Spanning Tree Protection review

This topic seems to be coming up on the practice tests pretty frequently so it’s probably worth a quick review.  There are 4 types of spanning tree protection mechanisms that I want to cover, but let’s first look at a quick basic configuration…

Assuming that these switches were just ‘write erased’ (a new verb) and cabled in this manner, what would spanning tree look like?  Well, you should recall that spanning-tree likes configuration items that are lower.  Lower is better in spanning tree. 

Electing the root bridge – The switch with the lowest bridge ID becomes the root.  The bridge ID is a combination of the bridge priority and the bridge MAC address (Also the system ID extension, VLAN, but that’s the same per VLAN). 

Electing the root port – The root creates and sends hellos every 2 seconds.  Switches receive the hellos, update them with the appropriate information, and then forward them out all other ports.  The port that receives the hello with the lowest calculated cost to the root is the root port.

Electing the designated port – The switch that sends the hellos with the lowest advertised cost onto a segment.

So based on that information, and assuming that all of our ports are 10/100 Ethernet, we should be able to figure out what the topology is going to look like.  The cost of each interface should be 19 (Fast Ethernet cost) so let’s take a stab at what this topology will look like…

Picking the root here is a rather easy process.  All of the devices have the same priority so distro1 with the lowest MAC address wins the right to be the root.  Distro1 then begins forwarding hellos out of all of his ports.  The initial hellos will have a cost of 0.  Core will get the hello, add the cost of the ingress interface (19) to the hello and forward.  Distro2 will do the same thing.  Since both Core and Distro2 are receiving hellos with the same cost they need to fall back to the lowest bridge ID, followed by lowest port priority, followed by lowest forwarders port number.  In this case, the bridge ID of distro2 is lower than that of core so distro2 will win the designated router role for tat segment…

Taking a look at the spanning-tree output on the three switches we can see that we came to the correct conclusion…

Ok, so now we want to make the core the root bridge.  We can do this a couple of ways.  The main goal here is to make sure that the priority of the root bridge is the lowest…

Here we use the first method which is to ‘set’ the role of the bridge per VLAN.  In the first example, we set the bridge role to root primary.  This takes the current root bridge’s priority and subtracts 8192 from it.  If we use the secondary version of the command, it takes the current root bridge priority and subtracts 4096 from it.  In a stable topology (one that’s already configured) this would work out just fine.  However, if you set the primary on one switch, it’s just working off of the current root’s priority.  Let me show you what I mean…

Here I set the distro2 switch to be the vlan 1 root primary.  After things converge, I see that it is in fact the root of the spanning tree for vlan 1.  Now let’s go onto the core switch and manually change the priority…

As you can see, the core switch becomes the root.  The ‘spanning-tree vlan <vlan> root <primary|secondary>’ command only works of the existing settings.  That is, it’s a sort of macro that actually does the math and converts the ‘primary’ piece of the command to a hard number it puts in the config.  This is why I prefer actually setting the priority to using these commands.

Ok, so now we have the topology in place that I actually wanted to use in this post (took me a while to get there huh?).

Now let’s take a look at the spanning tree protection mechanisms that I wanted to talk about…

Root Guard
Root guard examines BPDUs that are heard through a particular interface and checks to make sure that they aren’t lower than the switches BPDU.  If it does hear a superior BPDU, the switch will put the port into a ‘root inconsistent’ state which prevents the port from passing traffic.  This prevents an unwanted port from becoming the root port on a switch.  If the condition clears, the superior BPDUs stop coming, the port is returned to it’s normal state.  As far as I can tell, the current recommendation is to enable this on access ports. 

It’s important to note here that it has to hear a BPDU that’s superior to the local switches BPDU.  NOT that of the roots.  For instance, if you enabled it on distro2’s port to the core switch that interface would go into the root inconsistent state.

Let’s take a look at a quick example…

Here we enable it on a single port on disto1.  Then we plug in the ‘user’ switch on that same port…

Any guesses on what will happen?

Nothing.  Why?  The BPDU the user switch is sending is not superior to the local distro1 switch.  See, you have to make some assumptions here.  If distro1 is NOT the root, then it’s BPDU is lower than the roots.  So as long as the new switch is not higher than the BPDU of distro1 (non-root) then everything is fine. 

So now let’s see what happens when we change the priority on the user switch to 0…

Instantly, the port on distro1 goes into root inconsistent.  We can see that in a couple of different outputs…

And when the priority changes back to normal, the port condition automatically restores to the normal forwarding state after going through the normal 802.1d port process…

BPDU Guard
BPDU guard is similar to root guard, but it’s more straight to the point.  If you have BPDU guard enabled on a switch, and you hear a BPDU, err-disable the port.  This condition can only be reversed by shutting and no-shutting the port to recover the err-disabled state.  The configuration is pretty straight forward…

Now if we plug the user switch back into that same port, we can see the action taken immediately…

So if you hear a BPDU, shutdown the port.  We can see this in a couple of different outputs…

BPDU Filter
Like the command suggests, BPDU filter prevents the port that the filter is configured on from sending BPDUs as well as disregards BPDUs that are coming into the port.  The configuration is pretty straight forward…

If we do the same test (plugging the user switch in distro1) we can see the results on each switch…

Dsitro1 puts the fa1/0/3 interface into the forwarding state after going through the normal STP port loading process..

And as you can see above, the user switch didn’t receive any BPDUs so it assume that it’s the root of it’s own STP domain. 

BPDU filter and guard in conjunction with portfast
I’m assuming that we all know what portfast is at this point.  But to summarize, it puts a interface into spanning-tree forwarding mode immediately.  Portfast can be enabled in two distinct ways.  The first is globally, and the second is by specific interface.  The key piece to understand is that they act differently based on the configuration. 

Global portfast puts access ports into the portfast state UNLESS they hear a BPDU.  If the port hears a BPDU, the port comes out of the portfast and goes through the normal listening, learning, forwarding spanning tree port process.  Interface portfast puts the port into an unconditional portfast mode.  BPDU or no BPDU, the port will always remain in portfast.

We can see the two different options in action below…

Above you can see what occurs when it’s configured globally.  The instant the port comes up and begins sending frames (BPDUs) the port loses it’s portfast status.  Now if we configure it on the interface…

We can see that despite receiving BPDUs, the port keeps it’s portfast status.  I bring this up because you can also configure the BPDU filter and guard functions globally on a switch.  These can be done via the following commands…

Note that these functions rely on portfast since it’s part of their configuration.  Keep this (any how portfast acts when it receives BPDUs) in mind when configuring the features.  For a deep dive on how these can interact check out Marko’s blog post on it here…

http://blog.ipexpert.com/2010/12/06/bpdu-filter-and-bpdu-guard/

Loop Guard
Loop guard is usually talked about in conjunction with UDLD.  The base premise of loop guard is that it prevents a port from transitioning from a blocking state to a forwarding state.  If you ran into a scenario where you had a link that failed in one direction.  The switch on the other end would no longer receive BPDUs and would believe that it should transition into forwarding mode.  This would cause a loop in the network.  If loop guard was turned on, instead of transitioning the port to forwarding, it would put the port in loop-inconsistent state.