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

Delete the IP addresses on interfaces of devices having conflicting configuration so that new IP addresses can be reserved for these devices. One way to clear the device configuration is using below commands:

1. Register the device with inventory

efa inventory device register --ip <ip1, ip2> --username admin --password password

2. Issue debug clear "efa fabric debug clear-config --device <ip1, ip2>"

Delete the IP addresses on interfaces of devices having conflicting configuration so that new IP addresses can be reserved for these devices. One way to clear the device configuration is using below commands:

1. Register the device with inventory

efa inventory device register --ip <ip1, ip2> --username admin --password password

2. Issue debug clear "efa fabric debug clear-config --device <ip1, ip2>"

3. Add the devices to fabric

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.

Below are the steps to reproduce the issue:

1) Configure EPG with VRF, VLAN and anycast-ip (ipv4/ipv6) on a single rack Non-CLOS fabric.

2) Bring one of the devices to admin-down.

3) EPG Update anycast-ip-delete for anycast-ip ipv4 or ipv6. This will put EPG in "anycast-ip-delete-pending" state.

4) Bring the admin-down device to admin-up.

5) In this state, the only allowed operations on EPG are "epg configure" and EPG update "anycast-ip-delete".

6) Perform "epg configure --name <epg-name> --tenant <tenant-name>".

EPG: epgev10 Save for devices failed

When concurrent EFA tenant EPG create or update operation is requested where the commands involve large number of vlans and/or ports, one of them could fail with the error "EPG: <epg-name> Save for devices Failed".

Issue occurs with the below steps:

1. Create L3 EPG with VLAN/BD X on an MCT pair

2. Admin down one of the devices of the MCT pair

3. Delete the L3 EPG. This results in the L3 configuration removal (corresponding to the L3 EPG getting deleted) from the admin up device and no config changes happen on the admin down device and the EPG transits to epg-delete-pending state

4. Admin up the device which was made admin down in step 2

5. Delete the L3 EPG which transited to epg-delete-pending state in step 3

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.

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"

Initiating a device clean up using the following command does not clean up the associated bgp peer groups from the device.

efa fabric device remove --ip 10.20.48.161-162,10.20.48.128-129,10.20.54.83,10.20.61.92-93,10.20.48.135-136 --name fabric2 --no-device-cleanup

Before running EFA upgrade,

1. Edit /etc/ssh/sshd_config, remove the following entries

ClientAliveInterval 300

ClientAliveCountMax 0

2. Restart ssh service.

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

1) The current SLX firmware version on the devices which are being upgraded must be 20.2.3c, 20.2.3d, 20.2.3e, and 20.3.4.

2) The --noAutoCommit flag is specified for firmware download execution.

3) Any device that is in the same firmware download group with the device hosting the active EFA node, can encounter the firmware download failure.

The firmware download failure occurs when the active EFA node is reloaded to activate the new firmware while the other device is in the middle of an SLX firmware download. The HA failover will cause the firmware download workflows to be restarted at the last completed step. Since the SLX firmware download did not complete, the SLX firmware download command will be issued to the device again. The SLX firmware 20.2.3c through 20.3.4 returns an error stating that it "Cannot start download before the new image is committed."