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 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 faila 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.
