Understanding Loop Guard: Protecting Your Network from Layer‑2 Loops

Name: Loop Guard (STP Toolkit) | CCNA 200-301 Day 21 (part 4)
Uploaded: 2026-01-28T17:51:42.916031+00:00
Channel: Jeremy's IT Lab
Description: Summary and key takeaways on Understanding Loop Guard: Protecting Your Network from Layer‑2 Loops, covering Introduction In this article we explore the Loop

Jeremy's IT Lab

Jan 28, 2026

•

3 min read

YouTube video ID: uJ5_Klha0ig

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

PDF

Introduction

In this article we explore the Loop Guard feature of the Spanning‑Tree Protocol (STP) toolkit. Loop Guard adds an extra layer of protection against layer‑2 loops that can arise when a port unexpectedly stops receiving Bridge Protocol Data Units (BPDUs).

Why Loop Guard Is Needed

STP’s Goal – Prevent loops by exchanging BPDUs every 2 seconds.
Problem Scenario – A unidirectional link (data flows only one way) can cause a port to stop receiving BPDUs without the link going down.
Result – The silent port may transition to a Designated (forwarding) state, creating a broadcast storm and a network loop.

What Is a Unidirectional Link?

Occurs when one fiber or copper pair is damaged, broken, or mis‑connected.
Most common with fiber‑optic cables because they use separate Tx and Rx fibers; damage to one fiber disables traffic in one direction only.
If the devices do not detect the fault, both ends stay up/up, but traffic only travels one way.

How a Unidirectional Link Triggers a Loop

Switch SW3’s port stops receiving BPDUs from SW2.
After the max‑age timer expires, SW3 assumes the link is loop‑free and promotes its port to Designated (forwarding).
SW2 still believes its port is blocking, so both ports forward traffic → a layer‑2 loop forms (SW1 → SW2 → SW3 → SW1).

Loop Guard Mechanics

When enabled, a port that stops receiving BPDUs does not become Designated after the max‑age timer reaches zero.
Instead, the port enters the broken (loop‑inconsistent) state, labeled BKN in show spanning‑tree output.
The port remains up/up (physically active) but is blocked by STP, preventing loops.
If BPDUs resume, the port automatically recovers to normal operation – no manual intervention required.

Configuration Options

Method	Command	Scope
Per‑port	`spanning-tree guard loop` (interface config)	Individual ports
Global default	`spanning-tree loopguard default` (global config)	All ports (can be overridden with `spanning-tree guard none` on specific interfaces)

Typical usage: enable Loop Guard on root and non‑designated ports – i.e., ports that should receive BPDUs.

Interaction with Root Guard

Mutually exclusive – a port cannot have both Loop Guard and Root Guard enabled.
Root Guard protects designated ports from becoming root ports; Loop Guard protects non‑designated/root ports from becoming designated.
The most specific command wins: an interface‑level command overrides a global setting.

Practical Example

Enable Loop Guard on SW3 G0/1: spanning-tree guard loop.
Verify with show spanning-tree interface detail – it reports “Loop guard is enabled on the port”.
Simulate a unidirectional fault (e.g., bend a fiber). The CLI shows Loop guard blocking port GigabitEthernet0/1 and the port status changes to BKN, LOOP_Inc.
Repair the fiber – BPDUs flow again, the port automatically returns to blocking (no longer broken) and normal traffic resumes.

Key Takeaways

Loop Guard does not fix physical faults; it mitigates their impact on STP.
It automatically blocks ports that lose BPDUs, preventing accidental loops.
Configuration is simple and mirrors other STP toolkit features (PortFast, BPDU Guard, BPDU Filter).
Remember the exclusivity rule with Root Guard to avoid configuration conflicts.

Loop Guard is a vital safety net for STP networks, automatically blocking ports that lose BPDUs—often due to unidirectional fiber faults—and thereby preventing costly layer‑2 loops without 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 Loop Guard Is Needed

* **STP’s Goal** – Prevent loops by exchanging BPDUs every 2 seconds. * **Problem Scenario** – A unidirectional link (data flows only one way) can cause a port to stop receiving BPDUs without the link going down. * **Result** – The silent port may transition to a Designated (forwarding) state, creating a broadcast storm and a network loop.

What Is a Unidirectional Link?

* Occurs when one fiber or copper pair is damaged, broken, or mis‑connected. * Most common with fiber‑optic cables because they use separate Tx and Rx fibers; damage to one fiber disables traffic in one direction only. * If the devices do not detect the fault, both ends stay **up/up**, but traffic only travels one way.

How a Unidirectional Link Triggers a Loop

1. Switch SW3’s port stops receiving BPDUs from SW2. 2. After the **max‑age** timer expires, SW3 assumes the link is loop‑free and promotes its port to **Designated** (forwarding). 3. SW2 still believes its port is blocking, so both ports forward traffic → a layer‑2 loop forms (SW1 → SW2 → SW3 → SW1).

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 Layer 2 switching with built‑in STP features, allowing you to implement Loop Guard and other protection mechanisms in a real network

Amazon →

Ubiquiti Unifi Switch 8 Poe

Affordable managed switch that supports STP and Loop Guard configuration, ideal for small‑to‑medium labs and production environments

Amazon →

Fiber Optic Patch Cable Lc To Lc 10m

High‑quality fiber patch cable reduces the risk of unidirectional links caused by physical damage, supporting stable STP operation

Amazon →

Network Cable Tester Handheld

Helps quickly identify broken or mis‑wired fibers and copper cables before they cause unidirectional link issues that Loop Guard must mitigate

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 one more feature in the STP  
toolkit, Loop Guard, which basically acts as an 
extra line of defense against layer 2 loops. Now,  
the entire point of spanning tree protocol 
is to prevent loops, that’s why we use it,  
so what role does Loop Guard play? Well, 
that’s what we’ll cover in this video.
In the previous few videos we’ve covered 
these four features of the STP toolkit:  
PortFast, BPDU Guard, BPDU Filter, and Root 
Guard. Now we’re moving on to Loop Guard,  
which protects the network from loops by disabling 
a port if it unexpectedly stops receiving BPDUs,  
ensuring it does not mistakenly enter 
the Forwarding state. There are a few  
situations where this might happen, such as a 
software bug on one switch that stops it from  
sending BPDUs. But in this video we’ll look at 
one specific scenario: a unidirectional link.
So, we’ve got these two switches, SW1 and SW2,  
and let’s connect them together. Under normal 
circumstances, this is a bidirectional link,  
meaning SW1 can transmit data to SW2, 
and SW2 can transmit data to SW1.
But a unidirectional link is a network link 
where data transmission occurs in only one  
direction. For example, SW1 can send frames 
to SW2, but SW2 can’t send frames to SW1.  
This is obviously not a desirable situation, 
and is typically caused by a layer 1 issue,  
some physical problem with the hardware preventing 
data from flowing in one direction. For example,  
damaged cables could cause this, or faulty 
connectors or transceivers, such as the SFP,  
small form-factor pluggable, transceivers used for 
fiber optic connections. In fact, unidirectional  
links are more common with fiber-optic 
cables than copper UTP cables. Why is that?
Let’s see. As we covered back in the beginning 
of the course, fiber-optic connections typically  
use two separate fibers, as I’ve changed the 
diagram above to show. The Tx, transmission,  
side of SW1 connects to the Rx, reception, 
side of SW2. And the Tx side of SW2 connects  
to the Rx side of SW1. Although they are separate 
fibers, these two fibers are considered one cable,  
connecting one interface on SW1 to one interface 
on SW2, and allowing both of them to send and  
receive data. The problem is that if one fiber 
is damaged, it can disrupt data flow in one  
direction, while the other remains unaffected. 
And on top of that, fiber-optic cables are simply  
more vulnerable to physical damage than copper 
UTP cables. If you bend a fiber cable too far,  
you’ll hear a small snap, and then the 
cable is dead: you won’t be able to use it.
Now, for a fiber-optic interface to be up/up, 
both fibers must be connected and functional.  
For example, look at this connection between 
two switches. They’re connected by a fiber-optic  
cable, and the two fibers are connected on both 
sides, so the link lights are green. So, that’s  
what a functional fiber-optic connection looks 
like. If there is a problem with either fiber,  
the devices should be able to detect it and 
disable their interfaces. So, if you disconnect  
or cut this fiber, SW1 and SW2 should detect it 
and disable their interfaces. This doesn’t result  
in a unidirectional link – the link is disabled 
entirely. Let’s take a look at that connection  
again. With one fiber disconnected, the link 
lights are now off. And after damaging the fiber,  
even if I connect it, the link lights remain 
off. But not all physical problems preventing  
communication will be detected. And if the 
devices fail to detect the physical problem,  
it could result in a unidirectional link. If there 
is a problem on one of these fibers that prevents  
data transmission, but the devices don’t detect 
it, their interfaces will remain up/up, and now  
we have a unidirectional link. SW1 can transmit 
data to SW2, but data that SW2 transmits can’t  
reach SW1. They both think the connection is up 
and running, but actually it only works one way.
So, what’s the problem with a unidirectional 
link? Before we cover Loop Guard, let’s see  
the problem it solves. Loop Guard doesn’t prevent 
unidirectional links, but it can protect against  
the negative effect that a unidirectional link 
has on STP. As you know by now, BPDUs originate  
from the Root Bridge and are forwarded out of 
designated ports like this, every 2 seconds. And  
these BPDUs are how the switches share information 
with each other to determine the STP topology;  
which interfaces should be forwarding, 
and which interfaces should be blocking.  
In this network, SW3 G0/1 is a non-designated 
blocking port because it receives superior  
BPDUs from SW2. To keep the diagram 
simple I didn’t include any details,  
but this is either because SW2 has a superior 
root cost or bridge ID compared to SW3.
But if the SW2-SW3 link becomes unidirectional 
and SW2’s BPDUs can’t reach SW3, what will  
happen? Let’s assume there’s a physical issue 
that prevents SW2’s frames from reaching SW3,  
but doesn’t cause the switches to actually 
disable their G0/1 interfaces; the switches  
don’t detect the underlying physical issue. 
SW3, which no longer receives BPDUs from SW2,  
will assume there is no more loop in the 
LAN. After the max age timer expires,  
SW3 G0/1 will become a Designated port 
and start forwarding BPDUs to SW2. And  
because SW3’s BPDUs are inferior to SW2’s, 
SW2 simply ignores SW3’s BPDUs. So, SW2 G0/1  
and SW3 G0/1 are both in the forwarding state, 
meaning we have a loop from SW1 to SW3 to SW2.
Let’s see how that loop works. If SW1 receives a 
broadcast frame on one of its other interfaces,  
it will flood the frame toward SW2 and SW3. The 
frame flooded to SW2 won’t loop because of the  
unidirectional link; SW2’s frames can’t reach 
SW3. But the frame flooded to SW3 will loop  
around the three switches like this. Each switch 
that receives it will flood it repeatedly. So,  
that’s the problem with a unidirectional link in 
a LAN using STP. SW3 G0/1 stops receiving BPDUs,  
thinks it should become a designated 
port and start forwarding frames,  
and then causes a loop. It would be better 
if the hardware issue caused the link to  
go down entirely. In that case, SW2 and 
SW3 would both disable their G0/1 ports,  
and there would be no loop. But how 
can we deal with a situation like this,  
where a hardware issue causes a unidirectional 
link? You guessed it: the answer is Loop Guard.
So finally let’s see how Loop Guard solves 
this problem. As I said before, Loop Guard  
doesn’t prevent physical unidirectional links, 
but provides a mechanism to detect unidirectional  
links and then prevent layer 2 loops. When a Loop 
Guard-enabled port’s max age timer counts down to  
0, it doesn’t become a designated port and start 
transitioning to the forwarding state. Instead,  
it enters the broken (loop inconsistent) state. 
That probably sounds familiar. Like the broken  
(root inconsistent) state triggered by a root 
guard violation, this blocks the port. Note that,  
in both cases, whether it’s Root Guard or Loop 
Guard , the ports remains up/up. So the port isn’t  
actually shut down, it’s just that STP blocks it. 
So, let’s say Loop Guard is enabled on SW3 G0/1,  
and the SW2-SW3 link is unidirectional, preventing 
SW2’s frames from reaching SW3. The max age timer  
on SW3 G0/1 starts counting down. Normally, when 
it reaches 0, it will become a designated port  
and start transitioning to the forwarding 
state. But when Loop Guard is enabled,  
it enters the broken state, preventing a layer 
2 loop from occurring. And like Root Guard,  
recovery is automatic. If the physical issue is 
solved and the broken port starts receiving BPDUs  
again, it will be automatically re-enabled. 
So, how can we configure Loop Guard? Like  
the other features in the STP toolkit, the 
actual configurations are simple. It can be  
enabled in two ways. The first is per-port, 
with SPANNING-TREE GUARD LOOP in interface  
config mode. The second is by default in global 
config mode with SPANNING-TREE LOOPGUARD DEFAULT.  
This enables Loop Guard on all ports by default. 
And then you can use SPANNING-TREE GUARD NONE in  
interface config mode to disable it on specific 
ports if needed. Loop Guard should typically be  
activated on any ports that aren’t designated: 
root and non-designated ports. In other words,  
ports that are supposed to receive 
BPDUs from designated ports. Then,  
if they stop receiving BPDUs, Loop Guard 
will disable them to prevent loops.
Now let’s take a look at Loop Guard in 
the CLI. I enabled Loop Guard on SW3’s  
G0/1 port with SPANNING-TREE GUARD LOOP. In the 
output of SHOW SPANNING-TREE INTERFACE DETAIL,  
it says “Loop guard is enabled 
on the port”. So, that’s it;  
it just takes that one command 
to enable Loop Guard on a port.
But before we see it in action, let’s also see 
how it looks when you enable it by default. So,  
this time, instead of enabling it in interface 
config mode, I used SPANNING-TREE LOOPGUARD  
DEFAULT to enable it in global config mode. Then, 
the output of this command is basically the same,  
but it says “by default” at the end. Okay, now 
let’s see what happens when Loop Guard blocks a  
port. Currently, all links are operational 
and SW3 G0/1 is receiving BPDUs from SW2.
But what if the link connecting 
them becomes unidirectional? Well,  
this message is shown in the CLI: Loop guard 
blocking port GigabitEthernet0/1. And in the  
output of SHOW SPANNING-TREE, G0/1’s status 
is BKN, and it also says LOOP_Inc. As you  
probably guessed, BKN means broken, and 
LOOP_Inc means Loop Inconsistent. The port  
is blocked because it stopped receiving 
BPDUs. Maybe there’s a sharp bend in one  
of the fibers that degraded the signal, 
preventing SW2’s BPDUs from reaching SW3.
But then, perhaps someone adjusts the cable and 
the data starts flowing again, and Loop guard  
automatically unblocks the port because it starts 
receiving BPDUs again from SW2. As you can see  
here, G0/1’s status is now blocking, not broken, 
and it doesn’t say Loop Inconsistent anymore. So,  
like Root Guard, Loop Guard automatically 
re-enables a port if the problem is fixed;  
you don’t have to issue any 
commands to re-enable the port.
I’ve added another switch to this LAN, 
one that is not your switch; you don’t  
have direct control over its configuration. 
Before we wrap up this video, let me point out  
something about Loop Guard and Root Guard. 
These two features are mutually exclusive,  
and by that, I mean they can’t be enabled on 
the same port at the same time. And that’s  
because they basically serve opposite purposes. 
Root Guard is meant to prevent designated ports  
from becoming root ports. If a Root-Guard enabled 
designated port starts receiving superior BPDUs,  
it will be blocked. And Loop Guard is meant to 
prevent Non-Designated or Root ports from becoming  
Designated ports. If a Loop Guard-enabled port 
stops receiving BPDUs, it will be blocked. So,  
looking at SW3 in the network above, 
G0/0 and G0/1 should use Loop Guard,  
and G0/2 should use Root Guard. It wouldn’t make 
sense to configure the opposite. For example, SW3  
G0/0 and G0/1 are supposed to receive BPDUs from 
SW1 and SW2. If you configure Root Guard on them,  
they’ll both be blocked, cutting off communication 
in the LAN. Okay, so just remember that you can’t  
enable both on an interface at the same time. 
How does that affect the configurations? If Loop  
Guard is configured on a port, with SPANNING-TREE 
GUARD LOOP, and you then configure Root Guard,  
with SPANNING-TREE GUARD ROOT, Loop Guard will 
be disabled on the port. The Root Guard command  
will replace it. And vice versa. If Root Guard 
is enabled on a port and you then configure Loop  
Guard, Root Guard will be disabled. And if Loop 
Guard is enabled by default, in global config  
mode, and you then configure Root Guard on a 
port, Loop Guard will be disabled on the port.  
In other words, the more specific configuration 
takes effect. The interface command applies only  
to one interface, it's more specific than the 
global command, so the interface command takes  
effect. This is true for many features in IOS. For 
example, it’s the same for PortFast, BPDU Guard,  
and BPDU Filter. If you enable PortFast 
by default in global config mode, but then  
disable it on a specific interface, the interface 
command takes effect. Remember that about IOS  
commands. Usually, the more specific command 
takes effect over the less specific command.
Okay let’s summarize Loop Guard. Its purpose 
is to protect the network by blocking a port  
if it unexpectedly stops receiving BPDUs. This 
could happen if, for example, there is a software  
bug preventing a switch from sending BPDUs. Or if 
there is a hardware issue causing a unidirectional  
link. A unidirectional link is a network link 
where data transmission occurs in only one  
direction. A normal link should be bidirectional, 
allowing communication in both directions. A  
unidirectional link is typically caused by layer 
1 issues on fiber-optic cables; that’s the most  
common scenario. If the connected devices don’t 
detect the issue and disable their interfaces,  
it can result in a unidirectional link. This 
prevents BPDUs from reaching the neighboring  
switch. And if a root or non-designated port stops 
receiving BPDUs, it will become a designated port,  
potentially causing a layer 2 loop. Loop 
Guard’s role is to protect against this. If  
a Loop Guard-enabled port stops receiving BPDUs, 
it enters the broken “loop inconsistent” state,  
effectively disabling the port. But if it starts 
receiving BPDUs again, it will be automatically  
re-enabled. There are two ways to configure it. 
The first is per-port, with SPANNING-TREE GUARD  
LOOP in interface config mode. The second is by 
default, with SPANNING-TREE LOOPGUARD DEFAULT  
in global config mode. This enables it on all 
ports, but you can then use SPANNING-TREE GUARD  
NONE to disable it on specific ports if needed. 
It’s similar to enabling PortFast, BPDU Guard,  
or BPDU Filter by default and then disabling them 
on individual ports. Final point: Loop Guard and  
Root Guard are mutually exclusive, so they can’t 
be active on the same port at the same time. So,  
if Loop Guard is configured on a port and you then 
configure Root Guard, Loop Guard will be disabled,  
and vice versa. And if Loop Guard is enabled by 
default and you configure root guard on a port,  
Loop Guard will be disabled on the port. Only 
one can be active at a time on each port. Okay,  
that’s all for this video on Loop Guard. I 
hope it was helpful. Thanks for watching.