Cuando empecé a ver VLSM (Variable Length Subnet Masking) en el temario de Introduction to Networks de Cisco, lo viví como “otro ejercicio de convertir binario a decimal”. Con el tiempo, haciendo ejercicios reales en Packet Tracer con departamentos de tamaños muy distintos, entendí que VLSM no es una operación matemática suelta: es una decisión de diseño de red, y cada paso del cálculo responde a una pregunta práctica sobre cómo va a crecer y funcionar esa red.
El problema que VLSM viene a resolver
Imagina una empresa con tres departamentos: uno de 120 ordenadores, otro de 14, y otro de 5. Si usas una subred de tamaño fijo para los tres (por ejemplo, una máscara /24 para todos, que da 254 direcciones utilizables), estás malgastando cientos de direcciones IP en los departamentos pequeños solo porque el más grande las necesita. VLSM soluciona esto asignando a cada departamento el tamaño de subred que realmente necesita, ni una dirección más.
Esto no es un detalle académico: en una red real, las direcciones IP (sobre todo si trabajas con rangos privados limitados, o peor, con IPs públicas) son un recurso que hay que administrar con cabeza, no repartir a partes iguales sin pensar.
Cómo se aborda en la práctica (el método que a mí me funcionó)
Con departamentos de 120, 14 y 5 equipos, el orden de trabajo que a mí me terminó encajando fue:
1. Ordenar los departamentos de mayor a menor número de hosts. Esto no es opcional: VLSM se calcula de mayor a menor porque cada subred que reservas “corta” un trozo del espacio de direcciones disponible, y si empiezas por las pequeñas, puedes quedarte sin espacio contiguo para encajar la grande después.
2. Calcular cuántos bits de host necesita el departamento más grande. Para 120 equipos, necesitas al menos 2^7 = 128 direcciones (127 utilizables), así que reservas 7 bits para hosts, lo que te deja una máscara /25.
3. Repetir con el siguiente departamento, pero ya sobre el espacio que queda libre. Para 14 equipos, necesitas 2^4 = 16 direcciones (14 utilizables), así que aquí la máscara es /28.
4. Y para el más pequeño, 5 equipos, necesitas 2^3 = 8 direcciones (6 utilizables), máscara /29.
Lo que a mí me costaba al principio no era la fórmula en sí, sino mantener la cabeza fría mezclando binario y decimal a la vez: saber en qué octeto estás trabajando, cuánto vale cada bit que “tomas prestado” para host, y no perder la cuenta de qué rango ya está usado y cuál sigue libre. La solución no fue memorizar más rápido, sino crear mi propio método sobre papel: una tabla sencilla con columnas para departamento, hosts necesarios, bits de host, máscara resultante y rango de direcciones — repetirla en cada ejercicio hasta que dejó de hacer falta pensarla desde cero cada vez.
Con la red base 192.168.1.0/24, para los tres departamentos del ejemplo, la tabla queda así:
| Departamento | Hosts necesarios | Bits de host | Máscara | Rango de direcciones | Broadcast |
|---|---|---|---|---|---|
| Grande (120 equipos) | 120 | 7 (2⁷=128, 126 útiles) | /25 | 192.168.1.0 – 192.168.1.127 | 192.168.1.127 |
| Mediano (14 equipos) | 14 | 4 (2⁴=16, 14 útiles) | /28 | 192.168.1.128 – 192.168.1.143 | 192.168.1.143 |
| Pequeño (5 equipos) | 5 | 3 (2³=8, 6 útiles) | /29 | 192.168.1.144 – 192.168.1.151 | 192.168.1.151 |
Fíjate en el orden: el departamento grande “se queda” con el primer bloque completo (0-127), y solo cuando ese hueco está reservado se calcula el siguiente sobre el espacio que queda libre (128 en adelante). Si lo haces al revés, es fácil que el bloque de 128 direcciones que necesita el departamento grande ya no quepa entero en lo que sobra.
El error típico cuando empiezas
El fallo más habitual (y el que yo mismo cometía al principio) es calcular cada subred de forma aislada, sin tener en cuenta que el resultado de una condiciona el punto de partida de la siguiente. Si calculas el departamento de 14 equipos antes que el de 120, es fácil que la subred del más grande ya no encaje limpiamente en el espacio que queda, y termines con solapamientos o con rangos que no cuadran al verificarlos en Packet Tracer.
Por qué hacerlo en papel (o en un bloc de notas) ayuda más que una calculadora
Es tentador usar una calculadora de subredes desde el primer ejercicio, pero hacerlo a mano al principio — aunque parezca más lento — es lo que realmente te obliga a entender por qué cada bit se mueve donde se mueve. Una calculadora te da el resultado; el papel te obliga a razonar el proceso, que es justo lo que luego te hace falta en el examen o cuando toca defender el diseño de una red real sin herramientas delante.
Pon a prueba lo que has entendido
Vas a calcular subredes con VLSM para tres departamentos de tamaños distintos. ¿En qué orden debes calcularlas?
Resumen rápido
- VLSM reparte a cada subred solo las direcciones que necesita, en vez de un tamaño fijo para todas.
- Se calcula siempre de mayor a menor número de hosts, nunca al revés.
- La dificultad real no está en la fórmula, sino en mantener el orden mezclando binario y decimal sin perder la cuenta del espacio ya usado.
- Practicar en papel, con un método propio y repetible, ayuda más a largo plazo que depender de una calculadora desde el principio.