Aller au contenu
Avanet

Configurer l’IGMP Snooping et le MLD Snooping sur Sophos Switch

Sophos Switch

L’IGMP Snooping et le MLD Snooping empêchent un Sophos Switch de transmettre inutilement les données multicast à tous les ports d’un VLAN. IGMP Snooping observe les appartenances aux groupes IPv4, tandis que MLD Snooping remplit la même fonction pour IPv6. Le switch établit ainsi une liste des ports qui doivent recevoir les données multicast et ne transmet le flux qu’à ces ports.

Le snooping est une fonction de couche 2. Il ne génère pas de flux multicast et ne remplace pas le routage multicast entre les VLAN. Si un flux doit franchir la limite d’un sous-réseau, une conception de routage adaptée est également nécessaire, par exemple une route multicast statique sur Sophos Firewall ou PIM-SM.

⚠️ Important : Une version IGMP/MLD inadaptée, un Querier absent ou mal planifié, ou l’activation prématurée de Fast leave peuvent interrompre la réception. Le Status général peut s’appliquer à l’ensemble du switch ou du site ; comme Sophos ne documente aucune règle de priorité par rapport au Status du VLAN, la modification d’une seule ligne de VLAN ne constitue pas automatiquement un pilote isolé. Avant l’activation, il faut donc vérifier la portée potentielle ainsi que la présence de queries régulières.

Procédure rapide :

  1. Pour chaque VLAN, documenter la famille IP, l’émetteur, le groupe, les récepteurs, le routeur multicast et le Querier existant.
  2. Dans Sophos Fusion, ouvrir le switch et traiter séparément IGMP et MLD sous L3 protocols ; selon Sophos, il est également possible de sélectionner un site pour IGMP.
  3. Définir le statut général et Report suppression ; vérifier la Configuration source affichée.
  4. Pour chaque VLAN, définir le statut, la version, le Querier, les timers, Fast leave et les Static ports.
  5. Observer le Querier effectif et les requêtes générales régulières (General Queries) ; vérifier ensuite l’adhésion au groupe, la Group list et les données utiles pendant l’intervalle effectif de vieillissement des appartenances.
  6. En cas d’incidences sur des VLAN non concernés, rétablir d’abord le Status général ; sinon, rétablir uniquement la dernière modification selon les valeurs initiales documentées.

IGMP pour IPv4, MLD pour IPv6

TraficProtocole d’appartenanceFonction Sophos
Multicast IPv4IGMPIGMP snooping
Multicast IPv6MLDMLD snooping

Ces fonctions sont configurées séparément. Une réception IPv4 fonctionnelle ne prouve donc rien concernant IPv6, et inversement. Dans un VLAN dual stack, IGMP et MLD sont validés comme deux cas de test distincts.

Le Snooping Querier envoie des requêtes auxquelles les terminaux intéressés répondent par des Membership Reports. Ces rapports fournissent au switch les informations nécessaires à l’établissement de sa liste de transmission. Avant d’activer le Querier, il faut donc savoir si un autre composant remplit déjà cette fonction dans le VLAN. L’interface Sophos permet d’activer ou de désactiver le Querier pour chaque VLAN, mais elle ne remplace pas l’inventaire de la conception multicast existante.

Selon Sophos, les Static ports sont les ports connectés à des routeurs compatibles multicast. Il ne faut pas y inscrire systématiquement les ports des récepteurs, tous les uplinks ou les ports de l’émetteur. Le chemin réel vers le routeur doit être déterminé pour chaque VLAN à partir de la topologie.

Prérequis et plan de modification

La configuration décrite dans cet article s’effectue via Sophos Fusion. Le switch doit pour cela être enregistré et synchronisé. Une souscription Sophos Switch Support and Services valide est requise pour chaque switch géré via Sophos Fusion ; sans souscription valide, le switch continue de fonctionner et reste administrable localement, mais les modifications via Sophos Fusion ne sont plus possibles. Le compte Fusion utilisé doit disposer de l’autorisation nécessaire pour modifier la configuration du switch concerné ou du site concerné. Les comptes locaux du switch et les autorisations Fusion sont distincts.

Avant la modification, il faut également déterminer si Sophos Fusion ou l’interface locale détient l’autorité de configuration. Not set délègue la valeur concernée à la configuration locale et ne convient donc pas comme raccourci lorsque l’état cible est inconnu. Si la souscription ou la connexion Fusion n’est pas disponible pendant un incident, un accès de gestion local testé doit être disponible pour le diagnostic et le retour arrière.

Avant la modification, les informations suivantes sont consignées pour chaque VLAN concerné :

  • l’ID du VLAN et le switch ou le site concerné ;
  • IPv4, IPv6 ou dual stack ;
  • l’émetteur multicast, l’adresse du groupe et le port applicatif du flux de test ;
  • au moins un récepteur contrôlable et son port physique sur le switch ;
  • le port vers le routeur compatible multicast ;
  • le Querier IGMP ou MLD existant et ses paramètres ;
  • le Querier effectif observé pour chaque famille IP, avec son adresse source, sa version de protocole et les General Queries récurrentes ;
  • la version IGMP ou MLD requise par les appareils concernés ;
  • le statut général actuel et le statut actuel du VLAN ;
  • Report suppression, les timers du Querier, Fast leave, les Static ports et la Configuration source des paramètres généraux ;
  • l’entrée attendue dans la Group list, la fenêtre de maintenance et les valeurs de retour arrière.

Si le Status général doit passer de Disabled ou Not set à Enabled, le contrôle préalable couvre chaque VLAN susceptible de devenir effectif sur le switch sélectionné. Pour chacun de ces VLAN, il faut déterminer le statut effectif, le Querier, la version et le comportement des ports reliés aux routeurs compatibles multicast. En cas de modification au niveau du site, ce contrôle s’applique à chaque switch inclus. Si les VLAN rendus effectifs par le statut général n’ont pas été identifiés avec certitude, la modification doit être interrompue.

Un pilote véritablement limité à un VLAN n’est autorisé que sur un switch de test/laboratoire dédié, lorsqu’une règle de priorité est confirmée par le fabricant pour le firmware cible, ou après une mesure effectuée précisément sur ce firmware démontrant que tous les VLAN hors pilote restent inchangés. Dans le cas contraire, l’activation est planifiée, surveillée et rendue réversible comme une modification à l’échelle du switch ou du site, même si une seule ligne de VLAN est modifiée.

Le VLAN et l’appartenance de ses ports doivent déjà fonctionner correctement. Le snooping ne corrige pas un mauvais tagging. La configuration de couche 2 est traitée dans le guide Configurer les VLAN Sophos Switch en toute sécurité.

Pour la validation, l’application réceptrice doit pouvoir rejoindre réellement un groupe connu. Un ping vers une adresse unicast ne constitue pas un test multicast. De même, une configuration enregistrée ne suffit pas : les éléments déterminants sont le groupe appris et le flux réel sur le récepteur prévu.

Exemple de test compact

L’exemple suivant illustre uniquement l’affectation ; les valeurs doivent être remplacées par celles de votre propre topologie. Dans le VLAN 30, 192.0.2.10 émet vers le groupe multicast utilisé à des fins administratives 239.1.1.10 sur le port UDP 5000. Un seul appareil de test est connecté au port de switch 7. Le routeur multicast et Querier existant 192.0.2.1 est accessible via le port 24.

Pour ce test, IGMP est configuré, et non MLD. En tant que connexion au routeur, le port 24 doit être ajouté sous Static ports ; le port de l’émetteur et le port 7 ne doivent pas l’être. Fast leave ne peut être envisagé pour le port 7 que si cet unique terminal y est effectivement connecté directement. La version et les timers ne sont pas repris de l’exemple, mais déterminés à partir des appareils concernés et du Querier observé.

Lors de la validation, 239.1.1.10 doit apparaître dans la Group list après l’adhésion, le flux doit rester stable sur le port 7 et ne doit pas parvenir inutilement à un port contrôlé sans récepteur. Le contrôle périodique du Querier et l’intervalle de vieillissement des appartenances sont définis dans la section Validation.

Not set n’est pas une valeur opérationnelle propre

Pour Status, Version, Querier status et Fast leave, Not set signifie que le paramètre configuré localement sur le switch est utilisé. Pour les champs de statut, la valeur locale héritée peut être activée ou désactivée ; pour Version, la version de protocole sélectionnée localement s’applique. Configuration source indique l’origine des paramètres généraux de snooping. Pour définir un état cible via Sophos Fusion, il faut donc sélectionner des valeurs explicites et contrôler leur origine après l’enregistrement.

Déploiement contrôlé

Procédez comme suit pour garder le contrôle de l’activation :

  1. Sauvegarder l’état initial des deux niveaux de paramètres ainsi que la Configuration source des paramètres généraux.
  2. Si le statut général doit être activé, inventorier chaque VLAN susceptible de devenir effectif sur chaque switch inclus. Ne pas poursuivre tant que la portée n’est pas clarifiée.
  3. Définir un émetteur, un groupe connu et un récepteur contrôlable pour le VLAN de test.
  4. Pour chaque famille IP, utiliser une capture de paquets ou une télémétrie équivalente du switch/routeur afin d’observer le Querier effectif existant, son adresse source et sa version de protocole, ainsi que les General Queries récurrentes. La seule présence d’un Querier status configuré ne suffit pas. En l’absence de cette preuve, ne pas activer le snooping ni étendre le déploiement. La seule exception est la première utilisation planifiée du Sophos Switch comme Querier ; dans ce cas, le contrôle décrit ci-dessous immédiatement après Save constitue un critère d’interruption.
  5. Configurer uniquement la famille IP nécessaire ; en dual stack, traiter successivement IGMP et MLD.
  6. N’activer le statut général qu’après validation de la portée et configurer le VLAN de test avec la version appropriée.
  7. N’activer le Querier que conformément au plan des rôles. Plusieurs appareils capables d’agir comme Querier peuvent être configurés ; le point déterminant est qu’un Querier élu ou effectif soit observable. Si le Sophos Switch doit assurer ce rôle, observer après Save l’adresse source et la version réellement utilisées pour ses queries dans le VLAN. Conserver initialement les valeurs documentées des timers.
  8. Laisser Fast leave désactivé lors du premier test, sauf s’il est certain qu’un seul terminal est connecté au port.
  9. Sélectionner exclusivement la connexion au routeur sous Static ports.
  10. Enregistrer, contrôler de nouveau les valeurs affichées et vérifier la Configuration source des paramètres généraux.
  11. Faire rejoindre le groupe au récepteur et effectuer l’ensemble du contrôle périodique décrit dans la section Validation.
  12. Faire quitter le groupe au récepteur de manière contrôlée et observer le comportement.
  13. N’intégrer d’autres VLAN, un par un, qu’après une validation réussie incluant l’intervalle de vieillissement des appartenances.

Configurer l’IGMP Snooping pour IPv4

Dans Sophos Fusion, ouvrir le chemin suivant :

My Products > Switches > Switches > [switch ou site] > L3 protocols > IGMP snooping

Les champs suivants sont configurés dans l’ordre du déploiement contrôlé.

1. Définir les paramètres généraux

Sous IGMP snooping > Settings, les options suivantes sont disponibles :

  • Status
    • Enabled: activer l’IGMP Snooping.
    • Disabled: désactiver l’IGMP Snooping.
    • Not set: utiliser le statut configuré localement.
  • Report suppression: limiter le nombre de Membership Reports envoyés par le membre aux routeurs compatibles multicast. Les valeurs autorisées sont comprises entre 1 et 25.
  • Configuration source: origine affichée des paramètres généraux de l’IGMP Snooping.

Pour activer l’IGMP Snooping, sélectionner Status: Enabled. Pour Report suppression, conserver la valeur initiale documentée, sauf si une modification justifiée et testable est planifiée.

⚠️ Avant le Save général : Cette modification peut concerner l’ensemble du switch sélectionné. Au niveau du site, elle peut concerner chaque switch inclus. Ne sélectionner Save que lorsque tous les VLAN susceptibles de devenir effectifs à cause du statut général ont été recensés pour chaque switch concerné, que leur statut effectif, leur Querier, leur version et le comportement des ports de routeur ont été vérifiés, et que la valeur générale de retour arrière a été consignée. En l’absence de cette preuve, interrompre la modification.

Sélectionner ensuite Save, rouvrir les valeurs enregistrées et contrôler la Configuration source.

2. Modifier les paramètres du VLAN

Dans le tableau des VLAN, ouvrir le VLAN prévu via edit et configurer les champs suivants :

  • Status: Enabled, Disabled ou Not set ;
  • Version: v1, v2, v3 ou Not set ;
  • Querier status: Enabled, Disabled ou Not set ;
  • Fast leave: Enabled, Disabled ou Not set ;
  • Querier interval (seconds): 60 à 600 ;
  • Response interval (seconds): 0 à 25 ;
  • Startup query counter: 2 à 5 ;
  • Startup query interval (seconds): 15 à 150 ;
  • Static ports: ports vers les routeurs compatibles multicast.

La Version doit être compatible avec les récepteurs et le routeur multicast réellement utilisés. Ne pas changer de version uniquement parce que son numéro est supérieur. Not set reprend la version locale et ne doit donc être sélectionné volontairement que si cette valeur locale est connue.

Querier status: Enabled n’est sélectionné que si le Sophos Switch doit assurer le rôle documenté de Querier dans ce VLAN. Les timers ne doivent pas être optimisés au hasard : Querier interval définit l’intervalle entre les requêtes générales, tandis que Response interval définit le délai de réponse des hôtes. Startup query counter et Startup query interval contrôlent le nombre et la cadence des requêtes IGMP après le démarrage.

N’activer Fast leave que si un seul terminal est effectivement connecté au port concerné. Le switch traite alors ce port comme une connexion vers ce terminal unique. Plusieurs récepteurs peuvent se trouver derrière un autre switch ou une autre connexion de couche 2 partagée ; dans ce cas, Fast leave reste désactivé tant que cette architecture n’a pas été expressément testée.

Sous Static ports, sélectionner exclusivement les ports documentés vers le routeur compatible multicast. Pour terminer, sélectionner Save.

Configurer le MLD Snooping pour IPv6

Pour IPv6, ouvrir le chemin séparé :

My Products > Switches > Switches > [Switch] > L3 protocols > MLD snooping

Les champs suivants sont configurés dans l’ordre du déploiement contrôlé.

1. Définir les paramètres généraux

Sous MLD snooping > Settings, les champs suivants sont disponibles :

  • Status: Enabled, Disabled ou Not set ;
  • Report suppression: valeur comprise entre 1 et 25 ;
  • Configuration source: origine affichée des paramètres généraux du MLD Snooping.

Pour activer le MLD Snooping, définir explicitement le statut sur Enabled. Pour Report suppression, conserver la valeur initiale documentée, sauf si une modification justifiée et testable est planifiée.

⚠️ Avant le Save général : Cette modification peut concerner l’ensemble du switch sélectionné. Si le périmètre d’administration choisi comprend plusieurs switches, le même contrôle est requis sur chaque switch inclus. Ne sélectionner Save que lorsque tous les VLAN susceptibles de devenir effectifs à cause du statut général ont été recensés, que leur statut effectif, leur Querier, leur version et le comportement des ports de routeur ont été vérifiés, et que la valeur générale de retour arrière a été consignée. En l’absence de cette preuve, interrompre la modification.

Enregistrer avec Save, puis contrôler la Configuration source affichée.

2. Modifier les paramètres du VLAN

Ouvrir le VLAN prévu via edit. Les options configurables sont les suivantes :

  • Status: Enabled, Disabled ou Not set ;
  • Querier status: Enabled, Disabled ou Not set ;
  • Querier interval (seconds): 60 à 600 ;
  • Version: v1, v2 ou Not set ;
  • Fast leave: Enabled, Disabled ou Not set ;
  • Static ports: ports vers les routeurs compatibles multicast.

Sur le plan fonctionnel, Sophos associe MLDv1 à IGMPv2 et MLDv2 à IGMPv3 pour IPv4. Cette correspondance facilite la conception, mais ne rend pas les protocoles interchangeables : MLD doit toujours être utilisé et testé séparément dans le VLAN IPv6.

Pour le Querier, la version, Fast leave et les Static ports, les mêmes critères de décision que pour IGMP s’appliquent : clarifier d’abord le rôle du Querier existant, choisir la version en fonction des appareils concernés, utiliser Fast leave uniquement sur un port connecté à un terminal unique et ne sélectionner statiquement que les véritables ports de routeur. Sélectionner ensuite Save.

Validation

Vérifier le Querier effectif et l’état périodique

La validation s’effectue séparément pour chaque VLAN testé et chaque famille IP. Un Querier status configuré ou une seule adhésion ne prouve pas qu’un Querier fonctionne durablement. Avant la mise en production, une capture de paquets effectuée à un point de mesure approprié ou des données de télémétrie équivalentes du switch ou du routeur doivent montrer les éléments suivants :

  1. les General Queries du Querier élu ou effectif pour ce VLAN, avec son adresse source et la version IGMP ou MLD réellement utilisée ;
  2. au moins une autre General Query selon la cadence régulière observée, et pas uniquement les Startup Queries émises immédiatement après l’enregistrement ;
  3. un Membership Report du récepteur de test en réponse à une General Query ultérieure ;
  4. le maintien de l’entrée dans la Group list et un flux de test sans interruption pendant l’intervalle de vieillissement des appartenances applicable.

La durée d’observation n’est pas une valeur fixe universelle. Pour IGMPv3 et MLDv2, elle est déterminée à partir des valeurs Robustness, Query Interval et Query Response effectivement annoncées par le Querier effectif. L’intervalle de vieillissement des appartenances correspond à Robustness Value × Query Interval + Query Response Interval. Pour les versions antérieures, les valeurs réellement appliquées par le Querier et le firmware cible sont utilisées. Si les paramètres nécessaires ou l’intervalle effectif ne peuvent pas être déterminés de manière fiable, le test ne peut pas être considéré comme réussi.

Si un Querier externe est prévu avant la modification, ses queries périodiques doivent être confirmées avant l’activation du snooping. Si le Sophos Switch doit au contraire assurer pour la première fois le rôle de Querier, cela doit être consigné dans le plan de modification et de retour arrière ; immédiatement après Save, l’adresse source, la version et les General Queries récurrentes sont contrôlées. Si elles sont absentes ou incompatibles, le déploiement n’est pas poursuivi et la configuration est rétablie conformément au plan de retour arrière. Plusieurs appareils capables d’agir comme Querier peuvent être configurés ; il n’est pas exigé qu’un seul appareil soit configuré, mais qu’un Querier effectif soit observable pour chaque VLAN et chaque famille IP.

Vérifier l’appartenance au groupe et les données utiles

La Group list sous IGMP ou MLD affiche les groupes multicast détectés. Une validation réussie ne se limite pas à une entrée visible :

  1. Avant l’adhésion, documenter l’état initial de la Group list.
  2. Démarrer l’application réceptrice et rejoindre le groupe IPv4 ou IPv6 prévu.
  3. Recharger la Group list. Le groupe attendu doit apparaître après l’adhésion.
  4. Démarrer le flux de test et contrôler sur le récepteur prévu le contenu, la stabilité et le fonctionnement de l’application.
  5. Vérifier qu’un port sans récepteur intéressé ne reçoit pas inutilement le flux. Effectuer ce test négatif uniquement à l’aide d’une mesure adaptée ou d’un appareil de test contrôlé.
  6. Pendant l’intervalle de vieillissement des appartenances déterminé ci-dessus, observer une General Query ultérieure et la réponse du récepteur ; contrôler ensuite de nouveau la Group list et le flux.
  7. Faire quitter le groupe au récepteur. Si Fast leave est activé, vérifier tout particulièrement que seul le port prévu, connecté à un terminal unique, est concerné.
  8. Répéter le test après un redémarrage planifié ou une nouvelle synchronisation si ce comportement fait précisément partie de la modification.

La Group list confirme l’appartenance détectée, mais ne prouve pas à elle seule le bon fonctionnement du chemin de données de bout en bout. Inversement, un flux brièvement visible sans groupe correctement appris peut indiquer une transmission encore instable ou trop large. Ces deux observations doivent être évaluées ensemble.

Contrôle de la configuration

Pour la mise en production, deux éléments sont documentés conjointement : premièrement, l’état effectif de la configuration avec les statuts général et du VLAN, la version, le Querier et les timers, Fast leave, les Static ports, Report suppression et la Configuration source ; deuxièmement, la preuve du fonctionnement avec la source et la version des queries, la cadence régulière des queries, un Membership Report ultérieur, la Group list, ainsi qu’une adhésion, un flux et une sortie stables pendant l’intervalle de vieillissement des appartenances déterminé.

Vérifier de nouveau après toute modification du firmware ou de la topologie

La Group list indique un état opérationnel dynamique et non une liste d’autorisation permanente. Après toute modification d’un récepteur, du routeur multicast, du chemin du VLAN ou de la version du protocole, ainsi qu’après une mise à jour du firmware, il faut donc vérifier de nouveau l’adhésion, la Group list, les données utiles et la sortie. Il en va de même lorsque l’autorité de configuration passe de l’administration locale à Sophos Fusion ou inversement ; pour Not set, la valeur locale actuellement effective doit alors être déterminée de nouveau.

Le snooping reste limité à la transmission sélective de couche 2 dans le VLAN. Il ne remplace ni le routage multicast, ni la génération ou la disponibilité du flux, ni la planification des capacités sur le chemin de l’émetteur, du routeur, des uplinks et des récepteurs.

Identifier les erreurs selon leurs symptômes

La Group list reste vide

  1. Vérifier que l’application réceptrice a effectivement rejoint le bon groupe dans la bonne famille IP.
  2. Contrôler le statut général et le statut du VLAN. Not set peut reprendre une valeur locale inattendue.
  3. Vérifier la Configuration source des paramètres généraux et contrôler que les valeurs enregistrées s’affichent après une nouvelle ouverture.
  4. Comparer la version IGMP ou MLD avec celles du récepteur et du routeur.
  5. Déterminer si un Querier fonctionnel est présent dans le VLAN. Si le switch doit agir comme Querier, vérifier son Querier status et son intervalle.
  6. Contrôler l’appartenance au VLAN, le tagging et le port physique du récepteur.

L’adhésion fonctionne initialement, puis le groupe disparaît ou le flux s’arrête

  1. Utiliser une capture de paquets ou une télémétrie équivalente pour vérifier si les General Queries du Querier effectif attendu continuent d’arriver.
  2. Comparer l’adresse source et la version IGMP/MLD des queries observées avec le plan documenté des rôles et des versions. Un Querier status activé ne constitue pas à lui seul une preuve de fonctionnement.
  3. Vérifier si le récepteur répond à une General Query ultérieure par un Membership Report.
  4. Comparer l’intervalle de vieillissement des appartenances déterminé à partir des paramètres réellement effectifs du Querier avec l’heure de disparition du groupe ou d’arrêt du flux.
  5. En cas de queries absentes ou incompatibles, interrompre le déploiement et annuler la dernière modification ; ne pas modifier les timers à titre d’essai.

Le groupe est visible, mais le récepteur ne reçoit aucun flux

  • Vérifier que l’émetteur multicast, le groupe et le port applicatif correspondent aux valeurs de test.
  • Vérifier que le flux arrive au switch et que le récepteur écoute le même groupe et le bon port applicatif.
  • Si le trafic traverse les limites d’un VLAN, vérifier séparément le routage multicast. Le snooping ne crée aucune route.
  • Comparer les Static ports avec le port réel vers le routeur compatible multicast.
  • Ne pas confondre IGMP et MLD ; un groupe IPv6 n’apparaît pas grâce à une configuration IGMP.
  • Contrôler le pare-feu de l’hôte et l’application réceptrice avant de modifier les timers du snooping.

Le flux continue d’être distribué à trop de ports

  • Vérifier que le snooping est effectivement Enabled au niveau général et pour le VLAN concerné.
  • Contrôler la Configuration source des paramètres généraux ; un Not set visible ne prouve pas qu’une fonction locale est active.
  • Vérifier que le groupe attendu apparaît dans la Group list et que le récepteur prévu reçoit le flux de test.
  • Vérifier si des uplinks ou des ports de récepteur ont été sélectionnés systématiquement sous Static ports et ne conserver que les connexions de routeur documentées.
  • Ne pas modifier Report suppression ni les timers comme première tentative de correction. Vérifier d’abord l’apprentissage du groupe, le VLAN et le Querier.

La réception s’interrompt lorsqu’un autre appareil quitte le groupe

  • Désactiver Fast leave sur le port partagé ou le rétablir à sa valeur précédente documentée.
  • Vérifier si un autre switch ou plusieurs récepteurs sont connectés derrière ce port.
  • Reconstituer le groupe avec les deux récepteurs, puis ne faire quitter le groupe qu’à un seul récepteur et contrôler le flux restant.
  • Contrôler la version et l’état du Querier si le problème persiste même lorsque Fast leave est désactivé.

IPv4 fonctionne, mais pas IPv6

  • Pour IPv6, vérifier explicitement MLD snooping et son tableau de VLAN ; IGMP ne concerne qu’IPv4.
  • Contrôler séparément la version MLD et le Querier.
  • Rechercher le groupe IPv6 dans la Group list MLD, et non dans la liste IGMP.
  • Tester le routage multicast IPv6 et l’application réceptrice séparément du chemin IPv4 fonctionnel.

Après Save, le switch se comporte autrement que prévu

  • Vérifier que le bon switch ou le bon site a été modifié.
  • Lire la Configuration source des paramètres généraux et comparer les valeurs générales et propres au VLAN avec l’état initial.
  • Avec Not set, déterminer la valeur locale au lieu d’enregistrer plusieurs fois la même valeur Fusion.
  • Annuler uniquement la dernière modification délimitée, puis tester de nouveau l’adhésion, la Group list et le flux.

Retour arrière

Le retour arrière rétablit les valeurs initiales documentées. Not set n’est utilisé que lorsque la configuration locale doit de nouveau s’appliquer volontairement ; il ne remplace pas systématiquement Disabled.

Si la modification du Status général affecte un VLAN non concerné, le chemin de retour arrière à l’échelle du switch ou du site est prioritaire : rétablir immédiatement le Status général à sa valeur initiale documentée et sélectionner Save. En cas de modification au niveau du site, cette opération s’applique au périmètre d’administration concerné. Valider ensuite les VLAN de production concernés en observant les queries, la Group list et le flux réel. Les options propres aux différents VLAN ne sont examinées ou rétablies qu’une fois cet état stabilisé.

En l’absence d’incidences sur des VLAN non concernés, le retour arrière normal s’effectue progressivement :

  1. Arrêter le flux de test et documenter la dernière Group list, les VLAN concernés et le symptôme observé.
  2. Dans le VLAN IGMP ou MLD concerné, rétablir d’abord la dernière option modifiée, par exemple Fast leave, Querier status, Version, les timers ou les Static ports.
  3. Rétablir le Status du VLAN à sa valeur initiale documentée : Enabled, Disabled ou Not set.
  4. Si le statut général faisait partie de la modification, le rétablir également à sa valeur précédente. Ne modifier aucune autre famille IP ni aucun VLAN non concerné.
  5. Rétablir Report suppression à sa valeur précédente et sélectionner Save.
  6. Rouvrir les valeurs enregistrées et vérifier la Configuration source des paramètres généraux.
  7. Faire rejoindre de nouveau le groupe au récepteur de production précédent et contrôler les General Queries, la réponse du récepteur, la liste des groupes ainsi que le flux pendant au moins l’intervalle effectif de vieillissement des appartenances déterminé précédemment.

Si le snooping est entièrement désactivé, la transmission sélective configurée ici à partir de la liste des ports appris disparaît. Le trafic multicast peut alors être de nouveau distribué à davantage de ports ; cette mesure ne constitue donc qu’un retour arrière temporaire et contrôlé, et non un substitut à l’analyse de la cause. La modification n’est considérée comme terminée que lorsque la réception précédente fonctionne durablement, que les queries et rapports périodiques ont été observés dans l’état attendu et que l’origine effective de la configuration est documentée.