[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Windows 2008/2012 arp timeout process



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 at 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
>