Testing multicast: beacons, iperf 2 and ssmping
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
- Groups, not hosts. A sender transmits UDP packets to a group address. Any host that wants the traffic joins the group, and the network copies packets only where receivers exist.
- IPv4 group addresses run from 224.0.0.0 to 239.255.255.255. Some blocks matter for testing: 224.0.0.0/24 is for local control traffic and is never forwarded off the link; 232.0.0.0/8 is reserved for source-specific multicast; 239.0.0.0/8 is administratively scoped, for use inside one organization. For private tests, pick an address in 239.0.0.0/8.
- IGMP is how IPv4 hosts tell their local router which groups they want. IGMPv3 adds source filtering: a host can ask for a group only from listed sources, or from all sources except some. IPv6 does the same job with MLD; MLDv2 matches IGMPv3.
- ASM and SSM. In any-source multicast (ASM), receivers join a group (written *,G) and routers must discover the senders, usually through a rendezvous point. In source-specific multicast (SSM), receivers join a group from one known source (S,G), which is simpler and avoids the rendezvous point entirely.
- TTL. The time-to-live limits how many routers a multicast packet can cross. Many tools default to a TTL of 1, which keeps traffic on the local subnet.
Where multicast usually breaks
- The TTL is too low, so packets die at the first router. This is the most common test mistake.
- The receiver never joins, because a host firewall drops IGMP or the application is bound to the wrong interface.
- 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.
- Routers are not configured for multicast routing on every hop, or an ASM rendezvous point is unreachable.
- 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
ip maddress show dev eth0lists the multicast groups an interface has joined on Linux.tcpdump -n -i eth0 igmpshows IGMP joins and queries; if you see no queries, the VLAN has no querier.- Run the receiver and the sender on the same subnet first. If that works, add one router at a time.
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
- RFC 5771: IANA Guidelines for IPv4 Multicast Address Assignments
- RFC 3376: Internet Group Management Protocol, Version 3
- iperf 2 manual page, iperf2 project
- ssmping(1) manual page, Debian
- asmping(1) manual page, Debian
- ip-maddress(8) manual page, man7.org
- net/beacon port description, FreeBSD Ports
- mbone/beacon, pkgsrc