Newton: Troubleshooting Multicast

Newton makes use of multicast for Jini discovery

1. For Jini discovery - This is how Newton components in different containers locate the jini registry, and hence each other

   224.0.1.84 jini-announcement - port 4160
   224.0.1.85 jini-request - port 4160
   

To support this your network must propagate multicast packets between all of the Newton instances you want to see each other. This will typically be all instances on a particular subnet or switch. If you find that your Newton containers are unable to see each other you should check that you have multicast configured appropriately.

Note that even when you are using a single machine there are configurations in which multicast packets are not propagated between processes.

The following sections describe the multicast diagnostics tool included in the Newton distribution, as well as things to check if multicast isn't working.

The Newton distribution includes a lightweight command line tool called NicNack that can be used to see if multicast packets are travelling between two hosts or not. NicNack is network interface aware, i.e. it provides separate information for each network interface.

NickNac can be run using the nicnac.sh (unix) or nicnac.bat (windows) which can be found in the NEWTON_HOME/bin directory. For windows users this file must be run from this directory or NEWTON_HOME must be set.

NicNack runs in three modes:

1) List mode. This just lists all network interfaces on the machine, along with ip and host name information. For example:

sh bin/nicnack.sh list
NICs:

display name: vmnet8
name: vmnet8
ipv6: fe80:0:0:0:250:56ff:fec0:8
ip: 172.16.206.1

display name: vmnet1
name: vmnet1
ipv6: fe80:0:0:0:250:56ff:fec0:1
ip: 192.168.32.1

display name: wlan0
name: wlan0
ipv6: fe80:0:0:0:211:50ff:fe1b:d845
ip: 192.168.2.2

display name: lov
name: lo
ipv6: 0:0:0:0:0:0:0:1
ip: 127.0.0.1 -> localhost

2) Send mode. In this mode nicnack multicasts a custom message every two seconds to a specified multicast group and port. This can be read by other NicNack instances in receive mode.

> sh bin/nicnack.sh send 225.123.123.123 12345 hello
vmnet8: preparing
vmnet1: preparing
lo: preparing
wlan0: preparing
vmnet8: configured socket
vmnet1: configured socket
wlan0: configured socket
vmnet8: sending
vmnet1: sending
vmnet1: sent hello
wlan0: sending
wlan0: sent hello
vmnet8: sent hello
lo: configured socket
lo: sending
lo: sent hello
vmnet1: sent hello
vmnet8: sent hello
lo: sent hello
wlan0: sent hello
vmnet1: sent hello
wlan0: sent hello
vmnet8: sent hello
lo: sent hello

3) Receive mode. In this mode NicNack listens for and displays messages sent to a specified multicast group and port by NicNack instances in send mode. Used in conjunction with Send mode this can be used to establish whether or not multicast traffic is successfully propagated between two hosts. Note that multicast visibility is not symmetric, i.e. jhost A's ability to send multicast packets to host B does not imply host B's ability to send packets to host A. A sample from a receive mode NicNack session follows.

> sh bin/nicnack.sh receive 225.123.123.123 12345
vmnet8: preparing
lo: preparing
wlan0: preparing
vmnet1: preparing
wlan0: configued socket
wlan0: receiving
vmnet1: configued socket
vmnet1: receiving
vmnet8: configued socket
vmnet8: receiving
lo: configued socket
lo: receiving
wlan0: received 'hello'
vmnet1: received 'hello'
vmnet8: received 'hello'
lo: received 'hello'

If, having run the NicNack utility, you suspect that IP multicast may be the issue, the following two areas should be looked at in more detail.

The security firewall on one, a subset, or all of your machines that are running the Newton environment may be configured by default to block IP multicast traffic.

Linux - To enable multicast send / receive capability for Linux systems, insert the following entry into the operating system's iptable

INPUT -d 224.0.0.0/4 -j ACCEPT

Windows - In the case of Windows XP, by default, the Group Policy settings for the Windows Firewall are "Not Configured" for all objects. This allows the Windows Firewall to use its default settings, which are quite restrictive. With respect to multicast the default settings prohibits unicast response to multicast or broadcast requests.

On the relevant machines, edit Network > Network Connections > Firewall and set a disable policy

Prohibit unicast response to multicast or broadcast requests

Not Configured - The incoming unicast response is accepted if received within 3 seconds. The setting can be overridden by a local administrator.

Enabled - The incoming unicast response is dropped. This cannot be overridden by a local administrator.

Disabled - The incoming unicast response is accepted if received within 3 seconds. This cannot be overridden by a local administrator.

For other Firewall products or alternative Microsoft operating system versions. Check relevant documentation.

Simple layer II network switches treat multicast traffic in the same manner as broadcast traffic, that is, they will forwarded multicast packets to all active switch ports. If your Newton test machines connect to a layer II network, comprising of one or more simple layer II ethernet switches (these interconnected without intervening layer III routers), then the network is unlikely to be the cause of IP multicast connectivity issues.

In more sophisticated environments, network infrastructure supports a mulitcast protocol known as IGMP. Within an IGMP enabled network environment, traffic associated with a multicast group is only forwarded to ports that have members participating in that group. A layer-2 switch supporting IGMP snooping can passively snoop on IGMP Query, Report and Leave (IGMP version 2) packets transferred between IP Multicast Routers/Switches and IP Multicast hosts (on each switch port), to learn the required IP Multicast group membership required by each port. The advantage of using IGMP snooping is that it generates no additional network traffic, whilst significantly reduce multicast traffic passing through your switch - as all multicast is only targeted to hosts that have registered interest in the multicast group.

If Newton functions correctly when run on a single machine and also when run in a distributed environment with machines connected via a simple layer II network, but fail in a more complex network environments, then multicast configuration of the network is the the most likely cause. In such circumstances politely explain the problem to your network administrators. The network administrators will be able to help you diagnose the issue in greater detail, and may be willing/able to disable IGMP snooping on the relevant switches to verify whether or not IGMP is a contributing factor.