Introduction to EIGRP load balancing
We want to use the uplinks as much as possible when dealing with routing protocols, and most of the time in a balanced way. Sometimes not.
You don’t want one of your 1Gbps uplink to be used at 90% while the other 1Gbps uplink to be used at 0%? Or do you? Sometimes yes.
There is no correct answer, every case is different. Some companies will have the second 1Gps for backup with no usage. Classic example is MPLS + DMVPN backup links.
The only IGP protocol that supports unequal load balancing(UCLB) is our friend EIGRP, others IGP as IS-IS, OSPF or RIP do not support this feature.
BGP supports unequal load balancing also, but it’s not an IGP and also is not the topic of discussion here.
The default paths allowed for ECMP or UCMP varies per version, but there is a command to extend the default limit which is the maximum-paths command.
ECLB(equal ) vs UCLB(unequal)
Coming back to the same topology as Part 1:
Every successor is doing equal cost load balancing by default, sending traffic to each path equally.
Remember that a successor is a neighbor through we will send traffic to the destination in a loop-free fashion.
We can focus again in the route 188.8.131.52 which has 3 equal paths through R1, R2 and R3 to the destination R8. From R7 point of view, we have 3 successors, and 0 feasible successors.
Take a look how we send traffic to all of them when sending packets to R8:
Perfectly balanced, as things should be.
With the command show ip route you can see it also in the RIB(routing information base or routing table) which holds L3 information about how to route to destinations:
Unequal load balancing (UCLB)
Now for unequal load balancing: If we have several paths, but only 1 successor and we want all the links that already comply with the feasibility condition to forward traffic(to actually be promoted to successor) without touching the metrics we can use the variance command.
Remember: Variance cannot make a neighbor to comply with the feasibility condition, actually for variance to work the first thing you need to have is the feasibility condition matched.
If you feel that you need to refresh some concepts, visit Part 1 of the EIGRP series.
From R7 again, our route 184.108.40.206 for which I modified the metrics to have 1 successor (via eth 0/2), 1 feasible successor (via eth0/3) and 1 neighbor that do NOT comply with the feasibility condition (via eth0/1).
Notice how the historic FD 384512 is different from the current best CD 397056 that goes via eth0/2, remember that FD is a historic record of the best metric for that link.
Right now we have only 1 active path(1 successor via eth0/2) but we want another link to forward traffic so we can make the feasible successor(via eth0/3) to be promoted to successor using the variance command and achieving unequal load-balancing.
But what’s variance? Variance is just a multiplier to the FD, so variance 3 will raise the FD three times to take into account the feasible successors.
Variance is the Feasible distance (FD) for a route multiplied by the EIGRP variance multiplier.
Any feasible successor’s CD with a metric lower than the EIGRP variance value is installed into the RIB. We cannot make a path a feasible successor with variance.
Easiest way to calculate it, take the biggest CD of any feasible successor and divide it by the FD currently active; 1664256/384512 = 4.32 so we need at least variance 5!
Let’s check after applying variance 5 to the eigrp process in R7:
It worked, we have 2 successors now! Notice how variance command is not changing the actual metric that is showing here. It just for internal calculation only.
Notice the share count, this is the proportion of packets per path. 80/19 = 4.20 which is almost the same result we got when dividing their metrics before, if you remember it was 4.32
So R7 will send 4 packets via eth0/2, and 1 via eth0/3 in proportion!!
For Layer 2 forwarding: If we want to see the actual CEF forwarding, we can use show ip cef 220.127.116.11 internal:
CEF have 16 blocks to assign any time to send packets, see the proportion:
We have 16 blocks, 3 are assigned to eth0/3 and 13 to eth0/2, which give us 13/3=4.33 proportion. Pretty close!!
Variance and unequal load balancing is generally a source of confusion, hopefully this post will help you to clarify.
Remember that variance command cannot force a neighbor to become feasible successor, this is the most important part.
What are your thoughts?
We are sorry that this post was not useful for you!
Let us improve this post!
Tell us how we can improve this post?