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
Create docker bridge on existing system bridge. #2310
Comments
I'd like to add a use case to the discussion, in case it helps emphasize why this should be supported by docker. I have a pre-existing bridge named "vlan1". This is configured in the host system with a VPN that links it with other bridges on other hosts: 10.8.2.0/24 exists on the local host and can ping to 10.8.3.0/24 on a remote host through an IPSec connection. It is also bridged with a physical ethernet port on a protected LAN, so there is already a dnsmasq running to be able to serve IP addresses to virtual machines on this network. The only "normal" way to integrate Docker into this network is to run the container on a different network and then expose ports onto 10.8.2.1:xxx as if they were normal programs running on the host. This makes that service available to both the VPN and the local LAN. However, I have two use cases for which there is not a good solution:
What I want to do is:
and then connect my docker containers directly to this network either specifying a literal IP address, or getting one auto-assigned by the dnsmasq that was already running on this bridge. There is currently no way to do this (that I've found) without docker trying to take control of IP address assignment on that bridge. I think docker has left a path open for my use case by writing a custom Here is what I would want from my ideal driver:
It doesn't seem like this should be too hard. The only non-trivial code in this driver would be a dhcp client, and it could just call out to an existing tool. |
In most cases all you need is macvlan https://docs.docker.com/network/macvlan/ |
macvlan is different from bridge, mostly, can no access each other by ip, can not use existing ifaces, because can not access each other, if only require egress connection, macvlan is fine. |
You can just use Brouting to get the job done, via proxy arp. That's just one of those dirty tricks that don't work too well because docker is still maintaining the authority over a piece of your subnet which isn't an option at all. I mean, look at the iptables fiasco... |
@Grimeton I'm confused whether you are saying that bridge routing will or won't work. If it will, I'd be interested in a link to read about how to try that. |
@nrdvana "BridgeD routing" is something you can easily create via proxy_arp on IP4 and proxy_ndp on IP6. Simple example: Subnet: 10.1.1.0/24 eth0 is NOT part of br-docker ! Now you enable proxy_arp on eth0 and create a route for 10.1.1.192/26 on dev br-docker. ip route add 10.1.1.192/26 dev br-docker From this moment on, the host, will respond to all arp requests for anything 10.1.1.192/26 and will forward the packets between the br-docker bridge and the main eth0 interface. Unless docker messes with your iptables rules even when it's disabled. Just in case: iptables -P FORWARD ACCEPT On a side note: people that DROP network packets really do NOT understand how networking works. Cu |
Adding another use case - I've got an existing bridge, With this configuration, and |
Those of you who land on this page looking for answers - google "com.docker.network.bridge.inhibit_ipv4=true" |
Interestingly, |
I found that I can define custom bridge network in Docker, disconnect veth from that bridge and reconnect to the bridge that I want. It seems to work, but it is also ugly. Specifying existing bridge in |
Thank you both very much, brilliant! Both of your solutions work! (Actually they don't, see update..) The only exception I found so far is that in Other than that, the containers are exposed to the network, can connect to the network hosts and to each other and can be connected from the network. @nazar-pc, I have no Idea why it didn't work for you. I added network named
Then created the container:
Try pinging, everything should work! You can do the same with macvlan (assuming you removed the bridge on the docker host):
Creatig test container with docker compose:
Update:Unfortunately, I found out that former approach (i.e. creating bridge on the docker host and creating a bridge network) actually breaks the internet access from the containers that use standard network configuration. It happens because docker isolates the bridge network from other networks, thus while the containers connected to the bridge network work as expected and as I described above they are exposed to the network, the other containers which use default per-container neworks loose the connectivity to the LAN/internet. I don't know how to prevent docker from inserting iptables rules permanentaly, but when I insert ALLOW rule manually in the DOCKER-ISOLATION-STAGE-2 chain:
Everything works. Of cause it's not a solution, just the explanation how docker blocks the traffic. Luckily the latter (macvlan) approach works. It exposes required containers to the LAN and does not break connectivity of the continers with default network configuration. |
+1. There needs to be an official and documented way of using a bridge that exists outside of docker itself. From docker's perspective this means skipping creating/configuring/destroying the bridge and just using the existing bridge that was provided by the user. |
Unfortunately it appeared that the |
Hello,
situation on the Linux box:
ip link create dev br0 type bridge
ip link set dev eth0 master br0
ip link set dev eth0 up
ip address add 10.1.1.254/24 dev br0
ip link set dev br0 up
ip route add default via 10.1.1.1
Now you tell the daemon to use br0 as the default bridge. So far so good. Now you create a container with --ip 10.1.1.249. Works as well. But when you start the container:
Error response from daemon: user specified IP address is supported on user defined networks only
Not nice.
When you create a different network with a bridge, then the bridge is created but it does NOT contain a host interface that would allow real bridging to work. Based on the information provided here: https://docs.docker.com/engine/reference/commandline/network_create/#usage there doesn't seem to be a way to add one.
If you create a different network with a bridge and name it "br0" as well, then docker starts to mess with the system's network configuration which is a no go.
What I want:
The docker daemon using the existing bridge and allowing containers to be assigned an ip address from the existing network with the help of the --ip configuration option that is available in the create context.
That would allow simple configurations with REAL bridging, WITHOUT iptables and other trickery and to run the container in the local network even with a gateway and internet access. The way bridging is intended to work and what bridges have been designed for in the first place.
I googled and searched on github and it seems the issue is as old as docker while the problem is usually solved by just closing the ticket.
I wonder...
Cu
The text was updated successfully, but these errors were encountered: