- NANOG - lists.nanog.org

AS 2056 (AOL) access?
by nikw＠martnet.com 22 Jun '99

22 Jun '99

Does anyone happen to know how to go about obtaining (purchasing) connectivity into AOL's network (AS 2056)? I'm looking for DS3 access, to satisfy colocation/hosting customers who want to be closer to the big chunk of their customer base that lives on AOL. All of my many attempts at figuring out who to talk to have thus far been completely fruitless. Any hints would be appreciated... Nik Weidenbacher Network Engineer Sungard Network Solutions nikw(a)sgns.net nikw(a)martnet.com

1 0

getasn 0.5
by nikw＠martnet.com 21 Jun '99

21 Jun '99

I haven't seen one of these around, so I wrote one. My comments from the top of the proggie speak for themselves. #!/usr/local/bin/perl #getasn, version .5, June 1999, by N.Weidenbacher (nikw(a)martnet.com) #getasn is available from http://www.martnet.com/~nikw/getasn #The purpose of this software is to find the originating AS of the route #containing a given IP address or hostname, and to do so in a fun and #exciting way! That is, you type "getasn www.cisco.com" and you get #the ASN-CISCO record from the ARIN registry. Needless to say, this #software is not well-tested at all. #This software requires the perl Expect module, obtainable from CPAN #(ftp://ftp.cdrom.com/pub/perl/CPAN), or more specifically, #ftp://ftp.cdrom.com/pub/perl/CPAN/modules/by-module/Expect. Expect, in #turn, requires IO::Stty, available from #ftp://ftp.cdrom.com/pub/perl/CPAN/modules/by-module/IO #getasn requires an internet connection for three reason. #1) It may need to do a DNS lookup if you supply a name #2) It needs to telnet to route-views to get a BGP4 route #3) It needs to whois to rs.arin.net to look up the ASN. #getasn has only been tested on Solaris 2.7, but it should work pretty well #on most unixes whose "host" command produces output similar to Solaris's #"host". This is a direct result of my lameness. -nikw

1 0

revised ACL 112 ?
by Philippe Strauss 21 Jun '99

21 Jun '99

Hi nanogers, Recently (today :) I've been playing with configuring Sean ACL 112 on our transit BGP router. I'm surprised by the number of routes which have been dropped, especialy in the 206.0.0.0/7 range. The exact access list is the one Sean described on this list in 1995, available at http://www.ianai.net/filters/Sprint-ACL112 Here are the result: Before: Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 144.85.0.5 4 6893 42 30 687201 0 0 00:22:52 13 194.38.74.206 4 6776 28 37 687201 0 0 00:24:54 21 194.38.74.214 4 65501 26 27 687202 0 0 00:22:15 2 194.38.74.218 4 65402 0 0 0 0 0 never Idle (Admin) 194.148.254.253 4 3334 28 30 687162 0 0 00:23:04 2 195.89.0.85 4 5378 22567 26 687202 0 0 00:20:38 59045 195.141.225.1 4 6730 22398 15 687202 0 0 00:09:00 62345 195.202.192.33 4 8493 1040 1042 687202 0 0 17:17:48 0 195.202.192.41 4 8493 1040 1042 687202 0 0 17:17:53 0 195.202.192.77 4 8493 1040 1042 687202 0 0 17:17:48 0 195.202.192.117 4 8493 89 91 687202 0 0 01:26:17 0 Right after (clear ip bgp (5378|6730) soft in): Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 144.85.0.5 4 6893 45 33 749634 0 0 00:25:43 13 194.38.74.206 4 6776 31 40 749634 0 0 00:27:45 21 194.38.74.214 4 65501 28 30 749634 1 0 00:25:06 2 194.38.74.218 4 65402 0 0 0 0 0 never Idle (Admin) 194.148.254.253 4 3334 30 32 687372 0 0 00:25:56 2 195.89.0.85 4 5378 22669 29 687372 1 0 00:23:30 41236 195.141.225.1 4 6730 22452 17 687372 14 0 00:11:52 42188 195.202.192.33 4 8493 1043 1045 749634 0 0 17:20:40 0 195.202.192.41 4 8493 1043 1045 749634 0 0 17:20:44 0 195.202.192.77 4 8493 1043 1045 749634 0 0 17:20:40 0 195.202.192.117 4 8493 92 94 749634 0 0 01:29:09 0 lsne-br1#sh access-lists 199 Extended IP access list 199 permit ip 192.0.0.0 13.255.255.255 0.0.0.0 255.255.255.0 (35236 matches) permit ip 194.0.0.0 9.255.255.255 0.0.0.0 255.255.255.0 (20987 matches) permit ip 198.0.0.0 1.255.255.255 0.0.0.0 255.255.255.0 (15285 matches) permit ip 206.0.0.0 0.255.255.255 0.0.0.0 255.255.224.0 (894 matches) permit ip 206.0.0.0 1.255.255.255 0.0.0.0 255.255.192.0 (611 matches) permit ip 224.0.0.0 15.255.255.255 0.0.0.0 255.255.192.0 permit ip 128.0.0.0 63.255.255.255 0.0.0.0 255.255.0.0 (10520 matches) permit ip 1.0.0.0 126.0.0.0 0.0.0.0 255.0.0.0 (20 matches) permit ip 2.0.0.0 125.0.0.0 0.0.0.0 255.0.0.0 (6 matches) permit ip 4.0.0.0 123.0.0.0 0.0.0.0 255.0.0.0 (10 matches) permit ip 8.0.0.0 119.0.0.0 0.0.0.0 255.0.0.0 (2 matches) permit ip 16.0.0.0 111.0.0.0 0.0.0.0 255.0.0.0 (2 matches) permit ip 32.0.0.0 95.0.0.0 0.0.0.0 255.0.0.0 (2 matches) permit ip 64.0.0.0 63.0.0.0 0.0.0.0 255.0.0.0 permit ip 9.2.0.0 0.0.255.255 host 255.255.0.0 (2 matches) permit ip 9.20.0.0 0.0.255.255 host 255.255.192.0 permit ip 39.0.0.0 0.255.255.255 0.0.0.0 255.255.255.0 deny ip 0.0.0.0 127.255.255.255 0.128.0.0 255.127.255.255 (1458 matches) deny ip 0.0.0.0 127.255.255.255 0.64.0.0 255.191.255.255 deny ip 0.0.0.0 127.255.255.255 0.32.0.0 255.223.255.255 deny ip 0.0.0.0 127.255.255.255 0.16.0.0 255.239.255.255 deny ip 0.0.0.0 127.255.255.255 0.8.0.0 255.247.255.255 deny ip 0.0.0.0 127.255.255.255 0.4.0.0 255.251.255.255 deny ip 0.0.0.0 127.255.255.255 0.2.0.0 255.253.255.255 deny ip 0.0.0.0 127.255.255.255 0.1.0.0 255.254.255.255 deny ip 0.0.0.0 127.255.255.255 0.0.0.0 255.255.0.0 deny ip 0.0.0.0 191.255.255.255 0.0.128.0 255.255.127.255 (4635 matches) deny ip 0.0.0.0 191.255.255.255 0.0.64.0 255.255.191.255 deny ip 0.0.0.0 191.255.255.255 0.0.32.0 255.255.223.255 deny ip 0.0.0.0 191.255.255.255 0.0.16.0 255.255.239.255 deny ip 0.0.0.0 191.255.255.255 0.0.8.0 255.255.247.255 deny ip 0.0.0.0 191.255.255.255 0.0.4.0 255.255.251.255 deny ip 0.0.0.0 191.255.255.255 0.0.2.0 255.255.253.255 deny ip 0.0.0.0 191.255.255.255 0.0.1.0 255.255.254.255 deny ip 206.0.0.0 1.255.255.255 0.0.32.0 255.255.223.255 (12062 matches) deny ip 206.0.0.0 1.255.255.255 0.0.16.0 255.255.239.255 deny ip 206.0.0.0 1.255.255.255 0.0.8.0 255.255.247.255 deny ip 206.0.0.0 1.255.255.255 0.0.4.0 255.255.251.255 deny ip 206.0.0.0 1.255.255.255 0.0.2.0 255.255.253.255 deny ip 206.0.0.0 1.255.255.255 0.0.1.0 255.255.254.255 deny ip 224.0.0.0 15.255.255.255 0.0.32.0 255.255.223.255 deny ip 224.0.0.0 15.255.255.255 0.0.16.0 255.255.239.255 deny ip 224.0.0.0 15.255.255.255 0.0.8.0 255.255.247.255 deny ip 224.0.0.0 15.255.255.255 0.0.4.0 255.255.251.255 deny ip 224.0.0.0 15.255.255.255 0.0.2.0 255.255.253.255 deny ip 224.0.0.0 15.255.255.255 0.0.1.0 255.255.254.255 deny ip any host 255.255.255.0 (9567 matches) deny ip any 0.0.0.128 255.255.255.127 (335 matches) deny ip any 0.0.0.64 255.255.255.191 deny ip any 0.0.0.32 255.255.255.223 deny ip any 0.0.0.16 255.255.255.239 deny ip any 0.0.0.8 255.255.255.247 deny ip any 0.0.0.4 255.255.255.251 deny ip any 0.0.0.2 255.255.255.253 deny ip any 0.0.0.1 255.255.255.252 deny ip 240.0.0.0 15.255.255.255 any deny ip 0.0.0.0 0.255.255.255 any After reverting order of specific bit masking: Right after (clear ip bgp (5378|6730) soft in).. Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 144.85.0.5 4 6893 378 366 808741 0 0 05:56:23 88 194.38.74.206 4 6776 364 383 808741 0 0 05:58:25 21 194.38.74.214 4 65501 359 360 808741 0 0 05:55:46 2 194.38.74.218 4 65402 0 0 0 0 0 never Idle (Admin) 194.148.254.253 4 3334 361 377 808741 0 0 05:56:36 2 195.89.0.85 4 5378 81719 362 808741 0 0 05:54:09 40707 195.141.225.1 4 6730 31911 350 808741 0 0 05:42:32 42273 195.202.192.33 4 8493 1374 1376 809317 0 0 22:51:19 0 195.202.192.41 4 8493 1374 1376 809317 0 0 22:51:24 0 195.202.192.77 4 8493 1374 1376 809317 0 0 22:51:19 0 195.202.192.117 4 8493 422 424 809317 0 0 06:59:48 0 lsne-br1#sh access-lists 199 Extended IP access list 199 permit ip 192.0.0.0 13.255.255.255 0.0.0.0 255.255.255.0 (35360 matches) permit ip 194.0.0.0 9.255.255.255 0.0.0.0 255.255.255.0 (23838 matches) permit ip 198.0.0.0 1.255.255.255 0.0.0.0 255.255.255.0 (15257 matches) permit ip 206.0.0.0 0.255.255.255 0.0.0.0 255.255.224.0 (894 matches) permit ip 206.0.0.0 1.255.255.255 0.0.0.0 255.255.192.0 (612 matches) permit ip 224.0.0.0 15.255.255.255 0.0.0.0 255.255.192.0 permit ip 128.0.0.0 63.255.255.255 0.0.0.0 255.255.0.0 (10540 matches) permit ip 1.0.0.0 126.0.0.0 0.0.0.0 255.0.0.0 (20 matches) permit ip 2.0.0.0 125.0.0.0 0.0.0.0 255.0.0.0 (6 matches) permit ip 4.0.0.0 123.0.0.0 0.0.0.0 255.0.0.0 (10 matches) permit ip 8.0.0.0 119.0.0.0 0.0.0.0 255.0.0.0 (2 matches) permit ip 16.0.0.0 111.0.0.0 0.0.0.0 255.0.0.0 (2 matches) permit ip 32.0.0.0 95.0.0.0 0.0.0.0 255.0.0.0 (2 matches) permit ip 64.0.0.0 63.0.0.0 0.0.0.0 255.0.0.0 permit ip 9.2.0.0 0.0.255.255 host 255.255.0.0 (2 matches) permit ip 9.20.0.0 0.0.255.255 host 255.255.192.0 permit ip 39.0.0.0 0.255.255.255 0.0.0.0 255.255.255.0 deny ip 0.0.0.0 127.255.255.255 0.1.0.0 255.254.255.255 (1434 matches) means that ~700 networks in the old A class are announced /15 deny ip 0.0.0.0 127.255.255.255 0.2.0.0 255.253.255.255 (12 matches) deny ip 0.0.0.0 127.255.255.255 0.4.0.0 255.251.255.255 (6 matches) deny ip 0.0.0.0 127.255.255.255 0.8.0.0 255.247.255.255 (6 matches) deny ip 0.0.0.0 127.255.255.255 0.16.0.0 255.239.255.255 deny ip 0.0.0.0 127.255.255.255 0.32.0.0 255.223.255.255 deny ip 0.0.0.0 127.255.255.255 0.64.0.0 255.191.255.255 deny ip 0.0.0.0 127.255.255.255 0.128.0.0 255.127.255.255 (4 matches) deny ip 0.0.0.0 127.255.255.255 0.0.0.0 255.255.0.0 deny ip 0.0.0.0 191.255.255.255 0.0.1.0 255.255.254.255 (2946 matches) ~1500 networks in the old B class are announced /23 deny ip 0.0.0.0 191.255.255.255 0.0.2.0 255.255.253.255 (656 matches) deny ip 0.0.0.0 191.255.255.255 0.0.4.0 255.255.251.255 (281 matches) deny ip 0.0.0.0 191.255.255.255 0.0.8.0 255.255.247.255 (156 matches) deny ip 0.0.0.0 191.255.255.255 0.0.16.0 255.255.239.255 (170 matches) deny ip 0.0.0.0 191.255.255.255 0.0.32.0 255.255.223.255 (205 matches) deny ip 0.0.0.0 191.255.255.255 0.0.64.0 255.255.191.255 (123 matches) deny ip 0.0.0.0 191.255.255.255 0.0.128.0 255.255.127.255 (147 matches) deny ip 206.0.0.0 1.255.255.255 0.0.1.0 255.255.254.255 (7752 matches) ~3800 nets announced /23 in the supposedely /18 allocated old C space deny ip 206.0.0.0 1.255.255.255 0.0.2.0 255.255.253.255 (1379 matches) deny ip 206.0.0.0 1.255.255.255 0.0.4.0 255.255.251.255 (1047 matches) deny ip 206.0.0.0 1.255.255.255 0.0.8.0 255.255.247.255 (770 matches) deny ip 206.0.0.0 1.255.255.255 0.0.16.0 255.255.239.255 (676 matches) deny ip 206.0.0.0 1.255.255.255 0.0.32.0 255.255.223.255 (422 matches) deny ip 224.0.0.0 15.255.255.255 0.0.1.0 255.255.254.255 deny ip 224.0.0.0 15.255.255.255 0.0.2.0 255.255.253.255 deny ip 224.0.0.0 15.255.255.255 0.0.4.0 255.255.251.255 deny ip 224.0.0.0 15.255.255.255 0.0.8.0 255.255.247.255 deny ip 224.0.0.0 15.255.255.255 0.0.16.0 255.255.239.255 deny ip 224.0.0.0 15.255.255.255 0.0.32.0 255.255.223.255 deny ip any host 255.255.255.0 (9611 matches) deny ip any 0.0.0.1 255.255.255.252 deny ip any 0.0.0.2 255.255.255.253 (18 matches) deny ip any 0.0.0.4 255.255.255.251 (28 matches) deny ip any 0.0.0.8 255.255.255.247 (22 matches) deny ip any 0.0.0.16 255.255.255.239 (53 matches) deny ip any 0.0.0.32 255.255.255.223 (102 matches) deny ip any 0.0.0.64 255.255.255.191 (92 matches) deny ip any 0.0.0.128 255.255.255.127 (45 matches) deny ip 240.0.0.0 15.255.255.255 any deny ip 0.0.0.0 0.255.255.255 any I know that some old unused A classe were being reallocated CIDR. Don't know much about anything else. Also, old 1995 ACL112 doesn't consider europeean allocation policy (194/8 at /24, 195/8 at /20 for example), while today sprint filtering policy take this into consideration. Anyone clueful on this topic? Is old 1995 ACL112 way to restrictive? or ISP behavior really really bad (RAM is cheap nowadays.. except cisco RAM :-) TIA, cheers. -- Philippe Strauss, ingenieur reseau/systemes, Urbanet SA philippe.strauss(a)urbanet.ch tel +41 21 623 30 20 --

4 6

[semi-non-op] 9netave junk fax
by John R Levine 20 Jun '99

20 Jun '99

I gather than 9netave, a web hosting company in New Jersey, sent out last week large numbers of junk faxes to numbers scraped from WHOIS. I certainly got one, even though my listing says "NO FAX ADS $500 PENALTY". As you probably know, junk faxes are both unethical and illegal. You can sue for up to $1500 per junk fax under 47 USC 227. A friend and I are trying to put together a group suit to encourage them not to try steal customers that way. If you got one of these and still have it, please email either me or Ray Everett-Church, ray(a)everett.org. Regards, John Levine, johnl(a)iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner Finger for PGP key, f'print = 3A 5B D0 3F D9 A0 6A A4 2D AC 1E 9E A6 36 A3 47

2 1

Y2K tests and problems
by Sean Donelan 19 Jun '99

19 Jun '99

The San Fernando Valley sewage spill during a Y2K test in news reports was traced to a 1985 programmer mistake in the code. What combination of events tickled the bug, and why nothing at the plant alerted operators to the problem is still being investigated. In the Internet world, NSI announced on Friday their Y2K test program for domain name servers. If you choose to participate, I noticed NSI plans to use NTP for clock synchronization. One problem which has shown up in other Y2K tests is failing to keep the NTP test network properly isolated from the NTP production network. With correct stratum settings and a good NTP web, if the test and production networks are accidently connected, NTP figures out someone's clock is insane. However, in a few cases NTP on a production machine which isn't properly isolated will synchronize with the test NTP network, e.g. if a machine reboots, and uses a NTP broadcast to set its clock when booting. Unlike the financial industry which can do testing on the weekends, when few real transactions are in the system, the Internet is a 24x7 network. So be careful out there. http://biz.yahoo.com/bw/990618/va_network_2.html http://www.root2000.com/ -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

The Cidr Report
by Tony Bates 18 Jun '99

18 Jun '99

This is an auto-generated mail on Fri Jun 18 12:00:00 PDT 1999 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 18Jun99 0) General Status Table History ------------- Date Prefixes 110699 59966 120699 59973 130699 59896 140699 60007 150699 60030 160699 60041 170699 60131 180699 60164 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: 3790 Number of ASes announcing only one prefix: 1523 (344 cidr, 1179 classful) Largest number of cidr routes: 79 announced by AS2652 Largest number of classful routes: 811 announced by AS701 1) Gains by aggregating at the origin AS level --- 18Jun99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 350 148 202 57.7% BCnet Backbone AS4293 255 150 105 41.2% IMCI AS577 280 187 93 33.2% Bell Canada Backbone AS174 582 490 92 15.8% Performance Systems International AS7046 318 240 78 24.5% UUNET-CUSTOMER AS4200 179 101 78 43.6% AGIS (Apex Global Information Ser AS3749 137 63 74 54.0% TECNET AS7545 128 62 66 51.6% TPG Internet Pty Ltd AS7496 98 32 66 67.3% Power Up AS7122 139 78 61 43.9% MTS ADVANCED Network Policy AS1221 452 392 60 13.3% TELSTRA-AS AS1239 540 481 59 10.9% SprintLink Backbone AS4755 134 76 58 43.3% Videsh Sanchar Nigam Ltd. India AS9269 66 9 57 86.4% Hong Kong CTI AS7657 184 127 57 31.0% The Internet Group Limited AS72 95 39 56 58.9% Schlumberger Information Network AS4740 317 261 56 17.7% Ozemail Pty Ltd (ASN-OZEMAIL) AS10928 99 45 54 54.5% UNKNOWN AS2493 171 118 53 31.0% iSTAR Internet, Inc. AS719 462 410 52 11.3% LANLINK autonomous system AS3737 159 110 49 30.8% PenTeleData Inc. (ASN-PTD) AS549 222 178 44 19.8% ONet Backbone AS803 73 37 36 49.3% SaskNet Backbone AS3549 154 119 35 22.7% Frontier GlobalCenter AS6944 37 3 34 91.9% RapidSite, Inc. AS6172 153 119 34 22.2% HOME-NET-1 AS1 478 444 34 7.1% BBNPLANET AS1785 246 214 32 13.0% NYSERNet Backbone AS11515 32 1 31 96.9% UNKNOWN AS10479 36 5 31 86.1% ITESM-Rectoria Zona Norte 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

statistics and tool query (fwd)
by Abha Ahuja 18 Jun '99

18 Jun '99

Hi All! I've gotten a bunch of responses from people about the tools they are using - Thanks Everyone. I've also gotten a ton of responses from people who expressed an interest in the results, so I'll post a summary to the list. Anyone else have any feedback on tools, etc? I'd love to hear more! Thanks again! -abha ;) __________________________________________________________________________ -------------------------------------------------------------------------- abha ahuja ahuja(a)merit.edu Merit Network, Inc. 734.764.0294 ---------- Forwarded message ---------- Date: Thu, 17 Jun 1999 18:56:54 -0400 (EDT) From: Abha Ahuja <ahuja(a)merit.edu> To: nanog(a)merit.edu Subject: statistics and tool query Hey all! I'm trying to get a feeling for what ISPs are using for statistics, measurement, router configs, traffic engineering, network management, etc. and other tools... What you wished you had, what you are using now... That sort of thing. (I think Randy sent out a ping like this a couple of years ago)... I'd appreciate any info people can provide. It would be most useful for some of my work, etc. Please respond to me privately... I can post an anonymized summary to the list if people are interested... Thanks! -abha ;) __________________________________________________________________________ -------------------------------------------------------------------------- abha ahuja ahuja(a)merit.edu Merit Network, Inc. 734.764.0294

1 0

Re: Fatty Pipes with Y2K problem - OT humor
by Sean Donelan 18 Jun '99

18 Jun '99

rjoffe(a)centergate.COM (Rodney Joffe) writes: >We have had a significant pipe problem at our Sherman Oaks facility in >Los Angeles as a result of a Y2K test failure :-) The staff is currently >off-line recovering! Seriously. > >Sean, one for your book :-) > >http://www.cbs2.com/news/stories/news-990617-081237.html I smell a problem :-) But hardly the first. The best one I've heard so far was the entire country of Fiji went off-line a few weeks ago when the telco was conducting their Y2K test. Even if you think everything will work correctly, having a contigency plan is still a good idea. BTW, President Clinton signed an executive order setting up the US Y2K coordination center I spoke about at NANOG this week. But guess what, the vendor of the conference bridge the NCS uses doesn't have a Y2K readiness statement on their web page. And speaking of that, to bring this on topic: NOC communications, and communicating during contigency operations. During the recent virus/worm scare an old problem has re-appeared. For a variety of reasons some organizations feel the best response to these virus/worms is to pull up the drawbridges and shut-off their network connections each time a new one makes the rounds. This also happened during the "Morris" Worm ten years ago, and one of the reasons why BBN was tasked with creating the Network Manager's Phonebook. I can't ask you to go against your corporate security people. But consider planning how to keep a NOC contact up and running when you feel you must disconnect the rest of your corporate or agency network. If you pull the plug on your main (only?) mail server, how do you redirect your NOC mail? The government backbone networks seemed to do this more than commercial networks, but the principle applies to both. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

statistics and tool query
by Abha Ahuja 18 Jun '99

18 Jun '99

Hey all! I'm trying to get a feeling for what ISPs are using for statistics, measurement, router configs, traffic engineering, network management, etc. and other tools... What you wished you had, what you are using now... That sort of thing. (I think Randy sent out a ping like this a couple of years ago)... I'd appreciate any info people can provide. It would be most useful for some of my work, etc. Please respond to me privately... I can post an anonymized summary to the list if people are interested... Thanks! -abha ;) __________________________________________________________________________ -------------------------------------------------------------------------- abha ahuja ahuja(a)merit.edu Merit Network, Inc. 734.764.0294

2 1

Re: revised ACL 112 ?
by Michael P. Lucking 18 Jun '99

18 Jun '99

It might be policy, but I don't believe it to be practice. I have no problem reaching Verio from our /20 block. Oddly enough Verio (AS 2914) is advertising several /20 netblocks out of 206/8. Even more specific they are advertising as small as a /23 from 206/8. Further, they provide transit for customers advertising /24s. It might be possible that someone at Verio is not applying their policy, if one does indeed exist. Anyone from Verio care to comment? On Thu, 17 Jun 1999, Mark Cobb wrote: > I believe that some agencies, such as Verio and Expedia are filtering out > anything longer than /19. In fact, I know that Verio is and they said that they > would not change this policy. ARIN changed the policy, but RIPE and APNIC have > not; this is their excuse for not changing their policies. > > > "Michael P. Lucking" wrote: > > > In February we received a new /20 CIDR from ARIN. I felt that we might be > > caught by the filters at ISPs like Sprint (http://www.sprint.net/filter.htm) > > I contacted Sprint twice and spoke to two different engineers, both told > > me that they were not filtering as their page described, and they would > > allow advertisements for /20 in 206/8 - 233/8. Since that time I have > > spoken to several people who purchase transit from Sprint, and they do > > indeed see my advertisements. Looking at NetFlow stats I can't find any > > major provider that we have not had traffic flow between. I assume they > > had to have accepted my advertisements, nobody runs BGP and default routes > > :). > > > > BTW: I also contacted, and received a similar response from ANS. > > ========================================================================= Michael P. Lucking Michael(a)Lucking.COM

1 0