On 10/07/17 14:03, Thadeu Lima de Souza Cascardo wrote:
On Mon, Jul 10, 2017 at 06:47:21AM -0300, Thadeu Lima de Souza Cascardo wrote:
...
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.
Thanks for the additional details, will do some more testing and report
back...
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
