So in the previous videos we've seen how with AutoRP we have the concept
of candidate RPs that are announcing their candidacy and the mapping agent
which is collecting all those entries, electing just one for any given
group and then dispersing that via discovery messages.
And that's what all the other routers are listening to, those discovery
messages to see which RP has been elected.
But the downside to this process is that we know that by default RP candidates,
if you don't do anything special, if you don't use any access to this
or anything, by default they will announce their candidacy for the entire
class D range. But what if you start getting tricky and you start saying
okay well I only want you to be an RP for a certain range, like in my
lab example previously I said only for the 238 range, that's it.
No other multicast ranges will have an RP.
Well what happens then if a multicast stream does come in that's in one
of those other ranges for which there is no RP.
Well in that particular case, because all of your interfaces are in sparse
dense mode, which is what you really need to get this to work, those other
multicast streams will be flooded.
So you might think okay, prime use case of once again doing a network
attack, right? Just put a router into the network and have him listen
to the incoming discovery messages, take a look and say aha, okay so I
can see in this particular network, they've only got an RP for the 238
range. So here's what I'm going to do to mess everybody up.
I'm going to introduce a packet generator that sends out just gobs of
traffic going to, oh I don't know, how about 227 dot something.
Because I know that's going to be flooded via dense mode.
Every single router is going to get that, it's going to be flooded everywhere,
flood on every single segment.
If I do enough traffic, maybe I'll start congesting some links and maybe
some memory buffers and queues will get so full that I'll just start dropping
traffic and he he he I can really do some nasty work here.
So we want to prevent that kind of thing from happening, right?
This is where we would use something called an RP of last resort to prevent
that evil malicious person from doing that.
So talked about this is the potential problem.
So an RP of last resort is called a sync RP.
It's basically an RP that says, okay, we're going to we're going to I
have this valid R I've got these RPs over here.
This guy's doing 238.
This guy's doing 239.
What about everything else?
Well, while we have this third RP, we'll call him the sync RP and he will
be used for any other multicast stream that comes in, he'll have to register
with him. And presumably, there's no listeners for that.
Nobody is you know, that's you know, if 226 comes in, well, hey, in our
network and our company, we don't use 236.
All of our multicasts are 238 or 239.
That's why we got those RPs out there.
So if something comes in going to 225 or 226 or 227, there's not going
to be receivers for that.
So why don't we just send register packets to an RP and they'll just be
dropped right there.
They'll go nowhere.
They won't be flooded.
Or you might think, well, wait a second.
That's going to be bad for that router, right?
Because if an attack actually starts happening and gobs of traffic, gobs
of register messages start going to him for like hundreds or thousands
of multicast groups, isn't that going to kill him?
And then so what are we going to do about that?
Well, guess what?
Look at that last bullet point.
It could be a black hole.
In other words, you could go on to these routers and say, OK, your RP
is 9.9.9.9 for everything that you don't learn about via auto RP.
But in reality, 9.9 .9.9 doesn't exist.
It doesn't exist anywhere.
So even if there's a route for it in the routing table, eventually those
register packets will be dumped onto a LAN and just deleted.
Or maybe you don't have a route for it at all.
And maybe you make your sync RP and say, OK, let's see, in my network,
I'm using the 90 network for everything.
My entire enterprise is various subnets of 90.something.
So I'll make my sync RP 7.7.7.7.
There's not even a route for it.
So now if any of my routers start getting pounded with this unauthorized
multicast traffic, they'll say, oh, I need to register this.
Uh-oh. Don't have a route to this RP.
I'm supposed to be registering it to, I guess I'll just drop the traffic.
And it'll just die.
It won't be flooded.
And that's the whole idea behind this, this idea of an RP of last resort
or a sync RP. So how are we going to create this?
Real simple. We just go back to configuring the static RP address command.
Now you might be thinking, wait a second.
I know how routing works.
Static routes always take preference over dynamic routes.
Isn't this going to completely undo auto RP?
Nope, because in this particular case, it's just the opposite.
When routers are running auto RP, any RP they learn via an RP discover
packet from the mapping agent takes priority over this.
Yes. So what we're actually doing right here, let me go back to this,
is this is saying, okay, I'm going to configure 1.1.1.1 as my RP.
Now that doesn't even exist.
That IP address isn't even in any routing tables anywhere.
It's just a black hole.
And I'm going to say, and I'm going to configure this on every single
router in my network.
Because I never know where that rogue attack might start from.
So every single router who's doing auto RP is learning about my legitimate
RPs, and every router has this command, which says, okay, this guy 1.1
.1.1. Do not register with him.
Do not talk to him on these two addresses, because this is used for auto
RP. So he's excluded from those ranges.
But he's included for everything else, the entire class D range.
And so now, if, let's say here, if we receive in an RP discover packet
from the mapping agent.
And it says, hey, the elected RP is 90.0.0.1.
Because after all, we're using the 90 network in our company.
And he's the RP for 224.000 slash 4.
What we'll say, okay, this conflicts with this.
But the RP discover takes priority over this.
Or if we just make it a little bit less, like let's say something like
this. Our RP discover says 90.001 is going to be the RP for 238.000 slash
8. Okay, so now my router knows that if he ever gets an IGMP membership
report, that he should send his star, join, if he gets an IGMP membership
report for 238.anything, he should send his PIM join to 90.001.
If he ever actually receives a real multicast packet going to 238.anything,
he should register that with 90.001.
If he gets a multicast packet going to anything else, like 237.225, whatever,
then he'll say, okay, I need to register that packet with 1.1.1.1.
And if 1.1.1.1 doesn't actually exist, it's not real.
And he doesn't even have a route to this.
He'll just drop that multicast packet.
And that prevents it from being flooded via dense mode.
Which is what we wanted in the first place.
So that's how you configure what's known as an RP of last resort or a
sync RP. Now you might say one other permutation or option to this.
You might say, well, what if I actually do want to statically configure
an RP for one group?
And I want to make sure that that always takes priority.
So even if I learn about an RP by that same group via auto RP, I don't
want auto RP to take precedence.
I want my static configuration to take precedence.
Well, you can do that.
And that's where you would use the override keyword.
So like in this particular case, we're saying, okay, I'm statically configuring
2222. He's a real RP.
He's allowed to be the RP for this particular group.
And even if I learn about this group from auto RP, I'm going to ignore
that. This overrides auto RP.