Is there a way to filter which traffic we would want to say go over the serial link vs the fast ethernet link when doing unequal load balancing?
Hello Paul
Load balancing will “blindly” balance traffic over the various alternative paths without regard to the type of traffic being sent. The algorithms used to decide which packets are sent via which route are described in detail in this Cisco documentation:
Note that per-destination and per-packet load balancing options can be employed.
Now if you want to route traffic based on additional parameters such as QoS markings or source IP address, then you can employ policy based routing (PBR). There, using route maps, you can change the next hop based on a variety of parameters including anything that can be matched using a route map. For more info on PBR, take a look at this lesson:
For details on the options available in route maps, take a look at this lesson:
Keep in mind that it is best practice not to employ both EIGRP unequal cost load balancing and PBR together, as unpredictable routing may result.
I hope this has been helpful!
Laz
Thank you for this great write up.
This gives me some ideas for a solution I’ve been pondering… so I have a follow up question based on my production environment.
We use EIGRP to route from our 12 service centers into our core router in our data center.
We have 2 separate mpls service provider links at each service center… the primary link at each service center is 50 Mbps, and the secondary is 20 Mbps…
Currently, we have offset lists at each service center that forces all traffic to traverse the primary link, and the secondary link is basically just passing keep alive traffic (and is there for failover purposes only).
If I wanted to use eigrp variance to utilize both links, instead of just one, what would be the best method to still ensure more traffic is proportionally traversing the 50 Mbps primary link compared to the 20 Mbps failover? My first thought is to hard set using the bandwidth command at the interface level to influence the eigrp metric, but wanted to ask and get feedback first to ensure this would produce the desired result.
Hello Robert
EIGRP variance is a good solution to what you are proposing, but you must keep the following in mind:
- The value you use for the variance is used to determine if the feasible successor will be installed in the routing table. The variance value does not affect the proportion of traffic that chooses which path…
- The metric of the installed routes in the routing table is used to determine the proportion of traffic that will take which path.
So if you want to change the proportion of traffic that takes a particular route, you should adjust parameters to change the metric of those routes, and one way to do it is using the bandwidth command as you suggested. But if you change the bandwidth, you also change the metric, so you must ensure that the new metric still meets the criteria of your variance command for the feasible successor to be installed in the routing table.
In addition, you should also think about what kind of load balancing will take place: per packet or per destination. Per packet may be a bit more efficient, but it can wreak havoc with time sensitive applications like VoIP or videoconferencing because packets may often be received out of order or may experience delays due to different delays for each path taken…
Per destination is preferred. You can find out more about how that is configured (depending upon your platform) either using the IP route cache feature, of configuring CEF appropriately. These are described in the following two links respectively:
I hope this has been helpful!
Laz
Thank you for the lesson is very interesting.
I did not understand the advertised distance of loopback on R2,R3,R4
If I understood correctly
FastEthernet=256*(100/10+10000000/100000)=28160
Loopback=256*(5000/10+10000000/8000000)=128320
The sum is 156480
Am I doing something wrong? Or have any values been customized?
Hello Davide
Let’s take a look at the calculations again for the metric of the loopback with intermediary steps:
Equation = 256 * (10^7/bandwidth + total.delay/10)
= 256 * (10000000/800000 + 5000/10)
=256 * (1.25 + 500)
Now this is where it gets fun. Because Cisco routers do not perform floating point math when calculating the EIGRP metric, the 1.25 is truncated to 1. (Floating point math is any mathematics that involves decimals).
So now the equation becomes:
= 256 * (1 + 500) = 256*501 = 128256
Add this to 28160, and we get 156416.
Now this is still not the value that is advertised from R2, R3, and R4 to R1, and indeed this is stumping me too. For some reason, it seems that in the calculation, the equation is ignoring the value of 1.25 for the bandwidth component of the loopback completely. It could be that the bandwidth of the loopback was adjusted so that the result of 10^7/bandwidth was less than 1, and thus it was truncated down to 0. I’ll consult Rene to find out if this is the case.
In any case, it is of value to keep in mind how EIGRP calculates the metric knowing that at each stage in the calculation, you need to round down to the nearest integer to correctly calculate metrics.
I hope this has been helpful!
Laz