EIGRP Variance

[john.pepper]

Hi,

Our customer wants load-balance across unequal circuits due to the primary link being saturated. Primary link is 10Mb and backup is 4mb (multilink 2 x 2Mb).

I have tried implementing this using ‘variance’ under EIGRP on the 6500 switch but can’t seem to get both WAN routes in the routing table - unless I use the same metric on the route-maps we use for redistribution – e.g. set metric 10000 100 255 1 1500

If I do this the 6500 sees both routes but I’m concerned too much traffic will go via the lower speed link causing more problems. I have adjusted the delay under redistribution to make the 4Mb less preferred and I see this under ‘show ip eigrp top’ and thought the ‘variance’ command on the 6500 switch would work. But no matter what I set variance to it still doesn’t enter the less preferred route in the routing table.

I’m guessing this is down to the FD of the other route.? Any help is appreciated.

Thanks...John

Topology is as follows:

____

       |----2800---WAN (10Mb)

6500]

____|----3640---WAN (4Mb)

We use BGP on the WAN and redistribute into EIGRP on the LAN using route maps as follows:

2800 (10Mb)

router eigrp 5555

redistribute bgp 888 metric 10000 200 255 1 1500 route-map bgp-eigrp

no auto-summary

router bgp 888

redistribute eigrp 5555 route-map eigrp-bgp

route-map bgp-eigrp permit 30

description set eigrp metric and set tag

set metric 10000 100 255 1 1500

route-map eigrp-bgp permit 20

description permit all other routes learned via EIGRP

3640 (4Mb)

router eigrp 5555

redistribute bgp 888 metric 4000 400 255 1 1500 route-map bgp-eigrp

router bgp 888

redistribute eigrp 8001 route-map eigrp-bgp

route-map bgp-eigrp permit 30

description set eigrp metric and set tag

set metric 4000 200 255 1 1500

route-map eigrp-bgp permit 20

description permit all other routes learned via EIGRP

6500

Topology entry for 10.10.10.0 /24

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 281856

192.168.1.2 (Vlan1), from192.168.1.2 Send flag is 0x0

      Composite metric is (281856/281600), Route is External

     Vector metric:

       Minimum bandwidth is 10000 Kbit

       Total delay is 1010 microseconds

       Reliability is 255/255

       Load is 1/255

       Minimum MTU is 1500

       Hop count is 1

     External data:

       Originating router is 192.168.2.7

       AS number of route is 888

       External protocol is BGP, external metric is 0

       Administrator tag is 999 (0x000003E7)

192.168.1.3 (Vlan1), from192.168.1.3 Send flag is 0x0

     Composite metric is (1341696/1341440), Route is External

     Vector metric:

       Minimum bandwidth is 4000 Kbit

       Total delay is 2010 microseconds

       Reliability is 255/255

       Load is 1/255

       Minimum MTU is 1500

       Hop count is 1

     External data:

       Originating router is 192.168.3.7

       AS number of route is 888

       External protocol is BGP, external metric is 0

       Administrator tag is 999 (0x000003E7)

[Marwan ALshawi]

this link is  blog from INE very good one to understand EIGRP loadbalncing

http://blog.ine.com/2009/05/01/understanding-unequal-cost-load-balancing/

HTH

if helpful Rate

[john.pepper]

Thank you, this helps.

[Richard Burts · Accepted solution]

John

For unequal cost load balancing to work the higher cost link must qualify as a feasible successor. From the topology table information in your post the alternate link is not a FS. You need to get the metrics closer to each other to get unequal cost load balancing.

HTH

Rick

Sent from Cisco Technical Support iPhone App

[john.pepper]

Rick,

Thank you.. 

Problem is I can't get seem to get the alternate link to be a FS unless I match exactly the bandwiidth/delay etc. on the redistribution from the 4mb router - e.g.

route-map bgp-eigrp permit 30

description set eigrp metric and set tag

set metric 10000 100 255 1 1500

If I do this I see the alternate route as a FS and don't really need the variance command.  Trouble is then too much traffic may route across this lesser speed link. 

If I adjust the bandwidth or delay down slightly I don't seem to see the router as a FS... 

Any thoughts.?

Cheers

John

[Joseph W. Doherty]

Disclaimer

The     Author of this posting offers the information contained within this     posting without consideration and with the reader's understanding  that    there's no implied or expressed suitability or fitness for any   purpose.   Information provided is for informational purposes only and   should not   be construed as rendering professional advice of any kind.   Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In     no event shall Author be liable for any damages whatsoever   (including,   without limitation, damages for loss of use, data or   profit) arising  out  of the use or inability to use the posting's   information even if  Author  has been advised of the possibility of  such  damage.

Posting

Keeping in mind that EIGRP unequal-cost routing just proportionally round-robins flows, and if the primary link is truly saturated, you might not realize as much benefit as you might hope for, nor see much of an improvement over equal cost routing.

With or without any kind of multi-path load sharing, you might want to review your QoS policy.  If you're only using FIFO, you might want to consider having a QoS policy.

Instead of dynamically routing across both links, you might consider using one link for high priority or conversely low priority using PBR.

If your IOSs are new enough (3640 might be a problem), you could also consider the PIRO capable version of OER/PfR which can dynamically load balance across different bandwidth links.

[Richard Burts]

John

I do not know what other values you have used in your attempts to get the unequal cost load balancing to work but I would think that if the difference in redistribution metric were small that the higher cost route might qualify as a feasible successor.

In looking at the output that you posted the differences in bandwidth and delay make a very large difference in reported distance at the 6500 (281600 for one and 1341440 for the other). If you can get those numbers closer together then the load sharing might work.

Perhaps you can post an updated set of redistribution metrics and the resulting topology table on the 6500.

HTH

Rick