Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (OSF1-V5.1-alpha)
Apropos / Subsearch:
optional field

mrouted(8)							   mrouted(8)


  mrouted - IP multicast routing daemon


  /etc/mrouted [-p] [-c	config_file] [-d [debug_level]]


  -p  Specifies	that mrouted is	to start as a nonpruning router.  This can
      also be specified	in the configuration file (see the Configuration File

  -c config_file
      Specifies	an alternative configuration file instead of

  -d [debug_level]
      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 fol-
      lowing effects:

      1	  Prints all syslog messages to	stderr.

      2	  Prints all level 1 messages and notifications	of significant events
	  to stderr.

      3	  Prints all level 2 messages and notifications	of all packet
	  arrivals and departures to stderr.


  The mrouted program is an implementation of the Distance-Vector 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 for-
  warding 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 subnet-
  works	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 (uni-
  cast)	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 encapsu-
  lation is added on entry to a	tunnel,	and stripped off on exit from a	tun-
  nel.	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 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 multi-
  cast 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

  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	con-
  figuration or	to add tunnel links to other mrouted programs, place confi-
  guration 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 signi-
  ficant.  Specify the boundary	and altnet options as many times as neces-

  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.

  pruning off|on
      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	com-
      mand 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 boun-
      dary option on phyint or tunnel commands can accept either a name	or a

  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

  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

  The boundary option allows an	interface to be	configured as an administra-
  tive 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
       name EE
       # 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 boundary EE altnet
	       altnet altnet
       # 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 metric	1 threshold 1
	       rate_limit 0
       # This is our tunnel to the outside world.
       # Careful with those boundaries,	Eugene.
       tunnel 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	   subnet: 36.2		 1	 1    querier
			  pkts in: 3456
			 pkts out: 2322323

	 1	   subnet: 36.11	 1	 1    querier
			  pkts in: 345
			 pkts out: 3456

	 2	   tunnel:	 3	 1
			    peers: (2.2)
		       boundaries: 239.0.1
				 : 239.1.2
			  pkts in: 34545433
			 pkts out: 234342

	 3	   tunnel:	 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	   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 boun-
  daries 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 mul-
  ticasts 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

  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     3m	  2m	-  0	1
	138.96.48/21     5m	  2m	-  0	1
	128.9.160/20     3m	  2m	-  0	1
	198.106.194/24     9m	 28s   9m  0P

  Each entry is	characterized by the origin subnet number and mask and the
  destination multicast	group.	A description of the remaining fields is as

  CTmr	  Indicates the	lifetime of the	entry.	The entry is deleted from the
	  cache	table when the timer decrements	to zero.

  Age	  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.

  Ptmr	  Indicates the	amount of time until the upstream prune	times out.
	  This is a dash (-) if	no prune was sent upstream.

  IVif	  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

	  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:

  HUP	  Restarts mrouted.  The configuration file is reread every time this
	  signal is invoked.

  INT	  Sends	good-bye messages to all neighboring routers and terminates

  TERM	  Same as INT.

  USR1	  Dumps	the internal routing tables to the /var/tmp/mrouted.dump

  USR2	  Dumps	the internal cache tables to the /var/tmp/mrouted.cache	file.

  QUIT	  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