defective second root bridge

[mandreano]

Hi,

we have flat l2 network with 48 swichts.

One RB and a BRB (the core).

Each access swicht have a active path to the root and an alternate path (RSTP) to the back root bridge.

Now one of the access switch had a hardware failure. These hardware failure causes the STP process to be root. But it doesn't send BPDUs nor process the received BPDUs. So all ports of this switch move to forward state and we had a loop.

Questions:

1. Someone knows this problem?

2. Is there any STP feature (Cisco proprietary?) with prevent such a problem?

ps: excuses my bad English. ;-/

[glen.grant]

sounds like a misconfiguration somewhere . Without knowing the network this would be pretty tough to troubleshoot in here . The root and secondary should always be a larger switch within the switched network . force those to be root and secondary . If configured correctly it should not cause a loop that is what spanning tree is designed to prevent . these might help http://www.cisco.com/en/US/tech/tk389/tk621/tech_configuration_guides_list.html

[mandreano]

Hi Glen,

thx for the answer.

I don't think it is a misconfiguration.

I will try the problem to describe more in detail.

Only the relevant switches:

Switch A (4510R): Root Bridge (Priority 8193)

Switch B (4510R): Backup Root Bridge (Priority 12289), connected with Switch A.

Switch C (3750 Stack): 3 StackMember (Priority 49153), connected with Switch A (Root Port) and Switch B (Alternate Port).

The StackMaster of Switch C had a hardware failure.

Crashes associated with this %SUPERVISOR-3-FATAL: MIC exception error and such a stack decode are most often due to

bad hardware. Therefore, I would suggest as very first step to replace the switch.

I could verify in some cases that symptoms are similar to yours. The switch eventually reloads several times,

cannot complete his bootup at first attempt, sometimes hangs and prevents the whole stack from stabilizing.

The STP process on this stack (switch C) assumed to be the RB. So all ports on switch C proceed to forward state

(designated ports). But switch C dosen't send BPDU or process received BPDU.

Switch A still remain the "true" RB. Switch B had switch A as RB.

So we had a loop between A, B and C. Switch A and C had only designated ports (characteristic for a root bridge)

and switch B had a root port port to switch A and a designated port to switch C (because it dosen't receive BPDU vom switch C).

possible solutions (IMHO would not have functioned):

loop guard:

In the normal topology switch C had the blocked port and switch B the designated.

So i do not think loop guard would have helped.

rood guard:

Switch A dosen't receive any superior BPDU.

udld:

The bidirectional connection functioned.

The Question: Is there a technique to prevent such a software problem?

hope helps me to help.

thx.

best regards,

marco