Commit-Confirm: Your Safety Net Against Self-Lockout

November 21, 2025 · 6 min read

You SSH into a remote router. Change firewall rules. Commit. Connection drops. You just locked yourself out. The router is 500 km away. Your Friday evening plans are cancelled.

commit-confirm exists precisely for this scenario. It commits changes temporarily. If you don’t confirm within a timeout, changes roll back automatically. The router saves itself from your mistakes.

Every remote change should use commit-confirm. No exceptions.

How Commit-Confirm Works

1. You run: commit-confirm 5
2. Changes are applied
3. Timer starts (5 minutes)
4. If you run 'confirm' before timeout → changes persist
5. If timeout expires → automatic rollback to previous config

The key insight: if your change breaks connectivity, you can’t confirm. So the router reverts itself.

Basic Usage

Standard Commit-Confirm

# Enter configuration mode
configure

# Make your changes
set firewall ipv4 name WAN-IN rule 100 action drop
set firewall ipv4 name WAN-IN rule 100 source address 10.0.0.0/8

# Commit with 5-minute timeout
commit-confirm 5

# Test connectivity, verify everything works
# Then confirm:
confirm

# Or if something is wrong, just wait - it will rollback

Different Timeout Values

# Quick change, confident it works (minimum 1 minute)
commit-confirm 1

# Complex change, need time to verify
commit-confirm 10

# Major change, need extensive testing
commit-confirm 30

Choose timeout based on how long you need to verify the change works.

Check Remaining Time

# See if there's a pending confirm
show system commit

# Output shows:
# Commit confirmed in X minutes

Real-World Scenarios

Scenario 1: Firewall Rule Change

configure

# Adding rule to allow new service
set firewall ipv4 name WAN-IN rule 50 action accept
set firewall ipv4 name WAN-IN rule 50 destination port 8443
set firewall ipv4 name WAN-IN rule 50 protocol tcp

# Use confirm because this touches firewall
commit-confirm 3

# Test from external client
# curl https://server:8443 - works!

# Confirm the change
confirm

Scenario 2: Interface Address Change

configure

# Changing management IP - very risky remotely
set interfaces ethernet eth0 address 192.168.1.100/24
delete interfaces ethernet eth0 address 192.168.1.50/24

# Critical: use confirm with enough time to reconnect
commit-confirm 5

# Immediately try to SSH to new IP
# ssh admin@192.168.1.100

# If you can connect:
confirm

# If you can't connect - wait 5 minutes, router reverts

Scenario 3: Routing Change

configure

# Changing default gateway
delete protocols static route 0.0.0.0/0
set protocols static route 0.0.0.0/0 next-hop 10.0.0.1

commit-confirm 3

# Verify connectivity
ping 8.8.8.8
traceroute 8.8.8.8

# Looks good
confirm

What Happens on Rollback

When timeout expires without confirmation:

# 1. Current session is terminated
# 2. Config reverts to pre-commit state
# 3. All services reload with old config
# 4. Log entry created

# Check what happened
show log | grep -i rollback
show log | grep -i commit

# View current config (should be pre-change)
show configuration

Commit-Confirm vs Regular Commit

Aspect	`commit`	`commit-confirm`
Immediate	Yes	Yes
Persistent	Yes	Only after confirm
Rollback	Manual	Automatic on timeout
Remote safety	None	High
Use case	Local changes	Remote changes

Best Practices

1. Always Use for Remote Sessions

# Script wrapper for remote changes
#!/bin/bash
TIMEOUT=${1:-5}  # Default 5 minutes

source /opt/vyatta/etc/functions/script-template
configure
# ... your changes ...
commit-confirm $TIMEOUT

echo "Changes applied. Confirm with 'confirm' within $TIMEOUT minutes"
echo "Or changes will automatically rollback"

2. Test Connectivity Immediately

commit-confirm 3

# Immediately verify you can still reach the router
# From another terminal:
ping router-ip
ssh admin@router-ip

# Only then confirm
confirm

3. Have Console Access Ready

For major changes, have out-of-band access ready:

IPMI/iLO console
Serial console
Local access

If commit-confirm somehow doesn’t save you, console access will.

4. Document the Rollback Happened

# After a rollback, document it
show log | grep -i rollback

# Add comment explaining what was attempted
configure
comment firewall ipv4 name WAN-IN "Note: rule 100 attempt on 2025-01-08 caused lockout, rolled back"
commit

Edge Cases

Confirm from Different Session

# Session 1: commit-confirm 5
# Session 1: loses connectivity

# Session 2: SSH into router (if possible via different path)
confirm  # This confirms Session 1's changes

# Useful when you have multiple network paths

Immediate Rollback

# Changed your mind before timeout?
configure
rollback 0  # Rollback to last saved config
commit

# Or simply exit without confirming
exit discard
# Wait for timeout

Power Failure During Confirm Window

If router reboots during commit-confirm window:

Uncommitted changes are lost
Router boots with last saved (pre-commit-confirm) config
This is the safe behavior

Automating Confirm

For automated deployments, you need programmatic confirm:

# Ansible approach
- name: Apply VyOS config with confirm
  vyos.vyos.vyos_config:
    lines:
      - set firewall ipv4 name TEST rule 10 action accept
    save: no

- name: Verify connectivity
  wait_for:
    host: "{{ inventory_hostname }}"
    port: 22
    timeout: 60

- name: Confirm changes
  vyos.vyos.vyos_command:
    commands:
      - confirm

# If verify fails, Ansible doesn't reach confirm
# Timeout expires, config rolls back

API-Based Confirm

# Using VyOS API
curl -X POST https://router/configure \
  -H "Content-Type: application/json" \
  -d '{
    "op": "set",
    "path": ["firewall", "ipv4", "name", "TEST"],
    "value": "..."
  }'

# Apply with timeout
curl -X POST https://router/config-file \
  -d '{"op": "commit-confirm", "minutes": 5}'

# Verify connectivity, then:
curl -X POST https://router/config-file \
  -d '{"op": "confirm"}'

Common Mistakes

Mistake 1: Timeout Too Short

# Bad: 1 minute for complex change
commit-confirm 1
# You're still verifying when it rolls back

# Better: Give yourself time
commit-confirm 10

Mistake 2: Forgetting to Confirm

commit-confirm 5
# Test, looks good
# Get distracted
# 5 minutes pass
# Changes gone!

# Tip: Set a timer on your phone

Mistake 3: Not Using It At All

# The classic mistake
configure
set firewall ...  # Typo somewhere
commit  # No safety net
# Locked out

The Lesson

Every remote change should use commit-confirm. No exceptions.

The cost of using commit-confirm:

Few seconds to type the command
Remember to confirm

The cost of not using it:

Emergency drive to datacenter
Out-of-band console access scramble
Ruined weekend

The router can save itself from your mistakes. Let it.

I’ve been saved by commit-confirm more times than I care to admit. Every time I think “this change is simple, I don’t need confirm” — that’s exactly when I need it most.

Use it. Always.