Sleeping Apple Devices Responding to ARP Requests for the Default Gateway Hoping to get some insight regarding a bizarre issue that is being seen at a few of our networks, as well as others (based off reddit and NANOG posts). The short story of what is happening is that Apple devices (primarily MacBooks as well as some iMacs) that are sleeping will hijack the default gateway IP for the wireless VLAN that they are in, as well as responding to ARP requests asking who the default gateway is. This behavior makes the AP's log a message "CAPWAP detected next hop MAC changed from correct_DG_mac_address to apple_mac_address."

We have tickets open with Cisco who is blaming Apple, and Apple who is stating we need logs that are utterly impossible to get as we cannot recreate this behavior. Apples current workaround? Push out a script to completely disable sleep on all Apple devices.

More specifics:


This is only affecting 3802i WAPs that are in flexconnect mode, and
we are seeing this at multiple sites, on two different wireless
controllers. The 3802i's do not reboot - they lose connectivity,
recover, repeat.
Wireless subnets are generally as large as /20 and contain the AP's
as well as all clients. We plan to move AP's to a different subnet as
a test, but we are hesitant due to the fact that if AP's no longer
log the CAPWAP message/drop from Prime - then we will not know when
this behavior occurs making it harder to track.
The ARP entry on the switches NEVER changes. For this reason, I
believe DAI/DHCP snooping would not be an effective solution as I've
seen others suggest.
We think this behavior may be related to sleep proxy that can we seen
with out of the box Apple TV's, but have yet to prove that.


My question is - has anyone ran into this type of behavior before. In addition, does anyone have any suggestions as far as how to remedy this behavior so it no longer occurs?
We've been experiencing this issue and we're running Cisco 3802 Flex Connect with a WLC 8500.

We are going to attempt DIA This weekend but from both Cisco and Apple they are saying there isn't much we can do. Cisco is saying they will have a patch for the Wireless Controller to introduce ARP security for this in about a month and Apple won't release to the public what is the issue or when their patch would be out to fix it.

Some Options that have been floated to us as a Temp Solution
-- Downgrade the WLC to 8.2 from the current recommended version 8.5.140
-- Upgrade the WLC to 8.5.140.11 a special release not provided without support consent that will require DHCP reassociation on every device when roaming. Not a great Trade off.
-- Remove Flex Connect and re design your WLAN to Central which would tunnel the ARP traffic to the WLC and use built in security for ARP protection. "We are not going to do this"

What we will be trying!
Enable DIA on the Switching platform and log the drops. The hope is if this is from a sleeping Macbook then the getting dropped won't matter and we'll see some kind of containment. 

This is our last option.