3 Performing a Multicast Connectivity 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 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. |
|
-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
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
-
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 thetcpdump
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. Addhosts=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