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:

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. :)

@Zawi deceptively simple to say the least, and it took me a few times to see it in the documentation. I think I did try that before, but the key is that on my Site1 the Outbound NAT did not automatically include the subnet's from Site2, so once I put the Outbound NAT into Hybrid Mode and added the subnets, well things are now working as expected.

I am still using BGP though simply to avoid the static routes, I have a few subnets and am lazy. Couple of things I've learned also is under the Gateway entries, in Advanced you can define the thresholds for latency and packet loss for the gateway to be considered up/down, which is key here. Also, I had the VTI gateway set to disable monitoring, which in my testing also broke the failover, which was another key problem.

you need to apply it by neighbor.

your should use pf2.4.5

Bingo. I removed the brackets from the password and i ca now see information under OSPF status.

Thank you so much.