EIGRP Variance Command Example

Hello Hugues

Yes, I see what you mean. The actual value of the LAN portion, when added, changes the value of the calculated variance. So yes, to confirm, you must also include the cost of the LAN portion of the route to the destination in the calculation of the variance.

I hope this has been helpful!

Laz

1 Like

everything clears up, thank you

1 Like

Hi Rene,

Thanks for your great class.
I just wanted to know, in your example when we used the second variance (Variance 15) is it override the (Variance 3) for the same AS? or you used both?
if it is override it, then are all the links in the router will use the variance 15 only?

Hello Wisam

When you configure the variance for EIGRP, it overwrites the previous setting. So when a variance of 15 was applied to EIGRP process 1, the value of 3 was replaced with 15. With the specific configuration of a variance of 15, all three links are being used, as is shown in the routing table of R1:

R1#show ip route | begin 5.5.5.5
D       5.5.5.5 [90/2300416] via 192.168.14.4, 00:00:05, Serial2/0
                [90/412160] via 192.168.13.3, 00:00:05, Ethernet1/0
                [90/158720] via 192.168.12.2, 00:00:05, FastEthernet0/0

Variance is not something that is applied to each individual link, but is used to calculate how many paths will be included in the routing table. The value of 15 is applied to ALL routes within the EIGRP process. It is a value used to compare alternate paths to the successor (best path) to see if they should be included in the routing table.

I hope this has been helpful!

Laz

1 Like

Hi Rene,

I’ve enabled variance and I can see according to the “show ip route” command that the unequal links are load balancing, however they are load balancing as a 1:1, even though the delay (and therefore metric) are different. This is what I am seeing:

    Routing entry for 192.168.50.0/24
Known via "eigrp 987", distance 90, metric 1026560, type internal
  Redistributing via eigrp 987
  Last update from 192.168.10.2 on GigabitEthernet0/1, 00:02:15 ago
  Routing Descriptor Blocks:
  * 192.168.20.2, from 192.168.20.2, 00:02:18 ago, via GigabitEthernet0/0
      Route metric is 1026560, traffic share count is 1
      Total delay is 40000 microseconds, minimum bandwidth is 1000000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2
    192.168.10.2, from 192.168.10.2, 00:02:15 ago, via GigabitEthernet0/1
      Route metric is 1154560, traffic share count is 1
      Total delay is 45000 microseconds, minimum bandwidth is 1000000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2

Any idea why the Share Count is 1 for both? I can’t figure it out.

Thanks!

Hello Louis

This is indeed strange. Since the metrics of the two routes are indeed different, and you do see both routes in the routing table, and you have configured the variance command, then the traffic share count should not be 1:1.

One thing that I suspect is that because the metrics are relatively close, it may be that the router is estimating, or assuming that the ratio between the two metrics is close enough to 1:1 to use that as the share count. For example, the ratio of your metrics above is 1026560/1154560 = 0.8891 or about a share count of 89:100.

I tried to replicate your results by creating two routes that have a very close metric, and when I got my metrics to be 156416/154880 their share counts were 119:120 which does show a difference even though the metrics are almost the same. I further adjusted the parameters to get a closer metric value of 156416/156160 which, even though the metrics are not the same, did indeed result in a share count of 1:1.

So if you get the metrics close enough, even though they are not the same, you will eventually get a share ratio of 1:1 simply because you’re close enough to that value to warrant its use.

Now this doesn’t completely resolve the issue, because your difference in metric was quite large, where I had to get the metric values much closer to each other to result in a share count of 1:1, but this may depend on the IOS as well as the router platform that is being used. For my tests I used Cisco IOSv Software (VIOS-ADVENTERPRISEK9-M), Version 15.7(3)M3.

I hope this has been helpful!

Laz

1 Like

Is it possible to use Variance so that it only effects a specific network in the RIB and not the entire RIB? Would it only be avaialble in a CSR under named mode TOPOLOGY Name?

Hello Marc

The variance feature for EIGRP is something that you apply across the board. It is not prefix-specific. When using named mode, you can enable and configure it under the topology base configuration mode, but only on a per address-family basis… Beyond that, you can’t get any more specific.

If you want to adjust how a particular prefix will be routed independently of others, the most control can be obtained using route-maps or policy-based routing. You can take a look at the following lessons for more information.


Using route maps, you can actually change the metric of a particular prefix such that it will fall within the tolerance of the configured variance value, and in that way, cause that specific prefix to behave the way you want it.

I admit that the above may not fully resolve the issue you’re facing. However, it would be helpful if you would share with us what exactly you would like to achieve. By doing so, we may be able to suggest another option that would suit your needs even better…

I hope this has been helpful!

Laz

1 Like

Why we call that the control plane is the opposite direction of data plane , ??

if i change the BW and DELAY on an interface , How it impacts the traffic in terms of inbound and outbound ??

Hello Narad

I’m not sure what you mean. Can you clarify your question?

Bandwidth and delay as components of the EIGRP metric are always measured in an outbound direction. That means that the EIGRP metric is affected by the bandwidth or delay configurations of an interface for paths that have an outbound direction on that interface. For example, take a look at this network diagram:

If we change the bandwidth on the Fa 0/1 interface of R3, then the metric from R1 to destination 5.5.5.5 will be affected, because, for that path, Fa1/0 is participating as an outbound interface. This change, however, will not affect the metric from R5 to the E1/0 interface of R1 for example…

I hope this has been helpful!

Laz

1 Like

Great explanation! I am using CML for these labs and we cannot assign Fa or S links between devices. This creates an issue where the FD and AD for many of these routes are the same. What happens when the FD is the same across mulitple routes and none is lower than the other?

r1(config-router)#do sho ip ei topo 5.5.5.5 255.255.255.255
EIGRP-IPv4 Topology Entry for AS(1)/ID(192.168.14.1) for 5.5.5.5/32
  State is Passive, Query origin flag is 1, 3 Successor(s), FD is 131072
  Descriptor Blocks:
  192.168.12.2 (GigabitEthernet0/0), from 192.168.12.2, Send flag is 0x0
      Composite metric is (131072/130816), route is Internal
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 5020 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2
        Originating router is 5.5.5.5
  192.168.13.3 (GigabitEthernet0/1), from 192.168.13.3, Send flag is 0x0
      Composite metric is (131072/130816), route is Internal
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 5020 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2
        Originating router is 5.5.5.5
  192.168.14.4 (GigabitEthernet0/2), from 192.168.14.4, Send flag is 0x0
      Composite metric is (131072/130816), route is Internal
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 5020 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2
        Originating router is 5.5.5.5

Hello Kyle

When two or more routes to a particular destination exist that have the same metrics, the EIGRP will perform equal-cost load balancing (ECLB) by default. You can think of ECLB for EIGRP as a special case of unequal cost load balancing, where the variance is simply set to 1 (by default) which means load balancing will take place only if the metrics are exactly the same.

EIGRP will load balance up to 4 equal paths, but this can be increased by using the maximum-paths command in EIGRP router mode. More info about this can be found here:
https://www.ciscopress.com/articles/article.asp?p=2101519&seqNum=2

I hope this has been helpful!

Laz

>R3 and R4 have been selected as feasible successors because their advertised distance of 156.160 is lower than the feasible distance (158.729) of R2.

Isn’t the feasible distance of R2 158.720?

Hello Shogo

Yes, you are correct. That seems to be a typo. It should be 158720. I will let Rene know to make the correction.

Thanks for pointing that out!

Laz

1 Like

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:

  1. 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…
  2. 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