1
00:00:07,980 --> 00:00:12,560
 Dans la dernière vidéo, nous avons
 examiné en détail le processus.

2
00:00:12,560 --> 00:00:16,460
 est utilisé lors de la création de l'arbre
 partagé, comment l'appartenance à l'IGMPM

3
00:00:16,460 --> 00:00:21,780
 Le rapport reçu par la passerelle par défaut déclenche
 un PIM, ce que nous appelons une étoile,

4
00:00:21,780 --> 00:00:27,420
 G-join, qui remonte saut par saut
 jusqu'au point de rendez-vous.

5
00:00:27,420 --> 00:00:31,940
 Et nous avons vu comment, lorsque cela se produit, chaque routeur,
 par défaut, à partir du routeur, le routeur par défaut

6
00:00:31,940 --> 00:00:35,260
 passerelle qui a reçu le rapport d'appartenance,
 puis chaque routeur le long

7
00:00:35,260 --> 00:00:39,740
 le chemin qui reçoit l'étoile, G-join
 jusqu'au point de rendez-vous,

8
00:00:39,740 --> 00:00:44,440
 Cela a créé ce que nous appelions un état de routage
 en étoile, G-em, dans notre routage multicast.

9
00:00:44,440 --> 00:00:55,380
 tableau. Donc, une fois que nous avons cet état
 de route étoile-G-em, qui est, je ne sais pas

10
00:00:55,380 --> 00:00:59,080
 Peu importe la source, une fois qu'elle
 atteint ce point de rendez-vous,

11
00:00:59,080 --> 00:01:03,420
 Nous avons une connexion ouverte, un
 chemin ouvert, jusqu'au récepteur.

12
00:01:03,420 --> 00:01:06,820
 Et cela se base sur ce qui figurait dans
 la liste des interfaces sortantes.

13
00:01:06,820 --> 00:01:13,180
 Très bien, alors lançons la diffusion
 multicast et voyons ce qui se passe.

14
00:01:13,180 --> 00:01:19,800
 Dans ce cas précis, la ligne pointillée
 verte indique l'arbre partagé.

15
00:01:19,800 --> 00:01:21,140
 c'est déjà ouvert.

16
00:01:21,140 --> 00:01:26,180
 Je ne montre pas R8 ici, mais nous savons
 que R8 se situe entre ces deux-là.

17
00:01:26,180 --> 00:01:30,160
 La source va maintenant démarrer.

18
00:01:30,160 --> 00:01:34,700
 Et ce que nous allons voir, c'est lorsque
 R4 recevra ces flux multicast natifs.

19
00:01:34,700 --> 00:01:39,840
 Il va se dire, en voyant les paquets provenant
 de la source : « Tiens, j’ai un problème. »

20
00:01:39,840 --> 00:01:46,820
 Parce que je ne suis autorisé à transférer
 ces paquets multicast natifs que si

21
00:01:46,820 --> 00:01:51,820
 J'ai une entrée dans ma table de routage
 M qui possède une interface en sortie.

22
00:01:51,820 --> 00:01:56,960
 Liste des interfaces. Mais il va répondre :
 « Personne ne me l’a jamais demandé. »

23
00:01:56,960 --> 00:02:00,140
 Je n'ai jamais reçu de rapports
 d'adhésion à l'IGMP.

24
00:02:00,140 --> 00:02:03,060
 Je n'ai jamais reçu d'invitations
 PIM de qui que ce soit.

25
00:02:03,060 --> 00:02:05,820
 Je n'ai donc nulle part où envoyer ça.

26
00:02:05,820 --> 00:02:08,140
 Et pourtant, il pourrait
 y avoir des récepteurs.

27
00:02:08,140 --> 00:02:09,600
 Alors, que dois-je faire ?

28
00:02:09,600 --> 00:02:12,940
 Eh bien, avec le mode épuré de PIM,
 ce qu'il va faire, c'est prendre

29
00:02:12,940 --> 00:02:19,280
 ce paquet multicast et il va l'encapsuler
 dans un paquet unicast.

30
00:02:19,280 --> 00:02:22,520
 Et ceci sera inclus dans un paquet PIM.

31
00:02:22,520 --> 00:02:27,300
 Il y aura donc un autre type de
 paquet PIM appelé registre PIM.

32
00:02:27,300 --> 00:02:29,120
 Et c'est ce que nous allons
 examiner ensuite.

33
00:02:29,120 --> 00:02:31,640
 Le registre PIM contient donc
 effectivement des données.

34
00:02:31,640 --> 00:02:36,600
 Il s'agit d'un paquet unicast, envoyez-le
 directement de R4 au RP.

35
00:02:36,600 --> 00:02:39,200
 Nous allons donc voir les
 adresses sources R4.

36
00:02:39,200 --> 00:02:42,240
 L'adresse de destination est
 le point de rendez-vous.

37
00:02:42,240 --> 00:02:45,920
 Le type PIM sera un nouveau
 type appelé registre.

38
00:02:45,920 --> 00:02:51,240
 Et c'est dans ce corps de données que
 se trouveront nos données multicast.

39
00:02:51,240 --> 00:02:55,840
 Et lorsque le point de rendez-vous aura atteint
 ce point, il le désencapsulera, révélant

40
00:02:55,840 --> 00:02:57,780
 le paquet multicast.

41
00:02:57,780 --> 00:03:01,840
 Et ensuite, le RP dira : « D'accord, ai-je le pouvoir
 de décision au niveau de l'État pour cela ? »

42
00:03:01,840 --> 00:03:04,020
 Est-ce que quelqu'un m'a déjà
 posé cette question ?

43
00:03:04,020 --> 00:03:07,200
 Eh bien, dans ce cas, vous direz oui,
 car notre arbre partagé est déjà

44
00:03:07,200 --> 00:03:08,740
 Prêt et en attente.

45
00:03:08,740 --> 00:03:11,460
 Il transmettra donc cela dans
 l'arbre généalogique partagé.

46
00:03:11,460 --> 00:03:15,220
 Voilà comment notre multidiffusion démarrera
 initialement en s'enregistrant ici.

47
00:03:15,220 --> 00:03:26,920
 Ainsi, cela pourrait potentiellement
 continuer indéfiniment.

48
00:03:26,920 --> 00:03:28,600
 N'est-ce pas ? Je veux
 dire, ça fonctionne.

49
00:03:28,600 --> 00:03:31,640
 Il reçoit le flux multicast de
 la source vers le récepteur.

50
00:03:31,640 --> 00:03:38,240
 Mais il demande au routeur connecté
 à la source et au RP de fonctionner.

51
00:03:38,240 --> 00:03:42,940
 un peu plus difficile à enrouler
 en monobloc et à dérouler

52
00:03:42,940 --> 00:03:45,360
 de l'unicast à l'autre extrémité.

53
00:03:45,360 --> 00:03:50,440
 Donc, même si cela fonctionne, cela consomme
 un peu plus de ressources du processeur.

54
00:03:50,440 --> 00:03:54,040
 Et certainement si nous avions des dizaines ou
 des centaines de flux multicast fonctionnant

55
00:03:54,040 --> 00:04:05,320
 Cela pourrait potentiellement être néfaste pour le
 RP qui diffuse en multidiffusion à l'intérieur.

56
00:04:05,320 --> 00:04:08,500
 Alors, que va-t-il se passer ?

57
00:04:08,500 --> 00:04:13,940
 Et nous verrons cela plus en détail dans le prochain
 segment, c'est-à-dire le moment du rendez-vous

58
00:04:13,940 --> 00:04:18,400
 Dès qu'il aura reçu ce paquet d'enregistrement de
 code PIN, il va en fait en faire quelques-uns.

59
00:04:18,400 --> 00:04:20,260
 plusieurs choses simultanément.

60
00:04:20,260 --> 00:04:23,640
 Premièrement, il va le déballer et le transmettre
 le long de l'arbre partagé.

61
00:04:23,640 --> 00:04:25,320
 Nous en avons déjà parlé.

62
00:04:25,320 --> 00:04:36,140
 L'étape suivante, le point de rendez-vous,
 est ce multicast dans sa forme native pure.

63
00:04:36,140 --> 00:04:38,600
 Je peux donc simplement le transmettre
 en fonction de mon itinéraire m.

64
00:04:38,600 --> 00:04:41,700
 Ainsi, je n'aurai plus à importuner
 mon processeur avec ça.

65
00:04:41,700 --> 00:04:43,000
 Voyez, comment je fais ça ?

66
00:04:43,000 --> 00:04:46,540
 Eh bien, je sais que mon voisin en
 amont ne fera que le transmettre à

67
00:04:46,540 --> 00:04:48,980
 moi si je le lui demande.

68
00:04:48,980 --> 00:04:53,160
 Le RP enverra donc un message
 de participation à son voisin.

69
00:04:53,160 --> 00:04:57,560
 Mais il ne s'agit pas d'une collaboration entre une star
 et une comédie, car il connaît réellement la source.

70
00:04:57,560 --> 00:05:01,040
 Lorsque ce premier flux multiple arrive, il
 dit : « Oh, je sais qui est la source. »

71
00:05:01,040 --> 00:05:07,240
 est, 4.5.4.5. Il va donc envoyer ce
 qu'on appelle une jointure S, G.

72
00:05:07,240 --> 00:05:11,280
 Lorsqu'on observe le tracé du coupe-circuit, il présente
 exactement le même format qu'une étoile.

73
00:05:11,280 --> 00:05:15,600
 -comedy join, sauf qu'il y a l'adresse
 source et quelques autres éléments.

74
00:05:15,600 --> 00:05:17,800
 Les drapeaux sont également différents.

75
00:05:17,800 --> 00:05:24,440
 Et cela ouvre l'arbre des chemins les
 plus courts du point de rendez-vous à

76
00:05:24,440 --> 00:05:29,120
 la source. Car souvenez-vous, nous avons
 parlé du fait qu'il y a potentiellement

77
00:05:29,120 --> 00:05:32,080
 Plusieurs arbres partagés, n'est-ce pas ?

78
00:05:32,080 --> 00:05:35,240
 Si je suis un point de rendez-vous et qu'il
 y a 50 récepteurs différents répartis

79
00:05:35,240 --> 00:05:38,940
 Au sein du réseau, il pourrait y avoir
 50 arbres partagés différents.

80
00:05:38,940 --> 00:05:44,020
 Eh bien, de même, le concept d'arbre de
 plus court chemin provient d'un individu

81
00:05:44,020 --> 00:05:45,880
 Point de vue du routeur.

82
00:05:45,880 --> 00:05:49,700
 Le chemin le plus court pour atteindre cette
 source via un routeur peut être différent.

83
00:05:49,700 --> 00:05:54,700
 que le chemin le plus court pour
 atteindre cette même source.

84
00:05:54,700 --> 00:05:57,360
 Donc, au point de rendez-vous, lorsqu'il recevra
 ce dossier d'inscription, il se rendra

85
00:05:57,360 --> 00:06:02,820
 Autrement dit, je veux ouvrir le chemin le
 plus court pour atteindre cette source.

86
00:06:02,820 --> 00:06:06,140
 Car une fois ouvertes, ces
 caisses resteront fermées.

87
00:06:06,140 --> 00:06:09,900
 Je vais commencer à obtenir le multicast
 pur dans sa forme native.

88
00:06:09,900 --> 00:06:15,180
 Dès que la caisse arrive, en plus de
 la transmettre au bas de la page

89
00:06:15,180 --> 00:06:23,900
 Ainsi, ce RP va envoyer, laissez-moi
 développer un peu, il est

90
00:06:23,900 --> 00:06:34,200
 Je vais envoyer un s,
 G rejoindre en amont.

91
00:06:34,200 --> 00:06:39,960
 Et cela, dans R4, ajoutera une signature
 électronique rapide à zéro, zéro dans son

92
00:06:39,960 --> 00:06:42,320
 Liste des interfaces sortantes.

93
00:06:42,320 --> 00:06:45,600
 Maintenant, nos quatre
 diront : Oh, super.

94
00:06:45,600 --> 00:06:50,200
 D'accord, je peux maintenant commencer à transmettre
 le flux multicast en aval, sans aucune modification.

95
00:06:50,200 --> 00:06:55,180
 Forme native. Mais devinez quoi,
 il va continuer à s'inscrire.

96
00:06:55,180 --> 00:06:59,540
 Nous allons donc maintenant recevoir deux
 copies de ces paquets multicast sur le

97
00:06:59,540 --> 00:07:03,400
 RP. Nous allons recevoir
 le multicast natif.

98
00:07:03,400 --> 00:07:08,560
 Et nous allons en obtenir une autre copie à l'intérieur
 de ce paquet d'enregistrement des broches.

99
00:07:08,560 --> 00:07:14,380
 Vous vous demandez peut-être
 pourquoi cela s'est produit ?

100
00:07:14,380 --> 00:07:18,360
 Pourquoi une R4 s'arrête-t-elle
 net à ce moment-là ?

101
00:07:18,360 --> 00:07:20,600
 Eh bien, voici pourquoi.

102
00:07:20,600 --> 00:07:24,600
 Dans cette topologie particulière, cela
 ne le décrit pas vraiment très bien.

103
00:07:24,600 --> 00:07:40,480
 Mais imaginez si j'avais ça.

104
00:07:40,480 --> 00:07:44,140
 Bon, imaginez si, vous
 savez, voici ma source.

105
00:07:44,140 --> 00:08:00,640
 D'accord, nous avons le
 routeur X et le PIM RP.

106
00:08:00,640 --> 00:08:02,740
 Et voici le routeur numéro cinq.

107
00:08:02,740 --> 00:08:08,800
 Bon, ma source envoie donc son
 flux multicast au routeur cinq.

108
00:08:08,800 --> 00:08:13,700
 Le routeur cinq reçoit ensuite ce
 flux multicast et l'enregistre.

109
00:08:13,700 --> 00:08:20,020
 Voyons si je peux dessiner quelque
 chose ici pour l'indiquer.

110
00:08:20,020 --> 00:08:23,060
 Voilà pour l'inscription.

111
00:08:23,060 --> 00:08:34,020
 Et maintenant, le routeur cinq
 reçoit une jonction s, g.

112
00:08:34,020 --> 00:08:38,940
 Alors, la source est… voyons voir…
 quelle est la source de ce type ?

113
00:08:38,940 --> 00:08:41,740
 4.5.4.5 dans mon exemple particulier.

114
00:08:41,740 --> 00:08:45,280
 Il dit donc : « OK, voici
 une jonction PIM. »

115
00:08:45,280 --> 00:08:51,320
 Et il indiquera la source et le groupe.

116
00:08:51,320 --> 00:09:06,140
 Bon, alors, si cela se produit,
 comment formuler cela ?

117
00:09:06,140 --> 00:09:08,960
 En fait, voici un meilleur exemple.

118
00:09:08,960 --> 00:09:16,180
 Placez un routeur ici, au milieu.

119
00:09:16,180 --> 00:09:21,680
 D'accord, donc tous ces messages PIM
 ont une durée de vie d'un seul jour.

120
00:09:21,680 --> 00:09:26,020
 Bien, nous avons vu comment le signal PIM étoile virgule
 g join a été diffusé sur le même multicast.

121
00:09:26,020 --> 00:09:30,200
 adresse comme bonjour, 2240013.

122
00:09:30,200 --> 00:09:33,360
 Je ne l'ai pas vraiment souligné dans la
 trace du renifleur, mais tout comme le

123
00:09:33,360 --> 00:09:44,720
 PIM bonjour a une durée de vie d'un,
 PIM se connecte et disons son adresse

124
00:09:44,720 --> 00:09:55,220
 est 55555. Lorsque la jonction PIM se fait
 ici, dans l'en-tête IP proprement dit,

125
00:09:55,220 --> 00:10:01,160
 La source viendra de ce type.

126
00:10:01,160 --> 00:10:06,060
 Et la destination sera comme ça.

127
00:10:06,060 --> 00:10:09,120
 En fait, ce sera le routeur.

128
00:10:09,120 --> 00:10:11,820
 Ce type-là, 4.5.4.4.

129
00:10:11,820 --> 00:10:18,040
 Disons simplement que, pour faire
 simple, il est le routeur 4.

130
00:10:18,040 --> 00:10:24,100
 Il n'y a donc pas forcément moyen pour le
 routeur 4 de savoir que cette jonction

131
00:10:24,100 --> 00:10:28,800
 En fait, cela a commencé au RP
 car cela se fait saut par saut.

132
00:10:28,800 --> 00:10:43,360
 Lorsque le RP l'a envoyé pour la première fois, il l'a
 envoyé au routeur Z parce qu'il s'agit d'une virgule.

133
00:10:43,360 --> 00:10:48,720
 La commande g join contenait
 les mêmes informations.

134
00:10:48,720 --> 00:10:51,700
 La source était 4.5.4.5.

135
00:10:51,700 --> 00:10:56,500
 Le groupe était de 239 999.

136
00:10:56,500 --> 00:11:04,380
 Et le paquet avait ici une source
 IP du RP et la destination de

137
00:11:04,380 --> 00:11:12,800
 Routeur 4. Plaçons-le juste ici.

138
00:11:12,800 --> 00:11:18,440
 En fait, non, sa destination était le routeur
 Z car il s'agissait d'un saut par saut.

139
00:11:18,440 --> 00:11:22,540
 Il ne faut qu'un seul saut.

140
00:11:22,540 --> 00:11:27,040
 La source IP est RP.

141
00:11:27,040 --> 00:11:32,480
 Destination = routeur Z.

142
00:11:32,480 --> 00:11:36,820
 Il a donc envoyé cette virgule car
 le RP a dit : « OK, je sais qui… »

143
00:11:36,820 --> 00:11:44,580
 La source est… Mon voisin le
 plus proche est le routeur Z.

144
00:11:44,580 --> 00:11:49,440
 Je vais donc envoyer un PIM (comma g join)
 à ce voisin en disant : « Hé ! »

145
00:11:49,440 --> 00:11:52,140
 Voisin, pouvez-vous m'ouvrir ce passage ?

146
00:11:52,140 --> 00:11:55,660
 Ensuite, lorsque le routeur Z le
 reçoit, il fait la même chose.

147
00:11:55,660 --> 00:11:59,660
 Il dit : « Mon chemin sûr vers
 la source est le routeur 4. »

148
00:11:59,660 --> 00:12:04,360
 Je vais donc créer une jonction PIM
 s comma g et l'envoyer au routeur 4.

149
00:12:04,360 --> 00:12:07,520
 Cela s'ouvre donc au fur et à mesure
 que l'on avance sur ce chemin.

150
00:12:07,520 --> 00:12:11,120
 Cette interface est ouverte dans la
 liste des interfaces sortantes.

151
00:12:11,120 --> 00:12:14,460
 Cette interface est ouverte dans la
 liste des interfaces sortantes.

152
00:12:14,460 --> 00:12:19,600
 Mais lorsque le routeur 4 reçoit ceci, il n'a aucune
 idée de la raison pour laquelle il reçoit

153
00:12:19,600 --> 00:12:23,600
 C'est parce que le RP
 a lancé le processus.

154
00:12:23,600 --> 00:12:27,120
 Tout ce qu'il sait, c'est qu'il a reçu une
 commande s comma g join pour le routeur Z.

155
00:12:27,120 --> 00:12:32,080
 Il n'a aucune idée de pourquoi
 le routeur Z lui a envoyé ça.

156
00:12:32,080 --> 00:12:36,360
 Seul ce routeur Z l'a reçu, c'est
 ce routeur Z qui l'a initié.

157
00:12:36,360 --> 00:12:41,400
 Alors il dit, eh bien, le routeur Z m'a envoyé
 cette virgule g join, mais je suis dans le

158
00:12:41,400 --> 00:12:43,120
 processus d'inscription.

159
00:12:43,120 --> 00:12:44,780
 Les deux sont totalement différents.

160
00:12:44,780 --> 00:12:48,700
 Ce n'est pas parce qu'une personne m'a envoyé un lien
 d'inscription que je dois arrêter les inscriptions.

161
00:12:48,700 --> 00:12:51,300
 faire avec un autre gars.

162
00:12:51,300 --> 00:12:54,380
 Je vais continuer à m'inscrire car je n'ai
 pas encore eu de nouvelles de la part de

163
00:12:54,380 --> 00:13:05,700
 RP pour l'instant. Tout ce que j'ai entendu, c'est
 que le routeur Z recevrait deux copies de

164
00:13:05,700 --> 00:13:06,900
 Le même paquet.

165
00:13:06,900 --> 00:13:09,880
 Lorsque le paquet multicast commencera
 à transiter, il transitera nativement.

166
00:13:09,880 --> 00:13:15,240
 De 4 à Z à RP, car cette voie
 est désormais ouverte.

167
00:13:15,240 --> 00:13:19,240
 Et simultanément, lorsque le routeur 4
 a reçu ce paquet multicast, il a créé

168
00:13:19,240 --> 00:13:25,240
 une copie de celle-ci, encapsulée dans un message
 unicast et diffusée directement en unicast

169
00:13:25,240 --> 00:13:31,700
 au RP. Alors maintenant, le RP dit :
 « Hein ? D'accord, super nouvelle ! »

170
00:13:31,700 --> 00:13:37,400
 Je viens de recevoir le paquet multicast
 natif et authentique sur mon

171
00:13:37,400 --> 00:13:38,840
 Arbre du chemin le plus court.

172
00:13:38,840 --> 00:13:42,160
 Je sais maintenant que le chemin le plus
 court vers la source est ouvert.

173
00:13:42,160 --> 00:13:44,340
 Ça coule. Ça fonctionne.

174
00:13:44,340 --> 00:13:47,240
 Il dit : « Je n'ai plus besoin de
 ces messages d'inscription. »

175
00:13:47,240 --> 00:13:50,380
 Cela me fait travailler
 plus que nécessaire.

176
00:13:50,380 --> 00:14:00,520
 Le RP enverra donc ce qu'on appelle un
 message d'arrêt d'enregistrement PIM.

177
00:14:00,520 --> 00:14:05,060
 vers le routeur 4. C'est ce
 que recherche le routeur 4.

178
00:14:05,060 --> 00:14:09,820
 Cela l'amènera à interrompre
 le processus d'inscription.

179
00:14:09,820 --> 00:14:14,320
 Je sais donc que, dans ce schéma,
 ce n'était pas tout à fait clair.

180
00:14:14,320 --> 00:14:22,400
 Vous auriez peut-être dit : « D'accord, eh bien, quand
 l'application va-t-elle arrêter l'enregistrement ? »

181
00:14:22,400 --> 00:14:23,860
 Je veux te montrer non.

182
00:14:23,860 --> 00:14:28,920
 Non. L'inscription se poursuivra jusqu'à
 ce que le RP indique explicitement :

183
00:14:28,920 --> 00:14:32,900
 Arrêtez, s'il vous plaît. Je ne veux
 plus voir ces caisses enregistreuses.

184
00:14:32,900 --> 00:14:40,100
 Il utilise donc un message d'arrêt de registre
 pour effectuer la commutation.

185
00:14:40,100 --> 00:14:44,780
 En réalité, il ne l'utilise pas pour passer
 à son arbre de chemin le plus court.

186
00:14:44,780 --> 00:14:50,500
 Il le fait après que son arbre de chemin
 le plus court ait déjà été ouvert.

187
00:14:50,500 --> 00:15:05,720
 En fait, je suis prêt à changer cela.

188
00:15:05,720 --> 00:15:10,380
 Là, le RP utilise des messages d'arrêt enregistrés
 après son arbre de chemin le plus court.

189
00:15:10,380 --> 00:15:17,480
 C'est confirmé et ouvert.

190
00:15:17,480 --> 00:15:20,320
 Voilà donc le processus
 d'enregistrement PIM.

191
00:15:20,320 --> 00:15:26,420
 Alors, voyons cela de plus près
 et comment cela fonctionne.

192
00:15:26,420 --> 00:15:32,340
 Je pense donc que notre arbre de parenté
 partagé est actuellement ouvert.

193
00:15:32,340 --> 00:15:35,280
 Vérifions cela, allons au routeur 3 vers RP
 et assurons-nous qu'il est toujours là.

194
00:15:35,280 --> 00:15:46,720
 a une étoile, entrée.

195
00:15:46,720 --> 00:15:48,680
 Ah, d'accord, il ne le fait pas.

196
00:15:48,680 --> 00:15:53,640
 Revenons à notre source,
 notre récepteur ici.

197
00:15:53,640 --> 00:16:11,540
 Ah oui, c'est pour ça, parce qu'il
 n'a pas rejoint le groupe.

198
00:16:11,540 --> 00:16:14,500
 Bon, maintenant on devrait l'avoir.

199
00:16:14,500 --> 00:16:23,440
 Bon, voilà donc notre
 vedette, notre entrée.

200
00:16:23,440 --> 00:16:27,680
 Et en ce qui concerne ces minuteurs,
 celui-ci est comme…

201
00:16:27,680 --> 00:16:28,900
 la durée de vie de ceci.

202
00:16:28,900 --> 00:16:30,620
 Le compte à rebours va continuer.

203
00:16:30,620 --> 00:16:35,240
 Et si ce compte à rebours atteint zéro, cela
 signifie que je vais supprimer ceci.

204
00:16:35,240 --> 00:16:38,580
 interface de la liste des
 interfaces sortantes.

205
00:16:38,580 --> 00:16:43,640
 Mais nous savons que tant que ce récepteur
 est toujours actif, tant que

206
00:16:43,640 --> 00:16:48,120
 Il y a toujours des requêtes envoyées et
 des rapports reçus, routeur 2 tous les

207
00:16:48,120 --> 00:16:54,420
 Dans 60 secondes, nous enverrons une autre étoile.
 Inscrivez-vous ici pour actualiser cet état.

208
00:16:54,420 --> 00:16:59,720
 Et le routeur 8 sera également installé lorsqu'il
 l'aura reçu, nous lui enverrons sa propre étoile.

209
00:16:59,720 --> 00:17:02,780
 Rejoignez-nous pour actualiser cet état.

210
00:17:02,780 --> 00:17:12,280
 Par exemple, actuellement,
 nous sommes à 233.

211
00:17:12,280 --> 00:17:14,080
 Et c'est de nouveau opérationnel.

212
00:17:14,080 --> 00:17:19,580
 Vous voyez, nous avons donc commencé
 à trois minutes et 23 secondes.

213
00:17:19,580 --> 00:17:24,520
 Et nous sommes descendus
 à environ une minute.

214
00:17:24,520 --> 00:17:27,980
 Et puis nous ne l'avons pas vu, mais en
 arrière-plan, il a reçu une étoile.

215
00:17:27,980 --> 00:17:31,500
 il a participé à une actualisation
 et cela est remonté à ce niveau.

216
00:17:31,500 --> 00:17:38,740
 Ce minuteur indique la durée totale pendant
 laquelle cette interface a été active.

217
00:17:38,740 --> 00:17:40,220
 la liste des interfaces sortantes.

218
00:17:40,220 --> 00:17:44,100
 Cela fait donc une minute et quatre secondes
 que nous avons reçu notre tout premier

219
00:17:44,100 --> 00:17:51,160
 première étoile, rejoindre ce qui a initialement
 provoqué la création de cette entrée m-route.

220
00:17:51,160 --> 00:17:53,940
 Alors cette fois, nous allons simplement
 continuer à augmenter.