From owner-apops@lists.apnic.net Wed Apr 4 13:47:08 2001 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id NAA110345; Wed, 4 Apr 2001 13:47:07 +1000 (EST) Received: from enterprise.comms.unsw.edu.au (enterprise.comms.unsw.EDU.AU [129.94.1.210]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id NAA110340 for ; Wed, 4 Apr 2001 13:47:06 +1000 (EST) Received: from enterprise (enterprise [129.94.1.210]) by enterprise.comms.unsw.edu.au (8.9.3/8.9.3) with ESMTP id NAA09108 for ; Wed, 4 Apr 2001 13:47:04 +1000 (EST) Date: Wed, 4 Apr 2001 13:47:04 +1000 (EST) From: Ivan Philips X-Sender: ivan@enterprise Reply-To: ivan@unsw.edu.au To: apops@apnic.net Subject: [apops] Remote Environmental Monitoring Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-apops@lists.apnic.net Precedence: bulk Hi All, I was wondering if anybody has had any exerience in temperature/humidity monitoring for computer rooms. We have a number of geographical locations that require monitoring. I would like something that would have a 10BaseT interface and support SNMP. I have done some web searches and found a few products. But, industry experience is always good. Thanks Ivan Philips * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Fri Apr 6 04:04:24 2001 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id EAA87105; Fri, 6 Apr 2001 04:04: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 EAA87085 for ; Fri, 6 Apr 2001 04:04:22 +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 f35I4A912831; Fri, 6 Apr 2001 04:04:10 +1000 (EST) Received: (from cscora@localhost) by dev.apnic.net (8.9.3/8.9.3) id EAA27249; Fri, 6 Apr 2001 04:04:10 +1000 From: Routing Analysis Message-Id: <200104051804.EAA27249@dev.apnic.net> Subject: [apops] Weekly Routing Table Report Date: Fri, 6 Apr 2001 04:04:09 +1000 (EST) Reply-To: pfs@cisco.com To: apops@lists.apnic.net, rtma@arin.net, routing-wg@ripe.net X-Mailer: fastmail [version 2.5 PL1] Sender: owner-apops@lists.apnic.net Precedence: bulk This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats@lists.apnic.net For a graphical representation, please see http://www.apnic.net/stats/bgp. If you have any comments please contact Philip Smith . Routing Table Report 06 Apr, 2001 Analysis Summary ---------------- BGP routing table entries examined: 102338 Origin ASes present in the Internet Routing Table: 10506 Origin ASes announcing only one prefix: 3773 Transit ASes present in the Internet Routing Table: 1397 Average AS path length visible in the Internet Routing Table: 5.3 Max AS path length visible: 15 Illegal AS announcements present in the Routing Table: 17 Non-routable prefixes present in the Routing Table: 0 Prefixes being announced from the IANA Reserved Address blocks: 3 Number of addresses announced to Internet: 1218893376 Equivalent to 72 /8s, 166 /16s and 214 /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: 15577 Prefixes being announced from the APNIC address blocks: 14073 APNIC Region origin ASes present in the Internet Routing Table: 1222 APNIC Region origin ASes announcing only one prefix: 439 APNIC Region transit ASes present in the Internet Routing Table: 204 Average APNIC Region AS path length visible: 5.1 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 69182459 Equivalent to 4 /8s, 31 /16s and 163 /24s Percentage of available APNIC address space announced: 68.0 APNIC AS Blocks 4608 - 4864, 7467 - 7722, 9216 - 10239, 17408 - 18431 APNIC Address Blocks 61/8, 202/7, 210/7 and 218/8 ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 70742 Prefixes being announced from the ARIN address blocks: 48171 ARIN Region origin ASes present in the Internet Routing Table: 6397 ARIN Region origin ASes announcing only one prefix: 1876 ARIN Region transit ASes present in the Internet Routing Table: 658 Average ARIN Region AS path length visible: 5.2 Max ARIN Region AS path length visible: 14 Number of ARIN addresses announced to Internet: 180496434 Equivalent to 10 /8s, 194 /16s and 40 /24s Percentage of available ARIN address space announced: 82.8 ARIN AS Blocks 1 - 1876, 1902 - 2042, 2044 - 2046, 2048 - 2106 2138 - 2584, 2615 - 2772, 2823 - 2829, 2880 - 3153 3354 - 4607, 4865 - 5119, 5632 - 6655, 6912 - 7466 7723 - 8191, 10240 - 12287, 13312 - 15359 16384 - 17407, 18432 - 20479 ARIN Address Blocks 63/8, 64/7, 66/8, 199/8, 200/8, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 16002 Prefixes being announced from the RIPE address blocks: 12681 RIPE Region origin ASes present in the Internet Routing Table: 2885 RIPE Region origin ASes announcing only one prefix: 1458 RIPE Region transit ASes present in the Internet Routing Table: 533 Average RIPE Region AS path length visible: 6.0 Max RIPE Region AS path length visible: 15 Number of RIPE addresses announced to Internet: 96435151 Equivalent to 5 /8s, 191 /16s and 123 /24s Percentage of available RIPE address space announced: 82.1 RIPE AS Blocks 1877 - 1901, 2042, 2047, 2107 - 2136, 2585 - 2614 2773 - 2822, 2830 - 2879, 3154 - 3353, 5377 - 5631 6656 - 6911, 8192 - 9215, 12288 - 13311, 15360 - 16383 20480 - 21503 RIPE Address Blocks 62/8, 193/8, 194/7, 212/7 and 217/8 APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /19 equiv Description 1221 2084 684 Telstra 2764 431 139 connect.com.au pty ltd 703 376 204 UUNET Technologies, Inc. 2907 365 884 SINET Japan 4755 291 108 VSNL India 4538 243 1024 China Education and Research 7474 196 86 Optus Communications 4134 183 615 Data Communications Bureau 4763 177 34 Telstra New Zealand 4766 177 618 KORnet Powered BY Korea Telec 1237 164 71 System Engineering Research I 7657 160 12 The Internet Group Limited 7539 158 101 Delegated to TWNIC for subseq 9269 156 22 Hong Kong CTI 7545 152 10 TPG Internet Pty Ltd 17561 150 60 Internet service provision to 4740 149 10 Ozemail 4786 127 7 NetConnect Communications Pty 7617 124 46 One.Net Pty Ltd 9797 123 10 Asia Online Australia RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /19 equiv Description 702 427 634 UUNET Technologies, Inc. 3301 399 337 TeliaNet Sweden 1257 279 247 Swipnet AB 1270 278 448 UUNET Germany 680 208 913 Deutschef Forschurgsnetz 3215 203 227 RAIN 719 190 146 LANLINK 5515 190 336 Sonera Finland 786 184 959 JANET IP Service 3320 158 710 Deutsche Telekom AG 1849 139 243 UUNET UK (formerly PIPEX) 517 128 134 Xlink 5400 124 33 Concert Internet Plus Europea 3303 123 298 Swisscom 2856 122 388 BTnet UK Regional network 1290 115 206 PSINet UK Ltd. 8708 113 5 Romania Data System 1267 97 978 IUnet S.p.A 1901 97 69 EUnet Austria 2830 96 38 UUNET UK (formerly PIPEX) ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /19 equiv Description 701 2419 3628 UUNET Technologies, Inc. 705 1286 58 UUNET Technologies, Inc. 1 967 4497 BBN Planet 7018 948 3055 AT&T 7046 809 552 UUNET Technologies, Inc. 1239 642 1588 Sprint ICM-Inria 2914 605 1219 Verio, Inc. 3561 557 1249 Cable & Wireless USA 174 556 2768 PSINet Inc. 3549 540 496 Global Crossing 4293 482 51 Cable & Wireless USA 209 442 674 Qwest 690 414 49 Merit Network 2548 398 514 Digital Express Group, Inc. 3908 382 262 Supernet, Inc. 8112 372 76 Bell Atlantic Internet Soluti 8151 365 218 UniNet S.A. de C.V. 8013 339 55 PSINet Ltd. Canada 4323 337 136 Time Warner Communications, I 3967 332 223 Exodus Communication Global Per AS prefix count summary ---------------------------------- ASN No of nets /19 equiv Description 701 2419 3628 UUNET Technologies, Inc. 1221 2084 684 Telstra 705 1286 58 UUNET Technologies, Inc. 1 967 4497 BBN Planet 7018 948 3055 AT&T 7046 809 552 UUNET Technologies, Inc. 1239 642 1588 Sprint ICM-Inria 2914 605 1219 Verio, Inc. 3561 557 1249 Cable & Wireless USA 174 556 2768 PSINet Inc. 3549 540 496 Global Crossing 4293 482 51 Cable & Wireless USA 209 442 674 Qwest 2764 431 139 connect.com.au pty ltd 702 427 634 UUNET Technologies, Inc. 690 414 49 Merit Network 3301 399 337 TeliaNet Sweden 2548 398 514 Digital Express Group, Inc. 3908 382 262 Supernet, Inc. 703 376 204 UUNET Technologies, Inc. List of Unregistered ASNs (Global) ---------------------------------- Bad AS Designation Network Transit AS Description 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 1800 SPRINT 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 1800 SPRINT 5757 UNALLOCATED 192.239.13.0/24 701 UUNET Technologies, 65535 PRIVATE 203.24.169.0/24 17486 Swiftel Communicatio 65500 PRIVATE 203.166.86.0/24 10084 Western Australian I 5555 UNALLOCATED 205.110.64.0/24 721 DLA Systems Automati 5555 UNALLOCATED 205.110.68.0/22 721 DLA Systems Automati 5555 UNALLOCATED 205.110.72.0/21 721 DLA Systems Automati 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 106.1.1.0/24 5705 Sirius Solutions, Inc. 106.1.2.0/24 5705 Sirius Solutions, Inc. 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:4 /11:10 /12:29 /13:66 /14:204 /15:330 /16:6916 /17:1116 /18:2088 /19:6536 /20:5007 /21:4411 /22:6680 /23:8570 /24:59077 /25:260 /26:339 /27:146 /28:108 /29:67 /30:174 /31:1 /32:174 Number of /24s announced per /8 block (Global) ---------------------------------------------- 9:3 12:351 13:10 15:1 17:1 24:700 26:1 32:10 38:7 44:3 47:1 53:2 55:1 57:9 61:28 62:134 63:1891 64:1422 65:652 66:216 91:1 106:2 128:31 129:122 130:20 131:25 132:11 133:1 134:152 135:8 136:17 137:115 138:247 139:52 140:108 141:172 142:55 143:151 144:37 145:9 146:134 147:92 148:149 149:134 150:26 151:360 152:874 153:33 154:13 155:75 156:38 157:103 158:61 159:79 160:18 161:56 162:91 163:135 164:128 165:126 166:174 167:135 168:80 169:30 170:210 171:2 192:5383 193:1867 194:2040 195:759 196:375 198:3642 199:3370 200:1889 202:2468 203:4958 204:3376 205:2254 206:2729 207:2784 208:2911 209:3208 210:495 211:171 212:816 213:379 214:9 215:11 216:2871 217:177 End of report * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Sat Apr 7 16:04:37 2001 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id QAA81792; Sat, 7 Apr 2001 16:04:37 +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 QAA81788 for ; Sat, 7 Apr 2001 16:04:34 +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 XAA23850; Fri, 6 Apr 2001 23:00:02 -0700 Message-Id: <200104070600.XAA23850@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, 06 Apr 2001 23:00:02 -0700 From: Tony Bates Sender: owner-apops@lists.apnic.net Precedence: bulk This is an auto-generated mail on Fri Apr 6 23:00:00 PDT 2001 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 06Apr01 0) General Status Table History ------------- Date Prefixes 300301 98619 310301 98637 010401 98847 020401 98771 030401 98768 040401 98995 050401 99092 060401 99382 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 AS Summary ---------- Number of ASes in routing system: 10427 Number of ASes announcing only one prefix: 6119 (3475 cidr, 2644 classful) Largest number of cidr routes: 945 announced by AS705 Largest number of classful routes: 1594 announced by AS1221 1) Gains by aggregating at the origin AS level --- 06Apr01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1594 1193 401 25.2% Telstra Pty Ltd AS701 1469 1288 181 12.3% UUNET Technologies, Inc. AS8013 574 462 112 19.5% PSINet Ltd. Canada AS6429 215 103 112 52.1% RdC Internet AS6595 165 63 102 61.8% DoD Education Activity Network As AS705 343 245 98 28.6% UUNET Technologies, Inc. AS13999 104 8 96 92.3% Mega Cable S.A. de C.V. AS4151 242 148 94 38.8% USDA AS4293 373 280 93 24.9% Cable & Wireless USA AS7018 674 591 83 12.3% AT&T AS4755 207 126 81 39.1% Videsh Sanchar Nigam Ltd. Autonom AS577 241 172 69 28.6% Bell Advanced Communications Inc. AS5106 101 37 64 63.4% Ameritech Advanced Data Services, AS9498 80 17 63 78.8% BHARTI BT INTERNET LTD. AS3464 153 91 62 40.5% Alabama SuperComputer Network AS3749 121 60 61 50.4% Tennessee Board of Regents AS724 211 151 60 28.4% DLA Systems Automation Center AS11252 92 34 58 63.0% ISU Computer Center Bldg. 5 AS16758 63 6 57 90.5% IKON Office Solutions AS6413 67 11 56 83.6% Southern Online Systems, Inc. AS376 134 78 56 41.8% Reseau Interordinateurs Scientiqu AS226 148 92 56 37.8% Los Nettos AS7568 84 29 55 65.5% C.S. Communications Co., Ltd. AS1 608 553 55 9.0% BBN Planet AS4323 230 176 54 23.5% Time Warner Communications, Inc. AS6471 99 46 53 53.5% ENTEL CHILE S.A. AS17561 110 59 51 46.4% Internet service provision to Wes AS9269 113 64 49 43.4% City Telecom (H.K.) Ltd. AS174 417 368 49 11.8% PSINet Inc. AS1237 107 58 49 45.8% System Engineering Research Insti 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 Thu Apr 12 15:42:46 2001 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id PAA114634; Thu, 12 Apr 2001 15:42:45 +1000 (EST) Received: from oxygen2.syd.dav.net.au (oxygen2.syd.dav.net.au [203.111.0.43]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id PAA114629 for ; Thu, 12 Apr 2001 15:42:44 +1000 (EST) Received: from PGLAPTOP (plutonium.davtel.com.au [203.111.99.99]) by oxygen2.syd.dav.net.au (8.10.2/8.10.2/oxygen2/3.0) with SMTP id f3C5ghw18557; Thu, 12 Apr 2001 15:42:43 +1000 (EST) Message-ID: <002e01c0c313$6897aee0$b4646fcb@PGLAPTOP> From: "Phillip Grasso-Nguyen" To: , Subject: [apops] Telstra Community support Date: Thu, 12 Apr 2001 15:42:33 +1000 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-apops@lists.apnic.net Precedence: bulk Looks like Telstra do not want to support transitive communities, is there other "large" providers out there that does NOT support this BY CHOICE? Regards Phill. * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Fri Apr 13 04:30:44 2001 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id EAA66507; Fri, 13 Apr 2001 04:30:43 +1000 (EST) Received: from dev.apnic.net (dev.apnic.net [202.12.29.129]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id EAA66489 for ; Fri, 13 Apr 2001 04:30:42 +1000 (EST) Received: (from cscora@localhost) by dev.apnic.net (8.9.3/8.9.3) id EAA04244; Fri, 13 Apr 2001 04:30:40 +1000 From: Routing Analysis Message-Id: <200104121830.EAA04244@dev.apnic.net> Subject: [apops] Weekly Routing Table Report Date: Fri, 13 Apr 2001 04:30:40 +1000 (EST) Reply-To: pfs@cisco.com To: apops@lists.apnic.net, rtma@arin.net, routing-wg@ripe.net X-Mailer: fastmail [version 2.5 PL1] Sender: owner-apops@lists.apnic.net Precedence: bulk This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats@lists.apnic.net For a graphical representation, please see http://www.apnic.net/stats/bgp. If you have any comments please contact Philip Smith . Routing Table Report 13 Apr, 2001 Analysis Summary ---------------- BGP routing table entries examined: 103359 Origin ASes present in the Internet Routing Table: 10563 Origin ASes announcing only one prefix: 3791 Transit ASes present in the Internet Routing Table: 1417 Average AS path length visible in the Internet Routing Table: 5.3 Max AS path length visible: 15 Illegal AS announcements present in the Routing Table: 23 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: 1238454464 Equivalent to 73 /8s, 209 /16s and 80 /24s Percentage of available address space announced: 33.4 Percentage of allocated address space announced: 65.5 Percentage of available address space allocated: 51.0 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 16123 Prefixes being announced from the APNIC address blocks: 14631 APNIC Region origin ASes present in the Internet Routing Table: 1225 APNIC Region origin ASes announcing only one prefix: 432 APNIC Region transit ASes present in the Internet Routing Table: 200 Average APNIC Region AS path length visible: 5.1 Max APNIC Region AS path length visible: 14 Number of APNIC addresses announced to Internet: 71027382 Equivalent to 4 /8s, 59 /16s and 202 /24s Percentage of available APNIC address space announced: 69.8 APNIC AS Blocks 4608 - 4864, 7467 - 7722, 9216 - 10239, 17408 - 18431 APNIC Address Blocks 61/8, 202/7, 210/7 and 218/8 ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 71093 Prefixes being announced from the ARIN address blocks: 48604 ARIN Region origin ASes present in the Internet Routing Table: 6428 ARIN Region origin ASes announcing only one prefix: 1891 ARIN Region transit ASes present in the Internet Routing Table: 672 Average ARIN Region AS path length visible: 5.2 Max ARIN Region AS path length visible: 14 Number of ARIN addresses announced to Internet: 181106981 Equivalent to 10 /8s, 203 /16s and 121 /24s Percentage of available ARIN address space announced: 83.0 ARIN AS Blocks 1 - 1876, 1902 - 2042, 2044 - 2046, 2048 - 2106 2138 - 2584, 2615 - 2772, 2823 - 2829, 2880 - 3153 3354 - 4607, 4865 - 5119, 5632 - 6655, 6912 - 7466 7723 - 8191, 10240 - 12287, 13312 - 15359 16384 - 17407, 18432 - 20479 ARIN Address Blocks 63/8, 64/7, 66/8, 199/8, 200/8, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 16120 Prefixes being announced from the RIPE address blocks: 12783 RIPE Region origin ASes present in the Internet Routing Table: 2911 RIPE Region origin ASes announcing only one prefix: 1468 RIPE Region transit ASes present in the Internet Routing Table: 544 Average RIPE Region AS path length visible: 5.9 Max RIPE Region AS path length visible: 15 Number of RIPE addresses announced to Internet: 96664777 Equivalent to 5 /8s, 194 /16s and 252 /24s Percentage of available RIPE address space announced: 82.3 RIPE AS Blocks 1877 - 1901, 2042, 2047, 2107 - 2136, 2585 - 2614 2773 - 2822, 2830 - 2879, 3154 - 3353, 5377 - 5631 6656 - 6911, 8192 - 9215, 12288 - 13311, 15360 - 16383 20480 - 21503 RIPE Address Blocks 62/8, 193/8, 194/7, 212/7 and 217/8 APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /19 equiv Description 1221 2000 684 Telstra 2764 872 164 connect.com.au pty ltd 703 377 204 UUNET Technologies, Inc. 2907 363 884 SINET Japan 4755 300 110 VSNL India 4538 240 1022 China Education and Research 7539 218 97 Delegated to TWNIC for subseq 4766 187 770 KORnet Powered BY Korea Telec 4134 186 616 Data Communications Bureau 7474 186 85 Optus Communications 1237 163 71 System Engineering Research I 9269 160 22 Hong Kong CTI 7657 155 12 The Internet Group Limited 4740 153 10 Ozemail 17561 150 60 Internet service provision to 7545 149 10 TPG Internet Pty Ltd 4786 128 7 NetConnect Communications Pty 7617 124 46 One.Net Pty Ltd 7586 123 9 Paradox Digital Pty. Ltd 9797 122 10 Asia Online Australia RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /19 equiv Description 702 467 662 UUNET Technologies, Inc. 3301 390 337 TeliaNet Sweden 1257 278 247 Swipnet AB 1270 278 448 UUNET Germany 680 206 913 Deutschef Forschurgsnetz 3215 206 235 RAIN 719 190 146 LANLINK 5515 190 336 Sonera Finland 786 184 959 JANET IP Service 3320 159 710 Deutsche Telekom AG 517 129 135 Xlink 5400 125 33 Concert Internet Plus Europea 3303 123 298 Swisscom 2856 122 388 BTnet UK Regional network 1290 116 206 PSINet UK Ltd. 8708 115 5 Romania Data System 1849 108 224 UUNET UK (formerly PIPEX) 3352 108 241 Ibernet, Internet A 1267 97 978 IUnet S.p.A 1901 97 77 EUnet Austria ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /19 equiv Description 701 2411 3625 UUNET Technologies, Inc. 705 1390 62 UUNET Technologies, Inc. 7018 965 3194 AT&T 1 964 4497 BBN Planet 7046 824 560 UUNET Technologies, Inc. 1239 651 1638 Sprint ICM-Inria 2914 605 1211 Verio, Inc. 3561 554 1248 Cable & Wireless USA 174 529 2759 PSINet Inc. 3549 517 495 Global Crossing 4293 480 52 Cable & Wireless USA 209 449 675 Qwest 690 414 49 Merit Network 2548 398 514 Digital Express Group, Inc. 3908 382 262 Supernet, Inc. 8151 361 218 UniNet S.A. de C.V. 4323 337 136 Time Warner Communications, I 3967 335 224 Exodus Communication 8013 335 54 PSINet Ltd. Canada 11371 318 49 Rhythms NetConnections Global Per AS prefix count summary ---------------------------------- ASN No of nets /19 equiv Description 701 2411 3625 UUNET Technologies, Inc. 1221 2000 684 Telstra 705 1390 62 UUNET Technologies, Inc. 7018 965 3194 AT&T 1 964 4497 BBN Planet 2764 872 164 connect.com.au pty ltd 7046 824 560 UUNET Technologies, Inc. 1239 651 1638 Sprint ICM-Inria 2914 605 1211 Verio, Inc. 3561 554 1248 Cable & Wireless USA 174 529 2759 PSINet Inc. 3549 517 495 Global Crossing 4293 480 52 Cable & Wireless USA 702 467 662 UUNET Technologies, Inc. 209 449 675 Qwest 690 414 49 Merit Network 2548 398 514 Digital Express Group, Inc. 3301 390 337 TeliaNet Sweden 3908 382 262 Supernet, Inc. 703 377 204 UUNET Technologies, Inc. List of Unregistered ASNs (Global) ---------------------------------- Bad AS Designation Network Transit AS Description 65130 PRIVATE 65.28.144.0/20 7017 Continental Cablevis 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 1800 SPRINT 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 1800 SPRINT 5757 UNALLOCATED 192.239.13.0/24 701 UUNET Technologies, 65132 PRIVATE 202.160.247.176/28 7473 SINGTEL-IX 65132 PRIVATE 202.160.247.208/28 7473 SINGTEL-IX 65132 PRIVATE 202.160.247.224/28 7473 SINGTEL-IX 65535 PRIVATE 203.24.169.0/24 17486 Swiftel Communicatio 65132 PRIVATE 203.126.77.0/24 7473 SINGTEL-IX 65500 PRIVATE 203.166.86.0/24 10084 Western Australian I 65333 PRIVATE 203.208.131.0/24 7473 SINGTEL-IX 5555 UNALLOCATED 205.110.64.0/24 721 DLA Systems Automati 5555 UNALLOCATED 205.110.68.0/22 721 DLA Systems Automati 5555 UNALLOCATED 205.110.72.0/21 721 DLA Systems Automati 5757 UNALLOCATED 207.19.224.0/24 701 UUNET Technologies, Advertised IANA Reserved Addresses ---------------------------------- Network Origin AS Description 106.1.1.0/24 5705 Sirius Solutions, Inc. 106.1.2.0/24 5705 Sirius Solutions, Inc. 223.255.46.0/24 6853 GLOBAL-ONE-PORTUGAL 223.255.70.0/24 6853 GLOBAL-ONE-PORTUGAL Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:22 /9:4 /10:4 /11:10 /12:29 /13:67 /14:205 /15:330 /16:6925 /17:1127 /18:2102 /19:6576 /20:5032 /21:4440 /22:6736 /23:8682 /24:59899 /25:264 /26:374 /27:155 /28:134 /29:90 /30:93 /31:1 /32:58 Number of /24s announced per /8 block (Global) ---------------------------------------------- 9:3 12:354 13:10 15:1 17:1 24:708 26:1 32:12 38:7 44:3 47:2 53:2 55:1 57:12 61:28 62:133 63:1923 64:1456 65:751 66:246 106:2 128:31 129:115 130:20 131:25 132:9 133:1 134:161 135:8 136:16 137:116 138:246 139:52 140:141 141:174 142:56 143:76 144:132 145:9 146:134 147:134 148:153 149:134 150:27 151:176 152:838 153:33 154:13 155:76 156:39 157:108 158:61 159:80 160:18 161:56 162:61 163:135 164:113 165:127 166:175 167:134 168:81 169:32 170:210 171:2 192:5397 193:1907 194:2056 195:766 196:376 198:3676 199:3382 200:1914 202:2506 203:5143 204:3358 205:2241 206:2726 207:2830 208:2915 209:3269 210:735 211:191 212:809 213:393 214:8 215:11 216:2903 217:191 223:2 End of report * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Sat Apr 14 01:09:57 2001 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id BAA92605; Sat, 14 Apr 2001 01:09:57 +1000 (EST) Received: from oxygen2.syd.dav.net.au (oxygen2.syd.dav.net.au [203.111.0.43]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id BAA92586 for ; Sat, 14 Apr 2001 01:09:56 +1000 (EST) Received: from PGLAPTOP (plutonium.davtel.com.au [203.111.99.99]) by oxygen2.syd.dav.net.au (8.10.2/8.10.2/oxygen2/3.0) with SMTP id f3DF9oj07418; Sat, 14 Apr 2001 01:09:50 +1000 (EST) Message-ID: <002501c0c42b$ccbc1550$6500a8c0@PGLAPTOP> From: "Phillip Grasso-Nguyen" To: , , "Simon Hackett" References: <002e01c0c313$6897aee0$b4646fcb@PGLAPTOP> Subject: [apops] Re: [Oz-ISP] Telstra Community support Date: Sat, 14 Apr 2001 01:09:56 +1000 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-apops@lists.apnic.net Precedence: bulk > Can you define your meaning of the following phrases? > > - 'does not want to support' > - 'transitive communities' Simple, Telstra (AS1221), will not pass on communities set by it's customers and peers to any other customers, peers, and upstreams. > - 'large' hmmmm, "large" is ones own perception (if something thinks they are large, then so be it). But normally a good reference is apnic membership status or something like that. > - 'by choice' By the own preference, a Telstra POLICY. This makes passing bgp communities to other networks via Telstra impossible. Specifically if you want to do things similar RFC1998+ or setting remote policies via communites on your own network, or to someone elses. Regards Phillip. > At 3:42 PM +1000 12/4/01, Phillip Grasso-Nguyen wrote: > >Looks like Telstra do not want to support transitive communities, is there > >other "large" providers out there that does NOT support this BY CHOICE? > > > >Regards > > Phill. > > > >---- > >Email "unsubscribe aussie-isp" to majordomo@aussie.net to be removed. > > > --- > Simon Hackett, Technical Director, Internode Systems Pty Ltd > 31 York St [PO Box 284, Rundle Mall], Adelaide, SA 5000 Australia > Email: simon@internode.com.au Web: http://www.on.net > Phone: +61-8-8223-2999 Fax: +61-8-8223-1777 > * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Sat Apr 14 01:37:40 2001 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id BAA96443; Sat, 14 Apr 2001 01:37:40 +1000 (EST) Received: from buddha.automagic.org ([207.61.141.34]) by ns.apnic.net (8.9.3/8.9.3) with SMTP id BAA96439 for ; Sat, 14 Apr 2001 01:37:37 +1000 (EST) Received: (qmail 29537 invoked by uid 100); 13 Apr 2001 15:37:30 -0000 Date: Fri, 13 Apr 2001 11:37:29 -0400 From: Joe Abley To: Phillip Grasso-Nguyen Cc: apops@lists.apnic.net, aussie-isp@aussie.net, Simon Hackett Subject: Re: [apops] Re: [Oz-ISP] Telstra Community support Message-ID: <20010413113729.L19984@buddha.home.automagic.org> References: <002e01c0c313$6897aee0$b4646fcb@PGLAPTOP> <002501c0c42b$ccbc1550$6500a8c0@PGLAPTOP> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <002501c0c42b$ccbc1550$6500a8c0@PGLAPTOP>; from grasso@magna.com.au on Sat, Apr 14, 2001 at 01:09:56AM +1000 Sender: owner-apops@lists.apnic.net Precedence: bulk On Sat, Apr 14, 2001 at 01:09:56AM +1000, Phillip Grasso-Nguyen wrote: > > Can you define your meaning of the following phrases? > > > > - 'does not want to support' > > - 'transitive communities' > Simple, Telstra (AS1221), will not pass on communities set by it's customers > and peers to any other customers, peers, and upstreams. > > > - 'large' > hmmmm, "large" is ones own perception (if something thinks they are large, > then so be it). But normally a good reference is apnic membership status or > something like that. > > - 'by choice' > By the own preference, a Telstra POLICY. > > This makes passing bgp communities to other networks via Telstra impossible. > Specifically if you want to do things similar RFC1998+ or setting remote > policies via communites on your own network, or to someone elses. I'm not actually aware of any transit ASN anywhere that will propagate communities set by customers to peers, other customers or upstream ASes. I'm sure there are some, but none of the networks I have worked with will do this. What are you trying to achieve? Joe * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Sat Apr 14 02:26:53 2001 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id CAA102908; Sat, 14 Apr 2001 02:26:53 +1000 (EST) Received: from oxygen2.syd.dav.net.au (oxygen2.syd.dav.net.au [203.111.0.43]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id CAA102889 for ; Sat, 14 Apr 2001 02:26:52 +1000 (EST) Received: from PGLAPTOP (plutonium.davtel.com.au [203.111.99.99]) by oxygen2.syd.dav.net.au (8.10.2/8.10.2/oxygen2/3.0) with SMTP id f3DGQij18441; Sat, 14 Apr 2001 02:26:44 +1000 (EST) Message-ID: <006101c0c436$8af00e00$6500a8c0@PGLAPTOP> From: "Phillip Grasso-Nguyen" To: "Joe Abley" Cc: References: <002e01c0c313$6897aee0$b4646fcb@PGLAPTOP> <002501c0c42b$ccbc1550$6500a8c0@PGLAPTOP> <20010413113729.L19984@buddha.home.automagic.org> Subject: Re: [apops] Re: [Oz-ISP] Telstra Community support Date: Sat, 14 Apr 2001 02:26:50 +1000 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-apops@lists.apnic.net Precedence: bulk > I'm not actually aware of any transit ASN anywhere that will propagate > communities set by customers to peers, other customers or upstream ASes. > I'm sure there are some, but none of the networks I have worked with > will do this. e.g. Open transit, global one,ATT, Concert,sprint > What are you trying to achieve? by providers being able to pass communites, remote policy can be changed, e.g check out open transits policies, Extract from whois -h whois.ra.bet AS5511 Community Definition ------------------------------------------------------ 5511:1000 Do not announce to US peers 5511:1001 Prepend 5511 when announcing to US peers 5511:1002 Prepend 5511 5511 when announcing to US peers 5511:1101 Do not announce to Sprintlink/AS1239 5511:1102 Do not announce to ICM/AS1800 5511:1201 Prepend 5511 when announcing to Sprintlink 5511:1202 Prepend 5511 when announcing to ICM 5511:1301 Prepend 5511 5511 when announcing to Sprintlink 5511:1302 Prepend 5511 5511 when announcing to ICM 5511:1401 Do not announce to Sprint on Relay 5511:2000 Do not announce to european peers 5511:2001 Prepend 5511 when announcing to european peers 5511:2002 Prepend 5511 5511 to european peers 5511:2101 Do not announce to Global One/AS4000 5511:2102 Do not announce to Ebone/AS1755 5511:2201 Prepend 5511 when announcing to Global One 5511:2202 Prepend 5511 when announcing to Ebone 5511:2301 Prepend 5511 5511 when announcing to Global One 5511:2302 Prepend 5511 5511 when announcing to Ebone 5511:3000 Do not announce to asia/pacific peers 5511:4000 Do not announce to other peers endless possiblities. means that service providers don't have to break cidr to control their inbound policies, also gives end providers a choice how their networks get routed, specially if some providers want to route around bottleneaks etc. Regards Phillip. > > > Joe > * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Sat Apr 14 16:04:43 2001 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id QAA69840; Sat, 14 Apr 2001 16:04:43 +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 QAA69833 for ; Sat, 14 Apr 2001 16:04:41 +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 XAA28499; Fri, 13 Apr 2001 23:00:07 -0700 Message-Id: <200104140600.XAA28499@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, 13 Apr 2001 23:00:06 -0700 From: Tony Bates Sender: owner-apops@lists.apnic.net Precedence: bulk This is an auto-generated mail on Fri Apr 13 23:00:02 PDT 2001 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 13Apr01 0) General Status Table History ------------- Date Prefixes 060401 99382 070401 99975 080401 99951 090401 100057 100401 99187 110401 99440 120401 100138 130401 99823 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 223.255.46.0 from AS6853 *** Bogus 223.255.70.0 from AS6853 AS Summary ---------- Number of ASes in routing system: 10451 Number of ASes announcing only one prefix: 6152 (3491 cidr, 2661 classful) Largest number of cidr routes: 1051 announced by AS705 Largest number of classful routes: 1589 announced by AS1221 1) Gains by aggregating at the origin AS level --- 13Apr01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1589 1191 398 25.0% Telstra Pty Ltd AS701 1471 1283 188 12.8% UUNET Technologies, Inc. AS15412 666 535 131 19.7% FLAG Telecom Global Internet AS AS6429 210 103 107 51.0% RdC Internet AS4151 245 142 103 42.0% USDA AS6595 165 63 102 61.8% DoD Education Activity Network As AS705 342 245 97 28.4% UUNET Technologies, Inc. AS4293 372 281 91 24.5% Cable & Wireless USA AS7018 697 609 88 12.6% AT&T AS8013 321 236 85 26.5% PSINet Ltd. Canada AS4755 218 136 82 37.6% Videsh Sanchar Nigam Ltd. Autonom AS13999 97 16 81 83.5% Mega Cable S.A. de C.V. AS577 241 172 69 28.6% Bell Advanced Communications Inc. AS5106 98 35 63 64.3% Ameritech Advanced Data Services, AS3749 120 59 61 50.8% Tennessee Board of Regents AS3464 152 91 61 40.1% Alabama SuperComputer Network AS11252 92 34 58 63.0% ISU Computer Center Bldg. 5 AS16758 63 6 57 90.5% IKON Office Solutions AS6413 67 11 56 83.6% Southern Online Systems, Inc. AS226 149 93 56 37.6% Los Nettos AS1 606 550 56 9.2% BBN Planet AS724 201 146 55 27.4% DLA Systems Automation Center AS4323 232 178 54 23.3% Time Warner Communications, Inc. AS6471 99 46 53 53.5% ENTEL CHILE S.A. AS7568 83 31 52 62.7% C.S. Communications Co., Ltd. AS9498 72 22 50 69.4% BHARTI BT INTERNET LTD. AS9269 115 66 49 42.6% City Telecom (H.K.) Ltd. AS852 200 152 48 24.0% Telus Advanced Communications AS10692 62 14 48 77.4% DLS Computer Services, Inc. AS174 407 360 47 11.5% PSINet Inc. 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 Apr 14 23:32:20 2001 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id XAA123396; Sat, 14 Apr 2001 23:32:20 +1000 (EST) Received: from buddha.automagic.org ([207.61.141.34]) by ns.apnic.net (8.9.3/8.9.3) with SMTP id XAA123391 for ; Sat, 14 Apr 2001 23:32:16 +1000 (EST) Received: (qmail 5239 invoked by uid 100); 14 Apr 2001 13:32:14 -0000 Date: Sat, 14 Apr 2001 09:32:13 -0400 From: Joe Abley To: Phillip Grasso-Nguyen Cc: apops@lists.apnic.net Subject: Re: [apops] Re: [Oz-ISP] Telstra Community support Message-ID: <20010414093213.A18845@buddha.home.automagic.org> References: <002e01c0c313$6897aee0$b4646fcb@PGLAPTOP> <002501c0c42b$ccbc1550$6500a8c0@PGLAPTOP> <20010413113729.L19984@buddha.home.automagic.org> <006101c0c436$8af00e00$6500a8c0@PGLAPTOP> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <006101c0c436$8af00e00$6500a8c0@PGLAPTOP>; from grasso@magna.com.au on Sat, Apr 14, 2001 at 02:26:50AM +1000 Sender: owner-apops@lists.apnic.net Precedence: bulk On Sat, Apr 14, 2001 at 02:26:50AM +1000, Phillip Grasso-Nguyen wrote: > > What are you trying to achieve? > by providers being able to pass communites, remote policy can be changed, > e.g > check out open transits policies, > Extract from whois -h whois.ra.bet AS5511 > Community Definition > ------------------------------------------------------ > 5511:1000 Do not announce to US peers > 5511:1001 Prepend 5511 when announcing to US peers > 5511:1002 Prepend 5511 5511 when announcing to US peers > 5511:1101 Do not announce to Sprintlink/AS1239 > 5511:1102 Do not announce to ICM/AS1800 > 5511:1201 Prepend 5511 when announcing to Sprintlink > 5511:1202 Prepend 5511 when announcing to ICM > 5511:1301 Prepend 5511 5511 when announcing to Sprintlink > 5511:1302 Prepend 5511 5511 when announcing to ICM > 5511:1401 Do not announce to Sprint on Relay > 5511:2000 Do not announce to european peers > 5511:2001 Prepend 5511 when announcing to european peers > 5511:2002 Prepend 5511 5511 to european peers > 5511:2101 Do not announce to Global One/AS4000 > 5511:2102 Do not announce to Ebone/AS1755 > 5511:2201 Prepend 5511 when announcing to Global One > 5511:2202 Prepend 5511 when announcing to Ebone > 5511:2301 Prepend 5511 5511 when announcing to Global One > 5511:2302 Prepend 5511 5511 when announcing to Ebone > 5511:3000 Do not announce to asia/pacific peers > 5511:4000 Do not announce to other peers 5511 is not passing these communities through to peers, though, which is what you said you were asking for, wasn't it? You seem to want a mechanism that will allow you to influence the way your prefixes are propagated to the rest of the world; however, by asking Telstra to leave whatever communities you set intact, you are presupposing a solution. > endless possiblities. Endless is a little over-enthusiastic :) > means that service providers don't have to break cidr to control their > inbound policies, also gives end providers a choice how their networks get > routed, specially if some providers want to route around bottleneaks etc. The normal approach to routing around bottlenecks is to call your provider and say "hey! there's a bottleneck there. you should fix your export policy to avoid that." You are asking Telstra to offload the job of fixing their transit issues onto their customers. To some extent, this is similar to them just providing you with telnet access to their routers, and saying "if you need to make changes, go ahead" :) Joe * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Sun Apr 15 01:50:48 2001 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id BAA74454; Sun, 15 Apr 2001 01:50:47 +1000 (EST) Received: from oxygen2.syd.dav.net.au (oxygen2.syd.dav.net.au [203.111.0.43]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id BAA74450 for ; Sun, 15 Apr 2001 01:50:46 +1000 (EST) Received: from PGLAPTOP (plutonium.davtel.com.au [203.111.99.99]) by oxygen2.syd.dav.net.au (8.10.2/8.10.2/oxygen2/3.0) with SMTP id f3EFogj06644; Sun, 15 Apr 2001 01:50:42 +1000 (EST) Message-ID: <003d01c0c4fa$ad2512d0$6500a8c0@PGLAPTOP> From: "Phillip Grasso-Nguyen" To: "Joe Abley" Cc: References: <002e01c0c313$6897aee0$b4646fcb@PGLAPTOP> <002501c0c42b$ccbc1550$6500a8c0@PGLAPTOP> <20010413113729.L19984@buddha.home.automagic.org> <006101c0c436$8af00e00$6500a8c0@PGLAPTOP> <20010414093213.A18845@buddha.home.automagic.org> Subject: Re: [apops] Re: [Oz-ISP] Telstra Community support Date: Sun, 15 Apr 2001 01:50:47 +1000 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-apops@lists.apnic.net Precedence: bulk Hi > 5511 is not passing these communities through to peers, though, which is > what you said you were asking for, wasn't it? I'm not sure what they are passing to peers, but they have set these communities for at least customers to provide some valid use. > > > endless possibilities. > Endless is a little over-enthusiastic :) ok, not endless :), but many good (and some bad) things can come with passing of transit communities. > > > means that service providers don't have to break cidr to control their > > inbound policies, also gives end providers a choice how their networks get > > routed, specially if some providers want to route around bottlenecks etc. > > The normal approach to routing around bottlenecks is to call your provider > and say "hey! there's a bottleneck there. you should fix your export policy > to avoid that." "call your provider" have you ever tried to call Telstra support, imagine you favourite organization that likes to keep customers on hold for average between 20-45minutes, when getting on the phone gives you totally pointless information ,,,,, there isn't much choice of large enough service providers in Australia. Whether the bottleneck is a long term problem with an transit provider, or a short term problem similar to a few of Telstra's recent ones (not entirely Telstra's fault). Available bandwidth is reduced to a crawl, and rtt's are coming close to 3seconds & this lasting for days, while having some options to route via other paths are very good! (there where attempts to stop advertisements to Telstra international route tables, but due to some mis-configuration our internal routes "in Telstra" where still be announced internationally). Besides that gives one the option for more fine grain control of inbound route policies. > > You are asking Telstra to offload the job of fixing their transit issues > onto their customers. To some extent, this is similar to them just providing > you with telnet access to their routers, and saying "if you need to make > changes, go ahead" :) Yes and No, Obviously the problem is not just with Telstra but with most transit providers, it is almost mandatory that you always localpref customers before peers, and peers before upstreams. I agree with this for most routing scenarios, but this is the same reason why so many people break CIDR, and announce smaller prefixes out preferred links, I would "assume" that if someone had enough brains(this is obviously debateable :-) ) to announce longer prefixes via other providers to control inbound policy, they would also know to use advanced community support if available whereby not increasing global table size. a quote from someone we all know :-) >>Most networks already give control of their routing policy to remote >> networks, by virtue of longest-prefix wins. So how much more does it hurt to give your transit customers the option to control beyond the next hop AS, how much more functionally without making it difficult. I suppose if you really wanted to be difficult you could implement the edge filtering with something similar to the old access-list 112 by Sean Doran, but then we go back to the not knowing the true network path, and black holing networks. - ( yes this someone also mention this in "verio-style edge filtering"). What about things that like, - edge cache policy propagation? where a hosting provider decided to do reverse transparent caching, being put on the cache or even off caching can be achieved via simple community - QoS policy propagation? where certain network traffic can be modified to a high precedence or QoS group via communities, and on billing can be done via Netflow? obviously these things can be done already, but so much more can be done!. Regards Phill. * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Sun Apr 15 07:28:50 2001 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id HAA115296; Sun, 15 Apr 2001 07:28:49 +1000 (EST) Received: from buddha.automagic.org ([207.61.141.34]) by ns.apnic.net (8.9.3/8.9.3) with SMTP id HAA115290 for ; Sun, 15 Apr 2001 07:28:46 +1000 (EST) Received: (qmail 3943 invoked by uid 100); 14 Apr 2001 21:28:38 -0000 Date: Sat, 14 Apr 2001 17:28:38 -0400 From: Joe Abley To: Phillip Grasso-Nguyen Cc: apops@lists.apnic.net Subject: Re: [apops] Re: [Oz-ISP] Telstra Community support Message-ID: <20010414172837.C18845@buddha.home.automagic.org> References: <002e01c0c313$6897aee0$b4646fcb@PGLAPTOP> <002501c0c42b$ccbc1550$6500a8c0@PGLAPTOP> <20010413113729.L19984@buddha.home.automagic.org> <006101c0c436$8af00e00$6500a8c0@PGLAPTOP> <20010414093213.A18845@buddha.home.automagic.org> <003d01c0c4fa$ad2512d0$6500a8c0@PGLAPTOP> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <003d01c0c4fa$ad2512d0$6500a8c0@PGLAPTOP>; from grasso@magna.com.au on Sun, Apr 15, 2001 at 01:50:47AM +1000 Sender: owner-apops@lists.apnic.net Precedence: bulk On Sun, Apr 15, 2001 at 01:50:47AM +1000, Phillip Grasso-Nguyen wrote: > > The normal approach to routing around bottlenecks is to call your provider > > and say "hey! there's a bottleneck there. you should fix your export > > policy to avoid that." > > > [...] > So change providers! > there isn't much choice of large enough > service providers in Australia. So move to New Zealand! :P There are a bunch of Australian operators who bought capacity on Southern Cross, and who now have it lit and carrying traffic. Surely you have some choice in this area? > > You are asking Telstra to offload the job of fixing their transit issues > > onto their customers. To some extent, this is similar to them just > > providing > > you with telnet access to their routers, and saying "if you need to make > > changes, go ahead" :) > > Yes and No, Obviously the problem is not just with Telstra but with most > transit providers, I don't know about that. The essence of your problem seems to be "my transit provider isn't fixing my transit well enough to keep me happy, so I want knobs I can turn to fix it myself when I notice it is broken". If Telstra are exhibiting frequent congestion towards different locations, it suggests that their inbound traffic is quite finely balanced. That being the case, I can see why they don't go out of their way to allow customers to influence their inbound traffic -- a fix to your problem might cause a bigger problem for 100 other customers. > So how much more does it hurt to give your transit customers the option to > control beyond the next hop AS, how much more functionally without making it > difficult. I suppose if you really wanted to be difficult you could > implement the edge filtering with something similar to the old access-list > 112 by Sean Doran, but then we go back to the not knowing the true network > path, and black holing networks. - ( yes this someone also mention this in > "verio-style edge filtering"). These all seem like good questions to ask Telstra. And if you don't get answers you like, surely you can take your business elsewhere :) > What about things that like, > - edge cache policy propagation? where a hosting provider decided to do > reverse transparent caching, being put on the cache or even off caching can > be achieved via simple community Aren't caches illegal in Australia, now? :) > - QoS policy propagation? where certain network traffic can be modified to a > high precedence or QoS group via communities, and on billing can be done via > Netflow? > obviously these things can be done already, but so much more can be done!. QoS is based on the premise that a small subset of customers will be willing to spend ten times more than others on the strength that they should get better performance for an hour a day, with the understanding that any performance improvement cannot be measured. I haven't seen anybody rush to deploy this yet, for some reason. Joe -- # find / -name base -exec chown us:us {} \; * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Fri Apr 20 04:09:49 2001 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id EAA110954; Fri, 20 Apr 2001 04:09:49 +1000 (EST) Received: from dev.apnic.net (dev.apnic.net [202.12.29.129]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id EAA110949 for ; Fri, 20 Apr 2001 04:09:48 +1000 (EST) Received: (from cscora@localhost) by dev.apnic.net (8.9.3/8.9.3) id EAA18244; Fri, 20 Apr 2001 04:09:47 +1000 From: Routing Analysis Message-Id: <200104191809.EAA18244@dev.apnic.net> Subject: [apops] Weekly Routing Table Report Date: Fri, 20 Apr 2001 04:09:46 +1000 (EST) Reply-To: pfs@cisco.com To: apops@lists.apnic.net, rtma@arin.net, routing-wg@ripe.net X-Mailer: fastmail [version 2.5 PL1] Sender: owner-apops@lists.apnic.net Precedence: bulk This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats@lists.apnic.net For a graphical representation, please see http://www.apnic.net/stats/bgp. If you have any comments please contact Philip Smith . Routing Table Report 20 Apr, 2001 Analysis Summary ---------------- BGP routing table entries examined: 103456 Origin ASes present in the Internet Routing Table: 10626 Origin ASes announcing only one prefix: 3836 Transit ASes present in the Internet Routing Table: 1422 Average AS path length visible in the Internet Routing Table: 5.3 Max AS path length visible: 17 Illegal AS announcements present in the Routing Table: 34 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: 1239197280 Equivalent to 73 /8s, 220 /16s and 166 /24s Percentage of available address space announced: 33.4 Percentage of allocated address space announced: 65.6 Percentage of available address space allocated: 51.0 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 15690 Prefixes being announced from the APNIC address blocks: 14205 APNIC Region origin ASes present in the Internet Routing Table: 1232 APNIC Region origin ASes announcing only one prefix: 436 APNIC Region transit ASes present in the Internet Routing Table: 197 Average APNIC Region AS path length visible: 5.1 Max APNIC Region AS path length visible: 14 Number of APNIC addresses announced to Internet: 71391058 Equivalent to 4 /8s, 65 /16s and 87 /24s Percentage of available APNIC address space announced: 70.2 APNIC AS Blocks 4608 - 4864, 7467 - 7722, 9216 - 10239, 17408 - 18431 APNIC Address Blocks 61/8, 202/7, 210/7 and 218/8 ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 71577 Prefixes being announced from the ARIN address blocks: 49051 ARIN Region origin ASes present in the Internet Routing Table: 6462 ARIN Region origin ASes announcing only one prefix: 1911 ARIN Region transit ASes present in the Internet Routing Table: 683 Average ARIN Region AS path length visible: 5.2 Max ARIN Region AS path length visible: 14 Number of ARIN addresses announced to Internet: 180570501 Equivalent to 10 /8s, 195 /16s and 73 /24s Percentage of available ARIN address space announced: 82.8 ARIN AS Blocks 1 - 1876, 1902 - 2042, 2044 - 2046, 2048 - 2106 2138 - 2584, 2615 - 2772, 2823 - 2829, 2880 - 3153 3354 - 4607, 4865 - 5119, 5632 - 6655, 6912 - 7466 7723 - 8191, 10240 - 12287, 13312 - 15359 16384 - 17407, 18432 - 20479 ARIN Address Blocks 63/8, 64/7, 66/8, 199/8, 200/8, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 16155 Prefixes being announced from the RIPE address blocks: 12841 RIPE Region origin ASes present in the Internet Routing Table: 2939 RIPE Region origin ASes announcing only one prefix: 1489 RIPE Region transit ASes present in the Internet Routing Table: 540 Average RIPE Region AS path length visible: 5.9 Max RIPE Region AS path length visible: 17 Number of RIPE addresses announced to Internet: 96663513 Equivalent to 5 /8s, 194 /16s and 247 /24s Percentage of available RIPE address space announced: 82.3 RIPE AS Blocks 1877 - 1901, 2042, 2047, 2107 - 2136, 2585 - 2614 2773 - 2822, 2830 - 2879, 3154 - 3353, 5377 - 5631 6656 - 6911, 8192 - 9215, 12288 - 13311, 15360 - 16383 20480 - 21503 RIPE Address Blocks 62/8, 193/8, 194/7, 212/7 and 217/8 APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /19 equiv Description 1221 2001 684 Telstra 2764 425 147 connect.com.au pty ltd 703 390 205 UUNET Technologies, Inc. 2907 363 875 SINET Japan 4755 301 110 VSNL India 4538 235 1038 China Education and Research 7539 228 102 Delegated to TWNIC for subseq 4134 188 623 Data Communications Bureau 4766 187 770 KORnet Powered BY Korea Telec 7474 178 85 Optus Communications 9269 161 22 Hong Kong CTI 1237 156 70 System Engineering Research I 4740 152 10 Ozemail 7657 152 12 The Internet Group Limited 17561 151 61 Internet service provision to 7545 147 10 TPG Internet Pty Ltd 4786 129 7 NetConnect Communications Pty 7586 124 9 Paradox Digital Pty. Ltd 7617 124 46 One.Net Pty Ltd 9797 122 10 Asia Online Australia RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /19 equiv Description 702 480 670 UUNET Technologies, Inc. 3301 389 337 TeliaNet Sweden 1270 280 448 UUNET Germany 1257 277 247 Swipnet AB 680 207 914 Deutschef Forschurgsnetz 3215 207 228 RAIN 5515 190 336 Sonera Finland 719 189 146 LANLINK 786 185 959 JANET IP Service 3320 160 710 Deutsche Telekom AG 5400 129 41 Concert Internet Plus Europea 517 127 134 Xlink 3303 123 298 Swisscom 2856 122 388 BTnet UK Regional network 1290 117 206 PSINet UK Ltd. 8708 113 5 Romania Data System 3352 108 241 Ibernet, Internet A 1849 107 223 UUNET UK (formerly PIPEX) 1267 97 978 IUnet S.p.A 1901 97 77 EUnet Austria ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /19 equiv Description 701 2426 3626 UUNET Technologies, Inc. 705 1612 69 UUNET Technologies, Inc. 7018 962 3190 AT&T 1 960 4495 BBN Planet 7046 801 552 UUNET Technologies, Inc. 1239 641 1603 Sprint ICM-Inria 2914 608 1210 Verio, Inc. 3561 561 1264 Cable & Wireless USA 174 533 2751 PSINet Inc. 3549 505 514 Global Crossing 4293 480 52 Cable & Wireless USA 209 449 707 Qwest 690 424 43 Merit Network 2548 400 514 Digital Express Group, Inc. 3908 376 262 Supernet, Inc. 8151 362 218 UniNet S.A. de C.V. 3967 336 226 Exodus Communication 4323 336 136 Time Warner Communications, I 8013 336 54 PSINet Ltd. Canada 11371 332 50 Rhythms NetConnections Global Per AS prefix count summary ---------------------------------- ASN No of nets /19 equiv Description 701 2426 3626 UUNET Technologies, Inc. 1221 2001 684 Telstra 705 1612 69 UUNET Technologies, Inc. 7018 962 3190 AT&T 1 960 4495 BBN Planet 7046 801 552 UUNET Technologies, Inc. 1239 641 1603 Sprint ICM-Inria 2914 608 1210 Verio, Inc. 3561 561 1264 Cable & Wireless USA 174 533 2751 PSINet Inc. 3549 505 514 Global Crossing 702 480 670 UUNET Technologies, Inc. 4293 480 52 Cable & Wireless USA 209 449 707 Qwest 2764 425 147 connect.com.au pty ltd 690 424 43 Merit Network 2548 400 514 Digital Express Group, Inc. 703 390 205 UUNET Technologies, Inc. 3301 389 337 TeliaNet Sweden 3908 376 262 Supernet, Inc. List of Unregistered ASNs (Global) ---------------------------------- Bad AS Designation Network Transit AS Description 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 1800 SPRINT 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 1800 SPRINT 5757 UNALLOCATED 192.239.13.0/24 701 UUNET Technologies, 64561 PRIVATE 202.139.40.192/27 7474 Optus Communications 64537 PRIVATE 202.139.47.96/29 7474 Optus Communications 64537 PRIVATE 202.139.116.0/25 7474 Optus Communications 64532 PRIVATE 202.139.116.128/27 7474 Optus Communications 64532 PRIVATE 202.139.116.192/27 7474 Optus Communications 64532 PRIVATE 202.139.116.224/29 7474 Optus Communications 64532 PRIVATE 202.139.116.240/29 7474 Optus Communications 64532 PRIVATE 202.139.116.248/29 7474 Optus Communications 64534 PRIVATE 202.139.121.0/28 7474 Optus Communications 64537 PRIVATE 202.139.168.192/27 7474 Optus Communications 64543 PRIVATE 202.139.182.0/28 7474 Optus Communications 65535 PRIVATE 203.24.169.0/24 17486 Swiftel Communicatio 65500 PRIVATE 203.166.86.0/24 10084 Western Australian I 64553 PRIVATE 203.202.2.72/29 7474 Optus Communications 64555 PRIVATE 203.202.9.88/29 7474 Optus Communications 64534 PRIVATE 203.202.9.128/25 7474 Optus Communications 64548 PRIVATE 203.202.10.0/27 7474 Optus Communications 64560 PRIVATE 203.202.14.80/28 7474 Optus Communications 64553 PRIVATE 203.202.15.16/28 7474 Optus Communications 5555 UNALLOCATED 205.110.64.0/24 721 DLA Systems Automati 5555 UNALLOCATED 205.110.68.0/22 721 DLA Systems Automati 5555 UNALLOCATED 205.110.72.0/21 721 DLA Systems Automati 5757 UNALLOCATED 207.19.224.0/24 701 UUNET Technologies, Advertised IANA Reserved Addresses ---------------------------------- Network Origin AS Description 223.255.46.0/24 6853 GLOBAL-ONE-PORTUGAL 223.255.70.0/24 6853 GLOBAL-ONE-PORTUGAL Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:22 /9:4 /10:4 /11:10 /12:29 /13:67 /14:206 /15:326 /16:6939 /17:1125 /18:2106 /19:6583 /20:5060 /21:4421 /22:6744 /23:8626 /24:59774 /25:275 /26:405 /27:216 /28:196 /29:134 /30:125 /31:1 /32:58 Number of /24s announced per /8 block (Global) ---------------------------------------------- 9:3 12:354 13:10 15:1 17:1 24:709 26:1 32:12 38:7 44:3 47:1 53:2 55:1 57:11 61:28 62:131 63:1916 64:1461 65:954 66:274 128:30 129:112 130:20 131:26 132:9 133:1 134:168 135:8 136:16 137:117 138:247 139:52 140:149 141:176 142:61 143:41 144:131 145:9 146:132 147:134 148:154 149:134 150:27 151:175 152:801 153:33 154:15 155:77 156:39 157:109 158:61 159:83 160:28 161:56 162:61 163:136 164:129 165:127 166:177 167:134 168:82 169:34 170:219 171:2 192:5410 193:1949 194:2046 195:770 196:406 198:3656 199:3384 200:1909 202:2471 203:4989 204:3376 205:2246 206:2719 207:2844 208:2905 209:3202 210:481 211:190 212:847 213:408 214:9 215:11 216:2936 217:196 223:2 End of report * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Sat Apr 21 16:04:45 2001 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id QAA128592; Sat, 21 Apr 2001 16:04:45 +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 QAA128586 for ; Sat, 21 Apr 2001 16:04:42 +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 XAA07120; Fri, 20 Apr 2001 23:00:04 -0700 Message-Id: <200104210600.XAA07120@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, 20 Apr 2001 23:00:04 -0700 From: Tony Bates Sender: owner-apops@lists.apnic.net Precedence: bulk This is an auto-generated mail on Fri Apr 20 23:00:00 PDT 2001 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 20Apr01 0) General Status Table History ------------- Date Prefixes 130401 99823 140401 99656 150401 99795 160401 99731 170401 99601 180401 99779 190401 99884 200401 100216 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 223.255.46.0 from AS6853 *** Bogus 223.255.70.0 from AS6853 AS Summary ---------- Number of ASes in routing system: 10519 Number of ASes announcing only one prefix: 6219 (3531 cidr, 2688 classful) Largest number of cidr routes: 1218 announced by AS705 Largest number of classful routes: 1592 announced by AS1221 1) Gains by aggregating at the origin AS level --- 20Apr01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1592 1194 398 25.0% Telstra Pty Ltd AS701 1462 1276 186 12.7% 1 AS705 368 251 117 31.8% 1 AS6429 214 105 109 50.9% 1 AS4151 247 139 108 43.7% 1 AS6595 163 62 101 62.0% 1 AS13999 104 8 96 92.3% 1 AS4293 370 277 93 25.1% 1 AS7018 694 605 89 12.8% 1 AS15412 430 341 89 20.7% FLAG Telecom Global Internet AS AS8013 319 236 83 26.0% 1 AS4755 218 138 80 36.7% Videsh Sanchar Nigam Ltd. Autonom AS577 241 172 69 28.6% 1 AS5106 101 37 64 63.4% 1 AS3749 120 59 61 50.8% 1 AS9498 75 15 60 80.0% BHARTI BT INTERNET LTD. AS3464 151 92 59 39.1% 1 AS11252 92 34 58 63.0% 1 AS724 203 146 57 28.1% 1 AS16758 63 6 57 90.5% 1 AS1 609 552 57 9.4% 1 AS6413 67 11 56 83.6% 1 AS226 149 93 56 37.6% 1 AS7568 84 29 55 65.5% C.S. Communications Co., Ltd. AS6471 99 46 53 53.5% 1 AS4323 230 178 52 22.6% 1 AS9269 116 67 49 42.2% City Telecom (H.K.) Ltd. AS852 200 152 48 24.0% 1 AS10692 62 14 48 77.4% 1 AS9683 48 2 46 95.8% Kyonggi Cable TV 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 Wed Apr 25 03:35:38 2001 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id DAA126821; Wed, 25 Apr 2001 03:35:37 +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 DAA126784; Wed, 25 Apr 2001 03:35:31 +1000 (EST) Received: from pfs-laptop.cisco.com (ams-vpdn-client-180.cisco.com [144.254.46.181]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA17797; Tue, 24 Apr 2001 10:35:09 -0700 (PDT) Message-Id: <5.0.2.1.2.20010425022351.056e5588@lint.cisco.com> X-Sender: philsmit@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 25 Apr 2001 02:35:20 +1000 To: routing-wg@ripe.net From: Philip Smith Subject: [apops] Draft revision of RIPE-210: Coordinated Route Flap Damping Parameters Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-apops@lists.apnic.net Precedence: bulk Hi, bcc: nanog, apops, APNIC routing SIG, afnog Please accept my apologies for any duplicates. The attached is a proposed update and revision of the RIPE-210 Coordinated Route Flap Damping Parameters document. The authors would welcome any comments and feedback regarding the content of this document, either to the RIPE Routing Working Group, or at the RIPE meeting in Bologna, Italy, on w/b 30th April. We would also welcome links/sample configurations/examples for other router platforms (specifically Juniper/Foundry/Extreme and any other platforms which may be found in today's Internet) to augment the Cisco IOS configuration examples given in the Appendix. thanks, and kind regards, philip -- >>>>begin RIPE Routing-WG Recommendation for coordinated route-flap damping parameters Philip Smith Daniel Karrenberg Christian Panigl Joachim Schmitz This document Obsoletes: ripe-210, ripe-178 ----------------------------------------------------------------- Document status Version 1.2, April 24th, 2001 Abstract This paper recommends a set of route-flap damping parameters which should be applied by all ISPs in the Internet and should be deployed as default values by BGP router vendors. Table of Contents 1. Introduction 1.1 Motivation for route-flap damping 1.2 What is route-flap damping ? 1.3 "Progressive" versus "flat&gentle" approach 1.4 Motivation for coordinated parameters 1.5 Aggregation versus damping 1.6 "Golden Networks" 2. Recommended damping parameters 2.1 Motivation for recommendation 2.2 Description of recommended damping parameters 2.3 Example configuration for Cisco IOS 3. Other Features contributing to Internet Stability 3.1 BGP Route Refresh 3.2 Soft Reconfiguration (Cisco IOS) 3.3 Fast-External-Fallover (Cisco IOS) 4. Potential problems 4.1 Multiplication of flaps between ASes with multiple interconnections 4.2 Non-recommended flap damping parameters 5. References 6. Acknowledgements Appendices A.1 "Golden Networks" A.2 Sample Cisco IOS Configuration A.3 Study of Flap Damping Operation 1. Introduction Route-flap damping is a mechanism for (BGP) routers which is aimed at improving the overall stability of the Internet routing table and reducing the load on the CPUs of the core routers. 1.1 Motivation for route-flap damping In the early 1990s the accelerating growth in the number of prefixes being announced to the Internet (often due to inadequate prefix-aggregation), the denser meshing through multiple inter-provider paths, and increased instabilities started to cause significant impact on the performance and efficiency of the Internet backbone routers. Every time a routing prefix becomes unreachable because of a single line-flap, the withdrawal has to be advertised to the whole core Internet and dealt with by every single router which is carrying the full Internet routing table. To overcome this situation a route-flap damping mechanism was invented in 1993 and has been integrated into several router software implementations since 1995 (for example, Cisco, Merit/RSd, GateD Consortium). The implementation is described in detail in RFC2439. The flap damping mechanism is now widely used to help keep severe instabilities under control and more localised in the Internet. And there is a second benefit: it is raising the awareness of the existence of instabilities because severe route/line-flapping problems lead to permanent suppression of the unstable area by means of holding down the flapping prefixes. Route-flap damping has its greatest and most consistent value if it is applied as near to the source of the problem as possible. Therefore flap-damping should be applied both at peering and upstream boundaries, as well as at customer boundaries (see 1.4 and 1.5 for details). 1.2 What is route-flap damping ? When BGP route-flap damping is enabled in a router the router starts to collect statistics about the announcement and withdrawal of prefixes. Route-flap damping is governed by a set of parameters with vendor-supplied default values which may be modified by the router manager. The names, semantic and syntax of these parameters differ between the various implementations; however, the behaviour of the damping mechanism is basically the same. Each time a prefix is withdrawn, the router will increment the damping penalty by a fixed amount. When the number of withdrawals/announcements (=flap) is exceeded in a given time frame (cutoff threshold) the path is no longer used and not advertised to any BGP neighbour for a predetermined period starting from when the prefix stops flapping. Any more flaps happening after the prefix enters suppressed state will attract additional penalty. Once the prefix stops flapping, the penalty is decremented over time using a half-life parameter until the penalty is below a reuse threshold. Once below this reuse threshold the suppressed path is then re-used and re-advertised to BGP neighbours. Pointers to some more detailed and vendor specific documents: Cisco BGP Case Studies: Route Flap Damping http://www.cisco.com/warp/public/459/16.html ISI/RSd Configuration: Route Flap Damping http://www.isi.edu/div7/ra/RSd/doc/dampen.html GateD Configuration: Weighted Route Damping Statement http://www.gated.org/gated-web/code/doc/manuals/config_guide/bgp/ weighted_route_dampening.html See also "5. References" 1.3 "Progressive" versus "flat&gentle" approach One easy approach would be to just apply the current default-parameters which are treating all prefixes equally ("flat&gentle") everywhere. However, there is a major concern to penalise longer prefixes (=smaller aggregates) more than well aggregated short prefixes ("progressive"), because the number of short prefixes in the routing table is significantly lower and it seems in general that those are tending to be more stable and also are tending to affect more users. Another aspect is that progressive damping might increase the awareness of aggregation needs. However, it has to be accompanied by a careful design which doesn't force a rush to request and assign more address space than needed. A significant number of important services is sitting in long prefixes (e.g. root name servers), so the progressive approach has to exclude the strong penalisation for these so-called "golden" prefixes. With this recommendation we are trying to make a compromise and it is therefore called "graded damping". 1.4 Motivation for coordinated parameters There is a strong need for the coordinated use of damping parameters for several reasons: Coordination of "progressiveness": If penalties are not coordinated throughout the Internet, route-flap damping could lead to additional flapping or inconsistent routing because longer prefixes might already be re-announced through some parts of the Internet where shorter prefixes are still held down through other paths. Coordination of hold-down and reuse-threshold parameters between ISPs: If an upstream or peering provider would be damping more aggressively (e.g. triggered by less flaps or applying longer hold-down timers) than an access-provider towards his customers it will lead to a very inconsistent situation, where a flapping network might still be able to reach "near-line" parts of the Internet. Debugging of such instabilities is then much harder because the effect for the customer leads to the assumption that there is a problem "somewhere" in the "upstream" Internet instead of making him just call his ISPs hot-line and complain that he can't get out any longer. Further, after successful repair of the problem the access-provider can easily clear the flap-damping for his customer on his local router instead of needing to contact upstream NOCs all over the Internet to get the damping cleared. Vendor Defaults: As with most software implementations, there need to be some default values set when route-flap damping is enabled on routers. Vendors choosing different default values will result in a similar situation to that described above, where the more aggressive values will result in "black spots" in the Internet. Coordinated values will ensure consistency in dealing with instabilities. 1.5 Aggregation versus damping If a customer of an ISP is only using Provider Aggregated addresses, the aggregating upstream provider doesn't need to apply damping on these prefixes towards his customer, because instabilities of such prefixes will not propagate into the Internet. However, if a customer insists on announcing prefixes which can't be aggregated by its provider, damping should be applied. Reasons for leaking prefixes might include dual-homing (to different providers) of a customer, or customer's reluctance to renumber into the provider's aggregated address range. 1.6 "Golden Networks" Even though damping is strongly recommended, in some cases it may make sense to exclude certain networks or even individual hosts from damping. This is especially true if damping would cut off the access to vital infrastructure elements of the Internet. A most prominent example are the root name servers. At least in principle, there should be enough redundancy for root name servers. However we are still facing a situation where, at least outside USA, large parts of the Internet are seeing all of them through the same one or two backbone/upstream links (sea cable) and any instability of those links which is triggering damping would unnecessarily prolong the inaccessibility of the root name servers for an hour (at least those sitting in a /24 or longer prefix). Other examples of inclusions in the "Golden Networks" might be the Global Top Level Domain (gTLD) name servers, and possibly overseas or "special" networks the local ISP wishes to have continued connectivity to regardless of the instability of the infrastructure inbetween. Appendix 1 gives an example of the Golden Networks at the time of publication of this document. Before implementation of route flap damping using these Golden Networks, network managers are strongly encouraged to check that the networks listed are indeed still being announced, and are home to the servers mentioned. This can be done by matching BGP table announcements with the published addresses for the listed servers. These exceptions must only be made if there are strong and identifiable needs for them - the rule should be to apply coordinated route flap damping throughout. 2. Recommended damping parameters 2.1 Motivation for recommendation At RIPE26 and 27 Christian Panigl presented the following network backbone maintenance example from his own experience, which was triggering flap damping in some upstream and peering ISPs routers for all his and his customers /24 prefixes for more than 3 hours because of too "aggressive" parameters: scheduled SW upgrade of backbone router failed: - reload after SW upgrade 1 flap - new SW crashed 1 flap - reload with old SW 1 flap ------ 3 flaps within 10 minutes which resulted in the following damping scenario at some boundaries with progressive route-flap damping enabled: Prefix length: /24 /19 /16 suppress time: ~3h 45-60' <30' Therefore, in the Routing-WG session at RIPE27, it was agreed that suppression should not start until the 4th flap in a row and that the maximum suppression should in no case last longer than 1 hour from the last flap. It was agreed that a recommendation from RIPE would be desirable. Given that the current allocation policies are expected to hold for the foreseeable future, it was suggested that all /19's or shorter prefixes are not penalised harder (longer) than current Cisco default damping does. More recently, this recommendation has been altered so that only prefixes longer than a /21 are now damped more aggresively. The registries' minimum allocation is currently a /20, and a /21 announcement is quite feasible for a multihoming situation. With these suggestions in mind, Tony Barber designed the following set of route-flap damping parameters which have proved to work smoothly in his environment for a couple of months prior to the publication of RIPE-178 (the original version of this document). 2.2 Description of recommended damping parameters Basically the recommended values do the following with harsher treatment for /24 and longer prefixes: * don't start damping until the 4th flap * /24 and longer prefixes: max=min outage 60 minutes * /22 and /23 prefixes: max outage 45 minutes; min outage of 30 minutes * all other prefix lengths: max outage 30 minutes; min outage 10 minutes If a specific damping implementation does not allow configuration of prefix-dependent parameters the least aggressive set should be used: * don't start damping before the 4th flap in a row * max outage 30 minutes; min outage 10 minutes A sample configuration for Cisco IOS is provided in Appendix 2. This sample can be used as a basis for a configuration on other router platforms. 3. Other Features contributing to Internet Stability 3.1 BGP Route refresh RFC2918 describes a Route Refresh Capability for BGP-4. Prior to this, there was no mechanism to reset or refresh a BGP peering session without tearing it down and waiting for it to re-establish. This process is destructive - prefixes being exchanged between the two peering routers are withdrawn from their respective ASes, and this withdrawal can potentially pass through the whole Internet causing the burden and increased instability discussed earlier. Usually all that an ISP wishes when reseting a BGP session is to implement new or revised policy - destroying a BGP session carrying a large or the full routing table has severe impact on the ISP and his neighbours on the Internet. Furthermore, reset of a BGP session means the withdrawal of reachability information from the ISP's customers, and they have the perception that the Internet has "vanished" - the impression left with the end-user is that of an unreliable network. Route Refresh implements a messaging system whereby a router wishing to refresh or reset its BGP peering with its neighbour simply has to send the notification. When the neighbour receives the notification, it will send its entire announcement to its peer (obtained from BGP best path table and applicable outbound policy). To find out if your neighbour supports Route Refresh, using Cisco IOS as an example, enter: Router# sho ip bgp neigh w.x.y.c | include refresh Received route refresh capability(new) from peer Route refresh request: received 0, sent 0 If your router and your peer router support Route Refresh, you can use: Router# clear ip bgp w.x.y.c in for requesting a route refresh without clearing the BGP session. For an outbound route refresh without clearing the BGP session use Router# clear ip bgp w.x.y.c out It is recommended that all users of BGP use the route refresh capability when implementing new BGP policy. 3.2 Soft-Reconfiguration (Cisco IOS) Where the neighbour does not support RFC 2918 Route Refresh, there is a functionality in Cisco IOS called "Soft Reconfiguration". This reserves additional memory in the router to store the BGP table exactly as it was received from the peer, prior to any inbound policy being applied. The advantage of this is that the ISP can then change any inbound policy on the router without reseting the BGP session - the router simply uses the "raw" BGP table it has received from its peer. Disadvantage is that this functionality could potentially consume almost twice the amount of memory required for the BGP table heard from the peer. To configure soft-reconfiguration in IOS, simply add the extra line to the BGP peer configuration as below. Soft-reconfiguration is configured on a per-neighbour basis. ! router bgp 65501 neighbor 10.0.0.2 remote-as 65502 neighbor 10.0.0.2 soft-reconfiguration inbound ! Without the keyword "soft" a "clear ip bgp x.x.x.x" will completely reset the BGP session and therefore always withdraw all announced prefixes from/to neighbour x.x.x.x and re-advertise them (= route-flap for all prefixes which are available before and after the clear). With "clear ip bgp x.x.x.x soft out" the router doesn't reset the BGP session itself but sends an update for all its advertised prefixes. With "clear ip bgp x.x.x.x soft in" the router just compares the already received routes (stored in the "received" data structures) from the neighbour against locally configured inbound policy statements. It is recommended to use soft-reconfiguration with all peers which do not support RFC2918 Route Refresh Capability. 3.3 Fast-External-Fallover (Cisco IOS) Cisco IOS by default implements a feature known as "fast-external-fallover". This feature immediately clears the BGP session whenever the line-protocol to the external neighbour goes down. This feature is desirable so that there is fast failover in case of link failures - the router can withdraw paths as soon as the line goes down, rather than waiting for BGP keepalive timers. The drawback of this, however, is that circuits which are prone to unreliability will cause BGP sessions to drop and return (i.e. flap), resulting in instability within the ISP's network, and the potential for flap damping by upstreams or peers. If fast-external-fallover is turned off, the BGP sessions will survive these short line-flaps as it will use the longer BGP keepalive/hold timers (default 60/180 seconds). The drawback of turning it off - and currently it has to be done for a whole router and can not be selected peer-by-peer - is that the switch-over to an alternative path will take longer. We recommend turning off fast-external-fallover whenever possible: ! router bgp 65501 no bgp fast-external-fallover ! Alternatively it might be considered acceptable to retain "fast-external-fallover" and to turn off "interface keepalives" on unreliable circuits to overcome the immediate BGP resets on any significant CRC error period. Another potentially more satisfactory alternative would be to use a shorter per-neighbour BGP keepalive timer which has to be applied on both routers (e.g. 10 seconds which gives a hold-timer of 30 seconds): ! router bgp 65501 neighbor w.x.y.z timers 10 ! 4. Potential problems 4.1 Multiplication of flaps between ASes with multiple interconnections Christian Panigl experienced the following during a circuit upgrade of an Ebone customer: - Only ONE flap was generated as a result of the upgrade process (disconnect router-port from modem A, reconnect to modem B). Nevertheless the customer's prefix was damped in all ICM routers. - The flap statistics in the ICM routers stated *4* flaps !!! - The only explanation would be that the multiple interconnections between Ebone/AS1755 and ICM/AS1800 did multiply the flaps (advertisements/withdrawals arrived time-shifted at ICM routers through the multiple circuits). - This would then potentially hold true for any meshed topology because of the propagation delays of advertisements/withdrawals. There are two potential solutions to workaround this problem. The first one is operational, the second one is a software configuration feature (for Cisco IOS and possibly other implementations as well). * Schedule a downtime for at least 3-5 minutes which should be enough time for the prefix withdrawals to have propagated through all paths before reconnection and re-advertisement of the prefix. Avoid clearing BGP sessions as this also could generate a 30 minute outage through flap damping! * Configure a permanent static route pointing to the customer interface. Even if the interface goes down, there is still an entry in the routing table for the customer network, and BGP will therefore still announce the prefix. Example: ! router bgp 65500 network 169.254.0.0 mask 255.255.0.0 ip route 169.254.0.0 255.255.0.0 serial 5/0 permanent ! If migrating the customer from one router port to another, simply enter the second static route pointing to the new interface. Move the cable between ports - BGP continues to announce the prefix as the entry is still in the routing table. Note: this solution only applies to customers who connect using static routes. If the customer connects using BGP, first disable fast-external-fallover on both the customer and ISP router, and then move the cable in a time period less than the BGP hold-timer. 4.2 Non-recommended flap damping parameters There are situations where service providers would like to design their own route flap damping parameters for local needs or conditions. If this is really desired, then it is important to pay attention to how flap damping parameters are configured, whether the values are feasible or not, etc. For example, in Cisco IOS, it is perfectly possible to configure flap damping parameters which do nothing. * One example might be the configuration "set dampening 15 500 3000 30". Here the reuse limit is 500, maximum suppress time is 30 minutes and the half life is 15 minutes. Using these three parameters gives a maximum possible penalty value of 2000, well below the suppress limit of 3000. So even though this can be successfully configured on the router, no damping will take place. * Another example might be the configuration "set dampening 15 750 3000 30". Here the reuse limit is 750, maximum suppress time is 30 minutes and the half life is 15 minutes. Using these three parameters gives a maximum possible penalty of 3000, exactly the same as the suppress-limit. In Cisco IOS, the penalty is decayed every 5 seconds, so flap damping will only be take place if the update follows the withdraw within that 5 second time frame. 99% of the time no flap damping will take place. 5. References RIPE/Routing-WG Minutes dealing with Route Flap Damping: http://www.ripe.net/ripe/meetings/archive/ripe-24/ripe-m-24.txt http://www.ripe.net/ripe/meetings/archive/ripe-25/ripe-m-25.txt http://www.ripe.net/wg/routing/r25-routing.html http://www.ripe.net/wg/routing/r26-routing.html http://www.ripe.net/wg/routing/r27-routing.html Curtis Villamizar, Ravi Chandra, Ramesh Govindan RFC2439: BGP Route Flap Damping (Proposed Standard) ftp://ftp.ietf.org/rfc/rfc2439.txt Enke Chen RFC2918: Route Refresh Capability for BGP-4 (Proposed Standard) ftp://ftp.ietf.org/rfc/rfc2918.txt Merit/IPMA: Internet Routing Recommendations http://www.merit.edu/ipma/docs/help.html Cisco BGP Case Studies: Route Flap Damping http://www.cisco.com/warp/public/459/16.html Cisco Documentation: Configuring BGP / Route Dampening http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/ 121cgcr/ip_c/ipcprt2/1cdbgp.htm Cisco Documentation: BGP Soft Reset Enhancement http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/ 120newft/120t/120t7/sftrst.htm ISI/RSd Configuration: Route Flap Damping http://www.isi.edu/div7/ra/RSd/doc/dampen.html GateD Configuration: Weighted Route Damping Statement http://www.gated.org/gated-web/code/doc/manuals/config_guide/bgp/ weighted_route_dampening.html 6. Acknowledgements Thanks to all the contributors to this updated version. 7. Changes over previous versions This document is a significant rewrite and update of RIPE-210. The "Golden Networks" have now been moved to an Appendix as they are frequently changing and the authors have come across several instances of providers implementing the recommendations without actually checking that the Root Nameserver networks were still as listed in the document. Updates to the Cisco IOS configuration have been made, and the parameters chosen for /24 networks have been corrected to make them feasible. Examples of flap damping in operation have been added to Appendix 3. The sample configuration has been moved to Appendix 2 - again IOS is used as a known working example. Appendices A.1 "Golden Networks" This appendix lists some examples of Golden Networks which could be used when applying route flap damping at the edge of an ISP's network. The example uses Cisco IOS configuration syntax. The list was correct at time of writing (April 2001). ip prefix-list golden-networks description Golden Networks ! Root Nameservers ip prefix-list golden-networks permit 198.41.0.0/24 ! A & J ip prefix-list golden-networks permit 128.9.0.0/16 ! B ip prefix-list golden-networks permit 192.33.4.0/24 ! C ip prefix-list golden-networks permit 128.8.0.0/16 ! D ip prefix-list golden-networks permit 192.203.230.0/24 ! E ip prefix-list golden-networks permit 192.5.4.0/23 ! F ip prefix-list golden-networks permit 192.112.36.0/24 ! G ip prefix-list golden-networks permit 128.63.0.0/16 ! H ip prefix-list golden-networks permit 192.36.148.0/24 ! I ip prefix-list golden-networks permit 193.0.14.0/24 ! K ip prefix-list golden-networks permit 198.32.64.0/24 ! L ip prefix-list golden-networks permit 202.12.27.0/24 ! M ! Global Top Level Domain Servers ip prefix-list golden-networks permit 192.5.6.0/24 ! A ip prefix-list golden-networks permit 203.181.96.0/19 ! B ip prefix-list golden-networks permit 192.26.92.0/24 ! C ip prefix-list golden-networks permit 192.31.80.0/24 ! D ip prefix-list golden-networks permit 192.12.94.0/24 ! E ip prefix-list golden-networks permit 192.35.51.0/24 ! F ip prefix-list golden-networks permit 192.42.93.0/24 ! G ! ip prefix-list golden-networks permit ???? ! No H ip prefix-list golden-networks permit 192.36.144.0/24 ! I ip prefix-list golden-networks permit 210.132.96.0/19 ! J ip prefix-list golden-networks permit 213.177.192.0/21 ! K ip prefix-list golden-networks permit 192.41.162.0/24 ! L ip prefix-list golden-networks permit 202.153.112.0/20 ! M A.2 Sample Cisco IOS Configuration ! Parameters are : ! set damp ! There is a 1000 penalty for each flap ! There is a 500 penalty for change in attribute ! Penalty decays at granularity of 5 seconds, decay starts as soon as ! prefix is withdrawn ! Unsuppressed at granularity of 10 seconds ! damping info kept until penalty becomes < half of reuse limit. ! ! Cisco/IOS value-ranges: ! ! (range is 1-45 minutes). ! (range is 1-20000). ! (range is 1-20000). ! (range is 1-255 minutes ). ! !----------------------------------------------------------------------- ! ENABLE BGP DAMPenING using "graded" route-map !----------------------------------------------------------------------- router bgp 65500 NO bgp damp bgp damp route-map graded-flap-damping ! !----------------------------------------------------------------------- ! DEFINE "graded" route-map !----------------------------------------------------------------------- NO route-map graded-flap-damping ! ! don't damp Candidate Default Routes ! OPTIONAL (not part of recommendation) ! prefix-list default-networks lists the Candidate Default Routes ! !route-map graded-flap-damping deny 5 ! match ip address prefix-list default-networks ! ! don't damp Golden Networks ! route-map graded-flap-damping deny 10 match ip address prefix-list golden-networks ! ! - /24 and longer prefixes: max=min outage 60 minutes ! route-map graded-flap-damping permit 20 match ip address prefix-list min24 set damp 30 820 3000 60 ! ! - /22 and /23 prefixes: max outage 45 minutes but potential for ! less because of shorter half life value - minimum of 30 minutes ! outage route-map graded-flap-damping permit 30 match ip address prefix-list max22-23 set damp 15 750 3000 45 ! ! - all else prefixes: max outage 30 minutes min outage 10 minutes ! route-map graded-flap-damping permit 40 set damp 10 1500 3000 30 ! !----------------------------------------------------------------------- ! DEFINE PREFIX-LISTS !----------------------------------------------------------------------- ! ! OPTIONAL default-networks !no ip prefix-list default-networks !ip prefix-list default-networks description Candidate Default Routes ! no ip prefix-list golden-networks ip prefix-list golden-networks description Golden Networks ! See 7.1 above for sample list ! no ip prefix-list min24 ip prefix-list min24 description Apply to /24 and longer prefixes ip prefix-list min24 permit 0.0.0.0/0 ge 24 ! no ip prefix-list max22-23 ip prefix-list max22-23 description Apply to /22 and /23 prefixes ip prefix-list max22-23 permit 0.0.0.0/0 ge 22 le 23 ! A.3 Study of Flap Damping Operation It is instructive to observe how route flap damping actually works on a router - doing so will help the reader understand how the particular values described above were chosen. The test bed had two Cisco routers connected to each other. One router originated prefixes, the other one had the flap damping parameters described above in the text. The router originating the prefixes would withdraw a prefix, then reannounce, then withdraw, reannounce, etc. The BGP process in IOS checks every 60 seconds for any new or withdrawn prefixes in the local configuration - so on the source router, the withdraw and announce was done by removing and adding the BGP network statement for the prefix in question. The router monitoring the flaps would see the prefix being withdrawn and then announced 60s later. A.3.1 For /24s Parameters used are "set dampening 15 820 3000 30" 1st flap 1000 decay to 966, 982 at update 2nd flap 1966 decay to 1894, 1926 at update 3rd flap 2894 decay to 2787, 2846 at update 4th flap 3280 decay to 3165, 3226 at update Maximum possible penalty is 3280 as defined by the flap parameters, so the penalty at the 4th flap was only incremented from 2787 to 3280, not 3787 as might have been expected. At the 4th flap the prefix was marked as being suppressed for 59 minutes when the update message was received. If the update after the 4th flap was not received within 4 minutes and 20 seconds, the penalty dropped below 3000, and the prefix was not suppressed. A.3.2 For /22s, /23s Parameters used are "set dampening 15 750 3000 45" 1st flap 1000 decay to 921, 960 at update 2nd flap 1921 decay to 1777, 1850 at update 3rd flap 2777 decay to 2583, 2671 at update 4th flap 3583 decay to 3311, 3451 at update Maximum possible penalty is 6000. At the 4th flap the prefix was marked as being suppressed for 33 minutes when the update message was received. If the update after the 4th flap was not received within 4 minutes and 40 seconds, the penalty dropped below 3000, and the prefix was not suppressed. A.3.3 For remaining prefixes Parameters used are "set dampening 10 1500 3000 30" 1st flap 1000 decay to 889, 946 at update 2nd flap 1889 decay to 1679, 1781 at update 3rd flap 2679 decay to 2367, 2526 at update 4th flap 3367 decay to 3019, 3176 at update Maximum possible penalty is 12000. At the 4th flap the prefix was marked as being suppressed for 10 minutes when the update message was received. If the update after the 4th flap was not received within 2 minutes and 5 seconds, the penalty dropped below 3000, and the prefix was not suppressed. A.3.4 Summary When analysing flap damping performance on the router or across the network, network managers should compare with the above lab tests. Note especially that slowly flapping prefixes are unlikely to be suppressed even though they show significant flapping history. A future version of this document may consider what to do in this instance. >>>>end * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Fri Apr 27 04:11:03 2001 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id EAA67104; Fri, 27 Apr 2001 04:11:03 +1000 (EST) Received: from dev.apnic.net (dev.apnic.net [202.12.29.129]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id EAA67084 for ; Fri, 27 Apr 2001 04:11:02 +1000 (EST) Received: (from cscora@localhost) by dev.apnic.net (8.9.3/8.9.3) id EAA01816; Fri, 27 Apr 2001 04:11:00 +1000 From: Routing Analysis Message-Id: <200104261811.EAA01816@dev.apnic.net> Subject: [apops] Weekly Routing Table Report Date: Fri, 27 Apr 2001 04:11:00 +1000 (EST) Reply-To: pfs@cisco.com To: apops@lists.apnic.net, rtma@arin.net, routing-wg@ripe.net X-Mailer: fastmail [version 2.5 PL1] Sender: owner-apops@lists.apnic.net Precedence: bulk This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats@lists.apnic.net For a graphical representation, please see http://www.apnic.net/stats/bgp. If you have any comments please contact Philip Smith . Routing Table Report 27 Apr, 2001 Analysis Summary ---------------- BGP routing table entries examined: 104638 Origin ASes present in the Internet Routing Table: 10673 Origin ASes announcing only one prefix: 3885 Transit ASes present in the Internet Routing Table: 1436 Average AS path length visible in the Internet Routing Table: 5.3 Max AS path length visible: 21 Illegal AS announcements present in the Routing Table: 19 Non-routable prefixes present in the Routing Table: 0 Prefixes being announced from the IANA Reserved Address blocks: 1 Number of addresses announced to Internet: 1223206251 Equivalent to 72 /8s, 232 /16s and 165 /24s Percentage of available address space announced: 33.0 Percentage of allocated address space announced: 63.6 Percentage of available address space allocated: 51.9 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 15702 Prefixes being announced from the APNIC address blocks: 14207 APNIC Region origin ASes present in the Internet Routing Table: 1233 APNIC Region origin ASes announcing only one prefix: 441 APNIC Region transit ASes present in the Internet Routing Table: 199 Average APNIC Region AS path length visible: 5.1 Max APNIC Region AS path length visible: 21 Number of APNIC addresses announced to Internet: 71044162 Equivalent to 4 /8s, 60 /16s and 12 /24s Percentage of available APNIC address space announced: 69.8 APNIC AS Blocks 4608 - 4864, 7467 - 7722, 9216 - 10239, 17408 - 18431 APNIC Address Blocks 61/8, 202/7, 210/7 and 218/8 ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 72658 Prefixes being announced from the ARIN address blocks: 49910 ARIN Region origin ASes present in the Internet Routing Table: 6488 ARIN Region origin ASes announcing only one prefix: 1937 ARIN Region transit ASes present in the Internet Routing Table: 688 Average ARIN Region AS path length visible: 5.2 Max ARIN Region AS path length visible: 14 Number of ARIN addresses announced to Internet: 181209106 Equivalent to 10 /8s, 205 /16s and 8 /24s Percentage of available ARIN address space announced: 83.1 ARIN AS Blocks 1 - 1876, 1902 - 2042, 2044 - 2046, 2048 - 2106 2138 - 2584, 2615 - 2772, 2823 - 2829, 2880 - 3153 3354 - 4607, 4865 - 5119, 5632 - 6655, 6912 - 7466 7723 - 8191, 10240 - 12287, 13312 - 15359 16384 - 17407, 18432 - 20479 ARIN Address Blocks 63/8, 64/7, 66/8, 199/8, 200/8, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 16259 Prefixes being announced from the RIPE address blocks: 12958 RIPE Region origin ASes present in the Internet Routing Table: 2951 RIPE Region origin ASes announcing only one prefix: 1505 RIPE Region transit ASes present in the Internet Routing Table: 549 Average RIPE Region AS path length visible: 5.9 Max RIPE Region AS path length visible: 15 Number of RIPE addresses announced to Internet: 96959193 Equivalent to 5 /8s, 199 /16s and 122 /24s Percentage of available RIPE address space announced: 64.2 RIPE AS Blocks 1877 - 1901, 2042, 2047, 2107 - 2136, 2585 - 2614 2773 - 2822, 2830 - 2879, 3154 - 3353, 5377 - 5631 6656 - 6911, 8192 - 9215, 12288 - 13311, 15360 - 16383 20480 - 21503 RIPE Address Blocks 62/8, 80/7, 193/8, 194/7, 212/7 and 217/8 APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /19 equiv Description 1221 2010 692 Telstra 2764 428 139 connect.com.au pty ltd 703 390 205 UUNET Technologies, Inc. 2907 363 875 SINET Japan 4755 317 111 VSNL India 7539 219 101 Delegated to TWNIC for subseq 4134 194 631 Data Communications Bureau 4766 186 766 KORnet Powered BY Korea Telec 7474 184 85 Optus Communications 4538 183 989 China Education and Research 7657 173 13 The Internet Group Limited 9269 161 22 Hong Kong CTI 1237 156 70 System Engineering Research I 4740 153 10 Ozemail 17561 151 61 Internet service provision to 7545 146 10 TPG Internet Pty Ltd 4786 128 7 NetConnect Communications Pty 7586 125 10 Paradox Digital Pty. Ltd 7617 124 46 One.Net Pty Ltd 9443 122 22 INTERNETPRIMUS-AS-A RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /19 equiv Description 702 538 649 UUNET Technologies, Inc. 3301 389 337 TeliaNet Sweden 1257 278 263 Swipnet AB 1270 276 448 UUNET Germany 680 211 938 Deutschef Forschurgsnetz 3215 211 228 RAIN 5515 191 336 Sonera Finland 719 189 146 LANLINK 786 180 935 JANET IP Service 3320 161 710 Deutsche Telekom AG 5400 128 40 Concert Internet Plus Europea 517 127 134 Xlink 3303 124 298 Swisscom 2856 122 388 BTnet UK Regional network 8708 118 5 Romania Data System 1290 116 206 PSINet UK Ltd. 1849 105 223 UUNET UK (formerly PIPEX) 1267 101 978 IUnet S.p.A 1901 97 77 EUnet Austria 3269 85 277 TELECOM ITALIA ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /19 equiv Description 701 2367 3732 UUNET Technologies, Inc. 705 1752 73 UUNET Technologies, Inc. 7018 963 3159 AT&T 1 962 4472 BBN Planet 7046 773 553 UUNET Technologies, Inc. 1239 631 1581 Sprint ICM-Inria 2914 604 1202 Verio, Inc. 3561 562 1249 Cable & Wireless USA 18994 525 6 Crossing 3549 499 515 Global Crossing 174 475 2755 PSINet Inc. 4293 475 51 Cable & Wireless USA 209 450 715 Qwest 690 445 44 Merit Network 2548 402 514 Digital Express Group, Inc. 3908 375 262 Supernet, Inc. 8151 365 226 UniNet S.A. de C.V. 3602 345 72 Sprint Canada 3967 337 226 Exodus Communication 4323 337 136 Time Warner Communications, I Global Per AS prefix count summary ---------------------------------- ASN No of nets /19 equiv Description 701 2367 3732 UUNET Technologies, Inc. 1221 2010 692 Telstra 705 1752 73 UUNET Technologies, Inc. 7018 963 3159 AT&T 1 962 4472 BBN Planet 7046 773 553 UUNET Technologies, Inc. 1239 631 1581 Sprint ICM-Inria 2914 604 1202 Verio, Inc. 3561 562 1249 Cable & Wireless USA 702 538 649 UUNET Technologies, Inc. 18994 525 6 Crossing 3549 499 515 Global Crossing 174 475 2755 PSINet Inc. 4293 475 51 Cable & Wireless USA 209 450 715 Qwest 690 445 44 Merit Network 2764 428 139 connect.com.au pty ltd 2548 402 514 Digital Express Group, Inc. 703 390 205 UUNET Technologies, Inc. 3301 389 337 TeliaNet Sweden List of Unregistered ASNs (Global) ---------------------------------- Bad AS Designation Network Transit AS Description 60002 RESERVED 64.76.148.0/24 19583 CHILE S.A. 2027 UNALLOCATED 150.185.128.0/18 8143 Publicom Corp. 64842 PRIVATE 164.159.151.0/24 19143 Fish and Wildlife Se 64842 PRIVATE 164.159.152.0/22 19143 Fish and Wildlife Se 64842 PRIVATE 164.159.159.0/24 19143 Fish and Wildlife Se 64842 PRIVATE 164.159.160.0/24 19143 Fish and Wildlife Se 1877 UNALLOCATED 192.108.196.0/24 1800 SPRINT 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 1800 SPRINT 5757 UNALLOCATED 192.239.13.0/24 701 UUNET Technologies, 60002 RESERVED 200.9.98.0/24 6429 RdC Internet 60002 RESERVED 200.9.99.0/24 6429 RdC Internet 65535 PRIVATE 203.24.169.0/24 17486 Swiftel Communicatio 65500 PRIVATE 203.166.86.0/24 10084 Western Australian I 5555 UNALLOCATED 205.110.64.0/24 721 DLA Systems Automati 5555 UNALLOCATED 205.110.68.0/22 721 DLA Systems Automati 5555 UNALLOCATED 205.110.72.0/21 721 DLA Systems Automati 5757 UNALLOCATED 207.19.224.0/24 701 UUNET Technologies, Advertised IANA Reserved Addresses ---------------------------------- Network Origin AS Description 201.115.100.0/24 7018 AT&T 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:4 /11:10 /12:29 /13:67 /14:204 /15:331 /16:6936 /17:1138 /18:2101 /19:6595 /20:5104 /21:4438 /22:6747 /23:8662 /24:60408 /25:288 /26:463 /27:294 /28:296 /29:227 /30:193 /31:1 /32:77 Number of /24s announced per /8 block (Global) ---------------------------------------------- 9:3 12:353 13:10 15:1 17:2 24:682 26:1 32:23 38:7 44:3 47:1 53:2 55:1 57:11 61:28 62:133 63:1939 64:1473 65:1069 66:310 128:35 129:114 130:22 131:26 132:9 133:1 134:166 135:9 136:16 137:119 138:250 139:62 140:143 141:163 142:60 143:41 144:132 145:9 146:133 147:134 148:142 149:123 150:28 151:301 152:792 153:33 154:17 155:81 156:40 157:108 158:173 159:84 160:28 161:58 162:61 163:135 164:87 165:124 166:176 167:133 168:85 169:33 170:256 171:2 192:5381 193:1974 194:2079 195:810 196:407 198:3667 199:3403 200:1974 201:1 202:2484 203:5033 204:3379 205:2243 206:2705 207:2914 208:2930 209:3178 210:504 211:150 212:838 213:382 214:9 215:11 216:2944 217:212 End of report * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * From owner-apops@lists.apnic.net Sat Apr 28 16:59:27 2001 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id QAA115762; Sat, 28 Apr 2001 16:59:26 +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 QAA115757 for ; Sat, 28 Apr 2001 16:59:25 +1000 (EST) Received: (from mail@localhost) by guardian.apnic.net (8.9.3/8.9.3) id QAA26530 for ; Sat, 28 Apr 2001 16:08:25 +1000 (EST) Received: from lovefm.cisco.com(171.71.12.63) by int-gw.staff.apnic.net via smap (V2.1) id xma026526; Sat, 28 Apr 01 16:08:03 +1000 Received: from cisco.com (localhost.cisco.com [127.0.0.1]) by lovefm.cisco.com (8.6.12/8.6.5) with ESMTP id XAA21668; Fri, 27 Apr 2001 23:00:03 -0700 Message-Id: <200104280600.XAA21668@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, 27 Apr 2001 23:00:02 -0700 From: Tony Bates Sender: owner-apops@lists.apnic.net Precedence: bulk This is an auto-generated mail on Fri Apr 27 23:00:00 PDT 2001 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 27Apr01 0) General Status Table History ------------- Date Prefixes 200401 100216 210401 100108 220401 100099 230401 100219 240401 100457 250401 100635 260401 100755 270401 100797 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 218.6.128.0/17 from AS4134 AS Summary ---------- Number of ASes in routing system: 10591 Number of ASes announcing only one prefix: 6292 (3570 cidr, 2722 classful) Largest number of cidr routes: 1365 announced by AS705 Largest number of classful routes: 1602 announced by AS1221 1) Gains by aggregating at the origin AS level --- 27Apr01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1602 1190 412 25.7% TELSTRA-AS AS701 1409 1222 187 13.3% Alternet AS705 393 258 135 34.4% part of AS assignment AS701 - AS7 AS4151 257 145 112 43.6% part of AS assignment AS4151 - AS AS6429 216 105 111 51.4% ATT LA Internet Chile AS6595 163 62 101 62.0% autonomous system number assigned AS13999 104 8 96 92.3% autonomous system number assigned AS4293 372 279 93 25.0% part of AS assignment AS4287 - AS AS8013 326 239 87 26.7% autonomous system number assigned AS7018 698 613 85 12.2% AT&T WorldNet Service Backbone AS4755 229 144 85 37.1% part of AS assignment AS4608 - AS AS15412 260 183 77 29.6% FLAG Telecom Global Internet AS AS577 238 169 69 29.0% autonomous system number assigned AS6471 113 49 64 56.6% autonomous system number assigned AS5106 101 37 64 63.4% autonomous system number assigned AS3464 153 91 62 40.5% Alabama Research and Education Ne AS3749 120 59 61 50.8% autonomous system number assigned AS724 202 144 58 28.7% part of AS assignment AS721 - AS7 AS3602 253 195 58 22.9% Sprint Canada Inc. AS11252 92 34 58 63.0% autonomous system number assigned AS16758 63 6 57 90.5% autonomous system number assigned AS1 608 551 57 9.4% GTE Internetworking AS6413 67 11 56 83.6% autonomous system number assigned AS226 149 93 56 37.6% Los Nettos AS4323 232 179 53 22.8% Time Warner Telecom Internet AS852 203 155 48 23.6% autonomous system number assigned AS9269 109 62 47 43.1% Hong Kong CTI AS855 145 99 46 31.7% part of AS assignment AS853 - AS1 AS13544 68 22 46 67.6% autonomous system number assigned AS12235 49 3 46 93.9% Cove Software Systems Inc 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 *