Re: EIGRP Traffic Share Count

> Hey Tyson!
>
> I have read your blog, it is fantastic, all you vendors have made my life
> so much easier with your postings :-)
>
> I should have phrased my question earlier a bit better I believe, I went
> running yesterday so I was very tired this morning when I posted that!
>
> I know how to calculate the metrics for EIGRP so that I can achieve the
> traffic share ratio's that is no problems what I am getting a bit confused
> about how the router calculates the traffic share (I may have missed
> something obvious here! Pardon me if I did). The main reason because of this
> is I always learnt is that the router will calculate the traffic share by
> dividing all of the metrics for the route by the largest metric that is
> going to be used as part of the load balancing algorithm and then it'll
> round the result down to the nearest integer.
>
> This is what is actually says in Cisco's EIGRP whitepaper -
> http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094cb7.shtml#loadbalancing though
> I know they aren't always 100% accurate in the documentation.
>
> This seems true enough to me, I'll take one of the examples from your blog
> where you had R6 load balancing over three links at a ratio of 8:4:1..
>
> R6#show ip route 200.0.0.2
> Routing entry for 200.0.0.2/32
> Known via "eigrp 1001", distance 90, metric 158720, type internal
> Redistributing via eigrp 1001, eigrp 6009
> Advertised by eigrp 6009
> Last update from 150.100.100.2 on Serial0/1/0, 00:00:01 ago
> Routing Descriptor Blocks:
> 150.100.221.5, from 150.100.221.5, 00:00:01 ago, via FastEthernet0/1
> Route metric is 317184, traffic share count is 4
> Total delay is 5200 microseconds, minimum bandwidth is 13908 Kbit
> Reliability 255/255, minimum MTU 1500 bytes
> Loading 1/255, Hops 2
> * 150.100.220.5, from 150.100.220.5, 00:00:01 ago, via FastEthernet0/0
> Route metric is 158720, traffic share count is 8
> Total delay is 5200 microseconds, minimum bandwidth is 100000 Kbit
> Reliability 255/255, minimum MTU 1500 bytes
> Loading 1/255, Hops 2
> 150.100.100.2, from 150.100.100.2, 00:00:01 ago, via Serial0/1/0
> Route metric is 1269760, traffic share count is 1
> Total delay is 25000 microseconds, minimum bandwidth is 4065 Kbit
> Reliability 255/255, minimum MTU 1500 bytes
> Loading 1/255, Hops 1
>
>
> Okay, so performing the Math as per the Cisco White Paper we have
>
> 1269760 / 158720 = 8
> 1269760 / 317184 = 4.00322841
> 1269760 / 1269760 = 1
>
> Great, the second path will be rounded down to four and we achieved the
> traffic share ratio's as you noted in your blog. The world was happy!
>
> Then Bilal pointed out the traffic share ratio's that we saw in their
> workbooks EIGRP topology which was demonstrating unequal cost load balancing
> and all of a sudden our traffic share count is now at a ratio of 103:120 as
> per the below
>
> Rack1R6#show ip route 155.1.9.9
> Routing entry for 155.1.9.0/24
> Known via "eigrp 100", distance 90, metric 3072, type internal
> Redistributing via eigrp 10, eigrp 100
> Advertised by eigrp 10
> Last update from 155.1.146.1 on FastEthernet0/0.146, 00:01:04 ago
> Routing Descriptor Blocks:
> 155.1.146.1, from 155.1.146.1, 00:01:04 ago, via FastEthernet0/0.146
> Route metric is 3584, traffic share count is 103
> Total delay is 140 microseconds, minimum bandwidth is 1544 Kbit
> Reliability 255/255, minimum MTU 1500 bytes
> Loading 1/255, Hops 4
>
> * 155.1.67.7, from 155.1.67.7, 00:01:04 ago, via FastEthernet0/0.67
> Route metric is 3072, traffic share count is 120
> Total delay is 120 microseconds, minimum bandwidth is 100000 Kbit
> Reliability 255/255, minimum MTU 1500 bytes
> Loading 1/255, Hops 2
>
> In the above calculation only the value of delay was used as we know and as
> you have pointed out it seems that the formula for working out the traffic
> share has changed.. If it used the same formula as shown in the EIGRP white
> paper the traffic share would be
>
> 3584 / 3072 = 1.16666
> 3584 / 3584 = 1
>
> These would both be rounded down and the traffic share ratio would be
> 1:1....... obviously it wouldn't be perfect because the paths aren't
> actually equal but the formula still made sense which is why I am assuming
> Cisco Engineering decided to change the calculation when only delay has been
> considered to the calculation you pointed out before-
>
> 120 / 140 * 120 = 102.85
> 120 / 120 * 120 = 120
>
> I guess what I am wondering now is the following
>
> Is there a long methematical algorithm at work here then which is doing the
> calculation?
> Is it part of the EIGRP sub process performing the traffic share
> calculation or the actual routing process.. at the moment I'm assuming it
> must be EIGRP because how would the routing process know we are only
> considering delay as the value for metric calculation?
> I'm also wondering why Cisco have done this and why they have not
> documented it!
> Does it mean the algorithm for traffic share will change again if we have
> any of the other K values set to 1?
>
> Though I am not majorly worried about my questions come exam time again,
> it's really interesting to understand how things are being done behind the
> scene's in IOS! :-)
>
> Cheers
>
> Garth

Blogs and organic groups at http://www.ccie.net
Received on Wed Sep 29 2010 - 21:04:34 ART