MR Series Access Point restarts

[RickA]

During the last several years we have found the need to restart our Meraki Access Points weekly. These restarts appear to clear the cached entries and allow a more optimal connectivity during the work week. We are attempting to review regularly that these planned restarts are occurring. However, we are unable to find any reporting or page which shows the last Access Point restart for each Meraki AP. Is this an available feature?

NOTE: The only way we have been able to find the restart is to create a case with Meraki, and allow Meraki Engineers to tell us the last restart for each AP.

[rwiesmann]

Check out this documentation about device uptime...it's a new feature.

https://documentation.meraki.com/General_Administration/Monitoring_and_Reporting/Device_Uptime

hope this helps

[RickA]

I believe "ww" responded similarly, but we do not have the "Device Boot" choice within our filters. Even if we try to type it in manually, it will not take since there is not choice available. It is possible this new feature has not yet been deployed to our Meraki Dashboard. I sincerely appreciate the replies from everyone and am continuing to research an answer.

[ww]

The event log should report , device boot and also the reason

Filter on event type : device boot

[RickA]

I'm finding no such event type as device boot in any of the choices available but that is a great thought.

[mlefebvre]

So your access points are being restarted weekly, but you don't know when it happens? Why isn't this simply automated, or given to the same person every week as a checklist/runbook item? Have you tried troubleshooting at all with support as to why you "need" these weekly restarts?

[RickA]

This is not an accurate statement, I didn't want to make this a novel so I didn't elaborate how the restarts occur. We have a regularly scheduled batch file which runs every Sunday early in the morning. However, we need to ensure the reboots occurred within the Meraki Dashboard as part of our compliance and auditing requirements.

[mlefebvre]

Ok, that makes much more sense, though I still seriously doubt the legitimacy of this reboot requirement. Two fairly simple options that involve slightly more downtime but should work even with your older APs:

1) If these sites can be down for ~30 minutes instead of the length of a reboot, I would simply use Port Schedules to disable the ports with access points for 30 minutes every night, which should then show up on the Device Connectivity bar if you want to double check it visually. This has the added benefit of being entirely done in the Meraki dashboard and not needing your batch script any longer.

https://documentation.meraki.com/MS/Access_Control/Port_Schedules

2) You could reduce this to ~5-10 minutes by having your script disable PoE on the switch ports, then 5 minutes later enable PoE on the switch ports, this would still bring it down long enough where it should show up on the connectivity bar.

[RickA]

Thank you for the ideas, I don’t believe a 30 minute down window is ideal but your second idea provides a much better approach (nice out of the box thinking). In the end I’ve found we don’t have the “Device Boot” Feature yet…imagine 3 months from rollout and the phased in approach hasn’t arrived in our Dashboard yet. Hopefully soon and thank you an all the respondents — I appreciate each of you immensely!

[alemabrahao]

You can create a script in PowerShell and insert it into the code so that a log file is generated whether the reboot was successful or not.

I had a script for this, but I no longer have it available.

[RickA]

Unfortunately, a script running only logs if the script ran and is not able to track the physical power cycle of the AP. I do already have a script which tells me if my batch file was successful, but CMMC compliance requires an audit trail such as a Meraki Dashboard report detailing date/time of an AP recycle. Great thought again, and I love the thinking here.

[RickA]

Doing some further research, it appears we have a mix of Meraki Access points running two different firmware versions. The latest APs are operating at version 30.6, whereas the older APs are operating at version 26.8.3. The new "Device Boot" feature is only available to APs with a firmware version 30 or higher. It is possible with the mixed environment this feature is not available in our Meraki Dashboard.

Next option ?

[BlakeRichardson]

I've not heard of this or had to frequently reboot MR units. Is this a common thing? I've seen this with Ruckus access points in the past but never with MR

[RickA]

Yes, in large deployments where many shop floor devices (iPhones, tablets, kiosks, handheld barcode scanners, equipment monitoring, etc.) are moving around from AP to AP they build up the cache table which begins making them get a little flaky after a while. I've been in shops all around the U.S. where they don't use as much Wi-Fi moving devices, primarily stationary so this does not pose as much of an issue. However, when you have management team members, supervisors, inventory control specialists, etc. moving all over the shop their devices change APs frequently and sometimes cause more cache table entries and thus the connectivity problems occur. However, we are way off topic for this thread...LOL.

[Brash]

Assuming your AP's are running off PoE from a switch, you could look at the switch logs (in case of Meraki - event logs) to see the last time that port transitioned state (Up->Down and Down->Up).

A syslog would make this job much easier to consume the data and filter the noise.