I have been seeing a lot of LCC broad cast traffic from my AeroHives and it appears to be causing a broadcast storm on my network.
Disconnecting the AreoHive management switch removes the issues on the network instantly.
Below is a copy of the wireshark capture.
I see other people have also reported the issue but no solution has been offered.
Yes they are causing some major issues with communication on the network. I am in the process of clearing up the network as the management VLAN is far too big.
However I would still like to find an explanation for this broadcast traffic and if it is not required stop the system broadcasting.
I would start by looking at your usage requirements, as going forward you will want to implement VLANs to properly segment your traffic. This will require separate address ranges that you will need to plan for. APs will generate broadcast traffic but in my experience this does not detrimentally affect the network (especially if the management traffic is on it's own VLAN!)
I've been seeing a similar issue on someones network where LLC broadcast traffic is in the monumental amounts.
You mention it shouldn't be an issue since the management traffic is on it's own VLAN, but that would just mean the APs are affected by the large amount of traffic. In our case, we are seeing 121s having an excessive CPU load and it appears that traffic is causing it. Since this is the majority of the traffic we are seeing, it suggests that this is affecting them. Also, in the other linked article, somebody had specified they had issues like this and saw the same thing.
We have tried putting some APs on a separate VLAN to lessen the traffic affecting the APs but this has not mitigated the issues we are seeing.
Mike, what version of HiveOS are your APs currently running on and have they been upgraded recently?
I would guess the LLC broadcast traffic is at normal amounts expected from the AP's, and it is specifically amrp frames which are Aerohive's proprietary L2 routing protocol which is used for communication between AP's for a number of things. These can be broadcast, but also can be unicast frames. We cannot reduce or stop this traffic, it is necessary for our AP's to function properly.
The packet capture screenshot uploaded does not show much really....What volume of other traffic is on the network? Could this be a factor for the issues you are experiencing? Do you have much other Multicast / Broadcast traffic on the network? How big is the broadcast domain the AP's are in?
If you can share a full packet capture showing all traffic it would help us understand better.
Hi All thanks for the responses,
The traffic was causing a number of issues, predominantly with Video Conferencing however IMCP traffic was also blocked during the broadcasts from the Areo Hives.
Disconnecting the Areo Hive switch from the network immediately resolved any communication issues. To confirm the switch was not partly at fault an alternative switch was used for testing however the broadcast traffic persisted.
No switching loops were found anywhere in the network.
I re-designed part of the network to move the Video Conferencing away from the same subnet as the Aero Hive AP's and will be reducing the size of the management network to reduce the broadcast range.
What is the best practice recommended by AeroHive with regards to management VLANS?
I will look at running some additional packet captures this week and upload the results.
Glad you made some progress. We would always recommend segmenting traffic that is sensitive to latency and packet drops traffic like voice / video, so this is a good step.
With regards to management VLAN size best practice, this is not straight forward to answer and is why we don't have clear guidelines, a smaller subnet has advantages and in my opinion makes troubleshooting issues simpler, however this can depend on the size of the deployment. It might make sense to segment in to logical management subnets based on location, floor etc.