Redhat Enterprise Linux 6 Multicast Feed

Question

I am writing an application which receives multicast data on a new Redhat Enterprise Linux 6 server. The support team gives me an application which is used for testing whether the server can get multicast data flow.

Once I start the test application, and also having tcpdump running, I can see the multicast data coming in, e.g.,

12:58:21.645968 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 729
12:58:21.648369 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 969
12:58:21.649406 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 893
12:58:21.651823 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 604
12:58:21.654079 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 913
12:58:21.656724 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 1320
12:58:21.658194 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 124
12:58:21.658226 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 217
12:58:21.658348 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 182
12:58:21.658625 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 1014
12:58:21.659592 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 135
12:58:21.659842 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 242
12:58:21.660674 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 242
12:58:21.660743 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 84
12:58:21.662327 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 84
12:58:21.669154 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 161
12:58:21.669365 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 166
12:58:21.670792 IP 10.26.12.22.60002 > 238.230.230.100.60002: UDP, length 49
12:58:21.670796 IP 10.26.12.22.60002 > 238.230.230.100.60002: UDP, length 49
12:58:21.670798 IP 10.26.12.22.60002 > 238.230.230.100.60002: UDP, length 49
12:58:21.670799 IP 10.26.12.22.60002 > 238.230.230.100.60002: UDP, length 49

But the application is not able to pick up any data flow, i.e., the application runs as if the multicast data subscription is unsuccessful.

The support team assures me that there is no problem with the test application, because it is running fine on other servers. Since I am having a new server, it is possible that some settings on the server are not right.

I am wondering what Linux settings shall I look for which potentially may stop the application receiving the multicast data, even thought tcpdump can see the data. Missing libraries or packages?

Thanks.

Answer 1

pls check on switch level.In my case i was stuck with Clustering. My cluster only will work on mulitcast. But i was facing some packet lose in mulitcast. It was too strange for me. But eventually i got the solution from one of my best friends(google). I have just disable IGMP on my switch level and it's working fine..

Answer 2

First off, it's worth checking that RHEL 6 has multicast support enabled at the kernel level. (it probably does but I don't have RHEL 6 available to check) Make sure that the /proc/net/igmp file exists.

Also check that the multicast address range is routed to the interface that you're expecting. If this is incorrect you can have some interesting symptoms where you receive multicast only while tcpdump is (promiscuously) sniffing packets. This can also be the case if your NIC doesn't properly support multicast. Some older NICs may also need to be set to promiscuous mode to receive any multicast, regardless of the multicast setting shown in ifconfig.

Another thing to do is to check the contents of the /proc/net/igmp file while your test application is running. The /proc/net/igmp file will contain a list of all of the multicast group addresses that the server is actively receiving. If there is an entry in the "Group" column that corresponds to the multicast group address that the test application is meant to be receiving (in your case 238.6.6.36 and 238.230.230.100) then the IP_ADD_MEMBERSHIP (or IP_ADD_SOURCE_MEMBERSHIP) socket options have probably been called correctly, and on the correct NIC. Note that the Group column lists the multicast group addresses in hex and backwards - so 238.6.6.36 will be listed as 240606EE.

Your situation may be more complicated if you have a multicast router (eg. Xorp, igmpproxy) running on the same machine on which you're running the test application. If this is the case you should also investigate the /proc/net/ip_mr_vif and /proc/net/ip_mr_cache files to ensure that there are appropriate entries.

Answer 3

I had a similar problem on a RHEL 6 machine. I resolved it by adding the required UDP port to the allowed ports through the firewall. Try adding udp port 50002.