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.