This report has been generated at Fri Apr 25 21:13:54 2014 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 18-04-14 499254 282312 19-04-14 499492 282427 20-04-14 499557 282428 21-04-14 499371 282193 22-04-14 499156 282325 23-04-14 499260 282597 24-04-14 499642 282663 25-04-14 500177 282878 AS Summary 46910 Number of ASes in routing system 19117 Number of ASes announcing only one prefix 3731 Largest number of prefixes announced by an AS AS28573: NET Serviços de Comunicação S.A.,BR 119976960 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 25Apr14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 500075 282843 217232 43.4% All ASes AS28573 3731 380 3351 89.8% NET Serviços de Comunicação S.A.,BR AS6389 2983 58 2925 98.1% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2799 251 2548 91.0% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS4766 2953 931 2022 68.5% KIXS-AS-KR Korea Telecom,KR AS18881 1932 37 1895 98.1% Global Village Telecom,BR AS1785 2196 490 1706 77.7% AS-PAETEC-NET - PaeTec Communications, Inc.,US AS10620 2844 1349 1495 52.6% Telmex Colombia S.A.,CO AS18566 2047 565 1482 72.4% MEGAPATH5-US - MegaPath Corporation,US AS36998 1634 161 1473 90.1% SDN-MOBITEL,SD AS22773 3057 1587 1470 48.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS4323 2937 1516 1421 48.4% TWTC - tw telecom holdings, inc.,US AS7303 1757 457 1300 74.0% Telecom Argentina S.A.,AR AS4755 1850 583 1267 68.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS7545 2228 1072 1156 51.9% TPG-INTERNET-AP TPG Telecom Limited,AU AS7552 1220 107 1113 91.2% VIETEL-AS-AP Viettel Corporation,VN AS22561 1301 241 1060 81.5% AS22561 - CenturyTel Internet Holdings, Inc.,US AS6983 1326 314 1012 76.3% ITCDELTA - Earthlink, Inc.,US AS9829 1622 708 914 56.4% BSNL-NIB National Internet Backbone,IN AS24560 1126 295 831 73.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS4808 1209 391 818 67.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN AS18101 945 187 758 80.2% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN AS8151 1407 656 751 53.4% Uninet S.A. de C.V.,MX AS4788 1030 281 749 72.7% TMNET-AS-AP TM Net, Internet Service Provider,MY AS701 1482 751 731 49.3% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US AS7738 914 184 730 79.9% Telemar Norte Leste S.A.,BR AS26615 843 113 730 86.6% Tim Celular S.A.,BR AS855 756 57 699 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc.,CA AS4780 1037 370 667 64.3% SEEDNET Digital United Inc.,TW AS6147 780 113 667 85.5% Telefonica del Peru S.A.A.,PE AS9808 996 330 666 66.9% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN Total 52942 14535 38407 72.5% Top 30 total Possible Bogus Routes 27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US 41.78.236.0/24 AS37290 -Reserved AS-,ZZ 41.78.237.0/24 AS37290 -Reserved AS-,ZZ 41.78.238.0/24 AS37290 -Reserved AS-,ZZ 41.78.239.0/24 AS37290 -Reserved AS-,ZZ 41.190.72.0/24 AS37451 CongoTelecom,CG 41.190.73.0/24 AS37451 CongoTelecom,CG 41.190.74.0/24 AS37451 CongoTelecom,CG 41.190.75.0/24 AS37451 CongoTelecom,CG 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos,US 63.247.0.0/24 AS27609 -Reserved AS-,ZZ 63.247.1.0/24 AS27609 -Reserved AS-,ZZ 63.247.2.0/24 AS27609 -Reserved AS-,ZZ 63.247.3.0/24 AS27609 -Reserved AS-,ZZ 63.247.4.0/24 AS27609 -Reserved AS-,ZZ 63.247.5.0/24 AS27609 -Reserved AS-,ZZ 63.247.6.0/24 AS27609 -Reserved AS-,ZZ 63.247.7.0/24 AS27609 -Reserved AS-,ZZ 63.247.8.0/24 AS27609 -Reserved AS-,ZZ 63.247.9.0/24 AS27609 -Reserved AS-,ZZ 63.247.10.0/24 AS27609 -Reserved AS-,ZZ 63.247.11.0/24 AS27609 -Reserved AS-,ZZ 63.247.13.0/24 AS27609 -Reserved AS-,ZZ 63.247.14.0/24 AS27609 -Reserved AS-,ZZ 63.247.15.0/24 AS27609 -Reserved AS-,ZZ 63.247.16.0/24 AS27609 -Reserved AS-,ZZ 63.247.17.0/24 AS27609 -Reserved AS-,ZZ 63.247.18.0/24 AS27609 -Reserved AS-,ZZ 63.247.19.0/24 AS27609 -Reserved AS-,ZZ 63.247.20.0/24 AS27609 -Reserved AS-,ZZ 63.247.21.0/24 AS27609 -Reserved AS-,ZZ 63.247.22.0/24 AS27609 -Reserved AS-,ZZ 63.247.23.0/24 AS27609 -Reserved AS-,ZZ 63.247.24.0/24 AS27609 -Reserved AS-,ZZ 63.247.25.0/24 AS27609 -Reserved AS-,ZZ 63.247.26.0/24 AS27609 -Reserved AS-,ZZ 63.247.27.0/24 AS27609 -Reserved AS-,ZZ 63.247.28.0/24 AS27609 -Reserved AS-,ZZ 63.247.29.0/24 AS27609 -Reserved AS-,ZZ 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.111.160.0/20 AS40551 -Reserved AS-,ZZ 64.111.160.0/24 AS40551 -Reserved AS-,ZZ 64.111.161.0/24 AS40551 -Reserved AS-,ZZ 64.111.162.0/24 AS40551 -Reserved AS-,ZZ 64.111.167.0/24 AS40551 -Reserved AS-,ZZ 64.111.169.0/24 AS40551 -Reserved AS-,ZZ 64.111.170.0/24 AS40551 -Reserved AS-,ZZ 64.111.171.0/24 AS40551 -Reserved AS-,ZZ 64.111.172.0/24 AS40551 -Reserved AS-,ZZ 64.111.173.0/24 AS40551 -Reserved AS-,ZZ 64.111.174.0/24 AS40551 -Reserved AS-,ZZ 64.111.175.0/24 AS40551 -Reserved AS-,ZZ 64.119.240.0/22 AS26072 -Reserved AS-,ZZ 64.119.240.0/23 AS26072 -Reserved AS-,ZZ 64.119.242.0/23 AS26072 -Reserved AS-,ZZ 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc.,US 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.55.96.0/23 AS17203 -Reserved AS-,ZZ 66.55.98.0/24 AS17203 -Reserved AS-,ZZ 66.55.99.0/24 AS17203 -Reserved AS-,ZZ 66.55.100.0/22 AS17203 -Reserved AS-,ZZ 66.55.102.0/23 AS17203 -Reserved AS-,ZZ 66.55.104.0/21 AS17203 -Reserved AS-,ZZ 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.254.188.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 67.21.144.0/22 AS174 COGENT-174 - Cogent Communications,US 67.21.148.0/22 AS174 COGENT-174 - Cogent Communications,US 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.112.100.0/22 AS16764 -Reserved AS-,ZZ 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.115.124.0/23 AS46540 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.119.236.0/23 AS26368 -Reserved AS-,ZZ 74.119.239.0/24 AS26368 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 77.243.80.0/24 AS42597 -Reserved AS-,ZZ 77.243.81.0/24 AS42597 -Reserved AS-,ZZ 77.243.88.0/24 AS42597 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 77.243.94.0/24 AS42597 -Reserved AS-,ZZ 77.243.95.0/24 AS42597 -Reserved AS-,ZZ 80.250.32.0/22 AS37106 ODUA-AS,NG 85.202.160.0/20 AS44404 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.199.90.0/24 AS44330 -Reserved AS-,ZZ 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD,RU 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal,LT 91.229.182.0/24 AS56960 -Reserved AS-,ZZ 91.229.186.0/24 AS56967 -Reserved AS-,ZZ 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB 91.245.224.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.232.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.240.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.248.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 93.190.10.0/24 AS47254 -Reserved AS-,ZZ 95.215.140.0/22 AS48949 -Reserved AS-,ZZ 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building,MN 103.31.236.0/22 AS17941 BIT-ISLE Bit-isle Co.,Ltd.,JP 103.244.236.0/22 AS58794 103.247.52.0/23 AS4725 ODN SOFTBANK TELECOM Corp.,JP 110.76.128.0/22 AS13308 ENPL-PROD-AS-AP eintellego Networks Pty Ltd,AU 110.232.188.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 124.64.0.0/10 AS4847 CNIX-AP China Networks Inter-Exchange,CN 162.247.180.0/22 AS23175 POGOZONE - PogoZone,US 163.47.23.0/24 AS2907 SINET-AS Research Organization of Information and Systems, National Institute of Informatics,JP 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 176.124.32.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 185.55.100.0/22 AS12843 TELEMAXX TelemaxX Telekommunikation GmbH,DE 185.55.120.0/22 AS21385 TNIB Trusted Network GmbH,DE 185.55.124.0/22 AS8365 MANDA Man-da.de GmbH,DE 185.55.128.0/22 AS12573 WIDEXS WideXS B.V.,NL 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS,CO 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A.,EC 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.75.23.0/24 AS2579 -Reserved AS-,ZZ 192.75.239.0/24 AS23498 CDSI - Cogeco Data Services LP,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.104.61.0/24 AS1785 AS-PAETEC-NET - PaeTec Communications, Inc.,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.241.20.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.241.21.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.84.187.0/24 AS16276 OVH OVH SAS,FR 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB 193.109.217.0/24 AS13069 DATAGUARD DataGuard AS,NO 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.160.16.0/22 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.161.157.0/24 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc.,US 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.243.166.0/24 AS44093 -Reserved AS-,ZZ 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT HighTech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.113.27.0/24 AS12518 SHLINK SHLINK Internet Service,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.165.26.0/24 AS47381 DOCLERWEB-AS DoclerWeb Kft.,HU 194.165.27.0/24 AS47381 DOCLERWEB-AS DoclerWeb Kft.,HU 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 194.213.8.0/24 AS42845 BRETAGNETELECOM BRETAGNE TELECOM SAS,FR 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.39.252.0/23 AS29004 -Reserved AS-,ZZ 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.47.242.0/24 AS9050 RTD ROMTELECOM S.A,RO 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.90.98.0/23 AS57511 OVALTECH-AS OvalTech Internet Ltd,GB 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.114.14.0/23 AS31554 ALTFEL SC Almsoft Computers SRL,RO 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.2.224.0/22 AS24863 LINKdotNET-AS,EG 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.13.201.0/24 AS2018 TENET-1,ZA 196.13.202.0/24 AS2018 TENET-1,ZA 196.13.203.0/24 AS2018 TENET-1,ZA 196.13.204.0/24 AS2018 TENET-1,ZA 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.45.0.0/21 AS26625 -Reserved AS-,ZZ 196.45.10.0/24 AS26625 -Reserved AS-,ZZ 196.216.129.0/24 AS36886 -Reserved AS-,ZZ 196.216.130.0/24 AS36886 -Reserved AS-,ZZ 196.216.131.0/24 AS36886 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.72.78.0/23 AS3967 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.161.239.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.176.208.0/24 AS4318 FMI-NET-AS - Freeport McMoRan Copper & Gold Inc.,US 198.176.209.0/24 AS4318 FMI-NET-AS - Freeport McMoRan Copper & Gold Inc.,US 198.176.210.0/24 AS4318 FMI-NET-AS - Freeport McMoRan Copper & Gold Inc.,US 198.176.211.0/24 AS4318 FMI-NET-AS - Freeport McMoRan Copper & Gold Inc.,US 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services,HK 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.30.138.0/24 AS23319 -Reserved AS-,ZZ 199.30.139.0/24 AS23319 -Reserved AS-,ZZ 199.30.143.0/24 AS8100 IPTELLIGENT - IPTelligent LLC,US 199.68.72.0/24 AS174 COGENT-174 - Cogent Communications,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.87.166.0/24 AS26368 -Reserved AS-,ZZ 199.87.167.0/24 AS26368 -Reserved AS-,ZZ 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.91.240.0/21 AS174 COGENT-174 - Cogent Communications,US 199.102.73.0/24 AS26368 -Reserved AS-,ZZ 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.142.219.0/24 AS45149 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service,MN 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.10.94.0/23 AS30097 NUWAVE - NuWave,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp.,CA 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc.,US 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc.,US 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc.,US 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.74.224.0/22 AS174 COGENT-174 - Cogent Communications,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C.,US 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc.,US 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc.,US 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc.,US 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc.,US 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc.,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 212.119.32.0/19 AS12550 -Reserved AS-,ZZ 213.184.64.0/24 AS13071 -Reserved AS-,ZZ 213.184.65.0/24 AS13071 -Reserved AS-,ZZ 213.184.66.0/24 AS13071 -Reserved AS-,ZZ 213.184.67.0/24 AS13071 -Reserved AS-,ZZ 213.184.68.0/24 AS13071 -Reserved AS-,ZZ 213.184.69.0/24 AS13071 -Reserved AS-,ZZ 213.184.70.0/24 AS13071 -Reserved AS-,ZZ 213.184.71.0/24 AS13071 -Reserved AS-,ZZ 213.184.72.0/24 AS13071 -Reserved AS-,ZZ 213.184.73.0/24 AS13071 -Reserved AS-,ZZ 213.184.74.0/24 AS13071 -Reserved AS-,ZZ 213.184.75.0/24 AS13071 -Reserved AS-,ZZ 213.184.76.0/24 AS13071 -Reserved AS-,ZZ 213.184.77.0/24 AS13071 -Reserved AS-,ZZ 213.184.78.0/24 AS13071 -Reserved AS-,ZZ 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US 216.24.176.0/20 AS19401 -Reserved AS-,ZZ 216.24.188.0/24 AS19401 -Reserved AS-,ZZ 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.203.80.0/20 AS27021 -Reserved AS-,ZZ 216.203.80.0/21 AS27021 -Reserved AS-,ZZ 216.203.87.0/24 AS27021 -Reserved AS-,ZZ 216.203.88.0/21 AS27021 -Reserved AS-,ZZ 216.203.95.0/24 AS53490 MEDPLUS - MedPlus, Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog@nanog.org eof-list@ripe.net apops@apops.net routing-wg@ripe.net afnog@afnog.org
25-04-14 500177 282878
Half a million prefixes. 'Wow .. just wow.' There was a time when even I would have laughed at the thought of 500K. Just a "round number", but a milestone nonetheless. I checked, back in 2004, a little under 10 years ago, I posted this to NANOG: Patrick W Gilmore | 5 Nov 14:39 2004 On Nov 5, 2004, at 6:00 AM, cidr-report <at> potaroo.net wrote: > Recent Table History > Date Prefixes CIDR Agg [...] > 05-11-04 156315 103781 Well, we broke 150K prefixes - and without someone deaggregating the classical B space. :) Impressive. Remember when the 'Net was supposed to have fallen over before now? Pat yourselves on the back everyone, you did the impossible. Congratulations are in order. I think congratulations are still in order, but frankly, I am less impressed with getting to 500 than 150. The equipment today just seems to be better able to handle it (even with the Sup720-pocolypse), which is a good thing given our possible de-aggregate future. Anyway, congratulations everyone. The Internet is such an important part of not just our lives, but literally the whole planet - every industry, every country, every economy, every, uh, everything. And as sappy as it sounds, it has made an immeasurable number of people's lives better. Hopefully people won't take this the wrong way: I am proud of all of you. Keep up the good work. -- TTFN, patrick On Apr 25, 2014, at 18:00 , cidr-report@potaroo.net wrote:
This report has been generated at Fri Apr 25 21:13:54 2014 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/2.0 for a current version of this report.
Recent Table History Date Prefixes CIDR Agg 18-04-14 499254 282312 19-04-14 499492 282427 20-04-14 499557 282428 21-04-14 499371 282193 22-04-14 499156 282325 23-04-14 499260 282597 24-04-14 499642 282663 25-04-14 500177 282878
AS Summary 46910 Number of ASes in routing system 19117 Number of ASes announcing only one prefix 3731 Largest number of prefixes announced by an AS AS28573: NET Serviços de Comunicação S.A.,BR 119976960 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN
Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes').
--- 25Apr14 --- ASnum NetsNow NetsAggr NetGain % Gain Description
Table 500075 282843 217232 43.4% All ASes
AS28573 3731 380 3351 89.8% NET Serviços de Comunicação S.A.,BR AS6389 2983 58 2925 98.1% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2799 251 2548 91.0% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS4766 2953 931 2022 68.5% KIXS-AS-KR Korea Telecom,KR AS18881 1932 37 1895 98.1% Global Village Telecom,BR AS1785 2196 490 1706 77.7% AS-PAETEC-NET - PaeTec Communications, Inc.,US AS10620 2844 1349 1495 52.6% Telmex Colombia S.A.,CO AS18566 2047 565 1482 72.4% MEGAPATH5-US - MegaPath Corporation,US AS36998 1634 161 1473 90.1% SDN-MOBITEL,SD AS22773 3057 1587 1470 48.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS4323 2937 1516 1421 48.4% TWTC - tw telecom holdings, inc.,US AS7303 1757 457 1300 74.0% Telecom Argentina S.A.,AR AS4755 1850 583 1267 68.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS7545 2228 1072 1156 51.9% TPG-INTERNET-AP TPG Telecom Limited,AU AS7552 1220 107 1113 91.2% VIETEL-AS-AP Viettel Corporation,VN AS22561 1301 241 1060 81.5% AS22561 - CenturyTel Internet Holdings, Inc.,US AS6983 1326 314 1012 76.3% ITCDELTA - Earthlink, Inc.,US AS9829 1622 708 914 56.4% BSNL-NIB National Internet Backbone,IN AS24560 1126 295 831 73.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS4808 1209 391 818 67.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN AS18101 945 187 758 80.2% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN AS8151 1407 656 751 53.4% Uninet S.A. de C.V.,MX AS4788 1030 281 749 72.7% TMNET-AS-AP TM Net, Internet Service Provider,MY AS701 1482 751 731 49.3% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US AS7738 914 184 730 79.9% Telemar Norte Leste S.A.,BR AS26615 843 113 730 86.6% Tim Celular S.A.,BR AS855 756 57 699 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc.,CA AS4780 1037 370 667 64.3% SEEDNET Digital United Inc.,TW AS6147 780 113 667 85.5% Telefonica del Peru S.A.A.,PE AS9808 996 330 666 66.9% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN
Total 52942 14535 38407 72.5% Top 30 total
Possible Bogus Routes
27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US 41.78.236.0/24 AS37290 -Reserved AS-,ZZ 41.78.237.0/24 AS37290 -Reserved AS-,ZZ 41.78.238.0/24 AS37290 -Reserved AS-,ZZ 41.78.239.0/24 AS37290 -Reserved AS-,ZZ 41.190.72.0/24 AS37451 CongoTelecom,CG 41.190.73.0/24 AS37451 CongoTelecom,CG 41.190.74.0/24 AS37451 CongoTelecom,CG 41.190.75.0/24 AS37451 CongoTelecom,CG 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos,US 63.247.0.0/24 AS27609 -Reserved AS-,ZZ 63.247.1.0/24 AS27609 -Reserved AS-,ZZ 63.247.2.0/24 AS27609 -Reserved AS-,ZZ 63.247.3.0/24 AS27609 -Reserved AS-,ZZ 63.247.4.0/24 AS27609 -Reserved AS-,ZZ 63.247.5.0/24 AS27609 -Reserved AS-,ZZ 63.247.6.0/24 AS27609 -Reserved AS-,ZZ 63.247.7.0/24 AS27609 -Reserved AS-,ZZ 63.247.8.0/24 AS27609 -Reserved AS-,ZZ 63.247.9.0/24 AS27609 -Reserved AS-,ZZ 63.247.10.0/24 AS27609 -Reserved AS-,ZZ 63.247.11.0/24 AS27609 -Reserved AS-,ZZ 63.247.13.0/24 AS27609 -Reserved AS-,ZZ 63.247.14.0/24 AS27609 -Reserved AS-,ZZ 63.247.15.0/24 AS27609 -Reserved AS-,ZZ 63.247.16.0/24 AS27609 -Reserved AS-,ZZ 63.247.17.0/24 AS27609 -Reserved AS-,ZZ 63.247.18.0/24 AS27609 -Reserved AS-,ZZ 63.247.19.0/24 AS27609 -Reserved AS-,ZZ 63.247.20.0/24 AS27609 -Reserved AS-,ZZ 63.247.21.0/24 AS27609 -Reserved AS-,ZZ 63.247.22.0/24 AS27609 -Reserved AS-,ZZ 63.247.23.0/24 AS27609 -Reserved AS-,ZZ 63.247.24.0/24 AS27609 -Reserved AS-,ZZ 63.247.25.0/24 AS27609 -Reserved AS-,ZZ 63.247.26.0/24 AS27609 -Reserved AS-,ZZ 63.247.27.0/24 AS27609 -Reserved AS-,ZZ 63.247.28.0/24 AS27609 -Reserved AS-,ZZ 63.247.29.0/24 AS27609 -Reserved AS-,ZZ 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.111.160.0/20 AS40551 -Reserved AS-,ZZ 64.111.160.0/24 AS40551 -Reserved AS-,ZZ 64.111.161.0/24 AS40551 -Reserved AS-,ZZ 64.111.162.0/24 AS40551 -Reserved AS-,ZZ 64.111.167.0/24 AS40551 -Reserved AS-,ZZ 64.111.169.0/24 AS40551 -Reserved AS-,ZZ 64.111.170.0/24 AS40551 -Reserved AS-,ZZ 64.111.171.0/24 AS40551 -Reserved AS-,ZZ 64.111.172.0/24 AS40551 -Reserved AS-,ZZ 64.111.173.0/24 AS40551 -Reserved AS-,ZZ 64.111.174.0/24 AS40551 -Reserved AS-,ZZ 64.111.175.0/24 AS40551 -Reserved AS-,ZZ 64.119.240.0/22 AS26072 -Reserved AS-,ZZ 64.119.240.0/23 AS26072 -Reserved AS-,ZZ 64.119.242.0/23 AS26072 -Reserved AS-,ZZ 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc.,US 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.55.96.0/23 AS17203 -Reserved AS-,ZZ 66.55.98.0/24 AS17203 -Reserved AS-,ZZ 66.55.99.0/24 AS17203 -Reserved AS-,ZZ 66.55.100.0/22 AS17203 -Reserved AS-,ZZ 66.55.102.0/23 AS17203 -Reserved AS-,ZZ 66.55.104.0/21 AS17203 -Reserved AS-,ZZ 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.254.188.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 67.21.144.0/22 AS174 COGENT-174 - Cogent Communications,US 67.21.148.0/22 AS174 COGENT-174 - Cogent Communications,US 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.112.100.0/22 AS16764 -Reserved AS-,ZZ 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.115.124.0/23 AS46540 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.119.236.0/23 AS26368 -Reserved AS-,ZZ 74.119.239.0/24 AS26368 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 77.243.80.0/24 AS42597 -Reserved AS-,ZZ 77.243.81.0/24 AS42597 -Reserved AS-,ZZ 77.243.88.0/24 AS42597 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 77.243.94.0/24 AS42597 -Reserved AS-,ZZ 77.243.95.0/24 AS42597 -Reserved AS-,ZZ 80.250.32.0/22 AS37106 ODUA-AS,NG 85.202.160.0/20 AS44404 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.199.90.0/24 AS44330 -Reserved AS-,ZZ 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD,RU 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal,LT 91.229.182.0/24 AS56960 -Reserved AS-,ZZ 91.229.186.0/24 AS56967 -Reserved AS-,ZZ 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB 91.245.224.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.232.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.240.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.248.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 93.190.10.0/24 AS47254 -Reserved AS-,ZZ 95.215.140.0/22 AS48949 -Reserved AS-,ZZ 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building,MN 103.31.236.0/22 AS17941 BIT-ISLE Bit-isle Co.,Ltd.,JP 103.244.236.0/22 AS58794 103.247.52.0/23 AS4725 ODN SOFTBANK TELECOM Corp.,JP 110.76.128.0/22 AS13308 ENPL-PROD-AS-AP eintellego Networks Pty Ltd,AU 110.232.188.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 124.64.0.0/10 AS4847 CNIX-AP China Networks Inter-Exchange,CN 162.247.180.0/22 AS23175 POGOZONE - PogoZone,US 163.47.23.0/24 AS2907 SINET-AS Research Organization of Information and Systems, National Institute of Informatics,JP 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 176.124.32.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 185.55.100.0/22 AS12843 TELEMAXX TelemaxX Telekommunikation GmbH,DE 185.55.120.0/22 AS21385 TNIB Trusted Network GmbH,DE 185.55.124.0/22 AS8365 MANDA Man-da.de GmbH,DE 185.55.128.0/22 AS12573 WIDEXS WideXS B.V.,NL 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS,CO 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A.,EC 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.75.23.0/24 AS2579 -Reserved AS-,ZZ 192.75.239.0/24 AS23498 CDSI - Cogeco Data Services LP,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.104.61.0/24 AS1785 AS-PAETEC-NET - PaeTec Communications, Inc.,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.241.20.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.241.21.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.84.187.0/24 AS16276 OVH OVH SAS,FR 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB 193.109.217.0/24 AS13069 DATAGUARD DataGuard AS,NO 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.160.16.0/22 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.161.157.0/24 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc.,US 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.243.166.0/24 AS44093 -Reserved AS-,ZZ 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT HighTech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.113.27.0/24 AS12518 SHLINK SHLINK Internet Service,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.165.26.0/24 AS47381 DOCLERWEB-AS DoclerWeb Kft.,HU 194.165.27.0/24 AS47381 DOCLERWEB-AS DoclerWeb Kft.,HU 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 194.213.8.0/24 AS42845 BRETAGNETELECOM BRETAGNE TELECOM SAS,FR 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.39.252.0/23 AS29004 -Reserved AS-,ZZ 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.47.242.0/24 AS9050 RTD ROMTELECOM S.A,RO 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.90.98.0/23 AS57511 OVALTECH-AS OvalTech Internet Ltd,GB 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.114.14.0/23 AS31554 ALTFEL SC Almsoft Computers SRL,RO 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.2.224.0/22 AS24863 LINKdotNET-AS,EG 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.13.201.0/24 AS2018 TENET-1,ZA 196.13.202.0/24 AS2018 TENET-1,ZA 196.13.203.0/24 AS2018 TENET-1,ZA 196.13.204.0/24 AS2018 TENET-1,ZA 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.45.0.0/21 AS26625 -Reserved AS-,ZZ 196.45.10.0/24 AS26625 -Reserved AS-,ZZ 196.216.129.0/24 AS36886 -Reserved AS-,ZZ 196.216.130.0/24 AS36886 -Reserved AS-,ZZ 196.216.131.0/24 AS36886 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.72.78.0/23 AS3967 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.161.239.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.176.208.0/24 AS4318 FMI-NET-AS - Freeport McMoRan Copper & Gold Inc.,US 198.176.209.0/24 AS4318 FMI-NET-AS - Freeport McMoRan Copper & Gold Inc.,US 198.176.210.0/24 AS4318 FMI-NET-AS - Freeport McMoRan Copper & Gold Inc.,US 198.176.211.0/24 AS4318 FMI-NET-AS - Freeport McMoRan Copper & Gold Inc.,US 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services,HK 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.30.138.0/24 AS23319 -Reserved AS-,ZZ 199.30.139.0/24 AS23319 -Reserved AS-,ZZ 199.30.143.0/24 AS8100 IPTELLIGENT - IPTelligent LLC,US 199.68.72.0/24 AS174 COGENT-174 - Cogent Communications,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.87.166.0/24 AS26368 -Reserved AS-,ZZ 199.87.167.0/24 AS26368 -Reserved AS-,ZZ 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.91.240.0/21 AS174 COGENT-174 - Cogent Communications,US 199.102.73.0/24 AS26368 -Reserved AS-,ZZ 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.142.219.0/24 AS45149 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service,MN 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.10.94.0/23 AS30097 NUWAVE - NuWave,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp.,CA 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc.,US 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc.,US 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc.,US 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.74.224.0/22 AS174 COGENT-174 - Cogent Communications,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C.,US 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc.,US 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc.,US 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc.,US 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc.,US 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc.,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 212.119.32.0/19 AS12550 -Reserved AS-,ZZ 213.184.64.0/24 AS13071 -Reserved AS-,ZZ 213.184.65.0/24 AS13071 -Reserved AS-,ZZ 213.184.66.0/24 AS13071 -Reserved AS-,ZZ 213.184.67.0/24 AS13071 -Reserved AS-,ZZ 213.184.68.0/24 AS13071 -Reserved AS-,ZZ 213.184.69.0/24 AS13071 -Reserved AS-,ZZ 213.184.70.0/24 AS13071 -Reserved AS-,ZZ 213.184.71.0/24 AS13071 -Reserved AS-,ZZ 213.184.72.0/24 AS13071 -Reserved AS-,ZZ 213.184.73.0/24 AS13071 -Reserved AS-,ZZ 213.184.74.0/24 AS13071 -Reserved AS-,ZZ 213.184.75.0/24 AS13071 -Reserved AS-,ZZ 213.184.76.0/24 AS13071 -Reserved AS-,ZZ 213.184.77.0/24 AS13071 -Reserved AS-,ZZ 213.184.78.0/24 AS13071 -Reserved AS-,ZZ 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US 216.24.176.0/20 AS19401 -Reserved AS-,ZZ 216.24.188.0/24 AS19401 -Reserved AS-,ZZ 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.203.80.0/20 AS27021 -Reserved AS-,ZZ 216.203.80.0/21 AS27021 -Reserved AS-,ZZ 216.203.87.0/24 AS27021 -Reserved AS-,ZZ 216.203.88.0/21 AS27021 -Reserved AS-,ZZ 216.203.95.0/24 AS53490 MEDPLUS - MedPlus, Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US
Please see http://www.cidr-report.org for the full report
------------------------------------ Copies of this report are mailed to: nanog@nanog.org eof-list@ripe.net apops@apops.net routing-wg@ripe.net afnog@afnog.org
Hi, Patrick wrote:
25-04-14 500177 282878
I think congratulations are still in order, but frankly, I am less impressed with getting to 500 than 150. [...] Anyway, congratulations everyone.
.... now aggregate it back down again, please. :-) (If only) Andy
Composed on a virtual keyboard, please forgive typos.
On Apr 28, 2014, at 19:41, Chris Boyd <cboyd@gizmopartners.com> wrote:
On Apr 28, 2014, at 2:27 AM, Andy Davidson wrote:
.... now aggregate it back down again, please. :-)
I'm in the middle of a physical move. I promise I'll take the 3 deagg'd /24s out as soon as I can.
Do not laugh. If everyone who had 3 de-agg'ed prefixes fixed it, the table would drop precipitously. We all have to do our part. -- TTFN, patrick
On Mon, 28 Apr 2014 21:59:43 -0400, "Patrick W. Gilmore" said:
On Apr 28, 2014, at 19:41, Chris Boyd <cboyd@gizmopartners.com> wrote: I'm in the middle of a physical move. I promise I'll take the 3 deagg'd /24s out as soon as I can. Do not laugh. If everyone who had 3 de-agg'ed prefixes fixed it, the table would drop precipitously. We all have to do our part.
Do we have a handle on what percent of the de-aggrs are legitimate attempts at TE, and what percent are just whoopsies that should be re-aggregated?
On Mon, Apr 28, 2014 at 10:39 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Apr 28, 2014, at 19:41, Chris Boyd <cboyd@gizmopartners.com> wrote: I'm in the middle of a physical move. I promise I'll take the 3 deagg'd /24s out as soon as I can. Do not laugh. If everyone who had 3 de-agg'ed prefixes fixed it, the
On Mon, 28 Apr 2014 21:59:43 -0400, "Patrick W. Gilmore" said: table
would drop precipitously. We all have to do our part.
Do we have a handle on what percent of the de-aggrs are legitimate attempts at TE, and what percent are just whoopsies that should be re-aggregated?
And of those TE routes, how many can be suppressed by way of BGP Communities with their respective upstream providers ... charles
On 29 Apr 2014, at 12:39 pm, Valdis.Kletnieks@vt.edu wrote:
On Mon, 28 Apr 2014 21:59:43 -0400, "Patrick W. Gilmore" said:
On Apr 28, 2014, at 19:41, Chris Boyd <cboyd@gizmopartners.com> wrote: I'm in the middle of a physical move. I promise I'll take the 3 deagg'd /24s out as soon as I can. Do not laugh. If everyone who had 3 de-agg'ed prefixes fixed it, the table would drop precipitously. We all have to do our part.
Do we have a handle on what percent of the de-aggrs are legitimate attempts at TE, and what percent are just whoopsies that should be re-aggregated?
I made a shot at such a number in a presentation to NANOG in Feb this year (http://www.potaroo.net/presentations/2014-02-09-bgp2013.pdf) If you assume that Traffic Engineering more specifics share a common origin AS with the covering aggregate, then around 26% of more specifics are TE advertisements. This number (as a percentage) has gwon by 5% over the past three years If you assume that Hole Punching more specifics are more specifics that use a different origin AS, then these account for 30% of the more specifics in today's routing table. This number has fallen by 5% over the past three years. The remainder of the prefixes (45%) shares the same origin AS and the same path. The could be TE prefixes, but as they are identical to their covering aggregate its hard to appreciate exactly what the engineering intent may be. I could make a wild guess and call these 45% of more specifics to be an act of senseless routing vandalism. ( :-) ) This number has been steady as a % for the past three years. Interestingly, it's the hole punching more specifics that are less stable, and the senseless routing vandalism more specifics that are more stable than the average. thanks, Geoff
The remainder of the prefixes (45%) shares the same origin AS and the same path. The could be TE prefixes, but as they are identical to their covering aggregate its hard to appreciate exactly what the engineering intent may be. I could make a wild guess and call these 45% of more specifics to be an act of senseless routing vandalism. ( :-) ) This number has been steady as a % for the past three years.
This could easily be TE, and a type of TE which would be trivially fixed. Let's take a simple example of a network with a /22 and 4 POPs. They have the same transit provider(s) at all 4 POPs and a small backbone to connect them. Each POP gets a /24. A not-ridiculous way to force their transit provider to carry bits instead of clogging their backbone while still ensuring redundancy would be to announce the /22 at all four POPs and the individual /24 at each individual POP. This creates four /24s and a covering /22 with exactly the same path, but still has "use" as TE. Of course, it would be trivial for the network to clean up their act by attacking no-export to the /24s. But some people either do not know it exists, know how it works, or know BGP well enough to understand it would not harm them. Or maybe they are just lazy: "What's 3 extra prefixes in half a million?" The answer to the last question is, frankly, nothing. But 3 prefixes for 30K ASNs is an ass-ton. (That's a technical term meaning "lots & lots".) This is a good time for a marketing effort. Let's see if we can get the table back under 500K. Everyone check your announcements. Are you announcing more specifics and a covering aggregate with the same path? Can you delete the more specific? Can you add no-export or another community to keep the more specifics from the global table? If you are unsure, ask. I think it would be rather awesome if we saw a quick reversal in table growth and went back under 500K, even if it was short lived. ESPECIALLY if we can do it before we hit 512K prefixes. Would prove the community still cares about, well, the community, not just their own network. Because on the Internet, "your network" is part of the "community", and things that harm the latter do harm the former, even if it is difficult for you to see sometimes. Who will be the first to pull back a few prefixes? -- TTFN, patrick On Apr 29, 2014, at 03:31 , Geoff Huston <gih@apnic.net> wrote:
On 29 Apr 2014, at 12:39 pm, Valdis.Kletnieks@vt.edu wrote:
On Mon, 28 Apr 2014 21:59:43 -0400, "Patrick W. Gilmore" said:
On Apr 28, 2014, at 19:41, Chris Boyd <cboyd@gizmopartners.com> wrote: I'm in the middle of a physical move. I promise I'll take the 3 deagg'd /24s out as soon as I can. Do not laugh. If everyone who had 3 de-agg'ed prefixes fixed it, the table would drop precipitously. We all have to do our part.
Do we have a handle on what percent of the de-aggrs are legitimate attempts at TE, and what percent are just whoopsies that should be re-aggregated?
I made a shot at such a number in a presentation to NANOG in Feb this year (http://www.potaroo.net/presentations/2014-02-09-bgp2013.pdf)
If you assume that Traffic Engineering more specifics share a common origin AS with the covering aggregate, then around 26% of more specifics are TE advertisements. This number (as a percentage) has gwon by 5% over the past three years
If you assume that Hole Punching more specifics are more specifics that use a different origin AS, then these account for 30% of the more specifics in today's routing table. This number has fallen by 5% over the past three years.
The remainder of the prefixes (45%) shares the same origin AS and the same path. The could be TE prefixes, but as they are identical to their covering aggregate its hard to appreciate exactly what the engineering intent may be. I could make a wild guess and call these 45% of more specifics to be an act of senseless routing vandalism. ( :-) ) This number has been steady as a % for the past three years.
Interestingly, it's the hole punching more specifics that are less stable, and the senseless routing vandalism more specifics that are more stable than the average.
thanks, Geoff
Already working on aggregating as much as I can. I was checking my tables the other day and I think I saw another provider advertising their /18 as /24s, it made me sick. -- Kate Gerry Network Manager kate@quadranet.com 1-888-5-QUADRA Ext 206 | www.QuadraNet.com Dedicated Servers, Colocation, Cloud Services and more. Datacenters in Los Angeles, Dallas and Miami. Follow us on: -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Patrick W. Gilmore Sent: Tuesday, April 29, 2014 9:23 AM To: NANOG list Subject: Re: We hit half-million: The Cidr Report
The remainder of the prefixes (45%) shares the same origin AS and the same path. The could be TE prefixes, but as they are identical to their covering aggregate its hard to appreciate exactly what the engineering intent may be. I could make a wild guess and call these 45% of more specifics to be an act of senseless routing vandalism. ( :-) ) This number has been steady as a % for the past three years.
This could easily be TE, and a type of TE which would be trivially fixed. Let's take a simple example of a network with a /22 and 4 POPs. They have the same transit provider(s) at all 4 POPs and a small backbone to connect them. Each POP gets a /24. A not-ridiculous way to force their transit provider to carry bits instead of clogging their backbone while still ensuring redundancy would be to announce the /22 at all four POPs and the individual /24 at each individual POP. This creates four /24s and a covering /22 with exactly the same path, but still has "use" as TE. Of course, it would be trivial for the network to clean up their act by attacking no-export to the /24s. But some people either do not know it exists, know how it works, or know BGP well enough to understand it would not harm them. Or maybe they are just lazy: "What's 3 extra prefixes in half a million?" The answer to the last question is, frankly, nothing. But 3 prefixes for 30K ASNs is an ass-ton. (That's a technical term meaning "lots & lots".) This is a good time for a marketing effort. Let's see if we can get the table back under 500K. Everyone check your announcements. Are you announcing more specifics and a covering aggregate with the same path? Can you delete the more specific? Can you add no-export or another community to keep the more specifics from the global table? If you are unsure, ask. I think it would be rather awesome if we saw a quick reversal in table growth and went back under 500K, even if it was short lived. ESPECIALLY if we can do it before we hit 512K prefixes. Would prove the community still cares about, well, the community, not just their own network. Because on the Internet, "your network" is part of the "community", and things that harm the latter do harm the former, even if it is difficult for you to see sometimes. Who will be the first to pull back a few prefixes? -- TTFN, patrick On Apr 29, 2014, at 03:31 , Geoff Huston <gih@apnic.net> wrote:
On 29 Apr 2014, at 12:39 pm, Valdis.Kletnieks@vt.edu wrote:
On Mon, 28 Apr 2014 21:59:43 -0400, "Patrick W. Gilmore" said:
On Apr 28, 2014, at 19:41, Chris Boyd <cboyd@gizmopartners.com> wrote: I'm in the middle of a physical move. I promise I'll take the 3 deagg'd /24s out as soon as I can. Do not laugh. If everyone who had 3 de-agg'ed prefixes fixed it, the table would drop precipitously. We all have to do our part.
Do we have a handle on what percent of the de-aggrs are legitimate attempts at TE, and what percent are just whoopsies that should be re-aggregated?
I made a shot at such a number in a presentation to NANOG in Feb this year (http://www.potaroo.net/presentations/2014-02-09-bgp2013.pdf)
If you assume that Traffic Engineering more specifics share a common origin AS with the covering aggregate, then around 26% of more specifics are TE advertisements. This number (as a percentage) has gwon by 5% over the past three years
If you assume that Hole Punching more specifics are more specifics that use a different origin AS, then these account for 30% of the more specifics in today's routing table. This number has fallen by 5% over the past three years.
The remainder of the prefixes (45%) shares the same origin AS and the same path. The could be TE prefixes, but as they are identical to their covering aggregate its hard to appreciate exactly what the engineering intent may be. I could make a wild guess and call these 45% of more specifics to be an act of senseless routing vandalism. ( :-) ) This number has been steady as a % for the past three years.
Interestingly, it's the hole punching more specifics that are less stable, and the senseless routing vandalism more specifics that are more stable than the average.
thanks, Geoff
At one time Covad stated they announce everything as /24 to make hijacking more difficult. Looks like Covad (now MEGAPATH) hasn't changed that policy. On 4/29/2014 12:29 PM, Kate Gerry wrote:
Already working on aggregating as much as I can. I was checking my tables the other day and I think I saw another provider advertising their /18 as /24s, it made me sick.
-- Kate Gerry Network Manager kate@quadranet.com
1-888-5-QUADRA Ext 206 | www.QuadraNet.com Dedicated Servers, Colocation, Cloud Services and more. Datacenters in Los Angeles, Dallas and Miami.
Follow us on:
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Patrick W. Gilmore Sent: Tuesday, April 29, 2014 9:23 AM To: NANOG list Subject: Re: We hit half-million: The Cidr Report
The remainder of the prefixes (45%) shares the same origin AS and the same path. The could be TE prefixes, but as they are identical to their covering aggregate its hard to appreciate exactly what the engineering intent may be. I could make a wild guess and call these 45% of more specifics to be an act of senseless routing vandalism. ( :-) ) This number has been steady as a % for the past three years. This could easily be TE, and a type of TE which would be trivially fixed.
Let's take a simple example of a network with a /22 and 4 POPs. They have the same transit provider(s) at all 4 POPs and a small backbone to connect them. Each POP gets a /24.
A not-ridiculous way to force their transit provider to carry bits instead of clogging their backbone while still ensuring redundancy would be to announce the /22 at all four POPs and the individual /24 at each individual POP. This creates four /24s and a covering /22 with exactly the same path, but still has "use" as TE.
Of course, it would be trivial for the network to clean up their act by attacking no-export to the /24s. But some people either do not know it exists, know how it works, or know BGP well enough to understand it would not harm them. Or maybe they are just lazy: "What's 3 extra prefixes in half a million?"
The answer to the last question is, frankly, nothing. But 3 prefixes for 30K ASNs is an ass-ton. (That's a technical term meaning "lots & lots".)
This is a good time for a marketing effort. Let's see if we can get the table back under 500K. Everyone check your announcements. Are you announcing more specifics and a covering aggregate with the same path? Can you delete the more specific? Can you add no-export or another community to keep the more specifics from the global table?
If you are unsure, ask. I think it would be rather awesome if we saw a quick reversal in table growth and went back under 500K, even if it was short lived. ESPECIALLY if we can do it before we hit 512K prefixes. Would prove the community still cares about, well, the community, not just their own network. Because on the Internet, "your network" is part of the "community", and things that harm the latter do harm the former, even if it is difficult for you to see sometimes.
Who will be the first to pull back a few prefixes?
-- TTFN, patrick
On Apr 29, 2014, at 03:31 , Geoff Huston <gih@apnic.net> wrote:
On 29 Apr 2014, at 12:39 pm, Valdis.Kletnieks@vt.edu wrote:
On Mon, 28 Apr 2014 21:59:43 -0400, "Patrick W. Gilmore" said:
On Apr 28, 2014, at 19:41, Chris Boyd <cboyd@gizmopartners.com> wrote: I'm in the middle of a physical move. I promise I'll take the 3 deagg'd /24s out as soon as I can. Do not laugh. If everyone who had 3 de-agg'ed prefixes fixed it, the table would drop precipitously. We all have to do our part. Do we have a handle on what percent of the de-aggrs are legitimate attempts at TE, and what percent are just whoopsies that should be re-aggregated?
I made a shot at such a number in a presentation to NANOG in Feb this year (http://www.potaroo.net/presentations/2014-02-09-bgp2013.pdf)
If you assume that Traffic Engineering more specifics share a common origin AS with the covering aggregate, then around 26% of more specifics are TE advertisements. This number (as a percentage) has gwon by 5% over the past three years
If you assume that Hole Punching more specifics are more specifics that use a different origin AS, then these account for 30% of the more specifics in today's routing table. This number has fallen by 5% over the past three years.
The remainder of the prefixes (45%) shares the same origin AS and the same path. The could be TE prefixes, but as they are identical to their covering aggregate its hard to appreciate exactly what the engineering intent may be. I could make a wild guess and call these 45% of more specifics to be an act of senseless routing vandalism. ( :-) ) This number has been steady as a % for the past three years.
Interestingly, it's the hole punching more specifics that are less stable, and the senseless routing vandalism more specifics that are more stable than the average.
thanks, Geoff
There are many actually doing this, to be honest. From the top of my head, in the greater Dallas area, 54540 comes to mind. http://bgp.he.net/AS54540#_asinfo For large ASNs like these, aggregation would really help the table size. That said, working on reducing our own as well. On 4/29/2014 10:29 PM, Kate Gerry wrote:
Already working on aggregating as much as I can. I was checking my tables the other day and I think I saw another provider advertising their /18 as /24s, it made me sick.
-- Kate Gerry Network Manager kate@quadranet.com
1-888-5-QUADRA Ext 206 | www.QuadraNet.com Dedicated Servers, Colocation, Cloud Services and more. Datacenters in Los Angeles, Dallas and Miami.
Follow us on:
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Patrick W. Gilmore Sent: Tuesday, April 29, 2014 9:23 AM To: NANOG list Subject: Re: We hit half-million: The Cidr Report
The remainder of the prefixes (45%) shares the same origin AS and the same path. The could be TE prefixes, but as they are identical to their covering aggregate its hard to appreciate exactly what the engineering intent may be. I could make a wild guess and call these 45% of more specifics to be an act of senseless routing vandalism. ( :-) ) This number has been steady as a % for the past three years. This could easily be TE, and a type of TE which would be trivially fixed.
Let's take a simple example of a network with a /22 and 4 POPs. They have the same transit provider(s) at all 4 POPs and a small backbone to connect them. Each POP gets a /24.
A not-ridiculous way to force their transit provider to carry bits instead of clogging their backbone while still ensuring redundancy would be to announce the /22 at all four POPs and the individual /24 at each individual POP. This creates four /24s and a covering /22 with exactly the same path, but still has "use" as TE.
Of course, it would be trivial for the network to clean up their act by attacking no-export to the /24s. But some people either do not know it exists, know how it works, or know BGP well enough to understand it would not harm them. Or maybe they are just lazy: "What's 3 extra prefixes in half a million?"
The answer to the last question is, frankly, nothing. But 3 prefixes for 30K ASNs is an ass-ton. (That's a technical term meaning "lots & lots".)
This is a good time for a marketing effort. Let's see if we can get the table back under 500K. Everyone check your announcements. Are you announcing more specifics and a covering aggregate with the same path? Can you delete the more specific? Can you add no-export or another community to keep the more specifics from the global table?
If you are unsure, ask. I think it would be rather awesome if we saw a quick reversal in table growth and went back under 500K, even if it was short lived. ESPECIALLY if we can do it before we hit 512K prefixes. Would prove the community still cares about, well, the community, not just their own network. Because on the Internet, "your network" is part of the "community", and things that harm the latter do harm the former, even if it is difficult for you to see sometimes.
Who will be the first to pull back a few prefixes?
-- TTFN, patrick
On Apr 29, 2014, at 03:31 , Geoff Huston <gih@apnic.net> wrote:
On 29 Apr 2014, at 12:39 pm, Valdis.Kletnieks@vt.edu wrote:
On Mon, 28 Apr 2014 21:59:43 -0400, "Patrick W. Gilmore" said:
On Apr 28, 2014, at 19:41, Chris Boyd <cboyd@gizmopartners.com> wrote: I'm in the middle of a physical move. I promise I'll take the 3 deagg'd /24s out as soon as I can. Do not laugh. If everyone who had 3 de-agg'ed prefixes fixed it, the table would drop precipitously. We all have to do our part. Do we have a handle on what percent of the de-aggrs are legitimate attempts at TE, and what percent are just whoopsies that should be re-aggregated?
I made a shot at such a number in a presentation to NANOG in Feb this year (http://www.potaroo.net/presentations/2014-02-09-bgp2013.pdf)
If you assume that Traffic Engineering more specifics share a common origin AS with the covering aggregate, then around 26% of more specifics are TE advertisements. This number (as a percentage) has gwon by 5% over the past three years
If you assume that Hole Punching more specifics are more specifics that use a different origin AS, then these account for 30% of the more specifics in today's routing table. This number has fallen by 5% over the past three years.
The remainder of the prefixes (45%) shares the same origin AS and the same path. The could be TE prefixes, but as they are identical to their covering aggregate its hard to appreciate exactly what the engineering intent may be. I could make a wild guess and call these 45% of more specifics to be an act of senseless routing vandalism. ( :-) ) This number has been steady as a % for the past three years.
Interestingly, it's the hole punching more specifics that are less stable, and the senseless routing vandalism more specifics that are more stable than the average.
thanks, Geoff
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 29/04/2014 04:39, Valdis.Kletnieks@vt.edu a écrit :
Do we have a handle on what percent of the de-aggrs are legitimate attempts at TE, and what percent are just whoopsies that should be re-aggregated?
Deaggs can "legitimatelly" occur for a different purpose : hijack prevention (Pilosov & Kapela style). It's fairly easy to punch a hole in a larger prefix, but winning the reachability race while unable to propagate a more specific prefix significantly increase hijacking costs. For a less densely connected network (no presence on public IXPs, poor transits...), renumbering critical services (DNS, MX, extranets) to one of their /24s and de-aggregating it could be a smart move. - -- Jérôme Nicolle -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNg94YACgkQbt+nwQamihvv6wCdFS6gqfUJwD0m/OelYdWjCZui S9cAnAkxlWyM4/JJmTPKxPWKYRXbz/c0 =vuYo -----END PGP SIGNATURE-----
On Apr 30, 2014, at 09:15 , Jérôme Nicolle <jerome@ceriz.fr> wrote:
Le 29/04/2014 04:39, Valdis.Kletnieks@vt.edu a écrit :
Do we have a handle on what percent of the de-aggrs are legitimate attempts at TE, and what percent are just whoopsies that should be re-aggregated?
Deaggs can "legitimatelly" occur for a different purpose : hijack prevention (Pilosov & Kapela style).
It's fairly easy to punch a hole in a larger prefix, but winning the reachability race while unable to propagate a more specific prefix significantly increase hijacking costs.
Excellent point, Jérôme. Let's make sure nothing is hijack-able. Quick, let's de-agg -everything- to /24s. Everyone's routers can sustain > 10 million prefixes per full table, right? Jérôme, how many prefixes can your routers handle? Or we could stop thinking that abusing a shared resource for personal gain is a great idea.
For a less densely connected network (no presence on public IXPs, poor transits...), renumbering critical services (DNS, MX, extranets) to one of their /24s and de-aggregating it could be a smart move.
See my previous post. Of course deaggregation can have a use, but for a network is no peering an one or a few transits, those more specifices never have to hit the global table. Sending that /24 to your transit provider(s) with no-export will have the _exact_same_effect_, and not pollute anyone's routers whom you are not paying. The idea "I have a 'reason' for hurting everyone else, so it is OK" has got to stop. Just because you have a reason does not make it OK. And even when it is a good idea, most people implement it so poorly as to cause unneeded harm. -- TTFN, patrick
Patrick, Le 30/04/2014 16:54, Patrick W. Gilmore a écrit :
It's fairly easy to punch a hole in a larger prefix, but winning the reachability race while unable to propagate a more specific prefix significantly increase hijacking costs.
Excellent point, Jérôme.
Let's make sure nothing is hijack-able. Quick, let's de-agg -everything- to /24s. Everyone's routers can sustain > 10 million prefixes per full table, right? Jérôme, how many prefixes can your routers handle?
Or we could stop thinking that abusing a shared resource for personal gain is a great idea.
I totally agree with you. It's a shame to have to consider bad practices from a network perspective as necessities from a security standpoint. That beeing said, let's try to consider adverse interests on that matter. Large routing tables are an issue for smaller networks generating less value than major players usually providing transits to others. The constant growth of the routing table gives a technical and economical advantages to established carriers (roughly the same arguing OTTs _must_ pay premium PNIs because of an arbitrary ratio-driven peering policy). The necessity for higher-end routers to provide transit services could also slow down the steep fall of transit prices. It would establish a sensible barrier to newcomers on local transit services. It's also reducing the value of older equipments and killing the grey-market and brokers. Well, the power-draw of 6500's and other oldies could be enough, but their unability to scale to today's standards helps newer hardware sales. Now there would be a smart way to handle the issue with SDN. A "smart" network controler could manage a larger RIB with ease and provide routing-ASICs with a virtualy agregated FIB much smaller than the previous 256k routes limit, thus creating more interest for older routing-switches. Would a manufacturer develop such a smart conroller ? Nah, let's sell bigger overpriced TCAMs instead. Oh, and of course, the argument about hijack-prevention would disapear if everyone was doing there part and deploy RPKI in a matter of weeks. As did everyone feel the responsability to deploy IPv6, for that matter.
See my previous post. Of course deaggregation can have a use, but for a network is no peering an one or a few transits, those more specifices never have to hit the global table. Sending that /24 to your transit provider(s) with no-export will have the _exact_same_effect_, and not pollute anyone's routers whom you are not paying.
I'm not sure we're on the same page here. De-agregating with a no-export tag will have no effect at all but on TE between the orinating AS and its transit provider. If the more specific prefix isn't propagated, a hijack may occur locally anywhere else on the Internet. Let's consider someone willing to intercept mails from major hosted services (gmail, outlook...) to a company connected through bad transits. The hijacker would simply announce the more specific prefix on a few IXPs and win the reachability. The backchannel route could then be established over any other T1 (who won't pick up the more-specific anyway). Simply put, you have to be no more than one hop away from most IXPs to get a decent hijack-proof reachability. De-agg with no-export is a nonsense.
The idea "I have a 'reason' for hurting everyone else, so it is OK" has got to stop. Just because you have a reason does not make it OK. And even when it is a good idea, most people implement it so poorly as to cause unneeded harm.
Alright, let's implement new policies at a RIR, IXPs and T1s levels to forbid anyone from de-agregation without no-exports. Culprits would fall under a three-strike policy before definitive de-peering and public humiliation. Who's with me ? :) -- Jérôme Nicolle
On Apr 28, 2014, at 6:59 PM, Patrick W. Gilmore <patrick@ianai.net> wrote:
Composed on a virtual keyboard, please forgive typos.
On Apr 28, 2014, at 19:41, Chris Boyd <cboyd@gizmopartners.com> wrote:
On Apr 28, 2014, at 2:27 AM, Andy Davidson wrote:
.... now aggregate it back down again, please. :-)
I'm in the middle of a physical move. I promise I'll take the 3 deagg'd /24s out as soon as I can.
Do not laugh. If everyone who had 3 de-agg'ed prefixes fixed it, the table would drop precipitously. We all have to do our part.
If everyone who had 30+ inaggregable IPv4 prefixes replaced them with 1 (or even 3) IPv6 prefixes… As a bonus, we could get rid of NAT, too. ;-) /me ducks (but you know I had to say it) Owen
On 4/29/2014 2:06 PM, Owen DeLong wrote:
If everyone who had 30+ inaggregable IPv4 prefixes replaced them with 1 (or even 3) IPv6 prefixes…
As a bonus, we could get rid of NAT, too. ;-)
/me ducks (but you know I had to say it)
Yeah, just when we thought Slammer / Blaster / Nachi / Welchia / etc / etc had been eliminated by process of "can't get there from here"... we expose millions more endpoints... /me ducks too (but you know *I* had to say it)
On Tue, Apr 29, 2014 at 7:54 PM, Jeff Kell <jeff-kell@utc.edu> wrote:
On 4/29/2014 2:06 PM, Owen DeLong wrote:
If everyone who had 30+ inaggregable IPv4 prefixes replaced them with 1 (or even 3) IPv6 prefixes…
As a bonus, we could get rid of NAT, too. ;-)
/me ducks (but you know I had to say it)
Yeah, just when we thought Slammer / Blaster / Nachi / Welchia / etc / etc had been eliminated by process of "can't get there from here"... we expose millions more endpoints...
/me ducks too (but you know *I* had to say it)
No ducking here. You forgot Nimda. Do you have an example from the last 10 years of this class ? Windows XP SP3 with a default host firewall on really did solve most of this, not NAT. Not stateful firewalls in networks. In fact, jogging my memory, i clearly remember Blaster taking out enterprise networks with network firewalls and stateful inspection... because people manually move their laptops between security zones. Right? They got infected on one LAN and then attached and spread the worm to other LANs. I also remember the folks saying we just spent $100k on a pair of super Netscreen firewalls, why is our network crashing? Right? And then the infection scanning from hacked hosts... of course, overloaded the firewall, and that crashed the entire campus... because the firewall was a single point of failure sitting on the internet boarder... and it has the 0-day flaw of too many sessions = crash. Most firewalls have this 0-day, it's a feature. This really happened to me in 2003, where a network based attack had a broad impact on hosts. But, never again after Win XP SP3. Now, i just have DDoS from purposefully publicly (poorly) run NTP and DNS servers. And, hacks from users clicking on links they know they should not click on. Oh, and anything made with Java or Adobe or IE. Those things are impossible to run securely, so secure systems don't run them. And, every now and then a server gets cracked, right through the stateful firewall... because there was a rule allowing ANY to TCP 80. CB
On 4/29/2014 11:37 PM, TheIpv6guy . wrote:
On Tue, Apr 29, 2014 at 7:54 PM, Jeff Kell <jeff-kell@utc.edu> wrote:
On 4/29/2014 2:06 PM, Owen DeLong wrote:
If everyone who had 30+ inaggregable IPv4 prefixes replaced them with 1 (or even 3) IPv6 prefixes… As a bonus, we could get rid of NAT, too. ;-) /me ducks (but you know I had to say it) Yeah, just when we thought Slammer / Blaster / Nachi / Welchia / etc / etc had been eliminated by process of "can't get there from here"... we expose millions more endpoints...
/me ducks too (but you know *I* had to say it)
No ducking here. You forgot Nimda. Do you have an example from the last 10 years of this class ?
Oh? Anything hitting portmapper (tcp/135), or CIFS (tcp/445), or RDP (tdp/3389 -- CVE-2012-0002 ring any bells?). The vulnerabilities never stop. We just stop paying attention because most of us have blocked 135-139 and 445 and 3389 at the border long ago. Now granted that 80/443 (server-side) are more dangerous these days :) But that doesn't eliminate the original risks. These are ports that were originally open by default... and if you "don't" have a perimeter policy, you're "wrong" (policy, compliance, regulation, etc). Not to mention that PCI compliance requires you are RFC1918 (non-routed) at your endpoints, but I digress... Jeff
Just out of curiosity, how does removing port address translation from the equation magically and suddenly make everything exposed, and un-invent the firewall? -Blake On Tue, Apr 29, 2014 at 11:00 PM, Jeff Kell <jeff-kell@utc.edu> wrote:
On 4/29/2014 11:37 PM, TheIpv6guy . wrote:
On Tue, Apr 29, 2014 at 7:54 PM, Jeff Kell <jeff-kell@utc.edu> wrote:
On 4/29/2014 2:06 PM, Owen DeLong wrote:
If everyone who had 30+ inaggregable IPv4 prefixes replaced them with 1 (or even 3) IPv6 prefixes… As a bonus, we could get rid of NAT, too. ;-) /me ducks (but you know I had to say it) Yeah, just when we thought Slammer / Blaster / Nachi / Welchia / etc / etc had been eliminated by process of "can't get there from here"... we expose millions more endpoints...
/me ducks too (but you know *I* had to say it)
No ducking here. You forgot Nimda. Do you have an example from the last 10 years of this class ?
Oh? Anything hitting portmapper (tcp/135), or CIFS (tcp/445), or RDP (tdp/3389 -- CVE-2012-0002 ring any bells?).
The vulnerabilities never stop. We just stop paying attention because most of us have blocked 135-139 and 445 and 3389 at the border long ago.
Now granted that 80/443 (server-side) are more dangerous these days :) But that doesn't eliminate the original risks.
These are ports that were originally open by default... and if you "don't" have a perimeter policy, you're "wrong" (policy, compliance, regulation, etc).
Not to mention that PCI compliance requires you are RFC1918 (non-routed) at your endpoints, but I digress...
Jeff
On 4/30/14, 12:00 AM, "Jeff Kell" <jeff-kell@utc.edu> wrote:
Not to mention that PCI compliance requires you are RFC1918 (non-routed) at your endpoints, but I digress...
This is emphatically not true. All PCI compliance requires is that your private IP addresses are not disclosed to the public, which could be RFC1918, NAT, firewalling, proxies, creative routing, etc. --Josh hates this misconception.
Behalf Of Jeff Kell
Not to mention that PCI compliance requires you are RFC1918 (non-routed) at your endpoints, but I digress...
You're not funny. And if you're not joking, you're wrong. We just went over this on this very list two weeks ago. Jamie
On Wed, 30 Apr 2014 15:40:43 -0000, Jamie Bowden said:
You're not funny. And if you're not joking, you're wrong. We just went over this on this very list two weeks ago.
And in that discussion, we ascertained that what the PCI standard actually says, and what you need to do in order to get unclued boneheaded auditors to sign the piece of paper, are two very different things. Yes, the PCI standard gives a list of 4 options and then continues on to say that other creative solutions are acceptable as well. But if you discover mid-engagement that your auditor *thinks* it says "Thou shalt NAT", you have a problem. Anybody got recommendations on how to make sure the company you engage for the audit ends up sending you critters that actually have a clue? (Not necessarily PCI, but in general)
On 4/30/14, 9:30 AM, Valdis.Kletnieks@vt.edu wrote:
On Wed, 30 Apr 2014 15:40:43 -0000, Jamie Bowden said:
You're not funny. And if you're not joking, you're wrong. We just went over this on this very list two weeks ago.
And in that discussion, we ascertained that what the PCI standard actually says, and what you need to do in order to get unclued boneheaded auditors to sign the piece of paper, are two very different things.
Yes, the PCI standard gives a list of 4 options and then continues on to say that other creative solutions are acceptable as well. But if you discover mid-engagement that your auditor *thinks* it says "Thou shalt NAT", you have a problem.
Anybody got recommendations on how to make sure the company you engage for the audit ends up sending you critters that actually have a clue? (Not necessarily PCI, but in general)
So, I've been (fomerly) involved in the design/build/operation/refresh of pci environments as part of application services for enterprise with ~ order of .8 billion annually in online sales. The process starts at the beginning e.g. before you build it. If you parachute in a consultant or auditor totally cold, you are going to have to educate them to the nuances of your particular operation, it's is very similar with SOX controls. In any event your documentation should be order. and actual operation should be as documented. Ultimately as was my experience with FIPA/HERPA compliance in the educational environment these should not taken as mysterious externalities foisted on operations by hostile regulators, or industrial cartels, but as part of normal business operations, and internalized as such.
Anybody got recommendations on how to make sure the company you engage for the audit ends up sending you critters that actually have a clue? (Not necessarily PCI, but in general)
In my previous jobs when I was doing FIPS/NIST/whatever compliance, it ended up being the case that having a highlighted copy of the spec document worked wonders most of the time. Barring that, the one place where I had a problem with this also had a COO who was formerly a shark-in-an-$8000-suit type of lawyer, and he was often able to explain to a clue-free auditor's boss exactly what would happen if they failed us despite the fact we met the spec as written (starting with reporting them to the PCI guys in charge of maintaining the list of qualified auditors). It's been my general experience that one must vet auditors in the same way one vets other vendors of intangible products--carefully and thoroughly, lest they screw you. Spend the same amount of energy you'd spend choosing the appropriate corporate lawyers or outsourced HR. -- Josh
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30/04/14 17:30, Valdis.Kletnieks@vt.edu wrote:
... Anybody got recommendations on how to make sure the company you engage for the audit ends up sending you critters that actually have a clue? (Not necessarily PCI, but in general)
If more auditors (of whatever type) were put in the street when they annoy their customer or act irrationally, the world might become a better place. John - -- John Souter, CEO, London Internet Exchange Ltd Trinity Court, Trinity Street, Peterborough PE1 1DA. Registered 3137929 in England. Mobile: +44-7711-492389 https://www.linx.net/ "Working for the Internet" sip:john@linx.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlNiDWIACgkQbwHoykR44Oc6QQCfZd2+62OqHEM9Ua04IWAUmXMO c1sAn2A2vLYDknI0hqbti9lDZXUoi1v/ =2Bwf -----END PGP SIGNATURE-----
On May 1, 2014, at 2:01 AM, John Souter <john@linx.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 30/04/14 17:30, Valdis.Kletnieks@vt.edu wrote:
... Anybody got recommendations on how to make sure the company you engage for the audit ends up sending you critters that actually have a clue? (Not necessarily PCI, but in general)
If more auditors (of whatever type) were put in the street when they annoy their customer or act irrationally, the world might become a better place.
The problem with this theory is that if auditors can be so easily put to the street, you run into the risk of auditors altering behavior to increase customer satisfaction in ways that prevent them from providing the controls that are the reason auditors exist in the first place. If you don’t believe me, examine the history of Arthur Anderson and their relationship with a certain Houston-based company which failed spectacularly. Owen
On 01/05/14 17:41, Owen DeLong wrote:
The problem with this theory is that if auditors can be so easily put to the street, you run into the risk of auditors altering behavior to increase customer satisfaction in ways that prevent them from providing the controls that are the reason auditors exist in the first place.
I disagree. And the power balance is generally tilted way in favour of the auditors, as many people on this thread have already commented. In my experience, most companies are afraid/inhibited to raise issues or challenge their auditors in any way. Nobody is asking auditors to roll over, but if their behaviour is unprofessional/illogical, then a short sharp shock should do the trick.
If you don’t believe me, examine the history of Arthur Anderson and their relationship with a certain Houston-based company which failed spectacularly.
Can't really comment, but it was financial auditing, and ISTR that many things failed in that situation - not just financial auditing. John -- John Souter, CEO, London Internet Exchange Ltd Trinity Court, Trinity Street, Peterborough PE1 1DA. Registered 3137929 in England. Mobile: +44-7711-492389 https://www.linx.net/ "Working for the Internet" sip:john@linx.net
On May 1, 2014, at 11:07 AM, John Souter <john@linx.net> wrote:
On 01/05/14 17:41, Owen DeLong wrote:
The problem with this theory is that if auditors can be so easily put to the street, you run into the risk of auditors altering behavior to increase customer satisfaction in ways that prevent them from providing the controls that are the reason auditors exist in the first place.
I disagree. And the power balance is generally tilted way in favour of the auditors, as many people on this thread have already commented. In my experience, most companies are afraid/inhibited to raise issues or challenge their auditors in any way. Nobody is asking auditors to roll over, but if their behaviour is unprofessional/illogical, then a short sharp shock should do the trick.
I’m not saying that auditors shouldn’t be accountable or that people shouldn’t be able to do something about auditors that are being irrational/stupid. Believe me, I cringe every time I hear “our auditors require NAT as a security mechanism” since NAT is a minor hindrance to security at best. I realize you’re not asking auditors to roll over, but finding a balance point is tricky.
If you don’t believe me, examine the history of Arthur Anderson and their relationship with a certain Houston-based company which failed spectacularly.
Can't really comment, but it was financial auditing, and ISTR that many things failed in that situation - not just financial auditing.
Many things failed in that situation. MOST of them should have been caught and stopped by financial auditing. Yes, it was financial auditing, but I don’t really see the difference. When you turn “pleasing the customer” into a potential conflict with “accurate audit results”, you create a recipe for trouble. As much as I want auditors accountable for unprofessional/illogical conduct (which does not yield “accurate results” anyway), I consider it critical to avoid putting auditors in the “a happy customer is a good customer with a happy audit” mentality because that leads to very bad places. The right place is somewhere between these extremes, but defining that location is quite difficult. Owen
On 14-05-01 14:34, Owen DeLong wrote:
Believe me, I cringe every time I hear “our auditors require NAT as a security mechanism”
Pardon my ignorance here. But in a carrier-grade NAT implementation that serves say 5000 users, when happens when someone from the outside tries to connect to port 80 of the shared routable IP ? you still need to have explicit port forwarding to specific LAN side hosts (like the web server) right ? Trying to be devil's advocate here: (and discussing only incoming calls) In a NAT setup for a company, wouldn't the concept be that you explicitely have to open a few ports to specific hosts ? (for instance 80 points to the web server LAN IP address) All the rest of the gazillion ports are blocked by default since the router doesn't know to which LAN host they should go. On the other hand, for a LAN with routable IPs, by default, all ports are routed to all computers, and security then depends on ACLs or other mechanisms to implement a firewall. Auditors probably prefer architecture where everything is blocked by default and you open specific ports compared to one where everything is open by default and you then add ACLs to implement security. (Not judging whether one is better, just trying to figure out why auditors might prefer NAT). Also, home routers have "NAT" which is really a combo of NAT with basic firewall, so if you don't have "NAT", they may equate this to not having a firewall.
On 5/1/2014 7:10 PM, Jean-Francois Mezei wrote:
Pardon my ignorance here. But in a carrier-grade NAT implementation that serves say 5000 users, when happens when someone from the outside tries to connect to port 80 of the shared routable IP ? you still need to have explicit port forwarding to specific LAN side hosts (like the web server) right ?
Trying to be devil's advocate here: (and discussing only incoming calls)
That's the problem with your devil. The first outgoing connection negates every protection you've assumed with one-to-many NAT. What you really need is a policy that says explicitly what traffic is permitted in each direction. established/new outbound is the problem in this scenario, not what internal addresses you use. On a secure server LAN, the ideal configuration for outbound would only allow connections to update servers you control, and acknowledgement traffic for protocols you are allowing inbound.
In a NAT setup for a company, wouldn't the concept be that you explicitely have to open a few ports to specific hosts ? (for instance 80 points to the web server LAN IP address) All the rest of the gazillion ports are blocked by default since the router doesn't know to which LAN host they should go.
On the other hand, for a LAN with routable IPs, by default, all ports are routed to all computers, and security then depends on ACLs or other mechanisms to implement a firewall.
Auditors probably prefer architecture where everything is blocked by default and you open specific ports compared to one where everything is open by default and you then add ACLs to implement security. Blocked by default or allowed by default are just concepts on a firewall. People make the mistake of thinking that allowed by default is the default, but that's only true of the underlying host OS, and only if that host OS isn't hardened.
Specifically, ip forwarding shouldn't be turned on until needed. Linux doesn't turn this on by default, so by default you don't permit routing no matter the source or destination IP addresses. The mistake that everyone is making is they think with NAT, secure rules are easier to write so getting the firewall online for the first time is easier, and maintaining it is easier. The problem with this statement is it's only true to a certain extent. If you care about whatever you're securing at a PCI/SOX level then NAT bought you nothing. You still need to write secure inbound and outbound rules. If whatever you're securing doesn't have to be that tightly controlled then NAT buys you a little, but it comes with a glaring false sense of security. I know at my office the IT department has dealt with several worm outbreaks that spread through email and then use the local LAN to send outbound port 25. I had to block port 25 outbound for the corporate network when it became apparent that IT was using "NAT is a firewall" as their security methodology.
(Not judging whether one is better, just trying to figure out why auditors might prefer NAT).
Also, home routers have "NAT" which is really a combo of NAT with basic firewall, so if you don't have "NAT", they may equate this to not having a firewall.
Auditors prefer NAT because everyone in the world understands security and computers on different levels. You don't know if you're getting an auditor that writes their own pen-test suites or just runs nessus and prints the results. They may have been trained by someone who developed the "intuitive" logical understanding that NAT systems fail-closed so they're better for defense in depth. The problem with this is, as stated above, it's not buying enough to be worth it and it causes a false sense of security. They may have even reached this conclusion themselves and it's hard to convince someone their ideas are wrong. Honestly they aren't even wrong, they're just picking a battle that shouldn't mean as much as they think it does. Ideally, your security group should have unit-tests or just a network monitoring process that nmaps from both directions. On inbound there are PCI compliance auditors that will do this for you regularly so that you can be assured the protection is still there. Outbound you need to be just as vigilant to make sure the rules are just as strict. Ultimately, things like CGNAT are completely ineffective for security because the outbound rules have to be wide open so people can use it.
On May 1, 2014, at 4:10 PM, Jean-Francois Mezei <jfmezei_nanog@vaxination.ca> wrote:
Pardon my ignorance here. But in a carrier-grade NAT implementation that serves say 5000 users, when happens when someone from the outside tries to connect to port 80 of the shared routable IP ?
More to the point, your trust boundary includes 5000 people. Do you know them all? Who maintains their systems and software? Do you trust them? What happens if they approach you from behind the NAT?
On Fri, May 2, 2014 11:57 am, Fred Baker (fred) wrote:
On May 1, 2014, at 4:10 PM, Jean-Francois Mezei <jfmezei_nanog@vaxination.ca> wrote:
Pardon my ignorance here. But in a carrier-grade NAT implementation that serves say 5000 users, when happens when someone from the outside tries to connect to port 80 of the shared routable IP ?
More to the point, your trust boundary includes 5000 people. Do you know them all? Who maintains their systems and software? Do you trust them?
What happens if they approach you from behind the NAT?
Strikes me as a red herring; CGNat is not shifting your security boundary, wheras the typical NAT device used on a shared IPv4 connection usually does.
On May 1, 2014, at 4:57 PM, Fred Baker (fred) <fred@cisco.com> wrote:
On May 1, 2014, at 4:10 PM, Jean-Francois Mezei <jfmezei_nanog@vaxination.ca> wrote:
Pardon my ignorance here. But in a carrier-grade NAT implementation that serves say 5000 users, when happens when someone from the outside tries to connect to port 80 of the shared routable IP ?
More to the point, your trust boundary includes 5000 people. Do you know them all? Who maintains their systems and software? Do you trust them?
What happens if they approach you from behind the NAT?
It’s unlikely that CGN changes this at all… Most CGN deployments will be a second layer of horror on top of the existing horrors already present. Owen
Hey, I worked for them (AA) in the early 90's =D ----- Alain Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 05/01/14 14:07, John Souter wrote:
The problem with this theory is that if auditors can be so easily put to the street, you run into the risk of auditors altering behavior to increase customer satisfaction in ways that prevent them from providing the controls that are the reason auditors exist in the first place. I disagree. And the power balance is generally tilted way in favour of
On 01/05/14 17:41, Owen DeLong wrote: the auditors, as many people on this thread have already commented. In my experience, most companies are afraid/inhibited to raise issues or challenge their auditors in any way. Nobody is asking auditors to roll over, but if their behaviour is unprofessional/illogical, then a short sharp shock should do the trick.
If you don’t believe me, examine the history of Arthur Anderson and their relationship with a certain Houston-based company which failed spectacularly. Can't really comment, but it was financial auditing, and ISTR that many things failed in that situation - not just financial auditing.
John
Care to comment on how you feel about the COI that developed between AA Consulting business at Enron and AA auditing Enron? Not asking you to disclose anything confidential, but if you have wisdom to impart about any sort of generic lessons learned, etc. that might be relevant to this discussion, I think that could be useful. Owen On May 1, 2014, at 12:56 PM, Alain Hebert <ahebert@pubnix.net> wrote:
Hey,
I worked for them (AA) in the early 90's =D
----- Alain Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443
On 05/01/14 14:07, John Souter wrote:
The problem with this theory is that if auditors can be so easily put to the street, you run into the risk of auditors altering behavior to increase customer satisfaction in ways that prevent them from providing the controls that are the reason auditors exist in the first place. I disagree. And the power balance is generally tilted way in favour of
On 01/05/14 17:41, Owen DeLong wrote: the auditors, as many people on this thread have already commented. In my experience, most companies are afraid/inhibited to raise issues or challenge their auditors in any way. Nobody is asking auditors to roll over, but if their behaviour is unprofessional/illogical, then a short sharp shock should do the trick.
If you don’t believe me, examine the history of Arthur Anderson and their relationship with a certain Houston-based company which failed spectacularly. Can't really comment, but it was financial auditing, and ISTR that many things failed in that situation - not just financial auditing.
John
Well, I was just a suit drone into one of their 100 little IT firm around the world. The nearest I got to an actual AA associate was during a 1 month project in Chicago (: Wasted my time really... They billed 3 months to their clients, for a project that took 1 month, and I was asked to fill the cubicle for 2 month doing nothing. ----- Alain Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 05/01/14 18:43, Owen DeLong wrote:
Care to comment on how you feel about the COI that developed between AA Consulting business at Enron and AA auditing Enron?
Not asking you to disclose anything confidential, but if you have wisdom to impart about any sort of generic lessons learned, etc. that might be relevant to this discussion, I think that could be useful.
Owen
On May 1, 2014, at 12:56 PM, Alain Hebert <ahebert@pubnix.net> wrote:
Hey,
I worked for them (AA) in the early 90's =D
----- Alain Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443
On 05/01/14 14:07, John Souter wrote:
The problem with this theory is that if auditors can be so easily put to the street, you run into the risk of auditors altering behavior to increase customer satisfaction in ways that prevent them from providing the controls that are the reason auditors exist in the first place. I disagree. And the power balance is generally tilted way in favour of
On 01/05/14 17:41, Owen DeLong wrote: the auditors, as many people on this thread have already commented. In my experience, most companies are afraid/inhibited to raise issues or challenge their auditors in any way. Nobody is asking auditors to roll over, but if their behaviour is unprofessional/illogical, then a short sharp shock should do the trick.
If you don’t believe me, examine the history of Arthur Anderson and their relationship with a certain Houston-based company which failed spectacularly. Can't really comment, but it was financial auditing, and ISTR that many things failed in that situation - not just financial auditing.
John
On Apr 29, 2014, at 7:54 PM, Jeff Kell <jeff-kell@utc.edu> wrote:
On 4/29/2014 2:06 PM, Owen DeLong wrote:
If everyone who had 30+ inaggregable IPv4 prefixes replaced them with 1 (or even 3) IPv6 prefixes…
As a bonus, we could get rid of NAT, too. ;-)
/me ducks (but you know I had to say it)
Yeah, just when we thought Slammer / Blaster / Nachi / Welchia / etc / etc had been eliminated by process of "can't get there from here"... we expose millions more endpoints...
/me ducks too (but you know *I* had to say it)
Pretending that endpoints are not exposed to those things with NAT is kind of like putting a screen door in front of a bank vault and saying “now safe from tornadoes”. Owen
Security is a layered approach though. I can't recall any server or service that runs in listening state (and reachable from public address space) that hasn't had some type of remotely exploitable vulnerability. It's hard to lean on operating systems and software companies to default services to off. When you run "netstat -a" on a lot of operating systems there are too many things in listening state without a convincing enough reason. NAT is stateful only out of necessity but after IPv6 a small layer of security will go away but there is potentially another alternative. Scanning blocks of IPv6 addresses for valid hosts is mostly a waste of time but you could do things like looking at server logs or getting IP addresses of clients you are connected with on P2P networks. A good way to prevent that is to assign multiple IPv6 addresses to operating systems as security "zones" so a source address a browser or P2P client would use is not the same one with potentially remotely exploitable services running in listening state. As a bonus they should probably take it one step further and just place web browsers and email clients in a dedicated VM sandbox that can be blown out and recreated in case of infection or persistent browser toolbars and stuff. So far malware seems to be winning the war so it might be best to just acknowledge that people are likely to be attacked successfully and attempt to quarantine it when it happens. It would probably be less intrusive than trying to force people into restricted user accounts so I never understood why nobody ever really pushed for this. Technical users have been running suspect code and links in VM's for a while now. On Wed, Apr 30, 2014 at 1:13 AM, Owen DeLong <owen@delong.com> wrote:
On Apr 29, 2014, at 7:54 PM, Jeff Kell <jeff-kell@utc.edu> wrote:
On 4/29/2014 2:06 PM, Owen DeLong wrote:
If everyone who had 30+ inaggregable IPv4 prefixes replaced them with 1 (or even 3) IPv6 prefixes…
As a bonus, we could get rid of NAT, too. ;-)
/me ducks (but you know I had to say it)
Yeah, just when we thought Slammer / Blaster / Nachi / Welchia / etc / etc had been eliminated by process of "can't get there from here"... we expose millions more endpoints...
/me ducks too (but you know *I* had to say it)
Pretending that endpoints are not exposed to those things with NAT is kind of like putting a screen door in front of a bank vault and saying “now safe from tornadoes”.
Owen
On 4/29/2014 10:54 PM, Jeff Kell wrote:
Yeah, just when we thought Slammer / Blaster / Nachi / Welchia / etc / etc had been eliminated by process of "can't get there from here"... we expose millions more endpoints...
/me ducks too (but you know *I* had to say it)
Slammer actually caused many firewalls to fall over due to high pps and having to track state. I thought about posting in the super-large anti-NAT/statefull firewall thread a few weeks ago but decided it wasn't worth it to stir up trouble. Here is some trivia though: Back when Slammer hit I was working for a major NSP. I had gotten late dinner with a friend and was at his work chatting with him since he worked the night shift by himself. It became apparent that something bad was wrong with the Internet. I decided to drive to my office and attempt to do what I could to fix the issues. This was a mistake. Because of corporate reasons, my office was in a different city from the POP I connected to. I was 3 hops away from our corporate firewall, one of which was a T1. We had access lists on all the routers preventing people from getting to them from the Internet, so I thought my office was the only place I could fix the issue. Well, someone had put a SQL server in front of or behind the firewall, somewhere where it would cause fun. That DOS'd the firewall. It took 3-4 hours of hacking things to get to the inside and outside routers and put an access-list blocking SQL. Once that was done the firewall instantly got better and I was able to push changes to every 7500 in the network blocking SQL on the uplink ports. This didn't stop it everywhere because we had 12000's in the core and they didn't support ACLs on most of the interfaces we had. The access lists had to stick around for at least 6 months while the Internet patched and cleaned things up. Fun fact: the office network I was using pre-dated RFC1918 so we were using public IPs. The software firewall that fell over either did so because statefull rules were included for SQL even when they weren't needed, or it died due to pure packets/sec. Regardless, all of the switching and routing hardware around it were fine. This isn't an argument against firewalls, I'm just saying that people tend to put stock in them even when they're just adding complexity. If you have access lists blocking everything the firewall would block then you might think having both gives you defense in depth, but what it also does is gives a second place where typos or human error might cause problems. It also gives a second point of failure and (if state synchronization and load-balance/failover are added) compounded complexity. It depends on the goals you're trying to achieve. Sometimes redundant duties performed by two different groups gives you piece of mind, sometimes it's just added frustration.
At 22:00 25/04/2014 +0000, cidr-report@potaroo.net wrote:
This report has been generated at Fri Apr 25 21:13:54 2014 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/2.0 for a current version of this report.
Recent Table History Date Prefixes CIDR Agg 18-04-14 499254 282312 19-04-14 499492 282427 20-04-14 499557 282428 21-04-14 499371 282193 22-04-14 499156 282325 23-04-14 499260 282597 24-04-14 499642 282663 25-04-14 500177 282878
Historic event - 500K prefixes on the Internet. -Hank
Op 26 apr. 2014, om 20:05 heeft Hank Nussbacher <hank@efes.iucc.ac.il> het volgende geschreven:
At 22:00 25/04/2014 +0000, cidr-report@potaroo.net wrote:
This report has been generated at Fri Apr 25 21:13:54 2014 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/2.0 for a current version of this report.
Recent Table History Date Prefixes CIDR Agg 18-04-14 499254 282312 19-04-14 499492 282427 20-04-14 499557 282428 21-04-14 499371 282193 22-04-14 499156 282325 23-04-14 499260 282597 24-04-14 499642 282663 25-04-14 500177 282878
Historic event - 500K prefixes on the Internet.
And now we wait for everything to fall over at 512k ;)
Historic event - 500K prefixes on the Internet.
And now we wait for everything to fall over at 512k ;)
Based on a quick plot graph on the CIDR report, it looks like we are adding 6,000 prefixes a month, or thereabouts. So platforms that break at 512K die in two months or less? Sup720s may need to be reconfigured/rebooted, etc. Does anyone have doomsday plots of IPv6 prefixes? We are already at something like 20,000 prefixes there, and a surprising number of deaggregates (like /64s) in the global table. IIRC, a bunch of platforms will fall over at 128K/256K IPv6 prefixes (but sooner, really, because of IPv4 dual stack). Best, Deepak
On 27 Apr 2014, at 5:19 am, Deepak Jain <deepak@ai.net> wrote:
Historic event - 500K prefixes on the Internet.
And now we wait for everything to fall over at 512k ;)
Based on a quick plot graph on the CIDR report, it looks like we are adding 6,000 prefixes a month, or thereabouts. So platforms that break at 512K die in two months or less? Sup720s may need to be reconfigured/rebooted, etc.
Does anyone have doomsday plots of IPv6 prefixes? We are already at something like 20,000 prefixes there, and a surprising number of deaggregates (like /64s) in the global table. IIRC, a bunch of platforms will fall over at 128K/256K IPv6 prefixes (but sooner, really, because of IPv4 dual stack).
Check out pages 30 and 34 of http://www.potaroo.net/presentations/2014-02-09-bgp2013.pdf - a presentation I gave on predictions of BGP table size at NANOG 60 in February of this year. Geoff
On Apr 26, 2014, at 12:19 PM, Deepak Jain <deepak@ai.net> wrote:
Does anyone have doomsday plots of IPv6 prefixes? We are already at something like 20,000 prefixes there, and a surprising number of deaggregates (like /64s) in the global table. IIRC, a bunch of platforms will fall over at 128K/256K IPv6 prefixes (but sooner, really, because of IPv4 dual stack).
A /64 deaggregte only makes it through because folks let it; there’s something to be said for filters. That said, one might generally expect every AS (there are about 60K or them, I gather) to have one prefix, and if it deaggregates, it might be reasonable to expect it to multiply by four. RIR online records suggest that someone that asks for additional addresses beyond their /32 is told to shorten the existing prefix, not allocated a new one - the same prefix becomes a /31 or whatever. The reason we have 500K+ IPv4 prefixes is because we hand them out in dribbles, and there is no correlation between the one you received last week and the one you receive today. Geoff’s slides are interesting in part because of their observations regarding deaggregates. If 1% of of all AS’s advertise over half of the deaggregates, that seems like a problem their neighbors can help with, and if not them, the neighbors' neighbors. It’s hard to imagine that a single Ethernet (a single /64) is so critical that the entire world needs a distinct route to it. In any event, I would not approach this as a statistical issue, and say “well, IPv4 grew in a certain way, and IPv6 will do the same”. It can. But we have had the opportunity to think ahead and plan for the growth, and the RIR communities have been planning. It seems likely that, with a little care, IPv6 should do quite a bit better.
participants (28)
-
Alain Hebert -
Andy Davidson -
Blake Dunlap -
Charles Gucker -
Chris Boyd -
cidr-report＠potaroo.net -
Deepak Jain -
Fred Baker (fred) -
Geoff Huston -
Hank Nussbacher -
Jamie Bowden -
Jean-Francois Mezei -
Jeff Kell -
joel jaeggli -
John Souter -
Jérôme Nicolle -
Kate Gerry -
Mark Foster -
ML -
Owen DeLong -
Patrick W. Gilmore -
Paul S. -
Rick Astley -
Robert Drake -
Seth Mos -
Sholes, Joshua -
TheIpv6guy . -
Valdis.Kletnieks＠vt.edu