Customer traffic to a VF on a SRIOV port is QinQ double tagged. Traffic is being dropped at the VF interface. Network traffic to VF as single vlanid tagged works as expected At compute node SRIOV ports Physical server is HP DL 380 G9, SRIOV physical NIC is Intel x710 Behaviour occurs when sending double tagged traffic for the VF interface Compute host SRIOV VF unable to receive QinQ double tagged traffic as expected. Some more details on our environment: - Compute node deployed in OSP 10 {not generic KVM in article} - Compute node is running RHEL 7 {not RHEL 6 in article} - Compute nodes are running Intel x710 network interfaces {not 82599 in article} - Dual tagged traffic is being sent to the host VF {rather than the guest tagging the traffic in article} So question is - can SRIOV VF port work with "QinQ / 802.1ad double tagged" to a compute node running RHEL 7 using an Intel x710 NIC Our environment is a DPI application running in the Openstack instance VM. The DPI application needs to receive all traffic via the SRIOV port, and does not tag traffic inside the VM. Effectively a "port mirror" if you like. The traffic is already QinQ when it arrives on the PF on the actual NIC. We do not wish to add, nor remove any tags. We simply wish to pass the input frame "raw" from the NIC PF to the VF and into the VM (as VM's "eth0") When the VM goes promisc on it's eth0 (which is the SRIOV VF thats exposed to the VM), It should see everything that came in the physical NIC port.
A crucial part of the request that is missing is that the expectation is that instead of dropping the double tagged traffic, it will be propagated into the instance (with no tags stripped) where the VIF will be set to promiscuous mode. It sounds like the ask here is to support vlan_transparent API extension for SR-IOV ports. I added a link to Launchpad RFE for Neutron that seems to ask for the same.
Also to clarify, this is an RFE, a new feature request, and so it needs to go through proper planning phase for a next release.
This is verified - details - https://projects.engineering.redhat.com/browse/NFV-343
Closing EOL, OSP 15 has been retired as of Sept 19, 2020