All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roopa Prabhu <roopa@cumulusnetworks.com>
To: Joe Stringer <joe@ovn.org>
Cc: netdev <netdev@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	stephen@networkplumber.org, nikolay@cumulusnetworks.com,
	Thomas Graf <tgraf@suug.ch>,
	Hannes Frederic Sowa <hannes@stressinduktion.org>,
	Jiri Benc <jbenc@redhat.com>, pravin shelar <pshelar@ovn.org>,
	David Ahern <dsa@cumulusnetworks.com>,
	hadi@mojatatu.com, Jarno Rajahalme <jarno@ovn.org>
Subject: Re: [PATCH net-next v2 2/5] vxlan: support fdb and learning in COLLECT_METADATA mode
Date: Fri, 10 Feb 2017 20:55:55 -0800	[thread overview]
Message-ID: <589E995B.9090405@cumulusnetworks.com> (raw)
In-Reply-To: <CAPWQB7GGEvpjdnU6O6XM6r8MPQGZG1CV6wYdOkX33T6Ja5jtNw@mail.gmail.com>

On 2/10/17, 8:05 PM, Joe Stringer wrote:
> On 31 January 2017 at 22:59, Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
>> @@ -1289,7 +1331,12 @@ static int vxlan_rcv(struct sock *sk, struct sk_buff *skb)
>>         if (!vs)
>>                 goto drop;
>>
>> -       vxlan = vxlan_vs_find_vni(vs, vxlan_vni(vxlan_hdr(skb)->vx_vni));
>> +       vni = vxlan_vni(vxlan_hdr(skb)->vx_vni);
>> +
>> +       if ((vs->flags & VXLAN_F_COLLECT_METADATA) && !vni)
>> +               goto drop;
>> +
>> +       vxlan = vxlan_vs_find_vni(vs, vni);
>>         if (!vxlan)
>>                 goto drop;
> Hi Roopa,
>
> We've noticed a failure in OVS system-traffic kmod test cases and
> bisected it down to this commit. It seems that it's related to this
> new drop condition here. Can you explain what's meant to be special
> about VNI 0? I can't see anything mentioned about it in RFC7348, so I
> don't see why it should be dropped.
>
> In the OVS testsuite, we configure OVS in the root namespace with an
> OVS vxlan device (which has VXLAN_F_COLLECT_METADATA set), with vni 0.
> Then, we configure a veth pair into another namespace where we have
> the other end of the tunnel configured using a regular native linux
> vxlan device on vni 0. Prior to this commit, the test worked; after
> this test it failed. If we manually change to use a nonzero VNI, it
> works. The test is here:
To be honest, I thought vni 0 was only used for the collect metadata device for lookup
of the device until a real vni was derived. and since i moved the line that got the vni from the packet
up, I ended up adding that check. Did not realize vni 0 could be valid vni in the packet.
>
> https://github.com/openvswitch/ovs/blob/branch-2.7/tests/system-traffic.at#L218
>
> Jarno also tried setting up two namespaces with regular vxlan devices
> and VNI 0, and this worked too. Presumably this is because this would
> not use VXLAN_F_COLLECT_METADATA.
yeah, that should be it.

I will send a patch in a few hours. Thanks for reporting. I am glad you ran these tests.. as I was not able to
completely verify all cases for ovs.

  reply	other threads:[~2017-02-11  4:55 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-01  6:59 [PATCH net-next v2 0/5] bridge: per vlan dst_metadata support Roopa Prabhu
2017-02-01  6:59 ` [PATCH net-next v2 1/5] ip_tunnels: new IP_TUNNEL_INFO_BRIDGE flag for ip_tunnel_info mode Roopa Prabhu
2017-02-01  6:59 ` [PATCH net-next v2 2/5] vxlan: support fdb and learning in COLLECT_METADATA mode Roopa Prabhu
2017-02-11  4:05   ` Joe Stringer
2017-02-11  4:55     ` Roopa Prabhu [this message]
2017-02-01  6:59 ` [PATCH net-next v2 3/5] bridge: uapi: add per vlan tunnel info Roopa Prabhu
2017-02-01  6:59 ` [PATCH net-next v2 4/5] bridge: per vlan dst_metadata netlink support Roopa Prabhu
2017-02-01  6:59 ` [PATCH net-next v2 5/5] bridge: vlan dst_metadata hooks in ingress and egress paths Roopa Prabhu
2017-02-02  1:23 ` [PATCH net-next v2 0/5] bridge: per vlan dst_metadata support Alexei Starovoitov
2017-02-02  1:59   ` David Ahern
2017-02-02  4:02     ` Roopa Prabhu
2017-02-02  4:04       ` Stephen Hemminger
2017-02-02  5:07         ` Roopa Prabhu
2017-02-02  5:58   ` Roopa Prabhu
2017-02-02  7:06     ` Stephen Hemminger
2017-02-02 14:33       ` Roopa Prabhu
2017-02-03  1:50 ` David Miller
2017-02-03  6:06   ` Roopa Prabhu
2017-02-03 20:21 ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=589E995B.9090405@cumulusnetworks.com \
    --to=roopa@cumulusnetworks.com \
    --cc=davem@davemloft.net \
    --cc=dsa@cumulusnetworks.com \
    --cc=hadi@mojatatu.com \
    --cc=hannes@stressinduktion.org \
    --cc=jarno@ovn.org \
    --cc=jbenc@redhat.com \
    --cc=joe@ovn.org \
    --cc=netdev@vger.kernel.org \
    --cc=nikolay@cumulusnetworks.com \
    --cc=pshelar@ovn.org \
    --cc=stephen@networkplumber.org \
    --cc=tgraf@suug.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.