April 2001 - Test - lists.nanog.org

Routing System Scaling - Disaster Looming, but Medium-Term Fixes Known
by smd＠clock.org 02 Apr '01

02 Apr '01

It's very simple: ANYONE can build a multi-Gpps router which can handle a million or two static routes. Hell, if the Internet were completely undynamic, alot of things would be much easier. Likewise, anyone can build a 0 pps router that can handle an order of magnitude more dynamism in the global routing system than we observe today. Finally, anyone can build a multi-Gpps router that can handle heavy dynamism in a global routing table consisting of a dozen prefixes. The Internet: bigger, faster, more dynamic. Choose two. One usually sees "cheaper" as one of the terms in the "choose two" joke. In this case, it's implicit, since the total price of a large router is greater than the sum of the (increasingly expensive) cost of providing the oompf necesary to do each of these three things. So, there are several Deaths of the Internet which are possible: -- it's too expensive to keep up with growth, so utilization falls off, since nobody wants to pay the real bills -- we blow up on one of the scaling axes -- too many routes: poof, we run out of memory routers are unhappy when out of memory... (ok, more memory is cheap for static storage, but ever-faster memory seems to be a general problem) -- too much dynamism: poof, our memory isn't fast enough, or the distribution of stuff via BGP/TCP isn't fast enough, or we have no CPU cycles to generate tables fast enough our our communication among routing-process CPUs and forwarding engine isn't fast enough, etc... everyone is unhappy when it takes minutes, hours, or DAYS to see the end of blackholes/loops/other effects of incomplete convergence after a change (ok, everyone knows about route damping, yes? http://www.ripe.net/docs/ripe-210.html ) -- we blow up because while we can handle some of the technical aspects of routing system complexity, we lose on human factors -- inefficient/broken routing: we don't have the power needed to apply decent policy to the routes we learn from elsewhere, which is already seen in the form of route leakage, inadvertant transit, etc., and we don't have the skills to quickly find & fix problems that have global effect The reaction to scale driven by increasing numbers of ever-longer prefixes should not be a panicky turn to something radical, or sky-is-falling moaning. It has been demonstrated (by me) that there is little reachability lost when applying prefix-length filtering, or when applying progressive flap-damping (e.g., if you flap something longer than a /24, the route's gone from my tables until tomorrow). Dennis Ferguson's arguments for maximum-prefix limits from peers are also very interesting, and have gotten some testing in the real world. Ultimately the problem here is that this just makes introducing ever-longer prefixes harder, but does not expose a real cost to someone who is thinking of doing this. If various people, or someone sufficiently large, ever gets around to implementing the following idea, I think people may be more inclined to renumber and/or be aggregated, rather than try to introduce "exception routes" into the global routing system. What I wish I had finished @ Sprint: a web-based form that lets one arrange an exception to access-list 112 for some small fee, like $50/month/change. For your 50 bucks, you see no filtering on one of your long prefixes for a whole month (or year or whatever). These days it may be that your $50/month will make your long prefix less likely to be damped out of the routing table for a long time, however there is scope for further innovation, such as charging only $5 to clear your prefix out of the flap-damping penalty box of one router. This revenue stream would surely pay for alot of the costs of upgrading routers with more memory, faster CPUs, more CPUs, faster memory, better code, etc. to deal with the increase in the number and dynamicism of the current Internet's global routing system. It might even fund the switchover to something better than the IDR architecture we have now. Sean.

1 0

Re: outages in Toronto Canada (other places?)
by Sean Donelan 02 Apr '01

02 Apr '01

On Mon, 02 April 2001, Jon Stanley wrote: > interface. Apparently some routing process got hung and had to be > restarted, the person on the other end of the phone was a little unclear > as to what the problem really was..... Has anyone spoken with someone who was a little clearer about what the problem was? Was it operator error/software bug routing problems, or an attack. It seemed unusually wide-spread, and normally UUNET is good about saying what happened. But this time everyone seems a bit fuzzy.

1 0

Sprint and peering points
by Roy 02 Apr '01

02 Apr '01

Since I am located in what PacBell thinks is a rural area, I have to contend with using multiple T1s. This forces me to play with the AS paths in order to load balance between my upstreams (Sprint and others) I have found that Sprint is prepending their AS when sending routes to many of the public exchanges (example "1239 1239 20001") in order to "shift load" to private peer connections. The result is that now my other upstreams that send out the normal "701 20001" get the brunt of the traffic from the public exchange points. Needless to say I am a bit pissed at Sprint for doing this and not telling me. I had been a fan of Sprint until this happened. Anyone else out there seeing the same problems? Any ideas on how to cure it Roy Engehausen

5 7

Re: outages in Toronto Canada (other places?)
by Sean Donelan 02 Apr '01

02 Apr '01

The UUNET status web site was last updated on Fri Mar 30 20:20:14 EST 2001 and indicates no problems on the network. The Matrix (average.miq.net) shows several drop-outs in network performance. Numerous other providers and customers sent me mail that there is a routing issue with UUNET. No word out of UUNET though.

3 3

RE: dsl providers that will route /24
by Jason Lixfeld 02 Apr '01

02 Apr '01

Are we talking business grade DSL or Resi grade DSL? > -----Original Message----- > From: Roeland Meyer [mailto:rmeyer@mhsc.com] > Sent: Sunday, March 25, 2001 3:04 PM > To: 'michael'; nanog(a)merit.edu > Subject: RE: dsl providers that will route /24 > > > > If you find such, I want to know too. > > > -----Original Message----- > > From: michael [mailto:michael@aplatform.com] > > Sent: Sunday, March 25, 2001 8:08 AM > > To: nanog(a)merit.edu > > Subject: dsl providers that will route /24 > > > > > > > > Hello, > > > > Looking for contact information on dsl providers that route > > IP space not > > within their assigned block. I am also curious on high > speed wireless > > doing the same. > > > > Thanks, > > > > Michael... > > > > > > > -------------------------------------------------------------- > ----------- > This email server is running an evaluation copy of the > MailShield anti- > spam software. Please contact your email administrator if you have any > questions about this message. MailShield product info: www.mailshield.com .

19 70

IPv4 IP multicast best current practice
by Bill Nickless 01 Apr '01

01 Apr '01

-----BEGIN PGP SIGNED MESSAGE----- I have posted http://www-fp.mcs.anl.gov/~nickless/draft-nickless-ipv4-mcast-bcp-00.txt to the internet-drafts(a)ietf.org and the IETF mboned mailing lists. As I'm hoping it will eventually be adopted as a Best Current Practice, (having operational significance) please read it over and comment. === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless(a)mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com> iQCVAwUBOsfvrqwgm7ipJDXBAQHwdQQAgX1pb/H8fc1sArKL93w2Uf8LCZoqLT5S 79QudSw0jgsZgfEQHEc75smxLJWFSNvW7aggfMGEDXaGHE4caYrhwMemcQbNqHRp R6sLgPheV7H3MBs+oYeOBtWtaAB3F7n193SJ7+ryYDzz88dMVhD6bW+XhPlCVbrD l8YAEtU6+To= =Xyc4 -----END PGP SIGNATURE-----

1 0

Re: outages in Toronto Canada (other places?)
by Sean Donelan 01 Apr '01

01 Apr '01

On Sun, 01 April 2001, "Majdi S. Abbas" wrote: > UUnet appears to be very broken internally. Lots of reachability > issues, and they are announcing only a percentage of their prefixes to > many peers in various places. UUNET US customer service says no one has reported any problems.

2 1

Re: outages in Toronto Canada (other places?)
by Jim Mercer 01 Apr '01

01 Apr '01

On Sun, Apr 01, 2001 at 08:55:16PM -0400, Joseph Brunner wrote: > www.ibm.com > yet the site loads very fast... as easily in new york as in nigeria, perhaps > only port 80 gets alas, www.ibm.com was probably not a good place to point. i will note however, that i had dns trouble getting www.uu.net to resolve from a number of different places (and name servers). and there were other routing issues, seemingly with alter.net or uunet. jim -- hoping he wasn't crying wolf. -- [ Jim Mercer jim(a)pneumonoultramicroscopicsilicovolcanoconiosis.ca ] [ Reptilian Research -- Longer Life through Colder Blood ] [ aka jim(a)reptiles.org +1 416 410-5633 ]

1 0

Re: California PUC orders outage notification
by Sean Donelan 01 Apr '01

01 Apr '01

On Fri, 30 March 2001, "Henry R. Linneweh" wrote: > This will happen if the ISO gives ample warning, it has already been > determined that 10 minutes would not fall within that category, so its > a good decision but has its drawbacks. The California Office of Emergency Services now includes CAL-ISO power alerts in its radio EDIS service. (http://edis.oes.ca.gov/) Several software programers have developed various programs which constantly poll the CAISO web site, and will make noises and flashes your PC screen when alerts are issued.

1 0

BGP Community Attribute Support: Summary
by Joe Abley 01 Apr '01

01 Apr '01

The other week, I asked: On Sat, Mar 24, 2001 at 10:25:35PM -0500, Joe Abley wrote: > Quick poll: does any operator here currently use a router which does > not support setting BGP community attributes, does not permit community > attributes to be matched exactly when doing ingress/egress route > filtering, or does not permit wildcard matches on the last two octets > (e.g. "permit 1234:*")? These were pretty targeted questions, and what I have largely heard is silence. Hence either these three capabilities have widespread support, or people just didn't find the question interesting enough to reply to. I guess I shouldn't start designing surveys for a living :) Anyway, a couple of people said there was interest in a results summary, so here are the main points: + gated 3.6 public doesn't support setting community attributes but will pass them on unscathed, as you'd hope; + "Extreme networks equipment" does not support the wildcard community match, although the person who told me that had only limited experience with the product range; I also happened to ask a few people about specific platforms, and found out: + the Nortel shasta and bay RS platforms support those three capabilities + zebra supports all three capabilities (the wildcard match function is in version 0.91a, based on a patch by Rick Payne) I was already confident I could do all three things on juniper and cisco boxes, although I didn't bother to analyse which IOS/JUNOS versions would definitely support all three. One correspondant (working for a vendor) lamented the lack of clear guidelines on what base functionality should be supported by bgp speakers at all in relation to manipulating community attributes, and suggested a more general poll might be useful for that reason. The reason for asking about those three particular capabilities was to search for platforms that would have trouble doing this: http://www.automagic.org/~jabley/draft-jabley-edge-policy-propagation-contr… Thanks, Joe

1 0