> For the complete documentation index, see [llms.txt](https://jncia-workbook.gitbook.io/workbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://jncia-workbook.gitbook.io/workbook/junos-basics/8-automatic-rollback-part-1.md).
# 8) Automatic Rollback (Part 1)
### Pre-Work
If you made any changes, you can quickly revert the lab using the **load\_config\_on\_nodes.py** script.
```
python3 load_config_on_nodes.py --lab_dir three-routers --config_filename basic.addressing.cfg
```
### Lab
Connect to R1, delete the fxp0.0 (mgmt interface) address, and change it to something bogus.
```
delete interfaces fxp0.0 family inet
set interfaces fxp0.0 family inet address 1.2.3.4/32
```
Committing this change will break your connectivity to R1. Commit in such a way that you ensure the configuration is automatically rolled back if you lose access to the router. You should not need to reset the lab in order to gain SSH access back to R1.
### Answer
Expand to reveal
We must use the `commit confirm` feature to automatically roll back changes.
```
admin@R1# commit confirmed 1
commit confirmed will be automatically rolled back in 1 minutes unless confirmed
commit complete
# commit confirmed will be rolled back in 1 minute
[edit]
Broadcast Message from root@R1
(no tty) at 15:26 UTC...
Commit was not confirmed; automatic rollback complete.
[edit]
admin@R1#
```
### Explanation
Expand to reveal
The automatic rollback feature is a great way to prevent locking yourself out of the device. If you are making a change which might cause you to lose access, you should use `commit confirm`. In fact, some engineers like to *always* use `commit confirm`, as it is good insurance. Sometimes you can unexpectedly lose access to the router. Just remember to confirm your commit afterwards. We will look confirming a commit in the next lab.
\
The `commit confirm` command takes a number from 1-65535. This is the number of minutes that will elapse before the system automatically issues a `rollback 1` and `commit`. There does not appear to be a way to rollback in seconds. Also, I believe 1 minute will actually start the timer at 1 min 59 seconds, so the minimum outage you will suffer could be up to 2 minutes. Personally, I prefer the IOS-XR method where you can set down to 30 seconds. This limits the impact of a bad commit.
\
Below, you can see that issuing a `commit confirmed 1` at 16:09:06 results in a rollback around 16:11:08, taking about 2 minutes.
```
admin@R1# run show system uptime | grep Current
Current time: 2026-07-10 16:09:06 UTC <-----------------------
[edit]
admin@R1# commit confirmed 1
commit confirmed will be automatically rolled back in 1 minutes unless confirmed
commit complete
# commit confirmed will be rolled back in 1 minute
[edit]
admin@R1# run show system uptime | grep Current
Current time: 2026-07-10 16:10:24 UTC <-----------------------
# commit confirmed will be rolled back in less than 1 minute <-----------------------
[edit]
Broadcast Message from root@R1
(no tty) at 16:10 UTC...
Commit was not confirmed; automatic rollback complete.
[edit]
admin@R1# run show system uptime | grep Current
Current time: 2026-07-10 16:11:08 UTC <-----------------------
[edit]
admin@R2#
```
### Further Reading