- NANOG - lists.nanog.org

The Cidr Report
by Tony Bates 21 Mar '01

21 Mar '01

This is an auto-generated mail on Fri Mar 16 23:00:00 PST 2001 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 16Mar01 0) General Status Table History ------------- Date Prefixes 090301 98107 100301 97522 110301 97508 120301 97530 130301 97798 140301 98013 150301 98259 160301 97900 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 91.16.23.0/24 from AS11770 AS Summary ---------- Number of ASes in routing system: 10240 Number of ASes announcing only one prefix: 6004 (3405 cidr, 2599 classful) Largest number of cidr routes: 957 announced by AS701 Largest number of classful routes: 1594 announced by AS1221 1) Gains by aggregating at the origin AS level --- 16Mar01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1594 1194 400 25.1% Telstra Pty Ltd AS701 1417 1256 161 11.4% UUNET Technologies, Inc. AS6499 170 60 110 64.7% Brooks Fiber Properties, Inc. AS9269 162 53 109 67.3% Internet service Provider in Hong AS6429 212 107 105 49.5% RdC Internet AS6595 161 62 99 61.5% DoD Education Activity Network As AS7545 169 76 93 55.0% TPG Internet Pty Ltd AS705 329 237 92 28.0% UUNET Technologies, Inc. AS4293 376 285 91 24.2% Cable & Wireless USA AS13999 102 11 91 89.2% Mega Cable S.A. de C.V. AS8013 326 242 84 25.8% PSINet Ltd. Canada AS7018 654 575 79 12.1% AT&T AS4151 226 148 78 34.5% USDA AS4755 207 133 74 35.7% Videsh Sanchar Nigam Ltd. Autonom AS577 239 169 70 29.3% Bell Advanced Communications Inc. AS724 222 155 67 30.2% DLA Systems Automation Center AS174 495 428 67 13.5% PSINet Inc. AS9498 83 18 65 78.3% BHARTI BT INTERNET LTD. AS5106 101 37 64 63.4% Ameritech Advanced Data Services, AS11170 64 1 63 98.4% Bewell Net AS3749 120 59 61 50.8% Tennessee Board of Regents AS3464 153 92 61 39.9% Alabama SuperComputer Network AS7657 163 103 60 36.8% The Internet Group Limited AS16758 63 6 57 90.5% IKON Office Solutions AS6413 67 11 56 83.6% Southern Online Systems, Inc. AS4323 233 177 56 24.0% Time Warner Communications, Inc. AS376 133 77 56 42.1% Reseau Interordinateurs Scientiqu AS226 149 93 56 37.6% Los Nettos AS1 605 550 55 9.1% BBN Planet AS6471 99 46 53 53.5% ENTEL CHILE S.A. 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

3 2

Secure multi-homing Internet Access
by Martin Picard 21 Mar '01

21 Mar '01

Hi all, Due to may different factors, including different filtering policies, mutli-homing to different providers might not provide the same Internet view, or even reachability. Default-routing to the upstream ISPs therefore seems not to be the way to go. Instead full BGP tables can be kept on the enterprise border routers and default routes can be originated on these border routers and injected in the enterprise IGP. iBGP is used between the enterprise border routers. From any router in the enterprise network, the IGP metric is used to get to the nearest border router, and then, the best BGP route is selected, which could very well be on one of its iBGP peers. Therefore traffic can flow from any router to Border1, then Border2, then the upstream ISP router. (Assuming there is a direct path between Border1 and Border2 (tunnels, MPLS-LSP, etc)). Everything's fine (at least I think so) until we throw in some Firewalls !!! They either ought to be on the eBGP path or on the iBGP path. That is between the enterprise border router and the upstream ISP router or between the enterprise border router and the enterprise network. Putting the firewall on the iBGP path can lead to routing loops since the firewall will only have a default route to the local border router. When putting the firewall on the eBGP path, it defaults to its outside interface toward the upstream ISP router and has the enterprise address block on its inside interface. So far so good, but that means that the upstream ISP media type has to be supported by the firewall: oc3, oc12 !!!! ;-( And in any case the firewall has to provide proper throughput !!! ;-( How are large enterprise implementing secure multi-home internet access ? And to what type of bandwidth does this scale ? tx martin

1 0

RE: AOL holes again.
by Roeland Meyer 21 Mar '01

21 Mar '01

How many businesses use AOL? Most AOLers are consumers and their kids. They don't have the same service expectations. > -----Original Message----- > From: M. David Leonard [mailto:mdl@equinox.shaysnet.com] > Sent: Tuesday, March 20, 2001 1:42 PM > > Peter- > > This is nothing new - AOL was silently discarding e-mail a year > ago. What's worse, when I contacted them I was told that > they have an > automated system *which does NOT generate reports for the human > postmasters* so the staff does not know what domains are > being blackholed > without grepping through the logs on scores of SMTP servers. > I find it > difficult to believe that anyone could run a business like > that but, hey, > they seem to have a lot of customers who either don't care if > e-mail gets > through or don't know how much AOL loses for them. > > > David Leonard > ShaysNet > > > On Tue, 20 Mar 2001, Peter van Dijk wrote: > > > > > On Tue, Mar 20, 2001 at 01:36:02PM -0500, ken harris. wrote: > > > >If the MSNBC article is anywhere near correct (yeah, a > big assumption) then > > > >what AOL was doing was black-holing any "high-volume" > source. While that > > > >is a noble goal, the fact that any mailing list would > fall into that > > > >category is pretty lame. > > > > > > http://members.aol.com/adamkb/aol/mailfaq/dropped-mail.html#lists > > > > This basically means AOL is violating the very spirit of SMTP - you > > say '250 message accepted', and you deliver it to all recipients you > > specified acceptance for, or produce bounces. > > > > Greetz, Peter. > > > > >

9 10

AOL holes again.
by Alan Clegg 20 Mar '01

20 Mar '01

I run mailinglists.org a non-profitable mailing list server. Several people have complained to me over the last few days about people on various lists not getting mail. The only common thread was that the users were on AOL. Contacting AOL did no good, as it was always a "problem with the list server". Well, it turns out that it is a problem with AOL that NANOG folks might be interested in: http://www.msnbc.com/news/546689.asp?0nm=C14R&cp1=1 Now, since AOL told everyone that *MY* service was faulty, what can I do? *SIGH* AlanC -- perl -le '$_="6110>374086;2064208213:90<307;55";tr[0->][ LEOR\!AUBGNSTY];print' abc(a)bsdi.com

8 8

RE: AOL holes again.
by Richard Welty 20 Mar '01

20 Mar '01

> That may be the case, but the fix is not to put any server > that generates > "lots of mail" into the bitbucket. I've been getting > complaints from a > number of list members (no spam or relaying from mailinglists.org, I > promise) that folks on AOL suddenly stopped getting the > majority of their > list mail. i suggest not jumping to any conclusions here. i run digest.net, a smallish not-very-profitable electronic mailing list host, and i observed similar dropouts, but discovered that my reverse DNS lookups were broken, and AOL's current policy is to reject email from hosts for which reverse DNS isn't working properly. richard

1 0

FTP exploit?
by Clayton Fiske 20 Mar '01

20 Mar '01

Is there a (fairly) recent exploit for common ftp daemons going around lately? In the past several days, I've seen a very noticeable jump in the number of people attempting anonymous ftp logins. Typically I noticed it once or twice a week, and usually single attempts, but now they're coming in every few hours and they each make 4 attempts within a second (which is one per IP bound to the box I'm watching). It looks like it has to be some kind of script. Anyone else seeing any noticeable increases like this? -c

5 4

Re: Is www.cisco.com down?
by Richard A. Steenbergen 20 Mar '01

20 Mar '01

On Mon, Mar 19, 2001 at 11:15:59PM -0500, Kent Yu wrote: > route-server>tr 198.133.219.25 Ok, lets get with the program here. Is this topic really worth the reading time of 1,000 network engineers (and the 3 spammers who keep posting)? Do you really expect a useful answer? Cisco probably has 10 people who's only job is to click refresh on the webpage just to make sure it's up. Please, the DNS thread is bad enough without this noise. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

Is www.cisco.com down?
by Kent Yu 20 Mar '01

20 Mar '01

route-server>tr 198.133.219.25 Type escape sequence to abort. Tracing the route to www.cisco.com (198.133.219.25) 1 white_dwarf.cbbtier3.att.net (12.0.1.1) [AS 7018] 4 msec 0 msec 0 msec 2 ar3.n54ny.ip.att.net (12.126.0.30) [AS 7018] 4 msec 4 msec 4 msec 3 gbr2-a30s2.n54ny.ip.att.net (12.127.0.26) [AS 7018] 4 msec 4 msec 4 msec 4 gbr3-p00.n54ny.ip.att.net (12.122.5.246) [AS 7018] 4 msec 4 msec 0 msec 5 gbr3-p30.cgcil.ip.att.net (12.122.2.173) [AS 7018] 24 msec 24 msec 20 msec 6 gbr3-p30.sffca.ip.att.net (12.122.2.150) [AS 7018] 64 msec 60 msec 60 msec 7 gbr2-p60.sffca.ip.att.net (12.122.5.253) [AS 7018] 60 msec 60 msec 68 msec 8 ar4-a3120s3.sffca.ip.att.net (12.123.12.101) [AS 7018] 68 msec 68 msec 60 ms ec 9 12.126.204.58 [AS 7018] 64 msec 60 msec 60 msec 10 pigpen.cisco.com (128.107.240.166) [AS 109] 60 msec 64 msec 64 msec 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * Kent Yu

1 0

California rolling blackouts - March edition
by Sean Donelan 20 Mar '01

20 Mar '01

Rolling blackouts are back in California. Starting about 11:45am PST, CA-ISO requested utilities start shedding approximately 500 to 1000 MW. Involuntary load curtailment is expected to continue through the evening. 11,500 MW of power production was unavailable due to planned and unplanned maintenance. An additional 1,000 MW of power product was lost this morning when a transformer fire knocked two plants off-line in Southern California. A couple of colocation and Internet service providers reported they were operating on backup generators for 60-90 minutes as their power blocks were affected. No customer loads were reportedly dropped. Sun Microsystems reported loss of power at a manufacturing facility for two hours. PG&E is rezoning those blocks "exempted" from rolling blackouts beinging this month. Some customers previously identified as being in an exempt block are being moved since they aren't sharing a circuit with a critical facility. Likewise, some circuits not identified as serving critical facilities are now exempt because a critical facility is on the circuit. Critical facility means a hospital, emergency operations center, etc.

1 0

RE: Multiple Roots are "a good thing" - Karl Auerbach
by Roeland Meyer 20 Mar '01

20 Mar '01

> From: Miles Fidelman [mailto:mfidelman@civicnet.org] > Sent: Monday, March 19, 2001 3:14 PM > > On Mon, 19 Mar 2001, Shawn McMahon wrote: > > > > If you don't want to read, you don't have to. A lot of > us do feel that > > > this has operational impact, and will continue to discuss > the topic long > > > after its death. > > > > I suppose Susan could kick half of the list's members out, > if she think's > > that's productive. > > Haven't we all repeated the various positions to death? I > don't think any > minds are going to change at this point. Susan has a point, > let's drop it > - or at least take it to a venue where some policy might > really be made > (like the various DNSO lists). I sort of agree with Susan. DOMAIN-POLICY is the place to be, or the ICANN lists, for matters of policy and legitimacy. Contrary to some beliefs, those are not technical issues. The point that's made here is that most of these issues were covered years ago, on many of those other lists. I mentioned earlier that opinions expressed here were reminiscent of DOMAIN-POLICY, circa 3-years ago. The reason this is true is that many of you have NOT been keeping up with the changing issues and the moving consensus. The fact that many of NANOG felt sandbagged by the new.net play, may be explained by a sad case of denial and failing to follow the issues on those other lists. I've been expecting such a play since the November ICANN meet. Y'all may ridicule me all you want, but the sad fact remains that if y'all don't get involved you have not much room to complain, when the fecal material impacts the rotating blades. At that time, about all that you can do is duck and avoid the bigger pieces. IOW, it'll be too late. Poking your collective heads in the NANOG sands will not make these issues go away. BTW, the ORSC has been working the technical side for over three years. see www.icann.org www.dnso.org www.dnso.net www.open-rsc.org Let's take this over to the DOMAIN-POLICY lists, I'll see y'all there.

2 1