MR33 - Failed connections

superfly
Getting noticed

MR33 - Failed connections

Had an interesting issue today. Some windows 10 clients were unable to get an IP address. Didn't matter whether it was a corp or guest SSID. First I blamed Windows 10 but I tried going to a different building and in that building the client worked fine on both SSID's. Back at my desk it would fail and colleagues around me also had the same issues. The windows 7 device on my desk would work fine.

 

I looked in wireless health, failed connections and noticed that all the failed connections were on 1 particular AP. So I rebooted it and then all was ok again.

 

We've only been using these MR33's for a few weeks. Has anyone experienced something like this before?

12 Replies 12
BlakeRichardson
Kind of a big deal
Kind of a big deal

@superfly  Yes thats technology for you, I have seen this exact same issue with multiple vendors, no idea what causes it and it usually only affects new connections, existing connections seem to be OK. 

 

I find this usually happens once in a blue moon but if you are seeing the same access point have the same issue more often I would open a support case. 

If you found this post helpful, please give it Kudos. If my answer solves your problem, please click Accept as Solution so others can benefit from it.
NolanHerring
Kind of a big deal

I've ran into similar instances, reboot always fixes it. I've attempted to go out of my way to collect packet captures and open support cases but they never actually determine the root cause and end up suggesting I upgrade firmware to a beta build which kind of kills me inside. So I reboot my access points on a scheduled basis to keep them running fresh.
Nolan Herring | nolanwifi.com
TwitterLinkedIn
MerakiDave
Meraki Employee
Meraki Employee

I've seen this before also and don't have or know of a root cause yet.  True that it seems to be random and not that frequent, and that a reboot seems to fix it, but nonetheless I'd suggest opening a Support ticket if/when you catch this issue in progress.  If nothing else it'll allow Support to do a little data collection prior to any AP reboot (if you can afford the extra few minutes) since that can only help them get closer to a root cause, and/or identify a specific hardware/firmware combination where this occasionally happens.

 

Lagcat
Getting noticed

@NolanHerring how are you rebooting on a schedule? if this just a manual operation or you have a automatic way of doing this?

 

I was wondering if scheduling the ssid availability to go off for 30mins in early morning would have close the same effect

it would not reboot the AP but it would clear all associations which is what I was wondering if I could get away with

 

Cheers

 

BrechtSchamp
Kind of a big deal
NolanHerring
Kind of a big deal

I use a python script we wrote, with stackstorm, and it runs it once a week and using the Meraki API to reboot devices. It pulls entire inventory, and reboots only MR device types.

Nolan Herring | nolanwifi.com
TwitterLinkedIn
Lagcat
Getting noticed

is it possible for you to share it with me or a cut down example

when it comes to scripts and APIs its not something I do so its learning curve to get correct

BrechtSchamp
Kind of a big deal
Lagcat
Getting noticed

just to carry on this

 

I have a nice restart script now so all I have to do is tag my AP's with 'nightly-reboot' and they start rebooting with a 40sec delay between each

 

but my next question is in the event logs there is no confirmation or reboot acknowledgement 

 

not just for the script but if I do a manual reboot there also does not show in the logs which is a bit of a pain

 

as a Helpdesk informed me they have been rebooting an AP constantly throughout the day but not telling me and there does not seem to be any logs to confirm this

 

is there a way I could capture it as an event?

 

Cheers

redsector
Head in the Cloud

Isn´t it easier to use the scheduling of the switch port. Halve an hour a day scheduling as off, and after the time is run then the accesspoint reboots. It an easy way without any scripts.

You find it on "switch" - "port schedules".

 

jdsilva
Kind of a big deal


@superfly wrote:

 

I looked in wireless health, failed connections and noticed that all the failed connections were on 1 particular AP. So I rebooted it and then all was ok again.

 


This has become almost always the first place I go when I start troubleshooting "The WiFi sucks" issues. It's made my life easy numerous times now. Great tool. 

MerakiDave
Meraki Employee
Meraki Employee

Agree @jdsilva, Wireless Health is a fantastic assurance tool, and a great example of Meraki deploying a powerful new feature that was driven by customer wishes, didn't cost anything, didn't require any licensing, and typically didn't even require any firmware updates or AP reboots.  And it's even got a full API behind it for automation, alerting and other cool stuff.  I've heard this from so many customers, that Wireless Health is the first place they go now when there's an issue.

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels