Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No name resolution at advertise parameter #1185

Closed
andienase opened this issue Aug 18, 2015 · 7 comments
Closed

No name resolution at advertise parameter #1185

andienase opened this issue Aug 18, 2015 · 7 comments

Comments

@andienase
Copy link

I understand the problem with the private addresses for the bind parameter so I start the consul agent with the -bind paramter but with this I get an error for the advertise address

-> consul agent -node consul-s1-bind consul-s1 -config-file /home/consul/cfg/consul.cfg
==> WARNING: It is highly recommended to set GOMAXPROCS higher than 1
==> Starting raft data migration...
==> Starting Consul agent...
==> Error starting agent: Failed to start Consul server: Failed to start lan serf: Failed to parse advertise address!

The documentation says:
-advertise - The advertise address is used to change the address that we advertise to other nodes in the cluster. By default, the -bind address is advertised.

So ok I tried to tell him the same address as the bind address but it still not working:

-> consul agent -node consul-s1 -bind consul-s1 -advertise consul-s1 -config-file /home/consul/cfg/consul.cfg
==> WARNING: It is highly recommended to set GOMAXPROCS higher than 1
==> Starting raft data migration...
==> Starting Consul agent...
==> Error starting agent: Failed to parse advertise address: consul-s1

The name consul-s1 is resolved via LDAP and is pingable on the os (Linux/SLES 11). The node only starts when I commit the ip address to the advertise parameter.

-> consul agent -node consul-s1 -bind consul-s1 -advertise -config-file /home/consul/cfg/consul.cfg

@aidanhs
Copy link

aidanhs commented Aug 18, 2015

Doesn't this require consul to be aware of NSS in order to be able to find the address on LDAP? Why not just use -advertise $(dig +short consul-s1)?

@highlyunavailable
Copy link
Contributor

"Address" in this case is shorthand for "IP address" since Consul doesn't presuppose the existence of other DNS servers. @aidanhs method would work, or look up the address via some other method like checking the interfaces.

@andienase
Copy link
Author

Sorry in the last command line the ip address after -advertise was missing.

-> consul agent -node consul-s1 -bind consul-s1 -advertise 10.10.10.10 -config-file /home/consul/cfg/consul.cfg

(ip only for example because I have currently no access to server)

What surprises me is that the name resolution is working at the -bind parameter? The 'problem' also exists when the hostname is configured in /etc/hosts

This was referenced Nov 30, 2016
@slackpad
Copy link
Contributor

slackpad commented May 2, 2017

I'm going to close this out - we have documented these as addresses and don't intend to support host lookups in here (even if the path in Go happens to support them).

@slackpad slackpad closed this as completed May 2, 2017
@mitom
Copy link

mitom commented Jun 13, 2017

Would this have an effect in case servers changed IP addresses? As in, does this effectively control how do consul nodes reach out to each other (the member list)?

@Alexey-Tsarev
Copy link

Alexey-Tsarev commented Jun 20, 2017

Yes, if IP changed (because of dhcpclient, a point-to-point protocol, for instance pppoe), then Consul still listening old IP address. This is true when -bind=IP provided.
When -advertise provided, Consul listened on all interfaces:

netstat -nlp | grep consul
tcp        0      0 127.0.0.1:8500          0.0.0.0:*               LISTEN      5825/consul
tcp        0      0 127.0.0.1:8600          0.0.0.0:*               LISTEN      5825/consul
tcp6       0      0 :::8300                 :::*                    LISTEN      5825/consul
tcp6       0      0 :::8301                 :::*                    LISTEN      5825/consul
tcp6       0      0 :::8302                 :::*                    LISTEN      5825/consul
udp        0      0 127.0.0.1:8600          0.0.0.0:*                           5825/consul
udp6       0      0 :::8301                 :::*                                5825/consul
udp6       0      0 :::8302                 :::*                                5825/consul

But, anyway other Consul servers can not connect to this server.

So pointed solution:
#2563
doesn't work in this case - it's necessary to restart Consul with changed IP address.

A solution is a wrapper, which periodically checks interface's IP address and restart Consul when IP changed.
I don't see any other solution. And I think, that Consul should catch IP address changes.

@slackpad
Copy link
Contributor

Consul handling IP address changes is tracked under #1580.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants