share/man/man9/rtentry.9

   1 .\"
   2 .\" Copyright 1996 Massachusetts Institute of Technology
   3 .\"
   4 .\" Permission to use, copy, modify, and distribute this software and
   5 .\" its documentation for any purpose and without fee is hereby
   6 .\" granted, provided that both the above copyright notice and this
   7 .\" permission notice appear in all copies, that both the above
   8 .\" copyright notice and this permission notice appear in all
   9 .\" supporting documentation, and that the name of M.I.T. not be used
  10 .\" in advertising or publicity pertaining to distribution of the
  11 .\" software without specific, written prior permission.  M.I.T. makes
  12 .\" no representations about the suitability of this software for any
  13 .\" purpose.  It is provided "as is" without express or implied
  14 .\" warranty.
  15 .\"
  16 .\" THIS SOFTWARE IS PROVIDED BY M.I.T. ``AS IS''.  M.I.T. DISCLAIMS
  17 .\" ALL EXPRESS OR IMPLIED WARRANTIES WITH REGARD TO THIS SOFTWARE,
  18 .\" INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
  19 .\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT
  20 .\" SHALL M.I.T. BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
  21 .\" SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
  22 .\" LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
  23 .\" USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
  24 .\" ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
  25 .\" OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
  26 .\" OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  27 .\" SUCH DAMAGE.
  28 .\"
  29 .\" $FreeBSD: src/share/man/man9/rtentry.9,v 1.11.2.6 2002/03/17 09:12:50 schweikh Exp $
  30 .Dd October 8, 1996
  31 .Os
  32 .Dt RTENTRY 9
  33 .Sh NAME
  34 .Nm rtentry
  35 .Nd structure of an entry in the kernel routing table
  36 .Sh SYNOPSIS
  37 .In sys/types.h
  38 .In sys/socket.h
  39 .In net/route.h
  40 .Sh DESCRIPTION
  41 The kernel provides a common mechanism by which all protocols can store
  42 and retrieve entries from a central table of routes.  Parts of this
  43 mechanism are also used to interact with user-level processes by means
  44 of a socket in the
  45 .Xr route 4
  46 pseudo-protocol family.
  47 The
  48 .Aq Pa net/route.h
  49 header file defines the structures and manifest constants used in this
  50 facility.
  51 .Pp
  52 The basic structure of a route is defined by
  53 .Dq Li struct rtentry ,
  54 which includes the following fields:
  55 .Bl -tag -offset indent -width 6n
  56 .It Xo
  57 .Vt "struct radix_node rt_nodes[2]" ;
  58 .Xc
  59 Glue used by the radix-tree routines.  These members also include in
  60 their substructure the key (i.e., destination address) and mask used
  61 when the route was created.  The
  62 .Fn rt_key \&rt
  63 and
  64 .Fn rt_mask \&rt
  65 macros can be used to extract this information (in the form of a
  66 .Dq Li "struct sockaddr *" )
  67 given a
  68 .Li "struct rtentry *" .
  69 .It Xo
  70 .Vt "struct sockaddr *rt_gateway" ;
  71 .Xc
  72 The
  73 .Dq target
  74 of the route, which can either represent a destination in its own
  75 right (some protocols will put a link-layer address here), or some
  76 intermediate stop on the way to that destination (if the
  77 .Dv RTF_GATEWAY
  78 flag is set).
  79 .It Xo
  80 .Vt "long rt_refcnt" ;
  81 .Xc
  82 Route entries are reference-counted; this field indicates the number
  83 of external (to the radix tree) references.  If the
  84 .Dv RTF_UP
  85 flag is not present, the
  86 .Fn rtfree
  87 function will delete the route from the radix tree when the last
  88 reference drops.
  89 .It Xo
  90 .Vt "u_long rt_flags" ;
  91 .Xc
  92 See below.
  93 .It Xo
  94 .Vt "struct ifnet *rt_ifp" ;
  95 .Xc
  96 .It Xo
  97 .Vt "struct ifaddr *rt_ifa" ;
  98 .Xc
  99 These two fields represent the
 100 .Dq answer ,
 101 as it were, to the question posed by a route lookup; that is, they
 102 name the interface and interface address to be used in sending a
 103 packet to the destination or set of destinations which this route
 104 represents.
 105 .It Xo
 106 .Vt "struct sockaddr *rt_genmask" ;
 107 .Xc
 108 When the
 109 .Fn rtalloc
 110 family of functions performs a cloning operation as requested by the
 111 .Dv RTF_CLONING
 112 or
 113 .Dv RTF_PRCLONING
 114 flag, this field is used as the mask for the new route which is
 115 inserted into the table.  If this field is a null pointer, then a host
 116 route is generated.
 117 .It Xo
 118 .Vt "caddr_t rt_llinfo" ;
 119 .Xc
 120 When the
 121 .Dv RTF_LLINFO
 122 flag is set, this field contains information specific to the link
 123 layer represented by the named interface address.  (It is normally
 124 managed by the
 125 .Fn rt_ifa->ifa_rtrequest
 126 routine.)  Protocols such as
 127 .Xr arp 4
 128 use this field to reference per-destination state internal to that
 129 protocol.
 130 .It Xo
 131 .Vt "struct rt_metrics rt_rmx" ;
 132 .Xc
 133 See below.
 134 .It Xo
 135 .Vt "struct rtentry *rt_gwroute" ;
 136 .Xc
 137 This member is a reference to a route whose destination is
 138 .Li rt_gateway .
 139 It is only used for
 140 .Dv RTF_GATEWAY
 141 routes.
 142 .\" .It Dv "int (*rt_output)();"
 143 .\" See below.
 144 .It Xo
 145 .Vt "struct rtentry *rt_parent" ;
 146 .Xc
 147 A reference to the route from which this route was cloned, or a null
 148 pointer if this route was not generated by cloning.  See also the
 149 .Dv RTF_WASCLONED
 150 flag.
 151 .El
 152 .Pp
 153 The following flag bits are defined:
 154 .Bl -tag -offset indent -width RTF_CHAINDELETE -compact
 155 .It Dv RTF_UP
 156 The route is not deleted.
 157 .It Dv RTF_GATEWAY
 158 The route points to an intermediate destination and not the ultimate
 159 recipient; the
 160 .Li rt_gateway
 161 and
 162 .Li rt_gwroute
 163 fields name that destination.
 164 .It Dv RTF_HOST
 165 This is a host route.
 166 .It Dv RTF_REJECT
 167 The destination is presently unreachable.  This should result in an
 168 .Er EHOSTUNREACH
 169 error from output routines.
 170 .It Dv RTF_DYNAMIC
 171 This route was created dynamically by
 172 .Fn rtredirect .
 173 .It Dv RTF_MODIFIED
 174 This route was modified by
 175 .Fn rtredirect .
 176 .It Dv RTF_DONE
 177 Used only in the
 178 .Xr route 4
 179 protocol, indicating that the request was executed.
 180 .It Dv RTF_CLONING
 181 When this route is returned as a result of a lookup, automatically
 182 create a new route using this one as a template and
 183 .Li rt_genmask
 184 (if present) as a mask.
 185 .It Dv RTF_XRESOLVE
 186 When this route is returned as a result of a lookup, send a report on
 187 the
 188 .Xr route 4
 189 interface requesting that an external process perform resolution for
 190 this route.  (Used in conjunction with
 191 .Dv RTF_CLONING . )
 192 .It Dv RTF_LLINFO
 193 Indicates that this route represents information being managed by a
 194 link layer's adaptation layer (e.g.,
 195 .Tn ARP ) .
 196 .It Dv RTF_STATIC
 197 Indicates that this route was manually added by means of the
 198 .Xr route 8
 199 command.
 200 .It Dv RTF_BLACKHOLE
 201 Requests that output sent via this route be discarded.
 202 .It Dv RTF_PROTO1
 203 .It Dv RTF_PROTO2
 204 .It Dv RTF_PROTO3
 205 Protocol-specific.
 206 .It Dv RTF_PRCLONING
 207 Like
 208 .Dv RTF_CLONING ,
 209 only managed by an entire protocol.  (E.g.,
 210 .Tn IP
 211 uses this flag to manage a per-host cache integrated with the routing
 212 table, for those destinations which do not have a link layer
 213 performing this function.)
 214 .It Dv RTF_WASCLONED
 215 Indicates that this route was generated as a result of cloning
 216 requested by the
 217 .Dv RTF_CLONING
 218 or
 219 .Dv RTF_PRCLONING
 220 flag.  When set, the
 221 .Li rt_parent
 222 field indicates the route from which this one was generated.
 223 .It Dv RTF_PINNED
 224 (Reserved for future use to indicate routes which are not to be
 225 modified by a routing protocol.)
 226 .It Dv RTF_LOCAL
 227 Indicates that the destination of this route is an address configured
 228 as belonging to this system.
 229 .It Dv RTF_BROADCAST
 230 Indicates that the destination is a broadcast address.
 231 .It Dv RTF_MULTICAST
 232 Indicates that the destination is a multicast address.
 233 .El
 234 .Pp
 235 Every route has associated with it a set of metrics, defined by
 236 .Li struct rt_metrics :
 237 .Bl -tag -offset indent -width 6n
 238 .It Xo
 239 .Vt "u_long rmx_locks" ;
 240 .Xc
 241 Flag bits indicating which metrics the kernel is not permitted to
 242 dynamically modify.
 243 .It Xo
 244 .Vt "u_long rmx_mtu" ;
 245 .Xc
 246 MTU for this path.
 247 .It Xo
 248 .Vt "u_long rmx_hopcount" ;
 249 .Xc
 250 Number of intermediate systems on the path to this destination.
 251 .It Xo
 252 .Vt "u_long rmx_expire" ;
 253 .Xc
 254 The time
 255 (a la
 256 .Xr time 3 )
 257 at which this route should expire, or zero if it should never expire.
 258 It is the responsibility of individual protocol suites to ensure that routes
 259 are actually deleted once they expire.
 260 .It Xo
 261 .Vt "u_long rmx_recvpipe" ;
 262 .Xc
 263 Nominally, the bandwidth-delay product for the path
 264 .Em from
 265 the destination
 266 .Em to
 267 this system.  In practice, this value is used to set the size of the
 268 receive buffer (and thus the window in sliding-window protocols like
 269 .Tn TCP ) .
 270 .It Xo
 271 .Vt "u_long rmx_sendpipe" ;
 272 .Xc
 273 As before, but in the opposite direction.
 274 .It Xo
 275 .Vt "u_long rmx_ssthresh" ;
 276 .Xc
 277 The slow-start threshold used in
 278 .Tn TCP
 279 congestion-avoidance.
 280 .It Xo
 281 .Vt "u_long rmx_rtt" ;
 282 .Xc
 283 The round-trip time to this destination, in units of
 284 .Dv RMX_RTTUNIT
 285 per second.
 286 .It Xo
 287 .Vt "u_long rmx_rttvar" ;
 288 .Xc
 289 The average deviation of the round-type time to this destination, in
 290 units of
 291 .Dv RMX_RTTUNIT
 292 per second.
 293 .It Xo
 294 .Vt "u_long rmx_pksent" ;
 295 .Xc
 296 A count of packets successfully sent via this route.
 297 .It Xo
 298 .Vt "u_long rmx_filler[4]" ;
 299 .Xc
 300 .\" XXX badly named
 301 Empty space available for protocol-specific information.
 302 .El
 303 .Sh SEE ALSO
 304 .Xr route 4 ,
 305 .Xr route 8 ,
 306 .Xr rtalloc 9
 307 .Sh HISTORY
 308 The
 309 .Nm
 310 structure first appeared in
 311 .Bx 4.2 .
 312 The radix-tree representation of the routing table and the
 313 .Nm rt_metrics
 314 structure first appeared in
 315 .Bx 4.3 reno .
 316 The
 317 .Nm RTF_PRCLONING
 318 mechanism first appeared in
 319 .Fx 2.0 .
 320 .Sh BUGS
 321 There are a number of historical relics remaining in this interface.
 322 The
 323 .Li rt_gateway
 324 and
 325 .Li rmx_filler
 326 fields could be named better.
 327 .Pp
 328 There is some disagreement over whether it is legitimate for
 329 .Dv RTF_LLINFO
 330 to be set by any process other than
 331 .Fn rt_ifa->ifa_rtrequest .
 332 .Sh AUTHORS
 333 This manual page was written by
 334 .An Garrett Wollman .