Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-33137

identical MAC address being assigned to VFs during startup causing communication issue.

XMLWordPrintable

    • Important
    • None
    • CNF Network Sprint 253
    • 1
    • False
    • Hide

      None

      Show
      None
    • Hide
      * Previously, a race condition was generated after rebooting an {product-title} node that used a performance profile with a small number of reserved CPUs. This occurred because Single Root I/O Virtualization (SR-IOV) virtual functions (VFs) shared the same MAC address and any pods that used the VFs would experience communication issues. With this release, an update to the SR-IOV Network Operator config daemon ensures that the Operator checks that no duplicate MAC addresses do not exist on VFs. (link:https://issues.redhat.com/browse/OCPBUGS-33137[*OCPBUGS-33137*])
      Show
      * Previously, a race condition was generated after rebooting an {product-title} node that used a performance profile with a small number of reserved CPUs. This occurred because Single Root I/O Virtualization (SR-IOV) virtual functions (VFs) shared the same MAC address and any pods that used the VFs would experience communication issues. With this release, an update to the SR-IOV Network Operator config daemon ensures that the Operator checks that no duplicate MAC addresses do not exist on VFs. (link: https://issues.redhat.com/browse/OCPBUGS-33137 [* OCPBUGS-33137 *])
    • Bug Fix
    • Done

      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

              sscheink@redhat.com Sebastian Scheinkman
              rhn-support-adubey Akash Dubey
              Zhanqi Zhao Zhanqi Zhao
              Darragh Fitzmaurice Darragh Fitzmaurice
              Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

                Created:
                Updated:
                Resolved: