Open Defects

Below are the steps to reproduce the issue:

1. Create port-channel po1 under the ownership of tenant1

2. Create endpoint group with po1 under the ownership of tenant1

3. After step 2 begins and before step 2 completes, the raslog event w.r.t. step 1 i.e. port-channel creation is received. This Ralsog event is processed after step 2 is completed

1. Introduce switchport or switchport-mode drift on the SLX for the port-channel which is in cfg-refreshed state

2. Perform manual DRC to bring back the cfg-refreshed port-channel back to cfg-in-sync

Below are the steps to reproduce the issue:

1) Create VRF with local-asn

2) Create EPG using the VRF created in step 1

3) Take one of the SLX devices to administratively down state

4) Perform VRF Update "local-asn-add" to different local-asn than the one configured during step 1

5) Perform VRF Update "local-asn-add" to the same local-asn that is configured during step 1

6) Admin up the SLX device which was made administratively down in step 3 and wait for DRC to complete

Following are the steps to recover:

1) Log in to SLX device which was made admin down and then up

2) Introduce local-asn configuration drift under "router bgp address-family ipv4 unicast" for the VRF

3) Execute DRC for the device

Add the devices to fabric in the following sequence

1)First add devices that have preconfigured configs

2)Add remaining devices that don't have any configs stored

Removing the devices and adding the devices again to fabric in following sequence

1)First add devices that have preconfigured configs

2)Add remaining unconfigured devices.

Below are the steps to reproduce the issue:

1. Create tenant and PO.

2. Delete the tenant using the "force" option.

3. Recreate the tenant and recreate the PO in the short time window.

The bgp peer gets deleted from the SLX but not from EFA. This issue is seen when the following sequence is performed.

1. Create static bgp peer

2. Admin down one of the devices

3. Update the existing bgp static peer by adding a new peer

4. Update the existing bgp static peer by deleting the peers which were first created in step1. Delete from both devices

5. Admin up the device

6. efa tenant service bgp peer configure --name "bgp-name" --tenant "tenant-name"

Once the bgp peer is configured, the config is deleted from the switch for the device which is in admin up state whereas EFA still has this information and displays it during bgp peer show

Follow the steps below to remove the stale IP address from Tenant's knowledge base:

1. Find the management IP for the impacted devices. this is displayed in the EFA error message

2. Find the interface VE number. This is same as the CTAG number that the user was trying to associate the local-ip with

3. Telnet/SSH to the device management IP and login with admin privilege

4. Set the local IP address in the device

configure t

interface ve <number>

ip address <local-ip>

5. Do EFA device update by executing 'efa inventory device update --ip <IP> and wait for a minute for the information to be synchronized with Tenant service database

6. Reset the local IP address in the device

configure t

interface ve <number>

no ip address

7. Do EFA device update and wait for a minute for the information to be synchronized with Tenant service database

These steps will remove the stale entries and allow future local-ip-add operation to be successful.

Configure static IP, or obtain IP address from DHCP.

cd /opt/godcapp/efa

type: source deployment.sh

When the EFA installer appears, select Upgrade/Re-deploy

Select OK

Select single node, Select OK

Select the default of No for Additional management networks.

Select yes when prompted to redeploy EFA.

Once EFA has redeployed, all services should start

The device is stuck with the service lock taken as noted in the example inventory log message. This will happen when performing an EFA backup if the backup is performed near the expiration time of the authentication token.

{"@time":"2021-10-13T16:19:53.132404 CEST","App":"inventory","level":"info","msg":"executeCBCR: device '21.150.150.201' is already Locked with reason : configbackup ","rqId":"4f144a0c-7be6-4056-8371-f1dc39eb28b3"}

Following are the steps to reproduce-

Step1) Introduce VRF drift on SLX device by removing "vrf-forwarding" from VE Interfaces associated with the given VRF

Step2) Perform "efa inventory device update" for the SLX device where VRF is instantiated

Step3) Perform any VRF Update operation

Step4) Perform DRC for the same SLX device where VRF is instantiated

Step1) Remove VRF from the EndpointGroups to which it belongs by using EPG Update "vrf-delete"

Step2) Add VRF to all the EndpointGroups again by using EPG Update "vrf-add"

This issue can be seen for a bgp peer or peer group when update-peer-delete or delete operations are performed with one device for the mct pair in admin down state.

The bgp peer gets deleted from the SLX but not from EFA.

Steps to reproduce:

1. Create static bgp peer

2. Admin down one of the devices

3. Update the existing bgp static peer by deleting the peers which were first created in step1. Delete from both devices

4. Admin up the device

Once the device is brought up, auto drc kicks in and the config which is deleted from the switch due to admin down state has an incorrect provisioning-state and app-state.

During the "EFA Deploy Peer and Rejoin" step, the EFA image import into the k3s container runtime fails.

During the "TPVM Revert" step, the k3s on the active EFA node would not allow the standby EFA node to join the cluster due to a stale node-password in k3s.

Manually recover the TPVM and EFA deployment by following the procedure described in the link below:

EFA 2.5.2 Re-deploy post a TPVM Rollback failed on first attempt.

https://extremeportal.force.com/ExtrArticleDetail?an=000099582

A DRC status failure can occur if the SLX device also fails during the firmware download. The DRC failure is observed during the drift-reconcile completion step on either the spine node that is hosting the active EFA node TPVM or any device in the same firmware download group which is concurrently running the firmware download workflow at the time of HA failover. This is likely due to the SLX device rebooting and activating the new firmware.

During the EFA HA failover, the REST endpoint for the go-inventory service is not established properly and causes the drift-reconcile process to fail.

EFA's monitor process will detect and attempt to remediate this situation automatically. If it fails to do so, the following can help:

On both TPVMs, as the super-user,

$ systemctl restart k3s

If the problem recurs, these further steps, run as super-user, may help:

$ sed -i -E 's/EndpointSlice=true/EndpointSlice=false/' /lib/systemd/system/k3s.service

$ systemctl daemon-reload

$ systemctl restart k3s

The issue can be replicated by adding extra link to the existing ICL link. This could find the error in “efa fabric show”

The issue is not seen on every attempt.

Below are the steps to reproduce the issue:

1. Create a BD based tenant under a CLOS or Non-CLOS fabric.

2. Create a BD based EPG (under the ownership of the tenant created in step 1) with some ctags and some member port-channels.

3. For the reasons unknown, the BD (Bridge Domain) configuration pertaining to one of the member port-channel got deleted from the EFA DB, causing the DB to be in an inconsistent state.

4. Execute EPG update "port-group-delete" operation to remove the member port-channel whose BD configuration is inconsistent.

No recovery through EFA CLI.

The inconsistent DB needs to be corrected by creating dummy BD (Bridge Domain) entries in the database followed by EPG update "port-group-delete".

Below are the steps to reproduce the issue:

1. Create a BD based tenant under a CLOS or Non-CLOS fabric.

2. Create a BD based EPG (under the ownership of the tenant created in step 1) with some ctags and some member port-channels.

3. For the reasons unknown, the BD (Bridge Domain) configuration pertaining to one of the member port-channel got deleted from the EFA DB, causing the DB to be in an inconsistent state.

4. Execute EPG update "port-group-delete" operation to remove the member port-channel whose BD configuration is inconsistent.

Below are the steps to reproduce the issue:

1. The SLX device password is changed manually through the SLX command

2. The SLX device password is modified in EFA as well using the command "efa inventory device update --ip <IP> --username <user> --password <password"

3. "efa tenant ...." commands that correspond to the device (for which the password is changed) are executed

1. Change the device password through EFA using the command "efa inventory device update --ip <IP> --username <user> --password <password"

2. Change EFA inventory key-value store information for the corresponding device by using "efa inventory kvstore create --key switch.<IP addr>.password --value <new-password> --encrypt"

3. Wait for up to 15 minutes for this information to be consumed by the tenant service

Two recovery steps are available

Error will be observed when one of the following use cases are executed on bridge-domain enabled tenant.

Use case-1:

1. Create an EPG with multiple ctags mapped to one bridge-domain and with ports across SLX devices that are not part of an MCT pair

Use case-2:

1. Create an EPG with multiple ctags mapped to one bridge-domain and with ports or port-channels on one SLX device

2. Update the EPG with port(s) on new SLX device that is not an MCT pair of first device

Error will be observed when one of the following use cases are executed on bridge-domain enabled tenant.

Use case-1:

1. Create an EPG with multiple ctags mapped to one bridge-domain and with ports across SLX devices that are not part of an MCT pair

Use case-2:

1. Create an EPG with multiple ctags mapped to one bridge-domain and with ports or port-channels on one SLX device

2. Update the EPG with port(s) on new SLX device that is not an MCT pair of first device

1. Create L3 epg with device ports [0/10,11]

2. EPG update port-group-delete operation with both ports from the device.

3. EPG update with port-group-add with device port [0/10]

1. Create L3 EPGs with both ipv4 and ipv6 anycast-ips

2. EPG update with anycast-ip-delete, pass all anycast-ips configured as part of step 1

3. After EPG update, all anycast-ips are removed from the DB and device both

Workaround:

Pass anycast-ip one by one to the EPG update CLI. Last anycast-ip removal will

not be allowed and validation error will be thrown.

1. Create L3 EPG without ports

2. Update epg with operation: anycast-ip-delete

3. Anycast-ip not removed from the DB.