TTR Networks

Intermediate · Operating VyOS: monitoring, backups and automation · section 5 of 8

commit-confirm

✓ Lab-tested 18 October 2026 on VyOS 2026.10.16-0024-rolling, Debian 12 (rsyslog, nfcapd)

The worst kind of change is the one that cuts off your own access: a firewall rule or route that drops your SSH session halfway through. On a router in another building, that's a long drive.

commit-confirm is the safety net. Instead of commit, use commit-confirm 10: the change is applied, but unless you type confirm within 10 minutes, VyOS reverts to the previous configuration by itself. If the change locked you out, you just wait.

How it reverts is set by config-management commit-confirm action: reload reloads the previous configuration (as here), and the older default, reboot, reboots the router into its saved configuration. reload needs commit revisions enabled, so it has something to go back to.

In the lab: a "bad" change (a description, OOPS-UNTESTED-CHANGE) was committed with a one-minute window, and deliberately not confirmed. The commit was even archived to the ops server. About a minute later, R1 reloaded its previous configuration on its own: the description went back to MGMT-NETWORK, the unconfirmed commit disappeared from show system commit, and the commit-confirm timer appeared in the central syslog.

Make commit-confirm a habit for every remote change, and confirm only once you've checked you can still reach the router.

A change that isn't confirmed (real output)
configure
WARNING: You are currently configuring a live-ISO environment, changes will not persist until installed
[edit]
vyos@R1# set interfaces ethernet eth0 description 'OOPS-UNTESTED-CHANGE'
[edit]
vyos@R1# commit-confirm 1

commit-confirm will automatically reload previous config in 1 minutes
unless changes are confirmed.
Proceed ? [Y/n] y
Initialized commit-confirm; 1 minutes to confirm before reload
Archiving config...
  OPS: scp://198.51.100.10/home/cfgbackup/r1 OK
[edit]
vyos@R1# exit
Warning: configuration changes have not been saved.
exit
[... about a minute later, without confirming ...]
vyos@R1:~$ show interfaces ethernet eth0 brief
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface        IP Address                        S/L  Description
---------        ----------                        ---  -----------
eth0             198.51.100.1/24                   u/u  MGMT-NETWORK
vyos@R1:~$ show system commit | head -4
0  2026-10-17 15:16:54  by vyos  via cli
1  2026-10-17 15:16:29  by vyos  via cli
2  2026-10-17 15:05:28  by vyos  via cli
3  2026-10-17 14:57:46  by vyos  via cli
root@ops:~# grep -i confirm /var/log/r1.log
2026-10-17T15:18:51+00:00 R1 systemd[1]: commit-confirm.service: Deactivated successfully.
2026-10-17T15:18:51+00:00 R1 systemd[1]: commit-confirm.service: Consumed 11.207s CPU time.
2026-10-17T15:18:51+00:00 R1 systemd[1]: commit-confirm.timer: Deactivated successfully.
  • Line 4: The risky change.
  • Lines 6–11: Commit with a one-minute window.
  • Lines 12–13: Archived as usual.
  • Line 23: A minute later: the previous description is back.
  • Line 25: The unconfirmed commit is gone from the history.
  • Lines 30–32: The timer firing, in the central log.

Check your understanding

You're changing a firewall on a router 300 km away. Which command do you commit with?

  • commit-confirm, then confirm once you've checked you can still reach it
  • commit, then save immediately
  • save, then commit
  • commit-archive