El problema que resuelve VLSM
Dividir una red en partes iguales es simple, pero casi nunca coincide con la realidad. Una oficina típica tiene un área con cien equipos, otra con cincuenta, un par de áreas chicas y varios enlaces entre routers que solo necesitan dos direcciones. Si todo se reparte en bloques del mismo tamaño, hay que dimensionarlos para el área más grande, y cada enlace punto a punto termina ocupando un bloque de 128 direcciones para usar dos.
VLSM (Variable Length Subnet Mask) resuelve esto permitiendo que cada subred tenga su propio prefijo. Esta guía resuelve un ejercicio completo de principio a fin, explica por qué el orden de asignación importa y muestra qué hacer cuando el espacio no alcanza. Si los conceptos de red, broadcast y tamaño de bloque no están frescos, conviene repasar primero Subnetting desde los bits: cómo calcular una subred a mano.
El enunciado
Se dispone de la red 192.168.50.0/24 (256 direcciones) y hay que asignar subredes para estos requerimientos:
| Subred | Hosts necesarios |
|---|---|
| Ventas | 100 |
| Desarrollo | 50 |
| Soporte | 25 |
| Gerencia | 10 |
| Enlace WAN 1 | 2 |
| Enlace WAN 2 | 2 |
El objetivo es que cada subred tenga el bloque más chico posible que alcance para sus hosts, sin superposiciones y dejando el espacio libre lo más contiguo posible para crecer.
Paso 1: calcular el bloque de cada subred
Cada subred necesita sus hosts más dos direcciones: la de red y la de broadcast. Ese total se redondea hacia arriba a la siguiente potencia de 2, porque los bloques CIDR solo existen en esos tamaños. El prefijo sale de cuántos bits de host hacen falta: un bloque de 2ʰ direcciones tiene prefijo /(32 − h).
| Subred | Hosts | Hosts + 2 | Bloque | Prefijo | Hosts útiles | Desperdicio |
|---|---|---|---|---|---|---|
| Ventas | 100 | 102 | 128 | /25 | 126 | 26 |
| Desarrollo | 50 | 52 | 64 | /26 | 62 | 12 |
| Soporte | 25 | 27 | 32 | /27 | 30 | 5 |
| Gerencia | 10 | 12 | 16 | /28 | 14 | 4 |
| Enlace WAN 1 | 2 | 4 | 4 | /30 | 2 | 0 |
| Enlace WAN 2 | 2 | 4 | 4 | /30 | 2 | 0 |
Antes de asignar nada conviene verificar que todo entra: 128 + 64 + 32 + 16 + 4 + 4 = 248 direcciones, y la red base tiene 256. Sobran 8, así que el ejercicio tiene solución. Si la suma superara 256, ningún orden de asignación lo resolvería.
Paso 2: ordenar de mayor a menor
Este es el paso que define si el resultado queda limpio o fragmentado. Un bloque de tamaño 2ᵏ solo puede empezar en una dirección múltiplo de 2ᵏ: un /25 empieza en .0 o en .128; un /26 en .0, .64, .128 o .192; y así sucesivamente. Es la misma regla que hace que la dirección de red tenga todos los bits de host en cero.
Si se asignan primero los bloques grandes, cada bloque siguiente arranca exactamente donde terminó el anterior, y esa dirección ya es múltiplo de su tamaño, porque todo lo asignado antes es múltiplo de bloques más grandes. Si se empieza por los chicos, aparecen huecos. Por ejemplo, si el primer enlace WAN ocupa 192.168.50.0/30, la siguiente dirección libre es .4, pero un /25 no puede empezar en .4: al aplicar la máscara 255.255.255.128 a .4, el resultado es .0, que ya está ocupado. Ventas tendría que irse a .128, y el espacio entre .4 y .127 quedaría partido en pedazos que hay que encajar a mano.
Paso 3: asignar en orden
Con la lista ordenada, se asigna cada bloque a partir de la primera dirección libre:
Ventas (/25, 128 direcciones). Empieza en 192.168.50.0. El broadcast es la última del bloque: .0 + 128 − 1 = .127. Hosts .1 a .126. La siguiente libre es .128.
Desarrollo (/26, 64 direcciones). Empieza en .128, que es múltiplo de 64. Broadcast .128 + 63 = .191. Hosts .129 a .190. Siguiente libre: .192.
Soporte (/27, 32 direcciones). Empieza en .192. Broadcast .223. Hosts .193 a .222. Siguiente libre: .224.
Gerencia (/28, 16 direcciones). Empieza en .224. Broadcast .239. Hosts .225 a .238. Siguiente libre: .240.
Enlace WAN 1 (/30, 4 direcciones). Empieza en .240. Broadcast .243. Hosts .241 y .242. Siguiente libre: .244.
Enlace WAN 2 (/30, 4 direcciones). Empieza en .244. Broadcast .247. Hosts .245 y .246. Siguiente libre: .248.
El resultado completo
| Subred | Red | Máscara | Primer host | Último host | Broadcast |
|---|---|---|---|---|---|
| Ventas | 192.168.50.0/25 | 255.255.255.128 | .1 | .126 | .127 |
| Desarrollo | 192.168.50.128/26 | 255.255.255.192 | .129 | .190 | .191 |
| Soporte | 192.168.50.192/27 | 255.255.255.224 | .193 | .222 | .223 |
| Gerencia | 192.168.50.224/28 | 255.255.255.240 | .225 | .238 | .239 |
| Enlace WAN 1 | 192.168.50.240/30 | 255.255.255.252 | .241 | .242 | .243 |
| Enlace WAN 2 | 192.168.50.244/30 | 255.255.255.252 | .245 | .246 | .247 |
Se usan 248 de 256 direcciones (96,9 % de utilización) y quedan libres 192.168.50.248 a .255: un bloque /29 contiguo, con 6 hosts útiles, disponible para un enlace o un área chica que aparezca más adelante. El desperdicio total, sumando la diferencia entre hosts útiles y pedidos, es de 47 direcciones; con subredes iguales de /25 ni siquiera alcanzaría para las seis subredes.
Para verificar el resultado, basta con cargar la red base y los seis requerimientos en la calculadora VLSM, en cualquier orden: la herramienta ordena de mayor a menor por su cuenta y debería devolver exactamente esta tabla. Cualquier fila puede revisarse en detalle en la calculadora de subredes.
Variante: cuando el espacio no alcanza
Supongamos que Ventas necesitara 130 hosts en lugar de 100. Con 132 direcciones necesarias, el bloque pasa a 256: un /24 completo. Ventas ocuparía toda la red base y Desarrollo, Soporte y los demás ya no tendrían lugar. La suma de bloques (256 + 64 + 32 + 16 + 4 + 4 = 376) supera las 256 disponibles, y eso se detecta en el Paso 1 sin necesidad de asignar nada.
Hay tres salidas habituales:
- Pedir una red base más grande, por ejemplo un
/23(512 direcciones). - Partir el requerimiento grande en dos subredes (dos
/25de 126 hosts) si el diseño lo permite. - Revisar los números: a veces 130 hosts incluye impresoras o equipos que pueden ir en otra subred.
La calculadora VLSM marca este caso con un aviso de espacio insuficiente e indica cuántas direcciones faltan.
Errores frecuentes en ejercicios de VLSM
- Olvidar sumar 2 antes de redondear. 30 hosts entran en un
/27(30 útiles), pero 31 hosts ya necesitan un/26. - Redondear al tamaño de bloque equivocado. 100 hosts no es un
/26(62 útiles): el bloque tiene que cubrir los hosts útiles, no las direcciones totales. - Asignar en el orden del enunciado. El enunciado no está ordenado por tamaño a propósito; ordenar es parte del ejercicio.
- Superponer bloques. Si el broadcast de una subred es mayor o igual que la red de la siguiente, hay un error de cálculo.
- Usar
/31sin verificar el equipo. Los enlaces/31(RFC 3021) ahorran dos direcciones, pero no todos los equipos los soportan. Los/30son la opción compatible por defecto.
Resumen
VLSM se resuelve siempre con la misma secuencia: calcular el bloque de cada subred (hosts + 2, redondeado a potencia de 2), comprobar que la suma entra en la red base, ordenar de mayor a menor y asignar de forma contigua. El orden no es un detalle de estilo: es lo que garantiza que cada bloque quede alineado a su tamaño sin dejar huecos.