The gated Command

The syntax of the gated command is:

gated [-v] [-c] [-C] [-n] [-N] [-t trace_options] [-f config_file] [trace_file]

The -c and -n command-line options debug the routing configuration file without impacting the network or the kernel routing table. Frequently, these debugging options are used with a test configuration identified by the -f config_file option:

-c: Tells gated to read the configuration file and check for syntax errors. When gated finishes reading the configuration file, it produces a snapshot of its status and then terminates. It writes the snapshot to /usr/tmp/gated_dump. Running gated with the -c option does not require superuser privileges, and it is not necessary to terminate the active gated process.
-C: Checks the configuration file for syntax errors. gated exits with a status 1 if there are errors and 0 if there are none. Because this provides exit status, it is useful for script files.
-n: Tells gated not to update the kernel routing table. This is used to test the routing configuration with real routing data without interfering with system operation.
-f config_file: Tells gated to read the configuration from config_file instead of from the default configuration file, /etc/gated.conf. Used in conjunction with the -c option, -f checks a new configuration without interfering with the currently running gated configuration.

The -v option causes gated to display its version number. When this is used, no other options are used because gated terminates immediately after displaying the version information.

The -N command-line option prevents gated from running in background mode as a daemon. This option is used when gated is started from inittab. By default, gated runs as a daemon.

The command-line arguments trace_options and trace_file are used for protocol tracing. The trace_file argument names the file to which the trace output is written. If a file is not specified, the trace is written to the standard output. Tracing usually produces a large amount of output.

The command-line options used for tracing are:

-t

This option turns on tracing. If -t is specified with no trace_options, gated defaults to general tracing, which traces normal protocol interactions and routing table changes. gated always logs protocol errors even if no tracing is specified. You can define several different trace_options, all of which are described later in this appendix. A few trace_options (detail, send, recv) cannot be specified on the gated command line. Two others are most useful when they are defined on the command line:

symbols: Traces the symbols read from the kernel, which is primarily of interest to developers debugging the interaction of gated and the kernel.
iflist: Traces the list of interfaces read from the kernel. Use this to determine what interfaces are detected by the kernel interface scan.

The advantage of placing a trace option on the command line is that it can trace activities that happen before the configuration file is processed. For the two options listed above, this is an essential advantage. For other options, it is not very important. Most trace options are specified in the configuration file. See the traceoptions command later in this appendix for more details.

Signal Processing

gated processes the following signals:

SIGHUP: Tells gated to reread the configuration file. The new configuration replaces the one that gated is currently running. SIGHUP loads the new configuration file without interrupting gated service. SIGHUP is available for quick configuration changes. At most sites, the routing configuration changes infrequently. The few times you need to change to a new configuration, terminate gated and rerun it with the new configuration. This is a more accurate test of how things will run at the next boot.
SIGINT: Tells gated to snapshot its current state to the file /usr/tmp/gated_dump.
SIGTERM: Tells gated to shut down gracefully. All protocols are shut down following the rules of that protocol. For example, EGP sends a CEASE message and waits for it to be confirmed. SIGTERM removes from the kernel routing table all routes learned via the exterior routing protocols. If you need to preserve those routes while gated is out of operation, use SIGKILL.
SIGKILL: Tells gated to terminate immediately and dump core. Routes are not removed from the routing table, and no graceful shutdown is attempted.
SIGUSR1: Tells gated to toggle tracing. If no trace flags are set, SIGUSR1 has no effect. But if tracing is enabled, the first SIGUSR1 causes gated to toggle off tracing and to close the trace file. The next SIGUSR1 turns tracing back on and opens the trace file. When the trace file is closed, it can be moved or removed without interfering with the operation of gated. Use this to periodically empty out the trace file to prevent it from becoming too large.
SIGUSR2: Tells gated to check for changes in the status of the network interfaces.

The following is an example of gated signal handling. First, the SIGUSR1 signal is passed to the gated process using the process ID obtained from the gated.pid file (/var/run/gated.pid in this case).

# kill -USR1 'cat /var/run/gated.pid'

Next, the old trace file (/usr/tmp/gated.log in this case) is removed, and gated is passed another SIGUSR1 signal.

# rm /usr/tmp/gated.log
# 
               kill -USR1 'cat /etc/gated.pid'

After receiving the second signal, gated opens a fresh trace file (still named /usr/tmp/gated.log). An ls shows that the new file has been created.

# ls -l /usr/tmp/gated.log
-rw-rw-r--  1 root          105 Jul  6 16:41 /usr/tmp/gated.log

The gated Configuration Language

The gated configuration language is a highly structured language similar to C in appearance. Comments either begin with a #, or they begin with /* and end with */. gated configuration statements end with a semicolon, and groups of associated statements are enclosed in curly braces. The language structure is familiar to most Unix system administrators, and the structure makes it easy to see what parts of the configuration are associated with each other. This is important when multiple protocols are configured in the same file.

The configuration language is composed of nine types of statements. Two statement types, directive statements and trace statements, can occur anywhere in the gated.conf file and do not directly relate to the configuration of any protocol. These statements provide instructions to the parser and control tracing from within the configuration file. The other seven statement types are options statements, interface statements, definition statements, protocol statements, static statements, control statements, and aggregate statements. These statements must appear in the configuration file in the correct order, starting with options statements and ending with aggregate statements. Entering a statement out of order causes an error when parsing the file.

The remainder of this appendix provides a description of all commands in the gated configuration language, organized by statement type.

Directive Statements

Directive statements provide direction to the gated command language parser about “include” files. An include file is an external file whose contents are parsed into the configuration as if it were part of the original gated.conf file. Include files can contain references to other include files, and these references can be nested up to 10 levels deep.

The two directive statements are:

%include filename: Identifies an include file. The contents of the file are “included” in the gated.conf file at the point in the gated.conf file where the %include directive is encountered. filename is any valid Unix filename. If filename is not fully qualified, i.e., does not begin with a /, it is considered to be relative to the directory defined in the %directory directive.
%directory pathname: Defines the directory where the include files are stored. When it is used, gated looks in the directory identified by pathname for any include file that does not have a fully qualified filename.

Unless you have a very complex routing configuration, avoid using include files. In a complex environment, segmenting a large configuration into smaller, more easily understood segments can be helpful, but most gated configurations are very small. One of the great advantages of gated is that it combines the configuration of several different routing protocols into a single file. If that file is small and easy to read, segmenting the file unnecessarily complicates things.

Trace Statements

Trace statements allow you to control the trace file and its contents from within the gated.conf file. The trace statement is:

traceoptions
 ["trace_file" [replace] [size bytes[k|m] files n]]
 [nostamp]
 trace_options [except trace_options] 
;

Its components are as follows:

trace_file

Identifies the file that receives the trace output. It has exactly the same function as the trace_file argument on the gated command line.

replace

Replaces the existing trace file. If you do not use this keyword, the trace output is appended to the current contents of the file.

size bytes [k|m] [files n ]

Limits the trace file to a maximum size of bytes. The optional k or m indicates thousands (k) or millions (m) of bytes. Thus 1000000 and 10m are equivalent entries. The size of the trace file cannot be less than 10k bytes. n defines the maximum number of trace files that should be saved. When the trace file reaches the maximum size, it is saved as trace_file.0, trace_file.1, trace_file.2 up to trace_file.n. The next save then overwrites trace_file.0. The value for n must be at least 2.

nostamp

Specifies that trace lines should not begin with a timestamp. Timestamping each line of trace data is the default.

trace_options

Defines the events to be traced by gated. Each trace option is specified by a keyword name. The available trace options are:

none: Turns off all tracing.
all: Turns on all types of global tracing.
general: Turns on both normal and route tracing.
state: Traces state machine transitions for protocols such as OSPF and BGP. The RFCs describe these protocols using finite state machine (FSM) diagrams or tables. The protocols transition from one state to another based on the occurrence of certain events. For example, the state might change from idle to connect when a connection open event occurs. This is a highly specialized trace flag, useful only to those who have a thorough understanding of the protocols involved. Use this option within the protocol statement to trace a specific protocol’s transitions.
normal: Traces normal protocol interactions. Errors are always traced.
policy: Traces the application of routing policies. Use this to check that you have properly configured your routing policy.
task: Traces system-level processing.
timer: Traces the various timers used by a protocol or peer.
route: Traces routing table changes. Use this to check that routes are properly installed by the protocol.
detail: Traces the contents of the packets exchanged by the router. Must be specified before send or recv.
send: Limits the detail trace to packets sent by this router.
recv: Limits the detail trace to packets received by this router. Without these two options, all packets are traced when detail is specified.
symbols: Traces the symbols read from the kernel at startup. See the -t command-line argument.
iflist: Traces the kernel interface list. See the -t command-line argument.
parse: Traces the lexical analyzer and parser.
adv: Traces the allocation and release of blocks.

except trace_options

Disables specific trace options. Must be used in conjunction with trace_options that enable a wide variety of tracing. For example, traceoptions all except state turns on all traces except for finite state machine tracing.

gated provides the flexibility for you to choose where you want to control tracing—on the command line or in the configuration file. By and large, the same trace options can be set on the gated command line or in the configuration file. detail, send, and recv can be set only in the configuration file.

Two others, symbols and iflist, are primarily used on the command line. Refer to the section on the gated command for a description of setting trace options with -t.

Some trace options are useful only for protocol developers and other experts. For most of us, general, which enables normal and route tracing, is an appropriate level of information for debugging routing problems. Occasionally, policy is useful for testing a routing policy. Most of the time, however, no tracing is needed.

Options Statements

Options statements define parameters that direct gated to do special internal processing. Options statements appear before any other configuration statements in the gated.conf file.

The options statement syntax is:

 options
 [nosend]
 [noresolv]
 [gendefault [preference preference] [gateway gateway]]
 [syslog [upto] log_level]
 [mark time]
 ;

An options statement can contain:

nosend: Instructs the system not to send any packets. This option tests gated without actually sending out routing information. Use for RIP and HELLO. It is not yet implemented for BGP and is not useful for OSPF.
noresolv: Instructs the system not to use the Domain Name System (DNS) to resolve hostnames and addresses. DNS failures can cause gated to deadlock during startup. Use this to prevent deadlock.
gendefault [preference preference ] [gateway gateway ]: Generates a default route, with a preference of 20, when gated peers with an EGP or BGP neighbor. If gateway is not defined, the gateway in the generated route is the system itself, the default route is not installed in the kernel table, and this option is used only to advertise this system as a default gateway. If gateway is specified, the default route is installed in the kernel table with the specified router as the next hop. This option can be overridden with the nogendefault option.
syslog [upto] log_level: Tells the system to use the setlogmask facility to control gated logging. See the setlogmask(3) manpage if this facility is available on your system.
mark time: Sends a periodic timestamp message to the trace file. time defines how frequently the timestamp should be issued. Use this to determine if gated is running.

Interface Statements

An interface statement defines configuration options for the network interfaces. The interface_list identifies the interfaces affected by the configuration options. The interfaces in the list are identified by interface name (e.g., le0), by hostname, by IP address, or by the keyword all. The keyword all refers to every interface on the system. The interface name can refer to a single interface or a group of interfaces. For example, an interface name of eth0 refers to the interface eth0, whereas the name le refers to all installed interfaces that start with the letters le (which might include le0, le1, and le2). A hostname can be used if it resolves to only one address.

Most system administrators prefer to use the IP address to identify an interface. After all, IP addresses are inherently a part of TCP/IP, and it’s TCP/IP routing that this file configures.

Additionally, remote systems know this interface by its IP address, not its interface name. Finally, DNS may provide more than one address for a hostname, and future Unix operating systems may allow more than one address per interface. IP addresses are safest.

gated supports four types of interfaces: loopback, broadcast, point-to-point, and nonbroadcast multiple access (NBMA). All of these are discussed in the text of this book except for NBMA. It is a multiple access interface, but the underlying network is not capable of broadcast. Examples are Frame Relay and X.25.

gated ignores any interface in the list that has an invalid local, remote, or broadcast address, or an invalid subnet mask. gated also ignores a point-to-point interface that has the same local and remote addresses. gated assumes that interfaces that are not marked UP by the kernel do not exist.

The syntax of the interfaces statement is:

interfaces {
   options
     [strictinterfaces]
     [scaninterval time] 
     [ aliases-nexthop ( primary | lowestip | keepall ) ];
   interface interface_list 
     [preference preference]
     [down preference preference]
     [passive]
     [simplex]
     [reject]
     [blackhole]
     [ AS autonomoussystem ];
   define address
     [broadcast address] | [pointopoint address]
     [netmask mask]
     [multicast] ;
 } ;

The configuration options defined before the interface list are global options. The global options are:

strictinterfaces: Generates a fatal error if an interface referenced in the configuration file is not found when gated scans the kernel at startup and is not listed in a define statement. (See the define option later in this section.) Normally a warning message is issued and gated continues running.
scaninterval time: Specifies how often gated scans the kernel interface list for changes. The default is every 15 seconds on most systems, and 60 seconds on systems that pass interface status changes through the routing socket, such as BSD 4.4. Note that gated also scans the interface list on receipt of a SIGUSR2.
aliases-nexthop ( primary | lowestip | keepall ): Defines the next-hop address that gated installs for interface routes. primary, which is the default, uses the primary interface address as the gateway for an interface route. lowestip uses the lowest IP address as the next-hop address. keepall retains all interface routes in the kernel.

The interface command defines the interface_list and all of the options that affect the specified interfaces. Options available on this statement are:

preference preference: Sets the preference for this interface. The value preference is a number between 0 and 255. gated prefers routes through interfaces with low preference numbers. The default preference for all directly attached network interfaces is 0.
down preference preference: Sets the preference used when gated believes an interface is not functioning properly. The default is 120.
passive: Prevents gated from downgrading the preference of the interface when it is not functioning properly. gated assumes that an interface is down when it stops receiving routing information through that interface. gated performs this check only if the interface is actively participating in a routing protocol.
simplex: Specifies that gated should not use packets generated by this system as an indication that the interface is functioning properly. Only packets from remote systems are used to indicate that the interface is operating.
reject | blackhole: Either of these keywords identifies the interface as the “blackhole interface” used to install rejected routes in the kernel. (See the control statements for more about rejected routes.) This is available only on BSD systems that have installed a reject/blackhole pseudo-interface.
AS autonomoussystem: Identifies the autonomous system number that gated should use when creating an AS path vector for this route. You should recall that some routing protocols, such as BGP, associate an AS path with a route.

The define address command lists interfaces that might not be present when gated scans the kernel interface list at startup. It overrides the strictinterfaces option for the interface defined by address. Possible options for the define command are:

broadcast address: Defines the broadcast address.
pointopoint address: Defines the local address for a point-to-point interface. (See Chapter 6 for a discussion of point-to-point interfaces.) When this option is used, the address on the define statement specifies the address of the remote host, and the address specified after the pointopoint keyword defines the local address. Don’t use both broadcast and pointopoint in the same define.
netmask mask: Defines the subnet mask.
multicast: Specifies that the interface supports multicasting.

Definition Statements

Definition statements are general configuration statements that relate to more than one protocol. Definition statements must appear before any protocol statements in gated.conf. The three definition statements are:

autonomoussystem asn [loops n ] ;: Defines the autonomous system number (asn) used by BGP or EGP. The loops number defines the number of times this autonomous system may appear in an AS path for path vector protocols, such as BGP. The default value for n is 1.
routerid address ;: Defines the router identifier used by BGP and OSPF. Use the address of your primary OSPF or BGP interface. By default, gated uses the address of the first interface it encounters.
martians {host address [allow]; address [mask mask | masklen number ] [allow] ; default [allow] ; } ;: Changes the list of addresses about which all routing information is ignored. Sometimes a misconfigured system sends out obviously invalid destination addresses. These invalid addresses, called martians, are rejected by the routing software. This command allows changes to the list of martian addresses. A martian address can be specified as a host address by using the host keyword before the address, or as a network address by simply specifying the address.

An address mask can be defined for a network address. The mask can be defined in dotted decimal notation using the mask keyword or as a numeric prefix length using the masklen keyword. The address masks mask 255.255.0.0 and masklen 16 are equivalent. If no address mask is specified, the natural mask is used. Specifying an address in the martians statement adds the address to the martians list. The allow keyword is used to remove an address from the martians list. When an address is removed from the martians list, it then becomes a valid address for routing.

gated contains a standard martian list of addresses that are known to be invalid. This is the default martian list. The option default allow removes all of the standard entries from the martians list and permits unrestricted routing. Don’t do this if you’re on a connected network.

Here is a sample of each definition statement:

autonomoussystem 249 ; 
routerid 172.16.12.2 ; 
martians { 
        host 0.0.0.26 ; 
        192.168.0.0 masklen 16 allow ; } ;

The statements in the sample perform the following functions:

The autonomoussystem statement tells gated to use AS number 249 for its BGP or EGP packets.
The routerid statement tells gated to use 172.16.12.2 as the router identifier for OSPF and BGP.
The martians statement prevents routes to 0.0.0.26 from being included in the table, but it allows routes to the private IP addresses in the range 192.168.0.0 to 192.168.255.255.

Protocol Statements

Protocol statements enable or disable protocols and set protocol options. The protocol statements occur after the definition statements and before the static statements. There are many protocol statements, and more may be added at any time. There are statements for the various interior and exterior routing protocols and for other things that are not really routing protocols.

In this section we begin with the interior protocols, move on to the exterior protocols, and finish with the special “protocols.”

The ospf Statement

ospf yes | no | on | off  [{
  defaults {
    preference preference ;
    cost cost ;
    tag [as] tag ;
    type 1 | 2 ;
    inherit-metric; } ;
  exportlimit routes ;
  exportinterval time ;
  traceoptions trace_options ; 
  syslog [first count] [every count];
  monitorauthkey key ;
  backbone | area number {
    authtype 0 | 1 | none | simple ;
    stub [cost cost]  ;
    networks {
     address [mask mask | masklen number] [restrict]  ;
     host address [restrict]  ; } ;
    stubhosts { 
     address cost cost ; } ;
    interface interface_list [nonbroadcast] [cost cost]  {
     pollinterval time ;
     routers {
     address [eligible]  ; } ;
     interface_parameters } ;
    virtuallink neighborid router_id transitarea area {
     interface_parameters } ;
 } ; } ] ;

The ospf statement enables or disables the Open Shortest Path First (OSPF) routing protocol. By default, OSPF is disabled. It is enabled by specifying yes or on (it doesn’t matter which you use) and it is disabled with no or off.

Warning

For the sake of brevity, this text explains only the first occurrence of any gated.conf parameter if it is used the same way in subsequent commands. Only differences between commands are explained. For example, yes | no | on | off is not explained again because it is always used in the same way to enable or disable a protocol.

The ospf statement has many configuration parameters:

defaults

Defines the defaults used when importing OSPF routes from an external autonomous system and announcing those routes to other OSPF routers. The link-state advertisement (LSA) used to announce these routes is called an ASE (autonomous system external) because it contains routes from external autonomous systems. See the description of OSPF in Chapter 7.

preference preference: Defines the preference of OSPF ASE routes. The default is 150.
cost cost: Defines the cost used when advertising a non-OSPF route in an ASE. The default is 1.
tag [as] tag: Defines the OSPF ASE tag value. The tag is not used by the OSPF protocol but may be used by an export policy to filter routes. (See the export statement later in this appendix.) When the as keyword is specified, the tag field may contain AS path information.
type 1 | 2: Defines the type of ASE used. The default is type 1. Type 1 contains routes learned from an external protocol that provides a metric directly comparable to the OSPF metric. The metric is added to the cost of reaching the border router when routes are advertised. A type 2 ASE contains routes learned from an exterior gateway protocol that does not provide a routing metric comparable to the OSPF metric. These routes are advertised with the cost of reaching the border router. See Chapter 7.
inherit-metric: Directs gated to use the external metric for ASE routes if no metric is defined in the export statement.

exportlimit routes

Defines the maximum number of ASE LSAs that will be flooded at one time. The default is 100.

exportinterval time

Defines how frequently ASE link-state advertisements are flooded to the network. The default is once per second.

traceoptions trace_options

Defines the tracing used to debug OSPF. In addition to the standard trace flags, OSPF supports:

lsabuild: Traces construction of link-state advertisements (LSAs).
spf: Traces the Shortest Path First (SPF) calculations.
hello: Traces the OSPF HELLO packets.
dd: Traces the OSPF Database Description packets.
request: Traces the OSPF Link-State Request packets.
lsu: Traces the OSPF Link-State Update packets.
ack: Traces the OSPF Link-State Ack packets.

syslog [first number ] [every count ]

Defines packet capture parameters. first specifies the number of packets captured for each type of OSPF packet. every specifies how often packets are captured after the initial group is captured. For example, if count is set to 50, every fiftieth packet of each type is captured.

monitorauthkey password

Defines the password used for ospf_monitor queries. By default these queries are not authenticated. If monitorauthkey is specified, incoming queries must contain the specified password.

backbone | area number

Defines the OSPF area of which this router is a member. Every router must belong to an area. If more than one area is configured, at least one must be the backbone. The backbone is defined using the backbone keyword. All other areas are defined by the area keyword and the number of the area, e.g., area 1. See Chapter 7 for a discussion of OSPF areas. Several configuration parameters are associated with each area:

stub [cost cost ]: Specifies that this is a stub area. A stub area is one in which there are no ASE routes. If a cost is specified, it is used to advertise a default route into the stub area.
networks: Defines the range of networks contained within this area. The specified ranges are advertised into other areas as summary network LSAs and not as inter-area routes. If restrict is specified, the summary network LSAs are not advertised. The entries in the networks list are either specified as a host address by using the host keyword before the address, or as a network address by simply specifying the address. An address mask can be defined for a network address. The mask can be defined in dotted decimal notation using the mask keyword or as a numeric prefix length using the masklen keyword. The address masks mask 255.255.0.0 and masklen 16 are equivalent. If no address mask is specified, the natural mask is used. This option can reduce the amount of routing information propagated between areas.

stubhosts

Lists the directly attached hosts, and their costs, that should be advertised as reachable from this router. List point-to-point interfaces here.

interface interface_list [nobroadcast] [cost cost ]

Defines the interfaces used by OSPF. If the keyword nobroadcast is specified, the interface connects to a nonbroadcast multiple access (NBMA) network. If nobroadcast is not used, the interface connects to a broadcast or a point-to-point network. Specify the cost of the interface with the cost keyword, e.g., cost 5. The default cost is 1. Two options are specific to NBMA interfaces:

pollinterval time: Defines the time interval at which OSPF HELLO packets are sent to neighbors.
routers: Lists all neighbors by address. The eligible keyword indicates if the neighbor can become a designated router.

All interfaces—NBMA and broadcast—can use these parameters:

enable | disable ;: Enables or disables the interface.
retransmitinterval time ;: Defines the number of seconds between link-state advertisement retransmissions.
transitdelay time ;: Defines the estimated number of seconds required to transmit a link-state update over this interface. It must be greater than 0.
priority priority ;: Defines this system’s priority for the designated router election. priority is a number from 0 to 255. The router with the highest priority becomes the designated router. A router whose priority is 0 is ineligible to become the designated router. See Chapter 7 for a discussion of designated routers.
hellointerval time ;: Defines the number of seconds between transmissions of HELLO packets.
routerdeadinterval time ;: Defines the timeout before a neighbor is declared down. time is the maximum number of seconds this router will wait for a neighbor’s HELLO packet.
auth [ none | simple password | md5 key ] ;: Defines the type of authentication used to authenticate OSPF packets. none selects no authentication. simple selects password authentication. The password is specified as one to eight decimal digits separated by periods, a one- to eight-byte hexadecimal string preceded by 0x, or a one- to eight-character string in double quotes. md5 selects MD5 authentication. key is a valid MD5 cryptographic key.

virtuallink neighborid router_id transitarea area

Defines a virtual link for the backbone area. The router_id is the router identifier of the remote router at the other end of the virtual link. The transit area must be one of the other areas configured on this system. All standard interface parameters defined above may be specified on a virtual link.

The rip Statement

rip yes | no | on | off [ {
   broadcast ;
   nobroadcast ;
   nocheckzero ;
   preference preference ;
   defaultmetric metric ;
   query authentication [none | [simple | md5 password]]  ;
   interface interface_list
     [noripin] | [ripin]
     [noripout] | [ripout]
     [metricin metric]
     [metricout metric]
     [version 1 | 2 [multicast | broadcast]]
     [[secondary] authentication [none | [simple | md5 password]] ;
   trustedgateways gateway_list ;
   sourcegateways gateway_list ;
   traceoptions trace_options ; } ] ;

The rip statement enables or disables RIP. By default RIP is enabled. The rip statement options are:

broadcast

Forces gated to broadcast RIP update packets even if the system has only one network interface. By default, RIP updates are not broadcast if the system has only one network interface and are broadcast if it has more than one network interface; i.e., hosts do not broadcast updates and routers do.

nobroadcast

Forces gated to not broadcast RIP update packets even if the system has more than one network interface. If a sourcegateways clause is present, routes are still unicast directly to that gateway. See sourcegateways later in this section.

notcheckzero

Specifies that gated should not reject incoming version 1 RIP packets where the reserved fields are 0. Rejecting those packets is standard practice.

preference preference ;

Sets the gated preference for routes learned from RIP. The default preference for these routes is 100.

defaultmetric metric ;

Defines the metric used when advertising routes via RIP that were learned from other protocols. The default metric is 16, which to RIP indicates an unusable route. This means that by default, routes learned from other protocols are not advertised as valid routes by RIP. Set a lower value only if you want all routes learned from other protocols advertised at that metric.

query authentication [none | [simple | md5 key ]] ;

Specifies the authentication used for nonrouter query packets. The default is none. If simple is specified, the key is a 16-byte password. If md5 is specified, the key is a 16-byte value used with the packet contents to generate a Message Digest 5 cryptographic checksum.

interface interface_list

Identifies the interfaces over which RIP runs and defines the configuration parameters of those interfaces. The interface_list can contain interface names, hostnames, IP addresses, or the keyword all. Possible parameters are:

noripin: Tells system to ignore RIP packets received on this interface. The default is to listen to RIP packets on all nonloopback interfaces.
ripin: Tells system to listen to RIP packets received on this interface. This is the default.
noripout: Tells system not to send RIP packets out this interface. The default is to send RIP on all broadcast and nonbroadcast interfaces when in broadcast mode. See the nobroadcast option defined earlier in this list.
ripout: Tells system to send RIP packets out this interface. This is the default.
metricin metric: Specifies the RIP metric used for routes received on this interface. The default is the kernel interface metric plus 1, which is the default RIP hop count. If this metric is specified, it is used as the absolute value and is not added to the kernel metric.
metricout: Specifies the RIP metric added to routes sent out this interface. The default is 0. This option can only increase the metric.
version 1 | 2 [multicast | broadcast]: Identifies the version of RIP used for updates sent out this interface. Available versions are RIP 1 and RIP 2. RIP 1 is the default. If RIP 2 is specified and IP multicast is supported, full version 2 packets are sent via multicast. If multicast is not available, version 1-compatible version 2 packets are sent via broadcast. The keyword multicast, the default, specifies this behavior. The keyword broadcast specifies that RIP version 1-compatible version 2 packets should be broadcast on this interface, even if IP multicast is available. Neither keyword is used with version 1.
[secondary] authentication [none | simple | md5 key ]: Defines the RIP version 2 authentication used on this interface. The default authentication type is none. If simple is specified, the key is a 16-byte password. If md5 is specified, the key is a 16-byte value used with the packet contents to generate a Message Digest 5 cryptographic checksum. If secondary is specified, this defines the secondary authentication type. Packets are always sent using the primary authentication technique. The secondary authentication type is defined only for incoming packets. Inbound packets are checked against both the primary and secondary authentication methods before being discarded as invalid.

trustedgateways gateway_list ;

Defines the list of gateways from which RIP accepts updates. The gateway_list is simply a list of hostnames or IP addresses. By default, all gateways on the shared network are trusted to supply routing information. But if the trustedgateways statement is used, only updates from the gateways in the list are accepted.

sourcegateways gateway_list ;

Defines a list of gateways to which RIP sends packets directly. By default, RIP packets are broadcast or multicast to several systems on the shared network, but if this statement is used, RIP unicasts packets directly to the listed gateways.

traceoptions trace_options

Defines tracing for RIP. RIP supports most of the standard tracing options as well as these packet-tracing options:

packets: Traces all RIP packets.
request: Traces the RIP information request packets, such as REQUEST, POLL, and POLLENTRY.
response: Traces all RIP RESPONSE packets.
other: Traces any other type of RIP packet.

The isis Statement

isis on | off {
     [ area areaid ; ]
     [ area auth simple key ; ]
     [ domain auth simple key ; ]
     [ domain-wide on | off ; ]
     [ export-defaults ; ]
     [ export-defaults level 1 | 2 ; ]
     [ export-defaults metric metric | inherit ; ]
     [ export-defaults metric-type internal | external ; ] 
     [ external preference preference ; ] 
     [ level 1 | 2 | 1 and 2 ; ]
     [ interface name | address [ {
         [ enable | disable ; ]
         [ auth simple key ; ]
         [ csn-interval interval [ level 1 | 2 | 1 and 2 ] ; ]
         [ dis-hello-interval interval [ level 1 | 2 | 1 and 2 ] ; ]
         [ encap [ iso | ip ] ; ]
         [ hello-interval interval [ level 1 | 2 | 1 and 2 ] ; ]
         [ hello-multiplier number [ level 1 | 2 | 1 and 2 ] ; ]
         [ lsp-interval interval ; ] 
         [ level 1 | 2 | 1 and 2 ; ]
         [ max-burst number ; ]
         [ metric metric [ level 1 | 2 | 1 and 2 ] ; ]
         [ passive on | off ; ]
         [ priority priority [ level 1 | 2 | 1 and 2 ] ; ]
         [ retransmit-interval interval ; ]
     } ] ; ]
     [ overload-bit on | off ; ]
     [ preference preference ; ]
     [ psn-interval intervalt ; ]
     [ require-snp-auth on | off ; ] 
     [ ribs unicast | unicast multicast ; ]
     [ spf-interval interval ; ] 
     [ inet6 on | off ; ]
     [ summary-originate [ inet | inet6 ] {
         [network (mask mask | masklen n ) metric cost-value ; ]
     } ; ]
     [ summary-filter [ inet | inet6 ] {
         [network mask mask | masklen number ; ]
     } ; ]
     [ systemid systemid ; ]
     [ traceoptions traceoptions ; ] 
     [ config-time seconds ; ]
     [ es-config-time seconds ; ]
     [ hold-time seconds ; ]
};

The isis statement enables the IS-IS protocol. By default, it is disabled. The options that may appear in the isis statement are:

area areaid

Adds area addresses to those configured automatically from the circuits. IS-IS area addresses are automatically configured based on the real circuits over which IS-IS runs. Up to three areas can be added using area statements.

area auth simple key

Enables authentication for level 1 routing and selects the key. The format for key is one to eight decimal digits separated by periods, a one- to eight-byte hexadecimal string preceded by 0x, or a one- to eight-character string in double quotes. The same key format is used throughout the isis statement.

domain auth simple key

Enables authentication and selects the key for level 2 routing.

export-defaults level 1 | 2

Sets the protocol level used for exported routes. By default, a level 1 router exports at level 1, and a level 2 router supports both level 1 and 2.

export-defaults metric metric | inherit

Defines the default metric used on routes exported as IS-IS from another protocol. The default is to use the metric already contained in the route, which is indicated by the inherit keyword.

export-defaults metric-type internal | external

Defines the type of the metric used on routes exported as IS-IS from another protocol. The default is internal.

external preference preference

Defines the preference of external routes learned from IS-IS. The default preference is 151.

level 1 | 2 | 1 and 2

Sets the protocol level for this intermediate system. A level 1 system is an intra-area router. A level 1 system cannot have any level 2 interfaces. A level 2 system is an inter-area router, and it cannot have any level 1 interfaces. A level 1 and 2 system may have level 1, level 2, and level 1 and 2 interfaces. Additionally, individual options relating to protocol settings can be specified as level 1, level 2 or level 1 and 2 depending on the specific level for which the option is being set when the system supports level 1 and 2. The default is level 1 and 2.

interface name | address

Identifies the interfaces on which to run IS-IS. The default is all. The following options can be set for each interface:

enable | disable: enable or disable the interface. The default is enable.
auth simple key: Enables authentication and selects the authentication key for this interface.
csn-interval interval [ level 1 | 2 | 1 and 2 ]: Sets the interval at which this system will multicast CSN packets if it is elected the Designated Intermediate System (DIS). The interval can be from 1 to 100 seconds.
dis-hello-interval interval [level 1 | 2 | 1 and 2]: Sets the interval at which this system will send hello messages if it is elected the DIS. The interval can be from 1 to 100 seconds.
encap [ ip | iso ]: Selects the type of encapsulation used. The default is ip.
hello-interval interval [ level 1 | 2 | 1 and 2 ]: Defines the interval at which hello packets are sent on the interface. interval can be from 1 to 300 seconds.
hello-multiplier number [ level 1 | 2 | 1 and 2 ]: Defines the number of hello packets that must be missed before a neighbor is considered “down.” Thus if number is set to 3 and no hello packets are received from a neighbor in the amount of time in which three hello packets are normally received, the neighbor is considered down. number can be from 1 to 100.
lsp-interval interval: Defines the interval at which LSP packets are sent on the interface.
level 1 | 2 | 1 and 2 ;: Defines the protocol level used on this interface.
max-burst number: Defines the maximum number of packets that can be sent in a burst.
metric metric [ level 1 | 2 | 1 and 2 ]: Defines the cost associated with this interface.
passive on | off: Indicates whether this interface should be treated as an active or passive interface.
priority priority [ level 1 | 2 | 1 and 2 ]: Sets the priority number used for the DIS election. priority is a value from 1 to 127.
retransmit-interval interval: Defines the interval at which packets are retransmitted on the interface.

overload-bit on | off

Enables or disables use of the overload bit.

preference preference

Sets the gated preference for IS-IS routes. The default is 11.

psn-interval interval

Defines how often PSN packets are sent by this system. interval can be 1 to 20 seconds.

ribs unicast | unicast multicast

Defines the routing information base format used for IS-IS routes. The default is unicast.

spf-interval interval

Defines the amount of time to wait for more changes to occur before recalculating the routing table. interval can be from 1 to 60 seconds.

inet6 on | off

Enables support for IPv6 routing.

summary-originate

Defines how level 1 routes are summarized in this system’s routing information base for level 2 routing. summary-originate is used only if this system is a level 2 router. network identifies the level 1 address received, and the network mask, defined as either a mask or a numeric mask length, aggregates the routes.

summary-filter

Defines how level 1 routes are summarized when this system advertises them through level 2 routing. summary-filter is used only if this system is a level 2 router.

systemid systemid

Defines the IS-IS system ID. If no system identifier is specified, the system ID portion of the first circuit’s NSAP address is used.

traceoptions traceoptions

Defines the trace options used for IS-IS. The default is none.

The bgp Statement

bgp yes | no | on | off [{
    preference preference ;
    defaultmetric metric ;
    traceoptions trace_options ;
    group type external peeras as_number
       | internal peeras as_number
       | igp peeras as_number proto proto
       | routing peeras as_number proto proto interface interface_list
      | test peeras as_number {
      allow {
         address mask mask | masklen number
         all
         host address } ;
      peer address
        [metricout metric]
        [localas as_number]
        [nogendefault]
        [gateway address]
        [preference preference]
        [preference2 preference]
        [lcladdr address]
        [holdtime time]
        [version number]
        [passive]
        [sendbuffer number]
        [recvbuffer number]
        [indelay time]
        [outdelay time]
        [keep all | none]
        [showwarnings]
        [noaggregatorid]
        [keepalivesalways]
        [v3asloopokay]
        [nov4asloop]
        [logupdown]
        [ttl ttl]
        [traceoptions trace_options]  ; }
 ; }] ;

This statement enables or disables BGP. By default, BGP is disabled. The default preference is 170. By default, BGP does not advertise a metric. Unlike the RIP metric, the BGP metric does not play a primary role in determining the best route. The BGP metric is simply an arbitrary 16-bit value that can be used as one criterion for choosing a route. The defaultmetric statement can be used to define a metric that BGP will use when advertising routes.

Trace options can be specified for all of BGP or for individual BGP peers. BGP supports most of the standard trace options as well as the following:

packets: Traces all BGP packets. Traces BGP OPEN packets. Traces BGP UPDATE packets. Traces BGP KEEPALIVE packets.

BGP peers must be members of a group. The group statement declares the group, defines which peers are members of the group, and defines the group “type.” Multiple group statements may be specified, but each must have a unique combination of type and autonomous system number. There are five possible group types:

group type external peeras as_number: Specifies that BGP will run as a classic exterior gateway protocol. The peers listed in this group are members of an external autonomous system. Full policy checking is applied to all incoming and outgoing routes.
group type internal peeras as_number: Specifies that BGP will be used to distribute routes to an internal group that has no traditional interior gateway protocol. Routes received from external BGP peers are re-advertised to this group with the received metric.
group type igp peeras as_number proto proto: Specifies that BGP will be used to distribute path attributes to an internal group that runs an interior gateway protocol. BGP advertises the AS path, path origin, and transitive optional attributes if the path attributes are provided by the IGP’s tag mechanism. proto is the name of the interior gateway protocol, e.g., proto ospf.
group type routing peeras as_number proto proto interface interface_list: Specifies that BGP will be used internally to carry external routes, while an interior gateway protocol is used to carry only internal routes. Normally the routes learned by BGP from external autonomous systems are written in the routing table where they are picked up and distributed by an interior protocol to the local autonomous system. For this type of group, BGP distributes the external routes itself, and the interior protocol is limited to distributing only those routes that are interior to the local autonomous system. proto is the name of the interior protocol.
group type test peeras as_number: Specifies that the members of this group are test peers. All routing information exchanged by test peers is discarded.

A group clause contains peer subclauses. Any number of peer subclauses may belong to a group. Peers are specified explicitly with a peer statement, or implicitly with the allow statement.

allow: Any peer whose address is contained in the specified address range is a member of the group. The keyword all matches all possible addresses. The keyword host precedes an individual host address. The address and mask pairs define a range of addresses. Network masks can be defined with the keyword mask and an address mask written in dotted decimal notation, or with the keyword masklen and the prefix length written as a decimal number. All parameters for these peers must be defined in the group clause.
peer address: The peer identified by address is a member of the group.

The BGP peer subclause allows the following parameters, which can also be specified on the group clause. If placed on the group clause, the parameters affect all peers in the group. The available options are:

metricout metric: Defines the primary metric for routes sent to the peer. This overrides the default metric, a metric specified on the group, and any metric specified by export policy.
localas as_number: Defines the local system’s autonomous system number (asn). The default is to use the asn defined in the autonomoussystem statement.
nogendefault: Prevents gated from generating a default route when BGP peers with this neighbor, even if gendefault is set in the options directive statement.
gateway address: Identifies the next-hop gateway through which packets for this peer are routed. Use this only if the neighbor does not share a network with the local system. This option is rarely needed.
preference preference: Defines the preference used for routes learned from this peer, which permits gated to prefer routes from one peer, or group of peers, over another.
preference2 preference: Defines the “second” preference. In the case of a preference tie, the second preference is used to break the tie. The default value is 0.
lcladdr address: Defines the address of the local interface used to communicate with this neighbor.
holdtime time: Defines the number of seconds the peer should wait for a keepalive, update, or notification message before closing the connection. The value is sent to the peer in the Hold Time field of the BGP Open message. The value must be either 0 (no keepalives will be sent) or at least 3.
version version: Identifies the version of the BGP protocol to use with this peer. By default, the version is negotiated when the connection is opened. Currently supported versions are 2, 3, and 4.
passive: Specifies that gated should wait for the peer to issue an OPEN. By default, gated periodically sends OPEN messages until the peer responds.
sendbuffer buffer_size recvbuffer buffer_size: Defines the size of the send and receive buffers. The default is 65535 bytes, which is the maximum. These parameters are not used on normally functioning systems.
indelay time outdelay time: Implements “route dampening.” indelay defines the number of seconds a route must be stable before it is accepted. outdelay is the number of seconds a route must be present in the gated routing database before it is exported to this peer. The default value for each is 0, meaning that these features are disabled. Use this only if the routing table is fluctuating so rapidly it is unstable.
keep all: Tells the system to retain routes learned from this peer even if the routes’ AS paths contain our local AS number. Normally, routes that contain the local AS number are discarded as potential routing loops.
showwarnings: Tells the system to issue warning messages for events, such as duplicate routes, that are normally “silently ignored.”
noaggregatorid: Sets the routerid in the aggregator attribute to 0. By default, it is set to the router identifier. Use this to prevent this router from creating aggregate routes with AS paths that differ from other routers in the AS.
keepalivesalways: Instructs the system to send a keepalive even when an update could have correctly substituted for one. Used for interoperability with some routers.
v3asloopokay: Allows advertisement of a route with a loop in the AS path (i.e., with an AS appearing more than once in the path) to version 3 external peers.
nov4asloop: Prevents a route with a loop in the AS path from being advertised to version 4 external peers. Used to avoid passing such routes to a peer that incorrectly forwards them to version 3 neighbors.
logupdown: Logs every time a BGP peer enters or leaves the ESTABLISHED state.
ttl ttl: Defines the IP ttl for local neighbors. By default it is set to 1. Use this option if the local neighbor discards packets sent with a ttl of 1. Not all Unix kernels allow the ttl to be specified for TCP connections.

The BGP trace options were covered previously.

The egp Statement

egp yes | no | on | off [{
    preference preference ;
    defaultmetric metric ;
    packetsize maxpacketsize ;
    traceoptions trace_options ;
    group [peeras as_number] [localas as_number] [maxup number] {
    neighbor address
    [metricout metric]
    [preference preference]
    [preference2 preference]
    [ttl ttl]
    [nogendefault]
    [importdefault]
    [exportdefault]
    [gateway address]
    [lcladdr address]
    [sourcenet network]
    [minhello | p1 interval]
    [minpoll | p2 interval]
    [traceoptions trace_options] ; }
 ; }] ;

This statement enables or disables EGP. By default, EGP is disabled. The default metric for announcing routes via EGP is 255, and the default preference for routes learned from EGP is 200.

The packetsize argument defines the size of the largest EGP packet that will be sent or accepted. maxpacketsize is the size in bytes. The default is 8192 bytes. If gated receives a packet larger than maxpacketsize, the packet is discarded, but maxpacketsize is increased to the size of the larger packet so that future packets won’t have to be discarded.

The traceoptions statement defines the tracing for EGP. Tracing can be specified for the EGP protocol or for an individual EGP neighbor. The EGP trace options are:

packets: Traces all EGP packets.
hello: Traces EGP HELLO/I-HEARD-U packets.
acquire: Traces EGP ACQUIRE/CEASE packets.
update: Traces EGP POLL/UPDATE packets.

The egp statement has two clauses: the group clause and the neighbor clause. EGP neighbors must be part of a group, and all of the neighbors in a group must be members of the same autonomous system. Use the group clause to define parameters for a group of EGP neighbors. Values set in a group clause apply to all neighbor clauses in the group. There can be multiple group clauses. The following parameters are set by the group clause:

peeras: Identifies the autonomous system number of the autonomous system to which the members of the group belong. If not specified, this number is learned from the neighbors.
localas: Defines the local system’s autonomous system number. The default is to use the asn defined in the autonomoussystem statement.
maxup: Defines the number of EGP neighbors that gated is to acquire. The default is to acquire all listed neighbors.

The neighbor clause defines one EGP neighbor. The only part of the clause that is required is the address argument, which is the hostname or IP address of the neighbor. All other parameters are optional. All of these optional parameters can also be specified in the group clause if you want to apply the parameter to all neighbors. The neighbor clause parameters are:

metricout metric: Used for all routes sent to this neighbor. This value overrides the defaultmetric value set in the egp statement, but only for this specific neighbor.
preference preference: Defines the preference used for routes learned from this neighbor, which permits gated to prefer routes from one neighbor, or group of neighbors, over another.
preference2 preference: Defines the “second” preference. In the case of a preference tie, the second preference is used to break the tie. The default value is 0.
ttl ttl: Defines the IP ttl for local neighbors. By default, it is set to 1. Use this option if the local neighbor discards packets sent with a ttl of 1.
nogendefault: Prevents gated from generating a default route when EGP peers with this neighbor, even if gendefault is set in the options directive statement.
importdefault: Tells the system to accept the default route if it is included in this neighbor’s EGP update. By default, it is ignored.
exportdefault: Tells the system to send the default route in EGP updates to this EGP neighbor. Normally a default route is not included in an EGP update.
gateway address: Identifies the next-hop gateway through which packets for this neighbor are routed. Use this only if the neighbor does not share a network with the local system. This option is rarely needed.
lcladdr address: Defines the address of the local interface used to communicate with the neighbor.
sourcenet network: Changes the network queried in EGP POLL packets. By default, this is the shared network. However, if the neighbor does not share a network with your system, the neighbor’s network address should be specified here. This parameter is normally not needed. Do not use it if you share a network with the EGP neighbor.
minhello | p1 time: Sets the interval between the transmission of EGP HELLO packets. The default HELLO interval is 30 seconds. If the neighbor fails to respond to three HELLO packets, the system stops trying to acquire the neighbor. Setting a larger interval gives the neighbor a better chance to respond. The interval can be defined as seconds, minutes:seconds, or hours:minutes:seconds. For example, a 3-minute interval could be specified as 180 (seconds), 3:00 (minutes), or 0:3:00 (no hours and 3 minutes). The keyword p1 can be used instead of the keyword minhello.
minpoll | p2 time: Sets the time interval between sending polls to the neighbor. The default is 120 seconds. If three polls are sent without a response, the neighbor is declared “down” and all routes learned from that neighbor are removed from the routing table. If a neighbor becomes congested and can’t respond to rapid polls, this can cause the routing table to become very unstable. A longer polling interval provides a more stable, but less responsive, routing table. This interval is also defined as seconds, minutes:seconds, or hours:minutes:seconds.

The smux Statement

smux yes | no | on | off [ {
    port port ;
    password string ;
    traceoptions trace_options ; } ] ;

This command replaces the snmp statement used in previous versions of gated. The smux command controls whether gated informs the SNMP management software of its status. SNMP is not a routing protocol and is not started by this command. You must run SNMP software independently. This statement only controls whether gated keeps the management software apprised of its status. The default is on, so gated does inform SNMP of its status.

The smux statement supports three options:

port port: Changes the SNMP port used by gated. By default, the SNMP daemon listens to port 199.
password string: Enables password authentication and defines the password used.
traceoptions trace_options: Traces the interactions between gated and the SNMP daemon. Three options are supported: packets, send, and receive.

The redirect Statement

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

This statement controls whether ICMP redirects are allowed to modify the kernel routing table. It does not prevent a system from sending redirects, only from listening to them. If no or off is specified, gated attempts to remove the effects of ICMP redirects from the kernel routing table whenever the redirects are detected. Remember that ICMP is part of IP, and the redirects may be installed in the kernel table before they are seen by gated. If you disable redirects, gated actively removes the redirected routes from the routing table. By default, ICMP redirects are enabled on hosts that quietly listen to interior routing protocols, and disabled on gateways that actively participate in interior routing protocols.

The default preference of a route learned from a redirect is 30, which can be changed with the preference option. The interface statement controls how redirects are handled on an interface-by-interface basis. Redirects are ignored if noredirects is specified, and are permitted if redirects, which is the default, is specified. The trustedgateways statement enables redirects on a gateway-by-gateway basis. By default, redirects are accepted from all routers on the local network. If the trustedgateways statement is used, only redirects received from a gateway listed in the gateway_list are accepted. The gateway_list is simply a list of hostnames or addresses. The trace_options defined on the traceoptions statement are the standard gated trace options.

The icmp Statement

icmp {
    traceoptions trace_options ; }

On some systems, gated listens to all ICMP messages but only processes the ICMP redirect packets. That processing is controlled by the redirect statement. In the future, more functionality may be added. At present the icmp statement is used only to enable tracing of ICMP messages. The tracing options supported by the icmp statement are:

packets: Traces all ICMP packets.
redirect: Traces ICMP REDIRECT packets.
routerdiscovery: Traces ICMP ROUTER DISCOVERY packets.
info: Traces ICMP informational packets.
error: Traces ICMP error packets.

The routerdiscovery Statement

The Router Discovery Protocol informs hosts of the routers that are available on the network. It provides an alternative to static routes, routing protocols, and ICMP redirects for hosts that simply need to know the address of their default router. The Router Discovery Protocol is implemented as a server running on the router and a client running on the host. Both the server (router) software and the client (host) software are provided by gated.

First let’s look at the server configuration statement:

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 routerdiscovery statement for both the client and server supports tracing. The state trace flag can be used to trace finite state machine transitions. Router discovery packet tracing, however, is not done here. It is enabled via the ICMP statement.

The interface clause defines the physical interfaces and the parameters that apply to them. Only physical interfaces can be defined in the interface clause. Addresses are specified in the address clauses shown below. The interface parameters are:

maxadvinterval time: Defines the maximum time interval between sending router advertisements. It must be more than 4 seconds and less than 30:00 minutes. The default is 10:00 minutes (600 seconds).
minadvinterval time: Defines the minimum time interval between sending router advertisements. It must be no less than 3 seconds and no greater than maxadvinterval. The default is 0.75 times the maxadvinterval.
lifetime time: Defines how long clients should consider the addresses in a router advertisement valid. It must be greater than maxadvinterval and no more than 2:30:00 (two hours, thirty minutes). The default is 3 times the maxadvinterval.

The address clause defines the IP addresses used and the parameters that apply to them. The address clause parameters are:

advertise | ignore

advertise specifies that the address should be included in router advertisements, which is the default. ignore specifies that the address should not be included in router advertisements.

broadcast | multicast

broadcast specifies that the address should be included in a broadcast router advertisement because some systems on the network do not support multicasting. This is the default if the router does not support multicasting.

multicast specifies that the address should only be included in a multicast router advertisement. If the system does not support multicasting, the address is not advertised.

ineligible | preference preference

Defines the preference of the address as a default router. preference is a 32-bit signed integer. Higher values mean the address is more preferable. Note that this is not gated preference. This is a value transmitted as part of the Router Discovery Protocol.

The keyword ineligible assigns a preference of hex 80000000, which means the address is not eligible to be the default router. Hosts use ineligible addresses to verify ICMP redirects.

For routerdiscovery to work, the hosts must have the routerdiscovery client software. It is part of gated and is configured by the routerdiscovery client statement.

The routerdiscovery client statement

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

The client uses the same trace options as the server. Other options are different, however. The full list of client options is:

preference preference ;: Defines the preference of default routes learned from routerdiscovery. The default is 55. Unlike the server statement, this is gated preference.
interface interface_list: Defines the interfaces used by routerdiscovery.
enable | disable | multicast: Enables or disables routerdiscovery on the interface. enable is the default. multicast forces gated to use multicasting for router discovery. If multicasting is unavailable, router discovery is not attempted. Normally, gated uses multicasting or broadcasting depending on what is available for the interface.
broadcast | multicast: Specifies whether router solicitations should be broadcast or multicast on the interface. By default, router solicitations are multicast if that is supported; otherwise, router solicitations are broadcast. If the multicast keyword is specified and multicast is not available, the router solicitations are not sent. Generally, if these options are not specified, gated will do the right thing.
quiet | solicit: Specifies whether router solicitations are sent on this interface. solicit, which is the default, sends router solicitations. quiet listens to Router Advertisements but does not send router solicitations.

The kernel Statement

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

The kernel statement defines the interactions between gated and the kernel.

options

Defines three possible configuration options. These are:

nochange: Limits gated to deletes and adds. Use on early versions of the routing socket code that have a malfunctioning change operation.
noflushatexit: Prevents route deletions at shutdown. Normally, shutdown processing deletes routes that do not have a “retain” indication. Use to speed startup on systems with thousands of routes.
protosync: Updates the kernel protocol field with the current gated protocol value.

remnantholdtime

Holds routes read from the kernel forwarding table at startup for up to 3 minutes unless they are overridden.

routes number

Defines the maximum number of routes gated will install in the kernel. By default, there is no limit to the number of routes in the kernel forwarding table.

flash

Tunes the parameters used for flash updates. When routes change, the process of notifying the kernel is called a “flash update.”

limit number: Sets the maximum number of routes processed during one flash update. The default is 20. A value of -1 causes all route changes to be processed. Large updates can slow the processing of “time-critical” protocols. 20 is a good default.
type interface | interior | all: Specifies the type of routes processed during a flash update. By default, only interface routes are installed during a flash update. interior specifies that interior routes are also installed, and all specifies that interior and exterior routes should be processed. Specifying flash limit -1 all causes all routes to be installed during the flash update, which mimics the behavior of previous versions of gated.

background

Tunes the parameters used for background processing. Since only interface routes are normally installed during a flash update, most routes are processed in batches in the background.

limit number: Sets the number of routes processed in one batch. The default is 120.
priority flash | higher | lower: Sets the priority for processing batch updates. The default is lower, which means that batch updates are processed at a lower priority than flash updates. To process kernel updates at the same priority as flash updates, specify flash.

Many tracing options work for the kernel interface because, in many cases, the interface is handled as a routing protocol. The command-line trace options, symbols and iflist, provide information about the kernel. The kernel statement trace options are:

remnants: Traces routes read from the kernel when gated starts.
request: Traces gated kernel Add/Delete/Change operations.

The remaining trace options apply only to systems that use the routing socket to exchange routing information with the kernel.

info: Traces informational messages received from the routing socket.
routes: Traces routes exchanged with the kernel.
redirect: Traces redirect messages received from the kernel.
interface: Traces interface status messages received from the kernel.
other: Traces any other messages received from the kernel.

static Statements

static statements define the static routes used by gated. A single static statement can specify several routes. The static statements occur after protocol statements and before control statements in the gated.conf file. To gated, static routes are any routes defined with static statements. However, unlike the routes in a static routing table, these routes can be overridden by routes with better preference values.

The structure of a static statement is:

static {
   [default] | [[host] address [mask mask | masklen n]] gateway gateways
     [interface interface_list]
     [preference preference]
     [retain]
     [reject]
     [blackhole]
     [noinstall] ;
   address [mask mask | masklen n] interface interface
     [preference preference]
     [retain]
     [reject]
     [blackhole]
     [noinstall] ; 
} ;

The static statement has two different clauses. The one with the keyword gateway is the one you’ll use. This clause contains information similar to that provided by the route command. A static route is defined as a destination address reached though a gateway. The format of this clause is:

[default] | [[host] address [mask mask | masklen number ]] gateway gateways

Defines a static route through one or more gateways. The destination is defined by the keyword default (for the default route) or by a destination address. The destination address can be preceded by the keyword host, if it is a host address, or followed by an address mask. The address mask can be defined with the keyword mask and a dotted decimal address mask, or by the keyword masklen and a numeric prefix length. The listed gateways must be on a directly attached network. Possible configuration parameters are:

interface interface_list: When specified, gateways in the gateway_list must be directly reachable through one of these interfaces.
preference preference: Sets the gated preference for this static route. The default is 60.
retain: Prevents this static route from being removed during a graceful shutdown. Normally, only interface routes are retained in the kernel forwarding table. Use this to provide some routing when gated is not running.
reject: Installs this route as a “reject route.” Packets sent to a reject route are dropped and an “unreachable” message is sent back to the source. Not all kernels support reject routes.
blackhole: Installs this route as a “blackhole route.” A blackhole route is the same as a reject route except the “unreachable” message is not sent.
noinstall: Instructs the system to advertise this route via routing protocols but not to install it in the kernel forwarding table.

The other static statement clause uses the keyword interface instead of the keyword gateway. Use this clause only if you have a single physical network with more than one network address—a rare occurrence. ifconfig normally creates only one destination for each interface. This special form of the static statement adds additional destinations to the interface.

            address [mask mask | masklen number] interface interface

The preference, retain, reject, blackhole, and noinstall options are the same as described above.

The default preference of a static route is 60, which prefers static routes over several other routing sources. If you want other types of routes to override static routes, use the preference argument on the static statement to increase the preference number. (Remember that high preference values mean less-preferred routes.)

The following example defines a static default route through gateway 172.16.12.1. The preference is set to 125 so that routes learned from RIP are preferred over this static route:

static  { 
    default gateway 128.66.12.1 preference 125 ;  } ;

Control Statements

The control statements define your routing policy. Often when administrators hear the terms “routing policy” or “policy-based routing,” they assume that this is something done inside the routing protocol.

In reality, a routing policy is defined outside of the routing protocol in the configuration file. The policy defines what routes are accepted and what routes are advertised. gated does this with two control statements: import and export. The import statement defines which routes are accepted and from what sources those routes are accepted. The export statement defines which routes are advertised based on the source of the routes and the protocol used to advertise them.

The import and export statements use gated preference, routing metrics, routing filters, and AS paths to define routing policy. Preference and metrics are controlled by these keywords:

restrict: Specifies that the routes are not to be imported, in the case of the import command, or exported in the case of the export command. This keyword blocks the use of a specific route.
preference preference: Defines the preference value used when comparing this route to other routes. Preference is used when installing routes, not when advertising them.
metric metric: Specifies the metric used when advertising a route.

Route filters match routes by destination address. Among other places, route filters are used on martians and import and export statements. A route matches the most specific filter that applies. Specifying more than one filter with the same destination, mask, and modifiers generates an error. Import and export route filters can be specified in the following ways:^[155]

address [mask mask | masklen number ] [exact | refines | between n1 and n2 ]

Defines a range of addresses using an address and an address mask. The address mask can be defined with the keyword mask and a mask written in dotted decimal notation, or with the keyword masklen and a numeric prefix length. If no mask is defined, the natural mask of the network is used. Three options can be used:

exact: Matches a network, but no subnets or hosts of that network.
refines: Matches subnets and/or hosts of a network, but not the network itself.
between n1 and n2: Matches an address where at least n1 bits match and no more than n2 bits match.

all

Matches every possible address.

default

Matches only the default route.

host address

Matches an individual host address.

A routing filter that matches everything on network number 192.168.12.0 and the individual host 10.104.19.12 contains:

192.168.12.0 masklen 24 ; host 10.104.19.12 ;

When no route filtering is specified in an import or export statement, all routes from the specified source will match that statement. If any filters are specified, only routes that match the specified filters are imported or exported.

Border Gateway Protocol (BGP) is designed to support policy-based routing. A key feature of BGP is that it is a path-vector protocol. import and export statements allow you to use the AS path vector to enforce your routing policy.

An AS path lists the autonomous systems end-to-end for a route and provides an indication of the completeness of the path. Each autonomous system that a route passes through prepends its AS number to the beginning of the AS path.

The “origin” of the path indicates its completeness. An origin of igp indicates the route was learned from an interior routing protocol and is most likely complete. An origin of egp indicates the route was learned from an exterior routing protocol that does not support AS paths (EGP for example) and the path is most likely not complete.

When the path information is definitely not complete, an origin of incomplete is used. All of these origins can be specified in the import and export statements and therefore used in your routing policy. The keyword any is used when the policy applies to all origins.

The AS path can also be used in the control statements by defining an AS path regular expression.^[156] The AS path regular expression provides a pattern-matching syntax used to filter routes based on the autonomous system numbers in the AS paths associated with those routes.

An AS path regular expression is a regular expression composed of autonomous system numbers and special operators. Table B-1 lists the AS path operators. The AS path operator operates on an AS path term, which is an autonomous system number; a dot (.), which matches any autonomous system number; or a parentheses-enclosed subexpression.

Table B-1. AS path operators

Symbol	Meaning
{`m`,`n`}	At least `m` and at most `n` repetitions
{`m`}	Exactly `m` repetitions
{`m`,}	`m` or more repetitions
*	0 or more repetitions
+	1 or more repetitions
?	0 or 1 repetition
aspath_term \| aspath_term	Matches either the AS term on the left or the AS term on the right

A simple AS path regular expression might be:

import proto bgp aspath 164+ origin any restrict ;

This restricts all routes that have one or more occurrences of autonomous system number 164 in their path vector.

The import Statement

The format of an import statement varies depending on the source protocol. The format of the import statements for the exterior gateway protocols is:

import proto bgp | egp autonomoussystem as_number
   [restrict] |
   [[preference preference] {
   route_filter [restrict | (preference preference)]] ; } ;
import proto bgp aspath aspath_regexp
   origin any | igp | egp | incomplete
   [restrict] |
   [[preference preference] {
   route_filter [restrict | (preference preference)]] ; } ;

BGP and EGP importation may be controlled by autonomous system number. BGP also can control importation using AS path regular expressions. Routes that are rejected by the routing policy are stored in the routing table with a negative preference. A negative preference prevents a route from being installed in the forwarding table or exported to other protocols. Handling rejected routes in this manner alleviates the need to break and reestablish a session if routing policy changes during a reconfiguration.

The format of the import statements for the RIP and redirect protocols is:

import proto rip | redirect
 [interface interface_list | gateway gateway_list]
 [restrict] |
 [[preference preference] {
  route_filter [restrict | (preference preference)]] ; } ;

This statement controls what routes are imported based on the source protocol, interface, and gateway. The order of precedence is from the most general (protocol) to the most specific (gateway). Unlike BGP and EGP, these protocols do not save routes that were rejected because these protocols have short update intervals.

The preference option is not used with RIP. RIP doesn’t use preference to choose between routes of the same protocol. It uses the protocol metrics.

The format of the import statement for the OSPF protocol is:

import proto ospfase [tag ospf_tag] [restrict] |
 [[preference preference] {
  route_filter [restrict | (preference preference)]] ; } ;

Due to the nature of OSPF, only the importation of ASE routes can be controlled. Furthermore, it is only possible to restrict the importation of OSPF ASE routes when functioning as an AS border router. This requires you to specify an export ospfase statement in addition to the import ospfase statement. Specify an empty export statement to control importation of ASEs when no ASEs are being exported. (See the following section, “The export Statement.”) If a tag is specified, the import statement applies only to routes with the tag. OSPF ASE routes that are rejected by policy are stored in the table with a negative preference.

OSPF routes are imported into the gated routing table with a preference of 10. Preference is not used to choose between OSPF ASE routes. OSPF costs are used for that purpose.

The export Statement

The syntax of the export statement is similar to the syntax of the import statement, and the meanings of many of the parameters are identical. An important difference between the two statements is that while route importation is controlled by source information, route exportation is controlled by both source and destination. Thus, export statements define where the routes will be sent and where they originated. The destination of the route advertisement is defined by the proto clause at the beginning of the export statement. The source of the routes is defined in the export list.

The export statement varies slightly for each protocol. To advertise routes via EGP and BGP, use this syntax:

export proto bgp | egp as as_number
 [restrict] |
 [[metric metric] {
  export_list ; }] ;

Routes are exported via EGP and BGP to the specified autonomous system. restrict blocks exports to the AS. Valid BGP or EGP metrics can be specified. If no export list is defined, only the direct routes of the attached interfaces are exported. If an export list is used, it must explicitly specify everything that should be exported.

To advertise routes via RIP, use this syntax:

export proto rip
  [interface interface_list | gateway gateway_list]
  [restrict] |
  [[metric metric] {
  export_list ; }] ;

Routes exported by RIP can be sent through a specific interface or to a specific gateway. Set metric if you plan to export static or internally generated default routes. The metric option is used only when exporting non-RIP routes via RIP.

If no export list is specified, RIP exports direct routes and RIP routes. If an export list is used, it must explicitly specify everything that should be exported.

To advertise routes via OSPF, use this syntax:

export proto osfpase [type 1 | 2] [tag ospf_tag]
 [restrict] |
 [[metric metric] {
  export_list ; }] ;

Only OSPF ASE routes can be exported by gated. There are two types of OSPF ASE routes, type 1 and type 2. They are described in Chapter 7 and earlier in this appendix. The default type is specified in the ospf protocol statement, but it can be overridden here. The ospf_tag is an arbitrary 32-bit number used to filter routing information. The default tag value is specified in the ospf protocol statement, but it can be overridden here.

The source of the routes advertised by a protocol is defined by the export list. Each of the commands listed above contains an export list option. Just like those commands, the export list syntax varies depending on the source protocol of the routes. The commands described above define the protocols that are used to advertise the routes. The export lists shown below describe the protocols from which the routes are obtained. The biggest confusion caused by the export list syntax is that it is almost identical to the syntax shown above. In both cases we define protocols, autonomous systems, interfaces, gateways, and so on. In the first case we are defining the protocols, interfaces, etc., to which routes are sent, and in this case we are defining the protocols, interfaces, etc., from which routes are received.

To export routes learned from BGP and EGP, use this export list syntax:

export proto bgp | egp autonomoussystem as_number
 [restrict [noagg]] |
 [[metric metric] {
  route_filter [restrict | metric metric] ; }] ;

This defines routes learned via BGP or EGP from a specific autonomous system. Routes can be restricted, or have a metric applied, based on matching the source AS number or the route filter. noagg can be used with restrict to prevent any aggregate routes from matching the filter.

When BGP is configured, gated assigns all routes an AS path. For interior routes, the AS path specifies igp as the origin and no autonomous systems in the AS path (the current AS is added when the route is exported). For EGP routes, the AS path specifies egp as the origin and the source AS as the AS path. For BGP routes, the AS path learned from BGP is used. If you run BGP, the export of all routes may be controlled by the AS path using this syntax:

proto proto | all
 aspath aspath_regexp origin any | igp | egp | incomplete
 [restrict] |
 [[metric metric] {
  route_filter [restrict | metric metric] ; }] ;

The source of the routes can be any one protocol (proto) or all protocols (all). The importation of routes can be controlled by matching their AS paths against the AS path regular expression (aspath_regexp) or by matching their addresses against the route_filter. Route filters and AS path regular expressions were explained previously.

To export routes learned from RIP, use this export list syntax:

proto rip
 [interface interface_list | gateway gateway_list]
 [restrict] |
 [[metric metric] {
  route_filter [restrict | metric metric] ; }] ;

The export of RIP routes may be controlled by source interface, source gateway, or route filter.

To export routes learned from OSPF, use this export list syntax:

proto ospf | ospfase
 [restrict] |
 [[metric metric] {
  route_filter [restrict | metric metric] ; }] ;

The export of OSPF and OSPF ASE routes may be controlled by protocol and route filter. Exporting OSPF routes can also be controlled by tag using the following syntax:

proto proto | all tag tag
                 [restrict] |
   [[metric metric] {
   route_filter [restrict | metric metric] ; }] ;

OSPF and RIP version 2 provide a tag field. For all other protocols, the tag is always 0. Routes may be selected based on the contents of the tag field.

There are other sources of routes that are not true routing protocols, and export lists can be defined for these sources. The two export lists for these sources are:

proto direct | static | kernel
 [interface interface_list]
 [restrict] |
 [[metric metric] {
  route_filter [restrict | metric metric] ; }] ;

The export of these routes can be controlled based on the source “protocol” and the source interface. The “protocols” in this case are routes to direct interfaces, static routes, or routes learned from the kernel.

proto default | aggregate
 [restrict] |
 [[metric metric] {
  route_filter [restrict | metric metric] ; }] ;

The export of these routes may only be controlled based on source “protocol.” default refers to routes created by the gendefault option. aggregate refers to routes created by the aggregate statements, the topic of the next section.

Aggregate Statements

Route aggregation is used by regional and national networks to reduce the number of routes advertised. With careful planning, large network providers can announce a few aggregate routes instead of hundreds of client network routes. Enabling aggregation is the main reason that CIDR blocks are allocated as contiguous address blocks.

Most of us don’t have hundreds of routes to advertise. But we may have a classless address composed of a few class C addresses, and we may need to tell gated how to handle it. Older versions of gated automatically generated an aggregate route to a natural network using the old class A, B, and C concept; i.e., interface address 192.168.16.1 created a route to 192.168.16.0. With the advent of classless interdomain routing, this can be the wrong thing to do. gated does not aggregate routes unless it is explicitly configured with the aggregate statement:

aggregate default | address [[mask mask | masklen number] [bgp]]
  [preference preference] [brief] {
  proto proto
    [as as_number | tag tag | aspath aspath_regexp]
    [restrict] |
    [[preference preference] {
      route_filter [restrict | (preference preference)]] ; } ;

Several options are available for the aggregate statement:

bgp: Aggregations are to be formed using BGP protocol rules.
preference preference;: Defines the preference of the resulting aggregate route. The default is 130.
brief: Specifies that the AS path of the aggregate route should be the longest common AS path. The default is to build an AS path consisting of all contributing AS paths.
proto proto: Only aggregate routes learned from the specified protocol. The value of proto may be any currently configured protocol. This includes the “protocols” direct, static, and kernel, discussed in the previous section; all for all possible protocols; and aggregate for other route aggregations.
as as_number: Only aggregate routes learned from the specified autonomous system.
tag tag: Only aggregate routes with the specified tag.
aspath aspath_regexp: Only aggregate routes that match the specified AS path.
restrict: Indicates routes that are not to be aggregated.

Routes that match the route filters may contribute to the aggregate route. A route may contribute only to an aggregate route that is more general than itself. Any given route may contribute to only one aggregate route, but an aggregate route may contribute to a more general aggregate.

A slight variation of aggregation is the generation of a route based on the existence of certain conditions. The most common usage for this is to create a default based on the presence of a route from a peer on a neighboring backbone. This is done with the generate statement:

generate default | address [mask mask | masklen number]
  [preference preference] 
  [brief] {
  proto proto
    [as as_number | tag tag | aspath aspath_regexp]
    [restrict] |
    [[preference preference] {
    route_filter [restrict | preference preference]] ; } ;
} ;

The generate statement uses many of the same options as the aggregate statement. These options were described earlier in this appendix.

Table of Contents for
TCP/IP Network Administration, 3rd Edition

Appendix B. A gated Reference

The gated Command

Signal Processing

The gated Configuration Language

Directive Statements

Trace Statements

Options Statements

Interface Statements

Definition Statements

Protocol Statements

The ospf Statement

Warning

The rip Statement

The isis Statement

The bgp Statement

The egp Statement

The smux Statement

The redirect Statement

The icmp Statement

The routerdiscovery Statement

The routerdiscovery client statement

The kernel Statement

static Statements

Control Statements

The import Statement

The export Statement

Aggregate Statements

Table of Contents for TCP/IP Network Administration, 3rd Edition

Appendix B. A gated Reference

The gated Command

Signal Processing

The gated Configuration Language

Directive Statements

Trace Statements

Options Statements

Interface Statements

Definition Statements

Protocol Statements

The ospf Statement

Warning

The rip Statement

The isis Statement

The bgp Statement

The egp Statement

The smux Statement

The redirect Statement

The icmp Statement

The routerdiscovery Statement

The routerdiscovery client statement

The kernel Statement

static Statements

Control Statements

The import Statement

The export Statement

Aggregate Statements

Table of Contents for
TCP/IP Network Administration, 3rd Edition