Open Defects

import certificate manually

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

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>

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.

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.

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.

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

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

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

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

When a bgp peer-group update operations are performed after the device is admin down, the entire config from admin up device gets deleted.

Steps to reproduce this issue:

1. Create bgp peer group

2. Admin down both devices

3. peer add fails with appropriate message

4. Admin up one of the devices

5. perform peer-group add

6. update bgp peer group to delete the peer that was created in step 1 for both devices

7. perform bgp configure operation while one of the devices is still in admin down state

After performing the configure operation when one of the devices is still down, the entire config from admin up device gets deleted.

Create a bgp peer group and then put one of the devices into admin down state.

Then perform update operation on both devices

After which perform a configure bgp peer-group operation while one of the devices are still down.

The entire config from the device which is still in admin up state gets deleted.

The peers which are in sync and configured on the switch for the admin up device must not be deleted but as the bgp peer-group goes into delete pending state, the entire config gets deleted.

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

Below are the steps to recover from the issue:

1. Delete VRF from all EndpointGroups by performing EPG Update <vrf-delete> operation

2. Add VRF to EndpointGroups by performing EPG Update <vrf-add> operation

Below are the steps to recover from the issue:

1. Delete VRF from all EndpointGroups by performing EPG Update <vrf-delete> operation

2. Add VRF to EndpointGroups by performing EPG Update <vrf-add> operation

1. Configure non-clos fabric with backup-routing enabled.

2. Configure tenant, po, lot of vrf (e.g. 50), epgs, bgp peer-group, bgp static peers.

3. Configure maintenance-mode enable-on-reboot on the SLX.

4. Update fabric setting to configure MD5 password.

5. Configure fabric created in step 1 in order to provision MD5 password on Backup Routing neighbors for all the tenant VRFs.

6. Reload SLX to trigger MM triggered DRC or trigger manual DRC, as soon as the fabric configure is complete in step 5.

7. DRC will timeout since the provisioning of MD5 password on the Backup Routing neighbours was not allowed to be completed after step 5.

1. Update MD5 password setting in fabric and configure fabric.

2. Allow MD5 password to get provisioned on all BR neighbors of all the tenant VRFs on the SLX.

3. Perform manual/auto DRC once MD5 password is provisioned.

The firmware-host is registered to use the SCP protocol and the firmware-host has an unset or default "MaxStartups" config in the /etc/ssh/sshd_config file. The default "MaxStartups" is typically "10:30:60" when the configuration is not set.

MaxStartup Configuration:

1) "Start" - 10: The number of unauthenticated connections allowed.

2) "Rate" - 30: The percent chance that the connection is dropped after the "Start" connections are reached which linearly increases thereafter.

3) "Full" - 60: The maximum number of connections after which all subsequent connections are dropped.

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

If user selects "No" when EFA asks for final confirmation before upgrade process gets started, the process gets terminated, but older stack can't be identified any longer on SLX. Checking "show efa status" reflects "EFA application is not installed. Exiting..."

However there is no functional impact on EFA setup and EFA setup continues to work properly on TPVMs with existing version.

1. Create EPG1 with PO1 and switchport mode trunk with native VLAN V1.

2. Create EPG2 with the same PO as used in step1 i.e. PO1 and new port channel PO2 . Switchport mode is configured as trunk without native VLAN.

3. Execute Manual/auto DRC .

4. Native VLAN V1 gets added as trunk VLAN to PO2, on the SLX.

1.Introduce manual drift on SLX by executing "no switchport" on port channels which are not intended to have Native VLAN as trunk VLAN.

2.Perform manual/auto DRC.

3. After DRC execution only the required VLAN members will be added to the port-channel. Native VLAN will be removed from the not intended port channels

Execute "show" commands to verify if the failed REST request was indeed completed successfully.

Re-execute the failed REST request as applicable.