Understanding STP Rootguard

• By Joe Astorino
• October 28, 2011
• 22 Comments

Introduction

The spanning-tree rootguard feature, like most extended spanning-tree features from Cisco often leaves students confused when they first learn it. The confusion is usually not because it is hard, but because we have to keep it straight amongst bpduguard, loopguard, rootguard, bpdufilter, uplinkfast, backbonefast…how to keep them all straight?!  In this blog I will show you guys exactly what STP rootguard is, how it works under the hood and how to implement it on your Cisco switches.  Are you ready?  Awesome, let’s get started

To summarize, STP rootguard actually does exactly what the name says, and that is how I personally have always remembered it.  Rootguard…it guards the integrity of the root bridge.  In other words, rootguard makes sure that the switch you want to be the root bridge in your spanning-tree topology remains the root bridge.  It is sort of a security mechanism that prevents other rogue switches from staging a coup against your chosen root bridge and taking over the root bridge responsibilities.  Why do we want this?  We’ll get to that in just a second.

Why Protect The Root Bridge?

If you are not sure what a spanning-tree root bridge is or how it gets elected, you probably need to brush up on that first.  You must walk before you can run.  Remember, all ports on a root bridge are always forwarding (because they are designated ports), so oftentimes it is not uncommon for traffic going from one switch to another to “pass through” the root bridge.  This is one reason why the root bridge is so important.  Take this diagram for example.  This is what we will be working on today in the lab!

Imagine that in the above diagram, Cat1 and Cat2 are your enterprise core switches and Cat3 is an access layer switch with a connection to each core, as is common in large enterprise networks.  Cat1 is the root bridge by design.  For simplicity, we will only be dealing with a single VLAN for this example.  Cat1, Cat2, and Cat3 are under your administrative control. Now, imagine what would happen if somebody fired up Cat4 at their desk and plugged it into a drop that goes to Cat3 Fa0/23.  Cat4 happens to have a lower bridge ID, so boom it gets elected root bridge.  OK, so what?  Well think about what spanning-tree will do there.  If you work through it, you will see that when spanning-tree converges, the link between your two core switches Cat1 / Cat2 will now effectively be down because one of those links will be in the blocking state. That means the only way to get data between the two cores now is through a crappy access layer switch.  That could be a REALLY bad day at work : )  You are now pushing all cross core data through an access layer closet.  Obviously, this is bad.  To prevent this, we need to make sure Cat1 remains the root bridge at all times, unless it fails for some reason.  THAT is what rootguard is all about

Rootguard “Under The Hood”

Rootguard really is not all that complex.  As we have said, it protects the integrity of the root bridge by making sure the root bridge remains the root bridge even if another switch with a lower bridge ID gets tossed into the mix.  That is great, but how does it do that?  Well, you configure rootguard at the interface level with the spanning-tree guard root command.  Essentially, if the switch sees any superior BPDU’s (from a switch advertising a lower bridge-ID than the current root bridge) on an interface configured for root guard, the switch puts that interface into a special STP state called root-inconsistent.  Root-inconsistent basically means not functioning…it is similar to the listening state, so no data is going to get passed on the port.  When the superior BPDU’s go away, the port automatically transitions back to forwarding which is nice.  You don’t need to shut/no shut the port or anything like that.

Let’s get a little deeper.  Another way you can think of rootguard is that it actually prevents the interface it is configured on from ever becoming a spanning-tree root port.  Why?  What is a STP root port?  It is the port on the switch that is closest to the root bridge right?  If a switch interface is an STP root port that means that interface is facing the root bridge.  In the case of an interface configured for rootguard, we never want that to happen.  That would mean the root bridge is downstream from us and not upstream from us.  For example, in our little lab setup here if Cat4 became the root bridge, Cat3 Fa0/23 would become a root port.  Rootguard prevents that from happening. This is also exactly why rootguard is incompatible with STP loopguard.  Loopguard is another topic entirely (and covered in an earlier blog post!), but basically it is configured on non-designated ports (blocking or root ports) and it prevents those ports from becoming designated ports in the event of lost BPDUs from the designated port due to unidirectional links.  Since rootguard is generally configured on designated ports and prevents the port from becoming a root port, but loopguard is generally configured on root ports and prevents the port from becoming a designated port, the two are inherently incompatible with each other.  They are sort of opposites from an STP mechanics perspective.

That brings us to the next common question — Where do I configure rootguard?  You generally want to configure rootguard on any switch ports where you never expect to lead towards a root bridge.

Building The Lab

Enough chatter, let’s get into the lab.  Our first goal is to build the lab we see in the picture, and to have the spanning-tree topology in the picture replicated.  All I have done thusfar is configured all the switch to switch trunks as shown in the diagram. According to the diagram, Cat1 should be our root bridge.  Let’s see if we got lucky…

Cat1#show spanning-tree

VLAN0001
  Spanning tree enabled protocol ieee
  Root ID    Priority    32769
             Address     000b.46e2.6980
             Cost        19
             Port        25 (FastEthernet0/23)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
             Address     0018.1820.2700
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time  300 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/22              Altn BLK 19        128.24   P2p
Fa0/23              Root FWD 19        128.25   P2p

Nope…it says the root bridge is 000b.46e2.6980 off of Fa0/23. Could the root be Cat2?

Cat2#show spanning-tree | i VLAN|is the root
VLAN0001
             This bridge is the root

Yes! OK, so first thing we need to do is fix that. Let’s make Cat1 the root bridge

Cat1(config)#spanning-tree vlan 1 root primary
Cat1(config)#do sh spanning-tree | i VLAN|is the root
VLAN0001
             This bridge is the root

Good! According to our diagram, Cat3 Fa0/19 should be blocking and Fa0/22 should be forwarding. Are they?

Cat3#show span | b Interface
Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/19              Altn BLK 19        128.19   P2p Peer(STP)
Fa0/22              Root FWD 19        128.22   P2p Peer(STP)

Perfect…now we can play with rootguard

Implementing Root Guard

We have a few options.  First, let’s just throw rootguard on Cat1 Fa0/22.  If ANYTHING downstream says they have a better bridge ID, the BPDU will eventually make it up to Cat1 and the link will be shutdown.  Let’s try it.

Cat1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Cat1(config)#int fa0/22
Cat1(config-if)#spanning-tree guard root
Cat1(config-if)#
*Mar  1 01:02:43.272: %SPANTREE-2-ROOTGUARD_CONFIG_CHANGE: Root guard enabled on port FastEthernet0/22.

Now let’s make Cat4 start advertising itself as the root bridge…naughty naughty :P

Cat4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Cat4(config)#spanning-tree vlan 1 priority 4096

Sure enough, a few seconds later we get the following console log on Cat1:

*Mar  1 01:05:19.006: %SPANTREE-2-ROOTGUARD_BLOCK: Root guard blocking port FastEthernet0/22 on VLAN0001.

Let’s examine this further…

Cat1#show spanning-tree int fa0/22 detail
 Port 24 (FastEthernet0/22) of VLAN0001 is broken (Root Inconsistent)
   Port path cost 19, Port priority 128, Port Identifier 128.24.
   Designated root has priority 4097, address 000d.bc51.6d00
   Designated bridge has priority 24577, address 0018.1820.2700
   Designated port id is 128.24, designated path cost 57
   Timers: message age 3, forward delay 0, hold 0
   Number of transitions to forwarding state: 2
   Link type is point-to-point by default
   Root guard is enabled on the port
   BPDU: sent 502, received 1701

Gotta love that the IOS tells us “Fa0/22 is broken” lol … OK, so notice the Root Inconsistent as well. Here is another command that shows this information

Cat1#show span | b Interface
Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/22              Desg BKN*19        128.24   P2p *ROOT_Inc
Fa0/23              Root FWD 19        128.25   P2p

Let’s fix it by defaulting the priority on Cat4…

Cat4(config)#no spanning-tree vlan 1 priority 4096

Sure enough a few seconds later on Cat1 …

Cat1#
*Mar  1 01:08:50.760: %SPANTREE-2-ROOTGUARD_UNBLOCK: Root guard unblocking port FastEthernet0/22 on VLAN0001.

Cool…so things are working as expected. But, this pass through is not really as ratcheted down as we want. If some clown plugs a rogue root switch into Cat3, I want the interface on Cat3 to go down. So, in a real network we would likely also configure root guard on Cat3 Fa0/23. Another option that could also be configured there would be bpduguard which would flat out errdisable the port on reception of ANY BPDUs.

Cat3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Cat3(config)#int fa0/23
Cat3(config-if)#spanning-tree guard root

*Mar  1 01:10:35.467: %SPANTREE-2-ROOTGUARD_CONFIG_CHANGE: Root guard enabled on port FastEthernet0/23.

Cat3(config-if)#do sh spanning-tree int fa0/23 det | i Root
   Root guard is enabled on the port

Let’s test again now …

Cat4(config)#spanning-tree vlan 1 priority 4096

Sure enough, after a few seconds Cat3 Fa0/23 goes root-inconsitent

Cat3(config-if)#
*Mar  1 01:11:32.839: %SPANTREE-2-ROOTGUARD_BLOCK: Root guard blocking port FastEthernet0/23 on VLAN0001.

Cat3(config-if)#do sh span | b Interface
Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/19              Altn BLK 19        128.19   P2p Peer(STP)
Fa0/22              Root FWD 19        128.22   P2p Peer(STP)
Fa0/23 Desg BKN*19 128.23 P2p Peer(STP) *ROOT_Inc

Since Cat3 took care of the problem further downstream, Cat1 is still A-OK

Cat1#show span | b Interface
Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/22              Desg FWD 19        128.24   P2p
Fa0/23              Desg FWD 19        128.25   P2p

Summary

Rootguard is an extended feature of STP on Cisco switches that protects the integrity of your root bridge.  Protecting the root bridge placement in your network is important to ensure that traffic is flowing over the optimal paths at layer 2 in your network.  The rootguard feature is implemented on a per interface basis with the spanning-tree guard root command, and the feature essentially prevents the interface from ever becoming a root port by placing the interface into root-inconsistent state upon receiving a superior BPDU.  When the superior BPDU goes away, the port automatically transitions back to forwarding.

I hope this blog was useful and informative.  Keep studying hard!