Unequal Load balancing technique - EIGRP

[chiragom2341]

Hi,

as we know, EIGRP provides unequal as well as by default up to 4 equal load balancing facilities. In equal load balancing, there is possibility to go up to 6 links so what are the limit then in unequal load balancing ? how many links we use in unequal load balancing OR how many links EIGRP can support in unequal load balancing ?

Answer will helpful to understand better, Many Thanks in advance!

[Peter Paluch · Accepted solution]

Hello,

As far as I know, the limits for numbers of equal and unequal cost paths are the same and can not even be tuned individually. By default, the limit is set to 4. Older IOSes allowed this limit to go up to only 6, more recent IOSes allow this number to be 16 or even 32 - depending on the IOS version and the actual router or multilayer switch platform. The command to modify this limit is the well-known maximum-paths command.

EIGRP itself has no limit on the number of equal or unequal cost paths. The limit we are talking about is the limit of the routing table manager that will accept only a limited number of paths toward a single destination.

Please feel welcome to ask further!

Best regards,
Peter

[chiragom2341]

Peter, thank you so much for explaining.

I understand everything except - "can not even be tuned individually."

you mean, adjust the default limit of load balancing.. ??

[Peter Paluch · Accepted solution]

Hi,

You are welcome.

I understand everything except - "can not even be tuned individually."

What I meant to say is that there are no separate commands to independently configure the limits for equal-cost and unequal-cost path counts, respectively. Whenever you use the maximum-paths command, you are limiting the total number of paths, equal plus unequal, toward a destination.

Best regards,
Peter

[chiragom2341]

yes, understand all :-)

Thank you.

[Peter Paluch]

Hello,

You are welcome - and I thank you as well!

Best regards,
Peter

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

As a side note, in the past, one of our (founding) Hall of Fame members, Paolo Bevilacqua, was very much against using EIGRP unequal cost routing. If I remember correctly, I believe he said it didn't perform very well.  Whether that's still true, I don't know, but I did want to make you aware of it as a possibility.

[Peter Paluch]

Hi Joe,

It would be nice to know exactly what Paolo had in mind. I wonder what he's doing now. Despite his sometimes very ... direct and possessive way of communication, I kind of miss him :)

Fair enough, though, there are several issues with this feature.

First of all, it is usable much less often than one would guess. For an unequal cost path to be usable, it must go through a Feasible Successor, and Feasible Successors are chosen in turn by the Feasibility Condition that says RD<FD (Reported Distance must be smaller than our own Feasible Distance for a specific destination). Tuning the metrics so that this relation is met can get much more difficult than expected.

Furthermore, the FD itself is a value that is variable in time. The FD is defined as the smallest total distance encountered to the destination since the last time of Active-to-Passive transition. It is not the current smallest distance - it can be smaller. In other words, the FD is temporally dependent and depending on how the network has "evolved" over time, FD might be different and cannot be easily expected to have a certain specific value. It is thus possible that the set of unequal paths differs from one time to another, depending on what value the FD holds.

Yet another problem is that the upper metric bound for acceptable worse-metric paths is computed as V x current_best_metric where V is the value configured in the variance command. Cisco code does not check whether the result of this multiplication fits into unsigned 32-bit variable, and as a result, if both the variance and the current best metric to a destination are sufficiently large numbers, the result may overflow. The resulting overflown value may be even lower than the current best metric, in which case no unequal-cost paths will be installed at all, or it will be larger than the current best metric but obviously not at its correct value, and so only a subset of all intended unequal-cost paths will be considered.

These all issues relate to the control plane. Paolo may have in addition related to some problems with the load distribution between unequal-cost paths. I am not aware whether there were any issues - I would be interested to know.

To sum it up, the unequal-cost load balancing in EIGRP is being often marketed as a unique feature, but in reality, it is only a by-product of how the Feasibility Condition in EIGRP works, and it is kind of difficult to raise a byproduct to a fully-fledged feature in its own right.

Best regards,
Peter

[Joseph W. Doherty]

". . . his sometimes very ... direct and possessive way of communication . . .", ah yes, his replies often were, laugh, but of course, he helped others, and provided good information too.

The posts I have in mind, were quite some time ago, although they might still be on these forums (I recently noticed the LAN and WAN forums only go back about 10 years).

I don't recall if he actually stated it, but I have the impression he may said unequal cost EIGRP would be process switched.

Oh, and to the OP, if the equipment supports PFR with its PIRO feature, you should be to do unequal cost dynamic load balancing using any routing protocol.

[Peter Paluch]

Hi Joe,

". . . his sometimes very ... direct and possessive way of communication . . .", ah yes, his replies often were, laugh, but of course, he helped others, and provided good information too.

I certainly did not mean to disparage him in any way. I hold Paolo in the greatest esteem - his knowledge has exceeded mine by orders of magnitude, and his contributions were absolutely essential in building the CSC - formerly the NetPro - as we know it today.

I don't recall if he actually stated it, but I have the impression he may said unequal cost EIGRP would be process switched.

This could have been true in very old IOSes that did not yet run CEF. In every decently recent IOS, however, CEF is implemented including the possibility of doing unequal-cost load balancing. The following figure is retaken from the great document How to Choose the Best Router Switching Path for Your Network:

The hash table shown here is equipped with 16 entries, or buckets, that can point to different next-hop entries in the adjacency table. Traffic is then shared between multiple next hops depending on how many entries point to the same entry in the adjacency table. The count ratios of hash table entries pointing to individual adjacency table entries correspond to the ratios of the traffic distribution among the next hops.

There is also a great document called Troubleshooting Load Balancing Over Parallel Links Using Cisco Express Forwarding that provides further insight into how the population and usage of these bucket works.

Best regards,
Peter

[Joseph W. Doherty]

"This could have been true in very old IOSes that did not yet run CEF."

I think I argued a similar point at the time, i.e. his concern might have been dated, but he was adamant that was not the case.  I recall, he wrote, when he was at Cisco, he worked with/in the group that provided EIGRP.

Again, though, those posts were years ago, I believe, so newer IOSs since then certainly could have improved how EIGRP forwards unequal cost.  (Of course, my memory is hazy and it might not have been a forwarding performance issue, but issues similar to what you relate.)

In any case, to the OP, good chance EIGRP unequal cost will perform just fine, but perhaps something just to be prepared for just in case if doesn't perform well, i.e. you might want to have a "Plan B".