November 2012 - Test - lists.nanog.org

Windows 2008/2012 arp timeout process
by James Stoll 30 Nov '12

30 Nov '12

Greetings Nanog, I apologize in advance if this should be directed towards a server/systems discussion list, but I've noticed some (what I think are) issues with the way windows 2008/2012 handles arp. I started noticing some high arp processes on some of our 6500s running sup720s, and after performing some captures of packets being punted to the cpu I found that there were quite a few repeat sources. After digging into the sources, it looks like windows 2008/2012 systems are sending arp refresh requests quite frequently. According to this article ( http://support.microsoft.com/kb/949589 ), if the neighbor entry is in use for the IP it should not go stale. Specifically: "If the entry is in the "Reachable" state, Windows Vista TCP/IP hosts do not send ARP requests to the network. Therefore, Windows Vista TCP/IP hosts use the information in the cache. If an entry is not used, and it stays in the "Reachable" state for longer than its "Reachable Time" value, the entry changes to the "Stale" state. If an entry is in the "Stale" state, the Windows Vista TCP/IP host must send an ARP request to reach that destination." I know that states Windows Vista, but the "applies to" section lists the other OSes. I've replicated this in my lab (server pinging its own gateway while capturing traffic), and I am seeing the same issue: 222 10:05:18.462720 Dell_a6:dc:52 All-HSRP-routers_0a ARP Who has 10.36.0.1? Tell 10.36.0.31 223 10:05:18.464759 All-HSRP-routers_0a Dell_a6:dc:52 ARP 10.36.0.1 is at 00:00:0c:07:ac:0a 1886 10:06:31.962218 Dell_a6:dc:52 All-HSRP-routers_0a ARP Who has 10.36.0.1? Tell 10.36.0.31 1887 10:06:31.963004 All-HSRP-routers_0a Dell_a6:dc:52 ARP 10.36.0.1 is at 00:00:0c:07:ac:0a 3348 10:07:23.461682 Dell_a6:dc:52 All-HSRP-routers_0a ARP Who has 10.36.0.1? Tell 10.36.0.31 3349 10:07:23.471003 All-HSRP-routers_0a Dell_a6:dc:52 ARP 10.36.0.1 is at 00:00:0c:07:ac:0a I've tried this on various devices, and the only place I don't see this behavior is on wireless interfaces. I'm more of a linux guy, and performing the same tests there I see the behavior stated in this article (which is what I would expect) - http://linux-ip.net/html/ether-arp.html . Specifically: "Entries in the ARP cache are periodically and automatically verified unless continually used." Has anyone run into this issue before ? Have a fix ? Point me to any documentation or other distros that I should ask ? TIA, James

2 2

[tor-relays] Bandwidth and server leads [was: Tor raid]
by Eugen Leitl 30 Nov '12

30 Nov '12

----- Forwarded message from grarpamp <grarpamp(a)gmail.com> ----- From: grarpamp <grarpamp(a)gmail.com> Date: Thu, 29 Nov 2012 17:36:33 -0500 To: tor-relays(a)lists.torproject.org Cc: elw(a)stderr.org Subject: [tor-relays] Bandwidth and server leads [was: Tor raid] Reply-To: tor-relays(a)lists.torproject.org > From: elijah wright <elw(a)stderr.org> > Date: Thu, 29 Nov 2012 13:38:51 -0600 > Cc: nanog(a)nanog.org > Subject: Re: William was raided for running a Tor exit node. > We had a guy (aka potential customer) inquire the other day about hosting a > Tor exit on our infrastructure the other day; he disappeared fairly > quickly when he figured out that we weren't just going to give him an > endless supply of unmetered 10G bandwidth. I was looking forward to > billing him. :-) Contemporary mailing list lols aside, I believe you'll find that most operators in this space are quite serious and professional. If you're a potential friend of Tor, anonymity networks and the general thought space around it... and your price [or that of someone you know, nanog or otherwise, who might be such a friend] was highly competitive, or even special... I'd be fairly confident that consultation with those on this list would lead to a sale of said (or related) billable services. Feel free to forward and/or put any interested parties in touch with this list or torproject.org. _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

OpenBGPd problems relating to misuse of RESERVED bits in BGP Attribute Flags field
by Jeff Wheeler 29 Nov '12

29 Nov '12

I had two downstream BGP customers experience problem with an OpenBGPd bug tonight. Before diving into detail, I would like to link this mailing list thread, because this is not a new issue and a patch is available: http://www.mail-archive.com/misc@openbsd.org/msg115071.html For the following DFZ routes, I see wrong use of the fifth bit in the Attribute Flags field: Aggregator (7), length: 8, Flags [OT+8]: AS #68, origin 192.65.95.253 0x0000: 0000 0044 c041 5ffd Updated routes: 128.165.0.0/16 141.111.0.0/16 192.65.95.0/24 192.12.184.0/24 204.121.0.0/16 According to RFC 4271 page 17, "the low-order four bits of the Attribute Flags octet are unused. They MUST be zero when sent and MUST be ignored when received." I read "ignored" to mean, don't tear down the BGP session and print a cryptic error that the user probably will be unable to debug. The OpenBGPd guys clearly agree and have supplied a patch, so affected users should visit the above mailing list link, and install it. Here are my notes for this RFC page and a small diagram of the packet header, because surprisingly, there isn't one in the RFC already http://inconcepts.biz/~jsw/img/1121129aa-rfc4271pg17scan.jpg Sorry about the poor quality of this, but it is past 3am here, and I know of several operators (besides my downstream customers) who are experiencing this problem right now. If I were someone who is broken by this right now, I would either patch my OpenBGPd or ask your eBGP neighbors not to send you the above five routes (filtering it on your own OpenBGPd router probably won't help.) Thanks, I hope this is helpful -- Jeff S Wheeler <jsw(a)inconcepts.biz> Sr Network Operator / Innovative Network Concepts

4 4

Syria off the net
by George Herbert 29 Nov '12

29 Nov '12

The press is reporting on Renesys' report that Syria has finally dropped all its internet connectivity earlier this morning: http://www.renesys.com/blog/2012/11/syria-off-the-air.shtml http://m.washingtonpost.com/blogs/worldviews/wp/2012/11/29/web-monitor-100-… George William Herbert Sent from my iPhone

1 0

None
by andra.lutu＠imdea.org 29 Nov '12

29 Nov '12

Sent from my Nokia phone

1 0

juniper vpn
by Jeroen van Aart 29 Nov '12

29 Nov '12

Hello, Does anyone know a practical and somewhat user friendly way of connecting to juniper vpn using linux? I have happily used http://www.unix-ag.uni-kl.de/~massar/vpnc/ a allow linux users to connect cisco vpn boxes where a crappy cisco vpn client would be needed otherwise, and it works very nicely. I was hoping there exists a similar tool for juniper vpn. Thank you, Jeroen -- Earthquake Magnitude: 4.0 Date: Wednesday, November 28, 2012 00:20:46 UTC Location: Dominican Republic region Latitude: 19.3090; Longitude: -68.8393 Depth: 139.00 km

7 9

Looking for Alcatel GPON sales
by Tom Mikelson 28 Nov '12

28 Nov '12

Having trouble contacting anyone in Alcatel GPON sales, please contact me off-list.

1 0

Re: Middle East MPLS
by Scott Weeks 28 Nov '12

28 Nov '12

--- 2asx1y702(a)sneakemail.com wrote: Anyone from Etisalat on list? I'm interested in some MPLS connectivity into Dubai. ------------------------------------ Try on the MENOG list. scott

3 2

Middle East MPLS
by 2asx1y702＠sneakemail.com 28 Nov '12

28 Nov '12

Anyone from Etisalat on list? I'm interested in some MPLS connectivity into Dubai. kyle(at)epic(dot)com

2 1

1310nm optics over Corning LEAF G.655?
by Tim Durack 28 Nov '12

28 Nov '12

Anyone run 1000BASE-LX/10GBASE-LR 1310nm optics over a ~10km Corning LEAF G.655 span? I understand this fiber is not optimized for such usage, but what is the real-world behaviour? I'm having a hard time finding hard data. (Normal optics will be 1550nm and DWDM over ~40-100km spans.) -- Tim:>

2 3