SSO and MST

[darrinrobinson]

I am running a 6509 (IOS ver s3223-ipbasek9-mz.122-18.SXF3)with dual sup32's in SSO redundancy mode. I am also running Multiple Spanning-tree (MST). During testing I have found that when a switchover of the active supervisor occurs (due to physical remove), MST forces all active ports on the switch to go through spanning-tree again, resulting in an outage (approx 10 secs) to the attached devices. If I perform this same test when using PVST, this outage does not occur. Is this a limitation of MST?

[Francois Tallet]

MST is also SSO capable (the SSO code has been written at the same time for the three spanning tree modes available). Is it possible that as a result of your switchover you are losing the root port for instance and a sync is occurring? I'm not sure this should last 10 seconds, but it would explain why STP has to reconverge at least. If you could make easily the test with PVST, could you attempt it with rapid-PVST?

Regards,

Francois

[darrinrobinson]

I have reconfigured the test so that there is an uplink to the root bridge on both supervisors (combined in an etherchannel spanning the supervisors). When running MST and physically removing the active supervisor all trunk ports (except the uplinks to the root bridge) on the switch go through STP again (all normal ports do not go through STP contrary to my original post). When performing this same test when running PVST or Rapid-STP the trunk ports do NOT go through STP, so this is MST specific. This is an issue for us because we will be running 100+ VoIP phones on the switch and each phone will be a trunk connection (as the PC runs off the phone in a difference vlan).

[jbrunner007]

so run rapid-pvst.

its not really much overhead. If you insist on running mst, make it a layer 3 hop off the box instead of a stp branch... redesign if mst is a pain

[darrinrobinson]

The complete design has 9 floor 6500's connected to 2 core 6500's in seperate Layer 2 VLANs. Each Floor 6500 will have 100+ IP phone trunk ports. When running PVST/Rapid-PVST in this design the average CPU usage is around 50% with STP processes making up about 30% of the 50% (even with VLAN pruning). MST overcomes this issue due to the one instance of STP for all VLANs. A layer 3 design might be the answer.

[Francois Tallet]

If you are only using one MST instance, then indeed this will not be more complex that PVST. You basically don't have to touch the MST config at all;-)

I don't think of any reason why MST should behave differently than rapid-pvst in that conditions. Could you be a little bit more specific as to what you mean by "ports go through STP"? Do you see the port role change, or is it just designated ports to go to a blocking state. If you can afford to play around with your setup, could you enable some simple and focus on a single port that you see getting blocked?

Something like:

remote login switch (the MST debugs are on the supervisor, not on the msfc)

debug condition interface

debug spanning-tree mst role

debug spanning-tree mst sync

Enable this on the redundant supervisor, and we should see what's happening to this particular port when the switchover happens.

If you don't want to enable debugs, just doing some show span mst during the problem should already help.

Regards,

Francois

[Francois Tallet]

The brackets I put in the "debug condition" had a weird impact on the display. It was "debug condition interface type/x/y"

If you don't enter this, you will get the debug for all the ports... and they may be to many.

[darrinrobinson]

I have fixed this problem by enabling 'spanning-tree portfast trunk' on each of the IP Phone trunk ports. This stops MST from running through STP again everytime the active sup is removed (I was unaware that you could do portfast on trunks). Thanks to all that replied.

[Francois Tallet]

Well, you confirmed that there is a sync: portfast ports (edge ports in IEEE terms) are excluded from MST syncs. This is a solution only if these trunks do not provide any redundant l2 connection (This is the big warning you get on the console when configuring portfast;-)). If you need STP on these links (and I assumed it was the case when you told us about huge number of ports that you had to support and that lead you into an MST solution), then by configuring portfast you are introducing a problem potentially more serious than the one you are trying to solve.

I might have another solution, but indeed, if all the ports on your box are edge ports, then portfast everywhere is probably the best..

Regards,

Francois

[darrinrobinson]

They are all edge trunk ports for IP phones (with a PC sitting behind the phone). I have enabled bpduguard on the edge ports to protect from incorrect cabling/loops. I should have provided more detail on my setup in the begining. Thanks again for the help.

[Francois Tallet]

Then everything is fine, case closed;-)

You probably could have avoided to sync by configuring explicitly the cost of your root port on the etherchannel. But in your case where the trunks are edge ports, it's even better to configure portfast becaue it will also move the ports immediately to forwarding at link up (the cost trick would not have helped there, but would have probably worked on non-edge ports, dependending on your topology).

Thanks and regards,

Francois