gated control statements

gated control statements consist of import control statements and
export control statements.
These statements include clauses on route filtering and
autonomous system (AS) path matching.

gated 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 of 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.
The filtering syntax is as follows:

networknetwork mask masknetwork mask-length number
all
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 format is 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 an
export statement you can specify a metric.

networknetwork mask masknetwork mask-length number

Matching usually requires both an address and a mask, although the
mask is implied in the shorthand forms listed below. These three forms
vary in how the mask is specified. In the first form, the mask is implied
to be the natural mask of the network. In the second, the mask is
explicitly specified. In the third, the mask is specified by the number of
contiguous one bits.

NOTE:
The mask-length keyword may also be masklength,
masklen, or mask-len.

If no additional parameters are specified, any destination that falls in
the range given by the network and mask is matched; the mask of the
destination is ignored. If a natural network is specified, the network,
any subnets, and any hosts will match.

all

This entry matches anything. It is equivalent to:

0.0.0.0 mask 0.0.0.0

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, that is, all ones.
This is equivalent to:

host mask 255.255.255

Matching AS paths in gated

An AS path is a list of autonomous systems that routing
information has passed through to get to this router and an indicator
of the origin of the AS path. This information can be used
to prefer one path to a destination network over another.
The primary method for doing this with gated is to specify a list
of patterns to be applied to AS paths when importing and
exporting routes.

Each autonomous system that a route passes through prepends its
AS number to the beginning of the AS path.

The origin information details the completeness of AS path
information. An origin of igp indicates the route was learned from
an interior routing protocol and is most likely complete.
An origin of egp indicates the route was learned
from an exterior routing protocol that does not support AS paths (EGP, for
example) and the path is most likely not complete. When the path information
is definitely not complete, an origin of incomplete is used.

AS path regular expressions are defined in RFC
1164, section 4.2.

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.

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 path expressions.
An AS path expression is
composed of AS path terms and AS path operators.

An AS path term is one of the following three objects:

autonomous_system
( aspath_regexp )

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 expression enclosed in parentheses.

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 repetitions. This
is shorthand for {1,}.

aspath_term ?

A regular expression followed by ? means zero or one repetition. This is
shorthand for {0,1}.

aspath_term | aspath_term

Matches the AS term on the left or the AS term on the right.

gated import control statements

Importation of routes from routing protocols and installation of the routes in
gated's
routing database are controlled by import statements. The format of
an import statement varies depending on the source protocol.

In all cases, one of two keywords may be specified to control how routes
compete with other protocols:

restrict

Specifies that the routes are not desired in the routing table. In some
cases, this means that the routes are not installed in the routing table. In
others, it means that they are installed with a negative preference; this
prevents them from becoming active so they will not be installed in the
forwarding table or exported to other protocols.

preference preference

Specifies the preference value used when comparing this route to other
routes from other protocols. The route with the lowest preference
available of 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.

All the formats below with the variable route_filter allow
route filters. See
``gated route filtering''
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.

EGP importation may be controlled by autonomous_system.
BGP also supports controlling propagation by the use
of AS path regular expressions, which are documented in
the section on matching AS paths. Note that EGP
and BGP Versions 2 and 3 only support the propagation of
natural networks, so the host and default route filters are meaningless.

EGP and BGP both store any routes that were
rejected implicitly by not being
mentioned in a route filter or explicitly with the restrict
keyword in the
routing table with a negative preference. A negative preference prevents a
route from becoming active, which prevents it from being installed in the
forwarding table or exported to other protocols. This alleviates
breaking and reestablishing a session upon reconfiguration if importation policy is
changed.

The importation of RIP and Redirect routes may be controlled by any
of protocol, source interface, and source gateway. If more than one is specified,
they are processed from most general (protocol) to most specific (gateway).

RIP doesn't 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, because they have short update intervals.

Importing routes from OSPF

Due to the nature of OSPF,
only the importation of ASE routes may be
controlled. OSPF intra- and inter-area
routes are always imported into the
gated routing table with a preference of 10.
If a tag is specified, the import
clause will apply only to routes with the specified tag. Like the other interior
protocols, preference cannot be used to choose between
OSPF ASE routes;
that is done by the OSPF costs.
Routes that are rejected by policy are stored in
the table with a negative preference.

gated export control statements

The import statement controls which routes received from other systems are
used by gated, and the export statement controls which routes are
advertised by gated
to other systems. Like the import statement, the syntax
of the export statement varies slightly per protocol. The syntax of the
export statement is similar to the syntax of the import statement, and the
meanings of many of the parameters are identical. The main difference
between the two is that while route importation is controlled just 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. The innermost portion is
a route filter used to select individual routes.

Specifying metrics

The most specific specification of a metric is the one applied to the route being
exported. The values that may be specified for a metric depend on the
destination protocol that is referenced by this export statement.

restrict

Specifies that nothing should be exported. If specified on the
destination portion of the export statement, it specifies that nothing at
all should be exported to this destination. If specified on the source
portion, it specifies that nothing from this source should be exported to
this destination. If specified as part of a route filter, it specifies that the
routes matching that filter should not be exported.

metric metric

Specifies the metric to be used when exporting to the specified
destination.

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.

Exportation to EGP and BGP is controlled by
autonomous_system; the same policy is applied to all routers in
the AS. EGP metrics range from 0 to 255
inclusive with 0 being the most attractive.

BGP metrics are 16-bit unsigned quantities; that is, they
range from 0 to 65535 inclusive with 0 being the most attractive.

If no export policy is specified, only routes to attached interfaces will be
exported. If any policy is specified, the defaults are overridden; it is
necessary to explicitly specify everything that should be exported.

Note that EGP and BGP Versions 2 and 3
support only the propagation of
natural networks, so the host and default route filters are meaningless.

Exportation to RIP is controlled by any of protocol, interface, or
gateway. If more than one is specified, they are processed from most general
(protocol) to most specific (gateway).

It is not possible to set metrics for exporting RIP
routes into RIP.
Attempts to do this are silently ignored.

If no export policy is specified, RIP and interface
routes are exported into RIP.
If any policy is
specified, the defaults are overridden; it is necessary to explicitly specify
everything that should be exported.

RIP Version 1 assumes that all subnets of the shared network have
the same subnet mask, so they are only able to propagate subnets of that
network. RIP Version 2 removes that restriction
and is capable of propagating
all routes when not sending Version 1-compatible updates.

To announce routes that specify a next hop of the loopback interface (that is,
static and internally generated default routes) via RIP, it is
necessary to specify the metric at some level in the export clause. Just
setting a default metric such as RIP is not sufficient. This is a
safeguard to verify that the announcement is intended.

It is not possible to create OSPF
intra- or inter-area routes by exporting routes
from the gated routing table into OSPF. It is
only possible to export from the gated routing table into
OSPF ASE routes. It is also not possible to control the
propagation of OSPF routes within the OSPF protocol.

There are two types of OSPF ASE route, 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 (export_list)

The export_list specifies export based on the origin of
a route, and the syntax
varies depending on the source.

All the formats below with the variable route_filter allow
route filters. See
``gated route filtering''
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.

When BGP is configured, all routes are assigned an AS path when they are
added to the routing table.
For all interior routes, this AS path specifies igp as
the origin and no ASEs in the AS path
(the current AS is added when the route
is exported). For EGP routes, this AS path specifies EGP as the origin and the
source AS as the AS path. For BGP routes,
the AS path is stored as learned
from BGP.

Both OSPF and RIP Version 2 currently support tags;
all other protocols always
have a tag of zero. The source of exported routes may be selected based on this
tag. This is useful when routes are classified by tag when they are
exported into a given routing protocol.