Performance-Based Questions (PBQs)

interface GigabitEthernet0/1 switchport mode trunk switchport trunk allowed vlan 10 interface GigabitEthernet0/2 switchport mode trunk switchport trunk allowed vlan 20 end show interfaces trunk

Why wrong: This is incorrect because trunk ports are used to carry multiple VLANs between switches, not to connect end devices like PCs and servers. Access ports should be used instead.

vlan 10 name PC_VLAN vlan 20 name Server_VLAN interface GigabitEthernet0/1 switchport mode access switchport access vlan 10 interface GigabitEthernet0/2 switchport mode access switchport access vlan 20 end show vlan brief

Why wrong: This is incorrect because it includes unnecessary VLAN creation and naming steps. While not harmful, the question only asks to assign ports to VLANs, not to create or name them. However, the main issue is that the configuration is valid but not minimal; the question expects only the required commands.

interface GigabitEthernet0/1 switchport access vlan 10 interface GigabitEthernet0/2 switchport access vlan 20 end show vlan brief

Why wrong: This is incorrect because it omits the 'switchport mode access' command. Without setting the port mode to access, the port may default to dynamic desirable or trunk mode, which could cause issues with VLAN assignment.

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.

interface GigabitEthernet0/1 switchport mode trunk switchport trunk allowed vlan 10,20 power inline auto ! interface GigabitEthernet0/2 switchport mode access switchport access vlan 30 power inline never

Why wrong: This is incorrect because the IP phone port should be an access port, not a trunk. Using a trunk port would require the phone to negotiate trunking, which is not the standard Cisco IP phone deployment. The voice VLAN is configured via 'switchport voice vlan', not by trunking.

interface GigabitEthernet0/1 switchport mode access switchport access vlan 20 switchport voice vlan 10 power inline auto ! interface GigabitEthernet0/2 switchport mode access switchport access vlan 30 power inline never

Why wrong: This is incorrect because the voice VLAN should be 20, not the access VLAN. The access VLAN is for data traffic (typically VLAN 10), and the voice VLAN is for voice traffic. Swapping them would put voice traffic in VLAN 10 and data in VLAN 20, which is not the requirement.

interface GigabitEthernet0/1 switchport mode access switchport access vlan 10 switchport voice vlan 20 power inline never ! interface GigabitEthernet0/2 switchport mode access switchport access vlan 30 power inline auto

Why wrong: This is incorrect because PoE is disabled on the IP phone port (G0/1) and enabled on the AP port (G0/2), which is the opposite of what is required. The IP phone needs PoE to power on, and the AP should have PoE disabled.

Change R1 G0/0 subnet mask to /30, add a default route via 192.0.2.254, and keep the EUI-64 IPv6 address on G0/0.

Why wrong: This is incorrect because the default route points to 192.0.2.254, which is not R2's G0/0 IP (192.0.2.2), so IPv4 traffic will not be forwarded. Also, EUI-64 generates an interface ID from the MAC, which will not match the subnet expected by R2's static address 2001:db8:1::2/64.

Change R1 G0/0 subnet mask to /24, add a default route via 192.0.2.2, and configure a static IPv6 address 2001:db8:1::1/64 on G0/0.

Why wrong: This is incorrect because the subnet mask on R1's G0/0 remains /24, which does not match R2's /30. R1 will consider the subnet to be 192.0.2.0/24, while R2 uses 192.0.2.0/30, causing a mismatch that prevents direct communication.

Change R1 G0/0 subnet mask to /30, add a default route via 192.0.2.2, and keep the EUI-64 IPv6 address on G0/0.

Why wrong: This is incorrect because while the IPv4 issues are fixed, the IPv6 address generated by EUI-64 will not match the subnet expected by R2's static address 2001:db8:1::2/64. EUI-64 creates an interface ID based on the MAC, which is unpredictable and unlikely to be in the same subnet as R2's static address.

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'.

On R1, change the helper-address to 192.168.10.255 and the excluded-address range to 192.168.10.1 192.168.10.10. On SW1, enable DHCP snooping globally and for VLAN 10, and set all ports as trusted.

Why wrong: This is incorrect because the helper-address should be the DHCP server's IP (192.168.10.1), not the broadcast address (192.168.10.255). Also, setting all ports as trusted defeats the purpose of DHCP snooping, as it would allow rogue servers on any port.

On R1, change the helper-address to 192.168.10.1 and the excluded-address range to 192.168.10.1 192.168.10.254. On SW1, enable DHCP snooping globally and for VLAN 10, and set interface G0/1 as untrusted.

Why wrong: This is incorrect because the excluded-address range excludes almost all addresses (192.168.10.1 through 192.168.10.254), leaving only the broadcast address for clients, which is not usable. Also, the port facing the DHCP server (R1) must be trusted, not untrusted.

On R1, change the helper-address to 192.168.10.1 and the excluded-address range to 192.168.10.1 192.168.10.10. On SW1, enable DHCP snooping globally and for VLAN 10, and set interface G0/1 as untrusted.

Why wrong: This is incorrect because the port facing the DHCP server (R1) must be trusted. Setting it as untrusted would cause DHCP snooping to drop DHCP server messages (OFFER, ACK) from R1, preventing clients from obtaining IP addresses.

access-list 100 permit tcp 10.0.0.0 0.0.0.255 host 203.0.113.1 eq 22 access-list 100 deny ip any host 203.0.113.1 interface GigabitEthernet0/0 ip access-group 100 out

Why wrong: This is incorrect because applying the ACL outbound on G0/0 (facing SW1) would filter traffic leaving R1 toward R2. While it could work, it is less efficient because the traffic has already been routed through R1. Additionally, the implicit deny at the end of the ACL would block all other traffic to the loopback, but the outbound application is not the recommended direction.

access-list 100 permit tcp 10.0.0.0 0.0.0.255 host 203.0.113.1 eq 22 interface GigabitEthernet0/1 ip access-group 100 in

Why wrong: This is incorrect because it lacks the explicit deny statement for all other IP traffic to the loopback. Without the deny, the implicit deny at the end of the ACL will block all other traffic, but the explicit deny is necessary to clearly show the requirement is met. More importantly, the ACL does not deny traffic from other sources to the loopback; the implicit deny only applies to the ACL itself, but the question requires explicit denial.

access-list 100 permit tcp 10.0.0.0 0.0.0.255 host 203.0.113.1 eq 22 access-list 100 deny ip any any interface GigabitEthernet0/1 ip access-group 100 in

Why wrong: This is incorrect because the deny statement 'deny ip any any' blocks all IP traffic, including traffic to other destinations, not just the loopback. The requirement is to deny only traffic to the loopback, not all traffic. This would break connectivity for other traffic.

interface GigabitEthernet1/0/1 switchport mode trunk switchport trunk allowed vlan 10,110 power inline auto interface GigabitEthernet1/0/2 switchport mode access switchport access vlan 20

Why wrong: This is incorrect because Gi1/0/1 is configured as a trunk port instead of an access port. While a trunk can carry multiple VLANs, the requirement is for an access port with a voice VLAN. The 'switchport mode trunk' command changes the port to trunk mode, which is not desired.

interface GigabitEthernet1/0/1 switchport mode access switchport access vlan 10 switchport voice vlan 110 power inline never interface GigabitEthernet1/0/2 switchport mode access switchport access vlan 20

Why wrong: This is incorrect because 'power inline never' disables PoE on Gi1/0/1, preventing the IP phone from receiving power. The requirement explicitly states to enable PoE. The correct command is 'power inline auto' (or no command, as auto is default).

interface GigabitEthernet1/0/1 switchport mode access switchport access vlan 110 switchport voice vlan 10 power inline auto interface GigabitEthernet1/0/2 switchport mode access switchport access vlan 20

Why wrong: This is incorrect because the access VLAN and voice VLAN are swapped. The access VLAN should be 10 (data) and the voice VLAN should be 110 (voice). This misconfiguration would place the IP phone's data traffic in VLAN 110 and voice traffic in VLAN 10, which is not the requirement.

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.

Remove the incorrect static route 192.0.2.0 255.255.255.0 10.0.0.1 and add ip route 192.0.2.0 255.255.255.0 10.0.0.2 1

Why wrong: This is incorrect because the administrative distance of 1 is lower than the directly connected route's AD of 0, so the floating static route would be preferred over the directly connected route, defeating its purpose as a backup.

Keep the existing static route and add ip route 192.0.2.0 255.255.255.0 10.0.0.2 10

Why wrong: The existing static route cannot remain because it uses 10.0.0.1 — R1's own G0/0 address — as the next hop for the remote 192.0.2.0/24 network. When R1 processes this route, it performs a recursive lookup for 10.0.0.1 and finds itself, causing packets to be looped back out the same interface instead of being forwarded to R2; this route becomes the active route with AD 1, outcompeting the new AD 10 route. Adding the floating static route with next-hop 10.0.0.2 does not remove or override the bad route—the lower-AD bad route remains preferred, so traffic to 192.0.2.0/24 is still black-holed. You must delete the faulty static route first, then add the correct floating route with AD 10.

Remove the incorrect static route 192.0.2.0 255.255.255.0 10.0.0.1 and add ip route 192.0.2.0 255.255.255.0 g0/0

Why wrong: This is incorrect because using an exit interface (g0/0) instead of a next-hop IP address for a static route to a remote network can cause issues if the interface goes down, but more importantly, the question requires a floating static route with AD 10, which is not provided here. Additionally, the route would be directly connected? Actually, using an exit interface makes the route a directly connected static route, which has AD 0? No, static routes with exit interface have AD 1 by default. But the question specifies a floating static route with AD 10, so this does not meet the requirement.

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.

Add an A record for webserver.internal (192.168.10.50) and correct the PTR record for 192.168.10.50 to point to webserver.internal, but leave the unreachable DNS server 192.0.2.53 in the configuration.

Why wrong: This is incorrect because leaving the unreachable DNS server 192.0.2.53 in the configuration will continue to cause timeouts for external queries like example.com. The router will attempt to query that server first or in parallel, leading to delays or failures.

Remove the unreachable DNS server 192.0.2.53 and add an A record for webserver.internal (192.168.10.50), but do not correct the PTR record for 192.168.10.50.

Why wrong: This is incorrect because while it fixes the external timeout and forward resolution, it leaves the reverse DNS mapping wrong. Reverse DNS lookups for 192.168.10.50 will still return 'mail.internal' instead of 'webserver.internal', which can cause issues with applications that rely on reverse lookups (e.g., SMTP, logging).

Replace the unreachable DNS server 192.0.2.53 with a reachable one, and correct the PTR record for 192.168.10.50 to point to webserver.internal, but do not add an A record for webserver.internal.

Why wrong: This option is incorrect because while replacing the unreachable DNS server with a reachable one restores external resolution (e.g., example.com) and correcting the PTR record fixes reverse lookups, it completely omits the required forward A record for webserver.internal. Without an A record, a DNS query for webserver.internal returns NXDOMAIN, so internal clients cannot resolve the hostname to 192.168.10.50. A PTR record only maps an IP address back to a name; it does not enable forward name-to-address resolution. Both the forward and reverse records must exist to make the device properly reachable by name.

Remove the 'ip dhcp excluded-address 192.168.1.1 192.168.1.10' command because it excludes too many addresses.

Why wrong: This is incorrect because excluding 10 addresses from a /24 subnet (254 usable addresses) is not excessive. The exclusion is necessary to reserve addresses for static devices like the router interface. The APIPA issue is not caused by this exclusion.

Change the DHCP pool network to 192.168.1.0/24 and add the default-router 192.168.1.1 command.

Why wrong: This change is unnecessary and would not resolve the problem because the DHCP pool on R1 already contains the correct 'network 192.168.1.0 255.255.255.0' and 'default-router 192.168.1.1' statements. The configuration as written is valid and would lease addresses properly if the DHCP service were enabled. Simply rewriting or re-adding these commands does nothing to activate the router's DHCP server engine, which is disabled by default and requires the 'service dhcp' global command. Without that global enable, the client will continue receiving no DHCP replies and will fall back to an APIPA address.

Configure the 'ip helper-address' command on the client's VLAN interface to forward DHCP requests to the server.

Why wrong: This is incorrect because the DHCP server is on the same router (R1) as the client's subnet. The 'ip helper-address' command is used to forward DHCP broadcasts to a remote server, which is unnecessary here. The client and server are on the same device.

ntp server 198.51.100.10 source Loopback0 logging trap 4

Why wrong: This is incorrect because 'logging trap 5' uses the numeric severity level, but the question expects the keyword 'notifications' for severity 5. While both are technically valid, the question specifies 'severity 5 (notifications)', and the correct answer uses the keyword.

ntp server 198.51.100.10 logging trap notifications

Why wrong: This is incorrect because it omits the 'source Loopback0' parameter. Without specifying the source interface, the NTP client will use the outgoing interface IP, which may not be Loopback0, potentially causing reachability or authentication issues.

ntp server 203.0.113.5 source Loopback0 logging trap 7

Why wrong: This is incorrect because it uses the wrong NTP server address (203.0.113.5 instead of 198.51.100.10) and sets the logging trap level to debugging (7), which sends all messages instead of only notifications (5) and above.

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.

Change the virtual IP to 192.0.2.254 and remove the track command.

Why wrong: Removing the track command would disable HSRP's interface tracking, so R1 would no longer decrement its priority when G0/1 fails. This is counterproductive because the task explicitly requires R1 to yield active status if its uplink goes down, and the current track configuration is valid. Even with the virtual IP corrected to 192.0.2.254, without tracking R1 could remain active while having lost connectivity, defeating the redundancy objective. Thus, this change is incomplete and harmful.

Change the virtual IP to 192.0.2.254 and configure preempt on R2.

Why wrong: This is incorrect because the task explicitly says to fix the configuration on R1 only. Configuring preempt on R2 does not address the issue on R1 and may cause R2 to preempt R1, which is not desired.

Change the virtual IP to 192.0.2.254 and set priority to 100.

Why wrong: This is incorrect because setting priority to 100 (default) would not make R1 the active router if R2 also has priority 100. Without a higher priority, R1 may not become active, especially if R2 has preempt disabled.

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.