Now his star, comedy state.
Let me just go ahead and fill the rest of this out here.
So in router two, his outgoing interface list will say fast ethanet zero
zero because that's where he received the membership report.
So that's where he will forward the multicast traffic when it comes to
him. Router eight, his outgoing interface list will say fast ethanet zero
slash one because he received the PIM join on that interface.
Now, router three, I'm going to skip a couple of fields here.
His outgoing interface list will say fast ethanet zero slash one because
that's where he received the PIM join.
Now in the RP field, you're going to see something rather interesting.
It's going to say that because he is the RP.
That's his way of saying, okay, I know on the rendezvous point.
So that's me. And his incoming interface will say no because he'll say,
hey, I'm the root of the shared tree.
It starts with me.
And his next top, his RPF neighbor will also be all zeros.
But he'll say, look, I don't use any next top neighbor to get to myself.
I'm not psychotic.
I know I'm here.
I know I'm the rendezvous point.
So that's what we'll see.
So let's go ahead and start up this process here.
So I'm going to go ahead and trigger R1 to send the join.
And let's go ahead and start the sniffer trace so we can capture all of
this. So we'll just capture two things.
We'll capture the membership report coming in and the PIM join going from
router two up to router eight.
So to do that, so I want R2, 00 incoming and I want 01 outgoing.
So looking at my diagram here.
Okay, so I'm going to want R2.
So I want 0 slash 3.
Receive and I want 0 slash 1 out.
That's your slash 4.
I'll just do both for those.
So let's go ahead and do that.
Okay. Let's get the sniffer trace all set up and ready to go.
I do not know why wire shark is not letting me press any of the buttons
on the menu here.
This is irritating beyond belief.
There we go. Finally.
Okay. So stop. Here we go.
So now let's go to my receiver.
And you might be wondering how do I get a router to act like a PC?
How do I get him to send an IGMP membership report?
He's not a laptop.
Real easy. So let's see what interface do we want here.
We want fast ethernet 00.
So I just simply type IP, IGMP, join-group.
Oops, got to go to my interface.
Join-group and I'm going to do 239.
Let's see. What have we been doing on my examples here?
9.9.9. Yes. Actually before I do this, I can do a debug.
Okay. IP, IGMP, join -group 239.999.
And there it is.
He sent an IGMP version to report.
However, I don't think I started my snipper trace.
So let's go ahead and just shut that down.
Let's go to R2. Clear out my M-route state.
So I can start from scratch.
Clear IP M-route star.
That clears out all of your M-routs.
Okay, so I'm back to having just the auto-RP M-route.
Let's also do that in R8.
Okay, so let's go back to router one.
And let's start off my snipper trace this time so we can capture all this
good stuff. The IJRP is formed and I think I still have the debug running.
So he received an IJMP query and there he goes.
Okay, so here is the IJMP.
Nope, this is not, this is different.
Let's see here, here it is.
Here's the IJMP membership report from router one.
I should say my receiver.
And you can see here IJMP version two and he's joining the address of
239.999. So the moment that, let's go back here, the moment that router
two got that, he would create a PIM star coma-g join.
And he's going to use his source address of 8.2.8.2.
And that's what we see right here.
So right beneath our membership report, there is the PIM star coma-g join
leaving that router.
We dig into the details here.
So it's type three, remember type zero was the hello.
So type three is the join slash prune.
This is also not a little thing here.
This one message here is used for both joining branches to the tree and
pruning branches off of the tree.
Now we dig into the guts of it.
He says, okay, this is destined for my upstream neighbor.
Now why is that in there?
A couple things.
Notice that this is going out just like the PIM hello is going out to
the multicast address of 2240013.
So let's say that this was actually a shared land and there were other
routers on this land in addition to routers two and eight.
Let's say there was routers X and Y.
Where router two wants all these routers to know, hey, this PIM join I'm
sending is going along the branch to the shared tree, which means it needs
to be headed towards router eight.
So even though he's multicasting, which means any other routers on here
want to be headed towards router eight.
And we'll see it in here because it's got this upstream neighbor address
that ensures that the next router router eight will pay attention to this
and say, oh, okay, this is for me.
And so he says, he says, okay, number of joins.
I am joining one group.
This is the group I'm joining.
And this is the address not of the source, but of the rendezvous point.
The address of the RP.
And we're not pruning anything.
We're not pruning off any branches.
We are joining a branch.
And what else do we have in here?
I think that's all we've got at this point.
I didn't capture anything else.
Okay, so let's take a look at the the m route state in these routers now.
So let's start by going to router two and see if everything matches what
I've drawn right here.
Show IP m route.
Okay, there we go.
So if you see that in your m route in any router, you know one of three
things has happened.
One of three things.
Either you received an I.G.M.P.
membership report from a directly connected receiver.
In this case, that's true.
And we know that because of the C flag.
The C flag meaning I am connected to the receiver who sent me the join,
the membership report that caused this.
The other reason you might have that is because you received a PIM join.
So for example, the C flag right here, when we go to router eight, we're
going to see that exact same star, C, but the C flag will be missing.
See, S means this is a sparse mode entry.
We're running in sparse mode on the interface.
So both, so this is router eight, no C flag.
So this was created because he received the star, PIM join.
Or as this was created, because we received the I.G.M.P.
membership report.
And our RP is designated right here.
343.3. Incoming interface is fast ethernet zero slash one, which is indeed
the interface leading upstream to the rendezvous point.
RPF neighbor 8288.
And we got that because when we did a reverse path lookup to figure out
how do I get to the rendezvous point, we found in the routing table that
this was the guy who was the next top.
Our EIGRP route told us this is the next top.
And outgoing interface list.
This is the interface where we receive the I.G.M.P.
membership report.
And here's what looks like an R8.
Pretty much exactly the same thing except it's missing the C flag.
And now let's look at the difference of what it looks like in the actual
rendezvous point himself.
Okay, so notice he does list himself as the RP.
He says, I know I'm the RP, but his RPF neighbor is all zeros.
He doesn't need to go upstream to reach himself.
And the incoming interface is null.
And outgoing interface fast ethernet 00, he says I'm going to forward
it in sparse mode.
So now our shared tree from one to two to eight to three, this path is
now opened up. So if the multicast starts to flow, it's ready.
The rendezvous point is ready for it.
So we've looked at what M route state they create.
Now just a couple of additional things about these star, G joins.
They're recent every 60 seconds.
Why is that? Well, let's take a look at this again.
My source isn't sending right now.
So there's really no multicast flowing.
We don't know how long it's going to take.
What if it takes, you know, ten minutes for this guy to actually start
up? Maybe this is a multicast stream that our CEO is going to give at
three o'clock today.
And this guy is joining it ten minutes early.
Well, we don't want this thing to time out in this branch of the tree
to eliminate and go away.
So what we know that these things have a three minute timer, after 210
seconds of no activity, these branches will be torn down.
So in order to prevent that, a couple things are happening.
Number one, we know that every 60 seconds are two sending an IGMP query
onto the segment, saying, hey, any receivers down there watching anything?
And Rader one will respond back with a membership report.
So that's keeping this segment open, the exchange of queries and reports
for IGMP. And we know that when the IGMP membership report comes back,
that's going to trigger our two to send another PIM star, G join.
Now, you might be saying, well, what happens if, you know, over the course
of a minute, 25 or 65 membership reports from different receivers all
come in on this interface?
Does that mean that every single time he receives a membership report,
he's going to send out a star, G join?
No, that would be overkill.
So this guy here is going to send out a PIM star, G join to keep the state
refreshed every minute, every 60 seconds.
Now, if he realizes that there's no receivers left, if IGMP times out
or receives a bunch of leaves, and he says, okay, no receivers left, actually,
let's go ahead and take a look at that.
What's he going to do?
So I'm going to go ahead and remove my IGMP command on Rader one.
He should send an IGMP leave, although it's not mandated by the specification,
that's one of those should things.
And when he sends an IGMP leave, we should see Rader two send a PIM prune
message upstream, pruning this branch.
So let's go ahead and do that.
I'll get my receiver ready to go.
Okay, let's start the sniffer trace.
All right, there's my leave group message.
That's what we wanted to see.
Okay, so here is the IGMP leave message.
So it's actually got its own type code and says, I'm leaving this group,
and that kicked off his default gateway to send a prune message.
Notice it's the exact same message as the PIM join, but in this case,
the join is now zero, and the prune is set to a one.
And this says I am pruning off this tree, and I'm letting the rendezvous
point know about that.
By the way, SWR, in case you're wondering what that is, those are actually
some flags within this message.
The R is called the RP bit in this message.
That means this message needs to go up the shared tree towards the rendezvous
point. That's the ultimate destination.
And that's why we actually have the rendezvous points address in this
field right here because of that RP bit.
The W means that's the wild card bit.
That means I don't know what the actual source address is of this multicast
stream. And that's what creates the star, G state in these routers.
That's what creates the star, the wild card bit.
Have no idea who the source is.
And S, meaning this is a sparse mode join.
So that's what those bits mean, those flags.
What if the RPF info to the RP changes?
So we know that there's a possibility that routes could change.
I mean interfaces could go down, new interfaces could come up, and maybe
the EIGRP route that I have to the rendezvous point right now is not going
to be valid a couple of seconds from now.
So how does PIM account for that?
Well PIM has a timer and basically it's a, if you go into the specification,
if you're curious about this, the name of the timer, although you'll never
be tested on this, is called the Random Delay Join Timeout.
Random Delay Join Timeout, for those of you who like to know that kind
of thing. But basically, that's a timeout that says, okay, check to see
if the RPF to either a source or an RP has changed.
And that timer, according to the RFC, should be no more than 4.5 seconds.
So if the RPF to either a known source or the RP changes, routers running
PIMs should detect that within 4.5 seconds or less.
And if they do detect that, then they'll send another join.
They'll send what's called a trigger join up the new path to the RP.
And what deletes this M route state?
Well, we just saw that an IGMP leave came in.
Let's go back to router two.
Show IP M route.
See, it's gone. Now, did it happen immediately?
Well, let's find out.
Let's create the join again.
Okay, so now we have the star common g state.
And we only have one receiver who lives on fast ethernet 00.
Now, let's have that receiver send a leave message and let's see if that
immediately kills the state.
Because at that point, when that leave message comes in, that will remove
this interface from the outgoing interface list.
The outgoing interface list will be null.
And our question is, once the outgoing interface list is null in a star
common g enter, does that mean BAM, POOF?
It's gone immediately?
Or does it stay in there for a little bit of time?
Okay, it's still in there.
Outgoing interface list is null.
And I believe this will be in here for about, let's see, is there a time
it's counting down?
Yep, this timer right here.
Two minutes and 20 seconds.
Now we're down to two minutes and 11 seconds.
And when this timer counts down to zero, one minute and 56 seconds, I'm
not going to wait.
But when it counts down to zero, then this will be expired.
It'll be gone. But notice we now have the P flag, which means our shared
path, our path upstream to the rendezvous point, has been pruned.
I sent a prune message up to the RP.
And that's what indicates it right here.
Also, so in this particular case, we see that this is going to be gone
in two minutes. What if we go to the router in the middle?
Router eight. Because he received that prune.
See? He also pruned it.
And he's also counting down.
So this will count down to zero, and then this will end up being deleted.
Someone asked, do I absolutely have to have a rendezvous point in order
to get the multicast flowing from the source down to the receiver?
The short answer is in PIM sparse mode, yes.
Now if we were doing PIM dense mode, which just floods everything, no,
we wouldn't need an rendezvous point.
But sparse mode is trying to get away from that.
And so if we're not going to flood everything, we've got to have that
rendezvous point.
So what are some things that could break this?
Well, certainly, you know, a rendezvous point has to be configured.
If all the routers know who the rendezvous point is, but the rendezvous
point himself doesn't know that he's supposed to be playing that role,
it's not going to work.
People will be sending joins and stuff to him, but he won't know what
to do with them because he's not the rendezvous point.
If a particular router does not know who the rendezvous point is, that's
going to fail. Now, how would you know that?
Well, as we saw here, when you do show IPM route, let me zoom in on this
a little bit. Every single router, even the RP itself, should have the
IP address of the RP.
If you ever do this command and you see a star, G entry where the RP field
just says 0.0.0.0, that's bad.
That means the router has no knowledge of the rendezvous point.
There could be one out there, but this particular router that you're on
doesn't know who it is.
So that would be bad.
Another thing, not only does the RP have to exist, not only do routers
have to know who he is, but they have to have a valid unicast route to
reach him. What would be an indication that that is failing?
Well, if your incoming interface list is null and RPF neighbor is 0.0
.0. That's your biggest indicator.
If I have an address here, 3, 4, 3, 3, well, for example, let's do this.
Right now, router, let's go to router 2.
Show IPM route. Okay.
So here, we have knowledge of the RP.
Show IP RPF 3.4.3.3.
And we know that he's learned it via EIGRP.
So here's what I'm going to do.
I'm going to shut down this interface on the RP.
I'm basically going to get rid of the route to 3.4.3 on router 3.
Okay. So router 2, show IP route.
That route should disappear from the routing table very shortly.
Still there, but EIGRP should learn that it's gone in just a moment.
I might need to shut it on the other side as well.
Actually, I do because these two routers are connected to a switch.
They're not actually directly connected.
So I'm going to shut down this sub-interface here on...
So let's just do it this way.
So let's go to router 3.
Let's see. Now let's go to router 4.
Interface fast-eathen at 0.0.34.
Shut that down. Okay, so now it is well and truly gone.
And yep, okay, so the 3.4.3 network is gone.
So now when I do show IPM route, you can see he still knows who the RP
is because I statically configured it.
But RPF neighbor is all zeros.
Incoming interface list is null.
Which means I don't know how to get there.
I have no way to get to the rendezvous point.
So for sparse mode, those are the three conditions.
Well, there's more than that, but those are the three main conditions.
RP has to exist, got to have a route to him, and all the routers have
to know who the rendezvous point is.
Let's see here. There's some other questions.
Let's see here. What if R8 itself is the RP as well?
Is the shared tree going to be formed as well?
Yes, so the question here is, what if R8 was the rendezvous point?
Well, in that particular case, then the shared tree would be a lot shorter.
The shared tree would just be this one hop between R8 and R2, and then
from R2 down to the receiver.
What if R2 was the rendezvous point?
You could do that.
Well, then there pretty much wouldn't be a shared tree that if R2 was
the RP, then the shared tree would just be this direct connection here
to the receiver.
So in my particular topology, I intentionally made the rendezvous point
a little bit further away so we could see more distinct hops of what was
going along, but any of these routers could have been the PIM rendezvous