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