# Setting for option discovery.zen.ping.unicast.hosts in elasticsearch.yml **URL:** \ **Category:** Elasticsearch\ **Created:** [November 7, 2018, 12:21pm UTC](https://discuss.elastic.co/t/setting-for-option-discovery-zen-ping-unicast-hosts-in-elasticsearch-yml/155710 "2018-11-07T12:21:53Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![vmanohar1](https://avatars.discourse-cdn.com/v4/letter/v/e56c9b/32.png) [@vmanohar1](https://discuss.elastic.co/u/vmanohar1)\ **Post date:** [November 7, 2018, 12:21pm UTC](https://discuss.elastic.co/t/setting-for-option-discovery-zen-ping-unicast-hosts-in-elasticsearch-yml/155710/1 "2018-11-07T12:21:53Z")
As per the documentation setting can be - discovery.zen.ping.unicast.hosts: ["host1", "host2"]. Both hosts host1 and host2 are in their private networks e.g. in 20.x.x.x and 30.x.x.x. These 2 networks can't talk to each other. There are floating IPs to host1 and host2 that can talk to each other on required port(s) but they are say in 192.x.x.x. But IPs in 192.x.x.x are not mapped on local NIC. Hyperviser allows redirects to appropriate host in 20.x.x.x and 30.x.x.x. What configuration should be done in this case so that host1,host2 can work in one elastic cluster? Is there any way to make that happen? Or only way is to make 20.x.x.x and 30.x.x.x talk to each other on required port(s)?? If you can give any example config to explain how this can still work using 20.x.x.x,30.x.x.x and 192.x.x.x? Thanks very much in advance for your inputs. ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [November 7, 2018, 2:19pm UTC](https://discuss.elastic.co/t/setting-for-option-discovery-zen-ping-unicast-hosts-in-elasticsearch-yml/155710/2 "2018-11-07T14:19:25Z")
> [@vmanohar1](#): > > Both hosts host1 and host2 are in their private networks e.g. in 20.x.x.x and 30.x.x.x. These 2 networks can't talk to each other. This sounds like it is going to cause trouble. The simplest plan is really to allow the nodes to talk to each other properly. Elasticsearch assumes each node is accessible from all other nodes at a single address, so there will be difficulties if a node has different addresses depending on the location of the observer on the network. It's possible that setting `network.bind_host` to `20.x.x.x` or `30.x.x.x` and `network.publish_host` to `192.x.x.x` will do what you want, but it's also possible that what you want is not feasible with such a segregated network. ---
**Author:** ![vmanohar1](https://avatars.discourse-cdn.com/v4/letter/v/e56c9b/32.png) [@vmanohar1](https://discuss.elastic.co/u/vmanohar1)\ **Post date:** [November 7, 2018, 3:17pm UTC](https://discuss.elastic.co/t/setting-for-option-discovery-zen-ping-unicast-hosts-in-elasticsearch-yml/155710/3 "2018-11-07T15:17:10Z")
Thanks for reply.. Correct me if my understanding is not right here.. But I think in the suggestion you gave, network.publish\_host IP (192.x.x.x) needs to be mapped on one of the NIC cards on the host for it to work, isn't it? ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [November 7, 2018, 3:38pm UTC](https://discuss.elastic.co/t/setting-for-option-discovery-zen-ping-unicast-hosts-in-elasticsearch-yml/155710/4 "2018-11-07T15:38:03Z")
> [@vmanohar1](#): > > But I think in the suggestion you gave, network.publish\_host IP (192.x.x.x) needs to be mapped on one of the NIC cards on the host for it to work, isn't it? I'm not sure. Did you try it and, if so, were there any messages indicating whether or not it had worked? ---
**Author:** ![vmanohar1](https://avatars.discourse-cdn.com/v4/letter/v/e56c9b/32.png) [@vmanohar1](https://discuss.elastic.co/u/vmanohar1)\ **Post date:** [November 8, 2018, 1:35pm UTC](https://discuss.elastic.co/t/setting-for-option-discovery-zen-ping-unicast-hosts-in-elasticsearch-yml/155710/5 "2018-11-08T13:35:37Z")
I believe that I had tried that long ago.. I will try it again and then confirm.. ---
**Author:** ![vmanohar1](https://avatars.discourse-cdn.com/v4/letter/v/e56c9b/32.png) [@vmanohar1](https://discuss.elastic.co/u/vmanohar1)\ **Post date:** [November 8, 2018, 3:00pm UTC](https://discuss.elastic.co/t/setting-for-option-discovery-zen-ping-unicast-hosts-in-elasticsearch-yml/155710/6 "2018-11-08T15:00:05Z")
How should I configure discovery.zen.ping.unicast.hosts: in this case? I think that this one is a problem. If you configure private IPs(10.x.. and 20.x..), then they can't talk to each other. If you configure 192.x.x.x, then elasticsearch won't start.. That was my observation from past, hence this question.. Please let me know. Thanks. ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [November 8, 2018, 3:24pm UTC](https://discuss.elastic.co/t/setting-for-option-discovery-zen-ping-unicast-hosts-in-elasticsearch-yml/155710/7 "2018-11-08T15:24:36Z")
> [@vmanohar1](#): > > How should I configure discovery.zen.ping.unicast.hosts: in this case? `discovery.zen.ping.unicast.hosts` should be a list containing the `192.x.x.x` addresses of the other nodes. > [@vmanohar1](#): > > If you configure 192.x.x.x, then elasticsearch won't start This seems unexpected. What error does it give? ---
**Author:** ![vmanohar1](https://avatars.discourse-cdn.com/v4/letter/v/e56c9b/32.png) [@vmanohar1](https://discuss.elastic.co/u/vmanohar1)\ **Post date:** [November 8, 2018, 4:47pm UTC](https://discuss.elastic.co/t/setting-for-option-discovery-zen-ping-unicast-hosts-in-elasticsearch-yml/155710/8 "2018-11-08T16:47:43Z")
Let me test again.. ---
**Author:** ![vmanohar1](https://avatars.discourse-cdn.com/v4/letter/v/e56c9b/32.png) [@vmanohar1](https://discuss.elastic.co/u/vmanohar1)\ **Post date:** [November 8, 2018, 5:32pm UTC](https://discuss.elastic.co/t/setting-for-option-discovery-zen-ping-unicast-hosts-in-elasticsearch-yml/155710/9 "2018-11-08T17:32:43Z")
Tested.. Cluster is formed when you set - network.bind\_host: 0.0.0.0 network.publish\_host: 192.x.x.x discovery.zen.ping.unicast.hosts: 192.x.x.x [of remote host in the cluster] Now we should be able to use 192.x.x.x for adding data.. My configs look ok? ---
**Author:** ![vmanohar1](https://avatars.discourse-cdn.com/v4/letter/v/e56c9b/32.png) [@vmanohar1](https://discuss.elastic.co/u/vmanohar1)\ **Post date:** [November 8, 2018, 5:33pm UTC](https://discuss.elastic.co/t/setting-for-option-discovery-zen-ping-unicast-hosts-in-elasticsearch-yml/155710/10 "2018-11-08T17:33:01Z")
Thanks for your quick inputs. ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [November 8, 2018, 6:09pm UTC](https://discuss.elastic.co/t/setting-for-option-discovery-zen-ping-unicast-hosts-in-elasticsearch-yml/155710/11 "2018-11-08T18:09:00Z")
> [@vmanohar1](#): > > My configs look ok? Looks good to me. Setting `bind_host` to `0.0.0.0` makes sense if you want it to listen on all available interfaces. Glad to hear it's worked! ---
**Author:** ![vmanohar1](https://avatars.discourse-cdn.com/v4/letter/v/e56c9b/32.png) [@vmanohar1](https://discuss.elastic.co/u/vmanohar1)\ **Post date:** [November 8, 2018, 6:25pm UTC](https://discuss.elastic.co/t/setting-for-option-discovery-zen-ping-unicast-hosts-in-elasticsearch-yml/155710/12 "2018-11-08T18:25:14Z")
Cool.. I will use this now.. Thanks. Ticket can be closed. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [December 6, 2018, 6:25pm UTC](https://discuss.elastic.co/t/setting-for-option-discovery-zen-ping-unicast-hosts-in-elasticsearch-yml/155710/13 "2018-12-06T18:25:16Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.