Administered Partial Success

For a two-leaf MCT pair, you can enable configurations to succeed when only one node of the pair is reachable.

Overview

By default, when a REST operation succeeds on one device but fails on another, configuration changes are rolled back for both devices. For more information, see Rollback Scenarios for Data Consistency.

However, for a two-leaf MCT pair, you can administratively change the process to permit configuration to succeed even when one device is down. This process, called an administered partial success, is as follows.
  • You use the efa inventory admin-state command to change the state of the unreachable device to "admin down." The device then goes into maintenance mode. For more information about changing a device state, see Administratively Manage a Device State.
  • XCO filters out configurations destined for MCT pair as follows.
    • Create-related and delete-related configurations destined for the "admin up" device succeed.
    • Create-related configurations are not attempted for the "admin down" device, but the configurations are considered a success. These configurations are marked as pending, to be pushed to the device when it comes back up.
    • Delete-related configurations (de-configurations) are not attempted for the "admin down" device and the operation fails with an error in the REST response. You can retry these de-configurations after the device transitions to “admin up” state.

      XCO does not want to leave stale configurations on the devices because if stale configurations are left on the devices, then bringing the devices (with stale configurations) back into XCO are erroneous considering the full brownfield support is missing in XCO.

  • When the device is again reachable, you change the state of the device to "admin-up."
  • XCO pushes the pending configurations to the device, and the drift and reconcile process ensures that the configurations in XCO and the device are synchronized. For more information, see Drift and Reconcile.
  • The device comes out of maintenance mode.

Tips and considerations

Behavior changes during "admin down" state

After a device state changes to "admin down," the following behavior changes occur.
  • Switch Health Management does not trigger the drift and reconcile process.
  • A device going into maintenance mode does not trigger the drift and reconcile process.
  • The following commands are blocked from affecting the device.
    Table 1. Blocked commands
    Command type and name
    Inventory commands
    efa inventory device compare --ip
    efa inventory drift-reconcile --ip
    efa inventory device setting update --ip
    efa inventory rma --ip
    efa inventory config-backup execute --ip
    efa inventory config-replay execute --ip
    efa inventory device update --fabric
    efa inventory device firmware-download prepare add --ip
    efa inventory device update --ip
    efa inventory device interface set-speed --ip
    efa inventory device interface set-breakout --ip
    efa inventory device interface unset-breakout --ip
    efa inventory device interface set-mtu --ip
    efa inventory device interface set-admin-state --ip
    efa inventory device running-config persist --ip
    Fabric commands
    efa fabric configure --name

    efa fabric device remove --ip <> --name <>

    Allowed with the --no-device-cleanup option.
    efa fabric show-config --name
    efa fabric topology show underlay --name
    efa fabric topology show overlay --name
    efa fabric topology show physical --name

Behavior changes during "admin up" state

After a device is returned to "admin up" state and after the drift and reconcile process is complete (which the state change triggers), Switch Health Management and drift and reconcile resume normal behavior. Also, the blocked commands are unblocked.
9037725-01 RevAA