All of our Interior Gateway Protocols can perform equal-path load balancing on up to 4 routes by default. We can verify this by looking at the output of show ip protocols, it will tell us what the maximum path value is. Set it to 4 by default. We can change that value. If I want to load balance on more than 4 equal-cost paths, I can do that. Go into router configuration mode – in this case, for EIGRP autonomous system 100 – change the maximum paths to 8. You can see here, I could go all the way up to 32 equal-cost paths for load balancing.
Branch#show ip protocols | include MaximumMaximum path: 4
Branch(config)#router eigrp 100Branch(config-router)#maximum-paths ?<1-32> Number of pathsBranch(config-router)#maximum-paths 8
But alright, that is fine. All of our Dynamic Routing Protocols can do this. What separates EIGRP apart from the rest? Its ability to do unequal-path load balancing. It is not on by default, it's off. And how do we know it's off? We look at the output of show ip protocols, there is a value there; a value associated with a specific word and that word is variance. What does variance mean?
Branch#sh ip protocols | include varianceMaximum metric variance 1
Okay, it's in fact a pretty tricky value to understand, but I want you to think about ratios like a 1:1 ratio or 2:1 ratio or a 3:1 ratio. That in fact is a slider for the willingness to load balance across really inferior routes. How unequal are we willing to go? If it is 1, that in fact says the ratio between the best route and the next best route has to be a 1:1 relationship, which means, it has to be in fact equal. That is the default state. So, if I see a variance of 1, that means equal-path load balancing. Exactly. Anything higher than 1 would indicate that we are doing unequal-path load balancing. So if you saw a 2 or a 3 or a 4, and usually you stick to 2 in fact. Here is why. Because you will only load balance unequally when you have feasible successors. And the math works out that your feasible successors are still probably not going to be like 50 times worse than your successor. Because of the way that the DUAL algorithm would probably exclude that from being a feasible successor. So if we saw a variance of 2, that would mean we will go two times source. In terms of the metric, it could be double. If I see a variance of 3, it could be triple. The metric of the feasible successor could be triple and we would trickle down some traffic. And it is a trickle, it is not going to try to send the same amount, it is going to proportionally load balance. So this is a really intelligent mechanism.
Branch(config)#router eigrp 100Branch(config-router)#variance ?<1-128> Metric variance multiplierBranch(config-router)#variance 2
The problem is that it is good on paper, it is not good in production networks in a lot of cases. That is the reality, it really is. In a production network, you don't want to just go out and do this especially if you have sensitive traffic. If your traffic is sensitive to quality of service, then imagine sending some IP phone calls across your primary WAN and then, you got your other phone calls for IP telephony. Your CEO's phone call getting load balanced on the feasible successor and that feasible successor is already at capacity - could be pretty bad and it could be hard to enforce quality of service for that. So that is reality. We don't necessarily want to do this, but nevertheless, it's a feature that we should always understand about EIGRP. And this is pretty unique. Other routing protocols don't have this.
So folks, this is an example. Let us look at the exhibit we have.
It says unequal-cost load balancing. So, which of those two paths, I see a metric of 25 and a metric of 100, which of those two paths would be our successor?
Bottom path, metric at 25, of course. So with a variance of 1, will I perform unequal-path load balancing? Absolutely not. Because we are expecting a 1:1 relationship between our metrics and looks like we have a 4:1 relationship right now. So if we set a variance to 2, then what that tells our router to do is, just simply multiply that metric that we have for the successor route, which is 25 multiplied by the variance, which will be 2; so 25 times 2 is 50. And then, compare the other paths to this new value. If you are less than that value, then you are used for an unequal-path load balancing. So with a variance of 2, I get 50, is 100 less than 50? No, no so again, still not doing unequal-path load balancing. So as we said, we have a difference here of 4. It is 25 times 4, gives us 100. So that is all we are doing with that variance. We are multiplying it by that best metric and then comparing.
Now the whole story is would you want to set the variance to 4? Not if you read white papers. You do want to go 1 more than that. You do want to set the variance to 5 because a white paper will tell you if the numbers work out to being equal, like 4 times the 25 is a 100, right? So then, our successor and our feasible successor stack up the same after the variance is calculated. They tell you that equal is not sufficient. So you need to exceed that number with your variance to be inclusive. The reality is that it will work even if they are equal. Like 4 times the metric of 25 would satisfy in a production network, you are probably never going to see that. But it's pretty cool to learn about some of those real intricacies now, of routing operation.