moby: Missing Gateway field in `bridge` network inspect

First time daemon is booted (no docker0 bridge present, no or empty /var/lib/docker/network/files/local-kv.db file), IPAM.Config structure in network inspect output will not contain the Gateway field

$ docker network inspect bridge
[
    {
        "Name": "bridge",
        "Id": "2b5cc5f97b6de6a5e0533b1e2d5bec6284d900a9a82632ce782320a19db8b9e0",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.17.0.0/16"
                }
            ]
        },

Verified problem exists in 1.11.2, 1.12.0 and in current master (1.13.0).

Given the IPAM.Config filed currently used to carry both configuration and operational data, the gateway address should always be there.

Note: A daemon reload will fix the issue

About this issue

Original URL
State: open
Created 8 years ago
Reactions: 3
Comments: 16 (4 by maintainers)

Links to this issue

webgme-docker-worker-manager - npm

Commits related to this issue

[FIX] runbot: find docker gateway for build smtp host When a build is running, the stmp is the localhost. Since Docker builds, the localhost is the container which does not catch port 25 smtp. Mails ... — committed to odoo/runbot by d-fence 5 years ago
[FIX] runbot: find docker gateway for build smtp host When a build is running, the stmp is the localhost. Since Docker builds, the localhost is the container which does not catch port 25 smtp. Mails ... — committed to odoo/runbot by d-fence 5 years ago
workaround for https://github.com/moby/moby/issues/26799 — committed to overnode-org/overnode by avkonst 4 years ago
[calc] work around the docker bridge network issue (#4433) What is the motivation for this PR? There is a docker bridge network issue that would randomly cause "docker inspect bridge" to not show 'G... — committed to sonic-net/sonic-mgmt by yxieca 3 years ago
[calc] work around the docker bridge network issue (#4433) What is the motivation for this PR? There is a docker bridge network issue that would randomly cause "docker inspect bridge" to not show 'Ga... — committed to 119064273/sonic-mgmt by yxieca 3 years ago

Most upvoted comments

I have seen this now with the latest docker. I am surprised it is nearly 4 years old issue.

avkonst on Jul 8, 2020

The same issue on Ubuntu 16.04 LTS with Docker version 18.06.1-ce, build e68fc7a.

It’s fixed after run commands below:

sudo systemctl daemon-reload
sudo systemctl stop docker
sudo systemctl start docker

newnewcoder on Sep 14, 2018

This issue is still present in Docker 19.03.2 on Linux. Is there any way to solve this without restarting the service on first run?

hank-scorpio on May 27, 2020

have the same issue

Client: Docker Engine - Community
 Version:           20.10.7
 API version:       1.41
 Go version:        go1.13.15
 Git commit:        f0df350
 Built:             Wed Jun  2 11:58:10 2021
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.7
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       b0f5bc3
  Built:            Wed Jun  2 11:56:35 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.6
  GitCommit:        d71fcd7d8303cbf684402823e425e9dd2e99285d
 runc:
  Version:          1.0.0-rc95
  GitCommit:        b9ee9c6314599f1b4a7f497e1f1f856fe433d3b7
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker network inspect bridge
[
    {
        "Name": "bridge",
        "Id": "d0f87f91f1853bb16f82764665683529e27d831599a56e1e19302a6f06a615dc",
        "Created": "2021-07-10T23:22:35.604721866+08:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.80.0.0/24"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            
        },
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"
        },
        "Labels": {}
    }
]

llitfkitfk on Jul 11, 2021

Getting this on Debian Buster,

docker version Client: Docker Engine - Community Version: 19.03.8 API version: 1.40 Go version: go1.12.17 Git commit: afacb8b7f0 Built: Wed Mar 11 01:25:56 2020 OS/Arch: linux/amd64 Experimental: false

Server: Docker Engine - Community Engine: Version: 19.03.8 API version: 1.40 (minimum version 1.12) Go version: go1.12.17 Git commit: afacb8b7f0 Built: Wed Mar 11 01:24:28 2020 OS/Arch: linux/amd64 Experimental: false containerd: Version: 1.2.13 GitCommit: 7ad184331fa3e55e52b890ea95e65ba581ae3429 runc: Version: 1.0.0-rc10 GitCommit: dc9208a3303feef5b3839f4323d9beb36df0a9dd docker-init: Version: 0.18.0 GitCommit: fec3683

After investiguig a little bit, its looks like everything is registered properly, I can look in the file /var/lib/docker/network/file/local-kv.db and I see a json with looks like the expected value from the docker network inspect. Are you just missing a lookup in the database ?

hommeabeil on May 29, 2020

I am seeing this same issue in Docker in Docker. TestContainers depends on their being a gateway defined, and can’t route traffic correctly when it’s missing. I have to relaunch the docker daemon before running my Testcontainer tests.

lxdraw on Apr 16, 2020

Issue is there in 1.11.2 as well, not a regression. Given it won’t be seen after a daemon reload, it might be the reason why it went unnoticed for so long.

aboch on Sep 21, 2016