From: ccie2be (ccie2be@nyc.rr.com)
Date: Thu Jul 08 2004 - 12:52:34 GMT-3
I have to admit, Ididn't think of "ip route-cache" as a possible cause of
this dilemma, but, now that you brought this to my attention, I still think
it shouldn't affect the results of the unequal load-balancing. Here my
reason.
If unequal load-balancing works between R3 and R2, this isn't a factor. So,
the problem remains.
Who would have thought that such a seemingly simple problem would confound
so many very knowledgable people?
Tim
----- Original Message -----
From: "Mujica, Raul - (Per)" <raul.mujica@telmex.com>
To: "Jensen, Brian D." <bdjensen@eschelon.com>
Cc: <ccielab@groupstudy.com>
Sent: Thursday, July 08, 2004 11:03 AM
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
> > > >>
> > > >>
> _______________________________________________________________________
> > > >> 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:49 GMT-3