The below fix is resolving the issue. But I am not sure if that's the right solution. May be the packet metadata should also be saved in "struct ofputil_packet_in" in "emit_continuation()".
--- ofproto/ofproto-dpif.c | 1 + 1 file changed, 1 insertion(+) diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c index a1e0407..00369b6 100644 --- a/ofproto/ofproto-dpif.c +++ b/ofproto/ofproto-dpif.c @@ -4399,6 +4399,7 @@ nxt_resume(struct ofproto *ofproto_, struct dp_packet packet; dp_packet_init(&packet, pin->public.packet_len); dp_packet_put(&packet, pin->public.packet, pin->public.packet_len); + pkt_metadata_from_flow(&packet.md, &pin->public.flow_metadata.flow); struct flow headers; flow_extract(&packet, &headers); -- Thanks Numan On Fri, May 6, 2016 at 6:35 PM, Numan Siddique <nusid...@redhat.com> wrote: > > 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