In the previous video I mentioned that in auto RP you have to have at
least two routers playing two special roles, one called an RP candidate
and one called an mapping agent.
And I said that one router could play both roles, theoretically, but it's
better to split them apart on a different router so you have a little
bit more resiliency, a little bit more redundancy in case the router fails.
So let's start by looking at more details of the RP candidates.
So I mentioned how RP candidates send out messages called RP announcements.
And it's within these RP announcements that they say, hey, I would like
to be an RP for this particular group.
So those RP announcements are actually encapsulated in UDP.
And they use UDP port number 496.
I know you might come across some certification someday that asks you
a nitty gritty detail like that.
And even after it's initially sent, it's reset every 60 seconds, right,
because maybe this RP was not the one that was elected, but he still wants
to make himself known in case the elected RP goes away.
So it's reset every 60 seconds.
And it's sent to a special address of 224.0.1.39.
We saw this in the previous section, this is a reserved address.
Now, if I now only mapping agents pay attention to this, what do I mean
by pay attention to it?
Well, if a router, for example, let's say that this router, let's get
rid of that. Let's say that this router here was the RP candidate.
And so we're assuming here that all these interfaces are in the same way.
So he sends out via dense mode, he floods his RP announce messages.
And that's going to 239.
No, not 239.224.0.1.39.
Now, let's say that our mapping agent was over here.
Router two. So what's router eight going to do with this message?
Because after all, he can't really look at it to see if this guy's an
RP. And you might say, well, he'll just silently pass it on, right?
He'll just transparently pass it.
Well, but the problem with that is the rules of PIM state that you cannot
forward a multicast message without creating multicast state.
You can't just forward it.
Even in dense mode, you still have to create some sort of state in the
multicast routing table.
So when router eight receives this message, he's actually going to do
two things. He's going to create an s, entry because he does know the
source. The source is coming from router three.
He knows the group 2201.39.
So he will create an s, entry.
He'll also create a star, entry because that's required when you've got
an s, entry. And the outgoing interface list, remember when you've got
both a star, and an s, entry, the s, entry is typically the one that's
actually used for forwarding.
So whatever is in the outgoing interface list of the s, that's what we
use to forward packets.
So in this particular case, in router eight, when he creates his s, he's
going to say, all right, well, all of my interfaces are in sparse dense
mode, except for the one where I receive this packet is what I'm going
to put into my outgoing interface list.
So in his s, entry, you'll see that zero one and zero zero dot you know,
flood this RP announced message.
But if you at this point in time, if you actually look in him, you say,
okay, who's your RP?
Who's your RP? He'll say, I don't know.
He doesn't know because he can't actually look at this message to decide
who his RP should be.
That message has to get to the mapping agent.
And then the mapping agent will send an RP discover message.
And that's what router eight can use to figure out what RP he's going
to select. So within this RP announcement, and I'm actually going to do
a sniffer trace of this in just a second so you can see it, it contains
the address of the RP, you know, his unicast IP address, what groups he's
saying that he's capable of being the RP for, which by default is everything.
Everything beginning with one one one zero and binary.
And his whole time.
So how do I make a router an RP candidate with this command?
IP PIMS send dash RP dash announced.
And then interface.
And the interface you select here like fast ethernet zero zero, serial
one one, whatever.
This interface command here is going to actually control the source address
that he selects for those RP announced messages, the source address.
Why do we care? Well, the reason why we care is because this is what the
mapping agent uses to figure out who the best router is.
So if a mapping agent receives two or more RP announced messages from
two routers and they're advertising their capability to be the RP for
the exact same groups, the mapping agent will simply say, okay, whichever
one of you has the highest IP address, you're the winner.
You're the one I'm going to tell everybody about.
So this is how you can influence that by on the actual RP itself specifying
the interface, they'll be higher or lower than other routers that you're
configuring this for.
Scope, this basically controls the TTL.
So how far this RP announced message can go.
And it's not optional.
You have to set it, non optional keyword.
What is optional is the group list.
So this gives you the ability to say, okay, instead of being the RP for
everything, I only want you to be the RP for certain groups.
Now there's something actually kind of interesting about this.
And I'm going to show it to you rather than tell you I'm just going to
do it. So in order to replicate this and just do a quick snipper trace
of it, step number one is I have to go to all my interfaces right here
and configure them for sparse dense mode.
So let's just do that and then we'll go to the other side.
Okay, so that's all we need on him.
Go to router eight.
Okay, he's done.
Let's go on router three.
Oh, and while I'm here, let me delete my static here.
Okay, almost done here.
Okay, so we're all set up.
Everything's in sparse dense mode now.
Okay, so let's see here.
Let's go ahead and just continue with having router three be the RP.
So now we're going to configure him to send those RP announced messages.
Now before I do that, let's just go ahead and capture this in a little
bit. And according to my physical topology, R3, 01 is port 0 slash six
on the switch. All right, so ready to go.
So let's go back to R3.
And what I'm going to do is I'm actually going to configure R3 instead
of announcing his capability for everything.
I'm going to say, I only want you to announce yourself as a potential
RP for anything in the 238 range and specifically say you're not the RP
for the 239 range.
And there's a reason I'm doing this.
I'll show you. So let's do this.
Okay, access dash list one deny 239.
And you don't have to worry about the implicit deny at the end of the
access list. That does not affect this particular feature.
So this feature only looks at what you specifically configured as permits
or denies. And now I say IPPIM send dash RP announce.
Okay. And now I say, okay, what do I want your source interface to be?
Well, we'll just have it be fast ethernet zero slash zero.
Scope. I will just put it as like 100 hops.
And now I'm going to say group list in reference to access list one.
Now before I hit the enter key, let's do a snipper trace to see what his
message looks like.
Okay, so there's the RP announce.
Okay, so there it is.
Not sure why he sent two of them.
Oh, wait a second.
I think I know why.
Let's see here. Let's just check the source MAC address.
So this one has a source MAC address of five AC nine.
Seven C C zero. Yeah, so this is actually seven C C zero.
And I think if I go to router eight.
Let's see here. zero zero dot 83.
Seven C C zero. That what we saw in the router three.
Yes, seven C C zero.
So what we're actually seeing here, this is kind of interesting that in
the whiteboard when router three sent his RP announce.
Actually, what router eight did is he not selected it back.
I'm not sure why they do that.
But so we actually saw it coming back.
That's why it looks like it's it's the exact same message.
But one has a source MAC of router three.
One has a source MAC of router eight.
That's why it's showing up twice in the snipper trace here.
But the main thing I wanted to show you was the body of the message.
So notice it's encapsulated in UDP port 496.
And then we have the Cisco auto RP behind that.
And here's what I want to show you.
He says here's my IP address three four three three.
And I'm specifically telling you about two groups.
He says number one, the 238 group.
This is a positive group prefix.
This is his way of saying, Hey, mapping agent.
I would like to be the RP for everything beginning with 238.
So hopefully you'll elect me.
But down down here, 239, we have a negative group prefix.
Now you might just think, well, why is he even had that in there at all?
I mean, if he doesn't want to be the RP for 239, why not just exclude
that and just included 238?
And anything that he doesn't include, he'll just be implicitly assumed
that he doesn't want to be the RP for the rest of that stuff.
Well, that's kind of the way that's working.
For example, in this particular case, the no routers in my domain will
ever use this guy for 237, 236, 224, 225.
They will only learn that he wants to be the RP for everything beginning
with 238. So why is he including this negative group prefix?
This is actually kind of interesting what happens here.
What this is saying is he saying, Hey, everybody, everywhere, all PIM
routers, the 239 prefix must be used in dense mode.
We will not have any RP for 239.
So if you ever get an actual multicast dream going to 239 dot something,
flood it via dense mode, don't look for an RP because there's no RP that's
servicing it. Now, you might be thinking yourself, well, okay, but what
if I configure this command on another router?
And on that router, I say, you can be the RP for the 239 group.
Will that override this?
No, it will not.
This overrides that.
So if a router sends out a network, it basically forces the entire domain
to use dense mode for this particular group.
Now, why you'd want to do that?
I don't know, but I just want to point out that's how that works.
So be very careful if you're using access lists along with your RP announced
command, like I did right here.
Be very careful if you've got any deny statements in that access list,
because that's what's going to happen.
That particular group will now be forced to use dense mode and you might
end up with flooding that you did not intend.
Now, John points out that 239, according to the Internet Assigned Numbers
Authority, was the range for source specific multicast.
That's true. But remember, these are all recommendations, right?
A router will not say, oh, 239, I'm only going to accept that if that
source specific multicast.
That's just a recommendation by the Internet Assigned Numbers Authority.
Nothing preventing you from using IGMP version 2, not doing source specific
multicast and still using 239.something as your multicast streams.
That's all just recommendations.