*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->Tru64 Unix man pages -> mrouted (8)              



NAME    [Toc]    [Back]

       mrouted - IP multicast routing daemon

SYNOPSIS    [Toc]    [Back]

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

OPTIONS    [Toc]    [Back]

       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.

DESCRIPTION    [Toc]    [Back]

       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

       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

       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

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

EXAMPLES    [Toc]    [Back]

   Routing Table
       The following is a sample routing table:

       Virtual Interface Table
        Vif    Local-Address                      Metric   Thresh
         0       subnet:  36.2            1         1
                          pkts in: 3456
                         pkts out: 2322323

         1       subnet:  36.11          1        1
                          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   OutVifs

        36.2                                1     45    0    1* 2
        36.8            4    15    2    0*  1*
        36.11                               1     20    1    0* 2

       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

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

SIGNALS    [Toc]    [Back]

       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.

FILES    [Toc]    [Back]

       Specifies the default configuration file.   Specifies  the
       mrouted PID file.  Specifies the default dump file.  Specifies
 the default cache file.

SEE ALSO    [Toc]    [Back]

       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    [Toc]    [Back]

       Steve Deering, Ajit Thyagarajan, Bill Fenner

[ Back ]
 Similar pages
Name OS Title
multicast FreeBSD Multicast Routing
mrinfo HP-UX Multicast Routing Configuration Information Tool
route6d OpenBSD RIP6 routing daemon
route6d FreeBSD RIP6 Routing Daemon
gated IRIX gateway routing daemon
ogated Tru64 The gateway routing daemon
gated HP-UX gateway routing daemon
gated Tru64 gateway routing daemon
ip6rtrd Tru64 IPv6 routing daemon
IPXrouted FreeBSD IPX Routing Information Protocol daemon
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service