Okay, so before we get into the nitty gritty details of PIM as a multicast
routing protocol, let's look at a real high level of what are multicast
routing protocols, why do we need them, what problem were they designed
to solve. So we know that we got this concept of sources and receivers,
the source being some server out there that's pumping out multicast traffic
and hitting your router, that router is dropping it because there's no
idea where it's supposed to go.
And at the other end of the network, you got your receivers, your laptops,
your PCs that want that multicast traffic, but their default gateway has
no idea where the source is.
So how do we connect the two?
And that is the whole reason why we need multicast routing protocols to
build that branch, to connect them, to build this multicast distribution
tree. So we need to create that tree.
And I talked in the previous video that we've got two basic high level
ways of doing that.
One method, which is called the push model, which is used in dense mode
protocols, simply means let's just flood the network with that multicast
traffic. You'll definitely get down to the receivers and all the other
branches of the tree where it'll be up to the routers to prune off those
branches to say, hey, upstream router, stop sending that to me.
I don't have anybody downstream for me who actually wants it.
The other model is sparse mode, which means, OK, once the receivers indicate
their interest to the default gateway, the default gateway now has to
trigger some sort of multicast join message saying, OK, I'm going to send
a message upstream saying, hey, router up above me.
If you ever get this message, this multicast stream, I'm down here.
I want that. The question then becomes, OK, well, where does your default
gateway send that?
Because maybe he's got five or six routers sitting upstream from him.
Which one does he send this join to?
So in order to answer that, and here's a good analogy I came up with.
Think about dating, right?
Guys and girls dating trying to find each other.
So a dense mode protocol would sort of be like, you're the guy, you walk
into a nightclub, and in order to find your perfect mate, you just walk
up to every single girl that's here saying, hey, I love you.
Would you like to marry me?
I love you. Would you like to marry me?
Of course, you get slapped like multiple times that you're doing that.
But hopefully, eventually, you'll find your receiver, right?
The far corner there, the girl who's drinking a lot of beer, she'll say,
yeah, I want to marry you.
And so now you found your receiver.
You're the source.
She's the receiver.
You had to go through everybody else first and get pruned back.
But eventually, you found who you were looking for.
That's like a dense mode protocol.
A sparse mode protocol is like, instead of doing that and risking all
that rejection, you use a dating service.
So you've got this intermediary company called a dating service, you know,
whatever, eharmony.com or whatever the big one is these days.
And the source, you, you go to the dating service and you create a profile.
And you say, hey, this is me.
I'm so wonderful and great.
I make $5 million a year.
I drive a Ferrari.
Please marry me.
Right? So you post your thing there at the dating service.
The receivers, well, you know, of all the 50 million women who are using
that dating service, there might be three of them that go to that dating
service and say, oh, yeah, that's exactly what I'm looking for.
He's kind of a jerk.
He's got a lot of money.
He's got a Ferrari.
I'll like that guy.
And so the two of you meet up through the dating service and initially
you can't talk to each other, right?
Initially the dating service says, no, you know, to make sure this guy
is not a stalker and she's not crazy, you know, we're not going to let
you guys exchange phone numbers and addresses and stuff.
You're going to have to use our chat system and our email system to talk
to each other. But eventually after you've exchanged messages through
the dating service, now you can learn where each other lives.
You can exchange phone numbers and you can stop using them.
You can communicate directly.
That's how sparse mode protocols work.
With sparse mode protocols, you've got some router sitting somewhere in
your network that serves like that dating service functionality.
And so the receivers, once your laptop sends the IGMP message to the router,
your default gateway, your default gateway says, hmm, okay, I know I got
a receiver here, have no idea where the source is.
receiver wants. But I do know where the dating service is in the terms
of a multicast routing protocol, that dating service is what we call a
rendezvous point, an RP.
So there's some router in the network that all the routers running multicast
know that guy is the guy we go to.
That is the rendezvous point.
So now your router will say, okay, I'm going to create something called
a join, a multicast join message.
And I'll send it in the direction of the rendezvous point saying, hey,
I got a guy down here who's looking for this group.
And so eventually that join makes its way up to the rendezvous point.
Now the source may not have started yet, but the rendezvous point now
has built a branch down the tree from the rendezvous point down through
these routers down to your default gateway.
We've now opened up a path so that if the multicast does start, it's got
a direction that it can flow.
Now the source, the source starts up, the server.
So that server starts sending its multicast and it's hitting its router,
some router connected to that segment, is being pounded on the back of
the head with this multicast traffic.
Once again, that router way up there in the other corner of the network
says, I've never heard from any receivers, but I know where the dating
service is. I know where the rendezvous point is.
And we'll go into more details about this, but basically encapsulates
it in unicast. It takes that multicast packet, wraps it inside of a unicast
header and unicasts it to the rendezvous point.
Once the rendezvous point gets it, he unencapsulates it, says, oh, here's
multicast. Oh, yeah, I know where this goes because I received a join
for this and he sends it down the tree.
So that's how in sparse mode protocols we initially connect them, right?
That rendezvous point is the dating service.
But just like in my analogy, you don't want the source and the receiver
constantly going through the rendezvous point to talk to each other.
It's not necessarily efficient, right?
What if that receiver is in Florida, the source is in North Carolina,
but the rendezvous point is in California?
Well, in that traffic's going way out of the way to get to the rendezvous
point and back. There's a much shorter path directly between the source
and the receiver.
But we had to get that multicast going first before we could discover
where it's coming from, that it's coming from North Carolina.
And now the Rogers can switch over to that path.
They can say, OK, thank you, dating service.
Thank you, rendezvous point.
Don't need you anymore.
Now I know exactly where the source is.
We can get the traffic directly from him and we can switch over to that
path. So that's a real high level of how sparse mode protocols work.
We have to join with the rendezvous point first, express our interest,
build that branch.
The traffic has to start going to the rendezvous point and then it switches
over so it's going directly between the source and the receiver, rendezvous
point's not even part of the equation anymore.
So sparse mode protocols use something called core based trees or RP trees
because we've got a rendezvous point.
So the rendezvous point is the core of the tree.
Everybody starts by going to him and then it switches away from him pretty
quickly. OK, so RPF in case you're not familiar with, of course, RPF could
switch over to the tree.
It's a lot of different things but in this particular case it stands for
reverse path forwarding.
Now think about unicast traffic.
Let's steer away from multicast for a second.
A router receives a unicast packet going to some destination 9.9.9.9.
What does the router do?
The router says, OK, I'm going to look at that destination IP address,
go into my routing table and see if I have some sort of a route that tells
me where that destination is.
Normally in order to route that pack in order to get it on its way, does
the router care about the source of that packet?
No, you could care less what that source address is.
As a matter of fact, you could put 0, 0, 0, 0 as the source, the router
wouldn't care. In order to route that packet all it cares about is the
destination. Now certainly you could implement access lists and other
stuff like that to force him to look at the source.
And you can actually implement something called RPF as well.
For example, what if I, you know, let's say my laptop right now is sitting
on the 11 network, 11.something, so I've had an 11 address, 11.555.
That's the address of my laptop.
And I discover, I find out through the grapevine that I'm going to be
laid off today. I say, what?
Man, I put in all sorts of years with this company.
I've worked overtime.
I've sacrificed my children for this company.
They're going to lay me off.
That really ticks me off.
So I say, you know what?
Before I go, I know what the IP address is of my company's web server.
It's 77777. So I'm a little, I'm savvy enough.
I say, you know what?
I'm going to bring down that server.
I'm going to slam that server with, I don't know, some kind of traffic.
Maybe TCP sync requests, right?
I'm just going to slam it with 5 million TCP syncs every second.
Bring it down. So ha ha ha.
You want to lay me off?
I'm going to make you guys lose millions of dollars over the next couple
of hours while your server's down.
Well, if I decide to do that, I don't want people tracing those packets
back to me, right?
Because not only will I get laid off, now I'll be in a jail cell with
someone I'm not particularly fond of.
So I don't want that.
So I say, hmm, if I'm going to send those TCP sync requests to that server
to try to overwhelm it, I want to make sure that the source address is
not me. I don't want to be 11555, which is me.
I want to spoof that source address to look like something else.
So if they find those packets, they'll never know it came from me.
So I'll give it a fake IP address because I know when those packets hit
the routers, the routers don't care what the source address is.
And it'll crash.
Well, if I'm the network administrator, one thing I can do to prevent
people from doing that is I can use what's called unicast RPF checking,
which means when a packet comes into an interface on a router, before
I even look at the destination address, I'm going to look at the source
address, and I'm going to ask myself a very simple question.
That source address, if I was to go back in the reverse direction towards
that source, would I use this interface where it just came in?
Now, I'm sitting here.
I'm 11.555. I've intentionally changed the source address of my packet
to something completely fake, like 12, 12, 12, 12.
Well, it came in this interface.
It came in fast Ethan at 00 on the router.
According to this router's routing table, he says, to get to the 12, 12
network, I wouldn't go fast Ethan at 00.
I'd go out serial 11.
So if that network administrator has configured unicast RPF checking in
the router, the router will say, there's something wrong with this packet.
According to my reverse path, I would not go this way to get to 12.
I would go this way.
The packet came in the wrong interface, and it would be dropped.
It would be discarded.
And so now my server would never get that packet.
It would never harm the server.
That's not on by default.
Unicast RPF checking is something you have to enable if you want to do
that. Well, how does that relate to this?
When you enable multicast, multicast routing protocols do RPF checks on
the source by default.
As a matter of fact, you can't stop them from doing that.
They do that. Now, why do they do that?
They do it for loop detection.
The idea is when a multicast packet comes in, you don't want to just circle
around the network forever.
So what the routers do is they say, okay, router's running sparse mode
protocols. So if I'm a router sitting in a network, let's just say I'm
the default gateway.
I'm the gateway connected to this receiver, to my laptop right here.
And I've just been informed via IGMP that this receiver wants to receive
some multicast. 239-777.
Let's just draw this to make this clear.
Okay. So, here is, oh, hold on just a second.
I'll just do it this way then.
Here is my receiver right here as a square.
We'll put that as a little R.
And here is the default gateway that he's connected to.
Default gateway.
And he's got several interfaces leading upstream.
We'll just say interface one, two, and three.
Doesn't matter what they are.
Fast ethernet serial, it's irrelevant for this discussion.
Now, this router has just received an IGMP membership report from the
receiver. And that receiver wants to get the traffic for 239-777.
That's the group he wants to participate in.
Now, this router is running a sparse mode routing protocol.
So we'll just say it's PIM.
It's running the protocol independent multicast routing protocol.
So as part of PIM, in order to get PIM to work, he says, okay, I know
there's some router somewhere.
We'll call it way out here, which is my rendezvous point.
And so I've got to let the rendezvous point know that I've got a receiver
down here who wants this.
So let's say this rendezvous point is 8888.
So this router, he says, okay, I know.
Let's just do a little thought bubble here.
He says, I know that the PIM RP is 8888.
Now, he says, okay, how do I get to the PIM RP?
Now, this is where he uses his unicast routing protocol.
I've mentioned a few times that multicast routing works hand in hand with
your unicast routing protocol.
So he says, okay, let me go into my routing table.
And according to my routing table, I've got an EI-JRP route that says
to the get to the 8.8 network, it's via interface 2.
So he sends a PIM join out interface 2.
And eventually, that PIM join works its way through the network and gets
up to the rendezvous point.
So this is now the shared tree, right?
This is the tree going from the rendezvous point down to the default gateway.
Now, this default gateway, because he's running PIMS sparse mode, he says,
okay, I expect that when the multicast does start, whenever it starts,
it should come down from the rendezvous point.
So let's say the multicast does start, and here it comes.
Here it comes down this way.
So the source is 7777.
The destination is 239.777.
Well, because this guy's running PIMS sparse mode, he does an RPF check.
But here's how it works.
He says, well, because I expected this multicast to come by way of the
rendezvous point, he says, what interface should it have come in on?
Well, according to my routing table, to get to the rendezvous point, I
go via interface 2.
Huh, this multicast did not come down from the rendezvous point.
It did not come from interface 2.
So guess what? I'm going to kill it.
This is an RPF failure.
It did not come down what we call the shared tree, the tree that is shared
between the rendezvous point and this default gateway.
It just failed the RPF check.
Now let's say it had come down this way.
Okay, so it came down the correct path.
The RPF check would succeed.
It would pass. He'd say, okay, I am interested in this group, and it did
come in on the correct interface, on interface 2, which is the interface
leading to the RP.
Now something interesting happens.
So let's just go ahead and put this back in here.
Source was 777. Destination was 239.777.
Okay, so he can forward that multicast to the client, to the receiver.
Now for the very first time, this router says, oh, finally, I know who
the source is. The actual address of the server is 777.
Now PIMS-SPAR-SMO says, okay, I could continue to get this from the rendezvous
point, but is there a better path?
Is there actually a shorter path to get to that source that would be more
efficient? So he goes back to his routing table.
He says, okay, now let me do an RPF lookup on that.
And he says, oh, lo and behold, I've got a route that matches that, that
I learned via EIGRP.
Once again, it could be learned via RIP or OSPF.
We don't care. He says, that's via interface 1.
So now PIM does something special.
He sends another PIM join out this way.
We're going to get in all the details of this.
And he says, this is for source 777 destination 239.777.
And that PIM join goes all the way up.
And let's say the source is right here.
That's actually where the server is.
And there have been a bunch of routers in the middle.
So here was a router.
Here's a router.
And here's a router.
And they're all connected like this.
Assuming that all these routers know how to get to the 777 network, that
special PIM join would have gone all the way up and finally made it to
this router that's connected to the source.
And that has now opened up the shortest path tree.
Notice we've got two different trees here.
We've got the blue one and the green one.
And the blue point down to the default gateway was called the shared tree
or sometimes called the RP tree.
You might sometimes see the acronym RPT.
That worked, but it might not be the most efficient path.
This green tree is the shortest path tree.
But we didn't know what that was until we knew where the source was until
we got our very first multicast packet.
And so now that we've opened up that tree, now the router says, okay,
at this point, for a slight moment in time, the next time I get the multicast
packet, it could come from one of two places.
I will accept it on interface two because it might still be coming from
the rendezvous point.
And now if it comes on interface one, I will also accept it because I
tried to open up this path.
I intentionally tried to open up this path hoping that the multicast traffic
will come down this way.
So now if the multicast comes on interface three, that'll be an RPF failure.
Because the router says, hey, interface three, that's not the shared tree
and it's not the shortest path tree.
But it comes down either one of these, it'll pass the RPF check.
And once the multicast actually starts flowing and coming in on interface
number one, now the default gateway will say, great!
I'm getting the multicast traffic via the most efficient way possible
via the shortest path tree.
I don't need to get it from the rendezvous point anymore.
So he'll actually send a PIM prune message up this way, which will prune
off this tree. And now the multicast will be flowing down the shortest
path tree until the receiver no longer wants it.
So that's a real high level of how PIM sparse mode works.
But I did all that to show you that RPF checks are happening.
It all depends on where the router expects to get the multicast from.
If he's expecting it to come from the rendezvous point, he's going to
say, look, the rendezvous point lives on interface one or interface seven,
and he learns that by his routing protocol.
That's where I expect to get the multicast initially.
If it comes from any other interface, I'm going to kill it.
I'm going to drop it.
It wasn't supposed to come that way.
But once he knows what the source is and he tries to open up that shortest
path tree, now the RPF will succeed.
It will pass if the multicast comes down the shortest path tree.
So how do we determine the correct ingress interface?
How do we make sure that the RPF succeeds or passes based on the type
of tree that we're expecting?
Are we expecting it to come down the core tree, otherwise known as the
RP tree? Or are we expecting that traffic to come down the source tree?
Now, may be dependent on the specific IGP type.
What am I talking about there?
PIM is not the only multicast routing protocol.
There are other ones.
For example, MOSPF, multicast OSPF.
You can probably guess if I'm using multicast OSPF in order to figure
out what the correct interface is to go to the RP, or the correct interface
to go to the source, it relies on OSPF routes.
MOSPF cannot do RPF checking based on RIP or EIGRP.
It needs OSPF. There's another one called DVMRP, Distance Vector Multicast
Routing Protocol.
That one's kind of weird.
It actually builds its own separate unicast table just to do RPF checks.
The DVMRP table.
It doesn't use anything else.
The wonderful thing about PIM, Protocol Independent Multicast.
The Protocol Independent means PIM says, I don't care.
When I do an RPF check, I'm going to go into the routing table.
I don't care if I can find a route that's a static route, connected route,
EIGRP, RIP, OSPF.
I don't care. As long as I can find something in order to do my RPF checking,
I'll be happy. That's why PIM is so popular because it allows you to use
whatever IGP routing protocol you want.
It's not dependent on that.