STP Root Guard (STP Toolkit)

#ccna#stp#switching#security

STP Root Guard

Author — Giovanny Jr Valerio Perdomo

Why root bridge selection matters

The root bridge is the central reference point for STP. Every other switch computes its path toward it, and redundant links get blocked to prevent loops. The choice is not arbitrary — it directly shapes performance.

Optimal traffic flow. Hosts mostly talk to servers or the internet, not each other. The root bridge should sit where it gives the most efficient path to the gateway router.
Stability & reliability. Pick a modern, robust switch. You want it up and unchanged for as long as possible.

          R1
          |
         SW1   <- best place for the root bridge
        /   \
      SW2 -- SW3   (SW2<->SW3 link gets blocked by STP)

Term	Meaning
Latency	Time traffic takes to travel through the LAN.
Congestion	How busy the network is — like trying to pump water through a tiny pipe.

Key takeaway: The root bridge should be a stable switch that provides efficient traffic paths. Don't pick it at random.

Consequences of a poor root bridge

If SW3 becomes the root instead of SW1, SW2's traffic now flows SW2 → SW3 → SW1 → R1 instead of straight to SW1.

Latency goes up slightly (usually <1 ms — often negligible).
The real problem is congestion: the SW3–SW1 link may overload, frames queue, and in the worst case frames get dropped.

The problem: external switches can disrupt your root bridge

Inside your own LAN you control the root by setting priority:

SW1(config)# spanning-tree vlan 1 priority 0

Cisco switches run PVST+, so the VLAN ID is always added to the priority. Priority 0 on VLAN 1 → bridge priority 1.

But the moment you cross-connect to another organization (e.g. a service provider's Metro Ethernet handing off to a customer), you lose that control:

   Service Provider                 Customer
   SW1 (prio 1, MAC ...a)           SW6 (prio 1, MAC ...8)
       \                             /
        SW2 ───────────────────── SW4
        SW3 ───────────────────── SW5

Both sides advertise themselves as root. Lower bridge ID wins → SW6 (lower MAC) becomes root for the entire combined network. Provider links get re-blocked, and SW3-to-SW1 traffic now detours through the customer's LAN.

Root Guard solution

Root Guard is a Cisco STP feature that protects your topology by refusing superior BPDUs received on protected ports.

A superior BPDU = one claiming a better (lower) root bridge ID.
Apply it on ports facing switches outside your administrative control.
If a superior BPDU shows up, the port is moved to a broken / root-inconsistent state — disabled until the offending BPDUs stop.

Configuration

Per-interface only — there is no global default (unlike PortFast / BPDU Guard / BPDU Filter):

SW2(config)# interface g0/2
SW2(config-if)# spanning-tree guard root
*Sep 21 08:38:56.314: %SPANTREE-2-ROOTGUARD_CONFIG_CHANGE:
  Root guard enabled on port GigabitEthernet0/2.

Behavior when a superior BPDU arrives

*Sep 21 08:38:56.321: %SPANTREE-2-ROOTGUARD_BLOCK:
  Root guard blocking port GigabitEthernet0/2 on VLAN0001.

The port becomes BKN (broken) with reason ROOT_Inc (root inconsistent). It cannot forward or receive data frames — all traffic over that link is cut.

SW2# show spanning-tree
Interface   Role Sts Cost     Prio.Nbr Type
---------   ---- --- ----     -------- -------------------
Gi0/0       Root FWD 4        128.1    P2p
Gi0/1       Desg FWD 4        128.2    P2p
Gi0/2       Desg BKN*4        128.3    P2p *ROOT_Inc

Flag	Meaning
`BKN`	Broken — port is disabled, no data forwarding.
`ROOT_Inc`	Root Inconsistent — the port was disabled specifically by Root Guard.

Note: Both sides of the blocked link end up as designated ports — an unusual exception to the "one designated port per link" rule, caused by the two sides disagreeing on the root.

Recovery from Root Guard blocking

Root Guard recovery does not require touching the switch running Root Guard. You just need the superior BPDUs to stop. Practically, the provider tells the customer to raise SW6's priority:

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

That makes SW6's bridge ID 4097 — worse than SW1's 1. After the superior BPDUs age out (~20 s, the default Max Age timer), the ports automatically come back:

*Sep 21 08:54:26.955: %SPANTREE-2-ROOTGUARD_UNBLOCK:
  Root guard unblocking port GigabitEthernet0/2 on VLAN0001.

No errdisable recovery commands needed (unlike BPDU Guard).

Where to configure Root Guard

Yes: The provider configures Root Guard on its ports facing the customer — protecting its own root bridge.
No: The customer should not turn on Root Guard on their ports facing the provider. The provider's switches will send superior BPDUs and the customer ports will block — cutting the very link they came for.

STP toolkit comparison

Feature	Global default?	Behavior
PortFast	Yes — `spanning-tree portfast default`	Skips listening/learning on access ports; immediate forwarding.
BPDU Guard	Yes — `spanning-tree portfast bpduguard default`	Errdisables any PortFast port that receives a BPDU.
BPDU Filter	Yes — `spanning-tree portfast bpdufilter default`	Suppresses BPDU send/receive on PortFast ports.
Root Guard	No — per interface only (`spanning-tree guard root`)	Disables a port that receives a superior BPDU; auto-recovers when they stop.

Bottom line: Root Guard is configured per interface on links facing networks you don't control. It freezes the port in a root-inconsistent state on a superior BPDU and recovers itself ~20 s after the offending BPDUs stop — keeping your chosen root bridge stable without manual intervention.

Reinforce Your Knowledge

$ ./quiz — STP Root Guard (STP Toolkit)
question 1/5score: 0/5
Q1.Why does the choice of root bridge matter most in a real network?
0/5 answered

$ ./flashcards — Study Deck
card 1/8seen: 0/8
# front · click or press space to flip
Which STP feature errdisables a port if ANY BPDU is received?
# back · answer
BPDU Guard
again:0good:0easy:0

← back to CCNA 200-301