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

How to control the IP subnet used by docker_gwbridge #19298

Closed
dvenza opened this Issue Jan 13, 2016 · 4 comments

Comments

Projects
None yet
4 participants
@dvenza

dvenza commented Jan 13, 2016

I looked in the documentation and set up a testbed to try and understand how the docker_gwbridge stuff works. Now I understand it, but there is a piece missing, especially in a multi-host setting.

I have my container on the overlay network with two interfaces, one private, one public.

  • I can control the IP address space of the private one, by explicitly passing an IP subnet when I create the network.
  • But the IP that actually matters to me, the one I can use to access the services run inside the container from outside, is taken from the docker_gwbridge bridge network, that uses an arbitrary IP range, potentially different across different docker engines.

Is there some option that I can pass to the docker daemon to tell it which IP subnet it should use for the docker_gwbridge network?

If I create by hand a docker_gwbridge network with the IP range I want, before creating any container, will it be picked up by docker?

I understand that I am supposed to use port forwarding, but let's say I have lots of "public" IP addresses and I don't want to pay the NAT performance penalty. What can I do?

@GordonTheTurtle

This comment has been minimized.

Show comment
Hide comment
@GordonTheTurtle

GordonTheTurtle Jan 13, 2016

If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.

If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.

For more information about reporting issues, see CONTRIBUTING.md.

You don't have to include this information if this is a feature request

(This is an automated, informational response)


BUG REPORT INFORMATION

Use the commands below to provide key information from your environment:

docker version:
docker info:

Provide additional environment details (AWS, VirtualBox, physical, etc.):

List the steps to reproduce the issue:
1.
2.
3.

Describe the results you received:

Describe the results you expected:

Provide additional info you think is important:

----------END REPORT ---------

#ENEEDMOREINFO

If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.

If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.

For more information about reporting issues, see CONTRIBUTING.md.

You don't have to include this information if this is a feature request

(This is an automated, informational response)


BUG REPORT INFORMATION

Use the commands below to provide key information from your environment:

docker version:
docker info:

Provide additional environment details (AWS, VirtualBox, physical, etc.):

List the steps to reproduce the issue:
1.
2.
3.

Describe the results you received:

Describe the results you expected:

Provide additional info you think is important:

----------END REPORT ---------

#ENEEDMOREINFO

@mavenugo

This comment has been minimized.

Show comment
Hide comment
@mavenugo

mavenugo Jan 13, 2016

Contributor

If I create by hand a docker_gwbridge network with the IP range I want, before creating any container, will it be picked up by docker?

Yes It will be picked up. But, please note that we take special precautions to this network when we create this network to be used for overlay network. docker_gwbridge network is shared across all the containers running across multiple overlay networks. Because of that, we configure ICC=false in the docker_gwbridge in order to prevent the containers connected to the docker_gwbridge to communicate with each other via this network. PTAL : https://github.com/docker/libnetwork/blob/master/default_gateway_linux.go#L15

If you have to create it manually it will be docker network create --opts com.docker.network.bridge.enable_icc=false --subnet={your prefered subnet} docker_gwbridge.

But please note that, though this will work in the current overlay driver implementation, there is no guarantee that we will continue to use docker_gwbridge as a way to provide external connectivity.

Contributor

mavenugo commented Jan 13, 2016

If I create by hand a docker_gwbridge network with the IP range I want, before creating any container, will it be picked up by docker?

Yes It will be picked up. But, please note that we take special precautions to this network when we create this network to be used for overlay network. docker_gwbridge network is shared across all the containers running across multiple overlay networks. Because of that, we configure ICC=false in the docker_gwbridge in order to prevent the containers connected to the docker_gwbridge to communicate with each other via this network. PTAL : https://github.com/docker/libnetwork/blob/master/default_gateway_linux.go#L15

If you have to create it manually it will be docker network create --opts com.docker.network.bridge.enable_icc=false --subnet={your prefered subnet} docker_gwbridge.

But please note that, though this will work in the current overlay driver implementation, there is no guarantee that we will continue to use docker_gwbridge as a way to provide external connectivity.

@dvenza

This comment has been minimized.

Show comment
Hide comment
@dvenza

dvenza Jan 14, 2016

Thank you for the clarification. I will keep using the docker0 bridge for now and keep an eye on how overlay networks will evolve in 1.10.

dvenza commented Jan 14, 2016

Thank you for the clarification. I will keep using the docker0 bridge for now and keep an eye on how overlay networks will evolve in 1.10.

@igrcic

This comment has been minimized.

Show comment
Hide comment
@igrcic

igrcic Jun 8, 2016

Contributor

Hi @mavenugo

just a tiny fix, it should be --opt

docker network create --opt com.docker.network.bridge.enable_icc=false --subnet=192.168.2.0/24 docker_gwbridge

Additionally one can define--internal if no internet connectivity is required.

A question: will this network always persist on docker restarts? Can one save this somehow in docker daemon options?

Thank you,
Ivan

Contributor

igrcic commented Jun 8, 2016

Hi @mavenugo

just a tiny fix, it should be --opt

docker network create --opt com.docker.network.bridge.enable_icc=false --subnet=192.168.2.0/24 docker_gwbridge

Additionally one can define--internal if no internet connectivity is required.

A question: will this network always persist on docker restarts? Can one save this somehow in docker daemon options?

Thank you,
Ivan

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment