Una relación de vecindad PIM que nunca se forma, o que se forma pero elige el DR equivocado, rompe el multicast antes de que IGMP o la tabla de reenvío tengan siquiera la oportunidad de importar. Este es el orden de verificación para el plano de control subyacente — los comandos display exactos para el estado de interfaz PIM, el estado del vecino y la elección de DR, y las causas que siguen repitiéndose en implementaciones reales.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
O la relación de vecindad nunca se forma, o se forma y elige el dispositivo equivocado como DR — y aguas abajo, ambos casos parecen simplemente que el multicast no funciona.
Todo lo que IGMP y la tabla de reenvío multicast hacen aguas abajo depende de que PIM ya haya hecho correctamente dos cosas aguas arriba: formar una relación de vecindad con el router adyacente, y elegir al Router Designado correcto para realmente replicar el tráfico en el segmento. Cuando cualquiera de los dos está mal, IGMP puede estar perfectamente configurado y la tabla de reenvío puede ser exactamente correcta, y el multicast aun así no llegará al usuario — porque el dispositivo que se supone debe reenviar el tráfico a ese segmento no es el que lo hace, o no está ahí en absoluto.
Si la queja real es congelamiento de IPTV o mosaico de video CCTV en lugar de una falla del plano de control, nuestra nota complementaria sobre resolución de problemas de video multicast cubre el lado de IGMP/tabla/ancho de banda de eso; esta trata sobre lo que tiene que ser cierto del lado de PIM antes de que cualquiera de eso siquiera aplique.
Las fallas del plano de control PIM se dividen en exactamente dos formas en este árbol: la relación de vecindad nunca se forma, o se forma y el dispositivo equivocado termina a cargo del segmento.
Ubicar primero el síntoma aquí indica cuál de las secciones siguientes aplica realmente — un vecino genuinamente ausente necesita una solución completamente distinta de uno presente pero silenciosamente unidireccional.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Un vecino genuinamente caído y un vecino activo pero silenciosamente unidireccional se ven idénticos en display pim neighbor de un solo dispositivo — ambos lo dejan sin un par funcional — pero las soluciones no se parecen en nada. El árbol de arriba es lo que los distingue antes de tocar cualquier configuración.
Tres verificaciones, en orden — cada una es contexto para la siguiente, y los comandos que indican en cuál está realmente atascado.
display pim neighbor sin mostrar absolutamente nada produce la misma salida ya sea que PIM nunca se haya configurado o que esté ocurriendo una falla real de vecindad — revise primero la explicación más simple.
<Device> display current-configuration interface GigabitEthernet0/0/1
// no pim sm / pim dm line at all
[Device] multicast routing-enable
// required first if the device reports:
// Error: Please create Multicast Enable first, because current configuration depends on the object.
[Device-GigabitEthernet0/0/1] pim sm
<Device> display pim interface GigabitEthernet0/0/1
// check State column: Down here means check physical/protocol state firstPIM habilitado y la interfaz Up aún no son suficientes — el propio Hello debe ser aceptado en ambos extremos.
<Device> display pim neighbor
VPN-Instance: public net
Total Number of Neighbors = 0
// confirm subnet match, neighbor filter-policy, and Generation ID requirement next
<Device> display current-configuration interface Vlanif100
// check for a pim neighbor-policy acl-number entry that could be filtering the peerQue exista una relación de vecindad no es lo mismo que el dispositivo correcto esté a cargo del segmento — aquí es donde aparecen las fallas de DR dual y posteriores a la actualización.
<Device1> display pim interface Eth-Trunk3.50
Interface State NbrCnt HelloInt DR-Pri DR-Address
Eth-Trunk3.50 up 0 30 1 10.194.163.17 (local)
// NbrCnt 0 with DR-Address local on both upstream devices -> one-way Hello, not a real absence
[Device3-Eth-Trunk3] undo storm suppression multicast packets 0
// storm suppression on the member port was dropping PIM Hello
<DeviceA> display pim neighbor
Total Number of Neighbors = 3
// a neighbor and a DR role that didn't exist before the last upgrade -- compare against the pre-upgrade baselineUna vez realizadas las tres verificaciones anteriores, estas cinco causas explican la mayoría de lo que realmente falla en implementaciones reales.
SÍNTOMAdisplay pim neighbor no muestra absolutamente nada en una interfaz que claramente debería tener un vecino al otro lado del enlace.
CAUSALa interfaz simplemente nunca tuvo pim sm (o pim dm) configurado. Sin PIM configurado, no hay Hello que enviar o recibir, así que ninguna relación de vecindad puede existir jamás, independientemente de que todo lo demás esté correcto.
SOLUCIÓNConfigure pim sm en la interfaz; si el dispositivo informa que necesita multicast habilitado primero, ejecute multicast routing-enable en la vista de sistema primero, luego configure PIM en la interfaz.
<Device> display current-configuration interface GigabitEthernet0/0/1
// no pim sm/pim dm line at all
[Device] multicast routing-enable
[Device-GigabitEthernet0/0/1] pim smSÍNTOMAEl vecino PIM no se forma específicamente hacia el router de un fabricante externo, aunque la interfaz esté Up, PIM esté habilitado, y las dos interfaces estén en la misma subred.
CAUSAUn dispositivo está configurado para rechazar mensajes Hello que no lleven un parámetro Generation ID. Esta opción no la envía de forma idéntica cada fabricante, y cuando el Hello del peer no la incluye, la relación de vecindad silenciosamente nunca se forma — esto aparece específicamente en la interoperabilidad entre fabricantes, no en implementaciones del mismo fabricante.
SOLUCIÓNRevise si el dispositivo está configurado para requerir la opción Generation ID en los mensajes Hello recibidos, y relaje ese requisito al interoperar con un fabricante que no la envía.
<Device> display current-configuration interface Vlanif100
// check for a Generation-ID requirement in the PIM configuration
// relax it when the peer's Hello doesn't carry the optionSÍNTOMADos dispositivos aguas arriba en el mismo segmento agregado muestran ambos DR-Address como local — ambos creen que ganaron la elección de DR, y ambos reenvían tráfico multicast al mismo enlace aguas abajo.
CAUSAUn comando de supresión de tormenta en un puerto miembro del Eth-Trunk aguas abajo descartaba silenciosamente los paquetes Hello PIM. Cada dispositivo aguas arriba solo escuchaba su propio Hello reflejado, nunca el del otro, así que cada uno se consideraba el único dispositivo del segmento y se elegía a sí mismo como DR.
SOLUCIÓNElimine el comando de supresión de tormenta multicast del puerto miembro que está descartando el tráfico de control PIM, o excluya explícitamente la dirección multicast de PIM (224.0.0.13) de cualquier política de control de tormenta vigente.
<Device1> display pim interface Eth-Trunk3.50
Interface State NbrCnt HelloInt DR-Pri DR-Address
Eth-Trunk3.50 up 0 30 1 10.194.163.17 (local)
[Device3-Eth-Trunk3] undo storm suppression multicast packets 0SÍNTOMAJusto después de una actualización de firmware, los usuarios aguas abajo ya no pueden recibir multicast, aunque no se tocó nada en la topología ni en la configuración.
CAUSAEl comportamiento de elección de DR de PIM del dispositivo cambió entre versiones — una interfaz que solía perder la elección de DR frente al dispositivo aguas arriba correcto la ganó en su lugar después de la actualización, y el nuevo DR incorrecto no tiene ruta para replicar tráfico a los usuarios aguas abajo, así que el flujo multicast simplemente se detiene ahí.
SOLUCIÓNCompare display pim neighbor y display pim interface antes y después de la actualización para cualquier interfaz donde el DR haya cambiado; donde el nuevo DR no debería estar reenviando a ese segmento, elimine la interfaz de la relación de vecindad de la que no debería formar parte, o ajuste dr-priority para forzar que el dispositivo correcto gane.
<DeviceA> display pim interface
Vlanif4091 up 1 30 1 192.168.17.1
// a PIM neighbor relationship and a DR role that didn't exist before the upgradeSÍNTOMADespués de que un dispositivo se reinicia o resetea, el servicio de IPTV aguas abajo sigue roto aunque todos los enlaces vuelvan a estar activos y se vean saludables.
CAUSAUn puerto de agregación llevaba una VLAN que no debería, dejando que los paquetes Hello PIM de varios vecinos aguas arriba no relacionados se filtraran a la interfaz del dispositivo aguas abajo. Con varios vecinos PIM adicionales de repente visibles en esa VLAN, la elección de DR ya no favorecía al propio dispositivo aguas abajo, y dejó de ser el que replicaba el tráfico multicast a los usuarios debajo de él.
SOLUCIÓNElimine la VLAN que no debería llevarse a través de ese puerto trunk, para que el dispositivo aguas abajo solo vea los vecinos PIM que realmente debería ver.
<Device4> display pim neighbor
Total Number of Neighbors = 11
// several extra neighbors received via a leaked VLAN on Eth-Trunk20
[Device2-Eth-Trunk20] undo port trunk allow-pass vlan 43Extraídas directamente del campo — las que vale la pena tener una respuesta lista.
En un segmento multicast compartido, el Router Designado es el único dispositivo responsable de enviar consultas IGMP en ese segmento y reenviar tráfico multicast hacia él — todos los demás routers PIM del mismo segmento permanecen en silencio para ese rol. Si el dispositivo que gana la elección no tiene una ruta utilizable hacia los verdaderos receptores aguas abajo, el multicast simplemente no se replica hacia ellos, aunque todos los demás routers PIM del segmento funcionen bien.
Confirme primero que pim sm realmente esté configurado en esa interfaz, con display current-configuration interface — una configuración faltante produce exactamente la misma salida vacía que una falla real de vecindad. Luego confirme que el estado PIM de la interfaz esté Up con display pim interface; si está Down, revise el estado físico y de protocolo antes de revisar PIM en sí.
Significa que cada dispositivo cree que es el único router PIM en ese segmento, lo que casi siempre significa que los paquetes Hello no se están alcanzando entre sí en al menos una dirección — no que la lógica de elección en sí esté rota. Revise si hay algo en la ruta que pudiera estar descartando silenciosamente el tráfico de control multicast, particularmente una política de supresión de tormenta o QoS aplicada a 224.0.0.13, antes de asumir que es un problema de configuración de PIM.
El comportamiento de elección de DR de PIM es una de las cosas que puede cambiar entre versiones, incluso sin ningún cambio de configuración de su parte. Compare display pim interface y display pim neighbor antes y después de la actualización para la VLAN o interfaz afectada — si aparece un nuevo DR donde solía estar el anterior, y el nuevo DR no puede realmente alcanzar a los usuarios aguas abajo, ese es el mecanismo.
Revise si alguno de los dispositivos está configurado para rechazar mensajes Hello sin una opción Generation ID — este es un punto común de fricción entre fabricantes, ya que no todos los Hello predeterminados de cada fabricante la incluyen. Relajar ese requisito en el lado que lo verifica suele ser suficiente para que la relación se forme.
Esta nota se basa en el modelo de resolución de problemas de PIM del router Huawei serie AR y sus comandos display pim interface / pim neighbor, además de los casos de campo que los respaldan. Si su gateway es de otro fabricante, los comandos exactos cambian, pero el orden de verificación subyacente — habilitado, up, vecino, DR — se traslada directamente. No cubre en profundidad casos específicos de PIM-SSM ni interacciones de MSDP anycast-RP.
Cuéntenos si el vecino está completamente ausente o activo con el DR equivocado, junto con la salida de display pim interface / pim neighbor, y le ayudamos a interpretarla.