Vue d’ensemble de la surveillance IGMP

Avantages de la surveillance IGMP

• Optimized bandwidth utilization—Le principal avantage de l’espionnage IGMP est de réduire l’inondation de paquets. L’appareil transfère de manière sélective les données de multicast IPv4 vers une liste de ports qui souhaitent recevoir les données au lieu de les affecter à tous les ports d’un VLAN.

• Improved security: empêche les attaques par déni de service provenant de sources inconnues.

Fonctionnement de la surveillance IGMP

Les périphériques apprennent généralement les adresses MAC unicast en vérifiant le champ d’adresse source des trames qu’ils reçoivent, puis envoient le trafic de cette adresse unicast uniquement aux interfaces appropriées. Cependant, une adresse MAC multicast ne peut jamais être l’adresse source d’un paquet. Par conséquent, lorsqu’un équipement reçoit du trafic pour une adresse de destination de multidiffusion, il inonde le trafic sur le VLAN correspondant, envoyant une quantité importante de trafic pour laquelle il n’y a pas nécessairement de récepteurs intéressés.

La surveillance IGMP empêche cette inondation. Lorsque vous activez la surveillance IGMP, l’équipement surveille les paquets IGMP entre les récepteurs et les routeurs multicast et utilise le contenu des paquets pour créer une table de transfert multicast, c’est-à-dire une base de données des groupes multicast et des interfaces connectées aux membres des groupes. Lorsque l’équipement reçoit des paquets multicast, il utilise la table de transfert multicast pour transférer de manière sélective le trafic uniquement vers les interfaces connectées aux membres des groupes multicast appropriés.

Sur les commutateurs EX Series et QFX Series qui ne prennent pas en charge le style de configuration ELS (Enhanced L2 Software), la surveillance IGMP est activée par défaut sur tous les VLAN (ou uniquement sur le VLAN par défaut sur certains périphériques) et vous pouvez la désactiver de manière sélective sur un ou plusieurs VLAN. Sur tous les autres périphériques, vous devez explicitement configurer la surveillance IGMP sur un VLAN ou dans un domaine de pont pour l’activer.

Fonctionnement de la surveillance IGMP avec les interfaces VLAN routées

L’équipement peut utiliser une interface VLAN routée (RVI) pour transférer le trafic entre les VLAN de sa configuration. La surveillance IGMP fonctionne avec les interfaces de couche 2 et les RVI pour transférer le trafic multicast dans un réseau commuté.

Lorsque l’équipement reçoit un paquet multicast, ses moteurs de transfert de paquets effectuent une recherche multicast sur le paquet pour déterminer comment transférer le paquet vers ses interfaces locales. À partir des résultats de la recherche, chaque moteur de transfert de paquets extrait une liste d’interfaces de couche 3 qui ont des ports locaux dans le moteur de transfert de paquets. Si la liste inclut un RVI, l’équipement fournit un ID de groupe de multidiffusion de pont pour le RVI au moteur de transfert de paquets.

Pour les VLAN qui incluent des récepteurs multicast, l’ID de multicast de pont inclut un ID de sous-next-hop, qui identifie les interfaces de couche 2 du VLAN qui sont intéressées par la réception du flux multicast. Le moteur de transfert de paquets transfère ensuite le trafic multicast aux ID de multicast de pont qui ont des récepteurs multicast pour un groupe multicast donné.

Types de messages IGMP

Les routeurs de multidiffusion utilisent IGMP pour savoir quels groupes ont des auditeurs intéressés pour chacun de leurs réseaux physiques connectés. Dans un sous-réseau donné, un routeur multicast joue le rôle de requête IGMP. Le demandeur IGMP 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 : (IGMPv2 et IGMPv3 uniquement) Demande si un hôte écoute 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 : (IGMPv3 uniquement) Demande si un hôte écoute le trafic de multidiffusion de groupe provenant d’une source de multidiffusion 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 (IGMPv2 et IGMPv3 uniquement) indique que l’hôte souhaite quitter un groupe de multidiffusion particulier.

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

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

• En envoyant un message de jointure IGMP non sollicité à un routeur multicast qui spécifie le groupe multicast IP que l’hôte souhaite rejoindre.

• En envoyant un message de jointure IGMP en réponse à une requête générale d’un routeur multicast.

Un routeur multicast continue de transférer le trafic multicast vers un VLAN à condition qu’au moins un hôte de ce VLAN réponde aux requêtes IGMP générales périodiques. Pour qu’un hôte reste membre d’un groupe multicast, il doit continuer à répondre aux requêtes IGMP générales périodiques.

Les hôtes peuvent quitter un groupe de multidiffusion de l’une des deux manières suivantes :

• En ne répondant pas aux questions périodiques dans un intervalle de temps donné, ce qui est considéré comme un « congé silencieux ». Il s’agit de la seule méthode de congé pour les hôtes IGMPv1.

• En envoyant un rapport de congés. Cette méthode peut être utilisée par les hôtes IGMPv2 et IGMPv3.

Prise en charge des sources multicast IGMPv3

Dans IGMPv3, 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 périphériques qui prennent en charge IGMPv3 traitent les rapports d’appartenance INCLUDE et EXCLUDE, et la plupart des périphériques transfèrent le trafic SSM (source-specific multicast) uniquement à partir des sources demandées vers les récepteurs abonnés en conséquence. Toutefois, vous constaterez peut-être que l’appareil ne transfère pas strictement le trafic multicast source par source dans certaines configurations telles que :

• Commutateurs EX Series et QFX Series qui n’utilisent pas le style de configuration ELS (Enhanced L2 Software)

• Commutateurs EX2300 et EX3400 exécutant des versions de Junos OS antérieures à la version 18.1R2

• Commutateurs EX4300 exécutant les versions de Junos OS antérieures à 18.2R1, 18.1R2, 17.4R2, 17.3R3, 17.2R3 et 14.1X53-D47

• Passerelles de services SRX Series

Dans ce cas, l’équipement peut regrouper 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 multidiffusion de ce groupe, le saut suivant représentant 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 le trafic pour G à partir de la source A et que l’hôte 2 veut le trafic pour le groupe G à partir de la source B, ils reçoivent tous deux le trafic pour le groupe G, que A ou B envoie le trafic.

Interfaces de surveillance et de transfert IGMP

Pour déterminer comment transférer le trafic multicast, l’équipement sur lequel la surveillance IGMP 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 IGMP.

• 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 IGMP. Si une interface reçoit des requêtes IGMP ou des mises à jour PIM (Protocol Independent Multicast), 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 multicast, l’équipement ajoute l’interface à sa table de transfert multicast en tant qu’interface membre du groupe.

Les entrées de table d’interface apprises expirent au bout d’un certain temps. Par exemple, si une interface de routeur multicast apprise ne reçoit pas de requêtes IGMP ou de bonjours PIM 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é. Un appareil peut avoir un mélange d’interfaces configurées statiquement et apprises dynamiquement.

Règles générales de transfert

Une interface d’un VLAN sur laquelle la surveillance IGMP est activée reçoit le trafic multicast et le transfère selon les règles suivantes.

Trafic IGMP :

• Transférez les requêtes générales IGMP reçues sur une interface de routeur multicast à toutes les autres interfaces du VLAN.

• Transférez les requêtes spécifiques à un groupe IGMP reçues sur une interface de routeur multicast uniquement vers les interfaces du VLAN qui sont membres du groupe.

• Transférez les rapports IGMP reçus sur une interface hôte vers les interfaces de routeur multicast du même VLAN, mais pas vers les autres interfaces hôtes du VLAN.

Trafic multicast qui n’est pas du trafic IGMP :

• Inondez les paquets multicast dont l’adresse de destination est 233.252.0.0/24 vers toutes les autres interfaces du VLAN.

• Transférez les paquets multicast non enregistrés (paquets d’un groupe qui n’a pas de membres actuels) vers toutes les interfaces de routeur multicast du VLAN.

• Transférez les paquets multicast enregistrés vers les interfaces hôtes du VLAN qui sont membres du groupe multicast et vers toutes les interfaces de routeur multicast du VLAN.

Utilisation de l’appareil en tant qu’enquêteur IGMP

Avec l’espionnage IGMP sur un réseau local de niveau 2 pur (c’est-à-dire que la couche 3 n’est pas activée sur le réseau), si le réseau n’inclut pas de routeur multicast, le trafic multicast peut ne pas être correctement transféré via le réseau. Vous pouvez rencontrer ce problème si le réseau local est configuré de manière à ce que le trafic multicast doive être transféré entre les périphériques afin d’atteindre un récepteur multicast. Dans ce cas, un périphérique en amont ne transfère pas le trafic multicast vers un périphérique en aval (et donc vers les récepteurs multicast connectés au périphérique en aval) car le périphérique en aval ne transfère pas les rapports IGMP à l’équipement en amont. Vous pouvez résoudre ce problème en configurant l’un des périphériques pour qu’il soit un requier IGMP. Le périphérique de requête IGMP envoie périodiquement des paquets de requêtes générales à tous les périphériques du réseau, ce qui garantit que les tables d’appartenance à l’espionnage sont mises à jour et évite la perte de trafic multicast.

Si vous configurez plusieurs périphériques pour qu’ils soient des requeriers IGMP, l’appareil dont l’adresse source de requête IGMP est la plus basse (la plus petite) est prioritaire et agit en tant que requêteur. Les périphériques avec des adresses sources de requête IGMP plus élevées cessent d’envoyer des requêtes IGMP, sauf s’ils ne reçoivent pas de requêtes IGMP pendant 255 secondes. Si l’appareil avec une adresse source de requête IGMP plus élevée ne reçoit aucune requête IGMP pendant cette période, il recommence à envoyer des requêtes.

Pour configurer un périphérique afin qu’il agisse en tant que requête IGMP, entrez ce qui suit :

Pour configurer un commutateur de périphérique de nœud QFabric afin qu’il agisse en tant que demandeur IGMP, entrez ce qui suit :

Surveillance IGMP sur les VLAN privés (PVLAN)

Un PVLAN est constitué de VLAN secondaires, isolés et communautaires configurés au sein d’un VLAN principal. Sans la prise en charge de la surveillance IGMP sur les VLAN secondaires, les flux de multidiffusion reçus sur le VLAN principal sont inondés vers les VLAN secondaires.

À partir de Junos OS version 18.3R1, les commutateurs EX4300 et EX4300 Virtual Chassis prennent en charge la surveillance IGMP avec les PVLAN. À partir de Junos OS version 19.2R1, les commutateurs EX4300 multi-gigabit prennent en charge la surveillance IGMP avec des PVLAN. Lorsque vous activez la surveillance IGMP sur un VLAN principal, vous l’activez également implicitement sur tous les VLAN secondaires. L’équipement apprend et stocke les informations du groupe multicast sur le VLAN principal, ainsi que les informations du groupe multicast sur les VLAN secondaires dans le contexte du VLAN principal. En conséquence, l’appareil limite davantage les flux de multidiffusion aux seuls récepteurs intéressés sur les VLAN secondaires, plutôt que d’inonder le trafic dans tous les VLAN secondaires.

La CLI vous empêche de configurer explicitement la surveillance IGMP sur les VLAN secondaires isolés ou communautaires. Il vous suffit de configurer la surveillance IGMP sur le VLAN principal sous lequel les VLAN secondaires sont définis. Par exemple, pour un VLAN principal vlan-pri avec un VLAN secondaire isolé vlan-iso et un VLAN communautaire secondaire vlan-comm :

Les rapports IGMP et les messages de congé reçus sur les ports VLAN secondaires sont appris dans le contexte du VLAN principal. Les ports trunk ou les liaisons intercommutateurs de promiscuité agissant comme des interfaces de routeur multicast pour le PVLAN reçoivent les flux de données multicast entrants provenant de sources multicast et les transmettent uniquement aux ports VLAN secondaires avec des entrées de groupe multicast apprises.

Cette fonctionnalité ne prend pas en charge les ports VLAN secondaires en tant qu’interfaces de routeur multicast. La CLI ne vous empêche pas strictement de configurer statiquement une interface sur un VLAN communautaire en tant que port de routeur multicast, mais la surveillance IGMP ne fonctionne pas correctement sur les PVLAN avec cette configuration. Lorsque la surveillance IGMP est configurée sur un PVLAN, le commutateur désactive également automatiquement l’apprentissage dynamique des ports de routeur multicast sur toutes les interfaces VLAN isolées ou communautaires. La surveillance IGMP avec les PVLAN ne prend pas non plus en charge les configurations avec un demandeur IGMP sur les interfaces VLAN isolées ou communautaires.

Pour plus d’informations sur la configuration des PVLAN, reportez-vous aux sections Comprendre les VLAN privés et créer un VLAN privé couvrant plusieurs commutateurs EX Series avec prise en charge ELS (procédure CLI).