2 Replies Latest reply on Dec 28, 2016 12:08 AM by Minho Ban

    SR-IOV on NIC 82599: Are VF MAC Addresses unique?

    Raymond Kopa

      Hello experts,

      We are currently testing SR-IOV, and one of our concern is:

      Are the randomly generated MAC Addresses after each reboot unique from one PF to another PF (and i mean world wide)?

      I assume that on the same PF all the VFs have a different MAC Address, but if we have many SR-IOV ready NICs, aren't at risk to have a duplicate mac address in the network? Or there is a smart algorithm that generates the VF mac addresses based on the PF Mac address?

      We are also looking into the forcing of MAC Addresses, but we would like to avoid that solution, it doesn't seem stable in our environement, the dom0 detects MAC Address spoofing even though I've followed the procedure of rebooting the VM (reloading the vf driver). If i pursue this route, i read on an Intel doc that IPROUTE2 and a kernel 2.6.39+ were required, but on another documentation from intel: http://www.intel.com/content/dam/www/public/us/en/documents/technology-briefs/ethernet-x520-sr-iov-red-hat-tech-brief.pdf

      they don't mention iproute2 (just iproute) and not limit on the kernel version...

       

      Thanks in advance for your insights!

      Raymond

        • 1. Re: SR-IOV on NIC 82599: Are VF MAC Addresses unique?
          Patrick_Kutch

          Intel 82599 Ethernet Controller driver generates a random MAC address for VF at driver load time.   The random VF MAC address assigned by PF driver  can be changed by an application like Virt-Manager in RHEL after the PF driver is loaded.   Other application may change the VF MAC address at any time. 

           

          One caveat – User can use IPROUTE2 utility to assign a unique MAC address to a VF from within the host Operating System.  Once the new MAC address is assigned, VM that has this particular VF assigned to will not be able to alter its MAC address.  This is called “administratively assigned MAC” and is a security feature.

          • 2. Re: SR-IOV on NIC 82599: Are VF MAC Addresses unique?
            Minho Ban

            Hello,

             

            Quite outdated question but may I ask whether there is method to clean up the "administratively assigned MAC" with 00:00:00:00:00:00 which was initial state of VF?

            Whenever I destroy virtual machine using VF, libvirt try to reset the VF mac address with initial value but failed. Here's the log.

             

            Dec 27 12:57:13 mita-nova1 kvm: 0 guests now active

            Dec 27 12:57:14 mita-nova1 systemd-machined: Machine qemu-6-iovtest terminated.

            Dec 27 12:57:14 mita-nova1 journal: End of file while reading data: Input/output error

            Dec 27 12:57:14 mita-nova1 journal: Cannot set interface MAC/vlanid to 00:00:00:00:00:00/0 for ifname ens1f1 ifindex -1 vf 1: Invalid argument

            Dec 27 12:57:14 mita-nova1 kernel: ixgbevf 0000:05:10.3: enabling device (0000 -> 0002)

            Dec 27 12:57:14 mita-nova1 kernel: ixgbe 0000:05:00.1 ens1f1: VF Reset msg received from vf 1

            Dec 27 12:57:14 mita-nova1 journal: Failed to open file '/var/run/libvirt/qemu/ens1f1_vf1': No such file or directory

            Dec 27 12:57:14 mita-nova1 kernel: ixgbevf 0000:05:10.3: fe:ff:ff:ff:ff:ff

            Dec 27 12:57:14 mita-nova1 kernel: ixgbevf 0000:05:10.3: MAC: 1

            Dec 27 12:57:14 mita-nova1 kernel: ixgbevf 0000:05:10.3: Intel(R) 82599 Virtual Function

             

            This lead to mac address collision because the VF will be remain in previously assigned mac address. When I started new virtual machine with the other VF having that mac address then it didn't work. (when I changed the mac of the first VF, then network worked normally in the virtual machine)

             

            The host machine is running RHEL 7.3 and ixgbe version is 4.0.1-k-rh7.2. If you need any more information just let me know.

             

            Thanks and regards,

            Minho Ban