18.1 Introduction
Traditionally, the Unix routing table within the
kernel has been accessed using ioctl commands. In
Section 17.9, we
described the two commands that are provided, SIOCADDRT
and SIOCDELRT, to add or delete a route. We also mentioned
that no command exists to dump the entire routing table, and
instead programs such as netstat read the kernel memory to
obtain the contents of the routing table. One additional piece to
this hodgepodge is that routing daemons such as gated need
to monitor ICMP redirect messages that are received by the kernel,
and they often do this by creating a raw ICMP socket (Chapter 28) and
listening on this socket to all received ICMP messages.
4.3BSD Reno cleaned up the interface to the
kernel's routing subsystem by creating the AF_ROUTE
domain. The only type of socket supported in the route domain is a
raw socket. Three types of operations are supported on a routing
socket:
-
A process can
send a message to the kernel by writing to a routing socket. For
example, this is how routes are added and deleted.
-
A process can
read a message from the kernel on a routing socket. This is how the
kernel notifies a process that an ICMP redirect has been received
and processed, or how it requests a route resolution from an
external routing process.
Some operations involve both steps. For example,
the process sends a message to the kernel on a routing socket
asking for all the information on a given route, and the process
reads back the response from the kernel on the routing socket.
-
A process can
use the sysctl function (Section 18.4) to
either dump the routing table or list all configured
interfaces.
The first two operations require superuser
privileges on most systems, while the last operation can be
performed by any process.
Some newer releases have relaxed the superuser
requirement for opening a routing socket and instead restrict only
routing socket messages that change the table. This allows any
process to use, for instance, RTM_GET to look up a route
without being the superuser.
Technically, the third operation is not
performed using a routing socket but invokes the generic
sysctl function. We will see that one of the input
parameters is the address family, which is AF_ROUTE for
the operations we describe in this chapter, and the information
returned is in the same format as the information returned by the
kernel on a routing socket. Indeed, the sysctl processing
for the AF_ROUTE family is part of the routing socket code
in a 4.4BSD kernel (pp.632鈥?43 of TCPv2).
The sysctl utility appeared in 4.4BSD.
Unfortunately, not all implementations that support routing sockets
provide sysctl. For example, AIX 5.1 and Solaris 9 support
routing sockets, but neither supports sysctl.
|
