EIGRP Unequal Cost Load Balancing (maths)

the SG has

interface GigabitEthernet1.67
 delay 25
!
interface GigabitEthernet1.146
 delay 131
!
router eigrp 100
 variance 5

This question's mathmatics baffles me.  I have not done algebra since 1997.

I understand what needs to be done - but I do not underderstand the maths.

The solution guide goes from here (relavtive to this topic - dont worry about equal cost on R1)

The total delay of this path is 40 microseconds, or 4 tens of microseconds. Scaled by 256, R1 would be advertising 1024. Because R3's Feasible Distance of 1024 is equal to R6’s Feasible Distance, this path cannot be considered a Feasible Successor.

is this a typo?

to here:

Because the minimum configurable delay value is 10 microseconds, which is already the default for all Ethernet links, and based on task requirements, we need to modify R6's delay values on its VLAN 67 and VLAN 146 interfaces, so that metric through R1 is five times bigger than metric through R7.

then the formuale - which I do not know how to solve.  - was the 250 arbitary?

5 * [Delay(Gi1.9) + Delay(Gi1.79) + Delay(Gi1.67)] = [Delay(Gi1.9) + Delay(Gi1.79) + Delay(Gi1.37) + Delay(Gi1.13) + Delay(Gi1.146)].
5 * [10 + 10 +Delay(Gi1.67)] = [10 + 10 + 10 + 10 + Delay(Gi1.146)]].

I understand that the second line is a simplification of the first - but then how do you get the actual values for the delay on the interface? - It then suggests 250 - but I do not see the algebra workings:

If, for example, we configure delay on R6's VLAN 67 interface to be 250, in simple math we need to configure a delay value of 1310 on R6's VLAN 146 interface. This also means that configuring a variance of 5 will be enough so that both routes for VLAN 9 are installed in the routing table of R6 with the requested load distribution.

 - was the 250 arbitary? - or does it have a direct correlation with the feasability condition - and if so how was it calculated? - I dont mean its obviously 25 x 10s of microseconds - I mean was this pulled out of a hat - could we have used. 500 and 2620 ?

250 + 20 = 270 * 5 which correlates to 1310 + 40 = 1350 

But how was this worked out using maths to satisfy both the feasability condition and the 5 X load balancing ? guess work - or real algebra?

Thanks !


 

Comments

  • Does anyone have some input on this one? I'm confused on this lab also and how the delay calculations were reached.

     

    Thanks

     

     

  • The trick is that you don't have to worry about the mathematics - working with the formula will cause you to have a bad day! The way to approach these problems is to use EIGRP topology table.  For each path you are able to see the metric for a path and also what values of delay and bandwidth have been used.  Note the delay values.

    Following on from this the simplest way to get the required load balancing is to manipulate the metric for a particular path directly using an offset list inbound on the required interface for the path you want to influence.

    Then take a look at the delay value post this change! After removing the offset list you can then find the difference in delay and apply at an interface level.

     

  • Don't forget the delay will be configured in tens of microseconds, while the topology table shows microseconds.

  • I need a better way that "trial and error" with delay to get the required ratios!!! :D

    Could you possible point us in a direction for this method?  Alternatively, run through an example on here?

    It sounds too easy (from initial view) and I've been banging my head against a wall for days now... I have the same issue with the OP - where did this 250 come from??!  Random??!

  • It sounds too easy (from initial view) and I've been banging my head against a wall for days now... I have the same issue with the OP - where did this 250 come from??!  Random??!

    The thing is it is!  I take no credit about this technique - Brain Dennis demonstrated it on the boot camp I did back in 2013!

    Using the formula works how it's very long winded - while with the method the router does all of the work for you!

    Also unless the question explicitly states that only delay values may be changed then an offset list is the quickest way. To get the result.  In addition it also allows you to be selective about which prefixes load balance and which do not!

    I have not tried this scenario out so I don't know where 250 came from - I talking generically about configuring unequal cost load balancing.

  • JoeMJoeM ✭✭✭

    The trick is that you don't have to worry about the mathematics - working with the formula will cause you to have a bad day! The way to approach these problems is to use EIGRP topology table.  For each path you are able to see the metric for a path and also what values of delay and bandwidth have been used.  Note the delay values.


    Following on from this the simplest way to get the required load balancing is to manipulate the metric for a particular path directly using an offset list inbound on the required interface for the path you want to influence.


    Then take a look at the delay value post this change! After removing the offset list you can then find the difference in delay and apply at an interface level.


     

    I really like reading this.  I have to admit that the long route of eigrp formulas gives me a headache when thinking about the lab clock (tick tock).  It always feels like a time-slow-down waiting for one little error in the calcualation, similar to redistribution tasks.

    I wonder how many other CCIE's think this is sufficient.  EDIT: I see that it came directly from BrianD.  That is a good sign.  ;-)

    Thanks WELSHY for posting this method again. 

     

    Lets see if I have this method correct?  ;-)

    1. change EIGRP variation and calculate desired metrics.
            example: 6 to 1 metrics    calculator    6*(lowest metric) = desired total metric

    2. (the cheat) manually adjust the metric with offset for this calculated change.

    3. ....and note the total delay: EIGRP automatically reverse-engineeers the delay factor. ;-)

      Router#sh ip eigrp topology x.x.x.x
           
      x.x.x.x (Ethernet0/1), from y.y.y.y, Send flag is 0x0
          Composite metric is (196608000/66191360), route is External
          Vector metric:
            Minimum bandwidth is 10000 Kbit
            Total delay is 2000000000 picoseconds
            Reliability is 255/255
            Load is 1/255
            Minimum MTU is 1500
            Hop count is 1
            Originating router is z.z.z.z

    4. subtract the original total delay from this number (200000000) = final interface delay

    5. adjust interface delay to above result (in 10's)

    6. VERIFY final variation 6 to 1.       
             show ip route x.x.x.x    or   show ip cef x.x.x.x

  • I think I am getting there and getting a little excited at the thought of a simple method without the internal screaming in my head!

    Is there a Brian M video for this?  Or someone doing it live with a real example?

     

  • I think I am getting there and getting a little excited at the thought of a simple method without the internal screaming in my head!

    Here is an example not even needing a look in the EIGRP table- assumes variance is correct to get unequal load balancing

    We have

    Rack1R7#show ip route 192.168.179.32
    Routing entry for 192.168.179.32/29
      Known via "eigrp 179", distance 90, metric 33536, type internal
      Redistributing via eigrp 179
      Last update from 192.168.179.9 on FastEthernet0/1, 00:04:11 ago
      Routing Descriptor Blocks:
        192.168.179.9, from 192.168.179.9, 00:04:11 ago, via FastEthernet0/1
          Route metric is 33536, traffic share count is 1
          Total delay is 310 microseconds, minimum bandwidth is 100000 Kbit
          Reliability 255/255, minimum MTU 1500 bytes
          Loading 1/255, Hops 3
      * 192.168.179.2, from 192.168.179.2, 00:04:11 ago, via FastEthernet0/0
          Route metric is 33536, traffic share count is 1
          Total delay is 310 microseconds, minimum bandwidth is 100000 Kbit
          Reliability 255/255, minimum MTU 1500 bytes
          Loading 1/255, Hops 3

     

    We have ECMP path - let make the load share 5 to 2 by using an offset list

    The above is represented by the ratio 5:2

    Now the metric is inversely proportionate to the metric.  What I mean by this is for higher load share value I need a lowever metric and vice versa.

    This means that the ratio of the metrics will be 1/5 : 1/2 or equivalently 2/10 : 5/10 (what I have done here change the common demoninator so it common on each side of the ratio - the lowest denominator in this case is 10 - 2 time 5)

    From the above output we can see the metric is 33536 now let this be equivalent to 2/10

    Thus 1/10 is 16768

    So 5/10 is 83840

    This means that I would need to increase the metric inbound into f0/0 to 83840 to get the required loadshare!  As the metric is 33536 the offset needs to be 83840-33536 = 50304

    Applying offset-list 0 in 50304 f0/0 under to EIGRP process we get -

    Rack1R7#show ip route 192.168.179.32
    Routing entry for 192.168.179.32/29
      Known via "eigrp 179", distance 90, metric 33536, type internal
      Redistributing via eigrp 179
      Last update from 192.168.179.9 on FastEthernet0/1, 00:00:02 ago
      Routing Descriptor Blocks:
        192.168.179.9, from 192.168.179.9, 00:00:02 ago, via FastEthernet0/1
          Route metric is 33536, traffic share count is 5
          Total delay is 310 microseconds, minimum bandwidth is 100000 Kbit
          Reliability 255/255, minimum MTU 1500 bytes
          Loading 1/255, Hops 3
      * 192.168.179.2, from 192.168.179.2, 00:00:02 ago, via FastEthernet0/0
          Route metric is 83840, traffic share count is 2
          Total delay is 2275 microseconds, minimum bandwidth is 100000 Kbit
          Reliability 255/255, minimum MTU 1500 bytes
          Loading 1/255, Hops 3

    Although I haven't done this here - if we looked at the eigrp topology table for 192.168.179.32/29 we could look at the delay on for each path. Remember the delay via f0/1 hasn't changed by this process so will be same as the original delay for the path through f0/0.

    UPDATE - why is the delay influenced and not other component of the EIGRP metric.  By default the metric is generated as a composite of the bandwidth and delay - via the formula.  Changing the bandwidth wouldn't make sense - as it's the minimum BW found along a path from the advertising router, whereas delay is additive (like OSPF cost and RIP hop count) - it increases hop by hop.  Thus the offset list only affects the delay part of the metric.

    So 2275-310 = 1965 microseconds - so if we removed the offset list we would need to increase the interface delay fo f0/0 by 1964 microseconds or 196 tens of microseconds

    This case is more complex due the load sharing ratio - so needed to find the common denominator - where whis share of 1 to 5 the metrics would be 1 : 1/5 or 5 : 1 (multiply both sides by 5) So the metric on one side needs to be 5 times larger

     

  • EDIT: I see that it came directly from BrianD

    This almost falls in the catergory - "why keep a dog and bark yourself" - http://idioms.thefreedictionary.com/Why+keep+a+dog+and+bark+yourself? let the router do the heavy lifting for you!

    Anyway you method is right.  In the exam (I know only too well :-() is to use the simplest method to implement a solution. offset in my mind is better as we can link to an ACL and make it more specific whereas changing delay will affect all prefixes learned via that interface.

    I have also added a more complex example where the load share is 5 to 2 - which need an undertanding of fractions and common denominator calculation.

    Also noted that you are using named eigrp process so delay is in pico seconds - 1 micro second = 1000 nano seconds = 1000000 pico seconds - so you need to strip the first 7 digits to get tens of microseconds!

    PS: still practicing to be a CCIE - an expensive process when you fail :-(

  • Thank you

     

    This was the one of many questions that suprsied me when doing the version 4 EIGRP  labs 2-3 years ago.

    Now im doing version 5, this was the ONLY section that suprised me - again.  Im off to do IPSEC now. then back to ospf.  Thanks !

  • You sir, have made my week!  I am going to test (and practice) a whole load of these.

    Again, many thanks for taking the time to give such a clear explanation...  much appreciated by all.

    Thanks, neil.

  • Nope - still can't do it!  I start with 2 equal cost paths, trying to replicate your example.

    Every time I set an "offset-list in", the route immediately fails the feasibility criteria and drops out of the routing table, leaving only the best route in place.

    Variance is set to 128, but never gets chance to kick in.

    Also, changed the EIGRP metrics to only use DELAY too. 

    Any ideas?  Using IOL images, but tried a few with no luck.

  • JoeMJoeM ✭✭✭


    Nope - still can't do it!  I start with 2 equal cost paths, trying to replicate your example.


    Every time I set an "offset-list in", the route immediately fails the feasibility criteria and drops out of the routing table, leaving only the best route in place.


    Variance is set to 128, but never gets chance to kick in.


    If you are doing it on the final destination router, then I do not see how this could be possible.  However, it could happen, if the metric is added on another router in the path before it reaches the final destination.

     

    On the destination router, the offset-list is added for the final metric (not part of the incoming Feasibility test).

    To see this, can you give us the metrics for the two routes in the eigrp topology table?   Thanks.

          show ip eigrp topology x.x.x.x/y  | in Composite metric|Successor

     

  • Using INE topology, I am on R1 and want to unequal cost load balance 3:1 to destination 155.1.9.0/24 (hanging off R9).

     

    Initially, costs via R6 and R3 are equal:

     

    R1#sh ip rout 155.1.9.0

    Routing entry for 155.1.9.0/24

      Known via "eigrp 100", distance 90, metric 358400, type internal

      Redistributing via eigrp 100

      Last update from 155.1.146.6 on Ethernet0/1.146, 00:00:40 ago

      Routing Descriptor Blocks:

        155.1.146.6, from 155.1.146.6, 00:00:40 ago, via Ethernet0/1.146

          Route metric is 358400, traffic share count is 1

          Total delay is 4000 microseconds, minimum bandwidth is 10000 Kbit

          Reliability 255/255, minimum MTU 1500 bytes

          Loading 1/255, Hops 3

      * 155.1.13.3, from 155.1.13.3, 00:00:40 ago, via Ethernet0/1.13

          Route metric is 358400, traffic share count is 1

          Total delay is 4000 microseconds, minimum bandwidth is 10000 Kbit

          Reliability 255/255, minimum MTU 1500 bytes

          Loading 1/255, Hops 3

     

    R1#sh ip eigrp topology 155.1.9.0/24

    EIGRP-IPv4 Topology Entry for AS(100)/ID(150.1.1.1) for 155.1.9.0/24

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

      Descriptor Blocks:

      155.1.13.3 (Ethernet0/1.13), from 155.1.13.3, Send flag is 0x0

          Composite metric is (358400/332800), route is Internal

          Vector metric:

            Minimum bandwidth is 10000 Kbit

            Total delay is 4000 microseconds

            Reliability is 255/255

            Load is 1/255

            Minimum MTU is 1500

            Hop count is 3

            Originating router is 150.1.9.9

      155.1.146.6 (Ethernet0/1.146), from 155.1.146.6, Send flag is 0x0

          Composite metric is (358400/332800), route is Internal

          Vector metric:

            Minimum bandwidth is 10000 Kbit

            Total delay is 4000 microseconds

            Reliability is 255/255

            Load is 1/255

            Minimum MTU is 1500

            Hop count is 3

            Originating router is 150.1.9.9

     

    I create an ACL to only change the metric from 155.1.9.0/24:

     

    access-list 1 permit 155.1.9.0 0.0.0.255

     

    I then make sure the variance is high (128 max), then add the "offset-list in" on the interface facing R6.

     

    router eigrp 100

     variance 128

     offset-list 1 in 716800 ethernet 0/1.146 !choosing 716800 as it will make this path 3x higher than via R3 (eth0/1.13)

     

    Immediately, I lose the route via R6, only giving the route via R3:

     

    R1#sh ip route 155.1.9.0

    Routing entry for 155.1.9.0/24

      Known via "eigrp 100", distance 90, metric 358400, type internal

      Redistributing via eigrp 100

      Last update from 155.1.13.3 on Ethernet0/1.13, 00:00:29 ago

      Routing Descriptor Blocks:

      * 155.1.13.3, from 155.1.13.3, 00:00:29 ago, via Ethernet0/1.13

          Route metric is 358400, traffic share count is 1

          Total delay is 4000 microseconds, minimum bandwidth is 10000 Kbit

          Reliability 255/255, minimum MTU 1500 bytes

          Loading 1/255, Hops 3

    R1#

     

    It's still in the EIGRP topology table, but failing the feasibility rule.

     

    R1#sh ip eigrp topology 155.1.9.0/24

    EIGRP-IPv4 Topology Entry for AS(100)/ID(150.1.1.1) for 155.1.9.0/24

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

      Descriptor Blocks:

      155.1.13.3 (Ethernet0/1.13), from 155.1.13.3, Send flag is 0x0

          Composite metric is (358400/332800), route is Internal

          Vector metric:

            Minimum bandwidth is 10000 Kbit

            Total delay is 4000 microseconds

            Reliability is 255/255

            Load is 1/255

            Minimum MTU is 1500

            Hop count is 3

            Originating router is 150.1.9.9

      155.1.146.6 (Ethernet0/1.146), from 155.1.146.6, Send flag is 0x0

          Composite metric is (1075200/1049600), route is Internal

          Vector metric:

            Minimum bandwidth is 10000 Kbit

            Total delay is 32000 microseconds

            Reliability is 255/255

            Load is 1/255

            Minimum MTU is 1500

            Hop count is 3

            Originating router is 150.1.9.9

     

     

    And I doing something fundamentally wrong here??!

  • JoeMJoeM ✭✭✭

    Using INE topology, I am on R1 and want to unequal cost load balance 3:1 to destination 155.1.9.0/24 (hanging off R9).







    R1#sh ip eigrp topology 155.1.9.0/24




    EIGRP-IPv4 Topology Entry for AS(100)/ID(150.1.1.1) for 155.1.9.0/24




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




      155.1.13.3 (Ethernet0/1.13), from 155.1.13.3, Send flag is 0x0




          Composite metric is (358400/332800), route is Internal




      155.1.146.6 (Ethernet0/1.146), from 155.1.146.6, Send flag is 0x0




          Composite metric is (358400/332800), route is Internal





     

    OK.  We can see that the (final metric/received advertised metric) are equal.

           (358400/332800)

       358400-332800=25,600 is added by R1

     

     


    I create an ACL to only change the metric from 155.1.9.0/24:


    access-list 1 permit 155.1.9.0 0.0.0.255


    I then make sure the variance is high (128 max), then add the "offset-list in" on the interface facing R6.




    router eigrp 100


     variance 128


     offset-list 1 in 716800 ethernet 0/1.146 !choosing 716800 as it will make this path 3x higher than via R3 (eth0/1.13)


     

    Which router is this done on?   It should be done on R1, where you are looking for the final result.

     


    It's still in the EIGRP topology table, but failing the feasibility rule.




    R1#sh ip eigrp topology 155.1.9.0/24


    EIGRP-IPv4 Topology Entry for AS(100)/ID(150.1.1.1) for 155.1.9.0/24


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


      Descriptor Blocks:


      155.1.13.3 (Ethernet0/1.13), from 155.1.13.3, Send flag is 0x0


          Composite metric is (358400/332800), route is Internal


      155.1.146.6 (Ethernet0/1.146), from 155.1.146.6, Send flag is 0x0


          Composite metric is (1075200/1049600), route is Internal



     

    It seems to me that maybe you have changed the offset on R6.  Wrong router.

    1075200-1049600=only 25,600 added by R1, which is the same as before.

      Final - Received-Advertised-Metric

     

    But if we subtract the difference on the Received-Advertised-Metric we get your offset.   ????

       1,049,600(new) - 332,800(original) = 716,800   received on R1????

     

    Clear your neighbors and look at it again, but I believe you may have configured the wrong router.

  • No, I am only doing configuration on R1, nothing else.  Checked the other routers for "delay" under interface or any other offset-list and nothing there.  I am using the basic-eigrp configs.

     

    R1#sh run | s router

    router eigrp 100

     network 150.1.0.0

     network 155.1.0.0

     offset-list 1 in 716800 Ethernet0/1.146

    R1#


    here is R6:


    R6#sh run | s router

    router eigrp 100

     network 150.1.0.0

     network 155.1.0.0

    R6#



    here is R3:


    R3#sh run | s router

    router eigrp 100

     network 150.1.0.0

     network 155.1.0.0

    R3#



    here is R7:


    R7#sh run | s router

    router eigrp 100

     network 150.1.0.0

     network 155.1.0.0

    R7#




    I am glad something looks odd - I have been at this for hours and going slightly mad!! :D
  • And I doing something fundamentally wrong here??!

    This doesn't seem correct - the offset list  or applying a different delay to e0/1.146 would not change the reported distance (RD).

    From your output this has tripled - breaking the feasability condition.

    The offset list should change the what metric that is assigned to the interface.

    You could try this - remove the offset list

    Your change in delay is 32000 - 4000 = 28000 microseconds.

    Look at the delay configured on e0/1.146 from show interface e0/1.146

    Then increase the delay by 2800 tens of microseconds.

    Of course this will affect all routes

  • JoeMJoeM ✭✭✭

    Hey Welshy,   Thanks for staying in this conversation.  I just got a huge headache about this. 

    I just did a mini-lab sanity test on gns3 15.2(4)M5, and the offset did change the Reported Distance.  Back to the books for me.  arrrgh

    May be a bug in this IOS-- or I have to relearn something.    double-arrrrggghhhh

     

    BEFORE:=================

    R1(config-router)#do sh ip eigrp topolog  2.2.2.2/32
    EIGRP-IPv4 Topology Entry for AS(100)/ID(111.111.111.111) for 2.2.2.2/32
      State is Passive, Query origin flag is 1, 1 Successor(s), FD is 156160
      Descriptor Blocks:
      12.12.12.2 (FastEthernet0/1), from 12.12.12.2, Send flag is 0x0
          Composite metric is (156160/128256), route is Internal

    156160-127256=28,904

     

    AFTER:=================

    R1(config-router)#offset-list 0 in 111111 f0/1

    R1(config-router)#do sh ip eigrp topolog  2.2.2.2/32
    EIGRP-IPv4 Topology Entry for AS(100)/ID(111.111.111.111) for 2.2.2.2/32
      State is Passive, Query origin flag is 1, 1 Successor(s), FD is 267271
      Descriptor Blocks:
      12.12.12.2 (FastEthernet0/1), from 12.12.12.2, Send flag is 0x0
          Composite metric is (267271/239360), route is Internal

    267271-239360=27,911  ???

    239360(new reported) - 128256 (original reported) = 111,104 

     

    router eigrp 100
     network 1.1.1.1 0.0.0.0
     network 12.12.12.1 0.0.0.0
     offset-list 0 in 111111 FastEthernet0/1

  • JoeMJoeM ✭✭✭

    Walked away..........came back and tested in another IOS.  What a relief.

              Huge BUG ALERT in gns3 15.2(4)M5

    But I did learn something today (lol).   Offset is added to the original FD.

     

    Retested in different IOS.

    BEFORE=========================

    R1(config-router)#do sh ip eigrp topol 2.2.2.2/32
    IP-EIGRP (AS 100): Topology entry for 2.2.2.2/32
      State is Passive, Query origin flag is 1, 1 Successor(s), FD is 409600
      Routing Descriptor Blocks:
      12.12.12.2 (FastEthernet0/0), from 12.12.12.2, Send flag is 0x0
          Composite metric is (409600/128256), Route is Internal
          Vector metric:
            Minimum bandwidth is 10000 Kbit
            Total delay is 6000 microseconds
            Reliability is 255/255
            Load is 1/255
            Minimum MTU is 1500
            Hop count is 1

    AFTER========================

    R1(config-router)#offset-list 0 in 111111 f0/0
       
    R1(config-router)#do sh ip eigrp topol 2.2.2.2/32
    IP-EIGRP (AS 100): Topology entry for 2.2.2.2/32
      State is Passive, Query origin flag is 1, 1 Successor(s), FD is 409600
      Routing Descriptor Blocks:
      12.12.12.2 (FastEthernet0/0), from 12.12.12.2, Send flag is 0x0
          Composite metric is (520711/128256), Route is Internal
          Vector metric:
            Minimum bandwidth is 10000 Kbit
            Total delay is 10340 microseconds
            Reliability is 255/255
            Load is 1/255
            Minimum MTU is 1500
            Hop count is 1

    409600(original FD) + 111111(offset = 520,711

    (example) needed delay = 10340 - 6000 = 4340u + original interface delay

  • In fairness when I used this feature it was in 12.4T and not in 15 - the offset list acts like it is adding delay to interface!

  • JoeMJoeM ✭✭✭

    Thanks again Welshy for comfirming this.    

    I retested it in 12.4 and 15.4(1)T, and it works as it should.   For all of the time spent with the issue, I guess that I will chalk-it-up to good practice with the EIGRP variance/offset trick.  ;-)

  • So the solution worked on R1, however the requirements on the INE site call for the delay to be adjusted on R6, not R1.

    • Configure unequal cost load balancing so that traffic from R6 going to VLAN 9 is load balanced between R1 and R7.
      • Traffic share should be configured so that the link to R7 is used five times as much as the link to R1.
      • Modify delay on R6 as required.

    Are we barking up the wrong tree here using R1? Or are you making the offset-list changes on R1, checking the delay amounts, removing the offset-list on R1 and then making those delay adjustments on R6?

    Thanks

  • I was simply using the INE topology and coming up with my own scenario using the BASIC-EIGRP configurations.

    My scenario was getting UCLB to work from R1 to 155.1.9.0/24 (a subnet hanging off R9).

     

    I have checked all of my IOSes and every single on adds the metric in the offset-list to the AD *and* FD, therefore, something must be wrong with my IOSes or the platform I am using (WEB-IOU)... I fully expect the metric in the offset-list to only add to FD and the AD remains as is.

    Will keep investigating...

  • JoeMJoeM ✭✭✭

    I retested it in 12.4 and 15.4(1)T, and it works as it should. 

    Just to reassure you.....I tested the above successfully.   12.4 in GNS3  and 15.4(1)T in IOU.

     

     

  • Could you please verify the IOU filename you have for 15.4(1)T?

    I am using i86bi_linux-adventerprisek9-ms.154-1.T_A to no avail.

    I will not let this lie!!! I must see this with my own eyes!! [:D]

  • JoeMJoeM ✭✭✭

    In the above posts, I have already verified the three different IOS's.  

    Maybe try it in a different IOS that you have, or maybe try it in 12.4T.

     

     

  • I did notice that your total delay on interface Ethernet0/1.146 went from 4000 microseconds to 32000 microseconds, and it could be impacting your advertised distance. It is 1049600

    Remember that the advertised distance MUST be less than the feasible distance of the successor before it can be considered for load-balancing.

  • Hi,

    My approach:

    Path Delay 1 = R6 - R7 - R9 = 30

    Path Delay 2 = R6 - R1 - R3 - R7 - R9 = 50

    30/10 = 3 * 256 = Metric 1 768 (Gi1.67)

    50/10 = 5 * 256 = Metric 2 1280 (Gi1.146)

    Now first thing I did was to equalize metrics(by adding to the lowest one link). This will get me an equal starting point on both links, so it will be easier later.

    So I had to add the difference in metric on G1.67 so both links metric

    showed as 1280.  So,

    1280 - 768 = 512  ,   Now, let's see how much delay we need to add to equalize the metric. 

    If Metric = delay * 256, that means the equation for Delay will be:

    Delay = Metric / 256  ---> 512 / 256 = 2 <  We need to add this amount of delay on G1.67 Link.

    R6(iconfig-if)# delay 3**  (Is 3 because we add to the current delay value of the link) This value is the delay from the show ip int G1.146 | i DLY:

    MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec.      -   10 / 10 = Delay of 1  So we add to this value. And Since we are overriding the default value, we must take this into account as well.)

    Okay now R6's routing table should be something like this:

    R6#sh ip route 155.1.9.0
    Routing entry for 155.1.9.0/24
      Known via "eigrp 100", distance 90, metric 1280, type internal
      Redistributing via eigrp 100
      Last update from 155.1.146.1 on GigabitEthernet1.146, 00:32:40 ago
      Routing Descriptor Blocks:
        155.1.146.1, from 155.1.146.1, 00:32:40 ago, via GigabitEthernet1.146
          Route metric is 1280, traffic share count is 1 <<<<<<<<<<<<<<<<<<< Share Count is 1
          Total delay is 50 microseconds, minimum bandwidth is 1000000 Kbit
          Reliability 255/255, minimum MTU 1500 bytes
          Loading 1/255, Hops 4
      * 155.1.67.7, from 155.1.67.7, 00:32:40 ago, via GigabitEthernet1.67
          Route metric is 1280, traffic share count is 1 <<<<<<<<<<<<<<<<<<< Share Count is 1
          Total delay is 50 microseconds, minimum bandwidth is 1000000 Kbit
          Reliability 255/255, minimum MTU 1500 bytes
          Loading 1/255, Hops 2

    Now that the metrics are equal is easier to compute what is request by the task.

    The task ask us to :

    1. Configure unequal cost load balancing so that traffic from R6 going to VLAN 9 is load balanced between R1 and R7.
    • Traffic share should be configured so that the link to R7 is used five times as

                  much as the link to R1.  <--------- 5:1 Ratio

    • Modify delay on R6 as required.

     

    Next step is to add a value on one of the links so the end metric is 5 times higher than the other one.  In this case that would be G1.146.

    Actual metric is 1280 and that * 5 = 6400. That's the metric we need to get.

    Now, keep in mind that we are adding to the actual value of the metric, so to get to 6400 we just need to add the difference between 6400 (final metricl) and 1280 (actual metric) which is :  6400 - 1280 = 5120 < ----

    Now that have the metric value were adding, we need to convert it to the corresponding delay value for the interface.

    Delay = Metric / 256 --> Delay = 5120 / 256 --> Delay = 20

    We need to add a delay of 20 + 1*

    *Again we add 1 because we add to the current delay value of the link. This value is the delay from the show ip int G1.146 | i DLY:  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec.      -   10 / 10 = Delay of 1  So we add to this value.  And Since we are overriding the default value, we must take this into account as well.

    R6(config-if)#  delay 21

    Now that the corresponding delay values are in place, we just add a variance value of 5 under EIGRP router config

    R6(config-router)# variance 5

    Then we check the route again:

    Routing entry for 155.1.9.0/24
      Known via "eigrp 100", distance 90, metric 1280, type internal
      Redistributing via eigrp 100
      Last update from 155.1.146.1 on GigabitEthernet1.146, 00:00:32 ago
      Routing Descriptor Blocks:
        155.1.146.1, from 155.1.146.1, 00:00:32 ago, via GigabitEthernet1.146
          Route metric is 6400, traffic share count is 1 <---------------------------------------------------
          Total delay is 250 microseconds, minimum bandwidth is 1000000 Kbit
          Reliability 255/255, minimum MTU 1500 bytes
          Loading 1/255, Hops 4
      * 155.1.67.7, from 155.1.67.7, 00:00:32 ago, via GigabitEthernet1.67
          Route metric is 1280, traffic share count is 5 <---------------------------------------------------
          Total delay is 50 microseconds, minimum bandwidth is 1000000 Kbit
          Reliability 255/255, minimum MTU 1500 bytes
          Loading 1/255, Hops 2

    Notice the route share count now G1.146 is 1 and G1.67 is 5; we achieved a 5:1 ratio. 

    Now R6 will route traffic through R7 five times as much as through R1.

    I'm using the CSR1000v for my lab so I can't disable CEF, which means in order to provide debugging would require a hell of a post.  But with the

    show ip route 155.1.9.0 output you get how much traffic would be sent to each of the links.  HTH

     

    Config:

    router eigrp 100
     metric weights 0 0 0 1 0 0
     variance 5
     network 150.1.0.0
     network 155.1.0.0

    Current configuration : 146 bytes
    !
    interface GigabitEthernet1.146
     encapsulation dot1Q 146
     ip address 155.1.146.6 255.255.255.0
     delay 21 <--------------------------------
     ipv6 address 2001:155:1:146::6/64
    !
    interface GigabitEthernet1.67
     encapsulation dot1Q 67
     ip address 155.1.67.6 255.255.255.0
     delay 3 <-----------------------------------
     ipv6 address 2001:155:1:67::6/64
    end

     

     

  • Thanks c1sc0m . This helped me out a lot!

  • Glad to help.  I tried to explain this as best as I could, since English is not my native language.  So I apologize for any grammar mistakes.

     

    But the key point I wanted to share is to equalize the metrics so you get an equal starting point for the calculations.

Sign In or Register to comment.