Página siguiente Página anterior Índice general

6. Puentes y gateways

En esta sección vamos a tratar con más detalle la tecnología usada para construir grandes redes. Vamos a centrarnos especialmente en cómo conectar varias Ethernet, token rings, etc. Hoy día la mayoría de las redes son jerárquicas. Los hosts están incluídos en una red de área local, como una Ethernet o un token ring. Estas redes se conectan entre sí mediante alguna combinación de redes principales o enlaces punto a punto. Una universidad puede tener una red como se muestra, en parte, a continuación:

 ________________________________
 |   red 1      red 2    red 3  |        red 4            red 5
 | ---------X---------X-------- |      --------         --------
 |                         |    |         |                 |
 |  Edificio A             |    |         |                 |
 |               ----------X--------------X-----------------X
 |                              | red principal del campus  :
 |______________________________|                           :
                                                      línea :
                                                      serie :
                                                     -------X-----
                                                         red  6
Las redes 1, 2 y 3 están en un edificio. Las redes 4 y 5 están en edificios distintos del campus. La red 6 puede estar en una localización más distante. El diagrama anterior nos muestra que las redes 1, 2 y 3 están conectadas directamente, y los mecanismos que manejan las conexiones se marcan con "X". El edificio A está conectado a otros edificios en el mismo campus por una red principal. El tráfico desde la red 1 a la red 5 tomará el siguiente camino:

El tráfico hacia la red 6 debería pasar adicionalmente a través de la línea serie. Con la misma configuración, se usaría la misma conexión para conectar la red 5 con la red principal y con la línea serie. Así, el tráfico de la red 5 a la red 6 no necesita pasar a través de la red principal, al existir esa conexión directa entre la red 5 y la línea serie.

En esta sección vamos a ver qué son realmente estas conexiones marcadas con "x".

6.1 Diseños alternativos

Hay que hacer constar que hay distintos diseños alternativos al mostrado anteriormente. Uno de ellos es usar líneas punto a punto entre los hosts, y otro puede ser usar una tecnología de red a un nivel capaz de manejar tanto redes locales como redes de larga distancia.

Una red de líneas punto a punto.

En lugar de conectar los hosts a una red local como una Ethernet, y luego conectar dichas Ethernets, es posible conectar directamente los ordenadores a través de líneas serie de largo alcance. Si nuestra red consiste primordialmente en un conjunto de ordenadores situados en localizaciones distintas, esta opción tiene sentido. Veamos un pequeño diseño de este tipo:

  ordenador 1              ordenador 2             ordenador 3
      |                        |                       |
      |                        |                       |
      |                        |                       |
  ordenador 4 ------------ ordenador 5 ----------- ordenador 6

En el primer diseño, la tarea de enrutamiento de los datagramas a través de red era realizada por unos mecanismos de propósito específico que marcábamos con "x". Si hay líneas que conectan directamente un par de hosts, los propios hosts harán esta labor de enrutamiento, al mismo tiempo que realizan sus actividades normales. A no ser que haya líneas que comuniquen directamente todos los hosts, algunos sistemas tendrán que manejar un tráfico destinado a otros. Por ejemplo, en nuestro diseño, el tráfico de 1 a 3 deberá pasar a través de 4, 5 y 6. Esto es perfectamente posible, ya que la inmensa mayoría de las implementaciones TCP/IP son capaces de reenviar datagramas. En redes de este tipo podemos pensar que los propios hosts actúan como gateways. Y, por tanto, deberíamos configurar el software de enrutamiento de los hosts como si se tratase de un gateway. Este tipo de configuraciones no es tan común como podría pensarse en un principio debido, principalmente, a estas dos razones:

Por supuesto, es factible tener una red que mezcle los dos tipos de tecnologías. Así, las localizaciones con más equipos podría manejarse usando un esquema jerárquico, con redes de área local conectadas por este tipo de unidades, mientras que las localizaciones lejanas con un sólo ordenador podrían conectarse mediante líneas punto a punto. En este caso, el software de enrutamiento usado en los ordenadores lejanos deberá ser compatible con el usado por las unidades conmutadoras, o bien tendrá que haber un gateway entre las dos partes de la red.

Las decisiones de este tipo generalmente se toman tras estudiar el nivel de tráfico de la red, la complejidad de la red, la calidad del software de enrutamiento de los hosts y la habilidad de los hosts para hacer un trabajo extra con el tráfico de la red.

Tecnología de los circuítos de conmutación.

Otro enfoque alternativo al esquema jerárquico LAN/red principal es usar circuítos conmutadores en cada ordenador. Realmente, estamos hablando de una variante de la técnica de las líneas punto a punto, donde ahora el circuíto conmutador permite tener a cada sistema aparentar que tiene línea directa con los restantes. Esta tecnología no es usada por la mayoría de la comunidad TCP/IP debido a que los protocolos TCP/IP suponen que el nivel más bajo trabaja con datagramas aislados. Cuando se requiere una conexión continuada, el nivel superior de red la implementa usando datagramas. Esta tecnología orientada al datagrama no coincide con este sistema orientado a los circuítos de forma directa. Para poder usar esta tecnología de circuítos conmutadores, el software IP debe modificarse para ser posible construir circuítos virtuales de forma adecuada. Cuando hay un datagrama para un destino concreto se debe abrir un circuíto virtual, que se cerrará cuando no haya tráfico para dicho destino por un tiempo. Un ejemplo de este enfoque es la DDN (Defense Data Network). El protocolo principal de esta red es el X.25. Esta red parece desde fuera una red distribuída X.25. El software TCP/IP trata de manejar la DDN mediante el uso de canales virtuales. Técnicas similares podrían usarse con otras tecnologías de circuítos de conmutación, como, por ejemplo, ATT's DataKit, aunque no hay demasiado software disponible para llevarlo a cabo.

Redes de un sólo nivel.

En algunos casos, los adelantos en el campo de las redes de larga distancia pueden sustituir el uso de redes jerárquicas. Muchas de las redes jerárquicas fueron configuradas así para permitir el uso de tecnologías tipo Ethernet y otras LAN, las cuáles no pueden extenderse para cubrir más de un campus. Así que era mecesario el uso de líneas serie para conectar las distintas LANs de varios lugares. Sin embargo, ahora hay tecnologías de características similares a Ethernet, pero que pueden abarcar más de un campus y, por tanto, pensar en una sola red de larga distancia que no hace uso de una estructura jerárquica.

Las principales limitaciones de este tipo de redes son cuestiones de rendimiento y flexibilidad. Si una sola red es usada por todo el campus es muy fácil que se sobrecargue. Las redes jerárquicas pueden manejar un volumen de trabajo mucho mayor que las redes de un solo nivel. Además, el tráfico dentro de los departamentos tiende a ser mayor que el tráfico entre departamentos.

Veamos un ejemplo concreto. Sumpongamos que hay diez departamentos, cada uno de los cuales genera 1 Mbit/seg de tráfico. Supongamos que el 90% del tráfico se realiza entre sistemas del mismo departamento y el 10% restante hacia los demás departamentos. Si cada departamento tiene su propìa red, éstas deberían ser capaces de manejar 1 Mbit/seg, al igual que la red principal que las maneja, para poder posibilitar el 10% que cada departamento destina a otros departamentos. Para resolver la misma situación con una red de un solo nivel, puesto que debe manejar simultáneamente los diez departamentos, se resuelve con una red que soporte 10 Mbit/seg.

Está claro que el ejemplo anterior está pensado para que el sistema jerárquico sea ventajoso o, al menos, que sea más fácil de llevar a cabo. Si el tráfico destinado a los otros departamentos fuese mayor, el ancho de banda de la red principal deberá ser mayor. Por ejemplo, si en un campus hay algunos recursos centraliza dos, como mainframes u otros grandes sistemas en un centro de cálculo. Si la mayoría del tráfico procede de pequeños sistemas que intentan comunicarse con el sistema central, entonces el argumento anterior no es válido. Aunque un enfoque jerárquico puede que todavía sea útil, sin embargo no reduce el ancho de banda requerido. Siguiendo con el ejemplo dado, si los diez departamentos se comunicasen primordialmente con los sistemas del ordenador central, la red principal deberá ser capaz de manejar 10 Mbit/seg. El ordenador central debería de conectarse directamente a la red principal, o tener una red "departamental" con una capacidad de 10 Mbist/seg, en lugar de los 1 Mbit/seg de los otros departamentos.

La segunda limitación se refieren a consideraciones respecto a la fiabilidad, mantenibilidad y seguridad. Las redes de área amplia son más difíciles de diagnosticar y mantener que las redes de área local, porque los problemas pueden localizarse en el edificio donde la red se ubica. Además, hacen que el tráfico sea más fácil de controlar. Por estas razones es más lógico manejar un tráfico local dentro del edificio y usar las redes de área amplia sólo para el tráfico entre edificios. No obstante, si se da el caso de que en cada localización hay sólo uno o dos ordenadores, no tiene sentido montar una red local en cada lugar y sí usar una red de un solo nivel.

Diseños mixtos.

En la práctica, pocas redes se permiten el lujo de adoptar un diseño teóricamente puro.

Es poco probable que una red grande sea capaz de evitar el uso de un diseño jerárquico. Supongamos que la configuramos como una red de un solo nivel. Incluso si la mayoría de los edificios tienen sólo uno o dos ordenadores, habrá alguna localización donde haya bastantes ordenadores para justificar el uso de una red local. El resultado es una mezcla entre una red de un solo nivel y una red jerárquica. En la mayoría de los edificios sus ordenadores están conectados directamente a una red de área amplia, como una red de un solo nivel, pero en un edificio hay una red de área local usando su red de área amplia como red principal, a la cuál se conecta a través de unidades conmutadoras.

Por otro lado, incluso los diseñadores de redes que defienden el uso de una enfoque jerárquico, en muchas ocasiones encuentran partes de redes donde simplemente no resulta económico instalar una red de área local, así que algunos hosts se enganchan directamente a la red principal, o bien se usa una línea serie.

Además de las razones económicas de la instalación en sí, hay que tener en cuenta que a la larga hay que valorar aspectos de mantenimiento, de manera que a veces es mejor hacer un desembolso económico en el diseño para ahorrarnos dinero en el mantenimiento futuro. Por tanto, el diseño más consistente será aquél que podamos ser capaces de mantener más fácilmente.

6.2 Introducción a las distintas tecnologías de conmutación

En esta sección discutiremos las características de varias tecnologías usadas para intercambiar datagramas entre redes. En efecto, trataremos de dar más detalles sobre esas "cajas negras" que hemos visto en las anteriores secciones. Hay tres tipos básicos de conmutadores, como repetidores, bridges (o puentes) y gateways (o pasarelas), o, alternativamente, switches de nivel 1, 2 y 3 (basándonos en el nivel del modelo OSI en el que operan). También hay que aclarar que hay sistemas que combinan características de más de uno de estos dispositivos, especialmente bridges y gateways.

Las diferencias más importantes entre estos tipos de dispositivos residen en el grado de aislamiento a fallos, prestaciones, enrutamiento y las facilidades que ofrecen para la administración de la red. Más adelante examinaremos esto con más detalle.

La diferencia mayor se encuentra entre los repetidores y los otros dos tipos de switches. Hasta hace relativamente poco tiempo, los gateways proporcionaban unos servicios muy distintos a los ofrecidos por los bridges, pero ahora hay una tendencia a unificar estas dos tecnologías. Los gateways están empezando a adoptar un hardware de propósito específico que antes era característico de los bridges. Los bridges están empezando a adoptar un enrutamiento más sofisticado, características de aislamiento y de administración de redes que antes sólo se podían encontrar en los gateways. Incluso hay sistemas que pueden funcionar como bridges y gateway. Esto significa que la decisión crucial no es decidir si tenemos que usar un bridge o un gateway, sino qué características necesitamos en un switch y cómo éste afecta el diseño global de la red.

Repetidores.

Un repetidor es un equipo que conecta dos redes que usan la misma tecnología. Recibe los paquetes de datos de cada red y los retransmite a la otra red. La red resultante se caracteriza por tener la unión de los paquetes de ambas redes. Para las redes Ethernet, o que cumplen el protocolo IEEE 802.3, hay dos tipos de repetidores (otras tecnologías de red no hacen estas distinciones).

Un repetidor trabaja a muy bajo nivel. Su objetivo principal es subsanar las limitaciones de la longitud del cable que provocan pérdidas de señal, dispersión temporal, etc. Nos permiten construir redes más grandes y liberarnos de las limitaciones de la longitud del cable. Podríamos pensar que un repetidor se comporta como un amplificador a ambos lados de la red, pasando toda la información contenida en la señal (incluso las colisiones) sin hacer ningún procesamiento a nivel de paquetes. No obstante, hay un número máximo de repetidores que pueden introducirse en una red. Las especificaciones básicas de Ethernet requieren que las señales lleguen a su destino dentro de un límite de tiempo, lo que determina que haya una longitud máxima de la red. Poniendo varios repetidores en el camino se introducen dificultades para estar dentro del límite (de hecho, cada repetidor introduce un retraso, así que de alguna manera se introducen nuevas dificultades).

Un "repetidor con buffer" trabaja a nivel de paquetes de datos. En lugar de pasar la información contenida en la señal, almacena paquetes enteros de una red en un buffer interno y, luego, lo retranstime a la otra red, por lo que no deja pasar las colisiones. Debido a que los fenómenos de bajo nivel, como las colisiones, no son repetidos, se puede considerar como si las dos redes continuasen separadas en lo que se refiere a las especificaciones Ethernet. Por tanto, no hay restricciones respecto al número de repetidores con buffer que se pueden usar. De hecho, no es necesario que ambas redes sean del mismo tipo, pero han de ser suficientemente similares, de manera que tengan el mismo formato de paquete. Generalmente, esto significa que se emplean repetidores con buffer entre redes de la familia IEEE 802.x (asumiendo que elegimos la misma longitud para las direcciones y el mismo tamaño máximo para los paquetes), o entre dos redes de otra familia. Además, un par de repetidores con buffer pueden usarse para conectar dos redes mediante una línea serie.

Los repetidores con buffer y los repetidores básicos tienen una característica en común: repiten cada paquete de datos que reciben de una red en la otra. Y así ambas redes, al final, tienen exactamente el mismo conjunto de paquetes de datos.

Bridges y gateways.

Un bridge se diferencia principalmente de un repetidor en que realiza algún tipo de selección de qué datagramas se pasan a las otras redes. Persiguen alcanzar el objetivo de aumentar la capacidad de los sistemas, al mantener el tráfico local confinado a la red donde se originan. Solamente el tráfico destinado a otras redes será reenviado a través del bridge. Esta descripción también podría aplicarse a los gateways. Bridges y gateways se distinguen por la manera de determinar qué datagramas deben reenviarse. Un bridge usa sólo las direcciones del nivel 2 de OSI; en el caso de las redes Ethernet, o IEEE 802.x, nos referimos a las direcciones de 6 bytes de Ethernet o direcciones del nivel-MAC (el término "direcciones del nivel MAC" es más general. Sin embargo, con la intención de aclarar ideas, los ejemplos de esta sección se referirán a redes Ethernet y así sólo deberemos reemplazar el término "dirección Ethernet" por el equivalente de dirección de nivel MAC en cualquier otra tecnología). Un bridge no examina el datagrama en sí, así que no usa las direcciones IP, o su equivalente para tomar las decisiones de enrutamiento. Como contraste, un gateway basa sus decisiones en las direcciones IP, o su equivalente en otros protocolos.

Hay varias razones por las que importa el tipo de dirección usada para tomar una decisión. La primera de ellas afecta a cómo interactúan dichos dispositivos conmutadores con los niveles superiores del protocolo. Si el reenvío se hace a nivel de las direcciones de nivel- MAC (bridge), dicho dispositivo será invisible a los protocolos. Si se hace a nivel IP, será visible. Veamos un ejemplo en el que hay dos redes conectadas por un bridge:

       Red 1                    Red 2
      128.6.5                  128.6.4
 ===================  ==============================
    |             |    |           |            |
 ___|_______    __|____|__  _______|___   ______|____
  128.6.5.2       bridge     128.6.4.3     128.6.4.4
 ___________    __________  ___________   ___________
 ordenador A                ordenador B   ordenador C

Hay que decir que un bridge no tiene una dirección IP. En lo que se refiere a los ordenadores A, B y C, hay una sola Ethernet a la que están conectados. Esto se traduce en que las tablas de enrutamiento deben configurarse de manera que los ordenadores de ambas redes se traten como si fuesen locales. Cuando el ordenador A abre una conexión con el ordenador B, primero se envía una petición ARP preguntando por la dirección Ethernet del ordenador B. El bridge debe dejar pasar esta petición de la red 1 a la red 2. (En general, los bridges deben atender todas las peticiones). Una vez que ambos ordenadores conocen las direcciones Ethernet del otro, las comunicaciones usarán las direcciones Ethernet en el destino. Llegados a este punto, el bridge puede empezar a ejecutar alguna selección, y dejará pasar aquellos datagramas cuya dirección Ethernet de destino se encuentren en una máquina de la otra red. De esta manera un datagrama desde A hasta Bpasará de la red 2 a la red 1, pero un datagrama desde B hasta C se ignorará.

Con objeto de hacer esta selección, el bridge necesita saber en qué red está cada máquina. La mayoría de los bridges modernos construyen una tabla para cada red a la que se conecta, listando las direcciones Ethernet de las máquinas de las que se sabe en qué red se encuentran, y para ello vigilan todos los datagramas de cada red. Cuando un datagrama aparece primero en la red 1 es razonable pensar que la dirección del remitente corresponde a una máquina de la red 1.

Un bridge debe examinar cada datagrama por dos razones: la primera, para usar la dirección de procedencia y aprender qué máquinas están en cada red, y, la segunda, para decidir si el datagrama ha de ser reenviado o no en base a la dirección de destino.

Como mencionamos anteriormente, por regla general los bridges dejan pasar las peticiones de una red a la otra. Frecuentemente se usan las peticiones para localizar algún recurso. Una petición ARP es un típico ejemplo de lo anterior. Debido a que un bridge no tiene manera de saber si un host va a responder a dicha petición, deberá dejarla pasar a la otra red. Algunos bridges tienen filtros definidos por el usuario, que les posibilita dejar pasar algunos y bloquear a otros. Podemos permitir peticiones ARP (que son esenciales para que el protocolo IP funcione) y restringir otras peticiones menos importantes a su propia red de origen. Por ejemplo, podemos elegir no dejar pasar las peticiones rwhod, que usan algunos sistemas para conocer los usuarios conectados en cualquier otro sistema, o podemos decidir que rwhod sólo pueda tener acceso a una parte de la red.

Ahora veamos un ejemplo de dos redes conectadas por un gateway:

         Red 1                           Red 2
        128.6.5                         128.6.4
 ======================       ==============================
     |              |           |      |    |            |
 ____|______   _____|___________|__  __|____|___   ______|____
  128.6.5.2    128.6.5.1  128.6.4.1   128.6.4.3     128.6.4.4
 ___________   ____________________  ___________   ___________
 ordenador A          gateway        ordenador B   ordenador C

Los gateways tienen asignada una dirección IP por cada interface. Las tablas de enrutamiento de los ordenadores deberán configurarse para hacer los envíos a las direcciones adecuadas. Así, por ejemplo, el ordenador A tiene una entrada especificando que debe usarse el gateway 128.6.5.1 para alcanzar la red 128.6.4.

Debido a que los ordenadores tienen conocimiento de la existencia del gateway, el gateway no necesita inspeccionar todos los paquetes de la Ethernet. Los ordenadores le enviarán datagramas cuando sea apropiado. Por ejemplo, supongamos que el ordenador A necesita enviar un mensaje al ordenador B. En la tabla de enrutamiento de A se indica que deberemos usar el gateway 128.6.5.1, y entonces se enviará una petición ARP para esa dirección, respondiéndonos el gateway a la petición como si se tratase de un host cualquiera. A partir de entonces, los datagramas destinados a B serán enviados a la dirección Ethernet del gateway.

Más sobre bridges.

Hay varias ventajas para usar direcciones del nivel MAC, como lo hace un bridge. La primera es que cada paquete en una Ethernet, o en una red IEEE, usa dichas direcciones, y la dirección se localiza en el mismo lugar en cada paquete, incluso si es IP, DECnet, o de cualquier otro protocolo. De tal manera que es relativamente rápido obtener la dirección de cada paquete. Por otro lado, un gateway debe decodificar toda la cabecera IP y, si soporta otros protocolos distintos a IP, debe tener un software distinto para cada protocolo. Esto significa que un bridge soporta automáticamente cualquier protocolo posible, mientras que un gateway debe preveer qué protocolo debe soportar.

Sin embargo, también hay desventajas. La principal se refiere al diseño de un puente

Más sobre gateways.

Los gateways tienen sus propias ventajas y desventajas. En general, un gateway es más complejo de diseñar y administrar que un bridge. Un gateway debe participar en todos los protocolos para los que está diseñado para reenviar. Por ejemplo, un gateway IP debe responder a peticiones ARP. El estándar IP también necesita estudiar por completo las cabeceras IP, decrementando el tiempo para activar campos y obedecer cualquier opción IP.

Los gateways son diseñados para manejar topologías de redes más complejas que las que son capaces de manejar los bridges. Y, como ya hemos mencionado, tienen diferentes (y más complejas) decisiones que estudiar. En general, un bridge tiene decisiones más fáciles que tomar: si se debe reenviar un datagrama y, en caso de que deba hacerse, qué interface hemos de elegir. Cuando un gateway reenvía un datagrama, debe decidirse a qué host o gateway hay que enviarlo a continuación. Si un gateway envía un datagrama de vuelta a la red de donde procede, también debe enviar una redirección al emisor del datagrama indicando que use una mejor ruta. Muchos gateways pueden también manejar caminos paralelos. Si hay varios caminos igual mente buenos para un destino, el gateway usará uno de ellos determinado por algún tipo de algoritmo aleatorio. (Esto se hace también en algunos bridges, pero no suele ser lo usual. En ambos casos, se elige uno de ellos mediante algún tipo de algoritmo aleatorio. Esto tiende a hacer que la llegada de los datagramas tenga un orden distinto al que fueron enviados. Lo que puede complicar la labor de procesamiento de los datagramas de los hosts de destino, e, incluso, hay viejas implementaciones TCP/IP que tienen errores a la hora de ordenar los datagramas).

Para poder analizar todas estas decisiones, un gateway tendrá una tabla de enrutamiento muy similar a la de los hosts. Al igual que las tablas de enrutamiento, las tablas de los gateways contienen una entrada por cada posible número de red. Para cada red hay, o bien una entrada indicando que la red está conectada directamente al gateway, o hay una entrada indicando que el tráfico para esa red debe reenviarse hacia algún otro gateway o gateways. Describiremos posteriormente los "protocolos de enrutamiento" usados para elaborar esta información, en la discusión sobre cómo configurar un gateway.

6.3 Comparando las tecnologías de conmutación

Los repetidores, repetidores con buffer, bridges y gateways forman un espectro. Los dispositivos del principio de la lista son mejores para redes pequeñas, además son más baratos y fáciles de configurar aunque tienen menos servicios. Los del final de la lista son apropiados para construir redes más complejas. Muchas redes usan mezclas de dispositivos, con repetidores para conectar pequeños segmentos de red, bridges para algunas áreas grandes y gateways para enlaces de larga distancia.

Hasta ahora hemos asumido que sólo usan gateways. La sección de cómo configurar un host describe cómo configurar una tabla de enrutamiento, listando los gateways que se debían usar para alcanzar a distintas redes. Los repetidores y bridges son invisibles a IP, y, en lo que a las anteriores secciones se refiere, las redes conectadas mediante ellos se deben considerar como una única red. En la sección 3.4. se describe cómo configurar un host en el caso en que varias subredes se traten como una única red física; la misma configuración debería usarse cuando varias subredes se conectan mediante repetidores o bridges.

Como ya mencionamos, las características a tener en cuenta en un dispositivo conmutador son: aislamiento, rendimiento, enrutamiento y las facilidades de mantenimiento de la red.

Aislamiento.

Generalmente, los dispositivos conmutadores se usan para conectar redes. Así que, normalmente, pensamos en ganar conectividad, no en el aislamiento. Sin embargo, el aislamiento es algo digno de tener en cuenta. Si conectamos dos redes y no tenemos en cuenta el aislamiento para nada, entonces cualquier problema en otras redes aparecerá en la nuestra también. Asimismo, dos redes juntas pueden tener suficiente tráfico como para saturar la nuestra. Es por lo tanto conveniente elegir un nivel apropiado de protección.

El aislamiento puede llegar de dos maneras: aislamiento frente al mal funcionamiento y frente al tráfico. Con el objeto de discutir el aislamiento debido a errores de funcionamiento, vamos a señalar una clasificación de malfunciones:

El aislamiento al tráfico es proporcionado por bridges y gateways. La decisión más importante al respecto es conocer el número de ordenadores que podemos poner en una red sin sobrecargarla. Esto requiere el conocimiento de la capacidad de la red, y el uso al que se destinarán los hosts. Por ejemplo, una Ethernet puede soportar cientos de sistemas si se van a destinar para logins remotos y, ocasionalmente, para transferencia de ficheros. Sin embargo, si los ordenadores carecen de disco, y usamos la red para swapping, una Ethernet podría soportar entre 10 y 40, dependiendo de su velocidad y sus características de E/S.

Cuando ponemos más ordenadores en una red de los que es capaz de manejar, deberemos dividirla en varias redes y poner algún dispositivo conmutador entre ellos. Si esto se hace correctamente, la mayoría del tráfico deberá realizarse entre máquinas de la misma parte de la división, lo que significa poner los clientes en la misma red que su servidor, poner los servidores de terminales en la misma red que los hosts a los que se accede más frecuentemente.

Bridges y gateways, generalmente, suministran el mismo grado de aislamiento al tráfico. En ambos casos, sólo el tráfico destinado a los hosts del lado de la unidad conmutadora se pasará. Veremos esto más detalladamente en la sección del enrutamiento.

Prestaciones.

Los límites de las prestaciones empiezan a ser menos claros, puesto que las tecnologías de conmutación están mejorando continuamente. Generalmente, los repetidores pueden manejar todo el ancho de banda de la red (por su propia naturaleza, un repetidor básico ha de ser capaz de hacer esto). Los bridges y gateways frecuentemente tienen limitaciones en sus prestaciones de varios tipos. Los bridges tienen dos estadísticos de interés: la tasa de paquetes analizados y el rendimiento. Como explicamos anteriormente, los bridges deben analizar cada paquete que se encuentra en la red, incluso aquellos que no van a ser reenviados. El número de paquetes analizados por segundo es la unidad usada para medir la tasa de paquetes analizados. El rendimiento se puede aplicar tanto a bridges como a gateways, y refleja la parte del tráfico que ha sido reenviada; generalmente, depende del tamaño del datagrama. Así, el número de datagramas por segundo que una unidad puede manejar será mayor cuanto haya más datagramas pequeños que grandes. Normalmente, un bridge puede manejar desde algunos cientos de datagramas hasta unos 7.000. Se puede obtener mayor capacidad de procesamiento con equipos que usan una hardware de propósito específico para acelerar la labor de análisis de paquetes. La primera generación de gateways podían procesar entre algunos cientos de datagramas por segundo hasta unos 1.000 ó más; sin embargo, los gateways de segunda generación, ampliamente extendidos, usan un hardware de propósito específico igual de sofisticado que el usado en los bridges y con ellos se pueden manejar alrededor de 10.000 datagramas por segundo. Debido a que en este momento los bridges y gateways de altas prestaciones pueden manejar casi todo el ancho de banda de una Ethernet, las prestaciones no son una razón para elegir entre un tipo u otro de dispositivo. Sin embargo, para un tipo dado de dispositivo, hay todavía grandes diferencias entre los distintos modelos, sobre todo en la relación precio/prestaciones. Esto es especialmente cierto en los modelos de la gama baja. Los bridges más baratos cuestan menos de la mitad que los gateways más baratos.

Desgraciadamente, no hay un único estadístico para poder estimar las prestaciones de un dispositivo. No obstante, el que más se usa es el de paquetes por segundo. Hay que tener en cuenta que la mayoría de las empresas cuentan los datagramas una sola vez, cuando pase por el gateway; hay una compañía importante que cuenta los datagramas 2 veces, y, por tanto, deben dividirse por 2 para poder comparar. También hay que asegurarse, para hacer una comparación correcta, que los datagramas son del mismo tamaño. Un modelo para poder comparar prestaciones es


tiempo_de_procesamiento =
   tiempo_conmutación + tamaño_datagrama * tiempo_por_byte

Aquí, el tiempo de conmutación suele ser una constante; representa la interrupción latente, el procesamiento de las cabeceras, buscar en la tabla de enrutamiento, etc., más un componente proporcional al tamaño del datagrama, representando el tiempo necesario para hacer cualquier copia de datagrama. Un enfoque razonable para estudiar las prestaciones es dar los datagramas por segundo por los tamaños mínimos y máximos de los datagramas. Otra forma de conocer los límites de un dispositivo es conociendo la velocidad de los datagramas por segundo y el rendimiento en bytes por segundo, y aplicando la fórmula anterior.

Enrutamiento.

Vamos a estudiar las tecnologías usadas para decidir hacia dónde debe enviarse un datagrama. Por supuesto, no haremos esto para los repetidores, ya que éstos reenvían todos los paquetes.

La estrategia de enrutamiento de un bridge conlleva tomar dos decisiones:

La segunda decisión se toma en base a una tabla de direcciones del nivel-MAC. Como ya hemos descrito anteriormente, esta tabla se construye analizando el tráfico que pasa por cada interface. El objetivo es reenviar aquellos paquetes cuyo destino se encuentre a otro lado del bridge. Este algoritmo requiere tener una configuración de red que no contenga bucles o líneas redundantes. Los bridges menos sofisticados dejan esta tarea al diseñador de la red, y debemos diseñar y configurar una red sin bucles. Los bridges más sofisticados permiten una topología cualquiera, pero irá desactivando enlaces hasta que no haya bucles; además, nos proporciona una fiabilidad extra, ya que, en caso de fallo de un enlace, se activará automáticamente un enlace alternativo. Los bridges que funcionan de este modo tienen un protocolo que les permite detectar cuándo una unidad debe desactivarse o activarse, de manera que el conjunto activo de enlaces abarquen el árbol de expansión. Si necesitamos la fiabilidad proporcionada por los enlaces redundantes, debemos asegurarnos que nuestros bridges sean capaces de trabajar de esta manera. Actualmente no hay un protocolo estándar para este tipo de bridges, pero está en camino. En caso de comprar bridges de más de una marca, debemos asegurarnos que sus protocolos para trabajar con los árboles de expansión pueden entenderse.

Por otro lado, los gateways permiten cualquier tipo de topología, incluyendo bucles y enlaces redundantes. Debido a que tienen algoritmos más generales de enrutamiento, los gateways deben mantener un modelo de toda la red. Diferentes técnicas de enrutamiento mantienen modelos de redes con más o menos complejidad, y usan esta información con distinto tipo de sofisticación. Los gateways que pueden manejar IP, normalmente soportan los dos protocolos estándares de Internet: RIP (Routing Information Protocol) y EGP (External Gateway Protocol). El EGP es un protocolo de propósito específico usado en redes donde hay una red principal, y permite intercambiar información de "cómo llegar" con la red principal. Por regla general, es bastante recomendable que nuestros gateways soporten EGP.

RIP es un protocolo diseñado para manejar rutas en redes pequeñas o medianas, donde la velocidad de las líneas no difieren demasiado. Sus principales limitaciones son:

Algunas compañías venden modificaciones de RIP que mejoran su funcionamiento con EGP, o que incrementan la longitud del camino máximo más allá de 15, pero no incluyen otro tipo de modificaciones. En caso de que nuestra red disponga de gateways de más de una marca, en general necesitaremos que soporten RIP, puesto que suele ser el único protocolo de enrutamiento disponible. Si vamos a trabajar, además, con otro tipo de protocolo, pueden sernos útiles gateways que traduzcan su propio protocolo y RIP. Sin embargo, para redes muy grandes o complejas no nos queda otro remedio que usar otros protocolos.

También existen otros protocolos más sofisticados. Los principales son IGRP y los basados en los algoritmos SPF (el camino más corto primero - short path fist). Usualmente, estos protocolos han sido diseñados para redes más grandes o complejas y, en general, son estables bajo una gran variedad de condiciones, pudiendo manejar líneas de cualquier velocidad. Algunos de ellos permiten tener en cuenta la sobrecarga de algunos caminos, pero hasta el moemento no conozco un gateway que sea capaz de hacer esto. (Hay serios problemas para mantener un enrutamiento estable para realizarlo). Hay numerosas variantes de tecnologías de enrutamiento, y éstas se están modificando rápidamente, así que deberemos tener en cuenta la topología de nuestra red para elegir un producto en concreto; tenemos que asegurarnos que puede manejar nuestra topología y que puede soportar otros requerimientos especiales, como compartir el tráfico entre líneas paralelas, o ajustar la topología ante fallos. A largo plazo, se espera que aparezcan nuevos protocolos que estandaricen estos trabajos. Pero, por el momento, no se usa otra tecnología de enrutamiento que la RIP.

Otro asunto concerniente al enrutamiento es la politica en la que se basa el enrutamiento. En general, los protocolos de enrutamiento pretenden encontrar el camino más corto o más rápido posible para cada datagrama. En algunos casos, esto no es lo deseable; a veces, por razones de seguridad, razones económicas, etc, puede que deseemos reservar algunos caminos para algún uso específico. La mayoría de los gateways tienen la capacidad de controlar la propagación de la información de enrutamiento, lo que nos da algunas facilidades de administración sobre la forma en que estas rutas se usan, y el grado de control que soportan varía de un gateway a otro.

Administración de Redes.

La administración de redes abarca un amplio número de asuntos. En general, se suelen tratar con muchos datos estadísticos e información sobre el estado de distintas partes de la red, y se realizan las acciones necesarias para ocuparse de fallos y otros cambios. La técnica más primitiva para la monitorización de una red es hacer "pinging" a los hosts críticos; el "pinging" se basa en un datagrama de "echo" (eco), que es un tipo de datagrama que produce una réplica inmediata cuando llega al destino. La mayoría de las implementaciones TCP/IP incluyen un programa (generalmente, llamado "ping") que envía un echo a un host en concreto. Si recibimos réplica, sabremos que host se encuentra activo, y que la red que los conecta funciona; en caso contrario, sabremos que hay algún error. Mediante "pinging" a un razonable número de ciertos hosts, podremos normalmente conocer qué ocurre en la red. Si los ping a todos los hosts de una red no dan respuesta, es lógico concluir que la conexión a dicha red, o la propia red, no funciona. Si sólo uno de los hosts no da respuesta, pero los demás de la misma red responden, es razonable concluir que dicho host no funciona.

Técnicas más sofisticadas de monitorización necesitan conocer información estadística y el estado de varios dispositivos de la red. Para ello necesitará llevar la cuenta de varias clases de datagramas, así como de errores de varios tipos. Este tipo de información será más detallada en los gateways, puesto que el gateway clasifica los datagramas según protocolos e, incluso, él mismo responde a ciertos tipos de datagramas. Sin embargo, los bridges e incluso los repetidores con buffer contabilizan los datagramas reenviados, errores de interface. Es posible recopilar toda esta información en un punto de monitorización central.

También hay un enfoque oficial TCP/IP para llevar a cabo la monitorizaciòn. En la primera fase, usamos un conjunto de protocolos SGMP y SNMP, ambos diseñados para permitirnos recoger información y cambiar los parámetros de la configuración y otras entidades de la red. Podemos ejecutar los correpondientes programas en cualquier host de nuestra red. SGMP está disponible para varios gateways comerciales, así como para sistemas Unix que actúan como gateway. Cualquier implementación SGMP necesita que se proporciones un conjunto de datos para que pueda empezar a funcionar, y tienen mecanismos para ir añadiendo informaciones que varían de un dispositivo a otro. A finales de 1988 apareció una segunda generación de este protocolo, SNMP, que es ligeramente más sofisticado y necesita más información para trabajar y, para ello, usa el llamado MIB (Management Information Base). En lugar de usar una colección de variable SNMP, el MIB es el resultado de numerosas reuniones de Comités formados por vendedores y usuarios. También se espera la elaboración de un equivalente de TCP/IP de CMIS, el servicio ISO de monitorización de redes. Sin embargo, CMIS y sus protocolos, CMIP, todavía no son estándares oficiales ISO, pero están en fase experimental.

En términos generales, todos estos protocolos persiguen el mismo objetivo: permitirnos recoger información crítica de una forma estandarizada. Se ordena la emisión de datagramas UDP desde un programa de administración de redes que se encuentra ejecutando en alguno de los hosts de red. Generalmente, la interacción es bastante simple, con el intercambio de un par de datagramas: una orden y una respuesta. El mecanismo de seguridad también es bastante simple, siendo posible que se incluyan passwords en las órdenes. (En SGMP nos referiremos a éstos como una "session name", en lugar de password). También existen mecanismos de seguridad más elaborados, basados en la criptografía.

Probablemente querremos configurar la administración de la red con las herramientas que tenemos a nuestra disposición para controlar diversas actividades. Para redes con pocas terminales, queremos controlar cuándo nuestros dispositivos de conmutación fallan, están fuera de servicio por mantenimiento, y cuando haya fallos en las líneas de comunicación u otro hardware. Es posible configurar SGMP y SNMP para que usen "traps" (mensajes no solicitados) para un host en particular o para una lista de hosts cuando ocurre un evento crítico (por ejemplo, líneas activas o desactivas). No obstante, no es realista esperar que un dispositivo de conmutación nos notifique cuando falla. También es posible que los mensajes "traps" se pierdan por un fallo en la red, o por sobrecarga, así que no podemos depender completamente de los traps. No obstante, es conveniente que nuestros dispositivos de conmutación reúnan regularmente este tipo de información. Hay varias herramientas que visualizan un mapa de la red, donde los objetos cambian de color cuando cambian de estado, y hay cuadros que muestran estadísticas sobre los datagramas y otros objetos.

Otro tipo de monitorización deseable es recolectar información para hacer informes periódicos del porcentaje de uso de la red y prestaciones. Para ello, necesitamos analizar cada dispositivo de conmutación y quedarnos con los datos de interés. En la Universidad de Rutgers esto se hace cada hora, y se obtienen datos del número de datagramas reenviados a Internet u otra red, errores, varios, etc.; y se almacenan informes detallados de cada día. Hay informes mensuales en los que se refleja el tráfico que soporta cada gateway y algunas estadísticas de errores, elegidas para ver si hay un gateway que está sobrecargado (datagramasperdidos).

Sería posible que cualquier tipo de conmutador pudiese usar cualquier tipo de técnica de monitorización. Sin embargo, generalmente los repetidores no proporcionan ningún tipo de estadística, debido a que normalmente no tienen ningún procesador para abaratar su precio. Por otro lado, es posible usar un software de administración de redes con repetidores con buffer, bridges y gateways. Los gateways, en la mayoría de los casos, incluyen un avanzado software de administración de redes. La mayoría de los gateways pueden manejar IP y los protocolos de monitorización anteriormente mencionados. Y la mayoría de los bridges tienen medios para poder recoger algunos datos de prestaciones. Puesto que los bridges no están dirigidos a ningún protocolo en particular, la mayoría de ellos no tienen el software necesario para implementar los protocolos TCP/IP de administración de redes. En algunas ocasiones, la monitorización puede hacerse tecleando algunos comandos a una consola a la que esté directamente conectada. (Hemos visto un caso donde era necesario dejar el puente fuera de servicio para recoger estos datos). En los restantes casos, es posible recoger datos a través de la red, pero el protocolo requerido no suele ser ningún estándar.

Excepto para algunas pequeñas redes, debemos insistir en que cualquier dispositivo conmutador más complejo que un simple repetidor es capaz de recolectar estadísticas y algún mecanismo para hacernos con ellas de forma remota. Aquellas partes de la red que no soporten dichas operaciones pueden monitorizarse mediante pinging (aunque el ping sólo detecta errores graves, y no nos permite examinar el nivel de ruido de una línea serie y otros datos necesarios para llevar a cabo un mantenimiento de alta calidad). Se espera que la mayoría del software disponible cumpla los protocolos SGMP/SNMP y CMIS. También un software de monitorización no estándar, siempre y cuando sea soportado por los equipos que tenemos.

Una evaluación final.

Vamos a reunir todo lo anterior indicando dónde se usa cada tipo de conmutador, normalmente:


Página siguiente Página anterior Índice general