Pocas cosas son tan fundamentales en la administración de infraestructura como las máscaras de red —y pocas se entienden tan superficialmente. Cualquiera que haya configurado una interfaz de red ha escrito 255.255.255.0 casi por inercia. Pero cuando llega el momento de diseñar la arquitectura de red de un entorno de producción, de segmentar el tráfico entre VLANs, de dimensionar subredes para un despliegue en cloud privado o de entender por qué un firewall no deja pasar lo que debería, la comprensión real de cómo funcionan las máscaras de red marca la diferencia entre una infraestructura bien diseñada y una fuente permanente de incidencias.
Esta guía recorre el concepto desde los fundamentos hasta los escenarios prácticos que se encuentran a diario en entornos de datacenter y cloud, incluyendo tablas de referencia, ejemplos de cálculo y los errores más habituales.
Qué es una máscara de red y por qué importa en infraestructura
Una máscara de red es un valor de 32 bits que, aplicado a una dirección IP, separa dos cosas: la parte que identifica la red y la parte que identifica el host (el dispositivo concreto dentro de esa red). Es, en esencia, la herramienta que le dice a un sistema operativo, a un switch o a un router si un paquete debe quedarse en la red local o si tiene que salir por la puerta de enlace.
En binario, una máscara de red es siempre una secuencia de unos consecutivos seguidos de ceros consecutivos. Los unos marcan los bits de red; los ceros, los bits de host. No hay excepciones —aunque, como veremos más adelante, hubo un tiempo en que las había—.
Dos formas de expresar lo mismo:
- Notación decimal:
255.255.255.0 - Notación CIDR:
/24
Ambas representan exactamente lo mismo: los primeros 24 bits son red, los 8 restantes son host.
Cómo funciona internamente: la operación AND
Cuando un dispositivo necesita saber si una IP de destino está en su misma red, no compara direcciones «a ojo». Realiza una operación AND lógica entre su propia dirección IP y la máscara, y hace lo mismo con la IP de destino. Si los resultados coinciden, el paquete va directo. Si no, sale por el gateway.
Ejemplo práctico con la IP 192.168.1.45 y máscara 255.255.255.0:
IP: 11000000.10101000.00000001.00101101 (192.168.1.45)
Máscara: 11111111.11111111.11111111.00000000 (255.255.255.0)
────────────────────────────────────
AND: 11000000.10101000.00000001.00000000 → 192.168.1.0
El resultado —192.168.1.0— es la dirección de red. Si otro dispositivo produce el mismo resultado al aplicar su máscara, ambos están en la misma subred.
Este mecanismo, aparentemente simple, es lo que hace que toda la comunicación IP funcione: desde la red doméstica más básica hasta la arquitectura de red de un datacenter con cientos de VLANs.
Tabla completa de máscaras de red: de /32 a /0
La siguiente tabla es una referencia que conviene tener siempre a mano. Incluye la notación CIDR, la máscara en decimal, el número total de IPs, los hosts utilizables (descontando dirección de red y broadcast) y el uso más habitual en entornos reales de infraestructura.
| CIDR | Máscara decimal | Total IPs | Hosts utilizables | Uso habitual |
|---|---|---|---|---|
| /32 | 255.255.255.255 | 1 | 1 | Host route, loopback, reglas de firewall |
| /31 | 255.255.255.254 | 2 | 2* | Enlaces punto a punto (RFC 3021) |
| /30 | 255.255.255.252 | 4 | 2 | Interconexión entre routers |
| /29 | 255.255.255.248 | 8 | 6 | Segmento DMZ, IPs públicas pequeñas |
| /28 | 255.255.255.240 | 16 | 14 | Pequeño pool de IPs públicas, gestión |
| /27 | 255.255.255.224 | 32 | 30 | Red de gestión, oficina pequeña |
| /26 | 255.255.255.192 | 64 | 62 | VLAN de departamento, segmento de servidores |
| /25 | 255.255.255.128 | 128 | 126 | Subred de servidores mediana |
| /24 | 255.255.255.0 | 256 | 254 | LAN estándar, VLAN típica |
| /23 | 255.255.254.0 | 512 | 510 | LAN grande, campus |
| /22 | 255.255.252.0 | 1.024 | 1.022 | Campus, WiFi corporativo |
| /21 | 255.255.248.0 | 2.048 | 2.046 | Campus grande |
| /20 | 255.255.240.0 | 4.096 | 4.094 | ISP, cloud provider |
| /19 | 255.255.224.0 | 8.192 | 8.190 | Bloque ISP |
| /18 | 255.255.192.0 | 16.384 | 16.382 | Bloque ISP |
| /17 | 255.255.128.0 | 32.768 | 32.766 | Bloque ISP |
| /16 | 255.255.0.0 | 65.536 | 65.534 | Red corporativa grande |
| /12 | 255.240.0.0 | 1.048.576 | 1.048.574 | Rango privado Clase B (172.16.0.0/12) |
| /8 | 255.0.0.0 | 16.777.216 | 16.777.214 | Rango privado Clase A (10.0.0.0/8) |
| /0 | 0.0.0.0 | 4.294.967.296 | — | Ruta por defecto (default route) |
* La máscara /31, definida en la RFC 3021, no reserva dirección de red ni broadcast. Su uso está ampliamente soportado en routers modernos y ahorra una dirección respecto a /30 en cada enlace punto a punto —algo relevante cuando se gestionan cientos de interconexiones en un datacenter—.
Conversión decimal a binario: los valores que aparecen en cada octeto
| Decimal | Binario | Bits de red |
|---|---|---|
| 0 | 00000000 | 0 |
| 128 | 10000000 | 1 |
| 192 | 11000000 | 2 |
| 224 | 11100000 | 3 |
| 240 | 11110000 | 4 |
| 248 | 11111000 | 5 |
| 252 | 11111100 | 6 |
| 254 | 11111110 | 7 |
| 255 | 11111111 | 8 |
Estos son los únicos valores válidos que pueden aparecer en un octeto de una máscara de subred. Si alguien configura un valor diferente (por ejemplo, 255.255.255.200), la configuración es incorrecta.
Las máscaras más utilizadas en entornos profesionales
No todas las máscaras se usan con la misma frecuencia. En la práctica de datacenter e infraestructura cloud, estas son las que aparecen una y otra vez:
/24 — La máscara estándar
La más habitual en redes LAN y VLANs. Proporciona 254 hosts, lo que la hace adecuada para la mayoría de segmentos de una red empresarial: estaciones de trabajo, servidores de un rack, redes de gestión o VLANs de almacenamiento.
Ejemplo: 10.10.5.0/24 cubre desde 10.10.5.1 hasta 10.10.5.254, con broadcast en 10.10.5.255.
/25 — Dividir una /24 en dos
Cuando una /24 es demasiado grande y se necesita separar dos entornos (por ejemplo, producción y staging), una /25 divide el bloque en dos subredes de 126 hosts cada una.
| Subred | Rango | Hosts |
|---|---|---|
| 10.10.5.0/25 | .1 – .126 | 126 |
| 10.10.5.128/25 | .129 – .254 | 126 |
/26 — Cuatro segmentos por /24
Ideal para separar VLANs dentro de un mismo bloque cuando se necesitan segmentos más pequeños: red de servidores, red de gestión, red de monitorización y red de usuarios, cada una con hasta 62 hosts.
| Subred | Dirección de red | Primer host | Último host | Broadcast |
|---|---|---|---|---|
| 1 | 10.10.5.0/26 | 10.10.5.1 | 10.10.5.62 | 10.10.5.63 |
| 2 | 10.10.5.64/26 | 10.10.5.65 | 10.10.5.126 | 10.10.5.127 |
| 3 | 10.10.5.128/26 | 10.10.5.129 | 10.10.5.190 | 10.10.5.191 |
| 4 | 10.10.5.192/26 | 10.10.5.193 | 10.10.5.254 | 10.10.5.255 |
/27 — Segmentos de 30 hosts
Muy usado para redes de gestión (iDRAC/IPMI, switches, PDUs inteligentes) donde hay pocas decenas de dispositivos y se quiere un dominio de broadcast reducido.
/28 — Bloques pequeños de IPs públicas
Cuando un proveedor asigna un bloque de IPs públicas para un cliente, /28 (14 hosts) es una de las unidades más frecuentes. También se usa para DMZs con pocos servicios expuestos.
/30 y /31 — Enlaces punto a punto
En cualquier red de datacenter con múltiples routers o firewalls interconectados, los enlaces entre ellos usan /30 (2 hosts) o /31 (2 hosts sin desperdicio). En una infraestructura con 50 interconexiones, la diferencia entre /30 y /31 supone 50 direcciones IP ahorradas —algo que, a escala, importa—.
/32 — El host individual
No es una «subred» en sentido estricto: identifica una única dirección IP. Se utiliza en host routes (rutas estáticas a un host concreto), reglas de firewall específicas, interfaces loopback de routers y asignación de IPs en redes punto a multipunto.
Diseño de red con VLSM: un ejemplo real
En una infraestructura de producción, rara vez todas las subredes necesitan el mismo tamaño. La técnica VLSM (Variable Length Subnet Mask) permite asignar a cada segmento exactamente la máscara que necesita, optimizando el uso de direcciones.
Escenario: Una empresa tiene asignado el bloque 172.16.10.0/24 y necesita:
- Servidores de producción: 100 hosts
- Red de usuarios: 50 hosts
- Red de gestión/IPMI: 20 hosts
- DMZ: 10 hosts
- Dos enlaces WAN: 2 hosts cada uno
La asignación —empezando siempre por la subred más grande— sería:
| Segmento | Hosts necesarios | CIDR | Máscara | Hosts disponibles | Red asignada |
|---|---|---|---|---|---|
| Producción | 100 | /25 | 255.255.255.128 | 126 | 172.16.10.0/25 |
| Usuarios | 50 | /26 | 255.255.255.192 | 62 | 172.16.10.128/26 |
| Gestión | 20 | /27 | 255.255.255.224 | 30 | 172.16.10.192/27 |
| DMZ | 10 | /28 | 255.255.255.240 | 14 | 172.16.10.224/28 |
| WAN 1 | 2 | /30 | 255.255.255.252 | 2 | 172.16.10.240/30 |
| WAN 2 | 2 | /30 | 255.255.255.252 | 2 | 172.16.10.244/30 |
De las 256 direcciones del bloque original, se están utilizando 238 con un desperdicio mínimo. Sin VLSM, habría que asignar una /24 a cada segmento, necesitando seis bloques /24 en lugar de uno.
Wildcard mask: la otra cara de la máscara
En configuraciones de ACLs (listas de control de acceso) en routers y switches, y en protocolos como OSPF, no se usa la máscara de subred directamente sino su inverso: la wildcard mask o máscara comodín.
El cálculo es simple: 255.255.255.255 - máscara de subred = wildcard.
| Máscara de subred | Wildcard |
|---|---|
| 255.255.255.255 (/32) | 0.0.0.0 |
| 255.255.255.252 (/30) | 0.0.0.3 |
| 255.255.255.240 (/28) | 0.0.0.15 |
| 255.255.255.0 (/24) | 0.0.0.255 |
| 255.255.0.0 (/16) | 0.0.255.255 |
Ejemplo en ACL de Cisco: Permitir tráfico desde la red de servidores 172.16.10.0/25:
access-list 100 permit ip 172.16.10.0 0.0.0.127 any
Ejemplo en OSPF: Anunciar la red de gestión 172.16.10.192/27:
router ospf 1
network 172.16.10.192 0.0.0.31 area 0
Fórmulas de cálculo rápido
Dos fórmulas que conviene tener interiorizadas:
Hosts utilizables por subred:
2^(32 - prefijo_CIDR) - 2
Número de subredes al dividir un bloque:
2^(nuevo_prefijo - prefijo_original)
Ejemplos rápidos:
- ¿Cuántos hosts caben en una /27? → 2^(32-27) – 2 = 30
- ¿En cuántas /28 puedo dividir una /24? → 2^(28-24) = 16 subredes
- Necesito al menos 500 hosts: 2^n ≥ 502 → n = 9 → /23
Agregación de rutas (supernetting)
CIDR no solo permite dividir redes en subredes más pequeñas, sino también agregar varias redes en un anuncio más grande. Esto es fundamental para mantener las tablas de enrutamiento manejables, especialmente en BGP.
Ejemplo: En lugar de anunciar cuatro rutas separadas:
192.168.0.0/24
192.168.1.0/24
192.168.2.0/24
192.168.3.0/24
Se puede anunciar una sola ruta resumida: 192.168.0.0/22, reduciendo la carga en los routers vecinos. Esto solo funciona si las redes son contiguas y se alinean en un límite de potencia de 2.
Direcciones privadas (RFC 1918) y CGNAT
Tres bloques de direcciones están reservados para uso interno y no se enrutan en Internet:
| Bloque | CIDR | Hosts totales | Uso habitual |
|---|---|---|---|
| 10.0.0.0 – 10.255.255.255 | 10.0.0.0/8 | 16.777.214 | Redes corporativas grandes, cloud privado, datacenters |
| 172.16.0.0 – 172.31.255.255 | 172.16.0.0/12 | 1.048.574 | Redes medianas, segmentos de infraestructura |
| 192.168.0.0 – 192.168.255.255 | 192.168.0.0/16 | 65.534 | Redes domésticas, oficinas pequeñas |
Además, el bloque 100.64.0.0/10 está reservado para CGNAT (Carrier-Grade NAT, RFC 6598), una técnica que usan los ISP para compartir IPs públicas entre múltiples clientes. Es importante no utilizar este rango en redes internas propias para evitar conflictos.
Breve historia: de las redes planas a CIDR
El direccionamiento IP no siempre funcionó así:
Años 70: Las redes IP eran planas. Se asumían 8 bits para red y 24 para host. Solo existían 256 redes posibles en toda Internet.
1981 (RFC 791): Jon Postel introduce las clases A, B y C. La máscara se deduce implícitamente de la clase. El problema: una empresa mediana necesitaba una Clase B (65.534 hosts) porque la Clase C (254 hosts) se quedaba corta, desperdiciando miles de direcciones.
1985 (RFC 950): Se formalizan las máscaras de subred, permitiendo dividir redes en subredes más pequeñas.
1993 (RFC 1519): Nace CIDR (Classless Inter-Domain Routing), eliminando el concepto de clases y adoptando VLSM. Es el sistema que se usa actualmente y el que permitió que IPv4 sobreviviera mucho más de lo previsto.
Un dato curioso: en los primeros años, las máscaras no requerían bits contiguos. Una máscara como 255.255.192.128 era perfectamente válida. La práctica se abandonó a principios de los 90 porque hacía inviable el enrutamiento longest prefix match de forma eficiente.
Máscaras de red en IPv6
En IPv6, la notación decimal de máscara no existe. Se utiliza exclusivamente la notación de prefijo, equivalente a CIDR:
2001:0db8:85a3::1/64
Lo más habitual es /64 para redes locales (2^64 = 18,4 trillones de direcciones por subred, más que suficiente para cualquier escenario). Los ISP reciben bloques /32 o /48 de los registros regionales (RIPE, ARIN, LACNIC…).
En la práctica, la planificación de máscaras en IPv6 es más sencilla que en IPv4: la abundancia de direcciones elimina la necesidad del subnetting fino que hace imprescindible el dominio de VLSM en IPv4.
Consultar la máscara de red: comandos rápidos
Linux (la máscara aparece en notación CIDR):
ip addr show
# Ejemplo de salida: inet 10.10.5.45/24 brd 10.10.5.255 scope global eth0
Windows:
ipconfig
# Buscar: Máscara de subred . . . : 255.255.255.0
macOS:
ifconfig en0
# Buscar: netmask 0xffffff00 (hexadecimal de 255.255.255.0)
En un switch o router Cisco:
show ip interface brief
show running-config interface Vlan10
Errores frecuentes en la configuración de máscaras
Estos son los problemas más habituales que se encuentran en auditorías de red y que conviene conocer para evitarlos:
Máscaras inconsistentes en la misma VLAN. Si un servidor tiene /24 y otro /25 en la misma red física, parte del rango será inalcanzable para uno de ellos. Es una fuente clásica de «funciona a veces» difícil de diagnosticar.
Subredes solapadas. Al asignar manualmente bloques con VLSM sin un plan claro, es fácil que dos subredes se pisen. La consecuencia: paquetes que llegan al destino equivocado o rutas ambiguas.
Usar /24 por defecto cuando no es necesario. Un enlace WAN entre dos routers no necesita 254 direcciones. Un /30 o /31 es lo correcto; usar /24 desperdicia 252 IPs en cada enlace.
No restar 2 al calcular hosts. La dirección de red (todos los bits de host a 0) y la de broadcast (todos a 1) no son asignables. En una /24 hay 254 hosts, no 256. En una /30 hay 2, no 4.
Olvidar actualizar el gateway y el DNS. Al cambiar una máscara, la puerta de enlace y las reglas de firewall deben reflejar el nuevo esquema. Un cambio de máscara sin revisar el gateway es una caída garantizada.
Máscaras de red en el contexto de cloud privado
En entornos de cloud privado y bare metal, el diseño de subredes es una de las primeras decisiones arquitectónicas. La elección de máscaras afecta directamente a la escalabilidad, al aislamiento de tráfico y a la complejidad operativa.
Un diseño habitual en infraestructura de datacenter utiliza VLANs separadas con máscaras ajustadas a cada función:
| VLAN | Función | Máscara típica | Por qué |
|---|---|---|---|
| VLAN 10 | Producción | /24 o /23 | Espacio suficiente para servidores y crecimiento |
| VLAN 20 | Gestión/IPMI | /27 o /28 | Pocos dispositivos, aislamiento crítico |
| VLAN 30 | Almacenamiento (iSCSI/NFS) | /24 | Tráfico dedicado, MTU jumbo, sin gateway |
| VLAN 40 | Backup | /24 | Separado del tráfico de producción |
| VLAN 50 | DMZ | /28 o /27 | Solo servicios expuestos, firewall estricto |
| VLAN 100 | Interconexión de routers | /31 por enlace | Máximo aprovechamiento de IPs |
Este tipo de diseño, combinado con reglas de firewall entre VLANs y una buena documentación de la tabla de direccionamiento, es lo que separa una infraestructura profesional de un despliegue improvisado.
En la infraestructura de Stackscale, la gestión de red se diseña para que cada cliente disponga de segmentos correctamente dimensionados y aislados, con redundancia a nivel de red y conectividad a múltiples operadores. Si estás planificando un despliegue que requiere un diseño de red a medida, nuestro equipo puede ayudarte a dimensionar las subredes, VLANs y reglas de segmentación que mejor se adapten a tu caso.
