1
00:00:08,320 --> 00:00:13,520
 Bon, avant d'entrer dans le vif du sujet concernant
 le PIM en tant que multicast, il faut savoir que…

2
00:00:13,520 --> 00:00:17,920
 Protocole de routage : examinons de manière
 générale ce qu’est le multicast.

3
00:00:17,920 --> 00:00:22,100
 Protocoles de routage : pourquoi en avons-nous besoin
 et pour quel problème ont-ils été conçus ?

4
00:00:22,100 --> 00:00:28,500
 pour résoudre. Nous savons donc que nous avons
 ce concept de sources et de récepteurs,

5
00:00:28,500 --> 00:00:31,880
 la source étant un serveur quelconque
 qui diffuse du trafic multicast

6
00:00:31,880 --> 00:00:35,740
 et en atteignant votre routeur, ce dernier
 le rejette car il n'y a pas de

7
00:00:35,740 --> 00:00:38,000
 idée de l'endroit où ça est censé aller.

8
00:00:38,000 --> 00:00:41,380
 Et à l'autre bout du réseau, vous avez vos
 récepteurs, vos ordinateurs portables,

9
00:00:41,380 --> 00:00:45,760
 vos PC qui souhaitent ce trafic multicast,
 mais dont la passerelle par défaut a

10
00:00:45,760 --> 00:00:47,300
 Aucune idée d'où vient la source.

11
00:00:47,300 --> 00:00:49,720
 Alors, comment relier les deux ?

12
00:00:49,720 --> 00:00:54,140
 Et c'est précisément la raison pour laquelle nous
 avons besoin de protocoles de routage multicast.

13
00:00:54,140 --> 00:00:58,140
 Construisez cette branche, pour les connecter,
 pour construire cette distribution multicast

14
00:00:58,140 --> 00:01:04,360
 arbre. Il nous faut donc créer cet arbre.

15
00:01:04,360 --> 00:01:07,580
 Et j'ai expliqué dans la vidéo précédente
 que nous avons deux niveaux de base élevés

16
00:01:07,580 --> 00:01:09,160
 des façons de faire cela.

17
00:01:09,160 --> 00:01:13,380
 Une méthode, appelée modèle push,
 est utilisée en mode dense.

18
00:01:13,380 --> 00:01:17,440
 En clair, ces protocoles consistent
 à inonder le réseau de ce multicast.

19
00:01:17,440 --> 00:01:21,700
 trafic. Vous arriverez certainement jusqu'aux
 récepteurs et à tous les autres

20
00:01:21,700 --> 00:01:26,460
 les branches de l'arbre que
 les râteaux devront élaguer

21
00:01:26,460 --> 00:01:30,080
 des branches pour dire : « Hé, routeur
 en amont, arrête de m'envoyer ça. »

22
00:01:30,080 --> 00:01:34,220
 Je n'ai personne en aval qui
 en ait réellement envie.

23
00:01:34,220 --> 00:01:40,280
 L'autre modèle est le mode clairsemé, ce qui signifie
 que, OK, une fois que les récepteurs indiquent

24
00:01:40,280 --> 00:01:44,900
 leur intérêt pour la passerelle par défaut,
 la passerelle par défaut doit maintenant

25
00:01:44,900 --> 00:01:48,520
 déclencher une sorte de message de jonction multicast
 indiquant : « OK, je vais envoyer »

26
00:01:48,520 --> 00:01:51,400
 Un message en amont disant : «
 Hé, routeur au-dessus de moi. »

27
00:01:51,400 --> 00:01:56,100
 Si jamais vous recevez ce message,
 ce flux multicast, je suis ici.

28
00:01:56,100 --> 00:02:01,820
 Je veux ça. La question devient alors : OK, eh
 bien, où se situe votre valeur par défaut ?

29
00:02:01,820 --> 00:02:03,120
 passerelle, envoyez-moi ça ?

30
00:02:03,120 --> 00:02:08,020
 Parce qu'il a peut-être cinq ou
 six routeurs en amont de lui.

31
00:02:08,020 --> 00:02:10,760
 À qui envoie-t-il cette commande ?

32
00:02:10,760 --> 00:02:15,620
 Pour répondre à cette question, voici
 une bonne analogie que j'ai trouvée.

33
00:02:15,620 --> 00:02:18,600
 Pensez aux rencontres amoureuses,
 n'est-ce pas ?

34
00:02:18,600 --> 00:02:21,540
 Des garçons et des filles qui se rencontrent
 et essaient de se trouver.

35
00:02:21,540 --> 00:02:27,880
 Un protocole en mode dense serait donc un peu
 comme si vous étiez le gars qui marche.

36
00:02:27,880 --> 00:02:31,460
 entrer dans une boîte de nuit, et pour trouver
 l'âme sœur, il suffit de marcher

37
00:02:31,460 --> 00:02:34,580
 Je m'adresse à chacune des filles présentes
 qui me disent : « Hé, je t'aime. »

38
00:02:34,580 --> 00:02:35,660
 Veux-tu m'épouser ?

39
00:02:35,660 --> 00:02:37,380
 Je t'aime. Veux-tu m'épouser ?

40
00:02:37,380 --> 00:02:40,220
 Bien sûr, tu te fais gifler
 plusieurs fois pour ça.

41
00:02:40,220 --> 00:02:43,120
 Mais avec un peu de chance, vous finirez par
 retrouver votre récepteur, n'est-ce pas ?

42
00:02:43,120 --> 00:02:46,180
 Là-bas, tout au fond, la fille qui
 boit beaucoup de bière, elle dira :

43
00:02:46,180 --> 00:02:47,400
 Oui, je veux t'épouser.

44
00:02:47,400 --> 00:02:49,980
 Et voilà, vous avez trouvé
 votre récepteur.

45
00:02:49,980 --> 00:02:50,680
 Vous êtes la source.

46
00:02:50,680 --> 00:02:51,300
 C'est elle qui reçoit.

47
00:02:51,300 --> 00:02:54,160
 Il fallait d'abord passer par tous
 les autres et être éliminé.

48
00:02:54,160 --> 00:02:56,820
 Mais finalement, vous avez trouvé
 la personne que vous cherchiez.

49
00:02:56,820 --> 00:02:59,040
 C'est comme un protocole en mode dense.

50
00:02:59,040 --> 00:03:02,680
 Un protocole en mode clairsemé, c'est comme
 si, au lieu de faire cela et de risquer tout

51
00:03:02,680 --> 00:03:06,140
 Face à ce rejet, vous utilisez
 un service de rencontres.

52
00:03:06,140 --> 00:03:09,660
 Donc, vous avez cette société intermédiaire
 appelée service de rencontres, vous savez,

53
00:03:09,660 --> 00:03:15,140
 Peu importe, eharmony.com ou quel que
 soit le site à la mode en ce moment.

54
00:03:15,140 --> 00:03:19,540
 Et la source, c'est vous, vous allez sur le
 site de rencontre et vous créez un profil.

55
00:03:19,540 --> 00:03:21,260
 Et vous dites : « Hé, c'est moi. »

56
00:03:21,260 --> 00:03:22,400
 Je suis tellement merveilleuse
 et formidable.

57
00:03:22,400 --> 00:03:23,900
 Je gagne 5 millions de dollars par an.

58
00:03:23,900 --> 00:03:24,880
 Je conduis une Ferrari.

59
00:03:24,880 --> 00:03:26,160
 S'il vous plaît, épousez-moi.

60
00:03:26,160 --> 00:03:28,340
 C'est bien ça ? Donc tu publies ton
 annonce sur le site de rencontres.

61
00:03:28,340 --> 00:03:31,800
 Les destinataires, enfin, vous savez, de toutes
 les 50 millions de femmes qui utilisent

62
00:03:31,800 --> 00:03:35,180
 sur ce site de rencontres, il y
 en a peut-être trois qui y vont.

63
00:03:35,180 --> 00:03:38,020
 et dire : « Ah oui, c'est exactement
 ce que je cherchais. »

64
00:03:38,020 --> 00:03:38,800
 C'est un peu un crétin.

65
00:03:38,800 --> 00:03:39,600
 Il a beaucoup d'argent.

66
00:03:39,600 --> 00:03:40,920
 Il a une Ferrari.

67
00:03:40,920 --> 00:03:41,640
 Ce type va me plaire.

68
00:03:41,640 --> 00:03:45,140
 Vous vous rencontrez donc tous les deux par le
 biais du service de rencontres et initialement

69
00:03:45,140 --> 00:03:47,700
 Vous ne pouvez pas vous
 parler, n'est-ce pas ?

70
00:03:47,700 --> 00:03:50,340
 Au départ, le site de rencontres dit non,
 vous savez, pour s'assurer que ce type...

71
00:03:50,340 --> 00:03:53,420
 Elle n'est pas une harceleuse et elle n'est pas
 folle, vous savez, on ne va pas laisser faire.

72
00:03:53,420 --> 00:03:56,380
 Vous échangez vos numéros de
 téléphone, vos adresses, etc.

73
00:03:56,380 --> 00:03:59,740
 Vous devrez utiliser notre système de chat et notre
 système de messagerie électronique pour communiquer.

74
00:03:59,740 --> 00:04:03,900
 entre vous. Mais finalement, après
 avoir échangé des messages par

75
00:04:03,900 --> 00:04:07,580
 Grâce à ce service de rencontres, vous pouvez
 désormais savoir où habite l'autre personne.

76
00:04:07,580 --> 00:04:10,120
 Vous pouvez échanger vos numéros de téléphone
 et vous pouvez cesser de les utiliser.

77
00:04:10,120 --> 00:04:12,460
 Vous pouvez communiquer directement.

78
00:04:12,460 --> 00:04:15,160
 Voilà comment fonctionnent les
 protocoles en mode clairsemé.

79
00:04:15,160 --> 00:04:19,080
 Avec les protocoles en mode clairsemé,
 vous avez un routeur quelque part dans

80
00:04:19,080 --> 00:04:23,180
 votre réseau qui offre des fonctionnalités similaires
 à celles d'un service de rencontres.

81
00:04:23,180 --> 00:04:28,200
 Et donc les récepteurs, une fois que votre ordinateur
 portable a envoyé le message IGMP au routeur,

82
00:04:28,200 --> 00:04:32,880
 votre passerelle par défaut, votre passerelle par
 défaut dit, hmm, d'accord, je sais que j'ai

83
00:04:32,880 --> 00:04:40,060
 Je suis un récepteur, je n'ai aucune
 idée d'où se trouve la source.

84
00:04:40,060 --> 00:04:44,720
 Le destinataire le souhaite. Mais je sais où se situe le
 service de rencontres dans les conditions générales.

85
00:04:44,720 --> 00:04:48,700
 d'un protocole de routage multicast, ce service
 de rencontres est ce que nous appelons un

86
00:04:48,700 --> 00:04:51,160
 point de rendez-vous, un RP.

87
00:04:51,160 --> 00:04:54,660
 Il existe donc un routeur sur le réseau qui centralise
 le multicast pour tous les routeurs.

88
00:04:54,660 --> 00:04:57,380
 On sait que c'est à ce type-là
 qu'on s'adresse.

89
00:04:57,380 --> 00:04:59,460
 C'est le point de rendez-vous.

90
00:04:59,460 --> 00:05:03,060
 Votre routeur va maintenant dire : « D'accord,
 je vais créer quelque chose appelé… »

91
00:05:03,060 --> 00:05:05,380
 un message de jonction, un message
 de jonction multicast.

92
00:05:05,380 --> 00:05:09,520
 Et je l'enverrai en direction du point
 de rendez-vous en disant : hé,

93
00:05:09,520 --> 00:05:12,520
 J'ai quelqu'un ici qui
 recherche ce groupe.

94
00:05:12,520 --> 00:05:17,460
 Et finalement, cette jonction finit par
 atteindre le point de rendez-vous.

95
00:05:17,460 --> 00:05:20,900
 La source n'a peut-être pas encore démarré, mais
 le point de rendez-vous est maintenant prêt.

96
00:05:20,900 --> 00:05:25,000
 a construit une branche descendant l'arbre depuis
 le point de rendez-vous jusqu'à travers

97
00:05:25,000 --> 00:05:27,120
 Ces routeurs sont reliés à votre
 passerelle par défaut.

98
00:05:27,120 --> 00:05:32,320
 Nous avons maintenant ouvert une voie pour que, si la
 diffusion multicast démarre, elle soit disponible.

99
00:05:32,320 --> 00:05:34,240
 une direction dans laquelle
 il peut s'écouler.

100
00:05:34,240 --> 00:05:38,040
 Maintenant, la source, la source
 démarre, le serveur.

101
00:05:38,040 --> 00:05:41,900
 Le serveur commence donc à envoyer son flux
 multicast, qui atteint son routeur.

102
00:05:41,900 --> 00:05:45,580
 Un routeur connecté à ce segment est soumis
 à des chocs violents à l'arrière.

103
00:05:45,580 --> 00:05:47,580
 la tête avec ce trafic multicast.

104
00:05:47,580 --> 00:05:50,440
 Encore une fois, ce routeur tout là-haut,
 dans l'autre coin du réseau

105
00:05:50,440 --> 00:05:55,300
 dit-il, je n'ai jamais eu de nouvelles d'aucun destinataire,
 mais je sais où se trouve le site de rencontres

106
00:05:55,300 --> 00:06:03,540
 Le service est assuré. Je sais où
 se trouve le point de rendez-vous.

107
00:06:03,540 --> 00:06:07,080
 Nous reviendrons plus en détail
 sur ce point, mais en résumé :

108
00:06:07,080 --> 00:06:12,500
 Il le transmet en monodiffusion. Il prend ce paquet multidiffusion
 et l'encapsule dans une monodiffusion.

109
00:06:12,500 --> 00:06:16,500
 en-tête et le diffuse en monodiffusion
 au point de rendez-vous.

110
00:06:16,500 --> 00:06:20,920
 Une fois que le point de rendez-vous l'a reçu,
 il le déballe et dit : « Oh, voilà… »

111
00:06:20,920 --> 00:06:24,240
 multidiffusion. Ah oui, je sais où ça
 mène, car j'ai reçu une invitation.

112
00:06:24,240 --> 00:06:27,360
 pour cela, et il le fait
 descendre de l'arbre.

113
00:06:27,360 --> 00:06:31,020
 C'est donc ainsi que, dans les protocoles en mode clairsemé,
 nous les connectons initialement, n'est-ce pas ?

114
00:06:31,020 --> 00:06:33,460
 Ce point de rendez-vous, c'est
 le service de rencontres.

115
00:06:33,460 --> 00:06:37,460
 Mais comme dans mon analogie, vous ne voulez
 pas à la fois la source et le récepteur.

116
00:06:37,460 --> 00:06:41,360
 ils passaient constamment par le point
 de rendez-vous pour se parler.

117
00:06:41,360 --> 00:06:43,400
 Ce n'est pas forcément efficace,
 n'est-ce pas ?

118
00:06:43,400 --> 00:06:49,980
 Et si le récepteur se trouve en Floride
 et la source en Caroline du Nord ?

119
00:06:49,980 --> 00:06:52,680
 mais le point de rendez-vous
 se trouve en Californie ?

120
00:06:52,680 --> 00:06:55,700
 Eh bien, dans ce trafic, les gens font de gros
 détours pour arriver au point de rendez-vous.

121
00:06:55,700 --> 00:07:00,300
 aller-retour. Il existe un chemin beaucoup
 plus court directement depuis la source

122
00:07:00,300 --> 00:07:02,140
 et le récepteur.

123
00:07:02,140 --> 00:07:06,080
 Mais nous devions d'abord mettre en place cette
 diffusion multicast avant de pouvoir découvrir

124
00:07:06,080 --> 00:07:10,320
 D'où ça vient ? De Caroline du Nord.

125
00:07:10,320 --> 00:07:13,280
 Et maintenant, les Rogers peuvent
 emprunter cette voie.

126
00:07:13,280 --> 00:07:15,060
 Ils peuvent dire : « OK, merci,
 service de rencontres. »

127
00:07:15,060 --> 00:07:16,380
 Merci, point de rendez-vous.

128
00:07:16,380 --> 00:07:17,760
 Je n'ai plus besoin de toi.

129
00:07:17,760 --> 00:07:20,240
 Maintenant, je sais exactement
 où se trouve la source.

130
00:07:20,240 --> 00:07:24,040
 Nous pouvons obtenir le trafic directement de lui
 et nous pouvons basculer vers cette solution.

131
00:07:24,040 --> 00:07:29,360
 Voilà donc une vue d'ensemble du fonctionnement
 des protocoles en mode clairsemé.

132
00:07:29,360 --> 00:07:33,540
 Nous devons d'abord nous présenter au point
 de rendez-vous et exprimer notre intérêt.

133
00:07:33,540 --> 00:07:35,440
 Créez cette branche.

134
00:07:35,440 --> 00:07:39,680
 Le trafic doit commencer à se diriger vers le point
 de rendez-vous, puis il change de direction.

135
00:07:39,680 --> 00:07:44,620
 Le signal passe donc directement de
 la source au récepteur, rendez-vous

136
00:07:44,620 --> 00:07:49,260
 Ce point ne fait même plus
 partie de l'équation.

137
00:07:49,260 --> 00:07:56,680
 Les protocoles en mode clairsemé utilisent donc ce qu'on
 appelle des arbres à base de noyaux ou arbres RP.

138
00:07:56,680 --> 00:07:58,500
 Parce que nous avons un
 point de rendez-vous.

139
00:07:58,500 --> 00:08:01,140
 Le point de rendez-vous est
 donc le cœur de l'arbre.

140
00:08:01,140 --> 00:08:05,620
 Tout le monde commence par aller vers lui, puis
 l'attention se détourne de lui assez rapidement.

141
00:08:05,620 --> 00:08:16,700
 rapidement. OK, donc RPF, au cas où vous
 ne le sauriez pas, bien sûr, RPF pourrait

142
00:08:16,700 --> 00:08:16,880
 Passez à l'arbre.

143
00:08:16,880 --> 00:08:20,780
 Cela représente beaucoup de choses différentes,
 mais dans ce cas précis, cela signifie

144
00:08:20,780 --> 00:08:23,260
 Inversion du chemin de transmission.

145
00:08:23,260 --> 00:08:27,060
 Considérons maintenant le trafic unicast.

146
00:08:27,060 --> 00:08:29,840
 Laissons de côté la multidiffusion
 un instant.

147
00:08:29,840 --> 00:08:36,720
 Un routeur reçoit un paquet unicast
 à destination de l'adresse 9.9.9.9.

148
00:08:36,720 --> 00:08:38,560
 À quoi sert le routeur ?

149
00:08:38,560 --> 00:08:43,420
 Le routeur dit : OK, je vais examiner
 cette adresse IP de destination.

150
00:08:43,420 --> 00:08:47,920
 Je vais consulter ma table de routage et
 vérifier si j'ai une route qui indique…

151
00:08:47,920 --> 00:08:49,940
 me dire où se trouve cette destination.

152
00:08:49,940 --> 00:08:54,740
 Normalement, pour acheminer ce
 colis et le mettre en route,

153
00:08:54,740 --> 00:08:58,060
 Le routeur se soucie-t-il de
 la source de ce paquet ?

154
00:08:58,060 --> 00:09:01,320
 Non, vous vous fichez complètement
 de l'adresse source.

155
00:09:01,320 --> 00:09:05,260
 En fait, vous pourriez utiliser 0,
 0, 0, 0 comme source, le routeur

156
00:09:05,260 --> 00:09:09,220
 Il s'en fiche. Pour acheminer ce
 paquet, il ne tient compte que du

157
00:09:09,220 --> 00:09:13,920
 destination. Bien sûr, vous pourriez mettre
 en place des listes d'accès et d'autres

158
00:09:13,920 --> 00:09:17,120
 Des trucs comme ça pour le forcer
 à regarder à la source.

159
00:09:17,120 --> 00:09:20,580
 Et vous pouvez également implémenter
 quelque chose appelé RPF.

160
00:09:20,580 --> 00:09:25,720
 Par exemple, que se passe-t-il si, vous savez, disons que
 mon ordinateur portable est posé là, en ce moment ?

161
00:09:25,720 --> 00:09:32,120
 sur le réseau 11, 11.quelque chose,
 donc j'ai eu une adresse 11, 11.555.

162
00:09:32,120 --> 00:09:34,820
 Voici l'adresse de mon
 ordinateur portable.

163
00:09:34,820 --> 00:09:38,280
 Et je découvre, j'apprends par le
 bouche-à-oreille que je vais être

164
00:09:38,280 --> 00:09:41,080
 Licencié aujourd'hui. Quoi ?

165
00:09:41,080 --> 00:09:43,260
 J'ai passé des années
 dans cette entreprise.

166
00:09:43,260 --> 00:09:44,340
 J'ai fait des heures supplémentaires.

167
00:09:44,340 --> 00:09:46,520
 J'ai sacrifié mes enfants
 pour cette entreprise.

168
00:09:46,520 --> 00:09:47,560
 Ils vont me licencier.

169
00:09:47,560 --> 00:09:49,260
 Ça m'énerve vraiment.

170
00:09:49,260 --> 00:09:50,440
 Alors je dis, vous savez quoi ?

171
00:09:50,440 --> 00:09:56,140
 Avant de partir, je connais l'adresse
 IP du serveur web de mon entreprise.

172
00:09:56,140 --> 00:10:00,000
 C'est 77777. Donc je suis un peu,
 je suis assez débrouillard.

173
00:10:00,000 --> 00:10:00,560
 Je dis, vous savez quoi ?

174
00:10:00,560 --> 00:10:01,720
 Je vais faire tomber ce serveur.

175
00:10:01,720 --> 00:10:05,040
 Je vais saturer ce serveur avec, je
 ne sais pas, un trafic quelconque.

176
00:10:05,040 --> 00:10:07,300
 Peut-être des requêtes de synchronisation
 TCP, n'est-ce pas ?

177
00:10:07,300 --> 00:10:11,080
 Je vais simplement le saturer avec 5 millions
 de synchronisations TCP par seconde.

178
00:10:11,080 --> 00:10:12,440
 Faites-le descendre. Ha ha ha.

179
00:10:12,440 --> 00:10:13,540
 Vous voulez me licencier ?

180
00:10:13,540 --> 00:10:15,780
 Je vais vous faire perdre des millions de
 dollars dans les deux prochains mois.

181
00:10:15,780 --> 00:10:18,100
 pendant des heures, pendant que
 votre serveur est hors service.

182
00:10:18,100 --> 00:10:22,240
 Eh bien, si je décide de faire ça, je ne veux
 pas que les gens puissent tracer ces paquets.

183
00:10:22,240 --> 00:10:23,580
 C'est à moi de revenir, n'est-ce pas ?

184
00:10:23,580 --> 00:10:27,360
 Car non seulement je vais être licencié, mais
 maintenant je vais me retrouver en prison avec

185
00:10:27,360 --> 00:10:29,060
 Quelqu'un que je n'apprécie
 pas particulièrement.

186
00:10:29,060 --> 00:10:30,280
 Donc je ne veux pas de ça.

187
00:10:30,280 --> 00:10:34,080
 Alors je me dis, hmm, si je dois envoyer ces
 requêtes de synchronisation TCP à ce serveur

188
00:10:34,080 --> 00:10:37,480
 Pour tenter de le saturer, je veux
 m'assurer que l'adresse source est

189
00:10:37,480 --> 00:10:41,160
 Pas moi. Je ne veux pas être
 11555, c'est-à-dire moi.

190
00:10:41,160 --> 00:10:44,940
 Je veux falsifier cette adresse source
 pour qu'elle ressemble à autre chose.

191
00:10:44,940 --> 00:10:49,000
 Ainsi, s'ils trouvent ces paquets, ils
 ne sauront jamais que ça vient de moi.

192
00:10:49,000 --> 00:10:53,000
 Je vais donc lui attribuer une fausse adresse
 IP, car je sais quand ces paquets arrivent.

193
00:10:53,000 --> 00:11:00,260
 Les routeurs, les routeurs, se
 fichent de l'adresse source.

194
00:11:00,260 --> 00:11:02,260
 Et ça va planter.

195
00:11:02,260 --> 00:11:06,960
 Eh bien, si je suis l'administrateur réseau,
 une chose que je peux faire pour éviter

196
00:11:06,960 --> 00:11:12,540
 Pour empêcher les gens de faire cela, je peux utiliser
 ce qu'on appelle la vérification RPF unicast.

197
00:11:12,540 --> 00:11:16,740
 ce qui signifie que lorsqu'un paquet arrive
 sur une interface d'un routeur, avant

198
00:11:16,740 --> 00:11:21,460
 Je regarde même l'adresse de destination,
 je vais regarder la source

199
00:11:21,460 --> 00:11:25,440
 adresse, et je vais me poser
 une question très simple.

200
00:11:25,440 --> 00:11:31,180
 Cette adresse source, si je devais
 remonter dans le sens inverse vers

201
00:11:31,180 --> 00:11:36,280
 Cette source, est-ce que j'utiliserais cette interface
 à l'endroit où elle vient d'être injectée ?

202
00:11:36,280 --> 00:11:38,480
 Maintenant, je suis assis ici.

203
00:11:38,480 --> 00:11:44,100
 Je suis 11.555. J'ai intentionnellement
 modifié l'adresse source de mon paquet.

204
00:11:44,100 --> 00:11:49,320
 à quelque chose de complètement
 faux, comme 12, 12, 12, 12.

205
00:11:49,320 --> 00:11:51,060
 Eh bien, cela s'est présenté
 sous cette interface.

206
00:11:51,060 --> 00:11:53,580
 C'est arrivé rapidement, Ethan,
 à 00 sur le routeur.

207
00:11:53,580 --> 00:11:57,720
 D'après la table de routage de ce routeur,
 explique-t-il, pour atteindre le 12, 12

208
00:11:57,720 --> 00:12:01,120
 réseau, je n'irais pas vite Ethan à 00.

209
00:12:01,120 --> 00:12:03,740
 Je sortirais au numéro 11.

210
00:12:03,740 --> 00:12:08,120
 Donc, si cet administrateur réseau a configuré
 la vérification RPF unicast dans

211
00:12:08,120 --> 00:12:11,260
 Le routeur dira : « Il y a un
 problème avec ce paquet. »

212
00:12:11,260 --> 00:12:15,660
 En suivant mon itinéraire inverse, je ne
 passerais pas par là pour arriver à 12.

213
00:12:15,660 --> 00:12:16,700
 Je prendrais ce chemin.

214
00:12:16,700 --> 00:12:21,280
 Le paquet est arrivé par la mauvaise
 interface et sera donc abandonné.

215
00:12:21,280 --> 00:12:22,340
 Il serait jeté.

216
00:12:22,340 --> 00:12:25,760
 Et donc, mon serveur ne recevrait
 jamais ce paquet.

217
00:12:25,760 --> 00:12:27,980
 Cela ne nuirait jamais au serveur.

218
00:12:27,980 --> 00:12:29,900
 Cette option n'est pas
 activée par défaut.

219
00:12:29,900 --> 00:12:33,580
 La vérification RPF unicast est une fonctionnalité que vous
 devez activer si vous souhaitez effectuer cette opération.

220
00:12:33,580 --> 00:12:36,840
 Ça. Bon, quel rapport avec ça ?

221
00:12:36,840 --> 00:12:43,420
 Lorsque vous activez le multicast, les protocoles de routage
 multicast effectuent des vérifications RPF sur

222
00:12:43,420 --> 00:12:45,780
 la source par défaut.

223
00:12:45,780 --> 00:12:48,140
 En réalité, vous ne pouvez pas
 les empêcher de le faire.

224
00:12:48,140 --> 00:12:50,400
 Ils font ça. Mais pourquoi font-ils ça ?

225
00:12:50,400 --> 00:12:52,940
 Ils le font pour la détection de boucles.

226
00:12:52,940 --> 00:12:56,240
 L'idée est que, lorsqu'un paquet multicast arrive,
 il ne faut pas simplement tourner en rond.

227
00:12:56,240 --> 00:12:58,600
 autour du réseau pour toujours.

228
00:12:58,600 --> 00:13:04,280
 Les routeurs indiquent donc : « Le routeur
 fonctionne en mode clairsemé. »

229
00:13:04,280 --> 00:13:08,840
 protocoles. Donc, si je suis un routeur au sein
 d'un réseau, disons simplement que je suis

230
00:13:08,840 --> 00:13:09,700
 la passerelle par défaut.

231
00:13:09,700 --> 00:13:14,020
 Je suis la passerelle connectée à ce récepteur,
 à mon ordinateur portable juste ici.

232
00:13:14,020 --> 00:13:18,800
 Et je viens d'être informé via IGMP
 que ce récepteur souhaite recevoir

233
00:13:18,800 --> 00:13:22,240
 diffusion multiple. 239-777.

234
00:13:22,240 --> 00:13:27,780
 Faisons un schéma pour que ce soit clair.

235
00:13:27,780 --> 00:13:39,460
 D'accord. Alors, voilà… oh,
 attendez une seconde.

236
00:13:39,460 --> 00:13:42,820
 Je vais donc procéder ainsi.

237
00:13:42,820 --> 00:13:47,540
 Voici mon récepteur, juste
 ici, de forme carrée.

238
00:13:47,540 --> 00:13:50,920
 Nous allons écrire cela avec un petit R.

239
00:13:50,920 --> 00:13:58,180
 Et voici la passerelle par défaut
 à laquelle il est connecté.

240
00:13:58,180 --> 00:14:01,940
 Passerelle par défaut.

241
00:14:01,940 --> 00:14:08,900
 Et il dispose de plusieurs
 interfaces en amont.

242
00:14:08,900 --> 00:14:14,720
 Nous dirons simplement interface
 un, deux et trois.

243
00:14:14,720 --> 00:14:16,320
 Peu importe ce qu'ils sont.

244
00:14:16,320 --> 00:14:19,840
 La connexion série Fast Ethernet n'est
 pas pertinente pour cette discussion.

245
00:14:19,840 --> 00:14:27,300
 Ce routeur vient de recevoir un rapport
 d'appartenance IGMP de la part de

246
00:14:27,300 --> 00:14:39,060
 récepteur. Et ce récepteur souhaite capter
 le trafic destiné au port 239-777.

247
00:14:39,060 --> 00:14:41,740
 C'est le groupe auquel
 il souhaite participer.

248
00:14:41,740 --> 00:14:46,020
 Ce routeur utilise actuellement un protocole
 de routage en mode clairsemé.

249
00:14:46,020 --> 00:14:47,280
 On va donc dire que c'est PIM.

250
00:14:47,280 --> 00:14:51,420
 Il utilise le protocole de routage
 multicast indépendant du protocole.

251
00:14:51,420 --> 00:14:54,120
 Donc, dans le cadre de PIM, pour que PIM fonctionne,
 il dit : « D'accord, je sais. »

252
00:14:54,120 --> 00:14:55,420
 Il y a un routeur quelque part.

253
00:14:55,420 --> 00:15:00,660
 On appellera ça ici, tout au fond,
 c'est mon point de rendez-vous.

254
00:15:00,660 --> 00:15:04,140
 Je dois donc informer le point de
 rendez-vous que j'ai un récepteur.

255
00:15:04,140 --> 00:15:05,860
 Qui ici-bas veut ça ?

256
00:15:05,860 --> 00:15:10,240
 Disons donc que ce point
 de rendez-vous est 8888.

257
00:15:10,240 --> 00:15:14,580
 Alors ce routeur, dit-il,
 d'accord, je sais.

258
00:15:14,580 --> 00:15:17,400
 Faisons juste une petite
 bulle de pensée ici.

259
00:15:17,400 --> 00:15:22,220
 Il dit : « Je sais que
 le PIM RP est 8888. »

260
00:15:22,220 --> 00:15:26,960
 Maintenant, dit-il, d'accord,
 comment accéder au PIM RP ?

261
00:15:26,960 --> 00:15:30,260
 C'est ici qu'il utilise son protocole
 de routage unicast.

262
00:15:30,260 --> 00:15:35,100
 J'ai mentionné à plusieurs reprises que le routage
 multicast fonctionne de concert avec

263
00:15:35,100 --> 00:15:36,920
 votre protocole de routage unicast.

264
00:15:36,920 --> 00:15:39,560
 Alors il dit : « OK, laissez-moi
 accéder à ma table de routage. »

265
00:15:39,560 --> 00:15:42,980
 Et selon ma table de routage, j'ai
 une route EI-JRP qui indique

266
00:15:42,980 --> 00:15:49,800
 pour accéder au réseau 8.8,
 c'est via l'interface 2.

267
00:15:49,800 --> 00:15:56,920
 Il envoie donc une requête
 PIM join out interface 2.

268
00:15:56,920 --> 00:16:04,620
 Et finalement, cette connexion PIM se
 propage à travers le réseau et obtient

269
00:16:04,620 --> 00:16:06,420
 jusqu'au point de rendez-vous.

270
00:16:06,420 --> 00:16:09,840
 Donc, il s'agit maintenant de l'arbre
 partagé, n'est-ce pas ?

271
00:16:09,840 --> 00:16:14,600
 Voici l'arbre de décision allant du point de
 rendez-vous jusqu'à la passerelle par défaut.

272
00:16:14,600 --> 00:16:19,960
 Maintenant, cette passerelle par défaut, puisqu'il
 exécute PIMS en mode clairsemé, dit-il,

273
00:16:19,960 --> 00:16:27,080
 D'accord, je m'attends à ce que lorsque la multidiffusion
 démarrera, quel que soit le moment où elle démarrera,

274
00:16:27,080 --> 00:16:31,260
 Il devrait descendre du
 point de rendez-vous.

275
00:16:31,260 --> 00:16:35,640
 Supposons donc que la diffusion
 multicast démarre, et voilà.

276
00:16:35,640 --> 00:16:38,680
 Voilà comment ça se passe.

277
00:16:38,680 --> 00:16:44,540
 La source est donc 7777.

278
00:16:44,540 --> 00:16:48,660
 La destination est 239.777.

279
00:16:48,660 --> 00:16:54,700
 Eh bien, comme ce type utilise le mode clairsemé
 de PIMS, il effectue une vérification RPF.

280
00:16:54,700 --> 00:16:55,660
 Voici comment ça fonctionne.

281
00:16:55,660 --> 00:17:01,200
 Il dit, eh bien, parce que je m'attendais à ce que
 cette diffusion multiple arrive par le biais de

282
00:17:01,200 --> 00:17:06,740
 point de rendez-vous, dit-il, par quelle
 interface aurait-il dû arriver ?

283
00:17:06,740 --> 00:17:10,820
 Eh bien, d'après mon itinéraire, pour
 arriver au point de rendez-vous, je

284
00:17:10,820 --> 00:17:12,540
 Passer par l'interface 2.

285
00:17:12,540 --> 00:17:16,860
 Tiens, ce flux multicast n'est pas
 parvenu du point de rendez-vous.

286
00:17:16,860 --> 00:17:19,000
 Cela ne provenait pas de l'interface 2.

287
00:17:19,000 --> 00:17:21,820
 Alors devinez quoi ? Je vais le tuer.

288
00:17:21,820 --> 00:17:24,240
 Il s'agit d'une défaillance RPF.

289
00:17:24,240 --> 00:17:29,080
 Il n'est pas descendu de ce que nous appelons
 l'arbre commun, l'arbre qui est partagé

290
00:17:29,080 --> 00:17:31,620
 entre le point de rendez-vous et
 cette passerelle par défaut.

291
00:17:31,620 --> 00:17:35,460
 Le test RPF a échoué.

292
00:17:35,460 --> 00:17:38,740
 Imaginons maintenant que cela se
 soit produit de cette façon.

293
00:17:38,740 --> 00:17:41,820
 D'accord, donc ça a suivi le bon chemin.

294
00:17:41,820 --> 00:17:43,960
 Le contrôle RPF réussirait.

295
00:17:43,960 --> 00:17:48,020
 Ça passerait. Il dirait : « D'accord, ce
 groupe m'intéresse », et ça marcherait.

296
00:17:48,020 --> 00:17:52,640
 Connectez-vous via l'interface appropriée,
 l'interface 2, qui est l'interface

297
00:17:52,640 --> 00:17:55,100
 menant au RP.

298
00:17:55,100 --> 00:17:56,760
 Et là, il se passe quelque
 chose d'intéressant.

299
00:17:56,760 --> 00:17:58,480
 Alors, remettons-le simplement en place.

300
00:17:58,480 --> 00:18:04,080
 Source : 777. Destination : 239,777.

301
00:18:04,080 --> 00:18:09,460
 D'accord, il peut donc transmettre ce flux
 multicast au client, au destinataire.

302
00:18:09,460 --> 00:18:14,760
 Et maintenant, pour la toute première fois,
 ce routeur dit : « Ah, enfin, je sais qui… »

303
00:18:14,760 --> 00:18:21,480
 La source est : L'adresse
 réelle du serveur est 777.

304
00:18:21,480 --> 00:18:25,860
 PIMS-SPAR-SMO indique maintenant : « D'accord, je peux continuer
 à recevoir ces informations du point de rendez-vous. »

305
00:18:25,860 --> 00:18:28,640
 Certes, mais existe-t-il
 une meilleure solution ?

306
00:18:28,640 --> 00:18:32,880
 Existe-t-il un chemin plus court pour atteindre
 cette source qui serait plus avantageux ?

307
00:18:32,880 --> 00:18:36,900
 Efficace ? Il retourne donc
 à sa table de routage.

308
00:18:36,900 --> 00:18:42,140
 Il dit : « D'accord, laissez-moi faire
 une recherche RPF là-dessus. »

309
00:18:42,140 --> 00:18:48,060
 Et il dit : « Oh, figurez-vous que j'ai un
 itinéraire qui correspond à ça, à ça… »

310
00:18:48,060 --> 00:18:49,880
 J'ai appris grâce à EIGRP.

311
00:18:49,880 --> 00:18:52,620
 Là encore, cela pourrait être
 appris via RIP ou OSPF.

312
00:18:52,620 --> 00:18:58,240
 Ça nous est égal. Il dit que
 ça se fait via l'interface 1.

313
00:18:58,240 --> 00:19:00,740
 PIM fait donc maintenant
 quelque chose de spécial.

314
00:19:00,740 --> 00:19:04,940
 Il envoie une autre requête
 PIM de cette manière.

315
00:19:04,940 --> 00:19:09,720
 Nous allons entrer dans les détails.

316
00:19:09,720 --> 00:19:17,340
 Et il dit : ceci est pour la source
 777 destination 239.777.

317
00:19:17,340 --> 00:19:21,820
 Et cette jonction PIM
 remonte jusqu'en haut.

318
00:19:21,820 --> 00:19:25,960
 Et supposons que la source
 soit juste ici.

319
00:19:25,960 --> 00:19:31,360
 C'est là que se trouve le serveur.

320
00:19:31,360 --> 00:19:34,540
 Et il y a eu tout un tas
 de routeurs au milieu.

321
00:19:34,540 --> 00:19:36,000
 Voici donc un routeur.

322
00:19:36,000 --> 00:19:37,760
 Voici un routeur.

323
00:19:37,760 --> 00:19:38,940
 Et voici un routeur.

324
00:19:38,940 --> 00:19:41,000
 Et ils sont tous connectés
 de cette manière.

325
00:19:41,000 --> 00:19:47,760
 En supposant que tous ces routeurs sachent
 comment accéder au réseau 777, cela

326
00:19:47,760 --> 00:19:52,620
 Une jonction PIM spéciale aurait permis de remonter
 jusqu'au bout et d'atteindre finalement

327
00:19:52,620 --> 00:19:55,560
 ce routeur qui est connecté à la source.

328
00:19:55,560 --> 00:19:59,240
 Et cela a maintenant permis de découvrir
 l'arbre des chemins les plus courts.

329
00:19:59,240 --> 00:20:00,780
 Remarquez que nous avons ici
 deux arbres différents.

330
00:20:00,780 --> 00:20:04,520
 Nous avons le bleu et le vert.

331
00:20:04,520 --> 00:20:08,560
 Et le point bleu vers la passerelle par
 défaut était appelé l'arbre partagé

332
00:20:08,560 --> 00:20:11,280
 ou parfois appelé arbre RP.

333
00:20:11,280 --> 00:20:14,400
 Vous pourriez parfois rencontrer
 l'acronyme RPT.

334
00:20:14,400 --> 00:20:19,240
 Cela a fonctionné, mais ce n'est peut-être
 pas la méthode la plus efficace.

335
00:20:19,240 --> 00:20:23,720
 Cet arbre vert est l'arbre
 du chemin le plus court.

336
00:20:23,720 --> 00:20:28,320
 Mais nous ne savions pas de quoi il s'agissait
 tant que nous n'en connaissions pas la source.

337
00:20:28,320 --> 00:20:31,140
 Nous avons reçu notre tout
 premier paquet multicast.

338
00:20:31,140 --> 00:20:35,360
 Et maintenant que nous avons ouvert
 cet arbre, le routeur dit : « OK, »

339
00:20:35,360 --> 00:20:42,380
 À ce moment précis, pendant un bref instant, la prochaine
 fois que je recevrai le multicast, ce sera différent.

340
00:20:42,380 --> 00:20:45,660
 Le paquet pourrait provenir
 de deux endroits différents.

341
00:20:45,660 --> 00:20:50,200
 Je l'accepterai sur l'interface deux
 car il pourrait encore provenir de

342
00:20:50,200 --> 00:20:51,800
 le point de rendez-vous.

343
00:20:51,800 --> 00:20:55,680
 Et maintenant, même si cela se fait via l'interface
 1, je l'accepterai aussi parce que je

344
00:20:55,680 --> 00:20:57,000
 j'ai essayé d'ouvrir ce passage.

345
00:20:57,000 --> 00:21:01,560
 J'ai intentionnellement essayé d'ouvrir ce
 chemin en espérant que le trafic multicast

346
00:21:01,560 --> 00:21:04,100
 descendra par ici.

347
00:21:04,100 --> 00:21:09,320
 Donc maintenant, si le flux multicast arrive sur
 l'interface trois, il s'agira d'un échec RPF.

348
00:21:09,320 --> 00:21:12,660
 Parce que le routeur dit : « Hé, interface
 trois, ce n'est pas l'arbre partagé. »

349
00:21:12,660 --> 00:21:16,180
 et ce n'est pas l'arbre
 de chemin le plus court.

350
00:21:16,180 --> 00:21:20,720
 Mais dans les deux cas, ça
 passera le contrôle RPF.

351
00:21:20,720 --> 00:21:25,920
 Et une fois que le flux multicast commence effectivement
 à circuler et à arriver sur l'interface

352
00:21:25,920 --> 00:21:30,500
 Premièrement, la passerelle par
 défaut dira : « Super ! »

353
00:21:30,500 --> 00:21:33,940
 Je reçois le trafic multicast de la
 manière la plus efficace possible.

354
00:21:33,940 --> 00:21:36,260
 via l'arbre des chemins les plus courts.

355
00:21:36,260 --> 00:21:39,340
 Je n'ai plus besoin de le récupérer
 au point de rendez-vous.

356
00:21:39,340 --> 00:21:44,380
 Il enverra donc un message de purge PIM par ici,
 ce qui permettra de purger les ressources.

357
00:21:44,380 --> 00:21:51,460
 de cet arbre. Et maintenant, le flux multicast
 empruntera le chemin le plus court.

358
00:21:51,460 --> 00:21:56,100
 L'arborescence des chemins jusqu'à ce
 que le destinataire n'en veuille plus.

359
00:21:56,100 --> 00:21:59,760
 Voilà donc, en résumé, le fonctionnement
 du mode clairsemé de PIM.

360
00:21:59,760 --> 00:22:04,280
 Mais j'ai fait tout ça pour vous montrer
 que les contrôles RPF sont bien en cours.

361
00:22:04,280 --> 00:22:09,860
 Tout dépend de l'endroit d'où le routeur
 s'attend à recevoir le flux multicast.

362
00:22:09,860 --> 00:22:13,480
 S'il s'attend à ce que cela vienne
 du point de rendez-vous, il va

363
00:22:13,480 --> 00:22:17,860
 Disons, regarde, le point de rendez-vous se trouve
 sur l'interface un ou l'interface sept,

364
00:22:17,860 --> 00:22:20,640
 et il l'apprend grâce à son
 protocole de routage.

365
00:22:20,640 --> 00:22:24,280
 C'est là que je m'attends à recevoir
 le multicast initialement.

366
00:22:24,280 --> 00:22:27,800
 Si ça vient d'une autre interface,
 je vais la supprimer.

367
00:22:27,800 --> 00:22:28,820
 Je vais laisser tomber.

368
00:22:28,820 --> 00:22:31,340
 Ça ne devait pas se passer comme ça.

369
00:22:31,340 --> 00:22:34,880
 Mais une fois qu'il connaît la source
 et qu'il essaie d'ouvrir ce plus court

370
00:22:34,880 --> 00:22:39,500
 Arborescence de chemin, maintenant
 le RPF va réussir.

371
00:22:39,500 --> 00:22:46,420
 Cela passera si le flux multicast emprunte le
 chemin le plus court dans l'arbre de décision.

372
00:22:46,420 --> 00:22:51,840
 Comment déterminer l'interface
 d'entrée appropriée ?

373
00:22:51,840 --> 00:22:56,480
 Comment s'assurer que le RPF réussit
 ou est validé en fonction du type

374
00:22:56,480 --> 00:22:58,800
 de l'arbre que nous attendons ?

375
00:22:58,800 --> 00:23:02,460
 S'attend-on à ce que cela se produise au niveau
 de l'arbre principal, autrement dit le

376
00:23:02,460 --> 00:23:09,940
 Arbre RP ? Ou bien attendons-nous à ce que
 ce trafic provienne de l’arbre source ?

377
00:23:09,940 --> 00:23:16,400
 Cela peut maintenant dépendre
 du type spécifique d'IGP.

378
00:23:16,400 --> 00:23:18,620
 De quoi est-ce que je parle ?

379
00:23:18,620 --> 00:23:21,980
 PIM n'est pas le seul protocole
 de routage multicast.

380
00:23:21,980 --> 00:23:22,800
 Il y en a d'autres.

381
00:23:22,800 --> 00:23:27,120
 Par exemple, MOSPF, OSPF multicast.

382
00:23:27,120 --> 00:23:31,440
 Vous pouvez probablement deviner si j'utilise
 OSPF multicast pour comprendre

383
00:23:31,440 --> 00:23:35,140
 déterminer quelle est l'interface correcte
 pour accéder au RP, ou l'interface correcte

384
00:23:35,140 --> 00:23:39,480
 Pour accéder à la source, il
 utilise les routes OSPF.

385
00:23:39,480 --> 00:23:44,120
 MOSPF ne peut pas effectuer de vérification
 RPF basée sur RIP ou EIGRP.

386
00:23:44,120 --> 00:23:50,500
 Il nécessite OSPF. Il en existe un autre
 appelé DVMRP (Distance Vector Multicast).

387
00:23:50,500 --> 00:23:51,940
 Protocole de routage.

388
00:23:51,940 --> 00:23:53,120
 Celui-là est un peu bizarre.

389
00:23:53,120 --> 00:23:59,660
 Il construit en fait sa propre table unicast distincte
 uniquement pour effectuer des vérifications RPF.

390
00:23:59,660 --> 00:24:01,140
 Le tableau DVMRP.

391
00:24:01,140 --> 00:24:02,920
 Il n'utilise rien d'autre.

392
00:24:02,920 --> 00:24:08,720
 Ce qui est formidable avec le PIM, c'est
 le multicast indépendant du protocole.

393
00:24:08,720 --> 00:24:13,000
 L'indépendance du protocole signifie
 que PIM dit : « Je m'en fiche. »

394
00:24:13,000 --> 00:24:16,100
 Lorsque j'effectue une vérification RPF,
 je vais consulter la table de routage.

395
00:24:16,100 --> 00:24:19,960
 Peu m'importe de trouver un itinéraire
 statique ou connecté.

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

397
00:24:21,540 --> 00:24:27,160
 Ça m'est égal. Du moment que je trouve de
 quoi effectuer mes vérifications RPF,

398
00:24:27,160 --> 00:24:32,040
 Je serai content. C'est pourquoi le PIM est
 si populaire, car il vous permet d'utiliser

399
00:24:32,040 --> 00:24:35,100
 n'importe quel protocole de
 routage IGP de votre choix.

400
00:24:35,100 --> 00:24:36,860
 Cela n'en dépend pas.