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 actually is: 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 ignores those with the lowest MTU metric.

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.

7 comments:

  1. The best information about EIGRP MTU so far in the internet, and even on books, cause they always say that MTU is not used at all for calculation(and its not) and thats all, no one really explains the actual meaning of it. Finally someone really explained the meaning of the MTU value on EIGRP, thanks !

    ReplyDelete
  2. thanks for answering my question! :-)

    ReplyDelete
  3. Hello Ivan,

    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

    ReplyDelete
  4. I vaguely remember doing actual tests with 12.4 (or so) code. You have to make sure you have more than "maximum-metric" equal-cost paths and that the MTU in the EIGRP topology database is correct (it's not updated if you change MTU on the interface).

    ReplyDelete
  5. Hello Ivan,

    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

    ReplyDelete
  6. Ivan,

    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

    ReplyDelete
  7. Пиздохен Шванц!
    Thank you very much!

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.