B.11 The Aggregate Statements

Route aggregation is used by regional and national networks to reduce the number of routes advertised. With careful planning, large network providers can announce a few aggregate routes instead of hundreds of client network routes. Enabling aggregation is the main reason that CIDR blocks are allocated as contiguous address blocks.

Most of us don't have hundreds of routes to advertise. But we may have a classless address composed of a few class C address and we may need to tell gated how to handle it. Older versions of gated automatically generated an aggregate route to a natural network using the old Class A, B, and C concept; i.e., interface address 192.168.16.1 created a route to 192.168.16.0. With the advent of classless interdomain routing, this can be the wrong thing to do. gated does not aggregate routes unless it is explicitly configured with the aggregate statement:

aggregate default | address [mask mask | masklen number]
[preference preference] [brief] {
proto proto
[as as_number | tag tag | aspath aspath_regexp]
[restrict] |
[[preference preference] {
route_filter [restrict | (preference preference)]] ;
} ;

Several options are available for the aggregate statement:

preference preference;

Defines the preference of the resulting aggregate route. The default is 130.

brief

Specifies that the AS path of the agregate route should be the longest common AS path. The default is to build an AS path consisting of all contributing AS paths.

proto proto

Only aggregate routes learned from the specified protocol. The value of proto may be any currently configured protocol. This includes the "protocols" direct, static, and kernel, discussed in the previous section; all for all possible protocols; and aggregate for other route aggregations.

as as_number

Only aggregate routes learned from the specified autonomous system.

tag tag

Only aggregate routes with the specified tag.

aspath aspath_regexp

Only aggregate routes that match the specified AS path.

restrict

Indicates routes that are not to be aggregated.

Routes that match the route filters may contribute to the aggregate route. A route may only contribute to an aggregate route that is more general than itself. Any given route may only contribute to one aggregate route, but an aggregate route may contribute to a more general aggregate.

A slight variation of aggregation is the generation of a route based on the existence of certain conditions. The most common usage for this is to create a default based on the presence of a route from a peer on a neighboring backbone. This is done with the generate statement.

generate default | address [mask mask | masklen number]
[preference preference] {
proto proto
[as as_number | tag tag | aspath aspath_regexp]
[restrict] |
[[preference preference] {
route_filter [restrict | preference preference]] ;
} ;
} ;

The generate statement uses many of the same options as the aggregate statement. These options are described earlier in this appendix.