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.
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.
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 |
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)
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.
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.
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.
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.
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).
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.
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.
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.
Precaución: Los vecinos PIM no son compatibles con un canal de puerto vPC.
Flujo de tráfico multidifusión
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. |
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. |
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
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)
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
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
Consejo: Antes de analizar el RP automático, las adyacencias de PIM o la selección de RP, asegúrese siempre de que el dominio de routing subyacente sea estable, coherente y totalmente accesible 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)
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
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
Precaución: La resolución de problemas de multidifusión sin una topología clara equivale a una depuración sin visibilidad, ya que da lugar a suposiciones incorrectas y a diagnósticos erróneos.
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).
Nota: N9K-1 y N9K-2 se configuran como RP-Candidatos y Agentes de asignación dentro del dominio de multidifusión.
Precaución: Cualquier configuración de RP automático que falte o sea incoherente puede impedir que los routers aprendan el RP, lo que provoca que el tráfico multicast no se reenvíe correctamente.
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
En esta topología:
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:
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:
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:
Este comando valida:
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:
Se espera este comportamiento en esta topología.
RPA de RP automático: 10.2.1.5*
Auto-RP RPA: 10.2.1.5*
Esto significa:
Siguiente mensaje de descubrimiento en
next Discovery message in: 00:00:39
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
Primera entrada RP
RP: 10.2.0.1*, (0),
Esto confirma que N9K-1 está configurado como RP-Candidate.
Tiempo de actividad y prioridad
uptime: 22:18:44 priority: 255,
Origen RP
RP-source: 10.2.0.1 (A),
Intervalo de grupo
224.10.20.0/24
Segunda entrada RP
RP: 10.2.0.4, (0),
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
Importante diferencia de RP
RP-source: 10.2.1.5 (A),
Esto confirma que:
El RP automático utiliza dos funciones de plano de control de multidifusión diferentes:
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:
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:
Estos anuncios contienen:
En esta topología:
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:
Ambos RP-Candidatos también utilizan:
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:
En esta topología:
Debido a que ambos RP-Candidatos tienen la misma prioridad:
Por lo tanto:
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:
Precaución: En el Agente de mapeo, deben aparecer todos los RP-Candidatos dentro del mismo dominio multicast. Si falta algún RP-Candidate, verifique la disponibilidad enviando un ping a la dirección IP RP-Candidate originada en la dirección IP del agente de mapeo, normalmente una interfaz de loopback.
Todos los routers multicast que participan en el dominio de modo disperso de PIM deben mantener una disponibilidad IP estable para:
Esta validación es crítica porque el modo disperso de PIM depende del ruteo unicast para:
Si falla la disponibilidad hacia RP o el agente de mapeo:
La tabla de ruteo debe contener rutas de unidifusión estables hacia:
Las rutas deben permanecer continuamente instaladas sin inestabilidad de ruta ni eventos de reconvergencia excesivos.
Controle lo siguiente:
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
Después de validar la tabla de ruteo, verifique la disponibilidad de IP de extremo a extremo hacia:
El ping debe originarse en:
Esta validación es importante porque los routers multicast utilizan estas direcciones de origen durante:
Consejo: Si se utilizan interfaces no numeradas, donde varias interfaces de Capa 3 comparten la misma dirección IP desde una interfaz de loopback, la verificación de la accesibilidad se simplifica porque una única dirección IP de origen se puede utilizar de manera consistente.
| 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 |
El siguiente paso de validación consiste en comprobar que:
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:
En esta topología:
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:
Se espera este comportamiento porque:
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
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:
Este estado es importante porque valida:
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:
Se espera este comportamiento porque:
La única entrada de multidifusión presente es:
Corresponde al intervalo SSM predeterminado y el sistema lo instala automáticamente.
Se esperan estos valores:
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:
Se espera este comportamiento porque:
La tabla de ruteo multicast confirma:
Esto indica que:
En esta etapa:
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:
Por lo tanto, el RP contiene el estado de árbol compartido (*,G) para 224.10.20.10
Se esperan estos valores:
Esto indica que:
En esta etapa:
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:
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:
En este escenario específico:
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:
La entrada de ruteo multicast confirma:
Se espera este comportamiento porque el flujo de multidifusión no hash hacia FHR-1 para el reenvío saliente.
Como resultado:
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:
Esto indica que:
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:
Esto confirma que:
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:
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
Las funciones operativas de vPC influyen de forma diferente en el comportamiento de reenvío de multidifusión para:
En esta topología:
Ambos switches Nexus pueden:
Sin embargo:
Esta distinción es importante porque:
Por lo tanto:
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)
El LHR ahora contiene ambos:
Esto confirma:
La entrada (S,G) confirma:
Este comportamiento se confirma con éxito:
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:
Esto confirma el éxito:
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)
N9K-2 funciona como RP activo para el grupo multicast.
El RP contiene:
Se espera la ausencia de interfaces salientes en la entrada (S,G) porque:
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.
Consejo: La recopilación de esta información durante los periodos de trabajo y de descanso proporciona una visión clara de cómo aparece el problema desde la perspectiva de Nexus y mejora significativamente la capacidad de identificar la causa raíz.
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
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:
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
1.0 |
13-May-2026
|
Versión inicial |