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 inter-domain
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.
|