xref: /openbsd-src/share/man/man4/route.4 (revision 99fd087599a8791921855f21bd7e36130f39aadc)
1.\"	$OpenBSD: route.4,v 1.54 2019/11/22 06:26:00 claudio Exp $
2.\"	$NetBSD: route.4,v 1.3 1994/11/30 16:22:31 jtc Exp $
3.\"
4.\" Copyright (c) 1990, 1991, 1993
5.\"	The Regents of the University of California.  All rights reserved.
6.\"
7.\" Redistribution and use in source and binary forms, with or without
8.\" modification, are permitted provided that the following conditions
9.\" are met:
10.\" 1. Redistributions of source code must retain the above copyright
11.\"    notice, this list of conditions and the following disclaimer.
12.\" 2. Redistributions in binary form must reproduce the above copyright
13.\"    notice, this list of conditions and the following disclaimer in the
14.\"    documentation and/or other materials provided with the distribution.
15.\" 3. Neither the name of the University nor the names of its contributors
16.\"    may be used to endorse or promote products derived from this software
17.\"    without specific prior written permission.
18.\"
19.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
20.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
21.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
22.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
23.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
24.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
25.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
26.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
27.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
28.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
29.\" SUCH DAMAGE.
30.\"
31.\"     @(#)route.4	8.6 (Berkeley) 4/19/94
32.\"
33.Dd $Mdocdate: November 22 2019 $
34.Dt ROUTE 4
35.Os
36.Sh NAME
37.Nm route
38.Nd kernel packet forwarding database
39.Sh SYNOPSIS
40.In sys/socket.h
41.In net/if.h
42.In net/route.h
43.Ft int
44.Fn socket AF_ROUTE SOCK_RAW family
45.Sh DESCRIPTION
46.Ox
47provides some packet routing facilities.
48The kernel maintains a routing information database, which
49is used in selecting the appropriate network interface when
50transmitting packets.
51.Pp
52A user process (or possibly multiple co-operating processes)
53maintains this database by sending messages over a special kind
54of socket.
55This supplants fixed size
56.Xr ioctl 2 Ns 's
57used in earlier releases.
58Routing table changes may only be carried out by the super user.
59.Pp
60The operating system may spontaneously emit routing messages in response
61to external events, such as receipt of a redirect, or failure to
62locate a suitable route for a request.
63The message types are described in greater detail below.
64.Pp
65Routing database entries come in two flavors: for a specific
66host, or for all hosts on a generic subnetwork (as specified
67by a bit mask and value under the mask).
68The effect of wildcard or default route may be achieved by using
69a mask of all zeros, and there may be hierarchical routes.
70.Pp
71When the system is booted and addresses are assigned
72to the network interfaces, each protocol family
73installs a routing table entry for each interface when it is ready for traffic.
74Normally the protocol specifies the route
75through each interface as a
76.Dq direct
77connection to the destination host
78or network.
79If the route is direct, the transport layer of a protocol family usually
80requests the packet be sent to the same host specified in the packet.
81Otherwise, the interface is requested to address the packet to the gateway
82listed in the routing entry (i.e., the packet is forwarded).
83.Pp
84When routing a packet,
85the kernel will attempt to find
86the most specific route matching the destination.
87(If there are two different mask and value-under-the-mask pairs
88that match, the more specific is the one with more bits in the mask.
89A route to a host is regarded as being supplied with a mask of
90as many ones as there are bits in the destination.)
91If no entry is found, the destination is declared to be unreachable,
92and a routing\-miss message is generated if there are any
93listeners on the routing control socket described below.
94.Pp
95If there are two identical destinations, the route priority acts as a
96tie-breaker.
97If there are multiple routes to the same destination,
98the one with the lowest priority wins.
99The kernel assigns certain default priorities based on the type of
100route, as given in the table below.
101For connected and static routes, this default priority is added to the
102interface's priority.
103.Pp
104A wildcard routing entry is specified with a zero
105destination address value and a mask of all zeroes.
106Wildcard routes will be used
107when the system fails to find other routes matching the
108destination.
109The combination of wildcard routes and routing redirects can provide
110an economical mechanism for routing traffic.
111Routes created by redirects from wildcard routes and other routes
112will be marked
113.Em cloned ,
114until their
115.Dq parent
116from which they were created has disappeared.
117.Pp
118Route labels can be attached to routes and may contain arbitrary
119information about the route.
120Labels are sent over the routing socket (see below) as
121.Vt sockaddr_rtlabel
122structures.
123.Ss The Routing Socket
124One opens the channel for passing routing control messages
125by using the
126.Xr socket 2
127call shown in the
128.Sx SYNOPSIS
129above.
130.Pp
131The
132.Fa family
133parameter may be
134.Dv AF_UNSPEC ,
135which will provide
136routing information for all address families, or can be restricted
137to a specific address family by specifying which one is desired.
138There can be more than one routing socket open per system.
139.Pp
140Messages are formed by a header followed by a small
141number of
142.Vt sockaddr
143structures (which are variable length),
144interpreted by position, and delimited
145by the length entry in the
146.Vt sockaddr .
147An example of a message with four addresses might be an
148IPv4 route addition: the destination, netmask, gateway, and label,
149since both netmasks and labels are sent over the routing socket as
150.Vt sockaddr
151structures.
152The interpretation of which addresses are present is given by a
153bit mask within the header, and the sequence is least significant
154to most significant bit within the vector.
155.Pp
156Any messages sent to the kernel are returned, and copies are sent
157to all interested listeners.
158The kernel will provide the process ID
159of the sender, and the sender may use an additional sequence
160field to distinguish between outstanding messages.
161However, message replies may be lost when kernel buffers are exhausted.
162.Pp
163The kernel may reject certain messages, and will indicate this
164by filling in the
165.Va rtm_errno
166field.
167The routing code returns
168.Er EEXIST
169if
170requested to duplicate an existing entry,
171.Er ESRCH
172if
173requested to delete a non-existent entry,
174or
175.Er ENOBUFS
176if insufficient resources were available
177to install a new route.
178In the current implementation, all routing processes run locally,
179and the values for
180.Va rtm_errno
181are available through the normal
182.Va errno
183mechanism, even if the routing reply message is lost.
184.Pp
185A process may avoid the expense of reading replies to
186its own messages by issuing a
187.Xr setsockopt 2
188call indicating that the
189.Dv SO_USELOOPBACK
190option at the
191.Dv SOL_SOCKET
192level is to be turned off.
193A process may ignore all messages from the routing socket
194by doing a
195.Xr shutdown 2
196system call for further input.
197.Pp
198A process can specify an alternate routing table by using the
199.Dv ROUTE_TABLEFILTER
200.Xr setsockopt 2 .
201A value of
202.Dv RTABLE_ANY
203specifies all routing tables.
204For example, to receive messages for routing table 5:
205.Bd -literal -offset indent
206unsigned int rdomain = 5;
207
208if (setsockopt(routefd, AF_ROUTE, ROUTE_TABLEFILTER,
209    &rdomain, sizeof(rdomain)) == -1)
210	err(1, "setsockopt(ROUTE_TABLEFILTER)");
211.Ed
212.Pp
213A process can specify which route message types it's interested in
214by using
215.Dv ROUTE_FILTER(int type)
216and issuing a setsockopt call with the
217.Dv ROUTE_MSGFILTER
218option at the
219.Dv AF_ROUTE
220level.
221For example, to only get interface specific messages:
222.Bd -literal -offset indent
223unsigned int rtfilter;
224
225rtfilter = ROUTE_FILTER(RTM_IFINFO) |
226    ROUTE_FILTER(RTM_IFANNOUNCE);
227
228if (setsockopt(routefd, AF_ROUTE, ROUTE_MSGFILTER,
229    &rtfilter, sizeof(rtfilter)) == -1)
230	err(1, "setsockopt(ROUTE_MSGFILTER)");
231.Ed
232.Pp
233Similarly, a process can specify that it is only interested in messages
234relating to routes where the priority is no more than a certain value
235by issuing a setsockopt call with the
236.Dv ROUTE_PRIOFILTER
237option.
238For example, to select only local, directly connected and static routes:
239.Bd -literal -offset indent
240unsigned int maxprio = RTP_STATIC;
241
242if (setsockopt(routefd, AF_ROUTE, ROUTE_PRIOFILTER,
243    &maxprio, sizeof(maxprio)) == -1)
244	err(1, "setsockopt(ROUTE_PRIOFILTER)");
245.Ed
246.Pp
247The predefined constants for the routing priorities are:
248.Bd -literal
249#define RTP_NONE	0	/* unset priority use sane default */
250#define RTP_LOCAL	1	/* local address routes (must be the highest) */
251#define RTP_CONNECTED	4	/* directly connected routes */
252#define RTP_STATIC	8	/* static routes base priority */
253#define RTP_EIGRP	28	/* EIGRP routes */
254#define RTP_OSPF	32	/* OSPF routes */
255#define RTP_ISIS	36	/* IS-IS routes */
256#define RTP_RIP		40	/* RIP routes */
257#define RTP_BGP		48	/* BGP routes */
258#define RTP_DEFAULT	56	/* routes that have nothing set */
259#define RTP_PROPOSAL_STATIC	57
260#define RTP_PROPOSAL_DHCLIENT	58
261#define RTP_PROPOSAL_SLAAC	59
262#define RTP_PROPOSAL_UMB	60
263#define RTP_PROPOSAL_SOLICIT	61	/* request reply of all RTM_PROPOSAL */
264#define RTP_MAX		63	/* maximum priority */
265#define RTP_ANY		64	/* any of the above */
266#define RTP_MASK	0x7f
267#define RTP_DOWN	0x80	/* route/link is down */
268.Ed
269.Pp
270If a route is in use when it is deleted,
271the routing entry will be marked down and removed from the routing table,
272but the resources associated with it will not
273be reclaimed until all references to it are released.
274User processes can obtain information about the routing
275entry to a specific destination by using a
276.Dv RTM_GET
277message or via the
278.Dv PF_ROUTE
279.Xr sysctl 2 .
280.Pp
281Messages include:
282.Bd -literal
283#define RTM_ADD		0x1	/* Add Route */
284#define RTM_DELETE	0x2	/* Delete Route */
285#define RTM_CHANGE	0x3	/* Change Metrics or flags */
286#define RTM_GET		0x4	/* Report Metrics */
287#define RTM_LOSING	0x5	/* Kernel Suspects Partitioning */
288#define RTM_REDIRECT	0x6	/* Told to use different route */
289#define RTM_MISS	0x7	/* Lookup failed on this address */
290#define RTM_RESOLVE	0xb	/* req to resolve dst to LL addr */
291#define RTM_NEWADDR	0xc	/* address being added to iface */
292#define RTM_DELADDR	0xd	/* address being removed from iface */
293#define RTM_IFINFO	0xe	/* iface going up/down etc. */
294#define RTM_IFANNOUNCE	0xf	/* iface arrival/departure */
295#define RTM_DESYNC	0x10	/* route socket buffer overflow */
296#define RTM_INVALIDATE	0x11	/* Invalidate cache of L2 route */
297.Ed
298.Pp
299A message header consists of one of the following:
300.Bd -literal
301struct rt_msghdr {
302	u_short	rtm_msglen;	/* to skip over non-understood messages */
303	u_char	rtm_version;	/* future binary compatibility */
304	u_char	rtm_type;	/* message type */
305	u_short	rtm_hdrlen;	/* sizeof(rt_msghdr) to skip over the header */
306	u_short	rtm_index;	/* index for associated ifp */
307	u_short rtm_tableid;	/* routing table id */
308	u_char	rtm_priority;	/* routing priority */
309	u_char	rtm_mpls;	/* MPLS additional infos */
310	int	rtm_addrs;	/* bitmask identifying sockaddrs in msg */
311	int	rtm_flags;	/* flags, incl. kern & message, e.g. DONE */
312	int	rtm_fmask;	/* bitmask used in RTM_CHANGE message */
313	pid_t	rtm_pid;	/* identify sender */
314	int	rtm_seq;	/* for sender to identify action */
315	int	rtm_errno;	/* why failed */
316	u_int	rtm_inits;	/* which metrics we are initializing */
317	struct	rt_metrics rtm_rmx; /* metrics themselves */
318};
319
320struct if_msghdr {
321	u_short	ifm_msglen;	/* to skip over non-understood messages */
322	u_char	ifm_version;	/* future binary compatibility */
323	u_char	ifm_type;	/* message type */
324	u_short ifm_hdrlen;	/* sizeof(if_msghdr) to skip over the header */
325	u_short	ifm_index;	/* index for associated ifp */
326	u_short	ifm_tableid;	/* routing table id */
327	u_char	ifm_pad1;
328	u_char	ifm_pad2;
329	int	ifm_addrs;	/* like rtm_addrs */
330	int	ifm_flags;	/* value of if_flags */
331	int	ifm_xflags;
332	struct	if_data ifm_data;/* statistics and other data about if */
333};
334
335struct ifa_msghdr {
336	u_short	ifam_msglen;	/* to skip over non-understood messages */
337	u_char	ifam_version;	/* future binary compatibility */
338	u_char	ifam_type;	/* message type */
339	u_short ifam_hdrlen;	/* sizeof(ifa_msghdr) to skip over the header */
340	u_short	ifam_index;	/* index for associated ifp */
341	u_short	ifam_tableid;	/* routing table id */
342	u_char	ifam_pad1;
343	u_char	ifam_pad2;
344	int	ifam_addrs;	/* like rtm_addrs */
345	int	ifam_flags;	/* value of ifa_flags */
346	int	ifam_metric;	/* value of ifa_metric */
347};
348
349struct if_announcemsghdr {
350	u_short	ifan_msglen;	/* to skip over non-understood messages */
351	u_char	ifan_version;	/* future binary compatibility */
352	u_char	ifan_type;	/* message type */
353	u_short ifan_hdrlen;	/* sizeof(ifa_msghdr) to skip over the header */
354	u_short	ifan_index;	/* index for associated ifp */
355	u_short	ifan_what;	/* what type of announcement */
356	char	ifan_name[IFNAMSIZ];	/* if name, e.g. "en0" */
357};
358.Ed
359.Pp
360The
361.Dv RTM_IFINFO
362message uses an
363.Vt if_msghdr
364header, the
365.Dv RTM_NEWADDR
366and
367.Dv RTM_DELADDR
368messages use an
369.Vt ifa_msghdr
370header,
371the
372.Dv RTM_IFANNOUNCE
373message uses an
374.Vt if_announcemsghdr
375header,
376.Dv RTM_INVALIDATE
377is used only internally in the kernel and should never appear in a route
378message,
379and all other messages use the
380.Vt rt_msghdr
381header.
382.Pp
383The metrics structure is:
384.Bd -literal
385struct rt_metrics {
386	u_int64_t	rmx_pksent;	/* packets sent using this route */
387	int64_t		rmx_expire;	/* lifetime for route, e.g. redirect */
388	u_int		rmx_locks;	/* Kernel must leave these values */
389	u_int		rmx_mtu;	/* MTU for this path */
390	u_int		rmx_refcnt;	/* # references hold */
391	u_int		rmx_hopcount;	/* max hops expected */
392	u_int		rmx_recvpipe;	/* inbound delay-bandwidth product */
393	u_int		rmx_sendpipe;	/* outbound delay-bandwidth product */
394	u_int		rmx_ssthresh;	/* outbound gateway buffer limit */
395	u_int		rmx_rtt;	/* estimated round trip time */
396	u_int		rmx_rttvar;	/* estimated rtt variance */
397	u_int		rmx_pad;
398};
399.Ed
400.Pp
401Only
402.Va rmx_mtu , rmx_expire , rmx_pksent ,
403and
404.Va rmx_locks
405are used by the kernel routing table.
406All other values will be ignored when inserting them into the kernel and are
407set to zero in routing messages sent by the kernel.
408They are left for compatibility reasons with other systems.
409.Pp
410Flags include the values:
411.Bd -literal
412#define	RTF_UP        0x1       /* route usable */
413#define	RTF_GATEWAY   0x2       /* destination is a gateway */
414#define	RTF_HOST      0x4       /* host entry (net otherwise) */
415#define	RTF_REJECT    0x8       /* host or net unreachable */
416#define	RTF_DYNAMIC   0x10      /* created dynamically (by redirect) */
417#define	RTF_MODIFIED  0x20      /* modified dynamically (by redirect) */
418#define	RTF_DONE      0x40      /* message confirmed */
419#define	RTF_CLONING   0x100     /* generate new routes on use */
420#define	RTF_MULTICAST 0x200     /* route associated to a mcast addr.  */
421#define	RTF_LLINFO    0x400     /* generated by ARP or NDP */
422#define	RTF_STATIC    0x800     /* manually added */
423#define	RTF_BLACKHOLE 0x1000    /* just discard pkts (during updates) */
424#define	RTF_PROTO3    0x2000    /* protocol specific routing flag */
425#define	RTF_PROTO2    0x4000    /* protocol specific routing flag */
426#define	RTF_PROTO1    0x8000    /* protocol specific routing flag */
427#define	RTF_CLONED    0x10000   /* this is a cloned route */
428#define RTF_MPATH     0x40000   /* multipath route or operation */
429#define RTF_MPLS      0x100000  /* MPLS additional infos */
430#define RTF_LOCAL     0x200000	/* route to a local address */
431#define RTF_BROADCAST 0x400000	/* route associated to a bcast addr. */
432#define RTF_CONNECTED 0x800000	/* interface route */
433.Ed
434.Pp
435The following flags (defined as
436.Dv RTF_FMASK )
437can be changed by an RTM_CHANGE request:
438.Dv RTF_LLINFO ,
439.Dv RTF_PROTO1 ,
440.Dv RTF_PROTO2 ,
441.Dv RTF_PROTO3 ,
442.Dv RTF_BLACKHOLE ,
443.Dv RTF_REJECT ,
444.Dv RTF_STATIC
445and
446.Dv RTF_MPLS .
447.Pp
448Specifiers for metric values in
449.Va rmx_locks
450and
451.Va rtm_inits
452are:
453.Bd -literal
454#define RTV_MTU		0x1	/* init or lock _mtu */
455#define RTV_HOPCOUNT	0x2	/* init or lock _hopcount */
456#define RTV_EXPIRE	0x4	/* init or lock _expire */
457#define RTV_RPIPE	0x8	/* init or lock _recvpipe */
458#define RTV_SPIPE	0x10	/* init or lock _sendpipe */
459#define RTV_SSTHRESH	0x20	/* init or lock _ssthresh */
460#define RTV_RTT		0x40	/* init or lock _rtt */
461#define RTV_RTTVAR	0x80	/* init or lock _rttvar */
462.Ed
463.Pp
464Only
465.Dv RTV_MTU
466and
467.Dv RTV_EXPIRE
468should be used; all other flags are ignored.
469.Pp
470Specifiers for which addresses are present in the messages are:
471.Bd -literal
472#define RTA_DST		0x1	/* destination sockaddr present */
473#define RTA_GATEWAY	0x2	/* gateway sockaddr present */
474#define RTA_NETMASK	0x4	/* netmask sockaddr present */
475#define RTA_IFP		0x10	/* interface name sockaddr present */
476#define RTA_IFA		0x20	/* interface addr sockaddr present */
477#define RTA_AUTHOR	0x40	/* sockaddr for author of redirect */
478#define RTA_BRD		0x80	/* for NEWADDR, bcast or p-p dest addr */
479#define RTA_SRC		0x100	/* source sockaddr present */
480#define RTA_SRCMASK	0x200	/* source netmask present */
481#define RTA_LABEL	0x400	/* route label present */
482.Ed
483.Sh SEE ALSO
484.Xr netstat 1 ,
485.Xr socket 2 ,
486.Xr sysctl 2 ,
487.Xr rtable 4 ,
488.Xr mygate 5 ,
489.Xr route 8 ,
490.Xr route 9
491.Sh HISTORY
492A
493.Dv PF_ROUTE
494protocol family first appeared in
495.Bx 4.3 Reno .
496