Stacking issues/loss of stack members

[Tony Barrett_2]

I have various stacks of HP 2650 switches (all running f/w H.08.69). All stacks are chained via their Gb copper ports. The commander is the first switch in the stack, with a fibre uplink to the core switch (HP 5308).

Most of the stacks perform faultlessly, except for the two largest stacks (7 switches). The problem I have is that very regularly, I get lossofstackmember SNMP traps logged into OV NNM. The logs on the switches show these errors, and they can happen very frequently, and at odd times of the day (early hours of the morning).

The interesting thing is that the errors report loss of connection only to the 6th and 7th switches IN BOTH STACKS. I have never seen a loss of connection to any of the first 5 switches. The lossofstackmember errors seem to cause slowdowns or dropouts to clients on the last 2 switches.

I'm going to change the copper stack cables to see if this makes a difference, but it is very odd that two stacks with 7 switches both report loss of connectivity at the same point in the stack, and all other stacks with 2-4 switches never have a problem.

I'm under the impression I can stack up to 16 of these switches together, although I do understand the latency *may* be higher at the lower end of the stack, but they all connect together at 1Gb/s FD, and I'm not seeing any load levels that would indicate the commander not being able to get transmission packets through.

Am I seeing a bug in the firmware, or is it something else!

[Preston Gallwas]

Tony, are you using LACP? If not, HP has recommended to us when we were seeing this issue to issue "No int all lacp" at Switch(Conf)# to turn off LACP on all ports, as sometimes it can cause a block of a good port and drop the stack link.

You might also do a "Show Log" to see if something is showing up in there.

Also, there is a newer software for that switch so it might not hurt to upgrade those.

On that note, as to why it is just 2 stacks of several, the physical cabling may need to be tested.

[Tony Barrett_2]

Preston

Thanks for the pointer on LACP. We do run this, and I regularly see LACP blocking then releasing ports. Never thought this could cause a problem with stacking though. I'll give it a try and report back

[jamesps]

I would not remove LACP. It does help in tracing any network problems early. If LACP blocked one port then there is an external issue to look after. Do you use spanning tree at all? STP is the trickiest one to set up and until it is it does block ports all over the place especially if you have multiple redundant links and many switches to manage but once it is set up, it's a breeze. Together with LACP and IGMP they will make you a happy network admin :)

[Tony Barrett_2]

Well, rather than disabling LACP on all switch ports, I just tried disabling it on the stack uplink ports (Gb). Can't say I've noticed any difference though. I'm still getting loads of 'lossofstackmember' traps at the OV station, still on the stacks with more than 5 switches only though, and always at the 5th switch down in those stacks!

I'm not using STP. I'm probably going to be using switch meshing rather than STP.

If it's not LACP causing the problem, it has to be a firmware bug. There is no latency issues on any of the stacks, and no port errors on the stack ports.