On 10/07/17 11:47, 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.
I do not think its a non-supported configuration, as you could have a
non-GBP VNI (key) and a GBP VNIconfigured on the same UDP port.
The only problem I see, (looking at it again) is with the key=flow
option. An installed rule could use a VNI (key) setup for a (non-)GBP
interface. For example with the following configuration:
$ ovs-vsctl add-port br0 p1 -- set Interface p1 type=vxlan \
options:key=1 options:remote_ip=flow ofport_request=1
$ ovs-vsctl add-port br0 p2 -- set Interface p2 type=vxlan \
options:key=flow options:remote_ip=flow options:exts=gbp \
ofport_request=2
If an OF rules egressing p2 uses 1 as the key it will be dropped
by the remote site as its expecting a non GBP.
The patch will prevent a configuration like the one above, however
I could not find any reference in the RFC that this is an invalid
configuration, i.e. having GBP and non-GBP VXLAN sessions multiplexed
on the same UDP port based on the VNI value.
The only problem I have with applying this patch is that existing
configurations (that are working) will fail.
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
