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 first define statement has an Ethernet where you need to define the broadcast address as a /24.
• The second define statement shows how a /30 may be implemented in the define statement. The define tells GATED to treat the interface with a local address of 192.168.13.129, a netmask of 255.255.255.252, and a broadcast address of 192.168.13.131.
• The third define statement shows how a point-to-point interface is defined. The remote side of the point-to-point interface is specified first, and the local side (the one on this machine) is specified second.

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:

• The options statement tells the system to generate a default route when it peers with an EGP or BGP neighbor.
• The autonomoussystem statement tells GATED to use AS number 249 for EGP and BGP.
• The interface statement tells GATED not to mark interface 128.66.12.2 as down even if it sees no traffic.
• The martians statement prevents routes to 0.0.0.26 from ever being accepted.

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:

• RIP
  The Routing Information Protocol, Version 1 and Version 2, is the most commonly used interior protocol. RIP selects the route with the lowest metric as the best route. The metric is a hop count representing the number of gateways through which data must pass to reach its destination. The longest path that RIP accepts is 15 hops. If the metric is greater than 15, a destination is considered unreachable and GATED discards the route. RIP assumes the best route is the one that uses the fewest gateways i.e., the shortest path, not taking into account congestion or delay on route.
  The RIP version 1 protocol is described in RFC 1058 and the RIP version 2 protocol is described in RFC 1723.
• OSPF
  Open Shortest Path First is a link-state protocol. OSPF is better suited than RIP for complex networks with many routers. OSPF provides equal cost multipath routing.
  OSPF is described in RFC 1583, the MIB is defined in RFC 1253. Other related documents are RFC 1245, RFC 1246 and RFC 1370.

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:

• EGP
  Exterior Gateway Protocol: Originally EGP reachability information was passed into ARPANET/MILNET "core" gateways where the best routes were chosen and passed back out to all connected autonomous systems. As the Internet moved toward a less hierarchical architecture, EGP, an exterior routing protocol which assumes a hierarchical structure, became less effective.
  The EGP protocol is described in RFC 827 and RFC 904.
• BGP
  Border Gateway Protocol is replacing EGP as the exterior protocol of choice. BGP exchanges reachability information between autonomous systems, but provides more capabilities than EGP. BGP uses path attributes to provide more information about each route as an aid in selecting the best route. Path attributes may include, for example, administrative preferences based on political, organizational, or security (policy) considerations in the routing decision. BGP supports nonhierarchical topologies and can be used to implement a network structure of equivalent autonomous systems.
  BGP version 1 is described in RFC 1105; version 2 in RFC 1163; version 3 in RFC 1267; and version 4 in RFC 1771. The version 3 MIB is described in RFC 1269. The three documents, RFC 1164, RFC 1268, and RFC 1772, describe the application of versions 2, 3, and 4 in the Internet. A protocol analysis of an experience with BGP version 3 is available in RFC 1265 and RFC 1266. RFC 1397 talks about advertising a default route in BGP version 2 and 3.
  BGP version 4 is described in RFC 1771. The BGP V4 MIB implemented by GATED is draft standard, but is scheduled to go to standard. Other references for BGP are: RFC 1997 (BGP Communities), RFC 1966 (BGP Route Reflection), RFC 1966 (BGP AS Confederations), and RFC 1403 (BGP--OSPF interaction). A useful application document is: RFC 1998 (An Application of the BGP Community Attribute in Multi-home Routing).

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 ;

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

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

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:

• preference sets the preference for a route learned from a redirect. The default is 30.
• interface is the interface statement, which allows the enabling and disabling of redirects on an interface-by-interface basis. See Section A.10.1 for the description of the interface_list. The parameters are:
  • noredirects ---Specifies that redirects received from the specified interface will be ignored. The default is to accept redirects on all interfaces.
  • redirects --- This is the default. This argument may be necessary when noredirects are used on a wildcard interface descriptor.
• trustedgateways defines the list of gateways from which redirects will be accepted. The gateway_list is a list of host names or addresses. By default, all routers on the shared network(s) are trusted to supply redirects. But if the trustedgateways clause is specified, only redirects from the gateways in the list are accepted.

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:

• traceoptions specifies the Router Discovery tracing options (see Section A.15.3).
• interface specifies the parameters that apply to physical interfaces. Note a slight difference in convention from the rest of GATED, interface specifies just physical interfaces (such as LE0, EF0 and EN1), while address specifies protocol (in this case IP) addresses.
  The interface parameters are:
  • maxadvinterval specifies the maximum time allowed between sending broadcast or multicast Router Advertisements from the interface. Must be no less than 4 and no more than 30:00 (30 minutes or 1800 seconds). The default is 10:00 (10 minutes or 600 seconds).
  • minadvinterval specifies the minimum time allowed between sending unsolicited broadcast or multicast Router Advertisements from the interface. Must be no less than 3 seconds and no greater than maxadvinterval. The default is 0.75 * maxadvinterval .
  • lifetime specifies the life time of addresses in a Router Advertisement. Must be no less than maxadvinterval and no greater than 2:30:00 (two hours, thirty minutes or 9000 seconds). The default is 3 * maxadvinterval .
• address specifies the parameters that apply to the specified set of addresses on this physical interfaces. Note a slight difference in convention from the rest of GATED, interface specifies just physical interfaces (such as LE0, EF0 and EN1), while address specifies protocol (in this case IP) addresses.
  The address parameters are:
  • advertise , which Specifies that the specified addresses should be included in Router Advertisements. This is the default.
  • ignore , which specifies that the specified addresses should not be included in Router Advertisements.
  • broadcast , which specifies that the given addresses should be included in a broadcast Router Advertisement because this system does not support IP multicasting, or some hosts on attached network do not support IP multicasting. It is possible to mix addresses on a physical interface such that some are included in a broadcast Router Advertisement and some are included in a multicast Router Advertisement. broadcast is the default if the router does not support IP multicasting.
  • multicast , which specifies that the given addresses should only be included in a multicast Router Advertisement. If the system does not support IP multicasting the addresses will not be included. If the system supports IP multicasting, the default is to include the addresses in a multicast Router Advertisement if the given interface supports IP multicasting, if not the addresses will be included in a broadcast Router Advertisement.
  • preference , which specifies the preferability of the addresses as a default router address, relative to other router addresses on the same subnet. A 32-bit, signed, twos-complement integer, with higher values meaning more preferable. Note that hex 80000000 may only be specified as ineligible. The default is 0.
  • ineligible , which specifies that the given addresses will be assigned a preference of (hex 80000000) which means that it is not eligible to be the default route for any hosts.
    This is useful when the addresses should not be used as a default route, but are given as the next hop in an ICMP redirect. This allows the hosts to verify that the given addresses are up and available.