Understanding and Configuring Root Guard in STP

Name: Video 2XE_PgkvSic
Uploaded: 2026-01-28T13:36:42.389671+00:00
Channel: Jeremy's IT Lab
Description: Summary and key takeaways on Understanding and Configuring Root Guard in STP, covering Introduction In this article we explore the Root Guard feature of the

Jeremy's IT Lab

Jan 28, 2026

•

4 min read

YouTube video ID: 2XE_PgkvSic

Source: YouTube video by Jeremy's IT Lab — Watch original video

PDF

Introduction

In this article we explore the Root Guard feature of the Spanning‑Tree Protocol (STP) as presented in Jeremy’s IT Lab. Root Guard protects the designated root bridge of a LAN by preventing external switches from taking over the root role.

Why the Root Bridge Matters

Optimal traffic flow – Placing the root bridge where traffic takes the shortest path reduces latency and congestion.
Stability & reliability – A robust, always‑up switch should serve as the root to avoid frequent topology changes.
Example – In a three‑switch LAN (SW1, SW2, SW3) choosing SW1 as root gives the most direct path from hosts on SW2 and SW3 to the gateway (R1). Making SW3 the root forces traffic from SW2 to travel an extra hop, adding latency and potential congestion.

What is Root Guard?

Root Guard is a port‑level STP feature that: 1. Monitors incoming BPDUs on a configured interface. 2. If a superior BPDU (one that claims a better root bridge ID) is received, the port is placed in a broken state labeled ROOT_INCONSISTENT. 3. The port stops forwarding frames, effectively blocking the external switch from becoming the root. 4. When the superior BPDUs disappear (they age out after the Max‑Age timer, default 20 s), the port automatically recovers.

Configuring Root Guard

interface GigabitEthernet0/2
  spanning-tree guard root

The command is entered in interface configuration mode; there is no global‑config option to enable it by default.
Only enable Root Guard on ports that connect to networks you do not control (e.g., provider‑to‑customer links).

Practical Scenario: Service Provider vs. Customer

Network layout – Provider side: SW1 (root), SW2, SW3. Customer side: SW4, SW5, SW6.
Both sides initially advertise their own root bridges (SW1 and SW6). Because SW6’s MAC address is lower, it would win the election, pulling the provider’s topology into an inefficient state.
By applying spanning-tree guard root on SW2 G0/2 and SW3 G0/2, any superior BPDU from SW4/SW5/SW6 forces those ports into the broken state. The provider’s root bridge (SW1) remains unchanged, and the two LANs cannot exchange traffic until the issue is resolved.
Resolution – The provider asks the customer to raise SW6’s priority (e.g., to 4096). Once SW6’s BPDUs are no longer superior, they age out (≈20 s) and the guarded ports automatically transition back to forwarding.

Recovering from a Root Guard Block

No manual CLI action is required on the guarded switch.
The port returns to normal once it stops receiving superior BPDUs.
show spanning-tree will display the port status changing from BKN ROOT_INCONSISTENT to FWD.

Best‑Practice Guidelines

Guideline	Reason
Enable Root Guard only on uplink ports to external networks	Prevents accidental loss of the root bridge while avoiding unnecessary port shutdowns.
Do not enable it on every port (unlike PortFast, BPDU Guard, BPDU Filter)	Root Guard is meant for selective protection; a global enable would block legitimate topology changes.
Pair Root Guard with proper bridge‑priority planning (priority 0 for the intended root)	Guarantees the desired switch stays root when you have full control of the LAN.
Use BPDU Guard on PortFast ports to protect against rogue BPDUs from end hosts	Complements Root Guard by securing access‑layer ports.

Comparison with Related STP Features

PortFast – Moves a port to the forwarding state immediately; useful for end‑host ports.
BPDU Guard – Disables a PortFast port that receives any BPDU (err‑disable). Recovery requires manual or timer‑based actions.
BPDU Filter – Suppresses BPDUs on a port; can hide a switch from STP but may cause loops.
Root Guard – Specifically blocks a port from becoming a root port; auto‑recovers when the offending BPDUs disappear.

Summary

Root Guard is a lightweight yet powerful tool for preserving the intended STP topology when connecting to networks you don’t control. By configuring it on the appropriate uplink interfaces, you ensure that your chosen root bridge remains stable, traffic follows optimal paths, and any superior BPDUs are safely blocked until the external side adjusts its bridge priority.

Root Guard safeguards your LAN’s STP design by automatically blocking ports that receive superior BPDUs, ensuring the chosen root bridge stays in place and traffic remains efficient without requiring manual intervention.

Frequently Asked Questions

Who is Jeremy's IT Lab on YouTube?

Jeremy's IT Lab is a YouTube channel that publishes videos on a range of topics. Browse more summaries from this channel below.

Does this page include the full transcript of the video?

Yes, the full transcript for this video is available on this page. Click 'Show transcript' in the sidebar to read it.

Why the Root Bridge Matters

* **Optimal traffic flow** – Placing the root bridge where traffic takes the shortest path reduces latency and congestion. * **Stability & reliability** – A robust, always‑up switch should serve as the root to avoid frequent topology changes. * **Example** – In a three‑switch LAN (SW1, SW2, SW3) choosing SW1 as root gives the most direct path from hosts on SW2 and SW3 to the gateway (R1). Making SW3 the root forces traffic from SW2 to travel an extra hop, adding latency and potential congestion.

What is Root Guard?

Root Guard is a port‑level STP feature that: 1. Monitors incoming BPDUs on a configured interface. 2. If a **superior BPDU** (one that claims a better root bridge ID) is received, the port is placed in a *broken* state labeled **ROOT_INCONSISTENT**. 3. The port stops forwarding frames, effectively blocking the external switch from becoming the root. 4. When the superior BPDUs disappear (they age out after the Max‑Age timer, default 20 s), the port automatically recovers.

Helpful resources related to this video

If you want to practice or explore the concepts discussed in the video, these commonly used tools may help.

Cisco Catalyst 2960 Switch Recommended

Provides reliable hardware for implementing STP features like Root Guard, essential for stable enterprise networks

Amazon →

Ccna Official Cert Guide 6th Edition

Covers STP concepts and configuration steps, helping learners master Root Guard and other essential networking topics

Amazon →

Links may be affiliate links. We only include resources that are genuinely relevant to the topic.

Summarize another video

Full Transcript YouTube

Hello and welcome to Jeremy’s IT Lab. 
In this video, we will cover another  
feature in the STP toolkit. This time, the 
focus is Root Guard. As the name implies,  
Root Guard guards the root bridge of the LAN, 
ensuring that another switch with a lower bridge  
ID can’t take over the role. It’s typically used 
when connecting your switches to someone else’s  
switches that you don’t have direct control over. 
For example, if a service provider connects their  
switches to a customer’s network, the provider 
might want to ensure that the root bridge remains  
in the service provider’s network. And Root 
Guard can help with that. Let’s get started.
Here’s what we’ll cover. This is the third video 
in the STP Toolkit section of this course. We’ve  
already covered PortFast, BPDU Guard, and BPDU 
Filter in the previous few videos. And now we’re  
moving on to Root Guard, which prevents a port 
from becoming a root port by disabling it if  
superior BPDUs are received, thereby enforcing the 
current root bridge. As I mentioned in the intro,  
this can be very useful when connecting your 
LAN to another LAN that you don’t have direct  
control over. There is also one more feature in 
the toolkit that you need to know for the CCNA,  
Loop Guard. We’ll cover that in the next video.
So, why is it important to ensure that a specific 
switch remains the root bridge? Before we look at  
Root Guard, let’s see why it’s valuable. As 
you know, STP prevents loops by electing a  
root bridge, that’s SW1 in the network above, and 
ensuring that each other switch has only one valid  
path to reach it. In this network, SW2 has one 
active path to reach SW1, the direct connection  
between SW2 and SW1. And same for SW3, only its 
direct link to SW1 is active. The link between  
SW2 and SW3 is disabled to prevent loops. Any of 
these three switches could be the root bridge and  
STP would fulfill its role of preventing loops. 
But you shouldn’t randomly select the root bridge.  
Good placement of the root bridge is important, 
and some things you should consider are optimal  
traffic flow. For example, you should try to 
minimize latency and congestion in the LAN.  
Latency just means how much time it takes traffic 
to travel through the LAN. And congestion refers  
to how busy the network is. If you try to pump too 
much water through a small pipe at once, it’s not  
going to be very efficient. And the same principle 
applies to network connections. So, with that in  
mind, why did I select SW1 as the root bridge for 
this LAN? Well, in most LANs like this, the PCs,  
like those connected to SW2 and SW3, don’t 
communicate with each other very much. Usually  
they want to communicate with servers outside 
of the LAN: over the internet, over the wide  
area network, the WAN, etc. So, we want to ensure 
that the PCs have an efficient path to reach R1,  
their gateway to the outside world. And that’s 
why I selected SW1 as the root bridge. Traffic  
from hosts connected to SW2 takes the SW2-SW1 
link. And traffic from hosts connected to SW3  
takes the SW3-SW1 link. This is the most efficient 
path for each host’s frames to reach R1. Another  
consideration when selecting the root bridge is 
stability and reliability. Once you select a root  
bridge that provides an efficient path for traffic 
in the LAN, you want that switch to remain up and  
operational for as long as possible. So, if you 
are using multiple kinds of switches in the LAN,  
one of the more advanced and reliable switches 
should be the root bridge. For example, if you  
only have enough budget to buy a couple of new 
switches, and the rest of them are old junkers you  
found in the closet, you should make one of the 
new switches the root, as you can probably rely on  
it not to die out after a few weeks of operation. 
So, those are a couple of considerations when  
selecting the root bridge: optimal traffic 
flow, and stability and reliability. Let’s  
focus on the first one and see what happens 
if we make a different switch the root bridge.
Now SW3 is the root bridge. What’s wrong 
with that? Traffic from hosts connected  
to SW3 takes the same path, but traffic from 
SW2’s hosts now has to travel from SW2 to SW3,  
and then from SW3 to SW1, before reaching R1. 
This adds a bit of latency, as the frames are  
taking a less direct path. But to be honest, 
that’s negligible in most cases: probably less  
than a millisecond. The true issue is that 
there could be congestion on the SW3-SW1 link  
if the network is busy. When a link is congested, 
frames have to wait their turn to be transmitted,  
and in the worst case some frames might be 
dropped, and that could seriously affect network  
performance and user experience. No one likes a 
slow network. So, the point is that root bridge  
selection is important, and after we’ve selected a 
root bridge, we usually want it to remain stable.
Let’s expand the network to show how Root Guard 
is useful. Within your own LAN, you can easily  
control the root bridge by setting its priority 
to 0. For example, here is SW1’s bridge ID. The  
priority is 0, plus 1 for the VLAN ID. Remember, 
Cisco switches run PVST+, so they always add the  
VLAN ID to the priority. Assuming SW2 and SW3 
have the default priority, this makes SW1 the  
root bridge. And for the three switches on the 
right, we’ll do the same for SW6, making it the  
root bridge for its LAN. However, there are cases 
where you might connect your LAN to other switches  
outside of your direct control. For example, maybe 
the LAN on the left is controlled by a service  
provider, and the LAN on the right is controlled 
by a customer. This is one example where switches  
controlled by different organizations might be 
connected. A service provider offering Metro  
Ethernet service to customers. Metro Ethernet 
isn’t something you have to study for the CCNA  
exam, but it’s often used to connect sites 
within a MAN, a metropolitan area network,  
such as connecting offices within the same city. 
So, what happens when the service provider and  
customer connect their networks in this example? 
Well, SW2 and SW3 will send BPDUs saying that SW1  
is the root bridge. But SW4 and SW5 will also send 
BPDUs saying that SW6 is the root bridge. So, who  
is right? Which switch becomes the root bridge? 
SW1 and SW6 each have the same bridge ID up to  
this point: a priority of 1, and a MAC address 
starting with 5254.001, but the next digit for  
SW1 is “a” and the next digit for SW6 is “8”, so 
SW6 has a lower bridge ID. And that means it will  
become the root bridge. So, the lesson here is 
that, even if you set your root bridge’s priority  
to 0, its role can be taken by another switch 
with a lower MAC address, like SW6 in this case.
So, with no safeguard in place to 
enforce SW1 as the root bridge, SW1,  
SW2, and SW3 all accept SW6 as the root bridge, 
affecting the service provider’s STP topology.  
Both the SW1-SW3 link and the SW2-SW3 link are 
disabled. So, frames from SW3 to SW1 must take  
a detour through the customer’s LAN. This 
is obviously not an efficient traffic path,  
but Root Guard can be used to avoid a situation 
like this. Root Guard can be configured to protect  
your STP topology by preventing your switches 
from accepting superior BPDUs from switches  
outside of your control. And a superior BPDU 
is a BPDU with superior parameters when it  
comes to the STP algorithm. For example, a 
BPDU that claims a better root bridge ID.  
SW6’s BPDUs claim a lower root bridge 
ID than SW1’s, so SW6’s are superior.
So, if you want to ensure that the root bridge 
remains in your LAN, you can configure Root Guard  
on the ports connected to switches outside of 
your control. We’re looking at this example from  
the perspective of the service provider, so that 
means SW2 G0/2 and SW3 G0/2, which are connected  
to the customer’s switches. The command to enable 
Root Guard on a port is SPANNING-TREE GUARD ROOT,  
in interface config mode. Unlike PortFast, BPDU 
Guard, and BPDU Filter, there is no command to  
enable it by default from global config mode. You 
can only configure it in interface config mode.
Now that Root Guard is enabled on SW2 and 
SW3’s G0/2 ports, what happens when they  
receive BPDUs from SW4 and SW5, claiming that 
SW6 is the root bridge? If a Root Guard-enabled  
port receives a BPDU, it will enter the “broken” 
“root inconsistent” state, effectively disabling  
it. We’ll examine what those terms mean 
when we look at the CLI of these switches,  
but basically this means that the port won’t be 
able to forward frames and will discard any frames  
it receives. All traffic is cut off. And SW1, SW2, 
and SW3 won’t accept SW6 as the root bridge. So,  
even though the service provider and 
customer LANs are physically connected,  
they can’t communicate. Before moving on, I 
want to point out that SW2 G0/2 and SW3 G0/2,  
as well as the ports they connect to on SW4 and 
SW5, are all designated ports. Normally, there can  
only be one designated port per link, but in this 
case the switches disagree on who the root bridge  
is. Just remember that in a normal, functional 
spanning tree LAN, there should only be one  
designated port per link. But this is a special 
case, because Root Guard is blocking the link.
Okay, Root Guard prevented the customer from 
influencing the service provider’s STP topology,  
solving the problem for the service provider. But 
that also means the customer can’t communicate  
over the service provider’s network. How can 
we fix this? To re-enable a port disabled by  
Root Guard, you must solve the issue that 
disabled the port. (CLUCK2)In other words,  
the disabled port needs to stop receiving 
superior BDPUs. To stop the superior BPDUs,  
the service provider should tell the customer 
to increase the priority of their switch. So,  
the customer increases SW6’s priority to 4096, 
plus 1 for the VLAN ID, and then what happens?  
Once the superior BPDUs received by SW2 and 
SW3 age out, the ports will automatically be  
re-enabled. And how long does that take? Well, as 
you already know, a BPDU’s Max Age is 20 seconds  
by default. So, it should take about 20 seconds, 
and then SW2 and SW3 G0/2 should be re-enabled.
And not only will they be re-enabled, but also 
SW4, SW5, and SW6 will finally accept SW1 as the  
root bridge. And the final STP topology might look 
something like this. SW1 is the root bridge, all  
other switches have one active path to reach SW1, 
and the remaining links are blocked. So, the point  
to remember here is that, to re-enable a port 
that has been disabled by Root Guard, you don’t  
have to do anything in the CLI of SW2 or SW3, the 
switches using Root Guard. You just need to stop  
the superior BPDUs, and then the disabled ports 
will automatically recover. In this case, the  
service provider told the customer to modify their 
switch’s bridge ID, and then the issue was fixed.
Since Root Guard only needs a single command 
to configure it, there’s not much to show in  
the CLI. But let’s rewind a bit and look at that 
process once more in the CLI. So, once again SW6’s  
STP priority is 1, making its bridge ID superior 
to SW1’s. I enabled Root Guard on SW2 G0/2 with  
the command SPANNING-TREE GUARD ROOT. I’m only 
showing SW2’s CLI here, but I did the same on SW3,  
too. After issuing the command, a message is shown 
saying that Root Guard has been enabled on the  
port. So, what happens when SW2 and SW3 receive 
BPDUs from SW4 and SW5? As this log message says,  
Root Guard blocks the ports. Take a look at the 
output of SHOW SPANNING-TREE. G0/2’s status column  
says BKN, and on the right it says ROOT_Inc. 
BKN means broken, and ROOT_Inc means Root  
Inconsistent. A “broken” port is basically 
disabled, it can’t forward or receive data  
frames. And Root Inconsistent tells us why the 
port is broken: it was disabled by Root Guard.
Let’s fix that problem by asking the 
customer to increase SW6’s priority,  
which is now 4097. After about 20 seconds, SW2 
shows a message saying that G0/2 is now unblocked.  
And as you can see here, its status is no longer 
broken, and the Root Inconsistent message is gone.
So, the network once again converges with 
SW1 as the root bridge. Before we move on  
to summarize this video, I just want to clarify 
where you should configure Root Guard. SW1, SW2,  
and SW3 belong to a service provider, and they 
want to ensure SW1 remains the root bridge. A  
customer's switch shouldn’t disrupt the STP 
topology by becoming the root bridge. Therefore,  
Root Guard is configured on the ports 
connecting to customer switches,  
like SW2 G0/2 and SW3 G0/2. However, note that 
you shouldn’t always configure Root Guard on  
every port connected to another network. For 
example, while the customer’s switches connect  
to the service provider, the customer shouldn’t 
configure Root Guard on their own ports. If the  
customer configures Root Guard on SW4 and 
SW5’s ports that connect to the provider,  
those ports will just be disabled if they receive 
superior BDPUs, blocking those links. And there’s  
no point in connecting to a service provider 
if you can’t communicate over their network.
Okay let’s summarize Root Guard. When selecting 
a LAN’s root bridge, you should consider a few  
things, such as optimal traffic flow that 
minimizes latency and congestion, as well as  
the stability and reliability of the switches. The 
root bridge plays a key role in the spanning tree,  
so it shouldn’t be a random decision. Within your 
own LAN, you can easily control the root bridge by  
setting its priority to 0. And if you have direct 
control over all of the switches in the network,  
there’s no need to configure Root Guard. But there 
are cases where you might connect your switches to  
other switches that are outside of your control. 
The example we used in this video was a service  
provider’s switches connecting to a customer’s 
switches, which might happen when the service  
provider is offering Metro Ethernet services, 
for example. Root Guard can be configured on  
specific ports to prevent them from accepting 
superior BPDUs from other switches. For example,  
a service provider’s switches generally shouldn’t 
accept superior BPDUs from a customer’s switches.  
You can use SPANNING-TREE GUARD ROOT to enable 
Root Guard on a port, and there is no command to  
enable it by default from global config mode. 
PortFast can be enabled by default because,  
in most cases, you want to enable it on all 
access ports, because they usually connect  
to end hosts. And BPDU Guard and Filter can be 
enabled by default on all PortFast-enabled ports,  
because those features are often used together. 
But Root Guard isn’t the kind of feature that  
you want to enable on ports by default. It should 
only be enabled on specific ports where needed,  
and that’s why it can’t be enabled in global 
config mode. And what exactly does Root Guard  
do? It prevents a port from becoming a 
root port if it receives a superior BPDU.  
Instead, the port’s status will be “broken” and 
“root inconsistent”. Basically, “broken” means the  
port is blocked; it can’t forward frames. And Root 
Inconsistent tells us why it is broken: because  
Root Guard blocked the port. But if the port stops 
receiving superior BPDUs, it will automatically  
recover. You don’t need to manually re-enable the 
port, or use ErrDisable Recovery like with BPDU  
Guard. Okay, that’s all for this video on Root 
Guard. I hope it was helpful. Thanks for watching.