Máscara de subred: guía práctica con tabla CIDR, ejemplos y errores comunes

Qué es la máscara de subred y para qué sirve (con ejemplos simples)

Una máscara de subred es el “filtro” que separa la parte de red y la parte de host de una dirección IP. Cuando un equipo decide si un destino es “de mi red” o “tengo que salir por la pasarela”, lo hace aplicando un AND lógico entre su IP y la máscara, y comparando el resultado con el AND de la IP destino y esa misma máscara.

Ejemplo rápido en /24:

• Mi IP: 192.168.10.25

• Máscara: 255.255.255.0 (/24)

• Destino A: 192.168.10.80 → mismo prefijo (192.168.10.0), es local.

• Destino B: 192.168.12.50 → prefijo distinto, va por gateway.

Piensa en la máscara como una plantilla: los bits “1” fijan la red; los bits “0” quedan para hosts. En /24 hay 24 bits de red y 8 de hosts. Cambiar la máscara cambia el alcance de quién es “vecino” en L3: en varios hilos de foros he visto a gente “arreglar” un problema de alcance al pasar de /24 a /22 porque necesitaban que dos equipos se vieran sin pasar por router. El “arreglo” funciona… pero conviene planificar: ampliar demasiado puede traer más broadcast y más superficie de fallo.

Otra confusión muy común que veo repetida en comentarios es mezclar “clases” (A/B/C) con máscaras modernas. Olvida las clases para el día a día: lo operativo es pensar en prefijos (/x). Decir “255.255.255.0” o “/24” es equivalente, pero trabajar con /x te obliga a pensar en el número de hosts y subredes que necesitas.

Qué te llevas de esta sección

• La máscara decide local vs. gateway mediante AND.

• Cambiarla altera el dominio de capa 3 y, por tanto, quién se “alcanza” sin enrutamiento.

• Habla en /x: te será más fácil calcular y evitar errores de diseño.

Cómo leer CIDR y convertirlo a máscara (y viceversa)

CIDR expresa cuántos bits fijos pertenecen a la red: /x significa “x bits a 1”. Para convertir:

1. Escribe x unos y (32−x) ceros:

• /26 → 11111111.11111111.11111111.11000000

2. Trocea en octetos y pasa cada octeto a decimal:

• 11111111 → 255

• 11000000 → 192

• Resultado: /26 = 255.255.255.192

La vuelta (máscara → /x) es sumar cuántos bits a 1 tiene la máscara.

• 255.255.252.0 → (11111111 + 11111111 + 11111100 + 00000000) = /22

Direcciones totales y utilizables

• Direcciones totales por subred: 2^(32−x)

• Utilizables (en redes tradicionales): 2^(32−x) − 2 (se reservan red y broadcast).
  En enlaces punto a punto modernos, con /31 no se resta 2 porque no hay broadcast clásico; más abajo te explico cuándo conviene.

En foros técnicos suele aparecer otro tema: la máscara comodín (wildcard), muy usada en ACLs. Es el inverso de la máscara:

• Máscara 255.255.255.192 → comodín 0.0.0.63
  Saber calcularla a ojo te ahorra tiempo con listas de control.

Tabla rápida CIDR ↔ máscara ↔ hosts (referencia)

Pongo un extracto de la tabla más usada. Si quieres, preparo la tabla completa /32→/0 en un archivo descargable.

* En redes “clásicas” con red/broadcast reservado.
** /31 es un caso especial y se usa de forma segura solo en enlaces punto a punto; lo detallo ahora.

Un patrón que he leído mucho en comentarios de administradores es guardar esta mini-tabla mental: /30=2 hosts, /29=6, /28=14, /27=30, /26=62, /24=254. Interiorizar esos hitos te acelera el diseño.

/30 vs /31: cuándo usar cada uno (RFC 3021 explicado)

/30 (255.255.255.252) da 4 direcciones totales: red, 2 hosts, broadcast. Perfecto para enlaces entre routers cuando no quieres líos con compatibilidades y herramientas de laboratorio.

/31 (255.255.255.254) asigna exactamente dos direcciones y no usa broadcast. Está pensado para enlaces punto a punto reales (un extremo y otro, sin nadie más). Ventajas:

• Ahorras IPv4 (crítico si el pool es pequeño o público).

• Simplifica la numeración de troncales y uplinks.

Precauciones (recogidas una y otra vez en hilos de comunidad):

• No lo uses en medios donde pueda haber más de dos extremos (Ethernet compartida, túneles multipunto).

• Algunas herramientas de simulación o equipos antiguos no aceptan /31; en laboratorios he visto a mucha gente rendirse y usar /30 por compatibilidad (por ejemplo, versiones viejas de Packet Tracer).

• En entornos mixtos (routers modernos + hosts raros) valida primero: si un equipo no entiende /31, perderás conectividad.

Regla práctica

• Enlace P2P entre routers modernos: /31.

• Laboratorio, demo, o dudas de compatibilidad: /30.

• Segmentos con switches y potencial de terceros: /30 o más grande, nunca /31.

Diseño de subredes con VLSM: método rápido y plantillas

VLSM (Variable Length Subnet Mask) es repartir un bloque en subredes de tamaños distintos según necesidades reales. Mi receta rápida:

1. Lista de necesidades (ordenadas de mayor a menor):

   • Servidores (80 hosts), CCTV (30), gestión (10), invitados (50), enlace P2P (2), administración (6)…

2. Elige bloque base (p. ej., 192.168.50.0/24 para una pyme).

3. Asigna primero lo grande para evitar fragmentación:

   • 80 hosts → /25 (126 utilizables) → 192.168.50.0/25

   • 50 hosts → /26 (62 util.) → 192.168.50.128/26

   • 30 hosts → /27 (30 util.) → 192.168.50.192/27 (justito, ojo a crecimiento)

   • 10 hosts → /28 (14 util.) → 192.168.50.224/28

   • 6 hosts → /29 (6 util.) → 192.168.50.240/29

   • P2P → /31 → 192.168.50.248/31 (o /30 si lo prefieres)

4. Documenta: diagrama, tabla de VLAN↔subred, gateway, DHCP, exclusiones, ACLs.

5. Reserva margen: deja un par de subredes libres para crecimiento (otro /28 y un /27, por ejemplo).

Un consejo que aparece en blogs y foros: aplica nombres y etiquetas coherentes (VLAN_50_SERV, VLAN_60_GUEST…), y mantén una hoja con “quién anuncia qué” si usas routing dinámico. Varias personas comentan que el mayor dolor no es el cálculo, sino la documentación; concuerdo al 100%.

Errores comunes de máscara (y cómo diagnosticarlos en minutos)

1. Máscaras disparejas en la misma red.
   Si dos hosts que deberían verse usan máscaras distintas (/24 vs /23), el que “cree” que el otro está en su red no enruta al gateway, y el que no lo cree sí enruta… resultado: pings unidireccionales. Diagnóstico: revisa IP/máscara/gateway en ambos.
   He leído decenas de casos así en foros de helpdesk: el fix fue unificar máscara y, si hacía falta, agregar una ruta estática temporal para no perder acceso durante el cambio.

2. Broadcasts gigantes por agrandar de más.
   Pasar de /24 a /22 puede “arreglar” alcance, pero sube el ruido y los dominios de fallo. Mejor segmentar con VLSM y enrutamiento entre VLANs.

3. Asumir que /31 vale para todo.
   Repetido en hilos técnicos: /31 en un switch con más de dos nodos provoca confusión y fallos intermitentes. Mantén /31 solo para P2P.

4. Confundir máscara con comodín.
   En ACLs, 0 significa “coincide”, 1 significa “no me importa”. Muchos ejemplos online dejan claro que un comodín mal calculado abre más de lo debido.

5. Olvidar el gateway correcto.
   En varias preguntas de principiantes vi que todo estaba perfecto salvo la pasarela: host en 192.168.10.0/24 apuntando a 192.168.12.1. Sin gateway correcto, no hay milagros.

Checklist de diagnóstico (rápido):

• ipconfig/ifconfig → IP/máscara/gateway correctos y en el mismo prefijo.

• Ping al gateway.

• Ping a otro host local.

• Ping a IP externa (por número).

• DNS (si IP externa responde pero el nombre no).

• Si es enlace P2P: confirma si es /30 o /31 y si ambos extremos coinciden.

Casos reales: hogar, pyme y nubes (AWS VPC y normalización)

Hogar (router en bridge y equipos de mantenimiento)
Un patrón que he visto mucho: alguien quiere alcanzar el módem/ONT de la operadora en 192.168.100.1 pero su LAN es 192.168.1.0/24. Dos salidas:

• Añadir una ruta estática hacia 192.168.100.0/24 por la interfaz del router.

• O ampliar la máscara a /22 (si topológicamente todo está en el mismo segmento) para abarcar 192.168.0.0–192.168.3.255.
  La ruta estática suele ser más limpia; ampliar máscara es un “parche” que a veces funciona, pero produce dominios de broadcast más grandes.

Pyme (segmentación por roles y crecimiento)
Recomiendo partir de un /23 o /22 y segmentar con VLSM: servidores críticos con /26, usuarios con /24, invitados con /24 separado y políticas de firewall claras. En comentarios de admins, el tip recurrente es reservar bloques contiguos para áreas que crecen (soporte, IoT) y no mezclar invitados con producción ni por asomo.

Nube (AWS VPC)
En AWS el bloque de una VPC es, por ejemplo, 10.10.0.0/16 y las subredes suelen ser /24 o /26. La consola normaliza las subredes (te impide definiciones “raras” y exige prefijos dentro del supernet). La práctica frecuente que veo en comunidades cloud es:

• Subredes públicas /26 (ALB/NAT/Jump).

• Subredes privadas /24 para apps y datos.

• Crecimiento controlado: deja espacio para AZ extra y empareja subredes por zona.
  De nuevo, etiqueta y documenta; varios comentarios insisten en que el naming y la coherencia evitan sustos meses después.

Preguntas frecuentes sobre máscara de subred

¿Qué diferencia hay entre máscara, prefijo y comodín?
Máscara (255.255.255.0) y prefijo (/24) son formas equivalentes de expresar lo mismo; el comodín es su inverso (0.0.0.255) y se usa en ACLs/políticas.

¿Cuándo usar /31?
En enlaces punto a punto entre dispositivos que lo soporten. Si tienes dudas o hay equipos legacy, usa /30.

¿Cuántos hosts caben en X?
Aplica 2^(32−x) totales; restas 2 si no es /31 ni /32. Ej.: /26 → 64 totales, 62 utilizables.

¿Por qué cambiar la máscara a veces “arregla” la conectividad?
Porque amplías el dominio de capa 3, haciendo que dos IP que antes estaban “fuera” ahora sean “locales”. No es magia; es alcance.

¿CIDR por qué es mejor que clases?
Porque refleja la realidad actual (VLSM, rutas agregadas) y permite granularidad exacta según tus necesidades.

Conclusión

Dominar la máscara de subred es menos memorizar tablas y más entender el juego de bits y el alcance. Con el mapa mental de CIDR, la mini-tabla de tamaños y un proceso claro de VLSM, puedes diseñar redes que crecen sin dolores. Y cuando dudes entre /30 y /31, recuerda: contexto manda. La teoría dice una cosa; los comentarios de quienes lo pelean a diario recuerdan que la compatibilidad y el entorno real deciden.