Show IP Route practice questions

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.

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.

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.

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.

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.

An OSPF area mismatch

Why wrong: An OSPF area mismatch on the shared link would prevent R2 from even establishing a stable two-way relationship with R1, because the Area ID field in Hello packets would not match the configured area on the interface. The routers would typically become stuck in the INIT or DOWN state, or the Hello packets would be ignored entirely, rather than advancing to the EXSTART state. Since EXSTART is a state reached only after the routers have exchanged Hello packets and formed a neighbor relationship, an area mismatch would block the process earlier in the neighbor state machine.

A duplicate router ID on R1 and R2

Why wrong: A duplicate Router ID would cause each router to mistakenly interpret the other's Hello as coming from itself, triggering an immediate rejection of the adjacency and potential routing table flapping. While this could cause the neighbor state to oscillate, it would not normally leave the session permanently in EXSTART, as the duplicate ID is typically detected and the adjacency is torn down before the Database Descriptor exchange completes. The fact that R1 and R2 are specifically stuck in EXSTART on a single link points to a packet-level size or delivery issue, not a Router ID conflict.

A missing default route on R2

Why wrong: A missing default route on R2 is a routing information condition that has no bearing on the OSPF adjacency state machine, which governs only the exchange of Hello, Database Descriptor, and Link-State Request/Update packets. OSPF neighbors form adjacencies regardless of whether a default route exists in the routing table, as adjacency establishment is a prerequisite for exchanging routes in the first place. Therefore, the absence of a default route would not cause R2 to halt at EXSTART with R1.

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.

The OSPFv3 process ID must match on both routers.

Why wrong: OSPFv3 process IDs are only meaningful on the local router and do not influence the OSPFv3 neighbor relationship. Each router can run a different process ID number as long as the interface has been enabled for OSPFv3 in the same IPv6 area. Neighborship depends on stable parameters such as area ID, hello/dead timers, and MTU, not on the process ID. Therefore, a mismatch would not prevent R1 from seeing R2 in the neighbor table.

The link-local addresses are not in the same subnet.

Why wrong: ICMPv6 and OSPFv3 use link-local addresses (fe80::/10) exclusively for neighbor discovery and for exchange of routing information on the local segment. These addresses are only required to be unique on the link, never globally or in the same subnet as the remote peer. Because both interfaces are on the same Ethernet segment, their link-local addresses are automatically valid for OSPFv3 communication. A subnet mismatch of link-local addresses is therefore impossible and cannot be the cause of a missing neighbor entry.

The router ID 1.1.1.1 is duplicated on R2.

Why wrong: If the router ID 1.1.1.1 were actually duplicated, the routers would still discover each other via Hello packets and move through OSPF state machine into EXSTART/EXCHANGE before the duplicate ID is detected and the adjacency is halted. The absence of any neighbor entry at all, rather than a stuck state, indicates that OSPFv3 packets are not being processed on the interface. Duplicate router IDs are also unlikely in this scenario because the question only shows a missing neighbor on R1, not a conflict log. So this is not the correct explanation.

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.

Generate a new RSA key pair and restart the SSH service.

Why wrong: Generating a new RSA key pair and restarting the SSH service is unrelated to the actual failure. The 'connection refused' occurs at the TCP/VTY layer because the VTY lines only permit Telnet ('transport input telnet'), so the router rejects the SSH handshake before any key-based authentication or encryption is negotiated. Even if the key pair is absent or stale, SSH would fail differently (e.g., 'no host key' or authentication errors), not with a transport-level refusal; regenerating keys does not modify the line's transport input policy.

Configure 'ip ssh version 1' to enable backward compatibility.

Why wrong: The router already runs SSH version 2, and version 1 is less secure and not required for compatibility. Changing the version does not override the VTY transport input restriction, so SSH connections will still be refused.

Configure AAA authentication on the VTY lines.

Why wrong: AAA authentication is not required for SSH to function; the router is already using local authentication (implied by the working Telnet). The refusal occurs before authentication, at the transport protocol layer, so adding AAA would not resolve the issue.

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.

The adjacency fails because the router-id 1.1.1.1 is not reachable from R2. Configure a static route for 1.1.1.1/32 on R2.

Why wrong: The OSPF router-id is simply a 32-bit identifier drawn from the highest loopback or configured manually; it is not an address that OSPF uses for packet forwarding. R2 does not need to have a route to 1.1.1.1/32 because OSPF neighbor packets are sourced from the physical interface IP address, not the router-id. Adding a static route for the router-id would have no effect on hello processing, and the real cause of the failure is R1's passive-interface command.

The adjacency fails because the subnet mask on the link is /30 but OSPF expects a /24. Change the mask to /24 on both interfaces.

Why wrong: This is incorrect because OSPF does not require a specific subnet mask; it can form adjacency over any mask as long as the interfaces are in the same subnet. A /30 is perfectly valid for point-to-point links.

The adjacency fails because OSPF is not enabled on R2's GigabitEthernet0/0 interface. Configure 'ip ospf 1 area 0' on R2's G0/0.

Why wrong: This is incorrect because the question implies both routers are configured for OSPF; the issue is specifically on R1's passive-interface. If OSPF were not enabled on R2's interface, there would be no hello packets at all, but the scenario shows R1 is not sending hellos.

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 fails because the SNMPv2c trap receiver at 203.0.113.10 is bound to the 'private' community string, which is the read-write (RW) community. The question explicitly requires a v2c trap host using the read-only (RO) community 'public' to match the monitoring station's read-only access. Sending traps with the RW community violates the least-privilege principle and would be rejected by a properly configured NMS that expects traps from the 'public' community. Additionally, specifying the v2c host with the wrong community string means the NMS may not authenticate the trap, so no alarms would be received.

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: The entire SNMP configuration is correct, including the v2c public trap host, v3 user 'admin' with SHA/AES-128, and the trap hosts, but NetFlow export is misconfigured by using version 5 instead of the required version 9. NetFlow version 5 does not support templates, so it cannot carry flexible field definitions or accommodate new flow record formats; version 9 is template-based and allows extensible, structured data export. The question explicitly mandates version 9 for the flow exporter, making version 5 an incorrect choice. Even though the destination 203.0.113.20 and port 2055 are correct, the wrong version breaks the expected flow data encoding and may be unreadable by the collector.

The static route, because static routes always override dynamic routes

Why wrong: Static routes do not automatically override dynamic routes; the default AD for a static route is 1, but an administrator can create a floating static route with a higher AD, as done here with 150. Because OSPF's AD is 110, which is lower than 150, the OSPF route wins the routing table selection, despite being dynamic. The statement 'static routes always override dynamic routes' is false because AD is a configurable priority, not an inherent property of the route type. In this scenario, the static route is just a backup and is not active.

Both routes load-balance automatically

Why wrong: Load balancing only occurs when multiple routes have exactly the same administrative distance and metric, and the routing protocol supports equal-cost multipath (ECMP). Here, the OSPF route has AD 110 while the floating static route has AD 150, so they are not equal-cost and the router will not load-balance across them. OSPF and static routes are different sources, and the router always prefers the lower AD route for the default prefix. Therefore, only one route is actually installed and used, not both.

Neither route, because a default route cannot be learned by OSPF

Why wrong: OSPF absolutely can learn and carry a default route; this is commonly done using the 'default-information originate' command on an ASBR, which injects 0.0.0.0/0 into the OSPF domain. The router in question has received an OSPF default route, so the premise that OSPF cannot learn a default route is false. Both routes exist, but due to AD differences, exactly one is selected as the active default. Thus, saying 'neither route' is incorrect because the router will use the OSPF path.

snmp-server community publicRW ro snmp-server user admin admin v3 auth md5 cisco123 priv des cisco456 snmp-server enable traps snmp linkdown linkup snmp-server host 192.0.2.100 traps version 2c publicRW ip flow-export destination 192.0.2.200 2055 ip flow-export version 9

Why wrong: This configuration is missing the 'ip flow ingress' command on an interface, which is required to enable NetFlow data collection. Without it, no flow records will be exported, and 'show ip cache flow' will show no entries.

snmp-server community publicRW ro snmp-server user admin admin v3 auth md5 cisco123 priv des cisco456 snmp-server enable traps snmp linkdown linkup snmp-server host 192.0.2.100 traps version 2c publicRW ip flow-export destination 192.0.2.200 2055 ip flow-export version 9 interface GigabitEthernet0/0 ip flow egress

Why wrong: This configuration uses 'ip flow egress' instead of 'ip flow ingress'. While egress flow monitoring is valid, the task does not specify direction; however, ingress is more commonly used and the verification command 'show ip cache flow' expects ingress flows by default. More importantly, the task requires NetFlow export to work, and using egress may not capture the desired traffic.

snmp-server community publicRW ro snmp-server user admin admin v3 auth md5 cisco123 priv des cisco456 snmp-server enable traps snmp linkdown linkup snmp-server host 192.0.2.100 traps version 2c publicRW ip flow-export destination 192.0.2.200 2055 ip flow-export version 9 interface GigabitEthernet0/0 ip flow monitor FLOW-MONITOR input

Why wrong: This configuration uses 'ip flow monitor' which is a newer Flexible NetFlow command, but the task requires traditional NetFlow (version 9). The 'ip flow monitor' command requires a flow monitor configuration that is not provided, and it does not work with 'ip flow-export version 9' in the same way. The correct command for traditional NetFlow is 'ip flow ingress'.

The IP addresses on the serial interfaces are in different subnets, so packets are dropped at Layer 3.

Why wrong: This scenario misdiagnoses a Layer 3 issue as the cause of a Layer 2 state. The line protocol status reflects the data-link layer's ability to exchange frames and keepalives; IP addressing and subnetting do not influence it. If the interfaces were in different subnets, pings would fail because each router would not consider the other as directly reachable, but the serial interface would still show 'up, line protocol up' because Layer 2 is healthy. Since the question states the line protocol is down, the root cause must be below Layer 3, so an IP subnet mismatch is an incorrect explanation.

The serial cable is faulty, causing physical layer issues that trigger the line protocol down state.

Why wrong: This option incorrectly assumes a physical-layer problem. An interface's status is shown as 'Serial0/0 is up, line protocol is down', which explicitly indicates that the physical layer is functioning: the router detects a carrier signal and the interface is administratively up. If the serial cable were faulty or disconnected, the interface would instead display 'Serial0/0 is down, line protocol is down' or 'is down' for both, because the physical layer would not be able to provide a signal. Thus, a faulty cable does not explain a scenario where only the line protocol is down while the physical layer is up.

The routers are missing a routing protocol configuration, so they cannot route traffic across the link.

Why wrong: The absence of a dynamic routing protocol is irrelevant to the line protocol state. On a directly connected serial link, each router automatically installs a connected route for the subnet as soon as the interface is up and has an IP address; this occurs without any routing protocol. Even if a routing protocol like OSPF or EIGRP were configured, it would be dependent on the underlying data-link layer being operational. Since the line protocol is down, the interface cannot pass traffic at all, so adding or omitting a routing protocol has no effect on the observed symptom. The real problem remains the Layer 2 encapsulation mismatch.

Because static routes cannot reference exit interfaces.

Why wrong: Static routes may legitimately reference an exit interface, such as ip route 10.200.0.0 255.255.0.0 GigabitEthernet0/0, which is a common and valid configuration for point-to-point links. The problem in the exhibit is not that the configuration uses an exit interface, but that the referenced interface has been administratively shut down. When the interface is down, the route is removed from the routing table, whereas a healthy interface would allow the static route to appear.

Because the destination must be a /24, not a /16.

Why wrong: The prefix length /16 is perfectly valid for a static route, and there is no Cisco IOS requirement that a destination be a /24. Static routes accept any legitimate IPv4 prefix, and subnetted networks can be summarized into larger blocks like /16. The exhibit shows the route missing because the outgoing interface is down, not because the mask is too short or unsupported.

Because static routes require NTP before installation.

Why wrong: Network Time Protocol (NTP) is used for clock synchronization and does not affect the Routing Information Base or the installation of static routes. A static route is evaluated based on the administrative distance, metric, and the reachability of the configured next hop or exit interface, not on any time-based condition. NTP misconfiguration could impact logging or certificate validation but will never prevent a valid static route from being installed.

The SSH server is not enabled because the crypto key is missing or 'ip ssh' is not configured.

Why wrong: This is incorrect because while missing crypto keys or 'ip ssh' configuration can prevent SSH, the primary issue is the VTY transport setting. The question states the script fails to connect, and the VTY lines are configured for telnet only, which directly blocks SSH.

The SSH version is set to version 1, which is not supported by the Python script.

Why wrong: This is incorrect because SSH version 1 is deprecated and insecure, but the question does not provide any evidence that version 1 is configured. The typical default is SSH version 2, and the script would likely support both.

The domain name is not configured, which is required for SSH key generation.

Why wrong: This is incorrect because while a domain name is needed for RSA key generation, the question does not indicate that keys are missing. The immediate problem is the VTY transport setting, not the absence of a domain name.

R1(config)# ipv6 unicast-routing R1(config)# ipv6 router ospf 100 R1(config-rtr)# router-id 1.1.1.1 R1(config-rtr)# network 2001:db8:12::0/64 area 0 R1(config-rtr)# network 2001:db8:1::0/64 area 0 R2(config)# ipv6 unicast-routing R2(config)# ipv6 router ospf 100 R2(config-rtr)# router-id 2.2.2.2 R2(config-rtr)# network 2001:db8:12::0/64 area 0 R2(config-rtr)# network 2001:db8:2::0/64 area 0

Why wrong: This configuration is incorrect because OSPFv3 on Cisco IOS does not use the IPv4-style 'network' command under router configuration mode; that command is only valid for OSPFv2. In OSPFv3, interfaces must be placed into the OSPF process individually using the interface-level 'ipv6 ospf 100 area 0' command. Since no interface is enabled for OSPFv3, the routers will not send or process OSPFv3 hello packets, and no adjacency or route exchange can occur.

R1(config)# ipv6 unicast-routing R1(config)# ipv6 router ospf 100 R1(config-rtr)# router-id 1.1.1.1 R1(config-rtr)# interface gigabitethernet0/0 R1(config-if)# ipv6 ospf 100 area 0 R2(config)# ipv6 unicast-routing R2(config)# ipv6 router ospf 100 R2(config-rtr)# router-id 2.2.2.2 R2(config-rtr)# interface gigabitethernet0/0 R2(config-if)# ipv6 ospf 100 area 0

Why wrong: This configuration is wrong because OSPFv3 is enabled only on the GigabitEthernet0/0 interfaces; the loopback0 interfaces are left out of the OSPFv3 process. Without the 'ipv6 ospf 100 area 0' command under loopback0, the loopback IPv6 prefixes are not advertised into OSPF, so R1 and R2 will not install each other's loopback routes in their routing tables. The GigabitEthernet link will form an adjacency, but the loopback networks will remain unreachable, failing the requirement.

R1(config)# ipv6 unicast-routing R1(config)# ipv6 router ospf 100 R1(config-rtr)# router-id 1.1.1.1 R1(config-rtr)# interface gigabitethernet0/0 R1(config-if)# ipv6 ospf 100 area 0 R1(config-if)# interface loopback0 R1(config-if)# ipv6 ospf 100 area 0 R2(config)# ipv6 unicast-routing R2(config)# ipv6 router ospf 100 R2(config-rtr)# router-id 1.1.1.1 R2(config-rtr)# interface gigabitethernet0/0 R2(config-if)# ipv6 ospf 100 area 0 R2(config-if)# interface loopback0 R2(config-if)# ipv6 ospf 100 area 0

Why wrong: Both routers have been configured with the identical router-ID 1.1.1.1, which is invalid for OSPFv3 because router-IDs must be unique throughout the OSPF routing domain. When a router receives a hello packet advertising the same router-ID it uses itself, it rejects the neighbor and will not form an adjacency. Consequently, no OSPF database synchronization occurs, and neither router learns the other's loopback or link prefixes, so traffic between the routers fails.

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: Simply adding a primary static route via 192.0.2.2 with AD 1 and removing the existing 198.51.100.2 route eliminates all redundancy. If the 192.0.2.2 next-hop fails, there is no backup route to 192.168.10.0/24, so traffic is dropped instead of automatically failing over. The requirement explicitly calls for automatic failover, which necessitates keeping a backup path with a higher AD. Removing the backup route defeats the entire purpose of floating static routes, making this option incorrect.

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 designed to steer traffic based on complex conditions like source addresses, packet sizes, or application protocols, not for simple primary/backup path selection. In contrast, floating static routes with differing AD values are the intended, low-overhead mechanism for basic failover to a single destination prefix. PBR would also require route-map and next-hop configuration that does not automatically track the reachability of the primary next-hop the same way as AD-based static route failover. Additionally, PBR adds CPU overhead and configuration complexity, whereas the scenario's goal is straightforward path redundancy, making static route AD manipulation the correct answer.