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.
next prev parent 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$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=dsa@cumulusnetworks$(echo .)com \
--cc=hadi@mojatatu$(echo .)com \
--cc=hannes@stressinduktion$(echo .)org \
--cc=jarno@ovn$(echo .)org \
--cc=jbenc@redhat$(echo .)com \
--cc=joe@ovn$(echo .)org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=nikolay@cumulusnetworks$(echo .)com \
--cc=pshelar@ovn$(echo .)org \
--cc=stephen@networkplumber$(echo .)org \
--cc=tgraf@suug$(echo .)ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox