All right, so let's see here.
So we want to see the registration process.
The easiest way to create multicast traffic is simply to do a multicast
ping. And actually this will be easy.
The reason I was hesitating is because, for example, if I did a multicast
ping from router 4, when you initiate a multicast ping from a router,
he will actually send out that multicast packet, that multicast ICMP packet
on every single interface he has that has PIM enabled.
I mean, he doesn't even bother to check M-route state or anything.
He does copies it and sends it out every single packet.
And I didn't want that.
But in this case, I don't have to worry about because on router 5, he
only has one interface anyway.
So let's see here.
We want to capture the...
So this is going to be the multicast packet.
It's going to come down this way.
And we want to see that multicast packet as it's encapsulated in a PIM
register. And then we also want to see as soon as the RP gets that, we
want to see him send a PIM-S-G join to open up his shortest path.
Then we'll see the actual multicast itself flowing down in its native
form. And then lastly, we want to see the RP once he gets that, sending
a PIM register stop.
Because that's going to be the process.
So in order to do that, let's see here.
Why don't I just capture everything going in and out of router 3's fast
ethernet 00. So router 3 is fast ethernet 00 is port 0 slash 5 on the
switch. Alright, yep, 0 slash 5.
Okay, so we should be ready.
So let me go now to the source.
And I think it's 999 is what I'm using.
And I'll repeat that 100 times just to keep it going for a while.
And let's start the sniffer trace.
Okay, there we go.
That was enough.
Okay, so here is the register.
So we don't actually see the, because I'm only capturing on, let's go
back to this. Because I'm only capturing on data coming in and out of
00, we didn't actually see the native multicast as it came in to router
4. But we do see the register message.
So here it is, PIM register.
So this is the IP address 4545.
Let's just check here.
Router 4 should be doing the registering not router 5.
Let me just check router 5 here for a second.
Well, let's see, this is interesting, but there's an easy way to check
this. So the source address is actually coming from the source itself
4545. But is it really coming from him or did router 4 just shove that
in there? Well, we can check this by checking the source MAC address of
this frame to see who it really came from.
So the source MAC address came from 8C B6.
8C B6. So did that really come from FastEthernet01 and R5?
No, it did not because he is 8E0051.
So if we go to router 4.
Oops, not show run, show interface.
FastEthernet00.34.
There we go. 8C B6.
So this is interesting, look at this.
So when the native multicast hit router 4, when he encapsulates that in
a register message, hold on a second.
I think this is a weirdness of actually, I think I remember this is a
weirdness of wire shark, not actually the snipper.
Yeah, here we go.
Okay, not sure why wire shark doesn't like this.
Up here in the main window, it says it's coming from 4.5.
If you actually look in the body of it, here in the IP header, it is coming
from router 4. So I'm not sure why the discrepancy here between how it
displays it. But so here's my IP header.
So it's coming from router 4, going to the rendezvous point, router 3,
and then behind the IP header, is our PIM header.
So type number 1, which is a register packet.
And then you can see here there's just a couple of flags, and then here's
actually the multicast packet inside of it.
Coming from the source, going to the group, and just a couple of things
about this in the event that you're curious.
I'll talk about null register as the very last thing in this particular
video. But this thing here called border, what's that all about?
It says no. There's a feature that you can use in PIM sparse mode called
a border router, or a PIM border router.
That is, and honestly I'm not sure how frequently this is used in the
real world, but for example, if I had a router, then on one side was doing
something that's not PIM.
So we're doing a piece and doing PIM on the other interface.
And we want the multicast to flow through.
That would be considered a PIM border router.
In that particular case, if that router sent a register, that one bit
there, that flag bit, would be set to a 1, saying that yes, he is a border
router. But we're not doing that weird kind of thing here, so he's saying
no, he's not a border router.
So there's our register, pretty simple basic PIM header, and then just
the actual multicast inside of it.
And then according to our whiteboard, we said once that came down, the
rendezvous point should then attempt to open up his shortest path tree
by sending an S, G join.
So, let's see here.
That is probably this right here, PIM joins, let's see here.
It's coming, the source address is coming from our rendezvous point, 343,
that's router 3.
It's going to the PIM address of 2240013.
Type code 3 for join.
Now notice, what makes this different than a star, join?
Well, a couple of things.
Number one, number of joins one.
Remember we saw these flags here of SW and R?
Well, we don't see that this time.
The R meant the RP bit was set, meaning this particular join needed to
go up the shared tree.
The ultimate destination was the rendezvous point.
Well, we don't see that here.
The W bit was set mean the wild card bit.
The wild card bit meant that, okay, when you look at this address, this
address is the address of the rendezvous point.
Well, here we don't see that.
The wild card bit is not set, meaning that this is actually the address
of the source. So, it looks sort of like a star, join, but only until
you dig into the guts of it and you see what flags are here or what flags
are not here, can you actually tell whether it's a star, or an S, join.
And this case is an S, join.
So he says, okay, upstream neighbor, so this is router four.
He says, this is going to you, and I'm trying to join this source and
this group. Okay, so there is the S, join.
And then once that S, join is received, that should have put this sub
-interface into the outgoing interface list of router four.
And then the native multicast should have come down, and we should have
received two copies of it, one in a register packet and one in the native
multicast itself.
So let's see if we saw that.
So here is our join, and it looks like, okay, so right here, here is the
native multicast, notice there's no PIM in here.
Source is actually the source, here's the native multicast, and then right
behind that is a PIM register.
And here's an interesting question, are they actually the exact same packet
copied? Well, let's see here, in the actual native multicast, in the IP
header, we have an identification of 0, 0, 0, 1.
Remember, normally each individual IP packet has a unique identification
field. Let's see here, what about the register packet?
Has the exact same ID, so yes, these are duplicates of the same packet.
All right, and so once we saw that, then we see down here, router three,
which is the RP saying register stop, saying I don't want registers anymore.
So right here in the PIM body, type code two, register stop, and he says
I'm stopping for this source and this group.
Now there was one other field in the register that I sort of skipped over
a flag that I didn't talk about, which was this right here, the null register
flag, what is that?
In this particular case, the null register is set to no, it's off, but
when would it be on and why would we use it?
So, let's say, let's draw something here for a moment, and we can actually
use this as an example.
Let's say that our receiver was down here, and initially the multicast
flow was flowing through the shared tree through the RP, but we know that
within a short amount of time, and we're going to look at this in the
next section, we're going to switch over from the shared tree and the
traffic is no longer going to the RP, this has been, oops, not that, this
interface has been pruned off, let's just get rid of all this stuff, and
now the traffic is flowing in its pure native form this way down the shortest
path tree to the receiver.
Okay, so the multicast is going, it's going, it's going, it's fine, it's
going well. But what happens if 10, 15, 20 minutes later, this happens?
We have another receiver who joins our topology, and he wants the exact
same stream, so he sends an IGMP membership report.
That kicks off a PIM star-coma-G join, which creates star-coma-G state
in the RP, and the RP just sits here, waiting, and waiting, and waiting.
Because after all, router Z has no reason to forward this multicast traffic
to the RP, right, the RP pruned off this interface.
Once the traffic starts going down the shortest path tree, we receive
some prunes up this way, and the RP was told, hey, we don't need you anymore,
we don't need the traffic from you.
And when the RP heard that, he said, okay, I guess I don't need it anymore,
nobody else wants it from me, so the RP pruned off this link.
So that happened a long time ago.
Now somebody is asking the RP for this traffic again, but he's not getting
it. This is where the null register can come into play.
So let's talk about the null register.
So we know that after a while the RP may forget about that flow.
It went through him originally.
He prunes it off because he doesn't need it anymore, and he forgets about
it. So what's going to happen here is this, the router that's connected
to the source, router 4 says, well, I've been sending this multicast for
a while. There's a chance that maybe the RP needs it.
Hey, maybe somebody else wants to receive this traffic.
Maybe I should let the RP know that it's still going.
Well, we could take the next packet and register it with the RP.
That would work.
But instead the desires of PIM said, well, I don't want to keep bothering
the RP with this registration, because maybe he's got nobody.
Maybe nobody that he knows of actually wants this traffic.
So instead what happens is every few seconds, router 4 sends what's called
a null register to the rendezvous point.
What is a null register?
It basically looks exactly like a normal register packet, but it doesn't
have any multicast data inside of it.
So if we go back to our sniffer trace, a null register would say type
1 register, and it would have information in here about the source and
the group. But there would be no body.
There would be no multicast data inside of it.
It would be a much smaller packet.
And the null register flag would be set to a 1.
And this is the way that this router here could say, hey, RP just wants
you to know, I still know about this flow.
It's still going through me.
So if you want it, you better tell me.
And then once the router got, once the RP got that null register, he's
saying, oh, goody, goody.
I've been waiting to hear about that traffic, because somebody asked me
for it. So now the RP could once again send an S-comaG join to open up
this path, and the traffic could start flowing down this direction.
So that's what a null register is.
And these are sent every five seconds.
This is called the probe time.
So every five seconds, the router that's closest to the source, if the
source is still going, if it's still pumping out the multicast, we'll
send out every five seconds these null registers to the RP, just reminding
the RP that this traffic exists.
Because maybe during the last five seconds, a new receiver joined to the
RP, and maybe the RP wants that traffic again.