Bug 2089688

Summary:	IPv6 Neighbor Discovery doesn't work with Pod SR-IOV additional network interfaces
Product:	OpenShift Container Platform	Reporter:	Takayoshi Kimura <tkimura>
Component:	Networking	Assignee:	William Zhao <wizhao>
Networking sub component:	SR-IOV	QA Contact:	zhaozhanqi <zzhao>
Status:	CLOSED WONTFIX	Docs Contact:
Severity:	high
Priority:	high	CC:	auchida, bnemeth, cgoncalves, ddelcian, eglottma, mori, sscheink, takito, vpunj, wizhao, zshi
Version:	4.8
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	Telco: RAN
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-11-14 17:30:10 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Takayoshi Kimura 2022-05-24 09:00:57 UTC

Description of problem:

There is a IPv4 IPv6 dual stack network. IPv6 Neighbor Discovery works with VMs on this network.

However, it doesn't work with Pod SR-IOV additional network interfaces on the same network so and external clients cannot get a physical address of the Pod IPv6 addresses.

Looking at a tcpdump taken in the pod, the Neighbor Solicitation multicast packet to 33:33:XX:XX:XX:XX never reach to the SR-IOV additional network interfaces. 

Version-Release number of selected component (if applicable):

OpenShift 4.8.23
sriov-network-operator.4.8.0-202111250619

How reproducible:

Always at the customer env

Steps to Reproduce:
1. Send Neighbor Solicitation multicast packet to 33:33:XX:XX:XX:XX to query Pod IPv6 address
2.
3.

Actual results:

No Neighbor Advertisement response from the Pod, Pod doesn't see the NS packet

Expected results:

Neighbor Advertisement response from the Pod

Additional info:

Comment 5 William Zhao 2022-08-30 21:56:09 UTC

I am currently working on https://issues.redhat.com/browse/NHE-1. It is almost nearing completion.

I have been debugging this while doing development and I am able to send/receives neighbour solicitations without problems. Addresses such as ff02::1 enter my pod just fine (regardless of the fix I made). I am using Nvidia Mellanox NICs (CX-6 Lx/Dx). Do you know what NIC was the customer using? We believe the NIC might, by default, filter these multicast addresses and that is why it is not received. It would explain why the trust mode has an effect on this. Would it be possible to ping the customer on which network card they were using?

Comment 6 Takayoshi Kimura 2022-08-31 00:19:41 UTC

The NIC of the reported env is Intel E810.

Comment 7 William Zhao 2022-11-09 21:43:55 UTC

Hi Takayoshi, maybe this issue is related to BZ #2138215

Comment 8 William Zhao 2022-11-14 17:30:10 UTC

I have tested this on MLX ConnectX-5 where I had a secondary network (additional network) that was IPv6. I was able to use IPv6 successfully on that network between pods without setting trust on. I believe the issue is with the specific Intel E810 NIC/NIC driver and not specifically sriov-cni or other sriov components.

If the customer is happy with the workaround and the case is closed. I would like to close this case with the workaround. If trust on can not be used moving forward then we can reopen this case and have the Intel driver team investigate this issue.

Comment 9 Carlos Goncalves 2022-11-14 18:39:23 UTC

Related: https://bugzilla.redhat.com/show_bug.cgi?id=2140637