- NANOG - lists.nanog.org

RE: The Backhoe Summit
by David Lesher 24 Sep '00

24 Sep '00

> > Do the large carriers now participate in 'one-call' operations like power > > and gas companies do? At least in Virginia a couple of years ago, they > > didn't. It might be a good idea for them to do so. > > "For competitive reasons we can't tell you the location of our fiber." > > - An anonymous representative of a very large telco > For competitive reasons we can't tell you the location of our backhoe... -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

1 0

RE: The Backhoe Summit
by rdobbins＠netmore.net 24 Sep '00

24 Sep '00

Do the large carriers now participate in 'one-call' operations like power and gas companies do? At least in Virginia a couple of years ago, they didn't. It might be a good idea for them to do so. -----Original Message----- From: Sean Donelan To: nanog(a)merit.edu Sent: 9/23/00 5:36 PM Subject: The Backhoe Summit On November 30 I'm moderating a session at the Damage Prevention Convention (http://www.damageprevention.com/) on "What is being done to protect the Internet." What types of questions would you ask excavators, service providers, and users? Although we often joke about the backhoe as the leading cause of fiber cuts, in almost 1/3 of the cable cuts last quarter were due to inaccurate or incomplete marking by the cable owner. Are fiber companies their own worst enemy? Diversity, is it just an illusion. How can a user order diversity and be assured of getting it? How can we estimate the effect of a cable cut? With today's mergers, reselling, and swapping of fiber combined with dense-wave multiplexing a lot of customer's could have data passing through the same right of way. I'd like to have a mix of softball questions and a few more provacative questions. If you have any, please send them to me.

1 0

The Backhoe Summit
by Sean Donelan 24 Sep '00

24 Sep '00

On November 30 I'm moderating a session at the Damage Prevention Convention (http://www.damageprevention.com/) on "What is being done to protect the Internet." What types of questions would you ask excavators, service providers, and users? Although we often joke about the backhoe as the leading cause of fiber cuts, in almost 1/3 of the cable cuts last quarter were due to inaccurate or incomplete marking by the cable owner. Are fiber companies their own worst enemy? Diversity, is it just an illusion. How can a user order diversity and be assured of getting it? How can we estimate the effect of a cable cut? With today's mergers, reselling, and swapping of fiber combined with dense-wave multiplexing a lot of customer's could have data passing through the same right of way. I'd like to have a mix of softball questions and a few more provacative questions. If you have any, please send them to me.

1 0

RE: White House Net security summit
by Mike Bostardi 23 Sep '00

23 Sep '00

More than likely laws will be passed that gives the Feds the ability to fine you $100 US for not changing your passwords every 30days. IHMO this latest "White House Meeting" is another example of the government attempting to regulate something that they have no clue and no business in. Whats next a committee on minimum router config standards... I'm done > -----Original Message----- > From: Wayne Bouchard [mailto:web@typo.org] > Sent: Thursday, September 21, 2000 6:35 PM > To: Sean Donelan > Cc: nanog(a)merit.edu > Subject: Re: White House Net security summit > > > > Is security in an environment where new applications are installed on > an almost daily basis something you can really regulate? In some > regards, the thought of Washington getting involved here scares > me. > > On Thu, Sep 21, 2000 at 03:03:55PM -0700, Sean Donelan wrote: > > > > I guess if you snooze you loose. For anyone who didn't > know from MSNBC > > > > "A group of key high-tech executives agreed at a White > House meeting earlier > > today to move forward on a plan to set minimum security > standards for big > > companies that connect to the Internet, MSNBC.com has > learned. The meeting > > was attended by Microsoft, IBM, Oracle, Boeing, the > National Security Agency > > and U.S. Secretary of Commerce Norm Mineta." > > > > > > > > ---------------------------------------------------------------------- > Wayne Bouchard [Immagine Your ] > web(a)typo.org [Company Name Here] > Network Engineer > http://www.typo.org/~web/resume.html > ---------------------------------------------------------------------- >

3 3

Re: exponential route prefix growth, was: Re: The Cidr Report
by John Todd 23 Sep '00

23 Sep '00

>On Fri, Sep 22, 2000 at 03:44:50PM -0400, Vijay Gill wrote: > > On Fri, 22 Sep 2000, Kai Schlichting wrote: > > > > [ http://www.employees.org/~tbates/cidr.plot.html for a plot ] > > > > > of engineering experience announcing 32 /24's out of their scattered > > > POPs in addition to their /19 aggregate because they can't get their > > > load balancing right without it or have never heard of the 'NO_EXPORT' > > > attribute (I could point fingers now)? > > > > I suspect data from inside providers with aggressive filtering policies > > might prove to be interesting. > > > > Some promising local providers were past the 150k mark a while ago for sum > > (internal + global bgp) routes and were growing superlinearly the entire > > time because of the ever increasing number of customers. > > I have in one location over 100k prefixes received from >one nice large international provider: > >Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down >State/PfxRcd >a.b.c.d 4 701 10776831 107250 13024503 0 0 1w4d 105250 > > My primary concern is that the current growth is going to >outscale the medium sized providers as the one vendor that >the above output came from doesn't appear to be providing enough memory >in their equipment, or have enough memory options available. > > I am not predicting "the internet will end in 9 days, repent", >but it is some cause for concern in the next 6-12 months. > > What would be nice is if someone were to put together an >auto-nagger similar to the "your dns server is lame" of the old days >messages. Back when the network tables were about 40-45k, I would read >the output of "sh ip b" and send messages to people asking them to >aggregate, but those days are over... (at least for me..) > > - jared > >-- >Jared Mauch | pgp key available via finger from jared(a)puck.nether.net >clue++; | http://puck.nether.net/~jared/ My statements are only mine. >END OF LINE | Manger of IP networks built within my own home Take a look at: http://www.fox-den.com/routes/ This is a plot of routes v. paths on a router that peers with or at least sees the tables from a few large upstreams. Please ignore the large gaps in the chart where I <ahem> did some configuration that was contrary to the correct functioning of my statistics collection. This is a crude measurement, but it's useful for trending. I'm sure someone at CAIDA has done better research than my stupid-simple MRTG graphs, but I haven't seen theirs mentioned yet so I'll throw my $.02 in first. What is interesting in the growth difference between the two growth patterns. An interesting trend shows; there is a much larger increase in the number of paths than in the number of routes. I would assume that this indicates a growth in the interweaving of networks, or at least the interweaving of transit providing relationships. I suspect the interweaving of interconnections is growing at a similar rate, but proof of this is invisible with only a few BGP perspectives. Perhaps the more vital piece of information in this discussion is not the sudden growth of routes, but the growth of paths. The de-aggregation of routes (though I have done no research to prove this) seems to me simply a response to redundancy/load distribution issues introduced by current route selection algorithms. I think we're identifying one of the symptoms, but not the root cause of the growth in routes. * It seems that we should be saying that there is a growth in paths, not _just_ routes, and path growth with current implementation methodologies and reasoning implies route growth. * We come back to "BGP only works the way most people expect it to in a multi-home situation when you de-aggregate a route from one of your upstreams and announce it all the time to all your peers." Yes, there are many other reasons that one would de-aggregate and re-announce either back into the primary with the aggregate or others; however, I think that the (obvious) basic reasoning for the bulk of path/route announcements is redundancy and load sharing. The demand for "always on" backup ("announce all the time even in directions in which you pad the path") and cost efficiency ("we're paying for that second line, so we'd better get some use out of it") lead to increase in paths that need to be visible, and thus routes that need to be visible. Why in the last year has this been so large? You've got me there, but I'll take a swing at it. Probably something to do with the collapsing prices of bandwidth, the dispersion of BGP know-how (or the "how to set up BGP for your enterprise for dummies" books/FAQs, at least,) and the sudden expectation that all Internet traffic is mission-critical and mustmustmust always be available. The bubble of hype is finally moving down the hose and causing operational issues such as this. It's the nature of the beast; as complexity grows... complexity grows. So how does this get solved? The complex solutions of multi-provider NAT are possible, but practically impossible in a business environment where FUD rules the day. This is really a matter best discussed after at least 6 hours of deep thought, which is about 5:55 short of what has occurred for this message. :) JT

4 3

RE: exponential route prefix growth, was: Re: The Cidr Report
by Sean Donelan 23 Sep '00

23 Sep '00

On Fri, 22 September 2000, John Fraizer wrote: > Who's forcing address space on customers? It's like pulling teeth to get > address space from most of them! Cable&Wireless for one. I worked with several customers who never used the /24's allocated by C&W, but even after repeatedly telling C&W we don't need them, C&W wouldn't take them back. Every circuit came with a /24 whether you needed it or not.

3 2

The Cidr Report
by Tony Bates 23 Sep '00

23 Sep '00

This is an auto-generated mail on Fri Sep 22 12:00:00 PDT 2000 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 22Sep00 0) General Status Table History ------------- Date Prefixes 150900 87093 160900 87265 170900 87208 180900 87379 190900 87348 200900 87707 210900 87719 220900 87996 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 65.0.0.0/14 from AS6172 *** Bogus 65.33.0.0/16 from AS10994 *** Bogus 65.128.0.0/14 from AS209 *** Bogus 65.132.0.0/15 from AS209 *** Bogus 65.134.0.0/17 from AS209 *** Bogus 65.134.128.0/19 from AS209 *** Bogus 65.160.0.0/15 from AS1239 *** Bogus 65.162.0.0/16 from AS1239 *** Bogus 66.1.16.0/20 from AS3847 *** Bogus 66.4.0.0/17 from AS11686 *** Bogus 66.4.0.0/15 from AS11686 *** Bogus 66.4.128.0/17 from AS11686 *** Bogus 66.6.32.0/20 from AS701 *** Bogus 66.6.64.0/20 from AS14480 *** Bogus 66.6.96.0/20 from AS10970 *** Bogus 66.6.128.0/20 from AS3561 *** Bogus 66.6.192.0/20 from AS11282 *** Bogus 66.7.0.0/19 from AS16484 *** Bogus 66.7.64.0/19 from AS14618 *** Bogus 66.9.0.0/19 from AS6221 *** Bogus 66.9.16.0/23 from AS16445 *** Bogus 66.10.0.0/20 from AS7132 *** Bogus 66.10.32.0/20 from AS7132 *** Bogus 66.16.0.0/17 from AS14914 *** Bogus 66.18.13.0/24 from AS3549 *** Bogus 66.20.128.0/22 from AS7892 *** Bogus 105.200.37.0/24 from AS9768 *** Bogus 217.0.0.0/13 from AS3320 *** Bogus 217.8.0.0/20 from AS1299 *** Bogus 217.8.32.0/20 from AS3220 *** Bogus 217.8.128.0/20 from AS15552 *** Bogus 217.8.160.0/20 from AS8246 *** Bogus 217.8.160.0/20 from AS15560 *** Bogus 217.9.32.0/20 from AS15563 *** Bogus 217.9.36.0/22 from AS15563 *** Bogus 217.9.42.0 from AS15563 *** Bogus 217.9.64.0/20 from AS3269 *** Bogus 217.9.96.0/20 from AS15671 *** Bogus 217.9.128.0/20 from AS12969 *** Bogus 217.9.160.0 from AS15606 *** Bogus 217.9.224.0/20 from AS13124 *** Bogus 217.10.0.0/20 from AS1270 *** Bogus 217.10.64.0/20 from AS15594 *** Bogus 217.10.96.0/20 from AS5556 *** Bogus 217.10.96.0/20 from AS5378 *** Bogus 217.10.160.0/23 from AS15641 *** Bogus 217.10.162.0 from AS15641 *** Bogus 217.10.192.0 from AS12302 *** Bogus 217.11.0.0/20 from AS9034 *** Bogus 217.11.64.0/20 from AS702 *** Bogus 217.11.160.0/20 from AS3259 *** Bogus 217.11.224.0/20 from AS15685 *** Bogus 217.12.0.0/20 from AS15635 *** Bogus 217.12.32.0/20 from AS5378 *** Bogus 217.12.96.0 from AS15632 *** Bogus 217.12.96.0/23 from AS15632 *** Bogus 217.12.97.0 from AS15632 *** Bogus 217.12.192.0/20 from AS15626 *** Bogus 217.12.224.0/20 from AS15438 *** Bogus 217.13.0.0/20 from AS15659 *** Bogus 217.13.32.0 from AS15629 *** Bogus 217.13.33.0 from AS15629 *** Bogus 217.13.34.0 from AS15629 *** Bogus 217.13.192.0/20 from AS9126 *** Bogus 217.13.224.0/20 from AS3220 *** Bogus 217.14.64.0/20 from AS3303 *** Bogus 217.14.96.0/23 from AS13099 *** Bogus 217.14.128.0/20 from AS8851 *** Bogus 217.14.192.0/20 from AS3226 *** Bogus 217.15.0.0/20 from AS13064 *** Bogus 217.15.128.0/20 from AS13118 *** Bogus 217.16.96.0/20 from AS15687 *** Bogus 217.32.0.0/12 from AS2856 *** Bogus 217.117.117.0 from AS2007 *** Bogus 220.10.56.0 from AS3215 AS Summary ---------- Number of ASes in routing system: 8534 Number of ASes announcing only one prefix: 4865 (2696 cidr, 2169 classful) Largest number of cidr routes: 892 announced by AS701 Largest number of classful routes: 1087 announced by AS701 1) Gains by aggregating at the origin AS level --- 22Sep00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 432 155 277 64.1% BCnet Backbone AS9706 310 104 206 66.5% Pusan Metropolitan City Office of AS1221 611 451 160 26.2% TELSTRA-AS AS9269 179 40 139 77.7% Hong Kong CTI AS816 566 429 137 24.2% UUNET Canada (ASN-UUNETCA-AS4) AS2609 128 8 120 93.8% EUnet-TN AS7657 324 211 113 34.9% The Internet Group Limited AS9304 124 17 107 86.3% Hutchcity AS7046 376 270 106 28.2% COQUI-NET PRTC Internet AS7545 159 56 103 64.8% TPG Internet Pty Ltd AS705 367 266 101 27.5% UNKNOWN AS6429 209 115 94 45.0% FirstCom Internet AS7496 125 34 91 72.8% Power Up AS4755 208 118 90 43.3% Videsh Sanchar Nigam Ltd. India AS8013 490 403 87 17.8% UNKNOWN AS174 536 450 86 16.0% Performance Systems International AS6595 138 57 81 58.7% UNKNOWN AS3908 256 176 80 31.2% Supernet, Inc. AS4293 331 252 79 23.9% Internal ASN for C&W AS724 244 168 76 31.1% UNKNOWN AS1785 384 309 75 19.5% AppliedTheory Communications AS1727 172 97 75 43.6% UNKNOWN AS577 250 177 73 29.2% Bell Backbone AS7018 581 514 67 11.5% AT&T WorldNet Service Backbone AS701 1087 1021 66 6.1% Alternet AS4792 77 11 66 85.7% SK Telecom Co., Ltd. AS13999 77 11 66 85.7% UNKNOWN AS5106 99 36 63 63.6% UNKNOWN AS3749 119 57 62 52.1% UNKNOWN AS226 170 108 62 36.5% USC/Information Sciences Institut For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

12 12

RE: exponential route prefix growth, was: Re: The Cidr Report
by Sean Donelan 23 Sep '00

23 Sep '00

On Fri, 22 September 2000, "Aaron Moreau-Cook" wrote: > up getting only one /24. Then another upstream provider, quite large, forced > another /24 upon us. When we stated we didn't need/want it, they said they > could take it back but it was not standard practice; all DS3 customers get a > /24. Anyway... Think of all the other companies out there who get treated > like this? Yes, it does seem like ARIN doesn't treat everyone the same. I had the same experience. At the same time ARIN is telling me have to to divide my customers up into /27's or ARIN won't give me any more space, a very large upstream provider was making me take a minimum of a /24 for every connection whether I needed it or not. But I couldn't aggregate the /24 into anything.

1 0

RE: exponential route prefix growth, was: Re: The Cidr Report
by Roeland M.J. Meyer 22 Sep '00

22 Sep '00

> -----Original Message----- > From: Timothy Brown [mailto:tcb@ga.prestige.net] > Sent: Friday, September 22, 2000 1:32 PM > > > What 'threshold' has triggered this sudden event, with routes going > Which sucks, because the better choice for them is to ignore > the political > concerns and do the technically responsible thing, which is > bring their > content or resources, whatever they are, closer to points in > the Internet > where they are most commonly used. There's really very > little to be gained > by announcing their own space as opposed to having a > collocation provider > with good connectivity providing them blocks out of their space. au contrare. There's LOTs to be gained. > They just come from a larger enterprise mentality where they > work very hard > to make sure all the resources are centralized and controlled > by one or two > people. The key word is "control" and the right form of responsibility is "fiscal", not "technical".

1 0

Renaissance Hotel full? (fwd)
by Carol Wadsworth 22 Sep '00

22 Sep '00

Simon, Your travel agent was unfortunately misinformed by a reservation agent. As you may know, this has been a reoccurring problem. I just confirmed the following information with each hotel noted below: --------------- Renaissance Washington D.C. Hotel Since so many people have had difficulty making room reservations at the Renaissance (the NANOG meeting site), the hotel has extended the reservation cut-off date to September 28, and has the following rooms still available in the NANOG room block: Saturday, October 21 (7 rooms) Sunday, October 22 (11 rooms) Saturday, October 23 (10 rooms) Please call the hotel directly to make/change a reservation: 202-898-9000. --------------- Marriott at Metro Center (Renaissance overflow hotel) The NANOG block of rooms at the Marriott Metro Center on Saturday night, October 21, is now booked. The hotel is currently sold out at the discounted rate. --------------- Another alternative for lodging close by that currently has some open space for $179 night: Courtyard by Marriott (two blocks from the Renaissance) 900 "F" Street Washington, D.C. Telephone: 202-638-4600 Thanks for letting me know about your problem. I would have acted on it sooner, but I was out of the office yesterday. I hope you have better luck this time trying to make a room reservation. Carol Wadsworth Merit Network, Inc. ---------- Forwarded message ---------- Date: Thu, 21 Sep 2000 15:37:44 +0100 From: Simon Lockhart <simonl(a)rd.bbc.co.uk> To: nanog(a)merit.edu Subject: Renaissance Hotel full? Hi, The Renaissance Hotel have told our travel department that they have no further rooms available in the NANOG room block, and the only remaining rooms are $279/night. Can anyone confirm this, before I book with the Marriott, who apparently do have availability for the whole week. Simon -- Simon Lockhart | Tel: +44 (0)1737 839676 Internet Engineering Manager | Fax: +44 (0)1737 839516 BBC Internet Services | Email: Simon.Lockhart(a)bbc.co.uk Kingswood Warren,Tadworth,Surrey,UK | URL: http://support.bbc.co.uk/ ---------- End Forwarded Message ----------

1 0