Might be unique to FRR. FRR forked from quagga but it does have several ways that it differs. The config sytnax is still very similar so you can compare the ospf and zebra config files to see if there is some different option setup between them. It's possible that the quagga made an assumption that is now an optional behavior in the FRR package, which could explain the difference.

Hi, I have taken a look into some suggestions. First openvpn ist out of the box. The LWL is a 10GBit link. Even with ipsec and Intel acceleration the throughput is around 400mbit. Sounds like a good place for tnsr but until now I couldn't get a on side installation license. I tried using gateway groups which works fine on the branch office as uplink to the main office. But in the main office I have to add static routes so the brunch office, and there I can not use the gateway group in the static route. (Bomer!) Netgate support suggest only use frr. But I'm not shure how to setup this. The setup is two pfsense on main office and two in the branch office. In both office the LWL and wlan is connected to a switch which puts traffic in a dedicated vlan. This is done so both pfsense have access to both links. (Port multiplyer) There are two scenarios I think about. First a link goes down Second a pfsense goes down. In both cases network should continue work after a failover tome.which can be up to 2 to 3 minutes. On the inside interfaces in each office I use carp to Handel the failover when a pfsense box goes down. Know I need to Handel link failover and default gw in the branch office. Also routing from the main to the branch office. While taking a look at both scenarios. I sought I use frr with ospf which works fine except that the brunch office need to have both pfsense in the main office as default gw in case one pfsense goes down. And there need to bee a order/costs for the default routes so we don't end up having asynchronous routing. As far as I have read ospf and areas don't help me here or did I muss something? I would be glad to receive suggestions where to look into to get this setup up and working.

*" Hi all, I'm having some trouble understanding the role of assigning a gateway to an interface when one gets installed by an IP routing manager such as Zebra in the FRR package. I have a pfSense VM and have installed FRR. I've configured it to talk to two BGP neighbours for redundancy. They do this over the WAN - i.e. all on the same /29. Each of these neighbours provide a gateway to the internet. I use local BGP weights to preference one over the other. When I look at Diagnostics -> Routes, the gateway there is the one defined by System -> Routing -> Default Gateway IPv4. While it happens to be one of the neighbours, it's not the one I have preferenced. Is there a way to install a default route advertised by either of the BGP neighbours?"* Hello there! You have to know that there is a concept called AD which stands for administrative distance. AD used as a way to choose a route among other competing routes. So in case you define a default route from pfsense WebGUI actually you define a static default route. While default routes defined by BGP are dynamically defined. Here you have to now that the "AD of static default routes have a lower AD(lower means better in terms of AD) than BGP-learned routes. That is why the default route defined statically is the route according to which your traffic being forwarded to. Check out this link for further details about AD concept So to get route this issue simply don't define any "default routes" and pfsnse will route traffic according to BGP-learned routes assuming there are no "better" routes in the IP routing table. "Or am I doing this wrong and just use gateway groups (consisting of both the neighbours) instead and just ditch FRR/BGP altogether?" Well the answer depends on your needs. And by the way the gateway group is not an alternative to BGP protocol. If all you need a fail-over from one WAN to another one you can use gateway groups. No need for BGP at all. BGP is used for something very different although it can be used to receive default routes from ISP but actually you are wasting computing resources running BGP only for receiving defaults routes. If you need to traffic specific traffic for specific destinations over specific WAN then BGP is the answer assuming those destinations are changing dynamically. "The other thing I'd like to ask is what are the implications if I do/don't have a gateway defined under the WAN interface itself? I know that if there is no gateway defined then no automatic outbound NAT rules get created. Does this mean NAT is not happening before a packet leaves when entering from a LAN-like interface? Will outbound NAT rules get applied if I manually create them?" If you know what you do I guess you would face no issues with not designating an interface as WAN. for instance if know when NAT comes into play you really know when you have to use it. But in case you don't know about NAT and you simply attach your Internet access to an interface which is not designated as WAN then you would go into trouble by not being able to access the Internet. So designating an interface as WAN instruct pfsense to make a few assumptions such as, any traffic out of WAN interface should be NATed, WAN interface should be the default route.. etc. "Right now, I don't have a gateway defined under the WAN interface even though one is defined under System -> Routing -> Default Gateway. Yet from the outside, I can still get to my internal webservers via 1:1 NAT and appropriate firewall ACLs. I assume this is because it creates implicit rules to allow traffic back out like most firewalls do? If so, then is outbound NAT solely for traffic originating from a LAN-like interface and leaving the WAN interface?" Yes. pfsense behaves that way. You can even disable the auto-creation for ACLs which allow reply back connections. I guess a better question is this. When does NAT come into play? And the answer simply defined under Firewall->NAT->Outbound. That section tells you which traffic being NATed.

Just to close this off. I reinstalled 2.4.4, frr installed fine. Upgraded to 2.4.4_1 and FRR appears to be working, although I am having GUI config issues adding a BGP neighbor, but I suspect that is separate as I've seen this happen previously.

You were right. There was a configuration error on one of the ospf sites that was causing the asymmetric routing.

I admit, that was sort of a RTFM moment...

Thanks jimp... what I didnt mention these pfsense's were VMs that were between to different KVM hypervisors. these links provide a solution for any VNF / NFV peeps were kvm qemu is being used. I added OSPF to FW rules on both sides and then had to do this as well. (virsh edit domain) and vm (pfsense) reboot https://superuser.com/questions/944678/how-to-configure-macvtap-to-let-it-pass-multicast-packet-correctly https://libvirt.org/formatdomain.html#elementsNICS

the new version has add to pfsense? frr 5.0.1_2

@napsterbater jim said that it is cant use vtysh for pfsense. i think this bug for show ipv6 bgp up. always it cant show ipv6 bgp summary up . link text

Status of 2.4.4... I still loose routes when combining 2.4.3 with 2.4.4 and Cisco. But the good news is that it's not the case anymore with the following configurations: 1-pfSense 2.4.4 (priority 0), pfSense 2.4.4 (priority 0), DR Cisco (priority 1) 2-pfSense 2.4.4 (priority 0), BDR pfSense 2.4.4 (priority 1), DR Cisco (priority 1) In addition, both pfSense devices have the following setting: redistribute connected route-map DNR6 New issues: 1-After the upgrade to 2.4.4, connected interfaces are not redistributed anymore. As a workaround, disabling/enabling the interface sometimes works! And when not, it has to be re-created! 2-In order to have pfSense act as the BDR (the way we typically need it), it has to redistribute a default route to other routers in the area. At a minimum, the option "default-information originate" should be available on the UI with ideally the possibility to also select "always". When configured this way for both the DR and BDR, 2 default routes will end up on all the routers.

You could go for a completely manual config but the easiest workaround is what you did before, just add those networks to the manual list to distribute.

@jimp said in 2.4.4.a.20180716.1125 & frr 0.2_2 issues: That's a side effect of how the pkg edit interfac Many thanks Jim, think I'll pop in a redmine re the length of the password string, to either check the length before saving or mention in the text there is a length limit.

Digging further into the FRR OSPF IPV6 GUI functions i see more problems within the GUI and function of the FRR package: OSPF IPv6 doesn´t work with OPENVPN IPv6 P2P tunnels. Changing the OPSFv6 Interface to use the WAN Interface works perfectly. The IPv6 tunnel is working perfectly, FW Rules are set to "pass ipv4+6 * any any" but there is no OSPF "Hello" activity on the IPv6 tunnel, when OSPF6 ist set to use this tunnel as IPv6 activated interface with another FRR Pfsense on the other site. Usually OSPF IPv6 routes are based on the Link Local IP address of the interface, maybe this is a problem here, just guessing. OSPF IPv6 current version cannot use areas (not implemented yet) - so the OPSFv6 GUI is really misleading, we can change the area to some other, but there is no warning that there is no function behind that. There maybe a future version, where areas are supported in OPSF IPV6. OSPF Global Settings: The subnet field ist too short for a full IPv6 address, so a long IPv6 address is only partially displayed. OSPF6 Settings : the last part is really a problem, we can suppose, that there should be "Distribute Networks" and "Disable Redistribution" but non is there - only a subnet/area id field. There are some parts missing and it doesn´t work … even in OSPF v4 it doesn´t work. We really need an updated version of the FRR routing package, the current version is 5.x, where in Pfsense we are at 3.x. I really like that FRR package, but it is in a "BETA" State and with all this GUI problems not easy to implement. Regards Pete

Update. I think I fixed it. But I don't really understand it properly. I'd appreciate it if anyone can explain what's happening! I had to add some rules to Outbound NAT. On each pfSense I added a rule for all OpenVPN tunnel IP addresses (10.127.0.0/16 in my case) sources on the WAN to translate to the WAN interface address. This got the ping working via the third pfSenses during VPN outages. I then also added a rule for all IP addresses sourced from the LAN on the OpenVPN interface to translate to the OpenVPN interface address. In my example above, this meant NATing 192.168.128.0/24 on test1, 192.168.129.0/24 on test 2 etc. Now it works. If I set a ping going from one pfSense's lan to another, and I stop the VPN between the two, the pings get re-routed via the third pfSense. A few pings get lost while it's swapping, but this is what I wanted! Back of the net! Anyway, as I said, if anyone can explain what's happening here, that would be great. I won't mark this [SOLVED] just yet until I'm sure I've done this correctly. p.s. Don't you love it when things start to work just before pub o'clock!

In order for FRR to work with BFD you currently need PTMD.  This is planned to be fixed in a future release of FRR.