Feature behavior

The following list describes detailed behavior and CLI usage of the rollback feature:

• The user can create a rollback checkpoint, and later, return to this checkpoint with minimal impacts to services by using the following command.

  admin>rollback# save [comment comment-string]

  comment-string: a 255 character comment associated with the checkpoint

• Rollback checkpoints include all current operationally active configurations:

  • changes from direct CLI commands in the configuration branch

  • SNMP sets

• Rollback checkpoints do not include BOF configuration information. The BOF file (and BOF configuration) is not part of a rollback save or rollback. A rollback does not change any of the BOF configuration. The BOF contains basic information for the node and does not change frequently (mostly during initial commissioning of the node).

• A rollback save command can be automatically executed (scheduled, for example, monthly) using the CRON facility.

• The latest rollback checkpoint file uses a suffix of ‟.rb”. The next latest rollback checkpoint file has a suffix of ‟.rb.1”, the next oldest has a suffix of ‟rb.2”, and so on:

  file-url.rb <--- latest rollback file

  file-url.rb.1

  …

  file-url.rb.9<--- oldest rollback file

• When a rollback save [no ‟-”] is executed, the system shifts the file suffix of all the previous checkpoints by 1 (new ID= old ID+1). If there are already as many checkpoint files as the maximum number supported, the last checkpoint file is deleted.

• The maximum number of rollback checkpoints is configurable and defaults to 10 (the latest files and files 1 through 9, where checkpoint file 9 is deleted during the next rollback-save).

• The location and name of the rollback checkpoint files are configurable to be local storage (for example, compact flash) or remote storage. The file URL must not contain a suffix (just a path/directory and filename). The suffix for rollback checkpoint files is .rb and is automatically appended to rollback checkpoint files.

  config>system>rollback# rollback-location file-url

• There is no default rollback location. If a location is not specified (or it is cleared using no rollback-location) and a rollback save is attempted, the rollback save will fail and return an error message.

• On the 7210 SAS-R6 and 7210 SAS-R12, the entire set of rollback checkpoint files can be copied from the active CPM CF to the inactive CPM CF. This synchronization is done through the following command:

  admin>redundancy# rollback-sync

• The operator can enable automatic synchronization of rollback checkpoint files between the active CPM and inactive CPM. When this automatic synchronization is enabled, a rollback save will cause the new checkpoint file to be saved to both the active and standby. The suffixes of the old checkpoint files on both active and standby CPMs are increased.

  Note:

  The automatic synchronize only causes the one new checkpoint file to be copied to both CFs (the other 9 checkpoints are not automatically copied from active to standby, but that can be done manually using the admin>redundancy>rollback-sync command).

  config>redundancy# [no] rollback-sync

• config>redundancy>synchronize {boot-env|config} and admin>redundancy>synchronize {boot-env|config}” do not apply to rollback checkpoint files. These commands do not manually or automatically synchronize rollback checkpoint files. The dedicated rollback-sync commands must be used to sync rollback checkpoint files.

• Rollback files can be deleted using a dedicated rollback checkpoint deletion command:

  admin>rollback# delete {latest-rb | checkpoint-id}

  • Deleting a rollback checkpoint causes the suffixes to be adjusted (decremented) for all checkpoints older than the one that was deleted (to close the ‟hole” in the list of checkpoint files and create room to create another checkpoint).

  • If configure>redundancy>rollback-sync is enabled, a rollback delete will also delete the equivalent checkpoint on the standby CF and shuffle the suffixes on the standby CF.

  • If an operator manually deletes a rollback checkpoint file using file delete, the suffixes of the checkpoint files are not shuffled, nor is the equivalent checkpoint file deleted from the standby CF. This manual deletion creates a ‟hole” in the checkpoint file list until enough new checkpoints have been created to roll the ‟hole” off the end of the list.

• As shown in the following figure, support for rolling back to a previous configuration (a saved rollback checkpoint) with minimal impact on services. The previous configuration will be loaded and take operational effect:

  admin>rollback# revert [latest-rb | checkpoint-id]

  Figure: Configuration rollback

  

• A rollback revert does not affect the currently stored rollback checkpoint files (no deletions or renumbering). This means that if an operator issues a ‟rollback revert 3” and issues a ‟rollback-save”, the resulting rollback checkpoint files ‟file-url.rb” and ‟file-url.rb.4” will contain the same rollback state/configuration.

• The boot-good-exec or boot-bad-exec are not automatically executed after a rollback.

• Impacts to the running services are minimized during a rollback as follows:

  • There is no impact in areas of configuration that did not change, except for some exceptions.

  • Configuration parameters that changed (or items that a changed configuration has dependencies on) are first removed and the previous values are restored (can be briefly service impacting in changed areas). Some examples are as follows:

    • If the SAP ingress policy num-qos-resources value is different in the active configuration and in comparison to the value in the rollback checkpoint, all the SAPs are deleted and created again. This is done to guarantee that configuration of all the SAPs succeeds when moving to the previous configuration.

    • Changing some of the parameters in the SAP egress policy requires the port to be shut down. Therefore, when moving to a previous configuration results in change of these values, the port is shut down, the old SAP egress policy is removed, and the new SAP egress policy is applied.

• A rollback will undo any SNMP sets or direct CLI configuration commands that occurred since the last checkpoint creation.

• During the period when a node is processing a rollback revert command, both CLI commands from other users and SNMP commands will continue to be processed. The only commands that are blocked during a rollback revert are other rollback commands including revert, save, and compare (only one rollback command can be executing at a time on one node).

• Commands are available to view and compare the various rollback checkpoints to current operating and candidate configurations:

  • Rollback checkpoint files are not guaranteed to be in any particular format. They are not interchangeable with normal configuration files or exec scripts. A normal configuration file (from an admin save) cannot be renamed as a rollback checkpoint and a rollback can be executed as long as the hardware change was an addition of hardware to the node (for example, added a new IOM into a previously empty slot).

  • A rollback is not guaranteed to work if hardware was removed or changed (for example, the IOM was removed or an MDA was swapped for a different MDA type).

• Rollback across a change to the following parameters is not supported:

  • system resource profile commands

  • PTP commands

• Rollback is supported even after an admin reboot is performed (or the primary configuration in the BOF is changed and an admin reboot is performed). Admin reboot does not ‟break the chain” for rollback.

• The Configuration Rollback feature is incompatible with the use of Time Of Day (ToD) policies and functionality. Rollback save and rollback revert operations are blocked if any ToD policies are active (for example, assigned to objects such as a SAP).

• Any configuration or state change performed under the debug branch of CLI is not saved in the rollback checkpoint file nor impacted by a rollback.

• Rollbacks to a checkpoint created in a more recent release is not supported.

• The following list captures some side effects and specific behaviors of a rollback revert. Some of these side effects are not related purely to configuration (that is, in the CLI configuration branch) and may have interactions with tools commands, RADIUS, and so on:

  • SAA jobs that are running when a rollback revert is initiated, and need configuration changes due to the rollback, will be stopped. If the SAA job is a continuous type, it will be restarted as part of the rollback revert after the configuration changes have been applied (just as if the operator had typed no shutdown for the continuous SAA job). Non-continuous SAA jobs that were modified by the rollback need to be manually restarted if they need to be run again.

  • If max-nbr-mac-addr is reduced as part of the revert but the number of MAC addresses in the forwarding database is greater than the maximum number of MAC addresses, the rollback is aborted before any actions are taken and an informative error message is provided. The operator must take actions to remove the MAC addresses to proceed with the rollback.

  • If a force-switchover command has been applied to a spoke SDP FEC of a dynamic multi-segment pseudowire, and a rollback revert needs to change the admin state of the spoke SDP FEC (for example, to modify spoke SDP FEC parameters that may be dependent on admin state), the rollback revert will automatically remove the force-switchover and the node will revert to whatever is the best spoke SDP in the redundant set.

  • Rollback impacts the configuration state of the router, and as with normal operator CLI or SNMP configuration changes, additional actions or steps may need to occur before certain configuration changes take operational effect. The following are some examples:

    • Configuration changes that require a shutdown and no shutdown to be done by an operator to take operational effect also need a manual shutdown and no shutdown to be performed by the operator to take operational effect after a rollback if the rollback changes those configuration items. Some examples include:

    • Changes to autonomous system or confederation values require a BGP shutdown and no shutdown.

    • Changes to VPRN max-routes require a shutdown and no shutdown on the VPRN service.

    • Changes to an OSPF or ISIS export limit require a shutdown and no shutdown on OSPF or ISIS.

    • Configuration changes to an MSAP policy that requires a tools>perform>subscriber-mgmt>eval-msap command to take operational effect on subscribers that are already active. Rollback will change the MSAP policy configuration, but if it is required to have the configuration changes applied to the active subscribers, the operator will have to run the eval-msap tools command.

    • Changes to the SAP egress policy require a port shutdown and no shutdown. This is done automatically by the software when it detects a change.

    • Changes to the number of QoS resources in the SAP ingress policy results in deletion and creation of all the SAPs. This is done to ensure that the configuration can be successfully recreated using the SDX file.

  • Any uncommitted changes (that is, the begin command was entered and some changes were made, but the commit command was never entered) in the following areas will be lost/cleared when a rollback revert is initiated:

    • config>router>policy-options

    • config>system>sync-if-timing

• Some card and MDA commands require a reboot, remove, or rebuild of an entire card or XMA/MDA. When these commands need to be executed as part of a rollback, the impacted cards/MDAs will be listed in a warning and the operator will be prompted with a single y/n prompt to decide whether to proceed or not. This prompting will not occur for a rollback initiated via SNMP, nor if the operator uses the now keyword with the rollback revert command. Some examples of card and MDA commands that may cause a prompt are the following:

  • config>card>card-type

  • config>card>mda

  • config>card>mda>mda-type

• Although the use of the Ctrl-C key combination is not recommended during a rollback revert, it is supported through CLI and SNMP. Interrupting a rollback revert may leave the router in a state that is not necessarily something between the old active configuration and the rollback checkpoint since the rollback processing may have been in the middle of tearing things down or rebuilding configurations. A strong warning is issued in this case to indicate that the operator must examine the configuration and potentially issue another rollback revert to return to a known (and coherent) configuration.

• A high availability CPM switchover during a rollback revert will cause the rollback operation to abort. The newly active CPM will have an indeterminate configuration. When an HA switchover occurs during a rollback (or within a few seconds of a rollback completing), the operator is advised to repeat the rollback revert operation to the same checkpoint.