[AUDIO LOGO]
So we now have everything working in our environment
exactly as we designed it, except we
don't have redundancy for router 1, our route
reflector in 65001.
So in this video, we're going to set up
router 2 as a redundant route reflector.
Let's bring up our topology real quickly just
to remember exactly what we're doing.
And then we're going to jump into the command line,
get router 2 up and running as a redundant route reflector,
and then verify that it's actually working
and that we have multiple paths to get to our destinations.
So this was our original design from back when
we were making our game plan.
And if we take a look at this, we've
accomplished everything on here that we set out to do.
The only thing we haven't configured yet
is this route reflector over here on router 2
and, therefore, all of these other neighborships
that we're going to need in order for this to function.
We also need to reconfigure this neighborship between router
1 and router 2 because we don't want
router 2 to be a route reflector client of its peer route
reflector.
So all of that said, let's jump into the command line.
First, we'll reconfigure router 1 to fix that neighborship
to router 2.
And then we'll do the full configuration on router 2.
So we're not configuring anything we
haven't seen many times before.
So we'll just go ahead and paste the configuration in and then
just talk about it.
What we're doing here is removing our neighborship
to router 2.
Then we're reinstalling our neighborship to router 2,
putting in its remote AS, the update source,
and activating the address family.
The key thing we're doing here is removing it
from our iBGP peers neighbor group
so that it is no longer a route reflector client.
So now we're just configuring it like a traditional BGP
neighborship.
Now let's go configure router 2.
We see here on router 2 where router 1
bounced that relationship.
And we'll paste this configuration in as well.
This is going to be almost the exact same configuration
as router 1 had when we configured it
as a route reflector.
Once again, we're creating our neighbor group.
We're setting up the remote AS, the update source,
and the address family with a route-reflector-client
and next-hop-self under that neighbor group.
And then we're simply applying the neighbor group
to the routers that are going to be our new peers--
routers 3, 4, and 5.
Of course, we still have to configure routers 3, 4, and 5
to neighbor with router 2.
Once again, that's just going to be a standard neighborship.
We'll paste the config in on those routers as well.
So router 3 and 4 are going to be the same configuration.
So this is just going to be a new neighborship
with the remote-as, the update-source, and of course
the next-hop-self.
Router 4 is the same configuration.
Router 5 of course is slightly different
just because it's IOS XE.
However, it's the same basic properties.
If we've done all this correctly,
we should be able to go up to router 2.
We'll do a show bgp summary.
And we see that we are in fact now neighbors
with routers 3, 4, and 5, which we weren't previously.
Now, of course, the whole point of this was to have redundancy.
So let's make sure that's worked.
Let's go over to router 5.
If we do a show ip bgp, we see that we now
have two paths to each destination, one learned
from each route reflector.
Now, one final thing we need to configure here--
when you have route reflectors that
are acting as a redundant cluster rather
than hierarchical, you need to set the cluster ID
to be the same number.
The reason we do this is to prevent
suboptimal routing in the BGP environment
where you could possibly have one route reflector telling
the other route reflector about an update, who then tells
the route reflector clients.
It generally doesn't work out too well.
Again, it could lead to suboptimal path selection.
So it's a best practice to set these to the same number.
That is, of course, assuming that your redundant route
reflectors are actually peered with each other.
There's no requirement to actually do that.
However, here in our lab environment,
they are peered together.
So we'll go ahead and set that cluster ID
to be the same on router 1 and router 2.
Before we do that, just to see that they're not the same now,
let's do a show ip bgp for one of the prefixes here.
We'll pick on the 100.4.4.0.
And we see here that they are in fact coming from two
different cluster lists--
10.2.2.2 and 10.1.1.1, each cluster
being represented by the route reflector's router ID.
That's what we want to change.
So let's go up to router 1.
And since this is going between router 1 and router 2,
we'll effectively just set this to 12.
So again, we'll just paste this configuration in.
The only thing new here is this bgp
cluster-id that we pasted in.
And also notice the route reflector clients
again going down and coming back up.
So again, this should be done either
during initial deployment or during a maintenance window.
We'll do the same thing on Router 2.
It's exactly the same config because we're setting
the cluster-id to match.
Once the neighborships come back up,
let's go back over to router 5.
We'll do our show ip bgp again for the prefix.
And we can see that now the cluster list
is the same on both of them.
So now we have our cluster-id set properly,
and we have our redundancy.
In this video, we saw how to configure a device
as a redundant route reflector and how
to set the cluster-id to match when they're supposed
to be in a redundant cluster.
Again, this wouldn't be necessary
if you were doing hierarchical route reflectors.
But for a redundant cluster, the cluster-id
should be set to be the same.
I hope this has been informative for you,
and I'd like to thank you for viewing.