November 2013 - Test - lists.nanog.org

Any issues in asia-pac due to typhoon
by Grant Ridder 08 Nov '13

08 Nov '13

Hi Everyone, I am curious to see if anyone has been any issues or outages due to the typhoon in the area of the Philippines. Satellite: http://www.pagasa.dost.gov.ph/wb/sat_images/satpic.jpg http://www.usatoday.com/story/news/world/2013/11/07/philippines-typhoon/346… -Grant P.S. - Also sent this to outages list earlier

2 1

Bright House Networks Voice Contact
by Nick Olsen 08 Nov '13

08 Nov '13

Is anyone from the voice side of Bright House Networks Central Florida Division around? I seem to be hitting a CNAM cache on their network and was hoping to get it dumped. Thanks! Nick Olsen Network Operations (855) FLSPEED x106

2 1

Upstream / Handoff UPS?
by Kenny Kant 07 Nov '13

07 Nov '13

We have tons of circuits with various providers. Often times the demarc / handoff switch from the provider is not running on battery backup. Sometimes if the demarc device is located in the same room as our equipment we mitigate this and plug the device into our backup systems. Am I wrong to think that the demarc from the provider is a sacred thing that should only be touched by said provider. Thus they should provide their own battery system? Is it normal for this equipment not to be battery protected? We are not dealing with any crazy SLA's however I think it would be standard build practice to put UPS's on your gear. Even if its small handoff switch sitting right next to my switch. :) Kenny

5 4

advice on BGP + CARP setup on FreeBSD
by Antoine Beaupré 07 Nov '13

07 Nov '13

Hi fellow operators, We are slowly and carefully joining the fray of autonomous systems and started announcing our own netblock, a first test that started last week. So far, things are going well, but before going further along this setup, I would be curious to hear experience from other operators about the plan we are thinking of deploying. Our requirements: * free software, as much as possible * inexpensive * using existing operating system expertise (FreeBSD or Debian) So far, we have: * our own ASN * a /21 assigned by ARIN * two uplinks deployed (Netelligent and Cogent) * Netelligent announces 3 /24 netblocks for us * we announce the last /24 through a BGP link with cogent We have some horrible diagrams describing the setup here: https://wiki.koumbit.net/RoutingService/RoadMap As you can see, the uplinks are connected directly into a switch, in two separate VLANs. The reason for this is we want to be able to hotswap the routers in case of a hardware failure, but we have understood from Cogent's documentation that this is not a good practice because the links appears up even if the router goes down. What is your opinion on this? Also, we currently testing OpenBGPd for the announcements, and we are very pleased with it. The syntax is clear and it just works, with minimal memory usage: https://wiki.koumbit.net/OpenBgpdMaintenance#Checking_memory_usage However, this seems to be a fairly exotic platform, most people running BGP with Cisco, Juniper or, in some cases Quagga or Bird for Linux machines. Are there recmomendations on using OpenBGP in production? Good / bad experiences? How many people are running Linux routers vs dedicated Cisco/Juniper/etc routers? Finally, we are likely to complete this setup with a CARP (the free equivalent of VRRP) on the inside of the network. FreeBSD can apparently group interfaces and communicate with OpenBGPd - did anyone deploy such a thing here? What are your experiences or advice? Thanks for any advice, A. -- Sous un gouvernement qui emprisonne injustement, la place de l’homme juste est aussi en prison. - La désobéissance civile, Henry David Thoreau

2 3

www.akamai.net giving NXDOMAIN
by Anurag Bhatia 07 Nov '13

07 Nov '13

Anurags-MacBook-Pro:~ anurag$ dig @8.8.8.8 www.akamai.net. ; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 www.akamai.net. ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: *NXDOMAIN*, id: 2274 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.akamai.net. IN A ;; AUTHORITY SECTION: akamai.net. 167 IN SOA internal.akamaitech.net. hostmaster.akamai.com. 1383839413 90000 90000 90000 180 ;; Query time: 26 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Thu Nov 7 16:50:27 2013 ;; MSG SIZE rcvd: 109 Anurags-MacBook-Pro:~ anurag$ That's weird! Missing "akamai.net" entry from the authoritative DNS nodes? I am in Austria right now and so likely my nearby node giving bad replies. -- Anurag Bhatia anuragbhatia.com Linkedin <http://in.linkedin.com/in/anuragbhatia21> | Twitter<https://twitter.com/anurag_bhatia> Skype: anuragbhatia.com

2 2

Level3 and AT&T Latency
by Eric Williams 07 Nov '13

07 Nov '13

Is anybody else seeing or having major latency between Level 3 and AT&T today? We are multi-homed with Level 3 being one of our ISP's and had to divert traffic after seeing these issues. http://www.internetpulse.net/ Eric

8 9

M40e "AER" and MG9k's
by Shaw, Matthew 07 Nov '13

07 Nov '13

Good morning all, This is a bit of a longshot, but by any chance is there anyone watching this list who is currently or was formerly with VZ that's familiar with a configuration involving M40e's aggregating a number of customer facing MG9k's over ATM? We're having a heck of a time with them if you could reach out off list with any background or experiences with them from elsewhere I'd really appreciate it. Matt _______________________________________________________________________ This e-mail message and its attachments are for the sole use of the intended recipients. They may contain confidential information, legally privileged information or other information subject to legal restrictions. If you are not the intended recipient of this message, please do not read, copy, use or disclose this message or its attachments, notify the sender by replying to this message and delete or destroy all copies of this message and attachments in all media.

1 0

Re: Do you obfuscate email headers when reporting spam issues to clients?
by Anne P. Mitchell, Esq. 07 Nov '13

07 Nov '13

> On Wed, Nov 6, 2013 at 1:30 PM, Landon <landonstewart(a)gmail.com> wrote: >> How much trouble does your abuse department go to in order to obfuscate >> headers when providing evidence of spamming activity regardless of if it?s >> intentional/professional spammer activity or some kind of malware infection >> allowing a third party to spam. Especially for the pro spammers, we don?t >> want them list washing anything or worse yet becoming privy to spamtrap >> data if the reporting party wasn?t smart enough to obfuscate their own data >> before sending in the report. > > Howdy, > > It depends on the exact situation, but the general-purpose answer is: > none. zero. zip. > > The customer usually can't act on your information unless he can line > it up with an entry in his own logs. He needs lots of details in the > headers to figure out which computer or which of his users the message > came from. And he needs that information to determine whether the > message really came from his system -- headers get forged, you know. Because this is an issue inherent primarily with bulk mail, we remove all identifying information *except* the unsub link, which *should* have a unique identifying token embedded within, from which the sender *should* be able to determine the complainant's email address. And, if there is no such link, we use that as an opportunity to educate them as to *why* they need to include such a link (mind you, in order to be accredited with us the sender has to have already demonstrated that they comply with including an unsub link, but because many of our accreditation customers are ESPs, their customers may sometimes not be modelling 100% of best practices). Regardless of unsub link, or anything else, if we get a spam complaint against one of our customers, we hold their feet to the fire, and require them to explain exactly how the particular list was built, how the address was acquired, etc.. Failure to do so can (and usually does) result in termination of their accreditation - in the case of an ESP, they have to take corrective measures against their spamming customer or the ESP will lose their accreditation. Anne Anne P. Mitchell, Esq. Author: Section 6 of the CAN-SPAM Act of 2003 CEO/President Institute for Social Internet Public Policy http://www.ISIPP.com Member, Cal. Bar Cyberspace Law Committee How do you get to the inbox instead of the spam filter? SuretyMail! Helping businesses keep their email out of the junk folder since 1998 http://www.isipp.com/SuretyMail

4 6

latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic
by Jacque O'Lantern 07 Nov '13

07 Nov '13

http://www.washingtonpost.com/world/national-security/nsa-infiltrates-links…

19 28

Reverse DNS RFCs and Recommendations
by Nolan Rollo 06 Nov '13

06 Nov '13

I've been (probably needlessly) pouring over the Reverse DNS RFCs for long enough to actually have questions about a subject that should be relatively unimportant. I do want to make sure that we set up our reverse DNS correctly and most efficiently the first time so that we don't irritate other network operators with difficult regex based filtering ( http://www.gossamer-threads.com/lists/nanog/users/113633 ) and we don't have to change things as per a recommendation down the road. RFC draft-msullivan-dnsop-generic-naming-schemes-00.txt states: When using IP addresses in host names, their numbers SHOULD be separated by '.'s (dots) rather than any meta character such as a '-' (dash) and expressed in decimal. Host names SHOULD NOT use the '_' (underscore) character, host names for hosts with any form of SMTP mail service MUST NOT use the '_' (underscore) character. It is preferable to use the IP address in reverse format in the same way the the IN-ADDR.ARPA. domain is defined. Now since it is only a first revision draft I'm taking what it has to say with a grain of salt and it seems has taken quite a bit of criticism on forums. I'm also not singling out on Time Warner, WOW, Comcast or Charter for their naming conventions nor do I think they are bad, I'm just using them as examples because they are local, well-known ISPs. Actual Examples: cpe-67-XX-XX-XX.stny.res.rr.com - 67.XX.XX.XX d28-XX-XX-XX.dim.wideopenwest.com - 28.XX.XX.XX c-68-XX-XX-XX.hsd1.mi.comcast.net - 68.XX.XX.XX 24-XX-XX-XX.static.bycy.mi.charter.com - 24.XX.XX.XX *Most ISP Reverse DNS Hostnames (from what I've observed) seem to use the dash "-" character with the forward format, as opposed to the reverse IN-ADDR.ARPA. dotted scheme as recommended in the draft *Comcast and Charter all have geographic based furthest-right-hand tokens. *Charter, WideOpenWest, Time Warner, and Comcast all have some acronym that is not immediately clear, at least to me (HSD - High Speed Data?, BYCY - Bay City, MI?, DIM - Dynamic IP Mapping?, STNY - Southern Tier New York?) Which finally brings me to my questions: It seems like the unspoken de facto that mail admins appreciate given the IP 203.0.113.15 is "203-0-113-15.[type].[static/dynamic].yourdomain.tld". This seems perfectly acceptable, it's short, detailed and to the point. Is there really anything bad about this? What, if any would you name a network, gateway, broadcast address? Should the PTR be empty? <tinfoilhat> I've seen a lot about naming what type of technology it is (wireless, adsl, cable, etc.) in order to filter out the "high speed spammers". It seems to me that this would open up the likelihood of a targeted attack. We've all heard of security though obscurity and of course no one relies on it but we have to face the fact there are CVEs every day for various networking hardware/firmware. If an attacker can query DNS and find out that the IP is for wireless they could filter all wireless gear exploits. Is this still a good practice given the abundance of high speed data connections or is this just opening yourself up to reconnaissance?</tinfoilhat> There is a Merit Network mailing list discussion that outlines most of what I've read that can be found here ( http://www.merit.edu/mail.archives/nanog/msg06843.html ) Nolan Rollo VoIP Engineer Main: 517.223.3610x114 Fax: 517.223.4120 www.kw-corp.com<http://www.kw-corp.com/>

26 63