|
0:00:13
|
In our next section for BGP,
|
|
0:00:16
|
we're gonna talk about how route reflection works
|
|
0:00:18
|
as an alternative to using a full mesh between all of these IBGP peers,
|
|
0:00:23
|
and some of the advanced designs that come along with the route reflection configuration.
|
|
0:00:30
|
Now, the overall principle of route reflection can be...
|
|
0:00:33
|
a though of it, similar to the OSPF designated router, or...
|
|
0:00:36
|
the IS-IS designated intermediate system,
|
|
0:00:39
|
where we have some sort of centralized device
|
|
0:00:42
|
that is used to minimize the amount of control plane routing information that's sent throughout the network.
|
|
0:00:48
|
So, with the previous example using a full mesh of IBGP peers,
|
|
0:00:52
|
it's not only a lot of administrative overhead to maintain all the peerings,
|
|
0:00:57
|
but it's a lot of control plane information that a lot of router needs to process
|
|
0:01:01
|
as it's sending the duplicate updates out to all of the peers in the network.
|
|
0:01:05
|
So, with route reflection, we can centralize the peering arrangements
|
|
0:01:10
|
so that the clients are sending one copy of their routing updates to the route reflector,
|
|
0:01:16
|
then, the route reflector can turn around and send it down to...
|
|
0:01:18
|
all of the other IBGP neighbors in the network.
|
|
0:01:22
|
We'll see that in certain designs, the network can have more than one router reflector
|
|
0:01:26
|
that is either servicing the same set of clients,
|
|
0:01:30
|
or servicing different servicing of clients.
|
|
0:01:32
|
It really depends on what our redundancy goals are,
|
|
0:01:35
|
and what is the physical topology of the network.
|
|
0:01:39
|
Now, since we're breaking the previously defined loop prevention mechanism of iBGP,
|
|
0:01:45
|
where by default, it says that if you learn a route from an iBGP neighbor,
|
|
0:01:48
|
you're not allowed to advertise it to other iBGP neighbors.
|
|
0:01:52
|
We need to implement an additional loop prevention mechanism with route reflection.
|
|
0:01:57
|
And this comes in the form of the cluster identifier, or the cluster ID.
|
|
0:02:02
|
Now, the route reflector, when it receives an update from a client,
|
|
0:02:05
|
and passes it on to another client, or to another normal iBGP peer,
|
|
0:02:10
|
the route reflector's router ID,
|
|
0:02:13
|
which is then known as the cluster ID...
|
|
0:02:16
|
is gonna get added to the update in the clustered list.
|
|
0:02:21
|
Now, if it so happens that the route reflector sends the route out,
|
|
0:02:24
|
and somehow, the update gets passed back in,
|
|
0:02:28
|
when the route reflector receives an update with its own cluster identifier in the clustered list,
|
|
0:02:34
|
it's gonna automatically filter those updates out.
|
|
0:02:37
|
So, we'll see, there can be certain designs where route reflectors are peering with each other,
|
|
0:02:42
|
and the routing advertisements do loop through the network,
|
|
0:02:45
|
but ultimately, it will be automatically be filtered out
|
|
0:02:48
|
based on the cluster identifier being automatically included.
|
|
0:02:54
|
We'll also see that the other attributes of the update,
|
|
0:02:56
|
like the next hop value, the AS path, the local preference,
|
|
0:03:00
|
those are normally not going to be modified
|
|
0:03:02
|
by the route reflector.
|
|
0:03:05
|
This means like the example we saw previously,
|
|
0:03:08
|
where the edge routers were reporting the external next hop values into the iBGP network,
|
|
0:03:14
|
we would have the same type of design issue if we were to use route reflection.
|
|
0:03:18
|
That the neighbors internal to the iBGP network,
|
|
0:03:22
|
they would need to know the transit links between the edge routers and the remote EBGP peers
|
|
0:03:27
|
since the next hop values are not automatically changed
|
|
0:03:30
|
when we're advertising EBGP learned routes to out iBGP neighbors.
|
|
0:03:36
|
Again, the route reflector is gonna do the same thing
|
|
0:03:39
|
when it's receiving a route from an EBGP peer,
|
|
0:03:42
|
or it's receiving a route from an iBGP peer,
|
|
0:03:44
|
the next hop value is not going to be modified
|
|
0:03:47
|
as it is sent to other iBGP peers.
|
|
0:03:51
|
The only case that the next hop value is modified automatically
|
|
0:03:55
|
is anytime that we're advertising updates through EBGP peers.
|
|
0:04:00
|
So, in the case of a true EBGP peer, it means someone who is actually in a different autonomous system.
|
|
0:04:05
|
Not someone who's part of our confederation, but in a different sub-AS.
|
|
0:04:10
|
So, we'll see, when we look at our confederation configurations,
|
|
0:04:13
|
even the inter-sub-AS communication does not automatically do the next hop modification.
|
|
0:04:21
|
Now, from the route reflector's perspective,
|
|
0:04:24
|
we have three different types of peers:
|
|
0:04:27
|
we have normal EBGP peers,
|
|
0:04:30
|
which are routers that are in a different autonomous system than us locally,
|
|
0:04:34
|
client peers,
|
|
0:04:36
|
which are devices that have the route reflector client statement configured on
|
|
0:04:40
|
to their neighbor command,
|
|
0:04:42
|
and non-client peers,
|
|
0:04:44
|
who are regular iBGP neighbors
|
|
0:04:46
|
without the route reflector client statement configured on.
|
|
0:04:50
|
The reason that it is significant to separate the peers into these three different roles
|
|
0:04:56
|
is that the route reflector is gonna treat routing updates differently
|
|
0:05:00
|
depending on where the update is coming from and where the update is going to.
|
|
0:05:06
|
So, we have these three rules...
|
|
0:05:08
|
for the type of advertisements.
|
|
0:05:11
|
When the route reflector is learning a route from an EBGP neighbor,
|
|
0:05:15
|
those routes can be advertised to other EBGP neighbors,
|
|
0:05:19
|
any client peers, and any non-client peers.
|
|
0:05:24
|
When the route is coming from a client,
|
|
0:05:27
|
likewise, it can be advertised to EBGP peers, client peers, and non-client peers.
|
|
0:05:34
|
The only restriction of the route reflector
|
|
0:05:36
|
is that when an update is received from a non-client peer,
|
|
0:05:40
|
the route may be reflected to an EBGP peer and a client peer,
|
|
0:05:45
|
but not to other non-clients.
|
|
0:05:50
|
Now, the typical design case where we would see this
|
|
0:05:52
|
is that different route reflectors, when they're peering with each other,
|
|
0:05:57
|
typically, they are not clients of each other.
|
|
0:06:00
|
So, when we look at some larger scale designs with using multiple route reflectors
|
|
0:06:05
|
between the multiple clusters,
|
|
0:06:06
|
there are some cases where the inter-cluster communication will be non-client peerings
|
|
0:06:12
|
in order to reduce the amount of control plane updates that are replicated between the route reflectors.
|
|
0:06:20
|
So, in reality, there's only one point that you need to remember about this;
|
|
0:06:24
|
that the route reflector will no advertise routes between two non-client peers.
|
|
0:06:29
|
Or any other combination, it's gonna be valid.
|
|
0:06:31
|
From EBGP, to clients and non-clients,
|
|
0:06:34
|
from clients to EBGP and non-clients,
|
|
0:06:37
|
but not from a non-client to a non-client.
|
|
0:06:42
|
So, effectively, these three rules are going to affect the placement of the route reflector in the network.
|
|
0:06:48
|
And what different types of peerings that we are going to configure.
|
|
0:06:54
|
Now, we'll see, once we get pass out basic examples with route reflection,
|
|
0:06:59
|
there can be designs that there are multiple route reflectors inside the same autonomous system
|
|
0:07:04
|
in order to avoid single points of failure.
|
|
0:07:09
|
So, just like in the designated router election,
|
|
0:07:12
|
or the designated intermediate system election,
|
|
0:07:15
|
if that centralized device goes down, and that is in-charged of the updates,
|
|
0:07:18
|
if no other device takes that role on afterwards,
|
|
0:07:22
|
then, connectivity on our particular segment is gonna be lost.
|
|
0:07:27
|
In the case of BGP,
|
|
0:07:29
|
if there's only a single route reflector in the iBGP network, and it goes down,
|
|
0:07:33
|
it means that connectivity is gonna be lost everywhere to all BGP destinations.
|
|
0:07:39
|
So, in the vast majority of designs, we don't use only one single route reflector
|
|
0:07:43
|
to try to get more redundancy in case of one of them goes down.
|
|
0:07:48
|
Now, in order to do this, we need to make sure that we can maintain
|
|
0:07:51
|
the loop prevention mechanism between the route reflectors,
|
|
0:07:55
|
and effectively prevent the case where the routing updates are looping infinitely between the neighbors.
|
|
0:08:01
|
So, we'll see, the way that we can do this
|
|
0:08:04
|
by manually specifying the cluster identifier
|
|
0:08:07
|
between multiple route reflectors that are servicing the same clients,
|
|
0:08:11
|
and the different peering designs that we can have for the inter-cluster peerings
|
|
0:08:17
|
to get more redundancy
|
|
0:08:20
|
versus less redundancy
|
|
0:08:23
|
depending on how many updates that we want to send in the network.
|
|
0:08:27
|
So again, the difference between these designs whether we're doing a full mesh,
|
|
0:08:31
|
or whether we're doing a route reflection, or we're doing confederation
|
|
0:08:34
|
is the trade-off between the amount of updates to send
|
|
0:08:38
|
versus the diversity of paths in the network.
|
|
0:08:42
|
So, anytime that we are filtering the number of possible routes,
|
|
0:08:45
|
it means that the routers are making a less intelligent decision
|
|
0:08:48
|
about the potential exit points out of the network.
|
|
0:08:53
|
Now, we'll see, one of the potential problems with this
|
|
0:08:56
|
is that route reflector just like any other normal router in the BGP network
|
|
0:09:01
|
is generally only going to be selecting one best path on a per-route basis.
|
|
0:09:08
|
So, it's gonna go to the best path selection process for all of the routes that it learns,
|
|
0:09:12
|
look at things like the local preference, the AS path, the med, the origin code,
|
|
0:09:17
|
and figure out which is the actual active route that it's gonna use.
|
|
0:09:22
|
The end result of this best path selection is then gonna control
|
|
0:09:25
|
what routes can be installed in the routing table,
|
|
0:09:28
|
and what routes can be advertised.
|
|
0:09:31
|
So, the route reflector, just like any other peer
|
|
0:09:34
|
is only allowed to advertise its best path.
|
|
0:09:38
|
This means that different clients of the route reflector are going to have different views of the topology
|
|
0:09:44
|
depending on how the route reflector in their cluster
|
|
0:09:47
|
is making its individual best path selection.
|
|
0:09:51
|
However, if we were to set up the network in a full mesh of peerings,
|
|
0:09:54
|
then, every single route would know about every single path in the iBGP network.
|
|
0:10:00
|
So again, it's always a give and take between how many diverse paths do we have to choose from
|
|
0:10:05
|
versus the amount of overhead in the control plane
|
|
0:10:08
|
for actually sending the updates and then running the best path selection algorithm.
|
|
0:10:15
|
So, the topology we're gonna use for these examples
|
|
0:10:18
|
is pretty similar to the one that we did before
|
|
0:10:20
|
with the exception that router 2 is now in AS 200,
|
|
0:10:25
|
and peering with the EBGP peer who is BB3.
|
|
0:10:32
|
So, we have three separate
|
|
0:10:34
|
external peerings to the backbone routers. We have between router 6 and BB1,
|
|
0:10:39
|
router 4 and BB3,
|
|
0:10:42
|
and router 4 and BB2 2.
|
|
0:10:45
|
Then, between AS 100 and 200, we have a peering between routers 2 and 3,
|
|
0:10:51
|
and a peering between router 2 and 5.
|
|
0:10:54
|
So, ultimately, our goal here whether we're doing a full mesh or route reflection, or confederation
|
|
0:11:01
|
is that we want to be able to learn routes from AS 54,
|
|
0:11:05
|
continue to advertise them through AS 100 out to 200,
|
|
0:11:10
|
and then, ultimately advertise them to 254.
|
|
0:11:14
|
So, if we're trying to provide transit services then, eventually, we should be able to receive traffic in from BB1
|
|
0:11:19
|
route it all the way down to router 2 and then have it leave the network.
|
|
0:11:28
|
So first, let's look at the design
|
|
0:11:30
|
where we're using a single route reflector in the network.
|
|
0:11:34
|
And we'll take one of the centralized points, which is going to be router 1.
|
|
0:11:39
|
So, router 1 is going to be the route reflector,
|
|
0:11:41
|
and essentially, all of the routers in AS 100 are going to be its clients.
|
|
0:11:48
|
So, similar to the previous configuration we did with the peer groups,
|
|
0:11:52
|
typically, the route reflector would use a peer group configuration,
|
|
0:11:57
|
because not only is it going to cut down on the administration of the actual commands,
|
|
0:12:01
|
but it's also an optimization of the update process itself.
|
|
0:12:07
|
The reason why is that all routers in the update group
|
|
0:12:10
|
need to share the same attribute policy.
|
|
0:12:14
|
This means that if a route map is applied out to one neighbor in the peer group,
|
|
0:12:18
|
that identical route map needs to apply to all of the neighbors.
|
|
0:12:23
|
Now, since all of the peers are gonna have the same outbound policy,
|
|
0:12:27
|
it means that the route reflector or whoever has the peer group configured
|
|
0:12:31
|
only needs to make one decision that is going to apply on to all of them.
|
|
0:12:36
|
From the route reflector's perspective, if these neighbors were not in the peer group,
|
|
0:12:41
|
it would mean that for every peering it has,
|
|
0:12:44
|
which in this case, we have 1, 2, 3, 4, 5, 6, 7, 8,
|
|
0:12:49
|
the BGP process would have to make 8 separate independent update decisions
|
|
0:12:55
|
to figure out what particular routes are supposed to go to this neighbor,
|
|
0:12:59
|
and then what particular policy needs to be applied.
|
|
0:13:03
|
So, when we look at this in an actual production design for larger scale route reflection,
|
|
0:13:08
|
especially when we're talking about the full global BGP table
|
|
0:13:11
|
with about 400,000 routes,
|
|
0:13:14
|
it can be very processor and memory intensive
|
|
0:13:16
|
for the route reflector to actually send the update messages down to the clients.
|
|
0:13:22
|
So, in the vast majority of cases, the clients in the cluster
|
|
0:13:26
|
would be part of a peer group on the route reflector.
|
|
0:13:29
|
So, just for efficiency, not necessarily just for the management of the configuration.
|
|
0:13:37
|
So, let's take a look at router 1,
|
|
0:13:41
|
and right now, under the...
|
|
0:13:44
|
the BGP configuration,
|
|
0:13:49
|
we essentially don't have anything configured. We simply have the AS 100 defined.
|
|
0:13:54
|
So, the first thing I'm gonna do is to find the peer group,
|
|
0:13:57
|
specify the peer group's attributes, which will be the remote AS number
|
|
0:14:02
|
that the devices in there are route reflector clients.
|
|
0:14:06
|
And I'll send all of my updates from the loopback zero address.
|
|
0:14:10
|
So, the neighbor statement that goes on all the other routers,
|
|
0:14:12
|
we can basically use the same exact template.
|
|
0:14:16
|
So, first on router 1, let's go to BGP 100.
|
|
0:14:20
|
And I'm going to specify the peer group.
|
|
0:14:23
|
So, we'll give it a name. We'll say Clients.
|
|
0:14:27
|
Define this as a peer group.
|
|
0:14:29
|
The attributes for the peer group clients
|
|
0:14:33
|
first will be that all of the devices are in the same autonomous system,
|
|
0:14:37
|
and they are all route reflector clients.
|
|
0:14:44
|
Then lastly, every update is gonna come from my loopback zero.
|
|
0:14:50
|
Then, the individual peers, which would be...
|
|
0:14:54
|
the loopback interface of router 3
|
|
0:14:56
|
is gonna be in the peer group clients.
|
|
0:15:02
|
Also router 4,
|
|
0:15:04
|
and then all the way through...
|
|
0:15:07
|
switch 4.
|
|
0:15:13
|
So, we could basically just take this same configuration and then change the...
|
|
0:15:18
|
addresses that we're using for the loopbacks.
|
|
0:15:21
|
This would be router 5, 6, 7, 8.9...
|
|
0:15:25
|
and 10.
|
|
0:15:28
|
So, you see, with the BGP configuration, a lot of this stuff is repetitive.
|
|
0:15:34
|
Once you understand the overall design goal that you're trying to accomplish is,
|
|
0:15:38
|
ideally, you're gonna know the vast majority of the syntax off the top of your head.
|
|
0:15:42
|
So, that way, you can quickly build the template of config,
|
|
0:15:47
|
and then, simply apply it on to all of the neighbors that...
|
|
0:15:52
|
that need those particular options.
|
|
0:15:54
|
Now, from the rest of the neighbors,
|
|
0:15:58
|
under BGP 100,
|
|
0:16:00
|
they are gonna be peering with the loopback of router 1
|
|
0:16:05
|
in AS 100.
|
|
0:16:09
|
And the update source...
|
|
0:16:12
|
will be loopback zero.
|
|
0:16:14
|
So, from their perspective as the clients,
|
|
0:16:18
|
they do not need any special configuration...
|
|
0:16:20
|
that specifies who the route reflector is.
|
|
0:16:25
|
Update Sources Loopback Zero.
|
|
0:16:30
|
Now, assuming that we already have underlying IGP reachability...
|
|
0:16:35
|
to the route reflector,
|
|
0:16:37
|
which we should because all of these...
|
|
0:16:40
|
transit links are right now advertised in the EIGRP,
|
|
0:16:43
|
then, we should not have any problems establishing the adjacencies with router 1.
|
|
0:16:49
|
Now, from router 1, if we look at the Show IP BGP Summary,
|
|
0:16:53
|
this is gonna tell us if we actually have those peerings up.
|
|
0:16:59
|
So, it says, "I have peers with router 3 through 6,
|
|
0:17:02
|
switch 1 through switch 4.
|
|
0:17:05
|
Some of these neighbors, I'm not learning any prefixes from. Some of them are learning...
|
|
0:17:09
|
3 routes, 10 routes, 3 routes, and 10 routes.
|
|
0:17:15
|
So, specifically, the routes that are coming from router 3 and 5,
|
|
0:17:20
|
these are the prefixes that are being learned from...
|
|
0:17:25
|
AS 254,
|
|
0:17:28
|
then, passed on the router 3 and 5.
|
|
0:17:32
|
Then, from 3 and 5 up to the route reflector.
|
|
0:17:37
|
Because remember, there are no limitations about receiving updates from an EBGP neighbor,
|
|
0:17:43
|
and then, passing them to an iBGP neighbor.
|
|
0:17:46
|
Which in this case, from...
|
|
0:17:51
|
2...
|
|
0:17:57
|
to 3, this is EBGP.
|
|
0:18:02
|
So, 2 to 3 is EBGP.
|
|
0:18:03
|
2 to 5 is EBGP.
|
|
0:18:06
|
Then, from 5 to 1 and from 3 to 1, these are iBGP peerings.
|
|
0:18:12
|
So, the filtering limitation only occurs when the route is learned from the iBGP neighbor.
|
|
0:18:18
|
Now, additionally, we have routes coming from the opposite side.
|
|
0:18:22
|
BB1 is sending routes to 6,
|
|
0:18:24
|
6 is sending them to 1.
|
|
0:18:26
|
BB3 is sending routes to 4,
|
|
0:18:28
|
4 is sending them to 1.
|
|
0:18:32
|
Now, essentially, we should see on router 1
|
|
0:18:35
|
that we have two separate sets of the identical prefixes.
|
|
0:18:39
|
One of these sets is coming from routers 4 and 6,
|
|
0:18:43
|
the second set is coming from routers 3 and 5.
|
|
0:18:47
|
So, we could group these into general categories, we could say that...
|
|
0:18:51
|
these different prefixes...
|
|
0:18:53
|
would be...
|
|
0:18:55
|
A1 and A2
|
|
0:18:59
|
that are coming from router 3 and 5,
|
|
0:19:03
|
then we have B1 and B2
|
|
0:19:06
|
that are coming from 4 and 6.
|
|
0:19:11
|
The reason that this is significant
|
|
0:19:13
|
is based on the separate groupings of prefixes.
|
|
0:19:16
|
Router 1 is gonna choose one best path
|
|
0:19:20
|
of the A1 versus the A2 routes.
|
|
0:19:23
|
Then, the B1 versus the B2 routes.
|
|
0:19:27
|
So, depending on router 1's decision,
|
|
0:19:29
|
if we were to go to switch 3,
|
|
0:19:32
|
we may see that switch 3 knows about routes B1 and A2,
|
|
0:19:37
|
but not about A1 and not about B2.
|
|
0:19:41
|
It ultimately depends on how router 1 does the best path selection.
|
|
0:19:44
|
But the key is that the other devices in the network that are not the route reflector,
|
|
0:19:49
|
they will not see all of the diverse exit paths out of the topology.
|
|
0:19:55
|
The reason that this could be a potential issue
|
|
0:19:58
|
is that we may have a shorter to go not through the route reflector,
|
|
0:20:03
|
but since the route reflector is the one making the decision
|
|
0:20:06
|
on the behalf of the rest of the network,
|
|
0:20:08
|
then, we're loosing that overall visibility information.
|
|
0:20:13
|
So, from a routing efficiency point of view, the best design is to use a full mesh.
|
|
0:20:18
|
The problem is full mesh, a lot of the times is not feasible based on...
|
|
0:20:21
|
the CPU and the memory resources of the network.
|
|
0:20:28
|
Now, if we look at the result of this, let's go to router 1.
|
|
0:20:31
|
And Show...
|
|
0:20:33
|
Show IP BGP.
|
|
0:20:37
|
We see that there's a bunch of prefixes being learned.
|
|
0:20:39
|
Some of them are coming directly from AS 54,
|
|
0:20:43
|
which we are peering with;
|
|
0:20:45
|
some of them are coming from AS 200,
|
|
0:20:49
|
which is router 2.
|
|
0:20:52
|
Now, we see that for the prefixes coming from AS 54,
|
|
0:20:55
|
none of these are listed as best paths,
|
|
0:20:59
|
which most likely is related to the fact that we don't have a route to these...
|
|
0:21:04
|
external next hops.
|
|
0:21:07
|
So, the same case that we saw before.
|
|
0:21:09
|
We would see now...
|
|
0:21:11
|
that when router 4 and router 6
|
|
0:21:13
|
are learning the routes from the EBGP neighbors,
|
|
0:21:17
|
and passing them in to the route reflector,
|
|
0:21:21
|
the next hop values are not gonna be updated.
|
|
0:21:23
|
So, unless router 1 has a route to BB1,
|
|
0:21:26
|
and router 1 has a route to BB3,
|
|
0:21:28
|
it's not able to consider those for best path selection.
|
|
0:21:33
|
Then, likewise, when router 2 sends the update to 3,
|
|
0:21:37
|
and 3 sends it to 1,
|
|
0:21:39
|
router 1 is gonna see the next hop value
|
|
0:21:42
|
as the serial 0/1 interface of router 2.
|
|
0:21:46
|
For the update that's going from 2 to 5, then, 5 to 1,
|
|
0:21:50
|
the next hop value should be the frame-relay interface of router 2.
|
|
0:21:56
|
Now, depending on router 1 actually has those next hops,
|
|
0:22:00
|
it will control which of them can even consider for the best path selection.
|
|
0:22:06
|
So, before we go any further, we would wanna solve any issues with these next hop reachability.
|
|
0:22:14
|
Now again, there's two possible choices we have
|
|
0:22:17
|
for fixing the next hop issue.
|
|
0:22:19
|
We could either give router 1...
|
|
0:22:21
|
a route to these segments.
|
|
0:22:25
|
So, we could simply advertise them into our IGP.
|
|
0:22:30
|
Or we could change the next hop value to something router 1 already knows.
|
|
0:22:36
|
Since 1 and 4, and 1 and 6 are already directly connected on this LAN segment,
|
|
0:22:43
|
we could say on router 1, "As I received updates from 6,
|
|
0:22:45
|
or I received updates from 4,
|
|
0:22:47
|
set them to be the next hops of the Ethernet."
|
|
0:22:51
|
Or from router 6 to 1, we could say, Next Hop Self.
|
|
0:22:54
|
From router 4 to 1, we could change the next hop with a route map.
|
|
0:22:59
|
So, it really doesn't matter which solution we choose
|
|
0:23:01
|
as long as the end result
|
|
0:23:03
|
is that router 1 does have a route
|
|
0:23:06
|
to whatever the next hop value of the prefix is.
|
|
0:23:10
|
So, for simplicity sake,
|
|
0:23:12
|
let's just go to the edge routers and we're gonna advertise these links into EIGRP.
|
|
0:23:16
|
So, on router 6, we'll say under EIGRP 100,
|
|
0:23:20
|
Network 54.
|
|
0:23:22
|
And I'll also say that this is a passive interface.
|
|
0:23:27
|
On router 4,
|
|
0:23:30
|
we'll say, Network 204.12.28.0.
|
|
0:23:35
|
And passive interface...
|
|
0:23:38
|
Fast Ethernet 0/0.
|
|
0:23:43
|
Now, from router 1's perspective, if we were to look at the Show IP BGP
|
|
0:23:48
|
for any of these longer matches, let's say 112.0.0.0.
|
|
0:23:52
|
we should see
|
|
0:23:55
|
that neither of these next hop values are going to be inaccessible.
|
|
0:24:01
|
Right now, we can see, it does know how to get to the 54 network,
|
|
0:24:05
|
it does not yet know how to get to the 204 network,
|
|
0:24:09
|
most likely, just due to the convergence time.
|
|
0:24:11
|
So, if we check this again, ideally, we should be able to have some metric value
|
|
0:24:15
|
towards that next hop, which we do,
|
|
0:24:19
|
These metrics that are listed here, these are the ones that are coming from IGP.
|
|
0:24:25
|
So, it means, from router 1's perspective, our metric in EIGRP
|
|
0:24:29
|
is lower if I were to go to router 4 versus to router 6.
|
|
0:24:34
|
So, it's the metric value to the next hop.
|
|
0:24:38
|
We'll see when we talk about the best path selection in detail,
|
|
0:24:41
|
this is used as essentially the cost to the edge router
|
|
0:24:46
|
to figure out what is the shortest internal path
|
|
0:24:48
|
in oder to get out of the network.
|
|
0:24:52
|
So, if everything else is equal in the attributes,
|
|
0:24:54
|
like the weight value, the local preference, the AS path,
|
|
0:24:58
|
then, generally, we are gonna take the shortest internal path out of the network.
|
|
0:25:03
|
And that's effectively what's happening here.
|
|
0:25:05
|
We can see that the best route...
|
|
0:25:07
|
is to go towards router 4
|
|
0:25:09
|
because router 4 has the lower metric value
|
|
0:25:12
|
to whatever the next hop is.
|
|
0:25:17
|
If we look at any of the routes that we're learning from AS 200,
|
|
0:25:21
|
let's say Show IP BGP 222.22.2.0,
|
|
0:25:29
|
router 1 says, "I have 2 possible paths to reach this.
|
|
0:25:35
|
One of them is coming from router 5.
|
|
0:25:39
|
The other one is coming from router 3."
|
|
0:25:43
|
Now, for whatever reason we're choosing...
|
|
0:25:46
|
the one via router 5 as the best path,
|
|
0:25:49
|
to actually figure out why that's happening, we'd have to go down the individual list.
|
|
0:25:57
|
So, what the end result of this is gonna be...
|
|
0:26:00
|
is that when router 1 sends the adveritsements from these IBGP neighbors to the other clients,
|
|
0:26:08
|
only the routes that are the best routes are gonna be included.
|
|
0:26:12
|
So, this path via router 4,
|
|
0:26:14
|
this path via router 5,
|
|
0:26:17
|
not the additional path through router 6, and not the additional path through router 3.
|
|
0:26:24
|
We should also see in general
|
|
0:26:26
|
that whatever decision router 1 is making about one of the AS 54 routes,
|
|
0:26:32
|
it should happen for all of the AS 54 routes.
|
|
0:26:36
|
Because all of the attributes are the same, we're not doing any modifications.
|
|
0:26:40
|
Then likewise, if we're choosing router 5 as the exit point for this AS 200 route,
|
|
0:26:45
|
it's likely that we're gonna use it for all of the AS 200 routes.
|
|
0:26:50
|
We could filter this down in the BGP table by looking at a regular expression
|
|
0:26:55
|
that matches the AS path.
|
|
0:26:56
|
I could say, look for anything that I am learning from AS 54,
|
|
0:27:03
|
which would be caret (^) 54 underscore (_).
|
|
0:27:08
|
If I wanted to say, look at from what I'm learning from AS 200,
|
|
0:27:11
|
this would be caret (^) 200 underscore (_),
|
|
0:27:15
|
because I'm looking for the sequence 200 as the first number in the AS path.
|
|
0:27:23
|
So, we could see for the AS 200 routes, we're always using
|
|
0:27:27
|
the frame-relay interface to router 2.
|
|
0:27:31
|
Which essentially means, this is the path via router 5.
|
|
0:27:35
|
Then the routes to AS 54, we're using the Ethernet link between router 3 and BB3.
|
|
0:27:43
|
Or excuse me, router 4 and BB3.
|
|
0:27:47
|
So, it means that the two best paths
|
|
0:27:50
|
are the one's coming from 4.
|
|
0:27:53
|
And the one's coming from 5.
|
|
0:27:59
|
Now, which we should be able to predict
|
|
0:28:01
|
is that from the rest of the BGP network's point of view,
|
|
0:28:05
|
switch 1, switch 3, switch 4 and switch 2
|
|
0:28:11
|
will not see alternate routes other than the one's coming from router 4 and from router 5.
|
|
0:28:18
|
Now, likewise, router 4
|
|
0:28:21
|
will not be seeing the routes from 6.
|
|
0:28:25
|
And router 5 will not be seeing the routes from 3.
|
|
0:28:30
|
Because if router 1 is saying, "My best path is through router 5."
|
|
0:28:34
|
it means that no other alternate path's can be advertised to router 5.
|
|
0:28:39
|
And likewise if router 1 says, "My best path is through router 4."
|
|
0:28:42
|
Then no other routes can be advertised through router 4 for those same prefixes.
|
|
0:28:48
|
So, it's actually dual functionality here.
|
|
0:28:50
|
One of the reasons why this happens
|
|
0:28:52
|
is taht it cuts down on the size of the BGP table.
|
|
0:28:55
|
That if I'm receiving the full feed of four hundred thousand routes from one peer,
|
|
0:28:59
|
I don't wanna have to advertise it all the other peers if I'm actually using that path.
|
|
0:29:05
|
The second issue would be loop prevention.
|
|
0:29:08
|
If routeer 1 is routing through router 4,
|
|
0:29:11
|
it doesn't make sense to advertise router 4 alternate paths
|
|
0:29:14
|
because we would want to avoid the case where 1 routes to 4 and then 4 routes back to 1.
|
|
0:29:22
|
Now, based on the case that 4 sends to route to 1 and 1 never advertises anything back,
|
|
0:29:28
|
that would implicitly prevent router 4 from using router 1 as a next hop for any destination.
|
|
0:29:39
|
So, let's look at the result of this in the BGP table.
|
|
0:29:43
|
Let's look at switch 1.
|
|
0:29:46
|
And at the Show IP BGP output.
|
|
0:29:52
|
As we can see for each of these destinations, switch 1 only sees one possible path.
|
|
0:29:57
|
We have the exit point via router 4.
|
|
0:30:02
|
And the exit point via router 5.
|
|
0:30:06
|
Now, at this point, I'm not actually advertising anything out to the backbone routers.
|
|
0:30:12
|
So, we're not gonna be able to reach any of these.
|
|
0:30:15
|
We can get the traffic to the edge router but then it cannot go beyond that.
|
|
0:30:22
|
So, to fix this, I'm simply gonna go to the edge routers, which are 4, 6 and 2
|
|
0:30:31
|
and then advertise an aggregate of the internal space.
|
|
0:30:36
|
So, as long as we have some route,
|
|
0:30:39
|
one of the subnets that's in the BGP table,
|
|
0:30:42
|
we should be allowed to generate the aggregate.
|
|
0:30:45
|
Now, one quick way I could do this,
|
|
0:30:47
|
would be to simply go to the BGP process.
|
|
0:30:50
|
Say Redistribute Connected.
|
|
0:30:55
|
And then generate the aggregate.
|
|
0:30:58
|
Aggregate address 155.28.0.0
|
|
0:31:01
|
A mask of /16.
|
|
0:31:06
|
this would be on both router 4 and on router 6.
|
|
0:31:20
|
Then router 2 is gonna do the same thing but his would be for...
|
|
0:31:25
|
AS 200.
|
|
0:31:28
|
So, router BGP 200.
|
|
0:31:33
|
Redistribute Connected. And then do the aggregation.
|
|
0:31:39
|
Now, the subnets of the aggregate, it doesn't really matter how they get into the BGP table.
|
|
0:31:44
|
They could be there through the network statement.
|
|
0:31:45
|
They could be there through redistribution.
|
|
0:31:47
|
As long as there one subnet of 155.28,
|
|
0:31:50
|
it's gonna allow us to generate the summary.
|
|
0:31:54
|
So, on router 2, if we look at Show IP BGP,
|
|
0:31:57
|
we should see that locally originated,
|
|
0:32:00
|
we have the...
|
|
0:32:08
|
summary here, which is 155.28.0.0
|
|
0:32:11
|
Now, we could also filter this output to look at router 2's locally generated routes
|
|
0:32:17
|
by sasying Show IP BGP regular expression caret(^) dollar sign($)
|
|
0:32:22
|
This would look for the empty AS set.
|
|
0:32:26
|
Which means that all of these paths are locally originated inside my AS.
|
|
0:32:35
|
So, if the AS path information is empty,
|
|
0:32:36
|
it means that it's not going through other EBGP neighbors.
|
|
0:32:45
|
So, once these prefixes are advertised, we should see
|
|
0:32:49
|
that for any of these destinations, we're able to reach them.
|
|
0:32:52
|
So, if we trace to 112.0.0.1,
|
|
0:32:56
|
we see that the traffic goes to AS 100.
|
|
0:32:59
|
Then it's going to router 4 as the exit point.
|
|
0:33:03
|
Now, if we look at the actual updates that the clients are receiving from the server
|
|
0:33:08
|
or from the route reflector,
|
|
0:33:11
|
so router 4 sends the update to 1. 1 is reflecting it ot everyone else.
|
|
0:33:17
|
Again, it's not reflecting the update from router 6
|
|
0:33:19
|
because that's not considered the best path.
|
|
0:33:24
|
we can see the difference between this if we look at the Show IP BGP
|
|
0:33:29
|
regular expression caret(^) 54 underscore(_)
|
|
0:33:33
|
on router 4 versus router 6.
|
|
0:33:37
|
We would see that router 6 has multiple paths
|
|
0:33:41
|
but router 4 only has 1 path.
|
|
0:33:46
|
So, in the vast majority, BGP designs,
|
|
0:33:49
|
we can fairly well tell based on any point of the network
|
|
0:33:53
|
looking at the BGP table how the other neighbors are also routing.
|
|
0:33:58
|
So, based on the fact that router 4 only has 1 route to these destinations,
|
|
0:34:02
|
it means that the route reflector is routing through it to get there.
|
|
0:34:08
|
Now, router 6 has two possible choices.
|
|
0:34:12
|
It locally is choosing to go to the direct connection of BB1.
|
|
0:34:16
|
But this update is not gonna be sent past the route reflector.
|
|
0:34:21
|
If we were to go to router 1 and tell it, "I wanted to prefer router 6's advertisement",
|
|
0:34:27
|
then likewise, it would suppress the advertisement coming from 4.
|
|
0:34:31
|
And then continue to send advertisement from 6 on.
|
|
0:34:39
|
Now, if we were to go to any of the clients, let's say on switch 4,
|
|
0:34:44
|
and look at the details behind any of these routes,
|
|
0:34:46
|
we'll Show IP BGP 112.0.0.0,
|
|
0:34:51
|
we see that the attributes like the next hop value,
|
|
0:34:55
|
the AS path,
|
|
0:34:57
|
the local preference,
|
|
0:35:00
|
the origin code,
|
|
0:35:01
|
those type of attributes are not being modified by the route reflector.
|
|
0:35:06
|
The only key attribute that is being changed is the cluster list.
|
|
0:35:14
|
And actually, we have the originator, this is for loop prevention of your own
|
|
0:35:19
|
route being reflected back to you.
|
|
0:35:23
|
So, it says that router 4's the one who is actually originating this in the network.
|
|
0:35:27
|
This would prevent the case if we have some sort of dual route reflection.
|
|
0:35:30
|
Where 4 could potentially send an update to 1.
|
|
0:35:36
|
1 would pass it to 5. If 5 was also a route reflector, this could be passed to 4.
|
|
0:35:42
|
Router 4 would automatically filter this inbound
|
|
0:35:46
|
if it sees it's own originator ID.
|
|
0:35:50
|
So, the clients at the route reflector can use the originator ID for loop prevention.
|
|
0:35:54
|
The route reflector itself uses what's in the cluster list.
|
|
0:36:00
|
Now, the cluster list is gonna come from the cluster identifier.
|
|
0:36:04
|
Which by default comes fromthe BGP router ID,
|
|
0:36:07
|
which then in turn comes from the highest loopback.
|
|
0:36:12
|
So, just like OSPF or EIGRP or LDP,
|
|
0:36:16
|
the router ID is gonna be the highest loopback address.
|
|
0:36:21
|
Under the BGP process, we could change the BGP router ID
|
|
0:36:26
|
or we could change the BGP cluster ID separately.
|
|
0:36:30
|
Where we'll see there are cases where we would want to modify the cluster ID
|
|
0:36:35
|
so that multiple route reflector in the same clusters share the same value.
|
|
0:36:40
|
So, if I were to say the cluster ID is 1,
|
|
0:36:45
|
then when I clear the outbound updates, when I'm sending a route refresh out,
|
|
0:36:52
|
if I were to againlook at this on switch 4,
|
|
0:36:56
|
we see the cluster list now includes 1.
|
|
0:37:03
|
So, technically, the router ID and the cluster ID are separate values.
|
|
0:37:07
|
But by default, the cluster ID is going to be infered from what the router ID is.
|
