From: Kenneth Wygand (KWygand@customonline.com)
Date: Thu Jul 08 2004 - 14:05:59 GMT-3
Tim,
I too believe this problem is rooted in route-caching. Traffic sourced from R2 to R3 might not be route-cached, while traffic passing through R2 is. Try running a "no ip route-cache" on R2's interface that connects to R1.
Good luck!
Ken
--------------------------
Sent from my BlackBerry Wireless Handheld
-----Original Message-----
From: nobody@groupstudy.com <nobody@groupstudy.com>
To: R. Adjakou <radjakou@cfao.sn>; 'Jensen, Brian D.' <bdjensen@eschelon.com>; 'Tim Fletcher' <groupstudy@fletchmail.net>; 'Sergio Jimenez Arguedas' <sejimenez@its.co.cr>; ccielab@groupstudy.com <ccielab@groupstudy.com>
Sent: Thu Jul 08 12:52:26 2004
Subject: Re: Eigrp unequal load balancing problem
That's a very interesting idea. I never thought of that either.
But... what will be the metric of the subnet between R2 and R1 after it's
redist and sent to R3?
Now, I have another question. Once we eventually succeed in getting R3 to
unequal load-balance traffic going to R1, what load-balancing will take
place on traffic going in the other direction, from R1 to R3?
Will R2 unequal load-balance traffic from R1 going to R3 in the same ratio,
2:1?
Tim
----- Original Message -----
From: "R. Adjakou" <radjakou@cfao.sn>
To: "'ccie2be'" <ccie2be@nyc.rr.com>; "'Jensen, Brian D.'"
<bdjensen@eschelon.com>; "'Tim Fletcher'" <groupstudy@fletchmail.net>;
"'Sergio Jimenez Arguedas'" <sejimenez@its.co.cr>; <ccielab@groupstudy.com>
Sent: Thursday, July 08, 2004 12:16 PM
Subject: RE: Eigrp unequal load balancing problem
> Perhaps there is another solution.
> Run eigrp in 2 AS. The first AS between R1 and R2 and the second one
> between R2 and R3.
> Do mutual redistribution.
>
> Cordialement/Best regards;
>
> -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
> Roberto Adjakou
> E-mail : RAdjakou@cfao.sn
> -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
>
>
> -----Message d'origine-----
> De : nobody@groupstudy.com [mailto:nobody@groupstudy.com] De la part de
> ccie2be
> Envoyi : jeudi 8 juillet 2004 14:05
> @ : Jensen, Brian D.; 'Tim Fletcher'; Sergio Jimenez Arguedas;
> ccielab@groupstudy.com
> Objet : Re: Eigrp unequal load balancing problem
>
> Hi Brian,
>
> I want to thank you for taking the time to try all these variations. I
> think this experiment was vary valuable even if we never found the
> ultimate
> solution because no doubt I think we all learned a bit more about the
> way
> Eigrp computes it's metric and some new ways to consider manipulating
> those
> metrics.
>
> At this point, I believe there are two potential solutions:
>
> 1) Adjust the K values such that bandwidth isn't considered and make the
> delay very low on R2's interface (the one facing R1) so that the
> following
> is true. Assume d1 = the delay on the 64k link, d2 = delay on 2mb link
> and
> d3 = delay on 1mb link
>
> d1 + d2
> -------- = approx 2
> d1 + d3
>
>
> In other words, if d1 is so low that d1 + d2 = approx d2 and d1 + d3 =
> approx d3 then d2/d3 will = approx 2 so unequal load balancing
> will work as desired.
>
>
> 2) Leave the default K values, but set the bandwidth of R2's interface
> (facing R1) to over 2mb and make the delay very low. Now, R3 won't
> consider
> the 64k link in it's metric computation (since it's not the minimum b/w
> anymore).
>
> I wish I could try this myself to see what happens. But, all in all, I
> feel
> this was an excellent learning experience.
>
> Thanks to everyone who worked on this.
>
> Tim
> ----- Original Message -----
> From: "Jensen, Brian D." <bdjensen@eschelon.com>
> To: "'ccie2be'" <ccie2be@nyc.rr.com>; "Jensen, Brian D."
> <bdjensen@eschelon.com>; "'Tim Fletcher'" <groupstudy@fletchmail.net>;
> "Sergio Jimenez Arguedas" <sejimenez@its.co.cr>;
> <ccielab@groupstudy.com>
> Sent: Thursday, July 08, 2004 9:30 AM
> Subject: RE: Eigrp unequal load balancing problem
>
>
> > Hi ccie2be,
> >
> > You know, I've always read in texts how to load balance, and the steps
> > needed, even done it in production networks. Last night I was
> interested
> > enough to try it out *and measure it* to make sure it worked like it
> was
> > supposed to. Like I said, I was surprised. I tried many things last
> night,
> > such as changing the k values (put them all in, all k=1) added delay
> to
> the
> > lower bw link, changed the bw on the 64k link to 2mb, lots of stuff.
> (but
> > not all at the same time) The route tables changed like I would expect
> them
> > to, given the changes. But the actual traffic between R1 and R3 never
> did
> > load balance!! The code I was running was 12(2)14T, maybe its buggy,
> don't
> > know. But like I said, I was surprised. I think Tim was saying to make
> delay
> > more important that BW, one could do that by taking k1 and making it
> zero,
> > keeping k3 at 1. I think that might do it.
> >
> > Thanks,
> >
> > Brian
> >
> >
> > -----Original Message-----
> > From: ccie2be [mailto:ccie2be@nyc.rr.com]
> > Sent: Thursday, July 08, 2004 2:28 AM
> > To: Jensen, Brian D.; 'Tim Fletcher'; Sergio Jimenez Arguedas;
> > ccielab@groupstudy.com
> > Subject: Re: Eigrp unequal load balancing problem
> >
> >
> > Hi Brian,
> >
> > I'm glad you tried this. Now, you really understand what I'm talking
> about
> > and what the issue is.
> >
> > I understand the problem but I don't know what to do about it.
> >
> > Here's the problem:
> >
> > Eigrp, by default, uses 2 parameters in computing it's metric:
> cumulative
> > delay and minimum bandwidth (along the path).
> >
> > As you can see from your route table, from R3's point of view, the
> metric
> to
> > R1 is the same via either the 2mb link or the 1 mb link.
> >
> > That's because the minimum bandwidth along the path from R3 to R1 is
> 64k.
> >
> > Theoretically, the solution is to make R3 not consider the 64k link in
> it's
> > metric computation. But, I'm not sure of the best way to do that.
> >
> > One possible method might be to trick R3 into thinking that the 64k
> link
> is
> > 2mb. Then, the links between R3 and R2 will be the determining factor
> R3
> > uses when it does it's unequal load balancing.
> >
> > Another possibility according to Tim Fletcher is to change the k
> values
> such
> > that only delay is consider in the metric computation. As I recall,
> if
> the
> > k values are changed on one router in a eigrp domain, they better be
> changed
> > on all routers in that same domain. This sounds like a very
> reasonable
> > approach, but what should they be changed to?
> >
> >
> > ----- Original Message -----
> > From: "Jensen, Brian D." <bdjensen@eschelon.com>
> > To: "'Tim Fletcher'" <groupstudy@fletchmail.net>; "ccie2be"
> > <ccie2be@nyc.rr.com>; "Sergio Jimenez Arguedas" <sejimenez@its.co.cr>;
> > <ccielab@groupstudy.com>
> > Sent: Wednesday, July 07, 2004 11:52 PM
> > Subject: RE: Eigrp unequal load balancing problem
> >
> >
> > > Hi Tim,
> > >
> > > My curiosity was piqued, so I set this up in the lab:
> > >
> > > R1 Lo = 10.1.1.1
> > > R3 Lo = 10.3.3.3
> > > R2 Lo = 10.2.2.2
> > > Topology is same as original diagram, R1----R2===R3. Between R2 and
> R3,
> > > band on s0/0 is set to 2mb, and s0/1 is set to 1mb on both sides.
> > >
> > > Here are the routes from R3's perspective:
> > > D 10.2.2.0/24 [90/7519] via 10.100.1.1, 00:00:02, Serial0/0
> > > [90/12539] via 10.200.1.1, 00:00:02, Serial0/1
> > > D 10.1.1.0/24 [90/183771] via 10.200.1.1, 00:00:02, Serial0/1
> > > [90/183771] via 10.100.1.1, 00:00:02, Serial0/0
> > >
> > > Here are the routes from R2's perspective:
> > > D 10.1.1.0/24 [90/181771] via 10.11.0.1, 00:00:02, Serial1/1
> > > D 10.3.3.0/24 [90/7029] via 10.100.1.2, 00:00:02, Serial0/0
> > > [90/12049] via 10.200.1.2, 00:00:02, Serial0/1
> > >
> > >
> > > Its the strangest thing, I get load balancing between R2 and R3 in
> the
> > ratio
> > > of 2:1, but if the traffic goes from R1 to R3, then there is no load
> > > balancing. I have tried using the variance, and even "traffic bal"
> under
> > > eigrp on both sides, and the traffic still prefers the hi bw link,
> or
> > s0/0.
> > > These results are not what I expected to see. Now I too am asking,
> why
> is
> > > this so?
> > >
> > > Thanks,
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: nobody@groupstudy.com [SMTP:nobody@groupstudy.com] On Behalf
> Of
> > Tim
> > > > Fletcher
> > > > Sent: Wednesday, July 07, 2004 10:01 PM
> > > > To: ccie2be; Sergio Jimenez Arguedas; ccielab@groupstudy.com
> > > > Subject: Re: Eigrp unequal load balancing problem
> > > >
> > > > At 08:33 PM 7/6/2004, ccie2be wrote:
> > > > >OK, guys. You're not getting it, so I'll give you a hint.
> > > > >
> > > > >The problem is that from R3's point of view, the 2 paths to R1
> are
> > equal
> > > > >cost. This is because when Eigrp figures out the cost to a
> > destination,
> > > > it
> > > > >using the lowest bandwidth link anywhere along the path to the
> > > > destination.
> > > > >Since the path to R1's lo0 includes a single 64k link between R2
> and
> > R1,
> > > > >from R3's point of view both paths to R1 are equal.
> > > >
> > > > That's not entirely true. EIGRP does use the lowest bandwidth link
> in
> > the
> > > > path, but it also uses the cumulative delay. So you will see a
> larger
> > > > difference in the metrics to reach R2 than the metrics to reach
> R1.
> > > >
> > > > From R3's perspective, the two paths to R2 are going to have
> different
> > > > bandwidth and delay values, but the two paths to R1 are only going
> to
> > have
> > > > a difference in the delay value. The difference will also be
> smaller
> > > > because both paths will include the 64K link which will have a
> higher
> > > > delay than either of the other links. So you should see a
> difference
> in
> > > > the metrics to R1, but it will be much smaller.
> > > >
> > > >
> > > > >That, unfortunately, is as much as I know. What I don't know is
> how
> to
> > > > >overcome this problem such that R3 unequal load balances traffic
> to
> R1
> > > > just
> > > > >llike it does with traffic to R2.
> > > >
> > > > How about changing the EIGRP k values to achieve what you're
> after.
> One
> > > > possibility is to set them to only use delay, then set the delay
> very
> > low
> > > > on the 64K link from R2 to R1. This should give you pretty close
> to
> the
> > > > same distribution.
> > > >
> > > >
> > > >
> > > > >----- Original Message -----
> > > > >From: "Sergio Jimenez Arguedas" <sejimenez@its.co.cr>
> > > > >To: <ccielab@groupstudy.com>
> > > > >Sent: Thursday, July 22, 2004 8:14 PM
> > > > >Subject: RV: Eigrp unequal load balancing problem
> > > > >
> > > > >
> > > > >> Hi,
> > > > >>
> > > > >> I think traffic shara balanced is the option!!!
> > > > >>
> > > > >>
> > > >
> >
> >http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr
> /f
> > > > ipr
> > > > >> rp_r/1rfeigrp.htm#wp1024898
> > > > >>
> > > > >>
> > > > >> Rgds,
> > > > >>
> > > > >>
> > > > >> Sergio
> > > > >>
> > > > >>
> > > > >> -----Mensaje original-----
> > > > >> De: nobody@groupstudy.com [mailto:nobody@groupstudy.com]En
> nombre
> de
> > > > >> ccie2be
> > > > >> Enviado el: martes, 06 de julio de 2004 17:44
> > > > >> Para: tycampbell@comcast.net; Group Study
> > > > >> Asunto: Re: Eigrp unequal load balancing problem
> > > > >>
> > > > >>
> > > > >> Nope, not the answer.
> > > > >>
> > > > >> Variance is already configured and unequal load balancing
> already
> > works
> > > > >> between R2 and R3.
> > > > >>
> > > > >> The problem is that while unequal load balancing works between
> R2 &
> > R3,
> > > > >> unequal load balancing *doesn't* work between
> > > > >>
> > > > >> R1 and R3.
> > > > >>
> > > > >> Why?
> > > > >>
> > > > >> And, what is the solution?
> > > > >>
> > > > >>
> > > > >> ----- Original Message -----
> > > > >> From: <tycampbell@comcast.net>
> > > > >> To: "ccie2be" <ccie2be@nyc.rr.com>; "Group Study"
> > > > <ccielab@groupstudy.com>
> > > > >> Sent: Tuesday, July 06, 2004 7:06 PM
> > > > >> Subject: Re: Eigrp unequal load balancing problem
> > > > >>
> > > > >>
> > > > >> > I think variance may be the answer you are looking for
> > > > >> >
> > > > >> > variance of 2 should do it for this scenario
> > > > >> >
> > > > >> >
> > > > >> > > Hi guys,
> > > > >> > >
> > > > >> > > Here's the scenario:
> > > > >> > >
> > > > >> > >
> > > > >> > > 2 mbps
> > > > >> > > R1 -----64k ----- R2 ========= R3
> > > > >> > > 1 mbps
> > > > >> > >
> > > > >> > >
> > > > >> > > All routers are running Eigrp. R2 and R3 have unequal load
> > > > balancing
> > > > >> > > configured.
> > > > >> > >
> > > > >> > > Traffic between R2's lo0 and R3's lo0 unequal load balances
> > > > perfectly.
> > > > >> > > However, traffic between R1's lo0 and R3's lo0 don't
> > > > >> > > unequal load balance. In this case, traffic is balanced
> equally
> > > > across
> > > > >> the 2
> > > > >> > > links between R2 and R3.
> > > > >> > >
> > > > >> > > What the best way to have twice as much traffic going over
> the
> 2
> > > > mbps
> > > > >> link
> > > > >> > > from R3 to R2 as the 1 mbps link between those 2 routers?
> > > > >> > >
> > > > >> > >
> > > > >> > > TIA, Tim
> > > > >> > >
> > > > >> > >
> > > >
> >_______________________________________________________________________
> > > > >> > > Please help support GroupStudy by purchasing your study
> materials
> > > > >from:
> > > > >> > > http://shop.groupstudy.com
> > > > >> > >
> > > > >> > > Subscription information may be found at:
> > > > >> > > http://www.groupstudy.com/list/CCIELab.html
> > > > >>
> > > > >>
> >
> _______________________________________________________________________
> > > > >> Please help support GroupStudy by purchasing your study
> materials
> > from:
> > > > >> http://shop.groupstudy.com
> > > > >>
> > > > >> Subscription information may be found at:
> > > > >> http://www.groupstudy.com/list/CCIELab.html
> > > > >>
> > > > >>
> >
> _______________________________________________________________________
> > > > >> Please help support GroupStudy by purchasing your study
> materials
> > from:
> > > > >> http://shop.groupstudy.com
> > > > >>
> > > > >> Subscription information may be found at:
> > > > >> http://www.groupstudy.com/list/CCIELab.html
> > > > >
> > > >
> >_______________________________________________________________________
> > > > >Please help support GroupStudy by purchasing your study materials
> from:
> > > > >http://shop.groupstudy.com
> > > > >
> > > > >Subscription information may be found at:
> > > > >http://www.groupstudy.com/list/CCIELab.html
> > > >
> > > >
> _______________________________________________________________________
> > > > Please help support GroupStudy by purchasing your study materials
> from:
> > > > http://shop.groupstudy.com
> > > >
> > > > Subscription information may be found at:
> > > > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> _______________________________________________________________________
> > Please help support GroupStudy by purchasing your study materials
> from:
> > http://shop.groupstudy.com
> >
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Aug 01 2004 - 10:11:50 GMT-3