[ovs-dev] [PATCH] ovn-northd: Skip icmp4 packets destined for router ports from conntrack

Russell Bryant russell at ovn.org
Fri Mar 10 21:48:57 UTC 2017


On Fri, Mar 10, 2017 at 2:35 PM, Russell Bryant <russell at ovn.org> wrote:
> On Thu, Mar 9, 2017 at 11:52 PM, Numan Siddique <nusiddiq at redhat.com> wrote:
>> Thanks for the review. Please see inline.
>>
>>
>> On Fri, Mar 10, 2017 at 1:44 AM, Russell Bryant <russell at ovn.org> wrote:
>>>
>>> On Mon, Feb 27, 2017 at 12:59 AM,  <nusiddiq at redhat.com> wrote:
>>> > From: Numan Siddique <nusiddiq at redhat.com>
>>> >
>>> > Presently, the icmp4 requests to the router gateway ip are sent to the
>>> > connectiont tracker, but the icmp4 reply packets responded by
>>> > 'lr_in_ip_input' stage are not sent to the connection tracker.
>>> > Also no zone ids are assigned for the router ports. Because of which
>>> > the icmp4 request packets in the connection tracker will be in the
>>> > UNREPLIED state. If the CMS has added ACLs to drop packets which
>>> > are not in ESTABLISHED state, the icmp4 replies will be dropped.
>>> >
>>> > To fix this issue, this patch adds a priority-110 flow in
>>> > 'ls_in_pre_acl'
>>> > stage which doesn't set reg0[0] = 1 for icmp4 request packets destined
>>> > to the router gateway ips.
>>> >
>>> > Alternate solution would be to assign zone ids for the router ports
>>> > and send the packets from the router ports to the connection tracker.
>>> >
>>> > The approach used in this patch seems to be simpler.
>>> >
>>> > Signed-off-by: Numan Siddique <nusiddiq at redhat.com>
>>> > ---
>>> >  ovn/northd/ovn-northd.8.xml | 29 +++++++++++---
>>> >  ovn/northd/ovn-northd.c     | 92
>>> > +++++++++++++++++++++++++++------------------
>>> >  2 files changed, 79 insertions(+), 42 deletions(-)
>>>
>>>
>>> Can you clarify where the packet gets dropped?  It seems like we have
>>> flows trying to handle this already.  We skip conntrack for the router
>>> interface ports.  Roughly, I would expect:
>>>
>>
>> The packets are getting dropped because of the flow
>>
>> table=52, n_packets=40, n_bytes=3920,
>> priority=2001,ct_state=-est+trk,ip,reg15=0x3,metadata=0x3 ac
>> tions=drop
>>
>> This flow corresponds to logical flow -
>> table=4 (ls_out_acl         ), priority=2001 , match=((!ct.est || (ct.est &&
>> ct_label.blocked == 1)) && (outport ==
>> "ce575934-f308-45b8-b9cd-457646da213d" && ip)), action=(drop;)
>>
>>
>> This logical flow is added by neutron OVN plugin when the port is configured
>> with security groups. When I clear the security groups for the port or add a
>> specific security group rule to allow icmp, it works fine.
>
> The above flow could be hit at two different points (#2 and #5 below).
> In my local testing, it looks like it's happening in #5 so at least we
> aren't hitting conntrack related flows in a part of the pipeline where
> we don't expect it.
>
>>
>>>
>>> 1) inport == lport1, logical switch ingress pipeline.  packet sent
>>> through conntrack.
>>>
>>> 2) outport == router interface port, logical switch egress pipeline.
>>> packet *skips* conntrack since it's a router interface.
>>>
>>> 3) router datapath, icmp respose generated, sent back to logical switch
>>> ...
>>>
>>> 4) inport == router interface, logical switch ingress pipeline, packet
>>> *skips* conntrack since it's a router interface
>>>
>>> 5) outport == lport1, logical switch egress pipeline, packet sent
>>> through conntrack, which should find an existing conntrack entry
>>> established in step 1.  packet delivered to lport1.
>>>
>>
>> The connection tracking entry has this
>>
>> $ sudo conntrack -L | grep 10.0.0.1
>> conntrack v1.4.3 (conntrack-tools): 54 flow entries have been shown.
>> icmp     1 29 src=10.0.0.6 dst=10.0.0.1 type=8 code=0 id=7486 [UNREPLIED]
>> src=10.0.0.1 dst=10.0.0.6 type=0 code=0 id=7486 mark=0
>> secctx=system_u:object_r:unlabeled_t:s0 zone=1 use=1
>>
>> You think this should be addressed by neutron OVN plugin ?
>
> I don't think it's a Neutron issue.
>
> I see the conntrack entry remaining in the UNREPLIED state, even in
> the working case where there's not an ACL dropping the reply.
>
> icmp     1 29 src=10.0.0.10 dst=10.0.0.1 type=8 code=0 id=25857
> [UNREPLIED] src=10.0.0.1 dst=10.0.0.10 type=0 code=0 id=25857 mark=0
> zone=8 use=1
>
> If I ping a different address (something past the logical router), I
> see a proper conntrack entry that's not in the UNREPLIED state.
>
> I wonder if there's something about how we are generating the ICMP
> response from the logical router that's making conntrack not properly
> associate it with the request?

I checked into this and there's no meaningful difference in how we
form the ICMP reply.

I'm guessing this has to do with the request and reply both going
through conntrack as a part of processing the same packet in the OVS
data path.  That's not behaving how we would expect.  I'll keep
looking next week to try to identify the root cause here, but I would
appreciate any insight others may have about the behavior we should
expect in this scenario.

-- 
Russell Bryant


More information about the dev mailing list