Fusion Middleware Documentation
Advanced Search


Administering Oracle Coherence
Close Window

Table of Contents

Show All | Collapse

4 Performing a Multicast Connectivity Test

This chapter provides instructions for using the Coherence multicast test utility to check whether a network environment supports multicast communication. Any production deployment should be preceded by a successful run of the multicast test.

The following sections are included in this chapter:

4.1 Running the Multicast Test Utility

The Coherence multicast test utility is used to determine if multicast is enabled between two or more computers. The utility does not test load. Each instance, by default, only transmit a single multicast packet every two seconds. For network load testing, see Chapter 3, "Performing a Network Performance Test."

The multicast test utility is run from the command line using either the com.tangosol.net.MulticastTest class or by running the multicast-test script that is provided in the COHERENCE_HOME/bin directory. A script is provided for both Windows and UNIX-based platforms.

The following example runs the utility using the MulticastTest class:

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

The following example runs the utility using the script:

multicast-test <command value> <command value> ...

Table 4-1 describes the available command line options for the multicast test utility.

Table 4-1 Command Line Options for the Multicast Test Utility

Command Required/
Optional
Description Default

-local

Optional

The address of the NIC to transmit on, specified as an IP address

localhost

-group

Optional

The multicast address to use, specified as IP:port.

237.0.0.1:9000

-ttl

Optional

The time to live for multicast packets.

4

-delay

Optional

The delay between transmitting packets, specified in seconds.

2

-packetSize

Optional

The size of the packet to send. The default is based on the local MTU.

MTU

-display

Optional

The number of bytes to display from unexpected packets.

0

-translate

Optional

Listen to cluster multicast traffic and translate packets

none


4.2 How to Test Multicast

The example in this section demonstrates how to test if multicast address 237.0.0.1, port 9000 (the defaults for the test) can send messages between two servers: Server A with IP address 195.0.0.1 and Server B with IP address 195.0.0.2.

Note:

The default multicast address and port that are used by the test are different than the Coherence default address and port. The test should be performed using the same address and port that are being used in the actual Coherence processes. It is possible that the default address and port for the mutlicast test succeeds, but the Coherence defaults fail. This often due to local network policy configuration.

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

From a command prompt, enter the following command:

multicast-test.sh -ttl 0

After pressing ENTER, the utility display how it is sending sequential multicast packets and receiving them. Example 4-1 illustrates sample output.

Example 4-1 Sequential Multicast Packets Sent by the Multicast Test Utility

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

Press CTRL-C to stop further testing after several packets have been sent and received successfully.

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

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

Next, test multicast communications between Server A and Server B. For this test use a nonzero TTL which allows the packets to leave their respective servers. By default, the test uses a TTL of 4, if more network hops are required to route packets between Server A and Server B, specify a higher TTL value.

Start the test on Server A and Server B by entering the following command into each's respective command window and pressing ENTER:

multicast-test.sh

The following example demonstrates sample output for 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 Mar 17 16:11:03 EST 2008: Sent packet 1.
Tue Mar 17 16:11:03 EST 2008: Received test packet 1 from self.
Tue Mar 17 16:11:05 EST 2008: Sent packet 2.
Tue Mar 17 16:11:05 EST 2008: Received test packet 2 from self.
Tue Mar 17 16:11:07 EST 2008: Sent packet 3.
Tue Mar 17 16:11:07 EST 2008: Received test packet 3 from self.
Tue Mar 17 16:11:09 EST 2008: Sent packet 4.
Tue Mar 17 16:11:09 EST 2008: Received test packet 4 from self.
Tue Mar 17 16:11:10 EST 2008: Received test packet 1 from ip=serverb/195.0.0.2, group=/237.0.0.1:9000, ttl=4.
Tue Mar 17 16:11:11 EST 2008: Sent packet 5.
Tue Mar 17 16:11:11 EST 2008: Received test packet 5 from self.
Tue Mar 17 16:11:12 EST 2008: Received test packet 2 from ip=serverb/195.0.0.2, group=/237.0.0.1:9000, ttl=4.
Tue Mar 17 16:11:13 EST 2008: Sent packet 6.
Tue Mar 17 16:11:13 EST 2008: Received test packet 6 from self.
Tue Mar 17 16:11:14 EST 2008: Received test packet 3 from ip=serverb/195.0.0.2, group=/237.0.0.1:9000, ttl=4.
Tue Mar 17 16:11:15 EST 2008: Sent packet 7.
Tue Mar 17 16:11:15 EST 2008: Received test packet 7 from self.
...

The following example demonstrates sample output for 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 Mar 17 16:11:10 EST 2008: Sent packet 1.
Tue Mar 17 16:11:10 EST 2008: Received test packet 1 from self.
Tue Mar 17 16:11:11 EST 2008: Received test packet 5 from ip=servera/195.0.0.1, group=/237.0.0.1:9000, ttl=4.
Tue Mar 17 16:11:12 EST 2008: Sent packet 2.
Tue Mar 17 16:11:12 EST 2008: Received test packet 2 from self.
Tue Mar 17 16:11:13 EST 2008: Received test packet 6 from ip=servera/195.0.0.1, group=/237.0.0.1:9000, ttl=4.
Tue Mar 17 16:11:14 EST 2008: Sent packet 3.
Tue Mar 17 16:11:14 EST 2008: Received test packet 3 from self.
Tue Mar 17 16:11:15 EST 2008: Received test packet 7 from ip=servera/195.0.0.1, group=/237.0.0.1:9000, ttl=4.
...

In the example 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 it receives packet 1 from Server B.

4.3 Troubleshooting Multicast Communications

Use the following troubleshooting tips if bidirectional multicast communication is not established. If multicast is not functioning properly, consult with a network administrator or sysadmin to determine the cause and to correct the situation.

  • Firewalls—If any of the computers running the multicast test employ firewalls, the firewall may be blocking the traffic. Consult your operating system/firewall documentation for details on allowing multicast traffic.

  • Switches—Ensure that the switches are configured to forward multicast traffic.

  • IPv6—On operating systems 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 occurs if the test is run with the same multicast address as an existing Coherence cluster, or any other multicast application.

  • Multiple NICs—If the computers have multiple network interfaces, try specifying an explicit interface by using 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. In addition, the computer's routing table may require explicit configuration 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 that is designated to transmit multicast traffic.

  • AIX—On AIX systems, the following multicast issues may be encountered:

    • IPv6—In addition to specifying java.net.preferIPv4Stack=true, the operating system may require additional configuration to perform IPv4 name resolution. Add hosts=local,bind4 to the /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 the Developing Applications with Oracle Coherence for details.

    • MTU—Configure the MTU for the multicast device to 1500 bytes.

  • Cisco Switches—See "Deploying to Cisco Switches" for the list of known issues.

  • Foundry Switches—See "Deploying to Foundry Switches" for the list of known issues.