Sender -- (subnet I) --> Router A -- (subnet II) --> Router B -- (subnet III) --> Receiver
What I am struggling with is the need for a static route on the multicast sender:
Add route on multicast sender:
ip route add 224.0.1.20/32 via
>
The example works when I do this; I can send multicast traffic from Sender to Receiver using iperf2. But how can I have router A accept and forward multicast traffic without requiring a static route on the sender machine?
My situation is that I have multiple senders on subnet I, and I have multiple receivers on both subnet I and subnet III. I want multicast traffic from subnet I to be correctly sent to all receivers on subnet I and subnet III. If I add a static route as in the example, it seems that receivers on subnet I will not receive the traffic. There is only one group in use.
Thank you for any help. I feel like this is a common situation and I'm just missing something simple.
I think I solved my own problem. I was using a version of iperf2 that didn’t set the TTL properly. Even though it was specified on the command line as 32, a quick peek with Wireshark showed that it was actually getting set to 1. Changing to a different version of iperf2 seems to solve the problem - I can pass traffic without adding a static route on the sender.
That said, I still wonder why is this step included in the example in the wiki?
For reference, the version of iperf2 that did not set TTL properly was “iPerf 2.0.8 (12 jan 2015 - 231 KiB for Windows XP to Windows 10) built without Cygwin”. This is the only version that would work properly for me as the receiver/server (cygwin versions wouldn’t bind interface properly with a multicast address). But apparently doesn’t work properly as a sender/client. Changing the client to “iPerf 2.0.9 (6 jun 2016 - 1.7 MiB for Windows XP to Windows 10)” made this work.
Anyone have other suggestions for multicast testing tools that run on Windows? I have heard VLC works but I haven’t tried it yet.
TTL too low has got to be the #1 reason for multicast labs to fail! I must have fallen foul of that one at least 10 times now. First time it took me three days (I was using a faulty version of VLC that ignored the TTL setting, and I was convinced it was a PIM problem). Now I usually find it within minutes! If you understand the PIM and IGMP diagnostics, it helps a lot - I’m still getting my head around them.
Maybe it was required on previous operating systems? I seem to recall I used to add a multicast route years ago, but I don’t these days. Looks like the Windows default is OK. I don’t think I’ve fiddled with it on my Windows 10 machine, and it is currently set to:
I downloaded quite a few recently, and most did not work on recent versions of Windows. The famous MC Hammer doesn’t work. mcasttester (NListen and NSend) seems to work on Windows 7 and Windows 10.
VLC is great for generating multicast audio and video streams (and of course replaying them as well). Several versions have the TTL bug (always set to 0 regardless what you set it to in the GUI or command line). Lots of recent versions drop lots of packets (even at low data rates) when generating video streams. I can’t get 2.2.x to stream H264 video reliably - tried several versions on several machines - occasionally it’s OK - mostly not. So I always stick to 2.0.8 which doesn’t drop any packets when streaming - even when generating four video streams and 11 audio streams on five-year-old laptops!
You’ve got to master the command line when using VLC to stream or to play streams - the GUI wizard is too awkward. Set up your path to vlc.exe first of all and then:
By the way, I’m not sure if MikroTik’s PIM is fully functional. I can’t see any register-stop messages, so the RP (which could be several hops away) gets all the high bandwidth audio and video multicast data continuously, even when there are no subscribers nearby. That’s not right! I’ve had to bodge around the issue by having multiple RPs near to the sources.
There have been a couple of throwaway comments on various forum pages about ROS 6.x not doing PIM properly, and of course, it doesn’t do IGMP Snoop at all. It is rumoured that these will be sorted in ROS 7.x. It would be useful if a MikroTik adult could confirm or deny!
Yup I’m still learning too. Thanks for your input. I found the first four chapters of Interdomain Multicast Routing by Edwards, Giulano, and Wright helped me understand some of what’s going on - it’s from 2002 but the protocols haven’t really changed (doesn’t cover IPv6 though).
Maybe it was required on previous operating systems? I seem to recall I used to add a multicast route years ago, but I don’t these days. Looks like the Windows default is OK.
One place I have seen it necessary is to listen on a particular interface when the software does not choose the multicast interface in a well-defined way. That doesn’t seem relevant in this wiki example, though maybe it’s there just in case.
I downloaded quite a few recently, and most did not work on recent versions of Windows. The famous MC Hammer doesn’t work. mcasttester (NListen and NSend) seems to work on Windows 7 and Windows 10.
VLC is great for generating multicast audio and video streams (and of course replaying them as well). Several versions have the TTL bug (always set to 0 regardless what you set it to in the GUI or command line). Lots of recent versions drop lots of packets (even at low data rates) when generating video streams. I can’t get 2.2.x to stream H264 video reliably - tried several versions on several machines - occasionally it’s OK - mostly not. So I always stick to 2.0.8 which doesn’t drop any packets when streaming - even when generating four video streams and 11 audio streams on five-year-old laptops!
You’ve got to master the command line when using VLC to stream or to play streams - the GUI wizard is too awkward. Set up your path to vlc.exe first of all and then:
>
I also couldn't get MC Hammer to work, nor "mcast.exe" from Windows Server 2003 Resource Kit Tools. Do you have a link to mcasttester? (is it the same as [this](http://www.dqnetworks.ie/toolsinfo/mcasttest/)?)