# EC2 VPC Discovery Problems **URL:** \ **Category:** Elasticsearch\ **Created:** [February 1, 2013, 1:53am UTC](https://discuss.elastic.co/t/ec2-vpc-discovery-problems/10581 "2013-02-01T01:53:55Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![NickHaggmark](https://avatars.discourse-cdn.com/v4/letter/n/5e9695/32.png) [@NickHaggmark](https://discuss.elastic.co/u/NickHaggmark)\ **Post date:** [February 1, 2013, 1:53am UTC](https://discuss.elastic.co/t/ec2-vpc-discovery-problems/10581/1 "2013-02-01T01:53:55Z")
Hi Guys, I've recently spun up a new ES cluster (2 nodes) to replace my old stack. The new cluster is using the newest ES version (0.20.4) and newest AWS plugin (1.10.0) and is backing to S3. I cannot get them to talk to each other now and it's making me crazy. I'm using two Ubuntu 12.04 EC2 instances inside of a VPC. The nodes are in the same region, zone and subnet and the security groups for both the LB and EC2 instances both have 9200 and 9300 open to the world. Here is a copy of their config files: ------- NODE 1 ------- ################################### Cluster ################################### cluster.name: wtr\_search\_production node.name: wtr-search-watchtower-i-70776729 #################################### Index #################################### index.number\_of\_shards: 6 index.number\_of\_replicas: 1 #################################### Paths #################################### path.data: /usr/local/var/data/elasticsearch path.logs: /usr/local/var/log/elasticsearch ################################### Memory #################################### bootstrap.mlockall: true ################################## Discovery ################################## discovery.type: ec2 discovery.ec2.availability\_zones: us-west-1a discovery.ec2.ping\_timeout: 30s discovery.ec2.tag: wtrsearch\_production cloud.node.auto\_attributes: true cloud.aws.region: us-west-1 cloud.aws.access\_key: [omitted] cloud.aws.secret\_key: [omitted] ################################## Persistence ################################## gateway.type: s3 gateway.s3.bucket: wtr-search-data-us-west-1-test ------- NODE 2 ------- ################################### Cluster ################################### cluster.name: wtr\_search\_production node.name: wtr-search-watchtower-i-e27666bb #################################### Index #################################### index.number\_of\_shards: 6 index.number\_of\_replicas: 1 #################################### Paths #################################### path.data: /usr/local/var/data/elasticsearch path.logs: /usr/local/var/log/elasticsearch ################################### Memory #################################### bootstrap.mlockall: true ################################## Discovery ################################## discovery.type: ec2 discovery.ec2.availability\_zones: us-west-1a discovery.ec2.ping\_timeout: 30s discovery.ec2.tag: wtrsearch\_production cloud.node.auto\_attributes: true cloud.aws.region: us-west-1 cloud.aws.access\_key: [omitted] cloud.aws.secret\_key: [omitted] ################################## Persistence ################################## gateway.type: s3 gateway.s3.bucket: wtr-search-data-us-west-1-test * * * Can anyone think of any reason why these two wouldn't be able to talk to one another? I'm absolutely pulling my hair out. They both have cluster health outputs that look like this: { - cluster\_name: wtr\_search\_production - status: green - timed\_out: false - number\_of\_nodes: 1 - number\_of\_data\_nodes: 1 - active\_primary\_shards: 0 - active\_shards: 0 - relocating\_shards: 0 - initializing\_shards: 0 - unassigned\_shards: 0 } They both have cluster state outputs that look like this: { - cluster\_name: wtr\_search\_production - master\_node: HPscfXXMQNqSIuXA3b6MLQ - blocks: { } - nodes: { - HPscfXXMQNqSIuXA3b6MLQ: { - name: wtr-search-watchtower-i-70776729 - transport\_address: inet[/10.200.60.18:9300] - attributes: { - aws\_availability\_zone: us-west-1a } } } - metadata: { - templates: { } - indices: { } } - routing\_table: { - indices: { } } - routing\_nodes: { - unassigned: [] - nodes: { - HPscfXXMQNqSIuXA3b6MLQ: [] } } - allocations: [] } Except with (obviously) different addresses, names and master nodes. Please help! Thanks! -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![Ajay\_Sharma](https://avatars.discourse-cdn.com/v4/letter/a/6a8cbe/32.png) [@Ajay\_Sharma](https://discuss.elastic.co/u/Ajay_Sharma)\ **Post date:** [February 1, 2013, 2:09am UTC](https://discuss.elastic.co/t/ec2-vpc-discovery-problems/10581/2 "2013-02-01T02:09:57Z")
I'm assuming that you checked all the basics: - security group - acl's - local firewall on the box - telnetting to port 9300 from one box to another? I'm having a similar issue right now and everything looks solid except for the telnet part. Can't seem to get these boxes to talk to each other. On Thursday, January 31, 2013 5:53:55 PM UTC-8, Nicholas Haggmark wrote: > Hi Guys, > > I've recently spun up a new ES cluster (2 nodes) to replace my old stack. > The new cluster is using the newest ES version (0.20.4) and newest AWS > plugin (1.10.0) and is backing to S3. I cannot get them to talk to each > other now and it's making me crazy. I'm using two Ubuntu 12.04 EC2 > instances inside of a VPC. The nodes are in the same region, zone and > subnet and the security groups for both the LB and EC2 instances both have > 9200 and 9300 open to the world. > > Here is a copy of their config files: > > ------- NODE 1 ------- > > ################################### Cluster > ################################### > > cluster.name: wtr\_search\_production > node.name: wtr-search-watchtower-i-70776729 > > #################################### Index > #################################### > > index.number\_of\_shards: 6 > index.number\_of\_replicas: 1 > > #################################### Paths > #################################### > > path.data: /usr/local/var/data/elasticsearch > path.logs: /usr/local/var/log/elasticsearch > > ################################### Memory > #################################### > > bootstrap.mlockall: true > > ################################## Discovery > ################################## > discovery.type: ec2 > discovery.ec2.availability\_zones: us-west-1a > discovery.ec2.ping\_timeout: 30s > discovery.ec2.tag: wtrsearch\_production > > cloud.node.auto\_attributes: true > cloud.aws.region: us-west-1 > cloud.aws.access\_key: [omitted] > cloud.aws.secret\_key: [omitted] > > ################################## Persistence > ################################## > gateway.type: s3 > gateway.s3.bucket: wtr-search-data-us-west-1-test > > ------- NODE 2 ------- > > ################################### Cluster > ################################### > > cluster.name: wtr\_search\_production > node.name: wtr-search-watchtower-i-e27666bb > > #################################### Index > #################################### > > index.number\_of\_shards: 6 > index.number\_of\_replicas: 1 > > #################################### Paths > #################################### > > path.data: /usr/local/var/data/elasticsearch > path.logs: /usr/local/var/log/elasticsearch > > ################################### Memory > #################################### > > bootstrap.mlockall: true > > ################################## Discovery > ################################## > discovery.type: ec2 > discovery.ec2.availability\_zones: us-west-1a > discovery.ec2.ping\_timeout: 30s > discovery.ec2.tag: wtrsearch\_production > > cloud.node.auto\_attributes: true > cloud.aws.region: us-west-1 > cloud.aws.access\_key: [omitted] > cloud.aws.secret\_key: [omitted] > > ################################## Persistence > ################################## > gateway.type: s3 > gateway.s3.bucket: wtr-search-data-us-west-1-test > > * * * > > Can anyone think of any reason why these two wouldn't be able to talk to > one another? I'm absolutely pulling my hair out. > > They both have cluster health outputs that look like this: > > { > > - cluster\_name: wtr\_search\_production > - status: green > - timed\_out: false > - number\_of\_nodes: 1 > - number\_of\_data\_nodes: 1 > - active\_primary\_shards: 0 > - active\_shards: 0 > - relocating\_shards: 0 > - initializing\_shards: 0 > - unassigned\_shards: 0 > > } > > They both have cluster state outputs that look like this: > > { > > - cluster\_name: wtr\_search\_production > - master\_node: HPscfXXMQNqSIuXA3b6MLQ > - blocks: { } > - nodes: { > - HPscfXXMQNqSIuXA3b6MLQ: { > - name: wtr-search-watchtower-i-70776729 > - transport\_address: inet[/10.200.60.18:9300] > - attributes: { > - aws\_availability\_zone: us-west-1a > } > } > } > > - metadata: { > - templates: { } > - indices: { } > } > > - routing\_table: { > - indices: { } > } > > - routing\_nodes: { > - unassigned: > - nodes: { > - HPscfXXMQNqSIuXA3b6MLQ: > } > } > > - allocations: > > } > > Except with (obviously) different addresses, names and master nodes. > > Please help! > > Thanks! -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![NickHaggmark](https://avatars.discourse-cdn.com/v4/letter/n/5e9695/32.png) [@NickHaggmark](https://discuss.elastic.co/u/NickHaggmark)\ **Post date:** [February 1, 2013, 2:41am UTC](https://discuss.elastic.co/t/ec2-vpc-discovery-problems/10581/3 "2013-02-01T02:41:24Z")
Correct. I'm able to curl the other from each node on 9200 and able to telnet to the other on 9300. For the purposes of experimentation, i've opened 9200 and 9300 at the ELB and instance security group to any ip. I can hit the load balancer and it round robins me between the two nodes, they just can't seem to find one another. -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![Paul\_Smith](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/paul_smith/32/1323_2.png) [@Paul\_Smith](https://discuss.elastic.co/u/Paul_Smith)\ **Post date:** [February 1, 2013, 3:06am UTC](https://discuss.elastic.co/t/ec2-vpc-discovery-problems/10581/4 "2013-02-01T03:06:51Z")
i would consider editing the logging.yml file one each node and configure the 'discovery' and 'gateway' logger root to be DEBUG, you may find out stuff it is trying, but 'discarding' the other node due to specific logic/attribute values not yet clear. For example, maybe the 'host\_type' property of the plugin (defaulting to private\_ip) may be interfering within your VPC setup, but the extra detailed logging during the discovery protocol modules may give you insight into what is/isn't happening. Paul On 1 February 2013 13:41, Nicholas Haggmark [nhaggmark@gmail.com](mailto:nhaggmark@gmail.com) wrote: > Correct. > > I'm able to curl the other from each node on 9200 and able to telnet to > the other on 9300. For the purposes of experimentation, i've opened 9200 > and 9300 at the ELB and instance security group to any ip. I can hit the > load balancer and it round robins me between the two nodes, they just can't > seem to find one another. > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![NickHaggmark](https://avatars.discourse-cdn.com/v4/letter/n/5e9695/32.png) [@NickHaggmark](https://discuss.elastic.co/u/NickHaggmark)\ **Post date:** [February 1, 2013, 3:49am UTC](https://discuss.elastic.co/t/ec2-vpc-discovery-problems/10581/5 "2013-02-01T03:49:14Z")
Well, it appears to be finding it: [2013-02-01 03:37:56,112][TRACE][discovery.ec2] [wtr-search-watchtower-i-e27666bb] adding i-70776729, address 10.200.60.18, transport\_address inet[/10.200.60.18:9300] Then it adds it to a list of dynamic discovery nodes (it's in the list, but it's really long): [2013-02-01 03:37:56,116][DEBUG][discovery.ec2] [wtr-search-watchtower-i-e27666bb] using dynamic discovery nodes [[#cloud-i-0e21a948-0][inet[/10.178.30.112:9300]]... Then it disconnects... [2013-02-01 03:38:42,542][TRACE][discovery.zen.ping.unicast] [wtr-search-watchtower-i-e27666bb] [1] disconnecting from [#cloud-i-70776729-0][inet[/10.200.60.18:9300]] I wonder what is happening at this point? -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![NickHaggmark](https://avatars.discourse-cdn.com/v4/letter/n/5e9695/32.png) [@NickHaggmark](https://discuss.elastic.co/u/NickHaggmark)\ **Post date:** [February 1, 2013, 3:57am UTC](https://discuss.elastic.co/t/ec2-vpc-discovery-problems/10581/6 "2013-02-01T03:57:41Z")
If the other node isn't on the list of servers output as : [2013-02-01 03:54:26,288][TRACE][discovery.zen.ping.unicast] [wtr-search-watchtower-i-e27666bb] [1] connecting (light) to [#cloud-i-0e21a948-0][inet[/10.178.30.112:9300]] Does this mean that it's somehow getting filtered out an is not trying to connect? -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![NickHaggmark](https://avatars.discourse-cdn.com/v4/letter/n/5e9695/32.png) [@NickHaggmark](https://discuss.elastic.co/u/NickHaggmark)\ **Post date:** [February 1, 2013, 4:03am UTC](https://discuss.elastic.co/t/ec2-vpc-discovery-problems/10581/7 "2013-02-01T04:03:06Z")
Out of curiosity, is there a size limit to the number of servers it will attempt to contact? On the list of servers being pulled back (which is long), the new node is dead last. I'm curious if perhaps it's just not attempting to connect to it? -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![Paul\_Smith](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/paul_smith/32/1323_2.png) [@Paul\_Smith](https://discuss.elastic.co/u/Paul_Smith)\ **Post date:** [February 1, 2013, 4:29am UTC](https://discuss.elastic.co/t/ec2-vpc-discovery-problems/10581/8 "2013-02-01T04:29:22Z")
just triple checking, but you have marked these 2 EC2 nodes with the 'wtrsearch\_production' tag via the console or as part of the launch API call right? You've set the filter by tag, so maybe they see each other, but discount each other because the other doesn't belong to that tag (because neither does, maybe..) Just want to triple check that from EC2 point of view, that named instance Id does appear to come set with that tag? Paul On 1 February 2013 15:03, Nicholas Haggmark [nhaggmark@gmail.com](mailto:nhaggmark@gmail.com) wrote: > Out of curiosity, is there a size limit to the number of servers it will > attempt to contact? On the list of servers being pulled back (which is > long), the new node is dead last. I'm curious if perhaps it's just not > attempting to connect to it? > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![NickHaggmark](https://avatars.discourse-cdn.com/v4/letter/n/5e9695/32.png) [@NickHaggmark](https://discuss.elastic.co/u/NickHaggmark)\ **Post date:** [February 1, 2013, 4:42am UTC](https://discuss.elastic.co/t/ec2-vpc-discovery-problems/10581/9 "2013-02-01T04:42:13Z")
Sure did. I got it to work. Basically, I manually went to both nodes and added their current security group as a filter criteria and restarted. This worked immediately. It would seem that it only allows for a certain number of async connection attempts (I think?). This is going to be problematic for me since I'm using cloud formation and chef to built out and bootstrap entire stacks. It's possible that I incorrectly used tags previously, so I'll try that instead. Otherwise, I'll have to hit the AWS api using Ruby during the chef deploy to name match the security group that was generated for the instances in the stack. Either way should work. Thanks! Nick -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![NickHaggmark](https://avatars.discourse-cdn.com/v4/letter/n/5e9695/32.png) [@NickHaggmark](https://discuss.elastic.co/u/NickHaggmark)\ **Post date:** [February 1, 2013, 4:45am UTC](https://discuss.elastic.co/t/ec2-vpc-discovery-problems/10581/10 "2013-02-01T04:45:25Z")
Oh, you know what? It's probable that I was misusing the tags. That was probably part of my problem. I thought that the tags were AWS discovery plugin specific. I didn't realize they were actually matching against the EC2 tags. I thought they were just matching against other nodes in ES with that in their config. Thanks again! Nick On Thursday, January 31, 2013 8:42:13 PM UTC-8, Nicholas Haggmark wrote: > Sure did. > > I got it to work. Basically, I manually went to both nodes and added their > current security group as a filter criteria and restarted. This worked > immediately. It would seem that it only allows for a certain number of > async connection attempts (I think?). This is going to be problematic for > me since I'm using cloud formation and chef to built out and bootstrap > entire stacks. It's possible that I incorrectly used tags previously, so > I'll try that instead. Otherwise, I'll have to hit the AWS api using Ruby > during the chef deploy to name match the security group that was generated > for the instances in the stack. Either way should work. > > Thanks! > > Nick -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![Paul\_Smith](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/paul_smith/32/1323_2.png) [@Paul\_Smith](https://discuss.elastic.co/u/Paul_Smith)\ **Post date:** [February 1, 2013, 4:47am UTC](https://discuss.elastic.co/t/ec2-vpc-discovery-problems/10581/11 "2013-02-01T04:47:52Z")
yeah, it's definitely using EC2 specific tags, this is a way for the ES to quickly filter the node list to check ones worth checking. the EC2 api's can quickly bring back a list of nodes just with that tag. Imagine a very large Hadoop cluster, with a corresponding large-ish ES cluster working together. The ES nodes just want to scan over the list of ES nodes only, filtering the Hadoop ones out for checking if that host is up or not. I didn't think the security group filter was required, it's another way of matching though in a similar way. glad it worked out for you, good luck with your ES project! Paul On 1 February 2013 15:45, Nicholas Haggmark [nhaggmark@gmail.com](mailto:nhaggmark@gmail.com) wrote: > Oh, you know what? It's probable that I was misusing the tags. That was > probably part of my problem. I thought that the tags were AWS discovery > plugin specific. I didn't realize they were actually matching against the > EC2 tags. I thought they were just matching against other nodes in ES with > that in their config. > > Thanks again! > > Nick > > On Thursday, January 31, 2013 8:42:13 PM UTC-8, Nicholas Haggmark wrote: > > > Sure did. > > > > I got it to work. Basically, I manually went to both nodes and added > > their current security group as a filter criteria and restarted. This > > worked immediately. It would seem that it only allows for a certain number > > of async connection attempts (I think?). This is going to be problematic > > for me since I'm using cloud formation and chef to built out and bootstrap > > entire stacks. It's possible that I incorrectly used tags previously, so > > I'll try that instead. Otherwise, I'll have to hit the AWS api using Ruby > > during the chef deploy to name match the security group that was generated > > for the instances in the stack. Either way should work. > > > > Thanks! > > > > Nick > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![NickHaggmark](https://avatars.discourse-cdn.com/v4/letter/n/5e9695/32.png) [@NickHaggmark](https://discuss.elastic.co/u/NickHaggmark)\ **Post date:** [February 1, 2013, 4:51am UTC](https://discuss.elastic.co/t/ec2-vpc-discovery-problems/10581/12 "2013-02-01T04:51:11Z")
Many thanks! On Thursday, January 31, 2013 8:47:52 PM UTC-8, tallpsmith wrote: > yeah, it's definitely using EC2 specific tags, this is a way for the ES to > quickly filter the node list to check ones worth checking. the EC2 api's > can quickly bring back a list of nodes just with that tag. Imagine a very > large Hadoop cluster, with a corresponding large-ish ES cluster working > together. The ES nodes just want to scan over the list of ES nodes only, > filtering the Hadoop ones out for checking if that host is up or not. > > I didn't think the security group filter was required, it's another way of > matching though in a similar way. > > glad it worked out for you, good luck with your ES project! > > Paul > > On 1 February 2013 15:45, Nicholas Haggmark \<[nhag...@gmail.com](mailto:nhag...@gmail.com)\ > > > wrote: > > > Oh, you know what? It's probable that I was misusing the tags. That was > > probably part of my problem. I thought that the tags were AWS discovery > > plugin specific. I didn't realize they were actually matching against the > > EC2 tags. I thought they were just matching against other nodes in ES with > > that in their config. > > > > Thanks again! > > > > Nick > > > > On Thursday, January 31, 2013 8:42:13 PM UTC-8, Nicholas Haggmark wrote: > > > > > Sure did. > > > > > > I got it to work. Basically, I manually went to both nodes and added > > > their current security group as a filter criteria and restarted. This > > > worked immediately. It would seem that it only allows for a certain number > > > of async connection attempts (I think?). This is going to be problematic > > > for me since I'm using cloud formation and chef to built out and bootstrap > > > entire stacks. It's possible that I incorrectly used tags previously, so > > > I'll try that instead. Otherwise, I'll have to hit the AWS api using Ruby > > > during the chef deploy to name match the security group that was generated > > > for the instances in the stack. Either way should work. > > > > > > Thanks! > > > > > > Nick > > > > -- > > You received this message because you are subscribed to the Google Groups > > "elasticsearch" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \. > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**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, 2:53am UTC](https://discuss.elastic.co/t/ec2-vpc-discovery-problems/10581/13 "2017-07-06T02:53:39Z")