- Test - lists.nanog.org

The Cidr Report
by CIDR Report 02 Mar '02

02 Mar '02

This is an auto-generated mail on Fri Mar 1 23:00:00 PST 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 amont 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 01Mar02 0) General Status Table History ------------- Date Prefixes 220202 106236 230202 106385 240202 106326 250202 106519 260202 106454 270202 106725 280202 106799 010302 106896 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 96.0.0.0/20 from AS3549 AS Summary ---------- Number of ASes in routing system: 12522 Number of ASes announcing only one prefix: 7615 (4306 cidr, 3309 classful) Largest number of cidr routes: 769 announced by AS701 Largest number of classful routes: 1402 announced by AS701 1) Gains by aggregating at the origin AS level --- 01Mar02 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1402 1138 264 18.8% UUNET Technologies, Inc. AS1221 1140 883 257 22.5% Telstra Pty Ltd AS17557 224 96 128 57.1% Pakistan Telecom AS16473 198 77 121 61.1% Bell South AS7018 801 684 117 14.6% AT&T AS6595 162 57 105 64.8% DoD Education Activity Network As AS4151 255 150 105 41.2% USDA AS705 307 203 104 33.9% UUNET Technologies, Inc. AS852 432 329 103 23.8% Telus Advanced Communications AS7046 346 244 102 29.5% UUNET Technologies, Inc. AS577 288 192 96 33.3% Bell Advanced Communications Inc. AS19632 94 9 85 90.4% Metropolis Intercom S.A. AS12302 114 32 82 71.9% MobiFon S.A. AS2048 186 105 81 43.5% State of Louisiana AS1239 488 409 79 16.2% Sprint AS4755 226 150 76 33.6% Videsh Sanchar Nigam Ltd. Autonom AS4323 424 350 74 17.5% Time Warner Communications, Inc. AS3908 333 266 67 20.1% Supernet, Inc. AS7303 117 53 64 54.7% Telecom Argentina Stet-France Tel AS3464 157 97 60 38.2% Alabama SuperComputer Network AS724 218 159 59 27.1% DLA Systems Automation Center AS10620 79 21 58 73.4% TVCABLE BOGOTA AS16758 63 6 57 90.5% IKON Office Solutions AS226 145 89 56 38.6% Los Nettos AS1 473 417 56 11.8% BBN Planet AS19834 63 8 55 87.3% NetForce, Inc. AS9051 75 22 53 70.7% INCONET Autonomous System AS703 269 217 52 19.3% UUNET Technologies, Inc. AS702 619 567 52 8.4% UUNET Technologies, Inc. AS2149 301 249 52 17.3% Performance Systems, Inc. Total 54098 42109 11989 22.2% 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

The end of ASN 6172
by Sean Donelan 01 Mar '02

01 Mar '02

ASN 6172 (ATHOME) is still announcing a few routes. Any word on when @Home will turn off the last router? Or are they being abandoned in place. In the past, some defunct networks have been announced for as long as two years after everyone left.

1 0

Reverse DNS and SMTP
by Patrick Muldoon 01 Mar '02

01 Mar '02

We have recently implemented a policy on our mail servers of not accepting mail from hosts that do not correctly resolve via reverse DNS. While we on the technical side love the idea, there have been some questions from the business side of the house. If an ISP who doesn't have reverse DNS setup correctly on their mail servers, we point them to the RFC's and generally offer to help them correct it. We have noticed that our spam has reduced drastically, and the complaints are few, but alas this is a double edged sword, where if you even block 1 legitimate e-mail out of the 100K+ that we receive daily, someone is going to complain. Just curious if anybody here is doing the same and the response that they have had from doing so. Replies off list are fine and I will summarize if people are interested. Thanks, Patrick -- Patrick Muldoon, Network/Software Engineer INOC, LLC doon(a)inoc.net Press Ctrl-Alt-Del now for IQ test.

8 7

Teleglobe Contact
by Daniel Concepcion 01 Mar '02

01 Mar '02

Have someone any operative contact in Teleglobe for a Peering issues with AS8297 in Spain. I try the noc@ peering@ and I dont't have any response. PD: Sorry for the offtopic. Regards, Daniel Intelideas Spain

1 0

Re: DNS timeline
by Simon Higgs 01 Mar '02

01 Mar '02

At 01:40 AM 2/25/2002 -0500, Sean Donelan wrote: >Since it appears DNS goofiness is about to return, I put together >a timeline of significant events that affected DNS service technically >over the last 20 years. > >http://www.donelan.com/dnstimeline.html Here's some that you missed: 7/31/1996. DNS root fragments (no-one notices). IANA-rep authorizes Draft Postel TLD applicants to go live with new registr(ies) as proof of concept. AlterNIC chosen as the "test root" until 10/1/1996 when TLDs were due to go live in IANA root. Process hi-jacked by ISOC/ITU/WIPO whereby new TLDs forced to exist outside IANA root. ?/2001. ICANN introduce the first intentionally duplicate TLDs (.BIZ/.INFO), de-stabilizing the DNS and causing cross-root pollution (now everyone notices). ?/2001. .US domain moved to .BIZ name servers creating permanent state of DNS root cross-pollution and creates new .US resolution problems. And the latest major internet outage: 2/2002. Randy Bush starts sounding rational (Go Randy, go!): http://www.interesting-people.org/archives/interesting-people/200202/msg002… Best Regards, Simon -- ###

2 3

ep.net status?
by Chris Parker 28 Feb '02

28 Feb '02

Anyone know what's going on with ep.net? It's been unresolvable since at least yesterday. PAIX, SIX and several other exchanges point to ep.net to register for an IP assignment at the exchange. The two authoritive servers, flag.ep.net (198.32.4.13) dot.ep.net (198.32.2.10) are not working by my testing (from own network as well as looking glasses). I cannot even reach flag, and dot doesn't know about ep.net. $ dig @198.32.2.10 ep.net soa ; <<>> DiG 8.1 <<>> @198.32.2.10 ep.net soa ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 10 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;; ep.net, type = SOA, class = IN $ dig @198.32.4.13 ep.net soa ; <<>> DiG 8.1 <<>> @198.32.4.13 ep.net soa ; (1 server found) ;; res options: init recurs defnam dnsrch ;; res_send to server 198.32.4.13: Connection timed out Any insight or answer on how to register for IPs at an exchange ( since the exchange operators are just as stumped ) would be greatly appreciated. Thanks, -Chris -- \\\|||/// \ StarNet Inc. \ Chris Parker \ ~ ~ / \ WX *is* Wireless! \ Director, Engineering | @ @ | \ http://www.starnetwx.net \ (847) 963-0116 oOo---(_)---oOo--\------------------------------------------------------ \ Wholesale Internet Services - http://www.megapop.net

4 3

Re: Reverse DNS and SMTP
by David Charlap 28 Feb '02

28 Feb '02

Jared Mauch wrote: > > What I do is format my smtp headers such that a very simple > regex can find mail with no reverse dns and dump it in a spam folder. > I find this catches a lot of the messages. If your server is using a heuristic that has the potential of offending your customers, you can make the blocking optional. More specifically, respond to the "spam detected" condition by writing a header that customers can check for. Once that header's in place, a customer can configure his mail client to accept, delete, or spam-folder the message. If a client wants these kinds of messages to be deleted on the server, that may not be too hard to do either, once the header is written. -- David

1 0

Re: Reverse DNS and SMTP
by Conrad A. Rockenhaus 28 Feb '02

28 Feb '02

Patrick Muldoon <doon(a)inoc.net> said: > > If an ISP who doesn't have reverse DNS setup correctly on their > mail servers, we point them to the RFC's and generally offer to help > them correct it. > We have noticed that our spam has reduced drastically, and the > complaints are few, but alas this is a double edged sword, where if you > even block 1 legitimate e-mail out of the 100K+ that we receive daily, > someone is going to complain. To be honest, I would do this as a last resort. For example, if their ISP's (or their own, if they have the block delegated) DNS server is misconfigured, etc, you might have a issue. Also, some admins have no clue what reverse dns is, seriously :). I would use a service like MAPS first to see if that resolves the issue, and use this as a last resort. If they don't have an issue with blocking unresolvable ips, then they shouldn't have an issue with just using an rbl ;). --conradr

1 0

RE: Reverse DNS and SMTP
by Pete Stephenson 28 Feb '02

28 Feb '02

>A better solution is to check the ip and see if it is an MX record for >the domain the mail purports to be from. [de-lurk] Perhaps, but do recall that there are systems out there which have certain servers listed in the MX records for receiving mail, and different servers for sending mail that aren't listed in the MX records. You can't please everybody, I guess. Apologies to Daniel, as he would receive two copies of this message. -- Pete Stephenson HeyPete.com

1 0

Re: Satellite latency
by Mark Allman 28 Feb '02

28 Feb '02

> > if you adjust the window size on the sending and receiving > > systems, you can improve this, but this solution is impractical, > > as you would need to get everyone on the internet (or at least > > all of the webservers and websurfers you are servicing) to make > > adjustments to their local TCP stack. > > The receiver is the one that informs the sender how large of a > window it can accept, so it can be practical for a subscriber > installation. It wouldn't be a good idea to park a bunch of > servers behind one of these links, but any receiving node that set > its TCP receive window to 2x the byte/sec capacity of the link > should see decent throughput. No, you need to set things on both sides. The sender has to buffer data until it is ACKed in case it needs to retransmit. So, its buffer needs to be as big as the advertised window or the sender buffer will effectivly limit the advertised window. allman -- Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/

2 1