Hard Difficulty Questions

The native VLAN is mismatched on member interface Gi0/2.

Why wrong: The output explicitly states 'Native vlan mismatch: local 20, partner 1' for Gi0/2, confirming that the 802.1Q native VLAN differs between the local switch and its neighbor. In an EtherChannel, all member trunks must have identical native VLANs; when the native VLAN does not match, the switch suspends the member port, as shown by the 'susp' state, to prevent frame misdelivery. This mismatch is reported by CDP and is the direct cause of the port-channel member being non-forwarding.

The load-balancing method on the port-channel is set incorrectly to src-dst-ip.

Why wrong: The load-balancing method, such as src-dst-ip, determines how an EtherChannel distributes traffic across its active member links, but it has no effect on whether a link is placed into a 'susp' state. A suspended port results from a physical or configuration incompatibility between the local port and its peer, not from the hashing or distribution algorithm. Moreover, the exhibit shows a native VLAN mismatch on Gi0/2, and no load-balancing configuration appears in the output, so this answer is incorrect.

Spanning Tree Protocol has placed the port-channel in a blocking state due to a loop.

Why wrong: Spanning Tree Protocol prevents Layer 2 loops by placing redundant paths into a blocking state, but STP operates on the logical PortChannel interface, not on individual member ports, and it would not mark Gi0/2 as 'susp' in an EtherChannel status output. The 'susp' designation is an EtherChannel-specific condition caused by a configuration mismatch with the neighbor, such as the documented native VLAN mismatch on Gi0/2. Since the exhibit contains no STP state or topology-change indication, the blocking-state explanation is not supported.

The access list 'NAT' is incorrect; it should permit only specific hosts, not the entire subnet.

Why wrong: The access list 'NAT' is not the problem. In dynamic NAT, the ACL is used solely to identify which inside addresses are eligible for translation, and permitting the entire internal subnet is standard and correct when all internal hosts should have Internet access. Even if the ACL were narrowed to specific hosts, the router would still fail to translate return packets because the outside interface has not been designated with 'ip nat outside'. The ACL only controls which source addresses are translated, not whether NAT is applied on an interface.

The NAT configuration lacks the 'overload' keyword, so the pool is exhausted quickly.

Why wrong: The lack of the 'overload' keyword is a red herring here. Without overload, the router performs standard dynamic NAT, which still works correctly as long as the number of active inside addresses does not exceed the number of addresses in the pool. In the scenario, there are only 2 active translations and 11 addresses in the pool, so the pool is not exhausted and overload would not change the immediate outcome. The real issue is that the outside interface is not configured for NAT, and adding overload cannot compensate for that missing interface-level command.

The NAT pool 'POOL' has too few addresses; it should be expanded to a /24 subnet.

Why wrong: The NAT pool 'POOL' has 11 addresses, which is more than enough for the two active translations, so pool size is not causing the problem. Expanding the pool to a /24 subnet would only increase the maximum number of concurrent translations; it would not make the router process return traffic on the outside interface. Even with 254 public addresses available, the router would still not translate reply packets because the outside interface is not marked with 'ip nat outside'. The symptom of no replies is a direct result of missing interface NAT designation, not address exhaustion.

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 PAT translation table is full, causing new TCP connection requests to be dropped.

Why wrong: PAT uses source port translation to map many internal addresses to a single public IP. ICMP (ping) does not consume a port mapping and can still be translated even when the table is exhausted. New TCP connections, required for web traffic, will fail when no free source port is available.

The 'overload' keyword was omitted, causing the router to use dynamic NAT with a single-address pool.

Why wrong: The configuration shown includes the 'overload' keyword. Even if it were missing, dynamic NAT without overload would not allow any internal host other than the first one to use the IP, but pings would also fail from other hosts. This does not match the symptom.

A static NAT entry for a web server is using the same public IP address as the PAT overload.

Why wrong: Configuring a static NAT entry with the same IP as the overloaded outside interface would typically cause a conflict or prevent the PAT translation from working correctly for all traffic, including ping. The router would likely generate an error or reject the command.

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.

Disable Root Guard on the distribution switch interface

Why wrong: Root Guard is a protective STP feature that forces a designated port to enter the root-inconsistent state if it receives a superior BPDU, preventing a new switch from becoming the root bridge. Disabling it on the distribution switch interface would remove this safeguard and allow the unauthorized switch's lower bridge priority to win the STP election, potentially causing a topology change, switching loop, or suboptimal forwarding path. This action does nothing to resolve the err-disable state caused by BPDU Guard, and it actively reduces network stability, making it the opposite of the correct fix.

Remove PortFast from the new access switch uplink interface

Why wrong: PortFast on the new access switch's uplink does not directly cause the distribution switch interface to become err-disabled; the err-disable condition occurs because BPDU Guard is enabled on the distribution switch's port, which reacts to receiving any BPDU from the access switch. Removing PortFast from the access switch's uplink does not stop the distribution switch from receiving BPDUs—STP BPDUs are always sent on a link between switches unless BPDU filtering or guard is explicitly configured. Moreover, the appropriate configuration change is on the distribution switch interface itself, not on the access switch, and simply removing PortFast from an access switch port would not clear the existing err-disable state.

Configure the interface as an access port instead of trunk

Why wrong: Changing the distribution switch interface from trunk mode to access mode is irrelevant to the err-disable cause, because BPDU Guard err-disables any PortFast-enabled port that receives a BPDU, regardless of whether the port is configured as an access or trunk port. The interface is connected to a new access switch, so it must operate as a trunk to carry multiple VLANs and to exchange legitimate STP BPDUs. Reconfiguring it as an access port would break VLAN connectivity and still not prevent BPDU Guard from triggering on subsequent BPDU reception, so it fails to address the underlying issue.

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.

Check the DHCP server logs to see if it is receiving Discover messages.

Why wrong: Checking the DHCP server logs for Discover messages is premature in this scenario. Because the DHCP server resides on a different subnet than the clients, server-side logs will only show Discover packets if the router's VLAN 20 interface has an IP helper-address configured to forward broadcast DHCP requests. If the helper-address is missing, the router drops the broadcast at the VLAN boundary, and the server never sees any Discover traffic—so the absence of such messages in the logs would merely confirm the relay misconfiguration, not diagnose it. This step is valid only after confirming that the relay configuration is correct, and it wastes troubleshooting time by skipping the most fundamental cause.

Attempt to ping the DHCP server's IP address from the host's APIPA address.

Why wrong: The host's APIPA address (169.254.x.x) is a link-local address. Without a default gateway or a routable IP, pinging an address on a different subnet will not work, even if the DHCP server is reachable. This test does not confirm DHCP functionality and is not a standard troubleshooting step for DHCP failures.

Restart the DHCP service on the server and recheck the host.

Why wrong: Restarting the DHCP service is a disruptive action and should not be the first step, especially when the root cause likely lies in the network configuration (missing relay). It does not address the underlying issue and may cause unnecessary downtime.

R2 has a lower HSRP priority than R1, so it cannot become standby.

Why wrong: A lower priority does not prevent a router from becoming standby; it simply makes it less likely to become the active router if preemption is enabled. Here the issue is not priority—both routers are active in different groups.

The HSRP authentication strings do not match.

Why wrong: HSRP authentication mismatch would cause the routers to reject each other's hello messages, but the routers would still be configured with the same group number. The failure symptom would be both routers attempting to become active for the same group (or remaining in a non-active state), not the group 10 vs. group 20 configuration seen in the outputs. Since the show standby output explicitly displays different group numbers, authentication is not the root cause; the group mismatch fully explains the lack of failover.

HSRP version 1 is used on R1 while version 2 is used on R2.

Why wrong: A version mismatch would cause the routers to ignore each other’s hello packets and both become active, but they would still be in the same configured group number. The output shows different group numbers (10 vs 20), which is a more explicit misconfiguration.

The default gateway must be removed from the DHCP scope.

Why wrong: Removing the default gateway from the DHCP scope would eliminate the router as the next hop, breaking all off-subnet communication. The problem is isolated to hostname resolution while IP connectivity succeeds, so a missing gateway would cause total network failure, not just DNS failure. Therefore, the default gateway must remain in the scope and cannot be the cause.

The clients must use PPP before DNS works.

Why wrong: PPP (Point-to-Point Protocol) is a WAN data-link encapsulation used on serial or DSL links, not a service required for DNS on an Ethernet LAN. DNS resolution operates over IP and is independent of the data-link protocol; clients do not need PPP to send DNS queries. This option incorrectly conflates a WAN technology with local DHCP operation and is unrelated to the VLAN 70 issue.

The VLAN must be converted to the native VLAN on all trunks.

Why wrong: The native VLAN in 802.1Q trunks carries untagged frames; changing VLAN 70 to native would affect trunk tagging and could cause broadcast or misdelivery issues. However, the symptom is specifically that clients reach services by IP but not by hostname, indicating a DNS problem, not a Layer 2 forwarding issue. If the native VLAN were misconfigured, general connectivity would fail, not just name resolution.

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 token is the IPv4 subnet mask for controller traffic.

Why wrong: This is wrong because a token is not a subnetting concept.

A token is the STP root bridge identifier.

Why wrong: This is wrong because tokens are unrelated to STP root election.

A token forces the API to use Telnet.

Why wrong: This is wrong because tokens are not tied to Telnet usage.

Change the AP from Ethernet to PPP encapsulation.

Why wrong: PPP (Point-to-Point Protocol) is a WAN encapsulation used on serial or dial-up links, not on Ethernet LAN segments where access points typically connect. Changing the AP's encapsulation to PPP would not affect CAPWAP, which runs over UDP/IP and expects Ethernet framing on the local LAN. The exhibit gives no indication of a serial link or PPP requirement, so this action is unrelated to the AP's inability to join the controller.

Remove the AP IP address so it can obtain an IP address automatically via DHCP.

Why wrong: Removing the static IP and switching to DHCP does not address the root cause because the problem is a layer 3 reachability misconfiguration, not the method of address assignment. If the DHCP scope also provides the same incorrect default gateway, the AP will obtain a valid address but still be unable to reach the controller. Even a dynamically assigned address requires a correct gateway to forward CAPWAP traffic; the static IP itself is not preventing the AP from joining.

Disable DHCP on the controller for all APs.

Why wrong: Disabling DHCP on the controller globally is incorrect because the exhibit indicates that the problem is specific to this AP's default gateway, and other APs are already joining successfully. Such a global change would disrupt DHCP-based provisioning for all access points, including the healthy ones, without correcting the faulty gateway on the problematic AP. The issue lies in the AP's local IP routing configuration, not in the controller's DHCP service.

Because OSPF always overrides static routing, regardless of prefix length.

Why wrong: The premise that OSPF automatically overrides static routing is false; routing decisions prioritize longest prefix match first, and only when prefix lengths are equal does administrative distance break the tie. A static route has an administrative distance of 1, which is far lower than OSPF's 110, so a static /24 would be preferred for that prefix. The real reason the OSPF route wins here is that the /26 route has a longer prefix length than the static /24, not because of the protocol type.

Because the static route must have an administrative distance of 255 to be considered.

Why wrong: The static route does not need to have an administrative distance of 255 to be considered; in fact, an AD of 255 is treated as unreachable and would not be installed in the routing table. The static route is indeed valid and present, but its /24 prefix is less specific than the OSPF /26 route. Cisco IOS selects routes based on the longest prefix match first, so the more specific /26 route wins regardless of the static route's administrative distance.

Because the destination 198.51.100.70 is outside both listed routes.

Why wrong: The destination 198.51.100.70 is not outside both routes—it lies within the static /24 range of 198.51.100.0 through 198.51.100.255 and also within the OSPF /26 range of 198.51.100.64 through 198.51.100.127. Since .70 is between .64 and .127, it is covered by the more specific OSPF route. Therefore, the claim that it is outside either network is incorrect.

172.16.0.0/16

Why wrong: Although 172.16.20.200 is within the 172.16.0.0/16 address block, this route has a prefix length of only 16 bits. The router selects the route with the longest matching prefix; since the routing table contains more specific routes (172.16.20.0/24 and 172.16.20.128/25), the /16 route is not considered for forwarding. It would only be used if no longer prefix matches existed. Its broad summary covers many subnets, but that generality disqualifies it in favor of the more exact /25 entry.

172.16.20.0/24

Why wrong: While 172.16.20.0/24 does encompass the destination IP address 172.16.20.200, it is not the route selected. Routers utilise the Longest Prefix Match rule, which dictates that the most specific route available in the routing table for a given destination IP address will be chosen. In this scenario, 172.16.20.128/25 is a more precise match. This option would be correct if the 172.16.20.128/25 route were absent, as it would then represent the longest prefix match.

The default route

Why wrong: A default route, typically 0.0.0.0/0, matches every destination IP address. However, it has the shortest possible prefix length (0), making it the least specific route. The longest prefix match algorithm always prefers the route with the greatest number of matching bits; here, both 172.16.20.0/24 and 172.16.20.128/25 match the destination with longer prefixes, so the default route is never selected for this packet. It serves only as a last resort when no other route matches the destination network.

The trunk must be converted to an access port for VLAN 20 to work.

Why wrong: An access port is designed to carry a single untagged VLAN, so converting the trunk to an access port would force it to carry only the VLAN assigned as the access VLAN, such as VLAN 20. This would drop the tags for VLANs 10 and 30, making them unreachable across the link, which defeats the purpose of a trunk that must carry all three VLANs. Furthermore, trunk ports are the standard mechanism for inter-switch multi-VLAN traffic, and a misconfigured allowed list is a filtering problem, not a port-mode problem.

VLAN 20 must always be the native VLAN.

Why wrong: The native VLAN on an 802.1Q trunk is the VLAN that is transmitted without an 802.1Q tag; it is an untagged path used for control traffic and for devices that do not support VLAN tagging. VLAN 20 can be carried either as a tagged VLAN or as the native VLAN, but setting it as native would simply change the tagging behavior, not the allowed list. If VLAN 20 is missing from the allowed list, even untagged frames for the native VLAN will not be forwarded. Thus, native VLAN assignment is independent from the VLAN membership filtering issue.

The switches must both use ISL instead of 802.1Q.

Why wrong: ISL and 802.1Q are different trunking encapsulations; both use their own tagging format and both are capable of carrying VLAN 20 across a trunk. The problem described is that VLAN 20 is not in the allowed list on one side, which is a VLAN filter applied at the interface level regardless of the encapsulation protocol. Even if both switches were configured for ISL, the missing VLAN would still be omitted from the allowed list, so the traffic would still be blocked. Additionally, most Cisco switches today default to 802.1Q, and mixing encapsulations would break the trunk entirely.

The static route overrides OSPF immediately because static routes always win.

Why wrong: Static routes do not 'always win' because route selection is based on administrative distance, not on the route type alone. By default, a static route has an AD of 1, which normally beats OSPF's 110, but here the static route's AD has been configured higher than OSPF's, allowing OSPF to remain preferred. Therefore, it is the specific numeric AD values that determine preference, not a blanket rule that static outranks dynamic routing.

Both routes must be installed simultaneously because they point to the same destination.

Why wrong: The router does not install both routes just because they point to the same destination; it installs only the one with the best (lowest) administrative distance for that prefix. Both routes would be installed only if they had equal AD and formed equal-cost multipath (ECMP), or if they addressed different prefixes. Since the same destination and differing ADs mean only OSPF is selected, simultaneous installation is not required.

The router removes the OSPF route because the static route has a manually configured distance.

Why wrong: A manually configured distance does not cause the router to remove the OSPF route. The router selects the route with the lowest AD for the destination; because the static route's manually configured distance is higher than OSPF's 110, OSPF remains the best route and stays in the routing table. The static route is simply not installed, and OSPF is not removed merely because a static route with a higher distance exists.

The OSPF route is installed because cost 20 is lower than metric 0

Why wrong: This statement incorrectly compares OSPF's cost (20) to the static route's metric (0) and assumes a lower number wins. In Cisco IOS, a router first compares administrative distance when multiple routing sources provide a path to the same network; only if AD values are equal are metrics compared. Since the static route's AD of 5 is much lower than OSPF's default AD of 110, the static route is installed into the routing table despite OSPF having a lower metric value. The OSPF cost is irrelevant until the static route is removed, at which point OSPF becomes the active route by default, not because its cost is lower.

Both routes are installed as equal-cost paths automatically

Why wrong: Equal-cost multipath (ECMP) only applies when multiple routes to the same prefix have the same administrative distance and the same metric, and they are usually from the same routing protocol. Here the static route has an AD of 5 while OSPF has an AD of 110, so they are not equal from the router's perspective. Moreover, their metrics—0 for the static and 20 for OSPF—are not comparable across different protocols. Therefore, the router does not install both; it selects only the static route as the single best path.

All tagged VLAN traffic is automatically converted to routed traffic

Why wrong: A native VLAN mismatch does not alter the fundamental operation of a trunk link, which remains a Layer 2 forwarding path. The 802.1Q tag is still applied to frames from all non-native VLANs, and those frames are switched based on MAC addresses exactly as they would be with a correctly configured trunk. There is no mechanism that converts tagged VLAN traffic into routed traffic; routing would only occur if the frames are sent to a Layer 3 interface, which is a separate configuration unrelated to trunk native VLAN settings.

The mismatch forces OSPF adjacency reset on all routers

Why wrong: A native VLAN mismatch is a Layer 2 trunking misconfiguration; it directly affects only how untagged frames are interpreted on the trunk. OSPF adjacency is a Layer 3 routing process that relies on IP reachability and multicast hello packets, not on the native VLAN assignment of a trunk. While an IP connectivity issue could indirectly cause OSPF neighbors to go down, the mismatch itself does not force an OSPF adjacency reset on any router, and OSPF has no mechanism that reacts specifically to trunk native VLAN mismatches.

The trunk can carry only one VLAN until the mismatch is cleared

Why wrong: An 802.1Q trunk is designed to carry multiple VLANs simultaneously by adding a 4-byte tag to frames from all VLANs except the native VLAN. When a native VLAN mismatch exists, the untagged frames on the native VLAN are mishandled, but frames from other VLANs remain correctly tagged and continue to traverse the trunk normally. Therefore the trunk does not become limited to a single VLAN; it continues to transport all configured tagged VLANs, and only the untagged native VLAN traffic is subject to misassociation.

The interface received a superior BPDU and became the root port.

Why wrong: STP role changes like becoming a root port occur when a superior BPDU is received, but that event would be reflected in spanning-tree state transitions and forwarding behavior, not in a security intrusion log. A hub does not originate BPDUs, and the error message clearly identifies a port-security violation rather than an STP topology change. Therefore, the interface's down state is due to security enforcement, not a spanning-tree decision.

The hub forced the interface to become a routed port.

Why wrong: A hub is a Layer 1 device that simply forwards electrical signals, so it cannot change the logical mode of a switch interface. A routed port is created only by explicitly removing Layer 2 switching with the "no switchport" command, which is not shown here. The log message references a port-security violation, not a change in interface mode.

DHCP snooping always shuts a port when a hub is attached.

Why wrong: DHCP snooping filters DHCP messages based on whether a port is trusted or untrusted; it does not count MAC addresses or react to the simple attachment of a hub. A hub only extends the collision domain, and it does not generate DHCP traffic or cause a DHCP snooping violation by itself. The exhibit shows a port-security restriction on secure MAC addresses, not any DHCP-related action.