So let's start digging a little bit deeper into the details of the pin
bootstrap router protocol, starting with the election process.
So we know that only one router can actually be the bootstrap router,
and it's the bootstrap router's job to let all the other routers know
who the rendezvous points are.
So how is that elected?
Well it's elected by this flooding of bootstrap messages.
We'll actually see this in just a minute.
That's the actual type of PIM message.
So before we've seen PIM registers, we've seen PIM hello's, we've seen
PIM joins. Now we're going to see another type of PIM message in our sniffer
trace called a bootstrap message.
These go out to the same addresses, hello's 2240013.
So it's because it's got that link local scope.
It has to be replicated by each router along the hop so it can get all
the way out. And so the bootstrap router, if there's two or more routers
who are candidate BSRs.
The one that's the winner is either the one with the highest priority,
now the priority is 0 by default, but you can raise that all the way up
to 255 if you want, or the one with the highest IP address.
That will be the winner.
Now with PIM BSR, a preemption is on by default.
So what that means is if I currently have a router serving as my BSR,
and let's say his IP address is 2.2.2.2.
And he's been serving as the BSR for the last six months.
If I put another router into the network, configure him as a candidate
BSR, and his IP address is higher, he will take over the role of being
the BSR. It's not like it sticks with one particular router.
So this is how we configure the candidate BSR.
IPPIM BSR-candidate, and then just like our auto RP, we want to specify
an interface that would be used as the source IP address of our messages.
Then you can specify a hash mask length.
I'll get into that in the very last video here.
We'll talk a little bit about that, but by default at 0.
And then optionally you can specify the priority.
Like I said, the priority is 0 if you leave it alone.
So that's how you configure the candidate BSR.
How do I configure the candidate RPs?
Well, an auto RP, that was, do you remember?
What was the command in auto RP to specify candidate RP?
Well, hopefully the command that came to your mind was IPPIM RP-send-announce.
RP-send-announce.
That's how you configure the candidate RP in the world of auto RP.
Well, in the world of BSR, it's IPPIM RP-candidate.
So I can definitely see this as being a question on some test.
They can give you both ones and say which one is used by auto RP, which
one is used by BSR.
So definitely when I have that straight.
Same thing here.
The RP candidate, you have to specify an interface to say what his source
IP address is going to be.
And at that point, you could just hit enter and leave it alone.
And he will announce his RP candidacy as a candidate for all multicast
groups. But just like auto RP, you could reference an access list to say
which particular groups he's going to announce his candidacy for.
And you can specify a priority.
And I'll talk a little bit more about the priority here in just a little
bit. Now how do I monitor this?
Show IPPIM BSR and show IPPIM RP mapping.
That same command show IPPIM RP mapping is also what we used to monitor
auto RP as well.
So that command works both ways.
Now before I actually configure this and we get it running, let's actually,
well, let's go ahead and do it.
I'll do a snipper trace and then we'll look at that and we'll come back
to these slides here.
All right, so we're going to go into, let's see here.
Let's take off some of our auto RP stuff right now because we don't need
both. So I'm going to start by converting all of my interfaces back to
sparse mode, which does away with all that potential flooding I was concerned
about. 0001. Okay.
What we got here?
This is zero slash zero.
Okay. And this guy here do show run section PIM.
Let's get rid of this because we're not doing auto RP anymore.
Okay, let's go to router eight.
And right now this guy I believe is configures our mapping agent.
So let's get rid of that because that's for auto RP.
Now we just have to go to router four.
Okay, so everybody's configured at this point.
We're back to sparse mode, but we haven't configured any BSR stuff yet.
So let's start by configuring, let's see here.
Why don't we have router four and router eight both contend to be BSR.
So we'll configure both routers as candidate BSRs.
And we'll just rely on, we'll use priority to make the decision about
who the winner is.
So I will give router four the higher priority than router eight.
On router eight I won't even configure the priority at all.
So let's start with router four since we're here.
IP PIM BSR dash candidate.
And we'll just select, I don't know, serial zero slash one slash zero
as a source IP address.
We'll leave the default hash mask.
And notice that if you want to get to the priority, you have to specify
the hash mask. Now I know that right now you're saying what is a hash
mask? You haven't explained that yet.
Well, we'll get to that.
But now I'm going to do the priority list, do a priority of 40.
Okay, and before I do any of this stuff I want to start doing some sniffer
traces here. So let's just capture on, what do we want to capture here?
Our four's fastestion at zero zero, which is zero seven on the switch.
Okay, anything that goes in or out of that.
How about our eight zero zero and zero one?
That's going to be zero two and zero thirteen.
And that should do it.
Let's see here. And we're going to have router three be the candidate
RP. I'm already capturing on zero zero so that should capture his messages
as well when we get around to him.
All right, so let's go to the switch here.
Before I do this.
Let's go to the switch.
Okay, so it's going to be zero slash two, fastestion at zero slash seven
and fastestion at zero slash thirteen.
Okay, so let's go back to router four.
Okay, let's start the sniffer trace.
Okay, so we can see a whole bunch of bootstrap messages.
And the reason why we're seeing a lot of these is because I'm capturing
on multiple interfaces so we're seeing them coming in.
We're seeing them going out.
We're seeing them being forwarded.
It's really just one message though.
So if I open it up a little bit.
So notice it's carried in PIM because this is another PIM message type,
message type four bootstrap.
And it's pretty simple in this case.
He's saying that this is the bootstrap router.
I wish to be the bootstrap router.
This is router four right now, two dot four dot two dot four.
And we've given him a priority of forty.
And now we'll go ahead and configure a similar command on router eight.
But we'll just give him a lower priority.
We'll just leave him like that.
So now they're both sending out BSR messages and they will continue to
do so. It's not like one is going to stop.
In the world of some protocols like spanning tree, for example, once everybody
knows who the root bridge is, it's just the root bridge's job to send
out BPDUs periodically and everybody else is quiet.
Not so with BSR.
In this particular case, let's just keep capturing a few of these here.
That's probably enough.
We didn't get any bootstrap messages yet.
Let's keep going.
Okay, here's some bootstrap messages.
Two four, two four, two four.
So what's happening in this particular case is that it looks like we missed,
I didn't capture the bootstrap message that was sent from router eight.
But it's quite possible that as soon as I hit the command on router eight,
before he even had a chance to create his own bootstrap message, he may
have received the incoming bootstrap message from router four, and he
may have just realized, oh, router four is better than me.
He's got a higher priority than me, so I'm not even going to create my
own. I will just forward his.
So all of these have router four's name or ID in the BSR field.
But I could change that.
Actually, let's go to router eight and give him a priority of 50, and
we'll see how that changes over.
All right, let's start it again.
Come on, wire shark.
All right, and all those fails.
Start it over. Okay.
Now I can't even stop the snipper trace.
Nice. There we go.
Okay, so here we see the bootstrap router is being advertised as eight
dot two dot eight dot eight.
Now, because I'm capturing on multiple interfaces, we don't really know
if this is the bootstrap message that originated on router eight, or if
this is just one that was fine.
So we're forwarded by another router.
But we don't even see here is a, well, here's router four, three dot four
dot three dot four.
That's the IP address of router four.
So based on the fact that that's his source address, we can see he is
forwarding the bootstrap message from router eight.
So we don't even see the bootstrap message from router four anymore.
He's taken his name out of there, and everybody now realizes that router
eight is the BSR, by virtue of the higher priority.
Now the last piece of the puzzle here is to make a router a candidate
RP. So we'll just go back to our friend router three.
And we'll do that IPPIM RP-Canada, fast ethernet zero slash one.
And I'm not going to change the priority or anything like that.
I will change the interval so they go out more frequently.
Let's start this up again.
Okay, so this is what I wanted to point out.
There we go. Okay.
So a router serving as the RP candidate in PIMBSR won't even talk.
He won't even send an RP advertisement, and we see it here, it's called
an RP candidate.
Candidate RP advertisement.
He won't even send that until he knows who the bootstrap router is.
Now why is that?
Well because, take a look at this message.
This is not multicast.
This is unicast.
So the candidate RP's, once they know who the BSR is, they actually send
a unicast RP advertisement directly to the BSR.
And clearly they could not do that if they didn't know beforehand who
the BSR is. So here he's sending it to the BSR.
And we can see he says, here's my name.
I want to be the RP for everything.
And then... So let's see here was the very first one.
And so this now, so now our bootstrap message from the BSR not only contains
his identifier, his name, but also contains that information about that
rendezvous point.
Now before I go a little bit further, let's go back to the slides because
I don't want to get too far ahead of myself.
Okay, so we've seen that the BSR send what's called bootstrap messages.
Now here's a big difference between this and auto RP.
In the world of auto RP, the mapping agent was responsible for collecting
all of the RP announced messages and the mapping agent elected the best
RP for any given group.
So all the other routers out there, they didn't necessarily know the full
range of RP's. All they knew about was the RP's that the mapping agent
had elected. PIMBSR is not like that.
In PIMBSR, the idea is all of the RP's unicastor information to the BSR,
the BSR gathers them all into a combined list in that bootstrap message
and then he sends it out.
So every router in the network knows about every single BSR.
Not every single BSR, every single rendezvous point.
So if I'm a router sitting somewhere in the network and I say, okay, I've
just received a bootstrap message from the BSR and inside there, there's
a list of four different rendezvous points, all servicing the exact same
group. Well, we know that our, that PIM can't do that.
PIM can only use one.
So instead of like an auto RP where one router made that decision, the
mapping agent said, I'm going to tell you who you should use.
In this case, it's up to every router individually.
Every router when they receive these incoming bootstrap messages, if they
see two or more routers in there servicing the same group, each router
will independently elect for themselves which RP they want to use for
any given group.
Now, I'll go into more details about that in a little bit, but we saw
a little bit of a, a little bit of a preview of that because when we looked
at our, let's go back.
Actually, let's go forward a little bit.
So this is the bootstrap message.
We saw that in the snipper trace.
Generated by BSRs goes to 220,000, 13.
Contains a listing of all known rendezvous points.
So the BSR does not discriminate.
He just collects them all, puts them in that bootstrap message.
So notice in this particular message here, and this will save me from
having to do this in the lab.
Notice that in this particular message, the bootstrap router says, okay,
I'm telling you about two BSRs.
So both of these BSRs are servicing the exact same group.
220, you know, the entire multicast range.
So there's two rendezvous points I'm telling you about.
And it says, okay, the priority for the first rendezvous point, 2722 is
20. The priority for the second rendezvous point is 30.
So I think that gives you a little bit of a hint.
In this particular case, priority wins.
The highest priority, so all routers who receive this will elect for themselves
3.7.3.3 as their rendezvous point because it's got the higher priority
than 2.7.2. And I looked this up because I was just curious, you know,
whenever I see sniffer traces, I'm always curious about every single little
field and what it means, not that you probably ever need to know this
for any kind of test or anything, but FRP.
What's that? For those of you like me who like to know this kind of stuff,
that stands for fragment RP count.
What that's referring to is you'd have to have a lot of RPs to make this
happen, but there's a possibility that let's say you've got, I don't know,
100 RPs or 100 potential RPs in your network.
And the full listing of them just won't fit inside of a single bootstrap
message. Well, in that case, that bootstrap message could be fragmented,
put into multiple IP packets, and so the FRP count gives sort of a clue
as to, okay, there's other fragments coming.
There's more RPs than what I'm sending you in just this one bootstrap
message. Look for some other ones as well.
So that's sort of an indicator to the receiving routers about that.
Probably won't see that used very often, because like I said, you'd have
to have a lot of potential RPs.
To fill it up so big that it won't fit into a single packet.
And the fragment tag, that's used by the same thing.
So a fragment tag is sort of like, think about the IP header of an IPv4
packet. There's the ID field, right?
So if that IP packet has to be fragmented, every single fragment will
have the exact same ID number as the original packet.
That way they can all be sort of, when receivers receive these fragments,
they can say, oh, okay, I know this is all part of one coherent whole
packet. This is the same type of thing.
If a bootstrap message has to be fragmented, they will all contain the
same fragment tag.
Okay? Okay, so this is the RP candidate messages.
We looked at that in the snippet trace.
We saw how they are unicasted.
It includes a priority.
Uses PIM as the transport protocol.
So behind the IP header we saw this was carried in PIM.
And once again, here's an example of one of those.
And we already saw this in the wire shark snipper capture.
Now let's go to, at this point, because I have everything configured,
let's go to router two, who has received these bootstrap messages.
And we're going to use the same command we used in auto RP, show IP PIM
RP mapping. And we can see.
It says, now in this case, I only have a single RP, so there's not a lot
here. But if I had configured two or three or four candidate RP, so as
a matter of fact, let's do that.
Because a bootstrap router could also be a candidate RP at the same time.
So let's go to router four and configure him as a candidate RP as well.
RP-candidate. Okay, so now when we go to router two.
Okay, so now we see all the rendezvous points, right?
Because they were all contained in that single bootstrap message.
And it's saying either one of these could be a potential candidate for
the entire multicast range.
Now looking at just this output right now, there's no way for you to predict
just from this command, which router will actually be used.
So if this guy needs to send a register or a join message, is he going
to use two four or two four, or is he going to use eight three, eight
three, because they both have exactly the same priority?
Well, from this, you can't tell.