1 .\" Copyright (c) 1983, 1991, 1993
2 .\" The Regents of the University of California. All rights reserved.
4 .\" Redistribution and use in source and binary forms, with or without
5 .\" modification, are permitted provided that the following conditions
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.
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
32 .\" @(#)routed.8 8.2 (Berkeley) 12/11/93
41 .Nd network RIP and router discovery routing daemon
48 .Ar net Ns Op /mask Ns Op ,metric
53 is a daemon invoked at boot time to manage the network
55 It uses Routing Information Protocol, RIPv1 (RFC\ 1058),
57 and Internet Router Discovery Protocol (RFC 1256)
58 to maintain the kernel routing table.
59 The RIPv1 protocol is based on the reference
69 for Routing Information Protocol packets.
70 It also sends and receives multicast Router Discovery ICMP messages.
71 If the host is a router,
73 periodically supplies copies
74 of its routing tables to any directly connected hosts and networks.
75 It also advertises or solicits default routes using Router Discovery
78 When started (or when a network interface is later turned on),
80 uses an AF_ROUTE address family facility to find those
81 directly connected interfaces configured into the
82 system and marked "up".
83 It adds necessary routes for the interfaces
84 to the kernel routing table.
85 Soon after being first started, and provided there is at least one
86 interface on which RIP has not been disabled,
88 deletes all pre-existing
89 non-static routes in kernel table.
90 Static routes in the kernel table are preserved and
91 included in RIP responses if they have a valid RIP metric
95 If more than one interface is present (not counting the loopback interface),
96 it is assumed that the host should forward packets among the
98 After transmitting a RIP
101 Router Discovery Advertisements or Solicitations on a new interface,
102 the daemon enters a loop, listening for
103 RIP request and response and Router Discovery packets from other hosts.
109 formulates a reply based on the information maintained in its
113 packet generated contains a list of known routes, each marked
114 with a "hop count" metric (a count of 16 or greater is
115 considered "infinite").
116 Advertised metrics reflect the metric associated with interface
119 so setting the metric on an interface
120 is an effective way to steer traffic.
122 Responses do not include routes with a first hop on the requesting
123 network to implement in part
125 Requests from query programs
128 are answered with the complete table.
130 The routing table maintained by the daemon
131 includes space for several gateways for each destination
132 to speed recovery from a failing router.
135 packets received are used to update the routing tables provided they are
136 from one of the several currently recognized gateways or
137 advertise a better metric than at least one of the existing
140 When an update is applied,
142 records the change in its own tables and updates the kernel routing table
143 if the best route to the destination changes.
144 The change in the kernel routing table is reflected in the next batch of
147 If the next response is not scheduled for a while, a
149 response containing only recently changed routes is sent.
151 In addition to processing incoming packets,
153 also periodically checks the routing table entries.
154 If an entry has not been updated for 3 minutes, the entry's metric
155 is set to infinity and marked for deletion.
156 Deletions are delayed until the route has been advertised with
157 an infinite metric to insure the invalidation
158 is propagated throughout the local internet.
162 Routes in the kernel table that are added or changed as a result
163 of ICMP Redirect messages are deleted after a while to minimize
165 When a TCP connection suffers a timeout,
168 which deletes all redirected routes
169 through the gateway involved, advances the age of all RIP routes through
170 the gateway to allow an alternate to be chosen, and advances of the
171 age of any relevant Router Discovery Protocol default routes.
173 Hosts acting as internetwork routers gratuitously supply their
174 routing tables every 30 seconds to all directly connected hosts
176 These RIP responses are sent to the broadcast address on nets that support
178 to the destination address on point-to-point links, and to the router's
179 own address on other networks.
180 If RIPv2 is enabled, multicast packets are sent on interfaces that
181 support multicasting.
183 If no response is received on a remote interface, if there are errors
184 while sending responses,
185 or if there are more errors than input or output (see
187 then the cable or some other part of the interface is assumed to be
188 disconnected or broken, and routes are adjusted appropriately.
191 .Em Internet Router Discovery Protocol
192 is handled similarly.
193 When the daemon is supplying RIP routes, it also listens for
194 Router Discovery Solicitations and sends Advertisements.
195 When it is quiet and listening to other RIP routers, it
196 sends Solicitations and listens for Advertisements.
198 a good Advertisement and it is not multi-homed,
199 it stops listening for broadcast or multicast RIP responses.
200 It tracks several advertising routers to speed recovery when the
201 currently chosen router dies.
202 If all discovered routers disappear,
203 the daemon resumes listening to RIP responses.
204 It continues listening to RIP while using Router Discovery
205 if multi-homed to ensure all interfaces are used.
207 The Router Discovery standard requires that advertisements
208 have a default "lifetime" of 30 minutes. That means should
209 something happen, a client can be without a good route for
210 30 minutes. It is a good idea to reduce the default to 45
212 .Fl P Cm rdisc_interval=45
213 on the command line or
214 .Cm rdisc_interval=45
219 While using Router Discovery (which happens by default when
220 the system has a single network interface and a Router Discover Advertisement
221 is received), there is a single default route and a variable number of
222 redirected host routes in the kernel table.
223 On a host with more than one network interface,
224 this default route will be via only one of the interfaces.
225 Thus, multi-homed hosts running with \f3\-q\f1 might need
231 facility described below to support "legacy" systems
232 that can handle neither RIPv2 nor Router Discovery.
234 By default, neither Router Discovery advertisements nor solicitations
235 are sent over point to point links (e.g. PPP).
236 The netmask associated with point-to-point links (such as SLIP
237 or PPP, with the IFF_POINTOPOINT flag) is used by
239 to infer the netmask used by the remote system when RIPv1 is used.
241 The following options are available:
242 .Bl -tag -width indent
246 to supply routing information.
247 This is the default if multiple network interfaces are present on which
248 RIP or Router Discovery have not been disabled, and if the kernel switch
251 is the opposite of the
254 This is the default when only one interface is present.
255 With this explicit option, the daemon is always in "quiet-mode" for RIP
256 and does not supply routing information to other computers.
258 do not run in the background.
259 This option is meant for interactive use.
261 used on internetwork routers to offer a route
262 to the "default" destination.
266 and is present mostly for historical reasons.
269 on the command line or
274 since a larger metric
275 will be used, reducing the spread of the potentially dangerous
277 This is typically used on a gateway to the Internet,
278 or on a gateway that uses another routing protocol whose routes
279 are not reported to other local routers.
280 Notice that because a metric of 1 is used, this feature is
281 dangerous. It is more commonly accidentally used to create chaos with a
282 routing loop than to solve problems.
284 cause host or point-to-point routes to not be advertised,
285 provided there is a network route going the same direction.
286 That is a limited kind of aggregation.
287 This option is useful on gateways to Ethernets that have other gateway
288 machines connected with point-to-point links such as SLIP.
290 cause the machine to advertise a host or point-to-point route to
291 its primary interface.
292 It is useful on multi-homed machines such as NFS servers.
293 This option should not be used except when the cost of
294 the host routes it generates is justified by the popularity of
296 It is effective only when the machine is supplying
297 routing information, because there is more than one interface.
302 option to the limited extent of advertising the host route.
304 do not ignore RIPv2 authentication if we do not care about RIPv2
306 This option is required for conformance with RFC 1723.
307 However, it makes no sense and breaks using RIP as a discovery protocol
308 to ignore all RIPv2 packets that carry authentication when this machine
309 does not care about authentication.
311 increase the debugging level, which causes more information to be logged
312 on the tracefile specified with
315 The debugging level can be increased or decreased
323 .It Fl T Ar tracefile
324 increases the debugging level to at least 1 and
325 causes debugging information to be appended to the trace file.
326 Note that because of security concerns, it is wisest to not run
328 routinely with tracing directed to a file.
330 display and logs the version of daemon.
331 .It Fl F Ar net[/mask][,metric]
332 minimize routes in transmissions via interfaces with addresses that match
334 and synthesizes a default route to this machine with the
336 The intent is to reduce RIP traffic on slow, point-to-point links
337 such as PPP links by replacing many large UDP packets of RIP information
338 with a single, small packet containing a "fake" default route.
341 is absent, a value of 14 is assumed to limit
342 the spread of the "fake" default route.
343 This is a dangerous feature that when used carelessly can cause routing
345 Notice also that more than one interface can match the specified network
350 is equivalent to adding the parameter
358 Any other argument supplied is interpreted as the name
359 of a file in which the actions of
365 appending the name of the trace file to the command.
368 also supports the notion of
376 is started, it reads the file
378 to find such distant gateways which may not be located using
379 only information from a routing socket, to discover if some
380 of the local gateways are
382 and to obtain other parameters.
383 Gateways specified in this manner should be marked passive
384 if they are not expected to exchange routing information,
385 while gateways marked active
386 should be willing to exchange RIP packets.
389 gateways are installed in the
390 kernel's routing tables once upon startup and are not included in
391 transmitted RIP responses.
393 Distant active gateways are treated like network interfaces.
394 RIP responses are sent
398 If no responses are received, the associated route is deleted from
399 the kernel table and RIP responses advertised via other interfaces.
400 If the distant gateway resumes sending RIP responses, the associated
403 Such gateways can be useful on media that do not support broadcasts
404 or multicasts but otherwise act like classic shared media like
405 Ethernets such as some ATM networks.
406 One can list all RIP routers reachable on the HIPPI or ATM network in
410 Note that it is usually desirable to use RIPv2 in such situations
411 to avoid generating lists of inferred host routes.
415 are also passive, but are not placed in the kernel
416 routing table nor are they included in routing updates.
417 The function of external entries is to indicate
418 that another routing process
419 will install such a route if necessary,
420 and that other routes to that destination should not be installed
423 Such entries are only required when both routers may learn of routes
424 to the same destination.
428 file is comprised of a series of lines, each in
429 one of the following two formats or consist of parameters described later.
430 Blank lines and lines starting with '#' are comments.
439 .Pf < Cm passive No \&|
450 .Pf < Cm passive No \&|
458 is the name of the destination network or host.
459 It may be a symbolic network name or an Internet address
460 specified in "dot" notation (see
462 (If it is a name, then it must either be defined in
468 must have been started before
472 is an optional number between 1 and 32 indicating the netmask associated
477 is the name or address of the gateway to which RIP responses should
481 is the hop count to the destination host or network.
485 .Cm net Ar nname/32 .
492 must be present to indicate whether the gateway should be treated as
496 (as described above),
497 or whether the gateway is
499 to the scope of the RIP protocol.
501 As can be seen when debugging is turned on with
503 such lines create pseudo-interfaces.
504 To set parameters for remote or external interfaces,
506 .Cm if=alias(Hname) ,
507 .Cm if=remote(Hname) ,
510 Lines that start with neither "net" nor "host" must consist of one
511 or more of the following parameter settings, separated by commas or
514 .It Cm if Ns \&= Ns Ar ifname
515 indicates that the other parameters on the line apply to the interface
518 .It Cm subnet Ns \&= Ns Ar nname[/mask][,metric]
519 advertises a route to network
523 and the supplied metric (default 1).
524 This is useful for filling "holes" in CIDR allocations.
525 This parameter must appear by itself on a line.
526 The network number must specify a full, 32-bit value, as in 192.0.2.0
529 Do not use this feature unless necessary. It is dangerous.
530 .It Cm ripv1_mask Ns \&= Ns Ar nname/mask1,mask2
531 specifies that netmask of the network of which
536 For example \f2ripv1_mask=192.0.2.16/28,27\f1 marks 192.0.2.16/28
537 as a subnet of 192.0.2.0/27 instead of 192.0.2.0/24.
538 It is better to turn on RIPv2 instead of using this facility, for example
539 with \f2ripv2_out\f1.
540 .It Cm passwd Ns \&= Ns Ar XXX[|KeyID[start|stop]]
541 specifies a RIPv2 cleartext password that will be included on
542 all RIPv2 responses sent, and checked on all RIPv2 responses received.
543 Any blanks, tab characters, commas, or '#', '|', or NULL characters in the
544 password must be escaped with a backslash (\\).
545 The common escape sequences \\n, \\r, \\t, \\b, and \\xxx have their
549 must be unique but is ignored for cleartext passwords.
554 are timestamps in the form year/month/day@hour:minute.
555 They specify when the password is valid.
556 The valid password with the most future is used on output packets, unless
557 all passwords have expired, in which case the password that expired most
558 recently is used, or unless no passwords are valid yet, in which case
559 no password is output.
560 Incoming packets can carry any password that is valid, will
561 be valid within 24 hours, or that was valid within 24 hours.
562 To protect the secrets, the passwd settings are valid only in the
564 file and only when that file is readable only by UID 0.
565 .It Cm md5_passwd Ns \&= Ns Ar XXX|KeyID[start|stop]
566 specifies a RIPv2 MD5 password.
569 is required, this keyword is similar to
572 turns off aggregation of subnets in RIPv1 and RIPv2 responses.
574 turns off aggregation of networks into supernets in RIPv2 responses.
576 marks the interface to not be advertised in updates sent via other
577 interfaces, and turns off all RIP and router discovery through the interface.
579 disables all RIP processing on the specified interface.
580 If no interfaces are allowed to process RIP packets,
582 acts purely as a router discovery daemon.
584 Note that turning off RIP without explicitly turning on router
585 discovery advertisements with
591 to act as a client router discovery daemon, not advertising.
593 causes RIPv2 packets to be broadcast instead of multicast.
595 causes RIPv1 received responses to be ignored.
597 causes RIPv2 received responses to be ignored.
599 turns on RIPv2 output and causes RIPv2 advertisements to be
600 multicast when possible.
608 disables the Internet Router Discovery Protocol.
610 disables the transmission of Router Discovery Solicitations.
612 specifies that Router Discovery solicitations should be sent,
613 even on point-to-point links,
614 which by default only listen to Router Discovery messages.
616 disables the transmission of Router Discovery Advertisements.
618 specifies that Router Discovery Advertisements should be sent,
619 even on point-to-point links,
620 which by default only listen to Router Discovery messages.
622 specifies that Router Discovery packets should be broadcast instead of
624 .It Cm rdisc_pref Ns \&= Ns Ar N
625 sets the preference in Router Discovery Advertisements to the optionally
628 The default preference is 0.
629 Default routes with smaller or more negative preferences are preferred by
631 .It Cm rdisc_interval Ns \&= Ns Ar N
632 sets the nominal interval with which Router Discovery Advertisements
633 are transmitted to N seconds and their lifetime to 3*N.
634 .It Cm fake_default Ns \&= Ns Ar metric
635 has an identical effect to
636 .Fl F Ar net[/mask][=metric]
637 with the network and mask coming from the specified interface.
641 When RIPv2 routes are multicast, so that RIPv1 listeners cannot
642 receive them, this feature causes a RIPv1 default route to be
643 broadcast to RIPv1 listeners.
646 the default route is broadcast with a metric of 14.
647 That serves as a "poor man's router discovery" protocol.
648 .It Cm trust_gateway Ns \&= Ns Ar rname[|net1/mask1|net2/mask2|...]
649 causes RIP packets from that router and other routers named in
652 keywords to be accepted, and packets from other routers to be ignored.
653 If networks are specified, then routes to other networks will be ignored
656 causes RIP to allow ICMP Redirect messages when the system is acting
657 as a router and forwarding packets.
658 Otherwise, ICMP Redirect messages are overridden.
661 .Bl -tag -width /etc/gateways -compact
670 .%T Internet Transport Protocols
672 .%Q Xerox System Integration Standard
675 It does not always detect unidirectional failures in network interfaces,
676 for example, when the output side fails.