Comprendre l’espionnage MLD

Avantages de MLD Snooping

• Optimized bandwidth utilization—Le principal avantage de l’espionnage MLD est de réduire l’inondation des paquets. Les données de multicast IPv6 sont transférées de manière sélective vers 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 MLD Snooping

Par défaut, l’appareil inonde le trafic multicast de couche 2 sur toutes les interfaces appartenant à ce VLAN sur l’équipement, à l’exception de l’interface qui est la source du trafic 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’é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 transfert multicast IPv6, c’est-à-dire une base de données des groupes multicast IPv6 et des interfaces connectées aux membres intéressés de chaque groupe. Lorsque l’équipement reçoit du trafic multicast pour un groupe multicast, il utilise la table de transfert pour transférer le trafic uniquement vers les interfaces connectées à des récepteurs appartenant au groupe 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 MLD Snooping activé

Types de messages MLD

Les routeurs multicast utilisent MLD pour apprendre, pour chacun des réseaux physiques qui leur sont rattachés, quels groupes d’auditeurs sont intéressés. Dans un sous-réseau donné, un routeur multicast est choisi pour agir en tant que requête MLD. Le requêteur 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 est à l’écoute d’un groupe de multidiffusion spécifique. Cette requête est envoyée lorsqu’un hôte quitte le groupe de multidiffusion et permet au routeur de déterminer rapidement si les 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 multicast de groupe à 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é à recevoir du trafic multicast de groupe à partir de la source multicast et permet au routeur de déterminer rapidement si les hôtes restants sont intéressés à recevoir du trafic 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 multidiffusion particulier.

• Quitter le rapport : indique que l’hôte souhaite quitter un groupe de multidiffusion 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 veulent rejoindre ou quitter un groupe. Toutefois, par souci de simplicité, la documentation d’espionnage MLD utilise le terme rapport d’appartenance pour un rapport qui indique qu’un hôte veut rejoindre un groupe et utilise le terme rapport de congé pour un rapport qui indique qu’un hôte veut quitter un groupe.

Comment les hôtes rejoignent-ils et quittent-ils des groupes multicast ?

Les hôtes peuvent rejoindre des groupes de multidiffusion de l’une des deux manières suivantes :

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

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

Un routeur multicast continue de transférer 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 appartenance. 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 de multidiffusion de l’une des deux manières suivantes :

• 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és.

Prise en charge des sources multicast MLDv2

Dans MLDv2, un hôte peut envoyer un rapport d’appartenance qui inclut une liste d’adresses source. Lorsque l’hôte envoie un rapport d’appartenance en mode INCLUDE, il s’intéresse au trafic 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 multicast de groupe provenant 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, ce qui est connu sous le nom de rapport EXCLUDE NULL. Un rapport EXCLUDE NULL indique que l’hôte souhaite rejoindre le groupe de multidiffusion et recevoir des paquets de toutes les sources.

Les appareils qui prennent en charge l’écoute MLD prennent en charge les rapports d’appartenance MLDv2 qui sont en mode INCLUDE et EXCLUDE. Toutefois, les pare-feu SRX Series, les commutateurs QFX Series et les commutateurs EX Series exécutant MLD snooping, à l’exception des commutateurs EX9200, ne prennent pas en charge le transfert par source. Au lieu de cela, l’équipement consolide tous les rapports en mode 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 de 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 souhaite le trafic du groupe G à partir de la source A et que l’hôte 2 souhaite le trafic du groupe G à partir de la source B, ils reçoivent tous deux le trafic du groupe G, que A ou B envoie le trafic.

Interfaces de surveillance et de transfert 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 à des routeurs multicast ou à des requêtes MLD.

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

L’appareil apprend l’existence de 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 multicast-router. Si une interface reçoit des rapports d’appartenance pour un groupe multicast, l’équipement ajoute l’interface à sa table de transfert multicast en tant qu’interface membre du groupe.

Les entrées de table pour les interfaces que l’appareil apprend sont sujettes à l’ancienneté. Par exemple, si une interface de routeur multicast apprise ne reçoit pas de requêtes MLD dans un certain intervalle, l’équipement supprime l’entrée de cette interface de sa table de transfert multicast.

Vous pouvez configurer statiquement une interface pour qu’elle soit une interface de routeur multicast ou une interface de membre de groupe. L’équipement ajoute une interface statique à sa table de transfert multicast sans avoir à en apprendre davantage sur l’interface, et l’entrée dans la table n’est pas sujette à l’ancienneté. Vous pouvez avoir un mélange 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’appareil 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 générales MLD 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 qui sont 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 qui n’est pas du protocole MLD est transféré comme suit :

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

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

Exemples de transfert de multicast MLD Snooping

Les exemples suivants illustrent comment l’écoute MLD transfère le trafic multicast dans différentes topologies :

• Scénario 1 : Transfert de trafic multicast d’un périphérique vers un routeur et des hôtes multicast
• Scénario 2 : Transfert de trafic multicast vers un autre équipement
• Scénario 3 : Appareil connecté à des hôtes uniquement (pas de requête MLD)
• Scénario 4 : transfert de trafic multicast entre VLAN par un périphérique de couche 2/3

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

Dans la topologie illustrée sur la Figure 2, l’équipement agissant en tant qu’équipement de couche 2 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 connectée directement à l’appareil. Toutes les interfaces de l’appareil appartiennent au même VLAN.

Étant donné que l’équipement reçoit des requêtes MLD du routeur multicast sur l’interface P1, MLD snooping apprend que l’interface P1 est une interface de routeur multicast et ajoute l’interface à sa table de transfert multicast. Il transfère toutes les requêtes générales MLD qu’il reçoit sur cette interface à toutes les interfaces hôtes de l’appareil et, à son tour, transfère les rapports d’appartenance qu’il reçoit des hôtes à 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’appartenance pour le groupe ff1e ::2010. MLD snooping ajoute les interfaces P2 et P4 à son table de transfert multicast en tant qu’interfaces membres pour le groupe ff1e ::2010. Il transfère 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 questions générales avec un rapport d’appartenance pour le groupe ff15 ::2. L’équipement ajoute l’interface P3 à son table de transfert multicast en tant qu’interface membre du groupe ff15 ::2 et transfère le trafic multicast qu’il reçoit de la source B à l’hôte B. L’appareil transfère également le trafic multicast qu’il reçoit de la source B à l’interface de routeur multicast P1.

Figure 2 : Scénario 1 : Périphérique transférant du trafic multicast vers un routeur et des hôtes multicast

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

Dans la topologie illustrée à la Figure 3, une source de multidiffusion est connectée à l’appareil A. L’appareil A est à son tour connecté à un autre appareil, l’appareil B. Les hôtes des appareils A et B sont des membres potentiels du groupe de multidiffusion. Les deux appareils agissent comme des appareils de couche 2 et toutes les interfaces des appareils sont membres du même VLAN.

L’appareil A reçoit les requêtes MLD du routeur multicast sur l’interface P1, ce qui fait de l’interface P1 une interface de routeur multicast pour l’appareil A. L’appareil A transfère toutes les requêtes générales qu’il reçoit sur cette interface aux autres interfaces de l’appareil, y compris l’interface reliant l’appareil B. Étant donné que l’appareil B reçoit les requêtes MLD transférées sur l’interface P6, P6 est l’interface de routeur multicast de l’appareil B. L’appareil B transmet 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 transmet le rapport d’appartenance à son interface de routeur multicast, inclut l’interface P5 dans sa table de transfert multicast en tant qu’interface membre du groupe et transfère le trafic multicast de la source vers le périphérique B.

Figure 3 : Scénario 2 : Périphérique transférant du trafic multicast vers un autre périphérique

Dans certaines implémentations, vous devrez peut-être configurer P6 sur le périphérique B en tant qu’interface de routeur multicast statique pour éviter un retard dans la réception du trafic multicast par un hôte. 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’appareil A. Si le périphérique A reçoit ensuite du trafic multicast, il ne le transfère pas vers le 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 multicast enverra sa prochaine requête générale ; Toutefois, cela peut retarder la réception du trafic multicast par l’hôte. Vous pouvez configurer statiquement l’interface P6 en tant qu’interface de routeur multicast pour résoudre ce problème.

Scénario 3 : Appareil connecté à des hôtes uniquement (pas de requête MLD)

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

Pour que la surveillance MLD fonctionne correctement dans ce réseau et que l’appareil 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 de membres de groupe.

• Configurez une interface VLAN routée (RVI), également appelée interface de routage et de pontage intégrés (IRB), sur le VLAN et activez MLD sur celle-ci. Dans ce cas, l’appareil lui-même agit comme une requête MLD et les hôtes peuvent rejoindre dynamiquement le groupe de multidiffusion et actualiser leur appartenance au groupe en répondant aux requêtes.

Figure 4 : Scénario 3 : Périphérique connecté à des hôtes uniquement (pas de requête MLD)

Scénario 4 : transfert de trafic multicast entre VLAN par un périphérique de couche 2/3

Dans la topologie illustrée à la figure 5, une source de multidiffusion, le routeur de multidiffusion A et les hôtes A et B sont connectés à l’appareil et se trouvent dans le VLAN 10. Le routeur multicast B et les hôtes C et D sont également connectés à l’appareil 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 multicast de la source sur le VLAN 10, des RVI (ou interfaces IRB) doivent être créées sur les VLAN 10 et VLAN 20 afin de permettre le routage du trafic multicast entre les VLAN.

Figure 5 : Scénario 4 : transfert de trafic multicast entre VLAN d’un appareil de couche 2/3