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

Network interface names containing colons can't be bound to #17473

Closed
karlra opened this issue Apr 1, 2016 · 2 comments
Closed

Network interface names containing colons can't be bound to #17473

karlra opened this issue Apr 1, 2016 · 2 comments
Labels
discuss :Distributed/Network Http and internode communication implementations

Comments

@karlra
Copy link

karlra commented Apr 1, 2016

Elasticsearch version:
2.3.0

JVM version:
java version "1.8.0_77"
Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)

OS version:
Ubuntu 14.04:4

Steps to reproduce:

  1. Add a network interface that contains a colon
  2. Add this interface to elasticsearch.yml as the network host or publish host like so: network.host: _bond0:0_
  3. Restart elasticsearch

Provide logs (if relevant):

[2016-04-01 11:59:04,363][INFO ][node                     ] [master_1] initialized
[2016-04-01 11:59:04,363][INFO ][node                     ] [master_1] starting ...
[2016-04-01 11:59:04,466][ERROR][bootstrap                ] [master_1] Exception
java.lang.IllegalArgumentException: No interface named 'bond0:0' found, got [name:lo (lo), name:bond0 (bond0), name:bond0:0 (bond0:0)]
        at org.elasticsearch.common.network.NetworkUtils.getAddressesForInterface(NetworkUtils.java:232)
        at org.elasticsearch.common.network.NetworkService.resolveInternal(NetworkService.java:262)
        at org.elasticsearch.common.network.NetworkService.resolveInetAddresses(NetworkService.java:209)
        at org.elasticsearch.common.network.NetworkService.resolveBindHostAddresses(NetworkService.java:122)
        at org.elasticsearch.transport.netty.NettyTransport.bindServerBootstrap(NettyTransport.java:424)
        at org.elasticsearch.transport.netty.NettyTransport.doStart(NettyTransport.java:321)
        at org.elasticsearch.common.component.AbstractLifecycleComponent.start(AbstractLifecycleComponent.java:68)
        at org.elasticsearch.transport.TransportService.doStart(TransportService.java:170)
        at org.elasticsearch.common.component.AbstractLifecycleComponent.start(AbstractLifecycleComponent.java:68)
        at org.elasticsearch.node.Node.start(Node.java:252)
        at org.elasticsearch.bootstrap.Bootstrap.start(Bootstrap.java:221)
        at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:287)
        at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:35)
[2016-04-01 11:59:04,486][INFO ][node                     ] [master_1] stopping ...
[2016-04-01 11:59:04,488][INFO ][node                     ] [master_1] stopped
@clintongormley clintongormley added discuss :Distributed/Network Http and internode communication implementations labels Apr 4, 2016
@daschl
Copy link
Contributor

daschl commented Jul 20, 2016 •
edited
Loading

I was curious so I dug in a bit. The problem is not the colon naming but rather that this is a virtual interface. NetworkUtils.getAddressesForInterface uses NetworkInterface.getByName of the JDK which returns null for virtual interfaces, even if the "name" is right.

For your case NetworkInterface.getByName("bond0").getSubInterfaces().nextElement(); would get you the right element.

Now the thing is, its quite unpractical to split it up by colon itself and then match the subinterfaces name, but I think a compromise would be to just iterate over the result from NetworkService .getInterfaces and get the one where the name matches - because this includes all the physical and virtual interfaces (what the JDK refers to as sub interfaces).

If that makes sense I can get a PR up :)

@jasontedor wdyt?

daschl added a commit to daschl/elasticsearch that referenced this issue Jul 21, 2016
@daschl
Network: Allow to listen on virtual interfaces.
a20b531 
Previously when trying to listen on virtual interfaces during
bootstrap the application would stop working - the interface
couldn't be found by the NetworkUtils class.

The NetworkUtils utilize the underlying JDK NetworkInterface
class which, when asked to lookup by name only takes physical
interfaces into account, failing at virtual (or subinterfaces)
ones (returning null).

Note that when interating over all interfaces, both physical and
virtual ones are taken into account.

This changeset asks for all known interfaces, iterates over them
and matches on the given name as part of the loop, allowing it
to catch both physical and virtual interfaces.

As a result, elasticsearch can now also serve on virtual
interfaces.

A test case has been added which at least makes sure that all
iterable interfaces can be found by their respective name. (It's
not easily possible in a unit test to "fake" virtual interfaces).

Fixes elastic#17473
@daschl daschl mentioned this issue Jul 21, 2016
Merged
@jasontedor jasontedor reopened this Jul 22, 2016
@daschl
Copy link
Contributor

daschl commented Jul 22, 2016

I'll rework the test case and resubmit.

daschl added a commit to daschl/elasticsearch that referenced this issue Jul 25, 2016
@daschl
Network: Allow to listen on virtual interfaces.
3a89a3e 
Previously when trying to listen on virtual interfaces during
bootstrap the application would stop working - the interface
couldn't be found by the NetworkUtils class.

The NetworkUtils utilize the underlying JDK NetworkInterface
class which, when asked to lookup by name only takes physical
interfaces into account, failing at virtual (or subinterfaces)
ones (returning null).

Note that when interating over all interfaces, both physical and
virtual ones are taken into account.

This changeset asks for all known interfaces, iterates over them
and matches on the given name as part of the loop, allowing it
to catch both physical and virtual interfaces.

As a result, elasticsearch can now also serve on virtual
interfaces.

A test case has been added which  makes sure that all
iterable interfaces can be found by their respective name.

Note that this PR is a second iteration over the previously
merged but later reverted elastic#19537 because it causes tests
to fail when interfaces are down. The test has been modified
to take this into account now.

Closes elastic#17473
Relates elastic#19537
@daschl daschl mentioned this issue Jul 25, 2016
Closed
spinscale pushed a commit to spinscale/elasticsearch that referenced this issue Sep 13, 2016
@daschl @spinscale
Network: Allow to listen on virtual interfaces.
041e811 
Previously when trying to listen on virtual interfaces during
bootstrap the application would stop working - the interface
couldn't be found by the NetworkUtils class.

The NetworkUtils utilize the underlying JDK NetworkInterface
class which, when asked to lookup by name only takes physical
interfaces into account, failing at virtual (or subinterfaces)
ones (returning null).

Note that when interating over all interfaces, both physical and
virtual ones are taken into account.

This changeset asks for all known interfaces, iterates over them
and matches on the given name as part of the loop, allowing it
to catch both physical and virtual interfaces.

As a result, elasticsearch can now also serve on virtual
interfaces.

A test case has been added which  makes sure that all
iterable interfaces can be found by their respective name.

Note that this PR is a second iteration over the previously
merged but later reverted elastic#19537 because it causes tests
to fail when interfaces are down. The test has been modified
to take this into account now.

Closes elastic#17473
Closes elastic#19568
Relates elastic#19537
spinscale pushed a commit that referenced this issue Sep 13, 2016
@daschl @spinscale
Network: Allow to listen on virtual interfaces.
01dbf4b 
Previously when trying to listen on virtual interfaces during
bootstrap the application would stop working - the interface
couldn't be found by the NetworkUtils class.

The NetworkUtils utilize the underlying JDK NetworkInterface
class which, when asked to lookup by name only takes physical
interfaces into account, failing at virtual (or subinterfaces)
ones (returning null).

Note that when interating over all interfaces, both physical and
virtual ones are taken into account.

This changeset asks for all known interfaces, iterates over them
and matches on the given name as part of the loop, allowing it
to catch both physical and virtual interfaces.

As a result, elasticsearch can now also serve on virtual
interfaces.

A test case has been added which  makes sure that all
iterable interfaces can be found by their respective name.

Note that this PR is a second iteration over the previously
merged but later reverted #19537 because it causes tests
to fail when interfaces are down. The test has been modified
to take this into account now.

Closes #17473
Closes #19568
Relates #19537
spinscale pushed a commit that referenced this issue Sep 13, 2016
@daschl @spinscale
Network: Allow to listen on virtual interfaces.
556d077 
Previously when trying to listen on virtual interfaces during
bootstrap the application would stop working - the interface
couldn't be found by the NetworkUtils class.

The NetworkUtils utilize the underlying JDK NetworkInterface
class which, when asked to lookup by name only takes physical
interfaces into account, failing at virtual (or subinterfaces)
ones (returning null).

Note that when interating over all interfaces, both physical and
virtual ones are taken into account.

This changeset asks for all known interfaces, iterates over them
and matches on the given name as part of the loop, allowing it
to catch both physical and virtual interfaces.

As a result, elasticsearch can now also serve on virtual
interfaces.

A test case has been added which  makes sure that all
iterable interfaces can be found by their respective name.

Note that this PR is a second iteration over the previously
merged but later reverted #19537 because it causes tests
to fail when interfaces are down. The test has been modified
to take this into account now.

Closes #17473
Closes #19568
Relates #19537
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
discuss :Distributed/Network Http and internode communication implementations
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@daschl @clintongormley @jasontedor @karlra