So in the previous video, we looked at how to configure a router to advertise
its capability of being a candidate RP and send out these RP-announced
messages. But those messages don't do any good unless there's another
router playing the role of the mapping agent who can collect all of them.
And then from all the messages he gets, elect which RP is going to be
the RP for any particular group.
So now we're going to talk about that, the mapping agent.
So they collect those RP-announced messages and elect an RP for each group.
And it's just simply whoever has the highest IP address.
That's the winner.
You may remember that back when I configured my command for the RP candidate,
if I make this a little bit bigger here, nothing in here for priority.
So there's no priority.
It's simply highest IP address is the winner for any given group.
So the mapping agent will then, after it elects each RP for a given group
as the winner, it will put those into an RP discovery message and send
those out to the address of 224.0.1.40.
Also encapsulate in UDP.
And notice all PIM routers automatically listen to this group.
So you may have noticed if you're watching my labs in all the previous
videos on PIMS sparse mode, that as soon as I configured sparse mode on
any interface, and I enabled multicast routing globally automatically
without doing anything, every router started listening to 224.0.1.40.
So Cisco routers by default are listening for RP discovery messages without
you doing anything.
And just like the RP announced messages, these are sent out as dense mode.
They're flooded via dense mode.
So here's actually the body.
Here's actually a sniffer trace of what the RP discover message looks
like. They show up as RP mapping messages.
And they'll say in here, they'll say, okay, here's the RP's.
And notice this looks pretty much almost identical to the RP announced
message that we just saw.
It's a different packet type, RP mapping, but the body of it is pretty
much the same. It's listing, you know, who's the RP, what group, and is
that group a positive or a negative prefix?
But whereas there might be six or seven potential RP's out there all wanted
to be the RP for 224.0.
Everything, only one of them will be the winner.
And only the winner will be in this message right here.
And this is what routers are listening for to select which RP they're
going to use. So to configure routers, the mapping agent is the IPPIM
send RP discovery command.
And how do we verify on the router that is the mapping agent that he knows
that he's supposed to do that?
Well, show IPPIM RP mapping.
And I'll actually say this system is an RP mapping agent.
Now another sort of gotcha or thing to be aware of is that while there
is an election of which router can be a rendezvous point for any given
group, there is no such election when it comes to mapping agents.
So you might think, okay, well, I'm actually going to configure two or
three routers in my company as mapping agents.
So if one fails, all the other routers out there can listen to the other
one. You can do that, but be aware of this.
Every router that configures a mapping agent is going to be sending out
these RP discover messages.
And so for that reason, the mapping agents have to be configured identically.
And every mapping agent has to be able to receive these RP announced messages
from every RP. Because what could happen is, you know, imagine for a second
that you've got two mapping agents here.
And there's two different RP's, okay, RPA and RPB.
And they're both announcing their candidacy for the exact same group.
They're both saying, I want to be the RP for everything.
Okay, let's say that.
So ideally, both of those RP's would be learned by the first mapping agent.
Both of those RP's would be learned by the second mapping agent.
So when those mapping agents send out their messages, they look identical.
They've got the same elected RP's inside of them.
But what happens if they don't?
What happens if mapping agent number one, for some reason can't hear this
RP over here? There's some sort of filter or access list or something
and he's not getting that RP announced message.
And just the opposite of mapping agent number two, he can't hear that
RP. So now you've got mapping agents that we now in our network, as a
router, as a normal router, I'm getting two RP discovery messages from
two different mapping agents, which normally would not be a problem.
But here's my issue.
As one comes in, it says, oh, here, you should use the RP of 1.1.1.1.
He should be your RP for everything.
So I say, okay, and I start registering with him or I start sending my
joins to him. And then a split second later, I get another discovery message
that says, oh, you should use router 2.2.2 as your RP for everything.
Well, now it's going to happen.
I'm going to start flip flopping between them.
I'm going to be tearing down trees, sending joins up other trees, and
it's going to totally mess with my multicast.
So that's why if you have two or more mapping agents, the information
they're containing inside their discover packets has to be identical.
Otherwise, you could get really weird behavior within your network.
Now, in the PIMS sparse mode section, I talked about how one potential
threat to a network could be that the rendezvous point will accept incoming
register messages from anybody.
He doesn't discriminate.
And I showed you a command where I could say, okay, only these authorized
routers are actually allowed to send the RP register messages.
Well, something similar could happen here.
There's nothing by default to prevent somebody from inserting a rogue
router into the network, configuring it as a candidate RP, configuring
it with a really high IP address, like what happens if they configure
a loopback address with the highest unit cast address possible?
223.255, 255, 254.
The address just beneath the class D range.
Well, that rogue router will probably be elected as the RP over anything
else. And so now everybody will be pointing the traffic to him and that
could really screw up your multicast.
So we need to have some way of saying, okay, mapping agent, you're only
allowed to receive incoming RP announced messages from certain authorized
candidate RP's. And that's what we're looking at right here when we talk
about auto RP filters.
So you can configure the mapping agent in one of several ways.
You can do only from certain authorized RP's or you could say, hey, look,
anybody can send their RP announcement to me, but I'm only listening for
certain groups. I'm only going to tell the rest of the world about certain
groups or you could do both.
And here's the way you would do this on the mapping agent.
At the global level, you'd say IPPIM RP announced filter.
RP list one group list two.
So this is referencing two different access lists.
So access list one, which is in red, is giving us the list of authorized
candidate RP's. So there's a router out there with the name of 10, 001
and another one with 10, 002.
Those are the only ones we're going to listen to when they send in an
RP announce. So there's any other router out there announcing its capability
of being an RP, the mapping agent will not listen to that guy.
And as far as these two routers are concerned, in this particular case,
we're saying, okay, we will allow those two routers to announce their
candidacy for any class D.
I could have limited that down to a certain range.
So that's how you would use that command to filter out and protect yourself
against potential attacks.
So let's go ahead and configure this and see how this works.
So so far, I've got router three who's announcing his candidacy to be
an RP. And I think I configured him to announce his candidacy just for
the 238 group. So now I'm also going to configure router four to also
be an RP candidate.
And we'll give him the exact same group.
So there's going to be some conflict here.
238.000. And we'll configure router eight as our mapping agent.
And we'll see which one of these guys is elected as the highest.
Now remember, as part of my command when I make these guys the RP candidates,
I have to specify what interface they're going to use as their source
IP address. So let's say I say, well, I actually want router three to
be the winner. I want him to always win.
So here's what I'm going to do.
I'll have router four use his serial 010 as his source address.
So router four will be saying my name is 2.4.2.4.
Router three will be saying my name is 8.3.8.3.
And so router three should be elected as the winning RP by the mapping
agent. So on the mapping agent, we'll see how he's learned about both
our P's. We'll see how he's elected router three.
And then when we go to router two, we'll see how he should only know about
router three. He should have no knowledge of router four because router
four is the loser.
So let's go ahead and finish this up here.
So I've already done router three, although I don't think I specified
that interface as my source.
Yeah, I've got the wrong interface there.
So let's get rid of that command.
And let's redo it.
But with this interface.
And now we should see, here's my previous snippet trace.
And we saw it was coming from three four three three.
That was his IP address on fast ethernet zero zero.
Now as soon as I hit enter here, he should be sending new announcements
with a much higher IP address.
Yep, there it is.
8.3.8.3. All right, now let's go ahead and configure.
Let's just take the same configuration.
And what I'll do is I'll copy and paste most of this into notepad.
So we can have an identical configuration on the other router.
I'll leave this off.
And for him, we'll have it be serial zero one zero.
So that's what we're going to put into router four.
Okay. So now every single minute, we should be seeing our P announced
messages being sent from router three and router four.
See if I can catch both of those.
Once again, wire shark is not letting me click any of the buttons up here.
This is probably an issue with my laptop.
Not an issue with wire shark because my laptop has been doing all kinds
of weird stuff lately.
Come on. There we go.
Okay, so we've got one announcement we've seen so far from router three.
And because these announcements are flooded, we should see another one
coming from router four.
Well, I don't want to waste time looking for it, but it should be in there.
We can do show IP, PIM, auto RP.
And it does verify that auto RP is enabled and that he is sending out
RP announcements.
So far, he sent out eight of them, even though I didn't capture it in
my sniffer trace.
Okay, so now let's go over to our eight and make him the mapping agent.
Send RP Discovery packets.
And same thing, I got to select an interface for that just for the source
address. Scope defines the TTL.
I could change the interval.
Let's go ahead and do this.
Let's set the interval because normally it's every 60 seconds or if there's
a change. If the mapping agent suddenly hears a new RP announced message
that he didn't hear before, that will trigger him to send out another
discovery message.
But otherwise, if everything is nice and stable, they'll go out every
minute. I'm going to have him go out every 20 seconds.
Let's make it every 15 seconds.
Non-IP or PIM interface ignored and accepted command.
Oh, because he's using, I know why, because he's not using.
Fast Ethan at 00 doesn't have PIM or an IP on it.
He's using sub interfaces.
So I've got to put this on, let's just put on Fast Ethan at 01 as his
source address. Okay, so I don't know if he has collected the RP announcements
yet. Let's just see.
Show IP, PIM, RP, Mapping.
And it looks like he has.
Okay. So here for group 238, anything beginning with 238, he says I received
an RP announcement from router three, which is 8.3.8.3.
I've also received one from router four.
I have elected router three simply by virtue of the fact that he has the
highest IP address.
He also says, by the way, router three told me that the 239 group needs
to be flooded in dense mode.
But there's not going to be any RP for that.
Finally, let's go over to router two and see what router two has learned.
By the way, while I'm here, I can do show IP PIM, auto RP.
And this says, okay, I have actually transmitted 15 RP discovery messages.
And lastly on R2.
Show IP PIM RP. Now, notice you say what?
He doesn't have an RP.
Remember, this command show IP PIM RP really only useful if you have a
static RP. Then it verifies that you statically configured an RP.
But in this case, we're not doing static RP.
We're listening to auto RP messages.
Show IP PIM RP Mapping.
And right here. So we can see he has now learned about the elected RP
of 8.3. He has no knowledge of router four.
Because router four was not elected.
All he knows about is the elected one.
And he has also learned that if he ever gets any multicast packets for
239, there is no RP for that.
That has to be flooded via dense mode.
So in our next video, I'm going to conclude this section on auto RP by
talking about something called an RP of last resort.
Otherwise known as a sync RP.
What that is and why you might need to have one.