MTU in EIGRP metric?

[Peter Paluch]

Hello everyone,

Many pages describing EIGRP say that one of used metrics is the interface MTU. However, the formula for calculating the composite metric does not take MTU into account so the MTU can not affect the composite metric of a route.

I would like to ask how exactly is the MTU used in the EIGRP, then. Thank your for any insights!

With best regards,

Peter

[Richard Burts]

Peter

You ask a very good question and I believe that you are on the right track in trying to understand it. Your observation is correct that MTU is a required parameter in specifying EIGRP metric (for redistribution) and is one of the parameters that is advertised. You are also correct in observing that there is nothing in the EIGRP calculation that uses MTU. So the real answer is that the EIGRP specification included MTU but that it does not play any active role in the path selection done by EIGRP.

HTH

Rick

[Peter Paluch]

Rick,

It's kind of funny when the answer can be so straightforward :)

Anyway, thank you very much for your immediate and elaborate answer. I enjoyed reading it very much!

With best regards,

Peter

[burak-isiksoy · Accepted solution]

Hi Peter,

Actually it is used but not directly effective.MTU is advertised with the routing updates and it is stored in topology database, and if your router has equal paths to same destination and has to choose one of them MTU comes in to play

link with the low MTU ignored.

BR

Burak

[Peter Paluch · Accepted solution]

Hello Burak,

Thank you very much for answering my query!

I have asked this question about the MTU in the EIGRP quite a long time ago (it was back in 2006). Since then, I've come to know exactly what you have suggested - that if the metrics of two competing routes are the same, the EIGRP will choose the path with the larger MTU. Thank you so much for completing this thread!

EDIT (August 4th 2025): Despite all the information circulating on the internet and possibly even in various training materials and courses about EIGRP using MTU in this or that way in the best path selection algorithm, none of it is true. I myself was mistaken. My knowledge about EIGRP before October 2016 was based on my own experiments and studying the available public information about EIGRP but I had no access to Cisco internal knowledge base as an authoritative source of information. Being a Cisco employee since October 2016, I can now say safely and with authority that MTU plays no role whatsoever in EIGRP's metric computation or best path selection - none at all.

Best regards,
Peter

[Sam-CCNP]

Hi,

I have another question about this.

Is the MTU included in the update the lowest value in the path to the destination network (like BW)? 

The same goes for load and reliability, are the highest/lowest values along the path to the destination network included in the update?

I know neither are used in the default metric calculation as their k values are set zero but i just want to fully understand how it all works. 

Thanks.

Sam

[M02@rt37]

Hello @Peter Paluch 

MTU is not use in the EIGRP composite metric calculation, but it is include in EIGRP updates and use for route selection only as a tiebreaker when multiple routes have equal metric.

And if MTU are equal ? The route with the lowest IP will be the one installed in the routing table..

https://community.cisco.com/t5/switching/eigrp-best-path-selection-with-identical-metric/td-p/2286400

[Peter Paluch]

Hello M02@rt37 ,

In fact, the information about the MTU is wrong. MTU does not influence EIGRP's path selection in any way whatsoever.

My knowledge about many things related to EIGRP (and other Cisco's proprietary or internal mechanisms) before roughly 2017 was based on my experiments and research of the available information that was made public back then. However, I was not a Cisco employee until October 2016 and so before that date, I did not have access to authoritative sources of information about the internal specifics. Despite my utmost intent to get things right, I got some things wrong.

The issue of MTU as a possible tiebreaker in the EIGRP path selection algorithm is one of those unintended mistakes. Some of the experiments I have made back then must have been flawed and I interpreted them as MTU being used if the metrics were otherwise equal.

I was wrong. With the access into the internal documentation and source code I now have, I can state with absolute certainty that MTU is not and was not a part of EIGRP's best path selection algorithm in any way or form. There were considerations to make use of it but they were never implemented.

Remember that the EIGRP metrics were retaken from IGRP to allow EIGRP become a drop-in replacement for IGRP. MTU wasn't used even in IGRP, it was just advertised, just like the hop count - you can consider those two to be more of troubleshooting auxiliary information passed along the updates and not really components of the metric.

So the question about what happens if the MTU is or isn't equal is not really relevant - MTU plays no role in path selection.

With respect to the neighbor with the lowest IP address becoming the preferred neighbor - let's clarify this. This rule would only become effective if you had more ECMP paths than you allow installing into the routing table with maximum-paths command (set to 4 by default). EIGRP will internally sort the successors by their IP addresses in the ascending order, and pass them in this order to the routing table. But if you have ECMP paths that don't exceed the maximum-paths amount, they all will get into the routing table, not just the single one with the lowest next hop IP.

The thread you have linked here where Don Slice ( @dslice ) explains the changes to the source code for the DMVPN use cases is very relevant.

I hope this clarifies it a bit.

Best regards,
Peter

[M02@rt37]

Hello @Peter Paluch 

This clarifies a lot !

Thanks!

[Sam-CCNP]

Hello @Peter Paluch,

Thanks for explaining the MTU.

Are the Reliability and Load values the taken from the interface(s) connecting to upstream neighbor(s) that advertise the route, or are they the lowest/highest values along the path? Unlike MTU they can affect best path calculation (assuming corresponding values are not set to 0) so I'm try to figure out how it all works.

Thanks very much.

Sam

[Peter Paluch]

Hello @Sam-CCNP ,

With Reliability and Load, you perform similar operations to the Bandwidth - you take the path minimum for Reliability and the path maximum for Load:

• You compare the Reliability value in the received route to the Reliability on the receiving inteface, and take the lower one
• You compare the Load value in the received route to the Load on the receiving interface, and take the higher one

Compared to Bandwidth and Delay, though, a change to an interface's Reliability or Load does not automatically trigger an update in EIGRP. A route's Reliability and Load values are merely a snapshot of the path's minimum reliability and maximum load at the moment the route was advertised for some other reason.

I believe that when EIGRP's MANET extensions came about, we implemented the dampening-change and dampening-interval commands for EIGRP to allow triggering updates based on overall percentage change of the interface's metric. In that case, even a change to the Reliability and Load should trigger an update process.

This being said, dynamically reacting to the current path reliability or load is a finnicky thing. It can easily end up in route oscillations in the network whereby a highly loaded path stops being the best one and the traffic moved away to some other path, only to discover that once the load has subsided, the original path becomes the best one again and the traffic returning there... and the process going on and on. This is not specific to EIGRP - it's a fundamental collateral of taking the path load into its overall metric.

I have to say that I never, ever, saw EIGRP in production configured to take reliability and/or load into account.

And because of the awkward behavior even with the default metric behavior composed of only Bandwidth and Delay, if it was only my choice, I would suggest everyone just "downgrading" to the Delay component alone, hence K3=1 and all other K-values set to 0. This would make EIGRP's path computation much more understandable and intuitive, and every interface's delay command could be tuned arbitarily to select the preferred interfaces - just like we do in IS-IS.

It's not Cisco's official recommendation... but it certainly is mine : )

Best regards,
Peter

[Joseph W. Doherty]

@Peter Paluch, as usual, one of your excellent and informative replies.  I was thinking to make a somewhat similar reply to @Sam-CCNP's, last night, but I was tired and thought to do it this morning (when I saw yours).

Anyway, the three points I was going to emphasis were:  1) one consideration is the possible impact of the routing protocol dealing with constant updates, especially as interface load varies.  Basically a similar issue to dealing with a flapping interface.  (As you note using dampening can mitigate this, but getting that "right" has its own issues - i.e. being reactive without being too reactive.)

2) the problem of flows constantly "sloshing" between better paths which change due to their redirection to a better path.  This too you mention.

3) addressing these issues, especially on the hardware, of the era that existed during the creation of IGMP/EIGMP, wasn't, I believe, practical.  Further, to address such issues would be much more demanding on the hardware and require much more process logic than defined for EIGRP.   However, Cisco did come out with a later technology that did an, IMO, nice job of using multiple paths "ideally".  That technology was initially released as OER (optimized edge routing) and its V2 was renamed PfR (performance routing) (IWAN, and I suspect SD-WAN, has this technology).

I've setup and used OER/PfR, and my reaction to the technology was "WOW".  Laugh, the one unexpected "problem" was our network monitoring group no longer saw WAN issues.  The latter was mitigated by excluding much network monitoring traffic from OER/PfR and/or monitoring what OER/PfR was doing.

Anyway I mention OER/PfR as possibly the design of EIGMP had envisioned the potential benefits of smarter path selection and usage.  Studying the additional k variables of EIGMP is possibly somewhat like studying classful routing.

[Sam-CCNP]

Hi @Peter Paluch ,

Thank you for the explanation, makes sense and helps me to further my understanding.

Does that mean even with K values set to default, a change in Load or Reliability can still trigger updates? Or are the triggered updates restricted to when the metric actually changes, which in a default setup only occurs if Delay or BWmin change?

Yes, I know what you mean re the k values. I am learning this for CCIE purposes and have on occasion set k = 3 and the rest to 0 to simplify traffic engineering related experimentation during labs.

Thanks very much.

Sam