Guide de dépannage de la multidiffusion IP
Table des matières
Introduction
Ce document décrit des problèmes courants avec leurs solutions pour Multicast IP.
Conditions préalables
Exigences
Aucune exigence spécifique n'est associée à ce document.
Composants utilisés
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
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
Lorsque vous dépannez le routage de multidiffusion, la principale préoccupation est l'adresse source. La multidiffusion a un concept de contrôle RPF (Reverse Path Forwarding). Lorsqu'un paquet de multidiffusion arrive sur une interface, le processus RPF vérifie que cette interface entrante est l'interface sortante utilisée par le routage de monodiffusion afin d'atteindre la source du paquet de multidiffusion. Ce processus de contrôle RPF empêche des boucles. Le routage multidiffusion ne transmet pas de paquet à moins que la source du paquet ne passe un contrôle RPF. Une fois qu'un paquet aura passé ce contrôle RPF, le routage de multicast transfère le paquet en fonction seulement sur l'adresse de destination.
Comme le routage monodiffusion, le routage multicast a plusieurs protocoles à disposition, tels que le mode dense de Protocol Independent Multicast (PIM-DM), le mode intermédiaire de protocole multicast PIM (PIM-SM), le protocole multicast de routage à vecteur (DVMRP), le protocole BGP multicast (MBGP), et le protocole multicast de découverte de source (MSDP). Les études de cas de ce document vous guident tout au long du processus de dépannage de divers problèmes. Vous pouvez voir quelles commandes sont utilisées afin d'identifier rapidement le problème et apprendre à le résoudre. Les études de cas listées ici sont génériques à travers les protocole, sauf indication contraire.
Le routeur ne transfère pas des paquets multidiffusion à l'hôte en raison d'une panne RPF
Cette section fournit une solution au problème courant d'une défaillance RPF de multidiffusion IP. Ce schéma de réseau est utilisé comme exemple.
Exemple de schéma de réseau d'une défaillance RPF multidiffusion
Dans cette figure, les paquets de multidiffusion arrivent dans E0/0 du routeur 75a à partir d’un serveur dont l’adresse IP est 10.1.1.1 et les envoie au groupe 10.224.1.1. Ceci est connu comme (S, G) ou (10.1.1.1, 10.224.1.1).
diagnostic du problème
Les hôtes directement connectés au routeur 75a reçoivent le flux de multicast, mais les hôtes directement connectés au routeur 72a ne le reçoivent pas. Commencez par saisir le show ip mroute 224.1.1.1 afin de vérifier l'activité sur le routeur 75a. Cette commande examine l'itinéraire de multidiffusion (mroute) pour l'adresse de groupe 10.224.1.1 :
75a#show ip mroute 10.224.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 10.224.1.1), 00:01:23/00:02:59, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse-Dense, 00:01:23/00:00:00
(10.1.1.1, 10.224.1.1), 00:01:23/00:03:00, flags: TA
Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse-Dense, 00:01:23/00:00:00
Puisque le routeur exécute le mode dense PIM (vous savez qu'il est dense à cause de l'indicateur D), ignorez l'entrée *, G et concentrez-vous sur l'entrée S, G. Cette entrée indique que les paquets de multidiffusion sont originaires d'un serveur dont l'adresse est 10.1.1.1, qui les envoie à un groupe de multidiffusion de 10.224.1.1. Les paquets arrivent dans l’interface Ethernet0/0 et sont transférés à l’interface Ethernet0/1. C'est un scénario parfait.
Saisissez la commande show ip pim neighbor afin de voir si le routeur 72a montre le routeur en amont (75a) comme voisin PIM :
ip22-72a#show ip pim neighbor PIM Neighbor Table Neighbor Address Interface Uptime Expires Ver Mode 10.2.1.1 Ethernet3/1 2d00h 00:01:15 v2
A partir des versions show ip pim neighbor de la commande, le voisinage PIM semble bon.
Saisissez la commande show ip mroute afin de voir si le routeur 72a a une bonne mroute :
ip22-72a#show ip mroute 10.224.1.1
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,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 10.224.1.1), 00:10:42/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3/1, Forward/Dense, 00:10:42/00:00:00
Ethernet3/2, Forward/Dense, 00:10:42/00:00:00
(10.1.1.1, 10.224.1.1), 00:01:10/00:02:48, flags:
Incoming interface: Ethernet2/0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3/1, Forward/Dense, 00:01:10/00:00:00
Ethernet3/2, Forward/Dense, 00:00:16/00:00:00
ip22-72a#
Vous pouvez le voir à partir du show ip mroute 10.224.1.1 indique que l'interface entrante est Ethernet2/0, alors qu'Ethernet3/1 est attendu.
Saisissez la commande show ip mroute 10.224.1.1 count afin de voir si un trafic de multidiffusion pour ce groupe arrive au routeur 72a et ce qui se passe ensuite :
ip22-72a#show ip mroute 10.224.1.1 count
IP Multicast Statistics
3 routes using 2032 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg
Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null,
rate-limit etc)
Group: 10.224.1.1, Source count: 1, Packets forwarded: 0, Packets received: 471
Source: 10.1.1.1/32, Forwarding: 0/0/0/0, Other: 471/471/0
ip22-72a#
Vous pouvez voir à partir des Autres nombres que le trafic est abandonné en raison de la défaillance RPF : total 471 abandons, en raison de la défaillance RPF - 471...
Saisissez la commande show ip rpf afin de voir s'il y a une erreur RPF :
ip22-72a#show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: Ethernet2/0 RPF neighbor: ? (0.0.0.0) RPF route/mask: 10.1.1.1/32 RPF type: unicast (static) RPF recursion count: 0 Doing distance-preferred lookups across tables ip22-72a#
Cisco IOS® calcule l'interface RPF de cette façon. Les sources possibles d'informations RPF sont la table de routage de monodiffusion, la table de routage MBGP, la table de routage DVMRP et la table de routage Mroute statique. Lorsque vous calculez l'interface RPF, la distance administrative est principalement utilisée afin de déterminer exactement sur quelle source d'informations le calcul RPF est basé. Les règles spécifiques sont :
-
Toutes les sources précédentes de données RPF sont recherchées pour une correspondance sur l'adresse IP source. Lorsque vous utilisez des arborescences partagées, l'adresse RP est utilisée à la place de l'adresse source.
-
Si plusieurs routes correspondantes sont trouvées, la route avec la distance administrative la plus faible est utilisée.
-
Si les distances administratives sont égales, l'ordre de préférence suivant est utilisé :
-
Mroutes statiques
-
Routes de DVMRP
-
Routes MBGP
-
Routes de monodiffusion
-
-
Si plusieurs entrées se produisent pour une route dans le même tableau de routage, la route de la plus longue correspondance est utilisée.
Les show ip mroute 224.1.1.1 La sortie de la commande indique que l'interface RPF est E2/0, mais que l'interface entrante doit être E3/1.
Saisissez la commande show ip mroute 224.1.1.1 afin de voir pourquoi l'interface RPF est différente de ce qui était attendu.
ip22-72a#show ip route 10.1.1.1 Routing entry for 10.1.1.1/32 Known via "static", distance 1, metric 0 (connected) Routing Descriptor Blocks: * directly connected, via Ethernet2/0 Route metric is 0, traffic share count is 1
Vous pouvez voir de ce résultat de la commande montrer ip route 10.1.1.1 qu'il y a une route statique de /32, qui fait que l'interface fausse est choisie comme interface RPF.
Entrez d'autres commandes debug :
ip22-72a#debug ip mpacket 10.224.1.1 *Jan 14 09:45:32.972: IP: s=10.1.1.1 (Ethernet3/1) d=10.224.1.1 len 60, not RPF interface *Jan 14 09:45:33.020: IP: s=10.1.1.1 (Ethernet3/1) d=10.224.1.1 len 60, not RPF interface *Jan 14 09:45:33.072: IP: s=10.1.1.1 (Ethernet3/1) d=10.224.1.1 len 60, not RPF interface *Jan 14 09:45:33.120: IP: s=10.1.1.1 (Ethernet3/1) d=10.224.1.1 len 60, not RPF interface
Les paquets arrivent sur E3/1, ce qui est correct. Cependant, elles sont abandonnées car ce n'est pas l'interface que la table de routage de monodiffusion utilise pour le contrôle RPF.
Correctifs possibles
Vous pouvez soit modifier la table de routage de monodiffusion afin de satisfaire cette exigence, soit ajouter une mroute statique pour forcer la multidiffusion vers RPF à partir d'une interface particulière, quel que soit l'état de la table de routage de monodiffusion. Ajouter un mroute statique :
ip22-72a(config)#ip mroute 10.1.1.1 255.255.255.255 10.2.1.1
Cette mroute statique indique que pour atteindre l'adresse 10.1.1.1 pour RPF, utilisez 10.2.1.1 comme prochain saut qui est l'interface E3/1.
ip22-72a#show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: Ethernet3/1 RPF neighbor: ? (10.2.1.1) RPF route/mask: 10.1.1.1/32 RPF type: static mroute RPF recursion count: 0 Doing distance-preferred lookups across tables
Le résultat de show ip mroute et debug ip mpacket semble bon, le nombre de paquets envoyés dans le show ip mroute count augmente et l’hôte A reçoit des paquets.
ip22-72a#show ip mroute 10.224.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 10.224.1.1), 00:01:15/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3/1, Forward/Sparse-Dense, 00:01:15/00:00:00
Ethernet3/2, Forward/Sparse-Dense, 00:00:58/00:00:00
(10.1.1.1, 10.224.1.1), 00:00:48/00:02:59, flags: CTA
Incoming interface: Ethernet3/1, RPF nbr 10.2.1.1, Mroute
Outgoing interface list:
Ethernet3/2, Forward/Sparse-Dense, 00:00:48/00:00:00
ip22-72a#show ip mroute 10.224.1.1 count
IP Multicast Statistics
3 routes using 2378 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 10.224.1.1, Source count: 1, Packets forwarded: 1019, Packets received: 1019
Source: 10.1.1.1/32, Forwarding: 1019/1/100/0, Other: 1019/0/0
ip22-72a#show ip mroute 10.224.1.1 count
IP Multicast Statistics
3 routes using 2378 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 10.224.1.1, Source count: 1, Packets forwarded: 1026, Packets received: 1026
Source: 10.1.1.1/32, Forwarding: 1026/1/100/0, Other: 1026/0/0
ip22-72a#
ip22-72a#debug ip mpacket 10.224.1.1
*Jan 14 10:18:29.951: IP: s=10.1.1.1 (Ethernet3/1)
d=10.224.1.1 (Ethernet3/2) len 60, mforward
*Jan 14 10:18:29.999: IP: s=10.1.1.1 (Ethernet3/1)
d=10.224.1.1 (Ethernet3/2) len 60, mforward
*Jan 14 10:18:30.051: IP: s=10.1.1.1 (Ethernet3/1)
d=10.224.1.1 (Ethernet3/2) len 60, mforward
Le routeur ne transfère pas des paquets multidiffusion à l'hôte en raison de la configuration TTL de la source
Cette section fournit une solution au problème courant des paquets de multidiffusion IP qui ne sont pas transférés, car la valeur de durée de vie (TTL) est décrémentée à zéro. C'est un problème courant, car il y a beaucoup d'appplications multicast. Ces applications multidiffusion sont conçues principalement pour l'utilisation de LAN, et définissent ainsi le TTL à une valeur basse ou même à un 1. Utilisez ce schéma de réseau comme exemple.
Exemple d'utilisation d'applications multidiffusion conçues principalement pour le LAN
diagnostic du problème
Dans la figure précédente, le routeur A ne transmet pas les paquets de la ou des sources au routeur B qui est directement connecté au récepteur. Examinez le résultat de la commande show ip mroute sur le routeur A afin de voir l'état de routage de multidiffusion :
ROUTERA#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 00:00:01/00:00:00, RP 0.0.0.0, flags: DJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse-Dense, 00:00:01/00:00:00
(*, 10.224.1.1), 00:00:02/00:02:57, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse-Dense, 00:00:02/00:00:00
Vous pouvez ignorer le 10.224.0.40 dans le résultat puisque tous les routeurs rejoignent ce groupe de découverte Auto-RP. Mais il n'y a aucune source listée pour 10.224.1.1. En plus de « *, 10.224.1.1 », vous pouvez voir « 10.1.1.1, 10.224.1.1 ».
Entrez la commande show ip rpf afin de voir s'il s'agit d'un problème RPF :
ROUTERA#show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: Ethernet0/0 RPF neighbor: ? (0.0.0.0) - directly connected RPF route/mask: 10.1.1.1/24 RPF type: unicast (connected) RPF recursion count: 0 Doing distance-preferred lookups across tables
D'après le résultat, il ne s'agit pas d'un problème RPF. Le contrôle RPF indique correctement E0/0 pour atteindre l'adresse IP source.
Vérifiez si PIM est configuré sur les interfaces avec le show ip pim interface commande :
ROUTERA#show ip pim interface
Address Interface Version/Mode Nbr Query DR
Count Intvl
10.1.1.2 Ethernet0/0 v2/Sparse-Dense 0 30 10.1.1.2
10.2.1.1 Ethernet0/1 v2/Sparse-Dense 2 30 10.2.1.2
Le résultat semble bon, donc ce n'est pas le problème. Vérifiez si le routeur reconnaît un trafic actif avec le show ip mroute active commande :
ROUTERA#show ip mroute active Active IP Multicast Sources - sending >= 4 kbps
D’après le résultat, le routeur ne reconnaît aucun trafic actif.
ROUTERA#debug ip mpacket IP multicast packets debugging is on
Le récepteur n'envoie peut-être aucun rapport IGMP (Internet Group Management Protocol) (jointures) pour le groupe 10.224.1.1. Vous pouvez le vérifier auprès de la show ip igmp group commande :
ROUTERB#show ip igmp group IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter 224.0.1.40 Ethernet1/1 00:34:34 never 10.2.1.2 10.224.1.1 Ethernet1/2 00:30:02 00:02:45 10.3.1.2
10.224.1.1 a été connecté à E1/2, ce qui est en ordre.
Le mode dense du protocole multicast PIM est un protocole inondation et élagage, il n'y a donc pas de liaisons, mais il y a des greffes. Puisque le routeur B n'a pas été inondé par le routeur A, il ne sait pas où envoyer une greffe.
Vous pouvez vérifier s'il s'agit d'un problème de durée de vie avec la capture de l'analyseur de réseau et également avec show ip traffic commande :
ROUTERA#show ip traffic
IP statistics:
Rcvd: 248756 total, 1185 local destination
0 format errors, 0 checksum errors, 63744 bad hop count
0 unknown protocol, 0 not a gateway
0 security failures, 0 bad options, 0 with options
Le résultat affiche 63744 nombres de sauts erronés. Chaque fois que vous introduisez cette commande, le mauvais nombre de sauts augmente. Il s'agit d'une indication forte que l'expéditeur envoie des paquets avec une durée de vie de 1, que le routeur A décrémente à zéro. Ceci a comme conséquence une augmentation de la mauvaise valeur du nombre de sauts.
Correctifs possibles
Afin de résoudre le problème, vous devez augmenter la durée de vie. Ceci est fait au niveau de l'application sur l'expéditeur. Pour plus d'informations, consultez votre manuel d'instructions de l'application multidiffusion.
Une fois que ceci est fait, le routeur A ressemble à ceci :
ROUTERA#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 01:16:32/00:00:00, RP 0.0.0.0, flags: DJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse-Dense, 01:16:32/00:00:00
(*, 10.224.1.1), 00:28:42/00:02:59, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse-Dense, 00:28:42/00:00:00
(10.1.1.1, 10.224.1.1), 00:19:24/00:02:59, flags: TA
Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse-Dense, 00:19:24/00:00:00
C'est le résultat que vous voulez voir.
Sur le routeur B vous voyez :
ROUTERB#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 01:23:57/00:00:00, RP 0.0.0.0, flags: DJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet1/1, Forward/Sparse-Dense, 01:23:57/00:00:00
(*, 10.224.1.1), 01:19:26/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet1/1, Forward/Sparse-Dense, 01:19:26/00:00:00
Ethernet1/2, Forward/Sparse-Dense, 01:19:26/00:00:00
(10.1.1.1, 10.224.1.1), 00:17:46/00:02:59, flags: CTA
Incoming interface: Ethernet1/1, RPF nbr 10.2.1.1
Outgoing interface list:
Ethernet1/2, Forward/Sparse-Dense, 00:17:46/00:00:00
Le routeur ne transfère pas des paquets multidiffusion en raison du seuil de TTL du routeur
Cette section fournit une solution au problème courant où le seuil de durée de vie est trop bas, de sorte que le trafic de multidiffusion IP n'atteint pas le récepteur. Ce schéma de réseau est utilisé comme exemple.
Le seuil de durée de vie est trop bas pour que le trafic de multidiffusion IP n'atteigne pas le récepteur
diagnostic du problème
Dans la figure précédente, le récepteur ne reçoit pas de paquets de multidiffusion de la source. Il peut y avoir plusieurs routeurs entre la source et le routeur 75a. Observez d'abord le routeur 75a, puisqu'il est directement connecté au récepteur.
ip22-75a#show ip mroute 10.224.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 10.224.1.1), 00:32:05/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse-Dense, 00:08:17/00:00:00
(10.1.1.1, 10.224.1.1), 00:01:02/00:01:57, flags: CTA
Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse-Dense, 00:01:02/00:00:00
Le résultat montre que le routeur 75a transfère les paquets vers Ethernet0/1. Afin d'être absolument sûr que le routeur 75a transfère les paquets, activez debug uniquement pour ce groupe source et multidiffusion :
ip22-75a#configure terminal Enter configuration commands, one per line. End with CNTL/Z. ip22-75a(config)#access-list 101 permit udp host 10.1.1.1 host 10.224.1.1 ip22-75a(config)#end ip22-75a#debug ip mpacket 101 IP multicast packets debugging is on for access list 101 ip22-75a# *Jan 17 09:04:08.714: IP: s=10.1.1.1 (Ethernet0/0) d=10.224.1.1 len 60, threshold denied *Jan 17 09:04:08.762: IP: s=10.1.1.1 (Ethernet0/0) d=10.224.1.1 len 60, threshold denied *Jan 17 09:04:08.814: IP: s=10.1.1.1 (Ethernet0/0) d=10.224.1.1 len 60, threshold denied
Les debug Ces messages indiquent que le routeur 75a ne transmet pas les paquets de multidiffusion car le seuil de durée de vie a été atteint. Examinez la configuration du routeur afin de voir si vous pouvez trouver la raison. Ce résultat montre le coupable :
interface Ethernet0/1 ip address 10.2.1.1 255.255.255.0 ip pim sparse-dense-mode ip multicast ttl-threshold 15
Le routeur a un seuil de TTL de 15, mais ceci ne signifie pas que quelque chose plus grand qu'un TTL de 15 n'est pas envoyé. En fait, l'opposé est vrai. La demande est envoyée avec un TTL de 15. Quand qu'elle arrive au routeur 75a, les paquets de multidiffusion ont un TTL de moins de 15.
Les ip multicast ttl-threshold
signifie que tous les paquets dont la durée de vie est inférieure au seuil spécifié, dans ce cas, 15, ne sont pas transférés. Cette commande est généralement utilisée afin de fournir une frontière pour empêcher le trafic de multidiffusion interne de dériver hors de l'intranet.
Correctifs possibles
Supprimez le ip multicast ttl-threshold
avec la forme no de cette commande, qui revient à la valeur de seuil TTL par défaut de 0, ou abaissez le seuil TTL afin que le trafic puisse passer.
Plusieurs chemins à coût égal entraînent un comportement RPF indésirable
Cette section montre comment des chemins de coût égal vers une source de multidiffusion peuvent provoquer un comportement RPF indésirable. Il décrit également comment configurer la multidiffusion IP afin d'éviter ce comportement. Ce schéma de réseau est utilisé comme exemple.
Chemins à coût égal vers une source de multidiffusion provoquant un comportement RPF indésirable
diagnostic du problème
Dans la figure, le routeur 75b dispose de trois chemins de coût égal vers la source (10.1.1.1), et il choisit une liaison que vous ne voulez pas utiliser en premier comme liaison RPF.
Confronté aux plusieurs chemins à une source de coût égal, multicast IP choisit l'interface qui a un voisin de multidiffusion indépendant du protocole (PIM) avec l'adresse IP la plus élevée comme interface d'entrée et puis des éléments aux voisins PIM sur les autres liaisons.
Correctifs possibles
Afin de changer l'interface IP multicast choisit comme son interface entrante, vous pouvez faire l'une de ces choses :
-
Configurer seulement PIM sur les interfaces que vous voulez que le multicast traverse, ce qui signifie que vous perdez la redondance de multicast.
-
Modifier les sous-réseaux de sorte que l'adresse IP la plus élevée se trouve sur la liaison que vous voulez avoir comme liaison multicast primaire.
-
Créez une route de multidiffusion statique (mroute) qui pointe vers l'interface de multidiffusion préférée, ce qui signifie que vous perdez la redondance de multidiffusion.
Comme exemple, un mroute statique est créé.
Avant d'installer une mroute statique, vous voyez dans ce résultat que la table de routage a trois routes de coût égal pour l'adresse source 10.1.1.1. Les informations RPF indiquent que l'interface RPF est E1/3 :
ip22-75b#show ip route 10.1.1.1
Routing entry for 10.1.1.1/24
Known via "ospf 1", distance 110, metric 20, type intra area
Redistributing via ospf 1
Last update from 10.3.1.1 on Ethernet1/2, 00:26:21 ago
Routing Descriptor Blocks:
* 10.4.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3
Route metric is 20, traffic share count is 1
10.2.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1
Route metric is 20, traffic share count is 1
10.3.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/2
Route metric is 20, traffic share count is 1
ip22-75b#show ip rpf 10.1.1.1
RPF information for ? (10.1.1.1)
RPF interface: Ethernet1/3
RPF neighbor: ? (10.4.1.1)
RPF route/mask: 10.1.1.1/24
RPF type: unicast (ospf 1)
RPF recursion count: 0
Doing distance-preferred lookups across tables
ip22-75b#show ip mroute 10.224.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 10.224.1.1), 01:30:34/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet1/4, Forward/Sparse-Dense, 01:30:34/00:00:00
Ethernet1/1, Forward/Sparse-Dense, 01:30:35/00:00:00
Ethernet1/2, Forward/Sparse-Dense, 01:30:35/00:00:00
Ethernet1/3, Forward/Sparse-Dense, 00:24:22/00:00:00
(10.1.1.1, 10.224.1.1), 01:30:35/00:02:59, flags: CT
Incoming interface: Ethernet1/3, RPF nbr 10.4.1.1
Outgoing interface list:
Ethernet1/1, Prune/Sparse-Dense, 01:30:35/00:02:32
Ethernet1/4, Forward/Sparse-Dense, 01:30:35/00:00:00
Ethernet1/2, Prune/Sparse-Dense, 00:24:22/00:02:42
Après avoir configuré la mroute statique, vous voyez dans ce résultat que l'interface RPF a changé en E1/1 :
ip22-75b#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
ip22-75b(config)#ip mroute 0.0.0.0 0.0.0.0 10.2.1.1
ip22-75b(config)#end
ip22-75b#show ip rpf 10.1.1.1
RPF information for ? (10.1.1.1)
RPF interface: Ethernet1/1
RPF neighbor: ? (10.2.1.1)
RPF route/mask: 10.1.1.1/0
RPF type: static mroute
RPF recursion count: 0
Doing distance-preferred lookups across tables
ip22-75b#show ip route 10.1.1.1
Routing entry for 10.1.1.1/24
Known via "ospf 1", distance 110, metric 20, type intra area
Redistributing via ospf 1
Last update from 10.3.1.1 on Ethernet1/2, 00:26:21 ago
Routing Descriptor Blocks:
* 10.4.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3
Route metric is 20, traffic share count is 1
10.2.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1
Route metric is 20, traffic share count is 1
10.3.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/2
Route metric is 20, traffic share count is 1
ip22-75b#show ip mroute 10.224.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 10.224.1.1), 01:31:29/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet1/4, Forward/Sparse-Dense, 01:31:29/00:00:00
Ethernet1/1, Forward/Sparse-Dense, 01:31:30/00:00:00
Ethernet1/2, Forward/Sparse-Dense, 01:31:30/00:00:00
Ethernet1/3, Forward/Sparse-Dense, 00:25:17/00:00:00
(10.1.1.1, 10.224.1.1), 01:31:30/00:02:59, flags: CT
Incoming interface: Ethernet1/1, RPF nbr 10.2.1.1, Mroute
Outgoing interface list:
Ethernet1/4, Forward/Sparse-Dense, 01:31:30/00:00:00
Ethernet1/2, Prune/Sparse-Dense, 00:25:17/00:01:47
Ethernet1/3, Prune/Sparse-Dense, 00:00:31/00:02:28
Pourquoi Multicast IP ne cherche-t-il pas l'équilibre à travers tous les chemins de coût égal disponibles ?
Cette section fournit une solution au problème courant de la configuration de la multidiffusion IP afin d'équilibrer la charge sur tous les chemins à coût égal disponibles. Ce schéma de réseau est utilisé comme exemple.
Configurer la multidiffusion IP pour équilibrer la charge sur tous les chemins à coût égal disponibles
Dans la figure, le routeur 75b dispose de trois chemins de coût égal vers la source (10.1.1.1). Vous voulez équilibrer le trafic de multidiffusion à travers chacune des trois liaisons.
Correctifs possibles
Comme vous l'avez vu dans la section Plusieurs chemins à coût égal entraînent un comportement RPF indésirable, Protocol Independent Multicast (PIM) choisit seulement une interface pour le contrôle RPF et élague les autres. Ceci signifie que l'équilibrage de charge ne se produit pas. Pour équilibrer la charge, vous devez supprimer PIM des liaisons redondantes et créer un tunnel entre le routeur 75a et le routeur 75b. Vous pouvez alors équilibrer la charge au niveau de liaison, et l'IP s'exécute via le tunnel.
Ce sont les configurations pour le tunnel.
| Routeur 75a |
|---|
interface Tunnel0 ip address 10.6.1.1 255.255.255.0 ip pim sparse-dense-mode tunnel source Ethernet0/0 tunnel destination 10.5.1.1 ! interface Ethernet0/0 ip address 10.1.1.2 255.255.255.0 ip pim sparse-dense-mode ! interface Ethernet0/1 ip address 10.2.1.1 255.255.255.0 ! interface Ethernet0/2 ip address 10.3.1.1 255.255.255.0 ! interface Ethernet0/3 ip address 10.4.1.1 255.255.255.0 |
| Routeur 75b |
|---|
interface Tunnel0 ip address 10.6.1.2 255.255.255.0 ip pim sparse-dense-mode tunnel source Ethernet1/4 tunnel destination 10.1.1.2 ! interface Ethernet1/1 ip address 10.2.1.2 255.255.255.0 ! interface Ethernet1/2 ip address 10.3.1.2 255.255.255.0 ! interface Ethernet1/3 ip address 10.4.1.2 255.255.255.0 ! interface Ethernet1/4 ip address 10.5.1.1 255.255.255.0 ip pim sparse-dense-mode ! ip mroute 0.0.0.0 0.0.0.0 Tunnel0 |
Après avoir configuré le tunnel, entrez la commande show ip mroute afin de voir la route de multidiffusion (mroute) pour le groupe :
ip22-75a#show ip mroute 10.224.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 10.224.1.1), 02:40:31/00:02:59, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Tunnel0, Forward/Sparse-Dense, 00:20:55/00:00:00
(10.1.1.1, 10.224.1.1), 02:40:32/00:03:29, flags: TA
Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:
Tunnel0, Forward/Sparse-Dense, 00:20:55/00:00:00
ip22-75b#show ip mroute 10.224.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 10.224.1.1), 02:42:20/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Tunnel0, Forward/Sparse-Dense, 00:22:53/00:00:00
Ethernet1/4, Forward/Sparse-Dense, 02:42:20/00:00:00
(10.1.1.1, 10.224.1.1), 00:22:53/00:02:59, flags: CT
Incoming interface: Tunnel0, RPF nbr 10.6.1.1, Mroute
Outgoing interface list:
Ethernet1/4, Forward/Sparse-Dense, 00:22:53/00:00:00
Afin de vérifier que les données de multidiffusion sont équilibrées de manière égale sur les trois liaisons, examinez les données d'interface du routeur 75a.
L'interface d'entrée a 9000 octets/sec :
ip22-75a#show interface e0/0 . . 5 minute input rate 9000 bits/sec, 20 packets/sec
Les trois interfaces de sortie montrent chacune 3000 octets/sec :
ip22-75a#show interface e0/1 . . 5 minute output rate 3000 bits/sec, 7 packets/sec ip22-75a#show interface e0/2 . . 5 minute output rate 3000 bits/sec, 7 packets/sec ip22-75a#show interface e0/3 . . 5 minute output rate 3000 bits/sec, 7 packets/sec
Lorsque vous recevez les messages d'erreur IP Multicast "INVALID_RP_JOIN" sur le routeur
Cette section fournit des solutions au problème courant du message d'erreur de Multicast IP du « INVALID_RP_JOIN ».
Diagnostiquer le problème - Partie 1
Ce message d'erreur est reçu sur le point de rendez-vous (RP) :
00:55:15: %PIM-6-INVALID_RP_JOIN: Received (*, 10.224.1.1) Join from 10.1.6.2 for invalid RP 10.1.5.4 00:56:15: %PIM-6-INVALID_RP_JOIN: Received (*, 10.224.1.1) Join from 10.1.6.2 for invalid RP 10.1.5.4
Le document Messages d'erreur système du logiciel Cisco IOS explique ce qui cause cette erreur : un routeur PIM en aval a envoyé un message de jointure pour l'arborescence partagée, que ce routeur ne veut pas accepter. Ce comportement indique que ce routeur permet seulement à des routeurs en aval de se connecter à un RP spécifique.
Il est suspecté d'être en cours de filtrage. Vous devez examiner la configuration du routeur :
interface Ethernet0/0 ip address 10.1.5.4 255.255.255.0 ip pim sparse-dense-mode ! ip pim accept-rp 10.2.2.2 8 ip pim send-rp-announce Ethernet0/0 scope 15 ip pim send-rp-discovery scope 15 ! access-list 8 permit 224.0.0.0 0.255.255.255
Quel est le accept-rp dans la configuration supposée accomplir ? Dans IP Multicast Routing Commands, il est indiqué que « pour configurer un routeur pour accepter les jointures ou les pruneaux destinés à un RP spécifié et à une liste spécifique de groupes, utilisez la commande ip pim accept-rp . Pour supprimer ce contrôle, n'utilisez l'aucune forme de cette commande. »
Lorsque vous supprimez le ip pim accept-rp , les messages disparaissent. La commande à l'origine du problème a été trouvée, mais que faire si vous souhaitez conserver cette commande dans la configuration ? Vous pouvez autoriser la mauvaise adresse RP. Saisissez la commande show ip pim rp mapping afin de voir l'adresse RP correcte :
ip22-75a#show ip pim rp mapping
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)
This system is an RP-mapping agent
Group(s) 224.0.0.0/4
RP 10.1.5.4 (?), v2v1
Info source: 10.1.5.4 (?), via Auto-RP
Uptime: 01:00:48, expires: 00:02:07
D'après le résultat, 10.1.5.4 est le seul RP appris via Auto-RP ou autrement. Cependant, ce routeur est seulement le RP pour les groupes 224.0.0.0/4. Donc, la pim accept-rp dans la configuration est incorrecte.
Correctifs possibles
La solution consiste à corriger l'adresse IP dans le ip pim accept-rp comme suit :
Modifiez cette instruction
ip pim accept-rp 10.2.2.2 8
:
ip pim accept-rp 10.1.5.4 8
Vous pouvez également modifier l'instruction pour accepter ce qui se trouve dans le cache auto-rp et vous assurer que la liste d'accès (8 dans cet exemple) autorise la plage de groupes de multidiffusion nécessaire. Voici un exemple :
ip pim accept-rp auto-rp access-list 8 permit 224.0.0.0 0.255.255.255
Diagnostiquer le problème - Partie 2
Ce message d'erreur est visible sur le router2.
router2#
*Aug 12 15:18:17.891:
%PIM-6-INVALID_RP_JOIN: Received (*, 224.0.1.40)
Join from 0.0.0.0 for invalid RP 10.2.1.1
Vérifiez si le router2 est le RP pour le groupe 10.224.1.1 :
router2#show ip pim rp map
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 10.1.1.1 (?), v2v1
Info source: 10.1.1.1 (?), elected via Auto-RP
Uptime: 00:21:26, expires: 00:02:24
router2#
Le RP pour 10.224.1.1 est 10.1.1.1.
Vérifiez si c'est l'une des interfaces de router2 :
router2#show ip interface brief Interface IP-Address OK? Method Status Protocol Ethernet0/0 10.1.1.2 YES NVRAM up up Ethernet1/0 10.2.1.1 YES NVRAM up up Ethernet2/0 unassigned YES NVRAM administratively down down router2#
Comme le routeur 2 n’est pas un RP, il ne doit pas avoir reçu ce paquet RP-Join. Vérifiez pourquoi le routeur en aval a envoyé l’instruction Join à router2, alors qu’il ne doit pas :
router3#show ip pim rp map
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 10.1.1.1 (?), v2v1
Info source: 10.1.1.1 (?), elected via Auto-RP
Uptime: 00:24:30, expires: 00:02:16
Group(s): 224.0.0.0/4, Static-Override
RP: 10.2.1.1 (?)
router3#
Comme vous le voyez, le routeur 3 a configuré de manière statique les informations RP et pointe vers le routeur 2, ce qui est incorrect. Ceci explique pourquoi le routeur 3 envoie une jointure RP-Join au routeur 2.
Correctifs possibles
Faites du router2 le RP pour le groupe 10.224.1.1 ou modifiez la configuration sur router3 de sorte qu'il se rapporte à l'adresse correcte RP.
router3#show run | i rp ip pim rp-address 10.2.1.1 override router3#configure terminal Enter configuration commands, one per line. End with CNTL/Z. router3(config)#no ip pim rp-address 10.2.1.1 override router3(config)#exit router3#
Une fois la configuration sur le routeur 3 corrigée, le routeur 3 se réfère à l’adresse RP correcte et le message d’erreur s’arrête.
router3#show ip pim rp map
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 10.1.1.1 (?), v2v1
Info source: 10.1.1.1 (?), elected via Auto-RP
Uptime: 00:30:45, expires: 00:02:02
router3#
Le CGMP ne prévient pas la pléthore de paquets de multidiffusion
Cette section explique comment l'engorgement par paquets de multidiffusion non désiré peut se produire quand le protocole de gestion de groupe Cisco (CGMP) n'est pas activé sur tous les routeurs d'un sous-réseau particulier, et comment ce problème peut être évité. Ce schéma de réseau est utilisé comme exemple.
Le protocole CGMP (Cisco Group Management Protocol) n'est pas activé
diagnostic du problème
Dans la figure, la table CAM statique du commutateur Catalyst 5000 A n'affiche aucun des ports corrects qui sont remplis. Le routeur configuré Cgmp n'envoie pas des paquets CGMP.
Le CGMP est correctement configuré avec le set cgmp enable sur le commutateur A et la commande ip cgmp sur l’interface E0/2 du routeur 75a. Cependant, aucun groupe de multidiffusion n’est visible sur le commutateur A lorsque show multicast group est exécutée :
Console> (enable) show multicast group CGMP enabled IGMP disabled IGMP fastleave disabled GMRP disabled VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- Total Number of Entries = 0
La sortie de cette commande doit afficher chaque port sur lequel se trouve un routeur configuré CGMP (port 2/3) et chaque port sur lequel se trouve un récepteur intéressé (port 2/6). Puisque 0 est répertorié, vous pouvez supposer que tous les ports sont inondés inutilement de trafic de multidiffusion, qu'ils le veuillent ou non.
Observations
Vérifiez s'il y a des voisins multicast indépendants du protocole (PIM) sur le routeur 75a :
ip22-75a#show ip pim neighbor PIM Neighbor Table Neighbor Address Interface Uptime Expires Ver Mode 10.2.1.1 Ethernet0/2 00:07:41 00:01:34 v2
Le résultat montre que le routeur 75a peut voir le routeur 75b comme un voisin PIM valide via le commutateur A.
Vérifiez maintenant si vous recevez les informations correctes de route de multidiffusion (mroute) sur les routeurs :
ip22-75a#show ip mroute 10.224.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 10.224.1.1), 00:14:55/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/2, Forward/Sparse-Dense, 00:14:55/00:00:00
(10.1.1.1, 10.224.1.1), 00:14:56/00:02:59, flags: CTA
Incoming interface: Ethernet0/1, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/2, Forward/Sparse-Dense, 00:14:56/00:00:00
Le résultat montre que le routeur 75a transfère les paquets de multidiffusion vers E0/2 vers le commutateur A. Cette sortie montre que le routeur 75b obtient les paquets de multidiffusion et les transfère correctement :
ip22-75b#show ip mroute 10.224.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 10.224.1.1), 00:17:57/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet1/3, Forward/Sparse-Dense, 00:17:57/00:00:00
Ethernet1/4, Forward/Sparse-Dense, 00:17:57/00:00:00
(10.1.1.1, 10.224.1.1), 00:00:35/00:02:59, flags: CTA
Incoming interface: Ethernet1/3, RPF nbr 10.2.1.2
Outgoing interface list:
Ethernet1/4, Forward/Sparse-Dense, 00:00:35/00:00:00
Du point de vue du commutateur A, vous voyez que le routeur 75a se trouve sur le port 2/3.
Console> (enable) show multicast router CGMP enabled IGMP disabled IGMP fastleave disabled Port Vlan --------- ---------------- 2/3 6 Total Number of Entries = 1
Jusqu'ici, tout semble être en ordre. Saisissez des debug sur le routeur 75a afin de voir ce que vous pouvez découvrir :
ip22-75a#debug ip cgmp CGMP debugging is on *Feb 8 12:45:22.206: CGMP: Sending self Join on Ethernet0/2 *Feb 8 12:45:22.206: GDA 0000.0000.0000, USA 00d0.ff2f.a002 *Feb 8 12:46:22.234: CGMP: Sending self Join on Ethernet0/2 *Feb 8 12:46:22.234: GDA 0000.0000.0000, USA 00d0.ff2f.a002 *Feb 8 12:47:22.262: CGMP: Sending self Join on Ethernet0/2 *Feb 8 12:47:22.262: GDA 0000.0000.0000, USA 00d0.ff2f.a002
Dans le résultat, 0000.0000.0000 est l'adresse de tous les groupes et est utilisée lorsque les routeurs envoient des messages CGMP Join/Leave afin que les commutateurs puissent remplir les ports du routeur. GDA représente l'adresse de destination de groupe dans le format de niveau de contrôle d'accès au support (MAC) et USA est l'acronyme de Unicast Source Address. Il s'agit de l'adresse de l'hôte à l'origine du rapport IGMP pour lequel ce message CGMP est généré. Dans ce cas, c'est l'adresse MAC pour l'interface E0/2 du routeur 75a. L’adresse MAC de l’interface E0/2 du routeur 75a est visible avec la show interface comme indiqué ici :
ip22-75a#show interface e0/2 Ethernet0/2 is up, line protocol is up Hardware is cxBus Ethernet, address is 00d0.ff2f.a002 (bia 00d0.ff2f.a002)
En outre, vous pouvez régulièrement le voir lorsque le debug ip igmp est activée :
*Feb 8 12:51:41.854: IGMP: Received v2 Report from 10.2.1.3 (Ethernet0/2) for 10.224.1.1
Cependant, vous ne pouvez pas voir ultérieurement un paquet CGMP correspondant du routeur 75a. Cela signifie que le routeur 75a reçoit des rapports IGMP, mais ne génère pas les paquets CGMP nécessaires pour aider le commutateur A à savoir quels ports bloquer. C'est ce qui serait prévu du routeur 75a si c'est le requérant d'IGMP. Ce résultat du routeur 75a nous indique pourquoi le comportement attendu ne se produit pas :
ip22-75a#show ip igmp interface e0/2 Ethernet0/2 is up, line protocol is up Internet address is 10.2.1.2/24 IGMP is enabled on interface Current IGMP version is 2 CGMP is enabled IGMP query interval is 60 seconds IGMP querier timeout is 120 seconds IGMP max query response time is 10 seconds Last member query response interval is 1000 ms Inbound IGMP access group is not set IGMP activity: 3 joins, 1 leaves Multicast routing is enabled on interface Multicast TTL threshold is 0 Multicast designated router (DR) is 10.2.1.2 (this system) IGMP querying router is 10.2.1.1 No multicast groups joined
Si vous avez deux routeurs sur le même sous-réseau et que vous configurez les deux pour CGMP, un seul peut envoyer des paquets CGMP. Le routeur qui envoie les paquets CGMP est l'IGMP qui interroge le routeur. Ceci signifie le routeur avec la plus basse adresse IP de monodiffusion des routeurs prenant en charge l'IGMP.
Dans ce cas, les routeurs 75a et 75b prennent en charge IGMP (le routeur 75b est devenu le routeur auteur de la requête IGMP), mais seulement le routeur 75a prend en charge le CGMP. Puisque le routeur 75a n'est pas le routeur d'interrogation IGMP, aucun paquet CGMP n'est envoyé.
Correctifs possibles
Afin de résoudre le problème, vous devez configurer CGMP sur le routeur d'interrogation IGMP. Dans ce cas, routeur 75b. Tout d'abord, activez debug sur le routeur 75b :
ip22-75b#conf t Enter configuration commands, one per line. End with CNTL/Z. ip22-75b(config)#int e 1/3 ip22-75b(config-if)#ip cgmp ip22-75b(config-if)#end ip22-75b#debug ip cgmp ip22-75b#debug ip igmp *Feb 8 12:58:42.422: IGMP: Received v2 Report from 10.2.1.3 (Ethernet1/3) for 10.224.1.1 *Feb 8 12:58:42.422: CGMP: Received IGMP Report on Ethernet1/3 *Feb 8 12:58:42.422: from 10.2.1.3 for 10.224.1.1 *Feb 8 12:58:42.422: CGMP: Sending Join on Ethernet1/3 *Feb 8 12:58:42.422: GDA 0100.5e01.0101, USA 0030.b655.a859
Le routeur 75b reçoit un rapport IGMP de 10.2.1.3 pour le groupe 10.224.1.1. Il envoie ultérieurement une demande de connexion CGMP au commutateur A pour l'équivalent MAC de 10.224.1.1 avec l'adresse MAC (USA) de l'hôte intéressé 10.2.1.3. Le commutateur A sait quel port qui est l'hôte est allumé et le marque comme ouvert et bloque les autres.
Les choses doivent maintenant fonctionner sur le commutateur A :
Console> (enable) show multicast group CGMP enabled IGMP disabled IGMP fastleave disabled GMRP disabled VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- 6 01-00-5e-00-01-28 2/3-4 6 01-00-5e-01-01-01 2/3-4,2/6 Total Number of Entries = 2
C'est bien mieux. Les paquets 10.224.1.1 (01-00-5e-01-01-01) sont envoyés uniquement par les ports 2/3, 2/4 et 2/6 du commutateur A, comme ils le devraient. L'inondation des autres ports a arrêté. Le nombre total d'entrées est maintenant listé correctement comme 2. L'adresse MAC 01-00-5e-00-01-28 est mappée de l'adresse de multidiffusion 224.0.1.40 utilisée pour les connexions automatiques de CGMP.
Le CGMP n'empêche pas l'engorgement par paquets de multidiffusion, dû à emplacement de source/récepteur
Cette section fournit une solution au problème courant d'un commutateur Catalyst qui inonde le trafic vers chaque port, au lieu de simplement vers l'hôte correct. Ce schéma de réseau est utilisé comme exemple.
Commutateur Catalyst qui inonde le trafic vers chaque port
diagnostic du problème
Dans la figure, les routeurs 75a et 75b et le Catalyst 5000 (commutateur A) sont correctement configurés pour la multidiffusion et le protocole CGMP (Cisco Group Management Protocol). L’hôte reçoit le trafic de multidiffusion. Cependant, tous les autres hôtes du commutateur A le sont également. Le commutateur A diffuse le trafic par tous les ports, ce qui signifie que le protocole CGMP ne fonctionne pas.
Le résultat de la commande show multicast group sur le commutateur A ressemble à ceci :
Console> (enable) show multicast group CGMP enabled IGMP disabled IGMP fastleave disabled GMRP disabled VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- 6 01-00-5e-00-01-28 2/3-4 Total Number of Entries = 1
Vous pouvez voir dans le résultat que le seul groupe est 224.0.1.40, qui est utilisé par le routeur quand il envoie des autojointures CGMP pour le groupe auto-RP. Comment se fait-il qu'il n'y ait aucun autre groupe ?
Correctifs possibles
Afin de comprendre la solution, vous devez comprendre comment CGMP se comporte dans certaines conditions. Un routeur compatible CGMP envoie des jointures CGMP à un commutateur pour informer le commutateur des hôtes intéressés par un groupe de multidiffusion particulier. Le commutateur consulte les adresses MAC pour ces hôtes dans son tableau CAM, transfère alors des paquets de multidiffusion vers les ports avec des hôtes intéressés et bloque le transfert de tous les autres ports des paquets de multidiffusion.
Un routeur envoie une interface prenant en charge des connexions automatiques CGMP d'une interface prenant en charge le CGMP s'il reçoit des paquets de multidiffusion d'une source qui est sur la même interface que celle où le CGMP est pris en charge.
Par exemple, si la source était sur le même sous-réseau (VLAN), 10.2.1.0/24, que les routeurs 75a et 75b, CGMP fonctionnerait parfaitement. Le routeur, lorsqu'il identifie les paquets à partir de la source, envoie une auto-jointure CGMP au commutateur, qui apprend alors dynamiquement sur quels ports le routeur est et bloque tous les autres ports de transmettre des paquets de multidiffusion.
Un routeur envoie les demandes de connexion CGMP à une interface prenant en charge CGMP si elle reçoit des rapports IGMP d'un hôte sur la même interface que celle où le CGMP est pris en charge.
Un autre exemple est si vous aviez un hôte intéressé sur ce même VLAN. Dans ce cas, lorsqu'un routeur compatible CGMP reçoit un rapport IGMP (Internet Group Management Protocol) d'un hôte intéressé par un groupe de multidiffusion particulier, le routeur envoie une jointure CGMP. La demande de connexion indiquerait l'adresse de contrôle d'accès au support (MAC) de l'hôte qui a voulu se connecter et du groupe auquel il a voulu se connecter. Le Catalyst 5000 vérifierait alors sa table CAM pour l'adresse MAC hôte, placerait le port associé sur la liste de groupes de multidiffusion et bloquerait tous les autres ports non intéressés.
Il n'en va pas de même lorsque la source et le ou les hôtes intéressés se trouvent sur un sous-réseau autre que le sous-réseau activé par CGMP (VLAN). Les paquets de multidiffusion, qui proviennent de la source, ne déclenchent pas le routeur pour envoyer des autojointures CGMP au commutateur. Par conséquent, les paquets frappent le commutateur et inondent tout le VLAN. Ce scénario se poursuit jusqu'à ce qu'un hôte du VLAN, qui se ferme sur un port du commutateur, envoie une jointure IGMP. Seulement avec la réception d'un rapport IGMP, le routeur enverra un paquet CGMP, et le commutateur ajoutera alors le port hôte approprié comme port transférant et tous les autres sont bloqués (hormis les ports du routeur).
Pour que le CGMP fonctionne dans cette topologie de type transit, vous pouvez ajouter un hôte au même VLAN que les routeurs 75a et 75b, comme dans ce schéma de réseau.
Ajouter un hôte au même VLAN que les routeurs 75a et 75b
Ou alors vous pouvez déplacer la source sur le même sous-réseau que les routeurs 75a et 75b, comme dans cet exemple.
Déplacez la source sur le même sous-réseau que les routeurs 75a et 75b
Déplacez la source au même sous-réseau, puis vérifiez le résultat du commutateur A :
Console> (enable) show multicast router CGMP enabled IGMP disabled IGMP fastleave disabled Port Vlan --------- ---------------- 2/3 6 2/4 6 Total Number of Entries = 2 '*' - Configured Console> (enable) Console> (enable) show multicast group CGMP enabled IGMP disabled IGMP fastleave disabled GMRP disabled VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- 6 01-00-5e-00-01-28 2/3-4 6 01-00-5e-01-01-01 2/3-4 Total Number of Entries = 2
Le CGMP n'empêche pas l'engorgement par paquets de multidiffusion pour certaines adresses de groupe
Cette section explique pourquoi quelques adresses IP multicast causent l'inondation du trafic multidiffusion de tous les ports sur un LAN par le protocole de gestion de groupe Cisco. Lorsque vous utilisez l'adresse de groupe de multidiffusion 10.225.0.1, CGMP ne fonctionne pas. Il inonde le flux multidiffusion de tous les ports de commutation et gaspille la largeur de bande. Cependant, si vous modifiez l'adresse à 10.225.1.1, CGMP fonctionnera correctement. Pouvez-vous utiliser 10.225.0.1 car il ne s’agit pas d’une adresse enregistrée pour un protocole de routage ?
Correctifs possibles
D'abord, il est important de comprendre comment des adresses de multidiffusion de niveau 3 sont mappées pour les adresses de multidiffusion de niveau 2. Toutes les trames de multidiffusion IP utilisent des adresses de couche MAC IEEE commençant par le préfixe 24 bits 0x0100.5e. Lorsque vous mappez des adresses de couche 3 à des adresses de couche 2, les 23 bits de poids faible de l'adresse de multidiffusion de couche 3 sont mappés sur les 23 bits de poids faible de l'adresse MAC IEEE.
Il est également important de comprendre qu’il existe 28 bits d’espace d’adressage unique pour une adresse de multidiffusion IP (32 bits moins les 4 premiers bits qui contiennent le préfixe de classe D 1110). Puisqu'il y a seulement 23 bits branchés à l'adresse MAC d'IEEE, 5 bits de superposition demeurent. Ceci signifie que plusieurs adresses de niveau 3 de multidiffusion peuvent mapper à la même adresse de multidiffusion de niveau 2.
Exemple :
10.244.0.1 = 1110 0000.0000 0000.0000 0000.0000 0001 in binary low order 23 bits = 000 0000.0000 0000.0000 0001 hex equivalent = 0 0 0 0 0 1 result of mapping = 0x0100.5e00.0001 10.244.128.0 = 1110 0000.1000 0000.0000 0000.0000 0001 in binary low order 23 bits = 000 0000.0000 0000.0000 0001 hex equivalent = 0 0 0 0 0 1 result of mapping = 0x0100.5e00.0001
Notez que dans l'exemple, 10.244.0.1 et 10.244.128.0 correspondent à la même adresse de multidiffusion de couche 2.
Maintenant que vous savez comment les adresses de multidiffusion de couche 3 à couche 2 sont mappées, passez à la solution spécifique à ce problème.
Le commutateur A diffuse des paquets de multidiffusion vers 224.0.0.x, car ces adresses sont link-local et vous voulez vous assurer que les adresses link-local parviennent à tous les périphériques sur le réseau local (LAN). Les commutateurs Catalyst inondent également des paquets de multidiffusion à d'autres adresses de multidiffusion qui sont ambiguës de niveau avec 224.0.0.x (par exemple, 10.244.0.1 et 10.225.0.1 mappent les deux à 0100.5e00.0001). Le commutateur inonde ces adresses de liaison locales de paquets de multidiffusion que le CGMP soit activé ou non.
Par conséquent, l'application multidiffusion doit éviter l'utilisation des adresses de la classe D qui mappent à une adresse de multidiffusion de niveau 2 de 0100.5e00.00xx, où xx peut être 00 à FF en hexadécimales. Ceci se compose de ces adresses de la classe D :
224.0.0.x (x = 0 to 255) 225.0.0.x . 239.0.0.x 224.128.0.x (x = 0 to 255) 225.128.0.x . 239.128.0.x
Des paquets de multidiffusion sont reçus en double
Cause 1
Des paquets de multidiffusion sont reçus en double quand deux routeurs sont configurés en mode dense. En mode dense, le périphérique inonde périodiquement le flux. Après l'inondation, il taille des interfaces où le flux n'est pas souhaité. Les deux routeurs passent également par le processus d'assertion et décident qui est l'expéditeur. Chaque fois que les minuteurs se désactivent, et jusqu’à ce que ce processus soit terminé, les deux routeurs transfèrent le flux. A cause de cela, l'application reçoit les flux multidiffusion en double.
Correctif possible 1
Ce problème peut être résolu si vous avez un des routeurs configurés pour le routage multicast et l'autre routeur pour être le RP en amont. Configurez-le afin de convertir le flux en mode intermédiaire avant que le flux n'entre dans le routeur. Ceci pour éviter que les paquets en double atteignent l'application. Ce n'est pas une la responsabilité de réseaux de garantir qu'il n'y a pas de paquet en double atteignant un hôte d'extrémité. C'est la responsabilité de l'application de prendre en charge des paquets en double et d'ignorer des données inutiles.
Cause 2
Ce problème peut se produire dans des commutateurs de Cisco Catalyst 6500, qui sont configurés pour le mode de réplication multicast de sortie. Il peut être déclenché par suppression et réinsertion de toutes les cartes de ligne [OIR]. Après OIR, le port de sortie du fabric [FPOE] peut être mal programmé, ce qui peut entraîner la direction des paquets vers le mauvais canal de sortie du fabric et leur envoi vers les mauvaises cartes de ligne. Le résultat est une boucle de retour à la structure et une réplication multiple quant ils sortent sur la carte correcte.
C6509#show mls ip multicast capability
Current mode of replication is Egress
Auto replication mode detection is ON
Slot Multicast replication capability
1 Egress
2 Egress
3 Egress
4 Egress
5 Egress
6 Egress
7 Egress
Correctif possible 2
Comme solution, modifiez le mode de réplication en entrée. Pendant une modification de réplication de sortie au mode réplication en entrée, des interruptions du trafic peuvent se produire parce que les raccourcis sont purgés et réinstallés.
mls ip multicast replication-mode ingress
Mettez à niveau le logiciel Cisco IOS vers une version non affectée par l'ID de bogue Cisco CSCeg2814 afin de résoudre le problème de manière permanente.
Remarque : seuls les utilisateurs Cisco enregistrés ont accès aux outils Cisco internes et aux informations de bogue.
Cause 3
Ce problème peut également se produire si le paramètre Receive Side Scaling (RSS), sur les hôtes finaux ou les serveurs, est désactivé.
Correctif possible 3
Le paramètre RSS facilite une transmission plus rapide des données à travers plusieurs processeurs. Activez le paramètre RSS sur l'hôte final ou le serveur.
Pourquoi est-ce que des paquets de multidiffusion sont déposés ?
Cause 1
Il est possible que vous voyiez les vidages excessifs et les pertes de paquets d'entrée sur la ou les interfaces lorsque le trafic multidiffusion circule. Vous pouvez vérifier les vidages à l'aide du show interface erasecat4000_flash:.
Switch#show interface gi 1/0
!--- Output suppressed
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, media type is SX
input flow-control is off, output flow-control is on
Clock mode is auto
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 2/75/0/13370328 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
30 second input rate 195000 bits/sec, 85 packets/sec
30 second output rate 1000 bits/sec, 1 packets/sec
L2 Switched: ucast: 53056 pkt, 4728434 bytes - mcast: 235759386 pkt, 66914376970 bytes
L3 in Switched: ucast: 8714263 pkt, 1815426423 bytes - mcast: 1081138213 pkt,
438000092206 bytes mcast
L3 out Switched: ucast: 4939256 pkt, 790351689 bytes mcast: 0 pkt, 0 bytes
1326976857 packets input, 506833655045 bytes, 0 no buffer
Received 1318209538 broadcasts, 0 runts, 0 giants, 1 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
31643944 packets output, 3124494549 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
Correctif possible 1
Vous pouvez définir la valeur SPT comme mesure infinie pour l'interface où les inondations excessives se produisent.
Configurez ceci :
Switch(config-if)#ip pim spt-threshold infinity
Cause 2
Lorsque vous utilisez le ip igmp join-group
sur n'importe quelle interface, il effectue la commutation de processus. Si les paquets de multidiffusion sont commutés par processus sur une ou plusieurs interfaces, il consomme plus de CPU car il exige la commutation de processus de tous les paquets vers ce groupe. Vous pouvez exécuter la commande show buffers input-interface et vérifiez la taille anormale.
Switch#show buffers input-interface gi 1/0 Header DataArea Pool Rcnt Size Link Enc Flags Input Output 437C6EAC 8096AE4 Middl 1 434 7 1 280 Gi1/1 None 437C74B4 8097864 Middl 1 298 7 1 280 Gi1/1 None 437C98E4 809C964 Middl 1 434 7 1 280 Gi1/1 None 437CAAFC 809F1E4 Middl 1 349 7 1 280 Gi1/1 None 437CAE00 809F8A4 Middl 1 519 7 1 280 Gi1/1 None !--- Output suppressed
Correctif possible 2
Vous pouvez utiliser la ip igmp static-group
au lieu de la commande ip igmp join-group
erasecat4000_flash:.
Informations connexes
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
2.0 |
26-May-2023 |
Recertification |
1.0 |
02-Dec-2013 |
Première publication |
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)