With help from an Aerohive engineer, we saw that the issue looked to be related to Bonjour. After checking our BG settings, I saw that the Max Wireless Hop setting had been changed from 1 (which is what I had it set at) to 0 (which is unlimited and the default setting). After changing the setting back to 1, the issue was resolved.
I believe this occurred as a result of the upgrade of HM from 6.1r6 to 6.2r1. The complaints started to come in around the time after the upgrade. The upgrade from 6.2r1 to 6.2r1a did not change the setting.
Also - how many SSID's are your broadcasting?
In the end, remove network overhead, and Air-Time utilization.
To talk to another point in Mike's post, I had discussions with the various support engineers that worked with Mike on this case as to what was and was not tried and the logic behind these decisions. While keeping our internal processes to ourselves please be assured that we will use this case, like all cases, to improve our support to you, our users.
I am confident that we will get Mike's Aerohive installation humming along in short order. I hope that he decides to post the results of how his problem is solved.
The client would show as connected, and sniffing the network showed DHCP packets were going out from the server...but the client didn't see them. The firmware that we used when we deployed our switches had a bug that would drop DHCP packets, and this drove us crazy until we upgraded all of them.
Now our clients connect flawlessly, and roam with ease.
When it is happening, there are no errors or dropped packets on the switches on the ports the APs are connected to.
We downgraded from 6.4r1a.2103 to 6.1r6a.1794 on the APs and the problem has gone away - hasn't been seen for weeks with the old software version.
Time for a ticket of my own.
I wasn't able to resolve by reverting but by turning off DAS.
I did see some differences in previous versions so thought I would post them for others as a guide to what I experienced in testing because there is a lot of post discussion of previous versions by some pretty knowledgeable people on these forums.
I don't think that cleaning up memory issues will help when as soon as DAS is turned on with no clients it still shoots instantly to 99% and stays there regardless of any clients which doesn't seem related to freeing up memory issues
I seem to have problems with DAS being to much for the small footprint.
so are you saying I should turn DAS back on? and ignore the cpu it is designed to operate at that high level. Can the 121 handle DAS and then should I be seeing those cpu levels or Do I have other issues I need to look at is my real question? Is it just me and our setup.
there is a warning of sorts that DAS is only added to admin profiles not default?
Sorry, I know nothing about these systems so hence the question I am hoping for some helpful feedback from others. These units were installed education wide across the whole country not that long ago so it seems we have inherited almost redundant product for very high density usage which is not very inspiring.
We have also notised this problem on AP121. And may have found a couse.
We use multiple vlan (802.1Q) on the AP-backhaul.
We noteced that the switch had a vlan (802.1Q) on the port connected to the AP that was not used in any of profiles on the AP. This vlan hosted a large L2-Broadcast domain whith a fair bit of broadcast and multicast. and even if the AP doesent have the vlan in its configuration it still couses the the cpu in the AP to peak upto 100% from time to time.
Ive believe this can be coused by software handling of 802.1Q tagged frames in CPU and that 802.1Q is not handled by the AP:s nic in "hardware".
Others can try this by disbling vlan by vlan on the switchport until you se the the cpu go down.
We are running HiveOS 6.5r5