gated.conf man page on DigitalUNIX

gated.conf man page on DigitalUNIX

Man page or keyword search:
man Server 12896 pages
apropos Keyword Search (all sections)
Output format

gated.conf(4) gated.conf(4)

NAME
gated.conf - Gate daemon configuration file (general information)

DESCRIPTION
The gated.conf file contains configuration information that is read by
the gated daemon at initialization time. This file contains statements
that control tracing options, select routing protocols, manage routing
information, and manage independent system routing.

The /etc/gated.conf file is defined as a Context-Dependent Symbolic
Link (CDSL), and must be maintained as such. See the System Adminis‐
tration manual for more information.

The gated.conf file consists of a sequence of statements terminated by
a semi-colon (;). Statements are composed of tokens separated by any
combination of blanks, tabs, and newlines. This structure simplifies
identification of the parts of the configuration associated with each
other and with specific protocols. Comments can be specified by either
of the following: A number sign (#) The C-style /* and */ characters.

Syntax description conventions
Keywords and special characters that the parser expects are displayed
using the HTML strong style. Parameters are specified in the HTML
variable definition style. Parameters shown in brackets ([]) show
optional keywords and parameters. The vertical bar (|) indicates a
choice of optional parameters. Parentheses (()) group keywords and
parameters, when necessary. For example: backbone | (area area)

In this example, the brackets indicate that either parameter is
optional. The keywords are backbone and area. The vertical bar indi‐
cates that either backbone or area area can be specified. Because area
is in the variable definition0 style, it is a parameter that needs to
be provided.

Statement Grouping
The configuration statements and the order in which they must appear in
the gated.conf file are as follows: options statements interface state‐
ments definition statements protocol statements static statements con‐
trol statements aggregate statements

Entering a statement out of order causes an error when parsing the con‐
figuration file.

Two other types of statements do not fit in these categories: %direc‐
tive statements and %trace statements. These statements provide
instructions to the parser and control tracing from the configuration
file. They do not relate to the configuration of any protocol and may
occur anywhere in the gated.conf file.

Configuration Statement Summary
The following table lists each gated.conf configuration statement by
name, identifies the statement type, and gives a synopsis of the state‐
ment's function:

───────────────────────────────────────────────────────────────────
Name Type Synopsis
───────────────────────────────────────────────────────────────────
%directory directive Sets the directory for include
files.
%include directive Includes a file into gated.conf.
traceoptions trace Specifies which events are traced.
options definition Defines gated options.
interfaces definition Defines gated interfaces.

autonomoussystem definition Defines the AS number.
routerid definition Defines the originating router
(BGP, OSPF).
martians definition Defines invalid destination
addresses.
rip protocol Enables the RIP protocol.
isis protocol Enables the ISIS protocol.
kernel protocol Configures kernel interface
options.
ospf protocol Enables the OSPF protocol.
egp protocol Enables the EGP protocol.
bgp protocol Enables the BGP protocol.
redirect protocol Configures the processing of ICMP
redirects.
icmp protocol Configures the processing of gen‐
eral ICMP packets.
snmp protocol Enables reporting to SNMP.
pim protocol Enables PIM protocol.
dvrmp protocol Enables DVRMP protocol.
msdp protocol Enables MSDP protocol.
static static Defines static routes.
import control Defines which routes to import.
export control Defines which routes to export.
aggregate control Defines which routes to aggregate.
generate control Defines which routes to generate.
───────────────────────────────────────────────────────────────────

ROUTING AND PREFERENCES
The gated.conf files can define routes from one protocol or peer to
another, assigning each route a value called a preference.

The preference value determines the order of routes to the same desti‐
nation in a single routing database. The active route is chosen by the
lowest preference value.

Some protocols implement a second preference (preference2), sometimes
referred to as a tie breaker.

Use the following guidelines when setting preferences: It can be set in
several different configuration statements in gated.conf, although the
last or most specific value set for a route is the one used. (See
gated_intro(7).) It can be specify one network interface over another,
one protocol over another, or one remote gateway over another. It can‐
not be used to control the selection of routes within an interior gate‐
way protocol (IGP). That function is accomplished automatically by the
protocol based on metric. It can be used to select routes from the
same exterior gateway protocol (EGP) learned from different peers or
autonomous systems.

Selecting a Route
The gated daemon uses the following criteria to select a route: The
route with the best (numerically smallest) preference, as defined in
the gated.conf file, is preferred. If the two routes have the same
preference, the route with the best (numerically smallest) preference2
(also known as a tie breaker) is preferred. If autonomous system (AS)
path information is available it is used to help determine the most
preferred route as follows: A route with an AS path is preferred over
one without and AS path. If the AS paths and origins are identical,
the route with the lower metric is preferred. A route with an AS path
origin of IGP is preferred over a route with an AS path origin of EGP.
The least preferred is an AS path with an unknown origin. A route with
a shorter AS path is preferred. A route with the lowest Multi-Exit
Discriminator (MED)is preferred. MEDs are only compared between routes
that were received from the same neighbor AS. (This test is only
applied if the local AS has two or more connections to a given neighbor
AS.) A route learned from an IGP is preferred to a route learned from
an EGP. The least preferred is a route learned indirectly by an IGP
from an EGP. The route with the lowest numeric next-hop address is
used. If both routes are from the same protocol and AS, the one with
the lowest metric is preferred.

Assigning Preferences
A default preference is assigned to each source from which gated
receives routes. Preference values range from 0 to 255, with the low‐
est number indicating the most preferred route.

The following table lists each type of route, the statement (or clause
within statements) that sets preference for the route, and the default
preference for each type of route.

Note that a statement that is narrow in scope has a higher precedence
given to its preference value, but affects a smaller set of routes.

────────────────────────────────────────────────────────────────────
Preference of Defined by Statement Default
────────────────────────────────────────────────────────────────────
Direct connected networks interface 0
OSPF routes ospf 10
IS-IS level 1 routes isis level 1 15
IS-IS level 2 routes isis level 2 18
Internally generated default gendefault 20
Redirects redirect 30
Routes learned via route socket kernel 40
Static routes from config static 60
ANS SPF (SLSP) routes slsp 70
RIP routes rip 100
Point-to-point interface 110
Routes to interfaces that are down interfaces 120
Aggregate/generate routes aggregate/generate 130
OSPF AS external routes ospf 150
BGP routes bgp 170
EGP egp 200
────────────────────────────────────────────────────────────────────

Multi-Exit Discriminator
The Multi Exit Discriminator, or MED, allows the administrator of a
routing domain to choose between various exits from a neighboring AS.
The gated daemon uses this attribute to choose the best route to the
neighboring AS. If all the other factors for a path to a given AS are
equal, the path with the lower MED value takes preference over other
paths.

This attribute is not propagated to other neighboring ASs. This
attribute can be propagated, however, to other BGP speakers within the
same AS.

The MED attribute, for BGP version 4, is a four-octet unsigned integer.

You originate a MED by using the metricout option of group or peer
statements or the metric option of the export statement. You import a
MED by using the med keyword on the BGP group statement.

You must specify the med keyword on the group statement for gated to
consider metrics when calculating a next hop (the default action is to
ignore MEDs).

The following example shows the metricout option when specified on the
group statement:

group type external peeras 31337 metricout 5 {
peer 192.168.10.32;
peer 192.168.10.33; };

The following example shows the metricout option when specified on the
peer statement:

group type external peeras 31337 {
peer 192.168.10.32 metricout 2;
peer 192.168.10.33 metricout 3; };

The following example shows the metric keyword when specified on the
export statement:

export proto bgp as 31337 metric 5 {
proto static {
all;
}; };

The following example shows another case of specifying the metric key‐
word on the export statement:

export proto bgp as 31337 {
proto bgp as 64000 metric 1 {
all;
};
proto static metric 3 {
all;
};
proto direct metric 7 {
all;
}; };

Sample Preference Specifications
In the following statements, the preference applicable to routes
learned via RIP from gateway 138.66.12.1 is 75. The last preference
applicable to routes learned via RIP from gateway 138.66.12.1 is
defined in the accept statement. The preference applicable to other
RIP routes is found in the rip statement. The preference set on the
interface statement applies only to the route to that interface.

interfaces {
interface 138.66.12.2 preference 10 ; } ; rip yes {
preference 90 ; } ; import proto rip gateway 138.66.12.1 preference
75 ;

TRACE OPTIONS STATEMENT
Trace options statements control tracing options. The gated daemon's
tracing options may be configured at many levels. Tracing options
include the file specifications, control options, and global and proto‐
col-specific tracing options. Unless overridden, tracing options from
the next higher level are inherited by lower levels. For example, Bor‐
der Gateway Protocol (BGP) peer tracing options are inherited from BGP
group tracing options, which are inherited from global BGP tracing
options, which are inherited from global gated tracing options. At each
level, tracing specifications override the inherited options.

Syntax
traceoptions [trace_file [replace] [size size[k|m] files files]]
[control_options] trace_options [except trace_options];

traceoptions none ;

Specifies the file to receive tracing information. If this file name
does not begin with a slash (/), the directory in which gated was
started is prepended to the name. Replaces an existing trace file.
The default is to append to an existing file. Limits the maximum size
of the trace file to the specified size (minimum 10 kilobytes). When
the trace file reaches the specified size, it is renamed to file.0,
then file.1, file.2, up to the maximum number of files (minimum speci‐
fication is 2). Specifies options that control the appearance of trac‐
ing. The only valid value is nostamp, which specifies that a time
stamp should not be prepended to all trace lines. See the Global Trac‐
ing Options section for more information. Enables a broad class of
tracing and then disables more specific options. See the Global Trac‐
ing Options section for more information. Specifies that all tracing
should be turned off for this protocol or peer.

Global Tracing Options
There are two types of global options: those with global significance
and those with protocol significance.

Global Significance
The following trace flags have global significance: Traces the lexical
analyzer and parser. Used mainly by gated developers for debugging.
Traces the allocation of and freeing of policy blocks. Used mainly by
the gated developers for debugging. Traces symbols read from the ker‐
nel at startup. The principal means to specify this level of tracing
is by the -t option on the command line, because the symbols are read
from the kernel before parsing the configuration file. Traces the
reading of the kernel interface list. Specify this with the -t option
on the command line because the first interface scan is done before
reading the configuration file.

Protocol Significance
The following options flags have potential significance to protocols:
Turns on all of the options flags. A shorthand notation for specifying
both normal and route. Traces normal protocols occurrences. Abnormal
protocol occurrences are always traced. Traces routing table changes
for routes installed by this protocol or peer. Traces state machine
transitions in the protocols. Traces application of protocol and user-
specified policy to routes being imported and exported. Traces system
interface and processing associated with this protocol or peer. Traces
timer usage by this protocol or peer.

Note

Not all of these options apply to all of the protocols. In some cases,
their use does not make sense (for instance, RIP does not have a state
machine) and in some instances the requested tracing has not been
implemented (such as RIP support of the policy option).

It is not possible to specify packet tracing from the command line
because a global option for packet tracing would potentially create too
much output.

When protocols inherit their tracing options from the global tracing
options, tracing levels that do not make sense (such as parse, adv, and
packet tracing options) are masked out.

Global tracing statements have an immediate effect, especially parsing
options that affect the parsing of the configuration file. Tracing
values inherited by protocols specified in the configuration file are
initially inherited from the global options in effect as they are
parsed, unless they are overridden by more specific options.

After the configuration file is read, tracing options that were not
explicitly specified are inherited from the global options in effect at
the end of the configuration file.

Packet tracing
The tracing of packets is flexible. Every protocol has one or more
options for tracing packets. All protocols allow the packets keyword
to be used for tracing all packets sent and received by the protocol.
Most protocols have other options for limiting tracing to a useful sub‐
set of packet types. These tracing options can be further controlled
with the following modifiers: Specifies a more verbose format to pro‐
vide more information about the contents of the packet. The detail
option must be specified before send or recv. By default, packets are
traced in a terse form of one or two lines. Limit the tracing to pack‐
ets sent. If neither send nor recv option is specified, both sent and
received packets are traced. Limit the tracing to packets received.
If neither send nor recv option is specified, both sent and received
packets are traced.

Note

If a protocol allows for several different types of packet tracing,
modifiers can be applied to each individual type. Be aware, however,
that within one tracing specification the trace flags are summed up, so
specifying detail packets turns on full tracing for all packets.

DIRECTIVE STATEMENTS
Directive statements provide direction to the gated configuration lan‐
guage parser about included files and the directories in which these
files reside. Directive statements are immediately acted upon by the
parser. Other statements terminate with a semi-colon (;), but direc‐
tive statements terminate with a newline. The two directive statements
are as follows: Defines the directory in which the include files are
stored. When it is used, gated searches the directory identified by
pathname for any included files that do not have a fully qualified file
name (do not begin with "/"). This statement does not change the cur‐
rent directory; it only specifies the prefix applied to included file
names. Identifies an include file. The contents of the file are
included in the gated.conf file at the point where the %include direc‐
tive is located. If the file name is not fully qualified (does not
begin with "/"), it is considered to be relative to the directory
defined in the %directory directive. The %include directive statement
causes the specified file to be parsed completely before resuming with
this file. Nesting up to ten levels is supported. The maximum nesting
level can be increased by changing the definition of FI_MAX in the
parse.h file.

In a complex environment, segmenting a large configuration into smaller
more easily understood segments might be helpful, but one of the advan‐
tages of gated is that it combines the configuration of several differ‐
ent routing protocols into a single file. Segmenting a small file
unnecessarily complicates routing configurations.

OPTIONS STATEMENTS
The options statement allows specification of some global options. If
used, the options statement must appear before any other type of con‐
figuration statement in the gated.conf file.

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

The options list can contain one or more of the following options: When
gendefault is enabled and a BGP or EGP neighbor is up, a default route
with the special protocol default is created. This can be disabled per
BGP/EGP group with the nogendefault option. By default, this route has
a preference of 20. This route is normally not installed in the kernel
forwarding table; it is only present so it can be announced to other
protocols.

If a gateway is specified, the default route is installed in the
kernel forwarding table with a next hop of the listed gateway.

Note that the use of the more general generate default option is
preferred to the use of the gendefault option. The gendefault
option may be removed in the future. See the section on "Route
Aggregation" in gated.control(4) for more information on the
generate statement. Do not send any packets. This option makes
it possible to run gated on a live network to test protocol
interactions without actually participating in the routing pro‐
tocols. The packet traces in the gated log can be examined to
verify that gated is functioning properly. This is useful for
RIP and possibly the SMUX SNMP interface. This option does not
apply to BGP and is not useful with EGP and OSPF. By default,
gated tries to resolve symbolic names into IP addresses by using
the gethostbyname() and getnetbyname() library calls. These
calls usually use the Domain Name System (DNS) instead of the
host's local host and network tables. If there is insufficient
routing information to send DNS queries, gated deadlocks during
startup. This option can be used to prevent these calls; sym‐
bolic names result in configuration file errors. Controls the
amount of data gated logs via syslog on systems where setlog‐
mask() is supported. The available logging levels and other
terminology are as defined in setlogmask(3). The default is
equivalent to syslog upto info. Specifying this option causes
gated to output a message to the trace log at the specified
interval. This can be used to determine if gated is still run‐
ning.

INTERFACES STATEMENT
An interface is the connection between a router and one of its attached
networks. A physical interface can be specified by interface name, by
IP address, or by domain name (unless the network is an unnumbered
point-to-point network). Multiple levels of reference in the configu‐
ration language allow identification of interfaces using a wild card or
interface type name. Be careful with the use of interface names
because future versions might allow more than one address per inter‐
face. The interface_list is a list of one or more interface names
including wildcard names (names without a number) and names that may
specify more than one interface or address, or the token all for all
interfaces.

Syntax
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 | pointtopoint address]
[netmask mask]
[multicast]
; } ;

Allows configuration of the following global options related to inter‐
faces: Indicates that it is a fatal error to reference an interface in
the configuration file that is not present when gated is started and
not listed in a define statement. Without this option, a warning mes‐
sage is issued but gated continues. 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 (for example, BSD 4.4). Note that
gated also scans the interface list on receipt of a SIGUSR2. Specifies
which address gated will install as the next hop for interface routes.
If primary is used, the primary interface address (default) will be
installed. If lowestip is used, the address with the lowest IP address
will be installed. If keepall is used, all interface routes are kept
in the kernel up to a maximum of RT_N_MULTIPATH routes. The aliases-
nexthop option is a global parameter that can be overridden for inter‐
faces using the interface option. Sets interface options on the speci‐
fied interfaces. An interface list is all or a list of interface names
(see the "Interface Lists" section), domain names, or numeric
addresses. Options available on this statement are: Sets the prefer‐
ence for routes to this interface when it is up and appears to be func‐
tioning properly. The default preference is 0. Sets the preference
for routes to this interface when gated does not believe it to be func‐
tioning properly, but the kernel does not indicate it is down. The
default value is 120. Prevents gated from changing the preference of
the route to this interface if it is not believed to be functioning
properly due to lack of received routing information. The gated daemon
only performs this check if the interface is actively participating in
a routing protocol. Defines an interface as unable to hear its own
broadcast packets. Some systems define an interface as simplex with the
IFF_SIMPLEX flag; others require it to be specified in the configura‐
tion file. On simplex interfaces, a sender's own packets are assumed to
have been looped back in software and are not used as an indication
that the interface is functioning properly. Specifies that the address
of the interface matching these criteria is used as the local address
when installing reject routes in the kernel. Use this only with sys‐
tems based on BSD 4.3 Tahoe or earlier that have installed a
reject/blackhole pseudointerface. Specifies that the address of the
interface matching these criteria is used as the local address when
installing reject routes in the kernel. Use this only with systems
based on BSD 4.3 Tahoe or earlier that have installed a reject/black‐
hole pseudo interface. Specifies the AS that will be used to create an
AS path associated with the route created from the definition of this
interface. Defines interfaces that might not be present when gated is
started so they may be referenced in the configuration file when
strictinterfaces is defined. The following are valid define keywords:
Defines the interface as broadcast capable (for example, Ethernet or
Token Ring) and specifies the broadcast address. Defines the interface
as a point-to-point interface (for example, SLIP or PPP) and specifies
the address on the local side. The first address on the define state‐
ment references the address of the host on the remote end of the inter‐
face, the address specified after this pointopoint keyword defines the
address on the local side of the interface.

An interface that is not defined as broadcast or point-to-point
is assumed to be nonbroadcast multiaccess (NBMA), such as an
X.25 network. Specifies the subnet mask to be used on this
interface. This is ignored on point-to-point interfaces. Spec‐
ifies that the interface is multicast capable.

Interface Lists
An interface list is a list of references to interfaces or groups of
interfaces. The following four methods, from most general to most spe‐
cific, are available for referring to interfaces: Refers to all avail‐
able interfaces. Refers to all the interfaces of the same type. Tru64
UNIX interfaces consist of the device driver name and a unit number;
for example, le0. References to the name contain only alphabetic char‐
acters and match any interfaces that have the same alphabetic part.

For example, le refers to all Lance Ethernet interfaces, but le
does not match lel0. Refers to a specific interface, usually
one physical interface. These are specified as an alphabetic
part followed by a numeric part. This will match one specific
interface. But be aware that on many systems, there can be more
than one protocol (for example, IP) address on a given physical
interface. For example, ee1 matches an interface named ee1, but
not an interface named ee10. Matches one specific interface.
The reference can be by protocol address (for example,
10.0.0.51) or by symbolic host name (for example, nic.ddn.mil).
Note that a symbolic host name reference is only valid when it
resolves to only one address. Use of symbolic host names is not
recommended.

If many interface lists are present in the gated.conf file with more
than one parameter, these parameters are collected at run time to cre‐
ate the specific parameter list for a given interface. If the same
parameter is specified on more than one list, the parameters with the
most specific interface are used.

For example, the following interface list is for a system with three
interfaces, le0, le1, and du0:

rip yes {
interface all noripin noripout ;
interface le ripin ;
interface le1 ripout ; } ;

In this example, RIP packets are accepted from interfaces le0 and le1,
but not from du0. RIP packets are sent only on interface le1.

IP Interface Addresses and Routes
The BSD 4.3 and later networking implementations allow the following
four types of interfaces. Some implementations allow multiple protocol
addresses per physical interface, but these are mostly based on BSD 4.3
Reno or later. This interface must have the address of 127.0.0.1.
Packets sent to this interface are sent back to the originator. This
interface is also used as an interface for implementing other features,
such as reject and blackhole routes. Although a netmask is reported on
this interface, it is ignored. It is useful to assign an additional
address to this interface that is the same as the OSPF or BGP router
ID; this allows routing to a system based on the router ID that will
work if some interfaces are down. This is a multiaccess interface
capable of a physical level broadcast, such as Ethernet, Token Ring,
and FDDI. This interface has an associated subnet mask and broadcast
address. The interface route to a broadcast network is a route to the
complete subnet. This is a tunnel to another host, usually on some
sort of serial link. This interface has a local address and a remote
address. Although it may be possible to specify multiple addresses for
a point-to-point interface, there is no useful reason for doing so.

The remote address must be unique among all the interface
addresses on a given router. The local address may be shared
among many point-to-point interfaces and up to one non-point-to-
point interface. This is technically a form of the router ID
method for addressless links. This technique conserves subnets,
because none are required when using this technique.

If a subnet mask is specified on a point-to-point interface, it
is only used by RIP version 1 to determine which subnets may be
propagated to the router on the other side of this interface.
This type of interface is multiaccess, but not capable of broad‐
cast; for example frame relay and X.25. This type of interface
has a local address and a subnet mask.

The gated daemon ensures that there is a route available to each IP
interface that is configured and up. Typically this this done by the
ifconfig command that configures the interface; gated does it to ensure
consistency.

For point-to-point interfaces, gated installs some special routes. If
the local address on one or more point-to-point interfaces is not
shared with a non-point-to-point interface, gated installs a route to
the local address pointing at the loopback interface with a preference
of 110. This ensures that packets originating on this host destined
for this local address are handled locally.

OSPF prefers to route packets for the local interface across the point-
to-point link where they will be returned by the router on the remote
end. This is used to verify operation of the link. Because OSPF
installs routes with a preference of 10, these routes override the
route installed with a preference of 110.

If the local address of one or more point-to-point interfaces is shared
with a non-point-to-point interface, gated installs a route to the
local with a preference of 0 that is not installed in the forwarding
table. This prevents protocols like OSPF from routing packets to this
address across a serial interface when this system could be functioning
as a host.

When the status of an interface changes, gated notifies all the proto‐
cols, which take the appropriate action. The gated daemon assumes that
interfaces that are not marked UP do not exist.

The gated daemon ignores any interfaces that have invalid data for the
local, remote, or broadcast addresses or the subnet mask. Invalid data
includes zeros in any field. The gated daemon also ignores any point-
to-point interface that has the same local and remote addresses; it
assumes it is in some sort of loopback test mode.

DEFINITION STATEMENTS
Definition statements are general configuration statements that relate
to all of gated, or at least to more than one protocol. The three def‐
inition statements are autonomoussystem, routerid, and martians. If
used, autonomoussystem, routerid, and martians must appear before any
other type of configuration statement in gated.conf file.

Autonomous System Syntax
autonomoussystem autonomous_systemloops number ;

Sets the autonomous system number of this router to be autonomous_sys‐
tem. This option is required if BGP or EGP are in use. The AS number
is assigned by the Network Information Center (NIC).

The loops parameter is only for protocols supporting AS paths, such as
BGP. It controls the number of times this autonomous system may appear
in an AS path and defaults to 1 (one).

Router ID Syntax
routerid host ;

Sets the router identifier for use by the BGP and OSPF protocols. The
default is the address of the first interface encountered by gated.
The address of a non-point-to-point interface is preferred over the
local address of a point-to-point interface and an address on a loop‐
back interface that is not the loopback address (127.0.0.1) is most
preferred.

Martian Syntax
Sometimes a misconfigured system sends out invalid destination
addresses. These invalid addresses, called martians, are rejected by
the routing software. A martian configuration defines a list of mar‐
tian addresses from which all routing information is ignored. A mar‐
tian configuration is structured as follows:

martians {
host host [allow] ;
network [allow] ;
network mask mask [allow] ;
network masklen number [allow] ;
default [allow] ; } ;

Adds martian addresses to the list of martian addresses. You can spec‐
ify the allow parameter to explicitly allow a subset of a range that
was disallowed. (See the section on "Route Filtering" in gated.con‐
trol(4) for more information on specifying ranges.)

Sample Definition Statements
The following is an example of definition statements for a system:

options gendefault ; autonomoussystem 249 ; interface 128.66.12.2 pas‐
sive ; martians {
0.0.0.26 };

A description of each statement in this example follows: The options
statement tells the system to generate a default route when it peers
with an EGP or BGP neighbor. The autonomoussystem statement tells
gated to use AS number 249 for EGP and BGP. The interface statement
tells gated not to mark interface 128.66.12.2 as down even if it sees
no traffic. The martians statement prevents routes to 0.0.0.26 from
ever being accepted.

EXAMPLES
Sample Host Configurations
The gated.conf file for end systems is simple, usually containing only
two configuration statements. The following sample configuration file
emulates routed, runs RIP, and only sends updates if there is more than
one interface up and IP forwarding is enabled in the kernel:

# rip yes ; #

Note that RIP will not run if UDP checksums are disabled in the
kernel. The following sample gated.conf file runs RIP in quiet
mode; it only listens to packets, no matter how many interfaces
are configured:

# rip yes ; {
nobroadcast ; } ; # The following sample gated.conf file is
suitable for any system that runs RIP and has only one network
interface:

# # do not time-out the network interface # interface
136.66.12.2 passive ; # # enable rip # rip yes ; #

The passive keyword prevents gated from changing the preference
of the route to this interface if it is believed to be down due
to lack of received routing information. The interface passive
statement identifies a router with a guest host on an Ethernet.

In the previous example, the route is through the directly
attached network interface. Normally when gated thinks an
interface is down, it removes it from the routing database to
prevent a gateway from announcing that it can route data through
a nonoperational interface.

If the host has only one interface, it should not be removed
from the routing database even if the interface is down (the
interface 136.66.12.2 passive statement in the example. RIP is
enabled with the rip yes statement. This statement is not
required as it is the default, but the explicit statement in the
gated.conf file serves to document the configuration to prevent
future confusion.

Sample Interior Gateway (Intra-Domain) Configurations
Gateway configurations are more complicated than a simple host configu‐
ration as gateways have multiple interfaces and may run multiple proto‐
cols. This section contains sample gated.conf files for the following
interior gateway configurations: RIP only (subnet to backbone) RIP with
default announcement Direct routes Static routes Importing routes
Exporting routes CIDR Source and trusted gateways OSPF Using NBMA Mode
RIP and OSPF

RIP only (subnet to backbone)

The following sample gated.conf file connects two networks within an
autonomous system. You can use this configuration file for any gateway
that uses only RIP and that connects a single subnet to a larger net‐
work.

# # enable rip # rip yes ; # # using rip, announce subnet 3 via
interface 136.66.1.2 # export proto rip interface 136.66.1.2 {
proto direct
{
announce 136.66.3.0 metric 0 ;
} ; } ; # # using rip, announce all routes learned from interface
136.66.1.2 # export proto rip interface 136.66.3.1 {
proto rip interface 136.66.1.2
{
announce all ;
} ; } ;

In this example, the first export statement tells gated to announce,
via the RIP protocol and interface 136.66.1.2, a direct route to subnet
136.66.3.0. The second export statement announces to subnet 3 all
routes learned from the interface 136.66.1.2, including subnet routes
and any routes to the rest of the world, as well as default routes.

The first export statement is not required because by default gated
announces every network that is directly connected to the gateway. The
export statement was explicitly entered for two reasons: to document
the intended structure and to avoid relying on defaults that might be
changed in future releases.

In any export statement, the main proto clause and the main interface
clause may define the protocol and interface through which the routes
are advertised. Subsidiary proto and interface clauses define the pro‐
tocols and the interfaces from which the routes must be learned.

RIP with default announcement

In the following sample gated.conf file, the gateway announces a
default route to the backbone and announces all of the individual sub‐
net routes to the outside world.

# # enable rip # rip yes ; # # using rip, announce all local subnets
via 136.66.12.3 # export proto rip interface 136.66.12.3 metric 3 {
proto rip interface 136.66.1.5
{
announce all ;
} ; }; # # using rip, announce default to the local backbone
via 136.66.1.5 # export proto rip interface 136.66.3.1 {
proto rip interface 136.66.12.3
{
announce 0.0.0.0 ;
} ; } ;

The first export statement statement explicitly directs gated to
announce all of the routes it learns from interface 136.66.1.5 out
through interface 136.66.12.3. The explicit announce all is not
required. The metric value is specified in the main statement and
applies to every route announced via this protocol and interface. When
the metric is specified in the export clause, it only applies to the
routes specified in that clause. In the previous example, metric 3
applies to every route announced over interface 136.66.12.3 via RIP.

Direct Routes

If a gateway has interfaces on several networks, the following configu‐
ration provides for announcing routes learned via the RIP protocol and
routes to the directly connected networks.

# # enable rip # rip yes;

# # using rip announce all directly connected networks with a metric of
0 # and all routes learned via the rip protocol # export proto rip {
proto direct {
all metric 0;
};
proto rip {
all;
}; };

Static Routes

The following configuration shows how to statically configure certain
routes to point to a particular gateway. Only routes learned via the
RIP protocol and the statically configured routes are announced.

# # enable rip # rip yes;

# # these networks and host are reachable via gateway 192.168.12.1 #
static {
host 192.168.2.1 gateway 192.168.12.1;
192.168.10.0 mask 255.255.255.0 gateway 192.168.12.1;
192.168.11.0 masklen 24 gateway 192.168.12.1; };

# # export via RIP all the statically configured routes and # all
routes learned via RIP # the metric only applies to the static routes #
export proto rip metric 1 {
proto static {
all;
};
proto rip {
all;
}; };

Importing Routes

The following configuration imports routes from the specified gateways.
You might want to do this when you only want to import routes if they
meet certain requirements supplied by a route filter.

# # enable rip # rip yes;

# # import via RIP routes only from these hosts (gateways) # import
proto rip {
host 192.168.10.1;
host 192.168.11.1;
host 192.168.12.1; }

Exporting Routes

The following configuration demonstrates how to filter out certain
routes from being announced:

# # enable rip # rip yes;

# # use the export statement to block out the 14, 15, and 16 # networks
and announce all others # export proto rip {
192.168.14.0 masklen 24 restrict;
192.168.15.0 masklen 24 restrict;
192.168.16.0 masklen 24 restrict;
all; }

CIDR

Because RIP version 1 does not carry netmask information in its pack‐
ets, CIDR is difficult, if not impossible, to convey in RIP version 1
packets. The following configuration RIP version 2 is used to Multi‐
cast its routes. RIP version 2 in RIP version 1 compatibility mode is
not enough. While the netmask information is provided in RIP version 1
compatible packets, routes that might be improperly interpreted by RIP
version 1 will not be broadcasted by RIP version 2.

# # enable rip # turn on broadcast (RIPv2 will not multicast or broad‐
cast without this) # turn on version 2 multicast on each interface #
rip yes {
broadcast;
interface 192.168.10.1 version 2 multicast;
interface 192.168.11.1 version 2 multicast; };

Source and Trusted Gateways

Sometimes you do not want a RIP speaker to broadcast or Multicast (in
the case of RIP version 2) its route announcements. The following con‐
figuration shows how to use the sourcegateways option to unicast the
packets. It also shows how to use the trustedgateways option.

# # enable rip # Send to 10.1, 11.1, and 12.1 but only accept from 10.1
and 11.1 # rip yes {
nobroadcast;
sourcegateways 192.168.10.1 192.168.11.1 192.168.12.1;
trustedgateways 192.168.10.1 192.168.11.1; };

OSPF Using NBMA Mode

In the following sample gated.conf file, a server is configured as both
the area border router and the backbone router. This example has two
areas (0.0.0.1 and 0.0.0.2) besides the OSPF backbone area. In area
0.0.0.1, one other router (interface at 196.1.1.2) is eligible across
the NMBA network to be polled every 30 seconds. In area 0.0.02, two
other routers are listed (194.1.1.2 and 194.1.1.1), only one other
router can engage in OSPF packets with this router (194.1.1.2).

In the backbone area, all routers are polled by default at interval 30.

traceoptions parse ; routerid 195.1.1.2 ; # RIP no ; OSPF yes {
defaults {
preference 10 ;
cost 5 ;
type 1 ;
} ;
area 0.0.0.1 {
networks {
195.1.1.0 ;
} ;
interface 195.1.1.2 nonbroadcast {
routers {
195.1.1.1 eligible ;
195.1.1.2 eligible ;
} ;
priority 15 ;
enable ;
hellointerval 30 ;
routerdeadinterval 30 ;
pollinterval 30 ;
} ;
} ;
area 0.0.0.2 {
networks {
193.2.1.0 ;
194.1.1.0 ;
} ;
interface 194.1.1.3 nonbroadcast {
routers {
194.1.1.2 eligible ;
194.1.1.3 eligible ;
194.1.1.1 ;
} ;
priority 15 ;
enable ;
hellointerval 30 ;
routerdeadinterval 30 ;
retransmitinterval 30 ;
pollinterval 30 ;
} ;
} ;
backbone {
interface 15.13.115.156 nonbroadcast {
enable ;
transitdelay 20 ;
priority 10 ;
hellointerval 30 ;
routerdeadinterval 30 ;
retransmitinterval 30 ;
pollinterval 30 ;
} ;
} ; } ;

RIP and OSPF

The following sample gated.conf file for AS 283 enables both RIP and
OSPF protocols and can be used for testing RIP and OSPF.

#options noinstall ; interfaces {
interface le0 passive ; } ; autonomoussystem 283 ; snmp yes ; rip yes
{
broadcast ;
defaultmetric 5 ;
interface le version 2 multicast ; } ; ospf yes {
traceoptions lsabuild protocol ;
monauthkey "ZZZZZZZZ" ;
backbone {
interface all {
priority 2 ;
} ;
interface le {
auth simple "YYYYYYYY" ;
} ;
} ; } ; static {
default gateway 132.236.200.200 preference 140 retain ; }

In the RIP version 2 case, multicast packets are generated on all Eth‐
ernet interfaces (for example, le0, le1, and so on). This is a safe
way to test RIP because the production gateways on this network do not
support RIP version 2. In the OSPF case, all interfaces are configured
to be Priority 2, so the Proteon routers (Priority 0) become designated
routers. A simple password is specified "YYYYYYYY" for authentication
of all Ethernet interfaces (the only kind of interfaces in this config‐
uration).

Sample Exterior Gateway (Inter-Domain) Configurations
This section contains sample gated.conf files for the following exte‐
rior gateway configurations: RIP and EGP BGP and OSPF

RIP and EGP Configuration

The following sample gated.conf file enables both an interior (RIP) and
an exterior (EGP) protocol and sets certain protocol-specific parame‐
ters:

# generate a default route if an EGP neighbor is acquired # options
gendefault ; # # define the autonomous system number for EGP #
autonomoussystem 303 ; # # enable RIP # rip yes ; # # enable EGP with
hello interval 1 1/2 minute, poll # interval 10 minutes, neighbors
26.6.0.103 and 26.20.0.72 # egp yes {
packetsize 24488 ;
group minhello 1:30 minpoll 10:00 {
neighbor 26.6.0.103 ;
neighbor 26.20.0.72 ;
} ; } ; # # announce 136.66 to AS 183 # export proto egp as 183 {
proto direct {
136.66 metric 0 ;
} ; } ; # # announce default via RIP with a metric of 3 # export
proto rip interface 136.66.12.1 {
proto default {
announce 0.0.0.0 metric 3 ;
} ; } ;

The AS number 303 is defined early because it is a definition statement
and must occur before the first protocol statement. EGP is enabled by
the yes keyword in the EGP statement, which also defines the following
EGP parameters: the packetsize parameter, defining the initial size of
update packets accepted; the group clause, setting parameters for all
of the EGP neighbors in the group; and minhello and minpoll, setting
the protocol timers.

The first export statement directs gated to use EGP to advertise the
network (136.66.0.0) to the Internet. This is the address of the net‐
work, not of a gateway. The second export statement is used to
announce the default route to subnet 136.66.12.0 with a metric of 3.

BGP and OSPF Configuration

The following sample gated.conf file implements the transformation of
distance metrics between the internal (OSPF) and external (BGP) proto‐
cols. Autonomous system 1019, of which gated is a member, contains
network 19.0.0.0. The gated machine has several interfaces into this
autonomous system. The gated daemon is using BGP to peer with AS 2021,
neighbor 21.5.1.21.

/etc/gated.conf # # # # # # # # # # # # # # # # # # # interfaces
{options all passive; }; autonomoussystem 1019; routerid 19.1.1.18; rip
no; hello no; egp no; bgp yes {
preference 50 ;
group type
External peeras 2021
{

peer 21.5.1.21
;
} ;
group type
IGP peeras 1019
{

peer 19.1.1.19
;
} ; } ; ospf yes {
area 0.0.0.2 {
authtype none;
networks {
119.0.0.0 mask 255.0.0.0 ;
} ;
interface 119.2.128.18
cost 1 {
retransmitinterval 5;
transitdelay 1;
priority 1;
hello interval 10;
routerdeadinterval 40;
} ;
interface 119.4.128.18
cost 1 {
retransmitinterval 5;
transitdelay 1;
priority 1;
hellointerval 60;
routerdeadinterval 180;
} ;
} ;
backbone {
authtype none;
interface 19.1.1.19
cost 1 {
retransmitinterval 5;
transitdelay 1;
priority 1;
hellointerval 60;
routerdeadinterval 180;
} ;
} ; } ; export proto ospfase type 1 {
proto bgp as 2021 {
ALL
metric 1; };
proto direct {
ALL
metric 1; }; } ; export proto bgp as 2021 {
proto direct {
ALL
metric 1; } ;
proto ospfase {
ALL
metric 1; } ; } ;

In this example, two autonomous systems (one internal, one external)
are directly connected through a router that is attached to a backbone
speaking OSPF. The AS number 1019 is defined early as it is a defini‐
tion statement that occurs again in the first protocol statement, which
enables BGP. The first export statement directs gated to advertise
routes from the internal group AS 1019 running OSPF as the IGP gather‐
ing routing information to the external group AS 2021 using BGP.

Routes to two local Ethernets in AS 1019, identified as 119.2.128.18
and 119.4.128.18 (119.0.0.0 mask 255.0.0.0), are advertised along with
the OSPF backbone (19.1.1.19). The parameters for AS path, path ori‐
gin, and transitive optional attributes, including transmission inter‐
vals, are defined. The second export statement announces the default
route to AS 2021 with a metric of 1.