Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Problem with Rapid PVST on 6509

I have a 6509 core switch which was recently changed from PVST to Rapid PVST (this is necessary for efficient FWSM synching to a redundant 6509).

I now find that after rebooting one of the access switches (all of which run PVST) a brief network outage was caused due to a spanning-tree election.

Prior to implimenting Rapid PVST the election would not have caused any outage. Can anyone explain why this is occurring?


Re: Problem with Rapid PVST on 6509

You need to be more specific.

In general with 802.1W a spanning-tree topology change would not disrupt your network.

If you have taken appropriate precautions to protect your root bridge against unintended root elections you should not suffer outages, especially not through the entire network.

When a change in the topology occurs, directly attached links will flush their CAM tables. This will result in unicast flooding, until the switch re-learns mac-addresses from all active systems.

If that switch, which was rebooted is directly connected to the core switch, it could result in flushing CAMs. No big deal for a 6509.

Track the source of the TCN by issuing "show spanning-t vlan x detail. See from what port the last topology change was sourced.

If you want to find the problem, try to reboot after working hours and see if you can simulate the same effects. Then you can enable debugging on intermediate switches to see what happens.

Please check if your current software has reported bugs regarding spanning-tree. This has been my experience in the past with Rapid PVST problems.



* Please rate ALL posts.

New Member

Re: Problem with Rapid PVST on 6509

Thanks Leon, and I appreciate the initial post was a little sparse with info.

This was an access switch directly connected to a 6509 (root bridge) over a 20Gb fibre port channel. Checking from the 6509 as you suggest shows the last TCN did come from the port channel.

One possible lead I have is that the access end of the port channel does have 'flowcontrol receive on' set. The 6509 end has no flowcontrol configuration.

I'm wondering whether this has stopped the access switch from receiving BPDUs from the 6509 somehow resulting in spanning-tree reconverging.

Unfortunately rebooting out of hours is not an option as its a high availabilty 24/7 environment.

I will also look into reported bugs on the relevant IOS versions.

If anyone does know of spanning-tree issues caused by flowcontrol configuration that would be really helpful.

CreatePlease login to create content