Thanks Babu for your comments. I am seeing the problem even if NXM_OF_IN_PORT is not set to zero after the packet is resumed.
The issue is that a resumed packet is getting dropped when it executes the action 'OFPACT_CT'. 'xlate_lookup()' is failing in the 'upcall_receive()' Ben, if you want to reproduce the issue you can run the below commands Thanks Numan ----------------------------------------------------------------------- BRIDGE=ovs-test ovs-vsctl add-br $BRIDGE ovs-ofctl add-flow $BRIDGE "table=0,priority=1000,actions=controller(pause), resubmit(,1)" ovs-ofctl add-flow $BRIDGE "table=1,priority=1000,ip, actions=ct(table=2,zone=1)" ovs-ofctl add-flow $BRIDGE "table=1,priority=1000,arp, actions=FLOOD" ovs-ofctl add-flow $BRIDGE "table=2,priority=1000,actions=ct(commit,zone=1),resubmit(,3)" ovs-ofctl add-flow $BRIDGE "table=3,priority=1000,actions=NORMAL" ip netns add ns1 ip netns add ns2 ovs-vsctl add-port $BRIDGE tap1 -- set Interface tap1 type=internal ip link set tap1 netns ns1 ip netns exec ns1 ip link set dev tap1 up ip netns exec ns1 ip addr add 10.0.0.2/24 dev tap1 ovs-vsctl add-port $BRIDGE tap2 -- set Interface tap2 type=internal ip link set tap2 netns ns2 ip netns exec ns2 ip link set dev tap2 up ip netns exec ns2 ip addr add 10.0.0.3/24 dev tap2 # start ovs-ofctl monitor on $BRIDGE in another shell ovs-ofctl monitor $BRIDGE resume ip netns exec ns1 ping -c 1 10.0.0.3 ------------------------------------------------- On Thu, May 5, 2016 at 5:36 PM, Babu Shanmugam <bscha...@redhat.com> wrote: > Numan, > It happens because flow chain is paused at the DHCP flow and while > resuming, the inport is set 0. When the packet traverse down the pipeline, > while processing an upcall for conntrack in the 49th table, a lookup for DP > inport 0 is performed and could not be found. Hence, it was not able to > proceed further. > > I think using packet-out with necessary actions in the userdata for packet > traversal would be better. We can use logical flow syntax such as > "output(inport)" to imply that the response is a packet-out to the inport > from which packet came. Suggestion are welcome. > > Thank you, > Babu > > > On Wednesday 13 April 2016 09:23 PM, Numan Siddique wrote: > >> Hi, >> >> I am seeing an issue while testing the ovn native dhcp implementation. >> >> When the dhcp reply packet from ovn-controller is resumed by ovs-vswitchd, >> the packet is getting dropped in the egress pipeline - ACL stage. >> >> I see the below messages in the vswitchd.log >> >> ------------------ >> 2016-04-13T14:14:03.813Z|00002|ofproto_dpif_upcall(handler1)|INFO|received >> packet on unassociated datapath port 0 >> >> 2016-04-13T14:14:03.860Z|00001|ofproto_dpif_upcall(revalidator2)|WARN|Failed >> to acquire udpif_key corresponding to unexpected flow (Invalid argument): >> ufid:a33e557f-369f-404e-aefb-2e3da678b09a >> ------------------------ >> >> >> In the function upcall_receive(), I could see that xlate_lookup() is >> returning error. >> >> Also I could see that in the function odp_flow_key_to_flow__() >> L5191, nl_attr_get_odp_port(attrs[OVS_KEY_ATTR_IN_PORT]) is returning 0. >> >> >> Please let me know if you need further information. >> >> Thanks >> Numan >> _______________________________________________ >> dev mailing list >> d...@openvswitch.org >> http://openvswitch.org/mailman/listinfo/dev >> > >
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
