Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am looking for a good simple tool that runs on a standard OS (Windows or Linux) that I can used to test that multicast is being passed properly by a router.

I have been asked by a client to enable multicast routing on a Linux box acting as their router since their phone system requires multicast to for a few features. Since I am not physically near the client I don't really have the ability to experiment with the various methods for setting up multicast routing on Linux. I can setup a router at my desk that is identical to what is deployed on their network, but I don't know of any good simple tools that I can use to generate or listen for multicast traffic.

The one mulicast tool I have found is mcast.exe tool which is part of the Windows 2000/2003 resource kit. From what I have read online it seems that mcast.exe does not work across a router, and only works on the local network, so that doesn't seem to be useful for me to test multicast routing.

So what do tool(s) do you use to test that multicast routing is properly setup?


locked by HopelessN00b Jan 21 '15 at 18:45

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

closed as off-topic by HopelessN00b Jan 21 '15 at 18:45

This question appears to be off-topic. The users who voted to close gave this specific reason:

If this question can be reworded to fit the rules in the help center, please edit the question.

up vote 3 down vote accepted

Don't have much real world multicast experience, but have you seen mz?

Description: versatile packet creation and network traffic generation tool
 mausezahn (mz) is a fast traffic generator written in C which allows you to
 send nearly every possible and impossible packet. It is mainly used to test
 VoIP or multicast networks but also for security audits to check whether
 your systems are hardened enough for specific attacks.
 Mausezahn can be used for example:
  * as traffic generator (e.g. to stress multicast networks);
  * to precisely measure jitter (delay variations) between two hosts
    (e.g. for VoIP-SLA verification);
  * as didactical tool during a datacom lecture or for lab exercises;
  * for penetration testing of firewalls and IDS;
  * for DoS attacks on networks (for audit purposes of course);
  * to find bugs in network software or appliances;
  * for reconnaissance attacks using ping sweeps and port scans;
  * to test network behaviour under strange circumstances (stress test,
    malformed packets, ...).

There's also ssmping:

Description: check your multicast connectivity
 Tools to check whether you can receive Source Specific Multicast (SSM)
 or Any Source Multicast (ASM) via either IPv4 or IPv6
 If a host runs ssmpingd, users on other hosts can use the ssmping client
 to test whether they can receive SSM from the host. Another program
 called asmping is also provided to check whether can receive ASM.

Both installable on Ubuntu 10.10. Good luck!

ssmping also worked really well and helped a lot. I would upvote this, but SF is telling me that I had already cast my vote? – Zoredache Dec 21 '10 at 1:28
up vote 18 down vote

iperf is perfect for this and it's readily available for most linux distributions and windows.

On the listener side:

% iperf -s -u -B -i 1
Server listening on UDP port 5001
Binding to local address
Joining multicast group
Receiving 1470 byte datagrams
UDP buffer size:  110 KByte (default)

...and it will wait to hear from the source. On the source, begin sending:

% iperf -c -u -T 32 -t 3 -i 1
Client connecting to, UDP port 5001
Sending 1470 byte datagrams
Setting multicast TTL to 32
UDP buffer size:  110 KByte (default)
[  3] local port 59347 connected with port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec   129 KBytes  1.06 Mbits/sec
[  3]  1.0- 2.0 sec   128 KBytes  1.05 Mbits/sec
[  3]  2.0- 3.0 sec   128 KBytes  1.05 Mbits/sec
[  3]  0.0- 3.0 sec   386 KBytes  1.05 Mbits/sec
[  3] Sent 269 datagrams

at the same time, you'll see the listener receive the traffic:

[  3] local port 5001 connected with port 59347
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0- 1.0 sec   128 KBytes  1.05 Mbits/sec   0.035 ms    0/   89 (0%)
[  3]  1.0- 2.0 sec   128 KBytes  1.05 Mbits/sec   0.015 ms    0/   89 (0%)
[  3]  2.0- 3.0 sec   128 KBytes  1.05 Mbits/sec   0.025 ms    0/   89 (0%)
[  3]  0.0- 3.0 sec   386 KBytes  1.05 Mbits/sec   0.068 ms    0/  269 (0%)

By specifying the -T 32 option on the sender, you're setting the TTL to 32 which will ensure the traffic can be routed (assuming IGMP, PIM, and whatnot on the routers are properly configured)

BTW, the last time I tried using VLC in this scenario, I ran into an issue where VLC would ignore the TTL setting and always transmit packets with TTL set to 1. Read the bug report for a workaround.

Things to watch out for. Apparently iperf has issues if the 'server' is running on a computer with multiple interfaces. But aside from that, this worked. – Zoredache Dec 21 '10 at 1:25
Another thing to be careful of; the iperf test client will work correctly even if /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts is set (to 1). In this case, running iperf as a server and trying to ping the multicast address will NOT work. Whether this matters is dependent on your multicast needs. – nezroy Mar 23 '11 at 17:01

This may or may not be helpful, but in the past, I've used VLC (of all things) as a multicast video source. In my use cases, though, the multicast streams never needed to go beyond a L2 domain, so I can't say if the traffic it generates would be "proper" routable multicast.

I like that VLC will do multicast. I am hoping someone with a network that supports multicast across L3 can confirm that VLC does work, and possibly include some details about about the setup and testing procedure. – Zoredache Dec 15 '10 at 0:46
@Zoredache Due to our Novell legacy I have a multicast-enabled network at work (SLP). If I remember, I'll do some VLC checking tomorrow. – sysadmin1138 Dec 17 '10 at 5:45

mcast is the tool that we use to see if multicast has been allowed by our local router. It should be off by default.

You don't want multicast packets wandering off clogging up networks where they are not needed.


You can also try these application: VIC and RAT, multicast application used to be develop for MBONE, available for Windows XP and UNIX. It also support IPv4 and IPv6 Multicast. You can see them at


Not the answer you're looking for? Browse other questions tagged or ask your own question.