Applications receiving unwanted multicast traffic

Question

I have the following scenario; the host HostRec:

1) The NIC bond0 of the host has joined the multicast groups multicast1 and multicast2 – because an application has requested this. 2) I start a multicast listening application on the same host HostRec, which listens for traffic on multicast3 and UDP port3. 3) I start a multicast sending application on another host HostSend.

At this point I have the following 3 scenarios:

a) If the sending application of step3 is publishing on multicast address multicast3 and udp port3, the messages are correctly received by the listening application started on step2 above. This is the expected behaviour.

b) If I the multicast sending application publish messages on multicast2 and port3 those messages are still received by the listening application started on step2. Same behaviour if the multicast sending application publishes messages on multicast1 and port3. This behavior is wrong.

c) If the sending application (step3) is started publishing on multicast address multicast4 and udp port3 (NIC bond0 on HostRec has not joined this multicast group), the messages are correctly not received by the listening application started on step2. This is again the expected behaviour.

Could you suggest if anything is wrong in the multicast kernel configuration of the host?

uname -a Linux HostRec 2.6.18-164.2.1.el5 #1 SMP Mon Sep 21 04:37:42 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

Thanks, sommario

Answer 1

This is expected behaviour, although it does seem a little odd at first. Although you think you are binding to a multicast group/port, what you are really doing is:

1. Binding to a UDP port on an interface.
2. Subscribing this interface to a given multicast group.

These two actions are quite independent. The result of the first is that your process will receive all packets (multicast or not) that are UDP and are destined for your port/interface. The result of the second is to ensure that packets addressed to a given multicast address are sent (by the network routers) to your interface.

Most people don't want this, in fact they just want to receive data for a single multicast group and don't want to worry about what else is going on on the network. The best way to achieve this is to ensure that one port is used for only one multicast group. A common practice is to use the last octet of the multicast group as the least-significant octet of the port. For example 224.0.0.22/port 19022, and 224.0.0.150/19150. This way you'll never get the wrong data (as long as nobody is UDP unicasting data to those ports).