In recent years, we have started seeing more issues with code updates to the MX product line impacting performance to the point where in some scenarios we have to force the client to upgrade their MX to the next largest SKU.  Somewhere in that statement, there is a position someone could justify making, that if this is the case the MX was too small for their environment in the first place.  As I engage with our local meraki reps to try and get eyes on this. I am also trying to get input from other engineers that have to support this hardware.  Have you ever been in a situation where you needed local logs to prove a firmware bug or hardware failure, but the only way for you to effectively retrieve those logs is to keep your client's environment down for longer to get the needed logs?  I am wondering, is there any way that the Meraki platform could be changed to have a way to write critical local logs to persistent storage? Cisco Phones and many other classic Cisco devices have had ways to do this, creating a short window of time where logs can be retrieved after a device crashes or fails. That information, can then be used to effectively understand what happened and decide next steps.  Since Meraki support requires these local logs to diagnose many issues, I think the best lasting fix for all parties that have to support this equipment, would be to create a way for critical local logs to survive a reboot.  This request is born from situations where the local status page has become un-accessible or unreachable even locally on MX hardware after it begins having an issue that takes an environment offline. That then requires the equipment to be rebooted to bring it back online, which usually does fix the issue, but then no one is able to figure out what happened or why, which means the bug team cannot address a possible issue, and an RMA for hardware that is actually defective cannot be started. Putting us in a situation where a client may have to sustain 2 or 3 outages (or more), that are then extended so a technician on-site can spend time trying to retrieve the local logs.  I understand there are ways to access the local status page remotely from the LAN or with a jumpbox, but again, we are seeing an uptick in the local status pages just flat out not functioning or not being accessible with recent releases of code.  A way for the hardware to write critical errors like these to persistent storage would improve this product line drastically.  ... View more

Is Meraki going to make a way for Persistent log storage for local device logs? It seems recently we have seen an uptick in brand new MS130 and MS250 hardware having odd issues on MS 16.8 and MS 16.9 where the device seems to start dropping/filtering DHCP and DNS traffic.  When we have seen this behavior, a reboot fixes it, but clears the local logs.  This leads to a situation where I have to explain to a new client, that even though they purchased Cisco hardware, we cannot help them resolve the issues until it happens again, and then on top of this, we have to extend the downtime until we can get someone directly wired into the switch with a laptop.  In 2 of these recent scenarios in separate environments, the local status page would not even function until the hardware was rebooted.  If Cisco Meraki requires the local status logs to troubleshoot and diagnose issues, why was the Meraki platform released without a way to write critical local logs to persistent storage? Cisco phones have done it for years with a very small amount of onboard storage, and a rotating local log file.  There may be limitations that I am not aware of that prevent this. I am still going to inquire about it. If Meraki thinks its okay to take my client environments offline so they can troubleshoot, than I should be justified in asking why a permanent solution to this issue has not been implemented.  ... View more