SMCRoute - A static multicast routing daemon
Table of Contents
- Build & Install
- Origin & References
SMCRoute is a UNIX/Linux tool to manage and monitor multicast routes. It supports both IPv4 and IPv6 multicast routing.
Multicast routes exist in the UNIX kernel as long as a multicast routing daemon runs. On Linux, multiple multicast routers can run simultaneously using different multicast routing tables.
- Configuration file support,
- Support for restarting and reloading the
- Source-less on-demand routing, a.k.a. (*,G) based static routing
- Optional built-in mrdisc support, RFC4286
- Support for multiple routing tables on Linux
- Client with built-in support to show routes and joined groups
- Interface wildcard matching,
smcrouted [-nNhsv] [-c SEC] [-d SEC] [-e CMD] [-f CONF] [-l LVL] [-p USER:GROUP] [-t ID] smcroutectl [-Fkhv] [COMMAND] [⟨add | rem⟩ ⟨ROUTE⟩] [⟨join | leave⟩ ⟨GROUP⟩]
To set multicast routes and join groups you must first start the daemon,
which needs root privileges, or
to run the daemon in the foreground, as required by modern init daemons
like systemd and Finit.
/etc/smcroute.conf, which can look
something like this:
mgroup from eth0 group 126.96.36.199 mgroup from eth0 group 188.8.131.52 source 192.168.1.42 mroute from eth0 group 184.108.40.206 source 192.168.1.42 to eth1 eth2
The first line means "Join multicast group 220.127.116.11 on interface eth0".
eth0 is not directly connected to the source, but to a LAN
with switches with IGMP snooping. Joining the group opens up multicast
for that group towards
eth0. Only 20 groups can be joined, for large
setups investigate enabling multicast router ports in the switches, or
possibly use a dynamic multicast routing protocol.
mgroup is for source specific group join, i.e. the host
specifies that it wants packets from 192.168.1.42 and no other source.
mroute line is the actual layer-3 routing entry. Here we
say that multicast data originating from 192.168.1.42 on
eth0 to the
multicast group 18.104.22.168 should be forwarded to interfaces
Note: To test the above you can use ping from another device. The multicast should be visible as long as your IP# matches the source above and you ping 22.214.171.124 -- REMEMBER TO SET THE TTL >1
$ ping -I eth0 -t 2 126.96.36.199
The TTL is what usually bites people first trying out multicast routing.
Most TCP/IP stacks default to a TTL of 1 for multicast frames, e.g. ping
-t 2, or greater. This limitation is intentional and
reduces the risk of someone accidentally flooding multicast. Remember,
multicast behaves like broadcast unless limited.
The TTL should preferably be set on the sender side, e.g. the camera,
but can also be modified in the firewall on a router. Be careful though
because the TTL is the only thing that helps prevent routing loops! On
Linux the following
iptables command can be used to change the TTL:
# iptables -t mangle -A PREROUTING -i eth0 -d 188.8.131.52 -j TTL --ttl-inc 1
# smcrouted -e /path/to/script
-e CMD a user script or command can be called when
SIGHUP or installs a multicast route to the kernel. This
is useful if you, for instance, also run a NAT firewall and need to
flush connection tracking after installing a multicast route.
# smcrouted -N
-N command line option SMCRoute does not prepare all system
interfaces for multicast routing. Very useful if your system has a lot
of interfaces but only a select few are required for multicast routing.
Use the following in
/etc/smcroute.conf to enable interfaces:
phyint eth0 enable phyint eth1 enable phyint eth2 enable
It is possible to use any interface that supports the
Multiple Routing Tables
On Linux it is possible to run multiple multicast routing daemons due to its support for multiple multicast routing tables. In such setups it may be useful to change the default identity of SMCRoute:
# smcrouted -I mrt1 -t 1 # smcrouted -I mrt2 -t 2
-I NAME option alters the default syslog name, config file, PID
file, and client socket file name used. In the first instance above,
smcrouted will use:
and syslog messages will use the
mrt1 identity as well. Remember to
use the same
-I NAME also to
SMCRoute also has a client interface to interact with the daemon:
# smcroutectl join eth0 184.108.40.206 # smcroutectl add eth0 192.168.1.42 220.127.116.11 eth1 eth2
If the daemon runs with a different identity the client needs to be called using the same identity:
# smcrouted -I mrt # smcroutectl -I mrt show
There are more commands. See the man page or the online help for details:
# smcroutectl help
Note: Root privileges are required by default for
to the IPC socket permissions.
Multicast often originates from different sources but usually not at the same time. For a more generic setup, and to reduce the number of rules required, it is possible to set (*,G) IPv4 multicast routes.
phyint eth0 enable mrdisc phyint eth1 enable phyint eth1 enable mgroup from eth0 group 18.104.22.168 mroute from eth0 group 22.214.171.124 to eth1 eth2
or, from the command line:
# smcroutectl join eth0 126.96.36.199 # smcroutectl add eth0 188.8.131.52 eth1 eth2
Also, see the
smcrouted -c SEC option for periodic flushing of learned
(*,G) rules, including the automatic blocking of unknown multicast, and
smcroutectl flush command.
Another experimental feature is multicast router discovery, mrdisc,
described in RFC4286. This feature is disabled by default, enable
configure --enable-mrdisc. When enabled it periodically sends
out an IGMP message on inbound interfaces¹ to alert switches to open up
multicast in that direction. Not many managed switches have support for
¹ Notice the
mrdisc flag to the above
phyint eth0 directive, which
is missing for
Build & Install
SMCRoute should in theory work on any UNIX like operating system which supports the BSD MROUTING API. Both Linux and FreeBSD are tested on a regular basis.
On Linux the following kernel config is required:
CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y CONFIG_IP_MROUTE_MULTIPLE_TABLES=y # For multiple routing tables CONFIG_IPV6_MROUTE_MULTIPLE_TABLES=y # For multiple routing tables
On *BSD the following kernel config is required:
options MROUTING # Multicast routing options PIM # pimd extensions used for (*,G) support
Check the list of multicast capable interfaces:
or look for interfaces with the
MULTICAST flag in the output from:
Some interfaces have the
MULTICAST flag disabled by default, like
greN. Usually this flag can be enabled administratively.
Configure & Build
The GNU Configure & Build system use
/usr/local as the default install
prefix. In many cases this is useful, but this means the configuration
files and cache files will also use that same prefix. Most users have
come to expect those files in
/var/run/ and configure has
a few useful options that are recommended to use:
$ ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var $ make -j5 $ sudo make install-strip
As of SMCRoute v2.2 support for privilege separation using the
library was added. It is used to drop full root privileges at startup,
CAP_NET_ADMIN for managing the multicast routes.
The build system searches for the
libcap library and header file(s).
pkg-config are required.
Note: Although support is automatically detected, the build system
will issue a warning if
libcap is missing. This can be
Integration with systemd
For systemd integration
pkg-config are required.
When the unit file is installed,
systemctl can be used to enable and
$ sudo systemctl enable smcroute.service $ sudo systemctl start smcroute.service
Check that it started properly by inspecting the system log, or:
$ sudo systemctl status smcroute.service
Some people want to build statically, to do this with
autoconf add the
LDFLAGS= after the configure script. You may also need to
LIBS=..., which will depend on your particular system:
$ ./configure LDFLAGS="-static" ...
Building from GIT
configure script and the
Makefile.in files are generated and not
stored in GIT. So if you checkout the sources from GitHub you first
need to generated these files using
Origin & References
SMCRoute is maintained collaboratively at GitHub. Bug reports, feature requests, patches/pull requests, and documentation fixes are most welcome. The project was previously hosted and maintained by Debian at Alioth and before that by Carsten Schill, the original author.