Configuring Checkpoints and Rollback
The rollback feature allows you to take a snapshot, or user checkpoint, of the Cisco NX-OS configuration and then reapply that configuration to your device at any point without having to reload the device. A rollback allows any authorized administrator to apply this checkpoint configuration without requiring expert knowledge of the features configured in the checkpoint.
You can create a checkpoint copy of the current running configuration at any time. Cisco NX-OS saves this checkpoint as an ASCII file which you can use to roll back the running configuration to the checkpoint configuration at a future time. You can create multiple checkpoints to save different versions of your running configuration.
This section contains payload examples to demonstrate how to use the NX-API REST API to configure checkpoints and rollback on the Cisco Nexus 3000 and 9000 Series switches.
Triggering a checkpoint
Triggering a checkpoint
POST http://<IP_Address>/api/mo/sys/action.json
{
"actionLSubj": {
"attributes": {
"dn": "sys/action/lsubj-[sys]"
},
"children": [
{
"topSystemCreateCheckpointLTask": {
"attributes": {
"adminSt": "start",
"name": "checkpt-20160930",
"description": "End of quarter before upgrade",
"filename": "",
"delete": "no",
"dn": "sys/action/lsubj-[sys]/topSystemCreateCheckpointLTask",
"freq": "one-shot"
}
}
}
]
}
}
This example creates a checkpoint with a name and description.
See the NX-API DME Model Reference for detailed information about classes and attributes described in the payload: https://developer.cisco.com/site/nx-os/docs/nexus-model-reference/
For information about using the payloads, see the Cisco Nexus 9000 Series NX-OS Programmability Guide https://www.cisco.com/c/en/us/support/switches/nexus-9000-series-switches/products-programming-reference-guides-list.html
Triggering a checkpoint (with file name)
Triggering a checkpoint (with file name)
{
"actionLSubj": {
"attributes": {
"dn": "sys/action/lsubj-[sys]"
},
"children": [
{
"topSystemCreateCheckpointLTask": {
"attributes": {
"adminSt": "start",
"name": "",
"description": "",
"filename": "bootflash:ckp2",
"delete": "no",
"dn": "sys/action/lsubj-[sys]/topSystemCreateCheckpointLTask",
"freq": "one-shot"
}
}
}
]
}
}
{
"imdata": []
}
This example creates a checkpoint with a file name.
No information is present in the immediate JSON response. To verify success or failure and to view reasons for a failure, query the response object described below.
CLI Command
The CLI command below is the equivalent to the payload example displayed in the pane on the right.
checkpoint {[<name>] [description <descr>] | file <file_uri>}
For other CLI options, see the Cisco Nexus 9000 Series NX-OS Command Reference: http://www.cisco.com/c/en/us/support/switches/nexus-9000-series-switches/products-command-reference-list.html
See the NX-API DME Model Reference for detailed information about classes and attributes described in the payload: https://developer.cisco.com/site/nx-os/docs/nexus-model-reference/
For information about using the payloads, see the Cisco Nexus 9000 Series NX-OS Programmability Guide https://www.cisco.com/c/en/us/support/switches/nexus-9000-series-switches/products-programming-reference-guides-list.html
Deleting a checkpoint
Deleting a checkpoint
POST http://<IP_Address>/api/mo/sys/action/lsubj-[sys].json
{
"actionLSubj": {
"attributes": {
"dn": "sys/action/lsubj-[sys]"
},
"children": [
{
"topSystemCreateCheckpointLTask": {
"attributes": {
"adminSt": "start",
"name": "checkpt-20160930",
"description": "",
"filename": "",
"delete": "yes",
"dn": "sys/action/lsubj-[sys]/topSystemCreateCheckpointLTask",
"freq": "one-shot"
}
}
}
]
}
}
{
"imdata": []
}
Deletes the checkpoint named "checkpt-20160930"
By including "delete": "yes" in the payload, this example deletes the checkpoint.
CLI Command
The CLI command below is the equivalent to the payload example displayed in the pane on the right.
no checkpoint {[<name>] [description <descr>] | file <file_uri>}
For other CLI options, see the Cisco Nexus 9000 Series NX-OS Command Reference: http://www.cisco.com/c/en/us/support/switches/nexus-9000-series-switches/products-command-reference-list.html
See the NX-API DME Model Reference for detailed information about classes and attributes described in the payload: https://developer.cisco.com/site/nx-os/docs/nexus-model-reference/
For information about using the payloads, see the Cisco Nexus 9000 Series NX-OS Programmability Guide https://www.cisco.com/c/en/us/support/switches/nexus-9000-series-switches/products-programming-reference-guides-list.html
Clearing groups of checkpoints
Clearing groups of checkpoints
POST http://<IP_Address>/api/mo/sys/action.json
{
"actionLSubj": {
"attributes": {
"dn": "sys/action/lsubj-[sys]"
},
"children": [
{
"topSystemClearCheckpointDBLTask": {
"attributes": {
"adminSt": "start",
"mode": "all",
"dn": "sys/action/lsubj-[sys]/topSystemClearCheckpointDBLTask",
"freq": "one-shot"
}
}
}
]
}
}
{
"imdata": []
}
Deletes the checkpoint named "checkpt-20160930"
This example clears all checkpoints in the system.
No information is present in the immediate JSON response. To verify success or failure and to view reasons for a failure, query the response object described below.
CLI Command
The CLI command below is the equivalent to the payload example displayed in the pane on the right.
clear checkpoint database [user|system]
For other CLI options, see the Cisco Nexus 9000 Series NX-OS Command Reference: http://www.cisco.com/c/en/us/support/switches/nexus-9000-series-switches/products-command-reference-list.html
See the NX-API DME Model Reference for detailed information about classes and attributes described in the payload: https://developer.cisco.com/site/nx-os/docs/nexus-model-reference/
For information about using the payloads, see the Cisco Nexus 9000 Series NX-OS Programmability Guide https://www.cisco.com/c/en/us/support/switches/nexus-9000-series-switches/products-programming-reference-guides-list.html
Triggering a rollback
Triggering a rollback
POST http://<IP_Address>/api/mo/sys/action.json
{
"actionLSubj": {
"attributes": {
"dn": "sys/action/lsubj-[sys]"
},
"children": [
{
"topSystemRollbackLTask": {
"attributes": {
"adminSt": "start",
"name": "checkpt-20160930",
"uri": "",
"dn": "sys/action/lsubj-[sys]/topSystemRollbackLTask",
"freq": "one-shot"
}
}
}
]
}
}
This example rolls back to a checkpoint with a name.
Triggering a rollback (bootflash)
Triggering a rollback (bootflash)
{
"actionLSubj": {
"attributes": {
"dn": "sys/action/lsubj-[sys]"
},
"children": [
{
"topSystemRollbackLTask": {
"attributes": {
"adminSt": "start",
"name": "",
"uri": "bootflash:ckp2",
"dn": "sys/action/lsubj-[sys]/topSystemRollbackLTask",
"freq": "one-shot"
}
}
}
]
}
}
{
"imdata": []
}
This example rolls back to a checkpoint file in bootflash.
No information is present in the immediate JSON response. To verify success or failure and to view reasons for a failure, query the response object described below.
CLI Command
The CLI command below is the equivalent to the payload example displayed in the pane on the right.
rollback running-config {checkpoint <checkpoint_name> | file <file_uri>} [best-effort | stop-at-first-failure | atomic] [verbose]
For other CLI options, see the Cisco Nexus 9000 Series NX-OS Command Reference: http://www.cisco.com/c/en/us/support/switches/nexus-9000-series-switches/products-command-reference-list.html
See the NX-API DME Model Reference for detailed information about classes and attributes described in the payload: https://developer.cisco.com/site/nx-os/docs/nexus-model-reference/
For information about using the payloads, see the Cisco Nexus 9000 Series NX-OS Programmability Guide https://www.cisco.com/c/en/us/support/switches/nexus-9000-series-switches/products-programming-reference-guides-list.html
Limitations on Configuring Checkpoints and Rollbacks with NX-API
- When sending a checkpoint payload, provide the complete attribute list. Any attribute that is not required should be sent empty.
- When posting a task for creating a checkpoint to a name, the “file” attribute must be empty in the payload.
- When posting a task for creating a checkpoint to a file, only the “file” attribute should contain text, except for the “delete” attribute, which must contain “no”. The remaining attributes must be empty.
- When deleting a checkpoint, the payload must contain only the “name” attribute with the checkpoint name to be deleted, except for the “delete” attribute, which must contain “yes”. The remaining attributes must be empty.
- A payload must be provided as described above for all tasks.
- A maximum of 10 user-triggered checkpoints can be created on the device. Any user command to create an additional checkpoint is ignored. To add a new checkpoint when the limit has been reached, you must first delete one of the existing checkpoints.
- You can modify the "description" attribute with a new checkpoint request whose payload contains the same “name” attribute. Because you cannot overwrite a previously saved checkpoint, only the description will be changed.
- You must allow 5 to 10 seconds between consecutive REST requests.
- You cannot start a checkpoint filename with the word system.