So at this point we're pretty much done with the theory of PIMS sparse
mode and before we move into the concepts of dynamically discovering RPs
via auto-RP or the PIM bootstrap router, just want to finish up this topic
of PIMS sparse mode by going back to the commands.
Some of the commands you've already seen as I've talked about them and
displayed them in the lab and some of the commands will be new to you.
I just wanted to show you the most familiar ones that you're most likely
to use. Okay so verifying that PIMS sparse mode is working.
Certainly you can do show IP PIM interface.
I'm going to do each one of these as we go along here.
So show IP PIM interface and as you can see it shows you the address of
your interface. So in this case 454, that's actually the address of our
fours interface.
So this is confirming basically that PIMS is enabled on these interfaces
with these IP addresses.
I also shows you what version of PIMS, whether you're in sparse or dense
mode. There's also a mode called sparse dense and we'll talk about that
next when we talk about auto-RP.
How many neighbors you've got if any?
How often you're sending out PIM Hello packets which they call queries
here. The priority of the designated router which is one by default and
who is the designated router.
And some interfaces don't need it like point-to-point interfaces like
HDLC and PPP. There is no need for a designated router on that kind of
an interface. Show IP PIM neighbor gives you a little bit more detail.
Namely what you're getting out of this one here are these timers.
How long in total have I been neighbors?
So with this particular neighbor it's been almost 22 hours I've been neighbors
with this guy. And this is showing you okay if I lose a Hello, if I don't
continue getting PIM Hello's in one minute and 37 seconds I'm going to
tear down that neighborship.
Then we also have show IP PIM RP.
Now this particular command show IP PIM RP.
This command is really only useful if you statically configured an RP
like I've done up to this point.
Basically it just confirms that you have indeed statically configured
an RP and what particular groups that RP is servicing right now.
In this case it says expires never because it's never going to expire.
It's a static RP.
There's no mechanism here to verify that the RP actually exists and is
reachable. This next command show IP PIM RP mapping.
This is really if you're going to be using some sort of dynamic discovery
of the RP like auto RP or PIM BSR.
This is the command you're going to want to use to verify that you've
actually dynamically learned of an RP and what particular groups that
RP is servicing.
In this particular case there's not a lot of output here.
It says static, who the RP is and he's the RP for every single group but
you get a lot more output from this if we had dynamically learned it via
auto RP or BSR. We'll look at that coming up in the next set of videos.
Okay, there's some ways to modify the behavior of PIM.
IP PIM accept-register.
So what this is talking about is by default the rendezvous point will
accept any kind of register message that comes in from anybody.
There's no authorized list of routers out there that are authorized to
register. Any router can register which certainly could introduce the
concept of a rogue router.
Maybe somebody puts a rogue router into the network and intentionally
hammers the PIM RP with this gobs of register messages in an intentional
attempt to bring down the RP.
So in this particular command here you could say well only RP's, the only,
yeah, RP only routers connected to sources that match this list are actually
allowed to register with me.
So if a register comes in from any other router you'll just silently discard
it. IP PIM register rate-limit so if you're concerned about even the authorized
routers out there sending too many registrations, too many multicast sessions
are starting up at the same time, you could rate limit it using this command
here with bits per second.
IP PIM register-source.
Now this is a command that you would actually do on any router that's
going to be originating the register message.
Now normally a router when it says okay I need to register with the RP.
What that router will do is he'll go into his routing table, he'll do
an RPF look up and he'll say okay, what's the interface I would use, what's
actually the incoming interface that I'd use to get back to the RP?
He says oh according to my routing table my best route to the RP is fast
Ethernet 00. Well at that point he would pull that IP address from fast
Ethernet 00 and use that as the source address for his register messages.
There may be some scenarios where you don't want him to do that.
That regardless of what interface he uses to get to the RP, maybe you
always want him to use his loop back as his source address.
Well this would be the command that you would use to modify that behavior.
IP PIM, SPT Threshold, not going to talk about that, we've already covered
that I think in quite a lot of detail in some of the other videos.
And IP PIMs sparse SG-expiry-timer.
So what's this talking about?
It doesn't stay there forever, it has to be refreshed, and there's a couple
of things that could refresh it.
Every time an actual multicast packet arrives that matches that s-coma
-g entry that refreshes the state.
Or if we know also know that routers, even after they've joined the shortest
path tree, if they still want that multicast, they will periodically once
a minute send out another s-coma-g join to refresh the tree, and that
will also refresh s-coma-g state in any router that receives that kind
of a join. So if that doesn't happen, if a router's sitting here with
an s-coma-g entry and let's say the multicast stops, well by default after
a little bit over three minutes after 210 seconds that s-coma-g entry
will vanish, it'll go away.
Well, maybe you've got some scenario where you say, you know what?
Once the s-coma-g's are created in my router, I want it to stay there
for a long time, even if I stop getting the multicast.
I just don't want to have to keep recreating the s-coma-g over and over
again. I can't really think off the top of my head why you'd want to do
that, but this command would actually allow you to do that.
So that's what this is talking about.
If you set this command to its maximum, which is 57,600 seconds, that's
equal to 16 hours.
So basically what that's saying is, okay once an s-coma-g entry is created,
even if it's not refreshed, just keep it in there for up to 16 hours before
you expire it. So if you have a situation where that would be useful to
you, that's where that command would help.
And then the last command here is IPPIM NBMA-mode.
So imagine this scenario.
Actually, let me just go ahead and draw it here for a moment.
Let's say we had a WAN.
I'll just use frame relay as an example because frame relay is used a
lot on the CCNA and the CCNP.
And on this WAN we've got a hub and spoke scenario.
Where we've got router A as the hub and router B and C as the spokes.
Okay, so the only way that B and C can talk to each other is via router
A. They don't actually have any frame relay PVCs directly to each other.
Well, we know that like in the case of routing protocols, if we were talking
about OSPF or EIGRP or something, a lot of routing protocols, if router
B, and let's just say that on router A, his physical serial interface
is doing everything.
Okay, so our IP address is here.
We don't have any sub-interfaces.
This is a multi-point interface.
This is a non-broadcast, multi-axis interface.
Well, in this particular scenario with routing protocols, a lot of times
you'd have to disable split horizon, right?
Because split horizon is the rule that says, look, if a routing update
comes in on serial 0-0, in order to prevent routing loops, you are not
allowed to turn around and reflect that route right back out the exact
same interface where it came in.
So you'd have to, that split horizon prevents that.
So you'd have to turn off split horizon.
Well, the same kind of thing happens here for multicasts.
And for joins and things like that, if a multicast comes in right here,
or remember, the general rule of PIMS says that the incoming interface
cannot show up in the outgoing interface list.
Well, if that rule was true, then when this interface, when the multicast
came in here on serial 0-0, we would not be able to put that exact same
interface into the outgoing interface list, and router C would not be
able to get that multicast.
So, in order to allow that, you would want to use this command right here
on that non-broadcast, multi-access interface.
So this is basically sort of like turning off split horizon, but for multicast
traffic. That's what that command does.
And just want to finish up here a little bit by just explaining a little
bit more about the flags that you might see in your M route entries.
We've talked about a lot of these, but some of them I have not covered.
So the C flag. We talked about that.
If you see the C flag, that means one of two things.
Either this router has actually received an IGMP membership report, or
an MLDP listener report, meaning it's directly connected to a receiver,
to a laptop, to a PC.
Or it's actually gotten the multicast packet, and it realizes the source
of that multicast is directly connected to that router.
So there's a connected receiver or a connected source.
That's what C means.
The L flag haven't really talked about this, but knows how in my particular
lab, what I did is I took a router, router one, and I used that command,
IGMP join-group on that router.
And that's how I turned that router into a receiver, because routers don't
normally send out membership reports.
That's the job of laptops and PCs.
So in order to replicate that behavior, I used this command.
Well, if that router was also running PIM, which it's not, then in the
M-ROT entry it would have had the L flag, meaning I'm also a receiver
of this multicast.
When the multicast comes in, I'm not just going to forward it.
I'm actually going to send it to my CPU for processing, because I want
to see it. The F flag.
So this is called the PIM register flag.
Sometimes people get a little bit confused on this, because they see the
F, and they think, oh, that means that registration is happening right
now. And then they do show IPM route, show IPM route, they keep doing
it, and for the next 30-40 seconds, minute -5 minutes, the F flag is still
there. And they say, oh, I have a problem.
Registration should only happen for a second or two, and then it should
stop. Why am I still seeing the F flag?
Well, if you actually are in the process of registering right now when
you do this command, you'll actually see in the star, G entry the word
registering. It'll say that.
So you have the F flag, and it'll say, registering.
Like it says here, if you only see the F flag, but you don't see the word
registering, that means this router previously registered this flow.
It's just sort of like a historical marker saying, I successfully registered
it in the past, but not doing that anymore.
That's what the F flag would mean.
The J flag. So this means a router has attempted to join the respective
tree. So for example, if you see the J flag in the star, G output, you
might be tempted to think, and I think I actually misspoke on this in
a previous video.
I think I said, well, when you see the J flag, that means this router
has sent a PIM join up that tree.
Well, not necessarily.
What the J flag really means is the router wants to join that tree.
It's not really proof that a join actually went out.
So for example, if you see the J flag in the star, G output, that means,
okay, the router, something triggered the router to believe that it needs
to join the tree.
And so it needs to create a star, G join and send it up that tree towards
the rendezvous point.
Now, did it actually succeed in that?
Maybe, maybe not.
We don't know. The J flag just says it knew that it needed to do that.
Like in one of my previous labs that I was doing, if I go back to the
drawing here for a second, let's bring this over here.
So I had one lab, if you recall, is several videos ago where I had forgotten
to configure PIM on this interface right here on R4.
There was no PIM on here.
And yet there was PIM on this interface of R2.
And what I noticed was when the multicast started flowing down, this guy
created an S, G, E, and R2.
And it was the entry for it.
And it listed serial 010 as the incoming interface.
It said, okay, if the multicast comes down the shortest path tree, it
should come in the serial.
And it had the J flag.
And I initially thought, okay, well, that means that he sent a join up
there. But if you remember that video, I said, huh, something's missing.
If multicast traffic is actually really flowing down the shortest path
tree, in addition to the J flag, I should also see the T flag.
And that's the next bullet point that's coming up in the slide.
The T flag indicates I have actually received at least one multicast packet
down the shortest path tree.
So it's working.
But I didn't see that.
In my particular case, all I saw was the J flag and not the T.
And that made me think, okay, so he tried to join this tree, but multicast
isn't flowing down it yet.
What's going on?
And that's when I found out that PIM was not configured on router 4.
So I assumed that router 2 had sent out his join, but nothing happened
because on the other side, the router couldn't process it.
But I actually did a little bit of debugging.
It turns out that he realized he did not have a PIM neighbor.
Router 2 realized that even though he had PIM on his serial, he had not
learned of a neighbor on the other end of the serial.
And so when I did a debug, I realized that he didn't even create the join
in the first place because he was smart enough to realize, hey, what's
the point of creating an S-coma G join in sending out this link if there's
nobody at the other end of the link to even receive it and process it?
So that's why I say that J flag simply means he wants to join that branch
of the tree, but whether or not he actually succeeded in sending a join,
you can't tell just by that flag.
You'd have to do a little bit more troubleshooting to figure that out.
And then, like I said, lastly, we have the T flag, which is that's what
you want to see, right?
If the T flag is on the shortest path three, that's good.
That means I've actually received at least one multicast data packet on
the shortest path three.
There's one other flag I want to talk about, which is the R flag.
And this one sort of confused me a little bit.
I had to dig into the RFC and really think about it a little bit.
So the R flag is, you will see this only on routers in the shared tree.
So if you think about the path from the leaf router up to the RP, it's
only somewhere on that path that you'll see in a S, G entry, the R flag.
Now, what's that meaning?
Let's go back to this for a second.
This one. Okay, so we know that initially, once the multicast, if we know
that this guy is the RP right here, oops, what is that?
Okay. Once the multicast starts flowing down here from the RP, it's going
to go this way, and then it's going to go this way, and then it's going
to go this way. So in router eight right here, I'm focusing on him for
the moment. When he actually gets that multicast traffic, he's going to
have both the star, G, which he created a long time ago.
And then when you see that multicast packet, he's going to create an S,
G as well. And this particular case, the outgoing interface list of the
S, G is going to be fast Ethernet zero slash one.
Okay, good to go.
But we also know that as soon as router two, the leaf router gets that
very first multicast packet, he's going to try to switch over to the shortest
path tree. And if we assume that he's successful, and now he's receiving
traffic down the SPT, well then we know that he's going to send a prune
message. He's going to send what's called an S, G prune.
And what's that going to look like?
Well, in the body of that prune packet, it's going to have the source,
four dot five dot four dot five.
It's going to have the group, whatever it is.
And then it's also going to have the RP bit.
This is a flag, the RP bit set.
That's going to be set to a one.
And he's going to send that to router eight.
When router eight gets that, he's going to say, okay, this prune, because
it's got the RP bit, means I need to prune off this interface.
So he'll then stop forwarding the multicast on that link.
He'll remove that interface from the outgoing interface list.
And so now that's going to end up being null.
And then he's going to create his own prune packet and send it up this
way, which will then end up pruning this off right here.
So what does it have to do with the R flag?
Well, if I go into router eight's M route table after this has been done,
now we can assume that after this point in time, remember if an S, G state
has an outgoing interface list that's nothing, it's empty, null.
Well, it's got this countdown timer, right?
It's only good for 210 seconds.
And after 210 seconds, if nobody needs to use this, he's going to delete
it. So let's say I go on router eight before that time has expired.
So right after he's received the prune, but before the 210 seconds has
elapsed, then what I'm going to see in this S, G state is the letter R.
I'll also see a P.
So he'll say, actually, I think the P might come before the R, but basically
the P will say, this is pruned.
I'm not using this.
I've pruned this off.
And the R will say, I have pruned this because somebody downstream from
me set me an S, G prune with the RP bit set to a one.
Now you're not going to see that in the rendezvous point.
You'll all only see that in routers in between here.
So like router eight, if we had another router right here, we'd see it.
If we had another router right here, we'd see it.
But the routers in the middle who received the prune and have forwarded
it on, they will have an outgoing interface list of null, and they'll
say RP, and notice it's only in the S, G entry.
You're not going to see that in the star, G, only the S, G.
And I can actually replicate that pretty easily here, in case you want
to see it. I'll do the exact same thing.
I'll just go ahead and start the multicast stream from router five.
And by the time I get to router eight, like two seconds later, it will
already be pruned off.
And you'll see that he actually has the R flag in there.
Let's just do that.
Let's go over here to router five.
Let's do our ping.
Okay, already the stream has been switched over, and we can see that in
router two, the leaf router, show IPM route.
We can see that he's got the S, G entry.
He has joined or attempted to join the tree.
Was he successful?
Yes, he was successful because he's got the T flag.
He's actually receiving multicast traffic down the shortest path tree.
Now if we go to router eight, who's in the middle, who's no longer involved
in this traffic in any way, he's been pruned off, we can see in his S,
G entry, it says P, it's been pruned, and why was it pruned because of
R? Because we received a pruned message with the RP bit, which caused
our outgoing interface list to become no.
So this now is only going to be good for another, well, right now it says
two minutes and 28 seconds.
If I do it again, we're going to see it counting down.
Now it's only good for two minutes.
So two minutes from now, this entry will vanish, and then this entry will
also vanish as well because neither one of them will be needed at that