A PIM neighbor relationship that never forms, or one that forms but elects the wrong DR, breaks multicast before IGMP or the forwarding table ever gets a chance to matter. This is the check order for the control plane underneath — the exact display commands for PIM interface state, neighbor status and DR election, and the causes that keep coming back in real deployments.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
Either the neighbor relationship never forms in the first place, or it forms and elects the wrong device as DR — and downstream, both look like multicast just isn't working.
Everything IGMP and the multicast forwarding table do downstream depends on PIM having already done two things correctly upstream: forming a neighbor relationship with the adjacent router, and electing the right Designated Router to actually replicate traffic onto the segment. When either one is wrong, IGMP can be perfectly configured and the forwarding table can be exactly right, and multicast still won't reach the user — because the device that's supposed to be forwarding traffic onto that segment isn't the one doing it, or isn't there at all.
If the actual complaint is IPTV freezing or CCTV video turning to mosaic rather than a control-plane fault, our companion note on multicast video troubleshooting covers the IGMP/table/bandwidth side of that; this one is about what has to be true on the PIM side before any of that even applies.
PIM control-plane faults split into exactly two shapes on this tree: the neighbor relationship never forms, or it forms and the wrong device ends up in charge of the segment.
Placing the symptom here first tells you which of the sections below actually applies — a neighbor that's genuinely absent needs a completely different fix from one that's present but silently one-way.
Diagram labels are kept in English for engineering clarity.
A neighbor that's genuinely down and a neighbor that's up but silently one-way look identical from display pim neighbor on a single device — both leave you short a working peer — but the fixes are nowhere near each other. The tree above is what tells them apart before any configuration gets touched.
Three checks, in order — each one is context for the next, and the commands that tell you which one you're actually stuck on.
display pim neighbor showing nothing at all is the same output whether PIM was never configured or a genuine neighbor failure is happening — check the simple explanation first.
<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 enabled and the interface Up still isn't enough — the Hello itself has to be accepted on both ends.
<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 neighbor relationship existing isn't the same thing as the correct device being in charge of the segment — this is where dual-DR and post-upgrade faults show up.
<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 baselineOnce the three checks above have told you where the problem sits, these five account for most of what's actually wrong in real deployments.
SYMPTOMdisplay pim neighbor shows nothing at all on an interface that should clearly have a neighbor across the link.
CAUSEThe interface simply never had pim sm (or pim dm) configured. With no PIM configured, there is no Hello to send or receive, so no neighbor relationship can ever exist, independent of anything else being correct.
FIXConfigure pim sm on the interface; if the device reports it needs multicast enabled first, run multicast routing-enable in the system view first, then configure PIM on the 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 smSYMPTOMPIM neighbor won't form specifically toward a third-party vendor's router, even though the interface is Up, PIM is enabled, and the two interfaces are on the same subnet.
CAUSEOne device is configured to reject Hello messages that don't carry a Generation ID parameter. This option isn't sent identically by every vendor, and when the peer's Hello doesn't include it, the neighbor relationship silently never forms — this shows up specifically in cross-vendor interoperability, not in same-vendor deployments.
FIXCheck whether the device is configured to require the Generation ID option in received Hello messages, and relax that requirement when interoperating with a vendor that doesn't send it.
<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 optionSYMPTOMTwo upstream devices on the same aggregated segment both show DR-Address as local — both believe they won the DR election, and both forward multicast traffic onto the same downstream link.
CAUSEA storm-suppression command on one member port of the downstream Eth-Trunk was silently dropping PIM Hello packets. Each upstream device only ever heard its own Hello reflected back, never the other's, so each one considered itself the only device on the segment and elected itself DR.
FIXRemove the multicast storm-suppression command from the member port that's dropping PIM control traffic, or explicitly exclude PIM's multicast address (224.0.0.13) from whatever storm-control policy is in place.
<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 0SYMPTOMRight after a firmware upgrade, downstream users can't receive multicast anymore, even though nothing in the topology or configuration was touched.
CAUSEThe device's PIM DR election behavior changed between versions — an interface that used to lose the DR election to the correct upstream device won it instead after the upgrade, and the new, incorrect DR has no path to replicate traffic to the downstream users, so the multicast stream simply stops there.
FIXCompare display pim neighbor and display pim interface before and after the upgrade for any interface where the DR changed; where the new DR shouldn't be forwarding to that segment, remove the interface from the neighbor relationship it shouldn't be part of, or adjust dr-priority to force the correct device to win.
<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 upgradeSYMPTOMAfter a device reboots or resets, downstream IPTV service stays broken even though every link comes back up and looks healthy.
CAUSEAn aggregation port carried a VLAN it shouldn't have, letting PIM Hello packets from several unrelated upstream neighbors leak onto the downstream device's interface. With several extra PIM neighbors suddenly visible on that VLAN, the DR election no longer favored the downstream device itself, and it stopped being the one replicating multicast traffic to the users below it.
FIXRemove the VLAN that shouldn't be carried across that trunk port, so the downstream device only sees the PIM neighbors it's actually supposed to.
<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 43Pulled straight from the field — the ones worth having an answer ready for.
On a shared multicast segment, the Designated Router is the one device responsible for sending IGMP queries on that segment and forwarding multicast traffic onto it — every other PIM router on the same segment stays silent for that role. If the device that wins the election has no usable path to the actual downstream receivers, multicast simply doesn't get replicated to them, even though every other PIM router on the segment is working fine.
Confirm pim sm is actually configured on that interface first, with display current-configuration interface — a missing configuration produces exactly the same empty output as a genuine neighbor failure. Then confirm the interface's PIM state is Up with display pim interface; if it's Down, check the physical and protocol state before looking at PIM itself.
It means each device believes it's the only PIM router on that segment, which almost always means Hello packets aren't reaching each other in at least one direction — not that the election logic itself is broken. Check for anything on the path that could silently drop multicast control traffic, particularly a storm-suppression or QoS policy applied to 224.0.0.13, before assuming it's a PIM configuration problem.
PIM's DR election behavior is one of the things that can change between versions, even without any configuration change on your part. Compare display pim interface and display pim neighbor before and after the upgrade for the affected VLAN or interface — if a new DR appears where the old one used to be, and the new DR can't actually reach the downstream users, that's the mechanism.
Check whether either device is configured to reject Hello messages without a Generation ID option — this is a common point of cross-vendor friction, since not every vendor's default Hello includes it. Relaxing that requirement on the side that's checking for it is usually enough to let the relationship form.
This note is built around the Huawei AR-series router's PIM troubleshooting model and its display pim interface / pim neighbor commands, plus the field cases behind them. If your gateway is a different vendor, the exact commands change, but the underlying check order — enabled, up, neighbor, DR — carries over directly. It doesn't cover PIM-SSM-specific edge cases or MSDP anycast-RP interactions in depth.
Tell us whether the neighbor is missing entirely or up with the wrong DR, plus the display pim interface / pim neighbor output, and we'll help you read it.