- NANOG - lists.nanog.org

Understanding reverse DNS better
by Caleb Tennis 26 Jan '11

26 Jan '11

We have a /24 from one of our upstream providers that we handoff to a customer. The /24 has been SWIPd to us, and we have nameservers setup with ARIN against that record. Twice now this information has just "disappeared". That is, if do reverse DNS lookups, they returns nothing, whereas they were just working fine earlier. If you do an NS lookup on the block, it returns nothing. The /24 blocks immediately surrounding us continue to work just fine. If we do a lookup directly against our nameserver, it works just fine. It's like the nameserver information against that reverse DNS is just magically gone. The ARIN record looks good, nothing has changed. Last time, our upstream resubmitted the info so it would repopulate, and it started working again soon there after. I admit to not being the smartest one with how these records work: is the problem with the upstream, or ARIN's database, or is there not enough information to tell? Thanks, Caleb

7 8

Re: IPv6 filtering
by Hank Nussbacher 26 Jan '11

26 Jan '11

At 18:20 26/01/2011 +1300, Franck Martin wrote: >Content-Transfer-Encoding: 7bit > >Well we filter icmp due to exploits, if no exploits, then we can let the >whole of icmpv6 through. Or is there something terribly dangerous in >icmpv6 already? Ever since Cisco came out with "IPv6 Routing Header Vulnerability" in 2007 http://www.cisco.com/en/US/products/products_security_advisory09186a00807cb… I have had the following enabled: On the protected interface: ipv6 traffic-filter filter-rh in ipv6 access-list filter-rh deny ipv6 any any log routing permit ipv6 any any and have stopped many pkts that way. I still occasionally see hits in our log from all sorts of newbies who continue to try old bugs. -Hank

1 0

IPv6 - real vs theoretical problems
by Deepak Jain 26 Jan '11

26 Jan '11

Please, before you flame out, recognize I know a bit of what I am talking about. You can verify this by doing a search on NANOG archives. My point is to actually engage in an operational discussion on this and not insult (or be insulted). While I understand the theoretical advantages of /64s and /56s and /48s for all kinds of purposes, *TODAY* there are very few folks that are actually using any of them. No typical customer knows what do to do (for the most part) with their own /48, and other than autoconfiguration, there is no particular advantage to a /64 block for a single server -- yet. The left side of the prefix I think people and routers are reasonably comfortable with, it's the "host" side that presents the most challenge. My interest is principally in servers and high availability equipment (routers, etc) and other things that live in POPs and datacenters, so autoconfiguration doesn't even remotely appeal to me for anything. In a datacenter, many of these concerns about having routers fall over exist (high bandwidth links, high power equipment trying to do as many things as it can, etc). Wouldn't a number of problems go away if we just, for now, follow the IPv4 lessons/practices like allocating the number of addresses a customer needs --- say /122s or /120s that current router architectures know how to handle -- to these boxes/interfaces today, while just reserving /64 or /56 spaces for each of them for whenever the magic day comes along where they can be used safely? As far as I can tell, this "crippling" of the address space is completely reversible, it's a reasonable step forward and the only "operational" loss is you can't do all the address jumping and obfuscation people like to talk about... which I'm not sure is a loss. In your enterprise, behind your firewall, whatever, where you want autoconfig to work, and have some way of dealing with all of the dead space, more power to you. But operationally, is *anything* gained today by giving every host a /64 to screw around in that isn't accomplished by a /120 or so? Thanks, DJ

20 37

Re: Network Naming
by GP Wooden 25 Jan '11

25 Jan '11

Punk bands here .... ----- Reply message ----- From: "Christopher" <caldcv(a)gmail.com> Date: Tue, Jan 25, 2011 3:11 pm Subject: Network Naming To: <nanog(a)nanog.org> I usually name them after ex-girlfriends On 01/25/2011 03:50 PM, Nick Olsen wrote: > Whats the rule of thumb for naming gear these days > (routers,switches...etc). Or is there one? > > looks like level3 does something like > interface.routertype.location.level3.net > > Nick Olsen > Network Operations > (855) FLSPEED x106 > > >

1 0

Update Spamhaus DROP list from Cisco CLI (TCL)
by Thomas Magill 25 Jan '11

25 Jan '11

Previous conversations made me decide this would be fun to do so I ignored all my real work today and made it happen. I built a TCL script that can be mapped to an alias ("alias exec updatedrop tclsh updatedrop.tcl") that will connect to the Spamhaus DROP list and route all of the prefixes to null0. It should alsbo be able to be mapped to a kron job, but I haven't tested that and I've heard there are issues with kron+tcl unless you tie it to an EEM event. It adds a name indicator (Spamhaus_SBLXXXXX) to all of the routes to show that they come from the DROP list. You can find the script at: http://tmagill.net/cisco_networking_ccie_studies/?p=83 There is also a script to remove all of the Spamhaus_SBLXXXXX null routes. If I were to redis these into BGP they could be propagated just like the CYMRU Bogons... I plan on doing that within the next week and start testing. Does anyone see that as a useful service to be offered? Thomas Magill Network Engineer Office: (858) 909-3777 Cell: (858) 869-9685 tmagill(a)providecommerce.com<mailto:tmagill@providecommerce.com> provide-commerce 4840 Eastgate Mall San Diego, CA 92121 ProFlowers<http://www.proflowers.com/> | redENVELOPE<http://www.redenvelope.com/> | Cherry Moon Farms<http://www.cherrymoonfarms.com/> | Shari's Berries<http://www.berries.com/>

5 5

Re: IPv6: numbering of point-to-point-links
by Lasse Jarlskov 25 Jan '11

25 Jan '11

Thank you all for your comments - it appears that there is no consensus on how this should be done. Thank you for the reference to this draft, Marco - and to Ron as well. Both RFC3627 and this draft appears to be stating that these issues a implementation-specific. E.g. whether an implementation will perform subnet-router-anycast on a small subnet, whether Neighbor-Discovery-messages are rate-limited etc. Does anyone have any information on how different vendors handle this - even in older software? /126 appears to be the middle path - which is reserving the subnet-router-anycast address while keeping the subnet as small as possible. This appears to address both issues - at least for Ethernet links. (one free address will hardly constitute a potential Neighbor Cache Exhaustion issue). Best regards, /Lasse -----Oprindelig meddelelse----- Fra: Marco Hogewoning [mailto:mch-nanog@xs4all.nl] Sendt: 24. januar 2011 14:11 Til: Lasse Jarlskov Cc: nanog(a)nanog.org Emne: Re: IPv6: numbering of point-to-point-links > While reading up on IPv6, I've seen numerous places that subnets are now > all /64. > > I have even read that subnets defined as /127 are considered harmful. RFC3627, with a lot of discussion in the IETF on this. See also https://datatracker.ietf.org/doc/draft-ietf-6man-prefixlen-p2p/ > However while implementing IPv6 in our network, I've encountered several > of our peering partners using /127 or /126 for point-to-point links. I personally don't any benefit in using /126 subnets. > What is the Best Current Practice for this - if there is any? > > Would you recommend me to use /64, /126 or /127? > > What are the pros and cons? >From an operational point of view there is a risk that be using /64 somebody can eat away a lot of memory by either scanning or even changing addresses. This is also described in the draft above... I would personally recommend to at least always assign the /64, even if you would decide to configure the /127. RFC 3627 has been around long enough that you will keep running into equipment or software that won't like the /127. In which case you can always revert back to /64. This will also allow you to use easy to remember addresses like ::1 and ::2, saving you the headache of a lot of binary counting. Grtx, Marco

2 1

bestpath as-path multipath-relax
by Zaid Ali 24 Jan '11

24 Jan '11

I am looking for some operational feedback of this undocumented feature, bgp bestpath as-path multipath-relax, for IOS. If you are using this for outbound load balancing I would like to hear your experiences. Also if you are running it across edges. Thanks, Zaid

1 0

The Conficker Working Group Lessons Learned Document
by freed0 24 Jan '11

24 Jan '11

http://www.confickerworkinggroup.org/wiki/pmwiki.php/ANY/LessonsLearned http://www.confickerworkinggroup.org/wiki/uploads/Conficker_Working_Group_L… The Conficker Working Group Lessons Learned Document Starting in late 2008, and continuing through June of 2010, a coalition of security researchers worked to resist an Internet borne attack carried out by malicious software known as Conficker. This coalition became known as “The Conficker Working Group”, and seemed to be successful in a number of ways, not the least of which was unprecedented cooperation between organizations and individuals around the world, in both the public and private sectors. In 2009, The Department of Homeland Security funded a project to develop and produce a “Lessons Learned” document that could serve as a permanent record of the events surrounding the creation and operation of the working group so that it could be used as an exemplar upon which similar groups in the future could build. This is the document. The Rendon Group conducted the research independently, and although a number of members of the Conficker Working Group were interviewed, and provided information to the authors, the report is the sole work product of the Rendon Group. The views and conclusions are not necessarily those of the Conficker Working Group, or any of its official or unofficial members. Nonetheless the Core Committee of the Conficker Working Group believes the report has substantial value and is pleased to provide access to the Rendon document via the Conficker Working Group Website. Rodney Joffe Chair Conficker Working Group Follow up questions can be directed to the Rendon Group at the address below, as well as the following members of the Conficker Working Group Core Committee: * The Rendon Group * Phone: +1 202-745-4900 * trginfo(a)rendon.com Conficker Working Group Core Committee: The ShadowServer Foundation * Andre' M. DiMino * Co-Founder and Director * Phone: +1 914-410-6480 * Email: adimino(a)shadowserver.org Neustar, Inc * Rodney Joffe * Senior Vice President * Phone: +1 202-533-2900 * Email: rodney.joffe(a)neustar.biz Verisign, Inc. * Ramses Martinez * Director of Information Security * Phone: +1 571-723-1874 * Email: ramartinez(a)verisign.com Arbor Networks * Kevin Whalen * kwhalen(a)arbor.net * Phone: +1 978-852-8432 Internet Software Consortium * Barry Greene * President * Phone: +1 650-423-1311 * Email: bgreene(a)isc.org

1 0

Verizon local CFA sanity check
by Christopher Pilkington 24 Jan '11

24 Jan '11

I'm writing a LOA/CFA doc for some DS1s to be delivered to us on a Verizon private OC12 ring, and I'm getting conflicting info (including from multiple people within Verizon) on how to address individual DS1s. For STS/DS3s, it's pretty obvious, just the STS number, i.e. <SCID>/OC12/<STS>/<CLLI_there>/<CLLI_here> Anyone know for certain how Verizon numbers DS1 channels on an OC on a CFA doc? For clarity, this is Verizon local, Manhattan. Thanks, -cjp

2 2

Re: Using IPv6 with prefixes shorter than a /64 on a LAN
by Chris Nicholls 24 Jan '11

24 Jan '11

On Monday, 24 January 2011 at K:59:59 -0200, Carlos Martinez-Cagnazzo wrote: > I am particularly wondering about possible NDP breakage. +1 We allocate /64 per PtP but only configure /127 for NDP and secrity concerns, I figure we can always change the mask if the space is set asside from the get go. ta -- Chris Nicholls Timico Network Operations chris(a)timico.net

1 0