May 2000 - Test - lists.nanog.org

SAIC strikes again
by Sean Donelan 13 May '00

13 May '00

As NSI moves all the GTLD servers to a common platform with common software and common management, I thought I would include a quote from another SAIC project which also uses identical systems as back up. > Two servers running 17 hours a day manage the database. "If one > breaks down the other will back it up," according to SAIC Program > Manager Craig Sinclair. "The system is highly reliable." The FBI national gun buyers background check system has been out of service since Thursday.

1 0

Re: CIDR Report
by Danny McPherson 13 May '00

13 May '00

Perhaps part of the problem is this preconceived assumption that one requires portable address space and at least one unique AS number to be able to connect to the Internet in any reasonable manner, even if they're single-homed, or multi-homed to a single provider, etc.. Given, there are plenty of instances where it's indeed the optimal approach, but it's far from being the norm, even though it often seems to be evangelized as such. The other issue that folks seem to be overlooking is that while routers are indeed more capable today (in terms of route and forwarding table space and processor speeds, hardware-based forwarding and the like), there are still a number of things that could be significantly improved upon . Things that would make the Internet far more reliable as a whole, but won't be attainable if we forget about things like aggregation, reasonable justifcation for IP addresses, and address portability. For example, the fact that most large neworks (you define) don't perform any type of route prefix filtering between one another, but only at the customer ingress (if there), leaves a huge opportunity for (un)intentional unauthorized advertisement of another's routes. Think about it, right now nearly half of the root name servers could be pretty much completely taken offline by simply injecting a more-specfic advertisement for the network in which they reside into BGP. The other half, well, you could easily redirect ~half their traffic to an "alternative" location .. unless, of course, they reside within an address block which mean-old-Randy, or other networks are concerned about, then the number decreases slightly, but is still very substantial. Now, as for the actual impact this deaggregation and portability has, well: o if today I can't maintain a few 100K policy entries defining valid paths at the edges of my network o or today I have no _reliable means of determining if the source of the information is valid o or today I can't reach to the databases during policy definition time o or especially, today, can't store the polices on my BGP routers or reasonable apply them to the associated peers Well, I'd say 5 or 10 (conservative) potential additions for each new prefix should indeed be a concern. And this is just from a control plane perspective. Think about if you actually wanted to utilize those same policies to perform some type of ingress SA-based packet filtering on a per-peer basis (it could easily decrease the impact of spoofing attacks by an order of magnitude). Because of asymmetry, the packet filter can't be based on the forwarding table, it has to be based on the potential number of valid paths to the destination, and has to be performed in hardware. Now, think about the impact that 5 or 10 (conservative) potential additions for each new prefix would have on the forwarding plane. The CIDR stuff, the prefix-length filtering driven by Sean, Randy, myself and others over the years, the address portability and allocation stuff, it all feeds directly into this, and absolutely has a substantial impact. To toss it all, while forgetting about reliability and availablity, well, seems short-sighted to me. -danny

3 2

Re: Los Alamos Fire, Internet helping People......
by Sean Donelan 13 May '00

13 May '00

On Thu, 11 May 2000, "John M. Brown" wrote: > The raging fire in Los Alamos, New Mexico is devistating. 400+ homes destroyed. US West is reporting 1000+ lines with fire damage, but no major interruptions. The wildfire came within 1/2-mile of the Los Alamos central office. US West brought in water trucks for cooling and fire fighting. If you had a working computer and phone, it appears all the major and minor Internet service providers in the area maintained service.

2 1

RE: CIDR Report
by owen＠dixon.delong.sj.ca.us 13 May '00

13 May '00

> I've mentioned this before, so I'll just note it lightly. > There are a growing number of companies (dot-coms are only one of them) that have small head-count (<4000), but are spread out from Sydney to New York, with many "lone eagles" in the MST zone. They could probably do everything on a portable /24. However, with everyone filtering out announcements less than /20, such companies are encouraged to drop NAT, and use other methods to justify a /19, just so they can participate in peering (I won't say whom, one is a CTI development company). The VPN solution is cute, but the entire VP then becomes single-homed, at the VPN gateway (The alternative is that each location gets their own /24, linked by a VPN, to the other /24s, there are serious performance issues with this approach and hte /24 may only represent a single actual user). All of this burns IP addresses. > Or you build a VPN with multiple gateways, and accept the consequences when a gateway drops and you are rerouted to another gateway. This is usually rare, and most users will retry their HTTP request or other session at least once before calling for assistance. It's not pretty, but it is feasible. (Each gateway has it's own NAT pool that it exchanges with the world. Each office on the VPN is dynamically routed to the closest gateway.) > The point: Filtering BGP announcements costs in IP space allocations. There is a mathmatical relationship between IP address allocations, table sizes, and routing policies. Also, part of the relationship is determined by client business requirements. > > Organizations are becomeing more geophysically diffused, with many end-nodes actually participating in multiple organizations. This is only starting now (I still see over 100K nodes actually doing this), it will get much worse. > Yes, that is true. I think the long term solution is bigger routing tables with faster lookups and longer prefixes. CIDR was a hack to get us through a time when router memory and speed constraints were creating serious problems in routing the global internet. I believe this problem is mostly solved, and that modern routers are capable of handling a much larger routing table. As such, I think the need for optimization has shifted to IP space utilization and topological efficiency. Deaggregating routes to be able to use effective MEDs would also benefit from this going forward. I know this doesn't fit with Randy's religion, but it's not the first time I have disagreed with Randy. Owen > > -----Original Message----- > > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > > Mikael Abrahamsson > > Sent: Saturday, May 13, 2000 2:10 AM > > To: nanog(a)nanog.org > > Subject: Re: CIDR Report > > > > > > > > On Sat, 13 May 2000 pjnesser(a)Nesser.COM wrote: > > > > > But if you look at the last 250 days or so you see that the > > table has > > > grown by more than 16k routes. So we are seeing growth at > > 300% of what we > > > saw for the last 5 plus years. It also looks annoyingly > > geometric or > > > perhaps exponential, instead of the nice linear growth > > since CIDR was > > > introduced. > > > > If you just check from 01/01/99 to date then it looks linear > > or at least > > close to linear. > > > > I guess it *could* be that growing amount of new companies getting > > internet access is increasing. Is there any data that show "CIDR GAIN" > > from the cidr report, so we can see if the increase corresponds to an > > increase in (perhaps unneccessary) smaller announcements in > > larger blocks, > > or if it is actually just a lot more blocks allocated that needs to be > > routed. Any stats on arin/ripe/apnic new allocations of > > blocks in the same > > timeframe? Both in terms of IP adresses and in number of blocks of IP > > adresses. This would also give us some kind of hint as to > > when IPv4 space > > will be exhausted (or are there already projections about this?) > > > > -- > > Mikael Abrahamsson email: swmike(a)swm.pp.se > > > > >

1 0

NANOG 19 River Raft Trip - Second Announcement
by Daniel L. Golding 12 May '00

12 May '00

The Spring 2000 NANOG meeting will be held June 11-13 in Albuquerque, New Mexico. NetRail, Inc (www.netrail.net) and Riverstone Networks (www.riverstonenet.com) are hosting a special event: What: White Water Rafting Trip and Steak Dinner Cook-out URL: http://www.bigriverrafts.com/ How Much: FREE When: Saturday, June 10, 2000 - 10:00 AM (The day before NANOG begins) Where: We will pick you up at and return you to the Hyatt Regency in Albuquerque. http://www.hyatt.com/albuq/g-nano/index.html Who: The first 40 Nanogers to respond to: nanogerswww(a)netrail.net So far, the following are signed up: Dave Diller Joe Klein Maurice Dean Gwendolynn Elydyr Marc Mamane Miguel Dimayuga Kevin Epperson Steve Massey Donald Day Harold Willison Roy Wilner Phil Sykes Dan Golding Nathan Estes Scott Patterson Brian Fraine David Reale If you haven't signed up yet, please respond soon - spots are filling up. This should be a blast! - Dan Golding NetRail, Inc.

1 0

Xedia Technical Questions..
by Hallihan, Ian 12 May '00

12 May '00

Hello, I'm a new nanog member. I apologize if this is the wrong mail list but I'm looking for some helpful tips on configuring class-based queuing on a Xedia router. Can someone please point me in the right direction... Thanks, IanH Verbind Inc. 617-239-4188

1 0

The Cidr Report
by Tony Bates 12 May '00

12 May '00

This is an auto-generated mail on Fri May 12 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 12May00 0) General Status Table History ------------- Date Prefixes 080400 75151 090400 75137 100400 75215 110400 75403 120400 75730 130400 75919 010500 76182 020500 76265 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 5027 Number of ASes announcing only one prefix: 1865 (0 cidr, 1865 classful) Largest number of cidr routes: 0 announced by Largest number of classful routes: 1002 announced by AS701 1) Gains by aggregating at the origin AS level --- 12May00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 437 152 285 65.2% BCnet Backbone AS7046 500 336 164 32.8% COQUI-NET PRTC Internet AS9269 167 29 138 82.6% Hong Kong CTI AS9706 153 26 127 83.0% Pusan Metropolitan City Office of AS1221 529 408 121 22.9% TELSTRA-AS AS2609 123 18 105 85.4% EUnet-TN AS7545 164 66 98 59.8% TPG Internet Pty Ltd AS7657 264 168 96 36.4% The Internet Group Limited AS174 552 464 88 15.9% Performance Systems International AS7496 126 39 87 69.0% Power Up AS9304 109 24 85 78.0% Hutchcity AS9557 100 17 83 83.0% Pakistan Telecommunication Compan AS6429 204 121 83 40.7% RDC-INTERNET AS577 248 172 76 30.6% Bell Backbone AS7029 146 71 75 51.4% ALLTELNET AS209 463 392 71 15.3% Qwest Communications AS7018 529 463 66 12.5% AT&T WorldNet Service Backbone AS1727 162 98 64 39.5% MRMS-WEST AS4293 253 190 63 24.9% Internal ASN for C&W AS724 205 143 62 30.2% DLA-ASNBLOCK-AS AS7260 111 50 61 55.0% NORLIGHT AS705 270 209 61 22.6% ALTERNET-AS AS3749 121 61 60 49.6% TECNET AS3602 307 249 58 18.9% Sprint Canada Inc. AS6595 107 50 57 53.3% DODDSEUR AS4740 336 279 57 17.0% Ozemail Pty Ltd (ASN-OZEMAIL) AS5106 81 29 52 64.2% AADS-COLUMBUS AS7568 63 18 45 71.4% C.S. Communications Co., Ltd. AS816 308 266 42 13.6% UUNET Canada (ASN-UUNETCA-AS4) AS6528 48 6 42 87.5% WORLD-LYNX 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

1 0

Whoops!: Asia Pacific problems?
by Roeland Meyer (E-mail) 12 May '00

12 May '00

Sorry guys, this was supposd to be a private reply. > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > Roeland Meyer (E-mail) > Sent: Friday, May 12, 2000 5:04 AM > To: 'Joe Abley' > Cc: 'LIST NANOG (E-mail)' > Subject: RE: Asia Pacific problems? > > > > Hi Joe, > > I've been meaning to talk to you about IDNO stuff, when I

1 0

Contacts for ANS and CW IRRs
by Jason Lixfeld 12 May '00

12 May '00

Morning, all. Does anyone here work with or know anyone who works with the ANS or CW IRRs? We're running our own DB now which RADB is mirroring so there is no need to have objects in other RRs. I'm trying to get some objects removed that were added from upstreams many many many moons ago and am having great difficulty tracking down an administrator who can remove the objects. I managed to get the rogue RADB objects removed, and someone from BELL finally got back to me to remove the rogues from their DB. All that's left now is CW and ANS. Any help would be appreciated. Thx. Regards, -- Jason A. Lixfeld Senior Network Engineer Look Communications Inc --

1 0

Re: New Internet-draft on DDOS defense...
by owen＠dixon.delong.sj.ca.us 12 May '00

12 May '00

> >On Thu, 11 May 2000, Owen DeLong wrote: > > > >> Right answer, wrong reason. The originating host will be easy to identify > >> because the MAC address of the originating machine of the ECHO-REQUEST > >> packets will be contained in the packets. > > > >I have to strongly disagree, MAC addresses don't make it across router > >boundaries, source IP addresses do. > > Besides, MAC addresses are quite often changeable. Source IP's are even easier to modify than source MAC addresses. However, at least on a switched LAN, most switches provide some way to show the MAC forwarding table. As such, you can at least isolate which port the packets are originating from. Owen

1 0