- NANOG - lists.nanog.org

RE: Confussion over multi-homing
by Roeland M.J. Meyer 16 Sep '00

16 Sep '00

> There are LOTS of folks > out there that filter on the /24 boundry that your > announcement will make it through to via ISP B. I wish that this were true. But, it's false enough that you can't bet a business on it (for various thresholds of risk-tolerance/pain-avoidance).

4 6

Re: NASA (and e.root-servers.net) off the air
by Chris Yarnell 15 Sep '00

15 Sep '00

They are having major issues with DoS on one of their public networks at the moment. Unfortunately, the DoS is impacting the network equipment on which E's network resides. The issue is being worked with MSFC to get this resolved, and E will be available again ASAP. > It appears that all of NASA, including e.root-servers.net at Ames, is > off the net (and has been most of the day). I've heard something > about them having some kind of trouble at MAE-EAST and MAE-WEST; does > anybody know anything more than that?

1 0

Chicago transformer fire Wacker/Dearborn
by Sean Donelan 15 Sep '00

15 Sep '00

A fire in a tranformer vault required the Chicago fire department cutting power to three buildings 55 W. Wacker Drive (also called 222 N Dearborn), 39 N. LaSalle St. and 30 N. Clark St. http://www.chicagotribune.com/news/metro/chicago/article/0,2669,2-46923,FF.… The Ameritech NAP is a few blocks away on Randolph Street. There are several ISPs with offices and POPs in the immediate vicinity. Automobile traffic was a mess in the area, but it didn't affect any networks as far as I know.

2 1

NASA (and e.root-servers.net) off the air
by Chris Adams 15 Sep '00

15 Sep '00

It appears that all of NASA, including e.root-servers.net at Ames, is off the net (and has been most of the day). I've heard something about them having some kind of trouble at MAE-EAST and MAE-WEST; does anybody know anything more than that? -- Chris Adams <cmadams(a)hiwaay.net> Systems and Network Administrator - HiWAAY Information Services I don't speak for anybody but myself - that's enough trouble.

3 2

The Cidr Report
by Tony Bates 15 Sep '00

15 Sep '00

This is an auto-generated mail on Fri Sep 15 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 15Sep00 0) General Status Table History ------------- Date Prefixes 080900 85860 090900 85892 100900 85759 110900 86110 120900 86221 130900 87010 140900 86417 150900 87093 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.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.228.9.0/24 from AS577 *** 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.16.0.0/17 from AS14914 *** Bogus 108.122.0.0/24 from AS9847 *** 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.160.0/20 from AS8246 *** Bogus 217.8.224.0/20 from AS15560 *** Bogus 217.9.32.0/20 from AS15563 *** Bogus 217.9.36.0/22 from AS15563 *** Bogus 217.9.64.0/20 from AS3269 *** Bogus 217.9.64.0/20 from AS15671 *** Bogus 217.9.128.0/20 from AS12969 *** Bogus 217.9.160.0 from AS8308 *** 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.128.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.12.0.0/20 from AS15635 *** 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.117.117.0 from AS2007 *** Bogus 220.10.56.0 from AS3215 AS Summary ---------- Number of ASes in routing system: 8464 Number of ASes announcing only one prefix: 4814 (2667 cidr, 2147 classful) Largest number of cidr routes: 898 announced by AS701 Largest number of classful routes: 1070 announced by AS701 1) Gains by aggregating at the origin AS level --- 15Sep00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 433 153 280 64.7% BCNET-AS AS9706 258 96 162 62.8% Pusan Metropolitan City Office of AS1221 609 448 161 26.4% TELSTRA-AS AS816 575 435 140 24.3% UUNET Canada (ASN-UUNETCA-AS4) AS9269 173 47 126 72.8% Hong Kong CTI AS2609 128 8 120 93.8% EUnet-TN AS7657 318 207 111 34.9% The Internet Group Limited AS7046 370 265 105 28.4% COQUI-NET PRTC Internet AS7545 158 55 103 65.2% TPG Internet Pty Ltd AS705 365 263 102 27.9% ALTERNET-AS AS9304 117 21 96 82.1% Hutchcity AS6429 208 114 94 45.2% FirstCom Internet AS7496 126 35 91 72.2% Power Up AS4755 209 119 90 43.1% Videsh Sanchar Nigam Ltd. India AS174 533 450 83 15.6% Performance Systems International AS4293 329 249 80 24.3% Internal ASN for C&W AS3908 257 177 80 31.1% Supernet, Inc. AS6595 133 56 77 57.9% DODDSEUR AS1727 167 91 76 45.5% MRMS-WEST AS1785 386 311 75 19.4% AppliedTheory Communications AS577 251 178 73 29.1% CA-NET-AS AS3352 253 180 73 28.9% Ibernet, Internet Access Network AS724 225 154 71 31.6% DLA-ASNBLOCK-AS AS7018 582 513 69 11.9% AT&T WorldNet Service Backbone AS4792 77 11 66 85.7% SK Telecom Co., Ltd. AS5106 99 36 63 63.6% AADS-COLUMBUS AS3749 120 58 62 51.7% TECNET AS226 169 107 62 36.7% USC/Information Sciences Institut AS701 1070 1010 60 5.6% Alternet AS3602 296 240 56 18.9% Sprint Canada Inc. 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

Increase in DDOS activity
by Kevin Houle 15 Sep '00

15 Sep '00

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The CERT/CC has published an Incident Note, IN-2000-10, discussing widespread exploitation of vulnerabilities in rpc.statd and wu-ftpd. This activity is significant to network operators because we have seen an increase in DDoS tool deployment related to this activity. The Incident Note can be found at: http://www.cert.org/incident_notes/IN-2000-10.html Regards, Kevin -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQA/AwUBOcJQJ7vzUwvl02xJEQIBnACgoB5zxHv+LSmW4gc6SxqKz9J5wigAoNjX 6n85dqYLlXIya99pJwosleIF =m765 -----END PGP SIGNATURE-----

1 0

NANOG 20 & DNSSEC workshop
by Edward Lewis 15 Sep '00

15 Sep '00

For planning purposes... A while back I asked if there was interest in holding a DNSSEC workshop in conjunction with the NANOG 20 meeting. There was enough of a response to begin the planning process and we now have a room reserved. Here are the logistics for those needing to make travel arrangements. Where: Washington Marriott, 1221 22nd Street, N.W., Washington, DC 20037 (that's not the NANOG hotel - we were unable to get a room reserved there) When: Wednesday, October 25, 9am-5:30pm (more or less) Signing up: there will be a web page next week. Registration will be required, even if you have already sent me email. I will send reminders to those who have contacted be separately. Cost: $0 US What to bring: A computer (laptop) capable of running the latest BIND 9 code (see ftp://ftp.isc.org/isc/bind9/) with that code installed. Also, bring a cat 5 cable. (Wireless hasn't been decided upon yet.) As far as external Internet connectivity, nothing is promised, although we will try to provide this. ...I'd like to thank Net Soln's for arranging for the facilities. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis(a)tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer.

1 0

Re: Confussion over multi-homing
by Sean Donelan 15 Sep '00

15 Sep '00

On Thu, 14 September 2000, Brantley Jones wrote: > The problem is GETTING a /20 from anybody. We recently tried and could > only get a /23 (being a small start-up). BUT, that /23 is (apparently) > globally routable because of peering agreements with L3 and UUNET. Our /23 > prefix has yet to be filtered by anybody. It could be filtered now. You just won't find out about it until you try to reach a particular site, or they try to reach you. There is no practical way to test if an address is being "globally routed." You could try testing every address in your route table, but there is no assurance your route table is complete.

3 3

HR 4445 Reciprocal Compensation
by William Allen Simpson 15 Sep '00

15 Sep '00

"To exempt from reciprocal compensation requirements telecommunications traffic to the Internet. " Anybody know about this? Seems like it kills payments by ILECS to CLECs for dialups, when the calls are to an ISP. Note, only _TO_ an ISP; folks wanting to provide voice are still required to pay ILECs for traffic _from_ an ISP. Is this the "ILECs put ISPs out of business" act? `(A) IN GENERAL- Notwithstanding subsection (b)(5), after the date of enactment of this paragraph, no local exchange carrier shall be required to make any payment for the transport or termination of telecommunications to the Internet or any provider of Internet access service. `(B) JURISDICTION- Such transport or termination shall be considered interstate communications and subject to the exclusive jurisdiction of the Commission. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

8 8

RE: Confussion over multi-homing
by Roeland M.J. Meyer 15 Sep '00

15 Sep '00

David Lott: Thursday, September 14, 2000 10:34 AM wrote: > First, allow me to state the assumptions that I'm under. I understand > the policy to state that if a business needs to multi-home > and requires > less space than a /20, then they should request this space from their > ISP. I also understand that there are filters at the /20 > boundaries in > order to minimize the size of the routing table. > > Question: Doesn't this break multi-homing for end users that > need less > than a /20? Yep, this has been a topic here before...no real resolution. You didn't really need to prove the case, it has already been proven. The only way that you can do it is to justify a /20 or larger, get portable IP space from ARIN, and make your own peering arrangements with your upstreams. Considering that you will probably burn the best part of the /20 with distributed services, this increases your internal administration costs substantially. What you will have is a very low-density use net-block, but at least you can now multi-home and even have some geographical independence, for multiple-site use. If you have good admins, the whole thing can be folded/collapsed into about 20 physical servers, or less (Lintel boxen keep the costs low too, see: VA-Linux, about two racks). Is this wasteful of IP space? ...absolut! Is this necessary? ...sometimes. If you are building a H-Rel/Hi-Avail/Hi-Secure site(s), you ain't getting there without multi-homing with at least three providers. If you have multiple sites, you can't get there without multi-homing on an ASN that will be advertised (at least a /20, probably a /19). Do I tell clients this? ... absolut! Have I done this for clients? ... Yep, and I ain't saying who for either. --- R O E L A N D M . J . M E Y E R CEO, Morgan Hill Software Company, Inc. Managing Architect Tel: (925)373-3954 Fax: (925)373-9781 http://staff.mhsc.com/rmeyer

3 2