Problems with FRR

ChrisH 0

Hello all,I have a problem with one of our sites. We have over 50 sites and we use OpenVPN with OSPF for networking among the sites. In older sites we still use Quagga over PFsense and in the newer sites we use FRR.We always have multiple internet providers and at least 2 WAN lines and use gateway groups for different paths. Now I have the problem that a site is not reachable via OSPF. The states hang either in the status ExStart or Exchange.

Here is my FRR Config

##################### DO NOT EDIT THIS FILE! ######################
###################################################################

This file was created by an automatic configuration generator.

The contents of this file will be overwritten without warning!

###################################################################
!
frr defaults traditional
hostname CCFW0066.localdomain
password xxxx
log syslog
service integrated-vtysh-config
service password-encryption
!
ip router-id 10.74.0.1
!
ip route 192.168.181.0/24 Null0
ip route 192.168.186.0/24 Null0
!
interface ovpnc3
description "ospfd: Leipzig"
ip ospf cost 255
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 xxxx
ip ospf dead-interval 5
ip ospf hello-interval 2
ip ospf mtu-ignore
ip ospf area 0.0.0.0
interface ovpnc4
description "ospfd: Braunschweig"
ip ospf cost 220
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 xxxx
ip ospf dead-interval 5
ip ospf hello-interval 2
ip ospf area 0.0.0.0
interface ovpnc1
description "ospfd: Dortmund"
ip ospf cost 100
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5
ip ospf dead-interval 5
ip ospf hello-interval 2
ip ospf area 0.0.0.0
interface ovpnc2
description "ospfd: RZ"
ip ospf cost 150
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 xxxxx
ip ospf dead-interval 5
ip ospf hello-interval 2
ip ospf area 0.0.0.0
!
router ospf
ospf router-id 10.74.0.1
log-adjacency-changes detail
redistribute connected
distribute-list 1 out connected
ospf abr-type standard
network 10.74.0.0/16 area 0.0.0.0
!
access-list 1 seq 1 permit 10.74.0.0 0.0.255.255
access-list 1 seq 2 deny 192.168.181.0 0.0.0.255
access-list 1 seq 3 deny 192.168.186.0 0.0.0.255
access-list 1 remark Router blocken
!
ip prefix-list ACCEPTFILTER seq 10 deny 192.168.44.16/30
ip prefix-list ACCEPTFILTER seq 20 deny 192.168.44.18/32
ip prefix-list ACCEPTFILTER seq 30 deny 192.168.181.0/24
ip prefix-list ACCEPTFILTER seq 40 deny 192.168.186.0/24
ip prefix-list ACCEPTFILTER seq 50 permit any
!
route-map ACCEPTFILTER permit 10
match ip address prefix-list ACCEPTFILTER
!
ip protocol bgp route-map ACCEPTFILTER
!
ip protocol ospf route-map ACCEPTFILTER
!
line vty
!
end

In the System Log i see following

Jun 2 14:47:39 ospfd 8269 default:Packet[DD]: 10.47.0.1 DB Desc resend with seqnum:91d641f , flags:7
Jun 2 14:47:39 ospfd 8269 default:Packet[DD]: 10.23.0.1 DB Desc resend with seqnum:13bd5691 , flags:7
Jun 2 14:47:39 ospfd 8269 default:Packet[DD]: 10.0.0.230 DB Desc resend with seqnum:574f43e8 , flags:7
Jun 2 14:47:34 ospfd 8269 default:Packet[DD]: 10.47.0.1 DB Desc resend with seqnum:91d641f , flags:7
Jun 2 14:47:34 ospfd 8269 default:Packet[DD]: 10.23.0.1 DB Desc resend with seqnum:13bd5691 , flags:7
Jun 2 14:47:34 ospfd 8269 default:Packet[DD]: 10.0.0.230 DB Desc resend with seqnum:574f43e8 , flags:7
Jun 2 14:47:29 ospfd 8269 default:Packet[DD]: 10.47.0.1 DB Desc resend with seqnum:91d641f , flags:7
Jun 2 14:47:29 ospfd 8269 default:Packet[DD]: 10.23.0.1 DB Desc resend with seqnum:13bd5691 , flags:7
Jun 2 14:47:29 ospfd 8269 default:Packet[DD]: 10.0.0.230 DB Desc resend with seqnum:574f43e8 , flags:7
Jun 2 14:47:24 ospfd 8269 default:Packet[DD]: 10.47.0.1 DB Desc resend with seqnum:91d641f , flags:7
Jun 2 14:47:24 ospfd 8269 default:Packet[DD]: 10.23.0.1 DB Desc resend with seqnum:13bd5691 , flags:7
Jun 2 14:47:24 ospfd 8269 default:Packet[DD]: 10.0.0.230 DB Desc resend with seqnum:574f43e8 , flags:7
Jun 2 14:47:19 ospfd 8269 default:Packet[DD]: 10.47.0.1 DB Desc resend with seqnum:91d641f , flags:7
Jun 2 14:47:19 ospfd 8269 default:Packet[DD]: 10.23.0.1 DB Desc resend with seqnum:13bd5691 , flags:7
Jun 2 14:47:19 ospfd 8269 default:Packet[DD]: 10.0.0.230 DB Desc resend with seqnum:574f43e8 , flags:7

According to google this is related to MTU size problems, but all sites are configured the same and have the default MTU settings, which is 1500.

My PfSenseVersion on this Server is 2.5.2

I hope someone can help me.

LG

Chris

pete35

@chrish-0
I always use a MTU of 1400. That works in most cases.
Setting the interface to ignore the mtu may help too, there is an option to do that on the interface configuration page.

ChrisH 0

@pete35
Hello Pete, thanx for your help.

i have tested this with the MTU of 1400, but without success. The hook to ignore the MTU missmatch I have also already tested and this unfortunately without success.

pete35

@chrish-0
FRR on 2.5.2 is quite old. Maybe you try to update to 2.6.0 on these sites only?

ChrisH 0

@pete35
I have updated to 2.6.0, but the version of FRR is still not 1.1.1_7, so unfortunately no change.

pete35

@chrish-0
The version of FRR should be 1.1.1_7 ... try to update.

pete35

@jimp
The version of the frr package is about 15 month old. Is there a chance to update the frr package to the most recent version 8.2.2 ? There is a really long list of bugfixes on frr since then ... and there is also a redmine request #11206 , which nobody cares about? Is there no further development for this routing package? It isn't on the feature list of pfsense? A routing package with a lot of bugs doesn't make sense and pfsense without a routing package doesn't make sense for lots of usage cases too.

ChrisH 0

@pete35
thank you for pointing out the outdated version. I have tried many things, but unfortunately I can not get a newer version installed. :(

pete35

@chrish-0
To get support and an newer frr version, you should consider to change to the paid versions of pfsense. It looks like, that the CE version will be outdated for the most functions on a short timeframe. But the update to 1.1.1_7 should work, are there any logs available ? You can try to update FRR on a virtual testbox, it should work. Also reinstall and restore to config can help too.

Gcon

@pete35 What version of FRR does PfSense Plus come with? Not the Netgate package version, but the underlying FRR version? pfSense CE 2.6.0 and the current 2.7.0 development release come with 7.5.1 version dating from March 2021, so getting quite old considering how much development goes on with FRR:
https://frrouting.org/release/

pete35

Honestly - i dont know which version FRR is on Pfsense+. Considering that my question to jimp from july is already unanswered and they are not updating any packages on PF 2.6 i suppose that there is nothing newer as this frr version from March 2021. Besides that i would think about to switch over to the paid version and try to solve the various problems with frr with their support. Maybe someone has time to update the frr version for PF2.6 too. But that doesnt look like a reasonable fast solution path.

Gcon

@pete35 I grabbed a Plus lab license and changed a CE 2.6.0 install to 22.5 and saw that FRR is unchanged in that version, and the underlying FRR version is still only 7.5.1 at this point in time. Not sure where Netgate's priorities are here, as solid/dependable routing is absolutely key for corporate customers - the ones most likely to pay for the upper tier support contacts. IMHO FRR should be a top priority. FTIW pfSense CE 2.7.0 is still only on FRRR 7.5.1 but granted that is still early beta, but would be a shame if it too was still only 7.5.1 when final and not on a more recent FRR 8.x release.