Commit | Line | Data |
---|---|---|
0a4d79af JH |
1 | '\"COPYRIGHT 1989 by The Board of Trustees of Leland Stanford Junior University. |
2 | .TH MROUTED 8 | |
3 | .UC 5 | |
4 | .SH NAME | |
5 | mrouted \- IP multicast routing daemon | |
6 | .SH SYNOPSIS | |
7 | .B /etc/mrouted | |
8 | [ | |
9 | .B \-c | |
10 | .I config_file | |
11 | ] [ | |
12 | .B \-d | |
13 | [ | |
14 | .I debug_level | |
15 | ] ] | |
16 | .SH DESCRIPTION | |
17 | .I Mrouted | |
18 | is an implementation of the Distance-Vector Multicast Routing | |
19 | Protocol (DVMRP), an earlier version of which is specified in RFC-1075. | |
20 | It maintains topological knowledge via a distance-vector routing protocol | |
21 | (like RIP, described in RFC-1058), upon which it implements a multicast | |
22 | forwarding algorithm called Truncated Reverse Path Broadcasting (TRPB). | |
23 | .PP | |
24 | .I Mrouted | |
25 | forwards a multicast datagram along a shortest (reverse) path tree | |
26 | rooted at the subnet on which the datagram originates. It is a | |
27 | .I broadcast | |
28 | tree, which means it includes | |
29 | .I all | |
30 | subnets reachable by a cooperating set of | |
31 | .I mrouted | |
32 | routers. However, the datagram will not be forwarded onto | |
33 | .I leaf | |
34 | subnets of the tree if those subnets do not have members of the destination | |
35 | group. Furthermore, the IP time-to-live of a multicast datagram may prevent | |
36 | it from being forwarded along the entire tree. | |
37 | .PP | |
38 | In order to support multicasting among subnets that are separated by (unicast) | |
39 | routers that do not support IP multicasting, | |
40 | .I mrouted | |
41 | includes support for | |
42 | "tunnels", which are virtual point-to-point links between pairs of | |
43 | .IR mrouted s | |
44 | located anywhere in an internet. IP multicast packets are encapsulated for | |
45 | transmission through tunnels, so that they look like normal unicast datagrams | |
46 | to intervening routers and subnets. The encapsulation | |
47 | is inserted on entry to a tunnel, and stripped out | |
48 | on exit from a tunnel. | |
49 | By default, the packets are encapsulated using the IP-in-IP protocol | |
50 | (IP protocol number 4). | |
51 | Older versions of | |
52 | .I mrouted | |
53 | encapsulate using IP source routing, which puts a heavy load on some | |
54 | types of routers. | |
55 | This version supports IP source route encapsulation only for backwards | |
56 | compatibility. | |
57 | .PP | |
58 | The tunnel mechanism allows | |
59 | .I mrouted | |
60 | to establish a virtual internet, for | |
61 | the purpose of multicasting only, which is independent of the physical | |
62 | internet, and which may span multiple Autonomous Systems. This capability | |
63 | is intended for experimental support of internet multicasting only, pending | |
64 | widespread support for multicast routing by the regular (unicast) routers. | |
65 | .I Mrouted | |
66 | suffers from the well-known scaling problems of any distance-vector | |
67 | routing protocol, and does not (yet) support hierarchical multicast routing | |
68 | or inter-operation with other multicast routing protocols. | |
69 | .PP | |
70 | .I Mrouted | |
71 | handles multicast routing only; there may or may not be a unicast | |
72 | router running on the same host as | |
73 | .IR mrouted . | |
74 | With the use of tunnels, it | |
75 | is not necessary for | |
76 | .I mrouted | |
77 | to have access to more than one physical subnet | |
78 | in order to perform multicast forwarding. | |
79 | .br | |
80 | .ne 5 | |
81 | .SH INVOCATION | |
82 | .PP | |
83 | If no "\-d" option is given, or if the debug level is specified as 0, | |
84 | .I mrouted | |
85 | detaches from the invoking terminal. Otherwise, it remains attached to the | |
86 | invoking terminal and responsive to signals from that terminal. If "\-d" is | |
87 | given with no argument, the debug level defaults to 2. Regardless of the | |
88 | debug level, | |
89 | .I mrouted | |
90 | always writes warning and error messages to the system | |
91 | log demon. Non-zero debug levels have the following effects: | |
92 | .IP "level 1" | |
93 | all syslog'ed messages are also printed to stderr. | |
94 | .IP "level 2" | |
95 | all level 1 messages plus notifications of "significant" | |
96 | events are printed to stderr. | |
97 | .IP "level 3" | |
98 | all level 2 messages plus notifications of all packet | |
99 | arrivals and departures are printed to stderr. | |
100 | .SH CONFIGURATION | |
101 | .PP | |
102 | .I Mrouted | |
103 | automatically configures itself to forward on all multicast-capable | |
104 | interfaces, i.e., interfaces that have the IFF_MULTICAST flag set (excluding | |
105 | the loopback "interface"), and it finds other | |
106 | .IR mrouted s | |
107 | directly reachable | |
108 | via those interfaces. To override the default configuration, or to add | |
109 | tunnel links to other | |
110 | .IR mrouted s, | |
111 | configuration commands may be placed in | |
112 | /etc/mrouted.conf (or an alternative file, specified by the "\-c" option). | |
113 | There are two types of configuration command: | |
114 | .nf | |
115 | ||
116 | phyint <local-addr> [disable] [metric <m>] [threshold <t>] | |
117 | ||
118 | tunnel <local-addr> <remote-addr> [metric <m>] [threshold <t>] [srcrt] | |
119 | ||
120 | .fi | |
121 | The phyint command can be used to disable multicast routing on the physical | |
122 | interface identified by local IP address <local-addr>, or to associate a | |
123 | non-default metric or threshold with the specified physical interface. | |
124 | Phyint commands must precede tunnel commands. | |
125 | .PP | |
126 | The tunnel command can be used to establish a tunnel link between local | |
127 | IP address <local-addr> and remote IP address <remote-addr>, and to associate | |
128 | a non-default metric or threshold with that tunnel. The tunnel must be set | |
129 | up in the mrouted.conf files of both ends before it will be used. | |
130 | For backwards compatibility with older | |
131 | .IR mrouted s, | |
132 | the srcrt keyword specifies | |
133 | encapsulation using IP source routing. | |
134 | .PP | |
135 | The metric is the "cost" associated with sending a datagram on the given | |
136 | interface or tunnel; it may be used to influence the choice of routes. | |
137 | The metric defaults to 1. Metrics should be kept as small as possible, | |
138 | because | |
139 | .I mrouted | |
140 | cannot route along paths with a sum of metrics greater | |
141 | than 31. When in doubt, the following metrics are recommended: | |
142 | .ne 5 | |
143 | .IP 1 | |
144 | LAN, or tunnel across a single LAN | |
145 | .IP 2 | |
146 | serial link, or tunnel across a single serial link | |
147 | .IP 3 | |
148 | multi-hop tunnel | |
149 | .LP | |
150 | The threshold is the minimum IP time-to-live required for a multicast datagram | |
151 | to be forwarded to the given interface or tunnel. It is used to control the | |
152 | scope of multicast datagrams. (The TTL of forwarded packets is only compared | |
153 | to the threshold, it is not decremented by the threshold. Every multicast | |
154 | router decrements the TTL by 1.) The default threshold is 1. | |
155 | Suggested thresholds: | |
156 | .IP 32 | |
157 | for links that separate sites, | |
158 | .IP 64 | |
159 | for links that separate regions, | |
160 | .IP 128 | |
161 | for links that separate continents. | |
162 | .LP | |
163 | In general, all | |
164 | .IR mrouted s | |
165 | connected to a particular subnet or tunnel should | |
166 | use the same metric and threshold for that subnet or tunnel. | |
167 | .PP | |
168 | .I Mrouted | |
169 | will not initiate execution if it has fewer than two enabled vifs, | |
170 | where a vif (virtual interface) is either a physical multicast-capable | |
171 | interface or a tunnel. It will log a warning if all of its vifs are | |
172 | tunnels; such an | |
173 | .I mrouted | |
174 | configuration would be better replaced by more | |
175 | direct tunnels (i.e., eliminate the middle man). | |
176 | .SH SIGNALS | |
177 | .PP | |
178 | .I Mrouted | |
179 | responds to the following signals: | |
180 | .IP HUP | |
181 | .sp -.5v | |
182 | .IP TERM | |
183 | .sp -.5v | |
184 | .IP INT | |
185 | terminates execution gracefully (i.e., by sending | |
186 | good-bye messages to all neighboring routers). | |
187 | .IP USR1 | |
188 | dumps the internal routing tables to /usr/tmp/mrouted.dump. | |
189 | .IP QUIT | |
190 | dumps the internal routing tables to stderr (only if | |
191 | .I mrouted | |
192 | was invoked with a non-zero debug level). | |
193 | .bp | |
194 | .SH EXAMPLE | |
195 | .PP | |
196 | The routing tables look like this: | |
197 | .nf | |
198 | ||
199 | Virtual Interface Table | |
200 | Vif Local-Address Metric Thresh Flags | |
201 | 0 36.2.0.8 subnet: 36.2 1 1 querier | |
202 | groups: 224.0.2.1 | |
203 | 224.0.0.4 | |
204 | 1 36.11.0.1 subnet: 36.11 1 1 querier | |
205 | groups: 224.0.2.1 | |
206 | 224.0.1.0 | |
207 | 224.0.0.4 | |
208 | 2 36.2.0.8 tunnel: 36.8.0.77 3 1 | |
209 | peers : 36.8.0.77 | |
210 | 3 36.2.0.8 tunnel: 36.8.0.110 3 1 | |
211 | ||
212 | Multicast Routing Table | |
213 | Origin-Subnet From-Gateway Metric In-Vif Out-Vifs | |
214 | 36.2 1 0 1* 2 3* | |
215 | 36.8 36.8.0.77 4 2 0* 1* 3* | |
216 | 36.11 1 1 0* 2 3* | |
217 | ||
218 | .fi | |
219 | In this example, there are four vifs connecting to two subnets and two | |
220 | tunnels. The vif 3 tunnel is not in use (no peer address). The vif 0 and | |
221 | vif 1 subnets have some groups present; tunnels never have any groups. This | |
222 | instance of | |
223 | .I mrouted | |
224 | is the one responsible for sending periodic group | |
225 | membership queries on the vif 0 and vif 1 subnets, as indicated by the | |
226 | "querier" flags. | |
227 | .PP | |
228 | Associated with each subnet from which a multicast datagram can originate | |
229 | is the address of the previous hop gateway (unless the subnet is directly- | |
230 | connected), the metric of the path back to the origin, the incoming vif for | |
231 | multicasts from that origin, and a list of outgoing vifs. "*" means that | |
232 | the outgoing vif is connected to a leaf of the broadcast tree rooted at the | |
233 | origin, and a multicast datagram from that origin will be forwarded on that | |
234 | outgoing vif only if there are members of the destination group on that leaf. | |
235 | .SH FILES | |
236 | /etc/mrouted.conf | |
237 | .SH SEE ALSO | |
238 | TRPB is described, along with other multicast routing algorithms, in the | |
239 | paper "Multicast Routing in Internetworks and Extended LANs" by S. Deering, | |
240 | in the Proceedings of the ACM SIGCOMM '88 Conference. | |
241 | .SH AUTHOR | |
242 | Steve Deering |