Why does the classic EIGRP metric stop distinguishing links faster than 10 Gb/s, and what do RFC 7868's wide metrics change?

## The classic metric's resolution EIGRP's **classic** composite metric, with default K-values, is ``` metric = 256 × ( 10^7 / BWmin_kbps + sum_of_delays_in_tens_of_µs ) ``` Both terms are integers, and both run out of resolution on fast links. - **The bandwidth term.** RFC 7868 tells implementations to truncate `10^7 / BWmin` to an integer before scaling. That gives 10 for 1 Gb/s and 1 for 10 Gb/s. For anything faster, the quotient is below 1 and truncates to **0**: a 20, 50 or 100 Gb/s bottleneck all produce the same term. - **The delay term.** Delay is counted in **tens of microseconds**. RFC 7868's interface-delay compatibility table, which records one implementation's default values, gives every interface type from 1 Gb/s up the same classic delay, 10 µs — one unit — so unless an operator configures different delays, delay cannot separate them either. | Bottleneck | Bandwidth term | Classic delay (one hop) | Classic metric | |---|---|---|---| | 1 Gb/s | 10 | 10 µs = 1 | 256 × 11 = **2,816** | | 10 Gb/s | 1 | 10 µs = 1 | 256 × 2 = **512** | | 50 Gb/s | 0 | 10 µs = 1 | 256 × 1 = **256** | | 100 Gb/s | 0 | 10 µs = 1 | 256 × 1 = **256** | A single 50 Gb/s hop and a single 100 Gb/s hop get **identical** metrics, and 10 Gb/s differs from them by one unit where the real capacity differs five- or tenfold. In a fabric of 10, 40 and 100 Gb/s links, the classic metric cannot prefer the fat links. ## What wide metrics change RFC 7868 §5.6.2 introduces **wide metrics** precisely "to enable EIGRP to perform the path selection for interfaces with high bandwidths". Three things change: 1. **Finer units on the wire.** The multiprotocol route TLV carries delay in **picoseconds** and bandwidth in kilobits per second, both **unscaled** and 48 bits wide, instead of the classic TLV's 32-bit pre-scaled fields. 2. **A larger scale factor.** Throughput and latency are each multiplied by `EIGRP_WIDE_SCALE = 65,536` instead of the classic 256, so fractions that the classic formula truncated away become distinct integers. 3. **A 64-bit composite.** The composite is a 64-bit quantity; the RFC's unreachable constant is `0xFFFFFFFFFFFFFFFF`. The conversions in RFC 7868 §5.6.2.3 and §5.6.2.4 are: ``` Throughput = K1 × (10,000,000 × 65,536) / bandwidth_kbps Latency = K3 × (delay_ps × 65,536) / 1,000,000 metric = K1 × min(Throughput) + K3 × sum(Latency) (defaults) ``` With the compatibility table's wide-metric delays — 1,000 ns for 10 Gb/s, 200 ns for 50 Gb/s, 100 ns for 100 Gb/s — one hop gives: | Link | Throughput | Latency | Wide metric (approx.) | |---|---|---|---| | 10 Gb/s | 65,536 | 65,536 | 131,072 | | 50 Gb/s | ≈13,107 | ≈13,107 | ≈26,214 | | 100 Gb/s | ≈6,554 | ≈6,554 | ≈13,107 | Now each speed has its own metric, in proportion to its capacity. ## The extra weight: K6 Wide metrics add **`K6`**, which weights **extended attributes** carried with the route. RFC 7868 defines two, **jitter** and **energy**, both accumulated along the path. `K6` defaults to 0, and the RFC notes that EIGRP itself does not currently measure either, so by default they are absent. ## Living with both - **Two encodings on one link.** RFC 7868's TLV-version rules say routers using the older TLVs do not understand the newer ones, so a router speaking both must send updates in **both formats** in a mixed network. When the best path was learned from an older neighbour, the classic scaled metric it sent may be attached as an extended attribute, for information only. - **Different magnitudes.** Classic and wide metrics for the same path are different numbers on different scales, so any threshold or comparison written against one does not transfer to the other. - **Move the domain together.** Like K-values, the metric style is part of how every router ranks paths, so a design migrates the whole EIGRP domain rather than leaving a long mixed period. ## Common mistakes - Believing the classic metric just needs a bigger multiplier. The truncation happens before the multiplier, so the information is already lost. - Thinking EIGRP measures the picosecond delays. They are still configured or interface-derived values, just carried at finer resolution. - Assuming wide metrics change the default inputs. By default they still use minimum throughput and accumulated latency.