EIGRP troubleshooting is most effective when the engineer treats the protocol as a set of observable decisions: form a neighbor, learn topology information, calculate loop-free successors, install routes, and query neighbors only when a valid alternative is not already known. Problems that appear as “missing EIGRP routes” can originate at any of those stages, and the fix depends on identifying the first stage that failed.
The current 300-410 ENARSI v1.1 blueprint explicitly covers EIGRP classic and named mode, IPv4 and IPv6 address families, neighbor relationships, authentication, successor and feasible-successor logic, stuck-in-active conditions, stubs, equal and unequal-cost load balancing, and metrics. 350-401 ENCOR v1.2 keeps EIGRP at the comparison and architecture level, making ENARSI the stronger troubleshooting context.
Start with neighbor formation before investigating route calculation
EIGRP neighbors need compatible autonomous-system or address-family configuration, reachable interfaces, matching authentication where configured, and compatible K-values. If the neighbor never forms, route metrics and feasibility conditions are irrelevant. Check the interface, IP reachability, EIGRP process or named-mode address family, passive-interface state, and hello reception first.
Use neighbor uptime as a clue. A neighbor that never appears points to basic discovery or configuration. A neighbor that repeatedly resets suggests transport instability, authentication problems, resource issues, or repeated active-state failures. Correlate the EIGRP log with interface events so that a routing symptom is not mistaken for the physical cause.
In dual-stack environments, verify IPv4 and IPv6 separately. A stable IPv4 neighbor does not prove the IPv6 address family is enabled correctly. Named mode can make shared policy easier to organize, but it also means the engineer must inspect the correct hierarchy of address-family and interface configuration.
Use the topology table to understand DUAL decisions
The routing table shows only installed routes; the EIGRP topology table shows what DUAL knows about successors and candidate alternatives. When a route disappears, check whether the prefix is still present in the topology table and whether a successor exists. This distinguishes loss of all reachability from failure to install a learned path.
Reported distance is the metric a neighbor advertises to the destination. Feasible distance represents the local best known metric. A feasible successor must meet the feasibility condition so the router can use it immediately without creating a loop. A path can therefore look physically redundant but still not qualify as a feasible successor.
Do not “fix” a missing feasible successor by changing metrics blindly. First understand why the candidate does not meet the feasibility condition and whether the topology should be redesigned, summarized, or allowed to query during failure. The safety rule is what lets EIGRP converge quickly without accepting a potentially looping backup.
Investigate active routes as a query-propagation problem
When the current successor is lost and no feasible successor exists, EIGRP marks the route active and queries neighbors for an alternative. That is normal. The problem appears when replies do not return before the active timer expires, producing a stuck-in-active condition and potentially resetting the neighbor that failed to respond.
Large query domains make SIA more likely because a query can propagate through many routers and branches. Slow links, overloaded devices, unstable transport, or a distant topology change can delay the response. The router named in the SIA message is not always the original cause; it may simply be the neighbor from which the expected reply did not arrive.
Use query boundaries to improve scale. Summarization and EIGRP stub configuration reduce how far queries need to travel. A branch that never provides transit reachability for the rest of the network should not be asked about every lost core prefix. Query containment is a design feature, not just a troubleshooting trick.
Use EIGRP stub behavior to protect hub-and-spoke topologies
An EIGRP stub router advertises only selected route categories and tells neighbors that it should not be used as a general transit source for unknown destinations. Hubs then avoid sending many queries into a branch that cannot possibly provide an alternative path. This reduces convergence work and limits the blast radius of route loss.
Verify that stub configuration matches the branch role. If a site must redistribute a static or connected service route, the stub advertisement options need to allow that category. An overly restrictive stub can hide legitimate reachability; an absent stub can expose a small branch to unnecessary query load.
During troubleshooting, compare a healthy branch with the affected one. Differences in stub mode, summarization, passive interfaces, or redistribution often explain why one branch participates in a query chain while another does not.
Check metrics before assuming unequal-cost load balancing is broken
EIGRP calculates composite metrics from configured K-values and inputs such as bandwidth and delay. Equal-cost paths can be installed normally when they have the same metric and platform limits allow it. Unequal-cost load balancing uses variance, but a path must still satisfy loop-free requirements. A high variance value does not make every alternate route eligible.
Inspect the topology table metrics for each candidate. If an alternate path is absent, determine whether it was never learned, failed the feasibility condition, or exceeds the variance relationship. Also confirm the maximum-path setting and whether traffic sharing is intended to be proportional to metrics or simply spread across installed paths according to platform behavior.
Metric tuning should represent link capability and design intent. Artificially changing interface bandwidth only to manipulate EIGRP can affect other features that read the same value. Delay is often a more controlled routing-policy input, but any tuning should be documented and applied consistently.
Interface bandwidth and delay should be audited after circuit upgrades. If a 100 Mb/s WAN is replaced with 1 Gb/s service but the logical bandwidth remains at the old value, EIGRP may continue preferring a path that no longer represents the real topology. Conversely, changing bandwidth for a routing purpose can alter QoS, monitoring, or other features that consume the same interface value. Treat metric inputs as shared operational data.
Troubleshoot authentication and address-family mismatches explicitly
Authentication failures can look like a generic neighbor problem. Verify key chains or supported authentication configuration, key IDs, lifetimes, and clock accuracy. A key that is configured correctly but not valid at the current time will fail just as completely as a wrong secret.
Named mode supports structured address families, but configuration can be placed at different levels. Confirm that the intended interfaces are activated under the correct address family and that passive-interface policy is not inherited unexpectedly. For VRF-aware EIGRP, verify that the route is being examined inside the correct VRF rather than only in the global table.
Use packet captures or debugs carefully when configuration inspection is inconclusive. Hello packets can show whether EIGRP messages reach the interface. The absence of received Hellos points toward transport, ACL, multicast, or interface participation rather than metric calculation.
Route filtering deserves the same care as metric tuning. A distribute list, prefix list, route map, or summarization boundary can remove a path before DUAL has any opportunity to evaluate it. When an expected backup is missing, verify that the route is actually learned from the neighbor before trying to alter feasibility or variance settings.
Control redistribution so external routes do not feed back into EIGRP
Redistribution introduces routes that did not originate through normal EIGRP topology learning. External metrics, administrative distance, filtering, and route tags therefore matter. If the same prefix can cross between EIGRP and OSPF or BGP at multiple points, it can reenter the source protocol unless policy identifies and blocks the feedback path.
Use tags and explicit route maps so the origin of redistributed routes remains visible. The principles in route redistribution apply directly: define which prefixes may cross, assign a deliberate seed metric, tag them, and prevent the same tagged routes from being redistributed back.
Administrative distance can also change which source installs a route when multiple protocols know the prefix. A route missing from the IP table may still exist in the EIGRP topology table but lose to another routing source. Check the RIB decision before changing EIGRP neighbor or metric configuration.
Summarization is another troubleshooting signal. An EIGRP summary can intentionally hide more-specific failures behind a stable aggregate, often with a discard route installed locally to prevent loops. If remote routers still see the summary while one subnet inside it is down, the protocol may be behaving exactly as designed. Troubleshooting must move to the summarizing router to determine whether the missing more-specific route should have withdrawn the aggregate or only part of the summarized space.
Use protocol comparisons to isolate whether the fault is topology or policy
EIGRP is an advanced distance-vector protocol with DUAL, while OSPF builds a link-state database and runs SPF. The protocols converge and represent alternatives differently. If engineers apply OSPF troubleshooting habits mechanically to EIGRP, they can spend time looking for an LSDB that does not exist in the same form.
The differences among enterprise routing protocols is useful as a reminder that each control plane has its own evidence. For EIGRP, neighbors, topology entries, successors, feasible successors, active routes, queries, replies, and metrics are the key sequence.
At mixed-protocol boundaries, decide whether the fault exists before or after redistribution. If the route is correct in EIGRP but missing in OSPF, do not disturb EIGRP adjacencies. If the route never reaches the EIGRP topology table, redistribution policy is not yet the problem.
Baseline query behavior in healthy periods. Large enterprises should know which routers normally become active for a failed branch prefix and how far queries propagate. If a new site or redistribution point dramatically expands the query domain, the problem can be detected before it produces SIA during an outage. Query scope is a measurable property of the design.
Document expected convergence for representative failures. If a branch route normally switches to a feasible successor in milliseconds but suddenly goes active and queries the domain, that change is an early warning that topology or metric relationships have drifted even before a full outage occurs.
Use a repeatable troubleshooting sequence and preserve state before clearing it
Start with the interface and neighbor. Then check the topology table for the exact prefix, the successor and feasible-successor state, and whether the route is passive or active. Next check the routing table, administrative distance, and any redistribution policy. Finally validate the data plane and return path.
Avoid using clear commands as the first step. Resetting a neighbor can temporarily restore service while erasing the query state or authentication symptom that would have identified the cause. Capture neighbor uptime, active prefixes, SIA messages, topology metrics, interface errors, CPU load, and relevant logs before forcing reconvergence.
After the correction, test the failure case that exposed the problem. Shut or withdraw the intended primary path in a maintenance window and observe whether a feasible successor is used or whether queries remain bounded. A successful steady-state routing table is not enough; EIGRP design is proven when the network also converges predictably during loss.