Ethernet Products
Determine ramifications of Intel® Ethernet products and technologies
4862 Discussions

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

idata
Employee
6,063 Views

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 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

0 Kudos
2 Replies
Patrick_K_Intel1
Employee
4,682 Views

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.

0 Kudos
MBan
Beginner
4,682 Views

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

0 Kudos
Reply