Some PING packet is lost when a Geneve packet with 8021.q VLAN tag is received on OVS Windows kernel

[twofish197]

In one typical setup, on the Windows VM running OVS Windows Kernel(2.14/2.15 version), a Geneva packet with 8021.q VLAN tag is received. Then it will do POP_VLAN processing in Actions.c, if the packet does not have Ieee8021QNetBufferListInfo in the oob of the packet, it will be processed by function OvsPopVlanInPktBuf() then. In the function It will go on remove VLAN header present in the nbl, but related layers is never readjusted for the offset value in the function. As a result, it will cause function OvsValidateIPChecksum drop the packet.

 if (NET_BUFFER_LIST_INFO(ovsFwdCtx.curNbl,
                                 Ieee8021QNetBufferListInfo) != 0) {
            NET_BUFFER_LIST_INFO(ovsFwdCtx.curNbl,
                                 Ieee8021QNetBufferListInfo) = 0;
        } else {
            /*
             * The VLAN tag is inserted into the packet buffer. Pop the tag
             * by packet buffer modification.
             */
            status = OvsPopVlanInPktBuf(&ovsFwdCtx);
            if (status != NDIS_STATUS_SUCCESS) {
                dropReason = L"OVS-pop vlan action failed";
                goto dropit;
            }
        }

[twofish197]

Why this issue will not always happen, it is observed only the packet with 8021.q vlan tag which has missed the flow in the OVS kernel will have this issue. It will be upcall to OVS user space, then OVS Windows kernel gets back the flow and packet handling in function OvsExecuteDpIoctl. It will create one new nbl but related Ieee8021QNetBufferListInfo is missed for the packet. So it will cause this issue. If the packet with VLAN tag is received via miniport driver it does have the Ieee8021QNetBufferListInfo in the oob of the packet, if it could be hitting some flow in the OVS Windows kernel, it will be output to the correct port without issue.

[aserdean]

Can you provide a way to reproduce the issue (i.e. configuration, flows and pcap file)?

[aserdean]

Closed via df6ba9f09afc1bd1fadbd08fde950f45461b956a