Re: EIGRP Traffic Share Count

Not at all!! It is always good to find out if your understanding of
something is wrong rather than unknowingly have an incorrect understanding
:-P

On Mon, Sep 27, 2010 at 9:22 AM, Bilal Hansrod
<bilal.hansrod_at_gmail.com>wrote:

> 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
>>>>>>
>>>>>>
>>>>>>
Received on Mon Sep 27 2010 - 09:24:19 ART