When an enterprise routing incident begins, the phrase “the neighbor is up” often slows troubleshooting more than it helps. An established adjacency proves something important, but it does not prove that the intended prefix was advertised, accepted, installed, or selected for forwarding. Cisco 300-410 ENARSI scenarios require a layered way to inspect OSPF and EIGRP behavior: interface configuration, control-plane relationships, topology databases, route selection, and the actual packet path. Engineers who jump straight to changing timers or clearing processes can convert one localized fault into an unstable regional outage.
Begin with the exact missing route
A branch office loses access to a data-center application after a scheduled access-switch replacement. Other applications still work and adjacent routers show established routing relationships. Before proposing a routing protocol change, identify the source address, destination prefix, traffic direction, and expected next hop. Determine whether the branch router has any route to the destination, whether that route points to the correct neighbor, and whether upstream devices know the return prefix. A single missing more-specific route can create a failure that looks like a widespread network outage to affected users.
Check the forwarding table as well as the routing table. Some platforms may have a control-plane route that cannot be used as expected because of an interface or adjacency condition. Also verify access lists, policy-based routing, and address translation before concluding that OSPF or EIGRP is at fault. The useful question is not “is routing healthy?” but “at which stage does this precise destination stop being reachable?” That framing makes telemetry and show-command output actionable rather than a collection of screenshots.
OSPF neighbors require compatible expectations
OSPF adjacency formation depends on matching key parameters and network conditions. Area assignments, authentication configuration, hello and dead intervals, interface network types, and certain link characteristics can keep neighbors from progressing into a stable relationship. A mismatch may leave routers seeing one another but unable to synchronize the link-state database. If one side believes it is on a broadcast segment and another treats the link differently, designated-router behavior and network representation can complicate diagnosis.
A systematic process checks interface state and addressing, multicast reachability where used, OSPF process and area configuration, and neighbor state transitions. Only then should the engineer interpret LSA advertisements. Clearing an OSPF process can temporarily hide a chronic MTU mismatch or flapping transport link, and the resulting reconvergence may affect unrelated networks. If an adjacency repeatedly resets, correlate timestamps with physical errors, BFD events, interface counters, and authentication changes. The root cause may sit below the routing protocol.
A valid OSPF database does not ensure the desired path
OSPF chooses routes using the topology represented by link-state advertisements and associated costs. An area boundary, summarization policy, or missing LSA can cause one router to have a different view of a prefix than another. When investigating, distinguish intra-area, inter-area, and external route behavior. A route that appears in the OSPF database but not in the routing table may lose to a route from another protocol or fail selection for another reason. Administrative distance and route policy can be as relevant as OSPF’s own metric calculations.
For a multi-area network, verify that the area border router is generating and admitting the intended summary information. Overaggressive summarization may hide a failed more-specific destination behind a summary that still points toward an area where no path survives. Conversely, too many unnecessary external LSAs may increase operational complexity. The remedy should preserve the intended hierarchy, not merely make one ping work. Capture the expected topology before changing summaries or the costs that influence a large set of shortest-path calculations.
EIGRP has different failure mechanics
EIGRP uses neighbor relationships and DUAL calculations to maintain loop-free paths according to its metric and feasibility rules. An interface can form a neighbor while a desired route is absent due to filtering, summary behavior, or a feasible-distance and reported-distance relationship. A feasible successor may allow fast failover without a query-driven recomputation, but not every alternative neighbor automatically qualifies. Understanding this distinction explains why one prefix recovers immediately while another enters active computation during a failure.
Wide metrics, classic metric configuration, unequal-cost load balancing, summarization, and stub routing can all change behavior. A branch configured as an EIGRP stub may correctly avoid becoming a transit router, but it may also not advertise the routes a designer incorrectly assumed it would carry. Look for the actual topology entry and the routing information received from neighbors rather than relying only on whether EIGRP reports a stable peer. Queries that take too long can indicate a network boundary or topology problem requiring careful scope analysis.
Route filtering can be the hidden explanation
Both OSPF and EIGRP deployments may use policy at redistribution or summarization boundaries. A prefix can be present in one routing process but not carried into another. When a new subnet is introduced during a migration, an old prefix list or route map might silently exclude it. Prefix-length matching matters: permitting a summary address alone may not permit the more-specific routes operators expect. Check policy conditions and counters where available, and evaluate whether the intended boundary should leak the prefix in the first place.
A route’s absence may be the correct implementation of a security boundary, not a defect. If a guest network cannot reach a production database, ask whether that is deliberate before removing the filter. Similarly, introducing redistribution as a quick workaround can create feedback loops when multiple redistribution points exchange the same prefixes. A disciplined fix documents why the route is supposed to cross a boundary, adjusts the narrow policy element, and observes the surrounding route table for unexpected changes.
Isolate a protocol problem with a timeline
Imagine the trouble began immediately after an interface speed and MTU change. OSPF neighbors remain stuck in a database-exchange state; engineers should inspect negotiated link characteristics and packet capture evidence before changing area design. In a different incident, EIGRP neighbors remain healthy but one route vanishes after a branch summary is added; the topology and summary policies are more likely than hello timers. The incident timeline lets investigators prioritize tests without anchoring prematurely on a familiar command.
Operational evidence should be retained long enough to compare before and after states. Record neighbor transitions, interface errors, changed configuration lines, routing table outcomes, and reachability tests from both directions. If engineers make three changes at once, it becomes hard to explain which one mattered and whether another change introduced risk. A staged repair should alter one plausible factor, confirm its predicted effect, and then validate nearby prefixes that share the same policy or area.
Troubleshoot toward a stable design
After restoring service, revisit why the fault could occur. Was route policy stored in an undocumented device-specific configuration? Was an area boundary missing a change-approval owner? Did the team lack a simple test of a critical prefix from the branch? OSPF and EIGRP incidents often expose weaknesses in configuration governance or network observability rather than only a bad setting. Codify expected adjacencies, accepted prefixes, and route reachability tests so future changes can be assessed before traffic is affected.
The ENARSI candidate should be able to move between protocol details and architectural intent. A good diagnosis names which route is wrong, why the control plane produced that result, how the data plane is affected, and what targeted correction restores the intended policy. OSPF and EIGRP are different algorithms with different databases, but both reward precise evidence and narrow, verifiable changes over speculative reconvergence rituals.
A route-comparison lab that exposes assumptions
Build a small lab with two OSPF areas and a branch running EIGRP at its boundary. Introduce a new subnet, then make it disappear through a filtering rule rather than by shutting down an interface. Ask each router not merely whether its neighbors are up, but where it learned the subnet and why it installed or rejected the result. Next, change a summary so a destination becomes unreachable even though a less-specific route persists. Capture a route table and topology output before and after each change. This exercise distinguishes adjacency, advertisement, database state, and forwarding; it also forces students to explain why the same prefix appears differently in each protocol. Finally, restore the intended policy without restarting the entire routing process. The lab demonstrates how a precise diagnosis can minimize collateral reconvergence, which is often more important in production than producing a quick visible change. A useful exam answer names the failed mechanism and the narrowly justified repair.
Careful use of passive interfaces is another important operational detail. A router may need to advertise a connected user subnet without attempting to form a routing adjacency with arbitrary devices on that access network. Marking the interface passive can support that intent, but its effect depends on the protocol and overall configuration. Accidentally marking an actual transit interface passive can remove the intended neighbor and its routes. When a change involves many interfaces, test the desired adjacency matrix explicitly. The goal is not to enable neighbors everywhere; it is to form them only on legitimate routing links while still advertising required reachable prefixes. This distinction connects control-plane hardening with practical route availability.