Uma relação de vizinhança PIM que nunca se forma, ou que se forma mas elege o DR errado, quebra o multicast antes mesmo de o IGMP ou a tabela de encaminhamento terem chance de importar. Esta é a ordem de verificação para o plano de controle subjacente — os comandos display exatos para o estado da interface PIM, o status do vizinho e a eleição de DR, e as causas que continuam aparecendo em implantações reais.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
Ou a relação de vizinhança nunca se forma, ou se forma e elege o dispositivo errado como DR — e a jusante, ambos parecem simplesmente que o multicast não está funcionando.
Tudo o que o IGMP e a tabela de encaminhamento multicast fazem a jusante depende de o PIM já ter feito corretamente duas coisas a montante: formar uma relação de vizinhança com o roteador adjacente, e eleger o Roteador Designado certo para realmente replicar o tráfego no segmento. Quando qualquer um dos dois está errado, o IGMP pode estar perfeitamente configurado e a tabela de encaminhamento pode estar exatamente correta, e o multicast ainda assim não chegará ao usuário — porque o dispositivo que deveria encaminhar o tráfego para esse segmento não é o que está fazendo isso, ou nem sequer está lá.
Se a reclamação real é congelamento de IPTV ou mosaico de vídeo de CFTV em vez de uma falha do plano de controle, nossa nota complementar sobre solução de problemas de vídeo multicast cobre o lado de IGMP/tabela/largura de banda disso; esta é sobre o que precisa ser verdade do lado do PIM antes que qualquer coisa disso sequer se aplique.
As falhas do plano de controle PIM se dividem em exatamente duas formas nesta árvore: a relação de vizinhança nunca se forma, ou se forma e o dispositivo errado acaba no comando do segmento.
Colocar primeiro o sintoma aqui indica qual das seções abaixo realmente se aplica — um vizinho genuinamente ausente precisa de uma correção completamente diferente de um presente mas silenciosamente unidirecional.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Um vizinho genuinamente inativo e um vizinho ativo mas silenciosamente unidirecional parecem idênticos no display pim neighbor de um único dispositivo — ambos deixam você sem um par funcional — mas as correções não se parecem em nada. A árvore acima é o que os distingue antes de mexer em qualquer configuração.
Três verificações, em ordem — cada uma é contexto para a seguinte, e os comandos que indicam em qual você está realmente travado.
display pim neighbor não mostrando absolutamente nada produz a mesma saída, seja porque o PIM nunca foi configurado ou porque uma falha real de vizinhança está ocorrendo — verifique primeiro a explicação mais simples.
<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 e a interface Up ainda não são suficientes — o próprio Hello precisa ser aceito em ambos os lados.
<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 peerA existência de uma relação de vizinhança não é a mesma coisa que o dispositivo correto estar no comando do segmento — é aqui que aparecem as falhas de DR duplo e pós-atualização.
<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 baselineDepois de realizadas as três verificações acima, essas cinco causas respondem pela maior parte do que realmente está errado em implantações reais.
SINTOMAdisplay pim neighbor não mostra absolutamente nada em uma interface que claramente deveria ter um vizinho do outro lado do link.
CAUSAA interface simplesmente nunca teve pim sm (ou pim dm) configurado. Sem PIM configurado, não há Hello para enviar ou receber, então nenhuma relação de vizinhança pode existir, independentemente de qualquer outra coisa estar correta.
CORREÇÃOConfigure pim sm na interface; se o dispositivo relatar que precisa do multicast habilitado primeiro, execute multicast routing-enable na visualização do sistema primeiro, depois configure o PIM na interface.
<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 smSINTOMAO vizinho PIM não se forma especificamente em direção ao roteador de um fabricante terceiro, mesmo que a interface esteja Up, o PIM esteja habilitado, e as duas interfaces estejam na mesma sub-rede.
CAUSAUm dispositivo está configurado para rejeitar mensagens Hello que não carreguem um parâmetro Generation ID. Essa opção não é enviada de forma idêntica por todos os fabricantes, e quando o Hello do peer não a inclui, a relação de vizinhança silenciosamente nunca se forma — isso aparece especificamente na interoperabilidade entre fabricantes, não em implantações do mesmo fabricante.
CORREÇÃOVerifique se o dispositivo está configurado para exigir a opção Generation ID nas mensagens Hello recebidas, e relaxe essa exigência ao interoperar com um fabricante que não a envia.
<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 optionSINTOMADois dispositivos a montante no mesmo segmento agregado mostram ambos DR-Address como local — ambos acreditam que venceram a eleição de DR, e ambos encaminham tráfego multicast para o mesmo link a jusante.
CAUSAUm comando de supressão de tempestade em uma porta membro do Eth-Trunk a jusante estava descartando silenciosamente pacotes Hello PIM. Cada dispositivo a montante só ouvia seu próprio Hello refletido de volta, nunca o do outro, então cada um se considerava o único dispositivo no segmento e se elegia DR.
CORREÇÃORemova o comando de supressão de tempestade multicast da porta membro que está descartando o tráfego de controle PIM, ou exclua explicitamente o endereço multicast do PIM (224.0.0.13) de qualquer política de controle de tempestade em vigor.
<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 0SINTOMALogo depois de uma atualização de firmware, os usuários a jusante não conseguem mais receber multicast, embora nada na topologia ou configuração tenha sido tocado.
CAUSAO comportamento de eleição de DR do PIM do dispositivo mudou entre versões — uma interface que costumava perder a eleição de DR para o dispositivo a montante correto a venceu em vez disso depois da atualização, e o novo DR incorreto não tem caminho para replicar tráfego para os usuários a jusante, então o fluxo multicast simplesmente para ali.
CORREÇÃOCompare display pim neighbor e display pim interface antes e depois da atualização para qualquer interface onde o DR mudou; onde o novo DR não deveria estar encaminhando para esse segmento, remova a interface da relação de vizinhança da qual não deveria fazer parte, ou ajuste dr-priority para forçar o dispositivo correto a vencer.
<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 upgradeSINTOMADepois que um dispositivo reinicia ou reseta, o serviço de IPTV a jusante permanece quebrado mesmo que todos os links voltem e pareçam saudáveis.
CAUSAUma porta de agregação carregava uma VLAN que não deveria, deixando pacotes Hello PIM de vários vizinhos a montante não relacionados vazarem para a interface do dispositivo a jusante. Com vários vizinhos PIM extras de repente visíveis nessa VLAN, a eleição de DR não favorecia mais o próprio dispositivo a jusante, e ele deixou de ser o que replicava o tráfego multicast para os usuários abaixo dele.
CORREÇÃORemova a VLAN que não deveria ser carregada por essa porta trunk, para que o dispositivo a jusante veja apenas os vizinhos PIM que realmente deveria.
<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 43Tiradas diretamente do campo — aquelas que vale a pena ter uma resposta pronta.
Em um segmento multicast compartilhado, o Roteador Designado é o único dispositivo responsável por enviar consultas IGMP nesse segmento e encaminhar tráfego multicast para ele — todos os outros roteadores PIM no mesmo segmento permanecem em silêncio para essa função. Se o dispositivo que vence a eleição não tiver um caminho utilizável até os verdadeiros receptores a jusante, o multicast simplesmente não é replicado para eles, mesmo que todos os outros roteadores PIM no segmento estejam funcionando bem.
Confirme primeiro que o pim sm realmente está configurado nessa interface, com display current-configuration interface — uma configuração ausente produz exatamente a mesma saída vazia que uma falha real de vizinhança. Depois confirme que o estado PIM da interface está Up com display pim interface; se estiver Down, verifique o estado físico e de protocolo antes de olhar para o PIM em si.
Significa que cada dispositivo acredita ser o único roteador PIM nesse segmento, o que quase sempre significa que os pacotes Hello não estão se alcançando em pelo menos uma direção — não que a lógica de eleição em si esteja quebrada. Verifique se há algo no caminho que possa estar descartando silenciosamente o tráfego de controle multicast, particularmente uma política de supressão de tempestade ou QoS aplicada a 224.0.0.13, antes de supor que é um problema de configuração do PIM.
O comportamento de eleição de DR do PIM é uma das coisas que pode mudar entre versões, mesmo sem nenhuma mudança de configuração da sua parte. Compare display pim interface e display pim neighbor antes e depois da atualização para a VLAN ou interface afetada — se um novo DR aparecer onde o antigo costumava estar, e o novo DR não conseguir realmente alcançar os usuários a jusante, esse é o mecanismo.
Verifique se algum dos dispositivos está configurado para rejeitar mensagens Hello sem uma opção Generation ID — este é um ponto comum de atrito entre fabricantes, já que nem todo Hello padrão de cada fabricante a inclui. Relaxar essa exigência no lado que a verifica geralmente é suficiente para deixar a relação se formar.
Esta nota se baseia no modelo de solução de problemas de PIM do roteador Huawei série AR e seus comandos display pim interface / pim neighbor, além dos casos de campo por trás deles. Se o seu gateway for de outro fabricante, os comandos exatos mudam, mas a ordem de verificação subjacente — habilitado, up, vizinho, DR — se aplica diretamente. Não cobre em profundidade casos específicos de PIM-SSM nem interações de MSDP anycast-RP.
Conte-nos se o vizinho está completamente ausente ou ativo com o DR errado, junto com a saída de display pim interface / pim neighbor, e ajudamos você a interpretá-la.