- Test - lists.nanog.org

Weekly Routing Table Report
by cscora＠apnic.net 07 Jul '17

07 Jul '17

This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats(a)lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith <pfsinoz(a)gmail.com>. Routing Table Report 04:00 +10GMT Sat 08 Jul, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 653872 Prefixes after maximum aggregation (per Origin AS): 254333 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 315298 Total ASes present in the Internet Routing Table: 57740 Prefixes per ASN: 11.32 Origin-only ASes present in the Internet Routing Table: 49962 Origin ASes announcing only one prefix: 22072 Transit ASes present in the Internet Routing Table: 7778 Transit-only ASes present in the Internet Routing Table: 223 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 54 Max AS path prepend of ASN ( 55644) 51 Prefixes from unregistered ASNs in the Routing Table: 60 Numnber of instances of unregistered ASNs: 64 Number of 32-bit ASNs allocated by the RIRs: 19359 Number of 32-bit ASNs visible in the Routing Table: 15061 Prefixes from 32-bit ASNs in the Routing Table: 61319 Number of bogon 32-bit ASNs visible in the Routing Table: 64 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 349 Number of addresses announced to Internet: 2848140388 Equivalent to 169 /8s, 195 /16s and 44 /24s Percentage of available address space announced: 76.9 Percentage of allocated address space announced: 76.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.7 Total number of prefixes smaller than registry allocations: 217691 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 179377 Total APNIC prefixes after maximum aggregation: 51366 APNIC Deaggregation factor: 3.49 Prefixes being announced from the APNIC address blocks: 178434 Unique aggregates announced from the APNIC address blocks: 73877 APNIC Region origin ASes present in the Internet Routing Table: 8227 APNIC Prefixes per ASN: 21.69 APNIC Region origin ASes announcing only one prefix: 2309 APNIC Region transit ASes present in the Internet Routing Table: 1163 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 54 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3071 Number of APNIC addresses announced to Internet: 763514212 Equivalent to 45 /8s, 130 /16s and 77 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 199057 Total ARIN prefixes after maximum aggregation: 94804 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 201014 Unique aggregates announced from the ARIN address blocks: 92372 ARIN Region origin ASes present in the Internet Routing Table: 17915 ARIN Prefixes per ASN: 11.22 ARIN Region origin ASes announcing only one prefix: 6631 ARIN Region transit ASes present in the Internet Routing Table: 1765 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2073 Number of ARIN addresses announced to Internet: 1108484768 Equivalent to 66 /8s, 18 /16s and 34 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 175353 Total RIPE prefixes after maximum aggregation: 85837 RIPE Deaggregation factor: 2.04 Prefixes being announced from the RIPE address blocks: 171163 Unique aggregates announced from the RIPE address blocks: 102995 RIPE Region origin ASes present in the Internet Routing Table: 24179 RIPE Prefixes per ASN: 7.08 RIPE Region origin ASes announcing only one prefix: 11138 RIPE Region transit ASes present in the Internet Routing Table: 3406 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5978 Number of RIPE addresses announced to Internet: 712318592 Equivalent to 42 /8s, 117 /16s and 30 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 83011 Total LACNIC prefixes after maximum aggregation: 18472 LACNIC Deaggregation factor: 4.49 Prefixes being announced from the LACNIC address blocks: 84275 Unique aggregates announced from the LACNIC address blocks: 38801 LACNIC Region origin ASes present in the Internet Routing Table: 6112 LACNIC Prefixes per ASN: 13.79 LACNIC Region origin ASes announcing only one prefix: 1664 LACNIC Region transit ASes present in the Internet Routing Table: 1140 Average LACNIC Region AS path length visible: 5.4 Max LACNIC Region AS path length visible: 27 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3620 Number of LACNIC addresses announced to Internet: 170696160 Equivalent to 10 /8s, 44 /16s and 157 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 16966 Total AfriNIC prefixes after maximum aggregation: 3800 AfriNIC Deaggregation factor: 4.46 Prefixes being announced from the AfriNIC address blocks: 18637 Unique aggregates announced from the AfriNIC address blocks: 6939 AfriNIC Region origin ASes present in the Internet Routing Table: 1052 AfriNIC Prefixes per ASN: 17.72 AfriNIC Region origin ASes announcing only one prefix: 329 AfriNIC Region transit ASes present in the Internet Routing Table: 208 Average AfriNIC Region AS path length visible: 4.9 Max AfriNIC Region AS path length visible: 28 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 319 Number of AfriNIC addresses announced to Internet: 92717568 Equivalent to 5 /8s, 134 /16s and 194 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5550 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3982 406 383 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2976 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2809 11134 754 KIXS-AS-KR Korea Telecom, KR 9829 2744 1499 540 BSNL-NIB National Internet Backbone, IN 9808 2167 8699 32 CMNET-GD Guangdong Mobile Communication 4755 2089 422 222 TATACOMM-AS TATA Communications formerl 45899 2053 1424 111 VNPT-AS-VN VNPT Corp, VN 7552 1639 1104 73 VIETEL-AS-AP Viettel Corporation, VN 9498 1598 361 141 BBIL-AP BHARTI Airtel Ltd., IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3817 2953 160 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3423 1333 83 SHAW - Shaw Communications Inc., CA 18566 2179 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2064 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 2011 2172 418 CHARTER-NET-HKY-NC - Charter Communicat 209 1825 5067 640 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1823 3697 591 AMAZON-02 - Amazon.com, Inc., US 30036 1805 326 297 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1695 854 231 ITCDELTA - Earthlink, Inc., US 701 1561 10559 630 UUNET - MCI Communications Services, In Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3388 190 24 ALJAWWALSTC-AS, SA 8551 2974 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2908 962 2093 AKAMAI-ASN1, US 34984 2015 329 410 TELLCOM-AS, TR 9121 1930 1691 17 TTNET, TR 12479 1605 1044 53 UNI2-AS, ES 13188 1603 100 55 TRIOLAN, UA 12389 1521 1408 626 ROSTELECOM-AS, RU 6849 1225 355 21 UKRTELNET, UA 8402 1093 544 15 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3532 543 205 Telmex Colombia S.A., CO 8151 2472 3404 572 Uninet S.A. de C.V., MX 11830 2090 369 57 Instituto Costarricense de Electricidad 7303 1552 1012 243 Telecom Argentina S.A., AR 6503 1538 437 53 Axtel, S.A.B. de C.V., MX 6147 1296 377 27 Telefonica del Peru S.A.A., PE 3816 1026 501 94 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 968 2301 177 CLARO S.A., BR 11172 915 126 82 Alestra, S. de R.L. de C.V., MX 18881 896 1052 23 TELEFÔNICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1237 398 51 LINKdotNET-AS, EG 37611 724 91 8 Afrihost, ZA 36903 711 357 129 MT-MPLS, MA 36992 644 1375 26 ETISALAT-MISR, EG 24835 478 786 17 RAYA-AS, EG 37492 407 320 75 ORANGE-, TN 29571 401 36 10 CITelecom-AS, CI 15399 348 35 7 WANANCHI-, KE 8452 327 1730 17 TE-AS TE-AS, EG 2018 304 327 74 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5550 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3982 406 383 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3817 2953 160 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3532 543 205 Telmex Colombia S.A., CO 6327 3423 1333 83 SHAW - Shaw Communications Inc., CA 39891 3388 190 24 ALJAWWALSTC-AS, SA 17974 2976 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 8551 2974 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2908 962 2093 AKAMAI-ASN1, US 4766 2809 11134 754 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3817 3657 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3982 3599 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3388 3364 ALJAWWALSTC-AS, SA 6327 3423 3340 SHAW - Shaw Communications Inc., CA 10620 3532 3327 Telmex Colombia S.A., CO 8551 2974 2934 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 17974 2976 2903 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9829 2744 2204 BSNL-NIB National Internet Backbone, IN 9808 2167 2135 CMNET-GD Guangdong Mobile Communication Co.Ltd. 18566 2179 2070 MEGAPATH5-US - MegaPath Corporation, US Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 64525 PRIVATE 45.119.143.0/24 133275 GIGANTIC-AS Gigantic Infotel P 64525 PRIVATE 45.125.62.0/24 133275 GIGANTIC-AS Gigantic Infotel P 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 65534 PRIVATE 58.68.109.0/24 10201 DWL-AS-IN Dishnet Wireless Lim 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 65538 DOCUMENT 64.27.253.0/24 1273 CW Vodafone Group PLC, GB 65346 PRIVATE 94.50.36.0/22 31094 TTKNET Tyumen, Russia, RU 64111 UNALLOCATED 98.159.5.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64111 UNALLOCATED 98.159.7.0/24 19555 KMI-NETWORK - Kinder Morgan, I Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.48.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.49.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.50.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.51.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/24 64091 UNKNOWN 41.76.232.0/21 62878 XLITT - Xlitt, US 41.77.248.0/21 62878 XLITT - Xlitt, US 41.78.12.0/23 62878 XLITT - Xlitt, US 41.78.180.0/23 37265 -Reserved AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:15 /9:13 /10:36 /11:104 /12:280 /13:545 /14:1047 /15:1847 /16:13467 /17:7640 /18:13422 /19:24664 /20:38616 /21:41255 /22:77663 /23:64411 /24:366633 /25:864 /26:607 /27:642 /28:34 /29:22 /30:17 /31:2 /32:26 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3224 3423 SHAW - Shaw Communications Inc., CA 22773 2979 3817 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 39891 2946 3388 ALJAWWALSTC-AS, SA 8551 2439 2974 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2072 2179 MEGAPATH5-US - MegaPath Corporation, US 30036 1595 1805 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 11830 1480 2090 Instituto Costarricense de Electricidad y Telec 10620 1469 3532 Telmex Colombia S.A., CO 11492 1390 1541 CABLEONE - CABLE ONE, INC., US 6389 1371 2064 BELLSOUTH-NET-BLK - BellSouth.net Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1603 2:803 4:18 5:2435 6:34 8:1045 12:1833 13:123 14:1737 15:28 16:2 17:159 18:90 20:61 23:2395 24:1881 25:2 27:2459 31:1928 32:84 33:13 35:21 36:386 37:2349 38:1313 39:64 40:98 41:2947 42:472 43:1943 44:73 45:2892 46:2802 47:157 49:1239 50:987 51:19 52:833 54:364 55:6 56:4 57:42 58:1573 59:1053 60:388 61:1959 62:1601 63:1914 64:4602 65:2223 66:4547 67:2262 68:1238 69:3373 70:1150 71:586 72:2224 74:2684 75:388 76:426 77:1536 78:1436 79:2387 80:1401 81:1385 82:1002 83:723 84:932 85:1745 86:482 87:1165 88:754 89:2114 90:175 91:6199 92:977 93:2368 94:2383 95:2699 96:625 97:353 98:1062 99:86 100:154 101:1193 103:15324 104:2983 105:178 106:510 107:1719 108:823 109:2874 110:1453 111:1730 112:1198 113:1254 114:1036 115:1723 116:1792 117:1710 118:2198 119:1611 120:1055 121:1113 122:2259 123:1815 124:1482 125:1902 128:782 129:662 130:434 131:1428 132:526 133:199 134:659 135:223 136:448 137:435 138:1953 139:490 140:398 141:606 142:767 143:900 144:792 145:179 146:1046 147:694 148:1459 149:583 150:711 151:973 152:695 153:304 154:767 155:759 156:613 157:655 158:462 159:1522 160:694 161:740 162:2520 163:530 164:806 165:1396 166:380 167:1253 168:2988 169:821 170:3419 171:319 172:1022 173:1951 174:811 175:748 176:1870 177:4135 178:2529 179:1162 180:2203 181:1903 182:2361 183:996 184:862 185:10052 186:3254 187:2195 188:2602 189:1794 190:8296 191:1365 192:9506 193:5772 194:4684 195:3923 196:2081 197:1267 198:5503 199:5897 200:7430 201:4335 202:10333 203:9996 204:4479 205:2807 206:3014 207:3136 208:3972 209:3989 210:4015 211:2145 212:2844 213:2512 214:869 215:66 216:5800 217:2113 218:864 219:599 220:1694 221:932 222:762 223:1180 End of report

1 0

Heads-up: RFC 8212 on default EBGP route handling behavior
by Job Snijders 06 Jul '17

06 Jul '17

Dear NANOG, After a bit of tug-of-war common sense prevailed and RFC 8212 "External BGP (EBGP) Route Propagation Behavior without Policies" was published: https://tools.ietf.org/html/rfc8212 This industry has a long history of improving default behavior: DEC MOP is no longer enabled by default, telnet was swapped out in favor of SSH, and SHA-1 is now deprecated, so I'm confident we can manage this one too. TL;DR This mail offers advice on test scenarios to add to your evaluation checklist and a call to action to ask your vendor to implement RFC 8212. Please share this message with other communities. Background ---------- Prior to RFC 8212, the default behavior of BGP implementations (when no policy is configured on an EBGP session) was undefined, this resulted in a myriad of vendor defaults: some implementations not accepting routes and not advertising anything; some would accept anything, but announce nothing; some would announce only internal routes and accept anything; and some would indiscriminately accept everything and announce everything. The latter mode of operation is of course the most harmful one. An example minimal configuration: ! router bgp 15562 neighbor 192.0.2.1 remote-as 174 neighbor 192.0.2.5 remote-as 2914 ! Most of us have learned (the hard way) that on many platforms the above configuration will not only bring up two BGP sessions, but also immediately result in a "Lateral ISP-ISP-ISP Leak" [2], simply because no routing policy was associated with these EBGP sessions and an implicit 'permit-any' is assumed. The above configuration is of course an oversimplification of what happens in real life: operators may attempt to change a BGP peer to a peer-group which has missing configuration, or a copy+paste of a snippet of configuration only partially succeeds, or in an attempt to debug a BGP session some configuration is removed without realizing the full ramifications of doing so (until you see smoke coming off the circuit ;-). RFC 8212 updates the core BGP specification (RFC 4271) to specify that the above behavior is _incorrect_, and an implicit deny-all must be associated with the EBGP session. In other words: "fail closed" rather then "fail open and oops you tripped max-prefix all over the place (or worse [3])". The document purposefully does not cover IBGP, nor does it proscribe what the contents of configured policy on EBGP sessions should be. If an operator explicitly configures a 'permit-any' style policy, that is perfectly fine, it was a conscious choice to do so. Evaluation checklist -------------------- Going forward when you evaluate a BGP implementation or a new software release, it is advisable to take note of the default behavior of that specific release. As vendors come into compliance with RFC 8212 it may be beneficial to track this. I also strongly recommend to audit your network configurations for instances which depend on implicit 'permit-any' behavior and reconfigure those instances to be an explicit 'permit-any'. This way software upgrades are less likely to cause surprises, and as a bonus the readability of the device's configuration is improved! Call to action -------------- Some vendors will need encouragement to take their implementation from EBGP "fail open" to "fail closed", we are keeping track of the industry's current state of affairs here: https://github.com/bgp/RFC8212 Please contact your account management team and express your interest in them supporting RFC 8212. Also, make sure to include RFC 8212 in your next round of "Request for Proposals" (RFPs) as a 'must have'. Purchasing usually is an excellent opportunity to have meaningful dialogue with the vendor. Some vendors may argue "but our customers depend on our unsafe behavior!", but this only holds true if we don't speak up collectively and show them otherwise. EBGP is an internet-wide shared resource, we all benefit from sane defaults. Hat tip to Jared Mauch for initiating this project and to Greg Hankins for demonstrating change is possible [4]. Kind regards, Job [1]: https://mailarchive.ietf.org/arch/msg/idr/mqPltvvgEhpxBgAXET1y1Xow6t8 [2]: https://tools.ietf.org/html/rfc7908#section-3.2 [3]: https://bgpmon.net/massive-route-leak-cause-internet-slowdown/ [4]: https://mailarchive.ietf.org/arch/msg/idr/kgl6etbjUuR3jLHVeDSi4LLIs50

1 0

Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"?
by Josh Reynolds 06 Jul '17

06 Jul '17

- Josh On Jul 3, 2017 7:23 PM, "Josh Reynolds" <josh(a)kyneticwifi.com> wrote: > Specs... > > > - MIPS64 16 Core 1.8 GHz > - 16 GB DDR4 RAM > - 8 MB NOR Flash 4 GB eMMC NAND Flash > - Data Ports: (1) RJ45 Serial Port, (8) SFP+ Ports (1) RJ45 Gigabit > Ethernet Port > - 2 hotswap power supplies > > > No LACP. ECMP is currently broken. MPLS/VPLS is currently broken and not > done in hardware - this may eventually change. As far as the other stuff, > "telemetry" etc - no. > > As far as BGP crunching, plenty of routes, etc - it would easily and > happily be fine with that. > > As far as automation, it's a JunOS-like CLI originally based on vyatta, > which AT&T now owns - and one of the main reasons is it's scriptability, > use of Ansible and other tools right on the device, python, etc. > > - Josh > > On Jul 3, 2017 2:09 PM, "Job Snijders" <job(a)instituut.net> wrote: > >> Dear NANOG, >> >> Some friends of mine are operating a nonprofit (on shoe string) and >> looking >> to connect some CDN caches to an IX fabric. A BGP speaking device is >> needed >> between the caches and the BGP peers connected to the fabric. The BGP >> speaker is needed to present the peers on the IX with a unified view of >> the >> assemblage of CDN nodes. >> >> I was wondering whether anyone was experience with the "EdgeRouter >> Infinity >> XG" device, specifically in the role of a simple peering router for a >> couple of tens of thousands of routes. (I'd point default to the left and >> take just the on-net routes on the right to reduce the table size >> requirement). >> >> I hope the device can do at least 2xLACP trunks, has a sizable FIB, is >> automatable (supports idempotency), can forward IMIX at line-rate, *flow, >> and exposes some telemetry via SNMP. >> >> Any note sharing would be appreciated! >> >> Kind regards, >> >> Job >> >

4 5

Sign onto EFF's comment to the FCC on their net neutrality proposal
by Erica Portnoy 05 Jul '17

05 Jul '17

Dear colleagues, As many of you know, the FCC is currently engaging in the process of repealing its network neutrality rules and eliminating its Title II authority over broadband providers. I'm writing you today to ask you to sign on to a letter that EFF has prepared for filing, which explains several key engineering concepts that are vital to understanding how the Internet actually operates given that the FCC's own findings misinterpret how the Internet works. The letter stays away from legal arguments, and instead focuses on technical statements on the design and operation of the Internet. It is meant to establish a factual record for the FCC about the Internet and it is necessary because its initial findings in its Notice of Proposed Rulemaking <https://apps.fcc.gov/edocs_public/attachmatch/DOC-344614A1.pdf> are just wrong. For one, the FCC thinks that broadband Internet providers are the ones providing end users with the services of the entire Internet, from search engines to online newspapers to language translation tools. /*If you're willing to sign on and help, please email engineers-nn-comments(a)eff.org (off-list) by Friday, July 14 */and I will be happy to share a copy of the letter for you to review before you agree to sign on. The more signatures we can get, the more likely the FCC is to take notice as well as the courts should they move forward. All it takes is an email. Please help us make sure the FCC gets the facts from an engineer's standpoint. Thank you for your support, Erica Portnoy Staff Technologist Electronic Frontier Foundation

1 0

Armstrong Cable Services/AS27364 networking contact needed
by Darrin Veit 05 Jul '17

05 Jul '17

I'm hoping to find a networking contact at Armstrong that can ping me off list. We're investigating connectivity issues for some Armstrong customers when they are trying to connect to servers in AS8075. Thanks! -Darrin Veit, Xbox Platform Networking dveit(a)microsoft.com

1 0

Big Spam Burst
by Jay R. Ashworth 05 Jul '17

05 Jul '17

Am I the only person who got a big burst of spam -- 30 or 40 in about 5 minutes -- on Sunday night, from France? All forged with NANOG participant From names? I'm pretty sure Steve Bellovin and Rob Seastrom aren't sending me spam. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

1 0

Call For Presentations - DNS-OARC Workshop 27, San Jose, CA, USA, 29-30 September 2017
by Jacques Latour 05 Jul '17

05 Jul '17

[with apologies to those who see this on multiple lists] Call For Presentations The DNS-OARC 27th Workshop will take place in San Jose, CA, USA on September 29th and 30th 2017, the Friday and Saturday preceding NANOG 71. The Workshop's Program Committee is now requesting proposals for presentations. All DNS-related subjects are welcome. If you are an OARC member, and have a sensitive topic you would like to present for members-only, we can accommodate those talks during the Members Only session on the morning of September 29th. A timeslot will also be available for lightning talks (5-10 minutes) on Saturday September 30th, for which submissions will be accepted during Friday 29th. Workshop Milestones: 26 May 2017, Call for Presentations posted and open for submissions 28 July 2017, Deadline for submission 11 August 2017, Draft Programme published 01 September 2017, Final Program published 15 September 2017, Final deadline for slideset submission Details for presentation submission will be published here: https://indico.dns-oarc.net/event/27/call-for-abstracts/ The workshop presentations will be organized by common themes, depending on the topics and the timing of each presentation. There are 30-minute and 15-minute slots, let us know your preference in your submission. To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via <submissions(a)dns-oarc.net> Ray Bellis, for the OARC Programme Committee OARC depends on sponorship to fund its workshops and associated social events. Please contact <sponsor(a)dns-oarc.net> if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.)

1 1

Call for presentations EPF12, 18th - 20th September, Lisbon sent to NANOG
by Arnold Nipper 05 Jul '17

05 Jul '17

Dear all, AMS-IX, DE-CIX, LINX, Netnod are happy to host the 12th European Peering Forum (EPF) in Lisbon, Portugal from the 18th - 20st September 2017. The event will welcome up to 300 peering managers and coordinators from networks connected to the host Internet exchanges. Besides an interesting topical agenda, the three-day event accommodates room for attendees to meet on a one-to-one basis to discuss bilateral peering business opportunities. The programme committee will be looking for presentations and lightning talks related to peering and technical topics of interconnection. Your presentation should address * Interconnection Automation * Regional Peering * Interconnection and Peering Internet Governance and Regulatory TopicS * Economic and Product Trends * Peering/Interconnection Strategy * Interesting findings about peering * 100GE and beyond Submissions =========== Presentations must be of a non-commercial nature. Product or marketing heavy talks are strongly discouraged. Submissions of presentations should be made to the programme committee <epf-pc(a)peering-forum.eu>. Please include: * Author's name and e-mail * Presentation title * Abstract * Slides (if available) * Time requested Deadlines ========= Presentation Abstract Deadline 17/07/2017 12:00 UTC Final Selection of Speakers 28/07/2017 Presentation Slides Submission Deadline 04/09/2017 12:00 UTC More information about the event and other activities around EPF12 may be found at https://peering-forum.eu/ Best regards, Arnold On behalf of the EPF hosts -- Arnold Nipper email: arnold(a)nipper.de mobile: +49 172 2650958

1 1

Call for presentations RIPE 75 and DCTM info
by Benno Overeinder 03 Jul '17

03 Jul '17

Dear colleagues, Please find the CFP for RIPE 75 below or at: https://ripe75.ripe.net/submit-topic/cfp/. The deadline for submissions is *20 August 2017*. Note: due to UAE law, confirmed speakers will need to submit a copy of their passport and contact information in advance of the meeting. More details are available here: https://ripe75.ripe.net/attend/dctm-requirements Kind regards, Benno Overeinder RIPE PC Chair https://ripe75.ripe.net/ripe-pc/ -------------------->>><<<-------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 75 will take place from 22-26 October in Dubai, UAE. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 75. See the full descriptions of the different presentation formats, https://ripe75.ripe.net/submit-topic/presentation-formats/. Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than *20 August 2017*. Proposals submitted after this date will be considered depending on the remaining available space in the programme. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange - Connected Things (aka. Internet of Things - IoT) Speakers Due to UAE law, confirmed speakers will need to submit a copy of their passport and contact information in advance of the meeting. More details are available here: https://ripe75.ripe.net/attend/dctm-requirements Please also note that speakers do not receive any discount or funding towards the meeting fee at RIPE Meetings. Submissions RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. Presenters should indicate how much time they will require. In general, the time allocated for the different presentation formats is as follows: - Plenary presentations: 20-25 minutes presentation with 5-10 minutes discussion - Tutorials: up to two hours (Monday morning) - Workshops: one hour (during evening sessions) to two hours (Monday morning) - BoFs: approximately one hour - Lightning talks: 10 minutes total for both presentation and any discussion The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe75.ripe.net/submit-topic/ - Lightning talks should also be submitted using the meeting submission system (https://ripe75.ripe.net/submit-topic/) and can be submitted any time up to and including the meeting week. The allocation of lightning talks will be announced on short notice, in some cases on the same day but often one day prior to the time slot allocated. - Presenters who propose a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. - All presentation proposals will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/

1 0

IPv4 Hijacking For Idiots
by Ronald F. Guilmette 03 Jul '17

03 Jul '17

The more I know, the less I understand. Maybe some of you kind folks can help. Please explain for me the following scenario, and how this all actually works in practice. Let's say that you're a malevolent Bad Actor and all you want to do is to get hold of some ASN that nobody is watching too closely, and then use that to announce some routes to some IPv4 space that nobody is watching too closely, so that you can then parcel out that IP space to your snowshoe spammer pals... at least until somebody gets wise. OK, so you pull down a copy of, say, the RIPE WHOIS database, and you programatically walk your way through it, looking for contact email addresses on ASN records where the domain of the contact email address has become unregistered. Say for example the one for AS34991. So then you re-register that contact domain, fresh, and then you start telling all of your friends and enemies that you -are- AS34991. That part seems simple enough, and indeed, I've seen -this- part of the movie several times before. However once you have stepped into the identity of the former owners of the ASN, if you then want to actually proceed to -announce- some routes, and actually ave those routes make it out onto the Internet generally, then you still have to -peer- with somebody, right? So, I guess then, if you're clever, you look and see who the ASN you've just successfully hijacked has historically peered with, and then you somehow arrange to send route announcements to those guys, right? (I'm talking about AS206776 and AS57344 here, BTW.) But see, this is where I get lost. I mean how do you push your route announcements to these guys? (I don't actually know that much about how BGP actually works in practice, so please bear with me.) How do you know what IP address to send your announcements to? And if you are going to push your route announcements out to, say, the specific routers that are run by AS206776 and AS57344, i.e. the ones that will send your desired route announcements out to the rest of the Internet... well.. how do you find out the IP addresses of those routers on those other networks? Do you call up the NOCs at those other networks and do a bit of social engineering on them to find out the IP addresses you need to send to? And can you just send BGP messages to the routers on those other networks without -any- authentication or anything and have those routers just blindly accept them -and- relay them on to the whole rest of the Internet?? I've read article after article after article bemoanging the fact that "BGP isn't secure", but now I'm starting to wonder just how massively and unbelieveably unsecure it actually is. I mean would these routers being run by AS206776 and AS57344 just blindly accept -any- route announcements sent to them from literally -any- IP address? (That seems positively looney tunes to me! I mean things can't really be THAT colossally and unbelievably stupid, can they?) Thanks in advance for any enlightenment. Regards, rfg P.S. It would appear to be the case that since some time in April of this year the "Bulgarian" network, AS34991, had evinced a rather sudden and pronounced affinity for various portion of the IPv4 address space nominally associated with the nation of Columbia, including at least five /24 blocks within 168.176.0.0/16 which, from where I am sitting, would appear to belong to the National University of Columbia. Oh well. They apparently haven't been missing those five gaping holes in their /16 since the time the more specifics started showing up in April. And anyway, so far it looks like the new owners of AS34991 haven't actually sub-leased any of those /24s to any spammers yet. Only the 190.90.88.0/24 block seems to be filled, wall-to-all, with snowshoe spammers so far.

13 26