Task 2.5 - Some weird behavior

Hi,

I understand how this is done; however, for some reason I see in EIGRP topology that the minimun BW is 1Kbit. First thing I don't understand is why is this value showing up. I have gone thru all the devices in the path and none of them has the bandwidth manually configured. Second thing is that since this BW value is very low, and EIGRP metric is a function of the inverse of the BW scaled by 10^7 (and K1 and 256, but I'm just trying to keep this simple), when doing the math the delay values to achieve the desired ratios are either really large (unsupported by IOS) or negatives. I have reloaded the routers, but I keep seeing BW as 1Kbit. Following are my outputs. I don't have a clue on what could be wrong.

 

=========R4===========

Rack1R4#sh ip eigrp topo 192.10.1.0
IP-EIGRP (AS 1024): Topology entry for 192.10.1.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2561536256
  Routing Descriptor Blocks:
  174.1.45.5 (FastEthernet0/1), from 174.1.45.5, Send flag is 0x0
      Composite metric is (2561536256/2560000256), Route is External
      Vector metric:
        Minimum bandwidth is 1 Kbit
        Total delay is 60010 microseconds
        Reliability is 1/255
        Load is 1/255
        Minimum MTU is 1
        Hop count is 1
      External data:
        Originating router is 150.1.5.5 
        AS number of route is 0
        External protocol is RIP, external metric is 0
        Administrator tag is 0 (0x00000000)
  174.1.145.1 (Serial0/0/0), from 174.1.145.1, Send flag is 0x0
      Composite metric is (2565504512/2560000512), Route is External
      Vector metric:
        Minimum bandwidth is 1 Kbit
        Total delay is 215020 microseconds
        Reliability is 1/255
        Load is 1/255
        Minimum MTU is 1
        Hop count is 2
      External data:
        Originating router is 150.1.5.5 
        AS number of route is 0
        External protocol is RIP, external metric is 0
        Administrator tag is 0 (0x00000000)

Rack1R4#sh int s0/0/0 | i B  
  MTU 1500 bytes, BW 1544 Kbit/sec, DLY 215000 usec,
  Broadcast queue 0/64, broadcasts sent/dropped 47/0, interface broadcasts 47
Rack1R4#sh int fa0/1 | i BW
  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 60000 usec,

 

==============R1============

Rack1R1#sh int s0/0/0 | i BW
  MTU 1500 bytes, BW 1544 Kbit/sec, DLY 10 usec,

 

=============R5==============

Rack1R5#sh int s0/0/0 | i BW
  MTU 1500 bytes, BW 1544 Kbit/sec, DLY 10 usec,
Rack1R5#sh int fa0/1.52 | i BW
  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,

Rack1R5#sh int fa0/1 | i BW
  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,

Rack1R5#sh int fa0/0 | i BW
  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,

==============================================

I really appreciate if someone could shed some light on this issue.

 

Thanks,

Jorge

Comments

  • Hello Jorge,

    Actually i faced the same problem going throug the formulla to get the appropriate delay values but in vain i couldnt .

    I solved this by altering the EIGRP to use onle the Delay  and handled the delay which is much easier, i dont know if this answer is valid or not and i appreciate if any one could validate if it is , or provide a much clearer way to how could we get the appropriate delay values is case BW is still used.

     

    Regards

    Ahmed

  • Yes, I agree. Doing this just based on delay is easier. I don't see why this should not be valid.

  • Hi Jorge,

    I had the same thing with my metrics (BW showing up as 1 kbps).

    After about 30 minutes I found that I redistributed RIP into EIGRP, using metric 1 1 1 1 1.

    When I modified the redistribution-metrics to more realistic values, all was looking okay.

  • In my opinion solution for this task is not full. Without metric weight manipulation or interface bandwidth manipulation feasible condition for RIP routes come from R1 on R4 will be never met. So you can add even variance 128 and it makes no result. The best solution is of course modification of metric weight but how to find out if it's allowed or not. Ech it's so annoying :).

  • I agree.  I have come to the conclusion I cannot get this to work because the feasiblity condition is not being met.  I am using redistribute rip metric 1 1 1 1 1 also.

     

    Why would INE put the typical default metrics in the redistribution example if they teach to use the default metrics of 1 1 1 1 1 1 for redistribution into eigrp?

  • Ok, I got it working.

    I went ahead and changed the k-values so that bandwidth is being discarded.

    On R4, R5, R1, and R3 I issued "metric weights 0 0 0 1 0 0".  This will make the calculation much easier.

    The KEY to getting this to work properly is to make sure you satisfy the feasibilty condition!!

    Thus with respect to R4, you need the AD learned from R1 to be lower than the FD (which is thru the FastEthernet Link).

    Here are the values I set:

    LINK VIA ETHERNET LAN (total delay = 60 microsecs)

    R4 FA0/1 delay = 5 (50 microsecs)

    +

    R5 Redistribution delay = 1 (10 microsecs)

     

    LINK VIA FRAME-RELAY (total delay = 240 microsecs)

    R4 S0/0/0 delay = 22 (220 microsecs)

    +

    R1 S0/0 delay = 1 (10 microsecs)

    +

    R5 Redistribution delay = 1 (10 microsecs)

    This will give you a ratio of 60:240 = 1:4 (I chose the value of 60 arbitrarily and worked backwards from there).

    Remeber again the key is the feasibility condition.  The delay on R1's S0/0 MUST be low, otherwise it will make the Advertised distance that R4 learns from R1 higher than the Feasible Distance from the Ethernet LAN and EIGRP will not be able to install the alternate route no matter what the variance is set to.

    Recall the the first step in EIGRP for a route to become a backup route is that it must meet the feasibility condition.  The next step would be to check the variance.

     

    Hope this helps.

     

  • dude

     

    thanks for the expanation i was banging my head i was doing only delay metrics to keep it simple but in didn't put any weight into the FD condition #@$%

     

     

  • Dear all,

    why is the feasibility condition is not met if we are using redistribute rip metric 1 1 1 1 1? The feasibility condition states that as long as the reported distance is less than the feasible distance then its okay to use it right? In the above case, the feasible distance via ethernet link is 2561536256, while the reported distance from R1 is 2560000512. This is less than the feasible distance. Can someone explain? Or maybe I am wrong at some point?

  • INE is using more realistic redistribution values because of the max metric behavior. I think eigrp can not compute a metric size greater than 4294967295.
    If you use the values 1 1 1 1 1 you create a very large metric of 2560000512. This value is multiplied by the variance to activate unequel loadshare.

    In the solution guide is mentioned to redistribute in task 2.4  with 10000kbit/s which equals to a 10MBit Interface.
    When you distribute with 100000kbit/s (FastEthernet) you face the problem of feasibility condition because the lowest Interface Bandwidth on VLAN45 is then 100MBit. The feasible distance seen in R4 from R1 will in this case nearly never met the conditions because the slowest interface on Serial side is 1544kbit/s.

     

     

     

     

     

     

  • I would avoid complex calculations to do this task as this might impact next/previous tasks on the real lab. Not to mention it can take lots of precious time.

    I just did what the task asked although this won'be as much as elegant as SG:

     

    Rack3R4#sh ip route 192.10.3.0
    Routing entry for 192.10.3.0/24
      Known via "eigrp 1024", distance 170, metric 2170113, type external
      Redistributing via eigrp 1024
      Last update from 174.3.145.1 on Serial0/0/0, 00:00:52 ago
      Routing Descriptor Blocks:
        174.3.145.1, from 174.3.145.1, 00:00:52 ago, via Serial0/0/0
          Route metric is 8680452, traffic share count is 1
          Total delay is 274320 microseconds, minimum bandwidth is 1544 Kbit
          Reliability 255/255, minimum MTU 1500 bytes
          Loading 1/255, Hops 2
      * 174.3.45.5, from 174.3.45.5, 00:00:52 ago, via FastEthernet0/1
          Route metric is 2170113, traffic share count is 4
          Total delay is 74770 microseconds, minimum bandwidth is 10000 Kbit
          Reliability 255/255, minimum MTU 1500 bytes
          Loading 1/255, Hops 1


    Rack3R4#sh run | sec (router eigrp|FROM_BB)
    router eigrp 1024
     variance 4
     offset-list FROM_BB2 in 1911297 FastEthernet0/1
     offset-list FROM_BB2 in 5998340 Serial0/0/0

     network 150.3.4.4 0.0.0.0
     network 174.3.45.4 0.0.0.0
     network 174.3.145.4 0.0.0.0
     no auto-summary
     eigrp router-id 150.3.4.4
    ip access-list standard FROM_BB2
     permit 222.22.2.0 0.0.0.255
     permit 220.20.3.0 0.0.0.255
     permit 205.90.31.0 0.0.0.255
     permit 192.10.3.0 0.0.0.255

     

    I've classified the routes with an ACL and created two offset lists:

    1) inbound at fa0/1 to have routes coming from serial0/0/0 meet the feasible condition

    2) inbound at s0/0/0 to have the metric 4 times larger than fa0/1

    then I configured variance 4.

     

    I think that could do the trick since I didn't see any restriction on direct metric manipulation.

  • love it man.  great idea and much easier way to handle these tasks.  I would highly doubt they would prohibit this sort of a solution on an already difficult task.  great approach.

     

    Matt

  • Love the offset idea.

    I had metric 1 1 1 1 1. Then I noticed that the metrics were hideous, so I typed in some reasonable numbers for the redis command at R5. Then I spiked the delay on R4's FE link just so I could get it into the topology. Then a little trial and error to get the 4:1 ratio.

  • I hit the same problem by using "metric 1 1 1 1 1" when redistributing into EIGRP.

    I'd like the idea that soul mention, it is much much easier.

    Thanks for sharing

  • Hi soul

      I like u idea of doing Can u give more detail about how you got value of offset 1911297/5998340

     some more detail by doing some calculation from Start to end

    thank for a help in advance

    from

     khalid malik

  • The First obsticle is the split horizon.

    Second was the feasible distance.  
    On the feasible distance; the objective is just to get both routes to show up
    with no concern about the load balance ratio.  
    This was the major problem for me because of having to manipulate the
    redistribution on r5.    

    After manipulating the load and redistribution I ended up with
    the following two routs.   I also set a variance of 128 at first to be sure
    both routes showed up as being used.  

    Rack1R4#sh ip route 192.10.1.254
    Routing entry for 192.10.1.0/24
      Known via "eigrp 1024", distance 170, metric 1794560, type external
      Redistributing via eigrp 1024
      Last update from 174.1.145.1 on Serial0/0/0, 00:00:03 ago
      Routing Descriptor Blocks:
        174.1.145.1, from 174.1.145.1, 00:00:03 ago, via Serial0/0/0
          Route metric is 3196672, traffic share count is 9
                                -------
          Total delay is 60110 microseconds, minimum bandwidth is 1544 Kbit
          Reliability 253/255, minimum MTU 1500 bytes
          Loading 1/255, Hops 2
      * 174.1.45.5, from 174.1.45.5, 00:00:03 ago, via FastEthernet0/1
          Route metric is 1794560, traffic share count is 16
                                -------
          Total delay is 60100 microseconds, minimum bandwidth is 10000 Kbit
          Reliability 255/255, minimum MTU 1500 bytes
          Loading 1/255, Hops 1

    Rack1R4#

    This will not meet the requirements because the balance is 9 to 16 not 1 to 4.
    However the math is simpler from here.

    The next-hop of 174.1.45.5 has a metric of 1794560 so we know the metric
    for next hop 174.1.145.1 needs to be 4 times that value.

    So the target metric for routes out s0/0/0 must be (1794560 * 4) = 7178240

    The metric for routes out s0/0/0 is 3196672
    so we must add an offset to make it 7178240

    So the offset is ( 7178240 - 3196672) = 3981568

    So the objective is to apply offset 3981568 to all routes coming in (learned)
    on interface s0/0/0:

    Configuration on R4:
    ------------------------------------
      router eigrp 1024
      offset-list 0 in 3981568 s0/0/0
    ----------------------------------

    This applies an offset to all routes learned (in) on s0/0/0.  
    The access-list of 0 designates all routes because there is no need
    to specify individual prefixes since the offset needs to be applied to all.
    If you do the grueling EIGRP math and change the load it would apply
    to all routes learned from s0/0/0 anyway.  

    The result follows:

    Rack1R4#sh ip route 192.10.1.254
    Routing entry for 192.10.1.0/24
      Known via "eigrp 1024", distance 170, metric 1794560, type external
      Redistributing via eigrp 1024
      Last update from 174.1.145.1 on Serial0/0/0, 00:00:04 ago
      Routing Descriptor Blocks:
        174.1.145.1, from 174.1.145.1, 00:00:04 ago, via Serial0/0/0
          Route metric is 7178240, traffic share count is 1
                                 -------                                ---
          Total delay is 215640 microseconds, minimum bandwidth is 1544 Kbit
          Reliability 255/255, minimum MTU 1500 bytes
          Loading 1/255, Hops 2
      * 174.1.45.5, from 174.1.45.5, 00:00:04 ago, via FastEthernet0/1
          Route metric is 1794560, traffic share count is 4
                               -------                                   ---
          Total delay is 60100 microseconds, minimum bandwidth is 10000 Kbit
          Reliability 255/255, minimum MTU 1500 bytes
          Loading 1/255, Hops 1

    Rack1R4#

    So the only math is to multiply the f0/1 metric by 4 and subtract the s0/0/0
    metric to get the offset.   
    Then apply the offset ---  "offset-list 0 in 3981568 s0/0/0"
    This is simple enough for me to get through on an exam.

    With this the only difficulty is getting both routes in the routing table
    with routes out s0/0/0 having some metric less than 4 times the metric for f0/1.  
    To be safe I manipulated the load so I started with the metric for routes
    out s0/0/0 to be a bit higher (worse) than routes out f0/1.


    If this task had said that offset-list was not allowed I would still be
    doing the math.

    Kind Regards
    rbw

  • I'm facing the same problem. I didn't know IOS is not able to handle big metric numbers, my variance command was not doing anything while matching the successor condition.

    It was even doing strange things

    IP-EIGRP (AS 1024): Topology entry for 222.22.2.0/24

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

      Routing Descriptor Blocks:

      174.5.145.1 (Serial0/0/0), from 174.5.145.1, Send flag is 0x0

          Composite metric is (2560000768/2560000512), Route is External

          Vector metric:

            Minimum bandwidth is 1 Kbit

            Total delay is 30 microseconds

            Reliability is 1/255

            Load is 1/255

            Minimum MTU is 1

            Hop count is 2

          External data:

            Originating router is 150.5.5.5  

            AS number of route is 0

            External protocol is RIP, external metric is 7

            Administrator tag is 0 (0x00000000)

      174.5.45.5 (FastEthernet0/1), from 174.5.45.5, Send flag is 0x0

          Composite metric is (2560002816/2560000256), Route is External

          Vector metric:

            Minimum bandwidth is 1 Kbit

            Total delay is 110 microseconds

            Reliability is 1/255

            Load is 1/255

            Minimum MTU is 1

            Hop count is 1

          External data:

            Originating router is 150.5.5.5  

            AS number of route is 0

            External protocol is RIP, external metric is 7

            Administrator tag is 0 (0x00000000)

    Rack5R4# sh ip route eigrp

    D EX 222.22.2.0/24 [170/2560000768] via 174.5.145.1, 00:00:18, Serial0/0/0

    D EX 220.20.3.0/24 [170/2560000768] via 174.5.145.1, 00:00:18, Serial0/0/0 

     

    No load balance and variance is set to 128

  • Ok, I got it working.

    I went ahead and changed the k-values so that bandwidth is being discarded.

    On R4, R5, R1, and R3 I issued "metric weights 0 0 0 1 0 0".  This will make the calculation much easier.

    The KEY to getting this to work properly is to make sure you satisfy the feasibilty condition!!

    Thus with respect to R4, you need the AD learned from R1 to be lower than the FD (which is thru the FastEthernet Link).

    Here are the values I set:

    LINK VIA ETHERNET LAN (total delay = 60 microsecs)

    R4 FA0/1 delay = 5 (50 microsecs)

    +

    R5 Redistribution delay = 1 (10 microsecs)

     

    LINK VIA FRAME-RELAY (total delay = 240 microsecs)

    R4 S0/0/0 delay = 22 (220 microsecs)

    +

    R1 S0/0 delay = 1 (10 microsecs)

    +

    R5 Redistribution delay = 1 (10 microsecs)

    This will give you a ratio of 60:240 = 1:4 (I chose the value of 60 arbitrarily and worked backwards from there).

    Remeber again the key is the feasibility condition.  The delay on R1's S0/0 MUST be low, otherwise it will make the Advertised distance that R4 learns from R1 higher than the Feasible Distance from the Ethernet LAN and EIGRP will not be able to install the alternate route no matter what the variance is set to.

    Recall the the first step in EIGRP for a route to become a backup route is that it must meet the feasibility condition.  The next step would be to check the variance.

     

    Hope this helps.

     

     

    A huge thank you friend. This is a fantastic explanation. The simple number breakdown really helps. I needed to see this simplified.

    Thank you again

  • Hi,

    OMG, I spent two f...g hours trying to find out why it didn't work...

    I hate EIGRP... :) but ok, I forgot the story of the max metric.

    Anyway, my doubt is now... during the exam, what is the best practice ???? using metric 1 1 1 1 1 or is it better to use at least a value like 1544 or 10000 for BW ?

    I would like to know what is you advice.

     

    Thanks ;)

    Olivier

  • After this issue I've NEVER again using the composed metric 1 1 1 1 1

    10000 10000 255 1 1500 is what I use

  • hehe... this is the kind of answer I like :)

    Thanks for your input, I'm gonna follow the same rule !

    ;-)

  • On r5/r1 make s0/0/0 delay = 1 (remove unnecessary calcs)

    R4:
    sh ip route 220.20.3.0

    Take a look at a route learnt from BB2 (as per task)

    R4#sh ip ei top 220.20.3.0
    EIGRP-IPv4 Topology Entry for AS(1024)/ID(150.1.4.4) for 220.20.3.0/24
      State is Passive, Query origin flag is 1, 1 Successor(s), FD is 5120
      Descriptor Blocks:
      174.1.45.5 (FastEthernet0/1), from 174.1.45.5, Send flag is 0x0
          Composite metric is (5120/2560), route is External
          Vector metric:
            Minimum bandwidth is 10000 Kbit
            Total delay is 200 microseconds
            Reliability is 255/255
            Load is 1/255
            Minimum MTU is 1500
            Hop count is 1
            Originating router is 150.1.5.5
          External data:
            AS number of route is 0
            External protocol is RIP, external metric is 7
            Administrator tag is 0 (0x00000000)
      174.1.145.1 (Serial0/0/0), from 174.1.145.1, Send flag is 0x0
          Composite metric is (514816/2816), route is External
          Vector metric:
            Minimum bandwidth is 1544 Kbit
            Total delay is 20110 microseconds
            Reliability is 255/255
            Load is 1/255
            Minimum MTU is 1500
            Hop count is 2
            Originating router is 150.1.5.5
          External data:
            AS number of route is 0
            External protocol is RIP, external metric is 7
            Administrator tag is 0 (0x00000000)

    router ei 1024
    metric weights 0 0 0 1 0 0  (only look at delay)
    variance 4 (we want 4:1)

    int f0/1
    delay 500

    clear ei neigbours and take another look at same route

    R4#sh ip ei top 220.20.3.0
    EIGRP-IPv4 Topology Entry for AS(1024)/ID(150.1.4.4) for 220.20.3.0/24
      State is Passive, Query origin flag is 1, 2 Successor(s), FD is 130560
      Descriptor Blocks:
      174.1.45.5 (FastEthernet0/1), from 174.1.45.5, Send flag is 0x0
          Composite metric is (130560/2560), route is External
          Vector metric:
            Minimum bandwidth is 10000 Kbit
            Total delay is 5100 microseconds
            Reliability is 255/255
            Load is 1/255
            Minimum MTU is 1500
            Hop count is 1
            Originating router is 150.1.5.5
          External data:
            AS number of route is 0
            External protocol is RIP, external metric is 7
            Administrator tag is 0 (0x00000000)
      174.1.145.1 (Serial0/0/0), from 174.1.145.1, Send flag is 0x0
          Composite metric is (514816/2816), route is External
          Vector metric:
            Minimum bandwidth is 1544 Kbit
            Total delay is 20110 microseconds
            Reliability is 255/255
            Load is 1/255
            Minimum MTU is 1500
            Hop count is 2
            Originating router is 150.1.5.5
          External data:
            AS number of route is 0
            External protocol is RIP, external metric is 7
            Administrator tag is 0 (0x00000000)

    Now check RIB

    R4#sh ip route 220.20.3.0
    Routing entry for 220.20.3.0/24
      Known via "eigrp 1024", distance 170, metric 130560, type external
      Redistributing via eigrp 1024
      Last update from 174.1.145.1 on Serial0/0/0, 00:03:42 ago
      Routing Descriptor Blocks:
        174.1.145.1, from 174.1.145.1, 00:03:42 ago, via Serial0/0/0
          Route metric is 514816, traffic share count is 61
          Total delay is 20110 microseconds, minimum bandwidth is 1544 Kbit
          Reliability 255/255, minimum MTU 1500 bytes
          Loading 1/255, Hops 2
      * 174.1.45.5, from 174.1.45.5, 00:03:42 ago, via FastEthernet0/1
          Route metric is 130560, traffic share count is 240
          Total delay is 5100 microseconds, minimum bandwidth is 10000 Kbit
          Reliability 255/255, minimum MTU 1500 bytes
          Loading 1/255, Hops 1

    240:61 = 4:1

    I hope this would also be acceptable (the SG is a bit more complex).

Sign In or Register to comment.