IOS-XR reload in 10

← Batch rename file suffix | posts | Git checkout tags →

Network engineers not working on site where use the "reload in" command on IOS routers and switches to prevent accidental lockout. If configuring critical commands that would lead to losing connection to the control plane of the router, the reload in feature is the favoured command to prevent accidental lock out. In the worst case this reload the router and cause an outage, but after the network converged the configuration is as it has been before and nothing changed. It's cheap, but it works.

This is for example the case if configuring AAA commands. for RADIUS, TACACS+ or LDAP authentication and authorisation, or if configuring the interface via the vty session is currently running. This applies to switches to if configuring the trunk link and the switch is on the stick, much like a router on the stick.

In the IOS and IOS-XR operating system the reload command looks like in example depicted. Note its usage in the privileged EXEC mode which is (#), and the not saving the configuration before a reload:

R1# 
R1#reload in 10 reason I_took_an_arrow_in_the_knee
System configuration has been modified. Save? [yes/no]: no
Reload scheduled in 10 minutes by console
Reload reason: I_took_an_arrow_in_the_knee
Proceed with reload? [confirm]
R1#
*May 25 11:53:44.963: %SYS-5-SCHEDULED_RELOAD: Reload requested for 12:03:40 UTC Mon May 25 2020 at 11:53:40 UTC Mon May 25 2020 by console. Reload Reason: I_took_an_arrow_in_the_knee.

Verfication of the reload command:

R1#show reload
Reload scheduled in 9 minutes by console
Reload reason: I_took_an_arrow_in_the_knee
R1#

... 3 minutes have passed 

R1#show reload
Reload scheduled in 6 minutes by console
Reload reason: I_took_an_arrow_in_the_knee
R1#

Aborting the reload using IOS-XE and IOS-XE, after the work is successfully finished.

R1#
R1#reload cancel
R1#

***
*** --- SHUTDOWN ABORTED ---
***

R1#
*May 25 11:58:22.611: %SYS-5-SCHEDULED_RELOAD_CANCELLED:  Scheduled reload cancelled at 11:58:22 UTC Mon May 25 2020

Using IOS-XR this works almost the same but IOS-XR is using different syntax. It is configured in the (config) mode. Overview of available options:

RP/0/RSP0/CPU0:R2(config)#comm
commit  community-set  
RP/0/RSP0/CPU0:border1-gw(config)#commit confirmed ?
  <30-65535>  Seconds until rollback unless there is a confirming commit
  minutes     Specify the rollback timer in the minutes
  show-error  Displays commit failures immediately
  <cr>        Commit the configuration changes via pseudo-atomic operation

Syntax example:

RP/0/0/CPU0:R2#show running-config interface loopback 1
Mon May 25 13:04:24.840 UTC
interface Loopback1
 ipv4 address 7.7.7.7 255.255.255.255
!

RP/0/0/CPU0:R2#config
Mon May 25 13:04:26.260 UTC
RP/0/0/CPU0:R2(config)#no interface loopback 1
RP/0/0/CPU0:R2(config)#commit confirmed minutes ?
  <1-1024>  Minutes until rollback unless there is a confirming commit
RP/0/0/CPU0:R2(config)#commit confirmed minutes 10
Mon May 25 13:04:39.319 UTC
RP/0/0/CPU0:R2(config)#

In case the configuration session gets disconnected due to invalid configuration or similar, the IOS-XR router starts the rollback process and applies rollback configuration. This is only true for the current active management session, either on the console/vty or management-port. It is not intended using IOS-XR to commit confirm changes from another management session.