[Appendix B] B.10 Control Statements

B.10 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 advertsied. 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: Says 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 routes.
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: [2]

[2] Route filters may include additional parameters. On import statements they include a preference, and on export statements a metric. "Preference" and "metric" are described previously.

address [ mask mask | masklen number ] [ exact | refines ]

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

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 specfied 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. [3] 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.

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

An AS path regular expression is a regular expression composed of autonomous system numbers and special operators. Table 13.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.

B.10.1 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 re-establish a session if routing policy changes during a reconfiguration.

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

import proto rip | hello | 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 or HELLO. RIP and HELLO don't use preference to choose between routes of the same protocol. They use 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 only applies 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.

B.10.2 The export Statement

The syntax of the export statement is similar to the syntax of the import statement and the meaning of many of the parameters is 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.

Each 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 and HELLO, use this syntax:

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

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

If no export list is specified, RIP exports direct routes and RIP routes, and HELLO exports direct routes and HELLO 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 define the protocols, interfaces, etc., from which routes are recieved.

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

export proto bgp | egp autonomoussystem as_number
[ restrict ] |
[[ 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.

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 ( all ) protocols. 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 are explained above.

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

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

The export of RIP and HELLO routes may be controlled by protocol, 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 syntax shown below:

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.