NHRP domino effect
Yakov Rekhter <yakov@cisco.com> Tue, 11 July 1995 22:56 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19596;
11 Jul 95 18:56 EDT
Received: from [204.249.96.18] by IETF.CNRI.Reston.VA.US id aa19592;
11 Jul 95 18:56 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 SAA09516;
Tue, 11 Jul 1995 18:42:27 -0400
Received: (from root@localhost) by maelstrom.acton.timeplex.com
(8.6.12/8.6.12) id SAA13184 for rolc-out; Tue, 11 Jul 1995 18:39:13 -0400
Received: from nexen.nexen.com ([204.249.96.18]) by
maelstrom.acton.timeplex.com (8.6.12/8.6.12) with ESMTP id SAA13175 for
<rolc@nexen.com>; Tue, 11 Jul 1995 18:39:11 -0400
Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by
nexen.nexen.com (8.6.12/8.6.12) with ESMTP id SAA09461 for <rolc@nexen.com>;
Tue, 11 Jul 1995 18:39:09 -0400
Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by
puli.cisco.com (8.6.8+c/8.6.5) with SMTP id PAA08944;
Tue, 11 Jul 1995 15:36:53 -0700
Message-Id: <199507112236.PAA08944@puli.cisco.com>
To: rolc@nexen.com
Cc: bcole@cisco.com
Subject: NHRP domino effect
Date: Tue, 11 Jul 95 15:35:39 PDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Yakov Rekhter <yakov@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/
Folks, Appended is a short draft from myself and Bruce Cole that describes one potential problem with NHRP, as well as offers a possible solution. Comments are welcomed. Yakov & Bruce. ---------------------------------------------------------------------- Avoiding "domino" effect One could easy imagine a situation where an ingress router receives a data packet, such that this packet triggers an NHRP Request. If the router forwards this data packet without waiting for a short-cut route (via NHRP) to be established, then when the next router along the path receives the packet, the next router could do exactly the same - it would originate its own NHRP Request (as well as forward the packet). In fact, if every router along a path from an ingress to an egress router is NHRP-capable, then a data packet that triggers NHRP Request generation in the first (ingress) router would trigger NHRP Request generation on every router along the path through an NBMA network. We refer to this phenomena as the NHRP "domino" effect. The NHRP domino effect is clearly undesirable. At best it may result in excessive NHRP traffic. At worst it may result in excessive number of VCs being established (for no good reason at all). Therefore, it is important to take certain measures to avoid (suppress) it. 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. Of course, a router may just be preconfigured not to originate NHRP Requests. In this case this router is not a subject to the NHRP domino effect, and need not do what is proposed in the previous paragraph. A most elaborate strategy could be to configure a router in such a way that NHRP Request generation by the router would be driven only by the traffic the router receives over its non-NBMA interfaces (interfaces that are not attached to an NBMA network). Traffic received by the router over its NBMA-attached interfaces would not trigger NHRP Requests. Just like in the previous case, such a router is not a subject to the NHRP domino effect, and need not perform any actions to suppress this effect. Further work is needed to analyze how limiting rate of NHRP Requests could facilitate dealing with the NHRP domino effect.
- NHRP domino effect Yakov Rekhter
- Re: NHRP domino effect Andy Malis
- Re: NHRP domino effect Andrew Smith