Consul binds with private ip along with loopback ip

[buro1983]

consul version for both Client and Server

Consul v0.6.4
Consul Protocol: 3 (Understands back to: 1)

consul info for Server

Server config:

{
    "server": true,
    "bootstrap": true,
    "bind_addr": "127.0.0.1",
    "client_addr": "127.0.0.1",
    "ports": {
                 "dns": -1,
                 "http": -1,
                 "https": 8500,
                 "rpc": 8400,
                 "serf_lan": 8301,
                 "serf_wan": 8302,
                 "server": 8300
               },
    "start_join": [],
    "disable_update_check": true,
    "data_dir": "/usr/local/consul",
    "cert_file": "/usr/local/certs/service.crt",
    "key_file": "/usr/local/certs/service.key",
    "ca_file": "/usr/local/certs/service.ca",
    "verify_incoming": true,
    "verify_outgoing": true,
    "encrypt": "iJ0sXI5pvkFPIDlympraKQ==",
    "enable_syslog": true,
    "syslog_facility": "LOCAL5",
    "log_level": "ERR"
}

Operating system and Environment details

Linux version 2.6.32-573.el6.x86_64

Description of the Issue (and unexpected/desired result)

I have configured more than one private ips on our box (10.131.X.X) along with loop back ip. Consul config has bind address as 127.0.0.1 but consul is trying to bind with first private ip along with loopback ip. peers.json has entry for both because of that consul is not able to select cluster leader. Consul selects leader once I manually remove wrong entry from peers.json. But is does not give guarantee that this will not happen on restart of consul.

I have got another similar issue (#928) and it is mentioned as fixed. Can anyone please point me out what I am doing wrong.

[moofish32]

@buro1983 -- a month later, but I assume you have figured out the issues. I suspect it was pretty difficult to talk to a server bound to LO, but perhaps you had some other magic on the box. Ready to close this?

[sean-]

@buro1983 you may want to give the latest code in master a twirl and let us know if that would have helped out your situation any. There is now syntax for selecting the "correct" IP address, such as getting the first "usable" IP address on an interface, or any other manner of network craziness is likely possible now as a template evaluated address parameter can be passed to Consul addresses (e.g. -bind or bind_addr, or any other *_addr-like parameter):

-bind='{{ GetInterfaceIP "eth0" }}'
-bind='{{ GetAllInterfaces | include "network" "10.99.0.0/24" }}'
-bind='{{ GetDefaultInterfaces | include "network" "10.99.0.0/24" | sort "size,address" | attr "address" }}'
-bind='{{ GetAllInterfaces | exclude "rfc" "6890" | sort "type,size,address" | include "flags" "up|forwardable" | attr "address" }}'

Very few people should need to do anything as obscene as shown in the last example, but the functionality is there should you need it.

With the sockaddr command you can experiment with getting the right template syntax with the eval sub-command, for instance:

$ sockaddr eval 'GetAllInterfaces | include "network" "10.99.0.0/24" | sort "size,address" | attr "address"'
10.99.0.5
$ sockaddr eval 'GetInterfaceIP "eth0"'
10.99.0.5

There is now a configurable template language for examples and docs) behind this that you can use to create a customizable heuristic that should allow you to get whatever it is that you need from your environment when using an immutable image (see hashicorp/go-sockaddr/template and cmd/sockaddr.