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.

Sign up for GitHub

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

Jump to bottom

can't bind to all interfaces with some docker configurations? #13327

Closed
rmuir opened this issue Sep 3, 2015 · 3 comments
Closed

can't bind to all interfaces with some docker configurations? #13327

rmuir opened this issue Sep 3, 2015 · 3 comments
Labels
>bug v2.0.0-beta2

Comments

@rmuir
Copy link
Contributor

rmuir commented Sep 3, 2015

At least in one of our jenkins servers we have:

docker0
        inet 172.17.42.1 netmask:255.255.0.0 broadcast:0.0.0.0 scope:site
        hardware 56:84:7A:FE:97:99
        MULTICAST mtu:1500 index:3

Is this normal? The fact it has a broadcast address like that (which looks totally bogus), means that if the user configures 0.0.0.0, we will fail. I can fix the logic to deal with it in several ways (the interface is not marked up, we can not do the check explicitly for a wildcard address) but if anyone understands this I'd love to know why this docker interface looks like that.
@rmuir
Copy link
Contributor Author

rmuir commented Sep 3, 2015

Relevant jenkins fail: http://build-us-00.elastic.co/job/es_g1gc_master_metal/16773/

@drewr
Copy link
Contributor

drewr commented Sep 3, 2015

It's not only docker0, might be an issue with LXC in general. This is on Ubuntu 15.04 Vivid:

lxcbr0    Link encap:Ethernet  HWaddr 9e:ee:28:2e:2e:85
          inet addr:10.0.3.1  Bcast:0.0.0.0  Mask:255.255.255.0
          inet6 addr: fe80::9cee:28ff:fe2e:2e85/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:371713 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:29988240 (29.9 MB)

@rmuir
Copy link
Contributor Author

rmuir commented Sep 3, 2015

ok, its just intended as a safety check to prevent the user from making a mistake. I'll remove the broadcast check completely since apparently these containers don't understand how networking works.

rmuir added a commit to rmuir/elasticsearch that referenced this issue Sep 3, 2015
@rmuir
Remove broadcast address check.
529ad7f 
This was supposed to just help the user, in case they misconfigured something.
Broadcast is an ipv4 only thing, the only way you can really detect its a broadcast
address, is to look and see if an interface has that address as its broadcast address.

But we cannot trust that container interfaces won't have a crazy setup...

Closes elastic#13327
@rmuir rmuir mentioned this issue Sep 3, 2015
Merged
rmuir added a commit that referenced this issue Sep 3, 2015
@rmuir
Remove broadcast address check.
ffadada 
This was supposed to just help the user, in case they misconfigured something.
Broadcast is an ipv4 only thing, the only way you can really detect its a broadcast
address, is to look and see if an interface has that address as its broadcast address.

But we cannot trust that container interfaces won't have a crazy setup...

Closes #13327
rmuir added a commit that referenced this issue Sep 3, 2015
@rmuir
Remove broadcast address check.
e3f21a7 
This was supposed to just help the user, in case they misconfigured something.
Broadcast is an ipv4 only thing, the only way you can really detect its a broadcast
address, is to look and see if an interface has that address as its broadcast address.

But we cannot trust that container interfaces won't have a crazy setup...

Closes #13327
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
>bug v2.0.0-beta2
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@drewr @clintongormley @rmuir