Resolución de problemas de multidifusión de RP automático en Nexus 9000 con NX-OS

Introducción

Este documento describe cómo funciona Auto-RP en Cisco Nexus 9000 con NX-OS y cómo validar y solucionar problemas de funcionamiento multidifusión.

Prerequisites

Requirements

• Conocimientos básicos sobre IP Multicast
• Conocimiento básico de IGMP y modo disperso de PIM
• Experiencia con Cisco Nexus 9000 y NX-OS CLI
• Comprensión de los conceptos de routing unidifusión y RPF

Componentes Utilizados

• Switches de la serie Cisco Nexus 9000
• Software Cisco NX-OS
• Modo disperso de PIM
• RP estático y RP automático

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.

Descripción General de Multicast

La multidifusión es un modelo de comunicación de uno a varios en el que un origen envía un único flujo de tráfico a varios receptores interesados. En lugar de crear una copia independiente para cada destino, la red replica el tráfico sólo donde se bifurca la ruta de reenvío. Esto hace que la multidifusión sea más eficaz que las transmisiones de difusión o unidifusión repetida. En IPv4, el tráfico de multidifusión utiliza direcciones de destino del intervalo 224.0.0.0/4.

El modo disperso de PIM es el modelo de routing multidifusión compatible con los switches Cisco Nexus que ejecutan NX-OS. Reenvía el tráfico solo cuando el interés del receptor se ha aprendido explícitamente. En un diseño de multidifusión de cualquier fuente, los receptores se unen inicialmente a un árbol compartido hacia el punto de encuentro y los orígenes se registran con ese RP. Después de que el tráfico comience a fluir, el router de último salto puede moverse del árbol compartido al árbol de trayectoria más corta hacia el origen.

Es importante definir la terminología utilizada en la multidifusión, ya que la resolución de problemas precisa depende de la comprensión de cómo se representan los eventos del plano de control, las entradas de enrutamiento y las decisiones de reenvío. La terminología clara ayuda a interpretar correctamente el resultado de los comandos, a distinguir entre el comportamiento del árbol compartido y el del árbol de origen, y a identificar la función de cada componente de multidifusión en el proceso de reenvío de extremo a extremo.

Término	Definición
Dirección de grupo de multidifusión	Una dirección de destino IPv4 en el rango 224.0.0.0/4 utilizada para identificar un grupo multicast.
Dirección de la fuente	La dirección IP de unidifusión del remitente que transmite el tráfico a un grupo de multidifusión.
mroute	Entrada de enrutamiento de multidifusión que define cómo se gestiona el tráfico de multidifusión para una combinación de grupo de origen o de grupo de origen.
IIF	Interfaz entrante. La interfaz en la que se espera que llegue el tráfico multicast.
OIF	Interfaz saliente. Interfaz utilizada para reenviar el tráfico de multidifusión hacia los receptores o los vecinos descendentes.
PETRÓLEO	Lista de interfaces salientes. El conjunto de interfaces salientes asociadas con una entrada de ruteo multicast.
RPF	Reenvío de Trayectoria Inversa. Una verificación que verifica si el tráfico multicast llegó a la interfaz correcta basada en la ruta unicast hacia el origen o el RP.
MDT	Árbol de distribución de multidifusión. Árbol lógico que transporta el tráfico de multidifusión desde el origen a todos los receptores.
RPT	Árbol RP, también denominado árbol compartido. Conecta los receptores al RP y está representado por (*,G).
SPT	Árbol de trayecto más corto, también denominado árbol de origen. Conecta los receptores directamente con la fuente y está representado por (S,G).
FHR	Router de primer salto. El router multicast se conectó directamente con el origen y es responsable del registro de origen con el RP.
LHR	Router de último salto. El router multicast se conecta directamente a los receptores y es responsable de crear el estado multicast después de conocer el interés del receptor a través de IGMP.
RP	Punto de encuentro. Punto de reunión lógico utilizado en ASM y en el modo disperso de PIM para conectar orígenes y receptores inicialmente.
ASM	Multidifusión de cualquier fuente. Modelo de multidifusión en el que los receptores se unen a un grupo sin especificar previamente el origen.

Es importante comprender las Direcciones Multicast Reservadas Bien Conocidas porque la resolución de problemas de multidifusión depende de identificar rápidamente qué protocolo de control está utilizando un grupo de destino determinado y qué función sirve el tráfico en la red. Estas direcciones ayudan a distinguir el funcionamiento normal del protocolo del comportamiento anormal y facilitan la validación de los intercambios IGMP, PIM y RP automático. Para Auto-RP específicamente, los grupos más importantes a reconocer son 224.0.1.39 para RP-Announce y 224.0.1.40 para RP-Discovery, porque llevan la información que permite que los routers aprendan las asignaciones RP dinámicas.

Dirección Multicast	Propósito
224.0.0.1	Todos los hosts de la subred local
224.0.0.2	Todos los routers de la subred local
224.0.0.13	Todos los routers PIM
224.0.0.22	Mensajes IGMPv3
224.0.1.39	Mensajes Cisco RP-Announce utilizados por Auto-RP
224.0.1.40	Mensajes de detección de RP de Cisco utilizados por RP automático

Funcionamiento de RP automático en modo disperso de PIM (flujo de trabajo del plano de control)

El RP automático es un mecanismo de Cisco que se utiliza en el modo disperso de multidifusión independiente de protocolo para detectar y distribuir dinámicamente la información del punto de encuentro (RP) a través del dominio de multidifusión. Elimina la necesidad de una configuración RP estática mediante el uso de mensajes de plano de control basados en multidifusión para anunciar, seleccionar y aprender asignaciones RP a grupo. Sus componentes principales son RP candidatos, que ofrecen servicios RP para rangos de grupos específicos, y agentes de mapeo, que recopilan candidatos y deciden el RP activo por grupo.

El proceso comienza cuando cada RP candidato envía periódicamente mensajes RP-Announce a 224.0.1.39, incluyendo su dirección IP, prioridad e intervalos de grupos multicast soportados. Estos mensajes se inundan en toda la red mediante el receptor de RP automático en NX-OS, lo que garantiza que todos los agentes de asignación los reciban incluso antes de que la red funcione completamente en modo disperso.

Los agentes de asignación escuchan estos anuncios, crean una base de datos RP candidata y realizan un proceso de selección determinista por grupo (normalmente la prioridad más alta y, a continuación, la dirección IP más alta). Una vez que se elige el mejor RP, el agente de mapeo genera mensajes de detección RP y los envía a 224.0.1.40, anunciando las asignaciones finales RP a grupo a todos los routers del dominio.

Todos los routers PIM reciben los mensajes RP-Discovery e instalan las asignaciones en sus tablas RP locales. Con esta información, los routers de último salto (conectados a los receptores) envían mensajes de unión a PIM hacia el RP seleccionado para crear el árbol compartido (RPT), mientras que los routers de primer salto (conectados a las fuentes) encapsulan el tráfico multicast en los mensajes de registro PIM para informar al RP sobre las fuentes activas.

A medida que el tráfico fluye a través del RP, los routers pueden opcionalmente pasar del árbol compartido (RPT) a un árbol de trayectoria más corta (SPT) mediante la señalización adicional de unión/separación de PIM directamente hacia el origen. A lo largo de este proceso, el RP automático actualiza continuamente las asignaciones a través de mensajes de control periódicos, lo que garantiza la resistencia y la adaptación automática a los cambios de la topología o del RP.

Funcionamiento de RP automático en modo disperso de PIM (flujo de trabajo del plano de control)

Limitaciones de RP automático y limitaciones operativas

• El RP automático funciona solo con multidifusión IPv4 y no es compatible con IPv6 (PIM6), por lo que las implementaciones de IPv6 requieren un mecanismo de detección de RP diferente.
• El RP automático no puede coexistir con el BSR dentro del mismo dominio PIM, porque sólo se puede configurar un mecanismo de detección RP para evitar conflictos del plano de control.
• Los mensajes RP automáticos no se procesan ni reenvían de forma predeterminada en los dispositivos NX-OS, por lo que se requiere una configuración explícita para un funcionamiento correcto.
• La propagación de los mensajes de control de RP automático depende de la habilitación del receptor de RP automático; de lo contrario, la información de mapeo RP no llega a todos los routers.
• El intervalo de anuncio RP tiene un umbral mínimo de 15 segundos, que limita la rapidez con la que se pueden anunciar las actualizaciones RP y afecta al tiempo de convergencia.
• El filtrado automático de mensajes RP a través de mapas de ruta puede afectar al funcionamiento, ya que las políticas incorrectas pueden bloquear las asignaciones RP a grupos.
• El RP automático está desactivado de forma predeterminada en los contextos VRF, por lo que debe estar activado explícitamente en las implementaciones de varios VRF.

• El reenvío de múltiples rutas basado en ECMP está habilitado de forma predeterminada, lo que permite que el tráfico de multidifusión utilice rutas de igual coste para el equilibrio de carga.

• Se admite la autenticación de vecino PIM mediante IPsec AH-MD5.

• La detección de PIM no está disponible.

Ventajas del uso de RP automático

El RP automático proporciona detección de RP dinámica y distribución de asignación de RP centralizada para entornos de multidifusión de modo disperso de PIM. Elimina la necesidad de una configuración RP estática en cada router de multidifusión, reduce la complejidad operativa y mejora la escalabilidad de multidifusión. Auto-RP también soporta múltiples RP-Candidatos, habilitando la redundancia y failover RP automático. Este mecanismo ayuda a mantener un comportamiento de reenvío de multidifusión coherente, simplifica la expansión de la red y permite que los routers de multidifusión aprendan automáticamente la información de RP en todo el dominio.

Agente de mapeo RP automático y proceso de selección RP

El proceso de selección en RP automático es determinista y se basa principalmente en direcciones IP. A diferencia de otros protocolos (como PIMv2 BSR), Auto-RP no utiliza un valor de "prioridad" configurable; en su lugar, se basa en la jerarquía de direcciones IP para resolver conflictos.

Selección de agente de asignación (MA)

En RP automático, varios agentes de asignación pueden coexistir dentro de la misma red para obtener redundancia. No hay un proceso electoral formal donde uno se apaga y otro se enciende; todos están técnicamente activos. Sin embargo, los switches de la red deben decidir en qué información confiar.

• Criterio de selección: Dirección IP más alta.
• El proceso:
  1. Todos los agentes de mapeo envían sus mensajes de RP-Discovery al grupo multicast 224.0.1.40.
  2. Los switches cliente reciben estos mensajes.
  3. Si un switch recibe mensajes de detección de dos agentes de asignación diferentes que contienen información conflictiva, el switch acepta la información del agente de asignación con la dirección IP de origen más alta.
  4. Comportamiento de Nexus: Un agente de mapeo con una dirección IP más baja normalmente ingresa en un estado "pasivo" o "de supresión" al detectar otro MA con una dirección IP más alta para evitar el tráfico de control duplicado en la red.

Selección del punto de encuentro (RP)

Este proceso es realizado por el agente de mapeo después de escuchar todos los mensajes RP-Announce (enviados al grupo 224.0.1.39) de los candidatos.

Cuando el agente de asignación recibe varios candidatos para el mismo grupo de multidifusión, aplica estas reglas en orden:

Regla A: Coincidencia de prefijo más larga (máscara más específica)

Si los candidatos anuncian rangos superpuestos, el MA asigna el grupo al RP que anunció el rango más pequeño (la máscara de subred más larga).

• Ejemplo:
  • El candidato A anuncia 224.0.0.0/4 (the (intervalo de multidifusión completo).
  • El candidato B anuncia 224.10.20.0/24.
  • Resultado: Para el grupo 224.10.20.5, el Candidato B gana porque su rango es más específico.

Regla B: Dirección IP más alta (desempate)

Si dos o más candidatos anuncian exactamente el mismo rango de grupo, el agente de asignación debe elegir sólo uno.

• Criterio: El candidato con la dirección IP más alta gana.
• Ejemplo:
  • Candidato 1: 10.2.0.1 para el rango 224.10.20.0/24.
  • Candidato 2: 10.2.0.4 para el rango 224.10.20.0/24.
  • Resultado: El agente de mapeo selecciona 10.2.0.4 como RP oficial para ese rango y esto se anuncia en sus mensajes de detección.

Consideraciones sobre la capa 2: MAC de multidifusión y detección

Aunque el objetivo de este artículo es la multidifusión de capa 3 mediante PIM, el comportamiento de la capa 2 desempeña un papel fundamental en la resolución de problemas y el diseño general. En la capa 2, los dispositivos se comunican mediante direcciones MAC, que son identificadores de 48 bits asignados a interfaces de red, y el tráfico de multidifusión requiere un esquema de direcciones MAC específico para diferenciarlo del tráfico de unidifusión y difusión.

Las direcciones MAC de multidifusión IPv4 se derivan de las direcciones de grupo de multidifusión de capa 3 mediante el prefijo reservado `01:00:5E`. Sin embargo, sólo 23 bits de la dirección IP multicast se mapean en la dirección MAC, lo que crea un solapamiento 32:1, lo que significa que hasta 32 grupos IP multicast diferentes pueden mapearse a la misma dirección MAC. Como resultado, los hosts que escuchan una dirección MAC de multidifusión determinada pueden recibir tráfico para varios grupos de multidifusión, incluso si sólo están interesados en uno. Por ejemplo, 224.1.1.1, 225.1.1.1, 226.1.1.1, 227.1.1.1, 228.1.1.1 y más.

Este solapamiento tiene implicaciones directas para la eficacia de la red y la resolución de problemas. Dado que las decisiones de reenvío de capa 2 basadas únicamente en direcciones MAC no pueden distinguir entre grupos de multidifusión superpuestos, los switches pueden entregar tráfico innecesario a los hosts. Estos hosts deben depender de un filtrado de capa superior (IP/IGMP) para descartar paquetes no deseados, lo que consume recursos de CPU y búfer.

En Cisco Nexus NX-OS, esta limitación se ve mitigada por el comportamiento de la detección de IGMP. De forma predeterminada, la indagación IGMP realiza búsquedas basadas en IP en lugar de reenviar sólo MAC, lo que permite a los switches tomar decisiones de reenvío más precisas incluso cuando varios grupos de multidifusión comparten la misma dirección MAC. Esto mejora significativamente la eficacia de la capa 2 y reduce la entrega de tráfico innecesario.

Configuración de RP automática

Esta sección proporciona una explicación detallada de la configuración Auto-RP, usando una implementación simple como referencia. En esta configuración, una fuente de multidifusión se conecta a dos switches Nexus a través de vPC para enviar tráfico a un receptor. En este diseño, tanto N9K-1 como N9K-2 funcionan simultáneamente como candidatos RP y agentes de asignación.

Flujo de tráfico multidifusión

Router de primer salto

La misma configuración tiene FHR-2.

FHR-1# show running-config pim
feature pim
ip pim auto-rp forward listen

interface Vlan1
  ip pim sparse-mode

interface Ethernet1/1
  ip pim sparse-mode

interface Ethernet1/3
  ip pim sparse-mode

Comando	Objetivo/Descripción
feature pim	Habilita el proceso PIM (Protocol Independent Multicast) en el switch.
ip pim auto-rp forward listen	Habilita el receptor de RP automático. Esto permite que el switch reciba y reenvíe mensajes de control de RP automático (224.0.1.39 y 224.0.1.40) incluso si aún no conoce la identidad del RP.
ip pim sparse-mode	Habilita el modo disperso de PIM en una interfaz específica. En este modo, el tráfico multidifusión sólo se reenvía a los segmentos que lo han solicitado explícitamente a través de los mensajes de unión PIM.

Agente de asignación y candidato RP

N9K-1# show running-config pim
feature pim

ip pim auto-rp rp-candidate loopback0 group-list 224.10.20.0/24 interval 15
ip pim auto-rp mapping-agent loopback1

interface loopback0
  ip pim sparse-mode

interface loopback1
  ip pim sparse-mode

interface Ethernet1/3
  ip pim sparse-mode

interface Ethernet1/4
  ip pim sparse-mode

interface Ethernet1/49
  ip pim sparse-mode

Esta tabla proporciona un desglose técnico detallado de la configuración de PIM para N9K-1. Esta configuración se replica en N9K-2. Ambos switches se configuran con un rol dual, que actúa como candidato de RP y agente de asignación para el dominio de multidifusión.

Comando	Explicación técnica detallada
feature pim	Activación de funciones: Habilita globalmente el motor de multidifusión independiente de protocolo (PIM) en el switch Nexus.
ip pim auto-rp rp-candidate loopback0 group-list 224.10.20.0/24 interval 15	Función de candidato de RP: Configura este switch como "voluntario" como el punto de encuentro (RP). Fuente: Utiliza la dirección IP de loopback0 Alcance: Ofrece para manejar el rango de grupo multicast 224.10.20.0/24. Intervalo: Envía mensajes "Anunciar" al agente de asignación cada 15 segundos. El temporizador de espera es tres veces este valor.
ip pim auto-rp mapping-agent loopback1	Función de agente de asignación: Configura el switch como el "administrador" del proceso RP automático. Función: Escucha a todos los candidatos RP, resuelve conflictos (usando la dirección IP más alta como desempate) y transmite los mensajes de "detección" al resto de la red para informarles quién es el RP activo.
interface loopback0 / loopback1	Interfaces lógicas: PIM está habilitado en estas interfaces porque sirven como IP de origen para los roles de candidato RP y agente de asignación. Deben ser accesibles a través de la tabla de ruteo unicast desde todos los routers PIM.
interface Ethernet1/3, 1/4, 1/49	Reenvío físico: Habilita el modo disperso de PIM en los puertos físicos. Esto permite que el switch forme adyacencias de vecino PIM con otros routers y reenvíe el tráfico multicast a través de estos links específicos.
ip pim sparse-mode	Modo operativo: Se aplica a todas las interfaces anteriores. Garantiza que el tráfico multidifusión solo se envíe a los receptores que lo han solicitado explícitamente a través de los mensajes de incorporación PIM, evitando así la inundación innecesaria de la red.

Configuración de routing para disponibilidad de IPv4

• En esta topología, todos los switches Nexus participan en un único proceso OSPF denominado UNDERLAY, que funciona dentro del área 0 (0.0.0.0) para proporcionar una disponibilidad de routing total a través de la red.
• En el LHR, OSPF se habilita en la VLAN 2, que sirve como el gateway para el receptor multicast, y en las interfaces de link ascendente Ethernet1/49 y Ethernet1/50, ambas configuradas como punto a punto. Esto garantiza una formación de adyacencia eficiente hacia los switches ascendentes N9K sin elecciones DR/BDR.
• La capa FHR (FHR-1 y FHR-2) comparte una configuración idéntica. OSPF está habilitado en la VLAN 1, que actúa como el gateway para el origen de multidifusión, y en los enlaces ascendentes enrutados (Ethernet1/1 y Ethernet1/3) hacia la capa de agregación. Estos enlaces también se configuran como punto a punto, lo que optimiza la convergencia y el comportamiento de adyacencia.
• De manera similar, N9K-1 y N9K-2 tienen configuraciones OSPF idénticas, con la adición de Loopback0 y el anuncio Loopback1 en OSPF.
  • Estos loopbacks son críticos, ya que se utilizan más adelante para los roles de candidato RP PIM y agente de mapeo.

Vecinos PIM y Área OSPF 0

N9K-1 — Configuración OSPF

N9K-1(config)# show running-config ospf
feature ospf

router ospf UNDERLAY
  router-id 10.2.0.1

interface loopback0
  ip router ospf UNDERLAY area 0.0.0.0

interface loopback1
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/3
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/4
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/49
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

FHR-1 — Configuración OSPF

FHR-1(config)# show running-config ospf
feature ospf

router ospf UNDERLAY

interface Vlan1
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/1
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/3
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

LHR — Configuración OSPF

LHR(config)# show running-config ospf
feature ospf

router ospf UNDERLAY

interface Vlan2
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/49
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/50
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

Verificación del estado operativo y resolución de problemas de RP automático

Paso 1: Verificar el alcance IP básico (validación de la capa de unidifusión)

Antes de analizar el comportamiento de multidifusión, es fundamental validar que la capa subyacente de unidifusión (área OSPF 0) esté completamente operativa. Los protocolos del plano de control de multidifusión, como PIM y RP automático, dependen de la disponibilidad de unidifusión para funcionar correctamente.

El primer paso de validación es confirmar que el origen y el receptor (o sus gateways de capa 3 más cercanos: FHR y LHR).

Desde la topología:

• FHR-1 / FHR-2 → Más cercano a la fuente de multidifusión (10.150.1.37 - VLAN 1)

• LHR → Próximo al receptor de multidifusión (192.168.2.37 - VLAN 2)

Enfoque de validación

1. Realice pruebas de accesibilidad ICMP entre:

• FHR ↔ LHR

• FHR ↔ Subred del receptor (gateway VLAN 2)

• LHR ↔ Subred de origen (gateway VLAN 1)

2. Valide el origen y la disponibilidad del receptor en la tabla de ruteo. En el caso de implementaciones vPC, garantice la uniformidad entre los dos switches Nexus. Observe que el receptor tiene una trayectoria ECMP, mientras que el origen es alcanzable a través de la Capa 2.

FHR-1: ruta al origen

FHR-1# show ip route 10.150.1.37

10.150.1.37/32, ubest/mbest: 1/0, attached
    *via 10.150.1.37, Vlan1, [250/0], 06:57:19, am

FHR-1: ruta al receptor

FHR-1# show ip route 192.168.2.37

192.168.2.0/24, ubest/mbest: 2/0
    *via 10.4.0.6, Eth1/3, [110/45], 04:11:08, ospf-UNDERLAY, intra
    *via 10.4.0.10, Eth1/1, [110/45], 04:11:08, ospf-UNDERLAY, intra

FHR-2 — Ruta al origen

FHR-2# show ip route 10.150.1.37

10.150.1.37/32, ubest/mbest: 1/0, attached
    *via 10.150.1.37, Vlan1, [250/0], 07:03:45, am

FHR-2 — Ruta al receptor

FHR-2# show ip route 192.168.2.37

192.168.2.0/24, ubest/mbest: 2/0
    *via 10.4.0.13, Eth1/3, [110/45], 04:16:16, ospf-UNDERLAY, intra
    *via 10.4.0.18, Eth1/4, [110/45], 04:16:16, ospf-UNDERLAY, intra

LHR — Ruta al origen

LHR(config)# show ip route 10.150.1.37

10.150.1.0/24, ubest/mbest: 2/0
    *via 10.4.0.22, Eth1/49, [110/45], 04:14:52, ospf-UNDERLAY, intra
    *via 10.4.0.26, Eth1/50, [110/45], 04:14:52, ospf-UNDERLAY, intra

LHR — Ruta al receptor

LHR(config)# show ip route 192.168.2.37

192.168.2.37/32, ubest/mbest: 1/0, attached
    *via 192.168.2.37, Vlan2, [250/0], 06:47:21, am

Consideraciones importantes

• El fallo de esta prueba indica claramente un problema subyacente.

• La multidifusión no puede funcionar correctamente sin disponibilidad de unidifusión, ya que:

  • Los vecinos PIM dependen del routing unidifusión

  • Las direcciones RP (loopback) deben ser accesibles

  • Las verificaciones de RPF (Reverse Path Forwarding) dependen de la tabla de ruteo

• Un ping exitoso no garantiza que la multidifusión pueda funcionar, porque:

  • Se puede permitir ICMP mientras la multidifusión está bloqueada

  • PIM o RP automático pueden seguir estando mal configurados

Paso 2: Identificación de funciones de multidifusión y topología de extremo a extremo

El siguiente paso consiste en identificar claramente la función de cada dispositivo implicado en el reenvío del tráfico de multidifusión. Este es un paso obligatorio, ya que la resolución de problemas de multidifusión depende completamente de la comprensión del flujo de tráfico y del comportamiento esperado en toda la topología.

Como mínimo, deben identificarse estos elementos:

• Fuente de multidifusión (S): 10.150.1.37 (VLAN 1)

• Grupo de multidifusión (G): 224.10.20.10

• Receptor: 192.168.2.37 (VLAN 2)

• Router de primer salto (FHR): FHR-1 / FHR-2 (más cercano a la fuente)

• Router de último salto (LHR): LHR (más cercano al receptor)

Además, es necesario identificar las funciones del plano de control:

• Candidatos RP: N9K-1 y N9K-2 (Loopback0)

• Asignación de agentes: N9K-1 y N9K-2 (bucle invertido 1)

Reconocimiento de topología y plano de control

Es obligatorio contar con una topología de red detallada para continuar con cualquier solución de problemas de multidifusión. Esto incluye:

• Conectividad física (interfaces utilizadas entre dispositivos)

• Topología lógica (VLAN, enlaces enrutados, relaciones vPC)

• Protocolo de routing en uso (área OSPF 0 en este diseño)

• Límites de dominio de routing (IGP único frente a protocolos mixtos como OSPF, EIGRP o BGP)

• Interfaces de loopback utilizadas para RP y funciones de agente de asignación

• Interfaces habilitadas para PIM y relaciones de vecinos

Lo que debe entenderse claramente

• La ruta exacta desde el origen → FHR → RP → LHR → Receptor

• Qué dispositivos son responsables de:

  • Envío del registro PIM (FHR)

  • Árboles de construcción (*,G) o (S,G) (LHR)

  • Información de RP de publicidad (agente de asignación)

• Cómo el routing (OSPF) garantiza la disponibilidad para:

  • Subred de origen

  • Subred del receptor

  • direcciones de loopback RP

  • Mapping Agent Loopback Addresses

Paso 3: Validar configuración de RP automática basada en la función del dispositivo

El siguiente paso es verificar que Auto-RP esté correctamente configurado en cada dispositivo de acuerdo con su función en la topología multicast. Esto incluye confirmar que:

• Los candidatos RP (N9K-1 / N9K-2) están correctamente configurados para anunciar su Loopback0 como RP para el rango de grupos multicast.

• Los agentes de asignación (N9K-1 / N9K-2) se configuran para recopilar mensajes RP-Announce y generar mensajes RP-Discovery mediante Loopback1.

• FHR y LHR tienen habilitado el modo disperso de PIM en todas las interfaces relevantes para participar en el RP automático y recibir mapeos RP.

Es esencial asegurarse de que todas las interfaces requeridas (incluidos los loopbacks y los links enrutados) estén habilitadas para el modo disperso de PIM y que no falten configuraciones que impidan el intercambio de mensajes RP-Announce (224.0.1.39) y RP-Discovery (224.0.1.40).

Paso 4: Validar el funcionamiento de todos los candidatos RP y todos los agentes de asignación

Paso 4.1 Verificación de las Adyacencias del Vecino PIM

El primer paso de validación es confirmar que todos los vecinos PIM esperados se establecen correctamente en la topología de multidifusión.

N9K-1: Verificar vecinos PIM

N9K-1# show ip pim neighbor

PIM Neighbor Status for VRF "default"
Neighbor        Interface            Uptime    Expires   DR       Bidir-  BFD    ECMP Redirect
                                                         Priority Capable State     Capable
10.4.0.5        Ethernet1/3          23:19:45  00:01:20  1        yes     n/a     no
10.4.0.14       Ethernet1/4          23:19:45  00:01:38  1        yes     n/a     no
10.4.0.21       Ethernet1/49         23:19:45  00:01:38  1        yes     n/a     no

N9K-2: Verificar vecinos PIM

N9K-2# show ip pim neighbor

PIM Neighbor Status for VRF "default"
Neighbor        Interface            Uptime    Expires   DR       Bidir-  BFD    ECMP Redirect
                                                         Priority Capable State     Capable
10.4.0.9        Ethernet1/3          23:21:18  00:01:29  1        yes     n/a     no
10.4.0.17       Ethernet1/4          23:21:18  00:01:23  1        yes     n/a     no
10.4.0.25       Ethernet1/49         23:21:18  00:01:44  1        yes     n/a     no

Puntos de validación

• Verifique que todos los vecinos esperados aparezcan en cada interfaz ruteada.
• Verifique que el tiempo de actividad del vecino sea estable y aumente continuamente.
• Compruebe que el temporizador Vence se actualiza periódicamente.
• Verifique que no se produzca ninguna inestabilidad de adyacencia inesperada.
• Verifique que la elección del router designado (DR) sea correcta.
• Verifique que las interfaces multicast formen adyacencias PIM exitosamente.

En esta topología:

• N9K-1 establece tres vecinos PIM.
• N9K-2 también establece tres vecinos PIM.
• Todas las adyacencias permanecen estables durante más de 23 horas, lo que indica un funcionamiento estable del plano de control de multidifusión.

---

Paso 4.2 Verificación de las Interfaces Habilitadas para PIM

El siguiente paso es confirmar que todas las interfaces que participan en el RP automático están habilitadas para PIM.

Esta validación es especialmente importante para:

• Loopbacks de candidatos a RP
• Asignación de loopbacks del agente

N9K-1 — Verificar interfaces PIM

N9K-1# show ip pim interface brief

PIM Interface Status for VRF "default"
Interface            IP Address      PIM DR Address  Neighbor  Border
                                                     Count     Interface
Ethernet1/3          10.4.0.6        10.4.0.6        1         no
Ethernet1/4          10.4.0.13       10.4.0.14       1         no
Ethernet1/49         10.4.0.22       10.4.0.22       1         no
loopback0            10.2.0.1        10.2.0.1        0         no
loopback1            10.2.1.5        10.2.1.5        0         no

N9K-2: Verificar interfaces PIM

N9K-2# show ip pim interface brief

PIM Interface Status for VRF "default"
Interface            IP Address      PIM DR Address  Neighbor  Border
                                                     Count     Interface
Ethernet1/3          10.4.0.10       10.4.0.10       1         no
Ethernet1/4          10.4.0.18       10.4.0.18       1         no
Ethernet1/49         10.4.0.26       10.4.0.26       1         no
loopback0            10.2.0.4        10.2.0.4        0         no
loopback1            10.2.1.4        10.2.1.4        0         no

Puntos de validación:

• Verifique que todas las interfaces multicast ruteadas aparezcan en la salida.
• Verifique que los loopbacks RP-Candidate estén habilitados para PIM.
• Verifique que los loopbacks del agente de mapeo estén habilitados para PIM.
• Verifique que los conteos de vecinos sean correctos en las interfaces de tránsito.
• Verifique que las interfaces de loopback muestren correctamente Neighbor Count = 0.

Asignación de función de bucle invertido:

Dispositivo	Función	Loopback
N9K-1	RP-Candidato	10.2.0.1
N9K-1	Agente de asignación	10.2.1.5
N9K-2	RP-Candidato	10.2.0.4
N9K-2	Agente de asignación	10.2.1.4

Los loopbacks aparecen correctamente como interfaces PIM activas aunque no formen vecinos PIM. Se espera este comportamiento porque las interfaces de loopback no establecen adyacencias multicast directamente.

La presencia de estos loopbacks confirma que:

• PIM puede originar mensajes de control Auto-RP correctamente.
• Los anuncios RP se pueden originar correctamente.
• La funcionalidad del agente de asignación puede funcionar correctamente.

---

Paso 4.3 Analizar show ip pim rp

Este comando valida:

• detección RP
• Anuncios de RP automático
• Operación de asignación de agente
• Asignaciones de grupo a RP

N9K-1 — Información de RP

N9K-1# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5*, next Discovery message in: 00:00:39
BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

RP: 10.2.0.1*, (0),
 uptime: 22:18:44   priority: 255,
 RP-source: 10.2.0.1 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:00:37 (A)

RP: 10.2.0.4, (0),
 uptime: 23:00:32   priority: 255,
 RP-source: 10.2.0.4 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:00:44 (A)

Explicación línea por línea

BSR deshabilitado

BSR disabled

Esto confirma que:

• No se utiliza el router de arranque (BSR).
• El dominio multicast depende exclusivamente de Auto-RP.

Se espera este comportamiento en esta topología.

RPA de RP automático: 10.2.1.5*

Auto-RP RPA: 10.2.1.5*

• 10.2.1.5 corresponde a loopback1 en N9K-1.
• El * indica que el switch local en sí es el agente de mapeo activo.

Esto significa:

• N9K-1 origina mensajes de RP-Discovery.
• N9K-1 recopila los anuncios RP de los candidatos RP.
• N9K-1 distribuye la información de asignación de RP al dominio de multidifusión.

Siguiente mensaje de descubrimiento en

next Discovery message in: 00:00:39

• Compruebe que el temporizador se actualiza continuamente.
• Verifique que los mensajes de detección se envíen periódicamente.

Si este temporizador se congela o caduca inesperadamente, los anuncios de RP automático no se pueden propagar correctamente.

Campos de políticas

BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

• No se aplican políticas de filtrado.
• Se aceptan todos los anuncios de RP y los anuncios de Discovery.

Primera entrada RP

RP: 10.2.0.1*, (0),

• Dirección RP = 10.2.0.1
• El * indica que este RP es local para N9K-1.
• 10.2.0.1 corresponde a loopback0 en N9K-1.

Esto confirma que N9K-1 está configurado como RP-Candidate.

Tiempo de actividad y prioridad

uptime: 22:18:44   priority: 255,

• El tiempo de actividad estable indica una operación de anuncio RP estable.
• La prioridad 255 es la prioridad más alta predeterminada.

Origen RP

RP-source: 10.2.0.1 (A),

• El anuncio RP se originó directamente desde el RP mismo.
• (A) indica información aprendida de RP automático.

Intervalo de grupo

224.10.20.0/24

• Compruebe que se ha anunciado el intervalo de multidifusión correcto.
• Verifique que el rango del grupo coincida con la configuración.

Segunda entrada RP

RP: 10.2.0.4, (0),

• Existe otro RP en la topología.
• 10.2.0.4 corresponde a loopback0 en N9K-2.
• No * aparece porque este RP está remoto desde N9K-1.

N9K-2 — Información de RP

N9K-2# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5, uptime: 22:19:10, expires: 00:02:28

RP: 10.2.0.4*, (0),
 uptime: 23:14:14   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:02:28 (A)

Diferencias clave en N9K-2

Auto-RP RPA: 10.2.1.5

• No * aparece porque N9K-2 no es el agente de asignación.
• N9K-2 aprende la información del agente de asignación de forma remota desde N9K-1.

Importante diferencia de RP

RP-source: 10.2.1.5 (A),

• N9K-2 aprende la información RP del agente de asignación.
• El agente de mapeo es 10.2.1.5.

Esto confirma que:

• Los mensajes de detección automática de RP funcionan correctamente.
• Los anuncios del agente de asignación se propagan correctamente a través del dominio de multidifusión.

Paso 4.4 Validación del Proceso de Elección Auto-RP y Selección RP

El RP automático utiliza dos funciones de plano de control de multidifusión diferentes:

• RP-Candidato
• Agente de asignación

Comprender cómo interactúan estas funciones es crítico cuando se valida la operación de multidifusión en un entorno de modo disperso de PIM.

En esta topología:

• N9K-1 y N9K-2 funcionan como RP-Candidatos.
• N9K-1 funciona como el agente de asignación activo.

Operación RP-Candidate

Un RP-Candidate se anuncia como un punto de encuentro válido para uno o más rangos de grupos multicast.

Cada RP-Candidate envía periódicamente mensajes de Anuncio Auto-RP a:

• 224.0.1.39 — Grupo de anuncios de RP automático
  
  

Estos anuncios contienen:

• dirección RP
• Intervalo de grupo
• Prioridad
• Tiempo en espera

En esta topología:

• 10.2.0.1 en N9K-1 se anuncia como RP.
• 10.2.0.4 en N9K-2 se anuncia como RP.

N9K-1 — Información de RP-Candidate

N9K-1# show ip pim rp
<snip>
RP: 10.2.0.1*, (0),
 uptime: 23:11:22 priority: 255,
 RP-source: 10.2.0.1 (A),
 group ranges:
 224.10.20.0/24 , expires: 00:00:38 (A)

RP: 10.2.0.4, (0),
 uptime: 23:53:09 priority: 255,
 RP-source: 10.2.0.4 (A),
 group ranges:
 224.10.20.0/24 , expires: 00:00:43 (A)

N9K-2 — Información de RP-Candidate

N9K-2# show ip pim rp
<snip>
RP: 10.2.0.4*, (0),
 uptime: 1d00h priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24 , expires: 00:02:52 (A)

Ambos dispositivos anuncian el mismo rango de grupos multicast:

• 224.10.20.0/24

Ambos RP-Candidatos también utilizan:

• Prioridad 255

Esto es importante porque el RP automático utiliza la prioridad y la dirección RP durante la selección del RP.

Identificación del agente de asignación activo

El agente de asignación selecciona el RP activo para un grupo de multidifusión que comienza con esta lógica:

1. La prioridad RP más alta gana.
2. Si las prioridades son iguales, la dirección IP de RP más alta gana.

En esta topología:

• N9K-1 RP address = 10.2.0.1
• N9K-2 RP address = 10.2.0.4
• Ambos candidatos RP utilizan la prioridad 255

Debido a que ambos RP-Candidatos tienen la misma prioridad:

• La dirección IP de RP más alta se convierte en el RP seleccionado.

Por lo tanto:

• 10.2.0.4 se convierte en el RP activo para 224.10.20.0/24.

Validación de RP seleccionada

N9K-2: RP seleccionado

N9K-2# show ip pim rp
<snip>
RP: 10.2.0.4*, (0),
 uptime: 23:14:14   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24

Por qué N9K-1 aún muestra ambas entradas RP

En N9K-1:

N9K-1# show ip pim rp
<snip>
RP: 10.2.0.1*, (0),
RP: 10.2.0.4, (0),

Se espera este comportamiento porque:

• N9K-1 actúa como agente de asignación.
• El agente de asignación mantiene la visibilidad de todos los candidatos RP.
• El resultado muestra todos los anuncios RP aprendidos antes de que se distribuya la selección RP final.

Paso 5: Verificar disponibilidad para RP-Candidatos y agentes de mapeo

Todos los routers multicast que participan en el dominio de modo disperso de PIM deben mantener una disponibilidad IP estable para:

• Todos los candidatos a RP
• Todos los agentes de asignación

Esta validación es crítica porque el modo disperso de PIM depende del ruteo unicast para:

• Alcance el punto de encuentro (RP)
• Crear el árbol de multidifusión compartido (RPT)
• Entregar mensajes de registro PIM desde el router de primer salto (FHR)
• Recibir anuncios de detección de RP automática
• Realizar validación de Reverse Path Forwarding (RPF)

Si falla la disponibilidad hacia RP o el agente de mapeo:

• Los orígenes de multidifusión pueden no registrarse correctamente.
• Los receptores pueden no unirse a los grupos de multidifusión.
• Los anuncios de RP automático no se pudieron propagar correctamente.
• Pueden ocurrir fallas RPF.
• El reenvío del tráfico de multidifusión puede volverse inestable o intermitente.

---

Verificar Entradas De Ruteo Estables

La tabla de ruteo debe contener rutas de unidifusión estables hacia:

• Todos los loopbacks RP
• Todos los loopbacks del agente de asignación
• Todas las interfaces de tránsito multidifusión

Las rutas deben permanecer continuamente instaladas sin inestabilidad de ruta ni eventos de reconvergencia excesivos.

Controle lo siguiente:

• Corrección de la selección del siguiente salto
• Interfaz saliente correcta
• Tiempo de actividad estable de la ruta
• Origen de protocolo de ruteo esperado
• Alcance uniforme de unidifusión en el dominio de multidifusión

---

FHR-1: ruta al candidato RP 10.2.0.1

FHR-1# show ip route 10.2.0.1

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.1/32, ubest/mbest: 1/0
    *via 10.4.0.6, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-1: ruta al candidato RP 10.2.0.4

FHR-1# show ip route 10.2.0.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.4/32, ubest/mbest: 1/0
    *via 10.4.0.10, Eth1/1, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-1: ruta al agente de asignación 10.2.1.5

FHR-1# show ip route 10.2.1.5

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.5/32, ubest/mbest: 1/0
    *via 10.4.0.6, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-1: ruta al agente de asignación 10.2.1.4

FHR-1# show ip route 10.2.1.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.4/32, ubest/mbest: 1/0
    *via 10.4.0.10, Eth1/1, [110/5], 1d02h, ospf-UNDERLAY, intra

---

FHR-2: ruta al candidato RP 10.2.0.1

FHR-2# show ip route 10.2.0.1

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.1/32, ubest/mbest: 1/0
    *via 10.4.0.13, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-2: ruta al candidato RP 10.2.0.4

FHR-2# show ip route 10.2.0.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.4/32, ubest/mbest: 1/0
    *via 10.4.0.18, Eth1/4, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-2: Ruta al agente de asignación 10.2.1.5

FHR-2# show ip route 10.2.1.5

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.5/32, ubest/mbest: 1/0
    *via 10.4.0.13, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-2: Ruta al agente de asignación 10.2.1.4

FHR-2# show ip route 10.2.1.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.4/32, ubest/mbest: 1/0
    *via 10.4.0.18, Eth1/4, [110/5], 1d02h, ospf-UNDERLAY, intra

---

LHR — Route to RP-Candidate 10.2.0.1

LHR# show ip route 10.2.0.1

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.1/32, ubest/mbest: 1/0
    *via 10.4.0.22, Eth1/49, [110/2], 1d02h, ospf-UNDERLAY, intra

LHR — Route to RP-Candidate 10.2.0.4

LHR# show ip route 10.2.0.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.4/32, ubest/mbest: 1/0
    *via 10.4.0.26, Eth1/50, [110/2], 1d02h, ospf-UNDERLAY, intra

LHR — Ruta al agente de asignación 10.2.1.5

LHR# show ip route 10.2.1.5

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.5/32, ubest/mbest: 1/0
    *via 10.4.0.22, Eth1/49, [110/2], 1d02h, ospf-UNDERLAY, intra

LHR — Ruta al agente de asignación 10.2.1.4

LHR# show ip route 10.2.1.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.4/32, ubest/mbest: 1/0
    *via 10.4.0.26, Eth1/50, [110/2], 1d02h, ospf-UNDERLAY, intra

---

Verificación de la Disponibilidad de Ping desde las Interfaces PIM

Después de validar la tabla de ruteo, verifique la disponibilidad de IP de extremo a extremo hacia:

• Todos los candidatos a RP
• Todos los agentes de asignación

El ping debe originarse en:

• Interfaces con PIM
• Interfaces de loopback que participan en el ruteo multicast

Esta validación es importante porque los routers multicast utilizan estas direcciones de origen durante:

• establecimiento de vecino PIM
• Cálculos de RPF
• PIM Register Encapsulation
• Comunicación RP automática

Resumen de validación de ping

Dispositivo	IP de origen	Destino	Función	Resultado
FHR-1	10.4.0.5	10.2.0.1	RP-Candidato	Satisfactorio
FHR-1	10.4.0.5	10.2.0.4	RP-Candidato	Satisfactorio
FHR-1	10.4.0.5	10.2.1.5	Agente de asignación	Satisfactorio
FHR-1	10.4.0.5	10.2.1.4	Agente de asignación	Satisfactorio
FHR-2	10.4.0.9	10.2.0.1	RP-Candidato	Satisfactorio
FHR-2	10.4.0.9	10.2.0.4	RP-Candidato	Satisfactorio
FHR-2	10.4.0.9	10.2.1.5	Agente de asignación	Satisfactorio
FHR-2	10.4.0.9	10.2.1.4	Agente de asignación	Satisfactorio
LHR	10.4.0.5	10.2.0.1	RP-Candidato	Satisfactorio
LHR	10.4.0.5	10.2.0.4	RP-Candidato	Satisfactorio
LHR	10.4.0.5	10.2.1.5	Agente de asignación	Satisfactorio
LHR	10.4.0.5	10.2.1.4	Agente de asignación	Satisfactorio

Verificar el estado operativo y el reenvío de tráfico multidifusión en FHR y LHR

El siguiente paso de validación consiste en comprobar que:

• FHR y LHR aprendieron el RP esperado con éxito.
• La tabla de ruteo multicast contiene los estados multicast esperados.
• El plano de control de multidifusión funciona correctamente antes de que comience la transmisión del tráfico de multidifusión.
• El modo disperso de PIM genera el estado de árbol compartido esperado.

---

Paso 1 Verifique el aprendizaje RP en el FHR y el LHR

Antes de validar el estado de reenvío de multidifusión, compruebe que todos los enrutadores de multidifusión han aprendido el RP esperado para el grupo de multidifusión en la validación.

Este paso es fundamental porque:

• El FHR debe saber dónde enviar los mensajes del registro PIM.
• El LHR debe saber qué RP debe utilizar al construir el árbol compartido.
• El dominio de multidifusión debe mantener una asignación RP coherente.

En esta topología:

• El RP seleccionado es 10.2.0.4.
• El agente de mapeo es 10.2.1.5.
• El rango del grupo multicast es 224.10.20.0/24.

---

FHR-1: Verificar RP Aprendido

FHR-1# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5, uptime: 1d02h, expires: 00:02:30
BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

RP: 10.2.0.4, (0),
 uptime: 1d03h   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:02:30 (A)

FHR-2: Verificar RP Aprendido

FHR-2# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5, uptime: 1d02h, expires: 00:02:15
BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

RP: 10.2.0.4, (0),
 uptime: 1d03h   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:02:15 (A)

LHR — Verificar RP Aprendido

LHR# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5, uptime: 1d02h, expires: 00:02:07
BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

RP: 10.2.0.4, (0),
 uptime: 1d03h   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:02:07 (A)

---

Análisis de aprendizaje de RP

Los resultados confirman que:

• Todos los routers multicast aprendieron el mismo RP de manera consistente.
• El RP seleccionado es 10.2.0.4.
• El mapeo RP se aprendió a través de RP automático.
• El agente de mapeo que distribuye la información RP es 10.2.1.5.
• La asignación RP permanece estable durante más de un día.
• Los temporizadores de vencimiento de detección se actualizan correctamente.

Se espera este comportamiento porque:

• 10.2.0.4 fue seleccionado como RP activo durante el proceso de elección de RP automático.
• 10.2.1.5 funciona como el agente de mapeo.
• Todos los routers de multidifusión reciben correctamente los anuncios de detección automática de RP.

En esta etapa, el plano de control de multidifusión funciona correctamente y todos los routers tienen una asignación RP coherente para 224.10.20.0/24

---

Paso 2 Verifique el Estado del Ruteo Multicast Antes del Tráfico Multicast Activo

El siguiente paso es validar la tabla de ruteo multicast antes de que comience la transmisión del tráfico multicast.

En esta situación:

• El receptor de multidifusión ya se unió al grupo de multidifusión.
• Todavía no fluye ningún tráfico de origen de multidifusión activo.

Este estado es importante porque valida:

• operación de pertenencia IGMP
• creación de árbol compartido PIM
• Estado de multidifusión inicial (*,G)
• Propagación de intereses del receptor

FHR-1: Tabla de Ruteo Multicast

FHR-1# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 232.0.0.0/8), uptime: 23:07:34, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

FHR-2 — Tabla de Ruteo Multicast

FHR-2# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 232.0.0.0/8), uptime: 23:07:37, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

---

Análisis de estado de multidifusión de FHR

Los FHR aún no contienen:

• (* ,G) estado para 24.10.20.10
• (S,G) para el origen de multidifusión

Se espera este comportamiento porque:

• Aún no hay tráfico de origen de multidifusión activo.
• No se han generado mensajes de registro PIM.
• El FHR no ha iniciado el reenvío multidifusión.

La única entrada de multidifusión presente es:

• 232.0.0.0/8

Corresponde al intervalo SSM predeterminado y el sistema lo instala automáticamente.

Se esperan estos valores:

• Interfaz entrante: Nulo
• vecino RPF: 0.0.0.0
• Recuento de interfaces salientes: 0

Esta entrada no indica el reenvío de multidifusión activo.

---

LHR — Tabla de Ruteo Multicast

LHR# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 224.10.20.10/32), uptime: 23:07:39, igmp ip pim
  Incoming interface: Ethernet1/50, RPF nbr: 10.4.0.26
  Outgoing interface list: (count: 1)
    Vlan2, uptime: 23:07:39, igmp

(*, 232.0.0.0/8), uptime: 23:07:39, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

Análisis de estado de multidifusión LHR

A diferencia de los FHR, el LHR contiene una entrada activa (*,G) para:

• 224.10.20.10

Se espera este comportamiento porque:

• El receptor de multidifusión ya se unió al grupo.
• La información de pertenencia a IGMP se aprendió en Vlan2.
• El LHR inició la unión de árbol compartido hacia el RP.

La tabla de ruteo multicast confirma:

• La interfaz entrante (IIF) es Ethernet1/50.
• El vecino RPF es 10.4.0.26.
• La Lista de interfaces salientes (OIL) contiene Vlan2.

Esto indica que:

• El LHR construyó correctamente el árbol compartido hacia el RP.
• El interés del receptor de multidifusión se propagó correctamente en sentido ascendente.
• Los mensajes de PIM Join se transmitieron correctamente.

En esta etapa:

• Aún no hay tráfico de origen de multidifusión activo.
• Aún no existe ningún estado (S,G).
• Sólo existe el estado de árbol compartido.

---

N9K-1 — Asignación de tabla de routing multidifusión de agente

N9K-1# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 232.0.0.0/8), uptime: 1d03h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

Análisis del estado de multidifusión del agente de asignación

N9K-1 funciona solo como agente de asignación y no participa en el reenvío de multidifusión para 224.10.20.10

Por lo tanto, se espera la ausencia de entradas (* ,G) y entradas (S,G).

El agente de mapeo sólo distribuye información de mapeo RP y no participa necesariamente en el reenvío de datos multicast a menos que el tráfico multicast atraviese el dispositivo directamente.

---

N9K-2: Tabla de routing multidifusión RP

N9K-2# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 224.10.20.10/32), uptime: 1d01h, pim ip
  Incoming interface: loopback0, RPF nbr: 10.2.0.4
  Outgoing interface list: (count: 1)
    Ethernet1/49, uptime: 1d01h, pim

(*, 232.0.0.0/8), uptime: 1d03h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

Análisis de estado de multidifusión RP

N9K-2 funciona como RP activo para:

• 224.10.20.0/24

Por lo tanto, el RP contiene el estado de árbol compartido (*,G) para 224.10.20.10

Se esperan estos valores:

• Interfaz entrante = loopback0
• vecino RPF = 10.2.0.4
• Interfaz de salida = Ethernet1/49

Esto indica que:

• El RP instaló correctamente el estado del árbol compartido.
• El RP recibió mensajes de incorporación PIM de los routers de flujo descendente.
• El árbol de multidifusión compartido hacia los receptores se generó correctamente.

En esta etapa:

• El RP sólo contiene el estado de árbol compartido.
• Aún no hay tráfico de origen de multidifusión activo.
• Aún no existen entradas (S,G).

---

Paso 3 Verifique El Estado Del Ruteo Multicast Con El Tráfico Multicast Activo

Una vez que comienza la transmisión del tráfico multicast, la tabla de ruteo multicast pasa del estado del árbol compartido al estado de reenvío específico del origen activo.

En esta situación:

• El origen de multidifusión es 10.150.1.37.
• El grupo multicast es 224.10.20.10.
• El RP activo es 10.2.0.4 en N9K-2.
• El origen de multidifusión se conecta a través del canal de puerto 78 de vPC.

---

Consideraciones importantes sobre la multidifusión vPC

El origen de multidifusión se conecta a través de un dominio vPC formado por FHR-1 y FHR-2.

Debido a que el origen se conecta a través de un canal de puerto miembro de vPC:

• El hashing de tráfico puede reenviar paquetes de multidifusión hacia cualquier switch Nexus.
• Ambos FHR requieren una configuración de multidifusión idéntica.
• Ambos FHR requieren información de ruteo de unidifusión consistente.
• Ambos FHR deben mantener mapeos RP idénticos.
• Ambos FHR deben mantener adyacencias PIM estables.

En este escenario específico:

• El flujo de multidifusión se desvía hacia FHR-2.
• FHR-2 se convierte en el FHR de reenvío activo para el origen de multidifusión.

FHR-1: Tabla de Ruteo Multicast

FHR-1# show ip mroute

IP Multicast Routing Table for VRF "default"

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:03:58, ip pim
  Incoming interface: Vlan1, RPF nbr: 10.150.1.37
  Outgoing interface list: (count: 0)

(*, 232.0.0.0/8), uptime: 1d00h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

FHR-1: función vPC

FHR-1# show vpc role

vPC Role status
----------------------------------------------------
vPC role                        : primary <<<
Dual Active Detection Status    : 0
vPC system-mac                  : 00:23:04:ee:be:01
vPC system-priority             : 32667
vPC local system-mac            : 00:6b:f1:84:02:97
vPC local role-priority         : 32667
vPC local config role-priority  : 32667
vPC peer system-mac             : 6c:b2:ae:ee:5a:97
vPC peer role-priority          : 32667
vPC peer config role-priority   : 32667

Análisis de estado de multidifusión FHR-1

FHR-1 contiene una entrada activa (S,G) para:

• Fuente = 10.150.1.37
• Grupo = 24.10.20.10

La entrada de ruteo multicast confirma:

• La fuente se detectó en Vlan1.
• El vecino RPF es el origen de multidifusión conectado directamente.
• No existen interfaces de salida en el OIL.

Se espera este comportamiento porque el flujo de multidifusión no hash hacia FHR-1 para el reenvío saliente.

Como resultado:

• FHR-1 sólo instala el estado de origen local.
• FHR-1 no reenvía el tráfico de multidifusión ascendente a través de PIM.

FHR-2 — Tabla de Ruteo Multicast

FHR-2# show ip mroute

IP Multicast Routing Table for VRF "default"

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:16:35, ip pim
  Incoming interface: Vlan1, RPF nbr: 10.150.1.37
  Outgoing interface list: (count: 1)
    Ethernet1/3, uptime: 00:16:35, pim

(*, 232.0.0.0/8), uptime: 1d00h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

FHR-2: función vPC

FHR-2# show vpc role

vPC Role status
----------------------------------------------------
vPC role                        : secondary <<<
Dual Active Detection Status    : 0
vPC system-mac                  : 00:23:04:ee:be:01
vPC system-priority             : 32667
vPC local system-mac            : 6c:b2:ae:ee:5a:97
vPC local role-priority         : 32667
vPC local config role-priority  : 32667
vPC peer system-mac             : 00:6b:f1:84:02:97
vPC peer role-priority          : 32667
vPC peer config role-priority   : 32667

Análisis de estado de multidifusión FHR-2

A diferencia de FHR-1, FHR-2 contiene:

• Una lista de interfaces salientes activas
• Una ruta de reenvío PIM activa

Esto indica que:

• FHR-2 se convirtió en el FHR de reenvío operativo para el flujo de multidifusión.
• Los paquetes de multidifusión se dirigen a FHR-2 a través del canal de puerto del miembro vPC.
• FHR-2 encapsuló el tráfico multicast en mensajes de registro PIM.
• FHR-2 reenvió el tráfico multicast ascendente hacia el RP.

Comportamiento de reenvío de ECMP y multidifusión

La interfaz Ethernet1/3 de salida coincide con la tabla de ruteo de unidifusión hacia el receptor 192.168.2.37

FHR-2: Ruta al receptor de multidifusión

FHR-2# show ip route 192.168.2.37

IP Route Table for VRF "default"

'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.168.2.0/24, ubest/mbest: 2/0
    *via 10.4.0.13, Eth1/3, [110/45], 1d02h, ospf-UNDERLAY, intra
    *via 10.4.0.18, Eth1/4, [110/45], 1d02h, ospf-UNDERLAY, intra

FHR-2 contiene dos rutas de igual costo hacia la subred del receptor multicast:

• 10.4.0.13 a través de Ethernet1/3
• 10.4.0.18 a través de Ethernet1/4

Esto confirma que:

• El enrutamiento ECMP está activo en la topología de transporte de multidifusión.
• Existen varias rutas de reenvío de unidifusión válidas hacia la red del receptor.
• PIM puede utilizar la trayectoria RPF seleccionada por MRIB para las decisiones de reenvío multidifusión.
• No se produce la duplicación de paquetes entre rutas ECMP paralelas.

Aunque existen dos rutas de igual costo, el reenvío de multidifusión utiliza una sola ruta RPF para cada flujo de multidifusión.

En esta topología, el flujo de multidifusión utiliza:

• Ethernet1/3 hacia 10.4.0.13

Este comportamiento coincide con la tabla de ruteo multicast observada anteriormente:

(10.150.1.37/32, 224.10.20.10/32)
  Outgoing interface list:
    Ethernet1/3

---

Comportamiento operativo principal y secundario de vPC

Las funciones operativas de vPC influyen de forma diferente en el comportamiento de reenvío de multidifusión para:

• tráfico PIM
• procesamiento IGMP

En esta topología:

• FHR-1 es el vPC principal en funcionamiento.
• FHR-2 es el vPC secundario operativo.

Ambos switches Nexus pueden:

• Procesamiento del tráfico del plano de control PIM
• Generar estado de enrutamiento de multidifusión
• Reenvío de tráfico multidifusión a través de PIM

Sin embargo:

• Solo el vPC operativo procesa el tráfico del receptor IGMP hacia la capa de acceso.

Esta distinción es importante porque:

• El reenvío PIM hacia la red enrutada permanece activo en ambos pares.
• El reenvío de IGMP hacia los segmentos de receptor de la capa 2 permanece centralizado en el primario operativo.

Por lo tanto:

• El tráfico de multidifusión desde el origen hacia el dominio de multidifusión enrutado puede salir a través de cualquiera de los pares vPC.
• El tráfico de multidifusión hacia los receptores IGMP depende del comportamiento principal operativo.

---

LHR — Tabla de Ruteo Multicast

LHR# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 224.10.20.10/32), uptime: 1d00h, igmp ip pim
  Incoming interface: Ethernet1/50, RPF nbr: 10.4.0.26
  Outgoing interface list: (count: 1)
    Vlan2, uptime: 1d00h, igmp

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:06:31, ip mrib pim
  Incoming interface: Ethernet1/49, RPF nbr: 10.4.0.22
  Outgoing interface list: (count: 1)
    Vlan2, uptime: 00:06:31, mrib

(*, 232.0.0.0/8), uptime: 1d00h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

Análisis de estado de multidifusión LHR

El LHR ahora contiene ambos:

• (* ,G) estado de árbol compartido
• (S,G) estado del árbol de origen

Esto confirma:

• El receptor de multidifusión se unió correctamente.
• El origen de multidifusión se activó.
• El LHR pasó del reenvío de árbol compartido al reenvío de árbol de origen.

La entrada (S,G) confirma:

• La ruta de origen de multidifusión se aprendió correctamente.
• El vecino RPF es 10.4.0.22.
• El tráfico multicast llega a través de Ethernet1/49.
• El tráfico multicast reenvía hacia los receptores de Vlan2.

Este comportamiento se confirma con éxito:

• reenvío PIM
• validación de RPF
• Construcción del árbol de origen
• Entrega de tráfico de multidifusión

---

N9K-1: Tabla de routing multidifusión de tránsito

N9K-1# show ip mroute

IP Multicast Routing Table for VRF "default"

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:06:42, pim ip
  Incoming interface: Ethernet1/4, RPF nbr: 10.4.0.14
  Outgoing interface list: (count: 1)
    Ethernet1/49, uptime: 00:06:42, pim

(*, 232.0.0.0/8), uptime: 1d04h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

Análisis del estado de tránsito N9K-1

N9K-1 funciona como un router multicast de tránsito para el flujo multicast activo.

La entrada de ruteo multicast confirma:

• El tráfico multicast llega desde Ethernet1/4.
• El tráfico de multidifusión se reenvía hacia Ethernet1/49.
• El trayecto de reenvío multicast hacia el LHR está operativo.

Esto confirma el éxito:

• operación de vecino PIM
• validación de RPF
• Reenvío de multidifusión a través de la red de tránsito

---

N9K-2: Tabla de routing multidifusión RP

N9K-2# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 224.10.20.10/32), uptime: 1d02h, pim ip
  Incoming interface: loopback0, RPF nbr: 10.2.0.4
  Outgoing interface list: (count: 1)
    Ethernet1/49, uptime: 1d02h, pim

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:06:50, ip pim mrib
  Incoming interface: Ethernet1/4, RPF nbr: 10.4.0.17, internal
  Outgoing interface list: (count: 0)

(*, 232.0.0.0/8), uptime: 1d04h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

Análisis de estado de multidifusión RP

N9K-2 funciona como RP activo para el grupo multicast.

El RP contiene:

• (* ,G) estado de árbol compartido
• (S,G) estado del árbol de origen

Se espera la ausencia de interfaces salientes en la entrada (S,G) porque:

• El RP ya conmutó los receptores hacia el árbol de trayectoria más corta.
• La ruta de reenvío del árbol compartido ya no es necesaria para el reenvío de multidifusión activo.

Información de multidifusión mínima necesaria para RCA y diagnósticos de estado

La lista de comandos proporciona la recopilación de datos de multidifusión mínima recomendada necesaria para realizar un análisis de causa raíz (RCA) o un diagnóstico de estado de multidifusión adecuados en los switches Nexus de Cisco serie 9000 que ejecutan NX-OS. Estas salidas capturan el estado del plano de control de multidifusión, la programación MRIB, la información de reenvío, el estado operativo de vPC y los detalles de reenvío de hardware. Sin embargo, se puede requerir información adicional dependiendo del escenario de falla. Por ejemplo, la pérdida de paquetes de multidifusión, las caídas de tráfico intermitentes, los problemas de replicación de paquetes, las incoherencias en el reenvío de hardware o el reenvío de multidifusión fuera de servicio a menudo requieren capturas de paquetes directas en el switch Nexus mediante capturas de Ethanalyzer, SPAN o de nivel de hardware. De manera similar, pueden ocurrir inconsistencias transitorias de RPF, cambios de reenvío de ECMP, fallas de programación ASIC o eventos de supresión de IGMP sin generación de registro persistente.

Como resultado, la combinación de los resultados de show tech con las capturas de paquetes y la validación de reenvío mejora significativamente la precisión del diagnóstico y la calidad de RCA. Aunque esta información proporciona una base operativa sólida para la resolución de problemas de multidifusión, no garantiza que una RCA siempre se pueda identificar exclusivamente a partir de estas salidas. Ciertos fallos de multidifusión requieren resolución de problemas adicional, análisis de tráfico en tiempo real, validación a nivel de hardware, correlación de topologías o capturas de paquetes ampliadas para aislar la causa raíz exacta.

Comandos de recopilación de datos de multidifusión mínima

N9K-1# show tech-support multicast >> bootflash:$(SWITCHNAME)-sh-tech-multicast.txt

N9K-1# show tech-support details >> bootflash:$(SWITCHNAME)-sh-tech-det.txt

N9K-1# show tech-support vpc >> bootflash:$(SWITCHNAME)-sh-tech-vpc.txt

N9K-1# show tech-support forwarding multicast >> bootflash:$(SWITCHNAME)-sh-tech-fwd-multicast.txt

N9K-1# show tech-support forwarding l3 multicast detail vdc-all >> bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-multicast.txt

N9K-1# show tech-support forwarding l3 unicast detail vdc-all >> bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-unicast-det.txt

Crear un archivo TAR para exportar

Después de generar los archivos show tech, consolidelos en un solo archivo TAR para la exportación y el análisis. El comando es una sola línea.

N9K-1# tar create bootflash:$(SWITCHNAME)-multicast-logs
bootflash:$(SWITCHNAME)-sh-tech-multicast.txt
bootflash:$(SWITCHNAME)-sh-tech-det.txt
bootflash:$(SWITCHNAME)-sh-tech-vpc.txt
bootflash:$(SWITCHNAME)-sh-tech-fwd-multicast.txt
bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-multicast.txt
bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-unicast-det.txt

La exportación de un único archivo TAR simplifica:

• Cargas de casos de TAC
• flujos de trabajo RCA
• Análisis de registro centralizado
• Correlación de reenvío de multidifusión
• Preservación de fallos históricos

Historial de revisiones

Revisión	Fecha de publicación	Comentarios
1.0	13-May-2026	Versión inicial