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

[Numan Siddique]

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
>>
>
>