- Test - lists.nanog.org

IANA DNSSEC Testbed has been Decommissioned
by Joe Abley 15 Sep '10

15 Sep '10

Colleagues, Following advanced notice sent to this list on 2010-08-03, the IANA testbed was shut down on 2010-09-03. For more details on the IANA DNSSEC testbed, see <https://ns.iana.org/>. For more details on DNSSEC deployment in the Root Zone, see <http://www.root-dnssec.org/>. Queries to the nameserver bound to NS.IANA.ORG (208.77.188.32, 2620:0:2d0:1::32) now fail with ICMP type 3 code 3 (Destination Unreachable, Port Unreachable). We suggest that anybody using the DNSSEC testbed for anything resembling production services make plans to stop doing so at their earliest convenience, if operational necessity has not already made that obvious. ICANN would once again like to thank Packet Clearing House (PCH) and Dyn.com DynTLD for their support and generous donation of global DNS resources to the IANA DNSSEC testbed. Regards, Joe Abley Director DNS Operations, ICANN

1 0

Present at The Tools Track at NANOG 50
by Mohit Lad 14 Sep '10

14 Sep '10

Dear all, The Tools track at NANOG Atlanta is a chance to talk about and discover non-commercial network tools of interest to network operations. If you have open-source or non-commercial software that you wrote or use and is relevant to NANOG, consider presenting at this NANOGs Tools Track. Please get in touch with me directly if you are attending NANOG 50 and interested. Thanks Mohit

1 0

[NANOG-announce] Call for Nominations - Communications Committee
by Michael K. Smith - Adhost 14 Sep '10

14 Sep '10

Hello: Nominations for the NANOG Communications Committee are now open. This is a great way to become involved and serve the NANOG community. From the website: "The Communications Committee is a group of five individuals from the NANOG community who together are responsible for the administration and moderation of the NANOG mailing lists. A new Communications Committee will be selected by the Steering Committee after the election in October. Two positions are to be filled. The currently-serving Communications Committee members whose terms are expiring are Randy Epstein and Tim Yocum. The main NANOG mailing list serves an important role in the community by providing a day-to-day forum for network operators. Participating as a member of the Communications Committee gives you the opportunity to make a noticeable contribution. The Communications Committee is covered under section 7.1.2 of the NANOG charter." If you are interested in volunteering on the Communications Committee, please either volunteer yourself or nominate someone you feel would be willing and able to serve. Please send nominations to nominations(a)nanog.org and include your name, company affiliation, a brief biography and a statement of interest. This information will be posted to the NANOG website in the coming weeks. Please see http://www.nanog.org/governance/elections/2010elections/index.php for more information as well as samples of previous candidate submissions. Kind Regards, Michael K. Smith NANOG Communications Committee Chair _______________________________________________ NANOG-announce mailing list NANOG-announce(a)nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce

1 0

perl lib for management of NX-OS ?
by Leland Vandervort 14 Sep '10

14 Sep '10

Hi All, I have an XMLRPC server/API that I implemented (written in perl) to manage most of the cisco kit on the network, with most of the "worker" methods using Net::Telnet::Cisco. Our new datacenter, however, has Cisco Nexus equipment which totally breaks the API since Net::Telnet::Cisco doesn't work at all with NX-OS. I've done some scouring around to try to find something useful for NX-OS, but have come up with nil... Don't suppose anyone has any pointers or has heard of a similar lib for perl to be able to manage NX-OS based systems? I've tried to find a netconf-xmlrpc-ssh lib, but everything that I've found is specifically geared towards juniper rather than Cisco -- and while netconf is supposed to be "standard" (more or less), there are significant differences between the two implementations sufficient enough to make the libs that I've found incompatible with NX-OS. Anyone happen to have any ideas ? Many thanks, Leland

1 0

ISP port blocking practice
by Zhiyun Qian 13 Sep '10

13 Sep '10

Hi all, What is the common practice for enforcing port blocking policy (or what is the common practice for you and your ISP)? More specifically, when ISPs try to block certain outgoing port (port 25 for instance), they could do two rules: 1). For any outgoing traffic, if the destination port is 25, then drop the packets. 2). For any incoming traffic, if the source port is 25, then drop the packets. Note that either of the rule would be able to block outgoing port 25 traffic since each rule essentially represent one direction in a TCP flow. Of course, they could apply both rules. However, based on our measurement study, it looks like most of the ISPs are only using rule 1). Is there any particular reason why rule 1) instead of rule 2)? Or maybe both? Also, is it common that the rules are based on tcp flags (e.g. SYN, SYN-ACK)? One would think block SYN packet is good enough. Regards. -Zhiyun

52 121

Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
by Tim Franklin 13 Sep '10

13 Sep '10

> Competition would be wonderful, but is simply not practical in many > cases. Most people and companies don't want to hear this, but from > a consumer perspective the Internet is a utility, and very closely > resembles water/sewer/electric/gas service. That is, having 20 > people run fiber past your home when you're only going to buy from > one of them makes no economic sense. Indeed, we probably wouldn't > have both cable and DSL service if those were both to the home for > other reasons already. The copper pair from your house to the exchange isn't congested (at least, between you and other people), by definition. The fibre from your house to somewhere isn't congested, in the same way - although the 'somewhere' may be closer to you than the exchange. There's no reason to have competition here - but there's no reason to have a commercial entity trying to make a profit here either. Treat it like a real, basic utility, and run it on a cost-recovery basis, either directly by your local government entity, or by a dedicated organisation acting on their behalf. Whatever entity owns the local-loop sells access to competing service providers on an equal and transparent basis. Providers can then compete on level of network congestion, amongst other things, because they can directly control it in terms of how much backhaul they want to build from the exchange / FTTP street cab / whatever the aggregation point is against the volume of subscribers they sell off that aggregation point. For places which have it, this seems to work much better, or least break far less, than the alternatives (Openreach in the UK, Stokab in Stockholm being two I've dealt with). Exactly like electricity and gas - I only have one set of wires / pipes to my house, but there's a plethora of companies I can choose to buy energy services from. Regards, Tim.

2 1

Multicast issues in windows TCP/IP stack
by Philip Lavine 13 Sep '10

13 Sep '10

Not sure if this the the right venue for this, but would anyone happen to know if there is any changes or "enhancements" in the Windows 2008 64 Bit R2 TCP/IP stack or in TOE that would cause multicast or microsecond bursts of UDP to be dropped between the physical layer (NIC) and OS. I am running the same multicast app on Windows 2008 64 bit NOT R2 or standard and do not have this issue. -thx Philip

1 0

Re: Transporting QinQ across a Layer 2 link locked at 1518 octets AND across a Layer 3 link
by Nick Olsen 13 Sep '10

13 Sep '10

Only input I can give is on EOIP tunnels and MTU. Scenario is we had 1 remote router running, Tunneled back to our network using EOIP so that the remote network could use our ip space. Don't remember how I figured it out, But I was using the MTU of 1458 (On the EOIP interface). Everything was great, But weird things started happening. Certain sites wouldn't load, MSN.com....etc it was strange. Jacking it back up to 1500 flat fixed it. Nick Olsen Network Operations (877) 804-3001 x106 ---------------------------------------- From: "Francois Menard" <francois(a)menards.ca> Sent: Sunday, September 12, 2010 10:13 PM To: "Francois Menard" <francois(a)menards.ca> Subject: Re: Transporting QinQ across a Layer 2 link locked at 1518 octets AND across a Layer 3 link Oops two typos - sunday evening casualties. On 2010-09-12, at 10:06 PM, Francois Menard wrote: > Folks, > > Question #1: > > Is it possible for me to put an MPLS router on both ends of a circuit leased from a transport service provider which does not support QinQ (i.e. packets of 1526 bytes), and which requires us to tag traffic onto a well specified set of VLANs (i.e. if we want two VLANs, the service provider tells us which two VLANs to use). > > I was thinking of lowering the MTU size on my MPLS router such that I could do QinQ over VPLS, over MPLS, over Ethernet transport locked at @ 1514 octets. > > I would imagine that my effective IPv4 payload would be reduced to something like (not taking into account CRC removed in the Ethernet driver) > > 1514 minus 8 bytes for MPLS label minus 4 bytes for VPLS control word minus 4 bytes for VLAN tag #1 minus 4 bytes for VLAN tag #2 = > 1514 -8 -4 -4 -4 -4 = 1490 octets > > So if I set my MTU on my MPLS router at 1490 octets and send QinQ over VPLS over , wouldn't that allow for all of the above mentioned overhead to pile-up without exceeding the 1514 octets size allowed by my transport provider ? > So if I set my MTU on my MPLS router at 1490 octets and send QinQ over VPLS over MPLS over Ethernet, wouldn't that allow for all of the above mentioned overhead to pile-up without exceeding the 1514 octets size allowed by my transport provider ? > Question #2: > > I have another link, which is restricted by the transport service provider, which is an MPLS-VPN service, and which does not support QinQ, nor supports layer 2 bridging. > > An option available to me is to use an EoIP tunnel on a Mikrotik RouterOS router, which maps Ethernet over GRE over IP, causing some 28 octets of overhead. This is proprietary to Mikrotik. > > So in this case, assuming that I want to do something as dangerous as: > > QinQ over VPLS over MPLS over Ethernet over EoIP (over GRE, over IP) > > And accordingly set my MTU to: > > 1480 (from above) minus 28 octets (Ethernet over GRE over IP) = 1452 octets > 1490 (from above) minus 28 octets (Ethernet over GRE over IP) = 1462 octets > So if I set my MTU on my MPLS router at 1452 octets, wouldn't that allow for all of the above mentioned overhead to be successfully transported across an IP layer 3 circuit, effectively ending up with > 1462 octets > QinQ over MPLS over Ethernet over IP ? > > What are the consequences of setting the MTU as low as 1452 octets? What applications end-up breaking ? > 1462 octets > -=Francois=- > > > >

1 0

POS to Ethernet Converter
by Alan Bryant 13 Sep '10

13 Sep '10

I did a quick google search for a converter but either I'm not understanding, or I'm not searching for the right thing. We currently have a POS OC-3 that I would like to be able to convert it to Ethernet, if possible. Do such devices exist? -- Alan Bryant | Systems Administrator Gtek Computers & Wireless, LLC. alan(a)gtekcommunications.com | www.gtek.biz O 361-777-1400 | F 361-777-1405

12 11

Transporting QinQ across a Layer 2 link locked at 1518 octets AND across a Layer 3 link
by Francois Menard 13 Sep '10

13 Sep '10

Folks, Question #1: Is it possible for me to put an MPLS router on both ends of a circuit leased from a transport service provider which does not support QinQ (i.e. packets of 1526 bytes), and which requires us to tag traffic onto a well specified set of VLANs (i.e. if we want two VLANs, the service provider tells us which two VLANs to use). I was thinking of lowering the MTU size on my MPLS router such that I could do QinQ over VPLS, over MPLS, over Ethernet transport locked at @ 1514 octets. I would imagine that my effective IPv4 payload would be reduced to something like (not taking into account CRC removed in the Ethernet driver) 1514 minus 8 bytes for MPLS label minus 4 bytes for VPLS control word minus 4 bytes for VLAN tag #1 minus 4 bytes for VLAN tag #2 = 1514 -8 -4 -4 -4 -4 = 1490 octets So if I set my MTU on my MPLS router at 1490 octets and send QinQ over VPLS over , wouldn't that allow for all of the above mentioned overhead to pile-up without exceeding the 1514 octets size allowed by my transport provider ? Question #2: I have another link, which is restricted by the transport service provider, which is an MPLS-VPN service, and which does not support QinQ, nor supports layer 2 bridging. An option available to me is to use an EoIP tunnel on a Mikrotik RouterOS router, which maps Ethernet over GRE over IP, causing some 28 octets of overhead. This is proprietary to Mikrotik. So in this case, assuming that I want to do something as dangerous as: QinQ over VPLS over MPLS over Ethernet over EoIP (over GRE, over IP) And accordingly set my MTU to: 1480 (from above) minus 28 octets (Ethernet over GRE over IP) = 1452 octets So if I set my MTU on my MPLS router at 1452 octets, wouldn't that allow for all of the above mentioned overhead to be successfully transported across an IP layer 3 circuit, effectively ending up with QinQ over MPLS over Ethernet over IP ? What are the consequences of setting the MTU as low as 1452 octets? What applications end-up breaking ? -=Francois=-

1 1