A switch port has stopped forwarding. Should you look for an unexpected BPDU, a superior BPDU, or a missing BPDU? That distinction is the key to answering BPDU Guard vs BPDU Filter vs Root Guard vs Loop Guard in an interview—and to investigating the right failure on a live network.
Short answer: BPDU Guard disables a protected port when it receives a BPDU; BPDU Filter suppresses BPDU exchange, with important differences between global and interface configuration.[1] Root Guard blocks an unwanted path toward the root, while Loop Guard blocks a dangerous transition when expected BPDUs disappear.[2]
Comparison table: trigger, action and placement
The following summarizes Cisco behavior documented in the platform guides; verify support and syntax for your own switch and software release.[1][2]
| Feature | Trigger or behavior | Result | Typical placement |
|---|---|---|---|
| BPDU Guard | Any received BPDU on a protected port | Error-disabled port | Host-facing edge where a bridge is not allowed |
| BPDU Filter, explicit interface enable | Suppresses sent and received BPDUs | No normal STP protection through BPDU exchange | Exceptional, deliberately engineered boundary—not a general edge-security default |
| BPDU Filter, global PortFast default | Filters on operational PortFast ports; received BPDU removes operational PortFast/filtering behavior | Normal STP processing resumes | Host-facing ports, only where this behavior is specifically intended |
| Root Guard | Superior information would make the protected designated port a root port | Root-inconsistent, blocked | Downstream boundary that must never lead toward the root |
| Loop Guard | Expected BPDUs stop arriving on a relevant non-designated port | Loop-inconsistent, blocked | Eligible point-to-point switch links where root/alternate roles can occur |
Memory aid: Guard rejects unexpected BPDUs; Filter hides BPDUs; Root Guard rejects an unwanted root direction; Loop Guard reacts to missing BPDUs. Treat this as a mnemonic, not a substitute for the global-versus-interface distinction.
BPDU Guard: a host port should not receive BPDUs
On the documented Catalyst platform, global BPDU Guard applies to ports in the PortFast-operational state; interface-level BPDU Guard can act even without PortFast.[1]
If an attached device sends a BPDU, the protected interface enters the error-disabled state rather than simply electing a different STP role.[1] The trigger is not limited to a superior BPDU: even a device advertising a worse root can trigger BPDU Guard.[1]
Conceptual flow:
Host-facing port is forwarding
-> an attached device sends a BPDU
-> BPDU Guard detects the violation
-> interface becomes error-disabled
-> investigate the connection before restoring service
Operational recommendation: check the actual endpoint before blaming the feature. An unauthorized switch, a changed cabling arrangement or an intentionally bridging endpoint calls for different remediation. Do not repeatedly restore the interface without correcting the cause.
BPDU Filter: global default is not explicit interface enable
This is the most important configuration trap in the comparison.
Global PortFast-based filtering
On the documented Catalyst platform, spanning-tree portfast bpdufilter default applies to operational PortFast interfaces; those interfaces send a few BPDUs at link-up before filtering begins.[1]
If a BPDU arrives, the interface loses its PortFast-operational status and BPDU filtering is disabled, allowing ordinary STP behavior.[1] This is not the same response as BPDU Guard's error-disable action.[1]
Explicit interface filtering
The interface command spanning-tree bpdufilter enable suppresses sending and receiving BPDUs without requiring PortFast.[1] Cisco warns that interface-level filtering is effectively disabling spanning tree on that interface and can cause loops.[1]
Recommendation: do not use interface filtering as a quick fix for BPDU Guard incidents or STP blocking. The symptom may disappear because you have removed the control-plane information needed to detect the problem.
The behavior above describes filtering itself. When several protection features are combined, verify their interaction on the exact platform instead of assuming every independent behavior will happen in sequence.
Root Guard: protect the intended root direction
Root Guard belongs on a boundary where the local port should remain designated, not on an uplink that legitimately leads to the root.[2] When superior BPDU information would make that port a root port, Root Guard puts it into the root-inconsistent state.[2]
Unlike BPDU Guard, Root Guard does not reject every BPDU: it enforces a topology policy about where the root may be reached.[2]
Illustrative topology—not an executed lab:
Intended root / distribution switch
|
| designated downstream port with Root Guard
|
Downstream switch
If the downstream switch starts advertising a superior root path, the protected port blocks rather than allowing the root direction to move downstream.[2] When that superior information stops and normal STP conditions allow it, recovery is automatic; this is not an error-disabled interface requiring the same recovery workflow as BPDU Guard.[2]
Design check: describe the intended root location for each VLAN or instance before enabling Root Guard. Do not label an interface “downlink” and assume it can never be a valid backup path toward the root.
Loop Guard: silence is not proof that forwarding is safe
In a redundant topology, loss of expected BPDUs can cause a non-designated port to become designated and eventually forward, creating a loop.[2] Loop Guard instead holds the affected STP state in loop-inconsistent blocking when expected BPDUs disappear.[2]
Conceptual flow:
Root or alternate port receives expected BPDUs
-> BPDU reception stops while the link remains up
-> Loop Guard prevents an unsafe transition
-> affected STP state is loop-inconsistent
-> BPDUs return
-> inconsistency clears; STP determines the appropriate state
Recovery is automatic when BPDUs return; clearing the inconsistency does not mean the port must become forwarding, because its STP role still matters.[2]
The Nexus guide limits Loop Guard to appropriate point-to-point normal/network ports, excludes edge ports, and does not permit enabling it with Root Guard on the same interface.[2] These features implement different expectations: Root Guard says this port must not point toward the root; Loop Guard protects roles that depend on continued BPDU reception.[2]
Configuration and verification example
The following is an illustrative Cisco IOS/IOS XE-style host-port configuration, not an executed switch test. It assumes an existing access VLAN and an endpoint that must not bridge into the STP topology. PortFast and interface BPDU Guard syntax follow the Catalyst guide.[1]
configure terminal
interface GigabitEthernet1/0/10
description HOST_EDGE_EXAMPLE
switchport mode access
switchport access vlan 10
spanning-tree portfast
spanning-tree bpduguard enable
end
For a separately reviewed downstream boundary, the interface command is spanning-tree guard root; for an appropriate Loop Guard interface, it is spanning-tree guard loop—these are alternatives, not a pair to paste onto every port.[1][2]
Start troubleshooting with read-only checks; command availability and output vary by release:
show spanning-tree summary
show spanning-tree vlan 10
show spanning-tree interface GigabitEthernet1/0/10 detail
show spanning-tree inconsistentports
show interfaces status err-disabled
show running-config interface GigabitEthernet1/0/10
show logging
Suggested investigation checklist:
- Record whether the interface is error-disabled, root-inconsistent, loop-inconsistent, or simply discarding under normal STP.
- Check the affected VLAN/instance, current root ID and expected port role.
- Inspect both global defaults and interface overrides, especially BPDU filtering.
- Trace the cable and identify the connected device; do not rely only on the interface description.
- For missing BPDUs, investigate both link directions, remote STP operation and possible filtering.
- Correct the cause before removing protection or restoring service; then verify the root and forwarding topology again.
Common interview pitfalls
- “BPDU Guard only reacts to a better root.” No: any received BPDU triggers the protected-port behavior.[1]
- “BPDU Filter is a safer version of BPDU Guard.” No: explicit interface filtering can remove STP's ability to detect a loop through that interface.[1]
- “Root Guard belongs on all uplinks.” No: blocking a legitimate root direction can break the intended topology.[1][2]
- “Loop Guard detects every Ethernet loop.” No: its specific job is protecting against lost expected BPDU information on eligible ports.[2]
- “Every STP protection event shuts the physical interface down.” No: error-disable and STP inconsistency are different outcomes; examine the VLAN/instance as well as interface state.[1][2]
A concise interview answer
“BPDU Guard is for a port where I do not expect BPDUs: receiving one error-disables the protected port.[1] BPDU Filter suppresses BPDUs, but global PortFast-based filtering and explicit interface filtering behave differently, and interface filtering can create loops.[1] Root Guard prevents a downstream port becoming a path toward a superior root; Loop Guard prevents a root or alternate port becoming unsafe when expected BPDUs disappear.[2] I distinguish error-disabled, root-inconsistent and loop-inconsistent states before choosing a recovery action.”
Related reading
Summary
Choose the feature from the port's intended role and the failure you need to prevent—not from the similarity of its name to another feature. For interview practice, draw one host-facing port and one redundant switch path, assign the appropriate protections, and explain the trigger, resulting state and recovery for each.
Sources
- [1] https://cisco.com/c/en/us/td/docs/switches/lan/catalyst3650/software/release/3se/consolidated_guide/configuration_guide/b_consolidated_3650_3se_cg/b_consolidated_3650_3se_cg_chapter_011110.html
- [2] https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/layer2/503_n1_1/b_Cisco_n5k_layer2_config_gd_rel_503_N1_1/b_Cisco_n5k_layer2_config_gd_rel_503_N1_1_chapter_01011.html
Post a Comment