Máscaras de subred y notación CIDR: guía práctica para IPv4

Por qué las máscaras de subred siguen importando

Configurar un servidor, abrir un puerto en un grupo de seguridad, crear una VPC o depurar por qué dos contenedores no se ven entre sí son tareas que, tarde o temprano, obligan a cualquier desarrollador a enfrentarse con valores como 255.255.255.224 o /27. Aunque las herramientas modernas ocultan buena parte de la complejidad, entender qué significan esos números marca la diferencia entre adivinar una configuración y diseñarla con intención.

Esta guía reúne en un solo lugar una referencia rápida de prefijos CIDR, máscaras y máscaras comodín, y la acompaña de una explicación completa de cómo funcionan por dentro: la representación binaria de una dirección IPv4, la separación entre red y host, el origen de la notación CIDR y el antiguo sistema de clases que la precedió. Además, incluye ejemplos ejecutables con el módulo ipaddress de Python, un caso práctico de VLSM, las particularidades de las subredes en la nube y una colección de errores frecuentes con su solución.

Todo el contenido se centra en IPv4. IPv6 utiliza la misma idea de prefijos, pero con direcciones de 128 bits y convenciones distintas, por lo que merece un tratamiento aparte.

Tabla de referencia CIDR para IPv4

La siguiente tabla de referencia CIDR resume, para cada longitud de prefijo, la máscara en formato decimal, la máscara comodín (wildcard) que usan muchas listas de control de acceso, el número total de direcciones del bloque y cuántas de ellas pueden asignarse a equipos.

La regla que explica la última columna es sencilla: en una subred convencional se descuentan dos direcciones, la primera, que identifica a la red, y la última, que se usa como difusión. Hay dos excepciones. Un /32 representa un único equipo, algo habitual en rutas de host, interfaces loopback o reglas de firewall que apuntan a una sola IP. Un /31, definido en el RFC 3021, permite usar ambas direcciones en enlaces punto a punto entre dos routers, donde no tiene sentido reservar red ni difusión.

Para valores intermedios conviene memorizar un patrón: cada bit que se resta al prefijo duplica el tamaño del bloque. Un /25 tiene el doble de direcciones que un /26, y un /23 equivale a dos /24 contiguos.

Equivalencias binarias de cada octeto

Una máscara válida siempre está formada por unos consecutivos seguidos de ceros consecutivos. Por eso solo existen nueve valores posibles para cada octeto, y la máscara comodín no es más que su inverso bit a bit.

Si en alguna configuración aparece un octeto como 255.255.250.0, puede descartarse de inmediato: 250 no figura en la lista y, por tanto, no corresponde a una máscara contigua. Un truco útil para calcular la máscara comodín de cabeza es restar cada octeto de 255; para 255.255.255.240 se obtiene 0.0.0.15.

Anatomía de una dirección IPv4 en 32 bits

Una dirección como 10.40.8.17 es solo una forma cómoda de escribir un número de 32 bits. Esos bits se agrupan en cuatro bloques de ocho, llamados octetos, y cada octeto se expresa en decimal con un valor entre 0 y 255. El punto que los separa existe únicamente para facilitar la lectura humana; para la pila de red, la dirección es un entero sin estructura visible.

Esta perspectiva es la que permite entender todo lo demás. Una máscara de subred también es un número de 32 bits, y las operaciones que realizan los sistemas operativos para decidir si un paquete se entrega de forma local o se envía a la puerta de enlace son simples operaciones lógicas entre ambos números. El rango completo de IPv4 abarca 2^32 direcciones, es decir, algo más de 4,294 millones, una cifra que parecía inagotable en los años ochenta y que resultó insuficiente con la expansión de internet.

Conversión de decimal a binario paso a paso

Para convertir un octeto se utiliza una tabla de pesos con las potencias de dos de un byte:

El procedimiento consiste en recorrer la tabla de izquierda a derecha, colocando un 1 cuando el peso cabe en lo que queda del número y un 0 cuando no. Tomemos la dirección 198.51.100.42 y convirtamos su primer octeto, 198. Como 128 cabe, se anota 1 y restan 70; 64 cabe, se anota 1 y restan 6; 32, 16 y 8 no caben; 4 cabe y restan 2; 2 cabe y resta 0; el 1 queda en cero. El resultado es 11000110.

Repitiendo el proceso con los demás octetos se obtiene la representación completa, que puede comprobarse con unas pocas líneas de Python:

def a_binario(direccion: str) -> str:
    return ".".join(f"{int(octeto):08b}" for octeto in direccion.split("."))

print(a_binario("198.51.100.42"))
print(a_binario("255.255.255.224"))

11000110.00110011.01100100.00101010
11111111.11111111.11111111.11100000

El formato 08b indica que cada número debe representarse en binario con ocho dígitos, rellenando con ceros a la izquierda. Es una forma rápida de verificar ejercicios hechos a mano o de generar material de práctica.

Bits de red y bits de host

Toda dirección IPv4 se divide en dos partes. Los bits de la izquierda identifican la red a la que pertenece el equipo y los de la derecha identifican al equipo dentro de esa red. La frontera entre ambas partes no es fija: la determina la máscara.

La regla es directa. Donde la máscara tiene un 1, el bit correspondiente de la dirección pertenece a la red; donde tiene un 0, pertenece al host. Si se aplica una operación AND bit a bit entre la dirección y la máscara, el resultado es la dirección de red, también llamada identificador de red.

En este ejemplo, los 26 primeros bits forman la parte de red y los 6 restantes la parte de host. Con 6 bits de host caben 64 combinaciones; la primera, 172.20.16.128, es la dirección de red y la última, 172.20.16.191, actúa como dirección de broadcast de la red cuando se usa difusión. Los equipos pueden ocupar cualquier valor intermedio, de .129 a .190.

Cómo una máscara decide qué es local

Cuando un equipo quiere enviar un paquete, compara su propia red con la red del destino. Si ambas coinciden, entrega el paquete directamente en el segmento local, resolviendo la dirección física mediante ARP. Si no coinciden, lo envía a la puerta de enlace predeterminada, que se encargará de enrutarlo.

Un router doméstico ilustra bien la idea. El proveedor asigna una única dirección pública al router, y este reparte direcciones privadas a portátiles, teléfonos y televisores, normalmente dentro de un bloque como 192.168.1.0/24. Un portátil con la dirección 192.168.1.101 sabe, gracias a la máscara, que una impresora en 192.168.1.103 está en su misma red, mientras que un servidor web en otro continente debe alcanzarse a través del router. La dirección pública del router, a su vez, forma parte de una subred del proveedor que comparte con otros clientes y que también se rige por su propia máscara.

El mismo razonamiento puede automatizarse:

import ipaddress

def es_local(origen: str, destino: str) -> bool:
    interfaz = ipaddress.ip_interface(origen)
    return ipaddress.ip_address(destino) in interfaz.network

print(es_local("192.168.50.77/27", "192.168.50.90"))
print(es_local("192.168.50.77/27", "192.168.50.100"))

True
False

Con un prefijo /27, la red de 192.168.50.77 abarca de .64 a .95. Por eso .90 es un vecino directo, mientras que .100 queda en otra subred aunque los tres primeros octetos sean idénticos. Este detalle es una fuente clásica de confusión para quien asume que todo lo que comparte los primeros octetos está en la misma red.

Notación CIDR y su origen

CIDR significa Classless Inter-Domain Routing, enrutamiento entre dominios sin clases. Se introdujo en 1993 para frenar el agotamiento acelerado de direcciones IPv4 y contener el crecimiento de las tablas de enrutamiento de internet, dos problemas agravados por el rígido sistema de clases vigente hasta entonces.

CIDR aportó dos ideas centrales. La primera es la posibilidad de usar máscaras de longitud variable (VLSM), es decir, dividir una red en subredes de distinto tamaño y volver a subdividir esas subredes según se necesite, lo que reduce drásticamente el desperdicio. La segunda es la notación con barra, que expresa la máscara como el número de bits a 1 que contiene. Escribir 192.168.0.0/24 equivale a indicar la red 192.168.0.0 con la máscara 255.255.255.0, pero de forma mucho más compacta.

La notación también facilita la agregación de rutas, conocida como superredes. Cuatro redes contiguas como 10.1.0.0/24, 10.1.1.0/24, 10.1.2.0/24 y 10.1.3.0/24 pueden anunciarse como una sola ruta 10.1.0.0/22, lo que simplifica las tablas de los routers y acelera las búsquedas.

Calcular el prefijo a partir de una máscara

Para calcular la máscara de subred en formato CIDR basta con contar los unos de su representación binaria. La máscara 255.255.255.0 contiene tres octetos completos de unos, es decir, 24 bits, por lo que su prefijo es /24. La máscara 255.255.255.248 suma 24 bits de los tres primeros octetos más 5 del último (11111000), lo que da /29.

Python resuelve la conversión en ambas direcciones sin necesidad de contar a mano:

import ipaddress

mascaras = [
    "255.255.255.0",
    "255.255.255.192",
    "255.255.255.224",
    "255.255.255.248",
    "255.255.255.252",
]

for mascara in mascaras:
    prefijo = ipaddress.ip_network(f"0.0.0.0/{mascara}").prefixlen
    print(f"{mascara:<16} -> /{prefijo}")

255.255.255.0    -> /24
255.255.255.192  -> /26
255.255.255.224  -> /27
255.255.255.248  -> /29
255.255.255.252  -> /30

Al escribir una red en notación CIDR, la convención es usar la dirección de red y no la de un equipo concreto. La interfaz con dirección 192.168.0.101 y máscara 255.255.255.0 pertenece a la red 192.168.0.0/24. Escribir 192.168.0.101/24 es correcto para describir una interfaz, pero no para definir una red en una tabla de rutas o en una regla de firewall, donde algunas herramientas rechazarán el valor o lo normalizarán sin avisar.

Las subredes más usadas en el día a día

Aunque la tabla completa es útil como referencia, en la práctica unos pocos prefijos aparecen una y otra vez.

El /24 es el tamaño por defecto en redes domésticas y en muchas oficinas pequeñas: 254 equipos, frontera de red alineada con el tercer octeto y cálculos mentales triviales. Su popularidad lo convierte también en el punto de partida de casi cualquier diseño.

El /26 divide un /24 en cuatro bloques de 62 equipos, una opción equilibrada para separar departamentos, entornos o zonas de disponibilidad. El /27 ofrece 30 direcciones utilizables, adecuado para segmentos de servidores, redes de gestión o grupos reducidos de máquinas.

El /29 deja 6 direcciones útiles y es frecuente en bloques de IP públicas que los proveedores asignan a empresas pequeñas, así como en redes de tránsito con varios dispositivos. La subred /30 para enlaces punto a punto fue durante años el estándar entre dos routers, porque proporciona exactamente dos direcciones utilizables. Hoy muchos equipos aceptan /31 para ese mismo fin, lo que ahorra la mitad de las direcciones en redes con cientos de enlaces.

En el extremo opuesto, prefijos como /16 o /20 son habituales para definir el espacio completo de una VPC o de un centro de datos, que después se fragmenta en subredes más pequeñas.

Calcular subredes con Python y el módulo ipaddress

El módulo ipaddress forma parte de la biblioteca estándar de Python desde hace años, por lo que no requiere instalar nada. Los ejemplos de esta guía funcionan en Python 3.15, la versión estable más reciente al momento de escribir, y en cualquier versión 3 moderna.

El siguiente script obtiene todos los datos relevantes de un bloque:

import ipaddress

red = ipaddress.ip_network("10.40.8.0/22")
hosts = list(red.hosts())

print("Red:", red.network_address)
print("Broadcast:", red.broadcast_address)
print("Máscara:", red.netmask)
print("Wildcard:", red.hostmask)
print("Total de direcciones:", red.num_addresses)
print("Hosts utilizables:", red.num_addresses - 2)
print("Primer host:", hosts[0])
print("Último host:", hosts[-1])

Red: 10.40.8.0
Broadcast: 10.40.11.255
Máscara: 255.255.252.0
Wildcard: 0.0.3.255
Total de direcciones: 1024
Hosts utilizables: 1022
Primer host: 10.40.8.1
Último host: 10.40.11.254

Hay dos detalles importantes. El constructor ip_network es estricto por defecto: si se le pasa una dirección con bits de host activados, como 10.40.9.5/22, lanza un ValueError. Para normalizarla hay que añadir strict=False, o bien usar ip_interface, que representa una dirección concreta junto con su red. El segundo detalle es que hosts() excluye automáticamente red y difusión, y en un /31 devuelve las dos direcciones, en línea con el RFC 3021.

El módulo también resuelve tareas de diseño. El método subnets() divide una red, supernet() la agrega, overlaps() detecta solapamientos y collapse_addresses() fusiona bloques contiguos:

import ipaddress

oficina = ipaddress.ip_network("172.20.16.0/24")
for segmento in oficina.subnets(new_prefix=26):
    print(f"{segmento}  hosts: {segmento.num_addresses - 2}  rango: {segmento[1]} - {segmento[-2]}")

bloques = [ipaddress.ip_network(f"10.1.{i}.0/24") for i in range(4)]
print(list(ipaddress.collapse_addresses(bloques)))

172.20.16.0/26  hosts: 62  rango: 172.20.16.1 - 172.20.16.62
172.20.16.64/26  hosts: 62  rango: 172.20.16.65 - 172.20.16.126
172.20.16.128/26  hosts: 62  rango: 172.20.16.129 - 172.20.16.190
172.20.16.192/26  hosts: 62  rango: 172.20.16.193 - 172.20.16.254
[IPv4Network('10.1.0.0/22')]

En sistemas Linux, la herramienta de línea de comandos ip muestra el prefijo de cada interfaz, lo que permite verificar rápidamente la configuración real de una máquina:

ip -4 -brief address show

lo               UNKNOWN        127.0.0.1/8
eth0             UP             10.40.9.12/22

Subdividir una red y aplicar VLSM

Dividir un bloque en partes iguales es sencillo, pero rara vez refleja la realidad. Un departamento puede necesitar cien equipos y otro apenas veinte. VLSM resuelve este desajuste asignando a cada segmento el prefijo justo para sus necesidades.

El método clásico tiene tres pasos. Primero se ordenan las necesidades de mayor a menor. Después, para cada una, se busca el menor bloque cuya cantidad de direcciones, restando red y difusión, cubra los equipos requeridos. Por último, se asignan los bloques en orden, siempre alineados a su tamaño, partiendo del espacio libre restante.

Supongamos un bloque 10.50.0.0/24 que debe repartirse entre ventas (100 equipos), soporte (50), almacén (20) y un enlace WAN (2). El siguiente script automatiza el proceso:

import ipaddress
import math

def asignar_vlsm(bloque: str, necesidades: dict[str, int]) -> None:
    disponible = [ipaddress.ip_network(bloque)]
    for nombre, hosts in sorted(necesidades.items(), key=lambda x: -x[1]):
        prefijo = 32 - math.ceil(math.log2(hosts + 2))
        for i, libre in enumerate(disponible):
            if libre.prefixlen <= prefijo:
                elegida = next(libre.subnets(new_prefix=prefijo))
                disponible.pop(i)
                disponible[i:i] = list(libre.address_exclude(elegida))
                disponible.sort()
                print(f"{nombre:<12} {str(elegida):<18} hosts útiles: {elegida.num_addresses - 2}")
                break
        else:
            print(f"{nombre:<12} sin espacio suficiente")

asignar_vlsm("10.50.0.0/24", {
    "ventas": 100,
    "soporte": 50,
    "almacen": 20,
    "enlace-wan": 2,
})

ventas       10.50.0.0/25       hosts útiles: 126
soporte      10.50.0.128/26     hosts útiles: 62
almacen      10.50.0.192/27     hosts útiles: 30
enlace-wan   10.50.0.224/30     hosts útiles: 2

El resultado deja libre el rango de 10.50.0.228 a 10.50.0.255, espacio disponible para crecimiento futuro. Ordenar primero los segmentos más grandes es clave: si se asignara antes el enlace WAN al principio del bloque, el /25 de ventas ya no cabría alineado en la primera mitad y se fragmentaría el espacio sin necesidad.

El direccionamiento con clases y sus problemas

Antes de CIDR, cada dirección pertenecía a una clase determinada por sus primeros bits, y la clase fijaba de forma implícita la máscara.

Una red de clase A dedica un octeto a la red y tres al host, lo que permite más de 16.7 millones de equipos por red. Dentro de ese rango, el bloque 127.0.0.0/8 está reservado para loopback. La clase B reparte dos octetos para cada parte, con 16,384 redes posibles de 65,534 equipos cada una. La clase C ofrece algo más de dos millones de redes, pero de solo 254 equipos.

El problema era evidente. Una organización con mil dispositivos no cabía en una clase C, de modo que recibía una clase B con capacidad para más de 65 mil equipos, desperdiciando más del 98 % del bloque. Multiplicado por miles de organizaciones, ese desperdicio aceleró el agotamiento del espacio IPv4 y llenó las tablas de enrutamiento con rutas imposibles de agregar.

El sistema de clases se abandonó formalmente con la llegada de CIDR en 1993. Hoy su valor es sobre todo histórico y didáctico, aunque algunos términos sobreviven en el lenguaje cotidiano, por ejemplo cuando se habla de “una clase C” para referirse a un /24.

Rangos reservados y direcciones privadas

No todas las direcciones IPv4 son enrutables en internet. Varios bloques tienen usos especiales que conviene reconocer al diseñar o depurar una red.

Las redes privadas pueden reutilizarse en cualquier organización porque nunca se anuncian en internet; el tráfico sale al exterior a través de NAT. El rango 172.16.0.0/12 suele confundirse, ya que abarca de 172.16.0.0 a 172.31.255.255 y no solo el segundo octeto 16.

El módulo ipaddress ofrece propiedades para clasificar direcciones de forma rápida:

import ipaddress

for texto in ["10.20.30.40", "100.70.1.1", "8.8.8.8"]:
    ip = ipaddress.ip_address(texto)
    print(texto, "privada:", ip.is_private, "global:", ip.is_global)

10.20.30.40 privada: True global: False
100.70.1.1 privada: False global: False
8.8.8.8 privada: False global: True

La dirección del espacio CGNAT no es privada en el sentido del RFC 1918, pero tampoco es global, lo que refleja su naturaleza de espacio compartido entre operadores y clientes.

Subredes en la nube: el caso de AWS VPC

Los proveedores de nube aplican sus propias reglas sobre el direccionamiento clásico. En Amazon VPC, una subred IPv4 debe tener un tamaño entre /16 y /28, y AWS reserva cinco direcciones de cada subred: las cuatro primeras y la última. En un bloque 10.0.0.0/24, por ejemplo, quedan reservadas la dirección de red, la del router de la VPC, la del servicio DNS, una adicional para uso futuro y la última del rango.

La consecuencia práctica es que un /28 en AWS ofrece 11 direcciones utilizables en lugar de 14, y un /24 ofrece 251 en lugar de 254. Si una carga de trabajo necesita 29 instancias, un /27 no basta, porque tras las reservas solo quedan 27 direcciones libres. Además, el bloque de una subred no puede modificarse una vez creada, por lo que un error de dimensionado obliga a crear otra subred y migrar recursos.

Una estrategia habitual para planificar el direccionamiento IP en la nube consiste en asignar un /16 a cada VPC y dividirlo en subredes por zona de disponibilidad y por función, por ejemplo públicas para balanceadores y privadas para aplicaciones y bases de datos. También es fundamental evitar solapamientos con redes locales y con otras VPC, ya que el emparejamiento y las conexiones VPN no admiten rangos que se superpongan.

Errores comunes al diseñar subredes

Uno de los fallos más frecuentes es confundir dirección de host con dirección de red. Definir una regla de firewall o una ruta con 10.40.9.5/22 puede provocar errores de validación o comportamientos inesperados según la herramienta. La red correcta es 10.40.8.0/22.

Otro error típico es asumir que los primeros octetos determinan la pertenencia a una red. Como se vio antes, 192.168.50.90 y 192.168.50.100 comparten tres octetos, pero con un /27 están en subredes distintas.

También es común quedarse corto en el dimensionado. Elegir un /27 para un clúster de contenedores que asigna una IP a cada pod agota el espacio en cuanto la aplicación escala. En entornos dinámicos conviene calcular el consumo máximo previsto y añadir un margen generoso.

El solapamiento de rangos es otro clásico. Dos subredes como 10.16.0.0/24 y 10.16.0.128/25 comparten direcciones, y los sistemas de enrutamiento tratarán el tráfico de forma impredecible. La función overlaps() del módulo ipaddress permite detectarlo antes de aplicar la configuración.

Por último, muchas incidencias nacen de máscaras inconsistentes entre equipos del mismo segmento. Si un servidor usa /24 y su vecino /25, uno de ellos considerará remota una dirección que el otro trata como local, y las respuestas viajarán por caminos distintos.

Buenas prácticas para planificar el direccionamiento

Documentar el plan de direcciones es el primer paso. Una hoja de cálculo o, mejor aún, una herramienta de gestión de direcciones IP (IPAM) evita asignaciones duplicadas y facilita las auditorías.

Reservar espacio para crecer ahorra migraciones costosas. Una práctica razonable es dejar libres bloques contiguos junto a cada subred asignada, de modo que puedan agregarse más adelante sin fragmentar el plan.

Alinear las subredes a fronteras de potencias de dos simplifica la agregación de rutas y reduce el tamaño de las tablas. Asignar, por ejemplo, un /20 por región y /24 por entorno dentro de cada región produce un esquema jerárquico fácil de leer y de resumir.

Separar por función y nivel de confianza mejora la seguridad. Las subredes de gestión, aplicaciones, datos y acceso público deberían estar diferenciadas para aplicar políticas de filtrado específicas.

Automatizar la validación cierra el círculo. Integrar comprobaciones con ipaddress en los pipelines de infraestructura como código permite rechazar solapamientos, prefijos fuera de rango o redes mal normalizadas antes de que lleguen a producción.

Solución de problemas de conectividad relacionados con la máscara

Cuando dos equipos del mismo segmento no se comunican, conviene revisar primero la configuración de cada interfaz con ip -4 address en Linux o ipconfig en Windows, comparando prefijos y redes. Una máscara distinta en uno de los extremos es causa frecuente de comunicación asimétrica.

Si un equipo alcanza su red local pero no internet, el problema suele estar en la puerta de enlace. Esta debe pertenecer a la misma subred que la interfaz; una gateway fuera del rango de la máscara hará que el sistema no pueda resolverla mediante ARP. La tabla de rutas, consultable con ip route, muestra qué red se considera conectada directamente y hacia dónde se envía el resto del tráfico.

Una dirección del rango 169.254.0.0/16 en una interfaz indica que el equipo no obtuvo respuesta de un servidor DHCP y se asignó una dirección de enlace local. En ese caso, el problema no está en la máscara sino en la disponibilidad del servicio DHCP o en la conectividad física.

En entornos de nube, los errores al crear subredes suelen deberse a prefijos fuera del rango permitido, bloques que no pertenecen al espacio de la VPC o solapamientos con subredes existentes. Revisar el mensaje de error y contrastarlo con el plan de direcciones suele bastar para identificar la causa.

Conclusiones

Las máscaras de subred y la notación CIDR son la base sobre la que se construye cualquier red IPv4, desde una red doméstica hasta la infraestructura de una plataforma en la nube. Entender que una dirección es un número de 32 bits, que la máscara separa la parte de red de la de host y que cada bit del prefijo duplica o divide el tamaño de un bloque permite razonar sobre configuraciones complejas sin depender de calculadoras externas.

La tabla de referencia sirve para consultas rápidas, pero el verdadero valor está en saber derivarla: contar bits, aplicar operaciones AND y anticipar cuántas direcciones quedan disponibles tras las reservas de cada entorno. Con el módulo ipaddress de Python, esas operaciones se vuelven reproducibles y fáciles de integrar en scripts de automatización y validación.

El sistema de clases explica por qué se adoptó CIDR, mientras que VLSM, la agregación de rutas y una planificación cuidadosa permiten aprovechar al máximo un espacio IPv4 cada vez más escaso. Dimensionar con margen, evitar solapamientos y documentar cada asignación son hábitos que previenen buena parte de las incidencias de red que llegan a producción.