Re: Windows 2008/2012 arp timeout process

[Marcel Plug <marcelplug () gmail com>]

Hi James,

Is your windows client seeing traffic from the 6500 with the real (Burned
in) MAC address of your 6500?  If 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  HSRP
MAC.

My memory is fuzzy, but I think I've seen issues like that before.  Sorry
its been a while so I can't remember anything more specific.

-Marcel


On Thu, Nov 29, 2012 at 5:22 PM, James Stoll <eng.jstolli () yahoo com> wrote:

> 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