[AUDIO LOGO]
So now that we've taken a close look
at Cisco's proprietary Auto-RP solution
for dynamically finding the rendezvous point.
It's time to look at the industry standard
equivalent, which is BSR, or Bootstrap Router.
Now, since BSR is an industry standard,
they had the ability to actually update PIM in order
to support this solution.
Therefore, BSR actually requires PIM version 2.
Auto-RP was, of course, available in PIM version 1,
but PIM version 2 was updated to carry BSR's information.
Now, like auto-RP, it's another way
to automatically find the rendezvous point,
but the messaging is built into PIM itself.
Now, it does still have two moving parts--
we still have the candidate RPs, which are, of course,
the routers that are willing to be
the RPs for either all of the multicast groups,
or a subset of those groups.
Then we have the equivalent of the mapping agent,
but in this case, it's the BSR.
The protocol itself is named after the router
that's sort of acting like the mapping agent.
Now, the reason I say sort of acting like the mapping
agent is here is where the functionality really
gets different.
In BSR, well, the BSR doesn't actually
choose the winning rendezvous point.
Now, we'll see this more when we get to redundant RPs in BSR,
but for now, let's just go ahead and get
BSR set up and configured.
We're going to be configuring this the same way
we did auto-RP.
So let's just jump into our topology real quick,
take a look at what we're going to be setting up,
and then jump into the command line,
and get BSR working exactly the same way that we did auto-RP.
So we are still on multicast topology 1,
but here's what's going to change.
Router 2 is still going to be a candidate RP,
but this time for BSR.
And that means that router 5 is no longer a mapping agent,
it is now the BSR, or the Bootstrap Router.
So at the end of this, this should be functioning exactly
the same as auto-RP did.
Now, in the interest of time, just so you're aware,
I have already removed auto-RP from the environment.
We'll start by verifying that, but none
of the routers at this point have any RP configured at all.
Therefore, our data plane is also currently not working.
So as we go through this demonstration,
we are going to have to start up router 10 as the source again,
and have that start sending traffic
and rebuild the data plane once everybody has learned
what the new is through BSR.
So that said, let's go ahead and jump into the command line
and get this configured.
So let's begin with our show IP PIM RP map.
We'll send that to all of the routers.
And as we can see here on router 1,
there are currently no Group-to-RP Mappings.
We should see this on all of the routers.
Router 2 also has no information,
neither does router 3, router 4, router 5, router 6,
and router 7.
8, 9, and 10, of course, are not running PIM,
so they wouldn't have any information at this point
anyway.
So none of the devices have any information about the RP
at this point.
Let's go ahead and go on to router 2
and configure it to be a candidate RP for BSR.
So once again, if we do a show pim interface,
notice that our loopback is still enabled for multicast.
I only removed auto-RP, I didn't unconfigure
any of our interfaces.
So the loopback is good to go, all
we have to do is go into configuration mode,
enter router pim for ipv4, then we configure bsr candidate.
And notice if we hit the question mark,
we can either set this to be a candidate-bsr
or a candidate-rp.
But we're going for the candidate-rp.
As you can see here, unlike auto-RP on IOS XR,
this is not looking for an interface.
This actually wants us to simply put in an IP address.
So we'll simply put in the address for the loopback
interface.
There are some other choices here
much like what we had on our autoconfiguration.
Again, we could configure this for bidirectional.
We could filter this using a group so that it's only
an RP for certain groups.
We could change the interval.
And something else that we can do here is set the priority.
We'll look at that actually in our next video
when we do redundancy.
So for now, let's just hit Enter, commit those changes,
and exit configuration.
Now, let's go configure the BSR.
So this is going to be, again, on router 5.
We'll simply go into configuration mode.
And the command here is ip pim bsr-candidate.
Now, on this device, it does want an interface.
So again, it's going to be loopback 0.
However, notice that the only other thing
to put after this is the hash mask length.
Notice that it says that this is for RP selection.
This is going to come into play when we have
more than one candidate-rp.
So again, our next section is going
to be on redundancy with BSR.
We'll cover this then.
For now, we're just going to hit Enter and exit configuration.
Notice that we almost immediately
see that line protocol come up on tunnel 0, indicating we've
learned an RP.
We can, of course, verify that with a show ip pim rp map,
and what we see here is for the entire multicast group range,
the RP has been configured as 10.2.2.2, the info
source for that is, again, router 2 because we're
on the BSR.
Notice it says right up here that this system
is the bootstrap router.
We learned it via bootstrap, it currently
has a priority of 192, and, of course, we
see the whole time of 150 there that could also be configured.
Of course, if we look at this on any router that's not the BSR,
so again, let's say router 6, we see
that, again, it knows the RP, but notice the info source now.
The info source is now router 5, which is the BSR.
Now, the rest of this information
is fairly similar, of course, to what router 5 had,
and let's use our command window again to verify this
on all of the routers.
So we'll just redo our show ip pim rp map.
Again, we've already seen it here on router 6,
but let's go over and start looking at these from router 1.
So router 1, we see that it's now properly learned the RP.
Router 2 has as well.
So has router 3.
So has router 4.
We already looked at 5 and 6.
So if we jump over to 7, we see that 7 has it as well.
And of course, 8, 9, and 10 won't because they're not
participating in PIM itself.
So now that everybody's learned the RP,
we should be able to start our data plane again and have
this work.
So let's go start up our ping again on router 10.
So we'll start our ping.
And then let's go over to router 7 and do some verification.
So we'll just start with a show ip mroute.
So first, of course, we see that we have the star comma G entry
with the correct RP 10.2.2.2 , and we've learned the S,G
entry.
Given this information, this should indicate that the data
plane is working properly because, again,
I wouldn't have an S,G entry if the first packet hadn't gotten
to router 7.
So if I repeat this command and I put the count on it,
once again, we should see that it has currently
forwarded 32 packets.
And if we give it just a second, it's now forwarded 37.
Just as another quick side note here on this count output,
if you see where it says, packets forwarded--
42, but yet on the source tree, it's only forwarding 37, well,
notice that 5 were actually forwarded down
the RP-tree or the rendezvous point tree,
meaning the shared tree.
So what that really means is that 5 packets came down
the shared tree before it did the switch over
to the source tree.
That's all that really means.
But if you add up the 37 and the 5,
that's the total of the 42 packets
that have come through on this group route as a total.
One other thing to note, by the way, on the show ip mroute,
notice that yes, we are still a member of the 224.0.1.40
group for auto-RP, just because that's automatically
listened for on Cisco routers.
But notice that no other special groups
have been joined because all of this information
actually travels inside of PIM itself.
So in this video, we saw how to configure
BSR to automatically announce the rendezvous
point into our environment.
Now, as we saw, it's actually very similar to auto-RP,
except it doesn't need those extra groups to function
since it just uses PIM itself.
Now, that does mean that it requires PIM version 2,
but that's really not an issue since all of our devices
default to PIM version 2 anyway.
Now, just like before, BSR is up and running and working
and everything's fine, however, we
haven't looked at redundancy.
And that's exactly what we're going to do next.
Till then, I hope this has been informative for you,
and I'd like to thank you for viewing.