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