# Different behavior in unicast, between ver 17.1 and 17.0?

**URL:** <https://discuss.elastic.co/t/different-behavior-in-unicast-between-ver-17-1-and-17-0/4947>\
**Category:** Elasticsearch\
**Created:** [July 25, 2011, 8:09pm UTC](https://discuss.elastic.co/t/different-behavior-in-unicast-between-ver-17-1-and-17-0/4947 "2011-07-25T20:09:48Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![fucema](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/fucema/32/3160_2.png) [@fucema](https://discuss.elastic.co/u/fucema)\
**Post date:** [July 25, 2011, 8:09pm UTC](https://discuss.elastic.co/t/different-behavior-in-unicast-between-ver-17-1-and-17-0/4947/1 "2011-07-25T20:09:48Z")

</div>

Hi Shay,

I have upgraded from 16.x up to 17.0 in the past and had no problems  
connecting a client only node to a master node using unicast settings.  
Has there been a change in ver 17.1 behavior regarding networking  
between multicast clusters and unicast clients?

After upgrading to 17.1, the unicast client only node is no longer  
"seeing" the master node, and not connecting to the cluster. Cluster  
names have not changed. No other changes were made in configuration,  
except for updating the elastic jar to 17.1. I have also deleted the  
data folders to start the cluster from fresh. The master node has  
default network settings (ie uses multicast).

Here is the client only java startup snippet:

```
	Settings settings = settingsBuilder()
			.put("multicast.enabled", false)
			.put("client.transport.sniff", true)
			.put("cluster.name", "my-foo-cluster")
			.put("discovery.zen.ping.unicast.hosts", "master.foo.bar:9300")
			.build();
	this.node = nodeBuilder().settings(settings).client(true).node();

```

Here is the master elastic search config:

```
	cluster.name: my-foo-cluster
	path.data: /var/data/elasticsearch
	path.logs: /var/log/elasticsearch
	bootstrap.mlockall: true
```

---

<div class="post-metadata">

**Author:** ![fucema](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/fucema/32/3160_2.png) [@fucema](https://discuss.elastic.co/u/fucema)\
**Post date:** [July 25, 2011, 10:29pm UTC](https://discuss.elastic.co/t/different-behavior-in-unicast-between-ver-17-1-and-17-0/4947/2 "2011-07-25T22:29:46Z")

</div>

A followup to this problem.

I have tested the unicast discovery and it works fine when running the  
client and master node on the same computer.

The above posted problem involves a master node and client running on  
different subnets (hence, using unicast discovery from the client  
node). The master node is bound to 192.168.110.xx subnet, and the  
client data only node is on 192.168.109.xx subnet.

Again, prior to 0.17.1, the client node had no problem connecting to  
the master. Nothing else that I can think of has changed, other than  
updating the elastic jar to 0.17.1.

I just tested that unicast discovery works on the same subnet using a  
client only node and a master node running on the same machine. The  
client only node is configured for unicast ping discovery, and the  
master node is using default network configuration.

Anyone else having this problem?

- Seon

---

<div class="post-metadata">

**Author:** ![fucema](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/fucema/32/3160_2.png) [@fucema](https://discuss.elastic.co/u/fucema)\
**Post date:** [July 25, 2011, 11:20pm UTC](https://discuss.elastic.co/t/different-behavior-in-unicast-between-ver-17-1-and-17-0/4947/3 "2011-07-25T23:20:51Z")

</div>

Ok, I enabled TRACE logging out on the discovery module and copied and pasted a portion of it to here:

[https://gist.github.com/1105511](https://gist.github.com/1105511)

The client node (May Parker) is trying to connect to 192.168.109.138:9300 (the master node is Shuma-Gorath) yet it looks like a different node (Longshot) is responding instead.

Of course, Longshot is on a different cluster name so it May Parker should not be joining it.

I can't decipher the logs properly, but it seems like the presence of Long Shot (on the same subnet as May Parker but assigned a different cluster name) is interfering with May Parker joining Shuma-Gorath.

I don't have the time now, but I'm guessing that if I shutdown Longshot everything will work as expected.

---

<div class="post-metadata">

**Author:** ![fucema](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/fucema/32/3160_2.png) [@fucema](https://discuss.elastic.co/u/fucema)\
**Post date:** [July 25, 2011, 11:27pm UTC](https://discuss.elastic.co/t/different-behavior-in-unicast-between-ver-17-1-and-17-0/4947/4 "2011-07-25T23:27:25Z")

</div>

Here is additional output, captured from the start of the node initialization.

[https://gist.github.com/1105530](https://gist.github.com/1105530)

In this sample, the client only node is named [Bes]. The target master that Bes is trying to connect to should be [Shuma-Gorath]. Again, [Longshot] seems to be getting in the way of success.

Any ideas?

---

<div class="post-metadata">

**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\
**Post date:** [July 26, 2011, 4:52am UTC](https://discuss.elastic.co/t/different-behavior-in-unicast-between-ver-17-1-and-17-0/4947/5 "2011-07-26T04:52:13Z")

</div>

Heya, first, the logic did not change between 0.17.1 and 0.17.0, but, after  
analyzing the output you provided, I think I found the problem. It does rely  
on ordering of events, so its not really something that is consistent and  
you might just started to see it.

Here is the issue:  
[Unicast Discovery: Clusters under different cluster names can cause failed discovery · Issue #1159 · elastic/elasticsearch · GitHub](https://github.com/elasticsearch/elasticsearch/issues/1159), and will be part  
of 0.17.2 (which will be released either today or tomorrow).

On Tue, Jul 26, 2011 at 2:27 AM, fucema [fucema@gmail.com](mailto:fucema@gmail.com) wrote:

> Here is additional output, captured from the start of the node  
> initialization.
> 
> [gist:1105530 · GitHub](https://gist.github.com/1105530) [gist:1105530 · GitHub](https://gist.github.com/1105530)
> 
> In this sample, the client only node is named [Bes]. The target master that  
> Bes is trying to connect to should be [Shuma-Gorath]. Again, [Longshot]  
> seems to be getting in the way of success.
> 
> Any ideas?
> 
> --  
> View this message in context:  
> [http://elasticsearch-users.115913.n3.nabble.com/Different-behavior-in-unicast-between-ver-17-1-and-17-0-tp3198574p3199038.html](http://elasticsearch-users.115913.n3.nabble.com/Different-behavior-in-unicast-between-ver-17-1-and-17-0-tp3198574p3199038.html)  
> Sent from the Elasticsearch Users mailing list archive at [Nabble.com](http://Nabble.com).

---

<div class="post-metadata">

**Author:** ![fucema](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/fucema/32/3160_2.png) [@fucema](https://discuss.elastic.co/u/fucema)\
**Post date:** [July 26, 2011, 5:56am UTC](https://discuss.elastic.co/t/different-behavior-in-unicast-between-ver-17-1-and-17-0/4947/6 "2011-07-26T05:56:15Z")

</div>

Thanks Kimchy, you rock. Glad to know it wasn't user error this time. 😉

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 6, 2017, 3:59am UTC](https://discuss.elastic.co/t/different-behavior-in-unicast-between-ver-17-1-and-17-0/4947/7 "2017-07-06T03:59:27Z")

</div>