[158430] in North American Network Operators' Group
Windows 2008/2012 arp timeout process
daemon@ATHENA.MIT.EDU (James Stoll)
Thu Nov 29 20:34:41 2012
Date: Thu, 29 Nov 2012 14:22:13 -0800 (PST)
From: James Stoll <eng.jstolli@yahoo.com>
To: "nanog@nanog.org" <nanog@nanog.org>
Reply-To: James Stoll <eng.jstolli@yahoo.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Greetings Nanog,=0A=0AI apologize in advance if this should be directed tow=
ards 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 per=
forming 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 frequ=
ently.=0A=0AAccording to this article ( http://support.microsoft.com/kb/949=
589 ), if the neighbor entry is in use for the IP it should not go stale. S=
pecifically:=0A=0A"If the entry is in the "Reachable" state, Windows Vista =
TCP/IP hosts do not send ARP requests to the network. Therefore, Windows Vi=
sta 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 "Stal=
e" state, the Windows Vista TCP/IP host must send an ARP request to reach t=
hat destination."=0A=0AI know that states Windows Vista, but the "applies t=
o" section lists the other OSes. =0A=0AI've replicated this in my lab (serv=
er pinging its own gateway while capturing traffic), and I am seeing the sa=
me issue:=0A=0A222=A0=A0=A0=A0=A0=A0=A0=A0 10:05:18.462720=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Dell_a6:dc:52=A0=A0=A0=A0 All-HSRP-routers_0=
a=A0=A0=A0=A0=A0=A0 ARP=A0=A0=A0=A0=A0=A0=A0 Who has 10.36.0.1?=A0 Tell 10.=
36.0.31=0A223=A0=A0=A0=A0=A0=A0=A0=A0 10:05:18.464759=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 All-HSRP-routers_0a=A0=A0=A0=A0=A0=A0 Dell_a6:dc:5=
2=A0=A0=A0=A0 ARP=A0=A0=A0=A0=A0=A0=A0 10.36.0.1 is at 00:00:0c:07:ac:0a=0A=
1886=A0=A0=A0=A0=A0=A0 10:06:31.962218=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 Dell_a6:dc:52=A0=A0=A0=A0 All-HSRP-routers_0a=A0=A0=A0=A0=A0=A0 A=
RP=A0=A0=A0=A0=A0=A0=A0 Who has 10.36.0.1?=A0 Tell 10.36.0.31=0A1887=A0=A0=
=A0=A0=A0=A0 10:06:31.963004=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 A=
ll-HSRP-routers_0a=A0=A0=A0=A0=A0=A0 Dell_a6:dc:52=A0=A0=A0=A0 ARP=A0=A0=A0=
=A0=A0=A0=A0 10.36.0.1 is at 00:00:0c:07:ac:0a=0A3348=A0=A0=A0=A0=A0=A0 10:=
07:23.461682=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Dell_a6:dc:52=A0=
=A0=A0=A0 All-HSRP-routers_0a=A0=A0=A0=A0=A0=A0 ARP=A0=A0=A0=A0=A0=A0=A0 Wh=
o has 10.36.0.1?=A0 Tell 10.36.0.31=0A3349=A0=A0=A0=A0=A0=A0 10:07:23.47100=
3=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 All-HSRP-routers_0a=A0=A0=A0=
=A0=A0=A0 Dell_a6:dc:52=A0=A0=A0=A0 ARP=A0=A0=A0=A0=A0=A0=A0 10.36.0.1 is a=
t 00:00:0c:07:ac:0a=0A=0AI've tried this on various devices, and the only p=
lace I don't see this behavior is on wireless interfaces.=0A=0AI'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/e=
ther-arp.html . Specifically:=0A=0A"Entries in the ARP cache are periodical=
ly and automatically verified unless continually used."=0A=0AHas anyone run=
into this issue before ? Have a fix ? Point me to any documentation or oth=
er distros that I should ask ?=0A=0ATIA,=0AJames
