From: ccie2be (ccie2be@nyc.rr.com)
Date: Tue May 06 2003 - 23:32:37 GMT-3
Hey Mike,
Such a thorough and comprehensive answer to a problem is very unusual on
group study, but I have to admit I'm very impressed and appreciative. Thank
you for taking so much time to go into the details.
That said, I think you're right on the money. At first I was baffled but as
I started thinking through the process of what was going on at each router
the mystery of this behavior began to unfold.
I started to understand this problem when I started to ask myself the right
questions:
Q: Why is rtrC equal load not unequal load sharing between the 2 links to
rtrB?
Answer: Because rtrC sees both paths as equal cost.
Q: Why does rtrC sees both paths as equal cost?
A: Because rtrC doesn't consider the bandwidth of the links between it &
rtrB; it only considers the minimum bandwidth which is the 64k between rtrB
and rtrA. And, the other part of the metric equation, delay, is also the
same for both links.
Q: What can by done to change the metric rtrC computes for the 2 paths.
A: Change the delay on the on the 128k link so that it's twice as large as
on the 256k link from rtrC point of view.
Anyway, I haven't yet modeled this scenario in my lab since I was doing some
other practice labs on Eigrp, but I hope to have a chance to try this out
sometime this week. I'm not positive about how much I have to change the
delay but I figure making it twice as large is a reasonable starting point.
Anyway, thanks so much for your response. It sounds like you must be very
close to taking the lab. Are you planning on taking it soon?
Jim
----- Original Message -----
From: "Mike Williams" <ccie2be@swbell.net>
To: "'ccie2be'" <ccie2be@nyc.rr.com>
Sent: Tuesday, May 06, 2003 7:58 PM
Subject: RE: Eigrp unequal load balancing problem
> (OFFLIST) (And warning, this is kinda lengthy, but bear with me)
>
> Jim,
>
> Could you tell me some info about your setup? Specifically, what is the
> DLY (delay) as seen in the 'sh int' command on Router C for the 128Kbps
> and 256Kbps links?
>
> The reason I ask, is that, according to Doyle's TCP/IP Chapter on IGRP,
> the delay for anything fom 56K to T1 is 20,000 microseconds. If this is
> indeed the case, then the 'sh int' command on Router C would show the
> same DLY for both links. If THIS is the case, and you have applied the
> appropriate bandwidth commands on all interfaces on Router A, B, and C,
> then Router C should see any routes learned by B that came from A as
> equal cost and should load balance without a variance command needed.
> However, Routes originating on Router b that C learns WON'T be equal
> cost and WON'T get load-balanced even with a variance of 2 (more below
> on this)
>
> Assuming you don't change the metric weights, IGRP (and EIGRP) use the
> bandwidth and delay to compute a metric. Having said that, IGRP (EIGRP
> does the same it just muliplies by 256 after the IGRP comuputation is
> done) uses the *minimum* bandwidth in the entire route path (which you
> already know). So for routes originating on Router A, that are passed
> along to Router B, which passed them to Router C, those networks will
> appear as equal cost to Router C. Here would be the calculation:
>
> RtrA RtrB RtrC
>
> --256---
> -*--64---* *
> --128---
>
> Assumming routes directly connected to Router A, then
> RTRB sees the metric as:
>
> (EIGRP) (BW in Kbps)
> | | (Interface Delay as seen from the exit interface on
> Router B)
> | | |
> \|/ \|/ \|/
> v v v
> 256 * ((10^7/64) + 20000/10) = 256 * (156,250 + 2000) = 40512000
>
> From Router C, it would see routes for networks connected to A as:
>
> Over the 128Kbps link:
> 256 * ((10^7/64) + (20000+20000)/10) = 256 * (156,250 + 4000) = 41024000
>
> Over the 256Kbps link:
> 256 * ((10^7/64) + (20000+20000)/10) = 256 * (156,250 + 4000) = 41024000
>
> (notice in the above 2 metric calculations from Router C, 10^6 is
> devided by the *minimum* bandwidth in the path, which is 64, no matter
> whether the path is across the 128K or 256K link from C to B. Also the
> delay is end to end delay, so I used 20000+20000 for the delay)
>
> As long as there is no lower bandwidth link that Router A learns routes
> across, then this same priciple would also apply to ANY routes learned
> by Router A that it passes on to Router B and therefore Router C. (The
> metrics would be different for routes LEARNED by A and passed on as
> opposed to originating on Router A, however, since Router A would have a
> single metric for these learned metrics, the additional delay, etc
> should work out equally across the 128Kbps and 256Kbps since Router C
> sees them both as having the same delay and the minimum BW is 64Kbps)
>
> Now, consider routes connected to Router B. When it sends those routes
> to Router C, now router C will see two unequal costs metrics for those
> network, while STILL seeing EQUAL cost paths for networks coming from
> Router A.
>
> From Router C, it would see routes for networks connected to B as:
>
> Over the 128Kbps link:
> 256 * ((10^7/128) + 20000/10) = 256 * (78,125 + 2000) = 20512000
>
> Over the 256Kbps link:
> 256 * ((10^7/256) + 20000/10) = 256 * (39062 + 2000) = 10211872
>
> The following URL says "The variance command instructs the router to
> include routes with a metric less than n times the minimum metric route
> for that destination": http://www.cisco.com/warp/public/103/19.html
>
> So, for routes originating on B (that are not connected to C), the
> minimum metric is over the 256K link. When you use a variance of 2,
> times the lower metric (10211872 * 2) you get = 20423744. Unfortunately
> for you, 20423744 is lower than 20512000, so the 256Kbps link isn't used
> for load balancing.
>
> Although there are many other variables involved, I'm wondering if you
> knock your variance up to 3 instead of two, then you should see
> load-balancing.
>
> Sorry for being so long, and I'd like for you to tell me the DLY seen in
> the 'sh int' on both links on Router C. Also, can you tell me what you
> see with "sh ip eigrp top <network>' on Router C for some of the
> networks on or learned by router A. This will show you the exact
> end-to-end delay and minimum bandwidth in the path, and therefore you
> can spot things you may not have considered. I've just been digging
> into the innerworkings of (E)IGRP metric calculation to solve an
> assymetrical routing issue we have at work......... And part of that
> had to do with the fact that we assumed certain connections were equal,
> whereas an extra "hop" (even at layer 2 if the switch/router see that
> VLAN interface as a L3 interface with a 10microsecond delay) make all of
> the difference.
>
> Mike W.
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> ccie2be
> Sent: Tuesday, May 06, 2003 6:54 AM
> To: Group Study
> Subject: Eigrp unequal load balancing problem
>
>
> Hi,
>
> I'm having a problem figuring this out. Maybe you can help. All 3 rtr
> are running Eigrp.
>
> rtrA -----64k------ rtrB============rtrC ( There are 2 links betw rtrB
> & rtrC 1 at 256k & the other
>
> at128k )
>
>
> I want to rtrC to unequal load share betw the 2 links to rtrB to get to
> networks on the far side of rtrA, but rtrC sees the 2 paths as equal
> cost since it computes the metric by taking the lowest bandwidth along
> the path which is 64k in both cases.
>
> How can I configure rtrC to load share to networks to the left of rtrA?
>
>
> This is bothering me because rtrB will load share going to rtrC.
>
> Thanks, Jim
This archive was generated by hypermail 2.1.4 : Mon Jun 02 2003 - 15:13:38 GMT-3