January 2010 - Test - lists.nanog.org

IOS family naming
by Andrey Gordon 26 Jan '10

26 Jan '10

Hi List, Anyone recalls ever seeing the IOS naming convention document. In particular I'm interested in differences between families and trains. This is all I found: http://www.cisco.com/warp/public/620/1.html#topic1 But im looking for something a bit more recent maybe? Can figure out differences between say SG, SGA, EW and EWA. A link to the cipher would certainly help. ----- Andrey Gordon [andrey.gordon(a)gmail.com]

4 3

Enhancing automation with network growth
by Steve Bertrand 26 Jan '10

26 Jan '10

Hi all, I'm reaching the point where adding in a new piece of infrastructure hardware, connecting up a new cable, and/or assigning address space to a client is nearly 50% documentation and 50% technical. One thing that would take a major load off would be if my MRTG system could simply update its config/index files for itself, instead of me having to do it on each and every port change. Can anyone offer up ideas on how you manage any automation in this regard for their infrastructure gear traffic graphs? (Commercial options welcome, off-list, but we're as small as our budget is). Unless something else is out there that I've missed, I'm seriously considering writing up a module in Perl to put up on the CPAN that can scan my RANCID logs (and perhaps the devices directly for someone who doesn't use RANCID), send an aggregate 'are these changes authorized' email to an engineer, and then proceed to execute the proper commands within the proper MRTG directories if the engineer approves. I use a mix of Cisco/FreeBSD&Quagga for routers, and Cisco/HP for switches, so it is not as simple as throwing a single command at all configs. All feedback welcome, especially if you are in the same boat. My IP address documentation/DNS is far more important than my traffic stats, but it really hurts when you've forgotten about a port three months ago that you need to know about now. Steve

10 11

Re: unreachable Sites
by Reynold Guerrier 26 Jan '10

26 Jan '10

It's Ok Now. Thanks for your replies. reynold On Tue, Jan 26, 2010 at 11:32 AM, Scott Berkman <scott(a)sberkman.net> wrote: > I was able to reach both of these from where I sit in Atlanta. > > -Scott > > -----Original Message----- > From: Reynold Guerrier [mailto:reygue@gmail.com] > Sent: Tuesday, January 26, 2010 11:09 AM > To: NANOG list > Subject: unreachable Sites > > I have been notified this morning by several people that there is some > websites that are unreachable from Haiti: http://www.hostcentric.com, > http://www.gama.ht those are examples. It happens with different ISP. When > we change th DNS using the google one 8.8.8.8 it's ok for some but some > others still remain unreachable. Can some of you from the Nanog list check > and advise? > > Thank you > > -- > =================================== > Reynold Guerrier > IT Consultant > 509-3446-0099 > IM: reygue(a)hotmail.com > Skype: reygji > > > -- =================================== Reynold Guerrier IT Consultant 509-3446-0099 IM: reygue(a)hotmail.com Skype: reygji

1 0

Re: DDoS mitigation recommendations
by Jeffrey Lyon 26 Jan '10

26 Jan '10

The RioRey per prefix issue is fixed although the patch they released to us had a lot of bugs. Were still waiting on a working appliance with the new code. IntruGuard fits the bill and is probably 1/5th the cost of Arbor pound for pound. We use both RR and IG, each having their pros and cons. Jeff On Jan 26, 2010 9:39 AM, "Stefan Fouant" <sfouant(a)shortestpathfirst.net> wrote: There was an interesting thread on this topic a few weeks back. I really liked the Guards, it's too bad Cisco decided to pull this from the marketplace - it was as close to a panacea as it gets. As alternatives, I've worked with the Riorey boxes as well as Arbor gear. They are both very good boxes, but as your requirements state that you require Multi-tenancy that only really leaves the Arbor. Unfortunately, the Riorey boxes only support a one-size fits all approach as they do not allow unique filtering parameters on a per-prefix basis. Arbor on the other hand supports a full range of Managed Objects and Mitigation Templates which can be applied to individual prefixes, etc. Sorry for the top post, I'm on my Blackberry. Stefan Fouant ------Original Message------ From: Korten, Sean To: nanog(a)nanog.org To: tsands(a)rackspace.com Subject... Sent from my Verizon Wireless BlackBerry

1 0

Re: DDoS mitigation recommendations
by Stefan Fouant 26 Jan '10

26 Jan '10

There was an interesting thread on this topic a few weeks back. I really liked the Guards, it's too bad Cisco decided to pull this from the marketplace - it was as close to a panacea as it gets. As alternatives, I've worked with the Riorey boxes as well as Arbor gear. They are both very good boxes, but as your requirements state that you require Multi-tenancy that only really leaves the Arbor. Unfortunately, the Riorey boxes only support a one-size fits all approach as they do not allow unique filtering parameters on a per-prefix basis. Arbor on the other hand supports a full range of Managed Objects and Mitigation Templates which can be applied to individual prefixes, etc. Sorry for the top post, I'm on my Blackberry. Stefan Fouant ------Original Message------ From: Korten, Sean To: nanog(a)nanog.org To: tsands(a)rackspace.com Subject: RE: DDoS mitigation recommendations Sent: Jan 26, 2010 9:16 AM One more for Arbor. -----Original Message----- From: David Freedman [mailto:david.freedman@uk.clara.net] Sent: Tuesday, January 26, 2010 8:17 AM To: nanog(a)nanog.org Subject: Re: DDoS mitigation recommendations >Arbor stuff comes to mind and works very well in our experiences.... Arbor++ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. Sent from my Verizon Wireless BlackBerry

1 0

Fusion Splicers
by Kevin Hunt 26 Jan '10

26 Jan '10

Anyone here with any experience with Jilong fusion splicers ? Our old Fujikura has died and I have to at least consider the Jilong.

1 0

Re: DDoS mitigation recommendations
by Paul Stewart 26 Jan '10

26 Jan '10

Arbor stuff comes to mind and works very well in our experiences.... Paul -------------------------- Paul Stewart Senior Network Administrator Nexicom Inc. http://www.nexicom.net/ ----- Original Message ----- From: Tom Sands <tsands(a)rackspace.com> To: nanog <nanog(a)merit.edu> Sent: Tue Jan 26 07:40:35 2010 Subject: DDoS mitigation recommendations With Guard appliance and 65xx module being EoL'd, and Cisco's desire to exist the DDoS mitigation market, I'd like to get some recommendations of what other products people are having good success with. We are looking for something that can support 3Gbps - 10Gbps, multi-tenancy, seamless integration, and many of the basic features you'd see on the Guard. Thank you, -- -------------------------------------------------------------------------------- Tom Sands Chief Network Engineer Rackspace Hosting -------------------------------------------------------------------------------- Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse(a)rackspace.com, and delete the original message. Your cooperation is appreciated. ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."

1 0

Re: Using /31 for router links
by msokolov＠ivan.Harhan.ORG 26 Jan '10

26 Jan '10

Mark Smith <nanog(a)85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote: > What about NAT, ATM cell tax, unnecessary addressing fields in PTP > protocols (including your beloved HDLC), SSAP, DSAP fields not being big > enough in 802.2 necessitating SNAP, IPX directly over 802.3, AAL1 > through AAL4, PPPoE "dumbell" MTUs and MSS hacks? Some of those are far > worse sins in my opinion. Hmm. PPPoE: this kludge is a direct fallout of abusing Ethernet for WAN/PTP. If all those xDSL users were willing to stick V.35 cards in their PCs and use "modems" that put out V.35 instead of Ethernet, the whole PPPoE kludge with all of its attendant MTU issues would have been completely unnecessary. Want PPP for authentication etc? Just run straight PPP (RFC 1662) over V.35 instead of Ethernet/PPPoE, HDLC has no fixed MTU unlike Ethernet (jogging my memory, all HDLC controllers which I recall working with allowed maximum frame size up to just a little under 2^16 octets or so), and one can thus have the standard MTU of 1500 octets on that PPP link! Oh, and yet another soapbox of mine, an xDSL modem that puts out V.35 instead of goddamn Ethernet would be a true modem: a modulator/demodulator that modulates/demodulates the bits at the electrical level without caring about what's in those bits. What everyone else in this fubared world calls an xDSL "modem" (a black box that puts Ethernet out) is not a modem at all (i.e., total misappropriation of the term), it is actually a bastardized router! These boxes forward packets between two network interfaces: the presented Ethernet interface and the internal (often horrendously non-standard and proprietary) HDLC or ATM interface on the actual line. A device that forwards packets between two different network interfaces is by definition a router, hence what everyone calls a "modem" is actually a bastardized router - bastardized because its routing (packet forwarding) function is something incomprehensible. The Ethernet-to-Ethernet NAT boxes that everyone else calls "routers" should be called "NATters" or something like that, anything but a router! A true router is a box with a few AUIs and a few V.35 ports sticking out of it, running some very capable, flexible and totally user-configurable packet forwarding software stack that supports all networking models: IP routing, MAC bridging, VC cross-connect. As for ATM... The part that totally baffles me about the use of ATM on xDSL lines is that I have never, ever, ever seen an xDSL line carrying more than one ATM VC. OK, there may be someone out there who has set up a configuration like that just for fun, but 99.999% of all ATM'd xDSL lines out there carry a single PVC at 0*35 or 0*38. So what then is the point of running ATM?!?! All the hyped benefits of ATM (a little cell can squeeze in the middle of a big packet without waiting for it to finish, yadda yadda yadda) are contingent upon having more than one VPI/VCI going across the interface! If every single non-idle cell going across that ATM interface is 0*35 or 0*38, the interface will never carry anything other a direct succession of cells making up an AAL5 packet, strictly in sequence and without interruption. So what's the point of ATM then? Why chop that packet up into cells only to transmit those cells in direct sequence one after another? Why not simply send that same packet in plain HDLC over the same copper pairs/fiber? OK, the backhaul network upstream of the DSLAM may be ATM and that one does have many VCs, so ATM *might* be of use there, but even in that case why not do FRF.8 in the DSLAM and keep the ATM strictly on the backhaul, sending HDLC down the copper pairs? <off the soapbox for the moment> MS

7 6

Looking for someone from Steadfast Networks
by Dennis Hayes 25 Jan '10

25 Jan '10

Hi, Can someone from Steadfast Networks contact me off list. We're having issues accessing sites within your AS, including steadfast.net. I was routed to a tech in your DC and he wasn't sure where to transfer me to. Our AS is 21677 and our prefixes are 174.138.192.0/19, 206.80.240.0/20 and 216.246.224.0/19. I've tried both our up stream providers; one route fails at PAIX and the other fails in NTT's network in Chicago. Thanks, Dennis Hayes Distributel Communications Limited Tel: 613-237-3143 Email: dennis.hayes(a)distributel.ca

1 0

L-Root Maintenance 2010-01-27 1800 UTC - 2000 UTC
by Mehmet Akcin 25 Jan '10

25 Jan '10

Hi As part of staged, incremental deployment of DNSSEC in the root zone L-Root will begin serving a Deliberately Unvalidatable Root Zone (DURZ) after the completion of its scheduled maintenance at 2010-01-27 1800 UTC - 2000 UTC Please contact L-Root NOC via noc(a)dns.icann.org or T: +1.310.301.5817 if you have any questions. Please contact with rootsign(a)icann.org if you have any questions regarding DNSSEC Deployment at root zone. Regards Joe Abley / Mehmet Akcin / Dave Knight ICANN DNS Ops / L-ROOT

1 0