[ovs-dev] ovn: Issue in ACL stage when the dhcp reply packet is resumed

[Jarno Rajahalme]

Numan,

This seems to be the right fix. In general, recirculations due to NXT_RESUME will fail if the packet metadata is not restored prior to the packet execution.

Would you send a patch formatted by git format-patch with your Signed-off-by?

  Jarno

> On May 9, 2016, at 1:55 AM, Numan Siddique <nusiddiq at redhat.com> wrote:
> 
> 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 <nusiddiq at 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 <bschanmu at 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
>>>> dev at openvswitch.org
>>>> http://openvswitch.org/mailman/listinfo/dev
>>>> 
>>> 
>>> 
>> 
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev