WEBVTT

1
00:00.000 --> 00:03.840
So to really appreciate multi-cast, let's first of all talk about some other

2
00:03.840 --> 00:04.700
traffic patterns.

3
00:04.700 --> 00:07.040
And the first I'd like to chat about is unicast.

4
00:07.040 --> 00:11.120
And unicast is a traffic that I think most people think of when they think of

5
00:11.120 --> 00:11.800
IP traffic.

6
00:11.800 --> 00:16.310
It's traffic from one source IP address going to a specific destination address

7
00:16.310 --> 00:16.440
.

8
00:16.440 --> 00:22.760
An example would be this client here at 101050 making request, going up to the

9
00:22.760 --> 00:25.600
server at 23.1.2.100.

10
00:25.600 --> 00:28.900
And even though there may be napping used here at this edge router, we still

11
00:28.900 --> 00:32.300
have a single source address going to a single destination address.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

11
00:28.900 --> 00:32.300
have a single source address going to a single destination address.

12
00:32.300 --> 00:36.240
After the reply traffic, it'd be a single source address here going back to a

13
00:36.240 --> 00:37.400
single destination address.

14
00:37.400 --> 00:40.890
Or at this point, what are the net address was, then the end translation

15
00:40.890 --> 00:41.400
happens,

16
00:41.400 --> 00:44.150
and then that traffic is then routed back down to the client after the end

17
00:44.150 --> 00:45.400
translation happens here.

18
00:45.400 --> 00:48.810
But either way, the concept of unicast is one source address, one destination

19
00:48.810 --> 00:49.400
address.

20
00:49.400 --> 00:52.000
Now, what other kind of options do we have?

21
00:52.000 --> 00:53.800
Well, we also have broadcasts.

22
00:53.800 --> 00:55.800
So I clean up my markings over here.

23
00:55.800 --> 01:01.400
And a broadcast is from one source to all destinations.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

23
00:55.800 --> 01:01.400
And a broadcast is from one source to all destinations.

24
01:01.400 --> 01:05.550
So that's most typical in a protocol like ARP, which is looking for, for

25
01:05.550 --> 01:08.800
example, the layer two address of another device on the same local network.

26
01:08.800 --> 01:12.930
Let's imagine it's this PC right here doing an ARP request that ARP request

27
01:12.930 --> 01:16.310
goes into this network, the 10100 network, and that corresponding layer two

28
01:16.310 --> 01:17.200
broadcast domain.

29
01:17.200 --> 01:20.300
And that broadcast is sent to all other devices on the network segment.

30
01:20.300 --> 01:24.620
So if there's 100 devices here, all of them are going to see that broadcast

31
01:24.620 --> 01:25.900
message sent by the ARP.

32
01:25.900 --> 01:29.430
And then the device that has the corresponding layer three address would

33
01:29.430 --> 01:30.300
respond back.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

33
01:29.430 --> 01:30.300
respond back.

34
01:30.300 --> 01:34.310
But the initial request, the ARP request, is going to be a broadcast sent from

35
01:34.310 --> 01:37.900
one source device to all of the other devices on the local subnet.

36
01:37.900 --> 01:39.800
So let me clean this up a little bit.

37
01:39.800 --> 01:42.520
And let me clean this up a little bit as well, make it a little bit more tidy

38
01:42.520 --> 01:43.000
for us.

39
01:43.000 --> 01:48.700
So unicast is one source IP going to one destination IP broadcast is from one

40
01:48.700 --> 01:49.500
source IP.

41
01:49.500 --> 01:52.390
And that would also include broadcast or sent when we don't have a layer three

42
01:52.390 --> 01:52.600
address.

43
01:52.600 --> 01:56.800
For example, if a client is doing a discover message with DHCP, that's going to

44
01:56.800 --> 01:59.700
be a broadcast, but the client does not yet have an IP address.

45
01:59.700 --> 02:02.570
But the concept is the same as coming from one source and it's being sent to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

45
01:59.700 --> 02:02.570
But the concept is the same as coming from one source and it's being sent to

46
02:02.570 --> 02:04.500
all other devices on that network segment.

47
02:04.500 --> 02:08.360
So I switch when it receives a broadcast frame that comes in, for example, on a

48
02:08.360 --> 02:12.210
port associated with VLAN one, it's going to for that frame out all other ports

49
02:12.210 --> 02:14.200
associated with that same VLAN.

50
02:14.200 --> 02:17.300
So we've taken a look at unicast and broadcast.

51
02:17.300 --> 02:20.900
So what is this wonderful magical thing called multicast?

52
02:20.900 --> 02:21.700
And here's the secret.

53
02:21.700 --> 02:25.840
We're going to have one source and for our discussion, let's imagine that we

54
02:25.840 --> 02:29.800
have content that is being sent from this server into the network.

55
02:29.800 --> 02:32.700
So that's our source at 23.1.2.100.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

55
02:29.800 --> 02:32.700
So that's our source at 23.1.2.100.

56
02:32.700 --> 02:36.860
But instead of sending it to one specific IP address that represents a single

57
02:36.860 --> 02:38.100
device on the network.

58
02:38.100 --> 02:42.670
And instead of sending it to all devices in the case of a broadcast, instead

59
02:42.670 --> 02:45.800
this time we're going to go ahead and send it to some.

60
02:45.800 --> 02:48.900
And sometimes that's referred to as many, but not all.

61
02:48.900 --> 02:53.380
Now, how in the world do you have a server send traffic to some devices or many

62
02:53.380 --> 02:55.200
devices, but not all devices?

63
02:55.200 --> 02:59.310
And the answer is we are going to send the destination to a specific type of

64
02:59.310 --> 03:02.300
layer three address and that's a multicast address.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

64
02:59.310 --> 03:02.300
layer three address and that's a multicast address.

65
03:02.300 --> 03:08.980
That's a class D address and that range is the first octet being 224 through

66
03:08.980 --> 03:09.900
239.

67
03:09.900 --> 03:15.030
So IP address starts with a 224 all the way through 239 is a class D address

68
03:15.030 --> 03:17.000
and that is a multicast address.

69
03:17.000 --> 03:19.800
And here's something that I didn't really grasp immediately many decades ago

70
03:19.800 --> 03:23.360
when I started learning multicast is that when we have a multicast address, let

71
03:23.360 --> 03:29.300
's say for example, 224.67.8.3.

72
03:29.300 --> 03:34.190
That not only is a multicast address, but it's also referred to as a multicast
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

72
03:29.300 --> 03:34.190
That not only is a multicast address, but it's also referred to as a multicast

73
03:34.190 --> 03:34.800
group.

74
03:34.800 --> 03:39.700
Let's imagine that the server is pumping out content to 224.67.8.3.

75
03:39.700 --> 03:41.500
That multicast group address.

76
03:41.500 --> 03:45.120
How in the world is the network going to be able to forward this multicast

77
03:45.120 --> 03:49.140
group content down to, for example, a client down here that would like to

78
03:49.140 --> 03:49.700
receive it?

79
03:49.700 --> 03:53.680
And that's the topic I'd like to address next in this overview and explain how

80
03:53.680 --> 03:57.440
that traffic sent to this group address is being able to be delivered down here

81
03:57.440 --> 03:58.400
to this client.

82
03:58.400 --> 04:02.370
So let me clean up a little bit of space and let's talk about the details about
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

82
03:58.400 --> 04:02.370
So let me clean up a little bit of space and let's talk about the details about

83
04:02.370 --> 04:04.800
delivering multicast across a network.

84
04:04.800 --> 04:10.230
And I'm going to refer to that as multicast routing, the ability for routers

85
04:10.230 --> 04:14.140
who see a multicast group destination address to be able to forward it through

86
04:14.140 --> 04:15.000
the network.

87
04:15.000 --> 04:19.210
So the first step here is we need to do enable multicast routing on our routers

88
04:19.210 --> 04:19.500
.

89
04:19.500 --> 04:23.680
So once we've enabled multicast routing on our one and our two and our three

90
04:23.680 --> 04:27.070
and our four, they'll be able to go ahead and then for that traffic down to the

91
04:27.070 --> 04:28.100
clients that need it.

92
04:28.100 --> 04:32.310
Now, there are several different options regarding multicast routing and
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

92
04:28.100 --> 04:32.310
Now, there are several different options regarding multicast routing and

93
04:32.310 --> 04:33.300
setting it up.

94
04:33.300 --> 04:37.940
But one of the most popular and traditional methods is to use a protocol for

95
04:37.940 --> 04:39.700
multicast routing called PIM.

96
04:39.700 --> 04:45.200
Now PIM itself, that acronym stands for protocol independent multicast.

97
04:45.200 --> 04:47.200
And here's what that means in a Cisco world.

98
04:47.200 --> 04:51.730
If we set up PIM multicast routing on these devices, they are going to use our

99
04:51.730 --> 04:54.200
one, our two and our four and our three.

100
04:54.200 --> 04:58.110
They're going to use their IP routing tables and the thing about protocol

101
04:58.110 --> 05:02.060
independent multicast is it doesn't matter how those IP routing tables got
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

101
04:58.110 --> 05:02.060
independent multicast is it doesn't matter how those IP routing tables got

102
05:02.060 --> 05:03.000
populated.

103
05:03.000 --> 05:07.250
We could be using any type of routing protocol to train these routers on how to

104
05:07.250 --> 05:09.800
make forwarding decisions for normal IP traffic.

105
05:09.800 --> 05:16.900
So we could use things like OSPF or RIP, Heaven Help was there or EIGRP or BGP.

106
05:16.900 --> 05:21.080
It doesn't matter to protocol independent multicast how the unicast routing

107
05:21.080 --> 05:23.900
tables got populated, but it's leveraging that.

108
05:23.900 --> 05:26.500
And that's why it's called protocol independent multicast.

109
05:26.500 --> 05:31.020
As long as our IP routing to start with works OK, we can overlay protocol
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

109
05:26.500 --> 05:31.020
As long as our IP routing to start with works OK, we can overlay protocol

110
05:31.020 --> 05:33.300
independent multicast routing on top of it.

111
05:33.300 --> 05:34.900
And that's why it's called independent.

112
05:34.900 --> 05:38.860
It's independent of the method we use to populate the IP unicast routing tables

113
05:38.860 --> 05:39.100
.

114
05:39.100 --> 05:43.630
So I'm going to clean that up just a little bit and let's talk about how PIM is

115
05:43.630 --> 05:44.700
going to work.

116
05:44.700 --> 05:46.600
PIM has a couple of options.

117
05:46.600 --> 05:49.700
One's called sparse mode and the other is called dense mode.

118
05:49.700 --> 05:53.140
And there's a few different options regarding each of those and how to set it

119
05:53.140 --> 05:53.500
up.

120
05:53.500 --> 05:56.500
But the basic concept of sparse mode is this.

121
05:56.500 --> 06:01.200
If we have all these routers set up for multicast routing and the routers see
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

121
05:56.500 --> 06:01.200
If we have all these routers set up for multicast routing and the routers see

122
06:01.200 --> 06:05.300
this stream of traffic going to this multicast group 224 67.8.3

123
06:05.300 --> 06:09.280
by default with sparse mode, they're not going to bother forwarding it through

124
06:09.280 --> 06:09.900
the network.

125
06:09.900 --> 06:12.410
There's something going to say, you know what, we don't have any clients that

126
06:12.410 --> 06:13.500
we know of that need it.

127
06:13.500 --> 06:14.900
So we're not going to forward it.

128
06:14.900 --> 06:16.500
That's what sparse mode is all about.

129
06:16.500 --> 06:20.270
It's about saving bandwidth, not forwarding traffic where it doesn't need to go

130
06:20.270 --> 06:20.500
.

131
06:20.500 --> 06:24.280
Now dense mode on the other hand takes the attitude of, well, you know what, if

132
06:24.280 --> 06:26.300
we see a multicast destination address,

133
06:26.300 --> 06:29.500
we're just going to automatically forward it down through the network.

134
06:29.500 --> 06:33.550
And the reason it's called dense mode is that perhaps we had a large number of
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

134
06:29.500 --> 06:33.550
And the reason it's called dense mode is that perhaps we had a large number of

135
06:33.550 --> 06:38.300
devices that needed to join a multicast group and receive that content.

136
06:38.300 --> 06:41.260
That'd be another way of saying we have a dense population or a great

137
06:41.260 --> 06:43.900
population of devices that need that stream.

138
06:43.900 --> 06:47.360
And then dense mode might be justifiable in that case because we're going to go

139
06:47.360 --> 06:49.100
ahead and start forwarding it no matter what.

140
06:49.100 --> 06:52.290
So if there's lots of clients, it's possible they could get that a teeny bit

141
06:52.290 --> 06:55.700
faster than if the network had to figure out where all the receivers are.

142
06:55.700 --> 06:59.580
So for our discussion regarding protocol independent multicast, I'm going to

143
06:59.580 --> 07:03.100
focus on sparse mode for the remainder of our discussions.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

143
06:59.580 --> 07:03.100
focus on sparse mode for the remainder of our discussions.

144
07:03.100 --> 07:07.670
So for our next magic trick here is how do we let these routers know if we have

145
07:07.670 --> 07:08.500
sparse mode?

146
07:08.500 --> 07:13.690
How do we let them know that this client down here at 1010 050 would like to

147
07:13.690 --> 07:18.500
receive the traffic for that multicast group to 24 dot 67 dot 83?

148
07:18.500 --> 07:22.590
And the answer is this client is going to start the process by saying, you know

149
07:22.590 --> 07:22.900
what?

150
07:22.900 --> 07:27.700
I would love to receive that multicast group stream if it's available.

151
07:27.700 --> 07:32.100
So it starts by this client here joining the multicast group.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

151
07:27.700 --> 07:32.100
So it starts by this client here joining the multicast group.

152
07:32.100 --> 07:35.550
And again, when I talk about joining group, think of it like this client saying

153
07:35.550 --> 07:36.100
, you know what?

154
07:36.100 --> 07:39.100
I would really love to see the stream of traffic if it shows up.

155
07:39.100 --> 07:40.580
That's what joining a group means.

156
07:40.580 --> 07:45.200
It means it wants to go ahead and see that multicast stream if it's present on

157
07:45.200 --> 07:46.020
the network.

158
07:46.020 --> 07:49.560
Now, if there's no server or nothing else pumping up that content, of course,

159
07:49.560 --> 07:51.140
this guy is not going to get the traffic it needs.

160
07:51.140 --> 07:55.660
But assuming that that multicast content is being sent on the network and this

161
07:55.660 --> 07:58.980
client has joined and would like to receive it, that's an indication of this

162
07:58.980 --> 07:59.260
network.

163
07:59.260 --> 08:02.090
They need to deliver that traffic down to this client so you can go ahead and
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

163
07:59.260 --> 08:02.090
They need to deliver that traffic down to this client so you can go ahead and

164
08:02.090 --> 08:03.100
consume it and see it.

165
08:03.100 --> 08:06.620
An example of that would be this little client's running a multimedia player

166
08:06.620 --> 08:09.700
that receives or is able to receive multicast content.

167
08:09.700 --> 08:13.680
And so when the client launches their application and then says they want to

168
08:13.680 --> 08:17.900
join that group or receive that stream of traffic, that's what triggers the

169
08:17.900 --> 08:20.500
join request to go into the network from this client.

170
08:20.500 --> 08:27.490
Now, that join request in the background is using a protocol called IGMP, not

171
08:27.490 --> 08:29.380
to be confused with ICMP,

172
08:29.380 --> 08:34.740
but IGMP is the internet group, hence multicast groups, management protocol.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

172
08:29.380 --> 08:34.740
but IGMP is the internet group, hence multicast groups, management protocol.

173
08:34.740 --> 08:37.820
So in the background, when this client is joining a group or says in the

174
08:37.820 --> 08:42.440
interface of the software, I want to see the multicast stream for 2.2467.8.3 in

175
08:42.440 --> 08:43.100
the background,

176
08:43.100 --> 08:47.260
it's actually using this protocol, IGMP, internet group, management protocol to

177
08:47.260 --> 08:50.960
do that join, which indicates to the network that, hey, if that content's

178
08:50.960 --> 08:53.100
available, please deliver it down to this client.

179
08:53.100 --> 08:56.710
Now, there's three different versions of IGMP, there's version 1, which was the

180
08:56.710 --> 09:00.460
original flavor, there's version 2 that was more effective, and there's also a
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

180
08:56.710 --> 09:00.460
original flavor, there's version 2 that was more effective, and there's also a

181
09:00.460 --> 09:01.100
version 3,

182
09:01.100 --> 09:05.550
which allows for something called source specific multicast, which takes into

183
09:05.550 --> 09:10.120
consideration not just the destination multicast group, but also it takes into

184
09:10.120 --> 09:14.700
consideration the source of the server who's actually sending that content.

185
09:14.700 --> 09:18.660
And we'll save the whole discussion for source specific multicast for another

186
09:18.660 --> 09:20.500
set of videos in another course.

187
09:20.500 --> 09:24.230
But for now, I just want you to be aware that if a client is making a join

188
09:24.230 --> 09:27.900
request for a multicast group, it's going to be using IGMP.

189
09:27.900 --> 09:31.680
So let's imagine this client has launched some software like VLC or some other
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

189
09:27.900 --> 09:31.680
So let's imagine this client has launched some software like VLC or some other

190
09:31.680 --> 09:34.900
software that can process and receive multicast group streams,

191
09:34.900 --> 09:37.900
and they want to join the group 2.2467.83.

192
09:37.900 --> 09:41.840
Let's also imagine for this discussion that this client is going to be using I

193
09:41.840 --> 09:42.900
GMP version 2.

194
09:42.900 --> 09:44.700
So it sends a join request.

195
09:44.700 --> 09:50.240
So when the client joins that group, that 2.2467.83, that's what begins the

196
09:50.240 --> 09:53.810
process of training the network that they need to forward that content should

197
09:53.810 --> 09:57.300
they see it to 2.2467.83 down to this client.

198
09:57.300 --> 10:00.910
So the next question I'd like to chat with you about is how in the world does
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

198
09:57.300 --> 10:00.910
So the next question I'd like to chat with you about is how in the world does

199
10:00.910 --> 10:01.500
that happen?

200
10:01.500 --> 10:05.180
I mean, what's the magic in sparse mode of allowing the traffic from the server

201
10:05.180 --> 10:08.300
up here to be correctly routed all the way down to this client?

202
10:08.300 --> 10:13.220
And the answer is in multicast routing, when setting up PIM and sparse mode, it

203
10:13.220 --> 10:15.300
's going to use a tree structure.

204
10:15.300 --> 10:19.010
And one thing about a tree, as the starting point for this, is a tree has

205
10:19.010 --> 10:20.700
affected like one trunk.

206
10:20.700 --> 10:24.050
So I'm going to go ahead and instead of calling it a trunk, which might be

207
10:24.050 --> 10:27.500
confused with either 2.1Q, let's call this the base of the tree.

208
10:27.500 --> 10:30.700
Now that base of the tree could be any one of these four routers.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

208
10:27.500 --> 10:30.700
Now that base of the tree could be any one of these four routers.

209
10:30.700 --> 10:34.840
So for our discussion, let's imagine we want the base of the tree to be this

210
10:34.840 --> 10:38.100
one right here, R2, and we'll make that the base of the tree.

211
10:38.100 --> 10:42.300
So let's go ahead and use R2's loopback address of 2.2.2.2.

212
10:42.300 --> 10:46.220
So we can configure the entire network and back these four routers that the

213
10:46.220 --> 10:50.100
base of the tree is 2.22, reachable right here at R2.

214
10:50.100 --> 10:51.500
That's its loopback zero address.

215
10:51.500 --> 10:56.340
And once we do that, any routers that see multicast destination content, what

216
10:56.340 --> 10:58.700
they're going to do is they are going to simply send it.

217
10:58.700 --> 11:03.920
So if there's multicast content here, the class D address range, and R1 sees it
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

217
10:58.700 --> 11:03.920
So if there's multicast content here, the class D address range, and R1 sees it

218
11:03.920 --> 11:05.500
, it's going to forward it to R2.

219
11:05.500 --> 11:10.700
If, for example, R3 sees multicast content, it's going to forward it to R2.

220
11:10.700 --> 11:15.170
If R4 sees multicast content, it's going to forward it to R2 because that's the

221
11:15.170 --> 11:16.300
base of the tree.

222
11:16.300 --> 11:19.100
So using our example here, let me go ahead and clean this up a bit.

223
11:19.100 --> 11:23.360
Let's imagine that we do have the server here that's pumping out content to 224

224
11:23.360 --> 11:24.700
.67.83.

225
11:24.700 --> 11:29.640
R4 sees that and immediately forwards it over based on a routing table, which I

226
11:29.640 --> 11:30.700
think we'd go this way.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

226
11:29.640 --> 11:30.700
think we'd go this way.

227
11:30.700 --> 11:36.150
It's going to forward it over to R2 and based on Gigabit and OSPF, which I

228
11:36.150 --> 11:36.900
currently have running,

229
11:36.900 --> 11:41.100
and the reference bandwidth in place, the best path is going to be right here.

230
11:41.100 --> 11:46.500
So now that traffic is being forwarded from the server through R4, through R3

231
11:46.500 --> 11:48.500
based on the routing tables to R2,

232
11:48.500 --> 11:50.300
who is the root or the base of the tree.

233
11:50.300 --> 11:56.090
Now that base of the tree has a specific name in PIM and that's called an RP

234
11:56.090 --> 11:58.300
and that stands for rendezvous point.

235
11:58.300 --> 12:02.040
So whenever you see the concept of rendezvous point, think of it as like the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

235
11:58.300 --> 12:02.040
So whenever you see the concept of rendezvous point, think of it as like the

236
12:02.040 --> 12:02.900
base of the tree,

237
12:02.900 --> 12:06.760
where's the starting point for the dissemination and the propagation of our

238
12:06.760 --> 12:07.900
multicast content.

239
12:07.900 --> 12:12.300
Now in sparse mode, when R2 sees that multicast content, what's it going to do?

240
12:12.300 --> 12:16.160
The answer is it's not going to forward it by default in sparse mode anywhere

241
12:16.160 --> 12:18.900
until it knows that somebody needs that content.

242
12:18.900 --> 12:22.510
So if this client computer here did a join request and let me put the join

243
12:22.510 --> 12:23.900
request here in green.

244
12:23.900 --> 12:28.180
So if it did join a request here, R1, who sees that join request, is going to

245
12:28.180 --> 12:28.300
say,

246
12:28.300 --> 12:31.500
"Whoa, I've got a client that needs it and it's going to communicate up to the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

246
12:28.300 --> 12:31.500
"Whoa, I've got a client that needs it and it's going to communicate up to the

247
12:31.500 --> 12:33.900
rendezvous point that it needs that traffic,

248
12:33.900 --> 12:37.300
that it needs that flow of data, that it needs that multicast group stream."

249
12:37.300 --> 12:42.720
So here it'd be IgMP, the client setting out, and then R1, it's messaging up to

250
12:42.720 --> 12:44.900
the rendezvous point, would be using PIM.

251
12:44.900 --> 12:47.100
Effectively saying, "Hey, you know what? I need this traffic."

252
12:47.100 --> 12:51.320
Now once that all happens, R2 is going to change its mind about where it's

253
12:51.320 --> 12:52.500
going to forward the traffic

254
12:52.500 --> 12:55.500
and it'll start forwarding it out, gig 1/0.

255
12:55.500 --> 12:59.560
At which point, the switch in its default state is going to forward that multic

256
12:59.560 --> 13:01.500
ast traffic to all other ports
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

256
12:59.560 --> 13:01.500
ast traffic to all other ports

257
13:01.500 --> 13:06.530
or if something called IgMP snooping is on, it'll only forward it to ports that

258
13:06.530 --> 13:07.300
need that.

259
13:07.300 --> 13:12.280
So then the multicast traffic stream would be forwarded out, gig 1/0, gig 0/0

260
13:12.280 --> 13:13.900
here on router 1 would see it,

261
13:13.900 --> 13:17.900
and then R1 could then forward it down to the client who needs to get that data

262
13:17.900 --> 13:17.900
.

263
13:17.900 --> 13:21.320
And if there are local switches, which are likely to be there, if those

264
13:21.320 --> 13:23.300
switches are doing IgMP snooping,

265
13:23.300 --> 13:27.900
they would only bother forwarding that traffic down to the ports that need it.

266
13:27.900 --> 13:32.470
Or in the case of a switch that's either a non-managed switch or a switch that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

266
13:27.900 --> 13:32.470
Or in the case of a switch that's either a non-managed switch or a switch that

267
13:32.470 --> 13:34.700
does not have IgMP snooping enabled,

268
13:34.700 --> 13:38.260
it would just forward that multicast traffic to all other ports in that

269
13:38.260 --> 13:39.300
corresponding VLAN,

270
13:39.300 --> 13:41.500
if it didn't know exactly which ports needed that.

271
13:41.500 --> 13:45.700
However, most Cisco switches are going to have IgMP snooping on by default.

272
13:45.700 --> 13:52.100
Also, before we finish this overview, let's chat about a feature called RPF.

273
13:52.100 --> 13:57.030
And RPF stands for a reverse path forwarding check, that's why I call it an RPF

274
13:57.030 --> 13:57.300
check.

275
13:57.300 --> 14:01.080
And understand an RPF check, let me go ahead and clean up our PIM just a little
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

275
13:57.300 --> 14:01.080
And understand an RPF check, let me go ahead and clean up our PIM just a little

276
14:01.080 --> 14:01.500
bit here.

277
14:01.500 --> 14:06.300
And let's imagine we have that same multicast stream of 224.67.8.3.

278
14:06.300 --> 14:09.100
And let's imagine that flow of traffic and it's still coming from this server

279
14:09.100 --> 14:10.900
at 23.1.2.100.

280
14:10.900 --> 14:16.300
Let's imagine that here on R1, it's receiving that multicast group stream here.

281
14:16.300 --> 14:19.500
And it's also just for grains, let's imagine it's receiving it here.

282
14:19.500 --> 14:25.630
Now, obviously, R1 does not need to send two copies of that multicast group of

283
14:25.630 --> 14:26.700
224.67.83

284
14:26.700 --> 14:28.900
that's coming from the server down to the client.

285
14:28.900 --> 14:33.300
I mean, the client only needs one copy of each of the packets, it doesn't need
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

285
14:28.900 --> 14:33.300
I mean, the client only needs one copy of each of the packets, it doesn't need

286
14:33.300 --> 14:33.300
two.

287
14:33.300 --> 14:35.700
And that's where the RPF comes into play.

288
14:35.700 --> 14:40.300
An RPF check is simply considering the source of the packet coming in.

289
14:40.300 --> 14:44.100
And let's do that here on R1 regarding traffic coming in from 23.1.2.100.

290
14:44.100 --> 14:48.170
So if that source traffic for this multicast group is coming in on gig zero

291
14:48.170 --> 14:50.500
zero and coming on zero three slash one,

292
14:50.500 --> 14:54.910
the RPF check on R1 is going to say, okay, pause for a moment and let's think

293
14:54.910 --> 14:55.500
about this.

294
14:55.500 --> 15:02.500
If I'm not saying I need to, but if I needed to forward a packet to 23.1.2.100,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

294
14:55.500 --> 15:02.500
If I'm not saying I need to, but if I needed to forward a packet to 23.1.2.100,

295
15:02.500 --> 15:05.100
the source, which interface would I use?

296
15:05.100 --> 15:09.510
Would I use gig zero zero based on my IP routing table or would I use serial

297
15:09.510 --> 15:10.100
three slash one?

298
15:10.100 --> 15:15.500
And if the answer is gig zero zero and that's the interface where we receive

299
15:15.500 --> 15:16.900
that multicast group information,

300
15:16.900 --> 15:18.700
we're going to go ahead and forward.

301
15:18.700 --> 15:21.100
I call that passing the RPF check.

302
15:21.100 --> 15:23.300
So yes, I pass the check.

303
15:23.300 --> 15:26.300
It came in on the interface I would use to forward back to the source.

304
15:26.300 --> 15:29.900
I'm going to go ahead and forward, meaning forward out the other interfaces

305
15:29.900 --> 15:33.500
where I have clients or other devices that need that multicast group stream.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

305
15:29.900 --> 15:33.500
where I have clients or other devices that need that multicast group stream.

306
15:33.500 --> 15:37.100
So next, let's consider the RPF check for that multicast group stream.

307
15:37.100 --> 15:41.440
If it's received here on zero three slash one, if the router receives it here

308
15:41.440 --> 15:45.100
and it looks at the source IP address of where the server is sending it from,

309
15:45.100 --> 15:48.500
it would consider, okay, how do I reach 23.1.2.100?

310
15:48.500 --> 15:52.900
If it's not this interface, that's considered failing the RPF check.

311
15:52.900 --> 15:58.190
And as a result, we are not going to forward that multicast stream out any

312
15:58.190 --> 15:59.500
other interfaces.

313
15:59.500 --> 16:01.500
We're just going to begin to receive it because it's already there.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

313
15:59.500 --> 16:01.500
We're just going to begin to receive it because it's already there.

314
16:01.500 --> 16:04.910
Nothing we can do about that, but we're not going to bother propagating it any

315
16:04.910 --> 16:05.500
further down.

316
16:05.500 --> 16:07.100
And that's what the RPF check is about.

317
16:07.100 --> 16:10.840
It's about pausing for a moment in the mind of the router considering the

318
16:10.840 --> 16:13.700
source, considering the interface that that traffic came in on.

319
16:13.700 --> 16:17.100
And if it's a yes, I would use that same interface to reach the source.

320
16:17.100 --> 16:19.500
That's an RPF check that says yes, I pass.

321
16:19.500 --> 16:21.990
And as a result with multicast, it's going to forward it down the other

322
16:21.990 --> 16:22.500
interfaces.

323
16:22.500 --> 16:25.810
And if the traffic comes in on another interface like serial three slash one,

324
16:25.810 --> 16:28.700
and it pauses to consider how do I reach the source address and it's not the

325
16:28.700 --> 16:29.500
same interface there.

326
16:29.500 --> 16:33.270
That's a failure of the RPF check. And as a result, the multicast group is not
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

326
16:29.500 --> 16:33.270
That's a failure of the RPF check. And as a result, the multicast group is not

327
16:33.270 --> 16:35.500
forwarded out of any other interfaces.

328
16:35.500 --> 16:39.710
So now that we've taken a big picture, look at many of the features of multic

329
16:39.710 --> 16:43.240
ast routing, in the next several videos, I'd like to walk you through step by

330
16:43.240 --> 16:47.500
step the configuration and verification of multicast routing.

331
16:47.500 --> 16:58.260
Not with an I-Torz making an expert at multicast routing, but rather, to help

332
16:58.260 --> 16:58.500
reinforce the concepts of PIM and IgMP and how a sparse mode implementation of

333
16:58.500 --> 16:58.500
PIM multicast routing.

334
16:58.500 --> 17:00.500
And again, we'll do it step by step.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

334
16:58.500 --> 17:00.500
And again, we'll do it step by step.

335
17:00.500 --> 17:02.500
Continue to the next video.

336
17:02.500 --> 17:04.500
So I'll see you there in just a moment.