xref: /netbsd-src/sbin/routed/routed.8 (revision 6929ad87a5c37179228b21785018bbb66fe06b56)
1.\" Copyright (c) 1983, 1991, 1993
2.\"	The Regents of the University of California.  All rights reserved.
3.\"
4.\" Redistribution and use in source and binary forms, with or without
5.\" modification, are permitted provided that the following conditions
6.\" are met:
7.\" 1. Redistributions of source code must retain the above copyright
8.\"    notice, this list of conditions and the following disclaimer.
9.\" 2. Redistributions in binary form must reproduce the above copyright
10.\"    notice, this list of conditions and the following disclaimer in the
11.\"    documentation and/or other materials provided with the distribution.
12.\" 3. All advertising materials mentioning features or use of this software
13.\"    must display the following acknowledgement:
14.\"	This product includes software developed by the University of
15.\"	California, Berkeley and its contributors.
16.\" 4. Neither the name of the University nor the names of its contributors
17.\"    may be used to endorse or promote products derived from this software
18.\"    without specific prior written permission.
19.\"
20.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
21.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
22.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
23.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
24.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
25.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
26.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
27.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
28.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
29.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
30.\" SUCH DAMAGE.
31.\"
32.\"	from: @(#)routed.8	8.2 (Berkeley) 12/11/93
33.\"	$Id: routed.8,v 1.5 1994/05/13 08:04:48 mycroft Exp $
34.\"
35.Dd December 11, 1993
36.Dt ROUTED 8
37.Os BSD 4.2
38.Sh NAME
39.Nm routed
40.Nd network routing daemon
41.Sh SYNOPSIS
42.Nm routed
43.Op Fl d
44.Op Fl g
45.Op Fl q
46.Op Fl s
47.Op Fl t
48.Op Ar logfile
49.Sh DESCRIPTION
50.Nm Routed
51is invoked at boot time to manage the network routing tables.
52The routing daemon uses a variant of the Xerox NS Routing
53Information Protocol in maintaining up to date kernel routing
54table entries.
55It used a generalized protocol capable of use with multiple
56address types, but is currently used only for Internet routing
57within a cluster of networks.
58.Pp
59In normal operation
60.Nm routed
61listens on the
62.Xr udp 4
63socket for the
64.Xr route 8
65service (see
66.Xr services 5 )
67for routing information packets.  If the host is an
68internetwork router, it periodically supplies copies
69of its routing tables to any directly connected hosts
70and networks.
71.Pp
72When
73.Nm routed
74is started, it uses the
75.Dv SIOCGIFCONF
76.Xr ioctl 2
77to find those
78directly connected interfaces configured into the
79system and marked ``up'' (the software loopback interface
80is ignored).  If multiple interfaces
81are present, it is assumed that the host will forward packets
82between networks.
83.Nm Routed
84then transmits a
85.Em request
86packet on each interface (using a broadcast packet if
87the interface supports it) and enters a loop, listening
88for
89.Em request
90and
91.Em response
92packets from other hosts.
93.Pp
94When a
95.Em request
96packet is received,
97.Nm routed
98formulates a reply based on the information maintained in its
99internal tables.  The
100.Em response
101packet generated contains a list of known routes, each marked
102with a ``hop count'' metric (a count of 16, or greater, is
103considered ``infinite'').  The metric associated with each
104route returned provides a metric
105.Em relative to the sender .
106.Pp
107.Em Response
108packets received by
109.Nm routed
110are used to update the routing tables if one of the following
111conditions is satisfied:
112.Bl -enum
113.It
114No routing table entry exists for the destination network
115or host, and the metric indicates the destination is ``reachable''
116(i.e. the hop count is not infinite).
117.It
118The source host of the packet is the same as the router in the
119existing routing table entry.  That is, updated information is
120being received from the very internetwork router through which
121packets for the destination are being routed.
122.It
123The existing entry in the routing table has not been updated for
124some time (defined to be 90 seconds) and the route is at least
125as cost effective as the current route.
126.It
127The new route describes a shorter route to the destination than
128the one currently stored in the routing tables; the metric of
129the new route is compared against the one stored in the table
130to decide this.
131.El
132.Pp
133When an update is applied,
134.Nm routed
135records the change in its internal tables and updates the kernel
136routing table.
137The change is reflected in the next
138.Em response
139packet sent.
140.Pp
141In addition to processing incoming packets,
142.Nm routed
143also periodically checks the routing table entries.
144If an entry has not been updated for 3 minutes, the entry's metric
145is set to infinity and marked for deletion.  Deletions are delayed
146an additional 60 seconds to insure the invalidation is propagated
147throughout the local internet.
148.Pp
149Hosts acting as internetwork routers gratuitously supply their
150routing tables every 30 seconds to all directly connected hosts
151and networks.
152The response is sent to the broadcast address on nets capable of that function,
153to the destination address on point-to-point links, and to the router's
154own address on other networks.
155The normal routing tables are bypassed when sending gratuitous responses.
156The reception of responses on each network is used to determine that the
157network and interface are functioning correctly.
158If no response is received on an interface, another route may be chosen
159to route around the interface, or the route may be dropped if no alternative
160is available.
161.Pp
162Options supported by
163.Nm routed :
164.Bl -tag -width Ds
165.It Fl d
166Enable additional debugging information to be logged,
167such as bad packets received.
168.It Fl g
169This flag is used on internetwork routers to offer a route
170to the ``default'' destination.
171This is typically used on a gateway to the Internet,
172or on a gateway that uses another routing protocol whose routes
173are not reported to other local routers.
174.It Fl s
175Supplying this
176option forces
177.Nm routed
178to supply routing information whether it is acting as an internetwork
179router or not.
180This is the default if multiple network interfaces are present,
181or if a point-to-point link is in use.
182.It Fl q
183This
184is the opposite of the
185.Fl s
186option.
187.It Fl t
188If the
189.Fl t
190option is specified, all packets sent or received are
191printed on the standard output.  In addition,
192.Nm routed
193will not divorce itself from the controlling terminal
194so that interrupts from the keyboard will kill the process.
195.El
196.Pp
197Any other argument supplied is interpreted as the name
198of file in which
199.Nm routed Ns \'s
200actions should be logged.  This log contains information
201about any changes to the routing tables and, if not tracing all packets,
202a history of recent messages sent and received which are related to
203the changed route.
204.Pp
205In addition to the facilities described above,
206.Nm routed
207supports the notion of ``distant''
208.Em passive
209and
210.Em active
211gateways.  When
212.Nm routed
213is started up, it reads the file
214.Pa /etc/gateways
215to find gateways which may not be located using
216only information from the
217.Dv SIOGIFCONF
218.Xr ioctl 2 .
219Gateways specified in this manner should be marked passive
220if they are not expected to exchange routing information,
221while gateways marked active
222should be willing to exchange routing information (i.e.
223they should have a
224.Nm routed
225process running on the machine).
226Routes through passive gateways are installed in the
227kernel's routing tables once upon startup.
228Such routes are not included in
229any routing information transmitted.
230Active gateways are treated equally to network
231interfaces.  Routing information is distributed
232to the gateway and if no routing information is
233received for a period of time, the associated
234route is deleted.
235Gateways marked
236.Em external
237are also passive, but are not placed in the kernel
238routing table nor are they included in routing updates.
239The function of external entries is to inform
240.Nm routed
241that another routing process
242will install such a route, and that alternate routes to that destination
243should not be installed.
244Such entries are only required when both routers may learn of routes
245to the same destination.
246.Pp
247The
248.Pa /etc/gateways
249is comprised of a series of lines, each in
250the following format:
251.Bd -ragged
252.Pf < Cm net No \&|
253.Cm host Ns >
254.Ar name1
255.Cm gateway
256.Ar name2
257.Cm metric
258.Ar value
259.Pf < Cm passive No \&|
260.Cm active No \&|
261.Cm external Ns >
262.Ed
263.Pp
264The
265.Cm net
266or
267.Cm host
268keyword indicates if the route is to a network or specific host.
269.Pp
270.Ar Name1
271is the name of the destination network or host.  This may be a
272symbolic name located in
273.Pa /etc/networks
274or
275.Pa /etc/hosts
276(or, if started after
277.Xr named 8 ,
278known to the name server),
279or an Internet address specified in ``dot'' notation; see
280.Xr inet 3 .
281.Pp
282.Ar Name2
283is the name or address of the gateway to which messages should
284be forwarded.
285.Pp
286.Ar Value
287is a metric indicating the hop count to the destination host
288or network.
289.Pp
290One of the keywords
291.Cm passive ,
292.Cm active
293or
294.Cm external
295indicates if the gateway should be treated as
296.Em passive
297or
298.Em active
299(as described above),
300or whether the gateway is
301.Em external
302to the scope of the
303.Nm routed
304protocol.
305.Pp
306Internetwork routers that are directly attached to the Arpanet or Milnet
307should use the Exterior Gateway Protocol
308.Pq Tn EGP
309to gather routing information
310rather then using a static routing table of passive gateways.
311.Tn EGP
312is required in order to provide routes for local networks to the rest
313of the Internet system.
314.Sh FILES
315.Bl -tag -width /etc/gateways -compact
316.It Pa /etc/gateways
317for distant gateways
318.El
319.Sh SEE ALSO
320.Xr udp 4 ,
321.Xr icmp 4 ,
322.Xr XNSrouted 8 ,
323.Xr htable 8
324.Rs
325.%T Internet Transport Protocols
326.%R XSIS 028112
327.%Q Xerox System Integration Standard
328.Re
329.Sh BUGS
330The kernel's routing tables may not correspond to those of
331.Nm routed
332when redirects change or add routes.
333.Nm Routed
334should note any redirects received by reading
335the
336.Tn ICMP
337packets received via a raw socket.
338.Pp
339.Nm Routed
340should incorporate other routing protocols,
341such as Xerox
342.Tn \&NS
343.Pq Xr XNSrouted 8
344and
345.Tn EGP .
346Using separate processes for each requires configuration options
347to avoid redundant or competing routes.
348.Pp
349.Nm Routed
350should listen to intelligent interfaces, such as an
351.Tn IMP ,
352to gather more information.
353It does not always detect unidirectional failures in network interfaces
354(e.g., when the output side fails).
355.Sh HISTORY
356The
357.Nm
358command appeared in
359.Bx 4.2 .
360