Switch – Migrating from STP short mode to long mode

best practicesspanning treeswitch

It was decided recently to migrate a large campus network from the short mode STP costs (16-bit) to the long mode STP costs (32-bit).

I have clearly found it documented that this needs to be a "universal" configuration in that all switches need to support it and it needs to configured on all switches, however I have found very few discussions on how to migrate from short mode to long mode.

Most spanning tree costs in the campus network are dynamic, but there are some places where the costs were set manually.

When configuring long mode, would it be better to move from the root of spanning tree outwards to the edge or from the edge in towards the root?
How will the current manual costs be affected and should these be adjusted before hand in some fashion?
What issues should we be aware of before making this change?
If there were a few switches that did not support long mode and were left in short mode, would this still work? If so, should we be aware of?

Best Answer

I would run the change from root outwards but I don't think there are any use cases for doing it each way (someone correct me if I'm wrong).
Manual costs will stay exactly the same so you should at some point convert these to fall in line with your new costs once you have changed over.
Be aware of the fact that during topology changes or before you change over the manual metrics you may be running a sub-optimal L2 path between nodes.
It is recommended that all your switches run the same cost type and reference bandwidth, although I can't see any fatal flaws in not having them all the same it again could give you an inconsistent / sub-optimal L2 path.

Related Solutions

How to configure a port as STP “non-edge” on Juniper EX switches

set protocols rstp interface [interface] mode point-to-point

The JunOS STP interface mode docs and this example about Configuring Faster Convergence and Improving Network Stability with RSTP on EX-series Switches would seem to be of interest.

Preventing STP loops in etherchannels configurations

You should not be using "on" for link aggregation as it can lead to problems. On the side with aggregation statically on, it will use the interfaces in the etherchannel, no matter what the configuration is on the other side.

While storm control (from comments) can be very helpful with some of the problems that result, it does not resolve all of them. For instance if one of the remote side links is an access port on a different VLAN, all traffic that goes down that port will likely never reach its destination. Depending on how constant the traffic and the load balancing across the etherchannel, this may result in a complete "outage" for some hosts.

I always recommend the use of LACP over PAgP, so instead of desirable/auto or on, use either active on both sides or active on one and passive on the other. The reason for this is that LACP is standards based while PAgP is Cisco proprietary.

Of course this is in part dependent on the hardware platform, so check the appropriate documentation for your platform.

Best Answer

Related Solutions

How to configure a port as STP “non-edge” on Juniper EX switches

Preventing STP loops in etherchannels configurations

Related Topic