Router R1 Cannot Reach R3 Practice Questions

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.

Convert all inside hosts to the same private IP address.

Why wrong: This is wrong because PAT does not require all inside hosts to use the same private address.

Increase the size of the NAT pool to include multiple public addresses.

Why wrong: This is wrong because disabling the default route would break Internet access rather than improve PAT.

Configure static NAT mappings for each inside host.

Why wrong: This is wrong because switchport trunking does not create PAT behavior.

The OSPFv3 process ID must match on both routers.

Why wrong: OSPFv3 process IDs are locally significant and do not need to match for adjacency to form.

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

Why wrong: Link-local addresses are only used for neighbor discovery and do not require subnet matching; they are always on the same link.

The router ID 1.1.1.1 is duplicated on R2.

Why wrong: Duplicate router IDs can cause issues, but the 'show ospfv3 neighbor' output would typically show the neighbor in EXSTART or EXCHANGE state, not missing entirely.

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.

The routers need matching hostnames before OSPFv3 can start.

Why wrong: This is wrong because hostnames do not determine OSPFv3 adjacency formation.

IPv6 requires a /64 only for routing protocols to function.

Why wrong: This is wrong because the specific adjacency issue here is best explained by a protocol mismatch, not a blanket statement about all IPv6 routing.

OSPFv3 cannot run on directly connected interfaces.

Why wrong: This is wrong because OSPFv3 is designed to run on directly connected interfaces.

The NAT pool is exhausted because it contains only 21 addresses, and more than 21 internal hosts are trying to access the Internet simultaneously.

Why wrong: While pool exhaustion is possible, the output shows many translations already, and the symptom is that external hosts cannot initiate connections—a problem that would persist even with a larger pool if overload is not used.

The inside local addresses are not in the same subnet as the inside interface, causing asymmetric routing.

Why wrong: The inside local addresses (192.168.1.x) are typical private IPs and are assumed to be correctly configured on the inside interface. The translations show them mapping to public IPs, so routing is likely symmetric.

The outside global addresses are not routable on the Internet, so external hosts cannot send return traffic.

Why wrong: The public IPs shown (203.0.113.x) are from the TEST-NET-3 range, which is not globally routable. However, this is a common documentation range used in examples; in a real network, these would be replaced with routable IPs. The question assumes they are routable for the scenario.

The workstation has a duplicate IP address on the network.

Why wrong: A duplicate IP address would cause intermittent connectivity or inability to ping the gateway, but here the user can successfully ping the default gateway, ruling out a duplicate IP conflict.

The workstation is connected to the wrong VLAN.

Why wrong: Being on the wrong VLAN would likely prevent the workstation from reaching the default gateway entirely, as the gateway is typically on the same VLAN. Since the user can ping the gateway, the VLAN assignment is likely correct.

The workstation has a DNS misconfiguration.

Why wrong: DNS misconfiguration would affect name resolution, not the ability to ping an IP address directly. Since the user fails to ping 8.8.8.8 (an IP), DNS is not the cause.

The routers are in different OSPF areas.

Why wrong: This is wrong because both routers place the subnet into area 0.

The routers need identical hostnames before adjacency can form.

Why wrong: This is wrong because hostnames do not determine OSPF adjacency.

The subnet mask prevents OSPF multicast traffic.

Why wrong: This is wrong because the /24 mask does not block OSPF multicast here.

The static route will be preferred because static routes always beat dynamic routes.

Why wrong: Only if the static route has a lower AD than the competing routes.

RIP wins because its metric is lower than OSPF cost.

Why wrong: Different routing protocols are compared by AD first, not by their internal metrics.

All three routes should load-balance because the prefix length is the same.

Why wrong: Equal prefix length alone is not enough; the route source and attributes do not match for ECMP here.

The static route for 10.10.20.0/24 is missing from the routing table.

Why wrong: The exhibit shows that a static route to 10.10.20.0/24 via 10.10.10.2 is present in the routing table.

The GigabitEthernet0/0 interface is administratively down.

Why wrong: The interface is shown as directly connected with a local address, indicating it is up and operational.

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

Why wrong: The output shows 'Gateway of last resort is 10.10.10.2 to network 0.0.0.0', meaning the default route is present.

The floating static route is missing from the configuration.

Why wrong: The exhibit shows the static route is configured.

The administrative distance of the static route is too high.

Why wrong: An AD of 200 is correct for a floating static route to act as a backup to OSPF (AD 110).

The default route is overriding the static route to 10.10.10.0/24.

Why wrong: The default route is for 0.0.0.0/0 and does not affect the more specific route to 10.10.10.0/24.

STP is blocking the host because its MAC address changed.

Why wrong: This is wrong because STP does not block hosts for changing IP settings.

OSPF authentication failed on the access port.

Why wrong: This is wrong because OSPF is not the issue in a host ARP validation scenario.

The switch requires PPP authentication before allowing ARP traffic.

Why wrong: This is wrong because PPP authentication is unrelated to switched ARP inspection.

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.

Duplicate default routes on both routers

Why wrong: This is wrong because the issue described is neighbor formation, not route selection involving default routes.

Missing VLAN trunking on the link

Why wrong: This is wrong because the interfaces shown are routed OSPF interfaces, not switch trunks.

The OSPF process IDs are required to match

Why wrong: This is wrong because OSPF process IDs are locally significant.