From: Jensen, Brian D. (bdjensen@eschelon.com)
Date: Thu Jul 08 2004 - 12:19:48 GMT-3
Hi Raul,
I did that last night, too. I turned off route cache on both sides, forcing
process routing/switching. Didn't have the effect I was expecting. Then I
turned on CEF, with load balancing, and still the traffic preferred the high
bw route. I couldn't believe it. I must have spent most of last night
working on this, and trying different scenarios. At first glance, this
seemed like such a simple thing, but the more I dug, the more my
expectations were turned upside down. Finally I just went to bed....:)
The solutions of changing the BW I am uncomfortable with, as this affects
other things eigrp does, and deleting bw as part of the kvalue calculation
to just use delay could mess up an entire eigrp domain. There must be
something I am missing....
Thanks,
Brian
-----Original Message-----
From: Mujica, Raul - (Per) [mailto:raul.mujica@telmex.com]
Sent: Thursday, July 08, 2004 10:04 AM
To: Jensen, Brian D.
Cc: ccielab@groupstudy.com
Subject: RE: Eigrp unequal load balancing problem
Brian,
The traffic from R1 to R3 will not balance because "ip route-cache" is
enabled by default on all interface. Verify output interface for R34s
loopback on R2 with "sh ip cache". (Run debug ip packet #ACL on R3 to
verify)
If you want that traffic balances between the two links between R2-R3,
disable "ip route-cache" on all interface (of course enable "debug ip packet
#ACL on R3 and R2 to check).
Regards,
Raul
-----Mensaje original-----
De: Jensen, Brian D. [mailto:bdjensen@eschelon.com]
Enviado el: Jueves, 08 de Julio de 2004 08:30 a.m.
Para: 'ccie2be'; Jensen, Brian D.; 'Tim Fletcher'; Sergio Jimenez Arguedas;
ccielab@groupstudy.com
Asunto: 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
> > >>
> > >>
This archive was generated by hypermail 2.1.4 : Sun Aug 01 2004 - 10:11:49 GMT-3