- NANOG - lists.nanog.org

Anyone heard from Jared lately?
by Jay Ashworth 20 Nov '14

20 Nov '14

He generally provides same-day service on email, but... Hope all is well. Cheers, -- jra Moderator @ outages -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.

2 1

USA Power Grid compromised?
by JoeSox 20 Nov '14

20 Nov '14

Am I the only Network Admin wondering how this can happen and why its still an issue if it was discovered in 2011? Now I never worked in the Energy field so I am in the dark (pun intended I guess) on how serious the Public utilities address these issues. They should have redundant systems so they can clean (reimage, etc) whatever is there and be done with it?? ref: NSA chief admits China could cripple U.S. power grid, financial networks http://www.zdnet.com/nsa-chief-admits-china-could-cripple-u-s-power-grid-fi… http://abcnews.go.com/US/trojan-horse-bug-lurking-vital-us-computers-2011/s… -- Later, Joe

1 0

Need Godaddy Contact
by Larry Krone 20 Nov '14

20 Nov '14

I have a question that Godaddy support will not answer. My son moved a word press site to Godaddy from another host. Apparently, unbeknowest to him, the original wordpress site was also the email host. The mail was moved from the old server to the new server but the email was never properly set up via the GoDaddy Cpanel Question for a Godaddy Guru. if we set up the email through the cpanel, will it erase any mail currently in the accounts on the linux wordpress machine, or even acknowledge that the exist email is there? Any help would be GREATLY appreciated and Thanks.. Larry

3 2

FYI, Level 3 issues in Dallas
by David Hubbard 20 Nov '14

20 Nov '14

We have some customers unable to access their websites, seeing this on the way to them: 4 ae-0-11.bar2.Tampa1.Level3.net (4.69.137.110) 0.343 ms 0.423 ms 0.406 ms 5 ae-12-12.ebr1.Dallas1.Level3.net (4.69.137.118) 23.940 ms 23.470 ms 23.426 ms 6 ae-71-71.csw2.Dallas1.Level3.net (4.69.151.137) 24.026 ms ae-81-81.csw3.Dallas1.Level3.net (4.69.151.149) 24.007 ms ae-61-61.csw1.Dallas1.Level3.net (4.69.151.125) 23.855 ms 7 ae-3-80.edge10.Dallas1.Level3.net (4.69.145.146) 23.361 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 23.329 ms ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 23.936 ms 8 vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 23.378 ms vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.387 ms vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 23.963 ms 9 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 23.357 ms ae-1-60.edge9.Dallas1.Level3.net (4.69.145.16) 22.779 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 62.640 ms 10 vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 24.179 ms 23.297 ms 23.403 ms 11 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 65.617 ms ae-2-70.edge2.Dallas1.Level3.net (4.69.145.75) 23.286 ms ae-1-60.edge10.Dallas1.Level3.net (4.69.145.18) 23.553 ms 12 vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.303 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 24.027 ms 24.028 ms 13 ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 24.018 ms ae-3-80.edge10.Dallas1.Level3.net (4.69.145.146) 23.374 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 23.342 ms 14 vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 24.068 ms vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.361 ms 23.348 ms 15 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 24.023 ms ae-1-60.edge9.Dallas1.Level3.net (4.69.145.16) 22.740 ms ae-4-90.edge10.Dallas1.Level3.net (4.69.145.210) 23.963 ms 16 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 23.420 ms vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.400 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 25.317 ms 17 ae-2-70.edge10.Dallas1.Level3.net (4.69.145.82) 23.985 ms ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 23.476 ms ae-3-80.edge9.Dallas1.Level3.net (4.69.145.144) 51.762 ms 18 vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 23.416 ms vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 24.062 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 24.051 ms 19 ae-3-80.edge9.Dallas1.Level3.net (4.69.145.144) 44.798 ms ae-3-80.edge10.Dallas1.Level3.net (4.69.145.146) 22.856 ms ae-1-60.edge10.Dallas1.Level3.net (4.69.145.18) 22.891 ms 20 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 23.433 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 25.333 ms vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.367 ms 21 ae-2-70.edge2.Dallas1.Level3.net (4.69.145.75) 23.475 ms ae-4-90.edge9.Dallas1.Level3.net (4.69.145.208) 23.476 ms ae-1-60.edge9.Dallas1.Level3.net (4.69.145.16) 64.753 ms 22 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 24.008 ms 24.043 ms vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 23.508 ms 23 ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 23.505 ms ae-3-80.edge9.Dallas1.Level3.net (4.69.145.144) 23.958 ms ae-4-90.edge9.Dallas1.Level3.net (4.69.145.208) 24.058 ms 24 vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.429 ms vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 23.623 ms 25.547 ms 25 ae-2-70.edge10.Dallas1.Level3.net (4.69.145.82) 23.491 ms ae-3-80.edge9.Dallas1.Level3.net (4.69.145.144) 23.551 ms ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 24.078 ms 26 vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 24.472 ms 24.144 ms 24.080 ms 27 ae-1-60.edge10.Dallas1.Level3.net (4.69.145.18) 28.121 ms ae-3-80.edge10.Dallas1.Level3.net (4.69.145.146) 22.848 ms ae-4-90.edge9.Dallas1.Level3.net (4.69.145.208) 24.090 ms 28 vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 23.509 ms 24.056 ms vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 23.522 ms 29 ae-2-70.edge2.Dallas1.Level3.net (4.69.145.75) 24.161 ms 24.153 ms ae-4-90.edge9.Dallas1.Level3.net (4.69.145.208) 24.130 ms 30 vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.606 ms 23.482 ms vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 23.580 ms

5 6

Brian Krebs' new book is out.
by Roland Dobbins 20 Nov '14

20 Nov '14

This is an important book - well worth your time, and, more importantly, accessible to non-specialists (such as BDMs): <http://www.amazon.com/Spam-Nation-Organized-Cybercrime--Epidemic-ebook/dp/B…> <http://www.amazon.com/Spam-Nation-Organized-Cybercrime--Epidemic/dp/1402295…> It's not about spam, per se. It's about the global underground economy, and includes a lot of insight into internecine warfare amongst online criminals, including DDoS attacks with huge collateral damage footprints; and also talks about the origins of the Blue Security fiasco and subsequent DDoS, DDoS attacks against Spamhaus, etc. ----------------------------------- Roland Dobbins <rdobbins(a)arbor.net>

2 1

Overlay as a link
by Glen Kent 19 Nov '14

19 Nov '14

Hi, When youre doing overlay networking, i.e., you have tunnels from one virtual machine in a DC to another in another DC, then can i consider a tunnel between the two virtual machines as a "physical link" that exists in a regular network? I am wondering on what possibly can be the difference between a tunnel being considered as a link and a true physical link. I could run routing algorithms on both. The tunnel would only be considered as an interface. Or i could run BFD on both. Once difference that i can think of is that while you can send multiple frames together on a tunnel (for example if there are ECMP paths within the tunnel), you may not be able to send multiple frames at the same time on a physical link. Anything else? Glen

3 2

DNS Lookup - Filter "localhost"
by Radke, Justin 18 Nov '14

18 Nov '14

This past weekend we started receiving bursts of lookups on our DNS server for "localhost." We blocked our subscriber abusing this lookup (most assuredly malware and not intentional) but curious what safeguards you put in place for DOS attacks on your DNS servers. 1. As an ISP do you see a problem with blocking localhost on your DNS servers? (we don't see any validity to these requests but checking with you to see if we've overlooked something). 2. Do you have an actual localhost zone that issues 127.0.0.1? 3. Do you block >512 Bytes DNS requests? 4. Do you block non-UDP DNS requests or rate-limit requests? 5. Anything else you block/filter on your DNS servers? -=JGR

5 4

Route Science
by Greg Grabowski 17 Nov '14

17 Nov '14

Does anyone still have a Route Science box running out there? Our enterprise still has a box running and working. Just curious..;-)

7 6

Re: A case against vendor-locking optical modules
by Clayton Zekelman 17 Nov '14

17 Nov '14

At 02:49 PM 17/11/2014, Scott Voll wrote: >I've asked the same question and got the answer that there is a REAL BIG >chip manufacture that was having huge system issue and told the vendor that >they were going to rip out all the manufactures routing / switching >equipment if they didn't get it fixed. > >after the manufacture send engineering staff on site they found that the >problem was not the routers or switches but the SFP's that the Chip >manufacture had purchased. After replacing the SFP's they had no problems. > I've heard that explanation a number of times in various forms. I suspect it was an explanation crafted to counter the argument. Regardless, it should have been simple enough to rule out the optics with proper diagnostics and swapping out of suspect units. The real reason of course is margin http://www.lightreading.com/optical/optical-components/ciscos-secret-franch… --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409

1 0

Linux router traffic monitoring, how? netflow?
by Eliezer Croitoru 16 Nov '14

16 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey all, I have a tiny linux router based on ubuntu and sometimes I get a massive load of UDP traffic because of one of the PCs in the network. Usually I handle the situation with a strict block using iptables. The main issue is to find it due to the load. For now I am monitoring the traffic load using MRTG but it won't notify me. I can try to use nagios to monitor traffic load for a period of time but before I start working on it I want another person opinion and options. I have seen netflow in the past but never actually used it. Thanks in advance, Eliezer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUZOXKAAoJENxnfXtQ8ZQUnCcIAJn/3LQa1CKl1mBGiWHUvrEZ GZIPYKDlDWscVaq2VhJQH/ZcUqX5466YTSLsFQBaCEynLfc4vgk5gBZzyLK9TI1R MSDXAQNYvqRGnDG5rBrthCCvSA8UZyqVH9feSXw+U8aiwZcmQz4SSVv86yy288qP eFlerXq43QvSzXgMPFFrzwVzcwY3UVg0VMxlqIRIl+sB8dfg6ofau61/lax9ALQ4 cfxE674vxKtQsf319lJTmq/3JMvANzZNYbX0+XnLNIDaCciM/GTT/Xvasq+oigm2 IE4T0098KMUyBdJx5ewX5d+rawI2283euiY0Co5UnfCYzBnJTj4xZR32Tip53lM= =gZaZ -----END PGP SIGNATURE-----

8 8