We've seen all along that when you do show IPM route, it's very possible
that you might just have a star-comagee entry, right?
So if there's no multicast flowing but you've received a star-comagee
join, you'll have star -comagee state.
And so that means I'm ready.
I'm waiting to forward this multicast traffic.
Somebody has asked me for it.
An s-comagee entry cannot stand alone.
Cannot stand alone.
So in other words, when router 2 here creates this s-comagee entry, he
has to also create a star -comagee entry as well.
The two have to go together.
So even though he never got an IGMP membership report, even though he
never got a PIM star-comagee join with that wild card bit set, once he
creates an s-comagee entry, he's got to create a star-comagee entry as
well. They both have to be there.
So s-comagee, what analogy I sometimes use is think of the star-comagee
as being like the big brother and the s-comagee as being like the little
brother, right? The big brother who's 15 years old, he can walk out of
the house and walk around the neighborhood and ride his bike all by himself.
Little brother who is the s-comagee who's only 7 years old, he's not allowed
to do that unless big brother goes with him.
So don't know if they'll help you or not, but there you go.
Also, the once traffic starts flowing down the shortest path, it's the
s-comagee entry that's used to actually forward that traffic.
So what I mean is you'll see the star -comagee that's got some outgoing
interface list and you'll see the s-comagee that has an outgoing interface
list. Whatever's in the outgoing interface list of the s-comagee, that's
the important one.
That's what's used for actually forwarding the multicast.
When it's going down the shortest path, if it's going down the shared
path, then the star-comagee entry is what dictates the forwarding of the
traffic. A couple of additional things here I want to mention.
I don't have a whole lot of redundancy in this particular topology here.
So what if I had something like this?
Let's get rid of this line right here.
Let's say we had a switch and we had two neighbors, two upstream neighbors.
So in other words, actually it's not even deal with the switch.
Let's just put it like this.
Router one could either use router two or router four to get to the source.
So in this particular diagram, hopefully it's very clear that going through
the rendezvous point is not the shortest path because we've got four routers
to go through to get to the source where we can only go through two routers
if we go through router two or router four.
So the question now is, okay, when router one needs to open up his shortest
path, he's going to say, hmm, I have redundant shortest paths.
I could go via neighbor two or neighbor four.
So the question is, where is he going to go?
Where is he going to send his s, g join?
According to the specification, this is what you'll see.
It's the neighbor that has the highest IP address.
That's basically what it boils down to.
So if this was two dot two dot two dot two and this was two dot two dot
four, then that particular case, the s, g join would have gone via router
four. The neighbor with the highest IP address when you have redundant
paths. That's also the case in the shared tree, right?
If I was a router and I had multiple ways to get to the rendezvous point
and they were all the same EIGRP distance or all the same OSPF cost, I
would choose whichever PIM neighbor had the highest IP address.
That's where I would send my joins to get to the rendezvous point.
So we know that s, g stays created but it also must be maintained.
So this is no different.
Just like we talked about how in the shared tree, once it's built, every
minute, if I'm a router that's got a directly connected receiver, every
minute I'll send another star, g join upstream and so they'll go all the
way to keep that state refreshed along the way.
Same thing is true of the shortest path.
Every minute, every 60 seconds, routers who need that show us path will
send s, g joins upstream to keep it refreshed.
So when is that s, g state deleted?
Well, if those periodic joins from the downstream neighbor stop, so let's
say that the multicast source was behind me and I'm a router, you're a
router, and I'm your shortest path to get to that guy.
So right now, my outgoing interface list is pointing to you.
You sent me an s, g join indicating your interest.
I put you into the outgoing interface list.
So it's your responsibility every minute to send me s, g joins to refresh
this. But what if there's a switch or a hub in the middle of us and your
connection to that switch or hub goes down?
I don't know that.
As far as I'm concerned, you're still alive.
Well, so in that particular case, if the periodic joins stop, once again,
that timer of 210 seconds, that's the magic number, if after 210 seconds,
I'm no longer receiving those joins from you, then I will delete that
outgoing interface list.
Now, once again, in that particular situation, most likely what would
happen is I'd say, well, wait a second, I've lost my PIM neighbor, right?
Because in the case of PIM, you're also sending me PIM hellos every 30
seconds. And if I missed three of those, I declare a neighbor to be dead.
So one would assume that if that link between you and the switch went
down, PIM would detect the lost neighbor in, we saw 105 seconds, that
was that timer, before that 210 second timer expired.
I'm not going to test that right now.
But I just want to do you know, according to the specification, if the
periodic joins stop in 210 seconds elapses, that's one criteria for removing
that interface from the outgoing interface list.
If the multicast source stops transmitting, once again, 210 seconds later,
I'll wait, right?
If the multicast source stops hitting me on the back of the head, 210
seconds later, I will remove my outgoing interfaces.
And that happens for every router down along the way.
So in this particular topology right here, if the source stops, 210 seconds
later, router four will remove his interface and router one will remove
his interface from the outgoing interface list.
Or if you receive a PIM prune message.
So prune message is a way of saying, hey, I don't want this anymore.
Like in this particular case, once router one has successfully opened
up his shortest path tree, he will send a prune message up to the rendezvous
point, saying, I no longer need this branch of the tree.
So we can actually see that.
I don't think we've actually focused on a prune message yet.
But let's go back to our original topology here.
Now I think router five at this point is probably done, sending his pings.
Yep. Okay. And if 210 seconds has elapsed, which it probably has, we should
no longer see the s, g state in any routers.
Yep, that's gone.
That's expired. So I'm going to go ahead and start it up again, the ping.
And what we're specifically going to be looking for now is once router
two opens up this path, we should see him send a PIM prune to router eight.
And so let's go ahead and capture that prune just to see what it looks
like. So on router eight, I want zero slash one is his incoming interface.
And according to this, that's going to be zero slash two on the switch.
Okay. So let's get ready.
I'll go to router five.
And let's start up the snipper trace.
Okay. This is probably the prune right here.
Let's find out. Yep.
Number of prunes one.
So once again, the RP bit is set, meaning this is going up the shared
tree up to the rendezvous point.
And we're saying I am pruning off this source and this group.
So it's the exact same message format as a PIM join, except instead of
having join, we have prune.
So we've already talked about how PIM prunes use the same format as PIM
joins used to encourage upstream neighbors to stop forwarding multicast
traffic to us. Now, why does it say encourage, why isn't it force the
upstream neighbor to stop forwarding multicast traffic to us?
Well, here's why.
If I had this type of situation where I had, let's say, let's just make
it easy, a hub. Okay.
Let's say this is my RP.
We have router one, router two, and router three.
I'll connect to the same hub.
Okay. Let's say that right now both of these PCs, PCA and PCB, are multicast
receivers. And they're both receiving the exact same group.
You know, they're watching the CEO's video presentation right now.
So the multicast is flowing down.
And in router three, we have both star, and state.
And fast ethernet zero, zero is in the outgoing interface list.
Okay. If all of a sudden receiver A sends an IGMP leave message because
he's no longer interested in that stream, that's going to cause router
one. He's going to say, okay, I'm going to delete this interface from
my outgoing interface list.
He's going to say, oh, I have no more interfaces in my outgoing interface
list. My outgoing interface list is null.
So that's going to cause him to say, all right, I don't need this anymore.
So he's going to send a PMPRUN message, which we just saw in the sniffer
trace. That's going to go into the hub.
Router two will see it.
Router three will see it.
Now if router three immediately removed this interface himself, we'd have
a problem. Because PCB would stop getting the stream.
And he's still interested.
He's a still and interested receiver.
So the way that PEM works is that in this particular case, when router
three receives this prune, he's actually going to wait a few seconds.
I think it's about five seconds, although don't quote me on that.
But it's a few seconds.
It's not a very long time because the assumption is, hey, if router two
also saw that prune, what's he going to do?
He's going to say, wait a second.
I still have somebody who's interested.
And so that will trigger him to send another PEM join.
In this particular case, they'll probably be an s-coma-g join because
he does know the source.
And so that will override the prune.
And so that will keep this interface in the outgoing interface list.
So that's why we say PEM prunes encourage the upstream neighbor.
Because in this particular case, router won't say, oh man, I send a prune,
but I'm still getting that multicast.
Well, there's really nothing he can do about that.
Every minute he'll continue to send a prune and say, hey, please prune
me. And router two will override that by sending note, keep it going,
keep it going. So that's what triggers them.
A PEM prune is triggered when either you receive some sort of a leave
message from your receiver or if a downstream interface just times out,
right? Maybe the receiver walks away, never sends a leave, and eventually
you, you know, IgMP times out that interface, that would trigger a prune
as well. Or if you receive a prune from a downstream neighbor.
So in this particular case, when router B, or when PCB, finally does decide
that he's done, he doesn't want to watch it anymore.
Well, that will trigger router two to send his prune message.
That will remove this interface from the outgoing interface list.
And now that router three realizes that his outgoing interface list is
null, that will trigger him to send his own PEM prune upstream.
So that pretty much concludes this section on talking about joining the
shortest path tree.
Oh, there was one other thing we want to check before I finished.
Let me go back. We want to check this.
We want to see, okay, when the multicast does start flowing down the shared
tree, according to the RFC, the very first person to switch over has to
be the leaf router.
That this intermediary router of router eight here, because he has no
connected receivers, is not allowed to do that switchover process.
So let's see if that is indeed true.
I'm sure it probably is.
But let's see here.
How are we going to test that?
Well, here's what I think is going to happen.
If everything goes according to how the RFC says it should go, then when
router two, the leaf router gets the first multicast packet, he should
join the shortest path tree.
Once that shortest path tree opens up, he should prune router eight.
Router eight should then send a prune or router three.
So in a sense, we should never see an S, G join originated from router
eight. We should see prunes originated from him, but we should not see
S, G joins originated with his IP address.
So here's how we're going to test that.
Let's just go on the switch to every interface that's connected to router
eight, which is zero two and zero thirteen.
We'll capture all inbound and outbound traffic, and we'll see if he ever
actually sends an S, G join, which we should not see.
All right, so this is done.
Let's clear out the MROUT state, show IP, MROUT.
Okay, so the S, G state has already timed out.
Let's go to the switch.
So right now we're monitoring zero two.
We want to add zero thirteen to that list.
All right, let's go back to router five.
Start our snipper trace.
Okay, so at this point, I'm not seeing the multicast go through router
eight anymore, because right now that's all I'm looking at is interfaces
connected to router eight, and I'm not seeing any of the multicast going
through there. It stopped right here.
So let's see here eight two eight two.
That's router two eight four eight eight.
That is router eight eight four eight eight.
Okay, so what did router eight send right there?
Router eight eight four eight eight.
He sent a prune.
Okay, so this is him sending a prune up the shared tree, and he did that
in response to the prune that he received.
So this is most likely the prune that he received.
So this is, yep, so this is the prune from router two who's connected
to our receiver who said, hey, look, neighbor eight two eight eight.
I don't need you anymore.
Let's prune off that shared tree between you and me.
And router eight forwarded that prune himself to the rendezvous point.
So sure enough, we do not see any join messages from router eight.
Here he's joining to the auto RP, so that doesn't count.
So sure enough, that confirms what the RFC says, that only the leaf routers
or last hop routers are allowed to join the shortest path tree.