Re: EIGRP Traffic Share Count

Thanks Paul, atleast it cleared few doubts. Anyways, it might be a stupid
question, but how did you manage to arrive at metrics with only bandwidth
value. I tried to plugged in bandwidth value of 100 , but unable to get the
metric of 6530560.

Can you please shed some light on metric calculation.

EIGRP Metric = 256*((10^7 / min. Bw) + Delay)

Regards,

Bilal

On Mon, Sep 27, 2010 at 3:42 PM, Paul Negron <negron.paul_at_gmail.com> wrote:

> I'm still trying to figure that one out too. I'm afraid I will run into the
> dreaded Cisco EIGRP SECRET wall. When I know you'll know. Unless someone
> steps up and fills in the blank.
>
> It really doesn't seem to matter though except for the number of packets
> being sent per link. The load sharing is very consistent.
> --
> Paul Negron
> CCIE# 14856 CCSI# 22752
> Senior Technical Instructor
> www.micronicstraining.com
>
>
>
> > From: Garth Bryden <hacked.the.planet.on.28.8k.dialup_at_gmail.com>
> > Date: Mon, 27 Sep 2010 12:13:24 +0800
> > To: Paul Negron <negron.paul_at_gmail.com>
> > Cc: Bilal Hansrod <bilal.hansrod_at_gmail.com>, Cisco certification
> > <ccielab_at_groupstudy.com>
> > Subject: Re: EIGRP Traffic Share Count
> >
> > Hi Paul,
> >
> > Thanks I am still a little confused about how we managed to get the value
> of
> > 61 from the metrics?
> >
> > Sent from my iPad
> >
> > On 27/09/2010, at 11:02 AM, Paul Negron <negron.paul_at_gmail.com> wrote:
> >
> >> Fellas,
> >>
> >> First of all. Make sure you change the delay for the interface to be 10
> if
> >> you are using dynamips. Yes, it is off.
> >>
> >> If you were to take 4 paths with the following bandwidths:
> >>
> >> 1 = 100K
> >> 2 = 200K
> >> 3 = 300K
> >> 4 = 400K (This being the best path)
> >>
> >> After configuring a variance of 4:
> >>
> >> The following metrics would be used:
> >>
> >> 1 = 6530560 traffic-count = 240
> >> 2 = 8663808 traffic-count = 181
> >> 3 = 12930560 traffic-count = 121
> >> 4 = 25730560 traffic-count = 61
> >>
> >>
> >> What Garth said takes over from here:
> >>
> >> Largest metric (25730560) divided by path 1 metric (6530560) =
> 3.94002352
> >> Therefore the traffic-share of path 4 (61) * 3.94002352 = 240.341
> >> rounded down to the nearest integer is 240.
> >>
> >> Largest metric (25730560) / path 2 metric (8663808) = 2.969890376
> >> Therefore the traffic-share of path 4 (61) * 2.969890376 = 181.16
> >> rounded down to the nearest integer is 181.
> >>
> >> Largest metric (25730560) / path 3 metric (12930560) = 2.969890376
> >> Therefore the traffic-share of path 4 (61) * 1.98990299 = 121.38
> rounded
> >> down to the nearest integer is 121.
> >>
> >> Largest metric (25730560) / path 4 metric (25730560) = 1
> >> Therefore the traffic-share of path 4 (61) * 1 = 61 rounded down to
> the
> >> nearest integer is 61.
> >>
> >> Sure enough, I tested this by turning off CEF and I observed 240 packets
> >> down PATH 4 , 121 packets down path 3 and so fourth.
> >>
> >> This is how it works Gentlemen.
> >>
> >> Paul
> >> --
> >> 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,
> >>>>>> R6 s 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 R6 s
> >>>>>> Feasible Distance. Secondly the entire composite result R6
> calculates
> >>>>>> through
> >>>>>> R1 should be five times the Feasible Distance.
> >>>>>> In our case R1 s 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 R6 s 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 Mon Sep 27 2010 - 15:51:33 ART