EIGRP metric questions usually test three things: which inputs matter by default, how bandwidth and delay combine, and why mismatched K-values prevent neighbors from forming.
Short answer: with default K-values, EIGRP uses minimum path bandwidth and cumulative delay; for classic metrics, the calculation is 256 × (10^7 / minimum bandwidth in kbps + total delay in tens of microseconds).[1]
K1 and K3 default to 1; K2, K4 and K5 default to 0, so load and reliability do not contribute to the default calculation.[1]
What do EIGRP K-values mean?
K-values are coefficients that control the composite metric calculation, not measurements of the interfaces themselves.[1]
| Coefficient | Default | Role |
|---|---|---|
| K1 | 1 | Bandwidth term.[1] |
| K2 | 0 | Load adjustment to the bandwidth term.[1] |
| K3 | 1 | Delay term.[1] |
| K4 and K5 | 0 and 0 | Reliability-related factor.[1] |
| K6 | 0 | Extended attributes in wide metrics; not part of the classic five-coefficient formula.[1] |
When K5 is zero, the reliability factor is defined as one, not zero; otherwise a literal substitution into the general formula would incorrectly erase the entire metric.[1] MTU is carried in EIGRP vector metrics but does not participate in the classic composite metric calculation.[1]
For an interview, start with the default bandwidth-plus-delay behavior before discussing optional coefficients. Do not claim that EIGRP automatically chooses the least-congested link just because load appears among its possible inputs: K2 is zero by default.[1]
Classic EIGRP metric: get the units right
Use this form for the default classic calculation; the bandwidth quotient is truncated before the scaling factor is applied.[1]
B = floor(10,000,000 / minimum path bandwidth in kbps)
D = sum of outbound interface delays in tens of microseconds
Classic metric = 256 × (B + D)
Bandwidth is a bottleneck value: take the lowest bandwidth along the path, not the sum or average.[1] Delay is cumulative: add the outbound interface delays along the path toward the destination.[1] These are routing metric inputs, not the round-trip time from a ping test; the RFC describes interface-provided or bandwidth-derived one-way delay values.[1]
Worked example: two paths to the same prefix
This is an original teaching example, not captured router output. Assume classic metrics, default K-values, usable candidate paths to 192.0.2.0/24, and that the following figures already cover each complete path, including the destination-facing component.
| Candidate | Minimum bandwidth | Total delay | Bandwidth term B | Delay term D | Classic metric |
|---|---|---|---|---|---|
| Path A | 100,000 kbps | 200 microseconds | 100 | 20 | 30,720 |
| Path B | 1,000,000 kbps | 2,000 microseconds | 10 | 200 | 53,760 |
Path A: 256 × (100 + 20) = 30,720
Path B: 256 × (10 + 200) = 53,760
Path A has the lower metric despite its lower bottleneck bandwidth: the larger cumulative delay makes Path B more expensive under the default formula.[1] These example calculations were checked locally in Python; no router lab was run.
Do not turn this into “lowest metric is the whole EIGRP algorithm”: DUAL also applies its feasibility rules when choosing safe successors.[1] See the related successor/feasible-successor article for that separate question.
How the metric travels through the routing process
The following is a conceptual process flow, not a packet capture:
- Neighbors exchange Hellos containing their configured K-values; the values must agree for adjacency formation.[1]
- Routing updates carry vector metric information, allowing a receiving router to calculate a complete path through the advertising neighbor.[1]
- The router combines path inputs: the bandwidth bottleneck remains the minimum, while local outbound delay adds to the path delay.[1]
- EIGRP computes a scalar metric using its coefficients, and DUAL evaluates candidate next hops with its loop-prevention rules.[1]
An important consequence is that you should not simply add two already-computed EIGRP composite metrics to calculate a longer path. The bandwidth term is derived from a minimum, not an additive link-cost sum.[1]
Why must K-values match between neighbors?
EIGRP Hellos include the metric coefficients, and the protocol requires neighbors to use matching K-values so that their metric interpretation is consistent.[1] A K-value mismatch is therefore an adjacency problem, not merely a reason one router prefers a different path.[1]
Matching K-values does not mean matching interface bandwidth and delay settings. Coefficients select how inputs are weighted; interface values describe the individual links.[1]
Suggested troubleshooting order:
- Compare the active EIGRP process, address family and VRF on both ends.
- Read the actual K-values, rather than assuming both sides use defaults.
- Correlate adjacency loss with recent metric-weight changes and logs.
- If coefficients match, broaden the investigation to AS number, authentication and packet delivery; matching K-values alone is not a complete adjacency test.[1]
- Preserve configuration and logs before clearing neighbors or editing metric weights.
Do not change coefficients on one production router as an experiment. Treat domain-wide metric changes as a planned migration with rollback, not a quick fix for one undesirable path.
Verification commands and unexpected metrics
Illustrative Cisco IOS/IOS XE IPv4 checks are shown below. Command availability and syntax depend on release, VRF and classic versus named configuration mode; this is not a tested device transcript.
show ip protocols
show ip eigrp neighbors
show ip eigrp topology 192.0.2.0 255.255.255.0
show interfaces GigabitEthernet0/0
show running-config
| Observation | Next check |
|---|---|
| Expected neighbor is missing | Compare process context and K-values on both endpoints; inspect logs. |
| Manual result is much too large | Check whether delay was left in microseconds instead of tens of microseconds. |
| Bandwidth change has no routing effect | Determine whether another link is still the path bottleneck. |
| A fast path loses to a slower path | Compare total delay, not just interface speed. |
| Topology metric differs from your classic calculation | Identify whether wide metrics are in use before comparing numbers. |
The RFC discourages changing bandwidth merely to steer routing: a change only affects the metric when it changes the path minimum, and bandwidth configuration also influences EIGRP packet pacing.[1] For a lab, compare a deliberate delay adjustment with a bandwidth adjustment, recording both the topology entry and interface values before and after. In production, review other consumers of those interface settings before applying either change.
Classic versus wide metrics
The classic formula above is not a universal calculator for every EIGRP deployment: wide metrics change the vector representation and composite calculation to better distinguish high-bandwidth paths.[1] Wide metrics retain the default emphasis on minimum throughput and accumulated latency, and introduce K6 for extended attributes.[1]
Before declaring an output wrong, identify the metric mode and the exact software's display behavior. Do not assume that a value copied from a topology display and a value shown elsewhere use identical scaling.
Common interview pitfalls
- “EIGRP sums interface bandwidths.” It uses the minimum bandwidth along the path.[1]
- “Delay means measured ping latency.” Metric delay is an interface-provided or derived input, not a ping RTT.[1]
- “All five classic inputs are active by default.” Only bandwidth and delay contribute with default coefficients; MTU is not a classic metric term at all.[1]
- “K5 equals zero, so the metric equals zero.” The reliability multiplier is defined as one in that case.[1]
- “Neighbors can use different metric coefficients.” K-values must match for adjacency formation.[1]
- “The classic formula reproduces every modern display.” Wide metrics use a different calculation.[1]
A concise interview answer
“EIGRP uses a composite metric whose default inputs are minimum path bandwidth and total delay, with K1 and K3 set to one and the other classic coefficients set to zero.[1] For classic metrics I invert bandwidth in kbps, add delay in tens of microseconds, and multiply by 256.[1] K-values must match between neighbors, but their individual interface bandwidth and delay values do not have to be identical.[1] I would check the configured coefficients, units and metric mode before troubleshooting an unexpected result.”
Related reading
- EIGRP Successor and Feasible Successor: FD, RD and the Feasibility Condition
- EIGRP Stuck in Active: Troubleshooting and Prevention
Summary
Remember minimum bandwidth, accumulated delay, matching coefficients, and the correct metric mode.[1] Preparing for a network engineering interview? Recalculate both example paths without looking, explain why the faster path loses, and name the first checks you would make for a K-value mismatch.
Sources
- [1] RFC 7868: EIGRP
Post a Comment