The Routing Over Large Clouds Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1994-Oct> msg00008



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

NHRP issue

  • From: Curtis Villamizar <curtis@ans.net>
  • Date: Wed, 19 Oct 1994 14:54:42 -0400
  • cc: rolc@maelstrom.timeplex.com


In message <9410190236.AA10086@sol.sura.net>, rcoltun@sura.net writes:
In message <9410190236.AA10086@sol.sura.net>, rcoltun@sura.net writes:
> 
> 
> NHRP looks quite reasonable to me except for the fact that routers
> will have to periodically send out requests:
> 
> >8.1 Router-to-Router Operation
> >
> >   In practice, the initiating and responding stations may be either
> >   hosts or routers.  However, there is a possibility under certain
> >   conditions that a stable routing loop may occur if NHRP is used
> >   between two routers.  This situation can be avoided if there are no
> >   "back door" paths between the entry and egress router outside of the
> >   NBMA network, and can be ameliorated by periodically reissuing the
> >   NBMA network, and can be ameliorated by periodically reissuing the
> >   NHRP request.  If these conditions cannot be satisfied, the use of
> >   NHRP between routers is not recommended.
> 
> In my mind this a bit of a hand-wave although I certainly don't have
> better solution; doesn't look like it will scale all
> that well. Does it give anyone else heartburn?

Yes.  But "If these conditions cannot be satisfied, the use of NHRP
between routers is not recommended" covers it for us.  :-)

The scaling of redirects worries me more.  A flapping class A will be
The scaling of redirects worries me more.  A flapping class A will be
fun.  Right now you send one routing update.  If 1,000 routes fail you
send a few updates containing 1,000 routes (depending on how much fits
in the PDUs).

You could close the VCs from every host, and blackhole on transient.
This doesn't work if hosts open one VC for all traffic to your router.
Otherwise you just give the switches fits (a very sudden drop of lots
of VCs and a big call setup load).

You could leave the VCs open, forward, and send redirects.  One
redirect per VC, per some time period should keep you from sending one
redirect per incoming packet.  That means keeping track of when
redirects were sent to each VC.  This is OK except that if 1,000
routes change, you need to keep track of which VCs have been sent
which redirects recently.  The worst case state size is #routes *
#VCs.  Doesn't seem to me to scale well.  The alternate is to keep no
state and send one redirect per incoming packet.

> Thanks,
> ---rob

Curtis