- NANOG - lists.nanog.org

how many bits of entropy do we need for load balancing?
by Pascal Thubert (pthubert) 14 Dec '20

14 Dec '20

Dear all: How many bits of entropy do we need for (ECMP) load balancing in the core? This question has kept coming up regularly in many discussions and drafts at the IETF. The IPv6 flow label is 20 bits but hardware implementations do their balancing only on a subset of that, e.g. 12 or 16 bits. There are drafts for MPLS, BIER etc.. that provide their own entropy bit fields of various sizes. I traced to a 6MAN discussion at IETF 78 a claim that 10 or 11 bits were enough. Did someone do the actual exercise? It would be neat to align the IETF specs in the making to whatever truth may be established in the core. Keep safe, Pascal

2 1

Spectrum / TimeWarner contact
by Jared Geiger 14 Dec '20

14 Dec '20

I think Spectrum / Timewarner AS 7843 is dampening one of my routes 199.19.120.0/22. Can someone contact me to help diagnose the issue? We're not a customer traffic leaving Timewarner doesn't make it off the network and I'm unable to trace into the timewarner network. To TW mtr --report 209.18.47.61 HOST: opensips-dsw01.rtc.vocaltra Loss% Snt Last Avg Best Wrst StDev 1. rtr.rtc.vocaltransit.net 0.0% 10 0.2 0.2 0.2 0.3 0.0 2. 216.193.212.89 0.0% 10 0.6 2.4 0.6 8.3 2.8 3. ae12.cr1-was1.ip4.gtt.net 0.0% 10 1.0 1.2 0.9 1.7 0.3 4. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 >From TW mtr --report 199.19.120.1 Start: Mon Dec 14 17:24:57 2020 HOST: rtr-sunvalley Loss% Snt Last Avg Best Wrst StDev 1.|-- 142.254.236.5 0.0% 10 10.0 8.8 7.7 10.0 0.5 2.|-- agg56.vnnzca2402h.socal.r 0.0% 10 13.2 10.4 9.6 13.2 1.0 3.|-- 72.129.14.86 0.0% 10 15.9 14.1 10.3 17.7 2.2 4.|-- ??? 100.0 10 0.0 0.0 0.0 0.0

1 1

Changing DNS host records
by Matthew Crocker 12 Dec '20

12 Dec '20

Hello It has been over a decade since I’ve done this and need some help refreshing my memory. I have many customers that have registered their domains against my authoritative servers (DNS-AUTH3.CROCKER.COM) I need to move that machine to a different network/IP address. I’ve made the updates in my domain (crocker.com) but I think I also need to update the host glue records in the gtld-servers as well. How do I go about doing that? Ultimately the customers need to update their registration with our new authoritative servers, many have but we still have some stragglers I don’t want to break when I shutdown the old servers. Thanks -Matt

5 4

The Real AI Threat?
by Miles Fidelman 11 Dec '20

11 Dec '20

Hi Folks, It occurs to me that network & systems admins are the the folks who really have to worry about AI threats. After watching yet another AI takes over the world show - you know, the same general theme, AI wipes out humans to preserve its existence - it occurred to me: Perhaps the real AI threat is "self-healing systems" gone wild. Consider: - automated system management - automated load management - automated resource management - spin up more instances of <whatever> as necessary - automated threat detection & response - automated vulnerability analysis & response Put them together, and the nightmare scenario is: - machine learning algorithm detects need for more resources - machine learning algorithm makes use of vulnerability analysis library to find other systems with resources to spare, and starts attaching those resources - unbounded demand for more resources Kind of what spambots have done to the global email system. "For Homo Sapiens, the telephone bell had tolled." (Dial F for Frankenstein, Arthur C. Clarke) I think I need to start putting whisky in my morning coffee. And maybe not thinking about NOT replacing third shift with AI tools. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. In our lab, theory and practice are combined: nothing works and no one knows why. ... unknown

12 22

Weekly Routing Table Report
by cscora＠apnic.net 11 Dec '20

11 Dec '20

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, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG 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 12 Dec, 2020 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 833024 Prefixes after maximum aggregation (per Origin AS): 319019 Deaggregation factor: 2.61 Unique aggregates announced (without unneeded subnets): 399101 Total ASes present in the Internet Routing Table: 70094 Prefixes per ASN: 11.88 Origin-only ASes present in the Internet Routing Table: 60270 Origin ASes announcing only one prefix: 24923 Transit ASes present in the Internet Routing Table: 9824 Transit-only ASes present in the Internet Routing Table: 286 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 40 Max AS path prepend of ASN ( 22394) 36 Prefixes from unregistered ASNs in the Routing Table: 1079 Number of instances of unregistered ASNs: 1080 Number of 32-bit ASNs allocated by the RIRs: 34384 Number of 32-bit ASNs visible in the Routing Table: 28526 Prefixes from 32-bit ASNs in the Routing Table: 130841 Number of bogon 32-bit ASNs visible in the Routing Table: 18 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 531 Number of addresses announced to Internet: 2864277120 Equivalent to 170 /8s, 185 /16s and 102 /24s Percentage of available address space announced: 77.4 Percentage of allocated address space announced: 77.4 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.5 Total number of prefixes smaller than registry allocations: 283782 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 217228 Total APNIC prefixes after maximum aggregation: 64069 APNIC Deaggregation factor: 3.39 Prefixes being announced from the APNIC address blocks: 213269 Unique aggregates announced from the APNIC address blocks: 87397 APNIC Region origin ASes present in the Internet Routing Table: 11101 APNIC Prefixes per ASN: 19.21 APNIC Region origin ASes announcing only one prefix: 3153 APNIC Region transit ASes present in the Internet Routing Table: 1603 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 34 Number of APNIC region 32-bit ASNs visible in the Routing Table: 6224 Number of APNIC addresses announced to Internet: 778323968 Equivalent to 46 /8s, 100 /16s and 72 /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-143673 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: 240688 Total ARIN prefixes after maximum aggregation: 111288 ARIN Deaggregation factor: 2.16 Prefixes being announced from the ARIN address blocks: 240949 Unique aggregates announced from the ARIN address blocks: 115360 ARIN Region origin ASes present in the Internet Routing Table: 18690 ARIN Prefixes per ASN: 12.89 ARIN Region origin ASes announcing only one prefix: 6809 ARIN Region transit ASes present in the Internet Routing Table: 1913 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 40 Number of ARIN region 32-bit ASNs visible in the Routing Table: 3604 Number of ARIN addresses announced to Internet: 1093117952 Equivalent to 65 /8s, 39 /16s and 168 /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-401308 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, 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: 237159 Total RIPE prefixes after maximum aggregation: 111900 RIPE Deaggregation factor: 2.12 Prefixes being announced from the RIPE address blocks: 233076 Unique aggregates announced from the RIPE address blocks: 137705 RIPE Region origin ASes present in the Internet Routing Table: 27564 RIPE Prefixes per ASN: 8.46 RIPE Region origin ASes announcing only one prefix: 11851 RIPE Region transit ASes present in the Internet Routing Table: 3893 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 9735 Number of RIPE addresses announced to Internet: 709722752 Equivalent to 42 /8s, 77 /16s and 130 /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-213403 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: 112113 Total LACNIC prefixes after maximum aggregation: 26185 LACNIC Deaggregation factor: 4.28 Prefixes being announced from the LACNIC address blocks: 113225 Unique aggregates announced from the LACNIC address blocks: 47917 LACNIC Region origin ASes present in the Internet Routing Table: 10626 LACNIC Prefixes per ASN: 10.66 LACNIC Region origin ASes announcing only one prefix: 2626 LACNIC Region transit ASes present in the Internet Routing Table: 1967 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 33 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 8216 Number of LACNIC addresses announced to Internet: 174113024 Equivalent to 10 /8s, 96 /16s and 193 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-272796 + 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: 24755 Total AfriNIC prefixes after maximum aggregation: 4791 AfriNIC Deaggregation factor: 5.17 Prefixes being announced from the AfriNIC address blocks: 31974 Unique aggregates announced from the AfriNIC address blocks: 10289 AfriNIC Region origin ASes present in the Internet Routing Table: 1420 AfriNIC Prefixes per ASN: 22.52 AfriNIC Region origin ASes announcing only one prefix: 483 AfriNIC Region transit ASes present in the Internet Routing Table: 287 Average AfriNIC Region AS path length visible: 5.1 Max AfriNIC Region AS path length visible: 29 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 747 Number of AfriNIC addresses announced to Internet: 108557312 Equivalent to 6 /8s, 120 /16s and 116 /24s AfriNIC AS Blocks 36864-37887, 327680-329727 & ERX transfers AfriNIC Address Blocks 41/8, 45/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 7545 5676 777 661 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4755 4192 73 ERX-CERNET-BKB China Education and Rese 7552 3577 1330 21 VIETEL-AS-AP Viettel Group, VN 7713 3227 952 519 TELKOMNET-AS-AP PT Telekomunikasi Indon 45899 2842 1896 55 VNPT-AS-VN VNPT Corp, VN 9808 2574 9044 57 CMNET-GD Guangdong Mobile Communication 4766 2356 11104 565 KIXS-AS-KR Korea Telecom, KR 9498 2297 466 232 BBIL-AP BHARTI Airtel Ltd., IN 4755 2133 441 189 TATACOMM-AS TATA Communications formerl 45090 2064 1045 63 CNNIC-TENCENT-NET-AP Shenzhen Tencent C 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 11492 4755 315 695 CABLEONE, US 16509 4501 9066 2085 AMAZON-02, US 7155 4019 264 32 VIASAT-SP-BACKBONE, US 22773 3739 2994 196 ASN-CXA-ALL-CCI-22773-RDC, US 6327 3357 1319 83 SHAW, CA 16625 3124 1641 2247 AKAMAI-AS, US 209 2525 5059 511 CENTURYLINK-US-LEGACY-QWEST, US 30036 2487 370 113 MEDIACOM-ENTERPRISE-BUSINESS, US 5650 2336 2984 1643 FRONTIER-FRTR, US 20115 2165 2899 504 CHARTER-20115, US 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 47331 6502 900 3642 TTNET, TR 12479 6226 1667 141 UNI2-AS, ES 39891 3459 195 22 ALJAWWALSTC-AS, SA 20940 3330 3347 200 AKAMAI-ASN1, EU 8551 3237 379 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12389 2881 2282 892 ROSTELECOM-AS, RU 9009 2235 231 1219 M247, GB 34984 2167 351 576 TELLCOM-AS, TR 13188 1610 100 31 TRIOLAN, UA 58224 1449 853 541 TCI, IR 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 8151 8187 3442 603 Uninet S.A. de C.V., MX 10620 3396 526 550 Telmex Colombia S.A., CO 11830 2565 369 63 Instituto Costarricense de Electricidad 13999 1561 430 411 Mega Cable, S.A. de C.V., MX 6503 1444 311 475 Axtel, S.A.B. de C.V., MX 7303 1435 909 262 Telecom Argentina S.A., AR 28573 1371 2259 223 CLARO S.A., BR 6147 1147 379 39 Telefonica del Peru S.A.A., PE 3816 1113 537 151 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11664 999 212 418 Techtel LMDS Comunicaciones Interactiva 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 1567 393 22 LINKdotNET-AS, EG 24835 1288 480 25 RAYA-AS, EG 36992 1206 1529 133 ETISALAT-MISR, EG 36903 950 496 96 MT-MPLS, MA 29571 709 68 12 ORANGE-COTE-IVOIRE, CI 6713 533 1863 34 IAM-AS, MA 15399 485 46 17 WANANCHI-, KE 37342 478 32 1 MOVITEL, MZ 36935 464 522 40 Vodafone-, EG 23889 450 232 16 MauritiusTelecom, MU 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 8151 8187 3442 603 Uninet S.A. de C.V., MX 47331 6502 900 3642 TTNET, TR 12479 6226 1667 141 UNI2-AS, ES 7545 5676 777 661 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4755 4192 73 ERX-CERNET-BKB China Education and Rese 11492 4755 315 695 CABLEONE, US 16509 4501 9066 2085 AMAZON-02, US 7155 4019 264 32 VIASAT-SP-BACKBONE, US 22773 3739 2994 196 ASN-CXA-ALL-CCI-22773-RDC, US 7552 3577 1330 21 VIETEL-AS-AP Viettel Group, VN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggregation summary ----------------------------------------- ASN No of nets Net Savings Description 12479 6226 6085 UNI2-AS, ES 7545 5676 5015 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4755 4682 ERX-CERNET-BKB China Education and Research Net 11492 4755 4060 CABLEONE, US 7155 4019 3987 VIASAT-SP-BACKBONE, US 7552 3577 3556 VIETEL-AS-AP Viettel Group, VN 22773 3739 3543 ASN-CXA-ALL-CCI-22773-RDC, US 39891 3459 3437 ALJAWWALSTC-AS, SA 6327 3357 3274 SHAW, CA 8551 3237 3194 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Net Originated Transit AS Transit AS Name 62828 UNALLOCATED 8.21.130.0/24 3356 LEVEL3, US 393266 UNALLOCATED 8.23.52.0/24 174 COGENT-174, US 18604 UNALLOCATED 8.25.204.0/24 3356 LEVEL3, US 32985 UNALLOCATED 8.28.31.0/24 3356 LEVEL3, US 394936 UNALLOCATED 8.33.224.0/24 174 COGENT-174, US 23061 UNALLOCATED 8.39.119.0/24 3356 LEVEL3, US 395438 UNALLOCATED 8.42.206.0/24 3356 LEVEL3, US 46766 UNALLOCATED 8.44.208.0/24 3356 LEVEL3, US 40544 UNALLOCATED 12.0.33.0/24 6461 ZAYO-6461, US 393489 UNALLOCATED 12.7.109.0/24 7018 ATT-INTERNET4, US Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 192.88.99.0/24 6939 HURRICANE, US Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Unassigned Network ASN Information AS Name 23.141.0.0/24 Origin: 395350 UNASSIGNED Transit: 11426 TWC-11426-CAROLINAS, US 23.142.80.0/24 Origin: 397294 UNASSIGNED Transit: 398559 TUNBROKER, US 27.100.7.0/24 Origin: 56096 UNASSIGNED Transit: 45455 TH-2S1N-AP Two S One N Co Ltd, Internet 27.126.156.0/22 Origin: 55827 UNASSIGNED Transit: 9930 TTNET-MY TIME dotCom Berhad No. 14, Jala 27.126.156.0/23 Origin: 55827 UNASSIGNED Transit: 9930 TTNET-MY TIME dotCom Berhad No. 14, Jala 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:8 /9:13 /10:40 /11:101 /12:292 /13:579 /14:1175 /15:1932 /16:13469 /17:8249 /18:13675 /19:25588 /20:41340 /21:50275 /22:103262 /23:87738 /24:484046 /25:1242 /26:0 /27:0 /28:0 /29:0 /30:0 /31:0 /32:0 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 47331 5724 6502 TTNET, TR 12479 5201 6226 UNI2-AS, ES 11492 3803 4755 CABLEONE, US 6327 3152 3357 SHAW, CA 7155 3108 4019 VIASAT-SP-BACKBONE, US 8151 2892 8187 Uninet S.A. de C.V., MX 22773 2867 3739 ASN-CXA-ALL-CCI-22773-RDC, US 39891 2801 3459 ALJAWWALSTC-AS, SA 8551 2699 3237 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 30036 2225 2487 MEDIACOM-ENTERPRISE-BUSINESS, US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1879 2:1143 3:35 4:18 5:3408 6:53 8:1484 9:1 11:1 12:1759 13:351 14:2397 15:72 16:13 17:302 18:93 20:111 23:4139 24:2359 25:3 27:2340 31:2162 32:112 34:1 35:35 36:1128 37:3507 38:2000 39:476 40:150 41:3866 42:616 43:2111 44:236 45:14651 46:3618 47:322 49:1607 50:1680 51:90 52:1129 54:213 55:781 56:6 57:56 58:1691 59:1144 60:817 61:2305 62:2197 63:2016 64:5226 65:2380 66:5121 67:2951 68:1170 69:4101 70:1400 71:685 72:3090 74:2545 75:1457 76:687 77:1973 78:3178 79:2493 80:1917 81:1630 82:1297 83:1105 84:1251 85:3100 86:619 87:1784 88:2428 89:2868 90:402 91:7167 92:1590 93:2549 94:2910 95:4162 96:1228 97:341 98:968 99:976 100:90 101:1048 102:1211 103:24992 104:3616 105:390 106:775 107:2172 108:686 109:3743 110:2001 111:2346 112:1652 113:1533 114:1415 115:1853 116:1862 117:2118 118:2276 119:1863 120:939 121:1040 122:2295 123:2126 124:1631 125:2133 128:1384 129:1258 130:770 131:1996 132:746 133:311 134:1390 135:331 136:684 137:899 138:2293 139:1157 140:737 141:1161 142:1041 143:1249 144:1210 145:334 146:1361 147:1212 148:2170 149:1262 150:758 151:1201 152:1603 153:446 154:2298 155:1261 156:1353 157:1133 158:912 159:2040 160:2039 161:1078 162:3202 163:920 164:1422 165:1314 166:600 167:1719 168:3627 169:630 170:4359 171:743 172:2007 173:2923 174:966 175:1060 176:2910 177:4440 178:2785 179:1896 180:2280 181:2578 182:3160 183:1516 184:2403 185:17553 186:4025 187:3053 188:3298 189:2728 190:9091 191:1400 192:10585 193:7846 194:6379 195:4581 196:3109 197:2297 198:6010 199:5940 200:7310 201:5269 202:10566 203:10142 204:4633 205:3096 206:3295 207:3311 208:3986 209:4608 210:4193 211:2095 212:3587 213:3193 214:1189 215:61 216:6143 217:2472 218:897 219:637 220:2086 221:929 222:975 223:1701 End of report

1 0

Questions for Level3 & Choopa about their Enabling of IP Hijacking (RPKI Invalid)
by lists＠geeksolutions.ca 11 Dec '20

11 Dec '20

Is there anyone on this list at Level3 or Choopa who can respond to why: 1. Level3/Centurylink/Lumen: How come RPKI invalid prefixes were allowed to be announced and considered valid? 2. Level3/Centurylink/Lumen: Is there any actual NOC hidden behind the numbers where someone can reasonably be of assistance? Why are your SOC, Support and DDoS team saying you can't blackhole a hijacked prefix because of "GOVERNMENT regulations"? 3. CHOOPA: Why does your Vultr brand allow anyone who can successfully insert an IRR record (eg, in RaDB) to be imported (even when RPKI is invalid) and permit hijacking? 4. CHOOPA: Why does your Network Team need 3 days to check an RPKI valid or invalid? It is not rocket science. Please feel free to contact me off the list with these answers. If you are interested in the long story of the whole ordeal of being hijacked for 3 days, it is below. IP hijacking ordeal we went through: We are extremely disappointed with Choopa/Vultr and Level3. On 2020-12-07 at exactly 23:48:10, we notified Choopa and Vultr via email, ticket and contact form that one of our IPv4 prefixes was being hijacked by one of their customers. Our prefixes are RPKI signed, and the ASN announcing the prefix was not in the RPKI sign. We continued to follow up on the request, and sent more requests in to Vultr/Choopa's system. When we phoned Choopa, we were told by the individual on the phone that they see the ticket, and they'll bump it up on the network engineering ticket list. Frustrated after three days of an ongoing hijack, and consistently no assistance from Vultr or it's parent Choopa, we reached out to the only Tier-1 Choopa has in London that was NOT filtering according to RPKI, Level3. We sent an email to the noc(a)level3carrier.com, which was listed as a point of contact on the ASN & PeeringDB pages. The email had no response. We then called the number (1-833-453-8353), and spoke to Technical Support, who transferred us the first time to the SOC, the second time to their DDoS department. The person who responded in the SOC said that they can filter it "very fast" if we validate ownership of the prefix (despite being RPKI signed). So we complied, we were told to email "abuse(a)centurylinkservices.net" with a message saying the prefix is being hijacked, the ASN of the hijacker and the direct upstream (Vultr/Choopa). We sent that email, he said we "should get" an automatic reply (none arrived, confirmed with mx it was delivered). We waited half an hour, which they agreed was a "reasonable time" to wait for it to be filtered. After half an hour, we followed up, and this time landed on the DDoS department (I have no clue how they thought this through). At the DDoS department, they said that they can't help, and I should "keep emailing" abuse(a)centurylinkservices.net. He offered a phone number for me to call as a "direct line to abuse", upon hanging up and dialing, I got to the generic prompts for *customer services*. They were no help either. Fast forward four hours, we have no point of contact at Level3 or Choopa, we have had no communication from either. We finally get a message from Choopa, reading: "Greetings, This ticket has been forwarded to our networking team so they can examine your situation, check the infrastructure configuration, and apply any relevant changes. Please allow for significant additional time while we review this ticket." "Significant additional time" to check an RPKI valid? That seems incredibly odd. Fast forward to another hour, we receive the next of Choopa messages, this time saying: "Thanks for the update on this. We have validated the removal request and have removed the prefix from our network. Please allow additional time for this to update to the providers.". We finally thought we were in the clear. Almost two hours go by, and the prefix is still not filtered what-so-ever. We follow up once more, and are told "We have removed the prefix and is not announced by Vultr anymore. Please allow 24 to 48 hours for the internet providers to update their routing database." Finally, an hour later, nlnog & other lg's are seeing Level3 no longer announcing the prefix. What we found out in the process is Vultr ignores RPKI invalid (despite having a table on their system which shows RPKI Invalid/Invalid ASN), as long as at one point in time an IRR record existed (or, is created). Once Vultr gets their hands on it, they make the IRR records at RaDB, and keep updating them even when they're not valid. With the run around of Level3, and Choopa/Vultr, they're practically inviting IP hijackers to play. Insanity!

1 0

Fwd: Weather Service faces Internet bandwidth shortage, proposes limiting key data
by Rich Kulawiec 11 Dec '20

11 Dec '20

----- Forwarded message from Dave Farber <farber(a)gmail.com> ----- > From: Dave Farber <farber(a)gmail.com> > Date: Thu, 10 Dec 2020 15:47:44 +0900 > Subject: [IP] Weather Service faces Internet bandwidth shortage, proposes limiting key data > > Weather Service faces Internet bandwidth shortage, proposes limiting key data > The National Weather Service is proposing to place limits on accessing its > life-saving weather data in a bid to fix Internet outages. > By Jason Samenow and Andrew Freedman > > https://www.washingtonpost.com/weather/2020/12/09/nws-data-limits-internet-… [snip] This seems like a problem that this group could solve rather rapidly with minimal incremental expense. It also seems like one that's very much worth solving. ---rsk

10 10

Woefully outdated Verizon & Lumen ARIN whois/SWIP data
by nanog＠jima.us 10 Dec '20

10 Dec '20

Hi all, I apologize for dredging up the topic on this forum, but Lumen/CenturyLink/Qwest/US West has been continually unable to help me despite multiple attempts over years (yes, years), and Verizon's response to my colleague was to blame a downstream consumer of the whois data (?), and to use the opportunity to try to sell value-added services as a prerequisite to escalating the matter (!?). Does anyone have a lead on someone within those organizations who understands how to delete IP space assignments? Thanks in advance! - Jima

1 1

95th billing and automation
by Mehmet Akcin 10 Dec '20

10 Dec '20

hi there, i have asked about this in the past. What is the best tool out there to do 95th percentile billing. I have decided to use observium and librenms as result of responses but there seems to be some kind of billing module issue with these tools (thy are basically the same code). What are other systems besides observium and librenms (and old fashion cacti) people are using these days with 95th billing and integration with a CRM like salesforce/zoho, etc. I appreciate the responses. Mehmet

4 3

OpenNMS, openstreetmap, geocoding APIs and SNMP
by Eric Kuhnke 10 Dec '20

10 Dec '20

Anyone that has used a recent version of OpenNMS has probably noticed that the default home page view now includes an openstreetmap based view of node/device status, by geographical location. Section 18.3 here: https://docs.opennms.org/opennms/releases/latest/guide-admin/guide-admin.ht… https://wiki.opennms.org/wiki/Geographical_Maps example image here: https://www.tecmint.com/wp-content/uploads/2019/05/opennms-default-admin-da… While customizing a newly setup opennms VM for a unique purpose, I began thinking that there's two possible ways to go about accurately placing nodes on such a map, on a very large scale, with scripting/automation in the provisioning and monitoring process. *Method 1 *(as opennms does now): As defined in RFC3418, put the standard street address of the node in the SNMP sysLocation field. Typically in a human readable text format that would be understood when posted to a geolocation API SaaS. Example being: 2200 6th Avenue, Seattle WA 98121 sysLocation OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "The physical location of this node (e.g., 'telephone closet, 3rd floor'). If the location is unknown, the value is the zero-length string." ::= { system 6 } The above is dependent on a few things. First, every node needs to have a standard format street address entered into its sysLocation field. But what if you have a telecom tower site on a mountain or hillside? What if it's a node in a developing nation environment where standard third-party geolocation API providers (S.18.3 of the opennms documentation) can't resolve anything? What if it's a device that moves around, like a router on an ocean going vessel or aircraft? *Method 2 *(backwards compatible, possibly an improvement): Treat the 255 character sysLocation field as a rudimentary three column CSV file with pipe delimiters. Put the standard human readable description of the node location in the first column. Populate the second column with the latitude and longitude in WGS84 decimal degree format, such as: Suite 402 2200 6th Ave, Seattle WA 98121|47.616380|-122.341673 Where both columns have six decimal places of precision Column 2 is positive integer if north of the equator Column 3 is negative integer if west of Greenwich. Optional 4th column: Elevation in metres, MSL In the method 2 example described above, opennms can be customized to retrieve the lat/long from sysLocation and place nodes on the dashboard, rendering the underlying map from a self-hosted openstreetmap intranet server without needing to call an external geolocation API. Provided that the data provisioned into the CPE/node in the first place is accurate (this is absolutely a GIGO problem), node locations for difficult-to-geocode install locations should become much more accurate. *Some issues that may be encountered:* Very old or improperly implemented snmpd on some devices does not support a 255 character field length, sometimes not even 100 characters. Varies greatly by vendor implementation. Provisioning and configuration system for nodes need an automated way to enter those lat/long coordinates into columns 2 and 3 in a scripted, automated way. In an example of small 1/10GbE capable business-class ISP CPE demarc devices, *perhaps* as the result of a provisioning system's call to a geolocation API. But with some sort of optional step for configuring a node in a location that won't geocode - such as having a provisioning tech manually scroll to and click a location on a map in a browser. For ISPs with large numbers of CPE endpoint/stub nodes that don't presently have valid sysLocation, it will be a manually laborious one-time process to hunt down all extant CPEs and verify their street address vs customer records, google maps/bing maps/openstreetmap, and manually edit the sysLocation field. Environments that would have many nodes expected to fail third-party geolocation APIs, would probably want to customize some sort of click-on-map GUI for the persons doing the provisioning and hand-off of CPEs to field installation techs. Or possibly using GPS data acquired from an installation technician's mobile phone (standard iOS and Android browser APIs for requesting GPS data), as a custom data field in a ticketing system. Data from that field in the ticketing system could then be fed to another piece of software and pushed to a script to write the sysLocation. *Possibly outside scope*: It's possible to self host your own openstreetmap tile server. The vector data for the entire world is freely available to download. The tile rendering engine and all software needed to set it up is all open source. This can be implemented for ISP management/monitoring networks (NOC map dashboard functionality, etc) that for security reasons have no connection whatsoever to the global routing table. Nodes that move around because they're mounted on some sort of vehicle may be able to update and rewrite their own SNMP sysLocation field from GPS data. Would require custom scripting or being accompanied by a very small embedded Linux system with serial interface to a low-cost GPS chipset. That's a data acquisition system that already exists for some category of equipment such as two-way satellite terminals on ocean going vessels.

2 1