| Message ID | 1561562527-54784-1-git-send-email-u9012063@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [ovs-dev,PATCHv4] tunnel: Add layer 2 IPv6 GRE encapsulation support. | expand |
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@gmail.com> > Signed-off-by: Eli Britstein <elibr@mellanox.com> > Co-authored-by: Eli Britstein <elibr@mellanox.com> > Tested-by: Greg Rose <gvrose8192@gmail.com> > Reviewed-by: Greg Rose <gvrose8192@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? That is, why not just have an "ip6gre" type and then use options:packet_type to control what packets flow through it? (Actually, is there a reason why we should have a separate ip6gre at all? That is, why not just use "gre" and then control whether the outer protocol is IPv4 or IPv6 based on whether the local and remote IPs are IPv4 or IPv6?) Thanks, Ben.
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@gmail.com> >> Signed-off-by: Eli Britstein <elibr@mellanox.com> >> Co-authored-by: Eli Britstein <elibr@mellanox.com> >> Tested-by: Greg Rose <gvrose8192@gmail.com> >> Reviewed-by: Greg Rose <gvrose8192@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. Thanks, - Greg > That is, > why not just have an "ip6gre" type and then use options:packet_type to > control what packets flow through it? > > (Actually, is there a reason why we should have a separate ip6gre at > all? That is, why not just use "gre" and then control whether the outer > protocol is IPv4 or IPv6 based on whether the local and remote IPs are > IPv4 or IPv6?) > > Thanks, > > Ben. > _______________________________________________ > dev mailing list > dev@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
On 6/27/2019 1:21 AM, 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@gmail.com> >>> Signed-off-by: Eli Britstein <elibr@mellanox.com> >>> Co-authored-by: Eli Britstein <elibr@mellanox.com> >>> Tested-by: Greg Rose <gvrose8192@gmail.com> >>> Reviewed-by: Greg Rose <gvrose8192@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. > > Thanks, > > - Greg > >> That is, >> why not just have an "ip6gre" type and then use options:packet_type to >> control what packets flow through it? >> >> (Actually, is there a reason why we should have a separate ip6gre at >> all? That is, why not just use "gre" and then control whether the outer >> protocol is IPv4 or IPv6 based on whether the local and remote IPs are >> IPv4 or IPv6?) Hi Ben, I had a similar comment in https://mail.openvswitch.org/pipermail/ovs-dev/2019-June/359940.html The pro points are clear. The cons are that there are already "ip6erspan" separately from "erspan" (unless we do the same work to unite them too). Regarding "ip6gre" vs "ip6gretap", I thought it might be confusing as the type of the netdev is "ip6gretap" (for L2) and there is "ip6gre" type for L3. In IPv4 case, it is like this too ("gre"/"gretap", but there is support for both, so "gre" is more user friendly). In IPv6 case, as William and Greg commented, L3 over IPv6 GRE is not supported (at least yet). >> >> Thanks, >> >> Ben. >> _______________________________________________ >> dev mailing list >> dev@openvswitch.org >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fmailman%2Flistinfo%2Fovs-dev&data=02%7C01%7Celibr%40mellanox.com%7C5f70d74ebb2c4957c34608d6fa84b125%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636971845154020240&sdata=31JdQkU5nYWoEadDd%2BfY7uVJREAy%2BXgsbsGl%2BS9hOlk%3D&reserved=0 >> >
On Wed, Jun 26, 2019 at 11:31 PM Eli Britstein <elibr@mellanox.com> wrote: > > > On 6/27/2019 1:21 AM, 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@gmail.com> > >>> Signed-off-by: Eli Britstein <elibr@mellanox.com> > >>> Co-authored-by: Eli Britstein <elibr@mellanox.com> > >>> Tested-by: Greg Rose <gvrose8192@gmail.com> > >>> Reviewed-by: Greg Rose <gvrose8192@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. > > > > Thanks, > > > > - Greg > > > >> That is, > >> why not just have an "ip6gre" type and then use options:packet_type to > >> control what packets flow through it? > >> > >> (Actually, is there a reason why we should have a separate ip6gre at > >> all? That is, why not just use "gre" and then control whether the outer > >> protocol is IPv4 or IPv6 based on whether the local and remote IPs are > >> IPv4 or IPv6?) > > Hi Ben, > > I had a similar comment in > https://mail.openvswitch.org/pipermail/ovs-dev/2019-June/359940.html > > The pro points are clear. The cons are that there are already > "ip6erspan" separately from "erspan" (unless we do the same work to > unite them too). Regarding "ip6gre" vs "ip6gretap", I thought it might > be confusing as the type of the netdev is "ip6gretap" (for L2) and there > is "ip6gre" type for L3. In IPv4 case, it is like this too > ("gre"/"gretap", but there is support for both, so "gre" is more user > friendly). In IPv6 case, as William and Greg commented, L3 over IPv6 GRE > is not supported (at least yet). > Or do we want to add support for ip6gre (L3)? So we can use "ip6gre" and packet_type option to select L2 or L3. --William
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@gmail.com> > > > Signed-off-by: Eli Britstein <elibr@mellanox.com> > > > Co-authored-by: Eli Britstein <elibr@mellanox.com> > > > Tested-by: Greg Rose <gvrose8192@gmail.com> > > > Reviewed-by: Greg Rose <gvrose8192@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.
On Thu, Jun 27, 2019 at 06:31:24AM +0000, Eli Britstein wrote: > > On 6/27/2019 1:21 AM, 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@gmail.com> > >>> Signed-off-by: Eli Britstein <elibr@mellanox.com> > >>> Co-authored-by: Eli Britstein <elibr@mellanox.com> > >>> Tested-by: Greg Rose <gvrose8192@gmail.com> > >>> Reviewed-by: Greg Rose <gvrose8192@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. > > > > Thanks, > > > > - Greg > > > >> That is, > >> why not just have an "ip6gre" type and then use options:packet_type to > >> control what packets flow through it? > >> > >> (Actually, is there a reason why we should have a separate ip6gre at > >> all? That is, why not just use "gre" and then control whether the outer > >> protocol is IPv4 or IPv6 based on whether the local and remote IPs are > >> IPv4 or IPv6?) > > Hi Ben, > > I had a similar comment in > https://mail.openvswitch.org/pipermail/ovs-dev/2019-June/359940.html > > The pro points are clear. The cons are that there are already > "ip6erspan" separately from "erspan" (unless we do the same work to > unite them too). Regarding "ip6gre" vs "ip6gretap", I thought it might > be confusing as the type of the netdev is "ip6gretap" (for L2) and there > is "ip6gre" type for L3. In IPv4 case, it is like this too > ("gre"/"gretap", but there is support for both, so "gre" is more user > friendly). In IPv6 case, as William and Greg commented, L3 over IPv6 GRE > is not supported (at least yet). I'd like to separate the current limitations from the desired "user interface". I understand that we can't currently support the full matrix of outer IPv4/IPv6 versus inner packet type. I am not sure that that is a good reason to distinguish them from a configuration point of view, especially if we ultimately might support the full matrix. If your configuration is orthogonal, then as you add support for new cells in the matrix, you actually *delete* documentation that describes limitations; if it is not, then you have to add documentation that describes the new way to configure whatever new cell you added.
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@gmail.com> >>>> Signed-off-by: Eli Britstein <elibr@mellanox.com> >>>> Co-authored-by: Eli Britstein <elibr@mellanox.com> >>>> Tested-by: Greg Rose <gvrose8192@gmail.com> >>>> Reviewed-by: Greg Rose <gvrose8192@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. - Greg
On Thu, Jun 27, 2019 at 9:10 AM Gregory Rose <gvrose8192@gmail.com> 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@gmail.com> > >>>> Signed-off-by: Eli Britstein <elibr@mellanox.com> > >>>> Co-authored-by: Eli Britstein <elibr@mellanox.com> > >>>> Tested-by: Greg Rose <gvrose8192@gmail.com> > >>>> Reviewed-by: Greg Rose <gvrose8192@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. > > - Greg > Thanks for the feedbacks. Let me work on v5 to use 'ip6gre' with packet_type = L2, instead of using 'ip6gretap' and document that L3 ip6gre is not supported yet. Once we have L3 support, we user interface can remain the same. --William
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@gmail.com> > > > > > Signed-off-by: Eli Britstein <elibr@mellanox.com> > > > > > Co-authored-by: Eli Britstein <elibr@mellanox.com> > > > > > Tested-by: Greg Rose <gvrose8192@gmail.com> > > > > > Reviewed-by: Greg Rose <gvrose8192@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 feature support.
diff --git a/Documentation/faq/configuration.rst b/Documentation/faq/configuration.rst index cb2c6b4eca98..c9bcfa8a790d 100644 --- a/Documentation/faq/configuration.rst +++ b/Documentation/faq/configuration.rst @@ -212,6 +212,18 @@ Q: Does Open vSwitch support ERSPAN? options:erspan_ver=2 options:erspan_dir=1 \ options:erspan_hwid=4 +Q: Does Open vSwitch support IPv6 GRE? + + A: Yes. L2 tunnel interface GRE over IPv6 is supported. + L3 GRE tunnel over IPv6 is not supported. + + :: + + $ ovs-vsctl add-br br0 + $ ovs-vsctl add-port br0 at_gretap0 -- \ + set int at_gretap0 type=ip6gretap \ + options:remote_ip=fc00:100::1 + Q: How do I connect two bridges? A: First, why do you want to do this? Two connected bridges are not much diff --git a/NEWS b/NEWS index a38ab258fc6c..c7e84ed7931d 100644 --- a/NEWS +++ b/NEWS @@ -47,6 +47,7 @@ Post-v2.11.0 - Linux datapath: * Support for the kernel versions 4.19.x and 4.20.x. * Support for the kernel version 5.0.x. + - Add L2 GRE tunnel over IPv6 support. v2.11.0 - 19 Feb 2019 diff --git a/datapath/linux/compat/ip6_gre.c b/datapath/linux/compat/ip6_gre.c index ca4e66133570..ab50c72d0753 100644 --- a/datapath/linux/compat/ip6_gre.c +++ b/datapath/linux/compat/ip6_gre.c @@ -2550,7 +2550,7 @@ static struct rtnl_link_ops ip6gre_link_ops __read_mostly = { }; static struct rtnl_link_ops ip6gre_tap_ops __read_mostly = { - .kind = "ip6gre", + .kind = "ip6gretap", .maxtype = RPL_IFLA_GRE_MAX, .policy = ip6gre_policy, .priv_size = sizeof(struct ip6_tnl), diff --git a/lib/dpif-netlink-rtnl.c b/lib/dpif-netlink-rtnl.c index 2e23a8c14fcf..d666f239aeed 100644 --- a/lib/dpif-netlink-rtnl.c +++ b/lib/dpif-netlink-rtnl.c @@ -104,7 +104,7 @@ vport_type_to_kind(enum ovs_vport_type type, case OVS_VPORT_TYPE_IP6ERSPAN: return "ip6erspan"; case OVS_VPORT_TYPE_IP6GRE: - return "ip6gre"; + return "ip6gretap"; case OVS_VPORT_TYPE_NETDEV: case OVS_VPORT_TYPE_INTERNAL: case OVS_VPORT_TYPE_LISP: diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c index ba80a0079181..fc1d1591975e 100644 --- a/lib/dpif-netlink.c +++ b/lib/dpif-netlink.c @@ -699,7 +699,7 @@ get_vport_type(const struct dpif_netlink_vport *vport) return "ip6erspan"; case OVS_VPORT_TYPE_IP6GRE: - return "ip6gre"; + return "ip6gretap"; case OVS_VPORT_TYPE_UNSPEC: case __OVS_VPORT_TYPE_MAX: @@ -730,6 +730,8 @@ netdev_to_ovs_vport_type(const char *type) return OVS_VPORT_TYPE_ERSPAN; } else if (!strcmp(type, "ip6erspan")) { return OVS_VPORT_TYPE_IP6ERSPAN; + } else if (!strcmp(type, "ip6gretap")) { + return OVS_VPORT_TYPE_IP6GRE; } else if (!strcmp(type, "ip6gre")) { return OVS_VPORT_TYPE_IP6GRE; } else if (!strcmp(type, "gre")) { diff --git a/lib/netdev-vport.c b/lib/netdev-vport.c index 92a256af16ed..5a20415529eb 100644 --- a/lib/netdev-vport.c +++ b/lib/netdev-vport.c @@ -1212,10 +1212,10 @@ netdev_vport_tunnel_register(void) }, {{NULL, NULL, 0, 0}} }, - { "ip6gre_sys", + { "ip6gretap_sys", { TUNNEL_FUNCTIONS_COMMON, - .type = "ip6gre", + .type = "ip6gretap", .build_header = netdev_gre_build_header, .push_header = netdev_gre_push_header, .pop_header = netdev_gre_pop_header diff --git a/lib/tnl-ports.c b/lib/tnl-ports.c index 17353046cc6e..62065c0027cd 100644 --- a/lib/tnl-ports.c +++ b/lib/tnl-ports.c @@ -172,7 +172,8 @@ tnl_type_to_nw_proto(const char type[]) return IPPROTO_TCP; } if (!strcmp(type, "gre") || !strcmp(type, "erspan") || - !strcmp(type, "ip6erspan") || !strcmp(type, "ip6gre")) { + !strcmp(type, "ip6erspan") || !strcmp(type, "ip6gre") || + !strcmp(type, "ip6gretap")) { return IPPROTO_GRE; } if (!strcmp(type, "vxlan")) { diff --git a/tests/system-traffic.at b/tests/system-traffic.at index d23ee897b0b2..43056733794a 100644 --- a/tests/system-traffic.at +++ b/tests/system-traffic.at @@ -340,6 +340,46 @@ NS_CHECK_EXEC([at_ns0], [ping -s 3200 -q -c 3 -i 0.3 -w 2 10.1.1.100 | FORMAT_PI OVS_TRAFFIC_VSWITCHD_STOP AT_CLEANUP +AT_SETUP([datapath - ping over ip6gretap tunnel]) +OVS_CHECK_KERNEL_EXCL(3, 10, 4, 15) +OVS_CHECK_GRE() +OVS_CHECK_ERSPAN() + +OVS_TRAFFIC_VSWITCHD_START() +ADD_BR([br-underlay]) + +AT_CHECK([ovs-ofctl add-flow br0 "actions=normal"]) +AT_CHECK([ovs-ofctl add-flow br-underlay "actions=normal"]) + +ADD_NAMESPACES(at_ns0) + +dnl Set up underlay link from host into the namespace using veth pair. +ADD_VETH(p0, at_ns0, br-underlay, "fc00:100::1/96", [], [], nodad) +AT_CHECK([ip addr add dev br-underlay "fc00:100::100/96" nodad]) +AT_CHECK([ip link set dev br-underlay up]) + +dnl Set up tunnel endpoints on OVS outside the namespace and with a native +dnl linux device inside the namespace. +ADD_OVS_TUNNEL6([ip6gretap], [br0], [at_gretap0], [fc00:100::1], [10.1.1.100/24], + []) +ADD_NATIVE_TUNNEL6([ip6gretap], [ns_gretap0], [at_ns0], [fc00:100::100], + [10.1.1.1/24], [local fc00:100::1]) + +OVS_WAIT_UNTIL([ip netns exec at_ns0 ping6 -c 2 fc00:100::100]) + +dnl First, check the underlay +NS_CHECK_EXEC([at_ns0], [ping6 -q -c 3 -i 0.3 -w 2 fc00:100::100 | FORMAT_PING], [0], [dnl +3 packets transmitted, 3 received, 0% packet loss, time 0ms +]) + +dnl Okay, now check the overlay with different packet sizes +NS_CHECK_EXEC([at_ns0], [ping -q -c 3 -i 0.3 -w 2 10.1.1.100 | FORMAT_PING], [0], [dnl +3 packets transmitted, 3 received, 0% packet loss, time 0ms +]) +OVS_TRAFFIC_VSWITCHD_STOP +AT_CLEANUP + + AT_SETUP([datapath - ping over erspan v1 tunnel]) OVS_CHECK_KERNEL_EXCL(3, 10, 4, 15) OVS_CHECK_GRE() diff --git a/tests/tunnel-push-pop-ipv6.at b/tests/tunnel-push-pop-ipv6.at index cbdd5a32f719..07dd6ab504a0 100644 --- a/tests/tunnel-push-pop-ipv6.at +++ b/tests/tunnel-push-pop-ipv6.at @@ -1,5 +1,73 @@ AT_BANNER([tunnel_push_pop_ipv6]) +AT_SETUP([tunnel_push_pop_ipv6 - ip6gretap]) + +OVS_VSWITCHD_START([add-port br0 p0 -- set Interface p0 type=dummy ofport_request=1 other-config:hwaddr=aa:55:aa:55:00:00]) +AT_CHECK([ovs-vsctl add-br int-br -- set bridge int-br datapath_type=dummy], [0]) +AT_CHECK([ovs-vsctl add-port int-br t2 -- set Interface t2 type=ip6gretap \ + options:remote_ip=2001:cafe::92 ofport_request=2\ + ], [0]) + +AT_CHECK([ovs-appctl dpif/show], [0], [dnl +dummy@ovs-dummy: hit:0 missed:0 + br0: + br0 65534/100: (dummy-internal) + p0 1/1: (dummy) + int-br: + int-br 65534/2: (dummy-internal) + t2 2/6: (ip6gretap: remote_ip=2001:cafe::92) +]) + +dnl First setup dummy interface IP address, then add the route +dnl so that tnl-port table can get valid IP address for the device. +AT_CHECK([ovs-appctl netdev-dummy/ip6addr br0 2001:cafe::88/24], [0], [OK +]) +AT_CHECK([ovs-appctl netdev-dummy/ip4addr br0 1.1.2.88/24], [0], [OK +]) +AT_CHECK([ovs-appctl ovs/route/add 2001:cafe::92/24 br0], [0], [OK +]) + +AT_CHECK([ovs-ofctl add-flow br0 action=normal]) + +dnl Check Neighbour discovery. +AT_CHECK([ovs-vsctl -- set Interface p0 options:pcap=p0.pcap]) + +AT_CHECK([ovs-appctl netdev-dummy/receive int-br 'in_port(2),eth(src=aa:55:aa:55:00:00,dst=f8:bc:12:ff:ff:ff),eth_type(0x0800),ipv4(src=1.1.3.92,dst=1.1.3.88,proto=1,tos=0,ttl=64,frag=no),icmp(type=0,code=0)']) +AT_CHECK([ovs-pcap p0.pcap > p0.pcap.txt 2>&1]) + +AT_CHECK([cat p0.pcap.txt | grep 92aa55aa55000086dd6000000000203aff2001cafe | uniq], [0], [dnl +3333ff000092aa55aa55000086dd6000000000203aff2001cafe000000000000000000000088ff0200000000000000000001ff00009287004d48000000002001cafe0000000000000000000000920101aa55aa550000 +]) + +dnl +AT_CHECK([ovs-appctl netdev-dummy/receive p0 'in_port(1),eth(src=f8:bc:12:44:34:b6,dst=aa:55:aa:55:00:00),eth_type(0x86dd),ipv6(src=2001:cafe::92,dst=2001:cafe::88,label=0,proto=58,tclass=0,hlimit=255,frag=no),icmpv6(type=136,code=0),nd(target=2001:cafe::92,sll=00:00:00:00:00:00,tll=f8:bc:12:44:34:b6)']) + +AT_CHECK([ovs-appctl tnl/arp/show | tail -n+3 | sort], [0], [dnl +2001:cafe::92 f8:bc:12:44:34:b6 br0 +]) + +AT_CHECK([ovs-appctl tnl/ports/show |sort], [0], [dnl +Listening ports: +ip6gretap_sys (6) ref_cnt=1 +]) + +dnl Check IPv6 GRE tunnel pop +AT_CHECK([ovs-appctl ofproto/trace ovs-dummy 'in_port(1),eth(src=f8:bc:12:44:34:b6,dst=aa:55:aa:55:00:00),eth_type(0x86dd),ipv6(src=2001:cafe::92,dst=2001:cafe::88,label=0,proto=47,tclass=0x0,hlimit=64)'], [0], [stdout]) +AT_CHECK([tail -1 stdout], [0], + [Datapath actions: tnl_pop(6) +]) + +dnl Check IPv6 GRE tunnel push +AT_CHECK([ovs-ofctl add-flow int-br action=2]) +AT_CHECK([ovs-appctl ofproto/trace ovs-dummy 'in_port(2),eth(src=f8:bc:12:44:34:b6,dst=aa:55:aa:55:00:01),eth_type(0x0800),ipv4(src=1.1.3.88,dst=1.1.3.112,proto=47,tos=0,ttl=64,frag=no)'], [0], [stdout]) + +AT_CHECK([tail -1 stdout], [0], + [Datapath actions: clone(tnl_push(tnl_port(6),header(size=58,type=109,eth(dst=f8:bc:12:44:34:b6,src=aa:55:aa:55:00:00,dl_type=0x86dd),ipv6(src=2001:cafe::88,dst=2001:cafe::92,label=0,proto=47,tclass=0x0,hlimit=64),gre((flags=0x0,proto=0x6558))),out_port(100)),1) +]) + +OVS_VSWITCHD_STOP +AT_CLEANUP + AT_SETUP([tunnel_push_pop_ipv6 - ip6erspan]) OVS_VSWITCHD_START([add-port br0 p0 -- set Interface p0 type=dummy ofport_request=1 other-config:hwaddr=aa:55:aa:55:00:00]) diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml index bf4b6f8dc621..b7d81cdaa1cc 100644 --- a/vswitchd/vswitch.xml +++ b/vswitchd/vswitch.xml @@ -2561,10 +2561,16 @@ <dt><code>gre</code></dt> <dd> - Generic Routing Encapsulation (GRE) over IPv4/IPv6 tunnel, + Generic Routing Encapsulation (GRE) over IPv4 tunnel, configurable to encapsulate layer 2 or layer 3 traffic. </dd> + <dt><code>ip6gretap</code></dt> + <dd> + Generic Routing Encapsulation (GRE) over IPv6 tunnel, + encapsulate layer 2 traffic. + </dd> + <dt><code>vxlan</code></dt> <dd> <p> @@ -2623,8 +2629,8 @@ <group title="Tunnel Options"> <p> These options apply to interfaces with <ref column="type"/> of - <code>geneve</code>, <code>gre</code>, <code>vxlan</code>, - <code>lisp</code> and <code>stt</code>. + <code>geneve</code>, <code>gre</code>, <code>ip6gretap</code>, + <code>vxlan</code>, <code>lisp</code> and <code>stt</code>. </p> <p> @@ -2921,10 +2927,10 @@ </column> </group> - <group title="Tunnel Options: gre, geneve, and vxlan"> + <group title="Tunnel Options: gre, ip6gretap, geneve, and vxlan"> <p> - <code>gre</code>, <code>geneve</code>, and - <code>vxlan</code> interfaces support these options. + <code>gre</code>, <code>ip6gretap</code>, <code>geneve</code>, + and <code>vxlan</code> interfaces support these options. </p> <column name="options" key="csum" type='{"type": "boolean"}'> @@ -2938,8 +2944,9 @@ <p> When using the upstream Linux kernel module, computation of checksums for <code>geneve</code> and <code>vxlan</code> requires - Linux kernel version 4.0 or higher. <code>gre</code> supports - checksums for all versions of Open vSwitch that support GRE. + Linux kernel version 4.0 or higher. <code>gre</code> and + <code>ip6gretap</code> support checksums for all versions of + Open vSwitch that support GRE. The out of tree kernel module distributed as part of OVS can compute all tunnel checksums on any kernel version that it is compatible with. @@ -2951,10 +2958,11 @@ <group title="Tunnel Options: IPsec"> <p> Setting any of these options enables IPsec support for a given - tunnel. <code>gre</code>, <code>geneve</code>, <code>vxlan</code>, - and <code>stt</code> interfaces support these options. See the - <code>IPsec</code> section in the <ref table="Open_vSwitch"/> table - for a description of each mode. + tunnel. <code>gre</code>, <code>ip6gretap</code>, + <code>geneve</code>, <code>vxlan</code> and <code>stt</code> + interfaces support these options. See the <code>IPsec</code> + section in the <ref table="Open_vSwitch"/> table for a description + of each mode. </p> <column name="options" key="psk" type='{"type": "string"}'> <p>