Page MenuHomeVyOS Platform

Static IPv6 default route via OSPFv3-learned loopback is not activated
Needs testing, LowPublic

Description

admin@vyos:~$ show ipv6 route 
Codes: K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3,
       I - ISIS, B - BGP, * - FIB route.

S   ::/0 [1/0] via yyyy::2 inactive
C>* ::1/128 is directly connected, lo
C>* yyyy::1/128 is directly connected, lo
O>* yyyy::2/128 [110/1] via xxxx:fc54, tun0, 00:37:21
...
admin@vyos:~$ ping6 yyyy::2
PING yyyy::2(yyyy::2) 56 data bytes
64 bytes from yyyy::2: icmp_seq=1 ttl=64 time=13.9 ms
64 bytes from yyyy::2: icmp_seq=2 ttl=64 time=15.0 ms
^C
--- yyyy::2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 13.938/14.488/15.039/0.563 ms

When the router boots the static route is created, a script updates the IPSEC+GRE tunnel locally and remotely for dynamic IP, and eventually OSPFv3 learns the route to the remote router's loopback.

However, static default route with next-hop of the remote router's loopback does not function at this time unless destroyed and recreated. It is displayed as "inactive" and not installed in kernel routing table.

Deleting and recreating the static route after the loopback is learned from OSPFv3 allows traffic to be forwarded as expected and route is no longer displayed as "inactive".

Details

Difficulty level
Unknown (require assessment)
Version
999.201711232137
Why the issue appeared?
Will be filled on close

Event Timeline

Tiberius created this task.Dec 4 2017, 1:33 AM
Tiberius created this object in space S1 VyOS Public.
Tiberius changed Version from - to 999.201711232137.
syncer triaged this task as Low priority.Dec 21 2017, 9:09 PM
syncer changed the task status from Open to On hold.Oct 13 2018, 6:52 PM
syncer added a subscriber: syncer.

requires testing on the latest rolling

syncer changed the visibility from "Subscribers" to "Public (No Login Required)".Oct 13 2018, 6:52 PM
syncer edited subscribers, added: Active contributors, Maintainers; removed: Sentrium.
pasik added a subscriber: pasik.Nov 4 2018, 11:24 AM
syncer changed the task status from On hold to Needs testing.Feb 7 2019, 11:56 PM
syncer assigned this task to zsdc.

@Tiberius share your configuration and steps for reproducing.

ronie added a subscriber: ronie.Aug 16 2020, 11:42 PM
This comment was removed by ronie.
ronie added a comment.EditedAug 17 2020, 4:16 AM

I´ve tyred to reproduce this scenario with VyOS 1.3-rolling-202007300117.
The static-default-route is correctly installed in the routing table after rebooting the router.

The only difference, I guess, is that the IPv6 Global and Link-Local are manually set at the Tunnel Interface.

vyos@remote-host.example.net:~$ sh conf comm | grep route6
set protocols static route6 ::/0 next-hop 2001:172:16:3::3 #(this is the next hop router loopback interface)#
vyos@remote-host.example.net:~$
vyos@remote-host.example.net:~$
vyos@remote-host.example.net:~$ show conf comm | grep tun30
set interfaces tunnel tun30 address '2001:30:30:30::1/64'
set interfaces tunnel tun30 address 'fe80::520d:00ff:fe03:000c/10'
set interfaces tunnel tun30 encapsulation 'ip6gre'
set interfaces tunnel tun30 ipv6 address
set interfaces tunnel tun30 local-ip '2001:192:168:122:520d:ff:fe03:2'
set interfaces tunnel tun30 remote-ip '2001:192:168:122:520d:ff:fe01:2'
set interfaces tunnel tun30 source-interface 'eth2'
set protocols ospfv3 area 1 interface 'tun30'
vyos@remote-host.example.net:~$
vyos@remote-host.example.net:~$
vyos@remote-host.example.net:~$ show ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng,

O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued route, r - rejected route

**S> ::/0 [1/0] via 2001:172:16:3::3 (recursive), 00:02:11

  • via fe80::520d:ff:fe01:c, tun30, 00:02:11 #(the route recurses to the link-local neighbor)#**

O 2001:30:30:30::/64 [110/10] is directly connected, tun30, 00:10:02
C>* 2001:30:30:30::/64 is directly connected, tun30, 00:10:09
C>* 2001:172:16:1::1/128 is directly connected, lo, 00:10:14
O>* 2001:172:16:3::3/128 [110/21] via fe80::520d:ff:fe01:c, tun30, 00:02:11 #(The loopback learned via OSPFv3)#
C>* 2001:192:168:122::/64 is directly connected, eth2, 00:10:10
O>* 2001:192:168:123:144:70f2:b257:1b2e/128 [110/11] via fe80::520d:ff:fe01:c, tun30, 00:02:11
C>* 2001:192:168:123:d033:db0c:acc7:c8e3/128 is directly connected, eth0, 00:10:06
O>* 2001:192:168:123:d1da:58a9:ddcb:7dbd/128 [110/11] via fe80::520d:ff:fe01:c, tun30, 00:02:1
C * fe80::/10 is directly connected, tun30, 00:10:09
C>* fe80::/10 is directly connected, eth0, 00:10:11

I also rebooted the peer and as soon as the OSPFv3 is restablished and the remote loopback is learned the static route is re-installed in the routing-tabe:

vyos@remote-host.example.net:~$ sh ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng,

O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued route, r - rejected route

O 2001:30:30:30::/64 [110/10] is directly connected, tun30, 00:21:25
C>* 2001:30:30:30::/64 is directly connected, tun30, 00:21:32
C>* 2001:172:16:1::1/128 is directly connected, lo, 00:21:37
C>* 2001:192:168:122::/64 is directly connected, eth2, 00:21:33
C>* 2001:192:168:123:d033:db0c:acc7:c8e3/128 is directly connected, eth0, 00:21:29
C * fe80::/10 is directly connected, tun30, 00:21:32
C>* fe80::/10 is directly connected, eth0, 00:21:34
vyos@remote-host.example.net:~$
vyos@remote-host.example.net:~$ sh conf comm | grep route6
set protocols static route6 ::/0 next-hop 2001:172:16:3::3
vyos@remote-host.example.net:~$
vyos@remote-host.example.net:~$
vyos@remote-host.example.net:~$ sh ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng,

O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued route, r - rejected route

**S> ::/0 [1/0] via 2001:172:16:3::3 (recursive), 00:00:00

  • via fe80::520d:ff:fe01:c, tun30, 00:00:00**

O 2001:30:30:30::/64 [110/10] is directly connected, tun30, 00:22:11
C>* 2001:30:30:30::/64 is directly connected, tun30, 00:22:18
C>* 2001:172:16:1::1/128 is directly connected, lo, 00:22:23
O>* 2001:172:16:3::3/128 [110/21] via fe80::520d:ff:fe01:c, tun30, 00:00:00
C>* 2001:192:168:122::/64 is directly connected, eth2, 00:22:19
O>* 2001:192:168:123:144:70f2:b257:1b2e/128 [110/11] via fe80::520d:ff:fe01:c, tun30, 00:00:05
C>* 2001:192:168:123:d033:db0c:acc7:c8e3/128 is directly connected, eth0, 00:22:15
O>* 2001:192:168:123:d1da:58a9:ddcb:7dbd/128 [110/11] via fe80::520d:ff:fe01:c, tun30, 00:00:5
C * fe80::/10 is directly connected, tun30, 00:22:18
C>* fe80::/10 is directly connected, eth0, 00:22:20
vyos@remote-host.example.net:~$
vyos@remote-host.example.net:~$
vyos@remote-host.example.net:~$ sh ipv6 ospf neigh
Neighbor ID Pri DeadTime State/IfState Duration I/F[State]
172.16.3.3 1 00:00:31 Full/PointToPoint 00:00:26 tun30[PointToPoint]

Could you please share the scripts used to "update the IPSEC+GRE tunnel locally and remotely for dynamic IP"?

ronie added a comment.Aug 17 2020, 8:37 AM

It seems that making the tunnel connection a Stub Area would reach the same design goal without relying on a recursive static route, but it also seems that this feature is not supported in OSPFv3 by now. I´ve opened the following feature requests: https://phabricator.vyos.net/T2804 & https://phabricator.vyos.net/T2803 .