STP functionality after stack broken Cisco C9300 Stack

[nsmwella]

Hi, 

Here I have attached a snap for your reference.

A and B are C9500X switches and  C and D are C9300X switches. C and D are a switch stack. I need to know in case of stack broken between C and D what happen to STP ?

This is a SDA environment and A and B are the Fabric Border nodes. While we are doing LAN automation for C and D cluster suddenly the stack was broken ( investigating why it broken). At that time all the ports between A,B,C,D went forwarding state and loop happened. But after the stack broken this topology becomes a ring.

So, my concern is, in a case of stack broken in a this kind of topology and happened a split brain scenario is not STP functioning ?. If not what is the reason for that ?

Thanks

[pieterh]

if the stack is broken because of the interconnect malfunction,
then you indeed have a split brain scenario.

STP is likely to malfunction, because both switches think they are the stack-master and will activate all configured services.
in this situation both switches will use the same bridge-ID for BPDU packets. 

if the stack C-D was configured to be the root bridge, then the problem gets even worse
because all connected switches get root-bridge info from two different sides. (without detecting a loop)

[nsmwella]

@pieterh Does not the switch has a mechanism after the stack break even after some sort of time to change the bridge ID according to their own mac? or any command to to be added for happening it after a stack broken?

[pieterh]

Split-Brain Mechanism

• Shared Bridge ID (BID): A standard switch stack uses the same MAC address and BID for all stack members.
• Active-Active State: During a split-brain scenario, both stack members believe they are the active stack master.
• Duplicate BPDUs: Both switches output BPDUs with the exact same Bridge ID. Downstream switches receive the identical BID from two different physical locations, which masks loops and confuses the Spanning Tree algorithm. 

     MAC Address Source: The stack uses the MAC address of the current active switch as the bridge ID's base MAC address
-> you can reload one of the split-brain members ,it will restart with it's own BID
but better is to determine the reason  for the split-scenario and resolve this,
after all also the management IP address of both switches is the same
-> you get problems wnen using DOT1x authentication and when trying to  manage the device over SSH

other otion is to deconfigure the stack and give both devices a unique ip-address