Introducción a la Administración de una Red Local basada en Internet

3. Eligiendo una estructura de direcciones.

Antes de comenzar a montar una estructura de IP, necesitamos uno o más números de red oficiales. Una dirección IP tiene un aspecto como el siguiente: 128.6.4.3. Esta dirección sólo podrá ser usada por un ordenador de la Universidad de Marx. La primera parte de dicha dirección, 128.6, es un número de red asignado a dicha Universidad por una autoridad central. Por tanto, antes de asignar direcciones a nuestros ordenadores, deberemos obtener una dirección oficial de red. Sin embargo, alguna gente configura sus redes usando, o bien una dirección aleatoria o usando una dirección genérica suministrada por defecto en el equipo. Esta forma de trabajar podría funcionar en pequeñas redes, pero seguramente no lo hará en una mayor. Además, es posible que quisiéramos conectar nuestra red con la red de otra organización. Incluso si nuestra organización tuviese un gran control de seguridad, es posible que tuviéramos un ordenador dedicado a la investigación que estuviese conectado a una universidad u otra organización investigadora. Esta universidad o entidad estaría seguramente conectada a una red de nivel nacional. Tan pronto como uno de nuestros datagramas salga de nuestra red local va a provocar un estado de confusión en la organización con la que nos comuniquemos, porque la dirección que aparece en nuestros datagramas está probablemente asignada oficialmente a alguien distinto.

La solución es simple: obtener una dirección propia desde el principio. Además, no cuesta nada.

La decisión más importante que tenemos que hacer para configurar una red es, sin lugar a dudas, cómo asignar las direcciones IP a los ordenadores. Esta elección debe de hacerse desde el punto de vista de cómo nuestra red puede crecer. Si no se hiciese así, es casi seguro que tendremos que cambiar las direcciones en un futuro. Y cuando tengamos varios cientos de ordenadores, cambiar tantas direcciones es casi imposible.

Las direcciones son muy importantes porque los datagramas IP son enrutados en base a dicha dirección. Por ejemplo, las direcciones de la Universidad Rutgers tienen una estructura de dos niveles. Una dirección típica puede ser 128.6.4.3. La dirección 128.6 es la asignada a dicha Universidad. Visto desde el exterior, 128.6 es una simple red. Cualquier datagrama enviado desde el exterior, que comience por 128.6, se dirigirá al gateway más cercano de la Universidad Rutgers. Sin embargo, dentro de Rutgers dividimos el espacio de direcciones en "subredes". Usamos los siguientes 8 bits de dirección para indicar a qué subred pertenece el ordenador. Así, 128.6.4.3 pertenece a la subred 128.6.4. Generalmente, las subredes se corresponden con redes "físicas" o reales, por ejemplo una red Ethernet; sin embargo, veremos algunas excepciones más adelante. Los sistemas dentro de Rutgers, a diferencia de los de fuera, contienen información sobre la estructura de subredes de Rutgers. Así, una vez que un datagrama para 128.6.4.3 llega a Rutgers, la red de Rutgers lo enrutará hacia la Ethernet, Token Ring o cualquier otro tipo de red del departamento que tiene asignado la subred 128.6.4.

Cuando queremos configurar una red, hay varias decisiones de direccionamiento que debemos afrontar:

• ¿Dividimos nuestro espacio de direcciones?
• Si lo hacemos, ¿usamos subredes o direcciones de clase C?
• ¿Cómo debe ser de grande el espacio de direcciones que necesitamos?

3.1 ¿Debemos subdividir nuestro espacio en direcciones?

No es absolutamente necesario usar subredes. Hay mecanismos que permiten actuar a un campus o compañía completa como una simple y gran Ethernet, así que no es necesario un enrutamiento interno. Si usamos estas tecnologías, entonces no necesitaremos dividir nuestro espacio de direcciones. En este caso, la única decisión que tenemos que tomar es la de qué clase de dirección debemos de usar. Sin embargo, recomendamos usar un enfoque de subredes o cualquier otro método de subdividir nuestro espacio de dirección en varias redes:

• En la sección 6.2. discutiremos que los gateways internos son recomendables para todas las redes, más allá de su simplicidad.
• Incluso si no necesitamos gateways en estos momentos, podemos descubrir que tarde o temprano necesitaremos usarlos. De esta manera, probablemente tiene sentido asignar direcciones como si cada Ethernet o Token Ring fuera una subred separada. Esto permitirá hacer conversiones a subredes reales, si esto es necesario.
• Por razones de mantenimiento, es conveniente tener direcciones cuya estructura corresponda con la estructura de la red. Por ejemplo, si vemos un datagrama extraviado procedente del sistema 128.6.4.3, es de bastante ayuda saber que todas las direcciones que comienzan por 128.6.4 se en cuentran en un determinado edificio.

3.2 Subredes y múltiples numeros de red

Supongamos que estamos convencidos de que es una buena idea imponer alguna estructura en nuestras direcciones. La siguiente cuestión es cuál es la más adecuada. Hay dos enfoques básicos: subredes y múltiples números de red.

Los estándares de Internet especifican el formato de las direcciones. Para las direcciones que comienzan entre 128 y 191 (las más usadas actualmente), los dos primeros octetos forman el número de red; por ejemplo, en 140.3.50.1, 140.3 es el número de red. Los números de red están asignados a una organización particular. ¿Qué hacemos con los dos siguientes octetos que le siguen?. Podríamos optar por hacer al siguiente octeto un número de subred, u otro esquema completamente distinto. Los gateways dentro de nuestra organización deben configurarse para conocer qué esquema de división de redes estamos usando. Sin embargo, fuera de la organización nadie sabrá si 140.3.50 es una subred y 140.3.51 es otra; simplemente, fuera se sabe que 140.3 es una organización. Desafortunadamente, esta habilidad de añadir una estructura adicional a las direcciones, mediante el uso de subredes, no estaba presente en las especificaciones originales y, por tanto, un software antiguo sería incapaz de trabajar con subredes. Si una parte importante del software que hemos de usar tiene este problema, entonces no podremos dividir nuestra red en subredes.

Algunas organizaciones usan un enfoque distinto. Es posible que una organización use varios números de red. En lugar de dividir un simple número de red, por ejemplo 140.3, en varias subredes, como de 140.3.1 a 140.3.10, podríamos usar 10 números distintos de red. De esta manera haríamos una asignación desde 140.3 hasta 140.12. Todo el software IP sabrá que estas direcciones se corresponden con redes distintas.

A pesar de que usando números de red distintos todo funciona correctamente dentro de la organización, hay dos serias desventajas. La primera, y menos importante, es que se malgasta un gran espacio de direcciones. Hay solamente sobre unas 16.000 posibles direcciones de clase B. No queremos malgastar diez de ellas en nuestra organización, a no ser que sea bastante grande. Esta objección es menos seria, porque podríamos pedir una dirección C para este propósito y hay sobre 2 millones de direcciones C.

El problema más serio para usar varias direcciones de red, en lugar de subredes, es que sobrecarga las tablas de enrutamiento en el resto de Internet. Como comentamos anteriormente, cuando dividimos nuestro número de red en subredes, esta división sólo es conocida dentro de la organización, pero no fuera. Los sistemas externos a la organización sólo necesitan una entrada en sus tablas para ser capaces de llegar. Por tanto, otras Universidades tienen entradas en sus tablas de enrutamiento para 128.6, similar al número de la red de Rutgers. Si usa un rango de redes en lugar de subredes, dicha división será visible en todo Internet. Si usamos los números 128.6 a 128.16, en lugar de 128.6, las otras universidades necesitarían tener una entrada para cada uno de estos números de red en sus tablas de enrutamiento. La mayoría de los expertos de TCP/IP recomiendan el uso de subredes, en lugar de múltiples redes. La única razón para considerar múltiples redes es el uso de un software que no puede manejar subredes. Esto era un problema hace algunos años, pero actualmente es poco frecuente.

Una última indicación sobre subredes: Las subredes deben ser "adyacentes". Esto significa que no podemos conectar la subred 128.6.4 con la subred 128.6.5 mediante otra red, como la 128.121. Por ejemplo, Rutgers tiene campus en Simon City y Garfunken City. Es perfectamente posible conectar redes en ciudades distintas que sean subred de 128.6. Sin embargo, en este caso, las líneas entre Simon City y Garfunken City deben ser parte de 128.6. Supongamos que decidimos usar una red regional como la RegionaLnet para comunicarnos entre dos campus, en lugar de usar su propia línea. Puesto que RegionaLnet tiene de número de red 128.121, los gateways y líneas de serie que usarían empezarían por 128.121. Esto viola las reglas. No está permitido tener gateways o líneas que son parte de 128.121 conectando dos partes de 128.6. Así, si queremos usar RegionaLnet entre nuestros dos campus, tendríamos que obtener diferentes números de red para los dos campus. (Esta regla es un resultado de las limitaciones de la tecnología de enrutamiento. Eventualmente podría desarrollarse un software para un gateway para manejar configuraciones cuyas redes no son contiguas).