On 02/08/16 04:19, Peter P Morrissey wrote: > Given my understanding of the way arp works, not sure I understand how > it is possible for a large subnet to cause a client arp table to become > exhausted unless that client for some reason is directly communicating > with all of the other endpoints on the large subnet. > > My understanding is that the table is only populated in response to arp > queries that the client has initiated, even though it can “hear” > responses from other clients that are sent as a broadcast. It is easy > enough to verify this on Windows with an arp –a. > > I also don’t believe that broadcast traffic can have a material impact > on clients these days due to increases in CPU power at the magnitude of > Moore’s Law.
Sadly there is no Moore's Law for batteries. OS X since 10.10 will aggressively sleep and miss broadcast ARP packets. I have seen this on four different AP vendors and have the wireless captures to prove it. Generally it doesn't cause user-visible problems, and it can be worked around by enabling proxy ARP on the APs/controller (if the vendor supports it). It will most likely present problems if the clients are trying to access servers on the same subnet and it's the *server's* ARP cache that gets exhausted (or simply expires the client). The client will resolve the server's MAC address OK, send the SYN packet, then the server will send a broadcast ARP request to resolve the client's MAC address, which can be missed by the Mac laptop. Depending on the level of broadcast traffic, it can take a minute or more with retries before a connection is established. For wireless designs where all data goes through the gateway and there's no client communication to other devices on the same subnet you probably won't notice a problem as the gateway's ARP cache will always be fresh. We saw it because we have a campus-wide flat L2 network shared between wired and wireless, and I also noticed a lot of ARP traffic from laptops looking for Apple TV IP addresses. We have filed a ticket with Apple, radar://26488949 if anyone has any contacts to escalate it. The fastest resolution we've had for any Apple bug is 3 years, so I don't expect this to be fixed any time soon. -- James Andrewartha Network & Projects Engineer Christ Church Grammar School Claremont, Western Australia Ph. (08) 9442 1757 Mob. 0424 160 877 ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
