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
Received on Mon Sep 27 2010 - 11:22:22 ART