Question on neighbor cache behavior
Assuming Windows Server 2008 R2, I have an neighbor cache entry (say a regular ARP entry for my default gateway) in "reachable" state. As far as I understand the following is the default behavior: Assuming there is no active conversation via my default gateway, the entry will go in a "stale" state after 15-45 seconds (randomized) If the entry is in a "stale" state and a conversation should start again Windows will re-ARP before sending traffic Question: Is it correct that Windows will never try to refresh a neighbor cache entry unless there is traffic being sent to/via this destination? (Certain network gear operating systems will re-arp before they time out a value hence the question. Also RFC4861 is very vague with regards to garbage collection of such entries.) Scenario 2 (still same OS with an ARP entry for it's default gateway). According to various articles on the web, Vista/7/2k8 does not honor GARP messages to change entries in the neighbor cache. Question: Assuming the default gateway sends a GARP with the exact same information as already present in the cache, will the timer be reset? I found a number of documents around Windows 2003 IP stack registry settings but had a hard time finding the same level of detail for Vista/7/2k8. Any pointers and insight is greatly appreciated!
January 25th, 2011 9:50am

From captures I have performed Windows does not spontaneously refresh its ARP cache. Dynamic ARP entries appear to stick around for a while but if you were to say ping a host whose entry is old a packet capture reveals that another ARP request is sent for the destination.Matt W. CCNP, CCDA, CCNA-S, RHCT, MCSE, MCSA, MCP+I, A+
Free Windows Admin Tool Kit Click here and download it now
January 25th, 2011 6:16pm

Thanks Matt. That's inline with my understanding. As for the 2nd question: any chance you ever tried sending a GARP with the exact information as existing in the server's ARP/Neighbor cache? I wonder if an entry's timer would be reset... Thanks.
January 25th, 2011 7:55pm

I haven't tried using GARP in that way. If the host needed to reach another layer 3 address it would just ARP for the MAC of the destination station. I'm not sure GARP would be needed to keep the entry alive as it would be refreshed on demand. You could always create a static ARP entry on the host, switch, etc to make the mapping permanent across the layer 2 switch fabric but this wouldn't be advisable if you expect the MAC mappings to change or move around for something like clustering or failover applications.Matt W. CCNP, CCDA, CCNA-S, RHCT, MCSE, MCSA, MCP+I, A+
Free Windows Admin Tool Kit Click here and download it now
January 25th, 2011 9:30pm

Thanks Matt. Reason for me trying to keep the default gateway's ARP entry active is simple. I'm building large data centers (talking 1,000s or 10,000s servers/VMs spread over a set of VLANs). If all of those re-ARP frequently for their default gateway this creates load on the control plane of the switch/router representing the default gateway. If the switch had an option to proactively send out one GARP (per VLAN) updating all cache entries of the clients they would not have to re-ARP so frequently. For IPv6 I can obviously tune this via central router configuration but for IPv4 I don't have such an option. I could tweak things in the registry for IPv4 (basereachable) but I'd rather not touch that many hosts...
January 25th, 2011 10:00pm

On large datacenter core switches like Cisco 65XX with Sup720 or 720-10G and Nexus class switches I don't think this would be something I would be overly concerned about. Relatively speaking ARP packets are going to be quite small and unless you are being attacked at layer 2 (which has its own protection features available if you choose to implement them) I haven't seen this become a problem in any of my large datacenters in the past. If the network is designed properly, and you don't have lots of trunk links forwarding ARP requests to core switches with end-to-end layer 2 vlans that span entire campuses for instance, I don't think this would be one of my bigger concerns. Implement good layer 2 security, use QoS to prioritize/shape/police/whatever traffic if you have congestion issues, and overbuild the core as much as you can afford.Matt W. CCNP, CCDA, CCNA-S, RHCT, MCSE, MCSA, MCP+I, A+
Free Windows Admin Tool Kit Click here and download it now
January 26th, 2011 1:58am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics