Fw: [swinog] Contact @ AOL?
Please reply to him directly, thanks, Pascal - Original Message - From: Benoit Panizzon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 06, 2002 9:32 PM Subject: [swinog] Contact @ AOL? Does somebody have any contact to an AOL hostmaster or abuse person? Since about three months I get multiple attempts to send spam via a Formmail installation every day from the AOL.COM IP-Range. I forward the logs to [EMAIL PROTECTED] nearly every day but I never get any human answering my emails. I also called AOL in Germany but they don't know who I should contact or how I should escalate that problem. (They just told me [EMAIL PROTECTED] are the only ones known to care about such problems). PS: It's a secured Formmail and those attempts were all unsuccessfull, so no need to tell me it's not secure ;-) Benoit Panizzon ASCII-Ribbon Campaign No HTML or WORD in Mails HTML is for WEB, Word is for Micro$oft. ** Get stoned - drink wet concrete -- [EMAIL PROTECTED] Maillist-Archive: http://www.mail-archive.com/swinog%40swinog.ch/
Re: Updates to the root zone Re: KPNQwest ns.eu.net server.
This is not a political question, only operational process. Has ICANN and NTIA worked out their operational issues so they can quickly change the root zone to reflect changes in ccTLD nameservers if people need to change which name servers are handling the ccTLDs. Last year, some of the ccTLD operators were complaining it sometimes took weeks after they submitted the change for it to make it into the root zone. Actually what worries me more is the following. I did a small check on how frequently DNS servers occure in the European ccTLDs NS records. If I leave out the ones that only oocure once, I get the following : 14 NS.EU.NET. 10 NS.UU.NET. 9 SUNIC.SUNET.SE. 3 NS2.NIC.FR. 2 NS.RIPE.NET. 2 NS-EXT.VIX.COM. 2 DNS.PRINCETON.EDU. 2 AUTH02.NS.UU.NET. This is after checking 18 ccTLDs. Most of them only have four secondaries. If I read this correctly, the geographic distribution of servers is not that bad, but it could be better. Preferably by going with more than four secondaries. Consider that up until not to long ago, several of these servers where behind the same upstream. Best regards, - kurtis -
Re: Re: Re: KPNQwest ns.eu.net server.
Hallo Sabine, lange nichts gehoert ... On Fri, Jun 07, 2002 at 09:51:11AM +0200, Sabine Dolderer/Denic wrote: At least each IXP member would have direct connectivity to such infrastructural services (DNS, NTP, WHOIS, NNTP??) and thereby their customers would benefit from it. I agree that IXPs would be very gould locations as they offer network diversity, but there is one question still open and that is who will be the one running the and monitoring the server. And we at DENIC have seen in the last years an increasing demand in running the servics by ourself as only then we have the complete control and information about statistics, network attacks, performance ... Keep it simple ... the IXPs (e.g. Euro-IX) could/should provide the basis. I.e. taking care for excellent colo, sufficient connectivity, one-stop-shop etc. Interested parties would install the services by themselves and would be responsible to run them. Parties could be CENTR, DE-NIC, ICANN, EUxxx and so on. I would like to know more about the CENTR sss iniative. Whom should I contact? Arnold -- Arnold Nipper Email: [EMAIL PROTECTED] DE-CIX, The German Internet Exchange Mobile: +49 172 2650958
Re: Bogon list
On Thu, 6 Jun 2002, Stephen Griffin wrote: In the referenced message, Sean M. Doran said: Basically, arguing that the routing system should carry around even more information is backwards. It should carry less. If IXes need numbers at all (why???) then use RFC 1918 addresses and choose one of the approaches above to deal with questions about why 1918 addresses result in messy traceroutes. Fewer routes, less address consumption, tastes great, less filling. Sean. Do you: 1) Not believe in PMTU-D RFC1918 does not break path-mtu, filtering it does tho.. 2) Not believe in filtering RFC1918 sourced traffic at enterprise boundaries (of which an exchange would be a boundary) What for? You'll find many more much more mailicious packets coming from legit routable address space. 3) Not believe packet-passing devices have legitimate needs in contacting hosts, even if hosts don't have legitimate needs for contacting them? (a superset of 1, above) 4) All or some of the above? I would love if RFC1918 were adhered to such that L3 packet-passing devices either weren't numbered out of those blocks, or allowed what juniper allows with the ability to select the ip address with which packets sourced by the L3 packet-passing device sent traffic (other than primary ip on destination interface). The latter would permit intra-enterprise use of RFC1918 addresses, while still conforming with RFC1918. Failing that, use of RFC1918 addresses in places where inter-provider packets get RFC1918 sources, is a violation of RFC1918. For p2p you can use unnumbered.. it wont work on exchanges but i agree they shouldnt be rfc1918. Steve In any event, exchanges are inter-enterprise, and shouldn't be RFC1918.
Re: KPNQwest ns.eu.net server.
number and distribution of registrations maybe - that comes down to number and sizing of servers and geography/network diversity, the others are at best operational concerns for the backend, not for the frontend DNS servers. backend/frontend? Taking RFC 2870, why wouldn't all of section 2 and most of section 3 and section 4 be applicable to both gTLD and ccTLD servers (changing root zone and IANA as appropriate)? sure, you could take those sections as a starting point. But why stop at TLDs? Why not make this applicable to -ALL- dns servers? The problem we tried to tackle with RFC 2010, and apparently not well considered by the authors of RFC 2870 is the difficulty of segmenting system availabilty from operations. So to clarify, are you talking about the server operations or are you talking about availability of the zone? RFC 2870 muddies the waters here. You seem to be leaning toward ensuring availablity. RFC 2010 attempted to make the distinction. gTLD servers, today, have an operational requirement to run on 64bit hardware. Few if any ccTLDs have that as a requirement. The root servers may not see that requirement until 2038 or so... In any case, RFC 2870 is getting long in the tooth and
Re: KPNQwest ns.eu.net server.
On Fri, 07 Jun 2002 12:18:19 -, [EMAIL PROTECTED] said: sure, you could take those sections as a starting point. But why stop at TLDs? Why not make this applicable to -ALL- dns servers? Mighty fine pharmaceuticals you got there. ;) I'd settle for a requirement that dns servers have *basic* configuration correct - I mean, is it *that* hard to avoid lame delegations and typos in the SOA or NS records? -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg02530/pgp0.pgp Description: PGP signature
RE: NAS filed chp 11
now someone will surely step up to the plate in their defence and rant about how this is all a good thing for NASC and how they will go on to reemerge next year as a lean, mean, bigger better company. I think at this point we are all long past the innocent stage and rapidly approaching apathy. as our sisters and brothers lose jobs, i doubt either meanness or apathy are appropriate. do not tempt the fates. randy
Re: Bogon list
At 05:26 AM 6/7/02, Stephen J. Wilcox wrote: On Thu, 6 Jun 2002, Stephen Griffin wrote: In the referenced message, Sean M. Doran said: Basically, arguing that the routing system should carry around even more information is backwards. It should carry less. If IXes need numbers at all (why???) then use RFC 1918 addresses and choose one of the approaches above to deal with questions about why 1918 addresses result in messy traceroutes. Fewer routes, less address consumption, tastes great, less filling. Sean. Do you: 1) Not believe in PMTU-D RFC1918 does not break path-mtu, filtering it does tho.. Though many people either miss the point or don't care, RFC 1918 is also BCP 5. Last I checked, BCP stood for Best Current Practice. So you've got a BCP document saying the addresses listed in RFC 1918 should not be present on the public network. So yes, filtering is required by RFC 1918, and so use of the private IP address blocks does break Path MTU discovery. Some folks find the private address space specified in RFC 1918 convenient, but ignore the stipulations on use contained in the same document. - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranth.com
Re: KPNQwest ns.eu.net server.
[EMAIL PROTECTED] wrote: I mean, is it *that* hard to avoid lame delegations and typos in the SOA or NS records? apparently -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Bogon list
[ On Friday, June 7, 2002 at 10:26:53 (+0100), Stephen J. Wilcox wrote: ] Subject: Re: Bogon list RFC1918 does not break path-mtu, filtering it does tho.. So, in other words inappropriate use of RFC 1918 does not break Path MTU Discovery! You can't still have your cake and have eaten it too. One way or another RFC 1918 addresses must not be let past the enterprise boundaries. Lazy and/or ignorant people don't always meet all the requirements of RFC 1918, but it's only their lack of compliance that _may_ allow Path-MTU-discovery to continue working for their networks for _some_ people _some_ of the time. However any enterprise also using RFC 1918, but using it correctly (or customers of such an enterprise), and thus who are also carefully protecting their use from interference by outside parties, will be filtering inbound packets with source addresses in the RFC 1918 assigned networks, and so as a result they _will_ experience Path-MTU-discovery failure (i.e. at any time it's necessary it literally cannot work) when attempting to contact (and sometimes be contacted by, depending on the application protocol in use) any host on or behind the lazy and/or ignorant operator's network(s). (and no, I'm not sorry if I've yet again offended anyone who might be mis-using RFC 1918 addresses for public nodes -- you should all know better by now! How many _years_ has it been?) 2) Not believe in filtering RFC1918 sourced traffic at enterprise boundaries (of which an exchange would be a boundary) What for? You'll find many more much more mailicious packets coming from legit routable address space. If you have any IP address level trust relationsips on your internal LANs then you _MUST_ (if you want those trust relationships to be valid) filter all foreign packets with source addresses appearing to be part of your internal LANs. For p2p you can use unnumbered.. it wont work on exchanges but i agree they shouldnt be rfc1918. On this we can agree! :-) -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Portable Fire Suppression
Greetings; I would like to protect an unattended server enclosure in a remote location with some variety of fire suppression device. I imagine that some enterprising soul has invented a fire extinguisher with a nozzle that opens at a preset temperature (i.e. exploding head). Thank you in advance for any advice you can provide. Regards, Christopher J. Wolff, VP CIO Broadband Laboratories http://www.bblabs.com
RE: Portable Fire Suppression
Title: RE: Portable Fire Suppression Well, aren't fire extinguishers supposed to explode anyway upon high temperature? Rick Cheung NPI IT Wan Team, CCNP -Original Message- From: Christopher J. Wolff [mailto:[EMAIL PROTECTED]] Sent: Friday, June 07, 2002 1:00 PM To: [EMAIL PROTECTED] Subject: Portable Fire Suppression Greetings; I would like to protect an unattended server enclosure in a remote location with some variety of fire suppression device. I imagine that some enterprising soul has invented a fire extinguisher with a nozzle that opens at a preset temperature (i.e. exploding head). Thank you in advance for any advice you can provide. Regards, Christopher J. Wolff, VP CIO Broadband Laboratories http://www.bblabs.com
Portable Fire Suppression
From the first few responses I believe some clarification is in order...This specific 'unattended server enclosure' is sitting outside in the middle of the desert. Regards, Christopher J. Wolff, VP CIO Broadband Laboratories http://www.bblabs.com Greetings; I would like to protect an unattended server enclosure in a remote location with some variety of fire suppression device. I imagine that some enterprising soul has invented a fire extinguisher with a nozzle that opens at a preset temperature (i.e. exploding head). Thank you in advance for any advice you can provide. Regards, Christopher J. Wolff, VP CIO Broadband Laboratories http://www.bblabs.com
Re: Bogon list
Well, the biggest offender in this respect by far was @home, and you know what happened to THEM... -C On Fri, Jun 07, 2002 at 12:55:08PM -0400, Greg A. Woods wrote: [ On Friday, June 7, 2002 at 10:26:53 (+0100), Stephen J. Wilcox wrote: ] Subject: Re: Bogon list RFC1918 does not break path-mtu, filtering it does tho.. So, in other words inappropriate use of RFC 1918 does not break Path MTU Discovery! You can't still have your cake and have eaten it too. One way or another RFC 1918 addresses must not be let past the enterprise boundaries. Lazy and/or ignorant people don't always meet all the requirements of RFC 1918, but it's only their lack of compliance that _may_ allow Path-MTU-discovery to continue working for their networks for _some_ people _some_ of the time. However any enterprise also using RFC 1918, but using it correctly (or customers of such an enterprise), and thus who are also carefully protecting their use from interference by outside parties, will be filtering inbound packets with source addresses in the RFC 1918 assigned networks, and so as a result they _will_ experience Path-MTU-discovery failure (i.e. at any time it's necessary it literally cannot work) when attempting to contact (and sometimes be contacted by, depending on the application protocol in use) any host on or behind the lazy and/or ignorant operator's network(s). (and no, I'm not sorry if I've yet again offended anyone who might be mis-using RFC 1918 addresses for public nodes -- you should all know better by now! How many _years_ has it been?) 2) Not believe in filtering RFC1918 sourced traffic at enterprise boundaries (of which an exchange would be a boundary) What for? You'll find many more much more mailicious packets coming from legit routable address space. If you have any IP address level trust relationsips on your internal LANs then you _MUST_ (if you want those trust relationships to be valid) filter all foreign packets with source addresses appearing to be part of your internal LANs. For p2p you can use unnumbered.. it wont work on exchanges but i agree they shouldnt be rfc1918. On this we can agree! :-) -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] msg02540/pgp0.pgp Description: PGP signature
Re: KPNQwest ns.eu.net server.
On Fri, Jun 07, 2002 at 08:36:21AM -0400, [EMAIL PROTECTED] wrote: I'd settle for a requirement that dns servers have *basic* configuration correct - I mean, is it *that* hard to avoid lame delegations and typos in the SOA or NS records? Don't even get me started on typos in the delegation records at the TLD servers (entered by the registrants at least) there are currently 112 domains in .com alone with at least one incorrect NS record pointing at my nameservers.
Re: Portable Fire Suppression
This specific 'unattended server enclosure' is sitting outside in the middle of the desert. How will you protect it from gunshots: http://sadtomato.net/mojave.html They removed that phone booth a couple of years ago: http://www.lvrj.com/lvrj_home/2000/May-23-Tue-2000/news/13631118.html Are you taking the same spot, sort of analagous to turning an old CO into a co-location building? -mark
Re: KPNQwest ns.eu.net server.
Don't even get me started on typos in the delegation records at the TLD servers (entered by the registrants at least) there are currently 112 domains in .com alone with at least one incorrect NS record pointing at my nameservers. MX0 lame.delegation.to.hostname. * MX0 lame.delegation.to.hostname. randy
Re: KPNQwest ns.eu.net server.
Yo John! On Fri, 7 Jun 2002, John Payne wrote: Don't even get me started on typos in the delegation records at the TLD servers (entered by the registrants at least) there are currently 112 domains in .com alone with at least one incorrect NS record pointing at my nameservers. There is an easy tool I use to fix that. Just put up a zone file for them on your NS that points their www to www.playboy.com. This gets action fast! RGDS GARY --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676
RE: Portable Fire Suppression
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ] Greetings; ] ] I would like to protect an unattended server enclosure in a remote ] location with some variety of fire suppression device. I ] imagine that ] some enterprising soul has invented a fire extinguisher with a nozzle ] that opens at a preset temperature (i.e. exploding head). Depending on the area you want to cover, you may be able to use marine units (designed for boat engine compartments). KIDDE makes units that use FM200 or FE-241 starting at about $200 for 75 cubic feet and go up to 1100 cf. I found prices, etc at http://www.westmarine.com/ Good luck, - Mark -BEGIN PGP SIGNATURE- Version: PGP Personal Privacy 6.5.8 iQA/AwUBPQEBu+ze6cudrhHZEQJIagCbB/SJO5McZm6lT/hNIBlgnG8jp2UAn2Jh XRrGKNAUMNJp9f7sambDVYO2 =8lph -END PGP SIGNATURE-
Re: Bogon list
In the referenced message, Stephen J. Wilcox said: On Thu, 6 Jun 2002, Stephen Griffin wrote: In the referenced message, Sean M. Doran said: Basically, arguing that the routing system should carry around even more information is backwards. It should carry less. If IXes need numbers at all (why???) then use RFC 1918 addresses and choose one of the approaches above to deal with questions about why 1918 addresses result in messy traceroutes. Fewer routes, less address consumption, tastes great, less filling. Sean. Do you: 1) Not believe in PMTU-D RFC1918 does not break path-mtu, filtering it does tho.. sending RFC1918 addressed packets across enterprise boundaries is against RFC1918. RFC1918 states to filter ingress/egress at enterprise boundaries. Hence, filtering RFC1918 addresses is part of RFC1918. Therefore, the use of addresses where they are likely to generate traffic which violates RFC1918, is, well, a violation of RFC1918. This applies regardless of the ICMP error message generated. 2) Not believe in filtering RFC1918 sourced traffic at enterprise boundaries (of which an exchange would be a boundary) What for? You'll find many more much more mailicious packets coming from legit routable address space. Who said anything about malicious? In any event, ICMP error messages are generally useful with a few minor exceptions. Things like Source Quench, unreachables, TTL expired, and Can't Frag (as examples of useful icmp.) snip For p2p you can use unnumbered.. it wont work on exchanges but i agree they shouldnt be rfc1918. I agree, however, most folks want to see the topology, some just choose to violate RFC1918 in order to do it. Steve
Re: KPNQwest ns.eu.net server.
On Fri, Jun 07, 2002 at 11:48:24AM -0700, Gary E. Miller wrote: Yo John! On Fri, 7 Jun 2002, John Payne wrote: Don't even get me started on typos in the delegation records at the TLD servers (entered by the registrants at least) there are currently 112 domains in .com alone with at least one incorrect NS record pointing at my nameservers. There is an easy tool I use to fix that. Just put up a zone file for them on your NS that points their www to www.playboy.com. This gets action fast! Not when the domains are just registered for cybersquatting (the other problem). I have done something similar to what you suggest (but without targetting an innocent thirdparty)... see http://www.chairtime.com/ as an example. The abuse and legal threats were amusing to start with, but they're getting boring now - I'd much rather just pull the glue records and break those domains hard (nothing legitimate has ever been on those nameservers)
Re: KPNQwest ns.eu.net server.
On Fri, 7 Jun 2002, Gary E. Miller wrote: Yo John! There is an easy tool I use to fix that. Just put up a zone file for them on your NS that points their www to www.playboy.com. This gets action fast! I think pointing it to www.poopsex.com would be far more entertaining. Charles RGDS GARY --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676
www.worldnet.att.net routing problems
Does anyone have information why ATT's Worldnet portal is being routed through Splitrock, UIUC and NCSA? It seems to have pretty much taken the Worldnet site off the net. nslookup www.worldnet.att.net Server: localhost Address: 127.0.0.1 Non-authoritative answer: Name:www.worldnet.att.net Addresses: 204.127.43.37, 204.127.12.39 route-views.oregon-ix.netshow ip bgp 204.127.12.39 BGP routing table entry for 204.127.0.0/20, version 4137919 Paths: (1 available, best #1) Advertised to non peer-group peers: 64.166.72.140 1224 38 10514 7018 5731, (aggregated by 5731 204.127.128.251) 141.142.12.1 from 141.142.12.1 (141.142.12.1) Origin IGP, localpref 100, valid, external, atomic-aggregate, best route-views.oregon-ix.net
Last Call: NANOG Peering BOF
Hi All - At the Peering BOF Monday evening, so far I have Peering Coordinators lined up from Adelphia, CableVision, Comcast, Cox, DACOM Korea, Equinix, GNAPs, ICG, ISC, Japan Telecom, Merit, Powered, Shaw, TELUS, T-Systems, Videotron, Yahoo! and CW. We can take another 5-7 folks on the agenda, so... If you are a peering coordinator and would like to introduce yourself to the other Peering Coordinators, please fill out and e-mail the RSVP form below to [EMAIL PROTECTED] We had a lot of walk-ons last time and we will do that again this time, but if you RSVP I will have your contact info and RSVP info in the screen behind you as you introduce yourself, so it works better if you RSVP. A couple suggestions came from the field as well: Bring plenty of cards, network maps showing relevant info (peering points, backbone topology and size of pipes, etc). After the BOF we will break to the bar where the real work happens ;-) See you in Richmond Hill ! Bill - Previous Call for Participants -- Hi all - NANOG is only three weeks away and Monday evening at NANOG there will be another Peering BOF ; thanks to those that suggested this on the survey forms! We'll do this the same way as last time / the same way the Peering Personals ran at the last GPF: *Peering Coordinators*: Send me the completed RSVP form below. I'll assemble these into logos, icons, AS#s and contact info With this backdrop, each of you in turn get a chance to stand up and a) introduce yourself, your network, b) what you are looking for in a peer, c) why folks should want to peer with you, and d) which locations you currently or plan to peer. Making the initial contact with the potential peer is (oddly enough) the most difficult parts of peering, and the Peering Personals has proven to be an effective (and lively!) way to make those initial contacts. So *Peering Coordinators* - send me those RSVPs ! Since we only have 90 minutes I'm going to limit the number of Peering Coordinators to 25 or so. If there is time remaining we'll use the rest of the time for ad hoc Peering Personals as we did last time. A couple comments: I noticed on the thread Interconnects folks were talking about willingness to peer and MLPAs. At least from the conversations I had during my research on Peering, I found relatively little interest in MLPAs. For those using contracts for peering, folks preferred to control peering using their own contracts written by their lawyers, stating their evolving peering terms and conditions, and generally felt somewhat like they were losing control by signing up to a MLPA document. At the same time, I have found from running these Peering Personals and talking with these Peering Coordinators, that maybe 80% of all Peering Coordinators had a relatively open peering policy. By Relatively Open I mean that they would peer in any single location or multiple location with companies that they would not consider to be a prospective customer. This openness was surprising given all the huff and puff on mailing lists over the years about *not* being able to get peering. We'll see if my 80% figure rings true at the Peering BOF, and I'll share a couple anecdotes about an emerging set of significant traffic open peers at the Peering BOF. Bill -- RSVP FORM -- Clip Here --- Please Fill out and e-mail to [EMAIL PROTECTED] with Subject: Peering BOF V Name: __ Email: __ Title: __ Company: ___ AS#(s): _ Check each that applies: ___ We are an ISP (sell access to the Internet) -- OR -- ___ We are a Non-ISP (content company, etc.) ___ We are Content-Heavy -- OR -- ___ We are Access-Heavy ___ We generally require peering in multiple locations -- OR -- ___ We will peer with anyone in any single location ___Peering with Content Players or Content Heavy ISPs is OK by us ___ We have huge volumes of traffic (lots of users and/or lots of content) (Huge: 1 Gbps total outbound traffic to peers and transit providers) ___ We have a global network ___ We require written contracts for peering ___ We have a U.S. Nation-Wide Backbone (East Coast, West Coast, and at least one location in the middle) --- snip
Ren Nowlin's Saturday Expedition
Anyone driving over to the docks from the Sheraton hotel tomorrow AM? Willing to split a cab otherwise. -- David Diaz [EMAIL PROTECTED] [Email] [EMAIL PROTECTED] [Pager] Smotons (Smart Photons) trump dumb photons
Re: Bogon list
[ On Friday, June 7, 2002 at 15:28:56 (-0400), Stephen Griffin wrote: ] Subject: Re: Bogon list I agree, however, most folks want to see the topology, some just choose to violate RFC1918 in order to do it. Sometimes even I stoop so low! :-) # bloody rogers routers use these nets for interfaces, # thus we need to allow them for our own traceroutes to work # pass in quick proto icmp from 10.0.0.0/8 to 65.48.34.145 group 250 pass in quick proto icmp from 10.0.0.0/8 to 204.92.254.0/24 group 250 pass in quick proto icmp from 192.168.0.0/16 to 65.48.34.145 group 250 pass in quick proto icmp from 192.168.0.0/16 to 204.92.254.0/24 group 250 grrr -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
The Cidr Report
This is an auto-generated mail on Fri Jun 7 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 [EMAIL PROTECTED]. -- CIDR REPORT for 07Jun02 0) General Status Table History - DatePrefixes 310502 110978 010602 110824 020602 110920 030602 110922 040602 111222 050602 111490 060602 111589 070602 111313 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes - *** Bogus 192.0.2.0 from AS1103 AS Summary -- Number of ASes in routing system: 13089 Number of ASes announcing only one prefix: 7961 (4467 cidr, 3494 classful) Largest number of cidr routes: 646 announced by AS701 Largest number of classful routes: 1359 announced by AS701 1) Gains by aggregating at the origin AS level --- 07Jun02 --- ASnumNetsNow NetsCIDR NetGain % Gain Description AS701 1359 1091 268 19.7% UUNET Technologies, Inc. AS1221 1089 843 246 22.6% Telstra Pty Ltd AS17557 292 104 188 64.4% Pakistan Telecom AS852590 431 159 26.9% Telus Advanced Communications AS7018 818 687 131 16.0% ATT AS6595 177 57 120 67.8% DoD Education Activity Network As AS16473 194 76 118 60.8% Bell South AS705304 204 100 32.9% UUNET Technologies, Inc. AS19632 984 94 95.9% Metropolis Intercom S.A. AS4151 234 141 93 39.7% USDA AS12302 120 32 88 73.3% MobiFon S.A. AS7303 150 65 85 56.7% Telecom Argentina Stet-France Tel AS7046 331 246 85 25.7% UUNET Technologies, Inc. AS16814 104 19 85 81.7% NSS, S.A. AS1239 506 421 85 16.8% Sprint AS2048 181 104 77 42.5% State of Louisiana AS577267 194 73 27.3% Bell Advanced Communications Inc. AS4755 189 118 71 37.6% Videsh Sanchar Nigam Ltd. Autonom AS724230 161 69 30.0% DLA Systems Automation Center AS4323 408 339 69 16.9% Time Warner Communications, Inc. AS226154 91 63 40.9% Los Nettos AS3464 166 105 61 36.7% Alabama SuperComputer Network AS19834 644 60 93.8% NetForce, Inc. AS10620 83 23 60 72.3% TVCABLE BOGOTA AS1 450 392 58 12.9% GENUITY AS3908 308 251 57 18.5% Supernet, Inc. AS16758 636 57 90.5% IKON Office Solutions AS209314 258 56 17.8% Qwest AS905179 27 52 65.8% INCONET Autonomous System AS653562 15 47 75.8% Chilesat Servicios Empresariales Total 552694268712582 22.8% 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
