|
0:00:13
|
Next, we're gonna look at a case where we have multiple route reflectors in the network,
|
|
0:00:18
|
and they are sharing the same cluster ID
|
|
0:00:21
|
in order to prevent loops between their own updates.
|
|
0:00:25
|
Now, typically, the phsyical topology
|
|
0:00:29
|
in which this would be used is where the route reflectors...
|
|
0:00:34
|
have generally physical connectivity to each other,
|
|
0:00:37
|
where we have route reflector 1, route reflector 2,
|
|
0:00:41
|
and route reflector 3,
|
|
0:00:43
|
where these devices
|
|
0:00:46
|
are servicing a separate set of clients.
|
|
0:00:49
|
Router relflector 1 is part of cluster 1,
|
|
0:00:55
|
route reflector is part of cluster 2,
|
|
0:00:57
|
route reflector is part of cluster 3.
|
|
0:01:01
|
The cluster is defined by the clients,
|
|
0:01:05
|
and then, the identifier that the route reflector is using.
|
|
0:01:10
|
So, the ultimate design goal
|
|
0:01:13
|
of using the multiple clusters
|
|
0:01:17
|
is that if we have a client who's attached to route reflector 1,
|
|
0:01:21
|
let's say, all the way in the left, this is client 1.
|
|
0:01:24
|
When it sends an update to the route reflector,
|
|
0:01:28
|
these are passed down to the clients within the cluster.
|
|
0:01:31
|
They are passed to the other clusters,
|
|
0:01:35
|
which in turn passes them down to their clients.
|
|
0:01:42
|
And depending on whether route reflector 2 and route reflector 3 are clients of each other,
|
|
0:01:48
|
we may or may not...
|
|
0:01:49
|
send the updates between them.
|
|
0:01:54
|
So generally, router 1 is gonna peer with route reflector 2 and 3,
|
|
0:01:58
|
2 is gonna peer with 1 and 3,
|
|
0:02:00
|
and 3 is gonna peer with 1 and 2,
|
|
0:02:03
|
but they may or may not designate each other as...
|
|
0:02:06
|
just normal iBGP peers or route reflector clients.
|
|
0:02:10
|
Because remember the three rules
|
|
0:02:13
|
that if the route is learned from a client,
|
|
0:02:15
|
it can be advertised to both clients and non-clients.
|
|
0:02:20
|
But if a route is coming from a non-client,
|
|
0:02:23
|
it can only be advertised to clients.
|
|
0:02:28
|
This means, in the clustering design,
|
|
0:02:31
|
if router 2 is peering with 3,
|
|
0:02:35
|
but they are not clients of each other,
|
|
0:02:40
|
an update that comes from route reflector 1...
|
|
0:02:45
|
goes to route reflector 2, it's not gonna be passed back this way.
|
|
0:02:53
|
Now, there's technically nothing wrong with having the route reflectors be clients of each other.
|
|
0:02:57
|
We could say that basically, everyone is a client everywhere.
|
|
0:03:01
|
The only issue with this is it means there's gonna be more overhead in the control plane.
|
|
0:03:05
|
That route reflector 1 sends the update to 2,
|
|
0:03:08
|
2 sends it to 3,
|
|
0:03:10
|
3 sends it back to 1.
|
|
0:03:12
|
Even though the update is looping, it's really not gonna matter,
|
|
0:03:15
|
because the clustered list is going to prevent that.
|
|
0:03:19
|
The only issue is that we have extra overhead in the control plane
|
|
0:03:23
|
that route reflector 3 needs to send those updates.
|
|
0:03:26
|
Route reflector 1 needs to process them inbound before it can actually discard them.
|
|
0:03:31
|
So, if we're looking at the full BGP table,
|
|
0:03:33
|
to process three 400,000 routes, it's a real lot of overhead for the router to actually do that.
|
|
0:03:40
|
Now, the case that you would want to have them be clients of each other
|
|
0:03:45
|
is that if one of these links go down,
|
|
0:03:49
|
but from router 3's perspective,
|
|
0:03:52
|
2 was not a client and 1 was not a client,
|
|
0:03:57
|
it would mean that a single failure of any of the inter-cluster links
|
|
0:04:02
|
would effectively isolate traffic in cluster 1 from cluster 2.
|
|
0:04:09
|
So again, it's always a trade-off between...
|
|
0:04:11
|
the amount of redundancy and the diversity of the paths
|
|
0:04:15
|
for just how much overhead you have in the control plane.
|
|
0:04:19
|
So, if the routers have tons of memory and tons of CPU power,
|
|
0:04:22
|
then, maybe it doesn't matter if we have the extra updates.
|
|
0:04:25
|
But if they're already at 90% utilization because of BGP,
|
|
0:04:28
|
then, it might not be a good idea to give them the extra updates.
|
|
0:04:33
|
So, regardless of what the design is,
|
|
0:04:36
|
you're never gonna see a loop in the topology.
|
|
0:04:39
|
Because BGP will eventually figure out which updates are valid, and which ones are not.
|
|
0:04:43
|
It just depends on how much processing we have to do
|
|
0:04:46
|
before we figure out that that is a valid design or not.
|
|
0:04:51
|
So, let's look at this in our particular topology,
|
|
0:04:55
|
where we're gonna separate AS 100 into...
|
|
0:04:59
|
a couple different clusters.
|
|
0:05:02
|
We'll say that...
|
|
0:05:05
|
router 1 and 3
|
|
0:05:08
|
are route reflectors in cluster 1.
|
|
0:05:13
|
So, cluster 1 is gonna be between these five neighbors.
|
|
0:05:17
|
With router 1 as route reflector 1,
|
|
0:05:21
|
router 3 as route reflector 3.
|
|
0:05:25
|
Then, router 5 is also gonne be a route reflector.
|
|
0:05:28
|
Let's say this is route reflector 5,
|
|
0:05:30
|
which is going to service...
|
|
0:05:35
|
these four clients.
|
|
0:05:39
|
Now, in the case of the cluster on the right,
|
|
0:05:42
|
we're never gonna have any issues with the duplicate updates,
|
|
0:05:44
|
because there is only one route reflector that is servicing those clients.
|
|
0:05:49
|
So, it means that if an update wants to go to router 4,
|
|
0:05:52
|
there's basically no option but to go through router 5.
|
|
0:05:56
|
However, between router 1 and 3,
|
|
0:06:00
|
if 3 says that "These three neighbors are my clients."
|
|
0:06:04
|
And router 1 likewise says that "These three neighbors are my clients",
|
|
0:06:10
|
we would want to avoid the case where 6 sends an update to 1,
|
|
0:06:16
|
1 sends it to 3,
|
|
0:06:17
|
and then, 3 sends it back to 6.
|
|
0:06:20
|
Or 3 sends it to switch 1, where switch 1 already gathered in the first place from router 1.
|
|
0:06:26
|
And the way that we're gonna do that...
|
|
0:06:27
|
is by under router 1 and 3's configuration,
|
|
0:06:31
|
they're simply gonna share the same cluster ID.
|
|
0:06:35
|
So, that way, they would be able to exchange updates
|
|
0:06:38
|
from other clusters,
|
|
0:06:42
|
but they're not going to...
|
|
0:06:43
|
exchange routes about their same local clients.
|
|
0:06:49
|
Now, from router 5's perspective, this configuration is gonna be pretty straightforward.
|
|
0:06:53
|
We would simply go to the process.
|
|
0:06:58
|
And on router 5, we'll say, under BGP 100,
|
|
0:07:02
|
we have neighbor R5 clients...
|
|
0:07:09
|
as a peer group.
|
|
0:07:11
|
Neighbor R5 clients are going to be in...
|
|
0:07:16
|
remote AS 100.
|
|
0:07:19
|
They're going to be...
|
|
0:07:23
|
route reflector clients.
|
|
0:07:29
|
And the update
|
|
0:07:31
|
source
|
|
0:07:32
|
is loopback zero.
|
|
0:07:36
|
And the actual neighbors...
|
|
0:07:38
|
that are part of the peer group would be...
|
|
0:07:43
|
router 4.
|
|
0:07:45
|
peer group R5 clients.
|
|
0:07:52
|
Switch 2 and switch 4. So, that's gonna be 8 and 10.
|
|
0:08:00
|
Then, from their perspective,
|
|
0:08:02
|
so, this is from 4, 8, and 10,
|
|
0:08:05
|
they would say, under BGP,
|
|
0:08:09
|
"We are no longer peering with 1."
|
|
0:08:12
|
So, 1 is no longer the route reflector.
|
|
0:08:15
|
"Instead, we are peering with...
|
|
0:08:20
|
router 5, who's in AS 100.
|
|
0:08:26
|
And the update source...
|
|
0:08:30
|
is loopback zero."
|
|
0:08:44
|
Now, I'm going to maintain the peering between 1 and 5.
|
|
0:08:48
|
Who essentially are in the different clusters.
|
|
0:08:50
|
And we'll see in a minute why we do wanna maintain that peering
|
|
0:08:53
|
to make sure that the routes are advertised everywhere.
|
|
0:08:57
|
Then, on router 4,
|
|
0:09:00
|
switch 2, and switch 4,
|
|
0:09:03
|
we're getting rid of...
|
|
0:09:05
|
router...
|
|
0:09:06
|
Oops, that's the wrong one.
|
|
0:09:09
|
No Neighbor...
|
|
0:09:10
|
R5 Clients.
|
|
0:09:16
|
So, we're getting rid of router 1,
|
|
0:09:18
|
and we are replacing this with 5.
|
|
0:09:37
|
Then, on both router 1 and 3,
|
|
0:09:40
|
they're essentially gonna have the same configuration.
|
|
0:09:42
|
So, we'll say that this is...
|
|
0:09:46
|
cluster clients.
|
|
0:09:53
|
Where it's essentially the same configuration here, we're just specifying different...
|
|
0:09:58
|
different neighbors here.
|
|
0:10:00
|
So, from router 1, we're peering with 6.
|
|
0:10:04
|
With switch 1,
|
|
0:10:08
|
with switch 3,
|
|
0:10:12
|
and then also with router 3.
|
|
0:10:15
|
Now, router 3, I'm not gonna put it as part of the same peer group,
|
|
0:10:20
|
because there's gonna be a different policy that applies on to router 3
|
|
0:10:24
|
than applies on to the other ones.
|
|
0:10:27
|
So, anytime there's a difference between...
|
|
0:10:30
|
the...
|
|
0:10:32
|
one neighbor versus the other neighbors in the peer group,
|
|
0:10:35
|
then, we're gonna have to separate it out.
|
|
0:10:37
|
Because as I mentioned,
|
|
0:10:38
|
the same policy that goes to one neighbor
|
|
0:10:40
|
has to be the exact same that goes to all of the other ones.
|
|
0:10:44
|
So, router 3 is gonna be...
|
|
0:10:46
|
a regular neighbor.
|
|
0:10:48
|
Remote AS 100.
|
|
0:10:53
|
And the update source...
|
|
0:10:56
|
is loopback zero.
|
|
0:11:01
|
From the other neighbor's perspective in that cluster,
|
|
0:11:05
|
they're gonna have peerings to both 1 and 3.
|
|
0:11:10
|
And this is the main goal of the clustering that we have redundancy
|
|
0:11:15
|
between the route reflectors.
|
|
0:11:17
|
So, as long as those clients can reach either 1 or 3,
|
|
0:11:21
|
then, they should be able to get the updates about the entire network.
|
|
0:11:25
|
So, if 1 goes down, we still have 3 as the back up.
|
|
0:11:27
|
Then likewise, if 3 goes down, we're gonna have 1 as the back up.
|
|
0:11:31
|
So, this is gonna go on router 6,
|
|
0:11:35
|
switch 1,
|
|
0:11:39
|
and switch 3.
|
|
0:11:45
|
We then have router 1's config,
|
|
0:11:49
|
which is gonna be...
|
|
0:11:54
|
different than the previous.
|
|
0:11:56
|
So, essentially, what I can do here, I'll just remove the BGP process.
|
|
0:12:01
|
And we'll start from scratch.
|
|
0:12:08
|
So, we have three neighbors that are route reflector clients.
|
|
0:12:11
|
The two route reflectors in the cluster, they are not clients of each other.
|
|
0:12:16
|
Then, router 3 is essentially gonna say the same thing.
|
|
0:12:19
|
The only thing different is that we're changing this peering to 1's address...
|
|
0:12:27
|
as opposed to 3's.
|
|
0:12:42
|
So, next step, before we do any verification of the BGP table,
|
|
0:12:46
|
we need to make sure all the peerings are up.
|
|
0:12:48
|
So, on everyone, we need to look at the Show IP BGP Summary,
|
|
0:12:52
|
and make sure that no one has left out
|
|
0:12:54
|
one of the peerings, or one of the update source,
|
|
0:12:57
|
because that's gonna affect ultimately
|
|
0:12:59
|
what's going on with all the advertisements.
|
|
0:13:02
|
So, before geting to any more
|
|
0:13:04
|
advanced configurations in BGP,
|
|
0:13:07
|
within the scope of the lab exam,
|
|
0:13:08
|
you always need to verify from the bottom up.
|
|
0:13:13
|
So, if we look at the Show IP BGP summary,
|
|
0:13:15
|
and the neighbor's not working,
|
|
0:13:17
|
then you shouldn't be trying to verify why the aggregation isn't working.
|
|
0:13:21
|
Or why the best path selection isn't working.
|
|
0:13:24
|
So, form router 1's perspective, we have three clients.
|
|
0:13:28
|
And the non-client then which is router 3.
|
|
0:13:33
|
Router 2 is in the other AS. So, that's fine. The configuration hasn't changed here.
|
|
0:13:38
|
Router 3...
|
|
0:13:41
|
has its clients which are 6, 7, and 9.
|
|
0:13:45
|
The EBGP peer, router 2, and then the non-client peering with router 1.
|
|
0:13:53
|
Router 4 has the peering with the route reflector 5.
|
|
0:13:58
|
And the EBGP neighbor.
|
|
0:14:00
|
5 has...
|
|
0:14:04
|
its three clients but then I'm missing a peering between
|
|
0:14:09
|
1 and 5.
|
|
0:14:10
|
So, what we need to have the network look like overall,
|
|
0:14:14
|
there needs to be inter cluster peerings.
|
|
0:14:17
|
Where 3 and 5 and 1 and 5 need to peer.
|
|
0:14:25
|
Now, router 5 already has a peering configured to 1.
|
|
0:14:28
|
We need to configure it from 1 back to 5.
|
|
0:14:31
|
So, on router 5, let's say, Show Run Section Router BGP,
|
|
0:14:38
|
And notice that router 1,
|
|
0:14:40
|
it's not part of the peer group.
|
|
0:14:42
|
Because it's gonna have a different update policy
|
|
0:14:45
|
than the other clients in our cluster.
|
|
0:14:48
|
So, this is the correct configuration here.
|
|
0:14:50
|
I would wanna say the same thing for router 3.
|
|
0:15:07
|
So, router 3 is in AS 100.
|
|
0:15:09
|
We're updating from our local loopback.
|
|
0:15:13
|
Then on both router 1 and 3,
|
|
0:15:17
|
we're peering with router 5.
|
|
0:15:23
|
The update source is loopback 0.
|
|
0:15:25
|
Now, we don't necessarily have to set the update source as the loopback.
|
|
0:15:29
|
It's just usually easier to specify the value that we're gonna assume IGP is routing properly.
|
|
0:15:37
|
So, if EIGRP is already running on every single interface in the network,
|
|
0:15:41
|
then there's no reason that we need to specify the physical links that we're peering with.
|
|
0:15:45
|
So, as long as router 3 and 5 have some path to each other,
|
|
0:15:49
|
it means that the BGP peering is gonna be up.
|
|
0:15:51
|
We don't necessarily care what the path is.
|
|
0:15:54
|
As long as it's something valid, it's gonna eventually allow them to route the traffic.
|
|
0:15:59
|
Now, also keep in mind that the route reflectors here, they're just used for the control plane.
|
|
0:16:06
|
When we actually look at the final path of the updates,
|
|
0:16:10
|
we could have a potential case where BB1 sends the update to 6.
|
|
0:16:16
|
6 sends it to 1.
|
|
0:16:18
|
1 sends it to 5.
|
|
0:16:20
|
And 5 reflects it down to switch 4.
|
|
0:16:24
|
But since the next hop value is not being updated,
|
|
0:16:28
|
it means that the actual data plane flow could go this direction,
|
|
0:16:34
|
avoiding router 1.
|
|
0:16:40
|
So, again, the amount of updates that we have in the network,
|
|
0:16:42
|
it really doen't matter.
|
|
0:16:43
|
Okay, it's just gonna be a function of how much overhead there's gonna be in the actual control plane.
|
|
0:16:49
|
The data plane forwarding is always based on the IGP route to the next hop.
|
|
0:16:54
|
So, as long as the next hop is staying,
|
|
0:16:56
|
that interface of BB1,
|
|
0:16:58
|
then everyone internal to the topology
|
|
0:17:01
|
is gonna choose whenever there best IGP route is to get out of the network.
|
|
0:17:09
|
So, now, let's look at our final verification.
|
|
0:17:10
|
Let's go to router 1.
|
|
0:17:15
|
Look at the Show IP BGP Summary.
|
|
0:17:21
|
We have all our peerings up.
|
|
0:17:23
|
Okay, if we look at the Show IP BGP,
|
|
0:17:26
|
we see that we have a number of duplicate paths
|
|
0:17:31
|
to each of these destinations.
|
|
0:17:33
|
Now, let's pick just one of them individually. We'll take this top one.
|
|
0:17:37
|
28.119.16.0
|
|
0:17:40
|
If we Show IP BGP for this particular route,
|
|
0:17:44
|
it says that it's coming from three different neighbors.
|
|
0:17:48
|
One of them who is router 6,
|
|
0:17:52
|
which is the actual originator here.
|
|
0:17:55
|
One that came from router 3 and one that came from router 5.
|
|
0:18:02
|
So, here, we have kind of an inefficient design for the updates.
|
|
0:18:07
|
Where somehow this update is getting to 5 and it's being passed back to us.
|
|
0:18:14
|
So, let's try to follow the path of the updates here.
|
|
0:18:17
|
First we'll go to router 6 and look at the Show IP BGP
|
|
0:18:24
|
for this particular prefix, which is 28.119.16.0
|
|
0:18:33
|
Router 6 says that it has two possible paths.
|
|
0:18:37
|
One of them is from EBGP neighbor.
|
|
0:18:40
|
One of them is from the iBGP neighbor.
|
|
0:18:44
|
Now, it really doesn't make sense
|
|
0:18:46
|
that router 6 should be sending this route out to router 1, and then getting the update back in.
|
|
0:18:58
|
And the reason why,
|
|
0:19:00
|
is that we haven't configured the cluster ID to be the same between router 1 and router 3.
|
|
0:19:08
|
And it's kind of hard to see exactly where this is being originated from.
|
|
0:19:13
|
But it says, it came from 4
|
|
0:19:15
|
and it went through both 5 and 1.
|
|
0:19:18
|
This means that the update is going from BB3 to 4.
|
|
0:19:23
|
4 to 5, 5 to 1, and then 1 back to 6.
|
|
0:19:29
|
This would then imply from router 1's perspective,
|
|
0:19:33
|
what about the best path selection?
|
|
0:19:43
|
If router 1 is advertising this alternate path to router 6,
|
|
0:19:48
|
it means that 6 cannot be used as router 1's exit point.
|
|
0:19:53
|
Because remember, you only advertise your best path.
|
|
0:19:56
|
So, there should not be a case where the update goes from 6 to 1
|
|
0:19:59
|
and then 1 right back to 6.
|
|
0:20:02
|
So, let's actually try tracing this traffic.
|
|
0:20:04
|
Let's try it from switch 4 and see what the ultimate exit is.
|
|
0:20:08
|
If we trace...
|
|
0:20:11
|
And then the prefix was...
|
|
0:20:14
|
28.119.16.1
|
|
0:20:22
|
Notice that eventhough there's a bunch of duplicate updates,
|
|
0:20:27
|
there's still no loop in the data plane.
|
|
0:20:29
|
Because regardless which of these BGP updates we're using,
|
|
0:20:33
|
we're still ultimately following the IGP route to this next hop.
|
|
0:20:39
|
And we could assume that this is a loop free path
|
|
0:20:41
|
because EIGRP's dual calculation is gonna do that automatically.
|
|
0:20:46
|
The same would be true if we were using OSPF or IS-IS as our underlying IGP.
|
|
0:20:52
|
SO, BGP assumes that IGP is running already.
|
|
0:20:56
|
Then it doesn't have to do a lot of complicated logic about the loop prevention.
|
|
0:21:00
|
As long as the updates don't loop infinitely,
|
|
0:21:03
|
then that's really all the BGP cares about.
|
|
0:21:05
|
Because it's IGP that's actually doing the loop prevention in the data plane.
|
|
0:21:14
|
Now, let's take a look at router 3 for the same updates.
|
|
0:21:19
|
We could see router 3 sees a different subset of these.
|
|
0:21:22
|
Some of them are coming from 54.28.1.254, which is this address here.
|
|
0:21:32
|
Some of them are coming from 204.12.28.254, which is this address here.
|
|
0:21:41
|
So, essentially, router 3 is learning two separate updates.
|
|
0:21:44
|
One of them is going this direction.
|
|
0:21:46
|
One of them is going this direction.
|
|
0:21:53
|
We could see this if we look at the specifics of the 28.119.16.0
|
|
0:21:58
|
We can tell this based onthe originator IDs.
|
|
0:22:03
|
And then the cluster list.
|
|
0:22:07
|
Now, in reality, there's not really a case where router 3 needs this route.
|
|
0:22:14
|
Because why?
|
|
0:22:23
|
Why should router 3 not need to know the path that is via router 6?
|
|
0:22:30
|
Okay, this clustering design, a lot of it has to do with the physical topology.
|
|
0:22:34
|
So, we would have to assume in this case that...
|
|
0:22:37
|
let's say potentially, the link between router 6 and switch 1 didn't exist.
|
|
0:22:47
|
So, in this type of case, it doesn't make sense for BB1 to send update to 6.
|
|
0:22:52
|
6 send it to 1, 1 send it to 3 and then for 3 to send it to these neighbors,
|
|
0:23:00
|
because if router 1 is already doing that,
|
|
0:23:02
|
it's basically just the same exact infromation that's duplicated.
|
|
0:23:07
|
We should be able to see this if we go on the actual clients.
|
|
0:23:10
|
Go to switch 3 and look at the Show IP BGP.
|
|
0:23:14
|
We see that we have duplicate information
|
|
0:23:16
|
where we really don't need all of these routes.
|
|
0:23:21
|
This is where the route reflectors inside the cluster
|
|
0:23:25
|
which share the same cluster identifier.
|
|
0:23:28
|
So, we'll go to both router 1 and router 3.
|
|
0:23:32
|
And say the BGP cluster ID is anything that's the same.
|
|
0:23:36
|
Okay, we'll say 1.2.3.4. Doesn't really matter what it is.
|
|
0:23:40
|
As long as these both neighbors agree on this.
|
|
0:23:49
|
Then let's do a hard clear of the BGP...
|
|
0:23:53
|
peerings, just to make sure that everything reconverges.
|
|
0:23:57
|
Clear IP BGP Star(*)
|
|
0:24:03
|
And we could see that router 1 is gonna do a TCP reset for all of the neighbors.
|
|
0:24:08
|
Re-establish the sessions from scratch and then have to go through the updating process.
|
|
0:24:15
|
So, in a real BGP network in production, you wouldn't want to do it this way.
|
|
0:24:18
|
It means the router's gonna temporarily drop traffic as it tries to reconverge.
|
|
0:24:23
|
So, that's what the route refresh is for instead
|
|
0:24:26
|
where we're sending a triggered update out
|
|
0:24:28
|
or requesting a triggered update inbound.
|
|
0:24:33
|
So, now, let's look at the end result.
|
|
0:24:34
|
Let's look at everyone's output for the Show IP BGP
|
|
0:24:38
|
for...
|
|
0:24:41
|
28.119.16.0
|
|
0:24:46
|
Now, previously, router 1
|
|
0:24:49
|
had three separate paths to these.
|
|
0:24:53
|
They were from 5, 3 and 6.
|
|
0:24:58
|
But it didn't really make sense that three would learn the update.
|
|
0:25:03
|
Let's say it learns it this direction and then sends it back to 1.
|
|
0:25:09
|
Because based on the physical transit path,
|
|
0:25:12
|
router 3 should never be in the path to either 4's segment to BB3
|
|
0:25:18
|
or 6's segment to BB1.
|
|
0:25:20
|
So, the idea behind the clustering is we're trying to filter out that redundant update
|
|
0:25:25
|
between the two route reflectors.
|
|
0:25:27
|
If we look at the end clients on switch 1,
|
|
0:25:33
|
depending on how their route reflectors are making the decisions,
|
|
0:25:38
|
we may see only one update or we may see separate ones.
|
|
0:25:43
|
So, if we look at router 1 versus router 3,
|
|
0:25:46
|
let's say Show IP BGP.
|
|
0:25:49
|
And then, for the same prefix.
|
|
0:25:53
|
Router 1 says, "My best route is via router 5",
|
|
0:25:59
|
where router 3...
|
|
0:26:02
|
says "My best route is through router 6."
|
|
0:26:05
|
So, they're actually not agreeing on what the forwarding path is,
|
|
0:26:09
|
but eventually, it's gonna work itself out...
|
|
0:26:13
|
depending on what physical links that they used in the network.
|
|
0:26:17
|
So, to cut down on this a little bit,
|
|
0:26:19
|
let's try to get all of the route reflectors to agree on the path.
|
|
0:26:23
|
One way that we could do this would be to use the local preference,
|
|
0:26:26
|
because local preference is significant to the entire autonomous system.
|
|
0:26:31
|
So, as a quick fix on this on router 4,
|
|
0:26:33
|
I'm gonna say, "As I receive all of the updates in from BB3,
|
|
0:26:36
|
I'm just gonna set the local preference to 200."
|
|
0:26:39
|
Where the default of router 6 is receiving it in is going to be 100.
|
|
0:26:45
|
So on router 4, we'll say...
|
|
0:26:52
|
Route Map...
|
|
0:26:54
|
In from BB3.
|
|
0:26:57
|
Set Local Preference 200.
|
|
0:27:01
|
Then, under BGP 100, Neighbor 204.12.28.254,
|
|
0:27:07
|
Route Map In from BB3 In.
|
|
0:27:13
|
If we look at the Show IP BGP Output,
|
|
0:27:17
|
we can see right now, the local preference has not been modified.
|
|
0:27:20
|
Not until I ask for a route refresh that's going to apply the new policy
|
|
0:27:25
|
that the local preference should change to 200.
|
|
0:27:28
|
So, let's say Clear IP BGP 204.12.28.254 In.
|
|
0:27:37
|
Now, if we Show IP BGP,
|
|
0:27:39
|
we could see the local preference change to 200.
|
|
0:27:42
|
This value should be preserved as the update goes to 5.
|
|
0:27:49
|
So, 5 now says, "I'm gonna prefer this advertisement."
|
|
0:27:55
|
Likewise when this is received by 1 or 3,
|
|
0:28:00
|
they both should now agree on what the exit point is based on the local preference.
|
|
0:28:09
|
So, they're both agreeing that router 4 is gonna be the exit point.
|
|
0:28:13
|
Which means that the rest of the clients, like on switch 3,
|
|
0:28:20
|
they're only gonna see...
|
|
0:28:22
|
the one possible exit.
|
|
0:28:24
|
Now, in reality, we see multiple updates about the same exit point.
|
|
0:28:29
|
And it doesn't matter which one we follow,
|
|
0:28:31
|
because they're gonna use the same IGP route to the next hop.
|
|
0:28:36
|
But the key is that we're trying to get the redundancy to begin with.
|
|
0:28:38
|
So, if we look at the Show IP BGP,
|
|
0:28:41
|
and then, take any of these prefixes, let's say 112.
|
|
0:28:46
|
One of them is...
|
|
0:28:49
|
coming from router 3, one of them is coming from router 1.
|
|
0:28:54
|
It doesn't really matter which one we choose as the best route,
|
|
0:28:58
|
because we're using the same next hop value for either of them.
|
|
0:29:06
|
So, if I now were to go to router 1,
|
|
0:29:10
|
and let's say router 1 crashes. We'll just say...
|
|
0:29:15
|
Reload.
|
|
0:29:21
|
This means that this bottom update is gonna get withdrawn,
|
|
0:29:36
|
which means that now, we fall back over to router 3,
|
|
0:29:40
|
but ultimately, it shouldn't affect the actual transit to the destination.
|
|
0:29:46
|
So, since we're using the same next hop value,
|
|
0:29:49
|
the convergence time of the route
|
|
0:29:51
|
is not based on how long it takes us to detect that router 1 is down,
|
|
0:29:56
|
it's determine based on how long IGP takes to re-converge.
|
|
0:30:02
|
So, a lot of the BGP design, when we look at this from a larger scale point of view,
|
|
0:30:07
|
the convergence of the BGP network,
|
|
0:30:10
|
is more a function of the IGP network
|
|
0:30:13
|
than it is of BGP itself.
|
|
0:30:16
|
Because for the iBGP transit,
|
|
0:30:18
|
we're always relying on the IGP route to the next hop.
|
|
0:30:23
|
So, that means that if we can get high availability for the next hop,
|
|
0:30:26
|
it doesn't really matter what the BGP update is.
|
|
0:30:30
|
So, as long as the physical transit path doesn't necessarily have to go through the route reflector,
|
|
0:30:35
|
then, this type of clustering design
|
|
0:30:37
|
gives us a more diverse view of the BGP topology
|
|
0:30:40
|
while still ending up in
|
|
0:30:43
|
a valid forwarding path regardless of which route reflector that we're using.
|
|
0:30:49
|
Now, in an actual design, the network wouldn't look like this to start,
|
|
0:30:52
|
because there is too many links that are meshed between the devices
|
|
0:30:56
|
that it doesn't even really make sense to split this into a cluster.
|
|
0:31:00
|
Usually, it would make more sense where...
|
|
0:31:03
|
this would be from a larger
|
|
0:31:05
|
scale service provider,
|
|
0:31:07
|
where maybe they have point of presence on the US West Coast in Los Angeles,
|
|
0:31:11
|
and then in New York.
|
|
0:31:14
|
And they're trying to do long-haul between them.
|
|
0:31:19
|
It doesn't make sense that for the routers that are in LA,
|
|
0:31:25
|
that when their updates go here,
|
|
0:31:28
|
we wouldn't want the update to go to New York,
|
|
0:31:30
|
and then, let's say go down to Dallas, and then back.
|
|
0:31:37
|
So, we would never want to traffic to route...
|
|
0:31:40
|
this direction to begin with.
|
|
0:31:43
|
So, the inter-cluster communication
|
|
0:31:46
|
would be non-clients.
|
|
0:31:48
|
This would then prevent the case where a route from LA
|
|
0:31:52
|
goes to New York, and then is reflected back down to Dallas.
|
|
0:31:56
|
Where in reality, if...
|
|
0:31:58
|
Dallas wants to get to LA, they have to go directly from that neighbor.
|
|
0:32:03
|
But again, it's always a trade-off.
|
|
0:32:05
|
It's a trade-off between the redundancy of the network
|
|
0:32:09
|
versus how much overhead you have in the control plane advertisements.
|
|
0:32:17
|
So, if we look at the configuration here of...
|
|
0:32:21
|
router 3 or router 1,
|
|
0:32:23
|
it's actually a pretty straightforward implementation.
|
|
0:32:27
|
The thing that's difficult is that...
|
|
0:32:30
|
we need to understand visually how the design in gonna be set up to begin with.
|
|
0:32:34
|
So, the only extra command that we're adding is just the cluster ID.
|
|
0:32:39
|
That the two route reflectors inside the same cluster.
|
|
0:32:42
|
So, the two route reflectors that are servicing the same clients,
|
|
0:32:45
|
they need to share the same identifier.
|
|
0:32:47
|
Otherwise, they're gonna loop the updates back and forth between each other.
|
|
0:32:51
|
But again, there's never gonna be a traffic loop,
|
|
0:32:54
|
because we're still using the IGP route to the next hop.
|
|
0:32:58
|
It's just an inefficiency in the BGP updates themself.
|
|
0:33:03
|
Now, we'll also see when we look at the Best Path Selection Next
|
|
0:33:07
|
that the cluster ID length
|
|
0:33:10
|
is also part of best path selection.
|
|
0:33:13
|
So, it means that if all the attributes are equal,
|
|
0:33:15
|
if the AS path, the local preference, the med,
|
|
0:33:19
|
the metric to the next hop,
|
|
0:33:23
|
then, we would look at what the shorter clustered list length would be.
|
|
0:33:29
|
So essentially, we would choose the routes that goes through the minimum amount of route reflectors.
|
|
0:33:36
|
So, we're choosing effectively the geographically closer exit point.
|
|
0:33:45
|
Now, there's a couple documents on Cisco's website that goes over this type of design ,
|
|
0:33:50
|
that could be a good preference.
|
|
0:33:51
|
If you look at...
|
|
0:33:54
|
the search for BGP case studies,
|
|
0:33:59
|
this document on Cisco's website,
|
|
0:34:01
|
it has come pretty good examples of...
|
|
0:34:05
|
these type of designs, route reflectors,
|
|
0:34:08
|
so, a simple route reflector design.
|
|
0:34:10
|
And then, multiple clusters,
|
|
0:34:14
|
and then an even more complex design
|
|
0:34:16
|
beyond that where we have multiple route reflectors within the same cluster.
|
|
0:34:20
|
And this is where you would need to have...
|
|
0:34:24
|
basically, router D.
|
|
0:34:29
|
And router H.
|
|
0:34:33
|
So, this one here, and this one here.
|
|
0:34:35
|
These are route reflectors inside the same cluster.
|
|
0:34:38
|
It would be these two routers that would wanna share the same cluster identifier.
|
