Open Defects

This recovery procedure assumes multi-node EFA deployment on SLX1/TPVM1 and SLX2/TPVM2..

TPVM1 is the TPVM that was removed on SLX1, and SLX2/TPVM2 is the second device and now running active EFA.

On SLX1 perform the following steps.

1. Reinstall TPVM1 using config mode ​with the same configuration as before.

2. On SLX2/TPVM2, setup trusted peer with TPVM1. "SLX2(config-tpvm-TPVM)# trusted-peer ip TPVM1 password <password>"

3. On TPVM2, perform efa upgrade with node replacement using the following steps.

SLX2# efa deploy --graphics no

Starting "efa deploy"...

Step 1: Checking if TPVM is deployed...

Step 2: Get IP Address assigned to TPVM to deploy EFA

IP Address of the TPVM TPVM2

Step 3: Checking for EFA packages in /efaboot directory

Step 4: Deploying EFA package efa-2.5.0.tar.gz on TPVM2

Step 5: Checking for EFA Stack...

Previous Stack found

Are you sure you want to re-deploy EFA? (yes/no)

yes

Step 6: Re-deploying EFA

Would you like to configure additional IP address(es) for the HA health ping check? (yes/no)

no

Would you like to configure additional management IP networks? (yes/no)

no

Would you like to configure additional management IP network routes? (yes/no)

no

Please choose: 1 Multi Node Build Upgrade 2 Multi Node Build Upgrade With Node Replacement

2

Enter the replacement peer node (IP/Hostname):

TPVM1

TPVM1-IP server is reachable...

You have chosen:

- to redeploy EFA at version 2.5.0 build GA

- with peer TPVM1 and VIP EFA-VIP

- with node replacement

Do you wish to proceed? (yes/no)

yes

...

...

Waiting for EFA services

Waiting for EFA containers to start

Extreme Fabric Automation Stack has been upgraded successfully.

SLX2#

Once efa upgrade with node replacement is complete, verify on both nodes, efa is running and services have started using efactl status.

When the md5-password is updated on an already provisioned fabric, the existing tenant vrf backup routing bgp neighbours will be updated with the new md5-password followed by the clearing of the bgp neighbours.

Updation of md5-password and clearing of the corresponding bgp neighbors happens one SLX device at a time, hence resulting in the session being down time till the process is complete for both the devices of the MCT pair.

1. Configure fabric with the fabric setting backup routing enabled and with the md5-password fabric setting

2. Configure tenant under the fabric

3. Configure VRF and L3 EPG (using the VRF and under the ownership of the tenant), which results in the creation of the backup routing bgp neighbors (for the tenant vrf) using the md5-password provided at the fabric setting

4. Update md5-password on the already provisioned fabric followed by "fabric configure"

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

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

BGP Peer creation fails with the error "failed to fetch BgpAddressFamily data" because of the intermittent connectivity loss of EFA with SLX.

Rollback also failed leaving the stale config on SLX.

1. Create tenant, po, vrf and epg

2. Create bgp peer group

3. Create bgp peers

Create fails because of an intermittent connection issue

1. Delete the peer using force option so all stale config is removed.

2. Recreate the bgp peer

Below are the steps to reproduce the issue:

1. Create Endpoint group with ctag1, ctag2 and native vlan as ctag1

2. Update the Endpoint group (created in step 1) using ctag-range-add operation with the same set of ctags (i.e. ctag1, ctag2) and different native VLAN ctag2

Below are the steps to reproduce:

1. Create Tenant

2. Create VRF with max-path and graceful-restart-enable

3. Create EPG using VRF created in step 1

4. Take one of the SLX devices to administratively down state

5. Perform VRF Update max-path-add operation to add a different max-path value

6. Perform VRF Update graceful-restart-update to disable graceful-restart

7. Admin up the SLX device which was made administratively down in step 4 and wait for DRC to complete

Below are the steps to recover:

1. Perform VRF Update graceful-restart-update to enable graceful-restart

2. Admin up the SLX device which was made administratively down and wait for DRC to complete

3. Perform VRF Update graceful-restart-update to disable graceful-restart

In 2.4.x, adding the same ports/pos with different native vlan was allowed without any validation, this leads to two possible issues

1. Adding the same ports/PO to multiple epgs with different native-vlan VLAN results in the initial input native vlan being over written with the latest native vlan value onto the SLX

2. Adding the same port/po to multiple epgs, the first epg being created with native vlan and the second epg being created without native vlan, will result in removal of native vlan configured as part of the first epg

The same inconsistency gets carried over from 2.4.x to 2.5.0

Case1:

1. Create fabric, tenant

2. Create PO1 with Device1Port1

3. Create PO2 with Device1Port2

4. Create EPG1 with PO1, PO2, CTAG1, CTAG2 with "switchport mode trunk", and native vlan as CTAG1

5. Create EPG2 with PO2, CTAG3, CTAG4 with native vlan CTAG3

6. On the SLX, PO2 initial native vlan CTAG1 gets replaced with CTAG3, while PO1 will have the initial native vlan CTAG1

Case2:

1. Create fabric, tenant.

2. Create PO1 with Device1Port1

3. Create PO2 with Device1Port2

4. Create EPG1 with PO1, PO2, CTAG1, CTAG2 with "switchport mode trunk" and native vlan as CTAG1

5. Create EPG2 with PO2 CTAG3, CTAG4 without native vlan

6. On the SLX, PO2 initial native vlan CTAG1 gets replaced with the default value, while PO1 will have the initial native vlan CTAG1

1. Identify EPGs with common PO/port with conflicting native vlan

2. Delete conflicting ctag (that needs to be configured as native vlan but isnt configured as one) using EPG update "ctag-range-delete" operation

3. Add ctag back with correct native vlan (to be configured on SLX) using EPG update ctag-range-add" operation

network-property delete failed

When concurrent EFA tenant EPG delete operations are requested where the commands involve large number of vlans and/or ports, one of them could fail with the error "EPG network-property delete failed"

Steps to reproduce:

Create tenant and PO

Modify channel group mode on SLX

config t

interface Ethernet 0/17-18

no channel-group

channel-group 111 mode passive type standard

Update inventory

Manual DRC

Steps to reproduce:

1. Create tenant and PO

2. Modify po speed on SLX

config t

no int po 112

interface Port-channel 112

speed 100

no shutdown

3. Update inventory

4. Manual DRC

1. Create fabric and tenant.

2. Create EPG1 using CEP port.

3. Create EPG2 using the same CEP port.

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

Network and router creation during EFA HA fail-over, stale entries

Steps:

Started script/stack to create networks and routers

Did HA fail over when network/router creation was in progress

Few network and router creations failed.

EFA HA Failover during stack creation can result in failed network and router entries at OpenStack.

EFA services will be down for few minutes during HA failover, resulting in the failures.

1. Configure fabric

2. Create tenant, po, vrf and epg

3. Update fabric setting with "password$\n" and configure fabric

4. MD5 password is not configured on backup routing neighbors under BGP address family ipv4/ipv6 vrf

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.

Add the devices to fabric in following sequence

1)First add brownfield devices which have preconfigured configs

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

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

1)First add brownfield devices which have preconfigured configs

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

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

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

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

Creation of 100 Openstack VM/stacks fails at the rate of 10 stacks/min

One stack has 1 VM , 2 networks and 3 Ports (2 dhcp and one nova port)

100 openstack stacks created at the rate of 10 stacks/min are sent to the EFA.

The EFA processing requests at such high case resuts in overwhelming the CPU,

Since the EFA cannot handle requests at such high rates, backlog of requests are created. This eventually results in VM reschedules and failure to complete some stacks with errors.

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.

EPG update anycast-ip-delete operation succeeded for deletion of provisioned anycast-ip for admin-down device.

This issue is observed only if an update anycast-ip-add operation is performed after device is put in admin down state and the new config is in non-provisioned state followed by anycast-ip-delete operation for already configured anycast-ip.

Steps to reproduce issue:

1) Configure EPG with anycast-ip (ipv4/ipv6)

2) Make one device admin-down

3) Anycast-ip update-add new anycast-ip (ipv6/ipv4)

4) Update-delete provisioned anycast-ip configured in step-1 (ipv4/ipv6)

Step (4) should fail as IP is already configured on the device and trying to delete it should fail as part of APS.

Remove the devices from fabric and re-add

efa fabric device remove --name <fabric-name> --ip <device-ips>

efa inventory device delete --ip <device-ips>

efa fabric device add-bulk --name <fabric-name> --rack <rack-name> --username <username> --password <password> --ip <device-ips>

import certificate manually

efa certificates device install --ips x,y --certType