From woody at pch.net Fri Mar 1 06:54:57 2019 From: woody at pch.net (Bill Woodcock) Date: Thu, 28 Feb 2019 22:54:57 -0800 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: References: <50EFCF39-ABD7-4054-B6E1-99C2F73771AF@nist.gov> Message-ID: <6F4A6096-D81F-47D4-89E7-340EACD404EC@pch.net> > On Feb 24, 2019, at 9:20 PM, Bill Woodcock wrote: > > > >> On Feb 24, 2019, at 7:41 PM, Montgomery, Douglas (Fed) wrote: >> In the 3rd attack noted below, do we know if the CA that issued the DV CERTS does DNSSEC validation on its DNS challenge queries? > > We know that neither Comodo nor Let's Encrypt were DNSSEC validating before issuing certs. The Let’s Encrypt guys at least seemed interested in learning from their mistake. Can’t say as much of Comodo. Sorry, a correction: Apparently Let’s Encrypt _does_ do a DNSSEC validation check, and presumably that’s why a Comodo cert was used to attack us. It was my prior understanding that Let’s Encrypt certs had been used against DNSSEC-signed zones, but apparently that was not the case. My apologies for my confusion. Nonetheless, even with the DNSSEC validation, there’s a problem here that needs to be solved, on both the parts of the CAs involved and the registry/registrar chain. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From mjo at dojo.mi.org Fri Mar 1 10:19:29 2019 From: mjo at dojo.mi.org (Mike O'Connor) Date: Fri, 1 Mar 2019 05:19:29 -0500 Subject: a quick survey about LLDP and similar In-Reply-To: <87d0ncl22g.fsf@snoopy.tippete.net> References: <87d0ncl22g.fsf@snoopy.tippete.net> Message-ID: <20190301101929.ghvj44mjpekuclqt@dojo.mi.org> :Hello, :having a bit of a debate in my team about turning on LLDP and/or CDP. :I would appreciate if you could spend a minute answering this :survey so I have some numbers to back up my reasoning, or to accept :defeat. : :https://www.surveymonkey.com/r/TH3WCWP "Is LLDP / CDP that evil?" -- geez. Ask a leading question, get a leaden answer. It's clear what your biases are from the first few questions you ask. It _might_ be more interesting for you to present the points of view within your team. FWIW, my most recent foray into LLDP involved advising to turn it off for some systems. There were defects specific to the implementation on particular hardware, and I had a strange desire to not make my head hurt. I didn't label it evil, but it just wasn't a situation where I wanted "guinea pig" treatment while the vendor sorted out LLDP. -Mike -- Michael J. O'Connor mjo at dojo.mi.org =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--= "We buy junk and sell antiques." -Anguished English -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From cra at wpi.edu Fri Mar 1 14:25:47 2019 From: cra at wpi.edu (Anderson, Charles R) Date: Fri, 1 Mar 2019 14:25:47 +0000 Subject: a quick survey about LLDP and similar In-Reply-To: <87d0ncl22g.fsf@snoopy.tippete.net> References: <87d0ncl22g.fsf@snoopy.tippete.net> Message-ID: <20190301142545.lxxroyqcenii7z6a@angus.ind.wpi.edu> On Thu, Feb 28, 2019 at 10:00:55AM +0100, Pierfrancesco Caci wrote: > > Hello, > having a bit of a debate in my team about turning on LLDP and/or CDP. > I would appreciate if you could spend a minute answering this > survey so I have some numbers to back up my reasoning, or to accept > defeat. > > https://www.surveymonkey.com/r/TH3WCWP > > Feel free to cross-post to other relevant lists. > > Thank you > > Pf We require LLDP/LLDP-MED to configure our VOIP phones. For trunk links, it is extremely helpful to verify correct topology. For datacenters, it is EXTREMELY helpful to verify hypervisor connectivity. From cscora at apnic.net Fri Mar 1 18:03:37 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 2 Mar 2019 04:03:37 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190301180337.60FF9C55A0@thyme.apnic.net> 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 at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 02 Mar, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 738919 Prefixes after maximum aggregation (per Origin AS): 285184 Deaggregation factor: 2.59 Unique aggregates announced (without unneeded subnets): 355932 Total ASes present in the Internet Routing Table: 63421 Prefixes per ASN: 11.65 Origin-only ASes present in the Internet Routing Table: 54634 Origin ASes announcing only one prefix: 23613 Transit ASes present in the Internet Routing Table: 8787 Transit-only ASes present in the Internet Routing Table: 273 Average AS path length visible in the Internet Routing Table: 4.2 Max AS path length visible: 32 Max AS path prepend of ASN ( 16327) 25 Prefixes from unregistered ASNs in the Routing Table: 28 Number of instances of unregistered ASNs: 31 Number of 32-bit ASNs allocated by the RIRs: 25985 Number of 32-bit ASNs visible in the Routing Table: 21159 Prefixes from 32-bit ASNs in the Routing Table: 92373 Number of bogon 32-bit ASNs visible in the Routing Table: 26 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 250 Number of addresses announced to Internet: 2843232227 Equivalent to 169 /8s, 120 /16s and 71 /24s Percentage of available address space announced: 76.8 Percentage of allocated address space announced: 76.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.2 Total number of prefixes smaller than registry allocations: 247641 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 200962 Total APNIC prefixes after maximum aggregation: 57781 APNIC Deaggregation factor: 3.48 Prefixes being announced from the APNIC address blocks: 197911 Unique aggregates announced from the APNIC address blocks: 81748 APNIC Region origin ASes present in the Internet Routing Table: 9492 APNIC Prefixes per ASN: 20.85 APNIC Region origin ASes announcing only one prefix: 2667 APNIC Region transit ASes present in the Internet Routing Table: 1411 Average APNIC Region AS path length visible: 4.1 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4489 Number of APNIC addresses announced to Internet: 769995650 Equivalent to 45 /8s, 229 /16s and 51 /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-139577 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: 218584 Total ARIN prefixes after maximum aggregation: 103553 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 217591 Unique aggregates announced from the ARIN address blocks: 104294 ARIN Region origin ASes present in the Internet Routing Table: 18393 ARIN Prefixes per ASN: 11.83 ARIN Region origin ASes announcing only one prefix: 6848 ARIN Region transit ASes present in the Internet Routing Table: 1856 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2592 Number of ARIN addresses announced to Internet: 1079214496 Equivalent to 64 /8s, 83 /16s and 129 /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-399260 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: 203010 Total RIPE prefixes after maximum aggregation: 96936 RIPE Deaggregation factor: 2.09 Prefixes being announced from the RIPE address blocks: 199408 Unique aggregates announced from the RIPE address blocks: 118435 RIPE Region origin ASes present in the Internet Routing Table: 25858 RIPE Prefixes per ASN: 7.71 RIPE Region origin ASes announcing only one prefix: 11480 RIPE Region transit ASes present in the Internet Routing Table: 3630 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7871 Number of RIPE addresses announced to Internet: 717032640 Equivalent to 42 /8s, 189 /16s and 12 /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-210331 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: 95662 Total LACNIC prefixes after maximum aggregation: 22643 LACNIC Deaggregation factor: 4.22 Prefixes being announced from the LACNIC address blocks: 97031 Unique aggregates announced from the LACNIC address blocks: 42029 LACNIC Region origin ASes present in the Internet Routing Table: 8133 LACNIC Prefixes per ASN: 11.93 LACNIC Region origin ASes announcing only one prefix: 2188 LACNIC Region transit ASes present in the Internet Routing Table: 1529 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 32 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5681 Number of LACNIC addresses announced to Internet: 173345536 Equivalent to 10 /8s, 85 /16s and 11 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + 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: 20672 Total AfriNIC prefixes after maximum aggregation: 4249 AfriNIC Deaggregation factor: 4.87 Prefixes being announced from the AfriNIC address blocks: 26728 Unique aggregates announced from the AfriNIC address blocks: 9203 AfriNIC Region origin ASes present in the Internet Routing Table: 1253 AfriNIC Prefixes per ASN: 21.33 AfriNIC Region origin ASes announcing only one prefix: 430 AfriNIC Region transit ASes present in the Internet Routing Table: 252 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 526 Number of AfriNIC addresses announced to Internet: 103380224 Equivalent to 6 /8s, 41 /16s and 117 /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 7545 4662 542 545 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4656 4192 74 ERX-CERNET-BKB China Education and Rese 7552 3096 1241 50 VIETEL-AS-AP Viettel Group, VN 45899 3044 1737 111 VNPT-AS-VN VNPT Corp, VN 4766 2813 11125 769 KIXS-AS-KR Korea Telecom, KR 9829 2752 1496 552 BSNL-NIB National Internet Backbone, IN 9808 2429 8699 26 CMNET-GD Guangdong Mobile Communication 9394 2345 4906 29 CTTNET China TieTong Telecommunications 4755 2146 422 180 TATACOMM-AS TATA Communications formerl 17974 2009 968 50 TELKOMNET-AS2-AP PT Telekomunikasi Indo 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 6327 3611 1326 93 SHAW - Shaw Communications Inc., CA 11492 3524 228 608 CABLEONE - CABLE ONE, INC., US 22773 3306 2977 165 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2501 5370 1060 AMAZON-02 - Amazon.com, Inc., US 16625 2282 1268 1750 AKAMAI-AS - Akamai Technologies, Inc., 20115 2147 2739 544 CHARTER-20115 - Charter Communications, 18566 2123 405 108 MEGAPATH5-US - MegaPath Corporation, US 30036 2115 351 192 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 5650 2091 3074 1462 FRONTIER-FRTR - Frontier Communications 209 2081 5094 583 CENTURYLINK-US-LEGACY-QWEST - CenturyLi 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 5371 1626 137 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3035 378 44 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2634 545 1911 AKAMAI-ASN1, US 12389 2226 2221 637 ROSTELECOM-AS, RU 34984 2061 341 537 TELLCOM-AS, TR 9121 1681 1692 18 TTNET, TR 13188 1604 100 46 TRIOLAN, UA 9009 1343 145 746 M247, GB 8402 1305 545 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 8151 5587 3331 591 Uninet S.A. de C.V., MX 10620 2749 412 1054 Telmex Colombia S.A., CO 11830 2702 384 34 Instituto Costarricense de Electricidad 6503 1507 433 54 Axtel, S.A.B. de C.V., MX 7303 1430 961 231 Telecom Argentina S.A., AR 28573 1301 2246 186 CLARO S.A., BR 6147 1270 377 28 Telefonica del Peru S.A.A., PE 3816 1022 506 114 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 931 144 66 Alestra, S. de R.L. de C.V., MX 13999 929 517 243 Mega Cable, S.A. de C.V., MX 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 1202 393 21 LINKdotNET-AS, EG 37611 929 107 9 Afrihost, ZA 24835 848 636 22 RAYA-AS, EG 36903 827 416 125 MT-MPLS, MA 36992 811 1534 59 ETISALAT-MISR, EG 8452 689 1731 20 TE-AS TE-AS, EG 29571 484 70 13 ORANGE-COTE-IVOIRE, CI 37492 470 470 57 ORANGE-, TN 15399 429 45 11 WANANCHI-, KE 37342 420 32 1 MOVITEL, MZ 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 5587 3331 591 Uninet S.A. de C.V., MX 12479 5371 1626 137 UNI2-AS, ES 7545 4662 542 545 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4656 4192 74 ERX-CERNET-BKB China Education and Rese 39891 3778 203 20 ALJAWWALSTC-AS, SA 6327 3611 1326 93 SHAW - Shaw Communications Inc., CA 11492 3524 228 608 CABLEONE - CABLE ONE, INC., US 22773 3306 2977 165 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 7552 3096 1241 50 VIETEL-AS-AP Viettel Group, VN 45899 3044 1737 111 VNPT-AS-VN VNPT Corp, VN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5371 5234 UNI2-AS, ES 4538 4656 4582 ERX-CERNET-BKB China Education and Research Net 7545 4662 4117 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3611 3518 SHAW - Shaw Communications Inc., CA 22773 3306 3141 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 3096 3046 VIETEL-AS-AP Viettel Group, VN 8551 3035 2991 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 45899 3044 2933 VNPT-AS-VN VNPT Corp, VN 11492 3524 2916 CABLEONE - CABLE ONE, INC., 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 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65550 DOCUMENT 81.8.34.0/24 15924 BORUSANTELEKOM-AS, TR 65550 DOCUMENT 81.8.35.0/24 15924 BORUSANTELEKOM-AS, TR 1358592 UNALLOCATED 103.134.14.0/23 63956 COLO-AS-AP Colocation Australi 1358592 UNALLOCATED 103.134.15.0/24 63956 COLO-AS-AP Colocation Australi 65549 DOCUMENT 117.239.163.0/24 65544 UNKNOWN 224413 UNALLOCATED 131.221.136.0/24 264413 Conecta Telecom Ltda, BR 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US 64355 UNALLOCATED 156.40.196.0/24 30387 NIH-NET-NCCS - National Instit Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.220.48.0/20 36900 -Reserved AS-, ZZ 43.255.80.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 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:12 /9:10 /10:36 /11:100 /12:291 /13:567 /14:1134 /15:1907 /16:13363 /17:7914 /18:13889 /19:25651 /20:39785 /21:46161 /22:92355 /23:75415 /24:417393 /25:956 /26:842 /27:892 /28:27 /29:7 /30:15 /31:0 /32:197 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4251 5371 UNI2-AS, ES 6327 3383 3611 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2771 3524 CABLEONE - CABLE ONE, INC., US 22773 2546 3306 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2490 3035 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11830 2047 2702 Instituto Costarricense de Electricidad y Telec 18566 2018 2123 MEGAPATH5-US - MegaPath Corporation, US 30036 1862 2115 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1761 2091 FRONTIER-FRTR - Frontier Communications of Amer Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1607 2:890 4:22 5:2778 6:45 7:1 8:1179 12:1858 13:313 14:1914 15:39 16:4 17:226 18:58 20:49 23:2577 24:2522 25:2 27:2544 31:2071 32:94 35:36 36:834 37:3029 38:1692 39:295 40:121 41:3158 42:745 43:2003 44:144 45:6815 46:3228 47:250 49:1365 50:1095 51:322 52:1025 54:289 55:1 56:6 57:40 58:1708 59:1073 60:501 61:2058 62:1988 63:1800 64:4994 65:2189 66:4824 67:2701 68:1165 69:3545 70:1326 71:601 72:2383 74:2759 75:516 76:546 77:1710 78:1760 79:2319 80:1686 81:1448 82:1128 83:865 84:1098 85:2205 86:547 87:1549 88:1027 89:2429 90:217 91:6579 92:1273 93:2480 94:2521 95:3230 96:918 97:346 98:945 99:206 100:88 101:1153 102:422 103:20142 104:3508 105:248 106:885 107:1755 108:700 109:3482 110:1631 111:1876 112:1410 113:1406 114:1135 115:1719 116:1706 117:1873 118:2144 119:1624 120:1019 121:1032 122:2284 123:1643 124:1455 125:1962 128:1251 129:831 130:526 131:1627 132:731 133:218 134:1051 135:242 136:556 137:711 138:2018 139:846 140:575 141:840 142:795 143:1045 144:838 145:510 146:1262 147:792 148:1692 149:797 150:780 151:1010 152:1017 153:323 154:2618 155:867 156:1738 157:923 158:669 159:1924 160:1513 161:917 162:2674 163:792 164:1131 165:1577 166:428 167:1395 168:3276 169:870 170:4013 171:562 172:1104 173:2185 174:1017 175:896 176:2315 177:3994 178:2540 179:1334 180:2100 181:2406 182:2698 183:1068 184:1168 185:14814 186:3767 187:2424 188:2908 189:1967 190:8357 191:1407 192:10047 193:6588 194:5384 195:4055 196:2979 197:1640 198:5798 199:5979 200:7196 201:5068 202:10186 203:10197 204:4613 205:2972 206:3239 207:3283 208:3974 209:4232 210:3930 211:1991 212:3062 213:2903 214:1086 215:54 216:5968 217:2210 218:920 219:581 220:1869 221:966 222:998 223:1434 End of report From liam at fedney.org Fri Mar 1 21:44:24 2019 From: liam at fedney.org (L Sean Kennedy) Date: Fri, 1 Mar 2019 16:44:24 -0500 Subject: 2019 Program Committee Appointees Message-ID: Dear NANOG Community, Thanks for joining us in San Francisco and online for NANOG 75! I am excited to announce that 16 NANOG members accepted appointments to the Program Committee! There were 31 highly-qualified volunteers from the NANOG membership nominated for this year’s committee selection and it was a challenging exercise for the board to appoint a subset to serve this upcoming term. NANOG as an organization was founded by volunteers who set out to provide a high quality operator forum in North America. Despite the growth in NANOG’s programs, volunteers greatly outnumber professional staff and the volunteer-only Program Committee is responsible for soliciting, developing, and selecting all program content presented at NANOG meetings and other events. I personally thank each of the volunteers who were nominated for offering their time to NANOG and in early 2020 we hope to have them and other qualified candidates participating in our next appointment cycle to ensure appointment of a similar qualified and diverse cross-section of our community. Please join me in congratulating the PC members appointed. Tom Beecher, Jeff Bartig, Jason Bothe, Adam Davenport, Steve Feldman, Cat Gurinsky, Greg Hankins, Alex Latzko, Hossein Lotfi, Steve Meuse, Nagendra Kumar Nainar, Kat Parsons, Rekha Rawat, Brad Raymo, Matthew Ringel, and Anna Valsami Please thank and recognize the contributions of Christina Chu, Philippe Couture, Mohit Lad, Ryan Landry, Jeff Ringwelski, Krassimir Tzvetanov, Chris Woodfield, and Ryan Woolley for their service to NANOG on the Program Committee. In the coming weeks, the new Program Committee will hold its first meeting to develop content for NANOG 76 and select its leadership. The NANOG board is excited to see what the new PC will present to our community at that meeting and hope to see all of you in Washington DC in June! Thanks, Sean (for the NANOG Board of Directors) -------------- next part -------------- An HTML attachment was scrubbed... URL: From baldur.norddahl at gmail.com Sat Mar 2 17:18:41 2019 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 2 Mar 2019 18:18:41 +0100 Subject: Question about ISP billing procedures In-Reply-To: References: Message-ID: You can calculate the min and max by running it twice. Once with zero for missing values and once with max line speed. The true bill will be somewhere between min and max. If you are the ISP you would need to assume zero. You can only bill what you can prove. If you are the customer, you need to assume max. You can only claim excessive billing for what goes above what you can prove. Regards Baldur tor. 28. feb. 2019 04.32 skrev Daniel Rohan : > Can anyone shed light on how ISPs handle missing samples when calculating > p95s for monthly billing cycles? Do they fill null samples with zeros or > leave them as null? > > I’m working on a billing sanity tool and want to make sure to cover my > corner cases well. > > Thanks! > > Dan > -- > Thanks, Dan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Sat Mar 2 21:14:03 2019 From: jcurran at arin.net (John Curran) Date: Sat, 2 Mar 2019 21:14:03 +0000 Subject: ARIN upgrade completed (was: Re: FYI - Major upgrade this weekend to www.arin.net and ARIN Online) In-Reply-To: <835BE060-54F4-47D0-A0A2-1BA1D8AD1E71@arin.net> References: <1a0b2307-33c9-4592-1524-bdb97d198bd2@arin.net> <835BE060-54F4-47D0-A0A2-1BA1D8AD1E71@arin.net> Message-ID: <820D123B-B6F7-44F8-B05F-FBF835A3A447@arin.net> Folks - The upgrade to www.arin.net and the ARIN Online system has been completed as scheduled. Release notes are online here: https://www.arin.net/announcements/20190302/ Best wishes, /John John Curran President and CEO American Registry for Internet Numbers On 27 Feb 2019, at 12:02 PM, John Curran > wrote: Argh - my error on errant truncation. Correct link is further down the email, but also here - https://teamarin.net/2019/02/27/getting-ready-for-the-big-reveal/ /John John Curran President and CEO American Registry for Internet Numbers ... ________________________________ From: NANOG > on behalf of John Curran > Sent: Wednesday, February 27, 2019 10:56:27 AM To: nanog list Subject: FYI - Major upgrade this weekend to www.arin.net and ARIN Online NANOGers - This weekend there will be a major upgrade to www.arin.net website and the ARIN Online system. If you routinely use these systems, you might want to read what follows for an overview of the upcoming change – ... FYI, /John John Curran President and CEO American Registry for Internet Numbers Begin forwarded message: From: ARIN > Subject: [arin-announce] How Community Input Shaped Our New ARIN.NET Date: 27 February 2019 at 11:50:22 AM EST To: > On 2 March, we will be deploying a new and improved www.arin.net. This project is the product of collaboration with our community; user input was a driving factor at every stage. We encourage you to read our new blog post about the process and some of the changes you will see when we go live: https://teamarin.net/2019/02/27/getting-ready-for-the-big-reveal/ Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-announce Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccummings at coeur.com Sun Mar 3 01:27:41 2019 From: ccummings at coeur.com (Cummings, Chris) Date: Sun, 3 Mar 2019 01:27:41 +0000 Subject: AT&T or Cogent Assistance Message-ID: Good Evening, Can anyone from AT&T or Cogent assist me? I cannot connect between two of my sites, and the issue appears to be either on AT&T’s network or between AT&T and Cogent according to traceroute. All Internet traffic at both sites appears to be functioning, other than this site to site connectivity: Traceroute from side A, source IP 64.179.178.34: FW-A# exec traceroute 12.166.160.250 traceroute to 12.166.160.250 (12.166.160.250), 32 hops max, 3 probe packets per hop, 84 byte packets 1 64.179.178.33 2.297 ms 2.098 ms 1.849 ms 2 208.117.98.138 1.590 ms 1.643 ms 2.012 ms 3 10.255.0.0 11.100 ms 19.099 ms 22.795 ms 4 216.16.3.155 18.779 ms 18.644 ms 18.694 ms 5 38.142.172.9 27.814 ms 27.903 ms 27.844 ms 6 154.54.24.34 33.590 ms 33.645 ms 33.625 ms 7 154.54.45.18 33.418 ms 33.639 ms 33.808 ms 8 154.54.12.86 36.106 ms 35.741 ms 36.079 ms 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * Traceroute from side B, source IP 12.166.160.250: FW-B# exec traceroute 64.179.178.34 traceroute to 64.179.178.34 (64.179.178.34), 32 hops max, 3 probe packets per hop, 84 byte packets 1 12.166.160.249 0.148 ms 0.088 ms 0.082 ms 2 10.17.1.5 2.195 ms 2.281 ms 1.995 ms 3 10.17.0.5 4.179 ms 2.627 ms 3.879 ms 4 12.117.201.149 18.532 ms 18.482 ms 20.171 ms 5 12.122.158.170 87.847 ms * * 6 12.122.158.177 81.833 ms 86.028 ms 82.135 ms 7 12.122.5.229 88.562 ms 85.265 ms 84.468 ms 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * Both IPs in question here are setup to respond to ICMP ping. Thanks in advance! /chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Sun Mar 3 10:31:11 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 3 Mar 2019 12:31:11 +0200 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> Message-ID: <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> Hi all. Just an update on this... it did turn out to be an MTU issue which I've been working on since last year, November. The trick was finding the right combination of settings between my Mikrotik home router and one of our Cisco ASR1006 edge routers in my backbone that terminates the 6-in-4 tunnel. After testing this at the office, I was, then, sure that the problem was MTU-related as it only occurred at my house. My FTTH service is delivered over GPON, and after a bit of testing, concluded that my MTU for IPv4 is 1,452 bytes. Across the 6-in-4 tunnel, the tested MTU is 1,232 for IPv6. The Mikrotik will not pass any IPv6 traffic if the 6-in-4 tunnel does not have the minimum default MTU for IPv6, i.e., 1,280 bytes (even if the tunnel cannot actually transport 1,280 byte-sized packets). This is not documented anywhere, so it took a while to figure out. On the Cisco, you can't configure an IPv6 interface MTU lower than 1,280 bytes... but that is within the standard IPv6 spec., so no major drama. So the right combination of settings is to have 1,280 bytes on the Mikrotik and enable "ipv6 tcp adjust-mss 1232" on the Cisco (the latter for my specific case - yours may vary depending on your IPv4 conditions). Just wanted to update this thread in case someone else runs into this issue. Thanks for the clue, Mikael and all. Mark. On 13/Nov/18 12:38, Mark Tinka wrote: > > On 12/Nov/18 20:34, Mikael Abrahamsson wrote: > >>   >> >> Are you doing TCP MSS adjust/clamping? If you don't, try that and see >> if it helps. This might be a PMTUD issue. >> >> Otherwise if possible, try lowering the MTU sent in RA to the one you >> have on your tunnel (this depends on if this is available to you in >> your RA sending device). > Thanks, Mikael. > > I'll have a sniff and see of this helps. > > Mark. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Sun Mar 3 19:13:47 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 3 Mar 2019 21:13:47 +0200 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> Message-ID: <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> On 3/Mar/19 18:05, Jeroen Massar wrote: > IPv6 requires a minimum MTU of 1280. > > If you cannot transport it, then the transport (the tunnel in this case) needs to handle the fragmentation of packets of 1280 down to whatever does fit in the tunnel. As you know, IPv6 does not support fragmentation in transit. So that's not an option. Host fragmentation is per standard, but signaling of that was not so successful in IPv4. Real world scenarios for IPv6 (reasonably) apply here. > Have fun with all your UDP traffic that does not care about your TCP MSS adjustment. You just hid the problem... I considered this issue, but as with all things UDP re: fragmentation, it depends. Testing I've been doing all day shows previously (mostly-TCP) issues have resolved, and I've not run into any major problems that are impacting UDP. Nonetheless, I'm keeping an eye out. > > And a correctly configured MTU is especially going to be fun with "HTTP/3" that is being pushed through, even though the predecessor QUIC does not care about MTU at all... good that it is all in the hands of a company that can fix it themselves ;) Is it an ideal situation? About as ideal as flying in the cargo bay. But my reality is that until my FTTH provider can deliver native IPv6, this is what I have. Mark. From mark.tinka at seacom.mu Sun Mar 3 20:59:15 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 3 Mar 2019 22:59:15 +0200 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: <753803c3-cfab-28b6-19a9-e80233275b94@massar.ch> References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> <753803c3-cfab-28b6-19a9-e80233275b94@massar.ch> Message-ID: <0a327f8f-1a9e-333c-2493-064eef9d531d@seacom.mu> On 3/Mar/19 21:57, Jeroen Massar wrote: > The transport (tunnel) CAN support that kind of fragmentation. > > (e.g. the tunnel could chop up a 1280 byte packet into two packets and the remote then join them together; that is a "ethernet" level thing). If you have a working example between a Cisco IOS XE device and a Mikrotik router, I am all ears. > Real world for IPv6 is: do not try to transport it over a medium that does not support packets of at least 1280 bytes. Note I am not recommending this as a best practice. I believe the subscribers on this list are clued enough to discern that for themselves. But in the interest of posterity, let me make that explicit. > Maybe you should ask this "FTTH" provider to deliver a decent MTU size? (next to native IPv6, something something, 20+ years old protocol...) :-), you're a funny guy... maybe my provider and I will just get off the Internet altogether. Mark. From marka at isc.org Sun Mar 3 21:04:12 2019 From: marka at isc.org (Mark Andrews) Date: Mon, 4 Mar 2019 08:04:12 +1100 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> Message-ID: There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB getting back to the TCP servers. There are also IDIOTS that deploy load balancers that DO NOT LOOK INSIDE ICMP messages for redirecting ICMP messages to the correct back end. There are also IDOITS that rate limit PTB generation to ridiculously low rates. One should be able to generate PTB at line rate. Everyone that has configured mss-fix-up has contributed to misunderstanding that you can block ICMP. It is time we had a flag day to REMOVE mss-fix-up from all the boxes you control. We need to get PTB working and unfortunately that means that we need to stop pandering to admins who don’t know how IP is supposed to work. ICMP is NOT optional. If you don’t want to do PMTUD then DO NOT SEND packet bigger than the network MTU. For IPv6 set IPV6_USE_MIN_MTU 1 on the socket. On a properly written IP stack this will result in TCP MSS negotiation to the same value. Yes, it is a requirement of TCP to pay attention to this as it becomes the effective MTU of the outgoing interface even if it wasn’t explicitly written into the RFC that defined IPV6_USE_MIN_MTU. Mark > On 4 Mar 2019, at 6:13 am, Mark Tinka wrote: > > > > On 3/Mar/19 18:05, Jeroen Massar wrote: > >> IPv6 requires a minimum MTU of 1280. >> >> If you cannot transport it, then the transport (the tunnel in this case) needs to handle the fragmentation of packets of 1280 down to whatever does fit in the tunnel. > > As you know, IPv6 does not support fragmentation in transit. So that's > not an option. > > Host fragmentation is per standard, but signaling of that was not so > successful in IPv4. Real world scenarios for IPv6 (reasonably) apply here. > > >> Have fun with all your UDP traffic that does not care about your TCP MSS adjustment. You just hid the problem... > > I considered this issue, but as with all things UDP re: fragmentation, > it depends. > > Testing I've been doing all day shows previously (mostly-TCP) issues > have resolved, and I've not run into any major problems that are > impacting UDP. Nonetheless, I'm keeping an eye out. > > >> >> And a correctly configured MTU is especially going to be fun with "HTTP/3" that is being pushed through, even though the predecessor QUIC does not care about MTU at all... good that it is all in the hands of a company that can fix it themselves ;) > > Is it an ideal situation? About as ideal as flying in the cargo bay. But > my reality is that until my FTTH provider can deliver native IPv6, this > is what I have. > > Mark. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mark.tinka at seacom.mu Sun Mar 3 21:10:13 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 3 Mar 2019 23:10:13 +0200 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> Message-ID: <7c9f0bfe-fe82-0787-c555-a143dc721b0e@seacom.mu> On 3/Mar/19 23:04, Mark Andrews wrote: > There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB getting > back to the TCP servers. There are also IDIOTS that deploy load balancers that > DO NOT LOOK INSIDE ICMP messages for redirecting ICMP messages to the correct > back end. There are also IDOITS that rate limit PTB generation to ridiculously > low rates. One should be able to generate PTB at line rate. > > Everyone that has configured mss-fix-up has contributed to misunderstanding that > you can block ICMP. It is time we had a flag day to REMOVE mss-fix-up from all > the boxes you control. We need to get PTB working and unfortunately that means > that we need to stop pandering to admins who don’t know how IP is supposed to > work. ICMP is NOT optional. > > If you don’t want to do PMTUD then DO NOT SEND packet bigger than the network > MTU. For IPv6 set IPV6_USE_MIN_MTU 1 on the socket. On a properly written > IP stack this will result in TCP MSS negotiation to the same value. Yes, it is > a requirement of TCP to pay attention to this as it becomes the effective MTU > of the outgoing interface even if it wasn’t explicitly written into the RFC > that defined IPV6_USE_MIN_MTU. You're most welcome to my choir group, good sir. Mark. From list at satchell.net Sun Mar 3 22:33:59 2019 From: list at satchell.net (Stephen Satchell) Date: Sun, 3 Mar 2019 14:33:59 -0800 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> Message-ID: On 3/3/19 1:04 PM, Mark Andrews wrote: > There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB getting > back to the TCP servers. For those of us who are in the dark, "PTB" appears to refer to "Packet Too Big" responses in ICMPv6. Yes, some admins don't have fine-enough grain tools to block or throttle specific types of ICMP, but that's the fault of the vendors, not the admins. From marka at isc.org Sun Mar 3 23:16:13 2019 From: marka at isc.org (Mark Andrews) Date: Mon, 4 Mar 2019 10:16:13 +1100 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> Message-ID: <46A8769B-AFFD-4BFB-9AD0-88694DE31AA2@isc.org> > On 4 Mar 2019, at 9:33 am, Stephen Satchell wrote: > > On 3/3/19 1:04 PM, Mark Andrews wrote: >> There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB getting >> back to the TCP servers. > > For those of us who are in the dark, "PTB" appears to refer to "Packet > Too Big" responses in ICMPv6. > > Yes, some admins don't have fine-enough grain tools to block or throttle > specific types of ICMP, but that's the fault of the vendors, not the admins. No, it is the fault of the admins. They should be making it part of the purchasing decision if they want to filter ICMP. It’s not like selective filtering is a new idea. It is well over 20 years old at this stage. The amount of +20 year old equipment on the net is minimal. That said modern OS’s don’t need other equipment to “protect" them from ICMP of any form. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From chk at pobox.com Mon Mar 4 01:17:09 2019 From: chk at pobox.com (Harald Koch) Date: Sun, 03 Mar 2019 20:17:09 -0500 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> Message-ID: On Sun, Mar 3, 2019, at 17:35, Stephen Satchell wrote: > > Yes, some admins don't have fine-enough grain tools to block or throttle > specific types of ICMP, but that's the fault of the vendors, not the admins. We call these tunable parameters "nerd knobs". I used to create those knobs for firewalls. My experience then (and now, with my current employer) is that admins turn every knob you give them up to eleven; there is no finesse. The only answer was, and is, to remove the knobs altogether. (Can I join the choir too? :) -- Harald Koch chk at pobox.com From nanog at radu-adrian.feurdean.net Mon Mar 4 07:12:10 2019 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Mon, 04 Mar 2019 02:12:10 -0500 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> Message-ID: <222cf907-91ca-4a3f-a3b0-0aef5ae3e6bf@www.fastmail.com> On Sun, Mar 3, 2019, at 22:05, Mark Andrews wrote: > admins who don’t know how IP is supposed to work. You do realise that in "corporate world" that's more than 80% of network admins ? Some of them even make it to "audit" companies, so they can screw a company with clueful admins with their "mandatory reccomandations". > ICMP is NOT optional. Can we make a short rule that says: For ICMP, *ALLOW* *ALL* unless you do have a very specific and motivated reason to block some types. I would even go as far as "allow all icmp from any to any" (and if possible as the first firewall rule), but I do understand that may make some people have hives. From mark.tinka at seacom.mu Mon Mar 4 07:55:08 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 4 Mar 2019 09:55:08 +0200 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> Message-ID: <4ca19e6d-ac6c-34ac-bde6-358ace22f856@seacom.mu> On 4/Mar/19 03:17, Harald Koch wrote: > > (Can I join the choir too? :) But of course :-)... Mark. From mark.tinka at seacom.mu Mon Mar 4 08:00:03 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 4 Mar 2019 10:00:03 +0200 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: <222cf907-91ca-4a3f-a3b0-0aef5ae3e6bf@www.fastmail.com> References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> <222cf907-91ca-4a3f-a3b0-0aef5ae3e6bf@www.fastmail.com> Message-ID: <7b74e7f3-4eda-355a-9318-ad4a22298115@seacom.mu> On 4/Mar/19 09:12, Radu-Adrian Feurdean wrote: > Can we make a short rule that says: For ICMP, *ALLOW* *ALL* unless you do have a very specific and motivated reason to block some types. > I would even go as far as "allow all icmp from any to any" (and if possible as the first firewall rule), but I do understand that may make some people have hives. Not to be the wet blanket, but we've be crying about this since before I knew what CLI meant, and it either didn't work or has gotten even worse. That is how we ended up with all manner of hacks to work around failure to reliably deliver PTB messages. We've been crying about the same during the IPv6 era, and we appear to be running the same hacks for it too. Is there any reason to expect things to change given the continued "crying about it" approach? Just look at what I had to (unhappily) do over the weekend :-(. I don't have the answers yet, but just because it now ends with a "6", doesn't mean we shall necessarily drop our IPv4 bad habits. Perhaps it's time to consider a different approach, if we don't want to resign ourselves to the death of ICMP as we know it, and simply talking about what could have been had its full potential been realized. Mark. From saku at ytti.fi Mon Mar 4 08:13:53 2019 From: saku at ytti.fi (Saku Ytti) Date: Mon, 4 Mar 2019 10:13:53 +0200 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: <7b74e7f3-4eda-355a-9318-ad4a22298115@seacom.mu> References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> <222cf907-91ca-4a3f-a3b0-0aef5ae3e6bf@www.fastmail.com> <7b74e7f3-4eda-355a-9318-ad4a22298115@seacom.mu> Message-ID: On Mon, Mar 4, 2019 at 10:02 AM Mark Tinka wrote: > > Can we make a short rule that says: For ICMP, *ALLOW* *ALL* unless you do have a very specific and motivated reason to block some types. > > I would even go as far as "allow all icmp from any to any" (and if possible as the first firewall rule), but I do understand that may make some people have hives. > > Not to be the wet blanket, but we've be crying about this since before I > knew what CLI meant, and it either didn't work or has gotten even worse. > That is how we ended up with all manner of hacks to work around failure > to reliably deliver PTB messages. Not just ICMP but everything. We've designed these nice extendible protocols, but we've configured network so that we can't extend them. Like why is QUIC riding on UDP, instead of having its own L4 protocol number. Because of HTTP/3 majority of Internet traffic will be UDP, and due to its reflection potential in other applications that is not obvious net win. We should just retire UDP with status of 'trusted network only L4' and use something like QUIC for all untrusted L4 applications, where we've thought about issues like reflection. -- ++ytti From miesi at india.com Fri Mar 1 08:47:23 2019 From: miesi at india.com (Thomas Mieslinger) Date: Fri, 1 Mar 2019 09:47:23 +0100 Subject: a quick survey about LLDP and similar In-Reply-To: References: <87d0ncl22g.fsf@snoopy.tippete.net> Message-ID: <2052a844-ec08-5bf1-233f-8c17ed4790b4@india.com> A little more on the "it depends" switches connected to end-user/customer gear: never ever. switch to switch, switch to router interfaces: yes, to validate cabling and resolve problems as quickly as possible. switch to server interfaces: only to servers of teams you can trust. temporarily enable to untrusted teams if you'd need to order remote hands to lookup the exact cabling in case of problems. Thomas On 2/28/19 10:27 AM, Owen DeLong wrote: > The problem with your survey is that there’s no option to answer “it depends”. > > Hard yes or no answers aren’t realistic to the questions you’re asking because the context, > security parameters, sensitivity, and other parameters about the network all factor into a > decision whether to run or not run such protocols. > > There are some environments where the benefit and convenience is moderately high > and the risk is extremely low. There are other environments where the benefit is relatively > low, but the risks are significantly higher. > > Owen > > >> On Feb 28, 2019, at 01:00 , Pierfrancesco Caci wrote: >> >> >> Hello, >> having a bit of a debate in my team about turning on LLDP and/or CDP. >> I would appreciate if you could spend a minute answering this >> survey so I have some numbers to back up my reasoning, or to accept >> defeat. >> >> https://www.surveymonkey.com/r/TH3WCWP >> >> Feel free to cross-post to other relevant lists. >> >> Thank you >> >> Pf >> >> -- >> Pierfrancesco Caci, ik5pvx > From jeroen at massar.ch Sun Mar 3 16:05:02 2019 From: jeroen at massar.ch (Jeroen Massar) Date: Sun, 3 Mar 2019 17:05:02 +0100 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> Message-ID: On 2019-03-03 11:31, Mark Tinka wrote: [..] > Across the 6-in-4 tunnel, the tested MTU is 1,232 for IPv6. IPv6 requires a minimum MTU of 1280. If you cannot transport it, then the transport (the tunnel in this case) needs to handle the fragmentation of packets of 1280 down to whatever does fit in the tunnel. [..] > So the right combination of settings is to have 1,280 bytes on the Mikrotik and enable "ipv6 tcp adjust-mss 1232" on the Cisco (the latter for my specific case - yours may vary depending on your IPv4 conditions). Have fun with all your UDP traffic that does not care about your TCP MSS adjustment. You just hid the problem... And a correctly configured MTU is especially going to be fun with "HTTP/3" that is being pushed through, even though the predecessor QUIC does not care about MTU at all... good that it is all in the hands of a company that can fix it themselves ;) Greets, Jeroen From jeroen at massar.ch Sun Mar 3 19:57:02 2019 From: jeroen at massar.ch (Jeroen Massar) Date: Sun, 3 Mar 2019 20:57:02 +0100 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> Message-ID: <753803c3-cfab-28b6-19a9-e80233275b94@massar.ch> On 2019-03-03 20:13, Mark Tinka wrote: > > > On 3/Mar/19 18:05, Jeroen Massar wrote: > >> IPv6 requires a minimum MTU of 1280. >> >> If you cannot transport it, then the transport (the tunnel in this case) needs to handle the fragmentation of packets of 1280 down to whatever does fit in the tunnel. > > As you know, IPv6 does not support fragmentation in transit. So that's > not an option. The transport (tunnel) CAN support that kind of fragmentation. (e.g. the tunnel could chop up a 1280 byte packet into two packets and the remote then join them together; that is a "ethernet" level thing). Indeed, IPv6 won't do it: get a better transport. > Host fragmentation is per standard, but signaling of that was not so > successful in IPv4. Real world scenarios for IPv6 (reasonably) apply here. Real world for IPv6 is: do not try to transport it over a medium that does not support packets of at least 1280 bytes. >> Have fun with all your UDP traffic that does not care about your TCP MSS adjustment. You just hid the problem... > > I considered this issue, but as with all things UDP re: fragmentation, > it depends. > > Testing I've been doing all day shows previously (mostly-TCP) issues > have resolved, and I've not run into any major problems that are > impacting UDP. Nonetheless, I'm keeping an eye out. > > >> >> And a correctly configured MTU is especially going to be fun with "HTTP/3" that is being pushed through, even though the predecessor QUIC does not care about MTU at all... good that it is all in the hands of a company that can fix it themselves ;) > > Is it an ideal situation? About as ideal as flying in the cargo bay. But > my reality is that until my FTTH provider can deliver native IPv6, this > is what I have. Maybe you should ask this "FTTH" provider to deliver a decent MTU size? (next to native IPv6, something something, 20+ years old protocol...) Greets, Jeroen From contemno at gmail.com Mon Mar 4 01:42:02 2019 From: contemno at gmail.com (Joshua Miller) Date: Sun, 3 Mar 2019 20:42:02 -0500 Subject: Best practices for BGP Communities Message-ID: Hello everybody, A while back I read somewhere that transit providers shouldn't delete communities unless the communities have a specific impact to their network, but my google-fu is failing me and I can't find any sources. Is this still the case? Does anyone have a source for the practice of leaving unknown communities alone or deleting them? Best, Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: From woody at pch.net Mon Mar 4 17:54:59 2019 From: woody at pch.net (Bill Woodcock) Date: Mon, 4 Mar 2019 09:54:59 -0800 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: References: Message-ID: <6A490C17-72DA-4B52-BE26-CD5E04B2D52C@pch.net> > On Feb 26, 2019, at 1:34 PM, James Renken via NANOG wrote: > > On Feb 25, 2019, at 5:20 AM, Bill Woodcock wrote: >> We know that neither Comodo nor Let's Encrypt were DNSSEC validating before issuing certs. > > I’d like to clarify that Let’s Encrypt has always validated DNSSEC, dating to before we issued our first publicly trusted certificate in September 2015. Yes, my apologies… Comodo may well have been used in the attack against us _because_ Let’s Encrypt was DNSSEC validating. I’m sorry for tarring both Let’s Encrypt and Comodo with the same brush. The fact remains, however, that both Let’s Encrypt and Comodo are facilitating these hijacks by issuing illegitimate certificates to attackers. So, ipso facto, both organizations’ security practices are insufficient. We had what I thought to be a productive call with Jacob Hoffman-Andrews, of Let’s Encrypt, late last week, and arrived at a couple of possibilities for improving the situation a bit, but I don’t imagine that PCH has the expertise to contribute substantively to CA business process improvements, as that’s well outside our field. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From jtk at depaul.edu Mon Mar 4 18:15:11 2019 From: jtk at depaul.edu (John Kristoff) Date: Mon, 4 Mar 2019 12:15:11 -0600 Subject: Best practices for BGP Communities In-Reply-To: <0151bae74dec44b89820fa6522bcdf58@XCASPRD01.dpu.depaul.edu> References: <0151bae74dec44b89820fa6522bcdf58@XCASPRD01.dpu.depaul.edu> Message-ID: <20190304121511.18dff1b9@p50.localdomain> On Mon, 4 Mar 2019 01:42:02 +0000 Joshua Miller wrote: > A while back I read somewhere that transit providers shouldn't delete > communities unless the communities have a specific impact to their > network, but my google-fu is failing me and I can't find any sources. Perhaps you're referring to this recent work? John From eparra at zscaler.com Mon Mar 4 18:19:36 2019 From: eparra at zscaler.com (Eddie Parra) Date: Mon, 4 Mar 2019 10:19:36 -0800 Subject: HULU NOC In-Reply-To: References: Message-ID: John, I have used supportrequest at hulu.com prior. Not sure if this is valid anymore. -Eddie > On Feb 28, 2019, at 12:33 PM, John Alcock wrote: > > Afternoon, > > I have searched the forums and have had no luck. > > We have just received a new block of ip's. None of my subscribers can get to Hulu. I have started updating all the major GeoIP Databases. > > I figure I need to get Hulu to update their database. Of course calling regular support is useless > > Anyone have a contact? > > John Alcock > john at alcock.org > Network Engineer > Highland Communications -------------- next part -------------- An HTML attachment was scrubbed... URL: From saku at ytti.fi Mon Mar 4 19:06:30 2019 From: saku at ytti.fi (Saku Ytti) Date: Mon, 4 Mar 2019 21:06:30 +0200 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: <20190227100105.GF19597@arundodonax.nekodune.net> References: <20190227100105.GF19597@arundodonax.nekodune.net> Message-ID: Hey Jean, > I confess using IPv6 behind a 6in4 tunnel because the "Business-Class" service > of the concerned operator doesn't handle IPv6 yet. > > as such, I realised that, as far as I can figure, ICMPv6 packet "too-big" (rfc 4443) > seem to be ignored or filtered at ~60% of ClouFlare's http farms Might be related to this: https://blog.cloudflare.com/path-mtu-discovery-in-practice/ If you run ECMP then the hash algorithms make no guarantees ICMP messages generated by transit devices reach the correct host. -- ++ytti From saku at ytti.fi Mon Mar 4 19:08:28 2019 From: saku at ytti.fi (Saku Ytti) Date: Mon, 4 Mar 2019 21:08:28 +0200 Subject: a quick survey about LLDP and similar In-Reply-To: <2052a844-ec08-5bf1-233f-8c17ed4790b4@india.com> References: <87d0ncl22g.fsf@snoopy.tippete.net> <2052a844-ec08-5bf1-233f-8c17ed4790b4@india.com> Message-ID: Hey Thomas, > switches connected to end-user/customer gear: never ever. > switch to server interfaces: only to servers of teams you can trust. > temporarily enable to untrusted teams if you'd need to order remote > hands to lookup the exact cabling in case of problems. What are the problems in these scenarios LLDP may cause? -- ++ytti From marka at isc.org Mon Mar 4 22:25:48 2019 From: marka at isc.org (Mark Andrews) Date: Tue, 5 Mar 2019 09:25:48 +1100 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: References: <20190227100105.GF19597@arundodonax.nekodune.net> Message-ID: <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> > On 5 Mar 2019, at 6:06 am, Saku Ytti wrote: > > Hey Jean, > >> I confess using IPv6 behind a 6in4 tunnel because the "Business-Class" service >> of the concerned operator doesn't handle IPv6 yet. >> >> as such, I realised that, as far as I can figure, ICMPv6 packet "too-big" (rfc 4443) >> seem to be ignored or filtered at ~60% of ClouFlare's http farms > > Might be related to this: > https://blog.cloudflare.com/path-mtu-discovery-in-practice/ > > If you run ECMP then the hash algorithms make no guarantees ICMP > messages generated by transit devices reach the correct host. Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if they have installed broken ECMP devices. The simplest way to do that is to set the interface MTUs to 1280 on all the servers. Why should the rest of the world have to put up with their inability to purchase devices that work with RFC compliant data streams. Mark > -- > ++ytti -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mark.tinka at seacom.mu Tue Mar 5 06:18:16 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 5 Mar 2019 08:18:16 +0200 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> References: <20190227100105.GF19597@arundodonax.nekodune.net> <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> Message-ID: <8135e3e6-62e4-52f7-e320-cdba86ff4b4e@seacom.mu> On 5/Mar/19 00:25, Mark Andrews wrote: > > Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if > they have installed broken ECMP devices. The simplest way to do that > is to set the interface MTUs to 1280 on all the servers. Why should > the rest of the world have to put up with their inability to purchase > devices that work with RFC compliant data streams. I've had this issue with cdnjs.cloudflare.com for the longest time at my house. But as some of you may recall, my little unwanted TCP MSS hack for IPv6 last weekend fixed that issue for me. Not ideal, and I so wish IPv6 would work as designed, but... Mark. From marka at isc.org Tue Mar 5 06:26:51 2019 From: marka at isc.org (Mark Andrews) Date: Tue, 5 Mar 2019 17:26:51 +1100 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: <8135e3e6-62e4-52f7-e320-cdba86ff4b4e@seacom.mu> References: <20190227100105.GF19597@arundodonax.nekodune.net> <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> <8135e3e6-62e4-52f7-e320-cdba86ff4b4e@seacom.mu> Message-ID: <8D69F871-F8AC-4E42-BF43-D68FD4240B0D@isc.org> > On 5 Mar 2019, at 5:18 pm, Mark Tinka wrote: > > > > On 5/Mar/19 00:25, Mark Andrews wrote: > >> >> Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if >> they have installed broken ECMP devices. The simplest way to do that >> is to set the interface MTUs to 1280 on all the servers. Why should >> the rest of the world have to put up with their inability to purchase >> devices that work with RFC compliant data streams. > > I've had this issue with cdnjs.cloudflare.com for the longest time at my > house. But as some of you may recall, my little unwanted TCP MSS hack > for IPv6 last weekend fixed that issue for me. > > Not ideal, and I so wish IPv6 would work as designed, but… It does work as designed except when crap middleware is added. ECMP should be using the flow label with IPv6. It has the advantage that it works for non-0-offset fragments as well as 0-offset fragments and also works for transports other than TCP and UDP. This isn’t a protocol failure. It is shitty implementations. > Mark. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mark.tinka at seacom.mu Tue Mar 5 06:34:03 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 5 Mar 2019 08:34:03 +0200 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: <8D69F871-F8AC-4E42-BF43-D68FD4240B0D@isc.org> References: <20190227100105.GF19597@arundodonax.nekodune.net> <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> <8135e3e6-62e4-52f7-e320-cdba86ff4b4e@seacom.mu> <8D69F871-F8AC-4E42-BF43-D68FD4240B0D@isc.org> Message-ID: <4728d664-27a3-6014-d42c-080be7d375b4@seacom.mu> On 5/Mar/19 08:26, Mark Andrews wrote: > It does work as designed except when crap middleware is added. ECMP > should be using the flow label with IPv6. It has the advantage that > it works for non-0-offset fragments as well as 0-offset fragments and > also works for transports other than TCP and UDP. This isn’t a protocol > failure. It is shitty implementations. That's what I mean... we find ways to break protocols ourselves. Mark. From joelja at bogus.com Tue Mar 5 09:20:11 2019 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 5 Mar 2019 01:20:11 -0800 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: <8D69F871-F8AC-4E42-BF43-D68FD4240B0D@isc.org> References: <20190227100105.GF19597@arundodonax.nekodune.net> <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> <8135e3e6-62e4-52f7-e320-cdba86ff4b4e@seacom.mu> <8D69F871-F8AC-4E42-BF43-D68FD4240B0D@isc.org> Message-ID: Sent from my iPhone > On Mar 4, 2019, at 22:26, Mark Andrews wrote: > > > >> On 5 Mar 2019, at 5:18 pm, Mark Tinka wrote: >> >> >> >>> On 5/Mar/19 00:25, Mark Andrews wrote: >>> >>> >>> Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if >>> they have installed broken ECMP devices. The simplest way to do that >>> is to set the interface MTUs to 1280 on all the servers. Why should >>> the rest of the world have to put up with their inability to purchase >>> devices that work with RFC compliant data streams. >> >> I've had this issue with cdnjs.cloudflare.com for the longest time at my >> house. But as some of you may recall, my little unwanted TCP MSS hack >> for IPv6 last weekend fixed that issue for me. >> >> Not ideal, and I so wish IPv6 would work as designed, but… > > It does work as designed except when crap middleware is added. ECMP > should be using the flow label with IPv6. It has the advantage that > it works for non-0-offset fragments as well as 0-offset fragments and > also works for transports other than TCP and UDP. This isn’t a protocol > failure. It is shitty implementations. Your mobile carrier’s stateless tcp accelerator should stop sending acks with a zero flow label so we can actually identify them as part of the same flow... There a lot of headwind in the real world for using the flow label as a hash component. > >> Mark. > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > From saku at ytti.fi Tue Mar 5 09:31:04 2019 From: saku at ytti.fi (Saku Ytti) Date: Tue, 5 Mar 2019 11:31:04 +0200 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> References: <20190227100105.GF19597@arundodonax.nekodune.net> <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> Message-ID: On Tue, Mar 5, 2019 at 12:26 AM Mark Andrews wrote: > Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if > they have installed broken ECMP devices. The simplest way to do that Out of curiosity does that imply you are aware of non-broken ECMP devices, which are able to hash on the embedded original packet? -- ++ytti From joelja at bogus.com Tue Mar 5 10:09:15 2019 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 5 Mar 2019 02:09:15 -0800 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: References: <20190227100105.GF19597@arundodonax.nekodune.net> <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> Message-ID: <7FFCECD1-B7AF-4910-B98E-25134E9C3DCB@bogus.com> Sent from my iPhone > On Mar 5, 2019, at 01:31, Saku Ytti wrote: > >> On Tue, Mar 5, 2019 at 12:26 AM Mark Andrews wrote: >> >> Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if >> they have installed broken ECMP devices. The simplest way to do that > > Out of curiosity does that imply you are aware of non-broken ECMP > devices, which are able to hash on the embedded original packet? Parsing the icmp payload was something we considered in rfc7690 but wasn’t one the approaches we pursued (we broadcasted the ptb to all hosts on the segment(s) behind the load balancers in our original implementation). It actually seems like it is becoming feasible to do in an Ethernet switch ASIC like tofino if that is what you want to burn real estate on. Being worthwhile is another matter. > > -- > ++ytti > From bellman at nsc.liu.se Tue Mar 5 10:54:34 2019 From: bellman at nsc.liu.se (Thomas Bellman) Date: Tue, 5 Mar 2019 11:54:34 +0100 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: <8D69F871-F8AC-4E42-BF43-D68FD4240B0D@isc.org> References: <20190227100105.GF19597@arundodonax.nekodune.net> <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> <8135e3e6-62e4-52f7-e320-cdba86ff4b4e@seacom.mu> <8D69F871-F8AC-4E42-BF43-D68FD4240B0D@isc.org> Message-ID: <77868665-af7a-27db-4171-31b629ee0cd9@nsc.liu.se> On 2019-03-05 07:26 CET, Mark Andrews wrote: > It does work as designed except when crap middleware is added. ECMP > should be using the flow label with IPv6. It has the advantage that > it works for non-0-offset fragments as well as 0-offset fragments and > also works for transports other than TCP and UDP. This isn’t a protocol > failure. It is shitty implementations. Out of curiosity, which operating systems put anything useful (for use in ECMP) into the flow label of IPv6 packets? At the moment, I only have access to CentOS 6 and CentOS 7 machines, and both of them set the flow label to zero for all traffic. There is also the problem that the device generating the Packet Too Big ICMP, is not the same as the end host that the big packet was destined for, and does not know what flow label the end host would have set in its TCP responses. RFC 6437 is also explicit that: o Forwarding nodes such as routers and load distributors MUST NOT depend only on Flow Label values being uniformly distributed. In any usage such as a hash key for load distribution, the Flow Label bits MUST be combined at least with bits from other sources within the packet, so as to produce a constant hash value for each flow In practice, using at least the source and destination IP(v6) addresses in addition to the flow label. But the ICMP packet has a different source address than TCP responses from the end host. Further problem is that the TCP responses from the destination end host might not even be *passing* the router that generates a Packet Too Big ICMP error. In an anycast scenario, that router might have a route to the sending IPv6 address that goes to a different datacenter than the host that sent the large packet. E.g, consider the following network: A1 A2 | | DC1 DC2 / \ / / \ / / \ / R1 R2 \ / \ / \ / R3 | B A1 and A2 are hosts in different datacenters, using the same anycast address A. Host B initiates a TCP session with address A, R3 selects the route via R1, and thus reaches A1 in datacenter DC1. A1 sends a large packet towards B, but the router in DC1 elects to send that via R2. R2 generates a PTB ICMP, but has its best route to address A towards DC2... /Bellman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From saku at ytti.fi Tue Mar 5 11:05:09 2019 From: saku at ytti.fi (Saku Ytti) Date: Tue, 5 Mar 2019 13:05:09 +0200 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: <7FFCECD1-B7AF-4910-B98E-25134E9C3DCB@bogus.com> References: <20190227100105.GF19597@arundodonax.nekodune.net> <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> <7FFCECD1-B7AF-4910-B98E-25134E9C3DCB@bogus.com> Message-ID: On Tue, Mar 5, 2019 at 12:09 PM Joel Jaeggli wrote: > Parsing the icmp payload was something we considered in rfc7690 but wasn’t one the approaches we pursued (we broadcasted the ptb to all hosts on the segment(s) behind the load balancers in our original implementation). > > It actually seems like it is becoming feasible to do in an Ethernet switch ASIC like tofino if that is what you want to burn real estate on. Being worthwhile is another matter. It is definitely possible in all relevant existing NPUs like Trio, Solar, FP, EZChip, Lightspeed et.al. As it is within visibility of lookup engine and it is at fixed offset. So not only possible but also cheap. -- ++ytti From sthaug at nethelp.no Tue Mar 5 12:09:24 2019 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 05 Mar 2019 13:09:24 +0100 (CET) Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms,Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: <77868665-af7a-27db-4171-31b629ee0cd9@nsc.liu.se> References: <8135e3e6-62e4-52f7-e320-cdba86ff4b4e@seacom.mu> <8D69F871-F8AC-4E42-BF43-D68FD4240B0D@isc.org> <77868665-af7a-27db-4171-31b629ee0cd9@nsc.liu.se> Message-ID: <20190305.130924.250575559.sthaug@nethelp.no> > Out of curiosity, which operating systems put anything useful (for use > in ECMP) into the flow label of IPv6 packets? At the moment, I only > have access to CentOS 6 and CentOS 7 machines, and both of them set the > flow label to zero for all traffic. FreeBSD 11.2-STABLE. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From rsk at gsp.org Tue Mar 5 12:14:01 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 5 Mar 2019 07:14:01 -0500 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> Message-ID: <20190305121401.GA12619@gsp.org> On Mon, Mar 04, 2019 at 08:04:12AM +1100, Mark Andrews wrote: > ICMP is NOT optional. I've pointed folks at this for years: ICMP Packet Filtering v1.2 http://www.cymru.com/Documents/icmp-messages.html ---rsk From saku at ytti.fi Tue Mar 5 12:35:13 2019 From: saku at ytti.fi (Saku Ytti) Date: Tue, 5 Mar 2019 14:35:13 +0200 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: <20190305121401.GA12619@gsp.org> References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> <20190305121401.GA12619@gsp.org> Message-ID: Hey Rich, > I've pointed folks at this for years: > ICMP Packet Filtering v1.2 > http://www.cymru.com/Documents/icmp-messages.html To me this seems anti-pattern. It seems it was written on basis of 'what we know we allow, what we don't know we deny'. With assumption that ICMP dangerous. Similarly we break IP extensibility by not allowing IP protocols we don't know about. There are many, hopefully obvious reasons that just because we don't know about it, doesn't mean it's dangerous. One more obvious is, that it may not exist yet. To me, the correct pattern is here is to deny things you know to be harmful and can justify it reasonably and test that justification over time for its validity. One particular example springs to mind, ICMP Timestamp, this allows you to measure unidirectional latency to millisecond precision, unless we specifically break it. It's been useful troubleshooting tool to me in the past, saving time and money. -- ++ytti From list at satchell.net Tue Mar 5 14:53:16 2019 From: list at satchell.net (Stephen Satchell) Date: Tue, 5 Mar 2019 06:53:16 -0800 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: <77868665-af7a-27db-4171-31b629ee0cd9@nsc.liu.se> References: <20190227100105.GF19597@arundodonax.nekodune.net> <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> <8135e3e6-62e4-52f7-e320-cdba86ff4b4e@seacom.mu> <8D69F871-F8AC-4E42-BF43-D68FD4240B0D@isc.org> <77868665-af7a-27db-4171-31b629ee0cd9@nsc.liu.se> Message-ID: On 3/5/19 2:54 AM, Thomas Bellman wrote: > Out of curiosity, which operating systems put anything useful (for use > in ECMP) into the flow label of IPv6 packets? At the moment, I only > have access to CentOS 6 and CentOS 7 machines, and both of them set the > flow label to zero for all traffic. Did you submit a bug report? From adamv0025 at netconsultings.com Tue Mar 5 14:54:34 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Tue, 5 Mar 2019 14:54:34 -0000 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> <20190305121401.GA12619@gsp.org> Message-ID: <005301d4d363$5bd2ed40$1378c7c0$@netconsultings.com> > From: NANOG On Behalf Of Saku Ytti > > Hey Rich, > > > I've pointed folks at this for years: > > ICMP Packet Filtering v1.2 > > http://www.cymru.com/Documents/icmp-messages.html > > > To me, the correct pattern is here is to deny things you know to be harmful > and can justify it reasonably and test that justification over time for its > validity. > Let me play a devil's advocate here, the above statement begs a question then, how do you know all that is harmful would you test for every possible extension and hw/sw permutation? So there would be 3 sets (though lines might be blurred) known safe, known harmful and the biggest of them unknown unknowns. Now as an operator of a commercial network (i.e. your customers like it mostly up) wouldn't you do a calculated risk evaluation and opt for the known safe -which you know 99% of your customers use and block the rest while pissing off the remaining 1%? I know it sounds awful (like a calculations for vehicle safety recalls), but ... adam From saku at ytti.fi Tue Mar 5 14:59:31 2019 From: saku at ytti.fi (Saku Ytti) Date: Tue, 5 Mar 2019 16:59:31 +0200 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: <005301d4d363$5bd2ed40$1378c7c0$@netconsultings.com> References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> <20190305121401.GA12619@gsp.org> <005301d4d363$5bd2ed40$1378c7c0$@netconsultings.com> Message-ID: On Tue, Mar 5, 2019 at 4:54 PM wrote: > Let me play a devil's advocate here, the above statement begs a question then, how do you know all that is harmful would you test for every possible extension and hw/sw permutation? > So there would be 3 sets (though lines might be blurred) known safe, known harmful and the biggest of them unknown unknowns. > Now as an operator of a commercial network (i.e. your customers like it mostly up) wouldn't you do a calculated risk evaluation and opt for the known safe -which you know 99% of your customers use and block the rest while pissing off the remaining 1%? > I know it sounds awful (like a calculations for vehicle safety recalls), but ... You don't know. Everything is horribly broken anyhow and if you are not pwned, the main reason is that you're not attractive target. If you are being targeted, you will be pwned by zero to modest budget. Attacker budget leverage to defender is ridiculous. And ICMP won't be the vector. Fear is excellent marketing tool, as we can see in politics, works every time. But I rather fix realised problems, rather than make unprovable assumptions of actions yielding to net benefit. The assumption here is, if we just allow ICMP types A, B and C we are gaining in security, can we substantiate that claim at all? We can substantiate easily that the proposed ICMP filter breaks real useful ICMP tooling. -- ++ytti From jbarnes at essex.k12.va.us Mon Mar 4 21:19:40 2019 From: jbarnes at essex.k12.va.us (Jon Barnes) Date: Mon, 4 Mar 2019 16:19:40 -0500 Subject: Looking for a Google contact Message-ID: Can someone contact me off list about an issue. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn at mork.no Tue Mar 5 16:08:59 2019 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Tue, 05 Mar 2019 17:08:59 +0100 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: (Stephen Satchell's message of "Tue, 5 Mar 2019 06:53:16 -0800") References: <20190227100105.GF19597@arundodonax.nekodune.net> <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> <8135e3e6-62e4-52f7-e320-cdba86ff4b4e@seacom.mu> <8D69F871-F8AC-4E42-BF43-D68FD4240B0D@isc.org> <77868665-af7a-27db-4171-31b629ee0cd9@nsc.liu.se> Message-ID: <87va0x8fs4.fsf@miraculix.mork.no> Stephen Satchell writes: > On 3/5/19 2:54 AM, Thomas Bellman wrote: >> Out of curiosity, which operating systems put anything useful (for use >> in ECMP) into the flow label of IPv6 packets? At the moment, I only >> have access to CentOS 6 and CentOS 7 machines, and both of them set the >> flow label to zero for all traffic. > > Did you submit a bug report? I believe this was fixed 5 years ago (in Linux v3.17): https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cb1ce2ef387b01686469487edd45994872d52d73 But RHEL and CentOS are using kernels from the stone age, so they haven't noticed yet. Bjørn From hf0002+nanog at uah.edu Tue Mar 5 16:23:33 2019 From: hf0002+nanog at uah.edu (Hunter Fuller) Date: Tue, 5 Mar 2019 10:23:33 -0600 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: <87va0x8fs4.fsf@miraculix.mork.no> References: <20190227100105.GF19597@arundodonax.nekodune.net> <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> <8135e3e6-62e4-52f7-e320-cdba86ff4b4e@seacom.mu> <8D69F871-F8AC-4E42-BF43-D68FD4240B0D@isc.org> <77868665-af7a-27db-4171-31b629ee0cd9@nsc.liu.se> <87va0x8fs4.fsf@miraculix.mork.no> Message-ID: On Tue, Mar 5, 2019 at 10:09 AM Bjørn Mork wrote: > Stephen Satchell writes: > > Did you submit a bug report? > > I believe this was fixed 5 years ago (in Linux v3.17): > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cb1ce2ef387b01686469487edd45994872d52d73 > > But RHEL and CentOS are using kernels from the stone age, so they > haven't noticed yet. For those who might need this feature, and have a Red Hat contract, a suggestion: If you submit a ticket, someone at Red Hat might backport the patch for you. From dmitry at interhost.net Tue Mar 5 18:17:30 2019 From: dmitry at interhost.net (Dmitry Sherman) Date: Tue, 5 Mar 2019 18:17:30 +0000 Subject: Arista Layer3 In-Reply-To: <0c4a81cd-ad54-b5c8-abb0-adaf10949090@bogus.com> References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> <20171130191750.GB32439@sizone.org> <20171130210022.GF32439@sizone.org> <0c4a81cd-ad54-b5c8-abb0-adaf10949090@bogus.com> Message-ID: Hello, What do you think about Arista 7280SR (DCS-7280SR-48C6-M-R) as a BGP peering router with 3 x upstream with full route view in RIB (ipv4 + ipv6) and another IXP feed? Considering switching from ASR9001 which is doing perfect work but has no more ports left. The price is very competitive comparing to MX or ASR and this router-switch have 48x10Gig + 6x100GigE ports. Will it run smoothly with BGP, PIM, IPV6? Thanks. -- Dmitry Sherman Interhost Networks Ltd Dmitry at interhost.net Mobile: +972-54-3181182 Office: +972-74-7029881 Web: www.interhost.co.il On 01/12/2017, 1:17, "NANOG on behalf of joel jaeggli" wrote: On 11/30/17 13:00, Ken Chase wrote: > >Arista DCS-7280SRA-48C6 is a 1ru box.?? > > > >Has a nominally million route fib, Jericho+ 8GB of packet buffer. > >control-plane is 8GB of ram andAMD GX-424CC SOC which is 4 core 2.4ghz. > >We do direct fib injection with bird rather than the arista bgpd but the > >control-plane is capable of managing quite a few bgp sessions. > > > >the 1/2ru 7280CR2K-30 and 60 are 2m route fib boxes with still heftier > >control planes but they're a different class of box being all 100G and > >requiring multi-chip/internal fabrics. > > Sounds pretty good - hows your power draw on that thing? Why'd you pick Bird > in this case? this a standard sr that's moderately busy but not exactly slammed, I'm be impressed if you could triple that at full tilt. #show environment power Power Input Output Output Supply Model Capacity Current Current Power Status ------- -------------------- --------- -------- -------- -------- ------------- 1 PWR-500AC-R 500W 0.35A 5.27A 62.8W Ok 2 PWR-500AC-R 500W 0.32A 4.81A 56.4W Ok Total -- 1000W -- -- 119.1W -- bird had memory footprint going with it as well as some local modification and we hacked addpath into it a few years ago. filtering poilcy is something we programmatically generate and interact with via agents so a traditional style monolithic config isn't that useful. > /kc > > > >> /kc > >> > >> On Thu, Nov 30, 2017 at 10:45:09AM -0800, Tyler Conrad said: > >> >For Enterprise/DC, it works great. For service provider, they're not 100% > >> >yet. The main issue is going to be around VRFs, as there's no interaction > >> >between them (at least in the code version I'm on, that may have changed > >> >recently or be changing soon). They'll work great as a P-Router, but if you > >> >need a PE with route leaking I'd look at another vendor. > >> > > >> >I use a couple pairs of 7280SRs as edge routers/border leaves. Multiple > >> >full table feeds without any issue. > >> > > >> >On Thu, Nov 30, 2017 at 10:36 AM, Romeo Czumbil >> >> wrote: > >> > > >> >> So I've been using Arista as layer2 for quite some time, and I'm pretty > >> >> happy with them. > >> >> Kicking the idea around to turn on some Layer3 features but I've been > >> >> hearing some negative feedback. > >> >> The people that I did hear negative feedback don't use Arista themselves. > >> >> (they just heard....) > >> >> > >> >> So do we have any Arista L3 people out here that can share some negatives > >> >> or positives? > >> >> > >> >> Use case: Just some MPLS IPv4/IPv6 routing, l2vpn OSPF/BGP > >> >> Maybe 20k routes (no full internet routes) > >> >> 7050 Series > >> >> 7280 Series > >> >> > >> >> -Romeo > >> >> > >> > > > > > > > > This mail was received via Interhost Mail-SeCure System. From nanog at jack.fr.eu.org Tue Mar 5 18:25:41 2019 From: nanog at jack.fr.eu.org (nanog at jack.fr.eu.org) Date: Tue, 5 Mar 2019 19:25:41 +0100 Subject: Arista Layer3 In-Reply-To: References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> <20171130191750.GB32439@sizone.org> <20171130210022.GF32439@sizone.org> <0c4a81cd-ad54-b5c8-abb0-adaf10949090@bogus.com> Message-ID: <5C7EBF25.2030705@jack.fr.eu.org> Those devices are awesome, I use those on the same usecase, and recommend them (I do not run pim, tho) On 03/05/2019 07:17 PM, Dmitry Sherman wrote: > Hello, > What do you think about Arista 7280SR (DCS-7280SR-48C6-M-R) as a BGP peering router with 3 x upstream with full route view in RIB (ipv4 + ipv6) and another IXP feed? > Considering switching from ASR9001 which is doing perfect work but has no more ports left. > The price is very competitive comparing to MX or ASR and this router-switch have 48x10Gig + 6x100GigE ports. > Will it run smoothly with BGP, PIM, IPV6? > Thanks. > From saku at ytti.fi Tue Mar 5 19:26:11 2019 From: saku at ytti.fi (Saku Ytti) Date: Tue, 5 Mar 2019 21:26:11 +0200 Subject: Arista Layer3 In-Reply-To: References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> <20171130191750.GB32439@sizone.org> <20171130210022.GF32439@sizone.org> <0c4a81cd-ad54-b5c8-abb0-adaf10949090@bogus.com> Message-ID: Hey Dmitry, > What do you think about Arista 7280SR (DCS-7280SR-48C6-M-R) as a BGP peering router with 3 x upstream with full route view in RIB (ipv4 + ipv6) and another IXP feed? > Considering switching from ASR9001 which is doing perfect work but has no more ports left. > The price is very competitive comparing to MX or ASR and this router-switch have 48x10Gig + 6x100GigE ports. You should compare 7280SR against NCS5500 and PTX1k, not ASR and MX. ANET is great company, with great people, but they are like 2 years old in SP market and this is quite visible. It is impressive though what they've done in so little time. -- ++ytti From dhubbard at dino.hostasaurus.com Tue Mar 5 19:55:48 2019 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Tue, 5 Mar 2019 19:55:48 +0000 Subject: Arista Layer3 In-Reply-To: References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> <20171130191750.GB32439@sizone.org> <20171130210022.GF32439@sizone.org> <0c4a81cd-ad54-b5c8-abb0-adaf10949090@bogus.com> Message-ID: <27F7E3C6-62D4-4E58-AE68-649A7C775104@dino.hostasaurus.com> On 3/5/19, 2:28 PM, "NANOG on behalf of Saku Ytti" wrote: Hey Dmitry, > What do you think about Arista 7280SR (DCS-7280SR-48C6-M-R) as a BGP peering router with 3 x upstream with full route view in RIB (ipv4 + ipv6) and another IXP feed? > Considering switching from ASR9001 which is doing perfect work but has no more ports left. > The price is very competitive comparing to MX or ASR and this router-switch have 48x10Gig + 6x100GigE ports. You should compare 7280SR against NCS5500 and PTX1k, not ASR and MX. ANET is great company, with great people, but they are like 2 years old in SP market and this is quite visible. It is impressive though what they've done in so little time. -- ++ytti I love the NCS5501, but once Arista gets the 2M-route capacity down into the 48x10g format, I'd jump ship in a heartbeat; currently you have to do a much larger chassis-based device or their 100gig 7280 to have that route scale. My big gripes with the 5501 are that, due to its architecture, if you want to do uRPF, you chop your route scale in half, even on the 5501-SE. 5501 also has no supported configuration where you have both first hop redundancy and physical path redundancy, because you can't do both VRRP (its only redundant first hop option) and BVI's, can't do MC-LAG, can't do vPC, so you need switches in addition to the 5501's if that's the goal.. David From nanog at jack.fr.eu.org Tue Mar 5 20:30:11 2019 From: nanog at jack.fr.eu.org (nanog at jack.fr.eu.org) Date: Tue, 5 Mar 2019 21:30:11 +0100 Subject: Arista Layer3 In-Reply-To: <27F7E3C6-62D4-4E58-AE68-649A7C775104@dino.hostasaurus.com> References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> <20171130191750.GB32439@sizone.org> <20171130210022.GF32439@sizone.org> <0c4a81cd-ad54-b5c8-abb0-adaf10949090@bogus.com> <27F7E3C6-62D4-4E58-AE68-649A7C775104@dino.hostasaurus.com> Message-ID: <5C7EDC53.2030608@jack.fr.eu.org> Check out the 7280sr2k, which is actually 24*10G, 24*25G, 6*100G On 03/05/2019 08:55 PM, David Hubbard wrote: > I love the NCS5501, but once Arista gets the 2M-route capacity down into the 48x10g format, I'd jump ship in a heartbeat; currently you have to do a much larger chassis-based device or their 100gig 7280 to have that route scale. My big gripes with the 5501 are that, due to its architecture, if you want to do uRPF, you chop your route scale in half, even on the 5501-SE. 5501 also has no supported configuration where you have both first hop redundancy and physical path redundancy, because you can't do both VRRP (its only redundant first hop option) and BVI's, can't do MC-LAG, can't do vPC, so you need switches in addition to the 5501's if that's the goal.. > > David > From dmitry at interhost.net Tue Mar 5 20:34:30 2019 From: dmitry at interhost.net (Dmitry Sherman) Date: Tue, 5 Mar 2019 20:34:30 +0000 Subject: Arista Layer3 In-Reply-To: References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> <20171130191750.GB32439@sizone.org> <20171130210022.GF32439@sizone.org> <0c4a81cd-ad54-b5c8-abb0-adaf10949090@bogus.com> Message-ID: <6096156F-3A6B-4916-A102-45DAF9967B99@interhost.net> Thanks for info! -- Dmitry Sherman Interhost Networks Ltd Dmitry at interhost.net Mobile: +972-54-3181182 Office: +972-74-7029881 Web: www.interhost.co.il On 05/03/2019, 21:26, "Saku Ytti" wrote: Hey Dmitry, > What do you think about Arista 7280SR (DCS-7280SR-48C6-M-R) as a BGP peering router with 3 x upstream with full route view in RIB (ipv4 + ipv6) and another IXP feed? > Considering switching from ASR9001 which is doing perfect work but has no more ports left. > The price is very competitive comparing to MX or ASR and this router-switch have 48x10Gig + 6x100GigE ports. You should compare 7280SR against NCS5500 and PTX1k, not ASR and MX. ANET is great company, with great people, but they are like 2 years old in SP market and this is quite visible. It is impressive though what they've done in so little time. -- ++ytti From tyler at exospec.us Tue Mar 5 20:29:10 2019 From: tyler at exospec.us (Tyler Harden) Date: Tue, 5 Mar 2019 20:29:10 +0000 Subject: Internap Corporation - DDOS Message-ID: <651A4441-1872-4D58-859F-21992863ACB0@exospec.us> Is anyone else being DDOS’d or flooded with traffic from Internap Corporation registered IP space? We’re on day 2 of consistent outages and the traffic I’m receiving is entirely from IPs in the /15 range 64.94.0.0-64.95.255.255 Cheers, Tyler Harden President exospec -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Tue Mar 5 20:45:28 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 5 Mar 2019 15:45:28 -0500 Subject: How to choose a transit provider? In-Reply-To: References: <4055a90d-6183-6498-f4aa-e9be7f4d6e40@seacom.mu> Message-ID: thanks everyone watching the video, working on some more new ones. I am also working on a ranking system for transit providers. The way ranking will work is going to be limited to a Metro Do you guys have any recommendations what technical aspects to look for when ranking ISPs? it's quiet hard to rank them fairly without having their routing table views, i think, please let me know your thoughts on this and any recommendation is welcome. On Thu, Feb 14, 2019 at 3:05 PM Mehmet Akcin wrote: > thanks for all feedback, I have tried to summarize my thoughts in a video, > hoping this is useful set of notes https://youtu.be/4gihKxb6uys > > On Sat, Dec 15, 2018 at 9:46 AM Mark Tinka wrote: > >> >> >> On 15/Dec/18 19:37, nanog-isp at mail.com wrote: >> >> > >> > I certainly subscribe to the notion that transport + transit is >> usually less expensive than DIA, but this does depend on the market and >> location. >> >> ... and the type of customer. >> >> DIA for a high-value "Enterprise" customer (think of a large >> conglomerate) is typically more costly than DIA for a low-value >> "Enterprise" customer (think of a family-owned travel & tour company). >> The large global ISP's are making more money from "enterprise" business >> than typical wholesale/transit services. This can support the idea that >> DIA can be pricier than transit. >> >> Mark. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hf0002+nanog at uah.edu Tue Mar 5 22:12:31 2019 From: hf0002+nanog at uah.edu (Hunter Fuller) Date: Tue, 5 Mar 2019 16:12:31 -0600 Subject: a quick survey about LLDP and similar In-Reply-To: <20190301142545.lxxroyqcenii7z6a@angus.ind.wpi.edu> References: <87d0ncl22g.fsf@snoopy.tippete.net> <20190301142545.lxxroyqcenii7z6a@angus.ind.wpi.edu> Message-ID: On Fri, Mar 1, 2019 at 8:26 AM Anderson, Charles R wrote: > > We require LLDP/LLDP-MED to configure our VOIP phones. > > For trunk links, it is extremely helpful to verify correct topology. > > For datacenters, it is EXTREMELY helpful to verify hypervisor connectivity. I'd say it's extremely helpful anywhere. We enable it on every single port unless there is a specific reason to disable it. Our particularly clueful customers can now submit requests like: "For the system attached to port 1/2/3, please switch to VLAN 456." This ticket gets closed in about 10 seconds. We also run LLDP speakers on our University-controlled workstations so we can see details about the system in "slow lldp neighbor" on the switch. The more LLDP the better, from my perspective. From roel.parijs at gmail.com Tue Mar 5 22:46:50 2019 From: roel.parijs at gmail.com (Roel Parijs) Date: Tue, 5 Mar 2019 23:46:50 +0100 Subject: Arista Layer3 In-Reply-To: <5C7EDC53.2030608@jack.fr.eu.org> References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> <20171130191750.GB32439@sizone.org> <20171130210022.GF32439@sizone.org> <0c4a81cd-ad54-b5c8-abb0-adaf10949090@bogus.com> <27F7E3C6-62D4-4E58-AE68-649A7C775104@dino.hostasaurus.com> <5C7EDC53.2030608@jack.fr.eu.org> Message-ID: We have been using the 7280SR-48C6 for 2.5 years now. Just after Arista announced the full table BGP routing. Looking at the price / port there is nothing near Arista. We also use Cisco ASR1K and Juniper MX204 but these have far less capacity. When we first started, there were quite a few features missing but over the past 2 year they have really been catching up. I was very happy when they added MSS clamping at the end of last year. The new version 7280R2K should be able to handle 2M routes. On Tue, Mar 5, 2019 at 9:31 PM wrote: > Check out the 7280sr2k, which is actually 24*10G, 24*25G, 6*100G > > On 03/05/2019 08:55 PM, David Hubbard wrote: > > I love the NCS5501, but once Arista gets the 2M-route capacity down into > the 48x10g format, I'd jump ship in a heartbeat; currently you have to do a > much larger chassis-based device or their 100gig 7280 to have that route > scale. My big gripes with the 5501 are that, due to its architecture, if > you want to do uRPF, you chop your route scale in half, even on the > 5501-SE. 5501 also has no supported configuration where you have both > first hop redundancy and physical path redundancy, because you can't do > both VRRP (its only redundant first hop option) and BVI's, can't do MC-LAG, > can't do vPC, so you need switches in addition to the 5501's if that's the > goal.. > > > > David > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerry at jtcloe.net Tue Mar 5 22:55:36 2019 From: jerry at jtcloe.net (=?utf-8?Q?Jerry_Cloe?=) Date: Tue, 5 Mar 2019 16:55:36 -0600 Subject: Internap Corporation - DDOS In-Reply-To: <651A4441-1872-4D58-859F-21992863ACB0@exospec.us> References: <651A4441-1872-4D58-859F-21992863ACB0@exospec.us> Message-ID: Don't forget, just because its the source IP in the packet doesn't mean thats where it originated from (its probably not). But, since it contains a consistent source IP, it should be fairly simple to filter it upstream.   -----Original message----- From:Tyler Harden Sent:Tue 03-05-2019 02:44 pm Subject:Internap Corporation - DDOS To:nanog at nanog.org; Is anyone else being DDOS’d or flooded with traffic from Internap Corporation registered IP space?   We’re on day 2 of consistent outages and the traffic I’m receiving is entirely from IPs in the /15 range 64.94.0.0-64.95.255.255   Cheers, Tyler Harden President exospec -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at instituut.net Tue Mar 5 23:01:18 2019 From: job at instituut.net (Job Snijders) Date: Tue, 5 Mar 2019 23:01:18 +0000 Subject: Best practices for BGP Communities In-Reply-To: References: Message-ID: <20190305230118.GO71660@vurt.meerval.net> On Sun, Mar 03, 2019 at 08:42:02PM -0500, Joshua Miller wrote: > A while back I read somewhere that transit providers shouldn't delete > communities unless the communities have a specific impact to their > network, but my google-fu is failing me and I can't find any sources. > > Is this still the case? Does anyone have a source for the practice of > leaving unknown communities alone or deleting them? https://tools.ietf.org/html/rfc7454#section-11 Kind regards, Job From erich at gotfusion.net Tue Mar 5 23:22:56 2019 From: erich at gotfusion.net (Kaiser, Erich) Date: Tue, 5 Mar 2019 17:22:56 -0600 Subject: Arista Layer3 In-Reply-To: References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> <20171130191750.GB32439@sizone.org> <20171130210022.GF32439@sizone.org> <0c4a81cd-ad54-b5c8-abb0-adaf10949090@bogus.com> <27F7E3C6-62D4-4E58-AE68-649A7C775104@dino.hostasaurus.com> <5C7EDC53.2030608@jack.fr.eu.org> Message-ID: It would be worth your time to look at Extreme SLX9640 with advanced routing license. On Tue, Mar 5, 2019 at 4:47 PM Roel Parijs wrote: > We have been using the 7280SR-48C6 for 2.5 years now. Just after Arista > announced the full table BGP routing. > Looking at the price / port there is nothing near Arista. We also use > Cisco ASR1K and Juniper MX204 but these have far less capacity. > > When we first started, there were quite a few features missing but over > the past 2 year they have really been catching up. I was very happy when > they added MSS clamping at the end of last year. > > The new version 7280R2K should be able to handle 2M routes. > > On Tue, Mar 5, 2019 at 9:31 PM wrote: > >> Check out the 7280sr2k, which is actually 24*10G, 24*25G, 6*100G >> >> On 03/05/2019 08:55 PM, David Hubbard wrote: >> > I love the NCS5501, but once Arista gets the 2M-route capacity down >> into the 48x10g format, I'd jump ship in a heartbeat; currently you have to >> do a much larger chassis-based device or their 100gig 7280 to have that >> route scale. My big gripes with the 5501 are that, due to its >> architecture, if you want to do uRPF, you chop your route scale in half, >> even on the 5501-SE. 5501 also has no supported configuration where you >> have both first hop redundancy and physical path redundancy, because you >> can't do both VRRP (its only redundant first hop option) and BVI's, can't >> do MC-LAG, can't do vPC, so you need switches in addition to the 5501's if >> that's the goal.. >> > >> > David >> > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Courtney_Smith at comcast.com Tue Mar 5 23:32:07 2019 From: Courtney_Smith at comcast.com (Smith, Courtney) Date: Tue, 5 Mar 2019 23:32:07 +0000 Subject: Best practices for BGP Communities In-Reply-To: <20190305230118.GO71660@vurt.meerval.net> References: <20190305230118.GO71660@vurt.meerval.net> Message-ID: On 3/5/19, 6:04 PM, "NANOG on behalf of Job Snijders" wrote: On Sun, Mar 03, 2019 at 08:42:02PM -0500, Joshua Miller wrote: > A while back I read somewhere that transit providers shouldn't delete > communities unless the communities have a specific impact to their > network, but my google-fu is failing me and I can't find any sources. > > Is this still the case? Does anyone have a source for the practice of > leaving unknown communities alone or deleting them? https://tools.ietf.org/html/rfc7454#section-11 Kind regards, Job Remember policies between two peers may not be same as customer policies. Example: Customers_of_transit_X >>> Transit X >>> Peer_A >> Customers_of_Peer_A Customers_of_Peer_A may use community A:50 to set local pref to 50 in Peer_A network. But that doesn’t not mean Customers_of_transit_X can send A:50 to set lpref on their routes in Peer_A's network. Peer_A's policy with Transit X likely does not take action on customer communities since they are 'peers' not customers. Transit X can send A:50 to Peer_A but nothing would happen. What's the benefit of Transit X preserving A:50 from its customers if it means nothing in Transit X? From job at instituut.net Wed Mar 6 01:16:02 2019 From: job at instituut.net (Job Snijders) Date: Wed, 6 Mar 2019 10:16:02 +0900 Subject: Best practices for BGP Communities In-Reply-To: References: <20190305230118.GO71660@vurt.meerval.net> Message-ID: On Wed, Mar 6, 2019 at 8:32 Smith, Courtney wrote: > On 3/5/19, 6:04 PM, "NANOG on behalf of Job Snijders" > job at instituut.net> wrote: > > On Sun, Mar 03, 2019 at 08:42:02PM -0500, Joshua Miller wrote: > > A while back I read somewhere that transit providers shouldn't delete > > communities unless the communities have a specific impact to their > > network, but my google-fu is failing me and I can't find any sources. > > > > Is this still the case? Does anyone have a source for the practice of > > leaving unknown communities alone or deleting them? > > https://tools.ietf.org/html/rfc7454#section-11 > > > Remember policies between two peers may not be same as customer policies. > > Example: Customers_of_transit_X >>> Transit X >>> Peer_A >> > Customers_of_Peer_A > > Customers_of_Peer_A may use community A:50 to set local pref to 50 in > Peer_A network. But that doesn’t not mean Customers_of_transit_X can send > A:50 to set lpref on their routes in Peer_A's network. Peer_A's policy > with Transit X likely does not take action on customer communities since > they are 'peers' not customers. Transit X can send A:50 to Peer_A but > nothing would happen. What's the benefit of Transit X preserving A:50 from > its customers if it means nothing in Transit X? OP didn’t specify what kind of BGP communities they were referring to. In general we can separate communities into two categories: “Informational” and “Action”. You are right that preserving/propagating “action” communities (such as in your example) probably isn’t that interesting. “informational” communities on the other hand can be very valuable. See https://tools.ietf.org/html/rfc8195 for more information on how the two types differ. Kind regards, Job -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgont at si6networks.com Wed Mar 6 01:43:27 2019 From: fgont at si6networks.com (Fernando Gont) Date: Tue, 5 Mar 2019 22:43:27 -0300 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: <20190227100105.GF19597@arundodonax.nekodune.net> References: <20190227100105.GF19597@arundodonax.nekodune.net> Message-ID: <850cb065-b42d-6593-2e80-058c9e91b448@si6networks.com> On 27/2/19 07:01, Jean-Daniel Pauget wrote: > hello, > > I confess using IPv6 behind a 6in4 tunnel because the "Business-Class" service > of the concerned operator doesn't handle IPv6 yet. > > as such, I realised that, as far as I can figure, ICMPv6 packet "too-big" (rfc 4443) > seem to be ignored or filtered at ~60% of ClouFlare's http farms > > as a result, random sites such as http://nanog.org/ or https://www.ansible.com/ > are badly reachable whenever small mtu are involved ... > > support at cloudflare answered me that because I'm not the owner of concerned site, > and because of security reasons, they wouldn't investigate further. > > are there security concerns with ICMP-too-big ? Please see: https://tools.ietf.org/html/rfc5927 and also: https://tools.ietf.org/html/rfc8021 Thanks, -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont at si6networks.com Wed Mar 6 02:27:44 2019 From: fgont at si6networks.com (Fernando Gont) Date: Tue, 5 Mar 2019 23:27:44 -0300 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: <753803c3-cfab-28b6-19a9-e80233275b94@massar.ch> References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> <753803c3-cfab-28b6-19a9-e80233275b94@massar.ch> Message-ID: <9a6ba57a-e7ac-f119-3e3d-e1c11ed52cf7@si6networks.com> On 3/3/19 16:57, Jeroen Massar wrote: > On 2019-03-03 20:13, Mark Tinka wrote: >> >> >> On 3/Mar/19 18:05, Jeroen Massar wrote: >> >>> IPv6 requires a minimum MTU of 1280. >>> >>> If you cannot transport it, then the transport (the tunnel in this case) needs to handle the fragmentation of packets of 1280 down to whatever does fit in the tunnel. >> >> As you know, IPv6 does not support fragmentation in transit. So that's >> not an option. > > The transport (tunnel) CAN support that kind of fragmentation. Still, that's certainly not panacea. See: https://tools.ietf.org/html/rfc7872 -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont at si6networks.com Wed Mar 6 02:30:02 2019 From: fgont at si6networks.com (Fernando Gont) Date: Tue, 5 Mar 2019 23:30:02 -0300 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> Message-ID: On 3/3/19 18:04, Mark Andrews wrote: > There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB getting > back to the TCP servers. There are also IDIOTS that deploy load balancers that > DO NOT LOOK INSIDE ICMP messages for redirecting ICMP messages to the correct > back end. There are also IDOITS that rate limit PTB generation to ridiculously > low rates. One should be able to generate PTB at line rate. > > Everyone that has configured mss-fix-up has contributed to misunderstanding that > you can block ICMP. It is time we had a flag day to REMOVE mss-fix-up from all > the boxes you control. We need to get PTB working and unfortunately that means > that we need to stop pandering to admins who don’t know how IP is supposed to > work. ICMP is NOT optional. It would seem IETF's intention is to actually move away from ICMPv6-based PMTUD, to the extent that is possible. (RFC4821). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont at si6networks.com Wed Mar 6 02:32:20 2019 From: fgont at si6networks.com (Fernando Gont) Date: Tue, 5 Mar 2019 23:32:20 -0300 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: <46A8769B-AFFD-4BFB-9AD0-88694DE31AA2@isc.org> References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> <46A8769B-AFFD-4BFB-9AD0-88694DE31AA2@isc.org> Message-ID: <9c3ad44a-6482-913a-8d2a-9d31915d103a@si6networks.com> On 3/3/19 20:16, Mark Andrews wrote: > > >> On 4 Mar 2019, at 9:33 am, Stephen Satchell wrote: >> >> On 3/3/19 1:04 PM, Mark Andrews wrote: >>> There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB getting >>> back to the TCP servers. >> >> For those of us who are in the dark, "PTB" appears to refer to "Packet >> Too Big" responses in ICMPv6. >> >> Yes, some admins don't have fine-enough grain tools to block or throttle >> specific types of ICMP, but that's the fault of the vendors, not the admins. > > No, it is the fault of the admins. They should be making it part of the purchasing > decision if they want to filter ICMP. It’s not like selective filtering is a new idea. > It is well over 20 years old at this stage. The amount of +20 year old equipment on the > net is minimal. > > That said modern OS’s don’t need other equipment to “protect" them from ICMP of any form. > These news don't help in that direction: https://www.theregister.co.uk/2016/06/02/cisco_warns_of_ipv6_dos_vulnerability/ (I'm not complaining about the news, but about the bugs, if you wish) -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From hannigan at gmail.com Wed Mar 6 02:40:21 2019 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 5 Mar 2019 21:40:21 -0500 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: <20190305121401.GA12619@gsp.org> References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> <20190305121401.GA12619@gsp.org> Message-ID: On Tue, Mar 5, 2019 at 07:15 Rich Kulawiec wrote: > On Mon, Mar 04, 2019 at 08:04:12AM +1100, Mark Andrews wrote: > > ICMP is NOT optional. > > I've pointed folks at this for years: > > ICMP Packet Filtering v1.2 > http://www.cymru.com/Documents/icmp-messages.html > > ---rsk > Some of the networks that completely block ICMP are shocking. Best, -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: From tj at pcguys.us Wed Mar 6 02:44:51 2019 From: tj at pcguys.us (TJ Trout) Date: Tue, 5 Mar 2019 18:44:51 -0800 Subject: Comcast contact for wholesale ethernet/local loop Message-ID: Does anyone know the name, or have contact information for the department within Comcast that handles carriers looking to purchase local access, etc? Normally this would be the carrier or wholesale group, but either of their websites seem to be aligned to the services we are looking for? Thank you, TJ Trout EXPOHL LLC AS62809 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgont at si6networks.com Wed Mar 6 02:36:47 2019 From: fgont at si6networks.com (Fernando Gont) Date: Tue, 5 Mar 2019 23:36:47 -0300 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: <8D69F871-F8AC-4E42-BF43-D68FD4240B0D@isc.org> References: <20190227100105.GF19597@arundodonax.nekodune.net> <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> <8135e3e6-62e4-52f7-e320-cdba86ff4b4e@seacom.mu> <8D69F871-F8AC-4E42-BF43-D68FD4240B0D@isc.org> Message-ID: On 5/3/19 03:26, Mark Andrews wrote: > > >> On 5 Mar 2019, at 5:18 pm, Mark Tinka wrote: >> >> >> >> On 5/Mar/19 00:25, Mark Andrews wrote: >> >>> >>> Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if >>> they have installed broken ECMP devices. The simplest way to do that >>> is to set the interface MTUs to 1280 on all the servers. Why should >>> the rest of the world have to put up with their inability to purchase >>> devices that work with RFC compliant data streams. >> >> I've had this issue with cdnjs.cloudflare.com for the longest time at my >> house. But as some of you may recall, my little unwanted TCP MSS hack >> for IPv6 last weekend fixed that issue for me. >> >> Not ideal, and I so wish IPv6 would work as designed, but… > > It does work as designed except when crap middleware is added. ECMP > should be using the flow label with IPv6. It has the advantage that > it works for non-0-offset fragments as well as 0-offset fragments and > also works for transports other than TCP and UDP. This isn’t a protocol > failure. It is shitty implementations. Not to play devil's advocate but the IETF fot to publish a spec for ECMP use of Flow Labels only a few years ago. For quite a while, they were unasable... and might still be, for some implementations. -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From marka at isc.org Wed Mar 6 04:09:29 2019 From: marka at isc.org (Mark Andrews) Date: Wed, 6 Mar 2019 15:09:29 +1100 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> Message-ID: <2EFF6363-393D-46D9-A282-F4A4CE7FFEB5@isc.org> > On 6 Mar 2019, at 1:30 pm, Fernando Gont wrote: > > On 3/3/19 18:04, Mark Andrews wrote: >> There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB getting >> back to the TCP servers. There are also IDIOTS that deploy load balancers that >> DO NOT LOOK INSIDE ICMP messages for redirecting ICMP messages to the correct >> back end. There are also IDOITS that rate limit PTB generation to ridiculously >> low rates. One should be able to generate PTB at line rate. >> >> Everyone that has configured mss-fix-up has contributed to misunderstanding that >> you can block ICMP. It is time we had a flag day to REMOVE mss-fix-up from all >> the boxes you control. We need to get PTB working and unfortunately that means >> that we need to stop pandering to admins who don’t know how IP is supposed to >> work. ICMP is NOT optional. > > It would seem IETF's intention is to actually move away from > ICMPv6-based PMTUD, to the extent that is possible. (RFC4821). Which is not a reason to not fix broken equipment and misconfigured firewalls. The workarounds are basically there because people deploy broken equipment. Additionally everything isn’t TCP. > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont at si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Wed Mar 6 04:21:22 2019 From: marka at isc.org (Mark Andrews) Date: Wed, 6 Mar 2019 15:21:22 +1100 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: References: <20190227100105.GF19597@arundodonax.nekodune.net> <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> <8135e3e6-62e4-52f7-e320-cdba86ff4b4e@seacom.mu> <8D69F871-F8AC-4E42-BF43-D68FD4240B0D@isc.org> Message-ID: > On 6 Mar 2019, at 1:36 pm, Fernando Gont wrote: > > On 5/3/19 03:26, Mark Andrews wrote: >> >> >>> On 5 Mar 2019, at 5:18 pm, Mark Tinka wrote: >>> >>> >>> >>> On 5/Mar/19 00:25, Mark Andrews wrote: >>> >>>> >>>> Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if >>>> they have installed broken ECMP devices. The simplest way to do that >>>> is to set the interface MTUs to 1280 on all the servers. Why should >>>> the rest of the world have to put up with their inability to purchase >>>> devices that work with RFC compliant data streams. >>> >>> I've had this issue with cdnjs.cloudflare.com for the longest time at my >>> house. But as some of you may recall, my little unwanted TCP MSS hack >>> for IPv6 last weekend fixed that issue for me. >>> >>> Not ideal, and I so wish IPv6 would work as designed, but… >> >> It does work as designed except when crap middleware is added. ECMP >> should be using the flow label with IPv6. It has the advantage that >> it works for non-0-offset fragments as well as 0-offset fragments and >> also works for transports other than TCP and UDP. This isn’t a protocol >> failure. It is shitty implementations. > > Not to play devil's advocate but the IETF fot to publish a spec for ECMP > use of Flow Labels only a few years ago. > > For quite a while, they were unasable... and might still be, for some > implementations. And if it is still using the quintuple the PTB has all the necessary information for unfragmented and 0 offset fragment packets (which there shouldn’t be with a working TCP stack) to be passed through. > -- > Fernando Gont > SI6 Networks > e-mail: fgont at si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From tj at pcguys.us Wed Mar 6 05:32:40 2019 From: tj at pcguys.us (TJ Trout) Date: Tue, 5 Mar 2019 21:32:40 -0800 Subject: Comcast contact for wholesale ethernet/local loop In-Reply-To: References: Message-ID: Access to Comcast ethernet services on a wholesale level, interconnection for NNI to use comcast as local access, etc On Tue, Mar 5, 2019 at 9:01 PM Keith Christian wrote: > TJ, > > What are you seeking, exactly? > > Keith > > On Tue, Mar 5, 2019 at 7:46 PM TJ Trout wrote: > >> Does anyone know the name, or have contact information for the department >> within Comcast that handles carriers looking to purchase local access, etc? >> >> Normally this would be the carrier or wholesale group, but either of >> their websites seem to be aligned to the services we are looking for? >> >> Thank you, >> >> TJ Trout >> EXPOHL LLC >> AS62809 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From colton.conor at gmail.com Wed Mar 6 05:36:13 2019 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 5 Mar 2019 23:36:13 -0600 Subject: Arista Layer3 In-Reply-To: References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> <20171130191750.GB32439@sizone.org> <20171130210022.GF32439@sizone.org> <0c4a81cd-ad54-b5c8-abb0-adaf10949090@bogus.com> <27F7E3C6-62D4-4E58-AE68-649A7C775104@dino.hostasaurus.com> <5C7EDC53.2030608@jack.fr.eu.org> Message-ID: How much do these boxes cost? On Tue, Mar 5, 2019 at 5:24 PM Kaiser, Erich wrote: > It would be worth your time to look at Extreme SLX9640 with advanced > routing license. > > > > On Tue, Mar 5, 2019 at 4:47 PM Roel Parijs wrote: > >> We have been using the 7280SR-48C6 for 2.5 years now. Just after Arista >> announced the full table BGP routing. >> Looking at the price / port there is nothing near Arista. We also use >> Cisco ASR1K and Juniper MX204 but these have far less capacity. >> >> When we first started, there were quite a few features missing but over >> the past 2 year they have really been catching up. I was very happy when >> they added MSS clamping at the end of last year. >> >> The new version 7280R2K should be able to handle 2M routes. >> >> On Tue, Mar 5, 2019 at 9:31 PM wrote: >> >>> Check out the 7280sr2k, which is actually 24*10G, 24*25G, 6*100G >>> >>> On 03/05/2019 08:55 PM, David Hubbard wrote: >>> > I love the NCS5501, but once Arista gets the 2M-route capacity down >>> into the 48x10g format, I'd jump ship in a heartbeat; currently you have to >>> do a much larger chassis-based device or their 100gig 7280 to have that >>> route scale. My big gripes with the 5501 are that, due to its >>> architecture, if you want to do uRPF, you chop your route scale in half, >>> even on the 5501-SE. 5501 also has no supported configuration where you >>> have both first hop redundancy and physical path redundancy, because you >>> can't do both VRRP (its only redundant first hop option) and BVI's, can't >>> do MC-LAG, can't do vPC, so you need switches in addition to the 5501's if >>> that's the goal.. >>> > >>> > David >>> > >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgont at si6networks.com Wed Mar 6 04:37:29 2019 From: fgont at si6networks.com (Fernando Gont) Date: Wed, 6 Mar 2019 01:37:29 -0300 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: <2EFF6363-393D-46D9-A282-F4A4CE7FFEB5@isc.org> References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> <2EFF6363-393D-46D9-A282-F4A4CE7FFEB5@isc.org> Message-ID: <7bf1ee49-119e-77f4-6330-c4e8c92af843@si6networks.com> On 6/3/19 01:09, Mark Andrews wrote: > > >> On 6 Mar 2019, at 1:30 pm, Fernando Gont wrote: >> >> On 3/3/19 18:04, Mark Andrews wrote: >>> There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB getting >>> back to the TCP servers. There are also IDIOTS that deploy load balancers that >>> DO NOT LOOK INSIDE ICMP messages for redirecting ICMP messages to the correct >>> back end. There are also IDOITS that rate limit PTB generation to ridiculously >>> low rates. One should be able to generate PTB at line rate. >>> >>> Everyone that has configured mss-fix-up has contributed to misunderstanding that >>> you can block ICMP. It is time we had a flag day to REMOVE mss-fix-up from all >>> the boxes you control. We need to get PTB working and unfortunately that means >>> that we need to stop pandering to admins who don’t know how IP is supposed to >>> work. ICMP is NOT optional. >> >> It would seem IETF's intention is to actually move away from >> ICMPv6-based PMTUD, to the extent that is possible. (RFC4821). > > Which is not a reason to not fix broken equipment and misconfigured firewalls. > The workarounds are basically there because people deploy broken equipment. Agreed. That said, it wasn't solved in 30+ years of IPv4. Do you have hopes it will be different with IPv6? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From marka at isc.org Wed Mar 6 06:29:55 2019 From: marka at isc.org (Mark Andrews) Date: Wed, 6 Mar 2019 17:29:55 +1100 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: <7bf1ee49-119e-77f4-6330-c4e8c92af843@si6networks.com> References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> <2EFF6363-393D-46D9-A282-F4A4CE7FFEB5@isc.org> <7bf1ee49-119e-77f4-6330-c4e8c92af843@si6networks.com> Message-ID: > On 6 Mar 2019, at 3:37 pm, Fernando Gont wrote: > > On 6/3/19 01:09, Mark Andrews wrote: >> >> >>> On 6 Mar 2019, at 1:30 pm, Fernando Gont wrote: >>> >>> On 3/3/19 18:04, Mark Andrews wrote: >>>> There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB getting >>>> back to the TCP servers. There are also IDIOTS that deploy load balancers that >>>> DO NOT LOOK INSIDE ICMP messages for redirecting ICMP messages to the correct >>>> back end. There are also IDOITS that rate limit PTB generation to ridiculously >>>> low rates. One should be able to generate PTB at line rate. >>>> >>>> Everyone that has configured mss-fix-up has contributed to misunderstanding that >>>> you can block ICMP. It is time we had a flag day to REMOVE mss-fix-up from all >>>> the boxes you control. We need to get PTB working and unfortunately that means >>>> that we need to stop pandering to admins who don’t know how IP is supposed to >>>> work. ICMP is NOT optional. >>> >>> It would seem IETF's intention is to actually move away from >>> ICMPv6-based PMTUD, to the extent that is possible. (RFC4821). >> >> Which is not a reason to not fix broken equipment and misconfigured firewalls. >> The workarounds are basically there because people deploy broken equipment. > > Agreed. That said, it wasn't solved in 30+ years of IPv4. Do you have > hopes it will be different with IPv6? Make a big enough stink and it will get fixed. People just don’t make enough of a stink. Use social media. None of the companies with broken firewalls really want their idiotic practices pointed out in public. Start doing so every time you see it #STUPIDFIREWALL. > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont at si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From fgont at si6networks.com Wed Mar 6 06:38:56 2019 From: fgont at si6networks.com (Fernando Gont) Date: Wed, 6 Mar 2019 03:38:56 -0300 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> <2EFF6363-393D-46D9-A282-F4A4CE7FFEB5@isc.org> <7bf1ee49-119e-77f4-6330-c4e8c92af843@si6networks.com> Message-ID: <4a82c9a4-00a1-0cff-7b76-349367428757@si6networks.com> On 6/3/19 03:29, Mark Andrews wrote: > > >> On 6 Mar 2019, at 3:37 pm, Fernando Gont wrote: >> >> On 6/3/19 01:09, Mark Andrews wrote: >>> >>> >>>> On 6 Mar 2019, at 1:30 pm, Fernando Gont wrote: >>>> >>>> On 3/3/19 18:04, Mark Andrews wrote: >>>>> There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB getting >>>>> back to the TCP servers. There are also IDIOTS that deploy load balancers that >>>>> DO NOT LOOK INSIDE ICMP messages for redirecting ICMP messages to the correct >>>>> back end. There are also IDOITS that rate limit PTB generation to ridiculously >>>>> low rates. One should be able to generate PTB at line rate. >>>>> >>>>> Everyone that has configured mss-fix-up has contributed to misunderstanding that >>>>> you can block ICMP. It is time we had a flag day to REMOVE mss-fix-up from all >>>>> the boxes you control. We need to get PTB working and unfortunately that means >>>>> that we need to stop pandering to admins who don’t know how IP is supposed to >>>>> work. ICMP is NOT optional. >>>> >>>> It would seem IETF's intention is to actually move away from >>>> ICMPv6-based PMTUD, to the extent that is possible. (RFC4821). >>> >>> Which is not a reason to not fix broken equipment and misconfigured firewalls. >>> The workarounds are basically there because people deploy broken equipment. >> >> Agreed. That said, it wasn't solved in 30+ years of IPv4. Do you have >> hopes it will be different with IPv6? > > Make a big enough stink and it will get fixed. People just don’t make enough of > a stink. Use social media. None of the companies with broken firewalls really > want their idiotic practices pointed out in public. Start doing so every time > you see it #STUPIDFIREWALL. At times, it's fw defaults. Other times, it is admin policies. RFC4821 seems to signal that the IETF has given up in making ICMP-based PMTUD work, and aims at a (mostly) ICMP-free PMTUD. Essentially, when brokenness is widespread, you have to come-up with workarounds. And when workarounds are sufficiently widespread, there's less of an incentive to fix the original issue. Other times, there's a disconnect between with protocol standards, products, and operational requirements. That's the case of IPv6 EHs. This is their usability on the public Internet: RFC 7872. And these are some of the reasons why you get the numbers in RFC 7872: https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops Cheers, -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From tore at fud.no Wed Mar 6 07:17:42 2019 From: tore at fud.no (Tore Anderson) Date: Wed, 6 Mar 2019 08:17:42 +0100 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: <20190227100105.GF19597@arundodonax.nekodune.net> References: <20190227100105.GF19597@arundodonax.nekodune.net> Message-ID: <1f4410fe-2816-b358-ee52-5a3a23bef865@fud.no> * Jean-Daniel Pauget > I confess using IPv6 behind a 6in4 tunnel because the "Business-Class" service > of the concerned operator doesn't handle IPv6 yet. > > as such, I realised that, as far as I can figure, ICMPv6 packet "too-big" (rfc 4443) > seem to be ignored or filtered at ~60% of ClouFlare's http farms > > as a result, random sites such as http://nanog.org/ or https://www.ansible.com/ > are badly reachable whenever small mtu are involved ... Hi Jean-Daniel. If you're using using tunnels you'll want to have your tunnel endpoint adjust down the TCP MSS value to match the MTU of the tunnel interface. That way, you'll avoid problems with Path MTU Discovery. Even in those situations where PMTUD does work fine, doing TCP MSS adjustment will improve performance as the server does not need to spend an RTT to discover your reduced MTU. (This isn't really an IPv6 issue, by the way - ISPs using PPPoE will typically perform MSS adjustment for IPv4 packets too.) If you're using Linux as your tunnel endpoint, try: ip6tables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu Tore From dmitry at interhost.net Wed Mar 6 08:05:12 2019 From: dmitry at interhost.net (Dmitry Sherman) Date: Wed, 6 Mar 2019 08:05:12 +0000 Subject: Arista Layer3 In-Reply-To: References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> <20171130191750.GB32439@sizone.org> <20171130210022.GF32439@sizone.org> <0c4a81cd-ad54-b5c8-abb0-adaf10949090@bogus.com> <27F7E3C6-62D4-4E58-AE68-649A7C775104@dino.hostasaurus.com> <5C7EDC53.2030608@jack.fr.eu.org> Message-ID: <81EC084C-462A-42ED-BF94-C835759C2B66@interhost.net> Is there any reason to have 2M routes support for next 3 years? -- Dmitry Sherman Interhost Networks Ltd Dmitry at interhost.net Mobile: +972-54-3181182 Office: +972-74-7029881 Web: www.interhost.co.il From: NANOG on behalf of Roel Parijs Date: Wednesday, 6 March 2019 at 0:47 To: "nanog at nanog.org" Subject: Re: Arista Layer3 We have been using the 7280SR-48C6 for 2.5 years now. Just after Arista announced the full table BGP routing. Looking at the price / port there is nothing near Arista. We also use Cisco ASR1K and Juniper MX204 but these have far less capacity. When we first started, there were quite a few features missing but over the past 2 year they have really been catching up. I was very happy when they added MSS clamping at the end of last year. The new version 7280R2K should be able to handle 2M routes. On Tue, Mar 5, 2019 at 9:31 PM > wrote: Check out the 7280sr2k, which is actually 24*10G, 24*25G, 6*100G On 03/05/2019 08:55 PM, David Hubbard wrote: > I love the NCS5501, but once Arista gets the 2M-route capacity down into the 48x10g format, I'd jump ship in a heartbeat; currently you have to do a much larger chassis-based device or their 100gig 7280 to have that route scale. My big gripes with the 5501 are that, due to its architecture, if you want to do uRPF, you chop your route scale in half, even on the 5501-SE. 5501 also has no supported configuration where you have both first hop redundancy and physical path redundancy, because you can't do both VRRP (its only redundant first hop option) and BVI's, can't do MC-LAG, can't do vPC, so you need switches in addition to the 5501's if that's the goal.. > > David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists.nanog at monmotha.net Wed Mar 6 08:13:10 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Wed, 6 Mar 2019 03:13:10 -0500 Subject: Arista Layer3 In-Reply-To: <81EC084C-462A-42ED-BF94-C835759C2B66@interhost.net> References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> <20171130191750.GB32439@sizone.org> <20171130210022.GF32439@sizone.org> <0c4a81cd-ad54-b5c8-abb0-adaf10949090@bogus.com> <27F7E3C6-62D4-4E58-AE68-649A7C775104@dino.hostasaurus.com> <5C7EDC53.2030608@jack.fr.eu.org> <81EC084C-462A-42ED-BF94-C835759C2B66@interhost.net> Message-ID: <90869381-b1a4-c797-b9aa-c30675db9b79@monmotha.net> On 3/6/19 3:05 AM, Dmitry Sherman wrote: > Is there any reason to have 2M routes support for next 3 years? Full IPv4 table + full IPv6 table + multiple VRFs (BGP-VPN, etc.) plus lots of on-net deaggregates could well push you above 1M right now especially if your platform also shares that "1M" FIB space with next-hop L2 information, ARP/ND entries, etc. Bonus points for neeing MPLS info in FIB, too, on MPLS PE routers. IPv4 DFZ alone is rapidly growing to where it'll hit 1M for most viewpoints without FIB compression, though most end networks can probably compress it down a fair bit from that. 2M is the next "logical" FIB scale to target, I guess. I've seen 1.5M boxes, too, though the headline FIB scale is always suspect. You have to look at how other things that sit in TCAM will eat into that scale, whether it has static or dynamic CAM partitions, etc. -- Brandon Martin From lists.nanog at monmotha.net Wed Mar 6 08:14:21 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Wed, 6 Mar 2019 03:14:21 -0500 Subject: Arista Layer3 In-Reply-To: References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> <20171130191750.GB32439@sizone.org> <20171130210022.GF32439@sizone.org> <0c4a81cd-ad54-b5c8-abb0-adaf10949090@bogus.com> <27F7E3C6-62D4-4E58-AE68-649A7C775104@dino.hostasaurus.com> <5C7EDC53.2030608@jack.fr.eu.org> Message-ID: On 3/6/19 12:36 AM, Colton Conor wrote: > How much do these boxes cost? List is about $100k in North America for a 9640 with all the ports "unlocked", full hardware kit (PSUs, fans, etc.) and some maintenance/support. Take whatever your standard Brocade/Extreme discount from that tends to look like. I should hope nobody pays list or anywhere close. -- Brandon Martin From mark.tinka at seacom.mu Wed Mar 6 12:44:53 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 6 Mar 2019 14:44:53 +0200 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> <2EFF6363-393D-46D9-A282-F4A4CE7FFEB5@isc.org> <7bf1ee49-119e-77f4-6330-c4e8c92af843@si6networks.com> Message-ID: <604d4b44-4962-c6d8-8ca6-7ad31f97f74d@seacom.mu> On 6/Mar/19 08:29, Mark Andrews wrote: > Make a big enough stink and it will get fixed. People just don’t make enough of > a stink. Use social media. None of the companies with broken firewalls really > want their idiotic practices pointed out in public. Start doing so every time > you see it #STUPIDFIREWALL. I think the (Inter)network is growing a lot faster than we can shame folk into fixing things. Mark. From mark.tinka at seacom.mu Wed Mar 6 12:45:26 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 6 Mar 2019 14:45:26 +0200 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: <4a82c9a4-00a1-0cff-7b76-349367428757@si6networks.com> References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> <2EFF6363-393D-46D9-A282-F4A4CE7FFEB5@isc.org> <7bf1ee49-119e-77f4-6330-c4e8c92af843@si6networks.com> <4a82c9a4-00a1-0cff-7b76-349367428757@si6networks.com> Message-ID: <484d5bbc-6718-5a99-a63c-1155ab736e67@seacom.mu> On 6/Mar/19 08:38, Fernando Gont wrote: > > RFC4821 seems to signal that the IETF has given up in making ICMP-based > PMTUD work, and aims at a (mostly) ICMP-free PMTUD. As much as I hate to admit it, I think this is a more realistic approach. Mark. From mehmet at akcin.net Wed Mar 6 14:23:13 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 6 Mar 2019 09:23:13 -0500 Subject: Facebook Will Begin Selling Wholesale Fiber Capacity Message-ID: Just read this. https://datacenterfrontier.com/facebook-will-begin-selling-wholesale-fiber-capacity/?fbclid=IwAR3sgfisNYrQzzfJlanFSajIymOP-4USxhPR1s8MeiKtzNY4hRTdXYB2bz8 Looking forward to discussions. mehmet -------------- next part -------------- An HTML attachment was scrubbed... URL: From contemno at gmail.com Wed Mar 6 14:52:46 2019 From: contemno at gmail.com (Joshua Miller) Date: Wed, 6 Mar 2019 09:52:46 -0500 Subject: Best practices for BGP Communities In-Reply-To: References: <20190305230118.GO71660@vurt.meerval.net> Message-ID: Thanks for all the feedback. Follow up questions: How does one distinguish "informational" and "action" of unknown communities? Also, why would a transit provider go out of their way to remove unknown communities that don't have any meaning within their network? What benefit would it serve the transit provider? Best, Josh On Tue, Mar 5, 2019 at 8:18 PM Job Snijders wrote: > On Wed, Mar 6, 2019 at 8:32 Smith, Courtney > wrote: > >> On 3/5/19, 6:04 PM, "NANOG on behalf of Job Snijders" >> > job at instituut.net> wrote: >> >> On Sun, Mar 03, 2019 at 08:42:02PM -0500, Joshua Miller wrote: >> > A while back I read somewhere that transit providers shouldn't >> delete >> > communities unless the communities have a specific impact to their >> > network, but my google-fu is failing me and I can't find any >> sources. >> > >> > Is this still the case? Does anyone have a source for the practice >> of >> > leaving unknown communities alone or deleting them? >> >> https://tools.ietf.org/html/rfc7454#section-11 >> >> >> Remember policies between two peers may not be same as customer policies. >> >> Example: Customers_of_transit_X >>> Transit X >>> Peer_A >> >> Customers_of_Peer_A >> >> Customers_of_Peer_A may use community A:50 to set local pref to 50 in >> Peer_A network. But that doesn’t not mean Customers_of_transit_X can send >> A:50 to set lpref on their routes in Peer_A's network. Peer_A's policy >> with Transit X likely does not take action on customer communities since >> they are 'peers' not customers. Transit X can send A:50 to Peer_A but >> nothing would happen. What's the benefit of Transit X preserving A:50 from >> its customers if it means nothing in Transit X? > > > > OP didn’t specify what kind of BGP communities they were referring to. In > general we can separate communities into two categories: “Informational” > and “Action”. You are right that preserving/propagating “action” > communities (such as in your example) probably isn’t that interesting. > “informational” communities on the other hand can be very valuable. > > See https://tools.ietf.org/html/rfc8195 for more information on how the > two types differ. > > Kind regards, > > Job > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erich at gotfusion.net Wed Mar 6 16:57:13 2019 From: erich at gotfusion.net (Kaiser, Erich) Date: Wed, 6 Mar 2019 10:57:13 -0600 Subject: Arista Layer3 In-Reply-To: References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> <20171130191750.GB32439@sizone.org> <20171130210022.GF32439@sizone.org> <0c4a81cd-ad54-b5c8-abb0-adaf10949090@bogus.com> <27F7E3C6-62D4-4E58-AE68-649A7C775104@dino.hostasaurus.com> <5C7EDC53.2030608@jack.fr.eu.org> Message-ID: Agreed. On Wed, Mar 6, 2019 at 2:16 AM Brandon Martin wrote: > On 3/6/19 12:36 AM, Colton Conor wrote: > > How much do these boxes cost? > > List is about $100k in North America for a 9640 with all the ports > "unlocked", full hardware kit (PSUs, fans, etc.) and some > maintenance/support. Take whatever your standard Brocade/Extreme > discount from that tends to look like. I should hope nobody pays list > or anywhere close. > -- > Brandon Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Wed Mar 6 18:58:29 2019 From: sean at donelan.com (Sean Donelan) Date: Wed, 6 Mar 2019 13:58:29 -0500 (EST) Subject: March is Severe Weather Month - Plan Ahead for Disasters Message-ID: Network operators are involved in most weather disasters. March is Severe Weather Month in the U.S. The National Weather Service and many states use severe weather month to encourage public planning and preparedness. https://www.ready.gov/ https://www.weather.gov/wrn/ Remember, your Amazon Alexa, Google Assistant, Applie Siri smart speakers, smart TVs, and smart assistants won't practively warn you about emergency alerts or weather warnings. Amazon Alexa will tell you about weather warnings, but only when you ask about the weather. The FEMA National Advisory Council published its recommendations for Modernizing the Nation's Public Alert and Warning System, which included adding alerts to new technologies. https://www.fema.gov/media-library/assets/documents/177192 "Ensure people can receive and understand geo-targeted IPAWS messages in numerous ways, including social media, mobile aps, automotive GPS units, driverless cars and intelligent in-home automated systems (e.g., Smart Speakers)." I also have some suggestions for Wireless Emergency Alerts, in case any Apple iOS or Google Android developers are reading. 1. Improving the WEA Imminent Threat Class and Categories 2. Redefining the Child Abduction Emergency/AMBER class 3. Do Not Disturb WEA Behavior for Less Severe Alerts 4. Revising Sample WEA Options Menu 5. Default WEA class names for mobile device user interfaces https://www.donelan.com/WEA-Improvements.pdf https://www.donelan.com/eas.html From arnold at nipper.de Wed Mar 6 18:57:10 2019 From: arnold at nipper.de (Arnold Nipper) Date: Wed, 6 Mar 2019 19:57:10 +0100 Subject: Best practices for BGP Communities In-Reply-To: <20190304121511.18dff1b9@p50.localdomain> References: <0151bae74dec44b89820fa6522bcdf58@XCASPRD01.dpu.depaul.edu> <20190304121511.18dff1b9@p50.localdomain> Message-ID: On 04.03.2019 19:15, John Kristoff wrote: > On Mon, 4 Mar 2019 01:42:02 +0000 > Joshua Miller wrote: > >> A while back I read somewhere that transit providers shouldn't delete >> communities unless the communities have a specific impact to their >> network, but my google-fu is failing me and I can't find any sources. > > Perhaps you're referring to this recent work? > > > See also https://2019.apricot.net/assets/files/APKS756/weaponizing-bgp-using-communities.pdf Arnold -- Arnold Nipper email: arnold at nipper.de mobile: +49 172 2650958 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From mike.lyon at gmail.com Wed Mar 6 19:22:23 2019 From: mike.lyon at gmail.com (Mike Lyon) Date: Wed, 6 Mar 2019 11:22:23 -0800 Subject: Any peeps from Ookla on the list? Message-ID: If so, can you contact me off-list please? Thank You, Mike -- Mike Lyon mike.lyon at gmail.com http://www.linkedin.com/in/mlyon -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog-support at nanog.org Wed Mar 6 21:12:46 2019 From: nanog-support at nanog.org (NANOG Support) Date: Wed, 6 Mar 2019 16:12:46 -0500 Subject: 2019-2020 NANOG Scholarship Application Now Available Message-ID: NANOG is pleased to announce the 2019-2020 Scholarship Application is now available. The application will remain open until April 16, 2019. NANOG will be providing four (4) scholarships of $10,000 each for the 2019-2020 school year. Applicants must meet the listed criteria, and not be a prior recipient of a NANOG Scholarship. Please see https://www.nanog.org/scholarships for more information and a link to a flyer you can share. Students can go directly to the application site here: https://www.scholarsapply.org/nanog/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at shout.net Wed Mar 6 22:29:41 2019 From: bryan at shout.net (Bryan Holloway) Date: Wed, 6 Mar 2019 16:29:41 -0600 Subject: Anybody from switch.com (AS23005) lurking about? Message-ID: If so, could you please contact me off-list? From randy at psg.com Thu Mar 7 00:52:00 2019 From: randy at psg.com (Randy Bush) Date: Wed, 06 Mar 2019 16:52:00 -0800 Subject: Best practices for BGP Communities In-Reply-To: References: <20190305230118.GO71660@vurt.meerval.net> Message-ID: > How does one distinguish "informational" and "action" of unknown > communities? the action ones are divisible by 3 you are in a twisty maze where there are no formnally defined semantics, only a #:# syntax. if there were general formal semantics, it could have been put directly in bgp attributes. steaming pile From morrowc.lists at gmail.com Thu Mar 7 01:51:19 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 6 Mar 2019 20:51:19 -0500 Subject: Best practices for BGP Communities In-Reply-To: References: <20190305230118.GO71660@vurt.meerval.net> Message-ID: On Wed, Mar 6, 2019 at 7:53 PM Randy Bush wrote: > > How does one distinguish "informational" and "action" of unknown > > communities? > > "if the community is unknown why would you take any action except to strip it?" > the action ones are divisible by 3 > > > > you are in a twisty maze where there are no formnally defined semantics, > only a #:# syntax. if there were general formal semantics, it could > have been put directly in bgp attributes. > > isn't it really that the communities (well known aside) mean what you want them to mean? you get to be creative and have fun!! imagine the fun you'll leave behind with your follow on networking folks at your job!! great times! -------------- next part -------------- An HTML attachment was scrubbed... URL: From adamv0025 at netconsultings.com Thu Mar 7 15:19:13 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Thu, 7 Mar 2019 15:19:13 -0000 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> <20190305121401.GA12619@gsp.org> <005301d4d363$5bd2ed40$1378c7c0$@netconsultings.com> Message-ID: <004701d4d4f9$23023740$6906a5c0$@netconsultings.com> > From: Saku Ytti > Sent: Tuesday, March 5, 2019 3:00 PM > > On Tue, Mar 5, 2019 at 4:54 PM wrote: > > > Let me play a devil's advocate here, the above statement begs a question > then, how do you know all that is harmful would you test for every possible > extension and hw/sw permutation? > > So there would be 3 sets (though lines might be blurred) known safe, > known harmful and the biggest of them unknown unknowns. > > Now as an operator of a commercial network (i.e. your customers like it > mostly up) wouldn't you do a calculated risk evaluation and opt for the > known safe -which you know 99% of your customers use and block the rest > while pissing off the remaining 1%? > > I know it sounds awful (like a calculations for vehicle safety recalls), but ... > > > Fear is excellent marketing tool, as we can see in politics, works every time. > But I rather fix realised problems, rather than make unprovable assumptions > of actions yielding to net benefit. The assumption here is, if we just allow > ICMP types A, B and C we are gaining in security, can we substantiate that > claim at all? We can substantiate easily that the proposed ICMP filter breaks > real useful ICMP tooling. > > >From past experience my assumptions would be more along the lines of if it's not mainstream there's a higher likelihood that it might trigger exceptions in code. adam From saku at ytti.fi Thu Mar 7 15:29:07 2019 From: saku at ytti.fi (Saku Ytti) Date: Thu, 7 Mar 2019 17:29:07 +0200 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: <004701d4d4f9$23023740$6906a5c0$@netconsultings.com> References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> <20190305121401.GA12619@gsp.org> <005301d4d363$5bd2ed40$1378c7c0$@netconsultings.com> <004701d4d4f9$23023740$6906a5c0$@netconsultings.com> Message-ID: On Thu, Mar 7, 2019 at 5:19 PM wrote: > From past experience my assumptions would be more along the lines of if it's not mainstream there's a higher likelihood that it might trigger exceptions in code. My point is, let it break. Don't pre-emptively drop things that you don't know to be harmful, but where dropping definitely is harmful. After risk has realised you have more data about the risk. If it has never realised you have no idea. If we extrapolate this culture of fear, we will only have HTTPS open, nothing else, and we have to build then next-gen stuff as an overlay using HTTPS transport. -- ++ytti From adamv0025 at netconsultings.com Thu Mar 7 15:52:14 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Thu, 7 Mar 2019 15:52:14 -0000 Subject: Best practices for BGP Communities In-Reply-To: References: <0151bae74dec44b89820fa6522bcdf58@XCASPRD01.dpu.depaul.edu> <20190304121511.18dff1b9@p50.localdomain> Message-ID: <004d01d4d4fd$bfda82d0$3f8f8870$@netconsultings.com> > From: NANOG On Behalf Of Arnold Nipper > Sent: Wednesday, March 6, 2019 6:57 PM > > On 04.03.2019 19:15, John Kristoff wrote: > > On Mon, 4 Mar 2019 01:42:02 +0000 > > Joshua Miller wrote: > > > >> A while back I read somewhere that transit providers shouldn't delete > >> communities unless the communities have a specific impact to their > >> network, but my google-fu is failing me and I can't find any sources. > > > > Perhaps you're referring to this recent work? > > > > > > > > See also > > https://2019.apricot.net/assets/files/APKS756/weaponizing-bgp-using- > communities.pdf > > And the list goes on... Route-target extended community anyone? Yup I'm talking about routes being injected to your L3VPN customers'/services' routing-instances(VRFs). adam From adamv0025 at netconsultings.com Thu Mar 7 16:06:54 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Thu, 7 Mar 2019 16:06:54 -0000 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> <20190305121401.GA12619@gsp.org> <005301d4d363$5bd2ed40$1378c7c0$@netconsultings.com> <004701d4d4f9$23023740$6906a5c0$@netconsultings.com> Message-ID: <005201d4d4ff$cb83f9c0$628bed40$@netconsultings.com> Hey Saku, > From: Saku Ytti > Sent: Thursday, March 7, 2019 3:29 PM > > On Thu, Mar 7, 2019 at 5:19 PM wrote: > > > From past experience my assumptions would be more along the lines of if > it's not mainstream there's a higher likelihood that it might trigger exceptions > in code. > > My point is, let it break. Don't pre-emptively drop things that you don't know > to be harmful, but where dropping definitely is harmful. > > After risk has realised you have more data about the risk. If it has never > realised you have no idea. If we extrapolate this culture of fear, we will only > have HTTPS open, nothing else, and we have to build then next-gen stuff as > an overlay using HTTPS transport. > Sure I get it it's a very valid and a noble point, But what you're asking is let it break (yes potentially -it's just probability until it happens) for 1000s of subs just so that one kiddo has a working niche feature, I can already see what board has to say about that -screw that kid we have money to make there's our brand at stake (yes again just potentially -it's just probability until it actually happens) -but you'll already know what they're gonna say. So yes on a technical level I agree with you, but on a commercial level it's a tough case to make. And the same logic applies to the other thread around BGP communities filtering... adam From saku at ytti.fi Thu Mar 7 16:10:17 2019 From: saku at ytti.fi (Saku Ytti) Date: Thu, 7 Mar 2019 18:10:17 +0200 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: <005201d4d4ff$cb83f9c0$628bed40$@netconsultings.com> References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> <20190305121401.GA12619@gsp.org> <005301d4d363$5bd2ed40$1378c7c0$@netconsultings.com> <004701d4d4f9$23023740$6906a5c0$@netconsultings.com> <005201d4d4ff$cb83f9c0$628bed40$@netconsultings.com> Message-ID: On Thu, Mar 7, 2019 at 6:06 PM wrote: > Sure I get it it's a very valid and a noble point, > But what you're asking is let it break (yes potentially -it's just probability until it happens) for 1000s of subs just so that one kiddo has a working niche feature, I can already see what board has to say about that -screw that kid we have money to make there's our brand at stake (yes again just potentially -it's just probability until it actually happens) -but you'll already know what they're gonna say. > So yes on a technical level I agree with you, but on a commercial level it's a tough case to make. So why not disable ICMP Echo and UDP traceroute, those kids using network diagnostics don't need them. For clue constrained audience fear will always be the most compelling argument. -- ++ytti From list at satchell.net Thu Mar 7 18:30:35 2019 From: list at satchell.net (Stephen Satchell) Date: Thu, 7 Mar 2019 10:30:35 -0800 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> <20190305121401.GA12619@gsp.org> <005301d4d363$5bd2ed40$1378c7c0$@netconsultings.com> <004701d4d4f9$23023740$6906a5c0$@netconsultings.com> <005201d4d4ff$cb83f9c0$628bed40$@netconsultings.com> Message-ID: On 3/7/19 8:10 AM, Saku Ytti wrote: > So why not disable ICMP Echo and UDP traceroute, those kids using > network diagnostics don't need them. > > For clue constrained audience fear will always be the most compelling argument. OK, OK, so I will continue to rate-limit both, to reasonably high limits on the order of 250/second. Absent a DoS, it allows network operators to use these tools as they should. My logs show no harm except to attack traffic. Everything in moderation. From saku at ytti.fi Thu Mar 7 18:52:35 2019 From: saku at ytti.fi (Saku Ytti) Date: Thu, 7 Mar 2019 20:52:35 +0200 Subject: WIndows Updates Fail Via IPv6 - Update! In-Reply-To: References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <09a266e2-9013-fcc9-b4cf-d0e290bbcb7a@seacom.mu> <8f4f30f5-b924-d527-876e-94d17521575d@seacom.mu> <20190305121401.GA12619@gsp.org> <005301d4d363$5bd2ed40$1378c7c0$@netconsultings.com> <004701d4d4f9$23023740$6906a5c0$@netconsultings.com> <005201d4d4ff$cb83f9c0$628bed40$@netconsultings.com> Message-ID: On Thu, Mar 7, 2019 at 8:33 PM Stephen Satchell wrote: > OK, OK, so I will continue to rate-limit both, to reasonably high limits > on the order of 250/second. Absent a DoS, it allows network operators > to use these tools as they should. > > My logs show no harm except to attack traffic. > > Everything in moderation. Yes this is fair, all untrusted traffic to control-plane should be limited. But the question was, what about ICMP types you don't know about, like timestamps, is it fair to drop those just because we didn't know about them? What are the risks? Essentially timestamp it's just echo which happens to have timestamp from each side, hard to imagine a threat if ICMP echo is not also considered a threat. And massive benefit in diagnostics if you are able tell that issue is unidirectional and which direction is the culprit. Similarly, what about the ICMP type which doesn't exist yet? Should that be victim of our protection mechanism? This is essentially the reason why we can't introduce new L4 protocols, because Internet is full of networks on autopilot with legacy policies where we drop things we don't know about, without having any specific realised threat or way to test if that threat is still valid. And even if there are threats, remember ICMP echo f00fc7c8, +++ or plethora of crash bugs? We still run ICMP echo, because the diagnostic value exceeds the cost of the risk. What tools and protocols are we missing, because we never specify them as we know they would never work in practice? We have beautiful, expressive, extendible protocols and then operational policies which nullify that. We recently had crash bug in pseudowire LSP ping, but it gives us operational benefits so we'll just address the bug and we will continue using the tool. Threat was realised, but it was lower cost than the cost of losing the tool. -- ++ytti From colton.conor at gmail.com Fri Mar 8 03:44:34 2019 From: colton.conor at gmail.com (Colton Conor) Date: Thu, 7 Mar 2019 21:44:34 -0600 Subject: Arista Layer3 In-Reply-To: References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> <20171130191750.GB32439@sizone.org> <20171130210022.GF32439@sizone.org> <0c4a81cd-ad54-b5c8-abb0-adaf10949090@bogus.com> <27F7E3C6-62D4-4E58-AE68-649A7C775104@dino.hostasaurus.com> <5C7EDC53.2030608@jack.fr.eu.org> Message-ID: So how does the 7280SR-48C6 compare to the SLX9540? They are the same Broadcom chipset right? So the real question, is how does the product differ in software? On Wed, Mar 6, 2019 at 10:58 AM Kaiser, Erich wrote: > Agreed. > > > On Wed, Mar 6, 2019 at 2:16 AM Brandon Martin > wrote: > >> On 3/6/19 12:36 AM, Colton Conor wrote: >> > How much do these boxes cost? >> >> List is about $100k in North America for a 9640 with all the ports >> "unlocked", full hardware kit (PSUs, fans, etc.) and some >> maintenance/support. Take whatever your standard Brocade/Extreme >> discount from that tends to look like. I should hope nobody pays list >> or anywhere close. >> -- >> Brandon Martin >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgont at si6networks.com Fri Mar 8 06:42:10 2019 From: fgont at si6networks.com (Fernando Gont) Date: Fri, 8 Mar 2019 03:42:10 -0300 Subject: IPv6 Security Frequently Asked Questions (FAQ) Message-ID: Folks, The Internet Society has posted the "IPv6 Security Frequently Asked Questions (FAQ)" I authored. The document is available (in HTML, and also easy-to-print PDF) at: https://www.internetsociety.org/deploy360/ipv6/security/faq/ If you think there are other questions that should be added, or have comments on the answers, please do let me know -- the document can eventually be revised. Thanks! Cheers, -- -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From marka at isc.org Fri Mar 8 07:10:38 2019 From: marka at isc.org (Mark Andrews) Date: Fri, 8 Mar 2019 18:10:38 +1100 Subject: IPv6 Security Frequently Asked Questions (FAQ) In-Reply-To: References: Message-ID: <39DE85E5-35DD-44D3-8616-C53C2C8555EA@isc.org> "Generation of IPv6 fragments in response to ICMPv6 PTB messages has been deprecated in the revised IPv6 specification" IS INCORRECT generation of fragments is “discouraged". Discouraged and deprecated mean different thing. However, the use of such fragmentation is discouraged in any application that is able to adjust its packets to fit the measured path MTU (i.e., down to 1280 octets). the whole of 4.4 is very badly worded and states things as fact which don’t appear in RFC’s at all. The adding of a fragmentation header for PTB <1280 has gone. Fragmentation down to 1280 is still supposed to happen in response to a PTB. Packets still have to flow through paths that narrow down to 1280. > On 8 Mar 2019, at 5:42 pm, Fernando Gont wrote: > > Folks, > > The Internet Society has posted the "IPv6 Security Frequently Asked > Questions (FAQ)" I authored. > > The document is available (in HTML, and also easy-to-print PDF) at: > > https://www.internetsociety.org/deploy360/ipv6/security/faq/ > > If you think there are other questions that should be added, or have > comments on the answers, please do let me know -- the document can > eventually be revised. > > Thanks! > > Cheers, > -- > -- > Fernando Gont > SI6 Networks > e-mail: fgont at si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From fgont at si6networks.com Fri Mar 8 07:30:54 2019 From: fgont at si6networks.com (Fernando Gont) Date: Fri, 8 Mar 2019 04:30:54 -0300 Subject: IPv6 Security Frequently Asked Questions (FAQ) In-Reply-To: <39DE85E5-35DD-44D3-8616-C53C2C8555EA@isc.org> References: <39DE85E5-35DD-44D3-8616-C53C2C8555EA@isc.org> Message-ID: Hello, Mark, Thanks for your feedback! Please see in-line.... On 8/3/19 04:10, Mark Andrews wrote: > "Generation of IPv6 fragments in response to ICMPv6 PTB messages has been deprecated in the revised IPv6 specification" > > IS INCORRECT > > generation of fragments is “discouraged". Discouraged and deprecated mean different thing. There is a writeo here. The text should have said "generation of IPv6 atomic fragments", or, "Generation of IPv6 fragments in response to ICMPv6 PTB messages advertising an MTU smaller than 1280" The whole section refers to "atomic fragments" which might be generated even for protocols that are not supposed to employ fragmentation. I will clarify this in the next rev. > > However, the use of such > fragmentation is discouraged in any application that is able to > adjust its packets to fit the measured path MTU (i.e., down to 1280 > octets). > > the whole of 4.4 is very badly worded and states things as fact which don’t > appear in RFC’s at all. Please let me know if, considering the writeo I referred to above, you still feel the same. > > The adding of a fragmentation header for PTB <1280 has gone. Fragmentation > down to 1280 is still supposed to happen in response to a PTB. Packets still > have to flow through paths that narrow down to 1280. Agreed. This section is referred to this scenario: Say two nodes only mean to employ a TCP-based application (say two BGP peers). Say they filter fragments directed to them, since the TCP connections will avoid fragmentation. In such cases, what would seem as a "safe practice" may be not: if the involved systems employ a legacy IPv6 implementation, then an attacker can trigger the generation of IPv6 fragments (even for TCP conenctions) by spoofing an ICMPv6 PTB claiming an MTU < 1280. This is what this section is about: If you are going to drop fragments, make sure you also take care of ICMPv6 PTBs, since they may trigger fragmentation even for protocols that you'd assume would never emply fragmentation. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From marka at isc.org Fri Mar 8 07:36:07 2019 From: marka at isc.org (Mark Andrews) Date: Fri, 8 Mar 2019 18:36:07 +1100 Subject: IPv6 Security Frequently Asked Questions (FAQ) In-Reply-To: References: <39DE85E5-35DD-44D3-8616-C53C2C8555EA@isc.org> Message-ID: <7A832CA2-951A-47BE-B9E4-9E1E256FED09@isc.org> > On 8 Mar 2019, at 6:30 pm, Fernando Gont wrote: > > Hello, Mark, > > Thanks for your feedback! Please see in-line.... > > On 8/3/19 04:10, Mark Andrews wrote: >> "Generation of IPv6 fragments in response to ICMPv6 PTB messages has been deprecated in the revised IPv6 specification" >> >> IS INCORRECT >> >> generation of fragments is “discouraged". Discouraged and deprecated mean different thing. > > There is a writeo here. The text should have said "generation of IPv6 > atomic fragments", or, > > "Generation of IPv6 fragments in response to ICMPv6 PTB messages > advertising an MTU smaller than 1280" > > > The whole section refers to "atomic fragments" which might be generated > even for protocols that are not supposed to employ fragmentation. > > I will clarify this in the next rev. Thanks >> However, the use of such >> fragmentation is discouraged in any application that is able to >> adjust its packets to fit the measured path MTU (i.e., down to 1280 >> octets). >> >> the whole of 4.4 is very badly worded and states things as fact which don’t >> appear in RFC’s at all. > > Please let me know if, considering the writeo I referred to above, you > still feel the same. I think I’ll reserve judgement until I have seen the re-write. >> The adding of a fragmentation header for PTB <1280 has gone. Fragmentation >> down to 1280 is still supposed to happen in response to a PTB. Packets still >> have to flow through paths that narrow down to 1280. > > Agreed. > > This section is referred to this scenario: > > Say two nodes only mean to employ a TCP-based application (say two BGP > peers). Say they filter fragments directed to them, since the TCP > connections will avoid fragmentation. > > In such cases, what would seem as a "safe practice" may be not: if the > involved systems employ a legacy IPv6 implementation, then an attacker > can trigger the generation of IPv6 fragments (even for TCP conenctions) > by spoofing an ICMPv6 PTB claiming an MTU < 1280. > > This is what this section is about: If you are going to drop fragments, > make sure you also take care of ICMPv6 PTBs, since they may trigger > fragmentation even for protocols that you'd assume would never emply > fragmentation. > > Thanks! > > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fgont at si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From lists.nanog at monmotha.net Fri Mar 8 10:51:32 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Fri, 8 Mar 2019 05:51:32 -0500 Subject: Arista Layer3 In-Reply-To: References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> <20171130191750.GB32439@sizone.org> <20171130210022.GF32439@sizone.org> <0c4a81cd-ad54-b5c8-abb0-adaf10949090@bogus.com> <27F7E3C6-62D4-4E58-AE68-649A7C775104@dino.hostasaurus.com> <5C7EDC53.2030608@jack.fr.eu.org> Message-ID: On 3/7/19 10:44 PM, Colton Conor wrote: > So how does the 7280SR-48C6 compare to the SLX9540? They are the same > Broadcom chipset right? So the real question, is how does the product > differ in software? I think a 9540 would compare more directly against a Nexus 9k series device. They're targeted more at datacenter switching but have full L3 + MPLS and some features useful for carrier applications as well. -- Brandon Martin From lists.nanog at monmotha.net Fri Mar 8 11:18:35 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Fri, 8 Mar 2019 06:18:35 -0500 Subject: Arista Layer3 In-Reply-To: References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> <20171130191750.GB32439@sizone.org> <20171130210022.GF32439@sizone.org> <0c4a81cd-ad54-b5c8-abb0-adaf10949090@bogus.com> <27F7E3C6-62D4-4E58-AE68-649A7C775104@dino.hostasaurus.com> <5C7EDC53.2030608@jack.fr.eu.org> Message-ID: <5a129cb2-2da9-d623-6a21-9202b97a059c@monmotha.net> On 3/8/19 5:51 AM, Brandon Martin wrote: > On 3/7/19 10:44 PM, Colton Conor wrote: >> So how does the 7280SR-48C6 compare to the SLX9540? They are the same >> Broadcom chipset right? So the real question, is how does the product >> differ in software? I just realized that the 7280SR is an Arista device, not Cisco. Argh...too many similar model numbers. I haven't used Arista much at all really. -- Brandon Martin From fgont at si6networks.com Fri Mar 8 11:32:08 2019 From: fgont at si6networks.com (Fernando Gont) Date: Fri, 8 Mar 2019 08:32:08 -0300 Subject: SLAAC in renumbering events Message-ID: <41ee9908-03e9-0e4b-a651-8ad1e2f52d74@si6networks.com> Folks, If you follow the 6man working group of the IETF you may have seen a bunch of emails on this topic, on a thread resulting from an IETF Internet-Draft we published with Jan Žorž about "Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering Events" (Available at: https://github.com/fgont/draft-slaac-renum/raw/master/draft-gont-6man-slaac-renum-02.txt ) Short version of story: There are a number of scenarios where SLAAC hosts may end up using stale configuration information. For example, a typical IPv6 deployment scenario is that in which a CPE router requests an IPv6 prefix to an ISP via DHCPv6-PD, and advertises a sub-prefix of of the leased prefix on the LAN-side, via SLAAC. In such scenarios, if the CPE router crashes and reboots, it may loose all information about the previously-leased prefix. Upon reboot, the CPE router may be leased a new prefix that will result in a new sub-prefix being advertised on the LAN-side of the CPE router. As a result, hosts will normally configure addresses for the newly-advertised prefix, but will normally also keep (and use) the previously-configured (and now stale!) IPv6 addresses, leading to interoperability problems. The RIPE-690 BCOP document had originally tried to address this problem by recommending operators to lease stable IPv6 prefixes to CPE routers. However, for a variety of reasons ISP may not be able (or may not want) to lease stable prefixes, and may instead lease dynamic prefixes. Most of the voices on the 6man wg mailing-list fell into one of the following camps: * "ISPs should be leasing stable prefixes -- if they don't, they are asking for trouble!" * "CPE routers should record leased prefixes on stable storage, such that they can 'deprecate' such prefixes upon restart -- if they don't, they are asking for trouble!" * "No matter whose fault is this (if there is any single party to blame in the first place), we should improve the robustness of IPv6 deployments" Our Internet-Draft tries to improve the current state of affairs via the following improvements: * Allow hosts to gracefully recover from stale network configuration information -- i.e., detect and discard stale network configuration information * Have SLAAC routers employ more appropriate timers, such that information is phased-out in a timelier manner -- unless it is actively refreshed by Router Advertisement messages * Specify the interaction between DHCPv6-PD and SLAAC -- which was rather under-specified * Require CPE routers to store leased prefixes on stable storage, and deprecate stale prefixes (if necessary) upon restart We are looking forward to more input on the document (or any comments on the issue being discussed), particularly from operators. So feel free to send your comments on/off list as you prefer Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From jdpauget at rezopole.net Fri Mar 8 12:51:27 2019 From: jdpauget at rezopole.net (Jean-Daniel Pauget) Date: Fri, 8 Mar 2019 13:51:27 +0100 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: <1f4410fe-2816-b358-ee52-5a3a23bef865@fud.no> References: <20190227100105.GF19597@arundodonax.nekodune.net> <1f4410fe-2816-b358-ee52-5a3a23bef865@fud.no> Message-ID: <20190308125127.GC24828@arundodonax.nekodune.net> hello, Tore Anderson, you're right, clamping MSS is very efficient and very certainly solves most of the problems. now for UDP, I don't know yet how does things like QUIC can be handled ... regards, -- Jean-Daniel Pauget http://rezopole.net/ Rezopole/LyonIX +33 (0)4 27 46 00 50 On Wed, Mar 06, 2019 at 08:17:42AM +0100, Tore Anderson wrote: > * Jean-Daniel Pauget > > > I confess using IPv6 behind a 6in4 tunnel because the "Business-Class" service > > of the concerned operator doesn't handle IPv6 yet. > > > > as such, I realised that, as far as I can figure, ICMPv6 packet "too-big" (rfc 4443) > > seem to be ignored or filtered at ~60% of ClouFlare's http farms > > > > as a result, random sites such as http://nanog.org/ or https://www.ansible.com/ > > are badly reachable whenever small mtu are involved ... > > Hi Jean-Daniel. > > If you're using using tunnels you'll want to have your tunnel endpoint > adjust down the TCP MSS value to match the MTU of the tunnel interface. > That way, you'll avoid problems with Path MTU Discovery. Even in those > situations where PMTUD does work fine, doing TCP MSS adjustment will > improve performance as the server does not need to spend an RTT to > discover your reduced MTU. > > (This isn't really an IPv6 issue, by the way - ISPs using PPPoE will > typically perform MSS adjustment for IPv4 packets too.) > > If you're using Linux as your tunnel endpoint, try: > > ip6tables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu > > Tore From saku at ytti.fi Fri Mar 8 13:38:19 2019 From: saku at ytti.fi (Saku Ytti) Date: Fri, 8 Mar 2019 15:38:19 +0200 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: <20190308125127.GC24828@arundodonax.nekodune.net> References: <20190227100105.GF19597@arundodonax.nekodune.net> <1f4410fe-2816-b358-ee52-5a3a23bef865@fud.no> <20190308125127.GC24828@arundodonax.nekodune.net> Message-ID: Hey, > now for UDP, I don't know yet how does things like QUIC can be handled ... Unfortunately the magic answer you were hoping does not exist, what they do is they just send smaller packets. -- ++ytti From lists.nanog at monmotha.net Fri Mar 8 13:45:20 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Fri, 8 Mar 2019 08:45:20 -0500 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: References: <20190227100105.GF19597@arundodonax.nekodune.net> <1f4410fe-2816-b358-ee52-5a3a23bef865@fud.no> <20190308125127.GC24828@arundodonax.nekodune.net> Message-ID: <63147452-12b7-d259-f4f2-3e255a72f610@monmotha.net> On 3/8/19 8:38 AM, Saku Ytti wrote: > Hey, > >> now for UDP, I don't know yet how does things like QUIC can be handled ... > > Unfortunately the magic answer you were hoping does not exist, what > they do is they just send smaller packets. > What we almost seem to be moving toward in this discussion is an IP header where the path can reduce the reported MTU which can then be read at the receiving end. This would be somewhat like ECN just with more than a couple bits. Of course, we know how well extension headers, much less hop-by-hop headers, are handled on IPv6... Re-writing a field in the L4 header works, but it seems ugly since it means every hop that reduces the MTU of the link has to know every L4 that participates in such a scheme. ICMP is nice in that it's totally protocol agnostic and doesn't require altering of packets in transit. It's a shame we can't reasonably rely on it being delivered. -- Brandon Martin From ximaera at gmail.com Fri Mar 8 14:03:30 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Fri, 8 Mar 2019 23:03:30 +0900 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> References: <20190227100105.GF19597@arundodonax.nekodune.net> <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> Message-ID: On Tue, Mar 5, 2019, 7:27 AM Mark Andrews wrote: > [..] their inability to purchase > devices that work with RFC compliant data streams. > To prove your point, you may want to provide a sample list of devices that work that way, along with the benchmarks showing that those devices could still handle arbitrary junk ICMP packets at a line rate. NB: Cloudflare is basically busy filtering excessive amounts of spoofed ICMP packets containing whatever parameters and payload criminals could fit into, at virtually no cost for a customer. Your list might become somewhat short then. -- Töma > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeroen at massar.ch Fri Mar 8 14:09:28 2019 From: jeroen at massar.ch (Jeroen Massar) Date: Fri, 8 Mar 2019 15:09:28 +0100 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: <63147452-12b7-d259-f4f2-3e255a72f610@monmotha.net> References: <20190227100105.GF19597@arundodonax.nekodune.net> <1f4410fe-2816-b358-ee52-5a3a23bef865@fud.no> <20190308125127.GC24828@arundodonax.nekodune.net> <63147452-12b7-d259-f4f2-3e255a72f610@monmotha.net> Message-ID: <51e7ca62-75d2-170d-98fa-6341972dbad3@massar.ch> On 2019-03-08 14:45, Brandon Martin wrote: > On 3/8/19 8:38 AM, Saku Ytti wrote: >> Hey, >> >>>      now for UDP, I don't know yet how does things like QUIC can be handled ... >> >> Unfortunately the magic answer you were hoping does not exist, what >> they do is they just send smaller packets. >> > > What we almost seem to be moving toward in this discussion is an IP header where the path can reduce the reported MTU which can then be read at the receiving end.  This would be somewhat like ECN just with more than a couple bits. Something like what I once described in: https://jeroen.massar.ch/archive/drafts/draft-massar-v6man-mtu-label-02.txt ? :) Greets, Jeroen From saku at ytti.fi Fri Mar 8 14:11:31 2019 From: saku at ytti.fi (Saku Ytti) Date: Fri, 8 Mar 2019 16:11:31 +0200 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: References: <20190227100105.GF19597@arundodonax.nekodune.net> <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> Message-ID: Hey Töma, > NB: Cloudflare is basically busy filtering excessive amounts of spoofed ICMP packets containing whatever parameters and payload criminals could fit into, at virtually no cost for a customer. Your list might become somewhat short then. I don't know what is the problem is here, but the Cloudflare blog documents one specific problem related to ECMP, where the ICMPv6 messages arrive at wrong host and some solutions they are using to overcome that problem. You are proposing that in this case, there is no such issue of delivering ICMPv6 messages to correct host, but in this case issue is voluntary protection mechanism against too high volume of bad ICMPv6 packets. Is this something you personally are aware of or is this something you suspect might explain the problem? Personally I'm surprised if ICMP volume is relevant based on our netflow data. And I've personally been affected in own deployments with the ECMP problem and have solved it by just sending smaller packets. I understand it to be common problem and it would be good if we'd start asking vendors to fix the problem. The Cloudflare blog entry is 4 years old, if they had started actively pursuing proper fix to the ECMP problem, the fix would be in production right about now. -- ++ytti From tarko at lanparty.ee Fri Mar 8 14:21:54 2019 From: tarko at lanparty.ee (Tarko Tikan) Date: Fri, 8 Mar 2019 16:21:54 +0200 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: References: <20190227100105.GF19597@arundodonax.nekodune.net> <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> Message-ID: <1142a1f4-014a-88be-5765-bbfb7151bd83@lanparty.ee> hey, > The Cloudflare blog > entry is 4 years old, if they had started actively pursuing proper fix > to the ECMP problem, the fix would be in production right about now. You can find more recent overview at https://blog.cloudflare.com/increasing-ipv6-mtu/ -- tarko From ximaera at gmail.com Fri Mar 8 15:44:05 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Fri, 8 Mar 2019 18:44:05 +0300 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: References: <20190227100105.GF19597@arundodonax.nekodune.net> <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> Message-ID: On Fri, Mar 8, 2019 at 5:11 PM Saku Ytti wrote: > Personally I'm surprised if ICMP volume is relevant based on our > netflow data. Legitimate ICMP traffic volume — oh, that's for sure. But when it comes to attack volumes, it's a different story, and current netflow measurements might be a bad indicator here, as in "peacetime generals are always fighting the last war instead of the next one". > You are proposing that in this case, there is no such issue of > delivering ICMPv6 messages to correct host Guaranteed delivery of untrusted remote messages to exactly the particular host behind an equal cost fanout, if allowed in a DDoS mitigation network, is itself a problem, but that has been discussed in detail in the Section 6 of RFC 6437. My point is that it might be hard to find an affordable device that implements ECMP with v6 flow labels without a considerable performance impact. I would personally happy to see what others have tested in that regard. -- Töma From ekim9190 at gmail.com Fri Mar 8 16:38:58 2019 From: ekim9190 at gmail.com (Michael Starr) Date: Fri, 8 Mar 2019 11:38:58 -0500 Subject: Arista Layer3 (Colton Conor) In-Reply-To: References: Message-ID: I can't comment on the direct comparison of the SLX9540, but we have 8x 7280SR deployed across our network (just migrated off all the Brocades we had) and have had amazing success with them. The number of informational or "show" commands isn't as extensive as some of the others that have been around for a while and the output of some of them is a little jarring, but otherwise I have no complaints. All of my BGP sessions (200-300 IX sessions, 2 transit providers, 28 iBGP) are fully populated in <10 seconds (i know many of your networks are much larger than ours). As for pricing, I don't have list, but for the box, memory upgrade, and routing license we paid much less than 100k -- Of course the port density Feel free to reach out directly for more specific information :) Mike On Fri, Mar 8, 2019 at 7:00 AM wrote: Message: 8 Date: Thu, 7 Mar 2019 21:44:34 -0600 From: Colton Conor To: "Kaiser, Erich" Cc: NANOG list Subject: Re: Arista Layer3 Message-ID: Content-Type: text/plain; charset="utf-8" So how does the 7280SR-48C6 compare to the SLX9540? They are the same Broadcom chipset right? So the real question, is how does the product differ in software? On Wed, Mar 6, 2019 at 10:58 AM Kaiser, Erich wrote: > Agreed. > > > On Wed, Mar 6, 2019 at 2:16 AM Brandon Martin > wrote: > >> On 3/6/19 12:36 AM, Colton Conor wrote: >> > How much do these boxes cost? >> >> List is about $100k in North America for a 9640 with all the ports >> "unlocked", full hardware kit (PSUs, fans, etc.) and some >> maintenance/support. Take whatever your standard Brocade/Extreme >> discount from that tends to look like. I should hope nobody pays list >> or anywhere close. >> -- >> Brandon Martin >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From saku at ytti.fi Fri Mar 8 16:48:48 2019 From: saku at ytti.fi (Saku Ytti) Date: Fri, 8 Mar 2019 18:48:48 +0200 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: References: <20190227100105.GF19597@arundodonax.nekodune.net> <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> Message-ID: On Fri, Mar 8, 2019 at 5:44 PM Töma Gavrichenkov wrote: > My point is that it might be hard to find an affordable device that > implements ECMP with v6 flow labels without a considerable performance > impact. I would personally happy to see what others have tested in > that regard. Why do you think it would be expensive? It's cheaper than how ECMP is done for L3 keys, because you just read the flow label and not calculate any hash. Much much cheaper than how ECMP is done for L3+L4 keys, if that is done right, which it is not, because no device implements IPv6 correctly, as it's not possible in reasonably performing hardware, but this has nothing to do with ECMP. But in any case, flow labels is not the right solution here, this is not IPv6 problem, this is IP problem. The right solution is to look at L3+L4 inside the embedded ICMP packet, as that solves the problem for both AFIs. This at most costs one branch (negligible in typical NPU), as you set different static offset based on if you're parsing ICMP or not. In all likelyhood it costs nothing, as the code likely already contains branch for ICMP where you can just reset the ECMP offset. I still fail to understand why you think this particular problem has anything to do attacks or ICMP volume, I find no such indications, and the two cloudflare blog articles do not state attacks as motivators to this, it's just technical problem at delivering the ICMP packets to correct host. A real problem affecting other networks too, but a problem we can fix, if we start asking our vendors for a fix. -- ++ytti From gerry at tape.net Thu Mar 7 23:02:59 2019 From: gerry at tape.net (Gerry Boudreaux) Date: Thu, 07 Mar 2019 17:02:59 -0600 Subject: GPS week number rollover event on April 6th Message-ID: For those who have GPS based NTP servers. https://ics-cert.us-cert.gov/sites/default/files/documents/Memorandum_on_GPS_2019.pdf G From ximaera at gmail.com Fri Mar 8 17:06:45 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Fri, 8 Mar 2019 20:06:45 +0300 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: References: <20190227100105.GF19597@arundodonax.nekodune.net> <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> Message-ID: On Fri, Mar 8, 2019 at 7:48 PM Saku Ytti wrote: > Why do you think it would be expensive? It's cheaper than how ECMP is > done for L3 keys, because you just read the flow label and not > calculate any hash. The most honest answer would be: I have no idea. That's just what I've seen, rather briefly though, as we weren't going to investigate that part at the time. It's been a while since then, and maybe there was a mistake on our side (at least within a perfectly academic context I must assume that there was, as there was no peer review — we were not in academy after all!), but I'm still inclined to, first, see the benchmarks of any proposed piece of hardware that's promising you ECMP with flow labels, second, make any statements about the latter. -- Töma From saku at ytti.fi Fri Mar 8 17:18:34 2019 From: saku at ytti.fi (Saku Ytti) Date: Fri, 8 Mar 2019 19:18:34 +0200 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: References: <20190227100105.GF19597@arundodonax.nekodune.net> <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> Message-ID: On Fri, Mar 8, 2019 at 7:07 PM Töma Gavrichenkov wrote: > It's been a while since then, and maybe there was a mistake on our > side (at least within a perfectly academic context I must assume that > there was, as there was no peer review — we were not in academy after > all!), but I'm still inclined to, first, see the benchmarks of any > proposed piece of hardware that's promising you ECMP with flow labels, > second, make any statements about the latter. 1) current implementation - set offset byte to 8 - read 128 bits to memory1 - read 128 bits to memory2 - return hash_function(memory1, memory2) This is _JUST_ for L3 keys, in reality customers want L4 keys too, so it's more expensive. Particularly in IPv6 the L4 keys could be _anywhere_ potentially gigabytes in future, for same reasons in IPv6 you can bypass ACL filters in many cases, because the HW device won't know what the L4 keys are. 2) flow label implementation - set offset to 12 bits - read 20 bits to memory1 - return memory1 Seems cheaper to me. But still not a good solution, as it is AFI specific and requires us to actually use the flow label consistently, which is not universally true. ECMP on embedded ICMP actually would work without any changes anywhere else but the device calculating the hash. -- ++ytti From pkranz at unwiredltd.com Fri Mar 8 17:23:59 2019 From: pkranz at unwiredltd.com (Peter Kranz) Date: Fri, 8 Mar 2019 09:23:59 -0800 Subject: Arista Layer3 (Colton Conor) In-Reply-To: References: Message-ID: <00e201d4d5d3$b7848c80$268da580$@unwiredltd.com> These boxes are available with 3 different FIB options currently.. 7280R > 1M route 7280R2 (Jericho+) > 1.3M routes 7280R2K (Jericho+) > 2M routes On top of the base FIB capabilities, EOS 4.21.3F adds FIB compression and 2-to-1 route compression features that give quite a bit of headroom for the next few years of growth. As mentioned in other comments, these boxes are very affordable, as significant discounts from list are the norm. Peter Kranz www.UnwiredLtd.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Fri Mar 8 17:40:42 2019 From: bill at herrin.us (William Herrin) Date: Fri, 8 Mar 2019 09:40:42 -0800 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: <63147452-12b7-d259-f4f2-3e255a72f610@monmotha.net> References: <20190227100105.GF19597@arundodonax.nekodune.net> <1f4410fe-2816-b358-ee52-5a3a23bef865@fud.no> <20190308125127.GC24828@arundodonax.nekodune.net> <63147452-12b7-d259-f4f2-3e255a72f610@monmotha.net> Message-ID: On Fri, Mar 8, 2019 at 5:45 AM Brandon Martin wrote: > ICMP is nice in that it's totally protocol agnostic and doesn't require > altering of packets in transit. It's a shame we can't reasonably rely > on it being delivered. > Path MTU discovery is broken. It's the one place in TCP/IP where the end-to-end principle was thrown out the window and we keep on paying for it. A correct solution would have been for the intermediate router to truncate the packet. Not fragment, truncate. On receiving the truncated packet, the RECIPIENT (not the intermediate router) would report the truncation to the sender. This could easily have been done at layer 3, just like existing PMTUD. IPv4's inventors did a brilliant job with what they knew at the time. IPv6's inventors not so much. Sadly, they were too busy figuring out how to make IPv6 integrate well with ATM. Seriously, if you dig up a copy of the original IPng book I think it's chapter 3. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From cscora at apnic.net Fri Mar 8 18:03:34 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 9 Mar 2019 04:03:34 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190308180334.F2D46C55A1@thyme.apnic.net> 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 at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 09 Mar, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 740306 Prefixes after maximum aggregation (per Origin AS): 285904 Deaggregation factor: 2.59 Unique aggregates announced (without unneeded subnets): 356243 Total ASes present in the Internet Routing Table: 63449 Prefixes per ASN: 11.67 Origin-only ASes present in the Internet Routing Table: 54648 Origin ASes announcing only one prefix: 23590 Transit ASes present in the Internet Routing Table: 8801 Transit-only ASes present in the Internet Routing Table: 271 Average AS path length visible in the Internet Routing Table: 4.2 Max AS path length visible: 30 Max AS path prepend of ASN ( 16327) 25 Prefixes from unregistered ASNs in the Routing Table: 28 Number of instances of unregistered ASNs: 31 Number of 32-bit ASNs allocated by the RIRs: 26062 Number of 32-bit ASNs visible in the Routing Table: 21215 Prefixes from 32-bit ASNs in the Routing Table: 92922 Number of bogon 32-bit ASNs visible in the Routing Table: 26 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 255 Number of addresses announced to Internet: 2842211683 Equivalent to 169 /8s, 104 /16s and 181 /24s Percentage of available address space announced: 76.8 Percentage of allocated address space announced: 76.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.2 Total number of prefixes smaller than registry allocations: 248230 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 201454 Total APNIC prefixes after maximum aggregation: 57939 APNIC Deaggregation factor: 3.48 Prefixes being announced from the APNIC address blocks: 198125 Unique aggregates announced from the APNIC address blocks: 81878 APNIC Region origin ASes present in the Internet Routing Table: 9526 APNIC Prefixes per ASN: 20.80 APNIC Region origin ASes announcing only one prefix: 2681 APNIC Region transit ASes present in the Internet Routing Table: 1405 Average APNIC Region AS path length visible: 4.1 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4521 Number of APNIC addresses announced to Internet: 769392130 Equivalent to 45 /8s, 219 /16s and 254 /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-139577 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: 218861 Total ARIN prefixes after maximum aggregation: 103735 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 217916 Unique aggregates announced from the ARIN address blocks: 104509 ARIN Region origin ASes present in the Internet Routing Table: 18393 ARIN Prefixes per ASN: 11.85 ARIN Region origin ASes announcing only one prefix: 6841 ARIN Region transit ASes present in the Internet Routing Table: 1867 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2597 Number of ARIN addresses announced to Internet: 1079341472 Equivalent to 64 /8s, 85 /16s and 113 /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-399260 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: 203693 Total RIPE prefixes after maximum aggregation: 97183 RIPE Deaggregation factor: 2.10 Prefixes being announced from the RIPE address blocks: 200075 Unique aggregates announced from the RIPE address blocks: 118662 RIPE Region origin ASes present in the Internet Routing Table: 25857 RIPE Prefixes per ASN: 7.74 RIPE Region origin ASes announcing only one prefix: 11479 RIPE Region transit ASes present in the Internet Routing Table: 3655 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: 7881 Number of RIPE addresses announced to Internet: 717789120 Equivalent to 42 /8s, 200 /16s and 151 /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-210331 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: 95556 Total LACNIC prefixes after maximum aggregation: 22755 LACNIC Deaggregation factor: 4.20 Prefixes being announced from the LACNIC address blocks: 96878 Unique aggregates announced from the LACNIC address blocks: 41670 LACNIC Region origin ASes present in the Internet Routing Table: 8131 LACNIC Prefixes per ASN: 11.91 LACNIC Region origin ASes announcing only one prefix: 2163 LACNIC Region transit ASes present in the Internet Routing Table: 1518 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5691 Number of LACNIC addresses announced to Internet: 171980544 Equivalent to 10 /8s, 64 /16s and 55 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + 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: 20713 Total AfriNIC prefixes after maximum aggregation: 4270 AfriNIC Deaggregation factor: 4.85 Prefixes being announced from the AfriNIC address blocks: 27057 Unique aggregates announced from the AfriNIC address blocks: 9296 AfriNIC Region origin ASes present in the Internet Routing Table: 1252 AfriNIC Prefixes per ASN: 21.61 AfriNIC Region origin ASes announcing only one prefix: 426 AfriNIC Region transit ASes present in the Internet Routing Table: 248 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 525 Number of AfriNIC addresses announced to Internet: 103444224 Equivalent to 6 /8s, 42 /16s and 111 /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 7545 4662 542 544 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4657 4192 74 ERX-CERNET-BKB China Education and Rese 7552 3096 1240 49 VIETEL-AS-AP Viettel Group, VN 45899 3039 1737 111 VNPT-AS-VN VNPT Corp, VN 4766 2814 11125 767 KIXS-AS-KR Korea Telecom, KR 9829 2751 1496 551 BSNL-NIB National Internet Backbone, IN 9808 2431 8699 26 CMNET-GD Guangdong Mobile Communication 9394 2345 4906 29 CTTNET China TieTong Telecommunications 4755 2141 422 179 TATACOMM-AS TATA Communications formerl 9498 2012 426 162 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 6327 3619 1326 93 SHAW - Shaw Communications Inc., CA 11492 3531 228 607 CABLEONE - CABLE ONE, INC., US 22773 3363 2976 164 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2503 5371 1061 AMAZON-02 - Amazon.com, Inc., US 16625 2288 1272 1756 AKAMAI-AS - Akamai Technologies, Inc., 20115 2148 2740 537 CHARTER-20115 - Charter Communications, 18566 2119 405 108 MEGAPATH5-US - MegaPath Corporation, US 30036 2118 351 178 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 5650 2093 3074 1462 FRONTIER-FRTR - Frontier Communications 209 2081 5094 582 CENTURYLINK-US-LEGACY-QWEST - CenturyLi 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 5379 1628 138 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3289 378 44 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2646 547 1920 AKAMAI-ASN1, US 12389 2227 2221 637 ROSTELECOM-AS, RU 34984 2060 340 536 TELLCOM-AS, TR 9121 1682 1693 19 TTNET, TR 13188 1604 100 46 TRIOLAN, UA 9009 1372 146 757 M247, GB 8402 1304 545 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 8151 5600 3331 598 Uninet S.A. de C.V., MX 10620 2769 414 1053 Telmex Colombia S.A., CO 11830 2703 384 34 Instituto Costarricense de Electricidad 6503 1517 433 54 Axtel, S.A.B. de C.V., MX 7303 1432 965 233 Telecom Argentina S.A., AR 28573 1287 2247 181 CLARO S.A., BR 6147 1276 377 29 Telefonica del Peru S.A.A., PE 3816 1022 505 113 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 13999 937 518 246 Mega Cable, S.A. de C.V., MX 11172 932 144 66 Alestra, S. de R.L. de C.V., MX 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 1207 393 21 LINKdotNET-AS, EG 37611 915 107 9 Afrihost, ZA 24835 848 636 22 RAYA-AS, EG 36903 827 416 125 MT-MPLS, MA 36992 817 1535 60 ETISALAT-MISR, EG 8452 701 1731 20 TE-AS TE-AS, EG 29571 485 70 13 ORANGE-COTE-IVOIRE, CI 37492 470 470 57 ORANGE-, TN 15399 428 45 11 WANANCHI-, KE 37342 420 32 1 MOVITEL, MZ 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 5600 3331 598 Uninet S.A. de C.V., MX 12479 5379 1628 138 UNI2-AS, ES 7545 4662 542 544 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4657 4192 74 ERX-CERNET-BKB China Education and Rese 39891 3778 203 20 ALJAWWALSTC-AS, SA 6327 3619 1326 93 SHAW - Shaw Communications Inc., CA 11492 3531 228 607 CABLEONE - CABLE ONE, INC., US 22773 3363 2976 164 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8551 3289 378 44 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 7552 3096 1240 49 VIETEL-AS-AP Viettel Group, VN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5379 5241 UNI2-AS, ES 4538 4657 4583 ERX-CERNET-BKB China Education and Research Net 7545 4662 4118 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3619 3526 SHAW - Shaw Communications Inc., CA 8551 3289 3245 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 3363 3199 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 3096 3047 VIETEL-AS-AP Viettel Group, VN 45899 3039 2928 VNPT-AS-VN VNPT Corp, VN 11492 3531 2924 CABLEONE - CABLE ONE, INC., 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 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65550 DOCUMENT 81.8.34.0/24 15924 BORUSANTELEKOM-AS, TR 65550 DOCUMENT 81.8.35.0/24 15924 BORUSANTELEKOM-AS, TR 1358592 UNALLOCATED 103.134.14.0/23 63956 COLO-AS-AP Colocation Australi 1358592 UNALLOCATED 103.134.15.0/24 63956 COLO-AS-AP Colocation Australi 65549 DOCUMENT 117.239.163.0/24 65544 UNKNOWN 224413 UNALLOCATED 131.221.136.0/24 264413 Conecta Telecom Ltda, BR 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US 64355 UNALLOCATED 156.40.196.0/24 30387 NIH-NET-NCCS - National Instit Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.220.48.0/20 36900 -Reserved AS-, ZZ 43.255.80.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 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:12 /9:10 /10:36 /11:100 /12:291 /13:567 /14:1135 /15:1907 /16:13350 /17:7927 /18:13900 /19:25551 /20:39894 /21:46168 /22:92576 /23:75521 /24:418423 /25:957 /26:840 /27:896 /28:27 /29:7 /30:14 /31:0 /32:197 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4260 5379 UNI2-AS, ES 6327 3391 3619 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2773 3531 CABLEONE - CABLE ONE, INC., US 8551 2744 3289 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2604 3363 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 11830 2048 2703 Instituto Costarricense de Electricidad y Telec 18566 2014 2119 MEGAPATH5-US - MegaPath Corporation, US 30036 1865 2118 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1761 2093 FRONTIER-FRTR - Frontier Communications of Amer Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1607 2:888 4:22 5:2763 6:45 7:1 8:1183 11:3 12:1859 13:313 14:1924 15:39 16:4 17:233 18:59 20:49 23:2596 24:2521 25:2 27:2538 31:2068 32:97 35:36 36:833 37:3013 38:1689 39:295 40:120 41:3175 42:746 43:2002 44:143 45:6902 46:3224 47:251 49:1362 50:1098 51:322 52:1024 54:289 55:2 56:9 57:40 58:1713 59:1074 60:497 61:2069 62:1988 63:1815 64:4994 65:2202 66:4824 67:2706 68:1152 69:3544 70:1329 71:601 72:2425 74:2762 75:515 76:546 77:1711 78:1762 79:2331 80:1768 81:1496 82:1128 83:870 84:1098 85:2241 86:539 87:1551 88:1034 89:2431 90:210 91:6579 92:1261 93:2442 94:2520 95:3208 96:918 97:346 98:947 99:206 100:88 101:1157 102:453 103:20213 104:3528 105:247 106:890 107:1766 108:699 109:3723 110:1632 111:1867 112:1410 113:1418 114:1134 115:1721 116:1712 117:1876 118:2155 119:1624 120:1023 121:1034 122:2294 123:1643 124:1450 125:1965 128:1254 129:822 130:525 131:1633 132:733 133:218 134:1050 135:241 136:559 137:706 138:1995 139:848 140:579 141:844 142:800 143:1070 144:837 145:510 146:1261 147:793 148:1695 149:816 150:777 151:1010 152:1018 153:323 154:2898 155:894 156:1735 157:919 158:666 159:1894 160:1523 161:911 162:2680 163:791 164:1127 165:1577 166:428 167:1391 168:3210 169:861 170:4002 171:565 172:1108 173:2174 174:1015 175:893 176:2328 177:4048 178:2544 179:1368 180:2126 181:2398 182:2679 183:1069 184:1174 185:14837 186:3746 187:2418 188:2890 189:1973 190:8293 191:1394 192:10031 193:6622 194:5392 195:4057 196:2994 197:1648 198:5820 199:5965 200:7127 201:5081 202:10235 203:10202 204:4598 205:3006 206:3237 207:3289 208:3966 209:4237 210:3932 211:1994 212:3069 213:2889 214:1087 215:53 216:5959 217:2233 218:921 219:581 220:1864 221:966 222:999 223:1441 End of report From Anthony.DeLaCruz at CenturyLink.com Fri Mar 8 19:57:47 2019 From: Anthony.DeLaCruz at CenturyLink.com (Delacruz, Anthony B) Date: Fri, 8 Mar 2019 19:57:47 +0000 Subject: Issue with Geolocation in Virginia US In-Reply-To: References: Message-ID: <398B250423578A4E97AFE1B8B67C686C652071C8@PDDCWMBXEX503.ctl.intranet> This sometimes helps https://support.google.com/websearch/contact/ip you should probably also seek out getting geo updated on at least 3 different ones you have 3 different results. 129.46.232.65 ip2location Raleigh NC neustar butler TN maxmind Bridgewater NJ From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Raja Sekhar Gullapalli Sent: Wednesday, February 27, 2019 11:32 PM To: nanog at nanog.org Subject: Issue with Geolocation in Virginia US Team, We are having issues in our Virginia US office & it shows geolocation in all browsers as Canada instead of US region when we access news.google.com in our PC. Our public ip is 129.46.232.65. This issue is being observed for more than 2 month. Can you help to whom we can contact to resolve the issue. Regards, Raja This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From christopher.smalling at neonova.net Fri Mar 8 17:56:50 2019 From: christopher.smalling at neonova.net (Christopher Smalling) Date: Fri, 8 Mar 2019 11:56:50 -0600 Subject: Assistance needed from Global Net Access / Zayo Message-ID: Been having an issue with our public peering at an IX and have been getting the runaround from the NCC. AS 3595 (Global Net Access) has Zayo (AS 19092) as the contact. If anyone on here can assist, can you contact me off-list, please? -- [image: photo] Christopher Smalling NOC Support Technician at NeoNova O: 256-428-8788 • christopher.smalling at neonova.net www.neonova.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From spoofer-info at caida.org Fri Mar 8 18:00:04 2019 From: spoofer-info at caida.org (CAIDA Spoofer Project) Date: Fri, 8 Mar 2019 10:00:04 -0800 Subject: Spoofer Report for NANOG for Feb 2019 Message-ID: <201903081800.x28I04oK014670@fro.caida.org> In response to feedback from operational security communities, CAIDA's source address validation measurement project (https://spoofer.caida.org) is automatically generating monthly reports of ASes originating prefixes in BGP for systems from which we received packets with a spoofed source address. We are publishing these reports to network and security operations lists in order to ensure this information reaches operational contacts in these ASes. This report summarises tests conducted within usa, can. Inferred improvements during Feb 2019: ASN Name Fixed-By 16842 5DL 2019-02-01 7922 COMCAST-7922 2019-02-02 18451 LESNET 2019-02-11 12083 WOW-INTERNET 2019-02-21 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Feb 2019: ASN Name First-Spoofed Last-Spoofed 5650 FRONTIER-FRTR 2016-02-22 2019-02-20 15003 AS-UBIQUITY 2016-03-24 2019-02-01 19230 NANOG 2016-06-13 2019-02-20 7029 WINDSTREAM 2016-06-21 2019-02-15 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2019-02-26 6128 CABLE-NET-1 2016-09-03 2019-02-23 20412 CLARITY-TELECOM 2016-09-30 2019-02-21 6181 FUSE-NET 2016-10-10 2019-02-23 25787 ROWE-NETWORKS 2016-10-21 2019-02-14 174 COGENT-174 2016-10-21 2019-02-25 31857 PRIORITY-TERABIT 2016-10-25 2019-02-09 30341 SCTA-ASN 2016-10-31 2019-02-25 32440 LONI 2016-11-03 2019-02-26 12083 WOW-INTERNET 2016-11-09 2019-02-23 13427 SOFTCOM-INTERNET-COMMUNICATION 2016-11-14 2019-02-26 3549 LVLT-3549 2016-11-16 2019-02-22 7106 INDEPENDENTSFIBERNETWORK 2017-01-09 2019-02-18 21832 KELLINCOM-1 2017-02-03 2019-02-23 18451 LESNET 2017-02-22 2019-02-20 6597 CBDC-6597 2017-04-27 2019-02-08 701 UUNET 2017-06-14 2019-02-04 6461 ZAYO-6461 2017-06-21 2019-02-26 63296 AMARILLO-WIRELESS 2017-09-01 2019-02-27 7233 YAHOO-US 2017-09-07 2019-02-19 14051 SUREWEST 2017-10-26 2019-02-24 33523 ROWANUNIVERSITY 2017-10-29 2019-02-26 546 PARSONS-PGS-1 2017-11-20 2019-02-19 12222 AKAMAI 2018-02-14 2019-02-27 8100 ASN-QUADRANET-GLOBAL 2018-04-06 2019-02-28 4201 ORST 2018-04-19 2019-02-27 393564 SPOKANE 2018-06-05 2019-02-27 225 VIRGINIA 2018-06-18 2019-02-25 54804 CSMIII-BUNKIELA 2018-09-15 2019-02-04 33452 RW 2018-09-19 2019-02-22 20448 VPNTRANET-LLC 2018-09-20 2019-02-26 11996 LOBOIS 2018-09-24 2019-02-22 13825 TROYCABLE-NET 2018-11-21 2019-02-16 63275 RADIOWIRE 2019-02-07 2019-02-07 18534 FIBER-CA 2019-02-08 2019-02-08 10965 MRNET 2019-02-11 2019-02-11 715 WOODYNET-2 2019-02-13 2019-02-13 6360 UNIVHAWAII 2019-02-25 2019-02-25 Further information for these tests where we received spoofed packets is available at: https://spoofer.caida.org/recent_tests.php?country_include=usa,can&no_block=1 Please send any feedback or suggestions to spoofer-info at caida.org From merculiani at gmail.com Fri Mar 8 21:13:40 2019 From: merculiani at gmail.com (Matt Erculiani) Date: Fri, 8 Mar 2019 15:13:40 -0600 Subject: Assistance needed from Global Net Access / Zayo In-Reply-To: References: Message-ID: Replied off-list -Matt On Fri, Mar 8, 2019 at 2:55 PM Christopher Smalling < christopher.smalling at neonova.net> wrote: > Been having an issue with our public peering at an IX and have been > getting the runaround from the NCC. AS 3595 (Global Net Access) has Zayo > (AS 19092) as the contact. > > If anyone on here can assist, can you contact me off-list, please? > > -- > > [image: photo] > Christopher Smalling > NOC Support Technician at NeoNova > O: 256-428-8788 • christopher.smalling at neonova.net > www.neonova.net > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Fri Mar 8 22:22:03 2019 From: sean at donelan.com (Sean Donelan) Date: Fri, 8 Mar 2019 17:22:03 -0500 (EST) Subject: Should Netflix and Hulu give you emergency alerts? Message-ID: https://www.cnn.com/2019/03/08/tech/emergency-alert-netflix-hulu-streaming/index.html New York (CNN Business) The federal emergency alert program was designed decades ago to interrupt your TV show or radio station and warn about impending danger — from severe weather events to acts of war. But people watch TV and listen to radio differently today. If a person is watching Netflix, listening to Spotify or playing a video game, for example, they might miss a critical emergency alert altogether. "More and more people are opting out of the traditional television services," said Gregory Touhill, a cybersecurity expert who served at the Department of Homeland security and was the first-ever Federal Chief Information Security Officer. "There's a huge population out there that needs to help us rethink how we do this." [...] From merculiani at gmail.com Fri Mar 8 22:31:37 2019 From: merculiani at gmail.com (Matt Erculiani) Date: Fri, 8 Mar 2019 16:31:37 -0600 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: Message-ID: Sean I think the cellular emergency alert systems already in place have satisfied this need or should be implemented before forcing streaming services to alter their platforms. Plus they allow the user the ability to disable them if they so choose. If they have the alerts disabled and miss something important, that's on them. The world is evolving and I don't think interrupting streaming is necessary given all the other ways there are to alert a population. -Matt On Fri, Mar 8, 2019, 16:23 Sean Donelan wrote: > > > https://www.cnn.com/2019/03/08/tech/emergency-alert-netflix-hulu-streaming/index.html > > New York (CNN Business) The federal emergency alert program was designed > decades ago to interrupt your TV show or radio station and warn about > impending danger — from severe weather events to acts of war. > > But people watch TV and listen to radio differently today. If a person is > watching Netflix, listening to Spotify or playing a video game, for > example, they might miss a critical emergency alert altogether. > > "More and more people are opting out of the traditional television > services," said Gregory Touhill, a cybersecurity expert who served at the > Department of Homeland security and was the first-ever Federal Chief > Information Security Officer. "There's a huge population out there that > needs to help us rethink how we do this." > > [...] > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattlists at rivervalleyinternet.net Fri Mar 8 22:32:52 2019 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Fri, 8 Mar 2019 17:32:52 -0500 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: Message-ID: No. Please no. We need less regulation. Not more. VoIP started out the same way. Very simple to start offering voip. Worked well. Then the government got involved. Now it’s a mess of requirements, warnings and reporting. > On Mar 8, 2019, at 5:22 PM, Sean Donelan wrote: > > > https://www.cnn.com/2019/03/08/tech/emergency-alert-netflix-hulu-streaming/index.html > > New York (CNN Business) The federal emergency alert program was designed decades ago to interrupt your TV show or radio station and warn about impending danger — from severe weather events to acts of war. > > But people watch TV and listen to radio differently today. If a person is watching Netflix, listening to Spotify or playing a video game, for example, they might miss a critical emergency alert altogether. > > "More and more people are opting out of the traditional television services," said Gregory Touhill, a cybersecurity expert who served at the Department of Homeland security and was the first-ever Federal Chief Information Security Officer. "There's a huge population out there that needs to help us rethink how we do this." > > [...] From mike at mtcc.com Fri Mar 8 22:39:51 2019 From: mike at mtcc.com (Michael Thomas) Date: Fri, 8 Mar 2019 14:39:51 -0800 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: Message-ID: On 3/8/19 2:32 PM, Matt Hoppes wrote: > No. Please no. We need less regulation. Not more. > > VoIP started out the same way. Very simple to start offering voip. Worked well. Then the government got involved. Now it’s a mess of requirements, warnings and reporting. I was there developing service provider voip from the beginning and I can tell you that we were never unaware that we needed to deal with regulatory requirements from the pstn. e911, calia and all the rest. It was never simple. Mike > >> On Mar 8, 2019, at 5:22 PM, Sean Donelan wrote: >> >> >> https://www.cnn.com/2019/03/08/tech/emergency-alert-netflix-hulu-streaming/index.html >> >> New York (CNN Business) The federal emergency alert program was designed decades ago to interrupt your TV show or radio station and warn about impending danger — from severe weather events to acts of war. >> >> But people watch TV and listen to radio differently today. If a person is watching Netflix, listening to Spotify or playing a video game, for example, they might miss a critical emergency alert altogether. >> >> "More and more people are opting out of the traditional television services," said Gregory Touhill, a cybersecurity expert who served at the Department of Homeland security and was the first-ever Federal Chief Information Security Officer. "There's a huge population out there that needs to help us rethink how we do this." >> >> [...] From beecher at beecher.cc Fri Mar 8 22:43:17 2019 From: beecher at beecher.cc (Tom Beecher) Date: Fri, 8 Mar 2019 17:43:17 -0500 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: Message-ID: What specific regulations do you feel were onerous and unnecessary with respect to VOIP? (This is a legitimate question, not a trolling attempt. ) On Fri, Mar 8, 2019 at 5:36 PM Matt Hoppes < mattlists at rivervalleyinternet.net> wrote: > No. Please no. We need less regulation. Not more. > > VoIP started out the same way. Very simple to start offering voip. Worked > well. Then the government got involved. Now it’s a mess of requirements, > warnings and reporting. > > > On Mar 8, 2019, at 5:22 PM, Sean Donelan wrote: > > > > > > > https://www.cnn.com/2019/03/08/tech/emergency-alert-netflix-hulu-streaming/index.html > > > > New York (CNN Business) The federal emergency alert program was designed > decades ago to interrupt your TV show or radio station and warn about > impending danger — from severe weather events to acts of war. > > > > But people watch TV and listen to radio differently today. If a person > is watching Netflix, listening to Spotify or playing a video game, for > example, they might miss a critical emergency alert altogether. > > > > "More and more people are opting out of the traditional television > services," said Gregory Touhill, a cybersecurity expert who served at the > Department of Homeland security and was the first-ever Federal Chief > Information Security Officer. "There's a huge population out there that > needs to help us rethink how we do this." > > > > [...] > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Fri Mar 8 22:47:25 2019 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 8 Mar 2019 16:47:25 -0600 (CST) Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: Message-ID: <552796598.5581.1552085242467.JavaMail.mhammett@ThunderFuck> Streaming is probably the least important thing someone could be doing. A lot of places don't have adequate cell service. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Matt Erculiani" To: "Sean Donelan" Cc: "nanog at nanog.org list" Sent: Friday, March 8, 2019 4:31:37 PM Subject: Re: Should Netflix and Hulu give you emergency alerts? Sean I think the cellular emergency alert systems already in place have satisfied this need or should be implemented before forcing streaming services to alter their platforms. Plus they allow the user the ability to disable them if they so choose. If they have the alerts disabled and miss something important, that's on them. The world is evolving and I don't think interrupting streaming is necessary given all the other ways there are to alert a population. -Matt On Fri, Mar 8, 2019, 16:23 Sean Donelan < sean at donelan.com > wrote: https://www.cnn.com/2019/03/08/tech/emergency-alert-netflix-hulu-streaming/index.html New York (CNN Business) The federal emergency alert program was designed decades ago to interrupt your TV show or radio station and warn about impending danger — from severe weather events to acts of war. But people watch TV and listen to radio differently today. If a person is watching Netflix, listening to Spotify or playing a video game, for example, they might miss a critical emergency alert altogether. "More and more people are opting out of the traditional television services," said Gregory Touhill, a cybersecurity expert who served at the Department of Homeland security and was the first-ever Federal Chief Information Security Officer. "There's a huge population out there that needs to help us rethink how we do this." [...] -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron at heyaaron.com Fri Mar 8 23:08:29 2019 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Fri, 8 Mar 2019 15:08:29 -0800 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: Message-ID: On Fri, Mar 8, 2019 at 2:36 PM Matt Hoppes < mattlists at rivervalleyinternet.net> wrote: > No. Please no. We need less regulation. Not more. > > VoIP started out the same way. Very simple to start offering voip. Worked > well. Then the government got involved. Now it’s a mess of requirements, > warnings and reporting. Come on now...what we really need to get everyone attention is air raid sirens coupled with streaming interruptions via a simultaneous reboot of all 'core routers' on the internet so people stop surfing facebook and start wondering "what's up", followed by the public utilities cycling the nations power grid to the morse code 'SOS'. Oh, and this all occurs during the monthly test too. -A -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at essenz.com Fri Mar 8 23:25:52 2019 From: john at essenz.com (John Von Essen) Date: Fri, 8 Mar 2019 18:25:52 -0500 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: Message-ID: <2FC5B9AA-4060-4202-ADF4-E1844475D59F@essenz.com> I don’t care if Aliens are invading or a blackhole is swallowing our sun, do not... I repeat, do not interrupt me watching GoT’s on HBOGo! -John > On Mar 8, 2019, at 6:08 PM, Aaron C. de Bruyn via NANOG wrote: > >> On Fri, Mar 8, 2019 at 2:36 PM Matt Hoppes wrote: >> No. Please no. We need less regulation. Not more. >> >> VoIP started out the same way. Very simple to start offering voip. Worked well. Then the government got involved. Now it’s a mess of requirements, warnings and reporting. > > Come on now...what we really need to get everyone attention is air raid sirens coupled with streaming interruptions via a simultaneous reboot of all 'core routers' on the internet so people stop surfing facebook and start wondering "what's up", followed by the public utilities cycling the nations power grid to the morse code 'SOS'. Oh, and this all occurs during the monthly test too. > > -A -------------- next part -------------- An HTML attachment was scrubbed... URL: From clayton at MNSi.Net Fri Mar 8 23:45:48 2019 From: clayton at MNSi.Net (Clayton Zekelman) Date: Fri, 08 Mar 2019 18:45:48 -0500 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: Message-ID: <1552088751_200466@surgemail.mnsi.net> Just wait until your connected home speakers, smart smoke detector, smart refrigerator, smart tv, cell phone, IP streaming box, satellite receiver, cable box, home security panel and your Fitbit all go off warning you of the cancellation of an Amber alert at 1:30am, because the good folks at AlertReady.Ca and Pelmorex think that everything needs to go out at highest precedence, because, well, think of the children! At 05:22 PM 08/03/2019, Sean Donelan wrote: >https://www.cnn.com/2019/03/08/tech/emergency-alert-netflix-hulu-streaming/index.html > >New York (CNN Business) The federal emergency >alert program was designed decades ago to >interrupt your TV show or radio station and warn >about impending danger — from severe weather events to acts of war. >But people watch TV and listen to radio >differently today. If a person is watching >Netflix, listening to Spotify or playing a video >game, for example, they might miss a critical emergency alert altogether. > >"More and more people are opting out of the >traditional television services," said Gregory >Touhill, a cybersecurity expert who served at >the Department of Homeland security and was the >first-ever Federal Chief Information Security >Officer. "There's a huge population out there >that needs to help us rethink how we do this." > >[...] -- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Sat Mar 9 00:43:51 2019 From: sean at donelan.com (Sean Donelan) Date: Fri, 8 Mar 2019 19:43:51 -0500 (EST) Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: <1552088751_200466@surgemail.mnsi.net> References: <1552088751_200466@surgemail.mnsi.net> Message-ID: Canada made a lot of improvements with its alert implementation. It got to see all the things the U.S. did wrong. Unfortuantely, Canada also copied some wrong lessons from the the U.S. version. South Korea probably has the most ludicrous emergency alerts in the world. While improvements are needed, the various alert systems have saved people's lives. On Fri, 8 Mar 2019, Clayton Zekelman wrote: > Just wait until your connected home speakers, smart smoke detector, smart > refrigerator, smart tv, cell phone, IP streaming box, satellite receiver, > cable box, home security panel and your Fitbit all go off warning you of the > cancellation of an Amber alert at 1:30am, because the good folks at > AlertReady.Ca and Pelmorex think that everything needs to go out at highest > precedence, because, well, think of the children! From jhellenthal at dataix.net Sat Mar 9 00:46:53 2019 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Fri, 8 Mar 2019 18:46:53 -0600 Subject: GPS week number rollover event on April 6th In-Reply-To: References: Message-ID: <5BB672C9-7780-4065-A682-CF26F20E7365@dataix.net> Thanks! -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Mar 7, 2019, at 17:02, Gerry Boudreaux wrote: > > For those who have GPS based NTP servers. > > https://ics-cert.us-cert.gov/sites/default/files/documents/Memorandum_on_GPS_2019.pdf > > G > From clayton at MNSi.Net Sat Mar 9 00:51:42 2019 From: clayton at MNSi.Net (Clayton Zekelman) Date: Fri, 08 Mar 2019 19:51:42 -0500 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: <1552088751_200466@surgemail.mnsi.net> Message-ID: <1552092707_200759@surgemail.mnsi.net> Absolutely, we need public emergency alerting. What we don't need is every alert to go out mandatory highest level sound the klaxon, can't be blocked, even when it's an "all clear" cancelling a previous alert, and is being sent in the middle of the night. That's the system that has been foisted upon us here. I'm all for emergency alerting, but please make sure it's a real emergency. At least in the US version, they target the region affected, and code it with the appropriate alert level instead of sending alerts to people 1400 km away. https://www.thestar.com/news/gta/2018/05/14/first-emergency-alert-sets-off-phones-ontario-wide-following-thunder-bay-amber-alert.html At 07:43 PM 08/03/2019, Sean Donelan wrote: >Canada made a lot of improvements with its alert implementation. It >got to see all the things the U.S. did wrong. Unfortuantely, Canada >also copied some wrong lessons from the the U.S. version. > >South Korea probably has the most ludicrous emergency alerts in the world. > >While improvements are needed, the various alert systems have saved >people's lives. > >On Fri, 8 Mar 2019, Clayton Zekelman wrote: >>Just wait until your connected home speakers, smart smoke detector, smart >>refrigerator, smart tv, cell phone, IP streaming box, satellite receiver, >>cable box, home security panel and your Fitbit all go off warning you of the >>cancellation of an Amber alert at 1:30am, because the good folks at >>AlertReady.Ca and Pelmorex think that everything needs to go out at highest >>precedence, because, well, think of the children! -- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From jerry at jtcloe.net Sat Mar 9 01:29:36 2019 From: jerry at jtcloe.net (=?utf-8?Q?Jerry_Cloe?=) Date: Fri, 8 Mar 2019 19:29:36 -0600 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: Message-ID: NO!! But, I would not be opposed to some type of app on the boxes that support it, one that can be dismissed or controlled by the user.   -----Original message----- From:Sean Donelan Sent:Fri 03-08-2019 04:22 pm Subject:Should Netflix and Hulu give you emergency alerts? To:nanog at nanog.org; https://www.cnn.com/2019/03/08/tech/emergency-alert-netflix-hulu-streaming/index.html New York (CNN Business) The federal emergency alert program was designed decades ago to interrupt your TV show or radio station and warn about impending danger — from severe weather events to acts of war. But people watch TV and listen to radio differently today. If a person is watching Netflix, listening to Spotify or playing a video game, for example, they might miss a critical emergency alert altogether. "More and more people are opting out of the traditional television services," said Gregory Touhill, a cybersecurity expert who served at the Department of Homeland security and was the first-ever Federal Chief Information Security Officer. "There's a huge population out there that needs to help us rethink how we do this." [...] -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Sat Mar 9 01:44:17 2019 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 8 Mar 2019 20:44:17 -0500 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: <1552092707_200759@surgemail.mnsi.net> References: <1552088751_200466@surgemail.mnsi.net> <1552092707_200759@surgemail.mnsi.net> Message-ID: I’ve had issues with the amber alerts repeating or coming in from adjacent states because “reasons”. When they repeat for days/hours ugh. I do agree most people have devices. If there is a reasonable API method to fetch them then great. Sent from my iCar > On Mar 8, 2019, at 7:51 PM, Clayton Zekelman wrote: > > > Absolutely, we need public emergency alerting. What we don't need is every alert to go out mandatory highest level sound the klaxon, can't be blocked, even when it's an "all clear" cancelling a previous alert, and is being sent in the middle of the night. > > That's the system that has been foisted upon us here. I'm all for emergency alerting, but please make sure it's a real emergency. > > At least in the US version, they target the region affected, and code it with the appropriate alert level instead of sending alerts to people 1400 km away. > > https://www.thestar.com/news/gta/2018/05/14/first-emergency-alert-sets-off-phones-ontario-wide-following-thunder-bay-amber-alert.html > > > > At 07:43 PM 08/03/2019, Sean Donelan wrote: >> Canada made a lot of improvements with its alert implementation. It got to see all the things the U.S. did wrong. Unfortuantely, Canada also copied some wrong lessons from the the U.S. version. >> >> South Korea probably has the most ludicrous emergency alerts in the world. >> >> While improvements are needed, the various alert systems have saved people's lives. >> >>> On Fri, 8 Mar 2019, Clayton Zekelman wrote: >>> Just wait until your connected home speakers, smart smoke detector, smart >>> refrigerator, smart tv, cell phone, IP streaming box, satellite receiver, >>> cable box, home security panel and your Fitbit all go off warning you of the >>> cancellation of an Amber alert at 1:30am, because the good folks at >>> AlertReady.Ca and Pelmorex think that everything needs to go out at highest >>> precedence, because, well, think of the children! > > -- > > Clayton Zekelman > Managed Network Systems Inc. (MNSi) > 3363 Tecumseh Rd. E > Windsor, Ontario > N8W 1H4 > > tel. 519-985-8410 > fax. 519-985-8409 From sean at donelan.com Sat Mar 9 02:43:16 2019 From: sean at donelan.com (Sean Donelan) Date: Fri, 8 Mar 2019 21:43:16 -0500 (EST) Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: <1552088751_200466@surgemail.mnsi.net> <1552092707_200759@surgemail.mnsi.net> Message-ID: Software has bugs. If this happens to you (or anyone else), a hard power reset of your mobile phone will clear up the problem. I have not figured out what causes the repeating duplicate alerts. I've asked FEMA and some engineers at a cellular carrier. It seems to be a "known problem." But I haven't been able to get a technical explanation for the cause. The duplication happens randomly on both android and iOS phones, and on multiple carriers. So I'm a bit mystified about the root cause. On Fri, 8 Mar 2019, Jared Mauch wrote: > I’ve had issues with the amber alerts repeating or coming in from >adjacent states because “reasons”. When they repeat for days/hours ugh. > > I do agree most people have devices. If there is a reasonable API >method to fetch them then great. From mike at mtcc.com Sat Mar 9 02:48:54 2019 From: mike at mtcc.com (Michael Thomas) Date: Fri, 8 Mar 2019 18:48:54 -0800 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: Message-ID: <1bef70e4-8c79-2f53-2320-b74faf8c7ace@mtcc.com> On 3/8/19 2:22 PM, Sean Donelan wrote: > > https://www.cnn.com/2019/03/08/tech/emergency-alert-netflix-hulu-streaming/index.html > > > New York (CNN Business) The federal emergency alert program was > designed decades ago to interrupt your TV show or radio station and > warn about impending danger — from severe weather events to acts of war. > > But people watch TV and listen to radio differently today. If a person > is watching Netflix, listening to Spotify or playing a video game, for > example, they might miss a critical emergency alert altogether. > > "More and more people are opting out of the traditional television > services," said Gregory Touhill, a cybersecurity expert who served at > the Department of Homeland security and was the first-ever Federal > Chief Information Security Officer. "There's a huge population out > there that needs to help us rethink how we do this." > > [...] Has the IETF, etc looked into this? This looks like a good thing that could use a good dose of standardization to avoid a complete clusterf*ck. Mike From cma at cmadams.net Sat Mar 9 03:53:00 2019 From: cma at cmadams.net (Chris Adams) Date: Fri, 8 Mar 2019 21:53:00 -0600 Subject: GPS week number rollover event on April 6th In-Reply-To: References: Message-ID: <20190309035300.GB2140@cmadams.net> Once upon a time, Gerry Boudreaux said: > For those who have GPS based NTP servers. > > https://ics-cert.us-cert.gov/sites/default/files/documents/Memorandum_on_GPS_2019.pdf Note that the standard ntpd daemon has different code for different time sources related to the GPS week roll-over. For example, the Trimble TSIP driver has a hard-coded offset and has already rolled (but didn't do it right on at least some devices). -- Chris Adams From alter3d at alter3d.ca Sat Mar 9 04:32:18 2019 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Fri, 8 Mar 2019 23:32:18 -0500 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: <1552092707_200759@surgemail.mnsi.net> References: <1552088751_200466@surgemail.mnsi.net> <1552092707_200759@surgemail.mnsi.net> Message-ID: <76073cd6-51e7-a6b2-adc4-18b00eacc7b7@alter3d.ca> It can be blocked, FYI.  Just... not as easily as it should be. On Android, if you remove the CellBroadcastReceiver service, the phone no longer listens for the alerts. I rooted my phone specifically to be able to do this after the alerting system rolled out in Canada.  The test was bad enough, then within the first week we had several alerts for a single event that happened literally an entire day's drive away from me. And thus, in the first week the system was alive, alarm fatigue set in, the government confirmed that it cannot be trusted, and I revoked their privilege to use my personal devices for stuff I don't want. On 2019-03-08 7:51 p.m., Clayton Zekelman wrote: > > Absolutely, we need public emergency alerting.  What we don't need is > every alert to go out mandatory highest level sound the klaxon, can't > be blocked, even when it's an "all clear" cancelling a previous alert, > and is being sent in the middle of the night. > > That's the system that has been foisted upon us here.   I'm all for > emergency alerting, but please make sure it's a real emergency. > > At least in the US version, they target the region affected, and code > it with the appropriate alert level instead of sending alerts to > people 1400 km away. > > https://www.thestar.com/news/gta/2018/05/14/first-emergency-alert-sets-off-phones-ontario-wide-following-thunder-bay-amber-alert.html > > > > > At 07:43 PM 08/03/2019, Sean Donelan wrote: >> Canada made a lot of improvements with its alert implementation.  It >> got to see all the things the U.S. did wrong. Unfortuantely, Canada >> also copied some wrong lessons from the the U.S. version. >> >> South Korea probably has the most ludicrous emergency alerts in the >> world. >> >> While improvements are needed, the various alert systems have saved >> people's lives. >> >> On Fri, 8 Mar 2019, Clayton Zekelman wrote: >>> Just wait until your connected home speakers, smart smoke detector, >>> smart >>> refrigerator, smart tv, cell phone, IP streaming box, satellite >>> receiver, >>> cable box, home security panel and your Fitbit all go off warning >>> you of the >>> cancellation of an Amber alert at 1:30am, because the good folks at >>> AlertReady.Ca and Pelmorex think that everything needs to go out at >>> highest >>> precedence, because, well, think of the children! > From mark.tinka at seacom.mu Sat Mar 9 04:47:51 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 9 Mar 2019 06:47:51 +0200 Subject: Arista Layer3 In-Reply-To: <5a129cb2-2da9-d623-6a21-9202b97a059c@monmotha.net> References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> <20171130191750.GB32439@sizone.org> <20171130210022.GF32439@sizone.org> <0c4a81cd-ad54-b5c8-abb0-adaf10949090@bogus.com> <27F7E3C6-62D4-4E58-AE68-649A7C775104@dino.hostasaurus.com> <5C7EDC53.2030608@jack.fr.eu.org> <5a129cb2-2da9-d623-6a21-9202b97a059c@monmotha.net> Message-ID: On 8/Mar/19 13:18, Brandon Martin wrote: >   > > I haven't used Arista much at all really. We are currently swapping out our Juniper EX4550's and EX4600's for Arista's 7280SR switches, but this is purely for Layer 2 Ethernet customer aggregation in the data centre. The main issue we are having is getting support for L2PT in the Arista on par with what Juniper and Cisco can do today. So far, some of the critical protocols are trickling into test code, but there is still a little bit of way to go before we get everything we need. At any rate, it seems there are no hardware limitations in getting those protocols implemented, and Arista just need to get more people on to the code to write it all up. So that's a positive, although it is delaying our migration. In the core, been using the 7508E for 100Gbps Layer 2 Ethernet aggregation for over a year now. Apart from some fabric modules that failed in 2 switches at the same time (nothing really major as that is part of network operations), they've been solid. Mark. From rajag at qti.qualcomm.com Sat Mar 9 07:01:03 2019 From: rajag at qti.qualcomm.com (Raja Sekhar Gullapalli) Date: Sat, 9 Mar 2019 07:01:03 +0000 Subject: Issue with Geolocation in Virginia US In-Reply-To: <398B250423578A4E97AFE1B8B67C686C652071C8@PDDCWMBXEX503.ctl.intranet> References: <398B250423578A4E97AFE1B8B67C686C652071C8@PDDCWMBXEX503.ctl.intranet> Message-ID: <36db5cd2c5914eae8b889cd4818b5d87@APHYDEXM01E.ap.qualcomm.com> Hi Anthony, First one already tried & but no response. Who will help in getting geo updated which shows 3 results as per your email. Regards, Raja go/snitnet or go/itnet to request Network Services. From: Delacruz, Anthony B Sent: Saturday, March 9, 2019 1:28 AM To: Raja Sekhar Gullapalli ; nanog at nanog.org Subject: [EXT] RE: Issue with Geolocation in Virginia US This sometimes helps https://support.google.com/websearch/contact/ip you should probably also seek out getting geo updated on at least 3 different ones you have 3 different results. 129.46.232.65 ip2location Raleigh NC neustar butler TN maxmind Bridgewater NJ From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Raja Sekhar Gullapalli Sent: Wednesday, February 27, 2019 11:32 PM To: nanog at nanog.org Subject: Issue with Geolocation in Virginia US Team, We are having issues in our Virginia US office & it shows geolocation in all browsers as Canada instead of US region when we access news.google.com in our PC. Our public ip is 129.46.232.65. This issue is being observed for more than 2 month. Can you help to whom we can contact to resolve the issue. Regards, Raja This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aveline at misaka.io Sat Mar 9 07:11:33 2019 From: aveline at misaka.io (Siyuan Miao) Date: Sat, 9 Mar 2019 15:11:33 +0800 Subject: Issue with Geolocation in Virginia US In-Reply-To: <36db5cd2c5914eae8b889cd4818b5d87@APHYDEXM01E.ap.qualcomm.com> References: <398B250423578A4E97AFE1B8B67C686C652071C8@PDDCWMBXEX503.ctl.intranet> <36db5cd2c5914eae8b889cd4818b5d87@APHYDEXM01E.ap.qualcomm.com> Message-ID: Hi Raja, If you have peering with them (AS15169), you can submit Geolocation data via ISP Portal (https://isp.google.com/). Regards, Siyuan On Sat, Mar 9, 2019 at 3:03 PM Raja Sekhar Gullapalli < rajag at qti.qualcomm.com> wrote: > Hi Anthony, > > > > First one already tried & but no response. > > > > Who will help in getting geo updated which shows 3 results as per your > email. > > > > Regards, > > Raja > > > > go/snitnet or go/itnet to request Network Services. > > > > *From:* Delacruz, Anthony B > *Sent:* Saturday, March 9, 2019 1:28 AM > *To:* Raja Sekhar Gullapalli ; nanog at nanog.org > *Subject:* [EXT] RE: Issue with Geolocation in Virginia US > > > > This sometimes helps > > > > https://support.google.com/websearch/contact/ip > > > > you should probably also seek out getting geo updated on at least 3 > different ones you have 3 different results. > > > > 129.46.232.65 > > ip2location Raleigh NC > > neustar butler TN > > maxmind Bridgewater NJ > > > > *From:* NANOG [mailto:nanog-bounces at nanog.org ] *On > Behalf Of *Raja Sekhar Gullapalli > *Sent:* Wednesday, February 27, 2019 11:32 PM > *To:* nanog at nanog.org > *Subject:* Issue with Geolocation in Virginia US > > > > Team, > > > > We are having issues in our Virginia US office & it shows geolocation in > all browsers as Canada instead of US region when we access news.google.com > in our PC. > > > > Our public ip is 129.46.232.65. This issue is being observed for more than > 2 month. > > > > Can you help to whom we can contact to resolve the issue. > > > > > > Regards, > > Raja > > > > > > This communication is the property of CenturyLink and may contain > confidential or privileged information. Unauthorized use of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please immediately notify the sender > by reply e-mail and destroy all copies of the communication and any > attachments. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lguillory at reservetele.com Sat Mar 9 07:47:44 2019 From: lguillory at reservetele.com (Luke Guillory) Date: Sat, 9 Mar 2019 07:47:44 +0000 Subject: Issue with Geolocation in Virginia US In-Reply-To: <36db5cd2c5914eae8b889cd4818b5d87@APHYDEXM01E.ap.qualcomm.com> References: <398B250423578A4E97AFE1B8B67C686C652071C8@PDDCWMBXEX503.ctl.intranet>, <36db5cd2c5914eae8b889cd4818b5d87@APHYDEXM01E.ap.qualcomm.com> Message-ID: <5EA0DC15-0104-4740-A3D6-600BC85E347E@reservetele.com> Maxmind https://support.maxmind.com/geoip-data-correction-request/ Luke Ns Sent from my iPad On Mar 9, 2019, at 1:02 AM, Raja Sekhar Gullapalli > wrote: Hi Anthony, First one already tried & but no response. Who will help in getting geo updated which shows 3 results as per your email. Regards, Raja go/snitnet or go/itnet to request Network Services. From: Delacruz, Anthony B > Sent: Saturday, March 9, 2019 1:28 AM To: Raja Sekhar Gullapalli >; nanog at nanog.org Subject: [EXT] RE: Issue with Geolocation in Virginia US This sometimes helps https://support.google.com/websearch/contact/ip you should probably also seek out getting geo updated on at least 3 different ones you have 3 different results. 129.46.232.65 ip2location Raleigh NC neustar butler TN maxmind Bridgewater NJ From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Raja Sekhar Gullapalli Sent: Wednesday, February 27, 2019 11:32 PM To: nanog at nanog.org Subject: Issue with Geolocation in Virginia US Team, We are having issues in our Virginia US office & it shows geolocation in all browsers as Canada instead of US region when we access news.google.com in our PC. Our public ip is 129.46.232.65. This issue is being observed for more than 2 month. Can you help to whom we can contact to resolve the issue. Regards, Raja This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lguillory at reservetele.com Sat Mar 9 07:49:38 2019 From: lguillory at reservetele.com (Luke Guillory) Date: Sat, 9 Mar 2019 07:49:38 +0000 Subject: Issue with Geolocation in Virginia US In-Reply-To: <36db5cd2c5914eae8b889cd4818b5d87@APHYDEXM01E.ap.qualcomm.com> References: <398B250423578A4E97AFE1B8B67C686C652071C8@PDDCWMBXEX503.ctl.intranet>, <36db5cd2c5914eae8b889cd4818b5d87@APHYDEXM01E.ap.qualcomm.com> Message-ID: Neustar reporting, found after I sent the last email. Sorry https://www.security.neustar/resources/tools/submit-to-global-ip-database Luke Ns Sent from my iPad On Mar 9, 2019, at 1:02 AM, Raja Sekhar Gullapalli > wrote: Hi Anthony, First one already tried & but no response. Who will help in getting geo updated which shows 3 results as per your email. Regards, Raja go/snitnet or go/itnet to request Network Services. From: Delacruz, Anthony B > Sent: Saturday, March 9, 2019 1:28 AM To: Raja Sekhar Gullapalli >; nanog at nanog.org Subject: [EXT] RE: Issue with Geolocation in Virginia US This sometimes helps https://support.google.com/websearch/contact/ip you should probably also seek out getting geo updated on at least 3 different ones you have 3 different results. 129.46.232.65 ip2location Raleigh NC neustar butler TN maxmind Bridgewater NJ From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Raja Sekhar Gullapalli Sent: Wednesday, February 27, 2019 11:32 PM To: nanog at nanog.org Subject: Issue with Geolocation in Virginia US Team, We are having issues in our Virginia US office & it shows geolocation in all browsers as Canada instead of US region when we access news.google.com in our PC. Our public ip is 129.46.232.65. This issue is being observed for more than 2 month. Can you help to whom we can contact to resolve the issue. Regards, Raja This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Sat Mar 9 14:30:24 2019 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 9 Mar 2019 08:30:24 -0600 (CST) Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: <76073cd6-51e7-a6b2-adc4-18b00eacc7b7@alter3d.ca> References: <1552088751_200466@surgemail.mnsi.net> <1552092707_200759@surgemail.mnsi.net> <76073cd6-51e7-a6b2-adc4-18b00eacc7b7@alter3d.ca> Message-ID: <686515571.5874.1552141819244.JavaMail.mhammett@ThunderFuck> Seems a bit extreme... ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Peter Kristolaitis" To: nanog at nanog.org Sent: Friday, March 8, 2019 10:32:18 PM Subject: Re: Should Netflix and Hulu give you emergency alerts? It can be blocked, FYI. Just... not as easily as it should be. On Android, if you remove the CellBroadcastReceiver service, the phone no longer listens for the alerts. I rooted my phone specifically to be able to do this after the alerting system rolled out in Canada. The test was bad enough, then within the first week we had several alerts for a single event that happened literally an entire day's drive away from me. And thus, in the first week the system was alive, alarm fatigue set in, the government confirmed that it cannot be trusted, and I revoked their privilege to use my personal devices for stuff I don't want. On 2019-03-08 7:51 p.m., Clayton Zekelman wrote: > > Absolutely, we need public emergency alerting. What we don't need is > every alert to go out mandatory highest level sound the klaxon, can't > be blocked, even when it's an "all clear" cancelling a previous alert, > and is being sent in the middle of the night. > > That's the system that has been foisted upon us here. I'm all for > emergency alerting, but please make sure it's a real emergency. > > At least in the US version, they target the region affected, and code > it with the appropriate alert level instead of sending alerts to > people 1400 km away. > > https://www.thestar.com/news/gta/2018/05/14/first-emergency-alert-sets-off-phones-ontario-wide-following-thunder-bay-amber-alert.html > > > > > At 07:43 PM 08/03/2019, Sean Donelan wrote: >> Canada made a lot of improvements with its alert implementation. It >> got to see all the things the U.S. did wrong. Unfortuantely, Canada >> also copied some wrong lessons from the the U.S. version. >> >> South Korea probably has the most ludicrous emergency alerts in the >> world. >> >> While improvements are needed, the various alert systems have saved >> people's lives. >> >> On Fri, 8 Mar 2019, Clayton Zekelman wrote: >>> Just wait until your connected home speakers, smart smoke detector, >>> smart >>> refrigerator, smart tv, cell phone, IP streaming box, satellite >>> receiver, >>> cable box, home security panel and your Fitbit all go off warning >>> you of the >>> cancellation of an Amber alert at 1:30am, because the good folks at >>> AlertReady.Ca and Pelmorex think that everything needs to go out at >>> highest >>> precedence, because, well, think of the children! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From william.allen.simpson at gmail.com Sat Mar 9 14:51:00 2019 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Sat, 9 Mar 2019 09:51:00 -0500 Subject: SLAAC in renumbering events In-Reply-To: <41ee9908-03e9-0e4b-a651-8ad1e2f52d74@si6networks.com> References: <41ee9908-03e9-0e4b-a651-8ad1e2f52d74@si6networks.com> Message-ID: On 3/8/19 6:32 AM, Fernando Gont wrote: > Folks, > > If you follow the 6man working group of the IETF you may have seen a > bunch of emails on this topic, on a thread resulting from an IETF > Internet-Draft we published with Jan Žorž about "Reaction of Stateless > Address Autoconfiguration (SLAAC) to Renumbering Events" (Available at: > https://github.com/fgont/draft-slaac-renum/raw/master/draft-gont-6man-slaac-renum-02.txt > ) [...] > > We are looking forward to more input on the document (or any comments on > the issue being discussed), particularly from operators. > > So feel free to send your comments on/off list as you prefer > > Thanks for bringing this to the attention of operators. Too few IETF documents have operational considerations. From colton.conor at gmail.com Sat Mar 9 16:08:00 2019 From: colton.conor at gmail.com (Colton Conor) Date: Sat, 9 Mar 2019 10:08:00 -0600 Subject: Free Open Source Network Operating Systems Message-ID: What free, opensouce, network operating systems currently exist that run on whitebox broadcom or other merchant silicon switches? I know Cumulus is very popular, but I don't believe they have a free version that runs on whitebox switches right? Only on a virtual machine from what I can tell. I think if one of these vendors would release a free and truly opensource network operating system, with the option for paid support if needed, then whitebox switching would really take off. This would be similar to the Redhat model, but for the networking world. Right now, the cost of the whitebox plus a paid network operating system seems to equal the same cost as a discounted Juniper, Cisco, or Arista. I am not seeing the savings on paper. If we could just buy the whitebox hardware, and have a free operating system on there, then financially whitebox switches would be half the cost of a similar Cisco switch after discount. Am I missing something? -------------- next part -------------- An HTML attachment was scrubbed... URL: From clayton at MNSi.Net Sat Mar 9 16:19:51 2019 From: clayton at MNSi.Net (Clayton Zekelman) Date: Sat, 09 Mar 2019 11:19:51 -0500 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: <76073cd6-51e7-a6b2-adc4-18b00eacc7b7@alter3d.ca> References: <1552088751_200466@surgemail.mnsi.net> <1552092707_200759@surgemail.mnsi.net> <76073cd6-51e7-a6b2-adc4-18b00eacc7b7@alter3d.ca> Message-ID: <1552148394_204042@surgemail.mnsi.net> I think the point is they should have built a system that doesn't need to be blocked - it should always effectively and appropriately deliver timely and relevant alert messages. As taxpayers and citizens, we deserve better. At 11:32 PM 08/03/2019, Peter Kristolaitis wrote: >It can be blocked, FYI. Just... not as easily >as it should be. On Android, if you remove the >CellBroadcastReceiver service, the phone no longer listens for the alerts. > >I rooted my phone specifically to be able to do >this after the alerting system rolled out in >Canada. The test was bad enough, then within >the first week we had several alerts for a >single event that happened literally an entire day's drive away from me. > >And thus, in the first week the system was >alive, alarm fatigue set in, the government >confirmed that it cannot be trusted, and I >revoked their privilege to use my personal devices for stuff I don't want. > > >-- > >Clayton Zekelman >Managed Network Systems Inc. (MNSi) >3363 Tecumseh Rd. E >Windsor, Ontario >N8W 1H4 > >tel. 519-985-8410 >fax. 519-985-8409 From jason+nanog at lixfeld.ca Sat Mar 9 16:36:29 2019 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Sat, 9 Mar 2019 11:36:29 -0500 Subject: Free Open Source Network Operating Systems In-Reply-To: References: Message-ID: <76EFB9A6-E234-4C17-B5D6-08ECD7CB37D9@lixfeld.ca> I could be making this up, but my understanding is that the Broadcom SDK is not free, and without the SDK, hardware interaction is limited. At one time ONL was a free ONIE NOS but sans SDK. https://github.com/opencomputeproject/OpenNetworkLinux ? Sent from my iPhone On Mar 9, 2019, at 11:08 AM, Colton Conor > wrote: > What free, opensouce, network operating systems currently exist that run on whitebox broadcom or other merchant silicon switches? > > I know Cumulus is very popular, but I don't believe they have a free version that runs on whitebox switches right? Only on a virtual machine from what I can tell. > > I think if one of these vendors would release a free and truly opensource network operating system, with the option for paid support if needed, then whitebox switching would really take off. This would be similar to the Redhat model, but for the networking world. > > Right now, the cost of the whitebox plus a paid network operating system seems to equal the same cost as a discounted Juniper, Cisco, or Arista. I am not seeing the savings on paper. > > If we could just buy the whitebox hardware, and have a free operating system on there, then financially whitebox switches would be half the cost of a similar Cisco switch after discount. > > Am I missing something? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Sat Mar 9 19:04:33 2019 From: sean at donelan.com (Sean Donelan) Date: Sat, 9 Mar 2019 14:04:33 -0500 (EST) Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: Message-ID: On Fri, 8 Mar 2019, Matt Erculiani wrote: > The world is evolving and I don't think interrupting streaming is necessary > given all the other ways there are to alert a population. The headline: TLDR; Technology changes, so should emergency alerts. Think ahead to 2029. The long story: Technology changes over the decades. Emergency alerts have changed over the decades. If you think all the other ways are sufficient, remember how long it took to create all those other ways. And how much industry fought all those other ways at every step. The U.S. timeline (other countries have state-owned broadcasters, and different timelines): 1950s - AM radio and civil defense sirens 1960s - FM radio and TV broadcasts were included in EBS 1970s - Weather alerts and NOAA weather radio 1990s - Cable TV (not satellite) was included in EAS. 2000s - Satellite TV was added to national EAS alerts, i.e. there has never been a national EAS alert. But Satellite TV do not get state or local weather alerts on most channels. 2012 - Mobile phones were included with WEA expansion If streaming is how the public gets their information and entertainment now, that should also be how they can get emergency alerts. Almost no one under the age of 30 has a working AM radio in their homes or apartments anymore. Few people listen to FM radio outside of their cars, and "cord-cutting" means fewer people get local and weather alerts watching entertainment programs on cable TV. Cities have been eliminating outdoor warning sirens due to budget cuts since the 1990s (i.e. end of the Cold War, and no more FEMA funds for sirens). Wireless Emergency Alerts (WEA), i.e., mobile phone alerts, are less than 10 years old. And mostly on the high-end expensive cell phones and the most expensive carriers. People on NANOG may use mostly expensive smartphones, but not everyone can afford smartphones. Only about 100 carriers, including AT&T, Sprint, T-Mobile and Verizon, carrier have WEA working. In some U.S. territories and rural areas, no cellular providers have WEA working. The largest cellular carrier in Alaska only activated WEA in the last 6 months. Puerto Rico's largest cellular carrier activated WEA just last month. The mobile cell phone industry fought Wireless Emergency Alerts for over a decade, from the 1990s until 2012 when it was implemented. Of course, now the wireless industry claims it was all their idea. Both are true. The cellular industry engineers made it happen, at the same time the cellular industry lobbyists were fighting it. If emergency alerts didn't change with the technology, it would still be only AM radios. It usually takes at least a decade after technology changes to make changes to the emergency alert parts of those systems. It took more than 10 years after the 9/11/2001 attacks and Hurricane Katrina, which were the motivating factors for government, to get WEA working. If you think WEA is sufficient, just remember how long it takes to change. In 2029, what communication technology will be the dominant way people get entertainment and information? As I've said before, I think emergency alerts should be part of the platform, not the add on service. Netflix and Hulu are the wrong layer for emergency alerts. Emergency alerts should be part of the Smart TV and Smart Speaker operating system platforms, i.e., at the Amazon Alexa, Google Assistant, Apple Siri, etc. level. If you are streaming Netflix or Hulu on your mobile cell phone, the cell phone OS should be responsible for handling local emergency alerts. If you are streaming Netflix or Hulu on your Smart TV, the Smart TV OS should be responsible for handling local emergency alerts. If you are streaming Netflix or Hulu on your Smart Speakers (ok, you can't but lets say streaming an Audible book), your Smart Speaker OS should be responsible for local emergency alerts. Your alerting opt-outs, geo-targeting, and other preferences shouldn't need to change depending on which App you are using on the platform. NOAA Weather Wire and FEMA IPAWS emergency alerts, which are the alert aggregation points for most U.S. alerting systems, include geographic alert polygons within 0.1 mile. Emergency alerts can be very localized. Although training for local government officials is skimped, underfunded, ignored, etc.; so many still send alerts for entire jurisdictions, such as statewide in the U.S. or province-wide in Canada instead of geo-targeting specific areas. Cell phones have ATIS and 3GPP standard for emergency alerts. Cable set-top boxes have SCTE standards for emergency alerts. TVs with antennas have ATSC standards for emergency alerts. Analog radio still relies on broadcasters transmitting emergency alerts, i.e. that triple burst of modem noise. ISPs are also part of that, since ISPs know where their subscribers are geographically located. And yes, I'm a big believer in personal choice. Individual alert opt-outs and geo-targeting is critical. I think Canada (and New Zealand, and some other countries) are making a mistake by using the "mandatory" alert setting for all alerts. I also believe emergency alerts should be accessible to everyone, not just rich people with the most expensive smart phones and carriers. From lists.nanog at monmotha.net Sat Mar 9 19:14:27 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Sat, 9 Mar 2019 14:14:27 -0500 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: Message-ID: <72568063-979a-3444-a561-924df27acd05@monmotha.net> On 3/9/19 2:04 PM, Sean Donelan wrote: > Cell phones have ATIS and 3GPP standard for emergency alerts. Cable > set-top boxes have SCTE standards for emergency alerts. TVs with > antennas have ATSC standards for emergency alerts.  Analog radio still > relies on broadcasters transmitting emergency alerts, i.e. that triple > burst of modem noise. Any reason the ISP has to be directly involved in this? The relevant government organization originating the alert could easily have a service to make that information available to the public via some standard API (maybe they do)? Does it have to be push and application-agnostic? Maybe that's (gasp) a reasonable application for Internet multicast. Operators could help, here, by making sure that particular application of Internet multicast actually works even if other applications don't, and governments originating alerts could help by making that straightforward. Is it sufficient for the streaming services to simply include this information in their streams? Heck, they could just include all of them and let the device that's accessing the stream figure out which ones are relevant. After all, it's the streaming service that knows the user is consuming content suitable for inclusion of emergency alerts. The network operator rarely knows this directly (though we're pretty good at inferring it). > > ISPs are also part of that, since ISPs know where their subscribers are > geographically located. Do they? They know where the account is geographically located, but they don't necessarily know that the device consuming the media is located at the account address. Again, operators could help here by providing some sort of service to say "Where is my account located?", but many consumers of streaming media have far more accurate information based on mobile network geolocation information, Wi-Fi mapping, or outright GPS. I think the solution to this is perhaps maybe that network operators could "help" by building in some useful features to their network without explicitly supporting EAS or otherwise. After all, we (or at least most of us) already run pretty content- and application-neutral (and even -unaware) networks. Whether it's a good idea or even necessary to make those "helpful" features mandatory is perhaps a good question. At this stage, I'd probably lean toward no and see whether things resolve themselves on their own. The Internet, et. al., is pretty good at adapting to use cases like this without heavy-handed intervention it seems. -- Brandon Martin From valdis.kletnieks at vt.edu Sat Mar 9 19:53:18 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sat, 09 Mar 2019 14:53:18 -0500 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: <72568063-979a-3444-a561-924df27acd05@monmotha.net> References: <72568063-979a-3444-a561-924df27acd05@monmotha.net> Message-ID: <25267.1552161198@turing-police> On Sat, 09 Mar 2019 14:14:27 -0500, Brandon Martin said: > I think the solution to this is perhaps maybe that network operators > could "help" by building in some useful features to their network > without explicitly supporting EAS or otherwise. After all, we (or at > least most of us) already run pretty content- and application-neutral > (and even -unaware) networks. Didn't we just have a discussion about brain-dead firewalls that block any protocols/ports they don't know about? How does that play into the equation? From sean at donelan.com Sat Mar 9 20:03:02 2019 From: sean at donelan.com (Sean Donelan) Date: Sat, 9 Mar 2019 15:03:02 -0500 (EST) Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: <72568063-979a-3444-a561-924df27acd05@monmotha.net> References: <72568063-979a-3444-a561-924df27acd05@monmotha.net> Message-ID: On Sat, 9 Mar 2019, Brandon Martin wrote: > Any reason the ISP has to be directly involved in this? The relevant > government organization originating the alert could easily have a service to > make that information available to the public via some standard API (maybe > they do)? ISPs with Akamai servers on their network already have this. Akamai supplies FEMA IPAWS messages anywhere on its CDN. Smart Speakers, Smart TVs, streaming devices could query the nearest Akamai CDN server on the ISP network. > Does it have to be push and application-agnostic? Maybe that's (gasp) a > reasonable application for Internet multicast. Operators could help, here, > by making sure that particular application of Internet multicast actually > works even if other applications don't, and governments originating alerts > could help by making that straightforward. I've proposed using multicast in the past. Canada uses IP Multicast over satellite for its system. Emergency alerts are usually supplied at no-cost to subscribers by the supplier. That is, cellular carriers do not charge for SMS fees, cable TV companies do not charge for the emergency alert channel, etc. It may be part of the overhead cost, but not a separate subscriber charge. Although FEMA IPAWS alerts are digitally signed, ISPs have never figure out a good way to secure IP multicast and prevent IP multicast DDOS. ISPs also haven't figured otu a good way to charge money for IP multicast. But since emergency alerts would be a non-chargable service, that's less of an issue for emergency alerts. But if ISPs did, they could transmit the FEMA IPAWS alert stream via multicast. Managed IPTV suppliers, i.e. AT&T U-Verse, use IP multicast for their emergency alert service. > Is it sufficient for the streaming services to simply include this > information in their streams? Heck, they could just include all of them and > let the device that's accessing the stream figure out which ones are > relevant. After all, it's the streaming service that knows the user is > consuming content suitable for inclusion of emergency alerts. The network > operator rarely knows this directly (though we're pretty good at inferring > it). Requiring each streaming service to duplicate the emergency alert stream seems to be a lot more overhead than ISPs supplying one stream with only emergency alerts. This seems more like ISPs trying to cost shift to streaming suppliers, or vice versa, streaming services trying to cost shift to ISPs. ISPs already supply a DNS lookup service as part of their Internet service. ISPs could supply an Emergency Alert service as part of their basic Internet service. Of course, some ISPs suck at even DNS, so there are third-part DNS services. Unlike analog channels, Internet Protocol is multiplexed. IP can handle data from different sources over the same interfaces. > Do they? They know where the account is geographically located, but they > don't necessarily know that the device consuming the media is located at the > account address. This was the huge debate with 9-1-1 VOIP emergency phone service. Rather than repeating the geolocation arguments, just incorporate the 9-1-1 VOIP geolocation debates by reference. > Again, operators could help here by providing some sort of service to say > "Where is my account located?", but many consumers of streaming media have > far more accurate information based on mobile network geolocation > information, Wi-Fi mapping, or outright GPS. I agree, when available. If a streaming device can figure out how to black-out sports events or geo-target advertising in specific geographic areas, it should be able to figure out which emergency alerts are relevant to specific geographic areas. Once again, the cellular industry is an example of fighting something. Although most smart phones have built in mapping services and cellular advertisers can track your geographic location within 10 meters; cellular providers have been dragging their feet in geo-locating emergency alerts. Automatically geo-locating indoor smart speakers and smart TVs is more difficult, but if advertisers can get geolocation information from AT&T, Amazon, Apple, Google, Sprint, T-Mobile, Verizon, etc; why can't emergency alerts? > Whether it's a good idea or even necessary to make those "helpful" features > mandatory is perhaps a good question. At this stage, I'd probably lean > toward no and see whether things resolve themselves on their own. The > Internet, et. al., is pretty good at adapting to use cases like this without > heavy-handed intervention it seems. Sitting on the sidelines means you won't get to provide input on how it works. If you want to it to happen a specific way, then you need to contribute that way early in the process. The myth of the Internet figuring everything out isn't really true. Many of the things people take for granted, are the result of some intervention and even government requirements. Government requirements are often just public intervention when industry fails to act on its own. From lists.nanog at monmotha.net Sat Mar 9 20:18:34 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Sat, 9 Mar 2019 15:18:34 -0500 Subject: Free Open Source Network Operating Systems In-Reply-To: <76EFB9A6-E234-4C17-B5D6-08ECD7CB37D9@lixfeld.ca> References: <76EFB9A6-E234-4C17-B5D6-08ECD7CB37D9@lixfeld.ca> Message-ID: <85dd7011-67d9-15e3-b0fb-6f34f95380a5@monmotha.net> On 3/9/19 11:36 AM, Jason Lixfeld wrote: > I could be making this up, but my understanding is that the Broadcom SDK > is not free, and without the SDK, hardware interaction is limited. It likely is not. What would be interesting to know, however, is if the terms under which it (or at least the necessary hardware documentation) is distributed would permit a clean F/OSS implementation. If it would, then you just need to find someone at Broadcom to give you the time of day... -- Brandon Martin From snoble at sonn.com Sat Mar 9 20:25:38 2019 From: snoble at sonn.com (Steve Noble) Date: Sat, 9 Mar 2019 12:25:38 -0800 Subject: Free Open Source Network Operating Systems In-Reply-To: <85dd7011-67d9-15e3-b0fb-6f34f95380a5@monmotha.net> References: <76EFB9A6-E234-4C17-B5D6-08ECD7CB37D9@lixfeld.ca> <85dd7011-67d9-15e3-b0fb-6f34f95380a5@monmotha.net> Message-ID: <773b2f29-79b9-7af3-2400-903245c88d3b@sonn.com> Brandon Martin wrote on 3/9/19 12:18 PM: > On 3/9/19 11:36 AM, Jason Lixfeld wrote: >> I could be making this up, but my understanding is that the Broadcom >> SDK is not free, and without the SDK, hardware interaction is limited. > > It likely is not. > > What would be interesting to know, however, is if the terms under > which it (or at least the necessary hardware documentation) is > distributed would permit a clean F/OSS implementation. > > If it would, then you just need to find someone at Broadcom to give > you the time of day... If you don't need the SDK specifically and are using a Broadcom based switch you can get of-dpa or OpenNSL for multiple switches from https://github.com/Broadcom-Switch/ .  You can also normally get of-dpa, OpenNSL and even SAI from the switch vendor directly. From sethm at rollernet.us Sat Mar 9 20:27:18 2019 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 9 Mar 2019 12:27:18 -0800 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: <72568063-979a-3444-a561-924df27acd05@monmotha.net> Message-ID: <98e11b30-a184-cfdb-4c51-4aaacdc58b62@rollernet.us> On 3/9/19 12:03 PM, Sean Donelan wrote: > Automatically geo-locating indoor smart speakers and smart TVs is more > difficult, but if advertisers can get geolocation information from AT&T, > Amazon, Apple, Google, Sprint, T-Mobile, Verizon, etc; why can't > emergency alerts? There's no technical reason emergency alerts can't be geo located. But advertisers pay for it; emergency alerts aren't revenue generating. From shivaram.mysore at gmail.com Sat Mar 9 20:35:18 2019 From: shivaram.mysore at gmail.com (Shivaram Mysore) Date: Sat, 9 Mar 2019 12:35:18 -0800 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: <98e11b30-a184-cfdb-4c51-4aaacdc58b62@rollernet.us> References: <72568063-979a-3444-a561-924df27acd05@monmotha.net> <98e11b30-a184-cfdb-4c51-4aaacdc58b62@rollernet.us> Message-ID: <33D75D3E-1BB3-485A-80B9-61F5A66CC022@gmail.com> I personally believe apps should not be emitting generic emergency alerts. Devices should - ex TV, mobile phone, etc. if one is watching Hulu, MLB, NFL, or any other app it should not matter as long as device is notifying the user. /Shivaram ::Sent from my mobile device:: > On Mar 9, 2019, at 12:27 PM, Seth Mattinen wrote: > >> On 3/9/19 12:03 PM, Sean Donelan wrote: >> Automatically geo-locating indoor smart speakers and smart TVs is more difficult, but if advertisers can get geolocation information from AT&T, Amazon, Apple, Google, Sprint, T-Mobile, Verizon, etc; why can't emergency alerts? > > > There's no technical reason emergency alerts can't be geo located. But advertisers pay for it; emergency alerts aren't revenue generating. From sean at donelan.com Sat Mar 9 21:04:16 2019 From: sean at donelan.com (Sean Donelan) Date: Sat, 9 Mar 2019 16:04:16 -0500 (EST) Subject: Technical bandwidth requirements for Emergency Alerts Message-ID: Some background information for network engineers unfamilar with emergency alerts. In the United States, there are approximately 500,000 emergency alerts nationwide a year, not counting another million or so test alerts. Only about 7,500 emergency alerts are severe enough to activate public warning systems. Most emergency alerts are intended for other emergency management agencies and officials. The rest are advisories, watches, updates and cancels. The peak emergency alert busy day is 4 alerts per minute nationwide. Although stress testing indicates most emergency alert systems should be able to handle more. Emergency alerts are not evenly distributed across the country. Some geographic areas have nearly none. Other geographic areas have many, e.g. tornado alley and atlantic coastlines. Since the 1950s, there has never been an actual nationwide emergency alert, i.e. presidential alert message. Emergency alerts are almost all state, local and weather alerts. Test alerts are the most common alert type. The IPAWS system supports very geo-targetted alerts, and supports opting in or opting out of specific types of alerts. When government officials use those options, and alert distributions implement those options. When the IPAWS emergency alert standards were being written, 1.5 Mbps DSL lines and even 128Kbps ISDN lines were still common, so the IPAWS emergency alert message sizes were made relatively small. But it was still an huge improvement over the previous EAS radio and TV broadcast modem data bursts from the 1980s/1990s, which were limited to 256 characters. The average IPAWS emergency alert is 5KB to 15KB in size. Including audio and image files, the entire emergency alert can be about 5MB in size. In the U.S., audio and image files are transmitted separately because rural Internet connections were too slow at the time. Canada's AlertReady system is more recent, and can handle larger alert messages. In Canada, audio and image files are transmitted as part of the satellite IP multicast emergency alert message. The small 90-character cellular phone message was also due to the limited bandwidth available in cellular networks at the time. Newer cell broadcast networks can handle nearly 1,000 character messages. Starting in May 2019, the U.S. WEA mobile alerts will increase to 360 characters. Changes are slow. It takes less than 10 seconds to transmit an IPAWS emergency alert nationwide. Although radio and TV may delay transmitting an emergency alert up to 15 minutes, i.e. during commercial breaks. The goal for earthquake alert messages is less than 3 seconds, which is not currently achievable. All 500,000 emergency alerts do not need to be transmitted nationwide. An alert distributor can selectively transmits only relevant alerts to different geographic areas, and choose not to include less severe advisories or many tests. Training for state and local government officials issuing alerts is very underfunded, and they make mistakes. The public hates emergency alert systems, until a tornado destroys their home in the middle of the night, and then they complain they didn't get an emergency alert. From sean at donelan.com Sat Mar 9 21:09:06 2019 From: sean at donelan.com (Sean Donelan) Date: Sat, 9 Mar 2019 16:09:06 -0500 (EST) Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: <98e11b30-a184-cfdb-4c51-4aaacdc58b62@rollernet.us> References: <72568063-979a-3444-a561-924df27acd05@monmotha.net> <98e11b30-a184-cfdb-4c51-4aaacdc58b62@rollernet.us> Message-ID: On Sat, 9 Mar 2019, Seth Mattinen wrote: > On 3/9/19 12:03 PM, Sean Donelan wrote: >> Automatically geo-locating indoor smart speakers and smart TVs is more >> difficult, but if advertisers can get geolocation information from AT&T, >> Amazon, Apple, Google, Sprint, T-Mobile, Verizon, etc; why can't emergency >> alerts? > > There's no technical reason emergency alerts can't be geo located. But > advertisers pay for it; emergency alerts aren't revenue generating. In other words, only rich people deserve to be warned. Poor people.... Well, I guess they are poor and don't buy enough stuff from advertisers to be considered "revenue generating." Is that why Amazon, Apple and Google don't have emergency alerts as part of their "smart devices?" Good PR move. Amazon Alexa will alert me as it tracks my package of stuff, but won't warn me about the tornado about to destroy my neighborhood. From mohta at necom830.hpcl.titech.ac.jp Sat Mar 9 23:02:48 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sun, 10 Mar 2019 08:02:48 +0900 Subject: SLAAC in renumbering events In-Reply-To: <41ee9908-03e9-0e4b-a651-8ad1e2f52d74@si6networks.com> References: <41ee9908-03e9-0e4b-a651-8ad1e2f52d74@si6networks.com> Message-ID: <2a89677d-bea0-8b53-14cf-866d69fcae4d@necom830.hpcl.titech.ac.jp> Fernando Gont wrote: > There are a number of scenarios where SLAAC hosts may end up using stale > configuration information. That's because SLAAC maintain address configuration state in fully distributed manner without any authority, which is the worst possible way to do so. The only reasonable solution is to ban SLAAC. Masataka Ohta From beecher at beecher.cc Sat Mar 9 23:06:42 2019 From: beecher at beecher.cc (Tom Beecher) Date: Sat, 9 Mar 2019 18:06:42 -0500 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: <72568063-979a-3444-a561-924df27acd05@monmotha.net> <98e11b30-a184-cfdb-4c51-4aaacdc58b62@rollernet.us> Message-ID: Business ask to create near real time, location aware notification system to increase user engagement and refine ad tracking : "That's a a great idea, we can do that!" Government ask to create near real time, location aware notification system for public safety warnings : "THAT IS A BRIDGE TOO FAR, THIS IS OUTRAGEOUS GOVERNMENT OVERREACH!" On Sat, Mar 9, 2019 at 4:10 PM Sean Donelan wrote: > On Sat, 9 Mar 2019, Seth Mattinen wrote: > > On 3/9/19 12:03 PM, Sean Donelan wrote: > >> Automatically geo-locating indoor smart speakers and smart TVs is more > >> difficult, but if advertisers can get geolocation information from > AT&T, > >> Amazon, Apple, Google, Sprint, T-Mobile, Verizon, etc; why can't > emergency > >> alerts? > > > > There's no technical reason emergency alerts can't be geo located. But > > advertisers pay for it; emergency alerts aren't revenue generating. > > In other words, only rich people deserve to be warned. > > Poor people.... Well, I guess they are poor and don't buy enough stuff > from advertisers to be considered "revenue generating." > > Is that why Amazon, Apple and Google don't have emergency alerts as part > of their "smart devices?" Good PR move. > > Amazon Alexa will alert me as it tracks my package of stuff, but won't > warn me about the tornado about to destroy my neighborhood. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mohta at necom830.hpcl.titech.ac.jp Sun Mar 10 03:12:08 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sun, 10 Mar 2019 12:12:08 +0900 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> References: <20190227100105.GF19597@arundodonax.nekodune.net> <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> Message-ID: Mark Andrews wrote: > Why should the rest of the world have to put up with their inability > to purchase devices that work with RFC compliant data streams. Because RFCs specifying IPv6 are broken. That is, as PTB is generated against multicast, we should block them. Then, not blocking PTB against unicast needs very deep inspection, which is not possible with some network processors. See https://meetings.apnic.net/32/pdf/pathMTU.pdf for details. William Herrin wrote: > IPv4's inventors did a brilliant job with what they knew at the > time. IPv6's inventors not so much. Sadly, they were too busy > figuring out how to make IPv6 integrate well with ATM. Seriously, > if you dig up a copy of the original IPng book I think it's chapter 3. Indeed. IPv6 replaced link broadcast by various kind of multicast addresses only to increase MLDP overhead, because IPng WG believed that simple broadcast does not but more complicated multicast does work with IP over ATM. Masataka Ohta From jackson.tim at gmail.com Sun Mar 10 04:42:47 2019 From: jackson.tim at gmail.com (Tim Jackson) Date: Sat, 9 Mar 2019 22:42:47 -0600 Subject: Free Open Source Network Operating Systems In-Reply-To: References: Message-ID: SONiC https://azure.github.io/SONiC/ On Sat, Mar 9, 2019, 10:09 AM Colton Conor wrote: > What free, opensouce, network operating systems currently exist that run > on whitebox broadcom or other merchant silicon switches? > > I know Cumulus is very popular, but I don't believe they have a free > version that runs on whitebox switches right? Only on a virtual machine > from what I can tell. > > I think if one of these vendors would release a free and truly opensource > network operating system, with the option for paid support if needed, then > whitebox switching would really take off. This would be similar to the > Redhat model, but for the networking world. > > Right now, the cost of the whitebox plus a paid network operating system > seems to equal the same cost as a discounted Juniper, Cisco, or Arista. I > am not seeing the savings on paper. > > If we could just buy the whitebox hardware, and have a free operating > system on there, then financially whitebox switches would be half the cost > of a similar Cisco switch after discount. > > Am I missing something? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bzs at theworld.com Sun Mar 10 07:31:30 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Sun, 10 Mar 2019 03:31:30 -0400 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: Message-ID: <23684.48466.161723.602763@gargle.gargle.HOWL> I'm old. I was online @MIT-AI the night the pentagon (probably DISA?) started broadcasting messages that basically the ARPAnet was going down for "emergency testing" blah blah. I thought it was a prank so just kept working. Another message or two and it all went dead, CONNECTION LOST Couldn't dial back in. Idjits, oh well. The next morning I found out some students (not MIT students) had taken over the US embassy in Tehran so that would have been 1979-11-04 more or less. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From rajag at qti.qualcomm.com Sun Mar 10 07:39:56 2019 From: rajag at qti.qualcomm.com (Raja Sekhar Gullapalli) Date: Sun, 10 Mar 2019 07:39:56 +0000 Subject: Issue with Geolocation in Virginia US In-Reply-To: <5EA0DC15-0104-4740-A3D6-600BC85E347E@reservetele.com> References: <398B250423578A4E97AFE1B8B67C686C652071C8@PDDCWMBXEX503.ctl.intranet>, <36db5cd2c5914eae8b889cd4818b5d87@APHYDEXM01E.ap.qualcomm.com> <5EA0DC15-0104-4740-A3D6-600BC85E347E@reservetele.com> Message-ID: Thanks Luke. Let me submit the request to maxmind to change it. How you got below know info. Is there a way to check. you should probably also seek out getting geo updated on at least 3 different ones you have 3 different results. 129.46.232.65 ip2location Raleigh NC neustar butler TN maxmind Bridgewater NJ Regards, Raja From: Luke Guillory Sent: Saturday, March 9, 2019 1:18 PM To: Raja Sekhar Gullapalli Cc: Delacruz, Anthony B ; nanog at nanog.org Subject: [EXT] Re: Issue with Geolocation in Virginia US Maxmind https://support.maxmind.com/geoip-data-correction-request/ Luke Ns Sent from my iPad On Mar 9, 2019, at 1:02 AM, Raja Sekhar Gullapalli > wrote: Hi Anthony, First one already tried & but no response. Who will help in getting geo updated which shows 3 results as per your email. Regards, Raja go/snitnet or go/itnet to request Network Services. From: Delacruz, Anthony B > Sent: Saturday, March 9, 2019 1:28 AM To: Raja Sekhar Gullapalli >; nanog at nanog.org Subject: [EXT] RE: Issue with Geolocation in Virginia US This sometimes helps https://support.google.com/websearch/contact/ip you should probably also seek out getting geo updated on at least 3 different ones you have 3 different results. 129.46.232.65 ip2location Raleigh NC neustar butler TN maxmind Bridgewater NJ From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Raja Sekhar Gullapalli Sent: Wednesday, February 27, 2019 11:32 PM To: nanog at nanog.org Subject: Issue with Geolocation in Virginia US Team, We are having issues in our Virginia US office & it shows geolocation in all browsers as Canada instead of US region when we access news.google.com in our PC. Our public ip is 129.46.232.65. This issue is being observed for more than 2 month. Can you help to whom we can contact to resolve the issue. Regards, Raja This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From colton.conor at gmail.com Sun Mar 10 14:07:50 2019 From: colton.conor at gmail.com (Colton Conor) Date: Sun, 10 Mar 2019 09:07:50 -0500 Subject: Free Open Source Network Operating Systems In-Reply-To: References: Message-ID: Luke, Does VYOS run on bare metal broadcom switches though? I know it runs on X86, but I wan't aware it could run on bare metal switches. I don't see a hardware compatibility list on their website either. On Sat, Mar 9, 2019 at 10:32 AM Luke Marrott wrote: > Been a long time since I’ve messed with it but Vyatta may be worth looking > at. > > https://vyos.io/ > > > > > On Sat, Mar 9, 2019 at 09:09 Colton Conor wrote: > >> What free, opensouce, network operating systems currently exist that run >> on whitebox broadcom or other merchant silicon switches? >> >> I know Cumulus is very popular, but I don't believe they have a free >> version that runs on whitebox switches right? Only on a virtual machine >> from what I can tell. >> >> I think if one of these vendors would release a free and truly opensource >> network operating system, with the option for paid support if needed, then >> whitebox switching would really take off. This would be similar to the >> Redhat model, but for the networking world. >> >> Right now, the cost of the whitebox plus a paid network operating system >> seems to equal the same cost as a discounted Juniper, Cisco, or Arista. I >> am not seeing the savings on paper. >> >> If we could just buy the whitebox hardware, and have a free operating >> system on there, then financially whitebox switches would be half the cost >> of a similar Cisco switch after discount. >> >> Am I missing something? >> >> >> -- > :Luke Marrott > -------------- next part -------------- An HTML attachment was scrubbed... URL: From colton.conor at gmail.com Sun Mar 10 14:09:43 2019 From: colton.conor at gmail.com (Colton Conor) Date: Sun, 10 Mar 2019 09:09:43 -0500 Subject: Free Open Source Network Operating Systems In-Reply-To: References: Message-ID: Are either of you using SONiC in production? Seems to be well backed, and have good feature support. On Sat, Mar 9, 2019 at 10:42 PM Tim Jackson wrote: > SONiC > > https://azure.github.io/SONiC/ > > On Sat, Mar 9, 2019, 10:09 AM Colton Conor wrote: > >> What free, opensouce, network operating systems currently exist that run >> on whitebox broadcom or other merchant silicon switches? >> >> I know Cumulus is very popular, but I don't believe they have a free >> version that runs on whitebox switches right? Only on a virtual machine >> from what I can tell. >> >> I think if one of these vendors would release a free and truly opensource >> network operating system, with the option for paid support if needed, then >> whitebox switching would really take off. This would be similar to the >> Redhat model, but for the networking world. >> >> Right now, the cost of the whitebox plus a paid network operating system >> seems to equal the same cost as a discounted Juniper, Cisco, or Arista. I >> am not seeing the savings on paper. >> >> If we could just buy the whitebox hardware, and have a free operating >> system on there, then financially whitebox switches would be half the cost >> of a similar Cisco switch after discount. >> >> Am I missing something? >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsk at gsp.org Sun Mar 10 14:21:45 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Sun, 10 Mar 2019 10:21:45 -0400 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: Message-ID: <20190310142144.GA6710@gsp.org> A side point: On Sat, Mar 09, 2019 at 02:04:33PM -0500, Sean Donelan wrote: > Wireless Emergency Alerts (WEA), i.e., mobile phone alerts, are less than 10 > years old. And mostly on the high-end expensive cell phones and the most > expensive carriers. People on NANOG may use mostly expensive smartphones, > but not everyone can afford smartphones. That's an excellent point that's often lost among people who work in our industry. Not everyone is so wealthy as to afford the luxury of a smartphone. And not everyone can use one. And not everyone wants one. The first two items also happen to describe the people who are most vulnerable to disasters and have the most difficulty getting assistance recovering from them: the poor and the elderly. ---rsk From beecher at beecher.cc Sun Mar 10 14:39:01 2019 From: beecher at beecher.cc (Tom Beecher) Date: Sun, 10 Mar 2019 10:39:01 -0400 Subject: Issue with Geolocation in Virginia US In-Reply-To: References: <398B250423578A4E97AFE1B8B67C686C652071C8@PDDCWMBXEX503.ctl.intranet> <36db5cd2c5914eae8b889cd4818b5d87@APHYDEXM01E.ap.qualcomm.com> <5EA0DC15-0104-4740-A3D6-600BC85E347E@reservetele.com> Message-ID: I slammed together a Really Bad Script last year that checked all the major geo IP datapack providers via screen scrap or API for a particular issue we were dealing with. If I can find it, I'll make it Less Really Bad and put it up on Github. On Sun, Mar 10, 2019 at 3:41 AM Raja Sekhar Gullapalli < rajag at qti.qualcomm.com> wrote: > Thanks Luke. Let me submit the request to maxmind to change it. > > > > How you got below know info. Is there a way to check. > > > > you should probably also seek out getting geo updated on at least 3 > different ones you have 3 different results. > > > > 129.46.232.65 > > ip2location Raleigh NC > > neustar butler TN > > maxmind Bridgewater NJ > > > > > > Regards, > > Raja > > > > > > > > *From:* Luke Guillory > *Sent:* Saturday, March 9, 2019 1:18 PM > *To:* Raja Sekhar Gullapalli > *Cc:* Delacruz, Anthony B ; > nanog at nanog.org > *Subject:* [EXT] Re: Issue with Geolocation in Virginia US > > > > Maxmind > > > > > > https://support.maxmind.com/geoip-data-correction-request/ > > > > Luke > > > > > > Ns > > > > > > > > Sent from my iPad > > > On Mar 9, 2019, at 1:02 AM, Raja Sekhar Gullapalli > wrote: > > Hi Anthony, > > > > First one already tried & but no response. > > > > Who will help in getting geo updated which shows 3 results as per your > email. > > > > Regards, > > Raja > > > > go/snitnet or go/itnet to request Network Services. > > > > > > *From:* Delacruz, Anthony B > *Sent:* Saturday, March 9, 2019 1:28 AM > *To:* Raja Sekhar Gullapalli ; nanog at nanog.org > *Subject:* [EXT] RE: Issue with Geolocation in Virginia US > > > > This sometimes helps > > > > https://support.google.com/websearch/contact/ip > > > > you should probably also seek out getting geo updated on at least 3 > different ones you have 3 different results. > > > > 129.46.232.65 > > ip2location Raleigh NC > > neustar butler TN > > maxmind Bridgewater NJ > > > > *From:* NANOG [mailto:nanog-bounces at nanog.org ] *On > Behalf Of *Raja Sekhar Gullapalli > *Sent:* Wednesday, February 27, 2019 11:32 PM > *To:* nanog at nanog.org > *Subject:* Issue with Geolocation in Virginia US > > > > Team, > > > > We are having issues in our Virginia US office & it shows geolocation in > all browsers as Canada instead of US region when we access news.google.com > in our PC. > > > > Our public ip is 129.46.232.65. This issue is being observed for more than > 2 month. > > > > Can you help to whom we can contact to resolve the issue. > > > > > > Regards, > > Raja > > > > > > This communication is the property of CenturyLink and may contain > confidential or privileged information. Unauthorized use of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please immediately notify the sender > by reply e-mail and destroy all copies of the communication and any > attachments. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Sun Mar 10 16:54:52 2019 From: bill at herrin.us (William Herrin) Date: Sun, 10 Mar 2019 09:54:52 -0700 Subject: SLAAC in renumbering events In-Reply-To: <41ee9908-03e9-0e4b-a651-8ad1e2f52d74@si6networks.com> References: <41ee9908-03e9-0e4b-a651-8ad1e2f52d74@si6networks.com> Message-ID: On Fri, Mar 8, 2019 at 3:32 AM Fernando Gont wrote: > If you follow the 6man working group of the IETF you may have seen a > bunch of emails on this topic, on a thread resulting from an IETF > Internet-Draft we published with Jan Žorž about "Reaction of Stateless > Address Autoconfiguration (SLAAC) to Renumbering Events" (Available at: > > https://github.com/fgont/draft-slaac-renum/raw/master/draft-gont-6man-slaac-renum-02.txt > ) > Hi Fernando, I'm a little confused here. I can certainly see why the default timeout of 30 days is a problem, but doesn't the host lose the route from the RA sooner? Why would an IPv6 host originate connections from an address for which it has no corresponding route? Isn't that broken source address selection? I'd love to see that addressed in your draft. Obviously having the router always explicitly expire the old addresses is a non-starter. There's no certainty that the router knows what the old addresses were, that it's even the same piece of equipment or that all the hosts will see the packet if it does manage to send one. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From surfer at mauigateway.com Sun Mar 10 19:38:20 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Sun, 10 Mar 2019 12:38:20 -0700 Subject: Should Netflix and Hulu give you emergency alerts? Message-ID: <20190310123820.314CC36A@m0117459.ppops.net> --- beecher at beecher.cc wrote: From: Tom Beecher Business ask to create near real time, location aware notification system to increase user engagement and refine ad tracking : "That's a a great idea, we can do that!" Government ask to create near real time, location aware notification system for public safety warnings : "THAT IS A BRIDGE TOO FAR, THIS IS OUTRAGEOUS GOVERNMENT OVERREACH!" ------------------------------------------------------- No, it is overreach and Doing The Wrong Thing (AKA we do evil now even though we said we wouldn't in the beginning) for businesses as well. scott From sy at netcases.net Sun Mar 10 20:32:14 2019 From: sy at netcases.net (Howard C. Berkowitz) Date: Sun, 10 Mar 2019 16:32:14 -0400 Subject: Experiences on Cable Advisory Commissions Message-ID: I've designed services for cable and other residential broadband, and evaluated vendor proposals for WAN services. Now, though, I have a new responsibility: being on the Cable Advisory Committee for my small Cape Cod town od Chatham, MA. We're the easternmost point on the continental US, have been around for 300 years, and even was the original Marconi transmitter site and a WWII SIGINT intercept base. We have, however, more Great White Sharks than technologists. The town has a blue-collar fishing population that is dwarfed by summer vacationers/summer home residents. Has anyone else been in such a civic role? Can we share experience? Its first role is evaluating performance of Comcast, the incumbent, and deciding whether to recommend renewal or make a preliminary denial. This gets into an overall "ascertainment of needs" requirements process, possibly for new features to be built into the renewed contract. There are other issues to examine, such as subscribers cutting the cable or getting other digital access. Since the municipality gets revenue from the franchise fees, this may mean a drop in funding for Public Access, Education, and Government video channels. While it's not within the original committee charter, we may well look at overall communications architecture, including municipal fiber and Wifi, cellular infrastructure, emergency communications, etc. -- Howard C. Berkowitz 95 George Ryder Rd. Chatham, MA 02633 sy at netcases.net (508)241-1362 cell (866)262-6579 fax From fgont at si6networks.com Sun Mar 10 20:53:57 2019 From: fgont at si6networks.com (Fernando Gont) Date: Sun, 10 Mar 2019 17:53:57 -0300 Subject: SLAAC in renumbering events In-Reply-To: References: <41ee9908-03e9-0e4b-a651-8ad1e2f52d74@si6networks.com> Message-ID: Hi, Bill, Thanks for the feedback! In-line.... On 10/3/19 13:54, William Herrin wrote: > > > On Fri, Mar 8, 2019 at 3:32 AM Fernando Gont > wrote: > > If you follow the 6man working group of the IETF you may have seen a > bunch of emails on this topic, on a thread resulting from an IETF > Internet-Draft we published with Jan Žorž about "Reaction of Stateless > Address Autoconfiguration (SLAAC) to Renumbering Events" (Available at: > https://github.com/fgont/draft-slaac-renum/raw/master/draft-gont-6man-slaac-renum-02.txt >  ) > > > Hi Fernando, > > I'm a little confused here. I can certainly see why the default timeout > of 30 days is a problem, but doesn't the host lose the route from the RA > sooner? Which route? Configuration of addresses is mostly a different business than acquiring routes. SO, in the typical scenario where the CPE crashes and reboots, hosts will even have a default route -- advertised by the router that crashed and rebooted. If you are referring to the "on-link" route -- i.e., the route introduced because the Prefix Information Option had the "L" bit set -- then I don't think there's anything in the standard to actually grabage-collect such routes. > Why would an IPv6 host originate connections from an address for > which it has no corresponding route? Isn't that broken source address > selection? Please see above. The mechanism we specified in Section 5.1.3 of our draft tries to do exactly that: Try to detect when a previously-advertised prefix has become stale... and when it's inferred to be stale, just remove all the corresponding information. Regarding fixing this issue with source address selection: some have suggested that his should be addressed in source address selection. However, there are a number of problems with this. If you prioritize addresses from the prefix that was last advertised, then source addresses are guaranteed to flap -- and in the cause of multi-prefix networks, this would become a troubleshooting nightmare. Secondly, if you don't remove the on-link route for the stale-prefix, then packets meant to the new "owners" of that prefix will be assumed to be on-link, and hence communication will fail. This should probably be an indication that the solution is not to avoid using the stale information, but rather discarding it in a timelier manner. Please do let me know if I've missed anything. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From sean at donelan.com Sun Mar 10 21:37:30 2019 From: sean at donelan.com (Sean Donelan) Date: Sun, 10 Mar 2019 17:37:30 -0400 (EDT) Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: <20190310123820.314CC36A@m0117459.ppops.net> References: <20190310123820.314CC36A@m0117459.ppops.net> Message-ID: On Sun, 10 Mar 2019, Scott Weeks wrote: > No, it is overreach and Doing The Wrong Thing (AKA we do > evil now even though we said we wouldn't in the beginning) > for businesses as well. There is weird business feedback loop between proprietary app creators and smart device platform providers. Governments issue public alerts without restrictions. You don't need to reveal your location, how you use the alerts, etc. You paid for it as part of your taxes. There is not extra charge by the government to get emergency alerts. Proprietary Apps take that public information to build up walled gardens, with restrictions and harvest information from the users of those Apps. Addon proprietary App vendors heavily lobby to discourage platform creators and the government from competing with them. Some companies have regularly lobby congress to prohibit the National Weather Service from directly distributing weather forecasts and warnings directly to the public, instead they argue the NWS should distribute the information only to commercial companies which would then sell the information to the public. Emergency alerts on cell phones went through this in the early 2000s. Lobbyists discouraged adding emergency alerts as part of the base mobile operating system. In theory subscribers could get alerts through add-on apps and SMS messages on cell phones. The feedback loop meant subscribers had to pay SMS message fees and add-on App data; cellular carriers liked the revenue enhancement. Mobile device manufacturers were paid by junkware Apps to include those junk apps on phones. Phone manufacturers liked the junkware revenue stream. This money feedback loop wasn't very effecient at actually alerting the public. Typically, less than 15% of cellular subscribers used the proprietary alert apps. The junkware apps monitized the subscribers by collecting massive amounts of tracking information. The junkware alert apps didn't work very well either, depending on when their venture capital ran-out and stopped. I don't know what the current Amazon, Apple or Google App store feedback loop is like for Apps on smart devices. Imagine in 2024, after a major climate change driven severe weather disaster, the CEOs of several Smart Device platform companies testify before congress: Senator: In 2024, smart devices are now in 90% of homes. Smart devices have replaced radio and TV as the primary source of entertainment and information programming for the public. Why don't your smart devices include emergency alerts? CEOs: Emergency alerts aren't revenue generating, and we get money from proprietary App companies not to compete with them. Senator: Do you care that your customers' were hurt by the increasingly severe weather events? CEOs: We consider it a revenue benefit that customers need to buy new stuff after their homes are destroyed. We think it contributes to our economic growth this quarter. I wonder what the Amazon, Apple and Google smart device product pitch meetings are like. From mfidelman at meetinghouse.net Mon Mar 11 00:56:32 2019 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sun, 10 Mar 2019 20:56:32 -0400 Subject: Experiences on Cable Advisory Commissions In-Reply-To: References: Message-ID: Hi Howard, On 3/10/19 4:32 PM, Howard C. Berkowitz wrote: > I've designed services for cable and other residential broadband, and > evaluated vendor proposals for WAN services. Now, though, I have a new > responsibility: being on the Cable Advisory Committee for my small > Cape Cod town od Chatham, MA. We're the easternmost point on the > continental US, have been around for 300 years, and even was the > original Marconi transmitter site and a WWII SIGINT intercept base. We > have, however, more Great White Sharks than technologists. The town > has a blue-collar fishing population that is dwarfed by summer > vacationers/summer home residents. > > Has anyone else been in such a civic role? Can we share experience? Sure. In addition to running a policy shop, focused on municipal telecom, and consulting to municipalities, I also served on the Mayor's Telecom Advisory Board in Newton, MA (essentially the cable board).  Happy to share experiences. Ask away, here, or privately.  Also happy to talk by phone (contact me to coordinate time). Miles Fidelman > > Its first role is evaluating performance of Comcast, the incumbent, > and deciding whether to recommend renewal or make a preliminary > denial. This gets into an overall "ascertainment of needs" > requirements process, possibly for new features to be built into the > renewed contract. > > There are other issues to examine, such as subscribers cutting the > cable or getting other digital access. Since the municipality gets > revenue from the franchise fees, this may mean a drop in funding for > Public Access, Education, and Government video channels. > > While it's not within the original committee charter, we may well look > at overall communications architecture, including municipal fiber and > Wifi, cellular infrastructure, emergency communications, etc. > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From list at satchell.net Mon Mar 11 03:03:10 2019 From: list at satchell.net (Stephen Satchell) Date: Sun, 10 Mar 2019 20:03:10 -0700 Subject: GPS rollover Message-ID: <3f92098a-955e-b65c-7578-905208fc2f10@satchell.net> So far as I can tell with NTP, there was no issue with time sources becoming false-tickers, including my local GPS appliance. FWIW. From mpetach at netflight.com Mon Mar 11 08:44:49 2019 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 11 Mar 2019 01:44:49 -0700 Subject: GPS rollover In-Reply-To: <3f92098a-955e-b65c-7578-905208fc2f10@satchell.net> References: <3f92098a-955e-b65c-7578-905208fc2f10@satchell.net> Message-ID: On Sun, Mar 10, 2019 at 8:04 PM Stephen Satchell wrote: > So far as I can tell with NTP, there was no issue with time sources > becoming false-tickers, including my local GPS appliance. FWIW. > > I believe the rollover is *next* month, in April. :) https://ics-cert.us-cert.gov/sites/default/files/documents/Memorandum_on_GPS_2019.pdf "This paper is intended to provide an understanding of the possible effects of the April 6, 2019 GPS Week Number Rollover on Coordinated Universal Time derived from GPS devices." Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From esr at thyrsus.com Mon Mar 11 09:00:54 2019 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 11 Mar 2019 05:00:54 -0400 Subject: GPS rollover In-Reply-To: References: <3f92098a-955e-b65c-7578-905208fc2f10@satchell.net> Message-ID: <20190311090054.GB25748@thyrsus.com> Matthew Petach : > On Sun, Mar 10, 2019 at 8:04 PM Stephen Satchell wrote: > > > So far as I can tell with NTP, there was no issue with time sources > > becoming false-tickers, including my local GPS appliance. FWIW. > > > > > I believe the rollover is *next* month, in April. :) > https://ics-cert.us-cert.gov/sites/default/files/documents/Memorandum_on_GPS_2019.pdf > > "This paper is intended to provide an understanding of the possible effects > of the April 6, 2019 GPS Week Number Rollover on Coordinated Universal Time > derived from GPS devices." I'm a domain expert in this area - lead of NTPsec and GPSD. Everything said in that memo is correct. I would add only that it is more normal now than not for GPSes to have a hidden pivot date. "For example, a particular GPS device may interpret the WN parameter relative to a firmware creation date and would experience a similar rollover event 1024 weeks after that firmware creation date." Yes, exactly. It is therefore unlikely that your GPSes will become falsetickers on 6 April. That's the good news. The bad news is that they *will* go poof some unpredictable number of weeks later. -- Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. From rsk at gsp.org Mon Mar 11 11:32:42 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 11 Mar 2019 07:32:42 -0400 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: <76073cd6-51e7-a6b2-adc4-18b00eacc7b7@alter3d.ca> References: <1552088751_200466@surgemail.mnsi.net> <1552092707_200759@surgemail.mnsi.net> <76073cd6-51e7-a6b2-adc4-18b00eacc7b7@alter3d.ca> Message-ID: <20190311113241.GA19841@gsp.org> > Just wait until your connected home speakers, smart smoke detector, smart > refrigerator, smart tv, cell phone, IP streaming box, satellite receiver, > cable box, home security panel and your Fitbit all go off warning you > of the cancellation of an Amber alert at 1:30am, because the good folks > at AlertReady.Ca and Pelmorex think that everything needs to go out at > highest precedence, because, well, think of the children! and > And thus, in the first week the system was alive, alarm fatigue set in, the > government confirmed that it cannot be trusted, and I revoked their > privilege to use my personal devices for stuff I don't want. This is why the service(s) should use confirmed opt-in on a per-device basis and offer sufficient granularity that alerts are only sent to the people who need/want them on the devices they need/want them on. To fabricate some examples: Tornado alert: why, yes, I live in southwestern Kansas so definitely send those to my home device. Silver alert: nope. I live in Queens and don't go out much and don't drive, so I won't be on the road to see the license plate you're trying to tell me about. Never send me these. Coastal flooding alert: maybe. I live 130 miles from the coast and at 550 feet, so any coastal flooding even that would affect me will be beyond catastrophic. So don't send that to my home device. However, I'm vacationing at the beach right now so send it to my mobile. This will eliminate some of the alarm fatigue as well as reducing the transmission requirements. It's just a rather straightforward exercise in database management. ---rsk From Jason_Livingood at comcast.com Mon Mar 11 14:02:52 2019 From: Jason_Livingood at comcast.com (Livingood, Jason) Date: Mon, 11 Mar 2019 14:02:52 +0000 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: <20190310142144.GA6710@gsp.org> References: <20190310142144.GA6710@gsp.org> Message-ID: <88272721-9A02-4D38-A237-86374E6D51E6@cable.comcast.com> +1 to Rich's note: I agree we need to be careful not to extrapolate our experiences/devices/preferences to the average person. Emergency alerts serve a valuable purpose, especially when something like a wild fire or tornado or whatever is approaching and an extra few seconds or a minute of advance warning is the difference between life or death. There are many situations where a smartphone may not be present and/or where the person for example is too young to own one. So yeah, to answer the original question, I think a lot of platforms probably will need to support emergency alerts over the next 10 years. As the reach of traditional broadcast channels for those alerts declines, it seems natural and good for society to shift to the channels that have attention. Of course, the devil is in the details but I'm sure thoughtful engineering, UX design, and administrative rules can be devised to make it effective and not annoying. ;-) Jason On 3/10/19, 10:23 AM, "NANOG on behalf of Rich Kulawiec" wrote: A side point: On Sat, Mar 09, 2019 at 02:04:33PM -0500, Sean Donelan wrote: > Wireless Emergency Alerts (WEA), i.e., mobile phone alerts, are less than 10 > years old. And mostly on the high-end expensive cell phones and the most > expensive carriers. People on NANOG may use mostly expensive smartphones, > but not everyone can afford smartphones. That's an excellent point that's often lost among people who work in our industry. Not everyone is so wealthy as to afford the luxury of a smartphone. And not everyone can use one. And not everyone wants one. The first two items also happen to describe the people who are most vulnerable to disasters and have the most difficulty getting assistance recovering from them: the poor and the elderly. ---rsk From luke.marrott at gmail.com Sat Mar 9 16:32:04 2019 From: luke.marrott at gmail.com (Luke Marrott) Date: Sat, 9 Mar 2019 09:32:04 -0700 Subject: Free Open Source Network Operating Systems In-Reply-To: References: Message-ID: Been a long time since I’ve messed with it but Vyatta may be worth looking at. https://vyos.io/ On Sat, Mar 9, 2019 at 09:09 Colton Conor wrote: > What free, opensouce, network operating systems currently exist that run > on whitebox broadcom or other merchant silicon switches? > > I know Cumulus is very popular, but I don't believe they have a free > version that runs on whitebox switches right? Only on a virtual machine > from what I can tell. > > I think if one of these vendors would release a free and truly opensource > network operating system, with the option for paid support if needed, then > whitebox switching would really take off. This would be similar to the > Redhat model, but for the networking world. > > Right now, the cost of the whitebox plus a paid network operating system > seems to equal the same cost as a discounted Juniper, Cisco, or Arista. I > am not seeing the savings on paper. > > If we could just buy the whitebox hardware, and have a free operating > system on there, then financially whitebox switches would be half the cost > of a similar Cisco switch after discount. > > Am I missing something? > > > -- :Luke Marrott -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhay at meraka.org.za Sat Mar 9 17:16:36 2019 From: jhay at meraka.org.za (John Hay) Date: Sat, 9 Mar 2019 19:16:36 +0200 Subject: Free Open Source Network Operating Systems In-Reply-To: <76EFB9A6-E234-4C17-B5D6-08ECD7CB37D9@lixfeld.ca> References: <76EFB9A6-E234-4C17-B5D6-08ECD7CB37D9@lixfeld.ca> Message-ID: What about SONiC? https://azure.github.io/SONiC/ On Sat, 9 Mar 2019 at 18:39, Jason Lixfeld wrote: > I could be making this up, but my understanding is that the Broadcom SDK > is not free, and without the SDK, hardware interaction is limited. > > At one time ONL was a free ONIE NOS but sans SDK. > > https://github.com/opencomputeproject/OpenNetworkLinux ? > > Sent from my iPhone > > On Mar 9, 2019, at 11:08 AM, Colton Conor wrote: > > What free, opensouce, network operating systems currently exist that run > on whitebox broadcom or other merchant silicon switches? > > I know Cumulus is very popular, but I don't believe they have a free > version that runs on whitebox switches right? Only on a virtual machine > from what I can tell. > > I think if one of these vendors would release a free and truly opensource > network operating system, with the option for paid support if needed, then > whitebox switching would really take off. This would be similar to the > Redhat model, but for the networking world. > > Right now, the cost of the whitebox plus a paid network operating system > seems to equal the same cost as a discounted Juniper, Cisco, or Arista. I > am not seeing the savings on paper. > > If we could just buy the whitebox hardware, and have a free operating > system on there, then financially whitebox switches would be half the cost > of a similar Cisco switch after discount. > > Am I missing something? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.snyder at gmail.com Sun Mar 10 12:59:41 2019 From: joseph.snyder at gmail.com (Joseph J. Jsnyder III) Date: Sun, 10 Mar 2019 08:59:41 -0400 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: <98e11b30-a184-cfdb-4c51-4aaacdc58b62@rollernet.us> References: <72568063-979a-3444-a561-924df27acd05@monmotha.net> <98e11b30-a184-cfdb-4c51-4aaacdc58b62@rollernet.us> Message-ID: <19317619-516D-4A13-B056-9681A43B79B7@gmail.com> There is the other legal issues. Adv geolocation isnt always correct and in some cases way off. If it is wrong no big deal. If emerg alert geolocation is wrong you can open yourself up to huge legal action. On March 9, 2019 3:27:18 PM EST, Seth Mattinen wrote: >On 3/9/19 12:03 PM, Sean Donelan wrote: >> Automatically geo-locating indoor smart speakers and smart TVs is >more >> difficult, but if advertisers can get geolocation information from >AT&T, >> Amazon, Apple, Google, Sprint, T-Mobile, Verizon, etc; why can't >> emergency alerts? > > >There's no technical reason emergency alerts can't be geo located. But >advertisers pay for it; emergency alerts aren't revenue generating. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Mon Mar 11 16:50:04 2019 From: bill at herrin.us (William Herrin) Date: Mon, 11 Mar 2019 09:50:04 -0700 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: Message-ID: On Fri, Mar 8, 2019 at 2:22 PM Sean Donelan wrote: > "More and more people are opting out of the traditional television > services," said Gregory Touhill, a cybersecurity expert who served at the > Department of Homeland security and was the first-ever Federal Chief > Information Security Officer. "There's a huge population out there that > needs to help us rethink how we do this." > Hi Sean, Here's my take: If it has a screen or speaker and it connects to a network, it should be capable of providing emergency alerts. Every device capable of providing emergency alerts should allow them to be easily and fully disabled. Even if there is a missile inbound, I don't need 20 devices trying to tell me all at once. In fact, the cacophony would almost certainly make the alert hard to understand. My cell phone woke me up in the middle of the night during a recent landline outage because the county felt the need to let me know that I wouldn't be able to call 911 if, you know, I happened to need to call 911. Thanks guys. Thanks a lot. And I can't block their messages. That's a problem. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Mon Mar 11 17:21:24 2019 From: sean at donelan.com (Sean Donelan) Date: Mon, 11 Mar 2019 13:21:24 -0400 (EDT) Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: <20190311113241.GA19841@gsp.org> References: <1552088751_200466@surgemail.mnsi.net> <1552092707_200759@surgemail.mnsi.net> <76073cd6-51e7-a6b2-adc4-18b00eacc7b7@alter3d.ca> <20190311113241.GA19841@gsp.org> Message-ID: On Mon, 11 Mar 2019, Rich Kulawiec wrote: > This is why the service(s) should use confirmed opt-in on a per-device basis > and offer sufficient granularity that alerts are only sent to the people who > need/want them on the devices they need/want them on. Other than nerds, which means people on the NANOG list :=), few people like configuring lots of individual devices. They usually don't. Its like blaming people for choosing bad passwords and not configuring devices securely. Defaults matter. That's why I keep emphasizing the role of "Intelligent Assistants" in these smart device ecosystems. Apple Siri, Amazon Alexa, Google Assistent have positioned themselves as the entertainment and information device content management systems in the smart device world. When you connect a new smart device into you choice of intelligent assistant, all your emergency alert preferences should carry-over to the new device. If you turned-off emergency alerts in your intelligent assistant in the past, alerts would be off on new devices. If you want alerts on in one room, and off in a different room, talk to your intelligent assistant. You shouldn't need to remember to do that each time you buy a new smart TV or smart speaker. 10 years ago, I might have said AT&T or Comcast instead of Amazon and Google, because Cable and Telco ISPs were trying to be the home network managers. But CableLabs and ATIS have failed in that regard. Facebook is still a potential powerplayer, but seems to have missed the smart device/intelligent assistant boat. > This will eliminate some of the alarm fatigue as well as reducing the > transmission requirements. It's just a rather straightforward exercise > in database management. The opt-in versus opt-out decision is a huge debate in the emergency management world. Less than 15% of people actively opt into emergency alerts on any system, but they complain loudly after disasters. Its a bit like asking people to remember to turn on airbags or anti-lock brakes in their cars. Normal humans don't think about safety systems until after its too late. A plan to have a security guard unlock the fire exits in case of fire is a bad plan. That inevitable human failure is why cable TV was forced to add emergency alerts in the 1990s, after a series of tornado outbreaks across the midwest, and cell phones were forced to add emergency alerts in the 2000s after a different set of disasters. Generally, I think imminent danger warnings should be enabled by default, with easy opt-out available. Advisories and Informational alerts, such as Be On The Lookout (i.e. amber, blue, silver, etc) advisories should be opt-in, with do-not-disturb by default. Informational alerts should not alert by default, unless the user actively opts-in; and should just appear in my daily headlines, timelines, guide, whatever your smart information content manager uses. However, just like advertisers and social media company privacy policies -- I wouldn't trust Facebook to honor emergency alert settings, emergency managers tend to ignore their promises and user preferences. Strong emergency management guidance and training of emergency alert originators is also needed to avoid alert fatigue. Its not strictly a technical problem, the people problems are harder to solve. From sean at donelan.com Mon Mar 11 17:53:47 2019 From: sean at donelan.com (Sean Donelan) Date: Mon, 11 Mar 2019 13:53:47 -0400 (EDT) Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: Message-ID: On Mon, 11 Mar 2019, William Herrin wrote: > My cell phone woke me up in the middle of the night during a recent landline > outage because the county felt the need to let me know that I wouldn't be > able to call 911 if, you know, I happened to need to call 911. Thanks guys. > Thanks a lot. And I can't block their messages. That's a problem. 1. VOIP, telcos and network operators have recurring 9-1-1 issues. There has been multiple, multi-state 9-1-1 outages in the last few years. VOIP, telcos and network operators don't seem to have coherent plans how to handle multi-state 9-1-1 outages. Don't worry, the FCC has their "best people" looking into it, again. 2. Because that was something "that will never happen," there was no plan how to alert cellular subscribers. In fact, the "TOE," Telephone Outage Emergency code for 9-1-1 outages is blocked from WEA cell phones. 3. Since there is no multi-state plan and the official emergency alert code, TOE, is blocked from WEA; county emergency managers overrode the emergency alert system and used the "extreme alert" message instead. Can you spot the multiple planning and operating flaws? ======================= In the U.S., you can always block all state/local emergency alerts, including "extreme alerts," on your cell phone. The downside is that opts-out of *ALL* state, local, weather, etc. emergency alerts, except national/presidential emergencies. Canada doesn't allow opting out of emergency alerts by cellular subscribers. I proposed to the FCC a less severe alert settings for informational advisories, which wouldn't set off the WEA alarm on your cell phone. But the message would appear, semi-unobtrusively. BTW, it would make more sense for VOIP and Telco 9-1-1 operators to have a plan to notify people at the time they dial 9-1-1 it isn't working. But since 9-1-1 "never fails," they don't seem to want to have a plan. From sfisher at cymru.com Mon Mar 11 18:40:59 2019 From: sfisher at cymru.com (Scott Fisher) Date: Mon, 11 Mar 2019 14:40:59 -0400 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: Message-ID: <88e5e77c-ac89-9b88-2559-437ceadca00a@cymru.com> It would be nice if someone from the E911 space could add their 2cents on this. Anyone from Intrado/West-Corp on the list? Thanks, Scott On 3/11/19 1:53 PM, Sean Donelan wrote: > On Mon, 11 Mar 2019, William Herrin wrote: >> My cell phone woke me up in the middle of the night during a recent >> landline >> outage because the county felt the need to let me know that I wouldn't be >> able to call 911 if, you know, I happened to need to call 911. Thanks >> guys. >> Thanks a lot. And I can't block their messages. That's a problem. > > 1. VOIP, telcos and network operators have recurring 9-1-1 issues.  > There has been multiple, multi-state 9-1-1 outages in the last few > years. VOIP, telcos and network operators don't seem to have coherent > plans how to handle multi-state 9-1-1 outages.  Don't worry, the FCC has > their "best people" looking into it, again. > > 2. Because that was something "that will never happen," there was no > plan how to alert cellular subscribers.  In fact, the "TOE," Telephone > Outage Emergency code for 9-1-1 outages is blocked from WEA cell phones. > > 3. Since there is no multi-state plan and the official emergency alert > code, TOE, is blocked from WEA; county emergency managers overrode the > emergency alert system and used the "extreme alert" message instead. > > Can you spot the multiple planning and operating flaws? > > ======================= > > In the U.S., you can always block all state/local emergency alerts, > including "extreme alerts," on your cell phone. The downside is that > opts-out of *ALL* state, local, weather, etc. emergency alerts, except > national/presidential emergencies. > > Canada doesn't allow opting out of emergency alerts by cellular > subscribers. > > I proposed to the FCC a less severe alert settings for informational > advisories, which wouldn't set off the WEA alarm on your cell phone. But > the message would appear, semi-unobtrusively. > > BTW, it would make more sense for VOIP and Telco 9-1-1 operators to have > a plan to notify people at the time they dial 9-1-1 it isn't working. > But since 9-1-1 "never fails," they don't seem to want to have a plan. > From smeuse at mara.org Mon Mar 11 21:37:09 2019 From: smeuse at mara.org (Steve Meuse) Date: Mon, 11 Mar 2019 17:37:09 -0400 Subject: Analysing traffic in context of rejecting RPKI invalids using pmacct In-Reply-To: <20190212181554.GB36142@vurt.meerval.net> References: <20190212181554.GB36142@vurt.meerval.net> Message-ID: On Tue, Feb 12, 2019 at 1:15 PM Job Snijders wrote: > > > ps. Dear Kentik & Deepfield, please copy+paste this feature! We'll > happily share development notes with you, you can even look at pmacct's > source code for inspiration. :-) > Thanks Job, I just wanted to reach back out to you and the NANOG community that we've implemented this feature. Currently Kentik can match flow data with the following validation state: - VALID = Prefix fits in ROA, and ROA ASN and Prefix Origin Match - UNKNOWN = we haven't found any matching ROA - INVALID - ASN mismatch = BGP prefix fits in the ROA prefix's length BUT the ROA ASN differs from the Prefix Origin ASN - INVALID - Prefix length out of bounds = the BGP prefix doesn't have an ROA with large enough Max-Length to refer to - INVALID - ASN 0 specified = there is a matching ROA w/ the right max-length but the ASN associated w/ it is 0 (explicit invalid) If anyone would like more information please hit me up offline. -Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Tue Mar 12 01:09:19 2019 From: bill at herrin.us (William Herrin) Date: Mon, 11 Mar 2019 18:09:19 -0700 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: Message-ID: On Mon, Mar 11, 2019 at 10:53 AM Sean Donelan wrote: > On Mon, 11 Mar 2019, William Herrin wrote: > > My cell phone woke me up in the middle of the night during a recent landline > > outage because the county felt the need to let me know that I wouldn't be > > able to call 911 if, you know, I happened to need to call 911. Thanks guys. > > Thanks a lot. And I can't block their messages. That's a problem. > > Can you spot the multiple planning and operating flaws? I would have to say the most glaring flaw was that the message was not actionable. No instructions for what to do instead. Just, "Hey, wake up! You can't call 911 right now. Bye!" Regards, Bill Herrin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at mtcc.com Tue Mar 12 01:25:35 2019 From: mike at mtcc.com (Michael Thomas) Date: Mon, 11 Mar 2019 18:25:35 -0700 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: <88272721-9A02-4D38-A237-86374E6D51E6@cable.comcast.com> References: <20190310142144.GA6710@gsp.org> <88272721-9A02-4D38-A237-86374E6D51E6@cable.comcast.com> Message-ID: <62c9ac4d-7a65-f3f0-16aa-b7e035a78b07@mtcc.com> On 3/11/19 7:02 AM, Livingood, Jason wrote: > +1 to Rich's note: I agree we need to be careful not to extrapolate our experiences/devices/preferences to the average person. Emergency alerts serve a valuable purpose, especially when something like a wild fire or tornado or whatever is approaching and an extra few seconds or a minute of advance warning is the difference between life or death. There are many situations where a smartphone may not be present and/or where the person for example is too young to own one. > > So yeah, to answer the original question, I think a lot of platforms probably will need to support emergency alerts over the next 10 years. As the reach of traditional broadcast channels for those alerts declines, it seems natural and good for society to shift to the channels that have attention. Of course, the devil is in the details but I'm sure thoughtful engineering, UX design, and administrative rules can be devised to make it effective and not annoying. ;-) > This entire thing strikes me as a horrible layering violation. Why on earth should alerts be required to dogleg through content providers? And what is a "content provider" anyway? My pizza delivery app? It looks like it sets up a lot of single points of failure. You can understand why it's that way for tv and radio -- there was only one way to deliver the side channel -- but that's completely untrue in this day and age. And while the point about not everyone having access to smartphones is valid, we need to keep in mind that any attempt to shoehorn this into content is going to take a decade of bickering and pushback. Does anybody think that in the US every phone, tv, etc, will not be internet enabled in 10 years? It seems to me that it would be much better to use the standards we already have to deliver text, voice and video, and just make it a requirement that some list of devices must be able to listen for these announcements and act accordingly. It's not like compositing video or muting one audio stream in favor of the other is rocket science. Mike From bill at herrin.us Tue Mar 12 01:57:24 2019 From: bill at herrin.us (William Herrin) Date: Mon, 11 Mar 2019 18:57:24 -0700 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: <62c9ac4d-7a65-f3f0-16aa-b7e035a78b07@mtcc.com> References: <20190310142144.GA6710@gsp.org> <88272721-9A02-4D38-A237-86374E6D51E6@cable.comcast.com> <62c9ac4d-7a65-f3f0-16aa-b7e035a78b07@mtcc.com> Message-ID: On Mon, Mar 11, 2019 at 6:25 PM Michael Thomas wrote: > This entire thing strikes me as a horrible layering violation. Why on > earth should alerts be required to dogleg through content providers? > > It seems to me that it would be much better to use the standards we > already have to deliver text, voice and video, and just make it a > requirement that some list of devices must be able to listen for these > announcements and act accordingly. Hi Mike, What;'s the plan then? Establish a multicast path throughout my backbone for the emergency alert messages and pray none of them loop back in to my system to create a storm? If my $30 home firewall receives a multicast message on the proper port it should rebroadcast it inside? What could go wrong! Wide area multicast sucks dude. That's why we have video dogleg its way through content delivery networks in the first place. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at mtcc.com Tue Mar 12 02:02:47 2019 From: mike at mtcc.com (Michael Thomas) Date: Mon, 11 Mar 2019 19:02:47 -0700 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: <20190310142144.GA6710@gsp.org> <88272721-9A02-4D38-A237-86374E6D51E6@cable.comcast.com> <62c9ac4d-7a65-f3f0-16aa-b7e035a78b07@mtcc.com> Message-ID: <6f6562c7-bbc0-331b-8717-517382bc7f5c@mtcc.com> On 3/11/19 6:57 PM, William Herrin wrote: > On Mon, Mar 11, 2019 at 6:25 PM Michael Thomas > wrote: > > This entire thing strikes me as a horrible layering violation. Why on > > earth should alerts be required to dogleg through content providers? > > > > It seems to me that it would be much better to use the standards we > > already have to deliver text, voice and video, and just make it a > > requirement that some list of devices must be able to listen for these > > announcements and act accordingly. > > Hi Mike, > > What;'s the plan then? Establish a multicast path throughout my > backbone for the emergency alert messages and pray none of them loop > back in to my system to create a storm? If my $30 home firewall > receives a multicast message on the proper port it should rebroadcast > it inside? What could go wrong! > > Wide area multicast sucks dude. That's why we have video dogleg its > way through content delivery networks in the first place. While multicast would be advantageous, it's hardly required. Brute force and ignorance (= unicast) would work too. And yeah, maybe you need to alert all of the "viewable" devices unless you have some way of detecting what I'm paying attention to. Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Tue Mar 12 03:24:09 2019 From: sean at donelan.com (Sean Donelan) Date: Mon, 11 Mar 2019 23:24:09 -0400 (EDT) Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: <62c9ac4d-7a65-f3f0-16aa-b7e035a78b07@mtcc.com> References: <20190310142144.GA6710@gsp.org> <88272721-9A02-4D38-A237-86374E6D51E6@cable.comcast.com> <62c9ac4d-7a65-f3f0-16aa-b7e035a78b07@mtcc.com> Message-ID: On Mon, 11 Mar 2019, Michael Thomas wrote: > It seems to me that it would be much better to use the standards we already > have to deliver text, voice and video, and just make it a requirement that > some list of devices must be able to listen for these announcements and act > accordingly. It's not like compositing video or muting one audio stream in > favor of the other is rocket science. Ecosystem owners control what their smart devices do (and won't do). The major smart device ecosystem owners don't allow other parties to control their devices without going through ecosystem owner controlled APIs. Amazon controls what echo speakers and fire tv do with alexa. Apple controls what apple tv and apple homepod speakers do with siri. Google controls what google home speakers do with google assistant. I think you are correct, Netflix and Hulu are at the wrong layer. Netflix and Hulu don't control the smart TVs and smart speakers ecosystems used to present their content. Amazon Alexa, Apple Siri and Google Assistant do. Yes, there are add-on apps for weather and news, but without support by the ecosystem owner in the base operating system, add-on apps can't interrupt other Apps. I understand why ecosystem owners wouldn't want to give third-party Apps an API to interrupt other Apps. Ecosystem owners could include emergency alert functionality controlled as part of the base operating system/intelligent assistant, preserving whatever UX it wants without allowing other third-parties to interrupt. Apple has announced its going to announce something on March 26. I wonder if any reporters will ask if the new Apple TV supports emergency alerts? From sean at donelan.com Tue Mar 12 04:06:21 2019 From: sean at donelan.com (Sean Donelan) Date: Tue, 12 Mar 2019 00:06:21 -0400 (EDT) Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: <20190310142144.GA6710@gsp.org> <88272721-9A02-4D38-A237-86374E6D51E6@cable.comcast.com> <62c9ac4d-7a65-f3f0-16aa-b7e035a78b07@mtcc.com> Message-ID: On Mon, 11 Mar 2019, Sean Donelan wrote: > Apple has announced its going to announce something on March 26. > > I wonder if any reporters will ask if the new Apple TV supports emergency > alerts? Ugh, typo. March 25 at 10 a.m. PDT Hopefully, Tim Apple will forgive me :-) I still want a reporter to ask Apple about emergency alerts though. From phil.lavin at cloudcall.com Tue Mar 12 07:29:48 2019 From: phil.lavin at cloudcall.com (Phil Lavin) Date: Tue, 12 Mar 2019 07:29:48 +0000 Subject: AS701/Verizon Message-ID: We're seeing consistent +100ms latency increases to Verizon customers in Pennsylvania, during peak business hours for the past couple of weeks. If someone is able to assist, could they please contact me off-list? -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Tue Mar 12 07:45:19 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 12 Mar 2019 00:45:19 -0700 Subject: AS701/Verizon In-Reply-To: References: Message-ID: pennsylvania is largeish, maybe: "To philadelphia customers behind deviceX, Y, Z" or "Pittsburghers behind devices M, N, O" or something else helpful :) On Tue, Mar 12, 2019 at 12:30 AM Phil Lavin wrote: > We’re seeing consistent +100ms latency increases to Verizon customers in > Pennsylvania, during peak business hours for the past couple of weeks. > > > > If someone is able to assist, could they please contact me off-list? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From saku at ytti.fi Tue Mar 12 07:57:52 2019 From: saku at ytti.fi (Saku Ytti) Date: Tue, 12 Mar 2019 09:57:52 +0200 Subject: AS701/Verizon In-Reply-To: References: Message-ID: PSA to people running transit networks. a) During congestion you are not buffering just the exceeding traffic, you will delay every packet in the class for duration of congestion b) Adding buffering does not increase RX rate during persistent congestion, it only increases delay c) Occasional persistent congestion is normal, because how we've modeled economics of transit d) Typical device transit network operates can add >100ms latency on a single link, but you don't want more than 5ms latency on BB link Fix for IOS-XR: class BE bandwidth percent 50 queue-limit 5 ms Fix for Junos: BE { transmit-rate percent 50; buffer-size temporal 5k; } The actual byte value programmed is interface_rate * percent_share * time. If your class is by design out-of-contract, that means your rate is actually higher, which means the programmed buffer byte value results in smaller queueing delay. The configured byte value will only result in configured queueing delay when actual rate == g-rate. The buffers are not large to facilitate buffering single queue for 100ms, the buffers are large to support configurations of large amount of logical interfaces each with large number of queues. If you are configuring just few queues, assumption is that you are dimensoning your buffer sizes. Hopefully this motivates some networks to limit buffer sizes. Thanks! On Tue, Mar 12, 2019 at 9:32 AM Phil Lavin wrote: > > We’re seeing consistent +100ms latency increases to Verizon customers in Pennsylvania, during peak business hours for the past couple of weeks. > > > > If someone is able to assist, could they please contact me off-list? -- ++ytti From phil.lavin at cloudcall.com Tue Mar 12 08:01:46 2019 From: phil.lavin at cloudcall.com (Phil Lavin) Date: Tue, 12 Mar 2019 08:01:46 +0000 Subject: AS701/Verizon In-Reply-To: References: Message-ID: > or something else helpful :) Here's traceroutes, for those interested. Times are UTC. The issue is present to Verizon customers in both Pittsburgh and BlueBell. I don't have any other PA Verizon customers to reference against, though all of our other Verizon customers outside of PA look fine. phil at debian:~$ mtr -zwc1 108.16.123.123 Start: Tue Mar 12 00:19:43 2019 HOST: debian Loss% Snt Last Avg Best Wrst StDev 1. AS32334 192.30.36.123 0.0% 1 2.7 2.7 2.7 2.7 0.0 2. AS??? 10.11.11.1 0.0% 1 2.6 2.6 2.6 2.6 0.0 3. AS2914 129.250.199.37 0.0% 1 1.5 1.5 1.5 1.5 0.0 4. AS2914 ae-6.r24.nycmny01.us.bb.gin.ntt.net 0.0% 1 9.4 9.4 9.4 9.4 0.0 5. AS2914 ae-1.r08.nycmny01.us.bb.gin.ntt.net 0.0% 1 6.6 6.6 6.6 6.6 0.0 6. AS701 et-7-0-5.BR3.NYC4.ALTER.NET 0.0% 1 8.5 8.5 8.5 8.5 0.0 7. AS??? ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 8. AS701 ae203-0.PHLAPA-VFTTP-302.verizon-gni.net 0.0% 1 137.2 137.2 137.2 137.2 0.0 9. AS701 static-108-16-123-123.phlapa.fios.verizon.net 0.0% 1 118.4 118.4 118.4 118.4 0.0 phil at debian:~$ mtr -zwc1 108.16.123.123 Start: Tue Mar 12 07:48:25 2019 HOST: debian Loss% Snt Last Avg Best Wrst StDev 1. AS32334 192.30.36.123 0.0% 1 2.7 2.7 2.7 2.7 0.0 2. AS??? 10.11.11.1 0.0% 1 1.0 1.0 1.0 1.0 0.0 3. AS2914 129.250.199.37 0.0% 1 2.9 2.9 2.9 2.9 0.0 4. AS2914 ae-6.r24.nycmny01.us.bb.gin.ntt.net 0.0% 1 7.2 7.2 7.2 7.2 0.0 5. AS2914 ae-1.r08.nycmny01.us.bb.gin.ntt.net 0.0% 1 9.1 9.1 9.1 9.1 0.0 6. AS701 et-7-0-5.BR3.NYC4.ALTER.NET 0.0% 1 7.1 7.1 7.1 7.1 0.0 7. AS??? ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 8. AS701 ae203-0.PHLAPA-VFTTP-302.verizon-gni.net 0.0% 1 14.7 14.7 14.7 14.7 0.0 9. AS701 static-108-16-123-123.phlapa.fios.verizon.net 0.0% 1 17.8 17.8 17.8 17.8 0.0 Smokeping graph at https://ibb.co/g4VQR8k From morrowc.lists at gmail.com Tue Mar 12 08:17:47 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 12 Mar 2019 01:17:47 -0700 Subject: AS701/Verizon In-Reply-To: References: Message-ID: On Tue, Mar 12, 2019 at 1:01 AM Phil Lavin wrote: > > or something else helpful :) > > Here's traceroutes, for those interested. Times are UTC. The issue is > present to Verizon customers in both Pittsburgh and BlueBell. I don't have > any other PA Verizon customers to reference against, though all of our > other Verizon customers outside of PA look fine. > > phil at debian:~$ mtr -zwc1 108.16.123.123 > Start: Tue Mar 12 00:19:43 2019 > HOST: debian Loss% Snt > Last Avg Best Wrst StDev > 1. AS32334 192.30.36.123 0.0% 1 > 2.7 2.7 2.7 2.7 0.0 > 2. AS??? 10.11.11.1 0.0% 1 > 2.6 2.6 2.6 2.6 0.0 > 3. AS2914 129.250.199.37 0.0% 1 > 1.5 1.5 1.5 1.5 0.0 > 4. AS2914 ae-6.r24.nycmny01.us.bb.gin.ntt.net 0.0% 1 > 9.4 9.4 9.4 9.4 0.0 > 5. AS2914 ae-1.r08.nycmny01.us.bb.gin.ntt.net 0.0% 1 > 6.6 6.6 6.6 6.6 0.0 > 6. AS701 et-7-0-5.BR3.NYC4.ALTER.NET 0.0% 1 > 8.5 8.5 8.5 8.5 0.0 > 7. AS??? ??? 100.0 1 > 0.0 0.0 0.0 0.0 0.0 > 8. AS701 ae203-0.PHLAPA-VFTTP-302.verizon-gni.net 0.0% 1 > 137.2 137.2 137.2 137.2 0.0 > 9. AS701 static-108-16-123-123.phlapa.fios.verizon.net 0.0% 1 > 118.4 118.4 118.4 118.4 0.0 > > phil at debian:~$ mtr -zwc1 108.16.123.123 > Start: Tue Mar 12 07:48:25 2019 > HOST: debian Loss% Snt > Last Avg Best Wrst StDev > 1. AS32334 192.30.36.123 0.0% 1 > 2.7 2.7 2.7 2.7 0.0 > 2. AS??? 10.11.11.1 0.0% 1 > 1.0 1.0 1.0 1.0 0.0 > 3. AS2914 129.250.199.37 0.0% 1 > 2.9 2.9 2.9 2.9 0.0 > 4. AS2914 ae-6.r24.nycmny01.us.bb.gin.ntt.net 0.0% 1 > 7.2 7.2 7.2 7.2 0.0 > 5. AS2914 ae-1.r08.nycmny01.us.bb.gin.ntt.net 0.0% 1 > 9.1 9.1 9.1 9.1 0.0 > 6. AS701 et-7-0-5.BR3.NYC4.ALTER.NET 0.0% 1 > 7.1 7.1 7.1 7.1 0.0 > 7. AS??? ??? 100.0 1 > 0.0 0.0 0.0 0.0 0.0 > 8. AS701 ae203-0.PHLAPA-VFTTP-302.verizon-gni.net 0.0% 1 > 14.7 14.7 14.7 14.7 0.0 > 9. AS701 static-108-16-123-123.phlapa.fios.verizon.net 0.0% 1 > 17.8 17.8 17.8 17.8 0.0 > > I'm not in philly, but from IAD area the path back is via HE.net.it seems quick enough from IAD, but as a data point PHL may head back via NYC or it may go through IAD and HE.net. > Smokeping graph at https://ibb.co/g4VQR8k > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adamv0025 at netconsultings.com Tue Mar 12 11:47:52 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Tue, 12 Mar 2019 11:47:52 -0000 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: References: <20190227100105.GF19597@arundodonax.nekodune.net> <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> Message-ID: <00fb01d4d8c9$70f72c20$52e58460$@netconsultings.com> > Töma Gavrichenkov > Sent: Friday, March 8, 2019 5:07 PM > > On Fri, Mar 8, 2019 at 7:48 PM Saku Ytti wrote: > > Why do you think it would be expensive? It's cheaper than how ECMP is > > done for L3 keys, because you just read the flow label and not > > calculate any hash. > > The most honest answer would be: I have no idea. That's just what I've seen, > rather briefly though, as we weren't going to investigate that part at the > time. > > It's been a while since then, and maybe there was a mistake on our side (at > least within a perfectly academic context I must assume that there was, as > there was no peer review — we were not in academy after all!), but I'm still > inclined to, first, see the benchmarks of any proposed piece of hardware > that's promising you ECMP with flow labels, second, make any statements > about the latter. > We did this exact testing a while back on Juniper 2nd and 3rd gen PFEs. The results showed it doesn't matter a tiny bit whether you do 5-tuple hash or use flow label. So the bottom line is on modern NPUs it doesn't really matter. adam From saku at ytti.fi Tue Mar 12 11:53:46 2019 From: saku at ytti.fi (Saku Ytti) Date: Tue, 12 Mar 2019 13:53:46 +0200 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: <00fb01d4d8c9$70f72c20$52e58460$@netconsultings.com> References: <20190227100105.GF19597@arundodonax.nekodune.net> <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> <00fb01d4d8c9$70f72c20$52e58460$@netconsultings.com> Message-ID: Hey Adam, > We did this exact testing a while back on Juniper 2nd and 3rd gen PFEs. > The results showed it doesn't matter a tiny bit whether you do 5-tuple hash or use flow label. > So the bottom line is on modern NPUs it doesn't really matter. Does PFE mean PE or Trio? What exactly did you test? I don't see way to disable L3+L4 keys and enable flow_label. Doing flow_label + sip + dip + sport + dport indeed would be pretty almost same cost as sip + dip + spot + dport, the cost difference will be very marginal. Doing flow_label or sip+sip+sport+dport the cost difference is non-marginal, if that actually is true for any specific implementation is separate matter. -- ++ytti From adamv0025 at netconsultings.com Tue Mar 12 11:58:30 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Tue, 12 Mar 2019 11:58:30 -0000 Subject: AS701/Verizon In-Reply-To: References: Message-ID: <00fe01d4d8ca$ed184090$c748c1b0$@netconsultings.com> > From: NANOG On Behalf Of Saku Ytti > Sent: Tuesday, March 12, 2019 7:58 AM > > PSA to people running transit networks. > > a) During congestion you are not buffering just the exceeding traffic, you will > delay every packet in the class for duration of congestion > b) Adding buffering does not increase RX rate during persistent congestion, it > only increases delay > c) Occasional persistent congestion is normal, because how we've modeled > economics of transit > d) Typical device transit network operates can add >100ms latency on a single > link, but you don't want more than 5ms latency on BB link > > Fix for IOS-XR: > class BE > bandwidth percent 50 > queue-limit 5 ms > > Fix for Junos: > BE { > transmit-rate percent 50; > buffer-size temporal 5k; > } > > > The actual byte value programmed is interface_rate * percent_share * time. > If your class is by design out-of-contract, that means your rate is actually > higher, which means the programmed buffer byte value results in smaller > queueing delay. The configured byte value will only result in configured > queueing delay when actual rate == g-rate. > > The buffers are not large to facilitate buffering single queue for 100ms, the > buffers are large to support configurations of large amount of logical > interfaces each with large number of queues. If you are configuring just few > queues, assumption is that you are dimensoning your buffer sizes. > > Hopefully this motivates some networks to limit buffer sizes. > > Thanks! > +1 to that. The overall system works so much better if the network nodes don't interfere and instead report the actual network conditions accurately and in a timely fashion to the end hosts -i.e. by inducing drops as and when they occur. There are a number of papers on this topic btw.. adam From jayb at att.com Tue Mar 12 13:26:57 2019 From: jayb at att.com (Jay Borkenhagen) Date: Tue, 12 Mar 2019 09:26:57 -0400 Subject: Analysing traffic in context of rejecting RPKI invalids using pmacct In-Reply-To: References: <20190212181554.GB36142@vurt.meerval.net> Message-ID: <23687.45985.555430.436718@oz.mt.att.com> On 12-March-2019, Steve Meuse writes: > > > > ps. Dear Kentik & Deepfield, please copy+paste this feature! We'll > > happily share development notes with you, you can even look at pmacct's > > source code for inspiration. :-) > > Thanks Job, I just wanted to reach back out to you and the NANOG community > that we've implemented this feature. Currently Kentik can match flow data > with the following validation state: > > - VALID = Prefix fits in ROA, and ROA ASN and Prefix Origin Match > - UNKNOWN = we haven't found any matching ROA > - INVALID - ASN mismatch = BGP prefix fits in the ROA prefix's length BUT > the ROA ASN differs from the Prefix Origin ASN > - INVALID - Prefix length out of bounds = the BGP prefix doesn't have an > ROA with large enough Max-Length to refer to > - INVALID - ASN 0 specified = there is a matching ROA w/ the right > max-length but the ASN associated w/ it is 0 (explicit invalid) > Hi Steve, Thanks for the update, but based on that description I'm not certain that you implemented the same thing that pmacct built, which IMO is what is needed by those considering deploying a drop-invalids policy. (Perhaps you omitted mentioning that ability in your description but included it in your implementation.) Citing from Job's description: > Pmacct implemented Origin Validation in a cute way: it separates out > RPKI invalid BGP announcements into two categories: > > a) "invalid with no overlapping or alternative route" > (aka will be blackholed if 'invalid == reject') > > b) "invalid but an overlapping unknown/valid announcement also > exists" > (end-to-end connectivity can still work). > Networks contemplating Origin Validation need to be able to predict how their traffic with the rest of the Internet would change after deploying a drop-invalid-routes policy. When we (as7018) were preparing to begin dropping invalid routes received from peers earlier this year, that is exactly the kind of analysis we did. In our case we rolled our own with a two-pass process: we first found all the traffic to/from invalid routes by a bgp community we gave them, then outside of our flow analysis tool we further filtered the traffic for invalid routes which were covered by less-specific not-invalid routes. What remained was the traffic we would lose once invalid routes were dropped. Had the pmacct capability existed at that time, we would have used it. Regarding the ability to further partition invalid traffic into the three sub-categories you mentioned: that would not have been of interest to us at the time we did our analysis, and it's not clear to me how it would be useful to a network as it contemplates adopting a drop-invalids policy. In this context, the reason a route is invalid is not important; what is important is whether it is covered by a non-invalid route or not. Thanks. Jay B. From sean at donelan.com Tue Mar 12 15:19:52 2019 From: sean at donelan.com (Sean Donelan) Date: Tue, 12 Mar 2019 11:19:52 -0400 (EDT) Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: <88e5e77c-ac89-9b88-2559-437ceadca00a@cymru.com> References: <88e5e77c-ac89-9b88-2559-437ceadca00a@cymru.com> Message-ID: On Mon, 11 Mar 2019, Scott Fisher wrote: > It would be nice if someone from the E911 space could add their 2cents > on this. Anyone from Intrado/West-Corp on the list? See the FCC Electronic Comment Filing System for 911 Governance and Accountability (PS Docket No. 14-193) and Improving 911 Reliability (PS Docket No. 13-75). https://www.fcc.gov/ecfs/ From Jason_Livingood at comcast.com Tue Mar 12 16:49:49 2019 From: Jason_Livingood at comcast.com (Livingood, Jason) Date: Tue, 12 Mar 2019 16:49:49 +0000 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: <20190310142144.GA6710@gsp.org> <88272721-9A02-4D38-A237-86374E6D51E6@cable.comcast.com> <62c9ac4d-7a65-f3f0-16aa-b7e035a78b07@mtcc.com> Message-ID: <48A3E9E2-943A-4ECF-BCE1-37093AF46ECC@cable.comcast.com> On 3/11/19, 11:26 PM, "NANOG on behalf of Sean Donelan" wrote: I think you are correct, Netflix and Hulu are at the wrong layer. Netflix and Hulu don't control the smart TVs and smart speakers ecosystems used to present their content. Amazon Alexa, Apple Siri and Google Assistant do. [JL] Going onto to hardware like a smart TV will still result in lower penetration that if you went to the app layer that is where attention time is spent (which may be on a laptop or non-cellular-connected tablet or a game console). From adamv0025 at netconsultings.com Tue Mar 12 17:55:10 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Tue, 12 Mar 2019 17:55:10 -0000 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: References: <20190227100105.GF19597@arundodonax.nekodune.net> <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> <00fb01d4d8c9$70f72c20$52e58460$@netconsultings.com> Message-ID: <012901d4d8fc$c0c87d70$42597850$@netconsultings.com> Hey Saku, > From: Saku Ytti > Sent: Tuesday, March 12, 2019 11:54 AM > > Hey Adam, > > > We did this exact testing a while back on Juniper 2nd and 3rd gen PFEs. > > The results showed it doesn't matter a tiny bit whether you do 5-tuple hash > or use flow label. > > So the bottom line is on modern NPUs it doesn't really matter. > > Does PFE mean PE or Trio? What exactly did you test? I don't see way to > disable L3+L4 keys and enable flow_label. > This was on Trio and sorry I should have clarified we did test with default L3+L4 keys on MPLS labelled packets -default in Junos (as baseline). And then repeated the test using flow labels -which forced Trio to ignore the L3+L4 keys and act solely on flow label. PPS performance wise we couldn’t really tell the difference (was in the noise). adam From saku at ytti.fi Tue Mar 12 18:00:30 2019 From: saku at ytti.fi (Saku Ytti) Date: Tue, 12 Mar 2019 20:00:30 +0200 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: <012901d4d8fc$c0c87d70$42597850$@netconsultings.com> References: <20190227100105.GF19597@arundodonax.nekodune.net> <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> <00fb01d4d8c9$70f72c20$52e58460$@netconsultings.com> <012901d4d8fc$c0c87d70$42597850$@netconsultings.com> Message-ID: On Tue, Mar 12, 2019 at 7:55 PM wrote: > This was on Trio and sorry I should have clarified we did test with default L3+L4 keys on MPLS labelled packets -default in Junos (as baseline). > And then repeated the test using flow labels -which forced Trio to ignore the L3+L4 keys and act solely on flow label. > PPS performance wise we couldn’t really tell the difference (was in the noise). Are you sure we are talking about same thing. This thread is about 20bit IPv6 header Flow Label. I feel like you're talking about FAT pseudowires? By default JNPR will in pseudowire transit look for IP keys, with or without FAT. Optionally it can look even with existence of CW. You need to specifically ask it not to look for IP keys in pseudowires or add CW (and not explicitly tell it to look). -- ++ytti From adamv0025 at netconsultings.com Tue Mar 12 18:09:32 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Tue, 12 Mar 2019 18:09:32 -0000 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: References: <20190227100105.GF19597@arundodonax.nekodune.net> <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> <00fb01d4d8c9$70f72c20$52e58460$@netconsultings.com> <012901d4d8fc$c0c87d70$42597850$@netconsultings.com> Message-ID: <012d01d4d8fe$c1dc2570$45947050$@netconsultings.com> > From: Saku Ytti > Sent: Tuesday, March 12, 2019 6:01 PM > > On Tue, Mar 12, 2019 at 7:55 PM wrote: > > > This was on Trio and sorry I should have clarified we did test with default > L3+L4 keys on MPLS labelled packets -default in Junos (as baseline). > > And then repeated the test using flow labels -which forced Trio to ignore > the L3+L4 keys and act solely on flow label. > > PPS performance wise we couldn’t really tell the difference (was in the > noise). > > Are you sure we are talking about same thing. This thread is about 20bit IPv6 > header Flow Label. I feel like you're talking about FAT pseudowires? > Yes right, but the lookup principle is the same either you look at IPv6 flow label or you look at the Entropy label. > By default JNPR will in pseudowire transit look for IP keys, with or without > FAT. Optionally it can look even with existence of CW. You need to > specifically ask it not to look for IP keys in pseudowires or add CW (and not > explicitly tell it to look). > We didn't use FAT PWs, but rather entropy labels for VPNv4 traffic. adam From saku at ytti.fi Tue Mar 12 18:14:06 2019 From: saku at ytti.fi (Saku Ytti) Date: Tue, 12 Mar 2019 20:14:06 +0200 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: <012d01d4d8fe$c1dc2570$45947050$@netconsultings.com> References: <20190227100105.GF19597@arundodonax.nekodune.net> <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> <00fb01d4d8c9$70f72c20$52e58460$@netconsultings.com> <012901d4d8fc$c0c87d70$42597850$@netconsultings.com> <012d01d4d8fe$c1dc2570$45947050$@netconsultings.com> Message-ID: On Tue, Mar 12, 2019 at 8:09 PM wrote: > Yes right, but the lookup principle is the same either you look at IPv6 flow label or you look at the Entropy label. Correct, FAT, Entropy and IPv6 Flow Label are all in principle same, a way for source node to communicates what constitutes a flow. And in every case, there is no guarantee implementation has any performance gains, as implementation may choose to do normal flow speculation in addition of doing the fast thing. -- ++ytti From mike at mtcc.com Tue Mar 12 18:56:46 2019 From: mike at mtcc.com (Michael Thomas) Date: Tue, 12 Mar 2019 11:56:46 -0700 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: <20190310142144.GA6710@gsp.org> <88272721-9A02-4D38-A237-86374E6D51E6@cable.comcast.com> <62c9ac4d-7a65-f3f0-16aa-b7e035a78b07@mtcc.com> Message-ID: On 3/11/19 8:24 PM, Sean Donelan wrote: > On Mon, 11 Mar 2019, Michael Thomas wrote: >> It seems to me that it would be much better to use the standards we >> already have to deliver text, voice and video, and just make it a >> requirement that some list of devices must be able to listen for >> these announcements and act accordingly. It's not like compositing >> video or muting one audio stream in favor of the other is rocket >> science. > > Ecosystem owners control what their smart devices do (and won't do). > The major smart device ecosystem owners don't allow other parties to > control their devices without going through ecosystem owner controlled > APIs. > > Amazon controls what echo speakers and fire tv do with alexa. > > Apple controls what apple tv and apple homepod speakers do with siri. > > Google controls what google home speakers do with google assistant. > > > I think you are correct, Netflix and Hulu are at the wrong layer. > Netflix and Hulu don't control the smart TVs and smart speakers > ecosystems used to present their content.  Amazon Alexa, Apple Siri > and Google Assistant do. > > Yes, there are add-on apps for weather and news, but without support > by the ecosystem owner in the base operating system, add-on apps can't > interrupt other Apps. I understand why ecosystem owners wouldn't want > to give third-party Apps an API to interrupt other Apps. Ecosystem > owners could include emergency alert functionality controlled as part > of the base operating system/intelligent assistant, preserving > whatever UX it wants without allowing other third-parties to interrupt. > Yes, that's exactly my point: it should just be a requirement of the hardware platform to implement this. Just like e911. Enumerating the types of devices that are required to implement this is way easier than enumerating the types of apps/sites that need to implement it. All the government needs to do is set up the server infrastructure to source the alerts. Mike From sean at donelan.com Tue Mar 12 19:16:58 2019 From: sean at donelan.com (Sean Donelan) Date: Tue, 12 Mar 2019 15:16:58 -0400 (EDT) Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: <20190310142144.GA6710@gsp.org> <88272721-9A02-4D38-A237-86374E6D51E6@cable.comcast.com> <62c9ac4d-7a65-f3f0-16aa-b7e035a78b07@mtcc.com> Message-ID: On Tue, 12 Mar 2019, Michael Thomas wrote: > All the government needs to do is set up the server infrastructure to > source the alerts. In the U.S., the IPAWS server infrastructure was set up in 2012. Akamai servers on many ISP networks carry emergency alert CAP messages. However, the smart device ecosystem owners have so far refused to participate. Amazon and Google have explicitly told me no. They have no plans to add support for emergency alerts to Amazon Alexa or Google Assistant. Apple won't comment, but so far doesn't appear to have any plans for emergency alerts on Apple TV or Homepod. Microsoft Cortana is pretty much irrelevant now. There were a few other intelligent assistants at CES 2019, but I don't know of others with significant marketshare. Android and iOS on cell phones added emergency alerts only after laws and regulations required cellular carriers to support emergency alerts. Yes, there are third-part Apps with emergency alerts. They typically have less than 15% subscription rates. And require the end-user to explicitly check/ask the smart device about the weather or news or alerts. Without support from the smart device ecosystem owners (Amazon, Apple, Google), even third-part apps can't proactively alert people. Reporters (and legislators) shouldn't be asking Netflix and Hulu about emergency alerts. They should be asking the smart device ecosystem controllers: Amazon, Apple and Google. From bill at herrin.us Tue Mar 12 20:45:23 2019 From: bill at herrin.us (William Herrin) Date: Tue, 12 Mar 2019 13:45:23 -0700 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: <20190310142144.GA6710@gsp.org> <88272721-9A02-4D38-A237-86374E6D51E6@cable.comcast.com> <62c9ac4d-7a65-f3f0-16aa-b7e035a78b07@mtcc.com> Message-ID: On Tue, Mar 12, 2019 at 11:57 AM Michael Thomas wrote: > Yes, that's exactly my point: it should just be a requirement of the > hardware platform to implement this. Just like e911. Enumerating the > types of devices that are required to implement this is way easier than > enumerating the types of apps/sites that need to implement it. All the > government needs to do is set up the server infrastructure to source the > alerts. Hi Mike, In many cases, only the foreground app has a clear understanding of the state of the screen. Not the OS and definitely not the hardware platform. I'd be super pissed if I died in Overwatch because the BIOS tried to take over the screen to display an amber alert. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at mtcc.com Tue Mar 12 20:53:31 2019 From: mike at mtcc.com (Michael Thomas) Date: Tue, 12 Mar 2019 13:53:31 -0700 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: <20190310142144.GA6710@gsp.org> <88272721-9A02-4D38-A237-86374E6D51E6@cable.comcast.com> <62c9ac4d-7a65-f3f0-16aa-b7e035a78b07@mtcc.com> Message-ID: On 3/12/19 1:45 PM, William Herrin wrote: > On Tue, Mar 12, 2019 at 11:57 AM Michael Thomas > wrote: > > Yes, that's exactly my point: it should just be a requirement of the > > hardware platform to implement this. Just like e911. Enumerating the > > types of devices that are required to implement this is way easier than > > enumerating the types of apps/sites that need to implement it. All the > > government needs to do is set up the server infrastructure to source the > > alerts. > > Hi Mike, > > In many cases, only the foreground app has a clear understanding of > the state of the screen. Not the OS and definitely not the hardware > platform. I'd be super pissed if I died in Overwatch because the BIOS > tried to take over the screen to display an amber alert. But if you're about to be incinerated in real life -- Paradise -- you want the alert. We're not talking BIOS here, we're just talking a normal IP client program that has elevated privileges to take over the outputs as necessary. And, of course, we want to be able to prioritize things like Amber alerts to zero when we're sitting at home watching tv. Really, this is nothing more than Biff over IP. Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Tue Mar 12 21:04:33 2019 From: sean at donelan.com (Sean Donelan) Date: Tue, 12 Mar 2019 17:04:33 -0400 (EDT) Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: <48A3E9E2-943A-4ECF-BCE1-37093AF46ECC@cable.comcast.com> References: <20190310142144.GA6710@gsp.org> <88272721-9A02-4D38-A237-86374E6D51E6@cable.comcast.com> <62c9ac4d-7a65-f3f0-16aa-b7e035a78b07@mtcc.com> <48A3E9E2-943A-4ECF-BCE1-37093AF46ECC@cable.comcast.com> Message-ID: On Tue, 12 Mar 2019, Livingood, Jason wrote: > [JL] Going onto to hardware like a smart TV will still result in lower >penetration that if you went to the app layer that is where attention >time is spent (which may be on a laptop or non-cellular-connected tablet >or a game console). That's the problem with rules of thumb. You have eight other fingers. Recognizing how long it takes to change things, I'm prognosticating what things might be like 5+ years in the future, i.e., CES 2024. I'm focused on devices with mediation layers, i.e. the intelligent assistants, for a reason. Alert localization and user opt-outs should be as close to the end-user as technology allows. You need the mediation layer to do that per user/per household. Emergency alerts localized at the cable head-end or cell tower are too overbroad, but maybe as specific as old technology can support for backward compatibility. Having mediation layer is also important for multi-tasking. I often have Netflix, a web browser and email open at the same time on my computer. You don't want to interrupt the local news stream, CNN or the Weather Channel already covering a disaster with a non-local alert. If the alert is always embedded in the content, that's difficult to do. For example, AT&T U-Verse doesn't record emergency on the DVR. When you play back DVR recorded programming, you don't get old recorded emergency alerts. If new alerts happen while watching the U-Verse DVR, then you would get those new alerts. Analog content and dumb devices may not be able to support that. So there will always be some exceptions. See rule of thumbs :-) Likewise, I'm not suggesting every possible electronic device needs emergency alerts. I'm focused on things that people typically interact with for entertainment and information, such as smart TVs and smart speakers. Not light bulbs, thermostats or smoke detectors. From valdis.kletnieks at vt.edu Tue Mar 12 21:50:37 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 12 Mar 2019 17:50:37 -0400 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: <20190310142144.GA6710@gsp.org> <88272721-9A02-4D38-A237-86374E6D51E6@cable.comcast.com> <62c9ac4d-7a65-f3f0-16aa-b7e035a78b07@mtcc.com> Message-ID: <6250.1552427437@turing-police> On Tue, 12 Mar 2019 13:45:23 -0700, William Herrin said: > In many cases, only the foreground app has a clear understanding of the > state of the screen. Not the OS and definitely not the hardware platform. > I'd be super pissed if I died in Overwatch because the BIOS tried to take > over the screen to display an amber alert. Would you be super pissed if you died for real because Overwatch suppressed a tornado or other severe weather alert relevant to your location? Serious question here. Seems like the amber alert problem is a configuration issue - just tell your device's system configuration manager to not interrupt with amber alerts, just post a small "there is an alert" status of some sort. My Android-based phone tells me in a little thing in the top bar that I have 2 Google News items, a missed phone call, and some Skype activity - it shouldn't be difficult to add "3 weather alerts, 2 Amber alerts and a partridge in a pear tree" to it. And doing a similar thing for any device smart enough to play Overwatch shouldn't be a big technical hurdle in 2019. From sean at donelan.com Tue Mar 12 21:56:59 2019 From: sean at donelan.com (Sean Donelan) Date: Tue, 12 Mar 2019 17:56:59 -0400 (EDT) Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: <48A3E9E2-943A-4ECF-BCE1-37093AF46ECC@cable.comcast.com> References: <20190310142144.GA6710@gsp.org> <88272721-9A02-4D38-A237-86374E6D51E6@cable.comcast.com> <62c9ac4d-7a65-f3f0-16aa-b7e035a78b07@mtcc.com> <48A3E9E2-943A-4ECF-BCE1-37093AF46ECC@cable.comcast.com> Message-ID: > [JL] Going onto to hardware like a smart TV will still result in lower >penetration that if you went to the app layer that is where attention >time is spent (which may be on a laptop or non-cellular-connected tablet >or a game console). I should also mention the desktop Windows and Linux operating systems don't lock down their APIs like the smart device ecosystem owners. That makes it easier to create an emergency alert app on Windows or Linux, which can interrupt foreground programs and use sound/video drivers. There is also the downside that ill-behaved applications can be very disruptive on Windows and Linux. As a midnight/skunkworks project a wrote a proof-of-concept emergency alert app on Windows. Partly to learn Windows 10 Apps, Visual Studio and C-sharp; but also to try out NOAA's and FEMA's alert feeds. As a proof-of-concept the app worked, but not ready for commercial use. But using a desktop PC is not the same as a smart TV or smart speaker to anyone, other than a nerd. Not spouse-approved for use in any other room in the house :-) I spent about a year (skunkworks time, so not full-time) trying to figure out how to make emergency alerts work on Amazon Alexa and maybe 6-months on Google Assistant. Never could get past the virtual front-door at Apple. There doesn't seem to be a supported way to do it, and the smart device ecosystem owners seemed to oppose any attempt to bypass their control. From surfer at mauigateway.com Tue Mar 12 22:19:45 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 12 Mar 2019 15:19:45 -0700 Subject: Should Netflix and Hulu give you emergency alerts? Message-ID: <20190312151945.72B2B1E6@m0117457.ppops.net> --- mike at mtcc.com wrote: From: Michael Thomas But if you're about to be incinerated in real life -- Paradise -- you want the alert. -------------------------------------- So you can toss your children in the storm drain? http://www.hawaiinewsnow.com/story/37259815/biggest-fright-of-my-life-many-scramble-for-shelter-after-false-alarm-missile-warning "One video on social media showed an adult putting children into a storm drain; other social media images showed residents huddling in bathtubs." Or like me and this guy, just stay out in the ocean and watch it all happen... "We didn't know what to do except paddle [our surfboards] in and do as best we could. We debated whether we should just stay out" :) scott From clayton at MNSi.Net Tue Mar 12 22:27:26 2019 From: clayton at MNSi.Net (Clayton Zekelman) Date: Tue, 12 Mar 2019 18:27:26 -0400 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: <20190312151945.72B2B1E6@m0117457.ppops.net> References: <20190312151945.72B2B1E6@m0117457.ppops.net> Message-ID: <1552429650_224515@surgemail.mnsi.net> It's very fortunate that nobody was seriously injured after that total failure of the process. The people who run this stuff need to understand that a false alert can be very dangerous. At 06:19 PM 12/03/2019, Scott Weeks wrote: >--- mike at mtcc.com wrote: >From: Michael Thomas > >But if you're about to be incinerated in real >life -- Paradise -- you want the alert. >-------------------------------------- > >So you can toss your children in the storm >drain? > >http://www.hawaiinewsnow.com/story/37259815/biggest-fright-of-my-life-many-scramble-for-shelter-after-false-alarm-missile-warning > >"One video on social media showed an adult >putting children into a storm drain; other >social media images showed residents >huddling in bathtubs." > > >Or like me and this guy, just stay out in >the ocean and watch it all happen... > >"We didn't know what to do except paddle >[our surfboards] in and do as best we >could. We debated whether we should just >stay out" > >:) >scott -- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From beecher at beecher.cc Tue Mar 12 22:35:39 2019 From: beecher at beecher.cc (Tom Beecher) Date: Tue, 12 Mar 2019 18:35:39 -0400 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: <20190310142144.GA6710@gsp.org> <88272721-9A02-4D38-A237-86374E6D51E6@cable.comcast.com> <62c9ac4d-7a65-f3f0-16aa-b7e035a78b07@mtcc.com> Message-ID: To be fair, I've used the rogue BIOS excuse in quite a few Overwatch matches, and nobody buys it. So even if it did happen at this point, nobody would believe you. On Tue, Mar 12, 2019 at 4:47 PM William Herrin wrote: > On Tue, Mar 12, 2019 at 11:57 AM Michael Thomas wrote: > > Yes, that's exactly my point: it should just be a requirement of the > > hardware platform to implement this. Just like e911. Enumerating the > > types of devices that are required to implement this is way easier than > > enumerating the types of apps/sites that need to implement it. All the > > government needs to do is set up the server infrastructure to source the > > alerts. > > Hi Mike, > > In many cases, only the foreground app has a clear understanding of the > state of the screen. Not the OS and definitely not the hardware platform. > I'd be super pissed if I died in Overwatch because the BIOS tried to take > over the screen to display an amber alert. > > Regards, > Bill Herrin > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Tue Mar 12 22:39:08 2019 From: bill at herrin.us (William Herrin) Date: Tue, 12 Mar 2019 15:39:08 -0700 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: <6250.1552427437@turing-police> References: <20190310142144.GA6710@gsp.org> <88272721-9A02-4D38-A237-86374E6D51E6@cable.comcast.com> <62c9ac4d-7a65-f3f0-16aa-b7e035a78b07@mtcc.com> <6250.1552427437@turing-police> Message-ID: On Tue, Mar 12, 2019 at 2:50 PM wrote: > On Tue, 12 Mar 2019 13:45:23 -0700, William Herrin said: > > In many cases, only the foreground app has a clear understanding of the > > state of the screen. Not the OS and definitely not the hardware platform. > > I'd be super pissed if I died in Overwatch because the BIOS tried to take > > over the screen to display an amber alert. > > Would you be super pissed if you died for real because Overwatch suppressed a > tornado or other severe weather alert relevant to your location? Serious > question here. I'd prefer if my computer's BIOS didn't talk to the network at all, that being far more likely to open a path for malware than to save me from a tornado. Some things just have "bad idea" written all over them. Serious answer. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at mtcc.com Tue Mar 12 23:03:57 2019 From: mike at mtcc.com (Michael Thomas) Date: Tue, 12 Mar 2019 16:03:57 -0700 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: <20190310142144.GA6710@gsp.org> <88272721-9A02-4D38-A237-86374E6D51E6@cable.comcast.com> <62c9ac4d-7a65-f3f0-16aa-b7e035a78b07@mtcc.com> <6250.1552427437@turing-police> Message-ID: On 3/12/19 3:39 PM, William Herrin wrote: > > > On Tue, Mar 12, 2019 at 2:50 PM > wrote: > > On Tue, 12 Mar 2019 13:45:23 -0700, William Herrin said: > > > In many cases, only the foreground app has a clear understanding > of the > > > state of the screen. Not the OS and definitely not the hardware > platform. > > > I'd be super pissed if I died in Overwatch because the BIOS tried > to take > > > over the screen to display an amber alert. > > > > Would you be super pissed if you died  for real because Overwatch > suppressed a > > tornado or other severe weather alert relevant to your location?  > Serious > > question here. > > I'd prefer if my computer's BIOS didn't talk to the network at all, > that being far more likely to open a path for malware than to save me > from a tornado. Some things just have "bad idea" written all over > them. Serious answer. > What's with perpetuating the thought that it needs to be in the bios? It's just a normal app on a normal computer like Biff. Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Tue Mar 12 23:25:56 2019 From: sean at donelan.com (Sean Donelan) Date: Tue, 12 Mar 2019 19:25:56 -0400 (EDT) Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: <1552429650_224515@surgemail.mnsi.net> References: <20190312151945.72B2B1E6@m0117457.ppops.net> <1552429650_224515@surgemail.mnsi.net> Message-ID: On Tue, 12 Mar 2019, Clayton Zekelman wrote: > It's very fortunate that nobody was seriously injured after that total > failure of the process. > > The people who run this stuff need to understand that a false alert can be > very dangerous. I agree lack of training and funding for local emergency managers is an ongoing problem. In absolute numbers, more people have died without receiving warnings about an imminent hazard (mostly wildfires and tornados) in each of the last 5 years than have been severely injured after all the false EAS and WEA alerts combined in the last 5 years. Of course, its impossible to attribute cause of death directly due to lack of warning. But local officials being so afraid of issuing warnings means they don't issue them at all, or too late. It doesn't attract as much press attention, but lack of warning has been a recurring issue in local disasters. The National Weather Service does a good job with weather warnings, maybe too much overwarning. On the other hand, if a non-weather hazard such as a wildfire, industrial accident, chemical cloud happens; local emergency managers have little practice or training how to alert the public. Amber alerts are another matter. NCMEC (Amber Alerts) had the largest geographic area, between 100,000 sqkm and 1,000,000 sqkm. This might indicate over-alerting geographic policies, which should be reviewed by Amber Alert coordinators. Total NWS NCMEC State/Local 0 sqkm 0 0 0 0 up to 1 sqkm 0 0 0 0 up to 10 sqkm 0 0 0 0 up to 100 sqkm 0 0 0 0 up to 1,000 sqkm 56 49 0 7 up to 10,000 sqkm 325 193 7 125 up to 100,000 sqkm 88 22 55 11 up to 1,000,000 sqkm 109 1 91 17 up to 10,000,000 sqkm 1 0 0 1 Subtotal 579 265 153 161 There is a reason why people complain about Amber Alerts more than any other type of emergency alert. From sean at donelan.com Tue Mar 12 23:52:48 2019 From: sean at donelan.com (Sean Donelan) Date: Tue, 12 Mar 2019 19:52:48 -0400 (EDT) Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: <20190310142144.GA6710@gsp.org> <88272721-9A02-4D38-A237-86374E6D51E6@cable.comcast.com> <62c9ac4d-7a65-f3f0-16aa-b7e035a78b07@mtcc.com> <6250.1552427437@turing-police> Message-ID: On Tue, 12 Mar 2019, Michael Thomas wrote: > What's with perpetuating the thought that it needs to be in the bios? It's > just a normal app on a normal computer like Biff. I know, after working with network engineers in too many meetings. As I keep repeating, for smart devices (Smart TVs, Smart Speakers) emergency alerts should be part of the intelligent assistant mediation layer (Alexa, Siri, Google Assistant). The specifics vary depending on the smart device ecosystem. Its not part of the hardware bios. Its not part of a third-party app. Its not part of the content stream. Most of the intelligent assistant "smarts" live in a "cloud" in a bunch of data centers. On classic desktop computers, i.e. linux and windows, an emergency alert handler is usually implemented as a daemon or background process. Desktop computers would likely use a thick-client implementation. There are several vendors that sell classic desktop emergency alerting products. If you've ever been inside a Department of Defense facility during one of their active shooter drills, its a bit insane when all the alerting systems go off. I would suggest a different UX for home users. From mike at mtcc.com Wed Mar 13 00:02:49 2019 From: mike at mtcc.com (Michael Thomas) Date: Tue, 12 Mar 2019 17:02:49 -0700 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: <20190310142144.GA6710@gsp.org> <88272721-9A02-4D38-A237-86374E6D51E6@cable.comcast.com> <62c9ac4d-7a65-f3f0-16aa-b7e035a78b07@mtcc.com> <6250.1552427437@turing-police> Message-ID: <1fded73f-aa21-486a-cbac-0d06b9e09f08@mtcc.com> On 3/12/19 4:52 PM, Sean Donelan wrote: > On Tue, 12 Mar 2019, Michael Thomas wrote: >> What's with perpetuating the thought that it needs to be in the bios? >> It's >> just a normal app on a normal computer like Biff. > > I know, after working with network engineers in too many meetings. > > As I keep repeating, for smart devices (Smart TVs, Smart Speakers) > emergency alerts should be part of the intelligent assistant mediation > layer (Alexa, Siri, Google Assistant). The specifics vary depending on > the smart device ecosystem. Its not part of the hardware bios. Its not > part of a third-party app. Its not part of the content stream. Most of > the intelligent assistant "smarts" live in a "cloud" in a bunch of > data centers. > > On classic desktop computers, i.e. linux and windows, an emergency > alert handler is usually implemented as a daemon or background > process. Desktop computers would likely use a thick-client > implementation. There are several vendors that sell classic desktop > emergency alerting products. If you've ever been inside a Department > of Defense facility during one of their active shooter drills, its a > bit insane when all the alerting systems go off. > > I would suggest a different UX for home users. This seriously seems like something that needs formal standardization. Not the exact UI of course, but how it's transported, what the nature of the alert is (= prioritization), the security profile, location information. Jason Livingood chimed in so maybe there's something up that I'm just not aware of, but this strikes me as a pretty ietf-y kind of thing since we already had to deal with e911, calea and all of that for telephony... so there's some clue there. One thing that does bug me a little are the privacy implications (ie, it needs to know approximately where you are). But maybe with everything else we do it's... yet another part of our brave new world. Mike From bill at herrin.us Wed Mar 13 00:34:38 2019 From: bill at herrin.us (William Herrin) Date: Tue, 12 Mar 2019 17:34:38 -0700 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: <20190310142144.GA6710@gsp.org> <88272721-9A02-4D38-A237-86374E6D51E6@cable.comcast.com> <62c9ac4d-7a65-f3f0-16aa-b7e035a78b07@mtcc.com> <6250.1552427437@turing-police> Message-ID: On Tue, Mar 12, 2019 at 4:04 PM Michael Thomas wrote: > On 3/12/19 3:39 PM, William Herrin wrote: >> I'd prefer if my computer's BIOS didn't talk to the network at all, that being >> far more likely to open a path for malware than to save me from a tornado. >> Some things just have "bad idea" written all over them. Serious answer. > > What's with perpetuating the thought that it needs to be in the bios? It's just a normal app on a normal computer like Biff. Answer: On Tue, Mar 12, 2019 at 11:57 AM Michael Thomas wrote: > it should just be a requirement of the > hardware platform to implement this. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at mtcc.com Wed Mar 13 00:43:01 2019 From: mike at mtcc.com (Michael Thomas) Date: Tue, 12 Mar 2019 17:43:01 -0700 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: <20190310142144.GA6710@gsp.org> <88272721-9A02-4D38-A237-86374E6D51E6@cable.comcast.com> <62c9ac4d-7a65-f3f0-16aa-b7e035a78b07@mtcc.com> <6250.1552427437@turing-police> Message-ID: <4c1dbdbf-84ff-e8c1-b30c-7e3060128cbb@mtcc.com> On 3/12/19 5:34 PM, William Herrin wrote: > On Tue, Mar 12, 2019 at 4:04 PM Michael Thomas > wrote: > > On 3/12/19 3:39 PM, William Herrin wrote: > >> I'd prefer if my computer's BIOS didn't talk to the network at all, > that being > >> far more likely to open a path for malware than to save me from a > tornado. > >> Some things just have "bad idea" written all over them. Serious answer. > > > > What's with perpetuating the thought that it needs to be in the > bios? It's just a normal app on a normal computer like Biff. > > Answer: > > On Tue, Mar 12, 2019 at 11:57 AM Michael Thomas > wrote: > > it should just be a requirement of the > > hardware platform to implement this. > Oh, I meant like Android or IOS. or Ubuntu disto or... And that it's only required on certain hardware platforms, ie your toaster doesn't need to start popping up and down in morse code. Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmedcalf at dessus.com Wed Mar 13 01:04:30 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Tue, 12 Mar 2019 19:04:30 -0600 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: <6250.1552427437@turing-police> Message-ID: On Tuesday, 12 March, 2019 15:51, valdis.kletnieks at vt.edu wrote: >Would you be super pissed if you died for real because Overwatch >suppressed a tornado or other severe weather alert relevant to >your location? Serious question here. Seeing as you are dead, I doubt that you could be super pissed off. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From sean at donelan.com Wed Mar 13 02:36:40 2019 From: sean at donelan.com (Sean Donelan) Date: Tue, 12 Mar 2019 22:36:40 -0400 (EDT) Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: <1fded73f-aa21-486a-cbac-0d06b9e09f08@mtcc.com> References: <20190310142144.GA6710@gsp.org> <88272721-9A02-4D38-A237-86374E6D51E6@cable.comcast.com> <62c9ac4d-7a65-f3f0-16aa-b7e035a78b07@mtcc.com> <6250.1552427437@turing-police> <1fded73f-aa21-486a-cbac-0d06b9e09f08@mtcc.com> Message-ID: On Tue, 12 Mar 2019, Michael Thomas wrote: > This seriously seems like something that needs formal standardization. No one is paying me to work on this, so I don't plan to spend time doing free tutorials for Amazon, Apple and Google program managers; or money flying to standards meetings around the world. I think, within 5 years or so, its inevitable that smart TVs and smart speakers will support emergency alerts. The only questions is whether the ecosystem owners do it voluntarily or it becomes mandatory. Standards and APIs for emergency alert messages have existed for 5, 10, 15 years. Depending on which standard. Google's non-profit arm created a global alert map using those standards several years ago. Note the .org versus .com. https://www.google.org/publicalerts NOAA National Weather Service updated its API for weather alerts a couple of years ago, making it easier to get active alerts for a specific geographic coordinate, i.e. your house, school, etc. You no longer need to download all the alerts in a state. Documentation on the NOAA API is on the web site. https://alerts-v2.weather.gov/ The FEMA API requires signing a MOU with Homeland Security to retrieve non-weather alerts directly from IPAWS. The IPAWS API isn't intended for end-users. However there is no limitation on companies redidstributing those alerts. That's one source of Google.ORG's public alerts for its map. https://www.fema.gov/integrated-public-alert-warning-system-private-sector Intelligent assistants already know where your smart device is located. People even inform the intelligent assistant which room those devices are in. There is no requirement for intelligent assistants to report that information back to government alert originators. Its more or less a one-way feed of alerts. The formal standards are published by OASIS. The great thing about standards bodies is there are so many to choose from. https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=emergency Emergency alerts use the Common Alerting Protocol (CAP) specification. From jwbensley at gmail.com Wed Mar 13 07:51:07 2019 From: jwbensley at gmail.com (James Bensley) Date: Wed, 13 Mar 2019 07:51:07 +0000 Subject: Free Open Source Network Operating Systems In-Reply-To: References: Message-ID: On Sat, 9 Mar 2019 at 16:09, Colton Conor wrote: > Right now, the cost of the whitebox plus a paid network operating system seems to equal the same cost as a discounted Juniper, Cisco, or Arista. I am not seeing the savings on paper. I'm not going to defend the prices of Cisco/Juniper/et al. as they are often ridiculous however, there are many services you can get from these larger vendors that you can't from the smaller ones; it's not only some hardware, software, a bit of support and the occasional bug fix. Big vendors like Cisco and Juniper (and others, these are just examples) have a plethora of additional services smaller white box vendors don't have. My point here is, you seem to be suggesting the white box vendors offer the exact same service for less money but, in my experience this isn't apples for apples. > If we could just buy the whitebox hardware, and have a free operating system on there, then financially whitebox switches would be half the cost of a similar Cisco switch after discount. If you think about Capex only then possibly yes it could be cheaper. > Am I missing something? Yes. Can you imagine what a support nightmare it would be when there is a compatibility issue between software and hardware and those two components are from two different vendors and you're having major packet loss in your network? How will you manage NMS integration when the hardware vendor implements counters for that feature you use but the software vendor doesn’t, or vice versa? I’m not saying this can’t be done. Cumulus have many happy customers using white box switches so it definitely can be done. I’m saying, it’s not just about the Capex. Cheers, James. From adamv0025 at netconsultings.com Wed Mar 13 08:51:57 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Wed, 13 Mar 2019 08:51:57 -0000 Subject: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms In-Reply-To: References: <20190227100105.GF19597@arundodonax.nekodune.net> <9A123508-B7EA-4567-A35B-99F453CC2E47@isc.org> <00fb01d4d8c9$70f72c20$52e58460$@netconsultings.com> <012901d4d8fc$c0c87d70$42597850$@netconsultings.com> <012d01d4d8fe$c1dc2570$45947050$@netconsultings.com> Message-ID: <014101d4d97a$06a2ff50$13e8fdf0$@netconsultings.com> > From: Saku Ytti > Sent: Tuesday, March 12, 2019 6:14 PM > > On Tue, Mar 12, 2019 at 8:09 PM wrote: > > > Yes right, but the lookup principle is the same either you look at IPv6 flow > label or you look at the Entropy label. > > Correct, FAT, Entropy and IPv6 Flow Label are all in principle same, a way for > source node to communicates what constitutes a flow. And in every case, > there is no guarantee implementation has any performance gains, as > implementation may choose to do normal flow speculation in addition of > doing the fast thing. > That's right, and I didn't test that by sending forged packets (with conflicting L3+L4 keys and flow label) at the DUT to see if DUT uses L3+L4 keys or indeed relies on the flow information. adam From rafalfitt at gmail.com Wed Mar 13 10:04:14 2019 From: rafalfitt at gmail.com (=?UTF-8?Q?Rafa=C5=82_Fitt?=) Date: Wed, 13 Mar 2019 11:04:14 +0100 Subject: Should Netflix and Hulu give you emergency alerts? In-Reply-To: References: <20190310142144.GA6710@gsp.org> <88272721-9A02-4D38-A237-86374E6D51E6@cable.comcast.com> <62c9ac4d-7a65-f3f0-16aa-b7e035a78b07@mtcc.com> <6250.1552427437@turing-police> <1fded73f-aa21-486a-cbac-0d06b9e09f08@mtcc.com> Message-ID: You might check this alertmap: http://hisz.rsoe.hu/alertmap/index2.php They got some API: https://hisz.rsoe.hu/ https://hisz.rsoe.hu/ws/ Common Alerting Protocol Version 1.2 http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html -- Rafał Fitt -------------- next part -------------- An HTML attachment was scrubbed... URL: From smeuse at mara.org Wed Mar 13 15:17:22 2019 From: smeuse at mara.org (Steve Meuse) Date: Wed, 13 Mar 2019 11:17:22 -0400 Subject: Analysing traffic in context of rejecting RPKI invalids using pmacct In-Reply-To: <23687.45985.555430.436718@oz.mt.att.com> References: <20190212181554.GB36142@vurt.meerval.net> <23687.45985.555430.436718@oz.mt.att.com> Message-ID: On Tue, Mar 12, 2019 at 9:26 AM Jay Borkenhagen wrote: > > > Thanks for the update, but based on that description I'm not certain > that you implemented the same thing that pmacct built, which IMO is > what is needed by those considering deploying a drop-invalids policy. > (Perhaps you omitted mentioning that ability in your description but > included it in your implementation.) > > Thanks Jay, you are correct. As we were talking through the logic we realized we missed that bit. Internally, we're working though the logic to understand if there is a covering route, is that route valid, and if not, will we recurse and look for another covering route that is valid? Either way, we'll be updating our software with that functionality shortly. -Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at lumaoptics.net Wed Mar 13 23:08:37 2019 From: eric at lumaoptics.net (Eric Litvin) Date: Wed, 13 Mar 2019 16:08:37 -0700 Subject: Oracle DBA Message-ID: <3F30A530-936E-4D68-80EB-E4188138E90B@lumaoptics.net> We currently have Oracle 10g Ent Edition and running into Index and log space issues. Looking for an Oracle DBA we can hire for a day or so to help us cleanup and increase the space issue? This is in Sunnyvale area. Info: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi PL/SQL Release 10.2.0.3.0 - Production "CORE 10.2.0.3.0 Production" TNS for Linux: Version 10.2.0.3.0 - Production NLSRTL Version 10.2.0.3.0 - Production Please contact me offlist with recommendations. Cheers Eric From ross at tajvar.io Wed Mar 13 23:12:56 2019 From: ross at tajvar.io (Ross Tajvar) Date: Wed, 13 Mar 2019 19:12:56 -0400 Subject: Oracle DBA In-Reply-To: <3F30A530-936E-4D68-80EB-E4188138E90B@lumaoptics.net> References: <3F30A530-936E-4D68-80EB-E4188138E90B@lumaoptics.net> Message-ID: This is totally off-topic. On Wed, Mar 13, 2019, 7:10 PM Eric Litvin wrote: > We currently have Oracle 10g Ent Edition and running into Index and log > space issues. Looking for an Oracle DBA we can hire for a day or so to > help us cleanup and increase the space issue? > > This is in Sunnyvale area. > > Info: > Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi > PL/SQL Release 10.2.0.3.0 - Production > "CORE 10.2.0.3.0 Production" > TNS for Linux: Version 10.2.0.3.0 - Production > NLSRTL Version 10.2.0.3.0 - Production > > Please contact me offlist with recommendations. > > Cheers > > Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric-list at truenet.com Wed Mar 13 23:45:16 2019 From: eric-list at truenet.com (Eric Tykwinski) Date: Wed, 13 Mar 2019 19:45:16 -0400 Subject: Oracle DBA In-Reply-To: References: <3F30A530-936E-4D68-80EB-E4188138E90B@lumaoptics.net> Message-ID: <1495F585-F823-4774-8C56-61A402976FD6@truenet.com> > On Mar 13, 2019, at 7:12 PM, Ross Tajvar wrote: > > This is totally off-topic. Yes and no. Probably the wrong list: https://mailman.nanog.org/mailman/listinfo/jobs I think it’s a great idea to ask for/seek human resources, since they probably can be more cost effective than vendors at times. That’s it’s in a DBA field, well that’s sort of off topic, but I’m sure we all know people in the field so it’s probably not the one’s reading it, but it can be forwarded. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at lumaoptics.net Wed Mar 13 23:49:06 2019 From: eric at lumaoptics.net (Eric Litvin) Date: Wed, 13 Mar 2019 16:49:06 -0700 Subject: Oracle DBA In-Reply-To: <1495F585-F823-4774-8C56-61A402976FD6@truenet.com> References: <3F30A530-936E-4D68-80EB-E4188138E90B@lumaoptics.net> <1495F585-F823-4774-8C56-61A402976FD6@truenet.com> Message-ID: Sorry folks. I realized apres-deed that my DBA post was off-topic. Apologies. On Wed, Mar 13, 2019 at 4:45 PM Eric Tykwinski wrote: > > On Mar 13, 2019, at 7:12 PM, Ross Tajvar wrote: > > This is totally off-topic. > > > Yes and no. Probably the wrong list: > https://mailman.nanog.org/mailman/listinfo/jobs > I think it’s a great idea to ask for/seek human resources, since they > probably can be more cost effective than vendors at times. > > That’s it’s in a DBA field, well that’s sort of off topic, but I’m sure we > all know people in the field so it’s probably not the one’s reading it, but > it can be forwarded. > > -- Eric Litvin President eric at lumaoptics.net Direct: (650)440-4382 Mobile:(*650)996-7270* Fax: (650) 618-1870 -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Thu Mar 14 00:43:17 2019 From: randy at psg.com (Randy Bush) Date: Wed, 13 Mar 2019 17:43:17 -0700 Subject: Analysing traffic in context of rejecting RPKI invalids using pmacct In-Reply-To: References: <20190212181554.GB36142@vurt.meerval.net> <23687.45985.555430.436718@oz.mt.att.com> Message-ID: >> Thanks for the update, but based on that description I'm not certain >> that you implemented the same thing that pmacct built, which IMO is >> what is needed by those considering deploying a drop-invalids policy. >> (Perhaps you omitted mentioning that ability in your description but >> included it in your implementation.) >> >> > Thanks Jay, you are correct. As we were talking through the logic we > realized we missed that bit. Internally, we're working though the logic to > understand if there is a covering route, is that route valid, and if not, > will we recurse and look for another covering route that is valid? daniele's pam paper and ripe preso, layed it out pretty well Daniele Iamartino, Cristel Pelsser, Randy Bush. "Measuring BGP Route Origin Registration and Validation," PAM 2015. https://archive.psg.com//141223.route-origin-pam2015.pdf https://ripe69.ripe.net/presentations/103-route-origin-validation.pdf From randy at psg.com Thu Mar 14 00:44:13 2019 From: randy at psg.com (Randy Bush) Date: Wed, 13 Mar 2019 17:44:13 -0700 Subject: Oracle DBA In-Reply-To: References: <3F30A530-936E-4D68-80EB-E4188138E90B@lumaoptics.net> Message-ID: > This is totally off-topic. ya. none of us run oracle From fgont at si6networks.com Thu Mar 14 01:39:37 2019 From: fgont at si6networks.com (Fernando Gont) Date: Wed, 13 Mar 2019 22:39:37 -0300 Subject: IPv6 Security for IPv4 Engineers Message-ID: <8175faa7-c42d-9c53-04dd-3cf6fc0dd6c6@si6networks.com> Folks, It is often argued that IPv4 practices should be forgotten when deploying IPv6, as after all IPv6 is a different protocol! But we think years of IPv4 operational experience should be leveraged as much as possible. So we are publishing IPv6 Security for IPv4 Engineers as a roadmap to IPv6 security that is specifically aimed at IPv4 engineers and operators. Rather than describing IPv6 in an isolated manner, it aims to re-use as much of the existing IPv4 knowledge and experience as possible, by highlighting the security issues that affect both protocols in the same manner, and those that are new or different for the IPv6 protocol suite. Additionally, it discusses the security implications arising from the co-existence of the IPv6 and IPv4 protocols. The document is available at: https://www.internetsociety.org/blog/2019/03/ipv6-security-for-ipv4-engineers/ Comments are welcome. And if you think we've missed something or the like, please drop me en email -- the document can always be revised. P.S.: If you haven't taken a look at it (yet), we have also published the "IPv6 Security Frequently Asked Questions (FAQ)" at: https://www.internetsociety.org/blog/2019/02/ipv6-security-faq Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From aveline at misaka.io Thu Mar 14 03:41:24 2019 From: aveline at misaka.io (Siyuan Miao) Date: Thu, 14 Mar 2019 11:41:24 +0800 Subject: Looking for a AS15169 Google contact to update their PeeringDB records Message-ID: Hi, We're noticed that PeeringDB records of AS15169 in IX.br (PTT.br) São Paulo is outdated. I've tried to contact AS15169 to update it via IX Session Turnup ticket and noc at google.com but didn't get a reasonable response. That's what I got from noc at google.com: > Dear Team, > Thank you for contacting the Google NOC, as 15169. > > With the details provided we were unable to identify the relevant link. > > Please provide following items to identify which session is impacted: > > * Peering City > * BGP peering ASNs, including your own AS > * BGP peer IP addresses > > Thanks & Regards, > [redacted] > > Google Network Operation Center (GNOC) |noc at google.com | > [redacted] Can someone contact me off list about this issue? Regards, Siyuan Miao -------------- next part -------------- An HTML attachment was scrubbed... URL: From rubensk at gmail.com Thu Mar 14 04:02:30 2019 From: rubensk at gmail.com (Rubens Kuhl) Date: Thu, 14 Mar 2019 13:02:30 +0900 Subject: Looking for a AS15169 Google contact to update their PeeringDB records In-Reply-To: References: Message-ID: While I hope you get the contact you asked for, you can use IX.br communities to manipulate how your route announcement reaches them or not, so that even with the lack of other network cooperation, you might be able to achieve your goals. Rubens On Thu, Mar 14, 2019 at 12:43 PM Siyuan Miao wrote: > Hi, > > We're noticed that PeeringDB records of AS15169 in IX.br (PTT.br) São > Paulo is outdated. > > I've tried to contact AS15169 to update it via IX Session Turnup ticket > and noc at google.com but didn't get a reasonable response. > > That's what I got from noc at google.com: > > > Dear Team, > > Thank you for contacting the Google NOC, as 15169. > > > > With the details provided we were unable to identify the relevant link. > > > > Please provide following items to identify which session is impacted: > > > > * Peering City > > * BGP peering ASNs, including your own AS > > * BGP peer IP addresses > > > > Thanks & Regards, > > [redacted] > > > > Google Network Operation Center (GNOC) |noc at google.com | > > [redacted] > > Can someone contact me off list about this issue? > > Regards, > Siyuan Miao > -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Thu Mar 14 04:21:19 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 13 Mar 2019 21:21:19 -0700 Subject: Looking for a AS15169 Google contact to update their PeeringDB records In-Reply-To: References: Message-ID: I'm sure someone else already contacted you, but in the off chance that didn't happen :) maybe find me privately and we can chat? :) On Wed, Mar 13, 2019 at 8:43 PM Siyuan Miao wrote: > Hi, > > We're noticed that PeeringDB records of AS15169 in IX.br (PTT.br) São > Paulo is outdated. > > I've tried to contact AS15169 to update it via IX Session Turnup ticket > and noc at google.com but didn't get a reasonable response. > > That's what I got from noc at google.com: > > > Dear Team, > > Thank you for contacting the Google NOC, as 15169. > > > > With the details provided we were unable to identify the relevant link. > > > > Please provide following items to identify which session is impacted: > > > > * Peering City > > * BGP peering ASNs, including your own AS > > * BGP peer IP addresses > > > > Thanks & Regards, > > [redacted] > > > > Google Network Operation Center (GNOC) |noc at google.com | > > [redacted] > > Can someone contact me off list about this issue? > > Regards, > Siyuan Miao > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil.lavin at cloudcall.com Thu Mar 14 08:50:10 2019 From: phil.lavin at cloudcall.com (Phil Lavin) Date: Thu, 14 Mar 2019 08:50:10 +0000 Subject: AS701/Verizon In-Reply-To: References: Message-ID: > We're seeing consistent +100ms latency increases to Verizon customers in Pennsylvania, during peak business hours for the past couple of weeks. Verizon reached out shortly after my e-mail to say they had resolved the issue - latency has been within normal bounds since. Many thanks :) From ahebert at pubnix.net Thu Mar 14 11:26:40 2019 From: ahebert at pubnix.net (Alain Hebert) Date: Thu, 14 Mar 2019 07:26:40 -0400 Subject: Oracle DBA In-Reply-To: References: <3F30A530-936E-4D68-80EB-E4188138E90B@lumaoptics.net> Message-ID: <16bfee88-1ee7-9226-b1a7-8c3dcb536987@pubnix.net>     Run away from... ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 3/13/19 8:44 PM, Randy Bush wrote: >> This is totally off-topic. > ya. none of us run oracle > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.meredith at port.ac.uk Thu Mar 14 12:02:24 2019 From: mike.meredith at port.ac.uk (Mike Meredith) Date: Thu, 14 Mar 2019 12:02:24 +0000 Subject: Oracle DBA In-Reply-To: References: <3F30A530-936E-4D68-80EB-E4188138E90B@lumaoptics.net> Message-ID: <20190314120224.4b7900bb@scrofula.eps.is.port.ac.uk> On Wed, 13 Mar 2019 17:44:13 -0700, Randy Bush may have written: > ya. none of us run oracle Yeah but some of us walk it. -- Mike Meredith, University of Portsmouth Chief Systems Engineer, Hostmaster, Security, and Timelord! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From nanog at ics-il.net Thu Mar 14 12:17:36 2019 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 14 Mar 2019 07:17:36 -0500 (CDT) Subject: FB? Message-ID: <1461790733.9952.1552565854133.JavaMail.mhammett@ThunderFuck> So what happened at Facebook today ? I saw one article quoting Roland saying it was a route leak, but I haven't seen any other sources that aren't just quoting Roland. Usually there are a few independent posts out there by now. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roland.Dobbins at netscout.com Thu Mar 14 12:23:00 2019 From: Roland.Dobbins at netscout.com (Dobbins, Roland) Date: Thu, 14 Mar 2019 12:23:00 +0000 Subject: FB? In-Reply-To: <1461790733.9952.1552565854133.JavaMail.mhammett@ThunderFuck> References: <1461790733.9952.1552565854133.JavaMail.mhammett@ThunderFuck> Message-ID: <0B68C416-E859-4512-BE40-8C9E6C83DD44@netscout.com> On 14 Mar 2019, at 19:17, Mike Hammett wrote: > I saw one article quoting Roland saying it was a route leak, but I > haven't seen any other sources that aren't just quoting Roland. That was the result of a miscommunication; a clarification has been issued, FYI. -------------------------------------------- Roland Dobbins From simon at slimey.org Thu Mar 14 12:27:38 2019 From: simon at slimey.org (Simon Lockhart) Date: Thu, 14 Mar 2019 12:27:38 +0000 Subject: Apple devices spoofing default gateway? Message-ID: <20190314122738.GR29673@dilbert.slimey.org> All, We're seeing a bit of a weird one on our network at the moment, and wondering if anyone else has seen it. Since Friday we're seeing Apple devices (we believe it's both laptops and iPhones) responding to ARP requests for the default gateway IP with their own MAC address (i.e. ARP spoofing / MITM type attack). We're only seeing it on Apple devices, but what's more strange is that we're only seeing it where those Apple devices are connected to Cisco 1810 and 1815 APs, and where those APs are connected to a Cisco WLC running v8.5 software. If we downgrade the WLC to v8.2 the problem goes away (but v8.2 doesn't support 1815 APs, so we can't roll that out globally). We're engaged with Cisco TAC, but they're trying to deny it's their problem. Apple support are investigating, but aren't admitting to having seen it before. Has anyone else seen or heard of similar issues over the last few days? Many thanks, Simon From nanog at ics-il.net Thu Mar 14 12:28:47 2019 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 14 Mar 2019 07:28:47 -0500 (CDT) Subject: FB? In-Reply-To: <0B68C416-E859-4512-BE40-8C9E6C83DD44@netscout.com> References: <1461790733.9952.1552565854133.JavaMail.mhammett@ThunderFuck> <0B68C416-E859-4512-BE40-8C9E6C83DD44@netscout.com> Message-ID: <1669456769.10063.1552566523336.JavaMail.mhammett@ThunderFuck> Do you have a link to the clarification? With the high jitter of news, all I'm finding is people parroting the original statement. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Roland Dobbins" To: nanog at nanog.org Sent: Thursday, March 14, 2019 7:23:00 AM Subject: Re: FB? On 14 Mar 2019, at 19:17, Mike Hammett wrote: > I saw one article quoting Roland saying it was a route leak, but I > haven't seen any other sources that aren't just quoting Roland. That was the result of a miscommunication; a clarification has been issued, FYI. -------------------------------------------- Roland Dobbins -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Thu Mar 14 12:53:01 2019 From: mel at beckman.org (Mel Beckman) Date: Thu, 14 Mar 2019 12:53:01 +0000 Subject: Apple devices spoofing default gateway? In-Reply-To: <20190314122738.GR29673@dilbert.slimey.org> References: <20190314122738.GR29673@dilbert.slimey.org> Message-ID: <2163B326-339F-4BA0-B65A-DF1752431913@beckman.org> Can you post some packet captures? I was a network engineer on the WiFi network at SFO, for both passengers and baggage scanners, with several hundred APs. Several times we were misled by packet captures that seemed to show client traffic causing network problems, such as packet storms, but which ultimately always had some more mundane cause, like a failed DHCP server or flapping switch interface. The particular SFO network I worked on has Juniper switching and Aruba APs, so it’s not directly applicable to your ecosystem. But the complexities of interpreting packet captures may apply. -mel beckman > On Mar 14, 2019, at 5:28 AM, Simon Lockhart wrote: > > All, > > We're seeing a bit of a weird one on our network at the moment, and wondering > if anyone else has seen it. > > Since Friday we're seeing Apple devices (we believe it's both laptops and > iPhones) responding to ARP requests for the default gateway IP with their own > MAC address (i.e. ARP spoofing / MITM type attack). We're only seeing it on > Apple devices, but what's more strange is that we're only seeing it where > those Apple devices are connected to Cisco 1810 and 1815 APs, and where those > APs are connected to a Cisco WLC running v8.5 software. If we downgrade the > WLC to v8.2 the problem goes away (but v8.2 doesn't support 1815 APs, so we > can't roll that out globally). We're engaged with Cisco TAC, but they're > trying to deny it's their problem. Apple support are investigating, but aren't > admitting to having seen it before. > > Has anyone else seen or heard of similar issues over the last few days? > > Many thanks, > > Simon From bkain1 at ford.com Thu Mar 14 13:35:33 2019 From: bkain1 at ford.com (Kain, Rebecca (.)) Date: Thu, 14 Mar 2019 13:35:33 +0000 Subject: FB? In-Reply-To: <1669456769.10063.1552566523336.JavaMail.mhammett@ThunderFuck> References: <1461790733.9952.1552565854133.JavaMail.mhammett@ThunderFuck> <0B68C416-E859-4512-BE40-8C9E6C83DD44@netscout.com> <1669456769.10063.1552566523336.JavaMail.mhammett@ThunderFuck> Message-ID: <8a8e7978931d41a4b4ff819f82169248@ford.com> So what happened yesterday? From: NANOG On Behalf Of Mike Hammett Sent: Thursday, March 14, 2019 8:29 AM To: Roland Dobbins Cc: nanog at nanog.org Subject: Re: FB? Do you have a link to the clarification? With the high jitter of news, all I'm finding is people parroting the original statement. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ________________________________ From: "Roland Dobbins" > To: nanog at nanog.org Sent: Thursday, March 14, 2019 7:23:00 AM Subject: Re: FB? On 14 Mar 2019, at 19:17, Mike Hammett wrote: > I saw one article quoting Roland saying it was a route leak, but I > haven't seen any other sources that aren't just quoting Roland. That was the result of a miscommunication; a clarification has been issued, FYI. -------------------------------------------- Roland Dobbins > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsuter at tps.org Thu Mar 14 13:51:00 2019 From: jsuter at tps.org (Jason Suter) Date: Thu, 14 Mar 2019 09:51:00 -0400 Subject: FB? In-Reply-To: <8a8e7978931d41a4b4ff819f82169248@ford.com> References: <1461790733.9952.1552565854133.JavaMail.mhammett@ThunderFuck> <0B68C416-E859-4512-BE40-8C9E6C83DD44@netscout.com> <1669456769.10063.1552566523336.JavaMail.mhammett@ThunderFuck> <8a8e7978931d41a4b4ff819f82169248@ford.com> Message-ID: I found this article but no real answers. On Thu, Mar 14, 2019 at 9:36 AM Kain, Rebecca (.) wrote: > So what happened yesterday? > > > > *From:* NANOG *On Behalf Of *Mike Hammett > *Sent:* Thursday, March 14, 2019 8:29 AM > *To:* Roland Dobbins > *Cc:* nanog at nanog.org > *Subject:* Re: FB? > > > > Do you have a link to the clarification? With the high jitter of news, all > I'm finding is people parroting the original statement. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > > ------------------------------ > > *From: *"Roland Dobbins" > *To: *nanog at nanog.org > *Sent: *Thursday, March 14, 2019 7:23:00 AM > *Subject: *Re: FB? > > On 14 Mar 2019, at 19:17, Mike Hammett wrote: > > > I saw one article quoting Roland saying it was a route leak, but I > > haven't seen any other sources that aren't just quoting Roland. > > That was the result of a miscommunication; a clarification has been > issued, FYI. > > -------------------------------------------- > Roland Dobbins > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jeroen.Wunnink at gtt.net Thu Mar 14 14:04:39 2019 From: Jeroen.Wunnink at gtt.net (Jeroen Wunnink) Date: Thu, 14 Mar 2019 14:04:39 +0000 Subject: FB? In-Reply-To: <8a8e7978931d41a4b4ff819f82169248@ford.com> References: <1461790733.9952.1552565854133.JavaMail.mhammett@ThunderFuck> <0B68C416-E859-4512-BE40-8C9E6C83DD44@netscout.com> <1669456769.10063.1552566523336.JavaMail.mhammett@ThunderFuck> <8a8e7978931d41a4b4ff819f82169248@ford.com> Message-ID: The route-leak was something different that seems to have mainly hit west-Europe between 16:52 UTC to 17:08 UTC. There’s a few people in the *NOG communities still digging at the complete details of that right now, but it currently points to have originated from AS200020, impacting a few large upstreams for a short period of time. So unless this leak caused a catastrophic cascade in FB’s network somehow, it seems to be unrelated. It looked like a valid suspect because timing was very similar between the start of the FB outage and the leak. Jeroen Wunnink Sr. Manager - Integration Engineering www.gtt.net [id:image001.png at 01D37331.D1301F60] From: NANOG on behalf of "Kain, Rebecca (.)" Date: Thursday, 14 March 2019 at 14:36 To: Mike Hammett , Roland Dobbins Cc: "nanog at nanog.org" Subject: RE: FB? So what happened yesterday? From: NANOG On Behalf Of Mike Hammett Sent: Thursday, March 14, 2019 8:29 AM To: Roland Dobbins Cc: nanog at nanog.org Subject: Re: FB? Do you have a link to the clarification? With the high jitter of news, all I'm finding is people parroting the original statement. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ________________________________ From: "Roland Dobbins" > To: nanog at nanog.org Sent: Thursday, March 14, 2019 7:23:00 AM Subject: Re: FB? On 14 Mar 2019, at 19:17, Mike Hammett wrote: > I saw one article quoting Roland saying it was a route leak, but I > haven't seen any other sources that aren't just quoting Roland. That was the result of a miscommunication; a clarification has been issued, FYI. -------------------------------------------- Roland Dobbins > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Thu Mar 14 14:06:19 2019 From: beecher at beecher.cc (Tom Beecher) Date: Thu, 14 Mar 2019 10:06:19 -0400 Subject: FB? In-Reply-To: References: <1461790733.9952.1552565854133.JavaMail.mhammett@ThunderFuck> <0B68C416-E859-4512-BE40-8C9E6C83DD44@netscout.com> <1669456769.10063.1552566523336.JavaMail.mhammett@ThunderFuck> <8a8e7978931d41a4b4ff819f82169248@ford.com> Message-ID: As much as I wanted to crack jokes because I cannot stand Facebook (the product), much love to all you FB engineers that went through (and are probably still going through) much hell. On Thu, Mar 14, 2019 at 9:58 AM Jason Suter wrote: > > I found this article > but > no real answers. > > On Thu, Mar 14, 2019 at 9:36 AM Kain, Rebecca (.) wrote: > >> So what happened yesterday? >> >> >> >> *From:* NANOG *On Behalf Of *Mike Hammett >> *Sent:* Thursday, March 14, 2019 8:29 AM >> *To:* Roland Dobbins >> *Cc:* nanog at nanog.org >> *Subject:* Re: FB? >> >> >> >> Do you have a link to the clarification? With the high jitter of news, >> all I'm finding is people parroting the original statement. >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> >> >> ------------------------------ >> >> *From: *"Roland Dobbins" >> *To: *nanog at nanog.org >> *Sent: *Thursday, March 14, 2019 7:23:00 AM >> *Subject: *Re: FB? >> >> On 14 Mar 2019, at 19:17, Mike Hammett wrote: >> >> > I saw one article quoting Roland saying it was a route leak, but I >> > haven't seen any other sources that aren't just quoting Roland. >> >> That was the result of a miscommunication; a clarification has been >> issued, FYI. >> >> -------------------------------------------- >> Roland Dobbins >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pim at vanstam-ict.nl Thu Mar 14 14:22:58 2019 From: pim at vanstam-ict.nl (Pim van Stam) Date: Thu, 14 Mar 2019 15:22:58 +0100 Subject: FB? - route leak AS200020 In-Reply-To: References: <1461790733.9952.1552565854133.JavaMail.mhammett@ThunderFuck> <0B68C416-E859-4512-BE40-8C9E6C83DD44@netscout.com> <1669456769.10063.1552566523336.JavaMail.mhammett@ThunderFuck> <8a8e7978931d41a4b4ff819f82169248@ford.com> Message-ID: > On 14 Mar 2019, at 15:04, Jeroen Wunnink wrote: > > The route-leak was something different that seems to have mainly hit west-Europe between 16:52 UTC to 17:08 UTC. There’s a few people in the *NOG communities still digging at the complete details of that right now, but it currently points to have originated from AS200020, impacting a few large upstreams for a short period of time. > > So unless this leak caused a catastrophic cascade in FB’s network somehow, it seems to be unrelated. > It looked like a valid suspect because timing was very similar between the start of the FB outage and the leak. Hello, I’m an engineer at AS200020. We indeed had a route leak yesterday between 16:45 and 17:07 UTC. This was caused by a mistake in the configuration of one of ou core routers by one of our engineers. We leaked full table to one of our transits, which is apparently accepted. We’ve seen some prefixes from a couple of AS numbers coming in. Facebook was not one of these AS’es. As far as I can tell it’s not related at all to the major incidents at Facebook. We are very sorry for any inconvenience people could have experienced. If you received complaints in the mentioned time period and want to know if it could be related, please let me know. Best regards, Pim van Stam NBIP-naWas / AS200020 From job at instituut.net Thu Mar 14 15:08:46 2019 From: job at instituut.net (Job Snijders) Date: Thu, 14 Mar 2019 15:08:46 +0000 Subject: FB? / AS 200020 leak In-Reply-To: <20190314150626.GW12253@vurt.meerval.net> References: <1461790733.9952.1552565854133.JavaMail.mhammett@ThunderFuck> <0B68C416-E859-4512-BE40-8C9E6C83DD44@netscout.com> <1669456769.10063.1552566523336.JavaMail.mhammett@ThunderFuck> <8a8e7978931d41a4b4ff819f82169248@ford.com> <20190314150626.GW12253@vurt.meerval.net> Message-ID: <20190314150846.GX12253@vurt.meerval.net> Hi, On Thu, Mar 14, 2019 at 02:04:39PM +0000, Jeroen Wunnink wrote: > The route-leak was something different that seems to have mainly hit > west-Europe between 16:52 UTC to 17:08 UTC. There’s a few people in > the *NOG communities still digging at the complete details of that > right now, but it currently points to have originated from AS200020, > impacting a few large upstreams for a short period of time. Here are some details of prefixes affected (courtesy of Doug Madory). The percent at the beginning is the percentage of the peering sources that saw each prefix leaked. Last column is the AS_PATH March 14th, 2019 - 16:43 UTC was the start of the BGP leak incident. The leak was very serious in terms of negative impact, it affected many West European access providers (for instance AS 1136 has over 50% of Dutch access market). Kind regards, Job 70.6% 92.68.0.0/14 KPN B.V. NL ... 200020 1136 70.6% 92.64.0.0/14 KPN B.V. Amsterdam Provincie Noord-Holland NL ... 200020 1136 70.4% 93.154.64.0/18 KPN B.V. NL ... 200020 1136 70.4% 93.154.0.0/18 KPN B.V. NL ... 200020 1136 70.4% 86.88.0.0/13 KPN B.V. NL ... 200020 1136 70.4% 86.80.0.0/13 KPN B.V. NL ... 200020 1136 70.4% 84.84.0.0/14 KPN B.V. NL ... 200020 1136 70.4% 84.80.0.0/14 KPN B.V. NL ... 200020 1136 70.4% 81.206.0.0/15 KPN B.V. NL ... 200020 1136 70.4% 81.204.0.0/15 KPN B.V. NL ... 200020 1136 70.4% 80.61.0.0/16 Customers NL ... 200020 1136 70.4% 80.60.0.0/16 Customers NL ... 200020 1136 70.4% 77.62.0.0/15 KPN B.V. NL ... 200020 1136 70.4% 77.60.0.0/15 KPN B.V. NL ... 200020 1136 70.4% 77.170.0.0/15 KPN B.V. NL ... 200020 1136 70.4% 77.168.0.0/15 KPN B.V. NL ... 200020 1136 70.4% 77.164.0.0/14 KPN B.V. NL ... 200020 1136 70.4% 77.160.0.0/14 KPN B.V. NL ... 200020 1136 70.4% 62.12.0.0/20 KPN B.V. Amsterdam Provincie Noord-Holland NL ... 200020 1136 70.4% 46.145.0.0/16 KPN B.V. NL ... 200020 1136 70.4% 46.144.0.0/16 KPN B.V. NL ... 200020 1136 70.4% 31.161.0.0/16 KPN B.V. NL ... 200020 1136 70.4% 31.160.0.0/16 KPN B.V. NL ... 200020 1136 70.4% 145.7.128.0/17 KPN B.V. NL ... 200020 1136 70.4% 145.133.0.0/16 KPN B.V. NL ... 200020 1136 70.4% 145.132.0.0/16 KPN B.V. NL ... 200020 1136 70.1% 89.200.64.0/18 KPN Mobile The Netherlands B.V. NL ... 200020 1136 70.1% 89.200.0.0/18 KPN Mobile The Netherlands B.V. NL ... 200020 1136 70.1% 83.232.32.0/19 KPN Mobile The Netherlands B.V. NL ... 200020 1136 70.1% 83.232.128.0/17 KPN B.V. NL ... 200020 1136 70.1% 83.232.0.0/19 KPN Mobile The Netherlands B.V. NL ... 200020 1136 70.1% 83.232.0.0/17 KPN B.V. Amsterdam Provincie Noord-Holland NL ... 200020 1136 70.1% 82.171.96.0/19 Customers NL ... 200020 1136 70.1% 82.171.64.0/19 Customers NL ... 200020 1136 70.1% 82.171.32.0/19 Customers NL ... 200020 1136 70.1% 82.171.192.0/18 Customers NL ... 200020 1136 70.1% 82.171.128.0/18 Customers NL ... 200020 1136 70.1% 82.171.0.0/19 Customers NL ... 200020 1136 70.1% 82.170.128.0/17 Customers NL ... 200020 1136 70.1% 82.170.0.0/17 Customers NL ... 200020 1136 70.1% 82.169.96.0/20 Customers NL ... 200020 1136 70.1% 82.169.80.0/20 Customers NL ... 200020 1136 70.1% 82.169.64.0/20 Customers NL ... 200020 1136 70.1% 82.169.32.0/19 Customers NL ... 200020 1136 70.1% 82.169.224.0/19 Customers NL ... 200020 1136 70.1% 82.169.192.0/19 Customers NL ... 200020 1136 70.1% 82.169.176.0/20 Customers NL ... 200020 1136 70.1% 82.169.160.0/20 Customers NL ... 200020 1136 70.1% 82.169.144.0/20 Customers NL ... 200020 1136 70.1% 82.169.128.0/20 Customers NL ... 200020 1136 70.1% 82.169.112.0/20 Customers NL ... 200020 1136 70.1% 82.169.0.0/19 Customers NL ... 200020 1136 70.1% 82.168.64.0/18 Customers NL ... 200020 1136 70.1% 82.168.240.0/20 Customers NL ... 200020 1136 70.1% 82.168.224.0/20 Customers NL ... 200020 1136 70.1% 82.168.208.0/20 Customers NL ... 200020 1136 70.1% 82.168.192.0/20 Customers NL ... 200020 1136 70.1% 82.168.160.0/19 Customers NL ... 200020 1136 70.1% 82.168.128.0/19 Customers NL ... 200020 1136 70.1% 82.168.0.0/18 Customers NL ... 200020 1136 70.1% 82.136.224.0/19 KPN B.V. NL ... 200020 1136 70.1% 82.136.192.0/19 KPN B.V. NL ... 200020 1136 70.1% 80.60.224.0/20 Customers Amsterdam Provincie Noord-Holland NL ... 200020 1136 70.1% 80.60.224.0/19 Customers Amsterdam Provincie Noord-Holland NL ... 200020 1136 70.1% 77.173.128.0/17 Customers NL ... 200020 1136 70.1% 77.173.0.0/17 Customers NL ... 200020 1136 70.1% 77.172.128.0/17 Customers NL ... 200020 1136 70.1% 77.172.0.0/17 Customers NL ... 200020 1136 70.1% 62.41.128.0/17 KPN B.V. NL ... 200020 1136 70.1% 62.41.0.0/17 KPN B.V. NL ... 200020 1136 70.1% 62.25.32.0/19 KPN B.V. NL ... 200020 1136 70.1% 62.25.0.0/19 KPN B.V. NL ... 200020 1136 70.1% 62.21.192.0/18 KPN B.V. Amsterdam Provincie Noord-Holland NL ... 200020 1136 70.1% 62.21.128.0/18 KPN B.V. NL ... 200020 1136 70.1% 62.207.128.0/17 KPN B.V. NL ... 200020 1136 70.1% 62.207.0.0/17 KPN B.V. Amsterdam Provincie Noord-Holland NL ... 200020 1136 70.1% 62.133.96.0/19 KPN Mobile The Netherlands B.V. NL ... 200020 1136 70.1% 62.133.64.0/19 KPN Mobile The Netherlands B.V. NL ... 200020 1136 70.1% 62.132.128.0/17 KPN B.V. NL ... 200020 1136 70.1% 62.132.0.0/17 KPN B.V. NL ... 200020 1136 70.1% 62.131.128.0/17 Customer NL ... 200020 1136 70.1% 62.131.0.0/17 Customer NL ... 200020 1136 70.1% 62.12.16.0/20 KPN B.V. NL ... 200020 1136 70.1% 31.149.128.0/17 KPN B.V. NL ... 200020 1136 70.1% 31.149.0.0/17 KPN B.V. NL ... 200020 1136 70.1% 145.7.0.0/17 KPN B.V. Amsterdam Provincie Noord-Holland NL ... 200020 1136 70.1% 145.53.128.0/17 Customer Network NL ... 200020 1136 70.1% 145.53.0.0/17 KPN B.V. NL ... 200020 1136 70.1% 145.130.128.0/17 KPN B.V. NL ... 200020 1136 70.1% 145.130.0.0/17 KPN B.V. NL ... 200020 1136 70.1% 145.129.128.0/17 KPN B.V. NL ... 200020 1136 70.1% 145.129.0.0/17 KPN B.V. NL ... 200020 1136 70.1% 145.128.128.0/17 KPN B.V. NL ... 200020 1136 70.1% 145.128.0.0/17 KPN B.V. NL ... 200020 1136 69.8% 37.74.128.0/17 KPN B.V. NL ... 200020 1136 69.8% 37.74.0.0/17 KPN B.V. NL ... 200020 1136 56.0% 46.31.12.0/22 IX Networks BV io NL ... 200020 20562 12561 55.7% 46.31.9.0/24 IX Networks BV io Maastricht Provincie Limburg NL ... 200020 20562 12561 54.9% 91.194.98.0/23 ADELI SAS FR ... 200020 43142 43142 43142 43142 54.9% 91.194.96.0/23 ADELI SAS FR ... 200020 43142 43142 43142 43142 54.6% 46.227.18.0/23 ADELI SAS FR ... 200020 43142 43142 43142 43142 54.6% 46.227.16.0/23 ADELI SAS FR ... 200020 43142 43142 43142 43142 53.6% 185.94.170.0/23 CJ2 Hosting B.V. NL ... 200020 41887 53.6% 185.94.168.0/23 CJ2 Hosting B.V. Amsterdam Provincie Noord-Holland NL ... 200020 41887 53.6% 185.93.14.0/23 Xolphin B.V. NL ... 200020 41887 53.6% 185.93.12.0/23 Xolphin B.V. Amsterdam Provincie Noord-Holland NL ... 200020 41887 53.6% 185.85.114.0/23 VitrumNet BV NL ... 200020 41887 53.6% 185.85.112.0/23 VitrumNet BV NL ... 200020 41887 52.8% 91.194.97.0/24 ADELI SAS Tassin-la-Demi-Lune Rhône-Alpes FR ... 200020 43142 43142 43142 43142 52.8% 85.144.0.0/15 T-Mobile Thuis BV NL ... 200020 50266 52.8% 185.8.65.0/24 ADELI SAS Ambérieu-en-Bugey Rhône-Alpes FR ... 200020 43142 43142 43142 43142 52.5% 91.194.96.0/24 ADELI SAS Saint-Trivier-sur-Moignans Rhône-Alpes FR ... 200020 43142 43142 43142 43142 52.5% 85.146.128.0/18 T-Mobile Thuis BV NL ... 200020 50266 52.5% 85.146.0.0/17 T-Mobile Thuis BV NL ... 200020 50266 52.5% 46.227.17.0/24 ADELI SAS Ruy Rhône-Alpes FR ... 200020 43142 43142 43142 43142 52.5% 31.201.0.0/16 T-Mobile Thuis BV Amsterdam Provincie Noord-Holland NL ... 200020 50266 52.5% 31.20.0.0/16 Pool for fixed WBA users NL ... 200020 50266 52.5% 185.8.67.0/24 ADELI SAS FR ... 200020 43142 43142 43142 43142 52.5% 185.8.66.0/24 ADELI SAS FR ... 200020 43142 43142 43142 43142 52.5% 185.8.64.0/24 ADELI SAS FR ... 200020 43142 43142 43142 43142 52.2% 5.132.0.0/17 T-Mobile Thuis BV Amsterdam Provincie Noord-Holland NL ... 200020 50266 52.2% 46.227.16.0/24 ADELI SAS FR ... 200020 43142 43142 43142 43142 52.2% 37.143.80.0/21 T-Mobile Thuis BV Amsterdam Provincie Noord-Holland NL ... 200020 50266 49.0% 92.60.184.0/24 Kiev colocation Kiev Misto Kyyiv UA ... 200020 15772 49.0% 92.60.176.0/24 Wnet-Odessa-Colo Kiev Misto Kyyiv UA ... 200020 15772 48.8% 31.172.138.0/24 LL clients from Odessa region Odessa Odes’ka Oblast’ UA ... 200020 15772 48.8% 185.39.197.0/24 WNET-KYIV UA ... 200020 15772 48.5% 80.92.235.0/24 Unlimited Network Kharkov Kiev Misto Kyyiv UA ... 200020 15772 48.5% 31.172.137.0/24 Home net project, http://domonet.ua/ Kiev Misto Kyyiv UA ... 200020 15772 24685 48.2% 62.112.224.0/21 Solvinity B.V. Rolde Provincie Drenthe NL ... 200020 20562 29311 48.2% 185.61.227.0/24 Solvinity B.V. NL ... 200020 20562 29311 48.2% 185.61.226.0/24 Solvinity B.V. NL ... 200020 20562 29311 48.2% 185.61.225.0/24 Solvinity B.V. NL ... 200020 20562 29311 48.2% 185.61.224.0/24 ASP4ALL DC Amsterdam Provincie Noord-Holland NL ... 200020 20562 29311 48.2% 159.46.204.0/22 Ministerie van Justitie Amsterdam Provincie Noord-Holland NL ... 200020 20562 29311 48.0% 62.112.248.0/21 Solvinity B.V. Amsterdam Provincie Noord-Holland NL ... 200020 20562 29311 48.0% 62.112.240.0/21 Solvinity B.V. Amsterdam Provincie Noord-Holland NL ... 200020 20562 29311 48.0% 62.112.232.0/21 Solvinity B.V. Ugchelen Provincie Gelderland NL ... 200020 20562 29311 48.0% 159.46.200.0/22 Ministerie van Justitie Amsterdam Provincie Noord-Holland NL ... 200020 20562 29311 48.0% 159.46.196.0/22 Ministerie van Justitie NL ... 200020 20562 29311 48.0% 159.46.192.0/22 Ministerie van Justitie NL ... 200020 20562 29311 47.4% 23.50.56.0/24 Akamai International, BV Amsterdam Provincie Noord-Holland NL ... 200020 20940 47.4% 195.137.169.0/24 AKSI Automatisering B.V. Groningen Provincie Groningen NL ... 200020 31477 47.4% 193.177.163.0/24 Stichting Algemeen Christelijk Ziekenhuis Groningen Groningen Provincie Groningen NL ... 200020 31477 47.4% 193.138.248.0/22 Adix B.V. NL ... 200020 31477 47.4% 185.28.56.0/22 SoHosted Cloud B.V. NL ... 200020 31477 47.4% 185.180.96.0/22 AKSI Automatisering B.V. Groningen Provincie Groningen NL ... 200020 31477 47.4% 128.0.174.0/24 Home net project, http://domonet.ua/ Kiev Misto Kyyiv UA ... 200020 15772 47.2% 91.238.176.0/23 SoHosted Cloud B.V. NL ... 200020 31477 47.2% 89.200.200.0/21 Adix B.V. NL ... 200020 31477 47.2% 37.9.160.0/21 Youwe Concept B.V. NL ... 200020 31477 46.9% 91.206.136.0/23 theFactor.e B.V. Groningen Provincie Groningen NL ... 200020 31477 46.9% 91.194.8.0/23 Unet B.V. Amsterdam Provincie Noord-Holland NL ... 200020 29396 46.9% 194.53.84.0/24 Stichting Menzis Beheer Hengelo Provincie Overijssel NL ... 200020 29396 46.9% 193.222.190.0/24 Access Communications BV NL ... 200020 29396 46.9% 193.105.33.0/24 Gemeente Lelystad Lelystad Provincie Flevoland NL ... 200020 29396 46.9% 185.60.60.0/22 Educanet B.V. Den Helder Provincie Noord-Holland NL ... 200020 29396 46.9% 185.41.144.0/22 Unet B.V. Amsterdam Provincie Noord-Holland NL ... 200020 29396 46.9% 185.204.36.0/24 Poliservice B.V. Zeist Provincie Utrecht NL ... 200020 29396 46.9% 185.202.200.0/22 Green Flamingo UG NL ... 200020 29396 46.9% 185.171.128.0/22 Stichting Kabeltelevisie Pijnacker NL ... 200020 29396 46.9% 185.152.84.0/22 Unet B.V. NL ... 200020 29396 46.9% 185.128.32.0/22 GidPro BV Amsterdam Provincie Noord-Holland NL ... 200020 29396 46.9% 145.87.0.0/22 Gemeente Leeuwarden Leeuwarden Provincie Friesland NL ... 200020 29396 44.5% 90.145.0.0/16 Unet B.V. Amsterdam Provincie Noord-Holland NL ... 200020 29396 44.2% 84.53.64.0/18 Unet B.V. Amsterdam Provincie Noord-Holland NL ... 200020 29396 44.2% 82.148.192.0/19 Unet B.V. Amsterdam Provincie Noord-Holland NL ... 200020 29396 44.2% 46.22.176.0/23 IPv4 space for Intermax DSL NL ... 200020 29396 44.2% 195.189.20.0/22 Intermax BV NL ... 200020 29396 44.2% 185.30.56.0/24 ALMERE HQ Almere Stad Provincie Flevoland NL ... 200020 29396 43.4% 89.39.232.0/21 Lepida S.c.p.A. IT ... 200020 31638 43.4% 5.144.184.0/22 Lepida S.c.p.A. IT ... 200020 31638 43.4% 37.156.98.0/23 Lepida S.c.p.A. Bucharest București RO ... 200020 31638 43.4% 37.156.96.0/23 Lepida S.c.p.A. Bucharest București RO ... 200020 31638 43.4% 37.156.210.0/23 Lepida S.c.p.A. IT ... 200020 31638 43.4% 37.156.208.0/23 Lepida S.c.p.A. IT ... 200020 31638 43.4% 37.156.170.0/23 Lepida S.c.p.A. Bucharest București RO ... 200020 31638 43.4% 37.156.168.0/23 Lepida S.c.p.A. Bucharest București RO ... 200020 31638 43.4% 37.156.150.0/23 Lepida S.c.p.A. Bucharest București RO ... 200020 31638 43.4% 37.156.148.0/23 Lepida S.c.p.A. Bucharest București RO ... 200020 31638 43.2% 89.39.224.0/21 Lepida S.c.p.A. Bologna Emilia-Romagna IT ... 200020 31638 43.2% 5.144.188.0/22 Lepida S.c.p.A. IT ... 200020 31638 43.2% 46.255.84.0/22 Lepida S.c.p.A. IT ... 200020 31638 43.2% 46.255.80.0/22 Lepida S.c.p.A. IT ... 200020 31638 42.9% 23.206.96.0/20 Akamai International, BV Amsterdam Provincie Noord-Holland NL ... 200020 20940 16625 42.9% 23.206.80.0/20 Akamai International, BV Amsterdam Provincie Noord-Holland NL ... 200020 20940 16625 42.9% 23.206.116.0/23 Akamai International, BV Amsterdam Provincie Noord-Holland NL ... 200020 20940 16625 42.9% 23.206.112.0/22 Akamai International, BV Amsterdam Provincie Noord-Holland NL ... 200020 20940 16625 42.6% 2.21.40.0/22 Akamai Technologies Frankfurt am Main Hessen DE ... 200020 20940 16625 42.4% 95.100.96.0/23 Akamai Technologies Amsterdam Provincie Noord-Holland NL ... 200020 20940 42.4% 95.100.160.0/22 Akamai Technologies ... 200020 20940 16625 42.4% 95.100.128.0/20 Akamai Technologies ... 200020 20940 16625 42.1% 95.100.98.0/23 Akamai Technologies Amsterdam Provincie Noord-Holland NL ... 200020 20940 16625 41.8% 92.123.250.0/24 Akamai Technologies ... 200020 20940 41.3% 88.221.161.0/24 Akamai Technologies Sofia Sofiya-Grad BG ... 200020 20940 40.0% 95.101.39.0/24 Akamai Technologies Amsterdam Provincie Noord-Holland NL ... 200020 20940 40.0% 95.101.124.0/22 Akamai Technologies Amsterdam Provincie Noord-Holland NL ... 200020 20940 40.0% 95.101.0.0/22 Akamai Technologies Amsterdam Provincie Noord-Holland NL ... 200020 20940 40.0% 92.123.232.0/22 Akamai Technologies ... 200020 20940 40.0% 92.122.84.0/22 Akamai Technologies Amsterdam Provincie Noord-Holland NL ... 200020 20940 40.0% 88.221.184.0/21 Akamai Technologies Amsterdam Provincie Noord-Holland NL ... 200020 20940 40.0% 69.192.64.0/20 Akamai International, BV Amsterdam Provincie Noord-Holland NL ... 200020 20940 40.0% 104.70.0.0/20 Akamai International, BV Amsterdam Provincie Noord-Holland NL ... 200020 20940 40.0% 104.69.240.0/20 Akamai International, BV Amsterdam Provincie Noord-Holland NL ... 200020 20940 40.0% 104.64.32.0/20 Akamai International, BV NL ... 200020 20940 40.0% 104.110.189.0/24 Akamai International, BV Amsterdam Provincie Noord-Holland NL ... 200020 20940 39.7% 23.48.88.0/22 Akamai International, BV Amsterdam Provincie Noord-Holland NL ... 200020 20940 39.7% 23.2.112.0/20 Akamai International, BV Amsterdam Provincie Noord-Holland NL ... 200020 20940 39.7% 2.20.24.0/22 Akamai Technologies Amsterdam Provincie Noord-Holland NL ... 200020 20940 39.7% 2.19.176.0/20 Akamai Technologies Amsterdam Provincie Noord-Holland NL ... 200020 20940 39.7% 2.17.224.0/20 Akamai Technologies Amsterdam Provincie Noord-Holland NL ... 200020 20940 39.7% 2.16.94.0/23 Akamai Technologies Amsterdam Provincie Noord-Holland NL ... 200020 20940 39.7% 2.16.84.0/23 Akamai Technologies Amsterdam Provincie Noord-Holland NL ... 200020 20940 39.7% 197.157.19.0/24 Africell Uganda Limited Kampala Central Region UG ... 200020 30844 36991 39.4% 23.67.78.0/23 Akamai International, BV Amsterdam Provincie Noord-Holland NL ... 200020 20940 39.4% 23.215.9.0/24 Akamai International, BV Amsterdam Provincie Noord-Holland NL ... 200020 20940 37.0% 82.139.96.0/19 Lijbrandt Telecom Netblock-02 Amsterdam Provincie Noord-Holland NL ... 200020 41887 37.0% 82.139.64.0/19 Lijbrandt Telecom Netblock-01 Amsterdam Provincie Noord-Holland NL ... 200020 41887 37.0% 81.23.230.0/24 OLD prolocation.net netblock - MIGRATED Amsterdam Provincie Noord-Holland NL ... 200020 41887 37.0% 136.143.0.0/17 RIPE Network Coordination Centre NL ... 200020 15435 36.8% 94.228.136.0/21 Prolocation B.V. Amsterdam Provincie Noord-Holland NL ... 200020 41887 36.8% 81.23.231.0/24 OLD prolocation.net netblock - MIGRATED Amsterdam Provincie Noord-Holland NL ... 200020 41887 36.8% 62.204.80.0/20 Prolocation B.V. Amsterdam Provincie Noord-Holland NL ... 200020 41887 36.8% 62.204.64.0/20 Prolocation B.V. Amsterdam Provincie Noord-Holland NL ... 200020 41887 36.8% 213.132.208.0/20 CJ2 Hosting B.V. Amsterdam Provincie Noord-Holland NL ... 200020 41887 36.8% 213.132.192.0/20 CJ2 Hosting B.V. Amsterdam Provincie Noord-Holland NL ... 200020 41887 36.5% 94.228.128.0/21 Prolocation B.V. Amsterdam Provincie Noord-Holland NL ... 200020 41887 36.5% 85.119.108.0/22 VitrumNet BV Amsterdam Provincie Noord-Holland NL ... 200020 41887 36.5% 85.119.104.0/22 VitrumNet BV Amsterdam Provincie Noord-Holland NL ... 200020 41887 36.5% 62.241.9.0/24 Postecom S.p.A. IT ... 200020 15720 36.5% 62.241.8.0/24 Postecom S.p.A. IT ... 200020 15720 36.5% 62.241.3.0/24 Initial allocation for POSTECOM IT ... 200020 15720 36.5% 62.241.2.0/24 Initial allocation for POSTECOM IT ... 200020 15720 36.5% 62.241.0.0/24 Initial allocation for POSTECOM IT ... 200020 15720 36.5% 197.155.230.0/24 LIQUID BROADBAND (Pt-Pt FIBRE) Harare Harare Province ZW ... 200020 30844 36.5% 178.22.84.0/22 Prolocation B.V. Amsterdam Provincie Noord-Holland NL ... 200020 41887 36.5% 178.22.80.0/22 Prolocation B.V. Amsterdam Provincie Noord-Holland NL ... 200020 41887 36.2% 62.241.7.0/24 Postecom S.p.A. IT ... 200020 15720 36.2% 62.241.6.0/24 PosteCom S.p.A. Rome Lazio IT ... 200020 15720 36.2% 41.60.0.0/16 Liquid Telecommunications Operations Limited ZM ... 200020 30844 35.7% 62.241.5.0/24 PosteCom S.p.A. Rome Lazio IT ... 200020 15720 34.4% 93.117.192.0/18 Vodafone Libertel B.V. NL ... 200020 33915 34.1% 5.83.0.0/21 H4Hosting BV Amsterdam Provincie Noord-Holland NL ... 200020 51050 33.8% 88.202.164.0/22 OPENFIBER B.V. NL ... 200020 41887 33.8% 82.139.64.0/18 KPN B.V. NL ... 200020 41887 33.6% 145.128.224.0/19 RoutIT Ede Provincie Gelderland NL ... 200020 28685 33.3% 94.228.142.0/23 Prolocation B.V. Amsterdam Provincie Noord-Holland NL ... 200020 41887 33.3% 62.204.94.0/23 Prolocation B.V. Amsterdam Provincie Noord-Holland NL ... 200020 41887 33.3% 185.40.96.0/23 OPENFIBER B.V. Amsterdam Provincie Noord-Holland NL ... 200020 41887 33.0% 5.199.188.0/22 AFC Ajax NV NL ... 200020 33915 32.8% 91.241.29.0/24 Comvision B.V. NL ... 200020 33915 32.8% 136.144.23.0/24 STICHTING-ABRONA-136-144-23-0 Huis ter Heide Provincie Utrecht NL ... 200020 33915 32.5% 92.42.236.0/22 Open Line BV NL ... 200020 33915 32.5% 92.42.232.0/22 Open Line BV Doetinchem Provincie Gelderland NL ... 200020 33915 32.5% 85.88.96.0/19 Vodafone Libertel B.V. NL ... 200020 33915 32.5% 83.167.192.0/19 Vodafone Libertel B.V. Amsterdam Provincie Noord-Holland NL ... 200020 33915 32.5% 83.137.136.0/21 Vodafone Libertel B.V. Amsterdam Provincie Noord-Holland NL ... 200020 33915 32.5% 80.112.192.0/18 Vodafone Libertel B.V. Amsterdam Provincie Noord-Holland NL ... 200020 33915 32.5% 37.235.8.0/21 Nexct Services BV Utrecht Provincie Utrecht NL ... 200020 33915 32.5% 193.176.208.0/24 Heijmans Nederland B.V. NL ... 200020 33915 32.5% 185.159.188.0/22 OmnicomMediaGroup Nederland B.V. NL ... 200020 33915 32.5% 159.100.64.0/18 Vodafone Enterprise Solutions Prefix8 Amsterdam Provincie Noord-Holland NL ... 200020 33915 32.5% 144.2.254.0/23 Audax Amsterdam Provincie Noord-Holland NL ... 200020 33915 32.5% 144.2.252.0/22 Audax Amsterdam Provincie Noord-Holland NL ... 200020 33915 32.2% 77.49.0.0/17 FORTHnet SA GR ... 200020 1241 32.2% 213.34.128.0/19 Vodafone Libertel B.V. Amsterdam Provincie Noord-Holland NL ... 200020 33915 32.2% 213.16.144.0/20 ADSL LLU POOL GR ... 200020 1241 32.2% 212.78.192.0/19 Vodafone Libertel B.V. Amsterdam Provincie Noord-Holland NL ... 200020 33915 32.2% 212.251.64.0/18 FORTHnet SA GR ... 200020 1241 32.2% 194.53.32.0/20 Heijmans Nederland B.V. NL ... 200020 33915 31.4% 94.134.32.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 94.134.152.0/21 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 89.247.164.0/22 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 89.247.0.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 89.246.16.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 89.246.124.0/22 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 89.245.96.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 89.245.80.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 89.245.64.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 89.245.48.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 89.245.0.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 89.244.80.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 89.244.240.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 89.244.224.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 89.244.160.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 88.130.96.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 88.130.80.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 88.130.216.0/21 Versatel Deutschland DE ... 200020 8881 31.4% 88.130.176.0/21 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 87.123.96.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 87.123.64.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 87.123.48.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 87.123.32.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 87.123.240.0/22 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 87.123.176.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 87.123.16.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 87.123.128.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 87.122.96.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 87.122.80.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 87.122.32.0/19 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 87.122.224.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 87.122.208.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 87.122.144.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 87.122.0.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 83.135.96.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 83.135.80.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 83.135.64.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 83.135.232.0/21 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 83.135.192.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 83.135.176.0/22 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 83.135.144.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.4% 82.207.192.0/19 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 94.134.48.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 94.134.216.0/21 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 94.134.172.0/22 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 94.134.148.0/22 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 94.134.144.0/22 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 94.134.0.0/19 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 89.247.96.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 89.247.80.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 89.247.64.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 89.247.48.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 89.247.32.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 89.247.192.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 89.247.168.0/21 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 89.247.16.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 89.247.160.0/22 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 89.247.152.0/21 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 89.247.120.0/22 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 89.247.112.0/21 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 89.246.96.0/21 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 89.246.56.0/21 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 89.246.192.0/19 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 89.246.184.0/21 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 89.246.116.0/22 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 89.246.0.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 89.245.32.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 89.245.208.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 89.245.192.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 89.245.176.0/21 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 89.245.16.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 89.244.76.0/22 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 89.244.208.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 89.244.192.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 89.244.176.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 89.244.120.0/21 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 88.130.64.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 88.130.32.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 88.130.16.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 88.130.144.0/21 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 88.130.136.0/21 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 88.130.112.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 88.130.0.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 87.123.80.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 87.123.244.0/22 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 87.123.224.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 87.123.216.0/21 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 87.123.160.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 87.123.144.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 87.123.112.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 87.123.0.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 87.122.64.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 87.122.24.0/21 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 87.122.240.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 87.122.20.0/22 1&1 Versatel Deutschland GmbH Münster Nordrhein-Westfalen DE ... 200020 8881 31.2% 87.122.192.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 87.122.176.0/21 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 87.122.112.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 83.135.8.0/21 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 83.135.208.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 83.135.184.0/21 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 83.135.168.0/21 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 83.135.128.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 83.135.112.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 82.207.240.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 77.174.0.0/16 KPN B.V. NL ... 200020 12871 31.2% 62.214.240.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 62.214.224.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 46.227.232.0/21 KPN B.V. NL ... 200020 12871 31.2% 46.142.96.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 46.142.80.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 46.142.64.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 46.142.224.0/19 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 46.142.176.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 46.142.160.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 46.142.144.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 46.142.128.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 46.142.112.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 31.2% 37.188.64.0/20 KPN B.V. NL ... 200020 12871 31.2% 213.197.0.0/18 KPN B.V. Amsterdam Provincie Noord-Holland NL ... 200020 12871 31.2% 213.148.224.0/19 KPN B.V. NL ... 200020 12871 31.2% 195.64.64.0/20 KPN B.V. Amsterdam Provincie Noord-Holland NL ... 200020 12871 31.2% 141.105.0.0/20 KPN B.V. NL ... 200020 12871 30.9% 94.229.48.0/20 KPN B.V. NL ... 200020 12871 30.9% 85.113.224.0/19 KPN B.V. Amsterdam Provincie Noord-Holland NL ... 200020 12871 30.9% 84.39.0.0/19 KPN B.V. Amsterdam Provincie Noord-Holland NL ... 200020 12871 30.9% 31.172.144.0/21 Luxembourg Online S.A. LU ... 200020 8632 30.9% 128.127.32.0/20 KPN B.V. NL ... 200020 12871 30.9% 109.72.32.0/20 KPN B.V. Amsterdam Provincie Noord-Holland NL ... 200020 12871 30.6% 94.103.216.0/21 Luxembourg Online S.A. LU ... 200020 8632 30.6% 85.10.96.0/19 Dynamic IPs ADSL end users LU ... 200020 8632 30.4% 94.103.208.0/21 Luxembourg Online S.A. LU ... 200020 8632 30.4% 185.6.232.0/22 Luxembourg Online S.A. LU ... 200020 8632 29.6% 94.142.208.0/21 Breedband Nederland B.V. Amsterdam Provincie Noord-Holland NL ... 200020 5524 29.6% 91.189.208.0/22 Aaldering ICT NL ... 200020 5524 29.6% 46.231.40.0/21 Onsight Solutions B.V. NL ... 200020 5524 29.6% 46.226.56.0/21 Breedband Nederland B.V. NL ... 200020 5524 29.6% 31.3.8.0/21 Breedband Nederland B.V. Amsterdam Provincie Noord-Holland NL ... 200020 5524 29.3% 5.133.84.0/22 Horizon Telecom B.V. NL ... 200020 43366 60880 28.8% 92.8.0.0/15 Carphone Warehouse Broadband Services GB ... 200020 13285 13285 13285 13285 28.8% 92.8.0.0/14 Carphone Warehouse Broadband Services GB ... 200020 13285 13285 13285 13285 28.8% 92.6.0.0/15 Carphone Warehouse Broadband Services GB ... 200020 13285 13285 13285 13285 28.8% 92.4.0.0/15 Carphone Warehouse Broadband Services GB ... 200020 13285 13285 13285 13285 28.8% 92.4.0.0/14 Carphone Warehouse Broadband Services GB ... 200020 13285 13285 13285 13285 28.8% 92.30.0.0/15 TalkTalk Communications Limited GB ... 200020 13285 13285 13285 13285 28.8% 92.28.0.0/15 Opal Telecom DSL GB ... 200020 13285 13285 13285 13285 28.8% 92.26.0.0/15 Opal Telecom DSL GB ... 200020 13285 13285 13285 13285 28.8% 92.24.0.0/15 Opal Telecom DSL GB ... 200020 13285 13285 13285 13285 28.8% 92.24.0.0/13 TalkTalk Communications Limited GB ... 200020 13285 13285 13285 13285 28.8% 92.22.0.0/15 Carphone Warehouse Broadband Services London England GB ... 200020 13285 13285 13285 13285 28.8% 92.2.0.0/15 Carphone Warehouse Broadband Services London England GB ... 200020 13285 13285 13285 13285 28.8% 92.20.0.0/15 Carphone Warehouse Broadband Services London England GB ... 200020 13285 13285 13285 13285 28.8% 92.18.0.0/15 Carphone Warehouse Broadband Services GB ... 200020 13285 13285 13285 13285 28.8% 92.16.0.0/15 Carphone Warehouse Broadband Services GB ... 200020 13285 13285 13285 13285 28.8% 92.16.0.0/13 Carphone Warehouse Broadband Services GB ... 200020 13285 13285 13285 13285 28.8% 92.16.0.0/12 TalkTalk Communications Limited GB ... 200020 13285 13285 13285 13285 28.8% 92.14.0.0/15 Carphone Warehouse Broadband Services GB ... 200020 13285 13285 13285 13285 28.8% 92.12.0.0/15 Carphone Warehouse Broadband Services GB ... 200020 13285 13285 13285 13285 28.8% 92.12.0.0/14 Carphone Warehouse Broadband Services GB ... 200020 13285 13285 13285 13285 28.8% 92.10.0.0/15 Carphone Warehouse Broadband Services GB ... 200020 13285 13285 13285 13285 28.8% 92.0.0.0/15 Carphone Warehouse Broadband Services London England GB ... 200020 13285 13285 13285 13285 28.8% 92.0.0.0/14 Carphone Warehouse Broadband Services London England GB ... 200020 13285 13285 13285 13285 28.8% 92.0.0.0/12 Carphone Warehouse Broadband Services GB ... 200020 13285 13285 13285 13285 28.5% 89.243.0.0/16 Opal Telecom DSL GB ... 200020 13285 13285 13285 13285 28.5% 89.242.0.0/16 Opal Telecom DSL GB ... 200020 13285 13285 13285 13285 28.5% 89.241.0.0/16 Opal Telecom DSL GB ... 200020 13285 13285 13285 13285 28.5% 89.240.0.0/16 Opal Telecom DSL Network GB ... 200020 13285 13285 13285 13285 28.5% 78.150.0.0/15 Opal Telecom DSL London England GB ... 200020 13285 13285 13285 13285 28.5% 78.148.0.0/15 Opal Telecom DSL London England GB ... 200020 13285 13285 13285 13285 28.5% 78.146.0.0/15 TalkTalk Communications Limited London England GB ... 200020 13285 13285 13285 13285 28.5% 78.144.0.0/15 TalkTalk Communications Limited London England GB ... 200020 13285 13285 13285 13285 28.2% 84.13.128.0/17 Opal Telecom DSL Network GB ... 200020 13285 13285 13285 13285 28.2% 84.13.0.0/17 Opal Telecom DSL Network GB ... 200020 13285 13285 13285 13285 28.2% 2.98.0.0/15 TalkTalk Communications Limited GB ... 200020 13285 13285 13285 13285 28.2% 2.96.0.0/15 TalkTalk Communications Limited GB ... 200020 13285 13285 13285 13285 28.2% 2.102.0.0/15 TalkTalk Communications Limited GB ... 200020 13285 13285 13285 13285 28.2% 2.100.0.0/15 TalkTalk Communications Limited GB ... 200020 13285 13285 13285 13285 26.1% 89.242.0.0/15 Opal Telecom DSL GB ... 200020 13285 13285 13285 13285 26.1% 89.240.0.0/15 TalkTalk Communications Limited GB ... 200020 13285 13285 13285 13285 26.1% 85.222.231.0/24 XL Internet Services B.V. Turnhout Flanders BE ... 200020 49685 26.1% 78.148.0.0/14 Opal Telecom DSL London England GB ... 200020 13285 13285 13285 13285 26.1% 78.144.0.0/14 TalkTalk Communications Limited London England GB ... 200020 13285 13285 13285 13285 26.1% 195.224.0.0/16 Daisy Communications Ltd GB ... 200020 5413 26.1% 185.3.211.0/24 XL Internet Services B.V. Amsterdam Provincie Noord-Holland NL ... 200020 49685 25.8% 82.195.96.0/19 Daisy Communications Ltd GB ... 200020 5413 25.8% 62.44.64.0/19 Daisy Communications Ltd GB ... 200020 5413 25.8% 194.143.160.0/19 Daisy Communications Ltd London England GB ... 200020 5413 25.8% 194.1.210.0/24 Daisy Data Centre Solutions Limited London England GB ... 200020 5413 25.8% 176.35.0.0/16 Daisy Communications Ltd GB ... 200020 5413 25.6% 93.95.104.0/21 Daisy Communications Ltd GB ... 200020 5413 25.6% 93.92.120.0/21 Daisy Communications Ltd GB ... 200020 5413 25.6% 91.213.216.0/24 iForce Ltd London England GB ... 200020 5413 25.6% 89.145.192.0/18 Daisy Communications Ltd GB ... 200020 5413 25.6% 83.219.32.0/19 Daisy Communications Ltd London England GB ... 200020 5413 25.6% 78.41.208.0/21 Daisy Communications Ltd GB ... 200020 5413 25.6% 78.141.0.0/18 Daisy Communications Ltd GB ... 200020 5413 25.6% 77.75.238.0/24 Six Degrees Technology Group Limited Eastbourne England GB ... 200020 5413 25.6% 77.75.234.0/23 Six Degrees Technology Group Limited Eastbourne England GB ... 200020 5413 25.6% 77.44.0.0/17 Daisy Communications Ltd GB ... 200020 5413 25.6% 72.246.148.0/23 Akamai International, BV London England GB ... 200020 20940 25.6% 72.246.144.0/22 Akamai International, BV London England GB ... 200020 20940 25.6% 62.72.128.0/19 Daisy Communications Ltd London England GB ... 200020 5413 25.6% 62.232.0.0/16 Daisy Communications Ltd GB ... 200020 5413 25.6% 2.19.60.0/22 Akamai Technologies ... 200020 20940 25.6% 212.88.32.0/19 Daisy Communications Ltd London England GB ... 200020 5413 25.6% 212.241.128.0/17 Daisy Communications Ltd London England GB ... 200020 5413 25.6% 212.102.96.0/19 RADIAL COMMERCE LIMITED GB ... 200020 5413 25.6% 195.49.180.0/22 Dorset County Council Dorchester England GB ... 200020 5413 25.6% 195.226.32.0/19 Daisy Communications Ltd GB ... 200020 5413 25.6% 195.206.164.0/22 Total Web Solutions Ltd GB ... 200020 5413 25.6% 195.147.0.0/16 Daisy Communications Ltd GB ... 200020 5413 25.6% 194.79.243.0/24 Daisy Data Centre Solutions Limited London England GB ... 200020 5413 25.6% 194.79.242.0/24 Daisy Data Centre Solutions Limited London England GB ... 200020 5413 25.6% 194.79.240.0/24 Daisy Data Centre Solutions Limited London England GB ... 200020 5413 25.6% 194.154.160.0/19 Daisy Communications Ltd GB ... 200020 5413 25.6% 194.126.64.0/19 Daisy Communications Ltd GB ... 200020 5413 25.6% 193.242.116.0/24 Daisy Communications Ltd GB ... 200020 5413 25.6% 193.242.115.0/24 Daisy Communications Ltd GB ... 200020 5413 25.6% 193.242.113.0/24 Daisy Communications Ltd GB ... 200020 5413 25.6% 193.22.87.0/24 Westpoint Ltd GB ... 200020 5413 25.6% 185.166.252.0/22 Azur GCS AG GB ... 200020 5413 25.6% 185.153.204.0/22 Serversure Limited Sheffield England GB ... 200020 5413 25.6% 152.89.48.0/22 Digital Network Solutions Ltd GB ... 200020 5413 25.6% 141.105.192.0/18 DSL GB ... 200020 5413 25.6% 109.170.128.0/17 Daisy Communications Ltd GB ... 200020 5413 25.3% 94.30.0.0/17 Daisy Communications Ltd GB ... 200020 5413 25.3% 91.220.141.0/24 Punch Partnerships (PTL) Limited Burton upon Trent England GB ... 200020 5413 25.3% 85.91.36.0/22 Moose Internet Services Ltd. GB ... 200020 5413 25.3% 80.89.80.0/20 Daisy Communications Ltd GB ... 200020 5413 25.3% 80.234.128.0/17 Daisy Communications Ltd London England GB ... 200020 5413 25.3% 78.156.74.0/23 Firefly Enterprises Ltd London England GB ... 200020 5413 25.3% 78.156.64.0/19 Firefly Enterprises Ltd GB ... 200020 5413 25.3% 77.75.236.0/22 Six Degrees Technology Group Limited Eastbourne England GB ... 200020 5413 25.3% 77.107.128.0/18 Daisy Communications Ltd GB ... 200020 5413 25.3% 62.69.32.0/19 Daisy Communications Ltd GB ... 200020 5413 25.3% 62.201.42.0/24 Unilabs external address space SE ... 200020 57208 58343 25.3% 62.105.64.0/18 Daisy Communications Ltd GB ... 200020 5413 25.3% 5.179.96.0/20 Glide Utilities Ltd. GB ... 200020 5413 25.3% 23.64.32.0/20 Akamai International, BV London England GB ... 200020 20940 25.3% 23.64.16.0/20 Akamai International, BV London England GB ... 200020 20940 25.3% 2.22.146.0/24 Akamai Technologies London England GB ... 200020 20940 25.3% 217.78.144.0/20 RDS Global Limited GB ... 200020 5413 25.3% 217.67.48.0/20 Daisy Data Centre Solutions Limited London England GB ... 200020 5413 25.3% 2.16.162.0/24 Akamai Technologies London England GB ... 200020 20940 25.3% 213.205.128.0/18 Daisy Communications Ltd London England GB ... 200020 5413 25.3% 212.35.224.0/19 Daisy Communications Ltd London England GB ... 200020 5413 25.3% 212.22.96.0/24 @UK PLC LIR Tadley England GB ... 200020 5413 25.3% 212.103.224.0/19 Daisy Communications Ltd GB ... 200020 5413 25.3% 195.70.64.0/19 Daisy Communications Ltd London England GB ... 200020 5413 25.3% 195.39.192.0/24 Baniftec Limited Westerham England GB ... 200020 5413 25.3% 195.38.64.0/19 Daisy Communications Ltd GB ... 200020 5413 25.3% 195.206.163.0/24 Total Web Solutions Ltd GB ... 200020 5413 25.3% 194.62.32.0/24 Historic Buildings and Monumnets Commssion for England Swindon England GB ... 200020 5413 25.3% 194.153.0.0/19 Daisy Communications Ltd London England GB ... 200020 5413 25.3% 193.192.64.0/19 Daisy Communications Ltd GB ... 200020 5413 25.3% 193.192.34.0/23 Daisy Communications Ltd London England GB ... 200020 5413 25.3% 192.70.242.0/24 International Union of Crystallography Chester England GB ... 200020 5413 25.3% 185.57.79.0/24 Octopus Telecom Ltd GB ... 200020 5413 25.3% 185.243.60.0/24 Multidata Ltd Sunderland England GB ... 200020 5413 25.3% 185.223.184.0/22 Accord Housing Assocation Limited GB ... 200020 5413 25.3% 185.196.204.0/22 Daisy Data Centre Solutions Limited GB ... 200020 5413 25.0% 2.17.38.0/24 Akamai Technologies ... 200020 20940 25.0% 2.16.109.0/24 Akamai Technologies ... 200020 20940 24.8% 92.8.0.0/13 Carphone Warehouse Broadband Services GB ... 200020 13285 13285 13285 13285 24.8% 92.28.0.0/14 TalkTalk Communications Limited GB ... 200020 13285 13285 13285 13285 24.8% 92.24.0.0/14 Opal Telecom DSL GB ... 200020 13285 13285 13285 13285 24.8% 92.20.0.0/14 Carphone Warehouse Broadband Services GB ... 200020 13285 13285 13285 13285 24.8% 92.16.0.0/14 Carphone Warehouse Broadband Services GB ... 200020 13285 13285 13285 13285 24.8% 92.0.0.0/13 Carphone Warehouse Broadband Services GB ... 200020 13285 13285 13285 13285 24.5% 94.198.29.0/24 Sentia B.V. NL ... 200020 34762 24.5% 185.173.120.0/22 TalkTalk Communications Limited GB ... 200020 13285 13285 13285 13285 24.0% 192.121.173.0/24 Telecomputing AB SE ... 200020 57208 58343 23.2% 2.21.243.0/24 Akamai Technologies Amsterdam Provincie Noord-Holland NL ... 200020 20940 22.6% 23.62.224.0/24 Akamai International, BV Amsterdam Provincie Noord-Holland NL ... 200020 20940 22.4% 80.66.192.0/22 Stadtwerke Elmshorn DE ... 200020 13101 22.4% 2.96.0.0/14 TalkTalk Communications Limited GB ... 200020 13285 13285 13285 13285 22.4% 23.62.98.0/23 Akamai International, BV Amsterdam Provincie Noord-Holland NL ... 200020 20940 22.4% 23.62.100.0/24 Akamai International, BV Amsterdam Provincie Noord-Holland NL ... 200020 20940 22.4% 2.100.0.0/14 TalkTalk Communications Limited GB ... 200020 13285 13285 13285 13285 22.4% 104.119.34.0/23 Akamai International, BV Amsterdam Provincie Noord-Holland NL ... 200020 20940 22.4% 104.118.214.0/23 Akamai International, BV Amsterdam Provincie Noord-Holland NL ... 200020 20940 22.1% 62.241.4.0/24 PosteCom S.p.A. Rome Lazio IT ... 200020 15720 22.1% 104.118.26.0/24 Akamai International, BV Amsterdam Provincie Noord-Holland NL ... 200020 20940 21.8% 23.12.16.0/20 Akamai Technologies, Inc. US ... 200020 7713 20940 20940 21.8% 23.11.112.0/20 Akamai Technologies, Inc. Tokyo Tōkyō-to JP ... 200020 7713 20940 20940 21.8% 185.158.140.0/22 Net Global Srl IT ... 200020 50316 21.8% 185.157.24.0/22 Net Global Srl IT ... 200020 50316 21.6% 62.93.0.0/19 Stadtwerke Barmstedt DE ... 200020 13101 21.6% 23.15.15.0/24 Akamai Technologies, Inc. Jakarta Daerah Khusus Ibukota Jakarta ID ... 200020 7713 20940 20940 21.6% 185.56.224.0/22 Datadigest B.V. NL ... 200020 41887 21.3% 92.0.0.0/11 TalkTalk Communications Limited GB ... 200020 13285 13285 13285 13285 21.3% 89.240.0.0/14 TalkTalk Communications Limited GB ... 200020 13285 13285 13285 13285 21.3% 86.103.0.0/16 ennit server GmbH DE ... 200020 13101 21.3% 82.97.128.0/18 ennit server GmbH DE ... 200020 13101 21.3% 78.144.0.0/13 TalkTalk Communications Limited GB ... 200020 13285 13285 13285 13285 21.3% 5.178.112.0/21 Datacenter Groningen B.V. NL ... 200020 59554 21.3% 2.96.0.0/13 TalkTalk Communications Limited GB ... 200020 13285 13285 13285 13285 21.3% 23.9.192.0/20 Akamai Technologies, Inc. Jakarta Daerah Khusus Ibukota Jakarta ID ... 200020 7713 20940 20940 21.3% 23.0.176.0/20 Akamai Technologies, Inc. Jakarta Daerah Khusus Ibukota Jakarta ID ... 200020 7713 20940 20940 21.3% 23.0.172.0/23 Akamai Technologies, Inc. Jakarta Daerah Khusus Ibukota Jakarta ID ... 200020 7713 20940 20940 21.3% 23.0.168.0/22 Akamai Technologies, Inc. Jakarta Daerah Khusus Ibukota Jakarta ID ... 200020 7713 20940 20940 21.3% 185.94.168.0/22 CJ2 Hosting B.V. NL ... 200020 41887 21.3% 185.93.12.0/22 Xolphin B.V. NL ... 200020 41887 21.3% 185.85.112.0/22 VitrumNet BV NL ... 200020 41887 21.3% 185.63.164.0/22 Prolocation B.V. Amsterdam Provincie Noord-Holland NL ... 200020 41887 21.3% 185.56.224.0/23 Datadigest B.V. Delft Provincie Zuid-Holland NL ... 200020 41887 21.0% 84.13.0.0/16 TalkTalk Communications Limited London England GB ... 200020 13285 13285 13285 13285 21.0% 23.0.162.0/24 Akamai Technologies, Inc. Jakarta Daerah Khusus Ibukota Jakarta ID ... 200020 7713 20940 20940 21.0% 104.76.182.0/24 Akamai Technologies, Inc. Jakarta Daerah Khusus Ibukota Jakarta ID ... 200020 7713 20940 20940 20.8% 92.31.35.0/24 Carphone Warehouse Broadband Services GB ... 200020 13285 13285 13285 13285 20.8% 62.24.128.0/17 TalkTalk Communications Limited London England GB ... 200020 13285 13285 13285 13285 20.8% 217.70.192.0/20 ennit server GmbH DE ... 200020 13101 20.8% 213.178.64.0/19 ennit server GmbH DE ... 200020 13101 20.8% 213.158.96.0/19 ennit server GmbH DE ... 200020 13101 20.8% 195.42.101.0/24 Ulf Kieber DE ... 200020 13101 20.8% 194.180.18.0/24 ppi Media GmbH Preetz Schleswig-Holstein DE ... 200020 13101 20.8% 185.60.21.0/24 Network of PAYONE DC KEL02 DE ... 200020 13101 20.8% 185.119.72.0/22 Stadtwerke Barmstedt DE ... 200020 13101 20.8% 185.118.20.0/22 ennit server GmbH Kiel Schleswig-Holstein DE ... 200020 13101 20.2% 80.65.96.0/19 Previder B.V. Amsterdam Provincie Noord-Holland NL ... 200020 20847 20.2% 62.165.64.0/18 Previder B.V. Amsterdam Provincie Noord-Holland NL ... 200020 20847 20.2% 213.138.32.0/19 1&1 Versatel Deutschland GmbH Frankfurt am Main Hessen DE ... 200020 8881 20.0% 89.244.0.0/14 1&1 Versatel Deutschland GmbH DE ... 200020 8881 20.0% 84.241.128.0/18 Previder B.V. Amsterdam Provincie Noord-Holland NL ... 200020 20847 20.0% 84.19.192.0/19 1&1 Versatel Deutschland GmbH DE ... 200020 8881 20.0% 83.135.0.0/16 1&1 Versatel Deutschland GmbH DE ... 200020 8881 20.0% 82.207.128.0/17 1&1 Versatel Deutschland GmbH DE ... 200020 8881 20.0% 82.145.0.0/19 1&1 Versatel Deutschland GmbH Frankfurt am Main Hessen DE ... 200020 8881 20.0% 82.144.32.0/19 1&1 Versatel Deutschland GmbH DE ... 200020 8881 20.0% 62.220.0.0/19 1&1 Versatel Deutschland GmbH DE ... 200020 8881 20.0% 62.217.32.0/19 1&1 Versatel Deutschland GmbH DE ... 200020 8881 20.0% 62.214.0.0/16 1&1 Versatel Deutschland GmbH Frankfurt am Main Hessen DE ... 200020 8881 20.0% 46.142.0.0/16 1&1 Versatel Deutschland GmbH DE ... 200020 8881 20.0% 217.27.192.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 20.0% 213.30.192.0/18 1&1 Versatel Deutschland GmbH Frankfurt am Main Hessen DE ... 200020 8881 20.0% 195.226.96.0/19 1&1 Versatel Deutschland GmbH DE ... 200020 8881 20.0% 195.226.160.0/19 1&1 Versatel Deutschland GmbH DE ... 200020 8881 20.0% 195.202.32.0/19 1&1 Versatel Deutschland GmbH DE ... 200020 8881 20.0% 195.167.208.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 19.7% 94.134.0.0/15 1&1 Versatel Deutschland GmbH DE ... 200020 8881 19.7% 88.130.0.0/16 1&1 Versatel Deutschland GmbH DE ... 200020 8881 19.7% 87.122.0.0/15 1&1 Versatel Deutschland GmbH DE ... 200020 8881 19.7% 82.194.96.0/19 1&1 Versatel Deutschland GmbH DE ... 200020 8881 19.7% 82.140.0.0/18 1&1 Versatel Deutschland GmbH DE ... 200020 8881 19.7% 82.119.160.0/19 1&1 Versatel Deutschland GmbH DE ... 200020 8881 19.7% 80.242.160.0/19 1&1 Versatel Deutschland GmbH DE ... 200020 8881 19.7% 62.72.64.0/19 1&1 Versatel Deutschland GmbH DE ... 200020 8881 19.7% 217.199.64.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 19.7% 213.182.128.0/19 1&1 Versatel Deutschland GmbH Frankfurt am Main Hessen DE ... 200020 8881 19.7% 213.139.128.0/19 1&1 Versatel Deutschland GmbH Frankfurt am Main Hessen DE ... 200020 8881 19.7% 212.80.224.0/19 1&1 Versatel Deutschland GmbH DE ... 200020 8881 19.7% 194.99.113.0/24 Citti Handelsgesellschaft mbH & Co KG Hamburg Free and Hanseatic City of Hamburg DE ... 200020 8881 19.7% 194.6.239.0/24 Tele Columbus AG DE ... 200020 8881 19.7% 193.219.15.0/24 1&1 Versatel Deutschland GmbH DE ... 200020 8881 19.4% 89.27.128.0/17 1&1 Versatel Deutschland GmbH DE ... 200020 8881 19.4% 46.44.128.0/18 Routit BV NL ... 200020 28685 19.4% 46.189.0.0/17 1&1 Versatel Deutschland GmbH DE ... 200020 8881 19.4% 217.9.96.0/19 1&1 Versatel Deutschland GmbH DE ... 200020 8881 19.4% 217.9.32.0/19 1&1 Versatel Deutschland GmbH DE ... 200020 8881 19.4% 217.78.128.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 19.4% 217.65.16.0/20 1&1 Versatel Deutschland GmbH DE ... 200020 8881 19.4% 212.93.0.0/19 1&1 Versatel Deutschland GmbH DE ... 200020 8881 19.4% 212.7.128.0/19 1&1 Versatel Deutschland GmbH DE ... 200020 8881 19.4% 212.204.0.0/19 1&1 Versatel Deutschland GmbH DE ... 200020 8881 19.4% 185.243.68.0/22 Stadtwerke Wedel GmbH DE ... 200020 13101 19.4% 185.128.68.0/22 1&1 Versatel Deutschland GmbH DE ... 200020 8881 19.4% 145.131.160.0/19 RoutIT Ede Provincie Gelderland NL ... 200020 28685 19.2% 91.221.161.0/24 T-ICT Informatie & CommunicatieTechnologie B.V. Bunschoten Provincie Utrecht NL ... 200020 28685 19.2% 89.188.44.0/24 University of Montenegro ... 200020 12041 19.2% 89.146.0.0/18 Routit BV Amsterdam Provincie Noord-Holland NL ... 200020 28685 19.2% 37.153.192.0/18 Routit BV Amsterdam Provincie Noord-Holland NL ... 200020 28685 19.2% 213.204.224.0/21 Stipte B.V. NL ... 200020 28685 19.2% 213.144.224.0/19 Routit BV Amsterdam Provincie Noord-Holland NL ... 200020 28685 19.2% 212.121.96.0/19 Routit BV Amsterdam Provincie Noord-Holland NL ... 200020 28685 19.2% 185.144.196.0/22 Xcellent Automatisering B.V. NL ... 200020 28685 19.2% 185.106.152.0/22 Helden Van Nu BV NL ... 200020 28685 19.2% 145.131.192.0/18 RoutIT Ede Provincie Gelderland NL ... 200020 28685 19.2% 145.128.160.0/19 RoutIT Ede Provincie Gelderland NL ... 200020 28685 18.9% 94.190.200.0/21 Helden Van Nu BV NL ... 200020 28685 18.9% 84.246.0.0/18 Routit BV Amsterdam Provincie Noord-Holland NL ... 200020 28685 18.9% 37.0.80.0/20 Routit BV Amsterdam Provincie Noord-Holland NL ... 200020 28685 18.9% 213.247.64.0/18 Routit BV Amsterdam Provincie Noord-Holland NL ... 200020 28685 18.9% 213.204.192.0/20 Stipte B.V. Amsterdam Provincie Noord-Holland NL ... 200020 28685 18.9% 145.131.64.0/18 RoutIT Ede Provincie Gelderland NL ... 200020 28685 18.9% 145.131.128.0/19 RoutIT Ede Provincie Gelderland NL ... 200020 28685 18.9% 145.128.192.0/19 KPN B.V. NL ... 200020 28685 18.6% 91.246.26.0/23 Datatech UK Ltd GB ... 200020 47622 18.6% 5.199.0.0/17 Datatech UK Ltd GB ... 200020 47622 18.6% 46.248.128.0/23 COLT Telecom US ... 200020 8220 18.4% 199.254.48.0/24 Afilias, Inc. ... 200020 12041 18.1% 65.22.97.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.93.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.89.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.85.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.81.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.77.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.69.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.65.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.61.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.57.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.53.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.49.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.45.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.37.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.33.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.29.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.25.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.245.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.241.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.237.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.233.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.229.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.225.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.221.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.217.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.213.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.21.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.209.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.205.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.201.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.193.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.189.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.185.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.181.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.177.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.173.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.17.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.169.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.161.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.157.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.153.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.149.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.145.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.141.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.137.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.133.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.129.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.125.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.121.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.117.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.113.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.109.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.105.0/24 Afilias, Inc. US ... 200020 12041 18.1% 65.22.1.0/24 Afilias, Inc. ... 200020 12041 18.1% 65.22.101.0/24 Afilias, Inc. US ... 200020 12041 18.1% 199.254.60.0/24 Afilias, Inc. ... 200020 12041 18.1% 199.254.52.0/24 Afilias, Inc. ... 200020 12041 18.1% 199.254.28.0/24 Afilias, Inc. ... 200020 12041 18.1% 199.253.60.0/24 Afilias, Inc. ... 200020 12041 18.1% 199.253.56.0/24 Afilias, Inc. ... 200020 12041 18.1% 199.19.54.0/24 Afilias, Inc. ... 200020 12041 18.1% 199.182.1.0/24 Afilias, Inc. ... 200020 12041 18.1% 199.115.153.0/24 Afilias, Inc. ... 200020 12041 17.6% 178.239.16.0/22 Centile Telecom Applications SAS NL ... 200020 39647 15426 17.0% 46.31.8.0/21 IX Networks BV io NL ... 200020 20562 12561 17.0% 185.39.196.0/24 Unlimited Network Odessa Odessa Odes’ka Oblast’ UA ... 200020 15772 24685 16.2% 37.1.88.0/21 MCKAYCOM LTD GB ... 200020 50763 15.7% 193.107.204.0/22 MCKAYCOM LTD London England GB ... 200020 50763 15.7% 185.128.248.0/22 MCKAYCOM LTD SI ... 200020 50763 15.4% 192.75.207.0/24 PixelMotion Images Inc. CA ... 200020 50763 15.2% 65.22.7.0/24 Afilias, Inc. US ... 200020 12041 14.9% 57.67.160.0/19 Orange Business Services-SITA Internet services - BE aggregate BE ... 200020 5583 51964 14.6% 57.94.128.0/20 Orange Business Services-SITA Internet services - TR aggregate TR ... 200020 5583 51964 14.6% 195.61.96.0/19 Orange Business Services Internet services - NL aggregate NL ... 200020 5583 51964 14.6% 194.235.64.0/19 Orange Business Services Internet services - NL aggregate NL ... 200020 5583 51964 14.6% 194.235.216.0/21 Equant Inc. NL ... 200020 5583 51964 14.6% 194.235.110.0/23 Equant Inc. NL ... 200020 5583 51964 14.4% 62.229.96.0/20 Orange Business Services Internet services - NL aggregate NL ... 200020 5583 51964 14.4% 62.229.144.0/20 Orange Business Services Internet services - NL aggregate NL ... 200020 5583 51964 14.4% 62.229.112.0/21 Orange Business Services Internet services - LU aggregate LU ... 200020 5583 51964 14.4% 57.88.112.0/20 Orange Business Services-SITA Internet services - IL aggregate Jerusalem Jerusalem IL ... 200020 5583 51964 14.4% 57.79.224.0/20 Orange Business Services-SITA Internet services - BE aggregate Vatican City VA ... 200020 5583 51964 14.4% 57.67.224.0/19 Orange Business Services-SITA Internet services - LU aggregate LU ... 200020 5583 51964 14.4% 57.67.192.0/19 Orange Business Services-SITA Internet services - NL aggregate NL ... 200020 5583 51964 14.4% 194.235.246.0/23 Equant Inc. ... 200020 5583 51964 14.4% 194.235.232.0/22 Equant Inc. NL ... 200020 5583 51964 14.4% 194.235.226.0/24 Equant Inc. NL ... 200020 5583 51964 14.4% 194.235.224.0/23 Equant Inc. NL ... 200020 5583 51964 14.4% 194.235.212.0/22 Equant Inc. NL ... 200020 5583 51964 14.4% 194.235.210.0/23 Equant Inc. NL ... 200020 5583 51964 14.4% 194.235.112.0/20 Equant Inc. ... 200020 5583 51964 13.8% 65.22.66.0/24 Afilias, Inc. US ... 200020 12041 13.8% 199.19.53.0/24 Afilias, Inc. ... 200020 12041 13.6% 65.22.98.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.94.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.90.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.86.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.82.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.8.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.78.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.70.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.62.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.58.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.54.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.50.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.46.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.34.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.30.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.26.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.246.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.242.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.238.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.234.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.230.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.226.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.222.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.22.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.218.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.214.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.210.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.206.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.2.0/24 Afilias, Inc. ... 200020 12041 13.6% 65.22.202.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.194.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.190.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.186.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.182.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.18.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.178.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.174.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.170.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.162.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.158.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.154.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.150.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.146.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.142.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.138.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.134.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.130.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.126.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.122.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.118.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.114.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.110.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.106.0/24 Afilias, Inc. US ... 200020 12041 13.6% 65.22.102.0/24 Afilias, Inc. US ... 200020 12041 13.6% 62.204.64.0/19 Prolocation B.V. NL ... 200020 41887 13.6% 31.22.120.0/21 Conostix S.A. Luxembourg District de Luxembourg LU ... 200020 197692 13.6% 199.254.61.0/24 Afilias, Inc. ... 200020 12041 13.6% 199.254.57.0/24 Afilias, Inc. ... 200020 12041 13.6% 199.254.53.0/24 Afilias, Inc. ... 200020 12041 13.6% 199.254.49.0/24 Afilias, Inc. ... 200020 12041 13.6% 199.254.29.0/24 Afilias, Inc. ... 200020 12041 13.6% 199.253.61.0/24 Afilias, Inc. ... 200020 12041 13.6% 199.253.57.0/24 Afilias, Inc. ... 200020 12041 13.6% 199.182.16.0/24 Afilias, Inc. ... 200020 12041 13.6% 199.115.154.0/24 Afilias, Inc. ... 200020 12041 13.3% 94.228.128.0/20 Prolocation B.V. NL ... 200020 41887 13.3% 85.119.104.0/21 VitrumNet BV NL ... 200020 41887 13.3% 81.23.230.0/23 GarnierProjects BV Overveen Provincie Noord-Holland NL ... 200020 41887 13.3% 213.132.192.0/19 CJ2 Hosting B.V. NL ... 200020 41887 13.3% 178.22.80.0/21 Prolocation B.V. NL ... 200020 41887 13.0% 91.236.194.0/24 Datapark B.V NL ... 200020 41887 13.0% 90.145.56.0/24 UNET Mail platform Amsterdam Provincie Noord-Holland NL ... 200020 41887 13.0% 81.173.34.0/24 www.telfort.nl Amsterdam Provincie Noord-Holland NL ... 200020 41887 13.0% 213.132.221.0/24 CJ2 Hosting B.V. The Hague Provincie Zuid-Holland NL ... 200020 41887 13.0% 213.132.204.0/24 NLHOSTING-NET # 5 Amsterdam Provincie Noord-Holland NL ... 200020 41887 13.0% 185.40.96.0/22 OPENFIBER B.V. NL ... 200020 41887 12.2% 91.219.108.0/22 Xenosite B.V. Amsterdam Provincie Noord-Holland NL ... 200020 39647 15426 12.2% 89.255.0.0/18 Xenosite B.V. Amsterdam Provincie Noord-Holland NL ... 200020 39647 15426 12.2% 65.22.198.0/24 Afilias, Inc. US ... 200020 12041 12.2% 62.212.128.0/19 Xenosite B.V. Amsterdam Provincie Noord-Holland NL ... 200020 39647 15426 12.2% 5.178.32.0/21 Xenosite B.V. NL ... 200020 39647 15426 12.2% 46.231.80.0/21 Xenosite B.V. NL ... 200020 39647 15426 12.2% 46.102.224.0/21 Xenosite B.V. Amsterdam Provincie Noord-Holland NL ... 200020 39647 15426 12.0% 62.222.0.0/15 Coolwave Communications B.V. Amsterdam Provincie Noord-Holland NL ... 200020 20562 8918 8918 12.0% 217.148.132.0/22 Xenosite SRL Amsterdam Provincie Noord-Holland NL ... 200020 39647 15426 12.0% 212.4.192.0/19 Coolwave Communications B.V. Amsterdam Provincie Noord-Holland NL ... 200020 20562 8918 8918 12.0% 195.134.168.0/21 Xenosite B.V. NL ... 200020 39647 15426 12.0% 194.76.128.0/22 2Blue4U Internet B.V. NL ... 200020 39647 15426 12.0% 194.53.204.0/22 Within Reach Group B.V. Greup Provincie Zuid-Holland NL ... 200020 39647 15426 12.0% 194.34.240.0/22 Voiceworks GmbH DE ... 200020 39647 12.0% 194.145.194.0/23 Within Reach Group B.V. NL ... 200020 39647 15426 12.0% 193.84.188.0/22 Xenosite SRL NL ... 200020 39647 15426 12.0% 193.22.132.0/22 Within Reach Group B.V. NL ... 200020 39647 15426 12.0% 193.164.216.0/23 Xenosite B.V. Amsterdam Provincie Noord-Holland NL ... 200020 39647 15426 12.0% 193.107.220.0/22 Xenosite B.V. Amsterdam Provincie Noord-Holland NL ... 200020 39647 15426 12.0% 188.240.24.0/21 Xenosite B.V. NL ... 200020 39647 15426 12.0% 188.213.224.0/21 Xenosite B.V. NL ... 200020 39647 15426 12.0% 185.67.60.0/22 Within Reach Group B.V. NL ... 200020 39647 15426 12.0% 185.60.252.0/22 Xenosite B.V. NL ... 200020 39647 15426 12.0% 185.54.204.0/22 Xenosite B.V. Amsterdam Provincie Noord-Holland NL ... 200020 39647 15426 12.0% 185.31.228.0/22 Xenosite B.V. Amsterdam Provincie Noord-Holland NL ... 200020 39647 15426 12.0% 185.253.208.0/22 Xenosite B.V. NL ... 200020 39647 15426 12.0% 185.247.144.0/22 Voiceworks B.V. NL ... 200020 39647 15426 12.0% 185.243.88.0/22 Redhosting B.V. NL ... 200020 39647 15426 12.0% 185.232.184.0/22 Within Reach Group B.V. NL ... 200020 39647 15426 12.0% 185.19.56.0/22 Xenosite B.V. NL ... 200020 39647 15426 12.0% 185.189.104.0/22 Nedlook Holding BV NL ... 200020 39647 15426 12.0% 185.181.72.0/22 Within Reach Group B.V. NL ... 200020 39647 15426 12.0% 185.176.140.0/22 Within Reach Group B.V. NL ... 200020 39647 15426 12.0% 185.160.72.0/22 UE Agil Trade OOD NL ... 200020 39647 15426 12.0% 185.112.64.0/22 Hendrik Dekker trading as Camel IT Services & Solutions NL ... 200020 39647 15426 12.0% 185.10.232.0/22 Xenosite B.V. NL ... 200020 39647 15426 12.0% 178.132.208.0/21 Xenosite B.V. NL ... 200020 39647 15426 12.0% 141.0.24.0/21 Within Reach Group B.V. NL ... 200020 39647 15426 11.7% 46.34.92.0/22 VERIZON SPAIN S.L. Amsterdam Provincie Noord-Holland NL ... 200020 23148 11.7% 46.34.88.0/23 VERIZON SPAIN S.L. Brussels Bruxelles-Capitale BE ... 200020 23148 11.7% 46.34.80.0/21 VERIZON SPAIN S.L. Amsterdam Provincie Noord-Holland NL ... 200020 23148 11.7% 46.34.76.0/23 MSS-ISP-NOA Amsterdam Provincie Noord-Holland NL ... 200020 23148 11303 11.7% 46.34.74.0/24 ICMAS ES ... 200020 23148 11303 11.7% 46.34.74.0/23 VERIZON SPAIN S.L. Amsterdam Provincie Noord-Holland NL ... 200020 23148 11.7% 46.34.71.0/24 VERIZON SPAIN S.L. Amsterdam Provincie Noord-Holland NL ... 200020 23148 11.7% 46.34.68.0/24 VERIZON SPAIN S.L. Amsterdam Provincie Noord-Holland NL ... 200020 23148 11.7% 46.34.68.0/23 VERIZON SPAIN S.L. Amsterdam Provincie Noord-Holland NL ... 200020 23148 11.7% 46.234.216.0/21 Net Global Srl IT ... 200020 50316 11.7% 46.234.192.0/21 Net Global Srl IT ... 200020 50316 11.7% 185.96.96.0/22 Net Global Srl IT ... 200020 50316 11.7% 185.74.188.0/22 Net Global Srl IT ... 200020 50316 11.7% 185.10.188.0/22 Net Global Srl IT ... 200020 50316 11.4% 94.247.0.0/21 Within Reach Group B.V. Amsterdam Provincie Noord-Holland NL ... 200020 39647 11.4% 91.229.144.0/23 MYLAPS BV Amsterdam Provincie Noord-Holland NL ... 200020 39647 11.4% 89.184.160.0/19 Within Reach Group B.V. Amsterdam Provincie Noord-Holland NL ... 200020 39647 11.4% 85.112.26.0/23 AMS5-Managed-Services Amsterdam Provincie Noord-Holland NL ... 200020 23148 11303 11.4% 85.112.21.0/24 VERIZON SPAIN S.L. Amsterdam Provincie Noord-Holland NL ... 200020 23148 11.4% 85.112.16.0/22 VERIZON SPAIN S.L. Amsterdam Provincie Noord-Holland NL ... 200020 23148 11.4% 85.112.16.0/21 VERIZON SPAIN S.L. Amsterdam Provincie Noord-Holland NL ... 200020 23148 11.4% 84.243.192.0/18 Within Reach Group B.V. Amsterdam Provincie Noord-Holland NL ... 200020 39647 11.4% 81.28.80.0/20 Within Reach Group B.V. Amsterdam Provincie Noord-Holland NL ... 200020 39647 11.4% 46.34.84.0/22 TMRK-ECLOUD-AMS3 Amsterdam Provincie Noord-Holland NL ... 200020 23148 11303 11.4% 46.234.212.0/22 NETGLOBAL_NETWORK IT ... 200020 50316 11.4% 46.234.210.0/23 NETGLOBAL_NETWORK IT ... 200020 50316 11.4% 46.234.209.0/24 NETGLOBAL_END_USERS IT ... 200020 50316 11.4% 46.234.208.0/24 NETGLOBAL_END_USERS IT ... 200020 50316 11.4% 46.234.206.0/23 NETGLOBAL_NETWORK IT ... 200020 50316 11.4% 46.234.204.0/23 NETGLOBAL_NETWORK IT ... 200020 50316 11.4% 46.234.200.0/22 NETGLOBAL_NETWORK IT ... 200020 50316 11.4% 37.152.8.0/21 Within Reach Group B.V. Amsterdam Provincie Noord-Holland NL ... 200020 39647 11.4% 217.67.224.0/19 Within Reach Group B.V. NL ... 200020 39647 11.4% 217.171.224.0/21 Within Reach Group B.V. NL ... 200020 39647 11.4% 213.187.9.0/24 BEFFECT Di Alessandro Bertoldo IT ... 200020 50316 11.4% 213.187.8.0/24 NETGLOBAL_END_USERS IT ... 200020 50316 11.4% 213.187.16.0/20 Net Global Srl IT ... 200020 50316 11.4% 213.187.12.0/22 NETGLOBAL_NETWORK IT ... 200020 50316 11.4% 213.187.0.0/21 Net Global Srl IT ... 200020 50316 11.4% 185.93.116.0/22 Voiceworks GmbH DE ... 200020 39647 11.4% 185.43.164.0/22 Net Global Srl IT ... 200020 50316 11.4% 185.2.240.0/22 Within Reach Group B.V. NL ... 200020 39647 11.4% 185.22.192.0/22 Within Reach Group B.V. Amsterdam Provincie Noord-Holland NL ... 200020 39647 11.4% 185.142.122.0/23 Net Global Srl IT ... 200020 50316 11.4% 185.121.32.0/22 Net Global Srl IT ... 200020 50316 11.4% 178.238.96.0/20 Within Reach Group B.V. Amsterdam Provincie Noord-Holland NL ... 200020 39647 11.4% 152.194.72.0/22 IBM Cloud Managed Application Services Amsterdam Provincie Noord-Holland NL ... 200020 23148 11303 11.4% 146.255.48.0/21 Summa Communications B.V. NL ... 200020 39647 11.2% 185.123.62.0/24 STH-Customers NL ... 200020 39647 10.9% 65.22.41.0/24 Afilias, Inc. US ... 200020 12041 10.9% 65.22.40.0/24 Afilias, Inc. CA ... 200020 12041 10.9% 65.22.164.0/24 Afilias, Inc. US ... 200020 12041 10.9% 199.43.134.0/24 ICANN ... 200020 12041 10.9% 199.254.63.0/24 Afilias, Inc. ... 200020 12041 10.1% 91.217.31.0/24 Securitas Alert Services Nederland B.V. NL ... 200020 1136 8737 10.1% 185.241.44.0/22 SPICE FLOW LTD IM ... 200020 50763 10.1% 160.48.160.0/23 BMW AG, Landshut production plant DE ... 200020 1136 9.8% 92.65.0.0/23 KPN Mobile The Netherlands B.V. Dongen Provincie Noord-Brabant NL ... 200020 1136 8737 9.8% 82.171.128.0/17 Customers NL ... 200020 1136 9.8% 82.171.0.0/18 Customers NL ... 200020 1136 9.8% 82.170.0.0/16 Customers NL ... 200020 1136 9.8% 82.169.96.0/19 Customers NL ... 200020 1136 9.8% 82.169.192.0/18 Customers NL ... 200020 1136 9.8% 82.169.128.0/19 Customers NL ... 200020 1136 9.8% 82.169.0.0/18 Customers NL ... 200020 1136 9.8% 82.168.192.0/19 Customers NL ... 200020 1136 9.8% 82.168.128.0/18 Customers NL ... 200020 1136 9.8% 82.168.0.0/17 Customers NL ... 200020 1136 9.8% 62.132.12.0/22 KPN B.V. NL ... 200020 1136 59542 8737 9.8% 37.74.240.0/20 KPN B.V. NL ... 200020 1136 59542 8737 9.8% 185.34.146.0/23 BSU.LEASE NL ... 200020 1136 9.8% 185.34.144.0/23 BSU.LEASE NL ... 200020 1136 9.8% 170.37.205.0/24 RIPE Network Coordination Centre Amsterdam Provincie Noord-Holland NL ... 200020 1136 9.8% 170.37.204.0/24 RIPE Network Coordination Centre Amsterdam Provincie Noord-Holland NL ... 200020 1136 9.8% 160.48.160.0/24 BMW AG, Landshut production plant DE ... 200020 1136 9.8% 148.200.0.0/16 Gemeente Zoetermeer NL ... 200020 1136 9.8% 145.15.208.0/21 Nederlandse Spoorwegen PI block NL ... 200020 1136 9.8% 145.15.114.0/24 Nederlandse Spoorwegen PI block NL ... 200020 1136 9.8% 145.15.110.0/24 Nederlandse Spoorwegen PI block Amsterdam Provincie Noord-Holland NL ... 200020 1136 9.8% 145.15.109.0/24 Nederlandse Spoorwegen PI block Amsterdam Provincie Noord-Holland NL ... 200020 1136 9.8% 145.15.108.0/24 Nederlandse Spoorwegen PI block Amsterdam Provincie Noord-Holland NL ... 200020 1136 9.6% 92.69.46.0/23 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 92.69.42.0/23 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 92.69.38.0/23 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 92.69.34.0/23 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 91.90.40.0/21 BLIX GROUP Oslo Oslo County NO ... 200020 50304 9.6% 91.247.228.0/22 Host1 DA Oslo Oslo County NO ... 200020 50304 9.6% 91.229.142.0/23 Host1 DA Oslo Oslo County NO ... 200020 50304 9.6% 91.227.248.0/22 PE KARSTENSEN IT NO ... 200020 50304 9.6% 91.226.6.0/23 Centrum Telewizji Kablowej JIM-SAT Sp. z o.o. Gorzów Wielkopolski Województwo Lubuskie PL ... 200020 29314 9.6% 91.205.184.0/22 BLIX GROUP NO ... 200020 50304 9.6% 89.200.96.0/20 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 89.200.64.0/19 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 89.200.48.0/20 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 89.200.32.0/20 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 89.200.16.0/20 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 89.200.112.0/22 KPN Mobile The Netherlands B.V. Wageningen Provincie Gelderland NL ... 200020 1136 8737 9.6% 89.200.0.0/20 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 86.84.239.0/24 Customers Waddinxveen Provincie Zuid-Holland NL ... 200020 1136 59542 8737 9.6% 83.97.18.0/24 Netbouncer AB GB ... 200020 50304 9.6% 83.232.62.0/23 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 83.232.60.0/23 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 83.232.58.0/23 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 83.232.56.0/23 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 83.232.54.0/23 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 83.232.52.0/23 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 83.232.50.0/23 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 83.232.48.0/23 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 77.62.32.0/19 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 77.62.144.0/20 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 77.62.128.0/20 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 62.133.96.0/21 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 62.133.68.0/22 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 62.133.64.0/22 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 62.133.120.0/22 KPN Mobile The Netherlands B.V. Gorinchem Provincie Zuid-Holland NL ... 200020 1136 8737 9.6% 62.133.104.0/21 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 62.12.26.0/23 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 46.255.24.0/21 Special Tribunal for Lebanon NL ... 200020 1136 9.6% 46.17.27.0/24 Gemeente Amsterdam Amsterdam Provincie Noord-Holland NL ... 200020 1136 9.6% 46.17.26.0/24 Gemeente Amsterdam Amsterdam Provincie Noord-Holland NL ... 200020 1136 9.6% 46.17.25.0/24 Gemeente Amsterdam Amsterdam Provincie Noord-Holland NL ... 200020 1136 9.6% 46.17.24.0/24 Gemeente Amsterdam Amsterdam Provincie Noord-Holland NL ... 200020 1136 9.6% 31.41.208.0/21 Centrum Telewizji Kablowej JIM-SAT Sp. z o.o. PL ... 200020 29314 9.6% 31.169.48.0/21 BLIX GROUP Oslo Oslo County NO ... 200020 50304 9.6% 31.161.232.0/21 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 31.161.224.0/21 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 31.161.220.0/22 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 31.161.216.0/22 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 31.161.208.0/21 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 31.161.200.0/21 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 31.161.196.0/22 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 31.161.192.0/22 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 31.161.184.0/21 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 31.161.176.0/21 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 31.161.168.0/21 KPN Mobile The Netherlands B.V. Schoonhoven Provincie Zuid-Holland NL ... 200020 1136 8737 9.6% 31.161.160.0/21 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 31.161.152.0/21 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 31.161.144.0/21 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 31.161.140.0/22 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 31.161.136.0/22 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.6% 31.161.132.0/22 KPN Mobile The Netherlands B.V. Tilburg Provincie Noord-Brabant NL ... 200020 1136 8737 9.6% 31.161.128.0/22 KPN Mobile The Netherlands B.V. Tilburg Provincie Noord-Brabant NL ... 200020 1136 8737 9.6% 194.219.128.0/17 FORTHnet SA GR ... 200020 1241 9.6% 185.73.135.0/24 SEAMLESS OU Oslo Oslo County NO ... 200020 50304 9.6% 185.41.242.0/24 Blix Solutions - London London England GB ... 200020 50304 9.6% 185.41.240.0/23 BLIX GROUP SE ... 200020 50304 9.6% 185.41.240.0/22 BLIX GROUP Ås Akershus fylke NO ... 200020 50304 9.6% 185.35.200.0/24 BLIX GROUP Stockholm Stockholm SE ... 200020 50304 9.6% 185.35.200.0/22 BLIX GROUP Ås Akershus fylke NO ... 200020 50304 9.6% 185.12.72.0/22 Digital Raadgivning NO ... 200020 50304 9.6% 185.12.56.0/22 BLIX GROUP NO ... 200020 50304 9.6% 178.255.144.0/21 BLIX GROUP Oslo Oslo County NO ... 200020 50304 9.6% 176.125.232.0/22 BLIX GROUP Oslo Oslo County NO ... 200020 50304 9.6% 170.37.206.0/24 RIPE Network Coordination Centre NL ... 200020 1136 9.6% 170.37.203.0/24 RIPE Network Coordination Centre NL ... 200020 1136 9.6% 165.231.112.0/24 NORWAY Oslo Oslo County NO ... 200020 50304 9.6% 145.15.111.0/24 Nederlandse Spoorwegen PI block Amsterdam Provincie Noord-Holland NL ... 200020 1136 9.6% 134.90.149.0/24 BLIX GROUP Copenhagen Region Hovedstaden DK ... 200020 50304 9.6% 134.90.146.0/24 Blix Solutions - Amsterdam Amsterdam Provincie Noord-Holland NL ... 200020 50304 9.6% 134.90.144.0/21 BLIX GROUP Ås Akershus fylke NO ... 200020 50304 9.3% 91.235.60.0/22 Unique Network Oslo Oslo County NO ... 200020 50304 50272 9.3% 89.219.168.0/24 CITIC Telecom CPC Netherlands B.V. EE ... 200020 3327 9.3% 89.219.162.0/24 CITIC Telecom CPC Netherlands B.V. EE ... 200020 3327 9.3% 89.219.161.0/24 CITIC Telecom CPC Netherlands B.V. EE ... 200020 3327 9.3% 89.219.154.0/24 CITIC Telecom CPC Netherlands B.V. NL ... 200020 3327 9.3% 89.219.152.0/23 CITIC Telecom CPC Netherlands B.V. EE ... 200020 3327 9.3% 89.219.144.0/21 CITIC Telecom CPC Netherlands B.V. NL ... 200020 3327 9.3% 89.219.136.0/21 CITIC Telecom CPC Netherlands B.V. EE ... 200020 3327 9.3% 89.219.134.0/23 CITIC Telecom CPC Netherlands B.V. NL ... 200020 3327 9.3% 89.219.128.0/22 CITIC Telecom CPC Netherlands B.V. EE ... 200020 3327 9.3% 89.200.126.0/24 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.3% 86.80.0.0/12 KPN B.V. NL ... 200020 1136 9.3% 81.206.0.0/16 Customers NL ... 200020 1136 9.3% 77.60.0.0/14 KPN B.V. NL ... 200020 1136 9.3% 77.175.0.0/17 KPN B.V. Amsterdam Provincie Noord-Holland NL ... 200020 1136 49562 9.3% 62.24.32.0/19 AVUR Oslo Oslo County NO ... 200020 50304 50272 9.3% 62.128.112.0/20 CITIC Telecom CPC Netherlands B.V. NL ... 200020 3327 9.3% 62.128.104.0/21 CITIC Telecom CPC Netherlands B.V. NL ... 200020 3327 9.3% 62.128.102.0/23 CITIC Telecom CPC Netherlands B.V. PL ... 200020 3327 9.3% 62.128.100.0/22 CITIC Telecom CPC Netherlands B.V. NL ... 200020 3327 9.3% 44.137.0.0/16 Amateur Radio Digital Communications Amsterdam Provincie Noord-Holland NL ... 200020 3265 9.3% 37.74.0.0/16 KPN B.V. NL ... 200020 1136 9.3% 37.251.0.0/17 KPN B.V. Amsterdam Provincie Noord-Holland NL ... 200020 1136 49562 9.3% 31.160.0.0/15 KPN B.V. NL ... 200020 1136 9.3% 31.149.0.0/16 KPN B.V. NL ... 200020 1136 9.3% 217.28.240.0/20 CITIC Telecom CPC Netherlands B.V. NL ... 200020 3327 9.3% 212.27.226.0/24 CITIC Telecom CPC Netherlands B.V. Warsaw Województwo Mazowieckie PL ... 200020 3327 9.3% 195.238.234.0/24 Unique Network NO ... 200020 50304 50272 9.3% 194.99.140.0/24 CSM Deutschland GmbH DE ... 200020 3327 9.3% 188.142.0.0/17 KPN B.V. Amsterdam Provincie Noord-Holland NL ... 200020 1136 49562 9.3% 185.36.40.0/24 G4S Security Services BV NL ... 200020 1136 9.3% 185.2.172.0/22 KPN B.V. Amsterdam Provincie Noord-Holland NL ... 200020 1136 49562 9.3% 157.120.224.0/21 RIPE Network Coordination Centre HK ... 200020 8220 9.3% 152.194.64.0/22 ANS Communications, Inc Amsterdam Provincie Noord-Holland NL ... 200020 23148 9.3% 145.78.0.0/16 PostNL Holding B.V. NL ... 200020 1136 9.3% 145.4.224.0/20 PGGM Zeist Provincie Utrecht NL ... 200020 1136 9.3% 137.17.0.0/16 National Aerospace Laboratory Amsterdam Provincie Noord-Holland NL ... 200020 1136 9.0% 95.47.64.0/19 Metroset Ltd. RU ... 200020 50923 9.0% 95.47.0.0/19 Metroset Ltd. RU ... 200020 50923 9.0% 93.154.0.0/17 KPN B.V. NL ... 200020 1136 9.0% 92.64.0.0/13 KPN B.V. NL ... 200020 1136 9.0% 89.200.0.0/17 KPN B.V. NL ... 200020 1136 9.0% 84.80.0.0/13 KPN B.V. NL ... 200020 1136 9.0% 83.232.0.0/18 KPN Mobile The Netherlands B.V. NL ... 200020 1136 9.0% 83.232.0.0/16 KPN B.V. NL ... 200020 1136 9.0% 82.171.64.0/18 Customers NL ... 200020 1136 9.0% 82.169.64.0/19 Customers NL ... 200020 1136 9.0% 82.169.160.0/19 Customers NL ... 200020 1136 9.0% 82.168.224.0/19 Customers NL ... 200020 1136 9.0% 82.136.192.0/18 KPN B.V. NL ... 200020 1136 9.0% 81.207.0.0/17 Customers NL ... 200020 1136 9.0% 81.204.0.0/14 KPN B.V. NL ... 200020 1136 9.0% 80.60.0.0/15 KPN B.V. NL ... 200020 1136 9.0% 77.175.128.0/17 KPN B.V. NL ... 200020 1136 9.0% 77.173.0.0/16 Customers NL ... 200020 1136 9.0% 77.172.0.0/16 Customers NL ... 200020 1136 9.0% 77.168.0.0/14 KPN B.V. NL ... 200020 1136 9.0% 77.160.0.0/13 KPN B.V. NL ... 200020 1136 9.0% 62.41.0.0/16 KPN B.V. NL ... 200020 1136 9.0% 62.25.0.0/18 KPN B.V. NL ... 200020 1136 9.0% 62.21.128.0/17 KPN B.V. NL ... 200020 1136 9.0% 62.207.0.0/16 KPN B.V. NL ... 200020 1136 9.0% 62.133.64.0/18 KPN B.V. NL ... 200020 1136 9.0% 62.132.0.0/16 KPN B.V. NL ... 200020 1136 9.0% 62.131.0.0/16 KPN B.V. NL ... 200020 1136 9.0% 62.12.0.0/19 KPN B.V. NL ... 200020 1136 9.0% 5.102.142.0/24 Tribion B.V. Raamsdonksveer Provincie Noord-Brabant NL ... 200020 20562 52102 9.0% 46.144.0.0/15 KPN B.V. NL ... 200020 1136 9.0% 194.122.160.0/19 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.0% 188.207.56.0/22 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.0% 188.207.48.0/21 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.0% 188.207.32.0/20 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 9.0% 145.7.0.0/16 KPN B.V. NL ... 200020 1136 9.0% 145.53.0.0/16 KPN B.V. NL ... 200020 1136 9.0% 145.43.0.0/16 Reed Business bv Sutton England GB ... 200020 1136 9.0% 145.132.0.0/15 NL ... 200020 1136 9.0% 145.130.0.0/16 KPN B.V. NL ... 200020 1136 9.0% 145.129.0.0/16 KPN B.V. BE ... 200020 1136 9.0% 145.128.0.0/16 KPN B.V. NL ... 200020 1136 8.8% 93.113.104.0/24 TTI-AG Vienna Wien AT ... 200020 6663 8.8% 89.250.104.0/21 innogy Ceska republika a.s CZ ... 200020 29208 8.8% 83.232.24.0/21 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 1134 8.8% 83.232.16.0/21 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 1134 8.8% 83.232.0.0/20 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 1134 8.8% 82.103.112.0/24 Software Company Sofia Sofiya-Grad BG ... 200020 42794 8.8% 62.4.64.0/22 euNetworks GmbH DE ... 200020 13237 8.8% 45.67.108.0/22 Infradax B.V. NL ... 200020 49033 8.8% 185.232.160.0/22 Orange Bytes BV NL ... 200020 49033 8.8% 185.171.48.0/22 Smart Routing Solutions BV NL ... 200020 49033 8.8% 185.116.144.0/22 Smart Routing Solutions BV NL ... 200020 49033 8.5% 91.224.248.0/23 Oxilion B.V. Amsterdam Provincie Noord-Holland NL ... 200020 20559 8.5% 91.218.148.0/22 Fundaments B.V. NL ... 200020 20559 8.5% 88.218.152.0/22 Fundaments B.V. Madrid Comunidad de Madrid ES ... 200020 20559 8.5% 83.232.40.0/21 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 1134 8.5% 82.102.20.0/24 M247 LTD Copenhagen Infrastructure Copenhagen Region Hovedstaden DK ... 200020 9009 8.5% 79.103.0.0/16 FORTHnet SA GR ... 200020 1241 8.5% 62.133.80.0/20 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 1134 8.5% 62.133.74.0/23 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 1134 8.5% 62.133.72.0/23 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 1134 8.5% 62.133.112.0/21 KPN Mobile The Netherlands B.V. NL ... 200020 1136 8737 1134 8.5% 62.1.248.0/21 ADSL POOLS GR ... 200020 1241 8.5% 5.59.192.0/18 Metroset Ltd. RU ... 200020 50923 8.5% 46.246.192.0/18 FORTHNET LLU POOLS GR ... 200020 1241 8.5% 46.226.88.0/21 Fundaments B.V. NL ... 200020 20559 8.5% 46.12.0.0/16 FORTHnet SA GR ... 200020 1241 8.5% 31.207.60.0/22 MKBWebhoster BV NL ... 200020 49033 203822 8.5% 31.207.48.0/22 MKBWebhoster BV NL ... 200020 49033 203822 8.5% 31.207.48.0/21 MKBWebhoster BV NL ... 200020 49033 203822 8.5% 213.16.192.0/18 FORTHnet SA GR ... 200020 1241 8.5% 193.92.128.0/17 FORTHnet SA GR ... 200020 1241 8.5% 185.69.60.0/22 MKBWebhoster BV NL ... 200020 49033 203822 8.5% 185.206.224.0/24 M247 LTD Copenhagen Infrastructure Copenhagen Region Hovedstaden DK ... 200020 9009 8.2% 93.186.176.0/20 Oxilion B.V. Amsterdam Provincie Noord-Holland NL ... 200020 20559 8.2% 91.234.193.0/24 Veiligheidsregio Twente Hengelo Provincie Overijssel NL ... 200020 20559 8.2% 89.32.186.0/23 STEL S.R.L. Bucharest București RO ... 200020 56550 8.2% 5.172.40.0/21 Oxilion B.V. Amsterdam Provincie Noord-Holland NL ... 200020 20559 8.2% 46.19.216.0/21 Oxilion B.V. Amsterdam Provincie Noord-Holland NL ... 200020 20559 8.2% 31.200.208.0/21 Oxilion B.V. Amsterdam Provincie Noord-Holland NL ... 200020 20559 8.0% 93.117.172.0/23 STEL S.R.L. IT ... 200020 56550 8.0% 93.117.152.0/23 STEL S.R.L. IT ... 200020 56550 8.0% 93.115.62.0/23 STEL S.R.L. Bucharest București RO ... 200020 56550 8.0% 89.32.168.0/23 STEL S.R.L. Bucharest București RO ... 200020 56550 8.0% 86.105.177.0/24 STEL S.R.L. Bucharest București RO ... 200020 56550 8.0% 66.54.95.0/24 HERE North America LLC US ... 200020 1248 8.0% 66.54.64.0/19 HERE North America LLC Chicago IL US ... 200020 1248 8.0% 46.246.128.0/17 FORTHnet SA GR ... 200020 1241 8.0% 46.102.188.0/23 STEL S.R.L. IT ... 200020 56550 8.0% 31.177.40.0/21 STEL S.R.L. IT ... 200020 56550 8.0% 185.171.48.0/24 Smart Routing Solutions BV Amsterdam Provincie Noord-Holland NL ... 200020 49033 8.0% 153.96.252.0/24 Fraunhofer NET IGCV RMV 2 DE ... 200020 13132 8.0% 153.96.251.0/24 Fraunhofer NET IGCV RMV 1 DE ... 200020 13132 8.0% 131.228.255.0/24 HERE Global BV FI ... 200020 1248 8.0% 131.228.192.0/21 HERE US Internet aggregate US ... 200020 1248 8.0% 131.228.180.0/22 HERE Global BV Amsterdam Provincie Noord-Holland NL ... 200020 1248 8.0% 131.228.128.0/17 HERE Global BV FI ... 200020 1248 7.7% 94.177.127.0/24 STEL S.R.L. Bucharest București RO ... 200020 56550 7.7% 89.42.25.0/24 STEL S.R.L. IT ... 200020 56550 7.7% 89.36.228.0/24 STEL S.R.L. IT ... 200020 56550 7.7% 89.34.161.0/24 STEL S.R.L. La Maddalena Sardegna IT ... 200020 56550 7.7% 89.33.133.0/24 STEL S.R.L. Bucharest București RO ... 200020 56550 7.7% 85.204.147.0/24 STEL S.R.L. La Maddalena Sardegna IT ... 200020 56550 7.7% 85.204.119.0/24 STEL S.R.L. Bucharest București RO ... 200020 56550 7.7% 46.255.88.0/21 Petit Telecom B.V. NL ... 200020 197156 7.7% 31.214.153.0/24 STEL S.R.L. Frankfurt am Main Hessen DE ... 200020 56550 7.7% 31.14.28.0/24 STEL S.R.L. Bucharest București RO ... 200020 56550 7.7% 185.60.156.0/22 Petit Telecom B.V. NL ... 200020 197156 7.7% 185.145.136.0/22 GMG PRIMEX SRL IR ... 200020 9009 7.7% 178.255.48.0/21 Petit Telecom B.V. Amsterdam Provincie Noord-Holland NL ... 200020 197156 7.4% 37.120.153.0/24 M247 LTD Stockholm Infrastructure Stockholm Stockholm SE ... 200020 9009 7.4% 37.120.145.0/24 M247 LTD Copenhagen Infrastructure Copenhagen Region Hovedstaden DK ... 200020 9009 7.4% 37.120.131.0/24 M247 LTD Copenhagen Infrastructure Copenhagen Region Hovedstaden DK ... 200020 9009 7.4% 31.24.116.0/22 4all Solutions NV BE ... 200020 8368 7.4% 31.24.114.0/23 4all Solutions NV BE ... 200020 8368 7.4% 31.24.113.0/24 4all Solutions NV BE ... 200020 8368 7.4% 31.171.128.0/22 Ellada Projects B.V. trading as Netrouting Amsterdam Provincie Noord-Holland NL ... 200020 47869 7.2% 91.132.138.0/24 M247 Ltd Stockholm Stockholm Stockholm SE ... 200020 9009 7.2% 46.231.255.0/24 Innovative Solutions in Media (ISM) B.V. Amsterdam Provincie Noord-Holland NL ... 200020 20562 30925 21162 7.2% 46.231.248.0/21 Innovative Solutions in Media (ISM) B.V. Amsterdam Provincie Noord-Holland NL ... 200020 20562 30925 21162 7.2% 31.24.112.0/24 4all Solutions NV BE ... 200020 8368 7.2% 185.44.136.0/22 Innovative Solutions in Media (ISM) B.V. NL ... 200020 20562 30925 21162 7.2% 178.248.168.0/21 Innovative Solutions in Media (ISM) B.V. Amsterdam Provincie Noord-Holland NL ... 200020 20562 30925 21162 6.9% 92.247.128.0/23 Software Company Sofia Sofiya-Grad BG ... 200020 42794 6.9% 92.247.124.0/22 Software Company BG ... 200020 42794 6.9% 92.247.120.0/22 Software Company Sofia Sofiya-Grad BG ... 200020 42794 6.9% 91.195.64.0/22 E-Quest Glasvezel Diensten BV NL ... 200020 42707 6.9% 5.157.88.0/21 Innovative Solutions in Media (ISM) B.V. Amsterdam Provincie Noord-Holland NL ... 200020 20562 30925 21162 6.9% 37.252.224.0/24 Dedicated servers in SI Ljubljana Mestna Občina Ljubljana SI ... 200020 9119 42473 6.9% 31.132.204.0/22 N.V. Nederlandse Gasunie Groningen Provincie Groningen NL ... 200020 56953 6.9% 31.132.200.0/22 N.V. Nederlandse Gasunie Groningen Provincie Groningen NL ... 200020 56953 6.6% 91.229.152.0/23 N.V. Nederlandse Gasunie NL ... 200020 56953 6.6% 88.207.128.0/17 POST Luxembourg LU ... 200020 6661 6.6% 87.240.192.0/18 POST Luxembourg LU ... 200020 6661 6.6% 83.99.0.0/17 POST Luxembourg LU ... 200020 6661 6.6% 78.141.128.0/18 POST Luxembourg LU ... 200020 6661 6.6% 5.39.184.0/21 ColoCenter b.v. Amsterdam Provincie Noord-Holland NL ... 200020 58291 6.6% 37.157.152.0/21 POST Luxembourg LU ... 200020 6661 6.6% 213.166.32.0/19 POST Luxembourg LU ... 200020 6661 6.6% 213.135.224.0/19 POST Luxembourg LU ... 200020 6661 6.6% 195.46.224.0/19 POST Luxembourg Luxembourg District de Luxembourg LU ... 200020 6661 6.6% 194.154.192.0/19 POST Luxembourg LU ... 200020 6661 6.6% 178.237.101.0/24 Business & Decision Interactive Eolas SRL Paris Île-de-France FR ... 200020 8218 15401 6.6% 178.237.100.0/24 Business & Decision Interactive Eolas SRL Villeurbanne Rhône-Alpes FR ... 200020 8218 15401 6.4% 95.174.65.0/24 M247 LTD Copenhagen Infrastructure Copenhagen Region Hovedstaden DK ... 200020 9009 6.4% 94.247.192.0/21 KPN Internedservices B.V. Amsterdam Provincie Noord-Holland NL ... 200020 15879 6.4% 93.188.248.0/21 KPN Internedservices B.V. NL ... 200020 15879 6.4% 91.206.80.0/23 Syscon Automatisering B.V. Amsterdam Provincie Noord-Holland NL ... 200020 15879 6.4% 89.47.32.0/23 Lepida S.c.p.A. IT ... 200020 31638 6.4% 88.151.36.0/22 DSL Range Netaffairs Aalsmeer Provincie Noord-Holland NL ... 200020 15879 6.4% 87.250.128.0/19 KPN Internedservices B.V. NL ... 200020 15879 6.4% 87.237.96.0/23 Denit Internet Services NL ... 200020 25542 6.4% 87.237.100.0/23 Denit Internet Services NL ... 200020 25542 6.4% 85.255.208.0/20 Denit Internet Services Amsterdam Provincie Noord-Holland NL ... 200020 25542 6.4% 83.219.64.0/19 KPN Internedservices B.V. Amsterdam Provincie Noord-Holland NL ... 200020 15879 6.4% 83.150.232.0/22 NetBase BV NL ... 200020 51088 6.4% 82.201.0.0/17 KPN Internedservices B.V. Amsterdam Provincie Noord-Holland NL ... 200020 15879 6.4% 81.24.48.0/20 KPN Internedservices B.V. Amsterdam Provincie Noord-Holland NL ... 200020 15879 6.4% 80.97.192.0/18 SC Artelecom SA Bucharest București RO ... 200020 9050 6.4% 80.246.176.0/20 KPN Internedservices B.V. Amsterdam Provincie Noord-Holland NL ... 200020 15879 6.4% 77.245.80.0/20 KPN Internedservices B.V. Amsterdam Provincie Noord-Holland NL ... 200020 15879 6.4% 5.226.40.0/21 KPN Internedservices B.V. Amsterdam Provincie Noord-Holland NL ... 200020 15879 6.4% 46.255.104.0/21 KPN Internedservices B.V. Hoofddorp Provincie Noord-Holland NL ... 200020 15879 6.4% 37.61.243.0/24 DcforData SRL Le Bouscat Aquitaine FR ... 200020 8218 6.4% 37.61.242.0/24 DcforData SRL Lissieu Rhône-Alpes FR ... 200020 8218 6.4% 37.61.240.0/23 DcforData SRL Lyon Rhône-Alpes FR ... 200020 8218 6.4% 37.230.181.0/24 GZ Systems Limited DK ... 200020 9009 6.4% 37.230.180.0/24 GZ Systems Limited DK ... 200020 9009 6.4% 217.194.96.0/19 KPN Internedservices B.V. Amsterdam Provincie Noord-Holland NL ... 200020 15879 6.4% 217.149.64.0/20 KPN Internedservices B.V. Amsterdam Provincie Noord-Holland NL ... 200020 15879 6.4% 217.148.80.0/20 KPN Internedservices B.V. Amsterdam Provincie Noord-Holland NL ... 200020 15879 6.4% 217.115.192.0/20 KPN Internedservices B.V. Amsterdam Provincie Noord-Holland NL ... 200020 15879 6.4% 213.206.64.0/18 KPN Internedservices B.V. Amsterdam Provincie Noord-Holland NL ... 200020 15879 6.4% 213.197.192.0/18 KPN Internedservices B.V. Amsterdam Provincie Noord-Holland NL ... 200020 15879 6.4% 213.133.32.0/19 KPN Internedservices B.V. Amsterdam Provincie Noord-Holland NL ... 200020 15879 6.4% 213.130.160.0/19 KPN Internedservices B.V. NL ... 200020 15879 6.4% 212.204.192.0/18 KPN Internedservices B.V. NL ... 200020 15879 6.4% 203.12.1.0/24 DIALix Pty. Ltd. Amsterdam Provincie Noord-Holland NL ... 200020 25542 6.4% 197.155.77.0/24 Mirror servers Nairobi Nairobi KE ... 200020 30844 6.4% 195.3.176.0/22 Netaffairs Internetdiensten BV NL ... 200020 15879 6.4% 195.191.1.0/24 Syscon Automatisering B.V. Amsterdam Provincie Noord-Holland NL ... 200020 15879 6.4% 195.177.242.0/23 Move Next BV NL ... 200020 25542 6.4% 194.105.138.0/23 KPN Internedservices B.V. NL ... 200020 15879 6.4% 193.91.48.0/20 KPN Internedservices B.V. Amsterdam Provincie Noord-Holland NL ... 200020 15879 6.4% 193.239.88.0/22 Denit Internet Services Amsterdam Provincie Noord-Holland NL ... 200020 25542 6.4% 193.189.134.0/24 KPN Internedservices B.V. Amsterdam Provincie Noord-Holland NL ... 200020 15879 6.4% 193.105.3.0/24 RapidSugar B.V. NL ... 200020 15879 6.4% 193.104.111.0/24 RapidSugar B.V. Amsterdam Provincie Noord-Holland NL ... 200020 15879 6.4% 185.55.128.0/22 KPN Internedservices B.V. NL ... 200020 15879 6.4% 185.4.115.0/24 Denit NL ... 200020 25542 6.4% 185.28.148.0/22 KPN Internedservices B.V. NL ... 200020 15879 6.4% 185.245.84.0/24 M247 LTD Copenhagen Infrastructure Copenhagen Region Hovedstaden DK ... 200020 9009 6.4% 185.241.14.0/23 GMG-Copenhagen DK ... 200020 9009 6.4% 185.241.12.0/23 GMG-Copenhagen DK ... 200020 9009 6.4% 185.240.194.0/23 PPMAN-Copenhagen DK ... 200020 9009 6.4% 185.240.192.0/23 PPMAN-Copenhagen DK ... 200020 9009 6.4% 185.236.203.0/24 M247 LTD Copenhagen Infrastructure Copenhagen Region Hovedstaden DK ... 200020 9009 6.4% 185.212.169.0/24 M247 LTD Copenhagen Infrastructure Copenhagen Region Hovedstaden DK ... 200020 9009 6.4% 185.172.220.0/22 Basegrow B.V. NL ... 200020 15879 6.4% 185.139.148.0/22 Denit Internet Services NL ... 200020 25542 6.4% 185.138.248.0/22 Basegrow B.V. NL ... 200020 15879 6.4% 185.114.39.0/24 Ams-E-2 NL ... 200020 25542 6.4% 172.111.197.0/24 Secure Internet LLC Copenhagen Region Hovedstaden DK ... 200020 9009 6.1% 95.44.0.0/15 Eircom Limited Dublin Leinster IE ... 200020 5466 6.1% 94.126.64.0/21 Denit Internet Services Amsterdam Provincie Noord-Holland NL ... 200020 25542 6.1% 94.124.88.0/21 CJ2 Hosting B.V. NL ... 200020 39704 6.1% 91.194.98.0/24 ADELI SAS FR ... 200020 43142 43142 43142 43142 6.1% 91.194.101.0/24 ADELI SAS FR ... 200020 43142 43142 43142 43142 6.1% 91.194.100.0/24 ADELI SAS Samognat Rhône-Alpes FR ... 200020 43142 43142 43142 43142 6.1% 91.192.36.0/22 CJ2 Hosting B.V. NL ... 200020 39704 6.1% 86.40.0.0/13 Eircom Limited Dublin Leinster IE ... 200020 5466 6.1% 83.70.0.0/15 Eircom Limited Dublin Leinster IE ... 200020 5466 6.1% 83.160.0.0/14 Xs4all Internet BV NL ... 200020 3265 6.1% 81.93.48.0/20 Denit Internet Services Amsterdam Provincie Noord-Holland NL ... 200020 25542 6.1% 81.26.208.0/20 Denit Internet Services Amsterdam Provincie Noord-Holland NL ... 200020 25542 6.1% 80.247.160.0/20 Denit Internet Services Amsterdam Provincie Noord-Holland NL ... 200020 25542 6.1% 62.148.160.0/19 Denit Internet Services Amsterdam Provincie Noord-Holland NL ... 200020 25542 6.1% 5.22.248.0/21 CJ2 Hosting B.V. NL ... 200020 39704 6.1% 5.158.207.0/24 WaaS-ECONOCOM FR ... 200020 8368 59518 6.1% 5.152.178.0/24 AMS-E 5.152.178.0/24 Amsterdam Provincie Noord-Holland NL ... 200020 25542 6.1% 51.171.0.0/16 Eircom Limited IE ... 200020 5466 6.1% 46.235.40.0/21 NetBase BV Amsterdam Provincie Noord-Holland NL ... 200020 25459 34233 6.1% 46.182.216.0/21 CJ2 Hosting B.V. Amsterdam Provincie Noord-Holland NL ... 200020 39704 6.1% 37.220.168.0/21 dotXS Holding B.V. NL ... 200020 12859 198694 6.1% 31.193.48.0/21 Business & Decision Interactive Eolas SRL FR ... 200020 8218 15401 6.1% 31.173.160.0/22 Volga Branch of OJSC MegaFon - AS31133 Tol’yatti Samarskaya Oblast’ RU ... 200020 31133 6.1% 213.132.223.0/24 CJ2 Hosting B.V. The Hague Provincie Zuid-Holland NL ... 200020 39704 6.1% 213.132.210.0/23 CJ2 Hosting B.V. Driel Provincie Gelderland NL ... 200020 39704 6.1% 213.132.200.0/22 NLHOSTING-NET # 4 NL ... 200020 39704 6.1% 213.132.197.0/24 CJ2 Hosting B.V. Amsterdam Provincie Noord-Holland NL ... 200020 39704 6.1% 213.132.196.0/24 Webguru VOF NL ... 200020 39704 6.1% 213.132.196.0/22 CJ2 Hosting B.V. Amsterdam Provincie Noord-Holland NL ... 200020 39704 6.1% 213.132.195.0/24 Webguru VOF NL ... 200020 39704 6.1% 213.132.192.0/22 CJ2 Hosting B.V. Amsterdam Provincie Noord-Holland NL ... 200020 39704 6.1% 195.216.246.0/24 MortyDot NL ... 200020 39704 6.1% 194.50.163.0/24 CJ2 Hosting B.V. NL ... 200020 39704 6.1% 185.94.168.0/24 Webguru VOF NL ... 200020 39704 6.1% 185.170.192.0/22 Wnet Ukraine LLC UA ... 200020 15772 6.1% 185.103.16.0/22 CJ2 Hosting B.V. NL ... 200020 39704 6.1% 178.237.108.0/22 Eolas Hosted services - Datacenter MA FR ... 200020 8218 15401 6.1% 178.237.106.0/24 Eolas Hosted services - Datacenter CH FR ... 200020 8218 15401 6.1% 178.237.104.0/22 Eolas Hosted services - Datacenter CH FR ... 200020 8218 15401 6.1% 159.134.0.0/16 Eircom Limited Dublin Leinster IE ... 200020 5466 6.1% 152.89.162.0/24 M247 LTD Zurich CH ... 200020 9009 From bryan at shout.net Thu Mar 14 15:41:04 2019 From: bryan at shout.net (Bryan Holloway) Date: Thu, 14 Mar 2019 10:41:04 -0500 Subject: FB? In-Reply-To: References: <1461790733.9952.1552565854133.JavaMail.mhammett@ThunderFuck> <0B68C416-E859-4512-BE40-8C9E6C83DD44@netscout.com> <1669456769.10063.1552566523336.JavaMail.mhammett@ThunderFuck> <8a8e7978931d41a4b4ff819f82169248@ford.com> Message-ID: <6f3bd066-8009-7432-e255-04d01db2267f@shout.net> On 3/14/19 9:06 AM, Tom Beecher wrote: > As much as I wanted to crack jokes because I cannot stand Facebook (the > product), much love to all you FB engineers that went through (and are > probably still going through) much hell. > +1 on both counts. We've all been there; no bueno. From clinton.mielke at gmail.com Thu Mar 14 16:19:03 2019 From: clinton.mielke at gmail.com (cosmo) Date: Thu, 14 Mar 2019 09:19:03 -0700 Subject: FB? In-Reply-To: <6f3bd066-8009-7432-e255-04d01db2267f@shout.net> References: <1461790733.9952.1552565854133.JavaMail.mhammett@ThunderFuck> <0B68C416-E859-4512-BE40-8C9E6C83DD44@netscout.com> <1669456769.10063.1552566523336.JavaMail.mhammett@ThunderFuck> <8a8e7978931d41a4b4ff819f82169248@ford.com> <6f3bd066-8009-7432-e255-04d01db2267f@shout.net> Message-ID: Facebook pushed an update to their code that manages cookies, that had a rather severe bug in it that resulted in a large flood of requests to their database servers. To deal with this load, they had to prevent all writes and then slowly allow people back on. I saw the writeup for it last night but cannot seem to find it now! Grrr. Did I dream it? On Thu, Mar 14, 2019 at 8:42 AM Bryan Holloway wrote: > > On 3/14/19 9:06 AM, Tom Beecher wrote: > > As much as I wanted to crack jokes because I cannot stand Facebook (the > > product), much love to all you FB engineers that went through (and are > > probably still going through) much hell. > > > > +1 on both counts. > > We've all been there; no bueno. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at slimey.org Thu Mar 14 17:02:31 2019 From: simon at slimey.org (Simon Lockhart) Date: Thu, 14 Mar 2019 17:02:31 +0000 Subject: Apple devices spoofing default gateway? In-Reply-To: <2163B326-339F-4BA0-B65A-DF1752431913@beckman.org> References: <20190314122738.GR29673@dilbert.slimey.org> <2163B326-339F-4BA0-B65A-DF1752431913@beckman.org> Message-ID: <20190314170230.GV29673@dilbert.slimey.org> On Thu Mar 14, 2019 at 12:53:01PM +0000, Mel Beckman wrote: > Can you post some packet captures? I have some packet captures, but as they're from a live network, I'd rather not post them publicly. > I was a network engineer on the WiFi network at SFO, for both passengers and > baggage scanners, with several hundred APs. Several times we were misled by > packet captures that seemed to show client traffic causing network problems, > such as packet storms, but which ultimately always had some more mundane > cause, like a failed DHCP server or flapping switch interface. Sure - we're rattling every possible other cause we can think of, including using alternative DHCP server software vendor, etc. The only thing that's reliably making the problem go away is running the APs against WLC version 8.2. > The particular SFO network I worked on has Juniper switching and Aruba APs, > so it???s not directly applicable to your ecosystem. But the complexities of > interpreting packet captures may apply. I'm the sort of person who has copies of RFCs printed out on his desk. I'm fairly experienced at interpreting packet captures :) Simon From mel at beckman.org Thu Mar 14 18:13:50 2019 From: mel at beckman.org (Mel Beckman) Date: Thu, 14 Mar 2019 18:13:50 +0000 Subject: Apple devices spoofing default gateway? In-Reply-To: <20190314170230.GV29673@dilbert.slimey.org> References: <20190314122738.GR29673@dilbert.slimey.org> <2163B326-339F-4BA0-B65A-DF1752431913@beckman.org> <20190314170230.GV29673@dilbert.slimey.org> Message-ID: <89D043B9-4D78-4939-8C8C-F4069496E8DE@beckman.org> You asked if anyone else has seen this. It’s possibly going on in other networks but nobody is noticing. What symptoms brought the problem to your attention? You can sanitize the packet captures by limiting them to just the headers. The payloads are likely not useful for troubleshooting anyway, since this seems to be a Layer 2 problem. You asked for help, and sanitized packets would help people help you :) -mel > On Mar 14, 2019, at 10:02 AM, Simon Lockhart wrote: > > On Thu Mar 14, 2019 at 12:53:01PM +0000, Mel Beckman wrote: >> Can you post some packet captures? > > I have some packet captures, but as they're from a live network, I'd rather > not post them publicly. > >> I was a network engineer on the WiFi network at SFO, for both passengers and >> baggage scanners, with several hundred APs. Several times we were misled by >> packet captures that seemed to show client traffic causing network problems, >> such as packet storms, but which ultimately always had some more mundane >> cause, like a failed DHCP server or flapping switch interface. > > Sure - we're rattling every possible other cause we can think of, including > using alternative DHCP server software vendor, etc. The only thing that's > reliably making the problem go away is running the APs against WLC version 8.2. > >> The particular SFO network I worked on has Juniper switching and Aruba APs, >> so it???s not directly applicable to your ecosystem. But the complexities of >> interpreting packet captures may apply. > > I'm the sort of person who has copies of RFCs printed out on his desk. I'm > fairly experienced at interpreting packet captures :) > > Simon From jhellenthal at dataix.net Thu Mar 14 18:18:47 2019 From: jhellenthal at dataix.net (J. Hellenthal) Date: Thu, 14 Mar 2019 13:18:47 -0500 Subject: Apple devices spoofing default gateway? In-Reply-To: <89D043B9-4D78-4939-8C8C-F4069496E8DE@beckman.org> References: <20190314122738.GR29673@dilbert.slimey.org> <2163B326-339F-4BA0-B65A-DF1752431913@beckman.org> <20190314170230.GV29673@dilbert.slimey.org> <89D043B9-4D78-4939-8C8C-F4069496E8DE@beckman.org> Message-ID: <20190314181848.05F1D3F03F8C@DataIX.net> Right on! https://www.tracewrangler.com/ > On Mar 14, 2019, at 13:13, Mel Beckman wrote: > > You asked if anyone else has seen this. It’s possibly going on in other networks but nobody is noticing. What symptoms brought the problem to your attention? > > You can sanitize the packet captures by limiting them to just the headers. The payloads are likely not useful for troubleshooting anyway, since this seems to be a Layer 2 problem. You asked for help, and sanitized packets would help people help you :) > > -mel > >> On Mar 14, 2019, at 10:02 AM, Simon Lockhart wrote: >> >> On Thu Mar 14, 2019 at 12:53:01PM +0000, Mel Beckman wrote: >>> Can you post some packet captures? >> >> I have some packet captures, but as they're from a live network, I'd rather >> not post them publicly. >> >>> I was a network engineer on the WiFi network at SFO, for both passengers and >>> baggage scanners, with several hundred APs. Several times we were misled by >>> packet captures that seemed to show client traffic causing network problems, >>> such as packet storms, but which ultimately always had some more mundane >>> cause, like a failed DHCP server or flapping switch interface. >> >> Sure - we're rattling every possible other cause we can think of, including >> using alternative DHCP server software vendor, etc. The only thing that's >> reliably making the problem go away is running the APs against WLC version 8.2. >> >>> The particular SFO network I worked on has Juniper switching and Aruba APs, >>> so it???s not directly applicable to your ecosystem. But the complexities of >>> interpreting packet captures may apply. >> >> I'm the sort of person who has copies of RFCs printed out on his desk. I'm >> fairly experienced at interpreting packet captures :) >> >> Simon > — J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. From ops.lists at gmail.com Thu Mar 14 20:21:10 2019 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 14 Mar 2019 20:21:10 +0000 Subject: FB? In-Reply-To: References: <1461790733.9952.1552565854133.JavaMail.mhammett@ThunderFuck> <0B68C416-E859-4512-BE40-8C9E6C83DD44@netscout.com> <1669456769.10063.1552566523336.JavaMail.mhammett@ThunderFuck> <8a8e7978931d41a4b4ff819f82169248@ford.com> <6f3bd066-8009-7432-e255-04d01db2267f@shout.net>, Message-ID: That's a 2010 outage that someone dug out and was doing the rounds as a new one --srs ________________________________ From: NANOG on behalf of cosmo Sent: Thursday, March 14, 2019 9:50 PM To: Bryan Holloway Cc: nanog at nanog.org Subject: Re: FB? Facebook pushed an update to their code that manages cookies, that had a rather severe bug in it that resulted in a large flood of requests to their database servers. To deal with this load, they had to prevent all writes and then slowly allow people back on. I saw the writeup for it last night but cannot seem to find it now! Grrr. Did I dream it? On Thu, Mar 14, 2019 at 8:42 AM Bryan Holloway > wrote: On 3/14/19 9:06 AM, Tom Beecher wrote: > As much as I wanted to crack jokes because I cannot stand Facebook (the > product), much love to all you FB engineers that went through (and are > probably still going through) much hell. > +1 on both counts. We've all been there; no bueno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From selphie.keller at gmail.com Thu Mar 14 21:05:59 2019 From: selphie.keller at gmail.com (Selphie Keller) Date: Thu, 14 Mar 2019 15:05:59 -0600 Subject: FB? In-Reply-To: <1461790733.9952.1552565854133.JavaMail.mhammett@ThunderFuck> References: <1461790733.9952.1552565854133.JavaMail.mhammett@ThunderFuck> Message-ID: I did see this article indicating they had somehow invalidated their cache in a botched deployment of changes - https://www.facebook.com/notes/facebook-engineering/more-details-on-todays-outage/431441338919/ On Thu, 14 Mar 2019 at 06:18, Mike Hammett wrote: > So what happened at Facebook today? I saw one article quoting Roland > saying it was a route leak, but I haven't seen any other sources that > aren't just quoting Roland. Usually there are a few independent posts out > there by now. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lguillory at reservetele.com Thu Mar 14 21:08:53 2019 From: lguillory at reservetele.com (Luke Guillory) Date: Thu, 14 Mar 2019 21:08:53 +0000 Subject: FB? In-Reply-To: References: <1461790733.9952.1552565854133.JavaMail.mhammett@ThunderFuck> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5C027FCE7C0A@RTC-EXCH01.RESERVE.LDS> That’s old. By Robert Johnson on Thursday, September 23, 2010 at 7:29 PM Luke Ns From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Selphie Keller Sent: Thursday, March 14, 2019 4:06 PM To: Mike Hammett Cc: NANOG list Subject: Re: FB? I did see this article indicating they had somehow invalidated their cache in a botched deployment of changes - https://www.facebook.com/notes/facebook-engineering/more-details-on-todays-outage/431441338919/ On Thu, 14 Mar 2019 at 06:18, Mike Hammett > wrote: So what happened at Facebook today? I saw one article quoting Roland saying it was a route leak, but I haven't seen any other sources that aren't just quoting Roland. Usually there are a few independent posts out there by now. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From clinton.mielke at gmail.com Thu Mar 14 21:10:58 2019 From: clinton.mielke at gmail.com (cosmo) Date: Thu, 14 Mar 2019 14:10:58 -0700 Subject: FB? In-Reply-To: References: <1461790733.9952.1552565854133.JavaMail.mhammett@ThunderFuck> Message-ID: Ah-ha, that is indeed the write-up I saw. 8 years old! On Thu, Mar 14, 2019, 2:07 PM Selphie Keller wrote: > I did see this article indicating they had somehow invalidated their cache > in a botched deployment of changes - > https://www.facebook.com/notes/facebook-engineering/more-details-on-todays-outage/431441338919/ > > On Thu, 14 Mar 2019 at 06:18, Mike Hammett wrote: > >> So what happened at Facebook today? I saw one article quoting Roland >> saying it was a route leak, but I haven't seen any other sources that >> aren't just quoting Roland. Usually there are a few independent posts out >> there by now. >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffshultz at sctcweb.com Thu Mar 14 21:11:01 2019 From: jeffshultz at sctcweb.com (Jeff Shultz) Date: Thu, 14 Mar 2019 14:11:01 -0700 Subject: FB? In-Reply-To: References: <1461790733.9952.1552565854133.JavaMail.mhammett@ThunderFuck> Message-ID: The date on that is 2010. On Thu, Mar 14, 2019 at 2:07 PM Selphie Keller wrote: > > I did see this article indicating they had somehow invalidated their cache in a botched deployment of changes - https://www.facebook.com/notes/facebook-engineering/more-details-on-todays-outage/431441338919/ > > On Thu, 14 Mar 2019 at 06:18, Mike Hammett wrote: >> >> So what happened at Facebook today? I saw one article quoting Roland saying it was a route leak, but I haven't seen any other sources that aren't just quoting Roland. Usually there are a few independent posts out there by now. >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> -- Jeff Shultz Central Office Technician SCTC (503) 769-2125 Go Big Ask for Gig -- Like us on Social Media for News, Promotions, and other information!!                      _**** This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ****_ From selphie.keller at gmail.com Thu Mar 14 21:11:52 2019 From: selphie.keller at gmail.com (Selphie Keller) Date: Thu, 14 Mar 2019 15:11:52 -0600 Subject: FB? In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5C027FCE7C0A@RTC-EXCH01.RESERVE.LDS> References: <1461790733.9952.1552565854133.JavaMail.mhammett@ThunderFuck> <8D89F96B7AB1B84F9E049CC7BB91BF5C027FCE7C0A@RTC-EXCH01.RESERVE.LDS> Message-ID: Yeah I just saw that date and that is odd, I got the link yesterday from somewhere and didn't notice the date was old. They do mention the configuration change issue in this one though that is dated today 14th - https://www.cbsnews.com/news/facebook-instagram-down-wednesday-facebook-blames-server-configuration-for-longest-ever-outage/ >From my understanding yesterday is they invalidated their world cache and all the traffic hit their backend quickly overwhelming their servers. It was strange that they didn't really talk about the issue just some brief messages on their twitter saying it wasn't ddos. On Thu, 14 Mar 2019 at 15:08, Luke Guillory wrote: > That’s old. > > > > By Robert Johnson on Thursday, September 23, 2010 at 7:29 PM > > > > > > Luke > > > > Ns > > > > > > > > *From:* NANOG [mailto:nanog-bounces at nanog.org] *On Behalf Of *Selphie > Keller > *Sent:* Thursday, March 14, 2019 4:06 PM > *To:* Mike Hammett > *Cc:* NANOG list > *Subject:* Re: FB? > > > > I did see this article indicating they had somehow invalidated their cache > in a botched deployment of changes - > https://www.facebook.com/notes/facebook-engineering/more-details-on-todays-outage/431441338919/ > > > > On Thu, 14 Mar 2019 at 06:18, Mike Hammett wrote: > > So what happened at Facebook today? I saw one article quoting Roland > saying it was a route leak, but I haven't seen any other sources that > aren't just quoting Roland. Usually there are a few independent posts out > there by now. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rvandolson at esri.com Thu Mar 14 21:13:38 2019 From: rvandolson at esri.com (Ray Van Dolson) Date: Thu, 14 Mar 2019 21:13:38 +0000 Subject: FB? In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5C027FCE7C0A@RTC-EXCH01.RESERVE.LDS> References: <1461790733.9952.1552565854133.JavaMail.mhammett@ThunderFuck> <8D89F96B7AB1B84F9E049CC7BB91BF5C027FCE7C0A@RTC-EXCH01.RESERVE.LDS> Message-ID: https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_facebook_status_1106229690069442560&d=DwIGaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=r4NBNYp4yEcJxC11Po5I-w&m=IHR1veHNjVYVktL31OQ_tgBUNHO5Uf3ACrvIVAW5cho&s=zrKUWVShQdFllKTGbJE5kITG87q7KNJHo0bD6aETBBk&e= From: NANOG On Behalf Of Luke Guillory Sent: Thursday, March 14, 2019 2:09 PM To: Selphie Keller ; Mike Hammett Cc: NANOG list Subject: RE: FB? That’s old. By Robert Johnson on Thursday, September 23, 2010 at 7:29 PM Luke Ns From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Selphie Keller Sent: Thursday, March 14, 2019 4:06 PM To: Mike Hammett Cc: NANOG list Subject: Re: FB? I did see this article indicating they had somehow invalidated their cache in a botched deployment of changes - https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_notes_facebook-2Dengineering_more-2Ddetails-2Don-2Dtodays-2Doutage_431441338919_&d=DwIGaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=r4NBNYp4yEcJxC11Po5I-w&m=IHR1veHNjVYVktL31OQ_tgBUNHO5Uf3ACrvIVAW5cho&s=1EmIo8GEivgILxC4jZzEdBpYWt5R9CZ5cXhtr6i55rc&e= On Thu, 14 Mar 2019 at 06:18, Mike Hammett > wrote: So what happened at Facebook today? I saw one article quoting Roland saying it was a route leak, but I haven't seen any other sources that aren't just quoting Roland. Usually there are a few independent posts out there by now. ----- Mike Hammett Intelligent Computing Solutions https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ics-2Dil.com&d=DwIGaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=r4NBNYp4yEcJxC11Po5I-w&m=IHR1veHNjVYVktL31OQ_tgBUNHO5Uf3ACrvIVAW5cho&s=EAZZC6r_-2rdFCKgq9XpQy30F7OH79M6sZPNvXq0FPA&e= Midwest-IX https://urldefense.proofpoint.com/v2/url?u=http-3A__www.midwest-2Dix.com&d=DwIGaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=r4NBNYp4yEcJxC11Po5I-w&m=IHR1veHNjVYVktL31OQ_tgBUNHO5Uf3ACrvIVAW5cho&s=fEoBWpTXgY7eXczzc8vo7VHbvopKqDWk6Xz2XYutL0k&e= -------------- next part -------------- An HTML attachment was scrubbed... URL: From clinton.mielke at gmail.com Thu Mar 14 21:13:36 2019 From: clinton.mielke at gmail.com (cosmo) Date: Thu, 14 Mar 2019 14:13:36 -0700 Subject: FB? In-Reply-To: References: <1461790733.9952.1552565854133.JavaMail.mhammett@ThunderFuck> <0B68C416-E859-4512-BE40-8C9E6C83DD44@netscout.com> <1669456769.10063.1552566523336.JavaMail.mhammett@ThunderFuck> <8a8e7978931d41a4b4ff819f82169248@ford.com> <6f3bd066-8009-7432-e255-04d01db2267f@shout.net> Message-ID: Looks like Google recently posted their post-mortem of their outage on the 12th https://status.cloud.google.com/incident/storage/19002 On Thu, Mar 14, 2019 at 1:21 PM Suresh Ramasubramanian wrote: > That's a 2010 outage that someone dug out and was doing the rounds as a > new one > > --srs > > ------------------------------ > *From:* NANOG on behalf of cosmo < > clinton.mielke at gmail.com> > *Sent:* Thursday, March 14, 2019 9:50 PM > *To:* Bryan Holloway > *Cc:* nanog at nanog.org > *Subject:* Re: FB? > > Facebook pushed an update to their code that manages cookies, that had a > rather severe bug in it that resulted in a large flood of requests to their > database servers. To deal with this load, they had to prevent all writes > and then slowly allow people back on. > > I saw the writeup for it last night but cannot seem to find it now! Grrr. > Did I dream it? > > On Thu, Mar 14, 2019 at 8:42 AM Bryan Holloway wrote: > >> >> On 3/14/19 9:06 AM, Tom Beecher wrote: >> > As much as I wanted to crack jokes because I cannot stand Facebook (the >> > product), much love to all you FB engineers that went through (and are >> > probably still going through) much hell. >> > >> >> +1 on both counts. >> >> We've all been there; no bueno. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clinton.mielke at gmail.com Thu Mar 14 21:17:58 2019 From: clinton.mielke at gmail.com (cosmo) Date: Thu, 14 Mar 2019 14:17:58 -0700 Subject: FB? In-Reply-To: References: <1461790733.9952.1552565854133.JavaMail.mhammett@ThunderFuck> Message-ID: Yes, evidently someone screenshotted it and it was making the rounds on social media this morning, sans the date. So now back to other theories. On Thu, Mar 14, 2019 at 2:16 PM Jeff Shultz wrote: > The date on that is 2010. > > On Thu, Mar 14, 2019 at 2:07 PM Selphie Keller > wrote: > > > > I did see this article indicating they had somehow invalidated their > cache in a botched deployment of changes - > https://www.facebook.com/notes/facebook-engineering/more-details-on-todays-outage/431441338919/ > > > > On Thu, 14 Mar 2019 at 06:18, Mike Hammett wrote: > >> > >> So what happened at Facebook today? I saw one article quoting Roland > saying it was a route leak, but I haven't seen any other sources that > aren't just quoting Roland. Usually there are a few independent posts out > there by now. > >> > >> > >> > >> ----- > >> Mike Hammett > >> Intelligent Computing Solutions > >> http://www.ics-il.com > >> > >> Midwest-IX > >> http://www.midwest-ix.com > >> > > > -- > Jeff Shultz > Central Office Technician > SCTC > (503) 769-2125 > Go Big Ask for Gig > > -- > Like us on Social Media for News, Promotions, and other information!! > > > > > > > > > > > > > > > > > > > > _**** This message > contains confidential information and is intended only for the individual > named. If you are not the named addressee you should not disseminate, > distribute or copy this e-mail. Please notify the sender immediately by > e-mail if you have received this e-mail by mistake and delete this e-mail > from your system. E-mail transmission cannot be guaranteed to be secure or > error-free as information could be intercepted, corrupted, lost, > destroyed, > arrive late or incomplete, or contain viruses. The sender therefore does > not accept liability for any errors or omissions in the contents of this > message, which arise as a result of e-mail transmission. ****_ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mysidia at gmail.com Thu Mar 14 21:19:04 2019 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 14 Mar 2019 16:19:04 -0500 Subject: Apple devices spoofing default gateway? In-Reply-To: <20190314122738.GR29673@dilbert.slimey.org> References: <20190314122738.GR29673@dilbert.slimey.org> Message-ID: On Thu, Mar 14, 2019 at 7:29 AM Simon Lockhart wrote: > Apple devices, but what's more strange is that we're only seeing it where > those Apple devices are connected to Cisco 1810 and 1815 APs, and where those > APs are connected to a Cisco WLC running v8.5 software. If we downgrade the > WLC to v8.2 the problem goes away (but v8.2 doesn't support 1815 APs, so we Apple's Bonjour protocols include something called Apple Bonjour Sleep Proxy for Wake on Demand --- When a device goes to sleep, the Proxy that runs on various Apple devices is supposed to seize all the IP and MAC addresses that device had registered, so it can wait for an incoming TCP SYN, (and if one's received, then signal the sleeping device to wake up and process the connection.) Bonjour and the related mDNS protocols used for AirPlay/AirPrint/etc are built on Link-Local multicast. I wonder what would happen if some random Wireless LAN controllers malfunctioned, and decided that it would like to ignore that Link-Local restriction and proxy those packets b/w subnets anyways, as if they had been unrestricted multicast or Unicast, Possibly with the source IP address on registration Mangled to or "gateway'd" from the router's IP address. (Or perhaps they wanted to have a feature to let someone AirPlay from a different VLAN than another device?) Either way.... playing around with the source IP address on the Link-local m/c packets might accidentally get them a Default Gateway IP address registered with other workstations as a mobile device that's gone to sleep and needs a proxy. -- -JH From ross at tajvar.io Thu Mar 14 21:39:38 2019 From: ross at tajvar.io (Ross Tajvar) Date: Thu, 14 Mar 2019 17:39:38 -0400 Subject: FB? In-Reply-To: References: <1461790733.9952.1552565854133.JavaMail.mhammett@ThunderFuck> Message-ID: The cache invalidation thing is incorrect according to an Facebook SWE I talked to. He wouldn't tell me what it actually was though, basically saying "you have to know our infrastructure to understand and I can't tell you that." On Thu, Mar 14, 2019, 5:28 PM cosmo wrote: > Yes, evidently someone screenshotted it and it was making the rounds on > social media this morning, sans the date. > > So now back to other theories. > > On Thu, Mar 14, 2019 at 2:16 PM Jeff Shultz > wrote: > >> The date on that is 2010. >> >> On Thu, Mar 14, 2019 at 2:07 PM Selphie Keller >> wrote: >> > >> > I did see this article indicating they had somehow invalidated their >> cache in a botched deployment of changes - >> https://www.facebook.com/notes/facebook-engineering/more-details-on-todays-outage/431441338919/ >> > >> > On Thu, 14 Mar 2019 at 06:18, Mike Hammett wrote: >> >> >> >> So what happened at Facebook today? I saw one article quoting Roland >> saying it was a route leak, but I haven't seen any other sources that >> aren't just quoting Roland. Usually there are a few independent posts out >> there by now. >> >> >> >> >> >> >> >> ----- >> >> Mike Hammett >> >> Intelligent Computing Solutions >> >> http://www.ics-il.com >> >> >> >> Midwest-IX >> >> http://www.midwest-ix.com >> >> >> >> >> -- >> Jeff Shultz >> Central Office Technician >> SCTC >> (503) 769-2125 >> Go Big Ask for Gig >> >> -- >> Like us on Social Media for News, Promotions, and other information!! >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _**** This message >> contains confidential information and is intended only for the individual >> named. If you are not the named addressee you should not disseminate, >> distribute or copy this e-mail. Please notify the sender immediately by >> e-mail if you have received this e-mail by mistake and delete this e-mail >> from your system. E-mail transmission cannot be guaranteed to be secure >> or >> error-free as information could be intercepted, corrupted, lost, >> destroyed, >> arrive late or incomplete, or contain viruses. The sender therefore does >> not accept liability for any errors or omissions in the contents of this >> message, which arise as a result of e-mail transmission. ****_ >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at slimey.org Thu Mar 14 21:40:42 2019 From: simon at slimey.org (Simon Lockhart) Date: Thu, 14 Mar 2019 21:40:42 +0000 Subject: Apple devices spoofing default gateway? In-Reply-To: References: <20190314122738.GR29673@dilbert.slimey.org> Message-ID: <20190314214041.GZ29673@dilbert.slimey.org> On Thu Mar 14, 2019 at 04:19:04PM -0500, Jimmy Hess wrote: > Apple's Bonjour protocols include something called Apple Bonjour Sleep Proxy > for Wake on Demand --- When a device goes to sleep, the Proxy that runs on > various Apple devices is supposed to seize all the IP and MAC addresses that > device had registered, so it can wait for an incoming TCP SYN, (and if one's > received, then signal the sleeping device to wake up and process the > connection.) That's a very interesting observation - when we talk to the users of the Apple devices, they quite often say that the device was 'asleep' when it was sending these 'spoofed' ARP responses. > (Or perhaps they wanted to have a feature to let someone AirPlay from a > different VLAN than another device?) Cisco Wireless does claim to have some features to 'help' Bonjour / mDNS to work better. I wonder if one of those features is misbehaving. Simon From rwfireguru at gmail.com Thu Mar 14 22:23:10 2019 From: rwfireguru at gmail.com (Robert Webb) Date: Thu, 14 Mar 2019 18:23:10 -0400 Subject: FB? In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5C027FCE7C0A@RTC-EXCH01.RESERVE.LDS> References: <1461790733.9952.1552565854133.JavaMail.mhammett@ThunderFuck> <8D89F96B7AB1B84F9E049CC7BB91BF5C027FCE7C0A@RTC-EXCH01.RESERVE.LDS> Message-ID: No one looks at dates on Facebook posts. On Thu, Mar 14, 2019, 17:10 Luke Guillory wrote: > That’s old. > > > > By Robert Johnson on Thursday, September 23, 2010 at 7:29 PM > > > > > > Luke > > > > Ns > > > > > > > > *From:* NANOG [mailto:nanog-bounces at nanog.org] *On Behalf Of *Selphie > Keller > *Sent:* Thursday, March 14, 2019 4:06 PM > *To:* Mike Hammett > *Cc:* NANOG list > *Subject:* Re: FB? > > > > I did see this article indicating they had somehow invalidated their cache > in a botched deployment of changes - > https://www.facebook.com/notes/facebook-engineering/more-details-on-todays-outage/431441338919/ > > > > On Thu, 14 Mar 2019 at 06:18, Mike Hammett wrote: > > So what happened at Facebook today? I saw one article quoting Roland > saying it was a route leak, but I haven't seen any other sources that > aren't just quoting Roland. Usually there are a few independent posts out > there by now. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jheitz at cisco.com Fri Mar 15 00:43:28 2019 From: jheitz at cisco.com (Jakob Heitz (jheitz)) Date: Fri, 15 Mar 2019 00:43:28 +0000 Subject: Analysing traffic in context of rejecting RPKI invalids Message-ID: If at least one ROA matches a route, then the route is valid. This is to cover the case when more than one AS is authorized to originate a particular prefix. https://tools.ietf.org/html/rfc6811 Page 5: o NotFound: No VRP Covers the Route Prefix. o Valid: At least one VRP Matches the Route Prefix. o Invalid: At least one VRP Covers the Route Prefix, but no VRP Matches it. BTW, this rule allows you to issue a ROA authorizing AS0 to originate your complete address space. Why would you do that? Suppose you own an address space, but you only want to announce a portion of it to the internet. If you issue a ROA for the unannounced portion authorizing your own ASN, then an attacker can announce that portion and prepend your ASN. The attacker can thus hijack your unannounced space and appear valid by RPKI! To prevent that, you issue a ROA for your complete address space authorizing AS0 and your BGP announced space authorizing your own ASN. An AS path containing AS0 is malformed, being treated as withdraw. https://tools.ietf.org/html/rfc7607 Regards, Jakob. -----Original Message----- Date: Wed, 13 Mar 2019 11:17:22 -0400 From: Steve Meuse > > > Thanks for the update, but based on that description I'm not certain > that you implemented the same thing that pmacct built, which IMO is > what is needed by those considering deploying a drop-invalids policy. > (Perhaps you omitted mentioning that ability in your description but > included it in your implementation.) > > Thanks Jay, you are correct. As we were talking through the logic we realized we missed that bit. Internally, we're working though the logic to understand if there is a covering route, is that route valid, and if not, will we recurse and look for another covering route that is valid? Either way, we'll be updating our software with that functionality shortly. -Steve From bruce.curtis at ndsu.edu Fri Mar 15 03:05:12 2019 From: bruce.curtis at ndsu.edu (Curtis, Bruce) Date: Fri, 15 Mar 2019 03:05:12 +0000 Subject: Apple devices spoofing default gateway? In-Reply-To: <20190314214041.GZ29673@dilbert.slimey.org> References: <20190314122738.GR29673@dilbert.slimey.org> <20190314214041.GZ29673@dilbert.slimey.org> Message-ID: <248E9125-AA17-4FA7-9622-4729DC2C33B1@ndus.edu> We are running 8.5 and 1815s and I don’t think we are seeing this problem. We do have a very small number of 1810s and did see some strange behavior but it doesn’t seem to match this problem description. Is proxy arp disabled on the default gateway device? That could potentially interact strangely with the features mentioned in earlier posts and mentioned below. > On Mar 14, 2019, at 4:40 PM, Simon Lockhart wrote: > > On Thu Mar 14, 2019 at 04:19:04PM -0500, Jimmy Hess wrote: >> Apple's Bonjour protocols include something called Apple Bonjour Sleep Proxy >> for Wake on Demand --- When a device goes to sleep, the Proxy that runs on >> various Apple devices is supposed to seize all the IP and MAC addresses that >> device had registered, so it can wait for an incoming TCP SYN, (and if one's >> received, then signal the sleeping device to wake up and process the >> connection.) > > That's a very interesting observation - when we talk to the users of the > Apple devices, they quite often say that the device was 'asleep' when it > was sending these 'spoofed' ARP responses. The "Information About Passive Clients” section of this document https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-5/config-guide/b_cg85/wlan_interfaces.html says: "Wireless LAN controllers currently act as a proxy for ARP requests. Upon receiving an ARP request, the controller responds with an ARP response instead of passing the request directly to the client. This scenario has two advantages: • The upstream device that sends out the ARP request to the client will not know where the client is located. • Power for battery-operated devices such as mobile phones and printers is preserved because they do not have to respond to every ARP requests." Perhaps that function on version 8.5 is interacting incorrectly with the Apple Sleep Proxy feature on the Apple devices. "When a sleep proxy sees an IPv4 ARP or IPv6 ND Request for one of the sleeping device's addresses, it answers on behalf of the sleeping device, without waking it up, giving its own MAC address as the current (temporary) owner of that address.” https://en.wikipedia.org/wiki/Bonjour_Sleep_Proxy https://discussions.apple.com/thread/2160614 > >> (Or perhaps they wanted to have a feature to let someone AirPlay from a >> different VLAN than another device?) > > Cisco Wireless does claim to have some features to 'help' Bonjour / mDNS > to work better. I wonder if one of those features is misbehaving. > > Simon --- Bruce Curtis bruce.curtis at ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University From kotikalapudi.sriram at nist.gov Fri Mar 15 17:35:44 2019 From: kotikalapudi.sriram at nist.gov (Sriram, Kotikalapudi (Fed)) Date: Fri, 15 Mar 2019 17:35:44 +0000 Subject: Analysing traffic in context of rejecting RPKI invalids using pmacct Message-ID: Jay: >When we (as7018) were preparing to begin dropping invalid routes >received from peers earlier this year, that is exactly the kind of >analysis we did. In our case we rolled our own with a two-pass >process: we first found all the traffic to/from invalid routes by a >bgp community we gave them, then outside of our flow analysis tool we >further filtered the traffic for invalid routes which were covered by >less-specific not-invalid routes. What remained was the traffic we >would lose once invalid routes were dropped. Had the pmacct >capability existed at that time, we would have used it. We (NIST) did a detailed analysis of Invalid routes (with Routeviews data) that was presented at IETF 101: https://datatracker.ietf.org/meeting/101/materials/slides-101-sidrops-origin-validation-policy-considerations-for-dropping-invalid-routes-00 See slides 10-13. We tried to drill down on Invalid routes which were covered by less-specific not-invalid routes. We examined questions like: how often does the less-specific route have the same origin AS (OAS) as the Invalid, and, if not, then how frequently is the OAS of the less specific route a transit provider of the OAS of the Invalid route? We plan to update the results periodically. Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Fri Mar 15 17:36:58 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 15 Mar 2019 13:36:58 -0400 Subject: Oracle DBA In-Reply-To: <16bfee88-1ee7-9226-b1a7-8c3dcb536987@pubnix.net> References: <3F30A530-936E-4D68-80EB-E4188138E90B@lumaoptics.net> <16bfee88-1ee7-9226-b1a7-8c3dcb536987@pubnix.net> Message-ID: <6155.1552671418@turing-police> On Thu, 14 Mar 2019 07:26:40 -0400, Alain Hebert said: > ��� Run away from... And what realistic competitors does Oracle really have at the high end, when whatever MySQL calls itself now isn't sufficient? Remember to consider all factors, including whether you have a good supply of DBAs for hire at a reasonable price... (And yes, I can remember people saying 'Run away from Cisco' - before Juniper got their act together....) From randy at psg.com Fri Mar 15 17:55:00 2019 From: randy at psg.com (Randy Bush) Date: Fri, 15 Mar 2019 10:55:00 -0700 Subject: Analysing traffic in context of rejecting RPKI invalids using pmacct In-Reply-To: References: Message-ID: >> When we (as7018) were preparing to begin dropping invalid routes >> received from peers earlier this year, that is exactly the kind of >> analysis we did. In our case we rolled our own with a two-pass >> process: we first found all the traffic to/from invalid routes by a >> bgp community we gave them, then outside of our flow analysis tool we >> further filtered the traffic for invalid routes which were covered by >> less-specific not-invalid routes. What remained was the traffic we >> would lose once invalid routes were dropped. Had the pmacct >> capability existed at that time, we would have used it. > > We (NIST) did a detailed analysis of Invalid routes (with Routeviews data) > that was presented at IETF 101: > https://datatracker.ietf.org/meeting/101/materials/slides-101-sidrops-origin-validation-policy-considerations-for-dropping-invalid-routes-00 > See slides 10-13. We tried to drill down on Invalid routes which were covered by > less-specific not-invalid routes. We examined questions like: > how often does the less-specific route have the same origin AS (OAS) as the Invalid, > and, if not, then how frequently is the OAS of the less specific route > a transit provider of the OAS of the Invalid route? > We plan to update the results periodically. Daniele Iamartino, Cristel Pelsser, Randy Bush. "Measuring BGP Route Origin Registration and Validation," PAM 2015. https://archive.psg.com//141223.route-origin-pam2015.pdf https://ripe69.ripe.net/presentations/103-route-origin-validation.pdf From cscora at apnic.net Fri Mar 15 18:02:57 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 16 Mar 2019 04:02:57 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190315180257.3FC2AC55B5@thyme.apnic.net> 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 at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 16 Mar, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 742746 Prefixes after maximum aggregation (per Origin AS): 284987 Deaggregation factor: 2.61 Unique aggregates announced (without unneeded subnets): 357165 Total ASes present in the Internet Routing Table: 63650 Prefixes per ASN: 11.67 Origin-only ASes present in the Internet Routing Table: 54847 Origin ASes announcing only one prefix: 23682 Transit ASes present in the Internet Routing Table: 8803 Transit-only ASes present in the Internet Routing Table: 268 Average AS path length visible in the Internet Routing Table: 4.2 Max AS path length visible: 30 Max AS path prepend of ASN ( 16327) 25 Prefixes from unregistered ASNs in the Routing Table: 28 Number of instances of unregistered ASNs: 32 Number of 32-bit ASNs allocated by the RIRs: 26173 Number of 32-bit ASNs visible in the Routing Table: 21355 Prefixes from 32-bit ASNs in the Routing Table: 93575 Number of bogon 32-bit ASNs visible in the Routing Table: 27 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 266 Number of addresses announced to Internet: 2844073699 Equivalent to 169 /8s, 133 /16s and 30 /24s Percentage of available address space announced: 76.8 Percentage of allocated address space announced: 76.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.2 Total number of prefixes smaller than registry allocations: 249117 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 202186 Total APNIC prefixes after maximum aggregation: 58207 APNIC Deaggregation factor: 3.47 Prefixes being announced from the APNIC address blocks: 198865 Unique aggregates announced from the APNIC address blocks: 82260 APNIC Region origin ASes present in the Internet Routing Table: 9619 APNIC Prefixes per ASN: 20.67 APNIC Region origin ASes announcing only one prefix: 2700 APNIC Region transit ASes present in the Internet Routing Table: 1413 Average APNIC Region AS path length visible: 4.1 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4579 Number of APNIC addresses announced to Internet: 769643394 Equivalent to 45 /8s, 223 /16s and 211 /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-139577 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: 219026 Total ARIN prefixes after maximum aggregation: 103651 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 218231 Unique aggregates announced from the ARIN address blocks: 104548 ARIN Region origin ASes present in the Internet Routing Table: 18424 ARIN Prefixes per ASN: 11.84 ARIN Region origin ASes announcing only one prefix: 6859 ARIN Region transit ASes present in the Internet Routing Table: 1865 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2621 Number of ARIN addresses announced to Internet: 1079341216 Equivalent to 64 /8s, 85 /16s and 112 /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-399260 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: 204462 Total RIPE prefixes after maximum aggregation: 97382 RIPE Deaggregation factor: 2.10 Prefixes being announced from the RIPE address blocks: 200655 Unique aggregates announced from the RIPE address blocks: 118971 RIPE Region origin ASes present in the Internet Routing Table: 25885 RIPE Prefixes per ASN: 7.75 RIPE Region origin ASes announcing only one prefix: 11501 RIPE Region transit ASes present in the Internet Routing Table: 3644 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: 7901 Number of RIPE addresses announced to Internet: 717893568 Equivalent to 42 /8s, 202 /16s and 47 /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-210331 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: 96351 Total LACNIC prefixes after maximum aggregation: 21437 LACNIC Deaggregation factor: 4.49 Prefixes being announced from the LACNIC address blocks: 97712 Unique aggregates announced from the LACNIC address blocks: 41886 LACNIC Region origin ASes present in the Internet Routing Table: 8174 LACNIC Prefixes per ASN: 11.95 LACNIC Region origin ASes announcing only one prefix: 2189 LACNIC Region transit ASes present in the Internet Routing Table: 1526 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5721 Number of LACNIC addresses announced to Internet: 173387264 Equivalent to 10 /8s, 85 /16s and 174 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + 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: 20692 Total AfriNIC prefixes after maximum aggregation: 4288 AfriNIC Deaggregation factor: 4.83 Prefixes being announced from the AfriNIC address blocks: 27017 Unique aggregates announced from the AfriNIC address blocks: 9261 AfriNIC Region origin ASes present in the Internet Routing Table: 1261 AfriNIC Prefixes per ASN: 21.43 AfriNIC Region origin ASes announcing only one prefix: 433 AfriNIC Region transit ASes present in the Internet Routing Table: 251 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 533 Number of AfriNIC addresses announced to Internet: 103540480 Equivalent to 6 /8s, 43 /16s and 231 /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 7545 4666 542 544 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4658 4192 74 ERX-CERNET-BKB China Education and Rese 7552 3100 1240 49 VIETEL-AS-AP Viettel Group, VN 45899 3037 1737 111 VNPT-AS-VN VNPT Corp, VN 4766 2813 11125 767 KIXS-AS-KR Korea Telecom, KR 9829 2749 1496 550 BSNL-NIB National Internet Backbone, IN 9808 2431 8699 26 CMNET-GD Guangdong Mobile Communication 9394 2335 4906 30 CTTNET China TieTong Telecommunications 4755 2140 422 179 TATACOMM-AS TATA Communications formerl 9498 2019 426 163 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 6327 3616 1326 91 SHAW - Shaw Communications Inc., CA 11492 3548 229 616 CABLEONE - CABLE ONE, INC., US 22773 3367 2977 164 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2504 5372 1065 AMAZON-02 - Amazon.com, Inc., US 16625 2245 1280 1763 AKAMAI-AS - Akamai Technologies, Inc., 20115 2150 2746 536 CHARTER-20115 - Charter Communications, 30036 2126 352 145 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 18566 2113 405 108 MEGAPATH5-US - MegaPath Corporation, US 5650 2093 3074 1462 FRONTIER-FRTR - Frontier Communications 209 2081 5094 582 CENTURYLINK-US-LEGACY-QWEST - CenturyLi 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 5417 1628 138 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3282 378 45 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2644 543 1918 AKAMAI-ASN1, US 12389 2227 2221 637 ROSTELECOM-AS, RU 34984 2060 340 538 TELLCOM-AS, TR 9121 1680 1693 19 TTNET, TR 13188 1604 100 46 TRIOLAN, UA 9009 1395 148 762 M247, GB 8402 1294 545 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 8151 5628 3333 590 Uninet S.A. de C.V., MX 10620 3520 539 333 Telmex Colombia S.A., CO 11830 2706 384 34 Instituto Costarricense de Electricidad 6503 1467 433 54 Axtel, S.A.B. de C.V., MX 7303 1435 971 232 Telecom Argentina S.A., AR 28573 1331 2247 180 CLARO S.A., BR 6147 1242 377 29 Telefonica del Peru S.A.A., PE 3816 1022 505 113 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 13999 951 518 247 Mega Cable, S.A. de C.V., MX 11172 928 144 66 Alestra, S. de R.L. de C.V., MX 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 1207 393 21 LINKdotNET-AS, EG 37611 902 107 9 Afrihost, ZA 24835 848 636 22 RAYA-AS, EG 36903 828 416 125 MT-MPLS, MA 36992 800 1531 70 ETISALAT-MISR, EG 8452 700 1731 19 TE-AS TE-AS, EG 29571 485 70 12 ORANGE-COTE-IVOIRE, CI 37492 470 470 57 ORANGE-, TN 15399 429 45 11 WANANCHI-, KE 37342 420 32 1 MOVITEL, MZ 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 5628 3333 590 Uninet S.A. de C.V., MX 12479 5417 1628 138 UNI2-AS, ES 7545 4666 542 544 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4658 4192 74 ERX-CERNET-BKB China Education and Rese 39891 3778 203 20 ALJAWWALSTC-AS, SA 6327 3616 1326 91 SHAW - Shaw Communications Inc., CA 11492 3548 229 616 CABLEONE - CABLE ONE, INC., US 10620 3520 539 333 Telmex Colombia S.A., CO 22773 3367 2977 164 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8551 3282 378 45 BEZEQ-INTERNATIONAL-AS Bezeqint Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5417 5279 UNI2-AS, ES 4538 4658 4584 ERX-CERNET-BKB China Education and Research Net 7545 4666 4122 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3616 3525 SHAW - Shaw Communications Inc., CA 8551 3282 3237 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 3367 3203 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 10620 3520 3187 Telmex Colombia S.A., CO 7552 3100 3051 VIETEL-AS-AP Viettel Group, VN 11492 3548 2932 CABLEONE - CABLE ONE, INC., 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 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65550 DOCUMENT 81.8.34.0/24 15924 BORUSANTELEKOM-AS, TR 65550 DOCUMENT 81.8.35.0/24 15924 BORUSANTELEKOM-AS, TR 1358592 UNALLOCATED 103.134.14.0/23 63956 COLO-AS-AP Colocation Australi 1358592 UNALLOCATED 103.134.15.0/24 63956 COLO-AS-AP Colocation Australi 65549 DOCUMENT 117.239.163.0/24 65544 UNKNOWN 224413 UNALLOCATED 131.221.136.0/24 264413 Conecta Telecom Ltda, BR 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US 64355 UNALLOCATED 156.40.196.0/24 30387 NIH-NET-NCCS - National Instit Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.220.48.0/20 36900 -Reserved AS-, ZZ 43.255.80.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 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:12 /9:10 /10:36 /11:100 /12:291 /13:566 /14:1136 /15:1911 /16:13356 /17:7943 /18:13895 /19:25659 /20:39907 /21:46216 /22:92831 /23:75798 /24:420122 /25:965 /26:845 /27:903 /28:27 /29:7 /30:13 /31:0 /32:197 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4294 5417 UNI2-AS, ES 6327 3391 3616 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2780 3548 CABLEONE - CABLE ONE, INC., US 8551 2736 3282 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2607 3367 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 11830 2051 2706 Instituto Costarricense de Electricidad y Telec 18566 2008 2113 MEGAPATH5-US - MegaPath Corporation, US 30036 1873 2126 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1761 2093 FRONTIER-FRTR - Frontier Communications of Amer Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1606 2:839 4:22 5:2899 6:45 7:1 8:1187 9:1 11:3 12:1858 13:313 14:1931 15:37 16:4 17:237 18:59 20:49 23:2622 24:2536 25:2 27:2543 31:2074 32:97 35:36 36:839 37:3036 38:1688 39:295 40:120 41:3161 42:749 43:2024 44:147 45:6934 46:3252 47:251 49:1356 50:1099 51:322 52:1023 54:289 55:2 56:9 57:41 58:1720 59:1076 60:496 61:2076 62:2001 63:1812 64:4998 65:2213 66:4838 67:2702 68:1150 69:3530 70:1329 71:602 72:2444 74:2763 75:512 76:549 77:1717 78:1760 79:2328 80:1770 81:1503 82:1127 83:883 84:1101 85:2270 86:532 87:1553 88:1034 89:2469 90:215 91:6585 92:1317 93:2436 94:2588 95:3187 96:919 97:347 98:946 99:206 100:88 101:1153 102:465 103:20546 104:3548 105:248 106:857 107:1768 108:689 109:3719 110:1637 111:1880 112:1472 113:1392 114:1135 115:1725 116:1714 117:1892 118:2179 119:1641 120:1023 121:1033 122:2299 123:1656 124:1448 125:1968 128:1264 129:830 130:531 131:1624 132:736 133:219 134:1050 135:242 136:560 137:711 138:2012 139:846 140:573 141:843 142:798 143:1052 144:836 145:514 146:1262 147:800 148:1707 149:824 150:782 151:1005 152:1022 153:322 154:2906 155:899 156:1722 157:921 158:641 159:1918 160:1521 161:920 162:2685 163:795 164:1139 165:1583 166:441 167:1400 168:3272 169:842 170:4052 171:571 172:1112 173:2190 174:1014 175:905 176:2321 177:4150 178:2537 179:1416 180:2131 181:2393 182:2687 183:1068 184:1186 185:14855 186:3647 187:2479 188:2898 189:1987 190:8291 191:1527 192:10044 193:6644 194:5393 195:4066 196:3007 197:1637 198:5822 199:5987 200:7199 201:5105 202:10372 203:10242 204:4563 205:3011 206:3229 207:3287 208:3962 209:4237 210:3931 211:2000 212:3092 213:2887 214:1086 215:55 216:5933 217:2227 218:875 219:580 220:1866 221:967 222:998 223:1414 End of report From jayb at att.com Fri Mar 15 18:03:51 2019 From: jayb at att.com (Jay Borkenhagen) Date: Fri, 15 Mar 2019 14:03:51 -0400 Subject: Analysing traffic in context of rejecting RPKI invalids using pmacct In-Reply-To: References: Message-ID: <23691.59655.680162.719140@oz.mt.att.com> Sriram, Kotikalapudi (Fed) writes: > > >When we (as7018) were preparing to begin dropping invalid routes > >received from peers earlier this year, that is exactly the kind of > >analysis we did. In our case we rolled our own with a two-pass > >process: we first found all the traffic to/from invalid routes by a > >bgp community we gave them, then outside of our flow analysis tool we > >further filtered the traffic for invalid routes which were covered by > >less-specific not-invalid routes. What remained was the traffic we > >would lose once invalid routes were dropped. Had the pmacct > >capability existed at that time, we would have used it. > > We (NIST) did a detailed analysis of Invalid routes (with Routeviews data) > that was presented at IETF 101: > [foo] > See slides 10-13. We tried to drill down on Invalid routes which were covered by > less-specific not-invalid routes. We examined questions like: > how often does the less-specific route have the same origin AS (OAS) as the Invalid, > and, if not, then how frequently is the OAS of the less specific route > a transit provider of the OAS of the Invalid route? > We plan to update the results periodically. Sriram, Please note that this thread is about "Analysing traffic", not routes. Prior to dropping invalid routes, had we seen that we were exchanging any significant amount of traffic with destinations covered only by invalid routes, we would have tried to do something about it. First we would have attempted to contact the holder of the resources in question. If we were not able to resolve the issue that way, then we would have at least considered deploying a temporary whitelist entry, while continuing attempts to fix things the right way. Fortunately it did not come to that. The volume of the invalid-only traffic we were carrying then was insignificant. Of course, traffic volume is not the only thing one should consider prior to dropping invalid routes, but it should be one piece of one's due diligence. Jay B. From crussell at kanren.net Fri Mar 15 18:56:35 2019 From: crussell at kanren.net (Casey Russell) Date: Fri, 15 Mar 2019 13:56:35 -0500 Subject: sending again in case Zoom didn't email it correctly Message-ID: SIP failover call. Casey Russell is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://kanren.zoom.us/j/7858569809 One tap mobile +16699006833,,7858569809# US (San Jose) +16465588656,,7858569809# US (New York) Dial by your location +1 669 900 6833 US (San Jose) +1 646 558 8656 US (New York) Meeting ID: 785 856 9809 Find your local number: https://zoom.us/u/adjAi5zj6Y Sincerely, Casey Russell Network Engineer [image: KanREN] [image: phone]785-856-9809 2029 Becker Drive, Suite 282 Lawrence, Kansas 66047 [image: linkedin] [image: twitter] [image: twitter] need support? -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Fri Mar 15 19:40:19 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Fri, 15 Mar 2019 15:40:19 -0400 Subject: sending again in case Zoom didn't email it correctly In-Reply-To: References: Message-ID: <17771.1552678819@turing-police> On Fri, 15 Mar 2019 13:56:35 -0500, Casey Russell said: > SIP failover call. It's 2019. Surely we have better ways to have SIP fail over than manually sending an e-mail alert redirecting the person to a phone number? From randy at psg.com Fri Mar 15 19:40:34 2019 From: randy at psg.com (Randy Bush) Date: Fri, 15 Mar 2019 12:40:34 -0700 Subject: Analysing traffic in context of rejecting RPKI invalids using pmacct In-Reply-To: <23691.59655.680162.719140@oz.mt.att.com> References: <23691.59655.680162.719140@oz.mt.att.com> Message-ID: ace kumari did some ROV traffic measurements on the ietf meeting network for a few meetings before we turned dropping on randy From jhellenthal at dataix.net Fri Mar 15 19:47:08 2019 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Fri, 15 Mar 2019 14:47:08 -0500 Subject: sending again in case Zoom didn't email it correctly In-Reply-To: <17771.1552678819@turing-police> References: <17771.1552678819@turing-police> Message-ID: <82DA1714-70E2-4D0D-ACF7-C513D322F229@dataix.net> Anyone want to have a large off topic zoom meeting ? :-) consisting of IDK and willing to weigh in.... -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Mar 15, 2019, at 14:40, Valdis Klētnieks wrote: > > On Fri, 15 Mar 2019 13:56:35 -0500, Casey Russell said: > >> SIP failover call. > > It's 2019. Surely we have better ways to have SIP fail over than manually > sending an e-mail alert redirecting the person to a phone number? > From crussell at kanren.net Fri Mar 15 19:57:17 2019 From: crussell at kanren.net (Casey Russell) Date: Fri, 15 Mar 2019 14:57:17 -0500 Subject: sending again in case Zoom didn't email it correctly In-Reply-To: References: Message-ID: Good grief how embarrassing is that? Sorry for the noise. My apologies on not checking the autocomplete when entering the email addresses. Nothing like broadcasting a zoom link to half the operators in the country on accident. Sincerely, Casey Russell Network Engineer [image: KanREN] [image: phone]785-856-9809 2029 Becker Drive, Suite 282 Lawrence, Kansas 66047 [image: linkedin] [image: twitter] [image: twitter] need support? On Fri, Mar 15, 2019 at 1:56 PM Casey Russell wrote: > SIP failover call. > > Casey Russell is inviting you to a scheduled Zoom meeting. Join Zoom > Meeting https://kanren.zoom.us/j/7858569809 > > One tap mobile +16699006833,,7858569809# US (San Jose) > +16465588656,,7858569809# US (New York) Dial by your location +1 669 900 > 6833 US (San Jose) +1 646 558 8656 US (New York) Meeting ID: 785 856 9809 > Find your local number: https://zoom.us/u/adjAi5zj6Y > > > > Sincerely, > Casey Russell > Network Engineer > [image: KanREN] > [image: phone]785-856-9809 > 2029 Becker Drive, Suite 282 > Lawrence, Kansas 66047 > [image: linkedin] > [image: > twitter] [image: twitter] > need support? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at netfire.net Fri Mar 15 20:08:13 2019 From: matt at netfire.net (Matt Harris) Date: Fri, 15 Mar 2019 15:08:13 -0500 Subject: sending again in case Zoom didn't email it correctly In-Reply-To: References: Message-ID: Figures it'd be people from Lawrence. I'm pretty sure everyone there is drunk all of the time. ;) Although admittedly I only stop in there for drinks when I'm on my way back from motorsports events in Topeka. Definitely a nice little town if what you want is a beer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sakamura at gmail.com Fri Mar 15 20:34:51 2019 From: sakamura at gmail.com (Ishmael Rufus) Date: Fri, 15 Mar 2019 15:34:51 -0500 Subject: sending again in case Zoom didn't email it correctly In-Reply-To: References: Message-ID: I didn't get an outlook notification for this. On Fri, Mar 15, 2019 at 3:10 PM Matt Harris wrote: > Figures it'd be people from Lawrence. I'm pretty sure everyone there is > drunk all of the time. ;) > > Although admittedly I only stop in there for drinks when I'm on my way > back from motorsports events in Topeka. Definitely a nice little town if > what you want is a beer. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Fri Mar 15 22:52:40 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Fri, 15 Mar 2019 18:52:40 -0400 Subject: sending again in case Zoom didn't email it correctly In-Reply-To: References: Message-ID: <29594.1552690360@turing-police> On Fri, 15 Mar 2019 15:34:51 -0500, Ishmael Rufus said: > I didn't get an outlook notification for this. That's because Outlook would only send a "engineer stopped for a beer" notification when it was most embarassing. :) From surfer at mauigateway.com Sat Mar 16 01:18:01 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 15 Mar 2019 18:18:01 -0700 Subject: OT: friday fun - geko outsge Message-ID: <20190315181801.72B24431@m0117457.ppops.net> I thought some here might enjoy this. ------------------------------------------ Technician arrived onsite and found no issue with the fiber connection back to the CO. Tech then attempted to reseat the SM-A card and found a gecko in the card slot. Technician removed the gecko and verified that equipment was back in service after slotting back the card. ------------------------------------------ Troubleshooting in the tropics... :-) scott From ops.lists at gmail.com Sat Mar 16 01:24:32 2019 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 16 Mar 2019 06:54:32 +0530 Subject: friday fun - geko outsge In-Reply-To: <20190315181801.72B24431@m0117457.ppops.net> References: <20190315181801.72B24431@m0117457.ppops.net> Message-ID: Was it trying to help them save on car insurance? On 16/03/19, 6:49 AM, "NANOG on behalf of Scott Weeks" wrote: I thought some here might enjoy this. ------------------------------------------ Technician arrived onsite and found no issue with the fiber connection back to the CO. Tech then attempted to reseat the SM-A card and found a gecko in the card slot. Technician removed the gecko and verified that equipment was back in service after slotting back the card. ------------------------------------------ Troubleshooting in the tropics... :-) scott From sean at donelan.com Sat Mar 16 03:07:09 2019 From: sean at donelan.com (Sean Donelan) Date: Fri, 15 Mar 2019 23:07:09 -0400 (EDT) Subject: Proposed National Emergency Communications Plan Updates Message-ID: 2019 Update to the NECP https://www.dhs.gov/cisa/national-emergency-communications-plan CISA is seeking feedback on proposed updates to the NECP — the Nation’s strategic plan to improve emergency communications. Informed by last year’s SAFECOM Nationwide Survey, the NECP provides guidance to those that plan for, coordinate, invest in, and use communications to support response and recovery operations. This includes traditional emergency responder disciplines (e.g., law enforcement, fire, emergency medical services, dispatch) and other entities that share information during emergencies, such as medical facilities, utilities, nongovernmental organizations, as well as the media and private citizens. To prepare stakeholders for a rapidly evolving emergency communications landscape, CISA is leading a national effort to update the NECP (last published in 2014). Proposed updates reflect the expanding ecosystem of people, technologies, and functions involved in supporting emergency communications to aid public safety entities with addressing today's challenges while also planning for future advancements. To provide comments on the updated NECP, complete the feedback form on the DHS website and submit it to OECNECP at hq.dhs.gov by March 22, 2019. From amitchell at isipp.com Sat Mar 16 04:02:50 2019 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Fri, 15 Mar 2019 22:02:50 -0600 Subject: friday fun - geko outsge In-Reply-To: References: <20190315181801.72B24431@m0117457.ppops.net> Message-ID: <9A458105-C7F5-4304-BB07-39FDF114A092@isipp.com> > On Mar 15, 2019, at 7:24 PM, Suresh Ramasubramanian wrote: > > Was it trying to help them save on car insurance? (splorf) Woulda appreciated a C&C warning on that. :-) Anne --- Anne P. Mitchell, Attorney at Law GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant CEO/President, Institute for Social Internet Public Policy Board of Directors, Denver Internet Exchange Board of Directors, Asilomar Microcomputer Workshop Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center California Bar Association Cal. Bar Cyberspace Law Committee Colorado Cyber Committee Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop From rfg at tristatelogic.com Sat Mar 16 20:51:34 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sat, 16 Mar 2019 13:51:34 -0700 Subject: Webzilla Message-ID: <33791.1552769494@segfault.tristatelogic.com> [[ My apologies to thos eof you who may see this twice. I have posted the message below also to the RIPE Anti-Abuse Working Group mailing list, so any of you who are on that list also will see this twice. But I believe that it is relevant here also. ]] ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Perhaps some folks here might be interested to read these two reports, the first of which is a fresh news report published just a couple of days ago, and the other one is a far more detailed investigative report that was completed some time ago now. https://www.buzzfeednews.com/article/kenbensinger/dossier-gubarev-russian-hackers-dnc https://www.documentcloud.org/documents/5770258-Fti.html Please share these links widely. The detailed technical report makes it quite abundantly clear that Webzilla, and all of its various tentacles... many of which even I didn't know about until seeing this report... most probably qualifies as, and has qualified as a "bullet proof hosting" operation for some considerable time now. As the report notes, the company has received over 400,000 complaints or reports of bad behavior, and it is not clear to me, from reading the report, if anyone at the company even bothered to read any more than a small handful of those. I have two comments about this. First, I am inclined to wonder aloud why anyone is even still peering with any of the several ASNs mentioned in the report. To me, the mere fact that any of these ASNs still have connectivity represents a clear and self-evident failure of "self policing" in and among the networks that comprise the Internet. Second, its has already been a well know fact, both to me and to many others, for some years now, that Webzilla is by no means alone in the category commonly refered to as "bullet proof hosters". This fact itself raises some obvious questions. It is clear and apparent, not only from the report linked to above, but from the continuous and years-long existance of -many- "bullet proof hosters" on the Internet that there is no shortage of a market for the services of such hosting companies. The demand for "bullet proof" services is clearly there, and it is not likely to go away any time soon. In addition to the criminal element, there are also various mischevious governments, or their agents, that will always be more than happy to pay premium prices for no-questions-asked connectivity. So the question naturally arises: Other than de-peering by other networks, are there any other steps that can be taken to disincentivize networks from participating in this "bullet proof" market and/or to incentivize them to give a damn about their received network abuse complaints? I have no answers for this question myself, but I felt that it was about time that someone at least posed the question. The industry generally, and especially in the RIPE region, has a clear and evident problem that traditional "self policing" is not solving. Worse yet, it is not even discussed much, and that is allowing it to fester and worsen, over time. It would be Good if there was some actual leadership on this issue, at least from -some- quarter. So far I have not noticed any such worth mentioning. And even looking out towards the future horizon, I don't see any arriving any time soon. Regards, rfg From john at essenz.com Sun Mar 17 14:21:09 2019 From: john at essenz.com (John Von Essen) Date: Sun, 17 Mar 2019 10:21:09 -0400 Subject: Yahoo/Oath GeoDNS Issue (AS36647) Message-ID: If anyone from Yahoo/Oath is here, please email me off-list. Have a GeoDNS issue with yahoo API URLs in Australia, DNS results are returning IPs that are not ideal for the region (like on the other side of the world), it so bad (excess latency), we have to override them locally which I really rather not have to do. This is related to operations of a major/global search engine platform. In Australia, these Yahoo URLs should be resolving to Singapore, but instead are resolving to central USA. The issue started a few weeks back, prior to that DNS resolution was working to Singapore. Thanks John From mehmet at akcin.net Sun Mar 17 17:53:54 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Sun, 17 Mar 2019 10:53:54 -0700 Subject: Yahoo/Oath GeoDNS Issue (AS36647) In-Reply-To: References: Message-ID: I have notified people who is working on this. On Sun, Mar 17, 2019 at 07:21 John Von Essen wrote: > If anyone from Yahoo/Oath is here, please email me off-list. Have a > GeoDNS issue with yahoo API URLs in Australia, DNS results are returning > IPs that are not ideal for the region (like on the other side of the > world), it so bad (excess latency), we have to override them locally > which I really rather not have to do. This is related to operations of a > major/global search engine platform. > > In Australia, these Yahoo URLs should be resolving to Singapore, but > instead are resolving to central USA. The issue started a few weeks > back, prior to that DNS resolution was working to Singapore. > > Thanks > > John > > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From maxtul at netassist.ua Sun Mar 17 18:41:08 2019 From: maxtul at netassist.ua (Max Tulyev) Date: Sun, 17 Mar 2019 20:41:08 +0200 Subject: Webzilla In-Reply-To: <33791.1552769494@segfault.tristatelogic.com> References: <33791.1552769494@segfault.tristatelogic.com> Message-ID: It's quite conveniently to have all botnets C&C in several known ASNs. More pain if it will be spread through thousands regular residential customers, like when use fast(double)flux or peertopeer technologies ;) Joke. Really, there were a lot of cases all upstreams had disconnected some ASN for that type of activity. So it really works. 16.03.19 22:51, Ronald F. Guilmette пише: > [[ My apologies to thos eof you who may see this twice. I have posted the > message below also to the RIPE Anti-Abuse Working Group mailing list, > so any of you who are on that list also will see this twice. But I > believe that it is relevant here also. ]] > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Perhaps some folks here might be interested to read these two reports, > the first of which is a fresh news report published just a couple of > days ago, and the other one is a far more detailed investigative report > that was completed some time ago now. > > https://www.buzzfeednews.com/article/kenbensinger/dossier-gubarev-russian-hackers-dnc > > https://www.documentcloud.org/documents/5770258-Fti.html > > Please share these links widely. > > The detailed technical report makes it quite abundantly clear that > Webzilla, and all of its various tentacles... many of which even I didn't > know about until seeing this report... most probably qualifies as, and > has qualified as a "bullet proof hosting" operation for some considerable > time now. As the report notes, the company has received over 400,000 > complaints or reports of bad behavior, and it is not clear to me, from > reading the report, if anyone at the company even bothered to read any > more than a small handful of those. > > I have two comments about this. > > First, I am inclined to wonder aloud why anyone is even still peering > with any of the several ASNs mentioned in the report. To me, the mere > fact that any of these ASNs still have connectivity represents a clear > and self-evident failure of "self policing" in and among the networks > that comprise the Internet. > > Second, its has already been a well know fact, both to me and to many > others, for some years now, that Webzilla is by no means alone in the > category commonly refered to as "bullet proof hosters". This fact > itself raises some obvious questions. > > It is clear and apparent, not only from the report linked to above, but > from the continuous and years-long existance of -many- "bullet proof > hosters" on the Internet that there is no shortage of a market for the > services of such hosting companies. The demand for "bullet proof" > services is clearly there, and it is not likely to go away any time > soon. In addition to the criminal element, there are also various > mischevious governments, or their agents, that will always be more > than happy to pay premium prices for no-questions-asked connectivity. > > So the question naturally arises: Other than de-peering by other networks, > are there any other steps that can be taken to disincentivize networks > from participating in this "bullet proof" market and/or to incentivize > them to give a damn about their received network abuse complaints? > > I have no answers for this question myself, but I felt that it was about > time that someone at least posed the question. > > The industry generally, and especially in the RIPE region, has a clear > and evident problem that traditional "self policing" is not solving. > Worse yet, it is not even discussed much, and that is allowing it to > fester and worsen, over time. > > It would be Good if there was some actual leadership on this issue, at > least from -some- quarter. So far I have not noticed any such worth > mentioning. And even looking out towards the future horizon, I don't > see any arriving any time soon. > > > Regards, > rfg > From eric.kuhnke at gmail.com Mon Mar 18 07:36:23 2019 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Mon, 18 Mar 2019 00:36:23 -0700 Subject: Webzilla In-Reply-To: <33791.1552769494@segfault.tristatelogic.com> References: <33791.1552769494@segfault.tristatelogic.com> Message-ID: Looking at the AS adjacencies for Webzilla, what would prevent them from disconnecting all of their US/Western Euro based peers and transits, and remaining online behind a mixed selection of the largest Russian ASes? I do not think that any amount of well-researched papers and appeals to ethical ISPs on the NANOG mailing list will bring down those relationships. The likelihood of the Russian domestic legal system implementing US/Western European court orders against bulletproof hosting companies is quite low. On Sat, Mar 16, 2019 at 1:53 PM Ronald F. Guilmette wrote: > > [[ My apologies to thos eof you who may see this twice. I have posted the > message below also to the RIPE Anti-Abuse Working Group mailing list, > so any of you who are on that list also will see this twice. But I > believe that it is relevant here also. ]] > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Perhaps some folks here might be interested to read these two reports, > the first of which is a fresh news report published just a couple of > days ago, and the other one is a far more detailed investigative report > that was completed some time ago now. > > > https://www.buzzfeednews.com/article/kenbensinger/dossier-gubarev-russian-hackers-dnc > > https://www.documentcloud.org/documents/5770258-Fti.html > > Please share these links widely. > > The detailed technical report makes it quite abundantly clear that > Webzilla, and all of its various tentacles... many of which even I didn't > know about until seeing this report... most probably qualifies as, and > has qualified as a "bullet proof hosting" operation for some considerable > time now. As the report notes, the company has received over 400,000 > complaints or reports of bad behavior, and it is not clear to me, from > reading the report, if anyone at the company even bothered to read any > more than a small handful of those. > > I have two comments about this. > > First, I am inclined to wonder aloud why anyone is even still peering > with any of the several ASNs mentioned in the report. To me, the mere > fact that any of these ASNs still have connectivity represents a clear > and self-evident failure of "self policing" in and among the networks > that comprise the Internet. > > Second, its has already been a well know fact, both to me and to many > others, for some years now, that Webzilla is by no means alone in the > category commonly refered to as "bullet proof hosters". This fact > itself raises some obvious questions. > > It is clear and apparent, not only from the report linked to above, but > from the continuous and years-long existance of -many- "bullet proof > hosters" on the Internet that there is no shortage of a market for the > services of such hosting companies. The demand for "bullet proof" > services is clearly there, and it is not likely to go away any time > soon. In addition to the criminal element, there are also various > mischevious governments, or their agents, that will always be more > than happy to pay premium prices for no-questions-asked connectivity. > > So the question naturally arises: Other than de-peering by other networks, > are there any other steps that can be taken to disincentivize networks > from participating in this "bullet proof" market and/or to incentivize > them to give a damn about their received network abuse complaints? > > I have no answers for this question myself, but I felt that it was about > time that someone at least posed the question. > > The industry generally, and especially in the RIPE region, has a clear > and evident problem that traditional "self policing" is not solving. > Worse yet, it is not even discussed much, and that is allowing it to > fester and worsen, over time. > > It would be Good if there was some actual leadership on this issue, at > least from -some- quarter. So far I have not noticed any such worth > mentioning. And even looking out towards the future horizon, I don't > see any arriving any time soon. > > > Regards, > rfg > -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Mon Mar 18 08:50:12 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 18 Mar 2019 01:50:12 -0700 Subject: Webzilla In-Reply-To: References: <33791.1552769494@segfault.tristatelogic.com> Message-ID: isn't i the case that 35415 peers with 174/3356/2914 directly and shouldn't you just be asking those folk: "Hey, err... are you getting these complaints? do you care about the harm?" On Mon, Mar 18, 2019 at 12:37 AM Eric Kuhnke wrote: > Looking at the AS adjacencies for Webzilla, what would prevent them from > disconnecting all of their US/Western Euro based peers and transits, and > remaining online behind a mixed selection of the largest Russian ASes? I do > not think that any amount of well-researched papers and appeals to ethical > ISPs on the NANOG mailing list will bring down those relationships. > > The likelihood of the Russian domestic legal system implementing > US/Western European court orders against bulletproof hosting companies is > quite low. > > > > On Sat, Mar 16, 2019 at 1:53 PM Ronald F. Guilmette > wrote: > >> >> [[ My apologies to thos eof you who may see this twice. I have posted the >> message below also to the RIPE Anti-Abuse Working Group mailing list, >> so any of you who are on that list also will see this twice. But I >> believe that it is relevant here also. ]] >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> Perhaps some folks here might be interested to read these two reports, >> the first of which is a fresh news report published just a couple of >> days ago, and the other one is a far more detailed investigative report >> that was completed some time ago now. >> >> >> https://www.buzzfeednews.com/article/kenbensinger/dossier-gubarev-russian-hackers-dnc >> >> https://www.documentcloud.org/documents/5770258-Fti.html >> >> Please share these links widely. >> >> The detailed technical report makes it quite abundantly clear that >> Webzilla, and all of its various tentacles... many of which even I didn't >> know about until seeing this report... most probably qualifies as, and >> has qualified as a "bullet proof hosting" operation for some considerable >> time now. As the report notes, the company has received over 400,000 >> complaints or reports of bad behavior, and it is not clear to me, from >> reading the report, if anyone at the company even bothered to read any >> more than a small handful of those. >> >> I have two comments about this. >> >> First, I am inclined to wonder aloud why anyone is even still peering >> with any of the several ASNs mentioned in the report. To me, the mere >> fact that any of these ASNs still have connectivity represents a clear >> and self-evident failure of "self policing" in and among the networks >> that comprise the Internet. >> >> Second, its has already been a well know fact, both to me and to many >> others, for some years now, that Webzilla is by no means alone in the >> category commonly refered to as "bullet proof hosters". This fact >> itself raises some obvious questions. >> >> It is clear and apparent, not only from the report linked to above, but >> from the continuous and years-long existance of -many- "bullet proof >> hosters" on the Internet that there is no shortage of a market for the >> services of such hosting companies. The demand for "bullet proof" >> services is clearly there, and it is not likely to go away any time >> soon. In addition to the criminal element, there are also various >> mischevious governments, or their agents, that will always be more >> than happy to pay premium prices for no-questions-asked connectivity. >> >> So the question naturally arises: Other than de-peering by other >> networks, >> are there any other steps that can be taken to disincentivize networks >> from participating in this "bullet proof" market and/or to incentivize >> them to give a damn about their received network abuse complaints? >> >> I have no answers for this question myself, but I felt that it was about >> time that someone at least posed the question. >> >> The industry generally, and especially in the RIPE region, has a clear >> and evident problem that traditional "self policing" is not solving. >> Worse yet, it is not even discussed much, and that is allowing it to >> fester and worsen, over time. >> >> It would be Good if there was some actual leadership on this issue, at >> least from -some- quarter. So far I have not noticed any such worth >> mentioning. And even looking out towards the future horizon, I don't >> see any arriving any time soon. >> >> >> Regards, >> rfg >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bensons at pc.nanog.org Mon Mar 18 20:22:32 2019 From: bensons at pc.nanog.org (Benson Schliesser) Date: Mon, 18 Mar 2019 16:22:32 -0400 Subject: NANOG 76 call for presentations is open Message-ID: NANOG Community, The NANOG Program Committee (PC) is excited to announce that we are now accepting proposals for all sessions at NANOG 76 in Washington, DC, June 10-12, 2019. Below is a summary of key details and dates from the Call For Presentations on the NANOG website, which can be found at http://www.cvent.com/d/s6qzk4/6K Given by many of the industry’s top minds, presentations at NANOG meetings are meant to spark the imagination, encourage dialog, and drive new solutions to our greatest networking challenges. The PC is currently seeking proposals, and also welcomes suggestions for speakers and topics. Presentations may cover current technologies, soon-to-be deployed technologies, and industry innovation. Vendors are welcome to submit talks which cover relevant technologies and capabilities, but presentations should not be promotional, or discuss proprietary solutions. The primary speaker, moderator, or author should submit a presentation proposal and abstract via the PC Tool at: https://pc.nanog.org - Select “Propose Talk” from the “Talks” menu - Select NANOG 76 from the Meeting menu - Select the appropriate *Session* the talk will be presented in - General Session (30-45 minutes) - Tutorial (90-120 minutes) - Track (90-120 minutes) Timeline for submission and proposal review: - Submitter enters abstract (and draft slides if possible) in PC Tool prior to the deadline for slide submission. - PC performs initial review and assigns a “shepherd” to help develop the submission — within 2 weeks. - Submitter develops draft slides of talk if not already submitted with the initial proposal. Please submit initial draft slides early — the PC typically does not accept submissions until draft slides are available for review. NANOG Staff is available to assist with slide templates upon request from the submitter. - Panel and Track submissions should provide a topic list and intended/confirmed participants in the abstract. - PC reviews the slides and continues to work with Submitter as needed to develop the topic. - Draft presentation slides should be submitted prior to the published deadline for slides (May 06, 2019). - PC accepts or declines the submission. - Agenda assembled and posted. - Submitters notified. - Final presentation slides must be submitted prior to the published deadline for slides (Jun. 03, 2019). If you think you have an interesting topic but want feedback or suggestions for developing an idea into a presentation, please email the PC ( nanogpc at nanog.org), and a representative will respond to you in a timely manner. Otherwise, submit your talk, keynote, track, or panel proposal to the PC Tool at your earliest convenience. We look forward to reviewing your submission! Key dates for NANOG 76: Date Event/Deadline Mar. 18, 2019 CFP Opens & Agenda Outline Posted, Early Registration Begins Apr. 15, 2019 Standard Registration Begins May 06, 2019 CFP Deadline: Presentation Slides Due May 13, 2019 CFP Topic List & NANOG Meeting HIghlights Page posted May 28, 2019 NANOG 76 Agenda Posted, Late Registration Begins Jun. 03, 2019 Speaker FINAL presentations DUE (NO CHANGES accepted after this date) Jun. 09, 2019 Lightning Talk Submissions Open, Onsite Registration Begins Final slides must be submitted by Monday, June 3, 2019, and no changes will be accepted between that date and the conference. Materials received after that date may be updated on the website after the completion of the conference. We look forward to seeing you in June in Washington, DC! Sincerely, Benson Schliesser On behalf of the NANOG PC -------------- next part -------------- An HTML attachment was scrubbed... URL: From rfg at tristatelogic.com Mon Mar 18 21:24:36 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 18 Mar 2019 14:24:36 -0700 Subject: Webzilla In-Reply-To: Message-ID: <74769.1552944276@segfault.tristatelogic.com> In message , Eric Kuhnke wrote: >Looking at the AS adjacencies for Webzilla, what would prevent them from >disconnecting all of their US/Western Euro based peers and transits, and >remaining online behind a mixed selection of the largest Russian ASes? I do >not think that any amount of well-researched papers and appeals to ethical >ISPs on the NANOG mailing list will bring down those relationships. Everything you say may be correct, but I personally would feel remiss if I failed to point out the facts of this case to an audience that has it within its power to do something about the issue. And the facts in this case could not be more plain. At best, it can only be said that Webzilla, and all of its various faces, simply doesn't care about the majority of us who just want to use the Internet in peace and security. (And that abundant lack of care seems to be the overriding message of the reports I have cited.) At worst, the company and its various nefarious customers present a clear and present danger, if not to Western democracies then perhaps just to anyone and anything that's connected to the Internet. And all of the companies peering with the various Webzilla companies have a choice -- to support Webzilla and the harmful activities of all of its customers, many of whom have proven themselves, time and again, to be outright dangerous to the rest of us, or alternatively, to take reasonable measures, and do what they can to save themselves, their customers, and people around the world from so easily, conveniently, and inexpensively being hacked, fiddled, hoodwinked and penetrated. So this is the question. Can Western companies really justify, to themselves, to their stockholders, and to their customers, their acts which make it easier than it has to be for the likes of Webzilla to have connectivity? Should these companies, whose profitability and mere existance rests on both the freedom and justice, such as they are, that is commonly available in Western liberal democracies... should these companies continue to support, even if only indirectly, those who would undermine that same freedom and justice on which the companies themselves depend? And even setting aside THAT consequential question, are the long term best interests of these same Western companies best served by an Internet that is known to the public at large as a place primarily characterized by scamming, scheming, and skulduggery? And finally, is it a persuasive arguement to say that because there is crime in the world, and always has been, and likely always will be, that we, and each of us, should harbor and abet criminals simply because it is convenient for us to do so, and perhaps even profitable in the short run? You may think me naive, but I say that the answer each and all of these questions is a resounding "no". It shall not profit any of these companies who provide peering to Webzilla, even if they gain the whole world, if they lose their souls. Will there still be a thriving and growing market for moving bits when nobody in his or her right mind trusts the Internet anymore? Although I am cloaking my arguments, at least to some extent, in moral and ethical terms, I do understand that such considerations are not at all likely to be persuasive when it comes to the world of commerce. That's perfectly OK, because in this instance I believe that I am also arguing in favor of enlightened self-interest. Are any of the customers of any of the companies that provide peering to Webzilla and/or its various parts and pieces better off or worse off because of that peering? I believe that sober and informed reflection on this simple question will yield the Right Answer. In the early years of the 20th century, Vladimir Lenin, leader of the Bolshevik, revolution, famously quipped to his communist collegues that "The capitalists will sell us the rope to hang them with." His prescient words have endured even the fall of the empire he founded because they clarify a simple and fundamental truth -- in capitalist systems, short term greed often overrides both rationality and simple common sense. My hope is that it will not be so on this occasion, and that enligtened long-term self interest will prevail, at least among those companies that are peering with any of Webzilla's ASNs. I would be happy to see Webzilla be given no choice other than to beat a retreat, back to Russia, and to have the company seek connectivity there and only there. If the company wishes to continue either its support for, or its abject tolerance of the kind of nefarious activities documented in detail in the report I cited, then I say let them do that, let them connect only via Russia, and let the company's true allegiances be revealed for all to see. If, as now seems evident, the company wants to continue to flaunt the norms and traditions of the civilized portions of the Internet, then I don't see it as being in anyone else's best interests for Webzilla to continue to be welcomed with open arms, as they currently are, in Dallas, in Singapore, or in any other place where democracy and the rule of law still hold sway. Regards, rfg P.S. For those of you who missed it, I would like to suggest to you all that you google the name "Spammy Bear" and start reading. The press reports on this case arose from my determined efforts to investigate the source of a large scale set of bitcoin extortion spams, which had been sent to tens or hundreds of thousands of recipients across the United States, Canada, Australia, New Zealand, and Hong Kong on December 13th, 2018. These scam-spams informed all those who received it that there was a bomb in their building, and that the bomb would detonante if a certain bitcoin ransom wasn't paid by the end of business on that same day. In te wake of this large scale scam-spam, police, first responders, and bomb squads were called out in innumerable locations throughout all of the affected countries. Innumerable businesses, schools, hospitals, universities, and government buildings were either evacuated or put on lockdown as a reasonable precaution. Even now, several months after the event, you can still get a sense of how widespread this event was by simply going to YouTube and searching for "bitcoin" and "bomb threat". You will then be able to see numerous local media reports from around the country describing the widespread mayhem. I expended some considerable time and effort to try to find out who and what was the source of this massively disruptive event. Although I was not able, in the end, to find a conclusive attribution to any specific individuals, I was at least able to track down the full set of IPv4 addresses that were the likely sources of these bogus bitcoin extortion threats. And in turn, I identified the full set of ASNs that were the likely sources. (I also found out that GoDaddy had a rather serious security problem, but that is and was another story.) Several Russian ASNs were the primary sources of these unambiguously criminal scam-spams. Also however, at least a few of the source IP addresses involved traced back to at least two different Webzilla ASNs. I may not know for certain who the specific criminals were who sent out those bomb threat spams, but Webzilla does, or should anyway. I would be more than happy to receive that information from them, as, I'm sure would any one of the countless law enforcement agencies that were called out, on an emergency basis, on December 13th, 2018, to investigate these bogus bomb threats. I feel sure that, like me, they too are all still hopping mad about this bogus waste of their time and resources. That having been said, I do not anticipate that Webzilla will so easily give up their criminal customers who did this anytime soon. I invite the company to prove me wrong about this. (Not that it would make much difference to anything anyway, in the end. The actual perps who sent those scam-spams are almost certainly located in Russia, and thus, not subject to extradition, even if they were proven to be serial killers.) P.P.S. In a simpler and less naive time, an event like the coast-to-coast wall of bomb threats that was unleashed against my country, the United States of America, on December 13th, 2018 might well have been considered an Act of War. These days, everyone just shrugs and goes back to work. It is left as an exercise for the reader to deduce which response is the more appropriate one, given the totality of present circumstances. From rfg at tristatelogic.com Tue Mar 19 00:02:38 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 18 Mar 2019 17:02:38 -0700 Subject: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland) Message-ID: <75392.1552953758@segfault.tristatelogic.com> OVH, DigitalOcean, and Microsoft... Is there anybody awake and conscious at any of these places? I mean anybody who someone such as myself... just part of the Great Unwashed Masses... could actually speak to about a real and ongoing problem? Maybe most of you here will think that this is just a trivial problem, and one that's not even worth mentioning on NANOG. So be it. Make up you own minds. Here is the problem... For some time now, there has been an ongoing campaign of bitcoin extortion spamming going on which originates primarily or perhaps exclusively from IPv4 addresses owned by OVH and DigitalOcean. These scam spams have now been publicised in multiple places: https://myonlinesecurity.co.uk/fake-cia-sextortion-scam/ Yea, that's just one place, I know, but there's also no shortage of people tweeting about this crap also, in multiple languages even! https://twitter.com/SpamAuditor/status/1107365604636278784 https://twitter.com/dvk01uk/status/1107510553621266433 https://twitter.com/bortzmeyer/status/1107737034049900544 https://twitter.com/ariestess69/status/1107468838596038656 https://twitter.com/bernhard_mahr/status/1107513313020297216 https://twitter.com/jzmurdock/status/1107679858945974272 https://twitter.com/gamamb/status/1107384186548207617 https://twitter.com/davidgsIoT/status/1107725201331097606 https://twitter.com/cybers_guards/status/1107675396076560384 https://twitter.com/ThatHostingCo/status/1107588660831105024 https://twitter.com/fladna9/status/1107554090765242368 https://twitter.com/JUSTADACHI/status/1107549777607184384 https://twitter.com/okhin/status/1107627379650908160 https://twitter.com/Purple_Wyrm/status/1107454618705887232 https://twitter.com/LadyOFyre/status/1107349022220550144 https://twitter.com/laurelvail/status/1107345980062523392 https://twitter.com/Alex__Rubio/status/1107595560440217600 The thing of it is that ALL of this crap... al of these scam spams... are quite obviously originating out of the networks of OVH and DigitalOcean. And it's not even all that hard to figure out where from, exactly and specifically. I generated the following survey, on the fly, last night, based on a simple reverse DNS scan of the evidently relevant addrdess ranges: https://pastebin.com/raw/WtM0Y5yC As anyone who isn't as blind as a bat can easily see, there's a bit of a pattern here. All of the spam source IPs are on just two ASNs: AS16276 - OVH SAS AS4061 - DigitalOcean, LLC It's equally clear that there have already been numerous reports about this ongoing and blatantly criminal activity that have been sent to the low-level high school dropout interns that these companies, like most others on the Internet these days, choose to employ as their first-level minions in their "not a profit center" abuse handling departments. So, guess what? Surprise, surprise! None of those clue-deprived flunkies have apparently yet managed to figure out that there's a pattern here. Duh!. As a result, the scamming and the spamming just go on and on and on, and the spammer-scammer just keeps on getting fresh new IP addresess on both of these networks... and fresh (and utterly free) new domain names from the equally careless company called Freenom. So, you know, I really would appreciate it if someone could either put me in touch with some actual sentient being at either OVH or DigitalOcean... assuming that any such actually exist... or at the very least, try to find one to whom clue may be passed about all this, because although these scam spams were kind of humorous and novel at first, the novelty has now worn off and they're really not all that funny anymore. Oh! And while we are on the subject, I'd also like to obtain a contact, preferbly one which is also and likewise in possession of something roughly approximating clue, at this place: AS200517 - Microsoft Deutschland MCIO GmbH The reason is that although MS Deutschland is most probably not the source of any of the spams, they, or at least their 51.18.39.107 address, do appear to be mixed up in all of this somehow: https://pastebin.com/raw/ziVNCmZ8 I dunno. Maybe Microsoft has managed to engineer a merger with the CIA (?) If not, then maybe they would be so kind as to rat out this specific criminal customer of their's to appropriate authorities. Don't get me wrong. I heartily applaud Microsoft's Digital Crimes Unit for all of the admirable work they do, but you know the old saying... charity begins at home. So my hope is that they will seek to get this low-life off their network immediately, if not sooner, and then also seek to arrange suitable long term accomodations for him in, say, Florence, Colorado, or, if he/she/it has a higher than average level of tan, I hope that they will make all necessary inquiries to find out if there are still any open bunks available in Gitmo. Regards, rfg P.S. In recent days, the popular media has fanned the flames of controversy, as it is their habit to do, over the question of whether or not the various social media companies could have somehow automagically spotted and deleted, in real time, with some sort of yet-to-be-invented artificial intelligence wizardry, the shooter videos from New Zealand. Of course, none of the TV personalities who so cavalierly offer up their totally uninformed opinions on this question have ever themselves gotten within a country mile of the kinds of AI that could, perhaps in another decade or three, reliably distinguish between a video of a msss shooting and a video of a particularly raucous birthday party. It's a hard problem. In contrast to that hard problem, spotting the kind of trivial reverse DNS pattern I've noted above is child's play and a no brainer. Why then, one might reasonbly ask, have the combined abuse departments of both OVH and DigitalOcean been either utterly unable or else utterly unwilling to do so? Solving these kinds of trivial problems does not await the development of some advanced new artificial intelligence. It just requires the judicious application of a small bit of the non-artificial kind of intelligence. But the industry, it seems, can't, or won't, even manage that. From dovid at telecurve.com Tue Mar 19 01:17:19 2019 From: dovid at telecurve.com (Dovid Bender) Date: Mon, 18 Mar 2019 21:17:19 -0400 Subject: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland) In-Reply-To: <75392.1552953758@segfault.tristatelogic.com> References: <75392.1552953758@segfault.tristatelogic.com> Message-ID: Two notes: 1) We have seen most of the telecom fraud happen from three general locations a. The phones themselves. For instance people putting phones out there with the default password. b. Compromised routers. Fraudsters will compromise a CPE and bounce their traffic through it. Back in the day when we banned Palestine most of the fraud went down. Once they caught on they realized the traffic needed to flow from anywhere but PS. c. OVH - We used to get a lot from there till we started banning large blocks of their ranges. It seems the fraudsters caught on and they are going the route of compromised CPE's. 2) I spoke a few years back with the lead network engineers at DO and without giving away too much they are very aware that people use their network for fraud and actively work against it. I am nor sure about their abuse team but I know their core engineers have methods in place and shut down malicious activity. The issue is it's easier said then done. On Mon, Mar 18, 2019 at 8:03 PM Ronald F. Guilmette wrote: > > OVH, DigitalOcean, and Microsoft... > > Is there anybody awake and conscious at any of these places? I mean > anybody who someone such as myself... just part of the Great Unwashed > Masses... could actually speak to about a real and ongoing problem? > > Maybe most of you here will think that this is just a trivial problem, and > one that's not even worth mentioning on NANOG. So be it. Make up you own > minds. Here is the problem... > > For some time now, there has been an ongoing campaign of bitcoin > extortion spamming going on which originates primarily or perhaps > exclusively from IPv4 addresses owned by OVH and DigitalOcean. > These scam spams have now been publicised in multiple places: > > https://myonlinesecurity.co.uk/fake-cia-sextortion-scam/ > > Yea, that's just one place, I know, but there's also no shortage of people > tweeting about this crap also, in multiple languages even! > > https://twitter.com/SpamAuditor/status/1107365604636278784 > https://twitter.com/dvk01uk/status/1107510553621266433 > https://twitter.com/bortzmeyer/status/1107737034049900544 > https://twitter.com/ariestess69/status/1107468838596038656 > https://twitter.com/bernhard_mahr/status/1107513313020297216 > https://twitter.com/jzmurdock/status/1107679858945974272 > https://twitter.com/gamamb/status/1107384186548207617 > https://twitter.com/davidgsIoT/status/1107725201331097606 > https://twitter.com/cybers_guards/status/1107675396076560384 > https://twitter.com/ThatHostingCo/status/1107588660831105024 > https://twitter.com/fladna9/status/1107554090765242368 > https://twitter.com/JUSTADACHI/status/1107549777607184384 > https://twitter.com/okhin/status/1107627379650908160 > https://twitter.com/Purple_Wyrm/status/1107454618705887232 > https://twitter.com/LadyOFyre/status/1107349022220550144 > https://twitter.com/laurelvail/status/1107345980062523392 > https://twitter.com/Alex__Rubio/status/1107595560440217600 > > The thing of it is that ALL of this crap... al of these scam spams... are > quite obviously originating out of the networks of OVH and DigitalOcean. > And it's not even all that hard to figure out where from, exactly and > specifically. I generated the following survey, on the fly, last night, > based on a simple reverse DNS scan of the evidently relevant addrdess > ranges: > > https://pastebin.com/raw/WtM0Y5yC > > As anyone who isn't as blind as a bat can easily see, there's a bit of a > pattern here. All of the spam source IPs are on just two ASNs: > > AS16276 - OVH SAS > AS4061 - DigitalOcean, LLC > > It's equally clear that there have already been numerous reports about this > ongoing and blatantly criminal activity that have been sent to the > low-level > high school dropout interns that these companies, like most others on the > Internet these days, choose to employ as their first-level minions in their > "not a profit center" abuse handling departments. So, guess what? > Surprise, > surprise! None of those clue-deprived flunkies have apparently yet managed > to figure out that there's a pattern here. Duh!. As a result, the > scamming > and the spamming just go on and on and on, and the spammer-scammer just > keeps on getting fresh new IP addresess on both of these networks... and > fresh (and utterly free) new domain names from the equally careless company > called Freenom. > > So, you know, I really would appreciate it if someone could either put me > in touch with some actual sentient being at either OVH or DigitalOcean... > assuming that any such actually exist... or at the very least, try to find > one to whom clue may be passed about all this, because although these scam > spams were kind of humorous and novel at first, the novelty has now worn > off > and they're really not all that funny anymore. > > Oh! And while we are on the subject, I'd also like to obtain a contact, > preferbly one which is also and likewise in possession of something roughly > approximating clue, at this place: > > AS200517 - Microsoft Deutschland MCIO GmbH > > The reason is that although MS Deutschland is most probably not the source > of any of the spams, they, or at least their 51.18.39.107 address, do > appear > to be mixed up in all of this somehow: > > https://pastebin.com/raw/ziVNCmZ8 > > I dunno. Maybe Microsoft has managed to engineer a merger with the CIA (?) > If not, then maybe they would be so kind as to rat out this specific > criminal > customer of their's to appropriate authorities. > > Don't get me wrong. I heartily applaud Microsoft's Digital Crimes Unit for > all of the admirable work they do, but you know the old saying... charity > begins at home. So my hope is that they will seek to get this low-life off > their network immediately, if not sooner, and then also seek to arrange > suitable long term accomodations for him in, say, Florence, Colorado, or, > if he/she/it has a higher than average level of tan, I hope that they will > make all necessary inquiries to find out if there are still any open bunks > available in Gitmo. > > > Regards, > rfg > > > P.S. In recent days, the popular media has fanned the flames of > controversy, > as it is their habit to do, over the question of whether or not the various > social media companies could have somehow automagically spotted and > deleted, > in real time, with some sort of yet-to-be-invented artificial intelligence > wizardry, the shooter videos from New Zealand. Of course, none of the TV > personalities who so cavalierly offer up their totally uninformed opinions > on this question have ever themselves gotten within a country mile of the > kinds of AI that could, perhaps in another decade or three, reliably > distinguish between a video of a msss shooting and a video of a > particularly > raucous birthday party. It's a hard problem. > > In contrast to that hard problem, spotting the kind of trivial reverse DNS > pattern I've noted above is child's play and a no brainer. Why then, one > might reasonbly ask, have the combined abuse departments of both OVH and > DigitalOcean been either utterly unable or else utterly unwilling to do so? > Solving these kinds of trivial problems does not await the development of > some advanced new artificial intelligence. It just requires the judicious > application of a small bit of the non-artificial kind of intelligence. But > the industry, it seems, can't, or won't, even manage that. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chkuhtz at microsoft.com Tue Mar 19 01:37:25 2019 From: chkuhtz at microsoft.com (Christian Kuhtz) Date: Tue, 19 Mar 2019 01:37:25 +0000 Subject: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland) In-Reply-To: <75392.1552953758@segfault.tristatelogic.com> References: <75392.1552953758@segfault.tristatelogic.com> Message-ID: Ronald, we are asking Microsoft CDOC to investigate. You can find a variety of ways to report issues at their website as well: https://www.microsoft.com/en-us/msrc/cdoc Thanks, Christian ________________________________ From: NANOG on behalf of Ronald F. Guilmette Sent: Monday, March 18, 2019 5:02:38 PM To: nanog at nanog.org Subject: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland) OVH, DigitalOcean, and Microsoft... Is there anybody awake and conscious at any of these places? I mean anybody who someone such as myself... just part of the Great Unwashed Masses... could actually speak to about a real and ongoing problem? Maybe most of you here will think that this is just a trivial problem, and one that's not even worth mentioning on NANOG. So be it. Make up you own minds. Here is the problem... For some time now, there has been an ongoing campaign of bitcoin extortion spamming going on which originates primarily or perhaps exclusively from IPv4 addresses owned by OVH and DigitalOcean. These scam spams have now been publicised in multiple places: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmyonlinesecurity.co.uk%2Ffake-cia-sextortion-scam%2F&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393817755&sdata=G9Hg5walAZerFD9PnEQXIGzAVbzJNIS2KYET4HBBuco%3D&reserved=0 Yea, that's just one place, I know, but there's also no shortage of people tweeting about this crap also, in multiple languages even! https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FSpamAuditor%2Fstatus%2F1107365604636278784&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=k%2BMCTB2IkJwSqTONEkyo5rclZ7ACRB5B1%2FPLCFdfih4%3D&reserved=0 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fdvk01uk%2Fstatus%2F1107510553621266433&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=td3Ut9lblQnfKP2%2FDcVOSmrv%2F2vBop3PciSjELtv6GU%3D&reserved=0 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fbortzmeyer%2Fstatus%2F1107737034049900544&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=FV9rQ433O0uFkolp%2F4nz%2BFSRp4qC7YzjfHXM8sQTVbk%3D&reserved=0 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fariestess69%2Fstatus%2F1107468838596038656&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=sw5szX9XIE5gn9T5QB1qYSGW%2FF0ZFrBXi1R%2BaXY8c50%3D&reserved=0 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fbernhard_mahr%2Fstatus%2F1107513313020297216&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=wNhWzgjRIdon3zbnxlWBAo8rtiGwcqSSFFPwon7BQzY%3D&reserved=0 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fjzmurdock%2Fstatus%2F1107679858945974272&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=7tUqGf%2B157mD4d%2BLt11rnYT0xymSd4zwSDFmiof0ZmE%3D&reserved=0 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fgamamb%2Fstatus%2F1107384186548207617&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=xRJyg4F45qXdZtA3iMM3USsB7lZb0%2BIYXMSH%2BsY6jYA%3D&reserved=0 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FdavidgsIoT%2Fstatus%2F1107725201331097606&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=7klohIIudOseoOGP52YAR8iaytskolyM4nR8L6tbYeI%3D&reserved=0 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fcybers_guards%2Fstatus%2F1107675396076560384&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=oQr6NZJALnj69Msz7P7XjPgYfQ3mqKEZWnp1bmNzi2M%3D&reserved=0 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FThatHostingCo%2Fstatus%2F1107588660831105024&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=nj7CPej33pQFejB5Q8AF2nvANB%2BuLt8wv2imnlIggnU%3D&reserved=0 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Ffladna9%2Fstatus%2F1107554090765242368&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=v7CxmK3NbtoKVPu9aaRvtZh2xyMXXxocjbWM6ipz3DQ%3D&reserved=0 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FJUSTADACHI%2Fstatus%2F1107549777607184384&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=SnR1zh5au%2B1E1NrSK8v8BAE2SZT5QeDqKKu8ZxfhZlI%3D&reserved=0 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fokhin%2Fstatus%2F1107627379650908160&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=kRepqjm69Q4FYvaxSXocdMmVWZFKeLwaepSDjRecSgk%3D&reserved=0 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FPurple_Wyrm%2Fstatus%2F1107454618705887232&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=OrjjyCmz8dg7GmAu%2BsrWGx1AEeQWldDCNM7HdFj6XO0%3D&reserved=0 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FLadyOFyre%2Fstatus%2F1107349022220550144&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=bfVOPifXbNnvmuby13VI%2B%2FYsBXSIHF8tIfaCj1OQrmE%3D&reserved=0 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Flaurelvail%2Fstatus%2F1107345980062523392&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=RO%2Bsz5FXjn78A8x7c%2BZ6P%2BghH9bJYgDCBcJi20SYOro%3D&reserved=0 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FAlex__Rubio%2Fstatus%2F1107595560440217600&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393837741&sdata=BK8L6WcuS039Rf2lYNI0qZftj2DcIIomH0gl89P4APM%3D&reserved=0 The thing of it is that ALL of this crap... al of these scam spams... are quite obviously originating out of the networks of OVH and DigitalOcean. And it's not even all that hard to figure out where from, exactly and specifically. I generated the following survey, on the fly, last night, based on a simple reverse DNS scan of the evidently relevant addrdess ranges: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2Fraw%2FWtM0Y5yC&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393837741&sdata=I7W%2FyU7yoMlor3u4CkkSlmPtgO7clQA42sz6blLPY3U%3D&reserved=0 As anyone who isn't as blind as a bat can easily see, there's a bit of a pattern here. All of the spam source IPs are on just two ASNs: AS16276 - OVH SAS AS4061 - DigitalOcean, LLC It's equally clear that there have already been numerous reports about this ongoing and blatantly criminal activity that have been sent to the low-level high school dropout interns that these companies, like most others on the Internet these days, choose to employ as their first-level minions in their "not a profit center" abuse handling departments. So, guess what? Surprise, surprise! None of those clue-deprived flunkies have apparently yet managed to figure out that there's a pattern here. Duh!. As a result, the scamming and the spamming just go on and on and on, and the spammer-scammer just keeps on getting fresh new IP addresess on both of these networks... and fresh (and utterly free) new domain names from the equally careless company called Freenom. So, you know, I really would appreciate it if someone could either put me in touch with some actual sentient being at either OVH or DigitalOcean... assuming that any such actually exist... or at the very least, try to find one to whom clue may be passed about all this, because although these scam spams were kind of humorous and novel at first, the novelty has now worn off and they're really not all that funny anymore. Oh! And while we are on the subject, I'd also like to obtain a contact, preferbly one which is also and likewise in possession of something roughly approximating clue, at this place: AS200517 - Microsoft Deutschland MCIO GmbH The reason is that although MS Deutschland is most probably not the source of any of the spams, they, or at least their 51.18.39.107 address, do appear to be mixed up in all of this somehow: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2Fraw%2FziVNCmZ8&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393837741&sdata=dSVZUSMJeIZFaBgDygm7o7SmTibWdi8LwQBO6v4ftWo%3D&reserved=0 I dunno. Maybe Microsoft has managed to engineer a merger with the CIA (?) If not, then maybe they would be so kind as to rat out this specific criminal customer of their's to appropriate authorities. Don't get me wrong. I heartily applaud Microsoft's Digital Crimes Unit for all of the admirable work they do, but you know the old saying... charity begins at home. So my hope is that they will seek to get this low-life off their network immediately, if not sooner, and then also seek to arrange suitable long term accomodations for him in, say, Florence, Colorado, or, if he/she/it has a higher than average level of tan, I hope that they will make all necessary inquiries to find out if there are still any open bunks available in Gitmo. Regards, rfg P.S. In recent days, the popular media has fanned the flames of controversy, as it is their habit to do, over the question of whether or not the various social media companies could have somehow automagically spotted and deleted, in real time, with some sort of yet-to-be-invented artificial intelligence wizardry, the shooter videos from New Zealand. Of course, none of the TV personalities who so cavalierly offer up their totally uninformed opinions on this question have ever themselves gotten within a country mile of the kinds of AI that could, perhaps in another decade or three, reliably distinguish between a video of a msss shooting and a video of a particularly raucous birthday party. It's a hard problem. In contrast to that hard problem, spotting the kind of trivial reverse DNS pattern I've noted above is child's play and a no brainer. Why then, one might reasonbly ask, have the combined abuse departments of both OVH and DigitalOcean been either utterly unable or else utterly unwilling to do so? Solving these kinds of trivial problems does not await the development of some advanced new artificial intelligence. It just requires the judicious application of a small bit of the non-artificial kind of intelligence. But the industry, it seems, can't, or won't, even manage that. From nik at neko.id.au Tue Mar 19 01:50:26 2019 From: nik at neko.id.au (Nikolas Geyer) Date: Tue, 19 Mar 2019 01:50:26 +0000 Subject: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland) In-Reply-To: References: <75392.1552953758@segfault.tristatelogic.com>, Message-ID: <59B616E6-09B6-4C18-B7EF-B02CD8D146C2@neko.id.au> RFG; I have passed your email on to the relevant team within DO to have a look at. I’d like to thank you for your deriding commentary to bring attention to this problem. I am not sure it is the most effective way to try and engage the wider industry on a public list, but each to their own. Oh, and additionally, as an Australian citizen with many Aussie and Kiwi colleagues working at DO of various religious persuasions; your postscript relating this back to the recent terror attacks is abhorrent and disgusting. You should be completely ashamed. Kind regards, Nik. Sent from my iPhone > On Mar 18, 2019, at 9:39 PM, Christian Kuhtz via NANOG wrote: > > Ronald, > > we are asking Microsoft CDOC to investigate. > > You can find a variety of ways to report issues at their website as well: https://www.microsoft.com/en-us/msrc/cdoc > > Thanks, > Christian > > ________________________________ > From: NANOG on behalf of Ronald F. Guilmette > Sent: Monday, March 18, 2019 5:02:38 PM > To: nanog at nanog.org > Subject: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland) > > > OVH, DigitalOcean, and Microsoft... > > Is there anybody awake and conscious at any of these places? I mean > anybody who someone such as myself... just part of the Great Unwashed > Masses... could actually speak to about a real and ongoing problem? > > Maybe most of you here will think that this is just a trivial problem, and > one that's not even worth mentioning on NANOG. So be it. Make up you own > minds. Here is the problem... > > For some time now, there has been an ongoing campaign of bitcoin > extortion spamming going on which originates primarily or perhaps > exclusively from IPv4 addresses owned by OVH and DigitalOcean. > These scam spams have now been publicised in multiple places: > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmyonlinesecurity.co.uk%2Ffake-cia-sextortion-scam%2F&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393817755&sdata=G9Hg5walAZerFD9PnEQXIGzAVbzJNIS2KYET4HBBuco%3D&reserved=0 > > Yea, that's just one place, I know, but there's also no shortage of people > tweeting about this crap also, in multiple languages even! > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FSpamAuditor%2Fstatus%2F1107365604636278784&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=k%2BMCTB2IkJwSqTONEkyo5rclZ7ACRB5B1%2FPLCFdfih4%3D&reserved=0 > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fdvk01uk%2Fstatus%2F1107510553621266433&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=td3Ut9lblQnfKP2%2FDcVOSmrv%2F2vBop3PciSjELtv6GU%3D&reserved=0 > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fbortzmeyer%2Fstatus%2F1107737034049900544&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=FV9rQ433O0uFkolp%2F4nz%2BFSRp4qC7YzjfHXM8sQTVbk%3D&reserved=0 > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fariestess69%2Fstatus%2F1107468838596038656&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=sw5szX9XIE5gn9T5QB1qYSGW%2FF0ZFrBXi1R%2BaXY8c50%3D&reserved=0 > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fbernhard_mahr%2Fstatus%2F1107513313020297216&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=wNhWzgjRIdon3zbnxlWBAo8rtiGwcqSSFFPwon7BQzY%3D&reserved=0 > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fjzmurdock%2Fstatus%2F1107679858945974272&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=7tUqGf%2B157mD4d%2BLt11rnYT0xymSd4zwSDFmiof0ZmE%3D&reserved=0 > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fgamamb%2Fstatus%2F1107384186548207617&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=xRJyg4F45qXdZtA3iMM3USsB7lZb0%2BIYXMSH%2BsY6jYA%3D&reserved=0 > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FdavidgsIoT%2Fstatus%2F1107725201331097606&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=7klohIIudOseoOGP52YAR8iaytskolyM4nR8L6tbYeI%3D&reserved=0 > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fcybers_guards%2Fstatus%2F1107675396076560384&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=oQr6NZJALnj69Msz7P7XjPgYfQ3mqKEZWnp1bmNzi2M%3D&reserved=0 > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FThatHostingCo%2Fstatus%2F1107588660831105024&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=nj7CPej33pQFejB5Q8AF2nvANB%2BuLt8wv2imnlIggnU%3D&reserved=0 > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Ffladna9%2Fstatus%2F1107554090765242368&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=v7CxmK3NbtoKVPu9aaRvtZh2xyMXXxocjbWM6ipz3DQ%3D&reserved=0 > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FJUSTADACHI%2Fstatus%2F1107549777607184384&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=SnR1zh5au%2B1E1NrSK8v8BAE2SZT5QeDqKKu8ZxfhZlI%3D&reserved=0 > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fokhin%2Fstatus%2F1107627379650908160&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=kRepqjm69Q4FYvaxSXocdMmVWZFKeLwaepSDjRecSgk%3D&reserved=0 > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FPurple_Wyrm%2Fstatus%2F1107454618705887232&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=OrjjyCmz8dg7GmAu%2BsrWGx1AEeQWldDCNM7HdFj6XO0%3D&reserved=0 > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FLadyOFyre%2Fstatus%2F1107349022220550144&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=bfVOPifXbNnvmuby13VI%2B%2FYsBXSIHF8tIfaCj1OQrmE%3D&reserved=0 > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Flaurelvail%2Fstatus%2F1107345980062523392&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393827747&sdata=RO%2Bsz5FXjn78A8x7c%2BZ6P%2BghH9bJYgDCBcJi20SYOro%3D&reserved=0 > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FAlex__Rubio%2Fstatus%2F1107595560440217600&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393837741&sdata=BK8L6WcuS039Rf2lYNI0qZftj2DcIIomH0gl89P4APM%3D&reserved=0 > > The thing of it is that ALL of this crap... al of these scam spams... are > quite obviously originating out of the networks of OVH and DigitalOcean. > And it's not even all that hard to figure out where from, exactly and > specifically. I generated the following survey, on the fly, last night, > based on a simple reverse DNS scan of the evidently relevant addrdess > ranges: > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2Fraw%2FWtM0Y5yC&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393837741&sdata=I7W%2FyU7yoMlor3u4CkkSlmPtgO7clQA42sz6blLPY3U%3D&reserved=0 > > As anyone who isn't as blind as a bat can easily see, there's a bit of a > pattern here. All of the spam source IPs are on just two ASNs: > > AS16276 - OVH SAS > AS4061 - DigitalOcean, LLC > > It's equally clear that there have already been numerous reports about this > ongoing and blatantly criminal activity that have been sent to the low-level > high school dropout interns that these companies, like most others on the > Internet these days, choose to employ as their first-level minions in their > "not a profit center" abuse handling departments. So, guess what? Surprise, > surprise! None of those clue-deprived flunkies have apparently yet managed > to figure out that there's a pattern here. Duh!. As a result, the scamming > and the spamming just go on and on and on, and the spammer-scammer just > keeps on getting fresh new IP addresess on both of these networks... and > fresh (and utterly free) new domain names from the equally careless company > called Freenom. > > So, you know, I really would appreciate it if someone could either put me > in touch with some actual sentient being at either OVH or DigitalOcean... > assuming that any such actually exist... or at the very least, try to find > one to whom clue may be passed about all this, because although these scam > spams were kind of humorous and novel at first, the novelty has now worn off > and they're really not all that funny anymore. > > Oh! And while we are on the subject, I'd also like to obtain a contact, > preferbly one which is also and likewise in possession of something roughly > approximating clue, at this place: > > AS200517 - Microsoft Deutschland MCIO GmbH > > The reason is that although MS Deutschland is most probably not the source > of any of the spams, they, or at least their 51.18.39.107 address, do appear > to be mixed up in all of this somehow: > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2Fraw%2FziVNCmZ8&data=02%7C01%7Cchkuhtz%40microsoft.com%7Cb1ca95b917fe4df0e3ee08d6abfe627f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885506393837741&sdata=dSVZUSMJeIZFaBgDygm7o7SmTibWdi8LwQBO6v4ftWo%3D&reserved=0 > > I dunno. Maybe Microsoft has managed to engineer a merger with the CIA (?) > If not, then maybe they would be so kind as to rat out this specific criminal > customer of their's to appropriate authorities. > > Don't get me wrong. I heartily applaud Microsoft's Digital Crimes Unit for > all of the admirable work they do, but you know the old saying... charity > begins at home. So my hope is that they will seek to get this low-life off > their network immediately, if not sooner, and then also seek to arrange > suitable long term accomodations for him in, say, Florence, Colorado, or, > if he/she/it has a higher than average level of tan, I hope that they will > make all necessary inquiries to find out if there are still any open bunks > available in Gitmo. > > > Regards, > rfg > > > P.S. In recent days, the popular media has fanned the flames of controversy, > as it is their habit to do, over the question of whether or not the various > social media companies could have somehow automagically spotted and deleted, > in real time, with some sort of yet-to-be-invented artificial intelligence > wizardry, the shooter videos from New Zealand. Of course, none of the TV > personalities who so cavalierly offer up their totally uninformed opinions > on this question have ever themselves gotten within a country mile of the > kinds of AI that could, perhaps in another decade or three, reliably > distinguish between a video of a msss shooting and a video of a particularly > raucous birthday party. It's a hard problem. > > In contrast to that hard problem, spotting the kind of trivial reverse DNS > pattern I've noted above is child's play and a no brainer. Why then, one > might reasonbly ask, have the combined abuse departments of both OVH and > DigitalOcean been either utterly unable or else utterly unwilling to do so? > Solving these kinds of trivial problems does not await the development of > some advanced new artificial intelligence. It just requires the judicious > application of a small bit of the non-artificial kind of intelligence. But > the industry, it seems, can't, or won't, even manage that. From rfg at tristatelogic.com Tue Mar 19 04:15:52 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 18 Mar 2019 21:15:52 -0700 Subject: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland) In-Reply-To: Message-ID: <76385.1552968952@segfault.tristatelogic.com> In message , Christian Kuhtz wrote: >we are asking Microsoft CDOC to investigate. Thank you. I am not at all sure who the mysterious "we" is intended to represent in that sentence. Perpahs it is just intended as the royal "we" as in "We are not amused." But I don't really care. I am greatful for any assitance from whatever quarter. >You can find a variety of ways to report issues at their website as well: >https://www.microsoft.com/en-us/msrc/cdoc I do not use web forms to report spam incidents, even those as widespread and blatantly criminal as in this instance. It's a matter of principal. Why should companies such as these hide behind impersonal web forms, even as their paying customers are allowed to incessantly badger and harass me, and millions of others, via the medium of email? Are they too good to get down in the muck of email with the rest of us mere peasants? It appears that they think so. And in any event, where is the evidence that filling in such a form would result in any actual action whatsoever? I don't see any. Quite the opposite. What I see, and what is exemplified by this specific case, is that EVEN IF people do actually jump through all of the ridiculous hoops, spammers like this are allowed to just go on and on an on. Where is the accountability, either personal or corporate? Who, specifically, should be blamed, or can be blamed, if the output of such a web form is improperly being diverted, on a routine basis, to /dev/null? If I'm going to invest (or waste?) my time in meticulously explaining to some large corporation, exactly how they are screwing up, and/or exactly who and where their bad customers are, then is it really asking too much to hope and expect that these same companies should, at the very least, make available some actual human being with whom I can interact, as necessary, in order to make sure that they understand what I have taken my time to research and explain to them? It's a serious question, and I am constantly befuddled by the apparent desire of large corporations... even and perhaps especially those in the "communications" business... to isolate themselves from any and all outside communications, even those which might be helpful and beneficial to the corporations themselves. In short, would it really kill your people in your Digital Crimes Unit to just simply publish their names and email addresses, you know, sort of like the rest of us mere mortals do? Furthermore, I am compelled to ask this additional question: Why should it even be incumbant upon an unpaid volunteer Internet firefighters, such as myself, to inform various multi-billion dollar corporations that they have a problem? Are they really incapable of keeping a close eye on their own networks and figuring this out for themselves? I confess that on some days it would seem so. I now have your email address, which I see is in the microsoft.com domain. And I thank you for that. I hope that you won't begrudge me too awfully much if, the next time such a situation arises, I make use of it. As I have bemoaned at length now, it is both rare and difficult to find an actual and/or accountable human at most of the large corporations that run so much of the modern Internet, and thus, I am greatful to have one more such contact in my back pocket, especially given that you have already demonstrated that you both care and will take at least some action in response to serious ongoing situations such as this one. I thank you, and only ask that you please stay healthy and do not seek employment elsewhere, at least until my own demise or until the sun goes nova, whichever comes first. Regards, rfg From chkuhtz at microsoft.com Tue Mar 19 06:08:05 2019 From: chkuhtz at microsoft.com (Christian Kuhtz) Date: Tue, 19 Mar 2019 06:08:05 +0000 Subject: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland) In-Reply-To: <76385.1552968952@segfault.tristatelogic.com> References: , <76385.1552968952@segfault.tristatelogic.com> Message-ID: Please use the links I provided to make sure it gets to the right people with the information they need as fast as possible. Thanks, Christian ________________________________ From: NANOG on behalf of Ronald F. Guilmette Sent: Monday, March 18, 2019 9:15:52 PM To: nanog at nanog.org Subject: Re: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland) In message , Christian Kuhtz wrote: >we are asking Microsoft CDOC to investigate. Thank you. I am not at all sure who the mysterious "we" is intended to represent in that sentence. Perpahs it is just intended as the royal "we" as in "We are not amused." But I don't really care. I am greatful for any assitance from whatever quarter. >You can find a variety of ways to report issues at their website as well: >https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.microsoft.com%2Fen-us%2Fmsrc%2Fcdoc&data=02%7C01%7Cchkuhtz%40microsoft.com%7Ca476f83d6507497b512908d6ac21bf7f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885658276641149&sdata=qg2YKsQ%2FjLtlgD7E4Gfjq0zJET%2Bvr07aCHynATFlbzU%3D&reserved=0 I do not use web forms to report spam incidents, even those as widespread and blatantly criminal as in this instance. It's a matter of principal. Why should companies such as these hide behind impersonal web forms, even as their paying customers are allowed to incessantly badger and harass me, and millions of others, via the medium of email? Are they too good to get down in the muck of email with the rest of us mere peasants? It appears that they think so. And in any event, where is the evidence that filling in such a form would result in any actual action whatsoever? I don't see any. Quite the opposite. What I see, and what is exemplified by this specific case, is that EVEN IF people do actually jump through all of the ridiculous hoops, spammers like this are allowed to just go on and on an on. Where is the accountability, either personal or corporate? Who, specifically, should be blamed, or can be blamed, if the output of such a web form is improperly being diverted, on a routine basis, to /dev/null? If I'm going to invest (or waste?) my time in meticulously explaining to some large corporation, exactly how they are screwing up, and/or exactly who and where their bad customers are, then is it really asking too much to hope and expect that these same companies should, at the very least, make available some actual human being with whom I can interact, as necessary, in order to make sure that they understand what I have taken my time to research and explain to them? It's a serious question, and I am constantly befuddled by the apparent desire of large corporations... even and perhaps especially those in the "communications" business... to isolate themselves from any and all outside communications, even those which might be helpful and beneficial to the corporations themselves. In short, would it really kill your people in your Digital Crimes Unit to just simply publish their names and email addresses, you know, sort of like the rest of us mere mortals do? Furthermore, I am compelled to ask this additional question: Why should it even be incumbant upon an unpaid volunteer Internet firefighters, such as myself, to inform various multi-billion dollar corporations that they have a problem? Are they really incapable of keeping a close eye on their own networks and figuring this out for themselves? I confess that on some days it would seem so. I now have your email address, which I see is in the microsoft.com domain. And I thank you for that. I hope that you won't begrudge me too awfully much if, the next time such a situation arises, I make use of it. As I have bemoaned at length now, it is both rare and difficult to find an actual and/or accountable human at most of the large corporations that run so much of the modern Internet, and thus, I am greatful to have one more such contact in my back pocket, especially given that you have already demonstrated that you both care and will take at least some action in response to serious ongoing situations such as this one. I thank you, and only ask that you please stay healthy and do not seek employment elsewhere, at least until my own demise or until the sun goes nova, whichever comes first. Regards, rfg -------------- next part -------------- An HTML attachment was scrubbed... URL: From rfg at tristatelogic.com Tue Mar 19 06:17:27 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 18 Mar 2019 23:17:27 -0700 Subject: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland) Message-ID: <76776.1552976247@segfault.tristatelogic.com> Nikolas Geyer wrote: >I have passed your email on to the relevant team within DO to have a look at. Thank you, but that wasn't what I requested, I asked for a contact there. (I know that this may be hard to understand, but it's like the difference between giving a man a fish, and teaching him how to fish. I'm sure that you would make a fine long term conduit between me and whatever mystery people you think you have made contact with at DigitalOcean, but really, it would be best if you would simply introduce me to those people directly. That way, if you die or go on vacation, incidents like these won't need to be put on hold until you get back and resume your role as our designated go-between.) >I'd like to thank you for your deriding commentary to bring attention >to this problem. No problem. My pleasure. >I am not sure it is the most effective way to try and engage the wider >industry on a public list, but each to their own. I am not sure that there is any other way that a lone outsider can or could engage either OVH or DigitalOcean in a way that would actually cause either company to take action on the issues I've reported on. Complaints from ordinary Internet end-lusers about this, which both companies must surely be drowing in by now, don't seem to be doing the job. In any case, I would be more than happy to have you tell me the "right way" to engage with any actual live human beings at either of these companies, especially if you also are able to identify one or more such receptive individuals by name and email address, which is what I was requesting in the first place. >Oh, and additionally, as an Australian citizen with many Aussie and >Kiwi colleagues working at DO of various religious persuasions; your >postscript relating this back to the recent terror attacks is abhorrent >and disgusting. You should be completely ashamed. It's pretty clear to me that you have rather dramatically misread my the aforementioned postscript to my earlier post, and that a fair and clear-eyed reading of that should be quite entirely inoffensive to all, with the possible exception of some few people who work in mass media and/or the "news" business, such as it currently is. In that postscript, I merely used a recent mass media controversy relating specifically and only to the social media -handling- of recent events to illustrate two blatant absurdities at opposite ends of a spectrum, neither of which itself has anything at all do do with those recent news events specifically, much less with the race, creed, color or gender of any of the people who have, most sadly and regretably, been caught up in those events. Please consider again the two polar opposite absurdities that I was actually attempting to call attention to. One the one hand, we have TV talking heads, with essentially no technical knowledge whatsoever, wondering aloud why social media tech companies cannot do what is clearly technically impossible, and even more absurdly, why they can't do it in real time no less. On the other hand, and in contrast to that absurdity, we have the present example of this spamming operation that appears to be well and truly ensconsed on the networks of both OVH and DigitalOcean, where even large multi-billion dollar Internet hosting companies seem utterly unable to spot even trivial and easily identifiable patterns of bad behavior, in and among their own respective customer bases, even though, as I have now illustrated, a single lone unpaid volunteer guy, sitting in his basement and in his sweaty underwear and a bathrobe -can- easily and quickly spot the problem, within just a couple of hours in fact, provided that he has access to a decent quality passive DNS service and an ample supply of electricity, margaritas and cigarettes. I'm only kidding, of course. I don't actually have a basement. Regards, rfg P.S. Your apparent misreading of my earlier postscript is entirely understandable and forgiveable in light of the rather unfortunate quip that I made just prior to that, about sending this specific miscreant to Guantanamo if his skin color was sufficiently dark. I seriously regret and apologize for that inartful phrasing, and ask every charitable person to believe me when I say that that was said entirely in jest (albeit a bad one), and that if anything, it was intended to be an expression of my own personal outrage about my own country's abundant inequity and unfairness when dealing with people of color, either within our so-called justice system or elsewhere. Our justice system should be color blind. Alas, there is much evidence that it falls far short of this goal at the present time. From list at satchell.net Tue Mar 19 06:39:31 2019 From: list at satchell.net (Stephen Satchell) Date: Mon, 18 Mar 2019 23:39:31 -0700 Subject: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland) In-Reply-To: <76776.1552976247@segfault.tristatelogic.com> References: <76776.1552976247@segfault.tristatelogic.com> Message-ID: <15509a92-5b61-6b69-c7c2-86726bfdc3f6@satchell.net> On 3/18/19 11:17 PM, Ronald F. Guilmette wrote: > I am not sure that there is any other way that a lone outsider can or > could engage either OVH or DigitalOcean in a way that would actually > cause either company to take action on the issues I've reported on. > Complaints from ordinary Internet end-lusers about this, which both > companies must surely be drowing in by now, don't seem to be doing the > job. > I have sent reports to DigitalOcean and Microsoft about the abuse reported to me that appears on my network. The only response I'm interested in is the end of said abuse. When abuse continues to be seen on a DigitalOcean allocation, that allocation goes into a file-and-forget ACL. I investigate further only when a customer reports a problem connecting with a DigitalOcean netblock. No such reports yet, by the way. I respond to abuse reports promptly and completely. I expect others to do so, just as promptly and completely. "Pretty please" is not in my netadmin vocabulary. From jeffm at iglou.com Tue Mar 19 13:23:34 2019 From: jeffm at iglou.com (Jeff McAdams) Date: Tue, 19 Mar 2019 09:23:34 -0400 (EDT) Subject: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland) In-Reply-To: <76776.1552976247@segfault.tristatelogic.com> References: <76776.1552976247@segfault.tristatelogic.com> Message-ID: <50414.162.155.102.254.1553001814.iglou@webmail.iglou.com> (Disclosure: I, too, work for DigitalOcean as the Manager of Network Engineering. Nikolas does not work for me, nor I for him.) On Tue, March 19, 2019 02:17, Ronald F. Guilmette wrote: > > Nikolas Geyer wrote: >> I have passed your email on to the relevant team within DO to have a >> look at. > Thank you, but that wasn't what I requested, I asked for a contact > there. Oh, is that how this works? I ask that you FedEx me a million dollars cash, in small bills. I await the arrival of said parcel. > In any case, I would be more than happy to have you tell me the "right > way" to engage with any actual live human beings at either of these > companies, especially if you also are able to identify one or more such > receptive individuals by name and email address, which is what I was > requesting in the first place. Would you really be happy with that? You derided another good-faith respondent to your screed with a rant about not being willing to fill out web forms to report abuse because it offends your sensibilities. Nikolas brought your report to the attention of the relevant group at DigitalOcean, we also have a link on the front page of https://www.digitalocean.com/ to Report Abuse that goes directly to the relevant group or groups responsible. We respond to reports (even rude ones) here on nanog and on other relevant industry mailing lists. We would prefer, but don't require, that you use the web form because that is integrated into the workflow of the groups that respond to those reports. If they choose to give you their individualized contact information, then they can do that. It is not my place, nor Nikolas', to give out individual contact information for our co-workers out to anyone who asks. That would be irresponsible and obnoxious for us to do that. >> Oh, and additionally, as an Australian citizen with many Aussie and >> Kiwi colleagues working at DO of various religious persuasions; your >> postscript relating this back to the recent terror attacks is abhorrent >> and disgusting. You should be completely ashamed. > It's pretty clear to me that you have rather dramatically misread my > the aforementioned postscript to my earlier post, and that a fair and > clear-eyed reading of that should be quite entirely inoffensive to all, > with the possible exception of some few people who work in mass media > and/or the "news" business, such as it currently is. As a caucasian American, born and raised in the US Midwest, I too was offended by your postscript. I would encourage you to take a step back, and consider your rhetorical tactics and whether they are beneficial to the community, or even to your own efforts. -- Jeff McAdams Manager of Network Engineering DigitalOcean From nuclearcat at nuclearcat.com Mon Mar 18 22:56:07 2019 From: nuclearcat at nuclearcat.com (Denys Fedoryshchenko) Date: Tue, 19 Mar 2019 00:56:07 +0200 Subject: Webzilla In-Reply-To: <74769.1552944276@segfault.tristatelogic.com> References: <74769.1552944276@segfault.tristatelogic.com> Message-ID: <1f4a3fe5d4a88273b5aa52d81bac6fda@nuclearcat.com> On 2019-03-18 23:24, Ronald F. Guilmette wrote: > In message > , > Eric Kuhnke wrote: > >> Looking at the AS adjacencies for Webzilla, what would prevent them >> from >> disconnecting all of their US/Western Euro based peers and transits, >> and >> remaining online behind a mixed selection of the largest Russian ASes? >> I do >> not think that any amount of well-researched papers and appeals to >> ethical >> ISPs on the NANOG mailing list will bring down those relationships. > > In the early years of the 20th century, Vladimir Lenin, leader of the > Bolshevik, revolution, famously quipped to his communist collegues that > "The capitalists will sell us the rope to hang them with." His > prescient > words have endured even the fall of the empire he founded because they > clarify a simple and fundamental truth -- in capitalist systems, short > term greed often overrides both rationality and simple common sense. > My hope is that it will not be so on this occasion, and that enligtened > long-term self interest will prevail, at least among those companies > that > are peering with any of Webzilla's ASNs. > Your speech is very reminiscent of this very Lenin, who climbed on an armored car and broadcasted speech to the "worker class" and told how bad are rich and how to restore justice. Only instead of rich people you have "those pesky Russians", and instead of the working class - "Western democracies". But let's not get into politics too deep. What prevents those who consider the activities of this hosting to be so harmful that they are worth blocking - to filter and add to the ACL lists of networks, where Webzilla AS is origin? Or make some easy to use lists, API, BGP feed, and those who decide to participate will null-route offenders, and you will see how many people will support you. If this list is compiled carefully, then I am sure it will interest many(including me). If it turns into a political tool or a tool for extortion ... then of course not. And generally speaking, all these speeches from an armored cars end with a witch hunt, and almost always entire nations or categories of people are appointed as witches, depending on the trends. Who will be next? Cloudflare? Their attempt to maintain neutrality annoys many. Amazon? They react very slowly to abuse. OVH? It seems they do not care about abuse at all. Or maybe it will go into fashion to make the guilty - legal arms sellers? Or internet-stores who sell alcohol? Just create a cause for a depeering, and a lot of people with their special views will demand a depeering at every opportunity. P.S. North Korea, as far as I know, is very limited in connectivity choice, and this does not prevent them from creating a bunch of problems. As Max Tulyev said, and they are good example, just sprayed through countless proxies. From beecher at beecher.cc Tue Mar 19 14:01:03 2019 From: beecher at beecher.cc (Tom Beecher) Date: Tue, 19 Mar 2019 10:01:03 -0400 Subject: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland) In-Reply-To: <75392.1552953758@segfault.tristatelogic.com> References: <75392.1552953758@segfault.tristatelogic.com> Message-ID: This entire thread could easily have been simply : "Hey all! I'm having some challenges reaching a live person in the abuse groups for X, Y, and Z. Can anyone help with a contact, or if anyone from those companies sees this, can you contact me off-list?" Calling everyone an idiot in the midst of Endless Pontification isn't really a recipe for success. On Mon, Mar 18, 2019 at 8:04 PM Ronald F. Guilmette wrote: > > OVH, DigitalOcean, and Microsoft... > > Is there anybody awake and conscious at any of these places? I mean > anybody who someone such as myself... just part of the Great Unwashed > Masses... could actually speak to about a real and ongoing problem? > > Maybe most of you here will think that this is just a trivial problem, and > one that's not even worth mentioning on NANOG. So be it. Make up you own > minds. Here is the problem... > > For some time now, there has been an ongoing campaign of bitcoin > extortion spamming going on which originates primarily or perhaps > exclusively from IPv4 addresses owned by OVH and DigitalOcean. > These scam spams have now been publicised in multiple places: > > https://myonlinesecurity.co.uk/fake-cia-sextortion-scam/ > > Yea, that's just one place, I know, but there's also no shortage of people > tweeting about this crap also, in multiple languages even! > > https://twitter.com/SpamAuditor/status/1107365604636278784 > https://twitter.com/dvk01uk/status/1107510553621266433 > https://twitter.com/bortzmeyer/status/1107737034049900544 > https://twitter.com/ariestess69/status/1107468838596038656 > https://twitter.com/bernhard_mahr/status/1107513313020297216 > https://twitter.com/jzmurdock/status/1107679858945974272 > https://twitter.com/gamamb/status/1107384186548207617 > https://twitter.com/davidgsIoT/status/1107725201331097606 > https://twitter.com/cybers_guards/status/1107675396076560384 > https://twitter.com/ThatHostingCo/status/1107588660831105024 > https://twitter.com/fladna9/status/1107554090765242368 > https://twitter.com/JUSTADACHI/status/1107549777607184384 > https://twitter.com/okhin/status/1107627379650908160 > https://twitter.com/Purple_Wyrm/status/1107454618705887232 > https://twitter.com/LadyOFyre/status/1107349022220550144 > https://twitter.com/laurelvail/status/1107345980062523392 > https://twitter.com/Alex__Rubio/status/1107595560440217600 > > The thing of it is that ALL of this crap... al of these scam spams... are > quite obviously originating out of the networks of OVH and DigitalOcean. > And it's not even all that hard to figure out where from, exactly and > specifically. I generated the following survey, on the fly, last night, > based on a simple reverse DNS scan of the evidently relevant addrdess > ranges: > > https://pastebin.com/raw/WtM0Y5yC > > As anyone who isn't as blind as a bat can easily see, there's a bit of a > pattern here. All of the spam source IPs are on just two ASNs: > > AS16276 - OVH SAS > AS4061 - DigitalOcean, LLC > > It's equally clear that there have already been numerous reports about this > ongoing and blatantly criminal activity that have been sent to the > low-level > high school dropout interns that these companies, like most others on the > Internet these days, choose to employ as their first-level minions in their > "not a profit center" abuse handling departments. So, guess what? > Surprise, > surprise! None of those clue-deprived flunkies have apparently yet managed > to figure out that there's a pattern here. Duh!. As a result, the > scamming > and the spamming just go on and on and on, and the spammer-scammer just > keeps on getting fresh new IP addresess on both of these networks... and > fresh (and utterly free) new domain names from the equally careless company > called Freenom. > > So, you know, I really would appreciate it if someone could either put me > in touch with some actual sentient being at either OVH or DigitalOcean... > assuming that any such actually exist... or at the very least, try to find > one to whom clue may be passed about all this, because although these scam > spams were kind of humorous and novel at first, the novelty has now worn > off > and they're really not all that funny anymore. > > Oh! And while we are on the subject, I'd also like to obtain a contact, > preferbly one which is also and likewise in possession of something roughly > approximating clue, at this place: > > AS200517 - Microsoft Deutschland MCIO GmbH > > The reason is that although MS Deutschland is most probably not the source > of any of the spams, they, or at least their 51.18.39.107 address, do > appear > to be mixed up in all of this somehow: > > https://pastebin.com/raw/ziVNCmZ8 > > I dunno. Maybe Microsoft has managed to engineer a merger with the CIA (?) > If not, then maybe they would be so kind as to rat out this specific > criminal > customer of their's to appropriate authorities. > > Don't get me wrong. I heartily applaud Microsoft's Digital Crimes Unit for > all of the admirable work they do, but you know the old saying... charity > begins at home. So my hope is that they will seek to get this low-life off > their network immediately, if not sooner, and then also seek to arrange > suitable long term accomodations for him in, say, Florence, Colorado, or, > if he/she/it has a higher than average level of tan, I hope that they will > make all necessary inquiries to find out if there are still any open bunks > available in Gitmo. > > > Regards, > rfg > > > P.S. In recent days, the popular media has fanned the flames of > controversy, > as it is their habit to do, over the question of whether or not the various > social media companies could have somehow automagically spotted and > deleted, > in real time, with some sort of yet-to-be-invented artificial intelligence > wizardry, the shooter videos from New Zealand. Of course, none of the TV > personalities who so cavalierly offer up their totally uninformed opinions > on this question have ever themselves gotten within a country mile of the > kinds of AI that could, perhaps in another decade or three, reliably > distinguish between a video of a msss shooting and a video of a > particularly > raucous birthday party. It's a hard problem. > > In contrast to that hard problem, spotting the kind of trivial reverse DNS > pattern I've noted above is child's play and a no brainer. Why then, one > might reasonbly ask, have the combined abuse departments of both OVH and > DigitalOcean been either utterly unable or else utterly unwilling to do so? > Solving these kinds of trivial problems does not await the development of > some advanced new artificial intelligence. It just requires the judicious > application of a small bit of the non-artificial kind of intelligence. But > the industry, it seems, can't, or won't, even manage that. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsk at gsp.org Tue Mar 19 14:49:52 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 19 Mar 2019 10:49:52 -0400 Subject: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland) In-Reply-To: <50414.162.155.102.254.1553001814.iglou@webmail.iglou.com> References: <76776.1552976247@segfault.tristatelogic.com> <50414.162.155.102.254.1553001814.iglou@webmail.iglou.com> Message-ID: <20190319144952.GA14021@gsp.org> On Tue, Mar 19, 2019 at 09:23:34AM -0400, Jeff McAdams wrote: > We would prefer, but don't require, that you use the web form because that > is integrated into the workflow of the groups that respond to those > reports. Why isn't abuse@ integrated into the workflow? It darn well should be, (a) given that RFC 2142 has been "on the books" for 22 years and (b) given that methods for handling incoming abuse (or bug, or outage, or other) reports via email to role accounts are numerous and reliable. To be clear: if you want to offer a web form in addition to an abuse@ address (or a security@ address, or a postmaster@ address) that's fine. But web forms are a markedly inferior means of communication and are clearly not a substitute for well-known/standardized role addresses that route to the appropriate people/processes. ---rsk From john-nanog at peachfamily.net Tue Mar 19 14:56:29 2019 From: john-nanog at peachfamily.net (John Peach) Date: Tue, 19 Mar 2019 10:56:29 -0400 Subject: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland) In-Reply-To: <20190319144952.GA14021@gsp.org> References: <76776.1552976247@segfault.tristatelogic.com> <50414.162.155.102.254.1553001814.iglou@webmail.iglou.com> <20190319144952.GA14021@gsp.org> Message-ID: On 3/19/19 10:49 AM, Rich Kulawiec wrote: > On Tue, Mar 19, 2019 at 09:23:34AM -0400, Jeff McAdams wrote: >> We would prefer, but don't require, that you use the web form because that >> is integrated into the workflow of the groups that respond to those >> reports. > > Why isn't abuse@ integrated into the workflow? It darn well should be, > (a) given that RFC 2142 has been "on the books" for 22 years and > (b) given that methods for handling incoming abuse (or bug, or outage, > or other) reports via email to role accounts are numerous and reliable. > > To be clear: if you want to offer a web form in addition to an abuse@ > address (or a security@ address, or a postmaster@ address) that's fine. > But web forms are a markedly inferior means of communication and are > clearly not a substitute for well-known/standardized role addresses that > route to the appropriate people/processes. > > ---rsk > +1 -- John PGP Public Key: 412934AC From ray at orsiniit.com Tue Mar 19 15:29:49 2019 From: ray at orsiniit.com (Ray Orsini) Date: Tue, 19 Mar 2019 15:29:49 +0000 Subject: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland) In-Reply-To: References: <75392.1552953758@segfault.tristatelogic.com> Message-ID: I originally held back on a similar response. But I had the exact same opinion. It works against your argument when you start off with insults and condescension. Personally, I would not refer anyone to someone making a post like this. Regards, Ray Orsini – CEO Orsini IT, LLC – Technology Consultants VOICE –DATA – BANDWIDTH – SECURITY – SUPPORT P: 305.967.6756 x1009 E: ray at orsiniit.com TF: 844.OIT.VOIP http://www.orsiniit.com | Schedule a Call From: NANOG On Behalf Of Tom Beecher Sent: Tuesday, March 19, 2019 10:01 AM To: Ronald F. Guilmette Cc: NANOG Subject: Re: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland) This entire thread could easily have been simply : "Hey all! I'm having some challenges reaching a live person in the abuse groups for X, Y, and Z. Can anyone help with a contact, or if anyone from those companies sees this, can you contact me off-list?" Calling everyone an idiot in the midst of Endless Pontification isn't really a recipe for success. On Mon, Mar 18, 2019 at 8:04 PM Ronald F. Guilmette > wrote: OVH, DigitalOcean, and Microsoft... Is there anybody awake and conscious at any of these places? I mean anybody who someone such as myself... just part of the Great Unwashed Masses... could actually speak to about a real and ongoing problem? Maybe most of you here will think that this is just a trivial problem, and one that's not even worth mentioning on NANOG. So be it. Make up you own minds. Here is the problem... For some time now, there has been an ongoing campaign of bitcoin extortion spamming going on which originates primarily or perhaps exclusively from IPv4 addresses owned by OVH and DigitalOcean. These scam spams have now been publicised in multiple places: https://myonlinesecurity.co.uk/fake-cia-sextortion-scam/ Yea, that's just one place, I know, but there's also no shortage of people tweeting about this crap also, in multiple languages even! https://twitter.com/SpamAuditor/status/1107365604636278784 https://twitter.com/dvk01uk/status/1107510553621266433 https://twitter.com/bortzmeyer/status/1107737034049900544 https://twitter.com/ariestess69/status/1107468838596038656 https://twitter.com/bernhard_mahr/status/1107513313020297216 https://twitter.com/jzmurdock/status/1107679858945974272 https://twitter.com/gamamb/status/1107384186548207617 https://twitter.com/davidgsIoT/status/1107725201331097606 https://twitter.com/cybers_guards/status/1107675396076560384 https://twitter.com/ThatHostingCo/status/1107588660831105024 https://twitter.com/fladna9/status/1107554090765242368 https://twitter.com/JUSTADACHI/status/1107549777607184384 https://twitter.com/okhin/status/1107627379650908160 https://twitter.com/Purple_Wyrm/status/1107454618705887232 https://twitter.com/LadyOFyre/status/1107349022220550144 https://twitter.com/laurelvail/status/1107345980062523392 https://twitter.com/Alex__Rubio/status/1107595560440217600 The thing of it is that ALL of this crap... al of these scam spams... are quite obviously originating out of the networks of OVH and DigitalOcean. And it's not even all that hard to figure out where from, exactly and specifically. I generated the following survey, on the fly, last night, based on a simple reverse DNS scan of the evidently relevant addrdess ranges: https://pastebin.com/raw/WtM0Y5yC As anyone who isn't as blind as a bat can easily see, there's a bit of a pattern here. All of the spam source IPs are on just two ASNs: AS16276 - OVH SAS AS4061 - DigitalOcean, LLC It's equally clear that there have already been numerous reports about this ongoing and blatantly criminal activity that have been sent to the low-level high school dropout interns that these companies, like most others on the Internet these days, choose to employ as their first-level minions in their "not a profit center" abuse handling departments. So, guess what? Surprise, surprise! None of those clue-deprived flunkies have apparently yet managed to figure out that there's a pattern here. Duh!. As a result, the scamming and the spamming just go on and on and on, and the spammer-scammer just keeps on getting fresh new IP addresess on both of these networks... and fresh (and utterly free) new domain names from the equally careless company called Freenom. So, you know, I really would appreciate it if someone could either put me in touch with some actual sentient being at either OVH or DigitalOcean... assuming that any such actually exist... or at the very least, try to find one to whom clue may be passed about all this, because although these scam spams were kind of humorous and novel at first, the novelty has now worn off and they're really not all that funny anymore. Oh! And while we are on the subject, I'd also like to obtain a contact, preferbly one which is also and likewise in possession of something roughly approximating clue, at this place: AS200517 - Microsoft Deutschland MCIO GmbH The reason is that although MS Deutschland is most probably not the source of any of the spams, they, or at least their 51.18.39.107 address, do appear to be mixed up in all of this somehow: https://pastebin.com/raw/ziVNCmZ8 I dunno. Maybe Microsoft has managed to engineer a merger with the CIA (?) If not, then maybe they would be so kind as to rat out this specific criminal customer of their's to appropriate authorities. Don't get me wrong. I heartily applaud Microsoft's Digital Crimes Unit for all of the admirable work they do, but you know the old saying... charity begins at home. So my hope is that they will seek to get this low-life off their network immediately, if not sooner, and then also seek to arrange suitable long term accomodations for him in, say, Florence, Colorado, or, if he/she/it has a higher than average level of tan, I hope that they will make all necessary inquiries to find out if there are still any open bunks available in Gitmo. Regards, rfg P.S. In recent days, the popular media has fanned the flames of controversy, as it is their habit to do, over the question of whether or not the various social media companies could have somehow automagically spotted and deleted, in real time, with some sort of yet-to-be-invented artificial intelligence wizardry, the shooter videos from New Zealand. Of course, none of the TV personalities who so cavalierly offer up their totally uninformed opinions on this question have ever themselves gotten within a country mile of the kinds of AI that could, perhaps in another decade or three, reliably distinguish between a video of a msss shooting and a video of a particularly raucous birthday party. It's a hard problem. In contrast to that hard problem, spotting the kind of trivial reverse DNS pattern I've noted above is child's play and a no brainer. Why then, one might reasonbly ask, have the combined abuse departments of both OVH and DigitalOcean been either utterly unable or else utterly unwilling to do so? Solving these kinds of trivial problems does not await the development of some advanced new artificial intelligence. It just requires the judicious application of a small bit of the non-artificial kind of intelligence. But the industry, it seems, can't, or won't, even manage that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nik at neko.id.au Tue Mar 19 15:30:58 2019 From: nik at neko.id.au (Nikolas Geyer) Date: Tue, 19 Mar 2019 15:30:58 +0000 Subject: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland) In-Reply-To: <20190319144952.GA14021@gsp.org> References: <76776.1552976247@segfault.tristatelogic.com> <50414.162.155.102.254.1553001814.iglou@webmail.iglou.com>, <20190319144952.GA14021@gsp.org> Message-ID: Just to clarify, we are RFC 2142 section 4 compliant. I mention section 4 specifically as that is directly within my realm of control, the remaining sections I will check. Both methods, web form submission and abuse@ are integrated ultimately into the same workflow. Being transparent, as things currently stand, the abuse@ submission method requires an additional element of human verification before ingestion to the workflow as it is open to abuse itself. For example, an annoyed former user who has been removed from the platform for abusive activities trying to subscribe it (and other RFC 2142 addresses) to thousands of pornographic mailing lists, or attempting to slam it with tens of thousands of junk emails. We do take platform abuse seriously but, like any other company, there is always room for improvement. We have a dedicated team who’s 24/7 job function is to continually improve our systems and processes surrounding abuse, from trying to stem it at top of funnel, to mitigating on-going issues with as low MTTR as possible, to responding to abuse@ (and web form) submissions. tl;dr - both submission methods are available Sent from my iPhone > On Mar 19, 2019, at 10:52 AM, Rich Kulawiec wrote: > >> On Tue, Mar 19, 2019 at 09:23:34AM -0400, Jeff McAdams wrote: >> We would prefer, but don't require, that you use the web form because that >> is integrated into the workflow of the groups that respond to those >> reports. > > Why isn't abuse@ integrated into the workflow? It darn well should be, > (a) given that RFC 2142 has been "on the books" for 22 years and > (b) given that methods for handling incoming abuse (or bug, or outage, > or other) reports via email to role accounts are numerous and reliable. > > To be clear: if you want to offer a web form in addition to an abuse@ > address (or a security@ address, or a postmaster@ address) that's fine. > But web forms are a markedly inferior means of communication and are > clearly not a substitute for well-known/standardized role addresses that > route to the appropriate people/processes. > > ---rsk > From niels=nanog at bakker.net Tue Mar 19 15:50:41 2019 From: niels=nanog at bakker.net (niels=nanog at bakker.net) Date: Tue, 19 Mar 2019 16:50:41 +0100 Subject: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland) In-Reply-To: <76776.1552976247@segfault.tristatelogic.com> References: <76776.1552976247@segfault.tristatelogic.com> Message-ID: <20190319155041.GA88473@jima.tpb.net> Kind of bad netiquette to repost a private email to the list -- Niels. From jbarrett at appiaservices.com Tue Mar 19 14:15:53 2019 From: jbarrett at appiaservices.com (Jack Barrett (Appia)) Date: Tue, 19 Mar 2019 14:15:53 +0000 Subject: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland) In-Reply-To: References: <75392.1552953758@segfault.tristatelogic.com> Message-ID: I agree it could have definitely been simplified, but I also found the “endless pontification” a little amusing this morning. What I do not find amusing is the social outrage and identity politics that has made it’s way into the sacred NANOG mailing list. From: NANOG On Behalf Of Tom Beecher Sent: Tuesday, March 19, 2019 9:01 AM To: Ronald F. Guilmette Cc: NANOG Subject: Re: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland) This entire thread could easily have been simply : "Hey all! I'm having some challenges reaching a live person in the abuse groups for X, Y, and Z. Can anyone help with a contact, or if anyone from those companies sees this, can you contact me off-list?" Calling everyone an idiot in the midst of Endless Pontification isn't really a recipe for success. On Mon, Mar 18, 2019 at 8:04 PM Ronald F. Guilmette > wrote: OVH, DigitalOcean, and Microsoft... Is there anybody awake and conscious at any of these places? I mean anybody who someone such as myself... just part of the Great Unwashed Masses... could actually speak to about a real and ongoing problem? Maybe most of you here will think that this is just a trivial problem, and one that's not even worth mentioning on NANOG. So be it. Make up you own minds. Here is the problem... For some time now, there has been an ongoing campaign of bitcoin extortion spamming going on which originates primarily or perhaps exclusively from IPv4 addresses owned by OVH and DigitalOcean. These scam spams have now been publicised in multiple places: https://myonlinesecurity.co.uk/fake-cia-sextortion-scam/ Yea, that's just one place, I know, but there's also no shortage of people tweeting about this crap also, in multiple languages even! https://twitter.com/SpamAuditor/status/1107365604636278784 https://twitter.com/dvk01uk/status/1107510553621266433 https://twitter.com/bortzmeyer/status/1107737034049900544 https://twitter.com/ariestess69/status/1107468838596038656 https://twitter.com/bernhard_mahr/status/1107513313020297216 https://twitter.com/jzmurdock/status/1107679858945974272 https://twitter.com/gamamb/status/1107384186548207617 https://twitter.com/davidgsIoT/status/1107725201331097606 https://twitter.com/cybers_guards/status/1107675396076560384 https://twitter.com/ThatHostingCo/status/1107588660831105024 https://twitter.com/fladna9/status/1107554090765242368 https://twitter.com/JUSTADACHI/status/1107549777607184384 https://twitter.com/okhin/status/1107627379650908160 https://twitter.com/Purple_Wyrm/status/1107454618705887232 https://twitter.com/LadyOFyre/status/1107349022220550144 https://twitter.com/laurelvail/status/1107345980062523392 https://twitter.com/Alex__Rubio/status/1107595560440217600 The thing of it is that ALL of this crap... al of these scam spams... are quite obviously originating out of the networks of OVH and DigitalOcean. And it's not even all that hard to figure out where from, exactly and specifically. I generated the following survey, on the fly, last night, based on a simple reverse DNS scan of the evidently relevant addrdess ranges: https://pastebin.com/raw/WtM0Y5yC As anyone who isn't as blind as a bat can easily see, there's a bit of a pattern here. All of the spam source IPs are on just two ASNs: AS16276 - OVH SAS AS4061 - DigitalOcean, LLC It's equally clear that there have already been numerous reports about this ongoing and blatantly criminal activity that have been sent to the low-level high school dropout interns that these companies, like most others on the Internet these days, choose to employ as their first-level minions in their "not a profit center" abuse handling departments. So, guess what? Surprise, surprise! None of those clue-deprived flunkies have apparently yet managed to figure out that there's a pattern here. Duh!. As a result, the scamming and the spamming just go on and on and on, and the spammer-scammer just keeps on getting fresh new IP addresess on both of these networks... and fresh (and utterly free) new domain names from the equally careless company called Freenom. So, you know, I really would appreciate it if someone could either put me in touch with some actual sentient being at either OVH or DigitalOcean... assuming that any such actually exist... or at the very least, try to find one to whom clue may be passed about all this, because although these scam spams were kind of humorous and novel at first, the novelty has now worn off and they're really not all that funny anymore. Oh! And while we are on the subject, I'd also like to obtain a contact, preferbly one which is also and likewise in possession of something roughly approximating clue, at this place: AS200517 - Microsoft Deutschland MCIO GmbH The reason is that although MS Deutschland is most probably not the source of any of the spams, they, or at least their 51.18.39.107 address, do appear to be mixed up in all of this somehow: https://pastebin.com/raw/ziVNCmZ8 I dunno. Maybe Microsoft has managed to engineer a merger with the CIA (?) If not, then maybe they would be so kind as to rat out this specific criminal customer of their's to appropriate authorities. Don't get me wrong. I heartily applaud Microsoft's Digital Crimes Unit for all of the admirable work they do, but you know the old saying... charity begins at home. So my hope is that they will seek to get this low-life off their network immediately, if not sooner, and then also seek to arrange suitable long term accomodations for him in, say, Florence, Colorado, or, if he/she/it has a higher than average level of tan, I hope that they will make all necessary inquiries to find out if there are still any open bunks available in Gitmo. Regards, rfg P.S. In recent days, the popular media has fanned the flames of controversy, as it is their habit to do, over the question of whether or not the various social media companies could have somehow automagically spotted and deleted, in real time, with some sort of yet-to-be-invented artificial intelligence wizardry, the shooter videos from New Zealand. Of course, none of the TV personalities who so cavalierly offer up their totally uninformed opinions on this question have ever themselves gotten within a country mile of the kinds of AI that could, perhaps in another decade or three, reliably distinguish between a video of a msss shooting and a video of a particularly raucous birthday party. It's a hard problem. In contrast to that hard problem, spotting the kind of trivial reverse DNS pattern I've noted above is child's play and a no brainer. Why then, one might reasonbly ask, have the combined abuse departments of both OVH and DigitalOcean been either utterly unable or else utterly unwilling to do so? Solving these kinds of trivial problems does not await the development of some advanced new artificial intelligence. It just requires the judicious application of a small bit of the non-artificial kind of intelligence. But the industry, it seems, can't, or won't, even manage that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.kuhnke at gmail.com Tue Mar 19 16:17:23 2019 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Tue, 19 Mar 2019 09:17:23 -0700 Subject: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland) In-Reply-To: <20190319144952.GA14021@gsp.org> References: <76776.1552976247@segfault.tristatelogic.com> <50414.162.155.102.254.1553001814.iglou@webmail.iglou.com> <20190319144952.GA14021@gsp.org> Message-ID: Absolutely unrelated to Ronald's original post, but it's ironic that the abuse@ address is itself heavily "abused", by commercial copyright enforcement companies which think it's a catch-all address for things which are not operationally related to the health of a network (BGP hijacks, DDoS, spam email traffic, botnet/virus/worm/trojan traffic command and control and such). Despite the presence of a registered DMCA agent address[1][2] for an ASN, many companies continue to flood abuse@ with copyright notices. Ask any ISP that operates in the English language Internet but is not physically located in the USA (NZ, AU, CA, etc) how many USA-specific legal threats their abuse inbox receives. Usually for something like a residential customer torrenting a TV show. 1: https://www.copyright.gov/dmca-directory/ 2: https://www.copyright.gov/rulemaking/onlinesp/NPR/faq.html On Tue, Mar 19, 2019 at 7:50 AM Rich Kulawiec wrote: > On Tue, Mar 19, 2019 at 09:23:34AM -0400, Jeff McAdams wrote: > > We would prefer, but don't require, that you use the web form because > that > > is integrated into the workflow of the groups that respond to those > > reports. > > Why isn't abuse@ integrated into the workflow? It darn well should be, > (a) given that RFC 2142 has been "on the books" for 22 years and > (b) given that methods for handling incoming abuse (or bug, or outage, > or other) reports via email to role accounts are numerous and reliable. > > To be clear: if you want to offer a web form in addition to an abuse@ > address (or a security@ address, or a postmaster@ address) that's fine. > But web forms are a markedly inferior means of communication and are > clearly not a substitute for well-known/standardized role addresses that > route to the appropriate people/processes. > > ---rsk > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From niels=nanog at bakker.net Tue Mar 19 16:34:28 2019 From: niels=nanog at bakker.net (niels=nanog at bakker.net) Date: Tue, 19 Mar 2019 17:34:28 +0100 Subject: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland) In-Reply-To: <20190319155041.GA88473@jima.tpb.net> References: <76776.1552976247@segfault.tristatelogic.com> <20190319155041.GA88473@jima.tpb.net> Message-ID: <20190319163428.GB88473@jima.tpb.net> Apologies, it was in reply to a list mail. Just bad threading. * niels=nanog at bakker.net (niels=nanog at bakker.net) [Tue 19 Mar 2019, 16:51 CET]: >Kind of bad netiquette to repost a private email to the list > From kuenzler at init7.net Tue Mar 19 17:12:54 2019 From: kuenzler at init7.net (Fredy Kuenzler) Date: Tue, 19 Mar 2019 18:12:54 +0100 Subject: well-known Anycast prefixes Message-ID: <98053e99-687d-bc4c-cbd8-956b70a339ce@init7.net> I wonder whether anyone has ever compiled a list of well-known Anycast prefixes. Such as 1.1.1.0/24 8.8.8.0/24 9.9.9.0/24 ... Might be useful for a routing policy such as "always route hot-potato". PS. this mail is not intended to start a flame war of hot vs. cold potato routing. -- Fredy Kuenzler Init7 (Switzerland) Ltd. AS13030 Technoparkstrasse 5 CH-8406 Winterthur Twitter: @init7 / @kuenzler http://www.init7.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From woody at pch.net Tue Mar 19 17:39:30 2019 From: woody at pch.net (Bill Woodcock) Date: Tue, 19 Mar 2019 10:39:30 -0700 Subject: well-known Anycast prefixes In-Reply-To: <98053e99-687d-bc4c-cbd8-956b70a339ce@init7.net> References: <98053e99-687d-bc4c-cbd8-956b70a339ce@init7.net> Message-ID: <313D8869-90FF-423C-B444-B95E225A2E37@pch.net> > On Mar 19, 2019, at 10:12 AM, Fredy Kuenzler wrote: > > I wonder whether anyone has ever compiled a list of well-known Anycast > prefixes. I don’t know of one. It seems like a good idea. BGP-multi-hop might be a reasonable way to collect them. If others agree that it’s a good idea, and it’s not stepping on anyone’s toes, PCH would be happy to host/coordinate. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From david at xtom.com Tue Mar 19 17:43:19 2019 From: david at xtom.com (David Guo) Date: Tue, 19 Mar 2019 17:43:19 +0000 Subject: well-known Anycast prefixes In-Reply-To: <98053e99-687d-bc4c-cbd8-956b70a339ce@init7.net> References: <98053e99-687d-bc4c-cbd8-956b70a339ce@init7.net> Message-ID: Hi Fredy, Our anycast prefixes for DNS resolver 185.222.222.0/24 2a09::/48 You can add them if someone will maintain a list. Regards, David -----Original Message----- From: NANOG On Behalf Of Fredy Kuenzler Sent: Wednesday, March 20, 2019 1:13 AM To: nanog at nanog.org Subject: well-known Anycast prefixes I wonder whether anyone has ever compiled a list of well-known Anycast prefixes. Such as 1.1.1.0/24 8.8.8.0/24 9.9.9.0/24 ... Might be useful for a routing policy such as "always route hot-potato". PS. this mail is not intended to start a flame war of hot vs. cold potato routing. -- Fredy Kuenzler Init7 (Switzerland) Ltd. AS13030 Technoparkstrasse 5 CH-8406 Winterthur Twitter: @init7 / @kuenzler http://www.init7.net/ From kuenzler at init7.net Tue Mar 19 17:46:24 2019 From: kuenzler at init7.net (Fredy Kuenzler) Date: Tue, 19 Mar 2019 18:46:24 +0100 Subject: well-known Anycast prefixes In-Reply-To: <313D8869-90FF-423C-B444-B95E225A2E37@pch.net> References: <98053e99-687d-bc4c-cbd8-956b70a339ce@init7.net> <313D8869-90FF-423C-B444-B95E225A2E37@pch.net> Message-ID: Am 19.03.19 um 18:39 schrieb Bill Woodcock: >> On Mar 19, 2019, at 10:12 AM, Fredy Kuenzler >> wrote: I wonder whether anyone has ever compiled a list of >> well-known Anycast prefixes. > > I don’t know of one. > > It seems like a good idea. > > BGP-multi-hop might be a reasonable way to collect them. > > If others agree that it’s a good idea, and it’s not stepping on > anyone’s toes, PCH would be happy to host/coordinate. Thanks for the effort, much appreciated. Am 19.03.19 um 18:40 schrieb Joe Provo: > I think one would want that internal and no rely upon someone else > maintaining it. You might check if Oracle followed up on the > Renesys/Dyn work documented: > https://dyn.com/wp-content/uploads/2014/07/NANOG59_Anycast.pdf > > ...where there were ~600 anycast v4 prefixes at the time. That's a lot %-] Maybe a well-known community (similar to RFC7999) could be defined and every Anycast operator could tag his prefixes? That's likely a better idea than manually maintain some list somewhere. -- Fredy Kuenzler Init7 (Switzerland) Ltd. AS13030 Technoparkstrasse 5 CH-8406 Winterthur Skype: flyingpotato Phone: +41 44 315 4400 Fax: +41 44 315 4401 Twitter: @init7 / @kuenzler http://www.init7.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From aveline at misaka.io Tue Mar 19 17:56:08 2019 From: aveline at misaka.io (Siyuan Miao) Date: Wed, 20 Mar 2019 01:56:08 +0800 Subject: well-known Anycast prefixes In-Reply-To: References: <98053e99-687d-bc4c-cbd8-956b70a339ce@init7.net> <313D8869-90FF-423C-B444-B95E225A2E37@pch.net> Message-ID: A Well-known BGP community will be better. You'll need to rewrite next hop or do something similar if AnyCast prefixes are learnt from a multi hop BGP feed, and it made the configuration more complicated and difficult to debug. On Wed, Mar 20, 2019, 01:48 Fredy Kuenzler wrote: > Am 19.03.19 um 18:39 schrieb Bill Woodcock: > >> On Mar 19, 2019, at 10:12 AM, Fredy Kuenzler > >> wrote: I wonder whether anyone has ever compiled a list of > >> well-known Anycast prefixes. > > > > I don’t know of one. > > > > It seems like a good idea. > > > > BGP-multi-hop might be a reasonable way to collect them. > > > > If others agree that it’s a good idea, and it’s not stepping on > > anyone’s toes, PCH would be happy to host/coordinate. > > Thanks for the effort, much appreciated. > > Am 19.03.19 um 18:40 schrieb Joe Provo: > > I think one would want that internal and no rely upon someone else > > maintaining it. You might check if Oracle followed up on the > > Renesys/Dyn work documented: > > https://dyn.com/wp-content/uploads/2014/07/NANOG59_Anycast.pdf > > > > ...where there were ~600 anycast v4 prefixes at the time. > > That's a lot %-] > > Maybe a well-known community (similar to RFC7999) could be defined and > every Anycast operator could tag his prefixes? That's likely a better > idea than manually maintain some list somewhere. > > -- > Fredy Kuenzler > > Init7 (Switzerland) Ltd. > AS13030 > Technoparkstrasse 5 > CH-8406 Winterthur > Skype: flyingpotato > Phone: +41 44 315 4400 > Fax: +41 44 315 4401 > Twitter: @init7 / @kuenzler > http://www.init7.net/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damian at google.com Tue Mar 19 18:52:19 2019 From: damian at google.com (Damian Menscher) Date: Tue, 19 Mar 2019 11:52:19 -0700 Subject: well-known Anycast prefixes In-Reply-To: References: <98053e99-687d-bc4c-cbd8-956b70a339ce@init7.net> <313D8869-90FF-423C-B444-B95E225A2E37@pch.net> Message-ID: Careful thought should be given into whether the BGP community means "this is an anycast prefix" vs "please hot-potato to this prefix". Latency-sensitive applications may prefer hot-potato to their network even if it's not technically an anycast range, as their private backbone may be faster (less congested) than the public internet. Damian On Tue, Mar 19, 2019 at 10:57 AM Siyuan Miao wrote: > > A Well-known BGP community will be better. > > You'll need to rewrite next hop or do something similar if AnyCast > prefixes are learnt from a multi hop BGP feed, and it made the > configuration more complicated and difficult to debug. > > On Wed, Mar 20, 2019, 01:48 Fredy Kuenzler wrote: > >> Am 19.03.19 um 18:39 schrieb Bill Woodcock: >> >> On Mar 19, 2019, at 10:12 AM, Fredy Kuenzler >> >> wrote: I wonder whether anyone has ever compiled a list of >> >> well-known Anycast prefixes. >> > >> > I don’t know of one. >> > >> > It seems like a good idea. >> > >> > BGP-multi-hop might be a reasonable way to collect them. >> > >> > If others agree that it’s a good idea, and it’s not stepping on >> > anyone’s toes, PCH would be happy to host/coordinate. >> >> Thanks for the effort, much appreciated. >> >> Am 19.03.19 um 18:40 schrieb Joe Provo: >> > I think one would want that internal and no rely upon someone else >> > maintaining it. You might check if Oracle followed up on the >> > Renesys/Dyn work documented: >> > https://dyn.com/wp-content/uploads/2014/07/NANOG59_Anycast.pdf >> > >> > ...where there were ~600 anycast v4 prefixes at the time. >> >> That's a lot %-] >> >> Maybe a well-known community (similar to RFC7999) could be defined and >> every Anycast operator could tag his prefixes? That's likely a better >> idea than manually maintain some list somewhere. >> >> -- >> Fredy Kuenzler >> >> Init7 (Switzerland) Ltd. >> AS13030 >> Technoparkstrasse 5 >> CH-8406 Winterthur >> Skype: flyingpotato >> Phone: +41 44 315 4400 >> Fax: +41 44 315 4401 >> Twitter: @init7 / @kuenzler >> http://www.init7.net/ >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog-post at rsuc.gweep.net Tue Mar 19 19:53:18 2019 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Tue, 19 Mar 2019 15:53:18 -0400 Subject: well-known Anycast prefixes In-Reply-To: References: <98053e99-687d-bc4c-cbd8-956b70a339ce@init7.net> <313D8869-90FF-423C-B444-B95E225A2E37@pch.net> Message-ID: <20190319195318.GA38320@gweep.net> On Tue, Mar 19, 2019 at 11:52:19AM -0700, Damian Menscher via NANOG wrote: > Careful thought should be given into whether the BGP community means "this > is an anycast prefix" vs "please hot-potato to this prefix". > Latency-sensitive applications may prefer hot-potato to their network even > if it's not technically an anycast range, as their private backbone may be > faster (less congested) than the public internet. To this point, it is pretty clear that any WK community covering this will get [ab]used in a way that the prefix annoucer wishes. We'll then see operators only accepting the WKC if it matches their prefix lists of known entities, getting us back to "hey maybe this should just be a registry I could reference". Woody, maybe generate route-sets to publish in RPSL (RADB?), one per address-family, of observed anycasters? It might be reasonable to do so in a format others can emulate if they wish to create/provide their own lists? Cheers, Joe > Damian > > On Tue, Mar 19, 2019 at 10:57 AM Siyuan Miao wrote: > > > > > A Well-known BGP community will be better. > > > > You'll need to rewrite next hop or do something similar if AnyCast > > prefixes are learnt from a multi hop BGP feed, and it made the > > configuration more complicated and difficult to debug. > > > > On Wed, Mar 20, 2019, 01:48 Fredy Kuenzler wrote: > > > >> Am 19.03.19 um 18:39 schrieb Bill Woodcock: > >> >> On Mar 19, 2019, at 10:12 AM, Fredy Kuenzler > >> >> wrote: I wonder whether anyone has ever compiled a list of > >> >> well-known Anycast prefixes. > >> > > >> > I don???t know of one. > >> > > >> > It seems like a good idea. > >> > > >> > BGP-multi-hop might be a reasonable way to collect them. > >> > > >> > If others agree that it???s a good idea, and it???s not stepping on > >> > anyone???s toes, PCH would be happy to host/coordinate. > >> > >> Thanks for the effort, much appreciated. > >> > >> Am 19.03.19 um 18:40 schrieb Joe Provo: > >> > I think one would want that internal and no rely upon someone else > >> > maintaining it. You might check if Oracle followed up on the > >> > Renesys/Dyn work documented: > >> > https://dyn.com/wp-content/uploads/2014/07/NANOG59_Anycast.pdf > >> > > >> > ...where there were ~600 anycast v4 prefixes at the time. > >> > >> That's a lot %-] > >> > >> Maybe a well-known community (similar to RFC7999) could be defined and > >> every Anycast operator could tag his prefixes? That's likely a better > >> idea than manually maintain some list somewhere. > >> > >> -- > >> Fredy Kuenzler > >> > >> Init7 (Switzerland) Ltd. > >> AS13030 > >> Technoparkstrasse 5 > >> CH-8406 Winterthur > >> Skype: flyingpotato > >> Phone: +41 44 315 4400 > >> Fax: +41 44 315 4401 > >> Twitter: @init7 / @kuenzler > >> http://www.init7.net/ > >> > >> -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling From christoffer at netravnen.de Tue Mar 19 20:04:17 2019 From: christoffer at netravnen.de (Hansen, Christoffer) Date: Tue, 19 Mar 2019 21:04:17 +0100 Subject: well-known Anycast prefixes In-Reply-To: <98053e99-687d-bc4c-cbd8-956b70a339ce@init7.net> References: <98053e99-687d-bc4c-cbd8-956b70a339ce@init7.net> Message-ID: something like this? https://github.com/netravnen/well-known-anycast-prefixes/blob/master/list.txt PR's and/or suggestions appreciated! (Can be turned into $lirDB friendly format->style RPSL) On 19/03/2019 18:12, Fredy Kuenzler wrote: > I wonder whether anyone has ever compiled a list of well-known Anycast > prefixes. > > Such as > > 1.1.1.0/24 > 8.8.8.0/24 > 9.9.9.0/24 > ... > > Might be useful for a routing policy such as "always route hot-potato". > > PS. this mail is not intended to start a flame war of hot vs. cold > potato routing. > -- Christoffer 0x18DD23C550293098DE07052A9DCF2CA008EBD2E8 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From Grzegorz at Janoszka.pl Tue Mar 19 20:11:08 2019 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Tue, 19 Mar 2019 21:11:08 +0100 Subject: well-known Anycast prefixes In-Reply-To: References: <98053e99-687d-bc4c-cbd8-956b70a339ce@init7.net> Message-ID: On 2019-03-19 21:04, Hansen, Christoffer wrote: > https://github.com/netravnen/well-known-anycast-prefixes/blob/master/list.txt > PR's and/or suggestions appreciated! (Can be turned into $lirDB friendly > format->style RPSL) Most DNS root servers are anycasted. -- Grzegorz Janoszka From woody at pch.net Tue Mar 19 20:13:09 2019 From: woody at pch.net (Bill Woodcock) Date: Tue, 19 Mar 2019 13:13:09 -0700 Subject: well-known Anycast prefixes In-Reply-To: References: <98053e99-687d-bc4c-cbd8-956b70a339ce@init7.net> Message-ID: <6632F2F0-F715-437B-8DCB-B86850FEE329@pch.net> > On Mar 19, 2019, at 1:04 PM, Hansen, Christoffer wrote: > > something like this? > > https://github.com/netravnen/well-known-anycast-prefixes/blob/master/list.txt > > PR's and/or suggestions appreciated! (Can be turned into $lirDB friendly > format->style RPSL) Generally, static lists like that are difficult to maintain when they’re tracking multiple routes from multiple parties. Communities have been suggested, which works as long as they’re passed through to somewhere people can see. Between PCH, RIS, and Route-Views, most should be visible somewhere, but not all. I think a combination of the two is probably most useful… people tag with a well-known community, then those get eBGP-multi-hopped to a common collector, and published as a clean machine-readable list. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From woody at pch.net Tue Mar 19 20:13:59 2019 From: woody at pch.net (Bill Woodcock) Date: Tue, 19 Mar 2019 13:13:59 -0700 Subject: well-known Anycast prefixes In-Reply-To: References: <98053e99-687d-bc4c-cbd8-956b70a339ce@init7.net> Message-ID: > On Mar 19, 2019, at 1:11 PM, Grzegorz Janoszka wrote: > > On 2019-03-19 21:04, Hansen, Christoffer wrote: >> https://github.com/netravnen/well-known-anycast-prefixes/blob/master/list.txt >> PR's and/or suggestions appreciated! (Can be turned into $lirDB friendly >> format->style RPSL) > > Most DNS root servers are anycasted. Right, yeah, I think he was just showing an example, since he had roughly a dozen, out of thousands. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From geier at geier.ne.tz Tue Mar 19 20:55:03 2019 From: geier at geier.ne.tz (Frank Habicht) Date: Tue, 19 Mar 2019 23:55:03 +0300 Subject: well-known Anycast prefixes In-Reply-To: <6632F2F0-F715-437B-8DCB-B86850FEE329@pch.net> References: <98053e99-687d-bc4c-cbd8-956b70a339ce@init7.net> <6632F2F0-F715-437B-8DCB-B86850FEE329@pch.net> Message-ID: <5adb6997-f77a-f46a-18af-bf468c0d9712@geier.ne.tz> Hi, On 19/03/2019 23:13, Bill Woodcock wrote: > Generally, static lists like that are difficult to maintain when > they’re tracking multiple routes from multiple parties. agreed. and on the other extreme, communities are very much prone to abuse. I guess I could set any community on a number of prefixes (incl anycast) right now.... So, I think a (moderated) BGP feed of prefixes a'la bogon from a trusted {cymru[1], pch[2], ...} could be good [3]. Frank Habicht 37084 / 33791 if that matters {1] dealing with anycast? [2] biased? [3] speaking as someone not using (subscribing) any of the useful ones, nor contributing to any... From woody at pch.net Tue Mar 19 21:03:50 2019 From: woody at pch.net (Bill Woodcock) Date: Tue, 19 Mar 2019 14:03:50 -0700 Subject: well-known Anycast prefixes In-Reply-To: <5adb6997-f77a-f46a-18af-bf468c0d9712@geier.ne.tz> References: <98053e99-687d-bc4c-cbd8-956b70a339ce@init7.net> <6632F2F0-F715-437B-8DCB-B86850FEE329@pch.net> <5adb6997-f77a-f46a-18af-bf468c0d9712@geier.ne.tz> Message-ID: <062A7841-A157-4CCA-9CA6-2F3C244D5632@pch.net> > On Mar 19, 2019, at 1:55 PM, Frank Habicht wrote: > > Hi, > > On 19/03/2019 23:13, Bill Woodcock wrote: >> Generally, static lists like that are difficult to maintain when >> they’re tracking multiple routes from multiple parties. > > agreed. > and on the other extreme, communities are very much prone to abuse. > I guess I could set any community on a number of prefixes (incl anycast) > right now.... > > So, I think a (moderated) BGP feed of prefixes a'la bogon from a trusted > {cymru[1], pch[2], ...} could be good [3]. Ok, so, just trying to flesh out the idea to something that can be usefully implemented… 1) People send an eBGP multi-hop feed of well-known-community routes to a collector, or send them over normal peering sessions to something that aggregates… 2) Because those are over BGP sessions, the counterparty is known, and can be asked for details or clarification by the “moderator,” or the sender could log in to an interface to add notes about the prefixes, as they would in the IXPdir or PeeringDB. 3) Known prefixes from known parties would be passed through in real-time, as they were withdrawn and restored. 4) New prefixes from known parties would be passed through in real-time if they weren’t unusual (large/overlapping something else/previously announced by other ASNs). 5) New prefixes from known parties would be “moderated” if they were unusual. 6) New prefixes from new parties would be “moderated” to establish that they were legit and that there was some documentation explaining what they were. 7) For anyone who really didn’t want to provide a community-tagged BGP feed, a manual submission process would exist. 8) Everything gets published as a real-time eBGP feed. 9) Everything gets published as HTTPS-downloadable JSON. 10) Everything gets published as a human-readable (and crawler-indexable) web page. Does that sound about right? -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From rfg at tristatelogic.com Wed Mar 20 00:01:31 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Tue, 19 Mar 2019 17:01:31 -0700 Subject: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland) In-Reply-To: <50414.162.155.102.254.1553001814.iglou@webmail.iglou.com> Message-ID: <81905.1553040091@segfault.tristatelogic.com> [[ I've just collected some new information about the length of time that this specific bincoin extortion spamming bad actor has been on Digital Ocean's network. For those who may only have an interest in that one detail, you can just skip down to the line of plus signs and start reading there. ]] In message <50414.162.155.102.254.1553001814.iglou at webmail.iglou.com>, "Jeff McAdams" wrote: >(Disclosure: I, too, work for DigitalOcean as the Manager of Network >Engineering. Nikolas does not work for me, nor I for him.) > >On Tue, March 19, 2019 02:17, Ronald F. Guilmette wrote: >> > >> Nikolas Geyer wrote: >>> I have passed your email on to the relevant team within DO to have a >>> look at. > >> Thank you, but that wasn't what I requested, I asked for a contact >> there. > >Oh, is that how this works? I ask that you FedEx me a million dollars >cash, in small bills. I await the arrival of said parcel. In my experience, if you don't ask for something, you aren't likely to get it. There's no harm in asking. In any case, I offer you the pertinent observation also that "small bills" are soooooooo last century. These days, as should now be abundantly clear, payment in bitcoin is the preferable currency for such requests. :-) >> In any case, I would be more than happy to have you tell me the "right >> way" to engage with any actual live human beings at either of these >> companies, especially if you also are able to identify one or more such >> receptive individuals by name and email address, which is what I was >> requesting in the first place. > >Would you really be happy with that? You derided another good-faith >respondent to your screed with a rant about not being willing to fill out >web forms to report abuse because it offends your sensibilities. I stand by what I wrote. I don't like dealing with anonymous web forms that, for all I know, and based on the available evidence, are or may be aliased to /dev/null. I prefer the human touch, especially in cases where I am seeking to find someone who may be held accountable when and if no actual action ensues. >We would prefer, but don't require, that you use the web form because that >is integrated into the workflow of the groups that respond to those >reports. If they choose to give you their individualized contact >information, then they can do that. It is not my place, nor Nikolas', to >give out individual contact information for our co-workers out to anyone >who asks. That would be irresponsible and obnoxious for us to do that. I am not just "anyone who asks". I am a guy who's been spammed from your network. If you read my earlier report, then you should know that I am also the guy who took the time to carefully resarch this, and to provide your company with information about this specific crook/spammer... information that, it seems, you folks yourselves have apparently been largely or entirely unaware of, and for some considerable time now. Given that context, am I really entirely undeserving of even being informed of the mere email address of the head of DigitalOcean's abuse handling department, assuming, at least for the sake of argument, that such an inddividual does in fact exist? Wouldn't it be a Good Thing if that person and I could communicate direct? And more to the point, what would be the downside, exactly, if that person's name and email address were not only given to me, but also scattered to the four winds an given out to everyone on the planet? Are you implicitly asserting that that person might then have to (gasp!) deal with some additional influx of spam into his or her inbox? If so, then I can't help but wonder aloud why that person should NOT join the rest of us mere mortals in that shared and miserable club. Perhaps it would even be of some benefit for that person to come down out of the clouds at least long enough to experience what the rest of us poor sods have to deal with on a routine and daily basis. The experience might even enhance that person's understanding of, and appreciation of the very kinds of (spamming) problem that he or she is being paid to attend to. Stranger things have happened. I'll be generous here and will refrain from leaping to any conclusions that the person in question does not want his or her identity to be generally known for fear that he/she might then be personally criticised for his/her work and/or the lack thereof. But other than that, and a possible desire to avoid receiving any of this same spam-slime that the rest of us poor slobs get coated in on a daily basis, I really can't imagine what other reasons there might be that would cause Digital Ocean's abuse handling staff and/or the managment thereof to be so overwhelmingly discreet. What I can say, rather definitively now, is that the specific bitcoin scammer-spammer that prompted me to begin this thread has been given, over time, and by your company, Digital Ocean, no fewer than five hundred and fifty three (553) separate, distinct, discrete and individual IPv4 addresses and that many, most or all of those have been used for outbound spamming purposes, all just by this one bad actor, and all during the present calendar year. The evidence supporting this assertion was and is available here: https://pastebin.com/raw/WtM0Y5yC Note that this is the equivalent of more than a full /23 that Digital Ocean has given to this one customer, presumably after vetting the customer according to current industry standard due diligence procedures, which is to say no due diligence whatsoever, other than making sure that the check clears. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Additionally, I have just collected some additional evidence, courtesy of the Farsight Security passive DNS service, which appears to indicate that this specific bad actor has been (and perhaps remains?) a customer of Digital Ocean, not just for a few days, or just for a week or two, but for a period in excess of two full months, continuously, based upon reverse DNS settings in place on your network since at least January 7th: ==================================================================== ;; bailiwick: 71.128.178.in-addr.arpa. ;; count: 155 ;; first seen: 2019-01-07 13:09:45 -0000 ;; last seen: 2019-03-18 07:51:33 -0000 40.71.128.178.in-addr.arpa. IN PTR mx.c.cryptoaccount.ml. ==================================================================== This additional information raises a number of rather obvious questions: *) How many reports/complaints has Digital Ocean received, since the beginning of the current calendar year, regarding this specific criminal extortion spammer on your network? (Hint: If your assertion is that the number has been zero, I will likely point out that that estimate is not really credible, under the circumstances, and in light of the numerous Twitter spamming reports that I've previously cited.) *) Within the time period since this bad actor became active on the Digital Ocean network, and since the first relevant report of network abuse was received by your company about this specific bad actor, what has prevented Digital Ocean's abuse handling department from being either able or willing to effectively action this case? *) Does Digital Ocean enable outbound TCP port 25 connectivity for its new customers by default and in the absence of explicit customer requests? And if so, is that really the best choice? I look forward to your responses with respect to these relevant questions. Regards, rfg From rfg at tristatelogic.com Wed Mar 20 00:22:01 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Tue, 19 Mar 2019 17:22:01 -0700 Subject: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland) In-Reply-To: Message-ID: <82024.1553041321@segfault.tristatelogic.com> In message , Tom Beecher wrote: >Calling everyone an idiot in the midst of Endless Pontification isn't >really a recipe for success. I did not call "everyone" an idiot. I'm quite completely sure that there are innumerable people in all of the referenced companies who are consumate and hardworking professionals who excel at ther jobs. I do believe however, based on considerable experience and much hard evidence, that the abuse handling departnments at OVH and DigitalOcean, and indeed at essentially -every- sizable hosting company are less than entirely well staffed, less than entirely well trained, less than entirely well funded, and often inadequately effective, either due to their limited willingness or their limited authority, as circumscribed by management, when it comes to the execution of their assigned duties. The abuse handling function at *every* Internet company is the ugly stepchild, ignored whenever possible, and typically starved of resources by management whose overriding consideration is this quarter's P&L statement, and by extension, the nearest upcoming executive bonus period. Regards, rfg From dhubbard at dino.hostasaurus.com Wed Mar 20 00:33:02 2019 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 20 Mar 2019 00:33:02 +0000 Subject: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland) In-Reply-To: <82024.1553041321@segfault.tristatelogic.com> References: <82024.1553041321@segfault.tristatelogic.com> Message-ID: <935DC3C7-28FC-491E-85D1-24712F7F45CB@dino.hostasaurus.com> On 3/19/19, 8:23 PM, "NANOG on behalf of Ronald F. Guilmette" wrote: In message , Tom Beecher wrote: >Calling everyone an idiot in the midst of Endless Pontification isn't >really a recipe for success. I did not call "everyone" an idiot. I'm quite completely sure that there are innumerable people in all of the referenced companies who are consumate and hardworking professionals who excel at ther jobs. I do believe however, based on considerable experience and much hard evidence, that the abuse handling departnments at OVH and DigitalOcean, and indeed at essentially -every- sizable hosting company are less than entirely well staffed, less than entirely well trained, less than entirely well funded, and often inadequately effective, either due to their limited willingness or their limited authority, as circumscribed by management, when it comes to the execution of their assigned duties. The abuse handling function at *every* Internet company is the ugly stepchild, ignored whenever possible, and typically starved of resources by management whose overriding consideration is this quarter's P&L statement, and by extension, the nearest upcoming executive bonus period. Regards, rfg Why not just drop any prefixes from the respective ASN's? We had to do that with OVH after the endless attacks coming from their networks, and lack of abuse response. OVH really loves to shift the abuse around to new prefixes; I got tired of spending time staying ahead of it. From geier at geier.ne.tz Wed Mar 20 05:49:30 2019 From: geier at geier.ne.tz (Frank Habicht) Date: Wed, 20 Mar 2019 08:49:30 +0300 Subject: well-known Anycast prefixes In-Reply-To: <062A7841-A157-4CCA-9CA6-2F3C244D5632@pch.net> References: <98053e99-687d-bc4c-cbd8-956b70a339ce@init7.net> <6632F2F0-F715-437B-8DCB-B86850FEE329@pch.net> <5adb6997-f77a-f46a-18af-bf468c0d9712@geier.ne.tz> <062A7841-A157-4CCA-9CA6-2F3C244D5632@pch.net> Message-ID: Hi, On 20/03/2019 00:03, Bill Woodcock wrote: > Ok, so, just trying to flesh out the idea to something that can be > usefully implemented… > > 1) People send an eBGP multi-hop feed of well-known-community routes > to a collector, or send them over normal peering sessions to > something that aggregates… to clarify, eBGP multi-hop sounds good, that can be a dedicated session for this purpose, BGP communities probably don't need to be added. [for the case of 'normal peering sessions', it might seem "wasteful" to use an additional IP on multiple peering LANs] ... > Does that sound about right? to me yes. Frank From rsk at gsp.org Wed Mar 20 13:00:17 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 20 Mar 2019 09:00:17 -0400 Subject: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland) In-Reply-To: References: <76776.1552976247@segfault.tristatelogic.com> <50414.162.155.102.254.1553001814.iglou@webmail.iglou.com> <20190319144952.GA14021@gsp.org> Message-ID: <20190320130017.GC20100@gsp.org> On Tue, Mar 19, 2019 at 09:17:23AM -0700, Eric Kuhnke wrote: > Absolutely unrelated to Ronald's original post, but it's ironic that the > abuse@ address is itself heavily "abused", by commercial copyright > enforcement companies which think it's a catch-all address for things which > are not operationally related to the health of a network [snip] I've seen this movie and have implemented various mitigation approaches to it -- none of which constitute a "solution" but all of which help. 1. Block the addresses originating this traffic. There's no need for staff/processes on the receiving end to put up with spam. (If it's UBE, then it's spam -- by definition. The content and intention are irrelevant.) 2. Use procmail to redirect it where it needs to go. 3. Set up (non-public) Mailman-operated mailing lists for each role account and use the moderation queue on those as a throttling tool. (This works best in conjunction with (2). Let procmail do some of the heavy/straightforward lifting and sort the rest out later.) This also makes it easy to archive everything by subscribing an address that's an append-only mailbox. 4. Funnel the output of (2) and/or (3) into one of the many ticketing systems with priority assigned based on the characteristics of the senders as observed over time. ---rsk From john at alcock.org Wed Mar 20 14:02:13 2019 From: john at alcock.org (John Alcock) Date: Wed, 20 Mar 2019 10:02:13 -0400 Subject: Help on setting up a new block Message-ID: Odd Issues We recently went through an IP Broker and bought a /18 worth of IP's I am listing all my information below. Should be public record. AS Number/Range 395437 AS Handle AS395437 AS Name HIGHLANDTEL RPKI Certified Yes As for the IP Block Net Range 138.43.128.0 - 138.43.191.255 CIDR 138.43.128.0/18 Net Name HCL-73 Net Handle NET-138-43-128-0-1 Net Type Direct Allocation Parent NET-138-0-0-0-0 (VR-ARIN) RPKI Certified Yes In addition, I believe I got all the information in the IRR. I am unclear on this part, but I do know ATT is happy now. I can pass traffic through their network. whois -h whois.bgpmon.net " --roa 395437 138.43.128.0/24" 0 - Valid ------------------------ ROA Details ------------------------ Origin ASN: AS395437 Not valid Before: 2019-02-13 05:00:00 Not valid After: 2029-02-01 05:00:00 Expires in 9y318d10h46m2.39999997615814s Trust Anchor: rpki.arin.net Prefixes: 138.43.128.0/18 (max length /24) So here is my problem. There are certain sites I can not get to on the new ip block. clover.com - They are a large POS vendor catering to small business idrive.com - Online backup heart.org - american heart association onlineproviderservices.com - Looks like an outsourced group that handles medicare landstar.com - trucking company I am working on trying to contact the companies above, but I have started resorting to public shaming on social media. Not an ideal solution. My thought, could I be missing something? Perhaps I need to add a specfic entry in the IRR or anything? Just seems like a lot of sites will not accept my traffic. Any experts like to chime in? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From pete at tccmail.ca Wed Mar 20 14:22:34 2019 From: pete at tccmail.ca (Pete Baldwin) Date: Wed, 20 Mar 2019 10:22:34 -0400 Subject: Help on setting up a new block In-Reply-To: References: Message-ID: <3b3c57cf-9c38-0e67-3196-44aed6a4c27f@tccmail.ca>     Do a search on the /16 parent block.   It has a history of being on block lists.   I imagine some admins have old lists that they do not update very often, or have the entire /16 or greater blocked. I also went through this process when we purchased IPs, and I've had to contact hundreds of networks over the last couple of years to try and get our blocks removed from their firewalls.    Our specific block was never on any block lists, but the parent was plastered all over the place.     It's potentially more difficult now than in the past because there are some hosting providers that are simply a few people that own VMs on some other infrastructure that they do not control or have visibility into.  The VM hosting company might be blocking your network, and so the VMs never see your traffic.   This means you might contact Landstar, and then Landstar calls up their web person, but the web person doesn't understand this stuff.   The web person phones his web hosting company who can't find anything wrong, because they never see your packets to begin with.   Now the web hosting company (if you can get them to do this) needs to contact their DC company that is hosting their VMs to find out if there is a firewall or anti DDoS system etc that is sitting in front of their VMs.     Most of these calls take a long time.   There is a lot of hand-holding, and captures that need to be sent, and then you just hope you can find someone willing to dig into it on the other end of the phone.     Good luck with the process.  I believe you will be successful in most cases, but it will take awhile. ----- Pete Baldwin Tuckersmith Communications (P) 519-565-2400 (C) 519-441-7383 On 3/20/19 10:02 AM, John Alcock wrote: > Odd Issues > > We recently went through an IP Broker and bought a /18 worth of IP's > > I am listing all my information below.  Should be public record. > > AS Number/Range 395437 > AS Handle AS395437 > AS Name HIGHLANDTEL > RPKI Certified Yes > > As for the IP Block > > Net Range 138.43.128.0 - 138.43.191.255 > CIDR 138.43.128.0/18 > Net Name HCL-73 > Net Handle NET-138-43-128-0-1 > Net Type Direct Allocation > Parent NET-138-0-0-0-0 (VR-ARIN) > RPKI Certified Yes > > In addition, I believe I got all the information in the IRR. I am > unclear on this part, but I do know ATT is happy now.  I can pass > traffic through their network. > > whois -h whois.bgpmon.net " --roa 395437 > 138.43.128.0/24 " > > 0 - Valid > ------------------------ > ROA Details > ------------------------ > Origin ASN:       AS395437 > Not valid Before: 2019-02-13 05:00:00 > Not valid After:  2029-02-01 05:00:00  Expires in > 9y318d10h46m2.39999997615814s > Trust Anchor: rpki.arin.net > Prefixes: 138.43.128.0/18 (max length /24) > > > So here is my problem.  There are certain sites I can not get to on > the new ip block. > > clover.com - They are a large POS vendor catering > to small business > idrive.com - Online backup > heart.org - american heart association > onlineproviderservices.com - Looks > like an outsourced group that handles medicare > landstar.com - trucking company > > I am working on trying to contact the companies above, but I have > started resorting to public shaming on social media.  Not an ideal > solution. > > My thought, could I be missing something?  Perhaps I need to add a > specfic entry in the IRR or anything?  Just seems like a lot of sites > will not accept my traffic. > > Any experts like to chime in? > > John -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Wed Mar 20 14:25:51 2019 From: beecher at beecher.cc (Tom Beecher) Date: Wed, 20 Mar 2019 10:25:51 -0400 Subject: Help on setting up a new block In-Reply-To: References: Message-ID: Taking a quick look, seems like reachability to the first /24 at least is ok, so I don't think you have a problem there. You may have picked up a subnet with some nuggets of abuse history in there, it's quite common on the secondary V4 market. On Wed, Mar 20, 2019 at 10:05 AM John Alcock wrote: > Odd Issues > > We recently went through an IP Broker and bought a /18 worth of IP's > > I am listing all my information below. Should be public record. > > AS Number/Range 395437 > AS Handle AS395437 > AS Name HIGHLANDTEL > RPKI Certified Yes > > As for the IP Block > > Net Range 138.43.128.0 - 138.43.191.255 > CIDR 138.43.128.0/18 > Net Name HCL-73 > Net Handle NET-138-43-128-0-1 > Net Type Direct Allocation > Parent NET-138-0-0-0-0 (VR-ARIN) > RPKI Certified Yes > > In addition, I believe I got all the information in the IRR. I am unclear > on this part, but I do know ATT is happy now. I can pass traffic through > their network. > > whois -h whois.bgpmon.net " --roa 395437 138.43.128.0/24" > > 0 - Valid > ------------------------ > ROA Details > ------------------------ > Origin ASN: AS395437 > Not valid Before: 2019-02-13 05:00:00 > Not valid After: 2029-02-01 05:00:00 Expires in > 9y318d10h46m2.39999997615814s > Trust Anchor: rpki.arin.net > Prefixes: 138.43.128.0/18 (max length /24) > > > So here is my problem. There are certain sites I can not get to on the > new ip block. > > clover.com - They are a large POS vendor catering to small business > idrive.com - Online backup > heart.org - american heart association > onlineproviderservices.com - Looks like an outsourced group that handles > medicare > landstar.com - trucking company > > I am working on trying to contact the companies above, but I have started > resorting to public shaming on social media. Not an ideal solution. > > My thought, could I be missing something? Perhaps I need to add a specfic > entry in the IRR or anything? Just seems like a lot of sites will not > accept my traffic. > > Any experts like to chime in? > > John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fhr at fhrnet.eu Wed Mar 20 14:31:16 2019 From: fhr at fhrnet.eu (Filip Hruska) Date: Wed, 20 Mar 2019 14:31:16 +0000 Subject: Help on setting up a new block In-Reply-To: References: Message-ID: <010201699b83722a-df709021-3344-4158-b466-ba1419acdf68-000000@eu-west-1.amazonses.com> I would start with basic stuff first. Traceroutes to check if/where the packets are being dropped. If the path is clear, then it's probably a HTTP level block, in which case figure out if these companies share the same CDN/web protection solution/hoster. If that's the case, contact them directly. Regards, Filip Hruska On 20 March 2019 3:02:13 pm GMT+01:00, John Alcock wrote: >Odd Issues > >We recently went through an IP Broker and bought a /18 worth of IP's > >I am listing all my information below. Should be public record. > >AS Number/Range 395437 >AS Handle AS395437 >AS Name HIGHLANDTEL >RPKI Certified Yes > >As for the IP Block > >Net Range 138.43.128.0 - 138.43.191.255 >CIDR 138.43.128.0/18 >Net Name HCL-73 >Net Handle NET-138-43-128-0-1 >Net Type Direct Allocation >Parent NET-138-0-0-0-0 (VR-ARIN) >RPKI Certified Yes > >In addition, I believe I got all the information in the IRR. I am >unclear >on this part, but I do know ATT is happy now. I can pass traffic >through >their network. > >whois -h whois.bgpmon.net " --roa 395437 138.43.128.0/24" > >0 - Valid >------------------------ >ROA Details >------------------------ >Origin ASN: AS395437 >Not valid Before: 2019-02-13 05:00:00 >Not valid After: 2029-02-01 05:00:00 Expires in >9y318d10h46m2.39999997615814s >Trust Anchor: rpki.arin.net >Prefixes: 138.43.128.0/18 (max length /24) > > >So here is my problem. There are certain sites I can not get to on the >new >ip block. > >clover.com - They are a large POS vendor catering to small business >idrive.com - Online backup >heart.org - american heart association >onlineproviderservices.com - Looks like an outsourced group that >handles >medicare >landstar.com - trucking company > >I am working on trying to contact the companies above, but I have >started >resorting to public shaming on social media. Not an ideal solution. > >My thought, could I be missing something? Perhaps I need to add a >specfic >entry in the IRR or anything? Just seems like a lot of sites will not >accept my traffic. > >Any experts like to chime in? > >John -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at alcock.org Wed Mar 20 15:28:05 2019 From: john at alcock.org (John Alcock) Date: Wed, 20 Mar 2019 11:28:05 -0400 Subject: Help on setting up a new block In-Reply-To: <010201699b83722a-df709021-3344-4158-b466-ba1419acdf68-000000@eu-west-1.amazonses.com> References: <010201699b83722a-df709021-3344-4158-b466-ba1419acdf68-000000@eu-west-1.amazonses.com> Message-ID: I found an interesting pattern. I see a lot of traffic stopping at softlayer.com. Big datacenter? Could they be doing some blocking? John On Wed, Mar 20, 2019 at 10:31 AM Filip Hruska wrote: > I would start with basic stuff first. > > Traceroutes to check if/where the packets are being dropped. If the path > is clear, then it's probably a HTTP level block, in which case figure out > if these companies share the same CDN/web protection solution/hoster. If > that's the case, contact them directly. > > Regards, > Filip Hruska > > On 20 March 2019 3:02:13 pm GMT+01:00, John Alcock > wrote: >> >> Odd Issues >> >> We recently went through an IP Broker and bought a /18 worth of IP's >> >> I am listing all my information below. Should be public record. >> >> AS Number/Range 395437 >> AS Handle AS395437 >> AS Name HIGHLANDTEL >> RPKI Certified Yes >> >> As for the IP Block >> >> Net Range 138.43.128.0 - 138.43.191.255 >> CIDR 138.43.128.0/18 >> Net Name HCL-73 >> Net Handle NET-138-43-128-0-1 >> Net Type Direct Allocation >> Parent NET-138-0-0-0-0 (VR-ARIN) >> RPKI Certified Yes >> >> In addition, I believe I got all the information in the IRR. I am >> unclear on this part, but I do know ATT is happy now. I can pass traffic >> through their network. >> >> whois -h whois.bgpmon.net " --roa 395437 138.43.128.0/24" >> >> 0 - Valid >> ------------------------ >> ROA Details >> ------------------------ >> Origin ASN: AS395437 >> Not valid Before: 2019-02-13 05:00:00 >> Not valid After: 2029-02-01 05:00:00 Expires in >> 9y318d10h46m2.39999997615814s >> Trust Anchor: rpki.arin.net >> Prefixes: 138.43.128.0/18 (max length /24) >> >> >> So here is my problem. There are certain sites I can not get to on the >> new ip block. >> >> clover.com - They are a large POS vendor catering to small business >> idrive.com - Online backup >> heart.org - american heart association >> onlineproviderservices.com - Looks like an outsourced group that handles >> medicare >> landstar.com - trucking company >> >> I am working on trying to contact the companies above, but I have started >> resorting to public shaming on social media. Not an ideal solution. >> >> My thought, could I be missing something? Perhaps I need to add a >> specfic entry in the IRR or anything? Just seems like a lot of sites will >> not accept my traffic. >> >> Any experts like to chime in? >> >> John >> > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at shout.net Wed Mar 20 15:35:07 2019 From: bryan at shout.net (Bryan Holloway) Date: Wed, 20 Mar 2019 10:35:07 -0500 Subject: Help on setting up a new block In-Reply-To: References: <010201699b83722a-df709021-3344-4158-b466-ba1419acdf68-000000@eu-west-1.amazonses.com> Message-ID: On 3/20/19 10:28 AM, John Alcock wrote: > I found an interesting pattern.  I see a lot of traffic stopping at > softlayer.com .  Big datacenter?  Could they be > doing some blocking? > > John > Could be. They were acquired by IBM a few years ago. From aveline at misaka.io Wed Mar 20 15:38:39 2019 From: aveline at misaka.io (Siyuan Miao) Date: Wed, 20 Mar 2019 23:38:39 +0800 Subject: Help on setting up a new block In-Reply-To: References: <010201699b83722a-df709021-3344-4158-b466-ba1419acdf68-000000@eu-west-1.amazonses.com> Message-ID: They block IP address from Iran, Cuba, North Korea, and Syria. You can check https://cloud.ibm.com/docs/overview/terms-of-use?topic=overview-terms#notices for more details. On Wed, Mar 20, 2019 at 11:37 PM Bryan Holloway wrote: > > On 3/20/19 10:28 AM, John Alcock wrote: > > I found an interesting pattern. I see a lot of traffic stopping at > > softlayer.com . Big datacenter? Could they be > > doing some blocking? > > > > John > > > > Could be. They were acquired by IBM a few years ago. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chinese.apricot at gmail.com Wed Mar 20 16:32:24 2019 From: chinese.apricot at gmail.com (william manning) Date: Wed, 20 Mar 2019 09:32:24 -0700 Subject: Help on setting up a new block In-Reply-To: References: <010201699b83722a-df709021-3344-4158-b466-ba1419acdf68-000000@eu-west-1.amazonses.com> Message-ID: of course at the end of the day, there is ZERO requirement for anyone to accept traffic from any prefix. to paraphrase an old greybeard, "my network, my rulez" /Wm On Wed, Mar 20, 2019 at 8:40 AM Siyuan Miao wrote: > They block IP address from Iran, Cuba, North Korea, and Syria. > > You can check > https://cloud.ibm.com/docs/overview/terms-of-use?topic=overview-terms#notices > for more details. > > On Wed, Mar 20, 2019 at 11:37 PM Bryan Holloway wrote: > >> >> On 3/20/19 10:28 AM, John Alcock wrote: >> > I found an interesting pattern. I see a lot of traffic stopping at >> > softlayer.com . Big datacenter? Could they be >> > doing some blocking? >> > >> > John >> > >> >> Could be. They were acquired by IBM a few years ago. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at alcock.org Wed Mar 20 16:35:03 2019 From: john at alcock.org (John Alcock) Date: Wed, 20 Mar 2019 12:35:03 -0400 Subject: softlayer.com Message-ID: Afternoon, Thought I would start a new thread. After researching, traceroutes, etc, I think I found my problem. 9 out of the 10 sites that subscribers on my new block is being hosted by softlayer. Anyone on the list have contacts with softlayer. Right now I have an email to abuse. The support line will not help me out. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bryan at bryanfields.net Wed Mar 20 16:45:35 2019 From: Bryan at bryanfields.net (Bryan Fields) Date: Wed, 20 Mar 2019 12:45:35 -0400 Subject: Help on setting up a new block In-Reply-To: References: <010201699b83722a-df709021-3344-4158-b466-ba1419acdf68-000000@eu-west-1.amazonses.com> Message-ID: On 3/20/19 12:32 PM, william manning wrote: > of course at the end of the day, there is ZERO requirement for anyone to > accept traffic from any prefix. to paraphrase an old greybeard, > "my network, my rulez" Wouldn't this be in conflict with the idea of "network neutrality" rules? >_> <_< -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From valdis.kletnieks at vt.edu Wed Mar 20 17:15:44 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Wed, 20 Mar 2019 13:15:44 -0400 Subject: Help on setting up a new block In-Reply-To: <3b3c57cf-9c38-0e67-3196-44aed6a4c27f@tccmail.ca> References: <3b3c57cf-9c38-0e67-3196-44aed6a4c27f@tccmail.ca> Message-ID: <17211.1553102144@turing-police> On Wed, 20 Mar 2019 10:22:34 -0400, Pete Baldwin said: > ��� It's potentially more difficult now than in the past because there > are some hosting providers that are simply a few people that own VMs on > some other infrastructure that they do not control or have visibility > into.� The VM hosting company might be blocking your network, and so the > VMs never see your traffic.�� This means you might contact Landstar, and > then Landstar calls up their web person, but the web person doesn't > understand this stuff.�� The web person phones his web hosting company > who can't find anything wrong, because they never see your packets to > begin with.�� Now the web hosting company (if you can get them to do > this) needs to contact their DC company that is hosting their VMs to > find out if there is a firewall or anti DDoS system etc that is sitting > in front of their VMs. Have we reached the point where it is (or should be) due diligence and a BCP to make sure your new address space is reachable on IPv6 as well, to improve your chances of being reachable even if your IPv4 space is in somebody's block list? From valdis.kletnieks at vt.edu Wed Mar 20 17:18:43 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Wed, 20 Mar 2019 13:18:43 -0400 Subject: Help on setting up a new block In-Reply-To: References: <010201699b83722a-df709021-3344-4158-b466-ba1419acdf68-000000@eu-west-1.amazonses.com> Message-ID: <17407.1553102323@turing-police> On Wed, 20 Mar 2019 12:45:35 -0400, Bryan Fields said: > On 3/20/19 12:32 PM, william manning wrote: > > of course at the end of the day, there is ZERO requirement for anyone to > > accept traffic from any prefix. to paraphrase an old greybeard, > > "my network, my rulez" > > Wouldn't this be in conflict with the idea of "network neutrality" rules? Depends. Was softlayer up-front with the customers about what addresses are blocked, and why? If the customers knew that softlayer had a block list and had a way to tell if it was impacting their network access, that's one thing. If softlayer was doing it without informed consent from its customers, that's a different kettle of fish.... From chinese.apricot at gmail.com Wed Mar 20 17:54:04 2019 From: chinese.apricot at gmail.com (william manning) Date: Wed, 20 Mar 2019 10:54:04 -0700 Subject: Help on setting up a new block In-Reply-To: References: <010201699b83722a-df709021-3344-4158-b466-ba1419acdf68-000000@eu-west-1.amazonses.com> Message-ID: not clear what network neutrality has to say about this. are you required to accept DDoS traffic or is that covered by net neutrality? /Wm On Wed, Mar 20, 2019 at 9:47 AM Bryan Fields wrote: > On 3/20/19 12:32 PM, william manning wrote: > > of course at the end of the day, there is ZERO requirement for anyone to > > accept traffic from any prefix. to paraphrase an old greybeard, > > "my network, my rulez" > > Wouldn't this be in conflict with the idea of "network neutrality" rules? > > >_> > <_< > > -- > Bryan Fields > > 727-409-1194 - Voice > http://bryanfields.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ml-assoprovider at wt-tech.it Wed Mar 20 14:53:56 2019 From: ml-assoprovider at wt-tech.it (Davide Gelardi) Date: Wed, 20 Mar 2019 15:53:56 +0100 Subject: Amazon Prime video NOC contact Message-ID: <71c140ab6e1a36c64b4a209457e7394f@wt-tech.it> Hi, we are an italian ISP/WISP and we are experiecing trouble with Amazon Prime Video. They blocked our customers that cannot view the video. The error says that our IP class is located ouside italy. But this is wrong. Have you a contact we can get in touch with? thanks in advance! Davide Gelardi -- WT Srl tel 09411935549 / fax 09411936034 Sede legale: via Verdi 7 - 98066 PATTI - MESSINA www.IcaroInternet.it - www.wt-tech.it From bill at herrin.us Wed Mar 20 18:16:29 2019 From: bill at herrin.us (William Herrin) Date: Wed, 20 Mar 2019 11:16:29 -0700 Subject: Amazon Prime video NOC contact In-Reply-To: <71c140ab6e1a36c64b4a209457e7394f@wt-tech.it> References: <71c140ab6e1a36c64b4a209457e7394f@wt-tech.it> Message-ID: On Wed, Mar 20, 2019 at 11:03 AM Davide Gelardi wrote: > we are an italian ISP/WISP and we are experiecing trouble with Amazon > Prime Video. They blocked our customers that cannot view the video. The > error says that our IP class is located ouside italy. But this is wrong. > > Have you a contact we can get in touch with? > Hi Davide, You may have some luck here: https://www.amazonforum.com/forums/digital-content/prime-video Amazon staff working on Prime Video monitor and respond on that forum. The individuals reading may not be the right people, but they'll likely be on a first name basis with someone who is. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From nuclearcat at nuclearcat.com Wed Mar 20 19:21:52 2019 From: nuclearcat at nuclearcat.com (Denys Fedoryshchenko) Date: Wed, 20 Mar 2019 21:21:52 +0200 Subject: Facebook dropping MSS on congestion Message-ID: <6851f66c19c020c4a1b985bb56a79086@nuclearcat.com> Good day, I am writing here, as in technical support ticket I will most likely end up to the outsourcing guys, who will try to write some formal reply and close the ticket quickly to keep KPI high:) I have a faint hope that someone will read and listen. It may also be useful to colleagues. I noticed at last few month, if some congestion occurs on the network (specific subnet), facebook reduces the maximum segment size (MSS), even down to 256 bytes. Purely academically, on paper - this will reduce latency. In reality - it will cause avalanche effect. If ISP have CGNAT, or some other appliances - with great probability they will encounter the fact that pps will increase 4-5 times, and might hit pps limit on hardware. Additionally, overhead on IP headers will increase significantly, especially on ipv6, and this will further aggravate the congestion. Facebook don't do that, please. And thank you, if you listen to suggestions. Denys From ahad at swiftelnetworks.com Wed Mar 20 21:53:31 2019 From: ahad at swiftelnetworks.com (Ahad Aboss) Date: Thu, 21 Mar 2019 08:53:31 +1100 Subject: Help on setting up a new block In-Reply-To: References: Message-ID: Hi John, I have gone through this pain previously and I suggest you contact the main Geo IP database providers and have them update their DB as some organisation use them, they don't rely on IRR entries. Some hosting companies and content/streaming/Pay-TV providers also use these GeoIP Databases which may take a while to update. Here are a some of these companies FYI; IP2Location www.ip2location.com W3C Geolocation Quova www.quova.com Geo IP by MaxMind www.maxmind.com Cheers, Ahad On Thu, Mar 21, 2019 at 1:05 AM John Alcock wrote: > Odd Issues > > We recently went through an IP Broker and bought a /18 worth of IP's > > I am listing all my information below. Should be public record. > > AS Number/Range 395437 > AS Handle AS395437 > AS Name HIGHLANDTEL > RPKI Certified Yes > > As for the IP Block > > Net Range 138.43.128.0 - 138.43.191.255 > CIDR 138.43.128.0/18 > Net Name HCL-73 > Net Handle NET-138-43-128-0-1 > Net Type Direct Allocation > Parent NET-138-0-0-0-0 (VR-ARIN) > RPKI Certified Yes > > In addition, I believe I got all the information in the IRR. I am unclear > on this part, but I do know ATT is happy now. I can pass traffic through > their network. > > whois -h whois.bgpmon.net " --roa 395437 138.43.128.0/24" > > 0 - Valid > ------------------------ > ROA Details > ------------------------ > Origin ASN: AS395437 > Not valid Before: 2019-02-13 05:00:00 > Not valid After: 2029-02-01 05:00:00 Expires in > 9y318d10h46m2.39999997615814s > Trust Anchor: rpki.arin.net > Prefixes: 138.43.128.0/18 (max length /24) > > > So here is my problem. There are certain sites I can not get to on the > new ip block. > > clover.com - They are a large POS vendor catering to small business > idrive.com - Online backup > heart.org - american heart association > onlineproviderservices.com - Looks like an outsourced group that handles > medicare > landstar.com - trucking company > > I am working on trying to contact the companies above, but I have started > resorting to public shaming on social media. Not an ideal solution. > > My thought, could I be missing something? Perhaps I need to add a specfic > entry in the IRR or anything? Just seems like a lot of sites will not > accept my traffic. > > Any experts like to chime in? > > John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshank at cymru.com Wed Mar 20 18:05:11 2019 From: jshank at cymru.com (James Shank) Date: Wed, 20 Mar 2019 14:05:11 -0400 Subject: well-known Anycast prefixes In-Reply-To: <062A7841-A157-4CCA-9CA6-2F3C244D5632@pch.net> References: <98053e99-687d-bc4c-cbd8-956b70a339ce@init7.net> <6632F2F0-F715-437B-8DCB-B86850FEE329@pch.net> <5adb6997-f77a-f46a-18af-bf468c0d9712@geier.ne.tz> <062A7841-A157-4CCA-9CA6-2F3C244D5632@pch.net> Message-ID: <20182282-74de-9964-0d15-54ef7518074c@cymru.com> On 3/19/19 5:03 PM, Bill Woodcock wrote: > > >> On Mar 19, 2019, at 1:55 PM, Frank Habicht wrote: >> >> Hi, >> >> On 19/03/2019 23:13, Bill Woodcock wrote: >>> Generally, static lists like that are difficult to maintain when >>> they’re tracking multiple routes from multiple parties. >> >> agreed. >> and on the other extreme, communities are very much prone to abuse. >> I guess I could set any community on a number of prefixes (incl anycast) >> right now.... >> >> So, I think a (moderated) BGP feed of prefixes a'la bogon from a trusted >> {cymru[1], pch[2], ...} could be good [3]. > > Ok, so, just trying to flesh out the idea to something that can be usefully implemented… > > 1) People send an eBGP multi-hop feed of well-known-community routes to a collector, or send them over normal peering sessions to something that aggregates… > > 2) Because those are over BGP sessions, the counterparty is known, and can be asked for details or clarification by the “moderator,” or the sender could log in to an interface to add notes about the prefixes, as they would in the IXPdir or PeeringDB. > > 3) Known prefixes from known parties would be passed through in real-time, as they were withdrawn and restored. > > 4) New prefixes from known parties would be passed through in real-time if they weren’t unusual (large/overlapping something else/previously announced by other ASNs). > > 5) New prefixes from known parties would be “moderated” if they were unusual. > > 6) New prefixes from new parties would be “moderated” to establish that they were legit and that there was some documentation explaining what they were. > > 7) For anyone who really didn’t want to provide a community-tagged BGP feed, a manual submission process would exist. > > 8) Everything gets published as a real-time eBGP feed. > > 9) Everything gets published as HTTPS-downloadable JSON. > > 10) Everything gets published as a human-readable (and crawler-indexable) web page. > > Does that sound about right? > > -Bill Hi, Interesting discussion and ideas. I like how you've laid it out above, Bill. I'm not clear on the use cases, though. What are the imagined use cases? It might make sense to solve 'a method to request hot potato routing' as a separate problem. (Along the lines of Damian's point.) Thanks! James -- James Shank Senior Technical Advisor; Team Cymru, Inc. jshank at cymru.com; +1-847-378-3365; http://www.team-cymru.com/ From bradley at wifastnetworks.com Wed Mar 20 18:28:27 2019 From: bradley at wifastnetworks.com (Bradley Burch) Date: Wed, 20 Mar 2019 14:28:27 -0400 Subject: Amazon Prime video NOC contact In-Reply-To: References: <71c140ab6e1a36c64b4a209457e7394f@wt-tech.it> Message-ID: <699B7FC2-BF8C-41ED-90E4-571725C9BF43@wifastnetworks.com> I have had no luck from that forum. Davide, I will contact you off list. > On Mar 20, 2019, at 2:16 PM, William Herrin wrote: > >> On Wed, Mar 20, 2019 at 11:03 AM Davide Gelardi wrote: > >> we are an italian ISP/WISP and we are experiecing trouble with Amazon >> Prime Video. They blocked our customers that cannot view the video. The >> error says that our IP class is located ouside italy. But this is wrong. >> >> Have you a contact we can get in touch with? > > Hi Davide, > > You may have some luck here: https://www.amazonforum.com/forums/digital-content/prime-video > > Amazon staff working on Prime Video monitor and respond on that forum. The individuals reading may not be the right people, but they'll likely be on a first name basis with someone who is. > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From geier at geier.ne.tz Thu Mar 21 15:59:18 2019 From: geier at geier.ne.tz (Frank Habicht) Date: Thu, 21 Mar 2019 18:59:18 +0300 Subject: well-known Anycast prefixes In-Reply-To: <20182282-74de-9964-0d15-54ef7518074c@cymru.com> References: <98053e99-687d-bc4c-cbd8-956b70a339ce@init7.net> <6632F2F0-F715-437B-8DCB-B86850FEE329@pch.net> <5adb6997-f77a-f46a-18af-bf468c0d9712@geier.ne.tz> <062A7841-A157-4CCA-9CA6-2F3C244D5632@pch.net> <20182282-74de-9964-0d15-54ef7518074c@cymru.com> Message-ID: <68dd762c-0d38-64ef-4c86-3b60c7b46941@geier.ne.tz> Hi James, On 20/03/2019 21:05, James Shank wrote: > I'm not clear on the use cases, though. What are the imagined use cases? > > It might make sense to solve 'a method to request hot potato routing' > as a separate problem. (Along the lines of Damian's point.) my personal reason/motivation is this: Years ago I noticed that my traffic to the "I" DNS root server was traversing 4 continents. That's from Tanzania, East Africa. Not having a local instance (back then), we naturally sent the traffic to an upstream. That upstream happens to be in that club of those who don't have transit providers (which probably doesn't really matter, but means a "global" network). My Theory : So just because one I-root instance was hosted at a customer (or customer's customer), that got higher local-pref and now packets take the long way from Africa via Europe, NorthAmerica to Asia and that customer in Thailand. While closer I-root instances would obviously be along the way, just not from a paying customer, "only" from peering. I don't know whether or not to blame that "carrier" for intentionally(?) carrying the traffic that far - presumably the $ they got for that from the I-root host in Thailand was worth it, and not enough customers complained enough about the latency? But I think it would be worthwhile to give them an option and produce a mechanism of knowing what's anycasted. Maybe (thinking of it) a solution for really well-known prefixes available at many instances/locations (like DNS root) would be to have their fixed set of direct transits at all the "global" nodes and everywhere else to tell peers to not advertise this to upstreams. Greetings, Frank From job at ntt.net Thu Mar 21 16:30:04 2019 From: job at ntt.net (Job Snijders) Date: Thu, 21 Mar 2019 17:30:04 +0100 Subject: well-known Anycast prefixes In-Reply-To: <68dd762c-0d38-64ef-4c86-3b60c7b46941@geier.ne.tz> References: <98053e99-687d-bc4c-cbd8-956b70a339ce@init7.net> <6632F2F0-F715-437B-8DCB-B86850FEE329@pch.net> <5adb6997-f77a-f46a-18af-bf468c0d9712@geier.ne.tz> <062A7841-A157-4CCA-9CA6-2F3C244D5632@pch.net> <20182282-74de-9964-0d15-54ef7518074c@cymru.com> <68dd762c-0d38-64ef-4c86-3b60c7b46941@geier.ne.tz> Message-ID: <20190321163004.GH25417@hanna.meerval.net> On Thu, Mar 21, 2019 at 06:59:18PM +0300, Frank Habicht wrote: > On 20/03/2019 21:05, James Shank wrote: > > I'm not clear on the use cases, though. What are the imagined use cases? > > > > It might make sense to solve 'a method to request hot potato routing' > > as a separate problem. (Along the lines of Damian's point.) > > my personal reason/motivation is this: > Years ago I noticed that my traffic to the "I" DNS root server was > traversing 4 continents. That's from Tanzania, East Africa. > Not having a local instance (back then), we naturally sent the traffic > to an upstream. That upstream happens to be in that club of those who > don't have transit providers (which probably doesn't really matter, but > means a "global" network). Luckily there are other root servers too! :) > My Theory : > So just because one I-root instance was hosted at a customer (or > customer's customer), that got higher local-pref and now packets take > the long way from Africa via Europe, NorthAmerica to Asia and that > customer in Thailand. While closer I-root instances would obviously be > along the way, just not from a paying customer, "only" from peering. > > I don't know whether or not to blame that "carrier" for intentionally(?) > carrying the traffic that far - presumably the $ they got for that from > the I-root host in Thailand was worth it, and not enough customers > complained enough about the latency? > > But I think it would be worthwhile to give them an option and produce a > mechanism of knowing what's anycasted. > > Maybe (thinking of it) a solution for really well-known prefixes > available at many instances/locations (like DNS root) would be to have > their fixed set of direct transits at all the "global" nodes and > everywhere else to tell peers to not advertise this to upstreams. In all instances of what you mention you need cooperation from the network which is routing in a (from your perspective) suboptimal way. Either the customer of that upstream should use BGP communities to localize the announcement, or the upstream themselves need to change their routing policy to set 'same LOCAL_PREF everywhere' for some prefixes. Of course any input channel into routing policy can be a vector of abuse. Even if you equalize the LOCAL_PREF attribute across your network edge, you still have other tie breakers such as AS_PATH length. It is not clear to me how a list of well-known anycast addresses, in practise, would help swing the pendulum. In all cases you need cooperation from a lot of networks, and the outcome is not clearly defined because we don't have a true inter-domain 'shortest latency path' metric. Kind regards, Job From bryan at shout.net Thu Mar 21 16:31:53 2019 From: bryan at shout.net (Bryan Holloway) Date: Thu, 21 Mar 2019 11:31:53 -0500 Subject: well-known Anycast prefixes In-Reply-To: <68dd762c-0d38-64ef-4c86-3b60c7b46941@geier.ne.tz> References: <98053e99-687d-bc4c-cbd8-956b70a339ce@init7.net> <6632F2F0-F715-437B-8DCB-B86850FEE329@pch.net> <5adb6997-f77a-f46a-18af-bf468c0d9712@geier.ne.tz> <062A7841-A157-4CCA-9CA6-2F3C244D5632@pch.net> <20182282-74de-9964-0d15-54ef7518074c@cymru.com> <68dd762c-0d38-64ef-4c86-3b60c7b46941@geier.ne.tz> Message-ID: On 3/21/19 10:59 AM, Frank Habicht wrote: > Hi James, > > On 20/03/2019 21:05, James Shank wrote: >> I'm not clear on the use cases, though. What are the imagined use cases? >> >> It might make sense to solve 'a method to request hot potato routing' >> as a separate problem. (Along the lines of Damian's point.) > > my personal reason/motivation is this: > Years ago I noticed that my traffic to the "I" DNS root server was > traversing 4 continents. That's from Tanzania, East Africa. > Not having a local instance (back then), we naturally sent the traffic > to an upstream. That upstream happens to be in that club of those who > don't have transit providers (which probably doesn't really matter, but > means a "global" network). /snip > Greetings, > Frank > I can think of another ... We rate-limit DNS from unknown quantities for reasons that should be obvious. We white-list traffic from known trusted (anycast) ones to prevent a DDoS attack from throttling legitimate queries. This would be a useful way to help auto-generate those ACLs. From ross at tajvar.io Thu Mar 21 16:52:27 2019 From: ross at tajvar.io (Ross Tajvar) Date: Thu, 21 Mar 2019 12:52:27 -0400 Subject: well-known Anycast prefixes In-Reply-To: References: <98053e99-687d-bc4c-cbd8-956b70a339ce@init7.net> <6632F2F0-F715-437B-8DCB-B86850FEE329@pch.net> <5adb6997-f77a-f46a-18af-bf468c0d9712@geier.ne.tz> <062A7841-A157-4CCA-9CA6-2F3C244D5632@pch.net> <20182282-74de-9964-0d15-54ef7518074c@cymru.com> <68dd762c-0d38-64ef-4c86-3b60c7b46941@geier.ne.tz> Message-ID: Not all any-casted prefixes are DNS resolvers and not all DNS resolvers are anycasted. It sounds like you would be better served by a list of well-known DNS resolvers. On Thu, Mar 21, 2019 at 12:35 PM Bryan Holloway wrote: > > On 3/21/19 10:59 AM, Frank Habicht wrote: > > Hi James, > > > > On 20/03/2019 21:05, James Shank wrote: > >> I'm not clear on the use cases, though. What are the imagined use > cases? > >> > >> It might make sense to solve 'a method to request hot potato routing' > >> as a separate problem. (Along the lines of Damian's point.) > > > > my personal reason/motivation is this: > > Years ago I noticed that my traffic to the "I" DNS root server was > > traversing 4 continents. That's from Tanzania, East Africa. > > Not having a local instance (back then), we naturally sent the traffic > > to an upstream. That upstream happens to be in that club of those who > > don't have transit providers (which probably doesn't really matter, but > > means a "global" network). > > /snip > > > Greetings, > > Frank > > > > I can think of another ... > > We rate-limit DNS from unknown quantities for reasons that should be > obvious. We white-list traffic from known trusted (anycast) ones to > prevent a DDoS attack from throttling legitimate queries. This would be > a useful way to help auto-generate those ACLs. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at shout.net Thu Mar 21 17:39:01 2019 From: bryan at shout.net (Bryan Holloway) Date: Thu, 21 Mar 2019 12:39:01 -0500 Subject: well-known Anycast prefixes In-Reply-To: References: <98053e99-687d-bc4c-cbd8-956b70a339ce@init7.net> <6632F2F0-F715-437B-8DCB-B86850FEE329@pch.net> <5adb6997-f77a-f46a-18af-bf468c0d9712@geier.ne.tz> <062A7841-A157-4CCA-9CA6-2F3C244D5632@pch.net> <20182282-74de-9964-0d15-54ef7518074c@cymru.com> <68dd762c-0d38-64ef-4c86-3b60c7b46941@geier.ne.tz> Message-ID: <7332504c-4747-7d75-e755-92ce3a699084@shout.net> On 3/21/19 11:52 AM, Ross Tajvar wrote: > Not all any-casted prefixes are DNS resolvers and not all DNS resolvers > are anycasted. It sounds like you would be better served by a list of > well-known DNS resolvers. True on both counts, and that's why I said "help". > On Thu, Mar 21, 2019 at 12:35 PM Bryan Holloway > wrote: > > > On 3/21/19 10:59 AM, Frank Habicht wrote: > > Hi James, > > > > On 20/03/2019 21:05, James Shank wrote: > >> I'm not clear on the use cases, though.  What are the imagined > use cases? > >> > >> It might make sense to solve 'a method to request hot potato > routing' > >> as a separate problem.  (Along the lines of Damian's point.) > > > > my personal reason/motivation is this: > > Years ago I noticed that my traffic to the "I" DNS root server was > > traversing 4 continents. That's from Tanzania, East Africa. > > Not having a local instance (back then), we naturally sent the > traffic > > to an upstream. That upstream happens to be in that club of those who > > don't have transit providers (which probably doesn't really > matter, but > > means a "global" network). > > /snip > > > Greetings, > > Frank > > > > I can think of another ... > > We rate-limit DNS from unknown quantities for reasons that should be > obvious. We white-list traffic from known trusted (anycast) ones to > prevent a DDoS attack from throttling legitimate queries. This would be > a useful way to help auto-generate those ACLs. > From bpierce at consolidated.coop Thu Mar 21 16:13:58 2019 From: bpierce at consolidated.coop (Brian Pierce) Date: Thu, 21 Mar 2019 16:13:58 +0000 Subject: Amazon Prime video NOC contact In-Reply-To: <699B7FC2-BF8C-41ED-90E4-571725C9BF43@wifastnetworks.com> References: <71c140ab6e1a36c64b4a209457e7394f@wt-tech.it> <699B7FC2-BF8C-41ED-90E4-571725C9BF43@wifastnetworks.com> Message-ID: Bradley & Davide, I work for an ISP located in central Ohio and we’re experiencing the a similar issue with a newly acquired IP Block, it’s flagged as a VPN/Proxy. I’ve not had any success trying their forums or trying to climb through their customer service ladder to hope someone knowledgeable receives my ticket. Bradley, if you have any contact info I would greatly appreciate a message off list. Davide, if you are able to resolve this issue, please advise how you were able to do so. From: NANOG On Behalf Of Bradley Burch Sent: Wednesday, March 20, 2019 2:28 PM To: William Herrin Cc: nanog at nanog.org; davide.gelardi at wt-tech.it Subject: Re: Amazon Prime video NOC contact ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails. I have had no luck from that forum. Davide, I will contact you off list. On Mar 20, 2019, at 2:16 PM, William Herrin > wrote: On Wed, Mar 20, 2019 at 11:03 AM Davide Gelardi > wrote: we are an italian ISP/WISP and we are experiecing trouble with Amazon Prime Video. They blocked our customers that cannot view the video. The error says that our IP class is located ouside italy. But this is wrong. Have you a contact we can get in touch with? Hi Davide, You may have some luck here: https://www.amazonforum.com/forums/digital-content/prime-video Amazon staff working on Prime Video monitor and respond on that forum. The individuals reading may not be the right people, but they'll likely be on a first name basis with someone who is. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From amitchell at isipp.com Thu Mar 21 18:20:25 2019 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Thu, 21 Mar 2019 12:20:25 -0600 Subject: Amazon Prime video NOC contact In-Reply-To: References: <71c140ab6e1a36c64b4a209457e7394f@wt-tech.it> <699B7FC2-BF8C-41ED-90E4-571725C9BF43@wifastnetworks.com> Message-ID: May I have (at least some of) your permission to put this in front of someone at AMZ? Anne Anne P. Mitchell, Attorney at Law GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant CEO/President, Institute for Social Internet Public Policy Board of Directors, Denver Internet Exchange Board of Directors, Asilomar Microcomputer Workshop Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center California Bar Association Cal. Bar Cyberspace Law Committee Colorado Cyber Committee Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop > On Mar 21, 2019, at 10:13 AM, Brian Pierce wrote: > > Bradley & Davide, > > I work for an ISP located in central Ohio and we’re experiencing the a similar issue with a newly acquired IP Block, it’s flagged as a VPN/Proxy. > I’ve not had any success trying their forums or trying to climb through their customer service ladder to hope someone knowledgeable receives my ticket. > Bradley, if you have any contact info I would greatly appreciate a message off list. > Davide, if you are able to resolve this issue, please advise how you were able to do so. > > From: NANOG On Behalf Of Bradley Burch > Sent: Wednesday, March 20, 2019 2:28 PM > To: William Herrin > Cc: nanog at nanog.org; davide.gelardi at wt-tech.it > Subject: Re: Amazon Prime video NOC contact > > ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails. > > I have had no luck from that forum. > Davide, I will contact you off list. > > > > On Mar 20, 2019, at 2:16 PM, William Herrin wrote: > > On Wed, Mar 20, 2019 at 11:03 AM Davide Gelardi wrote: > we are an italian ISP/WISP and we are experiecing trouble with Amazon > Prime Video. They blocked our customers that cannot view the video. The > error says that our IP class is located ouside italy. But this is wrong. > > Have you a contact we can get in touch with? > > Hi Davide, > > You may have some luck here: https://www.amazonforum.com/forums/digital-content/prime-video > > Amazon staff working on Prime Video monitor and respond on that forum. The individuals reading may not be the right people, but they'll likely be on a first name basis with someone who is. > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: From woody at pch.net Thu Mar 21 18:51:44 2019 From: woody at pch.net (Bill Woodcock) Date: Thu, 21 Mar 2019 11:51:44 -0700 Subject: well-known Anycast prefixes In-Reply-To: References: <98053e99-687d-bc4c-cbd8-956b70a339ce@init7.net> <6632F2F0-F715-437B-8DCB-B86850FEE329@pch.net> <5adb6997-f77a-f46a-18af-bf468c0d9712@geier.ne.tz> <062A7841-A157-4CCA-9CA6-2F3C244D5632@pch.net> <20182282-74de-9964-0d15-54ef7518074c@cymru.com> <68dd762c-0d38-64ef-4c86-3b60c7b46941@geier.ne.tz> Message-ID: <5D2838BE-2254-4A45-84FA-C81CDA86D18C@pch.net> I imagine that the “description” of each entry in the list should include a machine-readable field indicating the use. There was a question about the use-case... I’m sure a lot of people in the ops community have their own reasons related to routing and filtering and so forth, but there’s also a huge demand for this kind of information, aggregated and sanity-checked, to support academic research at the graduate level. And the better we support those kids with real-world data, the more practical an education they receive, and the more ready they are to jump in to jobs we offer them in industry when they graduate. Supporting kids and networking graduate programs like that is a big part of our work, that tends not to be visible on the operations side. Academics downloaded routing-archive snapshots from us nearly 300 million times, last year, for example. -Bill > On Mar 21, 2019, at 09:52, Ross Tajvar wrote: > > Not all any-casted prefixes are DNS resolvers and not all DNS resolvers are anycasted. It sounds like you would be better served by a list of well-known DNS resolvers. > >> On Thu, Mar 21, 2019 at 12:35 PM Bryan Holloway wrote: >> >> On 3/21/19 10:59 AM, Frank Habicht wrote: >> > Hi James, >> > >> > On 20/03/2019 21:05, James Shank wrote: >> >> I'm not clear on the use cases, though. What are the imagined use cases? >> >> >> >> It might make sense to solve 'a method to request hot potato routing' >> >> as a separate problem. (Along the lines of Damian's point.) >> > >> > my personal reason/motivation is this: >> > Years ago I noticed that my traffic to the "I" DNS root server was >> > traversing 4 continents. That's from Tanzania, East Africa. >> > Not having a local instance (back then), we naturally sent the traffic >> > to an upstream. That upstream happens to be in that club of those who >> > don't have transit providers (which probably doesn't really matter, but >> > means a "global" network). >> >> /snip >> >> > Greetings, >> > Frank >> > >> >> I can think of another ... >> >> We rate-limit DNS from unknown quantities for reasons that should be >> obvious. We white-list traffic from known trusted (anycast) ones to >> prevent a DDoS attack from throttling legitimate queries. This would be >> a useful way to help auto-generate those ACLs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at alcock.org Thu Mar 21 19:39:43 2019 From: john at alcock.org (John Alcock) Date: Thu, 21 Mar 2019 15:39:43 -0400 Subject: softlayer.com In-Reply-To: References: Message-ID: Still looking for anyone from softlayer.com It has been a challenge. Anything hosted by softlayer.com is being blocked. Here is a small list so far windowbook.tpondemand.com ahainstructornetwork.americanheart.org clover.com Cebroker.com Softlayer.com indeed.com & Enforce Staffing It is growing every day. John On Wed, Mar 20, 2019 at 12:35 PM John Alcock wrote: > Afternoon, > > Thought I would start a new thread. After researching, traceroutes, etc, > I think I found my problem. > > 9 out of the 10 sites that subscribers on my new block is being hosted by > softlayer. > > Anyone on the list have contacts with softlayer. Right now I have an > email to abuse. The support line will not help me out. > > John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Thu Mar 21 22:55:35 2019 From: sean at donelan.com (Sean Donelan) Date: Thu, 21 Mar 2019 18:55:35 -0400 (EDT) Subject: Comcast: Xfinity Flex - No emergency alerts for cordcutters Message-ID: In advance of Apple TV's big announcement next week, other folks are announcing their new streaming TV boxes. Comcast announced Xfinity Flex today, a video streaming box. Xfinity Flex looks and acts like a set-top box, but uses Internet, so it avoids all those pesky cable TV rules. But emergency alerts aren't mentioned, even in the fine print at the bottom of the page. I expect there are none. I still hope a reporter asks Apple about emergency alerts at its big event on Monday. Apple TV streaming may be awesome, as that tornado destroys your mobile trailer park. From andrew at paolucci.ca Fri Mar 22 01:07:35 2019 From: andrew at paolucci.ca (andrew at paolucci.ca) Date: Fri, 22 Mar 2019 01:07:35 +0000 Subject: softlayer.com In-Reply-To: References: Message-ID: SoftLayer was aquirred by IBM, maybe reaching out to their NOC or support would be fruitful. IBM's DNS team is indeed mentioned in SoftLayers WHOIS info. Have you attempted email the addresses listed in the WHOIS for their ASN? network:Tech-Contact;I: sysadmins at softlayer.com network:Abuse-Contact;I: abuse at softlayer.com network:Updated-By: ipadmin at softlayer.com Registrant Contact Registrant Name Domain Administrator Registrant Organization Softlayer Technologies, Inc. Registrant Street 4849 Alpha Road Registrant City Dallas Registrant State/Province TX Registrant Postal Code 75244 Registrant Country USUnited States Registrant Phone +1.2144420600 Registrant Email bjohnson at softlayer.com Administrative Contact Admin Name Grace Micewicz Admin Organization International Business Machines Corporation Admin Street New Orchard Road Admin City Armonk Admin State/Province NY Admin Postal Code 10504 Admin Country USUnited States Admin Phone +1.9147654227 Admin Fax +1.9147654370 Admin Email dnsadm at us.ibm.com Regards. Andrew Paolucci ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, March 21, 2019 3:39 PM, John Alcock wrote: > Still looking for anyone from softlayer.com > > It has been a challenge. Anything hosted by softlayer.com is being blocked. > > Here is a small list so far > > windowbook.tpondemand.com > ahainstructornetwork.americanheart.org > clover.com > Cebroker.com > Softlayer.com > indeed.com & Enforce Staffing > > It is growing every day. > > John > > On Wed, Mar 20, 2019 at 12:35 PM John Alcock wrote: > >> Afternoon, >> >> Thought I would start a new thread. After researching, traceroutes, etc, I think I found my problem. >> >> 9 out of the 10 sites that subscribers on my new block is being hosted by softlayer. >> >> Anyone on the list have contacts with softlayer. Right now I have an email to abuse. The support line will not help me out. >> >> John -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Fri Mar 22 12:06:26 2019 From: jcurran at arin.net (John Curran) Date: Fri, 22 Mar 2019 12:06:26 +0000 Subject: "Under the hood" at ARIN (was: ARIN upgrade completed) In-Reply-To: <820D123B-B6F7-44F8-B05F-FBF835A3A447@arin.net> References: <1a0b2307-33c9-4592-1524-bdb97d198bd2@arin.net> <835BE060-54F4-47D0-A0A2-1BA1D8AD1E71@arin.net> <820D123B-B6F7-44F8-B05F-FBF835A3A447@arin.net> Message-ID: And for those looking into a little insight "under the hood" of the new ARIN Online system & website, Andy Newton wrote a short blog that highlights some of the architecture and framework decisions we made – https://teamarin.net/2019/03/19/under-the-hood-of-the-new-arin-net/ FYI, /John John Curran President and CEO American Registry for Internet Numbers On 2 Mar 2019, at 4:14 PM, John Curran > wrote: Folks - The upgrade to www.arin.net and the ARIN Online system has been completed as scheduled. Release notes are online here: https://www.arin.net/announcements/20190302/ Best wishes, /John John Curran President and CEO American Registry for Internet Numbers -------------- next part -------------- An HTML attachment was scrubbed... URL: From brak at gameservers.com Fri Mar 22 12:49:23 2019 From: brak at gameservers.com (Brian Rak) Date: Fri, 22 Mar 2019 08:49:23 -0400 Subject: softlayer.com In-Reply-To: References: Message-ID: I've been trying to reach them regarding an abuse issue, and have similarly had no actual luck in reaching their abuse/noc contacts. On 3/21/2019 9:07 PM, andrew at paolucci.ca wrote: > SoftLayer was aquirred by IBM, maybe reaching out to their NOC or > support would be fruitful. IBM's DNS team is indeed mentioned in > SoftLayers WHOIS info. > > Have you attempted email the addresses listed in the WHOIS for their ASN? > > network:Tech-Contact;I:sysadmins at softlayer.com > network:Abuse-Contact;I:abuse at softlayer.com > network:Updated-By:ipadmin at softlayer.com > > *Registrant Contact* > Registrant Name > Domain Administrator > Registrant Organization > Softlayer Technologies, Inc. > Registrant Street > 4849 Alpha Road > Registrant City > Dallas > Registrant State/Province > TX > Registrant Postal Code > 75244 > Registrant Country > USUnited States > Registrant Phone > +1.2144420600 > Registrant Email > bjohnson at softlayer.com > > *Administrative Contact* > Admin Name > Grace Micewicz > Admin Organization > International Business Machines Corporation > Admin Street > New Orchard Road > Admin City > Armonk > Admin State/Province > NY > Admin Postal Code > 10504 > Admin Country > USUnited States > Admin Phone > +1.9147654227 > Admin Fax > +1.9147654370 > Admin Email > dnsadm at us.ibm.com > > > Regards. > Andrew Paolucci > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Thursday, March 21, 2019 3:39 PM, John Alcock wrote: > >> Still looking for anyone from softlayer.com >> >> It has been a challenge.  Anything hosted by softlayer.com >> is being blocked. >> >> Here is a small list so far >> >> windowbook.tpondemand.com >> ahainstructornetwork.americanheart.org >> >> clover.com >> Cebroker.com >> Softlayer.com >> indeed.com & Enforce Staffing >> >> It is growing every day. >> >> John >> >> >> On Wed, Mar 20, 2019 at 12:35 PM John Alcock > > wrote: >> >> Afternoon, >> >> Thought I would start a new thread.  After researching, >> traceroutes, etc, I think I found my problem. >> >> 9 out of the 10 sites that subscribers on my new block is being >> hosted by softlayer. >> >> Anyone on the list have contacts with softlayer. Right now I have >> an email to abuse.  The support line will not help me out. >> >> John >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dvandyk at akamai.com Fri Mar 22 13:50:32 2019 From: dvandyk at akamai.com (Van Dyk, Donovan) Date: Fri, 22 Mar 2019 13:50:32 +0000 Subject: XO trace route request | Netherlands Message-ID: Hello all, If there's someone out there on XO's network, preferably in the Netherlands area, could you send me a traceroute to the following IP: 164.140.35.37 XO's Looking Glass seems to be broken. The BGP throws up an invalid error on the syntax error for its own input. Pings/ traceroutes come back with an empty display, Im guessing since it can’t reach the endpoint. I would hope the traceroute path would still show… Off-list is fine .. Thanks -- Donovan Van Dyk Platform Operations Engineer Fort Lauderdale, FL USA [id:9A68E9F7-1C69-4FEA-A38A-3B3754E954E2] The information contained in this electronic mail transmission and its attachments may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient (or an individual responsible for delivery of the message to such person), you are strictly prohibited from copying, disseminating or distributing this communication. If you have received this communication in error, please notify the sender immediately and destroy all electronic, paper or other versions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at packetflux.com Fri Mar 22 13:53:32 2019 From: lists at packetflux.com (Forrest Christian (List Account)) Date: Fri, 22 Mar 2019 09:53:32 -0400 Subject: softlayer.com In-Reply-To: References: Message-ID: Another idea... Have you tried reaching out to some of the blocked sites? They likely have better contact information than is available publicly, especially a larger one like indeed. On Thu, Mar 21, 2019, 3:41 PM John Alcock wrote: > Still looking for anyone from softlayer.com > > It has been a challenge. Anything hosted by softlayer.com is being > blocked. > > Here is a small list so far > > windowbook.tpondemand.com > ahainstructornetwork.americanheart.org > clover.com > Cebroker.com > Softlayer.com > indeed.com & Enforce Staffing > > It is growing every day. > > John > > > > > > > > > > > > > > > > > > On Wed, Mar 20, 2019 at 12:35 PM John Alcock wrote: > >> Afternoon, >> >> Thought I would start a new thread. After researching, traceroutes, etc, >> I think I found my problem. >> >> 9 out of the 10 sites that subscribers on my new block is being hosted by >> softlayer. >> >> Anyone on the list have contacts with softlayer. Right now I have an >> email to abuse. The support line will not help me out. >> >> John >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nik at neko.id.au Fri Mar 22 14:10:14 2019 From: nik at neko.id.au (Nikolas Geyer) Date: Fri, 22 Mar 2019 14:10:14 +0000 Subject: softlayer.com In-Reply-To: References: , Message-ID: <6015A8EB-2D06-4008-87BB-5517B1D622F8@neko.id.au> This is the best approach. Have run into this problem a few times and had zero success getting the filters removed without having SL customers log tickets with support. Verbiage needs to be “this prefix is blocked, please escalate to your backbone team”. Sent from my iPhone On Mar 22, 2019, at 9:56 AM, Forrest Christian (List Account) > wrote: Another idea... Have you tried reaching out to some of the blocked sites? They likely have better contact information than is available publicly, especially a larger one like indeed. On Thu, Mar 21, 2019, 3:41 PM John Alcock > wrote: Still looking for anyone from softlayer.com It has been a challenge. Anything hosted by softlayer.com is being blocked. Here is a small list so far windowbook.tpondemand.com ahainstructornetwork.americanheart.org clover.com Cebroker.com Softlayer.com indeed.com & Enforce Staffing It is growing every day. John On Wed, Mar 20, 2019 at 12:35 PM John Alcock > wrote: Afternoon, Thought I would start a new thread. After researching, traceroutes, etc, I think I found my problem. 9 out of the 10 sites that subscribers on my new block is being hosted by softlayer. Anyone on the list have contacts with softlayer. Right now I have an email to abuse. The support line will not help me out. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From aveline at misaka.io Fri Mar 22 14:22:18 2019 From: aveline at misaka.io (Siyuan Miao) Date: Fri, 22 Mar 2019 22:22:18 +0800 Subject: softlayer.com In-Reply-To: <6015A8EB-2D06-4008-87BB-5517B1D622F8@neko.id.au> References: <6015A8EB-2D06-4008-87BB-5517B1D622F8@neko.id.au> Message-ID: Perhaps it won't work because their customer support will ask you for bi-directional traceroute and refused to forward to backbone team. Then they'll say it's not their fault and you can see the packet is dropped outside our network. Here's a sample traceroute from SoftLayer Washington, San Jose and Seattle in case someone needs it: aveline at iad02-sl01:~$ mtr 138.43.128.1 --report-wide Start: Fri Mar 22 17:20:42 2019 HOST: iad02-sl01 Loss% Snt Last Avg Best Wrst StDev 1.|-- [REDACTED] 0.0% 10 1.4 1.5 0.8 3.7 1.0 2.|-- ae13.dar02.wdc01.networklayer.com 0.0% 10 0.5 3.3 0.4 28.6 8.8 3.|-- ae9.bbr01.eq01.wdc02.networklayer.com 0.0% 10 0.8 0.8 0.7 1.0 0.0 4.|-- eqix-dc5.intellifiber.com 0.0% 10 0.8 1.2 0.8 2.2 0.3 5.|-- ae13-0.cr02.asbn01-va.us.windstream.net 0.0% 10 0.9 0.9 0.9 1.0 0.0 6.|-- ae11-0.cr01.atln02-ga.us.windstream.net 0.0% 10 15.6 16.1 15.6 17.4 0.5 7.|-- ae0-0.pe06.atln02-ga.us.windstream.net 0.0% 10 17.4 16.1 15.9 17.4 0.3 8.|-- h43.88.198.64.static.ip.windstream.net 0.0% 10 24.7 24.8 24.6 24.9 0.0 9.|-- east.tndodge-21.static.tncsvl.blomand.net 0.0% 10 22.6 22.8 22.5 23.8 0.0 10.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 aveline at sjc03-sl01:~$ mtr 138.43.128.1 --report-wide Start: Fri Mar 22 16:21:04 2019 HOST: sjc03-sl01 Loss% Snt Last Avg Best Wrst StDev 1.|-- [REDACTED] 0.0% 10 2.4 2.0 0.3 14.3 4.3 2.|-- ae0.dar02.sjc01.networklayer.com 0.0% 10 1.0 0.5 0.3 1.3 0.0 3.|-- ae9.bbr01.eq01.sjc02.networklayer.com 0.0% 10 0.8 0.8 0.7 0.9 0.0 4.|-- eqix-sv1.windstream.com 0.0% 10 0.9 0.9 0.8 1.1 0.0 5.|-- ae6-0.cr02.lsaj01-ca.us.windstream.net 0.0% 10 11.6 11.5 11.5 11.6 0.0 6.|-- ae-11-0.cr01.dlls01-tx.us.windstream.net 0.0% 10 42.6 42.7 42.5 43.4 0.0 7.|-- ae7-0.cr02.atln02-ga.us.windstream.net 0.0% 10 64.0 65.6 63.9 74.2 3.4 8.|-- ae1-0.pe06.atln02-ga.us.windstream.net 0.0% 10 62.3 62.7 62.2 66.9 1.5 9.|-- h43.88.198.64.static.ip.windstream.net 0.0% 10 71.9 72.0 71.9 72.2 0.0 10.|-- east.tndodge-21.static.tncsvl.blomand.net 0.0% 10 69.9 68.8 68.6 69.9 0.3 11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 aveline at sea04-sl01:~$ mtr 138.43.128.1 --report-wide Start: Fri Mar 22 08:19:09 2019 HOST: sea04-sl01 Loss% Snt Last Avg Best Wrst StDev 1.|-- [REDACTED] 0.0% 10 0.7 1.2 0.7 1.8 0.0 2.|-- ae12.dar02.sr01.sea01.networklayer.com 0.0% 10 0.6 0.7 0.5 1.3 0.0 3.|-- ae9.bbr01.wb01.sea02.networklayer.com 0.0% 10 1.2 1.0 0.7 1.5 0.0 4.|-- six.seattle-wa.us.windstream.net 0.0% 10 1.5 1.0 0.7 1.7 0.0 5.|-- ae12-0.cr01.chcg01-il.us.windstream.net 0.0% 10 41.1 41.2 41.0 41.6 0.0 6.|-- ae17-0.cr02.chcg01-il.us.windstream.net 0.0% 10 41.1 41.4 41.1 42.0 0.0 7.|-- ae10-0.cr01.atln02-ga.us.windstream.net 0.0% 10 63.8 64.4 63.5 71.1 2.3 8.|-- ae0-0.pe06.atln02-ga.us.windstream.net 0.0% 10 63.7 63.7 63.5 64.0 0.0 9.|-- h43.88.198.64.static.ip.windstream.net 0.0% 10 71.6 71.8 71.5 72.8 0.0 10.|-- east.tndodge-21.static.tncsvl.blomand.net 0.0% 10 71.8 70.8 70.2 71.8 0.3 11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 Regards, Siyuan Miao On Fri, Mar 22, 2019 at 10:10 PM Nikolas Geyer wrote: > This is the best approach. Have run into this problem a few times and had > zero success getting the filters removed without having SL customers log > tickets with support. Verbiage needs to be “this prefix is blocked, please > escalate to your backbone team”. > > Sent from my iPhone > > On Mar 22, 2019, at 9:56 AM, Forrest Christian (List Account) < > lists at packetflux.com> wrote: > > Another idea... > > Have you tried reaching out to some of the blocked sites? They likely > have better contact information than is available publicly, especially a > larger one like indeed. > > On Thu, Mar 21, 2019, 3:41 PM John Alcock wrote: > >> Still looking for anyone from softlayer.com >> >> It has been a challenge. Anything hosted by softlayer.com is being >> blocked. >> >> Here is a small list so far >> >> windowbook.tpondemand.com >> ahainstructornetwork.americanheart.org >> clover.com >> Cebroker.com >> Softlayer.com >> indeed.com & Enforce Staffing >> >> It is growing every day. >> >> John >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Mar 20, 2019 at 12:35 PM John Alcock wrote: >> >>> Afternoon, >>> >>> Thought I would start a new thread. After researching, traceroutes, >>> etc, I think I found my problem. >>> >>> 9 out of the 10 sites that subscribers on my new block is being hosted >>> by softlayer. >>> >>> Anyone on the list have contacts with softlayer. Right now I have an >>> email to abuse. The support line will not help me out. >>> >>> John >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From cscora at apnic.net Fri Mar 22 18:03:53 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 23 Mar 2019 04:03:53 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190322180353.C27F1C55B6@thyme.apnic.net> 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 at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 23 Mar, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 741807 Prefixes after maximum aggregation (per Origin AS): 284756 Deaggregation factor: 2.61 Unique aggregates announced (without unneeded subnets): 357759 Total ASes present in the Internet Routing Table: 63716 Prefixes per ASN: 11.64 Origin-only ASes present in the Internet Routing Table: 54839 Origin ASes announcing only one prefix: 23689 Transit ASes present in the Internet Routing Table: 8877 Transit-only ASes present in the Internet Routing Table: 268 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 34 Max AS path prepend of ASN (206156) 26 Prefixes from unregistered ASNs in the Routing Table: 29 Number of instances of unregistered ASNs: 32 Number of 32-bit ASNs allocated by the RIRs: 26276 Number of 32-bit ASNs visible in the Routing Table: 21442 Prefixes from 32-bit ASNs in the Routing Table: 93820 Number of bogon 32-bit ASNs visible in the Routing Table: 27 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 256 Number of addresses announced to Internet: 2844501632 Equivalent to 169 /8s, 139 /16s and 166 /24s Percentage of available address space announced: 76.8 Percentage of allocated address space announced: 76.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.2 Total number of prefixes smaller than registry allocations: 247814 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 200650 Total APNIC prefixes after maximum aggregation: 57867 APNIC Deaggregation factor: 3.47 Prefixes being announced from the APNIC address blocks: 197536 Unique aggregates announced from the APNIC address blocks: 82366 APNIC Region origin ASes present in the Internet Routing Table: 9623 APNIC Prefixes per ASN: 20.53 APNIC Region origin ASes announcing only one prefix: 2705 APNIC Region transit ASes present in the Internet Routing Table: 1420 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4588 Number of APNIC addresses announced to Internet: 769694080 Equivalent to 45 /8s, 224 /16s and 153 /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-139577 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: 219300 Total ARIN prefixes after maximum aggregation: 103653 ARIN Deaggregation factor: 2.12 Prefixes being announced from the ARIN address blocks: 218381 Unique aggregates announced from the ARIN address blocks: 104721 ARIN Region origin ASes present in the Internet Routing Table: 18428 ARIN Prefixes per ASN: 11.85 ARIN Region origin ASes announcing only one prefix: 6874 ARIN Region transit ASes present in the Internet Routing Table: 1889 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2634 Number of ARIN addresses announced to Internet: 1079597952 Equivalent to 64 /8s, 89 /16s and 91 /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-399260 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: 204638 Total RIPE prefixes after maximum aggregation: 97408 RIPE Deaggregation factor: 2.10 Prefixes being announced from the RIPE address blocks: 200883 Unique aggregates announced from the RIPE address blocks: 119278 RIPE Region origin ASes present in the Internet Routing Table: 25909 RIPE Prefixes per ASN: 7.75 RIPE Region origin ASes announcing only one prefix: 11494 RIPE Region transit ASes present in the Internet Routing Table: 3682 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7936 Number of RIPE addresses announced to Internet: 717817472 Equivalent to 42 /8s, 201 /16s and 6 /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-210331 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: 96555 Total LACNIC prefixes after maximum aggregation: 21520 LACNIC Deaggregation factor: 4.49 Prefixes being announced from the LACNIC address blocks: 97920 Unique aggregates announced from the LACNIC address blocks: 41890 LACNIC Region origin ASes present in the Internet Routing Table: 8208 LACNIC Prefixes per ASN: 11.93 LACNIC Region origin ASes announcing only one prefix: 2184 LACNIC Region transit ASes present in the Internet Routing Table: 1531 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 28 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5749 Number of LACNIC addresses announced to Internet: 173485056 Equivalent to 10 /8s, 87 /16s and 44 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + 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: 20634 Total AfriNIC prefixes after maximum aggregation: 4286 AfriNIC Deaggregation factor: 4.81 Prefixes being announced from the AfriNIC address blocks: 26831 Unique aggregates announced from the AfriNIC address blocks: 9269 AfriNIC Region origin ASes present in the Internet Routing Table: 1261 AfriNIC Prefixes per ASN: 21.28 AfriNIC Region origin ASes announcing only one prefix: 432 AfriNIC Region transit ASes present in the Internet Routing Table: 246 Average AfriNIC Region AS path length visible: 4.9 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 535 Number of AfriNIC addresses announced to Internet: 103641856 Equivalent to 6 /8s, 45 /16s and 115 /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 7545 4680 542 543 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4658 4192 74 ERX-CERNET-BKB China Education and Rese 7552 3096 1265 52 VIETEL-AS-AP Viettel Group, VN 45899 3037 1737 111 VNPT-AS-VN VNPT Corp, VN 9829 2738 1494 553 BSNL-NIB National Internet Backbone, IN 4766 2615 11120 762 KIXS-AS-KR Korea Telecom, KR 9808 2434 8699 27 CMNET-GD Guangdong Mobile Communication 9394 2209 4906 31 CTTNET China TieTong Telecommunications 4755 2137 422 176 TATACOMM-AS TATA Communications formerl 9498 2026 426 167 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 6327 3601 1325 94 SHAW - Shaw Communications Inc., CA 11492 3552 230 615 CABLEONE - CABLE ONE, INC., US 22773 3382 2976 163 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2600 5900 1070 AMAZON-02 - Amazon.com, Inc., US 16625 2262 1288 1770 AKAMAI-AS - Akamai Technologies, Inc., 20115 2152 2747 535 CHARTER-20115 - Charter Communications, 30036 2131 352 138 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 18566 2112 405 108 MEGAPATH5-US - MegaPath Corporation, US 5650 2094 3074 1462 FRONTIER-FRTR - Frontier Communications 209 2080 5104 583 CENTURYLINK-US-LEGACY-QWEST - CenturyLi 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 5427 1628 139 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3269 378 45 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2643 540 1916 AKAMAI-ASN1, US 12389 2228 2221 638 ROSTELECOM-AS, RU 34984 2057 340 538 TELLCOM-AS, TR 9121 1679 1693 19 TTNET, TR 13188 1605 100 47 TRIOLAN, UA 9009 1399 145 761 M247, GB 8402 1256 545 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 8151 5638 3335 590 Uninet S.A. de C.V., MX 10620 3507 537 365 Telmex Colombia S.A., CO 11830 2704 384 34 Instituto Costarricense de Electricidad 7303 1447 985 245 Telecom Argentina S.A., AR 6503 1418 433 54 Axtel, S.A.B. de C.V., MX 28573 1327 2247 178 CLARO S.A., BR 6147 1258 377 29 Telefonica del Peru S.A.A., PE 3816 1022 505 113 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 951 144 66 Alestra, S. de R.L. de C.V., MX 13999 951 521 246 Mega Cable, S.A. de C.V., MX 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 1200 393 21 LINKdotNET-AS, EG 37611 895 107 9 Afrihost, ZA 24835 843 636 22 RAYA-AS, EG 36903 827 416 126 MT-MPLS, MA 36992 826 1531 71 ETISALAT-MISR, EG 8452 668 1731 19 TE-AS TE-AS, EG 29571 485 70 12 ORANGE-COTE-IVOIRE, CI 37492 470 470 57 ORANGE-, TN 37342 420 32 1 MOVITEL, MZ 23889 395 231 15 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 5638 3335 590 Uninet S.A. de C.V., MX 12479 5427 1628 139 UNI2-AS, ES 7545 4680 542 543 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4658 4192 74 ERX-CERNET-BKB China Education and Rese 39891 3778 203 20 ALJAWWALSTC-AS, SA 6327 3601 1325 94 SHAW - Shaw Communications Inc., CA 11492 3552 230 615 CABLEONE - CABLE ONE, INC., US 10620 3507 537 365 Telmex Colombia S.A., CO 22773 3382 2976 163 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8551 3269 378 45 BEZEQ-INTERNATIONAL-AS Bezeqint Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5427 5288 UNI2-AS, ES 4538 4658 4584 ERX-CERNET-BKB China Education and Research Net 7545 4680 4137 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3601 3507 SHAW - Shaw Communications Inc., CA 8551 3269 3224 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 3382 3219 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 10620 3507 3142 Telmex Colombia S.A., CO 7552 3096 3044 VIETEL-AS-AP Viettel Group, VN 11492 3552 2937 CABLEONE - CABLE ONE, INC., 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 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65550 DOCUMENT 81.8.34.0/24 15924 BORUSANTELEKOM-AS, TR 65550 DOCUMENT 81.8.35.0/24 15924 BORUSANTELEKOM-AS, TR 1358592 UNALLOCATED 103.134.14.0/23 63956 COLO-AS-AP Colocation Australi 1358592 UNALLOCATED 103.134.14.0/24 63956 COLO-AS-AP Colocation Australi 1358592 UNALLOCATED 103.134.15.0/24 63956 COLO-AS-AP Colocation Australi 65549 DOCUMENT 117.239.163.0/24 65544 UNKNOWN 224413 UNALLOCATED 131.221.136.0/24 264413 Conecta Telecom Ltda, BR 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 2.58.224.0/24 201843 IBERSONTEL, ES 2.58.225.0/24 201843 IBERSONTEL, ES 2.58.226.0/24 201843 IBERSONTEL, ES 2.58.227.0/24 201843 IBERSONTEL, ES 27.100.7.0/24 56096 UNKNOWN 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -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:12 /9:10 /10:36 /11:100 /12:291 /13:566 /14:1136 /15:1910 /16:13364 /17:7963 /18:13927 /19:25677 /20:39958 /21:46164 /22:92856 /23:75692 /24:421180 /25:965 /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 12479 4339 5427 UNI2-AS, ES 6327 3376 3601 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2779 3552 CABLEONE - CABLE ONE, INC., US 8551 2723 3269 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2620 3382 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 11830 2049 2704 Instituto Costarricense de Electricidad y Telec 18566 2007 2112 MEGAPATH5-US - MegaPath Corporation, US 30036 1878 2131 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1761 2094 FRONTIER-FRTR - Frontier Communications of Amer Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1606 2:865 4:22 5:2944 6:45 7:1 8:1255 9:1 11:3 12:1849 13:322 14:1952 15:36 16:4 17:240 18:59 20:49 23:2621 24:2544 25:2 27:2547 31:2076 32:97 35:36 36:845 37:3044 38:1700 39:296 40:120 41:3133 42:752 43:2022 44:147 45:7017 46:3251 47:252 49:1361 50:1100 51:322 52:1027 54:289 55:2 56:9 57:43 58:1694 59:1076 60:502 61:2073 62:2007 63:1812 64:4999 65:2216 66:4838 67:2706 68:1169 69:3531 70:1331 71:602 72:2452 74:2761 75:513 76:550 77:1723 78:1761 79:2323 80:1805 81:1505 82:1129 83:888 84:1104 85:2286 86:534 87:1563 88:1035 89:2485 90:222 91:6590 92:1351 93:2444 94:2590 95:3207 96:921 97:344 98:949 99:206 100:89 101:1158 102:480 103:20679 104:3560 105:247 106:847 107:1771 108:688 109:3729 110:1635 111:1885 112:1478 113:1390 114:1135 115:1762 116:1715 117:1892 118:2185 119:1644 120:1020 121:1034 122:2329 123:1652 124:1470 125:1971 128:1258 129:831 130:534 131:1653 132:722 133:219 134:1051 135:242 136:574 137:714 138:2047 139:844 140:578 141:859 142:854 143:1060 144:846 145:509 146:1268 147:805 148:1704 149:820 150:781 151:1011 152:1034 153:322 154:2814 155:899 156:1678 157:939 158:643 159:1915 160:1531 161:932 162:2691 163:799 164:1136 165:1567 166:452 167:1398 168:3286 169:868 170:4068 171:568 172:1166 173:2196 174:1014 175:909 176:2333 177:4209 178:2538 179:1456 180:2160 181:2397 182:2690 183:1075 184:1191 185:14883 186:3666 187:2442 188:2893 189:1984 190:8321 191:1512 192:10027 193:6647 194:5421 195:4072 196:3009 197:1613 198:5861 199:5986 200:7226 201:5119 202:10379 203:10229 204:4548 205:2994 206:3216 207:3260 208:3964 209:4247 210:3930 211:2000 212:3057 213:2904 214:1082 215:54 216:5918 217:2225 218:876 219:579 220:1876 221:967 222:984 223:1401 End of report From lburton at mrow.org Thu Mar 21 21:01:55 2019 From: lburton at mrow.org (Lee Burton) Date: Thu, 21 Mar 2019 14:01:55 -0700 Subject: Contact at Spectrum/Charter (LA area) Message-ID: Looking for a contact re: an event we are running. Thanks in advance, Lee Burton lburton at mrow.org lee.burton at lfest.org From tgarrison at netviscom.com Fri Mar 22 14:47:14 2019 From: tgarrison at netviscom.com (Travis Garrison) Date: Fri, 22 Mar 2019 14:47:14 +0000 Subject: FW: softlayer.com In-Reply-To: References: <6015A8EB-2D06-4008-87BB-5517B1D622F8@neko.id.au> Message-ID: Traceroute from here if it helps Tracing route to 138-43-128-1.reserved.highland.net [138.43.128.1] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms [REDACTED] 2 <1 ms <1 ms <1 ms [REDACTED] 3 1 ms 1 ms <1 ms [REDACTED] 4 1 ms <1 ms <1 ms [REDACTED] 5 6 ms 6 ms 6 ms v313.core1.mci3.he.net [216.218.213.141] 6 16 ms 16 ms 16 ms 100ge10-2.core1.dal1.he.net [184.105.81.206] 7 26 ms 26 ms 26 ms xo-as15-as2828.10gigabitethernet6-7.core1.dal1.he.net [184.105.255.78] 8 40 ms 39 ms 40 ms 207.88.14.198.ptr.us.xo.net [207.88.14.198] 9 40 ms 39 ms 40 ms 207.88.12.178.ptr.us.xo.net [207.88.12.178] 10 39 ms 39 ms 39 ms 216.156.16.239.ptr.us.xo.net [216.156.16.239] 11 48 ms 48 ms 48 ms ip65-46-198-198.z198-46-65.customer.algx.net [65.46.198.198] 12 41 ms 41 ms 41 ms occm-6.dhcp.grp1-rng1.tncsvl.blomand.net.57.131.192.in-addr.arpa [192.131.57.6] 13 * * * Request timed out. Thanks Travis From: NANOG > On Behalf Of Siyuan Miao Sent: Friday, March 22, 2019 9:22 AM To: Nikolas Geyer > Cc: nanog at nanog.org Subject: Re: softlayer.com Perhaps it won't work because their customer support will ask you for bi-directional traceroute and refused to forward to backbone team. Then they'll say it's not their fault and you can see the packet is dropped outside our network. Here's a sample traceroute from SoftLayer Washington, San Jose and Seattle in case someone needs it: aveline at iad02-sl01:~$ mtr 138.43.128.1 --report-wide Start: Fri Mar 22 17:20:42 2019 HOST: iad02-sl01 Loss% Snt Last Avg Best Wrst StDev 1.|-- [REDACTED] 0.0% 10 1.4 1.5 0.8 3.7 1.0 2.|-- ae13.dar02.wdc01.networklayer.com 0.0% 10 0.5 3.3 0.4 28.6 8.8 3.|-- ae9.bbr01.eq01.wdc02.networklayer.com 0.0% 10 0.8 0.8 0.7 1.0 0.0 4.|-- eqix-dc5.intellifiber.com 0.0% 10 0.8 1.2 0.8 2.2 0.3 5.|-- ae13-0.cr02.asbn01-va.us.windstream.net 0.0% 10 0.9 0.9 0.9 1.0 0.0 6.|-- ae11-0.cr01.atln02-ga.us.windstream.net 0.0% 10 15.6 16.1 15.6 17.4 0.5 7.|-- ae0-0.pe06.atln02-ga.us.windstream.net 0.0% 10 17.4 16.1 15.9 17.4 0.3 8.|-- h43.88.198.64.static.ip.windstream.net 0.0% 10 24.7 24.8 24.6 24.9 0.0 9.|-- east.tndodge-21.static.tncsvl.blomand.net 0.0% 10 22.6 22.8 22.5 23.8 0.0 10.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 aveline at sjc03-sl01:~$ mtr 138.43.128.1 --report-wide Start: Fri Mar 22 16:21:04 2019 HOST: sjc03-sl01 Loss% Snt Last Avg Best Wrst StDev 1.|-- [REDACTED] 0.0% 10 2.4 2.0 0.3 14.3 4.3 2.|-- ae0.dar02.sjc01.networklayer.com 0.0% 10 1.0 0.5 0.3 1.3 0.0 3.|-- ae9.bbr01.eq01.sjc02.networklayer.com 0.0% 10 0.8 0.8 0.7 0.9 0.0 4.|-- eqix-sv1.windstream.com 0.0% 10 0.9 0.9 0.8 1.1 0.0 5.|-- ae6-0.cr02.lsaj01-ca.us.windstream.net 0.0% 10 11.6 11.5 11.5 11.6 0.0 6.|-- ae-11-0.cr01.dlls01-tx.us.windstream.net 0.0% 10 42.6 42.7 42.5 43.4 0.0 7.|-- ae7-0.cr02.atln02-ga.us.windstream.net 0.0% 10 64.0 65.6 63.9 74.2 3.4 8.|-- ae1-0.pe06.atln02-ga.us.windstream.net 0.0% 10 62.3 62.7 62.2 66.9 1.5 9.|-- h43.88.198.64.static.ip.windstream.net 0.0% 10 71.9 72.0 71.9 72.2 0.0 10.|-- east.tndodge-21.static.tncsvl.blomand.net 0.0% 10 69.9 68.8 68.6 69.9 0.3 11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 aveline at sea04-sl01:~$ mtr 138.43.128.1 --report-wide Start: Fri Mar 22 08:19:09 2019 HOST: sea04-sl01 Loss% Snt Last Avg Best Wrst StDev 1.|-- [REDACTED] 0.0% 10 0.7 1.2 0.7 1.8 0.0 2.|-- ae12.dar02.sr01.sea01.networklayer.com 0.0% 10 0.6 0.7 0.5 1.3 0.0 3.|-- ae9.bbr01.wb01.sea02.networklayer.com 0.0% 10 1.2 1.0 0.7 1.5 0.0 4.|-- six.seattle-wa.us.windstream.net 0.0% 10 1.5 1.0 0.7 1.7 0.0 5.|-- ae12-0.cr01.chcg01-il.us.windstream.net 0.0% 10 41.1 41.2 41.0 41.6 0.0 6.|-- ae17-0.cr02.chcg01-il.us.windstream.net 0.0% 10 41.1 41.4 41.1 42.0 0.0 7.|-- ae10-0.cr01.atln02-ga.us.windstream.net 0.0% 10 63.8 64.4 63.5 71.1 2.3 8.|-- ae0-0.pe06.atln02-ga.us.windstream.net 0.0% 10 63.7 63.7 63.5 64.0 0.0 9.|-- h43.88.198.64.static.ip.windstream.net 0.0% 10 71.6 71.8 71.5 72.8 0.0 10.|-- east.tndodge-21.static.tncsvl.blomand.net 0.0% 10 71.8 70.8 70.2 71.8 0.3 11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 Regards, Siyuan Miao On Fri, Mar 22, 2019 at 10:10 PM Nikolas Geyer > wrote: This is the best approach. Have run into this problem a few times and had zero success getting the filters removed without having SL customers log tickets with support. Verbiage needs to be “this prefix is blocked, please escalate to your backbone team”. Sent from my iPhone On Mar 22, 2019, at 9:56 AM, Forrest Christian (List Account) > wrote: Another idea... Have you tried reaching out to some of the blocked sites? They likely have better contact information than is available publicly, especially a larger one like indeed. On Thu, Mar 21, 2019, 3:41 PM John Alcock > wrote: Still looking for anyone from softlayer.com It has been a challenge. Anything hosted by softlayer.com is being blocked. Here is a small list so far windowbook.tpondemand.com ahainstructornetwork.americanheart.org clover.com Cebroker.com Softlayer.com indeed.com & Enforce Staffing It is growing every day. John On Wed, Mar 20, 2019 at 12:35 PM John Alcock > wrote: Afternoon, Thought I would start a new thread. After researching, traceroutes, etc, I think I found my problem. 9 out of the 10 sites that subscribers on my new block is being hosted by softlayer. Anyone on the list have contacts with softlayer. Right now I have an email to abuse. The support line will not help me out. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at mtcc.com Sat Mar 23 00:50:29 2019 From: mike at mtcc.com (Michael Thomas) Date: Fri, 22 Mar 2019 17:50:29 -0700 Subject: webauthn Message-ID: <08f55165-2444-9187-7463-55c30225b901@mtcc.com> I know it's a little tangential, but it's a huge operational issue for network operations too. Have any NANOG folks been paying attention to webauthn? i didn't know about until yesterday, though i wrote a proof of concept of something that looks a lot like webauthn in 2012. The thing that is kind of concerning to me is that there seems to be some amount of misconception (I hope!) that you need hardware or biometric or some non-password based authentication on the user device in the many write ups i've been reading. i sure hope that misconception doesn't take hold because there is nothing wrong with *local* password based authentication to unlock your credentials. i fear that if the misconception takes hold, it will cause the entire effort to tank. the issue with passwords is transmitting them over the wire, first and foremost. strong *local* passwords that unlock functionality is still perfectly fine for many many applications, IMO. Which isn't to say that hardware/biometric is bad, it's just to say that they are separable problems with their own set of tradeoffs. NANOG folks sound like prime examples of who should be using 2 factor, etc. But we don't want to discourage, oh say, Epicurious to implement webauthn to get to my super-secret recipe box because they don't think people will buy id dongles. Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at mtcc.com Sat Mar 23 19:02:09 2019 From: mike at mtcc.com (Michael Thomas) Date: Sat, 23 Mar 2019 12:02:09 -0700 Subject: webauthn In-Reply-To: References: <08f55165-2444-9187-7463-55c30225b901@mtcc.com> Message-ID: <30d62076-2cf6-b7a5-391a-888a155921b3@mtcc.com> On 3/23/19 5:18 AM, Mauricio Rodriguez wrote: > My understanding is that 2-factor is one of the primary drivers for > webauthn.  I feel that hardware dongles are the thing of the past, > with software now being available that runs on your smartphone and > serves the same function.  Example - Google Authenticator. 2FA is fine, but the real problem is one factor passwords going over the wire. If we did nothing than get rid of that, it would be a massive upgrade to security on the net. Mike > > ______ > Regards, > Mauricio Rodriguez > Founder / Owner > Fletnet Network Engineering (www.fletnet.com ) > 1951 NW 7th Ave #600, Miami, FL 33136 > > Mauricio.Rodriguez at fletnet.com > Office: +1-786-309-5493 > Mobile: +1-305-978-6884 > > Schedule a Meeting with me > > > > > > > On Fri, Mar 22, 2019 at 8:52 PM Michael Thomas > wrote: > > I know it's a little tangential, but it's a huge operational issue > for network operations too. Have any NANOG folks been paying > attention to webauthn? i didn't know about until yesterday, though > i wrote a proof of concept of something that looks a lot like > webauthn in 2012. The thing that is kind of concerning to me is > that there seems to be some amount of misconception (I hope!) that > you need hardware or biometric or some non-password based > authentication on the user device in the many write ups i've been > reading. i sure hope that misconception doesn't take hold because > there is nothing wrong with *local* password based authentication > to unlock your credentials. i fear that if the misconception takes > hold, it will cause the entire effort to tank. the issue with > passwords is transmitting them over the wire, first and foremost. > strong *local* passwords that unlock functionality is still > perfectly fine for many many applications, IMO. > > Which isn't to say that hardware/biometric is bad, it's just to > say that they are separable problems with their own set of > tradeoffs. NANOG folks sound like prime examples of who should be > using 2 factor, etc. But we don't want to discourage, oh say, > Epicurious to implement webauthn to get to my super-secret recipe > box because they don't think people will buy id dongles. > > Mike > > > /This message (and any associated files) may contain confidential > and/or privileged information. If you are not the intended recipient > or authorized to receive this for the intended recipient, you must not > use, copy, disclose or take any action based on this message or any > information herein. If you have received this message in error, please > advise the sender immediately by sending a reply e-mail and delete > this message. Thank you for your cooperation./ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Sat Mar 23 19:41:32 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Sat, 23 Mar 2019 12:41:32 -0700 Subject: QFX5k question Message-ID: Hey there, I am trying to get my hands on some QFX5000s and I have a rather quick question. In the past, I often used MX + EX where MX did routing and I connected all uplinks/peering and EX, and EX did switching, i connected my servers to ex. in QFX, I am trying to see if I need EX or not? more importantly (besides from what juniper papers say) are there any known issues people run into for a small scale deployment. (100mbps-1gbps range 1 rack, 20 servers) my plan is to have QFX to it all, but i am worried, if this is too much for QFX, if you have relative experience on this , feel free to let me know thanks in advance mehmet -------------- next part -------------- An HTML attachment was scrubbed... URL: From contact at winterei.se Sat Mar 23 19:45:08 2019 From: contact at winterei.se (Paul S.) Date: Sun, 24 Mar 2019 04:45:08 +0900 Subject: QFX5k question In-Reply-To: References: Message-ID: <6ba8fe61-76fd-cdb4-4e94-8cf2957daa0b@winterei.se> QFX5100 as a L3 router + L2 switch performed well for us in the past, I don't see why it'd fall over in <1g traffic now. You should be good to go. On 3/24/2019 04:41 午前, Mehmet Akcin wrote: > Hey there, > > I am trying to get my hands on some QFX5000s and I have a rather quick > question. > > In the past, I often used MX + EX where MX did routing and I connected > all uplinks/peering and EX, and EX did switching, i connected my > servers to ex. > > in QFX, I am trying to see if I need EX or not? more importantly > (besides from what juniper papers say) are there any known issues > people run into for a small scale deployment. (100mbps-1gbps range 1 > rack, 20 servers) > > my plan is to have QFX to it all, but i am worried, if this is too > much for QFX, if you have relative experience on this , feel free to > let me know > > thanks in advance > > mehmet From mehmet at akcin.net Sat Mar 23 19:52:53 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Sat, 23 Mar 2019 12:52:53 -0700 Subject: QFX5k question In-Reply-To: <6ba8fe61-76fd-cdb4-4e94-8cf2957daa0b@winterei.se> References: <6ba8fe61-76fd-cdb4-4e94-8cf2957daa0b@winterei.se> Message-ID: thanks for quick reply. I forgot to mention, 2 x 10G providers with full routing table on each. thank you... On Sat, Mar 23, 2019 at 12:45 PM Paul S. wrote: > QFX5100 as a L3 router + L2 switch performed well for us in the past, I > don't see why it'd fall over in <1g traffic now. > > You should be good to go. > > On 3/24/2019 04:41 午前, Mehmet Akcin wrote: > > Hey there, > > > > I am trying to get my hands on some QFX5000s and I have a rather quick > > question. > > > > In the past, I often used MX + EX where MX did routing and I connected > > all uplinks/peering and EX, and EX did switching, i connected my > > servers to ex. > > > > in QFX, I am trying to see if I need EX or not? more importantly > > (besides from what juniper papers say) are there any known issues > > people run into for a small scale deployment. (100mbps-1gbps range 1 > > rack, 20 servers) > > > > my plan is to have QFX to it all, but i am worried, if this is too > > much for QFX, if you have relative experience on this , feel free to > > let me know > > > > thanks in advance > > > > mehmet > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From niels=nanog at bakker.net Sat Mar 23 20:01:20 2019 From: niels=nanog at bakker.net (Niels Bakker) Date: Sat, 23 Mar 2019 21:01:20 +0100 Subject: QFX5k question In-Reply-To: References: <6ba8fe61-76fd-cdb4-4e94-8cf2957daa0b@winterei.se> Message-ID: <20190323200120.GC88473@jima.tpb.net> * mehmet at akcin.net (Mehmet Akcin) [Sat 23 Mar 2019, 20:53 CET]: >thanks for quick reply. I forgot to mention, 2 x 10G providers with >full routing table on each. https://www.juniper.net/documentation/en_US/junos/topics/topic-map/unified-forwarding-table-D15-qfx-series.html#UFT-table-profile-tbl -- Niels. From joe at breathe-underwater.com Sat Mar 23 20:43:15 2019 From: joe at breathe-underwater.com (Joseph Jenkins) Date: Sat, 23 Mar 2019 13:43:15 -0700 Subject: QFX5k question In-Reply-To: References: Message-ID: I have 4 QFX51xx switches in a virtual chassis and have no problems pushing that much traffic through them for several hundred servers with 10GB uplinks. On March 23, 2019 at 12:42:52 PM, Mehmet Akcin (mehmet at akcin.net) wrote: Hey there, I am trying to get my hands on some QFX5000s and I have a rather quick question. In the past, I often used MX + EX where MX did routing and I connected all uplinks/peering and EX, and EX did switching, i connected my servers to ex. in QFX, I am trying to see if I need EX or not? more importantly (besides from what juniper papers say) are there any known issues people run into for a small scale deployment. (100mbps-1gbps range 1 rack, 20 servers) my plan is to have QFX to it all, but i am worried, if this is too much for QFX, if you have relative experience on this , feel free to let me know thanks in advance mehmet -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at wicks.co.nz Sat Mar 23 21:00:54 2019 From: tony at wicks.co.nz (Tony Wicks) Date: Sun, 24 Mar 2019 10:00:54 +1300 Subject: QFX5k question In-Reply-To: References: Message-ID: <002701d4e1bb$8214c440$863e4cc0$@wicks.co.nz> I have Virtual chassis QFX5100’s running as a switching/routing core with about 80k routes (bgp in routing-instances) and no issues. MX’s are on the upstream borders and downstream BNG’s. The only issue I has was I had some MPLS psuedowire switching on them and found a few glitches. From: NANOG On Behalf Of Joseph Jenkins Sent: Sunday, 24 March 2019 9:43 AM To: nanog Subject: Re: QFX5k question I have 4 QFX51xx switches in a virtual chassis and have no problems pushing that much traffic through them for several hundred servers with 10GB uplinks. On March 23, 2019 at 12:42:52 PM, Mehmet Akcin (mehmet at akcin.net ) wrote: Hey there, I am trying to get my hands on some QFX5000s and I have a rather quick question. In the past, I often used MX + EX where MX did routing and I connected all uplinks/peering and EX, and EX did switching, i connected my servers to ex. in QFX, I am trying to see if I need EX or not? more importantly (besides from what juniper papers say) are there any known issues people run into for a small scale deployment. (100mbps-1gbps range 1 rack, 20 servers) my plan is to have QFX to it all, but i am worried, if this is too much for QFX, if you have relative experience on this , feel free to let me know thanks in advance mehmet -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Sat Mar 23 21:09:21 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sat, 23 Mar 2019 15:09:21 -0600 Subject: QFX5k question In-Reply-To: References: Message-ID: <8caa182d-e570-0cd6-e459-401cdca1bcdc@spamtrap.tnetconsulting.net> On 3/23/19 1:41 PM, Mehmet Akcin wrote: > Hey there, Hi, > in QFX, I am trying to see if I need EX or not? more importantly > (besides from what juniper papers say) are there any known issues people > run into for a small scale deployment. (100mbps-1gbps range 1 rack, 20 > servers) > > my plan is to have QFX to it all, but i am worried, if this is too much > for QFX, if you have relative experience on this , feel free to let me know We have a large number of QFX5100s deployed as L3 ToRs. They are running anywhere between 50 G and 150 G through them, depending on the deployment. They work fairly well for us. I don't know if they can hold a full internet DFZ BGP feed or not. I don't know if that's an issue for you or not. > thanks in advance You're welcome, and good luck. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From sander at steffann.nl Sat Mar 23 21:09:32 2019 From: sander at steffann.nl (Sander Steffann) Date: Sat, 23 Mar 2019 22:09:32 +0100 Subject: QFX5k question In-Reply-To: References: <6ba8fe61-76fd-cdb4-4e94-8cf2957daa0b@winterei.se> Message-ID: <7B3C5FF3-CBF8-468F-8764-2DF00D02A720@steffann.nl> Hi, > thanks for quick reply. I forgot to mention, 2 x 10G providers with full routing table on each. Those QFXs won't be able to hold full routing tables: https://www.juniper.net/documentation/en_US/junos/topics/topic-map/layer-2-forwarding-tables.html#id-configuring-the-unified-forwarding-table-on-switches Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From bellman at nsc.liu.se Sat Mar 23 22:32:56 2019 From: bellman at nsc.liu.se (Thomas Bellman) Date: Sat, 23 Mar 2019 23:32:56 +0100 Subject: QFX5k question In-Reply-To: References: Message-ID: On 2019-03-23 12:41 -0700, Mehmet Akcin wrote: > I am trying to get my hands on some QFX5000s and I have a rather quick > question. First, there is no model named QFX5000. There is QFX5100, QFX5110, QFX5120, QFX5200 and QFX5210 (and some of them have several submodels, e.g. QFX5100-48T, QFX5100-48S and QFX5100-24Q). > in QFX, I am trying to see if I need EX or not? more importantly (besides > from what juniper papers say) are there any known issues people run into > for a small scale deployment. (100mbps-1gbps range 1 rack, 20 servers) > > my plan is to have QFX to it all, but i am worried, if this is too much for > QFX, if you have relative experience on this , feel free to let me know Presumably you are then interrested in the QFX5100-48S or QFX5100-48T, as the other QFX5k models have even more performance available, and thus cost a bit more. (Cheaper than most MX:es, though.) You might also consider the EX4600: only 24 SFP+ (10G) ports and 4 QSFP (40G) ports, but otherwise identical hardware to the QFX5100-48S. I think there are some features that Juniper has disabled in Junos for the EX4600, though (VXLAN isn't mentioned in the EX4600 datasheet, for example). We have both QFX5100-48S and EX4600, and are quite happy with them. They can easily handle the traffic volumes you are speaking about, for both L2 and L3. The Broadcom Trident II chip inside of them is what has been powering L3 switches at the big cloud providers for years, and they push much more traffic through them than that. They do have limited feature set, though. E.g, they only look at the first 64 octets of each packet (and that includes L2 and L2.5 headers) when deciding what to do with a packet, and can't chase the IPv6 header chain; thus, if there is an extension header before the TCP/UDP header, they won't know what TCP/UDP ports are used, or even if it is TCP, UDP or something else. Dealing with packets exiting tunnels (MPLS, VXLAN, et.c) is also limited. However: On 2019-03-23 12:52 -0700, Mehmet Akcin wrote: > thanks for quick reply. I forgot to mention, 2 x 10G providers with full > routing table on each. As others have told you, and a quick glance at the datasheets from Juniper will show, no way. 128k routes for IPv4, 64k routes for IPv6. And several caveats hiding, e.g. you can't reach both limits at the same time. And even reaching those will require careful configuration. First question: do you *need* full Internet DFZ tables? Or can you get away with just getting, e.g, 10k important prefixes from each uplink, and punt everything else through a default route? If those prefixes are chosen well, they might catch 95-99% of all the traffic, and the remaining 1-5% will just have to suffer sub-optimal routing. I have heard of people who get a full BGP feed from their providers, but only program a small portion of the prefixes into FIB, using some filter list. Then they monitor their outgoing traffic to notice when significant amounts of traffic go out the wrong way, and then change their filter lists. I don't know any details about how they do it, though. If you *do* need full Internet tables, have you considered using a Linux or BSD server with a couple of 10G interfaces and running Bird, Quagga, or any of the other BGP implementations for Unix/Linux? Or perhaps Junipers virtual MX, which you run on a Linux server? That is probably quite a bit cheaper than an MX router, and should easily be able to handle two 10G uplinks. And by the way, remember that you need to buy an extra license to use BGP on the QFX5k and EX4600 switches. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From michael at wi-fiber.io Sat Mar 23 22:59:16 2019 From: michael at wi-fiber.io (Michael Crapse) Date: Sat, 23 Mar 2019 16:59:16 -0600 Subject: contact for idrive.com Message-ID: Trying to find a NOC contact for idrive.com . Whois of the URL doesn't show any owner, whois of the IP for the site(not service) just shows centurylink Customers from a major subnet of ours cannot utilise the service. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nuclearcat at nuclearcat.com Sun Mar 24 08:25:48 2019 From: nuclearcat at nuclearcat.com (Denys Fedoryshchenko) Date: Sun, 24 Mar 2019 10:25:48 +0200 Subject: QFX5k question In-Reply-To: References: Message-ID: <3cb14ee992fd26b77faaf9aa1f34cf94@nuclearcat.com> On 2019-03-24 00:32, Thomas Bellman wrote: > They do have limited feature set, though. E.g, they only look at > the first 64 octets of each packet (and that includes L2 and L2.5 > headers) when deciding what to do with a packet, and can't chase > the IPv6 header chain; thus, if there is an extension header before > the TCP/UDP header, they won't know what TCP/UDP ports are used, > or even if it is TCP, UDP or something else. Dealing with packets > exiting tunnels (MPLS, VXLAN, et.c) is also limited. Some declared features - do not work. For example, IPIP termination through filters is claimed, but does not work. https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/ipip-tunnel-services-filter-qfx-series.html Perhaps "not implemented yet", possibly errata, nevertheless it is very unpleasant when you buy equipment and this is a key necessary function. Therefore, if any more or less complex (uncommon) features are used, it is better to test them first. From marcel.duregards at yahoo.fr Mon Mar 25 08:28:18 2019 From: marcel.duregards at yahoo.fr (marcel.duregards at yahoo.fr) Date: Mon, 25 Mar 2019 09:28:18 +0100 Subject: Incoming SSDP UDP 1900 filtering Message-ID: <5C989122.7030704@yahoo.fr> Dear Community, We see more and more SSDP 'scan' in our network (coming from outside into our AS). Of course our client have open vulnerables boxes (last one is an enterprise class Synology with all defaults ports open:-)) which could be used as a reflection SSDP client. As SSDP is used with PnP for local LAN service discovery, we are thinking of: 1) educate our client (take a lot of time) 2) filter incoming SSDP packets (UDP port 1900 at least) in our bgp border We see option 2 as a good action to remove our autonomous systeme from potential sources of DDOS SSDP source toward the Internet. Of course this might (very few chance) open others problems with clients which use this port as an obfuscation port, but anyhow it would not be a good idea as it is a registered IANA port. We could think of filtering also incoming port 5000 (UPnP), but it is the default port that Synology decide to use (WHY???? so many trojan use this) for the DSM login into the UI. What do you think ? Thank, best regards, -- Marcel From sean at donelan.com Mon Mar 25 09:17:46 2019 From: sean at donelan.com (Sean Donelan) Date: Mon, 25 Mar 2019 05:17:46 -0400 (EDT) Subject: Incoming SSDP UDP 1900 filtering In-Reply-To: <5C989122.7030704@yahoo.fr> References: <5C989122.7030704@yahoo.fr> Message-ID: On Mon, 25 Mar 2019, marcel.duregards--- via NANOG wrote: > As SSDP is used with PnP for local LAN service discovery, we are > thinking of: > > 1) educate our client (take a lot of time) > 2) filter incoming SSDP packets (UDP port 1900 at least) in our bgp border Its always a bad idea to do packet filtering at your bgp border. All packet filtering should be done as close to the customer as possible, preferably at the customer's home/office broadband gateway router device. I don't know why the default configuration of a broadband gateway router would allow unsolicited internet-to-lan packets. Doing the filtering on the customer's broadband gateway router, enables individual customer configuration changes, i.e. in the unlikely event they use those UDP/TCP ports for something else. Connecting "naked" consumer or enterprise LANs, i.e., a Synology NAS or most other things, directly to the internet without a gateway device is usually a bad idea. Naked LAN connections can be Ok in some situations, with proper configuration, but not by default. Although somewhat controversal, since 2003 I think ISPs should have some default filters at the customer-edge which can be removed at an individual customer's request. But no default packet filters at an ISP's BGP-edge, i.e., customer or upstream/downstream ISP bgp connections. It just breaks too many things, in weird difficult to diagnose ways. From phil.lavin at cloudcall.com Mon Mar 25 09:26:50 2019 From: phil.lavin at cloudcall.com (Phil Lavin) Date: Mon, 25 Mar 2019 09:26:50 +0000 Subject: Incoming SSDP UDP 1900 filtering In-Reply-To: <5C989122.7030704@yahoo.fr> References: <5C989122.7030704@yahoo.fr> Message-ID: On Mon, 25 Mar 2019, marcel.duregards--- via NANOG wrote: > As SSDP is used with PnP for local LAN service discovery, we are > thinking of: > > 1) educate our client (take a lot of time) > 2) filter incoming SSDP packets (UDP port 1900 at least) in our bgp > border Looking back at logs for VoIP calls over the past week (we are a small B2B telco), I see a fair number of RTP streams originating from UDP port 1900 on the customer side. Such filtering at the provider edge would have caused one way audio on these calls From sean at donelan.com Mon Mar 25 09:48:41 2019 From: sean at donelan.com (Sean Donelan) Date: Mon, 25 Mar 2019 05:48:41 -0400 (EDT) Subject: Incoming SSDP UDP 1900 filtering In-Reply-To: References: <5C989122.7030704@yahoo.fr> Message-ID: Barry Greene has already written up a great overview, and provides links to best practices on ISP port filtering, pro & con. http://www.senki.org/exploitable-port-filtering/ My advice is consistent with Barry's, but I should I done my web research first :-) From tom at ninjabadger.net Mon Mar 25 10:39:32 2019 From: tom at ninjabadger.net (Tom Hill) Date: Mon, 25 Mar 2019 10:39:32 +0000 Subject: Incoming SSDP UDP 1900 filtering In-Reply-To: References: <5C989122.7030704@yahoo.fr> Message-ID: <41650741-a196-5b1c-6965-17b487597bfe@ninjabadger.net> On 25/03/2019 09:17, Sean Donelan wrote: > Its always a bad idea to do packet filtering at your bgp border. Wild assertion. Why? DoS mitigation, iACLs, BGP security... I can think of lots of very sensible reasons. -- Tom From cb.list6 at gmail.com Mon Mar 25 12:13:15 2019 From: cb.list6 at gmail.com (Ca By) Date: Mon, 25 Mar 2019 05:13:15 -0700 Subject: Incoming SSDP UDP 1900 filtering In-Reply-To: <5C989122.7030704@yahoo.fr> References: <5C989122.7030704@yahoo.fr> Message-ID: Blocked ssdp and move on Ssdp is a horrible ddos vector Comcast and many others already block it, because is the smart and best thing to do https://www.xfinity.com/support/articles/list-of-blocked-ports On Mon, Mar 25, 2019 at 1:30 AM marcel.duregards--- via NANOG < nanog at nanog.org> wrote: > Dear Community, > > We see more and more SSDP 'scan' in our network (coming from outside > into our AS). Of course our client have open vulnerables boxes (last one > is an enterprise class Synology with all defaults ports open:-)) which > could be used as a reflection SSDP client. > > As SSDP is used with PnP for local LAN service discovery, we are > thinking of: > > 1) educate our client (take a lot of time) > 2) filter incoming SSDP packets (UDP port 1900 at least) in our bgp border > > We see option 2 as a good action to remove our autonomous systeme from > potential sources of DDOS SSDP source toward the Internet. > Of course this might (very few chance) open others problems with clients > which use this port as an obfuscation port, but anyhow it would not be a > good idea as it is a registered IANA port. > We could think of filtering also incoming port 5000 (UPnP), but it is > the default port that Synology decide to use (WHY???? so many trojan use > this) for the DSM login into the UI. > > What do you think ? > > Thank, best regards, > > -- > Marcel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhellenthal at dataix.net Mon Mar 25 12:33:30 2019 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Mon, 25 Mar 2019 07:33:30 -0500 Subject: Incoming SSDP UDP 1900 filtering In-Reply-To: References: <5C989122.7030704@yahoo.fr> Message-ID: <638EEC90-320C-4241-A66E-8F23B8BCDC1A@dataix.net> Actually a little surprised to see port 25 blocked in both directions here along with 1080. It’s like saying here’s your network buuuuut it’s limited. Though I wouldn’t recommend spawning up 25 it’s still a legitimately used port today as alike with 1080. -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Mar 25, 2019, at 07:13, Ca By wrote: > > Blocked ssdp and move on > > Ssdp is a horrible ddos vector > > Comcast and many others already block it, because is the smart and best thing to do > > https://www.xfinity.com/support/articles/list-of-blocked-ports > > >> On Mon, Mar 25, 2019 at 1:30 AM marcel.duregards--- via NANOG wrote: >> Dear Community, >> >> We see more and more SSDP 'scan' in our network (coming from outside >> into our AS). Of course our client have open vulnerables boxes (last one >> is an enterprise class Synology with all defaults ports open:-)) which >> could be used as a reflection SSDP client. >> >> As SSDP is used with PnP for local LAN service discovery, we are >> thinking of: >> >> 1) educate our client (take a lot of time) >> 2) filter incoming SSDP packets (UDP port 1900 at least) in our bgp border >> >> We see option 2 as a good action to remove our autonomous systeme from >> potential sources of DDOS SSDP source toward the Internet. >> Of course this might (very few chance) open others problems with clients >> which use this port as an obfuscation port, but anyhow it would not be a >> good idea as it is a registered IANA port. >> We could think of filtering also incoming port 5000 (UPnP), but it is >> the default port that Synology decide to use (WHY???? so many trojan use >> this) for the DSM login into the UI. >> >> What do you think ? >> >> Thank, best regards, >> >> -- >> Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: From cb.list6 at gmail.com Mon Mar 25 12:44:01 2019 From: cb.list6 at gmail.com (Ca By) Date: Mon, 25 Mar 2019 05:44:01 -0700 Subject: Incoming SSDP UDP 1900 filtering In-Reply-To: <638EEC90-320C-4241-A66E-8F23B8BCDC1A@dataix.net> References: <5C989122.7030704@yahoo.fr> <638EEC90-320C-4241-A66E-8F23B8BCDC1A@dataix.net> Message-ID: On Mon, Mar 25, 2019 at 5:33 AM Jason Hellenthal wrote: > Actually a little surprised to see port 25 blocked in both directions here > along with 1080. It’s like saying here’s your network buuuuut it’s limited. > > Though I wouldn’t recommend spawning up 25 it’s still a legitimately used > port today as alike with 1080. > Different topic. But most broadband providers have a similar list and it nearly always has port 25 blocked and you know why > > -- > J. Hellenthal > > The fact that there's a highway to Hell but only a stairway to Heaven says > a lot about anticipated traffic volume. > > On Mar 25, 2019, at 07:13, Ca By wrote: > > Blocked ssdp and move on > > Ssdp is a horrible ddos vector > > Comcast and many others already block it, because is the smart and best > thing to do > > https://www.xfinity.com/support/articles/list-of-blocked-ports > > > On Mon, Mar 25, 2019 at 1:30 AM marcel.duregards--- via NANOG < > nanog at nanog.org> wrote: > >> Dear Community, >> >> We see more and more SSDP 'scan' in our network (coming from outside >> into our AS). Of course our client have open vulnerables boxes (last one >> is an enterprise class Synology with all defaults ports open:-)) which >> could be used as a reflection SSDP client. >> >> As SSDP is used with PnP for local LAN service discovery, we are >> thinking of: >> >> 1) educate our client (take a lot of time) >> 2) filter incoming SSDP packets (UDP port 1900 at least) in our bgp border >> >> We see option 2 as a good action to remove our autonomous systeme from >> potential sources of DDOS SSDP source toward the Internet. >> Of course this might (very few chance) open others problems with clients >> which use this port as an obfuscation port, but anyhow it would not be a >> good idea as it is a registered IANA port. >> We could think of filtering also incoming port 5000 (UPnP), but it is >> the default port that Synology decide to use (WHY???? so many trojan use >> this) for the DSM login into the UI. >> >> What do you think ? >> >> Thank, best regards, >> >> -- >> Marcel >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoffer at netravnen.de Mon Mar 25 13:07:47 2019 From: christoffer at netravnen.de (Hansen, Christoffer) Date: Mon, 25 Mar 2019 14:07:47 +0100 Subject: Incoming SSDP UDP 1900 filtering In-Reply-To: References: <5C989122.7030704@yahoo.fr> <638EEC90-320C-4241-A66E-8F23B8BCDC1A@dataix.net> Message-ID: <412069f0-03f3-01ba-389e-c5ad8f57b51b@netravnen.de> On 25/03/2019 13:44, Ca By wrote: > Different topic. But most broadband providers have a similar > list and it nearly always has port 25 blocked and you know why https://ipv6.he.net/certification/faq.php HE blocks IRC 6667 and SMTP 25 ports on https://tunnelbroker.net/ tunnels for the same reasons. Blocking common abuse ports by default at the $customer CPE has it's positive benefits. Then allowing $customer to request port blocking removed if necessary. (Require $customer to know what they are doing before approving unblocking port) -- Christoffer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From roxanna.cieplinska at gmail.com Sat Mar 23 00:53:01 2019 From: roxanna.cieplinska at gmail.com (Roxanna Cieplinska) Date: Fri, 22 Mar 2019 17:53:01 -0700 Subject: webauthn In-Reply-To: <08f55165-2444-9187-7463-55c30225b901@mtcc.com> References: <08f55165-2444-9187-7463-55c30225b901@mtcc.com> Message-ID: <78D73628-72C6-4298-882F-D09F9D78E3A9@gmail.com> Keep it short! Roxanna I. Cieplinska M: + 1 (415) 412-7699 Sent from my iPhone > On Mar 22, 2019, at 5:50 PM, Michael Thomas wrote: > > I know it's a little tangential, but it's a huge operational issue for network operations too. Have any NANOG folks been paying attention to webauthn? i didn't know about until yesterday, though i wrote a proof of concept of something that looks a lot like webauthn in 2012. The thing that is kind of concerning to me is that there seems to be some amount of misconception (I hope!) that you need hardware or biometric or some non-password based authentication on the user device in the many write ups i've been reading. i sure hope that misconception doesn't take hold because there is nothing wrong with *local* password based authentication to unlock your credentials. i fear that if the misconception takes hold, it will cause the entire effort to tank. the issue with passwords is transmitting them over the wire, first and foremost. strong *local* passwords that unlock functionality is still perfectly fine for many many applications, IMO. > > Which isn't to say that hardware/biometric is bad, it's just to say that they are separable problems with their own set of tradeoffs. NANOG folks sound like prime examples of who should be using 2 factor, etc. But we don't want to discourage, oh say, Epicurious to implement webauthn to get to my super-secret recipe box because they don't think people will buy id dongles. > > Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrodriguez at fletnet.com Sat Mar 23 12:18:10 2019 From: mrodriguez at fletnet.com (Mauricio Rodriguez) Date: Sat, 23 Mar 2019 08:18:10 -0400 Subject: webauthn In-Reply-To: <08f55165-2444-9187-7463-55c30225b901@mtcc.com> References: <08f55165-2444-9187-7463-55c30225b901@mtcc.com> Message-ID: My understanding is that 2-factor is one of the primary drivers for webauthn. I feel that hardware dongles are the thing of the past, with software now being available that runs on your smartphone and serves the same function. Example - Google Authenticator. ______ Regards, Mauricio Rodriguez Founder / Owner Fletnet Network Engineering (www.fletnet.com) 1951 NW 7th Ave #600, Miami, FL 33136 Mauricio.Rodriguez at fletnet.com Office: +1-786-309-5493 Mobile: +1-305-978-6884 Schedule a Meeting with me On Fri, Mar 22, 2019 at 8:52 PM Michael Thomas wrote: > I know it's a little tangential, but it's a huge operational issue for > network operations too. Have any NANOG folks been paying attention to > webauthn? i didn't know about until yesterday, though i wrote a proof of > concept of something that looks a lot like webauthn in 2012. The thing that > is kind of concerning to me is that there seems to be some amount of > misconception (I hope!) that you need hardware or biometric or some > non-password based authentication on the user device in the many write ups > i've been reading. i sure hope that misconception doesn't take hold because > there is nothing wrong with *local* password based authentication to unlock > your credentials. i fear that if the misconception takes hold, it will > cause the entire effort to tank. the issue with passwords is transmitting > them over the wire, first and foremost. strong *local* passwords that > unlock functionality is still perfectly fine for many many applications, > IMO. > > Which isn't to say that hardware/biometric is bad, it's just to say that > they are separable problems with their own set of tradeoffs. NANOG folks > sound like prime examples of who should be using 2 factor, etc. But we > don't want to discourage, oh say, Epicurious to implement webauthn to get > to my super-secret recipe box because they don't think people will buy id > dongles. > > Mike > -- This message (and any associated files) may contain confidential and/or privileged information. If you are not the intended recipient or authorized to receive this for the intended recipient, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by sending a reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Mon Mar 25 13:46:27 2019 From: beecher at beecher.cc (Tom Beecher) Date: Mon, 25 Mar 2019 09:46:27 -0400 Subject: webauthn In-Reply-To: References: <08f55165-2444-9187-7463-55c30225b901@mtcc.com> Message-ID: I will personally always prefer hardware based methods where the private key data is never exposed over pure software based methods. On Mon, Mar 25, 2019 at 9:32 AM Mauricio Rodriguez wrote: > My understanding is that 2-factor is one of the primary drivers for > webauthn. I feel that hardware dongles are the thing of the past, with > software now being available that runs on your smartphone and serves the > same function. Example - Google Authenticator. > > ______ > Regards, > Mauricio Rodriguez > Founder / Owner > Fletnet Network Engineering (www.fletnet.com) > 1951 NW 7th Ave #600, Miami, FL 33136 > > Mauricio.Rodriguez at fletnet.com > Office: +1-786-309-5493 > Mobile: +1-305-978-6884 > > Schedule a Meeting with me > > > > > > > On Fri, Mar 22, 2019 at 8:52 PM Michael Thomas wrote: > >> I know it's a little tangential, but it's a huge operational issue for >> network operations too. Have any NANOG folks been paying attention to >> webauthn? i didn't know about until yesterday, though i wrote a proof of >> concept of something that looks a lot like webauthn in 2012. The thing that >> is kind of concerning to me is that there seems to be some amount of >> misconception (I hope!) that you need hardware or biometric or some >> non-password based authentication on the user device in the many write ups >> i've been reading. i sure hope that misconception doesn't take hold because >> there is nothing wrong with *local* password based authentication to unlock >> your credentials. i fear that if the misconception takes hold, it will >> cause the entire effort to tank. the issue with passwords is transmitting >> them over the wire, first and foremost. strong *local* passwords that >> unlock functionality is still perfectly fine for many many applications, >> IMO. >> >> Which isn't to say that hardware/biometric is bad, it's just to say that >> they are separable problems with their own set of tradeoffs. NANOG folks >> sound like prime examples of who should be using 2 factor, etc. But we >> don't want to discourage, oh say, Epicurious to implement webauthn to get >> to my super-secret recipe box because they don't think people will buy id >> dongles. >> >> Mike >> > > *This message (and any associated files) may contain confidential and/or > privileged information. If you are not the intended recipient or authorized > to receive this for the intended recipient, you must not use, copy, > disclose or take any action based on this message or any information > herein. If you have received this message in error, please advise the > sender immediately by sending a reply e-mail and delete this message. Thank > you for your cooperation.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Mon Mar 25 14:08:11 2019 From: beecher at beecher.cc (Tom Beecher) Date: Mon, 25 Mar 2019 10:08:11 -0400 Subject: Incoming SSDP UDP 1900 filtering In-Reply-To: <41650741-a196-5b1c-6965-17b487597bfe@ninjabadger.net> References: <5C989122.7030704@yahoo.fr> <41650741-a196-5b1c-6965-17b487597bfe@ninjabadger.net> Message-ID: If your edge ingress ACLs are not 100% in sync all the time, you will inevitably have Really Weird Stuff happen that will end up taking forever to diagnose. You will eventually end up closing off a port that something else needs to work properly, and now you have to figure out how to resolve that. Packet filtering is more computationally taxing than just routing is. Your edge equipment is likely going to be built for maximum routing efficiency. Trying to bite off too much filtering there increases your risk of legit traffic being tossed on the floor. On Mon, Mar 25, 2019 at 6:41 AM Tom Hill wrote: > On 25/03/2019 09:17, Sean Donelan wrote: > > Its always a bad idea to do packet filtering at your bgp border. > > > Wild assertion. Why? > > DoS mitigation, iACLs, BGP security... I can think of lots of very > sensible reasons. > > -- > Tom > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Mon Mar 25 14:31:57 2019 From: sean at donelan.com (Sean Donelan) Date: Mon, 25 Mar 2019 10:31:57 -0400 (EDT) Subject: Incoming SSDP UDP 1900 filtering In-Reply-To: <41650741-a196-5b1c-6965-17b487597bfe@ninjabadger.net> References: <5C989122.7030704@yahoo.fr> <41650741-a196-5b1c-6965-17b487597bfe@ninjabadger.net> Message-ID: On Mon, 25 Mar 2019, Tom Hill wrote: > On 25/03/2019 09:17, Sean Donelan wrote: >> Its always a bad idea to do packet filtering at your bgp border. > > Wild assertion. Why? My mistake trying to keep it simple. I should have just posted Barry Greene's link. http://www.senki.org/exploitable-port-filtering/ From bryan at shout.net Mon Mar 25 16:26:25 2019 From: bryan at shout.net (Bryan Holloway) Date: Mon, 25 Mar 2019 11:26:25 -0500 Subject: Incoming SSDP UDP 1900 filtering In-Reply-To: References: <5C989122.7030704@yahoo.fr> <41650741-a196-5b1c-6965-17b487597bfe@ninjabadger.net> Message-ID: <944006a8-8766-a016-9b3f-8dec1fdea8d3@shout.net> On 3/25/19 9:08 AM, Tom Beecher wrote: > If your edge ingress ACLs are not 100% in sync all the time, you will > inevitably have Really Weird Stuff happen that will end up taking > forever to diagnose. > > You will eventually end up closing off a port that something else needs > to work properly, and now you have to figure out how to resolve that. > > Packet filtering is more computationally taxing than just routing is. > Your edge equipment is likely going to be built for maximum routing > efficiency. Trying to bite off too much filtering there increases your > risk of legit traffic being tossed on the floor. Not necessarily disagreeing with your posits here, but, empirically speaking, we've had ACLs for stuff like this for years without any incidents or consternation. And we are careful to ensure that any updates are pushed to all edge ingresses. > On Mon, Mar 25, 2019 at 6:41 AM Tom Hill > wrote: > > On 25/03/2019 09:17, Sean Donelan wrote: > > Its always a bad idea to do packet filtering at your bgp border. > > > Wild assertion. Why? > > DoS mitigation, iACLs, BGP security... I can think of lots of very > sensible reasons. > > -- > Tom > From sean at donelan.com Mon Mar 25 16:40:58 2019 From: sean at donelan.com (Sean Donelan) Date: Mon, 25 Mar 2019 12:40:58 -0400 (EDT) Subject: Incoming SSDP UDP 1900 filtering In-Reply-To: <944006a8-8766-a016-9b3f-8dec1fdea8d3@shout.net> References: <5C989122.7030704@yahoo.fr> <41650741-a196-5b1c-6965-17b487597bfe@ninjabadger.net> <944006a8-8766-a016-9b3f-8dec1fdea8d3@shout.net> Message-ID: On Mon, 25 Mar 2019, Bryan Holloway wrote: > And we are careful to ensure that any updates are pushed to all edge > ingresses. BGP-edge filters don't help with customer-to-customer packets within the same ISP BGP autonomous area. So you would need CPE customer-edge filters anyway. A small ISP might be able to handle individual customer filters on their backbone routers, but that way leads to insane network engineers. See Barry Greene's page for the list of all the pro's & con's of different alternatives. There are very few new ideas, just new people rediscovering old ideas. From saku at ytti.fi Mon Mar 25 16:43:35 2019 From: saku at ytti.fi (Saku Ytti) Date: Mon, 25 Mar 2019 18:43:35 +0200 Subject: Incoming SSDP UDP 1900 filtering In-Reply-To: References: <5C989122.7030704@yahoo.fr> <41650741-a196-5b1c-6965-17b487597bfe@ninjabadger.net> Message-ID: Hey Tom, > If your edge ingress ACLs are not 100% in sync all the time, you will inevitably have Really Weird Stuff happen that will end up taking forever to diagnose. You may at some cases have hard to troubleshoot issues, which is true for everything, even when perfectly configured, because software is not perfect. However choosing to do iACL is still something many networks choose to do, because the upside is worth the complexity to them. > Packet filtering is more computationally taxing than just routing is. Your edge equipment is likely going to be built for maximum routing efficiency. Trying to bite off too much filtering there increases your risk of legit traffic being tossed on the floor. Depends on implementation, on some implementations it is zero-cost on some it is not. On most implementations it's very cheap, particularly compared to say uRPF. It seems your position is 'i don't know how ACL works on my platforms and i don't trust myself to write ACL, so i should not do them', which is perfectly valid position under those constrains, but other networks have other constrains under which it is no longer valid proposal to omit doing iACL. I would encourage networks to continue deploying iACL and consider it BCP. iACL removes attack surface and protects you from host of known and unknown SIRT issues. -- ++ytti From beecher at beecher.cc Mon Mar 25 16:54:45 2019 From: beecher at beecher.cc (Tom Beecher) Date: Mon, 25 Mar 2019 12:54:45 -0400 Subject: Incoming SSDP UDP 1900 filtering In-Reply-To: References: <5C989122.7030704@yahoo.fr> <41650741-a196-5b1c-6965-17b487597bfe@ninjabadger.net> Message-ID: "It seems your position is 'i don't know how ACL works on my platforms and i don't trust myself to write ACL, so i should not do them'," That is not my position at all, but thanks. On Mon, Mar 25, 2019 at 12:43 PM Saku Ytti wrote: > Hey Tom, > > > If your edge ingress ACLs are not 100% in sync all the time, you will > inevitably have Really Weird Stuff happen that will end up taking forever > to diagnose. > > You may at some cases have hard to troubleshoot issues, which is true > for everything, even when perfectly configured, because software is > not perfect. However choosing to do iACL is still something many > networks choose to do, because the upside is worth the complexity to > them. > > > Packet filtering is more computationally taxing than just routing is. > Your edge equipment is likely going to be built for maximum routing > efficiency. Trying to bite off too much filtering there increases your risk > of legit traffic being tossed on the floor. > > Depends on implementation, on some implementations it is zero-cost on > some it is not. On most implementations it's very cheap, particularly > compared to say uRPF. It seems your position is 'i don't know how ACL > works on my platforms and i don't trust myself to write ACL, so i > should not do them', which is perfectly valid position under those > constrains, but other networks have other constrains under which it is > no longer valid proposal to omit doing iACL. > > I would encourage networks to continue deploying iACL and consider it > BCP. iACL removes attack surface and protects you from host of known > and unknown SIRT issues. > > -- > ++ytti > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Mon Mar 25 17:18:32 2019 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 25 Mar 2019 12:18:32 -0500 (CDT) Subject: Comcast XB6 Blocking TFTP In-Reply-To: <1370124564.5731.1553534117166.JavaMail.mhammett@ThunderFuck> Message-ID: <2079383401.5744.1553534308903.JavaMail.mhammett@ThunderFuck> Have any of you seen the Comcast XB6 modem blocking TFTP and some SIP requests? We put the modem into bridge mode and TFTP requests are successful. Reset it, set security to the lowest setting, disable the firewall... no TFTP requests pass. Modem\Router - cable - laptop. Of course we can't call into support because the customer is out of town and thus we're unable to authenticate ourselves to support (not that we tried). ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Mon Mar 25 18:38:07 2019 From: sean at donelan.com (Sean Donelan) Date: Mon, 25 Mar 2019 14:38:07 -0400 (EDT) Subject: Bay Area: Help test Earthquake Early Warning System Message-ID: This is being covered on local San Francisco Bay Area media, but if network engineers aren't paying attention to the local news. Here is an opportunity for tech folks in the Oakland area to participate in the Earthquake Early Warning Test. TEST INFORMATION Date: Wednesday, March 27th, 2019 Time: 11:00AM Message: “TEST of the CA Earthquake Warning System. No action required. THIS IS A TEST.” Location: Downtown Oakland (Lakeside commercial neighborhood) with bleedover into adjacent areas depending on cell tower RF propagation. Part of this year's test is measuring how quickly earthquake warning alerts are propagated through different emergency alert channels. The future goal is transmitting earthquake alerts in less than 3 seconds. That is unlikely with current systems. Instead the test will help measure current alert system propagation delays. If you have access to accurate clocks, and a cell phone, and are in the Oakland area on Wednesday. https://www.caloes.ca.gov/cal-oes-divisions/earthquake-tsunami-volcano-programs/california-earthquake-early-warning-program Please participate in a citizen science test to see how fast these alerts can be transmitted to cell phones. For this test to be effective, you need to take the following steps: 1) Before the test starts, using either your cell phone or your desktop computer go to www.time.is. 2) Starting a few minutes in advance of the scheduled alert time (11:00AM Pacific), keep a close watch on your cell phone and www.time.is note the exact time--to the nearest second, if you can--at which the alert first arrives on your phone. This alert will have the heading "Emergency Alert", and this message: “TEST of the CA Earthquake Warning System. No action required. THIS IS A TEST.” 3) Please take this survey, armed with the time (to the second) you received the alert. https://www.surveymonkey.com/r/WEATESTSHAKEALERT Yeah, I know. Some folks on this list likely have nano-second synchronized clocks and will debate whether the propagation delay is taking into account the correct einstein relativity offset of the earth's surface in the oakland bay area (I just made that techno-babble up). Just do the reasonable thing, and help out the scientists :-) From john at alcock.org Mon Mar 25 19:14:07 2019 From: john at alcock.org (John Alcock) Date: Mon, 25 Mar 2019 15:14:07 -0400 Subject: FW: softlayer.com In-Reply-To: References: <6015A8EB-2D06-4008-87BB-5517B1D622F8@neko.id.au> Message-ID: Well, It has been a challenge. I am not sure who helped or fixed the problem, but now anything hosted on softlayer.com is responding. I am not sure if there was anyone lurking on the list that helped out, but if you are, Thank You. I have a batch of new stuff not working, but they may be one off's. I am trying to find a pattern. John On Fri, Mar 22, 2019 at 2:32 PM Travis Garrison wrote: > Traceroute from here if it helps > > > > Tracing route to 138-43-128-1.reserved.highland.net [138.43.128.1] > > over a maximum of 30 hops: > > > > 1 <1 ms <1 ms <1 ms [REDACTED] > > 2 <1 ms <1 ms <1 ms [REDACTED] > > 3 1 ms 1 ms <1 ms [REDACTED] > > 4 1 ms <1 ms <1 ms [REDACTED] > > 5 6 ms 6 ms 6 ms v313.core1.mci3.he.net [216.218.213.141] > > 6 16 ms 16 ms 16 ms 100ge10-2.core1.dal1.he.net > [184.105.81.206] > > 7 26 ms 26 ms 26 ms > xo-as15-as2828.10gigabitethernet6-7.core1.dal1.he.net [184.105.255.78] > > 8 40 ms 39 ms 40 ms 207.88.14.198.ptr.us.xo.net > [207.88.14.198] > > 9 40 ms 39 ms 40 ms 207.88.12.178.ptr.us.xo.net > [207.88.12.178] > > 10 39 ms 39 ms 39 ms 216.156.16.239.ptr.us.xo.net > [216.156.16.239] > > 11 48 ms 48 ms 48 ms > ip65-46-198-198.z198-46-65.customer.algx.net [65.46.198.198] > > 12 41 ms 41 ms 41 ms > occm-6.dhcp.grp1-rng1.tncsvl.blomand.net.57.131.192.in-addr.arpa > [192.131.57.6] > > 13 * * * Request timed out. > > > > Thanks > > Travis > > > > *From:* NANOG *On Behalf Of *Siyuan Miao > *Sent:* Friday, March 22, 2019 9:22 AM > *To:* Nikolas Geyer > *Cc:* nanog at nanog.org > *Subject:* Re: softlayer.com > > > > Perhaps it won't work because their customer support will ask you for > bi-directional traceroute and refused to forward to backbone team. > > > > Then they'll say it's not their fault and you can see the packet is > dropped outside our network. > > > > Here's a sample traceroute from SoftLayer Washington, San Jose and Seattle > in case someone needs it: > > > > aveline at iad02-sl01:~$ mtr 138.43.128.1 --report-wide > > Start: Fri Mar 22 17:20:42 2019 > > HOST: iad02-sl01 Loss% Snt Last Avg > Best Wrst StDev > > 1.|-- [REDACTED] 0.0% 10 1.4 > 1.5 0.8 3.7 1.0 > > 2.|-- ae13.dar02.wdc01.networklayer.com 0.0% 10 0.5 > 3.3 0.4 28.6 8.8 > > 3.|-- ae9.bbr01.eq01.wdc02.networklayer.com 0.0% 10 0.8 > 0.8 0.7 1.0 0.0 > > 4.|-- eqix-dc5.intellifiber.com 0.0% 10 0.8 > 1.2 0.8 2.2 0.3 > > 5.|-- ae13-0.cr02.asbn01-va.us.windstream.net 0.0% 10 0.9 > 0.9 0.9 1.0 0.0 > > 6.|-- ae11-0.cr01.atln02-ga.us.windstream.net 0.0% 10 15.6 > 16.1 15.6 17.4 0.5 > > 7.|-- ae0-0.pe06.atln02-ga.us.windstream.net 0.0% 10 17.4 > 16.1 15.9 17.4 0.3 > > 8.|-- h43.88.198.64.static.ip.windstream.net 0.0% 10 24.7 > 24.8 24.6 24.9 0.0 > > 9.|-- east.tndodge-21.static.tncsvl.blomand.net 0.0% 10 22.6 > 22.8 22.5 23.8 0.0 > > 10.|-- ??? 100.0 10 0.0 > 0.0 0.0 0.0 0.0 > > > > aveline at sjc03-sl01:~$ mtr 138.43.128.1 --report-wide > > Start: Fri Mar 22 16:21:04 2019 > > HOST: sjc03-sl01 Loss% Snt Last Avg > Best Wrst StDev > > 1.|-- [REDACTED] 0.0% 10 2.4 > 2.0 0.3 14.3 4.3 > > 2.|-- ae0.dar02.sjc01.networklayer.com 0.0% 10 1.0 > 0.5 0.3 1.3 0.0 > > 3.|-- ae9.bbr01.eq01.sjc02.networklayer.com 0.0% 10 0.8 > 0.8 0.7 0.9 0.0 > > 4.|-- eqix-sv1.windstream.com 0.0% 10 0.9 > 0.9 0.8 1.1 0.0 > > 5.|-- ae6-0.cr02.lsaj01-ca.us.windstream.net 0.0% 10 11.6 > 11.5 11.5 11.6 0.0 > > 6.|-- ae-11-0.cr01.dlls01-tx.us.windstream.net 0.0% 10 42.6 > 42.7 42.5 43.4 0.0 > > 7.|-- ae7-0.cr02.atln02-ga.us.windstream.net 0.0% 10 64.0 > 65.6 63.9 74.2 3.4 > > 8.|-- ae1-0.pe06.atln02-ga.us.windstream.net 0.0% 10 62.3 > 62.7 62.2 66.9 1.5 > > 9.|-- h43.88.198.64.static.ip.windstream.net 0.0% 10 71.9 > 72.0 71.9 72.2 0.0 > > 10.|-- east.tndodge-21.static.tncsvl.blomand.net 0.0% 10 69.9 > 68.8 68.6 69.9 0.3 > > 11.|-- ??? 100.0 10 0.0 > 0.0 0.0 0.0 0.0 > > > > aveline at sea04-sl01:~$ mtr 138.43.128.1 --report-wide > > Start: Fri Mar 22 08:19:09 2019 > > HOST: sea04-sl01 Loss% Snt Last Avg > Best Wrst StDev > > 1.|-- [REDACTED] 0.0% 10 0.7 > 1.2 0.7 1.8 0.0 > > 2.|-- ae12.dar02.sr01.sea01.networklayer.com 0.0% 10 0.6 > 0.7 0.5 1.3 0.0 > > 3.|-- ae9.bbr01.wb01.sea02.networklayer.com 0.0% 10 1.2 > 1.0 0.7 1.5 0.0 > > 4.|-- six.seattle-wa.us.windstream.net 0.0% 10 1.5 > 1.0 0.7 1.7 0.0 > > 5.|-- ae12-0.cr01.chcg01-il.us.windstream.net 0.0% 10 41.1 > 41.2 41.0 41.6 0.0 > > 6.|-- ae17-0.cr02.chcg01-il.us.windstream.net 0.0% 10 41.1 > 41.4 41.1 42.0 0.0 > > 7.|-- ae10-0.cr01.atln02-ga.us.windstream.net 0.0% 10 63.8 > 64.4 63.5 71.1 2.3 > > 8.|-- ae0-0.pe06.atln02-ga.us.windstream.net 0.0% 10 63.7 > 63.7 63.5 64.0 0.0 > > 9.|-- h43.88.198.64.static.ip.windstream.net 0.0% 10 71.6 > 71.8 71.5 72.8 0.0 > > 10.|-- east.tndodge-21.static.tncsvl.blomand.net 0.0% 10 71.8 > 70.8 70.2 71.8 0.3 > > 11.|-- ??? 100.0 10 0.0 > 0.0 0.0 0.0 0.0 > > > > > > Regards, > > Siyuan Miao > > > > > > On Fri, Mar 22, 2019 at 10:10 PM Nikolas Geyer wrote: > > This is the best approach. Have run into this problem a few times and had > zero success getting the filters removed without having SL customers log > tickets with support. Verbiage needs to be “this prefix is blocked, please > escalate to your backbone team”. > > > > Sent from my iPhone > > > On Mar 22, 2019, at 9:56 AM, Forrest Christian (List Account) < > lists at packetflux.com> wrote: > > Another idea... > > > > Have you tried reaching out to some of the blocked sites? They likely > have better contact information than is available publicly, especially a > larger one like indeed. > > > > On Thu, Mar 21, 2019, 3:41 PM John Alcock wrote: > > Still looking for anyone from softlayer.com > > > > It has been a challenge. Anything hosted by softlayer.com is being > blocked. > > > > Here is a small list so far > > > > windowbook.tpondemand.com > ahainstructornetwork.americanheart.org > clover.com > Cebroker.com > Softlayer.com > indeed.com & Enforce Staffing > > > > It is growing every day. > > > > John > > > > On Wed, Mar 20, 2019 at 12:35 PM John Alcock wrote: > > Afternoon, > > > > Thought I would start a new thread. After researching, traceroutes, etc, > I think I found my problem. > > > > 9 out of the 10 sites that subscribers on my new block is being hosted by > softlayer. > > > > Anyone on the list have contacts with softlayer. Right now I have an > email to abuse. The support line will not help me out. > > > > John > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake at ispn.net Mon Mar 25 21:29:35 2019 From: blake at ispn.net (Blake Hudson) Date: Mon, 25 Mar 2019 16:29:35 -0500 Subject: Comcast XB6 Blocking TFTP In-Reply-To: <2079383401.5744.1553534308903.JavaMail.mhammett@ThunderFuck> References: <2079383401.5744.1553534308903.JavaMail.mhammett@ThunderFuck> Message-ID: You may already be aware, but TFTP - like FTP - is not a NAT friendly protocol and requires a helper or ALG to inspect the control channel in order to open up and translate the connections used by the data channel (which use unrelated high numbered UDP ports). If TFTP is not working when NAT is enabled, it sounds like that modem does not have a TFTP ALG included or enabled. I have no experience with that model personally, but it's not a unique problem. Workarounds are to not use NAT, purchase a better NAT router, define a DMZ host, or use a NAT friendly protocol like SCP. Sorry about SIP. That's also not a NAT friendly protocol, and while some of the same workarounds still apply there are generally not numerous or better alternatives like there are for file transfer protocols that replace FTP/TFTP. --Blake Mike Hammett wrote on 3/25/2019 12:18 PM: > Have any of you seen the Comcast XB6 modem blocking TFTP and some SIP > requests? > > We put the modem into bridge mode and TFTP requests are successful. > Reset it, set security to the lowest setting, disable the firewall... >  no TFTP requests pass. > > Modem\Router - cable - laptop. > > Of course we can't call into support because the customer is out of > town and thus we're unable to authenticate ourselves to support (not > that we tried). > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elmi at 4ever.de Tue Mar 26 07:56:05 2019 From: elmi at 4ever.de (Elmar K. Bins) Date: Tue, 26 Mar 2019 08:56:05 +0100 Subject: AS112 contact Message-ID: <20190326075605.GH711@anx-nb3810.home> Hi guys, I hope this is only slightly off-topic... I'm looking for the correct address for AS112, 112 at root-servers.org keeps bouncing whatever I try. If anybody can drop me a line...much appreciated. Cheers, Elmar. From jeroen at massar.ch Tue Mar 26 07:59:53 2019 From: jeroen at massar.ch (Jeroen Massar) Date: Tue, 26 Mar 2019 08:59:53 +0100 Subject: AS112 contact In-Reply-To: <20190326075605.GH711@anx-nb3810.home> References: <20190326075605.GH711@anx-nb3810.home> Message-ID: On 2019-03-26 08:56, Elmar K. Bins wrote: > Hi guys, > > I hope this is only slightly off-topic... > > I'm looking for the correct address for AS112, 112 at root-servers.org > keeps bouncing whatever I try. > > If anybody can drop me a line...much appreciated. You can subscribe/post to: https://lists.dns-oarc.net/mailman/listinfo/as112-ops There is a whole bunch of folks behind AS112 eh ;) See https://www.as112.net for more details. Greets, Jeroen From matt at conundrum.com Tue Mar 26 08:04:46 2019 From: matt at conundrum.com (Matthew Pounsett) Date: Tue, 26 Mar 2019 09:04:46 +0100 Subject: AS112 contact In-Reply-To: <20190326075605.GH711@anx-nb3810.home> References: <20190326075605.GH711@anx-nb3810.home> Message-ID: On Tue, 26 Mar 2019 at 08:57, Elmar K. Bins wrote: > Hi guys, > > I hope this is only slightly off-topic... > > I'm looking for the correct address for AS112, 112 at root-servers.org > keeps bouncing whatever I try. > > If anybody can drop me a line...much appreciated. > There is also ops at as112.net, which comes to me. That address at least shows up here[0] ... if there are other places we (DNS-OARC, as the steward of the AS112 resources) could publish that address please let me know. The root-servers.org email addresses for AS112 operations have been dead for some time. Long enough that I don't recall when that happened. If they are still published somewhere, please also let us know about that so that we can get it fixed. [0]: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From drais at icantclick.org Wed Mar 27 02:41:30 2019 From: drais at icantclick.org (david raistrick) Date: Tue, 26 Mar 2019 22:41:30 -0400 Subject: residential/smb internet access in 2019 - help? Message-ID: folks, I've been away from nanog for a long time - and away from the ISP world for longer. Looking at a house in a new area, at&t copper splice box out front, bellsouth fiber markers as well (yes, that's usually just passing by. but it's there). Owners since '82 said the telephone company was AT&T - but the New AT&T apparently no longer offers phone or internet service there. This is located in a semi-rural area between Ocala and Gainesville Florida (Micanopy, specifically). I knew the state of residential service was in sorry shape - but from what I'm reading, it seems to be worse than I'd though possible. Anyone have any suggestions for service options? I'm cool with dark fiber, if it comes down to that (and can be price sanely and terminated somewhere useful), but it seems like there -should- still be CLEC/DLECs or just plain resellers in business who still have access to resources that are in the ground. My business operates from home - so obviously quality service is a priority, and I'm willing to pay for it within reason. Business plans are certainly an option as well. I've confirmed with all of the known players via their front channels - att, windstream, centurylink, frontier, cox/comcast/spectre. Via backchannels I've confirmed that cox has fiber in the ground 1.4 miles away - straight shot down a dirt road (same one with the BS fiber markers). I have a lead on a couple of tower shots - but there's a big (for florida) ridge between us, and I might have to build 3-400ft to hit anything (speculatively). Anyone have local area or other knowledge that might be helpful? I'd hate to miss out on this house - it's a lot of things we love - but cell or sat only for internet access just isn't going to fly. thanks guys. ...david -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Wed Mar 27 03:29:25 2019 From: ross at tajvar.io (Ross Tajvar) Date: Tue, 26 Mar 2019 23:29:25 -0400 Subject: residential/smb internet access in 2019 - help? In-Reply-To: References: Message-ID: This is a common problem with no good solution. Fiber buildouts are almost always insanely expensive. If you can get one at a more reasonable cost, or more likely if you can sign a contract of a sufficient length to convince the carrier to subsidize it, you may be able to get good service that way. The tower thing could also work if you want to spend the time/money on building and maintaining it. And also provided you can get a permit, etc. But most likely you're just out of luck. On Tue, Mar 26, 2019, 10:44 PM david raistrick wrote: > folks, > > I've been away from nanog for a long time - and away from the ISP world > for longer. > > Looking at a house in a new area, at&t copper splice box out front, > bellsouth fiber markers as well (yes, that's usually just passing by. but > it's there). Owners since '82 said the telephone company was AT&T - but > the New AT&T apparently no longer offers phone or internet service there. > > This is located in a semi-rural area between Ocala and Gainesville Florida > (Micanopy, specifically). > > I knew the state of residential service was in sorry shape - but from what > I'm reading, it seems to be worse than I'd though possible. > > Anyone have any suggestions for service options? I'm cool with dark > fiber, if it comes down to that (and can be price sanely and terminated > somewhere useful), but it seems like there -should- still be CLEC/DLECs or > just plain resellers in business who still have access to resources that > are in the ground. > > My business operates from home - so obviously quality service is a > priority, and I'm willing to pay for it within reason. Business plans are > certainly an option as well. > > I've confirmed with all of the known players via their front channels - > att, windstream, centurylink, frontier, cox/comcast/spectre. > > Via backchannels I've confirmed that cox has fiber in the ground 1.4 miles > away - straight shot down a dirt road (same one with the BS fiber markers). > I have a lead on a couple of tower shots - but there's a big (for > florida) ridge between us, and I might have to build 3-400ft to hit > anything (speculatively). > > Anyone have local area or other knowledge that might be helpful? > > I'd hate to miss out on this house - it's a lot of things we love - but > cell or sat only for internet access just isn't going to fly. > > > thanks guys. > > ...david > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From drais at icantclick.org Wed Mar 27 03:34:13 2019 From: drais at icantclick.org (david raistrick) Date: Tue, 26 Mar 2019 23:34:13 -0400 Subject: residential/smb internet access in 2019 - help? In-Reply-To: References: Message-ID: On Tue, Mar 26, 2019 at 11:29 PM Ross Tajvar wrote: > But most likely you're just out of luck. > it's really amazing that this is still the case, with our effectively internet based economy now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rvandolson at esri.com Wed Mar 27 03:36:41 2019 From: rvandolson at esri.com (Ray Van Dolson) Date: Wed, 27 Mar 2019 03:36:41 +0000 Subject: residential/smb internet access in 2019 - help? In-Reply-To: References: Message-ID: Have been through something similar recently with CenturyLink extending fiber service to a residence where only 3Mbps DSL was available previously. Total costs ended up being in the mid five figures range (though I don’t know how far they needed to extend fiber). We amortized over a multi-year term on top of an already four figure MRC. 50Mbps service in the end. Probably not worth it for most. Ray From: NANOG On Behalf Of Ross Tajvar Sent: Tuesday, March 26, 2019 8:29 PM To: david raistrick Cc: North American Network Operators' Group Subject: Re: residential/smb internet access in 2019 - help? This is a common problem with no good solution. Fiber buildouts are almost always insanely expensive. If you can get one at a more reasonable cost, or more likely if you can sign a contract of a sufficient length to convince the carrier to subsidize it, you may be able to get good service that way. The tower thing could also work if you want to spend the time/money on building and maintaining it. And also provided you can get a permit, etc. But most likely you're just out of luck. On Tue, Mar 26, 2019, 10:44 PM david raistrick > wrote: folks, I've been away from nanog for a long time - and away from the ISP world for longer. Looking at a house in a new area, at&t copper splice box out front, bellsouth fiber markers as well (yes, that's usually just passing by. but it's there). Owners since '82 said the telephone company was AT&T - but the New AT&T apparently no longer offers phone or internet service there. This is located in a semi-rural area between Ocala and Gainesville Florida (Micanopy, specifically). I knew the state of residential service was in sorry shape - but from what I'm reading, it seems to be worse than I'd though possible. Anyone have any suggestions for service options? I'm cool with dark fiber, if it comes down to that (and can be price sanely and terminated somewhere useful), but it seems like there -should- still be CLEC/DLECs or just plain resellers in business who still have access to resources that are in the ground. My business operates from home - so obviously quality service is a priority, and I'm willing to pay for it within reason. Business plans are certainly an option as well. I've confirmed with all of the known players via their front channels - att, windstream, centurylink, frontier, cox/comcast/spectre. Via backchannels I've confirmed that cox has fiber in the ground 1.4 miles away - straight shot down a dirt road (same one with the BS fiber markers). I have a lead on a couple of tower shots - but there's a big (for florida) ridge between us, and I might have to build 3-400ft to hit anything (speculatively). Anyone have local area or other knowledge that might be helpful? I'd hate to miss out on this house - it's a lot of things we love - but cell or sat only for internet access just isn't going to fly. thanks guys. ...david -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Wed Mar 27 03:57:01 2019 From: ross at tajvar.io (Ross Tajvar) Date: Tue, 26 Mar 2019 23:57:01 -0400 Subject: residential/smb internet access in 2019 - help? In-Reply-To: References: Message-ID: On Tue, Mar 26, 2019, 11:34 PM david raistrick wrote: > On Tue, Mar 26, 2019 at 11:29 PM Ross Tajvar wrote: > > >> But most likely you're just out of luck. >> > > it's really amazing that this is still the case, with our effectively > internet based economy now. > > Agreed....this is why monopolies are bad and municipal fiber is good. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joly at punkcast.com Wed Mar 27 04:39:00 2019 From: joly at punkcast.com (Joly MacFie) Date: Wed, 27 Mar 2019 00:39:00 -0400 Subject: residential/smb internet access in 2019 - help? In-Reply-To: References: Message-ID: Is there any chance LEO operators like OneWeb etc will make a difference on this front, and, if so, when? joly On Tue, Mar 26, 2019 at 11:57 PM Ross Tajvar wrote: > On Tue, Mar 26, 2019, 11:34 PM david raistrick > wrote: > >> On Tue, Mar 26, 2019 at 11:29 PM Ross Tajvar wrote: >> >> >>> But most likely you're just out of luck. >>> >> >> it's really amazing that this is still the case, with our effectively >> internet based economy now. >> >> > > Agreed....this is why monopolies are bad and municipal fiber is good. > >> -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast -------------------------------------------------------------- - -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Wed Mar 27 05:30:34 2019 From: ross at tajvar.io (Ross Tajvar) Date: Wed, 27 Mar 2019 01:30:34 -0400 Subject: residential/smb internet access in 2019 - help? In-Reply-To: References: Message-ID: On Wed, Mar 27, 2019, 12:30 AM Mike Bolitho wrote: > Agreed....this is why monopolies are bad and municipal fiber is good. >> > > It's not like municipal fiber has some magic spell to make last mile > affordable though. On OP's instance he would run into the same issue and > would be paying that five figure amount to bring FTTP. Municipal fiber is > only good if you happen to live where a municipality has already buried > conduit. > > I'm not saying we should support monopolistic practices, but "municipal > fiber everywhere!" isn't necessarily the answer either. > That's fair. What I really meant, and didn't take the time to think through and express properly, was this: financing a large fiber buildout like it's a long-term investment, rather than something that should make back its capital cost in 1-3 years, gets fiber to more people. Most commercial ISPs do not want to do this because they want immediate profit. Municipalities are used to making long-term infrastructure investments (like bridges, etc.) and are more amenable to doing it with fiber. Even if there were a municipality which had done a fiber buildout near OP's desired house, he may have still run into the same issue of no fiber being close enough to be financially viable. But the more fiber plant there is, the less likely that scenario becomes. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bryan at bryanfields.net Wed Mar 27 09:05:27 2019 From: Bryan at bryanfields.net (Bryan Fields) Date: Wed, 27 Mar 2019 05:05:27 -0400 Subject: residential/smb internet access in 2019 - help? In-Reply-To: References: Message-ID: <4a6b8c19-7539-1553-d92b-0603d824086e@bryanfields.net> On 3/26/19 10:41 PM, david raistrick wrote: > Looking at a house in a new area, at&t copper splice box out front, > bellsouth fiber markers as well (yes, that's usually just passing by. but > it's there). Owners since '82 said the telephone company was AT&T - but > the New AT&T apparently no longer offers phone or internet service there. > > This is located in a semi-rural area between Ocala and Gainesville Florida > (Micanopy, specifically). > > I'd hate to miss out on this house - it's a lot of things we love - but > cell or sat only for internet access just isn't going to fly. Order the service and have it installed before you close. Test it and ensure it's good. If the buyer won't allow it, walk. You _cannot_ trust some carrier to tell you what you have available before it's actually turned up. Time and time again I see people close on a home where Frontier or Cox or whoever says they have fiber there, and then after the move in, 4-8 week later you find out they don't have anything. Across the road, yes, but all you can get is POTS and IDSL/ISDN. Yep, is 2019 ISDN/IDSL is the only broadband service some people can get. It's also going to be 100+ USD per month. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From nanog at ics-il.net Wed Mar 27 11:50:14 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 27 Mar 2019 06:50:14 -0500 (CDT) Subject: residential/smb internet access in 2019 - help? In-Reply-To: References: Message-ID: <580616152.7202.1553687413885.JavaMail.mhammett@ThunderFuck> https://broadbandnow.com/Florida/Micanopy?zip=32667# You might want to try neighboring ZIP codes to see what other fixed wireless providers might be convinced to expand. http://svic.net/wireless-broadband-north-florida/ ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "david raistrick" To: "NANOG List" Sent: Tuesday, March 26, 2019 9:41:30 PM Subject: residential/smb internet access in 2019 - help? folks, I've been away from nanog for a long time - and away from the ISP world for longer. Looking at a house in a new area, at&t copper splice box out front, bellsouth fiber markers as well (yes, that's usually just passing by. but it's there). Owners since '82 said the telephone company was AT&T - but the New AT&T apparently no longer offers phone or internet service there. This is located in a semi-rural area between Ocala and Gainesville Florida (Micanopy, specifically). I knew the state of residential service was in sorry shape - but from what I'm reading, it seems to be worse than I'd though possible. Anyone have any suggestions for service options? I'm cool with dark fiber, if it comes down to that (and can be price sanely and terminated somewhere useful), but it seems like there -should- still be CLEC/DLECs or just plain resellers in business who still have access to resources that are in the ground. My business operates from home - so obviously quality service is a priority, and I'm willing to pay for it within reason. Business plans are certainly an option as well. I've confirmed with all of the known players via their front channels - att, windstream, centurylink, frontier, cox/comcast/spectre. Via backchannels I've confirmed that cox has fiber in the ground 1.4 miles away - straight shot down a dirt road (same one with the BS fiber markers). I have a lead on a couple of tower shots - but there's a big (for florida) ridge between us, and I might have to build 3-400ft to hit anything (speculatively). Anyone have local area or other knowledge that might be helpful? I'd hate to miss out on this house - it's a lot of things we love - but cell or sat only for internet access just isn't going to fly. thanks guys. ...david -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog-support at nanog.org Wed Mar 27 13:25:47 2019 From: nanog-support at nanog.org (NANOG Support) Date: Wed, 27 Mar 2019 09:25:47 -0400 Subject: A variety of opportunities to sponsor NANOG 76 and beyond! Message-ID: Our 76th community-wide gathering is June 9-12 in Washington, DC. As one of the largest communities of network engineers, architects, and operators in North America, a NANOG sponsorship provides the greatest level of exposure to our industry’s innovators — all in one place. >From espresso/breakfast/lunch/breaks and evening socials, to a presence at our coveted Beer ‘N Gear event, sponsorships start at just $3,000, and provide a variety of opportunities for you to connect and engage with our community. View premium partnerships View individual meeting sponsorships Have questions? Contact Shawn Winstead, Business Development Specialist: swinstead at nanog.org +1.866.902.1336 ext. 108 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikebolitho at gmail.com Wed Mar 27 04:30:28 2019 From: mikebolitho at gmail.com (Mike Bolitho) Date: Tue, 26 Mar 2019 21:30:28 -0700 Subject: residential/smb internet access in 2019 - help? In-Reply-To: References: Message-ID: > > Agreed....this is why monopolies are bad and municipal fiber is good. > It's not like municipal fiber has some magic spell to make last mile affordable though. On OP's instance he would run into the same issue and would be paying that five figure amount to bring FTTP. Municipal fiber is only good if you happen to live where a municipality has already buried conduit. I'm not saying we should support monopolistic practices, but "municipal fiber everywhere!" isn't necessarily the answer either. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Wed Mar 27 13:30:05 2019 From: randy at psg.com (Randy Bush) Date: Wed, 27 Mar 2019 14:30:05 +0100 Subject: criterio Message-ID: a bit of research has led us to wonder about some (non-hostile or worrisome) net activity of criterio autonomous systems. do any friends of the family know these folk and could introduce me so i can try to learn a bit of ground truth? thanks. randy From nanog at ics-il.net Wed Mar 27 13:36:15 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 27 Mar 2019 08:36:15 -0500 (CDT) Subject: residential/smb internet access in 2019 - help? In-Reply-To: References: Message-ID: <1615550420.7403.1553693774331.JavaMail.mhammett@ThunderFuck> If you're looking to start an ISP, talk to Windstream and Uniti for transport. I can put you in touch with people, should you be interested in going down that route. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "david raistrick" To: "NANOG List" Sent: Tuesday, March 26, 2019 9:41:30 PM Subject: residential/smb internet access in 2019 - help? folks, I've been away from nanog for a long time - and away from the ISP world for longer. Looking at a house in a new area, at&t copper splice box out front, bellsouth fiber markers as well (yes, that's usually just passing by. but it's there). Owners since '82 said the telephone company was AT&T - but the New AT&T apparently no longer offers phone or internet service there. This is located in a semi-rural area between Ocala and Gainesville Florida (Micanopy, specifically). I knew the state of residential service was in sorry shape - but from what I'm reading, it seems to be worse than I'd though possible. Anyone have any suggestions for service options? I'm cool with dark fiber, if it comes down to that (and can be price sanely and terminated somewhere useful), but it seems like there -should- still be CLEC/DLECs or just plain resellers in business who still have access to resources that are in the ground. My business operates from home - so obviously quality service is a priority, and I'm willing to pay for it within reason. Business plans are certainly an option as well. I've confirmed with all of the known players via their front channels - att, windstream, centurylink, frontier, cox/comcast/spectre. Via backchannels I've confirmed that cox has fiber in the ground 1.4 miles away - straight shot down a dirt road (same one with the BS fiber markers). I have a lead on a couple of tower shots - but there's a big (for florida) ridge between us, and I might have to build 3-400ft to hit anything (speculatively). Anyone have local area or other knowledge that might be helpful? I'd hate to miss out on this house - it's a lot of things we love - but cell or sat only for internet access just isn't going to fly. thanks guys. ...david -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Wed Mar 27 13:51:43 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 27 Mar 2019 06:51:43 -0700 Subject: criterio In-Reply-To: References: Message-ID: criterio ASN == ? (I'm sure folk may be able to find more useful into with ASN) On Wed, Mar 27, 2019 at 6:33 AM Randy Bush wrote: > > a bit of research has led us to wonder about some (non-hostile or > worrisome) net activity of criterio autonomous systems. do any friends > of the family know these folk and could introduce me so i can try to > learn a bit of ground truth? > > thanks. > > randy From m.waehlisch at fu-berlin.de Wed Mar 27 14:04:44 2019 From: m.waehlisch at fu-berlin.de (Matthias Waehlisch) Date: Wed, 27 Mar 2019 15:04:44 +0100 Subject: criterio In-Reply-To: References: Message-ID: ASN 19750 ASN 44788 ASN 55569 On Wed, 27 Mar 2019, Christopher Morrow wrote: > criterio ASN == ? (I'm sure folk may be able to find more useful into with ASN) > > On Wed, Mar 27, 2019 at 6:33 AM Randy Bush wrote: > > > > a bit of research has led us to wonder about some (non-hostile or > > worrisome) net activity of criterio autonomous systems. do any friends > > of the family know these folk and could introduce me so i can try to > > learn a bit of ground truth? > > > > thanks. > > > > randy > -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl From greg.kovich at al-enterprise.com Wed Mar 27 13:46:27 2019 From: greg.kovich at al-enterprise.com (Kovich Greg) Date: Wed, 27 Mar 2019 13:46:27 +0000 Subject: residential.smb internet access in 2019 - help? In-Reply-To: References: Message-ID: <1E6994E2-D4DD-4CD8-8A6C-64A28A143475@al-enterprise.com> Good luck David. Even up here in the Chicagoland Comcast footprint, I had a horror story when I moved into my home in 2002 wrt ATT. Anyway, I’m not sure how far you are from Ocala, but they do offer residential internet via their municipal fiber. https://www.ocalafl.org/government/city-departments/telecommunications/residential $60/month for 300 Mbps… ------- Greg Kovich Director, Global Education Sales Alcatel-Lucent Enterprise ALE USA 3015 Abby Lane | Suite 301-B Schererville, IN 46375 t: +1-818-878-4667 m: +1-219-276-2320 e: Greg.Kovich at al-enterprise.com w: www.al-enterprise.com @ALUEnterprise [LinkedIn] [Twitter] [YouTube] [Facebook] [Rainbow] [https://www.al-enterprise.com/en/-/media/assets/internet/images/logo.png] The Alcatel-Lucent name and logo are trademarks of Nokia used under license by ALE. This communication is intended to be received only by the individual or entity to whom or to which it is addressed and may contain information that is privileged/confidential or subject to copyright. Any unauthorized use, copying, review or disclosure of this communication is strictly prohibited. If you have received this communication in error, please delete this message from your e-mail box and information system (including all files and documents attached) and notify the sender by reply email. On Mar 27, 2019, at 7:00 AM, nanog-request at nanog.org wrote: Message: 7 Date: Wed, 27 Mar 2019 01:30:34 -0400 From: Ross Tajvar > To: Mike Bolitho > Cc: david raistrick >, "North American Network Operators' Group" > Subject: Re: residential/smb internet access in 2019 - help? Message-ID: > Content-Type: text/plain; charset="utf-8" On Wed, Mar 27, 2019, 12:30 AM Mike Bolitho > wrote: Agreed....this is why monopolies are bad and municipal fiber is good. It's not like municipal fiber has some magic spell to make last mile affordable though. On OP's instance he would run into the same issue and would be paying that five figure amount to bring FTTP. Municipal fiber is only good if you happen to live where a municipality has already buried conduit. I'm not saying we should support monopolistic practices, but "municipal fiber everywhere!" isn't necessarily the answer either. That's fair. What I really meant, and didn't take the time to think through and express properly, was this: financing a large fiber buildout like it's a long-term investment, rather than something that should make back its capital cost in 1-3 years, gets fiber to more people. Most commercial ISPs do not want to do this because they want immediate profit. Municipalities are used to making long-term infrastructure investments (like bridges, etc.) and are more amenable to doing it with fiber. Even if there were a municipality which had done a fiber buildout near OP's desired house, he may have still run into the same issue of no fiber being close enough to be financially viable. But the more fiber plant there is, the less likely that scenario becomes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsk at gsp.org Wed Mar 27 15:09:20 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 27 Mar 2019 11:09:20 -0400 Subject: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland) In-Reply-To: <75392.1552953758@segfault.tristatelogic.com> References: <75392.1552953758@segfault.tristatelogic.com> Message-ID: <20190327150920.GA26842@gsp.org> On Mon, Mar 18, 2019 at 05:02:38PM -0700, Ronald F. Guilmette wrote: > I generated the following survey, on the fly, last night, > based on a simple reverse DNS scan of the evidently relevant addrdess > ranges: > > https://pastebin.com/raw/WtM0Y5yC > > As anyone who isn't as blind as a bat can easily see, there's a bit of a > pattern here. I finally found time to check this out. And I have to ask: how in the heck did anybody accept this operation as a customer? Because it's obvious on inspection -- of the information in that paste -- that they're abusers. Let me 'splain. First, domains in certain TLDs should be considered as -- at best -- dubious until proven otherwise, because those TLDs are well-known as abuse magnets. Every domain in this sample falls in that category. Anyone making mass use of domains in those TLDs is up to something abusive. Second, anyone making mass requests for PTR records for random subdomains is up to something abusive. Third, anyone mass-registering domains whose names are permutations of each other is up to something abusive. (I'm not talking about someone registering a couple of domains that are plausible typos of a primary one or engaging in defensive registrations across a few TLDs. Look at the list, this is obviously quite different from those cases.) Fourth, anyone mass-registering domains whose names are intended to be typo'd and/or misread is up to something abusive. Anybody doing all of the above is not only up to something abusive, but they're standing on a rooftop screaming it through a bullhorn. The word "mass" is key throughout not only because it is a highly reliable indicator of ensuing abuse but because its nature makes detecting this up front quite easy. Once I got to it, it took me less than a minute of scanning that list to determine that there is absolutely no way I would accept this operation as a customer. I recognize that not everyone everyone has my experience in this area, but surely every operation should have someone equipped with modest experience and and a skeptical eye who screens new customers, and, at *minimum*, puts them on hold while some due diligence takes place. It's much easier (and cheaper) to refuse service to operations like this than to deal with the fallout that will inevitably ensue. It's also much better for the rest of us. So: how did these people ever get in the door? ---rsk From aveline at misaka.io Wed Mar 27 15:46:21 2019 From: aveline at misaka.io (Siyuan Miao) Date: Wed, 27 Mar 2019 23:46:21 +0800 Subject: Banned by Akamai (or some websites hosted with Akamai) Message-ID: Hi, I got some complaints from customers and found out that all IP addresses announced in one of our ASN are banned by Akamai or some websites hosted with Akamai. I've tried to contact one of the website owners but didn't get any response. Could someone from Akamai contact me off-list? Regards, Siyuan Miao -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed Mar 27 15:56:09 2019 From: owen at delong.com (Owen DeLong) Date: Wed, 27 Mar 2019 08:56:09 -0700 Subject: Banned by Akamai (or some websites hosted with Akamai) In-Reply-To: References: Message-ID: <6AC8A21E-F596-4FD7-ADBB-D1AA5A575F7E@delong.com> Akamai will _NOT_ be helpful in this situation. They will tell you that it is their customers who set the policy for their “Web Application Firewall”. In reality, Akamai’s customers set certain things on “autopilot” where Akamai maintains a reputation database for various IP addresses and triggers actions set by their customers without their customers direct knowledge or intervention. Akamai’s process for dealing with this (or rather their refusal to create a process for dealing with it) is a horrible disservice to the internet and to their customers. I tried to push for changes to this process while I was there and had no significant success. I’ve also been the victim of these practices after I was laid off by Akamai (along with about 7% of their employees last year). Because of a variety of issues I’m not at liberty to elaborate, it isn’t an easy problem for Akamai to solve, but as a company that prides itself on tackling and solving difficult problems, they’ve certainly fallen short here. Owen > On Mar 27, 2019, at 08:46 , Siyuan Miao wrote: > > Hi, > > I got some complaints from customers and found out that all IP addresses announced in one of our ASN are banned by Akamai or some websites hosted with Akamai. > > I've tried to contact one of the website owners but didn't get any response. > > Could someone from Akamai contact me off-list? > > Regards, > Siyuan Miao From jared at puck.nether.net Wed Mar 27 17:25:32 2019 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 27 Mar 2019 18:25:32 +0100 Subject: Banned by Akamai (or some websites hosted with Akamai) In-Reply-To: <6AC8A21E-F596-4FD7-ADBB-D1AA5A575F7E@delong.com> References: <6AC8A21E-F596-4FD7-ADBB-D1AA5A575F7E@delong.com> Message-ID: All companies have unique challenges in trying to mitigate abuse and serve customers well. Miao I’ll collect details from you in private to see if there is something that can be done. Sent from my iCar > On Mar 27, 2019, at 4:56 PM, Owen DeLong wrote: > > Akamai will _NOT_ be helpful in this situation. > > They will tell you that it is their customers who set the policy for their “Web Application Firewall”. > > In reality, Akamai’s customers set certain things on “autopilot” where Akamai maintains a reputation database for various IP addresses and triggers actions > set by their customers without their customers direct knowledge or intervention. > > Akamai’s process for dealing with this (or rather their refusal to create a process for dealing with it) is a horrible disservice to the internet and to their customers. > > I tried to push for changes to this process while I was there and had no significant success. > > I’ve also been the victim of these practices after I was laid off by Akamai (along with about 7% of their employees last year). > > Because of a variety of issues I’m not at liberty to elaborate, it isn’t an easy problem for Akamai to solve, but as a company that prides itself on tackling and solving difficult problems, they’ve certainly fallen short here. > > Owen > > >> On Mar 27, 2019, at 08:46 , Siyuan Miao wrote: >> >> Hi, >> >> I got some complaints from customers and found out that all IP addresses announced in one of our ASN are banned by Akamai or some websites hosted with Akamai. >> >> I've tried to contact one of the website owners but didn't get any response. >> >> Could someone from Akamai contact me off-list? >> >> Regards, >> Siyuan Miao From jared at puck.nether.net Wed Mar 27 17:36:06 2019 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 27 Mar 2019 13:36:06 -0400 Subject: Banned by Akamai (or some websites hosted with Akamai) In-Reply-To: References: Message-ID: <20190327173606.GA31027@puck.nether.net> On Wed, Mar 27, 2019 at 11:46:21PM +0800, Siyuan Miao wrote: > Hi, > > I got some complaints from customers and found out that all IP addresses > announced in one of our ASN are banned by Akamai or some websites hosted > with Akamai. > > I've tried to contact one of the website owners but didn't get any response. FYI: you can look things up here if you think something is blocking you: https://www.akamai.com/us/en/clientrep-lookup/?language=en_US - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From kmedcalf at dessus.com Wed Mar 27 17:42:50 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Wed, 27 Mar 2019 11:42:50 -0600 Subject: Banned by Akamai (or some websites hosted with Akamai) In-Reply-To: <20190327173606.GA31027@puck.nether.net> Message-ID: <26fcd5de312d76438076a3410eaacaeb@mail.dessus.com> >https://www.akamai.com/us/en/clientrep-lookup/?language=en_US Well, isn't that just jammed up with malicious third-party javascript ... --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From Bryan at bryanfields.net Wed Mar 27 19:28:05 2019 From: Bryan at bryanfields.net (Bryan Fields) Date: Wed, 27 Mar 2019 15:28:05 -0400 Subject: residential/smb internet access in 2019 - help? In-Reply-To: <580616152.7202.1553687413885.JavaMail.mhammett@ThunderFuck> References: <580616152.7202.1553687413885.JavaMail.mhammett@ThunderFuck> Message-ID: <2d769c20-6b66-0b63-d67f-c67e3fa4d641@bryanfields.net> On 3/27/19 7:50 AM, Mike Hammett wrote: > https://broadbandnow.com/Florida/Micanopy?zip=32667# > > You might want to try neighboring ZIP codes to see what other fixed > wireless providers might be convinced to expand. > > http://svic.net/wireless-broadband-north-florida/ You really want to weigh what wireless can offer as many of the local players doing wireless lack the depth of network knowledge and are completely ignorant of what it takes to run an RF network. I'd independently verify your circuits up-time if you decide to go with a wireless ISP. The other sad part is the PtMP wireless technology is likely slower than an LTE modem with external antenna. The WISP's had a great time circa 2005 or so, but now that the licensed players have surpassed what they can offer it's hard to justify the lower availability of the typical WISP vs. cost. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From tj at pcguys.us Wed Mar 27 19:30:10 2019 From: tj at pcguys.us (TJ Trout) Date: Wed, 27 Mar 2019 12:30:10 -0700 Subject: residential/smb internet access in 2019 - help? In-Reply-To: <2d769c20-6b66-0b63-d67f-c67e3fa4d641@bryanfields.net> References: <580616152.7202.1553687413885.JavaMail.mhammett@ThunderFuck> <2d769c20-6b66-0b63-d67f-c67e3fa4d641@bryanfields.net> Message-ID: You are way out of line, and grouping a whole industry into your experience with (probably) one hack On Wed, Mar 27, 2019 at 12:28 PM Bryan Fields wrote: > On 3/27/19 7:50 AM, Mike Hammett wrote: > > https://broadbandnow.com/Florida/Micanopy?zip=32667# > > > > You might want to try neighboring ZIP codes to see what other fixed > > wireless providers might be convinced to expand. > > > > http://svic.net/wireless-broadband-north-florida/ > > You really want to weigh what wireless can offer as many of the local > players > doing wireless lack the depth of network knowledge and are completely > ignorant > of what it takes to run an RF network. I'd independently verify your > circuits > up-time if you decide to go with a wireless ISP. > > The other sad part is the PtMP wireless technology is likely slower than an > LTE modem with external antenna. > > The WISP's had a great time circa 2005 or so, but now that the licensed > players have surpassed what they can offer it's hard to justify the lower > availability of the typical WISP vs. cost. > > -- > Bryan Fields > > 727-409-1194 - Voice > http://bryanfields.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From courtneysmith at comcast.net Wed Mar 27 19:37:33 2019 From: courtneysmith at comcast.net (Courtney Smith) Date: Wed, 27 Mar 2019 19:37:33 +0000 Subject: TestIT app to measure rural broadband access Message-ID: <1E7CBD56-D8C9-4439-9C37-122DCFBEF187@comcast.net> Saw this today in a press release from my county. https://www.naco.org/resources/press/naco-rural-lisc-and-rcap-launch-mobile-app-and-announce-bridging-economic-divide Washington, DC (February 26, 2019) – The National Association of Counties (NACo), the Rural Community Assistance Partnership (RCAP) and Rural LISC (Local Initiatives Support Corporation) have partnered to address the critical need for affordable high-speed internet for rural communities across the country. Together, the three organizations developed a mobile app that gives mobile phone users the power to accurately identify areas with low or no internet connectivity and share that information to push for change. Armed with that data, the organizations will advocate for adequate funding for broadband infrastructure across the country. From Bryan at bryanfields.net Wed Mar 27 20:04:07 2019 From: Bryan at bryanfields.net (Bryan Fields) Date: Wed, 27 Mar 2019 16:04:07 -0400 Subject: residential/smb internet access in 2019 - help? In-Reply-To: References: <580616152.7202.1553687413885.JavaMail.mhammett@ThunderFuck> <2d769c20-6b66-0b63-d67f-c67e3fa4d641@bryanfields.net> Message-ID: On 3/27/19 3:30 PM, TJ Trout wrote: > You are way out of line, and grouping a whole industry into your experience > with (probably) one hack I don't think I'm out of line, I'm relating what I've seen time and time again. Most WISP's are poorly capitalized and have to run extremely lean. Most WISP's cannot afford to employ experienced engineering staff. This causes problems in any company, let alone one where a lightning strike can take out an entire tower of equipment. Couple this with a lack of RF savvy engineering and failures are inevitable. Looking at the website of http://pcguys.us/services.html, one can see the highest service offered is "5.0Mbps" and pricing is 89.99/month for this service. I've got 45 Mbit/s on my Tmobile LTE card, and fully unlimited is in the same ballpark. Looking at the typical equipment used (64 QAM, 20 MHz channel), you're going to have a raw bitrate of around 80 mbit/s. Couple this with overhead and some inevitable interference and an access point will have about 50 mbit's of large frame capacity. This is not much, and every client added will slightly reduce this due to multicast and supervisory signaling losses. Each system is going to be Time Division Duplex (using the same channel for transmit and receive), so you will split this say 75/25 down/up stream. This means you have at best 37.5 Mbit/s available for all clients to share, which isn't much for a 90 or 120 degree sector out to 10 miles (or more) depending on density. 802.16 WIMAX had several things to address these issues, but it's dead and slow. In the US (as this is NANOG), few operators had the 3.65 GHz licenses for true wimax, and CBRS is eclipsing these licensed operators shortly. Wireless has it's place, but Point-to-Multi-Point broadband on 5 GHz is not it. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From joly at punkcast.com Wed Mar 27 20:52:03 2019 From: joly at punkcast.com (Joly MacFie) Date: Wed, 27 Mar 2019 16:52:03 -0400 Subject: residential/smb internet access in 2019 - help? In-Reply-To: References: <580616152.7202.1553687413885.JavaMail.mhammett@ThunderFuck> <2d769c20-6b66-0b63-d67f-c67e3fa4d641@bryanfields.net> Message-ID: > and CBRS is eclipsing these licensed operators shortly. Yeah what about that? https://www.fiercewireless.com/wireless/google-courts-wisps-tailored-cbrs-solutions -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast -------------------------------------------------------------- - -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradley at wifastnetworks.com Wed Mar 27 21:18:02 2019 From: bradley at wifastnetworks.com (Bradley Burch) Date: Wed, 27 Mar 2019 17:18:02 -0400 Subject: residential/smb internet access in 2019 - help? In-Reply-To: References: <580616152.7202.1553687413885.JavaMail.mhammett@ThunderFuck> <2d769c20-6b66-0b63-d67f-c67e3fa4d641@bryanfields.net> Message-ID: <83FF4A91-3FA3-4352-B860-EF1ACCB4F346@wifastnetworks.com> Wisp here. Our subscribers can get 100mbps bi directional. But we also know what we are doing. Technology is getting better, so speeds are getting better. > On Mar 27, 2019, at 4:04 PM, Bryan Fields wrote: > >> On 3/27/19 3:30 PM, TJ Trout wrote: >> You are way out of line, and grouping a whole industry into your experience >> with (probably) one hack > > I don't think I'm out of line, I'm relating what I've seen time and time > again. Most WISP's are poorly capitalized and have to run extremely lean. > Most WISP's cannot afford to employ experienced engineering staff. This > causes problems in any company, let alone one where a lightning strike can > take out an entire tower of equipment. Couple this with a lack of RF savvy > engineering and failures are inevitable. > > Looking at the website of http://pcguys.us/services.html, one can see the > highest service offered is "5.0Mbps" and pricing is 89.99/month for this > service. I've got 45 Mbit/s on my Tmobile LTE card, and fully unlimited is in > the same ballpark. > > Looking at the typical equipment used (64 QAM, 20 MHz channel), you're going > to have a raw bitrate of around 80 mbit/s. Couple this with overhead and some > inevitable interference and an access point will have about 50 mbit's of large > frame capacity. This is not much, and every client added will slightly reduce > this due to multicast and supervisory signaling losses. Each system is going > to be Time Division Duplex (using the same channel for transmit and receive), > so you will split this say 75/25 down/up stream. This means you have at best > 37.5 Mbit/s available for all clients to share, which isn't much for a 90 or > 120 degree sector out to 10 miles (or more) depending on density. > > 802.16 WIMAX had several things to address these issues, but it's dead and > slow. In the US (as this is NANOG), few operators had the 3.65 GHz licenses > for true wimax, and CBRS is eclipsing these licensed operators shortly. > > Wireless has it's place, but Point-to-Multi-Point broadband on 5 GHz is not it. > > -- > Bryan Fields > > 727-409-1194 - Voice > http://bryanfields.net From johnstong at westmancom.com Wed Mar 27 21:36:20 2019 From: johnstong at westmancom.com (Graham Johnston) Date: Wed, 27 Mar 2019 21:36:20 +0000 Subject: Advertisement of Equinix Chicago IX Subnet Message-ID: This afternoon at around 12:17 central time today we began learning the subnet for the Equinix IX in Chicago via a transit provider; we are on the IX as well. The subnet in question is 208.115.136.0/23. Using stat.ripe.net I can see that this subnet is also being learned by others, see the snip below. On our network this caused a nasty routing loop until we figured out what was wrong. My current best understanding is that because the route was learned via eBGP it trumped the OSPF learned route. As soon as I filtered the advertisement from my transit provider everything returned to normal. What am I doing that isn’t best practices that would have prevented this? Thanks, graham RIPE Info 1 RRCs see 1 peers announcing 208.115.136.0/23 originated by AS32703 * ▼RRC00 in Amsterdam, Netherlands sees 1 ASN orginating 208.115.136.0/23.AS32703 o ▼AS32703 is seen as the origin by 1 peer.192.102.254.1 § ▼192.102.254.1 is announcing route AS395152 AS63297 AS6327 AS36280AS32703. § Origin: IGP § Next Hop: 192.102.254.1 § Peer: 192.102.254.1 § Community: 63297:1000 § AS Path: 395152 63297 6327 36280 32703 § Last Updated: 2019-03-27T17:17:19 Route-views route-views.chicago.routeviews.org> show ip bgp 208.115.136.0 BGP routing table entry for 208.115.136.0/23 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 32709 32703 208.115.136.134 from 208.115.136.134 (63.134.128.248) Origin IGP, localpref 100, valid, external, best AddPath ID: RX 0, TX 64414249 Last update: Wed Mar 27 17:16:09 2019 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mureninc at gmail.com Wed Mar 27 21:43:58 2019 From: mureninc at gmail.com (Constantine A. Murenin) Date: Wed, 27 Mar 2019 16:43:58 -0500 Subject: Banned by Akamai (or some websites hosted with Akamai) In-Reply-To: <6AC8A21E-F596-4FD7-ADBB-D1AA5A575F7E@delong.com> References: <6AC8A21E-F596-4FD7-ADBB-D1AA5A575F7E@delong.com> Message-ID: I think it's a general problem with a lot of these application firewall companies these days. There's been a long time I couldn't access both staples.com and officedepot.com, and officedepot.com is still broken for me to this day. (Ironically, they're both using the same CDN — so much for the competition and differentiation.) I'm obviously a valid user, just as many others who get access denied, but I'm pretty sure that all of these access attempts by customers who are misclassified as bots and denied access are subsequently aggregated by these CDNs back to their clients as bad bots, which — luckily! — have been blocked to prevent $badThings from happening, $giveUsMoreMoneyToProtectYouFromYourOwnCustomers. Talking with these vendors at their booths at trade shows reveals that the incentives and selling points in the application firewall business are just wrong — they each boast about blocking more "bots" than their competition, completely dismissing the fact that many of these "bots" are actual paying customers that get denied access. Cheers, Constantine. P.S. Below is the page I currently get when visiting officedepot.com — so much for taking care of business! >>>> >>>>OfficeDepot.com - Taking Care Of Business. Office Supplies, Furniture, Technology & More! >>>>We're Sorry. We are unable to process your last request. >>>> >>>>Rest assured we are working diligently to resolve this issue. If you would like to place an order by phone or speak with one of our Customer Service representatives please contact us: >>>> >>>>Call 1-800-GO-DEPOT >>>>Reference Number: 18.34b51002.1553708764.397327 >>>> >>>>Copyright © 2012 by Office Depot, Inc. All rights reserved. On Wed, 27 Mar 2019 at 10:57, Owen DeLong wrote: > Akamai will _NOT_ be helpful in this situation. > > They will tell you that it is their customers who set the policy for their > “Web Application Firewall”. > > In reality, Akamai’s customers set certain things on “autopilot” where > Akamai maintains a reputation database for various IP addresses and > triggers actions > set by their customers without their customers direct knowledge or > intervention. > > Akamai’s process for dealing with this (or rather their refusal to create > a process for dealing with it) is a horrible disservice to the internet and > to their customers. > > I tried to push for changes to this process while I was there and had no > significant success. > > I’ve also been the victim of these practices after I was laid off by > Akamai (along with about 7% of their employees last year). > > Because of a variety of issues I’m not at liberty to elaborate, it isn’t > an easy problem for Akamai to solve, but as a company that prides itself on > tackling and solving difficult problems, they’ve certainly fallen short > here. > > Owen > > > > On Mar 27, 2019, at 08:46 , Siyuan Miao wrote: > > > > Hi, > > > > I got some complaints from customers and found out that all IP addresses > announced in one of our ASN are banned by Akamai or some websites hosted > with Akamai. > > > > I've tried to contact one of the website owners but didn't get any > response. > > > > Could someone from Akamai contact me off-list? > > > > Regards, > > Siyuan Miao > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at foobar.org Wed Mar 27 21:50:26 2019 From: nick at foobar.org (Nick Hilliard) Date: Wed, 27 Mar 2019 21:50:26 +0000 Subject: Advertisement of Equinix Chicago IX Subnet In-Reply-To: References: Message-ID: <4fb4376d-7078-ea4e-5c4a-91ac08e5c9e6@foobar.org> Graham Johnston wrote on 27/03/2019 21:36: > What am I doing that isn’t best practices that would have prevented this? you're setting the next-hop of the prefixes learned at the IXP to be your own IP address from the IXP subnet (i.e. 208.115.136.0/23). When your routers learn this address from an external source, that is preferred to your internal OSPF route. Ergo your IX traffic is sent out via transit. There are two things you should do: 1. change the bgp distance for ebgp to be higher than all your IGPs. On a cisco router, you would use something like: router bgp xxx address-family ipv4 distance bgp 200 200 200 address-family ipv6 distance bgp 200 200 200 2. use next-hop-self on internal ibgp sessions to ensure that when you redistribute the eBGP routes learned from your IX towards the internals of your network, the next-hop address is set to be the loopback address of your peering router. I.e. you remove the requirement for your internal network to know anything about the IXP address range. Nick From johnstong at westmancom.com Wed Mar 27 21:52:33 2019 From: johnstong at westmancom.com (Graham Johnston) Date: Wed, 27 Mar 2019 21:52:33 +0000 Subject: Advertisement of Equinix Chicago IX Subnet In-Reply-To: <4fb4376d-7078-ea4e-5c4a-91ac08e5c9e6@foobar.org> References: <4fb4376d-7078-ea4e-5c4a-91ac08e5c9e6@foobar.org> Message-ID: Thank you Nick. Graham Johnston Manager, Network Services Westman Communications Group 1906 Park Avenue | Brandon, MB | R7B 0R9 204-717-2829 |     johnstong at westmancom.com             -----Original Message----- From: Nick Hilliard Sent: March 27, 2019 4:50 PM To: Graham Johnston Cc: nanog at nanog.org Subject: Re: Advertisement of Equinix Chicago IX Subnet CAUTION: This email is from an external source. Do not click links or open attachments unless you recognize the sender and know the content is safe. Graham Johnston wrote on 27/03/2019 21:36: > What am I doing that isn't best practices that would have prevented this? you're setting the next-hop of the prefixes learned at the IXP to be your own IP address from the IXP subnet (i.e. 208.115.136.0/23). When your routers learn this address from an external source, that is preferred to your internal OSPF route. Ergo your IX traffic is sent out via transit. There are two things you should do: 1. change the bgp distance for ebgp to be higher than all your IGPs. On a cisco router, you would use something like: router bgp xxx address-family ipv4 distance bgp 200 200 200 address-family ipv6 distance bgp 200 200 200 2. use next-hop-self on internal ibgp sessions to ensure that when you redistribute the eBGP routes learned from your IX towards the internals of your network, the next-hop address is set to be the loopback address of your peering router. I.e. you remove the requirement for your internal network to know anything about the IXP address range. Nick From valdis.kletnieks at vt.edu Wed Mar 27 22:14:23 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Wed, 27 Mar 2019 18:14:23 -0400 Subject: residential/smb internet access in 2019 - help? In-Reply-To: <83FF4A91-3FA3-4352-B860-EF1ACCB4F346@wifastnetworks.com> References: <580616152.7202.1553687413885.JavaMail.mhammett@ThunderFuck> <2d769c20-6b66-0b63-d67f-c67e3fa4d641@bryanfields.net> <83FF4A91-3FA3-4352-B860-EF1ACCB4F346@wifastnetworks.com> Message-ID: <5632.1553724863@turing-police> On Wed, 27 Mar 2019 17:18:02 -0400, Bradley Burch said: > Wisp here. > > Our subscribers can get 100mbps bi directional. > > But we also know what we are doing. And being honest here - what percent of WISP operators out there are in your category, as opposed to the under-capitalized and RF experienced challenged group that Bryan was commenting in regards to? I'll bet a large pizza with everything but anchovies that it's in the same ballpark percentage as small copper/fiber base ISPs that have people who read NANOG. In other words, really low. From lists at packetflux.com Wed Mar 27 22:39:54 2019 From: lists at packetflux.com (Forrest Christian (List Account)) Date: Wed, 27 Mar 2019 16:39:54 -0600 Subject: residential/smb internet access in 2019 - help? In-Reply-To: References: <580616152.7202.1553687413885.JavaMail.mhammett@ThunderFuck> <2d769c20-6b66-0b63-d67f-c67e3fa4d641@bryanfields.net> Message-ID: On Wed, Mar 27, 2019 at 2:05 PM Bryan Fields wrote: > Looking at the typical equipment used (64 QAM, 20 MHz channel), you're going > to have a raw bitrate of around 80 mbit/s. Couple this with overhead and some > inevitable interference and an access point will have about 50 mbit's of large > frame capacity. This is not much, and every client added will slightly reduce > this due to multicast and supervisory signaling losses. Each system is going > to be Time Division Duplex (using the same channel for transmit and receive), > so you will split this say 75/25 down/up stream. This means you have at best > 37.5 Mbit/s available for all clients to share, which isn't much for a 90 or > 120 degree sector out to 10 miles (or more) depending on density. Ahh, and there's your misunderstanding. Most good WISPS deploy equipment which is capable of much more, with much smaller cell sizes anymore. 256QAM is the rule, 3 Miles is a large cell size, and with MU-MIMO enabled AP's you can get aggregate of around 500MB/s on a single 20Mhz wide channel. If you can find 40Mhz, it's over 1GB/s. Of course, this depends on the exact equipment deployed. Even with lower-end equipment most operators end up with 200Mb/s in 40Mhz - and will often limit the number of customers on that 200Mb/s AP to a dozen or so. You need to be aware that the industry has grown up a LOT in the last 4-5 years, but like in any industry there are bad and good operators. Some do fit into the category you're describing, but from what I can see a large portion of them do know how to deliver a lot of bandwidth. In addition, many WISP's are now also trenching fiber to the home where it makes sense, and deploying fixed wireless where it doesn't. Often the fiber trenching is being driven by those sites where the aggregate customer bandwidth needs do outstrip the capability of the wireless network. -- - Forrest From ccummings at coeur.com Wed Mar 27 23:44:05 2019 From: ccummings at coeur.com (Cummings, Chris) Date: Wed, 27 Mar 2019 23:44:05 +0000 Subject: Advertisement of Equinix Chicago IX Subnet In-Reply-To: References: Message-ID: Not too sure about your topology, but I’ve had something similar bite me, so we typically put a prefix list inbound to deny receiving our internal prefixes from our peers. This probably doesn’t work as well if your network is less “eyeballish” than ours, however. /chris On Wed, Mar 27, 2019 at 4:37 PM -0500, "Graham Johnston" > wrote: This afternoon at around 12:17 central time today we began learning the subnet for the Equinix IX in Chicago via a transit provider; we are on the IX as well. The subnet in question is 208.115.136.0/23. Using stat.ripe.net I can see that this subnet is also being learned by others, see the snip below. On our network this caused a nasty routing loop until we figured out what was wrong. My current best understanding is that because the route was learned via eBGP it trumped the OSPF learned route. As soon as I filtered the advertisement from my transit provider everything returned to normal. What am I doing that isn’t best practices that would have prevented this? Thanks, graham RIPE Info 1 RRCs see 1 peers announcing 208.115.136.0/23 originated by AS32703 · ▼RRC00 in Amsterdam, Netherlands sees 1 ASN orginating 208.115.136.0/23.AS32703 o ▼AS32703 is seen as the origin by 1 peer.192.102.254.1 § ▼192.102.254.1 is announcing route AS395152 AS63297 AS6327 AS36280AS32703. § Origin: IGP § Next Hop: 192.102.254.1 § Peer: 192.102.254.1 § Community: 63297:1000 § AS Path: 395152 63297 6327 36280 32703 § Last Updated: 2019-03-27T17:17:19 Route-views route-views.chicago.routeviews.org> show ip bgp 208.115.136.0 BGP routing table entry for 208.115.136.0/23 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 32709 32703 208.115.136.134 from 208.115.136.134 (63.134.128.248) Origin IGP, localpref 100, valid, external, best AddPath ID: RX 0, TX 64414249 Last update: Wed Mar 27 17:16:09 2019 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Thu Mar 28 11:02:34 2019 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 28 Mar 2019 06:02:34 -0500 (CDT) Subject: Nexus 9396 SNMP Issues Message-ID: <2029067423.505.1553770951300.JavaMail.mhammett@ThunderFuck> Does anyone else have issues with the 9396 sending out bum SNMP responses? Seemingly all DDM information for the optic modules return just a single digit. IE: [redacted]# show int eth 1/3 trans det Ethernet1/3 transceiver is present type is 1000base-LH name is Fiberstore part number is SFP1G-LH-31 revision is A0 serial number is F16ACO17646 nominal bitrate is 1300 MBit/sec Link length supported for 9/125um fiber is 10 km cisco id is 3 cisco extended id number is 4 SFP Detail Diagnostics Information (internal calibration) ---------------------------------------------------------------------------- Current Alarms Warnings Measurement High Low High Low ---------------------------------------------------------------------------- Temperature 40.72 C 100.00 C -50.00 C 85.00 C -40.00 C Voltage 3.35 V 3.79 V 2.80 V 3.46 V 3.13 V Current 15.89 mA 90.00 mA 0.00 mA 85.00 mA 0.00 mA Tx Power -6.05 dBm -1.50 dBm -10.50 dBm -3.00 dBm -9.03 dBm Rx Power -6.32 dBm -3.00 dBm -26.98 dBm -5.00 dBm -23.97 dBm Transmit Fault Count = 0 ---------------------------------------------------------------------------- Note: ++ high-alarm; + high-warning; -- low-alarm; - low-warning [redacted]:~$ /usr/bin/snmpget -v2c -c [redacted] .1.3.6.1.4.1.9.9.91.1.1.1.1.4.300003533 .1.3.6.1.4.1.9.9.91.1.1.1.1.4.300003534 iso.3.6.1.4.1.9.9.91.1.1.1.1.4.300003533 = INTEGER: -6 iso.3.6.1.4.1.9.9.91.1.1.1.1.4.300003534 = INTEGER: -6 [redacted]:/opt/librenms# tcpdump host [redacted] tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 11:13:33.360509 IP [redacted].49594 > [redacted].snmp: C="[redacted]" GetRequest(62) E:cisco.9.91.1.1.1.1.4.300003533 E:cisco.9.91.1.1.1.1.4.300003534 11:13:33.362093 IP [redacted].snmp > [redacted].49594: C="[redacted]" GetResponse(64) E:cisco.9.91.1.1.1.1.4.300003533=-6 E:cisco.9.91.1.1.1.1.4.300003534=-6 ^C 2 packets captured 2 packets received by filter 0 packets dropped by kernel Here I have a 3064 that reports just fine. [redacted]# show int eth 1/17 trans det Ethernet1/17 transceiver is present type is 1000base-LH name is FiberStore part number is SFP1G-LX-31 revision is A0 serial number is D87B1487283 nominal bitrate is 1300 MBit/sec Link length supported for 9/125um fiber is 10 km cisco id is 3 cisco extended id number is 4 SFP Detail Diagnostics Information (internal calibration) ---------------------------------------------------------------------------- Current Alarms Warnings Measurement High Low High Low ---------------------------------------------------------------------------- Temperature 33.38 C 100.00 C -50.00 C 85.00 C -40.00 C Voltage 3.33 V 3.79 V 2.80 V 3.46 V 3.13 V Current 19.60 mA 90.00 mA 0.00 mA 85.00 mA 0.00 mA Tx Power -6.10 dBm -1.50 dBm -10.50 dBm -3.00 dBm -9.03 dBm Rx Power -6.94 dBm 0.99 dBm -30.00 dBm -1.00 dBm -26.98 dBm Transmit Fault Count = 0 ---------------------------------------------------------------------------- Note: ++ high-alarm; + high-warning; -- low-alarm; - low-warning [redacted]:/opt/librenms# /usr/bin/snmpget -v2c -c [redacted] .1.3.6.1.4.1.9.9.91.1.1.1.1.4.300028173 .1.3.6.1.4.1.9.9.91.1.1.1.1.4.300028174 iso.3.6.1.4.1.9.9.91.1.1.1.1.4.300028173 = INTEGER: -6968 iso.3.6.1.4.1.9.9.91.1.1.1.1.4.300028174 = INTEGER: -6090 [redacted]:/opt/librenms# tcpdump host [redacted] tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 11:54:01.211115 IP [redacted].36131 > [redacted].snmp: C="[redacted]" GetRequest(62) E:cisco.9.91.1.1.1.1.4.300028173 E:cisco.9.91.1.1.1.1.4.300028174 11:54:01.261027 IP [redacted].snmp > [redacted].36131: C="[redacted]" GetResponse(66) E:cisco.9.91.1.1.1.1.4.300028173=-6968 E:cisco.9.91.1.1.1.1.4.300028174=-6090 ^C 2 packets captured 2 packets received by filter 0 packets dropped by kernel ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Thu Mar 28 11:12:14 2019 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 28 Mar 2019 06:12:14 -0500 (CDT) Subject: residential/smb internet access in 2019 - help? In-Reply-To: <2d769c20-6b66-0b63-d67f-c67e3fa4d641@bryanfields.net> References: <580616152.7202.1553687413885.JavaMail.mhammett@ThunderFuck> <2d769c20-6b66-0b63-d67f-c67e3fa4d641@bryanfields.net> Message-ID: <97309510.518.1553771529600.JavaMail.mhammett@ThunderFuck> Variability will always happen with small businesses, but you're more likely to encounter someone that won't do nasty things to your bits through a local WISP as opposed to a national player. It's also more likely to be consistent versus the variability of a mobile service. WISPs have been going strong for years. Typically when a fixed wireless customer moves to mobile wireless, they move back within a couple months. Also, *most* people don't need more than 10 megs at home, so fixed providers that haven't upgraded to support faster speeds aren't really at a disadvantage when you look at how the connection is actually used. That becomes apparent once you switch. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Bryan Fields" To: "NANOG List" Sent: Wednesday, March 27, 2019 2:28:05 PM Subject: Re: residential/smb internet access in 2019 - help? On 3/27/19 7:50 AM, Mike Hammett wrote: > https://broadbandnow.com/Florida/Micanopy?zip=32667# > > You might want to try neighboring ZIP codes to see what other fixed > wireless providers might be convinced to expand. > > http://svic.net/wireless-broadband-north-florida/ You really want to weigh what wireless can offer as many of the local players doing wireless lack the depth of network knowledge and are completely ignorant of what it takes to run an RF network. I'd independently verify your circuits up-time if you decide to go with a wireless ISP. The other sad part is the PtMP wireless technology is likely slower than an LTE modem with external antenna. The WISP's had a great time circa 2005 or so, but now that the licensed players have surpassed what they can offer it's hard to justify the lower availability of the typical WISP vs. cost. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Thu Mar 28 11:17:25 2019 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 28 Mar 2019 06:17:25 -0500 (CDT) Subject: Banned by Akamai (or some websites hosted with Akamai) In-Reply-To: References: <6AC8A21E-F596-4FD7-ADBB-D1AA5A575F7E@delong.com> Message-ID: <133059888.534.1553771841630.JavaMail.mhammett@ThunderFuck> Hopefully Jared can fix it. Owen's description matches up very well with my experiences in trying to fix similar problems at Akamai. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jared Mauch" To: "Owen DeLong" Cc: nanog at nanog.org Sent: Wednesday, March 27, 2019 12:25:32 PM Subject: Re: Banned by Akamai (or some websites hosted with Akamai) All companies have unique challenges in trying to mitigate abuse and serve customers well. Miao I’ll collect details from you in private to see if there is something that can be done. Sent from my iCar > On Mar 27, 2019, at 4:56 PM, Owen DeLong wrote: > > Akamai will _NOT_ be helpful in this situation. > > They will tell you that it is their customers who set the policy for their “Web Application Firewall”. > > In reality, Akamai’s customers set certain things on “autopilot” where Akamai maintains a reputation database for various IP addresses and triggers actions > set by their customers without their customers direct knowledge or intervention. > > Akamai’s process for dealing with this (or rather their refusal to create a process for dealing with it) is a horrible disservice to the internet and to their customers. > > I tried to push for changes to this process while I was there and had no significant success. > > I’ve also been the victim of these practices after I was laid off by Akamai (along with about 7% of their employees last year). > > Because of a variety of issues I’m not at liberty to elaborate, it isn’t an easy problem for Akamai to solve, but as a company that prides itself on tackling and solving difficult problems, they’ve certainly fallen short here. > > Owen > > >> On Mar 27, 2019, at 08:46 , Siyuan Miao wrote: >> >> Hi, >> >> I got some complaints from customers and found out that all IP addresses announced in one of our ASN are banned by Akamai or some websites hosted with Akamai. >> >> I've tried to contact one of the website owners but didn't get any response. >> >> Could someone from Akamai contact me off-list? >> >> Regards, >> Siyuan Miao -------------- next part -------------- An HTML attachment was scrubbed... URL: From edugas at unknowndevice.ca Thu Mar 28 13:08:26 2019 From: edugas at unknowndevice.ca (Eric Dugas) Date: Thu, 28 Mar 2019 09:08:26 -0400 Subject: Advertisement of Equinix Chicago IX Subnet In-Reply-To: References: Message-ID: I have a policy applied to my upstreams and peers to deny the IXP's LANs were connected to. I don't think of any reason to learn these routes from someone else's network. On Wed, Mar 27, 2019 at 7:44 PM Cummings, Chris wrote: > Not too sure about your topology, but I’ve had something similar bite me, > so we typically put a prefix list inbound to deny receiving our internal > prefixes from our peers. This probably doesn’t work as well if your network > is less “eyeballish” than ours, however. > > /chris > > > > On Wed, Mar 27, 2019 at 4:37 PM -0500, "Graham Johnston" < > johnstong at westmancom.com> wrote: > > This afternoon at around 12:17 central time today we began learning the >> subnet for the Equinix IX in Chicago via a transit provider; we are on the >> IX as well. The subnet in question is 208.115.136.0/23. Using >> stat.ripe.net >> >> I can see that this subnet is also being learned by others, see the snip >> below. On our network this caused a nasty routing loop until we figured out >> what was wrong. My current best understanding is that because the route was >> learned via eBGP it trumped the OSPF learned route. As soon as I filtered >> the advertisement from my transit provider everything returned to normal. >> What am I doing that isn’t best practices that would have prevented this? >> >> >> >> Thanks, >> >> graham >> >> >> >> >> >> RIPE Info >> >> *1* RRCs see *1* peers announcing *208.115.136.0/23 >> * originated by *AS32703* >> >> >> · ▼RRC00 in *Amsterdam, Netherlands* sees *1* ASN orginating *208.115.136.0/23 >> *.AS32703 >> >> o ▼*AS32703 >> * is >> seen as the origin by *1* peer.192.102.254.1 >> >> § ▼*192.102.254.1 >> * is >> announcing route *AS395152* >> >> *AS63297* >> >> *AS6327* >> >> *AS36280* >> >> *AS32703* >> >> . >> >> § Origin: IGP >> >> § Next Hop: 192.102.254.1 >> >> § Peer: 192.102.254.1 >> >> § Community: 63297:1000 >> >> § AS Path: 395152 63297 6327 36280 32703 >> >> § Last Updated: 2019-03-27T17:17:19 >> >> >> >> >> >> Route-views >> >> route-views.chicago.routeviews.org >> > >> show ip bgp 208.115.136.0 >> >> BGP routing table entry for 208.115.136.0/23 >> >> Paths: (1 available, best #1, table Default-IP-Routing-Table) >> >> Not advertised to any peer >> >> 32709 32703 >> >> 208.115.136.134 from 208.115.136.134 (63.134.128.248) >> >> Origin IGP, localpref 100, valid, external, best >> >> AddPath ID: RX 0, TX 64414249 >> >> Last update: Wed Mar 27 17:16:09 2019 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christopher.morrell.nanog at gmail.com Thu Mar 28 13:34:41 2019 From: christopher.morrell.nanog at gmail.com (Christopher Morrell) Date: Thu, 28 Mar 2019 09:34:41 -0400 Subject: Advertisement of Equinix Chicago IX Subnet In-Reply-To: References: Message-ID: I've been bit by this in the past at two different exchanges. I too have a policy applied to deny IXP LANs from upstreams and peers. It would be nice if there was a list of all IXP LANs somewhere that we could generically add to all upstream and peers. On Thu, Mar 28, 2019 at 9:11 AM Eric Dugas wrote: > I have a policy applied to my upstreams and peers to deny the IXP's LANs > were connected to. I don't think of any reason to learn these routes from > someone else's network. > > On Wed, Mar 27, 2019 at 7:44 PM Cummings, Chris > wrote: > >> Not too sure about your topology, but I’ve had something similar bite me, >> so we typically put a prefix list inbound to deny receiving our internal >> prefixes from our peers. This probably doesn’t work as well if your network >> is less “eyeballish” than ours, however. >> >> /chris >> >> >> >> On Wed, Mar 27, 2019 at 4:37 PM -0500, "Graham Johnston" < >> johnstong at westmancom.com> wrote: >> >> This afternoon at around 12:17 central time today we began learning the >>> subnet for the Equinix IX in Chicago via a transit provider; we are on the >>> IX as well. The subnet in question is 208.115.136.0/23. Using >>> stat.ripe.net >>> >>> I can see that this subnet is also being learned by others, see the snip >>> below. On our network this caused a nasty routing loop until we figured out >>> what was wrong. My current best understanding is that because the route was >>> learned via eBGP it trumped the OSPF learned route. As soon as I filtered >>> the advertisement from my transit provider everything returned to normal. >>> What am I doing that isn’t best practices that would have prevented this? >>> >>> >>> >>> Thanks, >>> >>> graham >>> >>> >>> >>> >>> >>> RIPE Info >>> >>> *1* RRCs see *1* peers announcing *208.115.136.0/23 >>> * originated by *AS32703* >>> >>> >>> · ▼RRC00 in *Amsterdam, Netherlands* sees *1* ASN orginating *208.115.136.0/23 >>> *.AS32703 >>> >>> o ▼*AS32703 >>> * is >>> seen as the origin by *1* peer.192.102.254.1 >>> >>> § ▼*192.102.254.1 >>> * is >>> announcing route *AS395152* >>> >>> *AS63297* >>> >>> *AS6327* >>> >>> *AS36280* >>> >>> *AS32703* >>> >>> . >>> >>> § Origin: IGP >>> >>> § Next Hop: 192.102.254.1 >>> >>> § Peer: 192.102.254.1 >>> >>> § Community: 63297:1000 >>> >>> § AS Path: 395152 63297 6327 36280 32703 >>> >>> § Last Updated: 2019-03-27T17:17:19 >>> >>> >>> >>> >>> >>> Route-views >>> >>> route-views.chicago.routeviews.org >>> > >>> show ip bgp 208.115.136.0 >>> >>> BGP routing table entry for 208.115.136.0/23 >>> >>> Paths: (1 available, best #1, table Default-IP-Routing-Table) >>> >>> Not advertised to any peer >>> >>> 32709 32703 >>> >>> 208.115.136.134 from 208.115.136.134 (63.134.128.248) >>> >>> Origin IGP, localpref 100, valid, external, best >>> >>> AddPath ID: RX 0, TX 64414249 >>> >>> Last update: Wed Mar 27 17:16:09 2019 >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From niels=nanog at bakker.net Thu Mar 28 13:59:43 2019 From: niels=nanog at bakker.net (Niels Bakker) Date: Thu, 28 Mar 2019 14:59:43 +0100 Subject: Advertisement of Equinix Chicago IX Subnet In-Reply-To: References: Message-ID: <20190328135943.GD88473@jima.tpb.net> * christopher.morrell.nanog at gmail.com (Christopher Morrell) [Thu 28 Mar 2019, 14:35 CET]: >I've been bit by this in the past at two different exchanges. I too >have a policy applied to deny IXP LANs from upstreams and peers. It >would be nice if there was a list of all IXP LANs somewhere that we >could generically add to all upstream and peers. I like Nick Hilliard's posted solution much better than creating static bogon lists that people will eventually forget about. -- Niels. From job at instituut.net Thu Mar 28 14:12:17 2019 From: job at instituut.net (Job Snijders) Date: Thu, 28 Mar 2019 14:12:17 +0000 Subject: Advertisement of Equinix Chicago IX Subnet In-Reply-To: <20190328135943.GD88473@jima.tpb.net> References: <20190328135943.GD88473@jima.tpb.net> Message-ID: <20190328141217.GA3094@vurt.meerval.net> On Thu, Mar 28, 2019 at 02:59:43PM +0100, Niels Bakker wrote: > * christopher.morrell.nanog at gmail.com (Christopher Morrell) [Thu 28 Mar 2019, 14:35 CET]: > > I've been bit by this in the past at two different exchanges. I too > > have a policy applied to deny IXP LANs from upstreams and peers. It > > would be nice if there was a list of all IXP LANs somewhere that we > > could generically add to all upstream and peers. > > I like Nick Hilliard's posted solution much better than creating > static bogon lists that people will eventually forget about. IXPs can use RPKI ROAs to signal to the world what their intentions are! IXPs could either create a ROA with an Origin ASN of '0' to suggest to the world that the peering lan prefix should never be visible in the DFZ, or they can specify their own services ASN and simply not announce the prefix. In either case IXPs should carefully specify the Max Length value to be the same as the Prefix Length value of the peering lan prefix. Kind regards, Job From job at instituut.net Thu Mar 28 14:21:43 2019 From: job at instituut.net (Job Snijders) Date: Thu, 28 Mar 2019 14:21:43 +0000 Subject: Advertisement of Equinix Chicago IX Subnet In-Reply-To: References: Message-ID: <20190328142143.GB3094@vurt.meerval.net> On Wed, Mar 27, 2019 at 09:36:20PM +0000, Graham Johnston wrote: > This afternoon at around 12:17 central time today we began learning > the subnet for the Equinix IX in Chicago via a transit provider; we > are on the IX as well. The subnet in question is 208.115.136.0/23. > Using stat.ripe.net I can see that this subnet is also being learned > by others, see the snip below. On our network this caused a nasty > routing loop until we figured out what was wrong. My current best > understanding is that because the route was learned via eBGP it > trumped the OSPF learned route. As soon as I filtered the > advertisement from my transit provider everything returned to normal. > What am I doing that isn’t best practices that would have prevented > this? There is two pieces to help prevent this type of failure: 1/ Equinix should have created a RPKI ROA for 208.115.136.0/23, with an Origin ASN of 0 or one of their own ASNs, and a Max Length of 23. 2/ You should implement RPKI based BGP Origin Validation in your network and honor those ROAs. Kind regards, Job From jared at puck.nether.net Thu Mar 28 16:32:22 2019 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 28 Mar 2019 12:32:22 -0400 Subject: Banned by Akamai (or some websites hosted with Akamai) In-Reply-To: <133059888.534.1553771841630.JavaMail.mhammett@ThunderFuck> References: <6AC8A21E-F596-4FD7-ADBB-D1AA5A575F7E@delong.com> <133059888.534.1553771841630.JavaMail.mhammett@ThunderFuck> Message-ID: <20190328163222.GA20280@puck.nether.net> On Thu, Mar 28, 2019 at 06:17:25AM -0500, Mike Hammett wrote: > Hopefully Jared can fix it. Owen's description matches up very well with my experiences in trying to fix similar problems at Akamai. Don't worry, I can't access my car owners insurance website from the country i'm in as well due to a similar WAF config on another CDN. I've replied to both people that posted to the list with some further details. Don't hesitate to reach out if you're not getting a response or have questions about your experiences with akamai. We are here and will do our best to fix things, but also similar to my car insurance folks who don't want me to have access from this country, keep in mind our customers may also have configured policy to block certain clients or behaviors. I can reach out to the account teams to have them confirm with customer the config is right if it seems odd. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From dhubbard at dino.hostasaurus.com Thu Mar 28 19:38:45 2019 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Thu, 28 Mar 2019 19:38:45 +0000 Subject: Did IPv6 between HE and Google ever get resolved? Message-ID: <84C6285F-9D45-4B87-9FC8-F541A246195E@dino.hostasaurus.com> Hey all, I’ve been having bad luck searching around, but did IPv6 transit between HE and google ever get resolved? Ironically, I can now get to them cheaply from a location we currently have equipment that has been Cogent-only, so if it fixes the IPv6 issue I’d like to make the move. Anyone peer with HE in general and want to share their experience offlist? With the price, if they’re a good option, I’d consider rolling them in to other locations where we have redundancy already, so the v6 isn’t as big a deal there. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhubbard at dino.hostasaurus.com Thu Mar 28 19:44:54 2019 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Thu, 28 Mar 2019 19:44:54 +0000 Subject: Was wrong Re: Did IPv6 between HE and Google ever get resolved? Message-ID: <7C048FF7-7865-47B1-81F3-E93D79413B4B@dino.hostasaurus.com> Oops, I was corrected that HE doesn’t have IPv6 issues with Google, not sure why I had that in my head. Cogent certainly does but something had me thinking there’s another big name that has the same problem. David From: NANOG on behalf of David Hubbard Date: Thursday, March 28, 2019 at 12:40 PM To: NANOG List Subject: Did IPv6 between HE and Google ever get resolved? Hey all, I’ve been having bad luck searching around, but did IPv6 transit between HE and google ever get resolved? Ironically, I can now get to them cheaply from a location we currently have equipment that has been Cogent-only, so if it fixes the IPv6 issue I’d like to make the move. Anyone peer with HE in general and want to share their experience offlist? With the price, if they’re a good option, I’d consider rolling them in to other locations where we have redundancy already, so the v6 isn’t as big a deal there. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlewis at lewis.org Thu Mar 28 21:48:44 2019 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 28 Mar 2019 17:48:44 -0400 (EDT) Subject: Was wrong Re: Did IPv6 between HE and Google ever get resolved? In-Reply-To: <7C048FF7-7865-47B1-81F3-E93D79413B4B@dino.hostasaurus.com> References: <7C048FF7-7865-47B1-81F3-E93D79413B4B@dino.hostasaurus.com> Message-ID: I think what you were remembering is Cogent/Google and Cogent/HE are both IPv6 issues where the parties can't agree on peering vs transit for the v6 relationship. On Thu, 28 Mar 2019, David Hubbard wrote: > > Oops, I was corrected that HE doesn’t have IPv6 issues with Google, not sure why I had that in my head.  Cogent certainly does but something had me thinking there’s another big name > that has the same problem. > >   > > David > >   > > From: NANOG on behalf of David Hubbard > Date: Thursday, March 28, 2019 at 12:40 PM > To: NANOG List > Subject: Did IPv6 between HE and Google ever get resolved? > >   > > Hey all, I’ve been having bad luck searching around, but did IPv6 transit between HE and google ever get resolved?  Ironically, I can now get to them cheaply from a location we > currently have equipment that has been Cogent-only, so if it fixes the IPv6 issue I’d like to make the move.  Anyone peer with HE in general and want to share their experience > offlist?  With the price, if they’re a good option, I’d consider rolling them in to other locations where we have redundancy already, so the v6 isn’t as big a deal there. > >   > > Thanks > >   > > > ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From aaron1 at gvtc.com Fri Mar 29 13:07:03 2019 From: aaron1 at gvtc.com (Aaron Gould) Date: Fri, 29 Mar 2019 08:07:03 -0500 Subject: Was wrong Re: Did IPv6 between HE and Google ever get resolved? In-Reply-To: References: <7C048FF7-7865-47B1-81F3-E93D79413B4B@dino.hostasaurus.com> Message-ID: <000901d4e630$4e186fb0$ea494f10$@gvtc.com> Why does cogent seem like the commonality between those 2 that you mentioned :| - Aaron ------------------------------------------------------------------------------------------------- "I think what you were remembering is Cogent/Google and Cogent/HE are both IPv6 issues where the parties can't agree on peering vs transit for the v6 relationship." From jlewis at lewis.org Fri Mar 29 13:41:13 2019 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 29 Mar 2019 09:41:13 -0400 (EDT) Subject: Was wrong Re: Did IPv6 between HE and Google ever get resolved? In-Reply-To: <000901d4e630$4e186fb0$ea494f10$@gvtc.com> References: <7C048FF7-7865-47B1-81F3-E93D79413B4B@dino.hostasaurus.com> <000901d4e630$4e186fb0$ea494f10$@gvtc.com> Message-ID: On Fri, 29 Mar 2019, Aaron Gould wrote: > Why does cogent seem like the commonality between those 2 that you mentioned :| Why do people think the policy as to whether or not they can peer or have to buy transit should be different for one address family vs the other? Why will some networks peer at an IX but refuse to make changes (like new port IPs or new ASN for the same organization they already peer with)? Regardless, this is why it pays to multi-home and peer as much as possible. If you directly peer with the networks one of your transit providers is in a pissing match with, the issue is easily ignored. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From job at instituut.net Fri Mar 29 13:44:23 2019 From: job at instituut.net (Job Snijders) Date: Fri, 29 Mar 2019 14:44:23 +0100 Subject: Was wrong Re: Did IPv6 between HE and Google ever get resolved? In-Reply-To: <000901d4e630$4e186fb0$ea494f10$@gvtc.com> References: <7C048FF7-7865-47B1-81F3-E93D79413B4B@dino.hostasaurus.com> <000901d4e630$4e186fb0$ea494f10$@gvtc.com> Message-ID: A careful observer will note multiple fractures/rifts in the ipv6 default-free zone. It’s not as meshed as ipv4, unfortunately. Kind regards, Job -------------- next part -------------- An HTML attachment was scrubbed... URL: From cscora at apnic.net Fri Mar 29 18:03:43 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 30 Mar 2019 04:03:43 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190329180343.4D435C55B5@thyme.apnic.net> 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 at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 30 Mar, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 742948 Prefixes after maximum aggregation (per Origin AS): 285249 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 358190 Total ASes present in the Internet Routing Table: 63769 Prefixes per ASN: 11.65 Origin-only ASes present in the Internet Routing Table: 54888 Origin ASes announcing only one prefix: 23710 Transit ASes present in the Internet Routing Table: 8881 Transit-only ASes present in the Internet Routing Table: 269 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 34 Max AS path prepend of ASN ( 25081) 32 Prefixes from unregistered ASNs in the Routing Table: 29 Number of instances of unregistered ASNs: 32 Number of 32-bit ASNs allocated by the RIRs: 26387 Number of 32-bit ASNs visible in the Routing Table: 21522 Prefixes from 32-bit ASNs in the Routing Table: 94294 Number of bogon 32-bit ASNs visible in the Routing Table: 28 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 267 Number of addresses announced to Internet: 2845039488 Equivalent to 169 /8s, 147 /16s and 219 /24s Percentage of available address space announced: 76.8 Percentage of allocated address space announced: 76.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.2 Total number of prefixes smaller than registry allocations: 248634 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 200727 Total APNIC prefixes after maximum aggregation: 57903 APNIC Deaggregation factor: 3.47 Prefixes being announced from the APNIC address blocks: 197663 Unique aggregates announced from the APNIC address blocks: 82276 APNIC Region origin ASes present in the Internet Routing Table: 9640 APNIC Prefixes per ASN: 20.50 APNIC Region origin ASes announcing only one prefix: 2717 APNIC Region transit ASes present in the Internet Routing Table: 1422 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 30 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4617 Number of APNIC addresses announced to Internet: 769678720 Equivalent to 45 /8s, 224 /16s and 93 /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-139577 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: 219503 Total ARIN prefixes after maximum aggregation: 103821 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 218452 Unique aggregates announced from the ARIN address blocks: 104995 ARIN Region origin ASes present in the Internet Routing Table: 18421 ARIN Prefixes per ASN: 11.86 ARIN Region origin ASes announcing only one prefix: 6869 ARIN Region transit ASes present in the Internet Routing Table: 1884 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2638 Number of ARIN addresses announced to Internet: 1079403648 Equivalent to 64 /8s, 86 /16s and 100 /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-399260 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: 205008 Total RIPE prefixes after maximum aggregation: 97638 RIPE Deaggregation factor: 2.10 Prefixes being announced from the RIPE address blocks: 201350 Unique aggregates announced from the RIPE address blocks: 119435 RIPE Region origin ASes present in the Internet Routing Table: 25936 RIPE Prefixes per ASN: 7.76 RIPE Region origin ASes announcing only one prefix: 11511 RIPE Region transit ASes present in the Internet Routing Table: 3677 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7962 Number of RIPE addresses announced to Internet: 718072960 Equivalent to 42 /8s, 204 /16s and 236 /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-210331 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: 96714 Total LACNIC prefixes after maximum aggregation: 21583 LACNIC Deaggregation factor: 4.48 Prefixes being announced from the LACNIC address blocks: 98073 Unique aggregates announced from the LACNIC address blocks: 42028 LACNIC Region origin ASes present in the Internet Routing Table: 8223 LACNIC Prefixes per ASN: 11.93 LACNIC Region origin ASes announcing only one prefix: 2179 LACNIC Region transit ASes present in the Internet Routing Table: 1533 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 27 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5768 Number of LACNIC addresses announced to Internet: 173549824 Equivalent to 10 /8s, 88 /16s and 41 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + 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: 20966 Total AfriNIC prefixes after maximum aggregation: 4282 AfriNIC Deaggregation factor: 4.90 Prefixes being announced from the AfriNIC address blocks: 27143 Unique aggregates announced from the AfriNIC address blocks: 9218 AfriNIC Region origin ASes present in the Internet Routing Table: 1262 AfriNIC Prefixes per ASN: 21.51 AfriNIC Region origin ASes announcing only one prefix: 434 AfriNIC Region transit ASes present in the Internet Routing Table: 246 Average AfriNIC Region AS path length visible: 4.9 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 537 Number of AfriNIC addresses announced to Internet: 104060672 Equivalent to 6 /8s, 51 /16s and 215 /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 7545 4720 545 547 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4660 4192 74 ERX-CERNET-BKB China Education and Rese 7552 3125 1297 53 VIETEL-AS-AP Viettel Group, VN 45899 3034 1733 110 VNPT-AS-VN VNPT Corp, VN 9829 2708 1490 563 BSNL-NIB National Internet Backbone, IN 4766 2612 11120 761 KIXS-AS-KR Korea Telecom, KR 9808 2435 8699 27 CMNET-GD Guangdong Mobile Communication 9394 2183 4906 31 CTTNET China TieTong Telecommunications 4755 2148 429 186 TATACOMM-AS TATA Communications formerl 9498 2030 426 167 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 11492 3605 234 580 CABLEONE - CABLE ONE, INC., US 6327 3600 1325 94 SHAW - Shaw Communications Inc., CA 22773 3382 2976 162 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2612 5902 1080 AMAZON-02 - Amazon.com, Inc., US 16625 2345 1293 1788 AKAMAI-AS - Akamai Technologies, Inc., 20115 2151 2747 535 CHARTER-20115 - Charter Communications, 30036 2143 353 142 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 18566 2111 405 108 MEGAPATH5-US - MegaPath Corporation, US 5650 2086 3074 1462 FRONTIER-FRTR - Frontier Communications 209 2065 5103 576 CENTURYLINK-US-LEGACY-QWEST - CenturyLi 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 5432 1628 139 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3265 378 45 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2643 537 1914 AKAMAI-ASN1, US 12389 2225 2221 636 ROSTELECOM-AS, RU 34984 2073 342 536 TELLCOM-AS, TR 9121 1683 1693 19 TTNET, TR 13188 1605 100 47 TRIOLAN, UA 9009 1410 146 767 M247, GB 8402 1249 545 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 8151 5654 3337 588 Uninet S.A. de C.V., MX 10620 3484 537 369 Telmex Colombia S.A., CO 11830 2705 384 34 Instituto Costarricense de Electricidad 7303 1449 987 252 Telecom Argentina S.A., AR 6503 1369 433 53 Axtel, S.A.B. de C.V., MX 28573 1328 2248 179 CLARO S.A., BR 6147 1254 377 29 Telefonica del Peru S.A.A., PE 3816 1023 506 114 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 13999 956 522 248 Mega Cable, S.A. de C.V., MX 11172 953 144 66 Alestra, S. de R.L. de C.V., MX 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 1176 393 21 LINKdotNET-AS, EG 37611 892 107 9 Afrihost, ZA 36903 827 416 126 MT-MPLS, MA 36992 825 1531 71 ETISALAT-MISR, EG 24835 824 620 22 RAYA-AS, EG 8452 683 1731 19 TE-AS TE-AS, EG 29571 484 70 12 ORANGE-COTE-IVOIRE, CI 37492 470 470 57 ORANGE-, TN 15706 421 32 6 Sudatel, SD 37342 420 32 1 MOVITEL, MZ 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 5654 3337 588 Uninet S.A. de C.V., MX 12479 5432 1628 139 UNI2-AS, ES 7545 4720 545 547 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4660 4192 74 ERX-CERNET-BKB China Education and Rese 39891 3778 203 20 ALJAWWALSTC-AS, SA 11492 3605 234 580 CABLEONE - CABLE ONE, INC., US 6327 3600 1325 94 SHAW - Shaw Communications Inc., CA 10620 3484 537 369 Telmex Colombia S.A., CO 22773 3382 2976 162 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8551 3265 378 45 BEZEQ-INTERNATIONAL-AS Bezeqint Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5432 5293 UNI2-AS, ES 4538 4660 4586 ERX-CERNET-BKB China Education and Research Net 7545 4720 4173 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3600 3506 SHAW - Shaw Communications Inc., CA 22773 3382 3220 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3265 3220 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 10620 3484 3115 Telmex Colombia S.A., CO 7552 3125 3072 VIETEL-AS-AP Viettel Group, VN 11492 3605 3025 CABLEONE - CABLE ONE, INC., 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 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65550 DOCUMENT 81.8.34.0/24 15924 BORUSANTELEKOM-AS, TR 65550 DOCUMENT 81.8.35.0/24 15924 BORUSANTELEKOM-AS, TR 1358592 UNALLOCATED 103.134.14.0/23 63956 COLO-AS-AP Colocation Australi 1358592 UNALLOCATED 103.134.14.0/24 63956 COLO-AS-AP Colocation Australi 1358592 UNALLOCATED 103.134.15.0/24 63956 COLO-AS-AP Colocation Australi 65550 DOCUMENT 104.232.236.0/24 138005 LENOVO-AS1-AP LENOVO (HONG KON 65549 DOCUMENT 117.239.163.0/24 65544 UNKNOWN 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.180.104.0/24 209737 MERICHOSTING, TR 5.180.105.0/24 209737 MERICHOSTING, TR 5.180.106.0/24 209737 MERICHOSTING, TR 5.180.107.0/24 209737 MERICHOSTING, TR 27.100.7.0/24 56096 UNKNOWN 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -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:12 /9:10 /10:36 /11:100 /12:291 /13:567 /14:1136 /15:1909 /16:13349 /17:7956 /18:13904 /19:25672 /20:39960 /21:46165 /22:92979 /23:75705 /24:422219 /25:978 /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 12479 4345 5432 UNI2-AS, ES 6327 3374 3600 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2819 3605 CABLEONE - CABLE ONE, INC., US 8551 2718 3265 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2620 3382 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 11830 2050 2705 Instituto Costarricense de Electricidad y Telec 18566 2006 2111 MEGAPATH5-US - MegaPath Corporation, US 30036 1890 2143 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1754 2086 FRONTIER-FRTR - Frontier Communications of Amer Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1610 2:927 4:22 5:2954 6:45 7:1 8:1284 9:1 11:3 12:1845 13:322 14:1969 15:36 16:4 17:241 18:58 20:49 23:2652 24:2528 25:2 27:2503 31:2095 32:97 35:36 36:851 37:3027 38:1707 39:294 40:120 41:3250 42:757 43:2018 44:148 45:7062 46:3245 47:254 49:1361 50:1101 51:322 52:1031 54:289 55:2 56:9 57:42 58:1788 59:1072 60:505 61:2126 62:2114 63:1814 64:4949 65:2211 66:4840 67:2701 68:1170 69:3526 70:1327 71:603 72:2447 74:2753 75:514 76:550 77:1718 78:1766 79:2323 80:1813 81:1510 82:1134 83:902 84:1114 85:2295 86:554 87:1569 88:1050 89:2572 90:219 91:6581 92:1377 93:2447 94:2553 95:3206 96:923 97:345 98:949 99:210 100:87 101:1153 102:489 103:20775 104:3520 105:248 106:846 107:1781 108:691 109:3742 110:1642 111:1901 112:1485 113:1392 114:1140 115:1731 116:1721 117:1900 118:2180 119:1645 120:1025 121:1037 122:2351 123:1660 124:1472 125:1981 128:1264 129:815 130:532 131:1676 132:733 133:219 134:1052 135:242 136:563 137:715 138:2042 139:844 140:577 141:855 142:797 143:1057 144:841 145:509 146:1265 147:834 148:1716 149:818 150:784 151:1010 152:1042 153:322 154:2819 155:902 156:1679 157:941 158:640 159:1919 160:1514 161:921 162:2699 163:800 164:1161 165:1562 166:439 167:1393 168:3291 169:868 170:4152 171:568 172:1127 173:2201 174:1035 175:917 176:2354 177:4196 178:2542 179:1465 180:2176 181:2398 182:2662 183:1074 184:1199 185:14899 186:3656 187:2475 188:2877 189:1981 190:8303 191:1528 192:10027 193:6662 194:5401 195:4077 196:3024 197:1747 198:5867 199:5987 200:7239 201:5106 202:10386 203:10112 204:4547 205:3008 206:3225 207:3258 208:3967 209:4239 210:3927 211:2008 212:3131 213:2928 214:1091 215:55 216:5939 217:2234 218:880 219:580 220:1875 221:968 222:988 223:1370 End of report From aaron at heyaaron.com Fri Mar 29 19:47:56 2019 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Fri, 29 Mar 2019 12:47:56 -0700 Subject: Qwest CenturyLink / Telia issues near Seattle? Message-ID: For the past ~36 hours I have been seeing 15% packet loss between CenturyLink and Telia. I regularly access equipment in a Wave Broadband datacenter in Longview, WA from my office connected via ToldeoTel and the traffic transits Qwest/CenturyLink over to Telia before hitting Wave. I have a handful of clients affected too. I contacted Wave yesterday and they said CenturyLink is aware that the link to Telia is 'completely saturated' and working on it. I contacted Wave again today to see if they had an update and they said no. ToledoTel didn't have any update either. Can anyone shed some light on it? Or an ETA for resolving it? Thanks, -A -------------- next part -------------- An HTML attachment was scrubbed... URL: From eparra at zscaler.com Fri Mar 29 21:36:48 2019 From: eparra at zscaler.com (Eddie Parra) Date: Fri, 29 Mar 2019 14:36:48 -0700 Subject: Contact wanted: abc.go.com Message-ID: <8DEBF6AA-1E76-42B3-9F09-6DB0349BDD03@zscaler.com> Does anyone have a contact for abc.go.com? If so, could you please contact me offline? Thanks, -Eddie From mike.lyon at gmail.com Fri Mar 29 23:19:28 2019 From: mike.lyon at gmail.com (Mike Lyon) Date: Fri, 29 Mar 2019 16:19:28 -0700 Subject: Anyone from Peloton Interactive on the list? Message-ID: If so, please contact me off list. Thank You, Mike -- Mike Lyon mike.lyon at gmail.com http://www.linkedin.com/in/mlyon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpetach at netflight.com Sat Mar 30 11:33:07 2019 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 30 Mar 2019 04:33:07 -0700 Subject: Did IPv6 between HE and Google ever get resolved? In-Reply-To: <84C6285F-9D45-4B87-9FC8-F541A246195E@dino.hostasaurus.com> References: <84C6285F-9D45-4B87-9FC8-F541A246195E@dino.hostasaurus.com> Message-ID: On Thu, Mar 28, 2019 at 12:40 PM David Hubbard < dhubbard at dino.hostasaurus.com> wrote: > Hey all, I’ve been having bad luck searching around, but did IPv6 transit > between HE and google ever get resolved? Ironically, I can now get to them > cheaply from a location we currently have equipment that has been > Cogent-only, so if it fixes the IPv6 issue I’d like to make the move. > Anyone peer with HE in general and want to share their experience offlist? > With the price, if they’re a good option, I’d consider rolling them in to > other locations where we have redundancy already, so the v6 isn’t as big a > deal there. > > > > Thanks > > > I wasn't aware of any issues between HE.net and Google; are you sure you don't mean HE.net and Cogent? Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpetach at netflight.com Sat Mar 30 11:35:35 2019 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 30 Mar 2019 04:35:35 -0700 Subject: Did IPv6 between HE and Google ever get resolved? In-Reply-To: References: <84C6285F-9D45-4B87-9FC8-F541A246195E@dino.hostasaurus.com> Message-ID: On Sat, Mar 30, 2019 at 4:33 AM Matthew Petach wrote: > > > On Thu, Mar 28, 2019 at 12:40 PM David Hubbard < > dhubbard at dino.hostasaurus.com> wrote: > >> Hey all, I’ve been having bad luck searching around, but did IPv6 transit >> between HE and google ever get resolved? Ironically, I can now get to them >> cheaply from a location we currently have equipment that has been >> Cogent-only, so if it fixes the IPv6 issue I’d like to make the move. >> Anyone peer with HE in general and want to share their experience offlist? >> With the price, if they’re a good option, I’d consider rolling them in to >> other locations where we have redundancy already, so the v6 isn’t as big a >> deal there. >> >> >> >> Thanks >> >> >> > > I wasn't aware of any issues between HE.net and Google; > are you sure you don't mean HE.net and Cogent? > > Matt > > Ah. Sorry, the changed subject line didn't thread in with this, so this showed up as an unreplied singleton in my inbox. Apologies for the duplicated response; at least this won't be a lonely singleton in anyone else's inbox now. ^_^; Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfillekes at gmail.com Sat Mar 30 14:34:39 2019 From: cfillekes at gmail.com (C. A. Fillekes) Date: Sat, 30 Mar 2019 10:34:39 -0400 Subject: Frontier rural FIOS & IPv6 Message-ID: So by COB yesterday we now officially have FIOS at our farm. Went from 3Mbps to around 30 measured average. Yay. It's a business account, Frontier. But...still no IPv6. The new router's capable of it. What's the hold up? Customer service's response is "We don't offer that". -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron at heyaaron.com Sun Mar 31 20:24:07 2019 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Sun, 31 Mar 2019 13:24:07 -0700 Subject: Frontier rural FIOS & IPv6 In-Reply-To: References: Message-ID: You're not alone. I talked with my local provider about 4 years ago and they said "We will probably start looking into IPv6 next year". I talked with them last month and they said "Yeah, everyone seems to be offering it. I guess I'll have to start reading how to implement it". I'm sure 2045 will finally be the year of IPv6 everywhere. -A On Sat, Mar 30, 2019 at 7:36 AM C. A. Fillekes wrote: > > So by COB yesterday we now officially have FIOS at our farm. > > Went from 3Mbps to around 30 measured average. Yay. > > It's a business account, Frontier. But...still no IPv6. > > The new router's capable of it. What's the hold up? > > Customer service's response is "We don't offer that". > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhubbard at dino.hostasaurus.com Sun Mar 31 20:31:13 2019 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Sun, 31 Mar 2019 20:31:13 +0000 Subject: Frontier rural FIOS & IPv6 In-Reply-To: References: Message-ID: <698612A2-3A02-449B-9D01-10CF723CB6D1@dino.hostasaurus.com> Things are no better in Spectrum land; gotta love the innovation in monopoly markets…. I ask every year and expect it in perhaps thirty. From: NANOG on behalf of "Aaron C. de Bruyn via NANOG" Reply-To: "Aaron C. de Bruyn" Date: Sunday, March 31, 2019 at 4:26 PM To: "C. A. Fillekes" Cc: NANOG mailing list Subject: Re: Frontier rural FIOS & IPv6 You're not alone. I talked with my local provider about 4 years ago and they said "We will probably start looking into IPv6 next year". I talked with them last month and they said "Yeah, everyone seems to be offering it. I guess I'll have to start reading how to implement it". I'm sure 2045 will finally be the year of IPv6 everywhere. -A On Sat, Mar 30, 2019 at 7:36 AM C. A. Fillekes > wrote: So by COB yesterday we now officially have FIOS at our farm. Went from 3Mbps to around 30 measured average. Yay. It's a business account, Frontier. But...still no IPv6. The new router's capable of it. What's the hold up? Customer service's response is "We don't offer that". -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcarpen at network1.net Sun Mar 31 20:43:07 2019 From: rcarpen at network1.net (Randy Carpenter) Date: Sun, 31 Mar 2019 16:43:07 -0400 (EDT) Subject: Frontier rural FIOS & IPv6 In-Reply-To: <698612A2-3A02-449B-9D01-10CF723CB6D1@dino.hostasaurus.com> References: <698612A2-3A02-449B-9D01-10CF723CB6D1@dino.hostasaurus.com> Message-ID: FWIW, I have had IPv6 for many years on my Spectrum (formerly Time Warner) connection at home. I think it was ~2012 or so. On our company fiber connection, it has been since ~2010, maybe a little earlier. Granted it took a little pressure and I’m sure were were the first IPv6 business customer in our area. -Randy > On Mar 31, 2019, at 16:32, David Hubbard wrote: > > Things are no better in Spectrum land; gotta love the innovation in monopoly markets…. I ask every year and expect it in perhaps thirty. > > From: NANOG on behalf of "Aaron C. de Bruyn via NANOG" > Reply-To: "Aaron C. de Bruyn" > Date: Sunday, March 31, 2019 at 4:26 PM > To: "C. A. Fillekes" > Cc: NANOG mailing list > Subject: Re: Frontier rural FIOS & IPv6 > > You're not alone. > > I talked with my local provider about 4 years ago and they said "We will probably start looking into IPv6 next year". > I talked with them last month and they said "Yeah, everyone seems to be offering it. I guess I'll have to start reading how to implement it". > > I'm sure 2045 will finally be the year of IPv6 everywhere. > > -A > > On Sat, Mar 30, 2019 at 7:36 AM C. A. Fillekes wrote: > > So by COB yesterday we now officially have FIOS at our farm. > > Went from 3Mbps to around 30 measured average. Yay. > > It's a business account, Frontier. But...still no IPv6. > > The new router's capable of it. What's the hold up? > > Customer service's response is "We don't offer that". > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethm at rollernet.us Sun Mar 31 20:53:39 2019 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 31 Mar 2019 13:53:39 -0700 Subject: Frontier rural FIOS & IPv6 In-Reply-To: <698612A2-3A02-449B-9D01-10CF723CB6D1@dino.hostasaurus.com> References: <698612A2-3A02-449B-9D01-10CF723CB6D1@dino.hostasaurus.com> Message-ID: On 3/31/19 13:31, David Hubbard wrote: > Things are no better in Spectrum land; gotta love the innovation in > monopoly markets….  I ask every year and expect it in perhaps thirty. It depends if you're Charter or Time Warner. Charter does. From cfillekes at gmail.com Sun Mar 31 23:11:09 2019 From: cfillekes at gmail.com (C. A. Fillekes) Date: Sun, 31 Mar 2019 19:11:09 -0400 Subject: Frontier rural FIOS & IPv6 In-Reply-To: References: Message-ID: Still it's pretty darn good having real broadband on the farm. One thing at a time. But, let's start thinking about ways to get Frontier up to speed on the IPv6 thing. On Sun, Mar 31, 2019 at 4:24 PM Aaron C. de Bruyn wrote: > You're not alone. > > I talked with my local provider about 4 years ago and they said "We will > probably start looking into IPv6 next year". > I talked with them last month and they said "Yeah, everyone seems to be > offering it. I guess I'll have to start reading how to implement it". > > I'm sure 2045 will finally be the year of IPv6 everywhere. > > -A > > On Sat, Mar 30, 2019 at 7:36 AM C. A. Fillekes > wrote: > >> >> So by COB yesterday we now officially have FIOS at our farm. >> >> Went from 3Mbps to around 30 measured average. Yay. >> >> It's a business account, Frontier. But...still no IPv6. >> >> The new router's capable of it. What's the hold up? >> >> Customer service's response is "We don't offer that". >> >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattlists at rivervalleyinternet.net Sun Mar 31 23:19:39 2019 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Sun, 31 Mar 2019 19:19:39 -0400 Subject: Frontier rural FIOS & IPv6 In-Reply-To: References: Message-ID: <293EE676-667B-4984-A37F-DA077D175E25@rivervalleyinternet.net> Going to play devils advocate. If frontier has a ton of ipv4 addresses, what benefit is there to them in rolling out ipv6? What benefit is there to you? > On Mar 31, 2019, at 7:11 PM, C. A. Fillekes wrote: > > > Still it's pretty darn good having real broadband on the farm. One thing at a time. > > But, let's start thinking about ways to get Frontier up to speed on the IPv6 thing. > > >> On Sun, Mar 31, 2019 at 4:24 PM Aaron C. de Bruyn wrote: >> You're not alone. >> >> I talked with my local provider about 4 years ago and they said "We will probably start looking into IPv6 next year". >> I talked with them last month and they said "Yeah, everyone seems to be offering it. I guess I'll have to start reading how to implement it". >> >> I'm sure 2045 will finally be the year of IPv6 everywhere. >> >> -A >> >>> On Sat, Mar 30, 2019 at 7:36 AM C. A. Fillekes wrote: >>> >>> So by COB yesterday we now officially have FIOS at our farm. >>> >>> Went from 3Mbps to around 30 measured average. Yay. >>> >>> It's a business account, Frontier. But...still no IPv6. >>> >>> The new router's capable of it. What's the hold up? >>> >>> Customer service's response is "We don't offer that". >>> >>> >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamie.stephens at gmail.com Sun Mar 31 20:43:08 2019 From: jamie.stephens at gmail.com (Jamie Stephens) Date: Sun, 31 Mar 2019 16:43:08 -0400 Subject: Frontier rural FIOS & IPv6 In-Reply-To: <698612A2-3A02-449B-9D01-10CF723CB6D1@dino.hostasaurus.com> References: <698612A2-3A02-449B-9D01-10CF723CB6D1@dino.hostasaurus.com> Message-ID: Depends on the spectrum markets. I have dual stack ipv6 at my house in NC On Mar 31, 2019, at 4:32 PM, David Hubbard wrote: Things are no better in Spectrum land; gotta love the innovation in monopoly markets…. I ask every year and expect it in perhaps thirty. From: NANOG on behalf of "Aaron C. de Bruyn via NANOG" Reply-To: "Aaron C. de Bruyn" Date: Sunday, March 31, 2019 at 4:26 PM To: "C. A. Fillekes" Cc: NANOG mailing list Subject: Re: Frontier rural FIOS & IPv6 You're not alone. I talked with my local provider about 4 years ago and they said "We will probably start looking into IPv6 next year". I talked with them last month and they said "Yeah, everyone seems to be offering it. I guess I'll have to start reading how to implement it". I'm sure 2045 will finally be the year of IPv6 everywhere. -A Jamie Stephens 864.438.8014 Sent from my mobile, please excuse any typos On Sat, Mar 30, 2019 at 7:36 AM C. A. Fillekes wrote: So by COB yesterday we now officially have FIOS at our farm. Went from 3Mbps to around 30 measured average. Yay. It's a business account, Frontier. But...still no IPv6. The new router's capable of it. What's the hold up? Customer service's response is "We don't offer that". -------------- next part -------------- An HTML attachment was scrubbed... URL: