First, the essential ideas
- Trust boundary
- A port's intended neighbor behavior: a single nonbridging endpoint, an allowed downstream bridge, or a path toward the legitimate root. The correct protection follows that role, not just the label access or trunk.
- BPDU and superior information
- A bridge protocol data unit carries spanning-tree information. A superior BPDU offers a better tree path or root claim; not every BPDU is superior.
- PortFast
- An edge-port feature that permits rapid entry into forwarding for an intended end station. It does not disable spanning tree and is not permission to connect arbitrary bridges.
- BPDU Guard
- A protection that error-disables a guarded port when it receives a BPDU. Explicit interface-level enable does not depend on PortFast; the global PortFast default applies through edge-operational behavior.
- Root Guard
- A protection on a designated boundary where a better root path must not appear. Superior information causes root-inconsistent blocking; ordinary inferior BPDUs can still be allowed.
- Loop Guard
- A protection for eligible root or alternate paths that rely on received BPDUs. Loss of expected BPDUs can cause loop-inconsistent blocking instead of an unsafe transition toward designated forwarding.
- Error-disabled versus inconsistent
- Error-disabled is a disabled-port condition requiring cause correction and recovery. Root-inconsistent and loop-inconsistent are spanning-tree protection conditions that can recover automatically when their specific trigger clears.
- BPDU filtering
- Suppression of spanning-tree messages, not a synonym for BPDU Guard. Interface-level filtering can effectively remove STP protection on that port. Global PortFast-default filtering has different receipt and fallback behavior.
Ask three different questions: should this port receive any BPDUs, may it lead toward a better root, and must it continue receiving BPDUs to remain safe? The answer determines the guard. These protections are not interchangeable switches to turn on everywhere.
See the idea
The same cable, two different guard tests
Any BPDU triggers BPDU Guard. Superior root information triggers Root Guard. The correct choice depends on the intended neighbor.
Ordinary baseline
The single access-VLAN cable joins two legitimate switches. SW1 priority 8192 beats SW2 priority 32768.
What this model leaves out: The boundary marker is part of SW1, not a third device. Both SVIs are on the two shown switches. Tests are sequential; the two guards are not combined.
Full visual explanation and references
SW2 sends BPDUs across its only cable to SW1 Gi0/0. A boundary marker belongs to SW1, where separate tests apply BPDU Guard and then Root Guard.
The boundary marker is part of SW1, not a third device. Both SVIs are on the two shown switches. Tests are sequential; the two guards are not combined.
- Ordinary baseline
The single access-VLAN cable joins two legitimate switches. SW1 priority 8192 beats SW2 priority 32768.
www.cisco.com - Wrong edge profile
Temporarily classify SW1 Gi0/0 as an edge with explicit BPDU Guard. SW2's ordinary BPDU should error-disable the port.
www.cisco.com - Correct bridge boundary
Remove the false edge profile and use Root Guard. Only SW2's temporary superior priority 4096 should create root inconsistency.
www.cisco.com
One idea at a time
Start with something familiar.
Write the intended neighbor role before writing a command. A workstation without bridging, an authorized downstream switch and an uplink toward the root have different expectations.
Why learn this?
An overbroad guard can shut a legitimate uplink; removing a working guard can allow an unauthorized topology change. Diagnose the violated assumption before changing the protection.
An everyday comparison
Different doors can admit staff, accept deliveries or serve as emergency exits. The rule depends on the doorway's purpose, not merely its physical size.
What happens in a network
A port's intended role determines which messages are normal. BPDU Guard rejects bridge participation, while Root Guard allows participation within a root-placement boundary.
Where the comparison stopsSwitches evaluate protocol information rather than human identities. These guards are not user authentication, encryption or a complete security perimeter.
Follow one worked example
- Classify the intended neighbor.
A nonbridging endpoint should not send BPDUs; an authorized downstream switch should.
Why: The presence of a BPDU has different meaning at different boundaries.
- Match the actual trigger.
Any received BPDU, superior information and missing expected BPDUs identify three different conditions.
Why: One generic blocked-port diagnosis hides the cause and the correct recovery.
- Remove the cause and verify recovery.
Restore the legitimate role or peer behavior, then check port state, root identity and the original traffic test.
Why: A command that reopens a port can simply retrigger the same unresolved violation.
Your first small task
For a single workstation, an authorized downstream switch that must never lead to the root, and a root-facing link that must keep receiving BPDUs, choose PortFast/BPDU Guard, Root Guard or Loop Guard. Explain why the other guards are not substitutes.
Show a hint
Ask whether the problem is any BPDU, a better BPDU or a missing BPDU.
Check the expected result
The workstation uses edge treatment with BPDU Guard; the downstream boundary uses Root Guard; the eligible root-facing path can use Loop Guard.
Pause and explain it in your own words
Does enabling every protection on one uplink provide maximum safety?
Show a hint
Consider whether root and loop protection expect the same port role.
Show the explanation
No. Root Guard and Loop Guard are mutually exclusive on the same interface and protect different assumptions. BPDU Guard on an ordinary switch uplink can disable the expected connection as soon as a BPDU arrives.
Short answer
What should you understand today?
Choose spanning-tree protection from expected neighbor behavior. PortFast suits a nonbridging endpoint; BPDU Guard reacts to a received BPDU. Root Guard permits a downstream bridge but rejects a superior root path. Loop Guard protects a path that unexpectedly stops receiving needed BPDUs. Their triggers and recovery differ. BPDU filtering suppresses protocol messages and can create loops; it is not a safer spelling of BPDU Guard.
Before you begin
Learning targets
- Understand root, designated and alternate roles from Day 23.
- Use two fresh IOSvL2 nodes under an existing CML 2.10 entitlement.
- Know that PortFast is intended for nonbridging endpoints, not ordinary switch uplinks.
- Explain the distinct trigger and recovery of each guard.
- Configure explicit interface-level PortFast and BPDU Guard in a bounded violation experiment.
- Configure Root Guard on a designated downstream boundary and test superior information.
- Interpret Loop Guard and BPDU filtering without claiming an unperformed failure simulation.
- Restore the legitimate neighbor policy and verify both state and traffic.
Words you will meet
Open a word when you need its meaning. You do not need to memorize the whole list before reading.
Trust boundary
A port's intended neighbor behavior: a single nonbridging endpoint, an allowed downstream bridge, or a path toward the legitimate root. The correct protection follows that role, not just the label access or trunk.
BPDU and superior information
A bridge protocol data unit carries spanning-tree information. A superior BPDU offers a better tree path or root claim; not every BPDU is superior.
PortFast
An edge-port feature that permits rapid entry into forwarding for an intended end station. It does not disable spanning tree and is not permission to connect arbitrary bridges.
BPDU Guard
A protection that error-disables a guarded port when it receives a BPDU. Explicit interface-level enable does not depend on PortFast; the global PortFast default applies through edge-operational behavior.
Root Guard
A protection on a designated boundary where a better root path must not appear. Superior information causes root-inconsistent blocking; ordinary inferior BPDUs can still be allowed.
Loop Guard
A protection for eligible root or alternate paths that rely on received BPDUs. Loss of expected BPDUs can cause loop-inconsistent blocking instead of an unsafe transition toward designated forwarding.
Error-disabled versus inconsistent
Error-disabled is a disabled-port condition requiring cause correction and recovery. Root-inconsistent and loop-inconsistent are spanning-tree protection conditions that can recover automatically when their specific trigger clears.
BPDU filtering
Suppression of spanning-tree messages, not a synonym for BPDU Guard. Interface-level filtering can effectively remove STP protection on that port. Global PortFast-default filtering has different receipt and fallback behavior.
PortFast changes entry behavior, not the neighbor contract
Use PortFast for an intended end station that is not bridging another network. It accelerates entry into forwarding but does not remove STP. A received BPDU can remove edge-operational status. A laptop running a bridge or a downstream switch does not fit the simple endpoint assumption merely because it connects to an access VLAN.
- An access port can connect to a switch, so access mode alone does not justify PortFast.
- The lab's SVIs are test endpoints; no imaginary workstation is added to the diagram.
BPDU Guard reacts to participation, not superiority
An interface explicitly configured with spanning-tree bpduguard enable can error-disable on a received BPDU whether or not PortFast is active. Global default configuration has a PortFast-operational scope. Correct the cause before manual shutdown/no shutdown recovery; automatic timers are policy choices, not a cure for a still-connected offender.
- Do not lower the peer's priority merely to make BPDU Guard work.
- An empty log buffer does not prove a guard was never triggered.
Root Guard allows a bridge but constrains root placement
Root Guard belongs on a designated boundary that must not become a path to the root. Inferior downstream information can coexist with normal forwarding. Superior information can place the affected VLAN in root-inconsistent state. When superior advertisements cease, normal STP recovery is automatic; this is different from manual error-disable recovery.
- Do not place Root Guard on an uplink that is supposed to lead toward the legitimate root.
- A downstream priority rollback restores the intended policy instead of bypassing protection.
Loop Guard watches for information that disappears
An eligible root or alternate port relies on received BPDUs. If they stop while conditions might otherwise allow an unsafe transition, Loop Guard can hold the VLAN in loop-inconsistent state. Normal BPDU reception permits automatic recovery. A physical shutdown is not the same failure as losing BPDUs on an otherwise active path.
- Root Guard and Loop Guard must not be combined on the same interface.
- Loop Guard does not replace every physical unidirectional-link detection function.
Filtering and guarding have different consequences
BPDU filtering suppresses messages instead of reacting with a protective guard state. Explicit interface filtering can effectively disable STP on that link and make a loop possible. The global PortFast-default form behaves differently: initial messages and received BPDUs can cause fallback from filtering/edge operation. Scope and platform matter.
- BPDU Guard is not a filter that silently drops control packets.
- The lab never disables STP or creates a second physical path to provoke a storm.
Recovery restores the intended boundary
Read running interface configuration, current role/state, inconsistent-port output and actual logs together. Identify whether an edge profile was applied to a legitimate bridge or an unexpected bridge appeared at a true edge. The authorized response differs. Do not automatically remove a guard whenever it blocks traffic.
- Retest the exact original peer destination after each correction.
- No independent runtime, measured recovery delay or production suitability is asserted.
Real-world walkthrough
A small switch appears behind a desk
A hypothetical desk port is error-disabled after someone adds a switch. The support request asks only to reopen the port. The port was intentionally a guarded endpoint boundary, so reopening it without investigating the new neighbor would ignore the reason for the protection.
- Read the exact interface status and retained message rather than assuming a cable fault.
- Verify the intended endpoint-only policy and physically or administratively identify the new bridge.
- Remove the unauthorized bridge according to local policy before recovering the port.
- Retain the edge protection and perform the authorized manual recovery.
- Repeat the workstation's original connectivity test and verify the port does not immediately retrigger.
Guided GNS3 lab
Two guard triggers on one isolated cable
Establish an ordinary switching baseline, demonstrate a deliberately wrong edge profile, restore a legitimate bridge boundary, and test Root Guard with a reversible priority change. No runtime execution is claimed.
Addressing plan
| Device | Interface | Address | Purpose |
|---|---|---|---|
| SW1 | Vlan10 | 192.0.2.1/24 | Protected-switch test endpoint |
| SW2 | Vlan10 | 192.0.2.2/24 | Legitimate peer and BPDU source |
Set up the lab
- Use an existing CML entitlement and exactly one cable between these fresh nodes. Never connect this experiment to a production or external network.
- On each node open Console, enter enable, show version and show running-config. Record build and confirm no automatic errdisable recovery, prior guard/filter configuration or extra links.
- Preserve a starting copy. Stop if the image rejects the documented guard syntax; a paper comparison remains useful but cannot establish a successful guard event.
- The intentional edge misclassification is a negative test only. No actual endpoint PortFast startup timing or missing-BPDU Loop Guard failure is tested.
Prepare SW1 ordinary switch link
In CML, select SW1, open its Console tab and connect before typing. Start with a normal inter-switch access link, not an edge port. There is exactly one cable and no alternate physical path in this experiment.
enable
configure terminal
spanning-tree mode rapid-pvst
vlan 10
exit
spanning-tree vlan 10 priority 8192
interface GigabitEthernet0/0
switchport mode access
switchport access vlan 10
no shutdown
endWhat each command means
enable- Enter privileged EXEC on the named lab node; stop if authorization is unavailable.
configure terminal- Enter global configuration mode from privileged EXEC; changes apply as accepted.
spanning-tree mode rapid-pvst- Use a consistent rapid per-VLAN mode.
vlan 10- Create the test VLAN.
exit- Return to global configuration.
spanning-tree vlan 10 priority 8192- Set a known bridge priority for predictable root comparison.
interface GigabitEthernet0/0- Select this node's only connected physical interface.
switchport mode access- Use a single-VLAN inter-switch link.
switchport access vlan 10- Place the cable in VLAN 10.
no shutdown- Enable the ordinary link.
end- Return to privileged EXEC without saving or reversing the configuration.
- What you should see
- The pair can exchange normal spanning-tree information.
- Why this step matters
- Starting with an ordinary working switch link makes the later intentional role-policy violation explicit.
Prepare SW2 ordinary switch link
In CML, select SW2, open its Console tab and connect before typing. Start with a normal inter-switch access link, not an edge port. There is exactly one cable and no alternate physical path in this experiment.
enable
configure terminal
spanning-tree mode rapid-pvst
vlan 10
exit
spanning-tree vlan 10 priority 32768
interface GigabitEthernet0/0
switchport mode access
switchport access vlan 10
no shutdown
endWhat each command means
enable- Enter privileged EXEC on the named lab node; stop if authorization is unavailable.
configure terminal- Enter global configuration mode from privileged EXEC; changes apply as accepted.
spanning-tree mode rapid-pvst- Use a consistent rapid per-VLAN mode.
vlan 10- Create the test VLAN.
exit- Return to global configuration.
spanning-tree vlan 10 priority 32768- Set a known bridge priority for predictable root comparison.
interface GigabitEthernet0/0- Select this node's only connected physical interface.
switchport mode access- Use a single-VLAN inter-switch link.
switchport access vlan 10- Place the cable in VLAN 10.
no shutdown- Enable the ordinary link.
end- Return to privileged EXEC without saving or reversing the configuration.
- What you should see
- The pair can exchange normal spanning-tree information.
- Why this step matters
- Starting with an ordinary working switch link makes the later intentional role-policy violation explicit.
Address SW1 local SVI
In CML, select SW1, open its Console tab and connect before typing. Use this switch's SVI as the sole local IP test endpoint. No hidden host, default gateway, route or Internet connection is needed.
configure terminal
interface Vlan10
ip address 192.0.2.1 255.255.255.0
no shutdown
endWhat each command means
configure terminal- Enter global configuration mode from privileged EXEC; changes apply as accepted.
interface Vlan10- Select the VLAN 10 IP attachment.
ip address 192.0.2.1 255.255.255.0- Assign the unique same-subnet test address.
no shutdown- Enable the SVI subject to active VLAN membership.
end- Return to privileged EXEC without saving or reversing the configuration.
- What you should see
- The two SVIs can communicate when the only VLAN link forwards.
- Why this step matters
- If the guarded cable stops forwarding, its SVI can also lose line protocol; that follows the same isolated failure.
Address SW2 local SVI
In CML, select SW2, open its Console tab and connect before typing. Use this switch's SVI as the sole local IP test endpoint. No hidden host, default gateway, route or Internet connection is needed.
configure terminal
interface Vlan10
ip address 192.0.2.2 255.255.255.0
no shutdown
endWhat each command means
configure terminal- Enter global configuration mode from privileged EXEC; changes apply as accepted.
interface Vlan10- Select the VLAN 10 IP attachment.
ip address 192.0.2.2 255.255.255.0- Assign the unique same-subnet test address.
no shutdown- Enable the SVI subject to active VLAN membership.
end- Return to privileged EXEC without saving or reversing the configuration.
- What you should see
- The two SVIs can communicate when the only VLAN link forwards.
- Why this step matters
- If the guarded cable stops forwarding, its SVI can also lose line protocol; that follows the same isolated failure.
Record the ordinary-link baseline
In CML, select SW1, open its Console tab and connect before typing. Both peers are normal switches at this point. Require a working SVI ping and an expected SW1 root before changing the role policy.
show spanning-tree vlan 10
show interfaces status
ping 192.0.2.2
show loggingWhat each command means
show spanning-tree vlan 10- Confirm SW1 is root and Gi0/0 is designated/forwarding.
show interfaces status- Record the connected, non-error-disabled physical port.
ping 192.0.2.2- Establish the original peer test.
show logging- Preserve any baseline retained messages.
- What you should see
- Expect ordinary bridge participation and successful peer replies.
- Why this step matters
- This distinguishes a later deliberate policy failure from an initially broken VLAN path.
Silence the peer before the edge test
In CML, select SW2, open its Console tab and connect before typing. Shut only the known peer port so the temporary edge profile is installed before the next BPDU. This is a local administrative test, not BPDU filtering.
configure terminal
interface GigabitEthernet0/0
shutdown
endWhat each command means
configure terminal- Enter global configuration mode from privileged EXEC; changes apply as accepted.
interface GigabitEthernet0/0- Select the single cable to SW1.
shutdown- Temporarily stop this peer link.
end- Return to privileged EXEC without saving or reversing the configuration.
- What you should see
- The only physical peer link becomes administratively down.
- Why this step matters
- A bounded shutdown avoids inventing a selective control-plane failure.
Install the deliberately wrong edge profile
In CML, select SW1, open its Console tab and connect before typing. This port really faces a switch. The following profile is intentionally invalid solely to demonstrate protection on the isolated, loop-free pair.
configure terminal
interface GigabitEthernet0/0
spanning-tree portfast
spanning-tree bpduguard enable
endWhat each command means
configure terminal- Enter global configuration mode from privileged EXEC; changes apply as accepted.
interface GigabitEthernet0/0- Select the disabled-by-peer link being tested.
spanning-tree portfast- Temporarily classify this port as an edge.
spanning-tree bpduguard enable- Explicitly guard against any received BPDU.
end- Return to privileged EXEC without saving or reversing the configuration.
- What you should see
- The interface has an explicit guard awaiting a BPDU.
- Why this step matters
- The exercise tests detection of wrong neighbor behavior, not a recommended switch-uplink policy.
Send ordinary peer BPDUs again
In CML, select SW2, open its Console tab and connect before typing. Restore the peer with its original, inferior priority. Do not change root priority during the BPDU Guard experiment.
configure terminal
interface GigabitEthernet0/0
no shutdown
endWhat each command means
configure terminal- Enter global configuration mode from privileged EXEC; changes apply as accepted.
interface GigabitEthernet0/0- Select the same temporarily disabled cable.
no shutdown- Restore ordinary bridge participation.
end- Return to privileged EXEC without saving or reversing the configuration.
- What you should see
- SW2 can again send BPDUs toward the guarded SW1 port.
- Why this step matters
- Even inferior BPDUs should trigger an explicitly enabled BPDU Guard.
Observe the guard violation
In CML, select SW1, open its Console tab and connect before typing. Inspect the protected switch after peer messages arrive. Record actual output and do not label a guard event successful unless the state supports it.
show interfaces status err-disabled
show logging
show spanning-tree vlan 10
ping 192.0.2.2What each command means
show interfaces status err-disabled- Look for the protected physical port in error-disabled state.
show logging- Read any actual BPDU-related diagnostic messages.
show spanning-tree vlan 10- Observe the loss of normal forwarding participation.
ping 192.0.2.2- Confirm that the original sole-link traffic path is unavailable.
- What you should see
- Expect a BPDU Guard event and lost peer reachability.
- Why this step matters
- A worse peer priority did not prevent the guard; this is an any-BPDU trigger.
Restore the legitimate bridge boundary
In CML, select SW1, open its Console tab and connect before typing. SW2 is an authorized switch in this lab. Correct the intentionally wrong edge profile while the port is held down, retain STP, and use Root Guard for the intended downstream boundary.
configure terminal
interface GigabitEthernet0/0
shutdown
no spanning-tree bpduguard enable
no spanning-tree portfast
spanning-tree guard root
no shutdown
end
show spanning-tree inconsistentports
show spanning-tree vlan 10
ping 192.0.2.2What each command means
configure terminal- Enter global configuration mode from privileged EXEC; changes apply as accepted.
interface GigabitEthernet0/0- Select only the test interface.
shutdown- Hold the port down during the role-policy correction.
no spanning-tree bpduguard enable- Remove the temporary explicit any-BPDU guard.
no spanning-tree portfast- Remove the false endpoint classification.
spanning-tree guard root- Protect the boundary against a superior root path.
no shutdown- Recover the physical port under the corrected policy.
end- Return to privileged EXEC without saving or reversing the configuration.
show spanning-tree inconsistentports- Verify no root inconsistency at the original peer priority.
show spanning-tree vlan 10- Confirm SW1 remains root and the link forwards.
ping 192.0.2.2- Require the original peer test to succeed again.
- What you should see
- Expect a normal forwarding baseline with Root Guard configured.
- Why this step matters
- The test changes to a legitimate bridge policy; real endpoint-only incidents should keep their edge guard instead.
Introduce superior root information
In CML, select SW2, open its Console tab and connect before typing. Proceed only after the corrected Root Guard baseline works. Change the peer priority alone, leaving cabling, VLANs and all guards unchanged.
configure terminal
spanning-tree vlan 10 priority 4096
endWhat each command means
configure terminal- Enter global configuration mode from privileged EXEC; changes apply as accepted.
spanning-tree vlan 10 priority 4096- Temporarily offer a better bridge ID than SW1's 8192.
end- Return to privileged EXEC without saving or reversing the configuration.
- What you should see
- The peer now advertises superior information toward the protected boundary.
- Why this step matters
- This tests Root Guard's specific trigger separately from any-BPDU guarding.
Read root inconsistency
In CML, select SW1, open its Console tab and connect before typing. Inspect the protected boundary without disabling Root Guard. An affected SVI may also lose line protocol because this is its sole active physical link.
show spanning-tree inconsistentports
show spanning-tree vlan 10
show logging
ping 192.0.2.2What each command means
show spanning-tree inconsistentports- Identify VLAN 10's root-inconsistent condition if triggered.
show spanning-tree vlan 10- Read the actual protected tree state.
show logging- Preserve real root-guard messages if retained.
ping 192.0.2.2- Retest the original destination during the blocking condition.
- What you should see
- Expect root-inconsistent blocking and loss of the sole data path.
- Why this step matters
- The intended root region is protected even though normal downstream service is temporarily blocked.
Withdraw the superior root claim
In CML, select SW2, open its Console tab and connect before typing. Restore the exact original base priority. Do not cycle SW1's port or remove Root Guard to hide the trigger.
configure terminal
spanning-tree vlan 10 priority 32768
end
show spanning-tree vlan 10What each command means
configure terminal- Enter global configuration mode from privileged EXEC; changes apply as accepted.
spanning-tree vlan 10 priority 32768- Return the peer to its recorded initial priority.
end- Return to privileged EXEC without saving or reversing the configuration.
show spanning-tree vlan 10- Observe convergence back toward the intended SW1 root.
- What you should see
- The superior advertisement ceases; Root Guard can recover automatically.
- Why this step matters
- Rollback corrects the offending information rather than weakening the boundary.
Verify automatic recovery
In CML, select SW1, open its Console tab and connect before typing. Wait for actual stable state and repeat the same checks. Preserve the Root Guard configuration for the legitimate downstream-switch design.
show spanning-tree inconsistentports
show spanning-tree vlan 10
show running-config interface GigabitEthernet0/0
ping 192.0.2.2
show loggingWhat each command means
show spanning-tree inconsistentports- Require the root-inconsistent entry to clear.
show spanning-tree vlan 10- Verify SW1 root identity and designated forwarding.
show running-config interface GigabitEthernet0/0- Confirm Root Guard remains and the temporary edge profile is absent.
ping 192.0.2.2- Repeat the original successful peer test.
show logging- Record actual recovery evidence if the buffer contains it.
- What you should see
- Expect normal forwarding and reachability without manually reopening the Root Guard port.
- Why this step matters
- Automatic inconsistency recovery differs from the earlier manual error-disable/profile correction.
Verify
- Require a successful ordinary-link baseline before the first guard test.
- Separate actual error-disabled state from root-inconsistent state.
- Confirm BPDU Guard triggers without lowering SW2's original priority.
- Establish a new successful Root Guard baseline before the priority fault.
- Restore SW2 priority 32768 and verify inconsistency clears with the guard retained.
- Label Loop Guard failure and filtering comparisons as conceptual, not performed tests.
Troubleshoot
- If BPDU Guard does not trigger, inspect explicit interface configuration and verify the peer actually participates in VLAN 10 STP; do not fabricate a BPDU receipt.
- If the port repeatedly error-disables, correct the peer role before another recovery attempt.
- If Root Guard blocks at baseline, compare actual bridge IDs and confirm the intended root is on the permitted side.
- If the peer remains unreachable after priorities recover, inspect SVI line protocol, VLAN membership and actual port state.
- If a command is unsupported, preserve the error and stop that branch; do not substitute filtering or a loop as a workaround.
Use an existing Cisco Modeling Labs 2.10 entitlement and its bundled reference images inside CML only. GNS3 does not provide Cisco images; use images there only when a separate applicable license permits that environment. Do not share or redistribute image files. A CML subscription alone does not authorize exporting its Cisco images to GNS3. Without entitlement, use the explicitly labeled paper exercises; they do not establish hands-on competence.
- Leave SW2 at priority 32768, SW1 at 8192 and both physical ports enabled with the legitimate Root Guard boundary restored.
- Do not enable automatic errdisable recovery or BPDU filtering merely to suppress evidence; retain private observations and stop the isolated lab.
Practice set
Answer before you reveal
01Does PortFast disable STP?
A port can lose operational edge status on BPDU receipt, and the intended endpoint role still matters.
02Must a BPDU be superior to trigger explicit BPDU Guard?
The lab intentionally keeps the peer's worse priority during the first test to separate this trigger from Root Guard.
03What clears root-inconsistent state?
Restoring the peer's legitimate priority removes the trigger while leaving Root Guard in place.
04What failure does Loop Guard address?
It prevents an unsafe transition based merely on missing information, and is not equivalent to physical-link shutdown.
05Can Root Guard and Loop Guard protect the same interface together?
Choose according to whether the boundary must remain designated or must continue hearing a valid upstream path.
06Why not replace BPDU Guard with filtering?
Global-default and explicit interface filtering also behave differently, so neither is a generic guard substitute.
Knowledge check
Quiz: prove the reasoning
Keep these
Technical takeaways
- Choose protection from the intended neighbor and root boundary.
- PortFast is edge behavior, not a replacement for spanning tree.
- BPDU Guard and Root Guard react to different information.
- Error-disabled and inconsistent states have different recovery paths.
- Loop Guard depends on expected BPDU reception.
- BPDU filtering is not BPDU Guard and can create loop risk.