So as a reminder, here is our game plan right here.
And we already have R1, R2, and R3 configured.
So our attention is going to be right here on R4.
So a couple of things we'll need to do.
Number one, we'll want to enable IP multicast routing.
And syntax for that is IP multicast routing with the little
hyphen between multicast and routing.
So that's done in global config.
So we'll do that first over on R4 and then we'll enable PIM in sparse mode
on each of its interfaces, which would be gig two zero, fast.
We'll see that four slash one and gig one zero. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We'll see that four slash one and gig one zero.
So the syntax there to be IP PIM sparse mode.
And then last but not least, we also want to make sure that R4 knows where
the root or the trunk of the tree is over here at R2, the rendezvous point.
So we're also going to use the command in global config.
In fact, I'll put it right here under IP multicast routing, which is also in
global
config, we'll have the command IP PIM RP dash address.
And then we'll put the loopback address here of R2, which is two dot two dot
two dot two.
And boom.
Another thing that happens once we do this configuration is that I GMP is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Another thing that happens once we do this configuration is that I GMP is
enabled on those interfaces by default.
So if we have a client, for example, out here and it does a joint request for a
multicast group, this router using I GMP can say, okay, great.
I know that you want it.
And if I have it, I'll forward it to you also periodically with I GMP, these
routers can query their network segments just to make sure there's at least one
device on that network segment that still needs that multicast group.
And if it doesn't, it can go ahead and prune off that outgoing interface and
not bother wasting bandwidth.
And again, that's the benefit of using sparse mode, only forwarding traffic WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And again, that's the benefit of using sparse mode, only forwarding traffic
down
into devices and entities that need it.
So that in mind, let's head over to R4 and let's configure multicast routing on
R4.
So here's our playground and also at the very tail end of this set of videos, I
'm
going to give you a hands-on lab so you can do the practice on your own.
So for now, let's go ahead and verify our topology.
So we are configuring R4.
Fantastic.
And to get to the console of any of these routers as well as the switch, we're
going to go ahead and double click right here on server one dash nug.
So we'll give that a double click, give that a moment to initialize and there's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we'll give that a double click, give that a moment to initialize and there's
our console interfaces.
So there's our one, our two, our three, our four and just to verify it real
quick,
let's just verify that R2 is already configured.
So let's go to R2 just as a sanity check.
Let's do a show IP PIM interface.
And sure enough, all of its interfaces are enabled for PIM.
And let's also show IP, IGMP interface.
And because PIM is enabled on the interfaces, IGMP should be as well.
So here's gig zero zero that's enabled for IGMP. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So here's gig zero zero that's enabled for IGMP.
And showing right here the version, which is version two and which multicast
groups have been joined on the interface.
So this multicast group here is used by a process called auto RP where it can
automatically decide on the rendezvous point.
In our case, we're manually configuring a rendezvous point.
So here if we did a show IP PIM RP or rendezvous point is showing us the
rendezvous point is at 2222.
And that's for this multicast group right here as well as for this
multicast group right here.
And because this is the only rendezvous point that we have, our two, any new WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And because this is the only rendezvous point that we have, our two, any new
groups
are also going to use the same root or trunk of the tree.
So we went over to R1, for example, and we did a show IP PIM RP and press
center.
Once again, it's going to indicate that same root or trunk of the tree, which
is 2222.
And in R4, we haven't yet configured that.
So let's go ahead and configure R4 for multicast routing.
So we'll start off by, in fact, let's do this.
We'll do a show IP PIM interface and it shouldn't have any.
And we'll do a show IP PIM RP and again, nothing. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we'll do a show IP PIM RP and again, nothing.
So there's no multicast configured whatsoever.
So on R4, we'll go into configuration mode and we use the command IP multicast
routing to enable multicast routing.
Then let's specify the PIM rendezvous point address with IP PIM RP dash address
.
And that is going to be 2.2.2.
And this tunnel right here is a logical tunnel between R4, which is right here.
And the rendezvous point, which is R2.
And it's going to use that logical tunnel.
If it needs a forward traffic that it sees, multicast traffic that it sees,
as it forwards it over to the rendezvous point. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
as it forwards it over to the rendezvous point.
So currently it says this down.
And that's because we don't have any interfaces yet enabled for PIM.
And that's our next step.
So we're going to go to interface and let's take a look at our interfaces real
quick.
We wanted to do interface gig 1, 0, gig 2, 0 and FA 4/1 and enable
all of them for PIM sparse mode.
So let's do interface range for a gigabit 1/0, gig 2/0, comma.
And what was the other one?
Let's take a look.
It is FA 4/1.
So we'll do FA 4/1. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we'll do FA 4/1.
And now in interface range configuration mode, we use the command IP, PIM
sparse mode and press center.
And we have some PIM messages here regarding DRs.
Now these are not the same as the DRs for OSP off.
These are DRs for PIM.
It also indicates here that we have a couple of neighbors.
So this means that our 4 has a neighbor ship with our 3 and also has a neighbor
ship over with our 2 based on these two messages right here.
So now if we did a show IP, I GMP interface, it's going to show us the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So now if we did a show IP, I GMP interface, it's going to show us the
interfaces that are enabled for I GMP.
And that's as a result of enabling PIM on those interfaces.
So the space bar is going to go through the interfaces involved.
And if you did a show IP PIM neighbor that gives details on our neighbors.
So off of our FA 4/1 interface, we have a neighbor that's R2 based on that last
octet.
And off of our gig 1/0 interface, we have a neighbor based on that last octet.
That's R3.
Now if we go to R2, which is our rendezvous point, let's go ahead and hop over WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now if we go to R2, which is our rendezvous point, let's go ahead and hop over
there.
Here we do a show IPM route press center.
And that's going to show us the multicast routing table.
And although there's a lot of information here, here's the key parts I'd like
you to pay attention to.
It has information regarding multicast streams that it has seen.
And some of these multicast groups, which are by default, are there to support
a feature called auto RP.
So at the moment, R2 knows about this destination group 224.0.1.40.
It knows about this one 239, 255, etc. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It knows about this one 239, 255, etc.
But it doesn't know anything about a multicast group based on our game plan
like 224.67.83.
So as a test, if you and I went over to R4.
And we did a ping to 224.67.8.3.
We sourced it from gig 2.0, which is the 23.1.2.4 address.
We would then see that combination here in the multicast table on R2.
Because even though R4 is sourcing that traffic, when it sees that traffic, it
's going to go ahead and forward it to the rendezvous point,
who's then going to build it as part of its multicast routing table. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
who's then going to build it as part of its multicast routing table.
So let's verify that next.
So we'll go over to R4 and on R4, let's do a ping to 224.1.2.
That's the wrong address.
Based on our plan, let's take a look at our plan for a moment.
Our multicast address is going to be 224.67.8.3.
That's our group that we're going to send the traffic to.
So with that in mind, let's do exactly that.
224.67.8.3.
Let's go ahead and also source this from the gig 2.0 interface address, which WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Let's go ahead and also source this from the gig 2.0 interface address, which
is 23.1.2.4.
So let's go ahead and actually let's verify that as well.
Let's do a show IP interface brief just to confirm.
So that's the address right there associated with the gig 2.0 interface.
So do I ping?
It doesn't really matter what content we send.
We can send ping requests that would work.
Or if you had a multicast application that was literally sending a stream that
people could watch and view.
All we're really concerned about here is the routing of that multicast traffic
at layer 3.
So ping to 224.67.8.3. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So ping to 224.67.8.3.
And we'll source that from this interface.
And let's go ahead and copy paste that to make it real easy.
And we'll source it from that interface and press enter.
So boom, we've done it now.
It sent one packet.
There was no response.
And that's because no one on this multicast network is joined that group yet.
So in our four, we simulated creating a multicast stream.
And now if we go back to R2, check this out a moment ago.
When we use this command show IPM route, it didn't have any information about a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
When we use this command show IPM route, it didn't have any information about a
source of 23.1.2.4 and a destination of multicast group 224.67.8.3.
But now we have the upper key for a refresh and go down a little bit, check it
out.
It learned about this multicast group 224.67.8.3.
And it also knows the source of that is the IP address interface of gig 2.0
over on R4.
So that means the root of the tree, the trunk of the tree has received this,
but check it out.
It's not yet forwarding it anywhere.
And that's because we're in sparse mode. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that's because we're in sparse mode.
And in sparse mode, the routers are not going to forward that multicast stream
unless they have a reason to.
So here's what you and I get to do in the next video.
In the next video, what we'll do is we'll go down to R1 and we'll have this
interface down in R1, the gig 2.0 interface join that multicast group.
And as a result, it can send that join request via PIM up to R2, who's the
trunk of the tree.
And at that moment, R2 is going to say, "You know what? I need to start
forwarding that traffic."
So we'll continue this conversation with that demonstration in the very next WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we'll continue this conversation with that demonstration in the very next
video.
So I'll see you there in just a moment.