Stop LCC Traffic from AeroHives

  • 1
  • Question
  • Updated 1 year ago

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.

https://community.aerohive.com/aerohive/topics/lots_of_broadcast_llc_traffic_coming_from_access_poin...

Photo of Mike

Mike

  • 3 Posts
  • 0 Reply Likes

Posted 1 year ago

  • 1
Photo of Luke Harris

Luke Harris

  • 265 Posts
  • 18 Reply Likes
Is this actually causing a problem on your network? - also are you APs located on a separate management VLAN? 
Photo of Mike

Mike

  • 3 Posts
  • 0 Reply Likes

Hi Luke,


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.

Photo of Luke Harris

Luke Harris

  • 265 Posts
  • 18 Reply Likes
Hey Mike,

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!) 
Photo of nath700 .

nath700 .

  • 1 Post
  • 0 Reply Likes
Hi there,

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?

Kind regards

Nathan W
Photo of Luke Harris

Luke Harris

  • 265 Posts
  • 18 Reply Likes
Nath,

When you have checked these APs with a high CPU, what does the 'show system processes state' output look like for you to conclude that the broadcast traffic is causing the problem and not another service.

I would also like to see more of the Wireshark output, if you are seeing a DoS-like symptom, have you checked for a broadcast storm in the network, typically caused by a switching loop?

Bonjour gateway services along with dynamic airtime scheduling other configuration factors that cause high CPU load.
(Edited)
Photo of Chris B

Chris B, Official Rep

  • 93 Posts
  • 10 Reply Likes
Hi Mike / Nath, jumping in on this one......

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.

Cheers

Chris
Photo of Mike

Mike

  • 3 Posts
  • 0 Reply Likes

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.

Photo of Chris B

Chris B, Official Rep

  • 93 Posts
  • 10 Reply Likes
Hi Mike

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.

Chris