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.