OSPF Troubleshooting Scenarios

90

Why it fails: 90 is the default administrative distance for EIGRP internal routes, not OSPF. It is tempting because both are interior gateway protocols, but OSPF's default sits at 110, so this value would misrepresent OSPF in route selection.

100

Why it fails: 100 is the default administrative distance for IGRP, a legacy protocol, not OSPF. It is tempting because it sits close to OSPF's real value, but OSPF defaults to 110 on Cisco IOS-XE, so this figure is wrong.

120

Why it fails: 120 is the default administrative distance for RIP, not OSPF. OSPF's default is 110. The value 120 is correct when the question asks about RIP routes on a Cisco IOS-XE router, so it fails this OSPF-specific scenario.

The router is load-balancing between OSPF and EIGRP routes.

Why it fails: EIGRP's administrative distance of 90 beats OSPF's 110, so the OSPF route is deleted and only the EIGRP path remains installed. Load-balancing requires equal-cost paths from the same or configured sources; unequal distances prevent it. This debug would show two inserts only if both protocols had matching distances.

The OSPF route is preferred due to lower metric.

Why it fails: Administrative distance, not metric, decides here: EIGRP's 90 beats OSPF's 110, so the OSPF route is deleted despite its lower metric of 20. Metric comparison is the correct tie-breaker only when both routes come from the same protocol.

Both routes are installed in the routing table.

Why it fails: The OSPF entry is deleted after the EIGRP insert, leaving only the EIGRP path; the table holds one route, not two. It is tempting because both protocols initially inserted the prefix, but administrative distance resolves the conflict in EIGRP's favour.

OSPF adjacency is forming correctly, moving to FULL state.

Why it fails: The debug shows EXSTART with the neighbour reporting a larger interface MTU, so the adjacency stalls rather than reaching FULL; mismatched MTU blocks DBD exchange. This output would indicate healthy progression only if both interfaces shared identical MTU values and the state advanced past EXSTART.

OSPF adjacency is stuck because the router is not the DR/BDR.

Why it fails: DR/BDR status is irrelevant to EXSTART; the debug shows the neighbour has a larger interface MTU, so the master/slave negotiation stalls and DBD exchange cannot proceed. DR/BDR election occurs after two-way and does not block adjacency formation at EXSTART.

OSPF adjacency is stuck due to authentication mismatch.

Why it fails: The debug shows the neighbour reaching EXSTART then reporting a larger interface MTU, so the stuck adjacency stems from an MTU mismatch, not authentication. Authentication failures halt OSPF earlier, during hello exchange, producing 'authentication failure' messages; that is the scenario where this diagnosis would apply.

It sets the administrative distance for OSPF routes to 150, but only for intra-area routes.

Why it fails: The distance 150 command applies to all OSPF routes regardless of area type, not only intra-area routes; intra-area distance is set with distance ospf intra-area. It is tempting because OSPF supports separate administrative distances per route type, but the bare distance command sets the default for every OSPF route.

It sets the administrative distance for OSPF external routes to 150.

Why it fails: The distance 150 command sets the administrative distance for all OSPF routes, not only external ones; external routes are controlled with distance ospf external. It is tempting because OSPF does allow separate distances for external routes, but that requires the external keyword, which is absent here.

It sets the administrative distance for OSPF routes to 150, but only for routes learned from a specific neighbor.

Why it fails: The distance command under router ospf sets a default administrative distance for all OSPF routes, not a per-neighbour value; neighbour-specific distance requires the distance ospf neighbour syntax. It is tempting because OSPF does support per-neighbour administrative distance, but that needs the explicit neighbour keyword.

OSPF will fail because the OSPF process must be configured globally, not under the VRF.

Why it fails: Cisco IOS supports per-VRF OSPF processes through the 'router ospf <id> vrf <name>' syntax, so the process starts normally within CUSTOMER_D. It is tempting because OSPF is often described as a global routing process, yet VRF-aware OSPF is standard for MPLS L3VPN customers.

OSPF will run on all interfaces, including those not in VRF CUSTOMER_D.

Why it fails: The 'router ospf 1 vrf CUSTOMER_D' command scopes the process to that VRF, so only interfaces assigned to CUSTOMER_D participate; interfaces outside it are excluded. It is tempting because a global 'router ospf 1' without the vrf keyword would indeed run OSPF on all non-VRF interfaces.

The network command is invalid because it uses a wildcard mask instead of a subnet mask.

Why it fails: OSPF network statements require wildcard masks, and 0.0.0.255 is a valid wildcard matching 192.168.2.0/24, so the command is accepted. It is tempting because wildcard masks look inverted relative to subnet masks, but OSPF has always used this format.

Auto-summary is enabled by default

Why it fails: OSPF auto-summary is disabled by default on Cisco IOS-XE, so no summarisation of redistributed routes occurs unless configured. It tempts because RIP and EIGRP historically enabled auto-summary by default, leading engineers to assume the same classful behaviour applies to OSPF.

Auto-summary is only enabled for external routes

Why it fails: Auto-summary is disabled by default for all OSPF routes, external included, so no automatic classful summarisation happens unless explicitly configured. It tempts because external routes redistributed into OSPF are the ones summarisation typically targets, but the default remains off regardless of route type.

Auto-summary is enabled only for inter-area routes

Why it fails: OSPF auto-summary applies only to redistributed routes on an ASBR, not to inter-area routes, which are summarised manually with area range. The option is tempting because area range does summarise inter-area prefixes, but that is a separate command, and auto-summary defaults to disabled on IOS-XE.

Configure `ip ospf database-filter all out` on the hub tunnel interface to suppress individual LSAs and allow the summary to propagate.

Why it fails: The `database-filter` command blocks LSA flooding on an interface but does not create summary LSAs. It would prevent spoke routes from being advertised at all, not summarize them. Summarization is an ABR function configured with `area range`, so this command cannot achieve the desired single-prefix advertisement.

Configure the `area 0 range 10.10.0.0 255.255.255.0` command on the hub router's tunnel interface instead of the global OSPF process.

Why it fails: The `area range` command is entered under the OSPF routing process, not on an interface. Placing it under the tunnel interface is invalid syntax and would be rejected. Interface-level OSPF commands control timers, authentication, and network type, but not inter-area summarization. This action cannot produce the required summary LSA.

Change the OSPF network type on the hub tunnel interface to point-to-multipoint and reapply the `area 0 range` command.

Why it fails: Changing the network type affects neighbor formation and next-hop behavior but does not enable summarization. Summarization requires the router to be an ABR for the area containing the routes. The network type is irrelevant to the ABR requirement, so this action leaves the underlying problem unresolved and spoke routes remain individual.

The OSPF route is a type 5 LSA, which has a higher AD than type 3 LSAs.

Why it fails: LSA type does not set administrative distance; OSPF's AD of 110 applies to all OSPF-learned routes regardless of LSA type. Type 5 LSAs carry external prefixes, but that does not raise their AD above EIGRP external's 170. LSA types describe flooding scope and origin, not preference.

The OSPF route has a metric of 20, while the EIGRP route has a metric of 2560.

Why it fails: Metrics are only compared between routes of the same protocol; EIGRP's 2560 and OSPF's 20 are never weighed against each other. Administrative distance decides first, and 170 exceeds 110. Metric tuning is the correct approach when selecting between two EIGRP paths, not across protocols.

The static route was redistributed with a route-map that sets the EIGRP metric to 1.

Why it fails: Setting the EIGRP metric to 1 does not alter administrative distance, so the external EIGRP route still carries AD 170 and loses to OSPF's 110. Route-map metric manipulation is used to influence EIGRP path selection among EIGRP routes, not to override a competing protocol's AD.

Disable OSPF authentication to reduce packet size and processing overhead.

Why it fails: OSPF authentication does not significantly affect packet size or processing overhead in a way that would cause flapping due to CoPP. Disabling authentication would weaken security and not solve the policer dropping packets. The flapping is due to the policer rate, not authentication. The correct fix is to adjust CoPP parameters.

Configure a higher priority queue for OSPF traffic in the policy map.

Why it fails: CoPP uses policing, not queuing, to rate-limit traffic. Priority queuing is not a feature of CoPP policy maps. While prioritization could help, the immediate issue is that the policer rate is too low, causing drops. Increasing the policed rate and burst size directly addresses the drops and resolves the flapping.

Apply the policy map to all interfaces instead of the control plane.

Why it fails: CoPP is specifically applied to the control plane to protect the route processor. Applying the policy to interfaces would affect data plane traffic and not protect the control plane. Moreover, it would not address the OSPF flapping caused by the policer dropping legitimate OSPF packets. The correct action is to adjust the policer parameters.

Two EEM applets are currently registered: one for syslog and one for timer.

Why it fails: History events record past triggers, not currently registered applets; registration is shown by show event manager policy registered. Two events fired once each, which does not establish that two applets remain registered on the device.

The OSPF-5-ADJCHG syslog event triggered an applet that executed a timer.

Why it fails: The history lists two independent events, each with trigger count 1; nothing shows the syslog event launching an applet that started the timer. Correlating a syslog trigger to an applet action requires the applet configuration, not this event history output.

The timer event is a countdown timer that triggered after 5 minutes and 23 seconds.

Why it fails: The output lists an absolute timer named MY-TIMER that fired at 00:06:00, not a countdown of five minutes twenty-three seconds; that figure is the syslog event's timestamp. Countdown timers appear as Timer Type: countdown, which this entry does not show.

The OSPFv3 router ID is a 128-bit value derived from the highest loopback IPv6 address.

Why it fails: The OSPFv3 router ID is a 32-bit value formatted like an IPv4 address, not 128-bit, and it is not derived from an IPv6 loopback address. It must be manually configured or inherited from an IPv4 address. A 128-bit identifier describes the IPv6 address, not the router ID.

The 'ipv6 router ospf' command is used to enable OSPFv3 on an interface.

Why it fails: The 'ipv6 router ospf' command creates the OSPFv3 routing process in global configuration mode; interface participation requires 'ipv6 ospf <process-id> area <area-id>' under the interface. It is tempting because process creation is a genuine prerequisite, but that step alone leaves the interface without an OSPFv3 adjacency.

OSPFv3 uses the network type configured under the OSPFv3 process globally, not per interface.

Why it fails: OSPFv3 network type is configured per interface with 'ipv6 ospf network', not globally under the process; the stem's global claim contradicts IOS-XE behaviour. It is tempting because several OSPFv3 parameters, such as router-id and reference bandwidth, are indeed set process-wide, but network type is not among them.

The distribute-list is applied to the wrong direction; it should be outbound to filter routes being advertised.

Why it fails: The distribute-list direction is not the problem; inbound filtering on the interface is the correct way to prevent a route from being installed. Outbound distribute-lists only affect routes advertised to other OSPF neighbors and have no impact on local routing table installation. The real issue is that OSPF may receive the same prefix from another neighbor not covered by this inbound filter.

The distribute-list uses an ACL that does not match the route exactly, so the route is permitted.

Why it fails: A distribute-list relies on an ACL to match route prefixes, and an ACL that does not contain the exact network statement will fall through to the implicit permit at the end, allowing the route. However, this is not the cause in this scenario because even a perfectly matched ACL would still fail to block the route if it is also learned from another OSPF neighbor. The engineer's filter cannot work when a parallel path exists in OSPF, so the ACL mismatch is irrelevant to the observed behavior.

The distribute-list is applied after the route is already installed in the routing table, so it has no effect.

Why it fails: Distribute-lists are applied to routing updates during the route installation process, before the route is inserted into the RIB; they do not remove routes that are already present. If a route is already installed, applying a distribute-list later will not flush it from the table. In this case, the route is still being learned from an unfiltered neighbor, so the fact that distribute-lists work pre-installation is not the reason the route remains.

The distribute-list is applied incorrectly and blocks all routes.

Why it fails: The stem states the distribute-list permits all routes, so it cannot be the cause of the missing routes. It is tempting because distribute-lists commonly filter OSPF routes, and an incorrectly applied one would be the right answer when neighbours form but prefixes are absent without a stated permit-all entry.

OSPF uses TCP, and CoPP only polices UDP.

Why it fails: OSPF runs directly over IP protocol 89, not TCP or UDP, so the premise is false and cannot explain the loss. It is tempting because CoPP class-maps often match UDP or TCP ports, and protocol mismatch would be the answer if OSPF genuinely used a transport protocol that the policy dropped.

The CoPP policy is applied to the wrong control plane subinterface.

Why it fails: CoPP polices traffic punted to the route processor; it is not applied to a control plane subinterface, so this mechanism does not exist as described. It is tempting because CoPP and control plane policing terminology overlap, and subinterface-level policy would be relevant when shaping per-interface transit traffic rather than protecting the RP.

The seed metric is not configured, so the routes are not redistributed.

Why it fails: A missing seed metric causes routes to be omitted from redistribution entirely, producing silent route loss rather than flapping and CPU spikes. It is tempting because seed metrics are a common redistribution pitfall, yet the symptom here is instability, which points to routes being redistributed back and forth between the two domains.

The administrative distance is set too low, causing the router to prefer the wrong route.

Why it fails: Administrative distance controls route preference between sources, not redistribution loops; a low AD would cause suboptimal path selection, not CPU spikes from flapping. It is tempting because AD governs route selection, but mutual redistribution loops arise from routes fed back between protocols without filtering or tag-based denial.

The OSPF process ID is the same on both routers.

Why it fails: OSPF process IDs are locally significant and need not match between routers, so identical IDs cause no redistribution problem. It is tempting because mismatched area or process identifiers do break OSPF adjacencies, but process ID mismatch is irrelevant here; the flapping stems from routes looping between the two protocols.

The EEM policies are not configured correctly.

Why it fails: The history lists syslog events that EEM detected, proving policies are registered and running; misconfiguration would show missing or malformed entries. EEM policy misconfiguration is the right diagnosis when applets fail to trigger or actions do not fire, not when events are logged correctly.

The EEM applet policies are disabled.

Why it fails: Disabled applets would not appear as detected events; the history shows EEM actively matching and recording syslog entries, so policies are enabled. Disabled applets are the correct diagnosis when configured policies exist but no events are captured or actions executed.

The syslog server is not reachable.

Why it fails: EEM records events locally in its history buffer regardless of remote syslog reachability, so the populated list does not indicate an unreachable server. An unreachable syslog server is the correct diagnosis when local logging works but no messages arrive at the collector.