From patchwork Tue Mar 14 15:21:33 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Numan Siddique X-Patchwork-Id: 738768 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from mail.linuxfoundation.org (mail.linuxfoundation.org [140.211.169.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3vjJNy4NJzz9s1h for ; Wed, 15 Mar 2017 02:21:38 +1100 (AEDT) Received: from mail.linux-foundation.org (localhost [127.0.0.1]) by mail.linuxfoundation.org (Postfix) with ESMTP id D3B28B35; Tue, 14 Mar 2017 15:21:36 +0000 (UTC) X-Original-To: dev@openvswitch.org Delivered-To: ovs-dev@mail.linuxfoundation.org Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 23835B1F for ; Tue, 14 Mar 2017 15:21:35 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-it0-f42.google.com (mail-it0-f42.google.com [209.85.214.42]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 545441AA for ; Tue, 14 Mar 2017 15:21:34 +0000 (UTC) Received: by mail-it0-f42.google.com with SMTP id w124so32745017itb.1 for ; Tue, 14 Mar 2017 08:21:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wRbCaB0jyLMClZQ8+AgZn88vzeJ488kyqYikeHQkE0Y=; b=LFHcUI5pFTDOZ9sRs7YGEJUphyhl6hy+FktHzirwM6naLECoBl7WTKMpfbMSG1uIWH zVKCxmXVehhT8F63SDQOqotN8g4HHCmsb6fqS1CSSlU9zoXUgHtmgeVArPD3uZrHXINT J1Od667XZNBS/yy1EOyIomUWJ/kjLTU1xl4FDw+b+fnSlzfUzuD3kpq0wVmYjCoKjjlx 0QjS+wS43VEdtHUSwxEV/2AytS8u9jqtrr8S4cdEFe3WHygscwiqNzco+Gdsbx82lApL nw6RlIwMzff0gapGbJi59kTSbx5ZL7ZBk2TK2TaHzNKrDrOJLeTcn81PytHTQiasvs2x 8Mfg== X-Gm-Message-State: AFeK/H1ExOG7mhtqTOwy93NYYTXzVhjypMm1wMYTf2RhFYiz2GhVIRGkqC7sKXW85OiuLjc5sRsMCG4RQdkNyBBu X-Received: by 10.36.37.84 with SMTP id g81mr399792itg.106.1489504893668; Tue, 14 Mar 2017 08:21:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.54.204 with HTTP; Tue, 14 Mar 2017 08:21:33 -0700 (PDT) In-Reply-To: References: <20170227055914.31953-1-nusiddiq@redhat.com> From: Numan Siddique Date: Tue, 14 Mar 2017 20:51:33 +0530 Message-ID: To: Russell Bryant X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Content-Filtered-By: Mailman/MimeDel 2.1.12 Cc: ovs dev Subject: Re: [ovs-dev] [PATCH] ovn-northd: Skip icmp4 packets destined for router ports from conntrack X-BeenThere: ovs-dev@openvswitch.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ovs-dev-bounces@openvswitch.org Errors-To: ovs-dev-bounces@openvswitch.org On Tue, Mar 14, 2017 at 12:57 AM, Russell Bryant wrote: > On Fri, Mar 10, 2017 at 4:48 PM, Russell Bryant wrote: > > On Fri, Mar 10, 2017 at 2:35 PM, Russell Bryant wrote: > >> On Thu, Mar 9, 2017 at 11:52 PM, Numan Siddique > wrote: > >> 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. > > I'm able to reproduce this outside of OpenStack. > > https://gist.github.com/russellb/4ab0a9641f12f8ac66fdd6822ee7789e > > This creates an OVN setup with two logical switches connected by a > logical router. > > switch d47412f9-e64a-4734-be26-80ee71ded805 (sw1) > port sw1-port1 > addresses: ["50:54:00:00:00:03 11.0.0.2"] > switch a1730d73-ccab-4f00-b748-3cafb683e9b8 (sw0) > port sw0-port2 > addresses: ["50:54:00:00:00:02 192.168.0.3"] > port sw0-port1 > addresses: ["50:54:00:00:00:01 192.168.0.2"] > router 193f68cd-4a93-4a04-ad3b-3ddf7b5c66f3 (lr0) > > The ping commands at the end demonstrate the problem. My expectation > is that the very last ping command should be successful, but is not > due to the issue we're seeing here. > > This issue seems to be fixed with the below code diff. From my observation, I could see that when the router datapath generates the icmp response and when the reply packet hits the ovs_ct_execute function in datapath - the "sw_flow_key - key" param has old conntrack values - in the function "__ovs_ct_lookup", skb_nfct_cached(net, key, info, skb) returns false. - and the state is not set with the flag- OVS_CS_F_ESTABLISHED. I want to check, if this is the right fix and get your feedback before sending the upstream patch to net-next. >************************************************< * for packets for which it makes sense. Otherwise the key may be * corrupted due to overlapping key fields. >************************************************< Thanks Numan ​ > -- > Russell Bryant > diff --git a/datapath/flow.c b/datapath/flow.c index 2bc1ad0..2c59acd 100644 --- a/datapath/flow.c +++ b/datapath/flow.c @@ -845,6 +845,8 @@ int ovs_flow_key_extract_userspace(struct net *net, const struct nlattr *attr, if (err) return err; + ovs_ct_fill_key(skb, key); + /* Check that we have conntrack original direction tuple metadata only