Okay, so we've already talked a little bit about this concept of the shared
tree, which is the path from the rendezvous point down to wherever the
receivers are. So there's potentially more than one shared tree, right?
If I've got 50 receivers spread throughout my network, I could potentially
have 50 different shared trees, 50 different paths from that RP leading
down to the various receivers where they live.
Let's go into a little bit more detail now about how all of that is built.
So first I'm going to show you some of the initial commands so we can
get this built, and then we're going to go back into the theory and see
how all this stuff works.
So I mentioned multicast routing has to be globally enabled, so IP, multicast,
dash routing. And then PIMS sparse mode must be enabled per interface,
so that's IP PIMS sparse dash mode, and then only one other thing is necessary.
How do you find the rendezvous point?
So we're just going to do it nice and simple.
We're going to statically configure a rendezvous point with the global
command IP PIM RP dash address and then the address.
So what this is doing right here is this is saying any multicast anywhere,
whether it's 224, 239, 228, whatever, they're all going to this one guy,
this one rendezvous point, 777.
Okay, so let's go ahead and start creating this, and then we'll start
talking about it as we go along.
So going back to my diagram right here, as you can see, router three at
the bottom is going to be my RP.
And so I'll just have his address on his spec.
You know, normally you'd probably select a loop back on that router, but
because that's not part of my diagram, I'm just going to choose his address
on fast ethernet 00, so 343, that will be the address of the rendezvous
point. So let me just real quickly here go into these four routers, routers
two, eight, four, and three, and quickly enable them for PIM.
So starting with router two, IP multicast dash routing, interface fast
ethernet zero slash one, that's the interface is going upstream to the
RP, IP PIM, sparse dash mode, and then give him knowledge of who the RP
is, and I'll talk about this whole DR thing coming up, IP PIM, RP dash
address, 3.4.3.3.
Now one other thing, let's take a look back here at our diagram.
What I've just done is I have enabled multicast routing on R2, and I've
enabled PIM on this interface.
I'm probably also going to want to do it on the serial interface, so let's
go ahead and do that as well on serial zero slash one.
But don't forget, you're also going to need to enable it in this particular
case on the interface leading to my receiver.
Now you might say, why do I need that?
I mean, there's no PIM routers in that direction.
He's not going to form any neighbor relationships or anything.
Here's the reason why we need this.
Number one, if you're using PIM sparse mode as your multicast routing
protocol, a router will not be allowed to receive any incoming multicast
or transmit any outgoing multicast on an interface that's not running
PIM. So if I didn't have PIM enabled on fast ethernet zero zero, router
one, my receiver here could be requesting multicast all day long.
It's never going to be forwarded out fast ethernet zero zero.
Here's the other reason.
We've talked about how receivers use IGMP to indicate their interest in
a multicast group to the directly connected router.
Well routers are not running IGMP by default.
They don't listen to that.
But we enable PIM on this interface that also enables IGMP as a byproduct.
So in order for this router to realize that, okay, I need to send queries
every couple minutes and I need to listen to IGMP membership reports,
I need to enable PIM on this interface.
So let's go ahead and do that.
Interface fast ethernet zero zero puts PIM sparse mode on here and interface
serial zero one zero.
Also put PIM on there.
Okay, let's go ahead now go into R3.
Okay, and the rendezvous point himself also needs to know that he is the
rendezvous point.
So I give him the exact same command I give to the other guys.
I say you are the RP and say oh that's my IP address.
Okay, I guess that's my job.
And my RP, he's going to have it on zero zero and zero one.
Okay, that's all I need on that guy.
So I've done R2, R3, let's go on to R8.
Now look at a couple things.
Before I do anything here on R8, show IPM route.
That's the way to check the multicast routing table.
Well, I have not enabled multicast routing yet on this guy.
So there's nothing there.
Absolutely, you know, it's actually kind of interesting that even shows
us the various flags and stuff that will be used.
But right now the multicast routing table does not exist.
If I do show IPPIM interface, I get nothing because I have not enabled
PIM yet. Now, IP multicast dash routing.
Now, if that's all I do, no PIM yet, show IPM route.
Still, doesn't do much.
But now I've enabled this router to populate this table.
He had no way of populating it before without that command.
All right, now let's go ahead and enable it on fast ethernet zero zero
and then my sub interfaces.
And also give him knowledge of who the rendezvous point is.
OK, so now at this point, well, let me just go ahead and finish it off
here. We've got one more router, router four.
So I should not have done that on zero zero because zero zero is a sub
interface. Thirty four and eighty four.
And lastly, let's give him knowledge of IPPIM, RP dash address.
OK, so in this particular router, let's go to somebody in the middle.
Let's go to router eight.
So right now, this guy is running PIM on his interface.
And I can verify that with show IPPIM interface.
And it shows me every interface where I've enabled PIM.
It shows me the version.
S in this case means it's running in sparse mode.
It shows me how many neighbors I've learned.
It sends I'm sending out PIM hellows every 30 seconds.
We'll talk about designated router in a second.
And here are the IP addresses of the PIM designated router, which we'll
get to. If I do show IPM route, now before I hit enter here, this router,
because he's in the middle, he's never going to receive any I GMP because
I GMP only happens between the receiver and his default gateway.
It goes no further than that.
The receiver hasn't asked for anything yet.
He hasn't joined anything.
Let's just make sure that's true before I make a liar out of myself here.
Right, so he has not asked for anything.
So, when I go into, so there have been no I GMP membership reports, therefore
we would expect that there are no PIM joins.
Nobody has asked to join anything yet.
And my source, he hasn't sent anything yet.
Everything's idle.
Nothing has started yet.
So one would expect that my multicast routing table should be blank.
Should be empty, right?
Show IPM route. What is this?
Where did that come from?
Well, later on, as we get to it, when we talk about auto RP, this particular
multicast address is used by auto RP.
This is actually a reserved multicast address used by Cisco's proprietary
auto RP. And Cisco routers, by default, join that group.
So this router is basically saying I'm ready to dynamically learn of who
the RP is, if auto RP is ever invoked.
So that's what that is for when you see that.
Okay, so everything is set up and ready to go now.
Let's keep going with our theory.
So I mentioned that PIM will not allow forwarding or receipt of multicast
traffic on interfaces unless one of two things is true.
Another PIM neighbor has been discovered on that interface or a directly
connected receiver slash source resides on that interface.
So I'm going back to my diagram here as an example.
Let's say that I had enabled PIM on all these interfaces.
Okay, let's say that.
Now notice the interfaces that I haven't circled and I did that on purpose.
I did not enable PIM here on this sub interface or right here.
In this particular case, multicast traffic is never going to flow.
If my receiver sends an IGMP membership report, we've got PIM enabled
on every interface to get up to the RP.
So we actually will form a shared tree.
This branch right here will be ready and waiting to transmit multicast
if it ever happens.
But here's the problem.
If the source starts sending, well, R4 is never going to receive a request
for that traffic.
In order for R4 to natively forward the multicast, just forward on interface,
somebody has to ask him for it.
He has to receive a PIM join.
Well he's not going to receive a PIM join this way because this interface
doesn't have PIM on it.
And he's not going to receive it.
If a PIM join does come in here or here, he's going to drop it because
he doesn't have PIM enable on these interfaces.
He can't receive PIM.
So that's a demonstration of why PIM has to be enabled on both sides of
a link. Also on the interface connected to the receiver and the interface
connected to the source in order to have everything flowing.
So this can be one source of multicast troubleshooting.
If multicast is not flowing somewhere in your network, it could be as
simple as the fact that you forgot to enable PIM on some link somewhere.
Some interface, some sub-interface doesn't have PIM enabled on it.
So PIM Hello packets are used to discover the PIM neighbors.
And if you're watching this recording, I do apologize.
In the previous recording, I misstated the multicast address of those
PIM Hello's. The correct address is 2240013.
So 2240013 is the address that PIM Hello's are sent to.
So let's actually do a snipper trace of those Hello's right now because
we've got PIM enabled.
I'll just pick one right here.
So we know that the actual physical topology in this case is right here.
PIM is enabled on R2, R8, R4.
So let's just do a snipper trace.
I'll capture the Hello's that are coming in on fast ethane at 0 slash
4 on this switch.
So I'm going to use the span feature on the switch to accomplish that.
I'm not really going to go into the details of how to configure span or
what span does because that's not really relevant to this presentation.
Okay, so at this point, anything that's coming in on, let's see here,
I did 0 slash 7.
So that would be right here.
Okay, R4. So when R4 is sending PIM Hello's, we should capture them and
my wire shark should pick them up.
They go out every 30 seconds so we shouldn't have to wait too long.
There we go. So I'm going to use my laptop or a bug with wire shark.
But a lot of times wire shark won't let me press the buttons up here to
stop something. So let's just expand this.
So here is our PIM Hello.
So notice the destination 2240013 and when we map that down to our destination
MAC address 01005E and D is 13.
It's carried in IP.
Has a time to live of 1 because it's only good on the local link.
And it's got a pretty high DSCP.
It's got an IP precedence of 6.
And you can only get higher than that by going to 7.
So as far as priorities concerns, a pretty high priority packet.
Protocol 103 for PIM.
And here we see the source is, in this case, router 8.
It looks like. Router 8.
And destinations PIM.
And then here is actually the PIM body.
PIM version 2, type code is 0, which means it's Hello.
And the option that says the hold time.
So 105 seconds, which is roughly three times the priority, or three times
the interval of the hello time, which is every 30 seconds.
And designated router priority and state refresh capable.
Talk a little bit more about those in just a minute.
But you can see the PIM Hello is pretty simple.
And here you can see they're going out fairly frequently.
So here's the one from router 8.
And it went out at 42.35 seconds.
So if we go roughly 30 seconds more than that, that should be five minutes
and around 15 seconds or so.
And here's the next hello.
About 30 seconds later, five minutes and 12 seconds.
And we'll talk about these other things, join prunes and stuff coming
up. OK, so PIM joins.
As I mentioned, PIM does not add a branch to the tree until someone wishes
to join it. So PIM actually has something called a join packet to do this.
And you'll see in a lot of documentations, they'll reference like two
different kinds of joins.
Something called a star comma g join and an s comma g join.
We're going to get into the gory details of each of these.
For now, I'll just say both of these are the exact same packet.
It's not like there's two different kinds of PIM packets.
They're both carried in the exact same packet.
The only difference is one little field is different between these two.
But this is the fundamental data structure that's used by PIM to send
a message upstream saying, hey neighbor, look at me, I need something.
I need a particular group.
Add me to your tree.
That's the PIM join.
So multicast forwarding is determined by entries in the M route table,
the multicast routing table.
So we call those M routes.
So what would cause these entries to be populated in the table?
Well, one of three things.
Either a router has received a PIM join.
It has received multicast traffic.
Actually, there's four things.
It has received an IGMP membership report.
So let me actually put that in here as well.
There we go. So a router has received PIM joins or an IGMP membership
report. It's received the actual multicast traffic itself.
Or sometimes it can be dynamically or automatically created.
We saw that the 2240140 was in there for auto RP.
And we didn't have to do anything for that.
We didn't actually receive any auto RP traffic that was just dynamically
put in there. So let's just look at the M route table for a moment.
And I'm going to point out some high level bullet points of it.
And then we'll talk a little bit more about some of the details.
So for example, if I go into here, show IPM route is how we see what's
in there. So these are all your flags.
And these flags will show up in various portions of your M route.
So this is, for example, considered an M route.
These four lines right here.
This is indicating a multicast route.
And these flags, we're going to talk about many of these.
Now, a lot of these have nothing to do with PIMS sparse mode.
So I will point out the most common ones that you'll see in PIMS sparse
mode. But some of them like the Z flag and the Y flag that has nothing
to do with PIMS sparse mode.
So we're not going to talk about that.
So you'll see here, so you can see this is your group.
This is the multicast group.
And we'll talk here in just a second what the star means.
Some timers about how long the group has been active, when it will expire.
Information about who the rendezvous point is.
Incoming interface, you know, where do I expect to receive my multicast
traffic? When it comes in to me, which interface will receive it?
And which interfaces will I forward it out of?
Sometimes the outgoing interface list will say no, meaning I have nobody.
Nobody's ever asked me for this traffic.
I've got no place to send it.
So we'll look in more detail at the various timers and things in here
as we go along. So how do we create the shared tree?
Well, number one, you got to know who the rendezvous point is.
You got to know how to get to him.
So if you don't have a route to the rendezvous point, it's not going to
do you much good.
And you have to have at least one request from a multicast receiver.
The multicast receiver, the laptop, the PC, once it sends an IGMP membership
report, that kicks off this whole process.
That's what builds the shared tree.
Okay, so let's go ahead and build a shared tree.
So what we're going to do in this case is I'm going to have my receiver,
which is really a router, but I'm going to have him send an IGMP membership
report for a particular group.
Now let's talk about the process that we're going to see.
And then we'll actually look at this in the lab.
So when R2 receives the membership report, he's suddenly going to be aware
of a source. So let's go ahead and actually do this on the whiteboard
here. So when this guy sends a membership report, let's just come up with
some group. 239.999.
Well, with PIM enabled on fast ethernet 00, router 2 will now realize,
okay, I have a receiver on this interface for this group.
Now notice when this membership report comes in, so there's not going
to be any mention of 4.5.4.5 because nobody knows that he exists at this
point. So when that report comes in, router 2 is now going to create some
state in his M route table, his multicast routing table, and we're going
to call this star, comma, g state.
Why do we call it that?
Well, it's going to be star, comma, g, meaning the star is what's the
IP address of the source?
Well, we don't know what the IP address of the source is.
So we just use a star as a placeholder, which means any source, we don't
care what the source is.
And then g, well, in this particular case, it'll be 239.999.
That is my group.
So you'll see here R2 will now have an M route entry saying star, comma,
239, 999. We call that a star, comma, g entry.
And fasteethanet00 will be placed in the outgoing interface list.
In other words, if I ever receive multicast for this group, I'll send
it outgoing on interface fasteethanet00.
Okay, so once router 2 gets that, he's now going to say, okay, I need
to let the PEM rendezvous point know that I'm down here.
And if he ever gets the multicast at 239.999, he needs to forward it to
me. Now, in this particular case, we've already identified the rendezvous
point as being router 3.
He is the PEM RP.
And all these routers know about that, because I statically configured
them for that. So router 2, in his star, comma, g entry, you'll see that
he'll say that. He'll say, okay, I know that the rendezvous point is 3
.4.3.3. And now he's going to go into his unicast routing table.
He's going to say, how do I get there?
Well, if I go into router 2, there's, if I want to verify that this router
actually can reverse path to the RP, that he knows how to get back to
the RP, there's two ways I could do it.
I could certainly just look at my routing table.
I could do that.
Show IP route. And we can see right here, there is a route to the 343
network, learned via EIGRP.
And so he's going to go out fast ethernet 0 slash 1.
Or if you want to do it the way PEM would do it, you can do show IP RPF
and then type in that IP address.
He says, okay, I know about this.
My interface to get there is fast ethernet 0 1.
My next top neighbor, in other words, the neighbor who told me about this
route is 8288. Here's the actual route I found on my routing table.
And I learned it via EIGRP process 100, EIGRP Autonomous System 100.
So now that he knows that, I go back to my whiteboard here, you'll see
in my star, G entry, he'll place something called an incoming interface.
Incoming interface.
And he'll say, once the RP starts sending me multicast data, because it
shouldn't initially start going down the shared tree from the RP, it should
start coming from fast ethernet 0 slash 1.
Because that's the interface I use to get to the rendezvous point.
And then he'll also say, my neighbor is 8.2 dot 8 dot 8.
Now he's got everything he needs.
So now router 2 will create a PEM join.
And we call this a PEM star, join.
Because just like the IGMP membership report gave no indication of what
the source address is of this multicast stream, this PEM join also gives
no indication of the multicast stream.
And we'll capture that in the snippet trace so you can see it.
Star, 239 dot 999.
And in that star, G join, it'll actually have the IP address of the rendezvous
point. And in that way, router 8 will say, okay, I know where this is
going, this is going to the RP.
So guess what? When router 8 gets that, it's going to create star, G state
in him. Because remember star, G state, this M route state is created
based on either an actual receiver asking for the route, or a downstream
router asking for the route.
If a downstream router sends you a star, G join, it creates the exact
same state as if you actually had a receiver.
Not quite the same, I need some flags in here that are different, but
still creates the state.
So router 8, he'll create a star, G entry.
He knows who the RP is.
He'll do a reverse path lookup, and I'm pretty much assuming that his
reverse path will be 00.83.
Just looking at this diagram, I'm pretty sure that's his fastest path.
And then his next top neighbor will actually be 3.4.3.3.
And once he gets that, he will forward a star, G join up to the RP.
And that will create star, G state in the rendezvous point himself.