Source Specific Multicast with iperf

oooh iperf ssm

As part of my lab at work, I need to have lots of traffic flying around all over the place. Unicast IPv4 and IPv6, of course – but also traffic in L3VPNs and multicast traffic. Multicast is a big part of the day-to-day traffic load in my production network, so it’s important to be there in the lab too.

I’ve used a variety of tools to generate multicast traffic in the past, more often than not the excellent OMPing. This time, however, I wanted to really chuck some volume around, to make my stats look nice and to really show up on NFSen. iperf is the natural choice for generating lots of traffic in a hurry, I’m using iperf3 to throw about 20Gbit/s around the lab core, but for some reason the developers have removed multicast functionality from the new and improved iperf3.

ASM (or any-source multicast) is (more) traditional multicast. It relies on interested parties joining a group (a multicast address) where any sender can be considered the source (*,G). It works well when your environment is well set up, with a rendezvous point and protocols such as PIM-SM (and MSDP when you wanna go multi-domain). Iperf handles this pretty easily, simply set up a server to ‘listen’ on one end, and a client to send on the other. This can be achieved by having two hosts, connected via a router which acts as the PIM-SM rendezvous point and has IGMPv2 on the interfaces, so the listener can tell it’s router that it’s keen on having a listen.

On the listener:
iperf -s -B -u -f m -i 1

On the sender:
iperf -c -u -b 100m -f m -i 1 -t -1 -T 32

On the listener, we’re telling iperf to be a server (-s), listening to an ASM multicast group (-B), using UDP (-u), formatting the output in megabit/s (-f) and telling us what’s up every 1 second (-i).

On the sender, we’re telling iperf to be a client (-c), using UDP, sending a 100Mbit/s stream (-b), sending forever (-t) and setting the multicast TTL to 32 (-T) – overkill, but hey.

This is a quick and easy way to check a basic ASM setup. I use it to confirm my multi-domain lab setup is working with multicast as I would expect and to generate lots of traffic to amuse myself.

Getting source specific

Source specific multicast is a bit cooler than ASM, because it should work for more people, more easily. If you have a single source (like a TV encoder, or some kind of unique data source) that you want plenty of receivers to see, and you have a nice way of telling them about your source address (like a higher-layer application – or in our case, manual config) – then SSM is the protocol for you.

To make SSM work, you really only need IGMPv3 in your network. Most *nix OS’s and even Windows supports IGMPv3 – usually by default. To check on your *nix host, you can run:
cat /proc/sys/net/ipv4/conf/eth0/force_igmp_version

If that returns a 0, and you’re on a modern-ish OS, you’re good to go. You can force your kernel to use IGMPv3 per interface, with:
echo "3" > /proc/sys/net/ipv4/conf/eth0/force_igmp_version

While most OS’s support IGMPv3 out of the box, plenty of network administrators in your friendly local LAN have probably forgotten to turn it on, or have left it with IGMPv2 and called it a day. No good.

Assuming you’re all good with IGMPv3, you then need to have an application which can listen not only for a particular multicast group address, but also a specific source. iperf, by default, doesn’t support this. Lucky for us, then, noushi has written an extension to iperf that allows for a couple of new flags, to set a specific source and interface. You can grab it here.

If you already had iperf installed, remove it. In Debian/Ubuntu, that would be:
sudo apt-get autoremove iperf -y

Unzip the file from git, then we compile:
sudo make install

Now we can run a client to send multicast as before (but this time, sending to the SSM range):
iperf -c -u -b 10m -f m -i 1 -t -1 -T 32 -p 5002

I’m running it on a different port (-p) from default, because I want SSM and ASM at the same time.

For the listener, we need to tell our newly improved iperf to listen for a particular source (the regular old IP address of our sender):
iperf -s -B -u -f m -i 1 -p 5002 -O -X eth0.101

The two new flags are there, along with our SSM multicast group (and new port). The -O flag sets the SSM source and -X tells iperf to use a particular interface. I’m not sure -X is new, but I’ve never used it before – so let’s say it is.

If it’s working, we’ll see a 10Mbit/s SSM stream turn up on the listener.

12 thoughts on “Source Specific Multicast with iperf”

  1. FYI, I just added SSM support into iperf2 for linux. (FreeBSD, Windows and OS X is in the plans.)

    The cli is a bit different as -X is already used. -H is used for the source instead of -X. Also, the device (or interface) is part of the -B per % This should suppport both ipv6 and ipv4.


    [rjmcmahon@rjm-fedora iperf2-code]$ src/iperf -s -V -u -B ff1e::1%eno1 -H 2001:db8:0:f102::2
    Server listening on UDP port 5001
    Binding to local address ff1e::1
    Joining multicast (S,G)=2001:db8:0:f102::2,ff1e::1 w/iface eno1
    Receiving 1470 byte datagrams
    UDP buffer size: 208 KByte (default)

    [rjmcmahon@rjm-fedora iperf2-code]src/iperf -s -u -B -H
    Server listening on UDP port 5001
    Binding to local address
    Joining multicast (S,G)=, w/iface eno1
    Receiving 1470 byte datagrams
    UDP buffer size: 208 KByte (default)


    1. Hi Santosh,

      With multicast, you typically send from a unicast address (such as to a multicast group address, such as The example range you have given isn’t an SSM range (that’s – so you can just use normal iperf to send your traffic:

      iperf -c -u -b 10m -f m -i 1 -t -1 -T 32

      What that will do is source a stream of traffic (10mbit/s UDP) to the group. Anyone who listens or attempts to join that group successfully will get a copy.

      On a listening machine (or even the same machine, but that’s a bit pointless), you run:

      iperf -s -B -u -f m -i 1

      And if it’s working, you will get the traffic that is being sent.

      Good luck!

  2. hi James
    i am using iperf to send multicast traffic , but i failed , iperf should send mebership report right ? but it is not sending .

    using : iperf -s -B -u -f m -i 1 -p 5002 -O -X eth0.101
    iperf -c -u -b 10m -f m -i 1 -t -1 -T 32 -p 5002
    and one more thing 2.0.12 version there is no -O and -X options

    1. The membership report will come from the listener, to its local PIM router. You need to use the specific version of multicast enabled iperf I was using to have those flags, or see the version Robert McMahon was mentioning in an earlier comment.

      1. Hi James,

        thanks for your quick response,
        Robert mentioned “It’s in iperf 2.0.11a which is the working version of 2.0.11. We’ll release 2.0.11 ” but i am using 2.0.12 still those option are not present.

  3. Hi James,

    I am using iperf 2.0.10 / 2.0.12, it is ruining on linux in server mode , same version running client mode (2.0.10/2.0.12) on windows system.
    i am facing Lost/Total Datagrams huge packets, i suspecting mostly wrong data.
    but issue is not seen if we use 2.0.5. can you please help to resolve this issue, sharing logs below.
    can some one help me how to resolve this issue ?

    # output
    ## AP3890:/# iperf -s -u -B -p 42000 -i 10
    ## Server listening on UDP port 42000
    Binding to local address
    Receiving 1470 byte datagrams
    UDP buffer size: 2.00 MByte (default)
    [ 3] local port 42000 connected with port 52766
    [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
    [ 3] 0.0-10.0 sec 73.2 KBytes 60.0 Kbits/sec 177.121 ms 107374182400/ 0 (7.1e-314%)
    [ 3] 0.00-10.00 sec 26 datagrams received out-of-order
    [ 3] 10.0-20.0 sec 109 KBytes 89.4 Kbits/sec 144.005 ms 163208757248/ 0 (7.1e-314%)
    [ 3] 10.00-20.00 sec 38 datagrams received out-of-order
    [ 3] 0.0-25.2 sec 256 KBytes 83.1 Kbits/sec 139.268 ms 3831110828746/4635333072020149271 (7.1e-314%)
    [ 3] 0.00-25.19 sec 68 datagrams received out-of-order
    [ 3] WARNING: ack of last datagram failed after 10 tries.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.