Le protocole PIM est un ensemble de protocoles permettant de transmettre du multicast dans un réseau entre routeurs. Les relations de voisinage se construisent de la même manière que dans le cas des protocoles de routage dynamique. PIMv2 envoie des messages Hello toutes les 30 secondes à l'adresse de multidiffusion réservée 224.0.0.13 (All-PIM-Routers). Le message contient des minuteries d'attente - généralement égales à 3.5*Hello Timer, soit 105 secondes par défaut.
PIM utilise deux modes de fonctionnement principaux : le mode Dense et Sparse. Commençons par le mode Dense.
Arbres de distribution basés sur la source.
Il est conseillé d'utiliser le mode Dense-Mode dans le cas d'un grand nombre de clients de différents groupes de multidiffusion. Lorsqu'un routeur reçoit du trafic de multidiffusion, la première chose qu'il fait est de vérifier la règle RPF. RPF - cette règle est utilisée pour vérifier la source d'une multidiffusion avec une table de routage unicast. Il faut que le trafic arrive à l'interface derrière laquelle cet hôte est caché selon la version de la table de routage unicast. Ce mécanisme résout le problème d'une boucle se produisant lors d'une transmission multicast.
R3 reconnaîtra la source de multidiffusion (Source IP) à partir du message de multidiffusion et vérifiera les deux flux de R1 et R2 à l'aide de sa table de monodiffusion. Le flux de l'interface indiquée par la table (R1 à R3) sera transmis davantage et le flux de R2 sera abandonné, car pour accéder à la source de multidiffusion, vous devez envoyer des paquets via S0/1.
La question est : que se passe-t-il si vous avez deux itinéraires équivalents avec la même métrique ? Dans ce cas, le routeur sélectionnera le prochain saut parmi ces routes. Celui qui possède l’adresse IP la plus élevée gagne. Si vous devez modifier ce comportement, vous pouvez utiliser ECMP. Plus de détails .
Après avoir vérifié la règle RPF, le routeur envoie un paquet multicast à tous ses voisins PIM, à l'exception de celui dont le paquet a été reçu. D'autres routeurs PIM répètent ce processus. Le chemin emprunté par un paquet de multidiffusion depuis la source jusqu'aux destinataires finaux forme une arborescence appelée arborescence de distribution basée sur la source, arborescence du chemin le plus court (SPT), arborescence source. Trois noms différents, choisissez-en un.
Comment résoudre le problème selon lequel certains routeurs n'ont pas abandonné certains flux de multidiffusion et qu'il n'y a personne à qui l'envoyer, mais le routeur en amont le lui envoie. Le mécanisme Prune a été inventé pour cela.
Message de taille.
Par exemple, R2 continuera à envoyer une multidiffusion à R3, bien que R3, selon la règle RPF, l'abandonne. Pourquoi charger la chaîne ? R3 envoie un message PIM Prune et R2, à la réception de ce message, supprimera l'interface S0/1 de la liste des interfaces sortantes pour ce flux, la liste des interfaces à partir desquelles ce trafic doit être envoyé.
Ce qui suit est une définition plus formelle d'un message PIM Prune :
Le message PIM Prune est envoyé par un routeur à un deuxième routeur pour amener le deuxième routeur à supprimer la liaison sur laquelle le Prune est reçu d'un SPT (S, G) particulier.
Après avoir reçu le message Prune, R2 règle la minuterie Prune sur 3 minutes. Après trois minutes, il recommencera à envoyer du trafic jusqu'à ce qu'il reçoive un autre message Prune. C'est dans PIMv1.
Et dans PIMv2, une minuterie d'actualisation d'état a été ajoutée (60 secondes par défaut). Dès qu'un message Prune a été envoyé depuis R3, ce timer est démarré sur R3. À l'expiration de ce minuteur, R3 enverra un message State Refresh, qui réinitialisera le minuteur d'élagage de 3 minutes sur R2 pour ce groupe.
Raisons de l’envoi d’un message Prune :
- Lorsqu'un paquet multicast échoue à la vérification RPF.
- Lorsqu'aucun client connecté localement n'a demandé un groupe de multidiffusion (rejoindre IGMP) et qu'il n'y a aucun voisin PIM auquel le trafic de multidiffusion peut être envoyé (interface sans élagage).
Message de greffe.
Imaginons que R3 ne veut pas de trafic de R2, envoie Prune et reçoive une multidiffusion de R1. Mais tout à coup, le canal entre R1 et R3 est tombé et R3 s'est retrouvé sans multidiffusion. Vous pouvez attendre 3 minutes jusqu'à ce que la minuterie d'élagage sur R2 expire. 3 minutes, c'est une longue attente, pour ne pas attendre, vous devez envoyer un message qui fera instantanément sortir cette interface S0/1 de R2 de l'état élagué. Ce message sera un message Graft. Après avoir reçu le message Graft, R2 répondra par un Graft-ACK.
Élaguer le remplacement.
Regardons ce diagramme. R1 diffuse la multidiffusion vers un segment avec deux routeurs. R3 reçoit et diffuse le trafic, R2 le reçoit, mais n'a personne à qui diffuser le trafic. Il envoie un message Prune à R1 dans ce segment. R1 devrait supprimer Fa0/0 de la liste et arrêter de diffuser dans ce segment, mais qu'arrivera-t-il à R3 ? Et R3 est dans le même segment, a également reçu ce message de Prune et a compris le drame de la situation. Avant que R1 n'arrête de diffuser, il règle une minuterie de 3 secondes et arrêtera de diffuser après 3 secondes. 3 secondes - c'est exactement le temps dont dispose R3 pour ne pas perdre son multicast. Par conséquent, R3 envoie un message Pim Join pour ce groupe dès que possible, et R1 ne pense plus à arrêter la diffusion. À propos de Rejoignez les messages ci-dessous.
Message d’affirmation.
Imaginons cette situation : deux routeurs diffusent simultanément sur un réseau. Ils reçoivent le même flux de la source et le diffusent tous deux sur le même réseau derrière l'interface e0. Ils doivent donc déterminer qui sera le seul et unique diffuseur de ce réseau. Les messages d'assertion sont utilisés à cet effet. Lorsque R2 et R3 détectent une duplication du trafic multicast, c'est-à-dire que R2 et R3 reçoivent une multidiffusion qu'ils diffusent eux-mêmes, les routeurs comprennent que quelque chose ne va pas ici. Dans ce cas, les routeurs envoient des messages d'assertion, qui incluent la distance administrative et la métrique de route avec laquelle la source de multidiffusion est atteinte - 10.1.1.10. Le gagnant est déterminé comme suit :
- Celui avec une AD inférieure.
- Si AD est égal, alors qui a la métrique la plus basse.
- S'il y a égalité ici, alors celui qui a l'IP la plus élevée dans le réseau sur lequel il diffuse cette multidiffusion.
Le gagnant de ce vote devient le routeur désigné. Pim Hello est également utilisé pour sélectionner les DR. Au début de l'article, le message PIM Hello était affiché, vous pouvez y voir le champ DR. Celui qui a l'adresse IP la plus élevée sur ce lien gagne.
Signe utile :
Tableau MROUTE.
Après un premier aperçu du fonctionnement du protocole PIM, nous devons comprendre comment travailler avec une table de routage multicast. La table mroute stocke des informations sur les flux demandés aux clients et les flux provenant des serveurs de multidiffusion.
Par exemple, lorsqu'un rapport d'adhésion IGMP ou une jointure PIM est reçu sur une interface, un enregistrement de type ( *, G ) est ajouté à la table de routage :
Cette entrée signifie qu'une demande de trafic a été reçue avec l'adresse 238.38.38.38. L'indicateur DC signifie que la multidiffusion fonctionnera en mode Dense et C signifie que le destinataire est directement connecté au routeur, c'est-à-dire que le routeur a reçu le rapport d'adhésion IGMP et la jointure PIM.
S'il existe un enregistrement de type (S,G), cela signifie que nous avons un flux multicast :
Dans le champ S - 192.168.1.11, nous avons enregistré l'adresse IP de la source multicast, c'est elle qui sera vérifiée par la règle RPF. En cas de problèmes, la première chose à faire est de vérifier la table de monodiffusion pour connaître l'itinéraire vers la source. Dans le champ Interface entrante, indique l'interface sur laquelle la multidiffusion est reçue. Dans une table de routage unicast, la route vers la source doit faire référence à l'interface spécifiée ici. L'interface sortante spécifie où la multidiffusion sera redirigée. S'il est vide, cela signifie que le routeur n'a reçu aucune demande pour ce trafic. Plus d'informations sur tous les drapeaux peuvent être trouvées .
Mode PIM clairsemé.
La stratégie du mode Sparse est à l’opposé du mode Dense. Lorsque le mode Sparse reçoit du trafic de multidiffusion, il enverra uniquement le trafic via les interfaces où il y a eu des demandes pour ce flux, par exemple des messages Pim Join ou IGMP Report demandant ce trafic.
Éléments similaires pour SM et DM :
- Les relations de voisinage se construisent de la même manière que dans PIM DM.
- La règle RPF fonctionne.
- La sélection DR est similaire.
- Le mécanisme des messages Prune Overrides et Assert est similaire.
Pour contrôler qui, où et quel type de trafic multicast est nécessaire sur le réseau, un centre d'information commun est nécessaire. Notre centre sera Rendezvous Point (RP). Quiconque souhaite une sorte de trafic multicast ou quelqu'un qui commence à recevoir du trafic multicast de la source, l'envoie ensuite au RP.
Lorsque le RP reçoit du trafic de multidiffusion, il l'envoie aux routeurs qui ont précédemment demandé ce trafic.
Imaginons une topologie où RP est R3. Dès que R1 reçoit du trafic de S1, il encapsule ce paquet multicast dans un message de registre PIM unicast et l'envoie au RP. Comment sait-il qui est le RP ? Dans ce cas, il est configuré de manière statique, et nous parlerons plus tard de configuration dynamique du RP.
adresse IP pim rp 3.3.3.3
RP va regarder : y a-t-il eu des informations provenant de quelqu'un qui aimerait recevoir ce trafic ? Supposons que ce ne soit pas le cas. Ensuite, RP enverra à R1 un message PIM Register-Stop, ce qui signifie que personne n'a besoin de cette multidiffusion, l'enregistrement est refusé. R1 n’enverra pas de multidiffusion. Mais l'hôte source de multidiffusion l'enverra, de sorte que R1, après avoir reçu Register-Stop, démarrera un temporisateur de suppression de registre égal à 60 secondes. 5 secondes avant l'expiration de ce temporisateur, R1 enverra un message de registre vide avec un bit de registre nul (c'est-à-dire sans paquet multicast encapsulé) vers RP. RP, à son tour, agira comme ceci :
- S'il n'y avait aucun destinataire, il répondra par un message Register-Stop.
- Si des destinataires apparaissent, il n'y répondra en aucun cas. R1, n'ayant pas reçu de refus d'enregistrement dans les 5 secondes, se contentera d'envoyer un message Register avec une multidiffusion encapsulée à RP.
Nous semblons avoir compris comment la multidiffusion atteint RP, essayons maintenant de répondre à la question de savoir comment RP achemine le trafic aux destinataires. Ici, il est nécessaire d'introduire un nouveau concept - l'arbre des chemins racines (RPT). RPT est un arbre enraciné dans RP, grandissant vers les destinataires, se ramifiant sur chaque routeur PIM-SM. RP le crée en recevant des messages PIM Join et ajoute une nouvelle branche à l'arborescence. Et c’est le cas de tous les routeurs en aval. La règle générale ressemble à ceci :
- Lorsqu'un routeur PIM-SM reçoit un message PIM Join sur une interface autre que celle derrière laquelle le RP est caché, il ajoute une nouvelle branche à l'arborescence.
- Une branche est également ajoutée lorsque le routeur PIM-SM reçoit un rapport d'adhésion IGMP d'un hôte directement connecté.
Imaginons que nous ayons un client multicast sur le routeur R5 pour le groupe 228.8.8.8. Dès que R5 reçoit le rapport d'adhésion IGMP de l'hôte, R5 envoie une jointure PIM en direction du RP et ajoute lui-même une interface à l'arborescence qui examine l'hôte. Ensuite, R4 reçoit PIM Join de R5, ajoute l'interface Gi0/1 à l'arborescence et envoie PIM Join en direction de RP. Enfin, RP ( R3 ) reçoit PIM Join et ajoute Gi0/0 à l'arborescence. Ainsi, le destinataire de multidiffusion est enregistré. Nous construisons un arbre de racine R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Après cela, une jointure PIM sera envoyée à R1 et R1 commencera à envoyer du trafic de multidiffusion. Il est important de noter que si l'hôte a demandé du trafic avant le début de la diffusion multicast, alors RP n'enverra pas PIM Join et n'enverra rien du tout à R1.
Si soudainement pendant l'envoi d'un multicast, l'hôte cesse de vouloir la recevoir, dès que RP reçoit un PIM Prune sur l'interface Gi0/0, il enverra immédiatement un PIM Register-Stop directement à R1, puis un PIM Prune via l'interface Gi0/1. L'arrêt du registre PIM est envoyé par monodiffusion à l'adresse d'où provient le registre PIM.
Comme nous l'avons dit précédemment, dès qu'un routeur envoie un PIM Join à un autre, par exemple R5 à R4, alors un enregistrement est ajouté à R4 :
Et une minuterie est démarrée selon laquelle R5 doit constamment réinitialiser cette minuterie. PIM Join messages constamment, sinon R4 sera exclu de la liste sortante. R5 enverra tous les 60 messages PIM Join.
Basculement de l’arborescence du chemin le plus court.
Nous allons ajouter une interface entre R1 et R5 et voir comment le trafic circule avec cette topologie.
Supposons que le trafic ait été envoyé et reçu selon l'ancien schéma R1-R2-R3-R4-R5, et ici nous avons connecté et configuré l'interface entre R1 et R5.
Tout d'abord, nous devons reconstruire la table de routage unicast sur R5 et maintenant le réseau 192.168.1.0/24 est atteint via l'interface R5 Gi0/2. Maintenant R5, recevant du multicast sur l'interface Gi0/1, comprend que la règle RPF n'est pas satisfaite et qu'il serait plus logique de recevoir du multicast sur Gi0/2. Il doit se déconnecter de RPT et créer une arborescence plus courte appelée Shortest-Path Tree (SPT). Pour ce faire, il envoie PIM Join à R0 via Gi2/1 et R1 commence également à envoyer une multidiffusion via Gi0/2. Désormais, R5 doit se désinscrire de RPT pour ne pas recevoir deux exemplaires. Pour ce faire, il envoie à Prune un message indiquant l'adresse IP source et insérant un bit spécial - RPT-bit. Cela signifie que vous n’avez pas besoin de m’envoyer du trafic, j’ai un meilleur arbre ici. RP envoie également des messages PIM Prune à R1, mais n'envoie pas de message Register-Stop. Autre fonctionnalité : R5 enverra désormais continuellement PIM Prune à RP, tandis que R1 continuera d'envoyer PIM Register à RP toutes les minutes. Jusqu'à ce qu'il n'y ait plus de nouvelles personnes souhaitant ce trafic, RP le refusera. R5 informe RP qu'il continue de recevoir la multidiffusion via SPT.
Recherche dynamique de RP.
Auto-RP.
Cette technologie est la propriété de Cisco et n'est pas particulièrement populaire, mais elle est toujours vivante. Le fonctionnement de l'Auto-RP se compose de deux étapes principales :
1) RP envoie des messages RP-Announce à l'adresse réservée - 224.0.1.39, se déclarant RP soit pour tout le monde, soit pour des groupes spécifiques. Ce message est envoyé toutes les minutes.
2) Un agent de mappage RP est requis, qui enverra des messages RP-Discovery indiquant pour quels groupes quel RP doit être écouté. C’est à partir de ce message que les routeurs PIM classiques détermineront eux-mêmes le RP. L'agent de mappage peut être soit le routeur RP lui-même, soit un routeur PIM distinct. RP-Discovery est envoyé à l'adresse 224.0.1.40 avec une minuterie d'une minute.
Examinons le processus plus en détail :
Configurons R3 en tant que RP :
ip pim send-rp-announce bouclage 0 portée 10
R2 comme agent de cartographie :
ip pim send-rp-discovery bouclage 0 portée 10
Et sur tous les autres nous attendrons du RP via Auto-RP :
ip pim autorp auditeur
Une fois que nous aurons configuré R3, il commencera à envoyer RP-Announce :
Et R2, après avoir configuré l'agent de mappage, commencera à attendre le message RP-Announce. Ce n'est que lorsqu'il trouvera au moins un RP qu'il commencera à envoyer RP-Discovery :
De cette façon, dès que les routeurs classiques (PIM RP Listener) recevront ce message, ils sauront où chercher le RP.
L'un des principaux problèmes avec Auto-RP est que pour recevoir des messages RP-Announce et RP-Discovery, vous devez envoyer PIM Join aux adresses 224.0.1.39-40, et pour envoyer, vous devez savoir où le Le RP est situé. Problème classique de la poule et de l’œuf. Pour résoudre ce problème, le PIM Sparse-Dense-Mode a été inventé. Si le routeur ne connaît pas RP, alors il fonctionne en mode Dense ; si c'est le cas, alors en mode Sparse. Lorsque le mode PIM Sparse et la commande ip pim autorp Listener sont configurés sur les interfaces des routeurs classiques, le routeur fonctionnera en mode Dense uniquement pour la multidiffusion directement à partir du protocole Auto-RP (224.0.1.39-40).
Routeur BootStrap (BSR).
Cette fonction fonctionne de manière similaire à Auto-RP. Chaque RP envoie un message à l'agent de mappage, qui collecte les informations de mappage et en informe ensuite tous les autres routeurs. Décrivons le processus de la même manière qu'Auto-RP :
1) Une fois que nous avons configuré R3 comme candidat pour être RP, avec la commande :
ip pim rp-candidat bouclage 0
Ensuite, R3 ne fera rien : pour commencer à envoyer des messages spéciaux, il doit d'abord trouver un agent cartographique. Ainsi, nous passons à la deuxième étape.
2) Configurez R2 en tant qu'agent de mappage :
ip pim bsr-candidat bouclage 0
R2 commence à envoyer des messages PIM Bootstrap, où il s'indique comme agent de mappage :
Ce message est envoyé à l'adresse 224.0.013, que le protocole PIM utilise également pour ses autres messages. Il les envoie dans toutes les directions et il n’y a donc pas de problème de poule et d’œuf comme il y en avait dans Auto-RP.
3) Dès que le RP reçoit un message du routeur BSR, il enverra immédiatement un message unicast à l'adresse du routeur BSR :
Après quoi, le BSR, ayant reçu des informations sur les RP, les enverra en multicast à l'adresse 224.0.0.13, qui est écoutée par tous les routeurs PIM. Par conséquent, un analogue de la commande ip pim autorp auditeur pour les routeurs réguliers non en BSR.
Anycast RP avec protocole de découverte de source multicast (MSDP).
Auto-RP et BSR nous permettent de répartir la charge sur RP comme suit : Chaque groupe multicast n'a qu'un seul RP actif. Il ne sera pas possible de répartir la charge d'un groupe multicast sur plusieurs RP. MSDP le fait en attribuant aux routeurs RP la même adresse IP avec un masque de 255.255.255.255. MSDP apprend les informations en utilisant l'une des méthodes suivantes : statique, Auto-RP ou BSR.
Sur l'image, nous avons une configuration Auto-RP avec MSDP. Les deux RP sont configurés avec l'adresse IP 172.16.1.1/32 sur l'interface Loopback 1 et sont utilisés pour tous les groupes. Avec RP-Announce, les deux routeurs s'annoncent en faisant référence à cette adresse. L'agent de mappage Auto-RP, après avoir reçu les informations, envoie RP-Discovery sur le RP avec l'adresse 172.16.1.1/32. Nous informons les routeurs du réseau 172.16.1.1/32 en utilisant IGP et, en conséquence. Ainsi, les routeurs PIM demandent ou enregistrent les flux du RP spécifié comme prochain saut sur la route vers le réseau 172.16.1.1/32. Le protocole MSDP lui-même est conçu pour que les RP eux-mêmes échangent des messages sur les informations de multidiffusion.
Considérez cette topologie :
Switch6 diffuse du trafic à l'adresse 238.38.38.38 et jusqu'à présent, seul RP-R1 le sait. Switch7 et Switch8 ont demandé ce groupe. Les routeurs R5 et R4 enverront respectivement PIM Join à R1 et R3. Pourquoi? La route vers 13.13.13.13 pour R5 fera référence à R1 en utilisant la métrique IGP, tout comme pour R4.
RP-R1 connaît le flux et commencera à le diffuser vers R5, mais R4 n'en sait rien, puisque R1 ne se contentera pas de l'envoyer. Le MSDP est donc nécessaire. On le configure sur R1 et R5 :
ip msdp peer 3.3.3.3 connexion-source Loopback1 sur R1
ip msdp peer 1.1.1.1 connexion-source Loopback3 sur R3
Ils ouvriront une session entre eux et lorsqu'ils recevront un flux, ils le signaleront à leur voisin RP.
Dès que le RP-R1 reçoit un flux du Switch6, il enverra immédiatement un message MSDP Source-Active unicast, qui contiendra des informations telles que (S, G) - des informations sur la source et la destination de la multidiffusion. Maintenant que RP-R3 sait qu'une source telle que Switch6, lors de la réception d'une requête de R4 pour ce flux, il enverra PIM Join vers Switch6, guidé par la table de routage. Par conséquent, R1 ayant reçu une telle jointure PIM commencera à envoyer du trafic vers RP-R3.
MSDP fonctionne sur TCP, les RP s'envoient des messages keepalive pour vérifier l'activité. La minuterie est de 60 secondes.
La fonction de division des homologues MSDP en différents domaines reste floue, puisque les messages Keepalive et SA n'indiquent l'appartenance à aucun domaine. De plus, dans cette topologie, nous avons testé une configuration indiquant différents domaines – il n'y avait aucune différence de performances.
Si quelqu'un peut clarifier, je serais heureux de le lire dans les commentaires.
Source: habr.com
