what causes a Topology Change in a topology without redundant link

[seanxiao]

hi all,

we have a topology without any redundant link. Every access switch is directly connected with the core switch, and it's a port-channel between access switch and the core. RSTP runs on switches by default, and we do not explicitly configure the core switch as the root bridge for all VLAN as we think that there is no discarding port at all, and every mac address is learnt correctly according to the interface where the NIC is connected to.

the thing is that I want to connect a new switch to the core switch for some test purpose. I know the newly-connected switch will send BPDU to the port (non-edge port) on the core that it 's connected to , and in this case, the port that the new switch connected to will transition to a designated port in forwarding status, which fulfill the condition of a topology change in RSTP. 

So in this case will the topology re-convergence and causes temporary connectivity lose? I think it won't because there is no blocking port before or after the new switch gets connected, and there is only one root port on a switch that connect to core , so the MAC address learnt from these ports are anyway valid and will be kept (not been flushed). 

What is your point of view? Thanks a lot!

[MHM Cisco World]

You need root guard and root primary/ secondary (or better config core priority with lowest value) this prevent any new SW add to your stp domain elect ad root and send TC to other SW.

MHM

[seanxiao]

thanks  MHM, our core is a stack containing two catalyst 6506 E member switch.

[MHM Cisco World]

The Core Nexus or c9500/9400/9600 or c6000series it not matter' 

We need always to keep our core the root of our STP domain.

MHM

[Joseph W. Doherty]

"We need always to keep our core the root of our STP domain."

Actually, what I believe @MHM Cisco World has in mind is protecting and selecting the root bridge for any L2 domain.

I mention this because a network "core" usually is thought of as the L3 core, but there may be many L2 domains, each with its own L2 root.  Often the L2 root is selected with the L3 gateway or L3 upstream hop.

[Joseph W. Doherty]

As @MHM Cisco World the big concern would be a newly added switch becoming a new root bridge.

Since you note you don't have any redundant path, logically the prior topology won't change, but the issue is all the bridges recalculating that.

[seanxiao]

thank you! so I might have temporary connectivity lose?

[Joseph W. Doherty]

'so I might have temporary connectivity lose?"

Yes, for the whole L2 domain!

Basically a root change causes the whole L2 domain to block until STP reconverges.

Such an event is usually noticable under rapid STP variants but not heart attack inducing like under non-rapid variants.

Also keep mind, if you have multiple VLANs, with Cisco's PVST, there's a root per VLAN, so only specific VLANs might be impacted.

In theory, other TCs shouldn't, themselves, disrupt the whole L2 domain, but in practice too many can disrupt or degrade parts or the whole L2 domain or part or all the devices hosting or connected to hosting devices of the L2 domain.  (I.e. think impact similar to L2 loop.)

The above is unusual, but best to try to reduce the possibilities of such happening with appropriate configurations.

One additional configuration statement I would suggest is setting non-trunk ports to use portfast globally.

[Martin L]

Note that there is significant change in how RSTP handles TC;  1,  only a link going UP state (into forwarding state) will cause the topology change event.  Such TC event will generate MAC flush event for 2xHelloTime seconds on all ports except to the port where the TC BPDU was received.  The "flushing MACs process" is one of drawbacks of RSTP due to nature of Ethernet (unicast flooding occurs until MACs are re-learned).  Good thing (in your case) maybe the fact that "flushing" happens on all ports except to the port where the TC BPDU was received. 

2, the edge links (PortFast links) do not create any topology changes, which is good thing ! This reduce  the amount of TC (topology changes) events on the network.  Also, Edge ports do not do those MAC addresses flushed as there are no MACs associated with edge ports. when a topology change message is received, thus further reducing flooding. Lastly, no TCN BPDUs are ever flooded out of the edge ports, as there is assumed to be no bridges connected downstream.

Finally, as mentioned above, if new switch has better BID, new Root Switch election will happen creating changes such as blocking all downstream ports on downstream switches (your existing switches will halt traffic for brief moment) via  process called synchronization or sync for short.   

Regards, ML
**Please Rate All Helpful Responses **

[seanxiao]

thanks Martin, so in this case no connectivity lose will occur? though P/A or sync will happen,  the mac address from the designated port (connecting to access switch) will not be flushed.

[Joseph W. Doherty]

BTW, what you describe doing, adding a switch without insuing root won't change is sort of like adding such a switch using VTP v1/2 without insuring the newly added switch won't overwrite VLANs definitions.  (Although probably much, much less impactful overall than a VTP oops.)

[Joseph W. Doherty]

Oh, although unasked, in L2 topology as described, sometimes it's asked, do we need to even use STP?

If we disable STP, the possible STP usage issues cannot arise, correct?

Yes, that's correct, but generally it's recommended to use a STP variant to handle inadvertent/accidental L2 loop creation.