Wireless client ARP caching, or the worst kind of high-tech laziness

As I no longer work as the senior network engineer at Plantronics, I have been reconfiguring an old Cisco 8xxW series device for use as my local router/gateway.  Given that I no longer administer a WLC, I am configuring the access point in autonomous mode.  I have been suffering for the last couple days because everything was working terrifically, except that I no longer had connectivity between wireless devices.

More specifically, wireless clients could connect to wired clients, and vice versa.  Wireless clients could not interact with other wireless clients, unless the ARP request happened in the first few moments after one of the wireless clients authenticated (before the AP added the client’s IP address to it’s internal table).  After much gnashing of teeth, packet traces, and web searches related to things like PSPF, I found this little gem on Cisco’s website:

When the wireless device receives an ARP request for an IP address not in the cache, the wireless device drops the request and does not forward it. In its beacon, the wireless device includes an information element to alert client devices that they can safely ignore broadcast messages to increase battery life. (link)

As it turns out, all that is required is for my access point to actually respond to client ARP requests instead of sometimes forwarding the requests (dropped by the client) or dropping them out of hand.  I tested both of these, and they both worked great.

dot11 arp-cache
dot11 arp-cache optional

Now I have back the functionality I really wanted, which is to say, ARD from my laptop to the Mac Mini in the living room to add more time for children with homework and the burden of parental controls without actually having to get my lazy ass up and walk there.

Laziness rules.

Leave a Reply