[AUDIO LOGO]
Our next choice for automatically discovering
the RP address is the industry standard BSR,
or Bootstrap Router.
Now, this functions in a lot of ways similar to AutoRP.
But it has its fundamental differences as well.
Like AutoRP, this has two primary components.
We have the routers that are the RP candidates that
are willing to be RPs for either all of the groups
or maybe just a subset of the groups.
Then those announce their willingness to the--
well, the bootstrap router, not the mapping agent like we
had in AutoRP.
But, here, we call it the BSR.
So the protocol itself is actually
named after that particular router.
Now, it has a very similar job.
It collects all the information about the candidate RPs.
But here's a fundamental difference
where AutoRP chose one RP chosen by the mapping agent
and announced to the rest of the network.
In BSR, the entire list of candidate RPs
is collected on the BSR.
And then the whole list is sent out to all the other routers.
And then each of those choose the RP off that list.
Now, they're all going to choose in the same way.
So, ultimately, we're still going
to end up with everybody choosing the same RP.
It's just done a little bit differently.
As we go through, we'll see why.
This is to allow a form of load sharing that we can do in BSR.
Now, of course, another fundamental difference here
is this is actually built into PIM itself.
It actually uses PIM's multicast group for its communication.
We don't have these additional groups,
like we did with AutoRP, that have
to be sent through the network.
So that's a big advantage.
But it also means it's only supported in PIM version 2.
So, again, it has a lot of similarities, but also
quite a few differences.
So let's go ahead and jump in and talk
about those differences and similarities.
And then we'll jump into the command line
and take a look at BSR in action.
So as we mentioned, BSR is the industry standard version
of AutoRP.
This is defined in RFC 5059 if you
want to look at this in a little bit more detail.
We also mentioned that this is part of PIM version 2.
This is not available in PIM version
1, because PIM had to be updated in order to support BSR.
Now, this actually uses the PIM group itself.
So this is traveling right inside of 224.0.0.13.
The big advantage to this, of course,
is this is a link-local multicast
group, which means it doesn't have to be routed itself.
So this does not have that same problem that AutoRP did.
This travels right inside the PIM protocol itself.
So we don't have to have any additional multicast
groups that are being flooded through the network.
So, again, from an operational perspective,
the BSR actually collects the information
about those candidate RPs.
Now, of course, the candidate RPs
still have to announce their willingness
to be an RP to the BSR.
But you can see here how the BSR is essentially
acting the same as the mapping agent did in AutoRP.
Where it gets to be a little bit different
is the BSR then disseminates all of the candidate RP information
to the other routers.
It doesn't just choose one winner.
The BSR's job is not to select the RP.
It simply collects the information
and then sends it out to all of the other routers.
Each of those other routers then makes
its own independent decision.
But it is based on the same rules.
Since it's based on the same rules,
they will all make the same although independent decision.
This is important because we have
to understand that we're still going to learn
the same RP on each device.
Now, these rules can be modified by the BSR itself.
We'll see how to do that when we get into configuration.
This uses something called a hash mask.
And we can use this to implement some load sharing in BSR.
Now, just so we're clear, we're not
going to get very deep into that load sharing here
in this skill.
However, when we get to our skill
on actually implementing multicast
and we have a larger environment that we're working with,
we'll take a look at this and see
how BSR can choose different RPs for different groups
based on this hash mask.
So because of the way all of this works,
this does give us a way to provide redundancy
because, again, the BSR will announce multiple candidates,
mobility because, again, any of those addresses
can move or be added to the group
or removed from the group.
And it allows us to do that group-based load sharing we
were just talking about based on the hash mask that's
announced by the BSR.
So now that we have some of these details
down, let's jump into the command line
and take a look how to actually configure
BSR to be a candidate RP as well as configuring the BSR itself.
So let's begin with a show ip pim rp map.
We currently have no groups mapped to any RPs.
However, if we do a show ip mroute,
we will see that we, of course, are still
listening to the AutoRP group.
But the main thing we want to see
is that we're not going to be adding
to this when we start up BSR.
Also, if we did a show ip igmp groups, we'll see once again,
we're joined to that AutoRP Group
on our loopback interface.
However, we're not going to be adding
to this as we start up BSR.
That's the main thing we want to see
is that this traffic is just going to be inside of PIM
itself.
So let's go into configuration mode.
First thing we'll do is configure ourselves
to be the RP candidate.
The command for this is a little bit different.
It's ip pim.
And this time it's just rp-candidate.
Once again, we have to specify the interface base.
So we'll say loopback 0.
Now, notice that there's nothing on here about scope.
The reason scope is not here is because this is
all link-local multicast now.
It's not being routed, so there is no need for a TTL.
The TTL is going to be 1.
Also note that we can, again, configure the group list here,
just like we did with static and AutoRP.
We can also change the interval.
And we can set the priority because, again, BSR
is going to follow rules as far as which candidate to select.
Again, we're not going to change any of these for this example.
So we'll just go ahead and hit Enter.
Now, if we do a show ip pim rp map,
notice that, again, we still haven't learned anything yet,
because we don't have a BSR.
However, we are being a candidate RP.
Also note it's indicating that this is only for PIM
version 2 because that's what BSR needs.
So now let's configure this router to also be the BSR.
So now we say ip pim bsr-candidate.
Quick note here, the reason why this is a candidate,
we can also have redundant BSRs.
And it will elect one BSR out of the group to actually function
as the active BSR.
This is going to be done by priority as well.
And we'll see that here as we go through this command.
If we take a look at our options,
it's again just for the interface.
So we'll say loopback 0.
And here's where we can set that hash mask length.
Now, the default for this is going to be 0.
And we'll leave it like that for now.
Notice I could also hit Enter and go with the defaults.
The only reason I'm going to put in the actual 0 and continue
is this is where we could set the priority as far
as whether we're allowed to become the active bootstrap
router.
So we could configure the priority as well.
Now, again, we're not going to configure these.
However, I just wanted to point out
that notice you have to put the hash mask length before you can
specify the priority, or you can specify none of them
and just get the defaults.
Notice that our tunnels have already
come up, indicating that this is probably working just fine now.
We'll exit configuration.
And we'll do a show ip pim rp map.
So what do we see?
First, we see that this router is the bootstrap router.
It's, again, responsible for all the multicast groups.
The RP is, of course, 10.1.1.1.
Notice that this, again, is only for version 2.
Our info source is the bootstrap router 10.1.1.1.
We've, of course, learned this via bootstrap.
We see the default priority is 0 because we didn't change it.
And the current hold time is 150.
It's been up for 18 seconds, and it expires
in 2 minutes and 7 seconds.
If we do a show ip pim bsr, we can get some more detail on BSR
itself.
Again, we see that this is only PIM version 2.
This system is the BSR.
The BSR's address is the 10.1.1.1.
We can see, of course, our uptime,
the default priority of 0, the default hash mask length of 0.
And we also see that it's learned the candidate
RP of 10.1.1.1.
It's being advertised every 60 seconds.
And the whole time is, again, that 150 seconds
that we saw previously.
And just to wrap up, if we do our show ip mroute again,
we've added no additional groups here.
And if we look at our igmp groups again,
we've added no additional groups here either
because, again, BSR does not require any additional groups
in order for it to function.
In this video, we took a look at BSR,
which is, again, the industry standard
version of Cisco's AutoRP.
I only call it that because Cisco AutoRP, of course,
came out first in PIM version 1.
And then the industry came out with BSR
starting with version 2.
We can also see that they function
a bit the same in that there's the candidate RPs,
and then there's the device.
AutoRP calls it the mapping agent.
And BSR calls it, well, the BSR that collects this information
and sends it out to the other routers.
Now, that's, of course, where things
start to get a little different, where all of the other routers
would learn all of the candidate RPs.
And they each make their own decisions
where in AutoRP the mapping agent
made that decision for us.
Again, we will review this in a little bit more
detail when we have a larger environment
during our multicast implementation skills.
For now, we need to take a look at this thing called
Anycast RP.
And that's exactly what we're going to jump in and take
a look at next.
Until then, I hope this has been informative for you.
And I'd like to thank you for viewing.