- NANOG - lists.nanog.org

Re: In wall switches
by Scott Weeks 16 Feb '10

16 Feb '10

--- standalone.sysadmin(a)gmail.com wrote: From: Matt Simmons <standalone.sysadmin(a)gmail.com> I'm going to be implementing some NJ220 switches. They are EOL, and only 10/100, but their feature set is impressive for their size. I ----------------------------------------------- That sounds like a big gamble. Buy extras. Lots of them... ;-) scott

2 1

[NANOG-announce] Lightning talks open for NANOG 48
by David Meyer 16 Feb '10

16 Feb '10

Get yours in now! Looking forward to seeing all of you in Austin. Dave (for the NANOG PC) _______________________________________________ NANOG-announce mailing list NANOG-announce(a)nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce

1 0

Denic (.de) blocking 6to4 nameservers (since begin feb 2010)
by Igor Ybema 16 Feb '10

16 Feb '10

Hi, We are using 6to4 on our fallback site because the provider there is not able to provide us native IPv6 yet. We have also installed a fallback nameserver over there using a 6to4 address. This works good and no complains what so ever in the past. However, last week Denic (registry for .de) changed their policy (or their checks). They don't allow a nameserver for a .de domain anymore which contains a 6to4 address. The policy is "it should be a global unicast AND the block should be assigned to a RIR for suballocation purpose". The 6to4 range is Global Unicast (http://www.iana.org/assignments/ipv6-unicast-address-assignments/) but it is not assigned to a RIR because it is a special block. This fails their policy and their checks (resulting in a ERROR: 105 All IPv6 Addresses must be Global Unicast). Ok, policy is policy and we should not complain. However, I'm asking your opinions about this policy. I find this really stupid because this completely brakes use for 6to4 in Germany and their is no good reason to block it. We know we should push our provider to support native IPv6, and we do. But this should not stop us using IPv6 6to4. regards, Igor Ybema

10 14

in-addr.arpa server problems for europe?
by Michelle Sullivan 16 Feb '10

16 Feb '10

I see constant issues where I can't resolve PTR's in Europe. I see no reason for this except that a bunch of servers are either dropping my packets or are permanently f**ked... any other clues gratefully accepted. michelle@enigma:~/dultools$ dig +trace -x 213.219.184.23 ; <<>> DiG 9.3.3 <<>> +trace -x 213.219.184.23 ;; global options: printcmd . 364340 IN NS J.ROOT-SERVERS.NET. . 364340 IN NS K.ROOT-SERVERS.NET. . 364340 IN NS L.ROOT-SERVERS.NET. . 364340 IN NS M.ROOT-SERVERS.NET. . 364340 IN NS A.ROOT-SERVERS.NET. . 364340 IN NS B.ROOT-SERVERS.NET. . 364340 IN NS C.ROOT-SERVERS.NET. . 364340 IN NS D.ROOT-SERVERS.NET. . 364340 IN NS E.ROOT-SERVERS.NET. . 364340 IN NS F.ROOT-SERVERS.NET. . 364340 IN NS G.ROOT-SERVERS.NET. . 364340 IN NS H.ROOT-SERVERS.NET. . 364340 IN NS I.ROOT-SERVERS.NET. ;; Received 332 bytes from 111.125.160.132#53(111.125.160.132) in 1 ms 213.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. 213.in-addr.arpa. 86400 IN NS NS3.NIC.FR. 213.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. 213.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. 213.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. 213.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. 213.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. ;; Received 224 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 20011 ms ;; connection timed out; no servers could be reached michelle@enigma:~/dultools$ dig +trace -x 213.219.184.23 ; <<>> DiG 9.3.3 <<>> +trace -x 213.219.184.23 ;; global options: printcmd . 364195 IN NS F.ROOT-SERVERS.NET. . 364195 IN NS G.ROOT-SERVERS.NET. . 364195 IN NS H.ROOT-SERVERS.NET. . 364195 IN NS I.ROOT-SERVERS.NET. . 364195 IN NS J.ROOT-SERVERS.NET. . 364195 IN NS K.ROOT-SERVERS.NET. . 364195 IN NS L.ROOT-SERVERS.NET. . 364195 IN NS M.ROOT-SERVERS.NET. . 364195 IN NS A.ROOT-SERVERS.NET. . 364195 IN NS B.ROOT-SERVERS.NET. . 364195 IN NS C.ROOT-SERVERS.NET. . 364195 IN NS D.ROOT-SERVERS.NET. . 364195 IN NS E.ROOT-SERVERS.NET. ;; Received 512 bytes from 111.125.160.132#53(111.125.160.132) in 1 ms 213.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. 213.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. 213.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. 213.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. 213.in-addr.arpa. 86400 IN NS NS3.NIC.FR. 213.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. 213.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. ;; Received 224 bytes from 192.112.36.4#53(G.ROOT-SERVERS.NET) in 5256 ms ;; connection timed out; no servers could be reached michelle@enigma:~/dultools$ dig +trace -x 213.219.184.23 ; <<>> DiG 9.3.3 <<>> +trace -x 213.219.184.23 ;; global options: printcmd . 364138 IN NS E.ROOT-SERVERS.NET. . 364138 IN NS F.ROOT-SERVERS.NET. . 364138 IN NS G.ROOT-SERVERS.NET. . 364138 IN NS H.ROOT-SERVERS.NET. . 364138 IN NS I.ROOT-SERVERS.NET. . 364138 IN NS J.ROOT-SERVERS.NET. . 364138 IN NS K.ROOT-SERVERS.NET. . 364138 IN NS L.ROOT-SERVERS.NET. . 364138 IN NS M.ROOT-SERVERS.NET. . 364138 IN NS A.ROOT-SERVERS.NET. . 364138 IN NS B.ROOT-SERVERS.NET. . 364138 IN NS C.ROOT-SERVERS.NET. . 364138 IN NS D.ROOT-SERVERS.NET. ;; Received 500 bytes from 111.125.160.132#53(111.125.160.132) in 1 ms 213.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. 213.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. 213.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. 213.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. 213.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. 213.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. 213.in-addr.arpa. 86400 IN NS NS3.NIC.FR. ;; Received 224 bytes from 192.203.230.10#53(E.ROOT-SERVERS.NET) in 183 ms ;; connection timed out; no servers could be reached michelle@enigma:~/dultools$ dig +trace -x 213.219.184.23 ; <<>> DiG 9.3.3 <<>> +trace -x 213.219.184.23 ;; global options: printcmd . 364091 IN NS D.ROOT-SERVERS.NET. . 364091 IN NS E.ROOT-SERVERS.NET. . 364091 IN NS F.ROOT-SERVERS.NET. . 364091 IN NS G.ROOT-SERVERS.NET. . 364091 IN NS H.ROOT-SERVERS.NET. . 364091 IN NS I.ROOT-SERVERS.NET. . 364091 IN NS J.ROOT-SERVERS.NET. . 364091 IN NS K.ROOT-SERVERS.NET. . 364091 IN NS L.ROOT-SERVERS.NET. . 364091 IN NS M.ROOT-SERVERS.NET. . 364091 IN NS A.ROOT-SERVERS.NET. . 364091 IN NS B.ROOT-SERVERS.NET. . 364091 IN NS C.ROOT-SERVERS.NET. ;; Received 500 bytes from 111.125.160.132#53(111.125.160.132) in 1 ms 213.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. 213.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. 213.in-addr.arpa. 86400 IN NS NS3.NIC.FR. 213.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. 213.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. 213.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. 213.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. ;; Received 224 bytes from 128.8.10.90#53(D.ROOT-SERVERS.NET) in 249 ms ;; connection timed out; no servers could be reached michelle@enigma:~/dultools$ dig +trace -x 213.219.184.23 ; <<>> DiG 9.3.3 <<>> +trace -x 213.219.184.23 ;; global options: printcmd . 364032 IN NS B.ROOT-SERVERS.NET. . 364032 IN NS C.ROOT-SERVERS.NET. . 364032 IN NS D.ROOT-SERVERS.NET. . 364032 IN NS E.ROOT-SERVERS.NET. . 364032 IN NS F.ROOT-SERVERS.NET. . 364032 IN NS G.ROOT-SERVERS.NET. . 364032 IN NS H.ROOT-SERVERS.NET. . 364032 IN NS I.ROOT-SERVERS.NET. . 364032 IN NS J.ROOT-SERVERS.NET. . 364032 IN NS K.ROOT-SERVERS.NET. . 364032 IN NS L.ROOT-SERVERS.NET. . 364032 IN NS M.ROOT-SERVERS.NET. . 364032 IN NS A.ROOT-SERVERS.NET. ;; Received 500 bytes from 111.125.160.132#53(111.125.160.132) in 1 ms 213.in-addr.arpa. 86400 IN NS NS3.NIC.FR. 213.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. 213.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. 213.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. 213.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. 213.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. 213.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. ;; Received 224 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 179 ms ;; connection timed out; no servers could be reached ...and to prove things do work @111.125.160.128/26... michelle@enigma:~/dultools$ dig +trace -x 8.8.8.8 ; <<>> DiG 9.3.3 <<>> +trace -x 8.8.8.8 ;; global options: printcmd . 364040 IN NS C.ROOT-SERVERS.NET. . 364040 IN NS D.ROOT-SERVERS.NET. . 364040 IN NS E.ROOT-SERVERS.NET. . 364040 IN NS F.ROOT-SERVERS.NET. . 364040 IN NS G.ROOT-SERVERS.NET. . 364040 IN NS H.ROOT-SERVERS.NET. . 364040 IN NS I.ROOT-SERVERS.NET. . 364040 IN NS J.ROOT-SERVERS.NET. . 364040 IN NS K.ROOT-SERVERS.NET. . 364040 IN NS L.ROOT-SERVERS.NET. . 364040 IN NS M.ROOT-SERVERS.NET. . 364040 IN NS A.ROOT-SERVERS.NET. . 364040 IN NS B.ROOT-SERVERS.NET. ;; Received 500 bytes from 111.125.160.132#53(111.125.160.132) in 4 ms 8.in-addr.arpa. 86400 IN NS NS1.LEVEL3.NET. 8.in-addr.arpa. 86400 IN NS NS2.LEVEL3.NET. ;; Received 84 bytes from 192.33.4.12#53(C.ROOT-SERVERS.NET) in 180 ms 8.8.8.in-addr.arpa. 3600 IN NS ns2.google.com. 8.8.8.in-addr.arpa. 3600 IN NS ns3.google.com. 8.8.8.in-addr.arpa. 3600 IN NS ns4.google.com. 8.8.8.in-addr.arpa. 3600 IN NS ns1.google.com. ;; Received 120 bytes from 209.244.0.1#53(NS1.LEVEL3.NET) in 175 ms 8.8.8.8.in-addr.arpa. 86400 IN PTR google-public-dns-a.google.com. ;; Received 82 bytes from 216.239.34.10#53(ns2.google.com) in 211 ms

13 27

AS16387 leaking routes
by Ernest Andrew McCracken (emccrckn) 16 Feb '10

16 Feb '10

Has anyone seen the strange activity from AS16387? Did they leak their entire table? Our route collectors are showing AS16387 originating large numbers of prefixes. It looks like we caught the tail end of this activity as they are now announcing updates with massive amounts of prepending. Here's an example. We have several pages worth of this. 20100215|15:17:58|1266268678678|164.128.32.11|3303|ORIGIN_CHANGE|95.79.192/19|34533|16387 20100215|15:18:58|1266268738707|164.128.32.11|3303|BGPMON_PATH|3303,3303,3303,3303,3303,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6 453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453, 6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453 ,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387 Ernest McCracken Research Assistant Networking Research Laboratory http://netlab.cs.memphis.edu Computer Science Department University of Memphis

2 4

Re: Noise (was Re: in-addr.arpa server problems for europe?)
by Larry Sheldon 15 Feb '10

15 Feb '10

On 2/15/2010 1:19 PM, JC Dill wrote: > I don't see the point you are trying to make in this discussion. I can see that. I don't have a clue bat big enough for the task. Are > you saying Troll skat. I'm out. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml

1 0

Re: dns interceptors
by charles＠knownelement.com 15 Feb '10

15 Feb '10

Not familiar with --outform argument. Will have to look into it. Presume you are doing site to site/network to network? Or are you setting this up for end users to terminate to? I've done the latter many many times, but not net to net. Happy to provide docs if you/nanog like. I think that everyone should run a vpn to secure remote access to services they are operating. You integrating this with an existing ski infrastructure? If so is it openssl based? Or maybe ad based? Lots of openvpn variables.... Might be worth starting a new thread on the subject. As I said, I feel its vital for folks to have a deep familiarity with openvpn and best practices etc. ------Original Message------ From: Randy Bush To: Charles Wyble Cc: nanog(a)nanog.org Subject: Re: dns interceptors Sent: Feb 14, 2010 7:10 PM > I run openvpn on my linux box to do exactly that. i am in the midst of setting up some openvpn servers now, westin, ashburn, tokyo, but westin first. having problems sorting in what --outform it wants the bleeping certs. randy Sent via BlackBerry from T-Mobile

5 7

Re: dns interceptors
by charles＠knownelement.com 15 Feb '10

15 Feb '10

Yes. Easy rsa is the way to go. They are normal certs. Check the scripts if you want to roll your own openssl wrapper scripts. ------Original Message------ From: Larry Brower To: nanog(a)nanog.org Subject: Re: dns interceptors Sent: Feb 14, 2010 7:44 PM Randy Bush wrote: > end user to network > > having probs with certs, i.e. what --outform it wants. not finding in > docs. tried raw, but now guessing pem. same for client and server > > server > ca.crt > server.crt > server.key > > client > ca.crt > client.crt > client.key > > and i presume i have to dump all client.crt files in the server's > ../openvpn dir, but under what names? or does it just wantonly trust > anyone under that ca? > > randy > > What error is getting logged? They are just normal cert's and should be in the keys directory under openvpn's user directory. OpenVPN includes scripts that can make the certificates for you under the directory easy-rsa Sent via BlackBerry from T-Mobile

1 0

Time out for a terminology check--"resolver" vs "server".
by Larry Sheldon 15 Feb '10

15 Feb '10

I thought I understood but from recent contexts here it is clear that I do not. I thought a resolver was code in your local machine that provide hostname (FQDN?), given address; or address, given host name (with assists to build FQDN). And I thought a "server" was a separate program, might be on the same machine, might be on another machine (might be on the local net, might be distant) that the resolver code called for information that was not in local cache. Just what is the straight scoop? -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml

6 9

Re: dns interceptors
by charles＠knownelement.com 15 Feb '10

15 Feb '10

I run openvpn on my linux box to do exactly that. Already running apache/bind/postfix/xmpp with legacy Im bridges so adding openvpn was a logical next step. #protip run it on port 443. :) makes it much easier to get around firewalls. Even with deep packet inspection, SSL traffic is expected on that port. I have business class att dsl and 7 static ip addresses. I run a dell optiplex desktop 24x7 and it sips power. You could also just host services in a Colo for around 20.00 a month for dedicated virtual server. You would probably pay that anyway to a company who provided the services you mentioned. Lots of risk with being smtp relay for the world. Just ask yahoo/sbc who provide large swaths of southern California with net access. They provide dns and authenticated/encrypted smtp outbound and charge 14.95 a month for the cheap package. Sent via BlackBerry from T-Mobile

2 1