1
00:00:08,320 --> 00:00:13,520
 Ok, antes de entrarmos nos detalhes
 do PIM como um multicast

2
00:00:13,520 --> 00:00:17,920
 protocolo de roteamento, vamos dar uma olhada
 em um nível realmente alto do que é multicast

3
00:00:17,920 --> 00:00:22,100
 protocolos de roteamento, por que precisamos
 deles, que problema eles foram projetados

4
00:00:22,100 --> 00:00:28,500
 resolver. Então sabemos que temos esse
 conceito de fontes e receptores,

5
00:00:28,500 --> 00:00:31,880
 a origem é algum servidor que está
 bombeando tráfego multicast

6
00:00:31,880 --> 00:00:35,740
 e atingindo seu roteador, esse roteador
 o está derrubando porque não há

7
00:00:35,740 --> 00:00:38,000
 ideia de onde deveria ir.

8
00:00:38,000 --> 00:00:41,380
 E do outro lado da rede você tem
 seus receptores seus laptops

9
00:00:41,380 --> 00:00:45,760
 seus PCs que desejam esse tráfego multicast,
 mas seu gateway padrão possui

10
00:00:45,760 --> 00:00:47,300
 não faço ideia de onde está a fonte.

11
00:00:47,300 --> 00:00:49,720
 Então, como conectamos os dois?

12
00:00:49,720 --> 00:00:54,140
 E essa é a razão pela qual precisamos de
 protocolos de roteamento multicast para

13
00:00:54,140 --> 00:00:58,140
 construir essa ramificação, para conectá-los,
 para construir esta distribuição multicast

14
00:00:58,140 --> 00:01:04,360
 árvore. Então precisamos
 criar essa árvore.

15
00:01:04,360 --> 00:01:07,580
 E eu falei no vídeo anterior que temos
 dois níveis básicos de alto nível

16
00:01:07,580 --> 00:01:09,160
 maneiras de fazer isso.

17
00:01:09,160 --> 00:01:13,380
 Um método, chamado modelo
 push, usado no modo denso

18
00:01:13,380 --> 00:01:17,440
 protocolos, significa simplesmente que
 vamos inundar a rede com esse multicast

19
00:01:17,440 --> 00:01:21,700
 tráfego. Você definitivamente chegará
 aos receptores e todos os outros

20
00:01:21,700 --> 00:01:26,460
 galhos da árvore onde caberá
 aos roteadores podá-los

21
00:01:26,460 --> 00:01:30,080
 ramificações para dizer, ei, roteador upstream,
 pare de enviar isso para mim.

22
00:01:30,080 --> 00:01:34,220
 Não tenho ninguém a jusante para
 mim que realmente queira isso.

23
00:01:34,220 --> 00:01:40,280
 O outro modelo é o modo esparso, o que significa,
 OK, uma vez que os receptores indiquem

24
00:01:40,280 --> 00:01:44,900
 seu interesse para o gateway padrão,
 o gateway padrão agora precisa

25
00:01:44,900 --> 00:01:48,520
 acionar algum tipo de mensagem de junção
 multicast dizendo: OK, vou enviar

26
00:01:48,520 --> 00:01:51,400
 uma mensagem upstream dizendo,
 ei, roteador acima de mim.

27
00:01:51,400 --> 00:01:56,100
 Se você receber esta mensagem, esse
 fluxo multicast, estou aqui.

28
00:01:56,100 --> 00:02:01,820
 Eu quero aquilo. A questão então é:
 OK, bem, onde está o seu padrão

29
00:02:01,820 --> 00:02:03,120
 gateway enviar isso?

30
00:02:03,120 --> 00:02:08,020
 Porque talvez ele tenha cinco ou seis
 roteadores instalados a montante dele.

31
00:02:08,020 --> 00:02:10,760
 Para qual deles ele envia esta junção?

32
00:02:10,760 --> 00:02:15,620
 Então, para responder a isso, aqui
 está uma boa analogia que fiz.

33
00:02:15,620 --> 00:02:18,600
 Pense em namorar, certo?

34
00:02:18,600 --> 00:02:21,540
 Rapazes e meninas namorando
 tentando se encontrar.

35
00:02:21,540 --> 00:02:27,880
 Então, um protocolo de modo denso seria
 tipo, você é o cara, você anda

36
00:02:27,880 --> 00:02:31,460
 em uma boate, e para encontrar seu companheiro
 perfeito, basta caminhar

37
00:02:31,460 --> 00:02:34,580
 até cada garota que está aqui
 dizendo, ei, eu te amo.

38
00:02:34,580 --> 00:02:35,660
 Você gostaria de se casar comigo?

39
00:02:35,660 --> 00:02:37,380
 Eu te amo. Você gostaria
 de se casar comigo?

40
00:02:37,380 --> 00:02:40,220
 Claro, você leva um tapa várias
 vezes por estar fazendo isso.

41
00:02:40,220 --> 00:02:43,120
 Mas espero que, eventualmente, você
 encontre seu receptor, certo?

42
00:02:43,120 --> 00:02:46,180
 No canto mais distante, a garota que está
 bebendo muita cerveja, ela vai dizer:

43
00:02:46,180 --> 00:02:47,400
 sim, eu quero me casar com você.

44
00:02:47,400 --> 00:02:49,980
 E agora você encontrou seu receptor.

45
00:02:49,980 --> 00:02:50,680
 Você é a fonte.

46
00:02:50,680 --> 00:02:51,300
 Ela é a receptora.

47
00:02:51,300 --> 00:02:54,160
 Você tinha que passar por todos os outros
 primeiro e ser podado novamente.

48
00:02:54,160 --> 00:02:56,820
 Mas, eventualmente, você encontrou
 quem estava procurando.

49
00:02:56,820 --> 00:02:59,040
 É como um protocolo de modo denso.

50
00:02:59,040 --> 00:03:02,680
 Um protocolo de modo esparso é como,
 em vez de fazer isso e arriscar tudo

51
00:03:02,680 --> 00:03:06,140
 essa rejeição, você usa
 um serviço de namoro.

52
00:03:06,140 --> 00:03:09,660
 Então você tem essa empresa intermediária
 chamada serviço de namoro, você sabe,

53
00:03:09,660 --> 00:03:15,140
 tanto faz, eharmony.com ou qualquer que
 seja o grande problema hoje em dia.

54
00:03:15,140 --> 00:03:19,540
 E a fonte, você, vai ao serviço
 de namoro e cria um perfil.

55
00:03:19,540 --> 00:03:21,260
 E você diz, ei, esse sou eu.

56
00:03:21,260 --> 00:03:22,400
 Eu sou tão maravilhoso e ótimo.

57
00:03:22,400 --> 00:03:23,900
 Eu ganho US$ 5 milhões por ano.

58
00:03:23,900 --> 00:03:24,880
 Eu dirijo uma Ferrari.

59
00:03:24,880 --> 00:03:26,160
 Por favor, case comigo.

60
00:03:26,160 --> 00:03:28,340
 Certo? Então você posta suas coisas
 lá no serviço de namoro.

61
00:03:28,340 --> 00:03:31,800
 As receptoras, bem, você sabe, de todos
 os 50 milhões de mulheres que usam

62
00:03:31,800 --> 00:03:35,180
 aquele serviço de namoro, pode haver três
 deles que vão para esse serviço de namoro

63
00:03:35,180 --> 00:03:38,020
 serviço e dizer, ah, sim, é exatamente
 isso que estou procurando.

64
00:03:38,020 --> 00:03:38,800
 Ele é meio idiota.

65
00:03:38,800 --> 00:03:39,600
 Ele tem muito dinheiro.

66
00:03:39,600 --> 00:03:40,920
 Ele tem uma Ferrari.

67
00:03:40,920 --> 00:03:41,640
 Eu vou gostar daquele cara.

68
00:03:41,640 --> 00:03:45,140
 E então vocês dois se encontram através
 do serviço de namoro e inicialmente

69
00:03:45,140 --> 00:03:47,700
 vocês não podem conversar
 um com o outro, certo?

70
00:03:47,700 --> 00:03:50,340
 Inicialmente, o serviço de namoro diz, não,
 você sabe, para garantir que esse cara

71
00:03:50,340 --> 00:03:53,420
 não é uma perseguidora e ela não é
 louca, você sabe, não vamos deixar

72
00:03:53,420 --> 00:03:56,380
 vocês trocam números de telefone,
 endereços e outras coisas.

73
00:03:56,380 --> 00:03:59,740
 Você terá que usar nosso sistema de chat
 e nosso sistema de e-mail para conversar

74
00:03:59,740 --> 00:04:03,900
 um para o outro. Mas, eventualmente, depois
 de você ter trocado mensagens através

75
00:04:03,900 --> 00:04:07,580
 o serviço de namoro, agora vocês
 podem saber onde moram.

76
00:04:07,580 --> 00:04:10,120
 Você pode trocar números de
 telefone e parar de usá-los.

77
00:04:10,120 --> 00:04:12,460
 Você pode se comunicar diretamente.

78
00:04:12,460 --> 00:04:15,160
 É assim que funcionam os protocolos
 de modo esparso.

79
00:04:15,160 --> 00:04:19,080
 Com protocolos de modo esparso, você
 tem algum roteador em algum lugar

80
00:04:19,080 --> 00:04:23,180
 sua rede que funciona como aquela funcionalidade
 de serviço de namoro.

81
00:04:23,180 --> 00:04:28,200
 E assim os receptores, assim que o seu laptop
 enviar a mensagem IGMP para o roteador,

82
00:04:28,200 --> 00:04:32,880
 seu gateway padrão, seu gateway padrão
 diz, hmm, ok, eu sei que tenho

83
00:04:32,880 --> 00:04:40,060
 um receptor aqui, não tenho
 ideia de onde está a fonte.

84
00:04:40,060 --> 00:04:44,720
 receptor deseja. Mas eu sei onde está
 o serviço de namoro nos termos

85
00:04:44,720 --> 00:04:48,700
 de um protocolo de roteamento multicast, esse
 serviço de namoro é o que chamamos de

86
00:04:48,700 --> 00:04:51,160
 ponto de encontro, um RP.

87
00:04:51,160 --> 00:04:54,660
 Então há algum roteador na rede que todos
 os roteadores rodando multicast

88
00:04:54,660 --> 00:04:57,380
 sei que esse cara é o
 cara que procuramos.

89
00:04:57,380 --> 00:04:59,460
 Esse é o ponto de encontro.

90
00:04:59,460 --> 00:05:03,060
 Então agora seu roteador dirá,
 ok, vou criar algo chamado

91
00:05:03,060 --> 00:05:05,380
 uma junção, uma mensagem
 de junção multicast.

92
00:05:05,380 --> 00:05:09,520
 E vou enviá-lo na direção do ponto
 de encontro dizendo, ei,

93
00:05:09,520 --> 00:05:12,520
 Tenho um cara aqui que está
 procurando esse grupo.

94
00:05:12,520 --> 00:05:17,460
 E então, eventualmente, essa junção
 chega ao ponto de encontro.

95
00:05:17,460 --> 00:05:20,900
 Agora a fonte pode ainda não ter começado,
 mas o ponto de encontro agora

96
00:05:20,900 --> 00:05:25,000
 construiu um galho na árvore
 desde o ponto de encontro até

97
00:05:25,000 --> 00:05:27,120
 esses roteadores até seu gateway padrão.

98
00:05:27,120 --> 00:05:32,320
 Agora abrimos um caminho para que,
 se o multicast começar, ele terá

99
00:05:32,320 --> 00:05:34,240
 uma direção em que ele possa fluir.

100
00:05:34,240 --> 00:05:38,040
 Agora a fonte, a fonte
 inicia, o servidor.

101
00:05:38,040 --> 00:05:41,900
 Então esse servidor começa a enviar
 seu multicast e atinge seu roteador,

102
00:05:41,900 --> 00:05:45,580
 algum roteador conectado a esse segmento,
 está sendo golpeado na parte traseira do

103
00:05:45,580 --> 00:05:47,580
 a cabeça com esse tráfego multicast.

104
00:05:47,580 --> 00:05:50,440
 Mais uma vez, aquele roteador lá
 em cima, no outro canto da rede

105
00:05:50,440 --> 00:05:55,300
 diz, nunca tive notícias de nenhum receptor,
 mas sei onde está o namoro

106
00:05:55,300 --> 00:06:03,540
 serviço é. Eu sei onde
 é o ponto de encontro.

107
00:06:03,540 --> 00:06:07,080
 E entraremos em mais detalhes sobre
 isso, mas basicamente encapsula

108
00:06:07,080 --> 00:06:12,500
 em unicast. Ele pega aquele pacote multicast
 e o envolve dentro de um unicast

109
00:06:12,500 --> 00:06:16,500
 cabeçalho e o envia para
 o ponto de encontro.

110
00:06:16,500 --> 00:06:20,920
 Assim que chega o ponto de encontro,
 ele desencapsula e diz, ah, aqui está

111
00:06:20,920 --> 00:06:24,240
 multitransmissão. Ah, sim, eu sei onde
 isso vai porque recebi uma adesão

112
00:06:24,240 --> 00:06:27,360
 por isso e ele manda descer da árvore.

113
00:06:27,360 --> 00:06:31,020
 Então é assim que nos protocolos de modo esparso
 inicialmente os conectamos, certo?

114
00:06:31,020 --> 00:06:33,460
 Esse ponto de encontro é
 o serviço de encontros.

115
00:06:33,460 --> 00:06:37,460
 Mas, assim como na minha analogia, você
 não quer que a fonte e o receptor

116
00:06:37,460 --> 00:06:41,360
 passando constantemente pelo ponto de encontro
 para conversar um com o outro.

117
00:06:41,360 --> 00:06:43,400
 Não é necessariamente eficiente, certo?

118
00:06:43,400 --> 00:06:49,980
 E se o receptor estiver na Flórida, a
 fonte estiver na Carolina do Norte,

119
00:06:49,980 --> 00:06:52,680
 mas o ponto de encontro é na Califórnia?

120
00:06:52,680 --> 00:06:55,700
 Bem, nesse trânsito está saindo do caminho
 para chegar ao ponto de encontro

121
00:06:55,700 --> 00:07:00,300
 apontar e voltar. Há um caminho muito
 mais curto diretamente entre a fonte

122
00:07:00,300 --> 00:07:02,140
 e o receptor.

123
00:07:02,140 --> 00:07:06,080
 Mas tivemos que iniciar esse multicast
 antes de podermos descobrir

124
00:07:06,080 --> 00:07:10,320
 de onde vem, que vem
 da Carolina do Norte.

125
00:07:10,320 --> 00:07:13,280
 E agora os Rogers podem
 seguir esse caminho.

126
00:07:13,280 --> 00:07:15,060
 Eles podem dizer: OK, obrigado,
 serviço de encontros.

127
00:07:15,060 --> 00:07:16,380
 Obrigado, ponto de encontro.

128
00:07:16,380 --> 00:07:17,760
 Não preciso mais de você.

129
00:07:17,760 --> 00:07:20,240
 Agora sei exatamente onde está a fonte.

130
00:07:20,240 --> 00:07:24,040
 Podemos obter o tráfego diretamente
 dele e podemos mudar para isso

131
00:07:24,040 --> 00:07:29,360
 caminho. Portanto, esse é um nível realmente alto
 de como os protocolos de modo esparso funcionam.

132
00:07:29,360 --> 00:07:33,540
 Temos que nos juntar primeiro ao ponto de
 encontro, expressar o nosso interesse,

133
00:07:33,540 --> 00:07:35,440
 construir esse ramo.

134
00:07:35,440 --> 00:07:39,680
 O tráfego tem que começar a ir para
 o ponto de encontro e depois muda

135
00:07:39,680 --> 00:07:44,620
 acabou, então vai diretamente entre a
 fonte e o receptor, ponto de encontro

136
00:07:44,620 --> 00:07:49,260
 ponto nem faz mais parte da equação.

137
00:07:49,260 --> 00:07:56,680
 Portanto, os protocolos de modo esparso usam algo
 chamado árvores baseadas em núcleo ou árvores RP

138
00:07:56,680 --> 00:07:58,500
 porque temos um ponto de encontro.

139
00:07:58,500 --> 00:08:01,140
 Portanto, o ponto de encontro
 é o núcleo da árvore.

140
00:08:01,140 --> 00:08:05,620
 Todo mundo começa indo até ele
 e então se afasta dele muito

141
00:08:05,620 --> 00:08:16,700
 rapidamente. OK, então RPF, caso você não
 esteja familiarizado, é claro, RPF poderia

142
00:08:16,700 --> 00:08:16,880
 mude para a árvore.

143
00:08:16,880 --> 00:08:20,780
 São muitas coisas diferentes, mas
 neste caso em particular significa

144
00:08:20,780 --> 00:08:23,260
 encaminhamento de caminho reverso.

145
00:08:23,260 --> 00:08:27,060
 Agora pense no tráfego unicast.

146
00:08:27,060 --> 00:08:29,840
 Vamos nos afastar do multicast
 por um segundo.

147
00:08:29,840 --> 00:08:36,720
 Um roteador recebe um pacote unicast
 indo para algum destino 9.9.9.9.

148
00:08:36,720 --> 00:08:38,560
 O que o roteador faz?

149
00:08:38,560 --> 00:08:43,420
 O roteador diz: OK, vou verificar
 o endereço IP de destino,

150
00:08:43,420 --> 00:08:47,920
 entre na minha tabela de roteamento e veja
 se tenho algum tipo de rota que diga

151
00:08:47,920 --> 00:08:49,940
 me onde fica esse destino.

152
00:08:49,940 --> 00:08:54,740
 Normalmente, para encaminhar esse
 pacote para colocá-lo a caminho,

153
00:08:54,740 --> 00:08:58,060
 o roteador se preocupa com
 a origem desse pacote?

154
00:08:58,060 --> 00:09:01,320
 Não, você não está nem aí para
 qual é o endereço de origem.

155
00:09:01,320 --> 00:09:05,260
 Na verdade, você poderia colocar
 0, 0, 0, 0 como fonte, o roteador

156
00:09:05,260 --> 00:09:09,220
 não me importaria. Para rotear esse
 pacote, tudo o que importa é o

157
00:09:09,220 --> 00:09:13,920
 destino. Agora certamente você poderia
 implementar listas de acesso e outras

158
00:09:13,920 --> 00:09:17,120
 coisas assim para forçá-lo
 a olhar para a fonte.

159
00:09:17,120 --> 00:09:20,580
 E você também pode implementar
 algo chamado RPF.

160
00:09:20,580 --> 00:09:25,720
 Por exemplo, e se eu, você sabe, digamos
 que meu laptop agora esteja parado

161
00:09:25,720 --> 00:09:32,120
 na rede 11, 11.alguma coisa, então
 tive um endereço 11, 11.555.

162
00:09:32,120 --> 00:09:34,820
 Esse é o endereço do meu laptop.

163
00:09:34,820 --> 00:09:38,280
 E eu descubro, descubro
 pelos boatos que vou ser

164
00:09:38,280 --> 00:09:41,080
 demitido hoje. Eu digo o que?

165
00:09:41,080 --> 00:09:43,260
 Cara, passei muitos anos nesta empresa.

166
00:09:43,260 --> 00:09:44,340
 Eu trabalhei horas extras.

167
00:09:44,340 --> 00:09:46,520
 Sacrifiquei meus filhos por esta empresa.

168
00:09:46,520 --> 00:09:47,560
 Eles vão me demitir.

169
00:09:47,560 --> 00:09:49,260
 Isso realmente me irrita.

170
00:09:49,260 --> 00:09:50,440
 Então eu digo, quer saber?

171
00:09:50,440 --> 00:09:56,140
 Antes de ir, sei qual é o endereço IP
 do servidor web da minha empresa.

172
00:09:56,140 --> 00:10:00,000
 É 77777. Então, sou um pouco
 experiente o suficiente.

173
00:10:00,000 --> 00:10:00,560
 Eu digo, quer saber?

174
00:10:00,560 --> 00:10:01,720
 Vou derrubar esse servidor.

175
00:10:01,720 --> 00:10:05,040
 Vou atacar aquele servidor com,
 não sei, algum tipo de tráfego.

176
00:10:05,040 --> 00:10:07,300
 Talvez solicitações de sincronização
 TCP, certo?

177
00:10:07,300 --> 00:10:11,080
 Vou acabar com 5 milhões de sincronizações
 TCP a cada segundo.

178
00:10:11,080 --> 00:10:12,440
 Traz isso para baixo. Então ha ha ha.

179
00:10:12,440 --> 00:10:13,540
 Você quer me despedir?

180
00:10:13,540 --> 00:10:15,780
 Vou fazer vocês perderem milhões
 de dólares nos próximos dois

181
00:10:15,780 --> 00:10:18,100
 de horas enquanto seu
 servidor está inativo.

182
00:10:18,100 --> 00:10:22,240
 Bem, se eu decidir fazer isso, não quero
 que as pessoas rastreiem esses pacotes

183
00:10:22,240 --> 00:10:23,580
 de volta para mim, certo?

184
00:10:23,580 --> 00:10:27,360
 Porque não só serei despedido, como
 agora estarei numa cela com

185
00:10:27,360 --> 00:10:29,060
 alguém de quem não gosto particularmente.

186
00:10:29,060 --> 00:10:30,280
 Então eu não quero isso.

187
00:10:30,280 --> 00:10:34,080
 Então eu digo, hmm, se vou enviar essas solicitações
 de sincronização TCP para esse servidor

188
00:10:34,080 --> 00:10:37,480
 para tentar sobrecarregá-lo, quero ter
 certeza de que o endereço de origem é

189
00:10:37,480 --> 00:10:41,160
 eu não. Eu não quero ser
 11555, que sou eu.

190
00:10:41,160 --> 00:10:44,940
 Quero falsificar esse endereço de origem
 para se parecer com outra coisa.

191
00:10:44,940 --> 00:10:49,000
 Então, se encontrarem esses pacotes,
 nunca saberão que vieram de mim.

192
00:10:49,000 --> 00:10:53,000
 Então, vou fornecer um endereço IP falso
 porque sei quando esses pacotes chegam

193
00:10:53,000 --> 00:11:00,260
 os roteadores, os roteadores não se
 importam com o endereço de origem.

194
00:11:00,260 --> 00:11:02,260
 E vai falhar.

195
00:11:02,260 --> 00:11:06,960
 Bem, se eu sou o administrador da rede,
 uma coisa que posso fazer para evitar

196
00:11:06,960 --> 00:11:12,540
 pessoas fazendo isso é que posso usar o que
 é chamado de verificação RPF unicast,

197
00:11:12,540 --> 00:11:16,740
 o que significa que quando um pacote entra
 em uma interface em um roteador, antes

198
00:11:16,740 --> 00:11:21,460
 Eu até olho o endereço de destino,
 vou olhar a origem

199
00:11:21,460 --> 00:11:25,440
 endereço, e vou me fazer uma
 pergunta muito simples.

200
00:11:25,440 --> 00:11:31,180
 Esse endereço de origem, se eu voltasse
 na direção inversa para

201
00:11:31,180 --> 00:11:36,280
 essa fonte, eu usaria essa interface
 onde ela acabou de entrar?

202
00:11:36,280 --> 00:11:38,480
 Agora estou sentado aqui.

203
00:11:38,480 --> 00:11:44,100
 Tenho 11.555. Alterei intencionalmente
 o endereço de origem do meu pacote

204
00:11:44,100 --> 00:11:49,320
 para algo completamente falso,
 como 12, 12, 12, 12.

205
00:11:49,320 --> 00:11:51,060
 Bem, ele veio nesta interface.

206
00:11:51,060 --> 00:11:53,580
 Chegou rápido Ethan às 00 no roteador.

207
00:11:53,580 --> 00:11:57,720
 De acordo com a tabela de roteamento deste
 roteador, diz ele, para chegar aos 12, 12

208
00:11:57,720 --> 00:12:01,120
 rede, eu não iria rápido Ethan às 00.

209
00:12:01,120 --> 00:12:03,740
 Eu sairia da série 11.

210
00:12:03,740 --> 00:12:08,120
 Portanto, se esse administrador de rede
 configurou a verificação RPF unicast

211
00:12:08,120 --> 00:12:11,260
 o roteador, o roteador dirá, há
 algo errado com este pacote.

212
00:12:11,260 --> 00:12:15,660
 De acordo com meu caminho inverso, eu não
 seguiria esse caminho para chegar ao 12.

213
00:12:15,660 --> 00:12:16,700
 Eu iria por aqui.

214
00:12:16,700 --> 00:12:21,280
 O pacote veio na interface
 errada e seria descartado.

215
00:12:21,280 --> 00:12:22,340
 Seria descartado.

216
00:12:22,340 --> 00:12:25,760
 E agora meu servidor nunca
 receberia esse pacote.

217
00:12:25,760 --> 00:12:27,980
 Isso nunca prejudicaria o servidor.

218
00:12:27,980 --> 00:12:29,900
 Isso não está ativado por padrão.

219
00:12:29,900 --> 00:12:33,580
 A verificação Unicast RPF é algo que
 você deve ativar se quiser fazer

220
00:12:33,580 --> 00:12:36,840
 que. Bem, como isso se
 relaciona com isso?

221
00:12:36,840 --> 00:12:43,420
 Quando você habilita o multicast, os protocolos de
 roteamento multicast fazem verificações RPF em

222
00:12:43,420 --> 00:12:45,780
 a fonte por padrão.

223
00:12:45,780 --> 00:12:48,140
 Na verdade, você não pode
 impedi-los de fazer isso.

224
00:12:48,140 --> 00:12:50,400
 Eles fazem isso. Agora,
 por que eles fazem isso?

225
00:12:50,400 --> 00:12:52,940
 Eles fazem isso para detecção de loop.

226
00:12:52,940 --> 00:12:56,240
 A ideia é que quando um pacote multicast
 chega, você não quer apenas circular

227
00:12:56,240 --> 00:12:58,600
 em torno da rede para sempre.

228
00:12:58,600 --> 00:13:04,280
 Então o que os roteadores fazem é dizer, ok,
 o roteador está rodando no modo esparso

229
00:13:04,280 --> 00:13:08,840
 protocolos. Então, se eu sou um roteador
 conectado a uma rede, digamos que estou

230
00:13:08,840 --> 00:13:09,700
 o gateway padrão.

231
00:13:09,700 --> 00:13:14,020
 Sou o gateway conectado a este
 receptor, ao meu laptop aqui.

232
00:13:14,020 --> 00:13:18,800
 E acabei de ser informado via IGMP
 que este receptor deseja receber

233
00:13:18,800 --> 00:13:22,240
 algum multicast. 239-777.

234
00:13:22,240 --> 00:13:27,780
 Vamos apenas desenhar isso
 para deixar isso claro.

235
00:13:27,780 --> 00:13:39,460
 OK. Então, aqui está, oh,
 espere só um segundo.

236
00:13:39,460 --> 00:13:42,820
 Vou fazer assim então.

237
00:13:42,820 --> 00:13:47,540
 Aqui está meu receptor
 aqui como um quadrado.

238
00:13:47,540 --> 00:13:50,920
 Vamos colocar isso como um pequeno R.

239
00:13:50,920 --> 00:13:58,180
 E aqui está o gateway padrão
 ao qual ele está conectado.

240
00:13:58,180 --> 00:14:01,940
 Gateway padrão.

241
00:14:01,940 --> 00:14:08,900
 E ele tem várias interfaces
 que levam ao upstream.

242
00:14:08,900 --> 00:14:14,720
 Diremos apenas interface um, dois e três.

243
00:14:14,720 --> 00:14:16,320
 Não importa o que sejam.

244
00:14:16,320 --> 00:14:19,840
 Serial Ethernet rápido, é irrelevante
 para esta discussão.

245
00:14:19,840 --> 00:14:27,300
 Agora, este roteador acaba de receber
 um relatório de associação IGMP do

246
00:14:27,300 --> 00:14:39,060
 receptor. E esse receptor deseja
 obter o tráfego de 239-777.

247
00:14:39,060 --> 00:14:41,740
 Esse é o grupo do qual
 ele quer participar.

248
00:14:41,740 --> 00:14:46,020
 Agora, este roteador está executando um
 protocolo de roteamento de modo esparso.

249
00:14:46,020 --> 00:14:47,280
 Então, diremos apenas que é PIM.

250
00:14:47,280 --> 00:14:51,420
 Ele está executando o protocolo de roteamento
 multicast independente de protocolo.

251
00:14:51,420 --> 00:14:54,120
 Então, como parte do PIM, para fazer
 o PIM funcionar, ele diz, ok, eu sei

252
00:14:54,120 --> 00:14:55,420
 há algum roteador em algum lugar.

253
00:14:55,420 --> 00:15:00,660
 Chamaremos isso daqui, que
 é meu ponto de encontro.

254
00:15:00,660 --> 00:15:04,140
 E então eu tenho que avisar ao ponto
 de encontro que tenho um receptor

255
00:15:04,140 --> 00:15:05,860
 aqui embaixo quem quer isso.

256
00:15:05,860 --> 00:15:10,240
 Então digamos que este ponto
 de encontro seja 8888.

257
00:15:10,240 --> 00:15:14,580
 Então esse roteador, ele diz, ok, eu sei.

258
00:15:14,580 --> 00:15:17,400
 Vamos apenas fazer um pequeno
 balão de pensamento aqui.

259
00:15:17,400 --> 00:15:22,220
 Ele diz, eu sei que o PIM RP é 8888.

260
00:15:22,220 --> 00:15:26,960
 Agora, ele diz, ok, como faço
 para chegar ao PIM RP?

261
00:15:26,960 --> 00:15:30,260
 Agora, é aqui que ele usa seu protocolo
 de roteamento unicast.

262
00:15:30,260 --> 00:15:35,100
 Já mencionei algumas vezes que o roteamento
 multicast funciona de mãos dadas com

263
00:15:35,100 --> 00:15:36,920
 seu protocolo de roteamento unicast.

264
00:15:36,920 --> 00:15:39,560
 Então ele diz, ok, deixe-me entrar
 na minha tabela de roteamento.

265
00:15:39,560 --> 00:15:42,980
 E de acordo com minha tabela de roteamento,
 tenho uma rota EI-JRP que diz

266
00:15:42,980 --> 00:15:49,800
 para chegar à rede 8.8 é via interface 2.

267
00:15:49,800 --> 00:15:56,920
 Então ele envia uma interface
 PIM join out 2.

268
00:15:56,920 --> 00:16:04,620
 E, eventualmente, essa junção
 do PIM percorre a rede e fica

269
00:16:04,620 --> 00:16:06,420
 até o ponto de encontro.

270
00:16:06,420 --> 00:16:09,840
 Então esta é agora a árvore
 compartilhada, certo?

271
00:16:09,840 --> 00:16:14,600
 Esta é a árvore que vai do ponto
 de encontro até o gateway padrão.

272
00:16:14,600 --> 00:16:19,960
 Agora, este gateway padrão, porque ele está
 executando o modo escasso do PIMS, ele diz,

273
00:16:19,960 --> 00:16:27,080
 ok, espero que quando o multicast
 começar, sempre que começar,

274
00:16:27,080 --> 00:16:31,260
 deveria descer do ponto de encontro.

275
00:16:31,260 --> 00:16:35,640
 Então, digamos que o multicast
 seja iniciado e aí vem.

276
00:16:35,640 --> 00:16:38,680
 Aqui desce desta forma.

277
00:16:38,680 --> 00:16:44,540
 Portanto a fonte é 7777.

278
00:16:44,540 --> 00:16:48,660
 O destino é 239.777.

279
00:16:48,660 --> 00:16:54,700
 Bem, como esse cara está executando o modo escasso
 do PIMS, ele faz uma verificação de RPF.

280
00:16:54,700 --> 00:16:55,660
 Mas é assim que funciona.

281
00:16:55,660 --> 00:17:01,200
 Ele diz, bem, porque eu esperava que
 esse multicast viesse através do

282
00:17:01,200 --> 00:17:06,740
 ponto de encontro, diz ele, em que
 interface deveria ter entrado?

283
00:17:06,740 --> 00:17:10,820
 Bem, de acordo com minha tabela de roteamento,
 para chegar ao ponto de encontro, eu

284
00:17:10,820 --> 00:17:12,540
 vá pela interface 2.

285
00:17:12,540 --> 00:17:16,860
 Huh, este multicast não saiu
 do ponto de encontro.

286
00:17:16,860 --> 00:17:19,000
 Não veio da interface 2.

287
00:17:19,000 --> 00:17:21,820
 Então adivinhe? Eu vou matá-lo.

288
00:17:21,820 --> 00:17:24,240
 Esta é uma falha de RPF.

289
00:17:24,240 --> 00:17:29,080
 Não desceu o que chamamos de árvore compartilhada,
 a árvore que é compartilhada

290
00:17:29,080 --> 00:17:31,620
 entre o ponto de encontro
 e esse gateway padrão.

291
00:17:31,620 --> 00:17:35,460
 Apenas falhou na verificação RPF.

292
00:17:35,460 --> 00:17:38,740
 Agora digamos que tenha
 acontecido desta forma.

293
00:17:38,740 --> 00:17:41,820
 Ok, então veio pelo caminho correto.

294
00:17:41,820 --> 00:17:43,960
 A verificação RPF seria bem-sucedida.

295
00:17:43,960 --> 00:17:48,020
 Isso passaria. Ele dizia, ok, estou interessado
 neste grupo, e isso aconteceu

296
00:17:48,020 --> 00:17:52,640
 entre na interface correta, na
 interface 2, que é a interface

297
00:17:52,640 --> 00:17:55,100
 levando ao PR.

298
00:17:55,100 --> 00:17:56,760
 Agora algo interessante acontece.

299
00:17:56,760 --> 00:17:58,480
 Então vamos em frente e colocar
 isso de volta aqui.

300
00:17:58,480 --> 00:18:04,080
 A origem foi 777. O destino foi 239.777.

301
00:18:04,080 --> 00:18:09,460
 Ok, então ele pode encaminhar esse multicast
 para o cliente, para o receptor.

302
00:18:09,460 --> 00:18:14,760
 Agora, pela primeira vez, este roteador
 diz: ah, finalmente, eu sei quem

303
00:18:14,760 --> 00:18:21,480
 a fonte é. O endereço real
 do servidor é 777.

304
00:18:21,480 --> 00:18:25,860
 Agora PIMS-SPAR-SMO diz, ok, eu poderia
 continuar recebendo isso do encontro

305
00:18:25,860 --> 00:18:28,640
 ponto, mas existe um caminho melhor?

306
00:18:28,640 --> 00:18:32,880
 Existe realmente um caminho mais curto
 para chegar a essa fonte que seria mais

307
00:18:32,880 --> 00:18:36,900
 eficiente? Então ele volta para
 sua tabela de roteamento.

308
00:18:36,900 --> 00:18:42,140
 Ele diz, ok, agora deixe-me fazer
 uma pesquisa RPF sobre isso.

309
00:18:42,140 --> 00:18:48,060
 E ele diz, ah, eis que tenho uma rota
 que corresponde a isso, a isso

310
00:18:48,060 --> 00:18:49,880
 Aprendi via EIGRP.

311
00:18:49,880 --> 00:18:52,620
 Mais uma vez, poderia ser
 aprendido via RIP ou OSPF.

312
00:18:52,620 --> 00:18:58,240
 Nós não nos importamos. Ele
 diz, isso é via interface 1.

313
00:18:58,240 --> 00:19:00,740
 Então agora o PIM faz algo especial.

314
00:19:00,740 --> 00:19:04,940
 Ele envia outro PIM para
 fora dessa maneira.

315
00:19:04,940 --> 00:19:09,720
 Vamos entrar em todos os detalhes disso.

316
00:19:09,720 --> 00:19:17,340
 E ele diz, isso é para a origem
 777 destino 239.777.

317
00:19:17,340 --> 00:19:21,820
 E essa junção do PIM vai até o fim.

318
00:19:21,820 --> 00:19:25,960
 E digamos que a fonte esteja bem aqui.

319
00:19:25,960 --> 00:19:31,360
 Na verdade, é onde está o servidor.

320
00:19:31,360 --> 00:19:34,540
 E tem havido vários roteadores no meio.

321
00:19:34,540 --> 00:19:36,000
 Então aqui estava um roteador.

322
00:19:36,000 --> 00:19:37,760
 Aqui está um roteador.

323
00:19:37,760 --> 00:19:38,940
 E aqui está um roteador.

324
00:19:38,940 --> 00:19:41,000
 E eles estão todos conectados assim.

325
00:19:41,000 --> 00:19:47,760
 Supondo que todos esses roteadores
 saibam como chegar à rede 777, isso

326
00:19:47,760 --> 00:19:52,620
 a junção especial do PIM teria subido
 até o fim e finalmente chegado

327
00:19:52,620 --> 00:19:55,560
 este roteador que está conectado à fonte.

328
00:19:55,560 --> 00:19:59,240
 E isso agora abriu a árvore
 do caminho mais curto.

329
00:19:59,240 --> 00:20:00,780
 Observe que temos duas árvores
 diferentes aqui.

330
00:20:00,780 --> 00:20:04,520
 Temos o azul e o verde.

331
00:20:04,520 --> 00:20:08,560
 E o ponto azul até o gateway padrão
 era chamado de árvore compartilhada

332
00:20:08,560 --> 00:20:11,280
 ou às vezes chamada de árvore RP.

333
00:20:11,280 --> 00:20:14,400
 Às vezes você pode ver a sigla RPT.

334
00:20:14,400 --> 00:20:19,240
 Isso funcionou, mas pode não
 ser o caminho mais eficiente.

335
00:20:19,240 --> 00:20:23,720
 Esta árvore verde é a árvore
 do caminho mais curto.

336
00:20:23,720 --> 00:20:28,320
 Mas não sabíamos o que era isso até
 sabermos onde estava a fonte até

337
00:20:28,320 --> 00:20:31,140
 recebemos nosso primeiro
 pacote multicast.

338
00:20:31,140 --> 00:20:35,360
 E agora que abrimos aquela
 árvore, o roteador diz, ok,

339
00:20:35,360 --> 00:20:42,380
 neste ponto, por um breve momento, na
 próxima vez que eu receber o multicast

340
00:20:42,380 --> 00:20:45,660
 pacote, ele pode vir de
 um de dois lugares.

341
00:20:45,660 --> 00:20:50,200
 Vou aceitá-lo na interface dois
 porque ainda pode vir de

342
00:20:50,200 --> 00:20:51,800
 o ponto de encontro.

343
00:20:51,800 --> 00:20:55,680
 E agora, se vier na interface
 um, também aceitarei porque

344
00:20:55,680 --> 00:20:57,000
 tentei abrir esse caminho.

345
00:20:57,000 --> 00:21:01,560
 Eu tentei intencionalmente abrir esse caminho
 esperando que o tráfego multicast

346
00:21:01,560 --> 00:21:04,100
 vai descer por aqui.

347
00:21:04,100 --> 00:21:09,320
 Portanto, agora, se o multicast vier na
 interface três, será uma falha de RPF.

348
00:21:09,320 --> 00:21:12,660
 Porque o roteador diz, ei, interface três,
 essa não é a árvore compartilhada

349
00:21:12,660 --> 00:21:16,180
 e não é a árvore do caminho mais curto.

350
00:21:16,180 --> 00:21:20,720
 Mas se um deles falhar, ele passará
 na verificação do RPF.

351
00:21:20,720 --> 00:21:25,920
 E assim que o multicast realmente começar
 a fluir e entrar na interface

352
00:21:25,920 --> 00:21:30,500
 número um, agora o gateway
 padrão dirá, ótimo!

353
00:21:30,500 --> 00:21:33,940
 Estou obtendo o tráfego multicast
 da maneira mais eficiente possível

354
00:21:33,940 --> 00:21:36,260
 através da árvore de caminho mais curto.

355
00:21:36,260 --> 00:21:39,340
 Não preciso mais tirá-lo
 do ponto de encontro.

356
00:21:39,340 --> 00:21:44,380
 Então, ele enviará uma mensagem de remoção
 do PIM desta forma, que removerá

357
00:21:44,380 --> 00:21:51,460
 desta árvore. E agora o multicast
 fluirá pelo caminho mais curto

358
00:21:51,460 --> 00:21:56,100
 árvore de caminhos até que o
 receptor não a queira mais.

359
00:21:56,100 --> 00:21:59,760
 Portanto, esse é um nível muito alto de
 como funciona o modo esparso do PIM.

360
00:21:59,760 --> 00:22:04,280
 Mas fiz tudo isso para mostrar que as
 verificações de RPF estão acontecendo.

361
00:22:04,280 --> 00:22:09,860
 Tudo depende de onde o roteador
 espera obter o multicast.

362
00:22:09,860 --> 00:22:13,480
 Se ele espera que isso venha
 do ponto de encontro, ele vai

363
00:22:13,480 --> 00:22:17,860
 digamos, olhe, o ponto de encontro fica
 na interface um ou na interface sete,

364
00:22:17,860 --> 00:22:20,640
 e ele aprende isso por meio de
 seu protocolo de roteamento.

365
00:22:20,640 --> 00:22:24,280
 É aí que espero obter o
 multicast inicialmente.

366
00:22:24,280 --> 00:22:27,800
 Se vier de qualquer outra
 interface, vou eliminá-lo.

367
00:22:27,800 --> 00:22:28,820
 Eu vou largar isso.

368
00:22:28,820 --> 00:22:31,340
 Não era para acontecer assim.

369
00:22:31,340 --> 00:22:34,880
 Mas uma vez que ele sabe qual é a fonte
 e tenta abrir o caminho mais curto

370
00:22:34,880 --> 00:22:39,500
 árvore de caminho, agora
 o RPF terá sucesso.

371
00:22:39,500 --> 00:22:46,420
 Ele será aprovado se o multicast descer
 pela árvore de caminho mais curto.

372
00:22:46,420 --> 00:22:51,840
 Então, como determinamos a interface
 de entrada correta?

373
00:22:51,840 --> 00:22:56,480
 Como podemos ter certeza de que o RPF foi
 bem-sucedido ou aprovado com base no tipo

374
00:22:56,480 --> 00:22:58,800
 de árvore que estamos esperando?

375
00:22:58,800 --> 00:23:02,460
 Será que estamos esperando que ela desça pela
 árvore central, também conhecida como

376
00:23:02,460 --> 00:23:09,940
 Árvore RP? Ou esperamos que o tráfego
 desça pela árvore de origem?

377
00:23:09,940 --> 00:23:16,400
 Agora, pode depender do
 tipo específico de IGP.

378
00:23:16,400 --> 00:23:18,620
 Do que estou falando aí?

379
00:23:18,620 --> 00:23:21,980
 O PIM não é o único protocolo
 de roteamento multicast.

380
00:23:21,980 --> 00:23:22,800
 Existem outros.

381
00:23:22,800 --> 00:23:27,120
 Por exemplo, MOSPF, OSPF multicast.

382
00:23:27,120 --> 00:23:31,440
 Você provavelmente pode adivinhar se estou
 usando OSPF multicast para descobrir

383
00:23:31,440 --> 00:23:35,140
 descobrir qual é a interface correta para
 ir para o RP, ou a interface correta

384
00:23:35,140 --> 00:23:39,480
 para ir até a origem, ele
 depende de rotas OSPF.

385
00:23:39,480 --> 00:23:44,120
 O MOSPF não pode fazer a verificação
 RPF com base em RIP ou EIGRP.

386
00:23:44,120 --> 00:23:50,500
 Precisa de OSPF. Há outro chamado
 DVMRP, Distance Vector Multicast

387
00:23:50,500 --> 00:23:51,940
 Protocolo de roteamento.

388
00:23:51,940 --> 00:23:53,120
 Esse é meio estranho.

389
00:23:53,120 --> 00:23:59,660
 Na verdade, ele cria sua própria tabela unicast
 separada apenas para fazer verificações de RPF.

390
00:23:59,660 --> 00:24:01,140
 A tabela DVMRP.

391
00:24:01,140 --> 00:24:02,920
 Não usa mais nada.

392
00:24:02,920 --> 00:24:08,720
 O que há de maravilhoso no PIM,
 Protocol Independent Multicast.

393
00:24:08,720 --> 00:24:13,000
 O Protocolo Independente significa
 que o PIM diz, não me importo.

394
00:24:13,000 --> 00:24:16,100
 Quando faço uma verificação RPF,
 irei para a tabela de roteamento.

395
00:24:16,100 --> 00:24:19,960
 Não me importo se consigo encontrar uma
 rota que seja estática, rota conectada,

396
00:24:19,960 --> 00:24:21,540
 EIGRP, RIP, OSPF.

397
00:24:21,540 --> 00:24:27,160
 Eu não ligo. Contanto que eu encontre algo
 para fazer minha verificação de RPF,

398
00:24:27,160 --> 00:24:32,040
 Eu vou ser feliz. É por isso que o PIM é
 tão popular porque permite que você use

399
00:24:32,040 --> 00:24:35,100
 qualquer protocolo de roteamento
 IGP que você desejar.

400
00:24:35,100 --> 00:24:36,860
 Não depende disso.