Compaq TCP/IP Services for OpenVMS
Management


Previous Contents Index

A.15.2 The Router Discovery Client

A host listens for Router Advertisements via the all-hosts multicast address (224.0.0.2), If IP multicasting is available and enabled, or on the interface's broadcast address. When starting up, or when reconfigured, a host may send a few Router Solicitations to the all-routers multicast address, 224.0.0.2, or the interface's broadcast address.

When a Router Advertisement with non-zero lifetime is received, the host installs a default route to each of the advertised addresses. If the preference ineligible , or the address is not on an attached interface, the route is marked unusable but retained. If the preference is usable, the metric is set as a function of the preference such that the route with the best preference is used. If more than one address with the same preference is received, the one with the lowest IP address will be used. These default routes are not exportable to other protocols.

When a Router Advertisement with a zero lifetime is received, the host deletes all routes with next-hop addresses learned from that router. In addition, any routers learned from ICMP redirects pointing to these addresses will be deleted. The same will happen when a Router Advertisement is not received to refresh these routes before the lifetime expires.

The Router Discovery Client syntax is as follows:


 
routerdiscovery client yes | no | on | off [ { 
    traceoptions trace_options ; 
    preference preference ; 
    interface interface_list
        [ enable ] | [ disable ] 
        [ broadcast ] | [ multicast ] 
        [ quiet ] | [ solicit ] 
        ; 
} ] ; 

In the Router Discovery Client statement:

A.15.3 Tracing Options

The Router Discovery Client and Server support the state trace flag, which traces various protocol occurrences.

The Router Discovery Client and Server do not directly support any packet tracing options, tracing of router discovery packets is enabled with the ICMP statement.

A.16 The Kernel Statement

While the kernel interface is not technically a routing protocol, it has many of the characteristics of one, and GATED handles it similarly to one. The routes GATED chooses to install in the kernel forwarding table are those that will actually be used by the kernel to forward packets.

The add, delete and change operations GATED must use to update the typical kernel forwarding table take a non-trivial amount of time. This does not present a problem for older routing protocols (RIP, EGP), which are not particularly time critical and do not easily handle very large numbers of routes anyway. The newer routing protocols (OSPF, BGP) have stricter timing requirements and are often used to process many more routes. The speed of the kernel interface becomes critical when these protocols are used.

To prevent GATED from locking up for significant periods of time installing large numbers of routes (up to a minute or more has been observed on real networks), the processing of these routes is now done in batches. The size of these batches may be controlled by the tuning parameters described below, but normally the default parameters will provide the proper functionality.

During normal shutdown processing, GATED normally deletes all the routes it has installed in the kernel forwarding table, except for those marked with retain. Optionally, GATED can leave all routes in the kernel forwarding table by not deleting any routes. In this case changes will be made to insure that routes with a retain indication are installed in the table. This is useful on systems with large numbers of routes as it prevents the need to re-install the routes when GATED restarts. This can greatly reduce the time it takes to recover from a restart.

A.16.1 Forwarding Tables and Routing Tables

The table in the kernel that controls the forwarding of packets is a forwarding table, also known as a forwarding information base, or FIB. The table that GATED uses internally to store routing information it learns from routing protocols is a routing table, also known as a routing information base, or RIB. The routing table is used to collect and store routes from various protocols. For each unique combination of network and mask an active route is chosen, this route will be the one with the best (numerically smallest) preference. All the active routes are installed in the kernel forwarding table. The entries in this table are what the kernel actually uses to forward packets.

A.16.2 Updating the Forwarding Table

There are two main methods of updating the kernel FIB, the ioctl() interface and the routing socket interface. Their various characteristics are described here.

A.16.2.1 Updating the Forwarding Table with the ioctl Interface

The ioctl interface to the forwarding table was introduced in BSD 4.3. This is a one-way interface; it only allows GATED to update the kernel forwarding table. It has several other limitations:

A.16.2.2 Updating the Forwarding Table with the Routing Socket Interface

The routing socket interface to the kernel forwarding table was introduced in BSD 4.3 Reno, widely distributed in BSD 4.3 Net/2 and improved in BSD 4.4. This interface is simply a socket, similar to a UDP socket, on which the kernel and GATED exchange messages. It has several advatages over the ioctl() interface:

A.16.3 Reading the Forwarding Table

When GATED starts up it reads the kernel forwarding table and installs corresponding routes in the routing table. These routes are called remnants and are timed out after a configured interval (which defaults to 3 minutes), or as soon as a more attractive route is learned. This allows forwarding to occur during the time it takes the routing protocols to start learning routes.

There are three main methods for reading the forwarding table from the kernel:

A.16.4 Reading the Interface List

The kernel support subsystem of GATED is resposible for reading the status of the kernel's physical and protocl interfaces periodically. GATED detects changes in the interface list and notifies the protocols so they can start or stop instances or peers. The interface list is read one of two ways:

A.16.5 Reading Interface Physical Addresses

Later version of the getkerninfo() and sysctl() interfaces return the interface physical addresses as part of the interface information. On most systems where this information is not returned, GATED scans the kernel physical interface list for this information for interfaces with IFFBROADCAST set, assuming that their drivers are handled the same as Ethernet drivers. On some systems, system specific interfaces are used to learn this information.

The interface physical addresses are useful for IS-IS. For IP protocols, they are not currently used, but they may be used in the future.

A.16.6 Reading Kernel Variables

At startup, GATED reads some special variables out of the kernel. This is usually done with the nlist (or kvm_nlist ) system call, but some systems use different methods.

The variables read include the status of UDP checksum creation and generation, IP forwarding and kernel version (for informational purposes). On systems where the routing table is read directly from kernel memory, the root of the hash table or radix tree routing table is read. On systems where interface physical addresses are not supplied by other means, the root of the interface list is read.

A.16.7 Special Route Flags

The later BSD based kernel support the special route flags described in the following list:

A.16.8 Kernel Configuration Syntax

The kernel configuration syntax is as follows:


kernel { 
    options 
        [ nochange ] 
        [ noflushatexit ] 
        ; 
    routes number ; 
    flash 
        [ limit number ] 
        [ type interface | interior | all ] 
        ; 
    background 
        [ limit number ] 
        [ priority flash | higher | lower ] 
        ; 
    traceoptions trace_options ; 
} ; 
 

In the kernel configuration syntax:

A.16.9 Kernel Tracing Options

While the kernel interface is not technically a routing protocol, in many cases it is handled as one. You can enter the following two symbols from the command line because the code that uses them is executed before the trace file is parsed.
symbols Symbols read from the kernel, by nlist() or similar interface.
iflist Interface list scan. This option is useful when entered from the command line as the first interface list scan is performed before the configuration file is parsed.

The following tracing options can be specified only in the configuration file. They are not valid from the command line.
remnants Routes read from the kernel when GATED starts.
request Requests by GATED to Add/Delete/Change routes in the kernel forwarding table.

Use the following general option and packet-tracing options to systems that use the routing socket to exchange routing information with the kernel. They do not apply to systems that use the old BSD 4.3 ioctl() interface to the kernel.

Packet tracing options (which may be modified with detail , send , and recv ) specify the types of message and include:


Previous Next Contents Index