- Test - lists.nanog.org

Spamcop under attack....
by blitz 20 Jul '02

20 Jul '02

Interesting... SpamCop under attack SpamCop is being attacked with a Distributed Denial of Service attack (DDoS). Service will be restored as soon as possible. In the meantime, representatives of Qwest are asked to investiage reports of abuse from your network. Packets appear to be originating in Qwest IP space. Packets are destined for SpamCop ip space (64.90.162.80/28). This attack began around 8:30 am EST.

1 0

RE: Power loss in downtown manhattan
by Randy Neals 20 Jul '02

20 Jul '02

We have a leased Oc-3 circuit from 60 Hudson (19th) to NYIIX/25 Broadway down. It stopped working about 12:50(+/-) which I understand is roughly the time of the power outage. Our own equipment at each end of the circuit has not lost power, but it would seem that the local carrier maybe experiencing problems. (The circuit is leased from Univ Access/Looking Glass.) Is anyone else having a similar problem? -Randy -----Original Message----- From: Thomas Kernen To: Alex Rubenstein; Chrisy Luke Cc: nanog(a)merit.edu Sent: 7/20/2002 3:47 PM Subject: Re: Power loss in downtown manhattan FiberNet lost power but came back up (our gear restarted by power on) @ approx 13:30 EST Thomas ----- Original Message ----- From: "Alex Rubenstein" <alex(a)nac.net> To: "Chrisy Luke" <chrisy(a)flix.net> Cc: <nanog(a)merit.edu> Sent: Saturday, July 20, 2002 2:56 PM Subject: Re: Power loss in downtown manhattan > > > We appear to have lost power on 23 Tel-x and/or 19th fibernet. > > > > On Sat, 20 Jul 2002, Chrisy Luke wrote: > > > > > http://www.ny1.com/ny/TopStories/SubTopic/index.html?topicintid=1&subtop icin tid=1&contentintid=23113 > > > > 60 Hudson seems to be affected. > > > > :( > > > > Chris. > > -- > > == chris(a)easynet.net T: +44 845 333 0122 > > == Global IP Network Engineering, Easynet Group PLC F: +44 845 333 0122 > > > > -- Alex Rubenstein, AR97, K2AHR, alex(a)nac.net, latency, Al Reuben -- > -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net -- > >

1 0

The Cidr Report
by CIDR Report 20 Jul '02

20 Jul '02

This is an auto-generated mail on Fri Jul 19 23:00:00 PDT 2002 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. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. 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 amount of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 19Jul02 0) General Status Table History ------------- Date Prefixes 120702 111339 130702 111268 140702 111583 150702 111941 160702 112093 170702 111866 180702 111800 190702 111736 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 88.128.0.0/17 from AS9116 *** Bogus 88.128.128.0/17 from AS9116 *** Bogus 88.129.0.0/17 from AS9116 *** Bogus 88.129.128.0/17 from AS9116 AS Summary ---------- Number of ASes in routing system: 13270 Number of ASes announcing only one prefix: 8089 (4550 cidr, 3539 classful) Largest number of cidr routes: 629 announced by AS3908 Largest number of classful routes: 1221 announced by AS701 1) Gains by aggregating at the origin AS level --- 19Jul02 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1089 841 248 22.8% Telstra Pty Ltd AS701 1221 978 243 19.9% UUNET Technologies, Inc. AS17557 293 101 192 65.5% Pakistan Telecom AS6595 221 54 167 75.6% DoD Education Activity Network As AS852 538 401 137 25.5% Telus Advanced Communications AS7018 808 681 127 15.7% AT&T AS16473 195 77 118 60.5% Bell South AS7303 171 74 97 56.7% Telecom Argentina Stet-France Tel AS5515 437 341 96 22.0% Sonera Finland Autonomous System AS4151 236 141 95 40.3% USDA AS19632 99 5 94 94.9% Metropolis Intercom S.A. AS1239 517 423 94 18.2% Sprint AS12302 119 26 93 78.2% MobiFon S.A. AS16814 105 20 85 81.0% NSS, S.A. AS226 171 88 83 48.5% Los Nettos AS7046 306 227 79 25.8% UUNET Technologies, Inc. AS4755 209 133 76 36.4% Videsh Sanchar Nigam Ltd. Autonom AS2048 180 105 75 41.7% State of Louisiana AS577 263 190 73 27.8% Bell Advanced Communications Inc. AS4323 401 333 68 17.0% Time Warner Communications, Inc. AS724 214 152 62 29.0% DLA Systems Automation Center AS3464 163 103 60 36.8% Alabama SuperComputer Network AS19834 64 4 60 93.8% NetForce, Inc. AS10620 84 24 60 71.4% TVCABLE BOGOTA AS1 444 386 58 13.1% GENUITY AS209 315 258 57 18.1% Qwest AS16758 63 6 57 90.5% IKON Office Solutions AS9051 82 26 56 68.3% INCONET Autonomous System AS3908 297 241 56 18.9% Supernet, Inc. AS9498 84 29 55 65.5% BHARTI BT INTERNET LTD. Total 55004 42386 12618 22.9% 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

Terremark bozos run amok
by David Conrad 19 Jul '02

19 Jul '02

Careful downloading mail from Terremark, particularly when on travel (to, oh say, the IETF in Japan). They just sent 11 _megabytes_ of spam to my personal email address. How far we've come. In 1982, I could buy a 10MByte hard disk for my IBM PC. Now, I get more than that in a single spam. Blech. Rgds, -drc

1 0

RE: IGP metrics on WAN links
by Frank Scalzo 19 Jul '02

19 Jul '02

MPLS allows you to do the best of both worlds. You can set your TE metrics to the latency/route-miles and then build bandwidth constrained LSPs from place to place and they will take the least latent, uncongested path that they fit on. Similar things can be done with ATM routing costs, and contracts on spvcs. Both of these are considerably more work, but it gets traffic flows on good paths very well. There is at least one large ISP doing metrics in that manner. -----Original Message----- From: Daniel Golding [mailto:dgolding@sockeye.com] Sent: Fri 7/19/2002 4:43 PM To: Joe Abley; Me Cc: Sush Bhattarai; nanog(a)merit.edu; Tom Holbrook Subject: RE: IGP metrics on WAN links I suspect the approach you take depends on how your network looks. If you have many pipes of a variety of sizes, doing IGP metrics based on pipe size makes a good deal of sense, then adding twists for things like ckt latency. However, folks with uniform sized networks, and uniform traffic between coasts probably tend to set IGP metrics for latency, with pipe size being the exception that they bias for afterwards. The latter is probably more prevelent in an established network, the former in a network undergoing a large fiber build. - Dan > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > Joe Abley > Sent: Friday, July 19, 2002 4:25 PM > To: Me > Cc: Sush Bhattarai; nanog(a)merit.edu; Tom Holbrook > Subject: Re: IGP metrics on WAN links > > > > On Fri, Jul 19, 2002 at 02:11:29PM -0600, Me wrote: > > I think you missed part of his comment: > > " of course there are always some "twinking" done regularly to > give higher > > priorities to the higher bandwidth, link condition etc" > > > > so fiber mileage is just the base, with modifications to make it work > > correctly, based on bandwidth, etc. > > Yeah, my (limited) experience is the opposite. At the previous large > operator at which I had enable, the IGP metrics were chosen primarily > according to circuit size, and were subsequently tweaked for other > issues (such as circuit latency, or the requirement to balance cross- > US traffic across non-parallel circuits). > > In my experience, congestion is a much more effecive killer of service > than latency due to optical distance. Hence attracting traffic to > circuits where there is more likely to be headroom seems a more > reasonable first-order approach for choosing metrics. > > That experience is all in networks where intra-AS traffic engineering > was done at the IP layer, however; in networks where there is a lower > layer of soft traffic engineering maybe other approaches would be more > appropriate. > > > Joe >

1 0

IGP metrics on WAN links
by Tom Holbrook 19 Jul '02

19 Jul '02

Just curious as to what people are using for metrics in their IGP and what their reasons are; bandwidth? geographical distance? latency? etc... Thanks -Tom __________________ Tom Holbrook Sr. Network Engineer Atlanta Earthlink

6 7

Re: IGP metrics on WAN links
by Warren Van Camp 19 Jul '02

19 Jul '02

At 12:27 PM 7/19/02 -0400, Tom Holbrook wrote: >Just curious as to what people are using for metrics in their IGP and what their reasons are; bandwidth? geographical distance? latency? etc... In the @Home backbone, we used actual fiber miles (plus a small offset per hop to break ties when a particular route had multiple paths with differing numbers of routers). This, of course, just created a "base" configuration which could be tweaked somewhat depending on what needed to happen to make the best use of circuits. Warren Van Camp (formerly @Home Network backbone engineering)

1 0

RE: /24s run amuck... again
by Alexander, Nathan M 19 Jul '02

19 Jul '02

That is of limited usefulness. 1) They'd all have to have the same next hop. 2) you would have to hear all three /24's of them from all your peers, all with the same next hop, metrics, med, etc. Otherwise the aggregate route becomes the backup route for other, more specific announcements of the /24 that you can't aggregate. It would be nice for the single homed, but then why are you running bgp? Nathan Alexander NMC Shift Manager 703/363-5293(office) 301/442-8695(cell) 877/541-2189(pager) Nathan.Alexander(a)qwest.com - Internal Use Only - Disclose and Distribute only to Qwest Employees and authorized persons working for Qwest. Disclosure outside of Qwest is prohibited without authorization. > -----Original Message----- > From: Ralph Doncaster [mailto:ralph@istop.com] > Sent: Friday, July 19, 2002 8:07 AM > To: Richard A Steenbergen > Cc: nanog(a)merit.edu > Subject: Re: /24s run amuck... again > > > > On Fri, 19 Jul 2002, Richard A Steenbergen wrote: > > > With all the recent talk about filtering, I figured now was > a good time > > to update my list of evil /24 announcers... There are > currently over 63k > > /24s out of 113k total unfiltered announcements (over 55%). > > Does anyone (Cisco, Juniper, etc.) have an auto-aggregation feature? > Let's say a router that receives the following prefixes under > a single AS > 206.51.128.0/24 > 206.51.129.0/24 > 206.51.131.0/24 > > And the following network is not in the table: > 206.51.130.0/24 > > Then it would be usefull to collapse it into a single 206.52.128/22 > aggregate (especially if the metrics & communities are the same). > > -Ralph > >

1 0

RE: verio arrogance
by David Diaz 19 Jul '02

19 Jul '02

Getting back to the more original thread. Is there any need to keep the routing table to a smaller size. Since in theory, it creates suboptimal routing. And considering the new routers out there today should be able to handle it. Considering verio is using junipers, and they pride themselves on handling a tremendously large table. Why should we shoot for a 100,000 route table instead of 500,000 if it does not impact performance? I do understand that the 100,000 might be that actual 'installed best routes' and that the routers might in fact be dealing with a much larger route table. That might be an issue. But certainly 100,000- 500,000 installed routes, is that a problem for large backbones with high end routers? My only consideration might be the small multihomed ISPs with 2-3 providers with full BGP feeds and cisco 4000s (256meg ram). I saw one last week. I might be concerned at that level. I'd love to hear feedback. It would then justify filtering...or not. David At 21:37 -0400 7/18/02, Phil Rosenthal wrote: >How is it arrogant? >I read that as: a customer set up an exploitable FormMail. Verio >received notice about it. Verio removed the FormMail in question. Verio >asked to be removed since they corrected the problem. Verio was ignored. > >Verio may have some problems with not terminating spammers, and I >believe this to be the truth -- I buy from verio, and Don't spam, and >whenever one of my clients spam, they get terminated for it. I receive >plenty of spam from verio ips, and no matter how much I complain, it >never gets terminated. This is probably a scenario of asking sales rep >"If I want to spam, but I pay more per meg -- Is this OK?" and getting >a positive answer. > >That is why the NANAE people don't like verio. But, nonetheless, I >don't think that putting verio's mailserver on a formmail list is >accomplishing anything good, since they fixed THAT problem... > >--Phil > >-----Original Message----- >From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of >Kai Schlichting >Sent: Thursday, July 18, 2002 6:37 PM >To: nanog(a)merit.edu >Cc: Kai Schlichting >Subject: Re: verio arrogance > > > >How's THIS for Verio arrogance, going to a whole new level: > >http://www.monkeys.com/anti-spam/filtering/verio-demand.ps > >Details were on the SPAM-L list Wed, 17 Jul 2002 15:51:05 EDT: Verio >threatens to sue Ron Guilmette over the IP 208.55.91.59 appearing on his >FormMail.pl open-proxy/formmail server DNSBL. > >And given the ever-increasing number of spammers now hopping onto Verio >tells me that Verio must be well down the spiral of death (spammers seem >to be attracted by NSP's going chapter 7/11, or who are getting close), >or else the dozen-or-so automated messages going to abuse(a)verio.net >every week complaining about connections (real or attempted) to hosts >under my control, and originating from their spamming customers would >have shown any results over time. > >I don't need connectivity to 208.55.0.0/16. I really don't, and I have >not the slightest tolerance for litigious, small-minded, >panic-lawyer-dialling scum like this. > >/etc/mail$ grep 208.55 access.local >208.55 550 Access for FormMail spam and litigious scum >denied - XXXX Verio in their XXXXXXXX XXX - we block more than just >208.55.91.59 - Spammers must die - see >http://www.monkeys.com/anti-spam/filtering/verio-demand.ps >/etc/mail$ > >PS: I also have zero tolerance for Nadine-type spam-generating, >"single-opt-in", > "87% permission-based" emailers nowadays: 2 bounces or a single mail >to a > never-existing account, and all your /24's are off into gated.conf as >a > next-hop route to 127.0.0.1. And no, they won't get around that by >advertising > /25's. > >Good-bye route-prefix-filtering wars, and welcome to the war on spam, >where Null0'd /28's for filtering 'undesirables' just doesn't cut it any >more. Casualties like 10-15 bystanding rackspace.com customers with a >"Nadine- type" mailer in neighboring IP space be damned: "move your >servers into a different slum, cause da landlord's running down 'da >neighborhood". > >-- >"Just say No" to Spam Kai >Schlichting >New York, Palo Alto, You name it Sophisticated Technical >Peon >Kai's SpamShield <tm> is FREE! >http://www.SpamShield.org >| >| | >LeasedLines-FrameRelay-IPLs-ISDN-PPP-Cisco-Consulting-VoiceFax-Data-Muxe >s >WorldWideWebAnything-Intranets-NetAdmin-UnixAdmin-Security-ReallyHardMat >h -- David Diaz dave(a)smoton.net [Email] pagedave(a)smoton.net [Pager] Smotons (Smart Photons) trump dumb photons

7 8

/24s run amuck... again
by Richard A Steenbergen 19 Jul '02

19 Jul '02

With all the recent talk about filtering, I figured now was a good time to update my list of evil /24 announcers... There are currently over 63k /24s out of 113k total unfiltered announcements (over 55%). http://www.e-gerbil.net/ras/projects/ipaddr/amuck-071902.txt This scan is done from the point of view of Williams (AS7911) transit, a fairly "average" unfiltered view of around 113k routes. It's not perfect, but it's pretty easy to go down the list and verify which ones are really poluting the internet. The reason these don't get picked up on other peoples "cidr scans" is that they have "gaps", so they are not perfectly cidr-able. The reasons for these announcements vary, including obvious incompetence and cable/dsl companies without a "backbone" connecting their various POPs announcing a /24 for each location to a single transit provider. If I had more free time I would extend this analysis past /24s, but since they're such a huge amount of polution it's a good place to start. If someone wanted to do an analysis of routes from a common block with identical attributes, I suspect they would find it a bigger cause of net polution than multihomers punching holes. For quick complaining, the top 10 offenders are: ASN Name Reg'd Netblock Prefixes --- ---- -------------- -------- 6595 DoD Dependents Schools - Europe 204.218.0.0/15 236 22927 TELEFONICA DE ARGENTINA 168.226.0.0/16 167 7029 Alltel Information Services 166.102.0.0/16 128 7303 Telecom Argentina Stet-France 200.43.0.0/16 127 14654 Wayport 64.134.0.0/16 113 16473 Bell South 198.146.0.0/16 111 11492 Cable One 24.116.0.0/16 108 18687 MPower Communications 208.57.0.0/16 98 7132 Southwestern Bell 207.193.0.0/16 89 1580 Army HQ, 5th Signal Command 144.170.0.0/16 88 -- 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)

4 3