 |  |
| |
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 addresses, 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] [bgp]]
[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:
Aggregations are to be formed using BGP protocol rules.
Defines the preference of the resulting aggregate route. The default is 130.
Specifies that the AS path of the aggregate route should be the longest common AS path. The default is to build an AS path consisting of all contributing AS paths.
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.
Only aggregate routes learned from the specified autonomous system.
Only aggregate routes with the specified tag.
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 contribute only to an aggregate route that is more general than itself. Any given route may contribute to only 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]
[brief] {
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 were described earlier in this appendix.
|  | |
| B.10. Control Statements |  | C. A named Reference |
Copyright © 2002 O'Reilly & Associates. All rights reserved.