|
0:00:13
|
In this section, we're gonna look at the other options
|
|
0:00:15
|
that are also on the aggregate address command.
|
|
0:00:19
|
Mainly, how we can change the attributes
|
|
0:00:21
|
with either a route map or an attribute map.
|
|
0:00:23
|
Or change what particular AS path information
|
|
0:00:27
|
that the aggregate is generated from
|
|
0:00:30
|
based on AS set and the advertised map options.
|
|
0:00:34
|
Now, if we were to look at the command line of router 2
|
|
0:00:37
|
who is generating a summary,
|
|
0:00:41
|
again, if we look at the Show Run Section Router BGP,
|
|
0:00:48
|
Router 2 is saying, Aggregate Address.
|
|
0:00:50
|
I'm generating the /20 and I'm generating this as only a summary.
|
|
0:00:55
|
If we look at the specific information, about the prefix 150.28.0.0/20,
|
|
0:01:01
|
We see router 2 says that this is a locally generated prefix.
|
|
0:01:05
|
The next hop is myself, 0.0.0.0
|
|
0:01:09
|
The origin is IGP, the local preference is 100.
|
|
0:01:12
|
Weight is 32768.
|
|
0:01:14
|
And this is the best route.
|
|
0:01:18
|
Now, if I wanted to modify any of the attributes on the aggregate locally,
|
|
0:01:24
|
we can do this with either the route map or the attribute map.
|
|
0:01:30
|
The same logic that also could be applied to the network statement as well,
|
|
0:01:34
|
if I were to say network 150.28.2.0 mask 255.255.255.0
|
|
0:01:42
|
So, the loopback subnet that were generating
|
|
0:01:46
|
if we look at the arguments on this command,
|
|
0:01:48
|
we could also specify a route map.
|
|
0:01:50
|
They could set the attributes locally
|
|
0:01:52
|
whether it'd be the local preference, the community value, the origin code, the weight.
|
|
0:01:59
|
We can change any of these values while we're actually originating the prefix.
|
|
0:02:04
|
Keypoint being here, that when we use the route map on the network statement itself,
|
|
0:02:09
|
it's going to affect the local BGP table on router 2.
|
|
0:02:13
|
As opposed to applying a route map out to the neighbor,
|
|
0:02:16
|
that is going to match that particular network.
|
|
0:02:19
|
That would be used to change the attribute as it is received by the remote peer.
|
|
0:02:24
|
Likewise, we could do the same onto the aggregate.
|
|
0:02:29
|
If we say Aggregate Address,
|
|
0:02:32
|
in this case, we're saying Summary Only.
|
|
0:02:34
|
We can either specify the attribute map or the route map to set the
|
|
0:02:39
|
particular attributes of the aggregate.
|
|
0:02:42
|
Now, for some reason, some of the older versions have both of these values,
|
|
0:02:45
|
the attribute map and the route map.
|
|
0:02:47
|
But essentially, they do the same thing.
|
|
0:02:50
|
If you look at the command reference for BGP
|
|
0:02:53
|
and look at the aggregate address command,
|
|
0:02:54
|
the attribute map isn't listed there anymore.
|
|
0:02:57
|
It's essentially the same exact thing you could do with the route map.
|
|
0:03:01
|
So, if I wanted to change the origin code for example,
|
|
0:03:05
|
I could have a route map that is...
|
|
0:03:07
|
we'll say origin...
|
|
0:03:10
|
incomplete.
|
|
0:03:12
|
It says, to set the origin code to incomplete,
|
|
0:03:16
|
then under the BGP process for this particular aggregate,
|
|
0:03:28
|
So, the aggregate address.
|
|
0:03:31
|
Then apply the route map origin_incomplete.
|
|
0:03:38
|
If we then look at the Show IP BGP for 150.28.0.0/20,
|
|
0:03:46
|
we could see now the local prefix that's being generated
|
|
0:03:49
|
does have the incomplete origin code.
|
|
0:03:51
|
So, whatever particular attribute that we wanna change,
|
|
0:03:54
|
we could either do this as the prefix is originated.
|
|
0:03:57
|
Or as it is going out to the neighbors or it's being received from the neighbors.
|
|
0:04:03
|
Now, one of the reasons that you may particularly want to set the attribute
|
|
0:04:07
|
as the prefix is being generated itself,
|
|
0:04:10
|
would be if we're trying to do some sort of administrative scoping on the route
|
|
0:04:14
|
based on the community attribute.
|
|
0:04:17
|
Now, we'll look at the communities and more detail a little bit later.
|
|
0:04:20
|
But we could say for example on router 1,
|
|
0:04:24
|
I wanna generate the aggregate so that it is advertised to router 6
|
|
0:04:31
|
and to router 4.
|
|
0:04:33
|
But I don't want this to be advertised to any of my EBGP peers.
|
|
0:04:38
|
I can accomplish that by locally setting the aggregate to be no export.
|
|
0:04:43
|
As opposed to setting it outbound to the neighbor.
|
|
0:04:48
|
Now, the difference in the order of operations,
|
|
0:04:51
|
would be that if router 1 advertises the aggregate out to 3,
|
|
0:04:56
|
and set the community to be no export,
|
|
0:04:58
|
it would mean that the prefix would not be exported out of AS 300.
|
|
0:05:04
|
However, if I were to set the no export community on the aggregate access itself,
|
|
0:05:11
|
it would mean the route would not be advertised out of AS 100.
|
|
0:05:16
|
So, it really just depends on who you want to process the attribute.
|
|
0:05:20
|
If you want the local the BGP table to process it
|
|
0:05:22
|
or do you want the remote neighbors to see it.
|
|
0:05:25
|
That would then determine what do you wanna set the attribute locally
|
|
0:05:28
|
on the netowrk statement or the aggregate versus outbound
|
|
0:05:31
|
to the neighbor or inbound from the neighbor.
|
|
0:05:37
|
There's a question here,
|
|
0:05:38
|
"In the Show IP BGP Command line Output,
|
|
0:05:40
|
what's the difference between aggregated and atomic aggregate?"
|
|
0:05:49
|
The aggregated means that we're locally doing it.
|
|
0:05:52
|
The atomic aggregate is the attribute that's actually set in the update
|
|
0:05:57
|
to tell the other nieghbors that this is not a specific match.
|
|
0:06:02
|
It's an aggregate that was generated from subnets.
|
|
0:06:05
|
So, if we look at the one that's coming from router 3
|
|
0:06:08
|
and the one that's coming from router 5,
|
|
0:06:10
|
these ones have the atomic aggregate attribute.
|
|
0:06:14
|
But they don't say aggregated.
|
|
0:06:16
|
Because router 2 here is not the one who is actually doing the advertisement.
|
|
0:06:22
|
The value of the person doing the aggregation is still maintained in the update.
|
|
0:06:27
|
We see the autonomous system, that did the aggregation,
|
|
0:06:30
|
and then the particular neighbor that did it.
|
|
0:06:32
|
Which is the router idea of router 1.
|
|
0:06:36
|
It's just that this value here aggregated this one is locally significant.
|
|
0:06:42
|
Now, the next two options that we have on to the aggregate command,
|
|
0:06:48
|
are going to be AS set and the...
|
|
0:06:54
|
AS set and the advertise map.
|
|
0:06:57
|
Now, the advertise map is only gonna be used in conjunction with the AS set.
|
|
0:07:02
|
If on the aggregate, we want to include all the autonomous systems
|
|
0:07:06
|
that all of the subnets came from,
|
|
0:07:10
|
but then selectively choose which AS's we want to include or exclude.
|
|
0:07:17
|
So, on router 2, let's say Aggregate Address.
|
|
0:07:19
|
The particular prefix, Summary Only.
|
|
0:07:22
|
Which means we're suppressing the subnets.
|
|
0:07:25
|
But then to include the AS set.
|
|
0:07:29
|
This means that when we look at the Show IP BGP,
|
|
0:07:32
|
and include 150.28,
|
|
0:07:35
|
all of the autonomous sytems that make up any of the subnets,
|
|
0:07:40
|
which in this case are ASs 100, 300 and 400,
|
|
0:07:45
|
they should then be included as an AS set to on to the aggregate itself.
|
|
0:07:52
|
Now, on router 2, if we look at the Show IP BGP for 150.28.0.0/20,
|
|
0:07:59
|
we see that the aggregation that router 2 is doing locally,
|
|
0:08:04
|
now, inside braces and includes 300, 100 and 400.
|
|
0:08:10
|
So, it means, somewhere along the path,
|
|
0:08:12
|
these subnets were passing through those three AS's.
|
|
0:08:19
|
If we were to look at the result of this from BB2's perspective,
|
|
0:08:23
|
where router 2 is advertising the aggregate out to,
|
|
0:08:26
|
we should see that that path information is gonna be maintained.
|
|
0:08:32
|
So, on BB2, if we look at the Show IP BGP,
|
|
0:08:35
|
150.28.0.0/20
|
|
0:08:42
|
This tells us that we're learning the prefix from AS 200.
|
|
0:08:47
|
But it's made up of subnets that pass through AS's 300, 100 and 400.
|
|
0:08:56
|
Now, generally, this is done for loop prevention
|
|
0:09:00
|
to maintain the autonomous systems that the subnets came from to begin with.
|
|
0:09:06
|
Because without the AS set keyword,
|
|
0:09:08
|
what's happening in this case when router 2 does the aggregation,
|
|
0:09:11
|
is that the prefix is advertised out to BB2, out to router 3 and out to router 5.
|
|
0:09:19
|
Eventhough the aggregate is made up of the subnets that we learned from 300 and learned from 400,
|
|
0:09:26
|
since the AS set is normally destroyed, where the AS path information is normally destroyed,
|
|
0:09:31
|
router 3 doesn't know that the aggregate is actually is made up of its own subnets.
|
|
0:09:38
|
Now, once we have the AS set keyword,
|
|
0:09:41
|
when router 3 receives this update inbound,
|
|
0:09:44
|
it's gonna say, "It has AS 300 in the path", which is my local AS number.
|
|
0:09:49
|
So, I'm not gonna accept that update in.
|
|
0:09:53
|
And we can see this on router 3 if we were to look at the Debug IP BGP Updates.
|
|
0:09:57
|
Then request a triggered update in from router 4.
|
|
0:10:02
|
So, we'll say Clear IP BGP 155.28.23.2 Inbound.
|
|
0:10:11
|
So, from router 2, we are requesting a new update.
|
|
0:10:15
|
We should see that we are receiving the aggregate, which is the /20.
|
|
0:10:22
|
But now, this is being denied because the AS path information contains our own autonomous system.
|
|
0:10:26
|
So, again, the arguements on to the aggregate,
|
|
0:10:33
|
it's simply to give us more control over
|
|
0:10:36
|
who either the aggregate or the subnets are being advertised to.
|
|
0:10:41
|
if we're using the AS set keyword,
|
|
0:10:43
|
it means that the originating autonomous sytem who had the subnets to begin with,
|
|
0:10:48
|
the aggregate is not gonna be advertised back to them.
|
|
0:10:53
|
Which in this type of case, it make sense.
|
|
0:10:55
|
Because if everyone in our internal network already has the /24 longer matches,
|
|
0:11:02
|
there's no reason that router 2 really needs to advertise to router 3, the /20.
|
|
0:11:08
|
The reason that this could potentially be an issue,
|
|
0:11:10
|
is let's say that router 1 looses connectivity to the other AS's.
|
|
0:11:17
|
Or let's say, somehow AS 100 as whole is isolated.
|
|
0:11:21
|
This means that 150.28.1.0
|
|
0:11:27
|
4.0 and 6.0, these are no longer reachable in the network.
|
|
0:11:33
|
But if router 2 is advertising the shorter match for these,
|
|
0:11:37
|
it means that AS 300 and AS 400
|
|
0:11:40
|
are gonna send traffic that's really destined for routers 1, 4 or 6
|
|
0:11:45
|
to router 2.
|
|
0:11:48
|
Whether we want that to occur or not,
|
|
0:11:50
|
it could then be automatically determine based on the AS path information.
|
|
0:11:55
|
So, when router 2 generates the aggregate,
|
|
0:11:57
|
if it says. "Inculde AS's 100, 300 and 400",
|
|
0:12:00
|
Then even if the routes are advertised back to those neighbors,
|
|
0:12:04
|
it's gonna be autmoatically filtered inbound.
|
|
0:12:11
|
So again, by default, when we add the AS set keyword,
|
|
0:12:14
|
it's gonna configure or add the ordered set of all the autonomous systems
|
|
0:12:20
|
that any of the subnets were either originated from or passed through.
|
|
0:12:26
|
So 100, 400, and 300 in this case.
|
|
0:12:31
|
Now, if for some reason, router 2 wanted to advertise the aggregate back to router 3,
|
|
0:12:39
|
what we could do is edit the AS path information router 2,
|
|
0:12:44
|
to say, "Do not include AS number 300 in the AS set."
|
|
0:12:49
|
"But do include 100 and 400."
|
|
0:12:53
|
This would mean that when router 2 advertises the aggregate to router 5,
|
|
0:12:58
|
it would be discarded.
|
|
0:13:01
|
But when the aggregate goes to router 3, it would be accepted.
|
|
0:13:05
|
As long as AS number 300 is not in the AS path.
|
|
0:13:09
|
And this is what the advertise map is used for under the aggregate statement.
|
|
0:13:15
|
So, on router 2, the first thing we're gonna do is create a policy that says,
|
|
0:13:18
|
"Exclude AS number 300...
|
|
0:13:22
|
from the AS set."
|
|
0:13:26
|
To do this, we need to match the actual AS number which is by and AS path access list.
|
|
0:13:32
|
So, our frist step on router 2, we'll go to global config.
|
|
0:13:35
|
And to find an IP AS path access list.
|
|
0:13:40
|
I'll say this is 300 to match AS 300.
|
|
0:13:44
|
I want to permit anything that has the number 300 in it.
|
|
0:13:50
|
This will be the regular expression underscore 300 underscore.
|
|
0:13:56
|
So, whether this is being learned from router 3, being originated from...
|
|
0:13:59
|
or actually...
|
|
0:14:02
|
Learned from AS 300.
|
|
0:14:05
|
Originated from AS 300 or passed through AS 300.
|
|
0:14:08
|
Anywhere in the AS path information, 300 now is gonna be matched.
|
|
0:14:16
|
So, again, just like I did with the prefix list before,
|
|
0:14:19
|
the access list logic is used to match, not to permit or deny.
|
|
0:14:24
|
The permit or deny logic is gonna stay inside of the route map.
|
|
0:14:28
|
This is gonna make sure that we do not end in a double negative.
|
|
0:14:32
|
Because if the access list says deny, then the route map says deny,
|
|
0:14:37
|
it does not mean to deny the prefix, it means do not match the prefix.
|
|
0:14:44
|
So, it can be a kind of a confusing logic if we end in the double negative.
|
|
0:14:49
|
That's why the list should always say permit which is used just to match
|
|
0:14:52
|
then whether we're actually allowing or denying a prefix,
|
|
0:14:55
|
that's gonna be controlled by the route-map.
|
|
0:15:00
|
So, on router 2, we'll say Route Map Exclude AS 300,
|
|
0:15:05
|
is going to deny anything that matches AS path 300.
|
|
0:15:13
|
Now, note here, this number 300, this is not the actual AS number.
|
|
0:15:17
|
I'm just naming the list number 300 for clarity.
|
|
0:15:21
|
I still need to match the regular expression that's calling that particular AS number.
|
|
0:15:29
|
So. we'll deny any AS that includes 300.
|
|
0:15:32
|
Then permit everything else. So, we'll say Permit 20.
|
|
0:15:38
|
Now, under the BGP process, once we generate the aggregate,
|
|
0:15:42
|
so, the same syntaxes before, we have summary only and the AS set.
|
|
0:15:47
|
Now, I want to include an advertise map
|
|
0:15:50
|
that is to exclude AS 300.
|
|
0:16:02
|
If we now look at the result of Show IP BGP 150.28.0.0/20,
|
|
0:16:12
|
we see that when router 2 is generating the aggregate,
|
|
0:16:16
|
it's not including...
|
|
0:16:19
|
the AS number 300.
|
|
0:16:23
|
Now, in this case, it actually had to exclude 100 as well.
|
|
0:16:27
|
Becasue 100 is in the same path as the 300.
|
|
0:16:35
|
So, depending whether we're learning the prefix directly from that AS
|
|
0:16:39
|
or whether it's transitting through something else,
|
|
0:16:41
|
the regular expression in this case is matching that full path, it's matching 100 and 300.
|
|
0:16:48
|
If we look at the result of this in BB2,
|
|
0:16:51
|
when we Show IP BGP 150.28.0.0/20,
|
|
0:16:59
|
the AS path information is 200 and 400 but not 300.
|
|
0:17:12
|
So, depending if AS 300 is actually originating the aggregate locally,
|
|
0:17:17
|
then that's gonna control whether we can still include number 100.
|
|
0:17:22
|
It depends on the actual match that we're doing in the regular expression.
|
|
0:17:26
|
But the keypoint being here, if you do want to include the AS set, but only part of it,
|
|
0:17:31
|
that's what both the AS set and the advertise map is for at the same time.
|
|
0:17:40
|
So, it's a really specific design
|
|
0:17:43
|
where you want the AS that has the subnets of the aggregate in order to receive the aggregate back.
|
|
0:17:51
|
Where normally, you wouldn't do that for a loop prevention mechanism.
|
|
0:17:55
|
But technically, you can.
|
|
0:17:58
|
So, we'll see a lot of this options in BGP,
|
|
0:18:01
|
it's not whether this is a good design principle or whether it's a bad design principle.
|
|
0:18:06
|
BGP just gives us the flexibility to pretty much do whatever we want.
|
|
0:18:11
|
Then it's up to us to define whether we should apply this policy or not.
|
|
0:18:16
|
So, there maybe cases where it doesn't make sense to do this.
|
|
0:18:20
|
But likewise, there maybe some real corner case design where
|
|
0:18:23
|
a particular service provider does need to exclude one autonomous system from the AS set.
|
|
0:18:32
|
So, let's take a look at this in the documentation. If we go to...
|
|
0:18:38
|
the 12.4 T Configuration Guide.
|
|
0:18:41
|
Then down to BGP Configuration.
|
|
0:18:48
|
You see, there's a couple different sections here
|
|
0:18:50
|
and really unless you read through all of these documents, it would be hard to keep track
|
|
0:18:54
|
as to where the particular features located.
|
|
0:18:58
|
So, what you may wanna do in the actual exam if you need the reference this configuration guide,
|
|
0:19:03
|
you may wanna just open all of the documents.
|
|
0:19:07
|
At least the first ones like, we know it's not gonna be in BGP link bandwidth,
|
|
0:19:10
|
or BGP policy accounting.
|
|
0:19:12
|
But I don't know if aggregation is in configuring a basic BGP network
|
|
0:19:16
|
or configuring advanced BGP features.
|
|
0:19:20
|
So, once I have these different guides open,
|
|
0:19:23
|
then I'm just gonna search inside the page for the aggregate address.
|
|
0:19:31
|
And I believe it did match here.
|
|
0:19:34
|
BGP route aggregation.
|
|
0:19:37
|
So, you'll see some examples in this configuration guide,
|
|
0:19:45
|
as to how the aggregation is gonna work.
|
|
0:19:54
|
And then also about the AS set information.
|
|
0:19:57
|
Generally, this type of stuff, you ideally wouldn't need to reference the configuration guide for it.
|
|
0:20:03
|
If you're stuck on a problem like this, you're better off looking at just the command reference.
|
|
0:20:06
|
So you can see what the usage information for an individual arguement is.
|
|
0:20:12
|
So, therefore, we'd go to the 12.4 T command reference.
|
|
0:20:16
|
Which again, If we were to start at the main documentation page,
|
|
0:20:20
|
we would go to Products, IOS,
|
|
0:20:24
|
Regular IOS,
|
|
0:20:26
|
12.4 T,
|
|
0:20:30
|
then under reference guides,
|
|
0:20:33
|
the Command Reference.
|
|
0:20:37
|
Down to BGP Command Reference,
|
|
0:20:39
|
this will be in the first section...
|
|
0:20:44
|
A through B.
|
|
0:20:46
|
Which is here, aggregate address.
|
|
0:20:51
|
Some of these arguements, you'll see are not available in the particular versions that we're using.
|
|
0:20:55
|
So, anytime you're looking at the command reference, if you scroll past the user guidelines,
|
|
0:21:00
|
it will tell you exactly which particular release
|
|
0:21:04
|
the keyword was added.
|
|
0:21:06
|
So, it says that the AS confed set was added in 12.2.33 SRE,
|
|
0:21:12
|
where I believe SRE is the one at the service provider trains.
|
|
0:21:19
|
So, since it doesn't say either 12.4 T or 15.0,
|
|
0:21:25
|
then it most likely means that in our particular versions, we wouldn't have the AS confed set keyword.
|
