Wireless Access

Hey,

i am running an Aruba Mobility Controller based wireless network. I get reports from some users that their devices do not receive any ARP traffic after connecting to a wireless network, this includes the ARP replies from the router. This leads to some devices trying to reconnect to the network because they do not have a internet connection.

I can confirm this issue by looking at my own traffic after connecting to the network, it takes up to 45 seconds for the ARP replies to reach my device.

I have "Dynamic Multicast Optimization" enabled (threshold of 6), "Convert Broadcast ARP requests to unicast" is also enabled, "Drop Broadcast and Multicast" is disabled. I am running version 8.3.0.6.

Is this a know issue? Can it be fixed easily or do i have to investigate further?

"Drop Broadcast and Unknown Multicast" should be enabled in most networks on all Virtual APs, because the level of brodcast traffic in networks can overwhelm unicast traffic and needs to be controlled.

Dynamic Multicast Optimization, in this scenario, typically does not play a part.

Thanks for your reply. I tried that option but that doesn't seem to fix the problem. In fact, it seems to make it worse, my laptop does not get any ARP replies at all after enabling that feature. I turned off "Drop Broadcast and Multicast" and "Convert Broadcast ARP requests to unicast" completely and now I am recieveing ARP replies again.

I still would like to use those features, so I would be glad if we could find a solution to this problem.

You mentioned that users complain that they do not get ARP replies.  How do users know that?  How long has this been happening?  What non-default settings do you have on your mobility controller?

It got reported occasionally since we run the system. Recently it happened to me as well and I could verify that it is an ARP issue by looking at my traffic. Users experienced disconnects an “no internet connection” warnings.

What do you mean by “non-default settings” on the controller? I do the configuration manly via the web interface.

Ok.

Are the client computers Windows machines?

Are you using encryption on that wireless network?

The issue has been observed on all kinds of devices, but mostly Android automatically disconnects if no ARP is recieved. I have confirmed it unsing Wireshart on macOS.

The network is secured using WPA2-Enterprise.

How long has it been happening?  Have there been any changes on the network?

We have had issues regarding ARP for some time in the wifi, I cannot exactly specify when it started. At first i thought it might be our new core switch (Aruba 8320) which also is the gateway in the network, but the issue does not occur when connecting to the same network wired or via our old WiFi System.

You should definitely open a TAC case in conjunction with this post to ensure someone can look at your configuration unredacted.

Were you able to open a TAC case?  Did anything come from it?  I am having the same issues on the same code version.  Thanks for any help you can provide.

No, I did not open a TAC Case for this. We had to fresh install of the system for some other reasons and since then we haven't had a lot of reports regarding this issue. Only one client with a self-complied Linux OS is experiencing this kind of problems.

If you open a TAC case for this, please let us know what your resolution was.

When you reinstalled did you reinstall 8.3.0.6 or a different version?

We have this behavior in our environment as well.  Most of our Windows devices are resilient and only lose a ping or two, but its enough to disrupt.  We have other devices (tunneled-nodes) that will initially dhcp and come online, but then once their arp expiration timer is exceeded they never reacquire a connection.

I have a TAC case open and we have been battling this for 5 months with no resolution.

That seems to be  different from the OP who is not using tunneled node.  The op said that it was happening on wifi and immediately after they connect.  It sounds like a different issue.  If you want to  open a different thread, detailing your issue with code version and topology that would give others who might be experiencing it, more specific information.