- Test - lists.nanog.org

OT: tos bits - current usage
by Simon Waters 18 Jan '04

18 Jan '04

Can anyone point me to any resources describing the current usage of the tos precedence bits. Specifically what happens in practice, not what is suppose to happen (I can find the RFC's and IETF documents okay). Prompted by noting that a lot of spambots set the lowest precedence bit (tos 0x20 in tcpdump), I assume this is just a reflection of what operating system is in use/has been compromised? Internet search engines seem to think the whole point of the tos bits is to allow you to more accurately fingerprint remote operating systems, at least that is what the naive searcher might conclude.

1 0

Re: One-element vs two-element design
by Brent_OKeeffe＠asc.aon.com 18 Jan '04

18 Jan '04

One key consideration you should think about is the ability to perform maintenance on redundant devices in the N+1 model without impacting the availability of the network. Brent Timothy Brown <tim(a)tux.org> Sent by: owner-nanog(a)merit.edu 01/16/2004 10:14 PM To: nanog(a)merit.edu cc: Subject: One-element vs two-element design I fear this may be a mother of a debate. In my (short?) career, i've been involved in several designs, some successful, some less so. I've recently been asked to contribute a design for one of the networks I work on. The design brings with it a number of challenges, but also, unlike a greenfield network, has a lot of history. One of the major decisions i'm being faced with is a choice between one-element or two-element design. When I refer to elements, what I really mean to say is N or N+1. For quite some time now, vendors have been improving hardware to the point where most components in a given device, with the exception of a line card, can be made redundant. This includes things like routing and switching processors, power supplies, busses, and even, in the case of vendor J and several others, the possibility of inflight restarts of particular portions of the software as part of either scheduled maintenance or to correct a problem. I have always been traditionally of the school of learning that states that it is best to have two devices of equal power and on the same footing, and, in multiple site configurations, four devices of equal power and equal footing. I feel like a safe argument to make is N+1, so that is the philosophy that I tend to adopt. N+2 or N...whatever doesn't seem to add a lot of additional security into the network's model of availability. This adds complexity, but I prefer to think of this in terms of, "Well, I can manage software or design complexity in my configurations, but I can't manage the loss of a single device which holds my network together." Now I must view this assertion in the context of better designed hardware and cheap spares-on-hand. Of course, like many other folks, I have tried to drink as deeply as I can from the well of knowledge. I've perused at length Cisco Press' High Availability Network Fundamentals, and understand MTBF calculations and some of the design issues in building a highly available network. But from a cost perspective, it seems that a single, larger box may be able to offer me as much redundancy as two equally configured boxes handling the same traffic load. Of course, there's that little demon on my shoulder, that tells me that I could always lose a complete device due to a power issue or short, and then i'd be up a creek. We have a history of adopting the N+1 model on the specific network i'm talking about, and it has worked very well so far in the face of occassional software failures by a vendor we occassionally have ridiculed here on nanog-l. However, in considering a comprehensive redesign, another vendor offers significantly more software stability, so i'm re-evaluating the need for multiple devices. My mind's more or less already made up, but i'd like to hear the design philosophies of other members of the operational community when adopting a N+1 approach. In particular, i'd love to hear a catastrophic operational failure which either proves or disproves either of the potential options. Tim ObDisclaimer: Please contact me off-list if you're okay with your thoughts on this matter being published in a book targeted to the operations community.

5 5

Re: router design (was Re: /24s run amuck)
by Richard A Steenbergen 17 Jan '04

17 Jan '04

On Tue, Jan 13, 2004 at 02:12:13PM -0500, Craig Partridge wrote: > > The basic issue here is the huge difference between a nice, dense, slow > and relatively cool [cheap!] DRAM and very fast, not so dense, and pretty hot > [and very expensive] SRAM. That Dell server has DRAM. Your route processor > (if the router is at all fast) needs SRAM (and of the ultra-fast expensive > variety). You're talking about the fib, I'm talking about the rib. Lets just assume for the sake of argument that your 8mb of sram is enough to scale to a million routes and is not a problem (or maybe not if you want to run a bunch of seperate routing tables, but that is an unrelated issue :P). There isn't really a reason why a route processor produced in the last 3 years needs sram at all. > And, oh by the way, for good performance the route processor usually > needs to share the same card as the link termination equipment -- those > nice lasers, and optical termination chips -- which eat board space and > generate heat you might otherwise budget for more route processor > memory. Nah. Every modern routing device worth any kind of time or attention uses something other than software lookups off the RP, even if it's just hacking l3 info into a switch cam. Even if there does exist a slow path through the route processor, it is assumed that if you hit it you're already screwed. The bandwidth necessary to distribute the forwarding information to the cards or other forwarding components is trivial. As far as pricing for these things goes, let us take an example here... The Juniper routing engine is actually a 6U blade server on it's side: http://www.kontron.com/products/pdproductsubcategory.cfm?keyProductCategory… I understand the need for compact components as space is limited, I understand the performance limitations of using laptop components, and I don't expect to see that kind of board upgradable to whatever processors are out 3 years from now. But don't tell me that you can't sell the 2GHz model that is available today instead of the p2 333mhz or the recently introduced p3 600mhz, or that it costs anywhere near $20,000 for that blade server. :) -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

2 1

One-element vs two-element design
by Timothy Brown 17 Jan '04

17 Jan '04

I fear this may be a mother of a debate. In my (short?) career, i've been involved in several designs, some successful, some less so. I've recently been asked to contribute a design for one of the networks I work on. The design brings with it a number of challenges, but also, unlike a greenfield network, has a lot of history. One of the major decisions i'm being faced with is a choice between one-element or two-element design. When I refer to elements, what I really mean to say is N or N+1. For quite some time now, vendors have been improving hardware to the point where most components in a given device, with the exception of a line card, can be made redundant. This includes things like routing and switching processors, power supplies, busses, and even, in the case of vendor J and several others, the possibility of inflight restarts of particular portions of the software as part of either scheduled maintenance or to correct a problem. I have always been traditionally of the school of learning that states that it is best to have two devices of equal power and on the same footing, and, in multiple site configurations, four devices of equal power and equal footing. I feel like a safe argument to make is N+1, so that is the philosophy that I tend to adopt. N+2 or N...whatever doesn't seem to add a lot of additional security into the network's model of availability. This adds complexity, but I prefer to think of this in terms of, "Well, I can manage software or design complexity in my configurations, but I can't manage the loss of a single device which holds my network together." Now I must view this assertion in the context of better designed hardware and cheap spares-on-hand. Of course, like many other folks, I have tried to drink as deeply as I can from the well of knowledge. I've perused at length Cisco Press' High Availability Network Fundamentals, and understand MTBF calculations and some of the design issues in building a highly available network. But from a cost perspective, it seems that a single, larger box may be able to offer me as much redundancy as two equally configured boxes handling the same traffic load. Of course, there's that little demon on my shoulder, that tells me that I could always lose a complete device due to a power issue or short, and then i'd be up a creek. We have a history of adopting the N+1 model on the specific network i'm talking about, and it has worked very well so far in the face of occassional software failures by a vendor we occassionally have ridiculed here on nanog-l. However, in considering a comprehensive redesign, another vendor offers significantly more software stability, so i'm re-evaluating the need for multiple devices. My mind's more or less already made up, but i'd like to hear the design philosophies of other members of the operational community when adopting a N+1 approach. In particular, i'd love to hear a catastrophic operational failure which either proves or disproves either of the potential options. Tim ObDisclaimer: Please contact me off-list if you're okay with your thoughts on this matter being published in a book targeted to the operations community.

1 0

Re: /24s run amuck
by Michael.Dillon＠radianz.com 16 Jan '04

16 Jan '04

>> The thing that surprises me is that there aren't any small >> vendors offering fairly generic routing boxes, i.e. Intel-based >imagestream does this, afaik. not too familiar with their offerings though. I stand corrected. The following page comparing Cisco and Imagestream is quite interesting. http://www.imagestream.com/Cisco_Comparison.html How many of you would buy an Imagestream box to evaluate for your next network buildout? --Michael Dillon

22 26

IANA IPv4 allocations and bogon update: 70/8
by Rob Thomas 16 Jan '04

16 Jan '04

Hi, NANOGers. Nope, we didn't forget or ignore it. :) The numerous Team Cymru bogon projects have been updated as of 15 JAN 2004 to reflect the following IANA allocation made on 15 JAN 2004: 70/8 Jan 04 ARIN IANA allocations change over time, so please check regularly to ensure you have the latest filters if you are not using the bogon BGP feed(s). We do announce updates to the bogon projects to sundry lists, such as the bogon-announce list. We can not stress this point strongly enough - these allocations change. If you do not adjust your filters, you will be unable to access perhaps large portions of the Internet. Worse yet, you may end up blocking access for people who transit through you. Please do not blindly apply any filters or blocks to your network without carefully considering the ramifications of doing so. As a point of reference, the Team Cymru master Bogon Reference Page can be found here: <http://www.cymru.com/Bogons/> A quick summary of the documents and projects that have been updated include the following: HTTP The Bogon List The Text Bogon List, Unaggregated The Text Bogon List, Aggregated Secure BIND Template Secure IOS Template (Cisco) Secure BGP Template (Cisco) Secure JUNOS Template (Juniper) Secure JUNOS BGP Template (Juniper) Ingress Prefix Filter Templates, Loose and Strict (Cisco) Ingress Prefix Filter Template, Loose (Juniper) Ingress Prefix Filter Template, Strict (Juniper) BGP Bogon route-server * RADb fltr-unallocated fltr-martian fltr-bogons DNS Bogon (bogons.cymru.com) zone Monitoring Bogon prefix monitoring * All of the bogon peers have received the appropriate BGP prefix updates. Please feel free to contact Team Cymru with any comments, questions, or concerns. We hope to see you in [sunny|warm|no snow] Miami! :) Thanks! Rob, for Team Cymru. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);

1 0

Re: "Third Level" domains not patented
by Michael.Dillon＠radianz.com 16 Jan '04

16 Jan '04

>Uh, no, that's not what the article said and it's not what the patent, >which is linked from the article, says. The patent is on the tiny >tweak of selling matching e-mail addresses and domains (it says URLs >but their examples show domains) of the form argle(a)bargle.tld and >argle.bargle.tld. I'm sure there is prior art from the discussions in 1996 but I can't remember enough details to dig that up. However here is something from 2 Jan 1997 that is clearly prior art for the selling personal domain names to people in the form first.last.something. http://listes.cru.fr/wws/arc/isoc.nommage/1997-01/msg00017.html Pass it on to anyone else who may be interested. --Michael Dillon

1 0

Re: "Third Level" domains patented?
by Michael.Dillon＠radianz.com 16 Jan '04

16 Jan '04

>According to the article, somebody maanged to patent the selling of >www.something.somethng.com. Which seems a bit assanine to me, since the >ISP I worked for in 1993 offered custoemrs www.customer.ccnet.com. >As much as I dislike Verisign, this is silly. Agreed. Here is some of my prior art from 1996 http://www.gtld-mou.org/gtld-discuss/mail-archive/01815.html and I may have mentioned it even earlier than this. I also consulted for the GNR during their application for the .NAME registry so there is a direct connection between the idea published in 1996 and the current .NAME registry which is the subject of the Verisign lawsuit. --Michael Dillon

4 3

Re: PC Routers (was Re: /24s run amuck)
by neil＠DOMINO.ORG 16 Jan '04

16 Jan '04

> As I remember, it used commercial gated. It used a heavily modifed public that IEng worked on. The guys at IEng were fantastic and did a huge amount of fixing and feature adding of features. I think Cisco bought IEng. Regards, Neil.

2 1

The Cidr Report
by cidr-report＠potaroo.net 16 Jan '04

16 Jan '04

This report has been generated at Fri Jan 16 21:47:34 2004 AEST. The report analyses the BGP Routing Table of an AS4637 (Reach) router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/as4637 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 09-01-04 129599 90707 10-01-04 129356 90679 11-01-04 129333 90639 12-01-04 129384 90638 13-01-04 129403 90939 14-01-04 129391 90995 15-01-04 129533 90914 16-01-04 129605 90920 AS Summary 16399 Number of ASes in routing system 6577 Number of ASes announcing only one prefix 1381 Largest number of prefixes announced by an AS AS701 : ALTERNET-AS UUNET Technologies, Inc. 73450752 Largest address span announced by an AS (/32s) AS568 : SUMNET-AS DISO-UNRRA Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 16Jan04 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 129677 90936 38741 29.9% All ASes AS4323 677 206 471 69.6% TW-COMM Time Warner Communications, Inc. AS6197 772 304 468 60.6% BATI-ATL BellSouth Network Solutions, Inc AS701 1381 958 423 30.6% ALTERNET-AS UUNET Technologies, Inc. AS7018 1377 955 422 30.6% ATT-INTERNET4 AT&T WorldNet Services AS7843 510 122 388 76.1% ADELPHIA-AS Adelphia Corp. AS4134 676 302 374 55.3% CHINANET-BACKBONE No.31,Jin-rong Street AS27364 379 34 345 91.0% ACS-INTERNET Armstrong Cable Services AS6198 546 219 327 59.9% BATI-MIA BellSouth Network Solutions, Inc AS22909 328 17 311 94.8% DNEO-OSP1 Comcast Cable Communications, Inc. AS22773 331 31 300 90.6% CCINET-2 Cox Communications Inc. Atlanta AS1239 953 669 284 29.8% SPRINTLINK Sprint AS4355 380 100 280 73.7% ERMS-EARTHLNK EARTHLINK, INC AS9583 294 25 269 91.5% SATYAMNET-AS Satyam Infoway Ltd., AS1221 906 653 253 27.9% ASN-TELSTRA Telstra Pty Ltd AS17676 291 43 248 85.2% GIGAINFRA Softbank BB Corp. AS6347 330 83 247 74.8% DIAMOND SAVVIS Communications Corporation AS25844 243 16 227 93.4% SKADDEN1 Skadden, Arps, Slate, Meagher & Flom LLP AS6140 353 129 224 63.5% IMPSAT-USA ImpSat AS209 724 509 215 29.7% ASN-QWEST Qwest AS14654 209 3 206 98.6% WAYPORT Wayport AS6478 257 53 204 79.4% ATT-INTERNET3 AT&T WorldNet Services AS11305 234 41 193 82.5% INTERLAND-NET1 Interland Incorporated AS2386 416 226 190 45.7% INS-AS AT&T Data Communications Services AS4519 199 17 182 91.5% MAAS Maas Communications AS6327 205 28 177 86.3% SHAW Shaw Communications Inc. AS20115 578 408 170 29.4% CHARTER-NET-HKY-NC Charter Communications AS9929 196 28 168 85.7% CNCNET-CN China Netcom Corp. AS15270 206 39 167 81.1% AS-PAETEC-NET PaeTec.net -a division of PaeTecCommunications, Inc. AS2048 249 84 165 66.3% LANET-1 State of Louisiana AS5668 323 159 164 50.8% AS-5668 CenturyTel Internet Holdings, Inc. Total 14523 6461 8062 55.5% Top 30 total Possible Bogus Routes 24.138.80.0/20 AS11260 ANDARA-HSI Andara High Speed Internet c/o Halifax Cable Ltd. 61.12.32.0/24 AS7545 TPG-INTERNET-AP TPG Internet Pty Ltd 61.12.34.0/24 AS7545 TPG-INTERNET-AP TPG Internet Pty Ltd 64.62.126.0/23 AS25700 SWIFTDESK SWIFTDESK VENTURE 65.61.96.0/20 AS30340 ASN-LLIP Liberty Lake Internet Portal 66.41.192.0/18 AS13367 CCCH-AS3 Comcast Cable Communications Holdings, Inc 66.114.0.0/19 AS16526 BIRCH-TELECOM Birch Telecom, Inc. 66.114.28.0/24 AS15083 INFOLINK-MIA-US Infolink Communication Services, Inc. 66.114.29.0/24 AS15083 INFOLINK-MIA-US Infolink Communication Services, Inc. 66.114.30.0/24 AS15083 INFOLINK-MIA-US Infolink Communication Services, Inc. 66.114.31.0/24 AS15083 INFOLINK-MIA-US Infolink Communication Services, Inc. 69.8.128.0/17 AS7260 NORLIGHT Norlight Telecommunications 132.0.0.0/10 AS568 SUMNET-AS DISO-UNRRA 137.0.0.0/13 AS568 SUMNET-AS DISO-UNRRA 138.136.0.0/13 AS568 SUMNET-AS DISO-UNRRA 158.0.0.0/13 AS568 SUMNET-AS DISO-UNRRA 192.43.230.0/24 AS4738 SAARDNET-AS South Australian Academic Research and Development Network 192.44.0.0/19 AS702 AS702 MCI EMEA 192.64.84.0/24 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.83.16.0/20 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.83.32.0/19 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.83.64.0/19 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.83.96.0/22 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.83.100.0/24 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.119.135.0/24 AS270 PSCNI-AS National Aeronautics and Space Administration 192.124.252.0/22 AS680 AS680 DFN-IP service G-WiN 192.135.50.0/24 AS7018 ATT-INTERNET4 AT&T WorldNet Services 192.136.71.0/24 AS719 AS719 LANLINK autonomous system 192.136.79.0/24 AS719 AS719 LANLINK autonomous system 192.153.144.0/21 AS568 SUMNET-AS DISO-UNRRA 192.172.0.0/19 AS568 SUMNET-AS DISO-UNRRA 192.188.208.0/20 AS568 SUMNET-AS DISO-UNRRA 192.243.32.0/23 AS2044 PALIN-AS Palin Aquisitions Inc. 198.23.26.0/24 AS4390 BELLATLANTIC-COM Bell Atlantic, Inc. 198.41.194.0/24 AS1982 ASN-NWNEXUS Northwest Nexus Inc. 198.97.72.0/21 AS568 SUMNET-AS DISO-UNRRA 198.97.80.0/20 AS568 SUMNET-AS DISO-UNRRA 198.97.88.0/24 AS89 NUSC-CSTLNET-AS Naval Underwater Systems Center 198.97.192.0/20 AS568 SUMNET-AS DISO-UNRRA 198.97.240.0/20 AS568 SUMNET-AS DISO-UNRRA 198.101.4.0/22 AS568 SUMNET-AS DISO-UNRRA 198.136.32.0/20 AS19329 MCNET Martin County Board of County Commissioners 198.144.32.0/19 AS3998 CITY-NET CityNet, Inc. 198.161.87.0/24 AS6539 GROUPTLCOM GT Group Telecom Services Corp. 198.161.165.0/24 AS852 ASN852 Telus Advanced Communications 198.163.155.0/24 AS684 MBNET-AS Manitoba Regional Network 198.167.0.0/16 AS7456 INTERHOP Interhop Network SERVICES Inc. 198.167.163.0/24 AS15290 ALLST-15290 Allstream Corp. Corporation Allstream 198.168.0.0/16 AS701 ALTERNET-AS UUNET Technologies, Inc. 198.169.0.0/16 AS803 SASKTEL SaskTel 198.232.133.0/24 AS23075 SKOTOS-AS Skotos Tech, Inc 199.10.0.0/16 AS568 SUMNET-AS DISO-UNRRA 199.60.0.0/20 AS271 BCNET-AS University of British Columbia 199.84.0.0/16 AS701 ALTERNET-AS UUNET Technologies, Inc. 199.114.0.0/18 AS568 SUMNET-AS DISO-UNRRA 199.114.0.0/21 AS568 SUMNET-AS DISO-UNRRA 199.114.128.0/18 AS568 SUMNET-AS DISO-UNRRA 199.114.130.0/24 AS721 DLA-ASNBLOCK-AS DoD Network Information Center 199.114.132.0/24 AS721 DLA-ASNBLOCK-AS DoD Network Information Center 199.114.136.0/24 AS1913 DLA4 Defense Logistics Agency 199.114.138.0/24 AS721 DLA-ASNBLOCK-AS DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 DISA/UNRRA 199.114.142.0/24 AS721 DLA-ASNBLOCK-AS DoD Network Information Center 199.114.144.0/24 AS721 DLA-ASNBLOCK-AS DoD Network Information Center 199.114.148.0/24 AS721 DLA-ASNBLOCK-AS DoD Network Information Center 199.114.150.0/24 AS721 DLA-ASNBLOCK-AS DoD Network Information Center 199.114.152.0/24 AS1913 DLA4 Defense Logistics Agency 199.114.154.0/24 AS1733 CENTAF-SWA AF DDN PMO 199.114.156.0/24 AS1913 DLA4 Defense Logistics Agency 199.114.160.0/24 AS1733 CENTAF-SWA AF DDN PMO 199.120.32.0/19 AS16582 NEXTLEVELINTERNET NEXTLEVEL INTERNET, INC. 199.121.0.0/16 AS568 SUMNET-AS DISO-UNRRA 199.123.0.0/18 AS568 SUMNET-AS DISO-UNRRA 199.123.16.0/20 AS568 SUMNET-AS DISO-UNRRA 199.123.80.0/21 AS568 SUMNET-AS DISO-UNRRA 199.189.32.0/19 AS7332 IQUEST-AS IQuest Internet 199.202.0.0/16 AS701 ALTERNET-AS UUNET Technologies, Inc. 200.120.0.0/16 AS22047 CL-VPNS-LACNIC VTR BANDA ANCHA S.A. 202.47.1.0/24 AS7491 PI-PH-AS-AP PI-PHILIPINES 202.70.0.0/20 AS4658 NETFRONT-AS NETFRONT I.T. LIMITED (HONG KONG) 202.70.16.0/22 AS17888 SINGTEL-HK SingTel Hong Kong Limited 202.70.240.0/20 AS4058 LINKAGENET-AP CPCNet Hong Kong Ltd. 202.72.112.0/22 AS22351 INTELSAT-1 INTELSAT 202.73.128.0/22 AS4058 LINKAGENET-AP CPCNet Hong Kong Ltd. 202.86.128.0/24 AS4755 VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 202.86.142.0/24 AS30362 HPT-ASN Hawaii-Pacific Teleport 202.86.171.0/24 AS4755 VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 202.86.172.0/23 AS4755 VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 202.86.190.0/24 AS4750 loxley-th Loxley Information Co., Ltd. 202.122.76.0/24 AS17553 TIMELESS-AP System Integration provider 202.133.3.0/24 AS9335 CIP-JAPAN-AS-AP ATT IPlus 203.32.4.0/23 AS7617 APNIC-AS-2-BLOCK Asia Pacific Network Information Centre 203.62.0.0/17 AS7572 AARNET-ACT-RNO Australian Academic and Reasearch Network (AARNet) 203.76.224.0/24 AS9549 COMDEK-ISP-AS-AP Comdek ISP 203.86.2.0/23 AS4058 LINKAGENET-AP CPCNet Hong Kong Ltd. 203.132.95.0/24 AS9787 CONCEPT-AU-AP Concept Networks 203.132.97.0/24 AS7652 VIANET-AS-AP Vianet Communications Pty Ltd 203.132.107.0/24 AS10236 FOXGOLD-NET-AU-AP FOXGOLD COMMUNICATIONS 203.132.108.0/24 AS10236 FOXGOLD-NET-AU-AP FOXGOLD COMMUNICATIONS 203.132.111.0/24 AS10236 FOXGOLD-NET-AU-AP FOXGOLD COMMUNICATIONS 203.132.118.0/24 AS18065 CENTRALDATA-WA Central Data Pty Ltd. 203.132.122.0/24 AS4802 WANTREE-AS-AP Wantree Development 203.132.123.0/24 AS18065 CENTRALDATA-WA Central Data Pty Ltd. 203.132.124.0/24 AS18065 CENTRALDATA-WA Central Data Pty Ltd. 203.132.125.0/24 AS4817 TECHEX1-AS-AP Techex Primary Netblock 203.135.99.0/24 AS2687 IBM-MMD-AS IBM 204.19.224.0/19 AS816 UUNET-AS4 UUNET Technologies, Inc. 204.69.144.0/22 AS5668 AS-5668 CenturyTel Internet Holdings, Inc. 204.154.125.0/24 AS3952 TELLABS-ASN TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN TELLABS Operations, Inc. 204.194.110.0/23 AS30653 EXOBIT Exobit Networks Inc. 205.150.0.0/15 AS701 ALTERNET-AS UUNET Technologies, Inc. 206.41.32.0/19 AS14824 NEWSOUTH NewSouth Communications Corp. 206.81.187.0/24 AS19194 JOVITA Sentris Network LLC 206.108.34.0/24 AS852 ASN852 Telus Advanced Communications 206.108.35.0/24 AS852 ASN852 Telus Advanced Communications 206.167.57.0/24 AS376 RISQ-AS Reseau Interordinateurs Scientique Quebecois (RISQ) 206.191.64.0/18 AS15290 ALLST-15290 Allstream Corp. Corporation Allstream 206.251.69.0/24 AS27429 TIL Telesat International Ltd. 207.162.192.0/19 AS4589 EASYNET Easynet Group Plc 207.231.96.0/19 AS11194 NUNETPA NuNet Inc 208.81.187.0/24 AS19194 JOVITA Sentris Network LLC 209.87.192.0/20 AS15290 ALLST-15290 Allstream Corp. Corporation Allstream 209.169.219.0/24 AS189 GENUITY-AS189 Genuity 209.169.223.0/24 AS189 GENUITY-AS189 Genuity 209.172.0.0/18 AS7770 TRITON Triton Technologies, Inc. 209.196.192.0/19 AS1784 GNAPS Global NAPs Networks 209.213.32.0/19 AS10629 INTERPAC Inter-Pacific Network Services 209.213.50.0/24 AS10629 INTERPAC Inter-Pacific Network Services 209.213.51.0/24 AS10629 INTERPAC Inter-Pacific Network Services 209.213.55.0/24 AS10629 INTERPAC Inter-Pacific Network Services 209.213.56.0/24 AS10629 INTERPAC Inter-Pacific Network Services 209.222.137.0/24 AS27429 TIL Telesat International Ltd. 209.240.96.0/19 AS10815 KCNET KCnet, Inc. 209.251.0.0/19 AS11036 SISCOM SISCOM, Inc 209.251.64.0/19 AS10266 NETWAY-AS MDC, Inc. 210.213.0.0/19 AS6453 GIEUROPE Teleglobe America Inc. 216.18.224.0/21 AS11458 IMBRIS IMBRIS, INC. 216.18.224.0/22 AS11458 IMBRIS IMBRIS, INC. 216.18.228.0/22 AS11458 IMBRIS IMBRIS, INC. 216.36.46.0/24 AS7176 GENUITY-AS7176 Genuity 216.36.47.0/24 AS7176 GENUITY-AS7176 Genuity 216.96.128.0/18 AS7018 ATT-INTERNET4 AT&T WorldNet Services Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)apops.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0