OSPF Troubleshooting Scenarios

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.

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.

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.

The routers need global unicast addresses before OSPFv3 can run.

Why wrong: OSPFv3's transport is based on IPv6 link-local addresses; it does not require global unicast addresses to establish the neighbor state. The OSPFv3 Hello protocol uses link-local destinations (FF02::5) and source addresses, so the adjacency can form even if global addresses are absent or not yet assigned. Global addresses are only necessary for external route advertisement or certain network designs, not for basic neighbor formation.

The router IDs must be identical before adjacency can form.

Why wrong: OSPFv3 requires each router to have a unique 32-bit Router ID, typically derived from an IPv4 address, to identify itself in the routing domain. If two routers had identical Router IDs, the adjacency would not form correctly; instead, it would cause a conflict and one of them would be rejected. The actual requirement is that Router IDs are unique, not identical, for a neighbor relationship to succeed.

The link-local addresses must be learned from DHCPv6.

Why wrong: IPv6 link-local addresses (FE80::/10) are automatically configured on every interface using EUI-64 or random generation, independent of DHCPv6. OSPFv3 uses these link-local addresses as the source for Hello packets and routing updates, so no DHCPv6 involvement is needed for adjacency formation. Even if DHCPv6 were used for other address assignment, it is irrelevant to the OSPFv3 neighbor process.

The OSPF route because metric 20 is lower than 30720

Why wrong: Comparing OSPF's metric of 20 to EIGRP's feasible distance of 30720 is invalid because each routing protocol uses a completely different metric calculation. OSPF calculates cost from interface bandwidth, whereas EIGRP uses a composite formula based on bandwidth and delay, so these numbers are not directly comparable. The router does not attempt to compare metrics across protocols; it first selects the route with the lowest administrative distance. Since EIGRP's AD of 90 is lower than OSPF's 110, the metric values are irrelevant to the final decision.

Both routes because ECMP is automatic across different protocols

Why wrong: Equal-cost multipath (ECMP) only applies when multiple routes have the same metric and are learned from the same routing protocol. Here, OSPF and EIGRP are different protocols with different administrative distances, so the router will not consider them for load balancing. Only the single route with the lowest AD is installed in the routing table, and traffic is forwarded along that one path. ECMP cannot occur across different protocols because they are not evaluated on an equal footing.

Neither route until one is redistributed into the other protocol

Why wrong: Redistribution is not required for a router to install a route learned via OSPF or EIGRP; each protocol independently builds its IP routing table and selects its best route. Redistribution is only used when injecting routes from one routing protocol into another for downstream routers, but it has no bearing on which of the two current routes is chosen for this router. The router simply compares the administrative distance of the two protocols and installs the one with the lower AD. Therefore, route installation and redistribution are separate processes.

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.

The static route because static routes always win over dynamic routes

Why wrong: A static route does not automatically override a dynamic route. The router compares administrative distance, and the default static route AD is 1, but a floating static route is deliberately set with a higher AD (e.g., 130) so that it yields to a more preferred dynamic route like OSPF (AD 110). Static routes only win when their AD is lower than the competing route's AD.

Both routes because the prefix length matches

Why wrong: Even when two routes share the same prefix length, the router installs only the single best route in the routing table. Route selection depends primarily on administrative distance, not just the subnet mask. Since the OSPF route has a lower AD than the floating static route, the router ignores the static route for this prefix and does not install both; both routes would be installed only if they had the same AD and metric.

Neither route until equal-cost load balancing is configured

Why wrong: Equal-cost load balancing requires two or more routes to the same destination with identical administrative distance and identical metric. Here the OSPF route and the floating static route have different ADs (110 vs. 130), so they are not equal-cost candidates. The router does not wait for load balancing to be configured; it immediately selects the OSPF route as the best path.

The OSPF 10.1.1.0/24 route

Why wrong: The OSPF route 10.1.1.0/24 does match the destination, but it describes a broader range of 256 addresses, whereas the static 10.1.1.128/25 describes a narrower range of 128 addresses that still includes the target. Longest-prefix match dictates that the more specific /25 route is preferred over the /24, regardless of the administrative distance or protocol; therefore, the OSPF route is not the one that gets used.

The default route

Why wrong: A default route is the ultimate prefix-length of 0.0.0.0/0, the least specific of all possible routes. In the routing table, it is used only when no other route matches the destination; because the /25 and /24 routes both match 10.1.1.130, the default route is never consulted, and even if it were, the /25's longer prefix would still take precedence.

The router load-balances across all three

Why wrong: Load balancing across equal-cost paths only applies to multiple routes that share the exact same prefix length and destination network. Here, the three candidates are 10.1.1.0/24, 10.1.1.128/25, and 0.0.0.0/0, each with a different prefix length, so they are not competing equal-cost routes; longest-prefix match selects exactly one route, so the router does not distribute the packet across them.

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.

They must have identical router IDs.

Why wrong: Each OSPF router must have a unique Router ID (RID), typically the highest loopback or active interface IP address, because the RID is the primary key for OSPF neighbor and database descriptions. If two routers share the same RID, they will reject each other as duplicates, causing the neighbor relationship to flap or never establish. Identical RIDs are therefore invalid and harmful, not a requirement.

They must use the same process ID number on both routers.

Why wrong: The OSPF process ID is a purely local parameter used to distinguish multiple OSPF processes running on the same router; it is not transmitted in any OSPF packet. Since hello, database descriptor, and link-state packets contain no process ID field, two routers can have completely different process IDs and still form a full adjacency. This makes the process ID irrelevant to neighbor requirements, unlike the area ID or subnet masking.

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.