Wired Intelligent Edge

I have a a network of around 50 switches, a mixture of Linksys and replaching with HP Procuve. Over the past 4 weeks and have had edge switches (not in a loop), drop off becuase the switch befores port has gone in Blocking, and the swich at the end of the chain that has dropped off needs to be rebooted. Just wondered of anyone has an ieda of why thos would be. If I disable and enable the port of the switch it stays in blocking. (Sh Spanning tree attached, see port 10 blocking)

This is the second switch at the end of a run, with no loop so a little confused as to why the port is blocked??

Multiple Spanning Tree (MST) Information

STP Enabled : Yes
Force Version : MSTP-operation
IST Mapped VLANs : 1-4094
Switch MAC Address : 101f74-9b61a0
Switch Priority : 32768
Max Age : 20
Max Hops : 20
Forward Delay : 15

Topology Change Count : 18
Time Since Last Change : 11 hours

CST Root MAC Address : 0014bf-5ff5da
CST Root Priority : 32768
CST Root Path Cost : 180000
CST Root Port : 9

IST Regional Root MAC Address : 101f74-9b61a0
IST Regional Root Priority : 32768
IST Regional Root Path Cost : 0
IST Remaining Hops : 20

Root Guard Ports :
TCN Guard Ports :
BPDU Protected Ports :
BPDU Filtered Ports :

| Prio | Designated Hello
Port Type | Cost rity State | Bridge Time PtP Edge
----- --------- + --------- ----- ---------- + ------------- ----- --- ----
1 10/100TX | Auto 128 Disabled |
2 10/100TX | 200000 128 Forwarding | 101f74-9b61a0 2 Yes Yes
3 10/100TX | 200000 128 Forwarding | 101f74-9b61a0 2 Yes Yes
4 10/100TX | Auto 128 Disabled |
5 10/100TX | 200000 128 Forwarding | 101f74-9b61a0 2 Yes Yes
6 10/100TX | Auto 128 Disabled |
7 10/100TX | Auto 128 Disabled |
8 10/100TX | Auto 128 Disabled |
9 1000SX | 20000 128 Forwarding | 101f74-9ba000 2 Yes No
10 1000SX | 20000 128 Blocking | 101f74-9b61a0 2 Yes No

Although you claim there is no loop, I am pretty sure that there is a loop if one of your ports is blocking.

Your CST root port is #9, and your blocking port is #10, so those two ports must have a loop.

And if your VLAN config throughout your network is not compatible with your STP config, then I can imagine your edge switches get effectively cut off from the rest.

You may want to double-check which switch is actually your root, as it seems the priority of your root is (the default) 32768. If you ask me, best practice is to manually select a root (normally your core switches) and give that switch a better priority then the others, that can remain at their default values.

It seems you may have accidently made one of your edge switches become the root.

The switch config above is the switch before the one that I lose at the end of the chain. The only thing that I get off that switch (at the end that I lose) is that its CST Root changed to itself.

192.168.21.82 00839 stp:  CST Root changed from 32768:0014bf-5ff5da to 32768:101f74-9b50e0

I have reconfigued a core switch as my Root Bridge now as one of the other edge switch was root.

By assigning the root, you will probably not prevent this issue to happen; it will only assure the root -under normal conditions- is indeed at the center of your network.

The fact the affected switch tells you he just became root tells you there is some kind of communication-error between that switch and the usual root (well... you already know that... thats your issue)

To me, it really seems your STP- and VLAN- configurations throughout your network are not compatible.

Could you confirm there is physically a loop between the ports 9 and 10 of the switch you pasted the output from... there must be a loop. Is this happening all the time if you connect some switch, or 'just' spontaneously during the day ?

I just noticed in the other section, Fredrik gave the same comment about a loop...

There you mention the fact this happens when you reboot an edge-switch behind this one. Makes sense... that edge-switch probably has a redundant link to the root that comes up because of the reboot, perhaps forcing a root-election, or at least an STP recalculation. At that point your inconsistency in STP and VLAN configurations probably kicks in...

Hello Nic,

this is a software prolem on the HP Switch. We had a similar setup and 2 out of 20 switches are becoming unresponsive. The result ist causing trouble within the STP domain. Please contact your HP Support. If I have news regarding our ticket I will let you know.

Cheers,

Michael

Thanks Michael, not sure if thats the news that I wanted....

I have turned debug on and will grab a show tec when it happens again, then log a case with HP. Do you have your case number so that I reference it?

Just explain the links a bit better and there is no loop, the network at the edge look like the below (with a few more switches in between switch #1 and the core. I lose connectvity switch #2 (this is where it makes itself root), and the show span (as orginal post) is from switch #1

Link to Core Network----<Switch #1>-----<Switch #2>

There is definatly no loop on either of these switches, and both only have 1 client device attached to them.

Hi Nic,

you can refer to case ID: 4636791514. Currently it is elevated to level 2 support. The problem in this case: After some uptime (3-5 days) the switch doesn't respond to any management traffic: ICMP, telnet, ssh, http, STP, LLDP don't work anymore. Normal traffic is still assing the switch. Console access is still working.

Cheers,

Michael

Whilst you are logging a call and chasing that up, there are a few other things you could do too:

• Logging is easily visible on the ProCurves:

sh logging -r

• download the IMC management platform eval - it shows a really cool spanning tree map that has found at least one loop I didn't know was there!
• Check your switch spanning tree priorities (somebody has already mentioned this).
  Make sure the core switch is the root bridge (ie span priority 0)
• put all the edge switches with a priority higher than 8 / 32768 (eg span priority 12)

Still trying to work out what is going on with the HP tech. I turned spanning tree off on the switch that I lose at the end of the chain (the one that elects itself to the root), to see if the blocking on the previous switch and root election where symptoms rather than the cause.

Overnight the switch dropped off again (seems to be around 5 days now before I lose it). The switch before has not gone into blocking and I can still ping devices connected to the switch.

This is sounding like the issue the Michael is having as, I can get to the console, switching is still working but I have completely lost management, and for some reason when spanning tree it on it elects it self to the root bridge, which in turn blocks the port on the switch in front of it.

Anyone have any thoughts?

Only that it's going to elect itself root (by default) if the switch management is running but not processing incoming packets. I've seen 2510s act similarly, with old firmware which used to leak input buffers.

I have had this happen on another switch that I bought at the same time, where it looks like the management crashes, causes some spanning tree issues, but the switch can still pass traffic. I got the orginal switch replaced and it has stood up 4 weeks where it was only standing up  days previous. Interested if anyone else has had an similar issues with the 2520-8-PoE switches?

I got the same problems wth two 2520-8-poe we bought end of last year.

The management crashes but still the trafikk can go through for all the vlan configured.

Although I am not sure about the reason as there was not that much in the logs, I change with another 2520-8-poe switch I had and after a few days, that one is still reachable.

I am looking after some possibily problems with spanning tree, but I don't get how the management stack would be bloked and not the rest.

Rod

Hi,

I change one of the switch 2520 with a 2615. I haven't had that problem for more than a week now. I will ask for replacement of the 2520 cause the last software didn't help.

For anyone else that gets here via google like myself.....

We have quite a large network 500+ switches and recently started using 2520-8-poe as media converters and for our avms cabs.

We have about 20-30 in service now.  2 or 3 stop responding to ping/snmp/all management after days/weeks.  They do continue to forward traffic (including tagged vlans) so fed switches continue to work although those switches are cut off from the rest of the spanning tree.  

We also thought the bug was related to spanningtree so I used bpdu-filtering on incoming ports to isolate that switch (and those it fed) and depended on bpdu-protection on the edge ports to protect from loops. 

Sadely this did not fix the problem but it did prove it is nothing to do with spannintree on the network as a whole but may well be a bug on the switches firmware (14.30) or just a faulty unit.  

New firmware is out 15.xx so we will be trying that before raising a case with HP.  

Just thought I'd share to stop anyone else thinking there is some odd spanningtree loop on their network.

Hello Nic,

HP released the S.14.39 which should fix the management issue. The title of the bug is "IP Agent Becomes Unresponsive. Requires Reload to Recover"

It is not published on the web, but it will be offical supported. Please ask your friendly HP support for providing the image.

Cheers,

Michael

http://www.ingentive.net

Is anyone else still getting this "IP Agent Becomes Unresponsive"-problem?

I have two 2520-8-PoE switches with firmware S.15.09.0007 that have become unresponsive this week. Other traffic (than management) is still passing through.

We are not even using STP in these switches so that can't cause the problem here...or can it?

Hey Michael,

Thanks for the update, I have been working with HP and there is now a newer release as well 14.40. Unfortunitly this has created a new issue for me that I see on both the .39 and .40 release, where outside the subnet I cannot ping (or telnet or snmp) the ip address of the switch anymore.  I was just wondering if anyone else has also encounted this issue, I have gone back to my contact at HP and am awaiting their reply.

Thanks again to all that have commented on my orginal post.

Nic