Using Change Control and Rollback in Your Nexus Dashboard

 
Updated August 14, 2025
PDF
Is this helpful? Feedback

New and changed information

The following table provides an overview of the significant changes up to this current release. The table does not provide an exhaustive list of all changes or of the new features up to this release.

Release Version Feature Description

Nexus Dashboard 4.1.1

Improved navigation and workflow when using change control and rollback

Beginning with Nexus Dashboard 4.1.1, the navigation and workflow when using change control and rollback in Nexus Dashboard have been enhanced.

About Change Control

The change control feature allows you to track intent changes using a unique ticket that is associated with a specific action, and provides a stage/approve/deploy workflow with users that have the required privileges.

When you enable the change control feature, any supported deployment operations will be allowed only through change control tickets; all other deployment operations through the GUI or REST API will not be allowed without a change control ticket.

For example, when creating a fabric without change control enabled, you would select the appropriate fabric template, complete the necessary configurations for that fabric, and then click Recalculate & Deploy as you normally would. However, if you have the change control feature enabled, you will be able to save the configurations that you entered for the new fabric, but you will not be able to deploy those configurations until the change control workflow has been completed for this specific operation. See Typical Change Control Workflow for more information.

note.svg

The rollback feature is a related feature to the change control feature, and is covered in the About Rollback area of this document.

The following topics provide more information on the change control feature:

Guidelines and Limitations: Change Control

Following are the guidelines and limitations for the change control feature:

Areas Where Change Control is Supported

The change control feature is supported in the following areas:

  • Operations in all LAN fabric template types except IPFM

  • Operations related to endpoint locator

  • Nexus Dashboard backup and restore

  • Interface create/edit/delete

  • Link/IFCs create/edit/delete

  • Network create/edit/delete

  • VRF create/edit/delete

  • Policy create/edit/delete

Areas Where Change Control is Not Supported

The change control feature is not supported in the following areas:

  • Creating, editing, or deleting a fabric

  • Operations in IP Fabric for Media (IPFM) fabrics

  • Interface group create/edit/delete

  • Private VLAN

  • The Wait for switch mode change to maintenance on deploy option

  • Interface-based flow telemetry

  • Operations related to Layer 4 to Layer 7 services

  • Security for VXLAN EVPN fabrics using security groups

  • Reversing a network change from Layer 2 only to Layer 3

  • Fabric backup and restore

    note.svg

    We recommend using change control when you need to track and roll back changes at a granular level. Fabric backup and restore allows you to take fabric-level snapshots of a configuration. These two features cannot be used in conjunction with each other.

Additional Guidelines and Limitations

  • Operations related to image management, such as switch image upgrades and changing the switch mode, will continue to work as-is for the Super Administrator and Fabric Administrator role users. No change control ticket is required for this operation.

  • The Reload Switch option will continue to work as-is for the Super Administrator and Fabric Administrator role users. No change control ticket is required for this operation.

  • The Push Config option will continue to work as-is for the Super Administrator and Fabric Administrator role users. No change control ticket is required for this operation.

  • Change control tickets are fabric agnostic. In other words, changes from multiple fabrics can be tracked and deployed with a single ticket.

  • Change control tickets are user agnostic, within a Nexus Dashboard. In other words, UserA can create a ticket, UserB and UserC can associate changes, and so on.

  • Users with the intent CRUD privileges (Create, Read, Update, and Delete) can create the ticket and associate changes.

  • There is no limitation on the maximum number of outstanding tickets that can be initiated.

  • Ensure that switches are In Sync before making changes using tickets. See the Resolving switch Out-Of-Sync conditions resulting from OOB changes description in Special Change Control Workflows for more information.

  • Multiple tickets can be active at the same time and worked on by different users, subject to conflict detection rules, and intent changes can be associated with each of those tickets. However, changes to an entity can only be associated with a single ticket.

    For example, assume a change control ticket Ticket1 is created, where the operation is to edit Ethernet1/1. You cannot create another change control ticket (Ticket2) where that operation is also to edit Ethernet1/1. In this situation, Nexus Dashboard will detect the conflict and will automatically deny the operation for Ticket2, and will provide the reasons for the denial. See Conflict Detection: Change Control for more information.

Enabling the Change Control Feature

The change control feature is disabled by default.

To enable the change control feature:

  1. Navigate to the Fabric Management page in Nexus Dashboard:

    Admin > System Settings > Fabric Management

  2. Locate the Change control feature box in the Fabric Management page and click Edit in that box.

  3. Click the box next to Enable change control to enable the change control feature.

  4. Determine if there are other configuration settings that you want for change control:

    • Enable for Orchestration: Check the box to enable change control for orchestration for ACI fabrics. The orchestration options are not supported for NX-OS fabrics.

      The following options become available if you check the Enable for Orchestration option:

      • Required number of approvers: Enter the number of approvers required for change control tickets. Default is 1 approver.

      • Allow self approval: This field is enabled by default. Check the box to allow users who select or create a change control ticket for an action to also approve that change control ticket.

    • Enable for ND Managed Fabrics: Check the box to enable change control for Nexus Dashboard-managed fabrics.

      The following options become available if you check the Enable for ND Managed Fabrics option:

      • Enable bypass change control for telemetry: Check the box to enable bypass change control for telemetry.

        If there are any system-triggered changes to configuration settings related to telemetry, a ticket approval or deployment process is not required, as these changes will be automatically approved and deployed if the Enable bypass change control for telemetry option is enabled.

        note.svg

        You can also disable Enable bypass change control for telemetry option, if you want to create a ticket to approve/deploy. The disable option will not work for colocation fabrics.

      • Ticket name prefix: Change the Ticket ID prefix string from the default TICKET_, if necessary. See Configuring the Auto Generated Ticket ID for more information.

  5. Click Save.

Once you have enabled the change control feature, all areas that are supported with change control are now tracked with a ticket. See Guidelines and Limitations: Change Control for a list of areas that are tracked with a ticket when change control is enabled, and see Typical Change Control Workflow to understand how having the change control feature enabled affects the Nexus Dashboard operations that are supported with change control.

You can return to the Fabric Management page to disable the change control feature; however, disabling the change control feature after you have enabled it is not supported when active tickets (works in progress) are detected. You must complete the change control process on any active tickets before you can disable the change control feature in this case.

Once you have successfully disabled the change control feature, the change operations will no longer be tracked with change control tickets. Completed tickets and associated data remains, but you cannot perform any actions against those areas.

Roles Associated With Change Control

These roles are associated with the change control feature:

  • Approver: Users with this privilege can approve change control tickets.

    A user that is assigned with the Approver role can double-check changes that are associated with a specific ticket and approve or deny those changes.

  • Support Engineer: Users with this privilege can deploy change control tickets.

    Once a change control ticket is approved by a user with the Approver role, that ticket is then available to any user that is assigned with the Support Engineer role, who can then deploy the changes that have moved to the deployment stage in the change control workflow.

    A user who is assigned a Support Engineer role will also have to go through the necessary credentials process in the LAN Credentials Management window:

    Manage > Device Credentials > LAN Credentials Management

    For more information, see the "LAN Credentials Management" section in the Managing Your Device Credentials.

  • Fabric Administrator: The traditional role of Fabric Administrator is also valid in the change control workflow, where a user with the Fabric Administrator role can also perform the actions associated with the Approver and Deployer roles.

    A user with the Fabric Administrator role can perform all the operations in Nexus Dashboard. For example, a user with this role can freeze a particular fabric or all fabrics in Nexus Dashboard.

  • Designer: A user with the Designer role can make configuration changes on Nexus Dashboard and can deploy these changes later.

    A Designer can perform the following actions:

    • Edit interface configurations

    • View or edit policies

    • Create interfaces

    • Change fabric settings

    • Edit or create templates

    However, a Designer cannot perform the following actions:

    • Cannot make any configuration deployments to switches.

    • Cannot perform deployment-related actions from the Nexus Dashboard Web UI or the REST APIs.

    • Cannot access the administration options like licensing, creating more users, and so on.

    • Cannot move switches in and out of maintenance mode.

    • Cannot move fabrics in and out of deployment-freeze mode.

    • Cannot install patches.

    • Cannot upgrade switches.

    • Cannot create or delete fabrics.

    • Cannot import or delete switches.

    • When you perform a Recalculate & Deploy action as part of a switch or interface configuration process, the host port resync process pulls the running configuration from the switches using LAN credentials. However, a user with the Designer role does not have access to the LAN credentials, so the Recalculate & Deploy action will fail in this case for users with the Designer role. Instead, a user with the Fabric Administrator role, with the appropriate LAN credentials, should perform the Recalculate & Deploy action in this case. Note that this issue exists regardless of whether change control is enabled or not.

Typical Change Control Workflow

Change control tickets have a defined workflow lifecycle, and include state information that indicates where they are in the workflow.

Following is a typical workflow when using change control:

  1. Verify that the change control feature has been enabled.

    See Enabling the Change Control Feature for those procedures.

  2. Verify that the appropriate users have been assigned the necessary Approver and Deployer change control roles.

    See Roles Associated With Change Control for more information.

  3. If you are performing an operation where change control is supported, at the end of that operation, a change control popup window appears, similar to the following:

    NDFC-ChangeControl-SaveChange.jpg

    For example, if you have change control enabled and you are creating a new fabric using any of the supported fabric templates, once you have entered all of the necessary information in the configuration fields and you have clicked the Save button at the end of the fabric creation process, a change control ticket similar to the image above appears.

  4. Enter the necessary information when the change control ticket appears to describe this change:

    1. In the Select Ticket field, select a previously-configured change control ticket, or click Create New Ticket to create a new change control ticket for this operation.

      See Guidelines and Limitations: Change Control for more information on scenarios where you might choose to use a previously-configured change control ticket for an operation.

      • If you selected a previously-configured change control ticket for this operation, click Save, then go to Step 5 in these procedures. Note that the following applies for the previously-configured change control tickets listed here:

        • Only tickets that are in the PENDING or DENIED states will be listed.

        • The ticket list is filtered with RBAC rules, so you will only see tickets that are associated with fabrics that you have access to.

      • If you clicked Create New Ticket to create a new change control ticket for this operation, the Save Ticket window appears.

        NDFC-ChangeControl-SaveTicket.jpg

        Continue with these steps to configure the new change control ticket.

    2. In the Ticket Id field, note that an automatically-generated change control ticket ID is entered by default for the new change control operation.

      Each new change control ticket is given an automatically-generated ticket ID in this format:

      <Ticket ID prefix string><Sequence id>

      • The <Ticket ID prefix string> part of the ticket ID is automatically generated based on the configurations in the Admin > System Settings > Fabric Management > Change control area. If you want to change the <Ticket ID prefix string> part of the automatically-generated ticket ID, see Configuring the Auto Generated Ticket ID.

      • The <Sequence id> part of the ticket ID is a numerical value that is automatically incremented.

    3. Determine if you want to use the automatically-generated change control ticket ID for this operation or if you want to manually enter a different, unique ticket ID for this operation.

      If you do not want to use the automatically-generated ticket ID, you can delete the default text in the Ticket Id field and replace it with new text, if necessary. The new ticket ID must meet the following criteria:

      • Only a-z, A-Z, 0-9, _, - characters are allowed.

      • The ticket ID should start with an alphabetical character.

      • Maximum length is 64 characters.

    4. In the Description of this change field, enter the reason for this change control ticket (for example, "This ticket is for creating the 'DC1' Data Center VXLAN EVPN fabric"). The maximum length for the text in this field is 255 characters.

    5. Click Save after you have entered the necessary information in the fields in the Save Ticket window.

      You are returned to the Save Change window, with the new ticket ID showing in the Select Ticket field by default.

    6. Click Save in the Save Change window.

  5. After you have completed the configurations in the Save Change window and clicked Save, you are returned to the original window where you were attempting to perform an operation where change control is supported.

    For example, using the example operation that we described earlier in these procedures, you would return to the Create Fabric page. You would then proceed through that remaining set of processes specific to this action as you normally would, such as clicking Save in the Create Fabric page and returning to the Fabric Overview window for that new fabric.

    Note that you may not be able to perform certain subsequent actions the same way as before if you have change control enabled. For example, continuing with the fabric creation scenario, normally you would be able to click Actions > Recalculate & Deploy in the Fabric Overview window for the fabric that you just created. However, when change control is enabled, that option changes to Actions > Recalculate; a user with the Support Engineer role can only deploy the change through the change control ticket process once change control is enabled.

  6. View the information on the new change control ticket.

    Navigate to Manage > Change Control to view detailed information about this change control ticket, and other change control tickets that are already configured on this system. See Viewing Change Control Ticket Information for more information.

  7. Submit the ticket for approval, if necessary.

    If you have a Nexus Dashboard Network Admin user role, you do not have to submit the ticket for approval in this step; the ticket will be automatically approved internally. Skip to the deployment process in Step 8 below in this case.

    1. With the Active tab selected in the Change Control window, select the change control ticket that you want to submit for approval.

    2. Click Actions > Submit for approval.

      A warning message appears, asking if you’re certain that you want to submit this change control ticket for approval.

    3. Enter a reason for the approval request in the text window, then click Ok.

Special Change Control Workflows

The following change control workflows have special characteristics that make them unique in some way:

  • Cancelling All active tickets and disabling the change control feature: Normally, the change control feature cannot be disabled if active tickets are present. However, there may be situations where the change control feature must be disabled forcefully with active tickets. The Cancel all option (Actions > More > Cancel all) is available to Fabric Administrator users to forcefully move all active ticket states to CANCELLED.

    note.svg

    This does not perform the rollback action. The ongoing configuration intent is kept intact.

    After performing the Cancel all action, you can then disable the change control feature from Admin > System Settings > Fabric Management > Change control. You can enable the change control feature again from the same location at a later date, if desired.

  • Deleting unwanted tickets: Only tickets in the CREATED state can be deleted. All records for this will be purged.

  • Changing the switch mode: Nexus Dashboard supports changing the switch mode in the Topology and Image Management windows; however, since operations related to image management are not integrated with change control, changing the switch mode or other operations from image management will work as-is, while the other flows will require ticket IDs for making changes.

  • Resolving switch Out-Of-Sync conditions resulting from OOB changes: When Nexus Dashboard detects out-of-band (OOB) configuration changes to switches, their Config Status changes to Out-Of-Sync. Gettting those switches back to an In-Sync state without additional configuration intent changes will require deploying the pending diffs using this procedure:

    1. Select the switches whose Config Status is Out-Of-Sync or Pending.

    2. Click Actions > More > Bind to Ticket and associate with a ticket.

    3. Deploy the diffs using the usual Change Control ticket workflow.

      note.svg

      Out-of-band changes on a switch will appear on existing active tickets.

  • Resolving bad intent issues:

    • If a ticket is in the APPROVED state but you then need to edit the intent, the Approver user can DENY the ticket to allow further edits.

    • If a deployment attempt has been made on a ticket in APPROVED state, the deployment may fail due to a bad intent, such as a typo, an invalid CLI entry, and so on. The ticket state will show as DEPLOYMENT_ATTEMPTED once the deployment fails. The Approver user can then DENY the ticket to allow further edits and go through the normal ticket deployment flow.

  • Deny/Return For Edits:

    • For tickets that are in the APPROVAL_PENDING or APPROVED states, it is possible to make further changes to these tickets by using the Action > Deny/Return For Edits option. This is supported for users with any of these roles:

      • Fabric Administrator

      • Approver

      • Designer

        note.svg

        A Designer can perfom this action only if they created the ticket.

    • For tickets that are in the DEPLOYMENT_ATTEMPTED state, it is possible to make further changes to these tickets by using the Action > Deny/Return For Edits. This is supported for users with any of these roles:

      • Fabric Administrator

      • Approver

  • Issues with user roles and VXLAN EVPN Multi-Site Fabrics:

    An issue may arise due to user roles when working with VXLAN EVPN Multi-Site fabrics.

    Assume your Nexus Dashboard has a fabric group (fabgroup-fab1) with two child fabrics (fab1 and fab2). A user with a Designer role (StagerFab1), who has write access to the "all" domain and to the the fab1 child fabric, wants to make configuration changes, such as creating overlay definitions, to the VXLAN EVPN Multi-Site fabric.

    • If change control is not enabled, the StagerFab1 user is allowed to create overlay definitions in the VXLAN EVPN Multi-Site fabric. That’s because, under normal conditions, a user has write access to a VXLAN EVPN Multi-Site fabric if they have both:

      • write access (Fabric Administrator or Designer) on the "all" domain, and

      • write access (Fabric Administrator or Designer) on at least one child fabric in the VXLAN EVPN Multi-Site fabric

    • However, if change control is enabled, the StagerFab1 user is allowed to create overlay definitions in the VXLAN EVPN Multi-Site fabric, but since the change control ticket involves a VXLAN EVPN Multi-Site fabric and the fab1 and fab2 child fabrics, the change control ticket will get filtered out for the StagerFab1 user because the change control ticket has changes in the fab2 child fabric, which the StagerFab1 user does not have write access for.

      To work around this issue, the StagerFab1 should be assigned a Fabric-Administrator role instead of a Designer role. A user with a Fabric-Administrator role is given the following access:

    • Fabric-Administrator access to domains associated with all member fabrics

    • Fabric-Administrator access to the “all” domain

    A user with a Fabric-Administrator role will be able to successfully make the configuration changes described above with change control enabled.

Viewing Change Control Ticket Information

Navigate to the Tickets screen to view information on the change control tickets that have been configured for your Nexus Dashboard system:

Manage > Change Control

Information on the all of the configured change control tickets are provided in the two tabs in the Tickets screen:

You can also view detailed information on a specific change control ticket. See Details on a Specific Change Control Ticket for more information.

Active

Tickets in any state other than DEPLOYED or CANCELLED are considered Active.

The Active tab provides the following detailed information on active change control tickets:

Field

Description

Time

The date and time that the change control tickets were triggered.

Tickets

The names of the change control tickets.

Description

The reason for the change control tickets (the information provided in the Description of this change field in the change control tickets).

Status

The status of the change control tickets, such as CREATED, PENDING, APPROVED, DENIED, and so on. See Change Control Ticket Lifecycle for more information on the various states that are displayed in the Status field and what they mean.

Last Reason

The last reason of the change control tickets, such as Change Associated.

Created By

The IDs of the users who triggered the change control tickets.

Approved By

The IDs of the users who approved the change control tickets. See Roles Associated With Change Control for more information.

Deployed By

The IDs of the users who deployed the change control tickets. See Roles Associated With Change Control for more information.

In the Active tab, the Actions button provides the following actions:

  • Create ticket: Allows you to create a change control ticket.

  • Submit for approval: Click a box next to a change control ticket that has a status of PENDING, then click Submit for approval to send that change control ticket to a Nexus Dashboard Change Approver.

  • Preview: Allows you to preview information about the change control ticket, such as the devices that are part of the change control ticket and the progress of the operation that is associated with the change control ticket.

  • Approve: If you have a Nexus Dashboard Change Approver role, click a box next to a change control ticket that is in the Active state, then click Approve to approve that change control ticket.

  • Deny: If you have a Nexus Dashboard Change Approver role, click a box next to a change control ticket that is in the Active state, then click Deny to deny that change control ticket.

  • Deploy: If you have a Nexus Dashboard Change Deployer role, click a box next to a change control ticket that is in the Active state, then click Deploy to deploy that change control ticket.

  • Rollback: Click a box next to a change control ticket that has a status of PENDING, then click Rollback to roll back that change control ticket. See About Rollback for more information.

  • Delete: Click a box next to a change control ticket that is in the Active state, then click Delete to delete that change control ticket.

Complete

Tickets in the DEPLOYED or CANCELLED state are considered Complete.

The Complete tab provides the following detailed information on active change control tickets:

Field

Description

Time

The date and time that the change control tickets were completed.

Tickets

The names of the change control tickets.

Description

The reason for the change control tickets (the information provided in the Description of this change field in the change control tickets).

Status

The status of the change control tickets, such as DEPLOYED or CANCELLED.

Last Reason

The last reason of the change control tickets, such as Deployment Successful - No Changes or Ticket Rolled Back.

Created By

The IDs of the users who triggered the change control tickets.

Approved By

The IDs of the users who approved the change control tickets. See Roles Associated With Change Control for more information.

Deployed By

The IDs of the users who deployed the change control tickets. See Roles Associated With Change Control for more information.

In the Complete tab, the Actions button provides the following actions:

  • Rollback: Click a box next to a change control ticket that has a status of DEPLOYED, then click Rollback to roll back that change control ticket. See About Rollback for more information.

Details on a Specific Change Control Ticket

Additional details are available for each change control ticket.

  1. Navigate to the main Tickets window:

    Manage > Change Control

  2. Double-click on any change control ticket listed under the Tickets column in either the Active or the Complete tab in the Tickets window.

    The details window for that specific change control ticket appears.

Change Records

The Change Records page shows the set of changes that are associated with this ticket.

The following fields are shown in the Change Records page:

Field

Description

Action

Indicates the user activity.

Operation

Indicates the type of operation used in the change control ticket, such as Update or Add.

Fabric

The name of the fabric that the change control ticket is associated with.

User

The user ID of the person who triggered the change.

Rollback Allowed

Indicates if a rollback is allowed for this specific change control action. For more information, see Guidelines and Limitations: Rollback.

Timestamp

The date and time when the change was triggered.

Details

Click View Details to view additional details on this change control ticket.
Audit History

The Audit History page shows the state of the transitions associated with this ticket.

The following fields are shown in the Audit History page:

Field

Description

Updated Time

The date and time that the stage in the change control ticket workflow occurred (the stage shown in the Status column).

User

The user ID of the person who triggered the change.

Status

The state of the transition for the change control ticket.

Reason

The reason for the change control ticket (the information provided in the Description of this change field in the change control ticket).
Deployment History

The Deployment History page shows the set of deployment records that are associated with this ticket (available only when a deployment has been attempted).

The following fields are shown in the Deployment History page:

Field

Description

HostName

The IP address of the entity that the change control ticket was triggered on.

Entity Name

The name of the entity that the change control ticket was triggered on.

Entity Type

The type of entity that the change control ticket was triggered on.

Source

The source where the entitythat the change control ticket was triggered on resides.

Commands

Click Detailed History to view details of the before and after commands associated with the change control ticket was triggered.

Status

The state of the transition for the change control ticket.

Serial Number

The serial number of the entity that the change control ticket was triggered on.

Status Description

The status of the change control ticket.

User

The user ID of the person who triggered the change.

Time of Completion

The date and time when the change control ticket was successfully deployed.

Configuring the Auto Generated Ticket ID

The change control ticket ID is set to be automatically generated, where each change control ticket uses the following format:

<Ticket ID prefix string><Sequence id>

Where:

  • The <Ticket ID prefix string> is a configurable property, with TICKET_ used as the default value.

  • The <Sequence id> is a numerical value that is automatically incremented that cannot be changed, starting with the default value of 0.

For example, if you were to change the value of the <Ticket ID prefix string> from TICKET_ to ND1_, then the change control tickets would start with the names ND_0, ND_1, and so on.

To configure the auto generated Ticket ID information:

  1. Navigate to:

    Admin > System Settings > Fabric Management > Change control

  2. Locate the Ticket name prefix field.

  3. Enter the value that you want to use for the <Ticket ID prefix string> part of the change control ticket ID.

    Only a-z, A-Z, 0-9, _, - characters are allowed, and the name should start with an alphabetical character.

  4. Click Save.

Change Control Ticket Lifecycle

The following figure shows the various states that a change control ticket goes through.

505015.jpg

The following table describes each stage of the change control ticket lifecycle.

Field

Description

CREATED

Newly-created tickets will be in the CREATED state.

PENDING

A ticket with at least one associated change will be in the PENDING state.

APPROVAL_PENDING

Intent changes associated with an APPROVAL_PENDING ticket are completed and have been submitted for approval. Only users with Super Administrator and Designer privileges can perform this action.

APPROVED

The user with Approver (and Super Administrator) privileges has reviewed the changes and is satisfied with the content. This state indicates that the ticket is ready for deployment.

DENIED

The user with Approver privileges (and Super Administrator) has reviewed the changes but requests more changes to be associated. This state indicates that the Designer must amend the existing ticket. Once a change is associated with a ticket in this state, it will move to the PENDING state.

CANCELLED

This could ndicate a ticket that has been rolled back. This is a terminal state. See About Rollback for more information.

This can also occur when a Nexus Dashboard Network Admin user performs a Cancel all action. This action is not a rollback, but instead forcefully moves the ticket to a CANCELLED state, leaving all the intent changes as is.

DEPLOYED

The user with Support Engineer (and Super Administrator) privileges has successfully deployed the ticket. This is a terminal state.

DEPLOYMENT_ATTEMPTED

This indicates an earlier failed deployment attempt. Users with Support Engineer (and Super Administrator) privileges have attempted a deployment that may have failed due to bad intent, issues with the reachability of the switch, or some other error condition. The ticket will either need to be edited (a change of intent) and/or will require a reattempt deployment after the error condition is fixed. Changing the intent will require the Approver user to Deny the ticket so that it goes to the DENIED state, and will then go through the approval process again. Any number of deployment attempts can be performed in this state until the entire set of diffs gets deployed successfully. Once the deployment is successful, the ticket will move to the DEPLOYED state.

Ticket Purging Policy

  • Tickets in the DEPLOYED and CANCELLED states (Complete), along with their associated records, will be retained for a certain number of days based on a setting in the LAN-Fabric tab in the Server Settings page.

    Set the amount of time that tickets will be retained by navigating to:

    Admin > System Settings > Fabric Management > Advanced Settings > LAN-Fabric

    Locate the Change Control Completed Tickets Purge Interval in days field and enter the appropriate value. The default value for this field is 30, and the acceptable range for this field is 10-60 days.

  • The purging check occurs once per day.

  • Tickets identified for purging will be removed from Nexus Dashboard along with their associated Policy Change History and Deployment History records. No record of the purged ticket will be maintained on Nexus Dashboard.

Policy Change History Usage

Change control tickets use the Policy Change History record for tracking changes.

  • The PTI History Tracking server setting, if checked, will disable the tracking of Policy Change records. When the Change Control feature is enabled, this server setting is a no-op.

  • The Purge limit for PTI history server setting controls the maximum number of policy change records that will be retained. When the Change Control feature is enabled, change records associated with tickets will not be purged. The Policy Change History records will be purged along with the ticket identified to be purged.

Deployment History Usage

Tickets use the Deployment History record for tracking deployment changes.

The Purge limit for deployment history server setting controls the maximum number of deployment records that will be retained. When the Change Control feature is enabled, deployment records associated with tickets will not be purged. The Deployment History records will be purged along with the ticket identified to be purged.

Beginning with Nexus Dashboard 3.2.1, to prevent a backup and restore failure due to a timeout because the purge limit for deployment history exceeds 4 million records, Nexus Dashboard checks the number of deployment history records every five minutes. Nexus Dashboard checks whether the number of deployment history records in the pmn_deployment_history table is more than 2 million and the number of deployment history records that are older than 24 hours is more than 300,000. If the condition matches, Nexus Dashboard purges the expired records that are older than 24 hours and keeps at most ten expired records for the host or flow policy for each device.

Conflict Detection: Change Control

Nexus Dashboard entities (such as switches, interfaces, networks, VRFs, and so on) can be associated with one active ticket at a time (any ticket whose state is not DEPLOYED or CANCELLED). If you attempt to trigger a change control ticket when a conflict is detected, Nexus Dashboard will not allow that change control ticket to be triggered and will describe the conflict so that you can resolve the issue.

The following conflict checks are performed when changes are associated with active tickets:

  • Entity conflicts: Each entity can be part of a single active ticket. For example, if Ethernet1/1 of switch A is associated with a change in ticket T1, the same interface cannot be updated by another ticket (T2). However, the same ticket T1 can be used for making further changes to Ethernet1/1 of switch A.

  • Fabric level actions: Edit settings and Recalculate actions must be in same ticket. If a Recalculate action is part of a ticket, another Recalculate action with a different ticket will be denied.

  • Switch level conflicts: python, python_cli check at switch level (serial number), template_cli and switch_freeform check PTI id

  • Host Port Resync: A Recalculate action must be part of the same ticket.

About Rollback

Using the rollback feature, tickets that have been created for change control can be rolled back or reverted, if necessary.

Rollback is supported in the following situations:

  • Change control tickets can be rolled back while they are still being worked on, such as a situation where a change was started but then a decision was made to abandon that change. This ticket can be rolled back, at which point all the intent changes made are reverted back to their previous state.

  • Tickets that have been deployed can also be rolled back. In this case, a new ticket will be automatically created, which has the intent to be rolled back.

note.svg

Because the rollback feature is an extension of the change control feature, the rollback feature is available only if you have enabled the change control feature. See Enabling the Change Control Feature for those procedures.

The following topics provide more information on the rollback feature:

Guidelines and Limitations: Rollback

Because the rollback feature is an extension of the change control feature, all guidelines and limitations listed in Guidelines and Limitations: Change Control are also applicable for the rollback feature.

Following are additional guidelines and limitations for the rollback feature:

  • Only users with the following roles can perform a rollback:

    • Users with an Super Administrator role

    • Users with a Designer role can perform a rollback; however, an additional Support Engineer role is needed to be able to deploy the rollback.

      Following is an example scenario that illustrates where users with certain roles can perform the approval and deployment actions associated with change control tickets, and can also perform a rollback action on those change control tickets:

      1. User-A, who has a Designer + Support Engineer role, creates an intent and associates it with a change control ticket. Later on, User-A also submits the ticket for approval.

      2. User-B, who has an approver role, approves the change control ticket.

      3. User-A then deploys the ticket, since User-A has the Designer + Support Engineer role.

      4. Later on, when it’s determined that this change control ticket should be rolled back, User-A is also able to roll back this ticket due to the Designer + Support Engineer role.

  • Rollback is supported in the following situations:

    • Undeployed Tickets: These are change control tickets where changes have been staged but have not yet been deployed (tickets shown in the Active tab in the Change Control window). In this case, the changes associated with the ticket will be discarded and the ticket will be moved to the CANCELLED state.

      For undeployed tickets:

      • You can perform a full ticket rollback, or you can perform a rollback of the last action for the undeployed ticket.

      • This rollback can be performed by an Fabric Administrator or any of the staging-related roles.

    • Deployed Tickets: These are tickets where changes have been deployed (tickets shown with a DEPLOYED status in the Complete tab in the Change Control window). In this case, a new ticket with changes to revert the original changes will be created. The new ticket must go through the usual approval process to get deployed, and the original ticket will be moved to the CANCELLED state.

      For deployed tickets:

      • You can only perform a full ticket rollback. You cannot perform a rollback of the last action for a deployed ticket.

      • This rollback can be perfomed by an Fabric Administrator or the Designer.

  • Rollback is not supported in the following situations:

    • A rollback of auto-generated rollback tickets is not allowed. The auto-generated rollback tickets are shown as NDFC_RB-xxxx tickets; they are generated during the rollback of deployed tickets.

    • Any action that involves an inventory change (for example, if you add or delete switches).

    • There may be challenges when rolling back certain actions that were “one way” (for example, some role changes).

    • Any change control ticket that has Layer 4 to Layer 7 services actions associated with it cannot be rolled back. In other words, if you take an action in the Layer 4 to Layer 7 services window with a new or existing (shared) control ticket, you cannot roll back that change control ticket.

    • Similarly, any change control tickets associated with endpoint locator (EPL) cannot be rolled back.

Typical Rollback Workflow

Users with sufficient privileges can perform a rollback.

Following is a typical workflow when using the rollback feature:

  1. Navigate to Manage > Change Control to view all of the undeployed and deployed change control tickets.

  2. Identify a change control ticket that you want to roll back, listed either under the Active tab (undeployed tickets) or with a DEPLOYED status under the Complete tab (deployed tickets).

  3. Click the box next to that change control ticket, then click Actions > Rollback.

    A warning messsage appears, asking if you are sure that you want to roll back this ticket.

  4. Click Confirm in the warning message to continue with this rollback action.

    The Change Control window reappears.

    • If you rolled back an undeployed ticket, the rolled-back change control ticket is removed from the list of tickets shown on Active page. The rolled-back ticket now appears in the Complete page, with CANCELLED shown in the Status column and "Ticket Rolled Back" shown in the Last Reason column.

    • If you rolled back a deployed ticket, the rolled-back ticket in the Complete page changes states, with CANCELLED shown in the Status column and "Ticket Rolled Back" shown in the Last Reason column.

      Follow these additional steps when rolling back a deployed ticket:

      1. Click the Active tab in the Change Control page.

        The rolled-back ticket now appears under the Active tab, with the status shown as APPROVED.

      2. Click the box next to the rolled-back ticket, then click Actions > Deploy to deploy the rolled-back ticket again.

      3. Navigate back to Manage > Change Control and click the Complete tab.

        The rolled-back ticket now appears with DEPLOYED in the Status column.

Special Rollback Workflows

The following rollback workflows have special characteristics that make them unique in some way:

  • Rollback of last action for an undeployed ticket:

    If you have an undeployed ticket, any user with Designer or Super Administrator roles can roll back the last action that was taken for that undeployed ticket. When all the associated changes are rolled back, the ticket state will be moved back to the CREATED state. Note that you can roll back the last action only on a ticket that is in a pending or denied state.

    For example, assume that you have a single change control ticket with 10 different changes as part of that single ticket, and you want to undo the last change in that undeployed change control ticket. Follow these procedures to rollback the last action in an undeployed ticket in this situation:

    1. Navigate to Manage > Change Control, then select the Active tab to display all of the undeployed tickets.

    2. Double-click on the undeployed ticket where you would like to rollback the last action on that ticket.

      The overview window for that undeployed ticket appears.

    3. Verify that you can see "true" as the value in the Rollback Allowed column for this undeployed ticket.

      You will not be able to roll back the last action of this undeployed ticket if the value in the Rollback Allowed column is shown as "false".

    4. Click Actions > Rollback last action.

      A warning message appears, asking if you’re sure that you want to roll back the last action on this ticket.

    5. Click Confirm to continue with the rollback.

      The last action in this undeployed ticket is now rolled back.

    6. Navigate back to the Active tab in the Change Control window.

      The value in the Status column for this undeployed ticket changes to CREATED.

  • Full ticket rollback:

    • Deployed Tickets:

      • Users with the Super Administrator role can perform a rollback on a deployed ticket, which will move the current ticket to a CANCELLED state. A new ticket can then be created internally for the rollback that will be in an APPROVED state that needs to be deployed.

      • Following are the characteristics of an internally-created rollback ticket:

        • The ticket ID shows as NDFC_RB-xxxxx. For example, NDFC-RB-565666666.

        • The description is shown as "Changes for rolling back ticket XXXXXX".

        • Both the original and newly-created ticket will cross reference each other’s ticket IDs and will be shown in the Nexus Dashboard GUI window.

        • Additional changes to the new ticket are not allowed.

        • The rollback ticket will be moved to an approved state at the end of rollback.

    • When a ticket is rolled back, it will be cancelled. No further actions can be performed on that ticket.

    • When a deployed ticket is rolled back, a new rollback ticket is created. That newly-created rollback ticket will be in the Approved state, so you can perform a deployment on that rolled back ticket.

Conflict Detection: Rollback

The following conflict checks will be performed when a ticket rollback is attempted:

  • For deployed tickets, each entity in a ticket that is being rolled back will be checked based on the rules provided in the Conflict Detection: Change Control section.

    For example, assume a deployed ticket is rolled back and has an entity E1. If one of the other pending tickets are associated with the same entity E1, then the rollback request will be treated as a conflict and will be denied.

    As another example, if there are one or more other deployed tickets that are associated with the same entity and if any of those changes are newer than the ticket being rolled back, then the rollback request will be treated as a conflict and will be denied.

  • Action level rollbacks are treated the same way as pending tickets, except that the scope is limited to one action.

  • The same rules for entity conflicts also apply for action conflicts, such as recalculate config.

First Published: 2025-01-31
Last Modified: 2025-01-31

Need help?