Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

A CentOS 5 system does not appear to come out-of-the-box with a route for multicast traffic. What it does appear to do is use a default route, if configured. In other words, a routing table like this:

# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface   U         0 0          0 eth0     U         0 0          0 eth0         UG        0 0          0 eth0

will work with my Java-based multicast client application (or the test case below), which expects to be able to send to a site-local multicast address.

This setup works. If I don't have a default route, e.g.

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface   U         0 0          0 eth0     U         0 0          0 eth0

my Java application will fail when it tries to send. I can correct this by adding the multicast route:

# route add -net via eth0

And to do the above permanently:

# echo via eth0 >>/etc/sysconfig/network-scripts/route-eth0

Should I be creating this route anyway? Is there any harm in letting the default route handle multicast traffic, other than the fact that it would stop working if the default route went away?

Here is a short test case which can be run by executing javac; java Sender. It sends a 0-byte UDP packet to the site-local address If I have no default route in place, it will fail with

Exception in thread "main" Network is unreachable
        at Method)
        at Sender.main(

However, if a default route (or the multicast route I mention above) is present, it will successfully send the packet to


class Sender {
    public static void main(String[] args) throws Throwable {
        MulticastSocket socket = new MulticastSocket();
        InetAddress groupAddress = InetAddress.getByName("");
        socket.send(new DatagramPacket(new byte[0], 0, groupAddress, 9999));
share|improve this question
Does your system only have one interface? – ewwhite Apr 2 '13 at 14:21
Yes, though I did wonder how this is supposed to work in a multiple-interface situation. – zigg Apr 2 '13 at 14:45
For multi-interface, your app needs to specify the join interface. – ewwhite Apr 2 '13 at 14:51

You should only need to add a route in your host is multi-homed.


Otherwise, the default route will do the correct thing.

share|improve this answer
This is interesting information, but it doesn't exactly address my question. I've edited to clarify. Multicast sending certainly does not work if there isn't a route present that contains the 224/4 network, although I don't believe it actually uses that route. – zigg Apr 2 '13 at 14:05
Your description does not reconcile with the definition of the routing table. – dmourati Apr 2 '13 at 15:32
I'm not sure what you mean. It's possible I'm communicating poorly. I do know, however, that I cannot send packets nor join a group unless there is some sort of route in place that encompasses the multicast group address I'm trying to use. See the test case I've added. – zigg Apr 2 '13 at 17:18
That route is the default route /eod. – dmourati Apr 2 '13 at 18:09

You typically don't want a multicast route in place. Not needed.

What does netstat -gn show? Joins should go out of the lowest-numbered interface eth0 by default.

See the steps I noted at: Multicast doesn't seem to be working on RHEL 5.5

share|improve this answer
My application is send-only, so it doesn't actually join any groups, since it isn't interested in incoming traffic. I didn't think I'd want to join unless I wanted to listen. – zigg Apr 2 '13 at 14:43
I wanted to let you know that I also tested a join scenario with no interface specified in the application and no multicast-covering route in place. The application failed with 'no such device'. So it seems that in order for eth0 to be used by default, there either must be a route or the application must do it--Linux will not select eth0 by itself. – zigg Apr 3 '13 at 16:30
up vote 0 down vote accepted

To get to the bottom of this, I created a virtual network between two systems. The answer to whether the route is needed depends on the application and network configuration.

These answers are valid for my application, which is a blind sender. It does not join any multicast group, because it is not interested in receiving traffic--only sending it to other systems joined to the group it is sending to. Thus, I did not evaluate the requirements for joining any particular multicast group.

The scenarios are as follows:

  1. The application sets the socket to a specific interface before sending (e.g. with Java's setNetworkInterface method). This does not require any routing table coverage of the network. Multicasted packets will be transmitted on the bound interface.

  2. The application does not set the socket to a specific interface before sending, and a default route exists. Multicasted packets will be transmitted on the interface specified by the default route.

  3. The application does not set the socket to a specific interface before sending, and no default route exists, yet there is coverage of the multicast group address in the routing table. Multicasted packets will be transmitted on the interface specified by the route that covers the multicast group address.

  4. The application does not set the socket to a specific interface before sending, and no route exists that will cover the multicast group address. The application will fail with "no route to host".

  5. Bonus scenario: the application does not set the socket to a specific interface, and both a default route on one interface and a multicast route on another interface exist, the latter covering the multicast group address. Multicast packets will be transmitted on the latter interface.

The answer seems to be that a multicast route is indeed required if the application does not select an interface to transmit on. It also preempts the default route, which in hindsight makes sense. Only the interface portion of the routes appears to be used.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.