EIGRP load and reliability metrics

Everyone studying the EIGRP details knows the “famous” composite metric formula, but the recommendation to keep the K values intact (or at least leaving K2 and K5 at zero) or the inability of EIGRP to adapt to changing load conditions is rarely understood.

IGRP, the EIGRP’s predecessor, had the same vector metric and very similar composite metric formula, but it was a true distance vector protocol (like RIP), advertising its routing information at regular intervals. The interface load and reliability was thus regularly propagated throughout the network and so it made sense to include them in the composite metric calculation (although this practice could lead to unstable or oscillating networks).

EIGRP routing updates are triggered only by a change in network topology (interface up/down event, IP addressing change or configured bandwidth/delay change) and not by change in interface load or reliability. The load/reliability numbers are thus a snapshot taken at the moment of the topology change and should be ignored.

Sending EIGRP updates whenever there’s a significant change in load or reliability would be technically feasible, but would diminish the benefits of replacing distance vector behavior with DUAL.

You might be wondering why Cisco decided to include the load and reliability into the EIGRP vector metric. The total compatibility of IGRP and EIGRP vector metrics allowed them to implement smooth IGRP-to-EIGRP migration strategy with automatic propagation of vector metrics in redistribution points, including the IGRP-EIGRP-IGRP redistribution scenario used in IGRP-to-EIGRP core-to-edge migrations.

8 comments:

  1. I have heard that the K in K-value stands for Knob, but can't find any documentation to back me up. Do you have any information on this topic?

    ReplyDelete
  2. Hi there,
    I was wondering about the MTU parameter... I thought it was part of the formula to calculate the composite metric, but it's not. So is it really used for something ??

    thanks for the blog!
    Mat

    ReplyDelete
  3. Ivan Pepelnjak24 May, 2010 18:34

    MTU is a tie-breaker. If you have more than "maximum-paths" equal-cost EIGRP paths, the ones with the highest MTU value are used. I've even labbed it once to test it, but obviously haven't documented the lab results.

    ReplyDelete
  4. Thanks for taking the time to answer me.

    Cheers
    Mat

    ReplyDelete
  5. Hi!
    I've been trying to find information about the load parameter. Is it the rx load or the tx load on the interface, or is it some combination of those two that would be the correct number in the formula?

    ReplyDelete
  6. Ivan Pepelnjak31 March, 2011 07:16

    It's whatever the interface show command would show. I guess it might be max(rx,tx), but that's just a guess - never used it with EIGRP, as it's totally useless.

    Here's what you can do: build a lab, start a unidirectional flood, trigger some EIGRP updates & examine EIGRP topology table to see what changes and where it changes.

    ReplyDelete
  7. You said:
    "Sending EIGRP updates whenever there’s a significant change in load or reliability would be technically feasible, but would diminish the benefits of replacing distance vector behavior with DUAL."

    Actually, EIGRP is in essence an enhanced distance vector routing protocol. The fact that it does not send updates at regular intervals does not transform its nature. This merely saves bandwidth and it sends updates when it is only appropriate, that is when changes (interface up/down event, IP addressing change or configured bandwidth/delay change) are detected.

    So I don't see any reason why "Sending EIGRP updates whenever there’s a significant change in load or reliability ... would diminish the benefits of replacing distance vector behavior with DUAL."

    Actually, I feel this would be a great enhancement to this routing protocol, since this simple ability to detect loaded or unreliable networks would be very valuable to medium-sized networks.
    It would be the responsability of the network engineer to correctly tweak the values to avoid too many route flaps.

    ReplyDelete
  8. Such a great blog, I finally understood (in 10 minutes) the importance of load into the composite metric of EIGRP, thanks!

    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.