Docker offers a variety of virtual networks (see https://docs.docker.com/engine/network/drivers/) for communication with and among containers, but does not ask you what IP addresses are safe to use for these networks. Instead, Docker simply appropriates IP address space of its own choosing, such as 172.17.0.0/16, which may already be in use by real hosts on the campus network.

Symptoms:

• Your containers will not be able to send packets to a real host at 172.17.x.y
• In some cases, your entire workstation will not be able to send packets to a real host at 172.17.x.y (because Docker has configured your workstation to give those packets to Docker instead).

To diagnose this problem:

1. `docker network list` to see the virtual networks Docker has configured.
2. `docker network inspect NETWORK` for each one to see what IP address space it is using.

The solution to this problem is to reconfigure Docker to instead use any part (or parts) of 192.168.0.0/16, which Technology Services does not route anywhere on the campus network (per Networking, Guide to University of Illinois IP Spaces).

Full details are out of scope for this article, but you may find the following links helpful:

• https://docs.docker.com/engine/network/drivers/bridge/#configure-the-default-bridge-network
• https://docs.docker.com/engine/daemon/#configure-the-docker-daemon
• https://github.com/docker/compose/issues/4336

Note that you probably do not want Docker to use the entire 192.168.0.0/16, especially on mobile workstations, because that would conflict with many home networks and public wi-fi networks. In the absence of detailed information about the specific real networks you frequent, consider configuring Docker to use something like 192.168.n.0/24 where n is between 101 and 253.