From owner-apops@lists.apnic.net Fri Dec 1 04:03:01 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id EAA125775; Fri, 1 Dec 2000 04:03:00 +1000 (EST) Received: from whois3.apnic.net (whois3.apnic.net [203.37.255.102]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id EAA125758 for ; Fri, 1 Dec 2000 04:02:58 +1000 (EST) Received: from dev.apnic.net (IDENT:root@dev.apnic.net [202.12.29.129]) by whois3.apnic.net (8.10.1/UW7.1.1-NSC) with ESMTP id eAUI2wH00271 for ; Fri, 1 Dec 2000 04:02:58 +1000 (EST) Received: (from cscora@localhost) by dev.apnic.net (8.9.3/8.9.3) id EAA01909 for apops@lists.apnic.net; Fri, 1 Dec 2000 04:02:57 +1000 From: Routing Analysis Message-Id: <200011301802.EAA01909@dev.apnic.net> Subject: [apops] Asia Pacific Weekly Routing Report Date: Fri, 1 Dec 2000 04:02:57 +1000 (EST) Reply-To: pfs@cisco.com To: apops@lists.apnic.net X-Mailer: fastmail [version 2.5 PL1] Sender: owner-apops@lists.apnic.net Precedence: bulk This is an automated weekly mailing sent to the APOPS list describing the state of the Internet Routing Table in the Asia Pacific Region. Daily listings are sent to bgp-stats@lists.apnic.net For a graphical representation, please see http://www.apnic.net/stats/bgp. If you have any comments please contact Philip Smith . Asia Pacific Report 01 Dec, 2000 Analysis Summary ---------------- BGP routing table entries examined: 94939 Origin ASes present in the Internet Routing Table: 9067 Origin ASes announcing only one prefix: 3182 Transit ASes present in the Internet Routing Table: 1227 Average AS path length visible in the Internet Routing Table: 5.2 Max AS path length visible: 18 Illegal AS announcements present in the Routing Table: 114 Non-routable prefixes present in the Routing Table: 0 Prefixes being announced from the IANA Reserved Address blocks: 2 Number of addresses announced to Internet: 1179642521 Equivalent to 70 /8s, 79 /16s and 234 /24s Percentage of available address space announced: 31.8 Percentage of allocated address space announced: 62.4 Percentage of available address space allocated: 51.0 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 13956 Prefixes being announced from the APNIC address blocks: 12743 APNIC Region origin ASes present in the Internet Routing Table: 1060 APNIC Region origin ASes announcing only one prefix: 368 APNIC Region transit ASes present in the Internet Routing Table: 177 Average APNIC Region AS path length visible: 5.2 Max APNIC Region AS path length visible: 13 Number of APNIC addresses announced to Internet: 59485073 Equivalent to 3 /8s, 139 /16s and 171 /24s Percentage of available APNIC address space announced: 70.0 APNIC AS Blocks 4608 - 4864, 7467 - 7722, 9216 - 10239, 17408 - 18431 APNIC Address Blocks 61/8, 202/7 and 210/7 APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /19 equiv Description 1221 934 985 Telstra 2563 527 70 Seoul National University 2764 449 128 connect.com.au pty ltd 2907 362 883 SINET Japan 4740 359 83 Ozemail 4755 324 112 VSNL India 9768 213 50 Korea Telecom 4618 211 56 Internet Thailand 9269 205 23 Hong Kong CTI 4763 193 43 Telstra New Zealand 703 188 97 UUNET Technologies, Inc. 7474 173 75 Optus Communications 7545 169 6 TPG Internet Pty Ltd 7657 152 6 The Internet Group Limited 4134 144 402 Data Communications Bureau 4766 144 493 KORnet Powered BY Korea Telec 4786 131 8 NetConnect Communications Pty 4433 128 114 Access One Pty Ltd 9797 127 10 Asia Online Australia Global Per AS prefix count summary ---------------------------------- ASN No of nets /19 equiv Description 701 2413 3453 UUNET Technologies, Inc. 12050 1931 1775 MachOne Communications, Inc. 705 1008 50 UUNET Technologies, Inc. 1 999 4553 BBN Planet 1221 934 985 Telstra 7018 898 3031 AT&T 1239 713 1637 Sprint ICM-Inria 7046 684 526 UUNET Technologies, Inc. 2914 665 1275 Verio, Inc. 174 578 2729 PSINet Inc. 209 559 565 Qwest 3561 558 1360 Cable & Wireless USA 6082 530 65 Management Analysis, Incorpor 2563 527 70 Seoul National University 3549 492 414 Frontier GlobalCenter 2764 449 128 connect.com.au pty ltd 2548 444 547 Digital Express Group, Inc. 3602 435 80 Sprint Canada 4293 432 55 Cable & Wireless USA List of Unregistered ASNs (Global) ---------------------------------- Bad AS Designation Network Transit AS Description 65530 PRIVATE 63.176.0.0/24 4999 Sprint 65530 PRIVATE 63.176.2.0/24 4999 Sprint 65530 PRIVATE 63.176.3.0/24 4999 Sprint 65530 PRIVATE 63.176.5.0/24 4999 Sprint 65530 PRIVATE 63.176.6.0/24 4999 Sprint 65530 PRIVATE 63.176.32.0/24 4999 Sprint 65530 PRIVATE 63.176.37.0/24 4999 Sprint 65530 PRIVATE 63.176.38.0/24 4999 Sprint 65530 PRIVATE 63.176.39.0/24 4999 Sprint 65530 PRIVATE 63.176.40.0/24 4999 Sprint 65530 PRIVATE 63.176.41.0/24 4999 Sprint 65530 PRIVATE 63.176.42.0/24 4999 Sprint 65530 PRIVATE 63.176.53.0/24 4999 Sprint 65530 PRIVATE 63.176.57.0/24 4999 Sprint 65530 PRIVATE 63.176.59.0/24 4999 Sprint 65530 PRIVATE 63.176.60.0/24 4999 Sprint 65530 PRIVATE 63.176.62.0/24 4999 Sprint 65530 PRIVATE 63.176.63.0/24 4999 Sprint 65530 PRIVATE 63.176.65.0/24 4999 Sprint 65530 PRIVATE 63.176.66.0/24 4999 Sprint 65530 PRIVATE 63.176.72.0/24 4999 Sprint 65530 PRIVATE 63.176.74.0/24 4999 Sprint 65530 PRIVATE 63.176.77.0/24 4999 Sprint 65530 PRIVATE 63.176.78.0/24 4999 Sprint 65530 PRIVATE 63.176.79.0/24 4999 Sprint 65530 PRIVATE 63.176.80.0/24 4999 Sprint 65530 PRIVATE 63.176.83.0/24 4999 Sprint 65530 PRIVATE 63.176.84.0/24 4999 Sprint 65530 PRIVATE 63.176.86.0/24 4999 Sprint 65530 PRIVATE 63.176.89.0/24 4999 Sprint 65530 PRIVATE 63.176.90.0/24 4999 Sprint 65530 PRIVATE 63.176.92.0/24 4999 Sprint 65530 PRIVATE 63.176.93.0/24 4999 Sprint 65530 PRIVATE 63.176.94.0/24 4999 Sprint 65530 PRIVATE 63.176.96.0/24 4999 Sprint 65530 PRIVATE 63.176.97.0/24 4999 Sprint 65530 PRIVATE 63.176.98.0/24 4999 Sprint 65530 PRIVATE 63.176.106.0/24 4999 Sprint 65530 PRIVATE 63.176.107.0/24 4999 Sprint 65530 PRIVATE 63.176.109.0/24 4999 Sprint 65530 PRIVATE 63.176.110.0/24 4999 Sprint 65530 PRIVATE 63.176.112.0/24 4999 Sprint 65530 PRIVATE 63.176.113.0/24 4999 Sprint 65530 PRIVATE 63.176.115.0/24 4999 Sprint 65530 PRIVATE 63.176.119.0/24 4999 Sprint 65530 PRIVATE 63.176.120.0/24 4999 Sprint 65530 PRIVATE 63.176.121.0/24 4999 Sprint 65530 PRIVATE 63.176.122.0/24 4999 Sprint 65530 PRIVATE 63.176.131.0/24 4999 Sprint 65530 PRIVATE 63.176.159.0/24 4999 Sprint 65530 PRIVATE 63.176.166.0/24 4999 Sprint 65530 PRIVATE 63.176.168.0/24 4999 Sprint 65530 PRIVATE 63.176.169.0/24 4999 Sprint 65530 PRIVATE 63.176.170.0/24 4999 Sprint 65530 PRIVATE 63.176.172.0/24 4999 Sprint 65530 PRIVATE 63.176.208.0/24 4999 Sprint 65530 PRIVATE 63.176.210.0/24 4999 Sprint 65530 PRIVATE 63.176.211.0/24 4999 Sprint 65530 PRIVATE 63.176.213.0/24 4999 Sprint 65530 PRIVATE 63.176.214.0/24 4999 Sprint 65530 PRIVATE 63.176.228.0/24 4999 Sprint 65530 PRIVATE 63.176.229.0/24 4999 Sprint 65530 PRIVATE 63.176.231.0/24 4999 Sprint 65530 PRIVATE 63.177.0.0/24 4999 Sprint 65530 PRIVATE 63.177.1.0/24 4999 Sprint 65530 PRIVATE 63.177.14.0/24 4999 Sprint 65530 PRIVATE 63.177.38.0/24 4999 Sprint 65530 PRIVATE 63.177.48.0/24 4999 Sprint 65530 PRIVATE 63.177.50.0/24 4999 Sprint 65530 PRIVATE 63.177.78.0/24 4999 Sprint 65530 PRIVATE 63.177.80.0/24 4999 Sprint 65530 PRIVATE 63.177.83.0/24 4999 Sprint 65530 PRIVATE 63.177.86.0/24 4999 Sprint 65530 PRIVATE 63.177.91.0/24 4999 Sprint 65530 PRIVATE 63.177.93.0/24 4999 Sprint 65530 PRIVATE 63.177.99.0/24 4999 Sprint 65530 PRIVATE 63.177.101.0/24 4999 Sprint 65530 PRIVATE 63.177.102.0/24 4999 Sprint 65530 PRIVATE 63.177.104.0/24 4999 Sprint 65530 PRIVATE 63.177.106.0/24 4999 Sprint 65530 PRIVATE 63.177.107.0/24 4999 Sprint 65530 PRIVATE 63.177.108.0/24 4999 Sprint 65530 PRIVATE 63.177.110.0/24 4999 Sprint 65530 PRIVATE 63.177.111.0/24 4999 Sprint 65530 PRIVATE 63.177.169.0/24 4999 Sprint 65530 PRIVATE 63.177.171.0/24 4999 Sprint 65530 PRIVATE 63.177.172.0/24 4999 Sprint 65530 PRIVATE 63.177.173.0/24 4999 Sprint 65530 PRIVATE 63.177.175.0/24 4999 Sprint 65530 PRIVATE 63.177.214.0/24 4999 Sprint 65530 PRIVATE 63.177.216.0/24 4999 Sprint 65530 PRIVATE 63.177.252.0/24 4999 Sprint 65530 PRIVATE 63.177.253.0/24 4999 Sprint 2027 UNALLOCATED 150.185.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.185.128.0/18 8143 Publicom Corp. 2027 UNALLOCATED 150.186.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.187.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.188.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.189.0.0/16 10530 Interpacket Group, I 64621 PRIVATE 152.121.2.0/24 701 UUNET Technologies, 64621 PRIVATE 152.121.3.0/24 701 UUNET Technologies, 64621 PRIVATE 152.121.4.0/24 701 UUNET Technologies, 64621 PRIVATE 152.121.33.0/24 701 UUNET Technologies, 64621 PRIVATE 152.121.36.0/24 701 UUNET Technologies, 64621 PRIVATE 152.121.49.0/24 701 UUNET Technologies, 64621 PRIVATE 152.121.100.0/24 701 UUNET Technologies, 64621 PRIVATE 152.121.200.0/24 701 UUNET Technologies, 64621 PRIVATE 152.121.255.0/24 701 UUNET Technologies, 1877 UNALLOCATED 192.108.196.0/24 1880 Stupi, house man's 1877 UNALLOCATED 192.108.209.0/24 1880 Stupi, house man's 1877 UNALLOCATED 192.108.210.0/24 1880 Stupi, house man's 1877 UNALLOCATED 192.108.214.0/24 1880 Stupi, house man's 5757 UNALLOCATED 192.239.13.0/24 701 UUNET Technologies, 5757 UNALLOCATED 207.19.224.0/24 701 UUNET Technologies, Advertised IANA Reserved Addresses ---------------------------------- Network Origin AS Description 91.16.23.0/24 11770 Net56 219.219.219.0/24 2563 Seoul National University Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:21 /9:4 /10:5 /11:9 /12:32 /13:56 /14:183 /15:290 /16:6724 /17:979 /18:1956 /19:6143 /20:4147 /21:4059 /22:6170 /23:8130 /24:54946 /25:234 /26:429 /27:90 /28:77 /29:80 /30:94 /31:0 /32:81 End of report * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Sat Dec 2 06:04:01 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id GAA115566; Sat, 2 Dec 2000 06:04:01 +1000 (EST) Received: from lovefm.cisco.com (lovefm.cisco.com [171.71.12.63]) by ns.apnic.net (8.9.3/8.9.3) with SMTP id GAA115547 for ; Sat, 2 Dec 2000 06:03:58 +1000 (EST) Received: from cisco.com (localhost.cisco.com [127.0.0.1]) by lovefm.cisco.com (8.6.12/8.6.5) with ESMTP id MAA25454; Fri, 1 Dec 2000 12:00:04 -0800 Message-Id: <200012012000.MAA25454@lovefm.cisco.com> To: nanog@merit.edu cc: tbates@cisco.com, eof-list@ripe.net, apops@apnic.net, routing-wg@ripe.net Subject: [apops] The Cidr Report Date: Fri, 01 Dec 2000 12:00:03 -0800 From: Tony Bates Sender: owner-apops@lists.apnic.net Precedence: bulk This is an auto-generated mail on Fri Dec 1 12:00:00 PST 2000 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. 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 xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 01Dec00 0) General Status Table History ------------- Date Prefixes 241100 92527 251100 92668 261100 92623 271100 92643 281100 92681 291100 92893 301100 93098 011200 93154 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 91.16.23.0/24 from AS11770 *** Bogus 219.219.219.0 from AS2563 AS Summary ---------- 1) Gains by aggregating at the origin AS level --- 01Dec00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description 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 * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Sat Dec 2 17:31:40 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id RAA123121; Sat, 2 Dec 2000 17:31:39 +1000 (EST) Received: from mail.q-linux.com (ip110.herrera.iphil.net [203.176.28.110]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id RAA123102 for ; Sat, 2 Dec 2000 17:31:34 +1000 (EST) Received: by mail.q-linux.com (Postfix, from userid 501) id D13AA3A7D9; Sat, 2 Dec 2000 15:31:01 +0800 (PHT) Date: Sat, 2 Dec 2000 15:31:01 +0800 From: "Miguel A.L. Paraz" To: apops@apnic.net Subject: [apops] AP Routing Message-ID: <20001202153101.B8003@mail.q-linux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-apops@lists.apnic.net Precedence: bulk This is in response to Philip's mail on the routing SIG. I find that the ISP's with the best routing within AP are Telcos - economics I perhaps. I buy transit from PH telcos and from US ISP's, from poking around the routing tables adjust the preference to use the telcos for the AP networks they can reach directly without passing through the US. I was wondering if it were feasible for others to do the same as a best practice, if their AP link is not too congested. I find some ISP's have transit from a US ISP/telco and an AP telco, but do AS-path prepends on the peering with the telco such that it is used as a backup route. Could they make an exception (local preference) and use the AP telco for connecting to other AP AS's/networks that are directly reachable? -- http://www.internet.org.ph - all about Internet and ISP's in the Philippines * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Sun Dec 3 04:02:17 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id EAA124054; Sun, 3 Dec 2000 04:02:16 +1000 (EST) Received: from mail1.cisco.com (mail1.cisco.com [171.68.225.60]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id EAA124050 for ; Sun, 3 Dec 2000 04:02:14 +1000 (EST) Received: from bgreenent2 (bgreene-dsl3.cisco.com [144.254.193.60]) by mail1.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id KAA10287; Sat, 2 Dec 2000 10:02:06 -0800 (PST) From: "Barry Raveendran Greene" To: "Miguel A.L. Paraz" , Subject: RE: [apops] AP Routing Date: Sat, 2 Dec 2000 09:58:47 -0800 Message-ID: <000901c05c89$8505d200$4f01a8c0@bgreenent2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: <20001202153101.B8003@mail.q-linux.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Importance: Normal Sender: owner-apops@lists.apnic.net Precedence: bulk Hello Miguel, The Telcos are using a bilateral peering technique that I called "AP Mesh." The peering agreement is derived from the way Telcos peer for international voice traffic. Each side pays for 1/2 the circuit with an QOS level set that triggers an automatic upgrade. So if the QOS level is set to be 70% average utilization during the top 4 peek hours of the day, then the circuit would be upgraded on both sides as soon as this level is reached. This allowed the two parties to start with 128Kbps between each other and then work up to the real speed needed to support peering traffic between them. There are some slides in this in an old trans-oceanic backbone presentation at: http://www.cisco.com/public/cons/isp/documents/Trans-OceanicInternetBackbone sv1.zip As you mentioned, it is a peering technique that has worked in Asia. It is not restricted to Telcos, ISP can do it. It is just that the techniques spread like wild fire in '96-'97 - mainly because the peering technique was familiar (being similar to what is done on voice with out the settlement). Barry > -----Original Message----- > From: owner-apops@lists.apnic.net [mailto:owner-apops@lists.apnic.net]On > Behalf Of Miguel A.L. Paraz > Sent: Friday, December 01, 2000 11:31 PM > To: apops@apnic.net > Subject: [apops] AP Routing > > > This is in response to Philip's mail on the routing SIG. > > I find that the ISP's with the best routing within AP are Telcos > - economics > I perhaps. I buy transit from PH telcos and from US ISP's, from > poking around > the routing tables adjust the preference to use the telcos for > the AP networks > they can reach directly without passing through the US. > > I was wondering if it were feasible for others to do the same as a best > practice, if their AP link is not too congested. I find some ISP's have > transit from a US ISP/telco and an AP telco, but do AS-path > prepends on the > peering with the telco such that it is used as a backup route. > > Could they make an exception (local preference) and use the AP telco for > connecting to other AP AS's/networks that are directly reachable? > > > -- > > http://www.internet.org.ph - all about Internet and ISP's in the > Philippines > > > > * APOPS: Asia Pacific Operations Forum * > * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * > * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Sun Dec 3 10:25:21 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id KAA98155; Sun, 3 Dec 2000 10:25:20 +1000 (EST) Received: from mail.q-linux.com (ip110.herrera.iphil.net [203.176.28.110]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id KAA98151 for ; Sun, 3 Dec 2000 10:25:18 +1000 (EST) Received: by mail.q-linux.com (Postfix, from userid 501) id AD21E3A7DC; Sun, 3 Dec 2000 08:25:43 +0800 (PHT) Date: Sun, 3 Dec 2000 08:25:43 +0800 From: "Miguel A.L. Paraz" To: Barry Raveendran Greene Cc: apops@apnic.net Subject: Re: [apops] AP Routing Message-ID: <20001203082543.A18740@mail.q-linux.com> References: <20001202153101.B8003@mail.q-linux.com> <000901c05c89$8505d200$4f01a8c0@bgreenent2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000901c05c89$8505d200$4f01a8c0@bgreenent2.cisco.com>; from bgreene@cisco.com on Sat, Dec 02, 2000 at 09:58:47AM -0800 Sender: owner-apops@lists.apnic.net Precedence: bulk On Sat, Dec 02, 2000 at 09:58:47AM -0800, Barry Raveendran Greene wrote: > As you mentioned, it is a peering technique that has worked in Asia. It is > not restricted to Telcos, ISP can do it. It is just that the techniques > spread like wild fire in '96-'97 - mainly because the peering technique was > familiar (being similar to what is done on voice with out the settlement). I think there is no recurring cost to the Telcos for the line, though =) Just capacity on existing cable. What I was pointing out is, wouldn't it be better if ISP's who buy backup transit from one of the meshed telcos adjust their local preferences to use the telco to reach other meshed telcos and their customers? -- http://www.internet.org.ph GSM Mobile: +63-917-8109728 Internet and ISP's in the Philippines * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Fri Dec 8 04:03:25 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id EAA96252; Fri, 8 Dec 2000 04:03:23 +1000 (EST) Received: from whois3.apnic.net (whois3.apnic.net [203.37.255.102]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id EAA96228 for ; Fri, 8 Dec 2000 04:03:17 +1000 (EST) Received: from dev.apnic.net (IDENT:root@dev.apnic.net [202.12.29.129]) by whois3.apnic.net (8.10.1/UW7.1.1-NSC) with ESMTP id eB7I3HH02999 for ; Fri, 8 Dec 2000 04:03:17 +1000 (EST) Received: (from cscora@localhost) by dev.apnic.net (8.9.3/8.9.3) id EAA07062 for apops@lists.apnic.net; Fri, 8 Dec 2000 04:03:17 +1000 From: Routing Analysis Message-Id: <200012071803.EAA07062@dev.apnic.net> Subject: [apops] Asia Pacific Weekly Routing Report Date: Fri, 8 Dec 2000 04:03:17 +1000 (EST) Reply-To: pfs@cisco.com To: apops@lists.apnic.net X-Mailer: fastmail [version 2.5 PL1] Sender: owner-apops@lists.apnic.net Precedence: bulk This is an automated weekly mailing sent to the APOPS list describing the state of the Internet Routing Table in the Asia Pacific Region. Daily listings are sent to bgp-stats@lists.apnic.net For a graphical representation, please see http://www.apnic.net/stats/bgp. If you have any comments please contact Philip Smith . Asia Pacific Report 08 Dec, 2000 Analysis Summary ---------------- BGP routing table entries examined: 98964 Origin ASes present in the Internet Routing Table: 9338 Origin ASes announcing only one prefix: 3296 Transit ASes present in the Internet Routing Table: 1253 Average AS path length visible in the Internet Routing Table: 5.3 Max AS path length visible: 18 Illegal AS announcements present in the Routing Table: 15 Non-routable prefixes present in the Routing Table: 0 Prefixes being announced from the IANA Reserved Address blocks: 4 Number of addresses announced to Internet: 1219031583 Equivalent to 72 /8s, 168 /16s and 242 /24s Percentage of available address space announced: 32.9 Percentage of allocated address space announced: 64.5 Percentage of available address space allocated: 51.0 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 16868 Prefixes being announced from the APNIC address blocks: 15330 APNIC Region origin ASes present in the Internet Routing Table: 1088 APNIC Region origin ASes announcing only one prefix: 386 APNIC Region transit ASes present in the Internet Routing Table: 176 Average APNIC Region AS path length visible: 5.2 Max APNIC Region AS path length visible: 12 Number of APNIC addresses announced to Internet: 61961628 Equivalent to 3 /8s, 177 /16s and 117 /24s Percentage of available APNIC address space announced: 73.0 APNIC AS Blocks 4608 - 4864, 7467 - 7722, 9216 - 10239, 17408 - 18431 APNIC Address Blocks 61/8, 202/7 and 210/7 APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /19 equiv Description 1221 2162 1191 Telstra 9768 1433 75 Korea Telecom 2563 477 64 Seoul National University 2764 429 127 connect.com.au pty ltd 2907 366 892 SINET Japan 4740 350 73 Ozemail 4755 327 110 VSNL India 7657 320 16 The Internet Group Limited 4618 211 56 Internet Thailand 9269 206 23 Hong Kong CTI 703 193 154 UUNET Technologies, Inc. 4763 192 43 Telstra New Zealand 7545 178 6 TPG Internet Pty Ltd 7474 172 75 Optus Communications 4433 157 59 Access One Pty Ltd 4766 151 496 KORnet Powered BY Korea Telec 4134 147 426 Data Communications Bureau 4786 138 8 NetConnect Communications Pty 9797 129 10 Asia Online Australia 7496 128 10 Power Up Global Per AS prefix count summary ---------------------------------- ASN No of nets /19 equiv Description 701 2525 3469 UUNET Technologies, Inc. 1221 2162 1191 Telstra 9768 1433 75 Korea Telecom 705 1199 55 UUNET Technologies, Inc. 1 1009 4555 BBN Planet 7018 896 3025 AT&T 1239 728 1629 Sprint ICM-Inria 7046 681 514 UUNET Technologies, Inc. 2914 662 1275 Verio, Inc. 2548 636 564 Digital Express Group, Inc. 174 603 2773 PSINet Inc. 209 564 566 Qwest 3561 561 1368 Cable & Wireless USA 6082 538 66 Management Analysis, Incorpor 3549 503 418 Frontier GlobalCenter 2563 477 64 Seoul National University 3908 457 289 Supernet, Inc. 271 442 312 BCnet Backbone 3602 437 80 Sprint Canada 4293 430 54 Cable & Wireless USA List of Unregistered ASNs (Global) ---------------------------------- Bad AS Designation Network Transit AS Description 65501 PRIVATE 64.21.103.0/24 16890 Network Services, In 64800 PRIVATE 64.78.130.128/25 5705 Sirius Solutions, In 2027 UNALLOCATED 150.185.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.185.128.0/18 8143 Publicom Corp. 2027 UNALLOCATED 150.186.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.187.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.188.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.189.0.0/16 10530 Interpacket Group, I 1877 UNALLOCATED 192.108.196.0/24 1880 Stupi, house man's 1877 UNALLOCATED 192.108.209.0/24 1880 Stupi, house man's 1877 UNALLOCATED 192.108.210.0/24 1880 Stupi, house man's 1877 UNALLOCATED 192.108.214.0/24 1880 Stupi, house man's 5757 UNALLOCATED 192.239.13.0/24 701 UUNET Technologies, 64512 PRIVATE 202.61.84.0/24 4743 IPhil Communications 5757 UNALLOCATED 207.19.224.0/24 701 UUNET Technologies, Advertised IANA Reserved Addresses ---------------------------------- Network Origin AS Description 50.0.0.0/8 9487 Handong University 91.16.23.0/24 11770 Net56 105.200.136.0/30 9768 Korea Telecom 219.219.219.0/24 2563 Seoul National University Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:23 /9:4 /10:5 /11:9 /12:32 /13:57 /14:188 /15:293 /16:6749 /17:991 /18:1965 /19:6157 /20:4221 /21:4153 /22:6266 /23:8278 /24:57118 /25:563 /26:953 /27:379 /28:152 /29:149 /30:156 /31:0 /32:103 Number of /24s announced per /8 block (Global) ---------------------------------------------- 9:2 12:301 15:1 24:607 26:1 32:7 38:7 44:2 53:2 55:1 57:9 61:59 62:97 63:2158 64:999 65:7 66:44 91:1 128:19 129:163 130:16 131:30 132:9 133:3 134:76 135:1 136:51 137:78 138:174 139:45 140:107 141:17 142:46 143:36 144:89 145:12 146:126 147:58 148:110 149:109 150:23 151:250 152:989 153:32 154:47 155:60 156:13 157:94 158:49 159:46 160:18 161:53 162:63 163:123 164:94 165:94 166:166 167:74 168:56 169:29 170:178 171:2 192:5326 193:1897 194:2008 195:856 196:361 198:3664 199:3413 200:1705 202:2516 203:5312 204:3507 205:2392 206:2730 207:2684 208:2759 209:3269 210:677 211:188 212:704 213:256 214:6 215:11 216:2582 217:61 219:1 End of report * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Sat Dec 9 06:04:05 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id GAA83856; Sat, 9 Dec 2000 06:04:04 +1000 (EST) Received: from lovefm.cisco.com (lovefm.cisco.com [171.71.12.63]) by ns.apnic.net (8.9.3/8.9.3) with SMTP id GAA83852 for ; Sat, 9 Dec 2000 06:04:02 +1000 (EST) Received: from cisco.com (localhost.cisco.com [127.0.0.1]) by lovefm.cisco.com (8.6.12/8.6.5) with ESMTP id MAA29600; Fri, 8 Dec 2000 12:00:03 -0800 Message-Id: <200012082000.MAA29600@lovefm.cisco.com> To: nanog@merit.edu cc: tbates@cisco.com, eof-list@ripe.net, apops@apnic.net, routing-wg@ripe.net Subject: [apops] The Cidr Report Date: Fri, 08 Dec 2000 12:00:02 -0800 From: Tony Bates Sender: owner-apops@lists.apnic.net Precedence: bulk This is an auto-generated mail on Fri Dec 8 12:00:00 PST 2000 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. 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 xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 08Dec00 0) General Status Table History ------------- Date Prefixes 011200 93154 021200 93136 031200 93184 041200 95348 051200 95118 061200 95808 071200 95387 081200 95404 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 91.16.23.0/24 from AS11770 *** Bogus 219.219.219.0 from AS2563 AS Summary ---------- Number of ASes in routing system: 9339 Number of ASes announcing only one prefix: 5413 (3047 cidr, 2366 classful) Largest number of cidr routes: 1001 announced by AS701 Largest number of classful routes: 1708 announced by AS1221 1) Gains by aggregating at the origin AS level --- 08Dec00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1708 1240 468 27.4% TELSTRA-AS AS2563 348 114 234 67.2% KoRean Education Network AS271 289 133 156 54.0% BCnet Backbone AS701 1534 1390 144 9.4% Alternet AS9269 167 48 119 71.3% Hong Kong CTI AS7545 166 50 116 69.9% TPG Internet Pty Ltd AS2609 115 11 104 90.4% EUnet-TN AS6595 164 63 101 61.6% DODDSEUR AS8013 453 353 100 22.1% PSINET-CA AS7657 285 194 91 31.9% The Internet Group Limited AS13999 94 6 88 93.6% UNKNOWN AS705 331 247 84 25.4% ALTERNET-AS AS4293 344 262 82 23.8% Internal ASN for C&W AS174 526 445 81 15.4% Performance Systems International AS4755 194 114 80 41.2% Videsh Sanchar Nigam Ltd. India AS7496 102 25 77 75.5% Power Up AS7046 326 250 76 23.3% UUNET-CUSTOMER AS4151 285 209 76 26.7% USDA Internet Access Network AS3908 238 166 72 30.3% Supernet, Inc. AS1942 136 64 72 52.9% FR-CICG-GRENOBLE AS577 243 172 71 29.2% Bell Backbone AS724 224 158 66 29.5% DLA-ASNBLOCK-AS AS7018 594 528 66 11.1% AT&T WorldNet Service Backbone AS226 169 104 65 38.5% USC/Information Sciences Institut AS5106 101 37 64 63.4% AADS-COLUMBUS AS1727 153 91 62 40.5% MRMS-WEST AS3749 116 56 60 51.7% TECNET AS3602 306 248 58 19.0% Sprint Canada Inc. AS2548 369 311 58 15.7% DIGEX-AS AS16758 63 6 57 90.5% UNKNOWN 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 * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Tue Dec 12 04:26:25 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id EAA106798; Tue, 12 Dec 2000 04:26:25 +1000 (EST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id EAA106794 for ; Tue, 12 Dec 2000 04:26:22 +1000 (EST) Received: from pfs-laptop.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA11561; Mon, 11 Dec 2000 10:25:53 -0800 (PST) Message-Id: <5.0.2.1.2.20001212042122.00ab3a40@localhost> X-Sender: philsmit@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 12 Dec 2000 04:23:16 +1000 To: gijucho@kt.co.kr, hanjh@kt.co.kr From: Philip Smith Subject: [apops] Fwd: Korea Telecom leaking >1000 prefixes to Internet Cc: apops@lists.apnic.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-apops@lists.apnic.net Precedence: bulk Hi, I sent this three days ago, with no apparent resolution. Please can you, or your upstreams repair this leakage. kind regards, philip -- >Date: Sat, 09 Dec 2000 09:59:53 +1000 >To: gijucho@kt.co.kr, hanjh@kt.co.kr >From: Philip Smith >Subject: Korea Telecom leaking >1000 prefixes to Internet >Cc: hostmast@nic.or.kr > >Hi, > >Since the 2nd of December, Korea Telecom has been leaking over 1000 >prefixes from your aggregate blocks to the Internet routing table. I'm >seeing these prefixes originating from AS9768 - an excerpt is below: > >gw>sh ip bgp regexp _9768$ > > > 210.90.24.128/26 202.249.2.24 0 2516 4766 > 3608 9768 i >*> 210.90.32.128/25 202.249.2.24 0 2516 4766 >3608 9768 i >*> 210.90.37.0/25 202.249.2.24 0 2516 4766 >7563 9768 i >*> 210.90.48.128/25 202.249.2.24 0 2516 4766 >7563 9768 i >*> 210.90.54.0/25 202.249.2.24 0 2516 4766 >7563 9768 i >*> 210.90.61.0/25 202.249.2.24 0 2516 4766 >3608 9768 i >*> 210.90.84.0/25 202.249.2.24 0 2516 4766 >7563 9768 i >* 210.90.89.0 202.249.2.109 0 2497 1239 >3608 3608 9768 i >*> 202.249.2.24 0 2516 4766 >7563 9768 i >* 202.249.2.19 0 2497 1239 >3608 3608 9768 i >*> 210.90.90.0/25 202.249.2.24 0 2516 4766 >7563 9768 i >*> 210.90.112.0/25 202.249.2.24 0 2516 4766 >7563 9768 i >*> 210.90.117.128/25 202.249.2.24 0 2516 4766 >3608 9768 i >*> 210.90.123.240/28 202.249.2.24 0 2516 4766 >7563 9768 i > >Please will you fix your filters so that these prefixes are not announced >to the Internet. FYI, no prefixes > /24 should appear in the Internet >routing table. > >Korea Telecom is also announcing > >*> 105.200.136.0/30 202.249.2.24 0 2516 4766 >7563 9768 ? > >105.200.136.0/30 has not been assigned to any organisation in the public >Internet, so should not be announced. Please can you fix this also. > >Thanks for your kind attention. > >philip >-- * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Tue Dec 12 05:34:01 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id FAA115060; Tue, 12 Dec 2000 05:34:01 +1000 (EST) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id FAA115056 for ; Tue, 12 Dec 2000 05:33:59 +1000 (EST) Received: from tecra.telstra.net (ietf.207.137.72.48.tx.verio.net [207.137.72.48]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id GAA30121; Tue, 12 Dec 2000 06:30:49 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20001212062302.00b9ce90@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Dec 2000 06:30:52 +1100 To: Philip Smith From: Geoff Huston Subject: Re: [apops] Fwd: Korea Telecom leaking >1000 prefixes to Internet Cc: gijucho@kt.co.kr, hanjh@kt.co.kr, apops@lists.apnic.net In-Reply-To: <5.0.2.1.2.20001212042122.00ab3a40@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-apops@lists.apnic.net Precedence: bulk "FYI, no prefixes > /24 should appear in the Internet routing table." Let me offer a more accurate phrasing: FYI, if you choose to advertise prefixes which describe very small address blocks using prefix lengths between /25 to /32, you should be aware that a number of other Internet Service Providers use prefix length filtering and you may suffer impaired connectivity as a consequence of this action. Such ISPs will simply not hear your routing advertisement, and your customers may be unable to reach their customers via the Internet. The issue is that there is no routing police, and no forcing function. You _can_ announce small prefixes into the global routing table, but it is not considered an action that has either short or longer term positive benefit to either the advertiser, or anyone else. kind regards, Geoff (in nit-picking mode - sorry!) At 12/12/00 04:23 AM +1000, Philip Smith wrote: >Hi, > >I sent this three days ago, with no apparent resolution. Please can you, or your upstreams repair this leakage. > >kind regards, > >philip >-- > >>Date: Sat, 09 Dec 2000 09:59:53 +1000 >>To: gijucho@kt.co.kr, hanjh@kt.co.kr >>From: Philip Smith >>Subject: Korea Telecom leaking >1000 prefixes to Internet >>Cc: hostmast@nic.or.kr >> >>Hi, >> >>Since the 2nd of December, Korea Telecom has been leaking over 1000 prefixes from your aggregate blocks to the Internet routing table. I'm seeing these prefixes originating from AS9768 - an excerpt is below: >> >>gw>sh ip bgp regexp _9768$ >> >>> 210.90.24.128/26 202.249.2.24 0 2516 4766 3608 9768 i >>*> 210.90.32.128/25 202.249.2.24 0 2516 4766 3608 9768 i >>*> 210.90.37.0/25 202.249.2.24 0 2516 4766 7563 9768 i >>*> 210.90.48.128/25 202.249.2.24 0 2516 4766 7563 9768 i >>*> 210.90.54.0/25 202.249.2.24 0 2516 4766 7563 9768 i >>*> 210.90.61.0/25 202.249.2.24 0 2516 4766 3608 9768 i >>*> 210.90.84.0/25 202.249.2.24 0 2516 4766 7563 9768 i >>* 210.90.89.0 202.249.2.109 0 2497 1239 3608 3608 9768 i >>*> 202.249.2.24 0 2516 4766 7563 9768 i >>* 202.249.2.19 0 2497 1239 3608 3608 9768 i >>*> 210.90.90.0/25 202.249.2.24 0 2516 4766 7563 9768 i >>*> 210.90.112.0/25 202.249.2.24 0 2516 4766 7563 9768 i >>*> 210.90.117.128/25 202.249.2.24 0 2516 4766 3608 9768 i >>*> 210.90.123.240/28 202.249.2.24 0 2516 4766 7563 9768 i >> >>Please will you fix your filters so that these prefixes are not announced to the Internet. FYI, no prefixes > /24 should appear in the Internet routing table. >> >>Korea Telecom is also announcing >> >>*> 105.200.136.0/30 202.249.2.24 0 2516 4766 7563 9768 ? >> >>105.200.136.0/30 has not been assigned to any organisation in the public Internet, so should not be announced. Please can you fix this also. >> >>Thanks for your kind attention. >> >>philip >>-- > >* APOPS: Asia Pacific Operations Forum * >* To unsubscribe: send "unsubscribe" to apops-request@apnic.net * * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Tue Dec 12 14:38:41 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id OAA114949; Tue, 12 Dec 2000 14:38:41 +1000 (EST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id OAA114943 for ; Tue, 12 Dec 2000 14:38:38 +1000 (EST) Received: from pfs-laptop.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id UAA08806; Mon, 11 Dec 2000 20:37:57 -0800 (PST) Message-Id: <5.0.2.1.2.20001212141332.07842ec0@localhost> X-Sender: philsmit@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 12 Dec 2000 14:36:27 +1000 To: Joe Abley From: Philip Smith Subject: Re: [apops] Fwd: Korea Telecom leaking >1000 prefixes to Internet Cc: gijucho@kt.co.kr, hanjh@kt.co.kr, apops@lists.apnic.net In-Reply-To: <20001211135958.Q22842@goose.automagic.org> References: <5.0.2.1.2.20001212042122.00ab3a40@localhost> <5.0.2.1.2.20001212042122.00ab3a40@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-apops@lists.apnic.net Precedence: bulk At 14:00 11/12/00 -0500, Joe Abley wrote: >If we're pointing fingers, then 3608, 4766, 2516, 7563, 2497 and 1239 >also need to be singled out for failing to implement basic martian >filters. That's NBNIC-NCA, KIX, KDDI, KII, IIJ and Sprint. Oh, and >cisco, presumably :) Finger pointing? Anyone in the region who has been watching their border routers over the last year will have noticed that, every few weeks, 1200 /26s and /30s appear in the BGP table for a few days. And then disappear again. All from the same source. This is both a serious operational matter for Korea Telecom, and for the rest of the Internet in the region (at least those who choose not to implement the >/24 prefix filter)... Isn't it? I'm sure vendors don't mind if Korea Telecom or anyone else on the Internet does this. Vendors are more than happy to sell more memory to everyone who carries or wants to carry the full routing table... I can provide a list of AsiaPac ISPs who fail to do basic aggregation, but Tony Bates does that in his weekly CIDR report... The above you listed are not the worst in the region. But, memory must be cheap, CPUs must be fast, etc. (Apparently enough so that not many people care...) BTW, to add on to Geoff's comment, it is interesting to note that my BGP table view from one v large "Tier-1" ISP in the US has around 5000 prefixes less than we see here in the Asia Pacific. The difference is big enough to be interesting now... :-) philip -- * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Wed Dec 13 04:20:53 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id EAA94308; Wed, 13 Dec 2000 04:20:53 +1000 (EST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id EAA94304 for ; Wed, 13 Dec 2000 04:20:50 +1000 (EST) Received: from pfs-laptop.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA24681; Tue, 12 Dec 2000 10:20:18 -0800 (PST) Message-Id: <5.0.2.1.2.20001213040422.07691610@localhost> X-Sender: philsmit@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 13 Dec 2000 04:12:54 +1000 To: Joe Abley From: Philip Smith Subject: Re: [apops] Fwd: Korea Telecom leaking >1000 prefixes to Internet Cc: apops@lists.apnic.net In-Reply-To: <20001212081205.B23618@goose.automagic.org> References: <5.0.2.1.2.20001212141332.07842ec0@localhost> <5.0.2.1.2.20001212042122.00ab3a40@localhost> <5.0.2.1.2.20001212042122.00ab3a40@localhost> <20001211135958.Q22842@goose.automagic.org> <5.0.2.1.2.20001212141332.07842ec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-apops@lists.apnic.net Precedence: bulk At 08:12 12/12/00 -0500, Joe Abley wrote: >And the only reason it's an operational matter for _anybody_ is that >those who peer and provide transit to Korea Telecom don't filter them >out. Sean Doran made an interesting suggestion at the IEPG on Sunday. Charge providers for the prefixes they announce. So if anyone thinks that 99500 is too much for their router to take, send a bill to the people who are announcing more than they ought to (i.e. subprefixes of their aggregates). They may ignore it, or they may send a cheque... Who knows... Anyone want to test the theory? >It's a fact of life that people will leak crap into the network every >once and a while. Maybe Korea Telecom are leaking a lot of crap. >Responsible peers and providers won't see it though, because they'll >filter it as a matter of routine. Yup, and those who don't know to do this may find out about some of the options... Like filtering, or charging money, or.... ;-) >This sounds like an interesting supposition to test. It would be nice >if periodic measurements could be taken across the regions to give a >representative sample distribution: I presume you are comparing single >point measurements in the US and AP? I was going to compare this US view with the AP view - early in the New Year though. It's big enough to make me curious... philip -- * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Wed Dec 13 04:22:20 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id EAA94469; Wed, 13 Dec 2000 04:22:20 +1000 (EST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id EAA94464 for ; Wed, 13 Dec 2000 04:22:17 +1000 (EST) Received: from pfs-laptop.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA25826; Tue, 12 Dec 2000 10:21:45 -0800 (PST) Message-Id: <5.0.2.1.2.20001213040422.07691610@localhost> X-Sender: philsmit@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 13 Dec 2000 04:12:54 +1000 To: Joe Abley From: Philip Smith Subject: Re: [apops] Fwd: Korea Telecom leaking >1000 prefixes to Internet Cc: apops@lists.apnic.net In-Reply-To: <20001212081205.B23618@goose.automagic.org> References: <5.0.2.1.2.20001212141332.07842ec0@localhost> <5.0.2.1.2.20001212042122.00ab3a40@localhost> <5.0.2.1.2.20001212042122.00ab3a40@localhost> <20001211135958.Q22842@goose.automagic.org> <5.0.2.1.2.20001212141332.07842ec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-apops@lists.apnic.net Precedence: bulk At 08:12 12/12/00 -0500, Joe Abley wrote: >And the only reason it's an operational matter for _anybody_ is that >those who peer and provide transit to Korea Telecom don't filter them >out. Sean Doran made an interesting suggestion at the IEPG on Sunday. Charge providers for the prefixes they announce. So if anyone thinks that 99500 is too much for their router to take, send a bill to the people who are announcing more than they ought to (i.e. subprefixes of their aggregates). They may ignore it, or they may send a cheque... Who knows... Anyone want to test the theory? >It's a fact of life that people will leak crap into the network every >once and a while. Maybe Korea Telecom are leaking a lot of crap. >Responsible peers and providers won't see it though, because they'll >filter it as a matter of routine. Yup, and those who don't know to do this may find out about some of the options... Like filtering, or charging money, or.... ;-) >This sounds like an interesting supposition to test. It would be nice >if periodic measurements could be taken across the regions to give a >representative sample distribution: I presume you are comparing single >point measurements in the US and AP? I was going to compare this US view with the AP view - early in the New Year though. It's big enough to make me curious... philip -- * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Wed Dec 13 04:40:04 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id EAA96444; Wed, 13 Dec 2000 04:40:04 +1000 (EST) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id EAA96439 for ; Wed, 13 Dec 2000 04:40:03 +1000 (EST) Received: from tecra.telstra.net (ietf.207.137.73.119.tx.verio.net [207.137.73.119]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id FAA62679; Wed, 13 Dec 2000 05:39:11 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20001213052553.00c24100@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 13 Dec 2000 05:39:12 +1100 To: Philip Smith From: Geoff Huston Subject: Re: [apops] Fwd: Korea Telecom leaking >1000 prefixes to Internet Cc: Joe Abley , apops@lists.apnic.net In-Reply-To: <5.0.2.1.2.20001213040422.07691610@localhost> References: <20001212081205.B23618@goose.automagic.org> <5.0.2.1.2.20001212141332.07842ec0@localhost> <5.0.2.1.2.20001212042122.00ab3a40@localhost> <5.0.2.1.2.20001212042122.00ab3a40@localhost> <20001211135958.Q22842@goose.automagic.org> <5.0.2.1.2.20001212141332.07842ec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-apops@lists.apnic.net Precedence: bulk At 12/13/00 04:12 AM +1000, Philip Smith wrote: >At 08:12 12/12/00 -0500, Joe Abley wrote: >>And the only reason it's an operational matter for _anybody_ is that >>those who peer and provide transit to Korea Telecom don't filter them >>out. > >Sean Doran made an interesting suggestion at the IEPG on Sunday. Charge providers for the prefixes they announce. So if anyone thinks that 99500 is too much for their router to take, send a bill to the people who are announcing more than they ought to (i.e. subprefixes of their aggregates). They may ignore it, or they may send a cheque... Who knows... Anyone want to test the theory? The problem is identifying the difference between route push and route pull. You are implicitly assuming this unidirectional route advertisement heads 'upstream' in making this statement. As a cursory examination of AS relations in AS paths reveals, what is upstream and what is downstream is largely a matter of opinion. It is on this particular rock that 'charging for advertisement of route prefixes' has foundered as a concept for the past 5 years. >>It's a fact of life that people will leak crap into the network every >>once and a while. Maybe Korea Telecom are leaking a lot of crap. >>Responsible peers and providers won't see it though, because they'll >>filter it as a matter of routine. > >Yup, and those who don't know to do this may find out about some of the options... Like filtering, or charging money, or.... ;-) > >>This sounds like an interesting supposition to test. It would be nice >>if periodic measurements could be taken across the regions to give a >>representative sample distribution: I presume you are comparing single >>point measurements in the US and AP? And who are the Routing Police and who gave them a charter and who gave them the authority to start intruding in the normally commercial in confidence relationships between a provider and a customer? The conversation strikes me as having identified a reasonable issue, but them wandered off into a vary unrealistic set of potential solutions. I _know_ that apnic would be __HORRIFIED__ to be portrayed as the Routing Police. I also know that the difference between collective action by a number of commercial entities and cartel-like behavior is often difficult to distinguish, and many providers would abhor the concept of behaving in a collusive way that discriminates or disadvantages a competitor or customer. So with all that in mind the solutions to issues such as these are not always easy to identify. The real issue here is far more complex and multi-dimensioned than is characterized in the messages I've seen to date, and before the routing jihad moves into the mode of eliminating the infidel /30 route prefix advertiser, we should all understand the dimension of the environment we live in, and its more than purely technology I would humbly suggest. regards, Geoff Huston * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Wed Dec 13 05:37:59 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id FAA102842; Wed, 13 Dec 2000 05:37:59 +1000 (EST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id FAA102837 for ; Wed, 13 Dec 2000 05:37:56 +1000 (EST) Received: from pfs-laptop.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA29344; Tue, 12 Dec 2000 11:36:47 -0800 (PST) Message-Id: <5.0.2.1.2.20001213050250.071ecec0@localhost> X-Sender: philsmit@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 13 Dec 2000 05:36:34 +1000 To: Geoff Huston From: Philip Smith Subject: Re: [apops] Fwd: Korea Telecom leaking >1000 prefixes to Internet Cc: Joe Abley , apops@lists.apnic.net In-Reply-To: <4.3.2.7.2.20001213052553.00c24100@localhost> References: <5.0.2.1.2.20001213040422.07691610@localhost> <20001212081205.B23618@goose.automagic.org> <5.0.2.1.2.20001212141332.07842ec0@localhost> <5.0.2.1.2.20001212042122.00ab3a40@localhost> <5.0.2.1.2.20001212042122.00ab3a40@localhost> <20001211135958.Q22842@goose.automagic.org> <5.0.2.1.2.20001212141332.07842ec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-apops@lists.apnic.net Precedence: bulk At 05:39 13/12/00 +1100, Geoff Huston wrote: > >Sean Doran made an interesting suggestion at the IEPG on Sunday. Charge > providers for the prefixes they announce. So if anyone thinks that 99500 > is too much for their router to take, send a bill to the people who are > announcing more than they ought to (i.e. subprefixes of their > aggregates). They may ignore it, or they may send a cheque... Who > knows... Anyone want to test the theory? > > >The problem is identifying the difference between route push and route pull. > >You are implicitly assuming this unidirectional route advertisement heads >'upstream' in making this statement. Upstream? I'm assuming that if someone makes a route announcement, it goes pretty much everywhere in the Internet it is allowed to go in. So that is upstream, downstream, between peers,... And if I understand the charging point, you simply send a bill to the originator of the prefixes you'd rather not carry in your network...? Or? >And who are the Routing Police and who gave them a charter and who gave >them the authority to start intruding in the normally commercial in >confidence relationships between a provider and a customer? The >conversation strikes me as having identified a reasonable issue, but them >wandered off into a vary unrealistic set of potential solutions. I _know_ >that apnic would be __HORRIFIED__ to be portrayed as the Routing Police. I >also know that the difference between collective action by a number of >commercial entities and cartel-like behavior is often difficult to >distinguish, and many providers would abhor the concept of behaving in a >collusive way that discriminates or disadvantages a competitor or >customer. So with all that in mind the solutions to issues such as these >are not always easy to identify. Exactly, solutions are not easy to identify, and any kind of routing police is not the right way to go. For starters, who would be the police? >The real issue here is far more complex and multi-dimensioned than is >characterized in the messages I've seen to date, and before the routing >jihad moves into the mode of eliminating the infidel /30 route prefix >advertiser, we should all understand the dimension of the environment we >live in, and its more than purely technology I would humbly suggest. Well, the particular issue I'm trying to "help" with is alerting providers who are inadvertently announcing subprefixes of aggregates they are also announcing. If KT, for example, have a commercial in-confidence reason for announcing /30s etc to their peers, that is their private issue, but then they should take reasonable steps to ensure that the rest of the world is not drawn into their private affairs (the no-export community could help with this, for example). But any provider who has a need to announce a /nn to the Internet should be free to do so, as you say. And it should not matter what it is - that's the idea of CIDR... :-) Some of the many examples I see, and know of, are ISPs who announce the /19 they received from APNIC, and then also announce the 32 "Class Cs" because that they have been brought up on the historical class A/B/C system we used to have in the Internet many years ago. And these providers in question tend to have one or two links to other service providers. For one link, I query why this leakage is necessary (the KT example falls into this category, going by the AS PATHs). For two links, well, this is "multihoming by the scatter gun approach". Nothing wrong with it, but it could be done a little more optimally, and with a little more finesse? cheers, philip -- * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Wed Dec 13 07:57:00 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id HAA118141; Wed, 13 Dec 2000 07:56:59 +1000 (EST) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id HAA118137 for ; Wed, 13 Dec 2000 07:56:58 +1000 (EST) Received: from tecra.telstra.net (ietf.207.137.73.158.tx.verio.net [207.137.73.158]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id IAA65824; Wed, 13 Dec 2000 08:56:54 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20001213084926.00b27420@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 13 Dec 2000 08:56:58 +1100 To: Philip Smith From: Geoff Huston Subject: Re: [apops] Fwd: Korea Telecom leaking >1000 prefixes to Internet Cc: apops@lists.apnic.net In-Reply-To: <5.0.2.1.2.20001213050250.071ecec0@localhost> References: <4.3.2.7.2.20001213052553.00c24100@localhost> <5.0.2.1.2.20001213040422.07691610@localhost> <20001212081205.B23618@goose.automagic.org> <5.0.2.1.2.20001212141332.07842ec0@localhost> <5.0.2.1.2.20001212042122.00ab3a40@localhost> <5.0.2.1.2.20001212042122.00ab3a40@localhost> <20001211135958.Q22842@goose.automagic.org> <5.0.2.1.2.20001212141332.07842ec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-apops@lists.apnic.net Precedence: bulk >And if I understand the charging point, you simply send a bill to the originator of the prefixes you'd rather not carry in your network...? Or? So I send a bill to a Slovakian ISP who has entreis in my routing table? hmm - probability of payment: 0 SO I drop the routes: right? Net result (tick one) +--+ Balkanized network | | +--+ +--+ Rational Optimally routed network | | +--+ I'd like to know how you get to the latter outcome from this mode of behavior. >Well, the particular issue I'm trying to "help" with is alerting providers who are inadvertently announcing subprefixes of aggregates they are also announcing. If KT, for example, have a commercial in-confidence reason for announcing /30s etc to their peers, that is their private issue, but then they should take reasonable steps to ensure that the rest of the world is not drawn into their private affairs (the no-export community could help with this, for example). But any provider who has a need to announce a /nn to the Internet should be free to do so, as you say. And it should not matter what it is - that's the idea of CIDR... :-) But my point is that NO export is broken - what if I want to bias the route selection of the 2 AS away provider - no export is useless and the next step after no export is global. Now is it KT's fault that the routing technology tools are simply not good enough to accurately represent policy promulgation? I guess not. >Some of the many examples I see, and know of, are ISPs who announce the /19 they received from APNIC, and then also announce the 32 "Class Cs" because that they have been brought up on the historical class A/B/C system we used to have in the Internet many years ago. And these providers in question tend to have one or two links to other service providers. For one link, I query why this leakage is necessary (the KT example falls into this category, going by the AS PATHs). For two links, well, this is "multihoming by the scatter gun approach". Nothing wrong with it, but it could be done a little more optimally, and with a little more finesse? It could, but if you want fine grained control of multiple links then the BGP table IS the only traffic engineering vehicle we have, and adjusting and announcing arbitrary prefixes does not work on a day by day basis - the /24's allow fine grained rapid (minutes) response multi-provider traffic engineering. Lousy outcomes are often the outcome of not having the right tool. regards, Geoff * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Wed Dec 13 08:34:41 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id IAA122371; Wed, 13 Dec 2000 08:34:41 +1000 (EST) Received: from xenon.syd.dav.net.au (xenon.syd.dav.net.au [203.111.0.37]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id IAA122364 for ; Wed, 13 Dec 2000 08:34:39 +1000 (EST) Received: from kenny2 (kenny2.magna.com.au [203.111.99.37]) by xenon.syd.dav.net.au (8.10.2/8.10.2/xenon/3.0) with SMTP id eBCMYcE27628 for ; Wed, 13 Dec 2000 09:34:38 +1100 (EST) Message-ID: <00db01c0648b$b4c33e60$25636fcb@magna.com.au> From: "Phillip Grasso-Nguyen" To: Subject: Re: [apops] Fwd: Korea Telecom leaking >1000 prefixes to Internet Date: Wed, 13 Dec 2000 09:34:35 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-apops@lists.apnic.net Precedence: bulk > announcing. If KT, for example, have a commercial > in-confidence reason for > announcing /30s etc to their peers, that is their private > issue, but then > they should take reasonable steps to ensure that the rest of > the world is > not drawn into their private affairs (the no-export community > could help > with this, for example). But any provider who has a need to > announce a /nn > to the Internet should be free to do so, as you say. And it > should not > matter what it is - that's the idea of CIDR... :-) This is only a suggestion, but I *think* that the larger providers should enforce RFC2519 for no-export functionally (to the smaller ISP's), and possibility the RADB *Could* be used as an alerting tool. I found that many providers knowingly announcing smaller blocks for preferred traffic direction, e.g. Satellite backchannel providers, /19 to Telstra, and two /20's to IHUG/NetConnect. Some Go beyond that and announce 32x/24's. Not just that but other providers announce sub-CIDR for MED (effectively more control) however they should only be announcing with NO-EXPORT. (i'm guilty of doing this :-( ). If more people had RFC1998+ configured, these satellite ho's could control traffic direction without the need for announcing longer prefixes, however there are always some that DON'T want ANY traffic going via their cable paths. Obviously this lead's to it's own problems, but so is Global routing table. Regards Phillip. * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Wed Dec 13 08:36:07 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id IAA122550; Wed, 13 Dec 2000 08:36:07 +1000 (EST) Received: from xenon.syd.dav.net.au (xenon.syd.dav.net.au [203.111.0.37]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id IAA122530 for ; Wed, 13 Dec 2000 08:36:05 +1000 (EST) Received: from kenny2 (kenny2.magna.com.au [203.111.99.37]) by xenon.syd.dav.net.au (8.10.2/8.10.2/xenon/3.0) with SMTP id eBCMa5E28375 for ; Wed, 13 Dec 2000 09:36:05 +1100 (EST) Message-ID: <00e401c0648b$e85cc700$25636fcb@magna.com.au> From: "Phillip Grasso-Nguyen" To: Subject: Re: [apops] Fwd: Korea Telecom leaking >1000 prefixes to Internet Date: Wed, 13 Dec 2000 09:36:00 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-apops@lists.apnic.net Precedence: bulk What stops an large providers from providing a OPEN community that will allow routes to be set with NO-EXPORT, etc. For example Telstra 1221, go-between provider AS7474, and AS1234 1221:5000 set NO-EXPORT 1221:5001 do not announce to PEERS 1221:5002 Do no announce to US upstreams. If provider AS1234 announced their routes with 1221:5000 their routes will only goto the telstra neighbours and no further. With community 1221:5001 they would not announce to peers etc. Obviously some tight controls and bit of consideration must be made before doing this (as it let's others control traffic direction etc.), but this allows true traffic engineering with multi-provider model without announcing longer-prefixes. Regards Phill. > It could, but if you want fine grained control of multiple > links then the BGP table IS the only traffic engineering > vehicle we have, and adjusting and announcing arbitrary > prefixes does not work on a day by day basis - the /24's > allow fine grained rapid (minutes) response multi-provider > traffic engineering. > > Lousy outcomes are often the outcome of not having the right tool. > > regards, > > Geoff * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Wed Dec 13 08:36:18 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id IAA122582; Wed, 13 Dec 2000 08:36:18 +1000 (EST) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id IAA122578 for ; Wed, 13 Dec 2000 08:36:17 +1000 (EST) Received: from tecra.telstra.net (ietf.207.137.73.158.tx.verio.net [207.137.73.158]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id JAA66515; Wed, 13 Dec 2000 09:35:43 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20001213092531.00b34420@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 13 Dec 2000 09:27:13 +1100 To: Phillip Grasso-Nguyen From: Geoff Huston Subject: RE: [apops] Fwd: Korea Telecom leaking >1000 prefixes to Internet Cc: Philip Smith , apops@lists.apnic.net In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-apops@lists.apnic.net Precedence: bulk The problem here is that its a specific per-network response which is a large and complex policy environment is close to impossible to maintain rationally. Unfortunately there is no more generic capability of the tool between 'everywhere' and 'my neighbor' to control route propagation. Geoff At 12/13/00 09:25 AM +1100, Phillip Grasso-Nguyen wrote: >What stops an large providers from providing a OPEN community that will >allow routes to be set with NO-EXPORT, etc. > >For example Telstra 1221, go-between provider AS7474, and AS1234 > >1221:5000 set NO-EXPORT >1221:5001 do not announce to PEERS >1221:5002 Do no announce to US upstreams. > >If provider AS1234 announced their routes with 1221:5000 their routes will >only goto the telstra neighbours and no further. >With community 1221:5001 they would not announce to peers etc. > >Obviously some tight controls and bit of consideration must be made before >doing this (as it let's others control traffic direction etc.), but this >allows true traffic engineering with multi-provider model without announcing >longer-prefixes. > >Regards > Phill. > > > > > It could, but if you want fine grained control of multiple > > links then the BGP table IS the only traffic engineering > > vehicle we have, and adjusting and announcing arbitrary > > prefixes does not work on a day by day basis - the /24's > > allow fine grained rapid (minutes) response multi-provider > > traffic engineering. > > > > Lousy outcomes are often the outcome of not having the right tool. > > > > regards, > > > > Geoff > > > > * APOPS: Asia Pacific Operations Forum * > > * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * > > * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Wed Dec 13 10:36:50 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id KAA70660; Wed, 13 Dec 2000 10:36:49 +1000 (EST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id KAA70653 for ; Wed, 13 Dec 2000 10:36:46 +1000 (EST) Received: from pfs-laptop.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA21208; Tue, 12 Dec 2000 16:36:06 -0800 (PST) Message-Id: <5.0.2.1.2.20001213102125.079d0110@localhost> X-Sender: philsmit@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 13 Dec 2000 10:35:04 +1000 To: Geoff Huston From: Philip Smith Subject: Re: [apops] Fwd: Korea Telecom leaking >1000 prefixes to Internet Cc: apops@lists.apnic.net In-Reply-To: <4.3.2.7.2.20001213084926.00b27420@localhost> References: <5.0.2.1.2.20001213050250.071ecec0@localhost> <4.3.2.7.2.20001213052553.00c24100@localhost> <5.0.2.1.2.20001213040422.07691610@localhost> <20001212081205.B23618@goose.automagic.org> <5.0.2.1.2.20001212141332.07842ec0@localhost> <5.0.2.1.2.20001212042122.00ab3a40@localhost> <5.0.2.1.2.20001212042122.00ab3a40@localhost> <20001211135958.Q22842@goose.automagic.org> <5.0.2.1.2.20001212141332.07842ec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-apops@lists.apnic.net Precedence: bulk At 08:56 13/12/00 +1100, Geoff Huston wrote: >So I send a bill to a Slovakian ISP who has entreis in my routing table? > >hmm - probability of payment: 0 You never know...? ;-) > +--+ > Rational Optimally routed network | | > +--+ > >I'd like to know how you get to the latter outcome from this mode of behavior. Well, what other big sticks have been used at the time of CIDR deployment in 1994? I remember the "flag" day for us in the UK when UUNET converted frmo BGP3 to BGP4. We kinda had to support BGP4, or stick in a static default to see the bits of the Internet which disappeared. And after then, there seemed to be a lot of peer pressure to get most of the Internet over to BGP4. And in the subsequent years (the linear growth in the BGP table), I was certainly very conscious of the "do the right thing" attitude for prudent announcements to the Internet. In the last 3 or 4 years, this seems to have been diminishing... Following from that we had Tony's CIDR report attempting to use peer pressure on providers so that they aggregate prefixes, rather than announcing specifics (I accept this is a slightly different problem). Could peer pressure of sorts be made to work? Or do we even want it to work? It comes back to the question of does any of this really matter, or do we decide that some of it matters when we are 30seconds from the brink? >But my point is that NO export is broken - what if I want to bias the >route selection of the 2 AS away provider - no export is useless and the >next step after no export is global. Yup, for more than one AS hop, there are no tools apart from cooperation and e-mail. >Now is it KT's fault that the routing technology tools are simply not good >enough to accurately represent policy promulgation? It's not clear to me that a lack of tools caused this particular problem. I'm told it was a missing prefix filter on one of the border routers. But granted, in the big picture, there is no tool to aid more detailed multihoming or route preferences between the detailed community policy possible for you and your immediately neighbouring ASes, and dealing with detailed policy for you and the rest of the world. >It could, but if you want fine grained control of multiple links then the >BGP table IS the only traffic engineering vehicle we have, and adjusting >and announcing arbitrary prefixes does not work on a day by day basis - >the /24's allow fine grained rapid (minutes) response multi-provider >traffic engineering. > >Lousy outcomes are often the outcome of not having the right tool. What would be the best way forward? Some better defined communities, say in the vein of RFC1998, which can have meaning more AS hops away. I can't see this scaling too well though (I seem to remember this being talked about recently somewhere)... Or maybe we should say "BGP was nice, but we need a new routing protocol for the Internet today"? philip -- * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Wed Dec 13 13:06:32 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id NAA89984; Wed, 13 Dec 2000 13:06:31 +1000 (EST) Received: from guardian.apnic.net (guardian.apnic.net [203.37.255.100]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id NAA89980 for ; Wed, 13 Dec 2000 13:06:30 +1000 (EST) Received: (from mail@localhost) by guardian.apnic.net (8.9.3/8.9.3) id NAA16799 for ; Wed, 13 Dec 2000 13:06:28 +1000 (EST) Received: from julubu.staff.apnic.net(192.168.1.37) by int-gw.staff.apnic.net via smap (V2.1) id xma016795; Wed, 13 Dec 00 13:06:07 +1000 Date: Wed, 13 Dec 2000 13:06:20 +1000 (EST) From: Bruce Campbell X-Sender: bc@julubu.staff.apnic.net To: apops@lists.apnic.net Subject: [apops] List maintainance. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-apops@lists.apnic.net Precedence: bulk Please note, the apops list (like most other lists hosted by APNIC) only accepts posts from the addresses that are subscribed to the list. Posts from addresses which are *not* subscribed are bounced to the administrators of the list in question (in this case, APNIC staff). In most cases, these bounces are spams (toner cartridges, make money fast, work for cisco, etc etc) and are deleted. In some cases, they are relevant to the conversation and are resent to the list by APNIC staff, when APNIC staff check for such mail. To check your subscription(s), send an email to majordomo from the address that you use to post to the list: -- To: majordomo@lists.apnic.net Subject: Majordomo does not read this line which help end -- Regards, -- Bruce Campbell +61-7-3367-0490 Systems Administrator Regional Internet Registry Asia Pacific Network Information Centre For the Asia Pacific Region Unix means never having to live hand-to-mouse. * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Wed Dec 13 13:07:32 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id NAA90115; Wed, 13 Dec 2000 13:07:32 +1000 (EST) Received: from goose.automagic.org ([207.61.141.34]) by ns.apnic.net (8.9.3/8.9.3) with SMTP id FAA110918 for ; Tue, 12 Dec 2000 05:00:05 +1000 (EST) Received: (qmail 27212 invoked by uid 100); 11 Dec 2000 19:00:02 -0000 Date: Mon, 11 Dec 2000 14:00:02 -0500 From: Joe Abley To: Philip Smith Cc: gijucho@kt.co.kr, hanjh@kt.co.kr, apops@lists.apnic.net Subject: Re: [apops] Fwd: Korea Telecom leaking >1000 prefixes to Internet Message-ID: <20001211135958.Q22842@goose.automagic.org> References: <5.0.2.1.2.20001212042122.00ab3a40@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.10i In-Reply-To: <5.0.2.1.2.20001212042122.00ab3a40@localhost>; from pfs@cisco.com on Tue, Dec 12, 2000 at 04:23:16AM +1000 Sender: owner-apops@lists.apnic.net Precedence: bulk On Tue, Dec 12, 2000 at 04:23:16AM +1000, Philip Smith wrote: > I sent this three days ago, with no apparent resolution. Please can you, or > your upstreams repair this leakage. [...] > >gw>sh ip bgp regexp _9768$ > > > > > 210.90.24.128/26 202.249.2.24 0 2516 4766 > > 3608 9768 i > >*> 210.90.32.128/25 202.249.2.24 0 2516 4766 > >3608 9768 i > >*> 210.90.37.0/25 202.249.2.24 0 2516 4766 > >7563 9768 i > >*> 210.90.48.128/25 202.249.2.24 0 2516 4766 > >7563 9768 i > >*> 210.90.54.0/25 202.249.2.24 0 2516 4766 > >7563 9768 i > >*> 210.90.61.0/25 202.249.2.24 0 2516 4766 > >3608 9768 i > >*> 210.90.84.0/25 202.249.2.24 0 2516 4766 > >7563 9768 i > >* 210.90.89.0 202.249.2.109 0 2497 1239 > >3608 3608 9768 i > >*> 202.249.2.24 0 2516 4766 > >7563 9768 i > >* 202.249.2.19 0 2497 1239 > >3608 3608 9768 i > >*> 210.90.90.0/25 202.249.2.24 0 2516 4766 > >7563 9768 i > >*> 210.90.112.0/25 202.249.2.24 0 2516 4766 > >7563 9768 i > >*> 210.90.117.128/25 202.249.2.24 0 2516 4766 > >3608 9768 i > >*> 210.90.123.240/28 202.249.2.24 0 2516 4766 > >7563 9768 i > > > >Please will you fix your filters so that these prefixes are not announced > >to the Internet. FYI, no prefixes > /24 should appear in the Internet > >routing table. If we're pointing fingers, then 3608, 4766, 2516, 7563, 2497 and 1239 also need to be singled out for failing to implement basic martian filters. That's NBNIC-NCA, KIX, KDDI, KII, IIJ and Sprint. Oh, and cisco, presumably :) Joe * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Wed Dec 13 13:08:03 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id NAA90196; Wed, 13 Dec 2000 13:08:02 +1000 (EST) Received: from goose.automagic.org ([207.61.141.34]) by ns.apnic.net (8.9.3/8.9.3) with SMTP id XAA118013 for ; Tue, 12 Dec 2000 23:12:11 +1000 (EST) Received: (qmail 23695 invoked by uid 100); 12 Dec 2000 13:12:08 -0000 Date: Tue, 12 Dec 2000 08:12:08 -0500 From: Joe Abley To: Philip Smith Cc: gijucho@kt.co.kr, hanjh@kt.co.kr, apops@lists.apnic.net Subject: Re: [apops] Fwd: Korea Telecom leaking >1000 prefixes to Internet Message-ID: <20001212081205.B23618@goose.automagic.org> References: <5.0.2.1.2.20001212042122.00ab3a40@localhost> <5.0.2.1.2.20001212042122.00ab3a40@localhost> <20001211135958.Q22842@goose.automagic.org> <5.0.2.1.2.20001212141332.07842ec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.10i In-Reply-To: <5.0.2.1.2.20001212141332.07842ec0@localhost>; from pfs@cisco.com on Tue, Dec 12, 2000 at 02:36:27PM +1000 Sender: owner-apops@lists.apnic.net Precedence: bulk On Tue, Dec 12, 2000 at 02:36:27PM +1000, Philip Smith wrote: > At 14:00 11/12/00 -0500, Joe Abley wrote: > > >If we're pointing fingers, then 3608, 4766, 2516, 7563, 2497 and 1239 > >also need to be singled out for failing to implement basic martian > >filters. That's NBNIC-NCA, KIX, KDDI, KII, IIJ and Sprint. Oh, and > >cisco, presumably :) > > Finger pointing? Anyone in the region who has been watching their border > routers over the last year will have noticed that, every few weeks, 1200 > /26s and /30s appear in the BGP table for a few days. And then disappear > again. All from the same source. This is both a serious operational matter > for Korea Telecom, and for the rest of the Internet in the region (at least > those who choose not to implement the >/24 prefix filter)... Isn't it? And the only reason it's an operational matter for _anybody_ is that those who peer and provide transit to Korea Telecom don't filter them out. It's a fact of life that people will leak crap into the network every once and a while. Maybe Korea Telecom are leaking a lot of crap. Responsible peers and providers won't see it though, because they'll filter it as a matter of routine. > I'm sure vendors don't mind if Korea Telecom or anyone else on the Internet > does this. Vendors are more than happy to sell more memory to everyone who > carries or wants to carry the full routing table... Oh, you heartless beasts :) > BTW, to add on to Geoff's comment, it is interesting to note that my BGP > table view from one v large "Tier-1" ISP in the US has around 5000 prefixes > less than we see here in the Asia Pacific. The difference is big enough to > be interesting now... :-) This sounds like an interesting supposition to test. It would be nice if periodic measurements could be taken across the regions to give a representative sample distribution: I presume you are comparing single point measurements in the US and AP? Joe * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Wed Dec 13 13:08:03 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id NAA90197; Wed, 13 Dec 2000 13:08:03 +1000 (EST) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id EAA95109 for ; Wed, 13 Dec 2000 04:28:12 +1000 (EST) Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.11.0) id eBCHS7P31139; Tue, 12 Dec 2000 09:28:07 -0800 From: Bill Manning Message-Id: <200012121728.eBCHS7P31139@zed.isi.edu> Subject: Re: [apops] Fwd: Korea Telecom leaking >1000 prefixes to To: pfs@cisco.com (Philip Smith) Date: Tue, 12 Dec 2000 09:28:07 -0800 (PST) Cc: jabley@automagic.org (Joe Abley), apops@lists.apnic.net In-Reply-To: <5.0.2.1.2.20001213040422.07691610@localhost> from "Philip Smith" at Dec 13, 2000 04:12:54 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-apops@lists.apnic.net Precedence: bulk % % At 08:12 12/12/00 -0500, Joe Abley wrote: % >And the only reason it's an operational matter for _anybody_ is that % >those who peer and provide transit to Korea Telecom don't filter them % >out. % % Sean Doran made an interesting suggestion at the IEPG on Sunday. Charge % providers for the prefixes they announce. So if anyone thinks that 99500 is % too much for their router to take, send a bill to the people who are % announcing more than they ought to (i.e. subprefixes of their % aggregates). They may ignore it, or they may send a cheque... Who knows... % Anyone want to test the theory? This was first raised back in the CIDR idea development stages Charging for router table slot occupancy, esp. if there is a "normalized" pricing structure caused all sorts of headaches with the legal folks... something about collusion and fixing markets. Hence the big pushback onto the registries for controlling delegation sizes. --bill * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Wed Dec 13 13:08:36 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id NAA90293; Wed, 13 Dec 2000 13:08:36 +1000 (EST) Received: from syd-mail-02.magna.com.au (mail2.davtel.com.au [203.111.99.160]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id HAA118449 for ; Wed, 13 Dec 2000 07:59:40 +1000 (EST) Received: by mail2.davtel.com.au with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Dec 2000 09:02:26 +1100 Message-ID: From: Phillip Grasso-Nguyen To: "'Philip Smith'" , Geoff Huston Cc: Joe Abley , apops@lists.apnic.net Subject: RE: [apops] Fwd: Korea Telecom leaking >1000 prefixes to Internet Date: Wed, 13 Dec 2000 09:02:18 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-apops@lists.apnic.net Precedence: bulk > announcing. If KT, for example, have a commercial > in-confidence reason for > announcing /30s etc to their peers, that is their private > issue, but then > they should take reasonable steps to ensure that the rest of > the world is > not drawn into their private affairs (the no-export community > could help > with this, for example). But any provider who has a need to > announce a /nn > to the Internet should be free to do so, as you say. And it > should not > matter what it is - that's the idea of CIDR... :-) This is only a suggestion, but I *think* that the larger providers should enforce RFC2519 for no-export functionally (to the smaller ISP's), and possibility the RADB *Could* be used as an alerting tool. I found that many providers knowingly announcing smaller blocks for preferred traffic direction, e.g. Satellite backchannel providers, /19 to Telstra, and two /20's to IHUG/NetConnect. Some Go beyond that and announce 32x/24's. Not just that but other providers announce sub-CIDR for MED (effectively more control) however they should only be announcing with NO-EXPORT. (i'm guilty of doing this :-( ). If more people had RFC1998+ configured, these satellite ho's could control traffic direction without the need for announcing longer prefixes, however there are always some that DON'T want ANY traffic going via their cable paths. Obviously this lead's to it's own problems, but so is Global routing table. Regards Phillip. * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Wed Dec 13 13:09:06 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id NAA90365; Wed, 13 Dec 2000 13:09:06 +1000 (EST) Received: from syd-mail-02.magna.com.au (mail2.davtel.com.au [203.111.99.160]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id IAA121050 for ; Wed, 13 Dec 2000 08:22:54 +1000 (EST) Received: by mail2.davtel.com.au with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Dec 2000 09:25:41 +1100 Message-ID: From: Phillip Grasso-Nguyen To: "'Geoff Huston'" , Philip Smith Cc: apops@lists.apnic.net Subject: RE: [apops] Fwd: Korea Telecom leaking >1000 prefixes to Internet Date: Wed, 13 Dec 2000 09:25:31 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-apops@lists.apnic.net Precedence: bulk What stops an large providers from providing a OPEN community that will allow routes to be set with NO-EXPORT, etc. For example Telstra 1221, go-between provider AS7474, and AS1234 1221:5000 set NO-EXPORT 1221:5001 do not announce to PEERS 1221:5002 Do no announce to US upstreams. If provider AS1234 announced their routes with 1221:5000 their routes will only goto the telstra neighbours and no further. With community 1221:5001 they would not announce to peers etc. Obviously some tight controls and bit of consideration must be made before doing this (as it let's others control traffic direction etc.), but this allows true traffic engineering with multi-provider model without announcing longer-prefixes. Regards Phill. > It could, but if you want fine grained control of multiple > links then the BGP table IS the only traffic engineering > vehicle we have, and adjusting and announcing arbitrary > prefixes does not work on a day by day basis - the /24's > allow fine grained rapid (minutes) response multi-provider > traffic engineering. > > Lousy outcomes are often the outcome of not having the right tool. > > regards, > > Geoff > > * APOPS: Asia Pacific Operations Forum * > * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * > * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Fri Dec 15 04:03:25 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id EAA125029; Fri, 15 Dec 2000 04:03:24 +1000 (EST) Received: from whois3.apnic.net (whois3.apnic.net [203.37.255.102]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id EAA125021 for ; Fri, 15 Dec 2000 04:03:19 +1000 (EST) Received: from dev.apnic.net (IDENT:root@dev.apnic.net [202.12.29.129]) by whois3.apnic.net (8.10.1/UW7.1.1-NSC) with ESMTP id eBEI3IH10409 for ; Fri, 15 Dec 2000 04:03:18 +1000 (EST) Received: (from cscora@localhost) by dev.apnic.net (8.9.3/8.9.3) id EAA29353 for apops@lists.apnic.net; Fri, 15 Dec 2000 04:03:18 +1000 From: Routing Analysis Message-Id: <200012141803.EAA29353@dev.apnic.net> Subject: [apops] Asia Pacific Weekly Routing Report Date: Fri, 15 Dec 2000 04:03:18 +1000 (EST) Reply-To: pfs@cisco.com To: apops@lists.apnic.net X-Mailer: fastmail [version 2.5 PL1] Sender: owner-apops@lists.apnic.net Precedence: bulk This is an automated weekly mailing sent to the APOPS list describing the state of the Internet Routing Table in the Asia Pacific Region. Daily listings are sent to bgp-stats@lists.apnic.net For a graphical representation, please see http://www.apnic.net/stats/bgp. If you have any comments please contact Philip Smith . Asia Pacific Report 15 Dec, 2000 Analysis Summary ---------------- BGP routing table entries examined: 98466 Origin ASes present in the Internet Routing Table: 9381 Origin ASes announcing only one prefix: 3309 Transit ASes present in the Internet Routing Table: 1270 Average AS path length visible in the Internet Routing Table: 5.2 Max AS path length visible: 18 Illegal AS announcements present in the Routing Table: 13 Non-routable prefixes present in the Routing Table: 0 Prefixes being announced from the IANA Reserved Address blocks: 2 Number of addresses announced to Internet: 1219364782 Equivalent to 72 /8s, 174 /16s and 7 /24s Percentage of available address space announced: 32.9 Percentage of allocated address space announced: 64.5 Percentage of available address space allocated: 51.0 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 15722 Prefixes being announced from the APNIC address blocks: 14197 APNIC Region origin ASes present in the Internet Routing Table: 1088 APNIC Region origin ASes announcing only one prefix: 387 APNIC Region transit ASes present in the Internet Routing Table: 180 Average APNIC Region AS path length visible: 5.0 Max APNIC Region AS path length visible: 12 Number of APNIC addresses announced to Internet: 62150697 Equivalent to 3 /8s, 180 /16s and 88 /24s Percentage of available APNIC address space announced: 73.2 APNIC AS Blocks 4608 - 4864, 7467 - 7722, 9216 - 10239, 17408 - 18431 APNIC Address Blocks 61/8, 202/7 and 210/7 APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /19 equiv Description 1221 2389 1193 Telstra 2764 429 127 connect.com.au pty ltd 2563 412 60 Seoul National University 2907 377 909 SINET Japan 4740 352 73 Ozemail 4755 318 100 VSNL India 7657 293 15 The Internet Group Limited 4618 210 56 Internet Thailand 9269 206 23 Hong Kong CTI 9768 203 66 Korea Telecom 703 194 147 UUNET Technologies, Inc. 4763 186 43 Telstra New Zealand 7474 180 84 Optus Communications 7545 175 6 TPG Internet Pty Ltd 4134 154 468 Data Communications Bureau 4433 152 55 Access One Pty Ltd 4766 152 496 KORnet Powered BY Korea Telec 4786 129 8 NetConnect Communications Pty 7586 128 10 Paradox Digital Pty. Ltd 7496 127 10 Power Up Global Per AS prefix count summary ---------------------------------- ASN No of nets /19 equiv Description 701 2587 3455 UUNET Technologies, Inc. 1221 2389 1193 Telstra 705 1488 65 UUNET Technologies, Inc. 1 1021 4565 BBN Planet 7018 891 3039 AT&T 1239 710 1590 Sprint ICM-Inria 7046 676 513 UUNET Technologies, Inc. 2914 637 1287 Verio, Inc. 2548 630 556 Digital Express Group, Inc. 174 604 2734 PSINet Inc. 3561 579 1380 Cable & Wireless USA 209 577 583 Qwest 6082 537 66 Management Analysis, Incorpor 3549 494 433 Frontier GlobalCenter 3908 453 281 Supernet, Inc. 271 439 311 BCnet Backbone 4293 439 56 Cable & Wireless USA 3602 435 80 Sprint Canada 2764 429 127 connect.com.au pty ltd 2563 412 60 Seoul National University List of Unregistered ASNs (Global) ---------------------------------- Bad AS Designation Network Transit AS Description 65501 PRIVATE 64.21.103.0/24 16890 Network Services, In 2027 UNALLOCATED 150.185.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.185.128.0/18 8143 Publicom Corp. 2027 UNALLOCATED 150.186.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.187.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.188.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.189.0.0/16 10530 Interpacket Group, I 1877 UNALLOCATED 192.108.196.0/24 1880 Stupi, house man's 1877 UNALLOCATED 192.108.209.0/24 1880 Stupi, house man's 1877 UNALLOCATED 192.108.210.0/24 1880 Stupi, house man's 1877 UNALLOCATED 192.108.214.0/24 1880 Stupi, house man's 5757 UNALLOCATED 192.239.13.0/24 701 UUNET Technologies, 5757 UNALLOCATED 207.19.224.0/24 701 UUNET Technologies, Advertised IANA Reserved Addresses ---------------------------------- Network Origin AS Description 91.16.23.0/24 11770 Net56 219.219.219.0/24 2563 Seoul National University Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:23 /9:4 /10:5 /11:9 /12:32 /13:57 /14:188 /15:296 /16:6738 /17:998 /18:1966 /19:6176 /20:4254 /21:4167 /22:6314 /23:8335 /24:57482 /25:285 /26:449 /27:155 /28:112 /29:117 /30:146 /31:0 /32:158 Number of /24s announced per /8 block (Global) ---------------------------------------------- 9:2 12:297 15:1 24:620 26:1 32:7 38:9 44:3 53:2 55:1 57:9 61:53 62:109 63:2478 64:1046 65:8 66:45 91:1 128:20 129:160 130:17 131:31 132:7 133:3 134:81 135:7 136:52 137:77 138:176 139:45 140:106 141:17 142:65 143:36 144:93 145:13 146:120 147:59 148:115 149:111 150:23 151:247 152:979 153:36 154:51 155:62 156:13 157:99 158:48 159:46 160:18 161:53 162:63 163:119 164:97 165:93 166:174 167:76 168:64 169:29 170:180 171:2 192:5336 193:1809 194:1997 195:851 196:363 198:3667 199:3399 200:1708 202:2527 203:5236 204:3520 205:2426 206:2739 207:2702 208:2804 209:3219 210:669 211:185 212:722 213:269 214:6 215:11 216:2572 217:69 219:1 End of report * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Sat Dec 16 06:04:15 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id GAA114569; Sat, 16 Dec 2000 06:04:15 +1000 (EST) Received: from lovefm.cisco.com (lovefm.cisco.com [171.71.12.63]) by ns.apnic.net (8.9.3/8.9.3) with SMTP id GAA114542 for ; Sat, 16 Dec 2000 06:04:12 +1000 (EST) Received: from cisco.com (localhost.cisco.com [127.0.0.1]) by lovefm.cisco.com (8.6.12/8.6.5) with ESMTP id MAA14974; Fri, 15 Dec 2000 12:00:10 -0800 Message-Id: <200012152000.MAA14974@lovefm.cisco.com> To: nanog@merit.edu cc: tbates@cisco.com, eof-list@ripe.net, apops@apnic.net, routing-wg@ripe.net Subject: [apops] The Cidr Report Date: Fri, 15 Dec 2000 12:00:03 -0800 From: Tony Bates Sender: owner-apops@lists.apnic.net Precedence: bulk This is an auto-generated mail on Fri Dec 15 12:00:00 PST 2000 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. 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 xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 15Dec00 0) General Status Table History ------------- Date Prefixes 081200 95404 091200 95823 101200 95806 111200 95907 121200 95679 131200 95592 141200 95583 151200 95822 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 91.16.23.0/24 from AS11770 *** Bogus 219.219.219.0 from AS2563 AS Summary ---------- Number of ASes in routing system: 9359 Number of ASes announcing only one prefix: 5425 (3034 cidr, 2391 classful) Largest number of cidr routes: 1190 announced by AS705 Largest number of classful routes: 1678 announced by AS1221 1) Gains by aggregating at the origin AS level --- 15Dec00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1678 1238 440 26.2% TELSTRA-AS AS2563 264 82 182 68.9% KoRean Education Network AS701 1593 1434 159 10.0% Alternet AS271 284 131 153 53.9% BCnet Backbone AS9269 167 48 119 71.3% Hong Kong CTI AS7545 166 50 116 69.9% TPG Internet Pty Ltd AS8013 455 349 106 23.3% PSINET-CA AS6595 162 63 99 61.1% DODDSEUR AS7657 277 188 89 32.1% The Internet Group Limited AS13999 94 6 88 93.6% UNKNOWN AS705 326 242 84 25.8% ALTERNET-AS AS4755 189 105 84 44.4% Videsh Sanchar Nigam Ltd. India AS174 530 449 81 15.3% Performance Systems International AS4293 340 260 80 23.5% Internal ASN for C&W AS7496 100 23 77 77.0% Power Up AS7046 328 251 77 23.5% UUNET-CUSTOMER AS4151 282 208 74 26.2% USDA Internet Access Network AS724 243 170 73 30.0% DLA-ASNBLOCK-AS AS1727 172 99 73 42.4% MRMS-WEST AS3908 236 164 72 30.5% Supernet, Inc. AS1942 137 65 72 52.6% FR-CICG-GRENOBLE AS577 242 171 71 29.3% Bell Backbone AS7018 594 528 66 11.1% AT&T WorldNet Service Backbone AS5106 101 37 64 63.4% AADS-COLUMBUS AS3749 123 59 64 52.0% TECNET AS226 167 104 63 37.7% USC/Information Sciences Institut AS3602 307 249 58 18.9% Sprint Canada Inc. AS2548 366 308 58 15.8% DIGEX-AS AS16758 63 6 57 90.5% UNKNOWN AS376 133 77 56 42.1% RISQ 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 * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Sun Dec 17 11:50:42 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id LAA113062; Sun, 17 Dec 2000 11:50:42 +1000 (EST) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id LAA113057 for ; Sun, 17 Dec 2000 11:50:40 +1000 (EST) Received: from tecra.telstra.net ([203.10.60.18]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id MAA82655; Sun, 17 Dec 2000 12:50:38 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20001217041355.00aa3e20@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 17 Dec 2000 04:18:12 +1100 To: Philip Smith From: Geoff Huston Subject: Re: [apops] Fwd: Korea Telecom leaking >1000 prefixes to Internet Cc: apops@lists.apnic.net In-Reply-To: <5.0.2.1.2.20001213102125.079d0110@localhost> References: <4.3.2.7.2.20001213084926.00b27420@localhost> <5.0.2.1.2.20001213050250.071ecec0@localhost> <4.3.2.7.2.20001213052553.00c24100@localhost> <5.0.2.1.2.20001213040422.07691610@localhost> <20001212081205.B23618@goose.automagic.org> <5.0.2.1.2.20001212141332.07842ec0@localhost> <5.0.2.1.2.20001212042122.00ab3a40@localhost> <5.0.2.1.2.20001212042122.00ab3a40@localhost> <20001211135958.Q22842@goose.automagic.org> <5.0.2.1.2.20001212141332.07842ec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-apops@lists.apnic.net Precedence: bulk >It comes back to the question of does any of this really matter, or do we >decide that some of it matters when we are 30seconds from the brink? I suspect that this time there is no hard limit of scaleability and therefore there is no visible brink. We can all use more memory and more processor power in the box after all. My 2c is that the victim here is average route stability, and in such a metric what you see is creeping decline without sharp discontinuities. >>Lousy outcomes are often the outcome of not having the right tool. > >What would be the best way forward? Some better defined communities, say >in the vein of RFC1998, which can have meaning more AS hops away. I can't >see this scaling too well though (I seem to remember this being talked >about recently somewhere)... > >Or maybe we should say "BGP was nice, but we need a new routing protocol >for the Internet today"? I'm thinking about that very topic right now - I really don't have hard and fast answers at present, but its a very useful conversation. regards, Geoff * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Fri Dec 22 04:03:22 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id EAA101370; Fri, 22 Dec 2000 04:03:21 +1000 (EST) Received: from whois3.apnic.net (whois3.apnic.net [203.37.255.102]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id EAA101358 for ; Fri, 22 Dec 2000 04:03:16 +1000 (EST) Received: from dev.apnic.net (IDENT:root@dev.apnic.net [202.12.29.129]) by whois3.apnic.net (8.10.1/UW7.1.1-NSC) with ESMTP id eBLI3FH12737 for ; Fri, 22 Dec 2000 04:03:15 +1000 (EST) Received: (from cscora@localhost) by dev.apnic.net (8.9.3/8.9.3) id EAA31142 for apops@lists.apnic.net; Fri, 22 Dec 2000 04:03:15 +1000 From: Routing Analysis Message-Id: <200012211803.EAA31142@dev.apnic.net> Subject: [apops] Asia Pacific Weekly Routing Report Date: Fri, 22 Dec 2000 04:03:14 +1000 (EST) Reply-To: pfs@cisco.com To: apops@lists.apnic.net X-Mailer: fastmail [version 2.5 PL1] Sender: owner-apops@lists.apnic.net Precedence: bulk This is an automated weekly mailing sent to the APOPS list describing the state of the Internet Routing Table in the Asia Pacific Region. Daily listings are sent to bgp-stats@lists.apnic.net For a graphical representation, please see http://www.apnic.net/stats/bgp. If you have any comments please contact Philip Smith . Asia Pacific Report 22 Dec, 2000 Analysis Summary ---------------- BGP routing table entries examined: 99729 Origin ASes present in the Internet Routing Table: 9472 Origin ASes announcing only one prefix: 3343 Transit ASes present in the Internet Routing Table: 1272 Average AS path length visible in the Internet Routing Table: 5.3 Max AS path length visible: 18 Illegal AS announcements present in the Routing Table: 13 Non-routable prefixes present in the Routing Table: 0 Prefixes being announced from the IANA Reserved Address blocks: 2 Number of addresses announced to Internet: 1223153153 Equivalent to 72 /8s, 231 /16s and 214 /24s Percentage of available address space announced: 33.0 Percentage of allocated address space announced: 64.7 Percentage of available address space allocated: 51.0 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 15464 Prefixes being announced from the APNIC address blocks: 13953 APNIC Region origin ASes present in the Internet Routing Table: 1103 APNIC Region origin ASes announcing only one prefix: 395 APNIC Region transit ASes present in the Internet Routing Table: 181 Average APNIC Region AS path length visible: 5.0 Max APNIC Region AS path length visible: 12 Number of APNIC addresses announced to Internet: 62727080 Equivalent to 3 /8s, 189 /16s and 35 /24s Percentage of available APNIC address space announced: 73.9 APNIC AS Blocks 4608 - 4864, 7467 - 7722, 9216 - 10239, 17408 - 18431 APNIC Address Blocks 61/8, 202/7 and 210/7 APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /19 equiv Description 1221 2359 1191 Telstra 2764 433 128 connect.com.au pty ltd 2907 376 909 SINET Japan 4755 337 100 VSNL India 2563 303 51 Seoul National University 4740 288 22 Ozemail 7657 281 14 The Internet Group Limited 703 271 205 UUNET Technologies, Inc. 9269 208 23 Hong Kong CTI 4618 203 56 Internet Thailand 7545 198 7 TPG Internet Pty Ltd 4763 188 43 Telstra New Zealand 7474 180 84 Optus Communications 4134 158 485 Data Communications Bureau 4766 158 496 KORnet Powered BY Korea Telec 4786 139 8 NetConnect Communications Pty 3462 132 172 Data Communications Institute 7586 131 10 Paradox Digital Pty. Ltd 7496 127 10 Power Up 9797 127 10 Asia Online Australia Global Per AS prefix count summary ---------------------------------- ASN No of nets /19 equiv Description 701 2582 3472 UUNET Technologies, Inc. 1221 2359 1191 Telstra 705 1414 63 UUNET Technologies, Inc. 1 1019 4573 BBN Planet 7018 889 3041 AT&T 7046 699 514 UUNET Technologies, Inc. 1239 692 1612 Sprint ICM-Inria 8013 682 69 PSINet Ltd. Canada 2914 646 1287 Verio, Inc. 2548 635 556 Digital Express Group, Inc. 174 611 2735 PSINet Inc. 209 589 568 Qwest 3561 582 1363 Cable & Wireless USA 6082 540 66 Management Analysis, Incorpor 3549 499 432 Frontier GlobalCenter 3908 451 281 Supernet, Inc. 271 438 311 BCnet Backbone 4293 437 56 Cable & Wireless USA 2764 433 128 connect.com.au pty ltd 3602 433 79 Sprint Canada List of Unregistered ASNs (Global) ---------------------------------- Bad AS Designation Network Transit AS Description 65501 PRIVATE 64.21.103.0/24 16890 Network Services, In 2027 UNALLOCATED 150.185.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.185.128.0/18 8143 Publicom Corp. 2027 UNALLOCATED 150.186.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.187.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.188.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.189.0.0/16 10530 Interpacket Group, I 1877 UNALLOCATED 192.108.196.0/24 1880 Stupi, house man's 1877 UNALLOCATED 192.108.209.0/24 1880 Stupi, house man's 1877 UNALLOCATED 192.108.210.0/24 1880 Stupi, house man's 1877 UNALLOCATED 192.108.214.0/24 1880 Stupi, house man's 5757 UNALLOCATED 192.239.13.0/24 701 UUNET Technologies, 5757 UNALLOCATED 207.19.224.0/24 701 UUNET Technologies, Advertised IANA Reserved Addresses ---------------------------------- Network Origin AS Description 91.16.23.0/24 11770 Net56 219.219.219.0/24 2563 Seoul National University Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:23 /9:4 /10:5 /11:9 /12:32 /13:59 /14:190 /15:298 /16:6749 /17:1010 /18:1969 /19:6208 /20:4293 /21:4177 /22:6407 /23:8413 /24:58309 /25:283 /26:457 /27:157 /28:115 /29:111 /30:274 /31:0 /32:177 Number of /24s announced per /8 block (Global) ---------------------------------------------- 9:2 12:297 15:1 24:625 26:1 32:7 38:10 44:2 53:2 55:1 57:9 61:60 62:108 63:2454 64:1068 65:12 66:46 91:1 128:20 129:173 130:18 131:31 132:9 133:3 134:84 135:7 136:114 137:113 138:182 139:66 140:103 141:18 142:64 143:35 144:93 145:14 146:129 147:94 148:118 149:112 150:23 151:256 152:1036 153:87 154:231 155:58 156:14 157:101 158:51 159:47 160:18 161:53 162:63 163:118 164:109 165:94 166:174 167:75 168:67 169:29 170:184 171:2 192:5354 193:1813 194:1986 195:847 196:366 198:3733 199:3392 200:1712 202:2510 203:5212 204:3593 205:2502 206:2802 207:2834 208:2780 209:3337 210:532 211:136 212:707 213:268 214:7 215:11 216:2598 217:80 219:1 End of report * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Sat Dec 23 06:04:08 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id GAA88905; Sat, 23 Dec 2000 06:04:08 +1000 (EST) Received: from lovefm.cisco.com (lovefm.cisco.com [171.71.12.63]) by ns.apnic.net (8.9.3/8.9.3) with SMTP id GAA88898 for ; Sat, 23 Dec 2000 06:04:05 +1000 (EST) Received: from cisco.com (localhost.cisco.com [127.0.0.1]) by lovefm.cisco.com (8.6.12/8.6.5) with ESMTP id MAA14413; Fri, 22 Dec 2000 12:00:04 -0800 Message-Id: <200012222000.MAA14413@lovefm.cisco.com> To: nanog@merit.edu cc: tbates@cisco.com, eof-list@ripe.net, apops@apnic.net, routing-wg@ripe.net Subject: [apops] The Cidr Report Date: Fri, 22 Dec 2000 12:00:03 -0800 From: Tony Bates Sender: owner-apops@lists.apnic.net Precedence: bulk This is an auto-generated mail on Fri Dec 22 12:00:00 PST 2000 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. 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 xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 22Dec00 0) General Status Table History ------------- Date Prefixes 151200 95822 161200 95919 171200 95802 181200 95790 191200 96081 201200 96409 211200 96198 221200 96064 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 91.16.23.0/24 from AS11770 *** Bogus 219.219.219.0 from AS2563 AS Summary ---------- Number of ASes in routing system: 9441 Number of ASes announcing only one prefix: 5499 (3068 cidr, 2431 classful) Largest number of cidr routes: 1099 announced by AS705 Largest number of classful routes: 1656 announced by AS1221 1) Gains by aggregating at the origin AS level --- 22Dec00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1656 1216 440 26.6% TELSTRA-AS AS2563 239 72 167 69.9% KoRean Education Network AS701 1572 1417 155 9.9% Alternet AS271 284 131 153 53.9% BCnet Backbone AS9269 168 46 122 72.6% Hong Kong CTI AS7545 189 67 122 64.6% TPG Internet Pty Ltd AS8013 450 345 105 23.3% PSINET-CA AS6595 166 64 102 61.4% DODDSEUR AS7657 255 164 91 35.7% The Internet Group Limited AS4755 215 125 90 41.9% Videsh Sanchar Nigam Ltd. India AS705 328 244 84 25.6% ALTERNET-AS AS4293 341 260 81 23.8% Internal ASN for C&W AS174 534 453 81 15.2% Performance Systems International AS7496 100 22 78 78.0% Power Up AS7046 333 256 77 23.1% UUNET-CUSTOMER AS1727 183 107 76 41.5% MRMS-WEST AS4151 283 208 75 26.5% USDA Internet Access Network AS724 245 172 73 29.8% DLA-ASNBLOCK-AS AS3908 234 162 72 30.8% Supernet, Inc. AS1942 137 65 72 52.6% FR-CICG-GRENOBLE AS13999 79 7 72 91.1% UNKNOWN AS577 240 170 70 29.2% Bell Backbone AS7018 590 526 64 10.8% AT&T WorldNet Service Backbone AS5106 101 37 64 63.4% AADS-COLUMBUS AS3749 123 60 63 51.2% TECNET AS226 168 105 63 37.5% USC/Information Sciences Institut AS2548 370 310 60 16.2% DIGEX-AS AS3602 306 247 59 19.3% Sprint Canada Inc. AS16758 63 6 57 90.5% UNKNOWN AS376 133 77 56 42.1% RISQ 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 * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Mon Dec 25 06:02:02 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id GAA75226; Mon, 25 Dec 2000 06:02:01 +1000 (EST) Received: from dipsy.tch.org (dipsy.tch.org [166.88.4.10]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id GAA75205 for ; Mon, 25 Dec 2000 06:01:58 +1000 (EST) Received: from localhost (ahuja@localhost) by dipsy.tch.org (8.11.1/8.11.1) with ESMTP id eBOK1uH52894 for ; Sun, 24 Dec 2000 12:01:56 -0800 (PST) Date: Sun, 24 Dec 2000 12:01:56 -0800 (PST) From: abha X-Sender: To: Subject: [apops] EGP/Peering survey Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-apops@lists.apnic.net Precedence: bulk Hi All! I'm working on gathering some information about how providers interact with each other for a research project. I've compiled a rather lengthy survey that asks questions about peering, peering policy and ISP practices. If you've ever set-up peering policies, etc. for an ISP, I'd love to have your responses to this survey. While answering all questions isn't necessary, I would appreciate it. And I'll be giving T-shirts out to those who complete the whole thing! :) All answers will be kept confidential and will be anonymized and aggregated before being included in any published findings... Anyone here willing to particpate? Drop me a note and I'll send you the survey! Thanks for your help! -abha ;) ps - some of you might've filled out a survey with me at NANOG some time ago, this is actually a follow-up to that one... ;) So, your participation in this round is still appreciated! * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Fri Dec 29 04:03:29 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id EAA81878; Fri, 29 Dec 2000 04:03:28 +1000 (EST) Received: from whois3.apnic.net (whois3.apnic.net [203.37.255.102]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id EAA81869 for ; Fri, 29 Dec 2000 04:03:25 +1000 (EST) Received: from dev.apnic.net (IDENT:root@dev.apnic.net [202.12.29.129]) by whois3.apnic.net (8.10.1/UW7.1.1-NSC) with ESMTP id eBSI3PH04321 for ; Fri, 29 Dec 2000 04:03:25 +1000 (EST) Received: (from cscora@localhost) by dev.apnic.net (8.9.3/8.9.3) id EAA00478 for apops@lists.apnic.net; Fri, 29 Dec 2000 04:03:25 +1000 From: Routing Analysis Message-Id: <200012281803.EAA00478@dev.apnic.net> Subject: [apops] Asia Pacific Weekly Routing Report Date: Fri, 29 Dec 2000 04:03:24 +1000 (EST) Reply-To: pfs@cisco.com To: apops@lists.apnic.net X-Mailer: fastmail [version 2.5 PL1] Sender: owner-apops@lists.apnic.net Precedence: bulk This is an automated weekly mailing sent to the APOPS list describing the state of the Internet Routing Table in the Asia Pacific Region. Daily listings are sent to bgp-stats@lists.apnic.net For a graphical representation, please see http://www.apnic.net/stats/bgp. If you have any comments please contact Philip Smith . Asia Pacific Report 29 Dec, 2000 Analysis Summary ---------------- BGP routing table entries examined: 103246 Origin ASes present in the Internet Routing Table: 9506 Origin ASes announcing only one prefix: 3364 Transit ASes present in the Internet Routing Table: 1268 Average AS path length visible in the Internet Routing Table: 5.3 Max AS path length visible: 18 Illegal AS announcements present in the Routing Table: 13 Non-routable prefixes present in the Routing Table: 0 Prefixes being announced from the IANA Reserved Address blocks: 2 Number of addresses announced to Internet: 1224972555 Equivalent to 73 /8s, 3 /16s and 153 /24s Percentage of available address space announced: 33.0 Percentage of allocated address space announced: 64.8 Percentage of available address space allocated: 51.0 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 18368 Prefixes being announced from the APNIC address blocks: 16884 APNIC Region origin ASes present in the Internet Routing Table: 1106 APNIC Region origin ASes announcing only one prefix: 397 APNIC Region transit ASes present in the Internet Routing Table: 181 Average APNIC Region AS path length visible: 5.2 Max APNIC Region AS path length visible: 12 Number of APNIC addresses announced to Internet: 64206328 Equivalent to 3 /8s, 211 /16s and 181 /24s Percentage of available APNIC address space announced: 75.6 APNIC AS Blocks 4608 - 4864, 7467 - 7722, 9216 - 10239, 17408 - 18431 APNIC Address Blocks 61/8, 202/7 and 210/7 APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /19 equiv Description 9768 3103 97 PubNet (Korea Telecom) 1221 2355 1191 Telstra 2764 436 128 connect.com.au pty ltd 2907 375 909 SINET Japan 4755 337 102 VSNL India 4740 288 22 Ozemail 7657 279 14 The Internet Group Limited 703 248 196 UUNET Technologies, Inc. 4618 208 56 Internet Thailand 9269 205 23 Hong Kong CTI 7545 198 7 TPG Internet Pty Ltd 4763 189 43 Telstra New Zealand 7474 182 84 Optus Communications 4766 173 608 KORnet Powered BY Korea Telec 4134 160 494 Data Communications Bureau 2563 144 24 Seoul National University 4433 142 56 Access One Pty Ltd 4786 138 8 NetConnect Communications Pty 3462 134 172 Data Communications Institute 7586 133 10 Paradox Digital Pty. Ltd Global Per AS prefix count summary ---------------------------------- ASN No of nets /19 equiv Description 9768 3103 97 PubNet (Korea Telecom) 701 2580 3482 UUNET Technologies, Inc. 1221 2355 1191 Telstra 705 1431 63 UUNET Technologies, Inc. 1 1024 4578 BBN Planet 7018 887 3040 AT&T 8013 726 71 PSINet Ltd. Canada 7046 686 512 UUNET Technologies, Inc. 1239 676 1620 Sprint ICM-Inria 2914 647 1293 Verio, Inc. 2548 638 566 Digital Express Group, Inc. 174 617 2754 PSINet Inc. 209 595 568 Qwest 3561 585 1362 Cable & Wireless USA 2551 580 348 NETCOM On-Line Communication 6082 538 66 Management Analysis, Incorpor 3549 500 432 Frontier GlobalCenter 3908 449 281 Supernet, Inc. 4293 439 56 Cable & Wireless USA 2764 436 128 connect.com.au pty ltd List of Unregistered ASNs (Global) ---------------------------------- Bad AS Designation Network Transit AS Description 65501 PRIVATE 64.21.103.0/24 16890 Network Services, In 2027 UNALLOCATED 150.185.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.185.128.0/18 8143 Publicom Corp. 2027 UNALLOCATED 150.186.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.187.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.188.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.189.0.0/16 10530 Interpacket Group, I 1877 UNALLOCATED 192.108.196.0/24 1880 Stupi, house man's 1877 UNALLOCATED 192.108.209.0/24 1880 Stupi, house man's 1877 UNALLOCATED 192.108.210.0/24 1880 Stupi, house man's 1877 UNALLOCATED 192.108.214.0/24 1880 Stupi, house man's 5757 UNALLOCATED 192.239.13.0/24 701 UUNET Technologies, 5757 UNALLOCATED 207.19.224.0/24 701 UUNET Technologies, Advertised IANA Reserved Addresses ---------------------------------- Network Origin AS Description 91.16.23.0/24 11770 Net56 219.219.219.0/24 2563 Seoul National University Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:23 /9:4 /10:5 /11:9 /12:32 /13:59 /14:193 /15:303 /16:6743 /17:1012 /18:1974 /19:6224 /20:4312 /21:4194 /22:6433 /23:8434 /24:58955 /25:986 /26:1495 /27:637 /28:196 /29:588 /30:285 /31:1 /32:149 Number of /24s announced per /8 block (Global) ---------------------------------------------- 9:2 12:299 15:1 24:625 26:1 32:7 38:10 44:2 53:2 55:1 57:9 61:63 62:108 63:2463 64:1080 65:12 66:50 91:1 128:16 129:176 130:18 131:30 132:9 133:3 134:80 135:7 136:113 137:112 138:189 139:56 140:104 141:18 142:46 143:35 144:93 145:14 146:129 147:92 148:119 149:116 150:23 151:325 152:1037 153:110 154:232 155:58 156:14 157:100 158:51 159:47 160:18 161:47 162:63 163:118 164:104 165:93 166:174 167:73 168:68 169:29 170:185 171:2 192:5347 193:1803 194:1996 195:839 196:365 198:3728 199:3455 200:1693 202:2508 203:5163 204:3629 205:2522 206:2858 207:2974 208:2796 209:3426 210:642 211:195 212:729 213:284 214:7 215:11 216:2619 217:83 219:1 End of report * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Fri Dec 29 05:33:26 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id FAA93215; Fri, 29 Dec 2000 05:33:25 +1000 (EST) Received: from marina.lowendale.com.au (gw.lowendale.com.au [203.26.242.120]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id FAA93194 for ; Fri, 29 Dec 2000 05:33:23 +1000 (EST) Received: from localhost (neale@localhost) by marina.lowendale.com.au (8.9.3/8.9.3/Debian/GNU) with ESMTP id GAA15454; Fri, 29 Dec 2000 06:46:17 +1100 Date: Fri, 29 Dec 2000 06:46:15 +1100 (EST) From: Neale Banks To: apops@lists.apnic.net Subject: Re: [apops] Asia Pacific Weekly Routing Report In-Reply-To: <200012281803.EAA00478@dev.apnic.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-apops@lists.apnic.net Precedence: bulk On Fri, 29 Dec 2000, Routing Analysis wrote: [...] > APNIC Region per AS prefix count summary > ---------------------------------------- > > ASN No of nets /19 equiv Description > 9768 3103 97 PubNet (Korea Telecom) [...] Ouch! I don't recall seeing this one previously. Given that 97*32 is 3104, has PubNet de-aggregated everything down to /24? Anyone know anything more about this? Regards, Neale. * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Fri Dec 29 12:39:31 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id MAA77689; Fri, 29 Dec 2000 12:39:31 +1000 (EST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id MAA77685 for ; Fri, 29 Dec 2000 12:39:28 +1000 (EST) Received: from pfs-laptop.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA24272; Thu, 28 Dec 2000 18:37:29 -0800 (PST) Message-Id: <5.0.2.1.2.20001229123149.072a0aa0@localhost> X-Sender: philsmit@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 29 Dec 2000 12:36:35 +1000 To: Neale Banks From: Philip Smith Subject: Re: [apops] Asia Pacific Weekly Routing Report Cc: apops@lists.apnic.net In-Reply-To: References: <200012281803.EAA00478@dev.apnic.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-apops@lists.apnic.net Precedence: bulk It has been a frequent occurrence ongoing for at least the last year or so. I mentioned it explicitly on the list a week or so back. The problem is caused by iBGP prefixes not intended for the public Internet being accidentally leaked out to PubNet's peers due to a missing eBGP filter. philip -- At 06:46 29/12/00 +1100, Neale Banks wrote: >On Fri, 29 Dec 2000, Routing Analysis wrote: > >[...] > > APNIC Region per AS prefix count summary > > ---------------------------------------- > > > > ASN No of nets /19 equiv Description > > 9768 3103 97 PubNet (Korea Telecom) >[...] > >Ouch! I don't recall seeing this one previously. > >Given that 97*32 is 3104, has PubNet de-aggregated everything down to /24? > >Anyone know anything more about this? > >Regards, >Neale. > >* APOPS: Asia Pacific Operations Forum * >* To unsubscribe: send "unsubscribe" to apops-request@apnic.net * * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Fri Dec 29 22:10:54 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id WAA81059; Fri, 29 Dec 2000 22:10:53 +1000 (EST) Received: from marina.lowendale.com.au (gw.lowendale.com.au [203.26.242.120]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id WAA81055 for ; Fri, 29 Dec 2000 22:10:50 +1000 (EST) Received: from localhost (neale@localhost) by marina.lowendale.com.au (8.9.3/8.9.3/Debian/GNU) with ESMTP id XAA16366; Fri, 29 Dec 2000 23:23:49 +1100 Date: Fri, 29 Dec 2000 23:23:47 +1100 (EST) From: Neale Banks To: Philip Smith cc: apops@lists.apnic.net Subject: Re: [apops] Asia Pacific Weekly Routing Report In-Reply-To: <5.0.2.1.2.20001229123149.072a0aa0@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-apops@lists.apnic.net Precedence: bulk On Fri, 29 Dec 2000, Philip Smith wrote: > It has been a frequent occurrence ongoing for at least the last year or so. > I mentioned it explicitly on the list a week or so back. Ah, that one. > The problem is caused by iBGP prefixes not intended for the public Internet > being accidentally leaked out to PubNet's peers due to a missing eBGP filter. So the problem is not one of de-aggreagtion down to say /24 but rather leaking of prefixes >>/24 to peers (the theory being that such long prefixes belong securely in IGPs and not in eBGP)? Regards, Neale. * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Sat Dec 30 03:07:11 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id DAA115898; Sat, 30 Dec 2000 03:07:11 +1000 (EST) Received: from tcb.net (tcb.net [205.168.100.1]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id DAA115894 for ; Sat, 30 Dec 2000 03:07:08 +1000 (EST) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id KAA09349 for ; Fri, 29 Dec 2000 10:05:58 -0700 Message-Id: <200012291705.KAA09349@tcb.net> X-Mailer: exmh version 2.0.3 To: apops@lists.apnic.net From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: Re: [apops] Asia Pacific Weekly Routing Report Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Dec 2000 10:05:58 -0700 Sender: owner-apops@lists.apnic.net Precedence: bulk > So the problem is not one of de-aggreagtion down to say /24 but rather > leaking of prefixes >>/24 to peers (the theory being that such long > prefixes belong securely in IGPs and not in eBGP)? I don't think anyone said that, at least, I hope not. IMO, you only want to put as much in your IGP as you have to, and that's it. At a previous employer we actually saw something similar to this (i.e., leaking of more-specifics that should have been denied by egress policies). It turned out that the folks doing to configuration management were rewriting most all of the routing/redistribution policies (e.g., route-maps and prefix filters) and because some were rather large, they'd take quite a bit of time to load. In the mean time, the BGP redistribution process would run, detect absence of the prescribed policy, and pass all routes through while NOT tagging the routes with one of the NON-transit BGP communities. In short, the quick fix was to simply permit advertisement of prefixes with explicitly tagged with transit communities, and implicitly deny all other prefixes. As well, we modified the configuration automation stuff so that policies were only touched if actual updates occurred [duh!]. The one thing we never did completely figure out is why some of the more-specifics hung around in other networks for sometimes hours, or even days, as the next iteration of the redistribute process contained the newly modified policy and the routes [should have been] withdrawn. I can only assume that some implementation bug resulted in this. I guess I should state that I'm not at all a fan of redistribution of information into another protocol, it was inherited, really! -danny * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Sat Dec 30 06:04:35 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id GAA71535; Sat, 30 Dec 2000 06:04:34 +1000 (EST) Received: from lovefm.cisco.com (lovefm.cisco.com [171.71.12.63]) by ns.apnic.net (8.9.3/8.9.3) with SMTP id GAA71516 for ; Sat, 30 Dec 2000 06:04:31 +1000 (EST) Received: from cisco.com (localhost.cisco.com [127.0.0.1]) by lovefm.cisco.com (8.6.12/8.6.5) with ESMTP id MAA01301; Fri, 29 Dec 2000 12:00:05 -0800 Message-Id: <200012292000.MAA01301@lovefm.cisco.com> To: nanog@merit.edu cc: tbates@cisco.com, eof-list@ripe.net, apops@apnic.net, routing-wg@ripe.net Subject: [apops] The Cidr Report Date: Fri, 29 Dec 2000 12:00:04 -0800 From: Tony Bates Sender: owner-apops@lists.apnic.net Precedence: bulk This is an auto-generated mail on Fri Dec 29 12:00:00 PST 2000 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. 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 xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 29Dec00 0) General Status Table History ------------- Date Prefixes 221200 96064 231200 96185 241200 96234 251200 96104 261200 95929 271200 96096 281200 96103 291200 96164 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 8416 Number of ASes announcing only one prefix: 4902 (2470 cidr, 2432 classful) Largest number of cidr routes: 1112 announced by AS705 Largest number of classful routes: 1652 announced by AS1221 1) Gains by aggregating at the origin AS level --- 29Dec00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1652 1215 437 26.5% TELSTRA-AS AS701 1581 1426 155 9.8% Alternet AS271 284 131 153 53.9% BCnet Backbone AS7545 189 67 122 64.6% TPG Internet Pty Ltd AS9269 165 46 119 72.1% Hong Kong CTI AS8013 449 344 105 23.4% PSINET-CA AS6595 162 63 99 61.1% DODDSEUR AS7657 253 164 89 35.2% The Internet Group Limited AS2563 127 40 87 68.5% KoRean Education Network AS705 326 241 85 26.1% ALTERNET-AS AS4755 209 124 85 40.7% Videsh Sanchar Nigam Ltd. India AS4293 341 258 83 24.3% Internal ASN for C&W AS174 527 448 79 15.0% Performance Systems International AS7496 100 22 78 78.0% Power Up AS4151 278 201 77 27.7% USDA Internet Access Network AS1727 187 111 76 40.6% MRMS-WEST AS7046 329 254 75 22.8% UUNET-CUSTOMER AS724 244 172 72 29.5% DLA-ASNBLOCK-AS AS3908 233 161 72 30.9% Supernet, Inc. AS1942 137 65 72 52.6% FR-CICG-GRENOBLE AS13999 79 7 72 91.1% UNKNOWN AS577 240 170 70 29.2% Bell Backbone AS7018 594 527 67 11.3% AT&T WorldNet Service Backbone AS5106 101 37 64 63.4% AADS-COLUMBUS AS3749 122 58 64 52.5% TECNET AS3602 307 244 63 20.5% Sprint Canada Inc. AS226 167 104 63 37.7% USC/Information Sciences Institut AS2548 365 308 57 15.6% DIGEX-AS AS16758 63 6 57 90.5% UNKNOWN AS376 133 77 56 42.1% RISQ 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 * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net *