Control Statements

The control statements define your routing policy. Often when administrators hear the terms “routing policy” or “policy-based routing,” they assume that this is something done inside the routing protocol.

In reality, a routing policy is defined outside of the routing protocol in the configuration file. The policy defines what routes are accepted and what routes are advertised. gated does this with two control statements: import and export. The import statement defines which routes are accepted and from what sources those routes are accepted. The export statement defines which routes are advertised based on the source of the routes and the protocol used to advertise them.

The import and export statements use gated preference, routing metrics, routing filters, and AS paths to define routing policy. Preference and metrics are controlled by these keywords:

restrict: Specifies that the routes are not to be imported, in the case of the import command, or exported in the case of the export command. This keyword blocks the use of a specific route.
preference preference: Defines the preference value used when comparing this route to other routes. Preference is used when installing routes, not when advertising them.
metric metric: Specifies the metric used when advertising a route.

Route filters match routes by destination address. Among other places, route filters are used on martians and import and export statements. A route matches the most specific filter that applies. Specifying more than one filter with the same destination, mask, and modifiers generates an error. Import and export route filters can be specified in the following ways:^[155]

address [mask mask | masklen number ] [exact | refines | between n1 and n2 ]

Defines a range of addresses using an address and an address mask. The address mask can be defined with the keyword mask and a mask written in dotted decimal notation, or with the keyword masklen and a numeric prefix length. If no mask is defined, the natural mask of the network is used. Three options can be used:

exact: Matches a network, but no subnets or hosts of that network.
refines: Matches subnets and/or hosts of a network, but not the network itself.
between n1 and n2: Matches an address where at least n1 bits match and no more than n2 bits match.

all

Matches every possible address.

default

Matches only the default route.

host address

Matches an individual host address.

A routing filter that matches everything on network number 192.168.12.0 and the individual host 10.104.19.12 contains:

192.168.12.0 masklen 24 ; host 10.104.19.12 ;

When no route filtering is specified in an import or export statement, all routes from the specified source will match that statement. If any filters are specified, only routes that match the specified filters are imported or exported.

Border Gateway Protocol (BGP) is designed to support policy-based routing. A key feature of BGP is that it is a path-vector protocol. import and export statements allow you to use the AS path vector to enforce your routing policy.

An AS path lists the autonomous systems end-to-end for a route and provides an indication of the completeness of the path. Each autonomous system that a route passes through prepends its AS number to the beginning of the AS path.

The “origin” of the path indicates its completeness. 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. All of these origins can be specified in the import and export statements and therefore used in your routing policy. The keyword any is used when the policy applies to all origins.

The AS path can also be used in the control statements by defining an AS path regular expression.^[156] The AS path regular expression provides a pattern-matching syntax used to filter routes based on the autonomous system numbers in the AS paths associated with those routes.

An AS path regular expression is a regular expression composed of autonomous system numbers and special operators. Table B-1 lists the AS path operators. The AS path operator operates on an AS path term, which is an autonomous system number; a dot (.), which matches any autonomous system number; or a parentheses-enclosed subexpression.

Table B-1. AS path operators

Symbol	Meaning
{`m`,`n`}	At least `m` and at most `n` repetitions
{`m`}	Exactly `m` repetitions
{`m`,}	`m` or more repetitions
*	0 or more repetitions
+	1 or more repetitions
?	0 or 1 repetition
aspath_term \| aspath_term	Matches either the AS term on the left or the AS term on the right

A simple AS path regular expression might be:

import proto bgp aspath 164+ origin any restrict ;

This restricts all routes that have one or more occurrences of autonomous system number 164 in their path vector.

The import Statement

The format of an import statement varies depending on the source protocol. The format of the import statements for the exterior gateway protocols is:

import proto bgp | egp autonomoussystem as_number
   [restrict] |
   [[preference preference] {
   route_filter [restrict | (preference preference)]] ; } ;
import proto bgp aspath aspath_regexp
   origin any | igp | egp | incomplete
   [restrict] |
   [[preference preference] {
   route_filter [restrict | (preference preference)]] ; } ;

BGP and EGP importation may be controlled by autonomous system number. BGP also can control importation using AS path regular expressions. Routes that are rejected by the routing policy are stored in the routing table with a negative preference. A negative preference prevents a route from being installed in the forwarding table or exported to other protocols. Handling rejected routes in this manner alleviates the need to break and reestablish a session if routing policy changes during a reconfiguration.

The format of the import statements for the RIP and redirect protocols is:

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

This statement controls what routes are imported based on the source protocol, interface, and gateway. The order of precedence is from the most general (protocol) to the most specific (gateway). Unlike BGP and EGP, these protocols do not save routes that were rejected because these protocols have short update intervals.

The preference option is not used with RIP. RIP doesn’t use preference to choose between routes of the same protocol. It uses the protocol metrics.

The format of the import statement for the OSPF protocol is:

import proto ospfase [tag ospf_tag] [restrict] |
 [[preference preference] {
  route_filter [restrict | (preference preference)]] ; } ;

Due to the nature of OSPF, only the importation of ASE routes can be controlled. Furthermore, it is only possible to restrict the importation of OSPF ASE routes when functioning as an AS border router. This requires you to specify an export ospfase statement in addition to the import ospfase statement. Specify an empty export statement to control importation of ASEs when no ASEs are being exported. (See the following section, “The export Statement.”) If a tag is specified, the import statement applies only to routes with the tag. OSPF ASE routes that are rejected by policy are stored in the table with a negative preference.

OSPF routes are imported into the gated routing table with a preference of 10. Preference is not used to choose between OSPF ASE routes. OSPF costs are used for that purpose.

The export Statement

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. An important difference between the two statements is that while route importation is controlled by source information, route exportation is controlled by both source and destination. Thus, export statements define where the routes will be sent and where they originated. The destination of the route advertisement is defined by the proto clause at the beginning of the export statement. The source of the routes is defined in the export list.

The export statement varies slightly for each protocol. To advertise routes via EGP and BGP, use this syntax:

export proto bgp | egp as as_number
 [restrict] |
 [[metric metric] {
  export_list ; }] ;

Routes are exported via EGP and BGP to the specified autonomous system. restrict blocks exports to the AS. Valid BGP or EGP metrics can be specified. If no export list is defined, only the direct routes of the attached interfaces are exported. If an export list is used, it must explicitly specify everything that should be exported.

To advertise routes via RIP, use this syntax:

export proto rip
  [interface interface_list | gateway gateway_list]
  [restrict] |
  [[metric metric] {
  export_list ; }] ;

Routes exported by RIP can be sent through a specific interface or to a specific gateway. Set metric if you plan to export static or internally generated default routes. The metric option is used only when exporting non-RIP routes via RIP.

If no export list is specified, RIP exports direct routes and RIP routes. If an export list is used, it must explicitly specify everything that should be exported.

To advertise routes via OSPF, use this syntax:

export proto osfpase [type 1 | 2] [tag ospf_tag]
 [restrict] |
 [[metric metric] {
  export_list ; }] ;

Only OSPF ASE routes can be exported by gated. There are two types of OSPF ASE routes, type 1 and type 2. They are described in Chapter 7 and earlier in this appendix. The default type is specified in the ospf protocol statement, but it can be overridden here. The ospf_tag is an arbitrary 32-bit number used to filter routing information. The default tag value is specified in the ospf protocol statement, but it can be overridden here.

The source of the routes advertised by a protocol is defined by the export list. Each of the commands listed above contains an export list option. Just like those commands, the export list syntax varies depending on the source protocol of the routes. The commands described above define the protocols that are used to advertise the routes. The export lists shown below describe the protocols from which the routes are obtained. The biggest confusion caused by the export list syntax is that it is almost identical to the syntax shown above. In both cases we define protocols, autonomous systems, interfaces, gateways, and so on. In the first case we are defining the protocols, interfaces, etc., to which routes are sent, and in this case we are defining the protocols, interfaces, etc., from which routes are received.

To export routes learned from BGP and EGP, use this export list syntax:

export proto bgp | egp autonomoussystem as_number
 [restrict [noagg]] |
 [[metric metric] {
  route_filter [restrict | metric metric] ; }] ;

This defines routes learned via BGP or EGP from a specific autonomous system. Routes can be restricted, or have a metric applied, based on matching the source AS number or the route filter. noagg can be used with restrict to prevent any aggregate routes from matching the filter.

When BGP is configured, gated assigns all routes an AS path. For interior routes, the AS path specifies igp as the origin and no autonomous systems in the AS path (the current AS is added when the route is exported). For EGP routes, the AS path specifies egp as the origin and the source AS as the AS path. For BGP routes, the AS path learned from BGP is used. If you run BGP, the export of all routes may be controlled by the AS path using this syntax:

proto proto | all
 aspath aspath_regexp origin any | igp | egp | incomplete
 [restrict] |
 [[metric metric] {
  route_filter [restrict | metric metric] ; }] ;

The source of the routes can be any one protocol (proto) or all protocols (all). The importation of routes can be controlled by matching their AS paths against the AS path regular expression (aspath_regexp) or by matching their addresses against the route_filter. Route filters and AS path regular expressions were explained previously.

To export routes learned from RIP, use this export list syntax:

proto rip
 [interface interface_list | gateway gateway_list]
 [restrict] |
 [[metric metric] {
  route_filter [restrict | metric metric] ; }] ;

The export of RIP routes may be controlled by source interface, source gateway, or route filter.

To export routes learned from OSPF, use this export list syntax:

proto ospf | ospfase
 [restrict] |
 [[metric metric] {
  route_filter [restrict | metric metric] ; }] ;

The export of OSPF and OSPF ASE routes may be controlled by protocol and route filter. Exporting OSPF routes can also be controlled by tag using the following syntax:

proto proto | all tag tag
                 [restrict] |
   [[metric metric] {
   route_filter [restrict | metric metric] ; }] ;

OSPF and RIP version 2 provide a tag field. For all other protocols, the tag is always 0. Routes may be selected based on the contents of the tag field.

There are other sources of routes that are not true routing protocols, and export lists can be defined for these sources. The two export lists for these sources are:

proto direct | static | kernel
 [interface interface_list]
 [restrict] |
 [[metric metric] {
  route_filter [restrict | metric metric] ; }] ;

The export of these routes can be controlled based on the source “protocol” and the source interface. The “protocols” in this case are routes to direct interfaces, static routes, or routes learned from the kernel.

proto default | aggregate
 [restrict] |
 [[metric metric] {
  route_filter [restrict | metric metric] ; }] ;

The export of these routes may only be controlled based on source “protocol.” default refers to routes created by the gendefault option. aggregate refers to routes created by the aggregate statements, the topic of the next section.

^[155] Route filters may include additional parameters. On import statements, they include a preference, and on export statements, a metric. Preference and metric were described previously.

^[156]AS path regular expressions are defined in RFC 1164.