[ovs-dev] [PATCH RFC] netdev-linux: support lwtunnel vxlan interfaces

Jiri Benc jbenc at redhat.com
Fri Oct 2 06:22:51 UTC 2015


On Thu, 1 Oct 2015 22:19:10 -0700, Pravin Shelar wrote:
> On Thu, Oct 1, 2015 at 9:08 AM, Jiri Benc <jbenc at redhat.com> wrote:
> > This is for IPv4 only at this point. Only vxlan is recognized for now.
> >
> > The usage is as follows:
> >
> > ip l a type vxlan metadata dstport 4789
> > ovs-vsctl add-port ovsbridge vxlan0
> >
> > Now, the encapsulation can be specified using ovs-ofctl, e.g.:
> >
> > ovs-ofctl add-flow ovs0 'in_port=2 actions=set_field:2->tun_id,set_field:192.168.1.1->tun_dst,1'
> > ovs-ofctl add-flow ovs0 'in_port=1,tun_id=2 actions=2'
> >
> 
> Existing ovs-vsctl add-port command for tunnels should work with
> lwtunnel inetrfaces. So tunnel vport create needs to switch between
> compat vport and lwtunnel interface according to the kernel support.

I admit one of the intents of this patch was to provoke a discussion.
I expected a similar comment and thought about this; several things are
not clear to me:

1. Such interface would have completely different lifespan than the
   corresponding ovsdb entry. After reboot, ovsdb entry for the tunnel
   is present but not the interface. Who should create it? It can
   hardly be ovs-vswitchd, because on ovs-vswitchd restart, the
   interface is still there. Trying to recreate it if it doesn't exist
   doesn't work either because of name spaces and because there may be
   an unrelated interface with the same name but different parameters
   (port, especially) created meanwhile. Note this is very different to
   internal ports which are created by the kernel datapath.

2. How to distinguish whether the kernel supports IPv6 metadata based
   vxlan? Kernel 4.3 will include lwtunnel support but ovs IPv6 tunnel
   support will be only in 4.4. That means that under 4.3, the creation
   of the vxlan lwtunnel succeeds (and would actually do a wrong thing
   for IPv6 from the ovs point of view due to patches that are not
   going to be in 4.3), yet it won't work for IPv6.

The second point is solvable by introducing a new netlink attributes
that allow user space to query capabilities of the kernel data path.
The question is whether it's worth it, as I don't currently see any
reliable solution to the first problem.

On the other hand, delegating creation of the vxlan interface to the
user/admin/network startup scripts solves both problems. The current
way of configuration will still work, because the kernel compat nor
user space compat code is not going to go away. The current setups will
still work and those who need new features (like IPv6 support) will
need to switch to the new way of configuration, and that would be
creating the tunnel interface manually. I actually don't see any
problem with that.

But, if you have a good solution to the first problem while letting
ovs create the interface, I'm not at all opposed to it (although I'm
not sure I'll be the one to implement it).

Thanks,

 Jiri

-- 
Jiri Benc



More information about the dev mailing list