Project

General

Profile

Actions

Bug #14240

closed

FRR OSPF Neighbor Not Detected for VTI Tunnels

Added by Kris Phillips about 2 years ago. Updated about 2 years ago.

Status:
Not a Bug
Priority:
Normal
Assignee:
-
Category:
FRR
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Affected Version:
Affected Plus Version:
23.01
Affected Architecture:
All

Description

Customer upgraded from 22.05 to 23.01 and FRR no longer showed a neighbor for a VTI tunnel with a /30 to an OSPF neighbor. Neighbors with physical links worked fine, but not VTI tunnels.

Running a pcap on the VTI interface, no OSPF traffic was attempting to traverse the interface. FRR shows the interface as detected, but UNUMBERED. Attempted to set the interface as non-broadcast and manually define a neighbor, but this still did not bring up the neighbor.

Looking at the logging, the following error was present:

Line #910 | Apr 7 01:52:43 [firewall name redacted] php-fpm4167: /vpn_ipsec.php: The command '/sbin/ifconfig 'ipsec14' inet '172.16.255.34/30' '172.16.255.33/30'' returned exit code '1', the output was 'ifconfig: 172.16.255.33/30: bad value'

We then reverted to 22.05 and the neighbor immediately came up with discovery when reverted to a broadcast neighbor.

Actions #1

Updated by Kris Phillips about 2 years ago

Additional troubleshooting:

We re-saved the interfaces, restarted the FRR Zebra and OSPF service several times, dropped and brought up the IPSec tunnel

Actions #3

Updated by Alhusein Zawi about 2 years ago

to work around it (tested)

Add an IP to the Localhost Firewall>Virtual IPs. (both sides, non used IPs)
add Localhost(lo0) to OSPF interface .
you should be able to see it in OSPF Routes .

Actions #4

Updated by Jim Pingle about 2 years ago

  • Status changed from New to Not a Bug

Can't reproduce this, it's working fine here as it has for quite some time. Even on 23.05 snapshots. Has to be a configuration problem that maybe happened to work in the past by accident.

VTI to VTI, /30 on both sides. OSPF configured with manual neighbor entries. Interfaces are set to point-to-point since VTI interfaces are point-to-point type (a -> b). Ignore MTU is also set on both.

Both routers see the neighbor, show it in a Full/DROther state, and both have exchanged routes with the peer and have them in the FIB.

Actions #5

Updated by Kris Phillips about 2 years ago

  • Status changed from Not a Bug to New

Jim Pingle wrote in #note-4:

Can't reproduce this, it's working fine here as it has for quite some time. Even on 23.05 snapshots. Has to be a configuration problem that maybe happened to work in the past by accident.

VTI to VTI, /30 on both sides. OSPF configured with manual neighbor entries. Interfaces are set to point-to-point since VTI interfaces are point-to-point type (a -> b). Ignore MTU is also set on both.

Both routers see the neighbor, show it in a Full/DROther state, and both have exchanged routes with the peer and have them in the FIB.

Both Alhusein and I were both able to recreate this. In 22.05 using the VTI interface as broadcast resulted in FRR OSPF detecting the neighbor automatically through the link without manual neighbor entries. While point-to-point neighbor configurations makes sense, this should allow for automatic neighbor discovery as well, so manual entries shouldn't be necessary. Once we upgraded to 23.01 this is immediately broken.

We will try with manual neighbor entries with the customer, but seems that a reduction in functionality has occurred here. Did you test without manually adding a neighbor?

Actions #6

Updated by Jim Pingle about 2 years ago

  • Status changed from New to Not a Bug

It may have worked by accident, but it wasn't supposed to have worked that way. The interfaces were only intended to be used in point-to-point or maybe non-broadcast mode. WireGuard is the same (On pfSense and TNSR both).

If something did change in FRR, then there isn't anything actionable anyhow since it would be a bug in FRR that FRR would need to solve upstream. And since it does work when configured the correct way, I doubt it would get much traction there.

Actions

Also available in: Atom PDF