Testing multicast: beacons, iperf 2 and ssmping

Updated November 2026

Multicast lets one sender reach many receivers while sending each packet only once. It is also notoriously hard to debug, because it depends on hosts, switches and routers all agreeing. This page explains the moving parts and shows how to test them with iperf 2 and ssmping.

Multicast in five minutes

Where multicast usually breaks

  1. The TTL is too low, so packets die at the first router. This is the most common test mistake.
  2. The receiver never joins, because a host firewall drops IGMP or the application is bound to the wrong interface.
  3. Switches with IGMP snooping forward traffic only to ports that sent a join. Without an IGMP querier on the VLAN, joins time out and streams stop after a few minutes.
  4. Routers are not configured for multicast routing on every hop, or an ASM rendezvous point is unreachable.
  5. Firewalls and tunnels drop multicast or do not forward it at all. Many VPNs and cloud networks carry no multicast.

Testing with iperf 2

iperf3 has no multicast options, so use iperf 2 (command iperf). The receiver runs as a server bound to the group address, which makes it join the group:

# receiver: join 239.255.10.1, report every second, stop after 40 s
iperf -s -u -B 239.255.10.1 -i 1 -t 40 -e

The sender is a client that sends to the group. Set a TTL high enough to cross your routers:

# sender: 2 Mbit/s for 30 s, TTL 16
iperf -c 239.255.10.1 -u -b 2M -T 16 -t 30

Each receiver prints bitrate, jitter and lost packets, as in a unicast UDP test. You can run the receiver command on several hosts at once to check every branch of the tree.

Choosing the interface

On hosts with several network cards, add the device after a percent sign: -B 239.255.10.1%eth1 accepts the group only on eth1. Without it, the group is accepted on any interface.

Source-specific multicast

For SSM, use a group in 232.0.0.0/8 and give the receiver the sender's address with -H:

# receiver: join (192.0.2.10, 232.1.1.1)
iperf -s -u -B 232.1.1.1 -H 192.0.2.10 -i 1 -t 40
# sender (on 192.0.2.10)
iperf -c 232.1.1.1 -u -b 2M -T 16 -t 30

iperf 2 multicast caveats. The manual notes that multicast tests cannot use -P, that the server handles multicast streams one after another, and that you should give the server a -t so it stops even if the final packet is lost.

Testing with ssmping and asmping

The ssmping tools, written by Stig Venaas, check whether you can receive multicast from a given host without setting up a stream yourself. The remote host runs a small responder:

ssmpingd

It listens on UDP port 4321. From the receiving side, run:

ssmping -c 5 192.0.2.10

ssmping sends unicast requests; the responder answers both by unicast and to the SSM group 232.43.211.234 (ff3e::4321:1234 for IPv6). If unicast replies arrive but multicast ones do not, multicast routing between the two hosts is broken. asmping does the same for any-source multicast; the group you give it must end in .234 for IPv4, for example asmping 239.255.10.234 192.0.2.10. On Debian and Ubuntu the tools are in the ssmping package.

Checking the host side

The NLANR Multicast Beacon

Before tools like these were common, research networks watched their multicast service with beacons. The NLANR/DAST Multicast Beacon ran a small probe at each participating site. Every beacon sent RTP packets to a shared group and listened to all the others, so each site could see loss, delay and jitter from every other site, and a central server collected the reports into a matrix. The first version was written in Java; a later version was written in Perl and is still packaged in pkgsrc as mbone/beacon. The same idea, a full mesh of senders reporting what they hear, is still a sound way to monitor any multicast deployment.

Sources