Subredes

Supongamos que una empresa dispone de varias oficinas, cada una con una red local, todas ellas
interconectadas entre sí, y que desea unirlas mediante el protocolo TCP/IP; una de dichas oficinas (la
principal) dispone además de una conexión a Internet. Supongamos también cada oficina tiene suficiente
con 254 direcciones de hosts. En principio sería posible asignar una red clase C diferente para cada
oficina, pero esto supone solicitar al NIC una red para cada oficina que se conecte, y al ser cada una
independiente de las demás la gestión se complica; por ejemplo sería preciso anunciar en Internet la ruta
para cada nueva red para que la oficina correspondiente fuera accesible. Dado que cada red sería en
principio independiente de las demás no habría una forma sencilla de agrupar las redes de la organización.

Hay un mecanismo que permite dividir una red IP en trozos o subredes, de forma que la empresa de
nuestro ejemplo podría solicitar una clase B y asignar fragmentos de dicha red a cada oficina a medida
que se fueran incorporando a la red. Esto equivale a crear un nivel jerárquico intermedio entre la red y el
host, permitiendo así grados variables de agrupación según el nivel en el que nos encontramos.
Supongamos que a la empresa de nuestro ejemplo se le asigna una red clase B, la 156.134.0.0; de los 16
bits que en principio corresponden al host podría reservar los primeros 8 para la subred y dejar los 8
siguientes para el host, con lo que dispondrá de 256 subredes de 256 direcciones cada una. Desde fuera la
red de la empresa seguirá siendo 156.134.0.0, ya que la estructura de subred no será visible.

Las subredes se añadieron a la Internet en 1982; con ello se consiguió una mayor flexibilidad en el reparto
de direcciones dentro de una red.

Para dividir la red en subredes se define una nueva máscara. Como siempre los bits a 1 de la máscara
identifican la parte de red (en este caso la parte de red-subred) y los bits a cero corresponden al host. Por
ejemplo, la máscara 255.255.255.0 aplicada sobre una red clase B la divide en 256 subredes de 256
direcciones cada una, pues tiene puestos a 1 los primeros 24 bits; en cierto modo podríamos decir que esta
máscara convierte una red clase B en 256 subredes clase C. Se pueden hacer divisiones que no
correspondan a bytes enteros, por ejemplo la máscara 255.255.252.0 hace subredes mas grandes, reserva
los primeros 6 bits para la subred y deja 10 para el host, con lo que podría haber hasta 64 subredes con
1024 direcciones cada una.

Cuando se crean subredes hay dos direcciones en cada subred que quedan automáticamente reservadas:
las que corresponden al campo host todo a ceros y todo a unos; estas se emplean para designar la subred y
para broadcast dentro de la subred, respectivamente. Así si la red 156.134.0.0 se subdivide con la máscara
255.255.255.0 se crean 256 subredes del tipo 156.134.subred.host, cada una con 256 direcciones. En cada
subred hay 254 direcciones aprovechables para hosts, ya que la primera dirección (156.134.subred.0)
identifica a la subred y la última (156.134.subred.255) es la dirección broadcast de esa subred. Por tanto
el número de hosts de una subred es siempre dos menos que el rango de direcciones que abarca. Una
consecuencia de lo anterior es que resulta absurdo crear subredes con la máscara 255.255.255.254, ya que
el campo host tendría un bit solamente y no quedaría ninguna dirección aprovechable para hosts.

Del mismo modo que los valores todo ceros o todo unos del campo host están reservados con un
significado especial, los valores todo ceros y todo unos del campo subred (es decir la primera y la última
subredes) también son especiales. El valor todo ceros se utiliza para representar la subred misma; por
ejemplo si a la red 156.134.0.0 le aplicamos la máscara 255.255.255.0 la primera subred (campo subred
todo a ceros) no debería utilizarse, pues resultaría ambiguo el significado de la dirección 156.134.0.0, que
representaría tanto a dicha subred como a la red entera. Análogamente la última subred (campo subred
todo a unos) tampoco debería utilizarse porque entonces la dirección 156.134.255.255 significaría tanto
broadcast en dicha subred como en la red entera. Por consiguiente en el campo subred también se pierden
siempre dos direcciones, y tampoco tendría sentido crear máscaras con el campo subred de un bit, como
sería el caso de una máscara 255.255.128.0 en el caso de una red clase B.

Mientras que la restricción de las direcciones todo ceros o todo unos en el campo host se ha de respetar
siempre, existen muchas situaciones en las que interesa aprovechar la subred toda a ceros o toda a unos,
violando la segunda norma antes mencionada. Esta violación, permitida por muchas implementaciones, se
conoce como subnet-zero y se adopta para aprovechar mejor el espacio de direcciones disponible; con
subnet-zero es posible por ejemplo dividir una red clase B por la mitad en dos subredes mediante la
máscara 255.255.128.0, cosa que no sería posible si no se permitiera esta pequeña 'infracción'.
En todos nuestros ejemplos la parte de subred de la máscara es contigua a la parte de red; en un principio
se permitía crear subredes con máscaras no contiguas, por ejemplo dividir una clase B con la máscara
255.255.0.255; en este caso el host vendría especificado por el tercer byte y la subred por el cuarto. Dado
que esta práctica solo resta claridad y hace menos eficiente el proceso de direcciones en los routers,
actualmente la norma exige que la máscara sea contigua.

Para terminar de clarificar la creación de subredes y el uso de máscaras resumimos en la tabla 3.5 todas
las posibles subredes y máscaras que se pueden utilizar con una red clase B. En el caso de una red clase C
las posibles subredes y máscaras son las que se recogen en la tabla 3.6.

Bits de Número de Nº subredes Bits de host Número de Máscara

subred subredes (subred cero) hosts
0 0 0 16 65534 255.255.0.0
1 0 2 15 32766 255.255.128.0
2 2 4 14 16382 255.255.192.0
3 6 8 13 8190 255.255.224.0
4 14 16 12 4094 255.255.240.0
5 30 32 11 2046 255.255.248.0
6 62 64 10 1022 255.255.252.0
7 126 128 9 510 255.255.254.0
8 254 256 8 254 255.255.255.0
9 510 512 7 126 255.255.255.128
10 1022 1024 6 62 255.255.255.192
11 2046 2048 5 30 255.255.255.224
12 4094 4096 4 14 255.255.255.240
13 8190 8192 3 6 255.255.255.248
14 16382 16384 2 2 255.255.255.252
15 32766 32768 1 0 255.255.255.254
16 65534 65536 0 0 255.255.255.255

Tabla 3.5.- Subredes y máscaras que pueden definirse en una red clase B

Bits de Número de Nº subredes Bits de host Número de Máscara

subred subredes (subred cero) hosts
0 0 0 8 254 255.255.255.0
1 0 2 7 126 255.255.255.128
2 2 4 6 62 255.255.255.192
3 6 8 5 30 255.255.255.224
4 14 16 4 14 255.255.255.240
5 30 32 3 6 255.255.255.248
6 62 64 2 2 255.255.255.252
7 126 128 1 0 255.255.255.254
8 254 256 0 0 255.255.255.255

Tabla 3.6.- Subredes y máscaras que pueden definirse en una red clase C

La división en subredes no ha de hacerse necesariamente de forma homogénea en todo el espacio de

direcciones, como hemos hecho hasta ahora. Supongamos que la empresa de nuestro ejemplo anterior
tiene una serie de oficinas pequeñas que tienen bastante con subredes de 256 direcciones, pero otras mas
grandes requieren un número mayor; podríamos partir la red en 256 subredes de 256 hosts y asignar
varias de esas subredes a las oficinas mayores, pero esto complicaría la gestión y las tablas de rutas. La
solución más adecuada en este caso sería dividir la red en subredes de diferentes tamaños y asignar a cada
oficina una subred adecuada a sus necesidades. Asi en nuestro ejemplo se podría dividir la red
156.134.0.0 de la siguiente manera:
 16 subredes de 256 direcciones:

Subred Máscara Subred/bits de máscara

156.134.0.0 255.255.255.0 156.134.0.0/24
156.134.1.0 255.255.255.0 156.134.1.0/24
156.134.2.0 255.255.255.0 156.134.2.0/24
156.134.3.0 255.255.255.0 156.134.3.0/24
156.134.4.0 255.255.255.0 156.134.4.0/24
156.134.5.0 255.255.255.0 156.134.5.0/24
156.134.6.0 255.255.255.0 156.134.6.0/24
156.134.7.0 255.255.255.0 156.134.7.0/24
156.134.8.0 255.255.255.0 156.134.8.0/24
156.134.9.0 255.255.255.0 156.134.9.0/24
156.134.10.0 255.255.255.0 156.134.10.0/24
156.134.11.0 255.255.255.0 156.134.11.0/24
156.134.12.0 255.255.255.0 156.134.12.0/24
156.134.13.0 255.255.255.0 156.134.13.0/24
156.134.14.0 255.255.255.0 156.134.14.0/24
156.134.15.0 255.255.255.0 156.134.15.0/24

16 subredes de 1024 direcciones

Subred Máscara Subred/bits de máscara

156.134.16.0 255.255.252.0 156.134.16.0/22
156.134.20.0 255.255.252.0 156.134.20.0/22
156.134.24.0 255.255.252.0 156.134.24.0/22
156.134.28.0 255.255.252.0 156.134.28.0/22
156.134.32.0 255.255.252.0 156.134.32.0/22
156.134.36.0 255.255.252.0 156.134.36.0/22
156.134.40.0 255.255.252.0 156.134.40.0/22
156.134.44.0 255.255.252.0 156.134.44.0/22
156.134.48.0 255.255.252.0 156.134.48.0/22
156.134.52.0 255.255.252.0 156.134.52.0/22
156.134.56.0 255.255.252.0 156.134.56.0/22
156.134.60.0 255.255.252.0 156.134.60.0/22
156.134.64.0 255.255.252.0 156.134.64.0/22
156.134.68.0 255.255.252.0 156.134.68.0/22
156.134.72.0 255.255.252.0 156.134.72.0/22
156.134.76.0 255.255.252.0 156.134.76.0/22

3 subredes de 4096 direcciones:

Subred Máscara Subred/bits de máscara

156.134.80.0 255.255.240.0 156.134.80.0/20
156.134.96.0 255.255.240.0 156.134.96.0/20
156.134.112.0 255.255.240.0 156.134.112.0/20

Y por último una subred de 32768 direcciones:

Subred Máscara Subred/bits de máscara

156.134.128.0 255.255.128.0 156.134.128.0/17

La técnica que hemos aplicado en el ejemplo anterior de dividir una red en subredes de diferentes
tamaños se conoce comúnmente como máscaras de tamaño variable. Obsérvese que en este ejemplo
hemos seguido la práctica de subnet-zero, es decir, se han considerado válidas subredes con el campo
subred todo a ceros y todo a unos, de lo contrario no habría sido posible crear una subred con 32768
direcciones. Obsérvese en la columna de la derecha el uso de la notación subred/bits de máscara para
representar las subredes; esta notación abreviada está sustituyendo en algunos casos a la tradicional y se
emplea en la configuración de algunos equipos, en RFCs y otros documentos.

Cuando el campo subred ocupa bytes enteros es trivial la identificación de subredes. Las cosas se
complican un poco más cuando no es así, por ejemplo en el caso anterior la primera subred de 1024
direcciones abarca un bloque de cuatro valores en el tercer byte, del 16 al 19; los bloques han de empezar
en valores múltiplo de cuatro, si en vez de empezar en el 16 hubiéramos empezado en el 15 (15, 16, 17 y
18) no habría sido posible crear una subred pues la dirección 156.134.15.0 no tiene una máscara de 22
bits común con las otras tres; por consiguiente las subredes formadas con máscara de 22 bits (grupos de
cuatro números) necesariamente han de empezar en valores múltiplos de cuatro (0, 4, 8, etc.).
Análogamente puede deducirse que las subredes de máscara de 20 bits (4096 direcciones) han de empezar
en valores múltiplos de 16, y así sucesivamente.

Superredes: Routing classless (CIDR)

El rápido crecimiento de la Internet está creando varios problemas, el más importante de los cuales es el
agotamiento del espacio de direcciones IP. La causa de esto ha sido en parte la excesiva disparidad de
tamaños entre las diferentes clases de redes. Hace ya mucho tiempo que han dejado de asignarse redes
clase A, debido a su escaso número y tamaño excesivo. Las organizaciones tenían pues que elegir entre
solicitar una clase B o una clase C. En muchos casos una clase B era excesiva, pero una C resultaba
insuficiente, por lo que la mayoría de las organizaciones optaban por solicitar una clase B, aunque a
menudo no necesitaban tantas direcciones. A la vista del rápido agotamiento de redes clase B debido a
este motivo se pensó en crear grupos de clases C, de forma que las organizaciones pudieran optar por
niveles intermedios entre las redes B y C, más adecuados a sus necesidades; por ejemplo una
organización que necesite 2048 direcciones puede hoy en día solicitar un grupo de ocho redes clase C .
De esta forma se reduce el problema de escasez de direcciones, pero se crea un problema nuevo: el
crecimiento de las tablas de rutas. Antes, cuando a una organización que se conectaba a Internet se le
asignaba una red esto suponía una nueva entrada en las tablas de rutas de Internet, pero al dar grupos de
clases C se requiere una entrada diferente para cada red asignada. Esto habría provocado un crecimiento
exponencial en las tablas de rutas de los routers que forman el ‘backbone’, cuyas capacidades se
encuentran ya bastante cerca del límite de la tecnología.

El gran tamaño de las tablas de rutas de Internet se debe también al mecanismo de asignación de
direcciones que se ha seguido, que durante mucho tiempo ha sido estrictamente cronológico. Al no haber
una correspondencia entre la ubicación geográfica de una organización o el proveedor que la conecta a
Internet y su rango de direcciones no es posible resumir o ‘sumarizar’ las tablas de rutas; la información
se ha de incluir enumerando una a una todas las redes existentes. Esto se podría resolver con una
organización jerárquica de direcciones de acuerdo con criterios geográficos, como ocurre por ejemplo en
el direccionamiento de la red telefónica que identifica a cada país con prefijo, cada región dentro de un
país con un subprefijo, y así sucesivamente.

Actualmente hay mas de 100.000 redes registradas en la Internet. Además del costo en memoria RAM
que supone el mantener tablas extremadamente grandes en los routers, los algoritmos de búsqueda se
complican y no funcionan adecuadamente con esas tablas, ya que fueron diseñados pensando en tablas
con muchas menos entradas. A principios de los 90 el crecimiento de la Internet se estaba produciendo a
un ritmo tal que el número de redes conectadas se duplicaba cada 9 meses, mientras que la tecnología sólo
permite duplicar la capacidad y potencia de los routers cada 18 meses. En esta situación la explosión de
las tablas de routing se estaba convirtiendo en un problema aún más grave que la escasez de direcciones.
Según cálculos hechos por la IETF en 1993 de seguir produciéndose el crecimiento al mismo ritmo en el
número de redes y rutas la Internet se habría colapsado hacia 1998.

Los dos problemas antes descritos, desperdicio del espacio de direcciones debido a la rigidez en la
asignación de rangos (redes clase B o C) y crecimiento de las tablas de rutas, se resolvieron
conjuntamente en 1993 con la adopción de un sistema denominado CIDR (Classless InterDomain
Routing) descrito en los RFCs 1466, 1518 y 1519 que consiste en dos medidas complementarias.
La primera medida consiste en establecer una jerarquía en la asignación de direcciones. En vez de utilizar
un criterio puramente cronológico, que desde le punto de vista geográfico o de topología de la red
equivale a una asignación aleatoria, los rangos se asignan por continentes. Inicialmente se realizó la
asignación de una parte del espacio de clase C de la siguiente manera:

Multi regional: 192.0.0.0 - 193.255.255.255

Europa: 194.0.0.0 - 195.255.255.255
Otros: 196.0.0.0 - 197.255.255.255
Noteamérica: 198.0.0.0 - 199.255.255.255
Centro y Sudamérica: 200.0.0.0 - 201.255.255.255
Anillo Pacífico: 202.0.0.0 - 203.255.255.255
Otros: 204.0.0.0 - 205.255.255.255
Otros: 206.0.0.0 - 207.255.255.255

Algunos de estos grupos se han ampliado posteriormente con nuevos rangos. A su vez cada proveedor
Internet solicita rangos propios al NIC que le corresponde según el continente donde se encuentra. Con
esta distribución regional de los números es en principio posible agrupar las entradas en las tablas de
rutas; por ejemplo un router en Japón podría tener una sola entrada en sus tablas indicando que todos los
paquetes dirigidos a las redes 194.0.0.0 hasta 195.255.255.0 se envíen a la interfaz por la cual accede a
Europa, evitando así las 131.072 entradas que normalmente harían falta para este rango de direcciones.

Una consecuencia curiosa de la asignación de rangos de direcciones por proveedor es que si una empresa
cambia de proveedor normalmente tendrá que 'devolver' al primero sus direcciones, y solicitar direcciones
al nuevo proveedor; por supuesto tendrá que modificar la configuración de todas las máquinas que tuviera
utilizando direcciones del primero.

Para que la sumarización de rutas (o agrupamiento de redes clase C) sea posible es preciso introducir una
ligera modificación en el software de los routers, ya que en principio el software no considera el rango
194.0.0.0–195.255.255.255 como una sola red sino como 131.072 redes clase C. Para resolver este
problema se ha extendido el concepto de subred en sentido contrario, es decir la máscara no solo puede
crecer hacia la derecha para dividir una red en subredes sino que puede menguar hacia la izquierda para
agrupar varias redes en una mayor (de ahí la denominación de ‘superredes’). Dicho de otra forma, la parte
red de la dirección vendrá especificada por la longitud de la máscara únicamente, no teniendo ya ningún
significado la clasificación tradicional en clases A, B y C de acuerdo con el valor de los primeros bits;
solo se repeta dicho significado en el caso de las clases D (multicast) y E (reservado). Dicha supresión de
las clases tradicionales es lo que da nombre a esta técnica conocida como enrutamiento entre dominios
sin clases o CIDR (Classless InterDomain Routing).

La segunda medida adoptada por CIDR es en realidad un complemento de la anterior. Consiste

sencillamente en dar a cada organización (bien directamente o a través de su proveedor correspondiente)
la posibilidad de solicitar rangos de direcciones ajustado a sus necesidades previstas, dándole siempre un
rango contiguo y que tenga una máscara de red común; por ejemplo un rango de 2048 direcciones se daría
asignando los primeros 21 bits de la dirección y podría estar formado por ejemplo por el rango que va del
194.0.8.0 al 194.0.15.255.

Supongamos que la Universidad de Málaga solicita a su proveedor direcciones de red y justifica la

previsión de tener 1200 hosts en un plazo razonable; como 1024 direcciones no serían suficientes su
proveedor le asigna 2048 direcciones, equivalentes a ocho redes clase C. Supongamos que el proveedor
tiene disponible el rango 195.100.0.0 a 195.100.255.255 y que ha ido asignando direcciones a sus clientes
por orden cronológico, quedándole libre a partir de la 195.100.12.0; no es posible asignar a la
Universidad de Málaga de la 195.100.12.0 a la 195.100.19.255 ya que aunque el rango es contiguo las
direcciones no tienen una máscara común (los primeros 21 bits no son iguales). El primer rango de 2048
direcciones con máscara común es el 195.100.16.0-195.100.23.255, que es el que se deberá asignar. Las
direcciones 195.100.12.0 a 195.100.15.255 quedarían libres para otros clientes con menores necesidades.
Con esta asignación de direcciones y sin utilizar CIDR el aspecto de la tabla de rutas para la Universidad
de Málaga sería por ejemplo:

A 195.100.16.0/24 por 192.168.1.2

A 195.100.17.0/24 por 192.168.1.2
A 195.100.18.0/24 por 192.168.1.2
A 195.100.19.0/24 por 192.168.1.2
A 195.100.20.0/24 por 192.168.1.2
A 195.100.21.0/24 por 192.168.1.2
A 195.100.22.0/24 por 192.168.1.2
A 195.100.23.0/24 por 192.168.1.2

donde se supone que 192.168.1.2 es la interfaz por la que se accedería a la Universidad de Málaga.

El uso de CIDR permite sintetizar estas ocho entradas en una sola:

A 195.100.16.0/21 por 192.168.1.2

El software de hosts normalmente no soporta CIDR, por lo que éstos siguen ‘pensando’ en términos de
redes clase A, B y C. Por tanto cuando dos hosts de la misma organización ubicados en redes clase C
diferentes desean intercambiar tráfico han de hacer uso del router para iniciar el diálogo.

El espacio de redes clase A, que suponen la mitad del espacio total, está asignado actualmente sólo en un
50% aproximadamente. Está prevista la posibilidad de dividir cuando sea necesario la parte no utilizada
de este rango de direcciones en redes de menor tamaño para su asignación mediante CIDR, igual que se
hace actualmente con el rango 192.0.0.0-207.255.255.255.

La aplicación de CIDR ha permitido extender considerablemente la vida prevista inicialmente del espacio
de direcciones de 32 bits de IPv4.