Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Compréhension de la snooping MLD

La snooping Multicast Listener Discovery (MLD) limite l’diffusion du trafic multicast IPv6 sur les réseaux VLAN. Lorsque la fonction de contrôle MLD est activée sur un VLAN, un équipement Juniper Networks examine les messages MLD entre les hôtes et les routeurs multicast et apprend quels hôtes souhaitent recevoir du trafic pour un groupe multicast. Au lieu d’inonder le trafic multicast sur toutes les interfaces du VLAN, l’équipement n’est alors connecté qu’aux récepteurs intéressés.

La snooping MLD prend en charge les programmes MLD version 1 (MLDv1) et MLDv2. Pour plus d’informations sur les mlDv1 et MLDv2, consultez les normes suivantes:

  • MLDv1— Découvrez RFC 2710, Multicast Listener Discovery (MLD) pour IPv6.

  • MLDv2— Voir RFC 3810, Multicast Listener Discovery Version 2 (MLDv2) pour IPv6.

Avantages de la snooping MLD

  • Optimized bandwidth utilization—Le principal avantage de la snooping MLD est de réduire les risques d’inondation de paquets. Les données multicast IPv6 sont, de manière sélective, transmis à une liste de ports qui souhaitent recevoir ces données, plutôt que d’être inondables vers tous les ports d’un VLAN.

  • Improved security—Les attaques par déni de service provenant de sources inconnues sont évités.

Fonctionnement de la snooping MLD

Par défaut, l’équipement inonde toutes les interfaces du VLAN du trafic multicast de couche 2, à l’exception de l’interface source du trafic multicast. Ce comportement peut consommer d’importantes quantités de bande passante.

Vous pouvez activer la snooping MLD pour éviter cette inondation. Lorsque vous activez la surveillance MLD, l’équipement surveille les messages MLD entre les récepteurs (hôtes) et les routeurs multicast et utilise le contenu des messages pour créer une table de diffusion multicast IPv6, une base de données de groupes multicast IPv6 et les interfaces connectées aux membres intéressés de chaque groupe. Lorsque l’équipement reçoit du trafic multicast pour un groupe de multicast, il utilise la table de diffusion pour ne faire avancer le trafic que sur les interfaces connectées aux récepteurs appartenant au groupe multicast.

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

Figure 1: Multicast Traffic Flow with MLD Snooping Enabled (En savoir plus Multicast Traffic Flow with MLD Snooping Enabled)

Types de messages MLD

Les routeurs multicast utilisent le MLD pour apprendre, pour chacun de leurs réseaux physiques associés, quels groupes ont des écouteurs intéressés. Dans un sous-réseau donné, un routeur multicast est choisi pour jouer le rôle de querier MLD. Le querier MLD envoie les types de requêtes suivants à des hôtes:

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

  • 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 multicast et permet au routeur de déterminer rapidement si les hôtes restants s’intéressent au groupe.

  • Requêtes spécifiques aux groupes et aux sources (MLD version 2 uniquement) Demande si un hôte écoute le trafic multicast groupé à partir d’une source 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 du trafic multicast de groupe à partir de la source multicast et permet au routeur de déterminer rapidement les hôtes restants qui souhaitent recevoir du trafic multicast de groupe à partir de cette source.

Les hôtes qui écoutent les écouteurs en multicast envoient les types de messages suivants:

  • Rapport d’adhésion: indique que l’hôte souhaite rejoindre un groupe multicast particulier.

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

Seuls les hôtes MLDv1 utilisent deux types de rapports différents pour indiquer s’ils souhaitent rejoindre un groupe ou en quitter. Les hôtes MLDv2 n’envoient qu’un seul type de rapport dont le contenu indique s’ils souhaitent rejoindre un groupe ou en quitter. Toutefois, pour plus de simplicité, la documentation de snooping MLD utilise le rapport d’adhésion à l’utilisation d’un rapport qui indique qu’un hôte souhaite rejoindre un groupe et utilise le terme « leave report » pour un rapport qui indique qu’un hôte souhaite quitter un groupe.

Comment les hôtes rejoignent et quittent des groupes multicast

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

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

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

Un routeur multicast continue de faire avancer le trafic multicast vers une interface à condition qu’au moins un hôte de cette interface réponde aux requêtes générales périodiques indiquant son adhésion. Pour qu’un hôte reste membre d’un groupe multicast, il doit donc continuer à répondre aux requêtes générales périodiques.

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

  • En ne répondant pas aux requêtes périodiques dans un intervalle donné. Ceci entraîne ce qu’on appelle le « laisser-faire silencieux ».

  • Envoyez un rapport de départ.

Note:

Si un hôte est connecté à l’équipement par le biais d’un hub, l’hôte ne quittera pas automatiquement le groupe de multicast s’il se déconnecte du hub. L’hôte reste membre du groupe jusqu’à ce que les horaires d’utilisation du groupe soient difficiles et qu’un laissez-faire silencieux se produise. Si un autre hôte se connecte au port du hub avant que le départ silencieux ne se produise, ce dernier peut recevoir le trafic multicast du groupe jusqu’au départ silencieux, même s’il n’a jamais envoyé de rapport d’adhésion.

Prise en charge des sources multicast MLDv2

Dans le mlDv2, un hôte peut envoyer un rapport d’adhésion comprenant une liste d’adresses source. Lorsque l’hôte envoie un rapport d’adhésion en mode INCLURE, l’hôte s’intéresse au trafic multicast de groupe uniquement en provenance de ces sources dans la liste d’adresses source. Si l’hôte envoie un rapport d’adhésion en mode EXCLUDE, l’hôte s’intéresse au trafic multicast de groupe en provenance 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 de la liste source est vide, connu sous le nom de rapport EXCLUDE NULL. Un rapport NULL D’EXCLUSION indique que l’hôte souhaite rejoindre le groupe multicast et recevoir des paquets de toutes les sources.

Les équipements qui supportent la snooping MLD supportent les rapports d’adhésion MLDv2 en mode INCLURE et EXCLURE. Toutefois, les équipements SRX Series, les commutateurs QFX Series et les commutateurs EX Series exécutant la snooping MLD, à l’exception des commutateurs EX9200, n’appuient pas le transfert par source. Au lieu de cela, l’équipement consolide tous les rapports de mode INCLUDE et EXCLUDE qu’il reçoit sur un VLAN pour un groupe spécifié en un seul route qui inclut toutes les sources multicast pour ce groupe, le saut suivant étant toutes les interfaces qui ont des récepteurs intéressés pour le groupe. Ainsi, les récepteurs intéressés du VLAN peuvent recevoir du trafic provenant d’une source qu’ils n’ont pas inclus dans leur rapport INCLUDE ou d’une source qu’ils ont exclu dans leur rapport EXCLUDE. Par exemple, si l’hôte 1 souhaite recevoir du trafic pour le groupe G à partir de la source A et l’hôte 2 souhaite le trafic du groupe G à partir de la source B, tous deux reçoivent du trafic pour le groupe G, que A ou B envoie le trafic.

Interfaces de snooping et de forwarding MLD

Pour déterminer la façon de forwarder le trafic multicast, l’équipement avec la snooping MLD activé conserve des informations sur les interfaces suivantes dans sa table de forwarding multicast:

  • Interfaces de routeur multicast: ces interfaces mènent à des routeurs multicast ou des queriers MLD.

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

Pour en savoir plus sur ces interfaces, l’équipement surveille le trafic MLD. Si une interface reçoit des requêtes MLD, l’équipement ajoute l’interface à sa table de diffusion multicast en tant qu’interface de routeur multicast. Si une interface reçoit des rapports d’adhésion pour un groupe multicast, l’équipement ajoute l’interface à sa table de diffusion multicast en tant qu’interface de membre du groupe.

Les entrées du tableau pour les interfaces que l’équipement apprend sont sujettes à un âge. Par exemple, si une interface de multicast-routeur apprise ne reçoit pas de requêtes MLD dans un certain intervalle, l’équipement retire l’entrée de cette interface de sa table de forwarding multicast.

Note:

Pour que l’équipement apprenne à utiliser les interfaces de routeur multicast et les interfaces des membres du groupe, un querier MLD doit exister dans le réseau. Pour que l’équipement lui-même fonctionne comme un quedeur MLD, le MLD doit être activé sur l’équipement.

Vous pouvez configurer de manière statique une interface en tant qu’interface multicast-routeur ou interface membre d’un groupe. L’équipement ajoute une interface statique à sa table de diffusion multicast sans avoir à en savoir plus sur l’interface, et l’entrée dans la table ne peut pas être vieillissante. Vous pouvez utiliser un mélange d’interfaces d’enseignement dynamique et de configuration statique sur l’équipement.

Règles générales d’adage

Le trafic multicast reçu sur l’interface de l’équipement dans un VLAN sur lequel la snooping MLD est activée est transmis conformément aux règles suivantes.

Le trafic des protocoles MLD est transmis de la manière suivante:

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

  • Seules les requêtes de groupe MLD reçues sur une interface de routeur multicast sont uniquement les interfaces du VLAN membres du groupe.

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

Le trafic multicast non MLD est transmis comme suit:

  • Un paquet multicast non enregistré, c’est-à-dire un paquet pour un groupe sans membre actuel, est transmis à toutes les interfaces de routeur multicast du VLAN.

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

Note:

Lorsque igMP et la snooping MLD sont tous deux activés sur le même VLAN, des interfaces multicast-routeur sont créées dans le cadre d’une configuration de snooping IGMP et MLD. Le trafic multicast non enregistré n’est pas bloqué et peut être transmis via les interfaces de routeur; en raison de limitations matérielles, le trafic multicast IPv4 non enregistré peut être transmis via les interfaces de routeur multicast créées dans le cadre d’une configuration de contrôle MLD, et le trafic multicast IPv6 non enregistré peut passer par des interfaces de routeur multicast créées dans le cadre de la configuration de contrôle IGMP.

Exemples de forwarding multicast de snooping MLD

Les exemples suivants sont fournis pour illustrer comment la snooping MLD permet de suivre le trafic multicast dans différentes topologies:

Scénario 1: Trafic multicast de l’équipement vers un routeur et des hôtes multicast

Sur la topologie indiquée sur la Figure 2, l’équipement joue le rôle d’un équipement de couche 2 et reçoit du trafic multicast appartenant au groupe multicast ff1e::2010 de la source A, qui est connectée au routeur multicast. Il reçoit également le trafic multicast appartenant au groupe multicast ff15::2 de la source B, qui est directement connecté à l’équipement. Toutes les interfaces de l’équipement appartiennent au même VLAN.

Étant donné que l’équipement reçoit des requêtes MLD depuis le routeur multicast de l’interface P1, la fonction de snooping MLD apprend que l’interface P1 est une interface de multicast et ajoute l’interface à sa table de forwarding multicast. Il présente toutes les requêtes générales MLD qu’il reçoit sur cette interface vers toutes les interfaces hôtes de l’équipement, puis il permet à son tour de faire part des rapports de membre qu’il reçoit des hôtes vers l’interface de routeur multicast.

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

L’hôte B a répondu aux requêtes générales en 2015, en 2015, en 2015, par un rapport d’adhésion. L’équipement ajoute l’interface P3 à sa table de forwarding multicast en tant qu’interface membre pour le trafic ff15:2 de groupe et permet le trafic multicast qu’il reçoit de la source B à l’hôte B. L’équipement permet également de faire avancer le trafic multicast qu’il reçoit de la source B vers l’interface de routeur multicast P1.

Figure 2: Scénario 1: Trafic multicast de l’équipement transmis à un routeur et des hôtes Scenario 1: Device Forwarding Multicast Traffic to a Multicast Router and Hosts multicast

Scénario 2: Trafic multicast de l’équipement transmis à un autre équipement

Sur la topologie de la figure 3, une source multicast est connectée à l’équipement A. L’équipement A est lui-même connecté à un autre équipement, l’équipement B. Les hôtes des deux équipements A et B sont des membres potentiels du groupe multicast. Les deux équipements jouent le rôle d’équipements de couche 2 et toutes les interfaces des équipements sont membres du même VLAN.

L’équipement A reçoit des requêtes MLD depuis le routeur multicast de l’interface P1, ce qui fait de l’interface P1 une interface multicast pour l’équipement A. L’équipement A a transmis toutes les requêtes générales qu’il reçoit sur cette interface aux autres interfaces de l’équipement, y compris l’interface de connexion de l’équipement B. L’équipement B reçoit les requêtes MLD sur l’interface P6, et le P6 est l’interface multicast du routeur de l’équipement B. L’équipement B reporte le rapport d’adhésion qu’il reçoit de l’hôte C à l’équipement A par le biais de son interface de routeur multicast. L’équipement A reporte le rapport de membre à son interface de routeur multicast, inclut l’interface P5 dans sa table de forwarding multicast en tant qu’interface de groupe, puis le trafic multicast de la source vers l’équipement B.

Figure 3: Scénario 2: Trafic multicast de l’équipement transmis à un autre équipement Scenario 2: Device Forwarding Multicast Traffic to Another Device

Dans certaines implémentations, vous pouvez devoir configurer P6 sur l’équipement B en tant qu’interface multicast statique pour éviter tout retard dans un trafic multicast de réception d’hôte. Par exemple, si l’équipement B reçoit des rapports d’adhésion non sollicités de la part de ses hôtes avant d’apprendre quelle interface est son interface multicast-routeur, il ne les a pas transmis à l’équipement A. Si l’équipement A reçoit alors du trafic multicast, il ne le signale pas à l’équipement B, car il n’a reçu aucun rapport d’adhésion sur l’interface P5. Ce problème sera résolu lorsque le routeur multicast envoie sa prochaine requête générale ; cependant, il peut entraîner un délai pour l’hôte qui reçoit le trafic multicast. Pour résoudre ce problème, vous pouvez configurer statiquement l’interface P6 en tant qu’interface de routeur multicast.

Scénario 3: Équipement connecté aux hôtes uniquement (pas de querier MLD)

Sur la topologie de la figure 4, l’équipement est connecté à une source multicast et aux hôtes. Il n’y a pas de routeur multicast dans cette topologie. Par conséquent, il n’y a pas de querier MLD. Sans que le mlD ne réponde à ces questions, un hôte n’envoie pas de rapports d’adhésion périodiques. En conséquence, même si l’hôte envoie un rapport d’adhésion non sollicité pour rejoindre un groupe multicast, son adhésion au groupe de multicast s’en trouvera ad hors délai.

Pour que la snooping MLD fonctionne correctement dans ce réseau afin que l’équipement puisse uniquement avancer le trafic multicast vers les hôtes A et C, vous pouvez:

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

  • Configurez une interface VLAN routage (RVI), également appelée interface de routage et de pontage intégré, sur le VLAN et activez le MLD dessus. Dans ce cas, l’équipement fait office de quedeur MLD et les hôtes peuvent rejoindre le groupe multicast de manière dynamique et actualiser leur statut de groupe en répondant aux requêtes.

Figure 4: Scénario 3: Connexion de l’équipement aux hôtes uniquement (pas de querier MLD) Scenario 3: Device Connected to Hosts Only (No MLD Querier)

Scénario 4: Trafic multicast de couche 2/couche 3 entre les VLANs

Sur la topologie de la figure 5, les hôtes A et A et B d’une source multicast sont connectés à l’équipement et se connectent au VLAN 10. Le routeur multicast B et les hôtes C et D sont également connectés à l’équipement et se connectent au VLAN 20.

Dans un environnement de couche 2 pur, le trafic n’est pas transmis entre les VLANs. Pour que l’hôte C reçoit le trafic multicast à partir de la source sur le VLAN 10, les RTO (ou interfaces IRB) doivent être créées sur les réseaux VLAN 10 et VLAN 20 afin de permettre le routage du trafic multicast entre les VLAN.

Figure 5: Scénario 4: Trafic multicast de couches 2 et 3 entre les VLANs Scenario 4: Layer 2/Layer 3 device Forwarding Multicast Traffic Between VLANs