So, up to this point in time in the previous videos, we've talked about
how the shared tree is built, all the way up to the rendezvous point and
then stopping there.
And then the last video we talked about, okay, once that source, that
server, starts sending out its multicast traffic, the very first router
it's connected to, which you would consider the default gateway for the
source, will take those multicast packets and register them with the PIM
rendezvous point.
And we talked about how that's basically taking the multicast packets
and wrapping them inside of a PIM header and then wrapping them inside
of a unicast IP header from the router to the RP.
So now we're going to look at joining the shortest path tree.
Now recall, I mentioned this in the other video that each router has its
own perspective on what the shortest path tree is, right?
As soon as a router receives a multicast packet, all of a sudden it has
this awakening, it says aha, this is what I've been looking for and now
I know the critical component I didn't know before.
I know who the source is.
So that router, excuse me, then doesn't RP up look up.
It goes into its unicast routing table and says, for me, what's the shortest
path back to that source?
Now that might lead you to ask the question, okay, so does that mean that
anywhere along the tree from the source all the way down to the receiver,
if there's any branches anywhere that branch off and is actually shortest
path, does that mean that any router anywhere along that path is allowed
to switch over to the shortest path tree and leave that core tree and
leave the rendezvous points tree?
Not quite. And so we're going to talk about that here.
But in this particular situation, the rendezvous point does have permission
to do that because remember at this point, the rendezvous point is receiving
register packets, which is causing his CPU to work a little bit harder
than it should. Normally, what we really want is when a multicast packet
comes in, we just want to look up the entry in the mRout table and forward
it on its way. As a matter of fact, if you're running SEP, Cisco Express
Forwarding, you can even do all that without potentially interrupting
the CPU at all, like for example, on switches.
If you've got a multi-layer switch with T cams and forwarding A6 and forwarding
engines and stuff, the CPU and the switch is doing all the PIM processing.
So when you PIM joins, PIM prunes, PIM register packets, they have to
go up to the CPU to be processed.
So if that multi-layer switch, which is sort of acting like a router,
is receiving tons of register packets, that's all going to a CPU.
Whereas if that was just coming in as native multicast, that could all
be handled in hardware on his T cams and his A6 and stuff and it would
never even bother the CPU, never even be seen by the CPU.
So ideally, that's what we want.
So we want to stop this registration process as quickly as we can so we
don't have to do all that extra work.
So we mentioned that the way that that's going to happen is that the PIM
RP is going to send a join message called an s, g join upstream to open
up his own shortest path.
And that's his way of saying, okay, I want to open it up so the multicast
can flow down in its native form.
Once that starts happening and I see that, I've confirmed that, then the
RP says stop the register.
I don't want that anymore.
Stop doing the registration process and he actually sends a PIM register
stop. We talked about that.
Now, I know it's also in this particular case, R2 is joining the shortest
path tree. Now, let me go back to my original drawing here for a moment.
This is what our current topology is like.
Now, I know as I intentionally designed this so that R8 would be able
to get directly to router four without going to router three.
So one might look at this and say, okay, so I would assume then that when
the first multicast packet, when the first register packet, the first
register packet comes downstream to router three and router three de encapsulates
that and sends it as a native multicast down to router eight, not only
would router three send his join upstream trying to join his shortest
path tree, wouldn't we expect router eight to do that as well?
I mean, after all, router eight now knows who the source is and he should
look in his routing table and say, oh, wait, I got this BAM straight connection
over here to the source.
That's my shortest path.
Wouldn't we expect him to also join the shortest path tree?
Well, we're going to take a look at this in a sniffer trace.
I'll tell you exactly what the RFC says.
The RFC for PIMS sparse mode says that the only people that are allowed
to switch over from a shared tree to a shortest path tree are either number
one, the rendezvous point, like we've been talking about, or the last
hop router. In other words, the router that's directly connected to the
receiver. So according to the RFC, in this particular diagram, router
eight would not be allowed to initiate that process.
He would have to receive the multicast on the shared tree and then just
continue to pass it along downstream to router two.
And because router two is directly connected to the receiver, remember,
we saw that with a little C flag because he received the membership report,
that means it would be his responsibility to connect over to the shortest
path tree, not router eight's responsibility.
So we'll actually take a look at that in a sniffer trace and see if that's
true because we know that sometimes with Cisco routers and stuff, they
don't exactly follow the RFC.
So let's see if that's going to happen.
But before we do that, just don't want to jump ahead here.
And by the way, this router two in the RFC, you might see it term two
different thing.
I've seen it called last hop router and I've also seen it termed leaf
routers. It's like a leaf at the edge of the tree.
It goes, the tree goes no further than that.
So they'll call leaf routers or last hop routers.
Okay, so this is a review of what we already talked about.
So I don't need to go in there.
And I've mentioned how S, G joins are used to open up the shortest path
tree. And you'll see that acronym S P T all the time when talking about
PIM, shortest path tree.
So what triggers an S, G join?
Well, there's once again multiple things that could trigger it.
If you happen to be the rendezvous point and you receive a multicast packet
and a register, that's going to trigger you to send out an S, G join.
Because as a rendezvous point, you're going to want to open up your shortest
path. So that's one thing that could trigger it.
What's another thing?
Like we talked about, if you are a leaf router when you receive the multicast
packet. Now this also raises an interesting point.
So you might wonder, well, does the leaf router do that immediately?
Only after he receives 10 packets or receives a certain bits per second.
You know, when does the leaf router decide to do that?
The actual RFC doesn't define that.
The actual RFC for PIMS Farsmo just says the leaf router may, he doesn't
even have to do it.
The leaf router may switch over to the shortest path tree once a certain
threshold is reached.
That's all it says.
Now how do Cisco routers actually do it?
The threshold for Cisco routers is one packet, just one.
So when the very first multicast packet reaches router two and router
two very first learns what that source address is, that is his trigger
to say, okay, do I have a shorter path?
Let me join it. So that's the threshold on Cisco routers.
Now you might say, do I have another option?
Is there something else I can do?
Let me show you what the command is to modify that behavior.
You don't have a lot of options.
Really, there's only two.
Only two options you have available to you.
So I'll go on the leaf router here.
And the command is IP PIM.
And then it is SPT threshold.
So Shores path threshold.
And you only got two options.
Zero, which is the default, or infinity, which means never switch over
to the shortest path.
That's it. Nothing in the middle.
So you can decide for yourself under what circumstances you might want
to select infinity.
But the default is switch over as soon as you receive the very first packet.
What state do they create in the M route table?
Okay, so if I go back to my router here, let's just go ahead and use this
guy. Show IP M route.
Okay, so so far we have our star, comma G entry.
Now the star, comma G entry is built based on the shared tree.
Where the only thing we know is the rendezvous point.
And how to get to the rendezvous point.
So if multicast packets start flowing down the shared tree, this is the
construct that we're going to use to forward those multicast packets.
Now you say, well, if the multicast actually starts flowing and we now
know the source, are we also going to use this?
Well, look at a couple things here.
Number one, incoming interface.
An RPF neighbor.
This is all based on our knowledge of the rendezvous point.
If I'm actually receiving the real multicast data, this wouldn't be relevant,
right? Because the incoming interface and the RPF neighbor to get to the
actual source itself might not be this.
It might be something different.
Also, I wouldn't need a star here anymore because now I would know what
the source address is.
So the moment a router actually receives the very first multicast packet,
it creates a second entry in here, which is called an S, comma G entry.
So let's go ahead and do that.
Let's start at the stream.
Basically do my ping again.
Okay. And actually I have to go to router eight because during the break,
I added something in here that might potentially screw up our demonstration.
So I just want to get rid of that.
Okay, so let's look over here at router two now.
Show IP, M route.
So here we see what's called an S, comma G, M route entry.
S because hey, we actually know who the source is right there.
So the incoming interface and the RPF neighbor is actually relevant now
to the source, not to the rendezvous point.
Now my particular topology, I actually made it so that on R2, he would
prefer this serial link to get to R4 rather than these fast ethernet links.
I just did that by manipulating EIGRP and using offset lists and stuff
like that. But R2 says okay, to get to the four five network, this is
the preferred path.
And once again, I can just check that, show IP RPF, four dot five dot
four dot five. And it says, I prefer to use serial zero one zero, and
that's via EIGRP 100.
So that's what we use as the incoming interface.
And the RPF neighbor is, well, like it sounds, the next top neighbor going
up that direction.
Now when there's a lot of rules surrounding this that we have to go through.
So number one, when an S, comma G is first formed, it basically just takes
whatever is in the outgoing interface list of the star, comma G, and just
copies it down here.
So normally they're the same.
There's one circumstance where that's not going to happen.
There's a rule of PIM, and this actually exists for both the star, comma
G and the S, comma G, that says you can never have your incoming interface
in the outgoing interface list.
In other words, your incoming interface can't be the same as your outgoing
interface. So if you see in the outgoing interface list null, meaning
nothing, that could be why.
But in this case, we don't have to worry about that.
So the incoming interface is serial zero one zero, and he just copied
this down here. Okay, what does the J mean?
The J flag means I have sent a join in this direction.
So in this particular case, because this is the shortest path tree, that
means I have sent an S, comma G join up the shortest path tree.
Now the J flag by itself is not proof that we've actually received any
multicast data from that direction.
All it means is that we've tried to open up that direction.
What we would normally want to see after the J flag, and I'm going to
investigate this here, would be the T flag.
Normally we'd see the T flag after the J flag, and the T flag actually
means I've received actual multicast data from the shortest path tree.
Now, why are we not seeing that in this particular case?
Well, let's do a little bit of troubleshooting here.
We know that in order to receive multicast traffic in this direction,
we need to have PIM right here.
Okay, so question number one, does router two have a PIM neighbor on serial
zero one zero? If he has a PIM neighbor, then that's proof that we actually
have enabled PIM on router four.
So let's see, show IP PIM neighbor.
And he does not.
All right, so we've only got a neighbor on fast Ethan at zero one.
We do not have it on the serial, so that's why we're not receiving traffic
that way. So let's take a look at router four.
Yes, and Peter just to validate, you really need to see the T flag in
this entry here to verify that you've received multicast traffic down
the shortest path tree.
All the J flag means is I've attempted to join that tree, but we don't
know if it's working yet.
And this particular case is clearly not working because I don't even have
a neighbor on that interface.
So why not? Let's go to router four.
Show run interface serial zero one zero.
And there we go.
I did not enable PIM on that interface.
So that explains that.
Okay, is the ping still going or is it done?
Yep, still going.
So now let's go to router two.
And there we go.
Now we've got the T flag.
That's good. So that means we have actually started receiving multicast
traffic from the shortest path tree.
Okay. And just for in the event that you're watching this recording and
you skipped over the previous section on PIM registers, in that particular
section I did a snipper trace of a PIM S, let's just take a look at that
real quick. So this is what an S, G join looks like.
It still goes out as a multicast using the same PIM destination address
of 2240013. So it's hop by hop.
So the source address will change hop by hop by hop.
And in the body of the PIM message, it's type three, once again, join
prune. Upstream neighbor, who is this going to?
Who's my RPF neighbor I'm sending this to?
And it'll say, number of joins, how many groups am I joining?
So what really differentiates a star, G join from an S, G join are the
flags right here.
We saw in the star, G join that in addition to the S bit, we had the W
bit and the R bit.
The W bit was the wild card bit, meaning I don't know what the source
of the stream is.
So this IP address, if the W was here, that would mean this IP address
is the rendezvous point.
But based on the fact that the W is missing, that means this is actually
the IP address of the source of the stream itself.
Also, the R bit is missing.
The R bit is what's called the RP bit.
If you actually look in the PIM specification, it's called the RP bit.
And that would mean this message, whether it's a prune or a join, is going
up the RP tree. It's going up the shared tree towards the rendezvous point.
Once again, that's missing here, because this is not going up the shared
tree. This is destined to go up the shortest path tree.
So other than that, they look fundamentally the same, a star, G join and
an S, G join. The body looks the same.
You really have to look at the flags here to see.
Is the W in the R bit here or are they missing?
That's what differentiates the two.
Now, I mentioned that one of the things that could cause S, G state in
the router is if you're actually receiving the multicast traffic itself.
There's another situation that could cause this.
If you receive an S, G join from a downstream router, for example, let's
not use this one.
Let's say, for example, that we have this situation.
This guy's the RP.
We'll just call this guy router one, router two, and router three.
We'll put our receiver right here, and we'll put our source right here.
All right, so we know that initially once the multicast very first starts
flowing, it's going to go in this direction to the rendezvous point, down
the shared tree, and then to the receiver.
So right now, router two has no state at all.
He has no M route state for the stream.
Nobody has ever asked him for it, either IGMP or PIM.
So if he did show IPM route, we'd see nothing.
Nothing related to the stream.
But when router one is trying to join the shortest path, if we presume
that this is the shortest path, he'll send a PIM S, G join upstream.
And like we saw in the body of the message, he'll say neighbor router
two, router two's IP address, and then he'll give the source and the destination,
right? He'll give the source of the stream.
Let's just say that this is xxx.
He'll have in here source equals xxx, group equals, you know, whatever
it is. So now even though router two initially had no M route state at
all, once he gets this S, G join, that will actually create S, G state
in his M route table.
And then he'll be able to then create his own S, G join and send it up
this way. One other key component, you might be tested on this on some