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:
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: 
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.  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 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.
A simple AS path regular expression might be:
import proto bgp aspath 164+ origin any restrict ;
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:
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:
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.
The syntax of the
statement is similar to the syntax of the
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
where the routes will be sent and where they originated. The destination
of the route advertisement is defined by the
Each export statement varies slightly for each protocol. To advertise routes via EGP and BGP, use this syntax:
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:
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.
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:
Only OSPF ASE routes can be exported by
. There are two types
of OSPF ASE routes, type 1 and type 2. They are described in
and earlier in this appendix. The default
type is specified in the
statement, but it can be overridden
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:
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:
The source of the routes can be any one protocol (
To export routes learned from RIP and HELLO, use this export list syntax:
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:
The export of OSPF and OSPF ASE routes may be controlled by protocol and
route filter. Exporting OSPF routes can also be controlled by
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:
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.
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.