The Routing Over Large Clouds Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1995-Jul> msg00018



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

NHRP domino effect

  • From: Yakov Rekhter <yakov@cisco.com>
  • Date: Tue, 11 Jul 95 15:35:39 PDT
  • Cc: bcole@cisco.com
  • X-Orig-Sender: owner-rolc@nexen.com

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.