We're asking the following questions to evaluate whether or not OCPBUGS-30256 warrants changing update recommendations from either the previous X.Y or X.Y.Z.

Which 4.y.z to 4.y'.z' updates increase vulnerability?

• RHEL8 to RHEL9. Basically all upgrades from 4.12 to 4.13
• This would affect any OCP cluster that uses multiple eth interfaces with the same MAC address, which is the case with Azure Accelerated Networking enabled

Which types of clusters?

• If nodes in the cluster contain multiple NICs with the same MAC address but different drivers, which is the case whenever Azure Accelerated Networking is enabled. Accelerated Networking is the default in ARO and OCP since 4.12.

What is the impact? Is it serious enough to warrant removing update recommendations?

• In ARO the race condition could cause a rebooted node's resolv.conf file to become empty. This, among other things, prevents the node from resolving the api-int hostname so that nodes achieve Ready state. There are a set of MachineHealthChecks that replace workers which are NotReady for 15 minutes or more, however the replacement nodes may encounter the same problem.
• In OCP the contents of /etc/resolv.conf propagated from DHCP are sufficient to resolve api-int, therefore there's only a one minute delay in achieving Ready state.

How involved is remediation?

• If you already upgraded and need to recover, you need to delete the respective .link file and reboot the node.
• MachineHealthChecks could automatically replace nodes which fail to achieve Ready state, however the replacement nodes may encounter the same problem.
• KCS article (unpublished) https://access.redhat.com/solutions/7059250

Is this a regression?

• Kinda yes, kinda no.
  Without `persist-nic-names` feature after upgrading RHEL8 to RHEL9 NICs can be renamed and stuff stops to work.
  With `persist-nic-names` feature after upgrading RHEL8 to RHEL9, from all of the NICs with duplicated MAC address one will persist its name and others will be in an undefined state.