Why do EIGRP networks keep K2, K4 and K5 at zero, leaving load and reliability out of the composite metric?
answer
- configured versus live values
- the metric chases its own traffic
- every change is an update
- snapshot taken at link change
basics
~20 sLoad 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.
solid answer
~40 sLoad enters RFC 7868's formula through `K2` as `(K2×BW)/(256 − LOAD)`, and reliability through the multiplier `K5/(REL + K4)`. Unlike configured bandwidth and delay, both describe what a link is doing now. With load in the metric, traffic moves to the better path, its load rises, it stops being best, and traffic swings back; every swing is a routing update, and a route with no feasible successor goes active and sends queries. The RFC also notes that one implementation samples them only when a link changes, so they may be stale anyway. And K-values must match on every neighbour, so the change is domain-wide. To steer paths, change interface delay instead.
go deeper
Recall that load and reliability exist as optional metric terms and are switched off by default.
Read the formula: K2 brings in load, K4 and K5 bring in reliability, and K5 = 0 makes the reliability quotient 1.
Explain the oscillation and churn a load-sensitive metric causes, the stale-sampling caveat, and why delay is the knob to turn instead.
Argue where congestion response belongs in a design, in queueing and traffic engineering rather than in the routing protocol's ranking of paths.
## The optional terms EIGRP's classic composite metric, as RFC 7868 §5.6.1.1 writes it, has room for four path properties: ``` metric = 256 × ( K1×BW + (K2×BW)/(256 − LOAD) + K3×DELAY ) × ( K5 / (REL + K4) ) ``` - **Load** (`LOAD`, 1 to 255, where 255 is a saturated link) enters through `K2`. The term `(K2×BW)/(256 − LOAD)` grows sharply as load approaches 255; RFC 7868 notes that `K2` has its greatest effect once load passes 90 %. - **Reliability** (`REL`, 1 to 255, where 255 is a perfectly reliable link) enters through the multiplier `K5 / (REL + K4)`. When `K5` is 0, RFC 7868 defines that quotient as 1, so reliability has no effect. - The defaults are `K1 = K3 = 1` and `K2 = K4 = K5 = 0`: bandwidth and delay only. Along a path, the vector keeps the **maximum** load and the **minimum** reliability, so one busy or lossy link sets the value for the whole route. ## Why live values make a bad metric Bandwidth and delay are **static** per-interface values; they change when the configuration or the interface changes, not with traffic. Load and reliability describe **what the link is doing now**. A metric built on them inherits that motion: 1. **Traffic oscillation.** Suppose two paths and load in the metric. Traffic piles onto the better path, its load rises, its metric worsens, and the other path becomes best. Traffic moves, the first path's load falls, it becomes best again, and the cycle repeats. The metric chases the traffic it is steering. 2. **Control-plane churn.** Every metric change is a routing change. EIGRP must send updates to its neighbours, who recompute and update theirs. 3. **Recomputation risk.** If a route's current path worsens and no neighbour meets the feasibility condition, the route goes **active** and EIGRP sends queries until it is resolved. A metric that moves with traffic makes that happen far more often than one that moves only when the topology changes. 4. **A whole-metric surprise from reliability.** With `K5 = 1` and `K4 = 0`, a perfectly reliable path is multiplied by `1/255`. Turning reliability on changes the magnitude of every route's metric, not only the lossy ones. ## The sampling problem RFC 7868's implementation note adds a second reason. In one implementation, load and reliability "are not dynamically measured; they are only measured at the time a link changes". So switching them on may not even track congestion: the metric captures a snapshot from the last link event, which can be long out of date. Either way — chasing live values or freezing stale ones — the result is worse than leaving them out. ## What turning them on actually costs | Choice | Effect on paths | Operational cost | |---|---|---| | Defaults (`K2 = K4 = K5 = 0`) | stable ranking by bottleneck and delay | none: the norm | | `K2 > 0` (load) | paths shift as utilisation changes, or reflect a stale snapshot | oscillation, update churn, more active routes | | `K5 > 0` (reliability) | every metric rescaled; lossy links penalised | the same churn, plus metrics no longer comparable with earlier baselines | And because neighbours must have identical K-values to peer, **any** of these changes has to be made on every router in the domain at once; a router changed alone loses its adjacencies. ## What to do instead - **Steer with delay.** RFC 7868's network-designer note recommends changing a link's configured delay to influence path selection, because delay affects only the metric calculation. - **Leave bandwidth alone.** The same note discourages lowering a link's configured bandwidth: it only matters if it becomes the path's minimum, other features such as quality of service read it too, and EIGRP paces its own packets to use no more than 50 % of the configured bandwidth, so a lowered value can starve an adjacency and slow convergence. - **Handle congestion where it lives.** Queueing and traffic engineering react to load without asking the routing protocol to rerank every path. ## Common mistakes - Believing load is in the default metric and EIGRP reroutes around busy links. - Assuming reliability is a percentage of uptime rather than an error-based value from 1 to 255. - Thinking a K-value change on one router is safe to try in isolation. - Lowering bandwidth to steer traffic, then wondering why the adjacency struggles.
- If you must steer EIGRP traffic away from one of two links, what should you change, and why not bandwidth?Raise the configured delay on the link you want to avoid. RFC 7868 notes that delay affects only the metric. Lowering bandwidth only counts if it becomes the path's minimum, other features such as quality of service read it, and EIGRP paces its packets to 50 % of the configured bandwidth, so a low value can starve the adjacency.
- With K5 = 1 and K4 = 0, what happens to a perfectly reliable path's EIGRP metric?It is multiplied by K5 / (REL + K4) = 1/255, so it shrinks by a factor of 255. Every route's metric changes scale, not only those over lossy links, which is one reason turning reliability on is a disruptive, domain-wide decision.
saying these in an interview costs you the question
- EIGRP's default metric routes around congested links automatically.
- Turning on load weighting makes EIGRP converge faster.
- With K5 = 0 the reliability multiplier zeroes the whole metric.
- A K-value change can be trialled safely on a single router.
- Lowering interface bandwidth is the cleanest way to steer EIGRP paths.