5

I'm a programmer, not a system adminstrator, so please forgive my administrative naivete. My software, written in C#, relies on UDP multicasting. One machine, the server, streams events to an known UDP group address (configurable, but 224.130.103.5 by default), to which all of the clients on the network are subscribed.

Usually this works great, but at some of my clients it does not work at all, and often their network administrators are unable to fix the problem. My question is, on a Windows network, what would the common causes be for UDP multicast not working? Is there anything I can tell the network administrators about how to fix it or at least where to look?

Improve this question
4
  • Shot in the dark, but… are either the clients or server using jumbo frames?
    – Nate
    Commented Jan 9, 2012 at 20:21
  • How do you tell?
    – Aaron Haspel
    Commented Jan 10, 2012 at 15:53
  • It’s a setting available on many gigabit Ethernet adapters. In Windows: Network and Sharing Center > Change Adapter Settings > (Right-Click network adapter) > Properties > Configure > Advanced. If one side has jumbo frames enabled and the other side does not, the symptom is that TCP works, but UDP does not work.
    – Nate
    Commented Jan 10, 2012 at 20:25
  • 1
    You really should not be using a reserved multicast address. IANA has the 239.0.0.0-239.255.255.255 Organization-Local Scope range for local assignment.
    – Ron Maupin
    Commented Dec 14, 2016 at 14:22

5 Answers 5

Reset to default
0

I'd say the most common cause that you'll need to be on the lookout for is routed networks, where the entire set of systems that need to participate in the multicast group (the clients and the server) are not on the same broadcast domain.

That's the first thing to ask the client's network administrators. As far as resolving it if that is the case, it depends on their networking equipment; they'll need to set up PIM and IGMP snooping on their routing equipment.

Their equipment having support for it may be hit or miss; this may be a major barrier for some of your clients. You may need to look into alternative solutions that don't require their network equipment to play nice with multicast. A couple ideas:

  • Having a sort of 'proxy' on each subnet with clients that gets the messages from the server over unicast and repeats them to the multicast group
  • Switching to unicast for all event traffic. Maybe one of these kinds of things: RabbitMQ ActiveMQ
Improve this answer
7

If you have a VirtualBox Host-Only Ethernet Adapter activated on your system that might be the problem, which it was for me, so try disabling it. See https://www.virtualbox.org/ticket/8698.

Improve this answer
2
  • For sure it was VirtualBox! ... the "a.. hole" :)
    – Mohammad Kanan
    Commented Jul 27, 2019 at 19:26
  • Also happens on Hyper-V Ethernet adapters
    – Adrian Dymorz
    Commented May 22, 2020 at 6:18
1

You can use a tool like wireshark to watch UDP packets on the troublesome machine. From that you should be able to determine if the UDP packets are even reaching that machine.

Improve this answer
1

I had similar problems while a Hyper-V virtual ethernet adapter (advertised as vEthernet (default switch)) was active on my machine.

With wireshark I could see the multicast network traffic on my server, but the server application did not respond even though it was registered to the address and port.

So the Answer in this case is: Disable the Hyper-V virtual ethernet adapter if it is enabled.

Improve this answer
0

Try disabling windows firewall and check if your software is receiving packets. I had similar problems with my Java program. If firewall is the problem start experimenting with firewall rules for your incoming traffic.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .