EIGRP Tutorial

This tutorial covers the Enhanced Interior Gateway Routing Protocol (EIGRP).

EIGRP started out as a Cisco-proprietary routing protocol, but since March 2013 Cisco has opened it up as a published standard so it can be used in multi-vendor environments. It’s a classless protocol — every routing update carries the subnet mask along with the network address — and it calculates its metric from a formula built on bandwidth and delay.

You’ll often see EIGRP called a hybrid routing protocol, since it blends characteristics of both distance-vector and link-state protocols — though Cisco itself now prefers to describe it as an advanced distance-vector protocol.

Note: calling EIGRP “hybrid” is a bit misleading — it isn’t really a mix of distance-vector and link-state mechanics. At its core it’s still a distance-vector protocol, just with a lot of enhancements layered on top.

EIGRP is a substantial step up from its predecessor, IGRP. Its standout features:

• Supports VLSM and discontiguous networks.
• Uses the Reliable Transport Protocol (RTP) to deliver and receive EIGRP packets.
• Uses the Diffusing Update Algorithm (DUAL) for best-path selection, which guarantees loop-free paths and keeps backup paths ready throughout the routing domain.
• Discovers neighbors via periodic Hello messages, which also double as a way to keep monitoring whether an existing neighbor is still reachable.
• Exchanges the full routing table only once, at startup — after that, it sends partial, triggered updates rather than repeating full-table updates the way older distance-vector protocols do, and only to the routers that actually need that information. This is different from link-state protocols, which flood an update to every router in the area regardless of whether it’s relevant. A triggered update fires, for instance, whenever a link comes up or goes down.
• Supports multiple routed protocols — EIGRP can carry routes for IPv4, IPv6, AppleTalk, and IPX/SPX.
• Supports load balancing, including unequal-cost load balancing, which lets administrators spread traffic across paths more flexibly than most protocols allow.

Note: “partial” here just means the update only contains information about whatever actually changed — not the entire table.

EIGRP’s metric is built from bandwidth, delay, reliability, and load — though by default, only bandwidth and delay are actually used in the calculation.

EIGRP relies on five packet types to communicate:

• Hello: identifies neighbors; sent as periodic multicasts.
• Update: advertises routes; sent as a multicast only when something has actually changed.
• Ack: acknowledges receipt of an Update. In practice, an Ack is just a Hello packet with no data — always sent as a unicast, over UDP.
• Query: sent to look for alternate paths once every known path to a destination has failed.
• Reply: sent in response to a Query, to tell the originator it doesn’t need to recompute the route because a feasible successor already exists. Replies are always unicast, back to whoever sent the query.

Both Query and Reply messages are sent via RTP, so every one of them gets acknowledged with an EIGRP Ack.