On Mon, Jul 10, 2017 at 06:47:21AM -0300, Thadeu Lima de Souza Cascardo wrote:
> On Mon, Jul 10, 2017 at 10:19:49AM +0200, Eelco Chaudron wrote:
> > On 07/07/2017 08:32 PM, Ben Pfaff wrote:
> > > On Fri, Jun 09, 2017 at 11:09:08AM +0200, Eelco Chaudron wrote:
> > > > This is a follow up patch for an earlier patch send by Cascardo,
> > > > however I think this patch might not be needed...
> > > > 
> > > > This patch will make sure VXLAN tunnels with and without the group
> > > > based policy (gbp) option enabled can not coexist on the same
> > > > destination udp port.
> > > > 
> > > > However the interface ports for VXLAN have to be unique on the same
> > > > destination port, i.e. they need a different VNI. Looking at the
> > > > datapath code (only Linux seems to support this), this is not a
> > > > problem for the ingress/egress path. For egress based on the
> > > > configuration the correct header is build. For ingress, if gbp is not
> > > > configured and a gbp VXLAN is received the packet is dropped. If gbp
> > > > is enabled and a non gbp packet is received its accepted (meaning
> > > > default group policy as per the draft rfc).
> 
> But, then, it does not go through the non-GBP configured vport, does it?
> So any flows configured for the non-GBP port are ignored. Doesn't it at
> least cause user confusion? I'd say it's a non-supported configuration,
> and OVS should just not allow it.
> 
> Cascardo.

You also have to consider whether ovs will configure the vxlan device to
have either GBP flag set or not. At least, this is a "bug" you should
take care of. And as ovs names its vxlan devices vxlan_sys_<port>, iirc,
it would fail to create one of the ports as the devices already existed.
If you really believe it should just work, then you might still want to
"merge" these concomitant ports and use the superset of the flags for
them.

Also, take note that this was work that was done in the GPE context, so
expecting that whatever affected GBP would also affect GPE. If you
demonstrante this works fine for GBP, maybe it doesn't for GPE, and you
might want to consider implementing this anyway, but using a test for
"conflicting" flags.

>From what I remember, whenever configuring two ports with conflicting
flags (one GBP and one non-GBP), OVS would not alert of any failure, but
one of the ports would not work, aka, receive any packets.

Regards.
Cascardo.

> 
> > > > 
> > > > Can some one that worked more in depth on the VXLAN side confirm this
> > > > patch can be tossed in the bin? If I missed some specific
> > > > configuration / use case why it is needed, please review the patch.
> > > > 
> > > > Signed-off-by: Eelco Chaudron <[email protected]>
> > > I've read this commit message a few times and I'm still not confident
> > > that I understand.  Let me restate it and you can correct me if I'm
> > > wrong.  I *think* that you are saying that the Linux datapath handles
> > > GBP and non-GBP tunnels that are otherwise the same in a sensible way,
> > > so that there is no need to add code to reject them.  Is that right?
> > > 
> > > Thanks,
> > > 
> > > Ben.
> > Hi Ben,
> > 
> > Yes your summary is correct! I was just wondering if I missed something
> > that does require this fix to be added.
> > 
> > Cheers,
> > 
> > Eelco
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to