IP : Multidifusión IP

Guía de resolución de problemas de multidifunción IP

25 Agosto 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Abril 2015) | Comentarios


Contenido


Introducción

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

prerrequisitos

Requisitos

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.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte las Convenciones de Consejos Técnicos de Cisco.

Antecedentes

Al localizar averías el ruteo multicast, el problema principal es la dirección de origen. El Multicast tiene un concepto de control del reenvío de trayecto inverso (revisión de "RPF"). Cuando un paquete de multidifusión llega a una interfaz, el proceso RPF realiza una verificación para asegurar que esta interfaz de entrada sea la interfaz de salida utilizada por el ruteo de unidifusión para llegar al origen del paquete de multidifusión. Este proceso de verificación del RPF evita los loops. El ruteo multicast no remite un paquete a menos que la fuente del paquete pase un control del reenvío de trayecto inverso (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.

Como el Unicast Routing, el ruteo multicast tiene varios protocolos disponibles, tales como modo denso de la multidifusión independiente de protocolo (PIM-DM), modo disperso de PIM (PIM-S), Distance Vector Multicast Routing Protocol (DVMRP), protocolo multicast border gateway (MBGP), y Multicast Source Discovery Protocol (MSDP). Los casos prácticos en este documento recorren usted con el proceso de localizar averías los diversos problemas. Usted verá se utilizan qué comandos para establecer claramente rápidamente el problema y de aprender cómo resolverlo. Están genéricos los casos prácticos enumerados aquí a través de los protocolos, a menos que donde observados.

El router no remite los paquetes de multidifusión al host debido a la falla de RPF

Esta sección proporciona una solución al problema común de un error del reenvío de trayecto inverso del Multicast IP (RPF). Este diagrama de la red se utiliza como un ejemplo.

http://www.cisco.com/c/dam/en/us/support/docs/ip/ip-multicast/16450-mcastguide1a.gif

En la figura arriba, los paquetes de multidifusión entran en el E0/0 del router 75a de un servidor cuya dirección IP sea 1.1.1.1 y envíe para agrupar 224.1.1.1. Esto es conocido como un (S,G) o (1.1.1.1, 224.1.1.1).

Diagnostique el problema

Los hosts conectados directamente con el router 75a reciben el suministro de multidifusión, pero los hosts conectados directamente con el router 72a no hacen. Primero, publique el comando de 224.1.1.1 de la ruta multicast del IP de la demostración de ver qué está continuando con el router 75a. Este comando examina la ruta de Multicast (ruta multicast) para el grupo de dirección 224.1.1.1:

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

(1.1.1.1, 224.1.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 

Puesto que el router es modo denso de PIM corriente (sabemos que es modo denso debido al indicador D), ignore *, entrada G y foco en el S, entrada G. Esta entrada le dice que los paquetes de multidifusión son originados de un servidor cuyo direccionamiento sea 1.1.1.1, que envía a un grupo de multidifusión de 224.1.1.1. Los paquetes están viniendo en la interfaz del Ethernet0/0 y se remiten hacia fuera la interfaz Ethernet0/1. Esto es un escenario perfecto.

Publique el comando show ip pim neighbor de ver si el router 72a está mostrando el router ascendente (75a) como vecino del PIM:

ip22-72a#show ip pim neighbor
PIM Neighbor Table 
Neighbor Address  Interface          Uptime    Expires   Ver  Mode 
2.1.1.1           Ethernet3/1        2d00h     00:01:15  v2 

De la salida del comando show ip pim neighbor, la mirada de la vecindad PIM buena.

Utilice este comando show ip mroute de ver si el router 72a tiene buena ruta multicast:

ip22-72a#show ip mroute 224.1.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
 
(*, 224.1.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
 
(1.1.1.1, 224.1.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#

Usted puede ver del comando de 224.1.1.1 de la ruta multicast del IP de la demostración que la interfaz entrante es Ethernet2/0, mientras que se espera Etheret3/1.

Publique el comando count de 224.1.1.1 de la ruta multicast del IP de la demostración de ver si algún tráfico Multicast para este grupo llega al router 72a y qué sucede después:

ip22-72a#show ip mroute 224.1.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: 224.1.1.1, Source count: 1, Packets forwarded:      0, Packets received: 471
  Source:      1.1.1.1/32, Forwarding: 0/0/0/0, Other: 471/471/0
ip22-72a#

Usted puede ver de las otras cuentas que el tráfico consigue caída debido a la falla de RPF: sume 471 descensos, debido a la falla de RPF – 471…

Publique el comando show ip rpf <source> de ver si hay un error RPF:

ip22-72a#show ip rpf 1.1.1.1
RPF information for ? (1.1.1.1)
  RPF interface: Ethernet2/0
  RPF neighbor: ? (0.0.0.0)
  RPF route/mask: 1.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 fuentes posibles de información RPF son tabla de Unicast Routing, tabla de ruteo MBGP, tabla de ruteo DVMRP y tabla del mRoute estático. Cuando usted calcula la interfaz RPF, sobre todo la distancia administrativa se utiliza para determinar exactamente que la fuente de información el cálculo del RPF se basa encendido. Las reglas específicas son:

  • Todas las fuentes precedentes de datos RPF se buscan para una coincidencia en la dirección IP de origen. Al usar los árboles compartidos, el direccionamiento RP se utiliza en vez de la dirección de origen.

  • Si se encuentra más de una ruta que corresponde con, la ruta con la mínima distancia administrativa se utiliza.

  • Si las distancias administrativas son iguales, después se utiliza esta orden de preferencia:

    1. MRoutes estáticos

    2. Rutas DVMRP

    3. Rutas MBGP

    4. Rutas Unicast

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

La salida de comando rpf 1.1.1.1 del IP de la demostración muestra la interfaz RPF que es E2/0, pero la interfaz entrante debe ser E3/1.

Publique el comando de 1.1.1.1 de la ruta de IP de la demostración de ver porqué la interfaz RPF es diferente de lo que fue esperado.

ip22-72a#show ip route 1.1.1.1
  Routing entry for 1.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

Usted puede ver de esta salida de comando de 1.1.1.1 de la ruta de IP de la demostración que hay una ruta estática de /32, que hace la interfaz incorrecta que se elegirá como interfaz RPF.

Publique algunos otros comandos debug:

ip22-72a#debug ip mpacket 224.1.1.1 
*Jan 14 09:45:32.972: IP: s=1.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.020: IP: s=1.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.072: IP: s=1.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.120: IP: s=1.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface

Los paquetes están viniendo adentro en el E3/1, que está correcto. Sin embargo, se están cayendo porque ésa no es la interfaz que la tabla de Unicast Routing utiliza para revisión de "RPF".

Nota: Hacer el debug de los paquetes es peligroso. El debugging de Pakcet acciona el process switching de los paquetes de multidifusión, que es uso intensivo de la CPU. También, el debugging del paquete puede producir la salida enorme que puede colgar el router totalmente debido reducir la salida al puerto de la consola. Antes de hacer debug en el paquete, el particular cuidado debe ser tomado para inhabilitar la salida de registro a la consola, y habilita el registro a la memoria intermedia. Para alcanzar esto, no configure ninguna consola de registro y debugging guardado en la memoria intermedia del registro. Los resultados del debug se pueden considerar con el comando show logging.

Correcciones posibles

Usted puede o cambiar la tabla de Unicast Routing para satisfacer este requisito o usted puede agregar un mRoute estático para forzar el Multicast al RPF hacia fuera una interfaz particular, sin importar lo que estado la tabla de Unicast Routing. Agregue un mRoute estático:

ip22-72a(config)#ip mroute 1.1.1.1 255.255.255.255 2.1.1.1

Esta mruta estática manifiesta que para llegar a la dirección 1.1.1.1, para RPF, utilice 2.1.1.1 como el salto siguiente que está fuera de la interfaz E3/1.

ip22-72a#show ip rpf 1.1.1.1 
RPF information for ? (1.1.1.1) 
  RPF interface: Ethernet3/1 
  RPF neighbor: ? (2.1.1.1) 
  RPF route/mask: 1.1.1.1/32 
  RPF type: static mroute 
  RPF recursion count: 0 
  Doing distance-preferred lookups across tables 

La salida de las miradas del mpacket del IP de la ruta multicast y del debug del IP de la demostración buenas, el número de paquetes enviados en los aumentos de la cuenta de la ruta multicast del IP de la demostración y el HostA recibe los 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 

(1.1.1.1, 224.1.1.1), 00:00:48/00:02:59, flags: CTA 
  Incoming interface: Ethernet3/1, RPF nbr 2.1.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: 1.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: 1.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=1.1.1.1 (Ethernet3/1) 
d=224.1.1.1 (Ethernet3/2) len 60, mforward 
*Jan 14 10:18:29.999: IP: s=1.1.1.1 (Ethernet3/1) 
d=224.1.1.1 (Ethernet3/2) len 60, mforward 
*Jan 14 10:18:30.051: IP: s=1.1.1.1 (Ethernet3/1) 
d=224.1.1.1 (Ethernet3/2) len 60, mforward

El router no remite los paquetes de multidifusión al host debido al TTL establece el valor del origen

Esta sección brinda una solución al problema común de los paquetes de multidifusión IP que no se reenvían porque el valor Tiempo de funcionamiento (TTL) ha llegado a cero. Esto es un problema común, pues hay muchas aplicaciones de multidifusión. Estas aplicaciones de multidifusión se diseñan sobre todo para el uso de LAN, y fijan así TTL a un valor bajo o aún a un 1. Utilice este diagrama de la red como un ejemplo.

http://www.cisco.com/c/dam/en/us/support/docs/ip/ip-multicast/16450-mcastguide2a.gif

Diagnostique el problema

En la figura arriba, el router A no remite los paquetes de las fuentes al receptor conectado de forma directa del router B. Mire la salida del comando show ip mroute en el router A de ver el estado del 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 

Usted puede ignorar 224.0.1.40 en la salida arriba puesto que todo el Routers se une a este auto-RP grupo de la detección. Pero no hay fuente enumerada para 224.1.1.1. Además de “*, 224.1.1.1” usted debe ver "1.1.1.1, el 224.1.1.1".

Publique el comando show ip rpf de ver si es un problema del reenvío de trayecto inverso (RPF):

ROUTERA#show ip rpf 1.1.1.1 
RPF information for ? (1.1.1.1) 
  RPF interface: Ethernet0/0 
  RPF neighbor: ? (0.0.0.0) - directly connected 
  RPF route/mask: 1.1.1.0/24 
  RPF type: unicast (connected) 
  RPF recursion count: 0 
  Doing distance-preferred lookups across tables 

De la salida arriba, usted ve que no es un problema RPF. Revisión de "RPF" señala correctamente el E0/0 para conseguir a la dirección IP de la fuente.

Marque si el PIM está configurado en las interfaces usando el comando show ip pim interface:

ROUTERA#show ip pim interface 

Address          Interface          Version/Mode    Nbr   Query     DR 
                                                    Count Intvl 
1.1.1.2          Ethernet0/0        v2/Sparse-Dense  0    30     1.1.1.2 
2.1.1.1          Ethernet0/1        v2/Sparse-Dense  2    30     2.1.1.2 

La salida parece buena, así que éste no es el problema. Marque si el router reconoce algún tráfico activo usando el comando show ip mroute active:

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

De acuerdo con la salida arriba, el router no reconoce ningún tráfico activo.

ROUTERA#debug ip mpacket 
IP multicast packets debugging is on 

Quizás el receptor no está enviando ninguna informes del Internet Group Management Protocol (IGMP) (se une a) para el grupo 224.1.1.1. Usted puede marcarlo usando el comando show ip igmp group:

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     2.1.1.2 
224.1.1.1        Ethernet1/2          00:30:02  00:02:45  3.1.1.2 

224.1.1.1 se ha unido a en el E1/2, que está muy bien.

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

Usted puede marcar para ver si es un problema de TTL con la captura del sniffer y también visto con el comando show ip traffic:

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 

La salida antedicha muestra 63744 malos conteos saltos. Cada vez que usted teclea este comando, el mún conteo saltos aumenta. Éste es un indicio sólido que el remitente está enviando los paquetes con un TTL=1, que el router A decrements a cero. Esto da lugar a un aumento del mún campo de conteo de saltos.

Correcciones posibles

Para solucionar el problema, usted necesita aumentar 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 que se hace esto, el router A parece esto:

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 

(1.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 

Ésta es la clase de salida que usted quiere ver.

En el router B usted ve:

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 

(1.1.1.1, 224.1.1.1), 00:17:46/00:02:59, flags: CTA 
  Incoming interface: Ethernet1/1, RPF nbr 2.1.1.1 
  Outgoing interface list: 
    Ethernet1/2, Forward/Sparse-Dense, 00:17:46/00:00:00

El router no remite los paquetes de multidifusión debido al umbral TTL del router

Esta sección proporciona una solución al problema común del umbral TTL que es fijado demasiado bajo, de modo que el tráfico del Multicast IP no alcance el receptor. Este diagrama de la red se utiliza como un ejemplo.

http://www.cisco.com/c/dam/en/us/support/docs/ip/ip-multicast/16450-mcastguide3a.gif

Diagnostique el problema

En la figura arriba, el receptor no recibe los paquetes de multidifusión de la fuente. Puede haber vario Routers entre la fuente y el router 75a. Primera mirada en el router 75a, puesto que está conectada directamente con el 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 

(1.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 antedicha muestra que el router 75a está remitiendo los paquetes hacia fuera Ethernet0/1. Para ser router absolutamente seguro que 75a está remitiendo los paquetes, que gire el debug apenas para esta fuente y grupo de 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 1.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=1.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied 
*Jan 17 09:04:08.762: IP: s=1.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied 
*Jan 17 09:04:08.814: IP: s=1.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied

Los mensajes antedichos del debug indican que el router 75a no remite los paquetes de multidifusión porque se ha alcanzado el umbral TTL. Mire la configuración del router para ver si usted puede encontrar la razón. Esta salida muestra al culpable:

interface Ethernet0/1 
 ip address 2.1.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 éste no significa que cualquier cosa mayor que TTL de 15 no está enviada. De hecho, se aplica lo contrario. La aplicación se está enviando con TTL de 15. Para el momento en que consiga al router 75a, los paquetes de multidifusión tienen TTL menos de 15.

El comando ip multicast ttl-threshold <value> significa que cualquier paquete con TTL baja que el umbral especificado, en este caso, 15, no se remite. Este comando se utiliza por lo general para proporcionar un borde para evitar que el tráfico de multidifusión interno salga sin rumbo de la red.

Correcciones posibles

Cualquiera quita el comando ip multicast ttl-threshold <value> usando la ninguna forma de este comando, que invierte al valor de umbral TTL predeterminado de 0, o baja el umbral TTL de modo que el tráfico pueda pasar.

Múltiples trayectos de igual costo pueden generar un comportamiento de retransmisión de trayecto de retorno no deseado

Esto secciona las demostraciones cómo los trayectos de igual costos a un origen de multidifusión pueden causar el comportamiento indeseado del Return Path Forwarding (RPF). También describe como configurar una IP multidifusión para evitar este comportamiento. Este diagrama de la red se utiliza como un ejemplo.

http://www.cisco.com/c/dam/en/us/support/docs/ip/ip-multicast/16450-mcastguide4a.gif

Diagnostique el problema

En la figura arriba, el router 75b tiene tres trayectos de igual costos de nuevo a la fuente (1.1.1.1), y elige un link que usted no quisiera que fuera su primera opción como el link RPF.

Cuando está hecho frente con los Trayectos múltiples de igual costo a una fuente, el Multicast IP elige la interfaz que tiene un vecino de la multidifusión independiente de protocolo (PIM) con la dirección IP más alta pues la interfaz entrante y después envía las pasas a los vecinos del PIM en los otros links.

Correcciones posibles

Para cambiar el Multicast IP de la interfaz elige como su interfaz entrante, usted puede hacer uno de éstos:

  • 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 así que la dirección IP más alta está en el link que usted quiere ser el link primario del Multicast.

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

Como un ejemplo, se crea un mRoute estático.

Antes de instalar un mRoute estático, usted ve en la salida debajo de ése que la tabla de ruteo tiene tres rutas de costo equivalente para la dirección de origen 1.1.1.1. La información RPF indica que la interfaz RPF es E1/3:

ip22-75b#show ip route 1.1.1.1 
Routing entry for 1.1.1.0/24 
  Known via "ospf 1", distance 110, metric 20, type intra area 
  Redistributing via ospf 1 
  Last update from 3.1.1.1 on Ethernet1/2, 00:26:21 ago 
  Routing Descriptor Blocks: 
  * 4.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3 
      Route metric is 20, traffic share count is 1 
    2.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1 
      Route metric is 20, traffic share count is 1 
    3.1.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 1.1.1.1 
RPF information for ? (1.1.1.1) 
  RPF interface: Ethernet1/3 
  RPF neighbor: ? (4.1.1.1) 
  RPF route/mask: 1.1.1.0/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 

(1.1.1.1, 224.1.1.1), 01:30:35/00:02:59, flags: CT 
  Incoming interface: Ethernet1/3, RPF nbr 4.1.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 el mRoute estático, usted ve en este hecho salir la interfaz RPF ha cambiado al 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 2.1.1.1 
ip22-75b(config)#end 

ip22-75b#show ip rpf 1.1.1.1 
RPF information for ? (1.1.1.1) 
  RPF interface: Ethernet1/1 
  RPF neighbor: ? (2.1.1.1) 
  RPF route/mask: 1.1.1.1/0 
  RPF type: static mroute 
  RPF recursion count: 0 
  Doing distance-preferred lookups across tables 

ip22-75b#show ip route 1.1.1.1 
Routing entry for 1.1.1.0/24 
  Known via "ospf 1", distance 110, metric 20, type intra area 
  Redistributing via ospf 1 
  Last update from 3.1.1.1 on Ethernet1/2, 00:26:21 ago 
  Routing Descriptor Blocks: 
  * 4.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3 
      Route metric is 20, traffic share count is 1 
    2.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1 
      Route metric is 20, traffic share count is 1 
    3.1.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 

(1.1.1.1, 224.1.1.1), 01:31:30/00:02:59, flags: CT 
  Incoming interface: Ethernet1/1, RPF nbr 2.1.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 carga del Multicast IP no equilibra a través de todos los trayectos de igual costos disponibles?

Esta sección ofrece una solución al problema común de la configuración de la multidifusión IP para el balance de carga a través de todos los trayectos disponibles de igual costo. Este diagrama de la red se utiliza como un ejemplo.

http://www.cisco.com/c/dam/en/us/support/docs/ip/ip-multicast/16450-mcastguide4a.gif

En la figura arriba, el router 75b tiene tres links de costo equivalentes de nuevo a la fuente (1.1.1.1). Usted quiere al balance de la carga el tráfico Multicast a través de los tres links.

Correcciones posibles

Como usted vio en los Trayectos múltiples de igual costo para dar lugar a la sección del comportamiento de retransmisión de trayecto de retorno no deseado arriba, la multidifusión independiente de protocolo (PIM) elige solamente una interfaz para el control del Return Path Forwarding (RPF) y poda las otras. Esto significa que no ocurre 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.

Éstas son las configuraciones para el túnel.

Router 75a
interface Tunnel0 
 ip address 6.1.1.1 255.255.255.0 
 ip pim sparse-dense-mode 
 tunnel source Ethernet0/0 
 tunnel destination 5.1.1.1 
! 
interface Ethernet0/0 
 ip address 1.1.1.2 255.255.255.0 
 ip pim sparse-dense-mode 
! 
interface Ethernet0/1 
 ip address 2.1.1.1 255.255.255.0 
! 
interface Ethernet0/2 
 ip address 3.1.1.1 255.255.255.0 
! 
interface Ethernet0/3 
 ip address 4.1.1.1 255.255.255.0

Router 75b
interface Tunnel0 
 ip address 6.1.1.2 255.255.255.0 
 ip pim sparse-dense-mode 
 tunnel source Ethernet1/4 
 tunnel destination 1.1.1.2 
! 
interface Ethernet1/1 
 ip address 2.1.1.2 255.255.255.0 
! 
interface Ethernet1/2 
 ip address 3.1.1.2 255.255.255.0 
! 
interface Ethernet1/3 
 ip address 4.1.1.2 255.255.255.0 
! 
interface Ethernet1/4 
 ip address 5.1.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 que usted configure el túnel, utilice el comando show ip mroute de ver la ruta de Multicast (ruta multicast) 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 

(1.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 

(1.1.1.1, 224.1.1.1), 00:22:53/00:02:59, flags: CT 
  Incoming interface: Tunnel0, RPF nbr 6.1.1.1, Mroute 
  Outgoing interface list: 
    Ethernet1/4, Forward/Sparse-Dense, 00:22:53/00:00:00 

Para marcar que están siendo los datos de multidifusión la carga equilibró igualmente a través de los tres links, mira los datos de la interfaz del router 75a.

La interfaz entrante es los dígitos por segundo 9000:

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

Las tres interfaces salientes cada dígitos por segundo de la demostración 3000:

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

¿Por qué recibimos en el router mensajes de error de multidifusión IP del tipo "INVALID_RP_JOIN"?

Esta sección proporciona las soluciones al problema común del Multicast IP “INVALID_RP_JOIN” mensaje de error.

Diagnostique el problema - Parte 1

Este los mensajes de error se reciben en el (RP) del punto de encuentro:

00:55:15: %PIM-6-INVALID_RP_JOIN: Received (*, 224.1.1.1) 
Join from 1.1.6.2 for invalid RP 1.1.5.4 
00:56:15: %PIM-6-INVALID_RP_JOIN: Received (*, 224.1.1.1) 
Join from 1.1.6.2 for invalid RP 1.1.5.4 

En Mensajes de error del sistema de software de Cisco IOS, se proporciona una explicación de las causas de este error: un router PIM de descarga envió un mensaje de incorporación para el árbol compartido, que este router no quiere validar. Este comportamiento indica que este router permite solamente los routeres en sentido descendente se une a un RP específico.

Se sospecha que está continuando una cierta clase de filtración. Usted necesita hechar una ojeada la configuración del router:

interface Ethernet0/0 
 ip address 1.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 

¿Cuál es el sentencia accept-rp en la configuración supuesta para lograr? En los comandos ip multicast routing, los estados de este documento que “configurar a un router para validar se une a o las pasas destinadas para un RP especificado y para una lista específica de grupos, utilizan el comando ip pim accept-rp global configuration. Para quitar ese control, no utilice la ninguna forma de este comando.”

Cuando usted quita el comando ip pim accept-rp, los mensajes desaparecen. ¿El comando que está causando el problema fue encontrado, solamente qué si usted quiere mantener ese comando la configuración? Usted puede permitir el direccionamiento incorrecto RP. Usando el comando show ip pim rp mapping, usted puede ver el direccionamiento correcto RP:

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 1.1.5.4 (?), v2v1 
    Info source: 1.1.5.4 (?), via Auto-RP 
         Uptime: 01:00:48, expires: 00:02:07

Según el resultado anterior, 1.1.5.4 es el único RP aprendido a través de RP automático, o por otro medio. Sin embargo, este router es solamente el RP para los grupos 224.0.0.0/4. Entonces, la sentencia pim accept-rp de la configuración anterior es incorrecta.

Correcciones posibles

La solución es corregir la dirección IP en la instrucción ip pim accept-rp como sigue:

Cambie esta declaración:

ip pim accept-rp 10.2.2.2 8

Por el siguiente:

ip pim accept-rp 1.1.5.4 8

Usted puede también cambiar la declaración para validar cuál está en el caché auto-RP, y para asegurarse que la lista de acceso (8 en este ejemplo) esté permitiendo 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

Diagnostique el problema - Parte 2

Este mensaje de error se considera 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 2.1.1.1

Marque para ver si el router2 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 1.1.1.1 (?), v2v1
    Info source: 1.1.1.1 (?), elected via Auto-RP
         Uptime: 00:21:26, expires: 00:02:24
router2#

El RP para 224.1.1.1 es 1.1.1.1.

Marque si éste es una de las interfaces del router2:

router2#show ip interface brief 
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                1.1.1.2         YES NVRAM  up                    up      
Ethernet1/0                2.1.1.1         YES NVRAM  up                    up      
Ethernet2/0                unassigned      YES NVRAM  administratively down down    
router2#

Puesto que el router2 no es un RP, debe no haber recibido esto RP-se une al paquete. Marque porqué el router en sentido descendente envió el unir a al router2, mientras que no debe:

router3#show ip pim rp map
PIM Group-to-RP Mappings
 
Group(s) 224.0.0.0/4
  RP 1.1.1.1 (?), v2v1
    Info source: 1.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: 2.1.1.1 (?)
router3#

Como usted ve, el router3 ha configurado estáticamente la información RP, señalando al router2, que es incorrecta. Esto explica porqué el router3 está enviando RP-se une a al router2.

Correcciones posibles

Haga router2 el RP para el grupo 224.1.1.1 o cambie la configuración en el router3 así que refiere al direccionamiento correcto RP.

router3#show run | i rp
ip pim rp-address 2.1.1.1 override
router3#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
router3(config)#no ip pim rp-address 2.1.1.1 override
router3(config)#exit
router3#

Después de que la configuración en el router3 se corrija, el router3 refiere al direccionamiento correcto RP y el mensaje de error para el aparecer.

router3#show ip pim rp map
PIM Group-to-RP Mappings
 
Group(s) 224.0.0.0/4
  RP 1.1.1.1 (?), v2v1
    Info source: 1.1.1.1 (?), elected via Auto-RP
         Uptime: 00:30:45, expires: 00:02:02
router3#

El CGMP no previene la inundación de los paquetes de multidifusión

Esta sección explica cómo la saturación no deseada de los paquetes de multidifusión puede ocurrir cuando el Cisco Group Management Protocol (CGMP) no se habilita en todo el Routers en una subred determinada, y cómo este problema puede ser evitado. Este diagrama de la red se utiliza como un ejemplo.

http://www.cisco.com/c/dam/en/us/support/docs/ip/ip-multicast/16450-mcastguide7a.gif

Diagnostique el problema

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

El CGMP se configura correctamente con el comando set cgmp enable en el Switch A y el comando ip cgmp en la interfaz E0/2 del router 75a. Sin embargo consideran a los grupos del no multicast en el Switch A cuando publican el comando show multicast group:

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 con CGMP configurado en ella (puerto 2/3) y cada puerto que tenga un receptor interesado en él (puerto 2/6). Puesto que 0 es mencionado, usted puede asumir que todos los puertos se están inundando innecesario con el tráfico Multicast si lo quieren o no.

‘Observaciones’

Marque para ver si hay algunos vecinos de la multidifusión independiente de protocolo (PIM) en el router 75a:

ip22-75a#show ip pim neighbor 
PIM Neighbor Table 
Neighbor Address  Interface          Uptime    Expires   Ver  Mode 
2.1.1.1           Ethernet0/2        00:07:41  00:01:34  v2 

La salida antedicha muestra que el router 75a puede ver al router 75b como vecino PIM válido con el Switch A.

Ahora marque si usted está recibiendo la información correcta de la ruta de Multicast (ruta multicast) sobre el Routers:

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

(1.1.1.1, 224.1.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 antedicha muestra que el router 75a está remitiendo los paquetes de multidifusión hacia fuera E0/2 hacia el Switch A. El router 75b de las demostraciones del producto siguiente está consiguiendo los paquetes de multidifusión y los está remitiendo correctamente:

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

(1.1.1.1, 224.1.1.1), 00:00:35/00:02:59, flags: CTA 
  Incoming interface: Ethernet1/3, RPF nbr 2.1.1.2 
  Outgoing interface list: 
    Ethernet1/4, Forward/Sparse-Dense, 00:00:35/00:00:00 

Mirando desde el punto de vista del Switch a, usted ve que considera al router 75a apagado 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 vista hasta ahora parece muy bien. Publique algunos comandos debug en el router 75a de ver lo que usted puede descubrir:

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 arriba, 0000.0000.0000 es los todo-grupos direccionamiento y se utiliza cuando el Routers envía el CGMP se une a/los mensajes de ausencia así que el Switches puede poblar los puertos de router. Dirección destino del grupo de la significa GDA en la dirección de origen de Unicast llana del formato del Media Access Control (MAC) y de la significa USA. Esta es la dirección del host que originó el reporte IGMP para el cual se genera el mensaje CGMP. En este caso, es la dirección MAC para la interfaz E0/2 del router 75a. La dirección MAC para el E0/2 del router 75a se puede considerar con el comando show interface según lo considerado 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, usted puede ver periódicamente esto cuando giran al comando debug ip igmp:

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

Sin embargo, usted no ve posteriormente un paquete CGMP correspondiente del router 75a. Esto significa que el Router 75a está recibiendo informes IGMP, pero no está generando los paquetes CGMP necesarios para ayudar al Switch A a distinguir qué puertos debe bloquear. Éste es algo que se espera del router 75a si es el interrogador IGMP. Esta salida del router 75a nos dice porqué no está sucediendo la conducta esperada:

ip22-75a#show ip igmp interface e0/2 
Ethernet0/2 is up, line protocol is up 
  Internet address is 2.1.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 2.1.1.2 (this system) 
  IGMP querying router is 2.1.1.1 
  No multicast groups joined 

Si usted tiene dos Routers en la misma subred, y usted configura ambos para el CGMP, sólo uno enviará los paquetes CGMP. El router que envía los paquetes CGMP es el router de interrogación IGMP. Esto significa al router con el Unicast IP Address más bajo del Routers IGMP-habilitado.

En este caso, el Routers 75a y el router 75b hacen el IGMP habilitar (el router 75b hizo el router de interrogación IGMP), pero solamente el router 75a hace el CGMP habilitar. Puesto que el router 75a no es el router de interrogación IGMP, no se está enviando ningunos paquetes CGMP.

Correcciones posibles

Para solucionar el problema, usted necesita configurar el CGMP en el router de interrogación IGMP. En este caso, router 75b. Primero, gire los comandos debug 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 2.1.1.3 (Ethernet1/3) for 224.1.1.1 
*Feb  8 12:58:42.422: CGMP: Received IGMP Report on Ethernet1/3 
*Feb  8 12:58:42.422:       from 2.1.1.3 for 224.1.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 2.1.1.3 para el grupo 224.1.1.1. Posteriormente envía una incorporación CGMP al Switch A para el 224.1.1.1 equivalente de MAC con la dirección MAC (USA) del host interesado 2.1.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.

Las cosas deben ahora trabajar 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 de 224.1.1.1 (01-00-5e-01-01-01) están siendo solamente los puertos enviados 2/3, 2/4, y 2/6 en el Switch A, como deben. El inundar al resto de los puertos ha parado. El número total de entradas ahora se enumera correctamente como 2. La dirección MAC 01-00-5e-00-01-28 se asocia de la dirección Multicast 224.0.1.40, que se utiliza para el CGMP propio se une a.

El CGMP no previene las inundaciones de paquetes de multidifusión, debido a la colocación del receptor/fuente

Esta sección proporciona una solución al problema común de un tráfico de la inundación del switch de Catalyst a cada puerto, en vez de apenas al host correcto. Este diagrama de la red se utiliza como un ejemplo.

http://www.cisco.com/c/dam/en/us/support/docs/ip/ip-multicast/16450-mcastguide8a.gif

Diagnostique el problema

En la figura anterior, los Routers 75a y 75b y el Catalyst 5000 (Switch A) están configurados de manera adecuada para multidifusión y el Protocolo de administración de grupos de Cisco (CGMP). El host está consiguiendo el tráfico Multicast. Sin embargo, está tan cada otro host apagado del Switch A del Switch A. está inundando el tráfico hacia fuera cada puerto, así que significa que el CGMP no está trabajando.

El resultado del comando show multicast group en el Switch A tiene el siguiente aspecto:

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 

Usted puede ver de la salida sobre eso que el único grupo es 224.0.1.40, que es utilizado por el router cuando envía las autoincorporaciones de CGMP para grupo RP automático. ¿Como se hace no hay otros grupos?

Correcciones posibles

Para entender la solución, usted necesita entender cómo el CGMP se comporta bajo ciertas condiciones. Un router CGMP envía incorporaciones CGMP a un switch, para informar al switch acerca de los hosts interesados en un grupo de multidifusión 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 manda las autoincorporaciones de CGMP una interfaz habilitada para CGMP si recibe los paquetes de multidifusión de una fuente que esté en la misma interfaz en la cual (el router) hace el CGMP habilitar.

Por ejemplo, si la fuente estuviera en la misma subred (VLAN), 2.1.1.0/24, como los routers 75a y 75b, CGMP funcionaría perfectamente. Al ver los paquetes provenientes de la fuente, el router enviaría un mensaje de autoincorporación de CGMP al switch, que luego aprendería en forma dinámica en qué puertos está el router e impediría al resto de los puertos el envío de paquetes de multidifusión.

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

Otro ejemplo es si teníamos un host interesado en este mismo VLA N. En ese caso, cuando un router habilitado para CGMP recibió un informe del Internet Group Management Protocol (IGMP) de un host que está interesado en un grupo de multidifusión determinado, el router enviaría un CGMP se une a. El unir a indicaría el Media Access Control (MAC) Address del host que quiso unirse a y del grupo que quiso unirse a. El Catalyst 5000 verificaría luego su tabla CAM para la dirección MAC del host, pondría al puerto asociado en la lista del grupo de multidifusión y bloquearía todos los otros puertos no interesantes.

Lo mismo no es verdad cuando la fuente y el host interesado están en una subred con excepción de la subred habilitado para CGMP (VLA N). Los paquetes de multidifusión, viniendo de la fuente, no accionan al router para enviar las autoincorporaciones de CGMP al Switch. Por lo tanto los paquetes golpean el Switch y consiguen inundados por todas partes dentro del VLA N. Este escenario continúa hasta que un host de la VLAN, que proviene de un puerto del 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).

Por lo tanto, para que el CGMP funcione en esta topología de tipo de tránsito, puede agregar un host al mismo VLAN que los routers 75a y 75b, como en este diagrama de red.

http://www.cisco.com/c/dam/en/us/support/docs/ip/ip-multicast/16450-mcastguide8b.gif

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

http://www.cisco.com/c/dam/en/us/support/docs/ip/ip-multicast/16450-mcastguide8c.gif

Mueva la fuente a la misma subred y después marque la salida 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 

Ahora 224.1.1.1 (01-00-5e-01-01-01) se inunda solamente a los puertos de router 2/3 y 2/4, y no a cada puerto del Switch A.

El CGMP no previene los grupos de dirección de las inundaciones de paquetes de multidifusión con certeza

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 usted utiliza a la dirección de grupo de multidifusión 225.0.0.1, el Cisco Group Management Protocol (CGMP) no trabaja. Inunda el flujo de secuencia de multidifusión fuera de todos los puertos del switch y desperdicia ancho de banda. Sin embargo, si usted cambia el direccionamiento a los trabajos de 225.1.1.1 CGMP muy bien. ¿Cuál es incorrecto con usar 225.0.0.1, puesto que no es una dirección registrada para un Routing Protocol?

Correcciones posibles

Primero, es importante entender cómo asocian a las direcciones Multicast de la capa 3 para acodar a 2 direcciones Multicast. Todas las tramas IP de multidifusión usan direcciones de capa de Control de acceso al medio (MAC) IEEE que comienzan con el prefijo de 24 bits 0x0100.5e. Cuando se mapean direcciones de Capa 3 y direcciones de Capa 2, se establece una correspondencia entre los 23 bits de bajo orden de la dirección de multidifusión de la Capa 3 y los 23 bits de bajo orden de la dirección MAC IEEE.

Otro hecho importante a entender es allí es 28 bits de espacio único de direcciones para un IP Multicast Address (32 bits menos los primeros 4 bits que contienen el prefijo de 1110 clases D). 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:

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


224.128.0.1 = 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 anterior que tanto 224.0.0.1 como 224.128.0.1 mapean a la misma dirección multidifusión de capa 2.

Ahora que usted sabe la capa 3 acodar a 2 direcciones Multicast se asocia, proceda a la solución específica al problema antedicho.

El Switch A inunda a 224.0.0.x con paquetes de multidifusión porque esas direcciones son de link local y queremos asegurarnos de que las direcciones de link local alcancen a todos los dispositivos en la red de área local (LAN). Los switches de Catalyst también inundan los paquetes de multidifusión a otras direcciones Multicast que sean nivel MAC ambiguo con 224.0.0.x (por ejemplo, 224.0.0.1 y 225.0.0.1 ambo correspondencia 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. Esto consiste en éstos los direccionamientos de la 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 las secuencias duplicados del paquete de multidifusión

Causa 1

Se reciben los paquetes de multidifusión duplicados cuando configuran a dos Routers en el modo denso. En el modo denso, el dispositivo inunda periódicamente la secuencia. Después de inundar, poda de las interfaces donde el vapor no se quiere. El dos Routers también pasa con el proceso de la aserción y decide quién es el promotor. Cada vez que se apagan los temporizadores, esto sucede, y hasta que este proceso sea completo, ambo Routers está remitiendo la secuencia. Esto hace la aplicación recibir las secuencias de multidifusión duplicados.

Arreglo posible 1

Este problema puede ser resuelto si usted tiene uno del Routers configurado para el ruteo multicast y configurar al otro router para ser el RP en la conexión en sentido ascendente. Configurelo para convertir la secuencia en el modo disperso antes de que la secuencia entre en al router. Esto puede evitar que los paquetes duplicados alcancen la aplicación. No es una parte de la responsabilidad de las redes de asegurarse de que ningunos paquetes duplicados alcanzan nunca un host extremo. Es una parte de la responsabilidad de la aplicación de manejar los paquetes duplicados y de ignorar los datos innecesarios.

Causa 2

Este problema puede ocurrir en los Cisco Catalyst 6500 Switch, que se configuran para el modo de la replicación de multidifusión de la salida y se pueden accionar por el retiro y la reinserción de cualquier [OIR] del linecards. Después del OIR, el puerto de la tela de [FPOE] de la salida puede misprogrammed, que puede hacer los paquetes ser ordenado perjudicar el canal de la salida de la tela y ser enviado al linecards incorrecto. El resultado es que son circuito hecho atrás a la tela y las épocas múltiples replicadas en que salen en el linecard correcto.

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

Arreglo posible 2

Como solución alternativa, cambie al modo de la replicación del ingreso. Durante un cambio de la salida al modo de la ingreso-replicación, las interrupciones del tráfico pueden ocurrir porque se purgan y están reinstalados los accesos directos.

mls ip multicast replication-mode ingress

Actualice el Cisco IOS Software a una versión no afectada por el Id. de bug Cisco CSCeg28814 (clientes registrados solamente) para permanantly resolver el problema.

Causa 3

Este problema puede también ocurrir si el [RSS] del escalamiento del lado de recepción que fija, en los host extremos o los servidores, se inhabilita.

Arreglo posible 3

La configuración RSS facilita una transición transmisión de datos más rápida a través de los CPU múltiples. Habilite la configuración RSS en el host extremo o el servidor. FRefer al establecimiento de una red scalable del artículo de Microsoft con el RSSleavingcisco.com para más información.

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

Causa 1

Es posible que usted ve los rubores y los descensos excesivos del paquete de entrada en las interfaces cuando fluye el tráfico Multicast. Usted puede marcar los rubores con el comando show interface.

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

Arreglo posible 1

Usted puede fijar el valor SPT como infinito para la interfaz donde se consideran los rubores excesivos.

Configure esto:

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

Causa 2

Cuando usted utiliza el comando del unir a-grupo del igmp del IP <group-name> en cualquier interfaz, hace el process switching. Si los paquetes de multidifusión son proceso conmutado en cualesquiera interfaces, consume más CPU como él asigna el process switching por mandato de todos los paquetes a ese grupo. Usted puede funcionar con el comando show buffers input-interface y marcar los tamaños anormales.

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

Arreglo posible 2

Usted puede utilizar el comando del estático-grupo del igmp del IP <group-name> en vez del comando del unir a-grupo del igmp del IP <group-name>.

Nota: Debido a los problemas anteriores, es posible que usted ve CPU elevada el uso el alrededor 90 por ciento. El CPU baja a normal cuando usted lo resuelve con estos arreglos posibles.

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 16450