Guía de Troubleshooting de IP Multicast

Ingrese algunos otros comandos 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

Los paquetes ingresan en E3/1, lo cual es correcto. Sin embargo, se descartan porque esa no es la interfaz que la tabla de ruteo unicast utiliza para la verificación RPF.

Nota: La depuración de paquetes es peligrosa. La depuración de paquetes activa la conmutación de los procesos de los paquetes de multidifusión, lo que hace un uso intensivo de la CPU. Además, la depuración de paquetes puede producir una salida enorme que puede colgar el router completamente debido a la salida lenta al puerto de la consola. Antes de depurar paquetes, se debe tener especial cuidado para inhabilitar la salida de registro a la consola y habilitar el registro en el buffer de memoria. Para lograr esto, configure no logging console y logging buffered debugging. Los resultados de la depuración se pueden ver con el comando show logging.

Correcciones posibles

Puede cambiar la tabla de ruteo unicast para satisfacer este requisito o puede agregar una ruta multicast estática para forzar la salida de multicast a RPF en una interfaz particular, independientemente de lo que indique la tabla de ruteo unicast. Agregue una ruta multicast estática:

ip22-72a(config)#ip mroute 10.1.1.1 255.255.255.255 10.2.1.1

Esta ruta multicast estática establece que para llegar a la dirección 10.1.1.1 para RPF, utilice 10.2.1.1 como el salto siguiente que está fuera de la interfaz 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 

La salida de show ip mroute y debug ip mpacket parece buena, el número de paquetes enviados en el show ip mroute count aumenta y el HostA recibe paquetes.

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

El router no reenvía paquetes de multidifusión al host debido a la configuración TTL del origen

Esta sección proporciona una solución al problema común de los paquetes de multidifusión IP que no se reenvían porque el valor de Tiempo de vida (TTL) se reduce a cero. Este es un problema común, ya que hay muchas aplicaciones de multidifusión. Estas aplicaciones de multidifusión están diseñadas principalmente para el uso de LAN y, por lo tanto, establecen el TTL en un valor bajo o incluso en 1. Utilice este diagrama de red como ejemplo. 

Ejemplo de Aplicaciones Multicast Diseñadas Principalmente para el Uso de LAN

Diagnosticar el problema

En la figura anterior, el Router A no reenvía paquetes de origen(s) al Router B que está conectado directamente al Receptor. Observe el resultado del   show ip mroute  comando en el Router A para ver el estado de ruteo multicast:

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 

Puede ignorar el 224.0.1.40 en la salida ya que todos los routers se unen a este grupo de detección de RP automático. Pero no hay ningún origen enumerado para 224.1.1.1. Además de "*, 224.1.1.1", no puede ver "10.1.1.1, 224.1.1.1".

Ingrese el comando show ip rpf para ver si es un problema 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 

A partir de la salida, no es un problema de RPF. La verificación RPF señala correctamente E0/0 para llegar a la dirección IP de origen.

Verifique si PIM está configurado en las interfaces con el show ip pim interface comando:

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 

El resultado se ve bien, así que este no es el problema. Verifique si el router reconoce cualquier tráfico activo con el show ip mroute active comando:

ROUTERA#show ip mroute active Active IP Multicast Sources - sending >= 4 kbps 

Según el resultado, el router no reconoce ningún tráfico activo.

ROUTERA#debug ip mpacket IP multicast packets debugging is on 

Es posible que el receptor no envíe ningún informe de protocolo de administración de grupos de Internet (IGMP) (uniones) para el grupo 224.1.1.1. Puede verificarlo con el show ip igmp group  comando:

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 se ha incorporado en E1/2, lo cual está bien.

El modo PIM denso es un protocolo de saturación y separación, por lo que no hay incorporaciones pero sí injertos. Dado que el Router B no ha recibido una inundación del Router A, no sabe a dónde enviar un injerto.

Puede verificar si se trata de un problema TTL con la captura del sabueso y también se ve con el show ip traffic  comando:

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 

El resultado muestra 63744 recuentos de saltos incorrectos. Cada vez que escribe este comando, el conteo de saltos incorrectos aumenta. Esta es una fuerte indicación de que el remitente envía paquetes con un TTL=1, que el router A reduce a cero. Esto resulta en un aumento del campo de conteo de saltos incorrectos.

Correcciones posibles

Para resolver el problema, debe aumentar el TTL. Esto se realiza en el nivel de aplicación del Remitente. Si desea obtener más información, consulte el manual de instrucciones de su aplicación de multidifusión.

Una vez hecho esto, el Router A se ve así:

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 

Este es el tipo de salida que desea ver.

En el router B, verá:

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

El router no reenvía paquetes de multidifusión debido al umbral TTL del router

Esta sección proporciona una solución al problema común donde el umbral TTL se establece en un valor demasiado bajo, de modo que el tráfico de multidifusión IP no llegue al receptor. Este diagrama de red se utiliza como ejemplo.

El umbral TTL es demasiado bajo para que el tráfico de multidifusión IP no llegue al receptor

Diagnosticar el problema

En la figura anterior, el Receptor no recibe paquetes multicast del Origen. Puede haber varios routers entre el origen y el router 75a. En primer lugar, observe el router 75a, ya que está conectado directamente al receptor.

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 

La salida muestra que el router 75a reenvía los paquetes fuera de Ethernet0/1. Para estar absolutamente seguro de que el Router 75a reenvía los paquetes, active debug sólo para este grupo de origen y multidifusión:

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

Los debug mensajes indican que el Router 75a no reenvía los paquetes multicast porque se ha alcanzado el umbral TTL. Observe la configuración del router para ver si puede encontrar la razón. Este resultado muestra al culpable:

interface Ethernet0/1 ip address 10.2.1.1 255.255.255.0 ip pim sparse-dense-mode ip multicast ttl-threshold 15 

El router tiene un umbral TTL de 15, pero esto no significa que no se envíe nada mayor que un TTL de 15. De hecho, se aplica lo contrario. La solicitud se envía con un TTL de 15. Para cuando llega al Router 75a, los paquetes multicast tienen un TTL inferior a 15.

El ip multicast ttl-threshold <value> comando significa que cualquier paquete con un TTL inferior al umbral especificado, en este caso, 15, no se reenvía. Este comando suele utilizarse para proporcionar un borde que impida que el tráfico de multidifusión interno salga de la intranet.

Correcciones posibles

Quite el ip multicast ttl-threshold <value> comando con la forma no de este comando, que vuelve al valor de umbral TTL predeterminado de 0, o baje el umbral TTL para que el tráfico pueda pasar.

Múltiples Trayectorias de Igual Costo Resultan en Comportamiento de RPF No Deseado

Esta sección muestra cómo las trayectorias de costo equivalente a un origen multicast pueden causar un comportamiento RPF no deseado. También describe cómo configurar la multidifusión IP para evitar este comportamiento. Este diagrama de red se utiliza como ejemplo.

Trayectorias de Coste Iguales a una Fuente Multicast Causan un Comportamiento RPF No Deseado

Diagnosticar el problema

En la figura, el Router 75b tiene tres trayectos de igual costo de regreso al Origen (10.1.1.1), y elige un link que no desea que sea su primera opción como el link RPF.

Cuando se enfrenta a múltiples trayectorias de igual costo a un origen, la multidifusión IP elige la interfaz que tiene un vecino de multidifusión independiente de protocolo (PIM) con la dirección IP más alta como la interfaz entrante y luego envía recortes a los vecinos de PIM en los otros links.

Correcciones posibles

Para cambiar la interfaz que IP Multicast elige como su interfaz entrante, puede realizar una de estas acciones:

• Sólo configure la PIM en las interfaces que quiere que atraviese la multidifusión. Esto significa que se pierde redundancia de multidifusión.

• Cambie las subredes para que la dirección IP más alta esté en el link que desea que sea el link multicast principal.

• Cree una ruta de multidifusión estática (mroute) que señale la interfaz de multidifusión preferida, lo que significa que pierde redundancia de multidifusión.

Por ejemplo, se crea una ruta multicast estática.

Antes de instalar una ruta multicast estática, verá en esta salida que la tabla de ruteo tiene tres rutas de igual costo para la dirección de origen 10.1.1.1. La información RPF indica que la interfaz RPF es 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 

Después de configurar la ruta multicast estática, verá en esta salida que la interfaz RPF ha cambiado a 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

¿Por qué la multidifusión IP no equilibra la carga en todas las rutas de igual coste disponibles?

Esta sección proporciona una solución al problema común de cómo configurar la multidifusión IP para equilibrar la carga en todas las trayectorias de igual costo disponibles. Este diagrama de red se utiliza como ejemplo.

Nota: Antes de cargar el tráfico multicast IP dividido a través de trayectos de igual costo a través de un túnel, configure el balanceo de carga CEF por paquete o los paquetes GRE no se pueden balancear por carga por paquete. Para ver otros métodos para compartir la carga en entornos de multidifusión, vea Load Splitting IP Multicast Traffic over ECMP.

Configuración de multidifusión IP para equilibrar la carga en todas las rutas de igual coste disponibles

En la figura, el router 75b tiene tres trayectorias de igual costo de regreso al origen (10.1.1.1). Desea equilibrar la carga del tráfico de multidifusión en los tres enlaces.

Correcciones posibles

Como vio en la sección Múltiples Trayectorias de Igual Costo Resultan en Comportamiento RPF No Deseado, Protocol Independent Multicast (PIM) solamente elige una interfaz para la verificación RPF y recorta las otras. Esto significa que no se produce el equilibrio de carga. Para lograr un equilibrio de carga, debe quitar el PIM de los links redundantes y crear un túnel entre el Router 75a y el Router 75b. Luego puede equilibrar la carga en el nivel de link y las ejecuciones de IP sobre el túnel.

Estas son las configuraciones para el túnel.

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

Después de configurar el túnel, ingrese el show ip mroute comando para ver la ruta multicast (mroute) para el grupo:

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 

Para verificar que los datos de multidifusión estén balanceados equitativamente en la carga a través de los tres links, observe los datos de interfaz del Router 75a.

La interfaz entrante es de 9000 bits/seg:

ip22-75a#show interface e0/0 . . 5 minute input rate 9000 bits/sec, 20 packets/sec 

Las tres interfaces salientes muestran cada una 3000 bits/seg:

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

Cuando recibe los mensajes de error "INVALID_RP_JOIN" de multidifusión IP en el router

Esta sección proporciona soluciones al problema común del mensaje de error "INVALID_RP_JOIN" de multidifusión IP.

Diagnóstico del problema - Parte 1

Este mensaje de error se recibe en el punto de encuentro (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 

El documento Mensajes de error del sistema del software Cisco IOS explica las causas de este error: un router PIM de flujo descendente envió un mensaje de unión para el árbol compartido, que este router no desea aceptar. Este comportamiento indica que este router solo permite que los routers de flujo descendente se unan a un RP específico.

Se sospecha que está filtrando. Debe echar un vistazo a la configuración del router:

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 

¿Qué se supone que debe lograr la accept-rp  instrucción de la configuración? En Comandos de Ruteo IP Multicast, indica que "para configurar un router para aceptar Uniones o Prunes destinados a un RP especificado y a una lista específica de grupos, utilice el ip pim accept-rp comando de configuración global. Para quitar esa comprobación, utilice la forma no de este comando."

Cuando se quita ip pim accept-rp el comando, los mensajes desaparecen. Se encontró el comando que causa el problema, pero ¿qué sucede si desea mantener ese comando en la configuración? Puede permitir la dirección RP incorrecta. Ingrese el show ip pim rp mapping  comando para ver la dirección RP correcta:

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

Según la salida , 10.1.5.4 es el único RP aprendido a través de RP automático o de otro modo. Sin embargo, este router es solamente el RP para los grupos 224.0.0.0/4. Por lo tanto, la pim accept-rp declaración de la configuración es incorrecta.

Correcciones posibles

La solución es corregir la dirección IP en la ip pim accept-rp declaración de la siguiente manera:

Cambie esta declaración:

ip pim accept-rp 10.2.2.2 8

Para ello:

ip pim accept-rp 10.1.5.4 8

También puede cambiar la sentencia para aceptar lo que está en la memoria caché de autorregulación de tráfico y asegurarse de que la lista de acceso (8 en este ejemplo) permite el rango de grupos de multidifusión necesario. Aquí tiene un ejemplo:

ip pim accept-rp auto-rp access-list 8 permit 224.0.0.0 0.255.255.255

Diagnóstico del problema - Parte 2

Este mensaje de error se ve en el 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

Verifique si el router 2 es el RP para el grupo 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#

El RP para 224.1.1.1 es 10.1.1.1.

Verifique si esta es una de las interfaces del 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#

Dado que el router 2 no es un RP, no debe haber recibido este paquete de unión RP. Verifique por qué el router de flujo descendente envió el Join to router2, mientras que no debe:

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#

Como puede ver, el router 3 ha configurado estáticamente la información RP y apunta al router 2, lo cual es incorrecto. Esto explica por qué el router 3 envía RP-Join al router 2.

Correcciones posibles

Haga que el router 2 sea el RP para el grupo 224.1.1.1 o cambie la configuración en el router 3 para que haga referencia a la dirección RP correcta.

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#

Después de corregir la configuración en el router3, el router3 se refiere a la dirección RP correcta y el mensaje de error se detiene.

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#

Se reciben flujos de paquetes de multidifusión duplicados

Causa 1

Los paquetes de multidifusión duplicados se reciben cuando dos routers se configuran en modo denso. En el modo denso, el dispositivo inunda periódicamente la secuencia. Después de la inundación, recorta las interfaces donde no se desea el vapor. Los dos routers también pasan por el proceso de aserción y deciden quién es el reenviador. Cada vez que los temporizadores se apagan esto sucede, y hasta que este proceso se complete, ambos routers reenvían la secuencia. Esto hace que la aplicación reciba secuencias de multidifusión duplicadas.

Posible corrección 1

Este problema se puede resolver si tiene uno de los routers configurados para el ruteo multicast y para configurar el otro router para que sea el RP en flujo ascendente. Configúrelo para convertir la secuencia en modo disperso antes de que la secuencia entre en el router. Esto puede evitar que los paquetes duplicados lleguen a la aplicación. Garantizar que ningún paquete duplicado llegue nunca a un host final no forma parte de la responsabilidad de las redes. Es parte de la responsabilidad de la aplicación manejar paquetes duplicados e ignorar datos innecesarios.

Causa 2

Este problema puede ocurrir en los switches Cisco Catalyst 6500, que están configurados para el modo de replicación multidifusión de salida y se pueden activar mediante la extracción y la reinserción de cualquier tarjeta de línea [OIR]. Después de OIR, el puerto de salida del fabric [FPOE] se puede programar erróneamente, lo que puede hacer que los paquetes se dirijan al canal de salida del fabric incorrecto y se envíen a las tarjetas de línea incorrectas. El resultado es que se vuelven a copiar en bucle en el fabric y se replican varias veces cuando salen de la tarjeta de línea correcta.

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

Posible corrección 2

Como solución alternativa, cambie al modo de replicación de entrada. Durante un cambio del modo de replicación de salida a entrada, pueden producirse interrupciones del tráfico porque los accesos directos se depuran y se reinstalan.

mls ip multicast replication-mode ingress 

Actualice el software Cisco IOS a una versión no afectada por el ID de bug Cisco CSCeg28814 para resolver el problema de forma permanente.

Nota: solo los usuarios registrados de Cisco tienen acceso a las herramientas internas de Cisco y a la información de errores.

Causa 3

Este problema también puede ocurrir si la configuración de Escala del lado de recepción (RSS), en los hosts finales o servidores, está inhabilitada.

Posible corrección 3

La configuración de RSS facilita una transmisión más rápida de datos a través de varias CPU. Habilite la configuración de RSS en el host final o el servidor.

¿Por qué se descartan los paquetes de multidifusión?

Causa 1

Es posible que vea los vaciados excesivos y las caídas de paquetes de entrada en las interfaces cuando fluye el tráfico de multidifusión. Puede verificar los vaciados con el show interface comando.

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

Posible corrección 1

Puede establecer el valor SPT como infinito para la interfaz donde se ven los vaciados excesivos.

Configure esto:

Switch(config-if)#ip pim spt-threshold infinity 

Causa 2

Cuando utiliza el ip igmp join-group <group-name> comando en cualquier interfaz, sí procesa la conmutación. Si los paquetes multicast son conmutados por proceso en cualquier interfaz, consume más CPU ya que exige la conmutación por proceso de todos los paquetes a ese grupo. Puede ejecutar el show buffers input-interface comando y comprobar el tamaño anormal.

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 

Posible corrección 2

Puede utilizar el ip igmp static-group <group-name> comando en lugar del ip igmp join-group <group-name> comando.

Nota: Debido a problemas anteriores, es posible que observe un uso elevado de la CPU de alrededor del 90%. La CPU baja a la normalidad cuando se resuelven con estas posibles correcciones.

Información Relacionada

• Solución de problemas de redes multidifusión con herramientas CLI
• Guía rápida de configuración para Multicast (Multidifusión)

• Habilitación de ECMP Multicast Load Splitting 

• Compatibilidad con tecnología de multidifusión IP
• Compatibilidad con IP Routing Protocols
• Asistencia técnica y descargas de Cisco