Subnetting explicado paso a paso: ejemplos, VLSM y errores comunes

Si trabajas con redes, antes o después tienes que dividir un bloque de direcciones: separar usuarios de servidores, aislar a los invitados, conectar dos sedes sin que se pisen los rangos. Eso es subnetting. Suele presentarse como un ejercicio de binario para aprobar un examen, pero en el día a día es sobre todo una herramienta de diseño: decide cuántos equipos caben en cada segmento, qué tráfico puede cruzar entre ellos y cómo vas a crecer sin renumerar media red.

En esta guía vamos del concepto al método práctico. Verás la fórmula que necesitas, un atajo para calcular rangos sin pasar por binario, tres ejemplos resueltos de dificultad creciente, los errores que más problemas dan en redes reales, un caso de campo y unos ejercicios para comprobar que lo has entendido.

Por qué se divide una red en subredes

Una red plana con cientos de equipos funciona, pero tiene costes. Dividirla aporta cuatro ventajas concretas:

• Menos ruido: los broadcast (como las peticiones ARP) no salen de su subred, así que cada segmento carga con menos tráfico.
• Seguridad: cuando los usuarios, los servidores y los invitados están en subredes distintas, puedes controlar con un firewall o una ACL qué puede hablar con qué.
• Orden: un direccionamiento coherente (por sede, por función o por VLAN) hace que diagnosticar un problema sea mucho más rápido.
• Crecimiento: un plan con huecos reservados permite añadir equipos o sedes sin tocar lo que ya funciona.

Si además segmentas con VLAN, te interesa nuestra guía de VLANs y segmentación de red empresarial: cada VLAN suele corresponderse con una subred.

IPv4, máscara y prefijo CIDR

Una dirección IPv4 son 32 bits que escribimos en cuatro grupos de 8 (octetos) separados por puntos, como 192.168.10.37. La máscara de subred indica qué parte de esos 32 bits identifica la red y qué parte identifica al equipo dentro de ella. Se puede escribir como 255.255.255.0 o, de forma abreviada, como prefijo CIDR: /24 significa que los primeros 24 bits son de red y los 8 restantes son de host.

Para saber a qué red pertenece una dirección, el equipo hace una operación AND bit a bit entre la IP y la máscara. Con 192.168.10.37 y una máscara /24:

IP:       11000000.10101000.00001010.00100101   (192.168.10.37)
Máscara:  11111111.11111111.11111111.00000000   (255.255.255.0)
Red:      11000000.10101000.00001010.00000000   (192.168.10.0)

Los bits de red se conservan y los de host se ponen a cero: la dirección de red es 192.168.10.0. No necesitas hacer esto en binario cada vez, pero conviene entenderlo una vez, porque todo lo demás se deriva de ahí.

Estas son las máscaras que más vas a usar:

• /24 = 255.255.255.0
• /25 = 255.255.255.128
• /26 = 255.255.255.192
• /27 = 255.255.255.224
• /28 = 255.255.255.240
• /29 = 255.255.255.248
• /30 = 255.255.255.252

Cuántos equipos caben en una subred

Con n bits de host, una subred tiene 2^n direcciones. De ellas, dos están reservadas: la primera es la dirección de red y la última es la dirección de broadcast. Por eso:

hosts utilizables = 2^(32 - prefijo) - 2

Resumen para los prefijos habituales:

• /24: 256 direcciones, 254 hosts utilizables
• /25: 128 direcciones, 126 hosts
• /26: 64 direcciones, 62 hosts
• /27: 32 direcciones, 30 hosts
• /28: 16 direcciones, 14 hosts
• /29: 8 direcciones, 6 hosts
• /30: 4 direcciones, 2 hosts

Dos detalles prácticos. Primero, la puerta de enlace (el router o firewall de la subred) también consume una de esas direcciones, así que el número real de equipos es uno menos. Segundo, hay excepciones: un /31 se usa en enlaces punto a punto entre dos routers (RFC 3021) y no reserva dirección de red ni de broadcast, y un /32 identifica a un único equipo, por ejemplo una dirección de loopback.

Para saber qué prefijo necesitas, suma 2 al número de equipos que quieres alojar y busca la potencia de 2 igual o superior. Para 50 equipos: 50 + 2 = 52, la potencia de 2 que lo cubre es 64 (2^6), así que necesitas 6 bits de host y el prefijo es 32 - 6 = /26.

El método del salto: calcular rangos sin binario

Hay un atajo que usan casi todos los técnicos con experiencia. Se fija en el octeto donde la máscara deja de ser 255 y calcula el tamaño del bloque:

salto = 256 - valor de ese octeto de la máscara

Con un /26 (255.255.255.192), el octeto interesante es el último: 256 - 192 = 64. Las subredes empiezan, por tanto, de 64 en 64: .0, .64, .128 y .192. Cada una termina un número antes de que empiece la siguiente, y esa última dirección es su broadcast.

Esta regla tiene una consecuencia importante que mucha gente pasa por alto: una subred siempre empieza en un múltiplo de su tamaño. En un /26, 10.0.0.64 es una dirección de red válida; 10.0.0.100 no lo es.

Ejemplo 1: dividir una /24 en cuatro subredes iguales

Tienes 192.168.10.0/24 y quieres cuatro segmentos del mismo tamaño. Para obtener 4 subredes necesitas 2 bits más (2^2 = 4), así que el prefijo pasa de /24 a /26. El salto es 64 y el resultado:

• 192.168.10.0/26: hosts del .1 al .62, broadcast .63
• 192.168.10.64/26: hosts del .65 al .126, broadcast .127
• 192.168.10.128/26: hosts del .129 al .190, broadcast .191
• 192.168.10.192/26: hosts del .193 al .254, broadcast .255

Cada subred admite 62 equipos (64 - 2). Si alguna necesita más, este reparto en partes iguales no te sirve, y ahí entra el siguiente ejemplo.

Ejemplo 2: VLSM, cada subred con el tamaño que necesita

En la práctica casi nunca hace falta repartir en partes iguales. VLSM (máscara de longitud variable) consiste en asignar a cada segmento justo el tamaño que necesita. Imagina que parte de 10.0.0.0/24 y debes alojar:

• Ventas: 100 equipos
• Administración: 50 equipos
• Servidores: 20 equipos
• Enlace punto a punto entre dos routers: 2 equipos

La regla de oro es ordenar de mayor a menor y asignar en ese orden, siempre en el primer bloque libre y alineado:

• Ventas necesita 100 + 2 = 102, y la potencia de 2 que lo cubre es 128, así que /25. Resultado: 10.0.0.0/25 (del .0 al .127), hosts del .1 al .126.
• Administración necesita 52, y el bloque es 64, así que /26. Resultado: 10.0.0.128/26 (del .128 al .191), hosts del .129 al .190.
• Servidores necesita 22, y el bloque es 32, así que /27. Resultado: 10.0.0.192/27 (del .192 al .223), hosts del .193 al .222.
• El enlace entre routers necesita 2 hosts, así que /30. Resultado: 10.0.0.224/30 (del .224 al .227), hosts .225 y .226.

Todavía te quedan libres las direcciones de la .228 a la .255. No las malgastes: son la reserva para crecer, y se pueden aprovechar con 10.0.0.228/30, 10.0.0.232/29 y 10.0.0.240/28, que respetan la alineación. Ordenar de mayor a menor evita que los bloques grandes se queden sin un hueco alineado donde caber.

Ejemplo 3: a qué subred pertenece una dirección

Te dan 172.16.45.200 con máscara /20 y te piden la red, el broadcast y el rango de hosts.

Un /20 son 255.255.240.0, así que el octeto interesante es el tercero. El salto es 256 - 240 = 16, y las redes van de 16 en 16 en ese octeto: 0, 16, 32, 48... El 45 cae entre 32 y 47, por lo que:

• Dirección de red: 172.16.32.0/20
• Broadcast: 172.16.47.255
• Hosts utilizables: de 172.16.32.1 a 172.16.47.254
• Cantidad de hosts: 2^12 - 2 = 4094

Errores frecuentes en el diseño de subredes

Estos son los fallos que más tiempo hacen perder:

• Olvidar las dos direcciones reservadas. Quien calcula 2^n en vez de 2^n - 2 acaba dimensionando una subred con una o dos direcciones de menos de las que necesita.
• Solapar rangos. Asignar 192.168.1.0/24 en una sede y 192.168.1.128/25 en otra genera conflictos de enrutamiento difíciles de ver a simple vista.
• No respetar la alineación. Una dirección de red debe ser múltiplo del tamaño del bloque; 10.0.0.100/26 no es una red válida.
• Elegir una subred justa, sin margen. Si hoy tienes 50 equipos y eliges un /26 (62 hosts), con muy poco crecimiento te quedas sin direcciones. Conviene dejar un 25 a 30 % de holgura.
• Confundir la máscara con la wildcard. Las ACL de muchos fabricantes y la configuración de OSPF en Cisco usan la máscara inversa: para un /24 es 0.0.0.255, y para un /26 es 0.0.0.63.
• Usar el mismo rango en sedes que luego se interconectan. Es muy habitual que dos oficinas utilicen 192.168.1.0/24, que viene de serie en muchos routers. Cuando las unes por VPN, el tráfico no sabe a qué lado enviar los paquetes: hay que renumerar una de ellas o recurrir a NAT, que añade complejidad.

Un caso real: dos sedes con el mismo rango

En una empresa del sector de distribución industrial, con dos oficinas situadas en distintas provincias, la VPN entre ambas aparecía como establecida en los dos firewalls, pero desde la sede principal no había forma de llegar a los equipos de la sucursal. Los usuarios decían que «la VPN estaba levantada y no funcionaba».

Lo primero que comprobamos fue el enrutamiento desde un equipo de la sede principal hacia un servidor de la sucursal, cuya dirección era 192.168.1.57:

$ ip route get 192.168.1.57
192.168.1.57 dev eth0 src 192.168.1.23

La salida lo explica todo: no aparece ningún via, es decir, no hay una puerta de enlace. El equipo consideraba que 192.168.1.57 estaba dentro de su propia red local y trataba de localizarlo mediante ARP, en lugar de enviar el tráfico al firewall.

Al revisar la configuración descubrimos que ambas sedes utilizaban 192.168.1.0/24, un rango habitual en routers domésticos y pequeñas instalaciones. Por tanto, aunque el túnel IPsec estaba correctamente negociado y aparecía como activo en ambos extremos, el tráfico destinado a la sucursal nunca llegaba al firewall para ser enviado por la VPN.

La pista definitiva apareció al hacer una captura de tráfico (con tcpdump -ni eth0 arp) mientras se intentaba acceder al servidor. Veíamos las peticiones ARP en la interfaz LAN del equipo, pero no aparecía tráfico dirigido al firewall. En pocos minutos quedó claro que el problema no estaba en la negociación de la VPN, sino en el direccionamiento de las dos redes.

La solución definitiva fue renumerar la sucursal y trasladarla al rango 10.42.18.0/24. Hubo que modificar el ámbito DHCP, las direcciones fijas de unos 14 dispositivos (entre ellos impresoras, cámaras IP y un servidor local), varios registros DNS, las reglas del firewall y los selectores de la VPN.

Como solución temporal se podría haber utilizado un NAT 1:1 para presentar la red remota mediante un rango diferente, pero esta opción añade complejidad y puede complicar el diagnóstico y el mantenimiento futuro.

Lo que aprendimos es que ahora cada sede recibe su propio bloque de direcciones desde el primer día, siguiendo un esquema similar a 10.sede.vlan.0/24. Además, el plan de direccionamiento se documenta y revisa antes de instalar los equipos o configurar la VPN.

En definitiva, que una VPN aparezca como «establecida» no significa necesariamente que exista conectividad entre las redes. Antes de revisar cifrados, túneles o reglas complejas, conviene comprobar algo tan básico como la tabla de rutas del equipo origen.

Buenas prácticas de direccionamiento

• Usa rangos privados (RFC 1918): 10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16.
• Diseña un esquema con lógica que se pueda leer. Por ejemplo, 10.sede.vlan.0/24 hace que de un vistazo sepas a qué sede y a qué segmento pertenece una IP.
• Separa por función: usuarios, servidores, gestión, invitados e IoT en subredes distintas, con reglas de firewall entre ellas.
• Reserva bloques contiguos por sede. Así puedes resumir rutas: dos subredes consecutivas como 10.1.0.0/24 y 10.1.1.0/24 se anuncian como una sola, 10.1.0.0/23. Esto cobra especial importancia cuando conectas sedes con protocolos de enrutamiento, como se ve en OSPF vs BGP.
• Documenta el plan de direccionamiento y mantenlo actualizado. Es el documento que más agradecerás a las 3 de la madrugada.

Cómo comprobar tus cálculos

Hacer los cálculos a mano es la mejor forma de aprender, pero para validarlos en un trabajo real conviene apoyarse en herramientas. Puedes usar nuestra calculadora de subredes o hacerlo desde la terminal. En Python, el módulo ipaddress de la biblioteca estándar resuelve los tres ejemplos de esta guía:

import ipaddress

# Ejemplo 3: red, broadcast y hosts de 172.16.45.200/20
red = ipaddress.ip_network("172.16.45.200/20", strict=False)
print(red)                                   # 172.16.32.0/20
print(red.network_address, red.broadcast_address)
print(red.num_addresses - 2)                 # 4094

# Ejemplo 1: dividir 192.168.10.0/24 en subredes /26
for sub in ipaddress.ip_network("192.168.10.0/24").subnets(new_prefix=26):
    print(sub)

Para ver qué dirección y qué prefijo tiene cada interfaz de un equipo, en Linux usa ip -4 addr show y en Windows ipconfig.

Ejercicios para practicar

Resuélvelos primero a mano y comprueba después:

1. ¿Cuántos hosts utilizables tiene 10.1.0.0/22?
2. ¿Cuál es la dirección de broadcast de 192.168.5.130/25?
3. ¿Qué prefijo necesitas para alojar 500 equipos?

Soluciones:

1. Un /22 deja 10 bits de host: 2^10 - 2 = 1022 hosts utilizables.
2. Un /25 divide cada /24 en dos bloques de 128. La dirección .130 está en el bloque .128 a .255, así que el broadcast es 192.168.5.255.
3. 500 + 2 = 502, y la potencia de 2 que lo cubre es 512 (2^9). Necesitas 9 bits de host, es decir, un /23, que ofrece 510 hosts utilizables.

Subnetting en IPv6: los mismos principios, otra escala

IPv6 usa direcciones de 128 bits escritas en hexadecimal (ocho grupos de cuatro dígitos). Los principios son los mismos que en IPv4: un prefijo separa la parte de red de la parte de host. Lo que cambia es la escala: el tamaño estándar de una subred es /64, que ofrece 2^64 direcciones, así que ya no hay que ajustar los tamaños para ahorrar. Los proveedores suelen entregar a una organización un prefijo /48 o /56, que permite crear 65.536 o 256 subredes /64 respectivamente. En IPv6 el subnetting es, sobre todo, un ejercicio de organización: dar a cada sede y a cada VLAN su propio /64 siguiendo un plan ordenado.

Resumen

Dominar el subnetting no consiste en memorizar tablas. Consiste en recordar tres ideas: la máscara separa red y host, una subred siempre empieza en un múltiplo de su tamaño, y se resta siempre 2 para las direcciones de red y de broadcast. Con el método del salto y VLSM ordenado de mayor a menor, puedes diseñar un direccionamiento limpio, con margen para crecer y fácil de documentar, que es lo que marca la diferencia entre una red que escala y una que se vuelve un problema cada vez que la tocas.