icon Top 9 categories map      RocketAware > man pages >


Tips: Browse or Search all pages for efficient awareness of more than 6000 of the most popular reusable and open source applications, functions, libraries, and FAQs.

The "RKT couplings" below include links to source code, updates, additional information, advice, FAQs, and overviews.


Search all pages


By activity
Professions, Sciences, Humanities, Business, ...

User Interface
Text-based, GUI, Audio, Video, Keyboards, Mouse, Images,...

Text Strings
Conversions, tests, processing, manipulation,...

Integer, Floating point, Matrix, Statistics, Boolean, ...

Algorithms, Memory, Process control, Debugging, ...

Stored Data
Data storage, Integrity, Encryption, Compression, ...

Networks, protocols, Interprocess, Remote, Client Server, ...

Hard World
Timing, Calendar and Clock, Audio, Video, Printer, Controls...

File System
Management, Filtering, File & Directory access, Viewers, ...


RocketLink!--> Man page versions: OpenBSD FreeBSD NetBSD Others

MROUTED(8)                                             MROUTED(8)

       mrouted - IP multicast routing daemon

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

       Mrouted is an implementation of the Distance-Vector Multi-
       cast Routing Protocol (DVMRP), an earlier version of which
       is specified in RFC-1075.  It maintains topological knowl-
       edge via a distance-vector  routing  protocol  (like  RIP,
       described  in RFC-1058), upon which it implements a multi-
       cast datagram forwarding  algorithm  called  Reverse  Path

       Mrouted  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 sub-
       networks 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 mul-
       ticasting, mrouted includes support for  "tunnels",  which
       are virtual point-to-point links between pairs of mrouteds
       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-in-IP
       protocol  (IP  protocol  number  4).   Older  versions  of
       mrouted tunnel using IP source routing, which puts a heavy
       load on some types of routers.  This version does not sup-
       port IP source route tunnelling.

       The  tunnelling  mechanism  allows  mrouted to establish a
       virtual internet, for the purpose  of  multicasting  only,
       which  is  independent of the physical internet, and which
       may 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.  Mrouted suffers from the
       well-known scaling problems of any distance-vector routing
       protocol,  and  does not (yet) support hierarchical multi-
       cast routing.

       Mrouted handles multicast routing only; there may  or  may
       not  be  unicast  routing  software  running  on  the same


MROUTED(8)                                             MROUTED(8)

       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.

       If no "-d" option is given, or if the debug level is spec-
       ified as 0, mrouted detaches from the  invoking  terminal.
       Otherwise,  it  remains  attached to the invoking terminal
       and responsive to signals from that terminal.  If "-d"  is
       given  with  no  argument,  the debug level defaults to 2.
       Regardless of the debug level, mrouted always writes warn-
       ing  and error messages to the system log demon.  Non-zero
       debug levels have the following effects:

       level 1
              all syslog'ed messages are also printed to  stderr.

       level 2
              all level 1 messages plus notifications of "signif-
              icant" events are printed to stderr.

       level 3
              all level 2  messages  plus  notifications  of  all
              packet  arrivals  and  departures  are  printed  to

       Upon  startup,  mrouted  writes  its  pid  to   the   file
       /var/run/mrouted.pid .

       Mrouted  automatically configures itself to forward on all
       multicast-capable interfaces, i.e., interfaces  that  have
       the IFF_MULTICAST flag set (excluding the loopback "inter-
       face"), and it finds other mrouteds directly reachable via
       those  interfaces.  To override the default configuration,
       or to add tunnel links to  other  mrouteds,  configuration
       commands  may be placed in mrouted.conf (or an alternative
       file, specified by the "-c" option).  There are four types
       of configuration commands:

           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>


MROUTED(8)                                             MROUTED(8)

       The  file  format is free-form; whitespace (including new-
       lines)  is  not  significant.   The  boundary  and  altnet
       options may be specified as many times as necessary.

       The  phyint command can be used to disable multicast rout-
       ing on the  physical  interface  identified  by  local  IP
       address <local-addr>, or to associate a non-default metric
       or threshold with the specified physical  interface.   The
       local  IP  address  <local-addr>  may  be  replaced by the
       interface name (e.g le0).  If a phyint is attached to mul-
       tiple IP subnets, describe each additional subnet with the
       altnet keyword.  Phyint commands must precede tunnel  com-

       The  tunnel command can be used to establish a tunnel link
       between  local  IP  address  <local-addr>  and  remote  IP
       address <remote-addr>, and to associate a non-default met-
       ric or threshold with that tunnel.  The local  IP  address
       <local-addr>  may  be replaced by the interface name (e.g.
       le0).  The remote IP address <remote-addr> may be replaced
       by  a host name, if and only if the host name has a single
       IP address associated with it.  The tunnel must be set  up
       in the mrouted.conf files of both routers before it can be

       The cache_lifetime is a value that determines  the  amount
       of  time  that  a  cached  multicast route stays in kernel
       before timing out. The value  of  this  entry  should  lie
       between 300 (5 min) and 86400 (1 day). It defaults to 300.

       The pruning <off/on> option is provided for mrouted to act
       as  a  non-pruning  router.  It  is also possible to start
       mrouted in a non-pruning mode using the "-p" option on the
       command  line.  It is expected that a router would be con-
       figured in this manner for test purposes only. The default
       mode is pruning enabled.

       You  may  assign names to boundaries to make configuration
       easier with the name  keyword.   The  boundary  option  on
       phyint  or  tunnel  commands can accept either a name or a

       The metric is the "cost" associated with sending  a  data-
       gram  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  inter-
       face or tunnel.  It is used to control the scope of multi-
       cast datagrams.  (The TTL of  forwarded  packets  is  only
       compared  to  the  threshold, it is not decremented by the


MROUTED(8)                                             MROUTED(8)

       threshold.  Every multicast router decrements the  TTL  by
       1.)  The default threshold is 1.

       In  general, all mrouteds 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 Kbits/second which would be
       allocated to multicast traffic.  It defaults to 500Kbps on
       tunnels, and 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  will  not  be
       forwarded  on  a  scoped  interface.   The boundary option
       accepts either a name or a boundary spec.

       Mrouted will not initiate execution if it has  fewer  than
       two  enabled  vifs,  where  a  vif  (virtual interface) is
       either a physical multicast-capable interface or a tunnel.
       It will log a warning if all of its vifs are tunnels; such
       an mrouted configuration would be better replaced by  more
       direct tunnels (i.e., eliminate the middle man).

       This  is an example configuration for a mythical multicast
       router at a big school.

       # mrouted.conf example
       # Name our boundaries to make it easier
       name LOCAL
       name EE
       # le1 is our gateway to compsci, don't 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 doesn't 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


MROUTED(8)                                             MROUTED(8)

       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

       Mrouted responds to the following signals:

       HUP    restarts  mrouted  .   The  configuration  file  is
              reread every time this signal is evoked.

       INT    terminates  execution  gracefully (i.e., by sending
              good-bye messages to all neighboring routers).

       TERM   same as INT

       USR1   dumps    the    internal    routing    tables    to

       USR2   dumps     the     internal    cache    tables    to

       QUIT   dumps the internal routing tables to  stderr  (only
              if  mrouted  was  invoked  with  a  non-zero  debug

       For convenience in sending signals, mrouted writes its pid
       to /var/run/mrouted.pid upon startup.


MROUTED(8)                                             MROUTED(8)

       The routing tables look like this:

       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  this  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  is  the one responsible for sending
       periodic group membership queries on the vif 0 and  vif  1
       subnets,  as indicated by the "querier" flags. The list of
       boundaries indicate the scoped addresses  on  that  inter-
       face.  A count of the no. of incoming and outgoing packets
       is also shown at each interface.

       Associated with each subnet from which a  multicast  data-
       gram  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.  "*" means  that  the  outgoing  vif  is


MROUTED(8)                                             MROUTED(8)

       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.


MROUTED(8)                                             MROUTED(8)

       Mrouted also maintains a copy  of  the  kernel  forwarding
       cache table. Entries are created and deleted by mrouted.

       The cache tables look like this:

       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.  The  'CTmr'
       field  indicates  the lifetime of the entry.  The entry is
       deleted from the cache table when the timer decrements  to
       zero.   The 'Age' field is the time since this cache entry
       was originally created.  Since cache entries get refreshed
       if  traffic is flowing, routing entries can grow very old.
       The 'Ptmr' field is simply a dash if  no  prune  was  sent
       upstream,  or  the amount of time until the upstream prune
       will time out.  The 'Ivif' field  indicates  the  incoming
       vif  for  multicast packets from that origin.  Each router
       also maintains a record of the number of  prunes  received
       from  neighboring  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.  The Forwvifs field shows
       the interfaces along  which  datagrams  belonging  to  the
       source-group  are forwarded. A "p" indicates that no data-
       grams  are  being  forwarded  along  that  interface.   An
       unlisted interface is a leaf subnet with are no members of
       the particular group on that subnet. A "b" on an interface
       indicates  that  it  is a boundary interface, i.e. traffic
       will not be forwarded on the scoped address on that inter-
       face.   An additional line with a ">" as the first charac-
       ter is printed for each source on the subnet.   Note  that
       there can be many sources in one subnet.


       mrinfo(8), mtrace(8), map-mbone(8)


MROUTED(8)                                             MROUTED(8)

       DVMRP  is  described,  along  with other multicast routing
       algorithms, in the paper "Multicast Routing  in  Internet-
       works and Extended LANs" by S. Deering, in the Proceedings
       of the ACM SIGCOMM '88 Conference.

       Steve Deering, Ajit Thyagarajan, Bill Fenner


Source: OpenBSD 2.6 man pages. Copyright: Portions are copyrighted by BERKELEY
SOFTWARE DESIGN, INC., The Regents of the University of California, Massachusetts
Institute of Technology, Free Software Foundation, FreeBSD Inc., and others.

(Corrections, notes, and links courtesy of RocketAware.com)

[Detailed Topics]
FreeBSD Sources for mrouted(8)
OpenBSD sources for mrouted(8)

[Overview Topics]

Up to: Multicast - Implementation of multicast routing for communications and networking

RocketLink!--> Man page versions: OpenBSD FreeBSD NetBSD Others

Rapid-Links: Search | About | Comments | Submit Path: RocketAware > man pages > mrouted.8/
RocketAware.com is a service of Mib Software
Copyright 1999, Forrest J. Cavalier III. All Rights Reserved.
We welcome submissions and comments