[158459] in North American Network Operators' Group
Re: Windows 2008/2012 arp timeout process
daemon@ATHENA.MIT.EDU (James Stoll)
Fri Nov 30 11:29:47 2012
Date: Fri, 30 Nov 2012 08:05:32 -0800 (PST)
From: James Stoll <eng.jstolli@yahoo.com>
To: Marcel Plug <marcelplug@gmail.com>
In-Reply-To: <CACfXSnDUuuZeuFsvBM-1GHPgu+6deezGPsmYLjbqFKqyjN3HGQ@mail.gmail.com>
Cc: "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
No, but to isolate any possible layer2 traffic that could affect the issue,=
one of my colleagues performed host to guest testing in a VM and we are se=
eing the same issue.=0A=0A14:28:30.420589 00:1c:42:d7:92:84 > 00:1c:42:00:0=
0:08, ethertype ARP (0x0806), length 42: Request who-has 10.211.55.2 (00:1c=
:42:00:00:08) tell 10.211.55.3, length 28=0A14:28:30.420684 00:1c:42:00:00:=
08 > 00:1c:42:d7:92:84, ethertype ARP (0x0806), length 60: Reply 10.211.55.=
2 is-at 00:1c:42:00:00:08, length 46=0A14:29:03.421388 00:1c:42:d7:92:84 > =
00:1c:42:00:00:08, ethertype ARP (0x0806), length 42: Request who-has 10.21=
1.55.2 (00:1c:42:00:00:08) tell 10.211.55.3, length 28=0A14:29:03.421505 00=
:1c:42:00:00:08 > 00:1c:42:d7:92:84, ethertype ARP (0x0806), length 60: Rep=
ly 10.211.55.2 is-at 00:1c:42:00:00:08, length 46=0A14:29:36.423363 00:1c:4=
2:d7:92:84 > 00:1c:42:00:00:08, ethertype ARP (0x0806), length 42: Request =
who-has 10.211.55.2 (00:1c:42:00:00:08) tell 10.211.55.3, length 28=0A14:29=
:36.423463 00:1c:42:00:00:08 > 00:1c:42:d7:92:84, ethertype ARP (0x0806), l=
ength 60: Reply 10.211.55.2 is-at 00:1c:42:00:00:08, length 46=0A14:30:09.4=
24479 00:1c:42:d7:92:84 > 00:1c:42:00:00:08, ethertype ARP (0x0806), length=
42: Request who-has 10.211.55.2 (00:1c:42:00:00:08) tell 10.211.55.3, leng=
th 28=0A=0A=0AThe "real" traffic was just pings between the host/vm, and a =
raw capture was performed and the only mac addresses in use were the ones l=
isted above.=0A=0A=0A=0A________________________________=0A From: Marcel Pl=
ug <marcelplug@gmail.com>=0ATo: James Stoll <eng.jstolli@yahoo.com> =0ACc: =
"nanog@nanog.org" <nanog@nanog.org> =0ASent: Friday, November 30, 2012 8:35=
AM=0ASubject: Re: Windows 2008/2012 arp timeout process=0A =0A=0AHi James,=
=0A=0AIs your windows client seeing traffic from the 6500 with the real (Bu=
rned in) MAC address of your 6500? =A0If so it may be re-arping to find out=
which of the MAC addresses is the 'right' one to use, the real MAC or the =
=A0HSRP MAC.=0A=0AMy memory is fuzzy, but I think I've seen issues like tha=
t before. =A0Sorry its been a while so I can't remember anything more speci=
fic.=0A=0A-Marcel=0A=0A=0A=0AOn Thu, Nov 29, 2012 at 5:22 PM, James Stoll <=
eng.jstolli@yahoo.com> wrote:=0A=0AGreetings Nanog,=0A>=0A>I apologize in a=
dvance 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. Afte=
r digging into the sources, it looks like windows 2008/2012 systems are sen=
ding arp refresh requests quite frequently.=0A>=0A>According to this articl=
e ( http://support.microsoft.com/kb/949589 ), if the neighbor entry is in u=
se for the IP it should not go stale. Specifically:=0A>=0A>"If the entry is=
in the "Reachable" state, Windows Vista TCP/IP hosts do not send ARP reque=
sts to the network. Therefore, Windows Vista TCP/IP hosts use the informati=
on in the cache. If an entry is not used, and it stays in the "Reachable" s=
tate 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."=0A>=0A>I know th=
at states Windows Vista, but the "applies to" section lists the other OSes.=
=0A>=0A>I've replicated this in my lab (server pinging its own gateway whil=
e capturing traffic), and I am seeing the same issue:=0A>=0A>222=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_0a=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=0A>223=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 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=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 ARP=A0=A0=A0=A0=A0=A0=A0 Wh=
o has 10.36.0.1?=A0 Tell 10.36.0.31=0A>1887=A0=A0=A0=A0=A0=A0 10:06:31.9630=
04=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 i=
s at 00:00:0c:07:ac:0a=0A>3348=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-rou=
ters_0a=A0=A0=A0=A0=A0=A0 ARP=A0=A0=A0=A0=A0=A0=A0 Who has 10.36.0.1?=A0 Te=
ll 10.36.0.31=0A>3349=A0=A0=A0=A0=A0=A0 10:07:23.471003=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:d=
c: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=
=0A>=0A>I've tried this on various devices, and the only place I don't see =
this behavior is on wireless interfaces.=0A>=0A>I'm more of a linux guy, an=
d 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:=0A>=0A>"Entries in the ARP cache are periodically and automa=
tically verified unless continually used."=0A>=0A>Has anyone run into this =
issue before ? Have a fix ? Point me to any documentation or other distros =
that I should ask ?=0A>=0A>TIA,=0A>James=0A>
