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 private IP address found error #385

Closed
subnetmarco opened this issue Mar 30, 2016 · 12 comments
Closed

No private IP address found error #385

subnetmarco opened this issue Mar 30, 2016 · 12 comments

Comments

@subnetmarco
Copy link

Hello, I am one of the maintainers of Kong and we have a user reporting the following error. I thought you may have an idea of what's going on here.

Basically when Kong starts we also start a Serf agent, since Serf provides the backbone of our cluster management. The ifconfig of the machine is:

$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0d:3a:a0:e7:06  
          inet addr:100.75.34.83  Bcast:100.75.35.255  Mask:255.255.254.0
          inet6 addr: fe80::20d:3aff:fea0:e706/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1177618 errors:0 dropped:1 overruns:0 frame:0
          TX packets:1466399 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:406062947 (406.0 MB)  TX bytes:263152078 (263.1 MB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:4342788 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4342788 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:224875180 (224.8 MB)  TX bytes:224875180 (224.8 MB)

And directly running serf agent on the machine returns the following output:

$ serf agent
==> Starting Serf agent...
==> Failed to start the Serf agent: Error creating Serf: Failed to create memberlist: No private IP     address found, and explicit IP not provided

Any tips on what may be the issue here? I would assume 100.75.34.83 would be a good pick for Serf, but maybe I am wrong.

@subnetmarco
Copy link
Author

I confirm that explicitly instructing Serf to bind on 100.75.34.83:7946 works. Still can't figure out why it can't automatically.

@slackpad
Copy link
Contributor

Hi @thefosk that's not one of the address ranges that Serf considers private. You can see the list of supported blocks here:

https://github.com/hashicorp/memberlist/blob/master/util.go#L25-L33

If it's not on that list then Serf will require you to specify an address explicitly to try to avoid exposing itself on a public interface. I did some digging and couldn't find anything pointing to 100.75 being part of a private range of addresses. If that doesn't seem right, please kick this back open and we can take a look.

@binhnq94
Copy link

i have same problem 💃

@laura-herrera
Copy link

Hi guys,

I am having the same problem, trying to bind to 100.65.90.183
any ideas as to how can i pass this onto serf when trying to start kong?

Thank you!

@subnetmarco
Copy link
Author

@laura-herrera have you tried to manually set the cluster_listen (and cluster_advertise property if needed)?

@laura-herrera
Copy link

Hi @thefosk , it seems that by having both of those properties kong wasn't starting correctly.
I removed cluster_listen and only setup cluster_advertise, and it all worked ok! thank you!

@HenryChelsea
Copy link

@thefosk If I need to bind private ip, I need to set cluster_advertise? Why Serf automatically get th e private ip and register in cluster?

@subnetmarco
Copy link
Author

Please ask Kong related questions on https://github.com/Mashape/kong - you will need to explicitly set cluster_advertise in your case. It really depends on your network settings.

@HenryChelsea
Copy link

@thefosk Got it! Thanks for your help.

@tarunsaxenattn
Copy link

The below YAML worked for me. My DNS RESOLVER Is :- 172.0.0.10
I have assigned a advertise IP to Kong :- 172.244.3.10:7946 . Before that I was facing the same problem.

apiVersion: extensions/v1beta1

kind: Deployment
metadata:
name: kong
namespace: qa
spec:
replicas: 1
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
type: RollingUpdate
template:
metadata:
labels:
run: kong
spec:
containers:

  • name: kong
    image: kong
    imagePullPolicy: Always
    ports:
  • containerPort: 8000
    protocol: TCP
  • containerPort: 8443
    protocol: TCP
  • containerPort: 8001
    protocol: TCP
  • containerPort: 7946
    protocol: UDP
  • containerPort: 7946
    protocol: TCP
    env:
  • name: KONG_DATABASE
    value: postgres
  • name: KONG_PG_HOST
    value: xxxxxx
  • name: KONG_PG_USER
    value: kong
  • name: KONG_PG_PASSWORD
    value: password
  • name: KONG_PG_DATABASE
    value: kong
  • name: KONG_DNS_RESOLVER
    value: 172.0.0.10
  • name: KONG_DNSMASQ
    value: "off"
  • name: KONG_CLUSTER_ADVERTISE
    value: 172.244.3.10:7946
    resources:
    limits:
    memory: 1200Mi
    requests:
    memory: 1100Mi

apiVersion: v1
kind: Service
metadata:
name: svc-kong
namespace: qa
annotations:
service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:us-east-1:xxxxxxxx:certificate/xxxxxxxxxxxxxxxxxxx
service.beta.kubernetes.io/aws-load-balancer-ssl-ports: https
spec:
ports:

  • name: "www"
    port: 8001
    targetPort: 8001

  • name: "www1"
    port: 80
    targetPort: 8000

  • name: "https"
    port: 443
    targetPort: 8443

  • name: "www2"

port: 7946

targetPort: 7946

selector:
run: kong
type: LoadBalancer

@olivierdeckers
Copy link

olivierdeckers commented Feb 8, 2017

According to kubernetes/kops#1458 and https://tools.ietf.org/html/rfc6598#section-7, the 100.64.0.0/10 range is a shared address range that is similar to the private address space (not globally routable). It seems to me serf can safely consider this range to be private as well.

@olivierdeckers
Copy link

Regarding my last commit: This has been fixed in serf 0.8.0, the 100.64.0.0/10 range is now also private as far as serf is concerned

h4ck3rk3y added a commit to kurtosis-tech/kurtosis that referenced this issue Apr 24, 2023
…096 (#545)

## Description:
Some services seem to follow RFC 6980; which requires certain flags to
be passed to those services to allow non private ip addresses (as
defined by the RFC). While working with the weaviate example I learned
that docker has no pain composing

```
version: '3.4'
services:
  weaviate:
    image: semitechnologies/weaviate:1.18.3
    ports:
    - 8080:8080
    restart: on-failure:0
    environment:
      QUERY_DEFAULTS_LIMIT: 25
      AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED: 'true'
      PERSISTENCE_DATA_PATH: '/var/lib/weaviate'
      DEFAULT_VECTORIZER_MODULE: 'none'
      CLUSTER_HOSTNAME: 'node1'
```
While with Kurtosis you can't run (even though the default inspect
output says RUNNING if you run it again you can see the service STOPPED)

```
WEAVIATE_IMAGE="semitechnologies/weaviate:1.18.3"

WEAVIATE_PORT = 8080
WEAVIATE_PORT_ID = "http"

def run(plan, args):

    plan.add_service(
        name = "weaviate",
        config = ServiceConfig(
            image = WEAVIATE_IMAGE,
            ports = {
                WEAVIATE_PORT_ID: PortSpec(number = WEAVIATE_PORT, transport_protocol = "TCP")
            },
            env_vars = {
                "QUERY_DEFAULTS_LIMIT": str(25),
                "AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED": 'true',
                "PERSISTENCE_DATA_PATH": '/var/lib/weaviate',
                "DEFAULT_VECTORIZER_MODULE": 'none',
                "CLUSTER_HOSTNAME": 'node1'
            },
        )
    )
```

This is because WEAVIATE uses hashicorp/memberlist which uses serf
underneath
hashicorp/serf#385 (comment)
underneath that disallows any non private ip addresses. Similar in
Grafana grafana/grafana#62453

## Is this change user facing?
NO
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

7 participants