EIGRP exchanges routing information between neighboring routers and uses the Diffusing Update Algorithm, or DUAL, to select paths without creating routing loops. Its metric ranks candidate paths, while DUAL determines when a router can safely keep or replace a next hop and when it must coordinate a new calculation with its neighbors.

Enhanced Interior Gateway Routing Protocol is an interior routing protocol for a managed routing domain. It is based on distance-vector information: a router learns a neighbor's distance to a destination and calculates a path through that neighbor. It does not need a complete map of every router and link to make each decision.

A backup path may be physically available yet fail EIGRP's local check for a loop-free route. In that case, the router may need replies from its neighbors before selecting a replacement.

How EIGRP Forms Neighbor Relationships

EIGRP discovers neighbors through Hello packets on participating interfaces. The routers must use the same EIGRP autonomous system number and matching metric coefficients, known as K-values. Their authentication settings must agree, and both routers must support the address family being exchanged. Routing packets must also be able to travel in both directions.

Receiving a Hello does not prove that two routers can exchange routes. During initialization, they also exchange unicast updates and acknowledgments. If multicast Hellos arrive but the required unicast packets are blocked, the neighbor relationship can remain incomplete.

The neighbor table records the router's adjacent peers. Each peer advertises a hold time: the interval its neighbor will wait for another EIGRP packet from that peer before declaring it unreachable. Each EIGRP packet received from the peer resets this timer. If the timer expires, the router informs DUAL that the neighbor has been lost. Physical link failure and other supported detection mechanisms can also trigger a change.

EIGRP uses acknowledgments and retransmission to deliver routing updates reliably. Discovery Hellos do not require acknowledgments, so they can continue arriving even when the update exchange is failing.

With authentication enabled, a router accepts EIGRP packets only when they pass the configured authentication checks. Neighboring routers need matching authentication settings and valid keys. A shared subnet by itself does not establish that another router is an authorized source of routing information.

What the EIGRP Metric Measures

EIGRP calculates a composite metric from advertised path information and the local interface's contribution. With the default K-values, the metric uses bandwidth and delay. Reliability and load can be represented in the metric information without affecting that default calculation.

For classic metrics, the bandwidth component depends on the lowest configured bandwidth along the path, while delays accumulate along the path. These configured values do not measure current throughput or the time taken by an application request. When otherwise eligible paths are compared, the lower metric is preferred.

The bandwidth setting also does not change the physical capacity of a link. A different bandwidth value can change which route EIGRP prefers, but it will not make the link transmit data faster.

Classic and Wide Metrics

Classic EIGRP uses 32-bit metric calculations. Wide metrics use 64-bit calculations and different scaling to distinguish faster links more effectively. In Cisco IOS XE 17.x, named mode uses wide metric calculations, while classic mode uses 32-bit metrics.

Classic and wide metric values cannot be compared directly because their formulas and scaling differ. A router may also scale a wide metric when placing it in the routing information base. To check a displayed value, first identify the metric format, K-values, interface settings, and any scaling applied to that display.

Reported, Computed, and Feasible Distance

A neighbor's reported distance, or RD, is the metric that neighbor advertises for reaching a destination. The receiving router calculates its own distance through that neighbor using the advertised path information and its local contribution. That result is the computed distance, or CD, for the candidate path.

Feasible distance, or FD, records the lowest distance to the destination since the route last moved from Active to Passive. It can equal the current best distance, but it can also remain lower when a path's cost rises without requiring a new diffusing computation.

The feasibility check uses this historical minimum. Substituting the current best path's metric for FD could make an alternate appear eligible even though it fails the actual test.

Successors and Feasible Successors

A successor is a next hop selected for forwarding toward the destination. A feasible successor is a neighbor whose reported distance satisfies the feasibility condition: its RD is strictly less than the local FD for that destination. Equality does not satisfy the condition.

Passing the condition tells DUAL that the path through that neighbor is loop-free. Failing the condition does not prove that the path contains a loop; it means the router cannot establish loop freedom from this local check alone. A low total cost does not remove that uncertainty.

A feasible successor can have a higher computed cost than the current successor and remain useful as an alternate. There is no requirement that every destination have such an alternate. Connectivity, path costs, and the retained FD determine which neighbors qualify.

A Route Selection Example

Consider a hypothetical router R with an FD of 1,000 for one destination. The distances below use the same illustrative metric scale. They are assumed values for this example, not router output or raw bandwidth measurements:

  • Neighbor B reports 600, and R's computed distance through B is 1,000.
  • Neighbor C reports 800, and R's computed distance through C is 1,400.
  • Neighbor D reports 1,000, and R's computed distance through D is 1,800.

B supplies the current least-cost path. C qualifies as a feasible alternate because 800 is less than 1,000, despite its higher total cost. D fails the feasibility condition because its reported distance equals R's FD. Comparing only the three computed distances would miss that distinction.

If the path through B fails while C remains the least-cost available candidate and retains its qualifying reported distance, R can select C without a new diffusing calculation. R's current computed distance becomes 1,400, but FD can remain at the earlier minimum of 1,000.

How DUAL Responds to a Route Change

Passive is the normal settled state for a destination when no diffusing computation is underway. Active means that the router is coordinating a calculation for that destination. These states apply separately to each destination. A route being Active does not mean that the entire router has stopped forwarding traffic.

When a topology change leaves the least-cost replacement satisfying the feasibility condition, the destination can remain Passive. When no suitable least-cost replacement passes the check, the destination must enter Active and coordinate with the neighbors participating in that computation.

Queries and Replies

A Query asks neighboring routers for their distance to a destination. A neighbor that also needs to recalculate its route may send queries of its own before returning a Reply. A Reply can report a usable distance or say that the destination is unreachable.

The router that started the calculation tracks which neighbors still owe a reply. Once DUAL completes the calculation, the route returns to Passive with the new path information, or is removed if the destination is unreachable. A path that failed the earlier feasibility check may become usable after this exchange.

In the hypothetical example, losing both B and C leaves D failing the original feasibility check. R cannot promote D solely because its route is the last advertised candidate. R must complete the DUAL calculation before deciding whether it can use D.

A Missing Reply Can Delay Convergence

A route that waits too long for required replies can encounter a stuck-in-active condition. Possible causes include delayed control packets, an overloaded router, or a neighbor that is itself waiting for replies farther along the path. The router waiting for a reply may therefore be several hops from the source of the delay.

SIA Query and SIA Reply messages help track progress while a computation is still underway. A neighbor can use an SIA Reply to confirm that it is still processing the query, but that message does not replace the final Reply. Recovery time depends on the topology, software behavior, and cause of the delay.

Stub Routing and Route Summaries

An EIGRP stub router tells its neighbors that it should not be used as a transit router and advertises only the routes allowed by its stub configuration. Neighbors that recognize this status do not send it route queries. This can reduce unnecessary query propagation toward a branch that should not carry transit between distribution routers.

The role must match the topology. If other routers rely on a branch router to advertise routes between core routers, making that branch router a stub can break those paths. The stub setting also does not determine which default route, summaries, or individual routes the branch receives; those advertisements must be configured separately.

Route summarization advertises a broader prefix in place of individual routes at a chosen point in the network. Routers receiving the summary need fewer route entries and may not need updates for every change within that range. A summary does not guarantee that every subnet it covers remains reachable.

A router's knowledge of a specific destination affects whether it can answer a query immediately or must ask its own neighbors. Stub routing prevents queries to designated branch routers, while summarization reduces the route detail advertised beyond a boundary. Neither setting can replace a valid backup path when a link fails.

Platform Support and Forwarding Checks

EIGRP originated with Cisco, and its published protocol description is an Informational RFC rather than an IETF Standards Track specification. Other implementations exist, including FRRouting's eigrpd. Support varies by platform and release, including the available address families, metric formats, authentication options, and stub features.

Before deploying EIGRP, check that the router hardware and software support the features the network needs. A configuration that works on one platform may need changes on another. The deployment plan should also account for software updates and ongoing support.

To check an EIGRP route, examine its neighbor relationship, topology entry, and installed forwarding entry. During an authorized failure test, record which path failed, the candidate distances, whether the route became Active, and which next hop was selected. Also measure the application's interruption: detecting a failure and calculating a replacement do not necessarily mean that usable forwarding has resumed.