Guide de dépannage de la multidiffusion IP

Entrez d'autres commandes debug :

ip22-72a#debug ip mpacket 224.1.1.1 
*Jan 14 09:45:32.972: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.020: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.072: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.120: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.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.

Remarque : le débogage des paquets est dangereux. Le débogage des paquets déclenche la commutation de processus des paquets de multidiffusion, qui sollicite énormément le processeur. En outre, le débogage de paquets peut produire un résultat énorme et encombrer le routeur complètement devant parce que la sortie vers le port de console est lente. Avant de déboguer des paquets, une attention particulière doit être apportée afin de désactiver la sortie de journalisation vers la console et d'activer la journalisation dans la mémoire tampon. Afin de réaliser ceci, configurez le no logging console et le logging buffered debugging. Les résultats du débogage peuvent être consultés avec la commande de show logging.

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 correct, 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 224.1.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 (*, 224.1.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, 224.1.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 224.1.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: 224.1.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 224.1.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: 224.1.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 224.1.1.1 *Jan 14 10:18:29.951: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward *Jan 14 10:18:29.999: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward *Jan 14 10:18:30.051: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.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   show ip mroute  la commande 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 (*, 224.1.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 l'adresse 224.0.1.40 dans le résultat, car tous les routeurs rejoignent ce groupe de détection Auto-RP. Mais il n'y a aucune source listée pour 224.1.1.1. En plus de « *, 224.1.1.1 », vous ne pouvez pas voir « 10.1.1.1, 224.1.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 la commande suivanteshow ip pim interface :

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 le trafic actif à l’aide de la commandeshow ip mroute active suivante :

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 224.1.1.1. Vous pouvez le vérifier avec 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 224.1.1.1 Ethernet1/2 00:30:02 00:02:45 10.3.1.2 

224.1.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 la 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 (*, 224.1.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, 224.1.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 (*, 224.1.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, 224.1.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 224.1.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 (*, 224.1.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, 224.1.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-le 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 224.1.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=224.1.1.1 len 60, threshold denied *Jan 17 09:04:08.762: IP: s=10.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied *Jan 17 09:04:08.814: IP: s=10.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied

Les debug 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.

La ip multicast ttl-threshold <value> commande 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 la ip multicast ttl-threshold <value> commande 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 224.1.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 (*, 224.1.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, 224.1.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 224.1.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 (*, 224.1.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, 224.1.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.

Remarque : avant de charger le trafic multicast IP partagé sur des chemins à coût égal sur un tunnel, configurez l'équilibrage de charge CEF par paquet ou sinon les paquets GRE ne peuvent pas être équilibrés par paquet. Pour d'autres méthodes de partage de charge dans des environnements de multidiffusion, consultez Load Splitting IP Multicast Traffic over ECMP.

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.

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

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 commandeshow ip mroute afin de voir la route de multidiffusion (mroute) pour le groupe :

ip22-75a#show ip mroute 224.1.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 (*, 224.1.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, 224.1.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 224.1.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 (*, 224.1.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, 224.1.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 (*, 224.1.1.1) Join from 10.1.6.2 for invalid RP 10.1.5.4 00:56:15: %PIM-6-INVALID_RP_JOIN: Received (*, 224.1.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 

Quelle est l’ accept-rp  instruction de la configuration censée accomplir ? ip pim accept-rp Dans IP Multicast Routing Commands, il est indiqué que « pour configurer un routeur afin qu'il accepte les jonctions ou les pruneaux destinés à un RP spécifié et à une liste spécifique de groupes, utilisez la commande de configuration globale ». Pour supprimer ce contrôle, n'utilisez l'aucune forme de cette commande. »

Lorsque vous supprimez cette ip pim accept-rp commande, 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. Entrez la show ip pim rp mapping  commande 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. Ainsi, l' pim accept-rp instruction de la configuration est incorrecte.

Correctifs possibles

La solution consiste à corriger l'adresse IP dans l'ip pim accept-rp instruction 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 224.1.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 224.1.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 224.1.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#

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 de la commandeshow interface .

Switch#show interface gigabitethernet 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 la commandeip igmp join-group <group-name> sur une ou plusieurs interfaces, elle 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 show buffers input-interface commande et vérifier la taille anormale.

Switch#show buffers input-interface gigabitethernet 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 commandeip igmp static-group <group-name> à la place de la commandeip igmp join-group <group-name>.

Remarque : en raison de problèmes précédents, il est possible que vous voyiez une utilisation élevée du processeur autour de 90 pour cent. Le processeur descend à la normale quand vous les résolvez le problème avec ces correctifs possibles.

Informations connexes

• Dépannage des réseaux multidiffusion avec les outils CLI
• Guide de configuration pour le démarrage rapide de la multidiffusion

• Activation du partage de charge multicast ECMP 

• Assistance pour la technologie multicast IP
• Assistance pour les protocoles de routage IP
• Assistance technique et téléchargements Cisco