pimd
-
@maximushugus, @louis2, @jeffscott
Hey all, if you don't mind, I have a general question for those of you that are using pimd. Are you using pim to route upstream pim-ssd from the WAN into your LAN segments? Or are you using pimd to bridge multicast between your LAN segments? Thanks.
-
I am (was) using pimd to make my media server accessible form multiple local vlan's.
To be more precise, my actual media server is implemented using a VM and running in my 'virtual machine vlan'. The destinations are some other vlan's among them my private pc-lan and guest-lan.
-
@dennypage bridge multicast between LAN segments here.
-
I have been querying the internet using ^multicast pimd versus pimd d^ and AI did give me this answer
PIM-DM (Dense Mode) and pimd (a daemon implementing PIM-SM) are both multicast routing protocols, but they operate differently. PIM-DM floods multicast traffic to all interfaces and relies on pruning to remove unwanted traffic, while pimd, when configured for PIM-SM (Sparse Mode), uses a Rendezvous Point (RP) to direct traffic to receivers, building source trees based on requests.
So that is probably the difference between the two pimd versions. So using pimd without dd is probably the better option for my/our problem
-
@louis2 Thanks. I understand PIM. My question was to discover if there was anyone with a use case for multicast routing beyond bridging local networks.
-
@dennypage, @maximushugus, @louis2, @jeffscott
Good news!
I have the PIMD version I did compile yesterday working !!
Including the related pfSense gui.Not I think I can make it running the way it should in the coming week(??).
Note that at this moment I still have the following issues:
- The warnings at compile time. Surely NOT OK!
=> I do not have the knowledge to fix this. but it does not be blocking. - The man directory issue.
=> I have no idea how to solve that. My actual work around is removing the manual files from package definitions (NOT OK) - Pimd does not run using the GUI.
=> At this moment I have to start pimd from the command line in debug mode and restart pimd after each config change. However pimd is running and I can access my media server.
pimd -n -f /var/etc/pimd/pimd.conf --disable-vifs -l debug=all - the firewall rules are not yet as they should be, for the test I just opened too much.
So I have to sort out things in the coming week/weeks. But I have good hope that I can solve points 3 and 4.
If someone can solve points 1 and 2, it would be highly appreciated!!
- The warnings at compile time. Surely NOT OK!
-
Note that I have posted a compiled version of PIMD in a separate thread a week ago (folder development).
-
@louis2
Hello ! Thank you for your work with pimd !
I have been able to test your pimd binary, it seem to work but I still have the same bug I discribed here
When starting PIMD, after a few seconds it works as it should, seeing multicast sources and routing it if needed.
But after about 3 minutes, PIMD is "loosing" multicast sources even if pfSense still receive this multicast traffic (packet capures, and network traffic). PIMD does not "receive" multicast source anymore. Restarting PIMD makes it see again multicast sources until it looses it again after about 3 minutes.@louis2 do you have the same problem ?
I really do not understand why I have this -
Hi all, just wanted do a followup on why I originally asked the question:
Are you using pim to route upstream pim-ssd from the WAN into your LAN segments? Or are you using pimd to bridge multicast between your LAN segments?
The reason was that I was in the process of creating a simpler alternative, mcast-bridge, for the common use case of bridging multicast traffic between LAN segments.
If you care to have a look, mcast-bridge has been released, and you can find information about it here.
There is also a package for pfSense pending. Some additional information regarding the package, including screenshots of the configuration, can be found in the forum here.
-
Thanks!
I have been watching this for a while in order to spread the love.. (multicast) among a number of remote sites to solve an issue that we have presently. I would elaborate but.. yeah..Thank you for your hard work!
-
@dennypage Hello !
Thank you for your work !
From what I've seen mcast-bridge is easier than PIMD to configure and lighter.
But it doesn't have the capability to transmit multicast routes between multiple router as PIMD has ? Or it has to be manually configured on each router.
So mcast-bridge seems more suited for routing multicast between muliple interfaces on the same router and PIMD for routing multicast between multiple routers ? -
@maximushugus said in pimd:
So mcast-bridge seems more suited for routing multicast between muliple interfaces on the same router and PIMD for routing multicast between multiple routers ?
PIM is a routing entity. It builds sparse routing trees and forwards multicast along those trees.
mcast-bridge is a bridging entity. It forwards multicast from one interface to another.
You can of course manually construct trees using mcast-bridge, but they would be dense instead of sparse, and you would have to ensure there are no loops in the configuration.
-
@dennypage said in pimd:
PIM is a routing entity. It builds sparse routing trees and forwards multicast along those trees.
mcast-bridge is a bridging entity. It forwards multicast from one interface to another.
Ok this is what i thought but didn't have the exact term. Now it's clear

Do you know is mcast-bridge can be used at the same time as PIMD, with disabling IGMP querier in mcast-bridge ?
Because most of the time only one "multicast routing" program can be used at a time. For example PIMD and IGMP-proxy cannot be used at the same time. Probably because both needs to be a querier.
I'm asking this because it would solve the lack of pim-to-igmp-proxy solution in PIMD. For reference here is the solution for Juniper router : pim-to-igmp-proxy.We would need such a thing on a network running PIM, and that also need to get a multicast stream from an interface on wich we do not controle the next router, not compatible with PIM. For reference here is a github issue about this problem.
-
@maximushugus said in pimd:
Do you know is mcast-bridge can be used at the same time as PIMD, with disabling IGMP querier in mcast-bridge ?
Because most of the time only one "multicast routing" program can be used at a time. For example PIMD and IGMP-proxy cannot be used at the same time. Probably because both needs to be a querier.Neither should need to be the active querier.
IGMP was specifically designed to separate the role of multicast router/forwarder and querier. There are often multiple router/forwarders present in the network, but only one querier. Note also that the querier does not even have to be a multicast router/forwarder.
The role of the active querier in the network is filled by election. People sometimes forget that the only thing special about a querier is that it is the one responsible for sending the IGMP query (please report status) messages to the network. That's it, and being the active querier (or not) should have no impact whatsoever on routing/forwarding decisions.
For purpose of discussion, let's say that you have have 4 entities in the network that are capable of being a querier:
- Network Switch
- mcast-bridge
- pimd
- IGMP-Proxy
If all four of these entities are at different IP addresses, there is no conflict. Whichever entity has the lowest numeric IP address will be elected the querier, and the rest will passively monitor the multicast state of the network based on seeing the multicast messages of the querier and clients.
Now, if two of these entities operate from the same IP address, and that address is the lowest numeric IP, then there will be a minor conflict because both entities will believe that they have won the election. I say minor because there will be multiple entities sending out IGMP query messages to the network. The downside of this will be excess IGMP reporting messages flying around, but as the reporting interval is generally every 125 seconds, this is not as bad as it might sound unless you have large numbers of multicast groups in operation.
Going back to the list of four, the best entity to use as the querier is the Network Switch, although it generally requires some configuration. If the switch has IGMP snooping enabled, and is at the lowest IP address, the switch will be elected naturally. If it doesn't have the lowest IP address, you have to disable the querier functions of anything installed at a lower IP address so that the switch wins the election.
NB: Regardless of who the querier is, it's critical to ensure that the switch ports that the software entities are connected to are configured as multicast routing ports--if you don't you'll generally see stuff work okay for a a couple of minutes following startup, and then stop working shortly thereafter when the switch turns multicast on the ports off.
Going again back to the list, given a choice between the querier implementation in mcast-bridge and pimd, I would prefer the IGMP implementation in mcast-bridge. The reason for this is that pimd operates at the raw socket level, which means that it is limited to operating as querier only for the groups that it is explicitly configured for. The IGMP implementation in mcast-bridge operates at a raw packet level, and is able to operate as a general querier, supporting up to a hundred multicast groups beyond what it is explicitly configured to forward.
I haven't spent much time looking at the IGMP implementation in IGMP Proxy, but I expect it shares the same limitations as pimd, and can only act as a querier for explicitly configured groups.
Hopefully this helps clarify some things.
-
@dennypage Ok well explained !
So probably PIMD and IGMP-proxy operate at raw socket both and that's why u cannot launch both at the same time on the same system ?I don't have a pfSense package for mcast-bridge (I'll compile it later when I have enough time), so I cannot test for the moment if PIMD and mcast-bridge can be used at the same time on the same system : do you know if it's the case ? Thanks
-
@maximushugus said in pimd:
@dennypage Ok well explained !
So probably PIMD and IGMP-proxy operate at raw socket both and that's why u cannot launch both at the same time on the same system ?Operating at the raw socket level itself should be no issue. However, pimd and IGMP Proxy both attempt to control the OS's multicast routing tables, which would be a conflict.

I don't have a pfSense package for mcast-bridge (I'll compile it later when I have enough time), so I cannot test for the moment if PIMD and mcast-bridge can be used at the same time on the same system : do you know if it's the case ?
For data, mcast-bridge uses standard OS user level calls recvfrom, sendto, IP_ADD_MEMBERSHIP and IP_DROP_MEMBERSHIP.
For IGMP, mcast-bridge bypasses the kernel and uses raw packet reception/injection.
mcast-bridge does not manipulate system routing tables in any way. In short, I don't see where a conflict would arise, however YMMV.
-
If some are interested in mcast-bridge, I build the program for pfSense : mcast-bridge.zip. You have to download, extract and install pfSense-pkg-mcast-bridge-1.2.pkg via
pkg add pfSense-pkg-mcast-bridge-1.2.pkgI can also confirm it work with PIMD running.
@dennypage I have a question : why do you exclude interfaces with a gateway from the available interfaces in mcast-bridge ?
To test it I had to comment line 61 to 65 in mcast_bridge_edit.php
And then I had my WAN interface listed (on a lab with VMs), and using it without problem. -
@maximushugus said in pimd:
hy do you exclude interfaces with a gateway from the available interfaces in mcast-bridge ?
To test it I had to comment line 61 to 65 in mcast_bridge_edit.php
And then I had my WAN interface listed (on a lab with VMs), and using it without problem.That is the recommended way to exclude wan interfaces from selection. Most of my packages, mdns-bridge, mcast-bridge, andwatch, are not intended to be used on wan interfaces.
pimd, which supports upstream routing protocols, is a better choice for a wan interface. mcast-bridge is a better choice if bridging between local interfaces.
-
@dennypage I agree generaly it's better not to use mdns with wan.
But for a multicast "bridge" or "proxy" I think it's usefull.
Without this wan possibility mcast-bridge cannot be used to bridge IPTV from a ISP for example.
Or in my case be used in complement with PIMD, on an interface connected to WAN on wich the next router / gateway doesnt speak PIM but understand IGMP (as I said PIM to IGMP proxy).
So maybe an option to enable this on mcast-bridge could be a solution to my "nasty" modification of the php file ? -
@maximushugus said in pimd:
Or in my case be used in complement with PIMD, on an interface connected to WAN on wich the next router / gateway doesnt speak PIM but understand IGMP (as I said PIM to IGMP proxy).
Can you share a network diagram showing your use case?
Privacy Policy · Cookie Policy