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