On 31 January 2017 at 22:59, Roopa Prabhu <ro...@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: 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.
