Introduction
Cet article poursuit la série sur la multidiffusion IP. Nous allons voir comment fonctionne la multidiffusion IP de base. Nous verrons ensuite comment fonctionne le mode dense PIM (PIM-DM), comment le configurer et comment le dépanner. Cela devrait nous réchauffer avant de nous attaquer au mode PIM Sparse, légèrement plus complexe et plus évolutif, dans un article ultérieur.
L’article initial sur la multidiffusion contient des liens vers les principaux groupes de travail de l’IETF à sa fin. Il peut être trouvé à l’adresse Les protocoles de la multidiffusion IP.
Comprendre la transmission de la multidiffusion IP
Le but d’un protocole de routage de multidiffusion est de permettre aux routeurs de travailler ensemble pour délivrer efficacement des copies de paquets de multidiffusion aux récepteurs intéressés. Ce faisant, le protocole de routage de multidiffusion fournit probablement aussi un mécanisme permettant aux voisins de découvrir et de suivre les routeurs voisins utilisant également le protocole de routage de multidiffusion.
Comme nous l’avons vu dans le dernier article, les ordinateurs intéressés par la réception d’un flux de paquets de multidiffusion utilisent IGMP pour notifier le ou les routeurs adjacents. Les routeurs utilisent alors le protocole de multidiffusion pour s’arranger pour qu’une copie du flux de paquets de multidiffusion leur soit envoyée afin qu’ils puissent le transmettre sur le réseau local contenant le récepteur. Nous n’avons pas mentionné ce qui se passe à la source du flux de paquets. Dans la multidiffusion IP, il n’existe aucun protocole permettant à la source de communiquer, de s’enregistrer ou d’informer les routeurs. La source commence simplement à envoyer des paquets de multidiffusion IP, et c’est au routeur ou aux routeurs voisins de faire ce qu’il faut. (Ce que la « bonne chose » se trouve être dépend du protocole de routage multicast).
L’image suivante montre une source qui envoie un paquet multicast en rouge, et des routeurs en aval qui dupliquent le paquet et l’inondent vers d’autres routeurs et finalement tous les segments du LAN. Comme nous le verrons prochainement, il s’agit du comportement initial (et périodique) du protocole de routage de multidiffusion indépendant du protocole (PIM) de Cisco, lorsqu’il agit en mode dense.
Notez dans l’image ci-dessus que les flèches bleues transmettent les copies de paquets de multidiffusion de manière organisée. Il peut y avoir deux copies de chaque paquet arrivant dans certains des routeurs ou segments de réseau local. Mais les routeurs ne transmettent pas les paquets « à l’envers ». C’est une bonne chose : pensez à ce qui pourrait se passer si le routeur E transmettait une copie du paquet qu’il a reçu de C au routeur B. B transmettrait-il alors le paquet à A, qui pourrait le transmettre à C, et ainsi de suite, dans une boucle de transmission ? Ce serait une sorte d’équivalent de couche 3 de ce qui se passe à la couche 2 lorsque Spanning Tree est désactivé dans une topologie en boucle : un bon moyen de gaspiller beaucoup de bande passante et de capacité de routeur.
Pour empêcher les boucles de transmission de multidiffusion, la multidiffusion IP effectue toujours une vérification RPF, dont nous parlerons sous peu.
En plus de la vérification RPF, les protocoles de routage de multidiffusion tels que PIM peuvent également fonctionner pour empêcher l’inefficacité. Par exemple, le routeur E dans l’image n’a pas besoin de recevoir deux copies de chaque paquet multicast (une de B, une de C).
Le protocole de routage multicast détermine quelles interfaces envoyer des copies (ou ne pas envoyer de copies). Comme le suggère l’image ci-dessus, le transfert de multidiffusion se produit le long d’arbres logiques, des chemins de ramification à travers le réseau. Toutes les informations relatives au transfert de multidiffusion sont stockées dans la table d’état de multidiffusion, que certains appellent la table de routage de multidiffusion. Ces informations peuvent être visualisées à l’aide de la commande très utile, show ip mroute. Jetons un bref coup d’œil à un exemple de sortie de la commande show ip mroute (avec le mode dense PIM en cours d’exécution).
Router# show ip mroute 233.1.1.1IP Multicast Routing TableFlags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit setTimers: Uptime/ExpiresInterface state: Interface, Next-Hop, State/Mode(*, 233.1.1.1), uptime 0:57:31, expires 0:02:59, RP is 0.0.0.0, flags: DC Incoming interface: Null, RPF neighbor 0.0.0.0 Outgoing interface list: Ethernet0, Forward/Dense, 0:57:31/0:02:52 FastEthernet1, Forward/Dense, 0:56:55/0:01:28 FastEthernet2, Forward/Dense, 0:56:45/0:01:22(172.16.16.1/32, 233.1.1.1), uptime 20:20:00, expires 0:02:55, flags: C Incoming interface: FastEthernet1, RPF neighbor 10.20.30.1 Outgoing interface list: Ethernet0, Forward/Dense, 20:20:00/0:02:52
Pour comprendre cela, notez que les adresses commençant par 224-239 sont des adresses ou des groupes de multidiffusion IP. (Le groupe fait référence au groupe de récepteurs pour cette adresse de destination multicast).
L’entrée commençant par (*, 233.1.1.1) est une entrée d’arbre de multidiffusion partagée, parfois appelée entrée (*, G). (G ici est juste 223.1.1.1). PIM-DM ne les utilise pas pour le transfert de paquets, mais liste les interfaces ayant un rôle dans la multidiffusion (récepteur IGMP connu ou voisin PIM) comme interfaces sortantes sous de telles entrées.
L’entrée commençant par (172.16.16.1, 233.1.1.1) est appelée entrée (S, G). S est la source, G est le groupe. Si vous préférez, considérez cela comme la source et la destination dans l’en-tête IP (puisque c’est là qu’elles apparaissent réellement dans les paquets). Cette entrée est un arbre de multidiffusion spécifique à la source pour un groupe de multidiffusion particulier. Il y aura généralement une telle entrée pour chaque source et chaque groupe. Notez que le saut suivant du routage unicast apparaît comme le voisin RPF, et l’interface entrante est l’interface RPF, l’interface utilisée par le routage unicast vers la source 172.16.16.1. La liste des interfaces sortantes montre que tout paquet de 172.16.16.1 avec la destination 233.1.1.1 reçu sur FastEthernet1 sera copié sur Ethernet0.
Vous pouvez dessiner l’arbre de transfert de multidiffusion pour un (S, G) particulier à des fins de dépannage. Pour ce faire, exécutez la commande show ip mroute sur chaque routeur. Prenez une copie de votre carte réseau et dessinez une flèche sortante pour chaque interface de la liste des interfaces sortantes (« OIL » ou « OILIST »). Vous vous retrouverez avec un diagramme ressemblant quelque peu à l’image ci-dessus.
Des drapeaux d’état que vous pourriez voir dans la sortie de la commande PIM-DM show ip mroute :
- D = Mode dense. Apparaît uniquement sur les entrées (*, G). Le groupe fonctionne en mode dense.
- C = Hôte directement connecté (IGMP !)
- L = Local (Le routeur est configuré pour être membre du groupe multicast).
- P = Prune (Toutes les interfaces OILIST sont configurées pour Prune). Le routeur envoie généralement Prune à son voisin RPF lorsque cela se produit.
- T = Forwarding via Shortest Path Tree (SPT), indique au moins un paquet reçu / transmis.
- J = Join SPT. Toujours présent dans l’entrée (*,G) de PIM-DM, ne signifie pas grand-chose.
Qu’est-ce que la vérification RPF, et pourquoi ?
Le transfert de multicast IP effectue toujours une vérification RPF. RPF est l’abréviation de Reverse Path Forwarding (transfert de chemin inverse). L’objectif de la vérification RPF est d’essayer d’empêcher une boucle de transmission de paquets multicast d’une manière simple. Pour chaque flux multicast, le routeur multicast vérifie l’adresse source, c’est-à-dire le périphérique qui a envoyé le multicast. Il recherche ensuite l’expéditeur dans la table de routage unicast et détermine l’interface à utiliser pour envoyer des paquets unicast à la source multicast. Cette interface est l’interface RPF, celle sur laquelle le routeur « s’attend » à recevoir des multidiffusions. Il s’agit de l’interface « officiellement approuvée » pour recevoir des multidiffusions de cette source particulière. Le routeur stocke l’interface RPF dans le cadre des informations d’état de multidiffusion pour cette source particulière et cette destination (groupe) de multidiffusion particulière.
Lorsqu’un paquet de multidiffusion est reçu par le routeur, ce dernier suit l’interface par laquelle le paquet est arrivé. Si le paquet est le premier paquet d’une nouvelle source, l’interface RPF est déterminée et stockée dans la table mroute, comme nous venons de le voir. Sinon, le routeur recherche la source et le groupe multicast dans la table mroute. Si le paquet a été reçu sur l’interface RPF, il est copié et transféré sur chaque interface sortante répertoriée dans la table mroute. Si le paquet a été reçu sur une interface non-RPF, il est écarté. Si le routeur était une personne, cela équivaudrait à « Pourquoi cette personne m’envoie-t-elle ceci ? Ils doivent être confus, je vais ignorer ce qu’ils viennent de m’envoyer. »
Le routeur ne renvoie pas non plus une copie d’un paquet sur l’interface par laquelle il est arrivé (l’interface RPF). En d’autres termes, même si le routeur voisin sur l’interface RPF demandait d’une manière ou d’une autre à recevoir des copies d’un flux de multidiffusion, le routeur n’ajoutera pas l’interface RPF à la liste des interfaces sortantes qui reçoivent des copies du flux de multidiffusion. Cela protège contre toute sorte d’erreur de protocole mettant deux voisins dans une boucle de transmission multicast serrée.
Le routeur E ignore aussi probablement l’un des deux flux de paquets, selon que B ou C est connecté à l’interface RPF. Même avec des routes à coût égal, normalement une seule interface est choisie comme interface RPF. Ainsi, si vous avez deux liaisons reliant deux routeurs, une seule sera généralement utilisée pour la multidiffusion à partir d’un seul sous-réseau source.
Voir cependant la commande ip multicast multipath (nouvelle dans Cisco IOS Version 12.0(8) T, 12.0(5) S). Avec cette commande, utilisée correctement, il peut y avoir un équilibrage de charge pour différentes sources pour un groupe multicast particulier. Comme il s’agit d’une répartition par source et non par flux, cela s’apparente davantage à une répartition de la charge. Cela peut ne pas finir par être très équilibré.
L’équilibrage de charge du trafic pour un flux de paquets (une source et un groupe) sur deux liens entre deux routeurs peut également être fait en utilisant des tunnels GRE entre des interfaces de bouclage, bien que je puisse m’inquiéter des implications de performance de faire cela avec un flux à large bande passante.
En passant, cela nous indique également comment diriger la multidiffusion IP sur les liens de notre choix. Nous contrôlons où va le trafic multicast en contrôlant la vérification RPF. Si un routeur n’apprend pas les routes de retour vers une source multicast sur une certaine interface, alors cette interface ne sera pas l’interface RPF. Ainsi, avec les protocoles à vecteur de distance et la « route starvation » (ne pas annoncer une route à un voisin), nous pouvons orienter ou diriger la multidiffusion.
Nous verrons plus tard que toute greffe ou jointure PIM est envoyée par l’interface RPF, en retour vers la source (ou RP, en mode PIM Sparse). En contrôlant où cette activité a lieu, nous contrôlons les liens sur lesquels le multicast est transmis. Les entrées statiques mroute (routes statiques de retour à la source à des fins de vérification RPF du multicast) sont un autre moyen de diriger le trafic multicast. Si / lorsque nous parlons de MBGP (Multiprotocol BGP for Multicast), nous verrons que MBGP nous fournit également un moyen de diriger ou de contrôler les liens utilisés par le trafic multicast. Notez également que si l’interface RPF n’a pas activé le multicast IP, le routeur attend des paquets là où il ne les recevra pas. L’interface RPF devrait toujours être une interface où la multidiffusion IP est activée.
Mode dense de PIM – Aperçu
La multidiffusion indépendante du protocole a deux modes, le mode dense et le mode épars. Cet article n’a d’espace que pour couvrir le premier. Nous aborderons PIM-SM dans le prochain article.
Le mode dense de PIM (PIM-DM) utilise une approche assez simple pour gérer le routage multicast IP. L’hypothèse de base derrière PIM-DM est que le flux de paquets de multidiffusion a des récepteurs à la plupart des endroits. Un exemple de ceci pourrait être une présentation d’entreprise par le PDG ou le président d’une société. À l’inverse, PIM-SM (PIM Sparse Mode) suppose que les récepteurs sont relativement moins nombreux. Un exemple serait la vidéo d’orientation initiale pour les nouveaux employés.
Cette différence se manifeste dans le comportement et les mécanismes initiaux des deux protocoles. PIM-SM n’envoie des multidiffusions que lorsqu’on lui demande de le faire. Alors que PIM-DM commence par inonder le trafic multicast, puis l’arrête chaque lien où il n’est pas nécessaire, en utilisant un message Prune. Je pense au message Prune comme un routeur qui dit à un autre « nous n’avons pas besoin de ce multicast ici en ce moment ».
Dans les anciennes versions de Cisco IOS, PIM-DM inondait à nouveau tout le trafic multicast toutes les 3 minutes. Cela convient pour le multicast à faible volume, mais pas pour les flux de paquets multicast à bande passante plus élevée. Les versions plus récentes de Cisco IOS prennent en charge une nouvelle fonctionnalité appelée PIM Dense Mode State Refresh, depuis la version 12.1(5)T. Cette fonctionnalité utilise des messages de rafraîchissement d’état PIM pour rafraîchir l’état Prune sur les interfaces sortantes. Un autre avantage est que les changements de topologie sont reconnus plus rapidement. Par défaut, les messages de rafraîchissement d’état PIM sont envoyés toutes les 60 secondes.
Considérez les routeurs E et F dans l’image ci-dessus. Lorsque deux routeurs PIM-DM se connectent à un réseau local, ils voient les paquets de multidiffusion de l’autre. L’un doit transmettre les paquets au réseau local, et l’autre non. Ils envoient tous les deux des messages Assert. La meilleure métrique de routage l’emporte, l’adresse IP la plus élevée servant à départager les deux. S’ils utilisent des protocoles de routage différents, un schéma de métrique de routage pondéré, un peu comme la distance administrative, détermine quel routeur sera le transitaire (qui transmet les paquets multicast sur le réseau local). Le forwarder peut être réduit au silence par un Prune d’un routeur en aval sans récepteur, s’il n’y a pas non plus de récepteur sur le segment LAN. Les routeurs en aval peuvent avoir à ajuster leur voisin RPF, pour refléter le gagnant du processus Assert.
Pour répéter cela dans tous les détails : lorsque le trafic multicast est reçu sur une interface non-RPF, un message Prune est envoyé, à condition que l’interface soit point-à-point. Ces messages Prune sont limités en débit, pour s’assurer que leur volume (potentiellement, un par multicast reçu) ne cause pas de problèmes supplémentaires.
Si l’interface non-RPF est un réseau local, un message Assert est envoyé. Les routeurs non forwarders envoient alors un Prune sur leur interface RPF s’ils n’ont pas besoin du flux multicast. Un seul Prune de ce type est envoyé, au moment de la transition vers l’absence d’interfaces dans la liste des interfaces sortantes (OILIST). Le récepteur de la prune du réseau local retarde son action de 3 secondes, de sorte que si un autre routeur du réseau local a encore besoin du flux de multidiffusion, il peut envoyer un message PIM Join pour contrer (annuler) la prune. (« Yo, ce routeur n’en a pas besoin, mais moi si ! »)
Supposons qu’un routeur ait Prune, et que quelque temps plus tard un récepteur demande le flux multicast avec un message IGMP. Le routeur envoie alors un message Graft. En effet, « hé, j’ai besoin de ce flux de multidiffusion ici maintenant ».
L’image suivante illustre cela, certes sous une forme un peu compressée.
Explication de l’image:
(1), peut-être que le routeur E choisit B comme voisin RPF, sur la base d’un routage unicast en retour vers la source. Ensuite, E reçoit un paquet multicast sur l’interface point à point de C. Il envoie un Prune à débit limité à C.
(2), les routeurs E et F sur le réseau local échangent des paquets Assert, lorsque E ou F voit le multicast transmis par l’autre des deux. Supposons que E gagne, sur la base de la métrique ou de l’adresse de routage unicast. F sait alors qu’il ne doit pas transmettre de multidiffusion sur le réseau local. Notez que G et H ne sont pas impliqués, puisque l’Ethernet est leur interface RPF.
(3), supposons que le routeur G n’a pas de récepteurs en aval. Il peut alors envoyer un LAN Prune au Forwarder pour le LAN, le routeur E.
(4), si le routeur H a un ou des récepteurs locaux ou en aval, il le contrebalance avec un LAN Join.
(5), supposons que le routeur D n’ait pas de récepteurs en aval ou locaux et qu’il envoie un Prune à B. Supposons que quelque temps plus tard, l’un des PC à sa droite lui envoie un message IGMP pour le même groupe multicast. Le routeur D peut alors envoyer une Greffe PIM à B, demandant à B de recommencer à lui envoyer le groupe multicast spécifié.
Protocole PIM et types de paquets
PIM est un protocole de routage complet, avec différents types de messages. Je ne vais pas radoter sur les différents messages. Mais je pense qu’il vaut la peine d’y jeter un bref coup d’œil, car il nous renseigne un peu sur le protocole.
PIM utilise des messages Hello pour découvrir les voisins et former des adjacences. Le Hello est envoyé à l’adresse multicast locale All-PIM-Routers, 224.0.0.13, toutes les 30 secondes (PIMv1 utilise AllRouters, 224.0.0.2). Chaque réseau local possède un routeur désigné (DR) PIM, utilisé en mode PIM Sparse. Il s’agit également du quêteur IGMPv1 : l’adresse IP la plus élevée du réseau local. La commande show ip pim neighbor montre les voisins et les informations d’adjacence et de temporisation.
Clarification ajoutée le 12/11/2004 : L’interrogateur IGMP et le routeur désigné sont les deux rôles en question. Voir ici.
En IGMP version 1, « Le DR est responsable des tâches suivantes:
- Envoyer des messages PIM register et PIM join and prune vers le RP pour l’informer de l’appartenance à un groupe d’hôtes.
- Envoyer des messages IGMP host-query. »
En IGMP version 2, ils sont découplés. Le querier IGMP est élu par l’IP la plus basse du réseau local. PIM sélectionne le DR par l’IP la plus élevée sur le LAN, pour transmettre les multicasts au LAN. (Cela décharge le travail).
PIM a également un message Join/Prune, utilisé comme décrit ci-dessus. Il y a aussi des messages Graft et Graft ACK, ce qui nous indique que le Graft est fait de manière fiable (contrairement au monde réel ?).
Et il y a le message PIM Assert.
PIM-SM a 3 types de messages supplémentaires : Register, Register-Stop, et RP-Reachability (pas dans PIMv2).
Configuration de PIM Dense Mode
Configurer PIM-DM est carrément facile par rapport à tout ce qui précède.
Globalement, activez le routage de multidiffusion avec la commande:
ip multicast-routing
Puis sur chaque interface que vous souhaitez participer à la multidiffusion, activez la multidiffusion IP et PIM avec la commande interface :
interface …
ip pim dense-mode
En fait, il est préférable de configurer le mode sparse-dense :
interface …
ip pim sparse-dense-mode
La raison est que cela vous permet de simplement migrer certains ou tous les groupes multicast vers le mode sparse, en faisant savoir au routeur qu’il existe un point de rendez-vous. Et vous pouvez même le faire sans reconfigurer beaucoup de routeurs ou d’interfaces de routeurs.
Vous pouvez configurer des réseaux stub pour une simple multidiffusion IP. L’idée est de ne pas exécuter PIM pour les parties stub du réseau, comme les petits sites distants, pour plus de simplicité. C’est une idée particulièrement bonne avec les routeurs qui ne sont pas sous votre contrôle : vous ne voulez pas qu’ils partagent le routage multicast avec vos routeurs. Cela élimine également l’inondation PIM-DM vers de tels routeurs (avec les anciennes versions de Cisco IOS).
Pour configurer le stub multicast, configurez
ip igmp helper-address a.b.c.d
sur toutes les interfaces LAN des routeurs stub avec des récepteurs multicast potentiels. L’adresse a.b.c.d est l’adresse du routeur central parlant PIM. Sur le routeur central, vous configurez un filtre pour rejeter tous les messages PIM que le voisin stub pourrait envoyer, avec:
ip pim neighbor-filter access-list
Voir aussi le guide des commandes à l’URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcpt3/1cfmulti.htm .
Il existe plusieurs commandes show pour aider à dépanner la multidiffusion IP. Celles que je préfère :
- show ip mroute
- show ip pim interface
- show ip pim neighbor
- show ip rpf
Comme l’espace est restreint, je vous renvoie à la référence des commandes pour les exemples.
Une note de dépannage : si vous avez effectivement une multidiffusion à large bande passante dans votre réseau, assurez-vous d’utiliser le rafraîchissement de l’état d’élagage dans les nouvelles versions de Cisco IOS si vous utilisez le mode clairsemé-dense. Je crains que les routeurs » oublient » qu’ils ont un RP et reviennent au mode dense, avec des inondations périodiques. Il peut s’agir d’une rare occurrence accidentelle, mais cela pourrait vraiment gâcher votre matinée ! Vous pouvez également envisager des techniques de robustesse de RP, un sujet pour notre article ultérieur sur PIM-SM ou Rendezvous Point.
En conclusion
Le livre recommandé pour beaucoup de sujets de multicast : Developing IP Multicast Networks : The Definitive Guide to Designing and Deploying CISCO IP Multicast Networks, Beau Williamson.
Un autre lien extrêmement bon sur le multicast Cisco peut être trouvé ici.
Prochain article : mise à l’échelle avec PIM Sparse Mode.