Dépannage de Multicast Auto-RP sur Nexus 9000 avec NX-OS

Introduction

Ce document décrit comment Auto-RP fonctionne sur Cisco Nexus 9000 avec NX-OS et comment valider et dépanner le fonctionnement de la multidiffusion.

Conditions préalables

Exigences

• Connaissance de base de la multidiffusion IP
• Connaissances de base des modes IGMP et PIM Sparse
• Expérience avec Cisco Nexus 9000 et NX-OS CLI
• Compréhension du routage monodiffusion et des concepts RPF

Composants utilisés

• Cisco Nexus 9000 Series Switches
• Logiciel Cisco NX-OS
• Mode intermédiaire PIM
• RP statique et Auto-RP

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Présentation de la multidiffusion

La multidiffusion est un modèle de communication un-à-plusieurs dans lequel une source envoie un flux de trafic unique à plusieurs récepteurs intéressés. Au lieu de créer une copie distincte pour chaque destination, le réseau réplique le trafic uniquement là où le chemin de transfert bifurque. Cela rend la multidiffusion plus efficace que les transmissions de diffusion ou de monodiffusion répétée. Dans IPv4, le trafic de multidiffusion utilise des adresses de destination de la plage 224.0.0.0/4.

PIM Sparse Mode est le modèle de routage multicast pris en charge sur les commutateurs Cisco Nexus exécutant NX-OS. Il transfère le trafic uniquement lorsque l'intérêt du récepteur a été explicitement appris. Dans une conception de multidiffusion Any-Source, les récepteurs rejoignent initialement une arborescence partagée vers le point de rendez-vous, et les sources s'enregistrent auprès de ce RP. Une fois que le trafic commence à circuler, le routeur du dernier saut peut passer de l’arborescence partagée à l’arborescence du plus court chemin vers la source.

Il est important de définir la terminologie utilisée dans la multidiffusion, car un dépannage précis dépend de la compréhension de la manière dont les événements du plan de contrôle, les entrées de routage et les décisions de transfert sont représentés. Une terminologie claire permet d'interpréter correctement les résultats des commandes, de distinguer le comportement de l'arborescence partagée du comportement de l'arborescence source et d'identifier le rôle de chaque composant de multidiffusion dans le processus de transfert de bout en bout.

Terme	Définition
Adresse du groupe multidiffusion	Adresse de destination IPv4 dans la plage 224.0.0.0/4 utilisée pour identifier un groupe de multidiffusion.
Adresse source	Adresse IP de monodiffusion de l'expéditeur transmettant le trafic à un groupe de multidiffusion.
mroute	Entrée de routage de multidiffusion qui définit la manière dont le trafic de multidiffusion pour un groupe ou une combinaison de groupe source est géré.
IIF	Interface entrante. Interface sur laquelle le trafic de multidiffusion est attendu.
OIF	Interface de sortie. Interface utilisée pour transférer le trafic de multidiffusion vers des récepteurs ou des voisins en aval.
HUILE	Liste des interfaces sortantes. Ensemble d'interfaces sortantes associées à une entrée de routage de multidiffusion.
RPF	Transfert de chemin inverse. Contrôle qui vérifie si le trafic de multidiffusion est arrivé sur la bonne interface en fonction de la route de monodiffusion vers la source ou le RP.
HAR	Arborescence de distribution multidiffusion. Arborescence logique qui transporte le trafic de multidiffusion de la source vers tous les récepteurs.
RPT	Arbre RP, également appelé arbre partagé. Il connecte les récepteurs au RP et est représenté par (*, G).
SPT	L'arborescence du plus court chemin, également appelée arborescence source. Il connecte les récepteurs directement à la source et est représenté par (S, G).
FHR	Routeur de premier saut. Le routeur de multidiffusion directement connecté à la source et responsable de l'enregistrement de la source auprès du RP.
LHR	Routeur de dernier saut. Le routeur multicast connecté directement aux récepteurs et responsable de la création de l'état multicast après avoir appris l'intérêt du récepteur via IGMP.
RP	Point de rendez-vous. Point de réunion logique utilisé en mode intermédiaire ASM et PIM pour connecter initialement des sources et des récepteurs.
ASM	Multidiffusion À Toutes Les Sources. Modèle de multidiffusion dans lequel les récepteurs rejoignent un groupe sans spécifier la source à l'avance.

Il est important de comprendre les adresses de multidiffusion réservées connues, car le dépannage de la multidiffusion dépend de l’identification rapide du protocole de contrôle qui utilise un groupe de destinations donné et de la fonction que le trafic remplit sur le réseau. Ces adresses permettent de distinguer un fonctionnement normal du protocole d'un comportement anormal et facilitent la validation des échanges IGMP, PIM et Auto-RP. Pour l'Auto-RP en particulier, les groupes les plus importants à reconnaître sont 224.0.1.39 pour RP-Announce et 224.0.1.40 pour RP-Discovery, car ils transportent les informations qui permettent aux routeurs d'apprendre les mappages dynamiques RP.

Adresse de multidiffusion	Objectif
224.0.0.1	Tous les hôtes du sous-réseau local
224.0.0.2	Tous les routeurs du sous-réseau local
224.0.0.13	Tous les routeurs PIM
224.0.0.22	Messages IGMPv3
224.0.1.39	Messages d'annonce RP Cisco utilisés par Auto-RP
224.0.1.40	Messages Cisco RP-Discovery utilisés par Auto-RP

Fonctionnement d'Auto-RP en mode intermédiaire PIM (workflow du plan de contrôle)

Auto-RP est un mécanisme Cisco utilisé en mode intermédiaire de multidiffusion indépendante du protocole pour détecter et distribuer dynamiquement les informations de point de rendez-vous (RP) dans le domaine de multidiffusion. Il élimine le besoin de configuration RP statique en utilisant des messages de plan de contrôle basés sur la multidiffusion pour annoncer, sélectionner et apprendre les mappages RP-à-groupe. Ses principaux composants sont les RP candidats, qui offrent des services RP pour des plages de groupes spécifiques, et les agents de mappage, qui collectent les candidats et décident du RP actif par groupe.

Le processus commence lorsque chaque RP candidat envoie périodiquement des messages RP-Announce à 224.0.1.39, y compris son adresse IP, sa priorité et les plages de groupes de multidiffusion prises en charge. Ces messages sont diffusés sur tout le réseau à l'aide de l'écouteur Auto-RP dans NX-OS, ce qui garantit que tous les agents de mappage les reçoivent avant même que le réseau fonctionne entièrement en mode intermédiaire.

Les agents de mappage écoutent ces annonces, créent une base de données RP candidate et effectuent un processus de sélection déterministe par groupe (généralement la priorité la plus élevée, puis l'adresse IP la plus élevée). Une fois que le meilleur RP est choisi, l'agent de mappage génère des messages RP-Discovery et les envoie à 224.0.1.40, annonçant les mappages RP-to-group finaux à tous les routeurs du domaine.

Tous les routeurs PIM reçoivent les messages RP-Discovery et installent les mappages dans leurs tables RP locales. Avec ces informations, les routeurs de dernier saut (connectés aux récepteurs) envoient des messages PIM Join vers le RP sélectionné pour construire l'arborescence partagée (RPT), tandis que les routeurs de premier saut (connectés aux sources) encapsulent le trafic de multidiffusion dans les messages PIM Register pour informer le RP des sources actives.

À mesure que le trafic circule dans le RP, les routeurs peuvent en option passer de l'arborescence partagée (RPT) à une arborescence du plus court chemin (SPT) en utilisant la signalisation PIM Join/Prune supplémentaire directement vers la source. Tout au long de ce processus, Auto-RP actualise continuellement les mappages via des messages de contrôle périodiques, garantissant la résilience et l'adaptation automatique à la topologie ou aux modifications RP.

Fonctionnement d'Auto-RP en mode intermédiaire PIM (workflow du plan de contrôle)

Limitations Auto-RP et contraintes opérationnelles

• Auto-RP fonctionne uniquement avec la multidiffusion IPv4 et n'est pas pris en charge pour IPv6 (PIM6), de sorte que les déploiements IPv6 nécessitent un mécanisme de détection RP différent.
• Auto-RP ne peut pas coexister avec BSR dans le même domaine PIM, car un seul mécanisme de détection RP peut être configuré afin d'éviter les conflits de plan de contrôle.
• Les messages Auto-RP ne sont pas traités ou transférés par défaut sur les périphériques NX-OS, de sorte qu'une configuration explicite est requise pour un fonctionnement correct.
• La propagation des messages de contrôle Auto-RP dépend de l'activation de l'écouteur Auto-RP ; sinon, les informations de mappage RP n'atteignent pas tous les routeurs.
• L'intervalle d'annonce RP a un seuil minimum de 15 secondes, ce qui limite la vitesse à laquelle les mises à jour RP peuvent être annoncées et affecte le temps de convergence.
• Le filtrage automatique des messages RP via les cartes de routage peut affecter le fonctionnement, car des stratégies incorrectes peuvent bloquer les mappages RP-à-groupe.
• L'Auto-RP est désactivé par défaut dans les contextes VRF, il doit donc être explicitement activé dans les déploiements multi-VRF.

• Le transfert multichemin basé sur ECMP est activé par défaut, ce qui permet au trafic multidiffusion d'utiliser des chemins à coût égal pour l'équilibrage de charge.

• L'authentification de voisin PIM utilisant IPsec AH-MD5 est prise en charge.

• La surveillance PIM n'est pas disponible.

Avantages de l'utilisation d'Auto-RP

L'Auto-RP fournit une découverte dynamique RP et une distribution de mappage RP centralisée pour les environnements de multidiffusion PIM Sparse Mode. Il élimine le besoin de configuration RP statique sur chaque routeur multidiffusion, réduit la complexité opérationnelle et améliore l'évolutivité multidiffusion. Auto-RP prend également en charge plusieurs RP-Candidates, ce qui permet le basculement et la redondance automatiques du RP. Ce mécanisme permet de maintenir un comportement de transfert multidiffusion cohérent, simplifie l'extension du réseau et permet aux routeurs multidiffusion d'apprendre automatiquement les informations RP sur l'ensemble du domaine.

Agent de mappage Auto-RP et processus de sélection RP

Le processus de sélection dans Auto-RP est déterministe et principalement basé sur les adresses IP. Contrairement à d'autres protocoles (tels que PIMv2 BSR), Auto-RP n'utilise pas de valeur de « priorité » configurable ; au lieu de cela, il s'appuie sur la hiérarchie des adresses IP pour résoudre les conflits.

Sélection de l'agent de mappage (MA)

Dans Auto-RP, plusieurs agents de mappage peuvent coexister dans le même réseau pour la redondance. Il n'y a pas de processus électoral formel où l'un s'éteint et l'autre s'allume ; tous sont techniquement actifs. Cependant, les commutateurs du réseau doivent décider des informations auxquelles ils doivent faire confiance.

• Critère de sélection : Adresse IP la plus élevée.
• Le processus :
  1. Tous les agents de mappage envoient leurs messages RP-Discovery au groupe de multidiffusion 224.0.1.40.
  2. Les commutateurs clients reçoivent ces messages.
  3. Si un commutateur reçoit des messages de détection de deux agents de mappage différents contenant des informations conflictuelles, il accepte les informations de l'agent de mappage dont l'adresse IP source est la plus élevée.
  4. Comportement de Nexus : Un agent de mappage avec une adresse IP inférieure passe généralement à l'état « passif » ou « suppression » lorsqu'il détecte un autre MA avec une adresse IP supérieure afin d'empêcher le trafic de contrôle en double dans le réseau.

Sélection du point de rendez-vous (RP)

Ce processus est effectué par l'agent de mappage après avoir écouté tous les messages RP-Announce (envoyés au groupe 224.0.1.39) des candidats.

Lorsque l'agent de mappage reçoit plusieurs candidats pour le même groupe de multidiffusion, il applique ces règles dans l'ordre suivant :

Règle A : Correspondance de préfixe la plus longue (masque le plus spécifique)

Si les candidats annoncent des plages qui se chevauchent, l’EM attribue le groupe au RP qui a annoncé la plage la plus petite (le masque de sous-réseau le plus long).

• Exemple :
  • Le candidat A annonce 224.0.0.0/4 (the (plage de multidiffusion complète).
  • Le candidat B annonce 224.10.20.0/24.
  • Résultat : Pour le groupe 224.10.20.5, le candidat B est gagnant car sa plage est plus spécifique.

Règle B : Adresse IP la plus élevée (Interrupteur de connexion)

Si deux candidats ou plus annoncent exactement la même plage de groupes, l'agent de mappage ne doit en choisir qu'un seul.

• Critère : Le candidat ayant l'adresse IP la plus élevée l'emporte.
• Exemple :
  • Candidat 1 : 10.2.0.1 pour la plage 224.10.20.0/24.
  • Candidat 2 : 10.2.0.4 pour la plage 224.10.20.0/24.
  • Résultat : L'agent de mappage sélectionne 10.2.0.4 comme RP officiel pour cette plage et ceci est annoncé dans ses messages de détection.

Considérations de couche 2 : MAC multidiffusion et surveillance

Bien que cet article se concentre sur la multidiffusion de couche 3 utilisant le protocole PIM, le comportement de couche 2 joue un rôle essentiel dans le dépannage et la conception globale. Au niveau de la couche 2, les périphériques communiquent à l'aide d'adresses MAC, qui sont des identificateurs 48 bits attribués aux interfaces réseau. Le trafic multidiffusion nécessite un schéma d'adressage MAC spécifique pour le différencier du trafic de monodiffusion et de diffusion.

Les adresses MAC de multidiffusion IPv4 sont dérivées des adresses de groupe de multidiffusion de couche 3 à l'aide du préfixe réservé `01:00:5E`. Cependant, seuls 23 bits de l'adresse de multidiffusion IP sont mappés dans l'adresse MAC, ce qui crée un chevauchement 32:1, ce qui signifie que jusqu'à 32 groupes IP de multidiffusion différents peuvent être mappés à la même adresse MAC. Par conséquent, les hôtes qui écoutent une adresse MAC de multidiffusion donnée peuvent recevoir du trafic pour plusieurs groupes de multidiffusion, même s'ils ne sont intéressés que par un seul. Par exemple, 224.1.1.1, 225.1.1.1, 226.1.1.1, 227.1.1.1, 228.1.1.1, etc.

Ce chevauchement a des conséquences directes sur l'efficacité et le dépannage du réseau. Étant donné que les décisions de transfert de couche 2 basées uniquement sur les adresses MAC ne peuvent pas distinguer les groupes de multidiffusion qui se chevauchent, les commutateurs peuvent fournir un trafic inutile aux hôtes. Ces hôtes doivent ensuite s'appuyer sur le filtrage de couche supérieure (IP/IGMP) pour éliminer les paquets indésirables, ce qui consomme les ressources du processeur et de la mémoire tampon.

Dans Cisco Nexus NX-OS, cette limitation est atténuée par le comportement de la surveillance IGMP. Par défaut, la surveillance IGMP effectue des recherches basées sur IP plutôt qu'un transfert uniquement MAC, ce qui permet aux commutateurs de prendre des décisions de transfert plus précises même lorsque plusieurs groupes de multidiffusion partagent la même adresse MAC. Cela améliore considérablement l'efficacité de la couche 2 et réduit la livraison de trafic inutile.

Configuration du protocole Auto-RP

Cette section fournit une explication détaillée de la configuration Auto-RP, en utilisant une implémentation simple comme référence. Dans cette configuration, une source de multidiffusion est connectée à deux commutateurs Nexus via vPC pour acheminer le trafic vers un récepteur. Dans cette conception, N9K-1 et N9K-2 fonctionnent simultanément en tant que candidats RP et agents de mappage.

Flux de trafic multidiffusion

Routeur de premier saut

La même configuration dispose de FHR-2.

FHR-1# show running-config pim
feature pim
ip pim auto-rp forward listen

interface Vlan1
  ip pim sparse-mode

interface Ethernet1/1
  ip pim sparse-mode

interface Ethernet1/3
  ip pim sparse-mode

Commande	Objectif / Description
feature pim	Active le processus PIM (Protocol Independent Multicast) sur le commutateur.
ip pim auto-rp forward listen	Active l'écouteur Auto-RP. Cela permet au commutateur de recevoir et de transférer des messages de contrôle Auto-RP (224.0.1.39 et 224.0.1.40) même s'il ne connaît pas encore l'identité du RP.
ip pim sparse-mode	Active le mode intermédiaire PIM sur une interface spécifique. Dans ce mode, le trafic de multidiffusion est uniquement transféré aux segments qui l'ont explicitement demandé via des messages de jointure PIM.

Agent de mappage et candidat RP

N9K-1# show running-config pim
feature pim

ip pim auto-rp rp-candidate loopback0 group-list 224.10.20.0/24 interval 15
ip pim auto-rp mapping-agent loopback1

interface loopback0
  ip pim sparse-mode

interface loopback1
  ip pim sparse-mode

interface Ethernet1/3
  ip pim sparse-mode

interface Ethernet1/4
  ip pim sparse-mode

interface Ethernet1/49
  ip pim sparse-mode

Ce tableau fournit une répartition technique détaillée de la configuration PIM pour N9K-1. Cette configuration est répliquée sur N9K-2. Les deux commutateurs sont configurés avec un double rôle, agissant à la fois comme candidat RP et comme agent de mappage pour le domaine de multidiffusion.

Commande	Explication technique détaillée
feature pim	Activation des fonctionnalités : Active globalement le moteur PIM (Protocol Independent Multicast) sur le commutateur Nexus.
ip pim auto-rp rp-candidate loopback0 group-list 224.10.20.0/24 interval 15	Rôle du candidat RP : Configure ce commutateur en tant que point de rendez-vous (RP) « volontaire ». Source : Utilise l’adresse IP de loopback0 Portée : Il permet de gérer la plage de groupes de multidiffusion 224.10.20.0/24. Intervalle : Envoie des messages « Annonce » à l'agent de mappage toutes les 15 secondes. Le minuteur d'attente est trois fois cette valeur.
ip pim auto-rp mapping-agent loopback1	Rôle d'agent de mappage : Configure le commutateur comme « administrateur » du processus Auto-RP. Fonction: Il écoute tous les candidats RP, résout les conflits (en utilisant l'adresse IP la plus élevée comme point de rupture) et diffuse les messages de « détection » au reste du réseau pour les informer de qui est le RP actif.
interface loopback0 / loopback1	Interfaces logiques : PIM est activé sur ces interfaces parce qu'elles servent d'IP source pour les rôles de candidat RP et d'agent de mappage. Ils doivent être accessibles via la table de routage de monodiffusion de tous les routeurs PIM.
interface Ethernet1/3, 1/4, 1/49	Transfert physique : Active le mode intermédiaire PIM sur les ports physiques. Cela permet au commutateur de former des contiguïtés de voisinage PIM avec d'autres routeurs et de transférer le trafic de multidiffusion sur ces liaisons spécifiques.
ip pim sparse-mode	Mode de fonctionnement : Appliqué à toutes les interfaces ci-dessus. Il garantit que le trafic de multidiffusion est uniquement envoyé aux destinataires qui l'ont explicitement demandé via des messages PIM Join, ce qui évite une inondation inutile du réseau.

Configuration du routage pour l'accessibilité IPv4

• Dans cette topologie, tous les commutateurs Nexus participent à un processus OSPF unique appelé UNDERLAY, fonctionnant dans la zone 0 (0.0.0.0) pour fournir une accessibilité de routage complète sur le réseau.
• Sur le LHR, le protocole OSPF est activé sur le VLAN 2, qui sert de passerelle pour le récepteur multidiffusion, et sur les interfaces de liaison ascendante Ethernet1/49 et Ethernet1/50, toutes deux configurées en tant que point à point. Cela garantit une formation de contiguïté efficace vers les commutateurs N9K en amont sans sélection de DR/BDR.
• La couche FHR (FHR-1 et FHR-2) partage une configuration identique. Le protocole OSPF est activé sur le VLAN 1, qui sert de passerelle pour la source de multidiffusion, et sur les liaisons ascendantes routées (Ethernet1/1 et Ethernet1/3) vers la couche d'agrégation. Ces liaisons sont également configurées comme point à point, ce qui optimise la convergence et le comportement de contiguïté.
• De même, N9K-1 et N9K-2 ont des configurations OSPF identiques, avec l'ajout de l'annonce Loopback0 et Loopback1 dans OSPF.
  • Ces boucles sont critiques, car elles sont utilisées ultérieurement pour les rôles de candidat RP PIM et d'agent de mappage.

Voisins PIM et zone OSPF 0

N9K-1 — Configuration OSPF

N9K-1(config)# show running-config ospf
feature ospf

router ospf UNDERLAY
  router-id 10.2.0.1

interface loopback0
  ip router ospf UNDERLAY area 0.0.0.0

interface loopback1
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/3
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/4
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/49
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

FHR-1 — Configuration OSPF

FHR-1(config)# show running-config ospf
feature ospf

router ospf UNDERLAY

interface Vlan1
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/1
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/3
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

LHR — Configuration OSPF

LHR(config)# show running-config ospf
feature ospf

router ospf UNDERLAY

interface Vlan2
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/49
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/50
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

Vérification de l'état opérationnel et dépannage du protocole Auto-RP

Étape 1: Vérifier l'accessibilité IP de base (validation de sous-couche monodiffusion)

Avant d'analyser le comportement de multidiffusion, il est essentiel de vérifier que le sous-réseau de monodiffusion (zone 0 OSPF) est pleinement opérationnel. Les protocoles de plan de contrôle de multidiffusion tels que PIM et Auto-RP dépendent de l'accessibilité de monodiffusion pour fonctionner correctement.

La première étape de validation consiste à confirmer que la source et le récepteur (ou leurs passerelles de couche 3 les plus proches : FHR et LHR) sont accessibles.

À partir de la topologie :

• FHR-1 / FHR-2 → La plus proche de la source de multidiffusion (10.150.1.37 - VLAN 1)

• LHR → Récepteur de multidiffusion le plus proche (192.168.2.37 - VLAN 2)

Méthode de validation

1. Effectuez des tests d’accessibilité ICMP entre :

• FHR ↔ LHR

• FHR ↔ Sous-réseau du récepteur (passerelle VLAN 2)

• LHR ↔ Sous-réseau source (passerelle VLAN 1)

2. Validez l’accessibilité de la source et du récepteur dans la table de routage. Pour les déploiements vPC, assurez la cohérence entre les deux homologues Nexus. Notez que le récepteur possède un chemin ECMP, tandis que la source est accessible via la couche 2.

FHR-1 — Route vers la source

FHR-1# show ip route 10.150.1.37

10.150.1.37/32, ubest/mbest: 1/0, attached
    *via 10.150.1.37, Vlan1, [250/0], 06:57:19, am

FHR-1 — Route vers le récepteur

FHR-1# show ip route 192.168.2.37

192.168.2.0/24, ubest/mbest: 2/0
    *via 10.4.0.6, Eth1/3, [110/45], 04:11:08, ospf-UNDERLAY, intra
    *via 10.4.0.10, Eth1/1, [110/45], 04:11:08, ospf-UNDERLAY, intra

FHR-2 — Route vers la source

FHR-2# show ip route 10.150.1.37

10.150.1.37/32, ubest/mbest: 1/0, attached
    *via 10.150.1.37, Vlan1, [250/0], 07:03:45, am

FHR-2 — Route vers le récepteur

FHR-2# show ip route 192.168.2.37

192.168.2.0/24, ubest/mbest: 2/0
    *via 10.4.0.13, Eth1/3, [110/45], 04:16:16, ospf-UNDERLAY, intra
    *via 10.4.0.18, Eth1/4, [110/45], 04:16:16, ospf-UNDERLAY, intra

LHR — Route vers la source

LHR(config)# show ip route 10.150.1.37

10.150.1.0/24, ubest/mbest: 2/0
    *via 10.4.0.22, Eth1/49, [110/45], 04:14:52, ospf-UNDERLAY, intra
    *via 10.4.0.26, Eth1/50, [110/45], 04:14:52, ospf-UNDERLAY, intra

LHR — Route vers le récepteur

LHR(config)# show ip route 192.168.2.37

192.168.2.37/32, ubest/mbest: 1/0, attached
    *via 192.168.2.37, Vlan2, [250/0], 06:47:21, am

Considérations importantes

• L'échec de ce test indique clairement un problème sous-jacent.

• La multidiffusion ne peut pas fonctionner correctement sans accessibilité de monodiffusion, car :

  • Les voisins PIM reposent sur le routage monodiffusion

  • Les adresses RP (bouclage) doivent être accessibles

  • Les vérifications RPF (Reverse Path Forwarding) dépendent de la table de routage

• Une requête ping réussie ne garantit pas que la multidiffusion peut fonctionner, car :

  • ICMP peut être autorisé lorsque la multidiffusion est bloquée

  • PIM ou Auto-RP peuvent toujours être mal configurés

Étape 2: Identification des rôles de multidiffusion et de la topologie de bout en bout

L'étape suivante consiste à identifier clairement le rôle de chaque périphérique impliqué dans le transfert du trafic de multidiffusion. Cette étape est obligatoire, car le dépannage de la multidiffusion dépend entièrement de la compréhension du flux de trafic et du comportement attendu dans la topologie.

Au minimum, ces éléments doivent être identifiés :

• Source De Multidiffusion (S) : 10.150.1.37 (VLAN 1)

• Groupe de multidiffusion (G) : 224.10.20.10

• Récepteur : 192.168.2.37 (VLAN 2)

• Routeur de premier saut (FHR) : FHR-1 / FHR-2 (le plus proche de la source)

• Routeur de dernier saut (LHR) : LHR (le plus proche du récepteur)

En outre, il est nécessaire d'identifier les rôles du plan de contrôle :

• Candidats RP : N9K-1 et N9K-2 (Loopback0)

• Agents de mappage : N9K-1 et N9K-2 (bouclage1)

Reconnaissance de la topologie et du plan de contrôle

Une topologie de réseau détaillée est obligatoire pour poursuivre le dépannage de la multidiffusion. Cela inclut :

• Connectivité physique (interfaces utilisées entre les périphériques)

• Topologie logique (VLAN, liaisons routées, relations vPC)

• Protocole de routage utilisé (zone OSPF 0 dans cette conception)

• Limites de domaine de routage (IGP unique ou protocoles mixtes tels qu'OSPF, EIGRP ou BGP)

• Interfaces de bouclage utilisées pour les rôles RP et Mapping Agent

• Interfaces compatibles PIM et relations de voisinage

Ce Qui Doit Être Clairement Compris

• Le chemin exact depuis la source → FHR → RP → LHR → Récepteur

• Quels périphériques sont responsables de :

  • Envoi du registre PIM (FHR)

  • Arbres du bâtiment (*, G) ou (S, G) (LHR)

  • Annonce des informations RP (Mapping Agent)

• Comment le routage (OSPF) garantit l'accessibilité pour :

  • Sous-réseau source

  • Sous-réseau du récepteur

  • Adresses de bouclage RP

  • Mappage des adresses de bouclage des agents

Étape 3: Valider la configuration Auto-RP en fonction du rôle du périphérique

L'étape suivante consiste à vérifier que le protocole Auto-RP est correctement configuré sur chaque périphérique en fonction de son rôle dans la topologie de multidiffusion. Cela inclut la confirmation que :

• Les candidats RP (N9K-1 / N9K-2) sont correctement configurés pour annoncer leur Loopback0 comme RP pour la plage de groupes de multidiffusion.

• Les agents de mappage (N9K-1 / N9K-2) sont configurés pour collecter les messages RP-Announce et générer des messages RP-Discovery à l'aide de Loopback1.

• FHR et LHR ont le mode intermédiaire PIM activé sur toutes les interfaces pertinentes pour participer à l'Auto-RP et recevoir les mappages RP.

Il est essentiel de s'assurer que toutes les interfaces requises (y compris les boucles et les liaisons routées) sont activées pour le mode intermédiaire PIM, et qu'il n'y a aucune configuration manquante qui empêcherait l'échange de messages RP-Announce (224.0.1.39) et RP-Discovery (224.0.1.40).

Étape 4: Valider le fonctionnement de tous les candidats RP et de tous les agents de mappage

Étape 4.1 Vérification des contiguïtés de voisinage PIM

La première étape de validation consiste à confirmer que tous les voisins PIM attendus sont correctement établis dans la topologie de multidiffusion.

N9K-1 : vérification des voisins PIM

N9K-1# show ip pim neighbor

PIM Neighbor Status for VRF "default"
Neighbor        Interface            Uptime    Expires   DR       Bidir-  BFD    ECMP Redirect
                                                         Priority Capable State     Capable
10.4.0.5        Ethernet1/3          23:19:45  00:01:20  1        yes     n/a     no
10.4.0.14       Ethernet1/4          23:19:45  00:01:38  1        yes     n/a     no
10.4.0.21       Ethernet1/49         23:19:45  00:01:38  1        yes     n/a     no

N9K-2 : vérification des voisins PIM

N9K-2# show ip pim neighbor

PIM Neighbor Status for VRF "default"
Neighbor        Interface            Uptime    Expires   DR       Bidir-  BFD    ECMP Redirect
                                                         Priority Capable State     Capable
10.4.0.9        Ethernet1/3          23:21:18  00:01:29  1        yes     n/a     no
10.4.0.17       Ethernet1/4          23:21:18  00:01:23  1        yes     n/a     no
10.4.0.25       Ethernet1/49         23:21:18  00:01:44  1        yes     n/a     no

Points de validation

• Vérifiez que tous les voisins attendus apparaissent sur chaque interface routée.
• Vérifiez que le temps de disponibilité du voisin est stable et qu'il augmente constamment.
• Vérifiez que le minuteur Expire est actualisé régulièrement.
• Vérifiez qu'aucun flap de contiguïté inattendu ne se produit.
• Vérifiez la sélection correcte du routeur désigné (DR).
• Vérifiez que les interfaces de multidiffusion forment correctement les contiguïtés PIM.

Dans cette topologie :

• N9K-1 établit trois voisins PIM.
• N9K-2 établit également trois voisins PIM.
• Toutes les contiguïtés restent stables pendant plus de 23 heures, ce qui indique un fonctionnement stable du plan de contrôle de multidiffusion.

---

Étape 4.2 Vérification des interfaces compatibles PIM

L'étape suivante consiste à confirmer que toutes les interfaces participant à Auto-RP sont activées pour PIM.

Cette validation est particulièrement importante pour :

• Boucles RP-Candidate
• Bouclages de Mapping Agent

N9K-1 : vérification des interfaces PIM

N9K-1# show ip pim interface brief

PIM Interface Status for VRF "default"
Interface            IP Address      PIM DR Address  Neighbor  Border
                                                     Count     Interface
Ethernet1/3          10.4.0.6        10.4.0.6        1         no
Ethernet1/4          10.4.0.13       10.4.0.14       1         no
Ethernet1/49         10.4.0.22       10.4.0.22       1         no
loopback0            10.2.0.1        10.2.0.1        0         no
loopback1            10.2.1.5        10.2.1.5        0         no

N9K-2 : vérification des interfaces PIM

N9K-2# show ip pim interface brief

PIM Interface Status for VRF "default"
Interface            IP Address      PIM DR Address  Neighbor  Border
                                                     Count     Interface
Ethernet1/3          10.4.0.10       10.4.0.10       1         no
Ethernet1/4          10.4.0.18       10.4.0.18       1         no
Ethernet1/49         10.4.0.26       10.4.0.26       1         no
loopback0            10.2.0.4        10.2.0.4        0         no
loopback1            10.2.1.4        10.2.1.4        0         no

Points de validation :

• Vérifiez que toutes les interfaces de multidiffusion routées apparaissent dans le résultat.
• Vérifiez que les boucles RP-Candidate sont compatibles PIM.
• Vérifiez que les boucles de l'agent de mappage sont compatibles PIM.
• Vérifiez que les nombres de voisins sont corrects sur les interfaces de transit.
• Vérifiez que les interfaces de bouclage affichent correctement le nombre de voisins = 0.

Attribution du rôle de bouclage :

Périphérique	Fonction	Bouclage
N9K-1	RP-candidat	10.2.0.1
N9K-1	Agent de mappage	10.2.1.5
N9K-2	RP-candidat	10.2.0.4
N9K-2	Agent de mappage	10.2.1.4

Les boucles apparaissent correctement en tant qu'interfaces PIM actives même si elles ne forment pas de voisins PIM. Ce comportement est attendu car les interfaces de bouclage n'établissent pas directement de contiguïtés de multidiffusion.

La présence de ces boucles confirme que :

• PIM peut générer correctement les messages de contrôle Auto-RP.
• Les annonces RP peuvent être émises correctement.
• La fonctionnalité Mapping Agent peut fonctionner correctement.

---

Étape 4.3 Analyse de la commande show ip pim rp

Cette commande valide :

• Détection RP
• Annonces Auto-RP
• Fonctionnement de Mapping Agent
• Mappages de groupe à RP

N9K-1 — Informations RP

N9K-1# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5*, next Discovery message in: 00:00:39
BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

RP: 10.2.0.1*, (0),
 uptime: 22:18:44   priority: 255,
 RP-source: 10.2.0.1 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:00:37 (A)

RP: 10.2.0.4, (0),
 uptime: 23:00:32   priority: 255,
 RP-source: 10.2.0.4 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:00:44 (A)

Explication ligne par ligne

BSR désactivé

BSR disabled

Cela confirme que :

• Le routeur d'amorçage (BSR) n'est pas utilisé.
• Le domaine de multidiffusion repose exclusivement sur Auto-RP.

Ce comportement est attendu dans cette topologie.

RPA Auto-RP : 10.2.1.5*

Auto-RP RPA: 10.2.1.5*

• 10.2.1.5 correspond à loopback1 sur N9K-1.
• Le symbole * indique que le commutateur local est lui-même l'agent de mappage actif.

Cela signifie :

• N9K-1 génère des messages RP-Discovery.
• N9K-1 recueille les annonces RP des candidats RP.
• N9K-1 distribue les informations de mappage RP au domaine de multidiffusion.

Message de détection suivant dans

next Discovery message in: 00:00:39

• Vérifiez que le minuteur est actualisé en permanence.
• Vérifiez que les messages de détection sont envoyés régulièrement.

Si ce minuteur se fige ou expire de manière inattendue, les annonces Auto-RP ne peuvent pas se propager correctement.

Champs de stratégie

BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

• Aucune stratégie de filtrage n'est appliquée.
• Toutes les annonces RP et Discovery sont acceptées.

Première entrée RP

RP: 10.2.0.1*, (0),

• Adresse RP = 10.2.0.1
• L'astérisque (*) indique que ce RP est local à N9K-1.
• 10.2.0.1 correspond à loopback0 sur N9K-1.

Cela confirme que N9K-1 est configuré en tant que RP-Candidate.

Disponibilité et priorité

uptime: 22:18:44   priority: 255,

• Un temps de fonctionnement stable indique un fonctionnement stable des annonces RP.
• La priorité 255 est la priorité la plus élevée par défaut.

Source RP

RP-source: 10.2.0.1 (A),

• L'annonce RP provient directement du RP lui-même.
• (A) indique les informations apprises par le protocole Auto-RP.

Plage du groupe

224.10.20.0/24

• Vérifiez que la plage de multidiffusion correcte est annoncée.
• Vérifiez que la plage du groupe correspond à la configuration.

Deuxième entrée RP

RP: 10.2.0.4, (0),

• Un autre RP existe dans la topologie.
• 10.2.0.4 correspond à loopback0 sur N9K-2.
• Aucun * n'apparaît car ce RP est distant de N9K-1.

N9K-2 — Informations RP

N9K-2# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5, uptime: 22:19:10, expires: 00:02:28

RP: 10.2.0.4*, (0),
 uptime: 23:14:14   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:02:28 (A)

Principales différences sur N9K-2

Auto-RP RPA: 10.2.1.5

• Non * apparaît car N9K-2 n'est pas l'agent de mappage.
• N9K-2 apprend les informations de l'agent de mappage à distance à partir de N9K-1.

Différence importante de RP

RP-source: 10.2.1.5 (A),

• N9K-2 apprend les informations RP auprès de l'agent de mappage.
• Mapping Agent est 10.2.1.5.

Cela confirme que :

• Les messages de détection Auto-RP fonctionnent correctement.
• Les annonces Mapping Agent se propagent correctement dans le domaine de multidiffusion.

Étape 4.4 Validation du processus de sélection du RP automatique et de la sélection du RP

L'Auto-RP utilise deux fonctions de plan de contrôle de multidiffusion différentes :

• RP-candidat
• Agent de mappage

Il est essentiel de comprendre comment ces fonctions interagissent lors de la validation d'une opération de multidiffusion dans un environnement PIM Sparse Mode.

Dans cette topologie :

• N9K-1 et N9K-2 fonctionnent en tant que candidats RP.
• N9K-1 fonctionne comme agent de mappage actif.

Opération RP candidate

Un RP-Candidat s'annonce comme un point de rendez-vous valide pour une ou plusieurs plages de groupes de multidiffusion.

Chaque RP-Candidate envoie périodiquement des messages d'annonce Auto-RP à :

• 224.0.1.39 — Groupe d'annonce Auto-RP
  
  

Ces annonces contiennent :

• adresse RP
• Plage de groupe
• Priorité
• Temps D'Attente

Dans cette topologie :

• 10.2.0.1 sur N9K-1 s'annonce comme RP.
• 10.2.0.4 sur N9K-2 s'annonce comme RP.

N9K-1 — Informations sur les candidats RP

N9K-1# show ip pim rp
<snip>
RP: 10.2.0.1*, (0),
 uptime: 23:11:22 priority: 255,
 RP-source: 10.2.0.1 (A),
 group ranges:
 224.10.20.0/24 , expires: 00:00:38 (A)

RP: 10.2.0.4, (0),
 uptime: 23:53:09 priority: 255,
 RP-source: 10.2.0.4 (A),
 group ranges:
 224.10.20.0/24 , expires: 00:00:43 (A)

N9K-2 — Informations sur les candidats RP

N9K-2# show ip pim rp
<snip>
RP: 10.2.0.4*, (0),
 uptime: 1d00h priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24 , expires: 00:02:52 (A)

Les deux périphériques annoncent la même plage de groupes de multidiffusion :

• 224.10.20.0/24

Les deux RP-Candidats utilisent également :

• Priority (priorité) 255

C'est important parce qu'Auto-RP utilise la priorité et l'adresse RP lors de la sélection RP.

Identification de l'agent de mappage actif

L'agent de mappage sélectionne le RP actif pour un groupe de multidiffusion en commençant par cette logique :

1. La priorité RP la plus élevée gagne.
2. Si les priorités sont égales, l'adresse IP RP la plus élevée l'emporte.

Dans cette topologie :

• Adresse RP N9K-1 = 10.2.0.1
• Adresse RP N9K-2 = 10.2.0.4
• Les deux candidats RP utilisent la priorité 255

Parce que les deux RP-Candidats ont la même priorité :

• L'adresse IP du RP la plus élevée devient le RP sélectionné.

Par conséquent :

• 10.2.0.4 devient le RP actif pour 224.10.20.0/24.

Validation RP sélectionnée

N9K-2 — RP sélectionné

N9K-2# show ip pim rp
<snip>
RP: 10.2.0.4*, (0),
 uptime: 23:14:14   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24

Pourquoi N9K-1 affiche toujours les deux entrées RP

Sur N9K-1 :

N9K-1# show ip pim rp
<snip>
RP: 10.2.0.1*, (0),
RP: 10.2.0.4, (0),

Ce comportement est attendu pour les raisons suivantes :

• N9K-1 fonctionne comme agent de mappage.
• L'agent de mappage conserve la visibilité de tous les candidats RP.
• Le résultat affiche toutes les annonces RP apprises avant la distribution de la sélection RP finale.

Étape 5: Vérifier l'accessibilité aux candidats RP et aux agents de mappage

Tous les routeurs de multidiffusion participant au domaine PIM en mode dispersé doivent maintenir une accessibilité IP stable pour :

• Tous les candidats RP
• Tous les agents de mappage

Cette validation est essentielle car le mode intermédiaire PIM repose sur le routage monodiffusion pour :

• Atteindre le point de rendez-vous (RP)
• Création de l'arborescence de multidiffusion partagée (RPT)
• Remettre des messages d'enregistrement PIM à partir du routeur de premier saut (FHR)
• Recevoir des annonces de découverte Auto-RP
• Valider le transfert par chemin inverse (RPF)

Si l'accessibilité vers le RP ou l'agent de mappage échoue :

• L'enregistrement des sources de multidiffusion peut échouer.
• Les récepteurs peuvent ne pas rejoindre les groupes de multidiffusion.
• Les annonces Auto-RP n'ont pas pu se propager correctement.
• Des défaillances RPF peuvent se produire.
• Le transfert de trafic multidiffusion peut devenir instable ou intermittent.

---

Vérification des entrées de routage stables

La table de routage doit contenir des routes unicast stables vers :

• Toutes les boucles RP
• Toutes les boucles Mapping Agent
• Toutes les interfaces de transit multidiffusion

Les routes doivent rester installées en permanence sans battement de route ni événements de reconvergence excessifs.

Vérifier :

• Correction de la sélection du tronçon suivant
• Interface de sortie correcte
• Temps de disponibilité de route stable
• Source de protocole de routage attendue
• Accessibilité de monodiffusion cohérente dans le domaine de multidiffusion

---

FHR-1 — Route vers RP-Candidate 10.2.0.1

FHR-1# show ip route 10.2.0.1

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.1/32, ubest/mbest: 1/0
    *via 10.4.0.6, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-1 — Route vers RP-Candidate 10.2.0.4

FHR-1# show ip route 10.2.0.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.4/32, ubest/mbest: 1/0
    *via 10.4.0.10, Eth1/1, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-1 — Route vers l'agent de mappage 10.2.1.5

FHR-1# show ip route 10.2.1.5

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.5/32, ubest/mbest: 1/0
    *via 10.4.0.6, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-1 — Route vers l'agent de mappage 10.2.1.4

FHR-1# show ip route 10.2.1.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.4/32, ubest/mbest: 1/0
    *via 10.4.0.10, Eth1/1, [110/5], 1d02h, ospf-UNDERLAY, intra

---

FHR-2 — Route vers RP-Candidate 10.2.0.1

FHR-2# show ip route 10.2.0.1

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.1/32, ubest/mbest: 1/0
    *via 10.4.0.13, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-2 — Route vers RP-Candidate 10.2.0.4

FHR-2# show ip route 10.2.0.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.4/32, ubest/mbest: 1/0
    *via 10.4.0.18, Eth1/4, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-2 — Route vers l'agent de mappage 10.2.1.5

FHR-2# show ip route 10.2.1.5

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.5/32, ubest/mbest: 1/0
    *via 10.4.0.13, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-2 — Route vers l'agent de mappage 10.2.1.4

FHR-2# show ip route 10.2.1.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.4/32, ubest/mbest: 1/0
    *via 10.4.0.18, Eth1/4, [110/5], 1d02h, ospf-UNDERLAY, intra

---

LHR — Route vers RP-Candidate 10.2.0.1

LHR# show ip route 10.2.0.1

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.1/32, ubest/mbest: 1/0
    *via 10.4.0.22, Eth1/49, [110/2], 1d02h, ospf-UNDERLAY, intra

LHR — Route vers RP-Candidate 10.2.0.4

LHR# show ip route 10.2.0.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.4/32, ubest/mbest: 1/0
    *via 10.4.0.26, Eth1/50, [110/2], 1d02h, ospf-UNDERLAY, intra

LHR — Route vers l'agent de mappage 10.2.1.5

LHR# show ip route 10.2.1.5

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.5/32, ubest/mbest: 1/0
    *via 10.4.0.22, Eth1/49, [110/2], 1d02h, ospf-UNDERLAY, intra

LHR — Route vers l'agent de mappage 10.2.1.4

LHR# show ip route 10.2.1.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.4/32, ubest/mbest: 1/0
    *via 10.4.0.26, Eth1/50, [110/2], 1d02h, ospf-UNDERLAY, intra

---

Vérifier l'accessibilité des requêtes ping depuis les interfaces PIM

Après avoir validé la table de routage, vérifiez l’accessibilité IP de bout en bout vers :

• Tous les candidats RP
• Tous les agents de mappage

La requête ping doit provenir de :

• Interfaces compatibles PIM
• Interfaces de bouclage participant au routage multidiffusion

Cette validation est importante, car les routeurs de multidiffusion utilisent ces adresses source pendant :

• établissement PIM voisin
• Calculs RPF
• Encapsulation du registre PIM
• Communication Auto-RP

Récapitulatif de validation ping

Périphérique	Adresse IP source	Destination	Fonction	Résultat
FRH-1	10.4.0.5	10.2.0.1	RP-candidat	Réussi
FRH-1	10.4.0.5	10.2.0.4	RP-candidat	Réussi
FRH-1	10.4.0.5	10.2.1.5	Agent de mappage	Réussi
FRH-1	10.4.0.5	10.2.1.4	Agent de mappage	Réussi
FRH-2	10.4.0.9	10.2.0.1	RP-candidat	Réussi
FRH-2	10.4.0.9	10.2.0.4	RP-candidat	Réussi
FRH-2	10.4.0.9	10.2.1.5	Agent de mappage	Réussi
FRH-2	10.4.0.9	10.2.1.4	Agent de mappage	Réussi
LHR	10.4.0.5	10.2.0.1	RP-candidat	Réussi
LHR	10.4.0.5	10.2.0.4	RP-candidat	Réussi
LHR	10.4.0.5	10.2.1.5	Agent de mappage	Réussi
LHR	10.4.0.5	10.2.1.4	Agent de mappage	Réussi

Vérification de l'état opérationnel et du transfert du trafic multidiffusion sur FHR et LHR

La prochaine étape de validation consiste à vérifier que :

• Le FHR et le LHR ont appris le RP attendu avec succès.
• La table de routage de multidiffusion contient les états de multidiffusion attendus.
• Le plan de contrôle de multidiffusion fonctionne correctement avant le début de la transmission du trafic de multidiffusion.
• Le mode intermédiaire PIM crée l'état d'arborescence partagée attendu.

---

Étape 1 - Vérifiez l’apprentissage RP sur les ressources FHR et LHR

Avant de valider l'état de transfert multidiffusion, vérifiez que tous les routeurs multidiffusion ont appris le RP attendu pour le groupe multidiffusion en cours de validation.

Cette étape est essentielle car :

• Le FHR doit savoir où envoyer les messages du registre PIM.
• Le LHR doit savoir quel RP utiliser lors de la création de l'arborescence partagée.
• Le domaine de multidiffusion doit maintenir un mappage RP cohérent.

Dans cette topologie :

• Le RP sélectionné est 10.2.0.4.
• Mapping Agent est 10.2.1.5.
• La plage du groupe de multidiffusion est 224.10.20.0/24.

---

FHR-1 — Vérifier le RP appris

FHR-1# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5, uptime: 1d02h, expires: 00:02:30
BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

RP: 10.2.0.4, (0),
 uptime: 1d03h   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:02:30 (A)

FHR-2 — Vérifier le RP appris

FHR-2# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5, uptime: 1d02h, expires: 00:02:15
BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

RP: 10.2.0.4, (0),
 uptime: 1d03h   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:02:15 (A)

LHR — Vérifier le RP appris

LHR# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5, uptime: 1d02h, expires: 00:02:07
BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

RP: 10.2.0.4, (0),
 uptime: 1d03h   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:02:07 (A)

---

Analyse d'apprentissage RP

Les résultats confirment que :

• Tous les routeurs de multidiffusion ont appris le même RP de manière cohérente.
• Le RP sélectionné est 10.2.0.4.
• Le mappage RP a été appris via Auto-RP.
• L'agent de mappage qui distribue les informations RP est 10.2.1.5.
• Le mappage RP reste stable pendant plus d'une journée.
• Les minuteurs d'expiration de la détection sont actualisés correctement.

Ce comportement est attendu pour les raisons suivantes :

• 10.2.0.4 a été sélectionné comme RP actif lors du processus de sélection du RP automatique.
• 10.2.1.5 fonctionne en tant qu'agent de mappage.
• Tous les routeurs de multidiffusion reçoivent avec succès des annonces de découverte Auto-RP.

À ce stade, le plan de contrôle de multidiffusion fonctionne correctement et tous les routeurs ont un mappage RP cohérent pour 224.10.20.0/24

---

Étape 2 - Vérifiez l’état du routage multidiffusion avant le trafic multidiffusion actif

L’étape suivante consiste à valider la table de routage multidiffusion avant le début de la transmission du trafic multidiffusion.

Dans ce scénario :

• Le récepteur multidiffusion a déjà rejoint le groupe multidiffusion.
• Aucun trafic source de multidiffusion actif ne circule encore.

Cet état est important car il valide :

• opération d'adhésion IGMP
• Création d'une arborescence partagée PIM
• État de multidiffusion initial (*, G)
• Propagation des intérêts du récepteur

FHR-1 — Table de routage multidiffusion

FHR-1# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 232.0.0.0/8), uptime: 23:07:34, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

FHR-2 — Table de routage multidiffusion

FHR-2# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 232.0.0.0/8), uptime: 23:07:37, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

---

Analyse d'état multidiffusion FHR

Les FHR ne contiennent pas encore :

• (*, G) pour 224.10.20.10
• État (S, G) de la source de multidiffusion

Ce comportement est attendu pour les raisons suivantes :

• Aucun trafic source de multidiffusion n'est encore actif.
• Aucun message du registre PIM n'a été généré.
• Le FHR n'a pas démarré le transfert multidiffusion.

La seule entrée de multidiffusion présente est :

• 232.0.0.0/8

Cela correspond à la plage SSM par défaut et est automatiquement installé par le système.

Ces valeurs sont attendues :

• Interface entrante : Null
• Voisin RPF : 0.0.0.0
• Nombre d'interfaces sortantes : 0

Cette entrée n'indique pas le transfert de multidiffusion actif.

---

LHR — Table de routage multidiffusion

LHR# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 224.10.20.10/32), uptime: 23:07:39, igmp ip pim
  Incoming interface: Ethernet1/50, RPF nbr: 10.4.0.26
  Outgoing interface list: (count: 1)
    Vlan2, uptime: 23:07:39, igmp

(*, 232.0.0.0/8), uptime: 23:07:39, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

Analyse d'état multidiffusion LHR

Contrairement aux FHR, le LHR contient une entrée active (*, G) pour :

• 224.10.20.10

Ce comportement est attendu pour les raisons suivantes :

• Le récepteur de multidiffusion a déjà rejoint le groupe.
• Les informations d'appartenance IGMP ont été apprises sur Vlan2.
• Le LHR a initié la jonction d'arbre partagé vers le RP.

La table de routage de multidiffusion confirme :

• L'interface d'entrée (IIF) est Ethernet1/50.
• Le voisin RPF est 10.4.0.26.
• La liste des interfaces sortantes (OIL) contient Vlan2.

Cela indique que :

• Le LHR a correctement construit l'arborescence partagée vers le RP.
• L'intérêt du récepteur de multidiffusion s'est propagé correctement en amont.
• Les messages de jointure PIM ont été transmis correctement.

À ce stade :

• Aucun trafic source de multidiffusion n'est encore actif.
• Aucun état (S, G) n'existe encore.
• Seul l'état d'arborescence partagée existe.

---

N9K-1 — Table de routage de multidiffusion de l'agent de mappage

N9K-1# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 232.0.0.0/8), uptime: 1d03h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

Mapping Agent Multicast State Analysis

N9K-1 fonctionne uniquement en tant qu'agent de mappage et ne participe pas au transfert multidiffusion pour 224.10.20.10

Par conséquent, l'absence d'entrées (*, G) et d'entrées (S, G) est attendue.

L'agent de mappage distribue uniquement les informations de mappage RP et ne participe pas nécessairement au transfert de données de multidiffusion à moins que le trafic de multidiffusion ne traverse directement le périphérique.

---

N9K-2 — Table de routage de multidiffusion RP

N9K-2# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 224.10.20.10/32), uptime: 1d01h, pim ip
  Incoming interface: loopback0, RPF nbr: 10.2.0.4
  Outgoing interface list: (count: 1)
    Ethernet1/49, uptime: 1d01h, pim

(*, 232.0.0.0/8), uptime: 1d03h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

Analyse d'état de multidiffusion RP

N9K-2 fonctionne comme RP actif pour :

• 224.10.20.0/24

Par conséquent, le RP contient l'état d'arborescence partagée (*, G) pour 224.10.20.10

Ces valeurs sont attendues :

• Interface entrante = loopback0
• RPF neighbor = 10.2.0.4
• Interface sortante = Ethernet1/49

Cela indique que :

• Le RP a correctement installé l'état d'arborescence partagée.
• Le RP a reçu des messages PIM Join des routeurs en aval.
• L'arborescence de multidiffusion partagée vers les récepteurs a été créée correctement.

À ce stade :

• Le RP contient uniquement l'état d'arborescence partagée.
• Aucun trafic source de multidiffusion n'est encore actif.
• Aucune entrée (S, G) n'existe encore.

---

Étape 3 - Vérifiez L’État Du Routage Multidiffusion Avec Le Trafic Multidiffusion Actif

Une fois que la transmission du trafic multidiffusion commence, la table de routage multidiffusion passe de l'état d'arborescence partagée à l'état de transfert spécifique à la source active.

Dans ce scénario :

• La source de multidiffusion est 10.150.1.37.
• Le groupe de multidiffusion est 224.10.20.10.
• Le RP actif est 10.2.0.4 sur N9K-2.
• La source de multidiffusion se connecte via le port-channel 78 vPC.

---

Considérations importantes sur la multidiffusion vPC

La source de multidiffusion se connecte via un domaine vPC formé par FHR-1 et FHR-2.

Parce que la source se connecte via un canal de port membre vPC :

• Le hachage du trafic peut transférer des paquets de multidiffusion vers l'un des commutateurs Nexus.
• Les deux FHR nécessitent une configuration de multidiffusion identique.
• Les deux FHR nécessitent des informations de routage de monodiffusion cohérentes.
• Les deux FHR doivent maintenir des mappages RP identiques.
• Les deux FHR doivent maintenir des contiguïtés PIM stables.

Dans ce scénario spécifique :

• Le flux de multidiffusion hache vers FHR-2.
• FHR-2 devient le FHR de transfert actif pour la source de multidiffusion.

FHR-1 — Table de routage multidiffusion

FHR-1# show ip mroute

IP Multicast Routing Table for VRF "default"

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:03:58, ip pim
  Incoming interface: Vlan1, RPF nbr: 10.150.1.37
  Outgoing interface list: (count: 0)

(*, 232.0.0.0/8), uptime: 1d00h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

FHR-1 — Rôle vPC

FHR-1# show vpc role

vPC Role status
----------------------------------------------------
vPC role                        : primary <<<
Dual Active Detection Status    : 0
vPC system-mac                  : 00:23:04:ee:be:01
vPC system-priority             : 32667
vPC local system-mac            : 00:6b:f1:84:02:97
vPC local role-priority         : 32667
vPC local config role-priority  : 32667
vPC peer system-mac             : 6c:b2:ae:ee:5a:97
vPC peer role-priority          : 32667
vPC peer config role-priority   : 32667

Analyse d'état de multidiffusion FHR-1

FHR-1 contient une entrée active (S, G) pour :

• Source = 10.150.1.37
• Groupe = 224.10.20.10

L'entrée de routage multidiffusion confirme :

• La source a été apprise sur Vlan1.
• Le voisin RPF est la source de multidiffusion connectée directement.
• Il n'existe aucune interface sortante dans l'OIL.

Ce comportement est attendu, car le flux de multidiffusion n'a pas effectué de hachage vers FHR-1 pour le transfert sortant.

En conséquence :

• FHR-1 installe l'état source local uniquement.
• FHR-1 ne transfère pas le trafic de multidiffusion en amont via PIM.

FHR-2 — Table de routage multidiffusion

FHR-2# show ip mroute

IP Multicast Routing Table for VRF "default"

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:16:35, ip pim
  Incoming interface: Vlan1, RPF nbr: 10.150.1.37
  Outgoing interface list: (count: 1)
    Ethernet1/3, uptime: 00:16:35, pim

(*, 232.0.0.0/8), uptime: 1d00h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

FHR-2 — Rôle vPC

FHR-2# show vpc role

vPC Role status
----------------------------------------------------
vPC role                        : secondary <<<
Dual Active Detection Status    : 0
vPC system-mac                  : 00:23:04:ee:be:01
vPC system-priority             : 32667
vPC local system-mac            : 6c:b2:ae:ee:5a:97
vPC local role-priority         : 32667
vPC local config role-priority  : 32667
vPC peer system-mac             : 00:6b:f1:84:02:97
vPC peer role-priority          : 32667
vPC peer config role-priority   : 32667

Analyse d'état de multidiffusion FHR-2

Contrairement à FHR-1, FHR-2 contient :

• Une liste d’interfaces sortantes actives
• Un chemin de transfert PIM actif

Cela indique que :

• FHR-2 est devenu le FHR de transfert opérationnel pour le flux de multidiffusion.
• Les paquets de multidiffusion ont été hachés vers FHR-2 via le canal de port membre vPC.
• FHR-2 a encapsulé le trafic de multidiffusion dans des messages de registre PIM.
• FHR-2 a transféré le trafic de multidiffusion en amont vers le RP.

Comportement de transfert ECMP et multidiffusion

L’interface sortante Ethernet1/3 fait correspondre la table de routage de monodiffusion vers le récepteur 192.168.2.37

FHR-2 — Route vers le récepteur multidiffusion

FHR-2# show ip route 192.168.2.37

IP Route Table for VRF "default"

'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.168.2.0/24, ubest/mbest: 2/0
    *via 10.4.0.13, Eth1/3, [110/45], 1d02h, ospf-UNDERLAY, intra
    *via 10.4.0.18, Eth1/4, [110/45], 1d02h, ospf-UNDERLAY, intra

FHR-2 contient deux routes à coût égal vers le sous-réseau du récepteur de multidiffusion :

• 10.4.0.13 via Ethernet1/3
• 10.4.0.18 via Ethernet1/4

Cela confirme que :

• Le routage ECMP est actif dans la topologie de transport multidiffusion.
• Il existe plusieurs chemins de transmission de monodiffusion valides vers le réseau récepteur.
• PIM peut utiliser le chemin RPF sélectionné par la MRIB pour les décisions de transfert multidiffusion.
• La duplication de paquets sur les chemins ECMP parallèles n'a pas lieu.

Bien qu'il existe deux routes à coût égal, le transfert multidiffusion utilise un chemin RPF unique pour chaque flux multidiffusion.

Dans cette topologie, le flux de multidiffusion utilise :

• Ethernet1/3 vers 10.4.0.13

Ce comportement correspond à la table de routage de multidiffusion précédemment observée :

(10.150.1.37/32, 224.10.20.10/32)
  Outgoing interface list:
    Ethernet1/3

---

Comportement principal et secondaire opérationnel du vPC

Les rôles opérationnels vPC influencent différemment le comportement de transfert multidiffusion pour :

• trafic PIM
• traitement IGMP

Dans cette topologie :

• FHR-1 est le principal vPC opérationnel.
• FHR-2 est le vPC secondaire opérationnel.

Les deux commutateurs Nexus peuvent :

• Traiter le trafic du plan de contrôle PIM
• Construire l'état de routage multidiffusion
• Transférer le trafic de multidiffusion via PIM

Cependant:

• Seul le vPC principal opérationnel traite le trafic du récepteur IGMP vers la couche d'accès.

Cette distinction est importante car :

• Le transfert PIM vers le réseau routé reste actif sur les deux homologues.
• Le transfert IGMP vers les segments récepteurs de couche 2 reste centralisé sur le principal opérationnel.

Par conséquent :

• Le trafic de multidiffusion de la source vers le domaine de multidiffusion routé peut sortir par l'un des homologues vPC.
• Le trafic multidiffusion vers les récepteurs IGMP dépend du comportement opérationnel principal.

---

LHR — Table de routage multidiffusion

LHR# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 224.10.20.10/32), uptime: 1d00h, igmp ip pim
  Incoming interface: Ethernet1/50, RPF nbr: 10.4.0.26
  Outgoing interface list: (count: 1)
    Vlan2, uptime: 1d00h, igmp

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:06:31, ip mrib pim
  Incoming interface: Ethernet1/49, RPF nbr: 10.4.0.22
  Outgoing interface list: (count: 1)
    Vlan2, uptime: 00:06:31, mrib

(*, 232.0.0.0/8), uptime: 1d00h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

Analyse d'état multidiffusion LHR

Le LHR contient désormais les deux éléments suivants :

• (* ,G) état de l'arborescence partagée
• (S, G) état de l'arborescence source

Cela confirme :

• Le récepteur de multidiffusion a été joint.
• La source de multidiffusion est devenue active.
• Le LHR est passé du transfert d'arborescence partagée au transfert d'arborescence source.

L'entrée (S, G) confirme :

• Le chemin source de multidiffusion a été correctement appris.
• Le voisin RPF est 10.4.0.2.
• Le trafic de multidiffusion arrive via Ethernet1/49.
• Le trafic de multidiffusion est transféré vers les récepteurs Vlan2.

Ce comportement confirme la réussite :

• Transfert PIM
• Validation RPF
• Construction de l'arbre source
• Livraison de trafic multidiffusion

---

N9K-1 — Table de routage de multidiffusion de transit

N9K-1# show ip mroute

IP Multicast Routing Table for VRF "default"

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:06:42, pim ip
  Incoming interface: Ethernet1/4, RPF nbr: 10.4.0.14
  Outgoing interface list: (count: 1)
    Ethernet1/49, uptime: 00:06:42, pim

(*, 232.0.0.0/8), uptime: 1d04h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

N9K-1 Analyse de l'état de transit

N9K-1 fonctionne comme un routeur de multidiffusion de transit pour le flux de multidiffusion actif.

L'entrée de routage multidiffusion confirme :

• Le trafic de multidiffusion provient d’Ethernet1/4.
• Le trafic de multidiffusion est acheminé vers Ethernet1/49.
• Le chemin de transfert multidiffusion vers le LHR est opérationnel.

Ceci confirme la réussite :

• Opération de voisinage PIM
• Validation RPF
• Transfert multidiffusion sur le réseau de transit

---

N9K-2 — Table de routage de multidiffusion RP

N9K-2# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 224.10.20.10/32), uptime: 1d02h, pim ip
  Incoming interface: loopback0, RPF nbr: 10.2.0.4
  Outgoing interface list: (count: 1)
    Ethernet1/49, uptime: 1d02h, pim

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:06:50, ip pim mrib
  Incoming interface: Ethernet1/4, RPF nbr: 10.4.0.17, internal
  Outgoing interface list: (count: 0)

(*, 232.0.0.0/8), uptime: 1d04h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

Analyse d'état de multidiffusion RP

N9K-2 fonctionne comme RP actif pour le groupe de multidiffusion.

Le RP contient les deux éléments suivants :

• (* ,G) état de l'arborescence partagée
• (S, G) état de l'arborescence source

L'absence d'interfaces sortantes dans l'entrée (S, G) est attendue pour les raisons suivantes :

• Le RP a déjà commuté les récepteurs vers l'arborescence du plus court chemin.
• Le chemin de transfert de l'arborescence partagée n'est plus nécessaire pour le transfert multidiffusion actif.

Informations de multidiffusion minimales requises pour les diagnostics RCA et d'intégrité

La liste des commandes fournit la collecte de données multicast minimale recommandée requise pour effectuer une analyse de la cause première (RCA) ou un diagnostic d'intégrité multicast sur les commutateurs Cisco Nexus 9000 exécutant NX-OS. Ces sorties capturent l'état du plan de contrôle de multidiffusion, la programmation MRIB, les informations de transfert, l'état opérationnel vPC et les détails de transfert matériel. Cependant, des informations supplémentaires peuvent toujours être requises selon le scénario de défaillance. Par exemple, la perte de paquets de multidiffusion, les abandons de trafic intermittents, les problèmes de réplication de paquets, les incohérences de transfert matériel ou le transfert de multidiffusion désordonné nécessitent souvent des captures directes de paquets sur le commutateur Nexus à l'aide d'Ethanalyzer, de la fonctionnalité SPAN ou de captures au niveau matériel. De même, des incohérences RPF passagères, des modifications de transfert ECMP, des échecs de programmation ASIC ou des événements de suppression IGMP peuvent se produire sans génération de journal persistante.

Par conséquent, la combinaison des résultats de la commande show tech avec les captures de paquets et la validation du transfert améliore considérablement la précision du diagnostic et la qualité RCA. Bien que ces informations fournissent une base opérationnelle solide pour le dépannage de la multidiffusion, elles ne garantissent pas qu'une RCA puisse toujours être identifiée exclusivement à partir de ces sorties. Certaines pannes de multidiffusion nécessitent un dépannage supplémentaire, une analyse du trafic en direct, une validation au niveau du matériel, une corrélation de topologie ou des captures de paquets étendues pour isoler la cause racine exacte.

Commandes de collecte de données de multidiffusion minimales

N9K-1# show tech-support multicast >> bootflash:$(SWITCHNAME)-sh-tech-multicast.txt

N9K-1# show tech-support details >> bootflash:$(SWITCHNAME)-sh-tech-det.txt

N9K-1# show tech-support vpc >> bootflash:$(SWITCHNAME)-sh-tech-vpc.txt

N9K-1# show tech-support forwarding multicast >> bootflash:$(SWITCHNAME)-sh-tech-fwd-multicast.txt

N9K-1# show tech-support forwarding l3 multicast detail vdc-all >> bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-multicast.txt

N9K-1# show tech-support forwarding l3 unicast detail vdc-all >> bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-unicast-det.txt

Créer une archive TAR pour l'exportation

Après avoir généré les fichiers show tech, consolidez-les dans une seule archive TAR pour les exporter et les analyser. La commande est une ligne unique.

N9K-1# tar create bootflash:$(SWITCHNAME)-multicast-logs
bootflash:$(SWITCHNAME)-sh-tech-multicast.txt
bootflash:$(SWITCHNAME)-sh-tech-det.txt
bootflash:$(SWITCHNAME)-sh-tech-vpc.txt
bootflash:$(SWITCHNAME)-sh-tech-fwd-multicast.txt
bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-multicast.txt
bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-unicast-det.txt

L'exportation d'une seule archive TAR simplifie :

• Téléchargements de dossiers TAC
• Workflows RCA
• Analyse centralisée des journaux
• Corrélation de transfert multidiffusion
• Conservation des défaillances historiques

Historique de révision

Révision	Date de publication	Commentaires
1.0	13-May-2026	Première publication