- Test - lists.nanog.org

Power cut if temps are too high
by Dovid Bender 29 May '19

29 May '19

12 17

Anyone from OpenDNS
by sam＠circlenet.us 28 May '19

28 May '19

Good afternoon list, Anyone on the list from OpenDNS willing to contact me offlist? Somehow my $dayjobs SSL cert if being munged on your service. Thank you Sam Moats

1 0

China Telecom people at NANOG 75
by Töma Gavrichenkov 28 May '19

28 May '19

Peace, There was some sales manager at the San Francisco meeting, from China Telecom, whom I had a chat with. I have lost their business card since then, and the attendee list for the 75th meeting is already missing from cvent dot com. If they are reading the mailing list, then I'd ask them to drop me a message off-list. Have a good day. | Töma Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: ximaera(a)gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58

1 0

Re: Spamming of NANOG list members
by Brian Kantor 24 May '19

24 May '19

An interesting development: my posting to this list a few minutes ago seems to have triggered an autoresponder asking me to confirm the issuance of a support ticket by Liquid Web, whoever they are. - Brian > > On Fri, May 24, 2019 at 08:17:31AM -0700, Brian Kantor wrote: > > > Anne, the way that such addresses are often harvested is that one of > > > the spammers (or his agent) becomes a member of the list and simply > > > records the addresses of persons posting to the list. They then > > > get spammed.

2 1

Call for Participation: NIST Workshop on Security for IPv6 Enabled Enterprises - June 13, 2019 @ NCCoE
by Montgomery, Douglas (Fed) 24 May '19

24 May '19

NIST NCCoE will host a workshop on Security for IPv6 Enabled Enterprises. The focus will be to identify and develop plans to address security challenges / barriers to full IPv6 deployment in enterprise settings. Please see the call for participation below for more details and to register. https://www.nccoe.nist.gov/events/security-ipv6-enabled-enterprises Questions about workshop participation should be sent to: ipv6-transition(a)nist.gov dougm -- Doug Montgomery, Manager Internet & Scalable Systems Research @ NIST

1 0

Google weird routing?
by Matt Harris 24 May '19

24 May '19

Hey folks, Looking at an mtr going out via a couple of different transit circuits, Google seems to be doing weird things. RTT pinging google.com is coming up with like 250-300ms times, but mtr's are telling me my packets are hitting google's network very quickly. Google's network then seems to send them on a rather long trip before reaching the google.com frontend servers. An example: 6 213.200.123.170 (213.200.123.170) 3.450 ms ae-1-3502.ear4.Newark1.Level3.net (4.69.211.177) 1.469 ms 1.634 ms 7 72.14.213.34 (72.14.213.34) 1.336 ms 1.372 ms 1.381 ms 8 108.170.248.52 (108.170.248.52) 2.474 ms * 2.150 ms 9 216.239.62.170 (216.239.62.170) 1.401 ms 216.239.62.150 (216.239.62.150) 1.400 ms 216.239.62.168 (216.239.62.168) 2.985 ms 10 216.239.57.136 (216.239.57.136) 20.043 ms 216.239.59.0 (216.239.59.0) 20.235 ms 216.239.57.196 (216.239.57.196) 20.382 ms 11 209.85.254.241 (209.85.254.241) 2.155 ms 108.170.235.61 (108.170.235.61) 74.295 ms 209.85.241.43 (209.85.241.43) 78.593 ms 12 72.14.239.155 (72.14.239.155) 96.254 ms 216.239.57.196 (216.239.57.196) 19.672 ms 72.14.239.155 (72.14.239.155) 96.328 ms 13 108.170.235.217 (108.170.235.217) 153.391 ms 108.170.236.119 (108.170.236.119) 153.445 ms 108.170.235.221 (108.170.235.221) 152.858 ms 14 172.253.51.111 (172.253.51.111) 220.084 ms 66.249.94.141 (66.249.94.141) 218.039 ms 72.14.239.197 (72.14.239.197) 75.008 ms 15 209.85.241.86 (209.85.241.86) 276.281 ms 72.14.235.160 (72.14.235.160) 276.104 ms 277.497 ms 16 108.170.235.105 (108.170.235.105) 217.030 ms 209.85.248.4 (209.85.248.4) 217.338 ms 66.249.94.141 (66.249.94.141) 217.573 ms 17 72.14.236.75 (72.14.236.75) 276.349 ms 276.097 ms 72.14.239.235 (72.14.239.235) 277.180 ms 18 bom07s01-in-f14.1e100.net (216.58.199.142) 276.139 ms 276.980 ms 64.233.174.27 (64.233.174.27) 279.212 ms As you can see from this traceroute output, Level3 is delivering my packets to Google (hop#7 and beyond) just fine, however all of the hops including #7 and beyond are all inside of google's network. My packets are originating from AS 394102. Anyone from google have any idea what's going on there? Thanks, Matt

7 13

Grande Communications Contact
by Conrad Rockenhaus 23 May '19

23 May '19

Hello, Does anyone have a Grande Communications Contact? Thanks, Conrad

1 1

Doha dark fiber
by Pui Edylie 22 May '19

22 May '19

Anyone knows anyone has dark fiber in doha and has a pop in Singapore?Thank you.RegardsEdySent from my Samsung Galaxy smartphone.

2 1

Free Program to take netflow
by Dennis Burgess 22 May '19

22 May '19

I am looking for a free program to take netflow and output what the top traffic ASes to and from my AS are. Something that we can look at every once in a while, and/or spin up and get data then shutdown.. Just have two ports need netflow from currently. Thanks in advance. [LTI-Full_175px] Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition" Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net<http://www.linktechs.net/> Create Wireless Coverage's with www.towercoverage.com

11 15

DHCPv6-PD relay route injection - standard?
by Brandon Martin 21 May '19

21 May '19

Is there a standard that defines/recommends behavior for route injection of snooped DHCPv6-PD (or IA, I guess) assignments on routers running relay agents? That is, snooping or otherwise examining a relayed DHCPv6 response for a delegated prefix (or IA, if you want) and installing a quasi-static route toward the relevant next-hop based on the lifetime of the delegation. Typical redistribution can then be used to put it in IGP if you want. It seems to be a common feature - Cisco ("Relay Agent Notification" on IOS-XE), Juniper ("DHCPv6-PD Route injection" on JunOS), and Arista ("ipv6 dhcp relay install routes" on EOS), and Ruckus ("Relay Agent Prefix Delegation Notification" on FastIron) all seem to support it. Google has, however, failed me at finding any standard that defines or recommends corresponding behavior. RFC 8415 punts on the issue: > the server may need a protocol or other > out-of-band communication to configure routing information for > delegated prefixes It would be nice to have some sort of semi-normative behavior to at least refer to if only to use it to prod vendors. -- Brandon Martin

5 11