Ways to undo a configuration

[The_Roo]

I have worked with Cisco catalyst since they first appeared, but I've only been working with Meraki for a while. One of the "Get out of gaol free" tricks Catalysts have is that if you are going to make a configuration change remotely, one that might cause you to lose your connection to a remote box, you can use the CLI command "reload in xx" where xx is the number of minutes/seconds till the box will reboot and revert to the initial (before you started messing with it) configuration.

Meraki is very different...no CLI and no "write mem" to make temporary changes permanant, but still the same ability to cut yourself off from a box when working remotely. I'm thinking about things like changing the "allowed" VLANs on an uplink trunk and omitting the management VLAN...if the management VLAN is not permitted on the uplink the box can't phone home, and you will lose connection to the device because the device loses connection to the Meraki cloud?

So here's the question: is there a command or capability within the Meraki hardware/dashboard which would allow me to have the box I'm working on go back to the configuration it was when I started messing with it? Then, if I don't cut myself off from the box, I could cancel the reload, and carry on with the new config, but if I lost the connection, all I have to do is wait till the box reloads and I'm back were I was before I started fiddling

[Ryan_Miles · Accepted solution]

While there's not a "reload in" command in Meraki world (and I too used that plenty pre cloud managed days) when I was a Network Engineer Meraki devices have a number of routines built in to help avoid loss of connectivity.

Much of this is covered in this doc https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Behavior_during_Conne...

But to highlight a few of them one is that if the mgmt IP of a device is using DHCP even if you were to change the mgmt VLAN the device would pull a new IP from its new subnet and still be reachable by dashboard. Additionally, if a device has a static mgmt IP and that stops functioning the device will attempt to obtain a DHCP IP from reachable VLANs and if successful would be reachable by dashboard.

There's also the idea of "safe config" which is covered in the doc linked above. But in short means if a device becomes unreachable and based on a few conditions mentioned in the doc it would revert to its prior known good config.

Both of these functions go a long way to addressing the possibility of cutting a device off from reachability. 

I'm sure other Meraki users here on the Community can provide their insights and experiences on the topic.

[DarrenOC]

Yep. I can vouch for the workability of devices switching to reachable VLANs and reregistering to the cloud following a clumsy change made remotely.  

I wasn’t aware that devices could change back to a previously known working config, that’s one I’ve not seen happen in the field.