Project

General

Profile

Actions

Bug #14797

closed

FRR not propagating some kernel routes to Zebra table, breaking OSPF redistribution

Added by Geoffrey Davis over 1 year ago. Updated over 1 year 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:
2.7.0
Affected Plus Version:
Affected Architecture:
All

Description

I recently upgraded a pfSense VM from 2.6.x to 2.7.0, and the FRR package was also updated from something to 1.3_1

When I did that, FRR seems to have forgotten how to redistribute certain routes into the Zebra table, and thus OSPFd won't pick them up for redistribution.


Topology

I have a policy-based VPN tunnel from a cellular modem to my backbone, 172.23.54.192/27 -> 0.0.0.0/0

In the kernel routing table, IPSec creates a kernel route like so:

$ netstat -rn | grep 172.23.65.192
172.23.65.192/27   link#4             U1          lo0

FRR was configured to redistribute kernel routes matching an FRR route-map called Redistribute_Kernel which in turn points to an FRR Prefix List called IPSec_VPNS . That list had not changed, and includes an entry permitting 172.23.65.192/27 .

It looks like this:

ip prefix-list IPSec_VPNS seq 10 permit 172.23.65.192/27 
ip prefix-list IPSec_VPNS seq 20 permit 172.16.76.0/22 ge 22 le 31 
ip prefix-list IPSec_VPNS seq 30 permit 172.16.71.0/24 ge 24 le 30 
ip prefix-list IPSec_VPNS description Policy-routed IPSec networks. SYNC MANUALLY WITH PF Alias IPSEC_POLICY_NETS
!
route-map Redistribute_Kernel permit 10
 description Permit IPSec_VPNS
 match ip address prefix-list IPSec_VPNS
route-map Redistribute_Kernel deny 100
 description Default Deny

However, FRR wasn't even seeing the 172.23.65.192/27 route from the Kernel table. I have no idea why, but it wasn't showing up in the Zebra Routes section of the FRR status page. Because FRR couldn't see the route, it wouldn't redistribute the route to OSPF.


Troubleshooting attempts:

I tried disabling the Route-map on OSPF redistribution of Kernel routes so that all Kernel routes would get redistributed, but that didn't change the behavior.

I also tried restarting IPSec and FRR a couple of times in different orders, with no change in behavior.


Workaround:

I ended up having to do two things:

  1. define a "Static Route" in FRR/Zebra (not at the OS layer, only in FRR).
  2. enable redistribution of FRR Static Routes into OSPF using the same Route-Map as I was using with the Kernel redistribution method.

I added an entry with the following options:

Do Not Accept: Unchecked
Null Route: Unchecked
Subnet: 172.23.65.192/27
Static Route Target: Interface: LAN
Once I did that, the kernel routing table (shown by netstat -rn ) changed to the following:

$ netstat -rn | grep 172.23.65.128
172.23.65.128/27   172.16.32.193      UG1         em1

This was expected, as the FRR settings page states that static Zebra Routes will get injected into the kernel table as well.

Additionally, the new static route showed up in the Zebra table.

However, it did NOT show up in the OSPF routes still.

I had to turn on FRR Static Routes in the Route Distribution section of the FRR OSPF Settings page. Once I did that, the route for 172.23.65.192/27 showed up in the OSPF Routing Table and propagated out to the rest of the backbone.

Actions #1

Updated by Jim Pingle over 1 year ago

  • Status changed from New to Not a Bug

This is most likely a problem in your configuration, or maybe an upstream bug in FRR on FreeBSD. Either way there isn't anything actionable here as a Redmine issue. We already have an issue open for updating to FRR 9.x which may help if it's an issue in FRR itself.

This site is not for support or diagnostic discussion, so any assistance with your configuration belongs on the forum.

For assistance in solving problems, please post on the Netgate Forum .

See Reporting Issues with pfSense Software for more information.

Actions

Also available in: Atom PDF