to really appreciate multicast and to see it in action. We probably not just
probably we absolutely
need to have a game plan in place and that's what you and I get to do right now
. So we'll put a
game plan together and then we'll implement it step by step. So for the game
plan as far as a
multicast server, let's just go ahead and let's use R4 as the multicast server.
Now we could use
another device perhaps and have it pump multicast traffic in but it's also
pretty easy from a Cisco
router without using external devices to go ahead and send a ping to a multic WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
router without using external devices to go ahead and send a ping to a multic
ast group. So we'll have
R4 act as the multicast server and for the multicast group, let's go ahead and
use 224 class D address
and let's use 67.83 and that would be our multicast group and as far as pumping
out the content,
let's also go ahead and source that from the gig two zero interface address
which is 23.1.2.4
here on R4 and that way we'll be able to very clearly see who the server is if
we source from
that IP address when we do the ping and we'll also see the group as far as the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that IP address when we do the ping and we'll also see the group as far as the
trunk or the root of
the tree. Let's go ahead and use R2 as the rendezvous point and they'll put RP
for short because it's
a lot easier to spell than rendezvous point but R2 will specify as the root or
the trunk of the
tree and that way any of our four routers that they see new multicast streams
coming in, they'll
simply directly forward it over to the root for further distribution. So let's
use the loopback
interface here on R2 which is 2.2.2.2. Now I currently in the lab environment, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
interface here on R2 which is 2.2.2.2. Now I currently in the lab environment,
I've got R1, R2, R3 all
configured ready to go. However, I've got absolutely no multicast configuration
over here on R4.
So as part of our journey together, we'll implement multicast routing and all
the pieces here in R4
and then once it's up and running, we can then test and verify our multicast
streams through the
network. And then when we implement PIM, we're going to go ahead and implement
it in sparse mode.
And sparse mode as a reminder, simply says, hey, don't bother forwarding this. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And sparse mode as a reminder, simply says, hey, don't bother forwarding this.
Like say R2 gets
some multicast group traffic. It says don't bother forwarding this out any
other interfaces
unless somebody requests it. So if R1 requests it, then we would go ahead and
start forwarding it
if that traffic exists. And then R1 wouldn't bother forwarding it down here out
of gig 2.0
unless a client or some other device on that network requested it. And if they
do, then we'll
start forwarding. So sparse mode says forward only if there's receivers that
have requested
that information. And on the switch, I don't know by default whether or not iG WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that information. And on the switch, I don't know by default whether or not iG
MP stooping is
enabled or not yet. We'll take a look at that here in a little bit. But if it
is not enabled,
multicast traffic is simply going to be forwarded to all other ports in the
same VLAN. Or if iGMP
stooping is on, it'll only for the multicast traffic to the actual ports in
that existing VLAN
where they have requested or need that multicast group. So that'll be our game
plan for implementation
of multicast routing. And we'll begin the configuration of implementing our WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of multicast routing. And we'll begin the configuration of implementing our
multicast routing,
focusing our attention on our four, which is not yet configured. And we'll
start that configuration
process in the next video. So I'll see you there in just a moment.