3

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
10.42.128.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth0
0.0.0.0         10.42.128.1     0.0.0.0         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
10.42.128.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     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 224.0.0.0/4 via eth0

And to do the above permanently:

# echo 224.0.0.0/4 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 Sender.java; java Sender. It sends a 0-byte UDP packet to the site-local address 239.192.0.1. If I have no default route in place, it will fail with

Exception in thread "main" java.io.IOException: Network is unreachable
        at java.net.PlainDatagramSocketImpl.send(Native Method)
        at java.net.DatagramSocket.send(DatagramSocket.java:629)
        at Sender.main(MulticastSender.java:7)

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

Sender.java

import java.net.*;

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

3 Answers 3

1

To get to the bottom of this, I created a virtual network between two systems. The answer to whether the 224.0.0.0/4 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 224.0.0.0/4 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.

1
  • 1
    Thanks for this, it was very helpful! For anyone else wondering, if using the POSIX C socket API, the way to set the multicast interface for outgoing messages on a given socket is setsockopt() with IP_MULTICAST_IF.
    – sdt
    Jan 17, 2023 at 12:36
0

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

See:

http://sourceforge.net/apps/trac/ganglia/wiki/Ganglia%203.1.x%20Installation%20and%20Configuration

Otherwise, the default route will do the correct thing.

4
  • 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.
    – Mattie
    Apr 2, 2013 at 14:05
  • Your description does not reconcile with the definition of the routing table.
    – dmourati
    Apr 2, 2013 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.
    – Mattie
    Apr 2, 2013 at 17:18
  • That route is the default route /eod.
    – dmourati
    Apr 2, 2013 at 18:09
0

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

2
  • 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.
    – Mattie
    Apr 2, 2013 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.
    – Mattie
    Apr 3, 2013 at 16:30

You must log in to answer this question.

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