Page MenuHomeVyOS Platform

L2tpv3 config delete on reboot/startup
Closed, WontfixPublicBUG

Description

I am not sure if I would call this a bug, but ill let you decide.

Topology
test lab all running 1.2.0-rc9
3 routers all running OSPF, l2tpv3 tunnel between the "left" and "right" router through the "middle"
middle router announces default route.
l2tpv3 local/remote ip is the loopback address

When the router is booting up it hits the l2tpv3 config section before it has started OSPF and shared routes, this makes the remote-ip of the l2tpv3 tunnel unreachable.

I know that the linux l2tp tool will not let you create a tunnel where there remote-ip is unreachable.
for example on a device with no default gateway:
sudo ip l2tp add tunnel tunnel_id 100 peer_tunnel_id 100 encap ip local 10.0.0.1 remote 10.100.100.1
might produce
RTNETLINK answers: Network is unreachable

When you have the situation where you are trying to create an l2tpv3 tunnel and the remote ip is unreachable, it fails. This seems to then delete that section of the config.

My workaround is to create a high distance(254) default gateway route that OSPF will eventually overwrite when it starts up. You could argue that it might be best practice to always turn on a default route, and I think you might be right.

This seems to be more of a bug/feature? of the linux l2tp tool itself. Maybe it makes sense to put some kind of delay in starting the l2tp section, or maybe this just needs to be documented in the wiki?
--Andrew

Details

Difficulty level
Unknown (require assessment)
Version
1.2.0-rc9
Why the issue appeared?
Issues in third-party code
Is it a breaking change?
Unspecified (possibly destroys the router)

Event Timeline

c-po changed the task status from Open to Confirmed.Apr 1 2021, 5:21 PM
c-po triaged this task as Normal priority.
c-po changed Why the issue appeared? from Will be filled on close to Issues in third-party code.
c-po set Is it a breaking change? to Unspecified (possibly destroys the router).
c-po moved this task from Need Triage to In Progress on the VyOS 1.4 Sagitta board.

This can be reproduced with the following config on 1.4

 interfaces {
     dummy dum0 {
         address 172.18.254.201/32
         address 172.18.202.10/32
     }
     ethernet eth0 {
         duplex auto
         speed auto
         vif 10 {
             address 172.16.33.8/24
         }
     }
     l2tpv3 l2tpeth10 {
         description "L2 VPN Tunnel"
         destination-port 5010
         encapsulation ip
         mtu 1500
         peer-session-id 110
         peer-tunnel-id 10
         remote 172.18.254.201
         session-id 110
         source-address 172.18.202.10
         source-port 5010
         tunnel-id 10
     }
+    l2tpv3 l2tpeth20 {
+        description "L2 VPN Tunnel"
+        destination-port 5020
+        encapsulation ip
+        mtu 1500
+        peer-session-id 120
+        peer-tunnel-id 20
+        remote 172.18.254.202
+        session-id 120
+        source-address 172.18.202.10
+        source-port 5020
+        tunnel-id 20
+    }
+    l2tpv3 l2tpeth30 {
+        description "L2 VPN Tunnel"
+        destination-port 5030
+        encapsulation ip
+        mtu 1500
+        peer-session-id 130
+        peer-tunnel-id 30
+        remote 172.18.254.203
+        session-id 130
+        source-address 172.18.202.10
+        source-port 5030
+        tunnel-id 30
+    }
 }

The most crucial part here is that there is NO default route present on the system

Or try to create a tunnel manually:

sudo ip l2tp add tunnel tunnel_id 3000 peer_tunnel_id 4000 encap udp local 172.18.202.10 remote 5.6.7.8 udp_sport 5000 udp_dport 6000 - the kernel does a nexthop lookup and fails :(

c-po raised the priority of this task from Normal to High.

Turns out this is not a VyOS limitation but is a Linux Kernel/iproute2 limitation.

It does not allow you to create an l2tpv3 interface where it can not reach the remote side during creation. Somehow this does not feel right but the best way is as you mentioned - install a high distance default route.