{"id":33142,"date":"2019-10-31T21:50:58","date_gmt":"2019-10-31T18:50:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/printsipy-raboty-protokola-pim\/"},"modified":"2019-10-31T21:50:58","modified_gmt":"2019-10-31T18:50:58","slug":"printsipy-raboty-protokola-pim","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/printsipy-raboty-protokola-pim","title":{"rendered":"Principes de fonctionnement du protocole PIM","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Le protocole PIM est un ensemble de protocoles pour la transmission de multicast sur le r\u00e9seau entre les routeurs. Les relations de voisinage se construisent de mani\u00e8re similaire \u00e0 celle des protocoles de routage dynamiques. PIMv2 envoie tous les 30 secondes des messages Hello \u00e0 l'adresse multicast r\u00e9serv\u00e9e 224.0.0.13 (All-PIM-Routers). Le message contient des Hold Timers \u2014 g\u00e9n\u00e9ralement \u00e9gal \u00e0 3,5 fois le Hello Timer, donc 105 secondes par d\u00e9faut.
\n\"Principes<\/a><\/noindex>
\n PIM utilise deux modes de fonctionnement principaux \u2014 Dense et Sparse mode. Commen\u00e7ons par le Dense mode. <\/a><\/noindex>
\nArbres de distribution bas\u00e9s sur la source.<\/b>
\nLe mode Dense est judicieux \u00e0 utiliser en cas de nombreux clients de diff\u00e9rents groupes multicast. Lorsque le routeur re\u00e7oit du trafic multicast, il v\u00e9rifie d'abord cette r\u00e8gle RPF. RPF \u2014 cette r\u00e8gle est utilis\u00e9e pour v\u00e9rifier la source du multicast avec la table de routage unicast. Le trafic doit arriver sur l'interface derri\u00e8re laquelle se trouve cet h\u00f4te selon la table de routage unicast. Ce m\u00e9canisme r\u00e9sout le probl\u00e8me des boucles lors de la transmission de multicast.
\n \"Principes<\/a><\/noindex>
\nLe routeur R3 d\u00e9couvre la source du multicast (Source IP) et v\u00e9rifie deux flux provenant de R1 et R2 selon sa table de routage unicast. Le flux de l'interface indiqu\u00e9e par la table (R1 vers R3) sera transmis, tandis que le flux de R2 sera rejet\u00e9, car pour atteindre la source du multicast, il faut envoyer des paquets par S0\/1.
\nLa question est de savoir ce qui se passera si vous avez deux chemins \u00e9quivalents avec la m\u00eame m\u00e9trique ? Dans ce cas, le routeur choisira en fonction du next-hop de ces chemins. Celui avec l'adresse IP la plus \u00e9lev\u00e9e est le gagnant. Si vous devez modifier ce comportement, vous pouvez utiliser ECMP. Plus de d\u00e9tails. ici<\/a><\/noindex>.
\nApr\u00e8s v\u00e9rification de la r\u00e8gle RPF, le routeur envoie le paquet multicast \u00e0 tous ses voisins PIM, sauf \u00e0 celui d'o\u00f9 il a re\u00e7u ce paquet. Les autres routeurs PIM r\u00e9p\u00e8tent ce processus. Le chemin que le paquet multicast a emprunt\u00e9 depuis la source jusqu'aux destinataires finaux forme un arbre, appel\u00e9 arbre de distribution bas\u00e9 sur la source, arbre de chemin le plus court (SPT), arbre source. Trois noms diff\u00e9rents, choisissez celui que vous pr\u00e9f\u00e9rez.
\nComment r\u00e9soudre le probl\u00e8me que certains routeurs ne re\u00e7oivent pas un certain flux multicast et qu'il n'y a personne pour l'envoyer, alors que le routeur sup\u00e9rieur lui envoie. Pour cela, le m\u00e9canisme Prune a \u00e9t\u00e9 invent\u00e9.
\nMessage de Prune.<\/b>
\nPar exemple, R2 continuera \u00e0 envoyer des multicasts \u00e0 R3, bien que R3 les ignore selon la r\u00e8gle RPF. Pourquoi surcharger la bande passante ? R3 envoie un message PIM Prune et R2, en recevant ce message, supprimera l'interface S0\/1 de la liste des interfaces sortantes pour ce flux, la liste des interfaces \u00e0 partir desquelles ce trafic doit \u00eatre envoy\u00e9. <\/p>\n

Voici une d\u00e9finition plus formelle d'un message PIM Prune :
\nLe message PIM Prune est envoy\u00e9 par un routeur \u00e0 un second routeur pour amener le second routeur \u00e0 retirer le lien sur lequel le Prune est re\u00e7u d'un SPT (Source, Group).<\/p><\/blockquote>\n

\nApr\u00e8s avoir re\u00e7u le message Prune, R2 d\u00e9finit un minuteur Prune \u00e0 3 minutes. Au bout de trois minutes, il recommencera \u00e0 envoyer du trafic, sauf s'il re\u00e7oit un autre message Prune. Cela fait partie de PIMv1.
\nDans PIMv2, un minuteur State Refresh a \u00e9t\u00e9 ajout\u00e9 (par d\u00e9faut 60 secondes). D\u00e8s qu'un message Prune est envoy\u00e9 de R3, ce minuteur commence sur R3. Une fois ce minuteur \u00e9coul\u00e9, R3 enverra un message State Refresh, qui r\u00e9initialisera le minuteur Prune de 3 minutes sur R2 pour ce groupe.
\nRaisons d'envoyer un message Prune :<\/p>\n