Bug #14240
closed
FRR OSPF Neighbor Not Detected for VTI Tunnels
Added by Kris Phillips over 2 years ago.
Updated over 2 years ago.
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.
Additional troubleshooting:
We re-saved the interfaces, restarted the FRR Zebra and OSPF service several times, dropped and brought up the IPSec tunnel
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 .
- 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.
- 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?
- 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.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by