gated.conf(4)gated.conf(4)NAME
gated.conf - GateDaemon Configuration Guide
SYNOPSISDESCRIPTION
Configuration Overview
· Introduction
· Statement Summary
· Preferences and Route Selection
· Trace Statements and Global Options
· Directive Statements
· Options Statements
· Interface Statements and Configuration
· Definition Statements
Protocol Statements
· Protocol Overview
· Interior gateway protocols (igps)
· RIP, HELLO, OSPF
· Exterior gateway protocols (egps)
· EGP, BGP
· ICMP Statement
· Redirect Statement
· Router Discovery Statement
· Kernel Interface
· Static Routes
Control Statements
· Route filtering
· Matching AS paths
· Route Importation
· Route Exportation
· Route Aggregation
Appendices
· Glossary of Terms
· References
Introduction to Configuring GateD
Syntax
The gated configuration file consists of a sequence of statements ter‐
minated by a semi-colon (;). Statements are composed of tokens sepa‐
rated 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 */.
Syntax description conventions
Keywords and special characters that the parser expects exactly are
displayed using bold type. Parameters are displayed in italic variable
definition style. Parameters shown in square brackets ([ and ]) are
used to show optional keywords and parameters. The vertical bar (|) is
used to indicate between a choice of optional parameters. Parentheses
(( and )) are used to group keywords and parameters when necessary.
For example, in the syntax description:
[ backbone | ( area area ) ]
The square brackets say that either parameter is optional. The keywords
are backbone and area. The vertical bar indicates that either "back‐
bone" or "area area" may be specified. Since area is in the variable
definition style, it is a parameter that needs to be provided.
Statement Grouping
The configuration statements and the order in which these statements
appear divide into options statements, interface statements, definition
statements, protocol statements, static statements, control statements,
and aggregate statements. Entering a statement out of order causes an
error when parsing the configuration file.
Two other types of statements do not fit in these categories: %direc‐
tive statements and %trace statements. These statements provide
instructions to the parser and control tracing from the configuration
file. They do not relate to the configuration of any protocol and may
occur anywhere in the gated.conf file.
Statement Summary
A summary table of the configuration statements (in the configuration
statement summary) lists each GateD configuration statement by name,
identifies the statement type, and provides a short synopsis of the
command function. More detailed definitions and descriptions of each of
the eight classes of GateD statements follow in separate sections.
GateD Configuration Statement Summary
The GateD configuration commands are summarized below. The table lists
each command by name, identifies the statement type, and gives a synop‐
sis of the statement function:
Summary of GateD Configuration Statements
%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 RIP protocol.
hello (protocol) enables HELLO protocol.
isis (protocol) enables ISIS protocol.
kernel (protocol) configures kernel interface
options.
ospf (protocol) enables OSPF protocol.
egp (protocol) enables EGP protocol.
bgp (protocol) enables BGP protocol.
redirect (protocol) configures the processing of ICMP
redirects.
icmp (protocol) configures the processing of gen‐
eral ICMP packets.
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. Pref‐
erence may not be used to control the selection of routes within an
igp, this is accomplished automatically by the protocol based on met‐
ric. 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. (See Glos‐
sary of Terms: Preference.) The preference value is an arbitrarily
assigned value used to determine the order of routes to the same desti‐
nation in a single routing database. The active route is chosen by the
lowest preference value. Some protocols implement a second preference
(preference2), sometimes referred to as a tie-breaker.
Selecting 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.
· A route with an AS path is preferred over one without an
AS path.
· If the AS paths and origins are identical, the route with
the lower metric is preferred.
· A route with an AS path origin of igp is preferred over a
route with an AS path origin of egp. Least preferred is an
AS path with an unknown origin.
· 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.
Preference Of Defined by Statement Default
────────────────────────────────────────────────────────────────────
direct connected networks interface 0
OSPF routes ospf 10
IS-IS level 1 routes isis level 1 15
IS-IS level 2 routes isis level 2 18
internally generated default gendefault 20
redirects redirect 30
routes learned via route socket kernel 40
static routes from config static 60
ANS SPF (SLSP) routes slsp 70
HELLO routes hello 90
RIP routes rip 100
point-to-point interface 110
routes to interfaces that are down interfaces 120
aggregate/generate routes aggregate/generate 130
OSPF AS external routes ospf 150
BGP routes bgp 170
EGP egp 200
Sample Preference Specifications
interfaces {
interface 138.66.12.2 preference 10 ;
} ;
rip yes {
preference 90 ;
} ;
import proto rip gateway 138.66.12.1 preference 75 ;
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 statement. The preference set on the interface statement
applies only to the route to that interface.
Trace Statements
Trace statements control tracing options. The GateD tracing options may
be configured at many levels. Tracing options include the file specifi‐
cations, 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 trac‐
ing options. At each level tracing specifications override the inher‐
ited 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.
Global significance only
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.
Protocol significance
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 pol‐
icy 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.
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 poten‐
tially 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 val‐
ues inherited by protocols specified in the configuration file are ini‐
tially inherited from the global options in effect as they are parsed,
unless they are overridden by more specific options. After the configu‐
ration file is read, tracing options that were not explicitly specified
are inherited from the global options in effect at the end of the con‐
figuration 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 allows 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 detail must be specified before send or recv. 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 detail on 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.
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 specifi‐
cation the trace flags are summed up, so specifying detail packets will
turn on full tracing for all packets.
Traceoptions syntax
traceoptions ["trace_file" [replace] [size size[k|m] files files]]
[control_options] trace_options [except trace_options] ;
traceoptions none ;
trace_file
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.
size size[k|m] files files
Limit the maximum size of the trace file to the speci‐
fied 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 (min‐
imum specification is 2).
control_options
Specifies options that control the appearance of trac‐
ing. Valid values are:
nostamp
Specifies that a timestamp should not be
prepended to all trace lines.
except trace_options
Used to enable a broad class of tracing and then dis‐
able 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 lan‐
guage parser about included files and the directories in which these
files reside. Directive statements are immediately acted upon by the
parser. Other statements terminate with a semi-colon (;), but directive
statements terminate with a newline. The two directive statements are:
%directory "directory"
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, such as files that do not begin
with "/". This statement does not actually change the
current the directory, it just specifies the prefix
applied to included file names.
%include "filename"
Identifies an include file. The contents of the file is
included in the gated.conf file at the point in the
gated.conf file where the %include directive is encoun‐
tered. If the filename is not fully qualified (does not
begin with "/"), it is considered to be relative to the
directory defined in the %directory directive. The
%include directive statement causes the specified file to
be parsed completely before resuming with this file.
Nesting up to ten levels is supported. The maximum nest‐
ing level may be increased by changing the definition of
FI_MAX in parse.h.
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.
The options statement syntax is:
options
[ nosend ]
[ noresolv ]
[ gendefault [ preference preference ] [ gateway gateway] ]
[ syslog [ upto ] log_level ]
[ mark time ]
;
The options list can contain one or more of the following options:
gendefault [ preference preference ] [ gateway gateway]
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. The the section on
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 HELLO 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 getnetby‐
name() 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 informa‐
tion 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 on sys‐
tems where setlogmask() is supported. The available log‐
ging levels and other terminology are as defined in the
setlogmask(3) manpage. The default is equivalent to sys‐
log upto info.
mark time
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 run‐
ning.
Interfaces Statement
Interface Syntax
interfaces {
options
[ strictinterfaces ]
[ scaninterval time ]
[ aliases-nh ( primary | lowestip | keepall ) ]
;
interface interface_list
[ preference preference ]
[ down preference preference ]
[ passive ]
[ simplex ]
[ reject ]
[ blackhole ]
[ alias primary address ]
[ aliases-nh ( primary | lowestip | keepall ) ]
;
define address
[ broadcast address ] | [ pointtopoint address ]
[ netmask mask ]
[ multicast ]
;
} ;
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 configura‐
tion language allow identification of interfaces using wildcard, inter‐
face type name, or delete word address. Be careful with the use of
interface names as future Unix operating systems may allow more than
one address per interface. The interface_list is a list of one or more
interface names including wildcard names (names without a number) and
names 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.
scaninterval time
Specifies how often GateD scans the kernel inter‐
face list for changes. The default is every 15
seconds on most systems, and 60 seconds on systems
that pass interface status changes through the
routing socket (BSD 4.4). Note that GateD will
also scan the interface list on receipt of a
SIGUSR2.
aliases-nh ( primary | lowestip | keepall )
Specifies which address GateD will install as the
next hop for interface routes when multiple
addresses are assigned to an interface like the
Service Guard environment. If is used, the primary
interface address (default) will be installed. If
is used, the address with the lowest IP address
will be installed. If is used, all interface
routes are kept in the kernel up to a maximum of
routes. This is a compile-time constant. This is
a global parameter that may be overridden for
interfaces using the interface option.
Note: The option is mandatory when gated is being
used in a Service Guard environment.
interface interface_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:
preference preference
Sets the preference for routes to this interface
when it is up and appears to be functioning prop‐
erly. The default preference is 0.
down preference preference
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 inter‐
face as simplex with the flag, on others it needs
to be specified in the configuration file. On sim‐
plex interfaces, packets from myself are assumed
to have been looped back in software and are not
used as an indication that the interface is func‐
tioning properly.
reject Specifies that the address of the interface which
matches these criteria will be used as the local
address when installing reject routes in the ker‐
nel. Should only be used with systems based on BSD
4.3 Tahoe or earlier which have installed a
reject/blackhole pseudo interface.
blackhole
Specifies that the address of the interface which
matches these criteria will be used as the local
address when installing reject routes in the ker‐
nel. Should only be used with systems based on BSD
4.3 Tahoe or earlier which have installed a
reject/blackhole pseudo interface.
alias primary address
Specifies a primary address for this interface.
This option overrides the address that GateD
determines to be primary.
aliases-nh ( primary | lowestip | keepall )
Specifies which address GateD will install as the
next hop for the route associated with this inter‐
face when multiple addresses are assigned to an
interface like the Service Guard environment. If
is used, the primary interface address (default)
will be installed. If is used, the address with
the lowest IP address will be installed. If is
used, all interface routes are kept in the kernel
up to a maximum of routes. This is a compile-time
constant. This parameter overrides the global
option for this interface.
Note: The option is mandatory when gated is being
used in a Service Guard environment.
define address
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:
broadcast address
Defines the interface as broadcast capable (Ether‐
net or Token Ring) and specifies the broadcast
address.
pointtopoint address
Defines the interface as a point-to-point inter‐
face (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 spec‐
ified after this pointtopoint keyword defines the
address on the local side of the interface.
An interface not defined as broadcast or point-to-point
is assumed to be nonbroadcast multiaccess (NBMA), such as
an X.25 network.
netmask mask
Specifies the subnetmask to be used on this inter‐
face. This is ignored on pointtopoint interfaces.
multicast
Specifies that the interface is multicast capable.
Interface lists
An interface list is a list of references to interfaces or groups of
interfaces. There are four methods available for referring to inter‐
faces. They are listed here from most general to most specific.
all This refers to all available interfaces.
Interface name wildcard
This refers to all the interfaces of the same type. Unix
interfaces consist of the name of the device driver, like
ie, and a unit number, like 0, 5 or 22. Reference to the
name contain only alphabetic characters and match any
interfaces that have the same alphabetic part.
For example, ie on a Sun would refer to all Interlan Eth‐
ernet interfaces, le would refer to all Lance Ethernet
interfaces. But ie would not match iel0.
Interface name
This refers to a specific interface, usually one physical
interface. These are specified as an alphabetic part fol‐
lowed by a numeric part. This will match one specific
interface. But be aware that on many systems, there can
be more than one protocol (IP) address on a given physi‐
cal 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 (10.0.0.51), or by symbolic hostname
(nic.ddn.mil). Note that a symbolic hostname reference is
only valid when it resolves to only one address. Use of
symbolic hostnames is not recommended.
If many interface lists are present in the configuration file with more
than one parameter, these parameters are collected at run-time to cre‐
ate the specific parameter list for a given interface. If the same
parameter is specified on more than one list, the parameters with the
most specific interface 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
The BSD 4.3 and later networking implementations allow four types of
interfaces. Some implementations allow multiple protocol addresses per
physical interface, these are mostly based on BSD 4.3 Reno or later.
loopback
This interface must have the address of 127.0.0.1. Pack‐
ets sent to this interface are sent back to the origina‐
tor. 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 addi‐
tional 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 multiaccess interface capable of a physical
level broadcast, such as Ethernet, Token Ring and FDDI.
This interface has an associated subnet mask and broad‐
cast 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 inter‐
face, it is only used by RIP version 1 and HELLO to
determine which subnets may be propagated to the router
on the other side of this interface.
nonbroadcast multiaccess or nbma
This type of interface is multiaccess, but not capable of
broadcast. And example would be frame relay and X.25.
This type of interface has a local address and a subnet
mask.
GateD insures that there is a route available to each IP interface that
is configured and up. Normally this this done by the ifconfig command
that configures the interface; GateD does it to insure 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 forward‐
ing 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 proto‐
cols, 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 inter‐
face 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 defi‐
nition statements are autonomoussystem, routerid and martians. if used,
autonomoussystem, routerid and martians must appear before any other
type of configuration statement in gated.conf file.
Autonomous System configuration
autonomoussystem autonomous_system [ loops number ] ;
Sets the autonomous system number of this router to be autonomous sys‐
tem. This option is required if BGP or EGP are in use. The AS number is
assigned by the Network Information Center (NIC).
Loops is only for protocols supporting AS paths, such as BGP. It con‐
trols the number of times this autonomous system may appear in an AS
path and defaults to 1 (one).
Router ID configuration
routerid host ;
Sets the router identifier for use by the BGP and OSPF protocols. The
default is the address of the first interface encountered by GateD. The
address of a non-point-to-point interface is preferred over the local
address of a point-to-point interface and an address on a loopback
interface that is not the loopback address (127.0.0.1) is most pre‐
ferred.
Martian configuration
martians {
host host [ allow ] ;
network [ allow ] ;
network mask mask [ allow ] ;
network masklen number [ allow ] ;
default [ allow ] ;
} ;
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 mar‐
tians, are rejected by the routing software. This command allows addi‐
tions to the list of martian addresses. See the section on Route Fil‐
tering for more information on specifying ranges. Also, the allow
parameter may be specified to explicitly allow a subset of a range that
was disallowed.
Sample Definition Statements
options gendefault ;
autonomoussystem 249 ;
interface 128.66.12.2 passive ;
martians {
0.0.0.26
};
The statements in the sample 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 exte‐
rior 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 acro‐
nym 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 consid‐
ered unreachable and GateD discards the route. RIP assumes the
best route is the one that uses the fewest gateways which 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.
HELLO
HELLO , another interior protocol, uses delay as the deciding fac‐
tor in choosing the best route. Round-trip time is the length of
time it takes a datagram to travel from the source and destina‐
tion. HELLO is historically significant for the Internet as it was
the protocol used among the original prototype NSFNET backbone
fuzzball gateways. Today, like fuzzballs, HELLO is a little-used
protocol.
An earlier version of the HELLO protocol is described in RFC 891.
OSPF Open Shortest Path First is a link-state protocol. OSPF is better
suited than RIP for complex networks with many routers. OSPF pro‐
vides equal cost multipath routing.
OSPF is described in RFC 1583, the MIB is defined in RFC 1253.
Other related documents are RFC 1245, RFC 1246 and RFC 1370.
Exterior Routing Protocols
Exterior protocols are used to exchange routing information between au‐
tonomous systems. Exterior protocols are only required when an autono‐
mous 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 sys‐
tem to another autonomous system need to run an exterior routing proto‐
col. 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 archi‐
tecture, EGP, an exterior routing protocol which assumes a hierar‐
chical 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 autono‐
mous 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, organiza‐
tional, or security (policy) considerations in the routing deci‐
sion. 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 sup‐
plement a statically configured default router. This is the pre‐
ferred 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 gateway protocols is the Routing
Information Protocol (RIP). RIP is an implementation of a distance-vec‐
tor, or Bellman-Ford routing protocol for local networks. It classi‐
fies routers as active and passive (silent). Active routers advertise
their routes (reachability information) to others; passive routers lis‐
ten and update their routes based on advertisements, but do not adver‐
tise. Typically, routers run RIP in active mode, while hosts use pas‐
sive mode.
A router running RIP in active mode broadcasts updates at set inter‐
vals. 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
etc. 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.
As delivered with most UNIX systems, RIP is run by the routing daemon,
routed (pronounced route-"d"). A RIP routing daemon 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 implemen‐
tations, if a gateway is not heard from for 180 seconds, all routes
from that gateway are deleted from the routing database. This 180 sec‐
ond interval also applies to deletion of specific routes.
RIP version 2 (more commonly known as RIP II) add additional capabili‐
ties to RIP. Some of these capabilities are compatible with RIP I and
some are not. To avoid supplying information to RIP I routes that could
be misinterpreted, RIP II can only use noncompatible features when its
packets are multicast. On interfaces that are not capable of IP multi‐
cast, RIP I compatible packets are used that do not contain potentially
confusing information.
Some of the most notable RIP II enhancements are:
Next hop
The primary ones are 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.
RIP I routers will ignore next hop information in RIP II pack‐
ets. This may result in packets crossing a network twice, which
is exactly what happens with RIP I. So this information is pro‐
vided in RIP I compatible RIP II packets.
Network Mask
RIP I assumes that all subnetworks of a given network have the
same network mask. It uses this assumption to calculate the net‐
work masks for all routes received. This assumption prevents
subnets with different netmasks from being included in RIP pack‐
ets. RIP II adds the ability to explicitly specify the network
mask with each network in a packet.
While RIP I routers will ignore the network mask in RIP II pack‐
ets, their calculation of the network mask will quite possibly
be wrong. For this reason, RIP I compatible RIP II packets must
not contain networks that would be misinterpreted. These net‐
work must only be provided in native RIP II packets that are
multicast.
Authentication
RIP II packets may also contain one of two types of authentica‐
tion string that may be used to verify the validity of the sup‐
plied routing data. Authentication may be used in RIP I compati‐
ble RIP II packets, but be aware that RIP I 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 incom‐
patible ways in future releases. This method uses the MD5 algo‐
rithm to create a crypto-checksum of a RIP packet and an authen‐
tication 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 authentica‐
tion 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-I and network masks
RIP-I 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 subnet‐
ted (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 sub‐
net.
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 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
rip yes | no | on | off [ {
broadcast ;
nobroadcast ;
nocheckzero ;
preference preference ;
defaultmetric metric ;
query authentication [none | [[simple|md5] password]] ;
interface interface_list
[noripin] | [ripin]
[noripout] | [ripout]
[metricin metric]
[metricout metric]
[version 1]|[version 2 [multicast|broadcast]]
[[secondary] authentication [none | [[simple|md5] password]] ;
trustedgateways gateway_list ;
sourcegateways gateway_list ;
traceoptions trace_options ;
} ] ;
The rip statement enables or disables RIP. 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. Nor‐
mally RIP will reject packets where the reserved fields
are zero.
preference preference
Sets the preference for routes learned from RIP. The
default preference is 100. This preference may be over‐
ridden by a preference specified in import policy.
defaultmetric metric
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.
query authentication [none | [[simple|md5] password]] ;
Specifies the authentication required of query packets
that do not originate from routers. The default is none.
interface interface_list
Controls various attributes of sending RIP on specific
interfaces. See the section on interface list specifica‐
tion 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 first
one one which RIP output is configured. This limitation
is required because of the way the Unix kernel operates.
It will hopefully be removed in a future release.
The possible parameters are:
noripin
Specifies that RIP packets received via the speci‐
fied interface will be ignored. The default is to
listen to RIP packets on all nonloopback inter‐
faces.
ripin This is the default. This argument may be neces‐
sary 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 nonbroadcast 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 it is desired to send RIP on point-to-point
interfaces and may be necessary when noripin is
used on a wildcard interface descriptor.
metricin metric
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 abso‐
lute 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.
metricout metric
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.
[secondary] authentication [none | [simple|md5] password]
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 authentica‐
tion type defaults to simple. The password should
be a quoted string with between 0 and 16 charac‐
ters.
If secondary is specified, this defines the sec‐
ondary authentication. If omitted, the primary
authentication is specified. The default is pri‐
mary authentication of none and no secondary
authentication.
trustedgateways gateway_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.
sourcegateways gateway_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.
traceoptions trace_options
Specifies the tracing options for RIP. (See Trace State‐
ments and the RIP specific tracing options below.)
Tracing options
The policy option logs info whenever a new route is announce, the met‐
ric 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 Hello Protocol
It is really better not to use HELLO unless you have a specific need
for it. We plan to drop it some time around GateD 4.0.
The HELLO protocol is an interior protocol that uses a routing metric
based on the length of time it takes a packet to make the trip between
the source and the destination. HELLO packets carry timestamp informa‐
tion which allows receivers to compute the shortest delay paths to des‐
tinations. The "best" route is the route with the shortest time delay.
The unit of time used in HELLO is milliseconds. If a HELLO update
packet takes less than 100 milliseconds to travel between two routers,
a minimum value of 100 is used for that hop. Thus on networks built of
high-speed interfaces HELLO essentially defaults to using hop counts.
As in any routing algorithm, HELLO cannot change routes too rapidly or
it would be unstable. To avoid instabilities, implementations of HELLO
build in hysteresis and "hesitate" to change routes until they have
confidence that the change will be lasting.
By default HELLO, like RIP, uses the kernel interface metric set by the
ifconfig command to influence metric added to routes as they are
installed in the routing table (metricin). Since the kernel interface
metric is in hops, it must be translated into HELLOs millisecond met‐
ric. In order to do that, the following table is used:
Hops HELLO metric
0 0
1 100
2 148
3 219
4 325
5 481
6 713
7 1057
8 1567
9 2322
10 3440
11 5097
12 7552
13 11190
14 16579
15 24564
16 30000
HELLO and network masks
HELLO 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 subnet‐
ted (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 sub‐
net.
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 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 Hello Statement
hello yes | no | on | off [ {
broadcast ;
nobroadcast ;
preference preference ;
defaultmetric metric ;
interface interface_list
[nohelloin] | [helloin]
[nohelloout] | [helloout]
[metricin metric]
[metricout metric] ;
trustedgateways gateway_list ;
sourcegateways gateway_list ;
traceoptions trace_options ;
} ] ;
the hello statement enables or disables HELLO. If the hello statement
is not specified, the default is hello off. If enabled, HELLO will
assume nobroadcast when there is only one interface and broadcast when
there is more than one interface.
broadcast
Specifies that HELLO 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 HELLO. 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 HELLO 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.
preference preference
Sets the preference for routes learned from HELLO. The
default preference is 90. This preference may be overrid‐
den by a preference specified in import policy.
defaultmetric metric
Defines the metric used when advertising routes via HELLO
that were learned from other protocols. If not specified,
the default value is 30000 (unreachable). This choice of
values requires you to explicitly specify a metric in
order to export routes from other protocols into HELLO.
This metric may be overridden by a metric specified in
export policy.
interface interface_list
Controls various attributes of sending HELLO on specific
interfaces. See the section on interface list specifica‐
tion for the description of the interface_list.
Note that if there are multiple interfaces configured on
the same subnet, HELLO updates will only be sent from
first one one which HELLO output is configured. This lim‐
itation is required because of the way the Unix kernel
operates. It will hopefully be removed in a future
release.
The possible parameters are:
nohelloin
Specifies that HELLO packets received via the
specified interface will be ignored. The default
is to listen to HELLO on all nonloopback inter‐
faces.
helloin
This is the default. This argument may be neces‐
sary when nohelloin is used on a wildcard inter‐
face descriptor.
nohelloout
Specifies that no HELLO packets will be sent on
the specified interfaces. The default is to send
HELLO on all broadcast and nonbroadcast interfaces
when in broadcast mode. The sending of HELLO on
point-to-point interfaces must be manually config‐
ured.
helloout
This is the default. This argument is necessary
when it is desired to send HELLO on point-to-point
interfaces and may be necessary when nohelloin is
used on a wildcard interface descriptor.
metricin metric
Specifies the HELLO 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 HELLO 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 HELLO routes learned via the specified
interface(s) less than HELLO routes from other
interfaces.
metricout metric
Specifies the HELLO 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 HELLO routes over
this router.
trustedgateways gateway_list
Defines the list of gateways from which HELLO 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.
sourcegateways gateway_list
Defines a list of routers to which HELLO 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.
traceoptions trace_options
Specifies the tracing options for HELLO. (See Trace
Statements and the HELLO specific tracing options below.)
The default preference is 90. The default metric is 30000.
Tracing options
The policy option logs info whenever a new route is announce, the met‐
ric being announced changes or a route goes or leaves holddown.
Packet tracing options (which may be modified with detail, send and/or
recv):
packets
All HELLO packets
The OSPF Protocol
Open Shortest Path Routing (OSPF) is a shortest path first (SPF) or
link-state protocol. OSPF is an interior gateway protocol that distrib‐
utes 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 mul‐
tipath 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 (the usable
interfaces and reachable neighbors of the router) 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 Auton‐
omous 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 met‐
rics. 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 short‐
est paths with itself as the root. This shortest-path tree gives the
route to each destination in the AS. Externally derived routing infor‐
mation appears on the tree as leaves. The link-state advertisement for‐
mat distinguishes between information acquired from external sources
and information acquired from internal routers, so there is no ambigu‐
ity 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 the OSPF 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 (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 OSPF of
the area, so it is not possible to override this. Although it is possi‐
ble 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 contigu‐
ous and the backbone is no exception. To permit maximum flexibility,
OSPF allows the configuration of virtual links enable the backbone area
to appear contiguous despite the physical reality.
All routers in an area must agree on the parameters of that area. 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 the configu‐
ration of that area. 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 guaran‐
tees that routing information is only imported from trusted routers, to
protect the Internet and its users. A variety of authentication schemes
can be used but a single scheme must be configured for each area. This
enables some areas to use much stricter authentication than others.
OSPF protocol exchanges may be authenticated. Authentication guarantees
that routing information is imported only from trusted routers, to pro‐
tect the Internet and its users. There are two authentication schemes
available. The first uses a simple authentication key of up to 8 char‐
acters and is standardized. The second is still experimental and uses
the MD5 algorithm and an authentication key of up to 16 characters.
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 OSPF Statement
ospf yes | no | on | off [ {
defaults {
preference preference ;
cost cost ;
tag [ as ] tag ;
type 1 | 2 ;
} ;
exportlimit routes ;
exportinterval time ;
traceoptions trace_options ;
monitorauthkey authkey ;
monitorauth none | ( [ simple | md5 ] authkey ) ;
backbone | ( area area ) {
authtype 0 | 1 | none | simple ;
stub [ cost cost] ;
networks {
network [ restrict ] ;
network mask mask [ restrict ] ;
network masklen number [ restrict ] ;
host host [ restrict ] ;
} ;
stubhosts {
host cost cost ;
} ;
interface interface_list; [cost cost ] {
interface_parameters
} ;
interface interface_list nonbroadcast [cost cost ] {
pollinterval time ;
routers {
gateway [ eligible ] ;
} ;
interface_parameters
} ;
Backbone only:
virtuallink neighborid router_id transitarea area {
interface_parameters
} ;
} ;
} ] ;
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.
enable | disable ;
retransmitinterval time ;
transitdelay time ;
priority priority ;
hellointerval time ;
routerdeadinterval time ;
authkey auth_key ;
defaults
These parameters 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.
preference preference
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.
cost cost
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.
type 1 | 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 pol‐
icy.
ASE export rate
Because of the nature of OSPF, the rate at which ASEs are
flooded must be limited. These two parameters can be used to
adjust those rate limits.
exportinterval time
This specifies how often a batch of ASE link state
advertisements will be generated and flooded into
OSPF. The default is once per second.
exportlimit routes
This parameter specifies how many ASEs will be gener‐
ated and flooded in each batch. The default is 100.
traceoptions trace_options
Specifies the tracing options for OSPF. (See Trace Statements
and the OSPF specific tracing options below.)
monitorauthkey authkey
OSPF state may be queried using the ospf_monitor (This should be
a hyperlink) utility. This utility sends nonstandard OSPF pack‐
ets which generate a text response from OSPF. By default these
requests are not authenticated, if an authentication key is con‐
figured, the incoming requests must match the specified authen‐
tication key. No OSPF state may be changed by these packets, but
the act of querying OSPF can utilize system resources.
backbone
area area
Each OSPF router must be configured into at least one OSPF area.
If more than one area is configured, at least one must the be
backbone. The backbone may only be configured using the backbone
keyword, it may not be specified as area 0. The backbone inter‐
face may be a virtuallink.
authtype 0 | 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 authenti‐
cation, or simple (1) for simple password authentication.
stub [ cost cost]
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 net‐
work LSAs are not advertised. Intra-area LSAs that do not
fall into any range are also advertised as summary net‐
work 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 the sec‐
tion on Route Filtering for more detail 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 speci‐
fied here.
It is also useful to assign a additional address to the
loopback interface (one not on the 127 network) and
advertise it as a stub hosts. 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.
interface interface_list [cost cost ]
This form of the interface clause is used to configure a
broadcast (which requires IP multicast support) or a
point-to-point interface. See the section on interface
list specification for the description of the inter‐
face_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 nonzero value may be specified.
Interface parameters common to all types of interfaces
are:
retransmitinterval time
The number of seconds between link state adver‐
tisement retransmissions for adjacencies
belonging to this interface.
transitdelay time
The estimated number of seconds required to
transmit a link state update over this inter‐
face. Transitdelay takes into account transmis‐
sion and propagation delays and must be greater
than 0.
priority priority
A number between 0 and 255 specifying the pri‐
ority 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.
hellointerval time
The length of time, in seconds, between Hello
packets that the router sends on the interface.
routerdeadinterval time
The number of seconds not hearing Hello packets
of a router before the neighbors of the router
will declare it down.
authkey auth_key
Used by OSPF authentication to generate and
verify the authentication field in the OSPF
header. The authentication key can be config‐
ured 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 multi‐
cast mechanism. Although, some implementations
of IP multicasting for Unix have a bug that
precludes the use of IP multicasting on these
interfaces. Gated will detect this condition
and fall back to using sending unicast OSPF
packets to this point-to-point neighbor.
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. This
option may also be used to eliminate warnings
when Gated detects the bug mentioned above.
interface interface_list nonbroadcast [cost cost ]
This form of the interface clause is used to specify a
nonbroadcast interface on a nonbroadcast multiaccess
(NBMA) media. Since an OSPF broadcast media must support
IP multicasting, a broadcast capable media, such as Eth‐
ernet, that does not support IP multicasting must be con‐
figured as a nonbroadcast interface.
A nonbroadcast interface supports any of the standard
interface clauses listed above, plus the following two
that are specific to nonbroadcast interfaces:
pollinterval time
Before adjacency is established with a neigh‐
bor, OSPF packets are sent periodically at the
specified pollinterval.
routers
By definition it is not possible to send broad‐
cast packets to discover OSPF neighbors on a
nonbroadcast, so all neighbors must be config‐
ured. The list includes one or more neighbors
and an indication of their eligibility to
become a designated router.
virtuallink neighborid router_id transitarea area
Virtual links are used to establish or increase connec‐
tivity of the backbone area. The neighborid is the
router_id of the other end of the virtual link. The tran‐
sit area specified must also configured on this system.
All standard interface parameters defined by the inter‐
face clause above may be specified on a virtual link.
Tracing options
In addition to the following OSPF specific trace flags, OSPF supports
the state which traces interface and neighbor state machine transi‐
tions.
lsabuild
Link State Advertisement creation
spf Shortest Path First (SPF) calculations
Packet tracing options (which may be modified with detail, send and
recv):
hello OSPF HELLO packets which are used to determine neighbor
reachability.
dd OSPF Database Description packets which are used in syn‐
chronizing OSPF databases.
request
OSPF Link State Request packets which are used in syn‐
chronizing OSPF databases.
lsu OSPF Link State Update packets which are used in synchro‐
nizing OSPF databases.
ack OSPF Link State Ack packets which are used in synchroniz‐
ing 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 autono‐
mous systems. Unlike interior protocols, EGP propagates only reachabil‐
ity indications, not true metrics. EGP updates contain metrics, called
distances which range from 0 to 255. GateD will only compare EGP dis‐
tances learned from the same AS. them.
Before EGP sends routing information to a remote router, it must estab‐
lish an adjacency with that router. This is accomplished by an
exchange of Hello (not to be confused with the 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 routes of that
neighbor from its database.
The EGP Statement
egp yes | no | on | off
[ {
preference preference ;
defaultmetric metric ;
packetsize number ;
traceoptions trace_options ;
group
[ peeras autonomous_system ]
[ localas autonomous_system ]
[ maxup number ]
{
neighbor host
[ metricout metric ]
[ preference preference ]
[ preference2 preference ]
[ ttl ttl ]
[ nogendefault ]
[ importdefault ]
[ exportdefault ]
[ gateway gateway ]
[ lcladdr local_address ]
[ sourcenet network ]
[ minhello | p1 time ]
[ minpoll | p2 time ]
[ traceoptions trace_options ]
;
} ;
} ] ;
preference preference
Sets the preference for routes learned from RIP. The
default preference is 200. This preference may be over‐
ridden by a preference specified on the group or neighbor
statements or by import policy.
defaultmetric metric ;
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 export‐
ing routes to EGP neighbors. This metric may be overrid‐
den by a metric specified on the neighbor or group state‐
ments or in export policy.
packetsize maxpacketsize
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.
traceoptions trace_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 the EGP specific tracing options
below.)
group EGP neighbors must be specified as members of a group. A
group is usually used to group all neighbors in one au‐
tonomous system. Parameters specified on the group clause
apply to all of the subsidiary neighbors unless explic‐
itly 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 speci‐
fied 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 speci‐
fied, 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 usu‐
ally only used when masquerading as another au‐
tonomous 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.
neighbor neighbor_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 param‐
eters are optional.
preference preference
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.
preference2 preference
In the case of a preference tie, the second
preference, preference2 may be used to break
the tie. The default value is 0.
metricout metric
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 neigh‐
bors.
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.
gateway gateway
If a network is not shared with a neighbor,
gateway specifies a router on an attached net‐
work to be used as the next hop router for
routes received from this neighbor. This option
is only rarely used.
lcladdr local_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 gateway of
the neighbor 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.
sourcenet network
Specifies the network queried in the EGP Poll
packets. By default this is the network shared
with neighbors address specified. If there is
no network shared with the neighbor, one of the
network the neighbor is attached to 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.
p1 time
minhello time
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 pack‐
ets, GateD stops trying to acquire the neigh‐
bor. Setting a larger interval gives the neigh‐
bor a better chance to respond. Minhello is an
alias for the P1 value defined in the EGP spec‐
ification.
p2 time
minpoll time
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 spec‐
ification.
ttl ttl
By default, GateD sets the IP TTL for local
neighbors to one and the TTL for nonlocal
neighbors to 255. This option is provided when
attempting to communicate with improperly func‐
tioning routers that ignore packets sent with a
TTL of one.
traceoptions trace_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 the EGP specific tracing options
below.)
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 BGP Protocol
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 au‐
tonomous systems as well as between transit and stub autonomous sys‐
tems. 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 rout‐
ing 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 prefer‐
ence 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 capabil‐
ity 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 ver‐
sion 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 neigh‐
bor 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 consid‐
ered 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 met‐
ric 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 connec‐
tion, 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 for‐
warding. 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. This forwarding address is used to look up an
immediate next hop in routes of the IGP. 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 com‐
mon 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 con‐
nect if an appropriate group has been configured with an allow clause.
The BGP Statement
bgp yes | no | on | off
[ {
preference preference ;
defaultmetric metric ;
traceoptions trace_options ;
group type ( external peeras autonomous_system )
| ( internal peeras autonomous_system )
| ( igp peeras autonomous_system proto proto )
| ( routing peeras autonomous_system proto proto
interface interface_list )
| ( test peeras autonomous_system )
{
allow {
network
network mask mask
network masklen number
all
host host
} ;
peer host
[ metricout metric ]
[ localas autonomous_system ]
[ nogendefault ]
[ gateway gateway ]
[ preference preference ]
[ preference2 preference ]
[ lcladdr local_address ]
[ holdtime time ]
[ version number ]
[ passive ]
[ sendbuffer number ]
[ recvbuffer number ]
[ indelay time ]
[ outdelay time ]
[ keep [ all | none ] ]
[ showwarnings ]
[ noauthcheck ]
[ noaggregatorid ]
[ keepalivesalways ]
[ v3asloopokay ]
[ nov4asloop ]
[ logupdown ]
[ ttl ttl ]
[ traceoptions trace_options ]
;
} ;
} ] ;
external | internal | igp | test
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 met‐
ric.
preference preference
Sets the preference for routes learned from RIP. The
default preference is 170. This preference may be over‐
ridden by a preference specified on the group or peer
statements or by import policy.
defaultmetric metric
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.
traceoptions trace_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 the BGP specific tracing options
below.)
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 com‐
bination of type and peer autonomous system. There are four possible
group types:
group type external peeras autonomous_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 local interfaces of the machine . By default
no metric is included in external advertisements, and the
next hop is computed with respect to the shared inter‐
face.
group type internal peeras autonomous_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 read‐
vertised with the received metric.
group type igp peeras autonomous_system proto proto
An internal group that runs in association with an inte‐
rior 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 inter‐
nal IGP peers are sent only a subset of the routes which
the IGP is exporting, the export policy of the IGP is
used. There is no need to implement the "don't routes
from peers in the same group" constraint since the adver‐
tised routes are routes that IGP already exports.
group type routing peeras autonomous_system proto proto inter‐
face interface_list
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. A type routing group com‐
putes immediate next hops for these routes by using the
BGP next hop which arrived with the route as a forwarding
address. The forwarding address is to be resolved via
the routing information of an internal protocol. In
essence, internal BGP is used to carry AS external
routes, while the IGP is expected to only carry AS inter‐
nal 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 propa‐
gated 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.
group type test peeras autonomous_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 net‐
work. 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 current next hop of the local machine. All routing
information advertised by and received from a test peer
is discarded, and all BGP routes that can be advertised
are sent back to the test peer. Metrics from EGP-derived
and BGP-derived routes are forwarded in the advertise‐
ment. 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 sub‐
clause 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 con‐
figured 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 detail
on specifying the network/mask pairs, see the section on
Route Filtering.
peer host
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 spec‐
ify 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.
metricout metric
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.
localas autonomous_system
Identifies the autonomous system which GateD is repre‐
senting 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.
gateway gateway
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.
preference preference
Specifies the preference used for routes learned from
these peers. This can differ from the default BGP prefer‐
ence 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.
preference2 preference
In the case of a preference tie, the second preference,
preference2 may be used to break the tie. The default
value is 0.
lcladdr local_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 gateway of the peer 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.
holdtime time
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.
version version
Specifies the version of the BGP protocol to use with
this peer. If not specified, the highest supported ver‐
sion 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.
sendbuffer buffer_size
recvbuffer buffer_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 con‐
figures the maximum supported. These parameters are not
needed on normally functioning systems.
indelay time
outdelay time
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 fea‐
tures are disabled.
keep all
Used to retain routes learned from a peer even if the AS
paths of the routes contain one of our exported AS num‐
bers.
showwarnings
Causes GateD to issue warning messages when receiving
questionable BGP updates such as duplicate routes and/or
deletions of nonexisting 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 aggre‐
gate routes with different AS paths.
keepalivesalways
Causes gated to always send keepalives, even when an
update could have correctly substituted for one. This
allows interoperability with routers that do not com‐
pletely obey the protocol specifications on this point.
v3asloopokay
By default gated will not advertise routes whose AS path
is looped (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 adver‐
tised to version 4 external peers. This can be useful to
avoid advertising such routes to peer which would incor‐
rectly 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.
ttl ttl
By default, GateD sets the IP TTL for local peers to one
and the TTL for nonlocal peers to 255. This option mainly
is provided when attempting to communicate with improp‐
erly functioning routers that ignore packets sent with a
TTL of one. Not all kernels allow the TTL to be speci‐
fied for TCP connections.
traceoptions trace_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 the BGP specific
tracing options below.)
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 rela‐
tionship.
update BGP UPDATE packets which are used to pass network reacha‐
bility information.
keepalive
BGP KEEPALIVE packets which are used to verify peer
reachability.
The ICMP Statement
On systems without the BSD routing socket, gated listens to ICMP mes‐
sages received by the system. Currently gated only does processing on
ICMP redirect packets, but more functionality may be added in the
future, such as support for the router discovery messages. Processing
of ICMP redirect messages is handled by the redirect statement.
Currently the only reason to specify the icmp statement is to be able
to trace the ICMP messages that gated receives.
The ICMP statement
icmp {
traceoptions trace_options ;
}
traceoptions trace_options ;
Specifies the tracing options for ICMP. (See Trace Statements
and the ICMP specific tracing options below.)
Tracing options
Packet tracing options (which may be modified with detail and recv):
packets
All ICMP packets received.
redirect
Only ICMP REDIRECT packets received.
routerdiscovery
Only ICMP ROUTER DISCOVERY packets received.
info Only ICMP informational packets, which include mask
request/response, info request/response, echo
request/response and time stamp request/response.
error Only ICMP error packets, which include time exceeded,
parameter problem, unreachable and source quench.
Redirect Processing
The redirect code is passed ICMP or ISO redirects learned by monitoring
ICMP messages, or via the routing socket on systems that support it. It
processes the redirect request and decides whether to accept the redi‐
rect. 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 fig‐
ure out if the kernel forwarding table has been modified. On systems
where ICMP messages are monitored this is accomplished by trying to
second guess what the kernel would have done with the redirect. On sys‐
tems with the routing socket, the kernel provides and indication of
whether the redirect was accepted; GateD ignores redirects that were
not processed.
If GateD has determined that the state of the kernel forwarding table
has been changed, the necessary requests to the kernel are made to
restore the correct state.
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 state of the
kernel. Because of the mechanisms involved, there will be windows
where the effects of redirects are present in the kernel.
By default, GateD removes redirects when actively participating in an
interior gateway protocol (RIP, HELLO, OSPF or IS-IS). It is not possi‐
ble to enable redirects once they have been automatically disabled.
Listening to RIP or HELLO in nobroadcast mode does not cause redirects
to be ignored, nor does the use of EGP and BGP. Redirects must be manu‐
ally configured off in these cases.
Note that in accordance with the latest IETF Router Requirements docu‐
ment, 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 redi‐
rects, only from listening to them.
The Redirect Statement
redirect yes | no | on | off
[ {
preference preference ;
interface interface_list
[ noredirects ] | [redirects ] ;
trustedgateways gateway_list ;
traceoptions trace_options ;
} ] ;
preference
Sets the preference for a route learned from a redirect.
The default is 30.
interface interface_list
The interface statement allows the enabling and disabling
of redirects on an interface-by-interface basis. See the
section on interface list specification for the descrip‐
tion of the interface_list. The possible parameters are:
noredirects
Specifies that redirects received via the spec‐
ified interface will be ignored. The default is
to accept redirects on all interfaces.
redirects
This is the default. This argument may be nec‐
essary when noredirects is used on a wildcard
interface descriptor.
trustedgateways gateway_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 net‐
work(s) are trusted to supply redirects. But if the
trustedgateways clause is specified only redirects from
the gateways in the list are accepted.
traceoptions trace_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 nonerror 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 to portions, the server portion which runs
on routers, and the client portion that runs on hosts. GateD treats
these much like two separate protocols, only one of which may be
enabled at a time.
The Router Discovery Server
The Router Discovery Server runs on routers and announces their exis‐
tence to hosts. It does this by periodically multicasting or broadcast‐
ing a Router Advertisement to each interface on which it is enabled.
These Router Advertisements contain a list of all the routers addresses
on a given interface and their preference for use as a default router.
Initially these Router Advertisements occur every few seconds, then
fall back to every few minutes. In addition, a host may send a Router
Solicitation to which the router will respond with a unicast Router
Advertisement (unless a multicast or broadcast advertisement is due
momentarily).
Each Router Advertisement contains a Advertisement Lifetime field indi‐
cating 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 Adver‐
tisement. When the Router advertisements are being sent to a net or
subnet broadcast, only the address associated with that net or subnet
is included.
The Router Discovery Server Statement
routerdiscovery server yes | no | on | off [ {
traceoptions trace_options ;
interface interface_list
[ minadvinterval time ]
[ maxadvinterval time ]
[ lifetime time ]
;
address interface_list
[ advertise ] | [ ignore ]
[ broadcast ] | [ multicast ]
[ ineligible ] | [ preference preference ]
;
} ] ;
traceoptions trace_options
Specifies the Router Discovery tracing options. (See
Trace Statements and the Router Discovery specific trac‐
ing options below.)
interface interface_list
Specifies the parameters that apply to physical inter‐
faces. Note a slight difference in convention from the
rest of GateD, interface specifies just physical inter‐
faces (such as le0, ef0 and en1), while address specifies
protocol (in this case IP) addresses.
Interface parameters are:
maxadvinterval time
The maximum time allowed between sending broad‐
cast 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 sec‐
onds).
minadvinterval time
The minimum time allowed between sending unso‐
licited broadcast or multicast Router Adver‐
tisements from the interface. Must be no less
than 3 seconds and no greater than maxadvinter‐
val. The default is 0.75 * maxadvinterval.
lifetime time
The lifetime of addresses in a Router Adver‐
tisement. Must be no less than maxadvinterval
and no greater than 2:30:00 (two hours, thirty
minutes or 9000 seconds). The default is 3 *
maxadvinterval.
address interface_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, inter‐
face 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 multi‐
casting, 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 Adver‐
tisement 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 Adver‐
tisement. If the system does not support IP
multicasting, the address(es) will not be
included. If the system supports IP multicast‐
ing, the default is to include the address(es)
in a multicast Router Advertisement if the
given interface supports IP multicasting. If
the given interface does not support IP multi‐
casting, the address(es) will be included in a
broadcast Router Advertisement.
preference preference
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.1) if IP multicasting is available and enabled, or on
the interface broadcast address. When starting up, or when reconfig‐
ured, a host may send a few Router Solicitations to the all-routers
multicast address, 224.0.0.2, or the interface broadcast address.
When a Router Advertisement with nonzero 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 Adver‐
tisement is not received to refresh these routes before the lifetime
expires.
The Router Discovery Client Statement
routerdiscovery client yes | no | on | off [ {
traceoptions trace_options ;
preference preference ;
interface interface_list
[ enable ] | [ disable ]
[ broadcast ] | [ multicast ]
[ quiet ] | [ solicit ]
;
} ] ;
traceoptions trace_options
Specifies the tracing options for OSPF. (See Trace State‐
ments and the OSPF specific tracing options below.)
preference preference ;
Specifies the preference of all Router Discovery default
routes. The default is 55.
interface interface_list
Specifies the parameters that apply to physical inter‐
faces. Note a slight difference in convention from the
rest of GateD, interface specifies just physical inter‐
faces (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 inter‐
face(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 Solicita‐
tions 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 per‐
formed.
solicit Specifies that initial Router Solicita‐
tions will be sent on this interface.
This is the default.
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 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 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 typ‐
ical kernel forwarding table take a nontrivial 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 know in ISO speak 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
in ISO speak 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.
Updating the Forwarding Table
There are two main methods of updating the kernel FIB, the ioctl()
interface and the routing socket interface. Their various characteris‐
tics are described here.
Updating the Forwarding Table with the ioctl interface
The ioctl interface to the forwarding table was introduced in BSD 4.3
and widely distributed in BSD 4.3. This is a one-way interface, it only
allows GateD to update the kernel forwarding table. It has several
other limitations:
Fixed subnet masks
The BSD 4.3 networking code assumed that all subnets of a
given network had the same subnet mask. This limitation
is enforced by the kernel. The network mask is not stored
in the kernel forwarding table, but determined when a
packet is forwarded by searching for interfaces on the
same network.
One way interface
GateD is able to update the kernel forwarding table, but
it is not aware of other modifications of the forwarding
table. GateD is able to listen to ICMP messages and guess
how the kernel has updated the forwarding table with
response to ICMP redirects.
Blind updates
GateD is not able to detect changes to the forwarding ta‐
ble resulting from the use of the route command by the
system administrator. Use of the route command on systems
that use the ioctl() interface is strongly discouraged
while GateD is running.
Changes not supported
In all known implementations, there is no change opera‐
tion supported, to change a route that exists in the ker‐
nel, the route must be deleted and a new one added.
Updating the Forwarding Table with the routing socket interface
The routing socket interface to the kernel forwarding table was intro‐
duced in BSD 4.3 Reno, widely distributed in BSD 4.3 Net/2 and improved
in BSD 4.4. This interface is simply a socket, similar to a UDP
socket, on which the kernel and GateD exchange messages. It has several
advantages over the ioctl() interface:
Variable subnet masks
The network mask is passed to the kernel explicitly. This
allows different masks to be used on subnets of the same
network. It also allows routes with masks that are more
general than the natural mask to be used. This is known
as classless routing.
Two way interface
Not only is GateD able to change the kernel forwarding
table with this interface, but the kernel can also report
changes to the forwarding table to GateD. The most inter‐
esting of these is an indication that a redirect has mod‐
ified the kernel forwarding table; this means that gated
no longer needs to monitor ICMP messages to learn about
redirects. Plus, there is an indication of whether the
kernel processed the redirect, GateD can safely ignore
redirect messages that the kernel did not process.
Updates visible
Changes to the routing table by other processes, includ‐
ing the route command are received via the routing
socket. This allows GateD to insure that the kernel for‐
warding table is in sync with the routing table. Plus it
allows the system administrator the ability to do some
operations with the route command while gated is running.
Changes supported
There is a functioning change message that allows routes
in the kernel to be atomically changed. Some early ver‐
sions of the routing socket code had bugs in the change
message processing. There are compilation time and con‐
figuration time options that cause delete and add
sequences to be used in lieu of change messages.
Expandable
New levels of kernel/GateD communications may be added by
adding new message types.
Reading the Forwarding Table
When GateD starts up it reads the kernel forwarding table and installs
corresponding routes in the routing table. These routes are called rem‐
nants and are timed out after a configured interval (which defaults to
3 minutes), or as soon as a more attractive route is learned. This
allows forwarding to occur during the time it takes the routing proto‐
cols to start learning routes.
There are three main methods for reading the forwarding table from the
kernel.
Reading forwarding table via kmem
On many systems, especially those based on BSD 4.3, GateD must have
knowledge of the kernel data structures and can go into the kernel to
read the current state of forwarding table. This method is slow and
subject to error if the kernel forwarding table is updated while GateD
is in the middle of reading it. This can happen if the system adminis‐
trator uses the route command, or an ICMP redirect message is received
while GateD is starting up.
Due to an oversight some systems, such as OSF/1, which are based on BSD
4.3 Reno or later, do not have the getkerninfo() system call described
below which allows GateD to read routes from the kernel without know
about kernel internal structures. On these systems it is necessary to
read the kernel radix tree from the kernel by poking around in kernel
memory. This is even more error prone than reading the hash based for‐
warding table.
Reading the forwarding table via getkerninfo/sysctl
Besides the routing socket, BSD 4.3 Reno introduced the getkerninfo()
system call. This call allows a user process (of which GateD is one) to
read various information from the kernel without knowledge of the ker‐
nel data structures. In the case of the forwarding table, it is
returned to gated atomically as a series of routing socket messages.
This prevents the problem associated with the forwarding table changing
while GateD is in the process of reading it.
BSD 4.4 changed the getkerninfo() interface into the sysctl() inter‐
face, which takes different parameters, but otherwise functions identi‐
cally.
Reading the forwarding table via OS specific methods
Some operating systems, for example SunOS 5, define their own method of
reading the kernel forwarding table. The SunOS 5 version is similar in
concept to the getkerninfo() method.
Reading the interface list
The kernel support subsystem of GateD is responsible for reading the
status of the kernel physical and protocol interfaces periodically.
GateD detects changes in the interface list and notifies the protocols
so they can start or stop instances or peers. The interface list is
read one of two ways:
Reading the interface list with SIOCGIFCONF
On systems based on BSD 4.3, 4.3 Reno and 4.3 Net/2 the interface is
used to read the kernel interface list. Using this method a list of
interfaces and some basic information about them is returned by the
call. Other information must be learned by issuing other ioctls to
learn the interface network mask, flags, MTU, metric, destination
address (for point-to-point interfaces) and broadcast address (for
broadcast capable interfaces).
GateD reads re-reads this list every 15 second looking for changes.
When the routing socket is in use, it also re-reads it whenever a mes‐
sages is received indicating a change in routing configuration.
Receipt of a SIGUSR2 signal also causes GateD to re-read the list. This
interval may be explicitly configured in the interface configuration.
Reading the interface list with sysctl
BSD 4.4 added the ability to read the kernel interface list via the
sysctl system call. The interface status is returned atomically as a
list of routing socket messages which GateD parses for the required
information.
BSD 4.4 also added routing socket messages to report interface status
changes immediately. This allows GateD to react quickly to changes in
interface configuration.
When this method is in use, GateD re-reads the interface list only once
a minute. It also re-reads it on routing table changes indications and
when a SIGUSR2 is received. This interval may be explicitly configured
in the interface configuration.
Reading interface physical addresses
Later version of the getkerninfo() and sysctl() interfaces return the
interface physical addresses as part of the interface information. On
most systems where this information is not returned, GateD scans the
kernel physical interface list for this information for interfaces with
set, assuming that their drivers are handled the same as Ethernet driv‐
ers. On some systems, such as SunOS 4 and SunOS 5, system specific
interfaces are used to learn this information
The interface physical addresses are useful for IS-IS, for IP proto‐
cols, they are not currently used, but may be in the future.
Reading kernel variables
At startup, GateD reads some special variables out of the kernel. This
is usually done with the nlist (or kvm_nlist) system call, but some
systems use different methods.
The variables read include the status of UDP checksum creation and gen‐
eration, IP forwarding and kernel version (for informational purposes).
On systems where the routing table is read directly from kernel memory,
the root of the hash table or radix tree routing table is read. On sys‐
tems where interface physical addresses are not supplied by other
means, the root of the interface list is read.
Special route flags
The later BSD based kernel support the special route flags described
here.
RTF_REJECT
Instead of forwarding a packet like a normal route,
routes with RTF_REJECT cause packets to be dropped and
unreachable messages to be sent to the packet origina‐
tors. This flag is only valid on routes pointing at the
loopback interface.
RTF_BLACKHOLE
Like the RTF_REJECT flag, routes with RTF_BLACKHOLE cause
packets to be dropped, but unreachable messages are not
sent. This flag is only valid on routes pointing at the
loopback interface.
RTF_STATIC
When GateD starts, it reads all the routes currently in
the kernel forwarding table. Besides interface routes, it
usually marks everything else as a remnant from a previ‐
ous run of GateD and deletes it after a few minutes. This
means that routes added with the route command will not
be retained after GateD has started.
To fix this the RTF_STATIC flag was added. When the route
command is used to install a route that is not an inter‐
face route it sets the RTF_STATIC flag. This signals to
GateD that said route was added by the systems adminis‐
trator and should be retained.
Kernel Configuration
kernel {
options
[ nochange ]
[ noflushatexit ]
[ remnantholdtime time ]
;
routes number ;
flash
[ limit number ]
[ type interface | interior | all ]
;
background
[ limit number ]
[ priority flash | higher | lower ]
;
traceoptions trace_options ;
} ;
options option_list
Configure kernel options. The valid options are:
nochange
On systems supporting the routing socket this
insures that changes operations will not be
performed, only deletes and adds. This is use‐
ful on early versions of the routing socket
code where the change operation was broken.
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 add them back.
remnantholdtime time
Normally remnant routes read from the kernel
forwarding table at startup are timed out in
three minutes or as soon as they are overrid‐
den. This option allows the interval to be con‐
figured to a value between zero and 15 minutes.
Setting it to zero causes these routes to be
deleted immediately.
routes number
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/exter‐
nal order. It queues interface routes first, followed by
internal routes, followed by external routes, and pro‐
cesses the queue from the beginning. If a 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 proto‐
cols is called a flash update. The kernel forwarding ta‐
ble 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.
limit number
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.
type interface | interior | all
Specifies the type of routes that will be pro‐
cessed during a flash update. Interior speci‐
fies that interior routes (See the definition
of interior gateway protocols) will also be
installed. All specifies the inclusion of exte‐
rior routes (See the definition of exterior
gateway protocols) as well. 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 behav‐
ior 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 pro‐
tocol 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:
limit number
Specifies the number of route which may be pro‐
cessed at during one batch. The default is 120.
priority flash | 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 pro‐
cessed 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 configura‐
tion 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 ker‐
nel forwarding table.
Static Statements
Static statements define the static routes used by GateD. A single
static statement can specify any number 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.
static {
( host host ) | default |
( network [ ( mask mask ) | ( masklen number ) ] )
gateway gateway_list
[ interface interface_list ]
[ preference preference ]
[ retain ]
[ reject ]
[ blackhole ]
[ noinstall ] ;
( network [ ( mask mask ) | ( masklen number ) ] )
interface interface
[ preference preference ]
[ retain ]
[ reject ]
[ blackhole ]
[ noinstall ] ;
} ;
host host gateway gateway_list
( network [ ( mask mask ) | ( masklen number ) ] )
default gateway gateway_list
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 gate‐
ways listed are available on directly attached inter‐
faces. If more than one eligible gateways are available,
they are limited by the number of multipath destinations
supported (this compile time parameter is currently
almost always one on Unix).
Parameters for static routes are:
interface interface_list
When this parameter is specified, gateways are
only considered valid when they are on one of
these interfaces.See the section on interface list
specification for the description of the inter‐
face_list.
preference preference
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 rout‐
ing 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 sup‐
ported.
noinstall
Normally the route with the lowest preference is
installed in the kernel forwarding table and is
the route exported to other protocols. When noin‐
stall 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.
( network [ ( mask mask ) | ( masklen number ) ] ) interface
interface
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.
Control Statements Overview
Control statements control routes that are imported from routing peers
and routes that are exported to these peers. These are the final state‐
ments to be included in the gated.conf file. The control statements
are:
· the Import Statement
· the Export Statement
· the Aggregate Statement
· the Generate Statement
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.
Filtering syntax
network [ exact | refines ]
network mask mask [ exact | refines ]
network masklen number [ exact | refines ]
all
default
host host
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 ]
network mask mask [ exact | refines ]
network masklen number [ 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 speci‐
fied by the number of contiguous one bits.
If no additional parameters are specified, any destina‐
tion 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 sub‐
nets, and any hosts will be match. The two optional modi‐
fiers 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 more specified (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
host host
Matches the specific host. To match, the address must
exactly match the specified host and the network mask
must be a host mask (all ones). This is equivalent to:
host mask 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 des‐
tination 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 num‐
ber 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 rout‐
ing 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 com‐
plete. 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.
AS path matching syntax
An AS path is matched using the following syntax.
aspath aspath_regexp origin any | ( [ igp ] [egp ] [ incomplete ] )
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
.
( aspath_regexp )
where
autonomous_system 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 expres‐
sion enclosed in parentheses
AS path operators
An AS path operator is one of the following:
aspath_term {m,n}
aspath_term {m}
aspath_term {m,}
aspath_term *
aspath_term +
aspath_term ?
aspath_term | aspath_term
aspath_term {m,n}
a regular expression followed by {m,n} (where m and n are both
nonnegative 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 repeti‐
tions. 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 the GateD routing database is controlled by import state‐
ments. 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
preference preference
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 pre‐
vents them from becoming active so they will not be
installed in the forwarding table, or exported to other
protocols.
preference preference
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 formats allow route filters as shown below. See the section on
route filters for a detailed explanation of how they work. When no
route filtering is specified (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.
network [ exact | refines ]
network mask mask [exact | refines ]
network masklen number [ exact | refines ]
default
host host
Importing routes from BGP and EGP
import proto bgp | egp autonomoussystem autonomous_system
restrict ;
import proto bgp | egp autonomoussystem autonomous_system
[ preference preference ] {
route_filter [ restrict | ( preference preference ) ] ;
} ;
import proto bgp aspath aspath_regexp
origin any | ( [ igp ] [egp ] [ incomplete ] )
restrict ;
import proto bgp aspath aspath_regexp
origin any | ( [ igp ] [egp ] [ incomplete ] )
[ preference preference ] {
route_filter [ restrict | ( preference preference ) ] ;
} ;
EGP importation may be controlled by autonomous system. BGP also sup‐
ports controlling propagation by the use of an AS path regular expres‐
sions, which are documented in the section on Matching AS paths. Note
that EGP and BGP versions 2 and 3 only support the propagation of natu‐
ral 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 key‐
word in the routing table with a negative preference. A negative pref‐
erence prevents a route from becoming active, which prevents it from
being installed in the forwarding table, or exported to other proto‐
cols. This alleviates the need to break and re-establish a session upon
reconfiguration if importation policy is changed.
Importing routes from an RIP, HELLO and Redirects
import proto rip | hello | redirect
[ ( interface interface_list ) | (gateway gateway_list ) ]
restrict ;
import proto rip | hello | redirect
[ ( interface interface_list ) | (gateway gateway_list ) ]
[ preference preference ] {
route_filter [ restrict | ( preference preference ) ] ;
} ;
The importation of RIP, HELLO 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 and HELLO do 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.
Importing routes from OSPF
import proto ospfase [ tag ospf_tag ] restrict ;
import proto ospfase [ tag ospf_tag ]
[ preference preference ] {
route_filter [ restrict | ( preference preference ) ] ;
} ;
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 speci‐
fied, 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 prefer‐
ence.
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 state‐
ment, 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
metric metric
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 spec‐
ifies 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.
metric metric
Specifies the metric to be used when exporting to the
specified destination.
Route Filters
All the formats allow route filters as shown below. See the section on
route filters for a detailed explanation of how they work. When no
route filtering is specified (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.
network [ exact | refines ]
network mask mask [exact | refines ]
network masklen number [ exact | refines ]
default
host host
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 proto bgp | egp as autonomous system
restrict ;
export proto bgp | egp as autonomous system
[ metric metric ] {
export_list ;
} ;
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. They range from 0 to 65535
inclusive with 0 being the most attractive. While BGP version 4 actu‐
ally 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 overrid‐
den; 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 meaning‐
less. BGP version 4 supports the propagation of any destination along
with a contiguous network mask.
Exporting to RIP and HELLO
export proto rip | hello
[ ( interface interface_list ) | (gateway gateway_list ) ]
restrict ;
export proto rip | hello
[ ( interface interface_list ) | (gateway gateway_list ) ]
[ metric metric ] {
export_list ;
} ;
Exportation to RIP and HELLO is controlled by any of protocol, inter‐
face 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, or
exporting HELLO routes into HELLO. Attempts to do this are silently
ignored.
If no export policy is specified, RIP and interface routes are exported
into RIP and HELLO and interface routes are exported into HELLO. If any
policy is specified, the defaults are overridden. It is necessary to
explicitly specify everything that should be exports.
RIP version 1 and HELLO assume 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
(static and internally generated default routes) via RIP or HELLO, it
is necessary to specify the metric at some level in the export clause.
Just setting a default metric for RIP or HELLO is not sufficient. This
is a safeguard to verify that the announcement is intended.
Exporting to OSPF
export proto ospfase [ type 1 | 2 ] [ tag ospf_tag ]
restrict ;
export proto osfpase [ type 1 | 2 ] [ tag ospf_tag ]
[ metric metric ] {
export_list ;
} ;
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 protocol configuration for detailed
information on OSPF tags. The default tag specified by the ospf
defaults 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.
Exporting BGP and EGP routes
proto bgp | egp autonomoussystem autonomous_system
restrict ;
proto bgp | egp autonomoussystem autonomous_system
[ metric metric ] {
route_filter [ restrict | ( metric metric ) ] ;
} ;
BGP and EGP routes may be specified by source autonomous system. All
routes may be exported by as path, see below for more information.
Exporting RIP and HELLO routes
proto rip | hello
[ ( interface interface_list ) | (gateway gateway_list ) ]
restrict ;
proto rip | hello
[ ( interface interface_list ) | (gateway gateway_list ) ]
[ metric metric ] {
route_filter [ restrict | ( metric metric ) ] ;
} ;
RIP and HELLO routes may be exported by protocol, source interface
and/or source gateway.
Exporting OSPF routes
proto ospf | ospfase restrict ;
proto ospf | ospfase [ metric metric ] {
route_filter [ restrict | ( metric metric ) ] ;
} ;
Both OSPF, and OSPF ASE routes may be exported into other protocols.
See below for information on exporting by tag.
Exporting routes from nonrouting protocols
Nonrouting with interface
proto direct | static | kernel
[ (interface interface_list ) ]
restrict ;
proto direct | static | kernel
[ (interface interface_list ) ]
[ metric metric ] {
route_filter [ restrict | ( metric metric ) ] ;
} ;
These protocols may be exported by protocol, or by the interface of the
next hop. These protocols are:
direct Routes to directly attached interfaces.
static Static routes specified in a static clause.
kernel On systems with the routing socket, routes learned from
the routing socket are installed in the GateD routing ta‐
ble 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.
Nonrouting by protocol
proto default | aggregate
restrict ;
proto default | aggregate
[ metric metric ] {
route_filter [ restrict | ( metric metric ) ] ;
} ;
These protocols may only be referenced by protocol.
default
Refers to routes created by the gendefault option. It is
recommended that route generation be used instead.
aggregate
Refers to routes synthesized from other routes when the
aggregate and generate statements are used. See the sec‐
tion on Route Aggregation for more information.
Exporting by AS path
proto proto | all aspath aspath_regexp
origin any | ( [ igp ] [egp ] [ incomplete ] )
restrict ;
proto proto | all aspath aspath_regexp
origin any | ( [ igp ] [egp ] [ incomplete ] )
[ metric metric ] {
route_filter [ restrict | ( metric metric ) ] ;
} ;
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 spec‐
ifies EGP as the origin and the source AS as the AS path. For BGP
routes, the AS path is stored as learned from BGP.
AS path regular expressions are documented in the section on Matching
AS paths.
Exporting by route Tag
proto proto | all tag tag restrict ;
proto proto | all tag tag
[ metric metric ] {
route_filter [ restrict | ( metric metric ) ] ;
} ;
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 auton‐
omous 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 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
aggregate default
| ( network [ ( mask mask ) | ( masklen number ) ] )
[ preference preference ] [ brief ] {
proto [ all | direct | static | kernel | aggregate | proto ]
[ ( as autonomous system ) | ( tag tag )
| ( aspath aspath_regexp ) ]
restrict ;
proto [ all | direct | static | kernel | aggregate | proto ]
[ ( as autonomous system ) | ( tag tag )
| ( aspath aspath_regexp ) ]
[ preference preference ] {
route_filter [ restrict | ( preference preference ) ] ;
} ;
} ;
generate default
| ( network [ ( mask mask ) | ( masklen number ) ] )
[ preference preference ] {
[ ( as autonomous system ) | ( tag tag )
| ( aspath aspath_regexp ) ]
restrict ;
proto [ all | direct | static | kernel | aggregate | proto ]
[ ( as autonomous system ) | ( tag tag )
| ( aspath aspath_regexp ) ]
[ preference preference ] {
route_filter [ restrict | ( preference preference ) ] ;
} ;
} ;
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 preferences of the route are used to order
the routes. The preference of the aggregate route will be that of the
contributing route with the lowest aggregate preference.
preference preference
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 SEQUENCEs of all contributing
AS paths.
proto proto
In addition to the special protocols listed, the con‐
tributing protocol may be chosen from among any of the
ones supported (and currently configured into) GateD.
as autonomous_system
Restrict selection of routes to those learned from the
specified autonomous system.
tag tag
Restrict selection of routes to those with the specified
tag.
aspath aspath_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.
route_filter
See below.
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 formats allow route filters as shown below. See the section on
route filters for a detailed explanation of how they work. When no
route filtering is specified (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 differ‐
ently, if any filters are specified, an all restrict ; is assumed at
the end of the list.
network [ exact | refines ]
network mask mask [exact | refines ]
network masklen number [ exact | refines ]
default
host host
Glossary of Terms
Terms used in descriptions throughout this document are defined below:
A relationship formed between selected neighboring routers for
the purpose of exchanging routing information. Not every pair of
neighboring routers becomes adjacent.
A set of routers under a single technical administration, using
an interior gateway protocol and common metrics to route packets
within the AS, and using an exterior gateway protocol to route
packets to other ASs. Since this classic definition was devel‐
oped, it has become common for a single AS to use several inte‐
rior gateway protocols and sometimes several sets of metrics
within an AS. The use of the term Autonomous System stresses
that even when multiple igps and metrics are used, the adminis‐
tration of an AS appears to other ASs to have a single coherent
interior routing plan and presents a consistent picture of what
networks are reachable through it. The AS is represented by a
number between 1 and 65534, assigned by the Internet Assigned
Numbers Authority.
One of a class of exterior gateway
protocols, described in more detail in the BGP section of
the Protocol Overview.
An OSPF metric. See metric.
A HELLO metric. Valid values are from zero to 30000 inclusive.
The value of 30000 is the maximum metric and means
unreachable. See metric.
OSPF: Each multiaccess network that has at least two
attached routers as a designated router. The designated
router generates a link state advertisement for the mul‐
tiaccess network and assists in running the protocol. The
designated router is elected by the HELLO protocol.
Any network or any host.
An EGP metric. See metric. Valid values are from zero to 255
inclusive.
A class of routing protocols used to exchange
routing information
within an autonomous system. A detailed
explanation of exterior gateway protocols
is available in the Protocol Overview.
One of a class of exterior gateway
protocols, described in more detail
in the EGP section of the Protocol
Overview.
An intermediate destination by which pack‐
ets are delivered to
their ultimate destination. A host
address of another router that is
directly reachable via an attached
network. As with any host address it
may be specified symbolically.
A list of one or more gateways separated by
white
space.
One of a class of interior gateway
protocols, described in more detail
in the HELLO section of the Protocol
Overview.
The IP address of any host. Usually speci‐
fied as a dotted quad,
four values in the range of 0 to 255
inclusive separated by dots (.). For
example 132.236.199.63 or 10.0.0.51.
It may also be specified as an eight
digit hexadecimal string preceded by
0x. For example 0x???????? or
0x0a000043. Finally, if options
noresolv is not specified, a sym‐
bolic hostname. For example
gated.cornell.edu or nic.ddn.mil.
The numeric forms are much preferred
over the symbolic form.
The host address of an attached interface.
This is
the address of a broadcast, nbma or
loopback interface and the remote
address of a point-to-point inter‐
face. As with any host address it
may be specified symbolically.
The connection between a router and one of
its attached
networks. A physical interface may
be specified by a single IP address,
domain name, or interface name.
(Unless the network is an unnumbered
point-to-point network.) Multiple
levels of reference in the configu‐
ration language allow identification
of interfaces using wildcard, inter‐
face type name, or delete word
address. Be careful with the use of
interface names as future Unix oper‐
ating systems may allow more than
one address per interface. Dynamic
interfaces can be added or deleted
and indicated as up or down as well
as changes to address, netmask and
metric parameters.
One of a class of routing
protocols used to exchange
routing
information within an
autonomous system. A
detailed explanation
of interior gateway
protocols is available
in the Protocol Over‐
view.
A list of one or more inter‐
face names including wildcard
names
(names without a num‐
ber) and names which
may specify more than
one interface or
address, or the token
"all" for all inter‐
faces. See the sec‐
tion on interface
lists for more infor‐
mation.
One of a class of interior
gateway
protocols.
The host address of an
attached interface. This is
the address of a
broadcast, nbma or
loopback interface and
the local address of a
point-to-point inter‐
face. As with any host
address it may be
specified symboli‐
cally.
A means of subdividing net‐
works using address modifica‐
tion. A
mask is a dotted quad
specifying which bits
of the destination are
significant. Except
when used in a route
filter, GateD only
supports contiguous
masks.
The number of significant
bits in the mask.
One of the units used to help
a system determine the best
route.
Metrics may be based
on hop count, routing
delay, or an arbitrary
value set by the
administrator depend‐
ing on the type of
routing protocol.
Routing metrics may
influence the value of
assigned internal
preferences. (See
preference.)
This sample table
shows the range of
possible values for
each routing protocol
metric and the value
used by each protocol
(See Protocol Over‐
view.) to reach a des‐
tination.
SAMPLE ROUTING PROTOCOL METRICS
Protocol Metric Represents Range Unreachable
-----------------------------------------
RIP distance (hop-count) 0-15 16
HELLO delay (milliseconds) 0-29999 30000
OSPF cost of path 0-????? Delete
ISIS cost of path 0-254 Delete
EGP distance (unused) 0-65535 255
BGP unspecified 0-65534 65535
Those physical networks that
support the attachment of
multiple
(more than two)
routers. Each pair of
routers on such a net‐
work is assumed to be
able to communicate
directly.
The format of an IP address
contains the network address
and the
host address. The
natural mask is a
default value applied
to the 3 class
addresses:
0xff000000 for class A (network.host.host.host),
0xffff0000 for class B (network.network.host.host) and
0xffffff00 for class C (network.network.network.host).
Another router which with
implicit or explicit communi‐
cation is
established by a rout‐
ing protocol. Neigh‐
bors are usually on a
shared network, but
not always. This term
is mostly used in OSPF
and EGP. Usually syn‐
onymous with peer.
Two routers that have inter‐
faces to a common network. On
multiaccess networks,
routers are dynami‐
cally discovered by
the OSPF HELLO proto‐
col.
Any packet-switched network.
A network may be specified by
its IP address or net‐
work name. The host
bits in a network
specification must be
zero. Default may be
used to specify the
default network
(0.0.0.0).
The IP address of a network.
Usually specified as a dotted
quad,
one to four values in
the range of 0 to 255
inclusive separated by
dots (.). For example
132.236.199, 132.236
or 10. It may also be
specified as a hexa‐
decimal string pre‐
ceded by 0x with an
even number of digits
between two and eight.
For example 0x??????,
0x???? or 0x0a. Also
allowed is the sym‐
bolic value default
which has the distin‐
guished value 0.0.0.0,
the default network.
If options noresolv is
not specified, a sym‐
bolic network name can
be used, for example
nr-tech-prod, cor‐
nellu-net and arpanet.
The numeric forms are
much preferred over
the symbolic form.
A positive integer.
One of a class of
interior gateway
protocols,
described in
more detail in
the OSPF sec‐
tion of the
Protocol Over‐
view.
Another router
which with
implicit or
explicit commu‐
nication is
estab‐
lished
by a
routing
proto‐
col.
Peers
are usu‐
ally on
a shared
network,
but not
always.
This
term is
mostly
used by
BGP.
Usually
synony‐
mous
with
neigh‐
bor.
A UDP or TCP
port number.
Valid values
are from 1
through 65535
inclu‐
sive.
A preference is
a value between
0 (zero) and
255
used to
select
between
many
routes
to the
same
destina‐
tion.
The
route
with the
best
(numeri‐
cally
lowest)
prefer‐
ence is
as the
active
route.
The
active
route is
the one
installed
in the
kernel
forward‐
ing ta‐
ble and
exported
to other
proto‐
cols.
Prefer‐
ence
zero is
usually
reserved
for
routes
to
directly
attached
inter‐
faces. A
default
prefer‐
ence is
assigned
to each
source
from
which
GateD
receives
routes.
(See
Prefer‐
ence.)
A contiguous
mask covering
the most sig‐
nificant bits
of an
address.
The pre‐
fix
length
speci‐
fies how
many
bits are
covered.
The OSI
equiva‐
lent of
TOS.
One
of
a
class
of
inte‐
rior
gate‐
way pro‐
to‐
cols,
described
in
more
detail
in
the
RIP
sec‐
tion
of
the
Pro‐
to‐
col
Over‐
view.
A
32-bit
num‐
ber
assigned
to
each
router
run‐
ning
the
OSPF
pro‐
to‐
col.
This
num‐
ber
uniquely
iden‐
ti‐
fies
the
router
within
the
au‐
ton‐
o‐
mous
sys‐
tem.
An
IP
address
used
as
unique
iden‐
ti‐
fier
assigned
to
rep‐
re‐
sent
a
spe‐
cific
router.
This
is
usu‐
ally
the
address
of
an
attached
inter‐
face.
The
repos‐
i‐
tory
of
all
of
the
GateD
retained
rout‐
ing
infor‐
ma‐
tion,
used
to
make
deci‐
sions
and
as
a
source
for
rout‐
ing
infor‐
ma‐
tion
which
is
prop‐
a‐
gated.
An
inter‐
face
may
be
marked
as
sim‐
plex
either
by
the
ker‐
nel,
or
by inter‐
face
con‐
fig‐
u‐
ra‐
tion.
A
sim‐
plex
inter‐
face
is
an
inter‐
face
on
a
broad‐
cast
media
that
is
not
capa‐
ble
of
receiv‐
ing
pack‐
ets
it
broad‐
casts.
GateD
takes
advan‐
tage
of
inter‐
faces
that
are
capa‐
ble
of
receiv‐
ing
their
own
broad‐
cast
pack‐
ets
to
mon‐
i‐
tor
whether
an
inter‐
face
appears
to
be
func‐
tion‐
ing
prop‐
erly.
A
time
value,
usu‐
ally
a
time
inter‐
val.
It
may
be
spec‐
i‐
fied
in any
one
of
the
fol‐
low‐
ing
forms:
num‐
ber A
non‐
neg‐
a‐
tive
dec‐
i‐
mal
num‐
ber
of
sec‐
onds.
For
exam‐
ple,
27,
60
or
3600.
num‐
ber:num‐
ber A
non‐
neg‐
a‐
tive
dec‐
i‐
mal
num‐
ber
of
min‐
utes
fol‐
lowed
by
a
sec‐
onds
value
in
the
range
of
zero
to
59
inclu‐
sive.
For
exam‐
ple,
0:27,
1:00
or
60:00.
num‐
ber:num‐
ber:num‐
ber A
non‐
neg‐
a‐
tive
dec‐
i‐
mal
num‐
ber
of
hours
fol‐
lowed
by
a
min‐
utes
value
in
the
range
of
zero
to
59
inclu‐
sive
fol‐
lowed
by
a
sec‐
onds
value
in
the
range
of
zero
to
59
inclu‐
sive.
For
exam‐
ple,
0:00:27,
0:01:00
or
1:00:00.
time
to
live
ttl The
Time
To
Live
(TTL)
of
an
IP
packet.
Valid
val‐
ues
are
from
one
(1)
through
255
inclu‐
sive.
The
type
of
ser‐
vice
is
for
inter‐
net
ser‐
vice
qual‐
ity selec‐
tion.
The
type
of
ser‐
vice
is
spec‐
i‐
fied
along
the
abstract
param‐
e‐
ters
prece‐
dence,
delay,
through‐
put,
reli‐
a‐
bil‐
ity,
and
cost.
These
abstract
param‐
e‐
ters
are
to
be
mapped
into
the
actual
ser‐
vice
param‐
e‐
ters
of
the
par‐
tic‐
u‐
lar
net‐
works
the
data‐
gram
tra‐
verses.
The
vast
major‐
ity
of
IP
traf‐
fic
today
uses
the
default
type
of
ser‐
vice.
WARN‐
INGS
con‐
tains
pro‐
vi‐
sions
for
BGP
pro‐
to‐
col,
but
it
is
not
offi‐
cially
sup‐
ported
by
HP
at
the
present
time.
The
route
aggre‐
ga‐
tion
and
gen‐
er‐
a‐
tion
state‐
ments
which
gen‐
er‐
ate
a
more
gen‐
eral
route
from
com‐
press‐
ing
the
spe‐
cific
routes
through
the
explicit
con‐
fig‐
u‐
ra‐
tion
are
not
sup‐
ported
in
this
release.
AUTHOR
See
gated(1M).
SEE
ALSO
RFC
827: E.
Rosen,
RFC
891: D.
Mills,
RFC
904: D.
Mills,
RFC
1058: C.
Hedrick,
RFC
1105: K.
Lougheed,
Y.
Rekhter,
RFC
1163: K.
Lougheed,
Y.
Rekhter,
RFC
1164: J.
Honig,
D.
Katz,
M.
Mathis,
Y.
Rekhter,
J.
Yu,
RFC
1227: M.
Rose,
RFC
1245: J.
Moy,
RFC
1246: J.
Moy,
RFC
1253: F.
Baker,
R.
Coltun,
RFC
1256: S.
Deer‐
ing,
RFC
1265: Y.
Rekhter,
RFC
1266: Y.
Rekhter,
RFC
1267: K.
Lougheed,
Y.
Rekhter,
RFC
1268: P.
Gross,
Y.
Rekhter,
RFC
1269: J.
Bur‐
russ,
S.
Willis,
RFC
1321: R.
Rivest,
RFC
1370: Inter‐
net
Archi‐
tec‐
ture
Board
RFC
1388: G.
Malkin,
RFC
1397: D.
Haskin,
RFC
1403: K.
Varad‐
han,
RFC
1583: J.
Moy,
gated.conf(4)