From fergdawgster at mykolab.com Fri Feb 2 03:59:11 2018 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Thu, 1 Feb 2018 19:59:11 -0800 Subject: listserv hosed? [Was: Fwd: nanog.org mailing list memberships reminder] In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 oh noes. the listserv deded. Started getting a series of these just now from the past. :-) And yes, the headers reveal that they are indeed coming from the NANOG listserv/MailMan. Can someone please fix that? kthxbai. :-) - - ferg - -------- Forwarded Message -------- Subject: nanog.org mailing list memberships reminder Date: Fri, 01 Sep 2017 05:00:40 +0000 From: mailman-owner at nanog.org To: fergdawgster at mykolab.com This is a reminder, sent out once a month, about your nanog.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. [...] - -- Paul Ferguson ICEBRG.io, Seattle USA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlpz4g8ACgkQKJasdVTchbIYkwD/YKFV2FP6R+Ow0o2HuiWfAD/H +7s2kWMowu0L3rpu1ssA/j+NTaDvydw99/BHG3ZAfj8XYItxDU8zYC976kS81AvF =Rexp -----END PGP SIGNATURE----- From jfmezei_nanog at vaxination.ca Fri Feb 2 04:07:13 2018 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 1 Feb 2018 23:07:13 -0500 Subject: listserv hosed? [Was: Fwd: nanog.org mailing list memberships reminder] In-Reply-To: References: Message-ID: <033df4c5-47c8-014b-8e1e-466fca8888f0@vaxination.ca> On 2018-02-01 22:59, Paul Ferguson wrote: > Started getting a series of these just now from the past. :-) Same here. The 821 headers show Received: to be "now", while the RFC 822 headers have a Date of first of where Month started in August 2017. Suspect something got reset and the list server is just catching up with the monthly reminders. From rsk at gsp.org Fri Feb 2 11:30:20 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 2 Feb 2018 06:30:20 -0500 Subject: listserv hosed? [Was: Fwd: nanog.org mailing list memberships reminder] In-Reply-To: References: Message-ID: <20180202113020.GA9634@gsp.org> 1. It's not a listserv. It's a mailing list. ListServ is obsolete, expensive, closed-source garbage software used exclusively by people who don't know any better and like to waste their money. 2. This problem was possibly, but not certainly, caused by a misfiring cron job. (I've seen it before.) The list-owner(s) were probably made aware of it almost immediately, because on a mailing list of this size, there are always SMTP rejects of some small fraction of the monthly reminders -- and this time, they probably arrived in batches of 16. ---rsk From lyle at lcrcomputer.net Fri Feb 2 13:18:33 2018 From: lyle at lcrcomputer.net (Lyle Giese) Date: Fri, 2 Feb 2018 07:18:33 -0600 Subject: listserv hosed? [Was: Fwd: nanog.org mailing list memberships reminder] In-Reply-To: <033df4c5-47c8-014b-8e1e-466fca8888f0@vaxination.ca> References: <033df4c5-47c8-014b-8e1e-466fca8888f0@vaxination.ca> Message-ID: Groundhog day AGAIN! Lyle On 2/1/2018 10:07 PM, Jean-Francois Mezei wrote: > On 2018-02-01 22:59, Paul Ferguson wrote: > >> Started getting a series of these just now from the past. :-) > > Same here. The 821 headers show Received: to be "now", while the RFC > 822 headers have a Date of first of where Month started in > August 2017. > > Suspect something got reset and the list server is just catching up with > the monthly reminders. From vwittkop at nanog.org Fri Feb 2 15:33:55 2018 From: vwittkop at nanog.org (Valerie Wittkop) Date: Fri, 2 Feb 2018 10:33:55 -0500 Subject: listserv hosed? [Was: Fwd: nanog.org mailing list memberships reminder] In-Reply-To: References: <033df4c5-47c8-014b-8e1e-466fca8888f0@vaxination.ca> Message-ID: Last night there was an update to the OS of our production environment, and a restart of the system. We are currently working to confirm all is functioning properly. Apologies for the extra noise in the mail list. Cheers, Valerie Valerie Wittkop NANOG Program Director Tel: +1 866 902 1336, ext 103 > On Feb 2, 2018, at 8:18 AM, Lyle Giese wrote: > > Groundhog day AGAIN! > > Lyle > > On 2/1/2018 10:07 PM, Jean-Francois Mezei wrote: >> On 2018-02-01 22:59, Paul Ferguson wrote: >> >>> Started getting a series of these just now from the past. :-) >> >> Same here. The 821 headers show Received: to be "now", while the RFC >> 822 headers have a Date of first of where Month started in >> August 2017. >> >> Suspect something got reset and the list server is just catching up with >> the monthly reminders. > > From cscora at apnic.net Fri Feb 2 18:03:29 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 3 Feb 2018 04:03:29 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180202180329.61981C450F@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, CaribNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG 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 03 Feb, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 683343 Prefixes after maximum aggregation (per Origin AS): 264741 Deaggregation factor: 2.58 Unique aggregates announced (without unneeded subnets): 329756 Total ASes present in the Internet Routing Table: 59719 Prefixes per ASN: 11.44 Origin-only ASes present in the Internet Routing Table: 51573 Origin ASes announcing only one prefix: 22679 Transit ASes present in the Internet Routing Table: 8146 Transit-only ASes present in the Internet Routing Table: 249 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 34 Max AS path prepend of ASN ( 30873) 32 Prefixes from unregistered ASNs in the Routing Table: 59 Number of instances of unregistered ASNs: 60 Number of 32-bit ASNs allocated by the RIRs: 21370 Number of 32-bit ASNs visible in the Routing Table: 17156 Prefixes from 32-bit ASNs in the Routing Table: 70940 Number of bogon 32-bit ASNs visible in the Routing Table: 13 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 336 Number of addresses announced to Internet: 2858256034 Equivalent to 170 /8s, 93 /16s and 134 /24s Percentage of available address space announced: 77.2 Percentage of allocated address space announced: 77.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.8 Total number of prefixes smaller than registry allocations: 225749 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 188424 Total APNIC prefixes after maximum aggregation: 53664 APNIC Deaggregation factor: 3.51 Prefixes being announced from the APNIC address blocks: 187544 Unique aggregates announced from the APNIC address blocks: 77378 APNIC Region origin ASes present in the Internet Routing Table: 8617 APNIC Prefixes per ASN: 21.76 APNIC Region origin ASes announcing only one prefix: 2448 APNIC Region transit ASes present in the Internet Routing Table: 1264 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 28 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3523 Number of APNIC addresses announced to Internet: 767340322 Equivalent to 45 /8s, 188 /16s and 175 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 203949 Total ARIN prefixes after maximum aggregation: 97708 ARIN Deaggregation factor: 2.09 Prefixes being announced from the ARIN address blocks: 204769 Unique aggregates announced from the ARIN address blocks: 96443 ARIN Region origin ASes present in the Internet Routing Table: 18070 ARIN Prefixes per ASN: 11.33 ARIN Region origin ASes announcing only one prefix: 6682 ARIN Region transit ASes present in the Internet Routing Table: 1797 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: 2301 Number of ARIN addresses announced to Internet: 1108936224 Equivalent to 66 /8s, 25 /16s and 6 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 184591 Total RIPE prefixes after maximum aggregation: 89911 RIPE Deaggregation factor: 2.05 Prefixes being announced from the RIPE address blocks: 180884 Unique aggregates announced from the RIPE address blocks: 108562 RIPE Region origin ASes present in the Internet Routing Table: 24840 RIPE Prefixes per ASN: 7.28 RIPE Region origin ASes announcing only one prefix: 11318 RIPE Region transit ASes present in the Internet Routing Table: 3483 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6610 Number of RIPE addresses announced to Internet: 713614976 Equivalent to 42 /8s, 136 /16s and 230 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 88114 Total LACNIC prefixes after maximum aggregation: 19461 LACNIC Deaggregation factor: 4.53 Prefixes being announced from the LACNIC address blocks: 89454 Unique aggregates announced from the LACNIC address blocks: 39866 LACNIC Region origin ASes present in the Internet Routing Table: 6803 LACNIC Prefixes per ASN: 13.15 LACNIC Region origin ASes announcing only one prefix: 1867 LACNIC Region transit ASes present in the Internet Routing Table: 1257 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 31 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4331 Number of LACNIC addresses announced to Internet: 172324320 Equivalent to 10 /8s, 69 /16s and 117 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 18204 Total AfriNIC prefixes after maximum aggregation: 3951 AfriNIC Deaggregation factor: 4.61 Prefixes being announced from the AfriNIC address blocks: 20356 Unique aggregates announced from the AfriNIC address blocks: 7237 AfriNIC Region origin ASes present in the Internet Routing Table: 1114 AfriNIC Prefixes per ASN: 18.27 AfriNIC Region origin ASes announcing only one prefix: 363 AfriNIC Region transit ASes present in the Internet Routing Table: 223 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 391 Number of AfriNIC addresses announced to Internet: 95656192 Equivalent to 5 /8s, 179 /16s and 153 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5429 4195 92 ERX-CERNET-BKB China Education and Rese 7545 3752 406 407 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2878 11132 769 KIXS-AS-KR Korea Telecom, KR 9829 2770 1499 539 BSNL-NIB National Internet Backbone, IN 17974 2767 934 77 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9394 2635 4923 27 CTTNET China TieTong Telecommunications 7552 2615 1160 65 VIETEL-AS-AP Viettel Group, VN 45899 2580 1550 154 VNPT-AS-VN VNPT Corp, VN 9808 2166 8699 32 CMNET-GD Guangdong Mobile Communication 4755 2088 417 209 TATACOMM-AS TATA Communications formerl 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 3385 1323 86 SHAW - Shaw Communications Inc., CA 22773 3265 2951 144 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2167 405 108 MEGAPATH5-US - MegaPath Corporation, US 20115 2081 2367 437 CHARTER-NET-HKY-NC - Charter Communicat 16509 1999 4162 575 AMAZON-02 - Amazon.com, Inc., US 6389 1938 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 209 1912 5059 619 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1894 334 214 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 11492 1735 231 557 CABLEONE - CABLE ONE, INC., US 7018 1681 20183 1248 ATT-INTERNET4 - AT&T Services, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3520 187 21 ALJAWWALSTC-AS, SA 20940 2837 832 2057 AKAMAI-ASN1, US 8551 2232 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12479 2211 1123 272 UNI2-AS, ES 12389 2120 1859 701 ROSTELECOM-AS, RU 34984 2002 332 474 TELLCOM-AS, TR 9121 1936 1691 17 TTNET, TR 13188 1605 100 46 TRIOLAN, UA 8402 1281 544 14 CORBINA-AS OJSC "Vimpelcom", RU 6849 1240 355 21 UKRTELNET, UA 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 4143 3386 590 Uninet S.A. de C.V., MX 10620 3595 542 237 Telmex Colombia S.A., CO 11830 2636 370 66 Instituto Costarricense de Electricidad 6503 1629 437 53 Axtel, S.A.B. de C.V., MX 7303 1505 1025 192 Telecom Argentina S.A., AR 6147 1030 377 27 Telefonica del Peru S.A.A., PE 28573 1016 2242 191 CLARO S.A., BR 3816 1014 509 114 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 920 126 85 Alestra, S. de R.L. de C.V., MX 18881 906 1067 28 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1192 398 50 LINKdotNET-AS, EG 37611 789 91 8 Afrihost, ZA 36903 739 371 135 MT-MPLS, MA 36992 672 1380 37 ETISALAT-MISR, EG 8452 565 1730 18 TE-AS TE-AS, EG 24835 478 786 17 RAYA-AS, EG 29571 462 68 12 ORANGE-COTE-IVOIRE, CI 37492 450 368 78 ORANGE-, TN 37342 360 32 1 MOVITEL, MZ 15399 355 35 7 WANANCHI-, KE Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5429 4195 92 ERX-CERNET-BKB China Education and Rese 8151 4143 3386 590 Uninet S.A. de C.V., MX 7545 3752 406 407 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3595 542 237 Telmex Colombia S.A., CO 39891 3520 187 21 ALJAWWALSTC-AS, SA 6327 3385 1323 86 SHAW - Shaw Communications Inc., CA 22773 3265 2951 144 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 4766 2878 11132 769 KIXS-AS-KR Korea Telecom, KR 20940 2837 832 2057 AKAMAI-ASN1, US 9829 2770 1499 539 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 8151 4143 3553 Uninet S.A. de C.V., MX 39891 3520 3499 ALJAWWALSTC-AS, SA 10620 3595 3358 Telmex Colombia S.A., CO 7545 3752 3345 TPG-INTERNET-AP TPG Telecom Limited, AU 6327 3385 3299 SHAW - Shaw Communications Inc., CA 22773 3265 3121 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 17974 2767 2690 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9394 2635 2608 CTTNET China TieTong Telecommunications Corpora 11830 2636 2570 Instituto Costarricense de Electricidad y Telec 7552 2615 2550 VIETEL-AS-AP Viettel Group, VN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65249 PRIVATE 5.42.234.0/23 35753 ITC ITC AS number, SA 65249 PRIVATE 5.42.234.0/24 35753 ITC ITC AS number, SA 65456 PRIVATE 31.171.126.0/23 199311 AZRT-LX Local Internet Exchang 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 65024 PRIVATE 87.103.234.0/24 39407 CHITATELECOM-AS, RU 65000 PRIVATE 95.179.2.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.3.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.69.0/24 65001 -Private Use AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.14.0/23 10247 NETLINE, ZA 14.192.50.0/23 10247 NETLINE, ZA 14.192.58.0/23 10247 NETLINE, ZA 23.159.192.0/24 54726 AET - AET Hosting Solutions, Inc., US 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/23 10247 NETLINE, ZA 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.228.144.0/22 9829 BSNL-NIB National Internet Backbone, IN 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 43.251.84.0/22 133676 PNPL-AS Precious netcom pvt ltd, IN Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:15 /9:12 /10:37 /11:100 /12:290 /13:563 /14:1092 /15:1895 /16:13330 /17:7774 /18:13638 /19:25295 /20:38825 /21:44967 /22:83912 /23:67887 /24:381470 /25:840 /26:605 /27:658 /28:36 /29:20 /30:18 /31:4 /32:60 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3177 3385 SHAW - Shaw Communications Inc., CA 39891 2946 3520 ALJAWWALSTC-AS, SA 22773 2528 3265 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2061 2167 MEGAPATH5-US - MegaPath Corporation, US 11830 1981 2636 Instituto Costarricense de Electricidad y Telec 8551 1696 2232 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 30036 1654 1894 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1587 3595 Telmex Colombia S.A., CO 11492 1516 1735 CABLEONE - CABLE ONE, INC., US 9121 1420 1936 TTNET, TR Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1575 2:846 4:18 5:2649 6:58 8:1094 9:1 12:1849 13:198 14:1757 15:26 16:3 17:184 18:65 20:49 21:3 23:2538 24:2057 25:2 27:2357 31:1954 32:88 35:23 36:486 37:2538 38:1451 39:243 40:100 41:3065 42:539 43:1952 44:93 45:3618 46:3035 47:197 49:1378 50:1039 51:47 52:941 54:350 55:4 56:7 57:42 58:1584 59:1013 60:388 61:2053 62:1820 63:1813 64:4693 65:2228 66:4493 67:2350 68:1175 69:3193 70:1135 71:560 72:2084 74:2665 75:398 76:420 77:1546 78:1642 79:1683 80:1480 81:1401 82:1056 83:786 84:994 85:1975 86:555 87:1233 88:905 89:2335 90:178 91:6280 92:1163 93:2373 94:2392 95:2719 96:645 97:358 98:928 99:114 100:79 101:1513 102:16 103:17026 104:3272 105:210 106:523 107:1806 108:704 109:2960 110:1574 111:1775 112:1294 113:1388 114:1113 115:1583 116:1644 117:1700 118:2207 119:1683 120:957 121:1050 122:2465 123:1803 124:1458 125:1838 128:1020 129:598 130:440 131:1638 132:597 133:194 134:1003 135:227 136:437 137:474 138:1958 139:557 140:401 141:682 142:778 143:989 144:799 145:446 146:1161 147:745 148:1503 149:710 150:735 151:981 152:763 153:310 154:979 155:752 156:818 157:774 158:613 159:1610 160:858 161:728 162:2557 163:521 164:1223 165:1359 166:395 167:1405 168:3126 169:797 170:3663 171:407 172:1017 173:1903 174:878 175:762 176:1879 177:3912 178:2416 179:1173 180:2233 181:2128 182:2446 183:1102 184:906 185:12330 186:3441 187:2343 188:2628 189:2007 190:8116 191:1286 192:9767 193:5875 194:4772 195:3989 196:2352 197:1435 198:5540 199:5911 200:7295 201:4877 202:10394 203:9984 204:4533 205:2850 206:3054 207:3111 208:4018 209:3921 210:4019 211:2143 212:2962 213:2617 214:895 215:62 216:5831 217:2125 218:901 219:624 220:1734 221:995 222:1050 223:1231 End of report From mansaxel at besserwisser.org Fri Feb 2 18:13:04 2018 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Fri, 2 Feb 2018 19:13:04 +0100 Subject: listserv hosed? [Was: Fwd: nanog.org mailing list memberships reminder] In-Reply-To: <20180202113020.GA9634@gsp.org> References: <20180202113020.GA9634@gsp.org> Message-ID: <20180202181303.GF27444@besserwisser.org> Subject: Re: listserv hosed? [Was: Fwd: nanog.org mailing list memberships reminder] Date: Fri, Feb 02, 2018 at 06:30:20AM -0500 Quoting Rich Kulawiec (rsk at gsp.org): > > 1. It's not a listserv. It's a mailing list. ListServ is obsolete, > expensive, closed-source garbage software used exclusively by people > who don't know any better and like to waste their money. Butbutbut! A VM/370 app that still does all internal processing in EBCDIC, even on POSIX OSes[0], with almost-ascii config files, and that ran very well on VMS? What is there not to love? /Måns, former sysop at SEGATE.SUNET.SE -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 What's the MATTER Sid? ... Is your BEVERAGE unsatisfactory? [0] Eric Thomas, mr LISTSERV himself, told me this when we were migrating that large LISTSERV one dark night 17 years ago. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From valdis.kletnieks at vt.edu Fri Feb 2 21:04:25 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 02 Feb 2018 16:04:25 -0500 Subject: listserv hosed? [Was: Fwd: nanog.org mailing list memberships reminder] In-Reply-To: <20180202113020.GA9634@gsp.org> References: <20180202113020.GA9634@gsp.org> Message-ID: <236118.1517605465@turing-police.cc.vt.edu> On Fri, 02 Feb 2018 06:30:20 -0500, Rich Kulawiec said: > > 1. It's not a listserv. It's a mailing list. ListServ is obsolete, > expensive, closed-source garbage software used exclusively by people > who don't know any better and like to waste their money. Well Rich, your bias is obvious. Have you ever considered that in some cases there's reasons it's used by people who don't agree with your assessment? We recently completed a migration from Listserv to Google Groups. It took us close to 3 years of planning and execution and well over 1 FTE/year, because we had been running Listserv for well over 30 years, and there were a *lot* of places where the way Listserv does things were embedded into business logic or otherwise difficult to replicate/migrate. One biggie - Listserv has this useful feature where you can say "people subscribed to this *OTHER* list are allowed to post". One very large department had well over 100 lists for various things, and all 100 had "accept post from dept-admins@". Worked really slick - if they create a new list, they just have to include that options. If they hire new administrative staff, they just add that person to dept-admins. Then there was the creeping horror for "class lists" - professors got a list for each of their classes, pre-loaded with the roster of the class. When you have 35,000 students, that's a big bunch of lists. (Amazingly enough, I never *did* get our ERP people deploy the Listserv feature of building subscriber lists on the fly using an SQL query - which would have been another thing that would be difficult to replicate (Hint: just doing an extract and doing a bulk mailing is similar - until you try to make "Reply-to: Listname" work) Don't ask how that works under Google Groups - it's another creeping horror :) Now add in the fun of migrating the archives for 12,000+ lists, notify list owners and users of the new addresses, etc etc etc, and suddenly the $4500/year doesn't look so bad. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From valdis.kletnieks at vt.edu Fri Feb 2 21:04:54 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 02 Feb 2018 16:04:54 -0500 Subject: listserv hosed? [Was: Fwd: nanog.org mailing list memberships reminder] In-Reply-To: <20180202181303.GF27444@besserwisser.org> References: <20180202113020.GA9634@gsp.org> <20180202181303.GF27444@besserwisser.org> Message-ID: <236163.1517605494@turing-police.cc.vt.edu> On Fri, 02 Feb 2018 19:13:04 +0100, Måns Nilsson said: > A VM/370 app that still does all internal processing in EBCDIC, even on > POSIX OSes[0], with almost-ascii config files, and that ran very well > on VMS? What is there not to love? > [0] Eric Thomas, mr LISTSERV himself, told me this when we were migrating > that large LISTSERV one dark night 17 years ago. And you have reason to think that it *still* does things that way, 17 years later? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From mansaxel at besserwisser.org Fri Feb 2 22:32:31 2018 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Fri, 2 Feb 2018 23:32:31 +0100 Subject: listserv hosed? [Was: Fwd: nanog.org mailing list memberships reminder] In-Reply-To: <236163.1517605494@turing-police.cc.vt.edu> References: <20180202113020.GA9634@gsp.org> <20180202181303.GF27444@besserwisser.org> <236163.1517605494@turing-police.cc.vt.edu> Message-ID: <20180202223231.GG27444@besserwisser.org> Subject: Re: listserv hosed? [Was: Fwd: nanog.org mailing list memberships reminder] Date: Fri, Feb 02, 2018 at 04:04:54PM -0500 Quoting valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu): > And you have reason to think that it *still* does things that way, 17 years later? I honestly do not know, but I'd suspect so. More of a hunch than anything else, though. It *was* very fast back then, though. Today, not so much of a competitive edge. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 Hold the MAYO & pass the COSMIC AWARENESS ... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From eric.kuhnke at gmail.com Sat Feb 3 02:15:36 2018 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Fri, 2 Feb 2018 18:15:36 -0800 Subject: Merit radb https interface, TLS1.0 only? Message-ID: Is the radb login page supposed to be TLS1.0 only? This is with the latest version of Firefox. Screenshot: https://imgur.com/nnlFmLZ I also noticed that the registration page is plain http/non TLS. for reference: https://www.google.com/search?client=ubuntu&channel=fs&q=tls+1.0+deprecated&ie=utf-8&oe=utf-8 From EPers at ansencorp.com Sat Feb 3 02:25:14 2018 From: EPers at ansencorp.com (Edwin Pers) Date: Sat, 3 Feb 2018 02:25:14 +0000 Subject: Merit radb https interface, TLS1.0 only? In-Reply-To: References: Message-ID: <8147048735a84f87bba19b450ec078ce@ansencorp.com> I'd hope that it's not supposed to be that way, but I'm seeing the same thing with chrome on win10 and firefox on debian 9, so it's not just you. -Ed -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Kuhnke Sent: Friday, February 2, 2018 9:16 PM To: nanog at nanog.org list Subject: Merit radb https interface, TLS1.0 only? >Is the radb login page supposed to be TLS1.0 only? From andy at mbrez.com Sat Feb 3 02:33:41 2018 From: andy at mbrez.com (Andy Brezinsky) Date: Fri, 2 Feb 2018 20:33:41 -0600 Subject: Merit radb https interface, TLS1.0 only? In-Reply-To: References: Message-ID: <11374df8-f3c6-ce76-4657-6f8cefc56167@mbrez.com> It's not just you: https://www.ssllabs.com/ssltest/analyze.html?d=radb.net&s=207.75.117.71 On 02/02/2018 08:15 PM, Eric Kuhnke wrote: > Is the radb login page supposed to be TLS1.0 only? > > This is with the latest version of Firefox. > > Screenshot: https://imgur.com/nnlFmLZ > > I also noticed that the registration page is plain http/non TLS. > > for reference: > https://www.google.com/search?client=ubuntu&channel=fs&q=tls+1.0+deprecated&ie=utf-8&oe=utf-8 From surfer at mauigateway.com Sat Feb 3 21:49:57 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Sat, 3 Feb 2018 13:49:57 -0800 Subject: improving signal to noise ratio from centralized network syslogs Message-ID: <20180203134957.FEADA1D@m0117460.ppops.net> --- jmaimon at jmaimon.com wrote: Centralized logging is a good thing. However, what happens is that every repetitive, annoying but not (usually) important thing fills up the log with reams of what you are not looking for. --------------------------------------- Apologies, I'm late to the party. But I just want to add one thing for the archives. It's along with what Rich Kulawiec said, "it forces you to look at your own data, which is really helpful. You'll be surprised at what you find if you've never done it before." This is accurate. It's fun to see what your network is putting out. This is all from memory (I've done it so many times it's in there permanently... :-) as I don't have a unix server or a router in front of me to use, so don't hold me to exact details... And it's mainly for the newbies. Have all the routers send to one syslog file, switches to another and other devices to a third on a *nix box: For example, send the router messages to /var/log/router.log and the switch messages to /var/log/switch.log This is done with the 'logging facility' command on the devices: After defining your syslog server's IP address and the level of messaging you want (I set it to debug because I want to see everything): on the routers: logging facility local0 on the switches: logging facility local1 on the logging server in: /etc/rsyslog.conf local0.* /var/log/router.log local1.* /var/log/switch.log Use logrotate to manage the log files as they can get quite large. Then, you can watch your network in real time like so (below is all one line): tail -f /var/log/router.log /var/log/switch.log | egrep -vi 'term1|term2|termN' 'egrep -v' takes out all the lines you don't want to see while the syslog messages scroll across the screen. Say there is a battery condition on router1 and a duplex mismatch on a switch I don't want to see: tail -f /var/log/router.log /var/log/switch.log | egrep -vi 'router1.*battery|switch1.*duplex.*mismatch' For me, N can get to 40-50 sometimes, so I put it into a shell script like so: vi log.sh --------------------------- #! /bin/sh tail -f /var/log/router.log /var/log/switch.log | egrep -v 'term1|term2|termN' --------------------------- then, run it like so: ./log.sh It's all netgeek fun-n-games from there on. :) scott From tarko at lanparty.ee Sun Feb 4 08:21:13 2018 From: tarko at lanparty.ee (Tarko Tikan) Date: Sun, 4 Feb 2018 10:21:13 +0200 Subject: improving signal to noise ratio from centralized network syslogs In-Reply-To: <20180203134957.FEADA1D@m0117460.ppops.net> References: <20180203134957.FEADA1D@m0117460.ppops.net> Message-ID: hey, > This is done with the 'logging facility' > command on the devices: > > After defining your syslog server's IP > address and the level of messaging you want > (I set it to debug because I want to see > everything): > > on the routers: logging facility local0 > on the switches: logging facility local1 Alternative, and more universal, way to do it is to use multiple IPs for syslog server. Then configure correct syslog server IP on the device. syslog-ng and others can all do filtering to different destinations based on the IP where message was received. -- tarko From cheetahmorph at gmail.com Sun Feb 4 09:07:45 2018 From: cheetahmorph at gmail.com (Jippen) Date: Sun, 4 Feb 2018 01:07:45 -0800 Subject: improving signal to noise ratio from centralized network syslogs In-Reply-To: References: <20180203134957.FEADA1D@m0117460.ppops.net> Message-ID: I really recommend setting up fluentd, and then routing logging from there - it makes it very easy to keep auditor-appeasing logs, while also having important stuff sending pages. Log aggregation, organization, and search is a hard problem, other people have already done it and provided it as a service, and chances are its NOT a core competency or secret sauce at your organization. Once you get your logs in one routing system, you can do a lot with them, but stop rolling your own. This is a prime area for most companies to buy something that works better, for less than the cost of developing in house. And if you run your own aggregation layer - then you can easily try out a bunch of different systems and add/remove them easily. :) Also, you may want to see one level of logs, but your auditors might wanna see another, and your engineers/sec team might wanna do some analytics on them. Being able to provide a solution for everyone who needs network logs at whatever detail level they ask for will make you popular at your organization. On Sun, Feb 4, 2018 at 12:21 AM, Tarko Tikan wrote: > hey, > > This is done with the 'logging facility' >> command on the devices: >> >> After defining your syslog server's IP >> address and the level of messaging you want >> (I set it to debug because I want to see >> everything): >> >> on the routers: logging facility local0 >> on the switches: logging facility local1 >> > > Alternative, and more universal, way to do it is to use multiple IPs for > syslog server. Then configure correct syslog server IP on the device. > > syslog-ng and others can all do filtering to different destinations based > on the IP where message was received. > > -- > tarko > From shane at short.id.au Mon Feb 5 02:25:36 2018 From: shane at short.id.au (Shane Short) Date: Mon, 5 Feb 2018 10:25:36 +0800 Subject: improving signal to noise ratio from centralized network syslogs In-Reply-To: <20180203134957.FEADA1D@m0117460.ppops.net> References: <20180203134957.FEADA1D@m0117460.ppops.net> Message-ID: In addition to that, you can use some fancy awk colour coding, so you can make it highlight certain lines based on content.. I use this for my e-mail logs, but I’m sure it could be adapted: tail -n 1000 -f /var/log/mail-submission.log | grep smtp.*relay | awk ' /sent/ {print "\033[32m" $0 "\033[39m"} /bounced/ {print "\033[31m" $0 "\033[39m"} /deferred/ {print "\033[33m" $0 "\033[39m"} ' > On 4 Feb 2018, at 5:49 am, Scott Weeks wrote: > > > --- jmaimon at jmaimon.com wrote: > Centralized logging is a good thing. However, > what happens is that every repetitive, annoying > but not (usually) important thing fills up the > log with reams of what you are not looking for. > --------------------------------------- > > Apologies, I'm late to the party. But I just > want to add one thing for the archives. It's > along with what Rich Kulawiec said, "it forces > you to look at your own data, which is really > helpful. You'll be surprised at what you find > if you've never done it before." This is > accurate. It's fun to see what your network > is putting out. > > This is all from memory (I've done it so many > times it's in there permanently... :-) as I > don't have a unix server or a router in front > of me to use, so don't hold me to exact > details... > > And it's mainly for the newbies. > > Have all the routers send to one syslog file, > switches to another and other devices to a > third on a *nix box: For example, send the > router messages to /var/log/router.log and > the switch messages to /var/log/switch.log > This is done with the 'logging facility' > command on the devices: > > After defining your syslog server's IP > address and the level of messaging you want > (I set it to debug because I want to see > everything): > > on the routers: logging facility local0 > on the switches: logging facility local1 > > on the logging server in: /etc/rsyslog.conf > local0.* /var/log/router.log > local1.* /var/log/switch.log > > Use logrotate to manage the log files as they > can get quite large. > > Then, you can watch your network in real time > like so (below is all one line): > > tail -f /var/log/router.log /var/log/switch.log > | egrep -vi 'term1|term2|termN' > > 'egrep -v' takes out all the lines you don't > want to see while the syslog messages scroll > across the screen. > > Say there is a battery condition on router1 > and a duplex mismatch on a switch I don't want > to see: > > tail -f /var/log/router.log /var/log/switch.log > | egrep -vi 'router1.*battery|switch1.*duplex.*mismatch' > > For me, N can get to 40-50 sometimes, so I put > it into a shell script like so: > > vi log.sh > > --------------------------- > #! /bin/sh > > tail -f /var/log/router.log /var/log/switch.log > | egrep -v 'term1|term2|termN' > --------------------------- > > then, run it like so: ./log.sh > > It's all netgeek fun-n-games from there on. :) > > scott From baldur.norddahl at gmail.com Mon Feb 5 15:57:14 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 5 Feb 2018 16:57:14 +0100 Subject: 40G reforming Message-ID: <31e7c223-f69a-1dda-8b9b-2c38176b1128@gmail.com> Hello Is it possible to reform a 40G signal as individual 10G links? The idea is to use a 40G QSFP multimode MTP module such as https://www.fs.com/products/44058.html. Then connect it using a MTP breakout cable such as https://www.fs.com/products/68049.html to get four dual fiber connectors. These are then connected to four 10G SFP+ multimode modules such as https://www.fs.com/products/11589.html. The reformer could be https://www.fs.com/products/43721.html. And finally the reformed signal can be transported using anything including DWDM modules such as https://www.fs.com/products/44058.html. Just using fs.com as a reference to the kind of equipment I am talking about. Many other vendors offer simelar products. The motivation for doing this is to get access to the many options that are available for 10G optics but not possible with 40G. Regards, Baldur From jeremyparr at gmail.com Mon Feb 5 17:28:16 2018 From: jeremyparr at gmail.com (Jeremy Parr) Date: Mon, 5 Feb 2018 12:28:16 -0500 Subject: Akamai caches hammering Sophos XG firewalls Message-ID: Somewhat OT, but before I was a jack of all trades enterprise sysadmin, I was a jack of all trades ISP sysadmin. I'm seeing an issue at a few sites where I have Sophos XG firewalls deployed where the XG gets hammered on it's WAN interface by Akamai hosts with TCP re-transmissions. Anyone at Akamai who may have some background on this issue please reach out to me. The hosts currently in question are 24.244.145.137 and 24.244.145.139, but I suspect that is only due to these being closest to me, colocated at my ISP AS15146. From surfer at mauigateway.com Mon Feb 5 18:49:42 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 5 Feb 2018 10:49:42 -0800 Subject: improving signal to noise ratio from centralized network syslogs Message-ID: <20180205104942.FEA275A@m0117460.ppops.net> --- tarko at lanparty.ee wrote: > This is done with the 'logging facility' > command on the devices: > > After defining your syslog server's IP > address and the level of messaging you want > (I set it to debug because I want to see > everything): > > on the routers: logging facility local0 > on the switches: logging facility local1 Alternative, and more universal, way to do it is to use multiple IPs for syslog server. Then configure correct syslog server IP on the device. syslog-ng and others can all do filtering to different destinations based on the IP where message was received. ------------------------------------------------ The nice thing about the simple way is you see everything that's happening on the network, except what you 'egrep -v' out, which you already know about. Then you find things you weren't expecting. You don't go looking for stuff. You just watch the network events scroll by in real time ans see what shows up. I have no knowledge of syslog-ng. Does it do the real time scrolling like I mention? scott From surfer at mauigateway.com Mon Feb 5 18:55:27 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 5 Feb 2018 10:55:27 -0800 Subject: improving signal to noise ratio from centralized network syslogs Message-ID: <20180205105527.FEA27D1@m0117460.ppops.net> --- shane at short.id.au wrote: In addition to that, you can use some fancy awk colour coding, so you can make it highlight certain lines based on content.. I use this for my e-mail logs, but I’m sure it could be adapted: tail -n 1000 -f /var/log/mail-submission.log | grep smtp.*relay | awk ' /sent/ {print "\033[32m" $0 "\033[39m"} /bounced/ {print "\033[31m" $0 "\033[39m"} /deferred/ {print "\033[33m" $0 "\033[39m"} ---------------------------------------------------- The main thing for me is to find things that your network is doing that you weren't aware of. Not normal things you want to see that a monitoring system will alert you about. scott From valdis.kletnieks at vt.edu Mon Feb 5 18:57:45 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 05 Feb 2018 13:57:45 -0500 Subject: improving signal to noise ratio from centralized network syslogs In-Reply-To: <20180205104942.FEA275A@m0117460.ppops.net> References: <20180205104942.FEA275A@m0117460.ppops.net> Message-ID: <25768.1517857065@turing-police.cc.vt.edu> On Mon, 05 Feb 2018 10:49:42 -0800, "Scott Weeks" said: > I have no knowledge of syslog-ng. Does it do the > real time scrolling like I mention? Use 'tail -f' or similar. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From niels=nanog at bakker.net Mon Feb 5 18:59:36 2018 From: niels=nanog at bakker.net (Niels Bakker) Date: Mon, 5 Feb 2018 19:59:36 +0100 Subject: Akamai caches hammering Sophos XG firewalls In-Reply-To: References: Message-ID: <20180205185936.GA30812@excession.tpb.net> * jeremyparr at gmail.com (Jeremy Parr) [Mon 05 Feb 2018, 18:28 CET]: >Somewhat OT, but before I was a jack of all trades enterprise >sysadmin, I was a jack of all trades ISP sysadmin. > >I'm seeing an issue at a few sites where I have Sophos XG firewalls >deployed where the XG gets hammered on it's WAN interface by Akamai >hosts with TCP re-transmissions. Anyone at Akamai who may have some >background on this issue please reach out to me. The hosts currently >in question are 24.244.145.137 and 24.244.145.139, but I suspect >that is only due to these being closest to me, colocated at my ISP >AS15146. Chances are your firewall cannot keep enough state in memory and starts complaining about packets because it's missing sessions. -- Niels. From baldur.norddahl at gmail.com Mon Feb 5 19:03:33 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 5 Feb 2018 20:03:33 +0100 Subject: 40G reforming In-Reply-To: References: <31e7c223-f69a-1dda-8b9b-2c38176b1128@gmail.com> Message-ID: I may need to clarify that I do not want to break the port into 4x10G as such. To the switch this will be an ordinary 40G link to another switch far away. I want to take advantage of the fact that 40G is transported as four individual streams. Each of the four streams are to be converted from 850 nm to a 1550 DWDM channel (one channel per stream). And the reverse at the other end of the link. The point of doing this is that 40G DWDM modules are not generally available and neither are 80 km modules. I need a true 40G channel so 4x10G LACP is not an option here. For the same reason I am unable to accept a solution that splits the 40G port into 4x10G and then perhaps recombines using LACP. Instead I am looking at an optical solution that is invisible to the switch hardware. The only doubt I have about the proposed solution is whether the frame format of the 10G substreams is somehow incompatible with what goes on in the reformer. As I understand these reformers they are little more than two SFP(+) modules connected back to back. And therefore it should not matter that the frame format may be different. Regards Baldur Den 5. feb. 2018 7.20 PM skrev "Paul Zugnoni" : Whether a 40G port can be broken into 4x10G is dependent on the router/switch hardware and the optic you use. Good news is that most 40G ports are capable of being broken out into 4x10G, since a 40G port is usually operating as 4x10G internally anyway to the ASIC. The QSFP you'll need would be a 40G-SR4 for MTP/Multimode or 40G-LR4 for MTP/Singlemode (or a lower power, less expensive equivalent). This is a pretty common use of 40G ports. All 4 10G ports would then be at 850nm or 1310nm, which you can then plug into any 10G SR or LR ports. What router or switch platform is driving the 40G? Paul Z On Mon, Feb 5, 2018 at 7:57 AM, Baldur Norddahl wrote: > Hello > > Is it possible to reform a 40G signal as individual 10G links? > > The idea is to use a 40G QSFP multimode MTP module such as > https://www.fs.com/products/44058.html. Then connect it using a MTP > breakout cable such as https://www.fs.com/products/68049.html to get four > dual fiber connectors. These are then connected to four 10G SFP+ multimode > modules such as https://www.fs.com/products/11589.html. The reformer > could be https://www.fs.com/products/43721.html. And finally the reformed > signal can be transported using anything including DWDM modules such as > https://www.fs.com/products/44058.html. > > Just using fs.com as a reference to the kind of equipment I am talking > about. Many other vendors offer simelar products. > > The motivation for doing this is to get access to the many options that > are available for 10G optics but not possible with 40G. > > Regards, > > Baldur > > From sryan at arbor.net Sun Feb 4 20:00:20 2018 From: sryan at arbor.net (Ryan, Spencer) Date: Sun, 4 Feb 2018 20:00:20 +0000 Subject: RADB - aut-num policy question Message-ID: Hello all, I'm a bit out of my element on this one and hoping someone can help. I'm putting together an aut-num entry for RADB and have a question about our Comcast peerings. We peer with AS7922 in several sites, but if you look at the actual pathing via bgp.he.net or just the routes themselves you can see that the first AS in the path after ours is either 7015 or 33668 depending on region for the paths that prefer comcast's network. For the import/export policy can I just reference 7922 or do I also need to include the others? Thanks in advance! Spencer Ryan | Senior Systems Administrator | sryan at arbor.net Arbor Networks | The security division of NETSCOUT +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com From sryan at arbor.net Mon Feb 5 16:22:50 2018 From: sryan at arbor.net (Ryan, Spencer) Date: Mon, 5 Feb 2018 16:22:50 +0000 Subject: 40G reforming In-Reply-To: <31e7c223-f69a-1dda-8b9b-2c38176b1128@gmail.com> References: <31e7c223-f69a-1dda-8b9b-2c38176b1128@gmail.com> Message-ID: 40G is either 4 x 10G over a single pair, or broken out into 8 fibers in the short or parallel versions. Almost all Ethernet platforms support running most or all of their 40G ports as 1 x 40 or 4 x 10. When using the breakout cables though your options are usually more limited. A 1U switch as a 4 x SFP+ to 1 x QSFP(28) converter will work, depending on your use case. Spencer Ryan | Senior Systems Administrator | sryan at arbor.net Arbor Networks | The security division of NETSCOUT +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Baldur Norddahl Sent: Monday, February 5, 2018 10:57 AM To: nanog at nanog.org Subject: 40G reforming Hello Is it possible to reform a 40G signal as individual 10G links? The idea is to use a 40G QSFP multimode MTP module such as https://urldefense.proofpoint.com/v2/url?u=https-3A__www.fs.com_products_44058.html&d=DwICaQ&c=Hlvprqonr5LuCN9TN65xNw&r=Iw8ah1pcqZhOErIjaFRfuA&m=6Ncau5mGbJHTsn49WZBhiGcOVEmu482YmvfcECst4Mw&s=n2mTvNLQoiqsoG6Xi1BrMs_SjV3eJO4k15Bo0EUujAg&e=. Then connect it using a MTP breakout cable such as https://urldefense.proofpoint.com/v2/url?u=https-3A__www.fs.com_products_68049.html&d=DwICaQ&c=Hlvprqonr5LuCN9TN65xNw&r=Iw8ah1pcqZhOErIjaFRfuA&m=6Ncau5mGbJHTsn49WZBhiGcOVEmu482YmvfcECst4Mw&s=QQafQeEfacv-FvVFG7i3lwVhi_0mf3k9if5ROFPqpF0&e= to get four dual fiber connectors. These are then connected to four 10G SFP+ multimode modules such as https://urldefense.proofpoint.com/v2/url?u=https-3A__www.fs.com_products_11589.html&d=DwICaQ&c=Hlvprqonr5LuCN9TN65xNw&r=Iw8ah1pcqZhOErIjaFRfuA&m=6Ncau5mGbJHTsn49WZBhiGcOVEmu482YmvfcECst4Mw&s=kHc5CkRMpHo-GOihA9giouVj-Ua8mfpDWy8-PFEoi7U&e=. The reformer could be https://urldefense.proofpoint.com/v2/url?u=https-3A__www.fs.com_products_43721.html&d=DwICaQ&c=Hlvprqonr5LuCN9TN65xNw&r=Iw8ah1pcqZhOErIjaFRfuA&m=6Ncau5mGbJHTsn49WZBhiGcOVEmu482YmvfcECst4Mw&s=1ZjK8WS9SvmkSJZuO3ONs20yRL2BLAJTfdYxi-SCu9A&e=. And finally the reformed signal can be transported using anything including DWDM modules such as https://urldefense.proofpoint.com/v2/url?u=https-3A__www.fs.com_products_44058.html&d=DwICaQ&c=Hlvprqonr5LuCN9TN65xNw&r=Iw8ah1pcqZhOErIjaFRfuA&m=6Ncau5mGbJHTsn49WZBhiGcOVEmu482YmvfcECst4Mw&s=n2mTvNLQoiqsoG6Xi1BrMs_SjV3eJO4k15Bo0EUujAg&e=. Just using fs.com as a reference to the kind of equipment I am talking about. Many other vendors offer simelar products. The motivation for doing this is to get access to the many options that are available for 10G optics but not possible with 40G. Regards, Baldur From tarko at lanparty.ee Mon Feb 5 19:22:14 2018 From: tarko at lanparty.ee (Tarko Tikan) Date: Mon, 5 Feb 2018 21:22:14 +0200 Subject: 40G reforming In-Reply-To: References: <31e7c223-f69a-1dda-8b9b-2c38176b1128@gmail.com> Message-ID: <620ed342-dff7-2391-975b-f4e6ff838b72@lanparty.ee> hey, > I want to take advantage of the fact that 40G is transported as four > individual streams. Each of the four streams are to be converted from 850 > nm to a 1550 DWDM channel (one channel per stream). And the reverse at the > other end of the link. You probably want something similar to: http://www.10gtek.com/qsfp-extender -- tarko From pz at wish.com Mon Feb 5 18:20:24 2018 From: pz at wish.com (Paul Zugnoni) Date: Mon, 5 Feb 2018 10:20:24 -0800 Subject: 40G reforming In-Reply-To: <31e7c223-f69a-1dda-8b9b-2c38176b1128@gmail.com> References: <31e7c223-f69a-1dda-8b9b-2c38176b1128@gmail.com> Message-ID: Whether a 40G port can be broken into 4x10G is dependent on the router/switch hardware and the optic you use. Good news is that most 40G ports are capable of being broken out into 4x10G, since a 40G port is usually operating as 4x10G internally anyway to the ASIC. The QSFP you'll need would be a 40G-SR4 for MTP/Multimode or 40G-LR4 for MTP/Singlemode (or a lower power, less expensive equivalent). This is a pretty common use of 40G ports. All 4 10G ports would then be at 850nm or 1310nm, which you can then plug into any 10G SR or LR ports. What router or switch platform is driving the 40G? Paul Z On Mon, Feb 5, 2018 at 7:57 AM, Baldur Norddahl wrote: > Hello > > Is it possible to reform a 40G signal as individual 10G links? > > The idea is to use a 40G QSFP multimode MTP module such as > https://www.fs.com/products/44058.html. Then connect it using a MTP > breakout cable such as https://www.fs.com/products/68049.html to get four > dual fiber connectors. These are then connected to four 10G SFP+ multimode > modules such as https://www.fs.com/products/11589.html. The reformer > could be https://www.fs.com/products/43721.html. And finally the reformed > signal can be transported using anything including DWDM modules such as > https://www.fs.com/products/44058.html. > > Just using fs.com as a reference to the kind of equipment I am talking > about. Many other vendors offer simelar products. > > The motivation for doing this is to get access to the many options that > are available for 10G optics but not possible with 40G. > > Regards, > > Baldur > > From md at bts.sk Mon Feb 5 19:32:42 2018 From: md at bts.sk (=?UTF-8?Q?Marian_=C4=8Eurkovi=C4=8D?=) Date: Mon, 5 Feb 2018 20:32:42 +0100 Subject: 40G reforming In-Reply-To: References: <31e7c223-f69a-1dda-8b9b-2c38176b1128@gmail.com> Message-ID: <20180205192505.M23178@bts.sk> Many switches based on BCM Trident ASIC allow you to configure 4 consecutive SFP+ ports as 40G link (not LACP, but using real hardware 40G framing). In such case, you can plug 4 DWDM SFP+ modules directly into the switch, without the need for any reformer. M. On Mon, 5 Feb 2018 20:03:33 +0100, Baldur Norddahl wrote > I may need to clarify that I do not want to break the port into 4x10G > as such. To the switch this will be an ordinary 40G link to another > switch far away. > > I want to take advantage of the fact that 40G is transported as four > individual streams. Each of the four streams are to be converted from 850 > nm to a 1550 DWDM channel (one channel per stream). And the reverse at > the other end of the link. > > The point of doing this is that 40G DWDM modules are not generally > available and neither are 80 km modules. > > I need a true 40G channel so 4x10G LACP is not an option here. For the > same reason I am unable to accept a solution that splits the 40G port > into 4x10G and then perhaps recombines using LACP. Instead I am > looking at an optical solution that is invisible to the switch hardware. > > The only doubt I have about the proposed solution is whether the frame > format of the 10G substreams is somehow incompatible with what goes on > in the reformer. As I understand these reformers they are little more > than two SFP(+) modules connected back to back. And therefore it > should not matter that the frame format may be different. > > Regards > > Baldur > > Den 5. feb. 2018 7.20 PM skrev "Paul Zugnoni" : > > Whether a 40G port can be broken into 4x10G is dependent on the > router/switch hardware and the optic you use. Good news is that most > 40G ports are capable of being broken out into 4x10G, since a 40G port > is usually operating as 4x10G internally anyway to the ASIC. The QSFP you'll > need would be a 40G-SR4 for MTP/Multimode or 40G-LR4 for > MTP/Singlemode (or a lower power, less expensive equivalent). This is > a pretty common use of 40G ports. All 4 10G ports would then be at > 850nm or 1310nm, which you can then plug into any 10G SR or LR ports. > > What router or switch platform is driving the 40G? > > Paul Z > > On Mon, Feb 5, 2018 at 7:57 AM, Baldur Norddahl > wrote: > > > Hello > > > > Is it possible to reform a 40G signal as individual 10G links? > > > > The idea is to use a 40G QSFP multimode MTP module such as > > https://www.fs.com/products/44058.html. Then connect it using a MTP > > breakout cable such as https://www.fs.com/products/68049.html to get four > > dual fiber connectors. These are then connected to four 10G SFP+ multimode > > modules such as https://www.fs.com/products/11589.html. The reformer > > could be https://www.fs.com/products/43721.html. And finally the reformed > > signal can be transported using anything including DWDM modules such as > > https://www.fs.com/products/44058.html. > > > > Just using fs.com as a reference to the kind of equipment I am talking > > about. Many other vendors offer simelar products. > > > > The motivation for doing this is to get access to the many options that > > are available for 10G optics but not possible with 40G. > > > > Regards, > > > > Baldur > > > > From sryan at arbor.net Mon Feb 5 19:33:38 2018 From: sryan at arbor.net (Ryan, Spencer) Date: Mon, 5 Feb 2018 19:33:38 +0000 Subject: 40G reforming In-Reply-To: <20180205192505.M23178@bts.sk> References: <31e7c223-f69a-1dda-8b9b-2c38176b1128@gmail.com> <20180205192505.M23178@bts.sk> Message-ID: Indeed. Arista does (did?) make at least one platform where you can do this. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Marian Durkovic Sent: Monday, February 5, 2018 2:33 PM To: Baldur Norddahl Cc: nanog at nanog.org Subject: Re: 40G reforming Many switches based on BCM Trident ASIC allow you to configure 4 consecutive SFP+ ports as 40G link (not LACP, but using real hardware 40G framing). In such case, you can plug 4 DWDM SFP+ modules directly into the switch, without the need for any reformer. M. On Mon, 5 Feb 2018 20:03:33 +0100, Baldur Norddahl wrote > I may need to clarify that I do not want to break the port into 4x10G > as such. To the switch this will be an ordinary 40G link to another > switch far away. > > I want to take advantage of the fact that 40G is transported as four > individual streams. Each of the four streams are to be converted from > 850 nm to a 1550 DWDM channel (one channel per stream). And the > reverse at the other end of the link. > > The point of doing this is that 40G DWDM modules are not generally > available and neither are 80 km modules. > > I need a true 40G channel so 4x10G LACP is not an option here. For the > same reason I am unable to accept a solution that splits the 40G port > into 4x10G and then perhaps recombines using LACP. Instead I am > looking at an optical solution that is invisible to the switch hardware. > > The only doubt I have about the proposed solution is whether the frame > format of the 10G substreams is somehow incompatible with what goes on > in the reformer. As I understand these reformers they are little more > than two SFP(+) modules connected back to back. And therefore it > should not matter that the frame format may be different. > > Regards > > Baldur > > Den 5. feb. 2018 7.20 PM skrev "Paul Zugnoni" : > > Whether a 40G port can be broken into 4x10G is dependent on the > router/switch hardware and the optic you use. Good news is that most > 40G ports are capable of being broken out into 4x10G, since a 40G port > is usually operating as 4x10G internally anyway to the ASIC. The QSFP > you'll need would be a 40G-SR4 for MTP/Multimode or 40G-LR4 for > MTP/Singlemode (or a lower power, less expensive equivalent). This is > a pretty common use of 40G ports. All 4 10G ports would then be at > 850nm or 1310nm, which you can then plug into any 10G SR or LR ports. > > What router or switch platform is driving the 40G? > > Paul Z > > On Mon, Feb 5, 2018 at 7:57 AM, Baldur Norddahl > > wrote: > > > Hello > > > > Is it possible to reform a 40G signal as individual 10G links? > > > > The idea is to use a 40G QSFP multimode MTP module such as > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.fs.com_prod > > ucts_44058.html&d=DwIDaQ&c=Hlvprqonr5LuCN9TN65xNw&r=Iw8ah1pcqZhOErIj > > aFRfuA&m=wWoshgttJT0E6q6-qJzP_ZcIrEz_EP88taPCbvAiK2Y&s=_rJfOmyDlGmPG > > C6M5FbhQ1V8_mho1OCpkcuYRNlaOvA&e=. Then connect it using a MTP > > breakout cable such as > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.fs.com_prod > > ucts_68049.html&d=DwIDaQ&c=Hlvprqonr5LuCN9TN65xNw&r=Iw8ah1pcqZhOErIjaFRfuA&m=wWoshgttJT0E6q6-qJzP_ZcIrEz_EP88taPCbvAiK2Y&s=Cz0mCyM3dtcHoZ7lGy7uyroI_Y7AwmKXdnYNFIF0rPI&e= to get four dual fiber connectors. These are then connected to four 10G SFP+ multimode modules such as https://urldefense.proofpoint.com/v2/url?u=https-3A__www.fs.com_products_11589.html&d=DwIDaQ&c=Hlvprqonr5LuCN9TN65xNw&r=Iw8ah1pcqZhOErIjaFRfuA&m=wWoshgttJT0E6q6-qJzP_ZcIrEz_EP88taPCbvAiK2Y&s=l-9OAiUxeydRJCJc7d1kTKPVSkwQlkV4xkZFlbFxyRs&e=. The reformer could be https://urldefense.proofpoint.com/v2/url?u=https-3A__www.fs.com_products_43721.html&d=DwIDaQ&c=Hlvprqonr5LuCN9TN65xNw&r=Iw8ah1pcqZhOErIjaFRfuA&m=wWoshgttJT0E6q6-qJzP_ZcIrEz_EP88taPCbvAiK2Y&s=NwCHiC_boNNs7zCOgJFRZ5nmZOVEPBovGYNTtdQ_pCE&e=. And finally the reformed signal can be transported using anything including DWDM modules such as https://urldefense.proofpoint.com/v2/url?u=https-3A__www.fs.com_products_44058.html&d=DwIDaQ&c=Hlvprqonr5LuCN9TN65xNw&r=Iw8ah1pcqZhOErIjaFRfuA&m=wWoshgttJT0E6q6-qJzP_ZcIrEz_EP88taPCbvAiK2Y&s=_rJfOmyDlGmPGC6M5FbhQ1V8_mho1OCpkcuYRNlaOvA&e=. > > > > Just using fs.com as a reference to the kind of equipment I am > > talking about. Many other vendors offer simelar products. > > > > The motivation for doing this is to get access to the many options > > that are available for 10G optics but not possible with 40G. > > > > Regards, > > > > Baldur > > > > From hf0002+nanog at uah.edu Mon Feb 5 19:56:53 2018 From: hf0002+nanog at uah.edu (Hunter Fuller) Date: Mon, 05 Feb 2018 19:56:53 +0000 Subject: 40G reforming In-Reply-To: References: <31e7c223-f69a-1dda-8b9b-2c38176b1128@gmail.com> <20180205192505.M23178@bts.sk> Message-ID: I suspect that implies that you can just take a 40Gbase-SR4 module and break it out into individual "10G" multi-mode pairs for DWDM use. Has anyone tried this? I'm also very interested in using that strategy. On Mon, Feb 5, 2018 at 1:36 PM Ryan, Spencer wrote: > Indeed. Arista does (did?) make at least one platform where you can do > this. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Marian Durkovic > Sent: Monday, February 5, 2018 2:33 PM > To: Baldur Norddahl > Cc: nanog at nanog.org > Subject: Re: 40G reforming > > Many switches based on BCM Trident ASIC allow you to configure 4 > consecutive > SFP+ ports as 40G link (not LACP, but using real hardware 40G framing). > In such case, you can plug 4 DWDM SFP+ modules directly into the switch, > without the need for any reformer. > > M. > > On Mon, 5 Feb 2018 20:03:33 +0100, Baldur Norddahl wrote > > I may need to clarify that I do not want to break the port into 4x10G > > as such. To the switch this will be an ordinary 40G link to another > > switch far away. > > > > I want to take advantage of the fact that 40G is transported as four > > individual streams. Each of the four streams are to be converted from > > 850 nm to a 1550 DWDM channel (one channel per stream). And the > > reverse at the other end of the link. > > > > The point of doing this is that 40G DWDM modules are not generally > > available and neither are 80 km modules. > > > > I need a true 40G channel so 4x10G LACP is not an option here. For the > > same reason I am unable to accept a solution that splits the 40G port > > into 4x10G and then perhaps recombines using LACP. Instead I am > > looking at an optical solution that is invisible to the switch hardware. > > > > The only doubt I have about the proposed solution is whether the frame > > format of the 10G substreams is somehow incompatible with what goes on > > in the reformer. As I understand these reformers they are little more > > than two SFP(+) modules connected back to back. And therefore it > > should not matter that the frame format may be different. > > > > Regards > > > > Baldur > > > > Den 5. feb. 2018 7.20 PM skrev "Paul Zugnoni" : > > > > Whether a 40G port can be broken into 4x10G is dependent on the > > router/switch hardware and the optic you use. Good news is that most > > 40G ports are capable of being broken out into 4x10G, since a 40G port > > is usually operating as 4x10G internally anyway to the ASIC. The QSFP > > you'll need would be a 40G-SR4 for MTP/Multimode or 40G-LR4 for > > MTP/Singlemode (or a lower power, less expensive equivalent). This is > > a pretty common use of 40G ports. All 4 10G ports would then be at > > 850nm or 1310nm, which you can then plug into any 10G SR or LR ports. > > > > What router or switch platform is driving the 40G? > > > > Paul Z > > > > On Mon, Feb 5, 2018 at 7:57 AM, Baldur Norddahl > > > > wrote: > > > > > Hello > > > > > > Is it possible to reform a 40G signal as individual 10G links? > > > > > > The idea is to use a 40G QSFP multimode MTP module such as > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.fs.com_prod > > > ucts_44058.html&d=DwIDaQ&c=Hlvprqonr5LuCN9TN65xNw&r=Iw8ah1pcqZhOErIj > > > aFRfuA&m=wWoshgttJT0E6q6-qJzP_ZcIrEz_EP88taPCbvAiK2Y&s=_rJfOmyDlGmPG > > > C6M5FbhQ1V8_mho1OCpkcuYRNlaOvA&e=. Then connect it using a MTP > > > breakout cable such as > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.fs.com_prod > > > > ucts_68049.html&d=DwIDaQ&c=Hlvprqonr5LuCN9TN65xNw&r=Iw8ah1pcqZhOErIjaFRfuA&m=wWoshgttJT0E6q6-qJzP_ZcIrEz_EP88taPCbvAiK2Y&s=Cz0mCyM3dtcHoZ7lGy7uyroI_Y7AwmKXdnYNFIF0rPI&e= > to get four dual fiber connectors. These are then connected to four 10G > SFP+ multimode modules such as > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.fs.com_products_11589.html&d=DwIDaQ&c=Hlvprqonr5LuCN9TN65xNw&r=Iw8ah1pcqZhOErIjaFRfuA&m=wWoshgttJT0E6q6-qJzP_ZcIrEz_EP88taPCbvAiK2Y&s=l-9OAiUxeydRJCJc7d1kTKPVSkwQlkV4xkZFlbFxyRs&e=. > The reformer could be > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.fs.com_products_43721.html&d=DwIDaQ&c=Hlvprqonr5LuCN9TN65xNw&r=Iw8ah1pcqZhOErIjaFRfuA&m=wWoshgttJT0E6q6-qJzP_ZcIrEz_EP88taPCbvAiK2Y&s=NwCHiC_boNNs7zCOgJFRZ5nmZOVEPBovGYNTtdQ_pCE&e=. > And finally the reformed signal can be transported using anything including > DWDM modules such as > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.fs.com_products_44058.html&d=DwIDaQ&c=Hlvprqonr5LuCN9TN65xNw&r=Iw8ah1pcqZhOErIjaFRfuA&m=wWoshgttJT0E6q6-qJzP_ZcIrEz_EP88taPCbvAiK2Y&s=_rJfOmyDlGmPGC6M5FbhQ1V8_mho1OCpkcuYRNlaOvA&e= > . > > > > > > Just using fs.com as a reference to the kind of equipment I am > > > talking about. Many other vendors offer simelar products. > > > > > > The motivation for doing this is to get access to the many options > > > that are available for 10G optics but not possible with 40G. > > > > > > Regards, > > > > > > Baldur > > > > > > > > -- -- Hunter Fuller Network Engineer VBH Annex B-5 +1 256 824 5331 Office of Information Technology The University of Alabama in Huntsville Systems and Infrastructure From jwbensley at gmail.com Mon Feb 5 20:27:13 2018 From: jwbensley at gmail.com (James Bensley) Date: Mon, 5 Feb 2018 20:27:13 +0000 Subject: improving signal to noise ratio from centralized network syslogs In-Reply-To: <25768.1517857065@turing-police.cc.vt.edu> References: <20180205104942.FEA275A@m0117460.ppops.net> <25768.1517857065@turing-police.cc.vt.edu> Message-ID: On 5 February 2018 at 18:57, wrote: > On Mon, 05 Feb 2018 10:49:42 -0800, "Scott Weeks" said: >> I have no knowledge of syslog-ng. Does it do the >> real time scrolling like I mention? > > Use 'tail -f' or similar. The only problem is that with BASH based solutions is that they are slow. They don't scale well. Some years ago I wrote a script that would periodically (every 5 minutes by default) grep for interesting events / filter uninteresting events from the syslog file and email you the results. It's here if anyone is interested: https://null.53bits.co.uk/index.php?page=sysgrep It's OK for a small network or small number of devices but it doesn't scale well. Having said that, it's better than nothing and costs $0 (which exactly why I used it in the first place). Cheers, James. From valdis.kletnieks at vt.edu Mon Feb 5 21:57:39 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 05 Feb 2018 16:57:39 -0500 Subject: improving signal to noise ratio from centralized network syslogs In-Reply-To: References: <20180205104942.FEA275A@m0117460.ppops.net> <25768.1517857065@turing-police.cc.vt.edu> Message-ID: <44499.1517867859@turing-police.cc.vt.edu> On Mon, 05 Feb 2018 20:27:13 +0000, James Bensley said: > On 5 February 2018 at 18:57, wrote: > > On Mon, 05 Feb 2018 10:49:42 -0800, "Scott Weeks" said: > >> I have no knowledge of syslog-ng. Does it do the > >> real time scrolling like I mention? > > > > Use 'tail -f' or similar. > > The only problem is that with BASH based solutions is that they are > slow. They don't scale well. The basic point was that you need to supply your own solution for monitoring syslog-ng logs, be it tail or logwatch or whatever - it doesn't come with its own. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From ml at knight-networks.com Mon Feb 5 23:43:02 2018 From: ml at knight-networks.com (Brian Knight) Date: Mon, 05 Feb 2018 17:43:02 -0600 Subject: improving signal to noise ratio from centralized network syslogs In-Reply-To: <20180203134957.FEADA1D@m0117460.ppops.net> References: <20180203134957.FEADA1D@m0117460.ppops.net> Message-ID: On 2018-02-03 15:49, Scott Weeks wrote: > Then, you can watch your network in real time > like so (below is all one line): > > tail -f /var/log/router.log /var/log/switch.log > | egrep -vi 'term1|term2|termN' > > 'egrep -v' takes out all the lines you don't > want to see while the syslog messages scroll > across the screen. Syslog-ng can do regex filtering on messages also. So instead of doing an 'egrep -v' on a huge file after it has been logged, you can put your filter right into the syslog-ng configuration, and have those filtered messages output to a file (or any other output that syslog-ng supports). The result is a smaller file to search and work with. We implemented a simple email alerter using this functionality. In syslog-ng, we set up two filters. One filter does the 'egrep -v': filter f_email_msg { not message("%PKT_INFRA-LINEPROTO-.*[0-9/]+\\.") # filter out subinterface up/downs and not message("%PKT_INFRA-LINEPROTO-.*Multilink") and not message("%PKT_INFRA-LINEPROTO-.*Serial") and not message("%PKT_INFRA-LINEPROTO-.*Tunnel") # etc }; Another filter applied to the messages filters messages to just our core devices: filter f_email_sources { host("192.0.2.1") or host("192.0.2.2") or host("192.0.2.3") or host("192.0.2.4") or host("192.0.2.5") or host("192.0.2.6") }; Then those are tied together in a syslog-ng rule that outputs to a file: destination d_email_log { file("/var/log/syslog-ng/alert/alerts.log" template("$HOST:$MSG\n") create_dirs(yes) ); }; log { source(s_devices); filter(f_email_sources); filter(f_email_msg); destination(d_email_log); }; A lightweight Python script that runs as a daemon checks that file once every 10 seconds, and if the file length is non-zero, it sends the contents of the file in an email to the admins. A shell script run as a cron job would work equally as well. (Also, for emailed syslogs, there is more incentive for the admin to keep her or his message filter up to date, as opposed to a file the administrator must manually examine. Otherwise the admin has a full inbox :) ) It's very simple and stable, and has worked better than the commercial product we used to use for this purpose. -Brian From sryan at arbor.net Tue Feb 6 01:57:05 2018 From: sryan at arbor.net (Ryan, Spencer) Date: Tue, 6 Feb 2018 01:57:05 +0000 Subject: 40G reforming In-Reply-To: References: <31e7c223-f69a-1dda-8b9b-2c38176b1128@gmail.com> <20180205192505.M23178@bts.sk> Message-ID: You don’t use 40G modules at all. Just 4 x 10G SFP+. The Broadcom trident chip is configured at the MAC layer for 40G, so it’s identical to a real 40G port inside. Some more reading: https://www.arista.com/assets/data/pdf/Whitepapers/AgilePorts_over_DWDM_Final.pdf Spencer Ryan | Senior Systems Administrator | sryan at arbor.net Arbor Networks | The security division of NETSCOUT +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com From: Hunter Fuller [mailto:hf0002+nanog at uah.edu] Sent: Monday, February 5, 2018 2:57 PM To: Ryan, Spencer Cc: Marian Ďurkovič ; Baldur Norddahl ; nanog at nanog.org Subject: Re: 40G reforming I suspect that implies that you can just take a 40Gbase-SR4 module and break it out into individual "10G" multi-mode pairs for DWDM use. Has anyone tried this? I'm also very interested in using that strategy. On Mon, Feb 5, 2018 at 1:36 PM Ryan, Spencer > wrote: Indeed. Arista does (did?) make at least one platform where you can do this. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Marian Durkovic Sent: Monday, February 5, 2018 2:33 PM To: Baldur Norddahl > Cc: nanog at nanog.org Subject: Re: 40G reforming Many switches based on BCM Trident ASIC allow you to configure 4 consecutive SFP+ ports as 40G link (not LACP, but using real hardware 40G framing). In such case, you can plug 4 DWDM SFP+ modules directly into the switch, without the need for any reformer. M. On Mon, 5 Feb 2018 20:03:33 +0100, Baldur Norddahl wrote > I may need to clarify that I do not want to break the port into 4x10G > as such. To the switch this will be an ordinary 40G link to another > switch far away. > > I want to take advantage of the fact that 40G is transported as four > individual streams. Each of the four streams are to be converted from > 850 nm to a 1550 DWDM channel (one channel per stream). And the > reverse at the other end of the link. > > The point of doing this is that 40G DWDM modules are not generally > available and neither are 80 km modules. > > I need a true 40G channel so 4x10G LACP is not an option here. For the > same reason I am unable to accept a solution that splits the 40G port > into 4x10G and then perhaps recombines using LACP. Instead I am > looking at an optical solution that is invisible to the switch hardware. > > The only doubt I have about the proposed solution is whether the frame > format of the 10G substreams is somehow incompatible with what goes on > in the reformer. As I understand these reformers they are little more > than two SFP(+) modules connected back to back. And therefore it > should not matter that the frame format may be different. > > Regards > > Baldur > > Den 5. feb. 2018 7.20 PM skrev "Paul Zugnoni" >: > > Whether a 40G port can be broken into 4x10G is dependent on the > router/switch hardware and the optic you use. Good news is that most > 40G ports are capable of being broken out into 4x10G, since a 40G port > is usually operating as 4x10G internally anyway to the ASIC. The QSFP > you'll need would be a 40G-SR4 for MTP/Multimode or 40G-LR4 for > MTP/Singlemode (or a lower power, less expensive equivalent). This is > a pretty common use of 40G ports. All 4 10G ports would then be at > 850nm or 1310nm, which you can then plug into any 10G SR or LR ports. > > What router or switch platform is driving the 40G? > > Paul Z > > On Mon, Feb 5, 2018 at 7:57 AM, Baldur Norddahl > > > wrote: > > > Hello > > > > Is it possible to reform a 40G signal as individual 10G links? > > > > The idea is to use a 40G QSFP multimode MTP module such as > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.fs.com_prod > > ucts_44058.html&d=DwIDaQ&c=Hlvprqonr5LuCN9TN65xNw&r=Iw8ah1pcqZhOErIj > > aFRfuA&m=wWoshgttJT0E6q6-qJzP_ZcIrEz_EP88taPCbvAiK2Y&s=_rJfOmyDlGmPG > > C6M5FbhQ1V8_mho1OCpkcuYRNlaOvA&e=. Then connect it using a MTP > > breakout cable such as > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.fs.com_prod > > ucts_68049.html&d=DwIDaQ&c=Hlvprqonr5LuCN9TN65xNw&r=Iw8ah1pcqZhOErIjaFRfuA&m=wWoshgttJT0E6q6-qJzP_ZcIrEz_EP88taPCbvAiK2Y&s=Cz0mCyM3dtcHoZ7lGy7uyroI_Y7AwmKXdnYNFIF0rPI&e= to get four dual fiber connectors. These are then connected to four 10G SFP+ multimode modules such as https://urldefense.proofpoint.com/v2/url?u=https-3A__www.fs.com_products_11589.html&d=DwIDaQ&c=Hlvprqonr5LuCN9TN65xNw&r=Iw8ah1pcqZhOErIjaFRfuA&m=wWoshgttJT0E6q6-qJzP_ZcIrEz_EP88taPCbvAiK2Y&s=l-9OAiUxeydRJCJc7d1kTKPVSkwQlkV4xkZFlbFxyRs&e=. The reformer could be https://urldefense.proofpoint.com/v2/url?u=https-3A__www.fs.com_products_43721.html&d=DwIDaQ&c=Hlvprqonr5LuCN9TN65xNw&r=Iw8ah1pcqZhOErIjaFRfuA&m=wWoshgttJT0E6q6-qJzP_ZcIrEz_EP88taPCbvAiK2Y&s=NwCHiC_boNNs7zCOgJFRZ5nmZOVEPBovGYNTtdQ_pCE&e=. And finally the reformed signal can be transported using anything including DWDM modules such as https://urldefense.proofpoint.com/v2/url?u=https-3A__www.fs.com_products_44058.html&d=DwIDaQ&c=Hlvprqonr5LuCN9TN65xNw&r=Iw8ah1pcqZhOErIjaFRfuA&m=wWoshgttJT0E6q6-qJzP_ZcIrEz_EP88taPCbvAiK2Y&s=_rJfOmyDlGmPGC6M5FbhQ1V8_mho1OCpkcuYRNlaOvA&e=. > > > > Just using fs.com as a reference to the kind of equipment I am > > talking about. Many other vendors offer simelar products. > > > > The motivation for doing this is to get access to the many options > > that are available for 10G optics but not possible with 40G. > > > > Regards, > > > > Baldur > > > > -- -- Hunter Fuller Network Engineer VBH Annex B-5 +1 256 824 5331 Office of Information Technology The University of Alabama in Huntsville Systems and Infrastructure From jackson.tim at gmail.com Tue Feb 6 02:11:14 2018 From: jackson.tim at gmail.com (Tim Jackson) Date: Mon, 5 Feb 2018 20:11:14 -0600 Subject: 40G reforming In-Reply-To: References: <31e7c223-f69a-1dda-8b9b-2c38176b1128@gmail.com> <20180205192505.M23178@bts.sk> Message-ID: I'm pretty sure that this is only available on 7150S which is FM6000, not broadcom at all. On Feb 5, 2018 8:00 PM, "Ryan, Spencer" wrote: You don’t use 40G modules at all. Just 4 x 10G SFP+. The Broadcom trident chip is configured at the MAC layer for 40G, so it’s identical to a real 40G port inside. Some more reading: https://www.arista.com/assets/data/pdf/Whitepapers/ AgilePorts_over_DWDM_Final.pdf Spencer Ryan | Senior Systems Administrator | sryan at arbor.net Arbor Networks | The security division of NETSCOUT +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com From: Hunter Fuller [mailto:hf0002+nanog at uah.edu] Sent: Monday, February 5, 2018 2:57 PM To: Ryan, Spencer Cc: Marian Ďurkovič ; Baldur Norddahl ; nanog at nanog.org Subject: Re: 40G reforming I suspect that implies that you can just take a 40Gbase-SR4 module and break it out into individual "10G" multi-mode pairs for DWDM use. Has anyone tried this? I'm also very interested in using that strategy. On Mon, Feb 5, 2018 at 1:36 PM Ryan, Spencer > wrote: Indeed. Arista does (did?) make at least one platform where you can do this. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Marian Durkovic Sent: Monday, February 5, 2018 2:33 PM To: Baldur Norddahl > Cc: nanog at nanog.org Subject: Re: 40G reforming Many switches based on BCM Trident ASIC allow you to configure 4 consecutive SFP+ ports as 40G link (not LACP, but using real hardware 40G framing). In such case, you can plug 4 DWDM SFP+ modules directly into the switch, without the need for any reformer. M. On Mon, 5 Feb 2018 20:03:33 +0100, Baldur Norddahl wrote > I may need to clarify that I do not want to break the port into 4x10G > as such. To the switch this will be an ordinary 40G link to another > switch far away. > > I want to take advantage of the fact that 40G is transported as four > individual streams. Each of the four streams are to be converted from > 850 nm to a 1550 DWDM channel (one channel per stream). And the > reverse at the other end of the link. > > The point of doing this is that 40G DWDM modules are not generally > available and neither are 80 km modules. > > I need a true 40G channel so 4x10G LACP is not an option here. For the > same reason I am unable to accept a solution that splits the 40G port > into 4x10G and then perhaps recombines using LACP. Instead I am > looking at an optical solution that is invisible to the switch hardware. > > The only doubt I have about the proposed solution is whether the frame > format of the 10G substreams is somehow incompatible with what goes on > in the reformer. As I understand these reformers they are little more > than two SFP(+) modules connected back to back. And therefore it > should not matter that the frame format may be different. > > Regards > > Baldur > > Den 5. feb. 2018 7.20 PM skrev "Paul Zugnoni" >: > > Whether a 40G port can be broken into 4x10G is dependent on the > router/switch hardware and the optic you use. Good news is that most > 40G ports are capable of being broken out into 4x10G, since a 40G port > is usually operating as 4x10G internally anyway to the ASIC. The QSFP > you'll need would be a 40G-SR4 for MTP/Multimode or 40G-LR4 for > MTP/Singlemode (or a lower power, less expensive equivalent). This is > a pretty common use of 40G ports. All 4 10G ports would then be at > 850nm or 1310nm, which you can then plug into any 10G SR or LR ports. > > What router or switch platform is driving the 40G? > > Paul Z > > On Mon, Feb 5, 2018 at 7:57 AM, Baldur Norddahl > > > wrote: > > > Hello > > > > Is it possible to reform a 40G signal as individual 10G links? > > > > The idea is to use a 40G QSFP multimode MTP module such as > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.fs.com_prod > > ucts_44058.html&d=DwIDaQ&c=Hlvprqonr5LuCN9TN65xNw&r=Iw8ah1pcqZhOErIj > > aFRfuA&m=wWoshgttJT0E6q6-qJzP_ZcIrEz_EP88taPCbvAiK2Y&s=_rJfOmyDlGmPG > > C6M5FbhQ1V8_mho1OCpkcuYRNlaOvA&e=. Then connect it using a MTP > > breakout cable such as > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.fs.com_prod > > ucts_68049.html&d=DwIDaQ&c=Hlvprqonr5LuCN9TN65xNw&r= Iw8ah1pcqZhOErIjaFRfuA&m=wWoshgttJT0E6q6-qJzP_ZcIrEz_EP88taPCbvAiK2Y&s= Cz0mCyM3dtcHoZ7lGy7uyroI_Y7AwmKXdnYNFIF0rPI&e= to get four dual fiber connectors. These are then connected to four 10G SFP+ multimode modules such as https://urldefense.proofpoint.com/v2/url?u=https-3A__www.fs. com_products_11589.html&d=DwIDaQ&c=Hlvprqonr5LuCN9TN65xNw&r= Iw8ah1pcqZhOErIjaFRfuA&m=wWoshgttJT0E6q6-qJzP_ZcIrEz_EP88taPCbvAiK2Y&s=l- 9OAiUxeydRJCJc7d1kTKPVSkwQlkV4xkZFlbFxyRs&e=. The reformer could be https://urldefense.proofpoint.com/v2/url?u=https-3A__www.fs. com_products_43721.html&d=DwIDaQ&c=Hlvprqonr5LuCN9TN65xNw&r= Iw8ah1pcqZhOErIjaFRfuA&m=wWoshgttJT0E6q6-qJzP_ZcIrEz_ EP88taPCbvAiK2Y&s=NwCHiC_boNNs7zCOgJFRZ5nmZOVEPBovGYNTtdQ_pCE&e=. And finally the reformed signal can be transported using anything including DWDM modules such as https://urldefense.proofpoint. com/v2/url?u=https-3A__www.fs.com_products_44058.html&d=DwIDaQ&c= Hlvprqonr5LuCN9TN65xNw&r=Iw8ah1pcqZhOErIjaFRfuA&m= wWoshgttJT0E6q6-qJzP_ZcIrEz_EP88taPCbvAiK2Y&s=_rJfOmyDlGmPGC6M5FbhQ1V8_ mho1OCpkcuYRNlaOvA&e=. > > > > Just using fs.com as a reference to the kind of equipment I am > > talking about. Many other vendors offer simelar products. > > > > The motivation for doing this is to get access to the many options > > that are available for 10G optics but not possible with 40G. > > > > Regards, > > > > Baldur > > > > -- -- Hunter Fuller Network Engineer VBH Annex B-5 +1 256 824 5331 Office of Information Technology The University of Alabama in Huntsville Systems and Infrastructure From sryan at arbor.net Tue Feb 6 04:59:45 2018 From: sryan at arbor.net (Ryan, Spencer) Date: Tue, 6 Feb 2018 04:59:45 +0000 Subject: 40G reforming In-Reply-To: References: <31e7c223-f69a-1dda-8b9b-2c38176b1128@gmail.com> <20180205192505.M23178@bts.sk> Message-ID: Looks like you’re right. Too many 7xxx model numbers. Either way, same result. The MAC layer in the switch treats it like a QSFP port would be. From: Tim Jackson [mailto:jackson.tim at gmail.com] Sent: Monday, February 5, 2018 9:11 PM To: Ryan, Spencer Cc: Hunter Fuller ; nanog list Subject: RE: 40G reforming I'm pretty sure that this is only available on 7150S which is FM6000, not broadcom at all. On Feb 5, 2018 8:00 PM, "Ryan, Spencer" > wrote: You don’t use 40G modules at all. Just 4 x 10G SFP+. The Broadcom trident chip is configured at the MAC layer for 40G, so it’s identical to a real 40G port inside. Some more reading: https://www.arista.com/assets/data/pdf/Whitepapers/AgilePorts_over_DWDM_Final.pdf Spencer Ryan | Senior Systems Administrator | sryan at arbor.net> Arbor Networks | The security division of NETSCOUT +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com From: Hunter Fuller [mailto:hf0002+nanog at uah.edu] Sent: Monday, February 5, 2018 2:57 PM To: Ryan, Spencer > Cc: Marian Ďurkovič >; Baldur Norddahl >; nanog at nanog.org Subject: Re: 40G reforming I suspect that implies that you can just take a 40Gbase-SR4 module and break it out into individual "10G" multi-mode pairs for DWDM use. Has anyone tried this? I'm also very interested in using that strategy. On Mon, Feb 5, 2018 at 1:36 PM Ryan, Spencer >> wrote: Indeed. Arista does (did?) make at least one platform where you can do this. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org>] On Behalf Of Marian Durkovic Sent: Monday, February 5, 2018 2:33 PM To: Baldur Norddahl >> Cc: nanog at nanog.org> Subject: Re: 40G reforming Many switches based on BCM Trident ASIC allow you to configure 4 consecutive SFP+ ports as 40G link (not LACP, but using real hardware 40G framing). In such case, you can plug 4 DWDM SFP+ modules directly into the switch, without the need for any reformer. M. On Mon, 5 Feb 2018 20:03:33 +0100, Baldur Norddahl wrote > I may need to clarify that I do not want to break the port into 4x10G > as such. To the switch this will be an ordinary 40G link to another > switch far away. > > I want to take advantage of the fact that 40G is transported as four > individual streams. Each of the four streams are to be converted from > 850 nm to a 1550 DWDM channel (one channel per stream). And the > reverse at the other end of the link. > > The point of doing this is that 40G DWDM modules are not generally > available and neither are 80 km modules. > > I need a true 40G channel so 4x10G LACP is not an option here. For the > same reason I am unable to accept a solution that splits the 40G port > into 4x10G and then perhaps recombines using LACP. Instead I am > looking at an optical solution that is invisible to the switch hardware. > > The only doubt I have about the proposed solution is whether the frame > format of the 10G substreams is somehow incompatible with what goes on > in the reformer. As I understand these reformers they are little more > than two SFP(+) modules connected back to back. And therefore it > should not matter that the frame format may be different. > > Regards > > Baldur > > Den 5. feb. 2018 7.20 PM skrev "Paul Zugnoni" >>: > > Whether a 40G port can be broken into 4x10G is dependent on the > router/switch hardware and the optic you use. Good news is that most > 40G ports are capable of being broken out into 4x10G, since a 40G port > is usually operating as 4x10G internally anyway to the ASIC. The QSFP > you'll need would be a 40G-SR4 for MTP/Multimode or 40G-LR4 for > MTP/Singlemode (or a lower power, less expensive equivalent). This is > a pretty common use of 40G ports. All 4 10G ports would then be at > 850nm or 1310nm, which you can then plug into any 10G SR or LR ports. > > What router or switch platform is driving the 40G? > > Paul Z > > On Mon, Feb 5, 2018 at 7:57 AM, Baldur Norddahl > >> > wrote: > > > Hello > > > > Is it possible to reform a 40G signal as individual 10G links? > > > > The idea is to use a 40G QSFP multimode MTP module such as > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.fs.com_prod > > ucts_44058.html&d=DwIDaQ&c=Hlvprqonr5LuCN9TN65xNw&r=Iw8ah1pcqZhOErIj > > aFRfuA&m=wWoshgttJT0E6q6-qJzP_ZcIrEz_EP88taPCbvAiK2Y&s=_rJfOmyDlGmPG > > C6M5FbhQ1V8_mho1OCpkcuYRNlaOvA&e=. Then connect it using a MTP > > breakout cable such as > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.fs.com_prod > > ucts_68049.html&d=DwIDaQ&c=Hlvprqonr5LuCN9TN65xNw&r=Iw8ah1pcqZhOErIjaFRfuA&m=wWoshgttJT0E6q6-qJzP_ZcIrEz_EP88taPCbvAiK2Y&s=Cz0mCyM3dtcHoZ7lGy7uyroI_Y7AwmKXdnYNFIF0rPI&e= to get four dual fiber connectors. These are then connected to four 10G SFP+ multimode modules such as https://urldefense.proofpoint.com/v2/url?u=https-3A__www.fs.com_products_11589.html&d=DwIDaQ&c=Hlvprqonr5LuCN9TN65xNw&r=Iw8ah1pcqZhOErIjaFRfuA&m=wWoshgttJT0E6q6-qJzP_ZcIrEz_EP88taPCbvAiK2Y&s=l-9OAiUxeydRJCJc7d1kTKPVSkwQlkV4xkZFlbFxyRs&e=. The reformer could be https://urldefense.proofpoint.com/v2/url?u=https-3A__www.fs.com_products_43721.html&d=DwIDaQ&c=Hlvprqonr5LuCN9TN65xNw&r=Iw8ah1pcqZhOErIjaFRfuA&m=wWoshgttJT0E6q6-qJzP_ZcIrEz_EP88taPCbvAiK2Y&s=NwCHiC_boNNs7zCOgJFRZ5nmZOVEPBovGYNTtdQ_pCE&e=. And finally the reformed signal can be transported using anything including DWDM modules such as https://urldefense.proofpoint.com/v2/url?u=https-3A__www.fs.com_products_44058.html&d=DwIDaQ&c=Hlvprqonr5LuCN9TN65xNw&r=Iw8ah1pcqZhOErIjaFRfuA&m=wWoshgttJT0E6q6-qJzP_ZcIrEz_EP88taPCbvAiK2Y&s=_rJfOmyDlGmPGC6M5FbhQ1V8_mho1OCpkcuYRNlaOvA&e=. > > > > Just using fs.com as a reference to the kind of equipment I am > > talking about. Many other vendors offer simelar products. > > > > The motivation for doing this is to get access to the many options > > that are available for 10G optics but not possible with 40G. > > > > Regards, > > > > Baldur > > > > -- -- Hunter Fuller Network Engineer VBH Annex B-5 +1 256 824 5331 Office of Information Technology The University of Alabama in Huntsville Systems and Infrastructure From john.kougoulos at gmail.com Tue Feb 6 12:03:45 2018 From: john.kougoulos at gmail.com (John Kougoulos) Date: Tue, 6 Feb 2018 13:03:45 +0100 Subject: improving signal to noise ratio from centralized network syslogs In-Reply-To: References: <20180205104942.FEA275A@m0117460.ppops.net> <25768.1517857065@turing-police.cc.vt.edu> Message-ID: On Mon, Feb 5, 2018 at 9:27 PM, James Bensley wrote: > On 5 February 2018 at 18:57, wrote: > > On Mon, 05 Feb 2018 10:49:42 -0800, "Scott Weeks" said: > >> I have no knowledge of syslog-ng. Does it do the > >> real time scrolling like I mention? > > > > Use 'tail -f' or similar. > > The only problem is that with BASH based solutions is that they are > slow. They don't scale well. > > Some years ago I wrote a script that would periodically (every 5 > minutes by default) grep for interesting events / filter uninteresting > events from the syslog file and email you the results. It's here if > anyone is interested: https://null.53bits.co.uk/index.php?page=sysgrep > > > Last year I found the time to code something similar in perl using File::Tail , here is the outcome in case anyone is interested: https://github.com/jkougoulos/9to5tail Regards, John From ekim9190 at gmail.com Tue Feb 6 14:34:07 2018 From: ekim9190 at gmail.com (Michael Starr) Date: Tue, 6 Feb 2018 09:34:07 -0500 Subject: Console Servers & Cellular Providers Message-ID: Hello NANOGers, I am wondering if people still use console servers with cellular service as a disaster out-of-band management solution in your data centers? If not, what are the alternatives? If so, are there any recommendations for pay-as-you-go cellular service? Apologies if this is too trivial a question for this group. Thanks for your time, Mike From lathama at gmail.com Tue Feb 6 18:59:54 2018 From: lathama at gmail.com (Andrew Latham) Date: Tue, 6 Feb 2018 12:59:54 -0600 Subject: Console Servers & Cellular Providers In-Reply-To: References: Message-ID: Almost exactly a year ago https://mailman.nanog.org/pipermail/nanog/2017-February/090293.html On Tue, Feb 6, 2018 at 8:34 AM, Michael Starr wrote: > Hello NANOGers, > > > > I am wondering if people still use console servers with cellular service as > a disaster out-of-band management solution in your data centers? If not, > what are the alternatives? If so, are there any recommendations for > pay-as-you-go cellular service? Apologies if this is too trivial a question > for this group. > > > > Thanks for your time, > > Mike > -- - Andrew "lathama" Latham - From faisal at snappytelecom.net Tue Feb 6 19:07:13 2018 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Tue, 6 Feb 2018 19:07:13 +0000 (GMT) Subject: Embratel / Claro AS4230 Message-ID: <1469523987.3778714.1517944033536.JavaMail.zimbra@snappytelecom.net> Hello All, Looking for a Technical Contact / IP NOC Engineer for EmbraTel/Claro AS4230 ? We are seeing some of the routes we are announcing not showing up in there route tables. (170.80.188.0/24 and 170.80.190.0/24 and 170.80.191.0/24) Off list contact will be great. Thanks Faisal Imtiaz Snappy Internet & Telecom http://www.snappytelecom.net Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net From ekim9190 at gmail.com Tue Feb 6 19:16:36 2018 From: ekim9190 at gmail.com (Michael Starr) Date: Tue, 6 Feb 2018 14:16:36 -0500 Subject: Console Servers & Cellular Providers In-Reply-To: References: Message-ID: <83FE13BE-F345-44CD-916D-82640A87C095@gmail.com> Good call out — I didn’t put enough effort into searching previous conversations. > On Feb 6, 2018, at 1:59 PM, Andrew Latham wrote: > > Almost exactly a year ago https://mailman.nanog.org/pipermail/nanog/2017-February/090293.html > > > >> On Tue, Feb 6, 2018 at 8:34 AM, Michael Starr wrote: >> Hello NANOGers, >> >> >> >> I am wondering if people still use console servers with cellular service as >> a disaster out-of-band management solution in your data centers? If not, >> what are the alternatives? If so, are there any recommendations for >> pay-as-you-go cellular service? Apologies if this is too trivial a question >> for this group. >> >> >> >> Thanks for your time, >> >> Mike > > > > -- > - Andrew "lathama" Latham - From rod.beck at unitedcablecompany.com Tue Feb 6 20:40:37 2018 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Tue, 6 Feb 2018 20:40:37 +0000 Subject: Dark Fiber Providers - Domestic Message-ID: Who regulates and licenses dark fiber providers? Or does no one? Roderick Beck Director of Global Sales United Cable Company www.unitedcablecompany.com New York City & Budapest rod.beck at unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png] From bill at herrin.us Tue Feb 6 20:56:14 2018 From: bill at herrin.us (William Herrin) Date: Tue, 6 Feb 2018 15:56:14 -0500 Subject: Dark Fiber Providers - Domestic In-Reply-To: References: Message-ID: On Tue, Feb 6, 2018 at 3:40 PM, Rod Beck wrote: > Who regulates and licenses dark fiber providers? Or does no one? Hi Rod, When they use public rights of way (alongside roads for example), dark fiber providers are regulated by the state corporation commission or public utilities commission of each state in which they operate. When they use only private rights of way (e.g. railroad tracks) they are generally unregulated. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From lathama at gmail.com Tue Feb 6 21:09:43 2018 From: lathama at gmail.com (Andrew Latham) Date: Tue, 6 Feb 2018 15:09:43 -0600 Subject: Dark Fiber Providers - Domestic In-Reply-To: References: Message-ID: Slight note that some states separate mineral rights under railroads. Example https://www.prnewswire.com/news-releases/current-and-former-owners-of-land-next-to-or-under-railroad-rights-of-way-may-be-eligible-for-cash-payments-from-a-class-action-settlement-166270626.html where the URL sums it up. On Tue, Feb 6, 2018 at 2:56 PM, William Herrin wrote: > On Tue, Feb 6, 2018 at 3:40 PM, Rod Beck > wrote: > > Who regulates and licenses dark fiber providers? Or does no one? > > Hi Rod, > > When they use public rights of way (alongside roads for example), dark > fiber providers are regulated by the state corporation commission or > public utilities commission of each state in which they operate. > > When they use only private rights of way (e.g. railroad tracks) they > are generally unregulated. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > -- - Andrew "lathama" Latham - From ben at adversary.org Wed Feb 7 02:23:26 2018 From: ben at adversary.org (Ben McGinnes) Date: Wed, 7 Feb 2018 13:23:26 +1100 Subject: Contact at archive.org Message-ID: <20180207022326.mwdp32igw2op74er@adversary.org> Hello, If there's anyone involved with archive.org's systems team lurking around here, I'd appreciate being contacted off list. Regards, Ben -- | GPG Made Easy (GPGME) Python 3 API Maintainer, GNU Privacy Guard | | GPG key: 0x321E4E2373590E5D http://www.adversary.org/ben-key.asc | | GPG key fpr: DB47 24E6 FA42 86C9 2B4E 55C4 321E 4E23 7359 0E5D | | https://www.gnupg.org/ https://securetheinternet.org/ | -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From ben at adversary.org Wed Feb 7 14:18:51 2018 From: ben at adversary.org (Ben McGinnes) Date: Thu, 8 Feb 2018 01:18:51 +1100 Subject: Contact at archive.org In-Reply-To: <20180207022326.mwdp32igw2op74er@adversary.org> References: <20180207022326.mwdp32igw2op74er@adversary.org> Message-ID: <20180207141851.l3j6lpvzmvsrjco4@adversary.org> On Wed, Feb 07, 2018 at 01:23:26PM +1100, Ben McGinnes wrote: > Hello, > If there's anyone involved with archive.org's systems team > lurking around here, I'd appreciate being contacted off list. I knew there was a reason I stayed on this list even after departing the ISP, hosting and domain registration space and this, right here, is it. Thanks one and all for demonstrating real networking, in all senses of the term. Regards, Ben P.S. To my fellow GPG users: Don't worry about the revelation that there's a GPG dev in such a cryptographically ignorant (not to mention mathematics denying) and rights eroded country as Australia. I deliberately stay away from the libgcrypt component of GPG for all the reasons that might come to mind (and maybe one or two others). There's plenty else to work on anyway. ;) -- | Ben McGinnes | Adversarial Press | Author and Publisher | | Writer, Trainer, Systems Administrator, Developer, ICT Consultant | | Twitter: @benmcginnes (personal) | @AdversaryPub (publishing) | | Web: http://www.adversary.org/ http://publishing.adversary.org/ | | ----------------------------------------------------------------- | | GPG Made Easy (GPGME) Python 3 API Maintainer, GNU Privacy Guard | | GPG key: 0x321E4E2373590E5D http://www.adversary.org/ben-key.asc | | GPG key fpr: DB47 24E6 FA42 86C9 2B4E 55C4 321E 4E23 7359 0E5D | | https://www.gnupg.org/ https://securetheinternet.org/ | | ----------------------------------------------------------------- | | This message may be delayed by failures of the Australian NBN. | | ----------------------------------------------------------------- | -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From jcutts at line2.com Tue Feb 6 20:26:38 2018 From: jcutts at line2.com (James Cutts) Date: Tue, 6 Feb 2018 12:26:38 -0800 Subject: Console Servers & Cellular Providers In-Reply-To: <83FE13BE-F345-44CD-916D-82640A87C095@gmail.com> References: <83FE13BE-F345-44CD-916D-82640A87C095@gmail.com> Message-ID: Michael, Let me know what you end up doing. This is definitely something I've considred for our DC On Tue, Feb 6, 2018 at 11:16 AM, Michael Starr wrote: > Good call out — I didn’t put enough effort into searching previous > conversations. > > > > > On Feb 6, 2018, at 1:59 PM, Andrew Latham wrote: > > > > Almost exactly a year ago https://mailman.nanog.org/ > pipermail/nanog/2017-February/090293.html > > > > historical notes first.> > > > >> On Tue, Feb 6, 2018 at 8:34 AM, Michael Starr > wrote: > >> Hello NANOGers, > >> > >> > >> > >> I am wondering if people still use console servers with cellular > service as > >> a disaster out-of-band management solution in your data centers? If not, > >> what are the alternatives? If so, are there any recommendations for > >> pay-as-you-go cellular service? Apologies if this is too trivial a > question > >> for this group. > >> > >> > >> > >> Thanks for your time, > >> > >> Mike > > > > > > > > -- > > - Andrew "lathama" Latham - > -- *James Cutts* Line2 | Director of Operations | (415) 223-5822 | Text Me Do business on a second line. iOS® , Android™ , Mac OS® , and *Windows® * From rcarpen at network1.net Wed Feb 7 16:27:55 2018 From: rcarpen at network1.net (Randy Carpenter) Date: Wed, 7 Feb 2018 11:27:55 -0500 (EST) Subject: Console Servers & Cellular Providers In-Reply-To: References: Message-ID: <579459199.18549.1518020875960.JavaMail.zimbra@network1.net> We use the Oopengear ACM and IM series and they are great. My only current issue is that Verizon does not allow for static IPv4 and IPv6 simultaneously. You can have one or the other, but not both. *facepalm* One major point of advice with the Opengear: make sure the firmware is up to date. There have been some issues with cellular stability in some releases. thanks, -Randy ----- On Feb 6, 2018, at 9:34 AM, Michael Starr ekim9190 at gmail.com wrote: > Hello NANOGers, > > > > I am wondering if people still use console servers with cellular service as > a disaster out-of-band management solution in your data centers? If not, > what are the alternatives? If so, are there any recommendations for > pay-as-you-go cellular service? Apologies if this is too trivial a question > for this group. > > > > Thanks for your time, > > Mike From jmilko at gmail.com Wed Feb 7 16:38:15 2018 From: jmilko at gmail.com (James Milko) Date: Wed, 7 Feb 2018 11:38:15 -0500 Subject: Console Servers & Cellular Providers In-Reply-To: <579459199.18549.1518020875960.JavaMail.zimbra@network1.net> References: <579459199.18549.1518020875960.JavaMail.zimbra@network1.net> Message-ID: How is cell reception in multi-story data centers/carrier hotels? Good enough for remote management? JM From scott.pennington at cinbell.com Wed Feb 7 16:46:49 2018 From: scott.pennington at cinbell.com (Pennington, Scott) Date: Wed, 7 Feb 2018 16:46:49 +0000 Subject: Console Servers & Cellular Providers In-Reply-To: References: <579459199.18549.1518020875960.JavaMail.zimbra@network1.net>, Message-ID: My $dayJob experience with cell to console in the larger locations has been poor, verging on unacceptable. ________________________________ From: NANOG on behalf of James Milko Sent: Wednesday, February 7, 2018 11:38 AM To: Randy Carpenter Cc: Michael Starr; nanog Subject: Re: Console Servers & Cellular Providers How is cell reception in multi-story data centers/carrier hotels? Good enough for remote management? JM From dhubbard at dino.hostasaurus.com Wed Feb 7 16:46:48 2018 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 7 Feb 2018 16:46:48 +0000 Subject: Console Servers & Cellular Providers In-Reply-To: References: <579459199.18549.1518020875960.JavaMail.zimbra@network1.net> Message-ID: Going to depend entirely on the data center. I've got OpenGear boxes deployed in a variety of places, using Verizon LTE with static IP. One Level 3 colo I'm in I had to buy a high gain directional antenna to get the signal strength up above -80, where below that you're lucky to get a reasonable SSH experience, but then I'm in a Switch colo in Vegas that has dramatically more customers and equipment, and I get almost double that signal strength, inside a rack, inside a metal heat chamber, with the built-in antennas. Just depends on the structure and proximity to a tower I'm guessing. On 2/7/18, 11:39 AM, "NANOG on behalf of James Milko" wrote: How is cell reception in multi-story data centers/carrier hotels? Good enough for remote management? JM From EPers at ansencorp.com Wed Feb 7 17:04:41 2018 From: EPers at ansencorp.com (Edwin Pers) Date: Wed, 7 Feb 2018 17:04:41 +0000 Subject: Console Servers & Cellular Providers In-Reply-To: References: <579459199.18549.1518020875960.JavaMail.zimbra@network1.net> Message-ID: <275fb3de7eea42069cac4bf4a1150f30@ansencorp.com> Pretty bad bordering on unusable most of the time (steel and concrete buildings after all). I'm only setup in buildings we own, so I've been able to put antennas up on the roof for this. At our more remote sites where there's no cell service at all I have POTS lines. KVMoIP is a bit painful at 56k, but it's usable. Ed -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of James Milko Sent: Wednesday, February 7, 2018 11:38 AM To: Randy Carpenter Cc: Michael Starr ; nanog Subject: Re: Console Servers & Cellular Providers How is cell reception in multi-story data centers/carrier hotels? Good enough for remote management? JM From kenneth.mcrae at me.com Wed Feb 7 17:24:32 2018 From: kenneth.mcrae at me.com (Kenneth McRae) Date: Wed, 07 Feb 2018 09:24:32 -0800 Subject: Console Servers & Cellular Providers In-Reply-To: References: Message-ID: <0B9478CB-F434-4474-878B-2DCBB5E71CC6@me.com> Yes. I use Opengear with great success. I use Verizon, T-Mobile & AT&T prepaid service depending on the area. When integrated with Opengear Lighthouse, the console server is fully manageable via cellular service. Kenneth > On Feb 6, 2018, at 6:34 AM, Michael Starr wrote: > > Hello NANOGers, > > > > I am wondering if people still use console servers with cellular service as > a disaster out-of-band management solution in your data centers? If not, > what are the alternatives? If so, are there any recommendations for > pay-as-you-go cellular service? Apologies if this is too trivial a question > for this group. > > > > Thanks for your time, > > Mike From jamann at mt.gov Wed Feb 7 17:28:40 2018 From: jamann at mt.gov (Mann, Jason) Date: Wed, 7 Feb 2018 17:28:40 +0000 Subject: Console Servers & Cellular Providers In-Reply-To: <0B9478CB-F434-4474-878B-2DCBB5E71CC6@me.com> References: <0B9478CB-F434-4474-878B-2DCBB5E71CC6@me.com> Message-ID: <73fbd61f34974271be79a6c3d0a77c81@doaisd5273.state.mt.ads> At the sites, are you installing external antennae's? -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Kenneth McRae Sent: Wednesday, February 7, 2018 10:25 AM To: Michael Starr Cc: nanog at nanog.org Subject: Re: Console Servers & Cellular Providers Yes. I use Opengear with great success. I use Verizon, T-Mobile & AT&T prepaid service depending on the area. When integrated with Opengear Lighthouse, the console server is fully manageable via cellular service. Kenneth > On Feb 6, 2018, at 6:34 AM, Michael Starr wrote: > > Hello NANOGers, > > > > I am wondering if people still use console servers with cellular > service as a disaster out-of-band management solution in your data > centers? If not, what are the alternatives? If so, are there any > recommendations for pay-as-you-go cellular service? Apologies if this > is too trivial a question for this group. > > > > Thanks for your time, > > Mike From tknchris at gmail.com Wed Feb 7 17:33:36 2018 From: tknchris at gmail.com (chris) Date: Wed, 7 Feb 2018 12:33:36 -0500 Subject: Console Servers & Cellular Providers In-Reply-To: References: Message-ID: I've been pretty successful doing this with VZW as they were the only ones that I was able to get a static ip from fairly easily. Talked to tmo and sprint a few times and their people would say it was possible but could never get it done for whatever reason. It works well as long as you have good signal, some buildings might be a little tough if theres alot of obstruction. hope this helps chris On Tue, Feb 6, 2018 at 9:34 AM, Michael Starr wrote: > Hello NANOGers, > > > > I am wondering if people still use console servers with cellular service as > a disaster out-of-band management solution in your data centers? If not, > what are the alternatives? If so, are there any recommendations for > pay-as-you-go cellular service? Apologies if this is too trivial a question > for this group. > > > > Thanks for your time, > > Mike > From chris at marget.com Wed Feb 7 17:47:40 2018 From: chris at marget.com (Chris Marget) Date: Wed, 7 Feb 2018 12:47:40 -0500 Subject: Console Servers & Cellular Providers In-Reply-To: References: Message-ID: Lots of references to static IPs from cellular providers for OoB access in this thread. Why? It seems like a dial-home scheme is an obvious solution here, whether it's Opengear's Lighthouse product, openvpn, or whatever... Do you all have a security directive that demands whitelisted IP addresses? I've got a handful of OoB systems that dial home via cellular, but only after they've been poked by SMS. Opengear's auto-response facilitates that, and I've done it with EEM (to start DMVPN) on Cisco ISRs. The main headache I've run into is that it's tough to get a SIM card from ATT that does data and SMS: ATT's M2M plans don't allow SMS, and moving the SIM from an iPhone to "a computer" causes the SMS capability to vanish. My ATT OoB boxes (used only where Verizon is reported to not work) are online all the time. From rcarpen at network1.net Wed Feb 7 17:55:16 2018 From: rcarpen at network1.net (Randy Carpenter) Date: Wed, 7 Feb 2018 12:55:16 -0500 (EST) Subject: Console Servers & Cellular Providers In-Reply-To: References: Message-ID: <588378700.19338.1518026116859.JavaMail.zimbra@network1.net> Static IPs are useful for connecting to the "home" site. If our main office is offline for some reason, it is nice to be able to quickly connect via cellular OoB. I agree that other solutions (dial-home, or private network) make sense for satellite sites. thanks, -Randy ----- On Feb 7, 2018, at 12:47 PM, Chris Marget chris at marget.com wrote: > Lots of references to static IPs from cellular providers for OoB access in > this thread. Why? It seems like a dial-home scheme is an obvious solution > here, whether it's Opengear's Lighthouse product, openvpn, or whatever... > > Do you all have a security directive that demands whitelisted IP addresses? > > I've got a handful of OoB systems that dial home via cellular, but only > after they've been poked by SMS. Opengear's auto-response facilitates that, > and I've done it with EEM (to start DMVPN) on Cisco ISRs. > > The main headache I've run into is that it's tough to get a SIM card from > ATT that does data and SMS: ATT's M2M plans don't allow SMS, and moving the > SIM from an iPhone to "a computer" causes the SMS capability to vanish. My > ATT OoB boxes (used only where Verizon is reported to not work) are online > all the time. From dhubbard at dino.hostasaurus.com Wed Feb 7 18:29:00 2018 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 7 Feb 2018 18:29:00 +0000 Subject: Console Servers & Cellular Providers In-Reply-To: References: Message-ID: We get static IP's to facilitate monitoring that the OOB remains online (easier to hit a non-changing IP than getting false positives for outage between an IP change and DDnS or whatever other type of update needs to happen), and it also makes IPSec VPN easy if your roving sysadmins know what IP to VPN into for a given site, when DNS may or may not be working. On 2/7/18, 12:49 PM, "NANOG on behalf of Chris Marget" wrote: Lots of references to static IPs from cellular providers for OoB access in this thread. Why? It seems like a dial-home scheme is an obvious solution here, whether it's Opengear's Lighthouse product, openvpn, or whatever... Do you all have a security directive that demands whitelisted IP addresses? I've got a handful of OoB systems that dial home via cellular, but only after they've been poked by SMS. Opengear's auto-response facilitates that, and I've done it with EEM (to start DMVPN) on Cisco ISRs. The main headache I've run into is that it's tough to get a SIM card from ATT that does data and SMS: ATT's M2M plans don't allow SMS, and moving the SIM from an iPhone to "a computer" causes the SMS capability to vanish. My ATT OoB boxes (used only where Verizon is reported to not work) are online all the time. From matthew at corp.crocker.com Wed Feb 7 18:30:01 2018 From: matthew at corp.crocker.com (Matthew Crocker) Date: Wed, 7 Feb 2018 18:30:01 +0000 Subject: Looking for colocation in NY or NJ Message-ID: <183A48DC-5E2F-4EE3-8767-97725717E8AD@corp.crocker.com> Hello, I’m looking to establish a POP in the area with the purpose of connecting to exchanges (DE-CIX, Equinix New York, NYIIX). I’ll need access to Lightower or Level(3) for transport back to Springfield (1 Federal St), & Boston MA (1 Summer St). I’ll need a cabinet, 208v power, planning on a Juniper MX480 but my go with a couple MX204s Initially I was looking at 111 8th. I’m getting pricing from Equinix for NY2 that will save $$ on space & power. Is it really ‘all the same’ and I can get anywhere to anywhere in NY Metro? Would I be handicapping myself by going across the river into NJ? Thanks -Matt -- Matthew Crocker Crocker Communications, Inc. President From smeuse at mara.org Wed Feb 7 18:43:14 2018 From: smeuse at mara.org (Steve Meuse) Date: Wed, 07 Feb 2018 18:43:14 +0000 Subject: Looking for colocation in NY or NJ In-Reply-To: <183A48DC-5E2F-4EE3-8767-97725717E8AD@corp.crocker.com> References: <183A48DC-5E2F-4EE3-8767-97725717E8AD@corp.crocker.com> Message-ID: You should talk to the guys at Towardex. http://www.towardex.com/ -Steve On Wed, Feb 7, 2018 at 6:30 PM Matthew Crocker wrote: > > Hello, > > I’m looking to establish a POP in the area with the purpose of connecting > to exchanges (DE-CIX, Equinix New York, NYIIX). I’ll need access to > Lightower or Level(3) for transport back to Springfield (1 Federal St), & > Boston MA > > (1 Summer St). > > I’ll need a cabinet, 208v power, planning on a Juniper MX480 but my go > with a couple MX204s > > Initially I was looking at 111 8th. I’m getting pricing from Equinix for > NY2 that will save $$ on space & power. Is it really ‘all the same’ and I > can get anywhere to anywhere in NY Metro? > > Would I be handicapping myself by going across the river into NJ? > > Thanks > > -Matt > > -- > Matthew Crocker > Crocker Communications, Inc. > President > From michael at crossivity.com Thu Feb 8 04:48:06 2018 From: michael at crossivity.com (Michael Rave) Date: Thu, 8 Feb 2018 13:48:06 +0900 Subject: Console Servers & Cellular Providers In-Reply-To: References: Message-ID: <0BF08BF0-198E-4AE5-9E54-7530B69CD00E@crossivity.com> > On 6 Feb 2018, at 23:34, Michael Starr wrote: > > I am wondering if people still use console servers with cellular service as > a disaster out-of-band management solution in your data centers? If not, > what are the alternatives? If so, are there any recommendations for > pay-as-you-go cellular service? Apologies if this is too trivial a question > for this group. At all my sites I use Air Console with an OOB IP connection from another ISP. Sometimes this is free since it is barely being used or I’m being charged a very small amount . Other times I exchange an OOB IP connection. So I get one from them and they get one from me through my network. Regards, Michael Rave Crossivity From saku at ytti.fi Thu Feb 8 09:27:38 2018 From: saku at ytti.fi (Saku Ytti) Date: Thu, 8 Feb 2018 11:27:38 +0200 Subject: Console Servers & Cellular Providers In-Reply-To: <0BF08BF0-198E-4AE5-9E54-7530B69CD00E@crossivity.com> References: <0BF08BF0-198E-4AE5-9E54-7530B69CD00E@crossivity.com> Message-ID: On 8 February 2018 at 06:48, Michael Rave wrote: > At all my sites I use Air Console with an OOB IP connection from another ISP. Sometimes this is free since it is barely being used or I’m being charged a very small amount . Other times I exchange an OOB IP connection. So I get one from them and they get one from me through my network. While I appreciate being thrifty, managing these good-will trades can be challenging. The person who you collaborated with may be gone, there may be no formal way to file complaint or escalate, so you may find MTTR times being very high or even need to come up with entirely new solution at arbitrary time. I would definitely optimise for having real contract and circuit # from provider who has normal product. Your situation may differ, but in my situation MRC is dominated by fibre leases and electricity, and IP-OOB WAN cost is immaterial. -- ++ytti From jason at unlimitednet.us Thu Feb 8 17:11:30 2018 From: jason at unlimitednet.us (Jason Canady) Date: Thu, 8 Feb 2018 12:11:30 -0500 Subject: ticketmaster.com 403 Forbidden In-Reply-To: <3d031ecfff91450c879c18aaa99cce1f@SC58MEXGP033.CORP.CHARTERCOM.com> References: <20170206160901.GA86663@excession.tpb.net> <0B7AD244-66FD-4CC2-95AD-DCC0316432C4@gmail.com> <64260455-395C-4864-B492-0BFD99EDC89D@gmail.com> <676ebaf4-48c9-1bd4-9de3-1a3fe3c5f97b@bogus.com> <3d031ecfff91450c879c18aaa99cce1f@SC58MEXGP033.CORP.CHARTERCOM.com> Message-ID: Has anyone found a resolution to this?  Our network has been blocked and I had a customer mention it to me the other day, so I would like to get it resolved. Thank you! Best Regards, -- Jason Canady Unlimited Net, LLC Responsive, Reliable, Secure On 2/7/17 12:05 PM, Manser, Charles J wrote: > All, > > Thank you for the suggestions. All (3) of the e-mail addresses associated with their ARIN records bounced back. > > Remote Server returned '< #5.7.133 smtp;550 5.7.133 RESOLVER.RST.SenderNotAuthenticatedForGroup; authentication required; Delivery restriction check failed because the sender was not authenticated when sending to this group>' > > It can be difficult for consumers to work these issues individually, so we reached out to the NANOG community for an assist. The problem seemed widespread and not isolated to single customers and referring them to a web form did not seem like an option. > > Good news: I am making some progress with the Live Nation/Ticketmaster team. > > "Thank you for bringing this to our attention. We are conducting an investigation on suspicious activity that has been observed on the range of IP's are associated to your connectivity and will make every effort to do this as fast as possible." > > Thank you all again for the help and I will keep the archive updated if we reach a repeatable resolution. > > Regards, > > Charles Manser | Principal Engineer I, Network Security > Charles.Manser at charter.com > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of joel jaeggli > Sent: Monday, February 06, 2017 7:38 PM > To: Suresh Ramasubramanian ; mike.lyon at gmail.com; Ethan E. Dee > Cc: Niels Bakker ; nanog at nanog.org > Subject: Re: ticketmaster.com 403 Forbidden > > On 2/6/17 8:49 AM, Suresh Ramasubramanian wrote: >> My guess is you have or had sometime in the long distant past a scalper operating on your network, using automated ticket purchase bots. >> >> If you still have that scalper around, you might want to turf him. If he’s ancient history, saying so might induce them to remove the block. > Note that scalper bots benefit from pools of residential ip addresses to > work with in subverting the anti-bot countermeasures of ticket sale > platforms. so there are the legitimate possibility that subverted hosts > are being used for that sort of thing. >> --srs >> >> On 06/02/17, 8:45 AM, "nanog-bounces at nanog.org on behalf of mike.lyon at gmail.com" wrote: >> >> Yup, i have a /22 that has the same problem. Support is useless... >> >> > On Feb 6, 2017, at 08:35, Ethan E. Dee wrote: >> > >> > It gives me a Forbidden error. >> > It has for over a year. >> > There support says they are not allowed to me why by their policy. >> > it is across an entire /19. >> > I gave up after the fifth time and encourage the customers to call them individually. >> > >> >> On 02/06/2017 11:09 AM, Niels Bakker wrote: >> >> * Charles.Manser at charter.com (Manser, Charles J) [Mon 06 Feb 2017, 16:21 CET]: >> >>> It seems that browsing to ticketmaster.com or any of the associated IP addresses results in a 403 Forbidden for our customers today. Is anyone else having this issue? >> >> >> >> http://help.ticketmaster.com/why-am-i-getting-a-blocked-forbidden-or-403-error-message/ >> >> >> >> >> >> -- Niels. >> > >> >> >> >> > > E-MAIL CONFIDENTIALITY NOTICE: > The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From dspataro at linode.com Wed Feb 7 19:17:54 2018 From: dspataro at linode.com (Dan Spataro) Date: Wed, 7 Feb 2018 14:17:54 -0500 Subject: Looking for colocation in NY or NJ In-Reply-To: <183A48DC-5E2F-4EE3-8767-97725717E8AD@corp.crocker.com> References: <183A48DC-5E2F-4EE3-8767-97725717E8AD@corp.crocker.com> Message-ID: <6533BE83-8CA4-446E-A390-DF47181A62DA@linode.com> > On Feb 7, 2018, at 1:30 PM, Matthew Crocker wrote: > > I’m looking to establish a POP in the area with the purpose of connecting to exchanges (DE-CIX, Equinix New York, NYIIX). I’ll need access to Lightower or Level(3) for transport back to Springfield (1 Federal St), & Boston MA (1 Summer St). > > I’ll need a cabinet, 208v power, planning on a Juniper MX480 but my go with a couple MX204s > > Initially I was looking at 111 8th. I’m getting pricing from Equinix for NY2 that will save $$ on space & power. Is it really ‘all the same’ and I can get anywhere to anywhere in NY Metro? We have collocation at 111 8th Equinix and 165 Halsey Street Newark NJ in one of the new MMRs. We much prefer Halsey due to the fact they do not charge MRCs for cross-connects. We pick up De-Cix/NYIIX from there plus a bunch of other providers, the building is overall pretty carrier dense. When looking into 165 Halsey you will probably want to do some homework and make sure the carriers you are using have redundant paths to the rest of their network from Halsey as some are just a stub of the NY POPs. http://www.165halsey.com/ -Dan From compuwizz at gmail.com Wed Feb 7 19:40:00 2018 From: compuwizz at gmail.com (Jared Geiger) Date: Wed, 7 Feb 2018 11:40:00 -0800 Subject: Brighthouse Networks packet loss Message-ID: Our customers on Bright House Networks / Time Warner Cable / Charter in Orlando, Melbourne and Tampa are experiencing packet loss between Orlando and Miami before the traffic reaches Hurricane Electric. The odd thing is when we disable Hurricane Electric, the packetloss goes away but the traceroute is the exact same path to Miami. HE sees no loss from our location in Reston VA/Ashburn to Miami. We are having our customers talk to Bright House Networks but probably won't get very far with residential support. Any tips or assistance would be greatly appreciated. Regards, Jared Geiger IT Vocal LLC AS 32478 From andy at xecu.net Wed Feb 7 23:36:59 2018 From: andy at xecu.net (Andy Dills) Date: Wed, 07 Feb 2018 18:36:59 -0500 Subject: Contact inside of Time Warner/Spectrum =?UTF-8?Q?NOC=3F?= Message-ID: <1cad3184ad8939498e432cd1b54e27a6@xecu.net> As of this past weekend, we've had numerous customers that are all on TWT/Spectrum/Charter's network complain to us about frequent slowness and dropped connections to our address space when using standard ports, as well as failed IPsec connections. Traffic on non-standard ports flows fine (for example a website on 8080). Doing wiresharks, we've determined the packets are hanging on the way back to the end user on Spectrum's network. It would appear traffic from our address space is being subjected to an overworked content inspection system. I can't seem to find a way to contact somebody technical without being a customer. Help? Thanks, Andy -- ----------------------------------------------------- ANDY DILLS - XECUNET, LLC 5744-R Industry Lane Frederick MD 21704 www.xecu.net [1] P: 301-682-9972 P: 1-877-XECUNET F: 240-215-0351 Twitter [2] Facebook [3] ----------------------------------------------------- Links: ------ [1] http://www.xecu.net/ [2] https://twitter.com/Xecunet [3] http://www.facebook.com/xecunet From edee at globalvision.net Thu Feb 8 20:23:29 2018 From: edee at globalvision.net (Ethan E. Dee) Date: Thu, 8 Feb 2018 15:23:29 -0500 Subject: ticketmaster.com 403 Forbidden In-Reply-To: References: <20170206160901.GA86663@excession.tpb.net> <0B7AD244-66FD-4CC2-95AD-DCC0316432C4@gmail.com> <64260455-395C-4864-B492-0BFD99EDC89D@gmail.com> <676ebaf4-48c9-1bd4-9de3-1a3fe3c5f97b@bogus.com> <3d031ecfff91450c879c18aaa99cce1f@SC58MEXGP033.CORP.CHARTERCOM.com> Message-ID: <52f60fb8-292d-d8f4-04b5-d3a327e7feac@globalvision.net> They don't care at all. They are not interested in helping in any way. All four times I contacted  they were extremely rude. On 2/8/2018 12:11 PM, Jason Canady wrote: > Has anyone found a resolution to this?  Our network has been blocked > and I had a customer mention it to me the other day, so I would like > to get it resolved. > > Thank you! > > Best Regards, > From andy at xecu.net Thu Feb 8 23:08:00 2018 From: andy at xecu.net (Andy Dills) Date: Thu, 08 Feb 2018 18:08:00 -0500 Subject: Brighthouse Networks packet loss In-Reply-To: References: Message-ID: This isn't all that different from our situation. Did this just start this week Jared? Perhaps the issue is whatever content inspection system is being used on TWT's peering with HE. I'll send 10796, 11426, 3456, 7843, and 20115 to another provider and hopefully things return to normal...(I think that's most of their traffic, not sure if they have some other ASNs). Andy --- ----------------------------------------------------- ANDY DILLS - XECUNET, LLC 5744-R Industry Lane Frederick MD 21704 www.xecu.net [1] P: 301-682-9972 P: 1-877-XECUNET F: 240-215-0351 Twitter [2] Facebook [3] ----------------------------------------------------- On 02/07/2018 14:40, Jared Geiger wrote: > Our customers on Bright House Networks / Time Warner Cable / Charter in > Orlando, Melbourne and Tampa are experiencing packet loss between Orlando > and Miami before the traffic reaches Hurricane Electric. The odd thing is > when we disable Hurricane Electric, the packetloss goes away but the > traceroute is the exact same path to Miami. HE sees no loss from our > location in Reston VA/Ashburn to Miami. > > We are having our customers talk to Bright House Networks but probably > won't get very far with residential support. > > Any tips or assistance would be greatly appreciated. > > Regards, > Jared Geiger > IT Vocal LLC > AS 32478 Links: ------ [1] http://www.xecu.net/ [2] https://twitter.com/Xecunet [3] http://www.facebook.com/xecunet From compuwizz at gmail.com Fri Feb 9 01:15:45 2018 From: compuwizz at gmail.com (Jared Geiger) Date: Thu, 8 Feb 2018 17:15:45 -0800 Subject: Brighthouse Networks packet loss In-Reply-To: References: Message-ID: If we send traffic to TWC / Charter / BHN via another provider, it does clear up. So yes there is something odd between HE and TWC / Charter/ BHN. Andy - add 33363 in your list of ASNs. That is Bright House Networks. On Thu, Feb 8, 2018 at 3:08 PM, Andy Dills wrote: > This isn't all that different from our situation. Did this just start this > week Jared? Perhaps the issue is whatever content inspection system is > being used on TWT's peering with HE. > > I'll send 10796, 11426, 3456, 7843, and 20115 to another provider and > hopefully things return to normal...(I think that's most of their traffic, > not sure if they have some other ASNs). > > Andy > --- > > ----------------------------------------------------- > *Andy Dills - Xecunet, LLC * > > 5744-R Industry Lane > > Frederick MD 21704 > > www.xecu.net > P: 301-682-9972 <(301)%20682-9972> > P: 1-877-XECUNET > F: 240-215-0351 <(240)%20215-0351> > > Twitter > > Facebook > ----------------------------------------------------- > > On 02/07/2018 14:40, Jared Geiger wrote: > > Our customers on Bright House Networks / Time Warner Cable / Charter in > Orlando, Melbourne and Tampa are experiencing packet loss between Orlando > and Miami before the traffic reaches Hurricane Electric. The odd thing is > when we disable Hurricane Electric, the packetloss goes away but the > traceroute is the exact same path to Miami. HE sees no loss from our > location in Reston VA/Ashburn to Miami. > > We are having our customers talk to Bright House Networks but probably > won't get very far with residential support. > > Any tips or assistance would be greatly appreciated. > > Regards, > Jared Geiger > IT Vocal LLC > AS 32478 > > From jmglass at iup.edu Fri Feb 9 14:22:02 2018 From: jmglass at iup.edu (Jim Glassford) Date: Fri, 9 Feb 2018 09:22:02 -0500 Subject: Square-Enix redirect to maintenance page? Message-ID: <19b8c7d5-f3be-2ec9-f595-ad4ccbc45b36@iup.edu> Greetings, Any chance someone has a support contact I could reach out to at Square Enix? Our Class B is redirected to a Maintenance Page: https://secure.square-enix.com/account/app/svc/info Our Class C networks under same ASN do work OK, get to their account login page: https://secure.square-enix.com/ Trying to work with their front line support and no luck getting anywhere. Any pointers appreciated! Jim Glassford From cscora at apnic.net Fri Feb 9 18:03:20 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 10 Feb 2018 04:03:20 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180209180320.1B6D0C450F@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, CaribNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG 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 10 Feb, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 683940 Prefixes after maximum aggregation (per Origin AS): 265286 Deaggregation factor: 2.58 Unique aggregates announced (without unneeded subnets): 330027 Total ASes present in the Internet Routing Table: 59792 Prefixes per ASN: 11.44 Origin-only ASes present in the Internet Routing Table: 51639 Origin ASes announcing only one prefix: 22710 Transit ASes present in the Internet Routing Table: 8153 Transit-only ASes present in the Internet Routing Table: 244 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 35 Max AS path prepend of ASN (262865) 25 Prefixes from unregistered ASNs in the Routing Table: 62 Number of instances of unregistered ASNs: 62 Number of 32-bit ASNs allocated by the RIRs: 21449 Number of 32-bit ASNs visible in the Routing Table: 17216 Prefixes from 32-bit ASNs in the Routing Table: 71349 Number of bogon 32-bit ASNs visible in the Routing Table: 14 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 335 Number of addresses announced to Internet: 2858858914 Equivalent to 170 /8s, 102 /16s and 185 /24s Percentage of available address space announced: 77.2 Percentage of allocated address space announced: 77.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.8 Total number of prefixes smaller than registry allocations: 225953 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 188822 Total APNIC prefixes after maximum aggregation: 53851 APNIC Deaggregation factor: 3.51 Prefixes being announced from the APNIC address blocks: 187878 Unique aggregates announced from the APNIC address blocks: 77445 APNIC Region origin ASes present in the Internet Routing Table: 8634 APNIC Prefixes per ASN: 21.76 APNIC Region origin ASes announcing only one prefix: 2446 APNIC Region transit ASes present in the Internet Routing Table: 1272 Average APNIC Region AS path length visible: 4.3 Max APNIC Region AS path length visible: 28 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3536 Number of APNIC addresses announced to Internet: 767608098 Equivalent to 45 /8s, 192 /16s and 197 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 204235 Total ARIN prefixes after maximum aggregation: 97874 ARIN Deaggregation factor: 2.09 Prefixes being announced from the ARIN address blocks: 205079 Unique aggregates announced from the ARIN address blocks: 96641 ARIN Region origin ASes present in the Internet Routing Table: 18085 ARIN Prefixes per ASN: 11.34 ARIN Region origin ASes announcing only one prefix: 6696 ARIN Region transit ASes present in the Internet Routing Table: 1799 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: 2308 Number of ARIN addresses announced to Internet: 1109188128 Equivalent to 66 /8s, 28 /16s and 222 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 184461 Total RIPE prefixes after maximum aggregation: 90070 RIPE Deaggregation factor: 2.05 Prefixes being announced from the RIPE address blocks: 180786 Unique aggregates announced from the RIPE address blocks: 108513 RIPE Region origin ASes present in the Internet Routing Table: 24866 RIPE Prefixes per ASN: 7.27 RIPE Region origin ASes announcing only one prefix: 11318 RIPE Region transit ASes present in the Internet Routing Table: 3485 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: 6632 Number of RIPE addresses announced to Internet: 713714560 Equivalent to 42 /8s, 138 /16s and 107 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 88156 Total LACNIC prefixes after maximum aggregation: 19487 LACNIC Deaggregation factor: 4.52 Prefixes being announced from the LACNIC address blocks: 89484 Unique aggregates announced from the LACNIC address blocks: 39901 LACNIC Region origin ASes present in the Internet Routing Table: 6824 LACNIC Prefixes per ASN: 13.11 LACNIC Region origin ASes announcing only one prefix: 1886 LACNIC Region transit ASes present in the Internet Routing Table: 1264 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 35 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4351 Number of LACNIC addresses announced to Internet: 172348384 Equivalent to 10 /8s, 69 /16s and 211 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 18202 Total AfriNIC prefixes after maximum aggregation: 3957 AfriNIC Deaggregation factor: 4.60 Prefixes being announced from the AfriNIC address blocks: 20378 Unique aggregates announced from the AfriNIC address blocks: 7260 AfriNIC Region origin ASes present in the Internet Routing Table: 1112 AfriNIC Prefixes per ASN: 18.33 AfriNIC Region origin ASes announcing only one prefix: 363 AfriNIC Region transit ASes present in the Internet Routing Table: 221 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 389 Number of AfriNIC addresses announced to Internet: 95610624 Equivalent to 5 /8s, 178 /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 4538 5435 4195 92 ERX-CERNET-BKB China Education and Rese 7545 3781 406 411 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2854 11132 769 KIXS-AS-KR Korea Telecom, KR 9829 2788 1499 539 BSNL-NIB National Internet Backbone, IN 17974 2762 934 77 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9394 2634 4923 27 CTTNET China TieTong Telecommunications 7552 2611 1161 63 VIETEL-AS-AP Viettel Group, VN 45899 2583 1554 155 VNPT-AS-VN VNPT Corp, VN 9808 2179 8699 32 CMNET-GD Guangdong Mobile Communication 4755 2079 417 215 TATACOMM-AS TATA Communications formerl 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 3392 1323 86 SHAW - Shaw Communications Inc., CA 22773 3269 2951 143 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2167 405 108 MEGAPATH5-US - MegaPath Corporation, US 20115 2086 2386 434 CHARTER-NET-HKY-NC - Charter Communicat 16509 2001 4162 574 AMAZON-02 - Amazon.com, Inc., US 6389 1937 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 209 1933 5059 620 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1912 335 209 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 11492 1733 229 564 CABLEONE - CABLE ONE, INC., US 7018 1683 20187 1249 ATT-INTERNET4 - AT&T Services, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3520 187 21 ALJAWWALSTC-AS, SA 20940 2828 822 2049 AKAMAI-ASN1, US 12479 2317 1149 357 UNI2-AS, ES 12389 2104 1859 703 ROSTELECOM-AS, RU 8551 2042 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 34984 2003 332 474 TELLCOM-AS, TR 9121 1955 1692 19 TTNET, TR 13188 1606 100 46 TRIOLAN, UA 8402 1265 544 14 CORBINA-AS OJSC "Vimpelcom", RU 6849 1240 355 21 UKRTELNET, UA 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 4154 3380 592 Uninet S.A. de C.V., MX 10620 3590 541 254 Telmex Colombia S.A., CO 11830 2637 370 66 Instituto Costarricense de Electricidad 6503 1618 437 53 Axtel, S.A.B. de C.V., MX 7303 1506 1026 191 Telecom Argentina S.A., AR 6147 1020 377 27 Telefonica del Peru S.A.A., PE 28573 1017 2242 192 CLARO S.A., BR 3816 1015 509 115 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 920 126 85 Alestra, S. de R.L. de C.V., MX 18881 906 1069 29 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1131 398 49 LINKdotNET-AS, EG 37611 797 91 8 Afrihost, ZA 36903 739 371 135 MT-MPLS, MA 36992 675 1380 37 ETISALAT-MISR, EG 8452 584 1730 18 TE-AS TE-AS, EG 24835 505 850 15 RAYA-AS, EG 29571 461 68 12 ORANGE-COTE-IVOIRE, CI 37492 450 368 78 ORANGE-, TN 15399 360 35 7 WANANCHI-, KE 37342 360 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 4538 5435 4195 92 ERX-CERNET-BKB China Education and Rese 8151 4154 3380 592 Uninet S.A. de C.V., MX 7545 3781 406 411 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3590 541 254 Telmex Colombia S.A., CO 39891 3520 187 21 ALJAWWALSTC-AS, SA 6327 3392 1323 86 SHAW - Shaw Communications Inc., CA 22773 3269 2951 143 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 4766 2854 11132 769 KIXS-AS-KR Korea Telecom, KR 20940 2828 822 2049 AKAMAI-ASN1, US 9829 2788 1499 539 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 8151 4154 3562 Uninet S.A. de C.V., MX 39891 3520 3499 ALJAWWALSTC-AS, SA 7545 3781 3370 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3590 3336 Telmex Colombia S.A., CO 6327 3392 3306 SHAW - Shaw Communications Inc., CA 22773 3269 3126 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 17974 2762 2685 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9394 2634 2607 CTTNET China TieTong Telecommunications Corpora 11830 2637 2571 Instituto Costarricense de Electricidad y Telec 7552 2611 2548 VIETEL-AS-AP Viettel Group, VN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65249 PRIVATE 5.42.234.0/23 35753 ITC ITC AS number, SA 65249 PRIVATE 5.42.234.0/24 35753 ITC ITC AS number, SA 65456 PRIVATE 31.171.126.0/23 199311 AZRT-LX Local Internet Exchang 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 65024 PRIVATE 87.103.234.0/24 39407 CHITATELECOM-AS, RU 65000 PRIVATE 95.179.2.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.3.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.69.0/24 65001 -Private Use AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.14.0/23 10247 NETLINE, ZA 14.192.50.0/23 10247 NETLINE, ZA 14.192.58.0/23 10247 NETLINE, ZA 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/23 10247 NETLINE, ZA 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.228.144.0/22 9829 BSNL-NIB National Internet Backbone, IN 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 43.251.84.0/22 133676 PNPL-AS Precious netcom pvt ltd, IN 43.251.84.0/23 133676 PNPL-AS Precious netcom pvt ltd, IN Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:15 /9:12 /10:37 /11:100 /12:290 /13:563 /14:1093 /15:1899 /16:13313 /17:7789 /18:13645 /19:25298 /20:38917 /21:44994 /22:84062 /23:68095 /24:381610 /25:820 /26:600 /27:652 /28:34 /29:20 /30:18 /31:4 /32:60 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3183 3392 SHAW - Shaw Communications Inc., CA 39891 2946 3520 ALJAWWALSTC-AS, SA 22773 2533 3269 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2061 2167 MEGAPATH5-US - MegaPath Corporation, US 11830 1983 2637 Instituto Costarricense de Electricidad y Telec 30036 1669 1912 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1587 3590 Telmex Colombia S.A., CO 11492 1517 1733 CABLEONE - CABLE ONE, INC., US 8551 1505 2042 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 9121 1439 1955 TTNET, TR Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1572 2:845 4:18 5:2652 6:58 8:1098 9:1 12:1851 13:202 14:1757 15:26 16:3 17:184 18:65 20:49 21:3 23:2533 24:2058 25:2 27:2358 31:1958 32:89 35:24 36:489 37:2561 38:1454 39:245 40:101 41:3040 42:538 43:1952 44:95 45:3664 46:3045 47:199 49:1370 50:1040 51:47 52:940 54:352 55:4 56:7 57:42 58:1587 59:1018 60:386 61:2060 62:1796 63:1805 64:4702 65:2224 66:4509 67:2342 68:1179 69:3192 70:1135 71:560 72:2086 74:2685 75:398 76:421 77:1547 78:1676 79:1755 80:1479 81:1406 82:1069 83:777 84:996 85:1995 86:559 87:1241 88:913 89:2330 90:182 91:6280 92:1162 93:2379 94:2395 95:2734 96:645 97:358 98:930 99:118 100:79 101:1516 102:16 103:17120 104:3275 105:218 106:526 107:1792 108:707 109:2694 110:1578 111:1779 112:1313 113:1377 114:1134 115:1621 116:1637 117:1707 118:2200 119:1675 120:962 121:1061 122:2459 123:1805 124:1458 125:1836 128:1006 129:599 130:439 131:1629 132:609 133:193 134:1003 135:227 136:438 137:478 138:1975 139:565 140:401 141:678 142:778 143:984 144:803 145:450 146:1170 147:752 148:1532 149:718 150:738 151:987 152:751 153:311 154:983 155:754 156:832 157:776 158:624 159:1608 160:844 161:723 162:2545 163:525 164:994 165:1365 166:397 167:1390 168:3103 169:799 170:3655 171:412 172:1029 173:1912 174:877 175:766 176:1882 177:3900 178:2409 179:1169 180:2234 181:2128 182:2454 183:1110 184:905 185:12439 186:3434 187:2362 188:2639 189:2005 190:8116 191:1342 192:9766 193:5878 194:4771 195:3991 196:2360 197:1426 198:5531 199:5912 200:7325 201:4882 202:10370 203:9952 204:4537 205:2849 206:3050 207:3118 208:4000 209:3932 210:4016 211:2143 212:2928 213:2612 214:895 215:61 216:5842 217:2126 218:899 219:623 220:1722 221:997 222:1055 223:1239 End of report From compuwizz at gmail.com Fri Feb 9 18:58:43 2018 From: compuwizz at gmail.com (Jared Geiger) Date: Fri, 9 Feb 2018 10:58:43 -0800 Subject: Brighthouse Networks packet loss In-Reply-To: References: Message-ID: After a few off list replies, HE responded to me again. Upon further investigation, 1 link in a LAG in Ashburn between HE and TWC wasn't showing bidirectional traffic. HE removed the link and the packetloss disappeared. Thanks to everyone who helped! On Thu, Feb 8, 2018 at 5:15 PM, Jared Geiger wrote: > If we send traffic to TWC / Charter / BHN via another provider, it does > clear up. So yes there is something odd between HE and TWC / Charter/ BHN. > > Andy - add 33363 in your list of ASNs. That is Bright House Networks. > > On Thu, Feb 8, 2018 at 3:08 PM, Andy Dills wrote: > >> This isn't all that different from our situation. Did this just start >> this week Jared? Perhaps the issue is whatever content inspection system is >> being used on TWT's peering with HE. >> >> I'll send 10796, 11426, 3456, 7843, and 20115 to another provider and >> hopefully things return to normal...(I think that's most of their traffic, >> not sure if they have some other ASNs). >> >> Andy >> --- >> >> ----------------------------------------------------- >> *Andy Dills - Xecunet, LLC * >> >> 5744-R Industry Lane >> >> Frederick MD 21704 >> >> www.xecu.net >> P: 301-682-9972 <(301)%20682-9972> >> P: 1-877-XECUNET >> F: 240-215-0351 <(240)%20215-0351> >> >> Twitter >> >> Facebook >> ----------------------------------------------------- >> >> On 02/07/2018 14:40, Jared Geiger wrote: >> >> Our customers on Bright House Networks / Time Warner Cable / Charter in >> Orlando, Melbourne and Tampa are experiencing packet loss between Orlando >> and Miami before the traffic reaches Hurricane Electric. The odd thing is >> when we disable Hurricane Electric, the packetloss goes away but the >> traceroute is the exact same path to Miami. HE sees no loss from our >> location in Reston VA/Ashburn to Miami. >> >> We are having our customers talk to Bright House Networks but probably >> won't get very far with residential support. >> >> Any tips or assistance would be greatly appreciated. >> >> Regards, >> Jared Geiger >> IT Vocal LLC >> AS 32478 >> >> > From mattlists at rivervalleyinternet.net Sat Feb 10 01:21:35 2018 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Fri, 9 Feb 2018 20:21:35 -0500 Subject: Netzero Email Abuse Message-ID: Could someone from Netzeros email abuse team contact me? Your spam notification system is spamming me and I have been unable to get ahold of anyone regarding this. Over the last 48 hours it has sent probably 25-30 emails to our abuse email address. All emails are the same, with the same content, and are actually a human generated email from a customer I personally know (Eg not even spam). From tb at tburke.us Sat Feb 10 18:18:05 2018 From: tb at tburke.us (Tim Burke) Date: Sat, 10 Feb 2018 18:18:05 +0000 Subject: Netzero Email Abuse In-Reply-To: References: Message-ID: Good luck... they do not have anybody clueful handling abuse. United Online's abuse is all handled by a bunch of untrained fools in a third-world country. This was as of ~5 years ago, things may have changed now, but I doubt it. On 2/9/18, 7:21 PM, "NANOG on behalf of Matt Hoppes" wrote: Could someone from Netzeros email abuse team contact me? Your spam notification system is spamming me and I have been unable to get ahold of anyone regarding this. Over the last 48 hours it has sent probably 25-30 emails to our abuse email address. All emails are the same, with the same content, and are actually a human generated email from a customer I personally know (Eg not even spam). From mattlists at rivervalleyinternet.net Sat Feb 10 18:59:30 2018 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Sat, 10 Feb 2018 13:59:30 -0500 Subject: Netzero Email Abuse In-Reply-To: References: Message-ID: <5742A26B-492E-4D79-AA1F-2E4BE6BAFE52@rivervalleyinternet.net> I just replied to them and got out on a CARID mailing list. What the? > On Feb 10, 2018, at 13:18, Tim Burke wrote: > > Good luck... they do not have anybody clueful handling abuse. United Online's abuse is all handled by a bunch of untrained fools in a third-world country. This was as of ~5 years ago, things may have changed now, but I doubt it. > > On 2/9/18, 7:21 PM, "NANOG on behalf of Matt Hoppes" wrote: > > Could someone from Netzeros email abuse team contact me? > > Your spam notification system is spamming me and I have been unable to get ahold of anyone regarding this. > > Over the last 48 hours it has sent probably 25-30 emails to our abuse email address. All emails are the same, with the same content, and are actually a human generated email from a customer I personally know (Eg not even spam). > From niels=nanog at bakker.net Sat Feb 10 19:17:12 2018 From: niels=nanog at bakker.net (Niels Bakker) Date: Sat, 10 Feb 2018 20:17:12 +0100 Subject: Netzero Email Abuse In-Reply-To: <5742A26B-492E-4D79-AA1F-2E4BE6BAFE52@rivervalleyinternet.net> References: <5742A26B-492E-4D79-AA1F-2E4BE6BAFE52@rivervalleyinternet.net> Message-ID: <20180210191712.GB30812@excession.tpb.net> * mattlists at rivervalleyinternet.net (Matt Hoppes) [Sat 10 Feb 2018, 20:00 CET]: >I just replied to them and got out on a CARID mailing list. What the? There's an autoresponder subscribed to this list but since the list admins rarely post themselves they won't know to take action. -- Niels. From sean at donelan.com Mon Feb 12 01:45:14 2018 From: sean at donelan.com (Sean Donelan) Date: Sun, 11 Feb 2018 20:45:14 -0500 (EST) Subject: Reminder: Deadline to submit 2017 hurricane comments to FCC Message-ID: There are 10 days left to submit comments to the FCC about the 2017 hurricane season and response/recovery efforts -- Due Feburary 21, 2018. http://transition.fcc.gov/Daily_Releases/Daily_Business/2017/db1211/DA-17-1180A1.pdf So far, 56 comments and reply comments have been filed in proceeding 17-344. https://www.fcc.gov/ecfs/search/filings?proceedings_name=17-344&sort=date_disseminated,DESC You don't need a lawyer, and can file "Express Comments." From sean at donelan.com Mon Feb 12 02:19:44 2018 From: sean at donelan.com (Sean Donelan) Date: Sun, 11 Feb 2018 21:19:44 -0500 (EST) Subject: Blackout in Northern Puerto Rico after explosion at power substation Message-ID: An explosion and large fire at a power substation has caused a blackout in northern Puerto Rico. Before this latest damage, Puerto Rico had recovered about 84% of its pre-hurricane electric grid distribution capacity. From Desigan.Pillay at is.co.za Mon Feb 12 08:31:37 2018 From: Desigan.Pillay at is.co.za (Desigan Pillay (IS)) Date: Mon, 12 Feb 2018 08:31:37 +0000 Subject: Level3 Technical Support Message-ID: Greetings Any chance someone has a support contact I could reach out to at Level3? Or could someone from Level3 support contact me? Regards Desigan Pillay Senior Network Engineer T +27 87 3530628 C +27 82 8808722 www.is.co.za Internet Solutions is a division of Dimension Data Disclaimer: https://www.is.co.za/legal/#e-mail-confidentiality-notice-and-disclaimer From mstucchi at ripe.net Mon Feb 12 14:14:57 2018 From: mstucchi at ripe.net (Massimiliano Stucchi) Date: Mon, 12 Feb 2018 15:14:57 +0100 Subject: RIPE NCC Global IPv6 Deployment Survey Message-ID: <04f85099-bcc7-ea89-a791-0e07e7502001@ripe.net> Dear colleagues, The RIPE NCC would like to invite you to participate in its Global IPv6 Survey 2018. The goal of the survey is to get an overview IPv6 deployment across the world, and to assess how this is seen from the perspective of ISPs and Enterprise users. The 2018 survey is a follow up to similar surveys run between 2008 and 2013, and will serve as a comparison with the data acquired back then. You can find the survey at the following address: https://www.surveymonkey.com/r/GlobalIPv6survey2018 Responses can be submitted until 31 March 2018. We will then collect the data with the aim of presenting the preliminary results during the upcoming RIPE 76 meeting in Marseille. If you have any question about the survey, please feel free to email us at: ipv6survey2018 at ripe.net. Thank you very much in advance for your participation! -- Massimiliano Stucchi IPv6 Programme Manager RIPE NCC mstucchi at ripe.net Follow us on Twitter for the fastest and latest RIPE NCC Training news! @TrainingRIPENCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 553 bytes Desc: OpenPGP digital signature URL: From brian at bloveland.com Tue Feb 13 04:21:09 2018 From: brian at bloveland.com (Brian Loveland) Date: Tue, 13 Feb 2018 04:21:09 +0000 Subject: Console Servers & Cellular Providers In-Reply-To: <588378700.19338.1518026116859.JavaMail.zimbra@network1.net> References: <588378700.19338.1518026116859.JavaMail.zimbra@network1.net> Message-ID: We have >100 AT&T units deployed and about 35 Verizon units and have had virtually no issues with call home via openvpn. All opengear ACM7xxx series. We are using machine to machine plans from marketplace.att.com. Used to be a great deal, the new plans are still “fair” and better than standard consumer/business prepaid plans. We average around 100MB/mo/device, we could probably improve that with some effort on keepalives etc. We have had coverage issues in some sites but in the colos we are in it has been fine. In colo we usually also take “house” IP due to XC costs blowing out any 3rd parties, and I have done DSL on PSTN XC before, but even in those cases the LTE is still useful particularly for turn up where the colo house ip rarely “just works”. On Wed, Feb 7, 2018 at 12:56 PM Randy Carpenter wrote: > > Static IPs are useful for connecting to the "home" site. If our main > office is offline for some reason, it is nice to be able to quickly connect > via cellular OoB. > > I agree that other solutions (dial-home, or private network) make sense > for satellite sites. > > thanks, > -Randy > > > ----- On Feb 7, 2018, at 12:47 PM, Chris Marget chris at marget.com wrote: > > > Lots of references to static IPs from cellular providers for OoB access > in > > this thread. Why? It seems like a dial-home scheme is an obvious solution > > here, whether it's Opengear's Lighthouse product, openvpn, or whatever... > > > > Do you all have a security directive that demands whitelisted IP > addresses? > > > > I've got a handful of OoB systems that dial home via cellular, but only > > after they've been poked by SMS. Opengear's auto-response facilitates > that, > > and I've done it with EEM (to start DMVPN) on Cisco ISRs. > > > > The main headache I've run into is that it's tough to get a SIM card from > > ATT that does data and SMS: ATT's M2M plans don't allow SMS, and moving > the > > SIM from an iPhone to "a computer" causes the SMS capability to vanish. > My > > ATT OoB boxes (used only where Verizon is reported to not work) are > online > > all the time. > From mhuff at ox.com Tue Feb 13 12:44:11 2018 From: mhuff at ox.com (Matthew Huff) Date: Tue, 13 Feb 2018 12:44:11 +0000 Subject: Opensource SNMP Trap Receivers ??? Message-ID: <62c2c255e14043ff902d0d629342dad4@ox.com> We are retiring a legacy SNMP system and are looking for a simple, opensource SNMP trap receiver/alerting system. We aren't looking for a full SNMP system, just something that will receive snmp traps and email/alert based on them. 1) Looking for something off the shelf, not a development project 2) Opensource or low cost 3) SNMP MIB compiler Any suggestions? ---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 From jackson.tim at gmail.com Tue Feb 13 13:07:43 2018 From: jackson.tim at gmail.com (Tim Jackson) Date: Tue, 13 Feb 2018 07:07:43 -0600 Subject: Opensource SNMP Trap Receivers ??? In-Reply-To: <62c2c255e14043ff902d0d629342dad4@ox.com> References: <62c2c255e14043ff902d0d629342dad4@ox.com> Message-ID: http://snmptt.sourceforge.net/ On Feb 13, 2018 6:46 AM, "Matthew Huff" wrote: > We are retiring a legacy SNMP system and are looking for a simple, > opensource SNMP trap receiver/alerting system. We aren't looking for a full > SNMP system, just something that will receive snmp traps and email/alert > based on them. > > 1) Looking for something off the shelf, not a development project > 2) Opensource or low cost > 3) SNMP MIB compiler > > Any suggestions? > > ---- > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > > > From kscotthelms at gmail.com Tue Feb 13 13:08:40 2018 From: kscotthelms at gmail.com (K. Scott Helms) Date: Tue, 13 Feb 2018 08:08:40 -0500 Subject: Opensource SNMP Trap Receivers ??? In-Reply-To: <62c2c255e14043ff902d0d629342dad4@ox.com> References: <62c2c255e14043ff902d0d629342dad4@ox.com> Message-ID: Matthew, Sadly, open source + SNMP traps != simple. The simplest option that I've personally used in the past is SNMPTT with Nagios. https://paulgporter.net/2013/09/16/nagios-snmp-traps/ http://www.snmptt.org/docs/snmptt.shtml The main problem is that SNMP traps, like most of SNMP, aren't simple despite the name. Having said that it can be done especially if the gear doesn't change too often. Scott Helms On Tue, Feb 13, 2018 at 7:44 AM, Matthew Huff wrote: > We are retiring a legacy SNMP system and are looking for a simple, > opensource SNMP trap receiver/alerting system. We aren't looking for a full > SNMP system, just something that will receive snmp traps and email/alert > based on them. > > 1) Looking for something off the shelf, not a development project > 2) Opensource or low cost > 3) SNMP MIB compiler > > Any suggestions? > > ---- > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > > > From mhuff at ox.com Tue Feb 13 13:25:16 2018 From: mhuff at ox.com (Matthew Huff) Date: Tue, 13 Feb 2018 13:25:16 +0000 Subject: Opensource SNMP Trap Receivers ??? In-Reply-To: References: <62c2c255e14043ff902d0d629342dad4@ox.com> Message-ID: <91c62a72f8f742b2add1b28013477560@ox.com> Oh hell yes, there isn’t anything simple about SNMP. A number of people have very quickly suggested SNMPTT, which is the sort of product I was looking for. My google foo had failed me. Thanks. ---- Matthew Huff             | 1 Manhattanville Rd Director of Operations   | Purchase, NY 10577 OTA Management LLC       | Phone: 914-460-4039 From: kscott.helms at gmail.com [mailto:kscott.helms at gmail.com] On Behalf Of K. Scott Helms Sent: Tuesday, February 13, 2018 8:09 AM To: Matthew Huff Cc: nanog Subject: Re: Opensource SNMP Trap Receivers ??? Matthew, Sadly, open source + SNMP traps != simple. The simplest option that I've personally used in the past is SNMPTT with Nagios. https://paulgporter.net/2013/09/16/nagios-snmp-traps/ http://www.snmptt.org/docs/snmptt.shtml The main problem is that SNMP traps, like most of SNMP, aren't simple despite the name.  Having said that it can be done especially if the gear doesn't change too often. Scott Helms On Tue, Feb 13, 2018 at 7:44 AM, Matthew Huff wrote: We are retiring a legacy SNMP system and are looking for a simple, opensource SNMP trap receiver/alerting system. We aren't looking for a full SNMP system, just something that will receive snmp traps and email/alert based on them. 1) Looking for something off the shelf, not a development project 2) Opensource or low cost 3) SNMP MIB compiler Any suggestions? ---- Matthew Huff             | 1 Manhattanville Rd Director of Operations   | Purchase, NY 10577 OTA Management LLC       | Phone: 914-460-4039 From ahebert at pubnix.net Tue Feb 13 13:29:25 2018 From: ahebert at pubnix.net (Alain Hebert) Date: Tue, 13 Feb 2018 08:29:25 -0500 Subject: Opensource SNMP Trap Receivers ??? In-Reply-To: References: <62c2c255e14043ff902d0d629342dad4@ox.com> Message-ID: <2b8f537d-b116-1176-b1a9-cfe3b460ad9d@pubnix.net>     Well, Traps:     snmptt is not that hard once you get used to it.     snmpttconvert takes care of most cases... Then the rest is all about scripting.     We're using it on Port Up/Down & BGP Session state change. As for an Open NMS ...  That's another story. https://en.wikipedia.org/wiki/Comparison_of_network_monitoring_systems     Good luck.     PS: We're using a tweaked version of Cacti 0.8.8x with Threshold and adding a sFlow Weatrhermap soon, with only ~200 devices (over 5000 ports) but all the ports are mapped, monitored for traffic, errors and pps,  Sites,  Peers and Customers are also documented and we're using it for our billing purposes (95th). ----- 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 02/13/18 08:08, K. Scott Helms wrote: > Matthew, > > Sadly, open source + SNMP traps != simple. > > The simplest option that I've personally used in the past is SNMPTT with > Nagios. > > https://paulgporter.net/2013/09/16/nagios-snmp-traps/ > > http://www.snmptt.org/docs/snmptt.shtml > > The main problem is that SNMP traps, like most of SNMP, aren't simple > despite the name. Having said that it can be done especially if the gear > doesn't change too often. > > Scott Helms > > On Tue, Feb 13, 2018 at 7:44 AM, Matthew Huff wrote: > >> We are retiring a legacy SNMP system and are looking for a simple, >> opensource SNMP trap receiver/alerting system. We aren't looking for a full >> SNMP system, just something that will receive snmp traps and email/alert >> based on them. >> >> 1) Looking for something off the shelf, not a development project >> 2) Opensource or low cost >> 3) SNMP MIB compiler >> >> Any suggestions? >> >> ---- >> Matthew Huff | 1 Manhattanville Rd >> Director of Operations | Purchase, NY 10577 >> OTA Management LLC | Phone: 914-460-4039 >> >> >> From jean at ddostest.me Tue Feb 13 13:46:47 2018 From: jean at ddostest.me (Jean | ddostest.me) Date: Tue, 13 Feb 2018 08:46:47 -0500 Subject: Opensource SNMP Trap Receivers ??? In-Reply-To: <2b8f537d-b116-1176-b1a9-cfe3b460ad9d@pubnix.net> References: <62c2c255e14043ff902d0d629342dad4@ox.com> <2b8f537d-b116-1176-b1a9-cfe3b460ad9d@pubnix.net> Message-ID: <4630aec2-2109-aa64-116a-eb97adb68809@ddostest.me> People often brag that snmp is super easy. You soon find out that it's not always the case. Some vendors do it better than others. Whataver the tool you will use, it's important to keep in mind to start small. My biggest advice is to start with 1 small example. One that is needed for you now. Like I want to know when 1 power supply fails. You unplug your secondary power supply and test. You will figure it out. Then you add another example like fan fails. Temperature alert. Gradually you will add more interesting stuff like bgp/ospf lost neighbor. Maybe some bfd traps. Really start small and slowly add 1 or 2 traps at a time. Only add traps that are important. Snmp is really powerful but you can easily get lost in all those details. Jean On 13/02/18 08:29 AM, Alain Hebert wrote: >     Well, > > Traps: > >     snmptt is not that hard once you get used to it. > >     snmpttconvert takes care of most cases... Then the rest is all > about scripting. > >     We're using it on Port Up/Down & BGP Session state change. > > > As for an Open NMS ...  That's another story. > > https://en.wikipedia.org/wiki/Comparison_of_network_monitoring_systems > >     Good luck. > >     PS: We're using a tweaked version of Cacti 0.8.8x with Threshold > and adding a sFlow Weatrhermap soon, with only ~200 devices (over 5000 > ports) but all the ports are mapped, monitored for traffic, errors and > pps,  Sites,  Peers and Customers are also documented and we're using it > for our billing purposes (95th). > > ----- > 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 02/13/18 08:08, K. Scott Helms wrote: >> Matthew, >> >> Sadly, open source + SNMP traps != simple. >> >> The simplest option that I've personally used in the past is SNMPTT with >> Nagios. >> >> https://paulgporter.net/2013/09/16/nagios-snmp-traps/ >> >> http://www.snmptt.org/docs/snmptt.shtml >> >> The main problem is that SNMP traps, like most of SNMP, aren't simple >> despite the name.  Having said that it can be done especially if the gear >> doesn't change too often. >> >> Scott Helms >> >> On Tue, Feb 13, 2018 at 7:44 AM, Matthew Huff wrote: >> >>> We are retiring a legacy SNMP system and are looking for a simple, >>> opensource SNMP trap receiver/alerting system. We aren't looking for >>> a full >>> SNMP system, just something that will receive snmp traps and email/alert >>> based on them. >>> >>> 1) Looking for something off the shelf, not a development project >>> 2) Opensource or low cost >>> 3) SNMP MIB compiler >>> >>> Any suggestions? >>> >>> ---- >>> Matthew Huff             | 1 Manhattanville Rd >>> Director of Operations   | Purchase, NY 10577 >>> OTA Management LLC       | Phone: 914-460-4039 >>> >>> >>> > From mdkuch at merit.edu Mon Feb 12 21:56:55 2018 From: mdkuch at merit.edu (Mitchell Kuch) Date: Mon, 12 Feb 2018 16:56:55 -0500 Subject: Merit radb https interface, TLS1.0 only? Message-ID: Hello - Indeed, the http(s)://www.radb.net load balancer was previously configured to support TLS 1.0. This morning the load balancer was re-configured to support TLS 1.2, modern key exchanges, and contemporary ciphers. We are now prioritizing https-everywhere for www.radb.net. Please reach out if you have any questions or concerns: db-admin at radb.net - - Mitchell On Fri, Feb 2, 2018 at 9:15 PM, Eric Kuhnke wrote: > Is the radb login page supposed to be TLS1.0 only? From greg.grimes at msstate.edu Tue Feb 13 14:58:05 2018 From: greg.grimes at msstate.edu (Greg Grimes) Date: Tue, 13 Feb 2018 08:58:05 -0600 Subject: Opensource SNMP Trap Receivers ??? In-Reply-To: <62c2c255e14043ff902d0d629342dad4@ox.com> References: <62c2c255e14043ff902d0d629342dad4@ox.com> Message-ID: We use syslog-ng to catch the traps and then use Simple Event Correlator(SEC). SEC: https://simple-evcorr.github.io/ syslog-ng: https://syslog-ng.org/ We are also developing Check_MK, which is an add on for Nagios. On 02/13/2018 06:44 AM, Matthew Huff wrote: > We are retiring a legacy SNMP system and are looking for a simple, opensource SNMP trap receiver/alerting system. We aren't looking for a full SNMP system, just something that will receive snmp traps and email/alert based on them. > > 1) Looking for something off the shelf, not a development project > 2) Opensource or low cost > 3) SNMP MIB compiler > > Any suggestions? > > ---- > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > > > > -- Greg T. Grimes Senior Network Analyst Information Technology Services Mississippi State University greg.grimes at msstate.edu 662-325-9311(w) From nanog at ics-il.net Tue Feb 13 15:22:25 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 13 Feb 2018 09:22:25 -0600 (CST) Subject: Console Servers & Cellular Providers In-Reply-To: References: <579459199.18549.1518020875960.JavaMail.zimbra@network1.net> Message-ID: <1860802072.5873.1518535345022.JavaMail.mhammett@ThunderFuck> Some RF knowledge helps. Picking a carrier and equipment capable of operating on a low frequency will help ensure it works. IE: In the US, not T-Mobile. Everyone else has near-universal network under 900 MHz. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "James Milko" To: "Randy Carpenter" Cc: "Michael Starr" , "nanog" Sent: Wednesday, February 7, 2018 10:38:15 AM Subject: Re: Console Servers & Cellular Providers How is cell reception in multi-story data centers/carrier hotels? Good enough for remote management? JM From aaron1 at gvtc.com Wed Feb 14 16:58:13 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Wed, 14 Feb 2018 10:58:13 -0600 Subject: 1/2u 100g Metro-E Aggregation Switch In-Reply-To: <1678802774.272368.1514560841025.JavaMail.zimbra@techcompute.net> References: <1484757956.247738.1514522989493.JavaMail.zimbra@techcompute.net> <1678802774.272368.1514560841025.JavaMail.zimbra@techcompute.net> Message-ID: <000301d3a5b5$00c8f570$025ae050$@gvtc.com> I just heard from a Juniper sales person about the ACX5448 (code name ACX5k+ or ACX+ or something like that) and about (4) 100 gig ports... also, about another ACX5k variant that may have 25 gig (25 gig is something the linux server engineer I work with has been talking about in his next datacenter server refresh).... Anybody else know anything about ACX5448 (ACX+) ? -Aaron From lguillory at reservetele.com Wed Feb 14 17:18:37 2018 From: lguillory at reservetele.com (Luke Guillory) Date: Wed, 14 Feb 2018 17:18:37 +0000 Subject: 1/2u 100g Metro-E Aggregation Switch In-Reply-To: <000301d3a5b5$00c8f570$025ae050$@gvtc.com> References: <1484757956.247738.1514522989493.JavaMail.zimbra@techcompute.net> <1678802774.272368.1514560841025.JavaMail.zimbra@techcompute.net> <000301d3a5b5$00c8f570$025ae050$@gvtc.com> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4940B7@RTC-EXCH01.RESERVE.LDS> The presentation I saw listed the two, 5448 and ACX+ as different products. 5448 listed as Committed while the ACX+ was listed as Under Planning. They were also shown to be targeted at different markets, 1G/10G with 100G and 10G/25G/100G. ns -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Aaron Gould Sent: Wednesday, February 14, 2018 10:58 AM To: 'Lewis,Mitchell T.'; 'Jerry Jones' Cc: 'NANOG' Subject: RE: 1/2u 100g Metro-E Aggregation Switch I just heard from a Juniper sales person about the ACX5448 (code name ACX5k+ or ACX+ or something like that) and about (4) 100 gig ports... also, about another ACX5k variant that may have 25 gig (25 gig is something the linux server engineer I work with has been talking about in his next datacenter server refresh).... Anybody else know anything about ACX5448 (ACX+) ? -Aaron From rjacobs at pslightwave.com Wed Feb 14 19:11:36 2018 From: rjacobs at pslightwave.com (Robert Jacobs) Date: Wed, 14 Feb 2018 19:11:36 +0000 Subject: 1/2u 100g Metro-E Aggregation Switch In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4940B7@RTC-EXCH01.RESERVE.LDS> References: <1484757956.247738.1514522989493.JavaMail.zimbra@techcompute.net> <1678802774.272368.1514560841025.JavaMail.zimbra@techcompute.net> <000301d3a5b5$00c8f570$025ae050$@gvtc.com> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4940B7@RTC-EXCH01.RESERVE.LDS> Message-ID: We are dropping these into our Metro network for pure layer 2 aggregation and 100 Gbs port density ... 32 100 Gig ports on single rack unit. Does support 4x 25 and 2x 50 on each interface https://www.extremenetworks.com/product/x870-series/ Robert Jacobs | Network Architect & Director Direct: 832-615-7742   Main:    832-615-8000 Fax:     713-510-1650 5959 Corporate Dr. Suite 3300; Houston, TX 77036 A Certified Woman-Owned Business 24x7x365 Customer  Support: 832-615-8000 | support at pslightwave.com This electronic message contains information from PS Lightwave which may be privileged and confidential. The information is intended to be for the use of individual(s) or entity named above. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify me by telephone or e-mail immediately. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Luke Guillory Sent: Wednesday, February 14, 2018 11:19 AM To: Aaron Gould Cc: 'NANOG' Subject: RE: 1/2u 100g Metro-E Aggregation Switch The presentation I saw listed the two, 5448 and ACX+ as different products. 5448 listed as Committed while the ACX+ was listed as Under Planning. They were also shown to be targeted at different markets, 1G/10G with 100G and 10G/25G/100G. ns -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Aaron Gould Sent: Wednesday, February 14, 2018 10:58 AM To: 'Lewis,Mitchell T.'; 'Jerry Jones' Cc: 'NANOG' Subject: RE: 1/2u 100g Metro-E Aggregation Switch I just heard from a Juniper sales person about the ACX5448 (code name ACX5k+ or ACX+ or something like that) and about (4) 100 gig ports... also, about another ACX5k variant that may have 25 gig (25 gig is something the linux server engineer I work with has been talking about in his next datacenter server refresh).... Anybody else know anything about ACX5448 (ACX+) ? -Aaron From aaron1 at gvtc.com Wed Feb 14 19:47:41 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Wed, 14 Feb 2018 13:47:41 -0600 Subject: 1/2u 100g Metro-E Aggregation Switch In-Reply-To: References: <1484757956.247738.1514522989493.JavaMail.zimbra@techcompute.net> <1678802774.272368.1514560841025.JavaMail.zimbra@techcompute.net> <000301d3a5b5$00c8f570$025ae050$@gvtc.com> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4940B7@RTC-EXCH01.RESERVE.LDS> Message-ID: <000501d3a5cc$ad36fd90$07a4f8b0$@gvtc.com> What does this include ? 17828 (part#) - X870 MPLS Feature Pack (product name) - ExtremeXOS X870 MPLS Feature Pack (firmware license) -Aaron From aaron1 at gvtc.com Wed Feb 14 19:48:57 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Wed, 14 Feb 2018 13:48:57 -0600 Subject: 1/2u 100g Metro-E Aggregation Switch In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4940B7@RTC-EXCH01.RESERVE.LDS> References: <1484757956.247738.1514522989493.JavaMail.zimbra@techcompute.net> <1678802774.272368.1514560841025.JavaMail.zimbra@techcompute.net> <000301d3a5b5$00c8f570$025ae050$@gvtc.com> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4940B7@RTC-EXCH01.RESERVE.LDS> Message-ID: <000701d3a5cc$da9ab600$8fd02200$@gvtc.com> Thanks, I too saw a 7 page preso, but no mention of 25 gig. Which one had 25gig ? -Aaron From lguillory at reservetele.com Wed Feb 14 19:55:05 2018 From: lguillory at reservetele.com (Luke Guillory) Date: Wed, 14 Feb 2018 19:55:05 +0000 Subject: 1/2u 100g Metro-E Aggregation Switch In-Reply-To: <000701d3a5cc$da9ab600$8fd02200$@gvtc.com> References: <1484757956.247738.1514522989493.JavaMail.zimbra@techcompute.net> <1678802774.272368.1514560841025.JavaMail.zimbra@techcompute.net> <000301d3a5b5$00c8f570$025ae050$@gvtc.com> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4940B7@RTC-EXCH01.RESERVE.LDS> <000701d3a5cc$da9ab600$8fd02200$@gvtc.com> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4959D5@RTC-EXCH01.RESERVE.LDS> ACX+ 5448 seems to be the 48 port 1g/10g with 4x100g Presentation I'm talking about is a 69 pager from the 2017 Global Tech Summit. Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory 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. Luke Guillory 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. . -----Original Message----- From: Aaron Gould [mailto:aaron1 at gvtc.com] Sent: Wednesday, February 14, 2018 1:49 PM To: Luke Guillory Cc: 'NANOG' Subject: RE: 1/2u 100g Metro-E Aggregation Switch Thanks, I too saw a 7 page preso, but no mention of 25 gig. Which one had 25gig ? -Aaron From juergen at jaritsch.at Wed Feb 14 21:16:01 2018 From: juergen at jaritsch.at (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=) Date: Wed, 14 Feb 2018 22:16:01 +0100 Subject: 1/2u 100g Metro-E Aggregation Switch Message-ID: <000a01d3a5d9$05f73650$11e5a2f0$@jaritsch.at> http://www.extremenetworks.com/wp-content/uploads/2014/10/ExtremeXOS_Feature _License_Requirements.pdf Page 18 - AFAIK there wasn’t THAT huge change on features since 2014 Best, JJ From alexsm at gmail.com Thu Feb 15 15:39:34 2018 From: alexsm at gmail.com (Alex Moura) Date: Thu, 15 Feb 2018 13:39:34 -0200 Subject: Looking for a L2/L3 managed switch with OpenFlow support Message-ID: Hello, We are now looking for indications for a managed top of rack switch for a network research testbed. For the last 3-4 years we have been using a product from a local (Brazilian) provider, but their OpenFlow support did not evolve in the last years, and now we are looking for a new box model that we can use from now on to install new racks or replace units without contract support that are limited to OpenFlow 1.0. We are looking for a box – it cay be a white-box – with the following features: • L2 / L3 switch • 48 Ports 1GbE UTP RJ-45 • Line rate non-blocking wire-speed for 64-byte packets • Minimum of 2 or more ports with 1Gbps mini GBIC (SFP) (support for 2x 10Gbps SFP+ is desirable, but not mandatory) • 1U 19" chassis • 110V / 220V AC Power (redundant is preferable, but not mandatory) • Support for IPv4, IPv6 and OpenFlow • Support for OpenFlow version 1.0.0 and above • Support for VLAN Tagging with simultaneous 4094 active VIDs IEEE 802.1q) • Support for Q-in-Q double tagging with EtherType 0x8100 and selective Q-in-Q • Support for VLAN translation allowing label push, pop or swap (IEEE 802.1q) • Support for Routing between VLANs (IPv4 and IPv6) • Support for management protocols (SNMP etc) • Support for debugging OpenFlow traffic in the CLI • Support for dual images for resilient firmware upgrades is desirable • Support for Secure remote management of the switch via Secure Shell (SSH) and SSL encryption • Support for SNMP versions 1, 2c, and 3 with support for SNMP Traps • Support for port mirroring • Configuration rollback feature is desirable • POE (IEEE 802.3af) is desirable, but not mandatory. Thanks, Alex From stuart at tech.org Thu Feb 15 16:28:38 2018 From: stuart at tech.org (Stephen Stuart) Date: Thu, 15 Feb 2018 16:28:38 +0000 Subject: Looking for a L2/L3 managed switch with OpenFlow support In-Reply-To: References: Message-ID: <201802151628.w1FGScxa007945@nb.tech.org> > Hello, > > We are now looking for indications for a managed top of rack switch for a > network research testbed. > For the last 3-4 years we have been using a product from a local > (Brazilian) provider, but their OpenFlow support did not evolve in the last > years, and now we are looking for a new box model that we can use from now > on to install new racks or replace units without contract support that are > limited to OpenFlow 1.0. > > We are looking for a box - it cay be a white-box - with the following > features: I suggest that you look at the switches that support the FAUCET software stack, many of which are listed here: http://docs.faucet.nz/en/latest/vendors/index.html Thanks, Stephen From g at 1337.io Thu Feb 15 17:39:33 2018 From: g at 1337.io (g at 1337.io) Date: Thu, 15 Feb 2018 09:39:33 -0800 Subject: Netzero Email Abuse In-Reply-To: <20180210181812.C1D3F6401@mx-01.viperserv.net> References: <20180210181812.C1D3F6401@mx-01.viperserv.net> Message-ID: <5a85c5d8.c5a1500a.f76a.b764SMTPIN_ADDED_MISSING@mx.google.com> Once upon a time, I worked on the SYS/NET OPS time of a United Online subsidiary. Spent a lot of time in the data centers and worked on occasion with other OPS folks from different business units. They would joke about the complaints that would come in, they do read the emails - but you have to name drop their VP of Tech to get them to do anything. Search LinkedIn or the usual channels for that name and good luck. On 2/10/18 10:18 AM, Tim Burke wrote: > Good luck... they do not have anybody clueful handling abuse. United Online's abuse is all handled by a bunch of untrained fools in a third-world country. This was as of ~5 years ago, things may have changed now, but I doubt it. > > On 2/9/18, 7:21 PM, "NANOG on behalf of Matt Hoppes" wrote: > > Could someone from Netzeros email abuse team contact me? > > Your spam notification system is spamming me and I have been unable to get ahold of anyone regarding this. > > Over the last 48 hours it has sent probably 25-30 emails to our abuse email address. All emails are the same, with the same content, and are actually a human generated email from a customer I personally know (Eg not even spam). > From eduardo at sysarmy.com.ar Thu Feb 15 18:23:35 2018 From: eduardo at sysarmy.com.ar (Eduardo Casarero) Date: Thu, 15 Feb 2018 15:23:35 -0300 Subject: someone from telecom italia (seabone.net) in the list? Message-ID: we are seeing routing issues from buenos aires to US, with routes changing to EU and back every 10 minutes. thanks. -- Eduardo Casarero Sysarmy - Organización mobile 54 911 56306373 From DHarlow at cards-tech.com Thu Feb 15 18:15:23 2018 From: DHarlow at cards-tech.com (David Harlow) Date: Thu, 15 Feb 2018 18:15:23 +0000 Subject: Anyone from NTT on the list Message-ID: <911094d5af0d4c8d9bb70bf17bae60bc@CCIEXCH01.cci.local> Can you contact me offlist for a issue? Or if someone could email me someone’s contact info.. [cid:imagef63406.PNG at a639ca52.4796e78e] David Harlow Field Technician DHarlow at cards-tech.com 11004 Manklin Meadows Lane Unit 1 Ocean Pines, MD 21811 Tel: (410) 208-3933 x3596 Web: www.cards-tech.com We run your network... So you can run your business. ® From bryan at shout.net Thu Feb 15 19:47:18 2018 From: bryan at shout.net (Bryan Holloway) Date: Thu, 15 Feb 2018 13:47:18 -0600 Subject: Anyone from NTT on the list In-Reply-To: <911094d5af0d4c8d9bb70bf17bae60bc@CCIEXCH01.cci.local> References: <911094d5af0d4c8d9bb70bf17bae60bc@CCIEXCH01.cci.local> Message-ID: <0aff18e4-b50a-d778-56f5-491c6d735e00@shout.net> NTT? Here? Pffft. Wait, I might know a guy. Name starts with a "J" and ends in "ob". On 2/15/18 12:15 PM, David Harlow wrote: > Can you contact me offlist for a issue? Or if someone could email me someone’s contact info.. > > > > [cid:imagef63406.PNG at a639ca52.4796e78e] > > David Harlow > > Field Technician > DHarlow at cards-tech.com > 11004 Manklin Meadows Lane Unit 1 > Ocean Pines, MD 21811 > Tel: (410) 208-3933 x3596 > Web: www.cards-tech.com > > We run your network... So you can run your business. ® > > > > > > > > > From job at ntt.net Thu Feb 15 19:51:57 2018 From: job at ntt.net (Job Snijders) Date: Thu, 15 Feb 2018 19:51:57 +0000 Subject: Anyone from NTT on the list In-Reply-To: <0aff18e4-b50a-d778-56f5-491c6d735e00@shout.net> References: <911094d5af0d4c8d9bb70bf17bae60bc@CCIEXCH01.cci.local> <0aff18e4-b50a-d778-56f5-491c6d735e00@shout.net> Message-ID: You can always try whispering my name three times facing West, but noc at ntt.net is a smoother running operation. Kind regards, Job From aaron1 at gvtc.com Thu Feb 15 20:01:35 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 15 Feb 2018 14:01:35 -0600 Subject: 1/2u 100g Metro-E Aggregation Switch In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4959D5@RTC-EXCH01.RESERVE.LDS> References: <1484757956.247738.1514522989493.JavaMail.zimbra@techcompute.net> <1678802774.272368.1514560841025.JavaMail.zimbra@techcompute.net> <000301d3a5b5$00c8f570$025ae050$@gvtc.com> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4940B7@RTC-EXCH01.RESERVE.LDS> <000701d3a5cc$da9ab600$8fd02200$@gvtc.com> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4959D5@RTC-EXCH01.RESERVE.LDS> Message-ID: <001801d3a697$c8e2b6d0$5aa82470$@gvtc.com> Preso I just looked at shows a spec for one of those boxes as having what appears to be break-out capability of the 100 gig interfaces to be (10's, 25's and 40's)... wondering if that would be true of those 100 gig ports on the ACX5448 as well ? if not, why not? -Aaron From tom at ninjabadger.net Fri Feb 16 12:16:23 2018 From: tom at ninjabadger.net (Tom Hill) Date: Fri, 16 Feb 2018 12:16:23 +0000 Subject: 1/2u 100g Metro-E Aggregation Switch In-Reply-To: <000501d3a5cc$ad36fd90$07a4f8b0$@gvtc.com> References: <1484757956.247738.1514522989493.JavaMail.zimbra@techcompute.net> <1678802774.272368.1514560841025.JavaMail.zimbra@techcompute.net> <000301d3a5b5$00c8f570$025ae050$@gvtc.com> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4940B7@RTC-EXCH01.RESERVE.LDS> <000501d3a5cc$ad36fd90$07a4f8b0$@gvtc.com> Message-ID: <98631adb-4b91-f16b-36a0-e98027f8381a@ninjabadger.net> On 14/02/18 19:47, Aaron Gould wrote: > What does this include ? > > 17828 (part#) - X870 MPLS Feature Pack (product name) - ExtremeXOS > X870 MPLS Feature Pack (firmware license) I was going to say, 'JFGI', but Extreme really don't make these things easy to find any more... Features in the MPLS feature pack: https://documentation.extremenetworks.com/FLR_22.4/EXOS_21_1/Feature_License_Requirements/r_feature-pack-features.shtml And MPLS configuration (scroll down for the tree on the left): https://documentation.extremenetworks.com/exos_22.4/EXOS_21_1/MPLS/mpls.shtml -- Tom From dovid at telecurve.com Fri Feb 16 18:02:44 2018 From: dovid at telecurve.com (Dovid Bender) Date: Fri, 16 Feb 2018 13:02:44 -0500 Subject: 60 Hudson Woes Message-ID: We have space with Digital Realty (aka TELX) and 60 Hudson and lately it's been a nightmare getting in. The real estate management company is having us reconsider our options. They are giving us the option to have ID badges for our employees but for anyone else that wants access we need to request it 48 hours in advance to get approval. So if we plan on having an unexpected outage and we need to have a have a vendor come on site (e.g. a Dell tech) we will need to let them know in advance. What are peoples experiences with 111 8th and 165 Halsey? We really like the connectivity options at 60 Hudson but at some point the hassle becomes not worth it. From cscora at apnic.net Fri Feb 16 18:03:08 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 17 Feb 2018 04:03:08 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180216180308.5B947C450F@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, CaribNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG 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 17 Feb, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 684637 Prefixes after maximum aggregation (per Origin AS): 265970 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 330947 Total ASes present in the Internet Routing Table: 59858 Prefixes per ASN: 11.44 Origin-only ASes present in the Internet Routing Table: 51687 Origin ASes announcing only one prefix: 22724 Transit ASes present in the Internet Routing Table: 8171 Transit-only ASes present in the Internet Routing Table: 246 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 35 Max AS path prepend of ASN (262865) 25 Prefixes from unregistered ASNs in the Routing Table: 60 Number of instances of unregistered ASNs: 65 Number of 32-bit ASNs allocated by the RIRs: 21513 Number of 32-bit ASNs visible in the Routing Table: 17291 Prefixes from 32-bit ASNs in the Routing Table: 71701 Number of bogon 32-bit ASNs visible in the Routing Table: 16 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 327 Number of addresses announced to Internet: 2859150498 Equivalent to 170 /8s, 107 /16s and 44 /24s Percentage of available address space announced: 77.2 Percentage of allocated address space announced: 77.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.8 Total number of prefixes smaller than registry allocations: 226547 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 188710 Total APNIC prefixes after maximum aggregation: 53959 APNIC Deaggregation factor: 3.50 Prefixes being announced from the APNIC address blocks: 187716 Unique aggregates announced from the APNIC address blocks: 77588 APNIC Region origin ASes present in the Internet Routing Table: 8644 APNIC Prefixes per ASN: 21.72 APNIC Region origin ASes announcing only one prefix: 2446 APNIC Region transit ASes present in the Internet Routing Table: 1277 Average APNIC Region AS path length visible: 4.3 Max APNIC Region AS path length visible: 27 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3548 Number of APNIC addresses announced to Internet: 767863586 Equivalent to 45 /8s, 196 /16s and 171 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 204508 Total ARIN prefixes after maximum aggregation: 98090 ARIN Deaggregation factor: 2.08 Prefixes being announced from the ARIN address blocks: 205428 Unique aggregates announced from the ARIN address blocks: 96860 ARIN Region origin ASes present in the Internet Routing Table: 18091 ARIN Prefixes per ASN: 11.36 ARIN Region origin ASes announcing only one prefix: 6692 ARIN Region transit ASes present in the Internet Routing Table: 1802 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: 2311 Number of ARIN addresses announced to Internet: 1108954656 Equivalent to 66 /8s, 25 /16s and 78 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 185052 Total RIPE prefixes after maximum aggregation: 90426 RIPE Deaggregation factor: 2.05 Prefixes being announced from the RIPE address blocks: 181322 Unique aggregates announced from the RIPE address blocks: 109009 RIPE Region origin ASes present in the Internet Routing Table: 24892 RIPE Prefixes per ASN: 7.28 RIPE Region origin ASes announcing only one prefix: 11332 RIPE Region transit ASes present in the Internet Routing Table: 3495 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: 6670 Number of RIPE addresses announced to Internet: 713989248 Equivalent to 42 /8s, 142 /16s and 156 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 88104 Total LACNIC prefixes after maximum aggregation: 19488 LACNIC Deaggregation factor: 4.52 Prefixes being announced from the LACNIC address blocks: 89436 Unique aggregates announced from the LACNIC address blocks: 39904 LACNIC Region origin ASes present in the Internet Routing Table: 6840 LACNIC Prefixes per ASN: 13.08 LACNIC Region origin ASes announcing only one prefix: 1887 LACNIC Region transit ASes present in the Internet Routing Table: 1260 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 35 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4369 Number of LACNIC addresses announced to Internet: 172280544 Equivalent to 10 /8s, 68 /16s and 202 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 18201 Total AfriNIC prefixes after maximum aggregation: 3960 AfriNIC Deaggregation factor: 4.60 Prefixes being announced from the AfriNIC address blocks: 20408 Unique aggregates announced from the AfriNIC address blocks: 7329 AfriNIC Region origin ASes present in the Internet Routing Table: 1118 AfriNIC Prefixes per ASN: 18.25 AfriNIC Region origin ASes announcing only one prefix: 366 AfriNIC Region transit ASes present in the Internet Routing Table: 224 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 393 Number of AfriNIC addresses announced to Internet: 95677696 Equivalent to 5 /8s, 179 /16s and 237 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5436 4195 92 ERX-CERNET-BKB China Education and Rese 7545 3778 407 412 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2869 11132 770 KIXS-AS-KR Korea Telecom, KR 9829 2801 1499 540 BSNL-NIB National Internet Backbone, IN 17974 2711 934 76 TELKOMNET-AS2-AP PT Telekomunikasi Indo 7552 2635 1161 60 VIETEL-AS-AP Viettel Group, VN 9394 2629 4923 28 CTTNET China TieTong Telecommunications 45899 2587 1558 154 VNPT-AS-VN VNPT Corp, VN 9808 2181 8699 32 CMNET-GD Guangdong Mobile Communication 4755 2079 416 214 TATACOMM-AS TATA Communications formerl 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 3391 1323 86 SHAW - Shaw Communications Inc., CA 22773 3272 2987 147 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2166 405 108 MEGAPATH5-US - MegaPath Corporation, US 20115 2088 2406 435 CHARTER-NET-HKY-NC - Charter Communicat 16509 2019 4164 592 AMAZON-02 - Amazon.com, Inc., US 209 1937 5060 625 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1919 337 197 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6389 1862 3671 36 BELLSOUTH-NET-BLK - BellSouth.net Inc., 11492 1732 229 571 CABLEONE - CABLE ONE, INC., US 7018 1685 20187 1251 ATT-INTERNET4 - AT&T Services, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3520 187 21 ALJAWWALSTC-AS, SA 20940 2835 828 2054 AKAMAI-ASN1, US 12479 2538 1193 511 UNI2-AS, ES 8551 2073 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12389 2058 1862 704 ROSTELECOM-AS, RU 34984 1995 332 474 TELLCOM-AS, TR 9121 1972 1692 19 TTNET, TR 13188 1606 100 46 TRIOLAN, UA 6849 1241 355 21 UKRTELNET, UA 8402 1237 544 14 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 4159 3388 585 Uninet S.A. de C.V., MX 10620 3594 541 252 Telmex Colombia S.A., CO 11830 2642 370 66 Instituto Costarricense de Electricidad 6503 1629 437 53 Axtel, S.A.B. de C.V., MX 7303 1507 1026 191 Telecom Argentina S.A., AR 3816 1018 511 116 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 1018 2243 186 CLARO S.A., BR 6147 1002 377 27 Telefonica del Peru S.A.A., PE 11172 921 126 86 Alestra, S. de R.L. de C.V., MX 18881 906 1069 29 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1177 398 49 LINKdotNET-AS, EG 37611 802 91 8 Afrihost, ZA 36903 739 371 135 MT-MPLS, MA 36992 678 1380 37 ETISALAT-MISR, EG 8452 612 1730 18 TE-AS TE-AS, EG 24835 517 850 15 RAYA-AS, EG 29571 464 68 12 ORANGE-COTE-IVOIRE, CI 37492 451 368 78 ORANGE-, TN 15399 362 35 7 WANANCHI-, KE 37342 358 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 4538 5436 4195 92 ERX-CERNET-BKB China Education and Rese 8151 4159 3388 585 Uninet S.A. de C.V., MX 7545 3778 407 412 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3594 541 252 Telmex Colombia S.A., CO 39891 3520 187 21 ALJAWWALSTC-AS, SA 6327 3391 1323 86 SHAW - Shaw Communications Inc., CA 22773 3272 2987 147 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 4766 2869 11132 770 KIXS-AS-KR Korea Telecom, KR 20940 2835 828 2054 AKAMAI-ASN1, US 9829 2801 1499 540 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 8151 4159 3574 Uninet S.A. de C.V., MX 39891 3520 3499 ALJAWWALSTC-AS, SA 7545 3778 3366 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3594 3342 Telmex Colombia S.A., CO 6327 3391 3305 SHAW - Shaw Communications Inc., CA 22773 3272 3125 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 17974 2711 2635 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9394 2629 2601 CTTNET China TieTong Telecommunications Corpora 11830 2642 2576 Instituto Costarricense de Electricidad y Telec 7552 2635 2575 VIETEL-AS-AP Viettel Group, VN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65249 PRIVATE 5.42.234.0/23 35753 ITC ITC AS number, SA 65249 PRIVATE 5.42.234.0/24 35753 ITC ITC AS number, SA 65456 PRIVATE 31.171.126.0/23 199311 AZRT-LX Local Internet Exchang 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 65024 PRIVATE 87.103.234.0/24 39407 CHITATELECOM-AS, RU 65000 PRIVATE 95.179.2.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.3.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.69.0/24 65001 -Private Use AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.14.0/23 10247 NETLINE, ZA 14.192.50.0/23 10247 NETLINE, ZA 14.192.58.0/23 10247 NETLINE, ZA 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/23 10247 NETLINE, ZA 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.228.144.0/22 9829 BSNL-NIB National Internet Backbone, IN 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 43.251.84.0/22 133676 PNPL-AS Precious netcom pvt ltd, IN 43.251.84.0/23 133676 PNPL-AS Precious netcom pvt ltd, IN Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:15 /9:12 /10:37 /11:100 /12:290 /13:563 /14:1093 /15:1897 /16:13322 /17:7772 /18:13608 /19:25217 /20:38997 /21:45069 /22:84323 /23:68271 /24:381816 /25:840 /26:603 /27:656 /28:36 /29:20 /30:18 /31:4 /32:58 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3182 3391 SHAW - Shaw Communications Inc., CA 39891 2946 3520 ALJAWWALSTC-AS, SA 22773 2532 3272 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2060 2166 MEGAPATH5-US - MegaPath Corporation, US 11830 1988 2642 Instituto Costarricense de Electricidad y Telec 30036 1675 1919 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1589 3594 Telmex Colombia S.A., CO 8551 1536 2073 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11492 1514 1732 CABLEONE - CABLE ONE, INC., US 9121 1457 1972 TTNET, TR Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1535 2:843 4:18 5:2650 6:59 8:1102 9:1 12:1849 13:203 14:1754 15:26 16:3 17:182 18:67 20:49 21:3 23:2540 24:2065 25:2 27:2354 31:1944 32:88 35:24 36:491 37:2609 38:1463 39:245 40:101 41:2986 42:453 43:1959 44:96 45:3706 46:2988 47:200 49:1380 50:1043 51:47 52:957 54:351 55:6 56:7 57:42 58:1565 59:1037 60:388 61:2061 62:1794 63:1810 64:4720 65:2228 66:4519 67:2342 68:1174 69:3196 70:1134 71:560 72:2092 74:2668 75:398 76:424 77:1553 78:1669 79:1821 80:1472 81:1410 82:1077 83:786 84:1007 85:2007 86:559 87:1247 88:917 89:2316 90:183 91:6271 92:1168 93:2382 94:2408 95:2730 96:644 97:359 98:929 99:120 100:79 101:1515 102:26 103:17197 104:3275 105:216 106:533 107:1801 108:707 109:2695 110:1580 111:1779 112:1314 113:1350 114:1117 115:1634 116:1641 117:1710 118:2024 119:1674 120:964 121:1063 122:2461 123:1797 124:1456 125:1849 128:988 129:603 130:442 131:1626 132:610 133:194 134:1001 135:226 136:438 137:474 138:1961 139:563 140:397 141:681 142:776 143:974 144:792 145:453 146:1162 147:742 148:1535 149:700 150:735 151:988 152:757 153:309 154:1015 155:754 156:833 157:772 158:619 159:1612 160:865 161:739 162:2543 163:526 164:1017 165:1368 166:397 167:1387 168:3102 169:801 170:3647 171:413 172:1032 173:1916 174:876 175:760 176:1919 177:3915 178:2416 179:1185 180:2238 181:2131 182:2462 183:1122 184:907 185:12537 186:3491 187:2321 188:2667 189:1951 190:8071 191:1349 192:9779 193:5885 194:4775 195:3986 196:2367 197:1426 198:5529 199:5898 200:7301 201:4889 202:10365 203:10027 204:4537 205:2862 206:3055 207:3114 208:3994 209:3934 210:4001 211:2129 212:2972 213:2623 214:895 215:61 216:5857 217:2124 218:898 219:621 220:1725 221:996 222:1054 223:1241 End of report From ESundberg at nitelusa.com Fri Feb 16 19:50:38 2018 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Fri, 16 Feb 2018 19:50:38 +0000 Subject: 60 Hudson Woes In-Reply-To: References: Message-ID: We just had an issue where cisco was going to replace a power tray in our router at 60 hudson, we are also at telx. Cisco contracts with IBM for this. The building is now checking that all 3rd party vendors have an existing Certificate of insurance (COI). This take 48 hours to get put in there system... So now we are forced to use telx smarthands if it's under 48 hours or weekends -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dovid Bender Sent: Friday, February 16, 2018 12:03 PM To: NANOG Subject: 60 Hudson Woes We have space with Digital Realty (aka TELX) and 60 Hudson and lately it's been a nightmare getting in. The real estate management company is having us reconsider our options. They are giving us the option to have ID badges for our employees but for anyone else that wants access we need to request it 48 hours in advance to get approval. So if we plan on having an unexpected outage and we need to have a have a vendor come on site (e.g. a Dell tech) we will need to let them know in advance. What are peoples experiences with 111 8th and 165 Halsey? We really like the connectivity options at 60 Hudson but at some point the hassle becomes not worth it. From uwcableguy at gmail.com Fri Feb 16 21:11:23 2018 From: uwcableguy at gmail.com (Ben Bartsch) Date: Fri, 16 Feb 2018 15:11:23 -0600 Subject: Anybody with experience with MT IS-IS on multi-vendor integration - JunOS MX to Dell OS9 Z9100 Message-ID: We are a small transit provider with a Juniper backbone running multi-topology IS-IS in a single area with a very small number of JunOS devices (less than 15 devices). We are attempting to integrate some 100 Gbps top of rack Dell (Force10) switches to do some backhaul in our metro areas. The end game is to use a full feature OS like IPInfusion OCNos or similar and stand up carrier services (VPWS, VPLS, L3VPN). Until we select our OS, we are stuck running Dell OS9 which is a very feature limited. We are struggling with getting the IS-IS routes for management to remain stable. We've found issues with CSNP timers and defaults, graceful-restart, network point-to-point, and re-using VLAN IDs in separate parts of the network in the same IS-IS area. We have Juniper TAC, Dell TAC, and Dell development engaged and seem to be making progress, but I'm still curious if anyone out there has any firsthand experience with DellOS9 and JunOS with MT IS-IS. I will be at NANOG 72 next week and would love to speak to anyone about this issue. I am also interested in learning more about experience with MT IS-IS and other IGPs. If anyone is willing to share experiences via email or at NANOG next week, please email me on or off list. Thanks in advance, ben From JGrady at 365datacenters.com Fri Feb 16 18:38:37 2018 From: JGrady at 365datacenters.com (Jim Grady) Date: Fri, 16 Feb 2018 18:38:37 +0000 Subject: 60 Hudson Woes In-Reply-To: References: Message-ID: <79ED0743-1382-4AC3-85FB-BE853F481B00@365datacenters.com> We do not have all of the carriers you can get at 60 Hudson but we do have many at 365 Data Centers at 65 Broadway and I can guarantee you won’t have the headaches from 60 Hud, and you can probably save money. Let me know if you have any interest and we can discuss your requirements so I can get you a quote. Best, Jim Sent from my iPhone > On Feb 16, 2018, at 1:04 PM, Dovid Bender wrote: > > We have space with Digital Realty (aka TELX) and 60 Hudson and lately it's > been a nightmare getting in. The real estate management company is having > us reconsider our options. They are giving us the option to have ID badges > for our employees but for anyone else that wants access we need to request > it 48 hours in advance to get approval. So if we plan on having an > unexpected outage and we need to have a have a vendor come on site (e.g. a > Dell tech) we will need to let them know in advance. > > What are peoples experiences with 111 8th and 165 Halsey? We really like > the connectivity options at 60 Hudson but at some point the hassle becomes > not worth it. > From nanog at ics-il.net Fri Feb 16 22:17:15 2018 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 16 Feb 2018 16:17:15 -0600 (CST) Subject: 60 Hudson Woes In-Reply-To: <79ED0743-1382-4AC3-85FB-BE853F481B00@365datacenters.com> References: <79ED0743-1382-4AC3-85FB-BE853F481B00@365datacenters.com> Message-ID: <964528763.10780.1518819432744.JavaMail.mhammett@ThunderFuck> I will generally prefer the smaller operators in a market for many reasons, but most relevant to this situation is that they simply don't have the market power to be jerks. They may want to be nice, but they have to be nice, else people go elsewhere. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Jim Grady" To: "Dovid Bender" Cc: "NANOG" Sent: Friday, February 16, 2018 12:38:37 PM Subject: Re: 60 Hudson Woes We do not have all of the carriers you can get at 60 Hudson but we do have many at 365 Data Centers at 65 Broadway and I can guarantee you won’t have the headaches from 60 Hud, and you can probably save money. Let me know if you have any interest and we can discuss your requirements so I can get you a quote. Best, Jim Sent from my iPhone > On Feb 16, 2018, at 1:04 PM, Dovid Bender wrote: > > We have space with Digital Realty (aka TELX) and 60 Hudson and lately it's > been a nightmare getting in. The real estate management company is having > us reconsider our options. They are giving us the option to have ID badges > for our employees but for anyone else that wants access we need to request > it 48 hours in advance to get approval. So if we plan on having an > unexpected outage and we need to have a have a vendor come on site (e.g. a > Dell tech) we will need to let them know in advance. > > What are peoples experiences with 111 8th and 165 Halsey? We really like > the connectivity options at 60 Hudson but at some point the hassle becomes > not worth it. > From ml at knight-networks.com Sat Feb 17 22:07:11 2018 From: ml at knight-networks.com (Brian Knight) Date: Sat, 17 Feb 2018 16:07:11 -0600 Subject: 60 Hudson Woes In-Reply-To: References: Message-ID: As the engineer working on that Cisco / IBM issue Erik mentioned... ;) I was able to get walk-up, same-day access to the building for myself a few weeks ago (as a customer of DR) and didn’t get my hand slapped for it. DR just created the access ticket with the building and that was enough. It took about 20 minutes start to finish. But if a vendor tech needs access, they need a COI generated, and that must be sent to the building ahead of time via DR. Otherwise they will be turned away. The COI was the biggest blocker. A 48 hour lead time for the visit didn’t seem to be enforced, not by Digital Realty anyway. Also, I tried to arrange for permanent building key card access while I was there. But the key cards must be used at least once every 60 days, otherwise they are deactivated. I decided just to arrange for access ahead of time since I don’t visit often. -Brian > On Feb 16, 2018, at 1:50 PM, Erik Sundberg wrote: > > We just had an issue where cisco was going to replace a power tray in our router at 60 hudson, we are also at telx. Cisco contracts with IBM for this. The building is now checking that all 3rd party vendors have an existing Certificate of insurance (COI). This take 48 hours to get put in there system... > > So now we are forced to use telx smarthands if it's under 48 hours or weekends > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dovid Bender > Sent: Friday, February 16, 2018 12:03 PM > To: NANOG > Subject: 60 Hudson Woes > > We have space with Digital Realty (aka TELX) and 60 Hudson and lately it's been a nightmare getting in. The real estate management company is having us reconsider our options. They are giving us the option to have ID badges for our employees but for anyone else that wants access we need to request it 48 hours in advance to get approval. So if we plan on having an unexpected outage and we need to have a have a vendor come on site (e.g. a Dell tech) we will need to let them know in advance. > > What are peoples experiences with 111 8th and 165 Halsey? We really like the connectivity options at 60 Hudson but at some point the hassle becomes not worth it. From drew at gothambus.com Sun Feb 18 15:55:01 2018 From: drew at gothambus.com (Drew Linsalata) Date: Sun, 18 Feb 2018 10:55:01 -0500 Subject: Anyone aware of status in Oaxaca since the quake? Message-ID: <0d503739-8178-4be8-ab0e-15cfb7279971@gothambus.com> Sorry to use the list this way but information is hard to come by. I'm wondering if anyone has any insight with respect to the power and data/cell situation in Oaxaca Mexico since the quake. Off list replies are fine if that's better. From dovid at telecurve.com Mon Feb 19 04:54:28 2018 From: dovid at telecurve.com (Dovid Bender) Date: Sun, 18 Feb 2018 23:54:28 -0500 Subject: 60 Hudson Woes In-Reply-To: <964528763.10780.1518819432744.JavaMail.mhammett@ThunderFuck> References: <79ED0743-1382-4AC3-85FB-BE853F481B00@365datacenters.com> <964528763.10780.1518819432744.JavaMail.mhammett@ThunderFuck> Message-ID: While dealing with DR is not always fun in this case it isn't their fault. The building management is the one creating the issues. I used to have no issues and now every time it seems like there are new rules to get in. Over all it seems that everyone has high praise for 165 Halsey so I will start there. On Fri, Feb 16, 2018 at 5:17 PM, Mike Hammett wrote: > I will generally prefer the smaller operators in a market for many > reasons, but most relevant to this situation is that they simply don't have > the market power to be jerks. They may want to be nice, but they have to be > nice, else people go elsewhere. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Jim Grady" > To: "Dovid Bender" > Cc: "NANOG" > Sent: Friday, February 16, 2018 12:38:37 PM > Subject: Re: 60 Hudson Woes > > We do not have all of the carriers you can get at 60 Hudson but we do have > many at 365 Data Centers at 65 Broadway and I can guarantee you won’t have > the headaches from 60 Hud, and you can probably save money. Let me know if > you have any interest and we can discuss your requirements so I can get you > a quote. > > Best, > > Jim > > Sent from my iPhone > > > On Feb 16, 2018, at 1:04 PM, Dovid Bender wrote: > > > > We have space with Digital Realty (aka TELX) and 60 Hudson and lately > it's > > been a nightmare getting in. The real estate management company is having > > us reconsider our options. They are giving us the option to have ID > badges > > for our employees but for anyone else that wants access we need to > request > > it 48 hours in advance to get approval. So if we plan on having an > > unexpected outage and we need to have a have a vendor come on site (e.g. > a > > Dell tech) we will need to let them know in advance. > > > > What are peoples experiences with 111 8th and 165 Halsey? We really like > > the connectivity options at 60 Hudson but at some point the hassle > becomes > > not worth it. > > > > From web at typo.org Mon Feb 19 05:46:24 2018 From: web at typo.org (Wayne Bouchard) Date: Sun, 18 Feb 2018 22:46:24 -0700 Subject: 60 Hudson Woes In-Reply-To: References: <79ED0743-1382-4AC3-85FB-BE853F481B00@365datacenters.com> <964528763.10780.1518819432744.JavaMail.mhammett@ThunderFuck> Message-ID: <20180219054624.GA6899@spider.typo.org> Yeah, with the demise of 111 8th as a carrier hotel, Halsey seems to be becoming a default for many. My prediction is that you won't have trouble getting to who you want to there. Thought I would be nice to have another facility outside of Manhattan as an alternate point in which to congregate. On Sun, Feb 18, 2018 at 11:54:28PM -0500, Dovid Bender wrote: > While dealing with DR is not always fun in this case it isn't their fault. > The building management is the one creating the issues. I used to have no > issues and now every time it seems like there are new rules to get in. Over > all it seems that everyone has high praise for 165 Halsey so I will start > there. > > > On Fri, Feb 16, 2018 at 5:17 PM, Mike Hammett wrote: > > > I will generally prefer the smaller operators in a market for many > > reasons, but most relevant to this situation is that they simply don't have > > the market power to be jerks. They may want to be nice, but they have to be > > nice, else people go elsewhere. > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > > ----- Original Message ----- > > > > From: "Jim Grady" > > To: "Dovid Bender" > > Cc: "NANOG" > > Sent: Friday, February 16, 2018 12:38:37 PM > > Subject: Re: 60 Hudson Woes > > > > We do not have all of the carriers you can get at 60 Hudson but we do have > > many at 365 Data Centers at 65 Broadway and I can guarantee you won???t have > > the headaches from 60 Hud, and you can probably save money. Let me know if > > you have any interest and we can discuss your requirements so I can get you > > a quote. > > > > Best, > > > > Jim > > > > Sent from my iPhone > > > > > On Feb 16, 2018, at 1:04 PM, Dovid Bender wrote: > > > > > > We have space with Digital Realty (aka TELX) and 60 Hudson and lately > > it's > > > been a nightmare getting in. The real estate management company is having > > > us reconsider our options. They are giving us the option to have ID > > badges > > > for our employees but for anyone else that wants access we need to > > request > > > it 48 hours in advance to get approval. So if we plan on having an > > > unexpected outage and we need to have a have a vendor come on site (e.g. > > a > > > Dell tech) we will need to let them know in advance. > > > > > > What are peoples experiences with 111 8th and 165 Halsey? We really like > > > the connectivity options at 60 Hudson but at some point the hassle > > becomes > > > not worth it. > > > > > > > --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From web at typo.org Mon Feb 19 05:49:52 2018 From: web at typo.org (Wayne Bouchard) Date: Sun, 18 Feb 2018 22:49:52 -0700 Subject: 60 Hudson Woes In-Reply-To: References: Message-ID: <20180219054952.GB6899@spider.typo.org> Yeah, this is another issue I've been seeing pop up more in the last several years. Apparently there have been a few incidents in the past that caused accountability problems so now any outside vendor is required to have a COI on file to do work in many colos (irespective of colo operator). That can take a bit to do if they're a new contractor. Once on file, a renewal is usually an easy thing but getting the initial paperwork done can take time. After that, they can come and go as they please, so long as access tickets are duly arranged. -Wayne On Sat, Feb 17, 2018 at 04:07:11PM -0600, Brian Knight wrote: > As the engineer working on that Cisco / IBM issue Erik mentioned... ;) > > I was able to get walk-up, same-day access to the building for myself a few weeks ago (as a customer of DR) and didn???t get my hand slapped for it. DR just created the access ticket with the building and that was enough. It took about 20 minutes start to finish. > > But if a vendor tech needs access, they need a COI generated, and that must be sent to the building ahead of time via DR. Otherwise they will be turned away. > > The COI was the biggest blocker. A 48 hour lead time for the visit didn???t seem to be enforced, not by Digital Realty anyway. > > Also, I tried to arrange for permanent building key card access while I was there. But the key cards must be used at least once every 60 days, otherwise they are deactivated. I decided just to arrange for access ahead of time since I don???t visit often. > > -Brian > > > On Feb 16, 2018, at 1:50 PM, Erik Sundberg wrote: > > > > We just had an issue where cisco was going to replace a power tray in our router at 60 hudson, we are also at telx. Cisco contracts with IBM for this. The building is now checking that all 3rd party vendors have an existing Certificate of insurance (COI). This take 48 hours to get put in there system... > > > > So now we are forced to use telx smarthands if it's under 48 hours or weekends > > > > > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dovid Bender > > Sent: Friday, February 16, 2018 12:03 PM > > To: NANOG > > Subject: 60 Hudson Woes > > > > We have space with Digital Realty (aka TELX) and 60 Hudson and lately it's been a nightmare getting in. The real estate management company is having us reconsider our options. They are giving us the option to have ID badges for our employees but for anyone else that wants access we need to request it 48 hours in advance to get approval. So if we plan on having an unexpected outage and we need to have a have a vendor come on site (e.g. a Dell tech) we will need to let them know in advance. > > > > What are peoples experiences with 111 8th and 165 Halsey? We really like the connectivity options at 60 Hudson but at some point the hassle becomes not worth it. > --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From stankiewicz at njedge.net Mon Feb 19 13:21:43 2018 From: stankiewicz at njedge.net (James Stankiewicz) Date: Mon, 19 Feb 2018 08:21:43 -0500 Subject: 60 Hudson Woes In-Reply-To: References: Message-ID: Halsey Street is outstanding,,great staff and is the place to be!! On Sat, Feb 17, 2018 at 5:07 PM, Brian Knight wrote: > As the engineer working on that Cisco / IBM issue Erik mentioned... ;) > > I was able to get walk-up, same-day access to the building for myself a > few weeks ago (as a customer of DR) and didn’t get my hand slapped for it. > DR just created the access ticket with the building and that was enough. It > took about 20 minutes start to finish. > > But if a vendor tech needs access, they need a COI generated, and that > must be sent to the building ahead of time via DR. Otherwise they will be > turned away. > > The COI was the biggest blocker. A 48 hour lead time for the visit didn’t > seem to be enforced, not by Digital Realty anyway. > > Also, I tried to arrange for permanent building key card access while I > was there. But the key cards must be used at least once every 60 days, > otherwise they are deactivated. I decided just to arrange for access ahead > of time since I don’t visit often. > > -Brian > > > On Feb 16, 2018, at 1:50 PM, Erik Sundberg > wrote: > > > > We just had an issue where cisco was going to replace a power tray in > our router at 60 hudson, we are also at telx. Cisco contracts with IBM for > this. The building is now checking that all 3rd party vendors have an > existing Certificate of insurance (COI). This take 48 hours to get put in > there system... > > > > So now we are forced to use telx smarthands if it's under 48 hours or > weekends > > > > > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dovid Bender > > Sent: Friday, February 16, 2018 12:03 PM > > To: NANOG > > Subject: 60 Hudson Woes > > > > We have space with Digital Realty (aka TELX) and 60 Hudson and lately > it's been a nightmare getting in. The real estate management company is > having us reconsider our options. They are giving us the option to have ID > badges for our employees but for anyone else that wants access we need to > request it 48 hours in advance to get approval. So if we plan on having an > unexpected outage and we need to have a have a vendor come on site (e.g. a > Dell tech) we will need to let them know in advance. > > > > What are peoples experiences with 111 8th and 165 Halsey? We really > like the connectivity options at 60 Hudson but at some point the hassle > becomes not worth it. > > -- *Jim Stankiewicz* *Principal Network Architect* *NJEdge* *W:855.832.EDGE(3343)* *c:201.306.4409* From dovid at telecurve.com Tue Feb 20 15:49:35 2018 From: dovid at telecurve.com (Dovid Bender) Date: Tue, 20 Feb 2018 10:49:35 -0500 Subject: 60 Hudson Woes In-Reply-To: References: Message-ID: What about remote hands? What I like about DR is their staff levels and resources should there be a storm etc. they are fully staff. I rarely use their remote hands but when I do they are golden. They also have a great record. On Mon, Feb 19, 2018 at 8:21 AM, James Stankiewicz wrote: > Halsey Street is outstanding,,great staff and is the place to be!! > > On Sat, Feb 17, 2018 at 5:07 PM, Brian Knight > wrote: > > > As the engineer working on that Cisco / IBM issue Erik mentioned... ;) > > > > I was able to get walk-up, same-day access to the building for myself a > > few weeks ago (as a customer of DR) and didn’t get my hand slapped for > it. > > DR just created the access ticket with the building and that was enough. > It > > took about 20 minutes start to finish. > > > > But if a vendor tech needs access, they need a COI generated, and that > > must be sent to the building ahead of time via DR. Otherwise they will be > > turned away. > > > > The COI was the biggest blocker. A 48 hour lead time for the visit didn’t > > seem to be enforced, not by Digital Realty anyway. > > > > Also, I tried to arrange for permanent building key card access while I > > was there. But the key cards must be used at least once every 60 days, > > otherwise they are deactivated. I decided just to arrange for access > ahead > > of time since I don’t visit often. > > > > -Brian > > > > > On Feb 16, 2018, at 1:50 PM, Erik Sundberg > > wrote: > > > > > > We just had an issue where cisco was going to replace a power tray in > > our router at 60 hudson, we are also at telx. Cisco contracts with IBM > for > > this. The building is now checking that all 3rd party vendors have an > > existing Certificate of insurance (COI). This take 48 hours to get put in > > there system... > > > > > > So now we are forced to use telx smarthands if it's under 48 hours or > > weekends > > > > > > > > > > > > -----Original Message----- > > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dovid Bender > > > Sent: Friday, February 16, 2018 12:03 PM > > > To: NANOG > > > Subject: 60 Hudson Woes > > > > > > We have space with Digital Realty (aka TELX) and 60 Hudson and lately > > it's been a nightmare getting in. The real estate management company is > > having us reconsider our options. They are giving us the option to have > ID > > badges for our employees but for anyone else that wants access we need to > > request it 48 hours in advance to get approval. So if we plan on having > an > > unexpected outage and we need to have a have a vendor come on site (e.g. > a > > Dell tech) we will need to let them know in advance. > > > > > > What are peoples experiences with 111 8th and 165 Halsey? We really > > like the connectivity options at 60 Hudson but at some point the hassle > > becomes not worth it. > > > > > > > -- > *Jim Stankiewicz* > > *Principal Network Architect* > *NJEdge* > *W:855.832.EDGE(3343)* > *c:201.306.4409* > From CGross at ninestarconnect.com Tue Feb 20 15:54:01 2018 From: CGross at ninestarconnect.com (Chris Gross) Date: Tue, 20 Feb 2018 15:54:01 +0000 Subject: 60 Hudson Woes In-Reply-To: References: Message-ID: I feel the issue here is people are already paying for support contracts and vendors to come on site. Now there's the additional incurred cost for remote hands to handle it. If it's a situation where it's replacing a person of my internal staff to act on it, sure. But if I'm paying Dell to come in and do hardware work anyway but they can't get in, I don't want to pay that extra forced cost. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dovid Bender Sent: Tuesday, February 20, 2018 10:50 AM To: James Stankiewicz Cc: NANOG Subject: Re: 60 Hudson Woes What about remote hands? What I like about DR is their staff levels and resources should there be a storm etc. they are fully staff. I rarely use their remote hands but when I do they are golden. They also have a great record. On Mon, Feb 19, 2018 at 8:21 AM, James Stankiewicz wrote: > Halsey Street is outstanding,,great staff and is the place to be!! > > On Sat, Feb 17, 2018 at 5:07 PM, Brian Knight > wrote: > > > As the engineer working on that Cisco / IBM issue Erik mentioned... > > ;) > > > > I was able to get walk-up, same-day access to the building for > > myself a few weeks ago (as a customer of DR) and didn’t get my hand > > slapped for > it. > > DR just created the access ticket with the building and that was enough. > It > > took about 20 minutes start to finish. > > > > But if a vendor tech needs access, they need a COI generated, and > > that must be sent to the building ahead of time via DR. Otherwise > > they will be turned away. > > > > The COI was the biggest blocker. A 48 hour lead time for the visit > > didn’t seem to be enforced, not by Digital Realty anyway. > > > > Also, I tried to arrange for permanent building key card access > > while I was there. But the key cards must be used at least once > > every 60 days, otherwise they are deactivated. I decided just to > > arrange for access > ahead > > of time since I don’t visit often. > > > > -Brian > > > > > On Feb 16, 2018, at 1:50 PM, Erik Sundberg > > > > > wrote: > > > > > > We just had an issue where cisco was going to replace a power tray > > > in > > our router at 60 hudson, we are also at telx. Cisco contracts with > > IBM > for > > this. The building is now checking that all 3rd party vendors have > > an existing Certificate of insurance (COI). This take 48 hours to > > get put in there system... > > > > > > So now we are forced to use telx smarthands if it's under 48 hours > > > or > > weekends > > > > > > > > > > > > -----Original Message----- > > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dovid > > > Bender > > > Sent: Friday, February 16, 2018 12:03 PM > > > To: NANOG > > > Subject: 60 Hudson Woes > > > > > > We have space with Digital Realty (aka TELX) and 60 Hudson and > > > lately > > it's been a nightmare getting in. The real estate management company > > is having us reconsider our options. They are giving us the option > > to have > ID > > badges for our employees but for anyone else that wants access we > > need to request it 48 hours in advance to get approval. So if we > > plan on having > an > > unexpected outage and we need to have a have a vendor come on site (e.g. > a > > Dell tech) we will need to let them know in advance. > > > > > > What are peoples experiences with 111 8th and 165 Halsey? We > > > really > > like the connectivity options at 60 Hudson but at some point the > > hassle becomes not worth it. > > > > > > > -- > *Jim Stankiewicz* > > *Principal Network Architect* > *NJEdge* > *W:855.832.EDGE(3343)* > *c:201.306.4409* > From izaac at setec.org Tue Feb 20 16:25:13 2018 From: izaac at setec.org (Izaac) Date: Tue, 20 Feb 2018 11:25:13 -0500 Subject: 60 Hudson Woes In-Reply-To: References: Message-ID: <20180220T161038Z@localhost> On Fri, Feb 16, 2018 at 01:02:44PM -0500, Dovid Bender wrote: > 111 8th This is a non-option. Google has been aggressive in removing non-Google tenants -- both telecom and office. -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__ From sean at donelan.com Tue Feb 20 17:01:49 2018 From: sean at donelan.com (Sean Donelan) Date: Tue, 20 Feb 2018 12:01:49 -0500 (EST) Subject: Reminer: FCC seeks comments on 2017 hurricane season respons In-Reply-To: References: Message-ID: The FCC has decided not to extend the deadline for hurricane season comments past February 21, 2018. If you have anything to say, get you comments in by Wednesday. http://www.insideradio.com/free/no-time-to-waste-fcc-keeps-hurricane-inquiry-timeline/article_794d21ac-160c-11e8-b98c-6755161a4f0b.html On Thu, 25 Jan 2018, Sean Donelan wrote: > Just a reminder, the Federal Communications Committee is still collecting > comments on the 2017 hurricane season. > > https://apps.fcc.gov/edocs_public/attachmatch/DA-17-1180A1.pdf > > PUBLIC SAFETY AND HOMELAND SECURITY BUREAU SEEKS COMMENT ON > RESPONSE EFFORTS UNDERTAKEN DURING 2017 HURRICANE SEASON > PS Docket No. 17-344 > Comments Due: January 22, 2018 > Reply Comments Due: February 21, 2018 From rod.beck at unitedcablecompany.com Tue Feb 20 17:08:43 2018 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Tue, 20 Feb 2018 17:08:43 +0000 Subject: 60 Hudson Woes In-Reply-To: References: , Message-ID: I thought 165 Halsey had high riser expenses. However, I fully agree that 165 Halsey appears to be indispensable. Does anyone know how much a dark fiber pair from 165 Halsey to 60 Hudson would be on a 5 year lease or 15 year IRU? Regards, Roderick. ________________________________ From: NANOG on behalf of Dovid Bender Sent: Tuesday, February 20, 2018 4:49 PM To: James Stankiewicz Cc: NANOG Subject: Re: 60 Hudson Woes What about remote hands? What I like about DR is their staff levels and resources should there be a storm etc. they are fully staff. I rarely use their remote hands but when I do they are golden. They also have a great record. On Mon, Feb 19, 2018 at 8:21 AM, James Stankiewicz wrote: > Halsey Street is outstanding,,great staff and is the place to be!! > > On Sat, Feb 17, 2018 at 5:07 PM, Brian Knight > wrote: > > > As the engineer working on that Cisco / IBM issue Erik mentioned... ;) > > > > I was able to get walk-up, same-day access to the building for myself a > > few weeks ago (as a customer of DR) and didn’t get my hand slapped for > it. > > DR just created the access ticket with the building and that was enough. > It > > took about 20 minutes start to finish. > > > > But if a vendor tech needs access, they need a COI generated, and that > > must be sent to the building ahead of time via DR. Otherwise they will be > > turned away. > > > > The COI was the biggest blocker. A 48 hour lead time for the visit didn’t > > seem to be enforced, not by Digital Realty anyway. > > > > Also, I tried to arrange for permanent building key card access while I > > was there. But the key cards must be used at least once every 60 days, > > otherwise they are deactivated. I decided just to arrange for access > ahead > > of time since I don’t visit often. > > > > -Brian > > > > > On Feb 16, 2018, at 1:50 PM, Erik Sundberg > > wrote: > > > > > > We just had an issue where cisco was going to replace a power tray in > > our router at 60 hudson, we are also at telx. Cisco contracts with IBM > for > > this. The building is now checking that all 3rd party vendors have an > > existing Certificate of insurance (COI). This take 48 hours to get put in > > there system... > > > > > > So now we are forced to use telx smarthands if it's under 48 hours or > > weekends > > > > > > > > > > > > -----Original Message----- > > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dovid Bender > > > Sent: Friday, February 16, 2018 12:03 PM > > > To: NANOG > > > Subject: 60 Hudson Woes > > > > > > We have space with Digital Realty (aka TELX) and 60 Hudson and lately > > it's been a nightmare getting in. The real estate management company is > > having us reconsider our options. They are giving us the option to have > ID > > badges for our employees but for anyone else that wants access we need to > > request it 48 hours in advance to get approval. So if we plan on having > an > > unexpected outage and we need to have a have a vendor come on site (e.g. > a > > Dell tech) we will need to let them know in advance. > > > > > > What are peoples experiences with 111 8th and 165 Halsey? We really > > like the connectivity options at 60 Hudson but at some point the hassle > > becomes not worth it. > > > > > > > -- > *Jim Stankiewicz* > > *Principal Network Architect* > *NJEdge* > *W:855.832.EDGE(3343)* > *c:201.306.4409* > From md at bts.sk Wed Feb 21 08:03:03 2018 From: md at bts.sk (=?UTF-8?Q?Marian_=C4=8Eurkovi=C4=8D?=) Date: Wed, 21 Feb 2018 09:03:03 +0100 Subject: Severe packet loss Amazon AWS->Telia Message-ID: <20180221075139.M16798@bts.sk> Hi, we're experiencing severe packet loss for downloads from Amazon AWS via Telia network, tcpdump regularly shows multiple missing packets triggering SACKs like this: 08:33:48.935415 IP 147.175.167.x.57668 > 54.231.33.x.443: Flags [.], ack 1051088, win 16384, options [nop,nop,sack 4 {1066840:1068272}{1063976:1065408}{1059680:1062544}{1056816:1058248}], length 0 Any ideas? Thanks, M. From tom.kac at gmail.com Wed Feb 21 15:32:34 2018 From: tom.kac at gmail.com (Tom Kacprzynski) Date: Wed, 21 Feb 2018 09:32:34 -0600 Subject: Call for Presentations - CHI-NOG 08 (May 10th) Message-ID: CHI-NOG 08 - (Chicago Network Operators Group) May 10th 2018, Chicago, IL The Chicago Network Operators Group (CHI-NOG) is a vendor neutral organization. Our goal is to create a regional community of network professionals by presenting the latest technology trends, enabling collaboration and providing networking opportunities. CHI-NOG will be hosting its eight annual conference on May 10th, 2018 in downtown Chicago. For more information on the conference please see event's page ( http://chinog.org/chi-nog-08/). The CHI-NOG Program Committee is seeking proposals for presentations on relevant networking technologies with the focus on the following topics: * Network Automation/ DevOps * Interconnection/Peering * Low Latency Networks/Financial Networks * Network Security * Academic Research in Networking and Related Infrastructure Fields. * Internet Monitoring * Network Analytics * Advanced BGP/MPLS Technologies * Optical Networking/Data Center Interconnect * Content Delivery Networks (CDNs) * Software Defined Networking * Cloud Networking Technologies * Network Traffic Engineering * Open Source Networking Tools * Data Center Fabric * Wireless * IPv6 Session Format Each presentation is 30 minutes, which includes a question and answer time. The duration can be extended per individual request to 60 minutes and will be considered by the program committee. Presentations should not contain any marketing material and should avoid discussion of commercial products but rather focus on the underlying technology. Key Dates 3/19/2018 - Presentation Abstract Submission Deadline 3/23/2018 - Program Committee's Selection Decision 4/15/2018 - Full Presentation Slides Submission Deadline 5/10/2018 - Conference Submission Please submit presentation’s abstract proposal by filling out the submission form at http://chinog.org/chi-nog-08/abstract-submission/ . Once your presentation is selected please provide the program committee with your photo and a short bio for web publication. All accepted speakers will receive complimentary tickets to the conference. For past presentation please see the archives at http://chinog.org/presentation-archive/. The program committee is looking forward to your submission and attendance. From ahebert at pubnix.net Wed Feb 21 15:38:18 2018 From: ahebert at pubnix.net (Alain Hebert) Date: Wed, 21 Feb 2018 10:38:18 -0500 Subject: sFlow/NetFlow Weathermap Message-ID: <6a8c52a7-8270-002f-c94c-cb5d93fb30ef@pubnix.net>     Hi,     We're looking for suggestion for a "cost effective" sFlow/NetFlow solution with dynamic Weathermap for a MAN.     As the usual most open source solution got grabbed by corporation and put behind paywall without much development.     ntopng seems to be a good candidate we might try it with a site but with when your basic interconnect are 40Gb... that ain't gonna fly.     Thanks. -- ----- 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 From luke at flem.io Wed Feb 21 09:39:33 2018 From: luke at flem.io (Luke) Date: Wed, 21 Feb 2018 20:39:33 +1100 Subject: Severe packet loss Amazon AWS->Telia In-Reply-To: <20180221075139.M16798@bts.sk> References: <20180221075139.M16798@bts.sk> Message-ID: <19512E63-9F78-4280-91CC-A43BC923A186@flem.io> > Any ideas? 1. Contact their NOC. amzn-noc-contact at amazon.com 2. Provide a traceroute and MTR 3. Provide a pingable source IP From victor.holguin at pricetravel.com Wed Feb 21 16:17:29 2018 From: victor.holguin at pricetravel.com (=?utf-8?B?VsOtY3RvciBFZHVhcmRvIEhvbGd1w61uIFDDqXJleg==?=) Date: Wed, 21 Feb 2018 16:17:29 +0000 Subject: sFlow/NetFlow Weathermap In-Reply-To: <6a8c52a7-8270-002f-c94c-cb5d93fb30ef@pubnix.net> References: <6a8c52a7-8270-002f-c94c-cb5d93fb30ef@pubnix.net> Message-ID: Hi, If you want all open source, there are a couple of options: Cacti + weathermap - native-ish integration Librenms + weathermap - This one doesn't have netflow/sflow but is based on interface's bandwidth (SNMP) Nfdump + weathermap - you would have to integrate it yourselves and probably use something like ELK stack for dashboards. Regards, Víctor Holguín -----Mensaje original----- De: NANOG [mailto:nanog-bounces+victor.holguin=pricetravel.com at nanog.org] En nombre de Alain Hebert Enviado el: miércoles, 21 de febrero de 2018 10:38 a. m. Para: 'NANOG list' Asunto: sFlow/NetFlow Weathermap     Hi,     We're looking for suggestion for a "cost effective" sFlow/NetFlow solution with dynamic Weathermap for a MAN.     As the usual most open source solution got grabbed by corporation and put behind paywall without much development.     ntopng seems to be a good candidate we might try it with a site but with when your basic interconnect are 40Gb... that ain't gonna fly.     Thanks. -- ----- 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 From apnet18 at gmail.com Wed Feb 21 17:34:52 2018 From: apnet18 at gmail.com (ap net) Date: Wed, 21 Feb 2018 09:34:52 -0800 Subject: [CFP] 2nd Asia-Pacific Workshop on Networking (APNet 2018) Message-ID: ************************************************************ ****************** CALL FOR PAPERS APNet 2018 The Second Asia-Pacific Workshop on Networking Beijing, China, August 2--3, 2018 *https://conferences.sigcomm.org/events/apnet2018/index.html * ************************************************************ ****************** *Overview* The Second Asia-Pacific Workshop on Networking (APNet’18) aims to bring together the very best researchers in computer networking and systems across the Asia-Pacific region and the global community to a live forum discussing and debating innovative ideas at their early stages. The mission of APNet is that promising but not-yet-mature ideas can receive timely feedback from experienced researchers, shaping them into major conferences such as SIGCOMM, NSDI, SOSP, OSDI, MobiCom, CoNEXT and so on. *Program Committee* *General Chairs* Dan Li (Tsinghua University, China) K. K. Ramakrishnan (University of California, Riverside, USA) *PC Co-Chairs* Mosharaf Chowdhury (University of Michigan, USA) Kun Tan (Huawei, China) *Steering Committee* Suman Banerjee (University of Wisconsin, USA) Kai Chen (HKUST, Hong Kong SAR), Co-Chair Albert Greenberg (Microsoft, USA) Jitu Padhye (Microsoft, USA) KyoungSoo Park (KAIST, South Korea) Kun Tan (Huawei, China), Co-Chair Minlan Yu (Yale University, USA) Lin Zhong (Rice University, USA) ********************************************************** We invite submissions of short papers (up to 6 pages, including references) on a wide range of networking research, including, but not limited to: • Network architectures and algorithms • Cloud and wide-area networking systems & infrastructure • Networking support for applications • Operating system support for networking • Kernel-bypass and RDMA networking and applications • Enterprise, datacenter, and storage area networks • SDN, NFV, and network programming • Networking hardware design • Network measurement, monitoring, diagnosis, and operations • Formal methods and network verification • Network security and privacy, censorship, transparency • Network, transport, and application-layer protocols • Resource management, QoS, and signaling • Routing, traffic engineering, switching, and addressing • Wireless, mobile, and sensor networking The APNet Program Committee will select papers based on novelty, significance, and technical merit, rather than completeness. Innovative well-reasoned ideas with preliminary evaluations will suffice for APNet. Accepted papers will be published in the ACM Digital Library. We hope that the extension of APNet papers, when substantiated by solid implementation and experimentation, can be published at the aforementioned premier conferences. *Important Dates* Abstract registration: April 6, 2018 (11:59 GMT) Paper submission: April 13, 2018 (11:59 PM GMT) Notification of decision: June 11, 2018 Camera-ready date: June 25, 2018 ================================================ We apologize if you receive multiple copies of this CFPs. We appreciate your help to forward this CFPs to your friends & email lists. ================================================ __________________ *Publicity Co-Chair* Chen Qian Assistant Professor Department of Computer Engineering Jack Baskin School of Engineering University of California Santa Cruz From bruns at 2mbit.com Wed Feb 21 18:58:20 2018 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 21 Feb 2018 11:58:20 -0700 Subject: Anyone else having Tunnelbroker.net issues? Message-ID: <573faccc-2b97-c841-264f-b713f2590b27@2mbit.com> Hi all, I hate asking this on the list, but is anyone else having issues with HE and Tunnelbroker.net currently? Isitdownrightnow.com seems to support the notion there is something going on with it, and tests from my various VMs on DigitalOcean in various DCs seem to support the notion. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bruns at 2mbit.com Wed Feb 21 19:04:23 2018 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 21 Feb 2018 12:04:23 -0700 Subject: User on list from carid.com sending automated replies In-Reply-To: <3ab2eab2bb33476abecbdef6cc80253c@localhost.localdomain> References: <3ab2eab2bb33476abecbdef6cc80253c@localhost.localdomain> Message-ID: <0160fe24-15ad-e7ea-0b9e-50166b911df2@2mbit.com> Just got this auto responder in re of my question to the list. Someone from carid.com seems to have their inbox routed to their company's support box. -------- Forwarded Message -------- Subject: Anyone else having Tunnelbroker.net issues? {3672073} Date: Wed, 21 Feb 2018 14:01:03 -0500 From: CARiD.com To: bruns at 2mbit.com Thank you for contacting CARiD's Customer Experience Team! This e-mail is to confirm we have received your inquiry. One of our dedicated Customer Experience Agents will contact you within 24 hours to provide you with the information you requested. We thank you for your patience and assure you we are working diligently to answer your request as soon as possible. Thank you again for choosing CARiD.com! Sincerely, CARiD Customer Experience Center Phone: 800.505.3274 Email: support at carid.com Facebook Google+ Youtube MyCARiD -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bruns at 2mbit.com Wed Feb 21 19:06:18 2018 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 21 Feb 2018 12:06:18 -0700 Subject: Anyone else having Tunnelbroker.net issues? In-Reply-To: References: <573faccc-2b97-c841-264f-b713f2590b27@2mbit.com> Message-ID: <17178674-39cb-1608-acc6-776377be7371@2mbit.com> On 2/21/2018 12:03 PM, Tommy Bowditch wrote: > HE FMT1 currently offline > https://twitter.com/henet/status/966380761136975872 > > As is their phones. Thx, didn't even think to check twitter. Just checked which DC the tunnel i'm having issues with is at, and solves that mystery! -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From me at tombowdit.ch Wed Feb 21 19:03:27 2018 From: me at tombowdit.ch (Tommy Bowditch) Date: Wed, 21 Feb 2018 19:03:27 +0000 Subject: Anyone else having Tunnelbroker.net issues? In-Reply-To: <573faccc-2b97-c841-264f-b713f2590b27@2mbit.com> References: <573faccc-2b97-c841-264f-b713f2590b27@2mbit.com> Message-ID: HE FMT1 currently offline https://twitter.com/henet/status/966380761136975872 As is their phones. T On Wed, Feb 21, 2018 at 6:58 PM, Brielle Bruns wrote: > Hi all, > > I hate asking this on the list, but is anyone else having issues with HE > and Tunnelbroker.net currently? > > Isitdownrightnow.com seems to support the notion there is something going > on with it, and tests from my various VMs on DigitalOcean in various DCs > seem to support the notion. > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > From vwittkop at nanog.org Wed Feb 21 23:39:38 2018 From: vwittkop at nanog.org (Valerie Wittkop) Date: Wed, 21 Feb 2018 18:39:38 -0500 Subject: User on list from carid.com sending automated replies In-Reply-To: <0160fe24-15ad-e7ea-0b9e-50166b911df2@2mbit.com> References: <3ab2eab2bb33476abecbdef6cc80253c@localhost.localdomain> <0160fe24-15ad-e7ea-0b9e-50166b911df2@2mbit.com> Message-ID: The email address had formally been moderated so replies went to the queue rather than automatically to the list. I had to research - and realized this auto-response falls under the same behavior as an automatic vacation message. The address is now on no-mail status per the AUP , number 6. Cheers, Valerie Valerie Wittkop NANOG Program Director Tel: +1 866 902 1336, ext 103 > On Feb 21, 2018, at 2:04 PM, Brielle Bruns wrote: > > > Just got this auto responder in re of my question to the list. Someone from carid.com seems to have their inbox routed to their company's support box. > > -------- Forwarded Message -------- > Subject: Anyone else having Tunnelbroker.net issues? {3672073} > Date: Wed, 21 Feb 2018 14:01:03 -0500 > From: CARiD.com > To: bruns at 2mbit.com > > > > > > > Thank you for contacting CARiD's Customer Experience Team! > > This e-mail is to confirm we have received your inquiry. One of our dedicated Customer Experience Agents will contact you within 24 hours to provide you with the information you requested. We thank you for your patience and assure you we are working diligently to answer your request as soon as possible. > > Thank you again for choosing CARiD.com! > > Sincerely, > > > CARiD > Customer Experience Center > Phone: 800.505.3274 > Email: support at carid.com > Facebook Google+ Youtube MyCARiD > > > > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org From surfer at mauigateway.com Wed Feb 21 22:18:43 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 21 Feb 2018 14:18:43 -0800 Subject: User on list from carid.com sending automated replies Message-ID: <20180221141843.B47C014F@m0117164.ppops.net> --- bruns at 2mbit.com wrote: From: Brielle Bruns Just got this auto responder in re of my question to the list. Someone from carid.com seems to have their inbox routed to their company's support box. --------------------------------------------- I sent admins at nanog.org an email about that on Sat 02/03/18 and Mon 02/05/18 and got no response either time. The email address is not monitored. scott ---------------------------------------------- ----------------------------------------------- Subject: Fwd: Re: improving signal to noise ratio from centralized network syslogs{3638747} Date: Sat 02/03/18 12:05 PM auto-responder. block, please. scott ----------------------------------------------- Subject: Re: improving signal to noise ratio from centralized network syslogs {3641238} Date: Mon, 5 Feb 2018 13:52:03 -0500 Is anyone reading this list? Please block the autoresponder email address. scott --- Begin forwarded message: From: "CARiD.com" To: surfer at mauigateway.com Subject: Re: improving signal to noise ratio from centralized network syslogs {3641238} Date: Mon, 5 Feb 2018 13:52:03 -0500 From surfer at mauigateway.com Wed Feb 21 22:45:03 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 21 Feb 2018 14:45:03 -0800 Subject: NANOG is moderated? Message-ID: <20180221144503.B47C0302@m0117164.ppops.net> Is NANOG now moderated? Can the folks with the purple robes and wizard hats please allow me back in? :-) scott --- Begin forwarded message: From: nanog-owner at nanog.org To: surfer at mauigateway.com Subject: Your message to NANOG awaits moderator approval Date: Wed, 21 Feb 2018 22:18:53 +0000 Your mail to 'NANOG' with the subject Re: User on list from carid.com sending automated replies Is being held until the list moderator can review it for approval. The reason it is being held: Post to moderated list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://mailman.nanog.org/mailman/confirm/nanog/69d14ed29585586fdcd7c404c5718aeb48f20746 -------------------------------------------------- MIME-Version: 1.0 Errors-To: nanog-bounces at nanog.org X-Mailman-Version: 2.1.20 Message-ID: Content-Type: text/plain; charset="utf-8" Received: from mail.nanog.org (mail.nanog.org [50.31.151.76])by m0116960.mta.everyone.net (EON-INBOUND) with ESMTP id m0116960.5a34abbb.31f472bfor ; Wed, 21 Feb 2018 14:18:55 -0800 from mail.nanog.org (localhost [IPv6:::1])by mail.nanog.org (Postfix) with ESMTP id E5367160066for ; Wed, 21 Feb 2018 22:18:54 +0000 (UTC) X-Eon-DM: m0116960.ppops.net Subject: Your message to NANOG awaits moderator approval Return-Path: Sender: "NANOG" Date: Wed, 21 Feb 2018 22:18:53 +0000 Precedence: bulk X-List-Administrivia: yes X-Beenthere: nanog at nanog.org To: surfer at mauigateway.com List-ID: North American Network Operators Group Content-Transfer-Encoding: base64 From: nanog-owner at nanog.org SpamShield Pro Actions...Report spam & move to: Trash Approve senders From trelane at trelane.net Thu Feb 22 01:35:53 2018 From: trelane at trelane.net (Andrew Kirch) Date: Thu, 22 Feb 2018 01:35:53 +0000 Subject: NANOG is moderated? In-Reply-To: <20180221144503.B47C0302@m0117164.ppops.net> References: <20180221144503.B47C0302@m0117164.ppops.net> Message-ID: Interesting as very few would call me moderate! Andrew On Wed, Feb 21, 2018 at 7:08 PM Scott Weeks wrote: > > > > Is NANOG now moderated? Can the folks with the purple > robes and wizard hats please allow me back in? :-) > > scott > > > > --- Begin forwarded message: > > From: nanog-owner at nanog.org > To: surfer at mauigateway.com > Subject: Your message to NANOG awaits moderator approval > Date: Wed, 21 Feb 2018 22:18:53 +0000 > > Your mail to 'NANOG' with the subject > > Re: User on list from carid.com sending automated replies > > Is being held until the list moderator can review it for approval. > > The reason it is being held: > > Post to moderated list > > Either the message will get posted to the list, or you will receive > notification of the moderator's decision. If you would like to cancel > this posting, please visit the following URL: > > > https://mailman.nanog.org/mailman/confirm/nanog/69d14ed29585586fdcd7c404c5718aeb48f20746 > > > > -------------------------------------------------- > > > > > > MIME-Version: 1.0 > Errors-To: nanog-bounces at nanog.org > X-Mailman-Version: 2.1.20 > Message-ID: > Content-Type: text/plain; charset="utf-8" > Received: from mail.nanog.org (mail.nanog.org [50.31.151.76])by > m0116960.mta.everyone.net (EON-INBOUND) with ESMTP id > m0116960.5a34abbb.31f472bfor ; Wed, 21 Feb 2018 > 14:18:55 -0800 > from mail.nanog.org (localhost [IPv6:::1])by mail.nanog.org (Postfix) > with ESMTP id E5367160066for ; Wed, 21 Feb 2018 > 22:18:54 +0000 (UTC) > X-Eon-DM: m0116960.ppops.net > Subject: Your message to NANOG awaits moderator approval > Return-Path: > Sender: "NANOG" > Date: Wed, 21 Feb 2018 22:18:53 +0000 > Precedence: bulk > X-List-Administrivia: yes > X-Beenthere: nanog at nanog.org > To: surfer at mauigateway.com > List-ID: North American Network Operators Group > Content-Transfer-Encoding: base64 > > > From: nanog-owner at nanog.org > SpamShield Pro Actions...Report spam & move to: Trash Approve senders > > > > > > From chuckchurch at gmail.com Thu Feb 22 02:30:01 2018 From: chuckchurch at gmail.com (Chuck Church) Date: Wed, 21 Feb 2018 21:30:01 -0500 Subject: Anyone else having Tunnelbroker.net issues? In-Reply-To: <573faccc-2b97-c841-264f-b713f2590b27@2mbit.com> References: <573faccc-2b97-c841-264f-b713f2590b27@2mbit.com> Message-ID: <02cf01d3ab85$0b0da500$2128ef00$@gmail.com> I've had problems with my Synology router and tunnel broker for several days. Used to work, config didn't change, assigned IPv4 address for me didn't change, but acting flakey, not much debugging capability on Synology I can find to figure it out. Chuck -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Brielle Bruns Sent: Wednesday, February 21, 2018 1:58 PM To: NANOG list Subject: Anyone else having Tunnelbroker.net issues? Hi all, I hate asking this on the list, but is anyone else having issues with HE and Tunnelbroker.net currently? Isitdownrightnow.com seems to support the notion there is something going on with it, and tests from my various VMs on DigitalOcean in various DCs seem to support the notion. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From brandon at burn.net Thu Feb 22 14:28:47 2018 From: brandon at burn.net (Brandon Applegate) Date: Thu, 22 Feb 2018 09:28:47 -0500 Subject: Spectrum/TWC contact off-list ? Message-ID: <3D5E2632-F304-4A00-B76D-E744EB10D7C5@burn.net> I’ve resisted reaching out like this so far. I posted on DSL Reports and didn't get anything valuable back. I’m also confident that Spectrum front line support will have zero clue as to where to take my question. In a nutshell: seeing some strange IPv6 reachability issues, and they are always overnight/wee-hours (EST). Seems to be very specific to a certain prefix (or more pointedly - my IA_NA vs. IA_PD). If someone could contact me off-list I would greatly appreciate it. This isn’t a hard down or critical issue - but it is an annoying head-scratcher. Thanks. -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 0641 D285 A36F 533A 73E5 2541 4920 533C C616 703A "For thousands of years men dreamed of pacts with demons. Only now are such things possible." -------------- 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 cscora at apnic.net Fri Feb 23 18:03:10 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 24 Feb 2018 04:03:10 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180223180310.BCED4C450F@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, CaribNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG 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 24 Feb, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 686347 Prefixes after maximum aggregation (per Origin AS): 266472 Deaggregation factor: 2.58 Unique aggregates announced (without unneeded subnets): 331010 Total ASes present in the Internet Routing Table: 59912 Prefixes per ASN: 11.46 Origin-only ASes present in the Internet Routing Table: 51754 Origin ASes announcing only one prefix: 22732 Transit ASes present in the Internet Routing Table: 8158 Transit-only ASes present in the Internet Routing Table: 251 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 35 Max AS path prepend of ASN (262865) 25 Prefixes from unregistered ASNs in the Routing Table: 57 Number of instances of unregistered ASNs: 57 Number of 32-bit ASNs allocated by the RIRs: 21595 Number of 32-bit ASNs visible in the Routing Table: 17346 Prefixes from 32-bit ASNs in the Routing Table: 72025 Number of bogon 32-bit ASNs visible in the Routing Table: 11 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 336 Number of addresses announced to Internet: 2854396258 Equivalent to 170 /8s, 34 /16s and 161 /24s Percentage of available address space announced: 77.1 Percentage of allocated address space announced: 77.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.8 Total number of prefixes smaller than registry allocations: 227261 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 189162 Total APNIC prefixes after maximum aggregation: 54011 APNIC Deaggregation factor: 3.50 Prefixes being announced from the APNIC address blocks: 188124 Unique aggregates announced from the APNIC address blocks: 77606 APNIC Region origin ASes present in the Internet Routing Table: 8664 APNIC Prefixes per ASN: 21.71 APNIC Region origin ASes announcing only one prefix: 2458 APNIC Region transit ASes present in the Internet Routing Table: 1272 Average APNIC Region AS path length visible: 4.3 Max APNIC Region AS path length visible: 27 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3573 Number of APNIC addresses announced to Internet: 767961378 Equivalent to 45 /8s, 198 /16s and 41 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 204886 Total ARIN prefixes after maximum aggregation: 98276 ARIN Deaggregation factor: 2.08 Prefixes being announced from the ARIN address blocks: 205810 Unique aggregates announced from the ARIN address blocks: 97004 ARIN Region origin ASes present in the Internet Routing Table: 18098 ARIN Prefixes per ASN: 11.37 ARIN Region origin ASes announcing only one prefix: 6699 ARIN Region transit ASes present in the Internet Routing Table: 1797 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: 2314 Number of ARIN addresses announced to Internet: 1104112928 Equivalent to 65 /8s, 207 /16s and 109 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 185727 Total RIPE prefixes after maximum aggregation: 90672 RIPE Deaggregation factor: 2.05 Prefixes being announced from the RIPE address blocks: 181965 Unique aggregates announced from the RIPE address blocks: 108868 RIPE Region origin ASes present in the Internet Routing Table: 24920 RIPE Prefixes per ASN: 7.30 RIPE Region origin ASes announcing only one prefix: 11340 RIPE Region transit ASes present in the Internet Routing Table: 3490 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: 6695 Number of RIPE addresses announced to Internet: 714129024 Equivalent to 42 /8s, 144 /16s and 190 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 88237 Total LACNIC prefixes after maximum aggregation: 19490 LACNIC Deaggregation factor: 4.53 Prefixes being announced from the LACNIC address blocks: 89586 Unique aggregates announced from the LACNIC address blocks: 39876 LACNIC Region origin ASes present in the Internet Routing Table: 6838 LACNIC Prefixes per ASN: 13.10 LACNIC Region origin ASes announcing only one prefix: 1870 LACNIC Region transit ASes present in the Internet Routing Table: 1265 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 35 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4374 Number of LACNIC addresses announced to Internet: 171976096 Equivalent to 10 /8s, 64 /16s and 37 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 18276 Total AfriNIC prefixes after maximum aggregation: 3978 AfriNIC Deaggregation factor: 4.59 Prefixes being announced from the AfriNIC address blocks: 20526 Unique aggregates announced from the AfriNIC address blocks: 7384 AfriNIC Region origin ASes present in the Internet Routing Table: 1116 AfriNIC Prefixes per ASN: 18.39 AfriNIC Region origin ASes announcing only one prefix: 364 AfriNIC Region transit ASes present in the Internet Routing Table: 225 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 390 Number of AfriNIC addresses announced to Internet: 95808768 Equivalent to 5 /8s, 181 /16s and 237 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5436 4195 92 ERX-CERNET-BKB China Education and Rese 7545 3794 407 414 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2859 11132 770 KIXS-AS-KR Korea Telecom, KR 9829 2802 1499 540 BSNL-NIB National Internet Backbone, IN 17974 2708 934 80 TELKOMNET-AS2-AP PT Telekomunikasi Indo 7552 2633 1161 59 VIETEL-AS-AP Viettel Group, VN 9394 2629 4923 28 CTTNET China TieTong Telecommunications 45899 2586 1558 154 VNPT-AS-VN VNPT Corp, VN 9808 2181 8699 32 CMNET-GD Guangdong Mobile Communication 4755 2083 417 215 TATACOMM-AS TATA Communications formerl 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 3363 1323 86 SHAW - Shaw Communications Inc., CA 22773 3272 2987 148 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2166 405 108 MEGAPATH5-US - MegaPath Corporation, US 20115 2089 2411 433 CHARTER-NET-HKY-NC - Charter Communicat 16509 2034 4277 595 AMAZON-02 - Amazon.com, Inc., US 209 1938 5062 626 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1922 337 199 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6389 1862 3671 36 BELLSOUTH-NET-BLK - BellSouth.net Inc., 11492 1729 227 579 CABLEONE - CABLE ONE, INC., US 7018 1683 20179 1248 ATT-INTERNET4 - AT&T Services, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3520 187 21 ALJAWWALSTC-AS, SA 20940 2843 837 2059 AKAMAI-ASN1, US 12479 2780 1254 671 UNI2-AS, ES 8551 2099 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12389 2028 1862 704 ROSTELECOM-AS, RU 34984 1992 332 474 TELLCOM-AS, TR 9121 1987 1692 19 TTNET, TR 13188 1606 100 46 TRIOLAN, UA 6849 1241 355 21 UKRTELNET, UA 8402 1239 544 14 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 4163 3389 588 Uninet S.A. de C.V., MX 10620 3599 542 238 Telmex Colombia S.A., CO 11830 2643 370 66 Instituto Costarricense de Electricidad 6503 1628 437 53 Axtel, S.A.B. de C.V., MX 7303 1507 1026 191 Telecom Argentina S.A., AR 3816 1018 511 116 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 6147 1015 377 27 Telefonica del Peru S.A.A., PE 28573 1011 2244 187 CLARO S.A., BR 11172 923 126 86 Alestra, S. de R.L. de C.V., MX 18881 907 1072 29 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1182 398 49 LINKdotNET-AS, EG 37611 803 91 8 Afrihost, ZA 36903 739 371 135 MT-MPLS, MA 36992 671 1380 36 ETISALAT-MISR, EG 8452 596 1730 18 TE-AS TE-AS, EG 24835 522 850 15 RAYA-AS, EG 29571 467 68 12 ORANGE-COTE-IVOIRE, CI 37492 454 376 80 ORANGE-, TN 15399 362 35 7 WANANCHI-, KE 37342 360 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 4538 5436 4195 92 ERX-CERNET-BKB China Education and Rese 8151 4163 3389 588 Uninet S.A. de C.V., MX 7545 3794 407 414 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3599 542 238 Telmex Colombia S.A., CO 39891 3520 187 21 ALJAWWALSTC-AS, SA 6327 3363 1323 86 SHAW - Shaw Communications Inc., CA 22773 3272 2987 148 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 4766 2859 11132 770 KIXS-AS-KR Korea Telecom, KR 20940 2843 837 2059 AKAMAI-ASN1, US 9829 2802 1499 540 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 8151 4163 3575 Uninet S.A. de C.V., MX 39891 3520 3499 ALJAWWALSTC-AS, SA 7545 3794 3380 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3599 3361 Telmex Colombia S.A., CO 6327 3363 3277 SHAW - Shaw Communications Inc., CA 22773 3272 3124 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 17974 2708 2628 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9394 2629 2601 CTTNET China TieTong Telecommunications Corpora 11830 2643 2577 Instituto Costarricense de Electricidad y Telec 7552 2633 2574 VIETEL-AS-AP Viettel Group, VN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65456 PRIVATE 31.171.126.0/23 199311 AZRT-LX Local Internet Exchang 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 65024 PRIVATE 87.103.234.0/24 39407 CHITATELECOM-AS, RU 65000 PRIVATE 95.179.2.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.3.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.69.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.70.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.92.0/24 65001 -Private Use AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.66.224.0/19 209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communicati Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.14.0/23 10247 NETLINE, ZA 14.192.50.0/23 10247 NETLINE, ZA 14.192.58.0/23 10247 NETLINE, ZA 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/23 10247 NETLINE, ZA 37.44.224.0/20 48666 AS-MAROSNET Moscow, Russia, RU 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.228.144.0/22 9829 BSNL-NIB National Internet Backbone, IN 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 43.251.84.0/22 133676 PNPL-AS Precious netcom pvt ltd, IN 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:14 /9:11 /10:37 /11:100 /12:290 /13:563 /14:1094 /15:1900 /16:13325 /17:7788 /18:13608 /19:25221 /20:39069 /21:45132 /22:84561 /23:68585 /24:382819 /25:842 /26:599 /27:654 /28:35 /29:20 /30:18 /31:4 /32:58 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3154 3363 SHAW - Shaw Communications Inc., CA 39891 2946 3520 ALJAWWALSTC-AS, SA 22773 2530 3272 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2060 2166 MEGAPATH5-US - MegaPath Corporation, US 11830 1989 2643 Instituto Costarricense de Electricidad y Telec 30036 1677 1922 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 12479 1644 2780 UNI2-AS, ES 10620 1592 3599 Telmex Colombia S.A., CO 8551 1562 2099 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11492 1515 1729 CABLEONE - CABLE ONE, INC., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1568 2:843 4:18 5:2652 6:59 7:1 8:1106 9:1 12:1868 13:204 14:1755 15:26 16:3 17:186 18:68 20:49 21:3 23:2541 24:2136 25:2 27:2346 31:1937 32:88 35:24 36:492 37:2629 38:1463 39:245 40:103 41:2997 42:538 43:1953 44:97 45:3727 46:3018 47:200 49:1362 50:1041 51:48 52:976 54:360 55:6 56:7 57:42 58:1596 59:1038 60:387 61:2062 62:1801 63:1803 64:4721 65:2226 66:4534 67:2342 68:1169 69:3189 70:1171 71:559 72:2099 74:2671 75:398 76:425 77:1520 78:1685 79:1845 80:1487 81:1414 82:1082 83:794 84:1006 85:2020 86:556 87:1258 88:919 89:2295 90:186 91:6283 92:1178 93:2369 94:2410 95:2735 96:650 97:357 98:928 99:120 100:79 101:1474 102:26 103:17188 104:3275 105:220 106:542 107:1803 108:708 109:2697 110:1572 111:1773 112:1312 113:1379 114:1129 115:1636 116:1642 117:1699 118:2202 119:1675 120:968 121:1059 122:2463 123:1802 124:1458 125:1855 128:987 129:602 130:434 131:1604 132:615 133:194 134:997 135:226 136:439 137:477 138:1961 139:568 140:402 141:684 142:779 143:989 144:797 145:454 146:1164 147:747 148:1535 149:704 150:736 151:987 152:761 153:309 154:1024 155:755 156:838 157:772 158:623 159:1617 160:865 161:737 162:2548 163:523 164:1021 165:1391 166:396 167:1389 168:3095 169:805 170:3657 171:414 172:1038 173:1921 174:877 175:753 176:1920 177:3952 178:2423 179:1156 180:2240 181:2143 182:2467 183:1131 184:906 185:12596 186:3452 187:2318 188:2676 189:1968 190:8118 191:1365 192:9789 193:5889 194:4778 195:3981 196:2419 197:1418 198:5523 199:5890 200:7320 201:4881 202:10372 203:10038 204:4542 205:2870 206:3064 207:3120 208:3989 209:3926 210:4039 211:2116 212:2995 213:2623 214:902 215:61 216:5850 217:2137 218:899 219:621 220:1726 221:996 222:1053 223:1238 End of report From bkain1 at ford.com Fri Feb 23 18:21:53 2018 From: bkain1 at ford.com (Kain, Rebecca (.)) Date: Fri, 23 Feb 2018 18:21:53 +0000 Subject: anyone from wired/condenast? Message-ID: <52ee326e0ae2453c9206c8690197ca6a@nafcmb01.exchange.ford.com> Seems the wired newsletter isn't coming into ford.com any longer, after 2/12/18. The email folks thing it's on the wired end. Can someone ping me? Thanks From mike.lyon at gmail.com Mon Feb 26 03:03:24 2018 From: mike.lyon at gmail.com (mike.lyon at gmail.com) Date: Sun, 25 Feb 2018 19:03:24 -0800 Subject: Any Southwest Airlines network peeps on the list? Message-ID: <1A5BAEE9-E3E6-48FF-898A-CDDEA16358F4@gmail.com> If so, can you shoot me an email offlist? Think you may be blocking some of my IPs. Thanks, Mike From CGross at ninestarconnect.com Mon Feb 26 12:54:16 2018 From: CGross at ninestarconnect.com (Chris Gross) Date: Mon, 26 Feb 2018 12:54:16 +0000 Subject: Craigslist Blocks Message-ID: Is there anyone from Craigslist here or anyone have a better way to deal with their blocks? There's a contact e-mail in the block messages when trying to visit, but there's never gets a response back when we try it. Please hit me up off list. From lists at silverlakeinternet.com Mon Feb 26 14:03:11 2018 From: lists at silverlakeinternet.com (Brett A Mansfield) Date: Mon, 26 Feb 2018 07:03:11 -0700 Subject: Craigslist Blocks In-Reply-To: References: Message-ID: <68DF8380-3BD8-460D-B343-CC6973F9EB96@silverlakeinternet.com> I’ve been having the same problem. I’d also like a contact off list from someone who can do something about it. Thank you, Brett A Mansfield > On Feb 26, 2018, at 5:54 AM, Chris Gross wrote: > > Is there anyone from Craigslist here or anyone have a better way to deal with their blocks? There's a contact e-mail in the block messages when trying to visit, but there's never gets a response back when we try it. Please hit me up off list. From jstump at fourway.net Mon Feb 26 14:18:44 2018 From: jstump at fourway.net (Joshua Stump) Date: Mon, 26 Feb 2018 09:18:44 -0500 Subject: Craigslist Blocks In-Reply-To: <68DF8380-3BD8-460D-B343-CC6973F9EB96@silverlakeinternet.com> References: <68DF8380-3BD8-460D-B343-CC6973F9EB96@silverlakeinternet.com> Message-ID: <06c801d3af0c$b5e70180$21b50480$@fourway.net> Same thing here. I've had unresolved issues for months. Tried multiple ways of contact, including email in block message. No luck. Joshua Stump Network Admin Fourway.NET 800-733-0062 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Brett A Mansfield Sent: Monday, February 26, 2018 9:03 AM To: Chris Gross Cc: NANOG Subject: Re: Craigslist Blocks I’ve been having the same problem. I’d also like a contact off list from someone who can do something about it. Thank you, Brett A Mansfield > On Feb 26, 2018, at 5:54 AM, Chris Gross wrote: > > Is there anyone from Craigslist here or anyone have a better way to deal with their blocks? There's a contact e-mail in the block messages when trying to visit, but there's never gets a response back when we try it. Please hit me up off list. From aaron1 at gvtc.com Mon Feb 26 17:00:05 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Mon, 26 Feb 2018 11:00:05 -0600 Subject: cogent last night Message-ID: <000301d3af23$40226b30$c0674190$@gvtc.com> Did anyone in San Antonio or surrounding areas have internet issues last night around ~8:00 - 8:30 p.m. central time ? I saw a significant drop in traffic during that time with packet loss seen on ping attempts. Just wanted to know if I was the only one that took a hit -Aaron From aaron1 at gvtc.com Mon Feb 26 17:21:06 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Mon, 26 Feb 2018 11:21:06 -0600 Subject: cogent last night In-Reply-To: <000301d3af23$40226b30$c0674190$@gvtc.com> References: <000301d3af23$40226b30$c0674190$@gvtc.com> Message-ID: <001001d3af26$312431b0$936c9510$@gvtc.com> No, I Wasn't the only one. 2 other neighboring South Texas ISP's just told me they had same packet loss/high latency issues on their cogent connection during same time frame. Anyone know why this occurred and how far reaching it was ? -Aaron From mike at sentex.net Mon Feb 26 18:19:52 2018 From: mike at sentex.net (Mike Tancsa) Date: Mon, 26 Feb 2018 13:19:52 -0500 Subject: cogent last night In-Reply-To: <001001d3af26$312431b0$936c9510$@gvtc.com> References: <000301d3af23$40226b30$c0674190$@gvtc.com> <001001d3af26$312431b0$936c9510$@gvtc.com> Message-ID: <4eacca17-92f9-4d47-7cc6-906ba84450c6@sentex.net> On 2/26/2018 12:21 PM, Aaron Gould wrote: > No, I Wasn't the only one. 2 other neighboring South Texas ISP's just told > me they had same packet loss/high latency issues on their cogent connection > during same time frame. > > Anyone know why this occurred and how far reaching it was ? Interesting, I pick up Cogent in Toronto and saw some sort of issue between them and sites I pick up out of AS577 (via in Cogent in Chicago). BGP paths seemed to be there, but traffic dropped to almost nothing for about 10min. By the time I got online to look, the issue had resolved. This was at about 02:05 Eastern to ~ 02:20. Were they perhaps doing some big upgrades ? ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, mike at sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada From amitchell at isipp.com Mon Feb 26 18:44:44 2018 From: amitchell at isipp.com (Anne P. Mitchell Esq.) Date: Mon, 26 Feb 2018 11:44:44 -0700 Subject: Craigslist Blocks In-Reply-To: <06c801d3af0c$b5e70180$21b50480$@fourway.net> References: <68DF8380-3BD8-460D-B343-CC6973F9EB96@silverlakeinternet.com> <06c801d3af0c$b5e70180$21b50480$@fourway.net> Message-ID: If someone wants to send me a copy of the block message, and at least one IP that is blocked, I'll see what we can do. Anne Anne P. Mitchell, Attorney at Law CEO/President, SuretyMail Email Reputation Certification and Inbox Delivery Assistance http://www.SuretyMail.com/ http://www.SuretyMail.eu/ Attorney at Law / Legislative Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Author: The Email Deliverability Handbook Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center Member, California Bar Cyberspace Law Committee Former Chair, Asilomar Microcomputer Workshop Ret. Professor of Law, Lincoln Law School of San Jose > > Same thing here. I've had unresolved issues for months. Tried multiple ways of contact, including email in block message. No luck. > > Joshua Stump > Network Admin > Fourway.NET > 800-733-0062 > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Brett A Mansfield > Sent: Monday, February 26, 2018 9:03 AM > To: Chris Gross > Cc: NANOG > Subject: Re: Craigslist Blocks > > I’ve been having the same problem. I’d also like a contact off list from someone who can do something about it. > > Thank you, > Brett A Mansfield > >> On Feb 26, 2018, at 5:54 AM, Chris Gross wrote: >> >> Is there anyone from Craigslist here or anyone have a better way to deal with their blocks? There's a contact e-mail in the block messages when trying to visit, but there's never gets a response back when we try it. Please hit me up off list. > > > From math at sizone.org Mon Feb 26 21:31:00 2018 From: math at sizone.org (Ken Chase) Date: Mon, 26 Feb 2018 16:31:00 -0500 Subject: MSFT reverse IP failure? Message-ID: <20180226213100.GA19634@sizone.org> Having a client doing a test from the MSFT exchange tools site, which is failing. NOQUEUE: reject: RCPT from unknown[13.67.59.89]: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [13.67.59.89]; NetRange: 13.64.0.0 - 13.107.255.255 CIDR: 13.96.0.0/13, 13.104.0.0/14, 13.64.0.0/11 NetName: MSFT A bit of an oversight? /kc -- Ken Chase - math at sizone.org Guelph Canada From chkuhtz at microsoft.com Mon Feb 26 23:25:59 2018 From: chkuhtz at microsoft.com (Christian Kuhtz) Date: Mon, 26 Feb 2018 23:25:59 +0000 Subject: MSFT reverse IP failure? In-Reply-To: <20180226213100.GA19634@sizone.org> References: <20180226213100.GA19634@sizone.org> Message-ID: Ken, A little difficult to say what this without knowing what 13.67.59.89 actually is. If this is an Azure deployment, ReverseFqdn needs to be populated on the Public IP address resource. Please take a look here https://docs.microsoft.com/en-us/azure/dns/dns-reverse-dns-for-azure-services Thanks, Christian -----Original Message----- From: NANOG On Behalf Of Ken Chase Sent: Monday, February 26, 2018 1:31 PM To: nanog at nanog.org Subject: Re: MSFT reverse IP failure? Having a client doing a test from the MSFT exchange tools site, which is failing. NOQUEUE: reject: RCPT from unknown[13.67.59.89]: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [13.67.59.89]; NetRange: 13.64.0.0 - 13.107.255.255 CIDR: 13.96.0.0/13, 13.104.0.0/14, 13.64.0.0/11 NetName: MSFT A bit of an oversight? /kc -- Ken Chase - math at sizone.org Guelph Canada From math at sizone.org Tue Feb 27 00:04:43 2018 From: math at sizone.org (Ken Chase) Date: Mon, 26 Feb 2018 19:04:43 -0500 Subject: MSFT reverse IP failure? In-Reply-To: References: <20180226213100.GA19634@sizone.org> Message-ID: <20180227000443.GG23308@sizone.org> Im not exactly sure what this is either, the client sent me a screenshot that called itself the "microsoft connectivity analyzer", which had several steps testing deliverability of email to their domain, with the final test of an actual test email delivery failing. /kc On Mon, Feb 26, 2018 at 11:25:59PM +0000, Christian Kuhtz said: >Ken, > >A little difficult to say what this without knowing what 13.67.59.89 actually is. If this is an Azure deployment, ReverseFqdn needs to be populated on the Public IP address resource. Please take a look here https://docs.microsoft.com/en-us/azure/dns/dns-reverse-dns-for-azure-services > >Thanks, >Christian > > >-----Original Message----- >From: NANOG On Behalf Of Ken Chase >Sent: Monday, February 26, 2018 1:31 PM >To: nanog at nanog.org >Subject: Re: MSFT reverse IP failure? > >Having a client doing a test from the MSFT exchange tools site, which is failing. > >NOQUEUE: reject: RCPT from unknown[13.67.59.89]: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [13.67.59.89]; > >NetRange: 13.64.0.0 - 13.107.255.255 >CIDR: 13.96.0.0/13, 13.104.0.0/14, 13.64.0.0/11 >NetName: MSFT > >A bit of an oversight? > >/kc >-- >Ken Chase - math at sizone.org Guelph Canada From list at satchell.net Tue Feb 27 00:09:00 2018 From: list at satchell.net (Stephen Satchell) Date: Mon, 26 Feb 2018 16:09:00 -0800 Subject: MSFT reverse IP failure? In-Reply-To: References: <20180226213100.GA19634@sizone.org> Message-ID: On 02/26/2018 03:25 PM, Christian Kuhtz via NANOG wrote: > A little difficult to say what this without knowing what 13.67.59.89 actually is. If this is an Azure deployment, ReverseFqdn needs to be populated on the Public IP address resource. Please take a look herehttps://docs.microsoft.com/en-us/azure/dns/dns-reverse-dns-for-azure-services Nope. NetRange: 13.64.0.0 - 13.107.255.255 CIDR: 13.64.0.0/11, 13.96.0.0/13, 13.104.0.0/14 NetName: MSFT NetHandle: NET-13-64-0-0-1 Parent: NET13 (NET-13-0-0-0-0) NetType: Direct Assignment OriginAS: Organization: Microsoft Corporation (MSFT) RegDate: 2015-03-26 Updated: 2015-03-26 OrgName: Microsoft Corporation OrgId: MSFT Address: One Microsoft Way City: Redmond StateProv: WA PostalCode: 98052 Country: US RegDate: 1998-07-09 Updated: 2017-01-28 Comment: For routing, peering or DNS issues, please Comment: contact: Comment: * IOC at microsoft.com From hank at efes.iucc.ac.il Tue Feb 27 07:38:10 2018 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 27 Feb 2018 09:38:10 +0200 Subject: MSFT reverse IP failure? In-Reply-To: References: <20180226213100.GA19634@sizone.org> Message-ID: <6bddbef2-2f70-f0d9-541b-d9542c529779@efes.iucc.ac.il> On 27/02/2018 01:25, Christian Kuhtz via NANOG wrote: | 13.67.59.89/32 should reverse to | testconnectivity.microsoft.com | | https://support.office.com/en-us/article/office-365-urls-and-ip-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2 *Optional:* Remote Connectivity Analyzer - Initiate connectivity tests. | testconnectivity.microsoft.com | no | 13.67.59.89/32 40.69.150.142/32 40.85.91.8/32 104.211.54.99/32 104.211.54.134/32 | TCP 80 & 443 -Hank > Ken, > > A little difficult to say what this without knowing what 13.67.59.89 actually is. If this is an Azure deployment, ReverseFqdn needs to be populated on the Public IP address resource. Please take a look here https://docs.microsoft.com/en-us/azure/dns/dns-reverse-dns-for-azure-services > > Thanks, > Christian > > > -----Original Message----- > From: NANOG On Behalf Of Ken Chase > Sent: Monday, February 26, 2018 1:31 PM > To: nanog at nanog.org > Subject: Re: MSFT reverse IP failure? > > Having a client doing a test from the MSFT exchange tools site, which is failing. > > NOQUEUE: reject: RCPT from unknown[13.67.59.89]: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [13.67.59.89]; > > NetRange: 13.64.0.0 - 13.107.255.255 > CIDR: 13.96.0.0/13, 13.104.0.0/14, 13.64.0.0/11 > NetName: MSFT > > A bit of an oversight? > > /kc From chkuhtz at microsoft.com Tue Feb 27 07:40:44 2018 From: chkuhtz at microsoft.com (Christian Kuhtz) Date: Tue, 27 Feb 2018 07:40:44 +0000 Subject: MSFT reverse IP failure? In-Reply-To: <6bddbef2-2f70-f0d9-541b-d9542c529779@efes.iucc.ac.il> References: <20180226213100.GA19634@sizone.org> , <6bddbef2-2f70-f0d9-541b-d9542c529779@efes.iucc.ac.il> Message-ID: Hah. Thanks. :) Yes, it's a big shop.. ________________________________ From: Hank Nussbacher Sent: Monday, February 26, 2018 11:38:10 PM To: Christian Kuhtz; Ken Chase; nanog at nanog.org Subject: Re: MSFT reverse IP failure? On 27/02/2018 01:25, Christian Kuhtz via NANOG wrote: 13.67.59.89/32 should reverse to testconnectivity.microsoft.com https://support.office.com/en-us/article/office-365-urls-and-ip-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2 Optional: Remote Connectivity Analyzer - Initiate connectivity tests. testconnectivity.microsoft.com no 13.67.59.89/32 40.69.150.142/32 40.85.91.8/32 104.211.54.99/32 104.211.54.134/32 TCP 80 & 443 -Hank Ken, A little difficult to say what this without knowing what 13.67.59.89 actually is. If this is an Azure deployment, ReverseFqdn needs to be populated on the Public IP address resource. Please take a look here https://docs.microsoft.com/en-us/azure/dns/dns-reverse-dns-for-azure-services Thanks, Christian -----Original Message----- From: NANOG On Behalf Of Ken Chase Sent: Monday, February 26, 2018 1:31 PM To: nanog at nanog.org Subject: Re: MSFT reverse IP failure? Having a client doing a test from the MSFT exchange tools site, which is failing. NOQUEUE: reject: RCPT from unknown[13.67.59.89]: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [13.67.59.89]; NetRange: 13.64.0.0 - 13.107.255.255 CIDR: 13.96.0.0/13, 13.104.0.0/14, 13.64.0.0/11 NetName: MSFT A bit of an oversight? /kc From george.herbert at gmail.com Tue Feb 27 10:08:16 2018 From: george.herbert at gmail.com (George Herbert) Date: Tue, 27 Feb 2018 02:08:16 -0800 Subject: Craigslist Blocks In-Reply-To: References: <68DF8380-3BD8-460D-B343-CC6973F9EB96@silverlakeinternet.com> <06c801d3af0c$b5e70180$21b50480$@fourway.net> Message-ID: <6431AADA-6EF6-4C3E-8ACD-318ECB8CEA78@gmail.com> ...Anne's contact is better placed for abuse incidents but if they fail I have an alternate contact who has also indirectly helped before. He's a programmer not abuse ops guy but does know the other teams well and has helped. George William Herbert Sent from my iPhone > On Feb 26, 2018, at 10:44 AM, Anne P. Mitchell Esq. wrote: > > If someone wants to send me a copy of the block message, and at least one IP that is blocked, I'll see what we can do. > > Anne > > Anne P. Mitchell, > Attorney at Law > CEO/President, > SuretyMail Email Reputation Certification and Inbox Delivery Assistance > http://www.SuretyMail.com/ > http://www.SuretyMail.eu/ > > Attorney at Law / Legislative Consultant > Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) > Author: The Email Deliverability Handbook > Legal Counsel: The CyberGreen Institute > Legal Counsel: The Earth Law Center > Member, California Bar Cyberspace Law Committee > Former Chair, Asilomar Microcomputer Workshop > Ret. Professor of Law, Lincoln Law School of San Jose > > > >> >> Same thing here. I've had unresolved issues for months. Tried multiple ways of contact, including email in block message. No luck. >> >> Joshua Stump >> Network Admin >> Fourway.NET >> 800-733-0062 >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Brett A Mansfield >> Sent: Monday, February 26, 2018 9:03 AM >> To: Chris Gross >> Cc: NANOG >> Subject: Re: Craigslist Blocks >> >> I’ve been having the same problem. I’d also like a contact off list from someone who can do something about it. >> >> Thank you, >> Brett A Mansfield >> >>> On Feb 26, 2018, at 5:54 AM, Chris Gross wrote: >>> >>> Is there anyone from Craigslist here or anyone have a better way to deal with their blocks? There's a contact e-mail in the block messages when trying to visit, but there's never gets a response back when we try it. Please hit me up off list. >> >> >> > > From ggm at apnic.net Tue Feb 27 04:26:41 2018 From: ggm at apnic.net (George Michaelson) Date: Tue, 27 Feb 2018 10:11:41 +0545 Subject: Removing the four stale TAL from the APNIC RPKI validation set. Message-ID: <64163AA3-B6FD-447F-9DC0-A05AF0B9A290@apnic.net> Updating RPKI trust anchor configuration ------------------------------------------------------- APNIC has completed the process of transitioning from its previous Resource Public Key Infrastructure (RPKI) trust anchor arrangement to a new single trust anchor configuration. Each RIR will publish an 'all resources' global trust anchor, under which its own regional resources (IP addresses and ASNs) will be certified. APNICs trust anchor is one of the previous five, which has been retained as the sole trust anchor over all APNIC resource certificate products. If you are using relying-party software, such as the Dragon Research Labs RPKI Toolkit, RPSTIR or the RIPE NCC’s RPKI Validator, you are advised to update your software’s configuration to use only the current APNIC trust anchor, rather than the set of five APNIC trust anchors that were previously in use. The update is to remove four of the five: One has been retained as the current live Trust Anchor. Note: this update is not critical. However, if it is not done, the software will log or report warnings about being unable to retrieve the trust anchors that are no longer being used. All resources now validate under the single active trust anchor and no orphan products are valid under the other prior trust anchors. The current APNIC TAL is as follows: ------ rsync://rpki.apnic.net/repository/apnic-rpki-root-iana-origin.cer MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx9RWSL61YAAYumEiU8z8 qH2ETVIL01ilxZlzIL9JYSORMN5Cmtf8V2JblIealSqgOTGjvSjEsiV73s67zYQI 7C/iSOb96uf3/s86NqbxDiFQGN8qG7RNcdgVuUlAidl8WxvLNI8VhqbAB5uSg/Mr LeSOvXRja041VptAxIhcGzDMvlAJRwkrYK/Mo8P4E2rSQgwqCgae0ebY1CsJ3Cjf i67C1nw7oXqJJovvXJ4apGmEv8az23OLC6Ki54Ul/E6xk227BFttqFV3YMtKx42H cCcDVZZy01n7JjzvO8ccaXmHIgR7utnqhBRNNq5Xc5ZhbkrUsNtiJmrZzVlgU6Ou 0wIDAQAB ------ Configuring Relying Party Software ----------------------------------------------- RIPE NCC RPKI Validator: If you upgrade to RIPE validator rpki-validator-app-2.24 the correct Trust Anchor is configured. No further work is required. Dragon Research Labs Rcynic Validator: If you run rcynic, you need to remove all the TAL, TA or CER entries in rcynic.conf except ones which point to apnic-rpki-root-iana-origin.cer or the related TAL. If you use the trusted-certs/ directory, simply remove the four files which are named for the non-APNIC RIR as follows: cd /etc/trust-anchors # or wherever you place the TAL files rm apnic-rpki-root-ripe-origin.tal rm apnic-rpki-root-arin-origin.tal rm apnic-rpki-root-lacnic-origin.tal rm apnic-rpki-root-afrinic-origin.tal RPSTIR To modify an installed RPSTIR system, locate the /usr/local/etc/rpstir directory and remove all but the current live APNIC TAL. More information is in the attached PDF describing how to update the trust anchor configuration in these three popular relying-partner software systems. -George -------------- 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 jeffmeal at microsoft.com Mon Feb 26 22:46:55 2018 From: jeffmeal at microsoft.com (Jeff Mealiffe) Date: Mon, 26 Feb 2018 22:46:55 +0000 Subject: MSFT reverse IP failure? In-Reply-To: <20180226213100.GA19634@sizone.org> References: <20180226213100.GA19634@sizone.org> Message-ID: Which "Exchange tools site" are you referring to? Happy to help get this fixed up. -jeff -----Original Message----- From: NANOG On Behalf Of Ken Chase Sent: Monday, February 26, 2018 1:31 PM To: nanog at nanog.org Subject: Re: MSFT reverse IP failure? Having a client doing a test from the MSFT exchange tools site, which is failing. NOQUEUE: reject: RCPT from unknown[13.67.59.89]: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [13.67.59.89]; NetRange: 13.64.0.0 - 13.107.255.255 CIDR: 13.96.0.0/13, 13.104.0.0/14, 13.64.0.0/11 NetName: MSFT A bit of an oversight? /kc -- Ken Chase - math at sizone.org Guelph Canada From joshua.morgan at gmail.com Tue Feb 27 00:46:21 2018 From: joshua.morgan at gmail.com (Joshua Morgan) Date: Tue, 27 Feb 2018 11:46:21 +1100 Subject: MSFT reverse IP failure? In-Reply-To: <20180227000443.GG23308@sizone.org> References: <20180226213100.GA19634@sizone.org> <20180227000443.GG23308@sizone.org> Message-ID: On Tue, Feb 27, 2018 at 11:04 AM, Ken Chase wrote: > Im not exactly sure what this is either, the client sent me a screenshot > that called itself the "microsoft connectivity analyzer", which had several > steps testing deliverability of email to their domain, with the final test > of an actual test email delivery failing. > > /kc It's one of the outbound IP addresses for the Microsoft Remote Connectivity Analyzer, as documented here: https://support.office.com/en-gb/article/office-365-urls-and-ip-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2 . Your client's mail exchanger is rejecting the test e-mail message because that particular outbound IP address does not have PTR resource record. Interestingly, all of the IP addresses listed do not. Josh From aaron1 at gvtc.com Tue Feb 27 16:30:21 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Tue, 27 Feb 2018 10:30:21 -0600 Subject: cgnat - how do you handle customer issues Message-ID: <000301d3afe8$437dfcc0$ca79f640$@gvtc.com> Couple questions please. When you put thousands of customers behind a cgnat boundary, how do you all handle customer complaints about the following. 1 - for external connectivity to the customers premise devices, not being able to access web servers, web cameras, etc, in their premises? 2 - from the premise natted device, when customers go to a university or bank web site, how do you handle randomly changing ip addresses/ports that may occur due to idle time and session tear-down in nat table such that the bank website has issues with seeing your session ip change? -Aaron From nanog at ics-il.net Tue Feb 27 16:32:34 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 27 Feb 2018 10:32:34 -0600 (CST) Subject: cgnat - how do you handle customer issues In-Reply-To: <000301d3afe8$437dfcc0$ca79f640$@gvtc.com> References: <000301d3afe8$437dfcc0$ca79f640$@gvtc.com> Message-ID: <2112898300.2375.1519749152853.JavaMail.mhammett@ThunderFuck> I'm a fan of nailing each customer IP to a particular range of ports on a given public IP. Real easy to track who did what and to prevent shifting IPs. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Aaron Gould" To: Nanog at nanog.org Sent: Tuesday, February 27, 2018 10:30:21 AM Subject: cgnat - how do you handle customer issues Couple questions please. When you put thousands of customers behind a cgnat boundary, how do you all handle customer complaints about the following. 1 - for external connectivity to the customers premise devices, not being able to access web servers, web cameras, etc, in their premises? 2 - from the premise natted device, when customers go to a university or bank web site, how do you handle randomly changing ip addresses/ports that may occur due to idle time and session tear-down in nat table such that the bank website has issues with seeing your session ip change? -Aaron From michael at wi-fiber.io Tue Feb 27 17:18:50 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Tue, 27 Feb 2018 10:18:50 -0700 Subject: cgnat - how do you handle customer issues In-Reply-To: <2112898300.2375.1519749152853.JavaMail.mhammett@ThunderFuck> References: <000301d3afe8$437dfcc0$ca79f640$@gvtc.com> <2112898300.2375.1519749152853.JavaMail.mhammett@ThunderFuck> Message-ID: For number 2, I'm a fan of what mike suggests. I believe the technical term is MAP-T. For number 1, anyone who wants one, gets one. We provide free public static IP to any customer who asks for one. Another solution, using above solution is to ask them which ports they need, and forward those to them using a port within their assign range. i.e. teach them how to access their home web server using a different port(say 32424, or similar). This won't solve all the issues, which is why we use solution 1. On 27 February 2018 at 09:32, Mike Hammett wrote: > I'm a fan of nailing each customer IP to a particular range of ports on a > given public IP. Real easy to track who did what and to prevent shifting > IPs. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Aaron Gould" > To: Nanog at nanog.org > Sent: Tuesday, February 27, 2018 10:30:21 AM > Subject: cgnat - how do you handle customer issues > > Couple questions please. When you put thousands of customers behind a cgnat > boundary, how do you all handle customer complaints about the following. > > > > 1 - for external connectivity to the customers premise devices, not being > able to access web servers, web cameras, etc, in their premises? > > > > 2 - from the premise natted device, when customers go to a university or > bank web site, how do you handle randomly changing ip addresses/ports that > may occur due to idle time and session tear-down in nat table such that the > bank website has issues with seeing your session ip change? > > > > > > -Aaron > > > From aaron1 at gvtc.com Tue Feb 27 17:52:42 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Tue, 27 Feb 2018 11:52:42 -0600 Subject: cgnat - how do you handle customer issues In-Reply-To: References: <000301d3afe8$437dfcc0$ca79f640$@gvtc.com> <2112898300.2375.1519749152853.JavaMail.mhammett@ThunderFuck> Message-ID: <000901d3aff3$c4a0c2a0$4de247e0$@gvtc.com> Thanks For #2 – what if the ports allocated aren’t enough for the amount of inet traffic the customer site uses ? …is the customer denied service based on insufficient port range ? …or are they assigned another block within that some ip’s range of I think it’s 0-64k or 1025-64k… but how far can you take that before there aren’t anymore port blocks left on that single ip ? …and if you have to allocate that customer another port block from a *different* ip, then we are in the situation of the bank website not liking the fact that the session is bouncing to a different ip maybe ? - Aaron From: Michael Crapse [mailto:michael at wi-fiber.io] Sent: Tuesday, February 27, 2018 11:19 AM To: Mike Hammett Cc: Aaron Gould; NANOG list Subject: Re: cgnat - how do you handle customer issues For number 2, I'm a fan of what mike suggests. I believe the technical term is MAP-T. For number 1, anyone who wants one, gets one. We provide free public static IP to any customer who asks for one. Another solution, using above solution is to ask them which ports they need, and forward those to them using a port within their assign range. i.e. teach them how to access their home web server using a different port(say 32424, or similar). This won't solve all the issues, which is why we use solution 1. On 27 February 2018 at 09:32, Mike Hammett wrote: I'm a fan of nailing each customer IP to a particular range of ports on a given public IP. Real easy to track who did what and to prevent shifting IPs. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Aaron Gould" To: Nanog at nanog.org Sent: Tuesday, February 27, 2018 10:30:21 AM Subject: cgnat - how do you handle customer issues Couple questions please. When you put thousands of customers behind a cgnat boundary, how do you all handle customer complaints about the following. 1 - for external connectivity to the customers premise devices, not being able to access web servers, web cameras, etc, in their premises? 2 - from the premise natted device, when customers go to a university or bank web site, how do you handle randomly changing ip addresses/ports that may occur due to idle time and session tear-down in nat table such that the bank website has issues with seeing your session ip change? -Aaron From CGross at ninestarconnect.com Tue Feb 27 17:58:11 2018 From: CGross at ninestarconnect.com (Chris Gross) Date: Tue, 27 Feb 2018 17:58:11 +0000 Subject: cgnat - how do you handle customer issues In-Reply-To: <000901d3aff3$c4a0c2a0$4de247e0$@gvtc.com> References: <000301d3afe8$437dfcc0$ca79f640$@gvtc.com> <2112898300.2375.1519749152853.JavaMail.mhammett@ThunderFuck> , <000901d3aff3$c4a0c2a0$4de247e0$@gvtc.com> Message-ID: <284559c4-8c85-4b36-bc18-a34f72c2f40b@ninestarconnect.com> I utilize A10 CGNAT that allows dynamic NAT logging, since we're in a similar boat of utilization. This email has been sent from my phone. Please excuse any brevity, typos, or lack of formality. ________________________________ From: Aaron Gould Sent: Tuesday, February 27, 2018 12:54 To: 'Michael Crapse'; 'Mike Hammett' Cc: 'NANOG list' Subject: RE: cgnat - how do you handle customer issues Thanks For #2 – what if the ports allocated aren’t enough for the amount of inet traffic the customer site uses ? …is the customer denied service based on insufficient port range ? …or are they assigned another block within that some ip’s range of I think it’s 0-64k or 1025-64k… but how far can you take that before there aren’t anymore port blocks left on that single ip ? …and if you have to allocate that customer another port block from a *different* ip, then we are in the situation of the bank website not liking the fact that the session is bouncing to a different ip maybe ? - Aaron From: Michael Crapse [mailto:michael at wi-fiber.io] Sent: Tuesday, February 27, 2018 11:19 AM To: Mike Hammett Cc: Aaron Gould; NANOG list Subject: Re: cgnat - how do you handle customer issues For number 2, I'm a fan of what mike suggests. I believe the technical term is MAP-T. For number 1, anyone who wants one, gets one. We provide free public static IP to any customer who asks for one. Another solution, using above solution is to ask them which ports they need, and forward those to them using a port within their assign range. i.e. teach them how to access their home web server using a different port(say 32424, or similar). This won't solve all the issues, which is why we use solution 1. On 27 February 2018 at 09:32, Mike Hammett wrote: I'm a fan of nailing each customer IP to a particular range of ports on a given public IP. Real easy to track who did what and to prevent shifting IPs. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Aaron Gould" To: Nanog at nanog.org Sent: Tuesday, February 27, 2018 10:30:21 AM Subject: cgnat - how do you handle customer issues Couple questions please. When you put thousands of customers behind a cgnat boundary, how do you all handle customer complaints about the following. 1 - for external connectivity to the customers premise devices, not being able to access web servers, web cameras, etc, in their premises? 2 - from the premise natted device, when customers go to a university or bank web site, how do you handle randomly changing ip addresses/ports that may occur due to idle time and session tear-down in nat table such that the bank website has issues with seeing your session ip change? -Aaron From mattlists at rivervalleyinternet.net Tue Feb 27 18:49:32 2018 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Tue, 27 Feb 2018 13:49:32 -0500 Subject: ProofPoint Contact Message-ID: <5a933b5c-b0b4-baa5-84fe-351bca3be7d7@rivervalleyinternet.net> Could a proofpoint e-mail blacklist contact please contact me? We are trying to get a blacklist resolved and can't get ahold of anyone. From jarenangerbauer at gmail.com Tue Feb 27 18:56:09 2018 From: jarenangerbauer at gmail.com (Jaren Angerbauer) Date: Tue, 27 Feb 2018 11:56:09 -0700 Subject: ProofPoint Contact In-Reply-To: <5a933b5c-b0b4-baa5-84fe-351bca3be7d7@rivervalleyinternet.net> References: <5a933b5c-b0b4-baa5-84fe-351bca3be7d7@rivervalleyinternet.net> Message-ID: On Tue, Feb 27, 2018 at 11:49 AM, Matt Hoppes < mattlists at rivervalleyinternet.net> wrote: > Could a proofpoint e-mail blacklist contact please contact me? > We are trying to get a blacklist resolved and can't get ahold of anyone. > Replied off list. Thanks, --Jaren From amitchell at isipp.com Tue Feb 27 19:57:00 2018 From: amitchell at isipp.com (Anne P. Mitchell Esq.) Date: Tue, 27 Feb 2018 12:57:00 -0700 Subject: Craigslist Blocks In-Reply-To: <6431AADA-6EF6-4C3E-8ACD-318ECB8CEA78@gmail.com> References: <68DF8380-3BD8-460D-B343-CC6973F9EB96@silverlakeinternet.com> <06c801d3af0c$b5e70180$21b50480$@fourway.net> <6431AADA-6EF6-4C3E-8ACD-318ECB8CEA78@gmail.com> Message-ID: > >> If someone wants to send me a copy of the block message, and at least one IP that is blocked, I'll see what we can do. This has been passed along to our contact; will let folks know what we hear back. Anne Anne P. Mitchell, Attorney at Law 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 Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center Member, Cal. Bar Cyberspace Law Committee Member, Colorado Cyber Committee Member, Elevations Credit Union Member Council Member, Board of Directors, Asilomar Microcomputer Workshop Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop From bgreene at senki.org Tue Feb 27 20:27:02 2018 From: bgreene at senki.org (Barry Greene) Date: Tue, 27 Feb 2018 15:27:02 -0500 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks Message-ID: Hello Fellow NANOGer, If you have not already seen it, experiences it, or read about it, working to head off another reflection DOS vector. This time it is memcached on port 11211 UDP & TCP. There are active exploits using these ports. Reflection attacks and the memcached is not new. We know how reflection attacks work (send a spoofed packet to a device and have it reflected back (yes please deploy source address validation and BCP 38). Operators are asked to review their networks and consider updating their Exploitable Port Filters (Infrastructure ACLs) to track or block UDP/TCP port 11211 for all ingress and egress traffic. If you do not know about iACLs or Explorable port filters, you can use this white paper details and examples from peers on Exploitable Port Filters: http://www.senki.org/operators-security-toolkit/filtering-exploitable-ports-and-minimizing-risk-to-and-from-your-customers/ Enterprises are also asked to update their iACLs, Exploitable Port Filters, and Firewalls to track or block UDP/TCP port 11211 for all ingress and egress traffic. Deploying these filters will help protect your network, your organization, your customers, and the Internet. Ping me 1:1 if you have questions. Sincerely, -- Barry Raveendran Greene Security Geek helping with OPSEC Trust Mobile: +1 408 218 4669 E-mail: bgreene at senki.org ---------------------------- Resources on memcached Exploit (to evaluate your risk): More information about this attack vector can be found at the following: • JPCERT – memcached のアクセス制御に関する注意喚起 (JPCERT-AT-2018-0009) http://www.jpcert.or.jp/at/2018/at180009.html • Qrator Labs: The memcached amplification attacks reaching 500 Gbps https://medium.com/@qratorlabs/the-memcached-amplification-attack-reaching-500-gbps-b439a7b83c98 • Arbor Networks: memcached Reflection/Amplification Description and DDoS Attack Mitigation Recommendations https://www.arbornetworks.com/blog/asert/memcached-reflection-amplification-description-ddos-attack-mitigation-recommendations/ • Cloudflare: Memcrashed – Major amplification attacks from UDP port 11211 https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/ • Link11: New High-Volume Vector: Memcached Reflection Amplification Attacks https://www.link11.com/en/blog/new-high-volume-vector-memcached-reflection-amplification-attacks/ • Blackhat Talk: The New Page of Injections Book: Memcached Injections by Ivan Novikov https://www.blackhat.com/docs/us-14/materials/us-14-Novikov-The-New-Page-Of-Injections-Book-Memcached-Injections-WP.pdf • Memcache Exploit http://niiconsulting.com/checkmate/2013/05/memcache-exploit/ -------------- 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 cb.list6 at gmail.com Tue Feb 27 20:47:27 2018 From: cb.list6 at gmail.com (Ca By) Date: Tue, 27 Feb 2018 20:47:27 +0000 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: References: Message-ID: Please do take a look at the cloudflare blog specifically as they name and shame OVH and Digital Ocean for being the primary sources of mega crap traffic https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/ Also, policer all UDP all the time... UDP is unsafe at any speed. On Tue, Feb 27, 2018 at 12:28 PM Barry Greene wrote: > Hello Fellow NANOGer, > > If you have not already seen it, experiences it, or read about it, working > to head off another reflection DOS vector. This time it is memcached on > port 11211 UDP & TCP. There are active exploits using these ports. > Reflection attacks and the memcached is not new. We know how reflection > attacks work (send a spoofed packet to a device and have it reflected back > (yes please deploy source address validation and BCP 38). > > Operators are asked to review their networks and consider updating their > Exploitable Port Filters (Infrastructure ACLs) to track or block UDP/TCP > port 11211 for all ingress and egress traffic. If you do not know about > iACLs or Explorable port filters, you can use this white paper details and > examples from peers on Exploitable Port Filters: > http://www.senki.org/operators-security-toolkit/filtering-exploitable-ports-and-minimizing-risk-to-and-from-your-customers/ > > Enterprises are also asked to update their iACLs, Exploitable Port > Filters, and Firewalls to track or block UDP/TCP port 11211 for all ingress > and egress traffic. > > Deploying these filters will help protect your network, your organization, > your customers, and the Internet. > > Ping me 1:1 if you have questions. > > Sincerely, > > -- > Barry Raveendran Greene > Security Geek helping with OPSEC Trust > Mobile: +1 408 218 4669 > E-mail: bgreene at senki.org > > ---------------------------- > Resources on memcached Exploit (to evaluate your risk): > > More information about this attack vector can be found at the following: > > • JPCERT – memcached のアクセス制御に関する注意喚起 (JPCERT-AT-2018-0009) > http://www.jpcert.or.jp/at/2018/at180009.html > • Qrator Labs: The memcached amplification attacks reaching 500 > Gbps > > https://medium.com/@qratorlabs/the-memcached-amplification-attack-reaching-500-gbps-b439a7b83c98 > • Arbor Networks: memcached Reflection/Amplification Description > and DDoS Attack Mitigation Recommendations > > https://www.arbornetworks.com/blog/asert/memcached-reflection-amplification-description-ddos-attack-mitigation-recommendations/ > • Cloudflare: Memcrashed – Major amplification attacks from UDP > port 11211 > > https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/ > • Link11: New High-Volume Vector: Memcached Reflection > Amplification Attacks > > https://www.link11.com/en/blog/new-high-volume-vector-memcached-reflection-amplification-attacks/ > • Blackhat Talk: The New Page of Injections Book: Memcached > Injections by Ivan Novikov > > https://www.blackhat.com/docs/us-14/materials/us-14-Novikov-The-New-Page-Of-Injections-Book-Memcached-Injections-WP.pdf > • Memcache Exploit > http://niiconsulting.com/checkmate/2013/05/memcache-exploit/ > From eric.kuhnke at gmail.com Tue Feb 27 21:16:37 2018 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Tue, 27 Feb 2018 13:16:37 -0800 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: References: Message-ID: I question whether there is *any* high volume hoster out there that has a reputation for successfully addressing abuse issues coming from their customer base, and cuts off services... By high volume hoster I define it as companies where anybody with a credit card can buy a $2 to $15/month VPS/VM in a fully automated process. OVH just happens to be one of the largest and probably ranks in the top 10 worldwide by number of hypervisors and VPS. I doubt whether any of their 30-40 competitors that are smaller than them do much better, considering the ratio of clued and attentive staff to VMs. On Tue, Feb 27, 2018 at 12:47 PM, Ca By wrote: > Please do take a look at the cloudflare blog specifically as they name and > shame OVH and Digital Ocean for being the primary sources of mega crap > traffic > > https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from- > port-11211/ > > Also, policer all UDP all the time... UDP is unsafe at any speed. > > > On Tue, Feb 27, 2018 at 12:28 PM Barry Greene wrote: > > > Hello Fellow NANOGer, > > > > If you have not already seen it, experiences it, or read about it, > working > > to head off another reflection DOS vector. This time it is memcached on > > port 11211 UDP & TCP. There are active exploits using these ports. > > Reflection attacks and the memcached is not new. We know how reflection > > attacks work (send a spoofed packet to a device and have it reflected > back > > (yes please deploy source address validation and BCP 38). > > > > Operators are asked to review their networks and consider updating their > > Exploitable Port Filters (Infrastructure ACLs) to track or block UDP/TCP > > port 11211 for all ingress and egress traffic. If you do not know about > > iACLs or Explorable port filters, you can use this white paper details > and > > examples from peers on Exploitable Port Filters: > > http://www.senki.org/operators-security-toolkit/ > filtering-exploitable-ports-and-minimizing-risk-to-and- > from-your-customers/ > > > > Enterprises are also asked to update their iACLs, Exploitable Port > > Filters, and Firewalls to track or block UDP/TCP port 11211 for all > ingress > > and egress traffic. > > > > Deploying these filters will help protect your network, your > organization, > > your customers, and the Internet. > > > > Ping me 1:1 if you have questions. > > > > Sincerely, > > > > -- > > Barry Raveendran Greene > > Security Geek helping with OPSEC Trust > > Mobile: +1 408 218 4669 > > E-mail: bgreene at senki.org > > > > ---------------------------- > > Resources on memcached Exploit (to evaluate your risk): > > > > More information about this attack vector can be found at the following: > > > > • JPCERT – memcached のアクセス制御に関する注意喚起 (JPCERT-AT-2018-0009) > > http://www.jpcert.or.jp/at/2018/at180009.html > > • Qrator Labs: The memcached amplification attacks reaching 500 > > Gbps > > > > https://medium.com/@qratorlabs/the-memcached- > amplification-attack-reaching-500-gbps-b439a7b83c98 > > • Arbor Networks: memcached Reflection/Amplification Description > > and DDoS Attack Mitigation Recommendations > > > > https://www.arbornetworks.com/blog/asert/memcached- > reflection-amplification-description-ddos-attack- > mitigation-recommendations/ > > • Cloudflare: Memcrashed – Major amplification attacks from UDP > > port 11211 > > > > https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from- > port-11211/ > > • Link11: New High-Volume Vector: Memcached Reflection > > Amplification Attacks > > > > https://www.link11.com/en/blog/new-high-volume-vector- > memcached-reflection-amplification-attacks/ > > • Blackhat Talk: The New Page of Injections Book: Memcached > > Injections by Ivan Novikov > > > > https://www.blackhat.com/docs/us-14/materials/us-14-Novikov- > The-New-Page-Of-Injections-Book-Memcached-Injections-WP.pdf > > • Memcache Exploit > > http://niiconsulting.com/checkmate/2013/05/memcache-exploit/ > > > From steve at blighty.com Tue Feb 27 21:36:56 2018 From: steve at blighty.com (Steve Atkins) Date: Tue, 27 Feb 2018 13:36:56 -0800 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: References: Message-ID: <82EF62CC-53F3-4815-B3B5-3140477BDE75@blighty.com> > On Feb 27, 2018, at 1:16 PM, Eric Kuhnke wrote: > > I question whether there is *any* high volume hoster out there that has a > reputation for successfully addressing abuse issues coming from their > customer base, and cuts off services... By high volume hoster I define it > as companies where anybody with a credit card can buy a $2 to $15/month > VPS/VM in a fully automated process. > > OVH just happens to be one of the largest and probably ranks in the top 10 > worldwide by number of hypervisors and VPS. I doubt whether any of their > 30-40 competitors that are smaller than them do much better, considering > the ratio of clued and attentive staff to VMs. OVH are worse than that. Floods of the same spam coming from the *same IP addresses* for years at a time. Continuous probes. A total refusal to police their network or even respond to reports of issues. They're not a major source of abuse because of their size, it's because they've chosen to be. Cheers, Steve From chip at 2bithacker.net Tue Feb 27 21:52:54 2018 From: chip at 2bithacker.net (Chip Marshall) Date: Tue, 27 Feb 2018 21:52:54 +0000 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: References: Message-ID: <20180227215253.GA694@piranha.2bit.co> On 2018-02-27, Ca By sent: > Please do take a look at the cloudflare blog specifically as they name and > shame OVH and Digital Ocean for being the primary sources of mega crap > traffic > > https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/ > > Also, policer all UDP all the time... UDP is unsafe at any speed. Hi, DigitalOcean here. We've taken steps to mitigate this attack on our network. Also, we've only seen udp/11211 being a problem. I'd be interested to hear of anyone seeing tcp/11211 attacks. -- Chip Marshall http://2bithacker.net/ From cb.list6 at gmail.com Tue Feb 27 22:26:25 2018 From: cb.list6 at gmail.com (Ca By) Date: Tue, 27 Feb 2018 22:26:25 +0000 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: <20180227215253.GA694@piranha.2bit.co> References: <20180227215253.GA694@piranha.2bit.co> Message-ID: On Tue, Feb 27, 2018 at 1:54 PM Chip Marshall wrote: > On 2018-02-27, Ca By sent: > > Please do take a look at the cloudflare blog specifically as they name > and > > shame OVH and Digital Ocean for being the primary sources of mega crap > > traffic > > > > > https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/ > > > > Also, policer all UDP all the time... UDP is unsafe at any speed. > > Hi, DigitalOcean here. We've taken steps to mitigate this attack on our > network. > > Also, we've only seen udp/11211 being a problem. I'd be interested to > hear of anyone seeing tcp/11211 attacks. > Thanks DO! Just udp. > -- > Chip Marshall > http://2bithacker.net/ > From justin at cloudflare.com Tue Feb 27 22:31:54 2018 From: justin at cloudflare.com (Justin Paine) Date: Tue, 27 Feb 2018 14:31:54 -0800 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: <20180227215253.GA694@piranha.2bit.co> References: <20180227215253.GA694@piranha.2bit.co> Message-ID: Thanks Chip! ____________ Justin Paine Head of Trust & Safety Cloudflare Inc. PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D On Tue, Feb 27, 2018 at 1:52 PM, Chip Marshall wrote: > On 2018-02-27, Ca By sent: >> Please do take a look at the cloudflare blog specifically as they name and >> shame OVH and Digital Ocean for being the primary sources of mega crap >> traffic >> >> https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/ >> >> Also, policer all UDP all the time... UDP is unsafe at any speed. > > Hi, DigitalOcean here. We've taken steps to mitigate this attack on our network. > > Also, we've only seen udp/11211 being a problem. I'd be interested to > hear of anyone seeing tcp/11211 attacks. > > -- > Chip Marshall > http://2bithacker.net/ From lee at asgard.org Tue Feb 27 22:41:56 2018 From: lee at asgard.org (Lee Howard) Date: Tue, 27 Feb 2018 17:41:56 -0500 Subject: cgnat - how do you handle customer issues In-Reply-To: <000301d3afe8$437dfcc0$ca79f640$@gvtc.com> References: <000301d3afe8$437dfcc0$ca79f640$@gvtc.com> Message-ID: <76f79a9a-7f3f-6f97-05f3-9e4f968ae074@asgard.org> On 02/27/2018 11:30 AM, Aaron Gould wrote: > Couple questions please. When you put thousands of customers behind a cgnat > boundary, how do you all handle customer complaints about the following. > > > > 1 - for external connectivity to the customers premise devices, not being > able to access web servers, web cameras, etc, in their premises? > For web servers, you gently remind them of their ToS, and offer to upgrade them to a business account. You offer to upgrade them to native IPv4, for a fee, and suggest they contact the manufacturer to see why it doesn't support IPv6. I've heard of PCP for this, but never seen it in production on CPE. I saw an early prototype of DS-Lite that included a customer portal that would allow the customer to enable port forwarding, but I can't imagine trying to walk a customer through two layers of port forwarding. Most of these consumer electronics devices long ago started using ICE/TURN/STUN, and/or the company's web portal as their external communication platform. Doesn't mean all of them do. > > 2 - from the premise natted device, when customers go to a university or > bank web site, how do you handle randomly changing ip addresses/ports that > may occur due to idle time and session tear-down in nat table such that the > bank website has issues with seeing your session ip change? > > You can extend your idle timers, of course, but only so much before you're squatting on all your ports. After that, it's down to explaining to the university, bank, etc. that they need IPv6 if they want their web site to be reachable. Or at least they need to extend their idle timers. Lee > > > > -Aaron > > From lee at asgard.org Tue Feb 27 22:42:50 2018 From: lee at asgard.org (Lee Howard) Date: Tue, 27 Feb 2018 17:42:50 -0500 Subject: cgnat - how do you handle customer issues In-Reply-To: <000901d3aff3$c4a0c2a0$4de247e0$@gvtc.com> References: <000301d3afe8$437dfcc0$ca79f640$@gvtc.com> <2112898300.2375.1519749152853.JavaMail.mhammett@ThunderFuck> <000901d3aff3$c4a0c2a0$4de247e0$@gvtc.com> Message-ID: On 02/27/2018 12:52 PM, Aaron Gould wrote: > Thanks > > > > For #2 – what if the ports allocated aren’t enough for the amount of inet traffic the customer site uses ? …is the customer denied service based on insufficient port range ? …or are they assigned another block within that some ip’s range of I think it’s 0-64k or 1025-64k… but how far can you take that before there aren’t anymore port blocks left on that single ip ? …and if you have to allocate that customer another port block from a *different* ip, then we are in the situation of the bank website not liking the fact that the session is bouncing to a different ip maybe ? Yes, common problem, and the session just fails (TCY SYN dropped) because of insufficient ports. Most CGNs allow you to configure a range of ports for a customer, and reserve an additional range if they need more ports. Yes, if you allocate 1000 ports for one IPv4 address to each of 50 customers and they all need hundreds more ports than that, you're going to run out of ports and connections fail. This is why you have IPv6. Even while many web sites and apps don't support IPv4, enough do that it relieves some pressure on your CGN. Lee > > > - Aaron > > > > From: Michael Crapse [mailto:michael at wi-fiber.io] > Sent: Tuesday, February 27, 2018 11:19 AM > To: Mike Hammett > Cc: Aaron Gould; NANOG list > Subject: Re: cgnat - how do you handle customer issues > > > > For number 2, I'm a fan of what mike suggests. I believe the technical term is MAP-T. > For number 1, anyone who wants one, gets one. We provide free public static IP to any customer who asks for one. Another solution, using above solution is to ask them which ports they need, and forward those to them using a port within their assign range. i.e. teach them how to access their home web server using a different port(say 32424, or similar). This won't solve all the issues, which is why we use solution 1. > > > > On 27 February 2018 at 09:32, Mike Hammett wrote: > > I'm a fan of nailing each customer IP to a particular range of ports on a given public IP. Real easy to track who did what and to prevent shifting IPs. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Aaron Gould" > To: Nanog at nanog.org > Sent: Tuesday, February 27, 2018 10:30:21 AM > Subject: cgnat - how do you handle customer issues > > > Couple questions please. When you put thousands of customers behind a cgnat > boundary, how do you all handle customer complaints about the following. > > > > 1 - for external connectivity to the customers premise devices, not being > able to access web servers, web cameras, etc, in their premises? > > > > 2 - from the premise natted device, when customers go to a university or > bank web site, how do you handle randomly changing ip addresses/ports that > may occur due to idle time and session tear-down in nat table such that the > bank website has issues with seeing your session ip change? > > > > > > -Aaron > > > > > > From rdobbins at arbor.net Tue Feb 27 23:10:27 2018 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 28 Feb 2018 06:10:27 +0700 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: References: <20180227215253.GA694@piranha.2bit.co> Message-ID: <3EF4D323-7971-4E73-8BDA-4C39E8116BC8@arbor.net> On 28 Feb 2018, at 5:26, Ca By wrote: > Just udp. This Arbor Threat Summary discusses the TCP issue, as well, FWIW: 'It should also be noted that memcached priming queries can also be directed towards TCP/11211 on abusable memcached servers. TCP is not currently considered a high-risk memcached reflection/amplification transport as TCP queries cannot be reliably spoofed.' We also recommend implementing situationally-appropriate network access policies at the IDC edge which disallow unwanted UDP/11211 as well as TCP/11211 from reaching abusable memcached deployments. ----------------------------------- Roland Dobbins From goemon at sasami.anime.net Wed Feb 28 00:13:23 2018 From: goemon at sasami.anime.net (Dan Hollis) Date: Tue, 27 Feb 2018 16:13:23 -0800 (PST) Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: References: Message-ID: OVH does not suprise me in the least. Maybe this is finally what it will take to get people to de-peer them. -Dan On Tue, 27 Feb 2018, Ca By wrote: > Please do take a look at the cloudflare blog specifically as they name and > shame OVH and Digital Ocean for being the primary sources of mega crap > traffic > > https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/ > > Also, policer all UDP all the time... UDP is unsafe at any speed. > > > On Tue, Feb 27, 2018 at 12:28 PM Barry Greene wrote: > >> Hello Fellow NANOGer, >> >> If you have not already seen it, experiences it, or read about it, working >> to head off another reflection DOS vector. This time it is memcached on >> port 11211 UDP & TCP. There are active exploits using these ports. >> Reflection attacks and the memcached is not new. We know how reflection >> attacks work (send a spoofed packet to a device and have it reflected back >> (yes please deploy source address validation and BCP 38). >> >> Operators are asked to review their networks and consider updating their >> Exploitable Port Filters (Infrastructure ACLs) to track or block UDP/TCP >> port 11211 for all ingress and egress traffic. If you do not know about >> iACLs or Explorable port filters, you can use this white paper details and >> examples from peers on Exploitable Port Filters: >> http://www.senki.org/operators-security-toolkit/filtering-exploitable-ports-and-minimizing-risk-to-and-from-your-customers/ >> >> Enterprises are also asked to update their iACLs, Exploitable Port >> Filters, and Firewalls to track or block UDP/TCP port 11211 for all ingress >> and egress traffic. >> >> Deploying these filters will help protect your network, your organization, >> your customers, and the Internet. >> >> Ping me 1:1 if you have questions. >> >> Sincerely, >> >> -- >> Barry Raveendran Greene >> Security Geek helping with OPSEC Trust >> Mobile: +1 408 218 4669 >> E-mail: bgreene at senki.org >> >> ---------------------------- >> Resources on memcached Exploit (to evaluate your risk): >> >> More information about this attack vector can be found at the following: >> >> • JPCERT – memcached のアクセス制御に関する注意喚起 (JPCERT-AT-2018-0009) >> http://www.jpcert.or.jp/at/2018/at180009.html >> • Qrator Labs: The memcached amplification attacks reaching 500 >> Gbps >> >> https://medium.com/@qratorlabs/the-memcached-amplification-attack-reaching-500-gbps-b439a7b83c98 >> • Arbor Networks: memcached Reflection/Amplification Description >> and DDoS Attack Mitigation Recommendations >> >> https://www.arbornetworks.com/blog/asert/memcached-reflection-amplification-description-ddos-attack-mitigation-recommendations/ >> • Cloudflare: Memcrashed – Major amplification attacks from UDP >> port 11211 >> >> https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/ >> • Link11: New High-Volume Vector: Memcached Reflection >> Amplification Attacks >> >> https://www.link11.com/en/blog/new-high-volume-vector-memcached-reflection-amplification-attacks/ >> • Blackhat Talk: The New Page of Injections Book: Memcached >> Injections by Ivan Novikov >> >> https://www.blackhat.com/docs/us-14/materials/us-14-Novikov-The-New-Page-Of-Injections-Book-Memcached-Injections-WP.pdf >> • Memcache Exploit >> http://niiconsulting.com/checkmate/2013/05/memcache-exploit/ >> > From fhr at fhrnet.eu Wed Feb 28 00:29:54 2018 From: fhr at fhrnet.eu (Filip Hruska) Date: Wed, 28 Feb 2018 00:29:54 +0000 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: References: Message-ID: <01020161d9d0c8a9-096fa330-4b76-4395-8ca9-ad035ac9f3e0-000000@eu-west-1.amazonses.com> This is just stupid. OVH is one of the largest server providers in the world - of course they will be at the top of that list. What exactly should they do, according to you? Why should people de-peer them? Regards, Filip Hruska > > On 28 Feb 2018 at 1:13 am, wrote: > > > OVH does not suprise me in the least. Maybe this is finally what it will take to get people to de-peer them. -Dan On Tue, 27 Feb 2018, Ca By wrote: > Please do take a look at the cloudflare blog specifically as they name and > shame OVH and Digital Ocean for being the primary sources of mega crap > traffic > > https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/ > > Also, policer all UDP all the time... UDP is unsafe at any speed. > > > On Tue, Feb 27, 2018 at 12:28 PM Barry Greene wrote: > >> Hello Fellow NANOGer, >> >> If you have not already seen it, experiences it, or read about it, working >> to head off another reflection DOS vector. This time it is memcached on >> port 11211 UDP & TCP. There are active exploits using these ports. >> Reflection attacks and the memcached is not new. We know how reflection >> attacks work (send a spoofed packet to a device and have it reflected back >> (yes please deploy source address validation and BCP 38). >> >> Operators are asked to review their networks and consider updating their >> Exploitable Port Filters (Infrastructure ACLs) to track or block UDP/TCP >> port 11211 for all ingress and egress traffic. If you do not know about >> iACLs or Explorable port filters, you can use this white paper details and >> examples from peers on Exploitable Port Filters: >> http://www.senki.org/operators-security-toolkit/filtering-exploitable-ports-and-minimizing-risk-to-and-from-your-customers/ >> >> Enterprises are also asked to update their iACLs, Exploitable Port >> Filters, and Firewalls to track or block UDP/TCP port 11211 for all ingress >> and egress traffic. >> >> Deploying these filters will help protect your network, your organization, >> your customers, and the Internet. >> >> Ping me 1:1 if you have questions. >> >> Sincerely, >> >> -- >> Barry Raveendran Greene >> Security Geek helping with OPSEC Trust >> Mobile: +1 408 218 4669 >> E-mail: bgreene at senki.org >> >> ---------------------------- >> Resources on memcached Exploit (to evaluate your risk): >> >> More information about this attack vector can be found at the following: >> >> • JPCERT – memcached のアクセス制御に関する注意喚起 (JPCERT-AT-2018-0009) >> http://www.jpcert.or.jp/at/2018/at180009.html >> • Qrator Labs: The memcached amplification attacks reaching 500 >> Gbps >> >> https://medium.com/@qratorlabs/the-memcached-amplification-attack-reaching-500-gbps-b439a7b83c98 >> • Arbor Networks: memcached Reflection/Amplification Description >> and DDoS Attack Mitigation Recommendations >> >> https://www.arbornetworks.com/blog/asert/memcached-reflection-amplification-description-ddos-attack-mitigation-recommendations/ >> • Cloudflare: Memcrashed – Major amplification attacks from UDP >> port 11211 >> >> https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/ >> • Link11: New High-Volume Vector: Memcached Reflection >> Amplification Attacks >> >> https://www.link11.com/en/blog/new-high-volume-vector-memcached-reflection-amplification-attacks/ >> • Blackhat Talk: The New Page of Injections Book: Memcached >> Injections by Ivan Novikov >> >> https://www.blackhat.com/docs/us-14/materials/us-14-Novikov-The-New-Page-Of-Injections-Book-Memcached-Injections-WP.pdf >> • Memcache Exploit >> http://niiconsulting.com/checkmate/2013/05/memcache-exploit/ >> > > From steve at blighty.com Wed Feb 28 00:38:18 2018 From: steve at blighty.com (Steve Atkins) Date: Tue, 27 Feb 2018 16:38:18 -0800 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: <01020161d9d0c8a9-096fa330-4b76-4395-8ca9-ad035ac9f3e0-000000@eu-west-1.amazonses.com> References: <01020161d9d0c8a9-096fa330-4b76-4395-8ca9-ad035ac9f3e0-000000@eu-west-1.amazonses.com> Message-ID: <6CA05446-F5D3-4087-9434-0CAA83C81C8A@blighty.com> > On Feb 27, 2018, at 4:29 PM, Filip Hruska wrote: > > > > This is just stupid. > > > > OVH is one of the largest server providers in the world - of course they will be at the top of that list. > > What exactly should they do, according to you? Read their abuse@ alias. Shut down those customers who are being abusive. Currently they do neither. Every so often they'll privately admit that they've been doing an unconscionably bad job of mitigating abuse from their networks and promise to do better, then don't. Given some of their customers have been consistently abusive for years from the same domain and the same IP address the problem isn't "Oh, the bad people keep signing up with new credit cards! Oh, poor us!" or any other reasoning based on being a large, inexpensive provider. > Why should people de-peer them? If the overall cost of the bad traffic exceeds the benefit of the good traffic. I'm sure it doesn't, but that people are even suggesting it is telling. Cheers, Steve From cb.list6 at gmail.com Wed Feb 28 00:41:43 2018 From: cb.list6 at gmail.com (Ca By) Date: Wed, 28 Feb 2018 00:41:43 +0000 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: <01020161d9d0c8a9-096fa330-4b76-4395-8ca9-ad035ac9f3e0-000000@eu-west-1.amazonses.com> References: <01020161d9d0c8a9-096fa330-4b76-4395-8ca9-ad035ac9f3e0-000000@eu-west-1.amazonses.com> Message-ID: On Tue, Feb 27, 2018 at 4:29 PM Filip Hruska wrote: > This is just stupid. > > OVH is one of the largest server providers in the world - of course they > will be at the top of that list. > What exactly should they do, according to you? > They should have rough norms enforced on their traffic behavior , especially around udp. If they do 1tbs of udp, they should police to 3tbs or something similar. Why should people de-peer them? > Abuse. But abuse happens, failure to fix chronic is a reason to depeer... not one off. Personally, i do not peer with ovh because i need my upstream to rtbh their traffic. > Regards, > Filip Hruska > > On 28 Feb 2018 at 1:13 am, > wrote: > > OVH does not suprise me in the least. > > Maybe this is finally what it will take to get people to de-peer them. > > -Dan > > On Tue, 27 Feb 2018, Ca By wrote: > > > Please do take a look at the cloudflare blog specifically as they name and > > shame OVH and Digital Ocean for being the primary sources of mega crap > > traffic > > > > https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/ > > > > Also, policer all UDP all the time... UDP is unsafe at any speed. > > > > > > On Tue, Feb 27, 2018 at 12:28 PM Barry Greene wrote: > > > >> Hello Fellow NANOGer, > >> > >> If you have not already seen it, experiences it, or read about it, working > >> to head off another reflection DOS vector. This time it is memcached on > >> port 11211 UDP & TCP. There are active exploits using these ports. > >> Reflection attacks and the memcached is not new. We know how reflection > >> attacks work (send a spoofed packet to a device and have it reflected back > >> (yes please deploy source address validation and BCP 38). > >> > >> Operators are asked to review their networks and consider updating their > >> Exploitable Port Filters (Infrastructure ACLs) to track or block UDP/TCP > >> port 11211 for all ingress and egress traffic. If you do not know about > >> iACLs or Explorable port filters, you can use this white paper details and > >> examples from peers on Exploitable Port Filters: > >> http://www.senki.org/operators-security-toolkit/filtering-exploitable-ports-and-minimizing-risk-to-and-from-your-customers/ > > >> > >> Enterprises are also asked to update their iACLs, Exploitable Port > >> Filters, and Firewalls to track or block UDP/TCP port 11211 for all ingress > >> and egress traffic. > >> > >> Deploying these filters will help protect your network, your organization, > >> your customers, and the Internet. > >> > >> Ping me 1:1 if you have questions. > >> > >> Sincerely, > >> > >> -- > >> Barry Raveendran Greene > >> Security Geek helping with OPSEC Trust > >> Mobile: +1 408 218 4669 > >> E-mail: bgreene at senki.org > >> > >> ---------------------------- > >> Resources on memcached Exploit (to evaluate your risk): > >> > >> More information about this attack vector can be found at the following: > >> > >> • JPCERT – memcached のアクセス制御に関する注意喚起 (JPCERT-AT-2018-0009) > >> http://www.jpcert.or.jp/at/2018/at180009.html > >> • Qrator Labs: The memcached amplification attacks reaching 500 > >> Gbps > >> > >> https://medium.com/@qratorlabs/the-memcached-amplification-attack-reaching-500-gbps-b439a7b83c98 > >> • Arbor Networks: memcached Reflection/Amplification Description > >> and DDoS Attack Mitigation Recommendations > >> > >> https://www.arbornetworks.com/blog/asert/memcached-reflection-amplification-description-ddos-attack-mitigation-recommendations/ > >> • Cloudflare: Memcrashed – Major amplification attacks from UDP > >> port 11211 > >> > >> https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/ > >> • Link11: New High-Volume Vector: Memcached Reflection > >> Amplification Attacks > >> > >> https://www.link11.com/en/blog/new-high-volume-vector-memcached-reflection-amplification-attacks/ > >> • Blackhat Talk: The New Page of Injections Book: Memcached > >> Injections by Ivan Novikov > >> > >> https://www.blackhat.com/docs/us-14/materials/us-14-Novikov-The-New-Page-Of-Injections-Book-Memcached-Injections-WP.pdf > >> • Memcache Exploit > >> http://niiconsulting.com/checkmate/2013/05/memcache-exploit/ > >> > > > > > From owen at delong.com Wed Feb 28 02:05:23 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 27 Feb 2018 18:05:23 -0800 Subject: cgnat - how do you handle customer issues In-Reply-To: References: <000301d3afe8$437dfcc0$ca79f640$@gvtc.com> <2112898300.2375.1519749152853.JavaMail.mhammett@ThunderFuck> <000901d3aff3$c4a0c2a0$4de247e0$@gvtc.com> Message-ID: <768B9EAE-243D-41F8-87F0-EDEAB1064784@delong.com> There’s also the issue of what a customer who needs something like GRE or IKE to work does from behind a CGNAT where there aren’t port numbers available for multiplexing. Owen > On Feb 27, 2018, at 2:42 PM, Lee Howard wrote: > > > > On 02/27/2018 12:52 PM, Aaron Gould wrote: >> Thanks >> >> >> For #2 – what if the ports allocated aren’t enough for the amount of inet traffic the customer site uses ? …is the customer denied service based on insufficient port range ? …or are they assigned another block within that some ip’s range of I think it’s 0-64k or 1025-64k… but how far can you take that before there aren’t anymore port blocks left on that single ip ? …and if you have to allocate that customer another port block from a *different* ip, then we are in the situation of the bank website not liking the fact that the session is bouncing to a different ip maybe ? > > > Yes, common problem, and the session just fails (TCY SYN dropped) because of insufficient ports. > Most CGNs allow you to configure a range of ports for a customer, and reserve an additional range if they need more ports. Yes, if you allocate 1000 ports for one IPv4 address to each of 50 customers and they all need hundreds more ports than that, you're going to run out of ports and connections fail. > > This is why you have IPv6. Even while many web sites and apps don't support IPv4, enough do that it relieves some pressure on your CGN. > > Lee >> >> - Aaron >> >> >> From: Michael Crapse [mailto:michael at wi-fiber.io] >> Sent: Tuesday, February 27, 2018 11:19 AM >> To: Mike Hammett >> Cc: Aaron Gould; NANOG list >> Subject: Re: cgnat - how do you handle customer issues >> >> >> For number 2, I'm a fan of what mike suggests. I believe the technical term is MAP-T. >> For number 1, anyone who wants one, gets one. We provide free public static IP to any customer who asks for one. Another solution, using above solution is to ask them which ports they need, and forward those to them using a port within their assign range. i.e. teach them how to access their home web server using a different port(say 32424, or similar). This won't solve all the issues, which is why we use solution 1. >> >> >> On 27 February 2018 at 09:32, Mike Hammett wrote: >> >> I'm a fan of nailing each customer IP to a particular range of ports on a given public IP. Real easy to track who did what and to prevent shifting IPs. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> >> Midwest Internet Exchange >> >> The Brothers WISP >> >> ----- Original Message ----- >> >> From: "Aaron Gould" >> To: Nanog at nanog.org >> Sent: Tuesday, February 27, 2018 10:30:21 AM >> Subject: cgnat - how do you handle customer issues >> >> >> Couple questions please. When you put thousands of customers behind a cgnat >> boundary, how do you all handle customer complaints about the following. >> >> >> >> 1 - for external connectivity to the customers premise devices, not being >> able to access web servers, web cameras, etc, in their premises? >> >> >> >> 2 - from the premise natted device, when customers go to a university or >> bank web site, how do you handle randomly changing ip addresses/ports that >> may occur due to idle time and session tear-down in nat table such that the >> bank website has issues with seeing your session ip change? >> >> >> >> >> >> -Aaron >> >> >> >> >> From goemon at sasami.anime.net Wed Feb 28 03:07:25 2018 From: goemon at sasami.anime.net (Dan Hollis) Date: Tue, 27 Feb 2018 19:07:25 -0800 (PST) Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: <01020161d9d0c8a9-096fa330-4b76-4395-8ca9-ad035ac9f3e0-000000@eu-west-1.amazonses.com> References: <01020161d9d0c8a9-096fa330-4b76-4395-8ca9-ad035ac9f3e0-000000@eu-west-1.amazonses.com> Message-ID: On Wed, 28 Feb 2018, Filip Hruska wrote: > What exactly should they do, according to you? read and act on abuse reports. > Why should people de-peer them? because they ignore abuse reports. -Dan From rsk at gsp.org Wed Feb 28 11:28:42 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 28 Feb 2018 06:28:42 -0500 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: References: Message-ID: <20180228112842.GA30776@gsp.org> On Tue, Feb 27, 2018 at 04:13:23PM -0800, Dan Hollis wrote: > OVH does not suprise me in the least. > > Maybe this is finally what it will take to get people to de-peer them. Let's hope so. There are two, and only two possibilities. 1. They know what's going on in their operation. In that case, they're fully aware of all the spam, phishing, attacks, abuse, etc., and are choosing to actively support and encourage them because it's profitable. 2. They don't know what's going on in their operation. In that case, they're amazingly ignorant and stunningly incompetent -- because we all know what's going on in it and we're not even there. But in either case, the operational impact on us is exactly the same and so is the solution. ---rsk From rsk at gsp.org Wed Feb 28 11:51:35 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 28 Feb 2018 06:51:35 -0500 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: <01020161d9d0c8a9-096fa330-4b76-4395-8ca9-ad035ac9f3e0-000000@eu-west-1.amazonses.com> References: <01020161d9d0c8a9-096fa330-4b76-4395-8ca9-ad035ac9f3e0-000000@eu-west-1.amazonses.com> Message-ID: <20180228115135.GA31953@gsp.org> On Wed, Feb 28, 2018 at 12:29:54AM +0000, Filip Hruska wrote: > OVH is one of the largest server providers in the world - of course they will be at the top of that list. Of course not. The larger an operation, the greater its responsibility to the rest of the Internet -- because the more damage it can and will do if it's not professionally operated. Moreover, the larger the operation the easier abuse control is and the less tolerance any of us should have for failure. I don't want to hear any clueless whining from ignorant newbies about how-oh-so-terribly-hard-it-is-with-a-billion-users. If you don't know how run it, or you're too lazy, cheap, and stupid to run it, you should never have built it: you're simply not good enough. ---rsk From jean at ddostest.me Wed Feb 28 12:01:34 2018 From: jean at ddostest.me (Jean | ddostest.me) Date: Wed, 28 Feb 2018 07:01:34 -0500 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: <20180228115135.GA31953@gsp.org> References: <01020161d9d0c8a9-096fa330-4b76-4395-8ca9-ad035ac9f3e0-000000@eu-west-1.amazonses.com> <20180228115135.GA31953@gsp.org> Message-ID: <770bca26-db0c-d3af-c4a1-55fafcf34965@ddostest.me> I ran a full scan of the internet with zmap to find vulnerable memcached servers from an AWS server. AWS received an abuse report and forwarded it to me. I deleted the VM and the case was close... LOL OVH Is not dumb. Do you know how easy it is to deploy a VM today with all the automated frameworks? Jean On 02/28/2018 06:51 AM, Rich Kulawiec wrote: > On Wed, Feb 28, 2018 at 12:29:54AM +0000, Filip Hruska wrote: >> OVH is one of the largest server providers in the world - of course they will be at the top of that list. > Of course not. The larger an operation, the greater its responsibility > to the rest of the Internet -- because the more damage it can and will do > if it's not professionally operated. Moreover, the larger the operation > the easier abuse control is and the less tolerance any of us should have > for failure. I don't want to hear any clueless whining from ignorant > newbies about how-oh-so-terribly-hard-it-is-with-a-billion-users. If you > don't know how run it, or you're too lazy, cheap, and stupid to run it, > you should never have built it: you're simply not good enough. > > ---rsk From Brian at ampr.org Wed Feb 28 12:13:26 2018 From: Brian at ampr.org (Brian Kantor) Date: Wed, 28 Feb 2018 04:13:26 -0800 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks Message-ID: <20180228121326.GB29944@meow.BKantor.net> It seems to me that since peer pressure hasn't worked, it's time to resort to legal means. Have a talk with your own organization's lawyers, explain to them how much time and money those folks are costing your organization, and see if there isn't something you can do in the way of billing for the time, small claims court, stern letters from your lawyers to their legal department, criminal illegal-computer-access complaints, etc. - Brian From job at ntt.net Wed Feb 28 12:31:11 2018 From: job at ntt.net (Job Snijders) Date: Wed, 28 Feb 2018 13:31:11 +0100 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: <20180228112842.GA30776@gsp.org> References: <20180228112842.GA30776@gsp.org> Message-ID: <20180228123111.GF5969@hanna.meerval.net> Dear all, Before the group takes on the pitchforks and torches and travels down to the hosting providers' headquarters - let's take a step back and look at the root of this issue: the memcached software has failed both the Internet community and its own memcached users. It is INSANE that memcached is/was[1] shipping with default settings that make the daemon listen and respond on UDP on INADDR_ANY. Did nobody take notes during the protocol wars where we were fodder for all the CHARGEN & NTP ordnance? The memcached software shipped with a crazy default that required no authentication - allowing everyone to interact with the daemon. This is an incredibly risky proposition for memcached users from a confidentiality perspective; and on top of that the amplification factor is up to 15,000x. WHAT?! And this isn't even new information, open key/value stores have been a security research topic for a number of years, these folks reported that in the 2015/2016 time frame they observed more than 100,000 open memcached instances: https://aperture-labs.org/pdf/safeconf16.pdf Vendors need to ensure that a default installation of their software does not pose an immediate liability to the user itself and those around them. No software is deployed in a vacuum. A great example of how to approach things is the behavior of the PowerDNS DNS recursor: this recursor - out of the box - binds to only 127.0.0.1, and blocks queries from RFC 1918 space. An operator has to consciously perform multiple steps to make it into the danger zone. This is how things should be. Kind regards, Job [1]: https://github.com/memcached/memcached/commit/dbb7a8af90054bf4ef51f5814ef7ceb17d83d974 ps. promiscuous defaults are bad, mmkay? Ask your BGP vendor for RFC 8212 support today! :-) From denys at visp.net.lb Wed Feb 28 12:42:37 2018 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Wed, 28 Feb 2018 14:42:37 +0200 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: <20180228123111.GF5969@hanna.meerval.net> References: <20180228112842.GA30776@gsp.org> <20180228123111.GF5969@hanna.meerval.net> Message-ID: <028f32868f0f00d1195ce7ae606d0665@nuclearcat.com> I want to add one software vendor, who is major contributor to ddos attacks. Mikrotik till now shipping their quite popular routers, with wide open DNS recursor, that don't have even mechanism for ACL in it. Significant part of DNS amplification attacks are such Mikrotik recursors. They don't care till now. On 2018-02-28 14:31, Job Snijders wrote: > Dear all, > > Before the group takes on the pitchforks and torches and travels down > to > the hosting providers' headquarters - let's take a step back and look > at > the root of this issue: the memcached software has failed both the > Internet community and its own memcached users. > > It is INSANE that memcached is/was[1] shipping with default settings > that make the daemon listen and respond on UDP on INADDR_ANY. Did > nobody > take notes during the protocol wars where we were fodder for all the > CHARGEN & NTP ordnance? > > The memcached software shipped with a crazy default that required no > authentication - allowing everyone to interact with the daemon. This is > an incredibly risky proposition for memcached users from a > confidentiality perspective; and on top of that the amplification > factor > is up to 15,000x. WHAT?! > > And this isn't even new information, open key/value stores have been a > security research topic for a number of years, these folks reported > that > in the 2015/2016 time frame they observed more than 100,000 open > memcached instances: https://aperture-labs.org/pdf/safeconf16.pdf > > Vendors need to ensure that a default installation of their software > does not pose an immediate liability to the user itself and those > around > them. No software is deployed in a vacuum. > > A great example of how to approach things is the behavior of the > PowerDNS DNS recursor: this recursor - out of the box - binds to only > 127.0.0.1, and blocks queries from RFC 1918 space. An operator has to > consciously perform multiple steps to make it into the danger zone. > This is how things should be. > > Kind regards, > > Job > > [1]: > https://github.com/memcached/memcached/commit/dbb7a8af90054bf4ef51f5814ef7ceb17d83d974 > > ps. promiscuous defaults are bad, mmkay? > Ask your BGP vendor for RFC 8212 support today! :-) From mattlists at rivervalleyinternet.net Wed Feb 28 18:21:45 2018 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Wed, 28 Feb 2018 13:21:45 -0500 Subject: TEKTONIC CONTACT Message-ID: Could someone from Tektonic VPS please contact me off list about routing issues? From Grzegorz at Janoszka.pl Wed Feb 28 20:23:20 2018 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Wed, 28 Feb 2018 21:23:20 +0100 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: <028f32868f0f00d1195ce7ae606d0665@nuclearcat.com> References: <20180228112842.GA30776@gsp.org> <20180228123111.GF5969@hanna.meerval.net> <028f32868f0f00d1195ce7ae606d0665@nuclearcat.com> Message-ID: <0f94938c-cf53-310a-43d6-1c93fefca0f6@Janoszka.pl> On 2018-02-28 13:42, Denys Fedoryshchenko wrote: > I want to add one software vendor, who is major contributor to ddos > attacks. > Mikrotik till now shipping their quite popular routers, with wide open > DNS recursor, > that don't have even mechanism for ACL in it. Significant part of DNS > amplification attacks > are such Mikrotik recursors. > They don't care till now. I have mixed experiences with Mikrotik, but I don't think they would do such a stupid thing. A friend of my has three offices and each one has mikrotik to form tunnels and one domain for all the company. He is not too IP savvy, so he copy-pasted the VPN config from internet and left the rest as it was. His routers are not open DNS resolvers. When I asked them I got no reply and their logs showed: _drop input: in:ether1 out:(unknown 0), src-mac 00:AB:CD:81:c2:71, proto UDP, AAA.47.138.134:9082->BBB.146.251.103:53, len 51 His settings showed the DNS server ON with all the queries for the local network and he actually had a toggle "allow remote queries" on, but his routers were not open resolvers. -- Grzegorz Janoszka From nanog at ics-il.net Wed Feb 28 20:57:42 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 28 Feb 2018 14:57:42 -0600 (CST) Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: <028f32868f0f00d1195ce7ae606d0665@nuclearcat.com> References: <20180228112842.GA30776@gsp.org> <20180228123111.GF5969@hanna.meerval.net> <028f32868f0f00d1195ce7ae606d0665@nuclearcat.com> Message-ID: <1096782347.332.1519851458500.JavaMail.mhammett@ThunderFuck> They ship it by default firewalled from the Internet. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Denys Fedoryshchenko" To: nanog at nanog.org Sent: Wednesday, February 28, 2018 6:42:37 AM Subject: Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks I want to add one software vendor, who is major contributor to ddos attacks. Mikrotik till now shipping their quite popular routers, with wide open DNS recursor, that don't have even mechanism for ACL in it. Significant part of DNS amplification attacks are such Mikrotik recursors. They don't care till now. On 2018-02-28 14:31, Job Snijders wrote: > Dear all, > > Before the group takes on the pitchforks and torches and travels down > to > the hosting providers' headquarters - let's take a step back and look > at > the root of this issue: the memcached software has failed both the > Internet community and its own memcached users. > > It is INSANE that memcached is/was[1] shipping with default settings > that make the daemon listen and respond on UDP on INADDR_ANY. Did > nobody > take notes during the protocol wars where we were fodder for all the > CHARGEN & NTP ordnance? > > The memcached software shipped with a crazy default that required no > authentication - allowing everyone to interact with the daemon. This is > an incredibly risky proposition for memcached users from a > confidentiality perspective; and on top of that the amplification > factor > is up to 15,000x. WHAT?! > > And this isn't even new information, open key/value stores have been a > security research topic for a number of years, these folks reported > that > in the 2015/2016 time frame they observed more than 100,000 open > memcached instances: https://aperture-labs.org/pdf/safeconf16.pdf > > Vendors need to ensure that a default installation of their software > does not pose an immediate liability to the user itself and those > around > them. No software is deployed in a vacuum. > > A great example of how to approach things is the behavior of the > PowerDNS DNS recursor: this recursor - out of the box - binds to only > 127.0.0.1, and blocks queries from RFC 1918 space. An operator has to > consciously perform multiple steps to make it into the danger zone. > This is how things should be. > > Kind regards, > > Job > > [1]: > https://github.com/memcached/memcached/commit/dbb7a8af90054bf4ef51f5814ef7ceb17d83d974 > > ps. promiscuous defaults are bad, mmkay? > Ask your BGP vendor for RFC 8212 support today! :-) From jeffmeal at microsoft.com Wed Feb 28 21:11:42 2018 From: jeffmeal at microsoft.com (Jeff Mealiffe) Date: Wed, 28 Feb 2018 21:11:42 +0000 Subject: MSFT reverse IP failure? In-Reply-To: <20180227000443.GG23308@sizone.org> References: <20180226213100.GA19634@sizone.org> <20180227000443.GG23308@sizone.org> Message-ID: I've escalated this to the team responsible for the tool. Will report back when we have some resolution. Thanks for calling out the issue. -----Original Message----- From: NANOG On Behalf Of Ken Chase Sent: Monday, February 26, 2018 4:05 PM To: Christian Kuhtz Cc: nanog at nanog.org Subject: Re: MSFT reverse IP failure? Im not exactly sure what this is either, the client sent me a screenshot that called itself the "microsoft connectivity analyzer", which had several steps testing deliverability of email to their domain, with the final test of an actual test email delivery failing. /kc On Mon, Feb 26, 2018 at 11:25:59PM +0000, Christian Kuhtz said: >Ken, > >A little difficult to say what this without knowing what 13.67.59.89 actually is. If this is an Azure deployment, ReverseFqdn needs to be populated on the Public IP address resource. Please take a look here https://docs.microsoft.com/en-us/azure/dns/dns-reverse-dns-for-azure-services > >Thanks, >Christian > > >-----Original Message----- >From: NANOG On Behalf Of Ken Chase >Sent: Monday, February 26, 2018 1:31 PM >To: nanog at nanog.org >Subject: Re: MSFT reverse IP failure? > >Having a client doing a test from the MSFT exchange tools site, which is failing. > >NOQUEUE: reject: RCPT from unknown[13.67.59.89]: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [13.67.59.89]; > >NetRange: 13.64.0.0 - 13.107.255.255 >CIDR: 13.96.0.0/13, 13.104.0.0/14, 13.64.0.0/11 >NetName: MSFT > >A bit of an oversight? > >/kc >-- >Ken Chase - math at sizone.org Guelph Canada From jacob at rezero.org Wed Feb 28 21:39:25 2018 From: jacob at rezero.org (Jacob Slater) Date: Wed, 28 Feb 2018 16:39:25 -0500 Subject: ALTDB maintainer creation Message-ID: Hello all, Any chance anyone has a contact for any of the ALTDB admins? I put in a maintainer creation request several months ago and haven't heard back. Working with an upstream who will only take ALTDB or LOAs and would like to avoid having to due LOAs in the future. Thanks all, Jacob Slater