|
HP OpenVMS Systems Documentation |
|
HP TCP/IP Services for OpenVMS
|
| Previous | Contents | Index |
An interface list is a list of references to interfaces or groups of interfaces. The following four methods, from most general to most specific, are available for referring to interfaces:
| ALL | Refers to all available interfaces. |
| Interface name wildcard | Refers to all the interfaces of the same type. Interfaces consist of the device driver name and a unit number, for example, LE0. References to the name contain only alphabetic characters and match any interfaces that have the same alphabetic part. |
| Interface name | Refers to a specific interface, usually one physical interface. These are specified as an alphabetic part followed by a numeric part. This will match one specific interface. But be aware that on many systems, there can be more than one protocol (for example, IP) address on a given physical interface. For example, EF1 matches an interface named EF1, but not an interface named EF10. |
| Interface address | Matches one specific interface. The reference can be by protocol address (for example, 10.0.0.51) or by symbolic host name (for example, nic.ddn.mil ). Note that a symbolic host name reference is only valid when it resolves to only one address. Use of symbolic host names is not recommended. |
If many interface lists are present in the TCPIP$GATED.CONF file with more than one parameter, these parameters are collected at run time to create the specific parameter list for a given interface. If the same parameter is specified on more than one list, the parameters with the most specific interface are used.
For example, the following interface list is for a system with three interfaces, LE0, LE1, and DU0:
rip yes {
interface all noripin noripout ;
interface le ripin ;
interface le1 ripout ;
} ;
|
In this example, RIP packets are accepted from interfaces LE0 and LE1,
but nor from DU0. RIP packets are sent only on interface LE1.
A.10.1.1 Example of Current Define Statements for GATED
interfaces {
define 192.168.12.5 broadcast 192.168.12.255 netmask 255.255.255.0 ;
define 192.168.13.129 netmask 255.255.255.252 broadcast 192.168.13.131;
# pointtopoint - is local side, 1st address is remote
define 192.168.13.116 pointtopoint 192.168.13.114 multicast;
};
|
The BSD 4.3 and later networking implementations allow the following four types of interfaces. Some implementations allow multiple protocol addresses per physical interface, but these are mostly based on BSD 4.3 RENO or later.
| Loopback | This interface must have the address of 127.0.0.1. Packets sent to this interface are sent back to the originator. This interface is also used as an interface for implementing other features, such as reject and blackhole routes. Although a netmask is reported on this interface, it is ignored. It is useful to assign an additional address to this interface that is the same as the OSPF or BGP routerid ; this allows routing to a system based on the router ID that will work if some interfaces are down. |
| Broadcast | This is a multiaccess interface capable of a physical level broadcast, such as Ethernet, Token Ring, and FDDI. This interface has an associated subnet mask and broadcast address. The interface route to a broadcast network is a route to the complete subnet. |
| Point-to-point |
This is a tunnel to another host, usually on some sort of serial link.
This interface has a local address and a remote address.
The remote address must be unique among all the interface addresses on a given router. If a subnet mask is specified on a point-to-point interface, it is only used by RIP version 1 to determine which subnets may be propagated to the router on the other side of this interface. |
| Nonbroadcast multi-access (NBMA) | This type of interface is multiaccess, but not capable of broadcast, for example, frame relay and X.25. This type of interface has a local address and a subnet mask. (Not supported.) |
The GATED daemon ensures that there is a route available to each IP interface that is configured and up. Normally this is done by the SET INTERFACE command that configures the interface; GATED also does it to ensure consistency.
For point-to-point interfaces, GATED installs some special routes. GATED installs a route to the local address pointing at the loopback interface with a preference of 110. This ensures that packets originating on this host destined for this local address are handled locally.
OSPF prefers to route packets for the local interface across the point-to-point link where they will be returned by the router on the remote end. This is used to verify operation of the link. Because OSPF installs routes with a preference of 10, these routes override the route installed with a preference of 110.
When the status of an interface changes, GATED notifies all the protocols, which take the appropriate action. The GATED daemon assumes that interfaces that are not marked UP do not exist.
The GATED daemon ignores any interfaces that have invalid data for the
local, remote, or broadcast addresses or the subnet mask. Invalid data
includes zeros in any field. The GATED daemon also ignores any
point-to-point interface that has the same local and remote addresses;
it assumes it is in some sort of loopback test mode.
A.11 Definition Statements
Definition statements are general configuration statements that relate
to all of GATED, or at least to more than one protocol. The three
definition statements are
autonomoussystem
,
routerid
, and
martians
. If used,
autonomoussystem
,
routerid
, and
martians
, must appear before any other type of configuration statement in
TCPIP$GATED.CONF file.
A.11.1 Autonomous System Configuration
The statement autonomoussystem as_number [loops number]; sets the AS number of this router used by BGP EGP. The AS number is the official autonomous system number assigned to you by the Network Information Center (NIC).
The loops parameter is only for protocols supporting AS paths, such as
BGP. It controls the number of times this autonomous system may appear
in an AS path and defaults to 1 (one).
A.11.2 Router ID Configuration
The statement
routerid host;
sets the router identifier for use by the BGP and OSPF protocols. The
default is the address of the first interface encountered by GATED. The
address of a non-point-to-point interface is preferred over the local
address of a point-to-point interface, and an address on a loopback
interface that is not the loopback address (127.0.0.1) is most
preferred.
A.11.3 Martian Configuration
Sometimes a misconfigured system sends out invalid destination addresses. These invalid addresses, called martians, are rejected by the routing software. A martian configuration defines a list of martian addresses from which all routing information is ignored. A martian configuration is structured as follows:
martians {
host host [allow] ;
network [allow] ;
network mask mask [allow] ;
network masklen number [allow] ;
default [allow] ;
} ;
|
The martians martian_list statement adds martian addresses to a martian address list. Routing information will not be accepted from the addresses specified in this list.
You can specify the allow parameter to explicitly allow a subset of a
range that was disallowed.
A.11.4 Sample Definition Statements
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:
| Previous | Next | Contents | Index |