Defects Closed with Code Changes

When the ports provided by the user in “tenant update port-delete operation” contains all the ports owned by the port-channel, the PO goes into delete pending state. However, the ports are not deleted from the PO.

They get deleted from the tenant though.

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

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"}

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

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

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

1. 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". Then wait for 15 minutes for this information to be available to Tenant service

2. If the password information needs to be quickly made available to Tenant service or if the first step does not help, restart the tenant service with sudo or root privilege using 'efactl restart-service gotenant-service'

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.

1. Create EPG1 with port-property ACL on the device1

2. Create EPG2 with network-property ACL on the device1.

3. Verify on the device, ACL configurations are pushed

4. Delete both EPG1 and EPG2

5. Do show mac access-list/ show ip access-list.

MAC and IP Access-lists not removed from the device.

1. Create EPG with PP ACL on the device port/PO.

2. Manually remove the rules under the ACL from the SLX device.

3. Trigger DRC flow. Drift in the ACL rules is not identified, hence during reconciliation, the rules are not pushed to the device.

Below are the steps to reproduce the issue:

1) Manually create a monitor session on the SLX i.e. Create an OOB (Out Of Band) monitor session on SLX

2) Create Tenant and Mirror Session from EFA

Below are the steps to reproduce the issue:

1) Create Fabric

2) Create Tenant and Portchannels

3) Create Mirror Session using Portchannel as a mirror source

4) Delete fabric with force option or remove devices from inventory

1) Manually delete the EFA created Mirror Session from SLX device

2) Manually delete the EFA created Portchannels from SLX device

Below are the steps to reproduce the issue:

1) Create a Tenant and create a Mirror Session. The mirror session create disables the LLDP on the mirror destination port

2) Delete the Mirror Session created in step 1

1. Create the EPG with PP/NP ACL on the device Ports/Networks.

2. Manually delete the rule under the ACL and create another rule with the same sequence number, on the SLX device.

3. Trigger DRC.

Below are the steps to reproduce the issue:

1) Create Tenant with more than one mirror-destination-port per device

2) Create Mirror Session with Global Vlan as mirror source and an explicit mirror destination (and not auto derived mirror destination)

1) Update Tenant to delete mirror-destination ports from devices using "efa tenant update --operation mirror-destination-port-delete --mirror-destination-port <ports>" so that only one mirror-destination port per device remains in tenant

2) Create Mirror Session again with Global Vlan as mirror source and the explicit mirror destination (and not auto derived mirror destination)