Topology Change Event - PVST vs RSTP

[g.rodegari]

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.

[pkhatri]

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.

[g.rodegari]

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.

[pkhatri · Accepted solution]

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

[Francois Tallet]

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

[g.rodegari]

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.

[Francois Tallet]

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

[hardiklodhia]

hi G.

I agree with Paresh.

Plz refer this link too.

http://www.cisco.com/en/US/products/hw/switches/ps628/products_configuration_guide_chapter09186a00800d84bc.html#64546

[xs2sachin]

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?

[g.rodegari]

Hello,

try show spannning-tree detailed

hope this help.

Bye

G.

[xs2sachin]

"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...

[g.rodegari]

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.

[xs2sachin]

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