1.\" $NetBSD: routed.8,v 1.23 1998/11/13 22:06:56 abs 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 BSD 4.4 39.Sh NAME 40.Nm routed , 41.Nm rdisc 42.Nd network RIP and router discovery routing daemon 43.Sh SYNOPSIS 44.Nm 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 advertise 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 insure 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 Ns , 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 listen 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 \f3\-q\f1 might need 227.Cm no_rdisc 228described below. 229.Pp 230See the 231.Cm pm_rdisc 232facility described below to support "legacy" systems 233that can handle neither RIPv2 nor Router Discovery. 234.Pp 235By default, neither Router Discovery advertisements nor solicitations 236are sent over point to point links (e.g. PPP). 237The netmask associated with point-to-point links (such as SLIP 238or PPP, with the IFF_POINTOPOINT flag) is used by 239.Nm 240to infer the netmask used by the remote system when RIPv1 is used. 241.Pp 242The following options are available: 243.Bl -tag -width indent 244.It Fl s 245force 246.Nm 247to supply routing information. 248This is the default if multiple network interfaces are present on which 249RIP or Router Discovery have not been disabled, and if the kernel switch 250ipforwarding=1. 251.It Fl q 252is the opposite of the 253.Fl s 254option. 255This is the default when only one interface is present. 256.It Fl d 257do not run in the background. 258This option is meant for interactive use. 259.It Fl g 260used on internetwork routers to offer a route 261to the "default" destination. 262It is equivalent to 263.Fl F 264.Cm 0/0,1 265and is present mostly for historical reasons. 266A better choice is 267.Fl P Cm pm_rdisc 268on the command line or 269.Cm pm_rdisc 270in the 271.Pa /etc/gateways 272file. 273since a larger metric 274will be used, reducing the spread of the potentially dangerous 275default route. 276This is typically used on a gateway to the Internet, 277or on a gateway that uses another routing protocol whose routes 278are not reported to other local routers. 279Notice that because a metric of 1 is used, this feature is 280dangerous. It is more commonly accidentally used to create chaos with a 281routing loop than to solve problems. 282.It Fl h 283cause host or point-to-point routes to not be advertised, 284provided there is a network route going the same direction. 285That is a limited kind of aggregation. 286This option is useful on gateways to Ethernets that have other gateway 287machines connected with point-to-point links such as SLIP. 288.It Fl m 289cause the machine to advertise a host or point-to-point route to 290its primary interface. 291It is useful on multi-homed machines such as NFS servers. 292This option should not be used except when the cost of 293the host routes it generates is justified by the popularity of 294the server. 295It is effective only when the machine is supplying 296routing information, because there is more than one interface. 297The 298.Fl m 299option overrides the 300.Fl q 301option to the limited extent of advertising the host route. 302.It Fl A 303do not ignore RIPv2 authentication if we do not care about RIPv2 304authentication. 305This option is required for conformance with RFC 1723. 306However, it makes no sense and breaks using RIP as a discovery protocol 307to ignore all RIPv2 packets that carry authentication when this machine 308does not care about authentication. 309.It Fl t 310increase the debugging level, which causes more information to be logged 311on the tracefile specified with 312.Fl T 313or standard out. 314The debugging level can be increased or decreased 315with the 316.Em SIGUSR1 317or 318.Em SIGUSR2 319signals or with the 320.Xr rtquery 8 321command. 322.It Fl T Ar tracefile 323increases the debugging level to at least 1 and 324causes debugging information to be appended to the trace file. 325Note that because of security concerns, it is wisest to not run 326.Nm 327routinely with tracing directed to a file. 328.It Fl v 329display and logs the version of daemon. 330.It Fl F Ar net[/mask][,metric] 331minimize routes in transmissions via interfaces with addresses that match 332.Em net/mask , 333and synthesizes a default route to this machine with the 334.Em metric . 335The intent is to reduce RIP traffic on slow, point-to-point links 336such as PPP links by replacing many large UDP packets of RIP information 337with a single, small packet containing a "fake" default route. 338If 339.Em metric 340is absent, a value of 14 is assumed to limit 341the spread of the "fake" default route. 342This is a dangerous feature that when used carelessly can cause routing 343loops. 344Notice also that more than one interface can match the specified network 345number and mask. 346See also 347.Fl g . 348.It Fl P Ar parms 349is equivalent to adding the parameter 350line 351.Em parms 352to the 353.Pa /etc/gateways 354file. 355.El 356.Pp 357Any other argument supplied is interpreted as the name 358of a file in which the actions of 359.Nm 360should be logged. 361It is better to use 362.Fl T 363instead of 364appending the name of the trace file to the command. 365.Pp 366.Nm 367also supports the notion of 368"distant" 369.Em passive 370or 371.Em active 372gateways. 373When 374.Nm 375is started, it reads the file 376.Pa /etc/gateways 377to find such distant gateways which may not be located using 378only information from a routing socket, to discover if some 379of the local gateways are 380.Em passive , 381and to obtain other parameters. 382Gateways specified in this manner should be marked passive 383if they are not expected to exchange routing information, 384while gateways marked active 385should be willing to exchange RIP packets. 386Routes through 387.Em passive 388gateways are installed in the 389kernel's routing tables once upon startup and are not included in 390transmitted RIP responses. 391.Pp 392Distant active gateways are treated like network interfaces. 393RIP responses are sent 394to the distant 395.Em active 396gateway. 397If no responses are received, the associated route is deleted from 398the kernel table and RIP responses advertised via other interfaces. 399If the distant gateway resumes sending RIP responses, the associated 400route is restored. 401.Pp 402Such gateways can be useful on media that do not support broadcasts 403or multicasts but otherwise act like classic shared media like 404Ethernets such as some ATM networks. 405One can list all RIP routers reachable on the ATM network in 406.Pa /etc/gateways 407with a series of 408"host" lines. 409Note that it is usually desirable to use RIPv2 in such situations 410to avoid generating lists of inferred host routes. 411.Pp 412Gateways marked 413.Em external 414are also passive, but are not placed in the kernel 415routing table nor are they included in routing updates. 416The function of external entries is to indicate 417that another routing process 418will install such a route if necessary, 419and that other routes to that destination should not be installed 420by 421.Nm Ns . 422Such entries are only required when both routers may learn of routes 423to the same destination. 424.Pp 425The 426.Pa /etc/gateways 427file is comprised of a series of lines, each in 428one of the following two formats or consist of parameters described later. 429Blank lines and lines starting with '#' are comments. 430.Pp 431.Bd -ragged 432.Cm net 433.Ar Nname[/mask] 434.Cm gateway 435.Ar Gname 436.Cm metric 437.Ar value 438.Pf < Cm passive No \&| 439.Cm active No \&| 440.Cm extern Ns > 441.Ed 442.Bd -ragged 443.Cm host 444.Ar Hname 445.Cm gateway 446.Ar Gname 447.Cm metric 448.Ar value 449.Pf < Cm passive No \&| 450.Cm active No \&| 451.Cm extern Ns > 452.Ed 453.Pp 454.Ar Nname 455or 456.Ar Hname 457is the name of the destination network or host. 458It may be a symbolic network name or an Internet address 459specified in "dot" notation (see 460.Xr inet 3 ). 461(If it is a name, then it must either be defined in 462.Pa /etc/networks 463or 464.Pa /etc/hosts , 465or 466.Xr named 8 , 467must have been started before 468.Nm Ns .) 469.Pp 470.Ar Mask 471is an optional number between 1 and 32 indicating the netmask associated 472with 473.Ar Nname . 474.Pp 475.Ar Gname 476is the name or address of the gateway to which RIP responses should 477be forwarded. 478.Pp 479.Ar Value 480is the hop count to the destination host or network. 481.Ar " Host hname " 482is equivalent to 483.Ar " net nname/32 ". 484.Pp 485One of the keywords 486.Cm passive , 487.Cm active 488or 489.Cm external 490must be present to indicate whether the gateway should be treated as 491.Cm passive 492or 493.Cm active 494(as described above), 495or whether the gateway is 496.Cm external 497to the scope of the RIP protocol. 498.Pp 499As can be seen when debugging is turned on with 500.Fl t , 501such lines create psuedo-interfaces. 502To set parameters for remote or external interfaces, 503a line starting with 504.Cm if=alias(Hname) , 505.Cm if=remote(Hname) , 506etc. should be used. 507.Pp 508Lines that start with neither "net" nor "host" must consist of one 509or more of the following parameter settings, separated by commas or 510blanks: 511.Bl -tag -width Ds 512.It Cm if Ns \&= Ns Ar ifname 513indicates that the other parameters on the line apply to the interface 514name 515.Ar ifname . 516.It Cm subnet Ns \&= Ns Ar nname[/mask][,metric] 517advertises a route to network 518.Ar nname 519with mask 520.Ar mask 521and the supplied metric (default 1). 522This is useful for filling "holes" in CIDR allocations. 523This parameter must appear by itself on a line. 524The network number must specify a full, 32-bit value, as in 192.0.2.0 525instead of 192.0.2. 526.Pp 527Do not use this feature unless necessary. It is dangerous. 528.It Cm ripv1_mask Ns \&= Ns Ar nname/mask1,mask2 529specifies that netmask of the network of which 530.Cm nname/mask1\f1 531is 532a subnet should be 533.Cm mask2 . 534For example \f2ripv1_mask=192.0.2.16/28,27\f1 marks 192.0.2.16/28 535as a subnet of 192.0.2.0/27 instead of 192.0.2.0/24. 536.It Cm passwd Ns \&= Ns Ar XXX[|KeyID[start|stop]] 537specifies a RIPv2 cleartext password that will be included on 538all RIPv2 responses sent, and checked on all RIPv2 responses received. 539Any blanks, tab characters, commas, or '#', '|', or NULL characters in the 540password must be escaped with a backslash (\\). 541The common escape sequences \\n, \\r, \\t, \\b, and \\xxx have their 542usual meanings. 543The 544.Cm KeyID 545must be unique but is ignored for cleartext passwords. 546If present, 547.Cm start 548and 549.Cm stop 550are timestamps in the form year/month/day@hour:minute. 551They specify when the password is valid. 552The valid password with the most future is used on output packets, unless 553all passwords have expired, in which case the password that expired most 554recently is used, or unless no passwords are valid yet, in which case 555no password is output. 556Incoming packets can carry any password that is valid, will 557be valid within 24 hours, or that was valid within 24 hours. 558To protect the secrets, the passwd settings are valid only in the 559.Em /etc/gateways 560file and only when that file is readable only by UID 0. 561.It Cm md5_passwd Ns \&= Ns Ar XXX|KeyID[start|stop] 562specifies a RIPv2 MD5 password. 563Except that a 564.Cm KeyID 565is required, this keyword is similar to 566.Cm passwd . 567.It Cm no_ag 568turns off aggregation of subnets in RIPv1 and RIPv2 responses. 569.It Cm no_super_ag 570turns off aggregation of networks into supernets in RIPv2 responses. 571.It Cm passive 572marks the interface to not be advertised in updates sent via other 573interfaces, and turns off all RIP and router discovery through the interface. 574.It Cm no_rip 575disables all RIP processing on the specified interface. 576If no interfaces are allowed to process RIP packets, 577.Nm 578acts purely as a router discovery daemon. 579.Pp 580Note that turning off RIP without explicitly turning on router 581discovery advertisements with 582.Cm rdisc_adv 583or 584.Fl s 585causes 586.Nm 587to act as a client router discovery daemon, not advertising. 588.It Cm no_rip_mcast 589causes RIPv2 packets to be broadcast instead of multicast. 590.It Cm no_ripv1_in 591causes RIPv1 received responses to be ignored. 592.It Cm no_ripv2_in 593causes RIPv2 received responses to be ignored. 594.It Cm ripv2_out 595turns off RIPv1 output and causes RIPv2 advertisements to be 596multicast when possible. 597.It Cm ripv2 598is equivalent to 599.Cm no_ripv1_in 600and 601.Cm no_ripv1_out . 602.It Cm no_rdisc 603disables the Internet Router Discovery Protocol. 604.It Cm no_solicit 605disables the transmission of Router Discovery Solicitations. 606.It Cm send_solicit 607specifies that Router Discovery solicitations should be sent, 608even on point-to-point links, 609which by default only listen to Router Discovery messages. 610.It Cm no_rdisc_adv 611disables the transmission of Router Discovery Advertisements. 612.It Cm rdisc_adv 613specifies that Router Discovery Advertisements should be sent, 614even on point-to-point links, 615which by default only listen to Router Discovery messages. 616.It Cm bcast_rdisc 617specifies that Router Discovery packets should be broadcast instead of 618multicast. 619.It Cm rdisc_pref Ns \&= Ns Ar N 620sets the preference in Router Discovery Advertisements to the optionally 621signed integer 622.Ar N . 623The default preference is 0. 624Default routes with smaller or more negative preferences are preferred by 625clients. 626.It Cm rdisc_interval Ns \&= Ns Ar N 627sets the nominal interval with which Router Discovery Advertisements 628are transmitted to N seconds and their lifetime to 3*N. 629.It Cm fake_default Ns \&= Ns Ar metric 630has an identical effect to 631.Fl F Ar net[/mask][=metric] 632with the network and mask coming from the specified interface. 633.It Cm pm_rdisc 634is similar to 635.Cm fake_default . 636When RIPv2 routes are multicast, so that RIPv1 listeners cannot 637receive them, this feature causes a RIPv1 default route to be 638broadcast to RIPv1 listeners. 639Unless modified with 640.Cm fake_default , 641the default route is broadcast with a metric of 14. 642That serves as a "poor man's router discovery" protocol. 643.It Cm trust_gateway Ns \&= Ns Ar rname[|net1/mask1|net2/mask2|...] 644causes RIP packets from that router and other routers named in 645other 646.Cm trust_gateway 647keywords to be accepted, and packets from other routers to be ignored. 648If networks are specified, then routes to other networks will be ignored 649from that router. 650.It Cm redirect_ok 651causes RIP to allow ICMP Redirect messages when the system is acting 652as a router and forwarding packets. 653Otherwise, ICMP Redirect messages are overridden. 654.El 655.Pp 656.Sh FILES 657.Bl -tag -width /etc/gateways -compact 658.It Pa /etc/gateways 659for distant gateways 660.El 661.Sh SEE ALSO 662.Xr icmp 4 , 663.Xr udp 4 , 664.Xr gated 8 , 665.Xr htable 8 , 666.Xr rtquery 8 . 667.Rs 668.%T Internet Transport Protocols 669.%R XSIS 028112 670.%Q Xerox System Integration Standard 671.Re 672.Sh BUGS 673It does not always detect unidirectional failures in network interfaces, 674for example, when the output side fails. 675.Sh HISTORY 676The 677.Nm 678command appeared in 679.Bx 4.2 . 680