First and foremost, the metric has been reworked.
EIGRP named mode automatically uses wide metrics when speaking to another EIGRP named mode process. No additional configuration is necessary, this is automatic. So if it’s speaking to a traditional EIGRP process, it uses the old calculations.
The new metric is designed to be able to differentiate paths above 10GB. The new metric essentially changes four things:
– Delay is now measured in picoseconds instead of microseconds. 10ms was the minimum previously.
– Bandwidth’s scaling factor is made much larger, the calculation is now 10^7 * 65536 / Interface Bandwidth, as opposed to the original 10^7 * 256 / Interface Bandwidth.
– The overall metric is now 64 bit.
– The K6 value has been added “for future use”, but Cisco has indicated this will be used for accumulated energy or accumulated jitter. Jitter is reasonsably obvious. Energy is the actual electric power it takes to use an interface, so that you could literally do “least cost” routing based on how inexpensively the packet can be sent from the various interface types in a path.
One important note here is that with wide metrics, the EIGRP calculated metric no longer fits into the RIB. For example:
Router#sh ip eigrp top 10.10.10.10/32 | i Composite metric
Composite metric is (330301440/329646080), route is Internal
Router#sh ip route 10.10.10.10 | i Route metric
Route metric is 2580480, traffic share count is 1
The EIGRP topology table indicates 330301440, the RIB says 2580480.
The RIB’s metric can’t exceed 32-bits, and there are circumstances with the new, more granular metrics won’t fit into the RIB. So all metrics, regardless of if the value would fit into 32-bits, are divided by the rib-scale value. The rib-scale is 128 by default:
330301440/128 = 2580480
You can reassign it to any value 1 to 255:
router eigrp SOMENAME
address-family ipv4 unicast autonomous-system 100
metric rib-scale [1-255]
Here’s a catch – I’ve gotten in the habit of using this command for redistributing into EIGRP when labbing:
redistribute <some other protocol> metric 1 1 1 1 1
Why? It’s quick and easy to type if you’re not trying to do traffic engineering.
Router#sh ip eigrp top 18.104.22.168/32 | i Composite metric
Composite metric is (655361310720/655360655360), route is External
655361310720/128 = 5120005120
The largest number that can be represented in a 32-bit unsigned integer is 4,294,967,296.
5120005120 > 4294967296, therefore it cannot be represented in the RIB:
Router#sh ip route 22.214.171.124
% Network not in table
You read that right: This is a valid, routable prefix that simply can’t make it into the RIB because of compatibility between the EIGRP topology table and the RIB. You need to adjust the rib-scale to make this work:
Router(config-router-af)#metric rib-scale 153
Router(config-router-af)#do sh ip route 126.96.36.199 | i Route metric
Route metric is 4283407259, traffic share count is 1
I imagine that would make for a really good troubleshooting problem. “A route is being redistributed on R1 with a specific metric, but is not being installed in the RIB on R3. Do not change the metric on R1, or adjust with a route-map”.
There are a few concerns with interoperability between the traditional EIGRP metric and the wide metrics, but not many. As I mentioned above, routers unable to understand wide metrics are auto-detected and sent the old metric, however, there are circumstances where a route might get depreffed after having passed through an older EIGRP process. For example, if two paths exist to a destination, one of them running entirely wide metrics and a different one running one router with traditional metrics, the traditional metric may make the entire path look worse and it may impact load share, or the ability to ECMP.