Defects Closed with Code Changes

1.Fabric devices are already in cfg-refresh-err state due to LLDP Link down(LD) event.

2. Bring up the LLDP links responsible for the fabric devices to be in cfg-refresh-err state.

3. Execute the TPVM failover by 'tpvm stop' and 'tpvm start' commands during the LLDP Link up (LA) event handling caused by 2.

1The user triggers LD/LA event by flapping the interface links which are the devices are in the cfg-refreshed state even though DRC wouldn't help out to recover the device to the cfg-sync state and the pending reason is "LA/LD".

1.1. "shutdown" the interface link on the physical link on Devices follow by "efa inventory device udpate --ip <device-ip>", which generates LD events

21.. "no shutdown" the interface link on the physical link on Devices follow by "efa inventory device udpate --ip <device-ip>", which generates LA events

1.3. If the pending config contains "LA" : Execute "efa inventory drift-reconcile execute --ip <device-ip> --reconcile" on the devices which are in cfg-refresh-err /cfg-refreshed state [or] IF the pending config contains "LD,LA" : Execute "efa fabric configure --name <fabric-name>" to clean up the configuration on devices which are in cfg-refresh-err /cfg-refreshed state.

[OR]

2. The user reboots the devices without maintenance mode which are the devices are in cfg-refreshed state even though DRC wouldn't help out to recover the device to the cfg-sync state.

2.1. "reload" the switches without out maintenance mode to enable

2.2. Execute "efa inventory drift-reconcile execute --ip <device-ip> --reconcile" on the devices which are in cfg-refresh-err /cfg-refreshed state.

After changing DNS nameservers in /etc/netplan and running the

update-dns.sh --dns-action allow, the following error is seen:

(efa:ubuntu)ubuntu@efa:/opt/efa$ sudo /opt/efa/update-dns.sh

/opt/efa/update-dns.sh Usage:

--help - Show this message

--dns-action <'allow'|'disallow'> - Allow host DNS entries to be forwarded

to the pods

(efa:ubuntu)ubuntu@efa:/opt/efa$ sudo /opt/efa/update-dns.sh --dnsaction

allow

Unexpected nameserver entry of 127.0.0.53 found in /etc/resolve.conf

(efa:ubuntu)ubuntu@efa:/opt/efa$

In 18.04.6 and 20.04, Ubuntu uses a stub-resolv.conf located in /run/

systemd/resolve/stub-resolv.conf . This file is symlink to /etc/resolv.conf

in /run/systemd/resolve/.

There is another file, resolv.conf which contains the information for DNS

from netplan.

Additionally, systemd-resolved provides a local DNS stub listener on IP

address 127.0.0.53 on the local loopback interface. Programs issuing

DNS requests directly,bypassing any local API may be directed to this

stub, in order to connect them to systemd-resolved.

Note: The best practice is for local programs to use the glibc NSS or

bus APIs instead (as described above), as various network resolution

concepts (such as link-local addressing, or LLMNR Unicode domains)

cannot be mapped to the unicast DNS protocol.

We do not recognize the 127.0.0.53 address as valid.

If updating DNS to allow host entries to be forwarded to the pods using the update-dns.sh script in XCO-3.3.0 on Ubuntu 20.0.4 or 18.0.4-6 or above, follow these steps.

20.0.4 or 18.0.4-6 or above, follow these steps:

After netplan is applied and before running update_dns.sh

1. Check if symlink exists, if not directly edit /etc/resolv.conf to netplan

ip

$ ls -l /etc/resolv.conf

lrwxrwxrwx 1 root root 39 Feb 20 2021 /etc/resolv.conf -> ../run/

systemd/resolve/stub-resolv.conf <<<symlink exists

sbr@sbr-virtual-machine

~ $

2. Check if it has 127.0.0.53 ip in below files:

~ $ cat /etc/resolv.conf | grep nameserver

nameserver 127.0.0.53

sbr@sbr-virtual-machine

~ $ cat /run/systemd/resolve/stub-resolv.conf | grep nameserver

nameserver 127.0.0.53

sbr@sbr-virtual-machine

~ $

3. Edit the following file to add netplan ip for the nameserver and

remove 127.0.0.53

sudo vi /run/systemd/resolve/stub-resolv.conf

4. Check if both files are updated.

~ $ cat /run/systemd/resolve/stub-resolv.conf | grep nameserver

nameserver 10.10.10.0

sbr@sbr-virtual-machine

~ $ cat /etc/resolv.conf | grep nameserver

nameserver 10.10.10.0

sbr@sbr-virtual-machine

~ $

5. Run update_dns.sh --dns-action allow.

6. Run sudo netplan apply to restore /etc/resolv.conf and /run/systemd/

resolve/stub-resolv.conf to its default value of 127.0.0.53.

The "Firmware Activate" process is initiated from the user interface, either through the Inventory Page or the Fabric-wide Page, even in the midst of an incomplete operation on a subset of devices.

For instance:

Device 1 and Device 2 trigger a download with auto-commit enabled from either the Inventory or Fabric-wide Page.

Device 3 triggers a download from the Fabric or Inventory Page.

Subsequently, Device 1 and Device 2 attempt to continue with the "Activate Download" operation from the inventory or fabric page, resulting in a "Firmware Commit Failed" failure.

When db error occurs in Rbac during initialization, then return gracefully.

Allowing Rbac to do re-initialization.

Earlier we were not returning when Db is unavailable/down, hence it was failing to load policies.

Thus, not able to resolve permissions to run command.

There are multiple issues observed when oob static routes are added. (a) When null route is added, inventory table is populated with wrong interface name - tengigabitethernet 0, (b) published vrfupdate event does not contain interface name and nexthoptype value is set to invalid value - 0, (c) when tenant reads the event it writes incomplete information in its db and (d) Tenant does not know how to read back the incomplete back properly.

1. Remove the static-routes from the vrf config in the device.
2. Update the tenant db vrf_static_route to delete the corresponding stale records (oob_created=1 and nh_type = 0).
3. Create the previously failing new epg-s and confirm that they succeed.
4. Re-add the static-routes in the vrf config in the device.

Go to table action and select Firmware Upgrade option.

Error is observed while updating EFA system CLI setting

Error : error creating directory on remote: Could not chdir to home directory /users/home21/<username>: No such file or directory

The monitor process is making rest calls to Inventory every 2 seconds to see if the backup is done yet and after 3 minutes monitor claims failure.

Setting the completion timeout greater than the netconf timeout which is 4 minutes and 50 seconds, so that the monitor won't have false positive failure messages.

1. Configure fabric.
2. Enable IPv6-Prefix over IPv4-Peer device setting from inventory CLI.
3. Remove device from fabric or delete entire fabric.
4. Add device back in fabric or re-configure fabric.

   Performing Step 4 doesn't configure IPv6-Prefix over IPv4-Peer setting on device and Inventory service keep on identifying drift for the same.

1. Create route-map stanza
2. Configure it on the device
3. Create BGP peer and peer-group with route-map binding
4. Delete the route-map with --seq all

Data corruption:

There is no mapping of anycast-ip with VE port in endpoint_group_network_properties_ip table for select VE ports (3 out of 20 to be exact). Instead, a NULL value was seen in device_id and device_port_ip_id column. This is normally done only when port-group-delete is executed, not otherwise.

Root cause:

there are other associated epg pord's anycast configs marked as deleted in XCO's database. This causes XCO to attempt to prepare configuration for these ports as well, as part of port-gruop-add use case. This use case has a bug in Tenant software and causes a non-fatal panic. this has cascaded to the actual issue customer faced.

System backup was failing due to error in decrypting the password.

Hence unable to do scp to remote host.

1. Create route-map stanza.
2. Configure it on the device.
3. Create BGP peer and peer-group with route-map binding.
4. Update route-map with operation remove-device.

1. Create prefix-list.
2. Create route-map.
3. Create route-map-match and associate prefix created in Step 1 with route-map created in Step 2.
4. Associate/advertise prefix-list/route-map in bgp peer-group.
5. Delete or Remove Prefix-list from Device created in Step 1.