@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?
In case anyone stumbles across this. The solution is to create a rule on the LAN interface that uses the "default" gateway for packets headed toward subnets that live on the other side of the VTI tunnels. This new rule needs to be higher in the list than the rule that you create which redirects incoming packets to a gateway group.
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.