December 2016 - Test - lists.nanog.org

IPv6 Residential Deployment Survey
by John Curran 24 Jan '19

24 Jan '19

NANOGers - If you are providing residential Internet service with IPv6 (or are a customer of same), please take a moment to complete Jordi’s survey - this will help provide insight into the actual technical practices being used in residential IPv6 deployment. More details in attached email - Thanks! /John Begin forwarded message: From: John Curran <jcurran(a)arin.net<mailto:jcurran@arin.net>> Subject: [arin-ppml] IPv6 Residential Deployment Survey Date: May 22, 2016 at 6:24:17 AM GMT+2 To: ARIN PPML <ppml(a)arin.net<mailto:ppml@arin.net>> Folks - Jordi Palet Martínez is conducting a brief survey regarding IPv6 deployment in residential Internet service. Having insight into the various practices that are in use may help to inform IPv6 number resource policy development, and thus I ask that you take a moment to complete the survey if you are providing such services (whether production or trial basis.) Jordi notes - "The results will be published and updated every month or so - No personal data will be published. (If you know your network, it takes less than 2 minutes to complete it) The survey can be responded even if is not yet a commercial service, and customers can also respond, not just the ISP. However, to avoid duplicate data, make sure to include the country and ISP name.” The IPv6 Residential Deployment Survey may be found here - <http://survey.consulintel.es/index.php/175122> Thanks! /John John Curran President and CEO ARIN

9 16

Quanta LB4M
by Mike Hammett 20 Apr '18

20 Apr '18

Has anyone gotten a "non-factory" firmware to go onto these guys? There are a couple threads on Google that are inconclusive. There are rumors that it's the same as a Dell something or an HP something else, but no one has outright said, "I loaded a Dell XXXX firmware onto it and solved all of the random ass bugs." If I didn't already have a couple of stacked Extreme x400s, I'd consider these at home, but they're somewhat buggy. Quanta told me to contact whomever I bought it from... but I don't think the random guy on eBay is going to have much of anything useful to say. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com

4 7

Why the internal network delays, Gmail?
by Nate Metheny 21 Jun '17

21 Jun '17

Help (and hi)! I work in higher education and we've been experiencing problems with Google delaying or queuing email for delivery to our domain. Here's some truncated email headers: ** Example 1: X-Received: by 10.237.55.65 with SMTP id i59mr10986018qtb.62.1472137448952; Thu, 25 Aug 2016 08:04:08 -0700 (PDT) Received: by mail-qt0-f175.google.com with SMTP id u25so27419242qtb.1 for <@***>; Thu, 25 Aug 2016 12:05:46 -0700 (PDT) ** Example 2: X-Received: by 10.36.1.75 with SMTP id 72mr5275579itk.40.1472130531887; Thu, 25 Aug 2016 06:08:51 -0700 (PDT) Received: by mail-it0-f48.google.com with SMTP id x131so289116132ite.0 for <@***>; Thu, 25 Aug 2016 11:50:42 -0700 (PDT) In both of these examples, these emails haven't even left Google's internal network yet; I'm getting blamed for these delays, however there is no delay in receiving these emails after they leave Google's network. Are other people having this same problem? I've tested delivery to my network from many outside sources and all SMTP requests go through without delay; this issue seems be exclusive to Google-hosted and Gmail accounts and domains. -- Nate <natemetheny(a)gmail.com>nate(a)dopedesign.com

14 21

Multi-port RFC2544/EtherSAM loopback appliance
by Jason Lixfeld 25 May '17

25 May '17

Group, I'm looking for options and opinions on a cost effective, multi-port (6'ish port SFP/SFP+) RFC2544/EtherSAM rack appliance that can act as the remote/loopback for our field installers' portable RFC2544/EtherSAM enabled Exfo test sets. I came across XenaNetworks XenaCompact which looks like it would fit the bill, but I'm sure there are others (save Ixia, Exfo and Fluke, which I'm pretty much excluding by default because I imagine they are likely completely out to lunch on price relative to the extremely simplified feature set we require). Thanks in advance.

5 4

BCP 38 coverage if top x providers ...
by Frank Bulk 24 Mar '17

24 Mar '17

My google fu is failing me, but I believe there was a NANOG posting a year or two ago that mentioned that if the top x providers would implement BCP 38 then y% of the traffic (or Internet) would be de-spoofed. The point was that we don't even need everyone to implement BCP 38, but if the largest (transit?) providers did it, then UDP reflection attacks could be minimized. If someone can recall the key words in that posting and dig it up, that would be much appreciated. Frank

6 6

Re: Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization
by Scott Weeks 09 Jan '17

09 Jan '17

:: and minimal time zones (still 5 hours :: between New York and Hawaii though). Apologies, I can't resist. :) Sometimes it's 6 hours and some times it's 5 between Hawaii and the East Coast. Hawaii is *always* -10 GMT. We don't do daylight savings time. scott

3 2

Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization
by Chris Grundemann 06 Jan '17

06 Jan '17

Hail NANOGers! A global hospitality organization with 100+ locations recently asked us how to weigh the importance of standardizing infrastructure across all their locations versus allowing each international location to select on their own kit. My first instinct was to jump on my favorite search engine and look for an authoritative document covering the topic. To my surprise I have not been able to find such a thing. So I've begun to write one myself, and as I start I've realized that: a) This is likely to be a document that will be helpful to the wider community, and b) This is likely a topic that many of you have a great deal of knowledge and personal experience. If you have pointers to an existing doc, please share. If you have a case study, lesson learned, data point, or even just a strong opinion; I'd love to hear it! My intention is to put this together BCOP style, but with more of a focus on why rather than how this time around. Feel free to reply on or off list. Thanks in advance for your input! Cheers, ~Chris PS - I won't use any direct quotes without advance permission and I'll provide attribution to all that contribute meaningfully. -- @ChrisGrundemann http://chrisgrundemann.com

12 15

microducts
by Baldur Norddahl 01 Jan '17

01 Jan '17

Hi I am planing a new FTTH outside plant deployment. We are going to use microducts but which system is the best? I see many resources describing the options available but few if any will take a stance on which one to choose. Some of the choices are: 1) Ducts with larger fixed tubes for direct burial 12/8 mm. Typically 7 ducts in a larger tube. 2) Ducts with smaller fixed tubes 5/3,5 mm. Typically 24 small tubes with one larger centre tube for backbone. 3) Ducts for direct burial arranged in a stripe side by side instead of in a tube. 12/8 mm ducts. Makes it easier to access the tubes and avoids problems with tubes of different length on the drum. And many more variations. I am planing to deploy in an area with the average distance between houses of 10 meters (actually 20 meters but we can serve both sides of the road from one walkway, so that makes it 10 meters average). I want to support a low level of initial uptake of just 10%. The problem is that most sources assume that I am planing for anything between 100% and 50%. I do expect that we will get more customers than just 10%, but the solution might become too expensive, if I have to pay all costs upfront years before I have any hope of that many customers. Some people say just put a lot of plastic down because it is so cheap. But it really isn't. I need to put down the correct amount of tubes because tubes are everything but cheap. I also need a system that is easy and quick to work with because labour is very expensive (but also very skilled) around here. I would appreciate any pointers to articles about this subject. Regards, Baldur

4 3

Quick name and shame -- Apologies but...
by bzs＠theworld.com 30 Dec '16

30 Dec '16

For years, YEARS, Microsoft's OUTLOOK.COM has flooded us with this sort of dictionary spamming on a daily basis. Is there anyone at MS who cares? Surely it's not that difficult to notice someone is blasting stuff like this from your servers every single day for years? Or are your servers just an out of control free-for-all? Do you even know who is using them? If you need another few zillion records like this for motivation just ask. 2016-12-30T16:34:29.342803-05:00 pcls5 sendmail[5627]: NOUSER: jmarkus1 relay=mail-bn3nam01on0058.outbound.protection.outlook.com [104.47.33.58] 2016-12-30T16:34:29.593566-05:00 pcls5 sendmail[5627]: NOUSER: jmarkus2 relay=mail-bn3nam01on0058.outbound.protection.outlook.com [104.47.33.58] 2016-12-30T16:34:29.844258-05:00 pcls5 sendmail[5627]: NOUSER: jmarkus3 relay=mail-bn3nam01on0058.outbound.protection.outlook.com [104.47.33.58] 2016-12-30T16:34:30.094905-05:00 pcls5 sendmail[5627]: NOUSER: jmarkus4 relay=mail-bn3nam01on0058.outbound.protection.outlook.com [104.47.33.58] 2016-12-30T16:35:23.984284-05:00 pcls5 sendmail[7053]: NOUSER: ehansen1 relay=mail-sn1nam02hn0244.outbound.protection.outlook.com [104.47.36.244] 2016-12-30T16:35:24.235025-05:00 pcls5 sendmail[7053]: NOUSER: ehansen10 relay=mail-sn1nam02hn0244.outbound.protection.outlook.com [104.47.36.244] 2016-12-30T16:35:24.485697-05:00 pcls5 sendmail[7053]: NOUSER: ehansen5 relay=mail-sn1nam02hn0244.outbound.protection.outlook.com [104.47.36.244] 2016-12-30T16:35:24.736408-05:00 pcls5 sendmail[7053]: NOUSER: ehansen2 relay=mail-sn1nam02hn0244.outbound.protection.outlook.com [104.47.36.244] 2016-12-30T16:35:24.987137-05:00 pcls5 sendmail[7053]: NOUSER: ehansen3 relay=mail-sn1nam02hn0244.outbound.protection.outlook.com [104.47.36.244] 2016-12-30T16:36:01.134355-05:00 pcls5 sendmail[7889]: NOUSER: efd5 relay=mail-bl2nam02hn0233.outbound.protection.outlook.com [104.47.38.233] 2016-12-30T16:36:01.385161-05:00 pcls5 sendmail[7889]: NOUSER: efd6 relay=mail-bl2nam02hn0233.outbound.protection.outlook.com [104.47.38.233] 2016-12-30T16:36:01.635940-05:00 pcls5 sendmail[7889]: NOUSER: efd7 relay=mail-bl2nam02hn0233.outbound.protection.outlook.com [104.47.38.233] 2016-12-30T16:36:01.886771-05:00 pcls5 sendmail[7889]: NOUSER: efd8 relay=mail-bl2nam02hn0233.outbound.protection.outlook.com [104.47.38.233] 2016-12-30T16:36:02.137626-05:00 pcls5 sendmail[7889]: NOUSER: efd9 relay=mail-bl2nam02hn0233.outbound.protection.outlook.com [104.47.38.233] 2016-12-30T16:41:25.012620-05:00 pcls5 sendmail[15054]: NOUSER: josephl6 relay=mail-dm3nam03hn0218.outbound.protection.outlook.com [104.47.41.218] 2016-12-30T16:41:25.263296-05:00 pcls5 sendmail[15054]: NOUSER: josephl4 relay=mail-dm3nam03hn0218.outbound.protection.outlook.com [104.47.41.218] 2016-12-30T16:41:25.514058-05:00 pcls5 sendmail[15054]: NOUSER: josephl7 relay=mail-dm3nam03hn0218.outbound.protection.outlook.com [104.47.41.218] 2016-12-30T16:41:25.764786-05:00 pcls5 sendmail[15054]: NOUSER: josephl8 relay=mail-dm3nam03hn0218.outbound.protection.outlook.com [104.47.41.218] 2016-12-30T16:41:26.015469-05:00 pcls5 sendmail[15054]: NOUSER: josephl5 relay=mail-dm3nam03hn0218.outbound.protection.outlook.com [104.47.41.218] -- -Barry Shein Software Tool & Die | bzs(a)TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

2 1

Re: Recent NTP pool traffic increase
by Gary E. Miller 30 Dec '16

30 Dec '16

Yo All! Someone on nanog was reporrting on the new NTP mystery. He suggested doing a dump similar to this: # tcpdump -nvvi eth0 port 123 |grep "Originator - Transmit Timestamp:" And I do indeed get odd results. Some on my local network... This is from a chronyd host to an ntpsec host. I monitor them both continuously and both seem to be keeping good time. 17:36:11.369329 IP (tos 0x0, ttl 64, id 21405, offset 0, flags [DF], proto UDP ( 17), length 76) 204.17.205.7.50937 > 204.17.205.27.123: [udp sum ok] NTPv4, length 48 Client, Leap indicator: clock unsynchronized (192), Stratum 0 (unspecifi ed), poll 6 (64s), precision 32 Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec) Reference Timestamp: 0.000000000 Originator Timestamp: 3691013707.207257069 (2016/12/17 17:35:07) Receive Timestamp: 276521666.321684728 (2044/11/11 10:02:42) Transmit Timestamp: 3684123061.899235956 (2016/09/29 00:31:01) Originator - Receive Timestamp: +880475255.114427658 Originator - Transmit Timestamp: -6890645.308021113 That 'Receive Timestamp' is strange. Here is another one from the same chronyd host, to another ntpsec host: 17:36:23.395415 IP (tos 0x0, ttl 64, id 3599, offset 0, flags [DF], proto UDP (1 7), length 76) 204.17.205.7.33551 > 204.17.205.1.123: [udp sum ok] NTPv4, length 48 Client, Leap indicator: clock unsynchronized (192), Stratum 0 (unspecifi ed), poll 6 (64s), precision 32 Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec) Reference Timestamp: 0.000000000 Originator Timestamp: 3691013718.824150890 (2016/12/17 17:35:18) Receive Timestamp: 1779216017.648483479 (2092/06/24 18:08:33) Transmit Timestamp: 1405803137.064633429 (2080/08/24 20:20:33) Originator - Receive Timestamp: -1911797701.175667410 Originator - Transmit Timestamp: +2009756714.240482539 Note both the 'Receive Timestamp' and 'Transmit Timestamp' are both strange. All three hosts have GPS for local time. Here is one from a laptop, running chrony, that has not GPS: 17:36:52.643814 IP (tos 0x0, ttl 64, id 24624, offset 0, flags [DF], proto UDP ( 17), length 76) 204.17.205.21.41485 > 204.17.205.8.123: [udp sum ok] NTPv4, length 48 Client, Leap indicator: (0), Stratum 0 (unspecified), poll 6 (64s), pre cision 32 Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec) Reference Timestamp: 0.000000000 Originator Timestamp: 3691013747.797479298 (2016/12/17 17:35:47) Receive Timestamp: 317494016.811980062 (2046/02/28 15:15:12) Transmit Timestamp: 127487236.597620268 (2040/02/21 11:35:32) Originator - Receive Timestamp: +921447565.014500764 Originator - Transmit Timestamp: +731440784.800140969 I have only seen this oddity from chronyd hosts... RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem(a)rellim.com Tel:+1 541 382 8588

26 50