Existing behavior in EFA 2.3.0
Configuration or Deconfiguration is never attempted on admin down switching devices.
Target Devices
Devices on which the configuration is intended to be pushed.
Complete Failure Topology
- Topology having atleast one single-homed device in admin down state or atleast one dual-homed device pair with both the devices in admin down state is a “complete failure topology”.
- Any Tenant CLI or REST API of create or delete nature attempted on the target devices having “complete failure topology” is rejected with an appropriate error and result in a complete failure. EFA does not have any configuration recipe prepared for this REST API or CLI as the entire request is rejected. For example, an EPG (endpoint group) create attempted on a single-homed device which is admin down state.
Complete Success Topology
- Topology with all the single-homed devices and all the dual-homed device pair in admin up state is a “complete success topology”.
- Any Tenant CLI or REST API of create or delete nature attempted on the target devices having “complete success topology” results in the configuration recipe preparation for all the target devices and the configuration is attempted on all the target devices as all the target devices are in “admin up” state.
Partial Success Topology
- Topology which is not “complete failure topology” and having at least one dual-homed device pair with one of the device in admin down state and the other device in admin up state is a “partial success topology”.
- Any Tenant CLI or REST API of
create nature attempted on the target devices having “partial success topology”
will result in the configuration being attempted onto the “admin up” devices and
configuration not being attempted onto the “admin down” devices. Even though
configuration is not attempted for “admin down” devices, the configuration is
treated as success for the “admin down” devices.
Configuration recipe is prepared and persisted in EFA for all the devices and the configuration is auto reconciled with the devices when the “admin down” devices transition to “admin up”.
When the devices are in the “admin up” state, the EFA intended configuration synchronizes with the device configuration.
- Any Tenant CLI or REST API of
delete nature attempted on the target devices having “partial success topology”
results in deconfiguration attempted on the “admin up” devices, and
deconfiguration not attempted on the “admin down” devices. The CLI or REST API
operation fails with an appropriate error indicating that the deconfiguration
not being attempted on the “admin down” devices.
The reason being EFA does not want to leave stale configurations on the devices because if the stale configurations are left on the devices, then bringing the devices (having stale configurations) back into EFA is erroneous considering the full brownfield support is missing in EFA. You can retry the same CLI or REST API operation after the “admin down” devices transition to “admin up” state so that the deconfiguration is attempted on all the devices. You can always use “force” option available in REST API to forcefully delete the entities from EFA even in case of partial success topology.
- Drift between the EFA intended configuration and device config is shown in the efa tenant debug device drift CLI or REST API output and in the corresponding entity GET or SHOW output (for example, efa tenant epg show and efa tenant po show in the form of “app-state” and “dev-state”.
- EFA blocks the tenant reconciliation API and rest of the tenant APIs support partial success behavior.