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:
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?
The NIC of the reported env is Intel E810.
Hi Takayoshi, maybe this issue is related to BZ #2138215
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.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2140637