Reset Search
 

 

Article

Apple/IOS Bonjour Sleep Proxy Claiming Default Gateway IP address

« Go Back

Information

 
TitleApple/IOS Bonjour Sleep Proxy Claiming Default Gateway IP address
Symptoms
Wireless Clients associate to access point successfully, and acquire DHCP addresses properly, but are not able to pass traffic outside their own subnet/VLAN
Issue is sporadic and may come and go
Environment
ExtremeWireless
IdentiFi Wireless
A mix of IOS and Android clients on the same WLAN/SSID
All versions
Cause

This issue is due to a "newer Android device" sending out a packet which is L3 destined to the IP of default gateway, and L2 destined for the MAC broadcast (all F's). For reasons that Apple still hasn't figured out, sleeping Apple devices (primarily MacBooks) react in such a way with Cisco's architecture when an environment is implementing local switching only which by default enables proxy arp/arp caching that the WAP's will send a proxy arp out up to 5 times a second on behalf of the Apple device stating that the default gateway is the Apple's MAC address.

Here is the document that Cisco recently posted regarding this issue.

This issue also affects multiple other vendor's wireless solutions. Below, are several links to internet community threads that have portions that call out Cisco, Meraki and Aruba also, as being affected by this issue:

Cisco: https://www.cisco.com/c/en/us/support/docs/wireless/aironet-3800-series-access-points/214491-arp-responses-for-default-gateway-ip-add.html 

Aruba: https://lists.gt.net/nanog/users/203412 

Meraki: https://apple.stackexchange.com/questions/358977/sleeping-apple-devices-responding-to-arp-requests-for-the-default-gateway

Resolution

If the topology being used is Bridged@AP, disabling "ARP Proxy" for any affected topologies should resolve this issue (see below):

User-added image

If you are using topologies that are Bridged@WirelessController, ARP Proxy is enabled by default and you cannot disable it.  Transitioning to B@AP topologies from B@WC topologies is possible, and in some ways and for some customer situations, may even be a more advantageous design choice in terms of overall traffic distribution for wireless clients.  If you need assistance making that transition, please call GTAC at 800-872-8440 so we can open a case and assist you in that effort.

Other "solutions" that may work for you:

  • While the issue is happening, do a packet capture for 5-10 minutes. Load it up in Wireshark, and filter by the following:

icmp && eth.addr == ff:ff:ff:ff:ff:ff

This will most likely give you a few icmp packets sourced from MurataMa MAC address, which in our case turned out to be a Samsung S10 device. Block it.

  • This is more of an extreme solution, but it still works. Push out a script on all of the MacBooks which disables sleep entirely.

sudo pmset -a disablesleep 1

See also:  
Clients get correct IP addresses but not able to pass traffic through default gateway  
Apple devices answer ARPs for the gateway

Additional notes
wns0022783

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255