Page MenuHomeVyOS Platform

OSPF does not redistribute connected routes associated with virtual tunnel interfaces
Closed, ResolvedPublic

Description

"set protocols ospf redistribute connected" will redistribute routes for physical interfaces- but does not appear to redistribute routes for virtual tunnel interfaces.

For example on the originating router:

$ show ip route 169.254.1.0
Routing entry for 169.254.1.0/30
 Known via "connected", distance 0, metric 1, best
 * directly connected, vti0

if I then do:

# set protocols ospf redistribute connected

On the ospf neighbors I see all the connected routes for normal interfaces (eth0, eth1, eth2, lo, etc.) however none of the connected routes associated with virtual tunnel interfaces show up.

Details

Difficulty level
Normal (likely a few hours)
Version
VyOS 999.201706062137
Why the issue appeared?
Implementation mistake
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Bug (incorrect behavior)

Event Timeline

syncer changed the task status from Open to On hold.Oct 13 2018, 10:49 AM
syncer edited projects, added VyOS 1.2 Crux (VyOS 1.2.0-rc4); removed VyOS 1.2 Crux.
syncer added a subscriber: syncer.

since we moved to frr, this requires testing with latest rolling

This may be also an issue for openvpn site-to-site tunnels. This shows in route list as follows:

wornet@<removed-name># run show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route

# [...]
O>* 10.41.127.34/32 [110/23] via 10.41.127.38, vtun0 onlink, 6d20h31m
O>* 10.41.127.35/32 [110/3] via 10.41.127.38, vtun0 onlink, 6d20h31m
O>* 10.41.127.36/32 [110/564] via 10.41.127.38, vtun0 onlink, 01:53:23
O>* 10.41.127.37/32 [110/64] via 10.41.127.38, vtun0 onlink, 6d20h31m
C>* 10.41.127.38/32 is directly connected, vtun0, 6d20h40m
O>* 10.41.127.39/32 [110/21] via 10.41.127.38, vtun0 onlink, 6d20h31m
O   10.41.191.0/24 [110/1] is directly connected, eth0, 6d20h40m
C>* 10.41.191.0/24 is directly connected, eth0, 6d20h40m
# [...]

vtun0 is the site-to-site interface and has a connected route but not an OSPF route altough redistributing connected is enabled. eth0 is redistributed normally.

syncer changed the task status from On hold to Needs testing.Feb 7 2019, 11:38 PM
syncer reassigned this task from sirket to zsdc.
syncer lowered the priority of this task from Normal to Low.

Tested this now using snapshot vyos-1.2.0-rolling+201903070337 and my usecase with OSPF via OpenVPN-Site-to-Site tunnels. Built up test setup using two vpn endpoints connected via a router (w/o firewall).

Addresses:

  • 10.99.37.2/24: vpn-endpoint1, public side
  • 10.99.38.1/24: vpn-endpoint1, private side reachable from other private side
  • 10.99.39.2/24: vpn-endpoint2, public side
  • 10.99.40.1/24: vpn-endpoint2, private side reachable from other private side
  • 10.99.41.1: vpn-endpoint1 local tun address
  • 10.99.41.2: vpn-endpoint2 local tun address

Output vpn-endpoint1:

vyos@vpn-endpoint1:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route

S>* 0.0.0.0/0 [1/0] via 10.99.37.1, eth0, 00:09:52
C>* 10.99.37.0/24 is directly connected, eth0, 00:09:59
O   10.99.38.0/24 [110/10] is directly connected, eth1, 00:09:51
C>* 10.99.38.0/24 is directly connected, eth1, 00:09:57
O>* 10.99.39.0/24 [110/20] via 10.99.41.2, vtun0 onlink, 00:00:29
O>* 10.99.40.0/24 [110/10010] via 10.99.41.2, vtun0 onlink, 00:00:30
O>* 10.99.41.1/32 [110/20] via 10.99.41.2, vtun0 onlink, 00:00:29
C>* 10.99.41.2/32 is directly connected, vtun0, 00:09:53

Output of vpn-endpoint2 is symmetric.

I'm keeping up the test environment for further tests., config of vpn-endpoint1 is attached - vpn-endpoint2 is symmetric.

Unknown Object (User) added a subscriber: Unknown Object (User).Aug 17 2020, 2:49 PM
Unknown Object (User) added a comment.Aug 20 2020, 5:24 AM

In this lab I used VyOS 1.3-rolling-202008170118. The connected routes redistributed in OSPF at HUB are being properly exchanged to WAN router, including the route to the virtual tunnel interface vti50.

image.png (1×1 px, 384 KB)

dmbaturin set Is it a breaking change? to Unspecified (possibly destroys the router).
Viacheslav added a subscriber: Viacheslav.

I don't see this bug in 1.3.0-rc5,

Tested configuration:

set interfaces ethernet eth0 address '192.168.122.14/24'
set interfaces ethernet eth1 address '192.0.2.1/30'
set interfaces vti vti2 address '10.0.0.1/30'
set interfaces vti vti2 address '100.64.1.1/24'
set protocols ospf area 0 network '192.168.122.0/24'
set protocols ospf redistribute connected
set vpn ipsec esp-group ESP-GRP-VTI compression 'disable'
set vpn ipsec esp-group ESP-GRP-VTI lifetime '1800'
set vpn ipsec esp-group ESP-GRP-VTI mode 'tunnel'
set vpn ipsec esp-group ESP-GRP-VTI pfs 'enable'
set vpn ipsec esp-group ESP-GRP-VTI proposal 1 encryption 'aes256'
set vpn ipsec esp-group ESP-GRP-VTI proposal 1 hash 'sha1'
set vpn ipsec ike-group IKE-GRP-VTI ikev2-reauth 'no'
set vpn ipsec ike-group IKE-GRP-VTI key-exchange 'ikev1'
set vpn ipsec ike-group IKE-GRP-VTI lifetime '3600'
set vpn ipsec ike-group IKE-GRP-VTI proposal 1 encryption 'aes256'
set vpn ipsec ike-group IKE-GRP-VTI proposal 1 hash 'sha1'
set vpn ipsec ipsec-interfaces interface 'eth1'
set vpn ipsec site-to-site peer 192.0.2.2 authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer 192.0.2.2 authentication pre-shared-secret 'SeCrEt'
set vpn ipsec site-to-site peer 192.0.2.2 ike-group 'IKE-GRP-VTI'
set vpn ipsec site-to-site peer 192.0.2.2 local-address '192.0.2.1'
set vpn ipsec site-to-site peer 192.0.2.2 vti bind 'vti2'
set vpn ipsec site-to-site peer 192.0.2.2 vti esp-group 'ESP-GRP-VTI'

On the remote site on vti interface we have 2 IP addresses 10.0.0.2/30 and 100.64.222.1/24 so we expect this routes in ospf

[email protected]:~$ show ip route ospf 
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup

O   10.0.0.0/30 [110/20] via 192.168.122.11, eth0, weight 1, 00:12:18
O>* 100.64.222.0/24 [110/20] via 192.168.122.11, eth0, weight 1, 00:12:18
O   192.0.2.0/30 [110/20] via 192.168.122.11, eth0, weight 1, 00:12:18
O   192.168.122.0/24 [110/1] is directly connected, eth0, weight 1, 00:13:19
[email protected]:~$

I don't see this issue for ipsec vti interfaces.

P.S for correct working ospf for openvpn site-to-site you should to use openvpn type "TAP" interfaces, i.e. frr doesn't work correctly with "unnumbered" interfaces.

dmbaturin renamed this task from ospf does not redistribute connected routes associated with virtuan tunnel interfaces to ospf does not redistribute connected routes associated with virtual tunnel interfaces.Sep 3 2021, 7:19 AM
dmbaturin renamed this task from ospf does not redistribute connected routes associated with virtual tunnel interfaces to OSPF does not redistribute connected routes associated with virtual tunnel interfaces.
dmbaturin set Issue type to Bug (incorrect behavior).