Bug #16222
open2.8.0 - FRR - OSPF Route Propagation Fails After Reboot
0%
Description
Since upgrading my pfSense with FRR, OSPF no longer seems to function correctly.
I use site-to-site OpenVPN tunnels to propagate routes between my locations. However, after rebooting either the primary or secondary firewall, OSPF does not automatically start advertising the routes.
The OpenVPN tunnels come up successfully, but no OSPF routes are exchanged.
If I manually restart the FRR services, or toggle FRR off and on again (via Services > FRR > OSPF), or even just reapply the OSPF interface settings, the routes start propagating as expected.
Restarting the OpenVPN tunnels will not trigger route propagation. Only manipulating FRR will.
Something's different between 2.0.2_1 and 2.0.2_6 packages
This doesn't seem to occur on standalone pfSense — only in HA setups.
Updated by F. M. 3 months ago
After further troubleshooting, I discovered that, for some reason, the file /var/etc/frr/frr.conf is missing the line "ip ospf area 0.0.0.0" on every interface.
However, whenever I restart the FRR services, the file is rewritten and the "ip ospf area 0.0.0.0" line is correctly added to every interface.
I’m not sure if this is the root cause of the problem or just a symptom. The fact is, when I reboot my HA PFSense box, /var/etc/frr/frr.conf is missing the "ip ospf area 0.0.0.0" statements, and only after restarting the FRR service does the file get updated.
In practical terms, I observe that no OSPF hello packets are sent until this is fixed—that is, until the services are restarted.
EDIT:
/usr/local/pkg/frr/inc/frr_ospf.inc
line 215, remove:
if (empty($interface_ip)) {
continue;
}
This fixes the problem.
Please provide a proper fix ;)
Updated by Kris Phillips 3 months ago
F. M. wrote in #note-1:
After further troubleshooting, I discovered that, for some reason, the file /var/etc/frr/frr.conf is missing the line "ip ospf area 0.0.0.0" on every interface.
However, whenever I restart the FRR services, the file is rewritten and the "ip ospf area 0.0.0.0" line is correctly added to every interface.
I’m not sure if this is the root cause of the problem or just a symptom. The fact is, when I reboot my HA PFSense box, /var/etc/frr/frr.conf is missing the "ip ospf area 0.0.0.0" statements, and only after restarting the FRR service does the file get updated.
In practical terms, I observe that no OSPF hello packets are sent until this is fixed—that is, until the services are restarted.
EDIT:
/usr/local/pkg/frr/inc/frr_ospf.inc
line 215, remove:
if (empty($interface_ip)) {
continue;
}This fixes the problem.
Please provide a proper fix ;)
Are you using Point-to-Point mode for the interfaces and have manually configured neighbors or are you relying on neighbor discovery? Typically with IPSec VTI and OpenVPN links, neighbor discovery is unreliable and neighbors should be manually configured.
Updated by F. M. 3 months ago
Kris Phillips wrote in #note-2:
F. M. wrote in #note-1:
After further troubleshooting, I discovered that, for some reason, the file /var/etc/frr/frr.conf is missing the line "ip ospf area 0.0.0.0" on every interface.
However, whenever I restart the FRR services, the file is rewritten and the "ip ospf area 0.0.0.0" line is correctly added to every interface.
I’m not sure if this is the root cause of the problem or just a symptom. The fact is, when I reboot my HA PFSense box, /var/etc/frr/frr.conf is missing the "ip ospf area 0.0.0.0" statements, and only after restarting the FRR service does the file get updated.
In practical terms, I observe that no OSPF hello packets are sent until this is fixed—that is, until the services are restarted.
EDIT:
/usr/local/pkg/frr/inc/frr_ospf.inc
line 215, remove:
if (empty($interface_ip)) {
continue;
}This fixes the problem.
Please provide a proper fix ;)Are you using Point-to-Point mode for the interfaces and have manually configured neighbors or are you relying on neighbor discovery? Typically with IPSec VTI and OpenVPN links, neighbor discovery is unreliable and neighbors should be manually configured.
I'm using point-to-point. My theory is that, for some reason, when the FRR services start before the OpenVPN tunnels are fully established, the OSPF area doesn't get populated.
As I mentioned, the quick and dirty fix works around the issue by explicitly defining the area within the interface configuration, ensuring it's always populated regardless.
Updated by Jim Pingle 3 months ago
- Project changed from pfSense to pfSense Packages
- Category changed from Routing to FRR
- Release Notes deleted (
Default)