Exemple : configuration de la surveillance multicast

Cet exemple utilise les composants matériels suivants :

• Un routeur MX Series

• Un équipement de couche 3 fonctionnant comme un routeur multicast

Avant de commencer :

• Configurez les interfaces.

• Configurez un protocole de passerelle intérieure. Consultez la bibliothèque de protocoles de routage Junos OS pour les équipements de routage.

• Configurez un protocole multicast. Cette fonctionnalité fonctionne avec les protocoles multicast suivants :

  • DVMRP

  • PIM-DM

  • PIM-SM

  • PIM-SSM

La surveillance IGMP empêche les équipements de couche 2 d’inonder indifféremment le trafic multicast de toutes les interfaces. Les paramètres que vous configurez pour la surveillance multicast aident à gérer le comportement de la surveillance IGMP.

Vous pouvez configurer des options de surveillance multicast sur l’instance maître par défaut et sur les instances de pont ou VPLS individuelles. La configuration d’instance maître par défaut est globale et s’applique à toutes les instances de pont ou VPLS individuelles du routeur logique. La configuration des instances individuelles remplace la configuration globale.

Cet exemple comprend les déclarations suivantes :

• flood-groups : vous permet de lister les adresses de groupes multicast pour lesquelles le trafic doit être inondé. Ce paramètre s’il est utile pour s’assurer que la surveillance IGMP n’empêche pas les inondations multicast nécessaires. Le bloc d’adresses multicast de 224.0.0.1 à 224.0.0.255 est réservé à une utilisation filaire locale. Les groupes de cette plage sont assignés à diverses utilisations, y compris les protocoles de routage et les mécanismes de découverte locaux. Par exemple, OSPF utilise 224.0.0.5 pour tous les routeurs OSPF.

• transfert-cache : spécifie comment les entrées de transfert sont vieillies et comment le nombre d’entrées est contrôlé.

  Vous pouvez configurer des valeurs de seuil sur le cache de transfert pour supprimer (suspendre) la surveillance lorsque les entrées de cache atteignent un certain maximum et réutiliser le cache lorsque le nombre tombe à une autre valeur de seuil. Par défaut, aucune valeur seuil n’est activée sur le routeur.

  Le seuil de suppression supprime les nouvelles entrées de cache de transfert multicast. Un seuil de réutilisation facultatif spécifie le point à partir duquel le routeur commence à créer de nouvelles entrées de cache de transfert multicast. Les deux seuils sont de 1 à 200 000. En cas de configuration, la valeur de réutilisation doit être inférieure à la valeur de suppression. La valeur de suppression est obligatoire. Si vous ne spécifiez pas la valeur de réutilisation facultative, le nombre d’entrées de cache de transfert multicast est limité à la valeur de suppression. Une nouvelle entrée est créée dès que le nombre d’entrées de cache de transfert multicast tombe en dessous de la valeur de suppression.

• graceful-restart : configure le temps après lequel les routes apprises avant un redémarrage sont remplacées par des routes réapprendes. Si le redémarrage progressif pour la surveillance multicast est désactivé, les informations de surveillance sont perdues après le redémarrage d’un moteur de routage.

  Par défaut, la durée de redémarrage est de 180 secondes (3 minutes). Vous pouvez définir cette valeur entre 0 et 300 secondes. Si vous définissez la durée sur 0, le redémarrage progressif est effectivement désactivé. Définissez cette valeur légèrement supérieure à l’intervalle de réponse aux requêtes IGMP.

• ignore-stp-topology-change : configure le routeur MX Series pour ignorer les messages concernant le changement d’état de topologie Spanning-Tree.

  Par défaut, le processus de surveillance IGMP sur un routeur MX Series détecte les modifications d’état d’interface apportées par n’importe quel protocole Spanning Tree (STP).

  Dans un environnement de multihébergement VPLS où deux routeurs PE sont connectés à deux routeurs CE interconnectés et où la protection racine STP est activée sur les routeurs PE, l’une des interfaces de routeur PE est en état de transfert et l’autre est en état de blocage.

  Si la liaison qui interconnecte les deux routeurs CE échoue, l’interface du routeur PE bloque les transitions d’état vers l’état de transfert.

  L’interface du routeur PE n’attend pas pour recevoir les rapports d’appartenance en réponse à la prochaine requête générale ou spécifique au groupe. Au lieu de cela, le processus de surveillance IGMP envoie un message de requête général au routeur CE. Les hôtes connectés au routeur CE répondent avec des rapports pour tous les groupes qui les intéressent.

  Lorsque la liaison interconnectant les deux routeurs CE est restaurée, l’état d’origine spanning-tree des deux routeurs PE est rétabli. Le PE de transfert reçoit un message de modification de topologie Spanning-Tree et envoie un message de requête général au routeur CE pour reconstruire immédiatement l’état d’appartenance au groupe.

  Note:

  L’instruction ignore-stp-topology-change est prise en charge uniquement pour le type d’instance de routage de commutateur virtuel .

Topologie

La figure 1 montre une topologie de multihébergement VPLS dans laquelle un réseau client dispose de deux équipements CE avec une liaison entre eux. Chaque CE est connecté à un PE.

Figure 1 : Topologie multihébergement VPLS

Pour vérifier la configuration, exécutez les commandes suivantes :

• afficher l’interface de surveillance igmp

• afficher l’appartenance igmp à la surveillance

• afficher les statistiques de surveillance igmp

• afficher une route de surveillance multicast

• afficher la table de routage