Configurer la multidiffusion de couche 2 dans l'ACI
Contenu
Introduction
Ce document décrit comment configurer et vérifier la multidiffusion de couche 2 (L2) dans le même groupe de terminaux (EPG) sur un fabric ACI (Application Centric Infrastructure) unique.
Conditions préalables
Conditions requises
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- Prise en charge de la multidiffusion de couche 2 dans l'ACI - toujours prise en charge
- Surveillance IGMP (Internet Group Management Protocol) dans ACI - activée par défaut
Components Used
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
- N9K-C93180YC-FX
- Version 4.2(7q)
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.
Informations générales
La multidiffusion de couche 2 désigne les paquets de multidiffusion IP transmis sur un segment de réseau de couche 2 (domaine de pont (BD)/sous-réseau), et non les paquets de multidiffusion de couche 2 qui sont des paquets de multidiffusion avec une adresse MAC de multidiffusion de destination sans en-tête IP. La multidiffusion de couche 2 exclut également la multidiffusion link-local (224.0.0.0/24). La multidiffusion locale de liaison est toujours transmise à tous les ports du BD.
La multidiffusion de couche 2 dans l'ACI n'est transmise que dans le BD. Si vous avez plusieurs groupes de terminaux qui utilisent le même BD, le trafic de multidiffusion inonde tous les groupes de terminaux indépendamment des contrats en place entre les groupes de terminaux.
L'ACI Cisco transmet les trames de multidiffusion sur l'arborescence multicast de superposition qui est construite entre les commutateurs leaf et spine. Le trafic de couche 2 utilise des arborescences FTAG (Forwarding Tag) pour fournir un équilibrage de charge efficace sur plusieurs liaisons redondantes de même coût. Pour plus d'informations sur les détails de l'arborescence FTAG, consultez le document Fondamentaux ACI.
Configuration
Topologie du réseau
Configurations
Voici un résumé des étapes de configuration. Il n'y a pas beaucoup de configuration pour la multidiffusion de couche 2 sauf pour activer un interrogateur IGMP.
- Étape 1 : Configurer les stratégies d'accès au fabric pour la connectivité du serveur multidiffusion et de l'hôte client
- Étape 2 : Créez l'EPG, le BD et le VRF pour le récepteur et la source de multidiffusion
- Étape 3 : Fixer un domaine physique au groupe de terminaux et configurer le port statique
- Étape 4 : Configurer le serveur de requêtes IGMP
Cette section décrit les étapes de configuration détaillées.
Étape 1 : Configurer les stratégies d'accès au fabric pour la connectivité du serveur multidiffusion et de l'hôte client
Les images montrent l'approche de haut niveau de la configuration. Des détails supplémentaires sur les politiques d'accès sont disponibles dans le document ACI Initial Deployment.
Vous pouvez ignorer cette étape si les stratégies d'accès sont déjà en place.
- Cette image montre les stratégies de matrice de ports du serveur de multidiffusion.
- Cette image montre les stratégies de fabric du port du récepteur de multidiffusion (client).
Étape 2 : Créez l'EPG, le BD et le VRF pour le récepteur et la source de multidiffusion
- Les EPG, BD et VRF sont créés avec les paramètres par défaut.
Par défaut, un BD utilise la stratégie IGMP Snoop par défaut prédéfinie dans le service partagé.
Le demandeur IGMP n'est pas activé par défaut sous le sous-réseau BD, ce qui est également le cas pour un déploiement NXOS ou Cisco IOS® hérité.
- Afin de vérifier la stratégie IGMP Snoop par défaut, choisissez le 'locataire commun > Politiques > Protocole > IGMP Snoop > default pour voir que la case Activer le demandeur n'est pas activée pour la stratégie IGMP par défaut.
- Cette image présente le résumé de la configuration EPG, BD et VRF (vue logique).
Étape 3 : Fixer un domaine physique au groupe de terminaux et configurer le port statique
- Cette image montre un domaine physique attaché à un EPG.
- Cette image montre un port statique configuré sous un EPG.
- Cette image montre que les points d'extrémité du serveur de multidiffusion (source) et du client de multidiffusion (récepteur) sont tous deux acquis (connectés) sous le même EPG.
Étape 4 : Configurer la file d'attente IGMP
Le demandeur IGMP doit être activé à deux endroits, sous la stratégie IGMP Snoop respective et sous le sous-réseau BD.
Note: Étant donné que la stratégie de surveillance IGMP avec Enable querier activé nécessite une adresse IP source pour envoyer la requête IGMP, il est nécessaire de configurer l'activation de l'IP IGMP Querier sous le sous-réseau BD. Sinon, le commutateur leaf n'enverra pas la requête IGMP au récepteur de multidiffusion.
Il est toujours recommandé de configurer une nouvelle stratégie IGMP Snooping avec le demandeur IGMP activé au lieu d'utiliser une stratégie IGMP Snooping par défaut. Notez que la stratégie de surveillance IGMP par défaut n'a pas de demandeur IGMP activé par défaut et qu'elle est associée par défaut à chaque BD. Une modification de toute configuration sous la stratégie de surveillance IGMP par défaut affecte chaque BD associé à la stratégie de surveillance IGMP par défaut. Il n'est donc pas recommandé de modifier les paramètres de stratégie de surveillance IGMP par défaut dans l'ACI.
- Afin de créer une nouvelle stratégie de surveillance IGMP, choisissez le locataire TN_D > Politiques > Protocoles, puis cliquez avec le bouton droit sur IGMP Snoop et cliquez sur Créer une stratégie de surveillance IGMP.
- Pour la nouvelle stratégie de surveillance IGMP ('TN_D_IGMP_snooping_POL'), cochez la case Activer le demandeur, puis cliquez sur Envoyer.
Note: Le paramètre Enable querier n'est requis que si le sous-réseau BD est configuré avec Querier IP. Si le demandeur IGMP se trouve en dehors de l'ACI, cette configuration n'est pas requise.
- Afin de joindre la nouvelle stratégie IGMP à la BD, choisissez TN_D > Networking > Bridge Domain > 'L2_Mcast_BD' et choisissez la nouvelle stratégie IGMP Snoop dans la liste déroulante IGMP Snoop Policy. Cliquez sur Soumettre afin d'appliquer les modifications.
- Afin d'activer le demandeur IGMP pour le sous-réseau BD, sélectionnez le sous-réseau et cochez la case Querier IP.
lf101# show ip igmp snooping querier Vlan IP Address Version Expires Port 21 10.100.0.254 v3 00:01:06 Switch querier
lf102# show ip igmp snooping querier Vlan IP Address Version Expires Port 19 10.100.0.254 v3 00:01:46 Switch querier
Vérification
Référez-vous à cette section pour vous assurer du bon fonctionnement de votre configuration.
Ceci MO query montre que la stratégie de messagerie IGMP a le moteur de requête activé.
apic1# moquery -d uni/tn-TN_D/snPol-TN_D_IGMP_snooping_POL Total Objects shown: 1 # igmp.SnoopPol name : TN_D_IGMP_snooping_POL adminSt : enabled annotation : childAction : ctrl : querier descr : dn : uni/tn-TN_D/snPol-TN_D_IGMP_snooping_POL extMngdBy : lastMbrIntvl : 1 lcOwn : local modTs : 2022-01-26T19:32:18.660+00:00 nameAlias : ownerKey : ownerTag : queryIntvl : 125 rn : snPol-TN_D_IGMP_snooping_POL rspIntvl : 10 startQueryCnt : 2 startQueryIntvl : 31 status : uid : 15374
Ceci MO query montre que le demandeur IGMP est également activé sur le sous-réseau BD.
apic1# moquery -c fvSubnet -f 'fv.Subnet.ip=="10.100.0.254/24"'
Total Objects shown: 1
# fv.Subnet
ip : 10.100.0.254/24
annotation :
childAction :
ctrl : querier <<
descr :
dn : uni/tn-TN_D/BD-L2_Mcast_BD/subnet-[10.100.0.254/24] extMngdBy : lcOwn : local modTs : 2021-12-28T19:28:54.860+00:00 monPolDn : uni/tn-common/monepg-default name : nameAlias : preferred : no
rn : subnet-[10.100.0.254/24] scope : private status : uid : 15374 virtual : no
Ceci MO query affiche la vérification de la configuration BD.
apic1# moquery -c fvBD -f "fv.BD.name==\"L2_Mcast_BD\"" Total Objects shown: 1 # fv.BD name : L2_Mcast_BD OptimizeWanBandwidth : no annotation : arpFlood : yes bcastP : 225.1.156.240 childAction : configIssues : descr : dn : uni/tn-TN_D/BD-L2_Mcast_BD epClear : no epMoveDetectMode : extMngdBy : hostBasedRouting : no intersiteBumTrafficAllow : no intersiteL2Stretch : no ipLearning : yes ipv6McastAllow : no lcOwn : local limitIpLearnToSubnets : yes llAddr : :: mac : 00:22:BD:F8:19:FF mcastAllow : no modTs : 2021-12-25T23:47:57.717+00:00 monPolDn : uni/tn-common/monepg-default mtu : inherit multiDstPktAct : bd-flood nameAlias : ownerKey : ownerTag : pcTag : 49154 rn : BD-L2_Mcast_BD scope : 2490368 seg : 16351140 status : type : regular uid : 15374 unicastRoute : yes unkMacUcastAct : proxy unkMcastAct : flood v6unkMcastAct : flood vmac : not-applicable
Ce résultat montre la vérification que leaf-101 est connecté à la source de multidiffusion 10.100.0.10.
lf101# show endpoint ip 10.100.0.10 detail
Legend:
s - arp H - vtep V - vpc-attached p - peer-aged
R - peer-attached-rl B - bounce S - static M - span
D - bounce-to-proxy O - peer-attached a - local-aged m - svc-mgr
L - local E - shared-service
+-----------------------------------+---------------+-----------------+--------------+-------------+------------------------------+
VLAN/ Encap MAC Address MAC Info/ Interface Endpoint Group
Domain VLAN IP Address IP Info Info
+-----------------------------------+---------------+-----------------+--------------+-------------+------------------------------+
20 vlan-1900 0011.0100.0001 L eth1/47 TN_D:Multicast_Servers:L2_Mcast_EPG
TN_D:VRF_A vlan-1900 10.100.0.10 L eth1/47
Ce résultat montre la vérification que leaf-102 est connecté au récepteur de multidiffusion 10.100.0.20.
lf102# show endpoint ip 10.100.0.20 detail
Legend:
s - arp H - vtep V - vpc-attached p - peer-aged
R - peer-attached-rl B - bounce S - static M - span
D - bounce-to-proxy O - peer-attached a - local-aged m - svc-mgr
L - local E - shared-service
+-----------------------------------+---------------+-----------------+--------------+-------------+------------------------------+
VLAN/ Encap MAC Address MAC Info/ Interface Endpoint Group
Domain VLAN IP Address IP Info Info
+-----------------------------------+---------------+-----------------+--------------+-------------+------------------------------+
17 vlan-1900 0011.0200.0001 L eth1/47 TN_D:Multicast_Servers:L2_Mcast_EPG
TN_D:VRF_A vlan-1900 10.100.0.20 L eth1/47
Explication du flux de paquets multicast de couche 2
- Leaf-101 reçoit le paquet de multidiffusion de la source de multidiffusion.
- Cette image montre EPG pcTag :
- Vous pouvez utiliser le module ELAM (Embedded Logic Analyzer Module), un outil de capture intégré, pour capturer le paquet entrant. Cette sortie montre la capture et la sortie ELAM leaf-101. La syntaxe ELAM dépend du type de matériel. Au cours de ces travaux pratiques, la sortie ELAM provient d’un commutateur FX. Une autre approche consiste à utiliser l'application ELAM Assistant.
lf101# vsh_lc
module-1# debug platform internal roc elam asic 0
module-1(DBG-elam)# trigger reset
module-1(DBG-elam)# trigger init in-select 6 out-select 0
module-1(DBG-elam-insel6)# set outer ipv4 src_ip 10.100.0.10 dst_ip 239.100.0.10
module-1(DBG-elam-insel6)# start
module-1(DBG-elam-insel6)# status
ELAM STATUS
===========
Asic 0 Slice 0 Status Triggered
module-1(DBG-elam-insel6)#
module-1(DBG-elam-insel6)# ereport
Python available. Continue ELAM decode with LC Pkg
ELAM REPORT
<snip..>
======================================================================================================================================================
Captured Packet
======================================================================================================================================================
------------------------------------------------------------------------------------------------------------------------------------------------------
Outer Packet Attributes
------------------------------------------------------------------------------------------------------------------------------------------------------
Outer Packet Attributes : l2mc ipv4 ip ipmc ipv4mc udp
Opcode : OPCODE_L3MC
------------------------------------------------------------------------------------------------------------------------------------------------------
Outer L2 Header
------------------------------------------------------------------------------------------------------------------------------------------------------
Destination MAC : 0100.5E64.000A <<
802.1Q tag is valid : no( 0x0 ) CoS : 0( 0x0 ) Access Encap VLAN : 0( 0x0 ) ------------------------------------------------------------------------------------------------------------------------------------------------------ Outer L3 Header ------------------------------------------------------------------------------------------------------------------------------------------------------ L3 Type : IPv4 IP Version : 4 DSCP : 0 IP Packet Length : 1362 ( = IP header(28 bytes) + IP payload ) Don't Fragment Bit : not set TTL : 64 IP Protocol Number : UDP IP CheckSum : 31679( 0x7BBF )
Destination IP : 239.100.0.10 <<
<snip...> ------------------------------------------------------------------------------------------------------------------------------------------------------ Sideband SB Multicast Information ------------------------------------------------------------------------------------------------------------------------------------------------------ BD : 11266( 0x2C02 ) Source is l3 interface : no
FTAG : 4( 0x4 ) <<< FTAG value 4 assigned by lf101 <snip..>
- Une fois que leaf-101 reçoit ce trafic, il est encapsulé vers une adresse externe du groupe BD (GIPO) et une valeur FTAG, et envoyé à Spine pour la recherche de la colonne vertébrale. Cette image montre l'adresse BD GIPO 225.1.156.240.
Les ID FTAG sont attribués en fonction de l'algorithme de hachage de charge utile (0 à 12). La valeur FTAG est imprévisible et pas la même valeur même si le noeud leaf et le BD GiPO de destination sont identiques.
Le binaire de 225.1.156.140 = 11100001.0000001.1001100.11111000
Les 4 derniers bits de la dernière valeur octale du GIPO de destination sont '0000', de sorte que les 4 derniers bits (entre 0 et 12) sont ajoutés à la valeur FTAG.
Ce résultat montre la liste des routes GIPO et de l'interface de sortie (OIF).
lf101# show isis internal mcast routes gipo
IS-IS process: isis_infra
VRF : default
GIPo Routes
====================================
System GIPo - Configured: 0.0.0.0
Operational: 239.255.255.240
====================================
GIPo: 225.0.0.0 [LOCAL]
OIF List:
Ethernet1/49.14
GIPo: 225.0.73.208 [TRANSIT]
OIF List:
GIPo: 225.1.110.160 [LOCAL]
OIF List:
Ethernet1/49.14
GIPo: 225.1.149.64 [LOCAL]
OIF List:
Ethernet1/49.14
GIPo: 225.1.156.240 [LOCAL]
OIF List:
Ethernet1/49.14
GIPo: 225.1.179.176 [TRANSIT]
OIF List:
GIPo: 225.1.192.0 [TRANSIT]
OIF List:
GIPo: 239.255.255.224 [LOCAL]
OIF List:
Ethernet1/49.14
GIPo: 239.255.255.240 [LOCAL]
OIF List:
Ethernet1/49.14
Ce résultat montre la valeur FTAG et la liste OIF.
lf101# show isis internal mcast routes ftag
IS-IS process: isis_infra
VRF : default
FTAG Routes
====================================
System ftag order: NEW
Phantom Spine Capable: NO
FTAG ID: 0 [Enabled] Cost:( 1/ 13/ 0)
----------------------------------
Root port: Ethernet1/49.14
OIF List:
FTAG ID: 1 [Enabled] Cost:( 1/ 1/ 0)
----------------------------------
Root port: Ethernet1/49.14
OIF List:
FTAG ID: 2 [Enabled] Cost:( 1/ 2/ 0)
----------------------------------
Root port: Ethernet1/49.14
OIF List:
FTAG ID: 3 [Enabled] Cost:( 1/ 3/ 0)
----------------------------------
Root port: Ethernet1/49.14
OIF List:
FTAG ID: 4 [Enabled] Cost:( 1/ 4/ 0)
----------------------------------
Root port: Ethernet1/49.14
OIF List:
FTAG ID: 5 [Enabled] Cost:( 1/ 5/ 0)
----------------------------------
Root port: Ethernet1/49.14
OIF List:
FTAG ID: 6 [Enabled] Cost:( 1/ 6/ 0)
----------------------------------
Root port: Ethernet1/49.14
OIF List:
FTAG ID: 7 [Enabled] Cost:( 1/ 7/ 0)
----------------------------------
Root port: Ethernet1/49.14
OIF List:
FTAG ID: 8 [Enabled] Cost:( 1/ 8/ 0)
----------------------------------
Root port: Ethernet1/49.14
OIF List:
FTAG ID: 9 [Enabled] Cost:( 1/ 9/ 0)
----------------------------------
Root port: Ethernet1/49.14
OIF List:
FTAG ID: 10 [Enabled] Cost:( 1/ 10/ 0)
----------------------------------
Root port: Ethernet1/49.14
OIF List:
FTAG ID: 11 [Enabled] Cost:( 1/ 11/ 0)
----------------------------------
Root port: Ethernet1/49.14
OIF List:
FTAG ID: 12 [Enabled] Cost:( 1/ 12/ 0)
----------------------------------
Root port: Ethernet1/49.14
OIF List:
FTAG ID: 13 [Disabled]
FTAG ID: 14 [Disabled]
FTAG ID: 15 [Disabled]
- Cette image montre la capture et la sortie ELAM Spine-201.
- Dans ce cas, cette sortie montre la valeur FTAG 4 ajoutée aux 4 derniers bits de BD GIPO dans le paquet reçu de leaf-101.
Spine201# vsh_lc <<< (OR "ssh root@lcX" if spine is modular). (Please engage TAC for spine ELAM)
module-1# debug platform internal roc elam asic 0
module-1(DBG-elam)# trigger reset
module-1(DBG-elam)# trigger init in-select 14 out-select 0
module-1(DBG-elam-insel6)# set inner ipv4 src_ip 10.100.0.10 dst_ip 239.100.0.10
module-1(DBG-elam-insel6)# start
module-1(DBG-elam-insel6)# status
module-1(DBG-elam-insel6)# ereport
------------------------------------------------------------------------------------------------------------------------------------------------------ Inner L2 Header ------------------------------------------------------------------------------------------------------------------------------------------------------ Inner Destination MAC : 0100.5E64.000A Source MAC : 0011.0100.0001 802.1Q tag is valid : no CoS : 0 Access Encap VLAN : 0 ------------------------------------------------------------------------------------------------------------------------------------------------------ Outer L3 Header ------------------------------------------------------------------------------------------------------------------------------------------------------ L3 Type : IPv4 DSCP : 0 Don't Fragment Bit : 0x0 TTL : 32 IP Protocol Number : UDP Destination IP : 225.1.156.244 <<<< BD GIPO + FTAG 4 (binary 11100001.00000001.10011100.11110100) Source IP : 10.1.160.64 <<<< Leaf 101 infra TEP address ------------------------------------------------------------------------------------------------------------------------------------------------------ Inner L3 Header ------------------------------------------------------------------------------------------------------------------------------------------------------ L3 Type : IPv4 DSCP : 0 Don't Fragment Bit : 0x0 TTL : 64 IP Protocol Number : UDP Destination IP : 239.100.0.10 Source IP : 10.100.0.10 <snip...>
------------------------------------------------------------------------------------------------------------------------------------------------------ Sideband SB Multicast Information ------------------------------------------------------------------------------------------------------------------------------------------------------ BD : 3( 0x3 ) Source is l3 interface : no FTAG : 4( 0x4 ) <snip...>
- Spine-201 examine ensuite sa propre route GIPO et sa propre valeur FTAG pour trouver la liste OIF pour transférer le paquet.
- Utilisez cette commande pour trouver la liste OIF pour le BD GIPO.
sp201# show isis internal mcast routes gipo
IS-IS process: isis_infra
VRF : default
GIPo Routes
====================================
System GIPo - Configured: 0.0.0.0
Operational: 239.255.255.240
====================================
GIPo: 225.0.0.0 [TRANSIT]
OIF List:
Ethernet1/2.35
Ethernet1/1.36
GIPo: 225.0.0.16 [TRANSIT]
OIF List:
<snip..>
GIPo: 225.1.156.240 [TRANSIT]
OIF List:
Ethernet1/2.35
Ethernet1/1.36
<snip...>
sp201# show isis internal mcast routes ftag
IS-IS process: isis_infra
VRF : default
FTAG Routes
====================================
System ftag order: NEW
System ftag preference: 2
Max Fabric System ftag preference: 2
Phantom Spine Capable: NO
FTAG ID: 0 [Root] [Enabled] Cost:( 0/ 0/ 0)
----------------------------------
Root port: -
OIF List:
Ethernet1/2.35
Ethernet1/1.36
FTAG ID: 1 [Root] [Enabled] Cost:( 0/ 0/ 0)
----------------------------------
Root port: -
OIF List:
Ethernet1/2.35
Ethernet1/1.36
FTAG ID: 2 [Root] [Enabled] Cost:( 0/ 0/ 0)
----------------------------------
Root port: -
OIF List:
Ethernet1/2.35
Ethernet1/1.36
FTAG ID: 3 [Root] [Enabled] Cost:( 0/ 0/ 0)
----------------------------------
Root port: -
OIF List:
Ethernet1/2.35
Ethernet1/1.36
FTAG ID: 4 [Root] [Enabled] Cost:( 0/ 0/ 0)
----------------------------------
Root port: -
OIF List:
Ethernet1/2.35 <<
<snip...> sp201#
show lldp neighbors Capability codes: (R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device (W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other Device ID Local Intf Hold-time Capability Port ID lf101 Eth1/1 120 BR Eth1/49 <<< Spine received packet from Leaf 101
lf102 Eth1/2 120 BR Eth1/49 <<< forward packet to Leaf 102 (and not back to Leaf 101) Total entries displayed: 2
- Le Leaf-102 reçoit les paquets et recherche l'entrée de la table de snoop, puis transfère le paquet au récepteur de multidiffusion.
- Cette commande affiche le résultat de la commande ELAM capture pour vérifier que le paquet de multidiffusion est reçu de la colonne vertébrale.
lf102# vsh_lc module-1# debug platform internal roc elam asic 0 module-1(DBG-elam)# trigger reset module-1(DBG-elam)# trigger init in-select 14 out-select 0 module-1(DBG-elam-insel14)# set inner ipv4 src_ip 10.100.0.10 dst_ip 239.100.0.10 module-1(DBG-elam-insel14)# start module-1(DBG-elam-insel14)# status ELAM STATUS =========== Asic 0 Slice 0 Status Triggered module-1(DBG-elam-insel14)# ereport ------------------------------------------------------------------------------------------------------------------------------------------------------ Outer L3 Header ------------------------------------------------------------------------------------------------------------------------------------------------------ L3 Type : IPv4 DSCP : 0 Don't Fragment Bit : 0x0 TTL : 31 IP Protocol Number : UDP Destination IP : 225.1.156.244 Source IP : 10.1.160.64 ------------------------------------------------------------------------------------------------------------------------------------------------------ Inner L3 Header ------------------------------------------------------------------------------------------------------------------------------------------------------ L3 Type : IPv4 DSCP : 0 Don't Fragment Bit : 0x0 TTL : 64 IP Protocol Number : UDP Destination IP : 239.100.0.10 Source IP : 10.100.0.10 ------------------------------------------------------------------------------------------------------------------------------------------------------
- Leaf-102 examine l'entrée IGMP Snoop pour transférer le paquet vers le récepteur de multidiffusion.
lf102# show ip igmp snooping group Type: S - Static, D - Dynamic, R - Router port, F - Fabricpath core port Vlan Group Address Ver Type Port list 16 239.100.0.10 v2 D Eth1/47
Requête IGMP requise
Les exigences du demandeur IGMP sont les suivantes :
- La surveillance IGMP demande à un interrogateur IGMP de fonctionner correctement, afin d'éviter l'abandon silencieux du groupe.
- Un routeur PIM (Protocol Independent Multicast) peut quand même envoyer la requête IGMP.
- Dans le cas d'une multidiffusion C2 pure sans routeur PIM dans le BD, nous pouvons activer une fonction de requête IGMP pour envoyer la requête sans exécuter PIM.
Dépannage
Cette section fournit des informations que vous pouvez utiliser pour dépanner votre configuration.
Utilisez ces commandes pour résoudre les problèmes IGMP de couche 2 :
show endpoints IPdetail show ip igmp snoop groups vlan xshow ip igmp snoop groups vlan x detailshow ip igmp snooping mroutermoquery -c fmcast.Grp
Informations connexes
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
1.0 |
28-Feb-2022 |
Première publication |
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)