Wow, it’s been a while, blogging universe, but I am back with a topic that has eluded me for a long time, and it seems like I was overthinking it as usual.
EIGRP is the only protocol that can do unequal cost load balancing; you can have two paths with two different costs, and EIGRP will use them in proportion to the
cost of the links. I am sure you are thinking, Mike, you need to sleep; you have been up labbing way too late, and the red bulls have finally gotten to you, but hear me out for a second. Let’s look at the following topology:
R4 has a loopback interface that has the IP address of 4.4.4.4/32 assigned to it. When R1 does a route lookup for that destination, we see two paths we can take to get to the destination.
R1#sh ip route 4.4.4.4
Routing entry for 4.4.4.4/32
Known via "eigrp 100", distance 90, metric 2809856, type internal
Redistributing via eigrp 100
Last update from 10.1.13.3 on Serial0/0.13, 01:25:24 ago
Routing Descriptor Blocks:
10.1.13.3, from 10.1.13.3, 01:25:24 ago, via Serial0/1
Route metric is 2809856, traffic share count is 1
Total delay is 45000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
* 10.1.12.2, from 10.1.12.2, 01:25:24 ago, via Serial0/0
Route metric is 2809856, traffic share count is 1
Total delay is 45000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2Currently, R1 is doing equal-cost load-balancing (in a 1:1 ratio) to 4.4.4.4. But what if we wanted to get crazy… What if your boss came up to you and said, hey, let\\\’s shake things up. I want you to do load balancing in a 1:7 ratio. After you look at him like he had a few too many the night before, you get hard to work, but you don’t know where to start. Let’s look at the formula we should use to solve this request.
The first thing you should do is look to see what the composite metric is. This is the metric that is reported to the RIB for that route. In this case, our composite metric is 2,809,856. This can be seen by putting in the following command:
R1#sh ip route 4.4.4.4 | inc 10.1.1.|Route metric
10.1.13.3, from 10.1.13.3, 01:29:14 ago, via Serial0/1
Route metric is 2809856, traffic share count is 1
* 10.1.12.2, from 10.1.12.2, 01:29:14 ago, via Serial0/0
Route metric is 2809856, traffic share count is 1OK, now we have to figure out what 7x our composite metric is; for this, we multiply 2,809,856 by 7. This gives us 19,668,992.
So, how do we accomplish this? We need to reverse engineer the EIGRP metric calculation to get our answer. So 19,668,992 = 256 (B/W + DLY + x_variable), with the X variable being what we are looking for.
Let’s break down our equation. What is the bandwidth of the link? As we all know, EIGRP uses the constraining bandwidth on the link in the metric calculation. The constraining bandwidth is a fancy way of saying the lowest bandwidth on a link in the transit path. Since we are using all serial interfaces, we are dealing with 1.544mbps or 1544kbps. To get our bandwidth part of the equation, we must divide the seed bandwidth by 1544kbps. In EIGRP, the seed bandwidth is 10gbps. So, if we take 10,000,000/1544 = 6476.683937823834, we drop everything after the decimal, and our bandwidth calculation is 6476. Now we have 19,668,992 = 256 (6476 +DLY + x_variable)
Now, onto the delay. Delay is the sum of all delays across the path. We can find this out by looking at the EIGRP topology table:
R1#sh ip eigrp top 4.4.4.4 255.255.255.255 | inc Total delay|10.1.1.
10.1.12.2 (Serial0/0), from 10.1.12.2, Send flag is 0x0
Total delay is 45000 microseconds
10.1.13.3 (Serial0/1), from 10.1.13.3, Send flag is 0x0
Total delay is 45000 microsecondsSo, R3 has a total delay of 45000 microseconds, which we take and divide by 10, which gives us 4500µs, which we plug into our equation
19,668,992 = 256 (6476 + 4500 + x_variable)
OK, now we are getting somewhere. Let us figure out what we get with the numbers that are already in the equation
6,476+4,500 = 10,976
So, our equation looks like
19,668.992 = 256(10,976 + x_variable)
Now, let’s divide our new 7x composite metric by 256
19,668,992/256 = 76,832
So we are left with
76,832 = 10,976 + x_variable
Now let’s carry 10,976 over to the other side, and we will need to subtract 76,832 by 10,976
76,832 – 10,976 = x_variable
This gives us X_variable is 65,856
Let’s raise the delay on s0/1 by 65,856 and raise the variance by 8
R1(config)#int s0/1
R1(config-subif)#delay 65856
R1(config-subif)#router eigrp 100
R1(config-router)#variance 8The key with the variance command is it multiplies the composite metric by whatever value you put into the command, so in this case, it will take 2809856 and multiply it by 8, which gives us 22478848. The router compares it to the feasible distance, and if the FD*variance is greater than the Feasible Successor, we can have unequal cost load-balancing.
Under show ip route 4.4.4.4, we see two unequal cost paths.
Routing entry for 4.4.4.4/32
Known via "eigrp 100", distance 90, metric 2809856, type internal
Redistributing via eigrp 100
Last update from 10.1.13.3 on Serial0/0.13, 00:00:17 ago
Routing Descriptor Blocks:
10.1.13.3, from 10.1.13.3, 00:00:17 ago, via Serial0/1
Route metric is 19156992, traffic share count is 7
Total delay is 683560 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
* 10.1.12.2, from 10.1.12.2, 00:00:17 ago, via Serial0/0
Route metric is 2809856, traffic share count is 48
Total delay is 45000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2Now how to see you are doing a 1:7 ratio for load balancing is you take 48 and divide it by 7, which gives you roughly 7 (the exact number is 6.857142857142857)