diff options
Diffstat (limited to 'usr.sbin/mrouted/mrouted.8')
| -rw-r--r-- | usr.sbin/mrouted/mrouted.8 | 319 |
1 files changed, 319 insertions, 0 deletions
diff --git a/usr.sbin/mrouted/mrouted.8 b/usr.sbin/mrouted/mrouted.8 new file mode 100644 index 0000000..5b9ee96 --- /dev/null +++ b/usr.sbin/mrouted/mrouted.8 @@ -0,0 +1,319 @@ +'\"COPYRIGHT 1989 by The Board of Trustees of Leland Stanford Junior University. +.TH MROUTED 8 +.UC 5 +.SH NAME +mrouted \- IP multicast routing daemon +.SH SYNOPSIS +.B /etc/mrouted +[ +.B \-p +] [ +.B \-c +.I config_file +] [ +.B \-d +[ +.I debug_level +]] +.SH DESCRIPTION +.I 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 protocol +(like RIP, described in RFC-1058), upon which it implements a multicast +datagram forwarding algorithm called Reverse Path Multicasting. +.PP +.I 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 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. +.PP +In order to support multicasting among subnets that are separated by (unicast) +routers that do not support IP multicasting, +.I mrouted +includes support for +"tunnels", which are virtual point-to-point links between pairs of +.IR mrouted s +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 +.I mrouted +tunnel using IP source routing, which puts a heavy load on some +types of routers. +This version supports IP source route tunnelling only for backwards +compatibility. +.PP +The tunnelling mechanism allows +.I 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. +.I Mrouted +suffers from the well-known scaling problems of any distance-vector +routing protocol, and does not (yet) support hierarchical multicast routing. +.PP +.I Mrouted +handles multicast routing only; there may or may not be unicast routing +software running on the same machine as +.IR mrouted . +With the use of tunnels, it +is not necessary for +.I mrouted +to have access to more than one physical subnet +in order to perform multicast forwarding. +.br +.ne 5 +.SH INVOCATION +.PP +If no "\-d" option is given, or if the debug level is specified as 0, +.I 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, +.I mrouted +always writes warning and error messages to the system +log demon. Non-zero debug levels have the following effects: +.IP "level 1" +all syslog'ed messages are also printed to stderr. +.IP "level 2" +all level 1 messages plus notifications of "significant" +events are printed to stderr. +.IP "level 3" +all level 2 messages plus notifications of all packet +arrivals and departures are printed to stderr. +.SH CONFIGURATION +.PP +.I 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 +.IR mrouted s +directly reachable +via those interfaces. To override the default configuration, or to add +tunnel links to other +.IR mrouted s, +configuration commands may be placed in +/etc/mrouted.conf (or an alternative file, specified by the "\-c" option). +There are four types of configuration commands: +.nf + + phyint <local-addr> [disable] [metric <m>] + [threshold <t>] [rate_limit <b>] + [boundary <scoped-addr>/<mask-len>] + + tunnel <local-addr> <remote-addr> [metric <m>] + [threshold <t>] [srcrt] [rate_limit <b>] + [boundary <scoped-addr>/<mask-len>] + + cache_lifetime <ct> + + pruning <off/on> + +.fi +.PP +One note about the configuration commands - all the phyint and tunnel +command options must be on a single line except for the boundary option +which may begin on a separate line. A single phyint or tunnel command may +have multiple boundary options. +.PP +The phyint command can be used to disable multicast routing 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 alternatively replaced by the +interface name (e.g le0) for the phyint command only. +Phyint commands must precede tunnel commands. +.PP +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 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. +For backwards compatibility with older +.IR mrouted s, +the srcrt keyword specifies +encapsulation using IP source routing. +.PP +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. +.PP +The pruning <off/on> option is provided for +.IR mrouted +to act as a non-pruning router. It is also possible to start +.Ir mrouted +in a non-pruning mode using the "-p" option on the command line. It is +expected that a router would be configured in this manner for test +purposes only. The default mode is pruning enabled. +.PP +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 +.I mrouted +cannot route along paths with a sum of metrics greater +than 31. +.LP +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. +.LP +In general, all +.IR mrouted s +connected to a particular subnet or tunnel should +use the same metric and threshold for that subnet or tunnel. +.PP +The rate_limit option allows the network administrator to specify a +certain bandwidth in Kbits/second which would be allocated to multicast +traffic. +.PP +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. +.PP +.I 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 +.I mrouted +configuration would be better replaced by more +direct tunnels (i.e., eliminate the middle man). +.SH SIGNALS +.PP +.I Mrouted +responds to the following signals: +.IP HUP +restarts +.I mrouted . +The configuration file is reread every time this signal is evoked. +.IP INT +terminates execution gracefully (i.e., by sending +good-bye messages to all neighboring routers). +.IP TERM +same as INT +.IP USR1 +dumps the internal routing tables to /usr/tmp/mrouted.dump. +.IP USR2 +dumps the internal cache tables to /usr/tmp/mrouted.cache. +.IP QUIT +dumps the internal routing tables to stderr (only if +.I mrouted +was invoked with a non-zero debug level). +.bp +.SH EXAMPLE +.PP +The routing tables look like this: +.nf + +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 In-Vif Out-Vifs + 36.2 1 0 1* 2 3* + 36.8 36.8.0.77 4 2 0* 1* 3* + 36.11 1 1 0* 2 3* + . + . + . + +.fi +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 +.I 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. +.PP +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 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. +.bp +.PP +.I Mrouted +also maintains a copy of the kernel forwarding cache table. Entries +are created and deleted by +.I mrouted. +.PP +The cache tables look like this: +.nf + +Multicast Routing Cache Table (325 entries) + Origin-Subnet Mcast-group CTmr IVif Prcv# Psnt Forwvifs + 134.207.7 224.2.140.239 300 1 0 0 2 + 138.15.103 224.2.203.214 295 1 2 P 0p 2p + 128.237.0 224.2.253.119 290 1 1 0 2p + 129.215.200 224.2.207.48 40 1 1 0p 2 + 36.77.14 239.0.1.234 345 2b + +.fi +Each entry is characterized by the origin subnet number and the +destination multicast group. The 'CTmr' field indicates the lifetime +(in seconds) of the entry. The entry is deleted from the cache table +when the timer decrements to zero. 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 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" in the Psnt field. 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 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 interface. + + +.SH FILES +/etc/mrouted.conf +.SH SEE ALSO +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. +.SH AUTHORS +Steve Deering & Ajit Thyagarajan |
