IP : Protocole IP Multicast

Reconstruction des entrées multicast avec CGMP et modifications de topologie Spanning Tree

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (7 octobre 2015) | Commentaires


Contenu


Introduction

Ce document discute comment le Protocole CGMP (Cisco Group Management Protocol) travaille aux commutateurs Cisco Catalyst et aux Routeurs de Cisco IOSÝ en ce qui concerne la reconstruction des entrées multicasts pour le CGMP après qu'une modification de topologie de spanning tree se soit produite.

Conditions préalables

Conditions requises

Cisco recommande de posséder des connaissances sur ces sujets :

  • fonctionnement de base des Commutateurs, des Routeurs, et de la multifusion

  • fonctionnement de base du spanning-tree, du CGMP, et du Protocole IGMP (Internet Group Management Protocol)

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

  • Version 12.1(9)EA1c du Catalyst 3550

  • Version 12.0(5)WC3b du Catalyst 2900/3500XL

  • Version 12.1(11b)EW de Supervisor Engine III de Catalyst 4000

  • Version 7.2(2) de l'engine I/II de superviseur de Catalyst 4000

  • Version du logiciel Cisco IOS 12.1(11b)EX d'engine de superviseur de Catalyst 6500

  • Version 7.2(2) OS de Catalyst de Catalyst 6500 (CatOS)

  • Version 4.5(13a) de CatOS de Catalyst 5500

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Modifications de CGMP et de topologie

Cette section décrit le pas à pas ce qui se produit et le quel problèmes peuvent surgir quand une modification de topologie de spanning tree est détectée sur un VLAN où le CGMP est utilisé afin de retenir le trafic de multidiffusion de l'inondation sur tous les ports. Le comme indiqué dans cet exemple, le réseau discuté dans ce document se compose d'un routeur, d'un commutateur, et de quatre PC :

/image/gif/paws/24100/154-a.gif

  • port 1 — PC 1 de récepteur

  • port 2 — PC 2 de récepteur

  • port 3 — PC 3 de récepteur

  • port 4 — pas un PC 4 de récepteur

  • port 5 — l'autre commutateur (aucun récepteur ou Routeurs sur ce commutateur)

  • port 48 — Routeur Cisco IOS exécutant IGMP et CGMP

Afin de ce document, on le suppose que les PC de récepteur utilisent IGMP et le commutateur exécute le CGMP. Le routeur Cisco IOS exécute IGMP et CGMP, qui reçoit un flot de Multidiffusion d'un serveur vidéo sur une interface différente. Cette interface envoie au groupe de multicast IP 239.100.100.100.

État stable

Une fois que tous les périphériques sont amorcés et les PC de récepteur ont envoyé leur IGMP joignent des messages pour le groupe 239.100.100.100, ils tous sont ajoutés par CGMP à la couche correspondante 2 groupes représentés par l'adresse MAC 01-00-5e-64-64-64.

Cette liste affiche quels ports, mis en valeur en gras, sur le commutateur reçoivent le flot de Multidiffusion qui sont livré par le routeur Cisco IOS.

  • port 1 — PC 1 de récepteur

  • port 2 — PC 2 de récepteur

  • port 3 — PC 3 de récepteur

  • port 4 — pas un PC 4 de récepteur

  • port 5 — l'autre commutateur (aucun récepteur ou Routeurs sur ce commutateur)

  • port 48 — Routeur Cisco IOS qui exécute IGMP et CGMP

Remarque: Le routeur Cisco IOS est également ajouté au groupe de multidiffusion, mais puisque c'est la source, elle ne reçoit pas ses propres paquets.

À chaque intervalle de requête, le routeur Cisco IOS envoie une requête générale IGMP (qui est envoyée au groupe de multidiffusion 224.0.0.1, et donc inondé à tous les autres composants). Quand ceci se produit, tout le début de récepteurs pour établir un rapport IGMP pour le groupe de 239.100.100.100. Les récepteurs envoient cet état de nouveau au groupe de multicast IP 239.100.100.100, avec une adresse MAC de la couche 2 de 01-00-5E-64-64-64. Puisque ceci est envoyé à l'adresse de groupe, tous les récepteurs reçoivent les états qui sont envoyés par d'autres récepteurs aussi bien que l'état renvoyé par le premier récepteur. Ceci déclenche les autres PC de récepteur pour annuler leur état pour ce groupe. Ceci signifie que seulement un CGMP joignent le message est envoyé pour ce groupe avec l'adresse MAC source du PC qui était le premier à répondre. Ceci continue pendant une longue période de temps, et tous les PC de récepteur reçoivent l'émission visuelle.

Pendant et après la modification de topologie

En ce moment, l'autre commutateur déclenche un changement de topologie du réseau. Selon la spécification de CGMP lors de recevoir la modification de topologie, le commutateur efface toutes les entrées multicasts qu'il avait apprises par le CGMP. Le trafic de multidiffusion du routeur est inondé à tous les ports sur le commutateur.

Cette liste affiche quels ports, mis en valeur en gras, sur le commutateur reçoivent le flot de Multidiffusion qui sont livré par le routeur Cisco IOS :

  • port 1 — PC 1 de récepteur

  • port 2 — PC 2 de récepteur

  • port 3 — PC 3 de récepteur

  • port 4 — pas un PC 4 de récepteur

  • port 5 — l'autre commutateur (aucun récepteur ou Routeurs sur ce commutateur)

  • port 48 — Routeur Cisco IOS qui exécute IGMP et CGMP

Pendant que le trafic est inondé à tous les ports, les PC de récepteur ne notent aucune différence, et ils continuent à recevoir l'émission visuelle. Cependant, puisque le trafic est inondé à tous les ports, PC 4, qui n'est pas un récepteur, et l'autre commutateur reçoivent maintenant également le flot de Multidiffusion, bien qu'ils ne l'aient pas demandé. Ceci continue jusqu'à ce que le routeur Cisco IOS envoie sa requête générale périodique IGMP de nouveau. La valeur par défaut pour ceci est de 60 secondes sur des routeurs Cisco IOS (configurés avec un intervalle de requête IP IGMP).

Deux requêtes générales IGMP après la notification de modification de topologie

Quand le routeur Cisco IOS envoie sa première requête générale IGMP, tout le début PC de récepteur pour établir leur rapport IGMP pour le groupe de 239.100.100.100. L'un d'entre eux (dans ce document, c'est PC 3) est le premier pour renvoyer son rapport IGMP. Puisqu'il n'y a aucune entrée multicast établie sur le commutateur encore, il est reçu par tous les PC, et les autres PC de récepteur annulent leur rapport IGMP. Le routeur Cisco IOS reçoit l'état et envoie le CGMP ultérieur joignent le message avec l'adresse source de PC 3. de récepteur.

Le commutateur établit une entrée multicast de nouveau pour le groupe 01-00-5e-64-64-64 et ajoute le port 3 à lui, comme c'est l'adresse source dans le CGMP joignent le paquet. Puisque le port 5 est le port de routeur multidiffusion, ceci est également ajouté au groupe de multidiffusion. Par conséquent, seulement PC 3 de récepteur reçoit le flux vidéo, alors que le flux vidéo sur PC 1 et PC 2 se tient toujours.

Cette liste affiche quels ports, mis en valeur en gras, sur le commutateur reçoivent le flot de Multidiffusion qui est livré par le routeur Cisco IOS :

  • port 1 — PC 1 de récepteur

  • port 2 — PC 2 de récepteur

  • port 3 — PC 3 de récepteur

  • port 4 — pas un PC 4 de récepteur

  • port 5 — l'autre commutateur (aucun récepteur ou Routeurs sur ce commutateur)

  • port 48 — Routeur Cisco IOS exécutant IGMP et CGMP

À la fin d'un intervalle de question IGMP, le routeur Cisco IOS envoie une autre requête générale IGMP. Lors de recevoir la requête, tous les PC de récepteur établissent un état pour le groupe de 239.100.100.100. Cette fois, cependant, les états des autres PC sont seulement reçus par PC 3 de récepteur et le routeur Cisco IOS. (Le port de routeur est automatiquement ajouté à chaque groupe de multidiffusion.)

Puisque PC 1 de récepteurs et PC 2 ne voient pas un état d'aucun autre récepteur, ils chacun des deux envoient leurs états. Le routeur Cisco IOS envoie ultérieurement un CGMP joignent le message avec l'adresse MAC source des PC respectifs, et donc, ils sont ajoutés et commencent recevoir le flot de Multidiffusion de nouveau par le routeur Cisco IOS.

Cette liste affiche quels ports, mis en valeur en gras, sur le commutateur reçoivent le flot de Multidiffusion qui est livré par le routeur Cisco IOS :

  • port 1 — PC 1 de récepteur

  • port 2 — PC 2 de récepteur

  • port 3 — PC 3 de récepteur

  • port 4 — pas un PC 4 de récepteur

  • port 5 — l'autre commutateur (aucun récepteur ou Routeurs sur ce commutateur)

  • port 48 — Routeur Cisco IOS exécutant IGMP et CGMP

La configuration est de nouveau à l'état stable d'origine et tout fonctionne correctement de nouveau. C'est une panne de ce qui s'est produit :

  1. Une modification de topologie se produit.

    Conseil : Quand le portfast n'est pas activé dans un port de hôte, chaque fois un hôte est redémarré, ou connecté/déconnecté à/de le port, un changement de l'état de liens déclenche une notification de modification de topologie dans le VLAN. Si l'élimination des imperfections du CGMP est activée au moment de la modification de topologie, ce message de débogage est affiché :

    CGMP SHIM: got short age timer
  2. Inondation des débuts à tous les ports.

  3. La première requête générale IGMP est envoyée.

  4. Inondation des arrêts.

  5. Non tous les récepteurs reçoivent le flot de Multidiffusion.

  6. La deuxième requête générale IGMP est envoyée.

  7. Tous les récepteurs sont ajoutés et reçoivent le flot de Multidiffusion de nouveau.

Améliorations de CGMP

Avoir depuis une perte d'one-minute (l'intervalle de question de par défaut IGMP) d'un flot de Multidiffusion pour un PC n'est pas toujours acceptable, il y a eu quelques améliorations faites pour les Routeurs et les Commutateurs qui exécutent le CGMP.

Transmission entre le commutateur et le routeur

Puisque les Routeurs sont les périphériques de la couche 3 et donc ne savent pas généralement les modifications de spanning-tree et de topologie qui se produisent, il y ont un besoin des Commutateurs dans le réseau d'alerter le routeur de cette modification de topologie. Un message global de congé IGMP est défini afin de manipuler ceci.

Ce message global de congé IGMP est un congé IGMP qu'un commutateur peut transmettre, demandant de laisser le groupe 0.0.0.0.

Afin de s'assurer que le routeur n'est pas surchargé avec les messages globaux de congé IGMP, seulement le commutateur de racine dans un domaine de spanning-tree est responsable d'envoyer à cet IGMP le message global de congé quand la modification de topologie est terminée.

Comportement du routeur

Quand le routeur reçoit ce message global de congé IGMP sur une interface qui exécute le logiciel de Cisco IOS, il identifie qu'une modification de topologie de spanning tree s'est produite sur cette interface et prend ces mesures d'essayer et limiter la perte du trafic de multidiffusion pour les récepteurs multicasts :

  1. Envoie le lot de CGMP joignent des messages après réception du message global de congé IGMP. Le routeur envoie un CGMP joignent le message avec sa propre adresse MAC comme l'adresse source d'utilisateur pour chaque groupe de multidiffusion qu'il a dans son cache IGMP pour cette interface. Par l'envoi que ceux-ci le CGMP auto-joignent des messages, les Commutateurs de CGMP crée automatiquement une entrée pour chaque groupe avec seulement le port de routeur dans lui.

    Cette liste affiche le réseau utilisé dans ce document, après que le lot de CGMP se joignent. Seulement le routeur Cisco IOS a été ajouté au groupe de multidiffusion, suivant les indications de gras.

    Remarque: Tandis que dans les exemples précédents dans ce document, les ports qui reçoivent le trafic du routeur multidiffusion étaient affichés en gras, cet exemple affiche tous les ports qui sont ajoutés sur le commutateur au groupe de multidiffusion.

    • port 1 — PC 1 de récepteur

    • port 2 — PC 2 de récepteur

    • port 3 — PC 3 de récepteur

    • port 4 — pas un PC 4 de récepteur

    • port 5 — l'autre commutateur (aucun récepteur ou Routeurs sur ce commutateur)

    • port 48 — Routeur Cisco IOS exécutant IGMP et CGMP

  2. Envoie une requête générale IGMP. Tous les récepteurs reçoivent cette requête générale IGMP, et établissent un état pour chaque groupe qu'ils ont joint. Puisque le commutateur de CGMP a déjà établi une entrée multicast pour chacun des groupes avec seulement le routeur comme récepteur, tous les états sont envoyés seulement au routeur. Le routeur envoie le CGMP ultérieur joignent des messages pour ajouter tous les récepteurs aux groupes correspondants.

    Après tout les récepteurs ont renvoyé leur rapport IGMP et le routeur a envoyé le CGMP correspondant joignent des messages, tous les récepteurs devrait avoir été ajouté de nouveau au groupe de multidiffusion.

  3. Après 10 secondes (maximum-réponse-temps par défaut IGMP), une autre requête générale IGMP est envoyée pour s'assurer que tous les récepteurs sont ajoutés. Cette étape est répétée plusieurs fois de s'assurer que tous les récepteurs rejoignent le groupe de multidiffusion.

    Tous les ports qui devraient avoir été ajoutés au groupe de multidiffusion ont été, suivant les indications de gras dans cet exemple :

    • port 1 — PC 1 de récepteur

    • port 2 — PC 2 de récepteur

    • port 3 — PC 3 de récepteur

    • port 4 — pas un PC 4 de récepteur

    • port 5 — l'autre commutateur (aucun récepteur ou Routeurs sur ce commutateur)

    • port 48 — Routeur Cisco IOS exécutant IGMP et CGMP

Comportement de commutateur de Catalyst

Dans la marge des Commutateurs de Catalyst, il y a quelques différences dans leur comportement. Chaque commutateur qui est Cgmp-capable fait comme décrit dans la section de modifications de CGMP et de topologie de ce document. Les améliorations pour le CGMP, cependant, ne sont pas mises en application sur toutes les Plateformes. Cette table fournit une liste de Commutateurs de Catalyst et comment ils réagissent au CGMP :

  Commutateur de CGMP Routeur de CGMP Envoie le congé global quand racine du Protocole Spanning Tree (STP)
Logiciel courant de Cisco IOS de Catalyst 6500 N Y Y
Catalyst 6500 exécutant CatOS N N N
Catalyst 5500, Catalyst 2926/2926G Y N Y
Engine I/II de superviseur de Catalyst 4000, Catalyst 2948G/2980G, Catalyst 4912G Y N Y
Engine III/IV de superviseur du Catalyst 4000/4500 N Y Y
Catalyst 2900XL/3500XL Y N Y
Catalyst 2940 N N N
Catalyst 2950 N N N
Catalyst 2970 N N N
Catalyst 3550 N Y Y
Catalyst 3750 N Y Y

Remarque: Sur le Catalyst 4000/4500 avec une engine III/IV de superviseur, le comportement en ce qui concerne la topologie change et le CGMP est configurable. Émettez cette commande afin de configurer le Catalyst 4000 pour envoyer ou pour ne pas envoyer à un IGMP le message global de congé quand ce n'est pas la racine de spanning-tree :

  • la requête d'ip igmp snooping tcn sollicitent

Remarque: Émettez cette « non » forme de la commande afin de la désactiver :

  • aucune requête d'ip igmp snooping tcn ne sollicitent

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 24100