search

docker / for-linux

Docker Engine for Linux
https://docs.docker.com/engine/installation/
756 stars 85 forks source link

create network and ip allocation issues - This has multiple issues combined into one report #170

Open kaithar opened 6 years ago

kaithar commented 6 years ago

Expected behavior

docker network create --attachable \
           $RANGE_AND_SUBNET \
           --gateway=10.243.3.1 \
           -o "com.docker.network.bridge.name"="zt_br0" \
           -o "com.docker.network.bridge.enable_ip_masquerade"="true" \
           -o "com.docker.network.bridge.enable_icc"="true" \
           -o "com.docker.network.bridge.host_binding_ipv4"="0.0.0.0" zt
# I expect the bridge to be on 10.243.3.1
docker run --rm -it --network="zt" busybox
# I would expect to now be in a container with, maybe, an ip of 10.243.3.2 with a netmask of /16

Actual behavior

Using --ip-range=10.243.3.1/24 --subnet=10.243.3.1/16 gets me the /16 netmask (correct) but my first container is being allocated 10.243.3.0 as an ip (wrong). Using --ip-range=10.243.3.1/16 --subnet=10.243.3.1/24 I get an allocation of 10.243.3.2 (correct) but netmasks of /24 (wrong) Just for larks I tried making --ip-range=10.243.3.1/16 --subnet=10.243.3.1/16 but now I'm getting 10.243.0.1 as my first allocation (wrong)

What should the correct invocation be? The documentation isn't clear on the right way to tell docker to use part of a larger reachable range. I'm not sure why it even thinks a .0 address is ok to hand out either. I admit I could be being dense, but a lot of googling and experimenting with options has hurt my head ;)

Output of docker version:

Client:
 Version:      17.05.0-ce
 API version:  1.29
 Go version:   go1.7.5
 Git commit:   89658be
 Built:        Thu May  4 22:06:06 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.05.0-ce
 API version:  1.29 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   89658be
 Built:        Thu May  4 22:06:06 2017
 OS/Arch:      linux/amd64
 Experimental: false
selansen commented 6 years ago

I will take a look at this one

selansen commented 6 years ago

I am using below docker version

ocker@ELANGO-CE-ubuntu-1:~$ docker version Client: Version: 17.09.0-ce API version: 1.32 Go version: go1.8.3 Git commit: afdb6d4 Built: Tue Sep 26 22:42:18 2017 OS/Arch: linux/amd64

Server: Version: 17.09.0-ce API version: 1.32 (minimum version 1.12) Go version: go1.8.3 Git commit: afdb6d4 Built: Tue Sep 26 22:40:56 2017 OS/Arch: linux/amd64 Experimental: false

Case 1

docker network create --attachable --ip-range 10.243.3.1/24 --subnet=10.243.3.1/16 test_nw container gets correct IP

"Containers": { "7a1ddeb92dcf060e580d10825fb84aae3bca939a631a0c91d5873108685a0677": { "Name": "test1", "EndpointID": "b939689d83155d9f314a4c4c4f040b498448d38754c06c509f7becfc2de748eb", "MacAddress": "02:42:0a:f3:03:01", "IPv4Address": "10.243.3.1/16", "IPv6Address": "" }

Case 2

docker network create --attachable --ip-range 10.243.3.1/16 --subnet=10.243.3.1/24 test_nw

"Containers": { "e76936c40d1b86f7ad6cb9311f4e5d6cc5198ca0625da562e2871f71e6b37e71": { "Name": "test1", "EndpointID": "bdc67d67c15a6b85d84a4cb1358ec99b81f9b10bf15354653008c23ffbbb1aaa", "MacAddress": "02:42:0a:f3:03:02", "IPv4Address": "10.243.3.2/24", "IPv6Address": "" }

This doesnt seem like an issue. It would not make sense to assign IP address larger than the subnet prefix. We don't proxy ARP for bridges.

Case 3

docker network create --attachable --ip-range 10.243.3.1/16 --subnet=10.243.3.1/16 test_nw "Containers": { "a2703d3f2d2803269c7dc14c7c8c17098409f2af5be3c2513d6183d157208f31": { "Name": "test1", "EndpointID": "1769360e70d45f7186b4846d69e760864fdff14ceaf45a259dba10b16fa4ac65", "MacAddress": "02:42:0a:f3:00:02", "IPv4Address": "10.243.0.2/16", "IPv6Address": "" }

This is also not an issue. subnet is 1/16 and range is also /16. So we allocate /16 IP address.

Case 1 also doesn't seem to be issue on my setup . Could you pls upgrade your CE version and test it?

kaithar commented 6 years ago

ok...

# docker version
Client:
 Version:      17.11.0-ce
 API version:  1.34
 Go version:   go1.9.2
 Git commit:   1caf76c
 Built:        Fri Dec  1 20:53:49 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.11.0-ce
 API version:  1.34 (minimum version 1.12)
 Go version:   go1.9.2
 Git commit:   1caf76c
 Built:        Fri Dec  1 20:52:37 2017
 OS/Arch:      linux/amd64
 Experimental: false

# docker network create --attachable --ip-range="10.243.1.1/24" --subnet="10.243.1.1/16" --gateway=10.243.1.1 -o "com.docker.network.bridge.name"="zt_br0" -o "com.docker.network.bridge.enable_ip_masquerade"="true" -o "com.docker.network.bridge.enable_icc"="true" -o "com.docker.network.bridge.host_binding_ipv4"="0.0.0.0" zerotier

8598: zt_br0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:15:b5:a0:70 brd ff:ff:ff:ff:ff:ff
    inet 10.243.1.1/16 scope global zt_br0
       valid_lft forever preferred_lft forever

 # docker run --rm -it --network="zerotier" busybox
/ # ifconfig
eth0      Link encap:Ethernet  HWaddr 02:42:0A:F3:01:00
          inet addr:10.243.1.0  Bcast:0.0.0.0  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:508 (508.0 B)  TX bytes:0 (0.0 B)

If I take out the --gateway param I get 10.243.1.0 assigned to the bridge instead.

selansen commented 6 years ago

I am not seeing anywhere restricting 10.243.1.0 IP for network device. Do you see any ping issue due to this IP address allocation ?

kaithar commented 6 years ago

considers it's normally a bad idea to use .0 addresses, although on a range more than /24 it's technically valid. There's probably still quite a bit of software and hardware that will bork because it's a class-C network address, it's still unreliable enough and uncommon enough that it's considered bad practice to use them. Although, technically, if the range is being provided as a cidr then strictly speaking it probably shouldn't be allowed. Sure, we're telling it that it's in a /16 range but we're saying the valid addresses to assign are the /24 so I'm of the opinion that it would be expected that the used range would be .1-.254.

Practically speaking, it looks like ping is working but it feels incredibly wrong. Maybe just document that subnet param uses the full cidr so people expect it?