Page MenuHomePhabricator

ospf does not redistribute connected routes associated with virtuan tunnel interfaces
Needs testing, LowPublic

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

Event Timeline

sirket created this task.Jun 18 2017, 5:25 PM
pasik added a subscriber: pasik.Oct 27 2017, 10:03 PM
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

syncer assigned this task to sirket.Oct 13 2018, 7:20 PM

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.