mrouted(8)mrouted(8)NAMEmrouted - IP multicast routing daemon
SYNOPSIS
/etc/mrouted [-p] [-c config_file] [-d [debug_level]]
OPTIONS
Specifies that mrouted is to start as a nonpruning router. This can
also be specified in the configuration file (see the Configuration File
section). Specifies an alternative configuration file instead of
/etc/mrouted.conf. Specifies the debugging level (default is 2). If
the -d option is not specified or if the debug level is specified as 0,
mrouted detaches from the invoking terminal. Otherwise, it remains
attached to the invoking terminal and responsive to signals from that
terminal.
Regardless of the debug level, mrouted always writes warning and
error messages to the system log demon. Nonzero debug levels
have the following effects: Prints all syslog messages to
stderr. Prints all level 1 messages and notifications of sig‐
nificant events to stderr. Prints all level 2 messages and
notifications of all packet arrivals and departures to stderr.
DESCRIPTION
The mrouted program is an implementation of the Distance-Vector Multi‐
cast Routing Protocol (DVMRP), an earlier version of which is specified
in RFC1075. The mrouted program maintains topological knowledge using a
distance-vector routing protocol (like Routing Information Protocol
(RIP), described in RFC1058), upon which it implements a multicast
datagram forwarding algorithm called Reverse Path Multicasting.
The mrouted program forwards a multicast datagram along a shortest
(reverse) path tree rooted at the subnet on which the datagram origi‐
nates. The multicast delivery tree may be thought of as a broadcast
delivery tree that has been pruned back so that it does not extend
beyond those subnetworks that have members of the destination group.
Hence, datagrams are not forwarded along those branches which have no
listeners of the multicast group. The IP time-to-live of a multicast
datagram can be used to limit the range of multicast datagrams.
In order to support multicasting among subnets that are separated by
(unicast) routers that do not support IP multicasting, mrouted includes
support for tunnels, which are virtual point-to-point links between
pairs of mrouted programs located anywhere in an internet. IP multi‐
cast packets are encapsulated for transmission through tunnels, so that
they look like normal unicast datagrams to intervening routers and sub‐
nets. The encapsulation is added on entry to a tunnel, and stripped
off on exit from a tunnel. By default, the packets are encapsulated
using the IP-in-IP protocol (IP protocol number 4). Older versions of
mrouted tunnels use IP source routing, which puts a heavy load on some
types of routers. This version does not support IP source route tun‐
neling.
The tunneling mechanism allows mrouted to establish a virtual internet,
for the purpose of multicasting only, that is independent of the physi‐
cal internet and can span multiple autonomous systems. This capability
is intended for experimental support of internet multicasting only,
pending widespread support for multicast routing by the regular (uni‐
cast) routers. The mrouted program suffers from the well-known scaling
problems of any distance-vector routing protocol, and does not support
hierarchical multicast routing.
The mrouted program handles multicast routing only; there may or may
not be unicast routing software running on the same machine as mrouted.
With the use of tunnels, it is not necessary for mrouted to have access
to more than one physical subnet in order to perform multicast forward‐
ing.
Upon startup, mrouted writes its PID to the /var/run/mrouted.pid file.
Configuration File
The mrouted program automatically configures itself to forward on all
multicast-capable interfaces (all interfaces except the loopback inter‐
face that have the IFF_MULTICAST flag set), and it finds other mrouted
programs directly reachable through those interfaces. To override the
default configuration or to add tunnel links to other mrouted programs,
place configuration commands in the /etc/mrouted.conf file (or an
alternative file specified by the -c option). The syntax of the valid
configuration commands are as follows:
phyint local-addr [disable] [metric m] [threshold t]
[rate_limit b] [boundary (boundary-name|scoped-addr/mask-len)]
[altnet network/mask-len]
tunnel local-addr remote-addr [metric m] [threshold t]
[rate_limit b] [boundary (boundary-name|scoped-addr/mask-len)]
cache_lifetime ct
pruning off|on
name boundary-name scoped-addr/mask-len
The file format is free-form; whitespace (including newlines) is not
significant. Specify the boundary and altnet options as many times as
necessary.
A description of each command is as follows: Disables multicast routing
on the physical interface identified by the local IP address local-
addr, or associates a nondefault metric or threshold with the specified
physical interface. The local IP address, local-addr, may be replaced
by the interface name (for example, le0). If a phyint command is
attached to multiple IP subnets, describe each additional subnet with
the altnet keyword. The phyint commands must precede tunnel commands.
Establishes a tunnel link between the local IP address local-addr and
the remote IP address remote-addr, and associates a nondefault metric
or threshold with that tunnel. The tunnel must be set up in the
mrouted.conf files of both routers before it can be used. Specifies
the amount of time that a cached multicast route stays in the kernel
before timing out. The value of this entry can be between 300 (5 min‐
utes) and 86400 (1 day). The default is 300. Specifies that mrouted
is to act as a nonpruning router. This can also be done when you start
mrouted by specifying the -p option on the command line. It is
expected that a router will be configured in this manner for testing
purposes only. The default mode is pruning enabled. Assigns names to
boundaries in order to ease configuration. The boundary option on
phyint or tunnel commands can accept either a name or a boundary.
The metric is the cost associated with sending a datagram on the given
interface or tunnel; it may be used to influence the choice of routes.
The metric defaults to 1. Metrics should be kept as small as possible,
because mrouted cannot route along paths with a sum of metrics greater
than 31.
The threshold is the minimum IP time-to-live required for a multicast
datagram to be forwarded to the given interface or tunnel. It is used
to control the scope of multicast datagrams. (The TTL of forwarded
packets is only compared to the threshold, it is not decremented by the
threshold. Every multicast router decrements the TTL by 1.) The
default threshold is 1.
In general, all mrouted programs connected to a particular subnet or
tunnel should use the same metric and threshold for that subnet or tun‐
nel.
The rate_limit option allows the network administrator to specify a
certain bandwidth in kilobits per second that would be allocated to
multicast traffic. It defaults to 500 Kb/s on tunnels; 0 (unlimited)
on physical interfaces.
The boundary option allows an interface to be configured as an adminis‐
trative boundary for the specified scoped address. Packets belonging
to this address are not forwarded on a scoped interface. The boundary
option accepts either a name or a boundary specification.
The mrouted program does not initiate execution if it has fewer than
two enabled virtual interfaces (vifs); a vif can be either a physical
multicast-capable interface or a tunnel. If all vifs are tunnels,
mrouted logs a warning; such mrouted configurations should be replaced
by more direct tunnels.
Sample Configuration File
The following is a sample configuration file for a fictitious multicast
router at a large academic institution:
# # mrouted.conf example # # Name our boundaries to make it easier name
LOCAL 239.255.0.0/16 name EE 239.254.0.0/16 # # le1 is our gateway to
compsci, do not forward our # local groups to them phyint le1
boundary EE # # le2 is our interface on the classroom net, it has four
# different length subnets on it. # note that you can use either
an ip address or an # interface name phyint 172.16.12.38 boundary EE
altnet 172.16.15.0/26 altnet 172.16.15.128/26 altnet
172.16.48.0/24 # # atm0 is our ATM interface, which does not properly #
support multicasting. phyint atm0 disable # # This is an internal tun‐
nel to another EE subnet # Remove the default tunnel rate limit, since
this # tunnel is over ethernets tunnel 192.168.5.4 192.168.55.101
metric 1 threshold 1 rate_limit 0 # # This is our tunnel to the
outside world. # Careful with those boundaries, Eugene. tunnel
192.168.5.4 10.11.12.13 metric 1 threshold 32 boundary LOCAL
boundary EE
EXAMPLES
Routing Table
The following is a sample routing table:
Virtual Interface Table
Vif Local-Address Metric Thresh Flags
0 36.2.0.8 subnet: 36.2 1 1 querier
groups: 224.0.2.1
224.0.0.4
pkts in: 3456
pkts out: 2322323
1 36.11.0.1 subnet: 36.11 1 1 querier
groups: 224.0.2.1
224.0.1.0
224.0.0.4
pkts in: 345
pkts out: 3456
2 36.2.0.8 tunnel: 36.8.0.77 3 1
peers: 36.8.0.77 (2.2)
boundaries: 239.0.1
: 239.1.2
pkts in: 34545433
pkts out: 234342
3 36.2.0.8 tunnel: 36.6.8.23 3 16
Multicast Routing Table (1136 entries)
Origin-Subnet From-Gateway Metric Tmr In-Vif Out-Vifs
36.2 1 45 0 1* 2 3*
36.8 36.8.0.77 4 15 2 0* 1* 3*
36.11 1 20 1 0* 2 3*
.
.
.
In the previous example, there are four vifs connecting to two subnets
and two tunnels. The vif 3 tunnel is not in use (no peer address). The
vif 0 and vif 1 subnets have some groups present; tunnels never have
any groups. This instance of mrouted sends periodic group membership
queries on the vif 0 and vif 1 subnets, as indicated by the querier
flags. The list of boundaries indicates the scoped addresses on that
interface. A count of the number of incoming and outgoing packets is
also shown at each interface.
Associated with each subnet from which a multicast datagram can origi‐
nate is the address of the previous hop router (unless the subnet is
directly-connected), the metric of the path back to the origin, the
amount of time since we last received an update for this subnet, the
incoming vif for multicasts from that origin, and a list of outgoing
vifs. An asterisk (*) means that the outgoing vif is connected to a
leaf of the broadcast tree rooted at the origin, and a multicast data‐
gram from that origin will be forwarded on that outgoing vif only if
there are members of the destination group on that leaf.
The mrouted program also maintains a copy of the kernel forwarding
cache table. Entries are created and deleted by mrouted.
Cache Table
The following is a sample cache table:
Multicast Routing Cache Table (147 entries)
Origin Mcast-group CTmr Age Ptmr IVif Forwvifs
13.2.116/22 224.2.127.255 3m 2m - 0 1 >13.2.116.19
>13.2.116.196
138.96.48/21 224.2.127.255 5m 2m - 0 1
>138.96.48.108
128.9.160/20 224.2.127.255 3m 2m - 0 1
>128.9.160.45
198.106.194/24 224.2.135.190 9m 28s 9m 0P >198.106.194.22
Each entry is characterized by the origin subnet number and mask and
the destination multicast group. A description of the remaining fields
is as follows: Indicates the lifetime of the entry. The entry is
deleted from the cache table when the timer decrements to zero. Indi‐
cates the time since this cache entry was originally created. Since
cache entries get refreshed if traffic is flowing, routing entries can
grow very old. Indicates the amount of time until the upstream prune
times out. This is a dash (-) if no prune was sent upstream. Indicates
the incoming vif for multicast packets from that origin. Each router
also maintains a record of the number of prunes received from neigh‐
bouring routers for a particular source and group. If there are no mem‐
bers of a multicast group on any downward link of the multicast tree
for a subnet, a prune message is sent to the upstream router. They are
indicated by a “P” after the vif number. Shows the interfaces along
which datagrams belonging to the source-group are forwarded. A “p”
indicates that no datagrams are being forwarded along that interface.
An unlisted interface is a leaf subnet with no members of the particu‐
lar group on that subnet. A “b” on an interface indicates that it is a
boundary interface; traffic is not forwarded on the scoped address on
that interface.
An additional line with a “>” as the first character is printed for
each source on the subnet. Note that one subnet can contain many
sources.
SIGNALS
The mrouted program responds to the following signals: Restarts
mrouted. The configuration file is reread every time this signal is
invoked. Sends good-bye messages to all neighboring routers and termi‐
nates execution. Same as INT. Dumps the internal routing tables to
the /var/tmp/mrouted.dump file. Dumps the internal cache tables to the
/var/tmp/mrouted.cache file. Dumps the internal routing tables to
stderr (only if mrouted was invoked with a nonzero debug level).
For convenience in sending signals, mrouted writes its PID to the
/var/run/mrouted.pid file upon startup.
FILES
Specifies the default configuration file. Specifies the mrouted PID
file. Specifies the default dump file. Specifies the default cache
file.
SEE ALSO
Commands: map-mbone(8), mrinfo(8), mtrace(8)
Networking: mbone.info(7)
DVMRP is described, along with other multicast routing algorithms, in
the paper Multicast Routing in Internetworks and Extended LANs by S.
Deering, in the Proceedings of the ACM SIGCOMM '88 Conference
AUTHORS
Steve Deering, Ajit Thyagarajan, Bill Fenner
mrouted(8)