skip to content

In a spanning-tree campus, where do Root Guard and Loop Guard belong, and what failure does each one stop?

level: seniorimportance: should knowfreq 28%

answer

  1. each guard asserts something about a port
  2. designated ports versus root and alternate
  3. a better root offered from below
  4. silence on a one-way link

basics

~20 s

Root Guard goes on designated ports facing switches that must never become root and blocks on a superior BPDU. Loop Guard goes on root and alternate ports between switches and holds them blocked when BPDUs stop, as on one-way links.

solid answer

~40 s

Both are implementation features that encode a design assumption about a port. **Root Guard** sits on **designated ports** facing downstream switches, typically distribution downlinks to access switches. If a **superior** BPDU arrives, one advertising a better root, the port is blocked until superior BPDUs stop, so a misconfigured or rogue switch cannot move the root. **Loop Guard** sits on **root and alternate ports** on switch-to-switch links. Normally, when BPDUs stop arriving, spanning tree lets the stored information expire and the port becomes designated and forwards. On a **one-way link**, where the port's transmit still works but it receives nothing, that opens a loop. Loop Guard holds the port in a blocked state until BPDUs resume. Host ports get an edge port with BPDU Guard instead, and BPDU Filter is avoided.

go deeper

for a junior

Remember the pairing: Root Guard protects where the root is, Loop Guard protects against a blocked port wrongly starting to forward, and BPDU Guard protects host ports.

for a middle

Explain what triggers each guard: a superior BPDU for Root Guard, missing BPDUs on a root or alternate port for Loop Guard. Explain how each recovers on its own.

for a senior

Place guards from the port's role and what it faces, and spot misplacements, such as Root Guard on access uplinks, that turn a guard into an outage.

for a principal

Treat guards as encoded design assumptions. Decide which ones are enforced by template, how trips are alerted and reviewed, and when to remove the need for them with a routed access design.

## Every guard is an assertion **Root Guard**, **Loop Guard**, **BPDU Guard** and **BPDU Filter** are implementation features, widely shared names rather than parts of the IEEE spanning-tree standard. Each encodes something the designer knows about a port that the protocol cannot know on its own: - *"No switch below this port may ever become root."* That is Root Guard. - *"BPDUs must keep arriving here; silence means a fault, not a free path."* That is Loop Guard. - *"Nothing on this port bridges."* That is an edge port with BPDU Guard. Placement follows from the assertion. Put a guard where its assertion is false and it causes an outage instead of preventing one. ## Root Guard: protect the root you designed The root bridge is chosen on purpose, usually a distribution or core switch, by giving it the lowest bridge priority. Nothing in the protocol stops another switch with a lower bridge ID from taking over. A lab switch configured with a low priority, or any switch with a lower MAC address when the designed root was left at the default priority, can win the election and drag the whole tree's traffic through itself. Root Guard is set on **designated ports** that face switches which must never offer a better path to the root: 1. distribution ports facing access switches; 2. ports facing a customer's or another team's bridged network. When a **superior** BPDU, one announcing a better root, arrives on a guarded port, the switch places that port in a blocked state instead of accepting the new root. When the superior BPDUs stop, the port recovers by itself in common implementations; no operator action is needed. ## Loop Guard: silence is not permission On a **root port** or an **alternate port**, BPDUs normally keep arriving from the designated bridge on the other end. If they stop, spanning tree assumes the neighbour is gone: under 802.1D after Max Age, under RSTP after three missed Hellos. The port then becomes **designated** and moves to forwarding. That is correct when the neighbour really has gone. It is a disaster on a **one-way link**. Suppose one fibre strand of a pair fails, or a transceiver's receiver dies: 1. the alternate port stops receiving BPDUs, but its own transmit still works; 2. the stored information expires and the port becomes designated and forwards; 3. frames sent out of that port reach the neighbour over the strand that still works, travel back round the rest of the topology to the same switch, and are sent out again: a loop. **Loop Guard** changes step 2: when BPDUs stop on a guarded root or alternate port, the port is held blocked instead of being promoted. When BPDUs resume, it recovers by itself in common implementations. It belongs on **point-to-point links between switches**; it has no meaning on host ports. ## The placement table | Port faces | Its usual role | Feature | Failure it stops | |---|---|---|---| | Hosts, phones, printers | Designated, edge | Edge port + BPDU Guard | A foreign switch or looped cable joining the tree | | Downstream access switches (from distribution) | Designated | Root Guard | A downstream switch taking over as root | | Upstream switches (access uplinks) | Root, alternate | Loop Guard | A one-way link turning a blocked port into a forwarding one | | A bridged network you do not control | Designated | Root Guard, or a deliberate boundary | Someone else's switch moving your root | ## Misplacements interviewers like - **Root Guard on an access switch's uplinks.** Those ports receive the root's BPDUs, which are superior by design, so Root Guard blocks them and the access switch cuts itself off. Root Guard goes on the *other* end of that link. - **Root Guard and Loop Guard on the same port.** They target opposite roles: designated ports for Root Guard, root and alternate ports for Loop Guard. Common implementations do not allow both on one port. - **BPDU Guard on a switch-to-switch link.** The first BPDU from the neighbour shuts the uplink. - **BPDU Filter to "quiet" a port.** Applied directly to a port it stops BPDUs both ways, which turns spanning tree off there and hides any loop through it. In common implementations it also overrides BPDU Guard on the same port, because the guard never sees a BPDU. ## Why the guards matter for convergence Each guard trades a little availability on one port for stability of the whole tree. A Root Guard or Loop Guard trip blocks one link while the rest of the tree keeps its shape. That is far cheaper than a root moving or a loop forming, both of which force every switch to reconverge, flush MAC tables and flood unicast across the VLAN.

  • What happens if Root Guard is configured on an access switch's uplinks towards the distribution layer?
    Those uplinks are the access switch's root and alternate ports, and the BPDUs they receive carry the real root, so they are superior by design. Root Guard therefore blocks them and the access switch loses its uplinks. Root Guard belongs on the distribution switch's ports facing the access switch, not the other way round.
  • Why doesn't link-loss detection cover the one-way fault that Loop Guard handles?
    A one-way fault can leave the link reported as up at one or both ends, depending on the media and the transceivers, so there may be no link-loss event at all. The only symptom is that BPDUs stop arriving. Loop Guard treats that silence on a root or alternate port as a fault, rather than as a reason to start forwarding.

saying these in an interview costs you the question

  • Root Guard belongs on the uplinks that lead towards the root bridge
  • Loop Guard is meant for host-facing access ports
  • Root Guard shuts the port until an operator re-enables it
  • When BPDUs stop on a blocked port, forwarding is the safe default
  • Root Guard and Loop Guard together on one port double the protection