not an issue anymore https://forum.netgate.com/topic/158592/pfblockerng-devel-v3-0-0-no-longer-bound-by-unbound:
CHANGELOG:

Add Localhost at the default DNSBL Listening interface
(Suggest all existing users change to this interface)

Not sure where to go with this, is it not possible, do I need to submit it as a feature request instead?

Pfsense FRR is based on this :

https://github.com/FRRouting/frr/releases

we need an updated package from time to time.

After Gui blew up, I restarted 11/16, I disabled xagent on both the Global and BGP level.

IT reset BGP which should be a bug....

But after removing xagent BGP peered, I checked the BGP status and all worked well, same with the Global(all) status.

So somehow I have something configured wrong or xagent enabled break Gui.
Any takers?

Sounds like you might have created an asymmetric routing situation having nothing to do with BGP (other than distributing routes as instructed).

FRR has some outdated documention, ospfv3 with areas should work. Alternative solutions are depending on your environment and size of your networks. Its all about static vs dynamic routes. If you dont have lots of routes (eg. less then 50) ospfv3 isnt worth the efforts and time. If you are dealing with more routes, you have usually dedicated routers in place, which can handle ospfv3 very well, in this case is no need for FRR on pfsense.

On VirtualBox 6.1.14, with the exact same pfSenseVM, but one of the interfaces changed from 82540EM to virtio, I still see the configured IPv6 address used as the source OSPF6 address, so changed the vNIC type didn't change the behavior.

However, the funny thing is that I then added two new vNICs to the VM (one 82540EM and one virtio) and then configured an IPv6 address and OSPF6 on both. Lo and behold, both new interfaces send out OSPF6 Hellos with the link-local address!

I compared the interface and frrospf6dinterfaces>config sections for those interfaces and they're the same as the interface that use the configured IPv6 address. I really can't explain the behavior in difference that I'm observing.

! address-family ipv6 unicast network 2606:0000:a100::/56 network 2606:0000:a101::/56 neighbor 2606:0000:a120:5::12 activate neighbor 2606:0000:a120:5::13 activate no neighbor 2606:0000:a120:5::13 send-community exit-address-family !

So i changed the above to remove the route-map

And this allowed peering to come online.

Yes, test that patch if you're able to. It's also reported in the thread @pete35 linked to above.

The correct way to go about this is to open a bug report if you have found a bug:
https://redmine.pfsense.org/

Or add to an existing bug if there is one. It sounds like there may well be if what you're reporting affects a lot of users. But we can always merge or link them.

That way it can be tracked and seen by developers.

Steve

@Gcon, YES!

I was able to get it working. In fact, we built it out to cover sites in the US, Europe and the Asia Pacific areas. The failover works quite nicely.

It's been some time since I made the original post, so my memory is a little foggy. I can't remember the exact setting I changed to get it to work. But it can be done.

That client had some internal personnel shake-ups so I don't work on their systems anymore, but the last automated report I saw indicated they were still using it through the pandemic.

DM me and I see what I can do to help.

The route map name must have no spaces, and you could only use alphanumeric characters and/or hyphens (no underscores). Otherwise the route map won't work.

@Elegant Good to hear you got it sorted out. Which pfsense plugin was it frr or openbgpd?

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?