Documentation forNetwork Performance Monitor

Monitor multicast traffic

NPM automatically discovers and monitors multicast groups and routing topology on Layer 3 devices using SNMP. After discovery, NPM collects multicast group, traffic, and topology information, without any additional configuration.

NPM monitors multicast routing on L3 routers and multilayer switches only. Layer 2 access switches (IGMP Snooping per-port membership) are not polled. For flow-based multicast bandwidth visibility, see Monitor multicast traffic in NTA.

Requirements

To monitor multicast traffic on a device:

  • The device must have multicast routing enabled.

  • At least one active multicast routing entry must exist on the device.

  • The device must be monitored by NPM.

  • The Multicast Routing checkbox must be enabled on the node resource list.

    NPM automatically assigns the multicast poller during discovery when multicast routing is enabled and active multicast routing entries exist. If multicast is configured but no active multicast groups exist during discovery, the poller will not be assigned. Enable Multicast Routing manually in Node Details > List Resources.

Limitations

The following capabilities are currently not supported:

  • Layer 2 IGMP Snooping membership monitoring on access switches

  • Deep packet inspection of multicast packet content

    SolarWinds Packet Analysis Sensors (NPAS/SPAS) capture TCP-based application traffic via SPAN port or server agent and produce Application Response Time (ART) and Network Response Time (NRT) metrics only. Multicast traffic is UDP-based and is not analyzed by packet analysis sensors. See How SolarWinds Packet Analysis Sensors work.

  • Per-transaction latency analysis

  • Application-to-group auto-detection.

  • End-host receiver mapping to multicast groups.

  • IPv6 multicast monitoring

Monitored metrics

Group health

  • Group status (Normal / Warning / Down) — calculated across all participating routers

  • PIM neighbor adjacency state — neighbor uptime and expiry per interface

  • Rendezvous Point (RP) state — Up or Down, including time of last state change

  • IGMP membership — last reporter IP per group per interface

Traffic

  • Incoming multicast traffic rate (pps and bps) per group per interface

  • Outgoing multicast traffic rate (pps and bps) per group per interface

  • Source traffic rate (pps) — traffic arriving directly from the multicast source

  • Node utilization by multicast traffic over time

Topology

  • Source IP of the multicast stream

  • Upstream routers — devices receiving traffic from the source

  • Downstream routers and interfaces — devices forwarding traffic toward receivers

  • Outgoing Interface List (OIL) per group

  • Multicast routing protocol per group (PIM Sparse, PIM Dense, DVMRP, MSDP)

  • Routing table change history — inserts, updates, and deletes tracked over time

    The topology shows L3 network devices only. End-host receivers (servers, clients) are not auto-mapped to groups. The last reporter IP from IGMP indicates which subnet last sent a membership report — it does not identify individual hosts.

How group status is calculated

NPM calculates multicast group status at two levels:

  • Node status: the most severe condition for each router participating in a group determines the node status:

    • Node status — is the router reachable?

    • Interface status — are the incoming and outgoing interfaces up?

    • Traffic presence — is the incoming traffic rate above 0 pps?

  • Group status: The overall group status is the worst status reported by any monitored node participating in the multicast group. NPM recalculates group status after each poll.

    Node state

    Interface state

    Traffic

    Group status

    Up

    		 Up > 0 pps Up
    Up One or more down > 0 pps Warning
    Up Up 0 pps Warning
    Up All down -- Down
    Down -- -- Down
    Unknown -- -- Unknown

A multicast group can display a Warning status when all devices and interfaces remain operational but multicast traffic is no longer being received. This is a common condition for IPTV streams, market data feeds, and video distribution when traffic drops to 0 pps. The router and its interfaces may be fully up — but the stream has stopped.

Map application names to multicast groups

By default, NPM identifies multicast groups by IP address, such as 239.1.1.1.

You can assign descriptive names to group IPs so that dashboards and alerts display a meaningful label.

  1. Go to My Dashboards > Network > NPM Summary.

  2. Find Multicast Groups Summary resource.

  3. Click Multicast Groups Setup.

  4. On the Manage multicast groups page, edit the Group Name field.

  5. Click Save Changes.

NPM does not auto-detect which application uses a multicast group. Group names must be maintained manually.

Configure alerts

NPM includes the following default alert templates for multicast:

Alert

Trigger condition

Multicast routing group status is not normal

Group status changes to Unknown, Warning or Down

Multicast routing group status is down

Group status changes to Down

Multicast routing group traffic too low (bps)

Traffic rate drops to 5000 bps or lower on a monitored group

Multicast routing group traffic too low (pps)

Traffic rate drops to 50 pps or lower on a monitored group

Create custom multicast alerts

To alert on specific multicast group IP ranges, use the Alert Manager with the following scope conditions:

  • Multicast Groups — Group IP — filter by IP range (for example, 239.0.0.0 to 239.255.255.255 for site-local streams)

  • Multicast Group Nodes — Source packets per second — set trigger when this drops to 0

To alert on interface-level multicast traffic, use Interfaces > Current Traffic in the Alert Manager and filter on Xmit/Recv Multicast Packets per second. This allows per-interface thresholds independent of group-level status.

If you are receiving a large number of multicast alerts for non-critical groups, limit the alert scope to specific multicast address ranges or disable the alert.

Disable multicast polling

If multicast monitoring is not required, you can disable polling to reduce alert noise and database load:

  1. Disable the multicast alerts in the Advanced Alert Manager.

  2. To stop polling entirely, go to Node Details > List Resources, and clear the Multicast Routing checkbox.