From: David Ahern <firstname.lastname@example.org>
To: Guillaume Nault <email@example.com>
Cc: Ido Schimmel <firstname.lastname@example.org>,
David Miller <email@example.com>,
Jakub Kicinski <firstname.lastname@example.org>,
email@example.com, Shuah Khan <firstname.lastname@example.org>,
Subject: Re: [PATCH net-next 1/4] selftests: forwarding: Test redirecting gre or ipip packets to Ethernet
Date: Wed, 7 Jul 2021 09:05:24 -0600 [thread overview]
Message-ID: <email@example.com> (raw)
On 7/6/21 1:02 PM, Guillaume Nault wrote:
> On Thu, Jul 01, 2021 at 09:38:44AM -0600, David Ahern wrote:
>> On 7/1/21 8:59 AM, Guillaume Nault wrote:
>>> I first tried to write this selftest using VRFs, but there were some
>>> problems that made me switch to namespaces (I don't remember precisely
>>> which ones, probably virtual tunnel devices in collect_md mode).
>> if you hit a problem with the test not working, send me the test script
>> and I will take a look.
> So I've looked again at what it'd take to make a VRF-based selftest.
> The problem is that we currently can't create collect_md tunnel
> interfaces in different VRFs, if the VRFs are part of the same netns.
> Most tunnels explicitely refuse to create a collect_md device if
> another one already exists in the netns, no matter the rest of the
> tunnel parameters. This is the behaviour of ip_gre, ipip, ip6_gre and
> Then there's sit, which allows the creation of the second collect_md
> device in the other VRF. However, iproute2 doesn't set the
> IFLA_IPTUN_LINK attribute when it creates an external device, so it
> can't set up such a configuration.
> Bareudp simply doesn't support VRF.
> Finally, vxlan allows devices with different IFLA_VXLAN_LINK attributes
> to be created, but only when VXLAN_F_IPV6_LINKLOCAL is set. Removing
> the VXLAN_F_IPV6_LINKLOCAL test at the end of vxlan_config_validate()
> is enough to make two VXLAN-GPE devices work in a multi-VRF setup:
Thanks for the details. In short, some work is needed to extend VRF
support to these tunnels. That is worth doing if you have the time.
next prev parent reply other threads:[~2021-07-07 15:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-30 12:51 [PATCH net-next 0/4] selftests: forwarding: Tests redirects between L3 and L2 devices Guillaume Nault
2021-06-30 12:51 ` [PATCH net-next 1/4] selftests: forwarding: Test redirecting gre or ipip packets to Ethernet Guillaume Nault
2021-07-01 5:46 ` Ido Schimmel
2021-07-01 14:59 ` Guillaume Nault
2021-07-01 15:38 ` David Ahern
2021-07-01 16:59 ` Guillaume Nault
2021-07-06 19:02 ` Guillaume Nault
2021-07-07 15:05 ` David Ahern [this message]
2021-07-07 15:42 ` Guillaume Nault
2021-07-08 1:50 ` David Ahern
2021-07-09 16:21 ` Guillaume Nault
2021-06-30 12:51 ` [PATCH net-next 2/4] selftests: forwarding: Test redirecting sit " Guillaume Nault
2021-06-30 12:51 ` [PATCH net-next 3/4] selftests: forwarding: Test redirecting ip6gre and ip6tnl " Guillaume Nault
2021-06-30 12:51 ` [PATCH net-next 4/4] selftests: forwarding: Test redirecting vxlan and bareudp " Guillaume Nault
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).