Page MenuHomeVyOS Platform

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

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
Normal (likely a few hours)
Version
999.201711232137
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Perfectly compatible
Issue type
Bug (incorrect behavior)

Event Timeline

Tiberius changed Version from - to 999.201711232137.
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.
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.

Unknown Object (User) added a subscriber: Unknown Object (User).Aug 16 2020, 11:42 PM
This comment was removed by Unknown Object (User).
Unknown Object (User) 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.

[email protected]:~$ 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)#
[email protected]:~$
[email protected]:~$
[email protected]:~$ 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'
[email protected]:~$
[email protected]:~$
[email protected]:~$ 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:

[email protected]:~$ 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
[email protected]:~$
[email protected]:~$ sh conf comm | grep route6
set protocols static route6 ::/0 next-hop 2001:172:16:3::3
[email protected]:~$
[email protected]:~$
[email protected]:~$ 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
[email protected]:~$
[email protected]:~$
[email protected]:~$ 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"?

Unknown Object (User) 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 .

dmbaturin set Is it a breaking change? to Perfectly compatible.Jan 27 2021, 6:52 PM
Unknown Object (User) changed the subtype of this task from "Task" to "Bug".Mar 11 2021, 8:01 PM
Unknown Object (User) changed Difficulty level from Unknown (require assessment) to Normal (likely a few hours).
dmbaturin set Issue type to Bug (incorrect behavior).Sep 3 2021, 7:30 AM