August 2004 - Test - lists.nanog.org

BGP Redistribution question
by D Train 10 Aug '04

10 Aug '04

While looking into a routing issue, I found that one of my routers wasn't passing one of my static routes, being redist into ospf into bgp, and not sure as to why. It has been a while since I have worked with BGP, so I am a little rusty. The solution was for me to add the following BGP network statement... network 10.86.8.0 mask 255.255.248.0. If statics are being redist info ospf, and ospf is basically being redist into bgp, why did I have to have the network statement. Why didn't it put it into BGP and pass it along? Here is the scenario: Router A: ip route 10.86.8.0 255.255.248.0 10.86.138.14 ATL--CR6513A#ping 10.86.138.14 success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms ATL -CR6513A#sh ip route 10.86.8.0 Routing entry for 10.86.8.0/21 Known via "static", distance 1, metric 0 Redistributing via ospf 1 Advertised by ospf 1 subnets bgp 2 Routing Descriptor Blocks: * 10.86.138.14 Route metric is 0, traffic share count is 1 ATL-CR6513A#sh ip ospf data ext 10.86.8.0 OSPF Router with ID (10.86.194.5) (Process ID 1) Type-5 AS External Link States Routing Bit Set on this LSA LS age: 898 Options: (No TOS-capability, DC) LS Type: AS External Link Link State ID: 10.86.8.0 (External Network Number ) Advertising Router: 10.86.194.2 LS Seq Number: 80000D87 Checksum: 0x3D49 Length: 36 Network Mask: /21 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 0.0.0.0 External Route Tag: 0 LS age: 554 Options: (No TOS-capability, DC) LS Type: AS External Link Link State ID: 10.86.8.0 (External Network Number ) Advertising Router: 10.86.194.5 LS Seq Number: 80000D87 Checksum: 0x2B58 Length: 36 Network Mask: /21 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 0.0.0.0 External Route Tag: 0 ATL-CR6513A#sh ip bgp 10.86.8.0 BGP routing table entry for 10.86.0.0/16, version 1078065 Paths: (2 available, best #2, table Default-IP-Routing-Table) Multipath: eBGP Advertised to non peer-group peers: 10.1.2.9 1, (aggregated by 1 10.1.254.253) 10.1.2.9 from 10.1.2.9 (10.1.254.253) Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate, multipath 1, (aggregated by 1 10.1.254.252) 10.1.2.1 from 10.1.2.1 (10.1.254.252) Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate, multipath, best router ospf 1 redistribute static subnets router bgp 2 no synchronization network x.x.x.x network y.y.y.y network 10.86.8.0 mask 255.255.248.0 ***had to be added for this to work, but wasn't present before hand*** redistribute connected route-map OSPF-Links redistribute ospf 1 route-map WW-OSPF-Routes neighbor 10.1.2.1 remote-as 1 neighbor 10.1.2.1 advertisement-interval 1 neighbor 10.1.2.9 remote-as 1 neighbor 10.1.2.9 advertisement-interval 1 maximum-paths 2 no auto-summary route-map WW-OSPF-Routes permit 10 set metric-type internal This is I was seeing on my Upstream Core router: ATL -CR12406A#sh ip route 10.86.8.0 Routing entry for 10.86.0.0/16 Known via "bgp 1", distance 200, metric 0, type locally generated Routing Descriptor Blocks: * directly connected, via Null0 Route metric is 0, traffic share count is 1 AS Hops 0, BGP network version This is what I was seeing after I add the network statement: GAATL-WW1-CR12406A#sh ip bgp 10.86.8.0 BGP routing table entry for 10.86.8.0/21, version 2210556 Paths: (2 available, best #2, Advertisements suppressed by an aggregate.) Multipath: eBGP iBGP Not advertised to any peer 2 10.1.2.2 from 10.1.2.2 (10.86.194.5) Origin IGP, metric 0, localpref 100, valid, external, multipath 2 10.1.2.6 from 10.1.2.6 (10.86.194.2) Origin IGP, metric 0, localpref 100, valid, external, multipath, best __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail

2 1

Re: that MIT paper again
by Paul Vixie 10 Aug '04

10 Aug '04

i wrote: > wrt the mit paper on why small ttl's are harmless, i recommend that > y'all actually read it, the whole thing, plus some of the references, > rather than assuming that the abstract is well supported by the body. > > http://nms.lcs.mit.edu/papers/dns-imw2001.html here's what i've learned by watching nanog's reaction to this paper, and by re-reading the paper itself. 1. almost nobody has time to invest in reading this kind of paper. 2. almost everybody is willing to form a strong opinion regardless of that. 3. people from #2 use the paper they didn't read in #1 to justify an opinion. 4. folks who need academic credit will write strong self-consistent papers. 5. those papers do not have to be inclusive or objective to get published. 6. on the internet, many folks by nature "think locally and act globally". 7. #6 includes manufacturers, operators, endusers, spammers, and researchers. 8. the confluence of bad science and disinterested operators is disheartening. 9. good "actual policy" must often fly in the face of "accepted mantra". we now return control of your television set to you.

2 1

OpenSRS outage
by John Rumpelein 08 Aug '04

08 Aug '04

Folks, I apologize if this isn't the best forum for the question, but does anyone know what is going on with OpenSRS? I have multiple customers on their spam-filtering service (quite handy until about 8 hours ago) whose MX records have been dropped. Then I noticed two of the their three DNS servers are not responding. The third seems to have developed amnesia. Their website appears to be affected as well. -J

1 0

Research - Valid Data Gathering vs. Annoying Other
by Robert Bonomi 07 Aug '04

07 Aug '04

To: nanog(a)merid.edu Subject: Re: Research - Valid Data Gathering vs Annoying Others > Date: Fri, 6 Aug 2004 14:09:01 -0400 (EDT) > From: John K Lerchey <lerchey(a)andrew.cmu.edu> > To: nanog(a)merit.edu > Subject: Research - Valid Data Gathering vs Annoying Others > > > Hi NANOG folks, > > We have a situation (which has come up in the past) that I'd like some > opinions on. [[.. $ mount /dev/soapbox # you have been warned. ..]] > Periodically, we have researchers who develop projects which will do > things like randomly port probe off-campus addresses. The most recent > instance of this is a group studying "bottlenecks" on the internet. Thus, > they hit hosts (again, semi-randomly) on both the commodity internet and > on I2 (abeline) to look for places where there is "traffic congestion". > > The problem is that many of their "random targets" consider the probes to > be either malicious in nature, or outright attacks. Why not? "Their network, *THEIR* rules." *HOW* is one supposed to tell a 'benign' probe from a 'hostile' one, when it is addressed to a machine that doesn't exist, or to a 'service' that doesn't exist on an existant machine? With all the 'overtly hostile' traffic out there, why on earth would anyone consider that, with regard to 'unexpected'/'abnormal' traffic, there should be _any_ 'expectation of innocence'? Surely you don't think that the 'recipient' needs to do a _complete_analysis_ of "what was being attempted, and why" -- including making a determination of the 'intentions' of the perpetrator -- for -every- 'unauthorized' attempt to use their network, before complaining about the fact of an attempt at 'unauthorized use'? I have a very _simple_ rule -- if it isn't intended for a service I make available, on a machine I let the world have access to, then it is, _by_ definition_, an attempt to access that machine 'without authorization, or in excess of the authorization granted'. Because the -only- 'authorized use is those things whiich I expressly let past my firewall. Ergo, if the firewall blocks it, it _IS_ an 'unauthorized access' attempt. Whereupon, 18 USC 1030 (b), becomes *very* relevant, given the language of 18 USC (a) (2) (C). The minimum penalty is 'up to a year imprisonment'. given any 'extenuating circumstances' and it could be up to 20 years. On my _personal_ network, at home (a /29 -- big wow:), I currently see well over FIFTEEN THOUSAND unauthorized probes per day. Of those, a *maximum* of 1-in-four-thousand *might* "possibly" be legitimate. I give people the 'benefit of the doubt', and assume that these probes are coming from virus-infected (unbeknownst to the owner) machines, rather than 'deliberate, with malice aforethought' hacking attempts by the machine's owner. HOWEVER, that notwithstanding, *EVERY*ONE* gets reported to the responsible _network_operator_ -- as an 'apparent virus-infected machine on your network', With the relevant supporting documentation, and a simple request that the machine be disabled from external network access until it has been sterilized and secured against further infection. The reporting is mostly to help the other operators keep _their_ networks clean. And to get those machines off-line -- so that they cannot infect other 'unprotected' machines. I'm confident _my_ network is adequately protected. <grin> Note: I "don't care" _what_ the 'name' of the machine is -- I don't even check for rDNS, I look up the registered netblock _owner_ of the IP address, at the RIR. And THAT is where the complaint reports go. > As a result of this, > we, of course, get complaints. Deservedly so. > One suggestion that I received fro a co-worker to help to mitigate this is > to have the researchers run the experiments off of a www host, and to have > the default page explain the experiment and also provide contact info. People are supposed to 'take it on faith' that what the website _says_ about what is going on _is_ what is *actually* happening? I hope you don't mind if I laugh -- Computerized 'social engineering', in an attempt to deflect complaints, _is_ a humorous concept. Do you *really* think that anybody is going to bother to go look to see _what_ the source system 'claims' is the reason it is doing what it is doing? If the traffic isn't a webserver _response_, then the fact that it comes from a machine named 'www.{something}' just means that something *unrelated* to the webserver is also running on that machine. And, therefore, no reason to believe that the webserver at that (coincidentally same) address would have any information whatsoever about the 'offensive' behavior observed.) I wouldn't even know *IF* an 'offending' machine had such a name. I don't do rDNS look-ups on any of the addresses I send complaints off about. > We also discussed having the researchers contact ISPs and other large > providers to see if they can get permission to use addresses in their > space as targets, and then providing the ISPs with info from the testing. This is one of two _good_ approaches. "Get Permission. *FIRST*" > How do you view the issue of experiments that probe random sites? Should > this be accepted as "reasonable", or should it be disallowed? Something > in between? "Private property is *private* property." The Internet consists *exclusively* of private property. those who own the property get to make the rules for -their- property. What 'everybody else' thinks are 'appropriate' rules is immaterial to how they run -their- property. (Well, except that if 'everybody else' doesnt like the way you run your property, they *are* free to choose to not let you visit _their_ property. :) If _I_ say that thus-and-such is an 'objectionable use' of *my* property, nobody, but *nobody*, has any standing to contradict me. Virtually _every_ AUP says that 'your' use of 'foreign' networks is subject to what _they_ (the foreign netowrk operator) deems to be 'acceptable' use of *their* network. The fact that complaints _are_ being generated is *proof* that they do not think that such is 'acceptable use'. And that, therefore, the perpetrators (despite 'good intentions') *ARE*, in all liklihood, in violation of _their_ _own_ TOS/AUP. > What other suggestions might you have about how such experiments could be > run without triggering alarms? That is *easy*. TRIVIALLY EASY. _rent_ a node on those foreign networks. run probes _to_ the hosts *you* control. (This is the second good approach: "Buy access.") Voila! "No problem." >From a pure philosophical standpoint, 'random testing' is no different than "spamming". Both rely on the use of "other people's resources", *WITHOUT* the consent/permission of those other people, and covering the costs of the resources involved. Since the 'testee' is paying for fully half of the costs of the testing, they must be consulted _in_advance_. If you want to claim that the testing "isn't wrong" because it only costs any testee an 'insignificant' amount, You better be prepared to accept all the traffic from the spammers who use exactly the same 'defense'. Executive summary: Method of choice: "Get Permission. *FIRST*." If that fails, try: "Buy Access." If =that= fails, then "Don't Do it!"

13 13

Research - Valid Data Gathering vs Annoying Others
by John K Lerchey 07 Aug '04

07 Aug '04

Hi NANOG folks, We have a situation (which has come up in the past) that I'd like some opinions on. Periodically, we have researchers who develop projects which will do things like randomly port probe off-campus addresses. The most recent instance of this is a group studying "bottlenecks" on the internet. Thus, they hit hosts (again, semi-randomly) on both the commodity internet and on I2 (abeline) to look for places where there is "traffic congestion". The problem is that many of their "random targets" consider the probes to be either malicious in nature, or outright attacks. As a result of this, we, of course, get complaints. One suggestion that I received fro a co-worker to help to mitigate this is to have the researchers run the experiments off of a www host, and to have the default page explain the experiment and also provide contact info. We also discussed having the researchers contact ISPs and other large providers to see if they can get permission to use addresses in their space as targets, and then providing the ISPs with info from the testing. How do you view the issue of experiments that probe random sites? Should this be accepted as "reasonable", or should it be disallowed? Something in between? What other suggestions might you have about how such experiments could be run without triggering alarms? Please send any suggestions directly to me and once I have some answers, I'll post a compilation to the list. Thanks! John John K. Lerchey Computer and Network Security Coordinator Computing Services Carnegie Mellon University

2 1

RE: Research - Valid Data Gathering vs. Annoying Other
by Michel Py 07 Aug '04

07 Aug '04

> John K. Lerchey wrote: > The problem is that many of their "random targets" consider > the probes to be either malicious in nature, or outright > attacks. As a result of this, we, of course, get complaints. [me puts the politician/opportunist suit on. It's election year, after all]. The one thing I would suggest, if you get complaints, talk to the dude that wrote the "testing" thing to make it look like an attack than it currently appears. Vote for me. [/suit off] That being said, you might want to read again an excellent post from Steve Atkins earlier :-) OMG, someone from China just tried to telnet to my router. I'm calling the FBI, the CIA and the NSA right away. The vty password is "san-fran" not "cisco", bozo. > One suggestion that I received fro a co-worker to help to > mitigate this is to have the researchers run the experiments > off of a www host, and to have the default page explain the > experiment and also provide contact info. Good idea, but largely useless as described, IMHO. I would suggest a better way, have the reverse lookup (PTR) of the testing IP address resolve to something like "see-www-dot-cmu-dot-edu-slash-testing" and have the explaining web page there; this might help with GWF[1] > We also discussed having the researchers contact ISPs and other > large providers to see if they can get permission to use addresses > in their space as targets, and then providing the ISPs with info > from the testing. The answer is no. > How do you view the issue of experiments that probe random > sites? Should this be accepted as "reasonable", or should > it be disallowed? Something in between? Irrelevant. Each operator and network admin will have a different opinion about it, and we all filter traffic the way we see fit. You will not get anything remotely close to a consensus here. [1] GWF > Steve Atkins wrote: > [GWF] Goober With Firewall. Originally from internal jargon > at abuse(a)above.net - a complaint, for example, that > "ns1.above.net is hackoring my port 53!" would be, and > should still be, closed with the sole annotation being "GWF". Alternate acronym meaning: Goon With Firewall. GWFes are mostly a by-product of IDS sales droids: first, they find one of these goober execs to attend a demo, then they crank up their gizmo that will find "high risk" alarms out of the ordinary network noise, then the exec hires a cheaper banana^H^H^H^H^H peanut eater aka GWS that does not know jack and has nothing to do but investigate the IDS alarms. The only thing that worries me about the recommendation I am about to make is that it is the same that we collectively used to think was the appropriate answer to spam (a long time ago): the delete key is your friend. Michel.

1 0

Reporting the state of an apparatus to a remote computer patented
by Scott Whyte 06 Aug '04

06 Aug '04

Thought this was relevent to nanog readership.. Abstract The state of an apparatus is reported to a remote computer using an embedded device in the apparatus. The embedded device detects the state, generates an electronic mail message that reports the state using a self-describing computer language, and sends the electronic mail message to the remote computer. The remote computer receives the electronic mail message and extracts the state of the embedded device from the message. http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=… Further, "Axeda has 11 additional patents pending in the United States and 10 international patents pending covering other aspects of the remote management of intelligent devices." http://www.axeda.com/products/drm-technology/patented-technology.html

4 4

low-latency bandwidth for cheap?
by Jeff Wheeler 06 Aug '04

06 Aug '04

This may be the wrong forum to ask this, and if so I apologize, please just point me in the right direction! I'm getting somewhat frustrated with the instability and high latency of residential cable and DSL offerings, but I love the T1 or greater bandwidth they offer. I'd like reasonable bandwidth with low latency without spending hundreds of dollars per month! Anybody know a good source for near-T1 low-latency bandwidth at around $100/month? I'm in the northern VA area btw. -- Jeff Wheeler Postmaster, Network Admin US Institute of Peace

11 14

Regional transit pricing differences?
by Steve Gibbard 06 Aug '04

06 Aug '04

I'm attempting to do some research on how having a local exchange point affects transit pricing. Common sense and anecdotal evidence suggests that transit should be and is cheaper when the data can be handed off through local peering, but I don't have any hard data to back that up. I'm hoping I can get answers to the following questions from a large number of US ISPs in a wide variety of locations: - What city or area are you in? - What city do you buy your transit in? - How far do you have to haul the data from where you buy the transit to where you use it? - How much are you paying for your transit connections -- dollars per megabit per second and how many megabits per second? - How much are you paying for circuits to connect you to the transit provider, if the circuits aren't included? - Do you peer at an exchange point? If so: - Which one? - How close is it to you? - How much are you paying for the port, and for how much traffic? - How much are you paying for circuits to get to the exchange? I'm looking for actual negotiated prices, not opening offers from sales people. I'm only really looking for US data at this point. I'll probably ask this question again about other countries at some point in the future, but at this point involving multiple countries would introduce too many other variables. I recognize that a lot of this information is covered under non-disclosure agreements, and may also be seen as sensitive internal company information. Therefore, I don't want to know who the transit providers are, and I don't particularly need to know who you are. I'm planning to aggregate the data together by region, and publish only the aggregates, not the data from any individual networks. I probably won't post an immediate summary to the list, but I should have a paper on the subject written by Mid-October. Thanks, Steve Gibbard Packet Clearing House

1 0

Weekly Routing Table Report
by Routing Table Analysis 06 Aug '04

06 Aug '04

This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats(a)lists.apnic.net If you have any comments please contact Philip Smith <pfs(a)cisco.com>. Routing Table Report 04:00 +10GMT Sat 07 Aug, 2004 Analysis Summary ---------------- BGP routing table entries examined: 143817 Prefixes after maximum aggregation: 85974 Unique aggregates announced to Internet: 69046 Total ASes present in the Internet Routing Table: 17741 Origin-only ASes present in the Internet Routing Table: 15390 Origin ASes announcing only one prefix: 7226 Transit ASes present in the Internet Routing Table: 2351 Transit-only ASes present in the Internet Routing Table: 76 Average AS path length visible in the Internet Routing Table: 4.8 Max AS path length visible: 26 Prefixes from unregistered ASNs in the Routing Table: 4 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 16 Number of addresses announced to Internet: 1308190496 Equivalent to 77 /8s, 249 /16s and 103 /24s Percentage of available address space announced: 35.3 Percentage of allocated address space announced: 57.0 Percentage of available address space allocated: 61.9 Total number of prefixes smaller than registry allocations: 66236 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 27508 Total APNIC prefixes after maximum aggregation: 13952 Prefixes being announced from the APNIC address blocks: 25752 Unique aggregates announced from the APNIC address blocks: 14069 APNIC Region origin ASes present in the Internet Routing Table: 2090 APNIC Region origin ASes announcing only one prefix: 628 APNIC Region transit ASes present in the Internet Routing Table: 328 Average APNIC Region AS path length visible: 4.9 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 154905472 Equivalent to 9 /8s, 59 /16s and 171 /24s Percentage of available APNIC address space announced: 70.7 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 23552-24575 APNIC Address Blocks 58/7, 60/7, 202/7, 210/7, 218/7, 220/7 and 222/8 ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 82367 Total ARIN prefixes after maximum aggregation: 50319 Prefixes being announced from the ARIN address blocks: 63781 Unique aggregates announced from the ARIN address blocks: 22146 ARIN Region origin ASes present in the Internet Routing Table: 9382 ARIN Region origin ASes announcing only one prefix: 3378 ARIN Region transit ASes present in the Internet Routing Table: 922 Average ARIN Region AS path length visible: 4.6 Max ARIN Region AS path length visible: 18 Number of ARIN addresses announced to Internet: 228675232 Equivalent to 13 /8s, 161 /16s and 78 /24s Percentage of available ARIN address space announced: 68.2 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647,29695-30719, 31744-33791 ARIN Address Blocks 24/8, 63/8, 64/6, 68/7, 70/7, 72/8, 198/7, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 26521 Total RIPE prefixes after maximum aggregation: 18762 Prefixes being announced from the RIPE address blocks: 23342 Unique aggregates announced from the RIPE address blocks: 15506 RIPE Region origin ASes present in the Internet Routing Table: 5716 RIPE Region origin ASes announcing only one prefix: 3086 RIPE Region transit ASes present in the Internet Routing Table: 982 Average RIPE Region AS path length visible: 5.4 Max RIPE Region AS path length visible: 26 Number of RIPE addresses announced to Internet: 168597824 Equivalent to 10 /8s, 12 /16s and 153 /24s Percentage of available RIPE address space announced: 59.1 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-34815 RIPE Address Blocks 62/8, 80/5, 88/8, 188/8, 193/8, 194/7, 212/7 and 217/8 LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 6199 Total LACNIC prefixes after maximum aggregation: 2264 Prefixes being announced from the LACNIC address blocks: 5950 Unique aggregates announced from the LACNIC address blocks: 3591 LACNIC Region origin ASes present in the Internet Routing Table: 387 LACNIC Region origin ASes announcing only one prefix: 113 LACNIC Region transit ASes present in the Internet Routing Table: 76 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 15 Number of LACNIC addresses announced to Internet: 15471872 Equivalent to 0 /8s, 236 /16s and 21 /24s Percentage of available LACNIC address space announced: 46.1 LACNIC AS Blocks 26592-26623, 27648-28671 LACNIC Address Blocks 200/7 Emerging AfriNIC Region Analysis Summary ---------------------------------------- Prefixes being announced by AfriNIC Region ASes: 1218 Total AfriNIC prefixes after maximum aggregation: 677 Prefixes being announced from the AfriNIC address blocks: 824 Unique aggregates announced from the AfriNIC address blocks: 652 AfriNIC Region origin ASes present in the Internet Routing Table: 91 AfriNIC Region origin ASes announcing only one prefix: 21 AfriNIC Region transit ASes present in the Internet Routing Table: 13 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 1977344 Equivalent to 0 /8s, 30 /16s and 44 /24s Percentage of available AfriNIC address space announced: 11.8 AfriNIC AS Blocks <none> AfriNIC Address Blocks 196/8 APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4134 818 4097 153 Data Communications Bureau 1221 817 1184 590 Telstra Pty Ltd 4766 548 2897 264 Korea Internet Exchange for " 9583 514 41 97 Satyam Infoway Ltd., 4755 363 133 51 Videsh Sanchar Nigam Ltd. Aut 9443 355 70 80 Primus Telecommunications 2907 353 1840 327 SINET Japan 17676 341 5084 33 XTAGE CORPORATION 9929 333 159 31 China Netcom Corp. 17557 326 23 162 Pakistan Telecom 703 317 342 244 UUNET 2764 289 274 236 connect.com.au pty ltd 7474 264 268 202 Optus Communications Pty Ltd 17633 238 56 6 ASN for Shandong Provincial N 9942 237 71 130 COMindico Australia 4802 227 25 140 Wantree Development 9800 226 370 64 CHINA UNICOM 9498 222 49 52 BHARTI BT INTERNET LTD. 10036 202 18 183 C&M Communication Co. Ltd. 4837 196 2023 106 chinanet IDC center beijing n ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7018 1400 6822 976 AT&T WorldNet Services 701 1297 8426 933 UUNET Technologies, Inc. 6347 951 390 100 SAVVIS Communications Corpora 1239 938 2877 626 Sprint 3356 883 10924 667 Level 3 Communications, LLC 4323 769 587 210 Time Warner Telecom 6197 758 495 309 BellSouth Network Solutions, 18566 739 193 8 Covad Communications 209 614 3445 496 Qwest 721 602 20826 282 DLA Systems Automation Center 20115 568 377 293 Charter Communications 7843 514 677 129 Adelphia Corp. 852 511 1142 399 Telus Advanced Communications 6198 452 395 205 BellSouth Network Solutions, 705 429 163 271 UUNET Technologies, Inc. 7132 426 7921 370 SBC Internet Services 2386 410 534 230 AT&T Data Communications Serv 22773 392 796 64 Cox Communications, Inc. Atla 4355 390 323 101 EarthLink, Inc. 376 384 363 113 Reseau Interordinateurs Scien RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 702 645 2019 536 UUNET - Commercial IP service 3320 302 2469 239 Deutsche Telekom AG 3301 282 1098 271 TeliaNet Sweden 8220 278 448 265 COLT Internet - International 680 244 2025 239 DFN-IP service G-WiN 1257 216 747 185 SWIPnet Swedish IP Network 3246 216 484 213 Song Networks 13083 216 51 8 Mannesmann Datenverarbeitung 5515 199 842 145 Sonera Solution Autonomous Sy 8708 194 113 175 Romania Data Systems S.A. 3215 182 892 77 France Telecom Transpac 786 177 1794 177 The JANET IP Service 25186 173 156 114 France Telecom Transpac's Tra 5400 152 208 123 BT Ignite European Backbone 6746 152 29 129 Dynamic Network Technologies, 719 150 288 102 LANLINK autonomous system 3269 141 1163 64 TELECOM ITALIA 8866 133 15 14 Bulgarian Telecommunication C 3303 130 609 129 Swisscom Ltd 12302 128 18 32 MobiFon S.A. LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 11172 350 83 52 Servicios Alestra S.A de C.V 6140 334 137 64 ImpSat 8151 286 391 132 UniNet S.A. de C.V. 16814 204 13 7 NSS, S.A. 6147 188 86 20 Telefonica Del Peru 6505 136 90 94 Global One Communicaoes Ltda 6503 135 202 91 AVANTEL, S.A. 11664 134 11 22 Keytech SA 7303 121 55 19 Telecom Argentina Stet-France 11556 100 63 22 Cable-Wireless Panama 11992 90 9 30 Integrated Systems 14420 82 6 32 ANDINATEL S.A. 6535 81 5 16 Chilesat Servicios Empresari 11311 81 7 19 Sinectis S.A. 15311 75 19 37 Telefonica Empresas 5639 71 8 8 Telecommunications Services o 4270 70 18 9 Red de Interconexion Universi 14117 69 5 4 Telefonica del Sur S.A. 11340 68 5 37 Red Universitaria Nacional 10292 67 6 26 TELECOMMUNICATIONS OF JAMAICA AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 3741 252 632 219 The Internet Solution 5536 113 16 4 Internet Egypt Network 2018 94 297 92 Tertiary Education Network 2905 92 276 81 The Internetworking Company o 11845 42 9 11 Data Pro Business Online 20928 42 16 1 Noor Advanced Technologies AS 24835 32 18 5 RAYA Telecom - Egypt 9129 29 3 4 UUNET Kenya 14988 29 16 1 Botswana Telecommunications C 6713 26 38 9 Itissalat Al-MAGHRIB 8524 26 2 4 AUCEGYPT Autonomous System 16637 26 9 19 Johnnic e-Ventures 5713 25 125 23 Telkom SA Ltd 12455 23 4 2 Jambonet Autonomous system 10798 18 1 12 Standard Bank of South Africa 8346 15 7 14 SONATEL-AS Autonomous System 12258 15 3 10 Vodacom Internet Company 15706 15 4 2 Sudatel Internet Exchange Aut 15808 13 1 2 Communication Solutions Ltd i 17148 13 1 7 First National Bank Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6347 951 851 SAVVIS Communications Corpora 18566 739 731 Covad Communications 4134 818 665 Data Communications Bureau 4323 769 559 Time Warner Telecom 6197 758 449 BellSouth Network Solutions, 9583 514 417 Satyam Infoway Ltd., 7843 514 385 Adelphia Corp. 701 1297 364 UUNET Technologies, Inc. 5668 382 364 Century Telephone 27364 350 331 Armstrong Cable Services 22909 359 329 Comcast Cable Corporation 22773 392 328 Cox Communications, Inc. Atla 6467 354 322 E.Spire Communications, Inc. 721 602 320 DLA Systems Automation Center 1239 938 312 Sprint 4755 363 312 Videsh Sanchar Nigam Ltd. Aut 17676 341 308 XTAGE CORPORATION 9929 333 302 China Netcom Corp. 11172 350 298 Servicios Alestra S.A de C.V 4355 390 289 EarthLink, Inc. List of Unregistered ASNs (Global) ---------------------------------- Bad AS Designation Network Transit AS Description 65217 PRIVATE 128.101.58.0/28 217 University of Minnes 1877 UNALLOCATED 192.108.199.0/24 1876 Southern Methodist U 63330 RESERVED 213.8.224.0/23 5486 Euronet Digital Comm 63330 RESERVED 213.8.226.0/23 5486 Euronet Digital Comm Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 132.0.0.0/10 721 DLA Systems Automation Center 137.0.0.0/13 721 DLA Systems Automation Center 158.0.0.0/13 721 DLA Systems Automation Center 192.43.230.0/24 4738 South Australian Academic Res 192.44.0.0/19 702 UUNET - Commercial IP service 192.70.164.0/24 25689 National Research Council of 192.83.16.0/20 5515 Sonera Solution Autonomous Sy 192.83.32.0/19 5515 Sonera Solution Autonomous Sy 192.83.96.0/22 5515 Sonera Solution Autonomous Sy 192.83.100.0/24 5515 Sonera Solution Autonomous Sy 192.84.205.0/24 719 LANLINK autonomous system 192.119.135.0/24 270 NASA 192.135.50.0/24 7018 AT&T WorldNet Services 192.136.79.0/24 719 LANLINK autonomous system 192.172.0.0/19 721 DLA Systems Automation Center 192.172.11.0/24 721 DLA Systems Automation Center Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:18 /9:3 /10:6 /11:15 /12:61 /13:129 /14:301 /15:533 /16:7950 /17:2133 /18:3732 /19:9649 /20:10098 /21:7482 /22:10401 /23:11942 /24:78660 /25:226 /26:193 /27:113 /28:48 /29:18 /30:65 /31:0 /32:41 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6347 730 951 SAVVIS Communications Corpora 18566 722 739 Covad Communications 6197 579 758 BellSouth Network Solutions, 7018 537 1400 AT&T WorldNet Services 3356 500 883 Level 3 Communications, LLC 702 401 645 UUNET - Commercial IP service 701 366 1297 UUNET Technologies, Inc. 1239 366 938 Sprint 9583 359 514 Satyam Infoway Ltd., 4766 356 548 Korea Internet Exchange for " 27364 336 350 Armstrong Cable Services 5668 334 382 Century Telephone 6198 334 452 BellSouth Network Solutions, 20115 301 568 Charter Communications 9929 265 333 China Netcom Corp. 6467 259 354 E.Spire Communications, Inc. 13609 257 300 Choice One Communications Inc 6517 255 281 Yipes Communications, Inc. 14824 253 277 NewSouth Communications Corp. 3320 249 302 Deutsche Telekom AG Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:3 8:2 12:832 13:1 15:5 16:2 17:3 20:9 24:733 32:66 33:2 38:78 40:54 44:4 55:1 56:3 57:16 60:6 61:440 62:513 63:1897 64:2199 65:2051 66:2751 67:348 68:515 69:681 70:64 80:536 81:370 82:190 83:126 84:17 128:176 129:171 130:84 131:183 132:23 134:184 135:17 136:174 137:54 138:170 139:35 140:165 141:107 142:118 143:60 144:100 145:42 146:290 147:94 148:418 149:110 150:88 151:70 152:162 153:67 154:2 155:129 156:57 157:67 158:137 159:147 160:54 161:71 162:387 163:78 164:177 165:162 166:111 167:217 168:254 169:114 170:282 171:9 192:5578 193:2846 194:2078 195:1418 196:583 198:3663 199:3254 200:3646 201:11 202:4783 203:5650 204:3125 205:2076 206:2276 207:2508 208:2164 209:3059 210:1423 211:575 212:1003 213:1202 214:86 215:30 216:3787 217:991 218:177 219:127 220:245 221:30 222:131 End of report

1 0