In the last video, we looked in pretty great detail about what the process
is used when we're creating the shared tree, how the IGMPM membership
report received by the default gateway kicks off a PIM, what we call star,
G-join, which works its way up hop by hop to the rendezvous point.
And we saw how as that happens, each router from the router, the default
gateway who received the membership report, and then each router along
the path that receives the star, G -join up until the rendezvous point,
that created what we called star, G-em route state in our multicast routing
table. So once we have that star, G -em route state, which is, I don't
care what the source is, once it starts hitting that rendezvous point,
we've got an open connection, an open path, all the way down to the receiver.
And that's based on what was shown in the outgoing interface list.
Okay, so now let's actually start the multicast and see what happens there.
So the green dash line in this particular case indicates the shared tree
that's already opened.
Now I'm not showing R8 here, but we know that R8 is between these two.
Now the source is going to start.
And what we're going to see is when R4 receives those native multicast
packets from the source, he's going to say, huh, I got a problem here.
Because I'm only allowed to forward these native multicast packets if
I have some entry in my M route table that has an interface in the outgoing
interface list. But he's going to say, nobody's ever asked me for this.
I've never received any IGMP membership reports.
I've never received any PIM joins from anybody.
So I've got no place to send this.
And yet there might be receivers out there.
So what do I do?
Well, with PIM sparse mode, what he's going to do is he's going to take
that multicast packet and he's going to encapsulate it inside of a unicast.
And this is going to be inside of a PIM packet.
So there's going to be another type of a PIM packet called a PIM register.
And that's what we're going to look at next.
So the PIM register actually carries.
It's a unicast packet, unicast it from R4 directly to the RP.
So we'll see the source addresses R4.
The destination address is the rendezvous point.
The PIM type will be a new type called register.
And in the body of that will actually be our multicast data.
And when the rendezvous point gets that, he will de encapsulate it, revealing
the multicast packet.
And then the RP will say, okay, do I have state for this?
Has anybody ever asked me for this?
Well, in this case, you'll say yes, because our shared tree is already
ready and waiting.
So he'll forward that down the shared tree.
So that's how our multicast will initially start by registering down this
way. So now that could continue potentially indefinitely.
Right? I mean, it works.
It gets the multicast from the source to the receiver.
But it's asking that router connected to the source and the RP to work
a little extra hard to wrap this thing into a unicast and to unwrap it
from the unicast on the other end.
So although it works, it's consuming a little bit more CPU resources.
And certainly if we had dozens or hundreds of multicast streams doing
this, that might potentially be bad on the RP who's multicast inside.
So what's going to happen?
And we'll see this in the next segment in more detail, is when the rendezvous
point gets this pin register packet, he's actually going to do a couple
of things simultaneously.
Number one, he's going to unwrap it, forward it down the shared tree.
We already talked about that.
Next thing the rendezvous point is this multicast in its pure native form.
So I can just forward it according to my m-route.
So I don't have to keep pestering my CPU with it.
See, how do I do that?
Well, I know that my upstream neighbor is only going to forward it to
me if I ask him for it.
So the RP will actually send a join message to his neighbor.
But this is not a star-comedy join because he actually knows the source.
When this first multicast comes in, he says, oh, I know who the source
is, 4.5.4.5. So he's going to send what's called an S, G join.
When we see in the snipper trace, it's the exact same format as a star
-comedy join, except it lists the source address in there and a couple
of the flags are different as well.
And that opens up the shortest path tree from the rendezvous point to
the source. Because remember, we talked about how there's potentially
multiple shared trees, right?
If I'm a rendezvous point and there's 50 different receivers spread out
through the network, there could be 50 different shared trees.
Well, similarly, the concept of a shortest path tree is from an individual
router's perspective.
My shortest path to get to that source is a router might be different
than your shortest path to get to that very same source.
So the rendezvous point, when he gets this register packet, he's going
to say, I want to open up my shortest path to get to that source.
Because once it's open, these registers will stop.
I'll start getting the pure multicast in its native form.
So as soon as the register comes in, in addition to forwarding it down
this way, this RP is going to send, let me expand this a little bit, he's
going to send an s, G join upstream.
And that will, in R4, that will add fast e-sign at zero, zero into his
outgoing interface list.
Now our four will say, Oh, great.
Okay, now I can start forwarding the multicast downstream in its pure
native form. But guess what, he's going to keep registering.
So now we're going to get two copies of these multicast packets on the
RP. We're going to get the native multicast coming down.
And we're going to get another copy of that inside this pin register packet.
Now you might say, why did that happen?
Why does an R4 just stop at that point?
Well, here's why.
In this particular topology, it doesn't really describe it very well.
But imagine if I had this.
Okay, so imagine if, you know, here's my source.
Okay, and we've got router X, and we've got the PIM RP.
And this is router five.
Okay, so here my source is sending its multicast to router five.
Router five is then taking that multicast and registering it.
See if I can sort of draw something here to indicate that.
So that's the registration.
And now router five gets an s, g join.
So the source is, let's see here, what's the guy's source?
4.5.4.5 in my particular example.
So he says, okay, here is a PIM join.
And it'll actually list the source and the group.
Okay, well, when this comes in, if there was, how do I phrase this?
Actually, here's a better example.
Put a router right here in the middle.
Okay, so these PIM messages all have a time to live of one.
Right, we saw how the PIM star comma g join went out to the same multicast
address as the hello, 2240013.
Now I didn't really point it out in the sniffer trace, but just like the
PIM hello has a time to live of one, PIM joins and let's say his address
is 55555. When the PIM join is going right here, in the actual IP header,
the source is going to be coming from that guy.
And the destination is going to be like that.
Well, actually it's going to be the router.
This guy right here, 4.5.4.4.
Let's just say that, let's just say he's router 4 to make it simple.
So there's not necessarily any way for router 4 to know that this join
actually originated at the RP because it's hop by hop.
When the RP first sent it, the RP sent it to router Z because he s comma
g join had the same information in it.
Source was 4.5.4.5.
Group was 239.999.
And the packet here had an IP source of the RP and the destination of
router 4. Let's put this right here.
Actually, no, it had destination of router Z because it's hop by hop.
It's one hop only.
IP source is RP.
Destination equals router Z.
So he sent this s comma g join because the RP said, okay, I know who the
source is. My next top neighbor is router Z.
So I'm going to send a PIM s comma g join to that neighbor saying, hey
neighbor, can you open up this path for me?
Then when router Z gets it, he does the same thing.
He says, my sure is path to the source is router 4.
So I'm going to create a PIM s comma g join and send it to router 4.
So that opens up as it goes along the path here.
This interface is opened up in the outgoing interface list.
But when router 4 gets this, he has no idea that the reason he's getting
it is because the RP started the process.
All he knows is he got an s comma g join for router Z.
He has no idea why router Z sent that to him.
Only this router Z got it, that router Z initiated it.
So he says, well, router Z sent me this s comma g join, but I'm in the
process of registering.
The two are totally different.
Just because one guy sent me a join doesn't mean I should stop the registration
process with another guy.
I'm still going to keep on registering because I haven't heard from the
RP yet. All I've heard from is router Z, the RP would get two copies of
the same packet.
When the multicast packet starts flowing down, it'll flow down natively
from 4 to Z to RP because this path has now been opened up.
And at the same time, when router 4 got that multicast packet, he created
a copy of it and it encapsulated it in unicast and unicasted it directly
to the RP. So now the RP says, huh, okay, great news.
I just received the real multicast packet in its pure native form on my
shortest path tree.
I now know that my shortest path to the source is open.
It's flowing. It's working.
He says, I don't need these register messages anymore.
That's making me work harder than I need to.
So the RP will actually send what's called a PIM register stop message
to router 4. That's what router 4 is looking for.
That will cause him to actually stop the registration process.
So I know that in this diagram, it wasn't entirely clear.
You might have said, okay, well, when the app is going to stop the register,
I want to show you no.
That's not. The registration will keep going until the RP explicitly says,
please stop. I don't want to see these registers anymore.
So he uses a register stop message to switch over.
Actually, he doesn't use it to switch over to his shortest path tree.
He does it after his shortest path tree has already been open.
So actually, I'm willing to change that.
There, the RP uses register stop messages after its shortest path tree
is confirmed and open.
So that is the PIM registration process.
So let's go ahead and take a look at that and see how that works.
So I think right now, our shared tree is currently open.
Let's just confirm, let's go to router 3 to RP and make sure he still
has a star, entry.
Oh, okay, he doesn't.
Let's go back to our source, our receiver here.
Okay, that's why, because he's not joined the group.
Okay, so now we should have it.
Okay, so there is our star, entry.
And also, as far as these timers are concerned, this timer here is like
the lifetime of this.
This will keep counting down.
And if this ever counts down to zero, that means I'm going to remove this
interface from the outgoing interface list.
But we know that as long as that receiver is still active, as long as
there's still queries going out and reports going back, router 2 every
60 seconds, we'll send another star, join up here to refresh that state.
And router 8 will also sit when he gets that, we'll send his own star,
join to refresh that state.
So for example, right now we're down to 233.
And it's back up.
See, so we started at three minutes and 23 seconds.
And we went down to about a minute.
And then we didn't see it, but in the background, he received a star,
how much he joined a refresh, and it went back up to this.
This here, this timer, is how long this interface in total has been in
the outgoing interface list.
So it's been a minute and four seconds since we very first received our
first star, join which caused this m -route entry to be created originally.
So this time we'll just keep increasing.