Spanning Tree Protocol Scenarios

Change the port type of Gi0/3 to trunk to allow multiple VLANs.

Why wrong: Configuring Gi0/3 as a trunk only affects VLAN tagging and the set of VLANs carried, not the STP port role. The blocking state indicates an STP decision—likely that the current root bridge has a higher bridge priority than another switch for VLAN 10—so the port cannot forward even after trunk mode is set. Trunking would be relevant if VLANs were being pruned, but it cannot change the root bridge election or port cost calculations.

Configure spanning-tree portfast on Gi0/3 to speed up convergence.

Why wrong: Portfast is intended solely for access ports connected to end stations, allowing them to bypass the listening and learning states to converge quickly. Applying it to an inter-switch uplink like Gi0/3 is dangerous because it could create a temporary bridging loop during STP recalculation. Even if Portfast were enabled, the port would still block after the switch receives the superior BPDU that elected another switch as root; it only skips the forward-delay timers, not the STP decision itself.

Enable BPDU guard on Gi0/3 to prevent unauthorized switches from affecting the network.

Why wrong: BPDU guard is an STP protection feature typically enabled on PortFast-configured access ports; when it receives a BPDU, it disables the port to prevent rogue switches. On an uplink connecting two switches, BPDUs are expected and necessary for STP operation, so enabling BPDU guard would shut down Gi0/3 and disrupt the link entirely. It does nothing to influence root bridge selection or why Gi0/3 is in a blocking state, since that state is determined by root bridge priorities and path costs.

The root bridge election failed, causing a loop.

Why wrong: The root bridge did not fail; SwitchC is the correctly elected root for VLAN 10 based on the lowest bridge priority and MAC address. A failed root election would cause all switches to claim root status and generate BPDU storms, not a single port being placed into err-disabled state. The actual cause is BPDU Guard, which administratively disables the port upon receiving an unexpected BPDU.

Rapid PVST+ is not compatible with PortFast.

Why wrong: Rapid PVST+ fully supports PortFast as a per-port enhancement. PortFast bypasses the listening and learning states but does not disable spanning-tree operation; it is designed for access ports that connect end hosts. Therefore, claiming that Rapid PVST+ and PortFast are incompatible is incorrect; they are commonly used together in enterprise campus networks.

The port is configured as a trunk but should be an access port.

Why wrong: The interface is configured as an access port using 'switchport mode access', so the premise of this option is false. BPDU Guard is independent of trunk or access mode; it is tied to PortFast, and it will shut down the port regardless of the port mode if a BPDU is received. Therefore, the problem is not a misconfigured trunk but the intentional BPDU Guard protection triggered by an unexpected BPDU.

Root Guard and UDLD

Why wrong: Root Guard is a spanning-tree feature that prevents a designated port from becoming a root port by placing the port in root-inconsistent state if it receives a superior BPDU, and it is used on ports that should never become the root bridge, not on edge ports. UDLD (Unidirectional Link Detection) detects and disables unidirectional fiber or copper links, but it does not affect the port's forwarding state during STP convergence. Neither feature speeds up initial forwarding for an end host nor protects against rogue BPDUs, so it does not meet the access-port requirement.

Loop Guard and native VLAN

Why wrong: Loop Guard prevents alternate or root ports from becoming designated when BPDUs stop being received on a redundant link, which protects against loops caused by unidirectional link failures, but it is not intended for edge ports and does not accelerate forwarding. The native VLAN is a VLAN assignment for frames on a trunk link that lack an 802.1Q tag, so it is irrelevant to an access port connected to a single end host. This combination neither enables fast transition nor provides BPDU filtering, making it an incorrect choice for an edge-port configuration.

Port security and EtherChannel

Why wrong: Port security restricts the number of MAC addresses allowed on a port and can take action if a violation occurs, but it does not bypass the STP listening and learning states or alter how the port receives BPDUs. EtherChannel is a link aggregation technology that bundles multiple physical links into one logical link, which has nothing to do with STP edge-port behavior or protecting the spanning-tree domain. These features address different concerns, so they are not the correct set for a layer 2 switch port connected to an end host.

Configure spanning-tree vlan 10,20 root primary and spanning-tree portfast on Gi0/1; then use 'errdisable recovery cause bpduguard' to automatically recover the port.

Why wrong: The 'root primary' command sets priority to 24576, which may not be low enough if another switch has a lower priority. Also, automatic recovery via 'errdisable recovery' is not the recommended manual recovery method described in the question; the question asks to recover without reloading, but automatic recovery is an alternative, not the direct action.

Configure spanning-tree vlan 10,20 priority 0 and spanning-tree bpduguard enable on Gi0/1; then use 'no spanning-tree bpduguard' to recover the port.

Why wrong: Setting priority to 0 is valid but extreme and may cause issues if other switches also use 0. More importantly, disabling BPDU Guard does not recover the port; the port remains err-disabled until you issue 'shutdown' and 'no shutdown'.

Configure spanning-tree vlan 10,20 priority 4096 and spanning-tree portfast on Gi0/1; then use 'clear spanning-tree detected-protocols' to recover the port.

Why wrong: While the spanning-tree configuration is correct, the recovery command is wrong. 'clear spanning-tree detected-protocols' is used to re-run the spanning-tree algorithm, not to recover an err-disabled port. The correct recovery is 'shutdown' and 'no shutdown'.

G0/1 is in forwarding state (Root Guard), G0/2 is in blocking state (Loop Guard), G0/3 is in err-disable state (BPDU Guard).

Why wrong: This is incorrect because Root Guard does not allow the port to forward when a superior BPDU is received; it blocks the port. Loop Guard does not block the port immediately; it only blocks if BPDUs stop being received. Here, BPDUs are still being received, so G0/2 should be forwarding.

G0/1 is in err-disable state (Root Guard), G0/2 is in forwarding state (Loop Guard), G0/3 is in blocking state (BPDU Guard).

Why wrong: This is incorrect because Root Guard does not place the port in err-disable; it blocks the port while the superior BPDU is received, and the port recovers automatically when the superior BPDU stops. BPDU Guard places the port in err-disable, not blocking state.

G0/1 is in blocking state (Root Guard), G0/2 is in loop-inconsistent state (Loop Guard), G0/3 is in err-disable state (BPDU Guard).

Why wrong: This is incorrect because Loop Guard only transitions to loop-inconsistent blocking state when BPDUs are no longer received. In this scenario, BPDUs are still being received on G0/2, so it remains in forwarding state. The question does not indicate a unidirectional link failure.

1. Configure BPDU Guard on PortFast ports. 2. Configure Loop Guard on non-designated ports. 3. Configure Root Guard on designated ports. 4. To recover a port that enters err-disabled due to BPDU Guard violation, re-enable BPDU Guard on the port.

Why wrong: This is incorrect because BPDU Guard should be applied after PortFast is enabled, but the order of applying protections is not arbitrary; Root Guard and Loop Guard have specific port roles. Also, re-enabling BPDU Guard does not recover an err-disabled port; the port must be manually reset or errdisable recovery must be configured.

1. Configure Loop Guard on non-designated ports. 2. Configure Root Guard on designated ports. 3. Configure BPDU Guard on PortFast ports. 4. To recover a port that enters err-disabled due to BPDU Guard violation, configure errdisable recovery cause bpduguard.

Why wrong: This is incorrect because while errdisable recovery can automatically recover the port, the question asks for the steps to recover a port that enters err-disabled due to BPDU Guard violation. The standard recovery method is manual reset, not automatic recovery. Additionally, the order of Root Guard and Loop Guard is swapped; Root Guard should be configured before Loop Guard? Actually, the order of these two does not matter as long as they are applied to correct port roles. However, the recovery method is not the most direct answer.

1. Configure Root Guard on designated ports. 2. Configure BPDU Guard on PortFast ports. 3. Configure Loop Guard on non-designated ports. 4. To recover a port that enters err-disabled due to BPDU Guard violation, remove BPDU Guard from the port.

Why wrong: This sequence correctly places Root Guard on designated ports and Loop Guard on non-designated ports, but the recovery step is fundamentally flawed. Removing BPDU Guard from the interface does NOT clear the err-disabled state; the port remains administratively down until you issue a manual shutdown followed by no shutdown, or until global errdisable recovery (if configured) automatically re-enables it. Additionally, merely deleting the BPDU Guard configuration does not alter the fact that the port was error-disabled by the STP watchdog, and the port will not pass traffic until that state is manually cleared.

interface g0/3 spanning-tree portfast spanning-tree bpduguard enable no shutdown

Why wrong: This is incorrect because after enabling BPDU Guard, the port is already in err-disabled state and will not recover without a manual shutdown/no shutdown cycle. Simply issuing 'no shutdown' without first shutting down the interface will not clear the err-disabled state.

interface g0/3 spanning-tree portfast spanning-tree bpduguard enable end copy running-config startup-config

Why wrong: The command sequence enables PortFast and BPDU Guard, but then exits to privileged exec and saves the running configuration. This does not address the immediate operational issue: the port is currently in err-disabled state because BPDU Guard detected a BPDU. Saving the configuration only persists the intended PortFast/BPDU Guard settings; it does not clear the error condition. To recover, the port must be manually cycled with shutdown followed by no shutdown, or the interface must be brought out of err-disabled via other means (e.g., errdisable recovery). Therefore, this sequence leaves the port offline.

interface g0/3 spanning-tree portfast spanning-tree bpduguard enable shutdown

Why wrong: After enabling BPDU Guard, issuing only shutdown places the port administratively down. While shutdown does clear the err-disabled state (as part of the manual recovery process), the port remains down because no subsequent no shutdown is issued. The standard recovery sequence requires both shutdown and no shutdown to transition from err-disabled to up/up. Hence, this incomplete sequence fails to restore connectivity.

Root Guard on Gi0/1, Loop Guard on Gi0/2, BPDU Guard on Gi0/0

Why wrong: This is incorrect because Root Guard should be applied on the designated port facing SW2 (Gi0/2), not on the uplink to the core (Gi0/1). Loop Guard should be on the uplink, not on the designated port.

Root Guard on Gi0/0, Loop Guard on Gi0/1, BPDU Guard on Gi0/2

Why wrong: This is incorrect because Root Guard should not be on an access port (Gi0/0) as it is PortFast-enabled and not expected to receive BPDUs; BPDU Guard is more appropriate there. BPDU Guard on Gi0/2 would err-disable the designated port upon receiving a superior BPDU, which is not the intended behavior.

Root Guard on Gi0/2, Loop Guard on Gi0/0, BPDU Guard on Gi0/1

Why wrong: This answer correctly places Root Guard on the designated port Gi0/2, but it misassigns the two remaining protections. Loop Guard is intended for root or alternate blocking ports, where a unidirectional link could cause a stale blocking state; an access port like Gi0/0 is not a blocking port and is better protected by BPDU Guard because it is PortFast-enabled. Placing BPDU Guard on the uplink Gi0/1 would improperly err-disable a legitimate switch-to-switch link if a normal BPDU is received, defeating its purpose of protecting end-user access ports.

Learning

Why wrong: During the learning state, the switch does begin populating its MAC address table by examining the source addresses of frames received on the port, even though it still does not forward those frames out any port. This state lasts for the forward-delay timer (15 seconds) and serves to avoid temporary loops while the port prepares to enter the forwarding state. It does not listen for BPDUs as its primary function; that happens in the listening state.

Forwarding

Why wrong: In the forwarding state, a port actively sends and receives normal user traffic, including its own BPDUs, and it is the final operating state for all root and designated ports. While a port in forwarding state continues to receive BPDUs from neighboring switches, it is no longer in the formal 'listening' phase because the switch has already converged on the active topology. Forwarding is not the state where a port listens for BPDUs to make STP decisions; that listening function is confined to the earlier listening state.

Disabled

Why wrong: A disabled port on a classic 802.1D switch is administratively shut down or has failed a hardware or link test, so it is completely excluded from the spanning-tree process. Because the port is not active, it neither sends nor receives BPDUs, does not learn MAC addresses, and does not forward any frames. The disabled state is not a normal STP transition state but rather an administrative or fault condition.

Root Guard automatically shuts down the port when a superior BPDU is received, similar to BPDU Guard.

Why wrong: The claim that Root Guard shuts down the port like BPDU Guard is incorrect. BPDU Guard moves the port to errdisable state, but Root Guard never errdisables the interface; it places the port in a root-inconsistent (blocking) state only as long as the superior BPDU is received. When the superior BPDU disappears, the port immediately resumes forwarding, so no manual recovery or administrative shutdown is involved.

Loop Guard, when enabled, disables a port if BPDUs are no longer received on it, preventing a unidirectional link failure.

Why wrong: This option misstates Loop Guard's behavior and purpose. Loop Guard does not disable (errdisable) a port; rather, when a root or alternate port stops receiving BPDUs — typically because of a unidirectional link failure — it transitions that port to a loop-inconsistent state, which is a blocking state that still allows BPDUs to be sent. Moreover, Loop Guard does not prevent the physical link failure itself; it only prevents the bridging loop that would occur if the switch incorrectly made that port designated and started forwarding.

BPDU Guard places the port in a blocking state (loop-inconsistent) when a BPDU is received, similar to Loop Guard.

Why wrong: BPDU Guard does not place the port in an STP blocking or 'loop-inconsistent' state like Loop Guard; it takes much more aggressive action by placing the interface in errdisable state. The loop-inconsistent state is used by Loop Guard when a port stops receiving BPDUs, and it does not involve BPDU reception. This option inverts the two mechanisms and incorrectly claims that BPDU Guard behaves similarly to Loop Guard.

Configure 'spanning-tree vlan 10 root primary' and 'spanning-tree vlan 20 root secondary' on MLS1. Verify with 'show spanning-tree vlan 10' and 'show interfaces gigabitEthernet0/1 status'.

Why wrong: This configuration is incorrect for VLAN 20 because 'spanning-tree vlan 20 root secondary' sets MLS1's bridge priority to 28672, which is the backup-root value, not the primary-root value of 24576 used by 'root primary'. While MLS1 would still outbid a switch at the default priority 32768, the command explicitly designates it as the standby root, contrary to the requirement that MLS1 be the root for both VLANs. Moreover, the verification commands only inspect VLAN 10 via 'show spanning-tree vlan 10' and the interface status, leaving VLAN 20's root election completely unverified.

Configure 'spanning-tree vlan 10 priority 4096' and 'spanning-tree vlan 20 priority 4096' on MLS1. Verify with 'show spanning-tree vlan 10' and 'show interfaces gigabitEthernet0/1 status'.

Why wrong: This is incorrect because setting the priority to 4096 is not the standard method; the 'root primary' command automatically sets the priority to 24576 (or lower if needed). A priority of 4096 is lower than 24576 and would also make the switch root, but the question specifically asks to use the 'root primary' command.

Configure 'spanning-tree vlan 10 root primary' and 'spanning-tree vlan 20 root primary' on MLS1. Then configure 'spanning-tree portfast default' and 'spanning-tree bpduguard default' globally. Verify with 'show spanning-tree vlan 10' and 'show interfaces gigabitEthernet0/1 status'.

Why wrong: This is incorrect because the question states that PortFast and BPDU Guard are already enabled on G0/1. Configuring them globally would apply to all access ports, which is unnecessary and could cause issues on trunk ports. The existing configuration on the interface is sufficient.

The trunk port is using ISL encapsulation, which does not support VLAN 40.

Why wrong: ISL encapsulation supports VLANs 1–1005, so VLAN 40 is within the valid range. Modern Cisco switches default to 802.1Q, and if encapsulation were mismatched the trunk would likely be down. The root cause is not encapsulation.

The technician omitted the 'add' keyword when adding VLAN 40 to the allowed list, so the trunk no longer permits VLAN 40.

Why wrong: When the 'add' keyword is omitted, the allowed list is overwritten and all previously allowed VLANs are removed. In that case, the show interfaces trunk command would not show VLAN 40 in the allowed list at all, contradicting the symptom of it being allowed but not in forwarding state.

VTP pruning is enabled, and VLAN 40 is not needed by any downstream neighbor, so it is pruned from this trunk.

Why wrong: VTP pruning removes VLAN traffic from trunks when no downstream switch has ports in that VLAN, but it requires a VTP domain and is a separate feature. Without any indication of VTP configuration, the most likely reason a single VLAN is missing from the forwarding list after being allowed is that the VLAN itself has not been created.