EIGRP Wide Metrics: 64-Bit Metrics in Named Mode

If you have ever looked at show ip eigrp topology on a modern router and wondered why the metrics suddenly have nine or ten digits, you have met wide metrics. Named mode EIGRP replaced the classic 32-bit composite metric with a 64-bit version, and it changed more than the number of digits: delay is now measured in picoseconds, a scaling factor sits between EIGRP and the routing table, and mixed classic/named networks quietly do conversions on every boundary. This article decodes all of it with real output from the CML lab used across the EIGRP complete guide cluster.

Why 32 Bits Stopped Working

The classic metric formula (the full derivation is in the EIGRP metric and K values guide) scales bandwidth as 10^7 divided by the slowest link in kbps. Work that out for modern interfaces and the problem is obvious: a 10 Gbps link gives 10^7 / 10000000 = 1, and anything faster is also 1. A 10 Gbps path and a 100 Gbps path look identical to classic EIGRP. Delay has the same ceiling problem: it is counted in tens of microseconds, and high-speed links genuinely differ by nanoseconds.

Wide metrics fix both dimensions: the composite value grows to 64 bits, bandwidth is scaled from a 10 Tbps reference (EIGRP calls the term throughput), and delay becomes latency, measured in picoseconds. Faster-than-10G links finally sort correctly.

Spotting Wide Metrics on a Live Router

show ip protocols tells you immediately which world you are in. R1 runs named mode:

R1# show ip protocols | section eigrp
Routing Protocol is "eigrp 100"
  EIGRP-IPv4 VR(PINGLABZ) Address-Family Protocol for AS(100)
    Metric weight K1=1, K2=0, K3=1, K4=0, K5=0 K6=0
    Metric rib-scale 128
    Metric version 64bit
    Router-ID: 1.1.1.1

Three tells: a sixth K value (K6, for future jitter/energy attributes, default 0), Metric rib-scale 128, and Metric version 64bit. Compare classic-mode R3 in the same network:

R3# show ip protocols | section eigrp
Routing Protocol is "eigrp 100"
  EIGRP-IPv4 Protocol for AS(100)
    Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
    Router-ID: 10.1.3.1

Five K values, no metric version line, no rib-scale. Same AS, same adjacencies, two metric dialects.

Reading a Wide Metric Topology Entry

Here is R2 (named mode) looking at R3's loopback, with the vector metrics that feed the calculation:

R2# show ip eigrp topology 3.3.3.3/32
EIGRP-IPv4 VR(PINGLABZ) Topology Entry for AS(100)/ID(2.2.2.2) for 3.3.3.3/32
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 524288000, RIB is 4096000
  Descriptor Blocks:
  10.0.12.1 (Ethernet0/1), from 10.0.12.1, Send flag is 0x0
      Composite metric is (524288000/458752000), route is Internal
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 7000000000 picoseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2
        Originating router is 10.1.3.1

Two things to notice. First, Total delay is 7000000000 picoseconds: that is 7 ms expressed in picoseconds, the wide-metrics latency unit. Second, the header line shows both numbers: FD is 524288000 (the 64-bit EIGRP metric) and RIB is 4096000 (what actually goes into the routing table). Divide them: 524288000 / 128 = 4096000. That is rib-scale at work.

Why rib-scale 128 Exists

The routing table's metric field is still 32 bits. A 64-bit EIGRP metric could overflow it, so named mode divides by a scaling factor (default 128) before installing the route. The routing table entry confirms it:

R2# show ip route 3.3.3.3
Routing entry for 3.3.3.3/32
  Known via "eigrp 100", distance 90, metric 4096000, type internal
  * 10.0.12.1, from 10.0.12.1, via Ethernet0/1
      Route metric is 4096000, traffic share count is 1

The division is lossy on purpose: two paths whose 64-bit metrics differ by less than the scale factor land on the same RIB metric. DUAL still compares the full 64-bit values internally, so successor selection and the feasibility condition (the heart of the DUAL algorithm) are unaffected. Change it with metric rib-scale <value> under the topology base if you ever need finer RIB granularity; almost nobody does.

The Wide Metric Formula (What Changed, What Did Not)

With default K values the shape is the familiar one: metric = throughput term + latency term, just at 65536x resolution. Sanity check against the capture: min bandwidth 10000 Kbit gives 65536 x (10^7 / 10000) = 65536000. Total delay 7 ms is 7000 tens-of-microseconds units, and 7000 x 65536 = 458752000. Sum: 524288000. Exactly the FD the router printed. The math is the same math, with room to breathe.

Mixed Classic and Named Networks

Our lab deliberately mixes modes (R1/R2/R4 named, R3/R5 classic), and the adjacencies form fine: metric style is not one of the neighbor requirements (K values are, as covered in EIGRP neighbor requirements). When a wide-metric router advertises to a classic peer, values are scaled down and precision is lost; classic-originated routes are scaled up. You saw the two dialects side by side above: R3's FDs are numbers like 307200, R2's are numbers like 524288000. The practical rule: mixed mode works, but path selection on fast links is only trustworthy where wide metrics are end to end. That, plus SHA authentication support, is most of the case for migrating everything to named mode (walkthrough in the EIGRP configuration guide).

Note that OSPF suffered the same high-speed blindness with its default reference bandwidth, solved with auto-cost reference-bandwidth; the OSPF guide covers that side of the street.

Migration Notes: What Actually Changes on Conversion

Converting a classic router to named mode (eigrp upgrade-cli does it in place, preserving the AS number) switches the router to wide metrics as a side effect, and a few practical details follow:

• Interface commands do not change. delay is still configured in tens of microseconds and bandwidth in kbps; wide metrics change how EIGRP consumes those values (converting delay to picoseconds internally), not how you set them. Our lab's delay 200 on R2's alternate path became 2 ms, visible as 2000000000 picoseconds inside the vector metrics.
• Absolute metric values change everywhere. Any monitoring that alerts on specific metric numbers, any documentation quoting FDs, and any offset-list built around 32-bit values needs revisiting. Relative path preference is preserved on links 10 Gbps and below; what changes is the numbers themselves.
• Path selection can legitimately differ above 10 Gbps. That is the point of the feature: links that used to tie at bandwidth term 1 now sort correctly. If a migration changes a forwarding path, check whether the old path was only winning by rounding error.
• Tune delay, not bandwidth, before and after. The bandwidth value also feeds QoS percentage calculations and interface utilization graphs; delay exists only for routing metrics, which is why it has always been the recommended traffic-engineering knob.

What About K6, Jitter, and Energy?

The wide-metrics TLVs reserve room for two extended attributes, jitter and energy, with K6 as their weight. The idea was forward-looking (prefer low-jitter paths for voice without touching delay), but no shipping IOS XE measures or populates these attributes, so K6 stays 0 and the extended terms contribute nothing. Treat K6 as protocol headroom rather than a feature: it must still match between neighbors, like every other K value (a mismatch is the classic adjacency killer covered in the neighbor troubleshooting guide). If you want traffic steered by live path quality on Cisco gear today, that job moved to performance routing and SD-WAN, not to K6.

Key Takeaways

• Classic 32-bit metrics cannot tell a 10G link from a 100G link. Wide metrics (named mode) extend the composite to 64 bits and measure delay in picoseconds.
• Identify wide metrics instantly: Metric version 64bit, rib-scale 128, and a K6 value in show ip protocols.
• The topology table shows the 64-bit FD; the routing table shows FD divided by rib-scale. Both numbers are printed on the same line, so you can verify the division yourself.
• DUAL compares full 64-bit values, so feasibility and successor math keep full precision regardless of rib-scale.
• Classic and named routers interoperate with automatic scaling, but buy accurate high-speed path selection by going named mode everywhere.

Wide metrics are what let a 1989-vintage metric formula stay honest in a 100G world. For how the metric feeds DUAL, variance, and the rest of the machine, the EIGRP complete guide has the full map.