1. Administering Oracle Coherence
  2. Basic Administration
  3. Performing a Multicast Connectivity Test

3 Performing a Multicast Connectivity Test

Coherence includes a multicast test utility that checks whether a network environment supports multicast communication. Any production deployment should be preceded by a successful run of the multicast test.

This chapter includes the following sections:

  • Running the Multicast Test Utility
    The Coherence multicast test utility is used to determine if multicast is enabled between two or more computers.
  • How to Test Multicast
    Testing multicast requires two steps: verify that multicast is functioning properly on individual servers; and ensure that multicast is functioning properly between servers.
  • Troubleshooting Multicast Communications
    There are many issues that can potentially cause bidirectional multicast communication to fail. If a failure is observed, then begin by reviewing the troubleshooting tips for the most common issues.

Parent topic: Basic Administration

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. See Performing a Network Performance Test for network load testing.

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 3-1 describes the available command line options for the multicast test utility.

Table 3-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

Parent topic: Performing a Multicast Connectivity Test

How to Test Multicast

Testing multicast requires two steps: verify that multicast is functioning properly on individual servers; and ensure that multicast is functioning properly between servers.

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 3-1 illustrates sample output.

Example 3-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.
...

Leave the test running for approximately 5 minutes to ensure there are no failures. Press CTRL-C to stop further testing.

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.

Parent topic: Performing a Multicast Connectivity Test

Troubleshooting Multicast Communications

There are many issues that can potentially cause bidirectional multicast communication to fail. If a failure is observed, then begin by reviewing the troubleshooting tips for the most common issues. If you are unable to resolve multicast issues after troubleshooting, then 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.

  • If the multicast test fails after initially succeeding, try running the following on a Coherence node:

    tcpdump -i nic_device igmp

    Where nic_device is the NIC device name. Make sure that IGMP Query Messages (either v2 or v3) are seen in the tcpdump output. Make sure the switch is enabled to send and receive IGMP Query Messages. Also make sure that the NIC and OS networking is set to respond to periodic IGMP Query Messages. Lastly, check the switch to make sure it sees the Coherence servers do both "IGMP Join" and "IGMP Query Message" acknowledgements. The output should be similar to: 

    07:58:33.452537 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP
 (2), length 40, options (RA))
 
longcoh06a1-priv.emea.kuoni.int > igmp.mcast.net: igmp v3 report, 1 group
 record(s) [gaddr 192.168.0.5 to_ex, 0 source(s)]
 
07:58:43.294453 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP
 (2), length 40, options (RA))
 
   longcoh06a1-priv.emea.kuoni.int > igmp.mcast.net: igmp v3 report, 1 group
 record(s) [gaddr 192.168.0.5 to_ex, 0 source(s)]
 
07:58:51.782848 IP (tos 0xc0, ttl 1, id 3133, offset 0, flags [none], proto
 IGMP (2), length 36, options (RA))
 
   10.241.113.40 > all-systems.mcast.net: igmp query v3 [max resp time 10s]
 
08:00:56.803800 IP (tos 0xc0, ttl 1, id 3134, offset 0, flags [none], proto
 IGMP (2), length 36, options (RA))
 
   10.241.113.40 > all-systems.mcast.net: igmp query v3 [max resp time 10s]
…

    The first two lines are servers "joining" the multicast group. The remaining output are the IGMP Query Messages originating at the switch, these are continuous, every few minutes - if the switch is configured to send them, and the NIC is configured to respond.

  • IPv6—On operating systems which support IPv6, Java may be attempting to route the Multicast traffic over IPv6 rather than IPv4. Try specifying the following Java system property to force IPv4 networking java.net.preferIPv4Stack=true. Coherence cluster members must all use either IPv4 or IPv6 and cannot use a mix of both.

  • 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 Using Well Known Addresses in Developing Applications with Oracle Coherence.

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

  • Cisco Switches—See Deploying to Cisco Switches.

  • Foundry Switches—See Deploying to Foundry Switches.

Parent topic: Performing a Multicast Connectivity Test