Router R1 Cannot Reach R3 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.

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.

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

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

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

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

Because the destination 198.51.100.70 is outside both listed routes.

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

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.

Set the interface network type to point-to-point

Why wrong: Setting the OSPF network type to point-to-point on the interface changes timer values and eliminates DR/BDR election, but Hellos are still sent periodically and the interface remains fully active in the OSPF process. Since the requirement is to prevent Hello transmission while still advertising the connected network, this does not satisfy it. The point-to-point type is appropriate for serial links but does not suppress adjacency formation.

Apply distribute-list out on the interface

Why wrong: A distribute-list out is used to filter routes from being advertised in routing updates, but OSPF does not use it to suppress Hellos; OSPF relies on the Hello protocol for neighbor discovery. This command operates on the routing table and redistributed routes, not on interface-level OSPF processes like Hello transmission. Thus, applying a distribute-list out on the interface has no bearing on whether the interface sends or receives Hellos.

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

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

Both routes are installed as equal-cost paths automatically

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

The path with the higher OSPF metric

Why wrong: Selecting the path with the higher OSPF metric would contradict OSPF's SPF calculation, which always chooses the least-cost path to a destination. A higher cost indicates a less desirable route, such as one traversing slower or more numerous links, and OSPF will never prefer it over a lower-cost alternative for the same prefix. The only time a higher-metric path is used is if the lower-metric path is absent from the routing table.

Both paths equally, because the administrative distance is the same

Why wrong: Administrative distance is a Cisco-specific trust rating assigned to the routing protocol as a whole, not a per-path metric for selecting among OSPF routes. When two OSPF paths to the same prefix have unequal metrics, the router compares the OSPF cost values directly, and the lower-cost path wins. Equal AD only means both routes are equally trusted as OSPF-learned; it does not enable load balancing, which would require the OSPF metrics to be exactly equal.

Neither path, because two OSPF routes to the same prefix are invalid

Why wrong: OSPF is fully capable of learning the same prefix through multiple paths, as occurs in redundant OSPF networks where the SPF algorithm evaluates all available routes. Having two OSPF routes to 10.10.10.0/24 is not invalid; rather, OSPF processes them and selects the one with the lowest metric for installation in the routing table, while potentially keeping equal-cost paths for ECMP. Discarding both routes would leave the network without a route, which OSPF would never do if any path exists.

A NAT rule translating IPv6 to IPv4

Why wrong: IPv6 was designed to restore end-to-end connectivity without relying on NAT; in normal native IPv6 environments, routing uses global unicast addresses directly. A NAT rule that translates IPv6 to IPv4 would be an unnecessary and complex workaround, and it would not help the host reach off-link IPv6 destinations unless that IPv4 path itself is routed. Since the host already reaches neighbors using IPv6, the missing element is not address translation but a route to a default gateway.

A VLAN trunk on the host NIC

Why wrong: VLAN trunking is a Layer 2 feature used to carry multiple VLANs over a single switch link, typically between switches or to a router-on-a-stick. An end host NIC rarely requires trunking, and the symptom described is unrelated to VLAN tagging because it concerns Layer 3 reachability. Even if the NIC were configured with a trunk, that would not provide a default route or next hop for off-link IPv6 packets.

A second global unicast address on the same interface

Why wrong: Adding a second global unicast address to the same interface only provides an additional source or destination identifier for that interface; it does not install any route or gateway information into the host's IPv6 routing table. The host still lacks a default route for off-link traffic, and the existing address already satisfies the requirement of having a valid IPv6 source address. Therefore, a duplicate address does not solve the described reachability problem.

The SSID broadcast setting, because the client must not be joined correctly.

Why wrong: The SSID broadcast setting only controls whether the network name appears in probe responses, not whether an already-associated client can send or receive traffic. Because the client successfully joined and pulled an address from the correct subnet, it is not a join failure. If broadcast were disabled, the client would still be able to connect if it manually knew the SSID, and would not explain an application-specific issue.

The voice VLAN on the wired access port connected to the AP uplink.

Why wrong: The voice VLAN on the wired access port is used to separate VoIP traffic from data traffic on the wired infrastructure, and it does not affect how a wireless client forwards traffic after joining a WLAN. A client that has already received an address from the correct subnet is clearly operating on the data VLAN, not the voice VLAN, and general employee access works correctly. Since the problem is restricted to one application, changing the voice VLAN setting on the AP uplink would have no bearing on this scenario.

The OSPF router ID on the client device.

Why wrong: OSPF router IDs are used by routers participating in OSPF to identify themselves in link-state advertisements; end-client devices such as laptops or phones do not run OSPF and never exchange routing protocol information with the network. A client's network stack obtains an address via DHCP and uses a default gateway for off-subnet traffic, so OSPF router ID is irrelevant. The application-specific failure cannot be caused by a parameter that does not exist on the client device.

The OSPF route, because dynamic routes always beat static routes

Why wrong: Dynamic routes do not automatically outrank static routes; that belief ignores how administrative distance works. Route preference is determined solely by the numeric administrative distance, not by whether the route was learned dynamically or configured manually. In this scenario, the static route's distance of 90 is lower than OSPF's 110, so the static route is more trusted. Therefore, OSPF is not installed because dynamic learning does not confer an inherent advantage.

Both routes equally, because the prefix is identical

Why wrong: Having the same prefix length does not mean both routes are equally preferred, because routes from different protocols are compared using administrative distance. OSPF's default administrative distance is 110, while this static route has a distance of 90. The router does not aggregate or load-balance across protocols; it installs only the route with the lower administrative distance. Thus the identical prefix length has no bearing on equality when the administrative distances differ.

Neither route, because duplicate information is dropped

Why wrong: Routers do not simply drop duplicate routing information; they perform a route-selection process. For the same destination prefix, the router compares administrative distances across different sources and installs the winning route in the forwarding table. The losing route remains in the originating protocol's database, not in the routing table. Therefore, duplicate information is not dropped; it is evaluated and only the best route is chosen.

Convert all inside hosts to the same private IP address.

Why wrong: Assigning every inside host the same private IP address would create Layer 3 addressing conflicts, breaking ARP and preventing any host from communicating on the LAN. PAT assumes each inside host retains its own unique private IPv4 address so the router can track individual sessions; the translation process then maps those unique local addresses to a shared public address with different port numbers. Thus, a common private IP is neither required nor usable.

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

Why wrong: Expanding the NAT pool to include more public addresses is characteristic of dynamic NAT or many-to-many translation, not of PAT. In PAT, even with a pool of addresses, the distinguishing mechanism is still the transport-layer port number, and the router will overload the available addresses by reusing them with different source ports. Simply adding more public IPs does not enable port-based session multiplexing, which is the core feature that PAT uses to handle many inside sessions.

Configure static NAT mappings for each inside host.

Why wrong: Configuring static NAT for each host requires a one-to-one mapping between an inside local address and an inside global address, meaning you need one public IPv4 address per host. That defeats the purpose of PAT, which is designed to conserve public address space by allowing many hosts to share a single outside address through port multiplexing. Static NAT also does not scale for even a small office and fails to provide the transport-layer port translation that PAT implements.

Default routes always override static routes.

Why wrong: Default routes (0.0.0.0/0) have the shortest prefix length (0 bits) and only match when no more specific route exists. A static route to 192.168.40.0/24 is more specific and, when valid, is always preferred over a default route because routers select the longest prefix match. Thus, default routes do not override static routes; they only act as a fallback, making this option wrong.

The destination must be configured as a /16, not a /24.

Why wrong: The /24 mask in the static route correctly identifies the 192.168.40.0/24 subnet that contains 192.168.40.200; changing it to a /16 would broaden the matched range to 192.168.0.0/16 but would not fix next-hop reachability. The prefix length affects which destinations match the route, not whether the next hop is reachable. Since the problem is an unreachable next hop, not an incorrect mask, this option is incorrect.

Static routes can be used only if OSPF is disabled.

Why wrong: Static routes are independent of the routing protocol in use; OSPF can run concurrently with static routes and does not inhibit their installation. A static route is installed when it satisfies administrative distance and next-hop reachability criteria, regardless of whether OSPF is enabled or disabled. Disabling OSPF would not make an otherwise valid static route usable, so this statement is incorrect.

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.