mrouted man page on DigitalUNIX

Man page or keyword search:  
man Server   12896 pages
apropos Keyword Search (all sections)
Output format
DigitalUNIX logo
[printable version]

mrouted(8)							    mrouted(8)

NAME
       mrouted - 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)
[top]

List of man pages available for DigitalUNIX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net