Network Development Team

Some of the IT support staff have taken the recently published IPv6 trial conditions quite seriously and we’ve already had two queries with regards to the spanning tree requirement. These queries aren’t disputing it but rather asking about specific behaviour that will occur when implementing it.

This is a slightly tricky article to write as

1. In our immediate team we tend to have spanning tree present on networks from the beginning
2. We use predominantly Cisco products on the backbone however college or department IT staff may be using any vendor, so please excuse any Cisco specific terminology – your vendors implementation should be roughly similar.

But lets dive in

1. Look at your network

Specifically do you have mix of vendors? Know in advance that although they can work together it’s possible to encounter some unexpected issues (I believe we’ve some investigative work planned in this area to assist).

You should have a login to your managed switches and complete list/inventory of the switch devices on your network. If not then perhaps you’ve inherited a network as part of a new position and some detective work is required to audit the network before you proceed. Cisco CDP, the IEEE LLDP or your vendors equivalent may be of assistance.

Draw a network diagram of your core network to help you visualise the network and speed up troubleshooting.

2. Decide on the type of spanning tree

Spanning tree is a great help, but depending on the age of your switch hardware and software you may have the opportunity to deploy rapid spanning tree (RSTP – IEEE 802.1w), which has benefits discussed below. You may also have the opportunity to use one of the implementations of per VLAN rapid spanning tree which you may decide to use if able and your network uses VLANs.

Dipping into the CCNA ICND2 Exam Certification Guide by Wendell Odom, Cisco Press we can save a lot of time and steal the following table from p88 which illustrates the features offered by the three main per VLAN spanning tree options on Cisco devices.

Option	Implemented via STP/802.1d	Implmented via RSTP/802.1w	Configuration Effort	Only one Instance Required for Each Redundant Path
PVST+	Yes	No	Small	No
PVRST	No	Yes	Small	No
MIST (MST)	No	Yes	Medium	Yes

I’ve altered the column title of the second (and third columns) in the above table from the original of ‘supports STP’ to make it clear that although the implementation may not use standard spanning tree it will co-exist with it. A network of rapid spanning tree switches can co exist with normal spanning tree and the switches will do the right thing in order to work together.

Don’t change the timing values of spanning tree when configuring it, leave these at the defaults. If you disagree with this then you’re probably excessively familiar with spanning tree and the advice in this article isn’t aimed at your level.

Mentions of spanning tree from this point onwards will tend to be generic unless otherwise stated and hence refer to whichever implementation you have chosen.

3. Plan – What will I see when I first implement it?

Firstly, standard spanning tree takes roughly 50 seconds to converge after a change, rapid spanning tree may be between 2-10 seconds. Convergence may be noticeable to your users as a delay, so perform the introduction out of standard working hours. If you have an at risk period, such as JANET’s Tuesday 7:00-9:00am period which has been widely adopted, then use this period.

In everyday use, if a link were to go down then with traditional spanning tree you might expect a reconvergence time to a redundant link of perhaps 30 to 50 seconds since any minor topology change might not result in a full network spanning tree reconvergence (e.g. it happens faster if you only have 3 switches instead of 30).  Those with a fascination for detailed scenario explanations should take a look at Cisco press “CCNP Switch 642-813 Official Certification Guide” by David Hucaby, p142 onwards.

I’d start by enabling spanning tree on your core switch e.g. the switch closest to the centre of your network (or one of them if you have more than one). It will initially assume it is the spanning tree root bridge until it decides otherwise from spanning tree traffic it receives. You can manually change the bridge priority to make the switch become the root bridge in any spanning tree election. Manually picking the root bridge will mean spanning tree topology should take reasonably expected paths in a more complex network. After this is done enable spanning tree on all your other switches.

If you’re unsure, the above paragraph seems confusing and you can count all your switch devices on a few fingers and toes then simply turn on spanning tree on all your switches. The switches will elect a root bridge without your involvement and should do the right thing.

With standard spanning tree as you enable it you might lose contact with switches for 20 seconds as the links start in spanning tree blocking mode then transition to forwarding (taking 20 seconds to do so), this is normal.

You might see some links go down and yet the network still functions – perhaps you didn’t know you had a redundant link (loop) on your network. Imagine you have the three switches – with a cable connecting them together in a triangle: with spanning tree two links would be up, the other would be disabled (connecting ports put into a blocking state), preventing a loop. If one of the live links was broken the disabled link would be made live automatically.

End users workstation ports connected to a switch running standard spanning tree will see a delay of roughly 30 seconds or more from connection to usability. This is noticeable to users and may result in odd complaints such as that “your DHCP server is too slow” or similar. You can configure “portfast” (I’m told on HP equipment this is the edge-port feature) on these ports to keep the port in a spanning tree forwarding state and make the delay vanish, which is good. The minor risk is that someone will plug in a switch that doesn’t do spanning tree to this port and another port, creating a bridging loop. Use BDPU guard (or your vendors equivalent) on ports you have portfast enabled on to protect against these ports being accidentally connected to another spanning tree enabled switch [this section may be expanded upon in the future].

4. Aftermath

Everything should be fine, but there would be a lot less IT positions if equipment always did what it should. Double check your network is functional (perhaps you have a Nagios,Zabbix or equivalent).

Look at what links (if any) spanning tree has disabled, and compare it to your network diagram. Did you know these redundant links were present?

You can now add intended redundant paths between your switches (e.g extra cables) for fault tolerance without impacting your network. Spanning Tree will automatically disable (connecting ports put into a blocking state) the redundant link when you plug it in and start using it when the usual link is broken.

Make yourself a cup of tea, smile to yourself and realise that you will have a reduced workload and less odd confusing issues with your network. When you hunger for more read more about STP, PortFast and BDPU Guard. Perhaps you might channel bond where you have dual links between switches and one is currently disabled by spanning tree. You might consider deploying Netdisco.

Finally don’t forget to drop our team an email to state you’re ready to take part in the IPv6 trials.