Troubleshooting Scenario Questions

Enable DFS channels to avoid radar interference.

Why wrong: DFS (Dynamic Frequency Selection) channels are specifically intended for radar interference avoidance, not for mitigating co-channel interference between APs. The exhibit shows no radar events; enabling DFS would introduce unnecessary radar-detect downtime and channel unavailability without changing the fact that multiple APs share the same non-DFS channel. The root cause is poor channel planning, not radar coexistence.

Increase the channel width to 160 MHz to improve throughput.

Why wrong: Increasing the channel width to 160 MHz would enlarge the RF footprint and consume most of the available 5 GHz spectrum, but it would not address the existing co-channel contention between APs. In fact, wider channels reduce the number of non-overlapping channels available (often to just one 160 MHz block per regulatory domain), which would increase CCI and make the problem worse. The exhibit's issue is channel reuse, not insufficient channel bandwidth.

Disable the 2.4 GHz radios to force all clients to 5 GHz.

Why wrong: Disabling the 2.4 GHz radios only removes the legacy band and does nothing to alter the channel assignments on the 5 GHz band where the contention is occurring. This would also force clients that depend on 2.4 GHz (such as IoT or older devices) onto 5 GHz, potentially causing connectivity issues while leaving the 5 GHz co-channel interference completely unsolved. The exhibit's problem is AP-to-AP channel overlap on 5 GHz, not the presence of the 2.4 GHz band.

The interface is administratively down.

Why wrong: The interface status in the output reads 'up, line protocol is up', indicating that the interface is fully operational at both Layer 1 and Layer 2. An administratively down interface would instead show 'administratively down, line protocol is down' and would not generate any IPv6 traffic, including Router Advertisements. Since the router is actively advertising and the link-local address is present, the interface is clearly not shut down or disabled.

The MAC address of the interface is invalid, preventing EUI-64 from generating a proper address.

Why wrong: The link-local address FE80::21A:2BFF:FE3C:4D5E shown in the output is derived from the interface MAC address using EUI-64, which inserts FFFE in the middle and flips the U/L bit. The presence of this valid link-local address proves the MAC address is not invalid and EUI-64 generation succeeded. An invalid or all-zero MAC would prevent IPv6 from generating any link-local address, but the output clearly displays a properly formed one, so this option cannot be the cause.

The router is not sending Router Advertisements, so hosts cannot autoconfigure.

Why wrong: The output explicitly states 'ND router advertisements are sent every 200 seconds', which confirms the router is actively sending ICMPv6 Router Advertisements on this interface. Hosts would therefore be able to perform stateless address autoconfiguration (SLAAC) and learn the default router. However, the problem is that hosts cannot reach the router's own link-local address, which points to a missing or incorrectly configured IPv6 address on the router itself, not to a lack of RA messages.

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 static route for 10.10.20.0/24 is missing from the routing table.

Why wrong: The routing table entry for 10.10.20.0/24 is visible in the output, showing 'via 10.10.10.2', so the static route is certainly not missing. This option misreads the table; the missing entry is actually the default route (0.0.0.0/0), not the static route to the 10.10.20.0 network. The presence of this specific static route does not affect the default route's reachability, which is the real issue.

The GigabitEthernet0/0 interface is administratively down.

Why wrong: The interface status in the exhibit is 'up/up' with IP address 10.10.10.1, and the connected route for 10.10.10.0/24 is present in the routing table. An administratively down interface would be 'shutdown' and would remove all connected routes, including the subnet that contains the next-hop. Since the next-hop is unreachable despite the interface being up, the problem lies with the remote router or Layer 2 connectivity, not the local interface state.

The default route is not configured; the gateway of last resort is missing.

Why wrong: The output includes the line 'Gateway of last resort is 10.10.10.2 to network 0.0.0.0', proving that a default route is configured and the router recognizes it as the gateway of last resort. However, the default route does not appear as an 'S*' entry in the routing table because the next-hop is unreachable. This option incorrectly assumes that the configuration is missing; in reality, the route is configured but not installed.

A NAT rule translating IPv6 to IPv4

Why wrong: IPv6 was designed to restore end-to-end connectivity without relying on NAT; in normal native IPv6 environments, routing uses global unicast addresses directly. A NAT rule that translates IPv6 to IPv4 would be an unnecessary and complex workaround, and it would not help the host reach off-link IPv6 destinations unless that IPv4 path itself is routed. Since the host already reaches neighbors using IPv6, the missing element is not address translation but a route to a default gateway.

A VLAN trunk on the host NIC

Why wrong: VLAN trunking is a Layer 2 feature used to carry multiple VLANs over a single switch link, typically between switches or to a router-on-a-stick. An end host NIC rarely requires trunking, and the symptom described is unrelated to VLAN tagging because it concerns Layer 3 reachability. Even if the NIC were configured with a trunk, that would not provide a default route or next hop for off-link IPv6 packets.

A second global unicast address on the same interface

Why wrong: Adding a second global unicast address to the same interface only provides an additional source or destination identifier for that interface; it does not install any route or gateway information into the host's IPv6 routing table. The host still lacks a default route for off-link traffic, and the existing address already satisfies the requirement of having a valid IPv6 source address. Therefore, a duplicate address does not solve the described reachability problem.

The SSID broadcast setting, because the client must not be joined correctly.

Why wrong: The SSID broadcast setting only controls whether the network name appears in probe responses, not whether an already-associated client can send or receive traffic. Because the client successfully joined and pulled an address from the correct subnet, it is not a join failure. If broadcast were disabled, the client would still be able to connect if it manually knew the SSID, and would not explain an application-specific issue.

The voice VLAN on the wired access port connected to the AP uplink.

Why wrong: The voice VLAN on the wired access port is used to separate VoIP traffic from data traffic on the wired infrastructure, and it does not affect how a wireless client forwards traffic after joining a WLAN. A client that has already received an address from the correct subnet is clearly operating on the data VLAN, not the voice VLAN, and general employee access works correctly. Since the problem is restricted to one application, changing the voice VLAN setting on the AP uplink would have no bearing on this scenario.

The OSPF router ID on the client device.

Why wrong: OSPF router IDs are used by routers participating in OSPF to identify themselves in link-state advertisements; end-client devices such as laptops or phones do not run OSPF and never exchange routing protocol information with the network. A client's network stack obtains an address via DHCP and uses a default gateway for off-subnet traffic, so OSPF router ID is irrelevant. The application-specific failure cannot be caused by a parameter that does not exist on the client device.

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.

PAT requires OSPF to be enabled on the WAN link.

Why wrong: PAT operates at Layer 3/4 and only needs the inside and outside interfaces to be correctly identified and the ACL to match traffic. Routing protocols like OSPF are used to exchange routes, not to enable NAT. As long as the router has a route to the destination (e.g., a default static route), PAT will work independently of whether OSPF is running.

The ACL must be numbered 100 instead of 1.

Why wrong: Standard ACLs (1-99) and extended ACLs (100-199) are both valid for NAT. The `access-list 1 permit` command simply defines which source addresses are eligible for translation; it does not require a specific number range. In fact, many PAT configurations use a standard ACL numbered 1, so changing to 100 would have no effect on whether PAT is working.

The router must use GRE before PAT can overload.

Why wrong: PAT is a form of NAT that multiplexes many private addresses to one public IP using unique port numbers. GRE is a tunneling protocol used to encapsulate packets (e.g., for VPNs) and is not a prerequisite for NAT/PAT. The router can perform PAT directly on the physical WAN interface without any tunnel.

On R1, change the subnet mask on G0/0 from /24 to /30. On R1 G0/1, issue 'ipv6 address 2001:db8:1::/64 eui-64' and 'no shutdown'. No need to enable IPv6 unicast-routing because it is on by default.

Why wrong: This is incorrect because IPv6 unicast-routing is not enabled by default on Cisco IOS; it must be explicitly configured with the 'ipv6 unicast-routing' global command. Without it, IPv6 packets will not be forwarded between interfaces.

On R1, change the subnet mask on G0/0 from /24 to /30. On R1 G0/1, issue 'ipv6 address 2001:db8:1::/64' (without eui-64) and 'no shutdown'. Enable 'ipv6 unicast-routing' globally on both routers.

Why wrong: This is incorrect because the question specifies that R1's G0/1 should use EUI-64. The command 'ipv6 address 2001:db8:1::/64' assigns a static address (the full /64 prefix as the interface ID), which is not what is required. The correct command includes the 'eui-64' keyword to generate the interface ID from the MAC address.

On R1, change the subnet mask on G0/0 from /24 to /30. On R1 G0/1, issue 'ipv6 address 2001:db8:1::/64 eui-64' and 'no shutdown'. Enable 'ipv6 unicast-routing' globally on both routers. Also, change the default gateway on PC1 to 2001:db8:1::1.

Why wrong: This is incorrect because the default gateway on PC1 should be the IPv6 address of R1's G0/1 interface. With EUI-64, the interface address is derived from the MAC address, not necessarily ::1. The question states that R1's G0/1 uses EUI-64, so the gateway address is not predetermined as ::1. The PCs already have correct gateways as per the existing explanation.

Configure a default gateway on PC-A with the IP address 192.168.10.1.

Why wrong: This is incorrect because PC-A has an APIPA address (169.254.23.45), which indicates it did not receive a DHCP lease. Manually setting a default gateway does not resolve the underlying issue of DHCP failure. The PC must first obtain a valid IP address via DHCP before a default gateway can be used.

Change the VLAN on SW1's interface connected to PC-A from VLAN 10 to VLAN 1.

Why wrong: This is incorrect because PC-A is configured for VLAN 10, and the DHCP pool is on subnet 192.168.10.0/24, which is associated with VLAN 10. Changing to VLAN 1 would place PC-A in a different subnet, preventing it from receiving a DHCP lease from R1's pool. The VLAN configuration is correct as is.

Add the 'ip helper-address' command on R1's interface connected to SW1.

Why wrong: This is incorrect because the DHCP server is on R1 itself, not on a remote server. The 'ip helper-address' command is used to forward DHCP broadcasts to a DHCP server on a different subnet. Since R1 is the DHCP server, no helper address is needed; the router will respond to DHCP requests on its directly connected interface.

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.

Change the LACP mode on SW1's Gi0/2 from active to passive.

Why wrong: This is incorrect because the LACP mode mismatch is not the primary issue; SW2's Gi0/2 is passive and SW1's Gi0/2 is active, which is a valid combination (active/passive). Changing to passive would not fix the speed/duplex/VLAN mismatches.

Configure both interfaces with speed 100, duplex half, and switchport access vlan 10.

Why wrong: This is incorrect because while it would make the interfaces consistent, it uses suboptimal settings (100/half) that would degrade performance. The correct fix should use the higher speed and full duplex (1000/full) to match the faster interface.

Remove the switchport access vlan command from both interfaces and configure them as trunk ports with native vlan 1.

Why wrong: This is incorrect because the issue is mismatched VLANs, not the interface mode. Changing to trunk with native VLAN 1 would still leave the speed/duplex mismatch unresolved, and the native VLAN must match on both sides. The current configuration shows access ports, so converting to trunk is unnecessary.

The DHCP pool is misconfigured: the excluded-address range should be 192.168.50.1 192.168.50.9, but the helper-address on GigabitEthernet0/0 is correct because it forwards DHCP requests to the remote server. The relay agent configuration is missing on GigabitEthernet0/1.

Why wrong: This is incorrect because the helper-address on GigabitEthernet0/0 is not needed; R1 is the DHCP server for that subnet, so broadcasts should not be forwarded elsewhere. Adding a helper-address would cause DHCP requests to be forwarded to the remote server unnecessarily.

The DHCP pool is correctly configured with excluded-address 192.168.50.1 192.168.50.9. The issue is that the 'ip helper-address' on GigabitEthernet0/1 is missing; it should be added to forward requests to the remote server. Additionally, the 'ip helper-address' on GigabitEthernet0/0 is correct because it forwards requests from VLAN 50 to the remote server.

Why wrong: This is incorrect because the excluded-address range is correct, but the helper-address on GigabitEthernet0/0 is still unnecessary and should be removed. The problem statement says clients on VLAN 50 are not receiving addresses, which is due to the excluded-address covering the entire pool, not the helper-address on G0/0.

The DHCP pool is misconfigured: the excluded-address range should be 192.168.50.1 192.168.50.9. The 'ip helper-address' on GigabitEthernet0/0 should be removed. The relay agent configuration is correct because 'ip helper-address 203.0.113.10' is already configured on GigabitEthernet0/1.

Why wrong: This is incorrect because the relay agent configuration is missing; the helper-address on GigabitEthernet0/1 is not present. The option claims it is already configured, but the problem states that the relay agent configuration is missing.

interface GigabitEthernet0/0.10 encapsulation dot1Q 10 ip helper-address 192.168.10.100

Why wrong: This places the helper-address on the VLAN 10 subinterface, which does not help VLAN 20 hosts because broadcasts from VLAN 20 are not received on this interface.

interface GigabitEthernet0/0.20 encapsulation dot1Q 20 ip dhcp relay information option

Why wrong: The ip dhcp relay information option command adds DHCP option 82 information but does not forward broadcasts to a specific server; it is not a substitute for ip helper-address.

ip dhcp pool VLAN20 network 192.168.20.0 255.255.255.0 default-router 192.168.20.1

Why wrong: This configures R1 as a DHCP server for VLAN 20, but the requirement is to forward broadcasts to an existing server, not to have R1 act as a server.

Port security has shut down the interface

Why wrong: Port security violations that put an interface into error-disabled state cause the port to display as 'err-disabled' or 'shutdown' in show interface output. The exhibit shows the interface status as 'connected' (up/up), which indicates the port is operational and not disabled by a security violation. Therefore, port security is not the reason the PC cannot reach the default gateway.

The port must be converted to a trunk

Why wrong: An access port sends and receives untagged Ethernet frames, which is exactly what a normal PC generates. A trunk port, by default, expects 802.1Q-tagged frames and would drop or mishandle the PC's untagged traffic unless the native VLAN is configured to match. Converting the port to a trunk would not solve the reachability problem and could make it worse; the correct fix is to ensure the access VLAN is active.

The default gateway must be configured on the physical switch port

Why wrong: A default gateway is a Layer 3 setting required on hosts or on a switch's management SVI, not on physical access ports. Configuring a default gateway on the PC's access port would have no effect on forwarding the PC's traffic, because access ports operate at Layer 2 and do not make routing decisions. The actual default gateway for VLAN 20 would be on the router or the switch's VLAN 20 SVI.