EIGRP (Enhanced Interior Gateway Routing Protocol)

EIGRP (Enhanced Interior Gateway Routing Protocol) is Cisco's answer to a fundamental problem: distance-vector protocols are simple but prone to loops and slow convergence, while link-state protocols are fast but complex and bandwidth-hungry. EIGRP takes the core distance-vector approach—learning routes from neighbors—and adds just enough intelligence to converge instantly while guaranteeing no loops, ever.

The secret is keeping backup routes ready and pre-validated. When your primary path fails, EIGRP doesn't need to recalculate anything. It already knows which backup is safe to use.

The Problem EIGRP Solves

Distance-vector protocols have a dirty secret: they're vulnerable to routing loops. When a route fails, routers advertise changes to their neighbors, who advertise to their neighbors, and during this convergence period, packets can circle endlessly. RIP's solution—wait up to 180 seconds for routes to time out—works but is painfully slow.

Link-state protocols like OSPF solve this differently: every router knows the complete network topology and calculates its own shortest paths. No loops, fast convergence. But this requires flooding topology information across the network and running complex Shortest Path First calculations.

EIGRP found a third way. It keeps the distance-vector model—routers only know what their neighbors tell them—but adds a mathematical guarantee that prevents loops without requiring full topology knowledge.

How EIGRP Prevents Loops

EIGRP's loop-prevention comes from the DUAL (Diffusing Update Algorithm) and a concept called the feasibility condition.

Every route in EIGRP has two metrics:

Feasible Distance (FD): Your best metric to reach a destination—the cost of your current best path.

Reported Distance (RD): What your neighbor claims their cost is to reach that destination.

The feasibility condition is beautifully simple: if your neighbor is closer to the destination than you are, they can't possibly loop back through you to get there.

Mathematically: a backup route is guaranteed loop-free if the neighbor's Reported Distance is less than your Feasible Distance. If they're already closer to the destination than your best path, there's no reason they'd ever route through you.

This creates two categories of routes:

Successor: Your current best route—the neighbor with the lowest total cost to the destination.

Feasible Successor: A backup route that passes the feasibility condition. It's mathematically guaranteed to be loop-free, so it's safe to use instantly.

Why Convergence Is So Fast

When your successor fails and a feasible successor exists, convergence is essentially instant—sub-second. There's no calculation, no querying neighbors, no waiting. The router simply switches to the backup it already knew was safe.

This is EIGRP's killer feature. In a well-designed network, most failures trigger instant failover because feasible successors exist.

When no feasible successor exists, EIGRP has to do actual work. It sends queries to neighbors: "My path to this destination failed. What do you know?" Neighbors reply with their routes (or pass the query along if they were using the failed router too). Once all replies arrive, EIGRP recalculates.

Even this slower path typically converges in seconds—far faster than RIP's minutes.

The Topology Table

Unlike RIP, which only keeps the best route to each destination, EIGRP maintains a topology table with all routes learned from all neighbors. This is what makes instant failover possible—the backups are already there, already validated.

The topology table answers a question most protocols can't: "If my current path fails right now, what's my next best option, and is it safe to use?"

Neighbor Relationships

EIGRP routers discover each other through Hello packets, sent every 5 seconds on fast links (Ethernet) or every 60 seconds on slow links. Once neighbors establish a relationship, they exchange their full topology tables, then send updates only when something changes.

This is far more efficient than RIP's approach of broadcasting the entire routing table every 30 seconds regardless of whether anything changed.

Metrics: Smarter Than Hop Count

RIP counts hops. A path through three routers beats a path through four, even if those three routers are connected by dial-up modems and the four-router path uses gigabit links.

EIGRP considers bandwidth and delay. By default, it calculates a composite metric from the minimum bandwidth along the path and the cumulative delay. A high-bandwidth, low-latency path beats a shorter path through congested, slow links.

The protocol can also consider reliability and load, though these are rarely enabled because they cause route instability—metrics that fluctuate cause routes to flap.

Efficient Updates

EIGRP is remarkably efficient with bandwidth:

Partial updates: Only changed routes are advertised, not the entire table.

Bounded updates: Changes propagate only as far as necessary. If a route change affects only one part of the network, routers in other parts never see the update.

Reliable delivery: EIGRP acknowledges update receipt, retransmitting if needed. No updates are lost.

In a stable network, EIGRP generates almost no routing traffic—just periodic Hellos to confirm neighbors are alive.

EIGRP's Achilles Heel: Stuck-in-Active

When EIGRP can't find a feasible successor and must query neighbors, it waits for replies. If a reply never comes—because a router crashed, a link is congested, or the network is partitioned—EIGRP waits. And waits.

After 3 minutes (by default), EIGRP declares the route "stuck-in-active" and tears down the neighbor relationship with whoever didn't respond. This can cascade, causing significant disruption.

Stuck-in-active is almost always a symptom of network design problems: query scope too large, insufficient summarization, or unreliable links. Well-designed EIGRP networks rarely experience it.

Unequal-Cost Load Balancing

Most routing protocols balance traffic only across equal-cost paths. EIGRP can distribute traffic across paths with different metrics using the variance command.

If you set variance to 2, EIGRP will use any feasible successor with a metric up to twice the best metric. Traffic is distributed proportionally—better paths get more traffic.

This is genuinely useful when you have multiple paths of different speeds and want to use them all rather than letting backup capacity sit idle.

EIGRP vs. OSPF

The practical choice usually comes down to vendor environment:

EIGRP excels in Cisco-centric networks. Simpler configuration (no area design), faster convergence with feasible successors, more efficient bandwidth usage, unequal-cost load balancing. Less CPU-intensive since there's no SPF calculation.

OSPF wins in multi-vendor environments. It's an open standard with universal support, wider expertise pool, and better vendor-neutral tooling. Hierarchical areas provide explicit scalability structure.

In a Cisco shop with engineers who know EIGRP, it's often the better choice. In a mixed environment or when hiring generalist network engineers, OSPF's ubiquity matters more.

Modern EIGRP

EIGRP supports IPv6 natively and includes a "named mode" configuration (introduced in IOS 15.0) that simplifies setup and supports both address families in a single configuration block.

In 2016, Cisco published EIGRP as an informational RFC, technically making it an open standard. In practice, it remains a Cisco technology—other vendors have little incentive to implement it when OSPF and IS-IS serve the same purpose.

When EIGRP Makes Sense

EIGRP is the right choice when:

• Your network is primarily Cisco equipment
• Fast convergence matters (sub-second failover with feasible successors)
• You want simpler configuration than OSPF's area hierarchy
• Unequal-cost load balancing would help utilize backup paths
• Your team already knows EIGRP

It's the wrong choice when:

• You need multi-vendor interoperability
• You're hiring generalist network engineers (OSPF knowledge is more common)
• You're building a network that might outlive your current vendor relationship