Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Comprendre la surveillance MLD

La surveillance MLD (Multicast Listener Discovery) limite l’inondation du trafic multicast IPv6 sur les VLAN. Lorsque la surveillance MLD est activée sur un VLAN, un équipement Juniper Networks examine les messages MLD entre les hôtes et les routeurs de multicast et apprend quels hôtes souhaitent recevoir du trafic pour un groupe de multicast. Sur la base de ce qu’il apprend, l’équipement transmet ensuite le trafic multicast uniquement aux interfaces du VLAN qui sont connectées aux récepteurs intéressés au lieu d’inonder le trafic vers toutes les interfaces.

La surveillance MLD prend en charge MLD version 1 (MLDv1) et MLDv2. Pour plus de détails sur MLDv1 et MLDv2, consultez les normes suivantes :

  • MLDv1 : voir RFC 2710, Multicast Listener Discovery (MLD) pour IPv6.

  • MLDv2 : voir RFC 3810, Multicast Listener Discovery Version 2 (MLDv2) pour IPv6.

Avantages de la surveillance MLD

  • Optimized bandwidth utilization: le principal avantage de la surveillance MLD est de réduire l’inondation de paquets. Les données de multicast IPv6 sont transmises de manière sélective à une liste de ports qui souhaitent recevoir les données, au lieu d’être inondées vers tous les ports d’un VLAN.

  • Improved security: les attaques par déni de service provenant de sources inconnues sont évitées.

Comment fonctionne la surveillance MLD

Par défaut, l’appareil inonde le trafic de multicast de couche 2 sur toutes les interfaces appartenant à ce VLAN sur l’appareil, à l’exception de l’interface qui est la source du trafic de multicast. Ce comportement peut consommer des quantités importantes de bande passante.

Vous pouvez activer la surveillance MLD pour éviter ce flooding. Lorsque vous activez la surveillance MLD, l’appareil surveille les messages MLD entre les récepteurs (hôtes) et les routeurs de multicast et utilise le contenu des messages pour créer une table de transfert de multicast IPv6, une base de données de groupes de multicast IPv6 et des interfaces connectées aux membres intéressés de chaque groupe. Lorsque l’appareil reçoit du trafic de multicast pour un groupe de multicast, il utilise la table de transfert pour transférer le trafic uniquement vers les interfaces connectées aux récepteurs appartenant au groupe de multicast.

La figure 1 montre un exemple de flux de trafic multicast avec la surveillance MLD activée.

Figure 1 : flux de trafic multicast avec surveillance MLD activée Network setup with a multicast router forwarding traffic for Group 1 and Group 2. EX Series Switch connects to Host A and B directly, Host 1 and 3 in Group 1, Host 2 and 4 in Group 2 via multicast traffic distribution.

Types de messages MLD

Les routeurs multicast utilisent MLD pour apprendre, pour chacun de leurs réseaux physiques connectés, quels groupes ont des auditeurs intéressés. Dans un sous-réseau donné, un routeur de multicast est choisi pour agir en tant que requête MLD. L’interrogateur MLD envoie les types de requêtes suivants aux hôtes :

  • Requête générale : demande si un hôte écoute un groupe.

  • Requête spécifique au groupe : demande si un hôte écoute un groupe de multicast spécifique. Cette requête est envoyée en réponse à un hôte quittant le groupe de multicast et permet au routeur de déterminer rapidement si des hôtes restants sont intéressés par le groupe.

  • Requête spécifique au groupe et à la source : (MLD version 2 uniquement) Demande si un hôte écoute le trafic de multicast de groupe à partir d’une source de multicast spécifique. Cette requête est envoyée en réponse à un hôte indiquant qu’il n’est plus intéressé par la réception de trafic de multicast de groupe à partir de la source de multicast et permet au routeur de déterminer rapidement les hôtes restants sont intéressés par la réception de trafic de multicast de groupe à partir de cette source.

Les hôtes qui sont des écouteurs multicast envoient les types de messages suivants :

  • Rapport d’appartenance : indique que l’hôte souhaite rejoindre un groupe de multicast particulier.

  • Quitter le rapport : indique que l’hôte souhaite quitter un groupe de multicast particulier.

Seuls les hôtes MLDv1 utilisent deux types de rapports différents pour indiquer s’ils souhaitent rejoindre ou quitter un groupe. Les hôtes MLDv2 n’envoient qu’un seul type de rapport, dont le contenu indique s’ils souhaitent rejoindre ou quitter un groupe. Toutefois, par souci de simplicité, la documentation sur la surveillance MLD utilise le terme rapport d’appartenance pour un rapport qui indique qu’un hôte souhaite rejoindre un groupe et utilise le terme rapport de congé pour un rapport qui indique qu’un hôte souhaite quitter un groupe.

Comment les hôtes rejoignent et quittent les groupes multicast

Les hôtes peuvent rejoindre des groupes de multicast de deux manières :

  • En envoyant un rapport d’appartenance non sollicité qui spécifie le groupe de multicast que l’hôte tente de rejoindre.

  • En envoyant un rapport d’appartenance en réponse à une requête provenant d’un routeur multicast.

Un routeur de multicast continue de transférer le trafic de multicast à une interface, à condition qu’au moins un hôte de cette interface réponde aux requêtes générales périodiques indiquant son appartenance. Par conséquent, pour qu’un hôte reste membre d’un groupe de multicast, il doit continuer à répondre aux requêtes générales périodiques.

Les hôtes peuvent quitter les groupes de multicast de deux manières :

  • En ne répondant pas aux requêtes périodiques dans un intervalle de temps défini. Il en résulte ce que l’on appelle un « congé silencieux ».

  • En envoyant un rapport de congé.

Remarque :

Si un hôte est connecté à l’appareil via un concentrateur, il ne quitte pas automatiquement le groupe de multicast s’il se déconnecte du concentrateur. L’hôte reste membre du groupe jusqu’à ce que l’adhésion au groupe expire et qu’un congé silencieux se produise. Si un autre hôte se connecte au port hub avant que le congé silencieux ne se produise, le nouvel hôte peut recevoir le trafic de multicast de groupe jusqu’au congé silencieux, même s’il n’a jamais envoyé de rapport d’adhésion.

Prise en charge des sources multicast MLDv2

Dans MLDv2, un hôte peut envoyer un rapport d’appartenance qui inclut une liste d’adresses sources. Lorsque l’hôte envoie un rapport d’appartenance en mode INCLUDE, l’hôte s’intéresse au trafic de multicast de groupe uniquement à partir des sources de la liste d’adresses source. Si l’hôte envoie un rapport d’appartenance en mode EXCLUDE, l’hôte est intéressé par le trafic de multicast de groupe à partir de n’importe quelle source, à l’exception des sources de la liste d’adresses source. Un hôte peut également envoyer un rapport EXCLUDE dans lequel le paramètre source-list est vide, appelé rapport EXCLUDE NULL. Un rapport EXCLUDE NULL indique que l’hôte souhaite rejoindre le groupe de multicast et recevoir des paquets de toutes les sources.

Les appareils qui prennent en charge la surveillance MLD prennent en charge les rapports d’appartenance MLDv2 qui sont en mode INCLUDE et EXCLUDE.

Interfaces de transfert et de surveillance MLD

Pour déterminer comment transférer le trafic multicast, l’équipement sur lequel la surveillance MLD est activée conserve les informations sur les interfaces suivantes dans sa table de transfert multicast :

  • Interfaces de routeur multicast : ces interfaces mènent aux routeurs multicast ou aux interrogateurs MLD.

  • Interfaces membres du groupe : ces interfaces mènent vers des hôtes membres de groupes de multicast.

L’appareil apprend à connaître ces interfaces en surveillant le trafic MLD. Si une interface reçoit des requêtes MLD, l’équipement ajoute l’interface à sa table de transfert multicast en tant qu’interface de routeur multicast. Si une interface reçoit des rapports d’appartenance pour un groupe de multicast, l’équipement ajoute l’interface à sa table de transfert de multicast en tant qu’interface de membre de groupe.

Les entrées de tableau des interfaces apprises par l’appareil sont sujettes à un vieillissement cutané. Par exemple, si une interface de routeur de multicast apprise ne reçoit pas de requêtes MLD dans un certain intervalle, le périphérique supprime l’entrée de cette interface de sa table de transfert de multicast.

Remarque :

Pour que l’appareil apprenne les interfaces de routeur multicast et les interfaces membres du groupe, un interrogateur MLD doit exister dans le réseau. Pour que l’appareil lui-même fonctionne comme une requête MLD, MLD doit être activé sur l’appareil.

Vous pouvez configurer statiquement une interface en tant qu’interface de routeur multicast ou interface membre de groupe. L’équipement ajoute une interface statique à sa table de transfert multicast sans avoir à connaître l’interface, et l’entrée dans la table n’est pas sujette au vieillissement. Vous pouvez avoir une combinaison d’interfaces configurées statiquement et apprises dynamiquement sur l’appareil.

Règles générales de transfert

Le trafic multicast reçu sur l’interface de l’équipement dans un VLAN sur lequel la surveillance MLD est activée est transféré selon les règles suivantes.

Le trafic du protocole MLD est transféré comme suit :

  • Les requêtes MLD générales reçues sur une interface de routeur multicast sont transmises à toutes les autres interfaces du VLAN.

  • Les requêtes spécifiques au groupe MLD reçues sur une interface de routeur multicast sont transmises uniquement aux interfaces du VLAN membres du groupe.

  • Les rapports MLD reçus sur une interface hôte sont transférés aux interfaces de routeur multicast du même VLAN, mais pas aux autres interfaces hôtes du VLAN.

Le trafic multicast qui n’est pas du protocole MLD est transféré comme suit :

  • Un paquet de multicast non enregistré, c’est-à-dire un paquet pour un groupe qui n’a pas de membres actuels, est transféré à toutes les interfaces de routeur de multicast du VLAN.

  • Un paquet de multicast enregistré est transmis uniquement aux interfaces hôtes du VLAN membres du groupe de multicast et à toutes les interfaces de routeur de multicast du VLAN.

Remarque :

Lorsque la surveillance IGMP et MLD est activée sur le même VLAN, des interfaces de routeur multicast sont créées dans le cadre de la configuration de la surveillance IGMP et MLD. Le trafic de multicast non enregistré n’est pas bloqué et peut être transmis via des interfaces de routeur. Par conséquent, en raison de limitations matérielles, le trafic de multicast IPv4 non enregistré peut passer par les interfaces de routeur de multicast créées dans le cadre de la configuration de surveillance MLD, et le trafic de multicast IPv6 non enregistré peut passer par des interfaces de routeur de multicast créées dans le cadre de la configuration de surveillance IGMP.

Exemples de surveillance MLD Transfert multicast

Les exemples suivants sont fournis pour illustrer comment la surveillance MLD transfère le trafic multicast dans différentes topologies :

Scénario 1 : Transfert de trafic multicast d’un appareil vers un routeur et des hôtes multicast

Dans la topologie illustrée à la Figure 2, l’appareil agissant en tant que périphérique de couche 2 reçoit du trafic de multicast appartenant au groupe de multicast ff1e ::2010 de la source A, qui est connectée au routeur de multicast. Il reçoit également le trafic multicast appartenant au groupe multicast ff15 ::2 de la source B, qui est connecté directement à l’équipement. Toutes les interfaces de l’équipement appartiennent au même VLAN.

Étant donné que l’appareil reçoit des requêtes MLD du routeur de multicast sur l’interface P1, la surveillance MLD apprend que l’interface P1 est une interface de routeur multicast et ajoute l’interface à sa table de transfert de multicast. Il transfère toutes les requêtes MLD générales qu’il reçoit sur cette interface à toutes les interfaces hôtes du périphérique et, à son tour, transfère les rapports d’appartenance qu’il reçoit des hôtes à l’interface du routeur multicast.

Dans l’exemple, les hôtes A et C ont répondu aux requêtes générales avec des rapports d’appartenance pour le groupe ff1e ::2010. La surveillance MLD ajoute les interfaces P2 et P4 à sa table de transfert de multicast en tant qu’interfaces membres pour le groupe ff1e ::2010. Il transfère le trafic de multicast de groupe reçu de la source A aux hôtes A et C, mais pas aux hôtes B et D.

L’hôte B a répondu aux questions générales avec un rapport d’adhésion pour le groupe ff15 ::2. L’appareil ajoute l’interface P3 à sa table de transfert de multicast en tant qu’interface membre pour le groupe ff15 ::2 et transfère le trafic de multicast qu’il reçoit de la source B à l’hôte B. L’équipement transfère également le trafic de multicast qu’il reçoit de la source B à l’interface de routeur de multicast P1.

Figure 2 : Scénario 1 : Transfert de trafic multicast d’un appareil vers un routeur et des hôtes Multicast routing diagram: Multicast Router connects Sources A ff1e::2010 and B ff15::2 to Hosts A, B, C, and D. Arrows show traffic flow. multicast

Scénario 2 : Transfert de trafic multicast d’un appareil vers un autre équipement

Dans la topologie illustrée à la Figure 3, une source de multicast est connectée au périphérique A. Le périphérique A est à son tour connecté à un autre périphérique, le périphérique B. Les hôtes des périphériques A et B sont des membres potentiels du groupe de multicast. Les deux équipements agissent comme des équipements de couche 2 et toutes les interfaces des équipements sont membres du même VLAN.

Le périphérique A reçoit des requêtes MLD du routeur de multicast sur l’interface P1, ce qui fait de l’interface P1 une interface de routeur de multicast pour le périphérique A. Le périphérique A transfère toutes les requêtes générales qu’il reçoit sur cette interface aux autres interfaces du périphérique, y compris l’interface connectant le périphérique B. Étant donné que l’équipement B reçoit les requêtes MLD transférées sur l’interface P6, P6 est l’interface de routeur multicast pour l’équipement B. L’équipement B transfère le rapport d’appartenance qu’il reçoit de l’hôte C à l’équipement A via son interface de routeur multicast. Le périphérique A transfère le rapport d’appartenance à son interface de routeur de multicast, inclut l’interface P5 dans sa table de transfert de multicast en tant qu’interface de membre de groupe et transfère le trafic de multicast de la source au périphérique B.

Figure 3 : Scénario 2 : Transfert de trafic multicast d’un appareil vers un autre équipement Network topology diagram showing multicast communication: Source server sends multicast traffic through a router to Switch A and Switch B. Hosts A and B connect to Switch A; Hosts C and D connect to Switch B.

Dans certaines implémentations, vous devrez peut-être configurer P6 sur l’équipement B en tant qu’interface de routeur de multicast statique pour éviter un retard dans un hôte recevant du trafic de multicast. Par exemple, si l’appareil B reçoit des rapports d’appartenance non sollicités de ses hôtes avant d’apprendre quelle interface est son interface de routeur multicast, il ne transmet pas ces rapports à l’équipement A. Si le périphérique A reçoit ensuite du trafic de multicast, il ne le transfère pas au périphérique B, car il n’a reçu aucun rapport d’appartenance sur l’interface P5. Ce problème sera résolu lorsque le routeur de multicast enverra sa prochaine requête générale ; Cependant, cela peut entraîner un retard dans l’hôte recevant le trafic multicast. Vous pouvez configurer statiquement l’interface P6 en tant qu’interface de routeur multicast pour résoudre ce problème.

Scénario 3 : Périphérique connecté aux hôtes uniquement (aucune requête MLD)

Dans la topologie illustrée à la Figure 4, l’équipement est connecté à une source de multicast et à des hôtes. Il n’y a pas de routeur multicast dans cette topologie, donc pas de requête MLD. Sans interrogateur MLD auquel répondre, un hôte n’envoie pas de rapports d’adhésion périodiques. Par conséquent, même si l’hôte envoie un rapport d’appartenance non sollicité pour rejoindre un groupe de multicast, son appartenance au groupe de multicast expirera.

Pour que la surveillance MLD fonctionne correctement dans ce réseau, de sorte que l’équipement transfère le trafic multicast vers les hôtes A et C uniquement, vous pouvez soit :

  • Configurez les interfaces P2 et P4 en tant qu’interfaces statiques membres d’un groupe.

  • Configurez une interface RVI (Routed VLAN Interface), également appelée interface IRB (Integrated Routing and Bridging), sur le VLAN et activez MLD sur celle-ci. Dans ce cas, l’appareil lui-même agit en tant que requête MLD et les hôtes peuvent rejoindre dynamiquement le groupe de multicast et actualiser leur appartenance au groupe en répondant aux requêtes.

Figure 4 : Scénario 3 : Appareil connecté à des hôtes uniquement (aucune requête MLD) Network topology diagram showing data flow from a source device to multiple hosts through a switch in a LAN setup.

Scénario 4 : Appareil de couche 2/couche 3 transmettant du trafic multicast entre VLAN

Dans la topologie illustrée à la Figure 5, une source de multicast, le routeur multicast A et les hôtes A et B sont connectés à l’équipement et se trouvent dans le VLAN 10. Le routeur multicast B et les hôtes C et D sont également connectés à l’équipement et se trouvent dans le VLAN 20.

Dans un environnement de couche 2 pure, le trafic n’est pas transféré entre les VLAN. Pour que l’hôte C reçoive le trafic de multicast de la source sur le VLAN 10, des RVI (ou interfaces IRB) doivent être créées sur les VLAN 10 et VLAN 20 pour permettre le routage du trafic de multicast entre les VLAN.

Figure 5 : Scénario 4 : Appareil de couche 2/3 Transfert de trafic multicast entre VLAN Network topology with multicast routing and VLANs: Source 11.1.1.10 sends multicast traffic via Multicast Routers A and B to Hosts A and B on VLAN 10 and Hosts C and D on VLAN 20.

Comportement de surveillance MLD spécifique à la plate-forme

Utilisez l’explorateur de fonctionnalités pour confirmer la prise en charge de la plate-forme et de la version pour des fonctionnalités spécifiques.

Utilisez le tableau suivant pour examiner le comportement spécifique à votre plateforme.

Tableau 1 : comportement de surveillance MLD spécifique à la plate-forme

Plate-forme

Différence

Pare-feu SRX Series, commutateurs QFX Series et commutateurs EX Series exécutant une surveillance MLD, à l’exception des commutateurs EX9200

  • Ne prenez pas en charge le transfert par source. Au lieu de cela, l’équipement consolide tous les rapports des modes INCLUDE et EXCLUDE qu’il reçoit sur un VLAN pour un groupe spécifié en une seule route qui inclut toutes les sources de multicast pour ce groupe, le saut suivant étant toutes les interfaces qui ont des récepteurs intéressés pour le groupe. Par conséquent, les récepteurs intéressés sur le VLAN peuvent recevoir du trafic d’une source qu’ils n’ont pas incluse dans leur rapport INCLUDE ou d’une source qu’ils ont exclue dans leur rapport EXCLUDE. Par exemple, si l’hôte 1 veut du trafic pour le groupe G à partir de la source A et l’hôte 2 veut du trafic pour le groupe G à partir de la source B, ils reçoivent tous deux du trafic pour le groupe G, que A ou B envoie le trafic.

Documentation connexe