route - kernel packet forwarding database


     #include <sys/types.h>
     #include <sys/socket.h>
     #include <net/if.h>
     #include <net/route.h>

     int socket(PF_ROUTE, SOCK_RAW, int protocol);


     UNIX provides some packet  routing  facilities.  The  kernel
     maintains  a  routing information database, which is used in
     selecting the appropriate network interface  when  transmit-
     ting packets.

     A user process (or possibly multiple co-operating processes)
     maintains  this  database by sending messages over a special
     kind of socket. This supplants fixed size ioctl(2)'s  speci-
     fied in  routing(7P). Routing table changes may only be car-
     ried out by the superuser.

     The operating system may spontaneously emit routing messages
     in  response  to  external  events, such as receipt of a re-
     direct, or failure to locate a suitable route for a request.
     The message types are described in greater detail below.

     Routing database entries come in two flavors: entries for  a
     specific host, or entries for all hosts on a generic subnet-
     work (as specified by a bit mask and value under the  mask).
     The  effect  of wildcard or default route may be achieved by
     using a mask of all zeros, and  there  may  be  hierarchical

     When the system is booted and addresses are assigned to  the
     network  interfaces, the internet 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  the  packet  be
     sent  to  the same 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

     When routing a packet, the kernel attempts to find  the most
     specific  route  matching  the  destination.  If no entry is
     found, the destination is declared to be unreachable, and  a
     routing-miss message is generated if there are any listeners
     on the routing control socket (described  below).  If  there
     are  two  different mask and value-under-the-mask pairs that
     match, the more specific is the one with more  bits  in  the
     mask. A route to a host is regarded as being supplied with a
     mask of as many ones as there are bits in the destination.

     A wildcard routing entry is specified with a  zero  destina-
     tion  address  value,  and  a  mask  of all zeroes. Wildcard
     routes are used when the system fails to find  other  routes
     matching the destination. The combination of wildcard routes
     and routing redirects can provide  an  economical  mechanism
     for routing traffic.

     One opens the channel for passing routing  control  messages
     by  using  the  socket  call  shown in the SYNOPSIS  section
     above.  There can be more than one routing socket  open  per

     Messages are formed by a header followed by a  small  number
     of  sockaddrs,  whose  length depend on the address  family.
     sockaddrs are interpreted by position. An example of a  type
     of  message  with  three  addresses  might be a  CIDR prefix
     route: Destination, Netmask, and Gateway. 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 provides the
     process ID of the sender, and the sender may  use  an  addi-
     tional  sequence  field  to  distinguish between outstanding
     messages.  However, message replies may be lost when  kernel
     buffers are exhausted.

     The protocol parameter specifies which messages an  applica-
     tion  listening  on the routing socket is interested in see-
     ing, based on  the  the  address  family  of  the  sockaddrs
     present.   Currently,  you  can specify AF_INET and AF_INET6
     to filter the messages seen by  the  listener,  or  alterna-
     tively,  you  can  specify  AF_UNSPEC   to indicate that the
     listener is interested in all routing messages.

     The kernel may reject certain messages,  and  will  indicate
     this  by  filling  in  the  rtm_errno field of the rt_msghdr
     struct (see below). The following codes may be returned:

           If requested to duplicate an existing entry

     ESRCH If requested to delete a non-existent entry

           If insufficient resources were available to install  a
           new route.

     In the current implementation,  all  routing  processes  run
     locally,  and the values for rtm_errno are available through
     the normal errno mechanism, even if the routing  reply  mes-
     sage is lost.

     A process may avoid the expense of reading  replies  to  its
     own  messages by issuing a setsockopt(3SOCKET) call indicat-
     ing 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 doing a  shutdown(3SOCKET) system call
     for further input.

     If a route is in use when it is deleted, the  routing  entry
     is  marked  down and removed from the routing table, but the
     resources associated with it are  not  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.

     Messages include:

     #define RTM_ADD      0x1   /* Add Route */
     #define RTM_DELETE   0x2   /* Delete Route */
     #define RTM_CHANGE   0x3   /* Change Metrics, Flags, or Gateway */
     #define RTM_GET      0x4   /* Report Information */
     #define RTM_LOSING   0x5   /* Kernel Suspects Partitioning */
     #define RTM_REDIRECT 0x6   /* Told to use different route */
     #define RTM_MISS     0x7   /* Lookup failed on this address */
     #define RTM_LOCK     0x8   /* fix specified metrics */
     #define RTM_OLDADD   0x9   /* caused by SIOCADDRT */
     #define RTM_OLDDEL   0xa   /* caused by SIOCDELRT */
     #define RTM_RESOLVE  0xb   /* request to resolve dst to LL addr */
     #define RTM_NEWADDR  0xc   /* address being added to iface */
     #define RTM_DELADDR  0xd   /* address being removed from iface */
     #define RTM_IFINFO   0xe   /* iface going up/down etc. */

     A message header consists of:

     struct rt_msghdr {
       ushort_t rtm_msglen;    /* to skip over non-understood messages */
       uchar_t  rtm_version;   /* future binary compatibility */
       uchar_t  rtm_type;      /* message type */
       ushort_t rtm_index;     /* index for associated ifp */
       pid_t   rtm_pid;        /* identify sender */
       int     rtm_addrs;      /* bitmask identifying sockaddrs in msg */
       int     rtm_seq;        /* for sender to identify action */
       int     rtm_errno;      /* why failed */
       int     rtm_flags;      /*  flags,  incl  kern  &  message, e.g., DONE */
       int     rtm_use;        /* from rtentry */
       uint_t  rtm_inits;      /* which values we are initializing */

     struct  rt_metrics rtm_rmx;   /* metrics themselves */


     struct rt_metrics {
       uint32_t rmx_locks;      /* Kernel must leave  these  values alone */
       uint32_t rmx_mtu;        /* MTU for this path */
       uint32_t rmx_hopcount;   /* max hops expected */
       uint32_t rmx_expire;     /* lifetime for route, e.g., redirect */
       uint32_t rmx_recvpipe;   /* inbound delay-bandwidth  product */
       uint32_t rmx_sendpipe;   /* outbound delay-bandwidth product */
       uint32_t rmx_ssthresh;   /* outbound gateway buffer limit */
       uint32_t rmx_rtt;        /* estimated round trip time */
       uint32_t rmx_rttvar;     /* estimated rtt variance */
       uint32_t rmx_pksent;     /* packets sent using this route */

     /* Flags include the values */

     #define RTF_UP         0x1     /* route usable */
     #define RTF_GATEWAY    0x2     /* destination is a gateway */
     #define RTF_HOST       0x4     /* host entry (net otherwise) */
     #define RTF_REJECT     0x8     /* host or net unreachable */
     #define RTF_DYNAMIC    0x10    /* created dynamically(by redirect) */
     #define RTF_MODIFIED   0x20    /* modified dynamically(by redirect) */
     #define RTF_DONE       0x40    /* message confirmed */
     #define RTF_MASK       0x80    /* subnet mask present */
     #define RTF_CLONING    0x100   /* generate new routes on use */
     #define RTF_XRESOLVE   0x200   /* external daemon resolves name */
     #define RTF_LLINFO     0x400   /* generated by ARP */
     #define RTF_STATIC     0x800   /* manually added */
     #define RTF_BLACKHOLE  0x1000  /* just discard pkts (during updates) */
     #define RTF_PRIVATE    0x2000  /* do not advertise this route */
     #define RTF_PROTO2     0x4000  /* protocol specific routing flag #2 */
     #define RTF_PROTO1     0x8000  /* protocol specific routing flag #1 */

     /* Specifiers for metric values in rmx_locks and rtm_inits are */

     #define RTV_MTU        0x1     /* init or lock _mtu */
     #define RTV_HOPCOUNT   0x2     /* init or lock _hopcount */
     #define RTV_EXPIRE     0x4     /* init or lock _expire */
     #define RTV_RPIPE      0x8     /* init or lock _recvpipe */
     #define RTV_SPIPE      0x10    /* init or lock _sendpipe */
     #define RTV_SSTHRESH   0x20    /* init or lock _ssthresh */
     #define RTV_RTT        0x40    /* init or lock _rtt */
     #define RTV_RTTVAR     0x80    /* init or lock _rttvar */

     /* Specifiers for which addresses are present in  the  messages are */

     #define RTA_DST        0x1     /* destination sockaddr present */
     #define RTA_GATEWAY    0x2     /* gateway sockaddr present */
     #define RTA_NETMASK    0x4     /* netmask sockaddr present */
     #define RTA_GENMASK    0x8     /* cloning mask sockaddr present */
     #define RTA_IFP        0x10    /* interface name sockaddr present */
     #define RTA_IFA        0x20    /* interface addr sockaddr present */
     #define RTA_AUTHOR     0x40    /* sockaddr for author of redirect */
     #define RTA_BRD        0x80    /* for NEWADDR, broadcast or p-p dest addr */


     ioctl(2),      setsockopt(3SOCKET),       shutdown(3SOCKET),


     Some of the metrics may not be implemented and return  zero.
     The implemented metrics are set in rtm_inits.

Man(1) output converted with man2html