On Tue, Jun 18, 2019 at 10:13 PM Eli Britstein <[email protected]> wrote:
> >> 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;
> >>
> >> 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.
> >>
> >> 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"
> >>
> >> Regards,
> >> William
> >>
> >>> Furthermore, I think the following is missing, as there is no ip6gretap,
> >>> only ip6gre:
> >>>
> > Hi Greg and Eli,
> >
> > Should we add both ip6gre (L3) and ip6gretap (L2) support?
> > @Eli, which mode do you want to use?
>
> ip6gretap
>
> I applied this patch too, and indeed the error is resolved. However, i
> still don't get traffic. Have you verified it works to indicate a setup
> issue for me?
>
No I haven't done the end-to-end test, the patch just passes
the port add stage. I will look into it.
--William
_______________________________________________
discuss mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
