|
0:00:13
|
The next topic we're gonna look at here in BGP,
|
|
0:00:16
|
is the BGP aggregation feature,
|
|
0:00:19
|
which as I mention is much more flexible than we saw before in IGP summarization
|
|
0:00:25
|
in either EIGRP or OSPF or RIP,
|
|
0:00:29
|
because BGP gives us a lot of different options to control the individual attributes,
|
|
0:00:35
|
that the aggregate is being generated with.
|
|
0:00:37
|
Also we have a lot to control to figure out
|
|
0:00:40
|
whether we are sending the subnets of the aggregate on a per-neighbor basis or on a per-process basis,
|
|
0:00:47
|
and what the AS path information is gonna be generated based on a particular subnets.
|
|
0:00:55
|
Now the pre-requisite to configure BGP aggregation
|
|
0:00:58
|
is that we need to make sure that we have at least one of the subnets inside of the BGP table.
|
|
0:01:06
|
Key point being here is that we're matching on the BGP table not on the routing table.
|
|
0:01:11
|
So, in the case of our topology, if we were trying to do an aggregation based on the loopback addresses,
|
|
0:01:17
|
we would need to make sure that the loopbacks, at least one of the subnets is advertised into the BGP table
|
|
0:01:22
|
before we can actually do the aggregation.
|
|
0:01:26
|
So, this means that the pre-requisite would be either the network statement or the redistribute statement,
|
|
0:01:31
|
and to make sure at least one of the prefixes
|
|
0:01:34
|
that are subnets of the aggregate are installed in the table.
|
|
0:01:39
|
Now, once this condition is met, then we use the aggregate address command under the BGP process,
|
|
0:01:44
|
specify what is the prefix and the prefix length that we want to generate,
|
|
0:01:48
|
followed by any other optional arguements.
|
|
0:01:52
|
Now, if we don't specify anything other than just the network and the mask,
|
|
0:01:56
|
BGP is going to originate the aggregate address,
|
|
0:02:00
|
but it's not gonna do any type of filtering on the subnets.
|
|
0:02:04
|
So, we're using it just to originate the prefix,
|
|
0:02:06
|
it does not have any limitation as to what is being advertised to the remote neighbors.
|
|
0:02:15
|
So, on our particular case, what I'm gonna do now is on the network edge,
|
|
0:02:20
|
which is gonna be on routers 4 and 6, and router 2,
|
|
0:02:24
|
I'm gonna advertised an aggregate for the loopback address space.
|
|
0:02:29
|
Before I do this on router 2, I'm gonna advertised its specific subnet
|
|
0:02:33
|
in the BGP for the loopbacks
|
|
0:02:36
|
to make sure AS's 100, 300 and 400 have reachability to that,
|
|
0:02:40
|
and in also on router 3, switch 1, and switch 3.
|
|
0:02:49
|
So, on router 2 under the BGP process, let's go to router BGP 200,
|
|
0:02:54
|
and I'm simply gonna classify the network statement.
|
|
0:02:56
|
So let's say, "Network 150.28.2.0 with the mask of /24",
|
|
0:03:06
|
if we then look at the Show IP BGP regular expression a caret dollar sign (^$),
|
|
0:03:10
|
we should see our own loopback is being originated into the process, which it is.
|
|
0:03:17
|
Then on router 3, if we look at the Show IP Route EIGRP,
|
|
0:03:23
|
these are the prefixes internal to our autonomous system,
|
|
0:03:28
|
and I wanna advertise the loopback of router 3 plus the loopback of swich 1 and switch 3.
|
|
0:03:35
|
So I could either do redistribution of EIGRP into the BGP process, or I could use the network statements.
|
|
0:03:44
|
So, again really the only functional difference between the two of them,
|
|
0:03:47
|
is that with the redistribution we're gonna set the origin code to incomplete.
|
|
0:03:55
|
Where we're still copying the IGP metric to the BGP med.
|
|
0:04:01
|
Now, we do have the flexibility to set whatever the attributes we want on to the BGP process,
|
|
0:04:06
|
so I could technically create a route map that says,
|
|
0:04:09
|
"Match those EIGRP prefixes, but also set the origin code to be IGP",
|
|
0:04:15
|
which means that I would be able to redistribute them,
|
|
0:04:17
|
but thet will not show up as the question mark, on the origin code.
|
|
0:04:23
|
So, as I mentioned, we'll get into this in more detail when we get into the best path selection,
|
|
0:04:27
|
because that's automatically where it's going to affect.
|
|
0:04:29
|
Whether we're choosing the prefix based on the IGP origination with the network statement versus the
|
|
0:04:36
|
versus the redistribution.
|
|
0:04:39
|
So, on router 3 now we'll simply, matched the,
|
|
0:04:43
|
the network as well so it should network 150.28.3.0/24,
|
|
0:04:51
|
7.0 and then 9.0
|
|
0:04:57
|
We now look at the Show IP BGP regular expression caret dollar sign (^$),
|
|
0:05:03
|
we see that our three loopbacks local to AS 300 are now being advertised into BGP.
|
|
0:05:10
|
If we were to look at any of the remote peers,
|
|
0:05:14
|
let's say, BB1, 2, or 3, we should see that we have routes to,
|
|
0:05:19
|
all of the loopbacks exact routes from router 1 all the way to switch 4.
|
|
0:05:26
|
Now, as I mentioned before in the actual exam,
|
|
0:05:28
|
you're not gonna have an access to the backbone routers to do any types of verifications,
|
|
0:05:32
|
but if you're using our rack rentals for any of the testing of these, types of exercises,
|
|
0:05:38
|
you can log it into them just to do some basic verifications.
|
|
0:05:43
|
So, if we were to go to the, the access server, and then Reverse Telnet to BB1,
|
|
0:05:50
|
we could see with this the banner message that shows you a bunch of show commands you could do,
|
|
0:05:55
|
in this particular case I wanna look at the Show IP BGP.
|
|
0:06:00
|
So, I have the exact subnet routes for 150.28.1.0 all the way to 10.0
|
|
0:06:09
|
If we look at the Show IP Route Connected, on BB1 these 112 through the 113 addresses,
|
|
0:06:21
|
these are essentially just the loopbacks that are connected on this router,
|
|
0:06:25
|
so if I were to ping 115.28, let's say "router 3", 3.3 and sources from loopback 112,
|
|
0:06:34
|
then I should get a response back in.
|
|
0:06:40
|
So, this would have to be a previledge 15, we see that we do a reachability to router 3.
|
|
0:06:47
|
Now, if I didn't change the source address here,
|
|
0:06:49
|
unless router 3 had a route back to the frame-relay link between router 6 and BB1,
|
|
0:06:56
|
then we're not gonna get a response back in.
|
|
0:06:59
|
So, to gain a key point, always to make sure you know exactly what's advertised in the BGP,
|
|
0:07:03
|
cause that's what you need to do the connectivity testing from.
|
|
0:07:10
|
Now, I could test all of these but, in general as long as I reachability to one of them,
|
|
0:07:14
|
I'm pretty confident that I'm gonna have reachability to the rest of them.
|
|
0:07:18
|
Cause we haven't done any type of filtering, we don't really have a complex policy going on with BGP yet.
|
|
0:07:25
|
So, the next thing I'm gonna do is go to router 2,
|
|
0:07:28
|
and I want to generate an aggregate that is gonna matched all 10 of these particular loopbacks.
|
|
0:07:35
|
So, the next thing I would then need to know
|
|
0:07:37
|
is what's an aggregate that's going to encompass all 10 of the addresses.
|
|
0:07:42
|
So, this is the same type of summarization logic like in IGP,
|
|
0:07:46
|
there's a lot of different shortcuts to do this, but personally,
|
|
0:07:50
|
I like to do it the long way with writing the addresses out in binary,
|
|
0:07:53
|
just so I can visually see the address and make sure that I'm not making any mistakes.
|
|
0:07:58
|
So, I know specifically in this case, the addresses are gonna be 150.28.1.0 all the away through 150.28.10.0
|
|
0:08:12
|
So, I really just need to look at what's the first address in the range and what is the last address in the range.
|
|
0:08:19
|
Now, we know based on just looking at the addresses here
|
|
0:08:22
|
that at least the first 16 bits are gonna be the same,
|
|
0:08:26
|
so I could summarize this to 150.28.0.0/16, if I want to go a little bit further,
|
|
0:08:33
|
then I'm gonna have to look at what is the bit values in the third octet.
|
|
0:08:39
|
So, for the first address if we were to look at the third octet in binary,
|
|
0:08:44
|
this is simply all zeroes and a one, so 00000001, where the 10 is going to be on 8 and a 2,
|
|
0:08:58
|
so this will be 0000 on 8 and a 2,
|
|
0:09:05
|
which means that the first 4 bits are in common between these two addresses.
|
|
0:09:11
|
So, then I would be able to summarize, 150.28.0.0 we already know we have /16 so 17, 18, 19, 20.
|
|
0:09:21
|
So, our summary is going to be 150.28.0.0/20.
|
|
0:09:29
|
Again, as long as we have one of the subnets in the BGP table,
|
|
0:09:34
|
that's the criteria we need to matched in order to originate the aggregate.
|
|
0:09:38
|
Now, this would also mean in a real design,
|
|
0:09:42
|
if for some reason the router losses the route to the subnet in the BGP table,
|
|
0:09:47
|
it means that it's going to withdraw the aggregate advertisement.
|
|
0:09:51
|
Which is ideally what you should want, because if we have multiple exit points out of the network,
|
|
0:09:57
|
let's says router 6 and router 4, where router 6 is advertising an aggregate to BB1,
|
|
0:10:03
|
router 4 is advertising it to BB3, if router 6 losses its connection to the rest of the internal network,
|
|
0:10:10
|
we would not want it to still advertise that summary, to BB1.
|
|
0:10:18
|
So, if router 6 doesn't have any of the subnets on the table,
|
|
0:10:21
|
it means that it's automatically going to withdraw the aggregate.
|
|
0:10:27
|
So, next let's go to router 2, where we're actually going to originate this.
|
|
0:10:32
|
So, we go on to the BGP process, specify the aggregate,
|
|
0:10:36
|
is 150.28.0.0, with the mask of 255.255.240.0,
|
|
0:10:51
|
if we now look at hte Show IP BGP regular expression caret dollar sign (^$),
|
|
0:10:56
|
we see that now router 2 is originating not only the subnet, but the /20 aggregate.
|
|
0:11:04
|
Now, in general we'll see that the attributes of the aggregates are going to be inherited from the subnets,
|
|
0:11:12
|
the only problem you can run into though
|
|
0:11:13
|
is that if the subnets have tons of different attributes that are not similar to each other,
|
|
0:11:18
|
then there is no way to the aggregate can reflect that.
|
|
0:11:21
|
So, if some of the subnets have the origin code incomplete, some of them have IGP,
|
|
0:11:25
|
then the origin code of the aggregate is not accurately going to reflect that.
|
|
0:11:30
|
But if we look at the attributes on router 2 and Show IP BGP,
|
|
0:11:34
|
for 150.28.0.0/20,
|
|
0:11:41
|
we see that the new attributes that are significant here,
|
|
0:11:44
|
is that the prefix now listed as an atomic aggregate,
|
|
0:11:49
|
which is telling the other BGP processes that someone is doing the aggregation here,
|
|
0:11:53
|
then specificly, who is doing the aggregation, or who is the aggregator.
|
|
0:12:00
|
So, in this case we know that router 2 is doing the origination of this,
|
|
0:12:04
|
okay, of some reason these prefix gets advertised out and then received back in by router 2,
|
|
0:12:08
|
it's not going to accept because it's the one who is actually originating the aggregate.
|
|
0:12:14
|
Now, once this is advertised out to the out BGP peers,
|
|
0:12:19
|
we'll see that the other subnets that make up the aggregate,
|
|
0:12:22
|
in this case, if we look at the Show IP BGP and include 150.28,
|
|
0:12:30
|
we see that there's a variety of different attributes here,
|
|
0:12:34
|
like the med values, the AS path information, the origin code, some of them are incomplete some of them are IGP,
|
|
0:12:42
|
when router 2 is doing the aggregation here, it's basically throwing away the attributes of the AS path,
|
|
0:12:49
|
and some of the other subnets, like we can't use the med value of 156160 and 0 and null,
|
|
0:12:57
|
so by default, router 2 is just gonna use null.
|
|
0:13:01
|
We could manually change this if we want to,
|
|
0:13:04
|
it's just that the majority of these attributes are going to be stripped from the aggregate.
|
|
0:13:09
|
If we look at the end result of this from, let's say BB2 who router 2 is connected to,
|
|
0:13:17
|
and look at the Show IP BGP, 150.28.0.0/20,
|
|
0:13:27
|
it still has the attributes that, this is a atomic aggregate,
|
|
0:13:30
|
router 2 is the aggregator,
|
|
0:13:32
|
and the AS path information now includes just router 2's autonomous system just AS 200.
|
|
0:13:41
|
However, if we look at the Show IP BGP, and look at the rest of the output,
|
|
0:13:45
|
we'll see that BB2 is still gonna be receiving all of the subnets that are making up the aggregate.
|
|
0:13:52
|
So, unlike aggregation in EIGRP or OSPF or RIP,
|
|
0:13:57
|
BGP aggregation does not automatically suppressed any of the subnet advertisements.
|
|
0:14:02
|
The reason why, is it gives us the flexibility to choose either globally to the process or on a per-neighbor basis,
|
|
0:14:10
|
exactly what particular advertisements we want to send them.
|
|
0:14:16
|
Now, depending on what the ultimate design is,
|
|
0:14:19
|
usually when we're doing aggregation, it means that we're trying save size in the BGP table.
|
|
0:14:25
|
So, it doesn't make sense that if we're advertising /20,
|
|
0:14:28
|
then we're also gonna advertise all the individual /24's out to the global BGP table.
|
|
0:14:34
|
So, in the vast majority cases if we were to do this aggregation on router 2,
|
|
0:14:38
|
when the prefix is going this direction,
|
|
0:14:41
|
we would wanna send the /20 but not in any individual subnets.
|
|
0:14:47
|
So, there's a lot of different ways that we can do this,
|
|
0:14:49
|
mainly this is gonna be controlled by those arguments that we have on to the command.
|
|
0:14:55
|
If we were to use the summary only argument,
|
|
0:14:58
|
it means any subnets that are part of the aggregate,
|
|
0:15:01
|
will then be suppressed in not advertised to any of our BGP peers.
|
|
0:15:06
|
This is going to include both our iBGP and our EBGP peers.
|
|
0:15:15
|
So, on router 2, if we were to modify the aggregate address command,
|
|
0:15:20
|
so under BGP 200,
|
|
0:15:26
|
we'll say, Aggregate Address, then summary only,
|
|
0:15:32
|
we should see the change now when we look at Show IP BGP and look at the rest of those subnets,
|
|
0:15:37
|
they're all now gonna get the status code lower case s, which means suppressed.
|
|
0:15:44
|
If I were to look at the details behind the attributes of any of these routes,
|
|
0:15:49
|
let's say, Show IP BGP, for 150.28.2.0/24,
|
|
0:15:58
|
says that this particular prefix is not advertised to any peer.
|
|
0:16:03
|
And the reason why is that the advertisement is being suppressed by the aggregate.
|
|
0:16:10
|
If we were to now look at BB2, and look at the change on the BGP table,
|
|
0:16:16
|
we'll see now we're only receiving the aggregate 150.28.0.0/24, or excuse me /20,
|
|
0:16:24
|
and not any of the individual subnets.
|
|
0:16:28
|
We should also now be able to see this from router 2,
|
|
0:16:31
|
when we look at the prefixes that we're advertising outbound,
|
|
0:16:35
|
so if we look at the Show IP BGP summary,
|
|
0:16:39
|
we'll see router 2 has three different peers, router 3, 5 and BB2.
|
|
0:16:45
|
If we look at the Show IP BGP neighbor, the neighbor's address 192.10.28.254,
|
|
0:16:54
|
and the advertised routes, we see router 2 is advertising the /20, but not on the /24s.
|
|
0:17:04
|
Likewise, if we were to look at the same output for router 5,
|
|
0:17:08
|
we'll say Show IP BGP neighbors, for the peer 155.28.0.5 advertised routes,
|
|
0:17:17
|
we're advertising them to /20 but not the /24.
|
|
0:17:26
|
Now, ultimately on this particular design, everyone still should have reachability to router 2's loopback,
|
|
0:17:32
|
it's simply that the replacing the previous /24 longer matched than they had,
|
|
0:17:37
|
with now the shorter matched of /20.
|
|
0:17:42
|
So, if I were to go to router 6,
|
|
0:17:45
|
and ping 150.28.2.2, source this from my own local loopback.
|
|
0:17:57
|
we see that we do have connectivity.
|
|
0:17:59
|
If we were to do a trace route on this, if we trace 150.28.2.2 then sources from our loopback zero,
|
|
0:18:06
|
we can see the particular BGP best path that we're choosing.
|
|
0:18:10
|
So, in this case we're going out to switch 1, and from switch 1 to router 3, then from router 3 to router 2.
|
|
0:18:20
|
So, we're not losing any reachability here,
|
|
0:18:22
|
we're simply summarizing the network informations so that the BGP table is smaller.
|
|
0:18:30
|
The same type of implementation on router 2 there's a lot of ways that we could do it though.
|
|
0:18:35
|
So, just one of those options there is with the, the summary only key word.
|
|
0:18:41
|
The only potential problem with this is that the summary only key word
|
|
0:18:45
|
is going to affect all of the neighbors at the same time.
|
|
0:18:48
|
Both our internal peers and our external peers.
|
|
0:18:53
|
Now, where could this be a potential issue is depending on where we are actually originating those individual subnets.
|
|
0:19:03
|
So, let's say now, we were to go to router 1,
|
|
0:19:10
|
and we're gonna do the same type of aggregation.
|
|
0:19:13
|
I wanna generate 150.28.0.0/20 on router 1,
|
|
0:19:20
|
and to all of the peers I wanna send just the summary.
|
|
0:19:26
|
So, on router 1, we'll basically do the same exact syntax as we did on router 2,
|
|
0:19:31
|
router BGP 100, generate the aggregate, we now look at the Show IP BGP,
|
|
0:19:42
|
we should see all of the subnets, all the /24s now have the status code of the lower case s,
|
|
0:19:49
|
so it means, all of these are suppressed,
|
|
0:19:52
|
but we should now be advertising the /20.
|
|
0:19:56
|
We should be advertising this to both router 4 and router 6 internal to our BGP network.
|
|
0:20:02
|
If we now Show IP BGP, on router 6, 6 should see the aggregate,
|
|
0:20:10
|
but it's not gonna see the subnets coming in from router 1.
|
|
0:20:16
|
Now it is seen alternate advertisements from the other peers,
|
|
0:20:19
|
because we have a very diverse connectivity of the peerings here,
|
|
0:20:24
|
but the potential problem that we can run into now,
|
|
0:20:26
|
is that we essentially have overlapping routes, that are matching the loopbacks of routers 1, 4 and 6,
|
|
0:20:36
|
that's the same match for the loopback of router 2.
|
|
0:20:42
|
This would then mean, depending on where the neighbor choose they're route,
|
|
0:20:46
|
whether they're using the /20 via router 1 or they're using the /20 via router 2,
|
|
0:20:51
|
some of the devices will have reachability to choose loopbacks,
|
|
0:20:54
|
some of them will have reachability to force, but not both on the same time.
|
|
0:21:00
|
If we were to look at this from, let's say router's 5 perspective,
|
|
0:21:06
|
and Show IP route 150.28.1.1, versus 2.2,
|
|
0:21:15
|
we can see in both cases the longer match of these addresses is the /20.
|
|
0:21:24
|
Router 5 says to get to the / 20, I'm going to router 2,
|
|
0:21:28
|
regardless whether this is matching router 1s loopback or router 2s loopback.
|
|
0:21:34
|
So, simply based on the fact that we have multiple matches to the same prefix,
|
|
0:21:39
|
router 5 is gonna havr to choose one over the other.
|
|
0:21:43
|
And since we have no visibility to figure out, where is the particular subnet of router 1 located,
|
|
0:21:49
|
we see that, that traffic is misrouted where coinsidentally the traffic that goes to router 2,
|
|
0:21:57
|
should go on the correct direction, which it is.
|
|
0:22:04
|
So, in this particular design, it might make sense to allow some neighbors to see the individual subnets,
|
|
0:22:12
|
but then at the same time make sure that the other external peers are only seeing the summary.
|
|
0:22:19
|
We could do this a couple different ways.
|
|
0:22:20
|
We could do this with the suppressed map under the aggregate,
|
|
0:22:25
|
that is gonna say which of the individual subnets do we not want to advertised.
|
|
0:22:32
|
We could suppressed all of the subnets then on a per-neighbor basis,
|
|
0:22:35
|
apply the unsuppressed map, which would be the opposite of the suppressed map,
|
|
0:22:41
|
so it says for whatever prefixes are suppressed, I do wanna advertise it to this individual peer,
|
|
0:22:47
|
or we could simple, simply filter on, a per-neighbor basis with a route map,
|
|
0:22:53
|
what particular subnets we do or do not want to advertised.
|
|
0:22:58
|
So, let's say that from router 1's perspective,
|
|
0:23:01
|
I want to leak this individual subnets as it goes to the internal peers.
|
|
0:23:11
|
So, I'm doing the aggregation but I also want to make sure that the individual subnets are advertised.
|
|
0:23:17
|
Now, technically I don't need to advertised this to router 4 and to router 6,
|
|
0:23:21
|
because they already have IGP routes to this particular destinations,
|
|
0:23:25
|
what I would wanna do is advertised them to router 3 and to router 5.
|
|
0:23:34
|
So, again a couple of different ways I could this,
|
|
0:23:36
|
I could simply specify the aggregate on its own, then selectively filter the subnets,
|
|
0:23:47
|
so on router 1, let's say, Show Run Section Router BGP,
|
|
0:23:56
|
I'm gonna remove the aggregate then re-apply it without the summary only.
|
|
0:24:05
|
So, right now, I'm just generating the prefix that's gonna advertised both the summary, and the subnets.
|
|
0:24:12
|
We look at the Show IP BGP summary, router 1 has four different peers.
|
|
0:24:19
|
For the first two peers, I want to send them the summary but not the subnets.
|
|
0:24:26
|
So, to router 4 and to router 6, I want to send them the /20 route but not the /24s.
|
|
0:24:33
|
For router 5 and router 3, I want to send them the loopbacks of router 1, 4 and 6 specifically
|
|
0:24:43
|
to make sure they have the exact match to those particular prefixes.
|
|
0:24:49
|
So I'm gonna essentially have two different policies here.
|
|
0:24:51
|
One, that goes to the internal peers and one that goes to the external peers.
|
|
0:24:55
|
The one that goes to router 4 and router 6
|
|
0:24:59
|
is gonna filter all of the subnets.
|
|
0:25:01
|
Now, one way I could do this would be to match with the prefix list
|
|
0:25:05
|
that says, "Look at the prefix length in addition to the address."
|
|
0:25:12
|
For example, of router 1, I would say, IP Prefix List
|
|
0:25:15
|
the loopback's subnets.
|
|
0:25:18
|
Start with the address 150.28.0.0.
|
|
0:25:23
|
I wanna match the first 16 bits,
|
|
0:25:27
|
and I know that all of the subnets are exactly /24.
|
|
0:25:32
|
So, I'll say, the subnet mask is greater than or equal to 24, but at the same time,
|
|
0:25:36
|
it's less than or equal to 24.
|
|
0:25:42
|
Permit that particular address.
|
|
0:25:48
|
So, it's matching not only on the number of bits in the address. It's saying, "Match the first 16 bits of 150.28.0.0/24,
|
|
0:25:56
|
but the, the subnet mask has to be exactly /24."
|
|
0:26:01
|
This is what I'm going to deny
|
|
0:26:03
|
from being advertised from router 4 and router 6.
|
|
0:26:09
|
When you're doing this here,
|
|
0:26:11
|
it's very important to keep the permit or deny logic clear
|
|
0:26:15
|
so you do not end up in a double negative.
|
|
0:26:18
|
And the way to do this,
|
|
0:26:19
|
whenever you're using an access list or a prefix list,
|
|
0:26:23
|
the access list or prefix list should always say permit
|
|
0:26:26
|
in order to match the routes.
|
|
0:26:30
|
Then, the route map is either actually going to permit or deny the prefix
|
|
0:26:34
|
based on its permit or deny logic.
|
|
0:26:38
|
So again, the access list or a prefix list is used just to match
|
|
0:26:42
|
whether we are allowing or filtering the prefix is gonna be based on the route map's logic.
|
|
0:26:48
|
So now, I have the prefixes matched.
|
|
0:26:51
|
I'll say, Route Map to...
|
|
0:26:54
|
iBGP.
|
|
0:26:55
|
Deny 10.
|
|
0:26:58
|
Match IP Address. Prefix List, the loopback's subnets.
|
|
0:27:08
|
If the prefixes are not the loopback subnets, I'm simply gonna permit them.
|
|
0:27:14
|
If I did not add the last statement here,
|
|
0:27:16
|
the route map is then going to deny everything,
|
|
0:27:18
|
because just like in access list or a prefix list, it does have an implicit deny.
|
|
0:27:24
|
The way I could verify this on router 1
|
|
0:27:26
|
would be to look at the Show IP BGP Neighbor Advertised Routes,
|
|
0:27:30
|
or go to router 4 and router 6 and see what they are learning inbound from router 1.
|
|
0:27:42
|
Now that I have the route map, I'm gonna apply it to the neighbor. So, under BGP 100,
|
|
0:27:47
|
Specify neighbor, 150.28.4.4.
|
|
0:27:52
|
The route map_iBGP out.
|
|
0:27:56
|
Same on router 6.
|
|
0:28:03
|
Now, on router 4 and 6, I'm gonna look at the Debug IP BGP Updates.
|
|
0:28:09
|
What I should see one router 1 once I apply the new policy,
|
|
0:28:14
|
it should send a withdraw message to 4 and 6
|
|
0:28:18
|
that says, I'm no longer advertising these particular subnets to you.
|
|
0:28:22
|
So, on router 1, if I say, Clear IP BGP 100 out,
|
|
0:28:25
|
which is gonna send them a new triggered update with route refresh,
|
|
0:28:33
|
On router 4, let's look at the Show Log.
|
|
0:28:39
|
And console logging was disabled.
|
|
0:28:43
|
So, actually, I need to re-enable it to everyone.
|
|
0:28:50
|
Let's say, Logging Console Level 7.
|
|
0:29:04
|
We can see now on router 4, we are receiving from the backbone routers
|
|
0:29:09
|
withdraw message about those individual subnets.
|
|
0:29:12
|
This essentially means that router 1
|
|
0:29:16
|
withdrew the update from 6,
|
|
0:29:19
|
6 withdrew it to BB1,
|
|
0:29:22
|
BB1 is then withdrawing it to BB3,
|
|
0:29:24
|
BB3 is withdrawing it to router 4.
|
|
0:29:28
|
Now, we know router 4 would never listen to this update to begin with
|
|
0:29:31
|
because it has its own autonomous system in the path,
|
|
0:29:34
|
but technically, the path is still gonna be withdrawn in an advertisement between them.
|
|
0:29:40
|
If we look at the result of this and go to...
|
|
0:29:43
|
router 4 or router 6 and look at the Show IP BGP.
|
|
0:29:47
|
We should see now, we're learning the /20 aggregate,
|
|
0:29:52
|
but we're not learning the individual subnets that are coming in from router 1.
|
|
0:29:59
|
Now, we see that we're still learning the subnets from the other neighbors,
|
|
0:30:02
|
which we couldn't prevent this from router 1's perspective.
|
|
0:30:06
|
If I wanted router 4 not to learn this inbound,
|
|
0:30:09
|
or more specifically not to advertise this outbound,
|
|
0:30:13
|
it would actually make a little bit more sense in this design to apply the filter on router 4 and router 6.
|
|
0:30:21
|
But if we were to look at router 1,
|
|
0:30:23
|
and look at what we're advertising out,
|
|
0:30:25
|
Show IP BGP Neighbor 150.28.6.6 advertised routes.
|
|
0:30:32
|
We see that were advertising them just that /20.
|
|
0:30:37
|
Now, on the other way around, if I were to look at what I'm advertising to router 5,
|
|
0:30:47
|
we can see router 1 is still advertising the individual subnet,
|
|
0:30:52
|
the 1.0, the 4.0, and the 6.0,
|
|
0:30:56
|
which means that these devices now would have exact matches to those routes.
|
|
0:31:00
|
And we should be able to reach now router 1,
|
|
0:31:05
|
or router 4, and router 6.
|
|
0:31:13
|
So, the key point about this is that when you're doing the aggregation,
|
|
0:31:17
|
you have to look at the overall topology to figure out how is the router making its decision
|
|
0:31:21
|
either based on the individual subnet route,
|
|
0:31:23
|
or now, the less specific aggregate.
|
|
0:31:27
|
If there's multiple devices that are originating the aggregate,
|
|
0:31:30
|
it means that they are going to
|
|
0:31:32
|
collect the traffic for the shorter match.
|
|
0:31:35
|
Then, depending or not whether they have the longer match,
|
|
0:31:39
|
the traffic could be forwarded, or the traffic could be dropped.
|
|
0:31:44
|
If we look at router 2 and look at the Show IP Route BGP,
|
|
0:31:50
|
we see that similar to EIGRP's summarization, or OSPF's summarization,
|
|
0:31:57
|
when we're originating the aggregate in BGP,
|
|
0:32:00
|
it does automatically include the discard route.
|
|
0:32:03
|
This means that from router 2's perspective,
|
|
0:32:06
|
if it does not have a longer match to anything inside the /20,
|
|
0:32:12
|
the packets are gonna be dropped.
|
|
0:32:16
|
This would also imply that router 2 would not be able to use a default route
|
|
0:32:21
|
in order to reach any of the subnets that are inside of the aggregate.
|
|
0:32:28
|
So, for example on router 2, if we have a default route
|
|
0:32:32
|
that says, "To go out towards...
|
|
0:32:35
|
BB2 via 192.10.28.254."
|
|
0:32:41
|
If router 2 receives any packets that are inside that /20,
|
|
0:32:45
|
since /20 is a longer match thant /0,
|
|
0:32:49
|
we would not be able to use the default in order to reach any of those subnets.
|
|
0:32:55
|
Most of the time, that would be the ideal case,
|
|
0:32:58
|
because if you're generating the aggregate,
|
|
0:32:59
|
generally, you would have the more specific matches to begin with.
|
|
0:33:03
|
It really depends on the design of the routing policy.
|
|
0:33:07
|
We could technically prevent this though
|
|
0:33:10
|
by filtering out the route to null zero.
|
|
0:33:13
|
The way that we could do this
|
|
0:33:16
|
under the BGP process
|
|
0:33:19
|
is with a BGP table map.
|
|
0:33:23
|
And the table map essentially controls
|
|
0:33:27
|
what particular routes that are best routes in the BGP table
|
|
0:33:31
|
actually get installed in the routing table.
|
|
0:33:37
|
So, if there's very some specific case where you want the routes still to be a best route,
|
|
0:33:41
|
but not make it into the local routing table,
|
|
0:33:44
|
we could technically filter it out with the table map.
|
|
0:33:50
|
So then, on router 2, I could match the exact prefix 150.28.0.0/20.
|
|
0:33:55
|
Permit this in a prefix list.
|
|
0:33:59
|
Deny it in the route map.
|
|
0:34:01
|
Then, have a second permit statement in the route map,
|
|
0:34:04
|
and then, apply it on to the process as a table map.
|
|
0:34:10
|
So, we'll see with a lot of these implementations in BGP,
|
|
0:34:13
|
there may be literally a hundred different ways that we could solve the same problem.
|
|
0:34:16
|
As long as we end up in the same result, that's really what we care about.
|
|
0:34:21
|
But BGP gives us a lot of its flexibility,
|
|
0:34:23
|
because there may be cases where takes less configuration
|
|
0:34:26
|
to do it one way versus another way
|
|
0:34:29
|
depending on how many prefixes, or how many particular peers that we're dealing with.
|
|
0:34:38
|
So, let's say, on router 1, we don't wanna do the configuration this way with the manual filter.
|
|
0:34:43
|
The way I solve the problem now is that I generated the aggregate
|
|
0:34:47
|
just with the...
|
|
0:34:50
|
Standard Aggregate Address command.
|
|
0:34:53
|
So, this means I'm generating the summary,
|
|
0:34:55
|
plus I'm advertising the subnets.
|
|
0:34:58
|
Then, for the particular neighbors that were router 4 and router 6,
|
|
0:35:01
|
I was filtering out the subnets
|
|
0:35:06
|
by specifying in the route map,
|
|
0:35:08
|
"Match anything that starts with 150.28
|
|
0:35:12
|
that has a subnet mask of 24."
|
|
0:35:14
|
And then, those prefixes were denied.
|
|
0:35:19
|
The problem is if there's a lot of internal peers that I want to apply this filtering on to,
|
|
0:35:25
|
it could be a lot of configuration and just a lot of maintenance to do in the configuration.
|
|
0:35:30
|
So, if I wanna make a change on the policy,
|
|
0:35:32
|
maybe I'm gonna have to update a hundred different internal peers.
|
|
0:35:37
|
So, in the case where there are less peers that you want to send the subnets,
|
|
0:35:43
|
then, you do want to send the aggregate,
|
|
0:35:46
|
then, we could use the unsuppressed map,
|
|
0:35:49
|
which is the opposite of either the summary only, or the suppress map.
|
|
0:35:57
|
So, on router 1, under the BGP process,
|
|
0:36:00
|
let's remove these route maps that are applied on to router 4,
|
|
0:36:05
|
and to router 6.
|
|
0:36:11
|
Now, if we say Clear IP BGP AS 100 Out,
|
|
0:36:18
|
on router 4, we can see from Debug IP BGP Updates.
|
|
0:36:22
|
Now, we're receiving the new subnets being advertised in.
|
|
0:36:27
|
So, if we were to scroll up here, we could see from router 1,
|
|
0:36:30
|
we receive the prefix 150.28.1.0/24 and the 6.0/24.
|
|
0:36:36
|
So now, these prefixes are no longer being filtered.
|
|
0:36:41
|
Next, on router 1, I'm gonna change the aggregate address.
|
|
0:36:46
|
So that it's using the summary only.
|
|
0:36:52
|
Another option would be to match a suppress map,
|
|
0:36:56
|
which is a route map that matches which prefixes we do not want to advertise.
|
|
0:37:04
|
If we were to have a suppress map that matches everything,
|
|
0:37:08
|
that's effectively the same thing as doing summary only.
|
|
0:37:13
|
So again, we have either option here, it just depends on how many prefixes we're dealing with.
|
|
0:37:17
|
If there's less prefixes we want to suppress,
|
|
0:37:20
|
it would make more sense to use the suppress map
|
|
0:37:22
|
as opposed to the unsuppressed map on a per-neighbor basis.
|
|
0:37:27
|
But if there are less prefixes we want to unsuppress,
|
|
0:37:30
|
then, we have the option to do it that way as well.
|
|
0:37:34
|
So, the end result is gonna be the same just depends on the individual steps we use in order to get there.
|
|
0:37:41
|
So now, on router 4,
|
|
0:37:44
|
we should see that there's a new withdraw message
|
|
0:37:46
|
that's gonna come from router 1.
|
|
0:37:49
|
So, on router 1, I'll say, Clear IP BGP 100 Out.
|
|
0:37:54
|
Router 4 should now get the withdraw message about its own loopback.
|
|
0:38:02
|
And if we Show IP BGP,
|
|
0:38:09
|
we see, the individual subnets are no longer learned from router 1.
|
|
0:38:13
|
So, we don't have the 1.0, the 4.0, or the 6.0.
|
|
0:38:18
|
This is because on router 1, when we look at the Show IP BGP,
|
|
0:38:23
|
we see that all the subnets are now being suppressed.
|
|
0:38:26
|
They have the lower case s.
|
|
0:38:31
|
Again, once I'm doing this, when we look at the actual advertisements in the network,
|
|
0:38:35
|
router 1 is advertising the /20
|
|
0:38:40
|
as is router 2.
|
|
0:38:43
|
So, depending on which one is actually chosen.
|
|
0:38:46
|
Some of the destinations are gonna be reachable,
|
|
0:38:48
|
some of them are not.
|
|
0:38:52
|
So now, what I wanna do on router 1
|
|
0:38:55
|
is on a per-neighbor basis,
|
|
0:38:58
|
say that out to router 3,
|
|
0:39:00
|
and out to router 5,
|
|
0:39:02
|
I want to advertise the specific subnets, 150.28.1.0/24.
|
|
0:39:13
|
6.0 and 4.0/24.
|
|
0:39:20
|
And I'm going to apply this separately on to router 3 and on to router 5.
|
|
0:39:24
|
So, use a separate route map that's going just to router 3,
|
|
0:39:26
|
a separate route map that's going just to router 5.
|
|
0:39:33
|
So, the first thing I need to do is match the particular prefixes.
|
|
0:39:37
|
I could do this on one prefix list,
|
|
0:39:40
|
or I could do it in separate prefix list.
|
|
0:39:42
|
It depends on how modular I want to make the configuration.
|
|
0:39:45
|
In this particular case, I'm gonna do it in three separate ones.
|
|
0:39:48
|
To make the configuration a little bit clear to read.
|
|
0:39:52
|
I'll say, IP Prefix List Router 1 Loopback.
|
|
0:39:57
|
Permit 150.28.1.0/24.
|
|
0:40:02
|
I'll then have router 4's loopback.
|
|
0:40:06
|
And router...
|
|
0:40:08
|
6's loopback.
|
|
0:40:14
|
So, three separate lists matching the three individual loopbacks.
|
|
0:40:20
|
Now, I'll have two separate route maps. One of them is gonna be an unsuppressed
|
|
0:40:25
|
map that is going to router 3.
|
|
0:40:30
|
Now, what I'm permitting here
|
|
0:40:33
|
is the subnets that are inside the aggregate that already suppressed.
|
|
0:40:38
|
It means that selectively, I'm going to advertise them to that individual peer.
|
|
0:40:45
|
Specifically to router 3, I'm going to...
|
|
0:40:49
|
Match IP Address Prefix List Router 1's Loopback.
|
|
0:40:57
|
A second statement that matches 4's loopback.
|
|
0:41:03
|
And a third statement that matches 6's loopback.
|
|
0:41:08
|
So essentially, all three of them are being unsuppressed.
|
|
0:41:14
|
Then, I'm gonna have a second route map that's going out to router 5.
|
|
0:41:19
|
Unsuppressed to router 5.
|
|
0:41:22
|
But in this one, I'm gonna match just...
|
|
0:41:27
|
the loopback of router 1.
|
|
0:41:31
|
So, I'm not mentioning 4's, and I'm not mentioning 6's.
|
|
0:41:35
|
Now, the end result of this, once we apply this on to the neighbors,
|
|
0:41:39
|
so, out to router 3, neighbor 155.28.13.3,
|
|
0:41:45
|
we have the unsuppressed map that is unsuppressed to router 3.
|
|
0:41:51
|
Then, out to 155.28.0.5,
|
|
0:41:55
|
unsuppress map, unsuppresed to router 5.
|
|
0:42:00
|
If we apply the new policy, so, we'll say, Clear IP BGP Star (*) Out,
|
|
0:42:04
|
then, look at the Show IP BGP Neighbor 155.28.13.3 advertised routes,
|
|
0:42:12
|
and compare this to what we're advertising to router 5,
|
|
0:42:16
|
we should see that we're advertising the /20.
|
|
0:42:20
|
So, this is not affecting the aggregate at all.
|
|
0:42:22
|
The difference is that we're choosing different subnets
|
|
0:42:26
|
to advertise to router 5 versus...
|
|
0:42:31
|
router 3.
|
|
0:42:36
|
The end result of this
|
|
0:42:39
|
is that it's going to affect the traffic flow.
|
|
0:42:42
|
Because now, router 1 is saying out to router 3,
|
|
0:42:45
|
"I'm advertising these specific routes for 1, 4, and 6.
|
|
0:42:50
|
Out to router 5, I'm advertising just the specific route for 1."
|
|
0:42:57
|
This now means from router 5's perspective,
|
|
0:43:00
|
when traffic is going to either router 4 or router 6,
|
|
0:43:05
|
it's gonna have to go through AS 300 first
|
|
0:43:08
|
before it gets to the final destination.
|
|
0:43:11
|
And the reason why is that simply, we're choosing the longer match to /24 as opposed to /20.
|
|
0:43:21
|
If we were to go to switch 4 and actually test this based on a traceroute,
|
|
0:43:25
|
we'll trace 150.28.1.1.
|
|
0:43:33
|
We'll source this...
|
|
0:43:36
|
and the switch, this switch need an extended traceroute. So, we'll say, Trace...
|
|
0:43:42
|
150.28.1.1.
|
|
0:43:45
|
Source is 150.28.10.10. So, it's my local loopback.
|
|
0:43:53
|
We see, from router 5, this is going directly to router 1.
|
|
0:43:56
|
This is because router 1 is directly advertising that specific subnet.
|
|
0:44:02
|
If we were to do the trace that goes either
|
|
0:44:04
|
to router 4,
|
|
0:44:07
|
or router 6's loopback,
|
|
0:44:11
|
since the specific is not being learned on the peering between router 1 and router 5,
|
|
0:44:17
|
the traffic has to be re-routed over to router 3.
|
|
0:44:25
|
So, the key point here with the aggregation,
|
|
0:44:28
|
it can be used not only for advertising the less specific matches.
|
|
0:44:34
|
So, in this case, we were advertising the /20 as opposed to the /24.
|
|
0:44:38
|
But we can also use it for traffic engineering based on the longest match principle.
|
|
0:44:43
|
If we are sending subnets to some neighbors,
|
|
0:44:48
|
and only the aggregate to others,
|
|
0:44:51
|
it means that when the traffic is returned inbound,
|
|
0:44:55
|
the remote neighbors would prefer the longer matches to the subnets
|
|
0:45:00
|
versus the shorter match to the aggregate.
|
|
0:45:05
|
Now, ultimately, as long as the aggregate is the correct route to any of these destinations,
|
|
0:45:10
|
then, if the subnet routes are withdrawn,
|
|
0:45:13
|
it would mean we would fall back to the shorter match.
|
|
0:45:17
|
So, let's assume for example that router 2 is not generating the aggregate at all.
|
|
0:45:22
|
So, we don't have a problem with the overlapping routes.
|
|
0:45:25
|
If router 1 is advertising this way, the /20 plus the /24's,
|
|
0:45:31
|
then, to router 5, we're advertising just the /20's,
|
|
0:45:35
|
it means that any traffic going to those subnets
|
|
0:45:38
|
is gonna be routed in that direction. Through router 3 first.
|
|
0:45:44
|
If the link between 1 and 3 goes down,
|
|
0:45:47
|
we should still be able to re-route to the shorter match via router 5.
|
|
0:45:53
|
So, it's still giving us redundancy in the network if one of the paths is down,
|
|
0:45:58
|
but based on the longest match routing principle,
|
|
0:46:00
|
we're forcing the inbound traffic flow
|
|
0:46:04
|
to go between router 1 and router 3.
|
