skip to content

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%

answer

  1. same vector, different verdicts
  2. weights are the ranking itself
  3. carried in the hellos
  4. one metric for every comparison

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.

solid answer

~40 s

Neighbours advertise each route's vector — minimum bandwidth, delay, load, reliability, MTU, hop count — and every router turns it into a composite metric with its own K-values. The K-values are not a unit that could be converted; they are the ranking. A router with `K3 = 0` ranks a 1 Gb/s path with 20 ms of delay above a 100 Mb/s path with 300 µs, while a default router ranks them the other way round. DUAL's feasibility condition compares a neighbour's reported distance against the router's own feasible distance, and that comparison only means something under one metric. So RFC 7868 carries the K-values in the parameter TLV of its hellos, and two routers become neighbours only if they match.

go deeper

for a junior

Recall the rule: EIGRP neighbours must have the same K-values, or they do not become neighbours at all.

for a middle

Explain that neighbours exchange vectors and each router applies its own K-values, so different weights produce different rankings of the same paths.

for a senior

Tie the rule to DUAL: the reported-distance versus feasible-distance comparison only means something under one metric, and plan K-value changes as domain-wide events.

for a principal

Weigh whether non-default K-values are ever worth a domain-wide coupling that turns every tuning change into a coordinated outage risk.

## What the K-values are EIGRP's composite metric is a weighted formula over the path properties every route carries — minimum bandwidth, total delay, load and reliability. The weights are the **K-values**, `K1` to `K5` for the classic metric and `K6` for the extended attributes of the wide metrics. RFC 7868 sets the defaults to `K1 = K3 = 1` and every other K-value to 0, which leaves only bandwidth and delay in the formula. Each K-value is an 8-bit field, and the RFC allows values up to 254. The K-values are not a local display preference. They decide **which of two paths a router believes is better**. ## Where the check happens RFC 7868 puts the K-values in the **parameter TLV** of HELLO packets, beside the hold time, and states the rule plainly: two routers become neighbours **only if their K-values are the same**, which "enforces that the metric usage is consistent". A router whose K-values differ from its neighbour's never forms the adjacency, so it neither sends nor accepts routes over that link. The rest of the adjacency checklist belongs to EIGRP neighbour formation; this answer is about why this item is on it. ## Why "just convert" does not work A tempting idea is to let the routers peer and have each translate the other's numbers. There is nothing to translate: 1. **Neighbours exchange vectors, not verdicts.** An EIGRP update carries each route's vector — minimum bandwidth, delay, load, reliability, MTU, hop count. Each receiving router computes its own composite metric from that vector with its own K-values. 2. **The K-values are the ordering itself.** They do not change a unit, as metres and feet do; they change which properties matter. Two weightings can rank the same pair of paths in opposite orders, and no conversion maps one ranking onto the other. 3. **DUAL compares distances across routers.** EIGRP's loop-free algorithm keeps a route without recomputation only when a neighbour's **reported distance** is strictly lower than the router's own **feasible distance**. That test, and the reasoning that makes it loop-free, is written for one metric that every router applies in the same way. ## A worked disagreement Take two paths to the same prefix and two routers, X with `K3 = 0` (bandwidth only) and Y with the defaults: | Path | Slowest link | Total delay | Y's metric (default) | X's metric (K3 = 0) | |---|---|---|---|---| | P1 | 1 Gb/s | 20,000 µs | 256 × (10 + 2,000) = **514,560** | 256 × 10 = **2,560** | | P2 | 100 Mb/s | 300 µs | 256 × (100 + 30) = **33,280** | 256 × 100 = **25,600** | Y prefers **P2**; X prefers **P1**. Neither is wrong by its own rule, but they no longer agree what "best" or "closer to the destination" means. Inside one EIGRP domain that leaves: - route choices that can differ hop by hop for the same destination, so the path a packet takes is no longer predictable from either router's view; - reported and feasible distances that mean different things on each side of a link, which is exactly the comparison the feasibility condition depends on; - troubleshooting that cannot assume one metric when reading either router's tables. Rather than reason about mixed weightings, RFC 7868 rules them out at the hello. ## What this means in operation - **Changing K-values is a domain-wide change.** The moment one router's K-values change, its adjacencies with every unchanged neighbour go down. A real change is planned as a maintenance event across every router in the domain, not as a per-router tweak. - **A mismatch is a hard stop, not a degraded state.** The routers do not peer with a warning; they simply never become neighbours, and the symptom is missing routes rather than odd metrics. - **The defaults are the norm.** Because every router must match and the defaults leave load and reliability out on purpose, almost every EIGRP network runs them unchanged. - **Reading the symptom.** If one router recently had its K-values edited and its neighbours vanished at the same moment, the K-values are the first thing to compare. ## Common mistakes - Thinking K-values are a local preference each router can set freely. - Expecting the routers to peer and negotiate one set of K-values. - Believing the routers convert each other's metrics into their own weighting. - Thinking a mismatch only produces suboptimal routes rather than no adjacency.

  • How would you change the K-values on a running EIGRP network?
    As a planned domain-wide change. Each router whose K-values change drops its adjacencies with neighbours that still run the old values, so routes disappear until both sides match. Plan a maintenance window, change every router in the domain, and expect a period of lost adjacencies while the change rolls out.
  • Does a K-value mismatch show up as bad routes or as missing routes?
    As missing routes. The routers never become neighbours, so no updates cross that link and the prefixes behind it are simply absent, or reached another way. Odd metrics with working adjacencies point somewhere else, such as a changed interface delay.

saying these in an interview costs you the question

  • Routers with different K-values peer and negotiate a common set.
  • Each router converts its neighbour's metrics into its own weighting.
  • K-values are a local preference that need not match between routers.
  • A K-value mismatch only makes routes suboptimal; the adjacency stays up.
  • Only K1 and K3 have to match; the zero-valued K-values are ignored.