1
00:00:07,980 --> 00:00:12,560
 No último vídeo, vimos detalhadamente
 como é o processo

2
00:00:12,560 --> 00:00:16,460
 é usado quando estamos criando a árvore
 compartilhada, como a adesão ao IGMPM

3
00:00:16,460 --> 00:00:21,780
 relatório recebido pelo gateway padrão inicia
 um PIM, o que chamamos de estrela,

4
00:00:21,780 --> 00:00:27,420
 G-join, que sobe salto a salto
 até o ponto de encontro.

5
00:00:27,420 --> 00:00:31,940
 E vimos como isso acontece, cada
 roteador do roteador, o padrão

6
00:00:31,940 --> 00:00:35,260
 gateway que recebeu o relatório de associação
 e, em seguida, cada roteador junto

7
00:00:35,260 --> 00:00:39,740
 o caminho que recebe a estrela,
 G-join até o ponto de encontro,

8
00:00:39,740 --> 00:00:44,440
 que criou o que chamamos de estado de rota
 estrela, G-em em nosso roteamento multicast

9
00:00:44,440 --> 00:00:55,380
 mesa. Assim que tivermos aquela estrela,
 estado de rota G-em, ou seja, eu não

10
00:00:55,380 --> 00:00:59,080
 importa qual é a fonte, uma vez que começa
 a atingir o ponto de encontro,

11
00:00:59,080 --> 00:01:03,420
 temos uma conexão aberta, um caminho
 aberto, até o receptor.

12
00:01:03,420 --> 00:01:06,820
 E isso é baseado no que foi mostrado
 na lista de interfaces de saída.

13
00:01:06,820 --> 00:01:13,180
 Ok, agora vamos iniciar o multicast
 e ver o que acontece lá.

14
00:01:13,180 --> 00:01:19,800
 Portanto, a linha tracejada verde neste caso
 específico indica a árvore compartilhada

15
00:01:19,800 --> 00:01:21,140
 isso já está aberto.

16
00:01:21,140 --> 00:01:26,180
 Agora não estou mostrando o R8 aqui, mas
 sabemos que o R8 está entre esses dois.

17
00:01:26,180 --> 00:01:30,160
 Agora a fonte vai começar.

18
00:01:30,160 --> 00:01:34,700
 E o que veremos é quando o R4 receber
 esses multicast nativos

19
00:01:34,700 --> 00:01:39,840
 pacotes da fonte, ele dirá, hein,
 estou com um problema aqui.

20
00:01:39,840 --> 00:01:46,820
 Porque só tenho permissão para encaminhar
 esses pacotes multicast nativos se

21
00:01:46,820 --> 00:01:51,820
 Eu tenho alguma entrada na minha tabela de
 rotas M que possui uma interface na saída

22
00:01:51,820 --> 00:01:56,960
 lista de interfaces. Mas ele vai dizer,
 ninguém nunca me pediu isso.

23
00:01:56,960 --> 00:02:00,140
 Nunca recebi nenhum relatório
 de adesão ao IGMP.

24
00:02:00,140 --> 00:02:03,060
 Nunca recebi nenhuma associação
 de PIM de ninguém.

25
00:02:03,060 --> 00:02:05,820
 Então não tenho para onde enviar isso.

26
00:02:05,820 --> 00:02:08,140
 E ainda assim pode haver
 receptores por aí.

27
00:02:08,140 --> 00:02:09,600
 Então o que eu faço?

28
00:02:09,600 --> 00:02:12,940
 Bem, com o modo PIM esparso,
 o que ele vai fazer é pegar

29
00:02:12,940 --> 00:02:19,280
 esse pacote multicast e ele irá encapsulá-lo
 dentro de um unicast.

30
00:02:19,280 --> 00:02:22,520
 E isso estará dentro de um pacote PIM.

31
00:02:22,520 --> 00:02:27,300
 Portanto, haverá outro tipo de pacote
 PIM chamado registro PIM.

32
00:02:27,300 --> 00:02:29,120
 E é isso que veremos a seguir.

33
00:02:29,120 --> 00:02:31,640
 Portanto, o registro PIM
 realmente carrega.

34
00:02:31,640 --> 00:02:36,600
 É um pacote unicast, transmita-o
 do R4 diretamente para o RP.

35
00:02:36,600 --> 00:02:39,200
 Então veremos os endereços de origem R4.

36
00:02:39,200 --> 00:02:42,240
 O endereço de destino
 é o ponto de encontro.

37
00:02:42,240 --> 00:02:45,920
 O tipo PIM será um novo tipo
 chamado registrador.

38
00:02:45,920 --> 00:02:51,240
 E no corpo disso estarão
 nossos dados multicast.

39
00:02:51,240 --> 00:02:55,840
 E quando o ponto de encontro chegar a esse
 ponto, ele irá descapsulá-lo, revelando

40
00:02:55,840 --> 00:02:57,780
 o pacote multicast.

41
00:02:57,780 --> 00:03:01,840
 E aí o RP vai dizer, ok,
 tenho estado para isso?

42
00:03:01,840 --> 00:03:04,020
 Alguém já me pediu isso?

43
00:03:04,020 --> 00:03:07,200
 Bem, neste caso você dirá que sim, porque
 nossa árvore compartilhada já está

44
00:03:07,200 --> 00:03:08,740
 pronto e esperando.

45
00:03:08,740 --> 00:03:11,460
 Então ele encaminhará isso para
 a árvore compartilhada.

46
00:03:11,460 --> 00:03:15,220
 Então é assim que nosso multicast começará
 inicialmente registrando este

47
00:03:15,220 --> 00:03:26,920
 caminho. Então agora isso pode continuar
 potencialmente indefinidamente.

48
00:03:26,920 --> 00:03:28,600
 Certo? Quer dizer, funciona.

49
00:03:28,600 --> 00:03:31,640
 Ele obtém o multicast da
 fonte para o receptor.

50
00:03:31,640 --> 00:03:38,240
 Mas está pedindo para aquele roteador
 conectado na fonte e no RP funcionar

51
00:03:38,240 --> 00:03:42,940
 um pouco mais difícil de embrulhar essa
 coisa em um unicast e desembrulhá-la

52
00:03:42,940 --> 00:03:45,360
 do unicast do outro lado.

53
00:03:45,360 --> 00:03:50,440
 Portanto, embora funcione, está consumindo
 um pouco mais de recursos da CPU.

54
00:03:50,440 --> 00:03:54,040
 E certamente se tivéssemos dezenas ou
 centenas de fluxos multicast fazendo

55
00:03:54,040 --> 00:04:05,320
 isso pode ser potencialmente ruim para
 o RP que está dentro do multicast.

56
00:04:05,320 --> 00:04:08,500
 Então o que vai acontecer?

57
00:04:08,500 --> 00:04:13,940
 E veremos isso no próximo segmento com
 mais detalhes, é quando o encontro

58
00:04:13,940 --> 00:04:18,400
 ponto recebe este pacote de registro de
 pin, ele realmente vai fazer alguns

59
00:04:18,400 --> 00:04:20,260
 das coisas simultaneamente.

60
00:04:20,260 --> 00:04:23,640
 Primeiro, ele vai desembrulhar e encaminhar
 para a árvore compartilhada.

61
00:04:23,640 --> 00:04:25,320
 Já conversamos sobre isso.

62
00:04:25,320 --> 00:04:36,140
 O próximo ponto de encontro é esse
 multicast em sua forma nativa pura.

63
00:04:36,140 --> 00:04:38,600
 Então posso encaminhá-lo de
 acordo com minha rota m.

64
00:04:38,600 --> 00:04:41,700
 Portanto, não preciso continuar
 incomodando minha CPU com isso.

65
00:04:41,700 --> 00:04:43,000
 Veja, como faço isso?

66
00:04:43,000 --> 00:04:46,540
 Bem, eu sei que meu vizinho upstream
 só vai encaminhá-lo para

67
00:04:46,540 --> 00:04:48,980
 mim se eu pedir isso a ele.

68
00:04:48,980 --> 00:04:53,160
 Portanto, o RP enviará uma mensagem
 de adesão ao seu vizinho.

69
00:04:53,160 --> 00:04:57,560
 Mas esta não é uma comédia estrelada
 porque ele realmente conhece a fonte.

70
00:04:57,560 --> 00:05:01,040
 Quando esse primeiro multicast chega,
 ele diz, ah, eu sei quem é a fonte

71
00:05:01,040 --> 00:05:07,240
 é, 4.5.4.5. Então ele vai enviar
 o que é chamado de junção S, G.

72
00:05:07,240 --> 00:05:11,280
 Quando vemos no traço do atirador, é exatamente
 o mesmo formato de uma estrela

73
00:05:11,280 --> 00:05:15,600
 -comedy join, exceto que lista
 o endereço de origem e alguns

74
00:05:15,600 --> 00:05:17,800
 das bandeiras também são diferentes.

75
00:05:17,800 --> 00:05:24,440
 E isso abre a árvore do caminho mais
 curto do ponto de encontro até

76
00:05:24,440 --> 00:05:29,120
 a fonte. Porque lembre-se, falamos
 sobre como há potencialmente

77
00:05:29,120 --> 00:05:32,080
 várias árvores compartilhadas, certo?

78
00:05:32,080 --> 00:05:35,240
 Se eu sou um ponto de encontro e há
 50 receptores diferentes espalhados

79
00:05:35,240 --> 00:05:38,940
 através da rede, pode haver 50 árvores
 compartilhadas diferentes.

80
00:05:38,940 --> 00:05:44,020
 Bem, da mesma forma, o conceito de árvore
 de caminho mais curto vem de um indivíduo

81
00:05:44,020 --> 00:05:45,880
 perspectiva do roteador.

82
00:05:45,880 --> 00:05:49,700
 Meu caminho mais curto para chegar a essa
 fonte é um roteador que pode ser diferente

83
00:05:49,700 --> 00:05:54,700
 do que o seu caminho mais curto
 para chegar à mesma fonte.

84
00:05:54,700 --> 00:05:57,360
 Então, no ponto de encontro, quando ele
 receber esse pacote de registro, ele irá

85
00:05:57,360 --> 00:06:02,820
 para dizer, quero abrir meu caminho
 mais curto para chegar a essa fonte.

86
00:06:02,820 --> 00:06:06,140
 Porque uma vez aberto, esses
 registros irão parar.

87
00:06:06,140 --> 00:06:09,900
 Começarei a obter o multicast
 puro em sua forma nativa.

88
00:06:09,900 --> 00:06:15,180
 Então assim que o cadastro chegar,
 além de encaminhar para baixo

89
00:06:15,180 --> 00:06:23,900
 assim, esse RP vai mandar, deixa
 eu expandir um pouco, ele vai

90
00:06:23,900 --> 00:06:34,200
 vou enviar um s, G junte-se ao upstream.

91
00:06:34,200 --> 00:06:39,960
 E isso irá, em R4, adicionar um sinal
 eletrônico rápido em zero, zero em seu

92
00:06:39,960 --> 00:06:42,320
 lista de interfaces de saída.

93
00:06:42,320 --> 00:06:45,600
 Agora nossos quatro dirão: Ah, ótimo.

94
00:06:45,600 --> 00:06:50,200
 Ok, agora posso começar a encaminhar o
 downstream multicast em sua forma pura

95
00:06:50,200 --> 00:06:55,180
 forma nativa. Mas adivinhe,
 ele continuará registrando.

96
00:06:55,180 --> 00:06:59,540
 Então agora vamos obter duas cópias
 desses pacotes multicast no

97
00:06:59,540 --> 00:07:03,400
 PR. Vamos fazer com que o multicast
 nativo seja desativado.

98
00:07:03,400 --> 00:07:08,560
 E vamos obter outra cópia dentro deste
 pacote de registro de pinos.

99
00:07:08,560 --> 00:07:14,380
 Agora você pode perguntar:
 por que isso aconteceu?

100
00:07:14,380 --> 00:07:18,360
 Por que um R4 simplesmente
 para nesse ponto?

101
00:07:18,360 --> 00:07:20,600
 Bem, aqui está o porquê.

102
00:07:20,600 --> 00:07:24,600
 Nesta topologia específica, ela
 não a descreve muito bem.

103
00:07:24,600 --> 00:07:40,480
 Mas imagine se eu tivesse isso.

104
00:07:40,480 --> 00:07:44,140
 Ok, então imagine se, você sabe,
 aqui está minha fonte.

105
00:07:44,140 --> 00:08:00,640
 Ok, e temos o roteador X e o PIM RP.

106
00:08:00,640 --> 00:08:02,740
 E este é o roteador cinco.

107
00:08:02,740 --> 00:08:08,800
 Ok, então aqui minha fonte está enviando
 seu multicast para o roteador cinco.

108
00:08:08,800 --> 00:08:13,700
 O roteador cinco pega esse
 multicast e o registra.

109
00:08:13,700 --> 00:08:20,020
 Veja se consigo desenhar algo
 aqui para indicar isso.

110
00:08:20,020 --> 00:08:23,060
 Então esse é o registro.

111
00:08:23,060 --> 00:08:34,020
 E agora o roteador cinco
 recebe uma junção s, g.

112
00:08:34,020 --> 00:08:38,940
 Então a fonte é, vamos ver aqui,
 qual é a fonte do cara?

113
00:08:38,940 --> 00:08:41,740
 4.5.4.5 no meu exemplo específico.

114
00:08:41,740 --> 00:08:45,280
 Então ele diz, ok, aqui
 está uma junção do PIM.

115
00:08:45,280 --> 00:08:51,320
 E na verdade listará a fonte e o grupo.

116
00:08:51,320 --> 00:09:06,140
 Ok, bem, quando isso acontecer, se houvesse,
 como posso expressar isso?

117
00:09:06,140 --> 00:09:08,960
 Na verdade, aqui está um exemplo melhor.

118
00:09:08,960 --> 00:09:16,180
 Coloque um roteador bem aqui no meio.

119
00:09:16,180 --> 00:09:21,680
 Ok, então todas essas mensagens
 PIM têm um tempo de vida.

120
00:09:21,680 --> 00:09:26,020
 Certo, vimos como a junção estrela vírgula
 g do PIM saiu para o mesmo multicast

121
00:09:26,020 --> 00:09:30,200
 endereço como olá, 2240013.

122
00:09:30,200 --> 00:09:33,360
 Bem, eu realmente não apontei isso no rastreamento
 do farejador, mas assim como o

123
00:09:33,360 --> 00:09:44,720
 PIM olá tem hora de viver de um só, PIM
 entra e vamos dizer o endereço dele

124
00:09:44,720 --> 00:09:55,220
 é 55555. Quando a junção do PIM está acontecendo
 aqui, no cabeçalho IP real,

125
00:09:55,220 --> 00:10:01,160
 a fonte virá daquele cara.

126
00:10:01,160 --> 00:10:06,060
 E o destino vai ser assim.

127
00:10:06,060 --> 00:10:09,120
 Bem, na verdade será o roteador.

128
00:10:09,120 --> 00:10:11,820
 Esse cara aqui, 4.5.4.4.

129
00:10:11,820 --> 00:10:18,040
 Digamos apenas isso, digamos que ele
 é o roteador 4 para simplificar.

130
00:10:18,040 --> 00:10:24,100
 Portanto, não há necessariamente nenhuma maneira
 de o roteador 4 saber que esta junção

131
00:10:24,100 --> 00:10:28,800
 na verdade, originou-se no
 RP porque é salto a salto.

132
00:10:28,800 --> 00:10:43,360
 Quando o RP o enviou pela primeira vez, o RP o enviou
 para o roteador Z porque ele é uma vírgula

133
00:10:43,360 --> 00:10:48,720
 g join tinha as mesmas informações.

134
00:10:48,720 --> 00:10:51,700
 A fonte foi 4.5.4.5.

135
00:10:51,700 --> 00:10:56,500
 O grupo era 239.999.

136
00:10:56,500 --> 00:11:04,380
 E o pacote aqui tinha um IP
 origem do RP e o destino do

137
00:11:04,380 --> 00:11:12,800
 roteador 4. Vamos colocar isso aqui.

138
00:11:12,800 --> 00:11:18,440
 Na verdade não, ele tinha como destino
 o roteador Z porque é salto a salto.

139
00:11:18,440 --> 00:11:22,540
 É apenas um salto.

140
00:11:22,540 --> 00:11:27,040
 A origem do IP é RP.

141
00:11:27,040 --> 00:11:32,480
 O destino é igual ao roteador Z.

142
00:11:32,480 --> 00:11:36,820
 Então ele enviou esta vírgula g join porque
 o RP disse, ok, eu sei quem é o

143
00:11:36,820 --> 00:11:44,580
 fonte é. Meu próximo vizinho
 principal é o roteador Z.

144
00:11:44,580 --> 00:11:49,440
 Então, vou enviar um PIM vírgula g join
 para aquele vizinho dizendo: ei

145
00:11:49,440 --> 00:11:52,140
 vizinho, você pode abrir
 esse caminho para mim?

146
00:11:52,140 --> 00:11:55,660
 Então, quando o roteador Z consegue,
 ele faz a mesma coisa.

147
00:11:55,660 --> 00:11:59,660
 Ele diz, meu caminho certo para
 a fonte é o roteador 4.

148
00:11:59,660 --> 00:12:04,360
 Então, vou criar uma junção de vírgula
 do PIM e enviá-la para o roteador 4.

149
00:12:04,360 --> 00:12:07,520
 Então isso se abre à medida que
 avançamos no caminho até aqui.

150
00:12:07,520 --> 00:12:11,120
 Esta interface é aberta na lista
 de interfaces de saída.

151
00:12:11,120 --> 00:12:14,460
 Esta interface é aberta na lista
 de interfaces de saída.

152
00:12:14,460 --> 00:12:19,600
 Mas quando o roteador 4 recebe isso, ele não
 tem ideia do motivo pelo qual está recebendo

153
00:12:19,600 --> 00:12:23,600
 é porque o RP iniciou o processo.

154
00:12:23,600 --> 00:12:27,120
 Tudo o que ele sabe é que tem uma junção
 de vírgula para o roteador Z.

155
00:12:27,120 --> 00:12:32,080
 Ele não tem ideia de por que o roteador
 Z enviou isso para ele.

156
00:12:32,080 --> 00:12:36,360
 Só esse roteador Z conseguiu,
 aquele roteador Z iniciou.

157
00:12:36,360 --> 00:12:41,400
 Então ele diz, bem, o roteador Z me enviou
 esta junção de vírgula, mas estou no

158
00:12:41,400 --> 00:12:43,120
 processo de registro.

159
00:12:43,120 --> 00:12:44,780
 Os dois são totalmente diferentes.

160
00:12:44,780 --> 00:12:48,700
 Só porque um cara me enviou uma inscrição não
 significa que devo interromper o registro

161
00:12:48,700 --> 00:12:51,300
 processo com outro cara.

162
00:12:51,300 --> 00:12:54,380
 Ainda vou continuar me registrando
 porque não tive notícias do

163
00:12:54,380 --> 00:13:05,700
 PR ainda. Tudo o que ouvi é do roteador
 Z, o RP receberia duas cópias do

164
00:13:05,700 --> 00:13:06,900
 o mesmo pacote.

165
00:13:06,900 --> 00:13:09,880
 Quando o pacote multicast começa
 a fluir, ele fluirá nativamente

166
00:13:09,880 --> 00:13:15,240
 de 4 a Z para RP porque esse
 caminho já foi aberto.

167
00:13:15,240 --> 00:13:19,240
 E ao mesmo tempo, quando o roteador 4 recebeu
 aquele pacote multicast, ele criou

168
00:13:19,240 --> 00:13:25,240
 uma cópia dele e encapsulado em
 unicast e unicast diretamente

169
00:13:25,240 --> 00:13:31,700
 para o PR. Então agora o RP
 diz, ok, ótimas notícias.

170
00:13:31,700 --> 00:13:37,400
 Acabei de receber o pacote multicast
 real em sua forma nativa pura no meu

171
00:13:37,400 --> 00:13:38,840
 árvore de caminho mais curto.

172
00:13:38,840 --> 00:13:42,160
 Agora sei que meu caminho mais
 curto para a fonte está aberto.

173
00:13:42,160 --> 00:13:44,340
 Está fluindo. Está funcionando.

174
00:13:44,340 --> 00:13:47,240
 Ele diz, não preciso mais dessas
 mensagens de registro.

175
00:13:47,240 --> 00:13:50,380
 Isso está me fazendo trabalhar
 mais do que preciso.

176
00:13:50,380 --> 00:14:00,520
 Portanto, o RP enviará o que é chamado
 de mensagem de parada do registro PIM

177
00:14:00,520 --> 00:14:05,060
 para o roteador 4. É isso que
 o roteador 4 está procurando.

178
00:14:05,060 --> 00:14:09,820
 Isso fará com que ele realmente interrompa
 o processo de registro.

179
00:14:09,820 --> 00:14:14,320
 Então eu sei que neste diagrama
 não ficou totalmente claro.

180
00:14:14,320 --> 00:14:22,400
 Você pode ter dito, ok, bem, quando
 o aplicativo vai parar o registro,

181
00:14:22,400 --> 00:14:23,860
 Eu quero te mostrar não.

182
00:14:23,860 --> 00:14:28,920
 Isso não é. O registro continuará
 até que o RP diga explicitamente:

183
00:14:28,920 --> 00:14:32,900
 por favor pare. Não quero
 mais ver esses registros.

184
00:14:32,900 --> 00:14:40,100
 Então ele usa uma mensagem de parada
 de registro para fazer a troca.

185
00:14:40,100 --> 00:14:44,780
 Na verdade, ele não o usa para mudar
 para a árvore do caminho mais curto.

186
00:14:44,780 --> 00:14:50,500
 Ele faz isso depois que sua árvore de
 caminho mais curto já estiver aberta.

187
00:14:50,500 --> 00:15:05,720
 Então, na verdade, estou
 disposto a mudar isso.

188
00:15:05,720 --> 00:15:10,380
 Lá, o RP usa mensagens de parada de registro
 após sua árvore de caminho mais curto

189
00:15:10,380 --> 00:15:17,480
 está confirmado e aberto.

190
00:15:17,480 --> 00:15:20,320
 Então esse é o processo
 de registro do PIM.

191
00:15:20,320 --> 00:15:26,420
 Então, vamos dar uma olhada
 nisso e ver como funciona.

192
00:15:26,420 --> 00:15:32,340
 Acho que agora nossa árvore
 compartilhada está aberta.

193
00:15:32,340 --> 00:15:35,280
 Vamos apenas confirmar, vamos ao roteador
 3 para RP e ter certeza de que ele ainda

194
00:15:35,280 --> 00:15:46,720
 tem uma estrela, entrada.

195
00:15:46,720 --> 00:15:48,680
 Ah, tudo bem, ele não quer.

196
00:15:48,680 --> 00:15:53,640
 Voltemos à nossa fonte,
 nosso receptor aqui.

197
00:15:53,640 --> 00:16:11,540
 Ok, é por isso, porque ele
 não se juntou ao grupo.

198
00:16:11,540 --> 00:16:14,500
 Ok, então agora devemos pegá-lo.

199
00:16:14,500 --> 00:16:23,440
 Ok, então aí está a nossa
 estrela, entrada.

200
00:16:23,440 --> 00:16:27,680
 E também, no que diz respeito a estes temporizadores,
 este temporizador aqui é como

201
00:16:27,680 --> 00:16:28,900
 a vida útil disso.

202
00:16:28,900 --> 00:16:30,620
 Isso continuará em contagem regressiva.

203
00:16:30,620 --> 00:16:35,240
 E se isso chegar a zero, isso
 significa que vou remover isso

204
00:16:35,240 --> 00:16:38,580
 interface da lista de
 interfaces de saída.

205
00:16:38,580 --> 00:16:43,640
 Mas sabemos que enquanto esse receptor
 ainda estiver ativo, enquanto

206
00:16:43,640 --> 00:16:48,120
 ainda há consultas sendo enviadas e relatórios
 retornando, roteador 2 a cada

207
00:16:48,120 --> 00:16:54,420
 60 segundos, enviaremos outra estrela, junte-se
 aqui para atualizar esse estado.

208
00:16:54,420 --> 00:16:59,720
 E o roteador 8 também ficará parado quando conseguir
 isso, enviaremos sua própria estrela,

209
00:16:59,720 --> 00:17:02,780
 join para atualizar esse estado.

210
00:17:02,780 --> 00:17:12,280
 Por exemplo, agora estamos em 233.

211
00:17:12,280 --> 00:17:14,080
 E está de volta.

212
00:17:14,080 --> 00:17:19,580
 Veja, então começamos em três
 minutos e 23 segundos.

213
00:17:19,580 --> 00:17:24,520
 E descemos por cerca de um minuto.

214
00:17:24,520 --> 00:17:27,980
 E aí a gente não viu, mas no fundo
 ele recebeu uma estrela,

215
00:17:27,980 --> 00:17:31,500
 quanto ele se juntou a uma atualização,
 e voltou a isso.

216
00:17:31,500 --> 00:17:38,740
 Este aqui, este temporizador, é quanto
 tempo esta interface no total esteve em

217
00:17:38,740 --> 00:17:40,220
 a lista de interfaces de saída.

218
00:17:40,220 --> 00:17:44,100
 Já se passaram um minuto e quatro segundos
 desde que recebemos nosso primeiro

219
00:17:44,100 --> 00:17:51,160
 primeira estrela, join que fez com que esta
 entrada m-route fosse criada originalmente.

220
00:17:51,160 --> 00:17:53,940
 Então desta vez vamos
 continuar aumentando.