2.1 EIGRP Load Distribution ... Going Crazy !!!

Hi,

I was trying to do the math for finding proper DELAY to apply to apply for the connection to R3 for a 5:1 ratio as asked in the WBook.

In the SG it's done the other way around, finding the delay to apply on the conn to R2, but I don't think this is a problem.

So, I really don't know where the problem is, PLEASE HELP :

5 * M1 = M2 <=> 5 * ( 107/1280 + X ) = 107/256 + 2010 <=> 107/256 + 5X = 107/256 +2010 <=> 5X = 2010 <=> X = 402 tens of usec

So 402 - 10 (100 usec is R2's local delay to 163.X.26.0/24 network) = 392 tens of usec.

When applying this to serial 0/1 on R1 , guess what ... a ratio of 4:1 is obtained :

Rack3R1#sh run int s 0/1     
Building configuration...

Current configuration : 110 bytes
!
interface Serial0/1
 bandwidth 1536
 ip address 164.3.13.1 255.255.255.0
 encapsulation ppp
 delay 392
end

Rack3R1#sh ip route 164.3.26.0
Routing entry for 164.3.26.0/24
  Known via "eigrp 100", distance 90, metric 2614784, type internal
  Redistributing via eigrp 100
  Last update from 164.3.12.2 on Serial0/0, 00:17:38 ago
  Routing Descriptor Blocks:
  * 164.3.13.3, from 164.3.13.3, 00:17:38 ago, via Serial0/1
      Route metric is 2614784, traffic share count is 4
      Total delay is 24020 microseconds, minimum bandwidth is 1280 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2
    164.3.12.2, from 164.3.12.2, 00:17:38 ago, via Serial0/0
      Route metric is 10514432, traffic share count is 1
      Total delay is 20100 microseconds, minimum bandwidth is 256 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

When doing the math the opposite way, everything is fine :

5 * M1 = M2 <=> 5 * ( 107/1280 +4010 ) = 107/256 + X => X = 20050 tens of usec

 

How is this possible, where am I getting this WRONG ?

 

Thank you guys,

Ciprian.

 

Comments

  • No one ? At least a guess maybe ?

    Thanks,

    Ciprian.

  • JoeMJoeM ✭✭✭

    If you have 4 to 1 ,    it is clear that you need to lower your delay even more going to R3.  

    I just finished redoing that task, and the workbook only adjusted bandwidth (according to circuits).  However, when I adjusted the bandwidth correctly, it was still necessary to adjust the delay.   

    SG wrong?   or my lab wrong?       What I do know, is that it is not correct until we see 5 to 1.

     

    note: My final delay on R1->R3 was (delay 400), but I also dropped the delay on R3's connection to R2  (delay 1).

     

  • Hi Ciprian,

     

    Your reverse calculation is correct but the way you applied the value is incorrect. As you are applying the delay only on R1's s0/1, it defines the delay between R1 & R3 but the value of delay between R3 & R2 remains same which would also be added to the configured delay. Recall that cumulative delay is referenced when calculating metric. So, it gives you incorrect result here. 

     

    So, the better way is to devide the value into two part, i.e. 292+100=392 & then apply it into S0/1 of R1 & s1/1.23 of R3 which would make 292+100+10=402. It would work but I think we should increase the delay by at least one(Not hundred percent sure) to make it feasible for traffic sharing in the desired way. So, just add the delay by one in any of the interfaces, it will work fine. 

     

    Here is the example: (values are different but I hope you will understand) [:P]

     

    R1#sh run inter s0/1

    Building configuration...

    Current configuration : 114 bytes

    !

    interface Serial0/1

     bandwidth 1536

     ip address 10.1.23.3 255.255.255.0

     delay 201

     serial restart-delay 0

    end

     

     

    R3#sh run inter s0/0.21

    Building configuration...

    Current configuration : 143 bytes

    !

    interface Serial0/0.21 point-to-point

     bandwidth 1280

     ip address 10.1.12.2 255.255.255.0

     delay 120

     frame-relay interface-dlci 201

    end

     

     

    R2#sh ip ei topology 164.1.26.0 255.255.255.0

    IP-EIGRP (AS 100): Topology entry for 164.1.26.0/24

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

      Routing Descriptor Blocks:

      0.0.0.0 (Ethernet1/0), from Connected, Send flag is 0x0

          Composite metric is (281600/0), Route is Internal

          Vector metric:

            Minimum bandwidth is 10000 Kbit

            Total delay is 1000 microseconds

     

    Total delay would be 421 in my scenario.

     

    R1#sh ip route 164.1.26.0 255.255.255.0

    Routing entry for 164.1.26.0/24

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

      Redistributing via eigrp 100

      Last update from 10.1.13.1 on Serial0/0.31, 00:28:59 ago

      Routing Descriptor Blocks:

      * 10.1.23.2, from 10.1.23.2, 00:28:59 ago, via Serial0/1

          Route metric is 2107648, traffic share count is 5

          Total delay is 4210 microseconds, minimum bandwidth is 1280 Kbit

          Reliability 255/255, minimum MTU 1500 bytes

          Loading 1/255, Hops 2

        10.1.13.1, from 10.1.13.1, 00:28:59 ago, via Serial0/0.31

          Route metric is 10537472, traffic share count is 1

          Total delay is 21000 microseconds, minimum bandwidth is 256 Kbit

          Reliability 255/255, minimum MTU 1500 bytes

          Loading 1/255, Hops 1

     

    Hope this helps!

     

  • Hi Hari,

    Thank you for taking time to provide me an answer to my question.

    Well, NOW I get it, which is the most important fact when studying [:D].

    So, I will explain it with my words : [:D]

    Their calculation is correct (as in SG) BECAUSE there is a direct link between R1 and R2, and by modifying the delay on R1's serial0/0, it will modify the whole delay along the path, adding the connected delay that R2 reports in for the total DELAY to reach the path.

    So now, my calculations were correct, 392 tens of usec were to be configured for the path R1-R3-R2 but as a whole, not only on the connection between R1 and R3, as in this case the total delay would be :

    392 + delay between R3 and R2 + 10 connected delay R2 reports in.

    Thanks so much Hari,

    Ciprian.

Sign In or Register to comment.