DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 
Configuring Internet Protocol (IP) routing

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:

   network
   network mask mask
   network 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.


network
network mask mask
network 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.

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 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.

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 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.

Importing routes from RIP and redirects

   import proto rip | redirect
       [ ( interface interface_list ) | (gateway gateway_list ) ]
       restrict ;
   import proto rip | redirect
       [ ( interface interface_list ) | (gateway gateway_list ) ]
       [ preference preference ] {
       route_filter [ restrict | ( preference preference ) ] ;
   } ;

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

   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 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.

The specification of the source of the routing information being exported (the export_list) is described at ``Specifying the source (export_list)''.

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.



Next topic: Configuring a system for IP routing
Previous topic: gated static statements

© 2003 Caldera International, Inc. All rights reserved.
SCO OpenServer Release 5.0.7 -- 11 February 2003