| Previous | Contents | Index |
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.
B.17.3.1 Specifying Preferences
In all cases, one of two keywords may be specified to control how routes compete with other protocols:
restrict
preference preference
|
Here,
All the formats allow route filters as shown below. See the section on route filters for a detailed explaination of how they work. When no route filtering is specified (i.e. 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 imported. Put differently, if any filters are specified, an all restrict ; is assumed at the end of the list.
network [ exact | refines ]
network mask mask [exact | refines ]
network masklen number [ exact | refines ]
default
host host
|
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 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.
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.
B.17.3.4 Importing Routes from RIP, HELLO and Redirects
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, HELLO 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 and HELLO don'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 since they have
short update intervals.
B.17.3.5 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.
B.17.4 The Export Statement
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 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.
B.17.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
|
Here,
All the formats allow route filters as shown below. See the section on route filters for a detailed explaination of how they work. When no route filtering is specified (i.e. 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. Put differently, if any filters are specified, an all restrict ; is assumed at the end of the list.
network [ exact | refines ]
network mask mask [exact | refines ]
network masklen number [ exact | refines ]
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
[ metric metric ] {
export_list ;
} ;
|
Exportation to EGP and BGP is controlled by autonomous system, the same policy is applied to all routers in the AS. EGP metrics range from 0 to 255 inclusive with 0 being the most attractive.
BGP metrics are 16 bit unsigned quantities, i.e. 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.
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 and HELLO
export proto rip | hello
[ ( interface interface_list ) | (gateway gateway_list ) ]
restrict ;
export proto rip | hello
[ ( interface interface_list ) | (gateway gateway_list ) ]
[ metric metric ] {
export_list ;
} ;
|
Exportation to RIP and HELLO 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, or exporting HELLO routes into HELLO. Attempts to do this are silently ignored.
If no export policy is specified, RIP and interface routes are exported into RIP and HELLO and interface routes are exported into HELLO. If any policy is specified the defaults are overridden; it is necessary to explicitly specify everything that should be exports.
RIP version 1 and HELLO assume 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 (i.e. static and internally generated default routes) via RIP or HELLO, it is necessary to specify the metric at some level in the export clause. Just setting a default metric for e.g. RIP or HELLO 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 inter-area 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, see the OSPF protocol configuration for a detailed explaination of the two types. 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. See the OSPF protocol configuration for detailed
information on OSPF tags. The default tag specified by the ospf
defaults clause may be overridden by a tag specified on the export
statement.
B.17.5 Specifying the Source
The export list specifies export based on the origin of a route and the syntax varies depending on the source.
Exporting BGP and EGP Routes
proto bgp | egp autonomoussystem autonomous_system
restrict ;
proto bgp | egp autonomoussystem autonomous_system
[ metric metric ] {
route_filter [ restrict | ( metric metric ) ] ;
} ;
|
BGP and EGP routes may be specified by source autonomous system. All routes may be exported by as path, see below for more information.
Exporting RIP and HELLO Routes
proto rip | hello
[ ( interface interface_list ) | (gateway gateway_list ) ]
restrict ;
proto rip | hello
[ ( interface interface_list ) | (gateway gateway_list ) ]
[ metric metric ] {
route_filter [ restrict | ( metric metric ) ] ;
} ;
|
RIP and HELLO routes may be exported by protocol, source interface and/or source gateway.
Exporting OSPF Routes
proto ospf | ospfase restrict ;
proto ospf | ospfase [ metric metric ] {
route_filter [ restrict | ( metric metric ) ] ;
} ;
|
Both OSPF, and OSPF ASE routes may be exported into other protocols. See below for information on exporting by tag.
Exporting Routes from Nonrouting Protocols
Non-routing with interface
proto direct | static | kernel
[ (interface interface_list ) ]
restrict ;
proto direct | static | kernel
[ (interface interface_list ) ]
[ metric metric ] {
route_filter [ restrict | ( metric metric ) ] ;
} ;
|
These protocols may be exported by protocol, or by the interface of the next hop. These protocols are:
Nonrouting by Protocol
proto default | aggregate
restrict ;
proto default | aggregate
[ metric metric ] {
route_filter [ restrict | ( metric metric ) ] ;
} ;
|
These protocols may only be referenced by protocol.
Exporting by AS Path
proto proto | all aspath aspath_regexp
origin any | ( [ igp ] [egp ] [ incomplete ] )
restrict ;
proto proto | all aspath aspath_regexp
origin any | ( [ igp ] [egp ] [ incomplete ] )
[ metric metric ] {
route_filter [ restrict | ( metric metric ) ] ;
} ;
|
When BGP is configured, all routes are assigned an AS path when they are added to the routing table. For all interior routes this AS path specifies IGP as the origin and no ASes in the AS path (the current AS is added when the route is exported). For EGP routes this AS path specifies EGP as the origin and the source AS as the AS path. For BGP routes, the AS path is stored as learned from BGP.
AS path regular expressions are documented in the section on Matching AS paths.
Exporting by Route Tag
proto proto | all tag tag restrict ;
proto proto | all tag tag
[ metric metric ] {
route_filter [ restrict | ( metric metric ) ] ;
} ;
|
Both OSPF and RIP version 2 currently support tags, all other protocols
always have a tag of zero. The source of exported routes may be
selected based on this tag. This is useful when routes are classified
by tag when the are exported into a given routing protocol.
B.17.6 Route Aggregation
Route aggregation is a method of generating a more general route given the presence of a specific route. It is used, for example, at an autonomous system border to generate a route to a network to be advertised via EGP given the presence of one or more subnets of that network learned via RIP. Older versions of GATED automatically performed this function, generating an aggregate route to a natural network (using the old Class A, B and C concept) given an interface to a subnet of that natural network. However that was not always the correct thing to do, and with the advent of classless interdomain routing it is even more frequently the wrong thing to do, so aggregation must be explicitly configured. No aggregation is performed unless explicitly requested in an aggregate statement.
Route aggregation is also used by regional and national networks to reduce the amount of routing information passed around. With careful allocation of network addresses to clients, regional networks can just announce one route to regional networks instead of hundreds.
Aggregate routes are not actually used for packet forwarding by the originator of the aggregate route, only by the receiver (if it wishes). A router receiving a packet which does not match one of the component routes which led to the generation of an aggregate route is supposed to respond with an ICMP network unreachable message. This is to prevent packets for unknown component routes from following a default route into another network where they would be forwarded back to the border router, and around and around again and again, until their TTL expires. Sending an unreachable message for a missing piece of an aggregate is only possible on systems with support for reject routes.
A slight variation of aggregation is the generation of a route based on the existence of certain conditions. This is sometimes known as the route of last resort. This route inherits the next hops and aspath from the contributor specified with the lowest (most favorable) preference. The most common usage for this is to generate a default based on the presence of a route from a peer on a neighboring backbone.
B.17.7 Aggregation and Generation Syntax
aggregate default
| ( network [ ( mask mask ) | ( masklen number ) ] )
[ preference preference ] [ brief ] {
proto [ all | direct | static | kernel | aggregate | proto ]
[ ( as autonomous system ) | ( tag tag )
| ( aspath aspath_regexp ) ]
restrict ;
proto [ all | direct | static | kernel | aggregate | proto ]
[ ( as autonomous system ) | ( tag tag )
| ( aspath aspath_regexp ) ]
[ preference preference ] {
route_filter [ restrict | ( preference preference ) ] ;
} ;
} ;
generate default
| ( network [ ( mask mask ) | ( masklen )
[ preference preference ] [ brief ] {
proto [ all | direct | static | kernel | aggregate |
proto ]
[ ( as autonomous system ) | ( tag tag
)
| ( aspath aspath_regexp ) ]
restrict ;
proto [ all | direct | static | kernel | aggregate |
proto ]
[ ( as autonomous system ) | ( tag tag
)
| ( aspath aspath_regexp ) ]
[ preference preference ] {
route_filter [ restrict | ( preference preference ) ];
} ;
} ;
|
Routes that match the route filters are called contributing routes. They are ordered according to the aggregation preference that applies to them. If there are more than one contributing routes with the same aggregating preference, the route's own preferences are used to order the routes. The preference of the aggregate route will be that of contributing route with the lowest aggregate preference.
A route may only contribute to an aggregate route which is more general than itself; it must match the aggregate under its mask. Any given route may only contribute to one aggregate route, which will be the most specific configured, but an aggregate route may contribute to a more general aggregate.
Route Filters
All the formats allow route filters as shown below. See the section on route filters for a detailed explaination of how they work. When no route filtering is specified (i.e. 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 considered as contributors. Put differently, if any filters are specified, an all restrict ; is assumed at the end of the list.
network [ exact | refines ]
network mask mask [exact | refines ]
network masklen number [ exact | refines ]
default
host host
|
| Previous | Next | Contents | Index |