Utilisation des commandes Cisco IOS « ip igmp join-group » et « ip igmp static-group »

Options de téléchargement

  • PDF     (240.2 KB)
    Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
  • ePub     (114.3 KB)
    Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
  • Mobi (Kindle)     (110.6 KB)
    Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils
Mis à jour:2 décembre 2015
ID du document:119383

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

Introduction

Ce document décrit le fonctionnement des commandes ip igmp join-group et ip igmp static-group dans Cisco IOS®.

Rejoindre de manière statique le groupe IGMP

Si le routeur possède la commande ip igmp join-group sur l'une des interfaces, le routeur lui-même devient un récepteur pour le flux de multidiffusion. Cette commande est utilisée afin de déplacer le trafic de multidiffusion vers ce routeur sans un récepteur directement connecté réel ou sans un voisin PIM (Protocol Independent Multicast) en aval qui envoie des requêtes PIM Join pour le flux de multidiffusion. Cependant, comme ce routeur rejoint le flux de multidiffusion, tous les paquets de multidiffusion sont transmis au processeur. Cela peut provoquer un CPU élevé ou provoquer l'impact des limiteurs de débit (le cas échéant) ou de la protection du plan de contrôle (CoPP).

Une meilleure alternative que vous pouvez utiliser afin d'attirer le flux de multidiffusion pour ce routeur est de configurer la commande d'interface ip igmp static-group. Avec cette commande, le routeur peut toujours attirer le flux de multidiffusion et le transférer sur l'interface, mais le routeur lui-même ne devient pas un récepteur pour le flux.

La commande d'interface ip igmp join-group et la commande ip igmp static-group amènent le PIM à envoyer des requêtes Join en amont vers la source ou vers le point de rendez-vous (RP), mais cela ne se produit que si le routeur avec cette commande est le routeur désigné (DR) PIM sur cette interface. Afin de s'assurer que la commande prend effet et attire le trafic de multidiffusion, utilisez la commande sur le routeur qui est le routeur désigné pour ce réseau particulier. Vous pouvez également définir le routeur qui utilise la commande PIM DR. Pour ce faire, configurez la commande ip pim dr-priority sur l'interface et assurez-vous qu'elle a la valeur de priorité DR PIM la plus élevée de tout routeur PIM sur ce réseau.

Voici un exemple :

Dans cet exemple, il existe une source avec l'adresse IP 10.1.3.3 et un récepteur pour le groupe 232.1.1.1.

Le récepteur est actif

Voici l’entrée de transfert multidiffusion sur le routeur R1 :

R1#show ip mroute 232.1.1.1 10.1.3.3
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
       Q - Received BGP S-A Route, q - Sent BGP S-A Route,
       V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
 
(10.1.3.3, 232.1.1.1), 01:54:48/00:02:54, flags: sT
Incoming interface: Ethernet1/0, RPF nbr 10.1.2.2
Outgoing interface list:
   Ethernet0/0, Forward/Sparse-Dense, 01:54:48/00:02:54

Comme l'illustre le résultat, l'interface Ethernet0/0 figure dans la liste OIL (Outgoing Interface List) et le trafic de multidiffusion (10.1.3.3, 232.1.1.1) est transféré à l'interface Ethernet0/0.

Ceci peut également être observé dans l'entrée MFIB (Multicast Forwarding Information Base) :

R1#show ip mfib 232.1.1.1 10.1.3.3        
Entry Flags:   C - Directly Connected, S - Signal, IA - Inherit A flag,
               ET - Data Rate Exceeds Threshold, K - Keepalive
               DDE - Data Driven Event, HW - Hardware Installed
I/O Item Flags: IC - Internal Copy, NP - Not platform switched,
                NS - Negate Signalling, SP - Signal Present,
               A - Accept, F - Forward, RA - MRIB Accept, RF - MRIB Forward,
               MA - MFIB Accept
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per second
Other counts:     Total/RPF failed/Other drops
I/O Item Counts:   FS Pkt Count/PS Pkt Count
Default
(10.1.3.3,232.1.1.1) Flags:
   SW Forwarding: 0/0/0/0, Other: 0/0/0
   Ethernet1/0 Flags: A
   Ethernet0/0 Flags: F NS
     Pkts: 0/0

Commande IGMP Join

Si le routeur R1 ne reçoit pas de requête PIM Join pour le flux multicast du routeur R4 (pour une raison quelconque), le flux multicast ne circule pas. Une raison possible est que le PIM n'est pas autorisé à former un voisinage entre les routeurs R1 et R4, car les routeurs appartiennent à un domaine administratif différent. Une solution consiste à transférer le trafic du routeur R1 vers le routeur R4 de manière statique.

La commande ip igmp join-group est utilisée sur l’interface Ethernet0/0 du routeur R1. Cela permet au routeur R1 d'envoyer une demande de jointure PIM en amont (vers la source ou le RP) et d'attirer le flux de multidiffusion (10.1.3.3, 232.1.1.1). Ce trafic est ensuite transféré à l’interface Ethernet0/0, car cette interface se trouve dans l’OIL. Cependant, le trafic est également pointé vers le processeur.

R1#show running-config interface Ethernet 0/0
!
interface Ethernet0/0
ip address 10.1.1.1 255.255.255.0
ip pim sparse-dense-mode
 ip igmp join-group 232.1.1.1 source 10.1.3.3
end
R1#show ip mroute 232.1.1.1 10.1.3.3
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
       Q - Received BGP S-A Route, q - Sent BGP S-A Route,
       V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
 
(10.1.3.3, 232.1.1.1), 00:09:30/00:02:19, flags: sLTI
Incoming interface: Ethernet1/0, RPF nbr 10.1.2.2
Outgoing interface list:
   Ethernet0/0, Forward/Sparse-Dense, 00:00:40/00:02:19

L'indicateur L signifie que le trafic de multidiffusion est puni. L’interface Ethernet0/0 se trouve dans l’OIL, de sorte que le trafic est pointé vers le processeur et transféré à l’interface Ethernet0/0.

L'entrée MFIB affiche l'indicateur Internal Copy (IC). Cela signifie que les paquets pour ce flux sont punis sur le CPU.

R1#show ip mfib 232.1.1.1 10.1.3.3
Entry Flags:   C - Directly Connected, S - Signal, IA - Inherit A flag,
               ET - Data Rate Exceeds Threshold, K - Keepalive
               DDE - Data Driven Event, HW - Hardware Installed
I/O Item Flags: IC - Internal Copy, NP - Not platform switched,
               NS - Negate Signalling, SP - Signal Present,
               A - Accept, F - Forward, RA - MRIB Accept, RF - MRIB Forward,
               MA - MFIB Accept
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per second
Other counts:     Total/RPF failed/Other drops
I/O Item Counts:   FS Pkt Count/PS Pkt Count
Default
(10.1.3.3,232.1.1.1) Flags:
   SW Forwarding: 0/0/0/0, Other: 0/0/0
   Ethernet1/0 Flags: A
   Ethernet0/0 Flags: F IC NS
     Pkts: 0/0

Comme tout le trafic de ce flux multicast est ponté, il peut provoquer des effets secondaires indésirables, comme décrit précédemment.

Avertissement : N'utilisez pas la commande ip igmp join-group à moins qu'elle ne soit utilisée dans un environnement de test.

Commande IGMP Static

La commande ip igmp static-group est utilisée comme solution afin de transférer le trafic du routeur R1 vers le routeur R4 de manière statique. Dans ce scénario, le routeur R1 envoie une requête de jointure PIM en amont (à la source ou au RP) et attire le flux de multidiffusion (10.1.3.3, 232.1.1.1). Ce trafic est ensuite transféré à l'interface Ethernet0/0, car cette interface se trouve dans l'OIL, mais le trafic n'est pas pointé vers le processeur.

R1#show running-config interface Ethernet 0/0
!
interface Ethernet0/0
ip address 10.1.1.1 255.255.255.0
ip pim sparse-dense-mode
 ip igmp static-group 232.1.1.1 source 10.1.3.3
end
R1#show ip mroute 232.1.1.1 10.1.3.3        
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
       Q - Received BGP S-A Route, q - Sent BGP S-A Route,
       V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
 
(10.1.3.3, 232.1.1.1), 00:07:41/stopped, flags: sTI
Incoming interface: Ethernet1/0, RPF nbr 10.1.2.2
Outgoing interface list:
 Ethernet0/0, Forward/Sparse-Dense, 00:05:06/00:00:53

L'indicateur L n'apparaît plus. Le trafic n’est pas pointé sur ce routeur, mais il est transféré aux interfaces de l’OIL.

De même, l'entrée MFB n'affiche pas l'indicateur IC :

R1#show ip mfib 232.1.1.1 10.1.3.3
Entry Flags:   C - Directly Connected, S - Signal, IA - Inherit A flag,
               ET - Data Rate Exceeds Threshold, K - Keepalive
               DDE - Data Driven Event, HW - Hardware Installed
I/O Item Flags: IC - Internal Copy, NP - Not platform switched,
               NS - Negate Signalling, SP - Signal Present,
               A - Accept, F - Forward, RA - MRIB Accept, RF - MRIB Forward,
               MA - MFIB Accept
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per second
Other counts:     Total/RPF failed/Other drops
I/O Item Counts:   FS Pkt Count/PS Pkt Count
Default
(10.1.3.3,232.1.1.1) Flags:
   SW Forwarding: 0/0/0/0, Other: 0/0/0
   Ethernet1/0 Flags: A
   Ethernet0/0 Flags: F NS
     Pkts: 0/0

Rôle DR PIM

Ni la commande ip igmp static-group ni la commande ip igmp join-group ne prennent effet si le routeur R1 n'est pas le DR PIM de l'interface Ethernet0/0.

Voici un exemple :

R1#show running-config interface Ethernet 0/0
!
interface Ethernet0/0
ip address 10.1.1.1 255.255.255.0
ip pim sparse-dense-mode
ip igmp static-group 232.1.1.1 source 10.1.3.3
end

Note: La commande permet de spécifier une source (PIM SSM) ou aucune source (PIM Sparse Mode/PIM BiDIR Mode).

R1#show ip mroute 232.1.1.1 10.1.3.3        
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
       Q - Received BGP S-A Route, q - Sent BGP S-A Route,
       V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
 
(10.1.3.3, 232.1.1.1), 00:00:30/00:02:29, flags: sPT
Incoming interface: Ethernet1/0, RPF nbr 10.1.2.2
 Outgoing interface list: Null

L’interface Ethernet0/0 ne se trouve pas dans l’OIL. Ceci est dû au fait que le routeur R1 n'est pas le DR PIM sur la liaison avec la commande ip igmp static-group :

R1#show ip pim interface ethernet 0/0
 
Address         Interface               Ver/   Nbr   Query DR     DR
                                         Mode   Count Intvl Prior
10.1.1.1        Ethernet0/0             v2/SD 1     30     1     10.1.1.4

Le routeur R1 n’envoie pas non plus de demande de connexion PIM en amont. Ceci est évident sur le routeur R2, car l’entrée de multidiffusion est manquante :

R2#show ip mroute 232.1.1.1 10.1.3.3
Group 232.1.1.1 not found

Voici le résultat qui peut être observé dès que le routeur R1 est le DR PIM sur l’interface Ethernet0/0 :

R1#show ip pim interface ethernet 0/0
 
Address         Interface               Ver/   Nbr   Query DR     DR
                                         Mode   Count Intvl Prior
10.1.1.1         Ethernet0/0             v2/SD 1     30     1     10.1.1.1
R1#show ip mroute 232.1.1.1 10.1.3.3
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
       Q - Received BGP S-A Route, q - Sent BGP S-A Route,
       V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
 
(10.1.3.3, 232.1.1.1), 00:02:39/00:02:55, flags: sTI
Incoming interface: Ethernet1/0, RPF nbr 10.1.2.2
Outgoing interface list:
   Ethernet0/0, Forward/Sparse-Dense, 00:00:04/00:02:55

Utilisation sécurisée de la commande ip igmp join-group

Afin de résoudre les problèmes, vous pouvez effectuer un test avec la multidiffusion, même en dehors des travaux pratiques. Dans ce cas, assurez-vous d'utiliser la commande ip igmp join-group de manière sécurisée. La raison pour laquelle vous devez utiliser la commande ip igmp join-group sur la commande ip igmp static-group est que les paquets de multidiffusion sont punis. En tant que tel, si vous exécutez une requête ping avec une destination de multidiffusion, le routeur avec la commande est un récepteur pour le flux de multidiffusion et peut répondre à la requête ping.

Voici un exemple :

La source 10.1.3.3 est une adresse IP sur le routeur R3. Si vous placez la commande sur l’interface Ethernet0/0 sur le routeur R1 et envoyez une requête ping à partir du routeur R3, le routeur R1 peut répondre à la requête ping. En tant que tel, vous pouvez effectuer des tests comme s’il y avait un récepteur directement connecté sur le routeur R1. La commande ip igmp join-group est placée sur l’interface Ethernet0/0 sur le routeur R1 et la source est spécifiée afin de s’assurer que le routeur R1 envoie uniquement du trafic de cette source (et y répond).

R1#show running-config interface Ethernet 0/0
!
interface Ethernet0/0
ip address 10.1.1.1 255.255.255.0
ip pim sparse-dense-mode
ip igmp join-group 232.1.1.1 source 10.1.3.3
end
R3#ping 232.1.1.1 source 10.1.3.3
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 232.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.3.3
 
Reply to request 0 from 10.1.1.1, 2 ms
R3#

La commande debug ip icmp sur le routeur R1 indique que la requête ping est arrivée et que le routeur R1 envoie une réponse :

R1#debug ip icmp
ICMP packet debugging is on
R1#
 
*Oct 30 11:35:41.133: ICMP: echo reply sent, src 10.1.1.1, dst 10.1.3.3,
 topology BASE, dscp 0 topoid 0

Remarques importantes sur l'utilisation des commandes

La meilleure pratique est de ne pas utiliser la commande ip igmp join-group à moins qu'elle ne soit utilisée à des fins de test dans les travaux pratiques ou lors d'un test temporaire sur un réseau actif. Supprimez la commande une fois tous les tests terminés. Si le trafic de multidiffusion doit être transféré de manière statique uniquement, utilisez la commande ip igmp static-group à la place.

TAC Authored

Contribution d’experts de Cisco

Ce document vous est-il utile?

FeedbackCommentaires

Contacter Cisco

Ce document s’applique à ces produits