mrouted - IP multicast routing daemon
/etc/mrouted [-p] [-c config_file] [-d [debug_level]]
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
significant events to stderr. Prints all level 2
messages and notifications of all packet arrivals
and departures to stderr.
The mrouted program is an implementation of the DistanceVector
Multicast 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 originates. 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 multicast packets
are encapsulated for transmission through tunnels, so
that they look like normal unicast datagrams to intervening
routers and subnets. 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-inIP
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 tunneling.
The tunneling mechanism allows mrouted to establish a virtual
internet, for the purpose of multicasting only, that
is independent of the physical 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
(unicast) 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 forwarding.
Upon startup, mrouted writes its PID to the
/var/run/mrouted.pid file.
Configuration File [Toc] [Back]
The mrouted program automatically configures itself to
forward on all multicast-capable interfaces (all interfaces
except the loopback interface 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|scopedaddr/mask-len)]
[altnet network/mask-len]
tunnel local-addr remote-addr [metric m] [threshold
t] [rate_limit b] [boundary (boundary-name|scopedaddr/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 minutes) 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 tunnel.
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 administrative 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 [Toc] [Back]
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 tunnel
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
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 OutVifs
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 originate 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 datagram 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 [Toc] [Back]
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. Indicates
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 neighbouring routers for a particular source and
group. If there are no members 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 particular 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.
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 terminates 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.
Specifies the default configuration file. Specifies the
mrouted PID file. Specifies the default dump file. Specifies
the default cache file.
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
Steve Deering, Ajit Thyagarajan, Bill Fenner
mrouted(8)
[ Back ] |
