|
HP OpenVMS Systems Documentation |
|
HP TCP/IP Services for OpenVMS
|
| Previous | Contents | Index |
The following sample shows definition statements for a system:
options gendefault ;
autonomoussystem 249 ;
interface 128.66.12.2 passive ;
martians {
0.0.0.26
};
|
The following list describes each statement in the example:
Unicast routing protocols allow packets to be routed to one
destination. All routing protocols determine the "best" route
to each destination, and they distribute routing information among the
systems on a network. Routing protocols are divided into two general
groups: interior (or intradomain routing) protocols and exterior (or
interdomain routing) protocols. GATED software combines management of
the interior and exterior routing protocols in one software daemon.
A.12.1 Interior Routing Protocols
Interior protocols are used to exchange reachability information within an autonomous system (AS). They are referred to as a class by the acronym IGP. There are several interior 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:
The Router Discovery protocol is used to inform hosts of the
availability of other hosts to which it can send packets. Router
Discovery is used to supplement a statically configured default router.
This is the preferred protocol for hosts to run. They are discouraged
from wiretapping routing protocols. Router Discovery is described in
RFC 1256
A.12.4 ICMP
On systems without the BSD routing socket, GATED listens to ICMP
messages received by the system. Processing of ICMP redirect messages
is handled by the redirect statement.
A.12.5 Redirect
The redirect code process 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.
A.12.6 Kernel Interface
Although the kernel interface is not technically a routing protocol, it has many characteristics of one, and GATED handles it similarly. 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 that GATED must use to update the
typical kernel forwarding table take a non-trivial amount of time. The
time used 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.
A.12.7 Static Routes
Static statements define the static routes used by GATED. A single
static statement can specify any number of routes. The static
statements occur after protocol statements and before control
statements in the TCPIP$GATED.CONF file. Any number of static
statements may be specified, each containing any number of static route
definitions. These routes can be overridden by routes with better
preference values.
A.13 The ICMP Statement
On systems without the BSD routing socket, GATED listens to ICMP messages received by the system. GATED currently supports router discovery as well as redirect. Processing of ICMP redirect messages is handled by the redirect statement.
Use the ICMP statement to trace the ICMP messages that GATED receives.
The following ICMP statement specifies the tracing options for ICMP.
icmp {
traceoptions trace_options ;
}
traceoptions trace_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. |
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.
You cannot 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 mechanisms 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 or OSPF). It is not possible to enable redirects once they have been automatically disabled. Listening to RIP 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 is formatted as follows:
redirect yes | no | on | off
[ {
preference preference ;
interface interface_list
[ noredirects ] | [redirects ] ;
trustedgateways gateway_list ;
traceoptions trace_options ;
} ] ;
|
In the redirect statement:
There are no redirect-specific tracing options. All nonerror messages
are traced under the normal class.
A.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.
A.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, which indicates 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 sent 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.
The Router Discovery Server syntax is as follows:
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 ]
;
} ] ;
|
The Router Discovery Server syntax includes the following:
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:
| Previous | Next | Contents | Index |