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

@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.

I had all sorts of issues too, but, my final solution was to distribute kernel routes but use a distribute list to then only send the exact kernel routes I want.

That way, I can have the routes set in pfSense as static routes too.

See my post here;
https://forum.netgate.com/topic/145252/osfp-distributing-routes-just-using-access-lists-not-bothering-with-interfaces-expect-the-vti-ones

That's part of why it's still just a patch and not in the code. It helps some situations, but not others. That said, you can't really have it both ways. It can either restart the packages or not restart the packages.

The reason it has to restart is typically what you have seen -- FRR needs to restart to latch back onto an interface which has changed (or probably deleted and recreated).

IPsec may fare better because of the changes I made in https://redmine.pfsense.org/issues/9668 which cycles the interface in FRR live without restarting the package. I'm not sure if a similar change for OpenVPN would be viable.

Thank you ... and yes i was laughing at that point ..... feel ashamed 😁

I tried it again, but no success. OVPN routes and static routes are classified as external routes (AS External Link States) into the OSPF database,
so according to this: https://github.com/FRRouting/frr/issues/5290 they are not summarized. Only local LAN addresses have a chance to get summarized.

@0daymaster said in FRR OSPF Ext 1 Default Route With Unexpected Cost.:

default-information originate metric 50 metric-type 1

You can try to change metric-type 1 to metric-type 2 which is the default. It shouldnt change the costs then... as far as i understand that metric-type ...

Got it figured with some basic reading. What i was missing was the policy based routing via firewall rules as described here:

https://docs.netgate.com/pfsense/en/latest/routing/directing-traffic-with-policy-routing.html

Hi Jim,
Thanks for your advice. I checked and our upstream gateway routers are indeed configured to block bogons at that point, so there is no issue with leaving this removed from the WAN interface.

Regards,
Erik

Great! Thank you on both accounts. I disabled the gateway, and we're still operational. :-)
And I didn't realize you could just start typing names in the network box.... From the GUI, it sure looks like it wants a network address.
But now the alias is in use.

Thanks again, and Happy New Year!

@barryboden

You can get all that info from the GUI too

70e24528-fe0c-45b8-af6e-9ddbb82c980d-image.png

cdd7c3a4-5ab5-494f-98dc-8d053a3cebf9-image.png

I'm sure it is. We'll pick up the update eventually. 2.5.0 snapshots are already on 7.1.

It's unlikely that we'll bring FRR 7.x back to 2.4.4-p3 at this point, though.

@gdi2k
We deployed VTI+FRR (2.4.4p3) and that was a disaster. We're thinking about trying OpenVPN+FRR. Do you know if this issue is resolved in the newer (v0.6.3_1) versions of FRR?

That is its own complete router distribution (like pfSense), not something that could be added to pfSense.

Yes, the ring setup is to simplify and to test any possible solutions. The real system has 8 nodes, so 28 tunnels according to your equation - so some connections will go over double hops, especially those which do not see a lot of traffic. Obviously, finding a cost distribution which fixes the issue is not that easy either with 8 nodes.

If it were possible to have ACK traffic be forced to go the same way SYN traffic came, problem solved. Jimp hinted at something in the other thread, with a solution in 2.5.0, but it doesn't seem to work yet. (See here).

Yes, it sounds like the problem others had where the patches on 9668 helped.

@nzkiwi68 I was having the same issue, and couldn't figure out why FRR 0.6.3_1 on 2.2.4-p3 was refusing to advertise route to openVPN tunnel, and then I came across your suggestion. Works great!

@jimp I still need to use a supernet to get FRR OSPF to advertise the subnet correctly despite it being on the latest version, so I think this ultimately an OS / OpenVPN issue as you described.

FreeBSD only supports one route per matching network so your FRR static route wouldn't stick because FreeBSD already has a route in its kernel routing table for the same network. Using a supernet works because that route doesn't already exist in your routing table.

Oddly enough it works as expected with IPv6, just not IPv4, but the behavior at the OS level is slightly different:
OpenVPN IPv4 subnet: 10.125.255.0 (was using /24 but wouldn't route, so used /26) on the OpenVPN interface instead.
OpenVPN IPv6 subnet: xxxx:yyyy:1100:a001::/64 you can see it shows up differently in the routing table and is properly advertised by OSPF6

In both cases OpenVPN's actual interface shows up as a loopback interface, but additionally in IPv4 it it puts in a /32 which is what initially shows up via OSPF.

10.125.255.0/26 10.125.255.2 UGS 0 1500 ovpns1 10.125.255.1 link#8 UHS 0 16384 lo0 10.125.255.1/32 ovpns1 U1 0 1500 ovpns1 10.125.255.2 link#8 UH 0 1500 ovpns1 xxxx:yyyy:1100:a001::/64 link#8 U 0 1500 ovpns1 xxxx:yyyy:1100:a001::1 link#8 UHS 0 16384 lo0

Update: If I put the 1:1 NATs on the IPsec interface and the VIPs as IP Aliases on Localhost I can get UDP and ICMP working. No TCP.