John Martyniak wrote:
I am running Mac OS X.
So en0 points to the external address and en1 points to the internal
address on both machines.
Here is the internal results from duey:
en1: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST>
mtu 1500
inet6 fe80::21e:52ff:fef4:65%en1 prefixlen 64 scopeid 0x5
inet 192.168.1.102 netmask 0xffffff00 broadcast 192.168.1.255
ether 00:1e:52:f4:00:65
media: autoselect (1000baseT <full-duplex>) status: active
lladdr 00:23:32:ff:fe:1a:20:66
media: autoselect <full-duplex> status: inactive
supported media: autoselect <full-duplex>
Here are the internal results from huey:
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::21e:52ff:fef3:f489%en1 prefixlen 64 scopeid 0x5
inet 192.168.1.103 netmask 0xffffff00 broadcast 192.168.1.255
what does
nslookup 192.168.1.103
and
nslookup 192.168.1.102
say?
There really ought to be different names for them.
> I have some other applications running on these machines, that
> communicate across the internal network and they work perfectly.
I admire their strength. Multihost systems cause us trouble. That and
machines that don't quite know who they are
http://jira.smartfrog.org/jira/browse/SFOS-5
https://issues.apache.org/jira/browse/HADOOP-3612
https://issues.apache.org/jira/browse/HADOOP-3426
https://issues.apache.org/jira/browse/HADOOP-3613
https://issues.apache.org/jira/browse/HADOOP-5339
One thing to consider is that some of the various services of Hadoop are
bound to 0:0:0:0, which means every Ipv4 address, you really want to
bring up everything, including jetty services, on the en0 network
adapter, by binding them to 192.168.1.102; this will cause anyone
trying to talk to them over the other network to fail, which at least
find the problem sooner rather than later
