[ovs-dev] ovs-vswitchd is dropping packets injected by controller during upcall

[Numan Siddique]

Hi Ben,

Its regarding the issue I mentioned in yesterday's meeting.

What's the issue:
-------------------
 - ovs-vswitchd is dropping packet during upcall - if the packet was
generated by ovn-controller (or any controller) with in_port  set to
OFPP_CONTROLLER.
- This normally happens when there are ct actions in the flow pipeline.

To overcome this issue in ovn-controller we try to by pass such
packets from conntrack.

We see the below logs when ovs-vswitchd drops the packets

*******
2020-03-13T10:24:08.177Z|00001|ofproto_dpif_upcall(handler42)|INFO|received
packet on unassociated datapath port 4294967295
2020-03-13T10:24:08.547Z|00001|ofproto_dpif_upcall(revalidator47)|WARN|Failed
to acquire udpif_key corresponding to unexpected flow (Invalid
argument): ufid:4cfb6038-4747-48db-ada5-113948cf5b2d
*******

The issue can be reproduced with the below commands

*************************
ovs-vsctl add-br br0
ovs-vsctl add-port br0 p1 -- set interface p1 type=internal
ovs-vsctl add-port br0 p2 -- set interface p2 type=internal

cat << EOF > flows.txt
table=0,in_port=1 actions=resubmit(,1)
table=1,ip actions=mod_dl_dst:83:83:83:83:83:83,ct(table=2)
table=2,ip,actions=ct(commit),output:2
EOF

ovs-ofctl del-flows br0
ovs-ofctl add-flows br0 flows.txt
ovs-ofctl -O OpenFlow13 -P standard monitor br0 --detach --no-chdir --pidfile

ovs-appctl -t ovs-ofctl ofctl/packet-out "in_port=controller
packet=ffffffffffff00102030405008004500001c00000000401100000a000002ffffffff0035111100080000
actions=resubmit(,1)"
sleep 1
ovs-ofctl dump-flows br0
ovs-appctl -t ovs-ofctl ofctl/packet-out "in_port=1
packet=ffffffffffff00102030405008004500001c00000000401100000a000002ffffffff0035111100080000
actions=resubmit(,1)"
sleep 1
ovs-ofctl dump-flows br0
****************************

In the first packet out with in_port=controller, the packet is not
delivered to port 2. When as in the second packet out with in_port=1,
the packet gets delivered to port 2.

You can reproduce this issue either with sandbox or kernel datapath.
However with sandbox, I didn't see the log messages which I mentioned
above.

I hope this helps in reproducing the issue.

Thanks
Numan