Re: [ovs-discuss] GRE over IPv6 configuration

[Gregory Rose]

On 6/18/2019 9:15 AM, William Tu wrote:
On Mon, Jun 17, 2019 at 10:46 PM Eli Britstein <el...@mellanox.com> wrote:

On 6/18/2019 1:22 AM, Gregory Rose wrote:
On 6/12/2019 2:20 AM, Eli Britstein wrote:
Could you please have a look (and even better try?) still need to
tidy up

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Felibr-mellanox%2Flinux%2Ftree%2Fovs-ipv6-gre&amp;data=02%7C01%7Celibr%40mellanox.com%7C25425e700b58418b19fa08d6f37253ae%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636964069686971905&amp;sdata=Ki55ZQGwQKNNDkB4PZ1zpk9aqC42TXbt5WT%2F86SDauo%3D&amp;reserved=0



Hi Eli,

I finally managed to getting around and building your kernel.  At
least it does do away with the protocol error message but
I haven't gotten it working yet.  Stay tuned and I'll provide feedback.
Hi Greg,

I think William was right pointing out the comment from Pravin. I agree
with them that if we can avoid changing the kernel, and support it via
lib/dpif-netlink-rtnl.c, it is the way to go, and we should abandon the
kernel changes.

I haven't deep dived into it yet to see how ip6erspan works (at least no
creation error, didn't run traffic though) and ip6gre doesn't.

Hi Eli and Greg,

I've found the root cause using upstream kernel 5.2.
When adding an ip6gre device type, the
ovs_vport_cmd_new
   new_vport
     netdev_create
       ovs_netdev_link

and fails due to
     if (vport->dev->flags & IFF_LOOPBACK ||
         (vport->dev->type != ARPHRD_ETHER &&
          vport->dev->type != ARPHRD_NONE) ||
         ovs_is_internal_dev(vport->dev)) {
         err = -EINVAL;

Open vswitch cannot deal with port types other than ARPHRD_ETHER and 
ARPHRD_NONE.  ARPHRD_IP6GRE is not
supported in the code anywhere.

Because ip6gre is ARPHRD_IP6GRE
Which means ip6gre never works using upstream kernel :(

If we use ip6gretap, then its type is ARPHRD_ETHER,
and the ip6gretap device can be created successfully.

Interesting...  The implementation in OVS is wrong then.

And for ip6erspan, it's never been a issue because it is ARPHRD_ETHER.

And when using compat module, ip6gre works due to a coincident here:
at datapath/linux/compat/ip6_gre.c
static struct rtnl_link_ops ip6gre_link_ops __read_mostly = {
     .kind       = "ip6gre",
     .maxtype    = RPL_IFLA_GRE_MAX,
   <skip>

static struct rtnl_link_ops ip6gre_tap_ops __read_mostly = {
     .kind       = "ip6gre",
     .maxtype    = RPL_IFLA_GRE_MAX,
     .policy     = ip6gre_policy,
     .priv_size  = sizeof(struct ip6_tnl),

We happen to use ip6gre_tap link ops in type "ip6gre"

Oops.

I'm working on sorting this out... not sure which way but we need to 
close this gap between upstream and out of
tree.

- Greg

_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss