[c-nsp] Rapid and classic Spanning Tree Interoperation/Migration

[Matt Buford]

"David J. Hughes" wrote:
> I may be wrong but I thought that the RSTP link change only impacted
> upon RSTP non-edge ports on the same device.  STP devices "below" that
> switch in the tree shouldn't be impacted upon because a TCN doesn't
> have any impact upon the topology of the receiving device.  You'd have
> to actually flap the link or block root BPDUs until the timers expired
> to get the STP instance on the downstream switch to recalc.  Or am I
> missing something that is about to cause me grief in our mixed RSTP /
> STP environment?

I believe it is only on the same switch (though I'm not 100% certain), 
however it is not "RSTP non-edge ports" but all non-edge ports.  Imagine a 
distribution layer switch with several downstream RSTP switches and one 
downstream STP switch.  Flap any of those RSTP ports, and the downstream STP 
switch drops off the network for the entire listen/learn delay.

So, we have 3 situations for non-edge ports when any other non-edge port 
flaps:

1.  Non STP speaker (should probably be portfast) - drops off the net for 
listen/learn.

2.  STP speaker - drops off the net for listen/learn.

3.  RSTP speaker - drops off the net but returns very quickly due to RSTP's 
quick convergence.

Also make sure you don't run code that is affected by bug CSCed63897.  This 
bug extends the behavior above to being triggered by any port flap, as 
opposed to only non-edge port flaps.

Another difference with RSTP is that when a TCN is generated the entire 
network-wide VLAN (all switches) dump their mac address table immediately, 
as opposed to STP's setting of a 6 second age.  This can make for giant 
bursts of flooded unknown unicast for the first second or two after a TCN.

After writing this, I read a bit more on Cisco's site.  It seems to me that 
this behavior is a result of problems in the original standard and this has 
been the focus least a couple redesigns.  Below are some relevant bug IDs. 
In the end, I'm not certain if the behavior I described above is still true 
in the latest IOS, or if it was just a temporary hack when they noticed that 
the original RSTP standard was broken and only in place until a proper fix 
was standardized.

CSCed00441
CSCed63897
CSCed85411

If anyone has better information, actually understands how this was 
resolved, and knows what the final/current behavior is please let us know. 
All of my lab testing and my TAC case on this issue is about 6 months old 
and was done on Sup720 with 12.2(17d)SXB1.

> Regardless of the protocol, portfast is your friend anyway ;-)

Agreed, but it used to be portfast was best-practices without being 
essential.  Now, if you forget some ports Very Bad Things start happening.