Recently, I was asked a question regarding traffic load balancing across several links and I was able to provide two options that I thought would work. I have decided to create articles on those solutions. In this 1st article, we will consider the first solution: using EIGRP.

A little background will be helpful at this point. Imagine two offices in different locations connected via two links. One of the links has a better connection speed than the other. This is common in organisations as a form of redundancy or high availability. In this scenario, let’s assume the organisation also wants to actively use its backup link instead of only in the event of the primary link’s failure.

The network diagram of this scenario is as shown below:

053014_1250_TrafficLoad1.png

We will be using GNS3 to simulate the network. The aim is to make sure that both links on the branch router are used as long as they are up and, in the event that one of the links fail, traffic should pass through the one that is still up. My GNS3 topology is shown below:

Notice that I have used Ethernet interfaces between the BRANCH_RTR and HQ_RTR1 so that I can have 10Mbps on that link. Also, I have used serial links between the branch router and the 2nd HQ router so that I can have 1.544Mbps. However, I didn’t have to do this; I could have manually set the bandwidth on the interfaces using the bandwidth interface configuration command.

The only configurations I have on the routers are IP address settings on the interfaces. To simulate the LAN on both the branch router and the HQ LAN router, I have used loopback addresses. No routing protocols or static routes have been configured.

To test that we have connectivity on direct links, I’ll ping from the branch router.

The next thing we will do is enable EIGRP on all the routers. We will use an AS number of 10. The configurations for the routers are listed below:

BRANCH_RTR

router eigrp 10
 network 41.1.1.0 0.0.0.3
 network 41.2.2.0 0.0.0.3
 network 192.168.10.0
 no auto-summary

HQ_RTR1

router eigrp 10
 network 41.1.1.0 0.0.0.3
 network 192.168.123.0
 no auto-summary

HQ_RTR2

router eigrp 10
 network 41.2.2.0 0.0.0.3
 network 192.168.123.0
 no auto-summary

HQ_LAN_RTR

router eigrp 10
 network 192.168.20.0
 network 192.168.123.0
 no auto-summary

Since we are mostly concerned about how the branch router accesses the HQ LAN, we can view the routing table of BRANCH_RTR.

As you can see from the above screenshot, only the faster link (the 10Mbps link between BRANCH_RTR and HQ_RTR1) is being used. This is because one of the metrics EIGRP uses to calculate its metric is bandwidth. Actually, only bandwidth and delay affect the EIGRP calculation by default. We can view the EIGRP topology table to give us more insight into the metrics advertised from both HQ routers.

Notice from above that although BRANCH_RTR sees the HQ LAN through both HQ_RTR1 and HQ_RTR2, only HQ_RTR1 (41.1.1.1) is installed in the routing table. Like we said, this is because HQ_RTR1 has a better Feasible Distance (FD = 412160) than HQ_RTR2 even though they have the same Advertised Distance (AD = 156160).

The reason for this better metric can be seen by looking at the interfaces on the branch router.

Notice that the Ethernet interface has better bandwidth and delay values than the serial link. So how do we go about load balancing these links? We will now consider one of them: tweaking the bandwidth and delay values of the serial link.

Note: Remember that EIGRP uses the minimum bandwidth along the path and the sum of delays in the path.

I will add the following commands on the serial interfaces of both the BRANCH_RTR and HQ_RTR2.

bandwidth 10000
delay 100

The bandwidth is specified in Kbits/sec while the delay is specified in “tens of microseconds,” i.e. if we want to specify 1000 usec, we will use the command delay 100.

Now that I have made this change, let us view the routing table again on the branch router.

We will notice now that it is load balancing (equally) on both links. However, the change that we have made is not recommended because we altered the bandwidth settings. EIGRP is not the only feature that is affected by that bandwidth command; QoS may also be affected. The recommended method to influence EIGRP metrics is by tweaking the delay value along the path. You can read more on this here.

We will now consider the second option I mentioned. To do this, I will restore those interface bandwidth and delay settings that I changed using the no form of those commands. We are now back to what we had before.

The second solution is to use the variance command under the EIGRP process. By default, EIGRP will load balance on equal cost paths but we can change this using the variance command.

According to Cisco, the variance n command instructs “the router to include routes with a metric of less than n times the minimum metric route for that destination.” For example, if the best (minimum) metric is 20 and you use the variance 2 command, then the router will include routes with metrics < 20*2, i.e. metrics less than 40.

Let’s take a look at the EIGRP topology table again for the HQ LAN network:

We can see that the cost of the 192.168.20.0/24 network through HQ_RTR2 is almost 6 times worse than the cost through HQ_RTR1, i.e. 2300416/412160 = 5.58. Therefore, according to the definition above, if we use the variance 6 command, then EIGRP with load balance across both links. Let’s give it a try.

The branch router now uses the second link with unequal cost load balancing. We can see the traffic share count using the show ip route command.

However, if we were to check the HQ LAN router, we will notice that nothing has changed. This is because the variance command is local to the router on which it is applied.

Let’s view the EIGRP topology table on this HQ LAN router.

From the above screenshot, we notice that HQ_RTR2 is not even listed as a feasible successor. Why?

As we can see from above, EIGRP has determined on HQ_RTR2 that it is even better to go through the longer path (HQ_RTR2 à HQ_RTR1 à BRANCH_RTR) than to use the serial link. We can tweak delay values on the interfaces and use distribute lists or offset lists to make it work on the LAN side but that is not the focus of this article.

Summary

This article assumes that the reader is familiar with how EIGRP works. Building on that knowledge, we have seen how to use EIGRP to achieve unequal cost path load balancing through the variance command.

In the next article, we will consider another solution to the traffic load balancing scenario which deals with policy-based routing and IP SLA tracking. I hope you have found this article insightful and I look forward to the next article in this mini-series.

Further reading