Up until this point in time, all of the videos I've done so far and all
the lab demonstrations I've done have been utilizing a static rendezvous
point where every single router had a static RP configured, which is fine,
it works, it's acceptable, but main downside to it is what if that rendezvous
point crashes and goes away.
Now multicast will not work at all in my network.
So for this reason, if you're actually going to implement multicast in
your network, you probably want to implement some sort of dynamic way
of discovering rendezvous points.
And using that same dynamic way, if a rendezvous point fails, you can
now switch over to a different rendezvous point.
So autorp is one way that you can do that.
So let's start by talking about autorp.
So autorp provides a method for dynamically learning of rendezvous points
and provides for rendezvous point redundancy.
It is Cisco proprietary.
It's pretty old.
Autorp actually was developed when PIM version one came out.
So as soon as the RSC for PIM version one came out, Cisco developed this
to provide for RP redundancy and dynamic learning.
So within autorp, routers play one of three roles.
You have RP candidates, so like the name suggests, these are routers that
are advertising their capability of being rendezvous points.
You have something called a mapping agent, which sort of collects all
of those advertisements.
And so the mapping agent's job then to create a message which he disperses
to everybody else, which I call others.
That's just my name for it.
And all the routers listen to this message from the mapping agent.
And that's how they learn who the rendezvous point is.
So in Cisco developed this, they reserved two special multicast addresses
for this purpose, and they're talking about PIM with the exception of
register messages, which were unicast, all of your PIM multicast messages
like joins and prunes and hellos, all were in the 224.00 range.
And remember I said that according to the Internet Assigned Numbers Authority,
that was called the link local multicast scope.
The any multicast packet going out to 224.00 was only meant to stay on
the local link. It could not be routed.
Well, no, that's not the case here, right?
This is using 224.0.1.
So when auto RP routers, either candidates or mapping agents, could use
these to create their messages, it will actually go through routers will
process it, but then they will continue to forward the message as well.
And we're going to talk more about that in detail.
So let's talk just a real high level of RP candidates, and then we'll
drill down into the details a little bit later.
So RP candidates must be manually configured.
A router does not just automatically assume it could be a rendezvous point.
So there's a command.
You have to type in to get to realize that.
Once you type in that command, then it will send out special messages
called RP announce messages.
And I'll actually show you this in a few minutes.
So if you type in RP candidate, it's RP announced message will say, I
want to be the RP for everything.
Everything beginning with 1110, you know, those first four bits, which
is the entire class D range.
Now, as part of the command to get the router to believe he's an RP candidate,
you can optionally tell the router, no, when you send out your RP announced
messages, I only want you to say you're capable for a particular range,
a group range like maybe the 224s and 225s.
I'll have another RP out there announce his capability for the 226s through
the 239s. You can optionally do that, but by default, they don't.
They say, I'm going to be the RP for everything.
Now, so those RP announced messages go out.
Router is between the rendezvous point and the mapping agent will get
those messages. But they will just, they will just sort of forward them
on through. It gets a little bit more complicated than that.
But the routers in the middle, what I call the other routers, do not listen
to the RP announced messages to say, Oh, there's a rendezvous point out
there. They don't listen to that.
It's sort of like, here's an analogy.
Think of the world of switching of VTP, right, the VLAN trunking protocol.
Think of a VTP transparent switch, right?
A VTP message can come into a transparent switch.
He'll check a couple things, make sure the domain name is okay, the password's
okay. And if those basic things check out, then he'll transparently pass
it on through. But that VTP message is saying, do something.
Create a new VLAN.
Delete an old VLAN.
The transparent switch will not do that.
He doesn't look at the instructions.
He just passes it on through.
Same type of thing here.
Rodders that are not mapping agents, when they get an RP announced message,
they just sort of pass it on through to make sure that eventually it can
get to the mapping agent.
So the mapping agent is actually the one who's listening for these RP
announcements and will actually process it in his CPU.
So if more than one rendezvous point announces his capability for the
same group, it's the mapping agent's job to elect the best one.
So this is a critical point here.
If I'm one of these other routers that's not an RP, not a mapping agent,
I'm just sitting there, running regular PIM, I'm not going to learn about
all the potential RPs out there.
I'm only going to learn about the rendezvous points that the mapping agent
decided were the best ones.
So that's a, now the other protocol we're going to talk about BSR is not
like that. But auto RP is.
The mapping agent has this very critical role that's his job to figure
out who the best rendezvous points are.
And we'll talk about how he does that.
And so the mapping agent sends out another message called the RP-discovery
message. And this is the one where he says, okay, everybody, here's the
rendezvous points I've elected for each specific group.
So we talked about in some of the earlier videos that that a router can
only know about one RP for any given group.
In other words, it would confuse a router for router, said, okay, I just
received a join for 225.777 and there's two RPs out there who are capable
of servicing that group.
Which one do I send my star comma G join to?
To both of them, to one of them?
So that's why in PIM it says no.
A router can only know of one RP for any given group.
So this is how that's accomplished in auto RP.
The mapping agent says, okay, I'll do that job for you.
I'll elect the best ones and then send you a list of the best ones within
this RP-discovery message.
Now if you want to, like this says, you could configure one router to
be both the RP candidate and the mapping agent, nothing wrong with that.
Kind of taking away your redundancy and your resiliency though, right?
Because if that one router crashes, you got a problem.
So usually it's a better idea to separate them onto different devices.
PIM dense mode is used to propagate these messages, RP announced and RP
discovery. This is a critical factor here.
This means that when you use sparse -dense mode, I'll show you what that
looks like. Just basically go to a router, go to one of his interfaces,
and you say IPPIM sparse-dense-mode.
And that's the mode you're going to use to do auto RP.
And what's going to happen here is that when a router receives an RP announced
message or an RP discover messages, he's going to flood that via dense
mode. That's what dense mode is going to be used for.
And hopefully, sparse mode will be used for the actual building of your
multicast distribution trees and the forwarding of your multicast data.
I say hopefully because sometimes that might not happen.
And I'll talk about that in a little bit.
Interfaces typically have to be in sparse dense mode in order to work
with auto RP so they can propagate these various RP announcements and
RP discover messages that auto RP uses.
And there can be situations where you don't want that, where you don't
want that to be used for the dense mode portion of sparse dense because
we know that dense mode is used for flooding.
And after all, that's why we use sparse mode because we don't want flooding.
So in a little bit, I'll talk a little bit more about why that could be
a problem in a way you can get around it.
But one way is this, you can configure the IPPIM auto RP listener command
and that should allow you just to stay in sparse mode and still work with