The /etc/gated.conf configuration file for
gated(ADMN)
consists of a sequence of statements terminated
by a semi-colon (;). Statements are composed of tokens
separated by white space, which can be 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 may be specified in either of two forms. One
form begins with a pound sign (#) and runs to the end
of the line. The other form, ``C''-style, starts with a ``/*''
and continues until it reaches ``*/''.
Statement grouping
The configuration statements and the order in which these
statements appear in gated.conf are:
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
and
%trace.
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.
Statement summary
The gated configuration commands are summarized below.
More detailed definitions and descriptions of each of the eight classes of
gated statements follow in separate sections.
Command
Type
Description
%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
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
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
Preference
Preference is the value gated uses to order preference of routes
from one protocol or peer over another. Preference can be set
in the gated configuration files in several different
configuration statements.
Preference can be set based on network interface over another, from
one protocol over another, or from one remote gateway over another.
Preference may not be used to control the selection of routes within
an igp, this is accomplished automatically by the
protocol based on metric. Preference may be used to select routes
from the same egp learned from different peers or
autonomous systems.
Each route has only one preference value associated with it, even
though preference can be set at many places in the configuration file.
Simply, the last or most specific preference value set for a route is the
value used.
The preference value is an arbitrarily assigned value used
to determine 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''.
The following algorithm is used to select a route:
The route with the best (numerically smallest) preference 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.
A route learned from a igp is preferred to a
route learned from an egp. Least preferred is a route
learned indirectly by an igp from an
egp.
If AS path information is available it is used to help determine
the most preferred route:
4a.
A route with an AS path is preferred over one without
an AS path.
4b.
If the AS paths and origins are identical, the route with
the lower metric is preferred.
4c.
A route with an AS path origin of igp is
preferred over a route with an AS path origin of
egp. Least preferred is an AS path with
an unknown origin.
4d.
A route with a shorter AS path is preferred.
If both routes are from the same protocol and AS, the one with
the lowest metric is preferred.
The route with the lowest numeric next-hop address is used.
Assigning preferences
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 summarizes the default preference values for routes
learned in various ways. The table lists the statements (some of these are
clauses within statements) that set preference, and shows the types of
routes to which each statement applies. The default preference for each
type of route is listed, and the table notes preference precedence between
protocols. The narrower the scope of the statement, the higher precedence
its preference value is given, but the smaller the set of routes it
affects.
In these 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 128.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.
Trace statements
Trace statements control tracing options.
gated'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, 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.
Global tracing options
There are two types of global options, those which only affect global
operations and those which have potential significance to protocols.
The trace flags that only have global significance are:
parse
Trace the lexical analyzer and parser. Mostly used by gated
developers for debugging.
adv
Trace the allocation of and freeing of policy blocks. Mostly
used by the gated developers for debugging.
symbols
Used to trace symbols read from the kernel at startup. The only
useful way to specify this level of tracing is via the
-t option on the command line since the symbols are
read from the kernel before parsing the configuration file.
iflist
Used to trace the reading of the kernel interface list. It is
useful to specify this with the -t option on the
command line since the first interface scan is done before
reading the configuration file.
The options flags that have potential significance to protocols are:
all
Turn on all of the following.
general
A shorthand notation for specifying both normal and
route.
state
Trace state machine transitions in the protocols.
normal
Trace normal protocols occurrences. Abnormal protocol
occurrences are always traced.
policy
Trace application of protocol and user-specified policy to routes
being imported and exported.
task
Trace system interface and processing associated with this
protocol or peer.
timer
Trace timer usage by this protocol or peer.
route
Trace routing table changes for routes installed by this protocol
or peer.
NOTE:
Not all of the above 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 currently possible to specify packet tracing from the
command line. This is 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 effect 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
Tracing of packets is very flexible. For any given protocol there are
one or more options for tracing packets. All protocols allow use of
the packets keyword 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:
detail
Normally packets are traced in a
terse form of one or two lines. When detail
is specified, a more verbose format is used
to provide further details about the contents of
the packet.
send
recv
These options limit the tracing to packets
sent or received. Without these options both sent and received
packets will be traced.
NOTE:detail, if specified, must be before send or
recv. If a protocol allows for several different types
of packet tracing, modifiers may be applied to each individual type.
But be aware that within one tracing specification the trace flags are
summed up, so specifying detail packets will turn on full
tracing for all packets.
Specifies the file to receive tracing information. If this file
name does not begin with a slash (/) the directory
where gated was started in prepended to the name.
replace
Tracing should start by replacing an existing file. The default
is to append to an existing file.
sizesize[k|m] filesfiles
Limit the maximum size of the trace file to the specified size
(minimum 10k). 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).
control_options
Specifies options that control the appearance of tracing. Valid
values are:
nostamp
Specifies that a timestamp should not be prepended to all trace
lines.
excepttrace_options
Used to enable a broad class of tracing and then disable more
specific options.
none
Specifies that all tracing should be turned off for this protocol
or peer.
Directive statements
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:
%directorydirectory
Defines the directory where the include files are stored. When
it is used, gated looks in the directory identified by pathname
for any included files that do not have a fully qualified
filename that is, do not begin with ``/''. This statement does not
actually change the current directory, it just specifies the
prefix applied to included file names.
%includefilename
Identifies an include file. The contents of the file is
included in the gated.conf file at the point
where the %include directive is
encountered. If the filename is not fully qualified, that is, 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.
In a complex environment, segmenting a large configuration into smaller
more easily understood segments might be helpful, but one of the great
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.
Options statements
Options statements allow specification of some global options. If used,
options must appear before any other type of configuration
statement in the gated.conf file.
When gendefault is enabled, when a BGP or EGP
neighbor is up, it causes the creation of a default route with the
special protocol default. 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 will be installed in the kernel forwarding table with a
next hop of the listed gateway.
Note that the use of the more general option is preferred to the use of
this gendefault option. The gendefault
option may go away in future releases. See
``Route aggregation''
for more information on the
generate statement.
nosend
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 most useful for RIP and
possibly the SMUX SNMP interface. This option does not yet apply
to BGP and is less than useful with EGP and OSPF.
noresolv
By default gated will try 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 hosts local host and network tables. If there is
insufficient routing information to send DNS queries, gated will
deadlock during startup. This option can be used to prevent
these calls, symbolic names will result in configuration file
errors.
syslog [ upto ] log_level
Controls the amount of data gated logs via syslog.
The available logging levels
and other terminology are as defined on the
syslog(SLIB)
manual page. The default is equivalent
to syslog upto info.
marktime
Specifying this option causes gated to output a message to the
trace log at the specified interval. This can be used as one
method of determining if gated is still running.
An interface is the connection between a router and one of its
attached networks. A physical interface may 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
wildcard, interface type name, or delete word address. Be careful
with the use of interface names as it is possible to have
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 which may specify more than one interface
or address, or the token all for all interfaces.
options
Allows configuration of some global options related to
interfaces. These are:
strictinterfaces
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 will be issued but gated will continue.
scanintervaltime
Specifies how often gated scans the kernel interface list
for changes. The default is every 15 seconds.
Note that gated will also scan the interface list on
receipt of a SIGUSR2.
interfaceinterface_list
Sets interface options on the specified interfaces. An interface
list is all or a list of interface names (see
warning about interface names), domain names, or numeric
addresses. Options available on this statement are:
preferencepreference
Sets the preference for routes to this interface when it
is up and appears to be functioning properly. The
default preference is 0.
down preferencepreference
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.
passive
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.
gated will only perform this check if the interface is
actively participating in a routing protocol.
simplex
Defines an interface as unable to hear its own broadcast
packets. Some systems define an interface as simplex
with the IFF_SIMPLEX flag, on others it needs to be
specified in the configuration file. On simplex
interfaces, packets from myself are assumed to have been
looped back in software and are not used as an indication
that the interface is functioning properly.
defineaddress
Defines interfaces that might not be present when gated is
started so they may be referenced in the configuration file when
strictinterfaces is defined. Possible
define keywords are:
broadcastaddress
Defines the interface as broadcast capable (for example, Ethernet
or Token Ring) and specifies the broadcast address.
pointopointaddress
Defines the interface as a pointopoint 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.
netmaskmask
Specifies the subnetmask to be used on this interface.
This is ignored on pointtopoint interfaces.
multicast
Specifies that the interface is multicast capable.
Interface list specification
An interface list is a list of references to interfaces or groups of
interfaces. There are four methods available for referring to
interfaces. They are listed here from the most general to the most specific.
all
This refers to all available interfaces.
Interface name wildcard
This refers to all the interfaces of the same type.
DLPI and ODI interface names
consist of the name of the device driver, such as
ie or TCM5X9_, and a unit number such as 0 or
1.
MDI interface names
consist of the token net, and a unit number such as 0 or
1.
Reference to the name contain
only alphabetic characters and match any interfaces that have the
same alphabetic part.
For example, ie would match ie0 or ie1,
but it would not match iel0.
Interface name
This 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
(that is, IP) address on a given physical interface.
For example, ef1 will match an interface named
ef1, but not an interface named ef10.
Interface address
This matches one specific interface. The reference can be by
protocol address (that is, 10.0.0.51), or by symbolic
host name (that is, 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 config 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 is used.
For example, consider a system with three interfaces,
le0, le1 and du0.
rip yes {
interface all noripin noripout ;
interface le ripin ;
interface le1 ripout ;
} ;
RIP packets would only be accepted from interfaces le0
and le1, but not from du0. RIP packets
would only be sent on interface le1.
IP interface addresses and routes
loopback
This interface must have the address of
127.0.0.1. Packets sent to this interface are
sent back to the originator. This interface is also used as a
catch all 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 which will
work if some interfaces are down.
broadcast
This is a multi-access 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 an broadcast
network will be a route to the complete subnet.
point-to-point
This is a tunnel to another host, usually on some sort
of serial link. This interface has a local
address, and a remote address. Although it may be
possible to specify multiple addresses for a
point-to-point interface, there does not seem to be a
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 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 as 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.
non-broadcast multi-access or nbma
This type of interface is multi-access, but not capable of broadcast.
gated insures that there is a route available to each
IP interface that is configured and up.
Normally 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 insures 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. Since OSPF installs routes with a preference
of 10, these routes will 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 will not be installed in the forwarding table. This is to
prevent 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. gated assumes that
interfaces which are not marked UP do not exist. While this
might not be the most correct action, it is the way things currently
work.
gated 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.
gated will also ignore 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
definition statements are autonomoussystem,
routerid and martians. If used,
autonomoussystem, routerid and
martians must appear before any other type of
configuration statement in the gated.conf file.
Autonomous system configuration
This statement 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).
loops 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 configuration
This statement sets the router identifier for use by the BGP
and OSPF protocols:
routeridhost;
The default is the address of the first interface encountered by
gated. The address of a non-point-to-point interface is preferred
over the local address of a point-to-point interface and an address on
a loopback interface that is not the loopback address (127.0.0.1) is
most preferred.
Defines a list of martian 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 additions to the list of martian addresses. See
``Route filtering''
for more information on
specifying ranges.
The allow parameter may be
specified to explicitly allow a subset of a range that was disallowed.
The statements in this example perform the following functions:
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 in 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.
Protocol overview
Routing protocols determine the ``best'' route to each destination and
distribute routing information among the systems on a network. Routing
protocols are divided into two general groups: interior and exterior
protocols.
gated software combines management of the interior and exterior
routing protocols in one software daemon.
Interior routing protocols
Interior protocols are used to exchange reachability information within an
autonomous system (AS). They are referred to as a class by the acronym
igp. There are several interior protocols:
RIP
The Routing Information Protocol, Version 1 and Version 2,
is the most commonly used interior protocol. RIP selects the
route with the lowest metric as the best route. The metric is a
hop count representing the number of gateways through which data
must pass to reach its destination. The longest path that RIP
accepts is 15 hops. If the metric is greater than 15, a
destination is considered unreachable and gated discards the
route. RIP assumes the best route is the one that uses the
fewest gateways, that is, the shortest path, not taking into account
congestion or delay on route.
The RIP version 1 protocol is described in RFC 1058
and the RIP version 2 protocol is described in RFC 1388.
OSPF
Open Shortest Path First is a link-state protocol. OSPF is
better suited than RIP for complex networks with many routers.
OSPF provides equal cost multipath routing.
OSPF is described in RFC 1583, and
the MIB is defined in RFC 1253.
Other related documents are
RFC 1245,
RFC 1246,
and
RFC 1370.
Exterior routing protocols
Exterior protocols are used to exchange routing information between
autonomous systems. Exterior protocols are only required when an
autonomous system must exchange routing information with another autonomous
system. Routers within an autonomous system run an interior routing
protocol like RIP. Only those gateways that connect an autonomous system
to another autonomous system need to run an exterior routing protocol.
There are two exterior protocols currently supported by gated:
EGP
Exterior Gateway Protocol: Originally EGP reachability
information was passed into ARPANET/MILNET ``core'' gateways where
the best routes were chosen and passed back out to all connected
autonomous systems. As the Internet moved toward a less
hierarchical architecture, EGP, an exterior routing protocol
which assumes a hierarchical structure, became less effective.
The EGP protocol is described in
RFC 827 and RFC 904.
BGP
Border Gateway Protocol is replacing EGP as the exterior protocol
of choice. BGP exchanges reachability information between
autonomous systems, but provides more capabilities than EGP. BGP
uses path attributes to provide more information about each route
as an aid in selecting the best route. Path attributes may
include, for example, administrative preferences based on
political, organizational, or security (policy) considerations in
the routing decision. BGP supports nonhierarchical topologies
and can be used to implement a network structure of equivalent
autonomous systems.
BGP version 1 is described in
RFC 1105,
version 2 in
RFC 1163,
version 3 in
RFC 1267.
The version 3 MIB is described in
RFC 1269.
The two documents,
RFC 1164
and
RFC 1268
describe the application of version 2 and three in the internet.
A protocol analysis of and experience with BGP version 3 are
available in
RFC 1265
and
RFC 1266.
RFC 1397
talks about advertising a default route in BGP version 2
and 3.
And finally,
RFC 1403
describes BGP/OSPF interaction.
Other routing protocols
Router Discovery
The Router Discovery protocol is used to inform hosts of the
availability of hosts it can send packets to and is used to
supplement a statically configured default router. This is
the preferred protocol for hosts to run, they are discouraged from
wiretapping routing protocols.
Router Discovery is described in RFC 1256.
Routing Information Protocol (RIP)
One of the most widely used interior routing protocols is the Routing
Information Protocol (RIP). RIP is an implementation of a
distance-vector, or Bellman-Ford routing protocol for local networks.
It classifies routers as active and passive (silent). Active routers
advertise their routes (reachability information) to others; passive
routers listen and update their routes based on advertisements, but do
not advertise. Typically, routers run RIP in active mode, while hosts
use passive mode.
A router running RIP in active mode broadcasts updates at set
intervals. Each update contains paired values where each pair
consists of an IP network address and an integer distance to that
network. RIP uses a hop count metric to measure the distance to a
destination. In the RIP metric, a router advertises directly
connected networks at a metric of 1. Networks which are reachable
through one other gateway are two hops, and so on. Thus, the number of hops
or hop count along a path from a given source to a given destination
refers to the number of gateways that a datagram would encounter along
that path. Using hop counts to calculate shortest paths does not
always produce optimal results. For example, a path with hop count 3
that crosses three Ethernets may be substantially faster that a path
with a hop count 2 that crosses two slow-speed serial lines. To
compensate for differences in technology many routers advertise
artificially high hop counts for slow links.
A RIP routing daemon (such as
route(ADMN))
dynamically builds on information received through RIP updates.
When started up, it issues a REQUEST for routing information
and then listens for responses to the request. If a system configured
to supply RIP hears the request, it responds with a RESPONSE packet
based on information in its routing database. The RESPONSE packet
contains destination network addresses and the routing metric for each
destination.
When a RIP RESPONSE packet is received, the routing daemon takes the information
and rebuilds the routing database adding new routes and ``better''
(lower metric) routes to destinations already listed in the database.
RIP also deletes routes from the database if the next router to that
destination says the route contains more than 15 hops, or if the route
is deleted. All routes through a gateway are deleted if no updates
are received from that gateway for a specified time period. In
general, routing updates are issued every 30 seconds. In many
implementations, if a gateway is not heard from for 180 seconds, all
routes from that gateway are deleted from the routing database. This
180 second interval also applies to deletion of specific routes.
RIP version 2
RIP version 2 (also known as RIPv2 or
RIP II) adds additional
capabilities to RIP.
Some of these capabilities are compatible with
RIP version 1 (also known as RIPv1 or
RIP I) and some are not.
To avoid supplying information to RIPv1
routes that could be mis-interpreted, RIPv2 can only use
non-compatible features when its packets are multicast. On
interfaces that are not capable of IP multicast,
RIPv1 compatible
packets are used that do not contain potentially confusing
information.
Some of the most notable RIPv2 enhancements are:
Next hop.
The ability to advertise a
next hop to use other than the router supplying the routing update.
This is quite useful when advertising a static route to a
dumb router that does not run RIP as it avoids having
packets destined through the dumb router from having to cross a
network twice.
RIPv1 routers will ignore next hop information in
RIPv2 packets.
This may result in packets crossing a network twice, which is
exactly what happens with RIPv1. So this information is provided
in RIPv1 compatible RIPv2 packets.
Network mask.
RIPv1 assumes that all subnetworks of a given network have the
same network mask. It uses this assumption to calculate the
network masks for all routes received. This assumption prevents
subnets with different netmasks from being included in RIP
packets. RIPv2 adds the ability to explicitly specify the
network mask with each network in a packet.
While RIPv1 routers will ignore the
network mask in RIPv2
packets, their calculation of the network mask will quite
possibly be wrong. For this reason, RIPv1-compatible
RIPv2
packets must not contain networks that would be mis-interpreted.
These network must only be provided in natve RIPv2 packets that
are multicast.
Authentication.
RIPv2 packets may also contain one of two types of
authentication string that may be used to verify the validity of
the supplied routing data. Authentication may be used in
RIPv1-compatible RIPv2 packets,
but be aware that RIPv1 routers will
ignore it.
The first method is a simple password in which an authentication
key of up to 16 characters is included in the packet. If this
does not match what is expected, the packet will be discarded.
This method provides very little security as it is possible to
learn the authentication key by watching RIP packets.
The second method is still experimental and may change in
incompatible ways in future releases. This method uses the
MD5 algorithm (see RFC 1321)
to create a crypto-checksum of a RIP packet and an
authentication key of up to 16 characters. The transmitted
packet does not contain the authentication key itself, instead it
contains a crypto-checksum, called the digest. The
receiving router will perform a calculation using the correct
authentication key and discard the packet if the digest does not
match. In addition, a sequence number is maintained to prevent
the replay of older packets. This method provides a much
stronger assurance that routing data originated from a router
with a valid authentication key.
Two authentication methods can be specified per interface.
Packets are always sent using the primary method, but
received packets are checked with both the primary and
secondary methods before being discarded. In addition,
a separate authentication key is used for non-router queries.
RIP version 1 and network masks
RIPv1 derives the network mask of received networks and hosts from
the network mask of the interface the packet via which the packet was
received. If a received network or host is on the same natural
network as the interface over which it was received and that network
is subnetted (the specified mask is more specific than the
natural netmask), the subnet mask is applied to the
destination. If bits outside the mask are set it is assumed to be a
host, otherwise it is assumed to be a subnet.
On point-to-point interfaces, the netmask is applied to the remote
address. The netmask on these interfaces is ignored if it matches the
natural network of the remote address or if it is all ones.
Unlike in previous releases, the zero subnet mask (a network that
matches the natural network of the interface, but has a more specific,
or longer, network mask) is ignored. If this is not desirable, a
route filter may be used to reject it.
The rip statement enables or disables RIP. If the
rip statement is not specified the default is rip
on ;. If enabled, RIP will assume nobroadcast when
there is only one interface and broadcast when there is
more than one.
The options are as follows:
broadcast
Specifies that RIP packets will be broadcast regardless of the
number of interfaces present. This is useful when propagating static
routes or routes learned from anther protocol into RIP. In some
cases, the use of broadcast when only one network
interface is present can cause data packets to traverse a single
network twice.
nobroadcast
Specifies that RIP packets will not be broadcast on attached
interfaces, even if there are more than one.
If a sourcegateways clause is present, routes will still
be unicast directly to that gateway.
nocheckzero
Specifies that RIP should not make sure that reserved fields in
incoming version 1 RIP packets are zero. Normally RIP will reject
packets where the reserved fields are zero.
preferencepreference
Sets the preference for routes learned from RIP. The default
preference is 100. This preference may be overridden by a preference
specified in import policy.
defaultmetricmetric
Defines the metric used when advertising routes via RIP that were
learned from other protocols. If not specified, the default value is
16 (unreachable). This choice of values requires you to explicitly
specify a metric in order to export routes from other protocols into
RIP. This metric may be overridden by a metric specified in export
policy.
Specifies the authentication required of query packets that do
not originate from routers. The default is none.
interfaceinterface_list
Controls various attributes of sending RIP on specific
interfaces. See
``Interface list specification''
for the description of the
interface_list.
Note that if there are multiple interfaces configured on the same
subnet, RIP updates will only be sent from the first one for which
RIP output is configured. This limitation is required because of
the way the kernel operates. It will hopefully be removed
in a future release.
The possible parameters are:
noripin
Specifies that RIP packets received via the specified
interface will be ignored. The default is to listen to
RIP packets on all non-loopback interfaces.
ripin
This is the default. This argument may be necessary
when noripin is used on a wildcard interface
descriptor.
noripout
Specifies that no RIP packets will be sent on the
specified interfaces. The default is to send RIP on all
broadcast and non-broadcast interfaces when in
broadcast mode. The sending of RIP on
point-to-point interfaces must be manually configured.
ripout
This is the default. This argument is necessary when
sending RIP on point-to-point interfaces and
may be necessary when noripin is used on a
wildcard interface descriptor.
metricinmetric
Specifies the RIP metric to add to incoming routes before
they are installed in the routing table. The default is
the kernel interface metric plus 1 (which is the default
RIP hop count). If this value is specified it will be
used as the absolute value, the kernel metric will not be
added. This option is used to make this router prefer
RIP routes learned via the specified interface(s) less
than RIP routes from other interfaces.
metricoutmetric
Specifies the RIP metric to be added to routes that are
send via the specified interface(s). The default is
zero. This option is used to make other routers prefer
other sources of RIP routes over this router.
version 1
Specifies that RIP packets send via the specified
interface(s) will be version 1 packets. This is the
default.
version 2
Specifies that RIP version 2 packets will be sent on the
specified interfaces(s). If IP multicast support is
available on this interface the default is to send full
version 2 packets. If it is not available, version 1
compatible version 2 packets will be sent.
multicast
Specifies that RIP version 2 packets should be multicast
on this interface. This is the default.
broadcast
Specifies that RIP version 1 compatible version 2 packets
should be broadcast on this interface, even if IP
multicast is available.
This defines the authentication type to
use. It applies only to RIP version 2 and is
ignored for RIP-1 packets. The default
authentication type is none. If a
password is specified, the authentication type
defaults to simple. The password
should be a quoted string with between 0 and 16
characters.
If secondary is specified, this defines the
secondary authentication. If omitted, the primary
authentication is specified. The default is primary
authentication of none and no secondary
authentication.
trustedgatewaysgateway_list
Defines the list of gateways from which
RIP will accept updates. The
gateway_list is simply a list of host names or IP
addresses.
By default, all routers on the shared network are trusted to
supply routing information. But if the
trustedgateways clause is specified only updates
from the gateways in the list are accepted.
sourcegatewaysgateway_list
Defines a list of routers to which RIP sends
packets directly, not through multicast or broadcast. This can be
used to send different routing information to specific gateways.
Updates to gateways in this list are not affected by
noripout on the interface.
The policy option logs information whenever a new route is
announced, the metric being announced changes, or a route goes or leaves
holddown.
Packet tracing options (which may be modified with
detail, send or recv):
packets
All RIP packets.
request
RIP information request packets, such as
REQUEST, POLL and
POLLENTRY.
response
RIP RESPONSE packets, which is the type of
packet that actually contains routing
information.
other
Any other type of packet. The only valid
ones are TRACE_ON and TRACE_OFF, both of
which are ignored.
The OSPF protocol
Open Shortest Path Routing (OSPF) is a shortest path first
(SPF) or link-state protocol. OSPF is an interior routing
protocol that distributes routing information between routers in a
single autonomous system. OSPF chooses the least cost path as the
best path. Suitable for complex networks with a large number of
routers, OSPF provides equal cost multipath routing where packets to a
single destination can be sent via more than one interface
simultaneously. In a link-state protocol, each router maintains a
database describing the entire AS topology, which it builds out of the
collected link state advertisements of all routers. Each
participating router distributes its local state (that is, the router's
usable interfaces and reachable neighbors) throughout the AS by
flooding. Each multiaccess network that has at least two attached
routers has a designated router and a backup designated
router. The designated router floods a link state advertisement
for the multiaccess network and has other special responsibilities.
The designated router concept reduces the number of adjacencies
required on a multiaccess network.
OSPF allows networks to be grouped into areas. Routing information
passed between areas is abstracted, potentially allowing a significant
reduction in routing traffic. OSPF uses four different types of
routes, listed in order of preference: intra-area, inter-area, type 1
external and type 2 external. Intra-area paths have destinations
within the same area, inter-area paths have destinations in other OSPF
areas and Autonomous System External (ASE) routes are routes to
destinations external to the AS. Routes imported into OSPF as type 1
routes are supposed to be from igps whose external metrics are directly
comparable to OSPF metrics. When a routing decision is being made,
OSPF will add the internal cost to the AS Border router to the
external metric. Type 2 ASEs are used for egps whose metrics are not
comparable to OSPF metrics. In this case, only the internal OSPF cost
to the AS Border router is used in the routing decision.
From the topology database, each router constructs a tree of the
shortest paths with itself as the root. This shortest-path tree gives
the route to each destination in the AS. Externally derived routing
information appears on the tree as leaves. The link-state
advertisement format distinguishes between information acquired from
external sources and information acquired from internal routers, so
there is no ambiguity about the source or reliability of routes.
Externally derived routing information (for example, routes learned
from EGP or BGP)
is passed transparently through the autonomous system
and is kept separate from OSPF's internally derived data. Each
external route can also be tagged by the advertising router, enabling
a passing of additional information between routers on the borders of
the autonomous system.
OSPF optionally includes type of service (TOS) routing and
allows administrators to install multiple routes to a given
destination for each type of service (for example, low delay or high
throughput.) A router running OSPF uses the destination address and
the type of service to choose the best route to the destination.
OSPF intra- and inter-area routes are always imported into the gated
routing database with a preference of 10. It would be a violation of
the protocol if an OSPF router did not participate fully in the area's
OSPF, so it is not possible to override this. Although it is possible
to give other routes lower preference values explicitly, it is
ill-advised to do so.
Hardware multicast capabilities are also used where possible to
deliver link-status messages.
OSPF areas are connected by the backbone area, the area with
identifier 0.0.0.0. All areas must be logically contiguous and the
backbone is no exception. To permit maximum flexibility, OSPF allows
the configuration of virtual links. These allow the backbone area
to appear contiguous despite the physical reality.
All routers in an area must agree on that area's parameters. A
separate copy of the link-state algorithm is run for each area.
Because of this, most configuration parameters are defined on a per
area basis. All routers belonging to an area must agree on that
area's configuration. Misconfiguration will lead to adjacencies not
forming between neighbors, and routing information might not flow, or
even loop.
Authentication
All OSPF protocol exchanges are authenticated. Authentication
guarantees that routing information is only imported from trusted
routers, to protect the Internet and its users.
There are two
authentication schemes available. The first uses a simple
authentication key of up to 8 characters and is standardized. The
second is still experimental and uses the MD5 algorithm
and an authentication key of up to 16 characters.
Only a single scheme may be configured for each area.
This allows some areas to use much
stricter authentication than others.
The simple password provides very little protection because in many
cases it is possible to easily capture packets from the network and
learn the authentication key. The experimental MD5 algorithm provides
much more protection as it does not include the authentication key in
the packet.
The OSPF specification currently specifies that the authentication
type be configured per area with the ability to configure separate
passwords per interface. This has been extended to allow the
configuration of different authentication types and keys per
interface. In addition it is possible to specify both a
primary and a secondary authentication type and key
on each interface. Outgoing packets use the primary authentication
type, but incoming packets may match either the primary or secondary
authentication type and key.
The following are the interface_parameters referred to
above. The may be specified on any class of interface and are
described under the interface
clause.
The parameters to defaults
specify the defaults used when importing OSPF
ASE routes into the gated
routing table and exporting routes from the
gated routing table into OSPF ASEs.
preferencepreference
The preference is used to determine how OSPF routes compete with
routes from other protocols in the gated routing table.
The default value is 150.
costcost
The cost is used when exporting a non-OSPF route from the
gated routing table into OSPF as an ASE.
The default value is 1. This may be explicitly overridden in export
policy.
tag [ as ] tag
OSPF ASE routes have a 32-bit tag field that is not used
by the OSPF protocol, but may be used by export policy to
filter routes. When OSPF is interacting with an egp, the
tag field may be used to propagate AS path information,
in which case the as keyword is specified
and the tag is limited to 12 bits of information. If not
specified, the tag is set to zero.
type1 | 2
Routes exported from the gated routing table into OSPF
default to becoming type 1 ASEs. This default may be
explicitly changed here and overridden in export policy.
Because of the nature of OSPF, the rate at which ASEs are
flooded must be limited. The following two parameters can be used to adjust
those rate limits:
exportintervaltime
This specifies how often a batch of ASE link state
advertisements will be generated and flooded into OSPF.
The default is once per second.
exportlimitroutes
This parameter specifies how many ASEs will be generated
and flooded in each batch. The default is 100.
OSPF state may be queried using the ospf_monitor
(this should be a hyperlink) utility. This utility sends non-standard
OSPF packets which generate a text response from OSPF. By default
these requests are not authenticated, if an authentication key is
configured, the incoming requests must match the specified
authentication key. No OSPF state may be changed by these packets,
but the act of querying OSPF can utilize system resources.
backbone
areaarea
Each OSPF router must be configured into at least one OSPF area.
If more than one area is configured, at least one must be the
backbone. The backbone may only be configured using the
backbone keyword, it may not be specified as
area 0. The backbone interface may be a
virtuallink.
authtype0 | 1 | none | simple
OSPF specifies an authentication scheme per area. Each
interface in the area must use this same authentication
scheme although it may use a different
authenticationkey. The currently valid
values are none (0) for no
authentication, or simple (1)
for simple password authentication.
stub [ costcost]
A stub area is one in which there are no ASE
routes. If a cost is specified, this is
used to inject a default route into the area with the
specified cost.
networks
The networks list describes the scope of an
area. Intra-area LSAs that fall within the specified
ranges are not advertised into other areas as inter-area
routes. Instead, the specified ranges are advertised as
``summary network'' LSAs. If
restrict is specified, the summary
network LSAs are not advertised. Intra-area LSAs
that do not fall into any range are also advertised as
summary network LSAs. This option is very useful on well
designed networks in reducing the amount of routing
information propagated between areas. The entries in
this list are either networks, or a subnetwork/mask pair.
See
``Route filtering''
for more details about specifying ranges.
stubhosts
This lists specifies directly attached hosts that should
be advertised as reachable from this router and the
costs they should be advertised with. Point-to-point
interfaces on which it is not desirable to run OSPF
should be specified here.
It is also useful to assign an additional address to the
loopback interface (one not on the 127 network) and
advertise it as a stub host. If this address is the
same one used as the router-id it enables routing to OSPF
routers by router-id, instead of by interface address.
This is more reliable than routing to one of the routers
interface addresses which may not always be reachable.
interfaceinterface_list [costcost ]
This form of the interface clause is used to configure a
broadcast (which requires IP multicast support) or a
point-to-point interface. See
``Interface list specification''
for the description of the format of
interface_list.
Each interface has a cost. The costs of all
interfaces a packet must cross to reach a destination are summed
to get the cost to that destination. The default cost is one,
but another non-zero value may be specified.
Interface parameters common to all types of interfaces are:
retransmitintervaltime
The number of seconds between link state
advertisement retransmissions for adjacencies
belonging to this interface.
transitdelaytime
The estimated number of seconds required to
transmit a link state update over this
interface. transitdelay takes into account
transmission and propagation delays and must
be greater than 0.
prioritypriority
A number between 0 and 255 specifying the
priority for becoming the designated router on
this interface. When two routers attached to
a network both attempt to become designated
router, the one with the highest priority
wins. A router whose router priority is set
to 0 is ineligible to become designated
router.
hellointervaltime
The length of time, in seconds, between Hello
packets that the router sends on the
interface.
routerdeadintervaltime
The number of seconds not hearing a
router's Hello packets before the router's
neighbors will declare it down.
authkeyauth_key
Used by OSPF authentication
to generate and verify the authentication
field in the OSPF header. The authentication
key can be configured on a per interface
basis. It is specified by 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.
Point-to-point interfaces also support this additional parameter:
nomulticast
By default, OSPF packets to neighbors on point-to-point
interfaces are sent via the IP multicast mechanism.
If the use of IP multicasting is not desired because the
remote neighbor does not support it, the
nomulticast parameter may be specified
to force the use of unicast OSPF packets.
interfaceinterface_listnonbroadcast [costcost ]
This form of the interface clause is used to specify a
nonbroadcast interface on a non-broadcast
multi-access (NBMA) media. Since an OSPF
broadcast media must support IP multicasting, a
broadcast capable media, such as Ethernet, that does not support
IP multicasting must be configured as a non-broadcast interface.
A non-broadcast interface supports any of the standard
interface clauses listed
above, plus the following two that are specific to non-broadcast
interfaces:
pollintervaltime
Before adjacency is established with a neighbor, OSPF
packets are sent periodically at the specified
pollinterval.
routers
By definition it is not possible to send broadcast
packets to discover OSPF neighbors on a non-broadcast, so
all neighbors must be configured. The list includes one
or more neighbors and an indication of their eligibility
to become a designated router.
virtuallinkneighboridrouter_idtransitareaarea
Virtual links are used to establish or increase connectivity of
the backbone area. The neighborid is the
router_id of the other end of the virtual link. The
transit area specified must also be configured on this
system. All standard interface parameters defined by the
interface clause above may be
specified on a virtual link.
OSPF tracing options
In addition to the following OSPF specific trace flags,
OSPF supports
the state which traces interface and neighbor state
machine transitions.
lsabuild
Link State Advertisement creation
spf
Shortest Path First (SPF) calculations
Packet tracing options (which may be modified with
detail, send and recv):
dd
OSPF Database Description packets which are
used in synchronizing OSPF databases.
request
OSPF Link State Request packets which are
used in synchronizing OSPF databases.
lsu
OSPF Link State Update packets which are used
in synchronizing OSPF databases.
ack
OSPF Link State Ack packets which are used in
synchronizing OSPF databases.
The Exterior Gateway Protocol (EGP)
The Exterior Gateway Protocol (EGP) is an exterior routing protocol
used for exchanging routing information with gateways in other
autonomous systems. Unlike interior protocols, EGP propagates only
reachability indications, not true metrics. EGP updates contain
metrics, called distances which range from 0 to 255. gated
will only compare EGP distances learned from the same AS.
Before EGP sends routing information to a remote router, it must
establish an adjacency with that router.
This is accomplished by an
exchange of Hello (not to be confused with the unsupported HELLO
protocol, or OSPF HELLO messages) and I Heard You (I-H-U)
messages with that router.
Computers communicating via EGP are called
EGP neighbors, and the exchange of HELLO
and I-H-U messages is
referred to as acquiring a neighbor.
Once the neighbor is acquired,
the system polls the neighbor for routing information.
The neighbor
responds by sending an update containing routing information.
If the system receives a poll from
its neighbor, it responds with its own update packet. When the system
receives an update, it includes routes from the update into its
routing database. If the neighbor fails to respond to three
consecutive polls, gated assumes that
the neighbor is down and removes
the neighbor's routes from its database.
Sets the preference for routes learned from RIP. The default
preference is 200. This preference may be overridden by a
preference specified on the group or
neighbor statements or by import policy.
defaultmetricmetric;
Defines the metric used when advertising routes via EGP. If not
specified, the default value is 255 which some systems may
consider unreachable. This choice of values requires you to
explicitly specify a metric when exporting routes to EGP
neighbors. This metric may be overridden by a metric specified
on the neighbor or group statements or in export policy.
packetsizemaxpacketsize
This defines the expected maximum size of a packet that EGP
expects to receive from this neighbor. If a packet larger than
this value is received, it will be incomplete and have to be
discarded. The length of this packet will be noted and the
expected size will be increased to be able to receive a packet of
this size. Specifying the parameter here will prevent the first
packet from being dropped. If not specified, the default size is
8192 bytes. All packet sizes are rounded up to a multiple of the
system page size.
traceoptionstrace_options
Specifies the tracing options for EGP. By default these are
inherited from the global trace options. These values may be
overridden on a group or neighbor basis. (See
``Trace statements''
and
``EGP tracing options''.)
group
EGP neighbors must be specified as members of a
group. A group is usually used to group all
neighbors in one autonomous system. Parameters specified on the
group clause apply to all of the subsidiary neighbors unless
explicitly overridden on a neighbor clause. Any number of
group clauses may specify any number of
neighbor clauses.
Any parameters from the neighbor subclause may be
specified on the group clause to provide defaults
for the whole group (which may be overridden for individual
neighbors). In addition, the group clause is the
only place to set the following attributes:
peeras
Identifies the autonomous system number expected from peers
in the group. If not specified it will be learned
dynamically.
localas
Identifies the autonomous system which gated is representing
to the group. The default is that which has been set
globally in the autonomoussystem
statement. This option is usually only used when
masquerading as another autonomous system and its
use is discouraged.
maxup
Specifies the number of neighbors gated should acquire from
this group. The default is to acquire all of the neighbors
in the group. gated will attempt to acquire the first
maxup neighbors in the order listed. If one of
the first neighbors is not available, it will acquire one
further down the list. If after start-up gated does manage
to acquire the more desirable neighbor, it will drop the
less desirable one.
neighborneighbor_address
Each neighbor subclause defines one EGP neighbor within a group.
The only part of the subclause that is required is the
neighbor_address argument which is the symbolic host
name or IP address of the neighbor. All other parameters are
optional.
preferencepreference
Specifies the preference used for routes learned from
these neighbors. This can differ from the default EGP
preference set in the egp statement, so that
gated can prefer routes from one neighbor, or group of
neighbors, over another. This preference may be explicitly
overridden by import policy.
preference2preference
In the case of a preference tie, the second
preference, preference2 may be used to break the
tie. The default value is 0.
metricoutmetric
This defines a metric to be used for all routes sent to this
neighbor. The value overrides the default metric set in the
egp statement and any metrics specified by
export policy, but only for this specific neighbor or group
of neighbors.
nogendefault
Prevents gated from generating a default route when EGP
receives a valid update from its neighbor. The default route
is only generated when the gendefault option is enabled.
importdefault
Enables gated to accept the default route (0.0.0.0) if it is
included in a received EGP update. If not specified, the
default route contained in an EGP update is ignored. For
efficiency, some networks have external routers announce a
default route to avoid sending large EGP update packets.
exportdefault
Enables gated to include the default route (0.0.0.0) in EGP
updates sent to this EGP neighbor. This allows the system to
advertise the default route via EGP. Normally a default route
is not included in EGP updates.
gatewaygateway
If a network is not shared with a neighbor,
gateway specifies a router on an attached
network to be used as the next hop router for routes received
from this neighbor. This option is only rarely used.
lcladdrlocal_address
Specifies the address to be used on the local end of the
connection with the neighbor. The local address must be on
an interface which is shared with the neighbor or with the
neighbor's gateway when the gateway
parameter is used. A session will only be opened when an
interface with the appropriate local address (through which
the neighbor or gateway address is directly reachable) is
operating.
sourcenetnetwork
Specifies the network queried in the EGP Poll packets. By
default this is the network shared with neighbors address
specified. If no network is shared with the neighbor,
one of the networks to which the neighbor is attached should be
specified. This parameter can also be used to specify a
network shared with the neighbor other than the one on which the
EGP packets are sent. This parameter is normally not needed.
p1time
minhellotime
Sets the minimum acceptable 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, gated stops trying to acquire the neighbor. Setting
a larger interval gives the neighbor a better chance to
respond. minhello is an alias for the P1 value
defined in the EGP specification.
p2time
minpolltime
Sets the time interval between 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
database. A longer polling interval supports a more stable
routing database but is not as responsive to routing changes.
minpoll is an alias for the P2 value defined in
the EGP specification.
ttlttl
By default, gated sets the IP TTL for local neighbors to
one and the TTL for non-local neighbors to 255. This
option is provided when attempting to communicate with
improperly functioning routers that ignore packets sent with
a TTL of one.
traceoptionstrace_options
Specifies the tracing options for this EGP neighbor. By
default these are inherited from group or EGP global trace
options. (See
``Trace statements''
and
``EGP tracing options''.)
EGP tracing options
The state and policy options work with
EGP.
Packet tracing options (which may be modified with detail,
send and recv):
packets
All EGP packets.
hello
EGP HELLO/I-HEARD-U packets which are used to
determine neighbor reachability.
acquire
EGP ACQUIRE/CEASE packets which are used to
initiate and terminate EGP sessions.
update
EGP POLL/UPDATE packets which are used to
request and receive reachability updates.
The Border Gateway Protocol (BGP)
The Border Gateway Protocol (BGP) is an exterior routing protocol
used for exchanging routing information between autonomous systems.
BGP is used for exchange of routing information between multiple
transit autonomous systems as well as between transit and stub
autonomous systems. BGP is related to EGP but operates with more
capability, greater flexibility, and less required bandwidth. BGP
uses ``path attributes'' to provide more information about each
route, and in particular maintain an ``AS path'', which includes
the AS number of each autonomous system the route has transited, providing
information sufficient to prevent routing loops in an arbitrary topology.
Path attributes may also be used to distinguish between groups of routes to
determine administrative preferences, allowing greater flexibility in
determining route preference to achieve a variety of administrative ends.
BGP supports two basic types of sessions between neighbors, internal
(sometimes referred to as IBGP)
and external. Internal sessions are
run between routers in the same autonomous system, while external
sessions run between routers in different autonomous systems. When
sending routes to an external peer the local AS number is prepended
to the AS path, hence routes received from an external peer are guaranteed
to have the AS number of that peer at the start of the path. Routes
received from an internal neighbor will not in general have the local AS
number prepended to the AS path, and hence will in general have the
same AS path that the route had when the originating internal neighbor
received the route from an external peer. Routes with no AS numbers
in the path may be legitimately received from internal neighbors; these
indicate that the received route should be considered internal to your
own AS.
The BGP implementation supports three versions of the BGP protocol,
versions 2, 3 and 4. BGP versions 2 and 3 are quite similar in
capability and function. They will only propagate classed network
routes, and the AS path is a simple array of AS numbers. BGP 4 will
propagate fully general address-and-mask routes, and the AS path has
some structure to represent the results of aggregating dissimilar routes.
External BGP sessions may or may not include a single metric, which
BGP calls the ``Multi-Exit Discriminator'', in the path attributes.
For BGP versions 2 and 3 this metric is a 16-bit unsigned integer, for
BGP version 4 it is a 32-bit unsigned integer. In either case smaller
values of the metric are to be preferred. Currently this metric is
only used to break ties between routes with equal preference
from the same neighbor AS. Internal BGP sessions carry at least
one metric in the path attributes, which BGP calls the ``LocalPref''.
The size of the metric is identical to the MED. For BGP versions 2 and 3
this metric is considered better when its value is smaller, for version 4
it is better when it is larger. BGP version 4 sessions may optionally carry
a second metric on internal sessions, this being an internal version
of the Multi-Exit Discriminator. The use of these metrics is
dependent on the type of internal protocol processing which is specified.
BGP collapses routes with similar path attributes into a single
update for advertisement. Routes that are received in a single update
will be readvertised in a single update. The churn caused by the loss
of a neighbor will be minimized and the initial advertisement sent
during peer establishment will be maximally compressed. BGP does not
read information from the kernel message-by-message, but fills the
input buffer. It processes all complete messages in the buffer before
reading again. BGP also does multiple reads to clear all incoming
data queued on the socket. This feature may cause other protocols to
be blocked for prolonged intervals by a busy peer connection.
All unreachable messages are collected into a single
message and sent prior to reachable routes during a flash update. For
these unreachable announcements, the next hop is set to the local
address on the connection, no metric is sent and the path origin is
set to incomplete. On external connections the AS path in unreachable
announcements is set to the local AS, on internal connections the AS
path is set to zero length.
The BGP implementation expects external peers to be directly attached to
a shared subnet, and expects those peers to advertise next hops which
are host addresses on that subnet (though this constraint can be relaxed
by configuration for testing). For groups of internal peers, however,
there are several alternatives which may be selected from by specifying
the group type. Type internal groups expect all peers to
be directly attached to a shared subnet so that, like external peers,
the next hops received in BGP advertisements may be used directly for
forwarding. Type routing groups instead will determine
the immediate next hops for routes by using the next hop received with
a route from a peer as a forwarding address, and using this to look up
an immediate next hop in an IGP's routes. Such groups support distant
peers, but need to be informed of the IGP whose routes they are using
to determine immediate next hops. Finally, type igp groups
expect routes from the group peers to not be used for forwarding at
all. Instead they expect that copies of the BGP routes received will
also be received via an IGP, and that the BGP routes will only be used
to determine the path attributes associated with the IGP routes. Such
groups also support distant peers, and also need to be informed of the
IGP they are running with.
For internal BGP group types (and for test groups), where possible a
single outgoing message is built for all group peers based on the common
policy. A copy of the message is sent to every peer in the group,
with possible adjustments to the next hop field as appropriate to each
peer. This minimizes the computational load of running large numbers
of peers in these types of groups. BGP allows unconfigured peers to
connect if an appropriate group has been configured with an
allow clause.
The bgp statement enables or disables BGP. By default
BGP is disabled. The default metric for announcing routes via BGP is
not to send a metric.
preferencepreference
Sets the preference for routes learned from RIP. The default
preference is 170. This preference may be overridden by a
preference specified on the group or
peer statements or by import policy.
defaultmetricmetric
Defines the metric used when advertising routes via BGP. If not
specified, no metric is propagated. This metric may be
overridden by a metric specified on the neighbor or group
statements or in export policy.
traceoptionstrace_options
Specifies the tracing options for BGP. By default these are
inherited from the global trace options. These values may be
overridden on a group or neighbor basis. (See
``Trace statements''
and
``BGP tracing options''.)
Groups
BGP peers are grouped by type and the autonomous system of the peers.
Any number of groups may be specified, but each must have a unique
combination of type and peer autonomous system. There are four
possible group types:
grouptypeexternalpeerasautonomous_system
In the classic external BGP group, full policy checking is
applied to all incoming and outgoing advertisements. The external
neighbors must be directly reachable through one of the machine's
local interfaces. By default no metric is included in external
advertisements, and the next hop is computed with respect to the
shared interface.
grouptypeinternalpeerasautonomous_system
An internal group operating where there is no IP-level IGP, for
example an SMDS network or MILNET. All neighbors in this group
are required to be directly reachable via a single interface.
All next hop information is computed with respect to this
interface. Import and export policy may be applied to group
advertisements. Routes received from external BGP or EGP
neighbors are by default readvertised with the received metric.
grouptypeigppeerasautonomous_systemprotoproto
An internal group that runs in association with an interior
protocol. The IGP group examines routes which the IGP is
exporting and sends an advertisement only if the path attributes
could not be entirely represented in the IGP tag mechanism. Only
the AS path, path origin, and transitive optional attributes are
sent with routes. No metric is sent, and the next hop is set to
the local address used by the connection. Received internal BGP
routes are not used or readvertised. Instead, the AS path
information is attached to the corresponding IGP route and the
latter is used for readvertisement. Since internal IGP peers are
sent only a subset of the routes which the IGP is exporting, the
export policy used is the IGP's. There is no need to implement
the ``do not routes from peers in the same group'' constraint since
the advertised routes are routes that IGP already exports.
An internal group which uses the routes of an interior protocol
to resolve forwarding addresses. A ``type routing'' group propagates
external routes between routers which are not directly connected,
and computes immediate next hops for these routes by using the
BGP next hop which arrived with the route as a forwarding address
to be resolved via an internal protocol's routing information. In
essence, internal BGP is used to carry AS external routes, while the
IGP is expected to only carry AS internal routes, and the latter is
used to find immediate next hops for the former.
The proto names the interior protocol to be used to resolve
BGP route next hops, and may be the name of any IGP in the configuration.
By default the next hop in BGP routes advertised to type routing peers
will be set to the local address on the BGP connection to those peers,
as it is assumed a route to this address will be propagated via the IGP.
The interface_list can optionally provide a list interfaces
whose routes are carried via the IGP for which third party next hops
may be used instead.
grouptypetestpeerasautonomous_system
An extension to external BGP which implements a fixed policy
using test peers. Fixed policy and special case code
make test peers relatively inexpensive to maintain. Test peers do
not need to be on a directly attached network. If gated and the
peer are on the same (directly attached) subnet, the advertised
next hop is computed with respect to that network, otherwise the
next hop is the local machine's current next hop. All routing
information advertised by and received from a test peer is
discarded, and all BGP advertizable routes are sent back to the
test peer. Metrics from EGP- and BGP-derived routes are
forwarded in the advertisement, otherwise no metric is included.
Group parameters
The BGP statement has group clauses and peer
subclauses. Any number of peer subclauses may be specified within a
group. A group clause usually defines default parameters for a group
of peers, these parameters apply to all subsidiary peer subclauses.
Any parameters from the peer subclause may be specified on the group
clause to provide defaults for the whole group (which may be
overridden for individual peers).
Specifying peers
Within a group, BGP peers may be configured in one of two ways. They
may be explicitly configured with a peer statement, or
implicitly configured with the allow statement. Both are
described here:
allow
The allow clauses allows for peer connections from
any addresses in the specified range of network and mask pairs.
All parameters for these peers must be configured on the group
clause. The internal peer structures are created when an
incoming open request is received and destroyed when the
connection is broken. For more information about specifying
network/mask pairs, see
``Route filtering''.
peerhost
A peer clause configures an individual peer. Each
peer inherits all parameters specified on a group as defaults.
Those default may be overridden by parameters explicitly
specified on the peer subclause.
Within each group clause, individual peers can be
specified or a group of potential peers can be specified
using allow. allow is used to specify a set of
address masks. If gated receives a BGP connection request from any
address in the set specified, it will accept it and set up a peer
relationship.
Peer parameters
The BGP peer subclause allows the following parameters,
which can also be specified on the group clause. All
are optional.
metricoutmetric
If specified, this metric is used as the primary metric on all
routes sent to the specified peer(s). This metric overrides the
default metric, a metric specified on the group and any metric
specified by export policy.
localasautonomous_system
Identifies the autonomous system which gated is representing to
this group of peers. The default is that which has been set
globally in the autonomoussystem statement.
nogendefault
Prevents gated from generating a default route when EGP receives
a valid update from its neighbor. The default route is only
generated when the gendefault option is enabled.
gatewaygateway
If a network is not shared with a peer, gateway
specifies a router on an attached network to be used as the next
hop router for routes received from this neighbor. This
parameter is not needed in most cases.
preferencepreference
Specifies the preference used for routes learned from these
peers. This can differ from the default BGP preference set
in the bgp statement, so that gated can prefer
routes from one peer, or group of peer, over others. This
preference may be explicitly overridden by import policy.
preference2preference
In the case of a preference tie, the second
preference, preference2 may be used to break the
tie. The default value is 0.
lcladdrlocal_address
Specifies the address to be used on the local end of the TCP
connection with the peer. For external peers the local
address must be on an interface which is shared with the peer or
with the peer's gateway when the gateway
parameter is used. A session with an external peer will only be
opened when an interface with the appropriate local address
(through which the peer or gateway address is directly reachable)
is operating. For other types of peers, a peer session will be
maintained when any interface with the specified local address is
operating. In either case incoming connections will only be
recognized as matching a configured peer if they are addressed to
the configured local address.
holdtimetime
Specifies the BGP holdtime value to use when negotiating the
connection with this peer, in seconds. According to BGP, if
gated does not receive a keepalive, update, or notification
message within the period specified in the Hold Time field of the
BGP Open message, then the BGP connection will be closed. The
value must be either 0 (no keepalives will be sent) or at least
3.
versionversion
Specifies the version of the BGP protocol to use with this peer.
If not specified, the highest supported version is used first and
version negotiation is attempted. If it is specified, only the
specified version will be offered during negotiation. Currently
supported version are 2, 3 and 4.
passive
Specifies that active OPENs to this peer should not be
attempted. gated should wait for the peer to issue an
open. By default all explicitly configured peers are active,
they periodically send OPEN messages until the peer responds.
sendbufferbuffer_size
recvbufferbuffer_size
Control the amount of send and receive buffering asked of the
kernel. The maximum supported is 65535 bytes although many
kernels have a lower limit. By default, gated configures the
maximum supported. These parameters are not needed on normally
functioning systems.
indelaytime
outdelaytime
Used to dampen route fluctuations. indelay is the
amount of time a route learned from a BGP peer must be stable
before it is accepted into the gated routing database.
outdelay is the amount of time a route must be
present in the gated routing database before it is exported to
BGP. The default value for each is 0, meaning that these
features are disabled.
keepall
Used to retain routes learned from a peer even if the routes' AS
paths contain one of our exported AS numbers.
analretentive
Causes gated to issue warning messages when receiving
questionable BGP updates such as duplicate routes and/or
deletions of non-existing routes. Normally these events are
silently ignored.
noauthcheck
Normally gated verifies that incoming packets have an
authentication field of all ones. This option may be used to
allow communication with an implementation that uses some other
form of authentication.
noaggregatorid
Causes gated to specify the routerid in the aggregator attribute
as zero (instead of its routerid) in order to prevent different
routers in an AS from creating aggregate routes with different AS
paths.
keepalivesalways
Causes gated always to send keepalives, even when an update could
have correctly substituted for one. This allows interoperability
with routers that do not completely obey the protocol
specifications on this point.
v3asloopokay
By default gated will not advertise routes whose AS path is
looped (that is, with an AS appearing more than once in the path) to
version 3 external peers. Setting this flag removes this
constraint. Ignored when set on internal groups or peers.
nov4asloop
Prevents routes with looped AS paths from being advertised to
version 4 external peers. This can be useful to avoid
advertising such routes to peer which would incorrectly forward
the routes on to version 3 neighbors.
logupdown
Causes a message to be logged via the syslog mechanism whenever a
BGP peer enters or leaves the ESTABLISHED state.
ttlttl
By default, gated sets the IP TTL for local peers to one
and the TTL for non-local peers to 255. This option mainly is
provided when attempting to communicate with improperly
functioning routers that ignore packets sent with a TTL of one.
traceoptionstrace_options
Specifies the tracing options for this BGP neighbor. By
default these are inherited from group or BGP global trace
options. (See
``Trace statements''
and
``BGP tracing options''.)
BGP tracing options
Note that the state option works with BGP, but does not
provide true state transition information.
Packet tracing options (which may be modified with
detail, send and recv):
packets
All BGP packets
open
BGP OPEN packets which are used to establish a peer
relationship.
update
BGP UPDATE packets which are used to pass network
reachability information.
keepalive
BGP KEEPALIVE packets which are used to verify peer reachability.
The ICMP statement
Currently the only reason to specify the icmp statement
is to be able to trace the ICMP messages that gated
receives.
Packet tracing options (which may be modified with detail
and recv):
packets
All ICMP packets received.
redirect
Only ICMP REDIRECT packets received.
routerdiscovery
Only ICMP ROUTER DISCOVERY packets received.
info
Only ICMP informational packets, which include mask
request/response, info request/response, echo request/response
and time stamp request/response.
error
Only ICMP error packets, which include time exceeded, parameter
problem, unreachable and source quench.
Redirect processing
The redirect code is passed ICMP redirects learned
by monitoring ICMP messages.
It processes the redirect request and decides whether to
accept the redirect. If the redirect is accepted, a route is
installed in the gated routing table with the protocol
redirect. Redirects are deleted from the routing table
after 3 minutes.
If gated determines that a redirect is not acceptable, it tries to
figure out if the kernel forwarding table has been modified. On
systems where ICMP messages are monitored this is accomplished by
trying to second guess what the kernel would have done with the
redirect.
If gated has determined that the state of the kernel forwarding table
has been changed, the necessary requests to the kernel are made to
restore the correct state.
Note that on currently available systems it is not possible to disable
the processing of ICMP redirects, even when the system is functioning
as a router. To ignore the effects of redirects, gated must process
each one and actively restore any changes it made to the kernel's
state. Because of the mechanism's involved there will be windows
where the effects of redirects are present in the kernel.
By default, gated removes redirects when actively participating in an
interior routing protocol (RIP or OSPF).
It is not possible to enable redirects once
they have been automatically disabled.
Listening to RIP in
nobroadcast mode does not cause redirects to be ignored, nor
does the use of EGP and BGP. Redirects must be manually configured
off in these cases.
Note that in accordance with the latest IETF Router Requirements
document, gated insures that all ICMP net redirects are processed as
host redirects. When an ICMP net redirect is accepted, gated issues
the requests to the kernel to make sure that the kernel forwarding
table is updated to reflect a host redirect instead of a net redirect.
The redirect statement does not prevent the system from sending
redirects, only from listening to them.
The redirect statement
redirectyes | no | on | off [ { preferencepreference; interfaceinterface_list
[ noredirects ] | [redirects ] ; trustedgatewaysgateway_list; traceoptionstrace_options; } ] ;
preference
Sets the preference for a route learned from a redirect. The
default is 30.
interfaceinterface_list
The interface statement allows the enabling and
disabling of redirects on an interface-by-interface basis. See
``Interface list specification''
for the description of the format of
interface_list.
The possible parameters are:
noredirects
Specifies that redirects received via the specified
interface will be ignored. The default is to accept
redirects on all interfaces.
redirects
This is the default. This argument may be necessary
when noredirects is used on a wildcard
interface descriptor.
trustedgatewaysgateway_list
Defines the list of gateways from which redirects will be
accepted. The gateway_list is simply a list of host
names or addresses. By default, all routers on the shared
network(s) are trusted to supply redirects. But if the
trustedgateways clause is specified only redirects
from the gateways in the list are accepted.
traceoptionstrace_options
There are no redirect-specific tracing options. All non-error
messages are traced under the normal class.
Tracing options
There are no redirect-specific tracing options. All
non-error messages are traced under the normal class.
The Router Discovery Protocol
The Router Discovery Protocol is an IETF standard protocol used to
inform hosts of the existence of routers. It is intended to be used
instead of having hosts wiretap routing protocols such as
RIP. It is used in place of, or in addition to statically configured
default routes in hosts.
The protocol is split into two portions, the server portion
which runs on routers, and the client portion that runs on
hosts. gated treats these much like two separate protocols, only one
of which may be enabled at a time.
The Router Discovery server
The Router Discovery server runs on routers and announces their
existence to hosts. It does this by periodically multicasting or
broadcasting a ROUTER ADVERTISEMENT to each interface
on which it is enabled. These Router Advertisements contain a list of
all the routers addresses on a given interface and their preference
for use as a default router.
Initially these Router Advertisements occur every few seconds, then fall back
to every few minutes. In addition, a host may send a ROUTER
SOLICITATION to which the router will respond with a unicast
Router Advertisement (unless a multicast or broadcast advertisement is due
momentarily).
Each Router Advertisement contains an Advertisement Lifetime field
indicating for how long the advertised addresses are valid. This
lifetime is configured such that another Router Advertisement will be
sent before the lifetime has expired. A lifetime of zero is used to
indicate that one or more addresses are no longer valid.
On systems supporting IP multicasting, the Router Advertisements are
by default send to the all-hosts multicast address
224.0.0.1. However, the use of broadcast may be
specified. When Router Advertisements are being sent to the all-hosts
multicast address, or an interface is configured for the
limited-broadcast address 255.255.255.255, all IP
addresses configured on the physical interface are included in the
Router Advertisement. When the Router advertisements are being sent
to a net or subnet broadcast, only the address associated with that
net or subnet is included.
Specifies the parameters that apply to physical interfaces. Note
a slight difference in convention from the rest of gated,
interface specifies just physical interfaces
(such as le0, ef0 and
en1), while address specifies
protocol (in this case IP) addresses.
Interface parameters are:
maxadvintervaltime
The maximum time allowed between sending broadcast or
multicast Router Advertisements from the interface. Must be
no less than 4 and no more than 30:00 (30
minutes or 1800 seconds). The default is
10:00 (10 minutes or 600 seconds).
minadvintervaltime
The minimum time allowed between sending unsolicited
broadcast or multicast Router Advertisements from the
interface. Must be no less than 3 seconds and no
greater than maxadvinterval. The default
is 0.75 * maxadvinterval.
lifetimetime
The lifetime of addresses in a Router Advertisement. Must
be no less than maxadvinterval and no
greater than 2:30:00 (two hours, thirty minutes or
9000 seconds). The default is 3 *
maxadvinterval.
addressinterface_list
Specifies the parameters that apply to the specified set of
addresses on this physical interfaces. Note a slight difference
in convention from the rest of gated, interface
specifies just physical interfaces (such as le0,
ef0 and en1), while
address specifies protocol (in this case IP)
addresses.
advertise
Specifies that the specified address(es) should be included
in Router Advertisements. This is the default.
ignore
Specifies that the specified address(es) should not be
included in Router Advertisements.
broadcast
Specifies that the given address(es) should be included in a
broadcast Router Advertisement because this system does not
support IP multicasting, or some hosts on attached network
do not support IP multicasting. It is possible to mix
addresses on a physical interface such that some are
included in a broadcast Router Advertisement and some are
included in a multicast Router Advertisement. This is the
default if the router does not support IP multicasting.
multicast
Specifies that the given address(es) should only be included
in a multicast Router Advertisement. If the system does not
support IP multicasting the address(es) will not be
included. If the system supports IP multicasting, the
default is to include the address(es) in a multicast Router
Advertisement if the given interface supports IP
multicasting, if not the address(es) will be included in a
broadcast Router Advertisement.
preferencepreference
The preferability of the address(es) as a default router
address, relative to other router addresses on the same
subnet. A 32-bit, signed, twos-complement integer, with
higher values meaning more preferable. Note that hex
80000000 may only be specified as
ineligible. The default is 0.
ineligible
Specifies that the given address(es) will be assigned a
preference of (hex 80000000) which means that it is not
eligible to be the default route for any hosts.
This is useful when the address(es) should not be used as a
default route, but are given as the next hop in an ICMP
redirect. This allows the hosts to verify that the given
addresses are up and available.
The Router Discovery client
A host listens for Router Advertisements via the all-hosts multicast
address (224.0.0.2), If IP multicasting is available and
enabled, or on the interface's broadcast address. When starting up,
or when reconfigured, a host may send a few Router Solicitations to
the all-routers multicast address, 224.0.0.2, or the
interface's broadcast address.
When a Router Advertisement with non-zero lifetime is received, the
host installs a default route to each of the advertised addresses. If
the preference ineligible, or the address is not on
an attached interface, the route is marked unusable but retained. If
the preference is usable, the metric is set as a function of the
preference such that the route with the best preference is used. If
more than one address with the same preference is received, the one
with the lowest IP address will be used. These default routes are not
exportable to other protocols.
When a Router Advertisement with a zero lifetime is received, the host
deletes all routes with next-hop addresses learned from that router.
In addition, any routers learned from ICMP redirects pointing to these
addresses will be deleted. The same will happen when a Router
Advertisement is not received to refresh these routes before the
lifetime expires.
Specifies the preference of all Router Discovery default routes.
The default is 55.
interfaceinterface_list
Specifies the parameters that apply to physical interfaces. Note
a slight difference in convention from the rest of gated,
interface specifies just physical interfaces
(such as le0, ef0 and
en1). The Router Discovery Client has no parameters
that apply only to interface addresses.
enable
Specifies that Router Discovery should be performed on the
specified interface(s). This is the default.
disable
Specifies that Router Discovery should not be performed on
the specified interface(s).
broadcast
Specifies that Router Solicitations should be broadcast on
the specified interface(s). This is the default if IP
multicast support is not available on this host or interface.
multicast
Specifies that Router Solicitations should be multicast on
the specified interface(s). If IP multicast is not
available on this host and interface, no solicitation will
be performed. The default is to multicast
Router Solicitations if the host and interface support it,
otherwise Router Solicitations are broadcast.
quiet
Specifies that no Router Solicitations will be sent on this
interface, even though Router Discovery will be performed.
solicit
Specifies that initial Router Solicitations will be sent on
this interface. This is the default.
Router Discovery tracing options
The Router Discovery Client and Server support the state
trace flag which traces various protocol occurrences.
state
State transitions
The Router Discovery Client and Server do not directly support any
packet tracing options, tracing of router discovery packets is enabled
via the icmp statement.
The SNMP statement
The Simple Network Management Protocol (SNMP) is a not a routing
protocol but a network management protocol. The snmp
statement controls whether gated tries to contact the SNMP
Multiplexing daemon to register supported variables. The SNMP daemon
(see
snmpd(ADMN))
must be run independently.
The snmp statement only controls whether gated keeps the
management software apprised of its status.
gated communicates with the SNMP daemon via the SMUX protocol that is
described in RFC 1227.
The SNMP statement syntax is:
snmpyes | no | on | off
[ { portport; debug; traceoptionstraceoptions; } ] ;
Reporting is enabled by specifying yes or on
and disabled with no or off.
The default
is on.
portport
By default, the SMUX daemon listens for requests on port 199.
gated can be configured to try to contact the SMUX
daemon on a different port by explicitly specifying the port.
debug
Specifying this option enables debugging of the SMUX code.
The default is debugging disabled.
There are no SNMP-specific trace options.
SNMP requests received via the
SMUX protocol from the SNMP daemon
are currently handled differently from packets. The detail,
send, and recv options are not supported.
receive
SNMP requests received from the SMUX daemon and the associated
responses.
register
Protocol requests to register variables.
resolve
Protocol requests to resolve variable names.
trap
SNMP trap requests from protocols.
The kernel statement
While the kernel interface is not technically a routing protocol, it
has many characteristics of one, and gated handles it
similarly to one.
The routes that gated chooses to install in the kernel forwarding
table are those that will actually be used by the kernel to forward
packets.
The add, delete and change operations gated must use to update the
typical kernel forwarding table take a non-trivial amount of time.
This does not present a problem for older routing protocols (RIP,
EGP), which are not particularly time critical and do not easily
handle very large numbers of routes anyway. The newer routing
protocols (OSPF, BGP)
have stricter timing requirements and are often
used to process many more routes. The speed of the kernel interface
becomes critical when these protocols are used.
To prevent gated from locking up for significant periods of time
installing large numbers of routes (up to a minute or more has been
observed on real networks), the processing of these routes is now done
in batches. The size of these batches may be controlled by the tuning
parameters described below, but normally the default parameters will
provide the proper functionality.
During normal shutdown processing, gated normally deletes all the
routes it has installed in the kernel forwarding table, except for
those marked with retain. Optionally, gated can
leave all routes in the kernel forwarding table by not deleting any
routes. In this case changes will be made to insure that routes with
a retain indication are installed in the table. This
is useful on systems with large numbers of routes as it prevents the
need to re-install the routes when gated restarts. This can greatly
reduce the time it takes to recover from a restart.
Forwarding tables and routing tables
The table in the kernel that controls the forwarding of packets is a
forwarding table, also known as a forwarding
information base, or FIB. The table that gated uses
internally to store routing information it learns from routing
protocols is a routing table, known as a
routing information base, or RIB. The routing table
is used to collect and store routes from various protocols. For each
unique combination of network and mask an
active route is chosen, this route will be the one with the
best (numerically smallest) preference. All the active
routes are installed in the kernel forwarding table. The entries in
this table are what the kernel actually uses to forward packets.
On systems supporting the routing
socket this insures that changes operations will not be
performed, only deletes and adds.
noflushatexit
During normal shutdown processing gated deletes all routes from
the kernel forwarding table that do not have a
retain indication. The
noflushatexit option prevents route deletions at
shutdown. Instead, routes are changed and added to make sure
that all the routes marked with retain get
installed.
This is handy on systems with thousands of routes. Upon startup
gated will notice which routes are in the kernel forwarding table
and not have to add them back.
remnantholddimtetime
Normally remnant routes read from the kernel
forwarding table at startup are timed out in three minutes or as
soon as they are overridden. This option allows the interval to
be configured to a value between zero and 15 minutes. Setting it
to zero causes these routes to be deleted immediately.
routesnumber
On some systems kernel memory is at a premium. With this
parameter a limit can be placed on the maximum number of routes
gated will install in the kernel. Normally gated
adds/changes/deletes routes in interface/internal/external order,
that is, it queues interface routes first, followed by internal
routes, followed by external routes, and processes the queue from
the beginning. If this parameter is specified and the
limit is hit, gated does two scans of the list instead. On the
first scan it does deletes, and also deletes all changed routes,
turning the queued changes into adds. It then rescans the list
doing adds in interface/internal/external order until it hits the
limit again. This will tend to favor internal routes over
external routes. The default is not to limit the number of
routes in the kernel forwarding table.
flash
When routes change, the process of notifying the protocols is
called a flash update. The kernel forwarding table
interface is the first to be notified. Normally a maximum of 20
interface routes may be processed during one flash update. The
flash command allows tuning of these parameters:
limitnumber
Specifies the maximum number of routes which may be
processed during one flash update. The default is
20. A value of -1 will cause all
pending route changes of the specified type to be processed
during the flash update.
typeinterface | interior | all
Specifies the type of routes that will be processed during a
flash update. interior specifies that interior
routes (see
``Interior routing protocols'')
will also be installed. all specifies the inclusion
of exterior routes as well (see
``Exterior routing protocols'').
The default is interface which
specifies that only interface routes will be installed
during a flash update.
Specifying flash limit -1 all causes all routes to
be installed during the flash update; this mimics the
behavior of previous versions of gated.
background
Since only interface routes are normally installed during a flash
update, the remaining routes are processed in batches in the
background, that is, when no routing protocol traffic is being
received. Normally, 120 routes are installed at a time to allow
other tasks to be performed and this background processing
is done at lower priority than flash updates the following
parameters allow tuning of these parameters:
limitnumber
Specifies the number of route which may be processed at
during one batch. The default is 120.
priorityflash | higher | lower
Specifies the priority of the processing of batches of
kernel updates in relationship to the flash update
processing. The default is lower which means
that flash updates are processed first. To process kernel
updates at the same priority as flash updates, specify
flash; to process them at a lower priority, use
lower.
Tracing options
While the kernel interface is not technically a routing protocol, in
many cases it is handled as one. The following two symbols make sense
when entered from the command line since the code that uses them is
executed before the trace file is parsed.
symbols
Symbols read from the kernel, by nlist or similar
interface.
iflist
Interface list scan. This option is useful when entered from the
command line as the first interface list scan is performed before
the configuration file is parsed.
The following tracing options may only be specified in the
configuration file. They are not valid from the command line.
remnants
Routes read from the kernel when gated starts.
request
Requests by gated to Add/Delete/Change routes in the kernel forwarding table.
Static statements
static statements define the static routes used by gated.
A single static statement can specify any number of routes.
The static statements occur after protocol statements and
before control statements in the gated.conf file. Any number of
static statements may be specified, each containing any
number of static route definitions. These routes can be overridden by
routes with better preference values.
This is the most general form of the static statement. It
defines a static route through one or more gateways. Static
routes are installed when one or more of the gateways
listed are available on directly attached interfaces. If more
than one eligible gateways are available, they are limited by
the number of multipath destinations supported. Currently, this number is one.
Parameters for static routes are:
interfaceinterface_list
When this parameter is specified, gateways are only
considered valid when they are on one of these
interfaces. See
``Interface list specification''
for a description of the format of
interface_list.
preferencepreference
This option selects the preference of this static route.
The preference controls how this route competes with routes
from other protocols. The default preference is 60.
retain
Normally gated removes all routes except interface routes
from the kernel forwarding table during a graceful shutdown.
The retain option may be used to prevent
specific static routes from being removed. This is useful
to insure that some routing is available when gated is not
running.
reject
Instead of forwarding a packet like a normal route,
reject routes cause packets to be dropped and
unreachable messages to be sent to the packet
originators. Specifying this option causes this route to be
installed as a reject route. Not all kernel forwarding
engines support reject routes.
blackhole
A blackhole route is the same as a
reject route except that
unreachable messages are not supported.
noinstall
Normally the route with the lowest preference is installed
in the kernel forwarding table and is the route exported to
other protocols. When noinstall is specified
on a route, it will not be installed in the kernel
forwarding table when it is active, but it will still be
eligible to be exported to other protocols.
This form defines a static interface route which is used for
primitive support of multiple network addresses on one interface.
The preference, retain,
reject, blackhole and
noinstall options are the same as described above.
Route filtering
Routes are filtered by specifying configuration language that will
match a certain set of routes by destination, or by destination and
mask. Among other places, route filters are used on
martians, import and export
statements.
The action taken when no match is found is dependent on the context,
for instance import and export route filters
assume an all reject ; at the end a list.
A route will match the most specific filter that applies. Specifying
more than one filter with the same destination, mask and modifiers
will generate an error.
These are all the possible formats for a route filter. Not all of
these formats are available in all places, for instance the
host and default formats are not valid for
martians.
In most cases it is possible to specify additional parameters relevant
to the context of the filter. For example, on a martian
statement it is possible to specify the allow keyword, on
an import statement you can specify a preference, and on
a export you can specify a metric.
network [ exact | refines ]
networkmaskmask [ exact | refines ]
networkmasklennumber [ exact | refines ]
Matching usually requires both an address and a mask, although
the mask is implied in the shorthand forms listed below. These
three forms vary in how the mask is specified. In the first
form, the mask is implied to be the natural mask of the
network. In the second, the mask is explicitly specified. In
the third, the mask is specified by the number of contiguous one
bits.
If no additional parameters are specified, any destination that
falls in the range given by the network and mask is matched, the
mask of the destination is ignored. If a natural
network is specified, the network, any subnets, and any hosts
will be match. The two optional modifiers cause the mask of the
destination to be considered also:
exact
This parameter specifies that the mask of the destination
must match the supplied mask exactly. This is used
to match a network, but no subnets or hosts of that network.
refines
Specifies that the mask of the destination must be
longer than the filter mask. This is used
to match subnets and/or hosts of a network, but not the
network.
all
This entry matches anything. It is equivalent to
0.0.0.0 mask 0.0.0.0.
default
Matches the default route. To match, the
address must be the default address and the mask must be all
zeros. This is equivalent to:
0.0.0.0 mask 0.0.0.0 exact.
hosthost
Matches the specific host. To match, the address must exactly
match the specified host and the network mask must be
a host mask (that is, all ones). This is equivalent to
hostmask 255.255.255.255 exact.
Matching AS paths
An AS path is a list of autonomous systems that
routing information has passed through to get to this router, and an
indicator of the origin of the AS path. This information can be used
to prefer one path to a destination network over another. The primary
method for doing this with gated is to specify a list of patterns to
be applied to AS paths when importing and exporting routes.
Each autonomous system that a route passed through prepends its AS
number to the beginning of the AS path.
The origin information details the completeness of AS path
information. 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.
AS path regular expressions are defined in RFC 1164
section 4.2.
This specifies that an AS matching the aspath_regexp with
the specified origin is matched.
AS path regular expressions
Technically, an AS path regular expression is a regular expression
with the alphabet being the set of AS numbers. An AS path regular
expression is composed of one or more AS paths expressions. An AS
path expressions is composed of AS path terms and AS path operators.
AS path terms
An AS path term is one of the following three objects:
autonomous_system
Is any valid autonomous system number, from one through 65534
inclusive.
.
Matches any autonomous system number.
(aspath_regexp)
Parentheses group subexpressions -- an operator, such as
* or ? works on a single element or on a
regular expression enclosed in parentheses.
AS path operators
An AS path operator is one of the following:
aspath_term{m,n}
a regular expression followed by {m,n} (where m
and n are both non-negative integers and m <= n) means at least
m and at most n repetitions.
aspath_term{m}
a regular expression followed by {m} (where m is
a positive integer) means exactly m repetitions.
aspath_term{m,}
a regular expression followed by {m,} (where m is a
positive integer) means m or more repetitions.
aspath_term*
an AS path term followed by * means zero or
more repetitions. This is shorthand for {0,}.
aspath_term+
a regular expression followed by + means one or
more repetitions. This is shorthand for {1,}.
aspath_term?
a regular expression followed by ? means
zero or one repetition. This is shorthand for
{0,1}.
aspath_term|aspath_term
matches the AS term on the left,
or the AS term on the right.
The import statement
Importation of routes from routing protocols and installation of the
routes in gated's routing database is controlled by
import statements. The format of an import
statement varies depending on the source protocol.
Specifying preferences
In all cases, one of two keywords may be specified to control how
routes compete with other protocols:
restrict
Specifies that the routes are not desired in the routing table.
In some cases this means that the routes are not installed in the
routing table. In others it means that they are installed with a
negative preference; this prevents them from becoming
active so they will not be installed in the forwarding
table, or exported to other protocols.
preferencepreference
Specifies the preference value used when comparing this route to
other routes from other protocols. The route with the lowest
preference available at any given route becomes the
active route, is installed in the forwarding table, and
is eligible to be exported to other protocols. The default
preferences are configured by the individual protocols.
Route filters
All the import formats allow route filters as shown below.
See
``Route filtering''
for a detailed
explanation of how route filtering works.
When no route filtering is specified
(that is, when restrict is specified on the first line of a
statement), all routes from the specified source will match that
statement. If any filters are specified, only routes that match the
specified filters will be imported. Put differently, if any filters
are specified, an all restrict ; is assumed at the end of
the list.
EGP importation may be controlled by autonomous system.
BGP also supports controlling propagation by the use of an AS path
regular expressions, which are documented in
``Matching AS paths''.
Note that EGP and BGP versions 2 and 3 only support the propagation of
natural networks, so the host and
default route filters are meaningless. BGP version 4
supports the propagation of any destination along with a
contiguous network mask.
EGP and BGP both store any routes that were rejected implicitly by not
being mentioned in a route filter, or explicitly with the
restrict keyword in the routing table with a negative
preference. A negative preference prevents a route from becoming
active, which prevents it from being installed in the forwarding
table, or exported to other protocols. This alleviates the need to
break and re-establish a session upon reconfiguration if importation
policy is changed.
The importation of RIP and Redirect routes may be controlled by
any of protocol, source interface and source gateway. If more than
one is specified, they are processed from most general (protocol) to
most specific (gateway).
RIP does not support the use of preference to choose between
routes of the same protocol. That is left to the protocol metrics.
These protocols do not save routes that were rejected since they have
short update intervals.
Due to the nature of OSPF,
only the importation of ASE routes may be
controlled. OSPF intra- and inter-area routes are always imported
into the gated routing table with a preference of 10.
If a tag is specified, the import clause will only apply to routes
with the specified tag.
It is only possible to restrict the importation of OSPF ASE routes
when functioning as an AS border router. This is accomplished by
specifying an export ospfase clause.
Specification of an empty export clause
may be used to restrict importation of ASEs when no ASEs are being
exported.
Like the other interior protocols, preference can not be used to
choose between OSPF ASE routes, that is done by the OSPF costs.
Routes that are rejected by policy are stored in the table with a
negative preference.
The export statement
The import statement controls which routes received from
other systems are used by gated, and the export statement
controls which routes are advertised by gated to other systems. Like
the import statement, the syntax of the
export statement varies slightly per protocol. 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. The main difference between the two
is that while route importation is just controlled by source
information, route exportation is controlled by both destination and
source.
The outer portion of a given export statement specifies
the destination of the routing information you are controlling. The
middle portion restricts the sources of importation that you wish to
consider. And the innermost portion is a
route filter used to select individual routes.
Specifying metrics
The most specific specification of a metric is the one applied to the
route being exported. The values that may be specified for a metric
depend on the destination protocol that is referenced by this export
statement.
restrict
Specifies that nothing should be exported. If specified on the
destination portion of the export statement it
specifies that nothing at all should be exported to this
destination. If specified on the source portion it specifies
that nothing from this source should be exported to this
destination. If specified as part of a
route filter, it specifies that the routes matching
that filter should not be exported.
metricmetric
Specifies the metric to be used when exporting to the specified
destination.
Route filters
All the export formats allow route filters as shown below.
See
``Route filtering''
for a detailed
explanation of how route filtering works.
When no route filtering is specified
(that is, when restrict is specified on the first line of a
statement), all routes from the specified source will match that
statement. If any filters are specified, only routes that match the
specified filters will be exported. Put differently, if any filters
are specified, an all restrict ; is assumed at the end of
the list.
Specifying the destination
As mentioned above, the syntax of the export statement
varies depending on the protocol it is being applied to. One thing
that applies in all cases is the specification of a metric. All
protocols define a default metric to be used for routes being
exported, in most cases this can be overridden at several levels of
the export statement.
The specification of the source of the routing information being
exported (the export list) is described
below.
Exporting to EGP and BGP
export protobgp | egpasautonomous system restrict;
Exportation to EGP and BGP is
controlled by autonomous system, the
same policy is applied to all routers in the AS.
EGP metrics range from 0 to 255 inclusive with 0 being the most
attractive.
BGP metrics are 16-bit unsigned quantities,
that is, they range from 0 to
65535 inclusive with 0 being the most attractive. While BGP version 4
actually supports 32-bit unsigned quantities, gated does not yet
support this.
If no export policy is specified, only routes to attached interfaces
will be exported. If any policy is specified the defaults are
overridden; it is necessary to explicitly specify everything that
should be exported.
Note that EGP and BGP versions 2 and 3
only support the propagation of
natural networks, so the host and
default route filters are meaningless. BGP version 4
supports the propagation of any destination along with a
contiguous network mask.
Exportation to RIP is controlled by any of protocol,
interface or gateway. If more than one is specified, they are
processed from most general (protocol) to most specific (gateway).
It is not possible to set metrics for exporting RIP routes into RIP.
Attempts to do this are silently ignored.
If no export policy is specified, RIP and interface routes are
exported into RIP.
If any policy is specified the defaults are overridden; it
is necessary to explicitly specify everything that should be exports.
RIP version 1 assumes that all subnets of the shared network
have the same subnet mask so they are only able to propagate subnets
of that network. RIP version 2 removes that restriction and is
capable of propagating all routes when not sending version 1
compatible updates.
To announce routes which specify a next hop of the loopback
interface (that is, static and internally generated default routes) via
RIP, it is necessary to specify the metric at some level in
the export clause. Just setting a default metric for
RIP is not sufficient. This is a safeguard to verify
that the announcement is intended.
It is not possible to create OSPF intra- or inter-area routes by
exporting routes from the gated routing table into OSPF. It is only
possible to export from the gated routing table into OSPF ASE routes.
It is also not possible to control the propagation of OSPF routes
within the OSPF protocol.
There are two types of OSPF ASE routes, type 1 and type
2, see the OSPF protocol
configuration for a detailed explanation of the two types. The
default type is specified by the defaults subclause of
the ospf clause. This may be overridden by a
specification on the export statement.
OSPF ASE routes also have the provision to carry a tag.
This is an arbitrary 32-bit number that can be used on OSPF routers to
filter routing information. See
``The OSPF statement''
for detailed information on OSPF tags. The
default tag specified by the ospfdefaults
clause may be overridden by a tag specified on the export
statement.
Specifying the source
The export list specifies export based on the origin of a route and
the syntax varies depending on the source.
On systems with the routing socket,
routes learned from the routing socket are installed in the gated
routing table with a protocol of kernel. These routes
may be exported by referencing this protocol. This is useful
when it is desirable to have a script install routes with the
route command and propagate them to other routing
protocols.
These statements allow routes to be exported that
are referenced only by protocol:
When BGP is configured, all routes are assigned an AS path when they
are added to the routing table. For all interior routes this AS path
specifies IGP as the origin and no ASes in the AS path (the current AS
is added when the route is exported). For EGP routes this AS path
specifies EGP as the origin and the source AS as the AS path. For BGP
routes, the AS path is stored as learned from BGP.
Both OSPF and RIP version 2 currently support tags, all other
protocols always have a tag of zero. The source of exported routes
may be selected based on this tag. This is useful when routes are
classified by tag when the are exported into a given routing protocol.
Route aggregation
Route aggregation is a method of generating a more general route given
the presence of a specific route. It is used, for example, at an
autonomous system border to generate a route to a network to be
advertised via EGP given the presence of one or more subnets of that
network learned via RIP.
Older versions of gated automatically
performed this function, generating an aggregate route to a
natural network (using the old Class A, B and C concept)
given an interface to a subnet of that natural network.
However that was not always the correct thing to do, and with the
advent of classless interdomain routing (CIDR)
it is even more frequently the
wrong thing to do, so aggregation must be explicitly configured. No
aggregation is performed unless explicitly requested in an
aggregate statement.
Route aggregation is also used by regional and national networks to
reduce the amount of routing information passed around. With careful
allocation of network addresses to clients, regional networks can just
announce one route to regional networks instead of hundreds.
Aggregate routes are not actually used for packet forwarding by the
originator of the aggregate route, only by the receiver (if it
wishes). A router receiving a packet which does not match one of the
component routes which led to the generation of an aggregate route is
supposed to respond with an ICMP network unreachable
message. This is to prevent packets for unknown component routes from
following a default route into another network where they would be
forwarded back to the border router, and around and around again and
again, until their TTL expires. Sending an unreachable message for a
missing piece of an aggregate is only possible on systems with support
for reject routes.
A slight variation of aggregation is the generation of a route based
on the existence of certain conditions. This is sometimes known as
the route of last resort. This route inherits the next hops
and aspath from the contributor specified with the lowest (most
favorable) preference. The most common usage for this is to generate
a default based on the presence of a route from a peer on a
neighboring backbone.
Aggregation and generation syntax
aggregatedefault
| ( network [ ( maskmask ) | ( masklennumber ) ] )
[ preferencepreference ] [ brief ] { proto [ all | direct | static | kernel | aggregate | proto ]
[ ( asautonomous system ) | ( tagtag )
| ( aspathaspath_regexp ) ]
restrict ;
proto [ all | direct | static | kernel | aggregate | proto ]
[ ( asautonomous system ) | ( tagtag )
| ( aspathaspath_regexp ) ]
[ preferencepreference ] { route_filter [ restrict | ( preferencepreference ) ] ; }; };
Routes that match the route filters are called contributing
routes. They are ordered according to the aggregation preference that
applies to them. If there are more than one contributing routes with
the same aggregating preference, the route's own preferences are used
to order the routes. The preference of the aggregate route will be
that of contributing route with the lowest aggregate preference.
preferencepreference
Specifies the preference to assign to the resulting aggregate
route. The default preference is 130.
brief
Used to specify that the AS path should be truncated to the
longest common AS path. The default is to build an AS path
consisting of SETs and SEQUENCE
of all contributing AS paths.
protoproto
In addition to the special protocols listed, the contributing
protocol may be chosen from among any of the ones supported (and
currently configured into) gated.
asautonomous_system
Restrict selection of routes to those learned from the specified
autonomous system.
tagtag
Restrict selection of routes to those with the specified tag.
aspathaspath_regexp
Restrict selection of routes to those that match the specified AS
path.
restrict
Indicates that these routes are not to be considered as
contributors of the specified aggregate. The specified protocol
may be any of the protocols supported by gated.
A route may only contribute to an aggregate route which is more
general than itself; it must match the aggregate under its mask.
Any given route may only contribute to one aggregate route, which will
be the most specific configured, but an aggregate route may contribute
to a more general aggregate.
Route filters
All the aggregation and generation formats allow route filters as shown below.
See
``Route filtering''
for a detailed explanation of how route filtering works.
When no route filtering is specified
(that is, when restrict is specified on the first line of a
statement), all routes from the specified source will match that
statement. If any filters are specified, only routes that match the
specified filters will be considered as contributors. Put
differently, if any filters are specified, an all restrict ;
is assumed at the end of the list.