Since Safe Mode is known to be woefully unreliable at detecting the device is no longer being accessed - especially with anything involving Layer2 connectivity changes - can I please suggest MikroTik implement an alternate method that is far more reliable. As well as allowing the user to momentarily lose connectivity, but without losing the option to continue configuring the device if they can log back in within time
In the Files menu, add another button “Safe Recovery” and when clicking on this it would let you enter a time in hours/minutes/seconds. Upon pressing OK it would
- Take a hidden backup file that cannot be seen/deleted/modified by any user
- Device starts logging all the changes that are made
- Show a countdown in the Winbox window title with the remaining time - ideally also change the window color or some other display that makes it blatantly obvious
- Timer is internal, and does not rely on the date/clock
- If timer reaches zero, exports all of the commands that have been entered to “SafeRecovery.rsc”, then loads/deletes the hidden backup file and reboots
- If user clicks on the button again before the timer reaches zero, discard all the above
I do a manual method by taking a backup and creating a schedule, but this is convoluted by having to manually create the file and enter an exact timestamp in the scheduler. It’s prone to errors if entering the time or the filename wrong - especially when doing work over midnight and forgetting the adjust the date forward. And its not so obvious to delete the schedule, especially when tired at 3:30am. Hence it may reload the backup file again in 24 hours. Ultimately its just more work
It would be great to have an ‘ultimate undo’ option that’s clean and nicely integrated
I must say I do miss the cisco “Reboot in X” option.
So if you you know you are about to do something sketchy and you do get locked out you know it will reboot back to the last saved config.
Safe mode is no good if you are Accessing the router from a remote RDP Session and you do something to break the internet at that location; as the router is still connected from the remote RDP and will therefore never roll back but you can no longer access the RDP session to correct it. Obviously trying to avoid getting into these situations is the best solution though.
Safe mode is just inherently so unreliable. I’d say I have a 80% success rate with it, but that other 20% it just does not recognize loss of connection at all. It seems especially so when i’m changing anything to do with L2 connectivity, such as VLAN’s, DHCP snooping, port isolation etc. And when it does fail it almost certainly going to be a device that is up a radio tower, on a particularly difficult rooftop etc
It’s also easy to accidently forget that you had it enabled on a RDP machine. I can recall once that approx 6 months went past, I completely forgot that the RDP session was running on a backup RDP machine and it was in safe mode the entire time, that RDP server rebooted and bam the entire thing rolled back to an out of date state (major management IP address changes were implemented over that time)
There’s also been plenty of instances with multiple moving parts, you can’t just make 1 change on the device, it goes hand in hand with several others and so safe-mode just cannot be used because you WILL lose connectivity… temporarily… hopefully temporarily… but having something on a countdown which is likely to be used in ~10 minute intervals, would be such a massive improvement and safety net. Safe mode still has its uses as it doesn’t need the device to reboot, so when it does work the downtime is usually a few seconds. However its just not suitable for large changes with multiple parts and its far too easy to screw up the scheduler method by accident
Why not a simple solution - do not persist config unless explicitly saved?
Cisco has got startup and running configs. Startup config is stored by explicit command to copy whole running config to startup config.
If admin manages to lock himself/herself out, just restart the device and start from the last working config. It’s easier to redo config, because of forgotten save, than to climb the ladder to unmount wAP and manually reset it via physical access.
If you lock yourself out you may not be able to get to the device to restart it. Almost everything I configure is remote
Problem with separate running/saved Configs is when forgetting to save them, same situation as above. 6 months might go by and the device reboots and loses its config