Performance-Based Questions (PBQs)

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 G0/0 as inside, G0/1 as outside; modify ACL 1 to permit 192.168.1.0 0.0.0.255; apply ip nat inside source list 1 interface G0/1 overload; keep ip nat inside source static 192.168.1.10 203.0.113.6

Why wrong: This is incorrect because the interface assignments are swapped: G0/0 (public) should be outside, not inside. PAT must be applied to the outside interface (G0/0), not G0/1.

Configure G0/0 as outside, G0/1 as inside; modify ACL 1 to permit 192.168.2.0 0.0.0.255; apply ip nat inside source list 1 interface G0/0 overload; keep ip nat inside source static 192.168.1.10 203.0.113.6

Why wrong: This is incorrect because ACL 1 still permits the wrong subnet (192.168.2.0/24) instead of the correct inside subnet (192.168.1.0/24). PAT would not translate traffic from the LAN.

Configure G0/0 as outside, G0/1 as inside; modify ACL 1 to permit 192.168.1.0 0.0.0.255; apply ip nat inside source list 2 interface G0/0 overload; keep ip nat inside source static 192.168.1.10 203.0.113.6

Why wrong: This is incorrect because the PAT command references ACL 2, but ACL 2 is not defined or does not match the inside subnet. The correct ACL is ACL 1 after modification.

ip access-list standard PERMIT_INTERNAL permit 192.168.1.0 0.0.0.255 interface GigabitEthernet0/1 ip nat outside interface GigabitEthernet0/0 ip nat inside ip nat inside source list PERMIT_INTERNAL interface GigabitEthernet0/0 overload ip nat inside source static tcp 192.168.1.10 80 203.0.113.10 80 ip nat inside source static tcp 192.168.1.20 25 203.0.113.11 25

Why wrong: This configuration incorrectly assigns the NAT interface directions: the inside interface (Gig0/1) is marked as 'outside' and the outside interface (Gig0/0) as 'inside'. This would cause NAT to fail because traffic from internal hosts would not be translated correctly.

ip access-list standard PERMIT_INTERNAL permit 192.168.1.0 0.0.0.255 interface GigabitEthernet0/1 ip nat inside interface GigabitEthernet0/0 ip nat outside ip nat inside source list PERMIT_INTERNAL interface GigabitEthernet0/0 overload ip nat inside source static 192.168.1.10 203.0.113.10 ip nat inside source static 192.168.1.20 203.0.113.11

Why wrong: This configuration omits the protocol and port in the static NAT entries. Without specifying TCP and port numbers, the static NAT would apply to all traffic (including non-HTTP/SMTP) and could conflict with PAT. Also, the 'extendable' keyword is missing, which is recommended when using PAT alongside static NAT.

ip access-list standard PERMIT_INTERNAL permit 192.168.1.0 0.0.0.255 interface GigabitEthernet0/1 ip nat inside interface GigabitEthernet0/0 ip nat outside ip nat inside source list PERMIT_INTERNAL interface GigabitEthernet0/0 overload ip nat outside source static tcp 203.0.113.10 80 192.168.1.10 80 ip nat outside source static tcp 203.0.113.11 25 192.168.1.20 25

Why wrong: This configuration uses 'ip nat outside source static' instead of 'ip nat inside source static'. The 'outside source static' command translates the source address of packets coming from the outside, which is not the correct method for mapping external public IPs to internal servers. The correct command is 'ip nat inside source static'.

Add a static route to 10.0.0.0/30 via the backup link to R3, then the default route to 10.0.0.2 will work. Then configure IPv6 default routes with AD 1 and 10 as described.

Why wrong: This is incorrect because adding a static route to 10.0.0.0/30 via the backup link would cause the default route to use the backup path, defeating the purpose of having a primary path. The issue is that the next-hop 10.0.0.2 is not directly connected or reachable; the correct fix is to ensure the interface is up and the next-hop is on a directly connected subnet, not to add a static route via the backup.

Change the administrative distance of the IPv4 default route to 10 and the backup to 1, so the backup becomes primary. Then configure IPv6 default routes with AD 10 and 1 respectively.

Why wrong: This is incorrect because it swaps the intended primary and backup paths. The requirement specifies that the primary path goes through R2 with AD 1 and backup through R3 with AD 10. Changing the AD values would make R3 the primary, which is not desired.

Remove the existing IPv4 static default route and configure it with the next-hop as the exit interface (e.g., GigabitEthernet0/0) instead of the IP address. Then add IPv6 default routes using the exit interface as well.

Why wrong: This is incorrect because using an exit interface for a static route (point-to-point) is valid, but it does not fix the recursive routing failure if the next-hop IP is unreachable. The issue is likely that the next-hop IP is not in the routing table; using the interface might bypass the recursive lookup but would still require the interface to be up. However, the requirement specifies using next-hop IP addresses, and the IPv6 routes also need next-hop IPs. Moreover, the problem statement indicates the next-hop is 10.0.0.2, which should be directly connected; using the interface is not necessary and may not match the intended design.

R1(config-if)# ipv6 address fe80::/10 eui-64 R1(config-if)# ipv6 address 2001:db8:1::/64 eui-64 R1(config-if)# no shutdown

Why wrong: This is incorrect because the link-local address cannot be manually configured with the eui-64 keyword in this manner; it is automatically generated by the ipv6 enable command. The command ipv6 address fe80::/10 eui-64 is not valid for link-local addresses.

R1(config-if)# ipv6 address 2001:db8:1::/64 eui-64 R1(config-if)# no shutdown

Why wrong: This is incorrect because without the ipv6 enable command, the interface will not generate a link-local address, which is required for IPv6 operation. The global unicast address alone does not enable IPv6 on the interface.

R1(config-if)# ipv6 enable R1(config-if)# ipv6 address 2001:db8:1::1/64 R1(config-if)# no shutdown

Why wrong: This is incorrect because the global unicast address is configured with a static interface ID (::1) instead of using EUI-64 as required by the question. The question specifies the use of EUI-64 for the global unicast address.

Change the native VLAN on R1's trunk interface to 99, correct the encapsulation on G0/0.20 to dot1Q 20, but do not enable IP routing because it is enabled by default.

Why wrong: This is incorrect because IP routing is not enabled by default on Cisco routers; it must be explicitly configured with the 'ip routing' command. Without it, the router cannot forward packets between subinterfaces.

Change the native VLAN on R1's trunk interface to 1, correct the encapsulation on G0/0.20 to dot1Q 20, and enable IP routing globally.

Why wrong: This is incorrect because the native VLAN mismatch is not resolved; the switch expects native VLAN 99, not 1. The native VLAN must match on both ends of the trunk.

Change the native VLAN on R1's trunk interface to 99, correct the encapsulation on G0/0.10 to dot1Q 10, and enable IP routing globally.

Why wrong: This is incorrect because the encapsulation on G0/0.20 is still wrong; it should be dot1Q 20, not dot1Q 10. The subinterface for VLAN 20 must use VLAN ID 20.

Change the WLAN security to WPA2-Personal, enable TKIP encryption, and set the radio policy to 5 GHz.

Why wrong: This is incorrect because the requirement specifies WPA3-Personal, not WPA2-Personal. WPA3 uses AES-CCMP, not TKIP, and TKIP is not supported with WPA3.

Change the WLAN security to WPA3-Personal, enable AES-CCMP, but leave the radio policy as 'All' (both 2.4 GHz and 5 GHz).

Why wrong: This is incorrect because the requirement specifies that the SSID should be for 5 GHz clients only. Leaving the radio policy as 'All' would allow 2.4 GHz clients to associate, which is not desired and could cause configuration issues.

Change the WLAN security to WPA3-Personal, enable AES-CCMP, set the radio policy to 5 GHz, but do not enable the WLAN after changes.

Why wrong: This is incorrect because the WLAN must be enabled after configuration changes for clients to associate. The command 'config wlan enable 1' is necessary to activate the WLAN.

Enter interface configuration mode and issue the 'speed 100' command to match the remote interface speed.

Why wrong: This is incorrect because the interface is administratively down, not a speed mismatch. Speed mismatches typically cause CRC errors or interface resets, not an administratively down state.

Enter interface configuration mode and issue the 'duplex full' command to force full-duplex operation.

Why wrong: This is incorrect because the interface is administratively down, not a duplex mismatch. Duplex mismatches typically cause high error rates and collisions, not an administratively down state.

Enter interface configuration mode and issue the 'no keepalive' command to disable keepalives.

Why wrong: This is incorrect because keepalive issues typically cause 'line protocol is down' while the interface remains up, not 'administratively down'. The output shows the interface is administratively down, which is a manual shutdown.

ip route 192.168.100.0 255.255.255.0 10.0.0.2

Why wrong: This is incorrect because it uses a /24 mask instead of /32. The loopback0 address is a single host (192.168.100.1/32), not a full subnet. Using a /24 mask would incorrectly assume a larger network.

ip route 192.168.100.1 255.255.255.255 192.168.1.1

Why wrong: This is incorrect because the next-hop IP address 192.168.1.1 is not on a directly connected network of R1. The next hop must be reachable via a directly connected interface; 192.168.1.1 is not a neighbor on any of R1's interfaces.

ip route 0.0.0.0 0.0.0.0 10.0.0.2

Why wrong: This is a default route, which would send all traffic with no more specific match to 10.0.0.2. While it would work for reaching 192.168.100.1, it is not the most specific or correct solution for the requirement. The question asks to configure R1 to reach the loopback address, implying a specific route, not a default.

Configure 'ip domain lookup' to enable DNS resolution on the switch.

Why wrong: This is incorrect because 'ip domain lookup' is already enabled; the issue is the missing name-server entry, not the lookup feature itself.

Change the 'ip domain name' to 'courseiva.local' to match the hostname being resolved.

Why wrong: This is incorrect because the 'ip domain name' is already set correctly to 'courseiva.local'. The issue is not the domain name but the missing name-server entry.

Use 'debug ip dns' to monitor DNS queries and identify the problem.

Why wrong: This is incorrect because while debugging can help identify issues, it does not fix the missing name-server configuration. The root cause is the empty name-server list, which requires re-entering the command.

Change the duplex to full and speed to 1000 Mbps manually, and keep the existing SFP.

Why wrong: This is incorrect because manually setting speed and duplex disables auto-negotiation, which can still cause mismatch if the remote end is set differently. Moreover, the existing SFP is rated for only 10 km, not the required 40 km, so it must be replaced.

Keep the manual speed/duplex settings but replace the SFP with a 1000BASE-SX module.

Why wrong: This is incorrect because keeping manual settings does not resolve the mismatch; the link partner likely uses auto-negotiation or different settings. Also, 1000BASE-SX is designed for multimode fiber (up to 550 m), not single-mode fiber, and cannot support 40 km.

Enable auto-negotiation on both ends but keep the existing SFP.

Why wrong: This is incorrect because while enabling auto-negotiation fixes the speed/duplex mismatch, the existing SFP is rated for only 10 km, which does not meet the 40 km requirement. The SFP must be replaced.

Change the AD of the static route via 192.0.2.2 to 200 and the AD of the route via 198.51.100.2 to 1.

Why wrong: This is incorrect because it suggests modifying both routes, but the primary route already has AD 1 (default) and the backup has AD 1 as well; the fix is to increase the backup's AD, not change the primary's.

Add a static route to 192.168.10.0/24 via 192.0.2.2 with AD 1 and remove the existing route via 198.51.100.2.

Why wrong: This removes the backup route entirely, which eliminates redundancy. The requirement is for automatic failover, not removal of the backup.

Configure a policy-based route to prefer the next-hop 192.0.2.2 for traffic to 192.168.10.0/24.

Why wrong: Policy-based routing (PBR) is not the standard solution for simple primary/backup path selection; static route AD manipulation is the correct method.

from netmiko import ConnectHandler connection = ConnectHandler(device_type='cisco_ios', ip='192.168.1.1', username='admin', password='cisco') connection.send_command('copy running-config tftp://192.168.1.100/r1-config') connection.disconnect()

Why wrong: This is incorrect because it does not handle the interactive confirmation prompt that the 'copy' command generates. The script will send the command but will not respond to the '[confirm]' prompt, causing the operation to hang or fail.

from netmiko import ConnectHandler connection = ConnectHandler(device_type='cisco_ios', ip='192.168.1.1', username='admin', password='cisco') connection.send_command('copy running-config tftp://192.168.1.100/r1-config', expect_string=r'#')

Why wrong: This is incorrect because the 'expect_string' is set to the router's prompt ('#'), but the 'copy' command will first display a confirmation prompt, not the router prompt. The script will not wait for the confirmation and may send subsequent commands prematurely.

from netmiko import ConnectHandler connection = ConnectHandler(device_type='cisco_ios', ip='192.168.1.1', username='admin', password='cisco') connection.send_command('copy running-config tftp://192.168.1.100/r1-config\n') connection.disconnect()

Why wrong: This is incorrect because appending '\n' to the command string does not properly handle the interactive prompt. The 'send_command' method will send the newline as part of the command, but the device will still prompt for confirmation, and the script will not respond to it.

The EtherChannel will form successfully because LACP active mode negotiates the channel regardless of speed/duplex or VLAN differences.

Why wrong: This is incorrect because LACP does not override speed/duplex or VLAN mismatches; these must match on all member interfaces for the channel to form.

The EtherChannel will not form because the port-channel interface must be configured with the same VLAN as the physical interfaces, but the physical interfaces can have different speeds.

Why wrong: This is incorrect because speed must match on all physical interfaces; different speeds prevent the channel from forming.

The EtherChannel will form successfully because the port-channel interface inherits the VLAN from the first physical interface added, so no additional configuration is needed.

Why wrong: This is incorrect because the port-channel interface does not automatically inherit VLAN settings; it must be explicitly configured, and all physical interfaces must have matching VLANs.

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.

snmp-server community NetOpsRO ro snmp-server user AdminUser v3 auth sha AuthPass1 priv aes 128 PrivPass2 snmp-server enable traps snmp-server host 192.0.2.10 TrapComm flow exporter EXPORTER destination 192.0.2.20 version 9 ! interface GigabitEthernet0/0 ip flow export EXPORTER

Why wrong: This is incorrect because the SNMPv3 user is created without a group, which is required for authentication and privacy privileges. Also, 'ip flow export' is not a valid interface command; the correct command is 'ip flow monitor' referencing a flow monitor that uses the exporter.

snmp-server community NetOpsRO ro snmp-server group AdminGroup v3 priv snmp-server user AdminUser AdminGroup v3 auth sha AuthPass1 priv aes 128 PrivPass2 snmp-server enable traps snmp-server host 192.0.2.10 version 2c TrapComm flow exporter EXPORTER destination 192.0.2.20 version 9 ! interface GigabitEthernet0/0 ip flow monitor FLOW-MONITOR input

Why wrong: This is incorrect because the 'snmp-server host' command includes 'version 2c', which forces traps to be sent using SNMPv2c with the community string. However, the trap community 'TrapComm' is specified, but the command syntax is correct; the error is that the trap destination should not specify version 2c if the community is intended for v2c traps, but the question does not specify version, so it's acceptable. Actually, the main error is missing the flow exporter reference in the flow monitor; the flow monitor must be configured with the exporter. The given config does not show the flow monitor configuration.

snmp-server community NetOpsRO ro snmp-server group AdminGroup v3 priv snmp-server user AdminUser AdminGroup v3 auth sha AuthPass1 priv aes 128 PrivPass2 snmp-server enable traps snmp-server host 192.0.2.10 TrapComm flow exporter EXPORTER destination 192.0.2.20 version 9 ! interface GigabitEthernet0/0 ip flow monitor FLOW-MONITOR input flow monitor FLOW-MONITOR exporter EXPORTER

Why wrong: This is incorrect because the flow monitor configuration is placed after the interface command, which is out of order. The flow monitor must be configured before it is applied to the interface. Additionally, the 'flow monitor' command should be in global configuration mode, not after the interface command.

interface range g0/1-2 channel-group 1 mode desirable

Why wrong: This is incorrect because 'mode desirable' is a PAgP (Cisco proprietary) parameter, not LACP. The question specifies LACP, so this command would use PAgP instead.

interface g0/1 channel-group 1 mode active interface g0/2 channel-group 1 mode passive

Why wrong: This is incorrect because both ports must use the same LACP mode to form a channel. Mixing 'active' and 'passive' on the same switch will not work; LACP requires consistent mode on both ends.

interface port-channel 1 channel-group 1 mode active

Why wrong: This is incorrect because the 'channel-group' command is applied on physical interfaces, not on the port-channel interface. The port-channel interface is created automatically after the channel-group command is applied to physical ports.

Configure 'aaa authentication login default local' and add the RADIUS server with 'radius-server host 192.0.2.10 key cisco123'.

Why wrong: This is incorrect because the authentication list uses only local authentication, not RADIUS first. The RADIUS server is configured but never referenced in the authentication list, so RADIUS is not used.

Enable AAA with 'aaa new-model' and configure 'aaa authentication login default group radius' without local fallback.

Why wrong: This is incorrect because there is no local fallback; if the RADIUS server is unreachable, authentication fails entirely. The requirement specifies local fallback.

Configure 'aaa new-model', then apply 'dot1x system-auth-control' and 'aaa authentication dot1x default group radius'.

Why wrong: This is incorrect because the question asks for default login authentication, not dot1x authentication. The 'aaa authentication login' command is for login (management access), while 'aaa authentication dot1x' is for 802.1X port authentication. The problem is about login authentication, not dot1x authentication list.

snmp-server community public snmp-server community private snmp-server user admin v3 auth md5 Cisco123 priv des56 Cisco456 snmp-server enable traps snmp-server host 203.0.113.10 version 2c public snmp-server host 203.0.113.10 version 3 auth admin ip flow-export destination 203.0.113.20 2055 ip flow-export version 9

Why wrong: This configuration is incorrect because it uses MD5 instead of SHA for SNMPv3 authentication and DES instead of AES 128 for encryption. Additionally, the community strings lack the RO and RW keywords, which are required to specify access levels.

snmp-server community public RO snmp-server community private RW snmp-server user admin v3 auth sha Cisco123 priv aes 128 Cisco456 snmp-server enable traps snmp-server host 203.0.113.10 version 2c private snmp-server host 203.0.113.10 version 3 auth admin ip flow-export destination 203.0.113.20 2055 ip flow-export version 9

Why wrong: This configuration incorrectly uses the private community string for the v2c trap host. The v2c trap host should use the read-only community string 'public' as specified in the question, not the read-write 'private'.

snmp-server community public RO snmp-server community private RW snmp-server user admin v3 auth sha Cisco123 priv aes 128 Cisco456 snmp-server enable traps snmp-server host 203.0.113.10 version 2c public snmp-server host 203.0.113.10 version 3 auth admin ip flow-export destination 203.0.113.20 2055 ip flow-export version 5

Why wrong: This configuration incorrectly uses NetFlow version 5 instead of version 9. The question explicitly requires version 9, which supports templates and is more flexible than the older version 5.

snmp-server host 10.1.1.200 version 2c private snmp-server enable traps ip flow-export destination 10.1.1.100 2055 version 9 ip flow-export source Loopback0 interface GigabitEthernet0/0 ip flow egress

Why wrong: This configuration is incorrect because the trap destination is set to the NetFlow collector (10.1.1.200) instead of the management server (10.1.1.100), and the NetFlow export destination is set to the management server instead of the collector. Additionally, NetFlow should be configured as ingress, not egress.

snmp-server host 10.1.1.100 version 2c private snmp-server enable traps ip flow-export destination 10.1.1.200 2055 version 9 ip flow-export source Loopback0 interface GigabitEthernet0/0 ip flow ingress

Why wrong: This configuration uses the read-write community string 'private' for SNMP traps instead of the read-only 'public'. While the trap destination and NetFlow settings are correct, the community string must match the read-only community for traps.

snmp-server host 10.1.1.100 version 2c public snmp-server enable traps snmp linkdown linkup ip flow-export destination 10.1.1.200 2055 version 5 ip flow-export source Loopback0 interface GigabitEthernet0/0 ip flow ingress

Why wrong: This configuration uses NetFlow version 5 instead of version 9. The question explicitly requires version 9. All other settings are correct.