Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
MROUTED(8)		    System Manager's Manual		    MROUTED(8)

       mrouted - IP multicast routing daemon

       /usr/sbin/mrouted [ -c config_file ] [ -d [ debug_level ]]

       Mrouted	is  an implementation of the Distance-Vector Multicast Routing
       Protocol	(DVMRP), an earlier version of which is	specified in RFC-1075.
       It maintains topological	knowledge via a	distance-vector	routing	proto-
       col (like RIP, described	in RFC-1058), upon which it implements a  mul-
       ticast datagram forwarding algorithm called Reverse Path	Multicasting.

       Mrouted	forwards  a multicast datagram along a shortest	(reverse) path
       tree rooted at the subnet on which the datagram originates. The	multi-
       cast  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  mul-
       ticast  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 multicast routers 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.  The	packets	are encapsulated using the IP-
       in-IP protocol (IP protocol number 4).  Older versions of mrouted  tun-
       neled using IP source routing, which puts a heavy load on some types of
       routers.	 This version does not support IP source route tunnelling.

       The tunnelling mechanism	allows mrouted to establish a  virtual	inter-
       net,  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	multi-
       casting 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 multicast routing.

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

       -c config_file
		 Specifies an alternate	configuration file to  read  (normally

       -d debug_level
		 Turn  on  debugging; debug_level is a comma-seperated list of
		 subsections to	debug.

       If no "-d" option is given, mrouted detaches from the  invoking	termi-
       nal.   Otherwise,  it remains attached to the invoking terminal and re-
       sponsive	to signals from	that terminal.	Regardless of the debug	level,
       mrouted	always writes warning and error	messages to the	system log de-
       mon.  The debug-level argument is a comma-seperated list	of any of  the

       packet	    Display  the  type,	 source	and destination	of all packets
		    sent or received.

       pruning	    Display more information about prunes sent or received.

       routing	    Display more information about routing update packets sent
		    or received.

       route_detail Display  routing  updates in excruciating detail.  This is
		    generally way too much information.

       neighbors    Display information	about neighbor discovery.

       cache	    Display insertions,	deletions and refreshes	of entries  in
		    the	kernel forwarding cache.

       timeout	    Debug timeouts and periodic	processes.

       interface    Display  information about interfaces and their configura-

       membership   Display information	about group  memberships  on  physical

       traceroute   Display  information  about	 multicast traceroute requests
		    passing through this router.

       igmp	    Display IGMP  operation  including	group  membership  and
		    querier election.

       icmp	    Monitor ICMP handling.

       rsrr	    Monitor RSRR operation.

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

       Mrouted automatically configures	itself to forward on all multicast-ca-
       pable interfaces, i.e., interfaces that have the	IFF_MULTICAST flag set
       (excluding  the loopback	"interface"), and it finds other DVMRP routers
       directly	reachable via those interfaces.	 To override the default  con-
       figuration, or to add tunnel links to other multicast routers, configu-
       ration commands may be placed in	/etc/mrouted.conf (or  an  alternative
       file, specified by the "-c" option).

       The  file  format  is free-form;	whitespace (including newlines)	is not
       significant.  The file begins with commands  that  apply	 to  mrouted's
       overall operation or set	defaults.

       cache_lifetime secs
		      Specifies,  in seconds, the lifetime of a	multicast for-
		      warding cache entry in the kernel.  Multicast forwarding
		      cache  entries in	the kernel are checked every secs sec-
		      onds, and	are refreshed if the source is still active or
		      deleted  if not.	Care should be taken when setting this
		      value, as	a low value can	keep the kernel	cache small at
		      the  cost	of "thrashing" the cache for periodic senders,
		      but high values can cause	the kernel cache to grow unac-
		      ceptably large.  The default is 300 seconds (5 minutes).

       prune_lifetime secs
		      Sepcifies,  in  seconds,	the average lifetime of	prunes
		      that are sent towards  parents.	The  actual  lifetimes
		      will  be	randomized in the range	[.5secs,1.5secs].  The
		      default is 7200 (2 hours).  Smaller  values  cause  less
		      state  to	be kept	both at	this router and	the parent, at
		      the cost of more	frequent  broadcasts.	However,  some
		      routers  (e.g. mrouted <3.3 and all currently known ver-
		      sions of cisco's IOS) do not use the DVMRP generation ID
		      to  determine that a neighbor has	rebooted.  Prunes sent
		      towards these neighbors should be	kept short,  in	 order
		      to  shorten  the time to recover from a reboot.  For use
		      in this situation, the  prune_lifetime  keyword  may  be
		      specified	on an interface	as described below.

       noflood	      Mrouted  uses  a DVMRP optimization to prevent having to
		      keep individual routing tables for each  neighbor;  part
		      of  this optimization is that mrouted assumes that it is
		      the forwarder  for  each	of  its	 attached  subnets  on
		      startup.	 This  can cause duplicates for	a short	period
		      (approximately one full route  report  interval),	 since
		      both the router that just	started	up and the proper for-
		      warder will be forwarding	traffic.  This behavior	can be
		      turned  off  with	 the noflood keyword; mrouted will not
		      assume that it is	the forwarder on startup.  Turning  on
		      noflood  can  cause  black  holes	on restart, which will
		      generally	last approximately one full route  report  in-
		      terval.	The  noflood  keyword can also be specified on
		      individual interfaces.

       rexmit_prunes [on|off]
		      Mrouted's	default	is to retransmit prunes	on all	point-
		      to-point interfaces (including tunnels) but no multi-ac-
		      cess interfaces.	This option may	be used	 to  make  the
		      default	on   (or   off)	  for	all  interfaces.   The
		      rexmit_prunes keyword can	also be	specified on  individ-
		      ual interfaces.

       name boundary-name scoped-addr/mask-len
		      Associates  boundary-name	with the boundary described by
		      scoped-addr/mask-len, to help make interface  configura-
		      tions more readable and reduce repetition	in the config-
		      uration file.

       The second section of the configuration file, which may	optionally  be
       empty, describes	options	that apply to physical interfaces.

       phyint local-addr|ifname
		      The  phyint command does nothing by itself; it is	simply
		      a	place holder  which  interface-specific	 commands  may
		      follow.  An interface address or name may	be specified.

       disable	      Disables multicast forwarding on this interface.	By de-
		      fault, mrouted discovers all locally attached  multicast
		      capable interfaces and forwards on all of	them.

       netmask netmask
		      If  the kernel's netmask does not	accurately reflect the
		      subnet (e.g. you're using	proxy-ARP in lieu of  IP  sub-
		      netting),	 use  the netmask command to describe the real

       altnet network/mask-len
		      If a phyint is attached to multiple IP subnets, describe
		      each  additional	subnet	with the altnet	keyword.  This
		      command may be specified multiple	times to describe mul-
		      tiple subnets.

       igmpv1	      If  there	 are any IGMPv1	routers	on the phyint, use the
		      igmpv1 keyword to	force mrouted into IGMPv1  mode.   All
		      routers on the phyint must use the same version of IGMP.

       force_leaf     Force mrouted to ignore other routers on this interface.
		      mrouted will never send or  accept  neighbor  probes  or
		      route reports on this interface.

       In addition, the	common vif commands described later may	all be used on
       a phyint.

       The third section of the	configuration file, also  optional,  describes
       the configuration of any	DVMRP tunnels this router might	have.

       tunnel local-addr|ifname	remote-addr|remote-hostname
		      This  command  establishes  a  DVMRP tunnel between this
		      host (on the interface described by  local-addr  or  if-
		      name)  and  a  remote host (identified by	remote-addr or
		      remote-hostname).	 A remote hostname may only be used if
		      it  maps	to a single IP address.	 A tunnel must be con-
		      figured on both routers before it	can be used.

		      Be careful that the unicast route	to the remote  address
		      goes  out	 the interface specified by the	local-addr|if-
		      name argument.  Some UNIX	kernels	rewrite	the source ad-
		      dress  of	 mrouted's packets on their way	out to contain
		      the address of the transmission interface.  This is best
		      assured via a static host	route.

       The  common  vif	commands described below may all be used on tunnels or

       metric m	      The metric is the	"cost"	associated  with  receiving  a
		      datagram	on  the	 given	interface or tunnel; it	may be
		      used to influence	the choice of routes.  The metric  de-
		      faults  to 1.  Metrics should be kept as small as	possi-
		      ble, because DVMRP cannot	route along paths with	a  sum
		      of metrics greater than 31.

       advert_metric m
		      The  advert_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 advert_met-
		      ric defaults to 0.  Note that the	effective metric of  a
		      link  is	one  end's  metric  plus  the  other end's ad-

       threshold t    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 exactly 1.)  The default threshold	is 1.

       In general, all multicast routers connected to a	particular  subnet  or
       tunnel should use the same metric and threshold for that	subnet or tun-

       rate_limit r   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  0

       boundary	boundary-name|scoped-addr/mask-len
		      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.  This command
		      may be specified several times on	an interface in	 order
		      to describe multiple boundaries.

       passive	      No  packets will be sent on this link or tunnel until we
		      hear from	 the  other  end.   This  is  useful  for  the
		      "server" end of a	tunnel that goes over a	dial-on-demand
		      link; configure the "server" end as passive and it  will
		      not send its periodic probes until it hears one from the
		      other side, so will not keep the link up.	 If  this  op-
		      tion  is	specified on both ends of a tunnel, the	tunnel
		      will never come up.

       noflood	      As described above, but only applicable to  this	inter-

       prune_lifetime secs
		      As  described  above, but	only applicable	to this	inter-

       rexmit_prunes [on|off]
		      As described above, but only applicable to  this	inter-
		      face/tunnel.   Recall that prune retransmission defaults
		      to on on point-to-point links and	tunnels,  and  off  on
		      multi-access links.

		      By default, mrouted refuses to peer with DVMRP neighbors
		      that do not claim	to support pruning.  This  option  al-
		      lows such	peerings on this interface.

       notransit      A	 specialized case of route filtering; no route learned
		      from an interface	marked "notransit" will	be  advertised
		      on another interface marked "notransit".	Marking	only a
		      single interface "notransit" has no meaning.

       accept|deny (route/mask-len [exact])+ [bidir]
		      The accept and deny  commands  allow  rudimentary	 route
		      filtering.   The accept command causes mrouted to	accept
		      only the listed routes on	the configured interface;  the
		      deny command causes mrouted to accept all	but the	listed
		      routes.  Only one	of accept or deny commands may be used
		      on a given interface.

		      The  list	 of routes follows the accept or deny keyword.
		      If the keyword exact follows a  route,  then  only  that
		      route  is	 matched;  otherwise,  that route and any more
		      specific route is	matched.  For example, deny 0/0	 denys
		      all  routes, while deny 0/0 exact	denys only the default
		      route.  The default route	may also be specified with the
		      default keyword.

		      The bidir	keyword	enables	bidirectional route filtering;
		      the filter will be applied to routes on both output  and
		      input.   Without the bidir keyword, accept and deny fil-
		      ters are only applied on input.  Poison  reverse	routes
		      are never	filtered out.

       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  re-
       placed 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
       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 mes-
	      sages to all neighboring routers).

       TERM   same as INT

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

       USR2   dumps the	internal cache tables to /var/tmp/mrouted.cache.

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

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

       The routing tables dumped in /var/tmp/mrouted.dump look like this:

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

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

	 2	   tunnel:	 3	 1
			    peers: (3.255)
		       boundaries: 239.0.1/24
				 : 239.1.2/24
			  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	interface. A count of the no. 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.  "*" 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.

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

       The cache tables	dumped in /var/tmp/mrouted.cache 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 life-
       time of the entry.  The entry is	deleted	from the cache table  (or  re-
       freshed,	if traffic is flowing) 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 en-
       tries 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
       datagrams are being forwarded along that	interface. An unlisted	inter-
       face  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	inter-
       face,  i.e. traffic will	not be 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 there can be many
       sources in one subnet.  An additional line with	a  "<"	as  the	 first
       character is printed describing any prunes received from	downstream de-
       pendent neighbors for this subnet and group.

       /etc/mrouted.conf	mrouted's configuration	file.

       /var/run/	mrouted's PID file.

       /var/tmp/mrouted.dump	Where mrouted dumps  its  routing  table  when
				sent a SIGUSR1.

       /var/tmp/mrouted.cache	Where  mrouted dumps its forwarding cache when
				sent a SIGUSR2.

       Note that these files are located in the	following places on pre-4.4BSD

       /etc/mrouted.conf	mrouted's configuration	file.

       /etc/		mrouted's PID file.

       /usr/tmp/mrouted.dump	Where  mrouted	dumps  its  routing table when
				sent a SIGUSR1.

       /usr/tmp/mrouted.cache	Where mrouted dumps its	forwarding cache  when
				sent a SIGUSR2.

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

       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

4.2 Berkeley Distribution					    MROUTED(8)


Want to link to this manual page? Use this URL:

home | help