RE: speed mismatch on frame multipoint sub interface and eigrp

From: pierreg (pierreg@mail.planetkc.com)
Date: Fri Jul 04 2003 - 13:02:23 GMT-3


Mike, thank you for the exhaustive answer.

I will be trying a few other things based on the info you brought here.

Pierre-Alex

---------- Original Message ----------------------------------
From: "Mike Williams" <ccie2be@swbell.net>
Reply-To: "Mike Williams" <ccie2be@swbell.net>
Date: Fri, 4 Jul 2003 09:59:58 -0500

This will work fine on any routes that R4 learns from R1 and R3 (as I
stated in my previous e-mail). But any routes that R3 and R1 learn from
R4 will have the same metric because, although EIGRP uses the lowest
bandwidth in the path, it uses the outgoing bandwidth of the interface.
So when R4 advertises to R1/R3, it will see a single bandwidth of 1544K.
Basically what I'm getting at is that the EIGRP metric is (for lack of a
better term) "direction sensitive". Here's an example:

10.2.2.0/24--R1-------------R2---------------R3--10.1.1.0/24
           band band band band
           512K 1544k 256K 768K
 
Here I have 3 routers with 2 1544K T1s between them, with the bandwidth
commands on each outgoing interface. Let's say R3 sends a route for
10.1.1.0/24 to R2. When it does, it uses "the smallest (outgoing)
bandwidth of the entire path" to compute the metric. In this case, the
only outgoing interface this route has traveled is the 768K interface.
So R2 receives the route and 768K is the bandwidth used. Then R2 sends
the 10.1.1.0/24 route to R1. When it does, it's outgoing bandwidth is
1544K. So 768K is still the smallest (outgoing) bandwidth in the path.
So when R1 gets the route, it uses 768K in the EIGRP computation. Now,
let's go the other way. When R1 sends to route for the locally
connected 10.2.2.0/24, it has an outgoing bandwidth of 512K, so when R2
gets the route, it uses 512K to compute the EIGRP metric. However, now,
when R2 sends the 10.2.2.0/24 route to R3, it has an outgoing bandwidth
of 256Kbps, so R3 receives the route, and now uses 256K to compute the
EIGRP metric since 256Kbps is the lowest bandwidth in the path from R1
to R3.

So the key thing to keep in mind is that EIGRP uses the minimum
bandwidth of all of the links *in the direction* that the route takes
from the router of origin. You can see the minimum bandwidth as well as
the delay used by a given router on a route by using "show ip eigrp
topology <network> <mask>"..... It's very important to use the mask, as
if you don't it assumes classful boundries....... I say that because we
use 10.x.x.x networks where I work but we have them broken into /16 and
/24s, but of course 10.x.x.x is a Class A, so if I don't put the mask on
that command, it assumes a /8.

HTH,
Mike W.

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
pierreg
Sent: Friday, July 04, 2003 8:50 AM
To: ccielab@groupstudy.com; pierreg@mail.planetkc.com
Subject: Re: speed mismatch on frame multipoint sub interface and eigrp

I think I may have a solution to my problem.

I will set the speed on R4 multipoint subinterface to 1544K
I will set the speed on R1 point-to-point interface to 768k
I will set the speed on R3 point-to-point interface to 512K

Given that EIGRP chooses the Lowerest bandwidth, the 1544K should be
ignored and the value on the spokes will be used.

I will now be testing.

Pierre-Alex

---------- Original Message ----------------------------------
From: "pierreg " <pierreg@XXXXX>
Reply-To: <pierreg@mail.planetkc.com>
Date: Fri, 4 Jul 2003 08:40:57 -0500

I have a simple question that is causing me lots of headache!

Please note there may not be a solution to this problem ...

---------------

R4 is connected to R1 and R3 via a multipoint subinterface

The PVC between R4 and R1 is 768 K

The PVC between R4 and R3 is 512 K

There is now way to put the two values on the multipoint subinterface.

So which bandwidth command should you use so that EIGRP computes

and advertise the metrics properly?

Thanks in advance,

Pierre-Alex



This archive was generated by hypermail 2.1.4 : Wed Aug 06 2003 - 06:52:24 GMT-3