[ovs-dev] [PATCHv4] tunnel: Add layer 2 IPv6 GRE encapsulation support.
blp at ovn.org
Fri Jul 5 20:38:18 UTC 2019
On Thu, Jun 27, 2019 at 09:10:06AM -0700, Gregory Rose wrote:
> On 6/27/2019 7:51 AM, Ben Pfaff wrote:
> > On Wed, Jun 26, 2019 at 03:21:49PM -0700, Gregory Rose wrote:
> > > On 6/26/2019 11:59 AM, Ben Pfaff wrote:
> > > > On Wed, Jun 26, 2019 at 08:22:07AM -0700, William Tu wrote:
> > > > > The patch adds ip6gretap support. Tunnel type 'ip6gretap' is a layer 2 GRE
> > > > > tunnel over IPv6, carrying inner ethernet packets and encap with GRE header
> > > > > with outer IPv6 header. Encapsulation of layer 3 packet over IPv6 GRE, ip6gre,
> > > > > is not supported yet. I tested it by running:
> > > > > # make check-kernel TESTSUITEFLAGS='-k ip6gretap'
> > > > > under kernel 5.2 and for userspace:
> > > > > # make check TESTSUITEFLAGS='-k ip6gretap'
> > > > >
> > > > > Signed-off-by: William Tu <u9012063 at gmail.com>
> > > > > Signed-off-by: Eli Britstein <elibr at mellanox.com>
> > > > > Co-authored-by: Eli Britstein <elibr at mellanox.com>
> > > > > Tested-by: Greg Rose <gvrose8192 at gmail.com>
> > > > > Reviewed-by: Greg Rose <gvrose8192 at gmail.com>
> > > > Thanks for working to generalize OVS tunnel support.
> > > >
> > > > For IPv4 GRE, we use the "gre" tunnel type and then we use
> > > > options:packet_type to control whether the tunnel carries L2 or L3
> > > > packets. Is there a reason that IPv6 GRE should be different?
> > > Hi Ben,
> > >
> > > unfortunately there is a reason that ipv6 gre is different and that is
> > > because it uses the ARPHRD_IP6GRE HW type. That
> > > is not currently supported by openvswitch so the best we can do for ipv6 gre
> > > is support the L2 tap driver which uses
> > > the ARPHRD_ETHER type.
> > I think that this is really an implementation detail. Ideally, we would
> > abstract the interface provided to our users (the configuration in the
> > database, and the OpenFlow interface) from the implementation in the
> > datapath. This seems doubly true because I don't know a reason why this
> > detail of the Linux kernel datapath would extend to other datapaths such
> > as the userspace datapath.
> I agree - there is a lot we could do to improve the user interface for all
> the gre based tunnels, including
> erspan. I'll see if I can find some time to work on this. Adding
> ARPHRD_IP6GRE support to the kernel datapath
> has not been scoped yet (SFAIK) and given all the subtle dependencies that
> developed because our kernel datapath
> has only supported ARPHRD_ETHER in the past I want to express caution. But
> if L3 ip6gre support in the kernel
> datapath is important then we can look at it.
I don't think it's important to add support for ARPHRD_IP6GRE. I'm only
concerned about a consistent interface here, not about particular
More information about the dev