Re: NHRP domino effect
Andrew Smith <asmith@baynetworks.com> Fri, 14 July 1995 23:24 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07374;
14 Jul 95 19:24 EDT
Received: from [204.249.96.18] by IETF.CNRI.Reston.VA.US id aa07370;
14 Jul 95 19:24 EDT
Received: from maelstrom.acton.timeplex.com (maelstrom.nexen.com
[204.249.97.5]) by nexen.nexen.com (8.6.12/8.6.12) with ESMTP id RAA03883;
Fri, 14 Jul 1995 17:58:47 -0400
Received: (from root@localhost) by maelstrom.acton.timeplex.com
(8.6.12/8.6.12) id RAA22388 for rolc-out; Fri, 14 Jul 1995 17:53:24 -0400
Received: from nexen.nexen.com ([204.249.96.18]) by
maelstrom.acton.timeplex.com (8.6.12/8.6.12) with ESMTP id RAA22379 for
<rolc@nexen.com>; Fri, 14 Jul 1995 17:53:20 -0400
Received: from lightning.synoptics.com (lightning.synoptics.com
[134.177.3.18]) by nexen.nexen.com (8.6.12/8.6.12) with SMTP id RAA03854 for
<rolc@nexen.com>; Fri, 14 Jul 1995 17:53:18 -0400
Received: from BayNetworks.COM ([134.177.1.95]) by lightning.synoptics.com
(4.1/SMI-4.1) id AA12614; Fri, 14 Jul 95 14:50:06 PDT
Received: from milliways-le0 (milliways-le0.synoptics.com) by BayNetworks.COM
(4.1/SMI-4.1) id AA04629; Fri, 14 Jul 95 14:51:12 PDT
Received: by milliways-le0 (4.1/2.0N) id AA15967; Fri, 14 Jul 95 14:53:07 PDT
Message-Id: <9507142153.AA15967@milliways-le0>
Date: Fri, 14 Jul 95 14:53:07 PDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Andrew Smith <asmith@baynetworks.com>
To: rolc@nexen.com, yakov@cisco.com
Subject: Re: NHRP domino effect
Cc: bcole@cisco.com
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/
> From owner-rolc@nexen.com Tue Jul 11 15:55:22 1995 > To: rolc@nexen.com > Cc: bcole@cisco.com > Subject: NHRP domino effect > Date: Tue, 11 Jul 95 15:35:39 PDT > From: Yakov Rekhter <yakov@cisco.com> Yakov, > The NHRP domino effect is clearly undesirable. .... > One possible solution for suppressing the domino effect would be to > require that when a router forwards an NHRP Request, the router > instantiates a (short-lived) state. The state just contains the route > that was used to forward the request. If the router receives a packet, > and the packet triggers an NHRP Request generation by the router, the > router checks whether the route to forward the request was recently > used to forward another request. If yes, then the router doesn't > generate the request (but still forwards the packet). This solution > also requires that when a router wants to originate an NHRP Request the > router should send the request before the data packet that triggered > the origination of the request. I think some router implementations might have trouble implementing this requirement, yours and ours included :-) Andrew ******************************************************************************** Andrew Smith TEL: +1 408 764 1574 Technology Synergy Unit FAX: +1 408 988 5525 Bay Networks, Inc. E-m: asmith@baynetworks.com Santa Clara, CA ********************************************************************************
- NHRP domino effect Yakov Rekhter
- Re: NHRP domino effect Andy Malis
- Re: NHRP domino effect Andrew Smith