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