Chapter 1 – Introduction
It’s not a real big secret that networks don’t like loops. If loops aren’t handled properly, traffic can travel around your network indefinitely, consuming resources.
At layer-3, loop handling is built in. That’s the TTL value in the IP header.
Layer-2 on the other hand, is not so lucky. So instead, we have spanning-tree. In this video and the next, we’ll look at why we need it, and how it works.
Chapter 2 – The Need for Spanning Tree
So why do we need spanning tree? Think about what happens to a layer-2 network when a broadcast is sent. A broadcast goes everywhere.
What does that mean for a topology like this one? One switch will forward the broadcast to the other switches. The other switches will pass it on.
Eventually the traffic is looping around forever, and although it’s not shown here, each connected device would get a copy of the broadcast frame every time it passes through that switch.
That doesn’t seem so bad with only three switches, but if we add just one more, you’ll see that the messages aren’t just looping, they’re replicating.
We’re seeing a broadcast storm. Any traffic that is flooded will cause this problem, whether it’s broadcast or not.
On top of that, MAC table entries will be continually updated, as they’re receiving frames from different sources. Remember that a MAC can only be associated with a single port; the one it’s learned on.
So eventually all the switch resources will be consumed, and the network will cease to function.
We try to limit broadcast traffic with VLANs, but the real problem here is that there is a loop. And there’s no built-in solution to stop loops at layer 2.
So this is where spanning-tree comes in. Its purpose is to find places where there could be a loop, and prevent it from forming in the first place.
It does this by selecting one of the links in the loop and blocking it. This prevents frames from travelling around the network indefinitely.
But spanning-tree is also clever enough so that it will never block too much. Devices will always be able to communicate. Frames can always be delivered no matter where the destination device is.
The secondary part of spanning-tree is to respond if there are problems or changes in the network.
A link failure in this topology would leave one switch isolated, with no way of reaching the rest of the network. So, spanning-tree will detect this change, and adapt by enabling the link that it originally blocked.
Here’s a few quiz questions to get you started with. There’ll be plenty throughout the video.
Chapter 3 – BPDUs and the Root Bridge
We know why we need spanning-tree, so let’s now look at how it works. There are a few different versions of spanning-tree. We’re going to focus on the original version for now, just to understand the basics, then look at the improvements in RSTP later.
The first piece of the spanning tree puzzle is the BPDU, or Bridge Protocol Data Unit. This is a message that switches start sending out their interfaces from the moment they come online.
Each switch will see BPDUs from other switches. This is how they initially discover each other and learn details about their neighbours.
As each switch needs to know about other switches, they need unique ways to identify themselves. This is the Switch ID.
This is made up of two values; The Bridge Priority and the switch’s MAC address.
Switches can have more than one MAC address. But, they will select one to represent the switch as a whole. Cisco’s term for this is the Base MAC.
We can find the Base MAC by running show spanning-tree. Get used to this command, as we’ll use it a lot.
This is a good time to clear one thing up… In spanning tree terms, switches are called bridges. This goes back to a time before switches existed. So whenever you see something referring to a bridge, just think of a switch.
Here, under the Bridge ID, there is an address. This is the Base MAC. It’s a unique value, so not other switches will have it.
Each switch, or bridge, also has a priority. We can see this here as well. By default, this is 32,768. Don’t worry too much about the rest of what you see here, we’ll go through it soon enough. The main thing is that you can see the MAC and the priority, which make up the Bridge ID.
The bridge priority is a number from zero to 61,440. However, you can’t pick just any number from this range. It needs to be values that are divisible by 4096.
That seems like a weird requirement right? Well, there’s a reason for it. Within the BPDU message is the 16-bit Bridge Priority field. The actual priority starts at the 13th bit. Lower bits make up the Extended System ID, which we’ll talk about another time. The point is, we can’t use every value in that 16-bit range for the bridge priority.
Don’t worry too much if that doesn’t make sense. The important part to remember is that a valid priority is divisible by 4094.
So as I said, the default bridge priority is 32,768, which is about halfway through that range. If we want, we can change this value to something else.
It’s really very simple. In configuration mode, we use the spanning-tree command, enter the vlan that we’re configuring (which is something you have to do on Cisco switches), and give it a priority. We’ll talk about why we would do this in a moment.
So, the bridge priority and the switch MAC address make the switch ID. This is one of the pieces of information that switches share with each other when they send and receive BPDUs.
It’s good to get to know your neighbour, but there’s more to it than that. As the name suggests, spanning-tree uses a tree-like structure, with the main links branching out to other switches.
One of the switches in the topology will become the Root Bridge. This is the most important place in the topology, and is decided based on the bridge ID that we looked at a moment ago.
The switch with the lowest bridge ID becomes the root bridge. And of course, we can influence this. We can’t change the switch’s MAC address, but we can change the bridge priority as we saw earlier. If two switches have the same priority, the lowest MAC address breaks the tie.
When they first come online, every switch thinks they’re the root bridge. So, they’ll start telling other switches about it in their BPDUs. These are sent every 2 seconds by default.
When another switch claims to be root, it will also send BPDUs. Keep in mind that in the original spanning-tree protocol, only the root bridge would send BPDUs. Other switches would simply forward them on after receiving them, flooding them through the network.
So if a switch starts sending BPDUs and it has better, that’s lower, Bridge ID, its BPDUs are called Superior BPDUs.
When a switch receives superior BPDUs, it will realise that it’s no longer the root bridge. In the original spanning-tree, this means that it stops sending BPDUs of its own.
What it will do instead is forward the superior BPDUs out its other links, if it has any. In our example, there are no other links to send the BPDU out. Of course, it won’t send the BPDU on the link that it received it on.
The main takeaway from this is that there is a constant flood of BPDUs being sent through the switching network.
Now’s the time to see if you’ve understood what we’re talking about so far.
Chapter 4 – Root Ports and Port Cost
Of course, that’s not the end of it. Using the information learned from the BPDUs, a switch will build something like a map of the network. Not exactly a full map though, more like signposts pointing the way to the root bridge.
And that’s the key point here. Spanning-tree is all about finding the best path to the root bridge.
Think about the switch that just turned on, and received a superior BPDU. It received that BPDU on a particular port. So, it knows that this port points the way to the root bridge. It names this port the Root Port.
All switches have a single root port. The only exception is the root bridge, which doesn’t have a root port. After all, it doesn’t need a path to the root bridge, as it is the root bridge.
Let’s not lose sight of the big picture though. Spanning-tree needs to find loops in the network. How might it do that? To understand that, we need to know about Path Cost.
As you know, each interface has a speed. Something like 100-Meg, or 1-Gig. Spanning-tree uses this value to assign a Cost to a port. The faster the interface, the lower the cost.
There are two different ways that spanning-tree might calculate the cost. The old way and the new way.
The old way isn’t so good in modern networks, as it was developed back when all interfaces were slow. With modern fast interfaces, the cost looks very similar on all interfaces. The new method addresses this by using larger costs.
The main point here is that spanning-tree assigns a cost to every interface. We’ve just used some small values in the topology here to keep things simple.
If we use show spanning-tree again, we can see the cost on each interface. Notice that these are gigabit interfaces, and the cost is 4. There’s not much room to get a smaller cost for faster interfaces is there?
So we can change the pathcost method to long. This is done in configuration mode with the spanning-tree pathcost method long command.
When we look at the costs again, see how they’re much bigger? That doesn’t mean that they’re worse than before. It just means that they’re calculated differently. Faster links will still have smaller costs, and slower links will have larger costs.
Remember that in the original spanning-tree, the root bridge continually sends BPDUs. The directly connected switches can see the cost of the interfaces they received the BPDU on, and know how far away the root bridge is.
They forward the BPDUs on, but only after they have added this path cost to the message. When the next switch receives this BPDU, it can add the cost of its own interface to the value in the BPDU.
Now it knows the distance to the root bridge as well. It also knows which port is closest to the root bridge.
If there’s more than one path to the root bridge, it also knows which one is the best path. The best path is the root port. Remember that there can only be one root port per switch. It acts like a signpost pointing out the direction and distance to the root bridge.
These two questions should determine if you’ve understood this section. If not, it might be a good idea to review before going on to the next part, as you really need to understand root ports and path cost.
Chapter 5 – Loops and Blocking
But… We still haven’t found loops in the network have we? Let’s cover that now.
The root bridge sends out BPDUs. Switches receive them. Sometimes they may receive them on a few different ports.
In the example shown here, the switch has found two paths to the root bridge. The BPDU with the shortest path is the superior BPDU; The longest path is the inferior BPDU. Of course the interface that receives the superior BPDU is the root port.
What about the port that receives the inferior BPDU? This represents an alternate path to the root bridge. If there is more than one path to the root bridge, then there is a loop.
We have now discovered a loop in our network!
We simply can’t have an active loop, so one link needs to be blocked. But switch one?
It’s not too hard to guess is it? The switch blocks the interface that represents the longer path cost. This way, the better path is active.
The ports that spanning-tree block are called Blocked Ports. No traffic, other than BPDUs, can flow over these ports.
This process repeats on all switches for all alternative paths to the root. Once loops have been blocked, we can see the tree-like structure, starting at the root bridge.
Switches also forward on any BPDUs they receive, so other switches can learn a path to the root bridge. They send them out all interfaces, except the root port.
If a port isn’t a root port, and it isn’t a blocking port, then it is a Designated Port. This is a valid path to send traffic on, but it’s not a path to the root bridge.
The key points from this section are:
- Root ports point toward the root bridge
- Designated ports point away from the root bridge
Here’s a few more questions for you to test your understanding of these concepts.
Chapter 6 – Port States and Timing
You might have a question from this. You might be thinking ‘it takes time for spanning-tree to find these loops and handle them. Can we have broadcast storms during this time?’
That’s a good question. Spanning-tree has a trick for this also.
The process of assigning a path cost and port roles happens when the interface first comes online. This could be when first powering up the switch, when plugging in a cable, or when we enable the port.
When the interface comes online, spanning-tree takes it through a few steps. In the original version of spanning-tree, these are known as blocking, listening, learning, and forwarding.
First the blocking state. For 20 seconds the switch will not allow any traffic to pass, other than BPDUs. This gives the switch time to decide if this port will be root, designated, or remain blocking to prevent loops. If it remains as blocking, it won’t transition through the remaining states.
Next, the port will spend 15 seconds in the listening state. This is where the port waits to see if the topology is stable, and isn’t continually changing.
Third, the port enters the learning state, which also lasts 15 seconds. During this time the switch does what all switches do. It looks at traffic it receives, and uses it to build or update its MAC table. During this time it still won’t forward traffic out the interface, other than BPDUs.
And finally, the port transitions to the forwarding state. It can now forward normal traffic.
Take note that with the original spanning-tree, it takes about 50 seconds for a port to come online. This is not fast enough in a modern network. In the next video we’ll see how newer versions of spanning-tree have improved this situation.
And of course, there are two more questions for you to consider. Pause and look at them now, or come back later.
Chapter 7 – Topology Changes
So we’ve got our nice topology, spanning-tree has learned where the root bridge is, the cost of each path, and which links to block. This is great, but what happens when the topology changes? Perhaps adding or removing links, or switches, or hardware failures?
The first thing spanning-tree needs to do is detect these changes. One way it can determine that something has happened is if it doesn’t receive BPDUs when it expects to.
Each switch has a timer called the Max Age timer. This is 10x the interval at which BPDUs are sent. By default, BPDUs are sent every 2 seconds, so the default Max Age timer is 20 seconds.
If BPDUs are missing on an interface for the duration of the Max Age timer, then the switch knows that there is a problem of some sort, and will need to adjust the topology.
This means that the spanning-tree algorithm needs to run again, and probably make different decisions.
By way of example, we’re going to add a new link to our switch. It’s now going to receive BPDUs on two different ports, as BPDUs travel over all possible paths. The result is that our switch now has more than one path to the root bridge.
Of course, the switch will need to look at the path cost. It can see that there is a smaller cost in this BPDU, making the new BPDUs superior.
So, it will need to make this new interface the root port. But remember that there can only be one root port per switch, so the other port loses its root port status.
Do you know what happens to this port? You guessed it! As it represents an alternate path to the root bridge, there is a loop, and it needs to be blocked.
This switch will also notify the rest of the topology that there has been a change. It will do this by sending a special variant of a BPDU called a TCN, or Topology Change Notification.
The TCN is sent toward the root bridge. The root bridge then floods it’s own TCN through the rest of the topology.
There’s a little more to the process, but to keep it simple, the point is the whole switching network has been notified that there has been a change.
Here are two final questions to consider. In particular, pay attention to question 12…
It’s good to develop a few more skills in the lab if you can. This lab is focusing on the original spanning-tree.
This is about improving the spanning-tree topology, including selecting the best root bridge, selecting backup root bridges, documenting the topology, and changing the cost calculation
Because spanning-tree is such an old protocol, the original version doesn’t work so well in modern networks. Over the years there have been a few improvements.
The most common one is Rapid Spanning Tree, or RSTP. Head over to the next video where we’re going to look at how RSTP improves on the original spanning-tree.