Multicast Test Utility

Included with Coherence is a Multicast Test utility, which helps you determine if multicast is enabled between two or more computers. This is a connectivity test, not a load test, each instance will by default only transmit a single multicast packet once every two seconds. For network load testing please see the Datagram Test.

Syntax

To run the Multicast Test utility use the following syntax from the command line:

java com.tangosol.net.MulticastTest <command value> <command value> ...

Command Options

Command	Optional	Description	Default
-local	True	The address of the NIC to transmit on, specified as an IP address	localhost
-group	True	The multicast address to use, specified as IP:port.	237.0.0.1:9000
-ttl	True	The time to live for multicast packets.	4
-delay	True	The delay between transmitting packets, specified in seconds.	2
-display	True	The number of bytes to dispaly from unexpected packets.	0

Usage Example

java com.tangosol.net.MulticastTest -group 237.0.0.1:9000

For ease of use, multicast-test.sh and multicast-test.cmd scripts are provided in the Coherence bin directory, and can be used to execute this test.

Note: prior to Coherence 3.1 the following syntax was used, and scripts were not provided:

java com.tangosol.net.MulticastTest <ip-addr> <multicast-addr> <port> <ttl> <delay-secs>

Example

Let's say that we want to test if we can use multicast address 237.0.0.1, port 9000 (the test's defaults) to send messages between two servers - Server A with IP address 195.0.0.1 and Server B with IP address 195.0.0.2.

Starting with Server A, let's determine if it has multicast address 237.0.0.1 port 9000 available for 195.0.0.1 by first checking the machine or interface by itself as follows:

From a command session, type in:

multicast-test.sh -ttl 0

After pressing ENTER, you should see the Multicast Test utility showing you how it is sending sequential multicast packets and receiving them as follows:

Starting test on ip=servera/195.0.0.1, group=/237.0.0.1:9000,ttl=0
Configuring multicast socket...
Starting listener...
Tue Jan 17 15:59:51 EST 2006: Sent packet 1.
Tue Jan 17 15:59:51 EST 2006: Received test packet 1 from self.
Tue Jan 17 15:59:53 EST 2006: Sent packet 2.
Tue Jan 17 15:59:53 EST 2006: Received test packet 2 from self.
...

Once you have seen a number of these packets sent and received successfully, you can hit CTRL-C to stop further testing.

If you do not see something similar to the above, then multicast is not working. Also, please note that we specified a TTL of 0 to prevent the multicast packets from leaving Server A.

You can repeat the same test on Server B to assure that it too has the multicast enabled for it's port combination.

Now to test multicast communications between Server A and Server B. For this test we will use a non-zero TTL which will allow the packets to leave their respective servers. By default the test will use a TTL of 4, if you believe that there may be more network hops required to route packets between Server A and Server B, you may specify a higher TTL value.

Start the test on Server A and Server B by entering the following command into the command windows and pressing ENTER:

multicast-test.sh

You should see something like the following on Server A:

Starting test on ip=servera/195.0.0.1, group=/237.0.0.1:9000, ttl=4
Configuring multicast socket...
Starting listener...
Tue Jan 17 16:11:03 EST 2006: Sent packet 1.
Tue Jan 17 16:11:03 EST 2006: Received test packet 1 from self.
Tue Jan 17 16:11:05 EST 2006: Sent packet 2.
Tue Jan 17 16:11:05 EST 2006: Received test packet 2 from self.
Tue Jan 17 16:11:07 EST 2006: Sent packet 3.
Tue Jan 17 16:11:07 EST 2006: Received test packet 3 from self.
Tue Jan 17 16:11:09 EST 2006: Sent packet 4.
Tue Jan 17 16:11:09 EST 2006: Received test packet 4 from self.
Tue Jan 17 16:11:10 EST 2006: Received test packet 1 from ip=serverb/195.0.0.2, group=/237.0.0.1:9000, ttl=4.
Tue Jan 17 16:11:11 EST 2006: Sent packet 5.
Tue Jan 17 16:11:11 EST 2006: Received test packet 5 from self.
Tue Jan 17 16:11:12 EST 2006: Received test packet 2 from ip=serverb/195.0.0.2, group=/237.0.0.1:9000, ttl=4.
Tue Jan 17 16:11:13 EST 2006: Sent packet 6.
Tue Jan 17 16:11:13 EST 2006: Received test packet 6 from self.
Tue Jan 17 16:11:14 EST 2006: Received test packet 3 from ip=serverb/195.0.0.2, group=/237.0.0.1:9000, ttl=4.
Tue Jan 17 16:11:15 EST 2006: Sent packet 7.
Tue Jan 17 16:11:15 EST 2006: Received test packet 7 from self.
...

and something like the following on Server B:

Starting test on ip=serverb/195.0.0.2, group=/237.0.0.1:9000, ttl=4
Configuring multicast socket...
Starting listener...
Tue Jan 17 16:11:10 EST 2006: Sent packet 1.
Tue Jan 17 16:11:10 EST 2006: Received test packet 1 from self.
Tue Jan 17 16:11:11 EST 2006: Received test packet 5 from ip=servera/195.0.0.1, group=/237.0.0.1:9000, ttl=4.
Tue Jan 17 16:11:12 EST 2006: Sent packet 2.
Tue Jan 17 16:11:12 EST 2006: Received test packet 2 from self.
Tue Jan 17 16:11:13 EST 2006: Received test packet 6 from ip=servera/195.0.0.1, group=/237.0.0.1:9000, ttl=4.
Tue Jan 17 16:11:14 EST 2006: Sent packet 3.
Tue Jan 17 16:11:14 EST 2006: Received test packet 3 from self.
Tue Jan 17 16:11:15 EST 2006: Received test packet 7 from ip=falco/192.168.0.204, group=/237.0.0.1:9000, ttl=4.
...

You can see that both Server A and Server B are issuing multicast packets and seeing their own and each other's packets. This indicates that multicast is functioning properly between these servers using the default multicast address and port.

Note: Server A sees only its own packets 1-4 until we start Server B and it receives packet 1 from Server B.

Troubleshooting

If you are unable to establish bidirectional multicast communication please try the following:

Firewalls - If any of the machines running the multicast test are running firewalls, the firewall may be blocking the traffic. Consult your OS/firewall documentation for details on allowing multicast traffic.
Switches - Ensure that your switches are configured to forward multicast traffic.
IPv6 - On OSs which support IPv6 Java may be attempting to route the Multicast traffic over IPv6 rather then IPv4. Try specifying the following Java system property to force IPv4 networking java.net.preferIPv4Stack=true.
Received ??? - If the test reports receiving "???" this is an indication that it is receiving multicast packets which did not originate from an instance of the Multicast test. This will occur if you are running the test with the same multicast address as a running Coherence cluster, or any other multicast application.
Multiple NICs - If your machines have multiple network interfaces you may try specifying an explicit interface via the -local test parameter. For instance if Server A has two interfaces with IP addresses 195.0.0.1 and 195.0.100.1, including -local 195.0.0.1 on the test command line would ensure that the multicast packets used the first interface. You may also need to explicitly set your machines routing table to forward multicast traffic through the desired network interface. This can be done by issuing the following command:
```
route add -net 224.0.0.0 netmask 240.0.0.0 dev eth1
```
Where eth1 is the device which will be designated to transmit multicast traffic.
AIX - On AIX systems you may run into the following multicast issues:
- IPv6 - In addition to specifying java.net.preferIPv4Stack=true you may need to configure the OS to perform IPv4 name resolution by adding hosts=local,bind4 to your /etc/netsvc.conf file.
- Virtual IP (VIPA) - AIX does not support multicast with VIPA. If using VIPA either bind multicast to a non-VIPA device, or run Coherence with multicast disabled. See well-known-addresses for details.
- MTU - Configure the MTU for the multicast device to 1500 bytes.
Cisco Switches - See the list of known issues related to Cisco switches
Foundry Switches - See the list of known issues related to Foundry switches

If multicast is not functioning properly, you will need to consult with your network administrator or sysadmin to determine the cause and to correct the situation.