@beb-consulting I'm having the exact same problem. The service simply won't start. When I try to start it via the terminal here's what I get:
[21.05-RELEASE][admin@xg71001u]/var/etc/frr: /usr/local/etc/rc.d/frr restart all
Checking intergrated config...
line 15: % Unknown command: no bgp network import-check
line 16: % Unknown command: neighbor 169.254.0.1 remote-as 4200000002
line 17: % Unknown command: neighbor 169.254.0.1 description Google Cloud HA VPN (us-central1)
line 18: % Unknown command: neighbor 169.254.0.1 update-source 169.254.0.2
line 20: % Unknown command: address-family ipv4 unicast
line 21: % Unknown command: neighbor 169.254.0.1 activate
line 22: % Unknown command: no neighbor 169.254.0.1 send-community
line 23: % Unknown command: neighbor 169.254.0.1 prefix-list InboundNetworks in
line 24: % Unknown command: neighbor 169.254.0.1 prefix-list OutboundNetworks out
line 25: % Unknown command: exit-address-family
I have yet to find a solution and removing/reinstalling doesn't work at all.
UPDATE: Well this is embarrassing... Check the length of your ASN; e.g., If you're using a 4 byte ASN sure it's 10 digits... not 11. 😬
That was the reason BGP wasn't starting in my situation (one too many zeroes).
EDIT: To clarify, I had the BGP session up and running at one point but I needed to change the ASN in addition to a few other settings, and after making all my changes and restarting the service, that's when all hell broke loose. The snippet I posted earlier threw me off the trail since it gives no indication that you may have typo'd something in the GUI (side note to the frr package maintainers: can we get amaxlength="10" on that field and/or a better error message? 😀). You might also notice the ASN is the correct length in the output above; it was my local ASN that was incorrect.
Added an alias for RFC1918 networks and configured an outbound NAT rule with RFC1918 as source and any destination on all pfSenses.
This solved what seemed like a routing problem but turned out to be a NATing problem.
However I'll probably have issues if/when I have multiple WAN connections.
Still would like to hear if there are any best practices.
Very strange, I use pfSense 2.4.5-p1, 2.5.1-REL, 2.5.2-RC, 2.6.0-DEV with FRR doing BGP and this issue has always been solvable.
Only showstopper I have come across these past few weeks is https://redmine.pfsense.org/issues/11545 - If you assign virtual IPv6 addresses to WAN, FRR in pfSense may decide to use one of them for outbound communication, even to your BGP peers which will usually result in the session stuck in "active" and not getting "established" because the peer expects you to come from a specific address.
@zawi FRR OSPF in 2.5.1 in the overview screen: E.g. I don't know what Interface opt2 or opt3 is, if i do not enter a description manually. It would be very helpful to show the interface description from pfsense in this screen as well. Like:
opt2 ('Description from pfSense') => opt2 (OpenVPNS1)
I logged about 3 or 4 FRR-related issues. I saw that the ACCEPTFILTER bug already had a bug entry, as I didn't know at the time that the packages used a seperate bug tracking system.
For your issue, do the routes ever come back on their own if left long enough, or is the only fix resetting ospf/FRR? For my connected redistributed routes disappearing - they come back on their own, but they should never have dropped to begin with. Sounds like you might be dealing with a different issue.
If you have a lab setup (GNS3 perhaps) you could try replicating it there and try substituting a VyOS or OPNsense device to see if it is happening their as well. Or even just a generic FreeBSD (or Linux) setup with FRR installed. Since I'm not seeing any urgency to the issues I logged, I have moved to OPNsense already as the routing issues I faced with pfSense are all fixed there. Will keep tracking these issues in pfSense ocassionally to see if/when they are addressed by Netgate engineers.
@heper Nevermind, got it figured out. I had to add mess with the Firewall rules on the LAN side and change some Mappings on the WAN side to accommodate for the fact that none of the subnets we're trying to route/NAT were local to the netgate.
When you say traffic is not getting routed back you are talking about traffic coming from the internet back in to your network?
You have two different ISPs, with two different public IP addresses yes? Are you doing anything to maintain state? If your routes are equally weighted, sometimes packets may go out one or the other ISP making it hard to establish a TCP session.
Is there a reason you are using two separate firewalls, and not connecting both ISPs to the same firewall?
As for the static routes, all the routes you are showing us are from which device? It appears to be routing everything to 192.168.200.2 which is which device? and what do the routing tables on 192.168.200.2 look like?
@612brokeaf I've been interested in getting away from troglobit's pimd package as well and would love to switch to FRR's pimd. The main reason I'm interested in doing so is because I want to avoid using multiple packages by separate developers that could conflict with each other.
Yeah a cleaner solution would be nice, but troglobit's pimd works. MSDP is what I'm really after with FRR's pimd, otherwise the other pimd works fine.
My understanding; however, is that FRR's implementation of PIMD isn't quite as complete as troglobit's pimd.
That's in FreeBSD. FRR isn't as widely used and tested on FreeBSD as it is on Linux (bar pfSense maybe).
Perhaps that's what you meant when you said that you're after SM and not SSM. I'm not quite familiar with the differences there.
I should have stated ASM not SM, still sparse mode. Any Source Multicast - join to *,G(roup) rather than S(ource),G. With SSM there is no need for an RP, you just send joins towards the source. I need static RPs so BSR is of not much use for me.
I need to eliminate slow start for multicast so I'm looking at FRR's pimd mostly because of MSDP, so I can have local RPs / anycast RP between sites. Right now I am forced to place the RP in one location, with loss or resiliency under failure conditions. I may be forced to use BSR.
Anyhow, over years of using pfSense I think I've learned to trust their judgement more. If a package is not available, 4/5 chance it's for a good reason.
I would still ove to hear from the team re. how frequent multicast requirements are, especially for non-local distribution. PfSense is seen as a security/fw first, routing second, type of platform.
@marcus_1302 it wasn’t very clear because you said you were trying to actually install it, not just document the last version to support it. Glad you got your answer. But yeah, check out the dynamic routing with FRR hangout (https://youtu.be/4IlKcB17rWk), Jim talks a bit about converting OpenBGPd installs to FRR.
You may check the raw configuration in frr.conf, does it make any changes in the configuration when this option is selected? Furthermore if you dont want to distribute any routes, why should it be listed in the interfaces?
We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.
Subscribe to our Newsletter
Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.