gated.conf - Gate daemon configuration file (general
information)
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 Administration 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 [Toc] [Back]
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 indicates 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 [Toc] [Back]
The configuration statements and the order in which they
must appear in the gated.conf file are as follows: options
statements interface statements definition statements protocol
statements static statements control statements
aggregate statements
Entering a statement out of order causes an error when
parsing the configuration file.
Two other types of statements do not fit in these categories:
%directive 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 [Toc] [Back]
The following table lists each gated.conf configuration
statement by name, identifies the statement type, and
gives a synopsis of the statement'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 general
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 [Toc] [Back] 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 destination 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 cannot be used to control the selection of routes
within an interior gateway 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 [Toc] [Back]
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 [Toc] [Back]
A default preference is assigned to each source from which
gated receives routes. Preference values range from 0 to
255, with the lowest 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 [Toc] [Back]
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 keyword 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 [Toc] [Back]
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 [Toc] [Back] 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 protocol-specific tracing
options. Unless overridden, tracing options from the next
higher level are inherited by lower levels. For example,
Border 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 [Toc] [Back]
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 specification is 2). Specifies options
that control the appearance of tracing. The only valid
value is nostamp, which specifies that a time stamp should
not be prepended to all trace lines. See the Global Tracing
Options section for more information. Enables a broad
class of tracing and then disables more specific options.
See the Global Tracing Options section for more information.
Specifies that all tracing should be turned off for
this protocol or peer.
Global Tracing Options [Toc] [Back]
There are two types of global options: those with global
significance and those with protocol significance.
Global Significance [Toc] [Back]
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 kernel
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 [Toc] [Back]
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 [Toc] [Back]
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 subset
of packet types. These tracing options can be further
controlled with the following modifiers: Specifies a more
verbose format to provide 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
packets 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 provide direction to the gated configuration
language 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 directive
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 current 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 directive
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 advantages of gated is that it
combines the configuration of several different routing
protocols into a single file. Segmenting a small file
unnecessarily complicates routing configurations.
The options statement allows specification of some global
options. If used, the options statement must appear
before any other type of configuration statement in the
gated.conf file.
Syntax [Toc] [Back]
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
protocols. 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; symbolic names result
in configuration file errors. Controls the amount
of data gated logs via syslog on systems where setlogmask()
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 running.
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 configuration
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 interface. 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 [Toc] [Back]
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 interfaces: 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 message
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 interfaces using the interface
option. Sets interface options on the specified 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 preference for routes to this interface when
it is up and appears to be functioning properly. The
default preference is 0. Sets the preference for routes
to this interface when gated does not believe it to be
functioning 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 configuration
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 systems 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/blackhole
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 statement references the address of the host on the
remote end of the interface, 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. Specifies
that the interface is multicast capable.
Interface Lists [Toc] [Back]
An interface list is a list of references to interfaces or
groups of interfaces. The following four methods, from
most general to most specific, are available for referring
to interfaces: Refers to all available 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 characters 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 create the specific parameter list
for a given interface. If the same parameter is specified
on more than one list, the parameters with the most specific
interface are used.
For example, the following interface list is for a system
with three interfaces, le0, le1, and du0:
rip yes {
interface all noripin noripout ;
interface le ripin ;
interface le1 ripout ; } ;
In this example, RIP packets are accepted from interfaces
le0 and le1, but not from du0. RIP packets are sent only
on interface le1.
IP Interface Addresses and Routes [Toc] [Back]
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-topoint
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 broadcast; 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-topoint
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 protocols, which take the appropriate action. The
gated daemon assumes that interfaces that are not marked
UP do not exist.
The gated daemon ignores any interfaces that have invalid
data for the local, remote, or broadcast addresses or the
subnet mask. Invalid data includes zeros in any field.
The gated daemon also ignores any point-to-point interface
that has the same local and remote addresses; it assumes
it is in some sort of loopback test mode.
DEFINITION STATEMENTS [Toc] [Back] Definition statements are general configuration statements
that relate to all of gated, or at least to more than one
protocol. The three definition statements are
autonomoussystem, routerid, and martians. If used,
autonomoussystem, routerid, and martians must appear
before any other type of configuration statement in
gated.conf file.
Autonomous System Syntax [Toc] [Back]
autonomoussystem autonomous_systemloops number ;
Sets the autonomous system number of this router to be
autonomous_system. 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 [Toc] [Back]
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-topoint
interface is preferred over the local address of a
point-to-point interface and an address on a loopback
interface that is not the loopback address (127.0.0.1) is
most preferred.
Martian Syntax [Toc] [Back]
Sometimes a misconfigured system sends out invalid destination
addresses. These invalid addresses, called martians,
are rejected by the routing software. A martian
configuration defines a list of martian addresses from
which all routing information is ignored. A martian configuration
is structured as follows:
martians {
host host [allow] ;
network [allow] ;
network mask mask [allow] ;
network masklen number [allow] ;
default [allow] ; } ;
Adds martian addresses to the list of martian addresses.
You can specify the allow parameter to explicitly allow a
subset of a range that was disallowed. (See the section
on "Route Filtering" in gated.control(4) for more information
on specifying ranges.)
Sample Definition Statements [Toc] [Back]
The following is an example of definition statements for a
system:
options gendefault ; autonomoussystem 249 ; interface
128.66.12.2 passive ; 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.
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 [Toc] [Back]
Gateway configurations are more complicated than a simple
host configuration as gateways have multiple interfaces
and may run multiple protocols. 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) [Toc] [Back]
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 network.
# # 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 protocols and the
interfaces from which the routes must be learned.
RIP with default announcement [Toc] [Back]
In the following sample gated.conf file, the gateway
announces a default route to the backbone and announces
all of the individual subnet 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 [Toc] [Back]
If a gateway has interfaces on several networks, the following
configuration 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 [Toc] [Back]
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 [Toc] [Back]
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 [Toc] [Back]
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 [Toc] [Back]
Because RIP version 1 does not carry netmask information
in its packets, CIDR is difficult, if not impossible, to
convey in RIP version 1 packets. The following configuration
RIP version 2 is used to Multicast 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 broadcast 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 [Toc] [Back]
Sometimes you do not want a RIP speaker to broadcast or
Multicast (in the case of RIP version 2) its route
announcements. The following configuration 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 [Toc] [Back]
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 [Toc] [Back]
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 Ethernet 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 configuration).
Sample Exterior Gateway (Inter-Domain) Configurations [Toc] [Back]
This section contains sample gated.conf files for the following
exterior 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 parameters:
# 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 gro
|
