"Be liberal in what you accept..." NOT. Not when it comes to routes. Announcement ACL's have to be explicit or we are all in for a world of hurt. At CIX I'm doing it with just ASpath info but it really has to be route by route, which means something like the old Merit way of having each netblock specify its route preferences in some kind of global delegated database that we can each gen our ACL's from. In all the hoopla for and against route servers, we seem to have lost sight of the fact that distributed rwhois (distributed along CIDR lines) for netblocks would be a fine way for all of us to stay in sync. I know several NSP's who do this more or less by hand and it's hellish. When I ran 16.0.0.0/8's IGP, I used explicit ACL's. My exterior peers (you know who you are) used explicit ACL's to protect themselves against me, too, and it was a good thing since I periodically sent them a default route or some other leaking icky thing and it was good for me to get a single phone call from my BGP saying "hey, cut that out you idiot" than to get 250,000 phone calls from everybody in the universe asking "why are you doing this to me?" As my favorite WG chair likes to ask me, "can we try and remember what it was we were arguing about?" We are not all of a like mind with respect to the RS, but is the RA so bad if it lets each NSP (and many multihomed ISP's) gen up their local ACL's in a way that respects the wishes of a netblock's owner? So what if the RS people also use it -- if you don't want to peer with an RS, then don't ("what if they threw a party and nobody came?") Do we also/still need to argue about whether the RA data itself ought to be kept?

Route holdowns: los pobres paquetos: that's just the beauty and purpose of routing protocols to propagate the info so that los pobres paquetos don't clog the pipe with the goal of being dropped. To hold routes eternally down is not good: what if the customer disconnects that network? I don't want to be notified by all leaf networks when they will hickup or disconnect for good. Mike On Sun, 23 Apr 1995, Randy Bush wrote:

Don't know what other folk are seeing, or if y'all even look. But a significant number of leaf customer sites 'round these parts seem to be pseudo-random route generators. I watched a small POP, less than 100 customers, for about six weeks. I would never had guessed that DEC, IBM, MIT, and dozens of surprising Bs and Cs were in rural Southern Oregon. I'm sure that the POP's peer ASs would have been very impressed if we had redistributed those routes to external BGP sessions.

And we occasionally get some exciting announcements from overseas links.

To move along an other tangent... What is the general wisdom on putting pull-ups on route annoucements to deter route flap? Vadim kindly gave me a static Null 250 hack to keep announcement up even if the source of the route drops it. Hence, you won't get the !H until you get to our border. Los pobre packitos will travel all the way and then get whacked. Seems to subvert one interpretation one could read into the intent of BGP.

randy

-------------------------------------------------------------------------------- Michael F. Nittmann nittmann@wis.com Network Architect nittmann@b3.com B3 Corporation, Marshfield, WI (CIX Member) (715) 387 1700 xt. 158 US Cyber (SM), Washington DC (715) 573 2448 (715) 831 7922 --------------------------------------------------------------------------------

Don't know what other folk are seeing, or if y'all even look. But a significant number of leaf customer sites 'round these parts seem to be pseudo-random route generators. I watched a small POP, less than 100 customers, for about six weeks. I would never had guessed that DEC, IBM, MIT, and dozens of surprising Bs and Cs were in rural Southern Oregon. I'm sure that the POP's peer ASs would have been very impressed if we had redistributed those routes to external BGP sessions.

And we occasionally get some exciting announcements from overseas links.

To move along an other tangent... What is the general wisdom on putting pull-ups on route annoucements to deter route flap? Vadim kindly gave me a static Null 250 hack to keep announcement up even if the source of the route drops it. Hence, you won't get the !H until you get to our border. Los pobre packitos will travel all the way and then get whacked. Seems to subvert one interpretation one could read into the intent of BGP.

randy

What happens if you do this and the target is multihomed? As long as you don't violate the integrity of the alternate paths, nobody is going to complain (and some will bless you). If you do lots of folks will complain. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland Voice: [+1 312 248-8649] | 7 POPs online through Chicago, all 28.8 Fax: [+1 312 248-9865] | Email to "info@mcs.net" for more information ISDN: Surf at Smokin' Speed | WWW: http://www.mcs.net, gopher: gopher.mcs.net

To move along an other tangent... What is the general wisdom on putting pull-ups on route annoucements to deter route flap? Vadim kindly gave me a static Null 250 hack to keep announcement up even if the source of the route drops it. Hence, you won't get the !H until you get to our border. Los pobre packitos will travel all the way and then get whacked. Seems to subvert one interpretation one could read into the intent of BGP.

randy

This sounds a lot like the slippery slope of static routing being the most stable, so we should encourage its use Internet wide. I -know- Karl D. (and others that depend on dynamic routing for alternate provider fallback) will kick at this. The general argument is that since the current hardware technology has problems with "flap", causing meltdown, that we should use statics to reduce the visablity of "flap" across the net. It is my contention that any use of dynamic routing will get you "flap".. by definition. So we end up with a few possible outcomes (there are more...) - Static routing is enforced on the perimeter of ISPs (BGP dies as it is no longer useful) - Strict limits on "address" portability are imposed. (no-hole, provider based addressing) - Internal nets become so complex that dynamic IGPs are squashed and statics take over there as well. In the end, the Internet looks just like the telco mesh. --bill

In message <199504241414.AA14108@zed.isi.edu>, bmanning@ISI.EDU writes: | This sounds a lot like the slippery slope of static routing being the most | stable, so we should encourage its use Internet wide. I -know- Karl D. | (and others that depend on dynamic routing for alternate provider fallback) | will kick at this. Why? What we have been arguing for has been limiting the scope of dynamic routing only to places where participating in global dynamic routing makes sense. In the case of multihomed networks, the appropriate technique is, in most simple cases I am aware of: Provider X Provider Y | | +------------------------+ | border router | +------------------------+ | Dynamic routing domain The border router does aggregation outbound and points the aggregates at Null 0 with a high metric. This is for cases in which there is no other router participating within the customer iBGP mesh, and where there are N (N>=1) upstream providers, and where dynamic routing must take place within the ISP's routing domain for various reasons (portable dialup links, links that are time-sensitive, etc.) I would argue that if N is 1, then BGP shouldn't be used to talk to Provider X, and the customer router can therefore have much less memory, however there are still NSPs which require BGP for resellers as a matter of policy. Another fairly common current practice is this one, which is popular where there are N (N>1) providers where : Provider X Provider Y | | +------------+ +------------+ | BGP router | | BGP router | +------------+\ /+------------+ \ / +----------+ | iBGP box | +----------+ | Dyanmic routing domain The iBGP box should do aggregation and have static routes pointing to Null0 for all nets it announces to the two edge routers. The utility of BGP is thus preserved -- the iBGP box can route based on policy towards the rest of the world, and the rest of the world can route towards things behind the iBGP box, and things should work when Provider X or Provider Y goes away. A more complex case is one like this: Provider X Provider Y Peers A, B, Z | | | +--------+ +--------+ +---------+ | | | | | | +--------+ +--------+ +---------+ \ | / (a bunch of iBGP-talking routers) at this point people are building something akin to what NSPs do. Step 1 is to make very sure that there is the same reachability from any of the three boxes above to all of the iBGP boxes. That is, build redundantly, or get caught being a bad aggregator/flapper or a victim of non-fate-sharing networking. Step 2 is to do the _same_ aggregation and high-metric routing to Null 0 on all the border boxes (the three shown above) so that a consistent picture of this small-i internet is presented to the outsides world. Step 3 is self-protective; where possible, route things to Null 0 on all one's edge boxes to avoid unnecessary route-flap propagating internally. There are lots of other steps which should or could be taken as one grows, including relaxing Step 1 in favour of aggregation to shortish (18-bit) prefixes on internal routers such that the border routers don't necessarily have to perform aggregation and pointing at Null 0. I'd detail several more steps but my fingers tell me they want to go on to the next message. At any rate, in none of these examples is BGP being eliminated or the ability to multihome one's network compromised. However, in the first example (one edge box), I see an equivalent to Providers X and Y typing, say: ip route 209.1.0.0 255.255.0.0 Serial 0 remove-when-down set-as 7001 where the last part tells your Cisco to pretend it heard the route from AS 7001 (doesn't exist yet), and remove-when-down says when the interface is down, stop announcing the route (this is the current default). No BGP necessary, and less work for the customer to do. Sean.

So it does not make sense for IBM or Sony to run dynamic routing in their internal networks?!?

That depends. If the topology can change then you probably want dynamic routing. Usually when I set up a Sony-sized IGP, I run dynamic in the core and use statics to reach the edges, since while there are usually backup paths in the core, the edges tend to be singly connected. This is identical to the reasoning I'd use if I were designing an NSP. That's what was meant by:

Why? What we have been arguing for has been limiting the scope of dynamic routing only to places where participating in global dynamic routing makes sense.