Why does EIGRP use bandwidth + delay for its metric instead of hop count like RIP?

Question

I just moved from the RIP chapter to EIGRP in the course and I'm a bit confused. RIP was simple — count the hops, lowest wins, max 15. But EIGRP apparently uses this composite metric with bandwidth and delay (and load/reliability?) and I don't really get *why* it's more complicated.

What problem does bandwidth + delay actually solve that hop count doesn't? And when EIGRP picks a path, which one "wins" — the fewest hops or something else? Trying to build the right mental model before I do the lab. 🙂

ben31833 · Accepted Answer

RIP only counts hops, so it has no idea a link is fast or slow — a 3-hop path over Gigabit loses to a 1-hop path over a 64k serial link. EIGRP fixes that by building a **composite metric** from bandwidth and delay.

Default metric (K1=K3=1, K2=K4=K5=0):

```
metric = (10^7 / min_bandwidth_kbps + sum_of_delays / 10) * 256
```

- **bandwidth** = the *slowest* link along the path (the bottleneck), in kbps
- **delay** = the *cumulative* interface delay of every hop, in microseconds
- the `*256` is just the wide-metric scaling

Two consequences worth internalizing:

1. Bandwidth is a min, delay is a sum. Adding a fast hop barely moves the metric; adding a slow hop can dominate it.
2. Only bandwidth+delay count by default. Load and reliability are in the formula but weighted 0 — leave the K-values alone unless you really mean it, and they must match on both neighbors or the adjacency won't form.

Lowest composite metric to a destination = the **feasible distance**, and that neighbor becomes the **successor** (installed route). A backup (feasible successor) is any neighbor whose advertised distance is less than your FD — that's the feasibility condition DUAL uses to guarantee a loop-free instant failover.

In the lab: build R1-R2-R3, run EIGRP, then `show ip eigrp topology` — you'll see FD and the reported distance side by side.

Shira Sivroni · Answer

Ben nailed the formula; here's the practical angle. The number that trips people up is **delay**, because it's not measured — it's a static per-interface value you can read with `show interfaces`. So EIGRP's "cost" is deterministic, not live traffic-based (load is off by default for exactly that reason — you don't want routes flapping with congestion).

Quick way to see path selection in action:

1. `show ip eigrp neighbors` — confirm the adjacency is up first.
2. `show ip route eigrp` — the installed successor.
3. `show ip eigrp topology` — FD vs. the neighbors' advertised distance; that's where you spot a feasible successor.

If a path you expected isn't chosen, check the **bottleneck bandwidth** — one slow serial anywhere on the path caps the whole thing. And remember the bandwidth EIGRP uses comes from the `bandwidth` interface command, which is often wrong/default and doesn't change actual throughput — it only steers routing. That mismatch is the #1 "why did it pick that path?" gotcha.

Why does EIGRP use bandwidth + delay for its metric instead of hop count like RIP?

2 Answers

Your answer