El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento proporciona una configuración de ejemplo del multicasting sobre un túnel GRE (Generic Routing Encapsulation).
En muchos escenarios de red, desea configurar la red para que utilice túneles GRE para enviar tráfico multidifusión independiente de protocolo (PIM) y tráfico multidifusión entre routers. Normalmente, esto ocurre cuando el origen y el receptor de multidifusión están separados por una nube IP que no está configurada para el ruteo de multidifusión IP. En tales escenarios de red, la configuración de un túnel a través de una nube IP con PIM habilitado transporta paquetes multicast hacia el receptor. Este documento describe la configuración, la verificación y los problemas relacionados que pertenecen a la multidifusión en un túnel GRE.
Asegúrese de cumplir estos requisitos antes de intentar esta configuración:
Una comprensión básica de multidifusión y PIM es útil. Refiérase a la Guía de Configuración de Inicio Rápido Multicast para obtener más información sobre multicast y PIM.
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
En esta sección encontrará la información para configurar las funciones descritas en este documento.
Como muestra el diagrama de red, el origen de multidifusión (10.1.1.1) está conectado a R102 y está configurado para el grupo de multidifusión 239.1.1.20. El receptor multicast (10.2.2.3) está conectado a R104 y está configurado para recibir paquetes multicast para el grupo 239.1.1.20. La separación de R102 y R104 es una nube IP, que no está configurada para el ruteo multicast.
Se configura un túnel entre R102 y R104 originado con sus interfaces de loopback. El comando ip pim sparse-dense mode se configura en las interfaces de túnel y el ruteo multicast se habilita en R102 y R104. La configuración del modo disperso-denso en las interfaces de túnel permite reenviar paquetes en modo disperso o en modo denso a través del túnel, según la configuración del punto de encuentro (RP) para el grupo.
Nota: Para el modo denso - Con el modo denso PIM configurado sobre el túnel, se configura un comando ip mroute 10.1.1.0 255.255.255.0 tunnel 0 en R104 para asegurar un RPF exitoso para la dirección de origen multicast 10.1.1.1. Los paquetes de multidifusión entrantes (10.1.1.1, 239.1.1.20) sobre el túnel0 (Tu0) se comprueban para Reenvío de Trayectoria Inversa (RPF) mediante esta instrucción mroute. Después de una comprobación exitosa, los paquetes de multidifusión se reenvían a las interfaces de la lista de interfaz saliente (OIL).
Nota: Para el modo disperso - Con el modo disperso PIM configurado sobre el túnel, asegúrese de que se dirigen estos puntos:
Para una verificación RPF exitosa del tráfico multicast que fluye sobre el árbol compartido (*,G) desde RP, se debe configurar un comando ip mroute rp-address nexthop para la dirección RP, que apunta a la interfaz de túnel.
Suponiendo que R102 es el RP (dirección RP 2.2.2.2) en este caso, la ruta multicast es el comando ip mroute 2.2.2.2 255.255.255.255 tunnel 0, que asegura una verificación RPF exitosa del tráfico que fluye sobre el árbol compartido.
Para una verificación RPF correcta del tráfico multidifusión (S,G) que fluye a través del árbol de rutas más cortas (SPT), se debe configurar un comando ip mroute source-address nexthop para el origen de multidifusión, apuntando a la interfaz de túnel.
En este caso, cuando el tráfico SPT fluye a través de la interfaz de túnel, se configura un comando ip mroute 10.1.1.0 255.255.255.0 tunnel 0 en R104 para garantizar una verificación RPF exitosa para el entrante (10.1.1.1, 239.1.1.1.1.20) paquetes a través de la interfaz Tu0.
En este documento, se utiliza esta configuración de red:
En este documento, se utilizan estas configuraciones:
Configure el router 102 de acuerdo con este archivo de configuración en ejecución:
R102 |
---|
version 12.2 !hostname r102 ! !ip subnet-zero no ip domain-lookup !--- It stops IP domain lookup, which improves |
Configure el router 104 de acuerdo con este archivo de configuración en ejecución:
R104 |
---|
r104# version 12.2 ! hostname r104 ! ! ip subnet-zero no ip domain-lookup !--- It stops IP domain lookup, which improves |
Use esta sección para confirmar que su configuración funciona correctamente.
El Analizador de Cisco CLI (solo clientes registrados) admite determinados comandos show. Utilice el Analizador de Cisco CLI para ver un análisis de los resultados del comando show.
show ip igmp group - Verifica que el receptor haya enviado su solicitud de afiliación de IGMP para el grupo 239.1.1.20 a R104.
r104#show ip igmp groups IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter 239.1.1.20 Ethernet0/0 00:00:04 00:02:55 10.2.2.3
show ip mroute group-address - Verifica que cuando el origen 10.1.1.1 inicia los paquetes de multidifusión para el grupo 239.1.1.20, R102 instala (*,239.1.1.20) y (10.1.1.1, 239.1.1.20) en la tabla mroute de R102.
Nota: En la entrada (10.1.1.1, 239.1.1.20), el OIL es Tunnel0.
r102#show ip mroute 239.1.1.20 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 Outgoing interface flags: H - Hardware switched Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 239.1.1.20), 00:00:09/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:00:09/00:00:00 Ethernet0/0, Forward/Sparse-Dense, 00:00:09/00:00:00 (10.1.1.1, 239.1.1.20), 00:00:09/00:02:58, flags: T Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Tunnel0, Forward/Sparse-Dense, 00:00:09/00:00:00
show ip mroute group-address - Verifica que R104 tenga las entradas (*,239.1.1.20) y (10.1.1.1, 239.1.1.20) mientras reenvía paquetes multicast para el grupo 239.1.1.20 originados en 10.1.1 1.
Nota: En (10.1.1.1, 239.1.1.20), la interfaz entrante es Tunnel0 y el vecino RPF es 192.168.24.1 - el extremo de la cabeza del túnel en R102. La verificación de RPF se realiza en función de la ruta multicast configurada en R104, y los paquetes multicast se envían al OIL al receptor conectado en la interfaz Ethernet 0/0.
r104#show ip mroute 239.1.1.20 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 Outgoing interface flags: H - Hardware switched Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 239.1.1.20), 00:07:10/00:00:00, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Tunnel0, Forward/Sparse-Dense, 00:07:10/00:00:00 Ethernet0/0, Forward/Sparse-Dense, 00:07:10/00:00:00 (10.1.1.1, 239.1.1.20), 00:01:13/00:02:24, flags: CLT Incoming interface: Tunnel0, RPF nbr 192.168.24.1, Mroute Outgoing interface list: Ethernet0/0, Forward/Sparse-Dense, 00:01:13/00:00:00
show ip rpf ip-address - Realice una verificación RPF para los paquetes originados desde 10.1.1.1. El siguiente ejemplo confirma que el RPF para 10.1.1.1 se realiza a través del túnel 0, en el que estamos recibiendo los paquetes multicast (S,G).
r104>show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: Tunnel0 RPF neighbor: ? (192.168.24.1) RPF route/mask: 10.1.1.1/24 RPF type: static RPF recursion count: 0 Doing distance-preferred lookups across tables
Use esta sección para resolver problemas de configuración.
El Analizador de Cisco CLI (solo clientes registrados) admite determinados comandos show. Utilice el Analizador de Cisco CLI para ver un análisis de los resultados del comando show.
Nota: Consulte Información Importante sobre Comandos Debug antes de utilizar los comandos debug.
Si su multicast sobre el túnel GRE no funciona, una de estas puede ser la causa:
Túnel que no es UP/UP - El origen y el destino del túnel no coinciden en cada extremo del túnel. Por ejemplo, si el destino del túnel en R102 se cambió a la dirección IP 10.2.2.2 en lugar de 2.2.2.2 mientras que la configuración en R104 se mantuvo igual, el túnel no se activaría.
Ejecute el comando show interface tunnel 0 para verificar el estado del túnel.
Los paquetes de multidifusión se descartan debido a una falla de RPF.
Ejecute el comando show ip mroute count. En este resultado se muestra un ejemplo de salida de este comando y sus contadores crecientes para la falla de RPF:
r104#show ip mroute count IP Multicast Statistics 3 routes using 1642 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.0.1.40, Source count: 0, Packets forwarded: 0, Packets received: 0 Group: 239.1.1.20, Source count: 1, Packets forwarded: 11, Packets received: 45 Source: 10.1.1.1/32, Forwarding: 11/0/100/0, Other: 25/14/0 !--- After some time, the show ip mroute count command
!--- is issued again. You can see the RPF failed counter increasing: r104#show ip mroute count IP Multicast Statistics 3 routes using 1642 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.0.1.40, Source count: 0, Packets forwarded: 0, Packets received: 0 Group: 239.1.1.20, Source count: 1, Packets forwarded: 11, Packets received: 50 Source: 10.1.1.1/32, Forwarding: 11/0/100/0, Other: 30/19/0 r104#
También puede ejecutar el comando show ip rpf source. Asegúrese de que la interfaz RPF sea la misma que en la que se reciben los paquetes multicast de origen - Túnel 0 en este ejemplo. Refiérase a la Guía de Troubleshooting de IP Multicast para obtener más información sobre fallas de RPF.
Vecinos PIM - El Router R102 no reenvía sobre la interfaz Tunnel0 porque no ve un vecino PM R104.
Ejecute estos comandos:
show ip pim neighbor - Puede utilizar el comando show ip pim neighbor en R102 para mostrar al vecino R104 sobre el túnel.
show ip pim int - También puede utilizar el comando show ip pim int para mostrar que hay un vecino.
ip pim sparse-dense-mode - Verifique que el comando interface level ip pim sparse-dense-mode esté configurado en ambos extremos del túnel y que el IP multicast-routing esté habilitado.