… updated on Wednesday, October 4, 2023 10:15 UTC
EIGRP MTU “metric”
Every so often I get a question about the MTU metric in EIGRP and whether it’s used at all or not. It’s supposed to be used (at least it was decades ago): if your router would have to ignore some equal-cost paths to the same destination (the number of equal-cost paths exceeds the value of the maximum-paths router configuration parameter), it would ignore those with the lowest MTU metric.
After an email exchange with Carlos G Mendioroz, I retested the above behavior with Cisco IOSv release 15.6(1)T in 2023. EIGRP MTU-related behavior changed since I last looked (in 2010): it no longer considers MTU when selecting a subset of equal-cost paths; the most stable (oldest) paths stay in the IP routing table regardless of their MTU value in the EIGRP topology table.
From the information propagation perspective, the MTU metric behaves similarly to the load and reliability metrics:
- A change in the MTU does not trigger a routing update.
- Whenever a “real” change in topology triggers an EIGRP update, the MTU metric is updated to reflect the then-current interface ip mtu value.
When processing inbound EIGRP updates, the minimum of the MTU value in the inbound UPDATE packet and the interface MTU is stored in the EIGRP topology database. No MTU processing is done on the outbound updates. The MTU metric thus represents the minimum unidirectional MTU between the current router and the originating router.
Revision History
- 2023-10-04
- EIGRP no longer considers MTU when selecting best paths
I hope this message reaches you. I have tried to verify the assumption about MTU being a tie-breaker in path selection on a lab gear but to my dismay, manipulating the MTU had no effect whatsoever on EIGRP's path selection - whether it were equal-cost best paths or equal-cost feasible successor paths, both with and without the "maximum-metric" command.
After talking to a gentleman from Cisco closely involved with EIGRP, he confirmed that the idea of using MTU was considered but never really implemented.
So I wonder... is there any document that would say otherwise? Alternatively, do you have a suggested test config that worked for you?
The issue of MTU in EIGRP is admittedly a neverending story... :-D
Best regards,
Peter Palúch
CCIE #23527 R&S, CCIP, Cisco CSC Designated VIP 2011-2012
Thank you very much for responding.
I made sure from the beginning that all you suggested was the case - more routes than allowed by "maximum-paths", MTU being correctly reflected in EIGRP topology database and properly shown even in the "show ip route X.X.X.X" output afterwards. However, the results stand - the MTU does not appear to have any effect. The timing may have contributed to the confusion here - sometimes the routing table displayed the routes with the highest available MTUs, but disabling an interface on a path with a high MTU and reenabling it later did not cause the EIGRP to reinstate the route with the highest available MTU - the existing routes simply stayed in the routing table and were not preempted by higher-MTU paths.
Any ideas?
Best regards,
Peter
I apologize for being tiresome here but I would be very, very thankful if you tried to reproduce your experiments - if you have some time to spare, of course. Cisco employees I talked to were absolutely adamant that there is no regard in EIGRP to the MTU in the best path selection process. I also could not see any effect of MTU on the path selection as I conducted my experiments, in alignment with your recommendations.
Thank you very much!
Best regards,
Peter
Thank you very much!
1. There is no MTU tie-breaker in best path selection algorithm. When several routes with same CD but different MTU exist in the topology table, only route age in the topology table serves as a tie-breaker: first come - first served. The order of receiving update matters only.
1a. When a router receive a route with the same CD as the current successor, it just installs them in the RIB. If it cannot install the route in RIB because of maximum-paths limit, it just ignores the route disregarding its MTU. So the routes are installed simply in the order or receiving updates, even if the first updates had lower MTU.
1b. Even if we reduce maximum-paths on the fly, the router prefers those routes that were received first, disregarding MTU.
2. In some situations there is a correlation between MTU and received updates order, so better-MTU updates come first.
2a. The effect is very weak. It's stronger on old IOSes; on newer hardware or virtual platforms I wasn't able to reproduce it.
2b. It obviously depends on a topology.
2c. I still cannot understand what causes this effect.