Docker crea por defecto la red `docker0` en 172.17.0.0/16 y va reservando bloques /16 sucesivos para cada red bridge definida por el usuario. En una empresa que ya usa 172.16.0.0/12 en su LAN, eso provoca el fallo más difícil de diagnosticar de todos: el contenedor arranca, pero no llega a un servidor interno porque su tabla de rutas cree que esa IP es local. Esta calculadora te dice cuántas direcciones útiles tiene cada prefijo, cuántos contenedores caben y qué bloques puedes reservar sin solaparte.
Cómo asigna Docker las subredes por defecto
El daemon usa un pool configurable (default-address-pools en /etc/docker/daemon.json) que de fábrica arranca en 172.17.0.0/16 y avanza en incrementos de /16 hasta 172.31.0.0/16, más 192.168.0.0/16 dividido en /20 para Swarm. Cada docker network create consume el siguiente bloque libre. Si tu red corporativa ya utiliza cualquiera de esos rangos, el conflicto es inevitable y silencioso: el tráfico hacia esa red nunca sale del host. La solución es declarar explícitamente el pool en el daemon o fijar --subnet en cada red.
Cuántos contenedores caben en cada prefijo
Un /24 ofrece 254 direcciones asignables (se descuentan la de red, la de broadcast y la del gateway que Docker reserva, así que en la práctica quedan 253). Un /25 deja 125, un /26 deja 61 y un /28 sólo 13, suficiente para un stack de Compose pequeño. Un /16 da 65.533, mucho más de lo que ningún host va a ejecutar: reservar /16 por red es el desperdicio más habitual y el que provoca colisiones con la LAN. Regla práctica: /24 para redes de proyecto, /26 o /28 para stacks aislados, y guarda los /16 para el pool global. Si necesitas dividir un bloque grande en varias redes, la calculadora CIDR y el conversor de máscara de red hacen el reparto exacto.
Configurar el pool global en daemon.json
El bloque {"default-address-pools":[{"base":"10.200.0.0/16","size":24}]} le indica a Docker que reparta redes /24 dentro de 10.200.0.0/16, es decir 256 redes posibles antes de agotarse. Este cambio requiere reiniciar el daemon (systemctl restart docker) y no reasigna las redes ya creadas: hay que borrarlas y recrearlas. Elegir un rango poco frecuentado dentro de 10.0.0.0/8 es la forma más limpia de no chocar nunca con oficinas, VPN o proveedores cloud, que casi siempre viven en 10.0.x, 172.16-31.x o 192.168.x.
Bridge, host, overlay y macvlan: implicaciones de direccionamiento
En modo bridge cada contenedor recibe una IP privada del bloque y sale a la red por NAT del host, así que su IP no es enrutable desde fuera. En modo host no hay IP propia: el contenedor comparte la pila de red del host y también sus puertos, lo que elimina el aislamiento. Overlay, usado en Swarm, encapsula el tráfico con VXLAN entre nodos y necesita que el puerto 4789/UDP y el 7946 estén abiertos entre ellos. Macvlan da al contenedor una MAC y una IP de la LAN real: es lo que se usa cuando un servicio debe verse como un equipo más de la red, y ahí sí debes reservar el rango en el DHCP para que no lo entregue a nadie más.
Diagnosticar un solape de red
Los síntomas son claros: el contenedor resuelve DNS pero no conecta con una IP interna concreta, o el host pierde acceso a un servidor tras levantar un stack. Comprueba con docker network inspect <red> | grep Subnet qué bloque se ha asignado y contrástalo con ip route en el host. Si la ruta hacia la red del contenedor tapa una ruta corporativa, ese es el problema. La reparación consiste en recrear la red con --subnet en un rango libre y actualizar el docker-compose.yml. Los generadores de Docker Compose y Dockerfile del sitio permiten dejar esa configuración fijada desde el principio.
Reservar direcciones e IP fijas por contenedor
En Compose puedes declarar ipam.config.subnet junto a ip_range para que Docker asigne dinámicamente sólo dentro de un subconjunto, dejando el resto del bloque para IP estáticas asignadas con ipv4_address. Es el patrón recomendado cuando un contenedor debe tener una dirección estable (un servidor DNS interno, un proxy, un colector de logs) sin renunciar al direccionamiento automático del resto. Documenta esas reservas igual que documentarías un rango de DHCP: la memoria del equipo no es un IPAM.
Casos de uso comunes
- Elegir el prefijo adecuado para una red de Compose sin desperdiciar direcciones.
- Definir un pool corporativo en daemon.json que no choque con la LAN ni con la VPN.
- Planificar redes overlay en un clúster Swarm con varios entornos.
- Reservar un rango de IP fijas para servicios de infraestructura dentro de una red bridge.
- Diagnosticar por qué un contenedor no alcanza un servidor interno.
Buenas prácticas
- Nunca dejes que Docker elija subred en un host conectado a una red corporativa: fija el pool.
- Usa /24 o menor por red de proyecto; los /16 sólo para el pool global.
- Documenta cada rango asignado igual que harías con las VLAN.
- Abre 4789/UDP y 7946 entre nodos antes de crear redes overlay.