Exemple : Configuration de la surveillance IGMP

Les équipements réseau tels que les routeurs fonctionnent principalement au niveau des paquets, ou couche 3. D’autres périphériques réseau, tels que les ponts ou les commutateurs LAN, fonctionnent principalement au niveau de la trame, ou de la couche 2. Le multicast fonctionne principalement au niveau des paquets, la couche 3, mais il existe un moyen de mapper les adresses de groupe de multicast IP de couche 3 aux adresses de groupe de multicast MAC de couche 2 au niveau de la trame.

Les routeurs peuvent gérer les informations d’adressage de couche 2 et de couche 3, car la trame et ses adresses doivent être traitées pour accéder au paquet encapsulé à l’intérieur. Les routeurs peuvent exécuter des protocoles multicast de couche 3 tels que PIM ou IGMP et déterminer où transférer le contenu multicast ou quand un hôte d’une interface rejoint ou quitte un groupe. Cependant, les ponts et les commutateurs LAN, en tant qu’appareils de couche 2, ne sont pas censés avoir accès aux informations multicast contenues dans les paquets transportés par leurs trames.

Comment les ponts et les autres équipements de couche 2 peuvent-ils déterminer quand un périphérique d’une interface rejoint ou quitte une arborescence multicast, ou si un hôte sur un LAN connecté souhaite recevoir le contenu d’un groupe multicast particulier ?

La solution est que l’appareil de couche 2 implémente la surveillance multicast. La surveillance multicast est un terme général qui s’applique au processus par lequel un périphérique de couche 2 « surveille » le contenu du paquet de couche 3 pour déterminer les actions à effectuer pour traiter ou transmettre une trame. Il existe des formes plus spécifiques d’espionnage, telles que l’espionnage IGMP ou l’espionnage PIM. Dans tous les cas, l’espionnage implique qu’un appareil configuré pour fonctionner au niveau de la couche 2 ait accès à des informations de couche 3 (paquets) normalement « interdites ». La surveillance rend le multicast plus efficace dans ces appareils.

L’espionnage est un moyen général pour les équipements de couche 2, tels que les routeurs de services Ethernet MX Series de Juniper Networks, de mettre en œuvre une série de procédures pour « fouiner » le contenu des paquets de couche 3 afin de déterminer les actions à effectuer pour traiter ou transmettre une trame. Des formes plus spécifiques d’espionnage, telles que l’écoute IGMP (Internet Group Membership Protocol) ou l’écoute PIM (Protocol Independent Multicast), sont utilisées avec le multicast.

Les périphériques de couche 2 (commutateurs ou ponts LAN) gèrent les paquets multicast et les trames qui les contiennent, de la même manière que les périphériques de couche 3 (routeurs) gèrent les diffusions. Ainsi, un commutateur de couche 2 traite une trame entrante ayant une adresse MAC (Media Access Control) de destination multicast en transférant une copie du paquet (trame) sur chacune des autres interfaces réseau du commutateur qui sont dans un état de transfert.

Cependant, cette approche (envoyer des trames multicast partout où l’appareil le peut) n’est pas l’utilisation la plus efficace de la bande passante du réseau, en particulier pour les applications IPTV. La surveillance IGMP fonctionne en « espionnant » les paquets IGMP reçus par les interfaces de commutation et en construisant une base de données multicast similaire à celle qu’un routeur multicast construit dans un réseau de couche 3. À l’aide de cette base de données, le commutateur ne peut transférer le trafic multicast que sur les interfaces en aval avec les récepteurs intéressés, ce qui permet une utilisation plus efficace de la bande passante du réseau.

Vous configurez la surveillance IGMP pour chaque pont sur le routeur. Une instance de pont sans apprentissage qualifié n’a qu’un seul domaine d’apprentissage. Dans le cas d’une instance de pont avec apprentissage qualifié, l’écoute fonctionne séparément au sein de chaque domaine d’apprentissage du pont. En d’autres termes, la surveillance IGMP et le transfert multicast se dérouleront indépendamment dans chaque domaine d’apprentissage du pont.

Cette discussion se concentre sur les instances de pont sans apprentissage qualifié (celles qui forment un domaine d’apprentissage sur l’appareil). Par conséquent, toutes les interfaces mentionnées sont des interfaces logiques du pont ou de l’instance VPLS.

Plusieurs concepts connexes sont importants lorsque l’on discute de la surveillance IGMP :

• Les interfaces de pont ou d’instance VPLS sont soit des interfaces de routeur multicast, soit des interfaces côté hôte.

• La surveillance IGMP prend en charge le mode proxy ou le mode sans-proxy.

Si une interface IRB est utilisée comme interface sortante dans une entrée de cache de transfert multicast (telle que déterminée par le processus de routage), la liste des interfaces de sortie est étendue à un sous-ensemble de l’interface de couche 2 dans le pont correspondant. Le sous-ensemble est basé sur les informations d’appartenance à la multidiffusion snoopée, en fonction de l’entrée du cache de transfert multicast installée par le processus d’écoute pour le pont.

Si aucune surveillance n’est configurée, la liste des interfaces de sortie IRB est étendue à toutes les interfaces de couche 2 du pont.

Junos OS ne prend pas en charge la surveillance IGMP dans une configuration VPLS sur un commutateur virtuel. Cette configuration n’est pas autorisée dans l’interface de ligne de commande.

La surveillance IGMP divise les interfaces de l’appareil en interfaces de routeur multicast et en interfaces côté hôte. Une interface de routeur multicast est une interface dans la direction d’un routeur multicast. Une interface sur le pont est considérée comme une interface de routeur multicast si elle répond à au moins un des critères suivants :

• Il est configuré de manière statique en tant qu’interface de routeur multicast dans l’instance de pont.

• Les requêtes IGMP sont reçues sur l’interface.

Toutes les autres interfaces qui ne sont pas des interfaces de routeur multicast sont considérées comme des interfaces côté hôte.

Tout trafic multicast reçu sur une interface de pont pour laquelle la surveillance IGMP est configurée sera transféré selon les règles suivantes :

• Tout paquet IGMP est envoyé au moteur de routage pour traitement par espionnage.

• Le trafic multicast supplémentaire dont l’adresse de destination est 224.0.0/24 est inondé sur toutes les autres interfaces du pont.

• Le reste du trafic multicast est envoyé à toutes les interfaces multicast-router, mais uniquement aux interfaces côté hôte pour lesquelles des hôtes sont intéressés à recevoir ce groupe multicast.

En l’absence d’accord de proxy, la surveillance IGMP ne génère ni n’introduit de requêtes ni de rapports. Il ne fera qu’espionner les rapports reçus de toutes ses interfaces (y compris les interfaces de routeur multicast) pour construire sa base de données d’états et de groupes (S,G).

Sans proxy, les messages IGMP sont traités comme suit :

• Query (Requête) : tous les messages de requête IGMP généraux et spécifiques au groupe reçus sur une interface de routeur multicast sont transférés à toutes les autres interfaces (à la fois les interfaces de routeur multicast et les interfaces côté hôte) sur le pont.

• Report (Rapport) : les rapports IGMP reçus sur n’importe quelle interface du pont sont transmis à d’autres interfaces de routeur multicast. L’interface de réception est ajoutée en tant qu’interface pour ce groupe si une entrée de routage multicast existe pour ce groupe. De plus, un minuteur de groupe est défini pour le groupe sur cette interface. Si ce minuteur expire (c’est-à-dire qu’il n’y a pas eu de rapport pour ce groupe pendant la période du minuteur de groupe IGMP), l’interface est supprimée en tant qu’interface pour ce groupe.

• Leave (Quitter) : les messages d’arrêt IGMP reçus sur n’importe quelle interface du pont sont transférés vers d’autres interfaces de routeur multicast sur le pont. Le message Quitter le groupe réduit le temps nécessaire au routeur multicast pour arrêter de transférer le trafic multicast lorsqu’il n’y a plus aucun membre dans le groupe hôte.

L’écoute de proxy réduit le nombre de rapports IGMP envoyés à un routeur IGMP.

En tant que proxy pour ses interfaces côté hôte, l’écoute IGMP en mode proxy répond aux requêtes qu’elle reçoit d’un routeur IGMP sur une interface de routeur multicast. Sur les interfaces côté hôte, la surveillance IGMP en mode proxy se comporte comme un routeur IGMP et envoie des requêtes générales et spécifiques à un groupe sur ces interfaces.

Toutes les requêtes générées par la surveillance IGMP sont envoyées en utilisant 0.0.0.0 comme adresse source. De plus, tous les rapports générés par la surveillance IGMP sont envoyés avec 0.0.0.0 comme adresse source, sauf s’il existe une adresse source configurée à utiliser.

Le mode proxy fonctionne différemment sur les interfaces de routeur multicast que sur les interfaces côté hôte.

Sur les interfaces de routeur multicast, en réponse aux requêtes IGMP, la surveillance IGMP en mode proxy envoie des rapports contenant des informations agrégées sur les groupes appris sur toutes les interfaces côté hôte du pont.

En plus de répondre aux requêtes, l’écoute IGMP en mode proxy transfère toutes les requêtes, les rapports et les feuilles reçus sur une interface de routeur multicast vers d’autres interfaces de routeur multicast. La surveillance IGMP conserve les informations d’appartenance apprises sur cette interface, mais n’envoie pas de requête spécifique au groupe pour les messages de congé reçus sur cette interface. Il expire simplement les groupes appris sur cette interface s’il n’y a pas de rapports pour le même groupe pendant la durée du minuteur.

Aucun rapport n’est envoyé sur les interfaces côté hôte par surveillance IGMP en mode proxy. La surveillance IGMP traite les rapports reçus sur ces interfaces et envoie des requêtes spécifiques au groupe sur les interfaces côté hôte lorsqu’elle reçoit un message de congé sur l’interface. Les interfaces côté hôte ne génèrent pas de requêtes générales périodiques, mais transfèrent ou inondent les requêtes générales reçues des interfaces de routeur multicast.

Si un groupe est supprimé d’une interface côté hôte et qu’il s’agit de la dernière interface côté hôte de ce groupe, une autorisation est envoyée aux interfaces multicast-router. Si un rapport de groupe est reçu sur une interface côté hôte et qu’il s’agit de la première interface côté hôte pour ce groupe, un rapport est envoyé à toutes les interfaces de routeur multicast.

L’espionnage IGMP sur un VLAN n’est autorisé que pour le cas vlan-id all hérité. Dans d’autres cas, il existe une configuration de domaine de pont spécifique qui détermine la configuration spécifique au VLAN pour la surveillance IGMP.

Toutes les instructions d’écoute IGMP configurées avec l’instruction igmp-snooping , à l’exception de l’instruction traceoptions , peuvent être qualifiées avec la même instruction au niveau du VLAN. Pour configurer les paramètres de surveillance IGMP au niveau du VLAN, incluez l’instruction vlan suivante :

Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

• [edit bridge-domains bridge-domain-name protocols igmp-snooping]

• [edit routing-instances routing-instance-name bridge-domains bridge-domain-name protocols igmp-snooping]

Cet exemple montre comment configurer la surveillance IGMP. La surveillance IGMP peut réduire le trafic inutile des applications multicast IP.

• Aperçu
• Mode non-proxy
• Mode proxy

Limitez le flooding des flux multicast L2 aux interfaces multicast-router au niveau de chaque VLAN ou domaine de pont. En limitant le flooding de données multicast à l’interface multicast-router en fonction des messages de jointure IGMP ou MLD, le trafic multicast inconnu peut être limité, ce qui permet d’optimiser l’utilisation de la bande passante.

Prenons l’exemple d’un scénario de multidiffusion vidéo L2 dans lequel les routeurs R1 et R2 sont activés avec IGMP/MLD Snooping.

Figure 3 : Vidéo multicast L2 (IPTV)

SRC1 et SRC2 sont des serveurs IPTV avec une tête de réseau vidéo, générant plusieurs canaux IPTV - CH1, CH2 et CH3. Le requier L2 est activé sur les routeurs R1 et R2 pour s’assurer que les hôtes peuvent actualiser régulièrement les rapports, qui expireront et supprimeront les récepteurs du transfert multicast dans le cas contraire.

Dans la topologie ci-dessus, le routeur R2 a des récepteurs intéressés par la réception des canaux CH1 et CH2, mais recevra également des flux multicast de CH3. Cela s’explique par le fait qu’il s’agit d’une interface de routeur multicast.

De même, le routeur R1 a un récepteur qui ne s’intéresse qu’au canal CH3, mais qui reçoit des flux multicast non sollicités de CH1 et CH2 via l’interface multicast-router.

En configurant no-flood-to-multicast-router-interfaces, vous pouvez limiter efficacement l’inefficacité de la bande passante mentionnée ci-dessus en envoyant des flux multicast uniquement lorsqu’il y a des récepteurs intéressés derrière une interface de routeur multicast.

Restriction du flooding du trafic multicast inconnu dans un environnement EVPN

Prenons l’exemple d’une topologie EVPN typique, sous la forme d’une superposition de pont EVPNoVXLAN sur laquelle le transfert multicast sélectif (SMET) est activé. Des routes EVPN de type 6 sont annoncées, assurant le transfert du trafic multicast vers les récepteurs intéressés uniquement.

Les équipements de tête de réseau IBC sont connectés à un routeur multicast externe redondant et à la fabric EVPN située en dessous. Puisqu’il s’agit d’une superposition de pont, il n’existe qu’une connectivité L2 à partir des routeurs multicast externes redondants sur lesquels l’IRB est activé sans surveillance. Le trafic multicast entrant dans les routeurs multicast externes est ponté ou commuté L2 lorsque le trafic doit sortir de l’IRB.

Figure 4 : déploiement multicast EVPN avec surveillance

Avec la fabric overlay pontée SMET reliée aux ports redondants externes du routeur multicast, le trafic multicast entrant dans un port du routeur multicast est rattaché via les commutateurs d’accès à la fabric vers le deuxième port du routeur multicast (la ligne pointillée orange sur la Figure 4). Le périphérique EVPN PE attire tout le trafic multicast, connu et inconnu, sur le cœur EVPN. En règle générale, les PE EVPN envoient des routes EVPN de type 3 qui ont des indicateurs de communauté étendus multicast sans le proxy d’écoute IGMP/MLD défini dans son NLRI. En définissant l’instruction no-flood-to-multicast-router-interfaces de configuration, les routes EVPN de type 3 sont envoyées avec des indicateurs de communauté étendue multicast avec les indicateurs de proxy d’écoute IGMP/MLD définis. Par conséquent, l’interface du routeur multicast n’attirera pas de trafic multicast inconnu.

Note:

Cette fonctionnalité est généralement implémentée dans un scénario de superposition de pont EVPN. Si le routage L3 est opérationnel sur le routeur multicast externe, son activation no-flood-to-multicast-router-interfaces peut entraîner une panne de trafic.