- NANOG - lists.nanog.org

best current practice: buffers
by Baldur Norddahl 19 Dec '20

19 Dec '20

Hello What is the best current practice for buffer size? For customer facing ports, core network ports and transit links? We have a buffer problem, discovered by a customer that moved their servers to a cloud service some distance away. That resulted in a drastic reduced transfer speed between their office and the cloud service. Nothing much could be done since we, like so many others, have switches with extreme fast port speeds (48x 10G, 4x 100G) with a tiny shared 12 MB buffer. Now the time has come to upgrade that hardware to something that does have plenty of buffer capacity, so I am planning out what the settings should be. I have read this paper http://web.stanford.edu/class/cs244/papers/sizing-router-buffers-redux.pdf which claims not much buffer is needed at all. And I think they are completely wrong. In the paper they assume we are trying to get as much throughput on a congested core or transit port. But we always make sure those are not congested, so that misses the mark completely. For core ports we are concerned about microbursts and for customer ports we do care about a single TCP session being able to get the max throughput. The paper assumes there will be a lot of TCP sessions sharing the bandwidth, but that is not always the case with customer ports. It might be a guy downloading an ISO image with him being the only guy at the office. The common wisdom is to set the buffer size to one bandwidth-delay product. And also that bigger buffers than this is harmful. But that raises the question of what distance do I tune for? Amsterdam is 10 ms away. East coast USA is 100 ms. Also the new hardware (Juniper ACX710) does support more than one queue per port. Would it be possible to have that ISO download go into a queue for heavy streams and allow smaller streams to skip the line, so we do not see the downside of a heavy buffer (buffer bloat)? It is no longer just a simple matter of buffer size. What are others doing to deliver the best possible performance to customers with regards to buffering? Regards, Baldur

2 1

Need someone with clue @ Network Solutions.
by Matthew Crocker 18 Dec '20

18 Dec '20

I need to get Network Solutions to remove glue records for hosts in my domain. My domain isn’t registered with Network Solutions and they refuse to speak with me as I’m not a customer. I’ve had my customer attempt to update their domain through Network Solutions but the only thing they can change is the NS record, not the underlying host glue record. I don’t think the glue records even need to exist as they are published by my domain already. Does anyone have any contacts at Network Solutions that can help? Example: dig <MY_CUSTOMER>.com NS @i.gtld-servers.net. ; <<>> DiG 9.10.6 <<>> <MY_CUSTOMER>.com NS @i.gtld-servers.net. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24593 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;<MY_CUSTOMER>.com. IN NS ;; AUTHORITY SECTION: <MY_CUSTOMER>.com. 172800 IN NS dns-auth4.crocker.com. <MY_CUSTOMER>.com. 172800 IN NS dns-auth3.crocker.com. ;; ADDITIONAL SECTION: dns-auth4.crocker.com. 172800 IN A 66.59.48.95 dns-auth3.crocker.com. 172800 IN A 66.59.48.94 ;; Query time: 73 msec ;; SERVER: 192.43.172.30#53(192.43.172.30) ;; WHEN: Tue Dec 15 11:34:41 EST 2020 ;; MSG SIZE rcvd: 124 The correct servers are: dns-auth3.crocker.com. 299 IN A 66.59.61.10 dns-auth4.crocker.com. 299 IN A 66.59.61.194

9 11

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

18 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 19 Dec, 2020 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 834384 Prefixes after maximum aggregation (per Origin AS): 319639 Deaggregation factor: 2.61 Unique aggregates announced (without unneeded subnets): 399442 Total ASes present in the Internet Routing Table: 70165 Prefixes per ASN: 11.89 Origin-only ASes present in the Internet Routing Table: 60316 Origin ASes announcing only one prefix: 24963 Transit ASes present in the Internet Routing Table: 9849 Transit-only ASes present in the Internet Routing Table: 296 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 203 Max AS path prepend of ASN (396896) 200 Prefixes from unregistered ASNs in the Routing Table: 1041 Number of instances of unregistered ASNs: 1042 Number of 32-bit ASNs allocated by the RIRs: 34457 Number of 32-bit ASNs visible in the Routing Table: 28615 Prefixes from 32-bit ASNs in the Routing Table: 131766 Number of bogon 32-bit ASNs visible in the Routing Table: 19 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 487 Number of addresses announced to Internet: 2864080896 Equivalent to 170 /8s, 182 /16s and 104 /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: 283940 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 218271 Total APNIC prefixes after maximum aggregation: 64342 APNIC Deaggregation factor: 3.39 Prefixes being announced from the APNIC address blocks: 214363 Unique aggregates announced from the APNIC address blocks: 87510 APNIC Region origin ASes present in the Internet Routing Table: 11125 APNIC Prefixes per ASN: 19.27 APNIC Region origin ASes announcing only one prefix: 3163 APNIC Region transit ASes present in the Internet Routing Table: 1606 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 31 Number of APNIC region 32-bit ASNs visible in the Routing Table: 6259 Number of APNIC addresses announced to Internet: 778351744 Equivalent to 46 /8s, 100 /16s and 180 /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: 240878 Total ARIN prefixes after maximum aggregation: 111543 ARIN Deaggregation factor: 2.16 Prefixes being announced from the ARIN address blocks: 241238 Unique aggregates announced from the ARIN address blocks: 115495 ARIN Region origin ASes present in the Internet Routing Table: 18688 ARIN Prefixes per ASN: 12.91 ARIN Region origin ASes announcing only one prefix: 6810 ARIN Region transit ASes present in the Internet Routing Table: 1917 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 203 Number of ARIN region 32-bit ASNs visible in the Routing Table: 3614 Number of ARIN addresses announced to Internet: 1093010176 Equivalent to 65 /8s, 38 /16s and 3 /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: 237298 Total RIPE prefixes after maximum aggregation: 111936 RIPE Deaggregation factor: 2.12 Prefixes being announced from the RIPE address blocks: 233244 Unique aggregates announced from the RIPE address blocks: 137821 RIPE Region origin ASes present in the Internet Routing Table: 27601 RIPE Prefixes per ASN: 8.45 RIPE Region origin ASes announcing only one prefix: 11876 RIPE Region transit ASes present in the Internet Routing Table: 3889 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 9766 Number of RIPE addresses announced to Internet: 709745280 Equivalent to 42 /8s, 77 /16s and 218 /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: 112152 Total LACNIC prefixes after maximum aggregation: 26270 LACNIC Deaggregation factor: 4.27 Prefixes being announced from the LACNIC address blocks: 113258 Unique aggregates announced from the LACNIC address blocks: 47934 LACNIC Region origin ASes present in the Internet Routing Table: 10629 LACNIC Prefixes per ASN: 10.66 LACNIC Region origin ASes announcing only one prefix: 2629 LACNIC Region transit ASes present in the Internet Routing Table: 1991 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 33 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 8226 Number of LACNIC addresses announced to Internet: 174119424 Equivalent to 10 /8s, 96 /16s and 218 /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: 24742 Total AfriNIC prefixes after maximum aggregation: 4794 AfriNIC Deaggregation factor: 5.16 Prefixes being announced from the AfriNIC address blocks: 31794 Unique aggregates announced from the AfriNIC address blocks: 10293 AfriNIC Region origin ASes present in the Internet Routing Table: 1424 AfriNIC Prefixes per ASN: 22.33 AfriNIC Region origin ASes announcing only one prefix: 484 AfriNIC Region transit ASes present in the Internet Routing Table: 284 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: 750 Number of AfriNIC addresses announced to Internet: 108424448 Equivalent to 6 /8s, 118 /16s and 109 /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 5682 777 661 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4749 4192 73 ERX-CERNET-BKB China Education and Rese 7552 3548 1330 21 VIETEL-AS-AP Viettel Group, VN 7713 3232 952 519 TELKOMNET-AS-AP PT Telekomunikasi Indon 45899 2855 1896 55 VNPT-AS-VN VNPT Corp, VN 9808 2585 9044 57 CMNET-GD Guangdong Mobile Communication 4766 2352 11103 560 KIXS-AS-KR Korea Telecom, KR 9498 2296 466 233 BBIL-AP BHARTI Airtel Ltd., IN 4755 2133 441 189 TATACOMM-AS TATA Communications formerl 45090 2067 1045 64 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 701 CABLEONE, US 16509 4528 9069 2096 AMAZON-02, US 7155 4020 264 32 VIASAT-SP-BACKBONE, US 22773 3769 3008 211 ASN-CXA-ALL-CCI-22773-RDC, US 6327 3357 1319 83 SHAW, CA 16625 3155 1654 2271 AKAMAI-AS, US 209 2523 5059 507 CENTURYLINK-US-LEGACY-QWEST, US 30036 2491 368 113 MEDIACOM-ENTERPRISE-BUSINESS, US 5650 2336 2984 1643 FRONTIER-FRTR, US 20115 2163 2898 509 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 12479 6214 1667 141 UNI2-AS, ES 47331 6104 845 3572 TTNET, TR 39891 3459 195 22 ALJAWWALSTC-AS, SA 20940 3327 3347 200 AKAMAI-ASN1, NL 8551 3225 379 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12389 2883 2282 892 ROSTELECOM-AS, RU 9009 2236 231 1220 M247, GB 34984 2168 352 577 TELLCOM-AS, TR 13188 1610 100 31 TRIOLAN, UA 58224 1463 856 550 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 8215 3444 601 Uninet S.A. de C.V., MX 10620 3394 526 590 Telmex Colombia S.A., CO 11830 2564 369 63 Instituto Costarricense de Electricidad 13999 1588 431 406 Mega Cable, S.A. de C.V., MX 6503 1438 311 475 Axtel, S.A.B. de C.V., MX 7303 1435 909 262 Telecom Argentina S.A., AR 28573 1376 2260 222 CLARO S.A., BR 6147 1146 379 39 Telefonica del Peru S.A.A., PE 3816 1115 537 152 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11664 1007 213 419 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 1566 393 22 LINKdotNET-AS, EG 24835 1287 478 26 RAYA-AS, EG 36992 1218 1530 137 ETISALAT-MISR, EG 36903 951 497 97 MT-MPLS, MA 29571 709 68 12 ORANGE-COTE-IVOIRE, CI 6713 533 1863 34 IAM-AS, MA 37342 478 32 1 MOVITEL, MZ 36935 464 522 40 Vodafone-, EG 23889 451 232 16 MauritiusTelecom, MU 15399 439 46 16 WANANCHI-, KE 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 8215 3444 601 Uninet S.A. de C.V., MX 12479 6214 1667 141 UNI2-AS, ES 47331 6104 845 3572 TTNET, TR 7545 5682 777 661 TPG-INTERNET-AP TPG Telecom Limited, AU 11492 4755 315 701 CABLEONE, US 4538 4749 4192 73 ERX-CERNET-BKB China Education and Rese 16509 4528 9069 2096 AMAZON-02, US 7155 4020 264 32 VIASAT-SP-BACKBONE, US 22773 3769 3008 211 ASN-CXA-ALL-CCI-22773-RDC, US 7552 3548 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 6214 6073 UNI2-AS, ES 7545 5682 5021 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4749 4676 ERX-CERNET-BKB China Education and Research Net 11492 4755 4054 CABLEONE, US 7155 4020 3988 VIASAT-SP-BACKBONE, US 22773 3769 3558 ASN-CXA-ALL-CCI-22773-RDC, US 7552 3548 3527 VIETEL-AS-AP Viettel Group, VN 39891 3459 3437 ALJAWWALSTC-AS, SA 6327 3357 3274 SHAW, CA 8551 3225 3182 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: 3803 RCN-AS1, US Transit: 398481 REDMERCURY, 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:1931 /16:13469 /17:8273 /18:13705 /19:25617 /20:41559 /21:50418 /22:103435 /23:87982 /24:484539 /25:1248 /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 5362 6104 TTNET, TR 12479 5185 6214 UNI2-AS, ES 11492 3805 4755 CABLEONE, US 6327 3152 3357 SHAW, CA 7155 3109 4020 VIASAT-SP-BACKBONE, US 8151 2917 8215 Uninet S.A. de C.V., MX 22773 2879 3769 ASN-CXA-ALL-CCI-22773-RDC, US 39891 2801 3459 ALJAWWALSTC-AS, SA 8551 2687 3225 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 30036 2224 2491 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:1881 2:1139 3:35 4:18 5:3410 6:53 8:1487 9:1 11:1 12:1755 13:349 14:2402 15:75 16:13 17:303 18:93 20:113 23:4145 24:2364 25:3 27:2339 31:2187 32:112 34:1 35:35 36:1137 37:3546 38:1999 39:458 40:150 41:3851 42:872 43:2114 44:234 45:14610 46:3625 47:321 49:1602 50:1678 51:90 52:1127 54:217 55:768 56:6 57:57 58:1689 59:1149 60:817 61:2312 62:2198 63:2011 64:5220 65:2375 66:5120 67:2947 68:1172 69:4100 70:1399 71:685 72:3102 74:2548 75:1457 76:688 77:1982 78:3096 79:2485 80:1924 81:1632 82:1313 83:1095 84:1261 85:3055 86:612 87:1792 88:2339 89:2891 90:400 91:7166 92:1597 93:2553 94:2919 95:4109 96:1226 97:342 98:966 99:976 100:90 101:1055 102:1215 103:25085 104:3620 105:390 106:775 107:2189 108:690 109:3752 110:2007 111:2351 112:1661 113:1554 114:1425 115:1855 116:1858 117:2111 118:2288 119:1866 120:958 121:1049 122:2301 123:2132 124:1639 125:2140 128:1342 129:1258 130:766 131:2003 132:743 133:311 134:1392 135:326 136:688 137:894 138:2307 139:1167 140:737 141:1165 142:1042 143:1242 144:1210 145:341 146:1383 147:1215 148:2175 149:1248 150:752 151:1201 152:1609 153:445 154:2116 155:1267 156:1353 157:1140 158:907 159:2039 160:2049 161:1079 162:3210 163:927 164:1421 165:1315 166:599 167:1735 168:3608 169:632 170:4354 171:744 172:2025 173:2911 174:973 175:1059 176:2926 177:4428 178:2788 179:1891 180:2278 181:2571 182:3161 183:1526 184:2406 185:17607 186:4030 187:3075 188:3391 189:2751 190:9060 191:1401 192:10596 193:7859 194:6401 195:4583 196:3079 197:2269 198:6023 199:5947 200:7325 201:5277 202:10554 203:10175 204:4651 205:3102 206:3308 207:3320 208:3991 209:4611 210:4199 211:2098 212:3613 213:3183 214:1186 215:61 216:6132 217:2476 218:899 219:641 220:2085 221:935 222:987 223:1706 End of report

1 0

All the latest NANOG News 👉 N80 Hackathon registration, new stories, and more!
by NANOG News 18 Dec '20

18 Dec '20

*Join us at the NANOG 81 Virtual Hackathon* *Saturday + Sunday, February 6-7, 2021* Hackathon Registration is now open 🎉 An essential part of our conferences, NANOG Hackathons are designed to be both fun and engaging, as well as a platform to build community and foster greater networking knowledge. The theme of the NANOG 81 Virtual Hackathon <https://nanog.org/meetings/nanog-81/nanog-81-hackathon/> is Configuration Modeling. Utilizing collaboration services from Zoom and Slack, participants can work individually, or self-organize into teams to work on software passion projects. All levels are welcome. And as always, registration is FREE. We hope to see you there! Learn More <https://nanog.org/meetings/nanog-81/nanog-81-hackathon/> Register Now <https://events.nanog.org/event/e3b346c8-0e5a-4188-a732-1d9525cd2c81/summary…> *Mark your calendars* *Registration for the NANOG 81 Virtual conference opens Jan 4! * Join us online February 8-10, 2021 for a three-day virtual program of talks, tutorials, keynotes, and panels, presented by some of the industry’s top minds. The fee to attend NANOG 81 Virtual <https://nanog.org/meetings/nanog-81/> will be $100, which helps offset our costs to build a virtual platform, and plan + execute the conference. We’re committed to ensuring NANOG Virtual events are accessible and welcoming to all. Complimentary Conference Registration will also be available to anyone who’d like to attend NANOG 81 Virtual for free. Stay tuned for more information! *Submit a talk proposal for NANOG 81 Virtual* Interested in sharing your research + ideas with the greater NANOG community, but missed the NANOG 81 submission deadline? The Program Committee (PC) is always looking for new + interesting talks, and there may still be time for your presentation to be scheduled for NANOG 81! The PC accepts proposals for all other future conferences on a rolling basis. *Topics of interest:* - Automation - SDN - Traffic analysis - ISP Issues: sharing lessons learned / what to watch out for - Cloud-related topics: scale concerns, etc. - Routing - Best current practices - Career development skills - Tutorials: 101, deep dives, etc. Learn More <https://www.nanog.org/meetings/nanog-81/nanog-81-call-presentations/> Submit Now <https://www.nanog.org/meetings/submit-presentation/> *Connect with us on LinkedIn * As of December 11, the NANOG Communications LinkedIn account is no longer active. But we'd love to stay connected! Be sure to follow us on our LinkedIn Business page <https://www.linkedin.com/company/nanog/> to keep up with all the latest NANOG news, events, and stories (and don't forget to tag us in your LinkedIn posts, so we can re-post and share the love!). Looking to join a community forum? Check out the NANOG Community-Moderated Group <https://www.linkedin.com/groups/40718/>, a LinkedIn group managed and moderated by members of our community. Follow Us <https://www.linkedin.com/company/nanog/> *“I love to be part of a community that continuously works to grow and improve the Internet.” * NANOG is, and always has been, dedicated to the people who make up our community. That's why we love to highlight the stories and experiences of the most exceptional people we know. The innovators, change makers, and mentors who embody our mission to advance an open, secure, and robust Internet, through inspiration, education, and empowerment. Keep up with our amazing community on NANOG Stories, where we regularly feature new interviews! Read More <https://nanog.org/stories/>

1 0

Re: Are the days of the showpiece NOC office display gone forever?
by Peter E. Fry 17 Dec '20

17 Dec '20

> > Subject: Re: Are the days of the showpiece NOC office display gone > forever? > From: Tom Beecher <beecher(a)beecher.cc> > To: Matt Erculiani <merculiani(a)gmail.com> > Cc: NANOG Operators' Group <nanog(a)nanog.org> > Date: Thursday, 12/17/2020 11:59:37 [...] > > > Contrary to what salespeople will say, the answer is not 100% > automation, or 100% humans. The proper answer is an often changing > combination of the two. I believe the desired combination is automation + button-pushing monkeys. > > > > ML is not the magical unicorn solution that solves everything, > contrary to what many papers and salespeople tell you. [...] But which will write Shakespeare first? I'd bet on the monkeys, although both come up with some unique and unanticipated ways to fail. Oh well. Back to pushing buttons. Someday my masterpiece will be complete... Peter E. Fry

2 1

"Hacking" these days - purpose?
by Peter E. Fry 17 Dec '20

17 Dec '20

Simple question: What's the purpose of obtaining illicit access to random devices on the Internet these days, considering that a large majority of attacks are now launched from cheap, readily available and poorly managed/overseen "cloud" services? Finding anything worthwhile to steal on random machines on the Internet seems unlikely, as does obtaining access superior (in e.g. location, bandwidth, anonymity, etc.) to the service from which the attack was launched. I was thinking about this the other day as I was poking at my firewall, and hopped onto the archives (here and elsewhere) to see if I could find any discussion. I found a few mentions (e.g. "Microsoft is hacking my Asterisk???"), but I didn't catch any mention of purpose. Am I missing something obvious (either a purpose or a discussion of such)? Have I lost my mind entirely? (Can't hurt to check, as I'd likely be the last to know.) Peter E. Fry

14 22

Re: "Hacking" these days - purpose?
by Hal Murray 16 Dec '20

16 Dec '20

> Simple question: What's the purpose of obtaining illicit access to random > devices on the Internet these days ... Aside from stealing user's information, there is also stealing industrial and diplomatic secrets. The Chinese stole a lot of F-35 info. The news is full of Russians hacking into US Treasury and Commerce Departments and probably more. -- These are my opinions. I hate spam.

1 0

Fwd: [apnic-talk] APRICOT 2021 call for presentations
by Mark Tinka 16 Dec '20

16 Dec '20

FYI. Mark. -------- Forwarded Message -------- Subject: [apnic-talk] APRICOT 2021 call for presentations Date: Fri, 20 Nov 2020 14:52:26 +1000 From: Philip Smith <pfsinoz(a)gmail.com> Organization: PFS Internet Development Pty Ltd To: apnic-talk(a)lists.apnic.net CC: APRICOT PC Chairs <pc-chairs(a)apricot.net> Hi everyone, As I mentioned last week when I sent out the Call for Volunteers for the APRICOT PC, APRICOT 2021 will be online in February next year. Same dates as we had planned for the in-person meeting. I've included the call for presentations below - looking forward to receiving your presentation proposals! Thanks! philip -- CALL FOR PAPERS =============== The APRICOT 2021 Programme Committee is now seeking contributions for Presentations and Tutorials for the APRICOT 2021 Conference. We are looking for presenters who would: - Offer a technical tutorial on an appropriate topic; - Participate in the technical conference sessions as a speaker; - Convene and chair panel sessions of relevant topics; Please submit on-line at: http://papers.apricot.net/user/login.php?event=128 Tutorials will take place during the week of 22nd February. Conference sessions and the Peering Forum will take place on the week of 1st March. All APRICOT 2021 sessions times will be one hour long, with up to four sessions scheduled per day. CONFERENCE MILESTONES --------------------- Call for Papers Opens: Now Draft Program Published: As Papers Confirmed Final Deadline for Submissions: 7 February 2021 Final Program Published: 14 February 2021 Final Slides Received: 21 February 2021 *SLOTS ARE FILLED ON A FIRST COME, FIRST SERVED BASIS, REGARDLESS OF PUBLISHED DEADLINES* PROGRAMME CONTENT ----------------- The APRICOT Conference Programme consists of three parts, these being Tutorials, the Peering Forum, and Conference Sessions. Topics proposed must be relevant to Internet Operations and Technologies: - IPv4 / IPv6 Routing and Operations - Internet backbone operations - Peering, Interconnects and IXPs - Network Function Virtualisaton - Network Automation/Programming - Content Distribution Network technology & operations - Research on Internet Operations and Deployment - Network infrastructure security - IPv6 deployment on fixed and Wireless/Cellular networks - DNS / DNSSEC - Access and Transport Technologies, including Cable/DSL, LTE/5G, wireless, metro ethernet, fibre, segment routing - Content & Service Delivery and "Cloud Computing" PEERING FORUM ------------- Due to APRICOT 2021 being held online, the PC will only accept Peering Personals prior to the event starting. Submissions must be of a single slide listing the operator's PeeringDB entry. Please refer to https://tinyurl.com/y46954n5 for how to create a successful Peering Personal presentation. CfP SUBMISSION -------------- Draft slides for both tutorials and conference sessions MUST be provided with CfP submissions otherwise the submission will be rejected immediately. For work in progress, the most current information available at time of submission is acceptable. All draft and complete slides must be submitted in PDF format only. Slides must be of original work, with all company confidential marks removed. Final slides are to be provided by the specified deadline for publication on the APRICOT website. Prospective presenters should note that the majority of speaking slots will be filled well before the final submission deadline. The PC may, at their discretion, retain a limited number of slots up to the final submission deadline for presentations that are exceptionally timely, important, or of critical operational importance. Every year we turn away submissions, due to filling up all available programme slots before the deadline. Presenters should endeavour to get material into the PC sooner rather than later. Any questions or concerns should be addressed to the Programme Committee by e-mail at: pc-chairs at apricot.net We look forward to receiving your presentation proposals. Mark Tinka, Marijana Novakovic & Philip Smith Co-Chairs, APRICOT 2021 Programme Committee -- _______________________________________________ apnic-talk mailing list apnic-talk(a)lists.apnic.net https://mailman.apnic.net/mailman/listinfo/apnic-talk .

1 0

Re: how many bits of entropy do we need for load balancing?
by Lawrence Wobker 15 Dec '20

15 Dec '20

So I’d argue that the pedantic answer is “you need only as many bits of entropy as your largest fan out” — meaning that 10 bits would allow 1024-way ECMP. But I don’t think that’s what you were actually after... Most of the challenges I’ve seen are not around how many bits you end up with, but rather how you get to those bits. There are lots of different ways to compute the hash values, but if you want to be “fast” you’re unlikely to also get “good” and “cheap”.... generally to select a path, we run a hash function against some set of packet fields, then map that hash to one of the member links. A “perfect” balancing algorithm would be crypto grade hash generation with a large output, and a true modulo operation to select which member we use. The reality is that both crypto hash functions and modulo operations are more expensive than lots of other ways to compute it, so vendors (disclaimer, I work for Cisco) have lots and lots of combinations for how it’s actually done. And then you still have the flow issue: since the vast majority of implementation are hashing flows regardless of their actual bandwidth, if you hash even a few ‘elephants’ onto the same link, you’re not going to get good distribution no matter how good your hashing/selection mechanism is. With respect to your comment about standardization, I doubt you’ll ever be able to get a broad consensus on the combination of “how many bits we need given the others constraints for a spec” and “how much we want to assume about the goodness of the hash generator” and “how much I’m willing to just throw bits at the problem” ... —lj —lj ________________________________ From: Lawrence Wobker <ljwobker(a)gmail.com> Sent: Monday, December 14, 2020 12:33:07 PM To: Pascal Thubert (pthubert) <pthubert(a)cisco.com>; NANOG <nanog(a)nanog.org> Subject: Re: how many bits of entropy do we need for load balancing? So I’d argue that the pedantic answer is “you need only as many bits of entropy as your largest fan out” — meaning that 10 bits would allow 1024-way ECMP. Most of the challenges I’ve seen are not around how many bits you end up with, but rather how you get to that state. There are lots of different ways to compute the hash values, but if you want to be “fast” you’re unlikely to also get “good” and “cheap”.... generally to select a path, we run a hash function against some set of packet fields, then map that hash to one of the member links. A “perfect” balancing algorithm would be crypto grade hash generation with a large output, and a true modulo operation to select which member we use. The reality is that both crypto hash functions and modulo operations are more expensive than lots of other ways to compute it, so vendors (disclaimer, I work for Cisco) have lots and lots of combinations for how it’s actually done. And then you still have the flow issue: since the vast majority of implementation are hashing flows regardless of their actual bandwidth, if you hash even a few ‘elephants’ onto the same link, you’re not going to get good distribution no matter how good your hashing/selection mechanism is. —lj ________________________________ From: NANOG <nanog-bounces+ljwobker=pobox.com(a)nanog.org> on behalf of Pascal Thubert (pthubert) via NANOG <nanog(a)nanog.org> Sent: Monday, December 14, 2020 9:44:05 AM To: NANOG <nanog(a)nanog.org> Subject: how many bits of entropy do we need for load balancing? 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

5 5

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