Access Points Dropping Suddenly

  • 2
  • Question
  • Updated 2 years ago
  • Answered
We have recently been experiencing issues with our AP's constantly dropping and coming back up. This has been happening constantly today alone, there is no obvious connection issues with our wiring. We have our AP's fairly spread since we have a grand total of 60 AP's we are a fairly large area and we have around 30 users who heavily rely on the Wi-Fi. 
Photo of Alex Ornelas

Alex Ornelas

  • 8 Posts
  • 0 Reply Likes

Posted 2 years ago

  • 2
Photo of Michael Brado

Michael Brado, Official Rep

  • 2114 Posts
  • 297 Reply Likes
Examining the syslog from an affected AP's support info might provide a clue...

What version firmware running on your ZD, and what model AP(s)?

Do you have big flat subnet VLANs with lots of multicast/broadcast traffic?
Photo of Alex Ornelas

Alex Ornelas

  • 8 Posts
  • 0 Reply Likes
Version9.10.0.0 build 218 and we are using mainly zf7762 outdoor ap's with a few t300's. 

To be honest I am not quite too sure how to answer that last question
Photo of Todd

Todd

  • 57 Posts
  • 13 Reply Likes
Alex,

Not sure if this is your issue, but I had a similar issue months ago and we suspected a wireless AP / controller issue.  It turned out that wasn't the problem.  It was an issue originating on the wire.

We had a single Lenovo PC with an i216/i217/i218 (not sure of the exact model) Intel NIC that was causing 100% of the issues. Here's a link to the problem:  https://communities.intel.com/thread/48051  But in short the Lenovo PC NIC / NIC drivers were sending IPv6 multicast traffic to ever port on the network.  This only happened when the PC entered a sleep state, so it wasn't consistent.  We would be fine for an hour or two and then we'd be down for 30 minutes to 4 hours.

The wireless symptom was that wireless clients would drop and an occasionally the AP's would drop and come back up.  The reason for that was that the AP's (7982's) were so busy processing multicast traffic that it couldn't service the wireless clients and if it was bad enough it didn't have time to make the heartbeat timeout with the controller so they used their controller based settings that are pushed to them, to reboot after 30 minutes of no connectivity with the controller.

Once we found the device mac using wireshark, we were able to narrow down the port the PC was plugged into and removed it from the network.  Problem solved.

Good luck with your issues.
(Edited)
Photo of Alex Ornelas

Alex Ornelas

  • 8 Posts
  • 0 Reply Likes
You know that sounds like a strong possibility, we do have some laptops connected directly to access points because we need these running 24/7 as they monitor our greenhouses. i will look into using wireshark. i appreciate the response Todd
Photo of Todd

Todd

  • 57 Posts
  • 13 Reply Likes
To be clear, this was a PC that was 3 switch hops away from AP's that were being affected.  The multicast traffic was affecting every switch port in our network but only the AP's were affected due to CPU limitations.  So I wouldn't immediately suspect the laptops connected to the AP's as the culprit.
Photo of Alex Ornelas

Alex Ornelas

  • 8 Posts
  • 0 Reply Likes
Right, at least this has given me some insight into a possibility. I will still do research into what other culprits there could be. Troubleshoot, troubleshoot, troubleshoot.
Photo of Michael Brado

Michael Brado, Official Rep

  • 2107 Posts
  • 297 Reply Likes
You may be on the right track Todd, good advice above, and was what my flat subnet ques was asking for.



We have seen certain NICs that sent ICMPv6-Multicast-Listener-Report broadcasts, which can

affect AP/ZD connectivity. 

https://support.ruckuswireless.com/answers/000003275 



I'll be inputting more information, capture screen shots, and make the title better.

We usually recommend not locating your ZD/APs on the same VLAN/subnet as servers

due to this sometimes seen issue.  Please update server/workstation NIC drivers if possible 
Photo of Alex Ornelas

Alex Ornelas

  • 8 Posts
  • 0 Reply Likes
Okay guys, so after that day it seems as though things have calmed down. The issue seems to be going on early morning and stabilizes around 8 a.m. At least now I have somewhat of a specific time period to investigate. Anything further I will update here. I appreciate everything Todd and Michael.