Le protocole PIM est un ensemble de protocoles pour la transmission de multicast sur le réseau entre les routeurs. Les relations de voisinage se construisent de manière similaire à celle des protocoles de routage dynamiques. PIMv2 envoie tous les 30 secondes des messages Hello à l'adresse multicast réservée 224.0.0.13 (All-PIM-Routers). Le message contient des Hold Timers — généralement égal à 3,5 fois le Hello Timer, donc 105 secondes par défaut.
PIM utilise deux modes de fonctionnement principaux — Dense et Sparse mode. Commençons par le Dense mode.
Arbres de distribution basés sur la source.
Le mode Dense est judicieux à utiliser en cas de nombreux clients de différents groupes multicast. Lorsque le routeur reçoit du trafic multicast, il vérifie d'abord cette règle RPF. RPF — cette règle est utilisée pour vérifier la source du multicast avec la table de routage unicast. Le trafic doit arriver sur l'interface derrière laquelle se trouve cet hôte selon la table de routage unicast. Ce mécanisme résout le problème des boucles lors de la transmission de multicast.
Le routeur R3 découvre la source du multicast (Source IP) et vérifie deux flux provenant de R1 et R2 selon sa table de routage unicast. Le flux de l'interface indiquée par la table (R1 vers R3) sera transmis, tandis que le flux de R2 sera rejeté, car pour atteindre la source du multicast, il faut envoyer des paquets par S0/1.
La question est de savoir ce qui se passera si vous avez deux chemins équivalents avec la même métrique ? Dans ce cas, le routeur choisira en fonction du next-hop de ces chemins. Celui avec l'adresse IP la plus élevée est le gagnant. Si vous devez modifier ce comportement, vous pouvez utiliser ECMP. Plus de détails. .
Après vérification de la règle RPF, le routeur envoie le paquet multicast à tous ses voisins PIM, sauf à celui d'où il a reçu ce paquet. Les autres routeurs PIM répètent ce processus. Le chemin que le paquet multicast a emprunté depuis la source jusqu'aux destinataires finaux forme un arbre, appelé arbre de distribution basé sur la source, arbre de chemin le plus court (SPT), arbre source. Trois noms différents, choisissez celui que vous préférez.
Comment résoudre le problème que certains routeurs ne reçoivent pas un certain flux multicast et qu'il n'y a personne pour l'envoyer, alors que le routeur supérieur lui envoie. Pour cela, le mécanisme Prune a été inventé.
Message de Prune.
Par exemple, R2 continuera à envoyer des multicasts à R3, bien que R3 les ignore selon la règle 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 à partir desquelles ce trafic doit être envoyé.
Voici une définition plus formelle d'un message PIM Prune :
Le message PIM Prune est envoyé par un routeur à un second routeur pour amener le second routeur à retirer le lien sur lequel le Prune est reçu d'un SPT (Source, Group).
Après avoir reçu le message Prune, R2 définit un minuteur Prune à 3 minutes. Au bout de trois minutes, il recommencera à envoyer du trafic, sauf s'il reçoit un autre message Prune. Cela fait partie de PIMv1.
Dans PIMv2, un minuteur State Refresh a été ajouté (par défaut 60 secondes). Dès qu'un message Prune est envoyé de R3, ce minuteur commence sur R3. Une fois ce minuteur écoulé, R3 enverra un message State Refresh, qui réinitialisera le minuteur Prune de 3 minutes sur R2 pour ce groupe.
Raisons d'envoyer un message Prune :
- Lorsque le paquet multicast ne passe pas le test RPF.
- Lorsqu'il n'y a pas de clients connectés localement ayant demandé un groupe multicast (IGMP Join) et pas de voisins PIM auxquels envoyer du trafic multicast (Non-prune Interface).
Message Graft.
Imaginons que R3 ne voulait pas du trafic de R2, a envoyé un Prune et recevait du multicast de R1. Mais tout à coup, le canal entre R1 et R3 est tombé, et R3 est resté sans multicast. On peut attendre 3 minutes, jusqu'à ce que le minuteur Prune de R2 expire. Attendre 3 minutes est long, pour ne pas attendre, il est nécessaire d'envoyer un message qui sortira instantanément cette interface S0/1 de R2 de l'état pruned. Ce message sera le message Graft. Après avoir reçu le message Graft, R2 enverra en réponse un Graft-ACK.
Prune Override.
Examinons ce schéma. R1 diffuse du multicast dans un segment avec deux routeurs. R3 reçoit et diffuse le trafic, R2 reçoit, mais il n'y a personne pour le diffuser. Il envoie un message Prune à R1 dans ce segment. R1 doit retirer Fa0/0 de la liste et cesser la diffusion dans ce segment, mais que va-t-il se passer pour R3 ? R3 est dans le même segment, a également reçu ce message Prune et a compris toute la gravité de la situation. Avant que R1 ne cesse de diffuser, il règle un minuteur à 3 secondes et cessera de diffuser dans 3 secondes. 3 secondes — c'est le temps dont dispose R3 pour ne pas perdre son multicast. Donc, R3 envoie dès que possible un message Pim Join pour ce groupe et R1 ne pense déjà plus à cesser de diffuser. Concernant les messages de Join ci-dessous.
Message Assert.
Imaginons une telle situation : deux routeurs diffusent simultanément dans un même réseau. Ils reçoivent le même flux d'une source, et tous deux le diffusent dans un même réseau via l'interface e0. Ils doivent donc déterminer qui sera le seul diffuseur pour ce réseau. Pour cela, des messages Assert sont utilisés. Lorsque R2 et R3 détectent une duplication du trafic multicast, c'est-à-dire que R2 et R3 reçoivent le multicast qu'ils diffusent eux-mêmes, les routeurs comprennent qu'il y a un problème. Dans ce cas, les routeurs envoient des messages Assert, qui incluent la Distance Administrative et la métrique du chemin emprunté pour atteindre la source du multicast — 10.1.1.10. Le gagnant est déterminé ainsi :
- Celui qui a la plus faible AD.
- Si les AD sont égales, celui qui a la métrique la plus basse.
- Si il y a toujours égalité, celui qui a l'IP la plus élevée dans le réseau où ils diffusent ce multicast.
Celui qui gagne ce vote devient le Routeur Désigné. Pour choisir le DR, les messages Pim Hello sont également utilisés. Au début de l'article, un message PIM Hello a été montré, où l'on peut voir le champ DR. Gagne celui qui a l'adresse IP la plus élevée sur ce lien.
Tableau utile :
Table MROUTE.
Après un examen initial du fonctionnement du protocole PIM, nous devons comprendre comment travailler avec la table de routage multicast. La table mroute contient des informations sur les flux qui ont été demandés par les clients et sur les flux qui transitent depuis les serveurs multicast.
Par exemple, à la réception d'un IGMP Membership Report ou d'un PIM Join sur une interface, une entrée de type ( *, G ) est ajoutée à la table de routage :
Cette entrée indique qu'une demande de trafic a été reçue depuis l'adresse 238.38.38.38. Le drapeau DC signifie que le multicast fonctionnera en mode Dense et C indique que le récepteur est directement connecté au routeur, c'est-à-dire que le routeur a reçu le rapport d'adhésion IGMP, et PIM Join.
S'il y a un enregistrement de type (S,G), cela signifie que nous avons un flux multicast :
Dans le champ S — 192.168.1.11, nous avons l'adresse IP de la source multicast, c'est elle qui sera vérifiée par la règle RPF. En cas de problème, il est nécessaire de vérifier en premier lieu la table unicast pour la route vers la source. Dans le champ Interface entrante, on indique l'interface par laquelle le multicast a été reçu. Dans la table de routage unicast, la route vers la source doit faire référence à l'interface spécifiée ici. Dans l'interface sortante, il est indiqué où le multicast sera redirigé. S'il est vide, cela signifie qu'aucune demande de trafic n'est parvenue au routeur. Plus d'informations sur tous les drapeaux peuvent être trouvées. .
PIM Sparse-mode.
La stratégie Sparse-mode est l'opposée de Dense-mode. Lorsque Sparse-mode reçoit du trafic multicast, il enverra le trafic uniquement à travers les interfaces où des demandes pour ce flux ont été faites, par exemple Pim Join ou messages de rapport IGMP demandant ce trafic.
Éléments similaires en SM et DM :
- Les relations de voisinage se construisent également comme dans PIM DM.
- La règle RPF s'applique.
- Le choix du DR est similaire.
- Le mécanisme Prune Overrides et les messages Assert sont analogues.
Pour contrôler qui a besoin de quel trafic multicast et où dans le réseau, un centre d'information commun est nécessaire. Ce centre sera notre Rendezvous Point (RP). Tous ceux qui souhaitent un certain trafic multicast ou qui commencent à recevoir du trafic multicast d'une source envoient leur demande au RP.
Lorsque le RP reçoit le trafic multicast, il l'envoie aux routeurs qui avaient 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 PIM Register unicast et l'envoie au RP. Comment sait-il qui est le RP ? Dans ce cas, il est configuré statiquement, et nous parlerons de la configuration dynamique du RP plus tard.
ip pim rp-address 3.3.3.3
RP vérifiera s'il y a eu des informations de quelqu'un qui souhaiterait recevoir ce trafic. Supposons qu'il n'y en ait pas. Alors, RP enverra à R1 un message PIM Register-Stop, signifiant qu'aucun multicast n'est nécessaire, l'enregistrement est refusé. R1 ne transmettra pas le multicast. Cependant, l'hôte source du multicast l'enverra, donc R1, après avoir reçu Register-Stop, démarrera un minuteur de suppression d'enregistrement de 60 secondes. Cinq secondes avant l'expiration de ce minuteur, R1 enverra un message Register vide avec le bit Null-Register (c'est-à-dire sans paquet multicast encapsulé) vers RP. RP agira comme suit :
- S'il n'y a pas de destinataires, il répondra par un message Register-Stop.
- S'il y a des destinataires, il ne répondra pas. R1, n'ayant pas reçu de refus pour son enregistrement dans les 5 secondes, sera heureux et enverra un message Register avec multicast encapsulé vers RP.
Maintenant que nous avons compris comment le multicast atteint RP, essayons de répondre à la question de la façon dont RP livre le trafic aux destinataires. Il est nécessaire d'introduire un nouveau concept : l'arbre de chemin racine (RPT). RPT est un arbre dont la racine est RP, croissant vers les destinataires, se ramifiant à chaque routeur PIM-SM. RP le crée en recevant des messages PIM Join et ajoute une nouvelle branche à l'arbre. Chaque routeur descendant fait de même. La règle générale est la suivante :
- Lorsqu'un routeur PIM-SM reçoit un message PIM Join sur une interface quelconque, sauf celle qui cache RP, il ajoute une nouvelle branche à l'arbre.
- Une branche est également ajoutée lorsqu'un routeur PIM-SM reçoit un rapport d'adhésion IGMP d'un hôte directement connecté.
Imaginons qu'un client multicast soit connecté au routeur R5 sur le groupe 228.8.8.8. Dès que R5 reçoit un rapport d'adhésion IGMP de l'hôte, R5 envoie un PIM Join en direction de RP, tout en ajoutant l'interface se connectant à l'hôte dans l'arbre. Ensuite, R4 reçoit le PIM Join de R5, ajoute l'interface Gi0/1 à l'arbre et envoie PIM Join en direction de RP. Enfin, RP (R3) reçoit PIM Join et ajoute Gi0/0 à l'arbre. Ainsi, l'enregistrement du destinataire multicast est effectué. Nous construisons un arbre avec R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Après cela, un PIM Join sera envoyé à R1 et R1 commencera à envoyer du trafic multicast. Il est important de noter que si l'hôte a demandé le trafic avant le début de la diffusion du multicast, le RP ne sera pas en mesure d'envoyer le PIM Join et ne transmettra rien à R1.
Si, pendant l'envoi du multicast, l'hôte ne souhaite plus le recevoir, dès que le RP reçoit un PIM Prune sur l'interface Gi0/0, il enverra immédiatement un PIM Register-Stop directement à R1, puis un message PIM Prune via l'interface Gi0/1. Le PIM Register-stop est envoyé en unicast à l'adresse d'où est arrivé le PIM Register.
Comme nous l'avons mentionné précédemment, dès qu'un routeur envoie un PIM Join à un autre, par exemple R5 à R4, une entrée est ajoutée sur R4 :
Et un minuteur est lancé, indiquant que R5 doit constamment envoyer des messages PIM Join, sinon R4 le supprimera de la liste sortante. R5 enverra un message PIM Join toutes les 60 secondes.
Basculement de l'arbre de chemin le plus court.
Nous ajouterons une interface entre R1 et R5, et examinerons comment le trafic circulera dans cette topologie.
Supposons que le trafic ait été envoyé et reçu selon l'ancienne schéma R1-R2-R3-R4-R5, et que nous avons maintenant connecté et configuré une interface entre R1 et R5.
Tout d'abord, notre table de routage unicast sur R5 sera reconstruite et maintenant le réseau 192.168.1.0/24 sera accessible via l'interface R5 Gi0/2. Maintenant, R5, recevant le multicast sur l'interface Gi0/1, comprend que la règle RPF n'est pas satisfaite et qu'il serait plus logique de recevoir le multicast sur Gi0/2. Il doit se déconnecter de l'RPT et construire un arbre plus court, appelé Shortest-Path Tree (SPT). Pour cela, il envoie un PIM Join à R1 via Gi0/2 et R1 commence à envoyer du multicast aussi via Gi0/2. Maintenant, R5 doit se désinscrire de l'RPT, afin de ne pas recevoir deux copies. Pour cela, il envoie un message Prune en spécifiant l'adresse IP de la source et en insérant un bit spécial — le RPT-bit. Cela signifie que je ne veux pas recevoir de trafic, j'ai un meilleur arbre ici. Le RP envoie également des messages PIM Prune vers R1, mais n'envoie pas de message Register-Stop. Une autre caractéristique : R5 enverra constamment des PIM Prune au RP, car R1 continue d'envoyer un PIM Register au RP chaque minute. Tant qu'il n'y a pas de nouveaux demandeurs de ce trafic, le RP lui répondra par un refus. R5 informe le RP qu'il continue de recevoir le multicast via SPT.
Recherche dynamique de RP.
Auto-RP.
Cette technologie est propriétaire de Cisco et n'est pas très populaire, mais elle est toujours en vie. Le fonctionnement d'Auto-RP se divise en deux étapes principales :
1) Le RP envoie des messages RP-Announce à l'adresse réservée — 224.0.1.39, en s'annonçant comme RP soit pour tous, soit pour des groupes spécifiques. Ce message est envoyé chaque minute.
2) Un agent de mappage RP est nécessaire, qui enverra des messages RP-Discovery indiquant à quels groupes chaque RP doit être écouté. C'est à partir de ce message que les routeurs PIM ordinaires détermineront leur 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 un intervalle d'une minute.
Examinons le processus de plus près :
Configurons R3 en tant que RP :
ip pim send-rp-announce loopback 0 scope 10
R2 en tant qu'agent de mappage :
ip pim send-rp-discovery loopback 0 scope 10
Et sur tous les autres, nous attendrons le RP via Auto-RP :
ip pim autorp listener
Dès que nous configurons R3, il commencera à envoyer des RP-Announce :
Et R2, après avoir été configuré en tant qu'agent de mappage, commencera à attendre les messages RP-Announce. Ce n'est que lorsqu'il trouvera au moins un RP qu'il commencera à envoyer des RP-Discovery :
Ainsi, dès que les routeurs ordinaires (PIM RP Listener) recevront ce message, ils sauront où chercher le RP.
Un des principaux problèmes d'Auto-RP est que pour recevoir les messages RP-Announce et RP-Discovery, il est nécessaire d'envoyer un PIM Join aux adresses 224.0.1.39-40, mais pour cela, il faut savoir où se trouve le RP. C'est le problème classique de la poule et de l'œuf. Pour résoudre ce problème, le mode PIM Sparse-Dense-Mode a été inventé. Si le routeur ne connaît pas le RP, il fonctionne en mode Dense, s'il le connaît, alors en mode Sparse. Lorsque sur les interfaces des routeurs ordinaires, PIM Sparse-mode et la commande ip pim autorp listener sont configurés, le routeur fonctionnera en mode Dense uniquement pour le multicast directement du protocole Auto-RP (224.0.1.39-40).
BootStrap Router (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 les partage ensuite avec tous les autres routeurs. Décrivons le processus de manière analogue à Auto-RP :
1) Dès que nous configurons R3 comme candidat pour être RP, avec la commande :
ip pim rp-candidate loopback 0
Alors R3 ne fera rien. Pour commencer à envoyer des messages spéciaux, il doit d'abord trouver un agent de mappage. Ainsi, nous passons à la deuxième étape.
2) Configurons R2 comme agent de mappage :
ip pim bsr-candidate loopback 0
R2 commence l'envoi de messages PIM Bootstrap, où il se déclare en tant qu'agent de mapping :
Ce message est envoyé à l'adresse 224.0.0.13, que le protocole PIM utilise également pour d'autres messages. Il les envoie dans toutes les directions, donc il n'y a pas de problème de poule et d'œuf, comme c'était le cas avec Auto-RP.
3) Dès que le RP reçoit un message du routeur BSR, il envoie immédiatement un message unicast à l'adresse du routeur BSR :
Ensuite, une fois que le BSR a l'information sur le RP, il la diffuse en multicast à l'adresse 224.0.0.13, qui est écoutée par tous les routeurs PIM. Par conséquent, il n'existe pas d'équivalent à la commande ip pim autorp listener pour les routeurs ordinaires dans BSR.
Anycast RP avec le protocole de découverte de source multicast (MSDP).
Auto-RP et BSR nous permettent de répartir la charge sur le RP comme suit : Chaque groupe multicast n'a qu'un seul RP actif. Il n'est pas possible de répartir la charge pour un groupe multicast entre plusieurs RP. MSDP le fait en attribuant aux routeurs RP la même adresse IP avec un masque de 255.255.255.255. MSDP obtient cette information par l'un des méthodes : 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. Lors du RP-Announce, les deux routeurs se déclarent, faisant référence à cette adresse. L'agent de mapping Auto-RP, ayant reçu l'information, envoie RP-Discovery concernant le RP avec l'adresse 172.16.1.1/32. Pour le réseau 172.16.1.1/32, nous informons les routeurs via IGP, respectivement. Ainsi, les routeurs PIM demandent ou s'enregistrent pour des flux à partir de ce RP, qui est désigné comme next-hop pour la route vers le réseau 172.16.1.1/32. Le protocole MSDP est, en effet, destiné aux RP eux-mêmes pour échanger des messages sur les informations multicast.
Considérons cette topologie :
Switch6 diffuse le trafic à l'adresse 238.38.38.38 et seul RP-R1 en a connaissance jusqu'à présent. Ici, Switch7 et Switch8 ont demandé ce groupe. Les routeurs R5 et R4 enverront un PIM Join à R1 et R3, respectivement. Pourquoi ? La route vers 13.13.13.13 pour R5 se référera à R1 en termes de métrique IGP, tout comme pour R4.
RP-R1 connaît le flux et commencera à le diffuser en direction de R5, tandis que R4 n'en sait rien, car R1 ne l'enverra pas sans raison. C'est pourquoi MSDP est nécessaire. Nous le configurons sur R1 et R5 :
ip msdp peer 3.3.3.3 connect-source Loopback1 sur R1
ip msdp peer 1.1.1.1 connect-source Loopback3 sur R3
Ils établiront une session entre eux et, lors de la réception d'un flux quelconque, informeront leur voisin RP à ce sujet.
Dès que RP-R1 reçoit un flux de Switch6, il enverra immédiatement un message MSDP Source-Active en unicast, qui contiendra des informations du type (S, G) — informations sur la source et la destination du multicast. Maintenant, lorsque RP-R3 saura qu'une source telle que Switch6 existe, il enverra, lors de la réception d'une demande de R4 pour ce flux, un PIM Join vers Switch6, en s'appuyant sur la table de routage. Par conséquent, R1, ayant reçu ce PIM Join, commencera à envoyer le trafic vers RP-R3.
MSDP fonctionne sur TCP, les RP s'envoient des messages de keepalive pour vérifier leur viabilité. Le timer est de 60 secondes.
La fonction de séparation des pairs MSDP dans différents domaines demeure floue, car les messages Keepalive et SA ne spécifient pas à quel domaine ils appartiennent. De plus, dans cette topologie, une configuration avec des domaines différents a été testée — il n'y avait pas de différence de fonctionnement.
Si quelqu'un peut apporter des éclaircissements, je serais ravi de lire vos commentaires.
Source : habr.com
