[ovs-dev] [RFC PATCH] create vxlan device using rtnetlink interface

Thadeu Lima de Souza Cascardo cascardo at redhat.com
Thu Apr 21 16:43:19 UTC 2016


On Wed, Apr 20, 2016 at 11:38:31AM -0700, Jesse Gross wrote:
> Thanks for that analysis. I agree with you that this looks safe. I'm
> glad - there are fewer corner cases than I was expecting.
> 
> One minor comment that I noticed on the patch itself - I don't know if
> the port mapping functions are handling IPsec variants of tunnels
> correctly in all situations (or maybe are handling them by accident).
> Since both IPsec and non-IPsec ports share the same dpif_port name, we
> might get the wrong class back and then it seems like we don't handle
> the IPsec class types when converting between names and types, which
> could itself be an independent bug. Can you take a look?

Sure, I am not too familiar with the ipsec code. Looking at it, I don't see
anything really special about it. It just requires that some configuration is
available and that the ovs-monitor-ipsec daemon is running. When adding and
removing devices, the same procedure would still work. So, I don't see why we
would need to handle it specially, do you?

On the other hand, I noticed that VXLAN-GBP tunnels will have the problem of
sharing the same dpif_port name with non GBP tunnels. That means that tunnels
using different remote IPs with the same port all must be GBP or not GBP. If we
used extensions for GPE, that would also apply there. Maybe we should just add
an infix gbp and gpe, resulting in vxlan_sys_gbp_4789 and vxlan_sys_gpe_4789.
How about that?

Regards.
Cascardo.



More information about the dev mailing list