Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

[no subject]

  • From: Unknown
  • Date: Mon May 22 23:34:08 2006

Generally, you should never announce internal instability/reachability 
problems to the real world.  There are some exceptions of course - most 
notably issues regarding full "SPLITS" of internal networking (you end up 
with two distinct networks which don't have connectivity to them) - 
but in most of these cases you're screwed in any case as you've probably got 
aggreated CIDR blocks split up.

As far as your internal routing goes, there's arguments both ways.  In my 
network I have some "customer edge" border routers which are quite 
frankly incapable of "null0" routing.  When they get a packet which is 
bound for a link which is down they forward it back to their default, 
which, under static routing, would forward it back to them, and on and on
until the TTL is expired.

I personsonally use dynamic routing between the braindead router and the 
more clueful one (cisco) to enable discarding of packets.  When the route 
flaps down, the cisco now uses the null0 path.  When it flaps back up, 
the cisco then starts forwarding packets again.

However, the world never needs to see this - it's an internal routing 
issue and when the internal route flaps it shouldn't affect the external 
routes.

So in summary:

1) Never flap your routes in public.  What you do in your own home is 
your own business.

-forrestc@imach.com

On Fri, 12 Jul 1996, Per Gregers Bilse wrote:

> On Jul 11, 20:53, Alan Hannan <alan@gi.net> wrote:
> >   If rtra is down, I do not want rtre to send packets to rtrd to get
> >   to rtra, do I?  Wouldn't I prefer them to be stopped ASAP?
> 
> This makes no difference.  For most intents and purposes, one-way
> traffic doesn't exist.  The only thing going down that line will
> be the odd packet intended to open a conversation -- the volume of
> this will be minimal compared to normal traffic volumes.  And even
> if you had one-way traffic in volume, it wouldn't exceed normal
> traffic levels, for which you will already have the capacity.
> 
> Whenever you do dynamic routing when it isn't necessary, you -will-
> be emitting unnecessary updates, which nobody is interested in.  We
> have several ASs behind unstable lines behind us, from which we do
> not propagate routing changes; we set origin AS and announce
> nailed-up static routes in their AS.  Neat, stable, works -- no flap
> and no global propagation delay when the connection comes back up.
> 
> > * Another situation is what happens when you renumber networks?
> 
> Your router configuration will be changed ... ?  :-)
> 
> >   What hapens when you've large number of downstream networks?  Do
> >   you really want static routes in rtrf for all networks attached to
> >   rtrs a,b,c,d,e?
> 
> Where you cut dynamic updates off doesn't really matter.  The key
> issue is not to propapgate unnecessary updates.  I mean, is it really
> interesting that a tail circuit in Cargolia went down?  Does this
> event -have- to be announced to the Net?
> 
> A different issue is that there are many networks with broken
> configuration.  If these people would "do the right thing", and not
> announce their instability to the Net, we'd be rid of, what?, 90% of
> all route flap.
> 
> -- 
> ------ ___                        --- Per G. Bilse, Mgr Network Operations Ctr
> ----- /     /  /   __   ___  _/_ ---- EUnet Communications Services B.V.
> ---- /---  /  /  /  /  /__/  /  ----- Singel 540, 1017 AZ Amsterdam, NL
> --- /___  /__/  /  /  /__   /  ------ tel: +31 20 6233803, fax: +31 20 6224657
> ---                           ------- 24hr emergency number: +31 20 421 0865
> --- Connecting Europe since 1982  --- http://www.EU.net  e-mail: bilse@EU.net
> 
- - - - - - - - - - - - - - - - -




Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.