STP Continued

Hopefully by this point we're getting a great understanding of spanning tree protocol, the spanning tree algorithm, and bridge protocol data units. There are a few more things that we have to cover: the processes of spanning tree protocol, the statuses that each of the ports can be in, some timers, PortFast and how to bring a port up very quickly, and what a BPDU guard is for those ports.

How the process gets started

We already know a lot about spanning tree protocol, and about the spanning tree algorithm and the process it uses to communicate using BPDUs. However, one thing we haven't talked about is how this all gets started. We've mentioned a few aspects of this throughout, but let's talk a little more in depth about it.

Let's say there's a switch that's brought up that hasn't spoken on this network yet — it's just being powered up. What's going to happen is it's not going to immediately start forwarding packets, it's not going to immediately start passing information along. That's why in some of my demo videos we saw this pause: I would make a change and then it would be quite a while before that change took effect, and for a lot of those times it was because we were waiting on STP to do its thing.

What is it waiting for? It doesn't want to forward traffic and create a loop. So first of all it starts by just listening. A switch will listen to see if anything's going on, and then it will start responding, sending its own bridge protocol data units out to see if it can generate any traffic and generate any knowledge amongst this network, before it starts forwarding out a bunch of packets that are going to cause loops. That's really the process: there's this waiting game, this wait-and-see. It happens when a switch goes live, but it also happens when a port goes live, so even if you were just to plug in a single port, it doesn't start right away.

Port states

When a port comes live it's going to go through several states. It's going to start out in blocking, and then start working into listening, learning and forwarding, or go into the disabled mode. Each one of those states is going to have different functionality.

For instance, will it receive bridge protocol data units and process them? Next, will it actually send out bridge protocol data units — will it form its own bridge protocol data units and send those out? Then there is the MAC table updates. This is for just the traffic going across the switch. A switch, we know, does learning, where it learns MAC addresses, and also forwarding, where it forwards onto specific ports based off of those MAC addresses. So is the MAC address table going to get updated? And then, does it actually start forwarding frames, forwarding the traffic? These two aspects are what a switch is designed to do, so is it going to perform the functions of the switch? The switch is really not fully functional until it gets to the last word, where it's actually forwarding frames.

What we can see is that in the blocking state it just receives bridge protocol data units. The first thing it does, it says, I don't want to get too involved here, I just want to see what's happening and see how I can be part of this network and where I'm going to fit in.

Then it goes into that listening mode, where it actually sends bridge protocol data units as well as receives them. So it's both sending and receiving at that point in time, and now it's fully participating in spanning tree protocol. Until the listening mode happens, we don't get full participation in spanning tree protocol.

Then it goes into a learning mode, and the learning mode then includes learning the MAC addresses. Remember, that's going to be the source MAC addresses: as a frame comes into it, it'll take a look at the source MAC address and log that, and the port that it came in on, into the MAC address table. So now it's updating the MAC address table.

Then that port will go into full forwarding, where it actually forwards as well. And then, if for some reason it needs to be an alternate route — for instance, it is a redundant link — then it will go into this disabled mode, where it won't participate at all.

Timers

Here is a bridge protocol data unit, and something we went over real quickly before was these timers right here, this information on timers. Let's get a little more in depth into some of these.

The first one is the hello timer. The hello timer is the time in between the times that it sends out new bridge protocol data units. In this case right here it's two bytes long. We can set it; it can be set for a range, and that range could be anywhere from one second to ten seconds, but the default is two seconds. That's the hello timer, and it's sent out with the bridge protocol data units. Because it's sent out, whoever gets elected as the root bridge can set this standard for the rest of the environment and say, this is how often I'd like everyone to speak with these bridge protocol data units.

The next one is the max age timer. The max age timer is how much time a port is spent in blocking before it transitions. The max age timer is set by default for 20 seconds, but it can be set anywhere from six seconds to 40 seconds. So if you want to speed up this process you could go into your network and change that from 20 seconds as the default to 40 seconds if you want to wait longer, or down to six seconds if you want it to be shorter.

We also have this forward delay. The forward delay is how much time is going to be spent both in the listening and learning mode. So if you set this for 15 seconds, it's going to set it for 15 seconds in each mode — 15 seconds is the default, by the way — so it's going to spend a total time of 30 seconds while it's in here. This can be set anywhere from 4 to 30 seconds, but the default once again is 15 seconds. So far, before we ever get into the forwarding mode, we have 20 plus 30: there's a 50 second delay before this port actually becomes live.

PortFast

That is one of the reasons for a command called PortFast. PortFast can be set up on each one of your interfaces that you choose to set it up on. The reason why we do PortFast is because that 50 second delay can cause some problems. When you plug a device into your network, it's expecting to have some sort of connectivity, and it goes and reaches out and tries to find a DHCP server and get a DHCP address and tries to do some things on your network. If it's waiting 50 seconds, that's quite a delay before it actually can start communicating, and it possibly could even have gone over that DHCP discovery process at that point in time.

So one thing that we can do is say, we are going to set up PortFast on all access ports, all ports that are going to have end devices. All three of my pies, my demo laptop, and anything else that I want, I would set up as PortFast so it could transition much faster. What will happen in that transition is that it's going to skip some of those steps and go into sending information out much sooner. This is a command that can help my ports come up much faster, but I wouldn't want to put it on a port that has a switch plugged into it.

BPDU guard

Because we bring these ports up much faster, if we put PortFast on one of these ports, what happens if that port does get plugged into another switch? Then it will create a loop once again. Loops are really bad from a Layer 2 perspective — they cause a lot of problems with our Layer 2 networks — so we want to mitigate against this, and that's where the bridge protocol data unit guard comes into play.

What a BPDU guard is, is that we can put it on any of the ports that we have PortFast turned on. If a BPDU comes in on that port, then it will disable that port immediately. It'll shut off that port and it won't come live; you'll have to manually get onto there and actually set up that port again, or bring it out of the disabled state. That's BPDU guard. We want to use PortFast on a lot of our end devices, but BPDU guard helps guard against anything that happened to get plugged into a switch: it will disable that port and we won't get a loop on our network.