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@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