Pimd support?
-
Now that FRR has working PIM+MSDP, what's the status of enabling it in pfSense, at least via raw config? Tried building FRR 7.5 on FreeBSD 12.2 and pimd builds cleanly - have not tested it yet but it's there.
With IoT, various discovery mechanisms, etc., and, well, anything else multicast, multicast between sites can be a necessity sometimes.
For the last n years I've just been installing (troglobit) pimd from FreeBSD, but now there is a better integrated alternative.
Is there any demand for this? And what work is necessary for minimal support?
-
You can install PIMD package and configure it from the pfSense WebGUI:
-
@viktor_g yeah this is what I've been using but I started using it before it was available as a package in pfSense and never bothered checking if there is a package for it. But this is not what I am asking - I am asking about enabling FRR's pimd, which is a different component that is integrated into vtysh / zebra.
-
OK - I've read up FRR docs about this.
https://docs.frrouting.org/en/latest/pim.html
OpenBSD has no multicast support and FreeBSD, and NetBSD only have support for SSM.I am after SM not SSM, so it has to be the external pimd package - @viktor_g thank you for pointing out that there is a package for this now.
-
@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. I like the fact that FRR is so close to being able to provide all of my Linux networking needs in a single integrated package with one set of closely knit developers.
My understanding; however, is that FRR's implementation of PIMD isn't quite as complete as troglobit's pimd. I read a while back that FRR's implementation doesn't support a dynamic BSR and RP election process based on candidate BSR and RP priority values. I understand that it'll support and listen to BSR messages but that the actual determination of which router is the BSR and which router is the RP is still a static definition. So far this is a deal breaker for me given the level of complexity in my network. I was wondering if you've heard otherwise and whether they're working to add that functionality into FRR.
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.
-
@dutsnekcirf said in Pimd support?:
@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.
