DIGITAL TCP/IP Services for OpenVMS
Management
Previous Contents Index

B.12.2 Exterior Routing Protocols

Exterior protocols are used to exchange routing information between autonomous systems. Exterior protocols are only required when an autonomous system must exchange routing information with another autonomous system. Routers within an autonomous system run an interior routing protocol like RIP. Only those gateways that connect an autonomous system to another autonomous system need to run an exterior routing protocol. There are two exterior protocols currently supported by GATED:

B.12.3 Router Discovery Protocol

The Router Discovery protocol is used to inform hosts of the availability of hosts it can send packets to and is used to supplement a statically configured default router. This is the prefered protocol for hosts to run, they are discouraged from wiretapping routing protocols.

Router Discovery is described in RFC 1256.

B.13 The ICMP Statement

On systems without the BSD routing socket, GATED listens to ICMP messages received by the system. Currently GATED only does processing on ICMP redirect packets, but more functionality may be added in the future, such as support for the router discovery messages. Processing of ICMP redirect messages is handled by the redirect statement.

Currently the only reason to specify the icmp statement is to be able to trace the ICMP messages that GATED receives.

The ICMP statement 


 
icmp { 
    traceoptions trace_options ; 
} 
 
traceoptions trace_options ;

Specifies the tracing options for ICMP. (See Trace Statements and the ICMP specific tracing options below.)

B.13.1 Tracing Options

Packet tracing options (which may be modified with detail and recv):
packets All ICMP packets received.
redirect Only ICMP REDIRECT packets received.
routerdiscovery Only ICMP ROUTER DISCOVERY packets received.
info Only ICMP informational packets, which include mask request/response, info request/response, echo request/response and time stamp request/response.
error Only ICMP error packets, which include time exceeded, parameter problem, unreachable and source quench.

B.14 Redirect Processing

The redirect code is passed ICMP or ISO redirects learned by monitoring ICMP messages, or via the routing socket on systems that support it. It processes the redirect request and decides whether to accept the redirect. If the redirect is accepted, a route is installed in the GATED routing table with the protocol redirect. Redirects are deleted from the routing table after 3 minutes.

If GATED determines that a redirect is not acceptable, it tries to figure out if the kernel forwarding table has been modified. On systems where ICMP messages are monitored this is accomplished by trying to second guess what the kernel would have done with the redirect. On systems with the routing socket, the kernel provides and indication of whether the redirect was accepted; GATED ignores redirects that were not processed.

If GATED has determined that the state of the kernel forwarding table has been changed, the necessary requests to the kernel are made to restore the correct state.

Note that on currently available systems it is not possible to disable the processing of ICMP redirects, even when the system is functioning as a router. To ignore the effects of redirects, GATED must process each one and actively restore any changes it made to the kernel's state. Because of the mechanism's involved there will be windows where the effects of redirects are present in the kernel.

By default, GATED removes redirects when actively participating in an interior gateway protocol (RIP, HELLO, or OSPF). It is not possible to enable redirects once they have been automatically disabled. Listening to RIP or HELLO in nobroadcast mode does not cause redirects to be ignored, nor does the use of EGP and BGP. Redirects must be manually configured off in these cases.

Note that in accordance with the latest IETF Router Requirements document, GATED insures that all ICMP net redirects are processed as host redirects. When an ICMP net redirect is accepted, GATED issues the requests to the kernel to make sure that the kernel forwarding table is updated to reflect a host redirect instead of a net redirect.

The redirect statement does not prevent the system from sending redirects, only from listening to them.

The Redirect Statement 


 
redirect yes | no | on | off 
[ { 
    preference preference ; 
    interface interface_list 
        [ noredirects ] | [redirects ] ; 
    trustedgateways gateway_list ; 
    traceoptions trace_options ; 
} ] ;

Here,

B.15 The Router Discovery Protocol

The Router Discovery Protocol is an IETF standard protocol used to inform hosts of the existence of routers. It is intended to be used instead of having hosts wiretap routing protocols such as RIP. It is used in place of, or in addition to statically configured default routes in hosts.

The protocol is split into to portions, the server portion which runs on routers, and the client portion that runs on hosts. GATED treats these much like two separate protocols, only one of which may be enabled at a time.

B.15.1 The Router Discovery Server

The Router Discovery Server runs on routers and announces their existence to hosts. It does this by periodically multicasting or broadcasting a Router Advertisement to each interface on which it is enabled. These Router Advertisements contain a list of all the routers addresses on a given interface and their preference for use as a default router.

Initially these Router Advertisements occur every few seconds, then fall back to every few minutes. In addition, a host may send a Router Solicitation to which the router will respond with a unicast Router Advertisement (unless a multicast or broadcast advertisement is due momentarily).

Each Router Advertisement contains a Advertisement Lifetime field indicating for how long the advertised addresses are valid. This lifetime is configured such that another Router Advertisement will be sent before the lifetime has expired. A lifetime of zero is used to indicate that one or more addresses are no longer valid.

On systems supporting IP multicasting, the Router Advertisements are by default send to the all-hosts multicast address 224.0.0.1. However, the use of broadcast may be specified. When Router Advertisements are being sent to the all-hosts multicast address, or an interface is configured for the limited-broadcast address 255.255.255.255, all IP addresses configured on the physical interface are included in the Router Advertisement. When the Router advertisements are being sent to a net or subnet broadcast, only the address associated with that net or subnet is included.

Router Discovery Server Syntax 


routerdiscovery server yes | no | on | off [ { 
    traceoptions trace_options ; 
    interface interface_list
        [ minadvinterval time ] 
        [ maxadvinterval time ] 
        [ lifetime time ] 
        ; 
    address interface_list
        [ advertise ] | [ ignore ] 
        [ broadcast ] | [ multicast ] 
        [ ineligible ] | [ preference preference ] 
        ; 
} ] ;

Here,

B.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 


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

Here,

B.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 via the ICMP Statement.

B.16 The Kernel Statement

While the kernel interface isn't technically a routing protocol, it has many 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.

B.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.

B.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.

B.16.2.1 Updating the Forwarding Table with the ioctl Interface

The ioctl interface to the forwarding table was introduced in BSD 4.3 and widely distributed 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:

Previous Next Contents Index