![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to routed.8c CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Power 6/32 Unix Tahoe 4.2BSD] / cci / usr / src / man / man8|
Return to routed.8c CVS log | Up to [Power 6/32 Unix Tahoe 4.2BSD] / cci / usr / src / man / man8 |
1.1 root 1: .TH ROUTED 8C "3 February 1983"
2: .UC 4
3: .SH NAME
4: routed \- network routing daemon
5: .SH SYNOPSIS
6: .B /etc/routed
7: [
8: .B \-s
9: ] [
10: .B \-q
11: ] [
12: .B \-t
13: ] [
14: .I logfile
15: ]
16: .SH DESCRIPTION
17: .I Routed
18: is invoked at boot time to manage the network routing tables.
19: The routing daemon uses a variant of the Xerox NS Routing
20: Information Protocol in maintaining up to date kernel routing
21: table entries.
22: .PP
23: In normal operation
24: .I routed
25: listens on
26: .IR udp (4P)
27: socket 520 (decimal)
28: for routing information packets. If the host is an
29: internetwork router, it periodically supplies copies
30: of its routing tables to any directly connected hosts
31: and networks.
32: .PP
33: When
34: .I routed
35: is started, it uses the SIOCGIFCONF
36: .I ioctl
37: to find those
38: directly connected interfaces configured into the
39: system and marked ``up'' (the software loopback interface
40: is ignored). If multiple interfaces
41: are present, it is assumed the host will forward packets
42: between networks.
43: .I Routed
44: then transmits a
45: .I request
46: packet on each interface (using a broadcast packet if
47: the interface supports it) and enters a loop, listening
48: for
49: .I request
50: and
51: .I response
52: packets from other hosts.
53: .PP
54: When a
55: .I request
56: packet is received,
57: .I routed
58: formulates a reply based on the information maintained in its
59: internal tables. The
60: .I response
61: packet generated contains a list of known routes, each marked
62: with a ``hop count'' metric (a count of 16, or greater, is
63: considered ``infinite''). The metric associated with each
64: route returned provides a metric
65: .IR "relative to the sender" .
66: .PP
67: .I Response
68: packets received by
69: .I routed
70: are used to update the routing tables if one of the following
71: conditions is satisfied:
72: .TP
73: (1)
74: No routing table entry exists for the destination network
75: or host, and the metric indicates the destination is ``reachable''
76: (i.e. the hop count is not infinite).
77: .TP
78: (2)
79: The source host of the packet is the same as the router in the
80: existing routing table entry. That is, updated information is
81: being received from the very internetwork router through which
82: packets for the destination are being routed.
83: .TP
84: (3)
85: The existing entry in the routing table has not been updated for
86: some time (defined to be 90 seconds) and the route is at least
87: as cost effective as the current route.
88: .TP
89: (4)
90: The new route describes a shorter route to the destination than
91: the one currently stored in the routing tables; the metric of
92: the new route is compared against the one stored in the table
93: to decide this.
94: .PP
95: When an update is applied,
96: .I routed
97: records the change in its internal tables and generates a
98: .I response
99: packet to all directly connected hosts and networks.
100: .I Routed
101: waits a short period
102: of time (no more than 30 seconds) before modifying the kernel's
103: routing tables to allow possible unstable situations to settle.
104: .PP
105: In addition to processing incoming packets,
106: .I routed
107: also periodically checks the routing table entries.
108: If an entry has not been updated for 3 minutes, the entry's metric
109: is set to infinity and marked for deletion. Deletions are delayed
110: an additional 60 seconds to insure the invalidation is propagated
111: throughout the internet.
112: .PP
113: Hosts acting as internetwork routers gratuitously supply their
114: routing tables every 30 seconds to all directly connected hosts
115: and networks.
116: .PP
117: Supplying the
118: .B \-s
119: option forces
120: .I routed
121: to supply routing information whether it is acting as an internetwork
122: router or not.
123: The
124: .B \-q
125: option is the opposite of the
126: .B \-s
127: option. If the
128: .B \-t
129: option is specified, all packets sent or received are
130: printed on the standard output. In addition,
131: .I routed
132: will not divorce itself from the controlling terminal
133: so that interrupts from the keyboard will kill the process.
134: Any other argument supplied is interpreted as the name
135: of file in which
136: .IR routed 's
137: actions should be logged. This log contains information
138: about any changes to the routing tables and a history of
139: recent messages sent and received which are related to
140: the changed route.
141: .PP
142: In addition to the facilities described above,
143: .I routed
144: supports the notion of ``distant''
145: .I passive
146: and
147: .I active
148: gateways. When
149: .I routed
150: is started up, it reads the file
151: .I /etc/gateways
152: to find gateways which may not be identified using
153: the SIOGIFCONF
154: .IR ioctl .
155: Gateways specified in this manner should be marked passive
156: if they are not expected to exchange routing information,
157: while gateways marked active
158: should be willing to exchange routing information (i.e.
159: they should have a
160: .I routed
161: process running on the machine).
162: Passive gateways are maintained in the
163: routing tables forever and information
164: regarding their existence is included in
165: any routing information transmitted.
166: Active gateways are treated equally to network
167: interfaces. Routing information is distributed
168: to the gateway and if no routing information is
169: received for a period of the time, the associated
170: route is deleted.
171: .PP
172: The
173: .I /etc/gateways
174: is comprised of a series of lines, each in
175: the following format:
176: .PP
177: .nf
178: < \fBnet\fP | \fBhost\fP > \fIname1\fP \fBgateway\fP \fIname2\fP \fBmetric\fP \fIvalue\fP < \fBpassive\fP | \fBactive\fP >
179: .fi
180: .PP
181: The
182: .B net
183: or
184: .B host
185: keyword indicates if the route is to a network or specific host.
186: .PP
187: .I Name1
188: is the name of the destination network or host. This may be a
189: symbolic name located in
190: .I /etc/networks
191: or
192: .IR /etc/hosts ,
193: or an Internet address specified in ``dot'' notation; see
194: .IR inet (3N).
195: .PP
196: .I Name2
197: is the name or address of the gateway to which messages should
198: be forwarded.
199: .PP
200: .I Value
201: is a metric indicating the hop count to the destination host
202: or network.
203: .PP
204: The keyword
205: .B passive
206: or
207: .B active
208: indicates if the gateway should be treated as
209: .I passive
210: or
211: .I active
212: (as described above).
213: .SH FILES
214: .DT
215: /etc/gateways for distant gateways
216: .SH "SEE ALSO"
217: ``Internet Transport Protocols'', XSIS 028112, Xerox System Integration
218: Standard.
219: .br
220: udp(4P)
221: .SH BUGS
222: The kernel's routing tables may not correspond to those of
223: .I routed
224: for short periods of time while processes utilizing existing
225: routes exit; the only remedy for this is to place the routing
226: process in the kernel.
227: .PP
228: .I Routed
229: should listen to intelligent interfaces, such as an IMP, and
230: to error protocols, such as ICMP, to gather more information.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.