HP OpenVMS Systems Documentation

The control statements are used to define:

• Route filtering, described in Section A.18.1
• Matching AS paths, as described in Section A.18.2
• Importing routes, as described in Section A.18.3
• Exporting routes, as described in Section A.18.4
• The source of exported routes, as described in Section A.18.5
• Route aggregation, as described in Section A.18.6

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, and in 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 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.

Filtering syntax:

network [ exact | refines | between number and number ]
network mask mask [ exact | refines | between number and number ]
network masklen number [ exact | refines | between number and number ]
all
default
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 and default formats are not valid for martians.

In most cases it is possible to specify additional parameters relevent 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 you can specify a metric.

Each control statement is described in the following list:

• network [ exact | refines | between lownumber and highnumber ] network mask mask [ exact | refines | between lownumber and highnumber ]] network masklen number [ exact | refines | between lownumber and highnumber ]
  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.
  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 be match. The two optional modifiers cause the mask of the destination to be considered also:

  exact	Specifies that the mask of the destination must match the supplied mask exactly. This is used to match a network, but no subnets or hosts of that network.
  refines	Specifies that the mask of the destination must be more specified (for example, longer) than the filter mask. This is used to match subnets or hosts of a network, but not the network.
  between lownumber and highnumber
  	Specifies that the mask of the destination must be as or more specific (for example, as long as or longer) than the lower limit ( lownumber) and no more specific (for example, as long as or shorter) than the upper limit ( highnumber). Note that exact and refines are both special cases of between .

• all
  This entry matches anything. It is equivalent to:

  0.0.0.0 mask 0.0.0.0

• default
  Matches the default route. To match, the address must be the default address and the mask must be all zeros. This is equivalent to:

  0.0.0.0 mask 0.0.0.0 exact

• 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 (i.e. all ones). This is equivalent to:

  host mask 255.255.255 exact

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

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

AS path regular expressions are defined in RFC 1164.

A.18.2.1 AS Path-Matching Syntax

An AS path is matched using the following syntax.

aspath aspath_regexp origin ( [ any ] ) | [ igp ] | [egp ] | [ incomplete ] )

aspath aspath_regexp

aspath specifies that an AS matching the aspath_regexp with the specified origin is matched.

origin ( [ any ] | [ igp ] | [ egp ] | [ incomplete ] )

An origin of igp indicates the route was learned from an intradomain routing protocol and is most likely complete. An origin of egp indicates the route was learned from an interdomain 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. An origin of any can be used for any origin.

A.18.2.2 AS Path Regular Expressions

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

A.18.2.3 AS Path Terms

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

• autonomous_system
  Specifies any valid autonomous system number, from one through 65534 inclusive.
• dot (.)
  Matches any autonomous system number.
• ( aspath_regexp )
  Group subexpressions in parenthese. 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}
  Indicates a regular expression followed by {m,n} (where m and n are nonnegative integers and m <= n) specifies at least m and at most n repetitions.
• aspath_term {m}
  Indicates a regular expression followed by {m}. When m is a positive integer, the expression specifies exactly m repetitions.
• aspath_term {m,}
  Indicates a regular expression followed by {m,} (where m is a positive integer), and specifies m or more repetitions.
• aspath_term *
  Indicates an AS path term followed by asterisk (*), specifying zero or more repetitions. This is shorthand for {0,}.
• aspath_term +
  Indicates a regular expression followed by plus sign (+), specifying one or more repetitions. This is shorthand for {1,}.
• aspath_term ?
  Indicates a regular expression followed by question mark (?), specifying 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.

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

A.18.3.1 Specifying Preferences

You can specify one of the following keywords to control how routes compete with other protocols:

restrict

preference preference

In these statements:

• 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 specifies the preference value used when comparing this route to other routes from other protocols. The route with the lowest preference available at 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 allow route filters described in this section. When no route filtering is specified (that is, 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. That is, if any filters are specified, a statement like all restrict ; is assumed at the end of the list.

network [ exact | refines | between number and number]
network mask mask [exact | refines | between number and number ]
network masklen number [ exact | refines | between number and number ]
default
host host

Use the following syntax to define importing routes from BGP and EGP:

import proto bgp | egp autonomoussystem autonomous_system
    [ aspath-opt ] restrict ;
import proto bgp | egp autonomoussystem autonomous_system
     [ aspath-opt ] [ preference preference ] {
    route_filter [ restrict | ( preference preference ) ] ;
} ;

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

EGP importation may be controlled by autonomous system. BGP also supports controlling propagation by the use of an 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. BGP version 4 supports the propagation of any destination along with a contiguous network mask.

The aspath-opt option allows the specification of import policy based on the path attributes found in the BGP update. (The option is not usable with EGP.) If multiple communities are specified in the aspath-opt option, only updates carrying all of the specified communities will be matched. If none is specified, only updates lacking the community attribute will be matched.

Note that it is quite possible for several BGP import clauses to match a given update. If more than one clause matches, the first matching clause will be used; all later matching clauses will be ignored. For this reason, it is generally desirable to order import clauses from most to least specific. An import clause without an aspath-opt option will match any update with any communities or none.

EGP and BGP both store any routes that were rejected implicitly by not being metioned 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 aleviates the need to break and re-establish a session upon reconfiguration if importation policy is changed.

A.18.3.4 Importing Routes from RIP and Redirects

Use the following syntax to define importing routes from RIP and redirect routes:

import proto rip | hello | redirect
    [ ( interface interface_list ) | (gateway gateway_list ) ]
    restrict ;
import proto rip | hello | 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 does not 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 since they have short update intervals.

A.18.3.5 Importing Routes from OSPF

Use the following syntax to define 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 only apply to routes with the specified tag.

It is only possible to restrict the importation of OSPF ASE routes when functioning as an AS border router. This is accomplished by specifying an export ospfase clause. Specification of an empty export clause may be used to restrict importation of ASEs when no ASEs are being exported.

Like the other interior protocols, preference can not 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.

A.18.4 The Export Statement

The import statement controls which routes received from other systems are used by GATED; 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 just controlled 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. And the innermost portion is a route filter used to select individual routes.

A.18.4.1 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
    metric metric

In this syntax:

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

All the formats allow route filters as shown in the following example. See the section on route filters for a detailed explaination of how they work. When no route filtering is specified (that is, when restrict is specified on the first line of a statement), all routes from the specfied source will match that statement. If any filters are specified, only routes that match the specified filters will be exported. That is, if any filters are specified, a all restrict ; statement is assumed at the end of the list.

network [ exact | refines | between number and number ]
network mask mask [exact | refines | between number and number ] ]
network masklen number [ exact | refines | between number and number ] ]
default
host host

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

Exporting to EGP and BGP

export proto bgp | egp as autonomous system
    restrict ;
export proto bgp | egp as autonomous system [ aspath-opt ]
    [ metric metric ] {
    export_list ;
} ;

Exportation to EGP and BGP is controlled by an autonomous system. The same policy is applied to all routers in the AS. EGP metrics range from 0 to 255 inclusive, with zero 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. While BGP version 4 actually supports 32 bit unsigned quantities, GATED does not yet support this. In BGP version 4, the metric is otherwise known as the Multi-Exit Discriminator, or MED.

In BGP, the aspath-opt option may be used to send the BGP community attribute. Any communities specified with the aspath-opt option are sent in addition to any received with the route or specified in the group statement.

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 only support the propagation of natural networks, so the host and default route filters are meaningless. BGP version 4 supports the propagation of any destination along with a contiguous network mask.

Exporting to RIP

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

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 in the export_list .

When exporting routes from other protocols, it is important to specify a metric on the export statement or in the route filters. Unless this is done, the value specified in defaultmetric is used. If not specified, the defaultmetric value is 16 (unreachable). It is likely that this is not the desired result.

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 which 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 for RIP is not sufficient. This is a safeguard to verify that the announcement is intended.

Exporting to OSPF

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

It is not possible to create OSPF intra- or interarea 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 routes, type 1 and type 2. 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. The default tag specified by the OSPF defaults clause may be overridden by a tag specified on the export statement.