Page MenuHomeVyOS Platform

VTI tunnels lose their v6 Link Local addresses when set down/up
Closed, ResolvedPublicBUG

Description

I’m having a weird issue with VTI tunnels losing their v6 Link Local addresses.

I am running the VyOS 1.5 rolling image. I’ve tested with 1.5-rolling-202310080024 and 1.5-rolling-202311210100.

I have IKEv2 routed VPNs between 3 VyOS hosts with BGP for dynamic routing, and IPv6 is implemented on all 3 systems and the interfaces. The VTI interfaces are configured dual-stack, so both v4 and v6 are assigned on each VTI. The VTI interfaces, if freshly created or configured by VyOS, will get a v6 link-local address. However if the link for the VTI is set to down for any reason, when it comes back up, the v6 link-local IP disappears and won’t come back until you delete/recreate the interface or otherwise force it to be reconfigured.

ifconfig before:

vti0: flags=193<UP,RUNNING,NOARP>  mtu 1436
        inet xxx.xxx.xxx.1  netmask 255.255.255.254
        inet6 fe80::f0f1:51ff:feb4:b29d  prefixlen 64  scopeid 0x20<link>
        inet6 xxxx:xxxx:xxxx:xxxx::fffd  prefixlen 127  scopeid 0x0<global>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
        RX packets 1757388  bytes 2361358233 (2.1 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 472658  bytes 39455683 (37.6 MiB)
        TX errors 54  dropped 54 overruns 0  carrier 54  collisions 0

ifconfig after:

vti0: flags=193<UP,RUNNING,NOARP>  mtu 1436
        inet xxx.xxx.xxx.1  netmask 255.255.255.254
        inet6 xxxx:xxxx:xxxx:xxxx::fffd  prefixlen 127  scopeid 0x0<global>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
        RX packets 1757388  bytes 2361358233 (2.1 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 472658  bytes 39455683 (37.6 MiB)
        TX errors 54  dropped 54 overruns 0  carrier 54  collisions 0

Please also note that it doesn't seem like the interface remembers the synthetic mac address that it's supposed to be getting, but that may be an intentional cosmetic thing there.

The fastest way I’ve seen that will remedy this is to force the interface to be reconfigured such as with set interfaces vti vti0 ipv6 address no-default-link-local and commit, then delete that line and commit again.

@Apachez suggested it may be an issue with Linux kernel and FRR forgetting information between each other.

@Viacheslav also suggests the following:

As it is a dynamic interface the MAC address generated during creating/commit by VyOS
and then when interface not in the system and adding again it don't use mac generation via commit
So you should trigger to re-generate mac after interface re-created without commit
Its probably should be called here https://github.com/vyos/vyos-1x/blob/3ab206b04350aec4872ed72ae4bd3440a47204f0/src/etc/ipsec.d/vti-up-down#L40-L41

https://github.com/vyos/vyos-1x/blob/3ab206b04350aec4872ed72ae4bd3440a47204f0/python/vyos/ifconfig/vti.py#L57-L59

Example configuration:

interfaces {
 vti {
  vti0 {
   address xxx.xxx.xxx.1/31
   address xxxx:xxxx:xxxx:xxxx::fffd/127
   mtu 1436
  }
 }
}

You can reproduce with: sudo ip link set vti0 down followed by sudo ip link set vti0 up, which should cause the link local address to disappear.

Details

Difficulty level
Unknown (require assessment)
Version
1.5-rolling-202310080024, 1.5-rolling-202311210100
Why the issue appeared?
Design mistake
Is it a breaking change?
Perfectly compatible
Issue type
Bug (incorrect behavior)

Event Timeline

This is related to Kernel addr_gen_mode beeing globally disabled. It's actually on my "to refactor list" and with this bug it gainer priority!

c-po changed the task status from Open to In progress.Nov 21 2023, 9:17 PM
c-po triaged this task as Normal priority.
c-po changed Why the issue appeared? from Will be filled on close to Design mistake.
c-po changed Is it a breaking change? from Unspecified (possibly destroys the router) to Perfectly compatible.
c-po added a project: VyOS 1.4 Sagitta.