*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->Tru64 Unix man pages -> route (7)              



NAME    [Toc]    [Back]

       route - Kernel packet forwarding database

SYNOPSIS    [Toc]    [Back]

       #include   <sys/socket.h>   #include  <net/if.h>  #include
       <net/route.h> int family s  =  socket(PF_ROUTE,  SOCK_RAW,

DESCRIPTION    [Toc]    [Back]

       The  UNIX operating system provides packet routing facilities.
 The kernel maintains a routing information database,
       which  is used in selecting the appropriate network interface
 when transmitting packets.

       A user process  (or  possibly  multiple  cooperating  processes)
 maintains this database by sending messages over a
       special kind of socket. Routing table changes may only  be
       carried out by the superuser.

       The  operating  system may spontaneously emit routing messages
 in response to external events, such as receipt of a
       redirect,  or  failure  to  locate  a suitable route for a

       Routing database entries are of two  types:  those  for  a
       specific  host,  and those for all hosts on a generic subnetwork
 (as specified by a bit mask and  value  under  the
       mask).  The  effect  of a wildcard or default route may be
       achieved by using a mask of all zeros.  There may be hierarchical

       When  the  system  is booted and addresses are assigned to
       the network interfaces, each protocol  family  installs  a
       routing  table  entry  for each interface when it is ready
       for traffic. Normally the  protocol  specifies  the  route
       through  each  interface as a ``direct'' connection to the
       destination host or network.  If the route is direct,  the
       transport layer of a protocol family usually requests that
       the packet be sent to the host specified  in  the  packet.
       Otherwise,  the  interface  is  requested  to  address the
       packet to the gateway listed in the  routing  entry  (that
       is, the packet is forwarded).

       When routing a packet, the kernel first attempts to find a
       route to the destination host. Failing that, a  search  is
       made  for  a  route  to  the  network  of the destination.
       Finally, any route to a default (wildcard) gateway is chosen.
  If no entry is found, the destination is declared to
       be unreachable, and an error message is generated if there
       are  any listeners on the routing control socket described
       later in this section.

       A wildcard routing entry is specified with a zero destination
  address  value.   Wildcard routes are used only when
       the system fails to find a route to the  destination  host
       and network.  The combination of wildcard routes and routing
 redirects can  provide  an  economical  mechanism  for
       routing traffic.

       To  open the channel for passing routing control messages,
       use the socket call shown in the SYNOPSIS.

       The family parameter may be AF_UNSPEC which  will  provide
       routing  information  for  all address families, or can be
       restricted to a  specific  address  family  by  specifying
       which  one  is desired. There can be more than one routing
       socket open per system.

       Messages are formed by a header followed by a small number
       of  sockaddrs  (now variable length), interpreted by position,
 and delimited by the new length entry in  the  sockaddr.
 An example of a message with four addresses might be
       an ISO redirect: destination, netmask, gateway, and author
       of  the  redirect.   The interpretation of which addresses
       are present is given by a bit mask within the header,  and
       the  sequence is least significant to most significant bit
       within the vector.

       Any messages sent to the kernel are returned,  and  copies
       are  sent  to  all  interested listeners.  The kernel will
       provide the process ID for the sender, and the sender  may
       use  an  additional  sequence field to distinguish between
       outstanding messages.  However,  message  replies  may  be
       lost when kernel buffers are exhausted.

       The  kernel may reject certain messages, and will indicate
       this by filling in the rtm_errno  field.  In  the  current
       implementation,  all  routing process run locally, and the
       values for rtm_errno  are  available  through  the  normal
       errno  mechanism,  even  if  the  routing reply message is

       A process may avoid the expense of reading replies to  its
       own  messages  by  issuing  a setsockopt() call indicating
       that the SO_USELOOPBACK option at the SOL_SOCKET level  is
       to  be  turned off. A process may ignore all messages from
       the routing socket by shutting down further input with the
       shutdown() function.

       If a route is in use when it is deleted, the routing entry
       will be marked down and removed from  the  routing  table,
       but the resources associated with it will not be reclaimed
       until all references to it are  released.  User  processes
       can  obtain  information about the routing entry to a specific
 destination by using a RTM_GET message, or by  reading
 the /dev/kmem device.

ERRORS    [Toc]    [Back]

       If  messages  are rejected, rtm_errno may be set to one of
       the following values: The  entry  to  be  created  already
       exists.  The entry to be deleted does not exist.  Insufficient
 resources were available to install a new route.

[ Back ]
 Similar pages
Name OS Title
divert FreeBSD kernel packet diversion mechanism
ipf FreeBSD packet filtering kernel interface
ipf FreeBSD alters packet filtering lists for IP packet input and output
configipforwardstate IRIX turn IP forwarding on or off
forward FreeBSD mail forwarding instructions
ioforw_timeout HP-UX enable timeout in I/O forwarding
forward OpenBSD e-mail forwarding information file
kvm_mkdb OpenBSD create kernel database
pf OpenBSD packet filter
ipl FreeBSD IP packet log device
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service