skip to content

EIGRP

EIGRP is an advanced distance-vector protocol: DUAL keeps loop-free backup paths, a composite metric ranks them and updates are incremental. It is OSPF's usual counterpoint in design talks.

on this pageshow

explore

questions

30

What does an EIGRP router's composite metric measure along a path by default, and which carried values does it leave out?

level: juniorimportance: must knowfreq 34%

answer

  1. a weakest link and a running total
  2. inverse of the slowest link
  3. static per-interface delay, summed
  4. K1 and K3 on, the rest at zero

basics

~20 s

By default the EIGRP composite metric adds two terms: the inverse of the slowest link's bandwidth on the path and the sum of the outgoing interfaces' delays. Load, reliability, MTU and hop count travel with the route but are not weighed.

solid answer

~40 s

EIGRP advertises a vector for each route — minimum bandwidth, total delay, maximum load, minimum reliability, minimum MTU and hop count — and each router folds it into one number using weights called K-values. With RFC 7868's defaults, `K1 = K3 = 1` and `K2 = K4 = K5 = 0`, only two terms survive: `10^7` divided by the slowest link's bandwidth in kb/s, and the sum of the outgoing interface delays in tens of microseconds, the total multiplied by 256. Lower is better. The delay is a configured per-interface value, not a measured latency. MTU is carried but RFC 7868 says it is never part of the metric, and hop count is carried without being a metric term.

go deeper

for a junior

Recall the two default inputs: the slowest link's bandwidth and the total delay along the path. Lower metric wins.

for a middle

Explain how each vector component is combined hop by hop, minimum versus sum, and why the default K-values leave only bandwidth and delay in play.

for a senior

Point out that delay is a configured value, so the metric never reacts to congestion, and that this stability is exactly why the defaults leave load out.

for a principal

Frame the composite metric as a design choice: a stable, static ranking that every router computes identically, traded against any ability to steer around live congestion.

## Why EIGRP needed more than a hop count A **distance-vector** routing protocol learns routes from its neighbours and ranks them by a number called the **metric**; lower is better. The simplest metric is a hop count, and it has an obvious flaw: two hops across slow links beat three hops across fast ones. EIGRP — a distance-vector protocol that was one vendor's for years and was published as **Informational RFC 7868** in 2016 — replaces the hop count with a **composite metric**: a single number built from several properties of the path. To make that possible, every route EIGRP advertises carries a small **vector** of path properties rather than one finished number. Each router updates the vector as the route passes through it, and each router turns the vector into a composite metric using weights called **K-values**. ## The vector each route carries RFC 7868 §5.6.2.1 lists how each component is combined from the destination back towards the router: | Component | Combined hop by hop as | In the default metric? | |---|---|---| | Bandwidth | the **minimum** along the path | yes, weighted by `K1` | | Delay | the **sum** along the path | yes, weighted by `K3` | | Load | the **maximum** along the path | no, `K2 = 0` | | Reliability | the **minimum** along the path | no, `K4 = K5 = 0` | | MTU | the **minimum** along the path | never: RFC 7868 says MTU is not an attribute for calculating the metric | | Hop count | the **sum** along the path | no: carried, not a metric term | ## The default formula RFC 7868 defines the default weights as `K1 = K3 = 1` and `K2 = K4 = K5 = 0` (and `K6 = 0`, a weight that only the newer wide metrics use). With those values the classic formula collapses to two terms: ``` metric = 256 × ( 10^7 / minimum bandwidth in kb/s + sum of delays in tens of microseconds ) ``` - **The bandwidth term** is `10^7` divided by the slowest link's bandwidth in kilobits per second. It is an inverse: the slower the bottleneck, the bigger the term, and the worse the route. - **The delay term** is the sum of the delays of the **outgoing interfaces** along the path, counted in units of ten microseconds. - **The factor 256** is historical: EIGRP kept its predecessor protocol's composite formula and multiplied it by 256 to widen a 24-bit metric to 32 bits. - **Reliability drops out cleanly.** The full formula multiplies by `K5 / (REL + K4)`, but RFC 7868 defines that reliability quotient to be 1 whenever `K5` is 0, so the default metric is not zeroed by it. ## What the two terms mean in practice 1. **The bandwidth term is a weakest link.** It looks only at the slowest link on the path. Adding more fast hops does not change it, and one slow hop dominates however fast the rest are. 2. **The delay term is what makes path length count.** Every hop adds its interface delay, so among paths with the same bottleneck the one with less accumulated delay — usually the shorter one — wins. 3. **Delay is configured, not measured.** RFC 7868 describes it as an administrative value assigned per interface to represent the time across an unloaded path. A congested link does not report a higher delay. The per-interface default values come from the implementation, not from the protocol. 4. **The result is compared, then advertised onward.** The router keeps the route with the lowest composite metric and advertises the updated vector — not the composite number — to its own neighbours, who apply the same K-values. That last point is why the K-values are an adjacency matter: every router must turn the same vector into the same ranking. Which checks a new neighbour must pass belongs to EIGRP's neighbour formation; the reason behind this one is the metric's. ## Common mistakes - Treating the bandwidth term as a sum or an average of the links. It is the minimum. - Believing EIGRP measures latency. The delay is a static per-interface value. - Listing MTU as a metric input. It travels in the vector so the path's smallest MTU is known, and the RFC excludes it from the calculation. - Counting hops. The hop count is carried in the vector but is not one of the weighted terms. - Saying load and reliability are part of the default metric. They are carried, and their weights are zero.

  • If load and reliability are not used by default, why does EIGRP carry them in every route at all?
    Because the K-values can switch them on. RFC 7868 lets K2 weigh load and K4 and K5 weigh reliability, so the vector must carry them for any router to apply those weights. With the defaults they are carried but multiplied by zero, or, for reliability, replaced by a quotient of 1.
  • Two EIGRP paths share the same 100 Mb/s bottleneck; what decides between them?
    Only the delay term. The bandwidth terms are identical because both use the same minimum, so the path whose outgoing interfaces sum to less delay has the lower metric. With per-interface delays, that is usually the path with fewer or faster hops.

A convoy can travel no faster than its slowest truck, and every stop along the way adds waiting time. EIGRP's default metric is exactly that: the slowest link on the path plus the delay added at every hop.

saying these in an interview costs you the question

  • EIGRP adds up the bandwidth of every link on the path.
  • EIGRP measures each link's latency with probes and feeds that in.
  • MTU is one of the default composite-metric terms.
  • Load and reliability are always part of the metric.
  • A higher EIGRP metric means a better route.
open as a page

In EIGRP, what makes routing updates partial and bounded, and how does that differ from RIP's periodic full-table updates?

level: juniorimportance: must knowfreq 42%

basics

~20 s

EIGRP sends an UPDATE only when a route is added or its metric changes, carries only those prefixes, and the change stops spreading where no router's best path changes; RIP resends its whole table every 30 seconds.

open as a page

How do you compute an EIGRP path's classic composite metric by hand, and why can a longer path beat a shorter one?

level: middleimportance: must knowfreq 27%

basics

~20 s

With default K-values, the EIGRP classic metric is 256 × (10^7 / slowest bandwidth in kb/s + summed delay in tens of microseconds). Only the slowest link sets the bandwidth term, so a longer path with a faster bottleneck can win.

open as a page

In EIGRP, what is the feasibility condition, and how does it decide which neighbours become feasible successors for a prefix?

level: middleimportance: must knowfreq 30%

basics

~20 s

A neighbour meets EIGRP's feasibility condition when its reported distance to a prefix is strictly below this router's feasible distance, its best distance since the route last went passive; that neighbour is a feasible successor, a guaranteed loop-free backup.

open as a page

Two EIGRP routers on the same link can ping each other but never become neighbours; what do you check, and why?

level: middleimportance: must knowfreq 38%

basics

~20 s

First check that hellos cross the link: EIGRP enabled, IP protocol 88 and 224.0.0.10 not filtered. Then the three things RFC 7868 makes neighbours agree on: the AS number, the K-values and authentication. Hello and hold timers need not match.

open as a page

Which EIGRP packet types are sent reliably and which are not, and how does EIGRP carry an acknowledgement?

level: middleimportance: must knowfreq 30%

basics

~20 s

EIGRP sends UPDATE, QUERY and REPLY packets, with their SIA sub-types, reliably: each carries a nonzero sequence number that must be acknowledged. HELLOs go unreliably with sequence 0, and an ACK is a HELLO with no data and a nonzero acknowledgement number.

open as a page

Reading an EIGRP topology-table entry with three paths, how do you pick the successor and feasible successors, and which reach the routing table?

level: middleimportance: must knowfreq 34%

basics

~20 s

The successor is the path with the lowest computed distance, which sets the feasible distance; any other path whose reported distance is strictly below that feasible distance is a feasible successor. Only successors, including equal-cost ones, reach the routing table.

open as a page

When choosing between EIGRP and OSPF as an enterprise IGP, what design trade-offs separate the two protocols?

level: middleimportance: must knowfreq 40%

basics

~20 s

EIGRP gives precomputed feasible-successor failover, summarisation on any interface and implementation-provided unequal-cost load balancing, but is essentially single-vendor; OSPF is an open standard whose shared area database and area hierarchy demand more design but give visibility and interoperability.

open as a page

What does stuck-in-active mean for an EIGRP route, how do SIA-QUERY and SIA-REPLY change the outcome, and what usually causes it?

level: seniorimportance: must knowfreq 18%

basics

~20 s

An EIGRP route is stuck in active when a queried neighbour fails to reply in time; an SIA-QUERY asks whether it is still computing, an SIA-REPLY says yes, and a silent neighbour loses the route or its whole adjacency.

open as a page

With unequal-cost load balancing on an EIGRP router, which paths does a variance multiplier admit, and why must each be a feasible successor?

level: seniorimportance: must knowfreq 24%

basics

~20 s

Variance, an implementation feature RFC 7868 does not define, admits a path only if it is a feasible successor and its computed distance lies within variance times the best metric; feasibility is required because only those paths are proven loop-free.

open as a page

What is DUAL in EIGRP, and how does it let a router change paths after a failure without creating a routing loop?

level: juniorimportance: should knowfreq 25%

basics

~20 s

DUAL, the Diffusing Update Algorithm, is how EIGRP picks routes: it keeps backup next hops that pass a loop-freedom test and switches to one at once; when none exists, it freezes the route and queries its neighbours before choosing again.

open as a page

How does an EIGRP router discover its neighbours on a link, and how does it notice that one has disappeared?

level: juniorimportance: should knowfreq 28%

basics

~20 s

An EIGRP router multicasts hello packets to 224.0.0.10, by default every 5 seconds, and lists each sender in its neighbour table. Each hello advertises a hold time, 15 seconds by default; a neighbour silent for that long is declared down.

open as a page

Why does an EIGRP router keep a topology table as well as its routing table, and what does each one hold?

level: juniorimportance: should knowfreq 32%

basics

~10 s

The EIGRP topology table records every path any neighbour advertised for each destination, with its distances and route state; the routing table receives only the successor paths actually used to forward packets.

open as a page

Why do network designers usually pick OSPF over EIGRP when an enterprise network runs routers from more than one vendor?

level: juniorimportance: should knowfreq 35%

basics

~20 s

OSPF is an open IETF Standards Track protocol (RFC 2328 for IPv4, RFC 5340 for IPv6) implemented across router vendors, while EIGRP was one vendor's protocol until Informational RFC 7868 in 2016 and still has few other implementations.

open as a page

Why does an EIGRP router refuse to become neighbours with a router whose K-values differ, rather than peering and converting metrics?

level: middleimportance: should knowfreq 22%

basics

~20 s

K-values decide how each EIGRP router ranks paths from the vector its neighbours advertise. With different weights, two routers can rank the same paths in opposite orders, and DUAL's distance comparisons assume one shared metric, so RFC 7868 forbids the adjacency.

open as a page

Must EIGRP neighbours use the same hello and hold timers, and what breaks when a router's hello interval exceeds its advertised hold time?

level: middleimportance: should knowfreq 22%

basics

~20 s

No. Each EIGRP router advertises its own hold time in its hellos, and neighbours time it out on that value, so timers may differ. But if a router's hello interval exceeds the hold time it advertises, neighbours drop it between hellos.

open as a page

On a LAN with several EIGRP neighbours, how does the Reliable Transport Protocol deliver one UPDATE reliably to all of them?

level: middleimportance: should knowfreq 18%

basics

~20 s

The router multicasts the UPDATE once with a new sequence number and records it on every neighbour's retransmit list; each neighbour unicasts an acknowledgement of that number, and only neighbours that stay silent get unicast retransmissions.

open as a page

When two EIGRP routers first become neighbours, why do they exchange full tables by unicast when later updates are partial multicasts?

level: middleimportance: should knowfreq 15%

basics

~20 s

A new EIGRP neighbour has no topology to apply changes to, so each router sends it the full table by reliable unicast, after an empty INIT-flagged UPDATE proves unicast works both ways. Once synchronised, only changes are multicast.

open as a page

Why do EIGRP networks keep K2, K4 and K5 at zero, leaving load and reliability out of the composite metric?

level: seniorimportance: should knowfreq 14%

basics

~20 s

Load and reliability change with traffic and errors, so an EIGRP metric built on them would change too: traffic would swing between paths, every swing would trigger updates and possible recomputation, and every router would have to change K-values together.

open as a page

When an EIGRP router loses its successor and has no feasible successor, how does DUAL's query-and-reply diffusing computation find a new path?

level: seniorimportance: should knowfreq 15%

basics

~20 s

The EIGRP route goes active and unusable; the router queries its neighbours, unaffected ones reply at once, affected ones go active and query onward, and once every reply is in it resets its feasible distance and picks the best answer.

open as a page

How do summarisation and stub routing bound EIGRP's query domain, and why does a bounded query domain make DUAL more stable?

level: seniorimportance: should knowfreq 12%

basics

~20 s

An EIGRP query ends at any router with no entry for the failed prefix, which replies at once with an infinite metric; summarisation hides specific prefixes beyond a boundary, and stub routing, an implementation feature, exempts routers that offer no transit.

open as a page

Which events end an EIGRP adjacency, and why can a neighbour that dies behind a switch take far longer to notice than a cut cable?

level: seniorimportance: should knowfreq 18%

basics

~20 s

EIGRP adjacencies end on local link-down, hold-time expiry, 16 unacknowledged retransmissions or a signalled reset. Behind a switch the link stays up, so a dead neighbour on a quiet link is found when its hold time expires, up to 15 seconds by default.

open as a page

An EIGRP adjacency forms, then resets repeatedly while routes are being exchanged, although hellos flow normally both ways; what does that point to, and how do you confirm it?

level: seniorimportance: should knowfreq 12%

basics

~20 s

Healthy hellos prove only that small unacknowledged multicasts arrive. Resets during the table exchange point at reliable delivery failing: unicast UPDATEs, retransmissions or their acknowledgements are lost, so after the retry limit the neighbour is reset and the cycle repeats.

open as a page

When a router's best path to a prefix fails, how does EIGRP's feasible-successor failover differ from OSPF rerunning SPF, and when does EIGRP lose its advantage?

level: seniorimportance: should knowfreq 25%

basics

~20 s

With a feasible successor, an EIGRP router switches locally and the route stays passive; OSPF floods a new LSA and every router in the area reruns SPF. Without one, EIGRP must query its neighbours and can converge more slowly.

open as a page

In a 200-site hub-and-spoke enterprise, how do EIGRP and OSPF differ in where routes can be summarised and how spoke routers are kept small?

level: seniorimportance: should knowfreq 18%

basics

~20 s

EIGRP can summarise on any interface, so hubs send spokes a summary or default and an implementation's stub feature stops hubs querying spokes; OSPF summarises only at area borders, so spokes need their own, ideally stub, areas.

open as a page

When migrating an enterprise from EIGRP to OSPF with both running and mutual redistribution at two border routers, how do you prevent routing feedback loops?

level: seniorimportance: should knowfreq 15%

basics

~20 s

Tag each route where it is redistributed and refuse to redistribute it back: OSPF carries a 32-bit External Route Tag, EIGRP externals an administrative tag. Also seed metrics deliberately, migrate site by site and check route-source preference at the borders.

open as a page

Why does the classic EIGRP metric stop distinguishing links faster than 10 Gb/s, and what do RFC 7868's wide metrics change?

level: seniorimportance: nice to knowfreq 9%

basics

~20 s

The classic EIGRP bandwidth term, 10^7 over kb/s, truncates to 0 above 10 Gb/s, and delay counts in 10 µs units. Wide metrics carry unscaled bandwidth and picosecond delay, scale by 65,536 and compare a 64-bit metric.

open as a page

Why does EIGRP's feasibility condition guarantee that a feasible successor's path is loop-free, and why does it still reject some loop-free paths?

level: seniorimportance: nice to knowfreq 10%

basics

~20 s

A neighbour routing through this EIGRP router must report more than this router's feasible distance, having added positive link costs to its advertisement; a lower report proves independence. But a long independent path also reports high, so it is rejected too.

open as a page

An EIGRP router peers with any router that sends a valid hello; how do you stop a rogue device on a user LAN from becoming a neighbour?

level: seniorimportance: nice to knowfreq 12%

basics

~20 s

Stop sending and accepting EIGRP hellos on interfaces that face only hosts, and authenticate every adjacency that must exist, preferably with SHA2-256. The AS number and K-values are no defence: every hello carries them in clear text.

open as a page

Why does an EIGRP router choose an internal route to a prefix as successor even when an external route to it has a lower metric?

level: seniorimportance: nice to knowfreq 12%

basics

~20 s

RFC 7868 requires EIGRP to prefer internal routes over external ones regardless of metric: while any internal path exists, successors are chosen only among internal routes, which keeps redistributed copies from overriding routes that originate inside the EIGRP domain.

open as a page