Enhanced Interior Gateway Routing Protocol (EIGRP) was introduced by Cisco in 1992 as an advanced distance-vector routing protocol, originally running only on Cisco devices. It remained Cisco-proprietary for over two decades before becoming an open, multi-vendor standard — a milestone worth getting the date right on, since it’s commonly misstated.
From Proprietary Protocol to Open Standard
It is an enhancement of IGRP (Interior Gateway Routing Protocol), Cisco’s earlier classful distance-vector protocol — hence the name. IGRP itself has been obsolete since IOS 12.3, having been fully superseded by EIGRP’s more capable design, which addressed IGRP’s classful addressing limitations and slower convergence behavior.
EIGRP stayed a Cisco-only protocol for its first several decades. Cisco submitted Its specification to the IETF as an informational draft in 2013, but the actual open-standard milestone — RFC 7868, “Cisco’s Enhanced Interior Gateway Routing Protocol (EIGRP)” — wasn’t formally published until May 2016. From that point on, other vendors have been able to implement genuinely interoperable EIGRP support, though in practice, non-Cisco implementations (such as those in FRRouting) have sometimes lagged behind or omitted certain features, like the stub designation, that Cisco’s own implementation includes.
Distance-Vector, Not “Hybrid”
Older CCNA material — and a fair amount of material still circulating — describes EIGRP as a “hybrid” routing protocol, implying it’s some blend of distance-vector and link-state technology. This label is inaccurate, and current, authoritative sourcing backs that up directly: RFC 7868 itself states plainly, “EIGRP is a routing protocol based on Distance Vector technology.” EIGRP is not a hybrid of two protocol families — it’s a genuinely advanced distance-vector protocol, using the Diffusing Update Algorithm (DUAL) rather than the link-state SPF algorithm that protocols like OSPF actually use.
What likely earned EIGRP the “hybrid” reputation is that it borrows a few practical ideas commonly associated with link-state design — most notably, EIGRP routers maintain a topology table containing multiple potential routes (not just the single best route the way classic distance-vector protocols like RIP do), and its neighbor-relationship and reliable-delivery mechanisms resemble link-state protocols on the surface. But the fundamental algorithm underneath — DUAL — is squarely a distance-vector-family algorithm, computing best paths based on information advertised by directly connected neighbors, not by building a complete map of the network topology the way link-state protocols do.
Why EIGRP Converges Faster Than Older Distance-Vector Protocols
EIGRP is suitable across a wide range of topologies and media, and in a well-designed network, it scales effectively while converging far faster than legacy distance-vector protocols like RIP, with minimal ongoing network traffic. Several design choices explain why.
Diffusing Update Algorithm (DUAL)
DUAL is the algorithm EIGRP uses to guarantee loop-free paths and to maintain backup routes throughout the routing domain. Whenever a route’s best path fails, DUAL recalculates only the portion of the topology actually affected by that failure — a far more targeted process than recomputing routes network-wide. EIGRP stores available backup routes proactively via DUAL, so it can often switch to a known-good backup path immediately rather than waiting to recompute one from scratch, which is one of the single biggest contributors to EIGRP’s reputation for fast convergence.
Establishing Neighbor Adjacencies
Like OSPF, EIGRP establishes and actively tracks neighbor adjacencies with directly connected routers also running EIGRP. This ongoing adjacency tracking is what allows EIGRP to detect a failed neighbor quickly, rather than relying solely on periodic timeouts the way older distance-vector protocols do.
Reliable Transport Protocol (RTP)
EIGRP uses a proprietary delivery mechanism called Reliable Transport Protocol (RTP) to ensure its packets actually reach neighbors, retransmitting when necessary. RTP, combined with neighbor adjacency tracking, is what makes DUAL’s loop-free guarantees possible — DUAL depends on knowing, reliably, what its neighbors have actually advertised.
Partial and Bounded Updates
Unlike RIP, which periodically re-broadcasts its entire routing table on a fixed schedule, EIGRP sends updates only when something actually changes — a partial update, containing just the specific route change (a link going up, a link going down, a metric changing), not the full table. These partial updates are also bounded: they’re sent only to the routers actually affected by the change, not flooded to every router in the domain regardless of relevance. Together, partial and bounded updates keep EIGRP’s bandwidth overhead low compared to protocols that periodically resend everything.
Equal and Unequal Cost Load Balancing
EIGRP supports both equal-cost and unequal-cost load balancing across multiple paths to the same destination. By default, the variance value is 1, which limits load balancing to paths with exactly equal cost. Increasing the variance allows EIGRP to also use paths with a higher cost than the best path — up to variance times the best path’s cost — enabling unequal-cost load balancing that can better utilize available bandwidth across multiple links of differing capacity, proportional to each path’s relative cost.
A Note on Legacy Protocol Support
Some older EIGRP material mentions that it could route not just IP but also AppleTalk and Novell NetWare (IPX) traffic, through separate Protocol-Dependent Modules (PDMs) that maintained independent tables per network-layer protocol. This was accurate at the time, but it’s now purely historical: Cisco permanently removed AppleTalk and IPX/Novell support from Cisco IOS starting around IOS 12.2(13)T and completed the removal with 15.0(1)M, driven by the near-total industry shift to IP-only networking. No currently supported Cisco IOS release retains this capability, so it’s worth knowing as protocol history rather than expecting to encounter it in any modern deployment.
Similarly, since IGRP and EIGRP shared a compatible metric structure (IGRP’s metric could be automatically translated into EIGRP’s), the two protocols could historically interoperate and redistribute between each other on the same network. With IGRP long obsolete, this interoperability is likewise a piece of protocol history rather than a live concern in current network design.
The Topology Table: Where DUAL’s Speed Comes From
A key structural difference between EIGRP and a simpler distance-vector protocol like RIP is the topology table. Where RIP’s routing table only ever holds the single best-known route to each destination, EIGRP’s topology table holds every route a neighbor has advertised for a given destination, not just the winner.
This is what makes EIGRP’s fast convergence possible: if the current best route (the successor) fails, DUAL can often find a pre-qualified backup route (a feasible successor) sitting right there in the topology table, without needing to query any other routers or wait for a new route to propagate in from elsewhere. This is a meaningful practical advantage over RIP, where a failed route typically means waiting through a slow recomputation and reconvergence process across the network.
A feasible successor isn’t just any alternate route — it has to satisfy the Feasibility Condition, meaning its reported distance (the neighbor’s own cost to the destination) must be strictly lower than the current successor’s total distance. This condition exists specifically to guarantee the alternate route can’t loop back through the router itself, preserving DUAL’s loop-free guarantee even when switching to a backup path instantly.
EIGRP’s Composite Metric
It calculates its route metric using a composite formula that, by default, combines bandwidth and delay (with load, reliability, and MTU available as configurable but disabled-by-default inputs). This composite approach lets EIGRP make more nuanced path decisions than a protocol using a single, simple metric like hop count — a low-bandwidth path with fewer hops can correctly lose out to a higher-bandwidth path with more hops, which better reflects real-world path quality than hop count alone ever could, and is one more example of EIGRP’s design going meaningfully beyond what a basic distance-vector protocol like RIP was originally built to do.
EIGRP vs. OSPF at a Glance
Since these two protocols are the ones most commonly compared on the CCNA exam, a quick side-by-side is worth having:
| EIGRP | OSPF | |
|---|---|---|
| Protocol family | Advanced distance-vector | Link-state |
| Core algorithm | DUAL | SPF (Dijkstra) |
| Metric | Composite (bandwidth + delay by default) | Cost (based on interface bandwidth) |
| Vendor origin | Cisco (now open via RFC 7868, 2016) | Originally IETF standard from the start |
| Convergence approach | Pre-computed feasible successors | Full topology recalculation within the area |
| Update behavior | Partial and bounded, event-driven | Flooded within area on topology change |
| Unequal-cost load balancing | Yes, via variance | No |
Neither protocol is universally “better” — EIGRP’s simpler configuration and fast convergence make it attractive in Cisco-heavy environments, while OSPF’s vendor-neutral, standards-based design and finer area-based control make it the more common choice in mixed-vendor or highly structured large networks. Many organizations that standardize on Cisco hardware throughout still choose OSPF specifically for its long track record as a formal IETF standard and its broader base of documentation and tooling support across the industry.
Frequently Asked Questions
Is EIGRP still a Cisco-proprietary protocol?
No, not since May 2016, when RFC 7868 was published as an IETF informational document, opening the specification for other vendors to implement. Cisco’s own implementation remains the most complete and widely deployed, but EIGRP is no longer exclusively Cisco’s. Some third-party implementations, including the open-source FRRouting project, have not implemented every feature described in the RFC — the stub designation being a commonly cited gap — which can affect interoperability and performance in mixed-vendor networks that mix Cisco and non-Cisco EIGRP routers.
Why do some CCNA materials still call EIGRP a “hybrid” protocol?
This terminology predates the current understanding and is now considered inaccurate — EIGRP is fundamentally a distance-vector protocol, confirmed directly by its own RFC. The “hybrid” label likely stuck because EIGRP borrows some ideas associated with link-state protocols (like maintaining a topology table of multiple candidate routes), even though its core DUAL algorithm remains distance-vector in nature.
What algorithm does EIGRP actually use instead of SPF?
The Diffusing Update Algorithm (DUAL), which guarantees loop-free paths and maintains backup routes by recalculating only the specific portion of the topology affected by a change, rather than running a full shortest-path calculation across the whole network the way OSPF’s SPF algorithm does.
Does EIGRP still support AppleTalk or Novell NetWare?
No. Support for both was permanently removed from Cisco IOS years ago, starting around IOS 12.2(13)T and completing with 15.0(1)M. Any current EIGRP deployment runs IP exclusively.
What’s the difference between EIGRP’s partial updates and RIP’s periodic updates?
RIP resends its entire routing table on a fixed timer regardless of whether anything changed. EIGRP only sends an update when a route actually changes, and only to the routers that specific change actually affects — significantly reducing routine bandwidth consumption compared to RIP’s approach.
What is a feasible successor, and why does it matter?
A feasible successor is a backup route to a destination that It has already verified satisfies the Feasibility Condition, meaning it’s guaranteed loop-free and can be used immediately if the current best route (the successor) fails. Having a qualified feasible successor already sitting in the topology table is what lets EIGRP switch to a backup path essentially instantly, without needing to query neighbors or wait for a new route computation, which is a major reason EIGRP converges faster than older distance-vector protocols after a link failure.
Conclusion
It began as a Cisco-proprietary enhancement of IGRP in 1992 and became a genuine open standard with RFC 7868 in 2016 — a milestone worth remembering correctly, since an earlier 2013 date sometimes circulates instead. Its defining features — DUAL for fast, loop-free convergence, a topology table stocked with pre-qualified feasible successors, RTP for reliable delivery, and partial/bounded updates for low bandwidth overhead — all stem from the same underlying design: a distance-vector protocol pushed considerably further than RIP or IGRP ever went, not a genuine hybrid with link-state technology despite older material sometimes suggesting otherwise.
