You will often find yourself in a situation in which there exist two or more paths to the same destination. EIGRP will automatically balance traffic over the paths if the cost for each is the same. If the paths are not equal, EIGRP will allow you to proportionally divide the traffic over both links.This situation can occur when there are multiple WAN links between two routers, but it is more common to see this situation when there are paths through multiple neighbors to a destination.
In Figure 2.26, we want to create traffic distribution over the two WAN links to connect to the Internet.The command to generate load balancing is variance
<multiplier>, where the multiplier tells the EIGRP process how many times larger the feasible successor total metric (including local interface cost) can be over the feasible distance and still load balance.Table 2.8 shows the metrics of both routes.
Table 2.8Metrics of Both Routes Metric over the 56 K link
Metric= K1*107/56+K3*22000/10=178571+2200=180771*256=46277376
Metric over the 128 K link (FD)
Metric= K1*107/128+K3*22000/10=78125+2200=80425*256=20588800
If we divide 46277376 by 20588800, we discover that it is 2.25 times the value of the feasible distance.Therefore, we need to use a variance multiplier of 3.
Our configuration at Router R is:
router eigrp 100 network 172.6.0.0 variance 3
Figure 2.26Efficient Use of Existing Links with the Variance Command
56K
The default behavior of EIGRP is to distribute traffic over the paths that meet the variance requirement inversely proportional to their metric. In our cir-cumstance, approximately one-third of the traffic will traverse the slower link.
There is an important rule regarding unequal-cost load balancing:The higher-cost path or paths must be feasible successors of the lower-cost path. Due to the nature of selecting feasible successors, you may discover that your load bal-ancing is only working in one direction. In Figure 2.26, we have created load balancing from Router R through the two WAN links and to the Internet.We discover that the 128K link is becoming saturated during high periods of activity.
This is the opposite behavior of what we would have expected.
When we begin to examine the metrics for our routes, we discover that the connection from Router I to Router R has only one successor, through Router B.The path through Router A does not meet the feasibility condition and is not in the topology table. Looking at the metric calculations in Table 2.8, we can see the problem.
Table 2.8Metric Calculations for Routers A and B Metric Advertised by Router A
Metric= K1*107/56+K3*20000/10=178571+2000=180571*256=46226176
Feasible Distance through Router B
Metric= K1*107/128+K3*21000/10=78125+2100=80225*256=20537600 There are two ways to resolve this problem.The first solution is to increase the physical bandwidth on the 56K link to 128K.You cannot deny the fact that during peak periods there is enough traffic to saturate the slow WAN links.
However, if raising the bandwidth between the two sites were an option, we would have done that originally.The second solution is to tinker with the EIGRP metrics between Routers A and R until it becomes a feasible successor.
Do not be too quick to walk over to Router A and raise the bandwidth con-figuration until the route meets the feasibility condition. In doing so, you can adversely affect other routes, and the solution may not produce the expected results. As an example, if you raise the bandwidth metric at Router A to 128K to lower the metric below 20537600, you will end up with something close to equal-cost load balancing, and you will oversubscribe the 56K link. If you change the delay metric on Router B to increase the feasible distance, the result will be the same.
www.syngress.com
In many situations, we would simply be at a standstill and have to wait for the budget to increase to add physical bandwidth on the WAN links. In our simple network, though, we can perform one additional step to get the desired result.
We can achieve the desired result if we increase the delay over the link between Router B and Router R until the route through Router A becomes a feasible successor, and then increase the delay between Router A and Router I.
This is not a generally recommended approach unless you very carefully examine all of the routes that will be affected. Influencing these metrics can result in sub-optimal path selection and is only given here as an example. In our network, this is the only path that will be affected so we are safe in moving forward.
We need to perform some calculations to determine the exact values of delay over the links.The first goal is to achieve feasible successor status for the link between Router A and Router R.To do this, we must raise the feasible distance to a value greater than 46226176, which is a factor of 2.251.To arrive at the delay value, we need to work through our formula backwards:
20537600*2.251=256(78125+Delay/10) 46230138/256=78125+Delay/10
1024615=Delay
Inserting this into our formula in Table 2.9 as our total delay between Router I and Router R through Router B, we can see that the feasibility condition is met and we have not increased the metric so high that the route through Router A becomes the successor.
Table 2.9Total Delay between Router I and Router R Metric Advertised by Router A
Metric= K1*107/56+K3*20000/10=178571+2000=180571*256=46226176
Feasible Distance through Router B Metric=
K1*107/128+K3*1024615/10=78125+102462=180587*256=46230272 Now we must determine how high to raise the delay value on the link between Router A and Router I.To get the appropriate balance, the total metric through Router A should be twice the metric through Router B. Currently, the total metric is:
Metric= K1*107/56+K3*21000/10=178571+2100=180671*256=46251776
Again, we need to work backwards for our solution:
2*46251776=256(178571+Delay/10) 92503552 /256=178571+Delay/10 1827710=Delay
Inserting this into our formula in Table 2.10, we can see that we have achieved the desired result:
Table 2.10Continued Calculations of Metrics Feasible Successor through Router A
Metric=
K1*107/56+K3*1827710/10=178571+182771=361342*256=92503552
Feasible Distance through Router B Metric=
K1*107/128+K3*1024615/10=78125+102462=180587*256=46230272
The final configurations on our routers become:
Router R
router eigrp 101 network 172.16.0.0 variance 3
Router A
router eigrp 100 network 172.16.0.0
Router B
router eigrp 100 network 172.16.0.0 interface serial0
delay 1023615
Router I
router eigrp 100 network 172.16.0.0
www.syngress.com
variance 3
interface ethernet0 delay 1807710
If we look at the route tables for Router R and Router I, we can see that both routes are entered in the route table.
Router R#show ip route Codes:
C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i ISIS, L1 ISIS level1, L2 ISIS level2, *
-candidate default
U - per-user static route, o - ODR
Gateway of last resort is not set
D 172.16.32.0/24 [90/20588800] via 172.16.10.2, 00:00:39, Serial0
[90/46277376] via 172.16.11.1, 00:00:39, Serial1
………
Router I#show ip route Codes:
C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i ISIS, L1 ISIS level1, L2 ISIS level2, *
-candidate default
U - per-user static route, o - ODR
Gateway of last resort is not set
D 172.16.8.0/24 [90/92503552] via 172.16.16.2, 00:01:03, Ethernet0
[90/46230272] via 172.16.17.1, 00:01:03, Ethernet1
………