Docker create two bridges that corrupts my internet access

前端 未结 3 2334
难免孤独
难免孤独 2021-02-20 14:14

I\'m facing a pretty strange issue:

Here is my config:

  • docker 17-ce
  • ubuntu 16.04.

I work from two differents places with differ

相关标签:
3条回答
  • 2021-02-20 14:51

    In my case I would not apply Clement solution because I have the network conflict only with my dev pc while the container is delivered to many server which are not affected. This problem in my opinion should be resolved as suggested here. I tried this workaround:

    1. I stopped the container with "docker-compose down" which destroys the bridge

    2. Started the container while I'm on the "bad" network, so the container use another network

    Since then, if I restart the container on any network it doesn't try to use the "bad" one, normally get the last used one.

    0 讨论(0)
  • 2021-02-20 15:10

    You have to tell Docker to use a different subnet. Edit /etc/docker/daemon.json and use something like this:

    {
      "bip": "198.18.251.1/24",
      "default-address-pools": [
        {
          "base": "198.18.252.0/22",
          "size": 26
        }
      ]
    }
    

    Information is a bit hard to come by, but it looks like the bip option controls the IP and subnet assigned to the docker0 interface, while default-address-pools controls the addresses used for the br-* interfaces. You can omit bip in which case it will grab an allocation from the pool, and bip doesn't have to reside in the pool, as shown above.

    The size is how big of a subnet to allocate to each Docker network. For example if your base is a /24 and you also set size to 24, then you'll be able to create exactly one Docker network, and probably you'll only be able to run one Docker container. If you try to start another you'll get the message could not find an available, non-overlapping IPv4 address pool among the defaults to assign to the network, which means you've run out of IP addresses in the pool.

    In the above example I have allocated a /22 (1024 addresses) with each network/container taking a /26 (64 addresses) from that pool. 1024 ÷ 64 = 16, so you can run up to 16 Docker networks with this config (so max 16 containers running at the same time, or more if some of them share the same network). Since I rarely have more than two or three running containers at any one time this is fine for me.

    In my example I'm using part of the 198.18.0.0/15 subnet as listed in RFC 3330 (but fully documented in RFC 2544) which is reserved for performance testing. It is unlikely that these addresses will appear on the real Internet, and no professional network provider will use these subnets in their private network either, so in my opinion they are a good choice for use with Docker as conflicts are very unlikely. But technically this is a misuse of this IP range so just be aware of potential future conflicts if you also choose to use these subnets.

    The defaults listed in the documentation are:

    {
      "bip": "",
      "default-address-pools": [
        {"base": "172.80.0.0/16", "size": 24},
        {"base": "172.90.0.0/16", "size": 24}
      ]
    }
    

    As mentioned above, the default empty bip means it will just grab an allocation from the pool, like any other network/container will.

    0 讨论(0)
  • 2021-02-20 15:13

    I manage to solve this issue after reading this:

    https://success.docker.com/Architecture/Docker_Reference_Architecture%3A_Designing_Scalable%2C_Portable_Docker_Container_Networks

    The second docker bridge br-1a0208f108d9 was created by docker because i was using a docker-compose file which involve the creation of an other custom network.

    This network was using a fixed ip range:

    networks:
      my_network:
        driver: bridge
        ipam:
          config:
          - subnet: 172.16.0.0/16
            gateway: 172.16.0.1
    
    • At my home, the physical wifi network adapter was automaticly assigned using DHCP the address 192.168.0.X.
    • But in the other place, the same wifi adapter get the address 172.16.0.x

    Which collide with the custom docker network.

    The solution was simply to change the IP of the custom docker network.

    0 讨论(0)
提交回复
热议问题