1
00:00:08,080 --> 00:00:12,180
 Então, neste ponto, terminamos praticamente
 a teoria do PIMS esparso

2
00:00:12,180 --> 00:00:16,320
 modo e antes de passarmos aos conceitos
 de descoberta dinâmica de RPs

3
00:00:16,320 --> 00:00:21,540
 via auto-RP ou roteador de bootstrap
 PIM, só quero finalizar este tópico

4
00:00:21,540 --> 00:00:25,000
 do modo escasso do PIMS
 voltando aos comandos.

5
00:00:25,000 --> 00:00:27,820
 Alguns dos comandos que você já
 viu enquanto falei sobre eles e

6
00:00:27,820 --> 00:00:31,180
 os exibiu no laboratório e alguns dos
 comandos serão novos para você.

7
00:00:31,180 --> 00:00:34,340
 Eu só queria mostrar os mais familiares
 que você provavelmente conhece

8
00:00:34,340 --> 00:00:43,200
 usar. Ok, então verifique se o modo
 escasso do PIMS está funcionando.

9
00:00:43,200 --> 00:00:45,460
 Certamente você pode mostrar
 a interface IP PIM.

10
00:00:45,460 --> 00:00:51,680
 Vou fazer cada um deles à
 medida que avançamos aqui.

11
00:00:51,680 --> 00:01:01,280
 Então mostre a interface IP PIM e como
 você pode ver ela mostra o endereço de

12
00:01:01,280 --> 00:01:06,580
 sua interface. Então, neste caso, 454,
 esse é na verdade o endereço do nosso

13
00:01:06,580 --> 00:01:08,460
 interface de quatro.

14
00:01:08,460 --> 00:01:13,380
 Então, isso confirma basicamente que o
 PIMS está habilitado nessas interfaces

15
00:01:13,380 --> 00:01:14,780
 com esses endereços IP.

16
00:01:14,780 --> 00:01:19,320
 Também mostro qual versão do PIMS,
 seja em esparso ou denso

17
00:01:19,320 --> 00:01:24,160
 modo. Há também um modo chamado esparso
 denso e falaremos sobre isso

18
00:01:24,160 --> 00:01:27,760
 a seguir, quando falarmos
 sobre RP automático.

19
00:01:27,760 --> 00:01:30,520
 Quantos vizinhos você tem, se houver?

20
00:01:30,520 --> 00:01:36,060
 Com que frequência você envia pacotes
 PIM Hello que eles chamam de consultas

21
00:01:36,060 --> 00:01:40,580
 aqui. A prioridade do roteador designado,
 que é um por padrão e

22
00:01:40,580 --> 00:01:42,220
 quem é o roteador designado.

23
00:01:42,220 --> 00:01:45,860
 E algumas interfaces não precisam disso,
 como interfaces ponto a ponto, como

24
00:01:45,860 --> 00:01:50,420
 HDLC e PPP. Não há necessidade de um
 roteador designado nesse tipo de

25
00:01:50,420 --> 00:02:03,940
 uma interface. Mostrar vizinho IP PIM
 fornece um pouco mais de detalhes.

26
00:02:03,940 --> 00:02:07,760
 Ou seja, o que você está ganhando
 com isso são esses temporizadores.

27
00:02:07,760 --> 00:02:09,980
 Há quanto tempo no total sou vizinho?

28
00:02:09,980 --> 00:02:13,620
 Então, com esse vizinho em particular
 já faz quase 22 horas que sou vizinho

29
00:02:13,620 --> 00:02:21,760
 com esse cara. E isso está mostrando que tudo
 bem se eu perder um Olá, se não perder

30
00:02:21,760 --> 00:02:25,560
 continue recebendo PIM Hello's em
 um minuto e 37 segundos, eu irei

31
00:02:25,560 --> 00:02:27,720
 destruir esse bairro.

32
00:02:27,720 --> 00:02:33,800
 Depois também mostramos IP PIM RP.

33
00:02:33,800 --> 00:02:39,460
 Agora, este comando específico
 mostra IP PIM RP.

34
00:02:39,460 --> 00:02:46,220
 Este comando só é realmente útil se
 você configurou estaticamente um RP

35
00:02:46,220 --> 00:02:48,500
 como fiz até agora.

36
00:02:48,500 --> 00:02:53,100
 Basicamente, apenas confirma que você
 realmente configurou estaticamente

37
00:02:53,100 --> 00:02:59,560
 um RP e quais grupos específicos esse
 RP está atendendo no momento.

38
00:02:59,560 --> 00:03:04,020
 Neste caso diz que expira nunca
 porque nunca irá expirar.

39
00:03:04,020 --> 00:03:05,280
 É um RP estático.

40
00:03:05,280 --> 00:03:10,440
 Não há nenhum mecanismo aqui para verificar
 se o RP realmente existe e está

41
00:03:10,440 --> 00:03:16,280
 alcançável. Este próximo comando
 mostra o mapeamento IP PIM RP.

42
00:03:16,280 --> 00:03:19,620
 Na verdade, isso ocorre se você usar
 algum tipo de descoberta dinâmica

43
00:03:19,620 --> 00:03:24,020
 do RP como auto RP ou PIM BSR.

44
00:03:24,020 --> 00:03:26,560
 Este é o comando que você deseja
 usar para verificar se você

45
00:03:26,560 --> 00:03:30,920
 realmente aprendido dinamicamente sobre
 um RP e quais grupos específicos esse

46
00:03:30,920 --> 00:03:32,380
 RP está atendendo.

47
00:03:32,380 --> 00:03:39,120
 Neste caso específico, não
 há muita saída aqui.

48
00:03:39,120 --> 00:03:45,040
 Diz estático quem é o RP e ele
 é o RP de cada grupo, mas

49
00:03:45,040 --> 00:03:48,880
 você obterá muito mais resultados com isso se
 tivéssemos aprendido dinamicamente por meio

50
00:03:48,880 --> 00:03:55,360
 RP automático ou BSR. Veremos isso
 no próximo conjunto de vídeos.

51
00:03:55,360 --> 00:04:00,660
 Ok, existem algumas maneiras de modificar
 o comportamento do PIM.

52
00:04:00,660 --> 00:04:03,540
 IP PIM aceita registro.

53
00:04:03,540 --> 00:04:09,520
 Então, o que isso está falando é que,
 por padrão, o ponto de encontro será

54
00:04:09,520 --> 00:04:12,960
 aceitar qualquer tipo de mensagem de registro
 que venha de qualquer pessoa.

55
00:04:12,960 --> 00:04:16,900
 Não existe uma lista autorizada
 de roteadores autorizados a

56
00:04:16,900 --> 00:04:21,040
 registro. Qualquer roteador pode registrar
 o que certamente poderia introduzir o

57
00:04:21,040 --> 00:04:22,320
 conceito de um roteador não autorizado.

58
00:04:22,320 --> 00:04:25,760
 Talvez alguém coloque um roteador não
 autorizado na rede e intencionalmente

59
00:04:25,760 --> 00:04:32,440
 martela o PIM RP com esse monte de mensagens
 de registro de forma intencional

60
00:04:32,440 --> 00:04:36,240
 tentativa de derrubar o RP.

61
00:04:36,240 --> 00:04:40,220
 Então, neste comando específico aqui você
 poderia dizer bem, apenas RP's, o único,

62
00:04:40,220 --> 00:04:47,420
 sim, apenas roteadores RP conectados a fontes
 que correspondem a esta lista são, na verdade,

63
00:04:47,420 --> 00:04:49,340
 permissão para se registrar comigo.

64
00:04:49,340 --> 00:04:52,980
 Portanto, se um registro vier de qualquer outro roteador,
 você simplesmente descartará silenciosamente

65
00:04:52,980 --> 00:05:01,020
 isto. Limite de taxa de registro IP PIM, portanto, se
 você estiver preocupado até mesmo com o autorizado

66
00:05:01,020 --> 00:05:06,340
 roteadores por aí enviando muitos registros,
 muitas sessões multicast

67
00:05:06,340 --> 00:05:10,420
 estão iniciando ao mesmo tempo, você
 pode limitá-lo usando este comando

68
00:05:10,420 --> 00:05:12,300
 aqui com bits por segundo.

69
00:05:12,300 --> 00:05:16,100
 Fonte de registro IP PIM.

70
00:05:16,100 --> 00:05:19,140
 Agora, este é um comando que você realmente
 executaria em qualquer roteador que esteja

71
00:05:19,140 --> 00:05:22,700
 irá originar a mensagem de registro.

72
00:05:22,700 --> 00:05:27,780
 Agora normalmente um roteador quando
 diz ok, preciso me registrar no RP.

73
00:05:27,780 --> 00:05:30,700
 O que esse roteador fará é entrar em
 sua tabela de roteamento, ele fará

74
00:05:30,700 --> 00:05:34,960
 um RPF procure e ele dirá ok, qual
 é a interface que eu usaria, qual é

75
00:05:34,960 --> 00:05:39,460
 na verdade, a interface de entrada
 que eu usaria para voltar ao RP?

76
00:05:39,460 --> 00:05:43,540
 Ele diz: oh, de acordo com minha tabela de roteamento,
 minha melhor rota para o RP é rápida

77
00:05:43,540 --> 00:05:48,180
 Ethernet 00. Bem, nesse ponto ele extrairia
 aquele endereço IP rapidamente

78
00:05:48,180 --> 00:05:53,920
 Ethernet 00 e use-o como endereço de origem
 para suas mensagens de registro.

79
00:05:53,920 --> 00:05:57,740
 Pode haver alguns cenários em que
 você não quer que ele faça isso.

80
00:05:57,740 --> 00:06:01,700
 Independentemente da interface que ele
 usa para chegar ao RP, talvez você

81
00:06:01,700 --> 00:06:05,400
 sempre quero que ele use seu loop
 back como endereço de origem.

82
00:06:05,400 --> 00:06:12,660
 Bem, este seria o comando que você usaria
 para modificar esse comportamento.

83
00:06:12,660 --> 00:06:16,300
 IP PIM, SPT Threshold, não vou
 falar sobre isso, já abordamos

84
00:06:16,300 --> 00:06:21,480
 isso penso com bastante detalhe
 em alguns dos outros vídeos.

85
00:06:21,480 --> 00:06:27,940
 E IP PIMs esparsos temporizador
 de expiração SG.

86
00:06:27,940 --> 00:06:38,780
 Então, do que isso está falando?

87
00:06:38,780 --> 00:06:43,740
 Não fica lá para sempre, tem que
 ser atualizado, e há alguns

88
00:06:43,740 --> 00:06:45,600
 de coisas que poderiam atualizá-lo.

89
00:06:45,600 --> 00:06:50,260
 Cada vez que chega um pacote multicast
 real que corresponde a esse s-coma

90
00:06:50,260 --> 00:06:53,420
 -g entrada que atualiza o estado.

91
00:06:53,420 --> 00:06:58,600
 Ou se sabemos também sabemos que os roteadores, mesmo
 depois de terem aderido ao caminho mais curto

92
00:06:58,600 --> 00:07:03,940
 árvore de caminhos, se eles ainda quiserem esse
 multicast, eles irão periodicamente uma vez

93
00:07:03,940 --> 00:07:08,900
 um minuto, envie outro s-coma-g join
 para atualizar a árvore, e isso

94
00:07:08,900 --> 00:07:13,920
 também atualizará o estado s-coma-g em
 qualquer roteador que receba esse tipo

95
00:07:13,920 --> 00:07:17,480
 de uma junção. Então, se isso não acontecer,
 se um roteador estiver aqui com

96
00:07:17,480 --> 00:07:21,960
 uma entrada s-coma-g e digamos que o multicast
 pare, bem, por padrão, depois

97
00:07:21,960 --> 00:07:26,180
 um pouco mais de três minutos após 210
 segundos daquela entrada s-coma-g

98
00:07:26,180 --> 00:07:28,940
 desaparecerá, irá embora.

99
00:07:28,940 --> 00:07:33,660
 Bem, talvez você tenha algum cenário
 em que diga, quer saber?

100
00:07:33,660 --> 00:07:39,180
 Depois que os s-coma-g forem criados no
 meu roteador, quero que ele fique lá

101
00:07:39,180 --> 00:07:43,120
 por muito tempo, mesmo que eu
 pare de receber o multicast.

102
00:07:43,120 --> 00:07:46,380
 Eu só não quero ter que ficar recriando
 o s-coma-g indefinidamente

103
00:07:46,380 --> 00:07:49,480
 de novo. Eu realmente não consigo pensar
 de cara por que você gostaria de fazer

104
00:07:49,480 --> 00:07:52,140
 isso, mas este comando realmente
 permitiria que você fizesse isso.

105
00:07:52,140 --> 00:07:54,240
 Então é disso que estamos falando.

106
00:07:54,240 --> 00:08:00,640
 Se você definir este comando para o máximo,
 que é 57.600 segundos, isso é

107
00:08:00,640 --> 00:08:02,620
 igual a 16 horas.

108
00:08:02,620 --> 00:08:06,660
 Então, basicamente, o que isso quer dizer é:
 ok, quando uma entrada s-coma-g for criada,

109
00:08:06,660 --> 00:08:11,440
 mesmo que não esteja atualizado, basta
 mantê-lo lá por até 16 horas antes

110
00:08:11,440 --> 00:08:16,520
 você expira. Então, se você tiver uma
 situação em que isso seria útil

111
00:08:16,520 --> 00:08:19,840
 você, é aí que esse comando ajudaria.

112
00:08:19,840 --> 00:08:25,480
 E então o último comando
 aqui é o modo IPPIM NBMA.

113
00:08:25,480 --> 00:08:27,040
 Então imagine esse cenário.

114
00:08:27,040 --> 00:08:29,680
 Na verdade, deixe-me desenhar
 aqui por um momento.

115
00:08:29,680 --> 00:08:34,220
 Digamos que temos uma WAN.

116
00:08:34,220 --> 00:08:37,560
 Usarei apenas o Frame Relay como exemplo
 porque o Frame Relay é usado como

117
00:08:37,560 --> 00:08:41,500
 lote no CCNA e no CCNP.

118
00:08:41,500 --> 00:08:47,120
 E nesta WAN temos um cenário
 hub and spoke.

119
00:08:47,120 --> 00:08:56,240
 Onde temos o roteador A como hub
 e os roteadores B e C como raios.

120
00:08:56,240 --> 00:09:04,160
 Ok, então a única maneira de B e
 C se comunicarem é via roteador

121
00:09:04,160 --> 00:09:09,320
 R. Na verdade, eles não possuem PVCs
 de frame relay diretamente entre si.

122
00:09:09,320 --> 00:09:12,200
 Bem, sabemos que, como no caso dos protocolos
 de roteamento, se estivéssemos falando

123
00:09:12,200 --> 00:09:17,260
 sobre OSPF ou EIGRP ou algo assim, muitos
 protocolos de roteamento, se roteador

124
00:09:17,260 --> 00:09:22,540
 B, e digamos apenas que no roteador
 A, sua interface serial física

125
00:09:22,540 --> 00:09:25,960
 está fazendo tudo.

126
00:09:25,960 --> 00:09:29,320
 Ok, então nosso endereço IP está aqui.

127
00:09:29,320 --> 00:09:30,840
 Não temos subinterfaces.

128
00:09:30,840 --> 00:09:32,720
 Esta é uma interface multiponto.

129
00:09:32,720 --> 00:09:38,360
 Esta é uma interface multieixos
 sem transmissão.

130
00:09:38,360 --> 00:09:41,300
 Bem, neste cenário específico com protocolos
 de roteamento, muitas vezes

131
00:09:41,300 --> 00:09:43,540
 você teria que desativar o
 horizonte dividido, certo?

132
00:09:43,540 --> 00:09:45,900
 Porque split Horizon é a regra que diz,
 veja, se uma atualização de roteamento

133
00:09:45,900 --> 00:09:50,940
 entra na serial 0-0, para evitar loops
 de roteamento, você não está

134
00:09:50,940 --> 00:09:55,180
 autorizado a dar meia-volta e refletir
 essa rota de volta ao exato

135
00:09:55,180 --> 00:09:57,620
 mesma interface onde ele entrou.

136
00:09:57,620 --> 00:10:00,160
 Então você teria que fazer isso, esse
 horizonte dividido impede isso.

137
00:10:00,160 --> 00:10:02,560
 Então você teria que desligar
 o horizonte dividido.

138
00:10:02,560 --> 00:10:05,560
 Bem, o mesmo tipo de coisa acontece
 aqui com multicasts.

139
00:10:05,560 --> 00:10:12,600
 E para junções e coisas assim,
 se um multicast chegar aqui,

140
00:10:12,600 --> 00:10:18,460
 ou lembre-se, a regra geral do PIMS
 diz que a interface de entrada

141
00:10:18,460 --> 00:10:22,040
 não pode aparecer na lista
 de interfaces de saída.

142
00:10:22,040 --> 00:10:26,040
 Bem, se essa regra fosse verdadeira, então
 quando esta interface, quando o multicast

143
00:10:26,040 --> 00:10:30,240
 veio aqui na série 0-0, não conseguiríamos
 colocar exatamente o mesmo

144
00:10:30,240 --> 00:10:34,220
 interface na lista de interfaces
 de saída e o roteador C não seria

145
00:10:34,220 --> 00:10:35,900
 capaz de obter esse multicast.

146
00:10:35,900 --> 00:10:40,680
 Então, para permitir isso, você gostaria
 de usar este comando aqui

147
00:10:40,680 --> 00:10:44,220
 naquela interface de multiacesso
 e sem transmissão.

148
00:10:44,220 --> 00:10:49,340
 Então, isso é basicamente como desligar
 o horizonte dividido, mas para multicast

149
00:10:49,340 --> 00:10:52,240
 tráfego. É isso que esse comando faz.

150
00:10:52,240 --> 00:10:58,140
 E só quero terminar aqui um
 pouco explicando um pouco

151
00:10:58,140 --> 00:11:01,780
 um pouco mais sobre os sinalizadores que
 você pode ver nas entradas da rota M.

152
00:11:01,780 --> 00:11:05,080
 Já conversamos sobre muitos deles,
 mas alguns deles não abordei.

153
00:11:05,080 --> 00:11:07,960
 Então a bandeira C. Nós
 conversamos sobre isso.

154
00:11:07,960 --> 00:11:11,400
 Se você vir a bandeira C, isso
 significa uma de duas coisas.

155
00:11:11,400 --> 00:11:15,660
 Ou este roteador recebeu realmente
 um relatório de associação IGMP ou

156
00:11:15,660 --> 00:11:20,680
 um relatório de ouvinte MLDP, o que significa
 que está diretamente conectado a um receptor,

157
00:11:20,680 --> 00:11:22,540
 para um laptop, para um PC.

158
00:11:22,540 --> 00:11:28,540
 Ou ele realmente recebeu o pacote
 multicast e percebe a origem

159
00:11:28,540 --> 00:11:31,340
 desse multicast está diretamente
 conectado a esse roteador.

160
00:11:31,340 --> 00:11:34,140
 Portanto, há um receptor conectado
 ou uma fonte conectada.

161
00:11:34,140 --> 00:11:36,920
 Isso é o que C significa.

162
00:11:36,920 --> 00:11:41,460
 A bandeira L ainda não falou sobre isso,
 mas sabe como no meu particular

163
00:11:41,460 --> 00:11:46,320
 laboratório, o que fiz foi pegar um roteador,
 roteador um, e usei esse comando,

164
00:11:46,320 --> 00:11:49,620
 Grupo de junção IGMP nesse roteador.

165
00:11:49,620 --> 00:11:54,440
 E foi assim que transformei aquele roteador
 em um receptor, porque roteadores não

166
00:11:54,440 --> 00:11:56,400
 normalmente enviam relatórios de membros.

167
00:11:56,400 --> 00:11:59,040
 Esse é o trabalho dos laptops e PCs.

168
00:11:59,040 --> 00:12:03,540
 Então, para replicar esse comportamento,
 usei este comando.

169
00:12:03,540 --> 00:12:08,080
 Bem, se esse roteador também estava executando
 o PIM, o que não está, então no

170
00:12:08,080 --> 00:12:12,240
 Entrada M-ROT teria a bandeira L, o que
 significa que também sou um receptor

171
00:12:12,240 --> 00:12:13,160
 deste multicast.

172
00:12:13,160 --> 00:12:15,760
 Quando o multicast chegar, não
 irei apenas encaminhá-lo.

173
00:12:15,760 --> 00:12:18,820
 Na verdade, vou enviá-lo para minha
 CPU para processamento, porque quero

174
00:12:18,820 --> 00:12:23,740
 para ver isso. A bandeira F.

175
00:12:23,740 --> 00:12:27,980
 Portanto, isso é chamado de
 sinalizador de registro PIM.

176
00:12:27,980 --> 00:12:30,580
 Às vezes as pessoas ficam um pouco
 confusas sobre isso, porque veem o

177
00:12:30,580 --> 00:12:35,060
 F, e eles pensam, ah, isso significa
 que o registro está acontecendo certo

178
00:12:35,060 --> 00:12:39,960
 agora. E então eles mostram a rota do IPM, mostram
 a rota do IPM, eles continuam fazendo

179
00:12:39,960 --> 00:12:43,760
 e pelos próximos 30-40 segundos, minuto-5
 minutos, a bandeira F ainda está

180
00:12:43,760 --> 00:12:46,480
 lá. E eles dizem, ah,
 estou com um problema.

181
00:12:46,480 --> 00:12:50,680
 O registro deve acontecer apenas por
 um ou dois segundos e depois deve

182
00:12:50,680 --> 00:12:54,140
 parar. Por que ainda estou
 vendo a bandeira F?

183
00:12:54,140 --> 00:12:59,000
 Bem, se você realmente está
 se registrando agora, quando

184
00:12:59,000 --> 00:13:03,200
 você executa este comando, você realmente
 verá na estrela, entrada G a palavra

185
00:13:03,200 --> 00:13:05,180
 registrando. Isso dirá isso.

186
00:13:05,180 --> 00:13:08,300
 Então você tem a bandeira
 F, e ela diz, registrando.

187
00:13:08,300 --> 00:13:12,400
 Como diz aqui, se você vê apenas a
 bandeira F, mas não vê a palavra

188
00:13:12,400 --> 00:13:17,720
 registrando, isso significa que este roteador
 registrou anteriormente este fluxo.

189
00:13:17,720 --> 00:13:22,000
 É como um marco histórico dizendo:
 Registrei-me com sucesso

190
00:13:22,000 --> 00:13:25,340
 isso no passado, mas não faço mais isso.

191
00:13:25,340 --> 00:13:29,340
 Isso é o que a bandeira F significaria.

192
00:13:29,340 --> 00:13:35,260
 A bandeira J. Isso significa que um roteador
 tentou ingressar no respectivo

193
00:13:35,260 --> 00:13:41,580
 árvore. Então, por exemplo, se você vir o
 sinalizador J na estrela, saída G, você

194
00:13:41,580 --> 00:13:44,760
 posso ficar tentado a pensar, e acho que
 na verdade falei mal sobre isso em

195
00:13:44,760 --> 00:13:45,340
 um vídeo anterior.

196
00:13:45,340 --> 00:13:48,280
 Acho que disse, bem, quando você vê a bandeira
 J, isso significa que este roteador

197
00:13:48,280 --> 00:13:53,160
 enviou um PIM para subir naquela árvore.

198
00:13:53,160 --> 00:13:54,700
 Bem, não necessariamente.

199
00:13:54,700 --> 00:13:59,400
 O que o sinalizador J realmente significa é que
 o roteador deseja ingressar nessa árvore.

200
00:13:59,400 --> 00:14:04,540
 Não é realmente uma prova de que
 uma associação realmente ocorreu.

201
00:14:04,540 --> 00:14:08,840
 Por exemplo, se você vir o sinalizador
 J na estrela, saída G, isso significa,

202
00:14:08,840 --> 00:14:14,620
 ok, o roteador, algo fez com que o
 roteador acreditasse que precisava

203
00:14:14,620 --> 00:14:16,960
 para se juntar à árvore.

204
00:14:16,960 --> 00:14:22,200
 E então ele precisa criar uma estrela, G junte-se
 e envie-a para aquela árvore em direção

205
00:14:22,200 --> 00:14:23,380
 o ponto de encontro.

206
00:14:23,380 --> 00:14:25,760
 Agora, isso realmente teve sucesso?

207
00:14:25,760 --> 00:14:27,460
 Talvez talvez não.

208
00:14:27,460 --> 00:14:31,420
 Nós não sabemos. A bandeira J apenas diz
 que sabia que precisava fazer isso.

209
00:14:31,420 --> 00:14:34,700
 Como em um dos meus laboratórios anteriores
 que eu estava fazendo, se eu voltar ao

210
00:14:34,700 --> 00:14:41,400
 desenhando aqui por um segundo,
 vamos trazer isso aqui.

211
00:14:41,400 --> 00:14:48,020
 Então eu tinha um laboratório, se você se lembra,
 há vários vídeos onde eu tinha esquecido

212
00:14:48,020 --> 00:14:53,080
 para configurar o PIM nesta
 interface aqui mesmo no R4.

213
00:14:53,080 --> 00:14:57,480
 Não houve PIM aqui.

214
00:14:57,480 --> 00:15:01,540
 E ainda assim havia PIM
 nesta interface do R2.

215
00:15:01,540 --> 00:15:06,800
 E o que notei foi que quando o multicast
 começou a fluir, esse cara

216
00:15:06,800 --> 00:15:08,640
 criou um S, G, E e R2.

217
00:15:08,640 --> 00:15:11,720
 E foi a entrada para isso.

218
00:15:11,720 --> 00:15:16,860
 E listou a série 010 como
 interface de entrada.

219
00:15:16,860 --> 00:15:20,080
 Ele disse, ok, se o multicast descer
 pela árvore de caminho mais curto,

220
00:15:20,080 --> 00:15:22,340
 deveria vir em série.

221
00:15:22,340 --> 00:15:25,680
 E tinha a bandeira J.

222
00:15:25,680 --> 00:15:29,840
 E inicialmente pensei, ok, bem, isso significa
 que ele enviou uma inscrição

223
00:15:29,840 --> 00:15:33,380
 lá. Mas se você se lembra daquele vídeo, eu
 disse, hein, está faltando alguma coisa.

224
00:15:33,380 --> 00:15:40,700
 Se o tráfego multicast estiver realmente
 fluindo pelo caminho mais curto

225
00:15:40,700 --> 00:15:45,980
 árvore, além da bandeira J, também
 devo ver a bandeira T.

226
00:15:45,980 --> 00:15:48,820
 E esse é o próximo ponto
 que aparece no slide.

227
00:15:48,820 --> 00:15:54,040
 O sinalizador T indica que recebi
 pelo menos um pacote multicast

228
00:15:54,040 --> 00:15:56,660
 descendo a árvore do caminho mais curto.

229
00:15:56,660 --> 00:15:58,160
 Então está funcionando.

230
00:15:58,160 --> 00:15:58,980
 Mas eu não vi isso.

231
00:15:58,980 --> 00:16:05,280
 No meu caso particular, tudo que
 vi foi a bandeira J e não o T.

232
00:16:05,280 --> 00:16:09,180
 E isso me fez pensar, ok, então ele tentou
 entrar nessa árvore, mas multicast

233
00:16:09,180 --> 00:16:10,300
 ainda não está fluindo.

234
00:16:10,300 --> 00:16:11,200
 O que está acontecendo?

235
00:16:11,200 --> 00:16:15,680
 E foi aí que descobri que o PIM não
 estava configurado no roteador 4.

236
00:16:15,680 --> 00:16:21,400
 Então presumi que o roteador 2 havia
 enviado seu join, mas nada aconteceu

237
00:16:21,400 --> 00:16:24,660
 porque do outro lado o roteador
 não conseguiu processá-lo.

238
00:16:24,660 --> 00:16:26,560
 Mas na verdade fiz um pouco de depuração.

239
00:16:26,560 --> 00:16:31,380
 Acontece que ele percebeu que
 não tinha vizinho do PIM.

240
00:16:31,380 --> 00:16:35,620
 O roteador 2 percebeu que mesmo tendo
 PIM em seu serial, ele não tinha

241
00:16:35,620 --> 00:16:38,960
 soube de um vizinho do
 outro lado da série.

242
00:16:38,960 --> 00:16:42,560
 E então quando fiz um debug, percebi
 que ele nem criou o join

243
00:16:42,560 --> 00:16:45,540
 em primeiro lugar porque ele era inteligente
 o suficiente para perceber, ei, o que há

244
00:16:45,540 --> 00:16:50,140
 o ponto de criar uma junção S-coma
 G enviando este link se houver

245
00:16:50,140 --> 00:16:54,280
 ninguém do outro lado do link
 para recebê-lo e processá-lo?

246
00:16:54,280 --> 00:16:58,820
 É por isso que digo que a bandeira J significa simplesmente
 que ele quer ingressar naquele ramo

247
00:16:58,820 --> 00:17:03,840
 da árvore, mas se ele realmente conseguiu
 ou não enviar uma junção,

248
00:17:03,840 --> 00:17:05,900
 você não pode dizer apenas
 por essa bandeira.

249
00:17:05,900 --> 00:17:10,000
 Você teria que solucionar um pouco
 mais para descobrir isso.

250
00:17:10,000 --> 00:17:15,180
 E então, como eu disse, por último,
 temos a bandeira T, que é isso

251
00:17:15,180 --> 00:17:16,200
 você quer ver, certo?

252
00:17:16,200 --> 00:17:19,240
 Se a bandeira T estiver no caminho
 mais curto três, isso é bom.

253
00:17:19,240 --> 00:17:22,780
 Isso significa que recebi pelo menos
 um pacote de dados multicast em

254
00:17:22,780 --> 00:17:24,220
 o caminho mais curto três.

255
00:17:24,220 --> 00:17:29,560
 Há outra bandeira sobre a qual quero
 falar, que é a bandeira R.

256
00:17:29,560 --> 00:17:31,760
 E este meio que me confundiu um pouco.

257
00:17:31,760 --> 00:17:34,980
 Tive que me aprofundar na RFC e realmente
 pensar um pouco sobre isso.

258
00:17:34,980 --> 00:17:43,600
 Portanto, o sinalizador R é: você verá isso apenas
 em roteadores na árvore compartilhada.

259
00:17:43,600 --> 00:17:48,600
 Então, se você pensar no caminho
 do roteador leaf até o RP, é

260
00:17:48,600 --> 00:17:56,900
 apenas em algum lugar nesse caminho que você
 verá em uma entrada S, G, o sinalizador R.

261
00:17:56,900 --> 00:17:58,340
 Agora, o que isso significa?

262
00:17:58,340 --> 00:18:01,500
 Vamos voltar a isso por um segundo.

263
00:18:01,500 --> 00:18:12,020
 Este. Ok, então sabemos que inicialmente,
 uma vez que o multicast, se soubermos

264
00:18:12,020 --> 00:18:17,100
 que esse cara é o RP aqui,
 opa, o que é isso?

265
00:18:17,100 --> 00:18:24,440
 OK. Assim que o multicast começar
 a fluir do RP para cá, ele irá

266
00:18:24,440 --> 00:18:27,640
 ir por aqui, e então vai
 por aqui, e então vai

267
00:18:27,640 --> 00:18:32,820
 para ir por aqui. Então, no roteador
 oito aqui, estou focando nele para

268
00:18:32,820 --> 00:18:37,260
 o momento. Quando ele realmente obtiver
 esse tráfego multicast, ele irá

269
00:18:37,260 --> 00:18:42,980
 tem tanto a estrela, G, que
 ele criou há muito tempo.

270
00:18:42,980 --> 00:18:45,700
 E então, quando você vir aquele pacote
 multicast, ele criará um S,

271
00:18:45,700 --> 00:18:52,680
 G também. E neste caso específico,
 a lista de interfaces de saída do

272
00:18:52,680 --> 00:18:58,180
 S, G será Fast Ethernet zero barra um.

273
00:18:58,180 --> 00:19:00,240
 Ok, pronto.

274
00:19:00,240 --> 00:19:02,780
 Mas também sabemos que assim que o roteador
 dois, o roteador folha recebe isso

275
00:19:02,780 --> 00:19:07,220
 primeiro pacote multicast, ele tentará
 mudar para o pacote mais curto

276
00:19:07,220 --> 00:19:12,320
 árvore de caminho. E se presumirmos que
 ele teve sucesso e agora está recebendo

277
00:19:12,320 --> 00:19:17,680
 tráfego pelo SPT, então sabemos
 que ele vai mandar uma ameixa

278
00:19:17,680 --> 00:19:23,300
 mensagem. Ele vai enviar o que
 chamamos de ameixa S, G.

279
00:19:23,300 --> 00:19:28,500
 E como será isso?

280
00:19:28,500 --> 00:19:32,600
 Bem, no corpo desse pacote de ameixas
 secas, ele terá a fonte,

281
00:19:32,600 --> 00:19:34,860
 quatro ponto cinco ponto
 quatro ponto cinco.

282
00:19:34,860 --> 00:19:37,960
 Vai ter o grupo, seja ele qual for.

283
00:19:37,960 --> 00:19:41,680
 E então também terá a parte RP.

284
00:19:41,680 --> 00:19:46,160
 Este é um sinalizador, o bit RP definido.

285
00:19:46,160 --> 00:19:49,100
 Isso será definido como um.

286
00:19:49,100 --> 00:19:52,680
 E ele vai enviar isso
 para o roteador oito.

287
00:19:52,680 --> 00:19:57,980
 Quando o roteador oito conseguir isso,
 ele dirá, ok, essa ameixa, porque

288
00:19:57,980 --> 00:20:03,280
 ele tem o bit RP, significa que
 preciso remover essa interface.

289
00:20:03,280 --> 00:20:07,920
 Então ele irá parar de encaminhar
 o multicast nesse link.

290
00:20:07,920 --> 00:20:14,920
 Ele removerá essa interface da
 lista de interfaces de saída.

291
00:20:14,920 --> 00:20:18,940
 E agora isso vai acabar sendo nulo.

292
00:20:18,940 --> 00:20:22,460
 E então ele vai criar seu próprio
 pacote de ameixas e enviá-lo

293
00:20:22,460 --> 00:20:28,760
 maneira, o que acabará eliminando
 isso aqui mesmo.

294
00:20:28,760 --> 00:20:31,800
 Então, o que isso tem a
 ver com a bandeira R?

295
00:20:31,800 --> 00:20:36,800
 Bem, se eu entrar na tabela de rotas M do
 roteador oito depois que isso for feito,

296
00:20:36,800 --> 00:20:44,840
 agora podemos assumir que após este
 momento, lembre-se se um estado S, G

297
00:20:44,840 --> 00:20:48,880
 tem uma lista de interfaces de saída
 que não é nada, está vazia, nula.

298
00:20:48,880 --> 00:20:50,560
 Bem, ele tem uma contagem
 regressiva, certo?

299
00:20:50,560 --> 00:20:52,440
 Só é bom por 210 segundos.

300
00:20:52,440 --> 00:20:57,500
 E depois de 210 segundos, se ninguém
 precisar usar isso, ele vai deletar

301
00:20:57,500 --> 00:21:02,300
 isto. Então, digamos que eu acesse o roteador
 oito antes que esse tempo expire.

302
00:21:02,300 --> 00:21:07,500
 Então, logo depois que ele recebeu a
 ameixa, mas antes dos 210 segundos

303
00:21:07,500 --> 00:21:13,480
 decorrido, então o que verei neste
 estado S, G é a letra R.

304
00:21:13,480 --> 00:21:15,220
 Também verei um P.

305
00:21:15,220 --> 00:21:19,200
 Então ele dirá, na verdade, acho que o
 P pode vir antes do R, mas basicamente

306
00:21:19,200 --> 00:21:22,920
 o P dirá, isso está podado.

307
00:21:22,920 --> 00:21:24,340
 Eu não estou usando isso.

308
00:21:24,340 --> 00:21:25,680
 Eu podei isso.

309
00:21:25,680 --> 00:21:31,360
 E o R dirá, eu podei isso
 porque alguém abaixo do

310
00:21:31,360 --> 00:21:37,640
 eu configurei uma ameixa S, G
 com o bit RP definido como um.

311
00:21:37,640 --> 00:21:40,100
 Agora você não verá isso
 no ponto de encontro.

312
00:21:40,100 --> 00:21:44,320
 Todos vocês verão isso apenas
 em roteadores aqui.

313
00:21:44,320 --> 00:21:47,300
 Assim como o roteador oito, se tivéssemos
 outro roteador aqui, nós o veríamos.

314
00:21:47,300 --> 00:21:49,660
 Se tivéssemos outro roteador
 aqui, nós o veríamos.

315
00:21:49,660 --> 00:21:52,800
 Mas os roteadores intermediários que
 receberam a remoção e encaminharam

316
00:21:52,800 --> 00:21:56,460
 ativado, eles terão uma lista
 de interface de saída nula e

317
00:21:56,460 --> 00:21:59,840
 diga RP e observe que está
 apenas na entrada S, G.

318
00:21:59,840 --> 00:22:04,040
 Você não verá isso na estrela,
 G, apenas o S, G.

319
00:22:04,040 --> 00:22:08,960
 E posso replicar isso facilmente
 aqui, caso você queira

320
00:22:08,960 --> 00:22:11,460
 para ver isso. Eu farei exatamente
 a mesma coisa.

321
00:22:11,460 --> 00:22:17,240
 Vou prosseguir e iniciar o fluxo
 multicast do roteador cinco.

322
00:22:17,240 --> 00:22:20,480
 E quando eu chegar ao roteador oito,
 uns dois segundos depois, ele vai

323
00:22:20,480 --> 00:22:22,440
 já foi podado.

324
00:22:22,440 --> 00:22:30,080
 E você verá que ele realmente
 tem a bandeira R ali.

325
00:22:30,080 --> 00:22:32,780
 Vamos fazer isso.

326
00:22:32,780 --> 00:22:38,560
 Vamos aqui para o roteador cinco.

327
00:22:38,560 --> 00:22:46,680
 Vamos fazer nosso ping.

328
00:22:46,680 --> 00:22:51,220
 Ok, o stream já foi trocado
 e podemos ver isso em

329
00:22:51,220 --> 00:22:55,640
 roteador dois, o roteador
 folha, mostra a rota IPM.

330
00:22:55,640 --> 00:23:02,240
 Podemos ver que ele tem a entrada S, G.

331
00:23:02,240 --> 00:23:05,040
 Ele se juntou ou tentou
 se juntar à árvore.

332
00:23:05,040 --> 00:23:06,180
 Ele teve sucesso?

333
00:23:06,180 --> 00:23:08,480
 Sim, ele teve sucesso porque
 tem a bandeira T.

334
00:23:08,480 --> 00:23:13,360
 Na verdade, ele está recebendo tráfego multicast
 pela árvore de caminho mais curto.

335
00:23:13,360 --> 00:23:16,880
 Agora, se formos para o roteador oito, quem
 está no meio, quem não está mais envolvido

336
00:23:16,880 --> 00:23:23,600
 neste trânsito de qualquer forma, ele
 foi podado, podemos ver em seu S,

337
00:23:23,600 --> 00:23:29,120
 Entrada G, diz P, foi podado e
 por que foi podado por causa de

338
00:23:29,120 --> 00:23:34,100
 R? Porque recebemos uma mensagem removida
 com o bit RP, o que causou

339
00:23:34,100 --> 00:23:37,860
 nossa lista de interfaces
 de saída se tornará não.

340
00:23:37,860 --> 00:23:42,320
 Então isso agora só vai ser bom
 para outro, bem, agora diz

341
00:23:42,320 --> 00:23:43,560
 dois minutos e 28 segundos.

342
00:23:43,560 --> 00:23:46,760
 Se eu fizer isso de novo, veremos
 a contagem regressiva.

343
00:23:46,760 --> 00:23:48,260
 Agora só serve por dois minutos.

344
00:23:48,260 --> 00:23:53,760
 Então, daqui a dois minutos, esta entrada
 irá desaparecer, e então esta entrada irá

345
00:23:53,760 --> 00:23:56,900
 também desaparecerão porque nenhum deles
 será necessário naquele momento