It’s not often I get requests for a blog post, and actually this would be the first one. So I am not going to pass up on the opportunity. Besides, I am studying QoS at the moment, and haven’t got anything on that to blog about yet, and trying to get external access to Lync on mobile devices at work is doing my head in. The request was that as MST is a bit of a dry topic (and let’s face it, it really isn’t the most interesting thing out there) can I do a post on it, well I can, but I can’t guarantee that it won’t be any dryer than the text books. So before looking at MST, let’s have a look at STP in general.
A brief history of the spanning-tree protocol
The Spanning Tree Protocol (STP) is designed to ensure a loop-free topology within an ethernet network, by preventing bridge loops. STP also allows for redundancy using backup paths, so if one link goes down the network will quickly find another way to the destination.
STP is standardized as IEEE 802.1D, and is based on an algorithm created by Radia Perlman in 1985 while she was working at DEC. It’s probably older than some of the readers of this blog.
STP is the first part in the CCIE Exam topic list (1.10)
How STP works
Root bridge election
STP begins by electing a root bridge. The root bridge is the bridge with the lowest bridge ID, which is a combination of a priority number and a MAC address. The default bridge ID is 32768, but this can be changed (in multiple of 4096). So if the priority on a switch is set to 4096 then this switch would become the root bridge. Alternatively the primary command can be used. Using the primary command will change the priority to 24577, and you can use the secondary command for the “backup” root bridge, which would set the priority at 28673.
Least cost path determination
The second step in the process is for the switches in the topology to work out the best path to the root. The path cost is the sum of the costs of the different segments of the network. The port on a switch that has the least cost to the root bridge is called a root port.
STP, being the old but venerated technology it is, has a number of pre-determined port costs:
4 Mbit/s = 250
10 Mbit/s = 100
16 Mbit/s = 62
100 Mbit/s = 19
1 Gbit/s = 4
2 Gbit/s = 3
10 Gbit/s = 2
Like I said, its venerated, meaning its old but still useful – nowadays, as network speeds increase the port costs offered by STP don’t actually leave much room for additional network speeds, unless we use 1 and 0, or start to use decimal places. Which is why this is a good place to leave STP and move on to more recent technologies. I will come back to STP in another post as there is still much to talk about, such as how we overcome ties in path costs, how we can influence path decision making, BPDUs and STP port states. But that’s more suited to a separate post.
The next big thing to happen to STP was in 2001, and that was to make STP rapid. Unsurprisingly it was called the Rapid Spanning Tree Protocol (RSTP), also known as 802.1w. RSTP brought with it improved convergence times (less than 10 seconds) compared to the 30 – 50 seconds offered by STP. Again we’ll cover RSTP in a separate post. Before we leave RSTP it’s important to cover the port costs:
4 Mbit/s = 5,000,000
10 Mbit/s = 2,000,000
16 Mbit/s = 1,250,000
100 Mbit/s = 200,000
1 Gbit/s = 20,000
2 Gbit/s = 10,000
10 Gbit/s = 2,000
We can see now that there is much room for future expansion.
PVST / PVST+
PVST or Per-VLAN Spanning Tree along with PVST+ are Cisco proprietary. PVST only supported ISL, so PVST+ was brought out to support 802.1Q encapsulation, and became the default on Cisco switches. Then they brought out Rapid Per-VLAN Spanning Tree (RPVST). These per-VLAN spanning tree protocols create a separate spanning tree instance for each VLAN, hence the term per-VLAN. Again more on this in a separate post, but this does lead us nicely into why MSTP is the best option.
Multiple Spanning Tree Protocol (802.1s) was brought about by RSTP/RSTP+ having a big overhead on the switch. With RSTP there is a direct one-to-one mapping of spanning tree instances to VLANs. If there are 10 different VLANs then the switch must participate in 10 independent spanning trees. So MST allows for multiple spanning trees whilst still preserving scalability.
VLANs are mapped to a single MST instance, allowing for a minimum number of instances, whilst still preserving the needs of the network design.
Let’s start with creating a default spanning tree topology
We have three Layer 3 switches, with a basic configuration to carry VLANs 10, 20,30,40,50 and 60 between SW1 and SW2. SW1 will carry 10, 20 and 30 to SW3 and SW2 will carry 40, 50 and 60 to SW3.
I won’t bore you with a needless “sh run” for the switches, but all that has been done is create VLANs 10-60 using the “vlan <number>” command, and setting the ports above to be trunk ports.
Let’s have a look at the result of “show spanning-tree summary” though:
So some important things to notice here. Firstly the default STP mode for a Cisco switch is PVST, and that we have a total of seven STP instances. We can see that SW1 is the root for all of our VLANs, and if we wait a few seconds and try the same command again we can see that SW1 is now forwarding for all the VLANs:
So we have a nice, simple and working PVST implementation. Now lets see how to change this to MSTP.
We begin with the command “spanning-tree mst configuration“, and if we then use the command “show current” we can see that all our VLANs have been mapped to instance 0.
Now the plan is that we will have different instances between our switches. As we want to trunk half the VLANs from SW1 to SW3 and the other half from SW2 to SW3 then we need two instances. Its important to point out at the moment that by default there is an instance 0. So if on the CCIE exam the task is to make sure that only two instances are ever used then note that you shouldnt create instance 1 and 2, as that would mean you have three instances.
So here we will have instance 0 (VLANs 10, 20, and 30) and instance 1 (VLANs 40, 50 and 60) going between SW1 and SW2. Instance 0 will go from SW1 to SW3 and instance 1 will go from SW2 to SW3.
To create an instance is very straight forward, we use the instance command, followed by the instance number and then assign the VLANs to that instance, we can then check it using the “show pending command“:
Lastly we need to give our instance a name, a revision number and use the exit command in order to save the changes:
If we exit back out we can use the sh command to see our configuration:
We can see that instance 1 has been named, that we have 2 configured instances, and our mapped VLANs. Its important to note the line “% Switch is not in mst mode“, and we will come back to that shortly.
All we need to do form now is to make the same changes as above to the other two switches.
Once all the switches have been configured the same as SW1 we can decide about which switches are the root for our instances. So lets make SW1 the root for instance 0 and SW2 the root for instance 1:
Lastly we need to set the mode, and thankfully Cisco has given us a nice reminder that we need to do this by telling us “% Switch is not in mst mode“, and this is easy to do using the command “spanning tree mode mst“.
Once this is set on all three we can have a look at our spanning-tree topology.
If we run the command “show spanning-tree mst” we get a whole bunch of useful information:
Over all we can see that as each interface is an ethernet interface (note: not fastethernet) that the path cost is set at 2,000,000, which is the same cost as specified by RSTP.
Lets break the MST particulars down by instance.
SW1 tells us that the bridge address is aabb.cc00.0100, and the priority is 0. It confirms that it is the root “this switch for the CIST”. The CIST is the Common and Internal Spanning Tree (instance 0). We also know that the timers are all using the defaults, and that the ports are Designated forwarders, and are currently forwarding traffic.
SW1 tells us that the bridge address is the same as for instance 0, but the Root is aabb.cc00.0200, and that this is through port Et0/1. Et0/1 is a root port and that Et0/2 is again a Designated Forwarder, and is forwarding traffic.
SW2 also confirms what we are seeing, but with slight variation:
Looking at MST1 we can see that the Bridge address is aabb.cc00.0200, confirming what SW1 told us, and that the root for MST 1 is indeed itself. It also points to SW1’s bridge address for the root of instance 0.
Lastly SW3 knows of the root for instance 0 as SW1, and SW2 for instance 1. But we can see that it is blocking e0/2 for MST 0 (its links to SW2 and also blocking E0/1 for instance 1 (its link to SW1)
The context sensitive help does not have a lot of options for MST:
We can limit our show commands down to a specific instance, get the configuration, or look at the detail of MST overall, or limit it down to an interface, which is quite useful:
Here we can see quickly if any guards or filters have been enabled on the interface.
The benefits of MST
The benefits, as would be seen in an enterprise environment with a higher workload on the switch than we can see in this example would be reduced cpu and memory than with PVST, or similar. It doesn’t take long to set up and there is a good payoff for the time and effort.
So I hope that this hasn’t been too dry!
Great post dude, I am glad you accepted the request.