Following on from introducing prefixes
into BGP,
we now look at how to configure aggregation.
And we actually have the
same tools available to us.
Cisco IOS has the "redistribute static" and the "network"
statement and we show you how to use those.
there's also an additional command
called aggregate address
which was introduced to as another way of
configuring aggregation within IOS.
So let's look at each in turn.
So first off
redistributing static.
As with introducing a prefix into BGP, the
redistribute static can be used for introducing the aggregate as well.
Now
rather than having a specific prefix pointing to an interface,
or any customer link,
We now set up our aggregate and point it to the null interface.
In Cisco IOS
it's called "null", other vendors sometimes call it the discard interface,
but it has the same purpose, packets that get sent to that interface
are discarded by the
hardware in the router
So this is actually very handy, and it has two
purposes as well,
not only will this introduce the aggregate into the global RIB,
but it also means that packets headed towards that address space, for
where there's no more specific routing entry,
they will just be silently
discarded by the router.
So that's quite a handy feature when it comes to dealing
with dropping packets for which there's no specific path in the network.
So the
static route for the aggregate, to null,
puts it into the global RIB and then the
redistribute static command simply
will move that static route, and all others don't forget, into the BGP RIB, as we've seen already.
Looking at the "network" command, it's the same implementation here as well, static
route to null for the aggregate
and then we must have the matching
network statement within BGP
to introduce the prefix into the BGP RIB.
The network masks have to match exactly.
A subnet is not good enough, they have to
match exactly.
I consider this the easiest and best way of generating an
aggregate, and I've used this in many many implementations and applications
over recent years of helping network operators build and grow their infrastructure.
The third option is the "aggregate-address" command.
In my personal
experience I've tended to shy away from this, for a couple of reasons.
The first reason is, I actually much prefer using the network statement or in more advanced applications to redistribute static,
as it just seems a more natural way of
introducing prefixes into BGP.
What the aggregate-address command does, it will introduce an aggregate
into the BGP RIB, if a subnet of that aggregate exists in
the RIB.
Now that's fine as long as the subnet is there.
If the subnet disappears
for whatever reason, your aggregate vanishes as well.
One of the best
practices in the Internet industry is today,
is always always announce the
aggregate. Never let your aggregate disappear from the internet.
Because if your aggregate disappears,
you're then dealing with propagation
delays, advertisement intervals in BGP and so forth.
you do disappear from the network for a noticeable amount of time.
depending where you are can be anything from five minutes to over half an hour.
You want
stability for your network infrastructure,
so you want a stable way
of generating the aggregate in the network.
And what we generally do in most
service provider backbones,
is generate the aggregate in many different places,
many different points of presence across that backbone.
So coming back to the aggregate address, it has this dependency in that a subnet of the aggregate must
be in BGP,
otherwise a new aggregate will be generated.
So you have to be careful, if you want to use aggregate address make sure that the subnet,
that's going to cause the aggregate to be generated,
can never disappear.
Because if it does your aggregate vanishes as well, with the implications that has.
Cisco IOS has this "summary-only" keyword and other
implementations have a similar concept.
And that will only announce the
aggregate, it suppresses the more specific routes.
Again, you have to be
kind of careful with that implementation,
because if that subnet is a customer
prefix, connected to this router for example,
it could be that the customer
subnet disappears from your backbone,
so your other customers have no reachability to this particular one simply because you've used the "summary-only" command.
And so, generally when you start looking at these two issues I've highlighted,
I'm kind of nervous of even implementing the aggregate address these days.
One thing it does do, as we'll see a bit later on, is the aggregate address command
sets this aggregator attribute,
it lets you know which router
in the autonomous system generated the aggregate.
But these days given network
operators are generating aggregates in many many paths across this backbone,
I have not really found much use for the aggregator attribute itself.
other people's experience may vary, but I generally have found not much use
for that feature and that's really why I just don't really use the aggregate address command itself.
I much prefer the "network" statement I mentioned earlier
and the "redistribute static" which is the bit more advanced configuration which I also mentioned
earlier.
We'll see later on in the series,
examples of using the redistribute static in a properly controlled environment.
© Produced by Philip Smith and the Network Startup Resource Center, through the University of Oregon.
Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
This is a human-readable summary of (and not a substitute for) the license. Disclaimer. You are free to: Share — copy and redistribute the material in any medium or format Adapt — remix, transform, and build upon the material The licensor cannot revoke these freedoms as long as you follow the license terms. Under the following terms: Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. NonCommercial — You may not use the material for commercial purposes. No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.