On 2/10/17, 8:05 PM, Joe Stringer wrote: > 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: 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.
