-
Bug
-
Resolution: Done-Errata
-
Major
-
None
-
4.14
-
Important
-
No
-
False
-
-
When the SR-IOV Operator creates virtual functions after a node reboot there is a minimal chance of a race condition that will make the operator allocate the same MAC address on two different virtual functions
-
Bug Fix
-
In Progress
-
This is a clone of issue OCPBUGS-33137. The following is the description of the original issue:
—
Description of problem:
During startup the VFs are being assigned identical MACs &further being allocated by Multus to pods resulting in communication problem.
Version-Release number of selected component (if applicable):
with Intel E810-C nic on OCP v4.14
How reproducible:
Need to check
Steps to Reproduce:
1. configure VFs in netdevice & reboot
2. Check the boot logs or journalctl logs to see Vf being assigned same MAC
3.
Actual results:
I can see VF with duplicate MACs in sosreport. vf 1 link/ether 5e:6c:b2:9f:ba:4a brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off vf 13 link/ether 5e:6c:b2:9f:ba:4a brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust on vf 12 link/ether 22:9d:7f:36:76:d7 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off vf 36 link/ether 22:9d:7f:36:76:d7 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
Expected results:
Fs with identical MAC so the communicaton works normally
Additional info:
1) As a workaround, I have suggested them to turn off SpoofCheck & this helped them. 2) Also, I can confirm that the application pod isn't setting the MAC as their application logs doesn't have anything like that & SriovNetworks have dynamic mac assignment capability disabled. 3) We have a Slack Channel already for the issue.--> https://redhat.enterprise.slack.com/archives/C0716KYNW0H
- blocks
-
-
- Closed
-
- clones
-
-
- Closed
-
- is blocked by
-
-
- Closed
-
- is cloned by
-
-
- Closed
-
- links to
-
RHBA-2024:4468
OpenShift Container Platform 4.16.z extras update