I found a multicasting example at http://ntrg.cs.tcd.ie/undergrad/4ba2/multicast/antony/example.html. After correcting some errors, this program seems to work fine within our network.

I now need to multicast to a different subnet. Here is my setup: my machine ==> cisco router ==> Internet ==> cisco hub ==> client machine.

My local IP address is The client machine's IP address is

Our network provider has configured a GRE tunnel between the cisco router and the cisco hub. If I ssh or ping from my machine to, it works just fine.

I now need to run my multicast server program on my machine and the client program on the client machine. However, it appears the message from my server never reaches the client.

The network service provider demonstrated a program that seemed to multicast just fine. Unfortunately, they don't have the source code for the application. All they said is that they used as the group id and 6000 as the port. I changed our application to use these parameters but still couldn't get the client and server to communicate.

I am thinking the multicast datagram probably reaches the router but the router does not know if the datagram must be send on the GRE tunnel or to the Internet. This is because the server code does not specifically mention anything about 192.168.15.xx network.

I feel I need to somehow pass in a hint to the router that the multicast packet must really be forwarded to the internal network. Given that the destination client ids are 192.168.15.xx, I tried to set the groupid of the server to (from the net, it appeared that the first four bits for multicast must be 1110. I am using 0b11100000). However, even this did not seem to work.

I am at a loss. Can you please guide me on how to hint the router that the multicasting is meant of 192.168.15.x network? Regards.

  • Have you enabled multicast routing and PIM between the routers? By default, routers drop multicasts. You must explicitly configure them to route multicast.
    – Ron Maupin
    Dec 12, 2015 at 18:16
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer.
    – Ron Maupin
    Aug 12, 2017 at 23:15

2 Answers 2


You probably need to use IGMP.

IGMP is the protocol end hosts use to let their routers know which multicast groups they're interested in listening to. End hosts inform their routers, and the routers in turn join the relevant groups over the WAN.

Here's an overview of the process, shamelessly stolen from wikipedia:

enter image description here

The client uses IGMP over the LAN to let his local router know that he's interested in a certain multicast group. The router then uses a multicast protocol (PIM in this case) to join the group (which consists of Router 1 in this case)

  • The clients do use IGMP, when they issue JOIN and LEAVE requests. The server doesn't use IGMP at all.
    – user207421
    Dec 13, 2015 at 21:09
  • @EJP Yes. That's what i said.
    – Malt
    Dec 13, 2015 at 21:11

Thank you all for your help. I finally made it work. I am posting my solution here in hopes that it will save you days.

In Cisco router, multicasting setup rule requires you to specify the group id and the port you intend to use. It appears there is yet another parameter that I had missed initially in my server code and that is the TTL value.

By default, it appears Cisco router drops the datagram if the TTL value is 1 or less.

In your server code, if you don't specifically set the TTL value, by default it is assumed to be 1. You can set it by calling setsocketoptwith IP_MULTICAST_TTLparameter.

Once I used the proper group id, port and TTL value, my client-server communication started to work.

PS: In the Cisco router, apparently you can use ip multicast ttl-thresholdcommand to change this but I haven't tried it.

  • 1
    Any router should drop the packet if the TTL is less than one. That's how it's supposed to work.
    – user207421
    Dec 13, 2015 at 21:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.