Re: r2r NHRP - Target Size
Dimitry Haskin <dhaskin@baynetworks.com> Wed, 22 November 1995 16:38 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14620;
22 Nov 95 11:38 EST
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa14604;
22 Nov 95 11:37 EST
Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by
guelah.nexen.com (8.6.12/8.6.12) with ESMTP id LAA20773;
Wed, 22 Nov 1995 11:03:55 -0500
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id
LAA05377 for rolc-out; Wed, 22 Nov 1995 11:15:11 -0500
Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by
maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id LAA05364 for
<rolc@nexen.com>; Wed, 22 Nov 1995 11:15:08 -0500
Received: from lobster.wellfleet.com (lobster.wellfleet.com [192.32.253.3]) by
nexen.nexen.com (8.6.12/8.6.12) with SMTP id LAA20661 for <rolc@nexen.com>;
Wed, 22 Nov 1995 11:15:04 -0500
Received: from pobox.BayNetworks.com (pobox.wellfleet.com) by
lobster.wellfleet.com (4.1/SMI-4.1)
id AA12262; Wed, 22 Nov 95 11:11:11 EST
Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1)
id AA03952; Wed, 22 Nov 95 11:12:12 EST
Date: Wed, 22 Nov 95 11:12:12 EST
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Dimitry Haskin <dhaskin@baynetworks.com>
Message-Id: <9511221612.AA03952@pobox.BayNetworks.com>
To: rolc@nexen.com, 92mjr1@eng.cam.ac.uk
Subject: Re: r2r NHRP - Target Size
X-Orig-Sender: owner-rolc@nexen.com
Precedence: bulk
X-Info: Submissions to rolc@nexen.com
X-Info: [Un]Subscribe requests to rolc-request@nexen.com
X-Info: Archives for rolc via
ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/
Matthew, > > > > One example: > > > > Let's assume a forwarder A wants to build a single shortcut to a default > > router which mainains a complete routing table and can act as a traffic > > de-multiplexer for A. The domain topology may look like that: > > > > E > > | > > A -- B -- C -- D -- F > > | > > G > > > > where D is a proxy router for E, G, and F exit forwarders. D injects a default > > into IGP. To resolve the shortcat destination, A sends request for the default > > route (i.e. 0.0.0.0/0) along ABCD path. When request reaches D, D would be obliged > > to reply to A since it has more specific routes than the requested default route. D > > specifies itself as the shortcut endpoint. > > > > Dimitry > > I'm assuming that all the routers in the above diagram are on the > same NBMA. Is this correct ? Correct. > If so, then the behaviour suggested isn't quite what I expected > but can be made to happen. I'm interested in a fairly simple multi-area > OSPF arrangement of routers as the "underlay" to NHRP. A diagram can be > made available if you like, but for now I'll try and describe my scenario: > Network is broken up into OSPF areas of approx. 50 routers each. > Two ABRs are allocated for each _pair_ of areas. Each ABR links to area 0 > and to _both_ these areas, thus providing redundant connection between > each area and the backbone. > Each area is in effect a smaller "large cloud" and so in the > above diagram routers B and C don't exist. > The ABRs perform address aggregation and consequently other > routers do not know what size LANs are attached to routers in other > networks. Just sending NHRP requests for a single host address is liable > to be inefficient. On the other hand, establishing a "short-cut" to the > ABR is not normally useful since NHRP has then done nothing. > > From the current spec. (Yakov's email of 20th Oct.) I'm under the > impression that if A sends a Request for a Target covering (say) E,F and > G then D should in effect return an error: > "If the Second NHRP target constraint is violated then the router > [D in this case] sends back an NHRP Reply and terminateas the query. The > Reply should indicate that the second NHRP target constraint was violated. > The Reply contains IP and NBMA addresses of the router." > The upshot of this is that the "error" reply lets you use D as a > forwarder for E,F and G if you really want. > However, please could you give some examples where this is > desirable (I'm under the impression that it's advisable to avoid sending > data via D since sending traffic between D and the NBMA network will often > cost money ). > If you look at the current practices in legacy networks you may find a lot of devices that send all their traffic to a router even if a more direct path is available. I saw it used on a large scale when I supported a huge, goverment run X.25 based network where a good number of peripheral routers and hosts sent their traffic to a few "core" routers. The reason it is used exactly the same that you think it should be avoided - economical. In some cases it is more economical to default traffic to a few high-end routers than to attempt to maintain necessary states and routing information at peripheral devices. As to your case I think you'd use R2R in the following way: When A wants to send trafic to a destination for which it doesn't have a specific route, it sends a Request with a mask of all ones (or prefix length of 32 as Yakov suggested). If this desination is reached via an exit router E, E replies with the prefix length of the route to the desination. Now A may use the shortcut to E to send traffic to all destinations covered by the route that E provided. Desitnations through F and G are resolved in the same way. I hope it helps. > Matthew. > > Dimitry
- r2r NHRP - Target Size M.J. Robinson
- Re: r2r NHRP - Target Size Dimitry Haskin
- Re: r2r NHRP - Target Size Yakov Rekhter
- Re: r2r NHRP - Target Size Andrew Smith
- Re: r2r NHRP - Target Size Adrian Smith
- Re: r2r NHRP - Target Size Dimitry Haskin
- Re: r2r NHRP - Target Size M.J. Robinson
- Re: r2r NHRP - Target Size Dimitry Haskin