Bug #14240
closed
FRR OSPF Neighbor Not Detected for VTI Tunnels
0%
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.
Updated by Kris Phillips over 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
Updated by Alhusein Zawi over 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 .
Updated by Jim Pingle over 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.
Updated by Kris Phillips over 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?
Updated by Jim Pingle over 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.