[AUDIO LOGO]
So now it's time to look at redundant RPs with BSR.
Now, just at its default configuration,
this actually works the same as what we saw in auto-RP.
So we're only going to spend just a few minutes looking
at that.
BSR has two other options which are really going
to be the focus of this video.
The first is we can use priority to control which RP becomes
chosen as the active RP.
This is something that wasn't really available in auto-RP,
it just chose the highest IP address.
But the other choice we have with BSR
is leaving everything equal, we can actually
do load sharing per group between multiple RPs.
So that's another option we need to look at because that gives
us not only redundancy, but also a certain amount of load
sharing.
It's a little more complicated than it sounds,
but it gives us load sharing nonetheless.
So as usual, let's bring up our topology
just real quickly to review what we're going to do,
and then we'll jump into the command line
and see redundant RPs with BSR in action.
So one last time, here we are on multicast topology 1.
And there's really two things that we
need to discuss before we jump into the command line.
The first is, of course, that we're
going to be bringing router 4 in here as a second RP.
But the other thing we need to discuss
is when we start doing load sharing,
how does BSR actually do load sharing?
And the answer to that is it uses a hash.
This hash is referenced in RFC 4601,
and I put it here just for your reference.
Don't panic.
You don't have to know this in any way.
I just wanted to show it to you so you understand this is not
as easy as it's just going to do 50/50 load sharing between two
rendezvous points and so on.
It uses this algorithm to combine
the group, the mask, and the RP address to create a hash.
That hash is then used to load share between the RPs.
So don't be too surprised when we start changing the hash mask
length if you don't exactly get a nice even load
share across the RPs.
That's not exactly how this works.
But the other way to look at it, of course,
is that any load sharing is better than no load sharing.
So all of that said, let's jump into the command line.
We'll start on router 4 just by configuring it to be an RP.
So this is actually the exact same configuration
that we did on router 2, the only difference is
we're going to be using router 4's loopback IP address.
So we'll just paste this configuration in,
and now router 4 is a candidate RP.
So let's go up to the BSR router 5 and see what that looks like.
So on router 5, we'll do our show ip pim rp map,
and what we see is that the BSR is now aware of both rendezvous
points.
These are completely equal, except for their IP address.
So the question becomes, which one is actually being used?
Well, if we do our show ip pim rp,
we can see that for our group, it's actually using router 4.
Once again, just like auto-RP, this
has chosen the highest IP address.
This is why we're not going to spend a lot of time discussing
this particular configuration, because at this point,
BSR is acting exactly like auto-RP with only one
difference.
If we go to a router that's not the BSR--
we've been picking on router 6 a lot.
And if we did a show ip pim rp map here,
notice that unlike auto-RP where only the winner gets advertised
to the other routers, with BSR, the BSR is really
just collecting all of the information
and sending it out to the other routers.
Notice the info source is the BSR,
but it's still notifying us of both RPs.
That's because in BSR, each router
chooses the winner on its own.
But again, they're all going to make the same decision
based on the same criteria.
So if we do our show ip pim rp we'll
see that this is also using router 4 just like router 5 is.
Everybody's making the same decision
based on the highest IP.
But what if that's not what we want to do?
What if we want to force router 2 to be the RP
and not router 4 without changing their addresses?
Well, this is where BSR gives us an option.
The good news is this is super simple.
Notice that both of these RPs currently
have a priority of 192.
Well, the best priority wins in BSR, however,
the caveat is the best priority is actually
the lowest priority.
So let's change the priority on router 2 to make it the winner.
So on router 2, we'll simply go into configuration mode.
Under router pim for IPv4.
Under the bsr candidate-rp line, where
we were advertising 10.2.2.2, we'll add a priority.
We can see here the range is 1 to 255.
We already saw that the default was 192.
So let's just lower it to say 128.
Let's commit that change.
Then let's go back over to router 6
and see what's happened.
So if we just do our show ip pim rp again,
we see that now it has switched to router 2 as we wanted it to.
And of course, if we look at the map again,
we'll see that router 2 has that lower or better priority of 128
beating out the 192.
So what this is doing is if our goal is
to have an active standby type scenario,
it allows us to choose which one's going to be active
and which one's going to be standby.
But what if we want to do load sharing?
Well in order to do load sharing, the priorities-- well,
they're going to have to be set back to the same again.
So let's go ahead and do that first,
and then we'll implement load sharing.
So back over here on router 2, if we just
say no on the bsr candidate-rp command,
it'll actually take the whole command out.
So to set this back, we're going to have
to set this back to 192, which is the default
and then commit the change again.
We can exit out of configuration here on router 2.
This time, let's go over to router 7
because seeing the load sharing on router 7, which
is the last hop router is going to be a little bit easier.
So here on router 7, let's start with our show ip pim rp
map because we want to see that they are back to being equal.
The priorities are the same, they're
both 192, which means that we should be using router 4.
So if we do our show ip pim rp, we can see that, yes in fact,
we are using router 4.
Now, one other thing to note here.
If we're going to do group-based load sharing
and we want to see it work, we're
going to need more than just this one group 224.1.1.1.
So we're going to hop on to router 8 real quick
and just have it join a few groups
with some various different group numbers.
So let's go ahead and do that.
So here on router 8, I'm just going
to paste the configuration in.
I already have it saved.
You can see here we're simply joining
a bunch of different igmp groups that
are sort of different in the first and second octets.
It doesn't really matter a whole lot because of the way
the hash works.
However, we're having it join these groups.
So now if we go over to router 7 again,
and we look at our show ip pim rp, what we see
is at the moment--
and you could say then by default--
this is not doing any form of load sharing.
Everything is going to the 10.4.4.4.
The way we control the load sharing is from the BSR.
So let's go over to router 5.
We'll go into configuration mode.
And then on the line where we're configuring
pim and the bsr-candidate, again, we
have to put in the loopback interface,
but now we're going to change the hash mask length.
Now, the default is zero, which means
it's going to put a zero into the formula,
and therefore everything is going
to become the exact same hash.
If you're trying to load share as evenly as
possible between two rendezvous points, which
is a very, very common thing to do, the best value to use
here is 31.
If we hit 31, that allows it to create 2 different hashes
to load share between the rendezvous points
because there's one bit that's not masked.
So if we hit 31 and we go back over and look at router 7
again, we look at our groups again,
we can see that now we have a fairly even split.
We have 3 groups that are going to router 2,
and we have 3 groups that are going to router 4.
Now, just to show you what I was talking about,
let's go change router 5 to something else.
Let's change router 5 to, say, 16.
Only mask 16 bits.
You might think that that would also
give you an even load share.
But like I said, the hash isn't that predictable.
Back over to router 7, look at it again.
And what we see is now we have 4 groups going to router 2
and only 2 groups going to router 4.
So as I mentioned, if you're in an environment that's
using two RPs, which is fairly common,
the best hash mask length to use is generally 31.
Now, you can play around with other numbers
and see what kind of load sharing
you get or you can sit down and figure out the hash,
but generally speaking, 31 works fairly well if you have 2 RPs.
So let's go ahead and set router 5 back
so we have some nice even load sharing.
So again, router 5, we'll just set it back to the 31.
We'll go back over to router 7.
And we can see that we're back to our nice even load
sharing of 3 groups going to 1 RP and 3 groups
going to the other.
So this is how we can do load sharing in BSR.
So in this video, we took a look at our redundancy options
in BSR.
So the first option, which we looked at very quickly,
is we can simply configure multiple BSR/RP candidates
and it will simply choose the one with the highest IP address
just like auto-RP.
The second option, however, gives us
a little bit more control.
We can set the best priority, which is the lowest priority,
on a particular RP, and then that will win and become
the active RP that we're using.
And of course, the final choice is
to change the hash mask length on the BSR
itself so that it will create multiple hashes
for each different group and send them to different RPs.
Again, it can be a little bit finicky,
but if you use a 31 with 2 RPs, you generally
get a fairly even split.
Now, all of that said, that covers everything
that we need to discuss in this skill,
which leaves us with nothing more
than a review in the form of a quiz and, of course,
that's what we're going to do next.
Until then, I hope this has been informative for you,
and I'd like to thank you for viewing.