skip to content

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%

answer

  1. two terms, then a constant multiplier
  2. kilobits per second, tens of microseconds
  3. only the slowest link counts
  4. truncate, add, multiply by 256

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.

solid answer

~40 s

With RFC 7868's default K-values the metric is `256 × (10^7 / BWmin + delay sum)`, where `BWmin` is the slowest link in kb/s, truncated after the division, and the delay sum is the outgoing interface delays in tens of microseconds. Three 100 Mb/s hops at 100 µs each give `256 × (100 + 30) = 33,280`. A 1 Gb/s hop at 10 µs followed by a 10 Mb/s hop at 1,000 µs gives `256 × (1,000 + 101) = 281,856`. The three-hop path wins because the bandwidth term only sees the bottleneck, and hop count is not a term at all.

code

pseudocode · 13 lines
pseudocode
function classicMetric(hops, K1=1, K2=0, K3=1, K4=0, K5=0):
    bw    = floor(10^7 / min(h.bandwidthKbps for h in hops))
    delay = sum(h.delayMicroseconds for h in hops) / 10   // tens of µs
    load  = max(h.load for h in hops)                      // 1..255
    rel   = min(h.reliability for h in hops)               // 1..255
    m = K1*bw + (K2*bw) / (256 - load) + K3*delay
    if K5 != 0:
        m = m * K5 / (rel + K4)    // K5 = 0 means the quotient is 1
    return 256 * m

// Path A: three hops of 100,000 kb/s at 100 µs  -> 256 * (100 + 30)   = 33,280
// Path B: 1,000,000 kb/s at 10 µs, then 10,000 kb/s at 1,000 µs
//                                                -> 256 * (1000 + 101) = 281,856

go deeper

for a junior

Remember the shape: a bandwidth term from the slowest link, plus a delay term, times 256. Lower wins.

for a middle

Compute it end to end with the units right, kilobits per second and tens of microseconds, and explain why the bottleneck dominates.

for a senior

Use the arithmetic to predict where traffic will go after a link change, and explain why tuning delay steers paths more safely than tuning bandwidth.

for a principal

Judge whether a static bottleneck-plus-delay ranking suits an estate whose capacity is uneven, and when its blind spots argue for a different design.

## The formula you compute EIGRP's **classic composite metric** is defined in RFC 7868 §5.6.1.1 with five weights, the **K-values**: ``` metric = 256 × ( K1×BW + (K2×BW)/(256 − LOAD) + K3×DELAY ) × ( K5 / (REL + K4) ) ``` - `BW` is `10^7` divided by the **minimum** bandwidth on the path, in **kilobits per second**. - `DELAY` is the **sum** of the outgoing interface delays along the path, in **tens of microseconds**. - `LOAD` and `REL` are values from 1 to 255; RFC 7868 defines the reliability quotient as 1 whenever `K5` is 0. With the defaults `K1 = K3 = 1` and `K2 = K4 = K5 = 0`, everything except two terms vanishes: ``` metric = 256 × ( 10^7 / BWmin_kbps + sum_of_delays_in_tens_of_µs ) ``` RFC 7868 also says to **truncate** the bandwidth division to an integer before multiplying by 256. ## The procedure, step by step 1. List the **outgoing interfaces** from this router to the destination, each with its bandwidth and its configured delay. 2. Take the **smallest bandwidth** and convert it to kb/s (100 Mb/s is 100,000 kb/s). 3. Compute the bandwidth term: `10^7 / BWmin`, truncated. 4. **Add up the delays** and convert microseconds to tens of microseconds (divide by 10). 5. Add the two terms and **multiply by 256**. 6. Repeat for every candidate path; the **lowest** result is the best route. ## A worked comparison Two paths lead to the same prefix. The delays below are the values configured on each outgoing interface. | | Path A | Path B | |---|---|---| | Links | three hops of 100 Mb/s | 1 Gb/s, then 10 Mb/s | | Delays | 100 µs + 100 µs + 100 µs | 10 µs + 1,000 µs | | Slowest link | 100,000 kb/s | 10,000 kb/s | | Bandwidth term | 10^7 / 100,000 = **100** | 10^7 / 10,000 = **1,000** | | Delay term | 300 µs = **30** | 1,010 µs = **101** | | Metric | 256 × 130 = **33,280** | 256 × 1,101 = **281,856** | **Path A wins by a factor of more than eight**, although it has one more hop. Path B's single 10 Mb/s link sets its bandwidth term to 1,000, ten times Path A's, and its fast first hop cannot buy any of that back, because the bandwidth term only ever sees the slowest link. The same table shows the other half of the formula: Path B's delay term is also larger, because one slow interface carries a large configured delay. Both terms point the same way here, but the bandwidth term moves the result most. ## Why a longer path can beat a shorter one - **Hop count is not a term.** EIGRP carries a hop count in the route's vector, but the default weights never multiply it into the metric. - **The bottleneck dominates.** The bandwidth term grows as the inverse of the slowest link, so a single slow hop can add far more than any number of fast hops add through their delays. - **Delay is the only length-sensitive term.** Each extra hop adds its interface's delay, which is small on fast links, so extra fast hops cost little. - **Units decide the answer.** Using megabits instead of kilobits, or microseconds instead of tens of microseconds, changes the numbers by orders of magnitude, which is why interviewers watch the units more than the multiplication. ## When the defaults are not in force The same procedure extends to non-default weights, which interviewers sometimes add as a twist: - If `K2` is non-zero, add the load term `(K2×BW)/(256 − LOAD)`, using the **maximum** load along the path; it grows sharply as the load approaches 255. - If `K5` is non-zero, multiply the sum by `K5 / (REL + K4)`, using the **minimum** reliability along the path, where 255 means fully reliable. - If `K1` or `K3` changes, scale that term by the new weight before adding. - Every EIGRP neighbour must run the same K-values, so a calculation with non-default weights describes every router in the domain, never just one. ## Checking your arithmetic A fast sanity check: a single 10 Mb/s Ethernet hop with a 1 ms delay — the example RFC 7868 itself uses — gives a bandwidth term of 1,000 and a delay term of 100, so 256 × 1,100 = 281,600. Path B above is that hop plus 10 µs of extra delay, which is why it lands only 256 higher, at 281,856.

  • Why does RFC 7868 tell implementations to truncate the bandwidth division before scaling?
    So every router turns the same bandwidth into the same integer term. If one router kept a fraction and another rounded it away, the two would compute different metrics from the same advertised vector, and a protocol that relies on every router ranking paths identically cannot afford that.
  • Path A's metric is 33,280; how much extra configured delay on its links would make it lose to a path whose metric is 40,960?
    40,960 / 256 = 160, and Path A's terms sum to 130, so its delay term must grow by more than 30 tens of microseconds. Adding more than 300 µs of configured delay across its outgoing interfaces makes Path A's metric exceed 40,960, and the other path wins.

saying these in an interview costs you the question

  • Enter the bandwidth in megabits per second rather than kilobits.
  • Add the delays in microseconds without converting to tens of microseconds.
  • Use the average of the links' bandwidths instead of the minimum.
  • Forget the final multiplication by 256 and report the raw sum.
  • Each extra hop adds a fixed penalty to an EIGRP metric.