I don't think it is possible in the GUI because I have looked as well. For this sort of thing I have always just resorted to the staticd raw config.

@juesor After completing the FRR WebGUI configuration, try to run it from the console:
# zebra --log --log-level debug -f /var/etc/frr/zebra.conf
and
# zebra --log --log-level debug -f /var/etc/frr/bgpd.conf

You can also create a redmine issue:
https://docs.netgate.com/pfsense/en/latest/development/bug-reporting.html

Perfect! Any idea when this commit will make it's way into the packages release channel?

Losing the area value should be fixed in the latest update I just pushed.

The upgrade hanging is something we're still working on. It's not isolated to FRR, it happens to several packages.

Looks like a recent change broke that validation (and also messed up the Area setting when upgrading).

I just pushed a fix, it should show up soon.

@owczi said in 2.4.2: FRR shows empty status output:

I found out what it was. Special characters in the FRR master password.

I removed the "_" from my password and it started working so I just assumed this was still an open issue. Sorry.

Though I'm not sure what specific issue you are talking about, there aren't any differences in the FRR package on 2.5.0 and 2.4.5-p1 except the 2.5.0 version is compiled with multipath enabled.

I just gave that a shot and it appears to work as expected.

Thanks for your help working out how the parts inter-operate

I actually see now flipping though the forums both of these have been reported before.

The first issue can be worked around by using "any6" instead of "any", but I think it'll still get dropped into the wrong file. I don't think there's any workaround for the 2nd but it's be previously mentioned.

what do you mean by "When it's not there".?

if the next hop is not available , the traffic will be forwarded via default route.

@jimp ok, thanks for the reply.

If your update branch is set to "Latest stable" then you should not upgrade any packages before upgrading pfSense.

If you manually set your update branch to stay on 2.4.4-pX then it won't offer package updates which would be potentially harmful.

@jimp said in FRR SG-1100 2.4.5:

It appears to be a problem with FRR itself on that architecture. We're aware and looking into it.

@jimp Any updates on this? I just got my SG-1100 a few weeks ago and installed 2.4.5 and have been stuck with static routes since I can't get FRR to work anymore.

Even if I downgraded to 2.4.4 would it work???

Thanks!

please upgrade to 7.3.1

I may have figured it out. I just added the CARP address as a default BGP peer. It might be right.

Use Prefix Lists :
FRR Global Settings/Zebra > Prefix Lists
then apply on neighbors:
Services>FRR>BGP>Edit>Neighbors >> Peer Filtering>Prefix List Filter(Inbound )

Configuration:

Prefix Lists

ip prefix-list testd seq 10 permit 10.10.10.0/24
ip prefix-list testd description

Before prefix list
*>i10.10.10.0/24 172.21.11.105 1 100 0 ?
*>i20.20.20.0/24 172.21.11.105 1 100 0 ?
*>xxxxxxxxxx/19 172.21.11.105 1 100 0 ?
*>i70.xxxxxxx/30 172.21.11.105 1 100 0 ?
*>i100.100.100.0/24 172.21.11.105 1 100 0 ?
*>i172.21.xx.xx/24 172.21.11.105 0 100 0 i
*>i172.21.xx.xx/27 172.21.11.105 1 100 0 ?
*>i172.21.1x.xx/29 172.21.11.105 1 100 0 ?

after applying
Network Next Hop Metric LocPrf Weight Path
*>i10.10.10.0/24 172.21.11.105 1 100 0 ?

@smaxwell2 said in FRR 0.6.4_3 not installing on 2.4.4-RELEASE-p3 (while FRR 0.6.4_2 works):

I am having exactly the same issue. However don't wish to upgrade to 2.4.5 as I am having a few issues with that. Is there a command you can run to install FRR 0.6.4_2 manually ?

No. Since 2.4.5 is out, there is no way to keep the packages pointed at the old 2.4.4 repository. You have to upgrade to access any packages.

Also looking forward for implementation of this.

I run a pfsense machine inside China's great firewall and fast failover of BGP within ipsec tunnels would be helpful.

I applied the first patch and then the second, no issues there. Repeating the steps above, initial test seem positive. I will let it bake for a few days and report the status of it. It seems the AWS tunnels drop and reconnect one at a time in sequence once or twice a day. As long as no one texts me about connectivity, it will be a success. :)