Guía de Troubleshooting de IP Multicast

Introducción

Este documento describe los problemas comunes y soluciones del IP multicast.

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware. 

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

Cuando resuelve problemas de ruteo multicast, la principal preocupación es la dirección de origen. La multidifusión tiene un concepto de verificación de Reverse Path Forwarding (RPF). Cuando un paquete multicast llega a una interfaz, el proceso RPF verifica que esta interfaz entrante sea la interfaz saliente utilizada por el ruteo unicast para alcanzar el origen del paquete multicast. Este proceso de verificación del RPF evita los loops. El ruteo multicast no reenvía un paquete a menos que el origen del paquete pase una verificación RPF. Una vez que un paquete pasa el control RPF, el ruteo multidifusión reenvía el paquete basándose sólo en la dirección de destino.

Al igual que el routing unidifusión, el routing multidifusión tiene varios protocolos disponibles, como el modo denso multidifusión independiente de protocolo (PIM-DM), el modo disperso de PIM (PIM-SM), el protocolo de routing multidifusión por vectores a distancia (DVMRP), el protocolo de gateway fronterizo multidifusión (MBGP) y el protocolo de transmisión de fuente multidifusión (MSDP). Los casos prácticos de este documento le guiarán a través del proceso de solución de diversos problemas. Puede ver qué comandos se utilizan para identificar rápidamente el problema y aprender a resolverlo. Los casos prácticos que se enumeran a continuación son genéricos para todos los protocolos, excepto cuando se indique lo contrario.

El Router No Reenvía Paquetes Multicast al Host Debido a una Falla RPF

Esta sección proporciona una solución al problema común de una falla de IP multicast RPF. Este diagrama de red se utiliza como ejemplo.

Diagrama de Red Ejemplo de Falla RPF Multicast

En esta figura, los paquetes multicast entran en E0/0 del Router 75a desde un servidor cuya dirección IP es 10.1.1.1 y los envía al grupo 10.224.1.1. Esto es conocido como un (S,G) o (10.1.1.1, 10.224.1.1).

Diagnosticar el problema

Los hosts conectados directamente al router 75a reciben la fuente de multidifusión, pero los hosts conectados directamente al router 72a no. En primer lugar, introduzca el show ip mroute 224.1.1.1  para verificar la actividad en el router 75a. Este comando examina la ruta multicast (mroute) para la dirección de grupo 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 

Dado que el router ejecuta el modo denso de PIM (ya sabe que es el modo denso debido al indicador D), ignore la entrada *,G y céntrese en la entrada S,G. Esta entrada indica que los paquetes multicast se originan en un servidor cuya dirección es 10.1.1.1, que envía a un grupo multicast de 10.224.1.1. Los paquetes entran en la interfaz Ethernet0/0 y se reenvían fuera de la interfaz Ethernet0/1. Este es un escenario perfecto.

Escriba el show ip pim neighbor para ver si el router 72a muestra el router ascendente (75a) como vecino 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 

Desde show ip pim neighbor resultado del comando, la vecindad PIM se ve bien.

Escriba el show ip mroute  para ver si el router 72a tiene una buena ruta multicast:

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#

Puede ver en la  show ip mroute 10.224.1.1  que la interfaz entrante es Ethernet2/0, mientras que Ethernet3/1 es esperado.

Escriba el  show ip mroute 10.224.1.1 count  para ver si llega tráfico multicast para este grupo al Router 72a y qué sucede a continuación:

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#

Puede ver en los Otros recuentos que el tráfico se interrumpe debido a una falla de RPF: 471 caídas en total, debido a una falla de RPF - 471...

Escriba el show ip rpf   para ver si hay un error de 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® calcula la interfaz RPF de esta manera. Las posibles fuentes de información de RPF son la Tabla de Ruteo Unicast, la Tabla de Ruteo MBGP, la Tabla de Ruteo DVMRP y la Tabla de Ruteo Multicast Estático. Cuando se calcula la interfaz RPF, se utiliza principalmente la distancia administrativa para determinar exactamente en qué fuente de información se basa el cálculo de RPF. Las reglas específicas son:

• Se busca una coincidencia en la dirección IP de origen en todas las fuentes anteriores de datos RPF. Cuando se utilizan árboles compartidos, se utiliza la dirección RP en lugar de la dirección de origen.

• Si se encuentra más de una ruta coincidente, se utiliza la ruta con la distancia administrativa más baja.

• Si las distancias administrativas son iguales, se utiliza este orden de preferencia:

  1. Rutas multicast estáticas

  2. Rutas DVMRP

  3. Rutas MBGP

  4. Rutas Unicast

• Si ocurren múltiples entradas para una ruta dentro de la misma tabla de rutas, se utiliza la ruta de coincidencia más larga.

 show ip mroute 224.1.1.1 El resultado del comando muestra que la interfaz RPF es E2/0, pero la interfaz entrante debe ser E3/1.

Escriba el  show ip mroute 224.1.1.1 para ver por qué la interfaz RPF es diferente de lo que se esperaba.

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

Puede ver en este resultado del comando show ip route 10.1.1.1 que hay una ruta estática /32, que hace que la interfaz incorrecta sea elegida como interfaz RPF.

Ingrese algunos comandos adicionales de 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

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 

El resultado de  show ip mroute  y  debug ip mpacket  parece correcto, el número de paquetes enviados en el  show ip mroute count aumenta y el HostA recibe los paquetes.

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

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 de la  show ip mroute  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 

(*, 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 

Puede ignorar el 10.224.0.40 en la salida ya que todos los routers se unen a este grupo de detección de RP automático. Pero no hay ninguna fuente enumerada para 10.224.1.1. Además de "*, 10.224.1.1", puede ver "10.1.1.1, 10.224.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.

Compruebe si PIM está configurado en las interfaces con  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. Compruebe si el router reconoce el 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 10.224.1.1. Puede comprobarlo 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 
10.224.1.1        Ethernet1/2          00:30:02  00:02:45  10.3.1.2 

10.224.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 comprobar si se trata de un problema TTL con la captura del sabueso y también se ve con 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 

(*, 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 

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 

(*, 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

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 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 

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 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

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

  ip multicast ttl-threshold  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  con la forma no de este comando, que vuelve al valor predeterminado del umbral TTL de 0, o baja 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 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 

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 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

¿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, introduzca el show ip mroute  para ver la ruta multicast (mroute) para el grupo:

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 

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 (*, 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 

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é es el accept-rp  en la configuración que se supone que debe realizar? En IP Multicast Routing Commands, indica que "para configurar un router de modo que acepte uniones o recortes destinados a un RP especificado y a una lista específica de grupos, utilice el comando ip pim accept-rp global configuration. Para quitar esa comprobación, utilice la forma no de este comando."

Cuando se quita el ip pim accept-rp  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. Escriba el show ip pim rp mapping  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, pim accept-rp de la configuración es incorrecta.

Correcciones posibles

La solución es corregir la dirección IP en el  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 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#

El RP para 10.224.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 10.224.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#

CGMP no evita la inundación de paquetes de multidifusión

En esta sección se explica cómo se puede producir una inundación no deseada de paquetes de multidifusión cuando el Protocolo de administración de grupos de Cisco (CGMP) no está habilitado en todos los routers de una subred en particular, y cómo se puede evitar este problema. Este diagrama de red se utiliza como ejemplo.

Cisco Group Management Protocol (CGMP) no está activado

Diagnosticar el problema

En la figura, la tabla de CAM estática en el Catalyst 5000 Switch A no muestra ninguno de los puertos correctos que se llenan. El router configurado con CGMP no envía paquetes CGMP.

CGMP se ha configurado correctamente con el set cgmp enable  en el conmutador A y el ip cgmp  en la interfaz E0/2 del router 75a. Sin embargo, no se ven grupos multicast en el Switch A cuando el  show multicast group  se ejecuta el comando:

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 salida de este comando debe mostrar cada puerto que tenga un router configurado por CGMP (puerto 2/3) y cada puerto que tenga un receptor interesado (puerto 2/6). Dado que 0 aparece en la lista, puede asumir que todos los puertos están innecesariamente inundados con tráfico multicast, lo deseen o no.

‘Observaciones’

Verifique si hay algún vecino de Protocol Independent Multicast (PIM) en el Router 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 

El resultado muestra que el Router 75a puede ver al Router 75b como un vecino PIM válido a través del Switch A.

Ahora verifique si recibe la información correcta de la ruta multicast (mroute) en los routers:

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 

La salida muestra que el router 75a reenvía los paquetes multicast fuera de E0/2 hacia el switch A. Este resultado muestra que el Router 75b obtiene los paquetes multicast y los reenvía correctamente:

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 

Desde el punto de vista del Switch A, puede ver que el Router 75a está fuera del puerto 2/3.

Console> (enable) show multicast router 
CGMP enabled 
IGMP disabled 
IGMP fastleave disabled 

Port       Vlan 
---------  ---------------- 
 2/3       6 

Total Number of Entries = 1 

Todo lo visto hasta ahora parece estar bien. Introduzca algunos  debug en el Router 75a para ver lo que puede averiguar:

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 

En la salida, 0000.0000.0000 es la dirección de todos los grupos y se utiliza cuando los routers envían mensajes de incorporación/salida CGMP para que los switches puedan llenar los puertos del router. GDA significa dirección de destino de grupo en formato de nivel de control de acceso a medios (MAC) y EE.UU. significa dirección de origen unidifusión. Esta es la dirección del host que originó el informe IGMP para el cual se genera este mensaje CGMP. En este caso, es la dirección MAC para la interfaz E0/2 del router 75a. La dirección MAC para E0/2 del router 75a se puede ver con el  show interface  como se ve aquí:

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)

Además, puede ver esto periódicamente cuando el  debug ip igmp  comando está activado:

*Feb  8 12:51:41.854: IGMP: Received v2 Report from 10.2.1.3 (Ethernet0/2) for 10.224.1.1

Sin embargo, posteriormente no verá un paquete CGMP correspondiente del Router 75a. Esto significa que el Router 75a recibe informes IGMP, pero no genera los paquetes CGMP necesarios para ayudar al Switch A a saber qué puertos bloquear. Esto es algo que se espera del router 75a si es el solicitante IGMP. Esta salida del Router 75a nos indica por qué no ocurre el comportamiento esperado:

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 tiene dos routers en la misma subred y configura ambos para CGMP, sólo uno puede enviar paquetes CGMP. El router que envía los paquetes CGMP es el IGMP que consulta al router. Esto significa el router con la dirección IP de unidifusión más baja de los routers habilitados para IGMP.

En este caso, tanto el router 75a como el router 75b tienen habilitado IGMP (el router 75b se convirtió en el router de consultas IGMP), pero solo el router 75a tiene habilitado CGMP. Dado que el router 75a no es el router de consulta IGMP, no se envían paquetes CGMP.

Correcciones posibles

Para resolver el problema, debe configurar CGMP en el router de consulta IGMP. En este caso, el router 75b. En primer lugar, encienda debug comandos en el router 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 

El router 75b recibe un informe IGMP desde 10.2.1.3 para el grupo 10.224.1.1. Posteriormente envía una incorporación CGMP al Switch A para el 10.224.1.1 equivalente de MAC con la dirección MAC (USA) del host interesado 10.2.1.3. El switch A conoce el puerto en el que se encuentra el host, de manera que lo marca como abierto y bloquea a los demás.

Ahora todo debe funcionar en el switch 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 

Esto es mucho mejor. Los paquetes 10.224.1.1 (01-00-5e-01-01-01) sólo se envían por los puertos 2/3, 2/4 y 2/6 del switch A, como deberían. Se ha detenido la inundación de todos los demás puertos. El número total de entradas ahora se muestra correctamente como 2. La dirección MAC 01-00-5e-00-01-28 se asigna desde la dirección de multidifusión 224.0.1.40, que se utiliza para las autouniones CGMP.

CGMP no evita la inundación de paquetes de multidifusión debido a la ubicación del origen/receptor

Esta sección proporciona una solución al problema común de un switch Catalyst que inunda el tráfico a cada puerto, en lugar de sólo al host correcto. Este diagrama de red se utiliza como ejemplo.

Switch Catalyst que inunda el tráfico a cada puerto

Diagnosticar el problema

En la figura, los routers 75a y 75b y el Catalyst 5000 (Switch A) están configurados correctamente para multidifusión y Cisco Group Management Protocol (CGMP). El host obtiene el tráfico de multidifusión. Sin embargo, también lo hacen los demás hosts fuera del Switch A. El Switch A inunda el tráfico fuera de cada puerto, lo que significa que el CGMP no funciona.

El resultado de la  show multicast group en el switch A es similar 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 

Total Number of Entries = 1 

Puede ver en la salida que el único grupo es 224.0.1.40, que es utilizado por el router cuando envía autouniones CGMP para el grupo auto-RP. ¿Cómo es que no hay otros grupos?

Correcciones posibles

Para entender la solución, debe entender cómo se comporta el CGMP bajo ciertas condiciones. Un router habilitado para CGMP envía uniones CGMP a un switch para informar al switch de los hosts interesados en un grupo multicast determinado. El switch busca las direcciones MAC para estos hosts en su tabla CAM, luego reenvía los paquetes de multidifusión a los puertos con hosts interesados y evita que el resto de los puertos reenvíe paquetes de multidifusión.

Un router envía autouniones CGMP a una interfaz habilitada para CGMP si recibe paquetes multicast de un origen que se encuentra en la misma interfaz en la que (el router) tiene CGMP habilitado.

Por ejemplo, si la fuente estuviera en la misma subred (VLAN), 10.2.1.0/24, como los routers 75a y 75b, CGMP funcionaría perfectamente. El router, cuando identifica paquetes del origen, enviaría una autounión CGMP al switch, que luego aprendería dinámicamente en qué puertos se encuentra el router y bloquearía el reenvío de paquetes multicast en todos los demás puertos.

Un router envía CGMP se une a una interfaz habilitada para CGMP si recibe informes IGMP de un host en la misma interfaz que tiene habilitada CGMP (el router).

Otro ejemplo es si tenía un host interesado en esta misma VLAN. En ese caso, cuando un router habilitado para CGMP recibe un informe de Protocolo de administración de grupos de Internet (IGMP) de un host que está interesado en un grupo de multidifusión determinado, el router envía una unión CGMP. La unión indicará la dirección MAC (del inglés Media Access Control, control de acceso a medios) del host que desea unirse y el grupo al que desea unirse. El Catalyst 5000 luego verificaría su tabla CAM para la dirección MAC del host, colocaría el puerto asociado en la lista de grupos multicast y bloquearía todos los otros puertos no interesados.

No sucede lo mismo cuando el host de origen y los hosts interesados se encuentran en una subred distinta de la subred habilitada para CGMP (VLAN). Los paquetes de multidifusión, que provienen del origen, no activan que el router envíe autouniones CGMP al switch. Por lo tanto, los paquetes llegan al switch y se inundan en todas partes dentro de la VLAN. Este escenario continúa hasta que un host en la VLAN, que sale de un puerto en el switch, envía una unión IGMP. Sólo con la recepción de un informe IGMP el router envía un paquete CGMP que provoca que el switch agregue el puerto de host apropiado como puerto de reenvío y se bloqueen los demás puertos (además de los puertos del router).

Para que CGMP funcione en esta topología de tipo de tránsito, puede agregar un host a la misma VLAN que los routers 75a y 75b, como en este diagrama de red.

Agregar un host a la misma VLAN que los routers 75a y 75b

O mueva la fuente en la misma subred como routers 75a y 75b, como en este ejemplo.

Mover el origen en la misma subred que los routers 75a y 75b

Mueva el origen a la misma subred y luego verifique el resultado del Switch 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 

CGMP no evita la inundación de paquetes de multidifusión para ciertas direcciones de grupo

Esta sección describe los motivos por los cuales algunas direcciones IP hacen que el protocolo de administración de grupo de Cisco (CGMP) se inunde con tráfico multidifusión afuera de todos los puertos de una red de área local (LAN). Cuando utiliza la dirección de grupo multicast 10.225.0.1, CGMP no funciona. Inunda el flujo de secuencia de multidifusión fuera de todos los puertos del switch y desperdicia ancho de banda. Sin embargo, si cambia la dirección a 10.225.1.1 CGMP funciona correctamente. ¿Puede utilizar 10.225.0.1 ya que no es una dirección registrada para un protocolo de ruteo?

Correcciones posibles

En primer lugar, es importante comprender cómo se asignan las direcciones de multidifusión de capa 3 a las direcciones de multidifusión de capa 2. Todas las tramas de multidifusión IP utilizan direcciones de capa MAC IEEE que comienzan con el prefijo de 24 bits de 0x0100.5e. Cuando asigna direcciones de la Capa 3 a la Capa 2, los 23 bits de orden inferior de la dirección multicast de la Capa 3 se asignan a los 23 bits de orden inferior de la dirección IEEE MAC.

Otro hecho importante que se debe comprender es que hay 28 bits de espacio de dirección único para una dirección de multidifusión IP (32 bits menos los primeros 4 bits que contienen el prefijo de clase D 1110). Como sólo hay 23 bits conectados a la dirección MAC de IEEE, quedan 5 bits de superposición. Esto significa que las múltiples direcciones multidifusión de capa 3 pueden mapear hacia la misma dirección multidifusión de capa 2.

Por ejemplo:

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

Observe en el ejemplo que tanto 10.244.0.1 como 10.244.128.0 se asignan a la misma dirección de multidifusión de Capa 2.

Ahora que ya sabe cómo se asignan las direcciones multidifusión de la capa 3 a la capa 2, vaya a la solución específica para este problema.

El switch A inunda los paquetes de multidifusión a 224.0.0.x porque esas direcciones son locales de link y desea asegurarse de que las direcciones locales de link lleguen a todos los dispositivos de la red de área local (LAN). Los switches Catalyst también inundan los paquetes multicast a otras direcciones multicast que son ambiguas a nivel MAC con 224.0.0.x (por ejemplo, 10.244.0.1 y 10.225.0.1 se asignan a 0100.5e00.0001). El switch inunda los paquetes de multidifusión destinados a estas direcciones locales del link sin tener en cuenta si CGMP está activado o no.

Por lo tanto, la aplicación de multidifusión debe evitar el uso de direcciones clase D que corresponden a una dirección de multidifusión de Capa 2 de 0100.5e00.00xx, donde xx puede ser 00 a FF en formato hexadecimal. Consta de las siguientes direcciones de clase 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

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 comprobar los vaciados con el comando  show interface  comando.

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

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   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 y compruebe el tamaño anormal.

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

Posible corrección 2

Puede utilizar el   ip igmp static-group   en lugar del comando  ip igmp join-group   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