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

FreeBSD Manual Pages


home | help
MROUTED(8)							    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
       responsive  to  signals	from  that  terminal.  Regardless of the debug
       level, mrouted always writes warning and	error messages to  the	system
       log  demon.   The debug-level argument is a comma-seperated list	of any
       of the following:

       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-
       capable 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	configuration,	or  to	add  tunnel  links  to other multicast
       routers,	configuration 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
		      interval.	 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-
		      access  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
		      default, mrouted discovers all locally  attached	multi-
		      cast 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
		      ifname) 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|ifname  argument.   Some  UNIX  kernels rewrite the
		      source address 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
		      defaults to 1.  Metrics should be	kept as	small as  pos-
		      sible, 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

       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
		      option 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
		      allows 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
       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
       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.
       Entries 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
       refreshed, if traffic is	flowing) when the timer	 decrements  to	 zero.
       The  'Age' field	is the time since this cache entry was originally cre-
       ated.  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	multi-
       cast 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
       dependent 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