Re: EIGRP Traffic Share Count

From: Paul Negron <negron.paul_at_gmail.com>
Date: Sun, 26 Sep 2010 22:08:40 -0500

OOPS. I meant. 240 down path 4, 181 down path 3, 121 down path 2, and 61
down path 1.

-- 
Paul Negron
CCIE# 14856 CCSI# 22752
Senior Technical Instructor
www.micronicstraining.com
> From: Bilal Hansrod <bilal.hansrod_at_gmail.com>
> Reply-To: Bilal Hansrod <bilal.hansrod_at_gmail.com>
> Date: Mon, 27 Sep 2010 11:22:22 +1000
> To: Garth Bryden <hacked.the.planet.on.28.8k.dialup_at_gmail.com>
> Cc: Cisco certification <ccielab_at_groupstudy.com>
> Subject: Re: EIGRP Traffic Share Count
> 
> Sorry Garth, I didn't mean to confuse you, but waiting for big boys to come
> up with logical explanation when they have time :-)
> 
> Regards,
> 
> Bilal H
> 
> 
> 
> 
> On Mon, Sep 27, 2010 at 11:12 AM, Garth Bryden <
> hacked.the.planet.on.28.8k.dialup_at_gmail.com> wrote:
> 
>> Would be nice to find out why such the large values, I believe it is so it
>> can get the share ratio as accurate as possible while using whole numbers,
>> because the actual ratio is so close.
>> 
>> Though, I always believed the traffic share count would always start at 1
>> then the rest of the paths increased based on the ratio.. if the numbers
>> where not whole numbers then it'd be rounded down to the whole number.. but
>> based on that logic your traffic share count 1:1 not 103:120
>> 
>> Though after googling to try find some information on it, I've come back
>> with nothing and more confused than before!! There is a cisco press book
>> "Traffic Engineering with MPLS" which is saying non-whole numbers are
>> rounded UP to the nearest integer not rounded DOWN though all the Cisco
>> Documentation says it is rounded down. :-/
>> 
>> On Mon, Sep 27, 2010 at 8:44 AM, Bilal Hansrod
> <bilal.hansrod_at_gmail.com>wrote:
>> 
>>> Hello again,
>>> 
>>> Garth has provided a valuable resource to calculate Traffic Share and
>>> detail about load sharing. Can anyone else, please provide more
>>> understanding on how to calculate share based on examples as I am having
>>> difficulty understanding nuts and bolts of Traffic Share Count.
>>> 
>>> Thanks everyone -
>>> 
>>> Regards,
>>> Bilal
>>> 
>>>   On Sun, Sep 26, 2010 at 11:42 PM, Bilal Hansrod <
>>> bilal.hansrod_at_gmail.com> wrote:
>>> 
>>>> Thanks Garth, but still I am trying to understand Traffic Share Count
>>>> value arrived via calculation. How did you get 120 via 155.1.67.7 and 103
>>>> via 155.1.146.1 (please see below output from show ip route 155.1.9.9).
>>>> There is a lab in INE W1 and it asks to change the traffic share to 1:5
> and
>>>> uses the formula:
>>>> 
>>>> INE Task 5.15 EIGRP Unequal Cost Load Balancing
>>>> 
>>>> "These paths are now balanced 103:120. To achieve the desired 1:5 traffic
>>>> share,
>>>> R6s delay on the link to R1 must be updated. The actual values used on
>>>> R1,
>>>> R3, and R6 for delay can have multiple valid options as long as two
>>>> conditions
>>>> are true. First, the Advertised Distance R1 sends to R6 must be lower
>>>> than R6s
>>>> Feasible Distance. Secondly the entire composite result R6 calculates
>>>> through
>>>> R1 should be five times the Feasible Distance.
>>>> In our case R1s Advertised Distance is 40 microseconds, or 4 tens of
>>>> microseconds. This specifically means the following must be true if we
>>>> want a
>>>> traffic share of 1:5.
>>>> 3072 * 5 = (R6_TO_R1_DLY + 4) * 256
>>>> Therefore R6s delay to R1 should be 56 tens of microseconds."
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Sun, Sep 26, 2010 at 10:29 PM, Garth Bryden <
>>>> hacked.the.planet.on.28.8k.dialup_at_gmail.com> wrote:
>>>> 
>>>>> Hi Bilal,
>>>>> 
>>>>> You want to read this post-
>>>>> 
> http://blog.ine.com/2009/05/01/understanding-unequal-cost-load-balancing/..
>>>>> This has an explanation on the traffic share ratio you are seeing above.
>>>>> 
>>>>> I think the answer you seek though is
>>>>> 
>>>>> EIGRP will divide each links metric by the largest paths metric..
>>>>> 
>>>>> 3584 / 3072 which is 1.166
>>>>> 3584 / 3584 which is 1
>>>>> 
>>>>> FYI- 120 / 103 = 1.165
>>>>> 
>>>>> EIGRP will round down to the nearest integer so the first path is
>>>>> actually "1"
>>>>> 
>>>>> I also believe the largest metric would have be a path being selected by
>>>>> EIGRP for placement into the routing table.. If your route is not
> selected
>>>>> because the metric is larger than the
>>>>>  Variance x feasible distance.. I do not believe it will be included in
>>>>> the route traffic share calculation.
>>>>> 
>>>>> HTH
>>>>> 
>>>>> Garth
>>>>> 
>>>>> 
>>>>> 
>>>>>  On Sun, Sep 26, 2010 at 6:14 PM, Bilal Hansrod <
>>>>> bilal.hansrod_at_gmail.com> wrote:
>>>>> 
>>>>>>  Hello Everyone,
>>>>>> 
>>>>>> I am having difficulty calculating the EIGRP Traffic Share Count. As
>>>>>> far as
>>>>>> my understanding regarding Traffic Share Count is, you divide the
>>>>>> largest
>>>>>> metric with lowest to forward packets based on number. For example
>>>>>> 
>>>>>> A-X = Metric is 10
>>>>>> B-X = Metric is 20
>>>>>> C-X = Metric is 30
>>>>>> D-X = Metric is 40
>>>>>> E-X = Metric is 90
>>>>>> 
>>>>>> If I configure variance 4, it means all above metric will be used for
>>>>>> load
>>>>>> balancing except E-X (90), because it does not fall under 80 (Lowest
>>>>>> Metric
>>>>>> X 4). So when calculate, I still use E-X Metric for Traffic Share
>>>>>> Count.
>>>>>> 
>>>>>> 
>>>>>> A-X = Metric is 10 = Traffic Share Count (90/10)   = 9
>>>>>> B-X = Metric is 20 = Traffic Share Count (90/20)   = 5
>>>>>> C-X = Metric is 30 = Traffic Share Count (90/30)   = 3
>>>>>> D-X = Metric is 40 = Traffic Share Count (90/40)   = 2
>>>>>> 
>>>>>> It means 9 packets will be sent via A-X, 5 packets via B-X, 3 packets
>>>>>> via
>>>>>> C-X, and 2 packets via D-X and round robin. Am I correct till here??
>>>>>> 
>>>>>> Now, when I have below output, how is Traffic Share Count calculated
>>>>>> 
>>>>>> 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
>>>>>> 
>>>>>> 
>>>>>> Anyone's help will be highly appreciated,
>>>>>> 
>>>>>> Regards,
>>>>>> 
>>>>>> Bilal
>>>>>> 
>>>>>> 
>>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>> 
>>>>>> _______________________________________________________________________
>>>>>> Subscription information may be found at:
>>>>>> http://www.groupstudy.com/list/CCIELab.html
> 
> 
> Blogs and organic groups at http://www.ccie.net
> 
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
Received on Sun Sep 26 2010 - 22:08:40 ART

This archive was generated by hypermail 2.2.0 : Fri Oct 01 2010 - 05:58:06 ART