xref: /netbsd/sbin/routed/routed.8 (revision bf9ec67e)
1.\"	$NetBSD: routed.8,v 1.37 2002/05/12 15:48:37 wiz Exp $
2.\"
3.\" Copyright (c) 1983, 1991, 1993
4.\"	The Regents of the University of California.  All rights reserved.
5.\"
6.\" Redistribution and use in source and binary forms, with or without
7.\" modification, are permitted provided that the following conditions
8.\" are met:
9.\" 1. Redistributions of source code must retain the above copyright
10.\"    notice, this list of conditions and the following disclaimer.
11.\" 2. Redistributions in binary form must reproduce the above copyright
12.\"    notice, this list of conditions and the following disclaimer in the
13.\"    documentation and/or other materials provided with the distribution.
14.\" 3. All advertising materials mentioning features or use of this software
15.\"    must display the following acknowledgment:
16.\"	This product includes software developed by the University of
17.\"	California, Berkeley and its contributors.
18.\" 4. Neither the name of the University nor the names of its contributors
19.\"    may be used to endorse or promote products derived from this software
20.\"    without specific prior written permission.
21.\"
22.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
23.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
24.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
25.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
26.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
27.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
28.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
29.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
30.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
31.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
32.\" SUCH DAMAGE.
33.\"
34.\"     @(#)routed.8	8.2 (Berkeley) 12/11/93
35.\"
36.Dd June 1, 1996
37.Dt ROUTED 8
38.Os
39.Sh NAME
40.Nm routed ,
41.Nm rdisc
42.Nd network RIP and router discovery routing daemon
43.Sh SYNOPSIS
44.Nm routed
45.Op Fl sqdghmpAtv
46.Op Fl T Ar tracefile
47.Oo
48.Fl F
49.Ar net Ns Op /mask Ns Op ,metric
50.Oc
51.Op Fl P Ar parms
52.Sh DESCRIPTION
53.Nm
54is a daemon invoked at boot time to manage the network
55routing tables.
56It uses Routing Information Protocol, RIPv1 (RFC\ 1058),
57RIPv2 (RFC\ 1723),
58and Internet Router Discovery Protocol (RFC 1256)
59to maintain the kernel routing table.
60The RIPv1 protocol is based on the reference
61.Bx 4.3
62daemon.
63.Pp
64It listens on the
65.Xr udp 4
66socket for the
67.Xr route 8
68service (see
69.Xr services 5 )
70for Routing Information Protocol packets.
71It also sends and receives multicast Router Discovery ICMP messages.
72If the host is a router,
73.Nm
74periodically supplies copies
75of its routing tables to any directly connected hosts and networks.
76It also advertises or solicits default routes using Router Discovery
77ICMP messages.
78.Pp
79When started (or when a network interface is later turned on),
80.Nm
81uses an AF_ROUTE address family facility to find those
82directly connected interfaces configured into the
83system and marked "up".
84It adds necessary routes for the interfaces
85to the kernel routing table.
86Soon after being first started, and provided there is at least one
87interface on which RIP has not been disabled,
88.Nm
89deletes all pre-existing
90non-static routes in kernel table.
91Static routes in the kernel table are preserved and
92included in RIP responses if they have a valid RIP metric
93(see
94.Xr route 8 ) .
95.Pp
96If more than one interface is present (not counting the loopback interface),
97it is assumed that the host should forward packets among the
98connected networks.
99After transmitting a RIP
100.Em request
101and
102Router Discovery Advertisements or Solicitations on a new interface,
103the daemon enters a loop, listening for
104RIP request and response and Router Discovery packets from other hosts.
105.Pp
106When a
107.Em request
108packet is received,
109.Nm
110formulates a reply based on the information maintained in its
111internal tables.
112The
113.Em response
114packet generated contains a list of known routes, each marked
115with a "hop count" metric (a count of 16 or greater is
116considered "infinite").
117Advertised metrics reflect the metric associated with interface
118(see
119.Xr ifconfig 8 ) ,
120so setting the metric on an interface
121is an effective way to steer traffic.
122.Pp
123Responses do not include routes with a first hop on the requesting
124network to implement in part
125.Em split-horizon .
126Requests from query programs
127such as
128.Xr rtquery 8
129are answered with the complete table.
130.Pp
131The routing table maintained by the daemon
132includes space for several gateways for each destination
133to speed recovery from a failing router.
134RIP
135.Em response
136packets received are used to update the routing tables provided they are
137from one of the several currently recognized gateways or
138advertise a better metric than at least one of the existing
139gateways.
140.Pp
141When an update is applied,
142.Nm
143records the change in its own tables and updates the kernel routing table
144if the best route to the destination changes.
145The change in the kernel routing table is reflected in the next batch of
146.Em response
147packets sent.
148If the next response is not scheduled for a while, a
149.Em flash update
150response containing only recently changed routes is sent.
151.Pp
152In addition to processing incoming packets,
153.Nm
154also periodically checks the routing table entries.
155If an entry has not been updated for 3 minutes, the entry's metric
156is set to infinity and marked for deletion.
157Deletions are delayed until the route has been advertised with
158an infinite metric to ensure the invalidation
159is propagated throughout the local internet.
160This is a form of
161.Em poison reverse .
162.Pp
163Routes in the kernel table that are added or changed as a result
164of ICMP Redirect messages are deleted after a while to minimize
165.Em black-holes .
166When a TCP connection suffers a timeout,
167the kernel tells
168.Nm "" ,
169which deletes all redirected routes
170through the gateway involved, advances the age of all RIP routes through
171the gateway to allow an alternate to be chosen, and advances of the
172age of any relevant Router Discovery Protocol default routes.
173.Pp
174Hosts acting as internetwork routers gratuitously supply their
175routing tables every 30 seconds to all directly connected hosts
176and networks.
177These RIP responses are sent to the broadcast address on nets that support
178broadcasting,
179to the destination address on point-to-point links, and to the router's
180own address on other networks.
181If RIPv2 is enabled, multicast packets are sent on interfaces that
182support multicasting.
183.Pp
184If no response is received on a remote interface, if there are errors
185while sending responses,
186or if there are more errors than input or output (see
187.Xr netstat 1 ) ,
188then the cable or some other part of the interface is assumed to be
189disconnected or broken, and routes are adjusted appropriately.
190.Pp
191The
192.Em Internet Router Discovery Protocol
193is handled similarly.
194When the daemon is supplying RIP routes, it also listens for
195Router Discovery Solicitations and sends Advertisements.
196When it is quiet and listening to other RIP routers, it
197sends Solicitations and listens for Advertisements.
198If it receives
199a good Advertisement and it is not multi-homed,
200it stops listening for broadcast or multicast RIP responses.
201It tracks several advertising routers to speed recovery when the
202currently chosen router dies.
203If all discovered routers disappear,
204the daemon resumes listening to RIP responses.
205It continues listening to RIP while using Router Discovery
206if multi-homed to ensure all interfaces are used.
207.Pp
208The Router Discovery standard requires that advertisements
209have a default "lifetime" of 30 minutes.  That means should
210something happen, a client can be without a good route for
21130 minutes.  It is a good idea to reduce the default to 45
212seconds using
213.Fl P Cm rdisc_interval=45
214on the command line or
215.Cm rdisc_interval=45
216in the
217.Pa /etc/gateways
218file.
219.Pp
220While using Router Discovery (which happens by default when
221the system has a single network interface and a Router Discover Advertisement
222is received), there is a single default route and a variable number of
223redirected host routes in the kernel table.
224On a host with more than one network interface,
225this default route will be via only one of the interfaces.
226Thus, multi-homed hosts running with
227.Fl q
228might need
229.Cm no_rdisc
230described below.
231.Pp
232See the
233.Cm pm_rdisc
234facility described below to support "legacy" systems
235that can handle neither RIPv2 nor Router Discovery.
236.Pp
237By default, neither Router Discovery advertisements nor solicitations
238are sent over point to point links (e.g. PPP).
239The netmask associated with point-to-point links (such as SLIP
240or PPP, with the IFF_POINTOPOINT flag) is used by
241.Nm
242to infer the netmask used by the remote system when RIPv1 is used.
243.Pp
244The following options are available:
245.Bl -tag -width indent
246.It Fl s
247force
248.Nm
249to supply routing information.
250This is the default if multiple network interfaces are present on which
251RIP or Router Discovery have not been disabled, and if the sysctl
252net.inet.ip.forwarding=1.
253.It Fl q
254is the opposite of the
255.Fl s
256option.
257This is the default when only one interface is present.
258With this explicit option, the daemon is always in "quiet-mode" for RIP
259and does not supply routing information to other computers.
260.It Fl d
261do not run in the background.
262This option is meant for interactive use.
263.It Fl g
264used on internetwork routers to offer a route
265to the "default" destination.
266It is equivalent to
267.Fl F
268.Cm 0/0,1
269and is present mostly for historical reasons.
270A better choice is
271.Fl P Cm pm_rdisc
272on the command line or
273.Cm pm_rdisc
274in the
275.Pa /etc/gateways
276file.
277since a larger metric
278will be used, reducing the spread of the potentially dangerous
279default route.
280This is typically used on a gateway to the Internet,
281or on a gateway that uses another routing protocol whose routes
282are not reported to other local routers.
283Notice that because a metric of 1 is used, this feature is
284dangerous.  It is more commonly accidentally used to create chaos with a
285routing loop than to solve problems.
286.It Fl h
287cause host or point-to-point routes to not be advertised,
288provided there is a network route going the same direction.
289That is a limited kind of aggregation.
290This option is useful on gateways to Ethernets that have other gateway
291machines connected with point-to-point links such as SLIP.
292.It Fl m
293cause the machine to advertise a host or point-to-point route to
294its primary interface.
295It is useful on multi-homed machines such as NFS servers.
296This option should not be used except when the cost of
297the host routes it generates is justified by the popularity of
298the server.
299It is effective only when the machine is supplying
300routing information, because there is more than one interface.
301The
302.Fl m
303option overrides the
304.Fl q
305option to the limited extent of advertising the host route.
306.It Fl A
307do not ignore RIPv2 authentication if we do not care about RIPv2
308authentication.
309This option is required for conformance with RFC 1723.
310However, it makes no sense and breaks using RIP as a discovery protocol
311to ignore all RIPv2 packets that carry authentication when this machine
312does not care about authentication.
313.It Fl t
314increase the debugging level, which causes more information to be logged
315on the tracefile specified with
316.Fl T
317or standard out.
318The debugging level can be increased or decreased
319with the
320.Em SIGUSR1
321or
322.Em SIGUSR2
323signals or with the
324.Xr rtquery 8
325command.
326.It Fl T Ar tracefile
327increases the debugging level to at least 1 and
328causes debugging information to be appended to the trace file.
329Note that because of security concerns, it is wisest to not run
330.Nm
331routinely with tracing directed to a file.
332.It Fl v
333displays and logs the version of daemon.
334.It Fl F Ar net[/mask][,metric]
335minimize routes in transmissions via interfaces with addresses that match
336.Em net/mask ,
337and synthesizes a default route to this machine with the
338.Em metric .
339The intent is to reduce RIP traffic on slow, point-to-point links
340such as PPP links by replacing many large UDP packets of RIP information
341with a single, small packet containing a "fake" default route.
342If
343.Em metric
344is absent, a value of 14 is assumed to limit
345the spread of the "fake" default route.
346This is a dangerous feature that when used carelessly can cause routing
347loops.
348Notice also that more than one interface can match the specified network
349number and mask.
350See also
351.Fl g .
352.It Fl P Ar parms
353is equivalent to adding the parameter
354line
355.Em parms
356to the
357.Pa /etc/gateways
358file.
359.El
360.Pp
361Any other argument supplied is interpreted as the name
362of a file in which the actions of
363.Nm
364should be logged.
365It is better to use
366.Fl T
367instead of
368appending the name of the trace file to the command.
369.Pp
370.Nm
371also supports the notion of
372"distant"
373.Em passive
374or
375.Em active
376gateways.
377When
378.Nm
379is started, it reads the file
380.Pa /etc/gateways
381to find such distant gateways which may not be located using
382only information from a routing socket, to discover if some
383of the local gateways are
384.Em passive ,
385and to obtain other parameters.
386Gateways specified in this manner should be marked passive
387if they are not expected to exchange routing information,
388while gateways marked active
389should be willing to exchange RIP packets.
390Routes through
391.Em passive
392gateways are installed in the
393kernel's routing tables once upon startup and are not included in
394transmitted RIP responses.
395.Pp
396Distant active gateways are treated like network interfaces.
397RIP responses are sent
398to the distant
399.Em active
400gateway.
401If no responses are received, the associated route is deleted from
402the kernel table and RIP responses advertised via other interfaces.
403If the distant gateway resumes sending RIP responses, the associated
404route is restored.
405.Pp
406Such gateways can be useful on media that do not support broadcasts
407or multicasts but otherwise act like classic shared media like
408Ethernets such as some ATM networks.
409One can list all RIP routers reachable on the HIPPI or ATM network in
410.Pa /etc/gateways
411with a series of
412"host" lines.
413Note that it is usually desirable to use RIPv2 in such situations
414to avoid generating lists of inferred host routes.
415.Pp
416Gateways marked
417.Em external
418are also passive, but are not placed in the kernel
419routing table nor are they included in routing updates.
420The function of external entries is to indicate
421that another routing process
422will install such a route if necessary,
423and that other routes to that destination should not be installed
424by
425.Nm "" .
426Such entries are only required when both routers may learn of routes
427to the same destination.
428.Pp
429The
430.Pa /etc/gateways
431file consists of a series of lines, each in
432one of the following two formats or consist of parameters described later.
433Blank lines and lines starting with '#' are comments.
434.Pp
435.Bd -ragged
436.Cm net
437.Ar Nname[/mask]
438.Cm gateway
439.Ar Gname
440.Cm metric
441.Ar value
442.Pf \*[Lt] Cm passive No \&|
443.Cm active No \&|
444.Cm extern Ns \*[Gt]
445.Ed
446.Bd -ragged
447.Cm host
448.Ar Hname
449.Cm gateway
450.Ar Gname
451.Cm metric
452.Ar value
453.Pf \*[Lt] Cm passive No \&|
454.Cm active No \&|
455.Cm extern Ns \*[Gt]
456.Ed
457.Pp
458.Ar Nname
459or
460.Ar Hname
461is the name of the destination network or host.
462It may be a symbolic network name or an Internet address
463specified in "dot" notation (see
464.Xr inet 3 ) .
465(If it is a name, then it must either be defined in
466.Pa /etc/networks
467or
468.Pa /etc/hosts ,
469or
470.Xr named 8 ,
471must have been started before
472.Nm "" . )
473.Pp
474.Ar Mask
475is an optional number between 1 and 32 indicating the netmask associated
476with
477.Ar Nname .
478.Pp
479.Ar Gname
480is the name or address of the gateway to which RIP responses should
481be forwarded.
482.Pp
483.Ar Value
484is the hop count to the destination host or network.
485.Ar " Host hname "
486is equivalent to
487.Ar " net  nname/32 " .
488.Pp
489One of the keywords
490.Cm passive ,
491.Cm active
492or
493.Cm external
494must be present to indicate whether the gateway should be treated as
495.Cm passive
496or
497.Cm active
498(as described above),
499or whether the gateway is
500.Cm external
501to the scope of the RIP protocol.
502.Pp
503As can be seen when debugging is turned on with
504.Fl t ,
505such lines create pseudo-interfaces.
506To set parameters for remote or external interfaces,
507a line starting with
508.Cm if=alias(Hname) ,
509.Cm if=remote(Hname) ,
510etc. should be used.
511.Pp
512Lines that start with neither "net" nor "host" must consist of one
513or more of the following parameter settings, separated by commas or
514blanks:
515.Bl -tag -width Ds
516.It Cm if Ns \&= Ns Ar ifname
517indicates that the other parameters on the line apply to the interface
518name
519.Ar ifname .
520.It Cm subnet Ns \&= Ns Ar nname[/mask][,metric]
521advertises a route to network
522.Ar nname
523with mask
524.Ar mask
525and the supplied metric (default 1).
526This is useful for filling "holes" in CIDR allocations.
527This parameter must appear by itself on a line.
528The network number must specify a full, 32-bit value, as in 192.0.2.0
529instead of 192.0.2.
530.Pp
531Do not use this feature unless necessary.  It is dangerous.
532.It Cm ripv1_mask Ns \&= Ns Ar nname/mask1,mask2
533specifies that netmask of the network of which
534.Cm nname/mask1
535is
536a subnet should be
537.Cm mask2 .
538For example
539.Cm ripv1_mask Ns \&= Ns Ar 192.0.2.16/28,27
540marks 192.0.2.16/28
541as a subnet of 192.0.2.0/27 instead of 192.0.2.0/24.
542It is better to turn on RIPv2 instead of using this facility, for example
543with
544.Cm ripv2_out .
545.It Cm passwd Ns \&= Ns Ar XXX[|KeyID[start|stop]]
546specifies a RIPv2 cleartext password that will be included on
547all RIPv2 responses sent, and checked on all RIPv2 responses received.
548Any blanks, tab characters, commas, or '#', '|', or NULL characters in the
549password must be escaped with a backslash (\\).
550The common escape sequences \\n, \\r, \\t, \\b, and \\xxx have their
551usual meanings.
552The
553.Cm KeyID
554must be unique but is ignored for cleartext passwords.
555If present,
556.Cm start
557and
558.Cm stop
559are timestamps in the form year/month/day@hour:minute.
560They specify when the password is valid.
561The valid password with the most future is used on output packets, unless
562all passwords have expired, in which case the password that expired most
563recently is used, or unless no passwords are valid yet, in which case
564no password is output.
565Incoming packets can carry any password that is valid, will
566be valid within 24 hours, or that was valid within 24 hours.
567To protect the secrets, the passwd settings are valid only in the
568.Em /etc/gateways
569file and only when that file is readable only by UID 0.
570.It Cm md5_passwd Ns \&= Ns Ar XXX|KeyID[start|stop]
571specifies a RIPv2 MD5 password.
572Except that a
573.Cm KeyID
574is required, this keyword is similar to
575.Cm passwd .
576.It Cm no_ag
577turns off aggregation of subnets in RIPv1 and RIPv2 responses.
578.It Cm no_super_ag
579turns off aggregation of networks into supernets in RIPv2 responses.
580.It Cm passive
581marks the interface to not be advertised in updates sent via other
582interfaces, and turns off all RIP and router discovery through the interface.
583.It Cm no_rip
584disables all RIP processing on the specified interface.
585If no interfaces are allowed to process RIP packets,
586.Nm
587acts purely as a router discovery daemon.
588.Pp
589Note that turning off RIP without explicitly turning on router
590discovery advertisements with
591.Cm rdisc_adv
592or
593.Fl s
594causes
595.Nm
596to act as a client router discovery daemon, not advertising.
597.It Cm no_rip_mcast
598causes RIPv2 packets to be broadcast instead of multicast.
599.It Cm no_ripv1_in
600causes RIPv1 received responses to be ignored.
601.It Cm no_ripv2_in
602causes RIPv2 received responses to be ignored.
603.It Cm ripv2_out
604turns on RIPv2 output and causes RIPv2 advertisements to be
605multicast when possible.
606.It Cm ripv2
607is equivalent to
608.Cm no_ripv1_in
609and
610.Cm no_ripv1_out .
611This enables RIPv2.
612.It Cm no_rdisc
613disables the Internet Router Discovery Protocol.
614.It Cm no_solicit
615disables the transmission of Router Discovery Solicitations.
616.It Cm send_solicit
617specifies that Router Discovery solicitations should be sent,
618even on point-to-point links,
619which by default only listen to Router Discovery messages.
620.It Cm no_rdisc_adv
621disables the transmission of Router Discovery Advertisements.
622.It Cm rdisc_adv
623specifies that Router Discovery Advertisements should be sent,
624even on point-to-point links,
625which by default only listen to Router Discovery messages.
626.It Cm bcast_rdisc
627specifies that Router Discovery packets should be broadcast instead of
628multicast.
629.It Cm rdisc_pref Ns \&= Ns Ar N
630sets the preference in Router Discovery Advertisements to the optionally
631signed integer
632.Ar N .
633The default preference is 0.
634Default routes with smaller or more negative preferences are preferred by
635clients.
636.It Cm rdisc_interval Ns \&= Ns Ar N
637sets the nominal interval with which Router Discovery Advertisements
638are transmitted to N seconds and their lifetime to 3*N.
639.It Cm fake_default Ns \&= Ns Ar metric
640has an identical effect to
641.Fl F Ar net[/mask][=metric]
642with the network and mask coming from the specified interface.
643.It Cm pm_rdisc
644is similar to
645.Cm fake_default .
646When RIPv2 routes are multicast, so that RIPv1 listeners cannot
647receive them, this feature causes a RIPv1 default route to be
648broadcast to RIPv1 listeners.
649Unless modified with
650.Cm fake_default ,
651the default route is broadcast with a metric of 14.
652That serves as a "poor man's router discovery" protocol.
653.It Cm trust_gateway Ns \&= Ns Ar rname[|net1/mask1|net2/mask2|...]
654causes RIP packets from that router and other routers named in
655other
656.Cm trust_gateway
657keywords to be accepted, and packets from other routers to be ignored.
658If networks are specified, then routes to other networks will be ignored
659from that router.
660.It Cm redirect_ok
661causes RIP to allow ICMP Redirect messages when the system is acting
662as a router and forwarding packets.
663Otherwise, ICMP Redirect messages are overridden.
664.El
665.Sh FILES
666.Bl -tag -width /etc/gateways -compact
667.It Pa /etc/gateways
668for distant gateways
669.El
670.Sh SEE ALSO
671.Xr icmp 4 ,
672.Xr udp 4 ,
673.Xr rtquery 8
674.Rs
675.%T Internet Transport Protocols
676.%R XSIS 028112
677.%Q Xerox System Integration Standard
678.Re
679.Sh HISTORY
680The
681.Nm
682command appeared in
683.Bx 4.2 .
684.Sh BUGS
685It does not always detect unidirectional failures in network interfaces,
686for example, when the output side fails.
687