Re: EIGRP Traffic Share Count

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 - 09:12:18 ART