What is the "Docker Subnet" used for?

Question

There is an option in docker-desktop that allow to change the "Docker subnet". And I don't see this default subnet 192.168.65.0/28 being used anywhere.

I tried to docker network inspect on every Docker internal network, checked the docker-desktop WSL2 distro and my Windows host for routes or IPs but I don't see that default subnet being used anywhere (even when setting up a custom one).

This does not change the subnet used in docker network inspect bridge or any other one.

I'm struggling to find any documentation on what it is and/or what it used for.

Veal

Answer 1

For the most part it is an internal implementation detail that you don't need to worry about.

The only time you actually need to change this value is if your host network has the same address. In that case you can change this to anything that doesn't conflict. If your host network happens to be, for example, 192.168.65.0/24 then you could change the Docker network to 192.168.66.0/24 (or /28) and it'd work fine.

Internally containers have individual IP addresses, and this is the default subnet they get assigned from. If you docker network create a network or you're using Docker Compose, a new subnet will be allocated. This is almost entirely an implementation detail and you never need to know these addresses: from outside Docker you can't reach these addresses (*), and inside Docker it provides a DNS system so you can use container names as host names.

More specifically, if you

docker run --rm busybox ifconfig

you will see an address from this subnet.

(*) ...except in the one very specific case of connecting from the console of the native-Linux host that's actually running the containers; but never from other hosts, or if you're using Docker Toolbox or Docker Desktop.

Rector

I ran your command and the container doesn't have an IP in that default subnet. And I just noticed something even stranger, the DNS server IP I've setup isn't the same in the container but is instead an IP that belong on the default subnet! See here i.imgur.com/jYHFUQ4.png Using docker network create without specifying a subnet (without --subnet) does not use the default subnet either. See: i.imgur.com/BZxHFmx.png – Veal

This question is getting a lot of views but two years later I still don't find this to be a complete enough answer. See my previous comment. – Veal

This is so strange... It seems a simple question, but no one can help answer it. – Fraternize

Agreed, time for a bounty maybe – Veal

Answer 2

In Docker Desktop (for either Windows or macOS), containers do not run directly on the system kernel, they run inside a Linux VM (in the case of macOS) or inside a container within Hyper-V (in the case of WSL 2 on Windows).

This subnet is the network used for the Docker daemon environment running in the VM or Hyper-V container.

On macOS, you can enter the Docker VM and look around, using the below command.

docker run -it --rm --privileged --pid=host justincormack/nsenter1

(I'm not sure whether this command works on Windows, and I don't have a system to test it on, but you could try it and see.)

Inside the Docker VM, you can look at the network config and you will find this subnet there.

/ # ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 02:50:00:00:00:01 brd ff:ff:ff:ff:ff:ff
    inet 192.168.65.3/24 brd 192.168.65.255 scope global dynamic noprefixroute eth0
       valid_lft 7019sec preferred_lft 5579sec
    inet6 fe80::50:ff:fe00:1/64 scope link
       valid_lft forever preferred_lft forever

/ # ip route show | grep 192.168.65
default via 192.168.65.1 dev eth0 proto dhcp src 192.168.65.3 metric 202
192.168.65.0/24 dev eth0 proto dhcp scope link src 192.168.65.3 metric 202
192.168.65.5 dev services1 proto kernel scope link src 192.168.65.4

/ # cat /etc/resolv.conf
# DNS requests are forwarded to the host. DHCP DNS options are ignored.
nameserver 192.168.65.5

The containers that you lauch from this environment don't use this network, though. They are also addressed from an RFC 1918 network, but a different one, as seen below:

15: eth0@if16: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever

/ # ip route
default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 scope link  src 172.17.0.2

Here you can see that 172.17.0.0/16 is in use. That's part of the larger 172.16.0.0/12 allocation found in RFC 1918.

If the subnet you're asking about were used for containers, you would run out of addresses fairly quickly, because a /28 network only has 14 usable addresses (13, if you realize the Docker VM uses one for itself). Whereas the /16 network for containers has 65,534 usable addresses in it.

Ligule

Answer 3

Docker Desktop for Linux user manual

Docker Desktop uses a private IPv4 network for internal services such as a DNS server and an HTTP proxy. In case the choice of subnet clashes with something in your environment, specify a custom subnet using the Network setting.

Docker Desktop for Windows user manual

You can configure Docker Desktop networking to work on a virtual private network (VPN). Specify a network address translation (NAT) prefix and subnet mask to enable Internet connectivity.

Docker Desktop\Networking features in Docker Desktop for Windows

Understanding Docker Networks and resolving conflict with Docker Subnet IP Range!

Here you can find a sample case that a network conflict and NoRouteToHostException error in connecting to an external resource with the IP in the range of 172.17.. is resolved by changing Docker Subnet IP Range.

Note: Every container is attached to Docker Bridge Network by default and gets an IP or range 172.17..

Changing containers default Bridge IP Range to 172.26.. solved problem.

Hypnotherapy

Answer 4

I would like to add to Dan Lowe's answer, that on MacOS, when you run a container with host network, it will share the same IP space with the docker VM (docker daemon, docker desktop,...).
Try this command to spin up a test container:

docker run --network=host -itd --name=container3 busybox

Then, execute this command to get the IP of the container:

docker exec -it container3 ip addr show dev eth0

The result looks like this:

8: eth0@docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue 
    link/ether 12:e9:7c:d1:13:54 brd ff:ff:ff:ff:ff:ff
    inet 192.168.65.4 peer 192.168.65.5/32 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::10e9:7cff:fed1:1354/64 scope link 
       valid_lft forever preferred_lft forever

The IP is 192.168.65.4, it belongs to the subnet 192.168.65.0/28.

Thibodeau