Introducción
Este documento describe el uso de la subred cero y la subred de todo unos.
Prerequisites
Requirements
No hay requisitos específicos para este documento.
Componentes Utilizados
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Convenciones
Para obtener más información sobre las convenciones del documento, consulte Utilizar convenciones de formato para sugerencias técnicas y otro contenido.
Antecedentes
La división en subredes descompone una dirección de red dada en subredes menores. Junto con otras tecnologías como la traducción de direcciones de red (NAT) y la traducción de direcciones de puerto (PAT), permite un uso más eficiente del espacio de direcciones IP disponible y alivia en gran medida el problema del agotamiento de las direcciones. Las subredes tienen pautas que cubren el uso de la primera y la última subredes, conocidas como subred cero y subred de todo unos, respectivamente.
Subred Cero
Si una dirección de red se conecta en subredes, la primera subred obtenida después de la división en subredes de la dirección de red se llama subred cero.
Considere una dirección de la clase B, 172.16.0.0. De forma predeterminada, la dirección de Clase B 172.16.0.0 tiene 16 bits reservados para representar la parte del host, por lo que permite 65534 (216-2) direcciones de host válidas. Si la red 172.16.0.0/16 se divide en subredes porque toma prestados tres bits de la parte del host, se obtienen ocho (23) subredes. Esta tabla es un ejemplo que muestra las subredes obtenidas mediante la división en subredes de la dirección 172.16.0.0, la máscara de subred resultante, las direcciones de difusión asociadas y el rango de direcciones de host válidas.
Dirección de Subred |
Máscara de subnet |
Dirección de Broadcast |
Rango de Host Válido |
172.16.0.0 |
255.255.224.0 |
172.16.31.255 |
172.16.0.1 a 172.16.31.254 |
172.16.32.0 |
255.255.224.0 |
172.16.63.255 |
172.16.32.1 a 172.16.63.254 |
172.16.64.0 |
255.255.224.0 |
172.16.95.255 |
172.16.64.1 a 172.16.95.254 |
172.16.96.0 |
255.255.224.0 |
172.16.127.255 |
172.16.96.1 a 172.16.127.254 |
172.16.128.0 |
255.255.224.0 |
172.16.159.255 |
172.16.128.1 a 172.16.159.254 |
172.16.160.0 |
255.255.224.0 |
172.16.191.255 |
172.16.160.1 a 172.16.191.254 |
172.16.192.0 |
255.255.224.0 |
172.16.223.255 |
172.16.192.1 a 172.16.223.254 |
172.16.224.0 |
255.255.224.0 |
172.16.255.255 |
172.16.224.1 a 172.16.255.254 |
En el ejemplo anterior, la primera subred (subred 172.16.0.0/19) se denomina subred cero.
La clase de la red dividida en subredes y el número de subredes obtenidas después de la división en subredes no determinan la subred cero. Es la primera subred obtenida cuando se divide en subredes la dirección de red. Además, cuando se escribe el equivalente binario de la dirección de subred cero, todos los bits de subred (bits 14, 15, y 16 en este caso) son ceros. La subred cero también se conoce como subred de todo ceros.
Subred All-Ones
Cuando una dirección de red se divide en subredes, la última subred obtenida se llama subred de todo unos.
Con referencia al ejemplo anterior, la última subred obtenida al dividir en subredes la red 172.16.0.0 (subred 172.16.224.0/19) se denomina subred de todo unos.
La clase de la red dividida en subredes y el número de subredes obtenidas después de la división en subredes no determinan la subred de todo unos. Además, cuando escribe el equivalente binario de la dirección de subred de todo unos, todos los bits de subred (bits 14, 15 y 16 en este caso) son unos, de ahí el nombre.
Problemas con la subred cero y la subred todo uno
Tradicionalmente, se recomendaba encarecidamente que la subred cero y la subred de todo unos no se utilizaran para las direcciones IP. Basado en RFC 950, "Es útil preservar y ampliar la interpretación de estas direcciones especiales (de red y difusión) en redes con subredes. Esto significa que los valores de todos ceros y todos unos en el campo de subred no deben asignarse a subredes reales (físicas)." Esta es la razón por la que los ingenieros de red requeridos para calcular el número de subredes obtenidas cuando toma prestados tres bits calcularían 23-2 (6) y no 23 (8). El -2 sabe que la subred cero y la subred de todo unos no se utilizan tradicionalmente.
Problemas de subred cero
Se desaconsejó el uso de una subred cero para el direccionamiento IP debido a la confusión inherente a una red y una subred con direcciones no distinguibles.
Con referencia al ejemplo anterior, considere la dirección IP 172.16.1.10. Si calcula la dirección de subred asociada a esta dirección IP, la respuesta que encontrará es la subred 172.16.0.0 (subred cero). Observe que esta dirección de subred es idéntica a la dirección de red 172.16.0.0, que se creó en subredes en primer lugar, por lo que siempre que realice la creación de subredes, obtendrá una red y una subred (subred cero) con direcciones no distinguibles. Ésta era antes una fuente de gran confusión.
Antes de Cisco IOS® Software Release 12.0, los routers de Cisco, de forma predeterminada, no permitían que una dirección IP que pertenece a la subred cero se configurara en una interfaz. Sin embargo, si un ingeniero de red que trabaja con una versión de software de Cisco IOS anterior a la 12.0 encuentra seguro utilizar la subred cero, el comando ip subnet-zero en el modo de configuración global puede utilizarse para superar esta restricción. A partir de Cisco IOS Software Versión 12.0, los routers Cisco tienen ahora ip subnet-zero habilitada de forma predeterminada; no obstante, si el ingeniero de red piensa que no es seguro utilizar la subred cero, puede utilizar el comando no ip subnet-zero para restringir el uso de las direcciones de subred cero.
En las versiones anteriores a Cisco IOS Software Release 8.3, se utilizó el comando service subnet-zero.
Problemas de subred de todo uno
El uso de la subred de todo unos para el direccionamiento IP se ha desaconsejado en el pasado debido a la confusión inherente a una red y una subred con direcciones de difusión idénticas.
Con referencia al ejemplo anterior, la dirección de difusión de la última subred (subred 172.16.224.0/19) es 172.16.255.255, que es idéntica a la dirección de difusión de la red 172.16.0.0, que se conectó en subredes en primer lugar, por lo que siempre que realice la conexión en subredes obtendrá una red y una subred (subred de todo unos) con direcciones de difusión idénticas. En otras palabras, un ingeniero de redes podría configurar la dirección 172.16.230.1/19 en un router, pero si eso se hace, ya no puede diferenciar entre una transmisión de subred local (172.16.255.255 (/19)) y la difusión completa de Clase B (172.16.255.255(/16)).
Aunque ahora se puede utilizar la subred de todo unos, los errores de configuración pueden provocar problemas.
Nota: Consulte Cantidades de Host y Subred para obtener más detalles.
Para que tenga una idea de lo que puede suceder, tenga en cuenta lo siguiente:
Subred todo en uno mal configurada
Los routers 2 a 5 son routers de acceso que tienen, cada uno, varias conexiones asíncronas (o ISDN) entrantes. La red (192.168.1.0/24) se divide en cuatro partes para estos usuarios entrantes. Cada parte se asigna a uno de los routers de acceso. Además, las líneas asíncronas están configuradas p unnum e0. El router 1 tiene rutas estáticas que apuntan al router de acceso correcto, y cada router de acceso tiene puntos de ruta predeterminados en el router 1.
La tabla de ruteo del router 1 tiene la siguiente apariencia:
C 192.168.2.0/24 E0
S 192.168.1.0/26 192.168.2.2
S 192.168.1.64/26 192.168.2.3
S 192.168.1.128/26 192.168.2.4
S 192.168.1.192/26 192.168.2.5
Los routers de acceso poseen la misma ruta conectada para la Ethernet, la misma ruta predeterminada y varias rutas de host para sus líneas asíncronas (cortesía del Point-to-Point Protocol (PPP)).
Router 2 routing table: Router 3 routing table:
C 192.168.2.0/24 E0 C 192.168.2.0/24 E0
S 10.0.0.0/0 192.168.2.1 S 10.0.0.0/0 192.168.2.1
C 192.168.1.2/32 async1 C 192.168.1.65/32 async1
C 192.168.1.5/32 async2 C 192.168.1.68/32 async2
C 192.168.1.8/32 async3 C 192.168.1.74/32 async3
C 192.168.1.13/32 async4 C 192.168.1.87/32 async4
C 192.168.1.24/32 async6 C 192.168.1.88/32 async6
C 192.168.1.31/32 async8 C 192.168.1.95/32 async8
C 192.168.1.32/32 async12 C 192.168.1.104/32 async12
C 192.168.1.48/32 async15 C 192.168.1.112/32 async15
C 192.168.1.62/32 async18 C 192.168.1.126/32 async18
Router 4 routing table: Router 5 routing table:
C 192.168.2.0/24 E0 C 192.168.2.0/24 E0
S 10.0.0.0/0 192.168.2.1 S 10.0.0.0/0 192.168.2.1
C 192.168.1.129/32 async1 C 192.168.1.193/32 async1
C 192.168.1.132/32 async2 C 192.168.1.197/32 async2
C 192.168.1.136/32 async3 C 192.168.1.200/32 async3
C 192.168.1.141/32 async4 C 192.168.1.205/32 async4
C 192.168.1.152/32 async6 C 192.168.1.216/32 async6
C 192.168.1.159/32 async8 C 192.168.1.223/32 async8
C 192.168.1.160/32 async12 C 192.168.1.224/32 async12
C 192.168.1.176/32 async15 C 192.168.1.240/32 async15
C 192.168.1.190/32 async18 C 192.168.1.252/32 async18
¿Qué sucede si los hosts están configurados incorrectamente en las líneas asincrónicas para tener una máscara 255.255.255.0 en lugar de una máscara 255.255.255.192? Todo funciona bien?
Observe lo que ocurre cuando uno de estos hosts (192.168.1.24) hace un broadcast local (NetBIOS, WINS). El paquete tiene este aspecto:
s: 192.168.1.24 d: 192.168.1.255
El router 2 recibe el paquete. El router 2 lo envía al router 1, que lo envía al router 5, que lo envía al router 1, que lo envía al router 5, y así sucesivamente, hasta que caduque el tiempo de vida (TTL).
Este es otro ejemplo (host 192.168.1.240):
s: 192.168.1.240 d: 192.168.1.255
El router 5 recibe este paquete. El Router 5 lo envía al Router 1, que lo envía al Router 5, que lo envía al Router 1, que lo envía al Router 5, y así sucesivamente, hasta que caduca el TTL. Si se produce esta situación, podría pensar que estaba sufriendo un ataque de paquetes. Dada la carga del Router 5, esta sería una suposición razonable.
En este ejemplo, se ha creado un loop de ruteo. Debido a que el Router 5 maneja la subred de todo unos, se destruye. Los routers 2 a 4 ven el paquete "broadcast" una sola vez. El Router 1 también resulta afectado pero, ¿y si se trata de un Cisco 7513, que puede gestionar esta situación? En ese caso, necesita configurar sus hosts con la máscara de subred correcta.
Para protegerse contra hosts que no están configurados correctamente, cree una interfaz de loopback en cada router de acceso con una ruta estática 192.168.1.255 a la dirección de loopback. Puede utilizar la interfaz Null0, pero esto hace que el router genere mensajes "inalcanzables" del Protocolo de mensajes de control de Internet (ICMP).
Utilizar subred cero y subred todo uno
Debe tenerse en cuenta que, aunque no se recomienda, todo el espacio de direcciones que incluye la subred cero y la subred de todo unos siempre se ha podido utilizar. El uso de la subred de todo unos se permitía explícitamente, y el uso de la subred cero se permite explícitamente desde Cisco IOS Software Versión 12.0. Incluso antes de Cisco IOS Software Release 12.0, se podía utilizar la subred cero si se ingresaba el comando de configuración global ip subnet-zero
Consulte RFC 1878sobre los problemas de la subred cero y el uso de la subred de todo unos. Actualmente, el uso de la subred cero y la subred de todo unos es generalmente aceptado, y la mayoría de los proveedores soportan su uso. Sin embargo, en ciertas redes, particularmente las que utilizan software heredado, el uso de la subred cero y la subred de todo unos puede conducir a problemas.
Nota: solo los usuarios registrados de Cisco pueden acceder a la información y las herramientas internas de Cisco.
Información Relacionada