IP : Resolución y asignación dinámica de direcciones

Uso de Subnet Zero y All-Ones Subnet

18 Octubre 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

La división en subredes descompone una dirección de red dada en subredes menores. Acoplada a otras tecnologías como NAT (Network Address Translation) y PAT (Port Address Translation), permite el uso más eficiente del espacio de direcciones IP disponible, paliando así en gran parte el problema del agotamiento de direcciones. La división en subredes tiene pautas relativas al uso de la primera y la última subredes, conocidas como subred cero y subred de todo unos, respectivamente. Este documento discute la subred cero y subred de todo unos y sus aplicaciones.

prerrequisitos

Requisitos

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.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte las Convenciones de Consejos Técnicos de Cisco.

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. Por abandono el direccionamiento 172.16.0.0 de la clase B tiene 16 bits reservados para representar la porción del host, así permitiendo a 65534 (216-2) direcciones de host válidas. Si la red 172.16.0.0/16 es subnetted pidiendo prestados tres bits de la porción del host, se obtienen ocho subredes (de 23). La tabla siguiente es un ejemplo que muestra las subredes obtenidas por división en subredes de la dirección 172.16.0.0, la máscara de subred resultante, las direcciones de broadcast correspondientes, 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 llama subred cero.

La clase de red dividida en subredes y el número de subredes obtenidas después de la división en subredes no tienen ningún papel en la determinación de 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 17, 18, y 19 en este caso) son ceros. La subred cero también se conoce como subred de todo ceros.

Última subred

Cuando una dirección de red se divide en subredes, la última subred obtenida se llama subred de todo unos.

Referente al ejemplo anterior, la última subred obtenida al dividir en subredes la subred 172.16.0.0 (subred 172.16.224.0/19) se llama subred de todo unos.

La clase de red dividida en subredes y el número de subredes obtenidas después de la división en subredes no tienen ningún papel en la determinación de la subred de todo unos. Además, cuando se escribe el equivalente binario de la dirección de subred cero, todos los bits de subred (bits 17, 18, y 19 en este caso) son unos, de ahí el nombre.

Problemas con la subred cero y la subred todo-uno

Tradicionalmente, se recomendaba que la subred cero y la subred de todo unos no se utilizaran para el direccionamiento. Según el RFC 950, "Es útil preservar y ampliar la interpretación de estas direcciones especiales (red y broadcast) en las redes divididas en subredes.leavingcisco.com Esto significa que los valores de todo ceros y todo unos en el campo subred no se deben asignar a subredes reales (físicas)." Ésta es la razón por la que los ingenieros de red requeridos calcular el número de subredes obtenidas pidiendo prestados tres bits calcularían 23-2 (6) y no 23 (8). El -2 tiene en cuenta que la subred cero y la subred de todo unos no se utilizan de la manera tradicional.

Subred cero

El uso de la subred cero para el direccionamiento no se recomendaba debido a la confusión inherente a tener una red y una subred con direcciones indistinguibles.

Referente a nuestro ejemplo anterior, considere la dirección IP 172.16.1.10. Si calcula la dirección de subred correspondiente a esta dirección IP, la respuesta a la que llegará 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 dividió en subredes en primer lugar, así que siempre que realice división en subredes obtendrá una red y una subred (subred cero) con direcciones indistinguibles. Ésta era antes una fuente de gran confusión.

Antes del Software Release 12.0 de Cisco IOS�, los routeres Cisco, por abandono, no permitieron una dirección IP que pertenecía a la subred cero que se configurará en una interfaz. Sin embargo, si un ingeniero de red que trabaje con una versión de Cisco IOS Software anterior a la 12.0 encuentra seguro utilizar la subred cero, puede utilizar el comando ip subnet-zero en el modo de configuración global 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 al software Cisco IOS, versión 8.3, se utilizó el comando service subnet-zero.

Última subred

El uso de la subred de todo unos para el direccionamiento no se recomendaba debido a la confusión inherente a tener una red y una subred con direcciones de broadcast idénticas.

Referente al ejemplo anterior, la dirección de broadcast para la última subred (subred 172.16.224.0/19) es 172.16.255.255, que es idéntica a la dirección de broadcast de la red 172.16.0.0, que se dividió en subredes en primer lugar, así que siempre que realice la división en subredes se obtiene una red y una subred (subred de todo unos) con direcciones de broadcast idénticas. Es decir, un ingeniero de red podría configurar la dirección 172.16.230.1/19 en un router pero, si lo hace, ya no podrá distinguir entre un broadcast de subred local (172.16.255.255 (/19)) y el broadcast completo de la 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. Para que tenga una idea de lo que puede ocurrir, considere lo siguiente:

/image/gif/paws/13711/40a.gif

Nota: Vea Cantidades de Hosts y Subredes para ver más detalles.

Los routers 2 a 5 son routers de acceso que tienen, cada uno, varias conexiones asíncronas (o ISDN) entrantes. Hemos decidido dividir una red (195.1.1.0/24) 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 se configuran ip unnum e0. El Router 1 tiene rutas estáticas apuntando al router de acceso correcto, y cada router de acceso tiene una ruta predeterminada apuntando al Router 1.

La tabla de ruteo del router 1 tiene la siguiente apariencia:

C  195.1.2.0/24   E0
      S  195.1.1.0/26   195.1.2.2
      S  195.1.1.64/26  195.1.2.3
      S  195.1.1.128/26 195.1.2.4
      S  195.1.1.192/26 195.1.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  195.1.2.0/24   E0                       C  195.1.2.0/24   E0           
      S  0.0.0.0/0      195.1.2.1                S  0.0.0.0/0      195.1.2.1    
      C  195.1.1.2/32   async1                   C  195.1.1.65/32   async1      
      C  195.1.1.5/32   async2                   C  195.1.1.68/32   async2      
      C  195.1.1.8/32   async3                   C  195.1.1.74/32   async3      
      C  195.1.1.13/32   async4                  C  195.1.1.87/32   async4      
      C  195.1.1.24/32   async6                  C  195.1.1.88/32   async6      
      C  195.1.1.31/32   async8                  C  195.1.1.95/32   async8      
      C  195.1.1.32/32   async12                 C  195.1.1.104/32   async12    
      C  195.1.1.48/32   async15                 C  195.1.1.112/32   async15    
      C  195.1.1.62/32   async18                 C  195.1.1.126/32   async18    
          
  Router 4 routing table:                  Router 5 routing table:                    
                                                                               
      C  195.1.2.0/24   E0                       C  195.1.2.0/24   E0          
      S  0.0.0.0/0      195.1.2.1                S  0.0.0.0/0      195.1.2.1   
      C  195.1.1.129/32   async1                 C  195.1.1.193/32   async1    
      C  195.1.1.132/32   async2                 C  195.1.1.197/32   async2    
      C  195.1.1.136/32   async3                 C  195.1.1.200/32   async3    
      C  195.1.1.141/32   async4                 C  195.1.1.205/32   async4    
      C  195.1.1.152/32   async6                 C  195.1.1.216/32   async6    
      C  195.1.1.159/32   async8                 C  195.1.1.223/32   async8    
      C  195.1.1.160/32   async12                C  195.1.1.224/32   async12   
      C  195.1.1.176/32   async15                C  195.1.1.240/32   async15   
      C  195.1.1.190/32   async18                C  195.1.1.252/32   async18

¿Qué sucede si se ha configurado erróneamente los hosts de las líneas asincrónicas para que tengan una máscara de 255.255.255.0 en lugar de una máscara de 255.255.255.192? Todo funciona bien.

Observe lo que ocurre cuando uno de estos hosts (195.1.1.24) hace un broadcast local (NetBIOS, WINS). El paquete tiene este aspecto:

s: 195.1.1.24 d: 195.1.1.255

El paquete es recibido por el Router 2. 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 expire el plazo TTL (Time to Live).

El siguiente es otro ejemplo (host 195.1.1.240):

s: 195.1.1.240  d: 195.1.1.255

Este paquete es recibido por el Router 2. 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 expire el plazo TTL. Si ocurre esta situación, puede ser que piense que está 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. Dado que el router 5 está gestionando la subred de todo unos, revienta. 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 configurados de manera incorrecta, cree una interfaz de loopback en cada router de acceso con una ruta estática 195.1.1.255 a la dirección del loopback. Podría utilizar la interfaz Null0, pero esto hace que el router genere mensajes "inalcanzable" de ICMP (Internet Control Message Protocol).

Uso de Subnet Zero y All-Ones Subnet

Hay que tener en cuenta que, aunque no se recomendara, todo el espacio de direcciones, incluidas la subred cero y la subred de todo unos, ha sido utilizable siempre. 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 Versión 12.0, la subred cero podía utilizarse ingresando el comando del modo de configuración global ip subnet-zero.

Sobre el problema del uso de la subred cero y la subred de todo unos, RFC 1878 afirma, "Esta práctica (de excluir la subred de todo ceros y la de todo unos) está obsoleta.leavingcisco.com El software moderno podrá utilizar todas las redes definibles.” Hoy, el uso de la subred cero y de la subred de todo unos está generalmente aceptado, y la mayoría de proveedores soportan su uso. Sin embargo, en ciertas redes, en particular en las que utilizan software heredado, el uso de la subred cero y de la subred de todo unos puede provocar problemas.

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 13711