Routing flaps, was Re: Ping flooding

Forrest W. Christian forrestc at imach.com
Fri Jul 12 13:40:32 UTC 1996


>From reading this discussion, I think that there are two separate issues 
being discussed or argued here - specifically internal versus external 
routing methodologies.

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 at imach.com

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

> On Jul 11, 20:53, Alan Hannan <alan at 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 at EU.net
> 





More information about the NANOG mailing list