Migration guide says:
Elasticsearch now binds to the loopback interface by default (usually
127.0.0.1 or ::1). The network.host setting can be specified to change
this behavior.
But this is a little confusing, because it still sends multicast packets over all interfaces (224.2.2.4). Instead, when we are only bound to loopback interface, I think we should use a link-local scoped address (e.g. 224.0.0.x). Ideally we'd use node-local if ipv4 had it (nodes bound to different loopback interfaces won't see each other). ipv6 can do node-local though.
Just startup another node on the same network with -Des.network.host= and you will see that it gets multicast packets from the other machine (of course things don't work, since its advertising localhost):
[2015-08-15 22:19:45,835][WARN ][org.elasticsearch.discovery.zen.ping.multicast] [Lorna Dane] failed to connect to requesting node [Locksmith][ywu92vT0Q0OYRNo-EmK01w][mac2][inet[/127.0.0.1:9300]]
ConnectTransportException[[Locksmith][inet[/127.0.0.1:9300]] connect_timeout[30s]]; nested: ConnectException[Connection refused: /127.0.0.1:9300];
at org.elasticsearch.transport.netty.NettyTransport.connectToChannels(NettyTransport.java:827)
at org.elasticsearch.transport.netty.NettyTransport.connectToNode(NettyTransport.java:760)
at org.elasticsearch.transport.netty.NettyTransport.connectToNode(NettyTransport.java:733)
at org.elasticsearch.transport.TransportService.connectToNode(TransportService.java:234)
at org.elasticsearch.discovery.zen.ping.multicast.MulticastZenPing$Receiver$1.run(MulticastZenPing.java:537)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.net.ConnectException: Connection refused: /127.0.0.1:9300
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
at org.jboss.netty.channel.socket.nio.NioClientBoss.connect(NioClientBoss.java:152)
at org.jboss.netty.channel.socket.nio.NioClientBoss.processSelectedKeys(NioClientBoss.java:105)
at org.jboss.netty.channel.socket.nio.NioClientBoss.process(NioClientBoss.java:79)
at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337)
at org.jboss.netty.channel.socket.nio.NioClientBoss.run(NioClientBoss.java:42)
at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
... 3 more
Try the same scenario with bin/elasticsearch -Ddiscovery.zen.ping.multicast.group=224.0.0.200 and you can bring up multiple instances on one machine, but you won't see these pings from another machine. With mac at least there is an issue, and even changing the address here does not work...
Migration guide says:
Elasticsearch now binds to the loopback interface by default (usually
127.0.0.1or::1). Thenetwork.hostsetting can be specified to changethis behavior.
But this is a little confusing, because it still sends multicast packets over all interfaces (224.2.2.4). Instead, when we are only bound to loopback interface, I think we should use a link-local scoped address (e.g. 224.0.0.x). Ideally we'd use node-local if ipv4 had it (nodes bound to different loopback interfaces won't see each other). ipv6 can do node-local though.
Just startup another node on the same network with -Des.network.host= and you will see that it gets multicast packets from the other machine (of course things don't work, since its advertising localhost):
[2015-08-15 22:19:45,835][WARN ][org.elasticsearch.discovery.zen.ping.multicast] [Lorna Dane] failed to connect to requesting node [Locksmith][ywu92vT0Q0OYRNo-EmK01w][mac2][inet[/127.0.0.1:9300]]
ConnectTransportException[[Locksmith][inet[/127.0.0.1:9300]] connect_timeout[30s]]; nested: ConnectException[Connection refused: /127.0.0.1:9300];
at org.elasticsearch.transport.netty.NettyTransport.connectToChannels(NettyTransport.java:827)
at org.elasticsearch.transport.netty.NettyTransport.connectToNode(NettyTransport.java:760)
at org.elasticsearch.transport.netty.NettyTransport.connectToNode(NettyTransport.java:733)
at org.elasticsearch.transport.TransportService.connectToNode(TransportService.java:234)
at org.elasticsearch.discovery.zen.ping.multicast.MulticastZenPing$Receiver$1.run(MulticastZenPing.java:537)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.net.ConnectException: Connection refused: /127.0.0.1:9300
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
at org.jboss.netty.channel.socket.nio.NioClientBoss.connect(NioClientBoss.java:152)
at org.jboss.netty.channel.socket.nio.NioClientBoss.processSelectedKeys(NioClientBoss.java:105)
at org.jboss.netty.channel.socket.nio.NioClientBoss.process(NioClientBoss.java:79)
at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337)
at org.jboss.netty.channel.socket.nio.NioClientBoss.run(NioClientBoss.java:42)
at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
... 3 more
Try the same scenario with
bin/elasticsearch -Ddiscovery.zen.ping.multicast.group=224.0.0.200and you can bring up multiple instances on one machine, but you won't see these pings from another machine. With mac at least there is an issue, and even changing the address here does not work...