WEBVTT

1
00:00.000 --> 00:05.920
to really appreciate multicast and to see it in action. We probably not just

2
00:05.920 --> 00:06.880
probably we absolutely

3
00:06.880 --> 00:10.550
need to have a game plan in place and that's what you and I get to do right now

4
00:10.550 --> 00:11.440
. So we'll put a

5
00:11.440 --> 00:15.580
game plan together and then we'll implement it step by step. So for the game

6
00:15.580 --> 00:16.800
plan as far as a

7
00:16.800 --> 00:22.800
multicast server, let's just go ahead and let's use R4 as the multicast server.

8
00:22.800 --> 00:23.760
Now we could use

9
00:23.760 --> 00:27.930
another device perhaps and have it pump multicast traffic in but it's also

10
00:27.930 --> 00:29.120
pretty easy from a Cisco

11
00:29.120 --> 00:33.810
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

11
00:29.120 --> 00:33.810
router without using external devices to go ahead and send a ping to a multic

12
00:33.810 --> 00:35.360
ast group. So we'll have

13
00:35.360 --> 00:40.760
R4 act as the multicast server and for the multicast group, let's go ahead and

14
00:40.760 --> 00:42.880
use 224 class D address

15
00:42.880 --> 00:47.860
and let's use 67.83 and that would be our multicast group and as far as pumping

16
00:47.860 --> 00:48.720
out the content,

17
00:48.720 --> 00:52.640
let's also go ahead and source that from the gig two zero interface address

18
00:52.640 --> 00:54.880
which is 23.1.2.4

19
00:54.880 --> 00:59.200
here on R4 and that way we'll be able to very clearly see who the server is if

20
00:59.200 --> 00:59.760
we source from

21
00:59.760 --> 01:04.030
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

21
00:59.760 --> 01:04.030
that IP address when we do the ping and we'll also see the group as far as the

22
01:04.030 --> 01:05.200
trunk or the root of

23
01:05.200 --> 01:10.320
the tree. Let's go ahead and use R2 as the rendezvous point and they'll put RP

24
01:10.320 --> 01:11.520
for short because it's

25
01:11.520 --> 01:16.350
a lot easier to spell than rendezvous point but R2 will specify as the root or

26
01:16.350 --> 01:17.280
the trunk of the

27
01:17.280 --> 01:21.910
tree and that way any of our four routers that they see new multicast streams

28
01:21.910 --> 01:22.880
coming in, they'll

29
01:22.880 --> 01:26.700
simply directly forward it over to the root for further distribution. So let's

30
01:26.700 --> 01:27.440
use the loopback

31
01:27.440 --> 01:33.200
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

31
01:27.440 --> 01:33.200
interface here on R2 which is 2.2.2.2. Now I currently in the lab environment,

32
01:33.200 --> 01:36.480
I've got R1, R2, R3 all

33
01:36.480 --> 01:41.810
configured ready to go. However, I've got absolutely no multicast configuration

34
01:41.810 --> 01:43.440
over here on R4.

35
01:43.440 --> 01:46.870
So as part of our journey together, we'll implement multicast routing and all

36
01:46.870 --> 01:48.480
the pieces here in R4

37
01:48.480 --> 01:51.920
and then once it's up and running, we can then test and verify our multicast

38
01:51.920 --> 01:52.800
streams through the

39
01:52.800 --> 01:56.060
network. And then when we implement PIM, we're going to go ahead and implement

40
01:56.060 --> 01:57.520
it in sparse mode.

41
01:57.520 --> 02:01.650
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

41
01:57.520 --> 02:01.650
And sparse mode as a reminder, simply says, hey, don't bother forwarding this.

42
02:01.650 --> 02:02.400
Like say R2 gets

43
02:02.400 --> 02:06.690
some multicast group traffic. It says don't bother forwarding this out any

44
02:06.690 --> 02:07.760
other interfaces

45
02:07.760 --> 02:12.030
unless somebody requests it. So if R1 requests it, then we would go ahead and

46
02:12.030 --> 02:13.280
start forwarding it

47
02:13.840 --> 02:17.860
if that traffic exists. And then R1 wouldn't bother forwarding it down here out

48
02:17.860 --> 02:18.960
of gig 2.0

49
02:18.960 --> 02:22.950
unless a client or some other device on that network requested it. And if they

50
02:22.950 --> 02:23.520
do, then we'll

51
02:23.520 --> 02:27.890
start forwarding. So sparse mode says forward only if there's receivers that

52
02:27.890 --> 02:28.800
have requested

53
02:28.800 --> 02:32.900
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

53
02:28.800 --> 02:32.900
that information. And on the switch, I don't know by default whether or not iG

54
02:32.900 --> 02:34.000
MP stooping is

55
02:34.000 --> 02:37.910
enabled or not yet. We'll take a look at that here in a little bit. But if it

56
02:37.910 --> 02:38.880
is not enabled,

57
02:38.880 --> 02:43.060
multicast traffic is simply going to be forwarded to all other ports in the

58
02:43.060 --> 02:44.960
same VLAN. Or if iGMP

59
02:44.960 --> 02:49.130
stooping is on, it'll only for the multicast traffic to the actual ports in

60
02:49.130 --> 02:50.720
that existing VLAN

61
02:50.720 --> 02:55.680
where they have requested or need that multicast group. So that'll be our game

62
02:55.680 --> 02:56.960
plan for implementation

63
02:56.960 --> 03:01.050
of multicast routing. And we'll begin the configuration of implementing our
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

63
02:56.960 --> 03:01.050
of multicast routing. And we'll begin the configuration of implementing our

64
03:01.050 --> 03:02.320
multicast routing,

65
03:02.320 --> 03:05.440
focusing our attention on our four, which is not yet configured. And we'll

66
03:05.440 --> 03:06.480
start that configuration

67
03:06.480 --> 03:11.720
process in the next video. So I'll see you there in just a moment.