Migrate from Rapid-PVST to MST loopguard error

gbusson · ‎03-22-2007

Hi,

try to migrate this night from Rapid-PVST to MST. Having loopgaurd pb

Configuration

2 6506 Core Switch

14 3560 Distribution switch

14 3560 Access switch

Migration scenario

Step 1 :

All switch are configured with rapid-pvst

6506-1 primary root fo all vlan

6560-2 secondary root for all vlan

spanning-tree loopguard default &

spanning-tree portfast bpduguard default

configured on all 3560 switch (not on 6506)

Step 2 :

Migrate 6506-1 to MST (primary root for MST) : Ok, 45 s for spt calculation

Migrate 6506-2 to mst (secondary root for MST) : Ok, but 45 s for spt calculation and all my 3560 are unreachable.

Having loopguard blocking port msg on 3560

Step 3 : Migrate one 3560 to MST (OK), all other 3560 are unreachable

Question :

I read that MST and Rapid-PVST can works toguether. In my case, it doesn't works. Any known issues about that ? Is there a pb with the command Spanning-tree loopguard default and MST ?

Thank for your help

Gilles

Francois Tallet · ‎03-22-2007

MST interacts with PVST by replicating the CIST bpdu on each and every vlan. I think that the problem you have here is that the mst switch have not detected that they were connected to pvst neighbors because of loopguard.

When you are transitioning from pvst to mst, the STP code restarts. As a result, no BPDUs are sent for a while and it seems that it triggers loopguard on your 3560. When loopguard is triggered, the 3560 will not send any bpdu until they receive one from their neighbor. Thus, the mst switch will never detect that it's connected to pvst neighbor (it would detect that from receiving tagged pvst+ bpdus). The simplest solution in your case would be to flap your links manually (simple because you can do it from the core switches) or remove and re-enable loopguard everywhere.

Note that it is only worth migrating to mst if you have a majority of your bridges running mst. Else, you will in fact have worse performances. Interaction mst-pvst is slow and complex. Please, have a look to the mst white paper http://www.cisco.com/warp/public/473/147.html and let us know what's happening in your case.

Thanks and regards,

Francois

gbusson · ‎03-23-2007

Hi Fra?ois,

we planned to have all 3560 in mst mode. But when we have encountered the problem during migration, we decided to roll back all our switch in Rapid-PVST

Question : How do you flap the link manually ?

We will try again in 2 weeks. If i understand what you said about loopguard, i think the bzest way is to remove the spanning-tree loopguard default from all 3560 switch before beginning migration

Is that right ?

Best regards

Gilles

Francois Tallet · ‎03-23-2007

Yes, it's probably better to remove loopguard before the migration. What I meant by flapping the link was doing a simple "shut/no shut" from the core switch.

Also, I'd like to know about the kind of problems you got with the 3560 in MST mode. If you can run the latest version of MST on the whole network, you won't need loopguard because MST integrates a mechanism that prevent failures cause by uni-directional link failures.

Regards,

Francois

gbusson · ‎03-24-2007

I was able to reproduce the case on a test platform.

2 3750 Core switch + 2 3560 DSW + 2 3560 ASW

All running in Rapid-PVST, loopguard enable only on 3560

- Rapid-PVST to MST on 3750 CSW 1 : OK

- Rapid-PVST to MST on 3750 CSW 2 : OK

3560 are always reachable.

Roll back to Rapid-PVST on all switch

Connecting a CSS 11501 to one 3560 DSW (we have 8 CSS115001 in production)

- Rapid-PVST to MST on 3750 CSW 1 : OK

- Rapid-PVST to MST on 3750 CSW 2 : OK

3560 are now unreachable. Same problem that i had in production

Trying a new test

Roll back to Rapid-PVST on all switch

Connecting a CSS 11501 to one 3560 DSW

Removing loopguard on all 3560

- Rapid-PVST to MST on 3750 CSW 1 : OK

- Rapid-PVST to MST on 3750 CSW 2 : OK

3560 are still reachable

It seem's the problem is with CSS11501 and loopguard instruction on 3560

Any explanation ?