2600, spanning tree bug disables IP management?

[RicN]

On several Procurve 2626 switches running software H.10.67 I have seen some very strange problems, most likely a bug, which seems to be related to Spanning Tree.

The symptom is that when the Spanning Tree root is changed in the network the spanning tree topology is changed correctly on all switches, but the management IP on some 2626 switches sometimes is no longer reachable.
It happens directly after the Spanning tree is changed, so I belive the bug is somewhat related in the software - even if it has no logical connection.

If connected to such switch (with broken IP management) through the console I can see that all ports that should be forwarding is forwarding and the switch is working on Layer 2, but is not responding at all at Layer 3.

I have found two work-arounds - one is to simply reboot the switch and the other is to make Spanning Tree "work some more" on the device, for example by attaching one cable at two ports on the switch. The result is of course that one port gets blocked and - by magic - the IP management returns.

Have any of you seen this problem and do you know if HP is aware of this (likely) bug?

[Paulen]

Of course your management VLAN is tagged over the newly opened port, and all the way through?

[RicN]

Yes, all ports have the management VLAN tagged correctly. (Otherwise that would be a likely explanation.)

Since the management VLAN returns after for example a reboot with nothing else changed this also points no configuration error.

[Krzysztof Oledzki]

Yep, something like "me too".

I hit this problem several times, however it is very hard to debug it with limited physical access to the switches, so I was never sure that it is a 2626 problem and not for example 2828, I also have here.

The biggest problem is that when it happens, a switch is no longer able to authorize/authenticate clients via radius. :(

In the affected network I have two 2828 "core switches" and several 2626 "edge switches", connected like:


|----|<->2626<->2626<->2626<->2626<->|----|
|2828| <-> 2626 <-> 2626 <-> 2626 <->|2828|
|----| <---> 2626 <-----> 2626 <---> |----|
(sorry, it doesn't look good here, try to Ctrl+C, Ctrl+V to the notepad)

Both 2828 are connected with a dedicated 2x1G lacp link, and one of them is a STP root switch. I have UDLD enabled But I have never prooved that it is releated.

Like in the oryginal question - sometimes is is enough to reboot the affected switch, sometimes it can be solved by setting uplink port down/up/down/up on that switch or by doing the same with the downlink port on the uplink switch.

[RicN]

Interesting is that when I have observed this there were also 2800-switches involved as STP roots, and the issue did occour when the Spanning Tree Root status was changed from one 2800 to another.

However, since the Spanning Tree itself gets calculated correctly, I suspect it has something to do with the software on the the 2600. Something like when the CPU has been doing the STP calculations it "forgets" to hand back the CPU to the rest of the operating system.

[cenk sasmaztin]

very interesting RicN

please test

you make all uplink port managemet vlan untag member all other vlan tag member

and you make retest

[Krzysztof Oledzki]

Hm... just found it on the K.12.45 relnotes:

STP (PR_1000449365) â ARP & MAC tables get out of sync after a spanning tree (MSTP
or RSTP) re-convergence. An ARP entry fails to be associated to the port even though the
MAC entry exists. This may result in an unexpected ping failure.

Looks *very* similar.