COnnected routes are not being advertised via ospfd
-
Hi,
We have pair of pfsense configured with CARP. We enabled ospf on WAN interface with redistribute connected.
We have created an IP alias(eg.1.1.1.1/20 which is different from WAN segment) for the purpose of routing and NAT. The segment which is configured as ip alias was advertised by the firewall via OSPF as we configured 'redistribute connected'... yesterday we changed the WAN IP address/Gateway, as soon as change the ip address, no issues in forming neighbor with the connected switches but the firewall stopped advertising 1.1.1.1/20 segment .(We also enabled static route for this segment via WAN gateway).
We did failover to make the 'backup' fw as master and the secondary firewall was running without any issue.
finally in primary firewall we found that the above segment was showing as kernel route.... So we deleted the static route but the route was still available as kernel route.....at last we rebooted the device... it started working...
IS it because of BUG or some thing else???... Pleas help....
Firewall version is 2.4.3-RELEASE-p1 -
do we have to add any rule on WAN interface for OSPF to exchange ospf related stuffs?
-
that seems more then likely ... without rules no packets
-
Okay fine.. I cant find the root cause of this issue... because we enabled rule for ospf and the firewall became neighbor of the switches but the route alone was not advertised by the firewall but it is showing all the routes received via OSPF...
-
there used to be a bug with quagga ospf combined with openvpn, that when the openvpn-service got restarted, the ospf-route got stuck as a kernel-route. i can't remember if this was fixed or not.
perhaps a similar thing is happening here.
are you using quagga or FRR ? you could switch to the other & see if its solved
-
I am using quagga-ospf but not running openvpn service...
-
the bug was not only with openvpn... more info here:
https://forum.netgate.com/topic/99252/major-issue-with-quagga-ospf-and-vlans-pfsense-2-3-0/19
&
https://redmine.pfsense.org/issues/6305conclusion of the bug-report on redmine was: give FRR a try, no further updates on that redmine
-
We actually redistribute the kernel routes and it has got resolved but we didnt want to do any changes in the setup which was running earlier and also when we did CARP failover the secondar firewall advertised the route without any issue... So we reboot the device and it started working...
-
Finally reboot fixed the issue but unable to find out the root cause...
-
I dont think it is because of bug as we found no issue in Backup firewall. there must be some malfunction happened while changing the IP of WAN interface... Still searching for the root cause...