I'm used to work with PVST with enhancements like Uplink Fast etc...
I'm aware that, in case of TC event in one instance (link down) the ageing time of the MAC table become 15s (from 5 minutes).
Now I'd like to move to standard RSTP, single instance. In case of TC (now a link Up) is the mac table completely or per port flushed? or the mechanism is always the one to lower the ageing time of the MAC entries ad wait?
Solved! Go to Solution.
With RSTP, the TC mechanism is a bit different. The switch detecting the change propagates BPDUs out of all forwarding ports, with the Topology Change flag set. When that happens, the receiving switches immediately clear the forwarding entries for all active interfaces (except the one on which the BPDU was received) and then propagate it further out of all those ports.
PS> Pls do remember to rate posts.
thank you for the explanation.
Beyond the different causes to TC generation,
the difference is that a TC for PVST produce the lowering of the aging time for all MAC entries for that istance... (per Vlan)
Instead, for RSTP there is an immediate flush, per port.
Am I correct?
That's correct. As regular STP's convergence is supposed to be in the 30-50 seconds, there is no need to hurry and the fast aging time is sufficient (and efficient because active conversation don't get their cam entries flushed). With RSTP, it is not acceptable to wait 15 seconds to remove stale cam entries (else, what's the port of changing the state of the ports quickly). Thus, the ports are flushed, on a per instance basis. This will result in much more flooding but will maximize connectivity.
When Cisco implemented uplinkfast, before RSTP and its flush, we had to rely on dummy multicast generation in order to speed up the update of the cam table. This is an efficient mechanism, but not really scalable.
thanks a lot for very helpful support!
Just last question about this topic.
Any ideas about the difference between the two output sentecens form "sh spanning-tree deta ":
1) Topology change flag set, detected flag NOT set
2) Topology change flag set, detected flag set
The "detected" flag is set when a topology change was detected locally and needs to be advertised on the root port via a topology change notification (TCN). The TCN is periodically transmitted until a topology change acknowledgement (TCA) is received on the root port.
Have a look to http://www.cisco.com/warp/public/473/17.html for a detailed explanation of the topology change mechanism with STP and let me know if you have any question. In MST and Rapid-PVST, mode you should only see this on a root port connected to an STP bridge.
As per the document (what u gave on above link) it mentions that on 4000, 5000, and 6000's are able to show port and
ID of the bridge that last sent the topology change.
When i tried the command "show spantree statistics" is not
a valid command on a 4500 (IOS).
Does anyone know what the correct command would be?
"show spanning-tree detail" tells when last time the topology changed and from which interface.....Actually i want to know that if it is from FE 5/10 then which bridge(mac address) initiated that....
where as per documentation in CAT os "show spantree statistics" tells the mac address of the bridge which initiated the TC
It would be of gr8 help to me getting this mac address of bridge from which TC was reported...
SWITCH#sh spanning-tree detail
VLAN0001 is executing the ieee compatible Spanning Tree protocol
Bridge Identifier has priority 24576, sysid 1, address 0014.XXXX.XXXX
Configured hello time 2, max age 20, forward delay 15
We are the root of the spanning tree
Topology change flag not set, detected flag not set
Number of topology changes 5147 last change occurred 01:00:47 ago
from GigabitEthernet2/0/9 <--------| TC COMES FROM THIS INTERFACE
Times: hold 1, topology change 35, notification 2
hello 2, max age 20, forward delay 15
Timers: hello 0, topology change 0, notification 0, aging 300
I think you can follow the TC source switch b switch and find the sender...
In my case the switches(non cisco) connected through these ports does not give such a detailed information even not the interface name from where the TC has come.
And there are approximately 50-80 switches connected in some of the FE ports so it becomes very difficult to identify which switch has intiated TC.... if i have mac address atleast i can dig out