I think that safe mode need to be more like time based than session based
since some times you need to change remotely a config and that maybe will obvious close the session but not necessary it a mistake
so it better to setup a timer

Ubiquiti equipment allows you to ‘test’ a change.....
If you mess up, just Wait the 120 seconds!!
Phew!


Sent from my iPhone using Tapatalk

Yes,
让它,这样你就可以队列一群变化nd test deploy them for 120s or so.
+1

I hope mikrotik team need to think about this functionality

Enviado de meu XT1580 usando Tapatalk

Obvious requirement for a multitude of remote changes +1

been requested since 2017?

I don't understand this request. Safe mode already allows multiple changes. It will not do anything, unless your config causes disconnect. So commit your 10 changes and wait for 120 seconds before exiting safe mode. It's the same as you ask now, except that the time is shown on screen?

A slight difference between what's achievable now and what people ask for is that certain changes will cause disconnect which is expected. Example: change of bridge MAC address while administrator is using MAC-telnet or MAC-winbox to connect. Current implementation will revert the changes made in safe mode while administrator would want to keep the change if he is able to connect using new MAC address within 120 seconds.

I understand that there are workarounds to keep safe mode working and still making changes, but there are different cases each requiring different workaround and it's not simple to plan to use appropriate workaround in advance.

That is the point..
If you are remotely and make some changes, like move interface into a bridge or something similar, sometime you get disconnected and the safe mode is triggered..
Why just put a timer setting like

Set 5 min make some changes if you made a mistake and get locked in 5 safe mode is trigger and everything is back as before the changes.

I don't understand this request. Safe mode already allows multiple changes. It will not do anything, unless your config causes disconnect. So commit your 10 changes and wait for 120 seconds before exiting safe mode. It's the same as you ask now, except that the time is shown on screen?

Sent from my XT1580 using Tapatalk

Another good example
Why safe mode need to re think
Also
Safe mode sometimes troll you:
You are directly connected making simple changes.
When you go terminal to exit safe mode it tell y that was overwrite by another one and exit sometimes it revert sometime it keeps the changes..

A slight difference between what's achievable now and what people ask for is that certain changes will cause disconnect which is expected. Example: change of bridge MAC address while administrator is using MAC-telnet or MAC-winbox to connect. Current implementation will revert the changes made in safe mode while administrator would want to keep the change if he is able to connect using new MAC address within 120 seconds.

I understand that there are workarounds to keep safe mode working and still making changes, but there are different cases each requiring different workaround and it's not simple to plan to use appropriate workaround in advance.

Sent from my XT1580 using Tapatalk

If you lose connection, how do you expect safe mode to remain activated?

If you lose connection, how do you expect safe mode to remain activated?

Normis,

A simple flap on a interface (wan) cause safe mode to trigger...
So not always a brief loss of connection means that safe mode need to be triggered

Sent from my XT1580 using Tapatalk

If you lose connection, how do you expect safe mode to remain activated?

.
Maybe if after the user, which started safe mode, gets disconnected ... and subsequently connects again before timer expires, the session would actually resume with safe mode activated and all? Possibly the timer would reset to initial value again not to trigger safe mode due to too little time remaining for administrator to manually exit safe mode?

If you lose connection, how do you expect safe mode to remain activated?

.
Maybe if after the user, which started safe mode, gets disconnected ... and subsequently connects again before timer expires, the session would actually resume with safe mode activated and all? Possibly the timer would reset to initial value again not to trigger safe mode due to too little time remaining for administrator to manually exit safe mode?

good point
also since when safe mode have a timer ?

If you lose connection, how do you expect safe mode to remain activated?

Normis,
A simple flap on a interface (wan) cause safe mode to trigger...
So not always a brief loss of connection means that safe mode need to be triggered

YES, YES, YES "raffav" have a 100% right !
UBNT have a good solution with their 120 seconds delay.. why MT can't have it ?
MikroTik team - please introduce the same at RouterOS. Tahnks.

If you lose connection, how do you expect safe mode to remain activated?

Although I agree with you and plan my changes with a 'dual-stack' mentality to bring things into line - I do get the point the others are trying to make. Sometimes the changes you need to make affect your connectivity to the device, you want to make those changes but if the changes dont work you are locked out - perfect for safe mode. Problem being that you make those changes with safe mode on, your session disconnects as expected, then the config reverts to old so you either cant apply new config - or have to apply new config and hope that it works without a safeguard.

Being able to set a safe mode / commit timer means you can turn on- make the change - lose your connection - re-connect and confirm all-ok to stop the revert.

It could certainly be handy in some situations for remote devices.

also since when safe mode have a timer ?

It doesn't have it now. We're trying to convince Normis that it's a good idea to introduce one.

Anything happened here?
I am relatively new to Mikrotik, and are used to a system with Save and Activate as two independent choices. Combined with ping watchdog I was able to move a client from one AP to another, and be absolutely sure that if I did something wrong, or the client didn't connect with the new AP - it would come back to the old AP in a few minutes. Saved me many truckrolls. Surprised something similar is not implemented in RouterOS, with so many other great features for a WISP? Or am I missing something?

+1 MODE time based
Do not be instant undo!
Wait 180 second after the connection loss!!!

I can see the point. Sometimes when you perform a change, maybe a routing-change or vlan-change. The break of the TCP-connection is expected, however it's reachable via another IP, then a timeout-based rollback would be prefered.

我有时用预定的工作——我解决它f it didn't work, then reverse the changes after some minutes.

My aproach on normal routine
0) Connect with winbox
1) Enable Safe Mode
2) do what must be do
3)退出安全模式
4) Close winbox

My approach on unsafe change
0) Connect with winbox
1) paste on terminal the script for:
. . a) create backup "safe"
. . b) schedule a reload backup "safe" after 5 min
2) do what must be do
. . !] if something go wrong, and I lost the connection for more than 5 min, scheduler reload again backup on the hope the device go back online
3) remove scheduler
4) Close winbox

If you lose connection, how do you expect safe mode to remain activated?

We are asking for a way to 'resume' safe mode by reconnecting after loss of connection. A more simple example:

Say you are helping configure a remote CPE with new username and password in PPPoE, you are connecting via the WAN.

你登录——启用了安全模式,改变用户pass - you are EXPECTED to lose connectivity due to changing the WAN - but it would be nice if Safe Mode had a timeout where if you log back in to the device within X seconds/minutes, it will resume (as you've now used the new IP or specific details to log in) - where as with current setup as soon as you change user pass in the PPP you'd get kicked out and the system would revert back to old one. In this way - the ONLY way to change user/pass would be non-safe mode and 'hope' that it works, you never get a real chance to test that it comes up with the safety of the revert function after 1 or 2 minutes.

Why not have a timer that can be set on safe mode. If you lose your connection you have X seconds to re-establish the connection before safe mode reverts everything? This would cover instances if you have a remote router and need to change a configuration that will break the connection until a configuration is changed on a local router.

I will say the next best option I saw was to set up a scheduled restore from a backup file. Although, Safe Mode with some kind of timer for reconnection grace period would be nice.

Regards,

Stewart

I concur with the need for safe mode timer, this is almost a standard I see more and more with Ub and Netonix for example.

My case example is that I want to change an ospf router ID, In order to this this there is a slight delay in the change that will cause a disconnect before the change, so I cannot implement this without being on site. This is just the current reason, but in the past have had several where I need to make a change that I know will work, but safe mode reverts as it will cause a disconnect as it changes.

also since when safe mode have a timer ?

It doesn't have it now. We're trying to convince Normis that it's a good idea to introduce one.

Confusion: is this correct, and active : "safe mode timer" or just wishful thinking????https://tikdis.com/mikrotik-routeros/ha ... e-history/

It looks like wishful thinking. Time based Safe Mode is not there.

Connected to the LAN via wifi, and entered another AP with Winbox
Made a change to the bridge comment in Safe Mode. (Nothing dangerous)
Then switched to another wifi network, WinBox immediately lost connection on PC.

When I switched back and reconnected, the mod was still there, but disappeared after 10 sec !??
Did it again .... similar, first it was still there, then disappeared
Waited longer the 3rd time, was gone.

The RouterOS process needed time to detect the disconnect. When the logout happened (even after reconnecting), the "safe mode" mod disappeared.

The example of the need to change a WAN setting that causes the interface to flap is exactly on point.

How would I reconfigure the WAN setting (like new PPPoE credentials) while connecting through this WAN interface, unless I have time based safe mode? @normis


Ever vendor has some kind of "reload in ..." which works, because the configuration applied is not also immediately saved. But with RouterOS the configuration is always immediately saved, that is why safe mode needs a time based instead of connection based trigger, as opposed to other network OS where we can just "reload in".

@rextended has a workaround that is making a configuration backup and scheduling a restore script, but this is a lot of work for such as simple need that really everyone has and every other NOS vendor has figured out.

Here is @rextended workaround layed out with commands and all:

For device without flash remove the "flash/" prefix in the filename (inBOTHplaces):

step 1: make backup
step 2: plan script to restore backup in System/Scheduler (choose whatever time you need):

step 3: make changes

step 4: if the changes are good, remove the restore script from the scheduler, otherwise wait for the script to trigger a restore of the backup

Isn't it easier to put it in system scripts and run it before changes???

How do you know that the backup actually succeeded?
What if you pasted this in a box that has no flash/ for example or there is no free space?
Will you see, understand and stop your actions in time?
What if in the release on this particular box the script aborts when the winbox connection closes/disconnects interrupting your script during the :delay ?


I need as much reliability as I can get, because this is not going to be used in clean and up to date lab or greenfield but the actual network with all kinds of platforms and releases. Reliability is the main concern here, not ease of use.

Concur with the previous speaker!

Real real real answer:
if it comes from anav, route to blackhole. Just like his Cloudflare Zerotrust suggestion.
Done.

While a reconnect timer for safemode would absolutely be useful at times when you are working remotely and are about to make one or more changes that will knowingly reset the connection,

Another (and possible very easy to implement) also needed option is to have a setting in winbox (and enabled by default) be to login and automatically activate safemode at login. There's no reason Winbox and webfig should not default themselves to activating safemode automatically when you connect into a device (give the option to disable this in winbox).

Answer: you can enable Safemode anytime manually. ;P

Just to recap how other vendors handle this. This discusses Cisco IOS and vyatta/EdgeOS.

Both of these are similar in effect to what was proposed by rextended in "unsafe change" inpost #22(although his method requires more work than in most other networking os's that have a feature built in).

I think it would be nice to have a ROS provided standard mechanism (even a script) that standardized how this is done. Perhaps allowing an optional time till reboot to be specified

Cisco IOS (this is old knowledge, there may be different ways now)
Cisco maintains two "configurations", a running-configuration (what is in RAM and being used) and a startup-configuration (what will be used to reload the running-configuration on startup/boot)
When changes are made in IOS, they only affect the running-configuration, you must do a copy running-configuration startup-configuration to make the changes permanent.
To do something that you are afraid may lock you out, you first schedule a restart, then you make the change, if you are still connected, or can reconnect (in case an ip address was changed), then after reconnecting, you then cancel the scheduled restart, then wr mem (or copy run start) to make the change persistent.

The cisco implementation will warn you that a scheduled restart will happen (periodically), I think the last one is 1 minute prior to reboot.

vyatta/EdgeOS (possibly in Junos, which heavily influenced vyatta)

In vyatta, there are 3 configuration sets, active (similar to Running in Cisco), boot/startup and working (which is where a set of changes can be staged before they are "commited" to the active/running configuration. so the change process is: enter config mode, (this implicitly copies active to working), make changes, then commit the changes (verifies changes are valid, then copies working to active). then save (which copies active to startup/flash). In addition to commit, there is a commandcommit-confirm, which essentially starts a scheduled reboot (it is called a rollback but other than doing some extra paperwork, it is essentially a reboot, and that will use the last saved config.boot file). So the procedure in vyatta to do an unsafe change is first to make sure that the active and boot configs are the same (enter config mode, then use the save command), then make changes, then use commit-confirm (default 10 minutes until reboot unless cancelled with the "confirm“命令,但您可以指定若干分钟other than 5. It has been reported that the number of minutes is truncated, it is really wait until this many minute crossing have occurred, so using commit-confirm 1 can restart 5 seconds or less after the command was entered, depending on how many seconds are left in the current minute; I consider that a bug in implementation). If you can still access the router, then issue "confirm" which confirms that change didn't break things, and cancels rollback, and finally asave. Note: at least on EdgeOS you don't get any warnings that the system will reboot, and if you forget to enter "confirm", your only indication is that the router will reboot unexpectedly, and you will be back to the last saved config. I can't remember for sure, but I think I tested this where I did do a save after the commit-confirm, but did not use the confirm command, and when it rebooted it did use the "last saved" config, so in that case it still had the changes. In other words, it isn't a rollback to the state just prior to the commit-confirm. Note two: EdgeOS has a webGUI as well, and it does not give you any method of safe changes, the when you give it the "ok" it does a commit and save. And that change can lock you out. It is also the reason any time I make remote changes, I never use the webGUI, and use the command line interface instead.

Another approach for devices that have at least 2 partition:

1) Copy current working config on backup/inactive partition.

2) Set the backup/inactive partition as boot.

3) Schedule a reboot after, for example 5 minutes.

4) Make changes, if something go wrong or kernel reboot for watchdog, or after a power failure, RouerBOARD reboots with the last valid config copied on backup.

5) When the changes are done, remove scheduler and set current active partition as boot partition.

Another approach for devices that have at least 2 partition:
...
5) When the changes are done, remove scheduler and set current active partition as boot partition.

That's a good way if you have a device with enough flash for partitioning. It essentially is a manual analogue of running/startup in Cisco. (But it requires manually copying the config to backup, as it seems that MikroTik will change the startup config when the running config is changed).

Using the backup method will work on a much larger set of devices (that do not support partitions due to tiny flash capacity, like the hEX S with 16MB)

If MikroTik at least supported "show | compare" and "commit confirm xxx" like Juniper, it would be great.

WB!

Can you expound on how Juniper does it.
My biggest beef is that whenever the router burps and returns safe mode is off vice how one left it, ON....

Safe mode on MikroTik is not reliable, sometimes it rollbacks too far back, sometimes not far enough, sometimes it doesn't work.

https://www.juniper.net/documentation/u ... nfirmation

If MikroTik at least supported "show | compare" and "commit confirm xxx" like Juniper, it would be great.

yes that will be great in MikroTik