Cannot pass ipv6 packets into a VM using VFs (82599)

[SKenn2]

Hello,

Short story - cannot receive ipv6 packets in a KVM guest using SR-IOV interfaces (VF), but, ipv4 works fine.

Long Story:

Have 2 KVM VMs set up on 2 separate hosts. OS in the host and the guest is RHEL6.4. The hosts use the 82599 NICs. Have assigned a VFs to each guest (eh4/eth5) using unique mac addresses in the XML guest definition (the other interfaces in the VM are bridged interfaces). Assigned a unique VLAN to each VF per VM (eth4 is 610, eth5 is 611) using 'ip link set' commands. Using Intel provided driver ixgbe (3.15.1) on the host and ixgbevf (2.8.7) in the guest. Plumbed ipv4 and ipv6 IP in the guests for eth4 on each VM. Ping (ipv4) works fine. We can see the packet enter the NIC on the receive side host (tcpdump) and can see it in the guest too. When we repeat the process for ipv6, it fails. It leaves the guest fine, we see it hit the NIC on the received host), but it is NOT received by the guest across the VF. If we pull out the VFs and replace with bridges, ipvv6 works fine so it's not a routing/network issue.

Is there something we need to set up/configure to get ipv6 to show up in the guest?? Note we can also ping out successfully to the upstream L3 switch (subnet gateway), but not to the other VM.

Thanks,

Shawn

[SKenn2]

The issue has been found and addresses in RHEL6.5 in the ixgbe driver.

Since I wasn't getting anywhere working with Intel, I brought it to the attention of Redhat. They

worked in conjunction with HP (it was their device) and the between the two of them,

the oncovered and solved the issue.

I cannot tell you what specifically it was, but they updated the ixgbe driver (3.15.1-k) and

rolled that out in the new RHEL6.5 kernel.

I suppose it will eventually rolled out back into the base intel driver. As I stated earlier, the

multicast register was getting cleared when setting MTU size greater than 1500

bytes && SR-IOV interfaces were used.

Thanks,

Shawn

[KEgef]

Hi Patrick,

Are you able to determine when this issue will be fixed, or are we required to migrate to red hat to get this working? :-)

Thanks

Regards

Kristoffer

[KEgef]

Looks like its working in version 3.19.1 ;-)

[Patrick_K_Intel1]

Excellent! Sorry I've been quiet of late - for some reason I've not been getting notifications of updates. I'll go see what is going on and try to be more active.

- Patrick

[SKenn2]

According to the RH kernel changelog, it states:

[netdrv] ixgbe: fix inconsistent clearing of the multicast table

When googling for that, I see:

https://kernel.googlesource.com/pub/scm/linux/kernel/git/jkirsher/net-next/+/cf78959c0d7afbde31498afc4212294c28e2c278%5E%21/# F0 https://kernel.googlesource.com/pub/scm/linux/kernel/git/jkirsher/net-next/+/cf78959c0d7afbde31498afc4212294c28e2c278%5E%21/# F0

So, can someone tell me what official intel version has this fix??

[KEgef]

I believe I found something looking almost like that commit in the src code for 3.19.1 - which I have confirmed to be working, but I have not been able to find any change log for the official intel drivers...?

[Patrick_K_Intel1]

Checked with engineering, this fix will be available in an official release late Q1 or early Q2.

[AmitW]

Hello ,

I am facing the similar issue with IPv6 where neighbor discovery is not happening once we added explicit neighbor information then only the ipv6 ping works for the VF (pci-passthrough)

Here's the system details.

NIC :  FortVille Card (Ethernet Controller X710 for 10GbE SFP+)

OS : Ubuntu 16.04 LTS (kernel 4.15.0-112-generic )

Virtualization : KVM

Driver Info :

# ethtool -i ens2f1
driver: i40e
version: 2.1.14-k
firmware-version: 6.01 0x800036e4 1.1861.0
expansion-rom-version:
bus-info: 0000:03:00.1
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes

[MaryT_Intel]

Hi AmitW,

Please post a new question. You replied on a thread that's a couple years old and is not monitored anymore. Our Support Engineers will see it when you've created a new thread.

Kind regards,

Mary T.

Support Community Manager