On Wed, Jul 07, 2021 at 09:05:24AM -0600, David Ahern wrote:
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 ip6_tunnel.
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.
I probably won't have the time in the immediate future, but I've added this work to my todo list. Meanwhile, I'll move the selftests to net/ and repost when net-next reopens.