- Test - lists.nanog.org

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

Re: New Internet-draft on DDOS defense...
by Vipul Shah 12 May '00

12 May '00

> >Another point that hasn't been mentioned in this thread is that this type >of attack is very easy to track down, since all the echo-reply packets >will have addresses in the same subnet. A good portion of the problem >with smurf attacks is not so much the attack itself as the painful process >of tracking it to it's source. > By the time you trace the packets, identify the subnet, and convince the Network Administrator to detach the compromized system from the network, the victim's router might have crashed. Especially, when there are more than one DDoS agents are compromized over different networks, the victim site may loose several hours of business! Vipul >Brandon Ross 404-522-5400 >VP Engineering, NetRail http://www.netrail.net >AIM: BrandonNR ICQ: 2269442 >Read RFC 2644! >Stop Smurf attacks! Configure your router interfaces to block directed >broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details. > > >

2 1

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

12 May '00

Does anyone know what's happening across the pacific? root@falcon#> traceroute www.pcchips.com traceroute to www.pcchips.com (210.176.102.130), 30 hops max, 40 byte packets 1 dslnet.gw.mhsc.net (199.108.175.1) 2.777 ms 2.907 ms 2.486 ms 2 monster-paix-atm-1.dslnetworks.net (199.108.168.1) 28.128 ms 29.948 ms 33.144 ms 3 fe2-0.sjc-bb3.cerf.net (134.24.23.1) 21.246 ms 20.800 ms 21.761 ms 4 pos0-2-155M.sjc-bb2.cerf.net (134.24.29.25) 21.676 ms 21.776 ms 21.622 ms 5 pos1-1-155M.sfo-bb3.cerf.net (134.24.32.89) 23.185 ms 24.678 ms 23.141 ms 6 pos3-0-0-155M.sfo-bb1.cerf.net (134.24.29.202) 23.296 ms 22.669 ms 23.374 ms 7 atm11-0-0.BR1.SCL1.ALTER.NET (137.39.23.137) 26.055 ms 24.776 ms 25.761 ms 8 105.at-5-0-0.XR4.SCL1.ALTER.NET (152.63.48.182) 25.336 ms 25.956 ms 26.089 ms 9 152.63.51.141 (152.63.51.141) 25.685 ms 42.531 ms 26.274 ms 10 188.ATM11-0-0.GW2.PAO1.ALTER.NET (146.188.147.237) 25.532 ms 27.583 ms 26.757 ms 11 hkt-gw.customer.ALTER.NET (157.130.193.134) 29.935 ms 27.987 ms 28.247 ms 12 h2-0-0.tmhbr01.hkt.net (202.84.128.229) 439.046 ms 476.217 ms 432.080 ms 13 f1-1.tmh100.imsbiz.com (205.252.128.234) 452.217 ms 432.152 ms 463.321 ms 14 tmh103.imsbiz.com (206.161.62.7) 528.569 ms 506.871 ms 480.182 ms 15 210.176.102.158 (210.176.102.158) 4470.295 ms * 4259.799 ms 16 210.176.102.130 (210.176.102.130) 3683.300 ms 4523.936 ms 3898.093 ms --- R O E L A N D M . J . M E Y E R

2 2