12-12-2006 01:20 AM - edited 03-05-2019 01:18 PM
Hi Guys,
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?
Thank you,
Best Regards,
G.
Solved! Go to Solution.
12-12-2006 01:56 PM
Hi,
Yes. As I indicated in my earlier post, the TC change process in RSTP causes an immediate clearing of the forwarding database, which is different to PVST+, which reduces the aging time to the forwarding delay value of 15s.
You are correct :-)
Paresh
12-12-2006 01:26 AM
Hi,
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.
Paresh
PS> Pls do remember to rate posts.
12-12-2006 01:27 PM
Hello Paresh
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?
Best Regards,
G.
12-12-2006 01:56 PM
Hi,
Yes. As I indicated in my earlier post, the TC change process in RSTP causes an immediate clearing of the forwarding database, which is different to PVST+, which reduces the aging time to the forwarding delay value of 15s.
You are correct :-)
Paresh
12-12-2006 04:12 PM
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.
Regards,
Francois
12-13-2006 04:00 AM
Hi Guys
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
Best Regars,
bye G.
12-13-2006 11:15 AM
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.
Regards,
Francois
12-12-2006 02:03 AM
hi G.
I agree with Paresh.
Plz refer this link too.
12-13-2006 11:24 PM
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?
12-14-2006 02:42 AM
Hello,
try show spannning-tree detailed
hope this help.
Bye
G.
12-19-2006 01:17 AM
"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...
12-19-2006 05:21 AM
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...
Bye G.
12-19-2006 08:46 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide