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
| masklennumber
]
[ preferencepreference
] [ brief ] {
protoproto
[ asas_number
| tagtag
| aspathaspath_regexp
]
[ restrict ] |
[[ preferencepreference
] {
route_filter
[ restrict | ( preferencepreference
)]] ;
} ;
Several options are available for the aggregate statement:
preference;
Defines the preference of the resulting aggregate route. The default is 130.
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
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_number
Only aggregate routes learned from the specified autonomous system.
tag
Only aggregate routes with the specified tag.
aspath_regexp
Only aggregate routes that match the specified AS path.
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
| masklennumber
]
[ preferencepreference
] {
protoproto
[ asas_number
| tagtag
| aspathaspath_regexp
]
[ restrict ] |
[[ preferencepreference
] {
route_filter
[ restrict | preferencepreference
]] ;
} ;
} ;
The generate statement uses many of the same options as the aggregate statement. These options are described earlier in this appendix.