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".
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.
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.
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.
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.
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.
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.
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.
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
.
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
bridge
si se coloca en una red muy concurrida, incluso si el tráfico
que atraviesa el bridge
es pequeño.
No obstante, existe otra desventaja basada en la manera como los
bridges están diseñados. Sería posible, en principio, diseñar bridges sin
estas desventajas, pero no hay indicios de que se cambie. La desventaja
se debe al hecho de que los bridges no tienen una tabla de enrutamiento
completa con todos los sistemas de las redes, ya que sólo tienen una
simple lista con las direcciones Ethernet que se encuentran en sus redes.
Lo que significa quebridge
capaz de manejar
líneas punto a punto paralelas, en un caso especial donde dichas líneas
tienen en sus extremos un bridge
. Los bridges tratarían las dos líneas
como una única línea virtual y usarlas alternativamente, siguiendo algún
algoritmo aleatorio.
El proceso de desactivar conexiones redundantes hasta que no queden
bucles es conocido como un "algoritmo de expansión de árboles". Este
nombre se debe a que un árbol se define como un patrón de conexiones
sin bucles. Lo que se hace es ir desactivando conexiones, ya que las
conexiones restantes en el árbol incluyen a todas las redes del sistema.
Para llevarlo a cabo, todos los bridges del sistema de redes deben
comunicarse entre ellos.
Hay una tendencia a que los árboles de expansión resultantes cargan
demasiado a la red en alguna parte del sistema. Las redes cercanas a la
"raiz del árbol" manejan todo el tráfico entre las distintas partes de la
red.
En una red que usa gateways
, sería posible poner enlaces extras entre
partes de la red que tengan un gran tráfico, pero dichos enlaces extras no
pueden ser usados por un conjunto de bridges.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
.
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.
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:
bridge
, gateway
).software
que provocan un excesivo tráfico entre
algunos hosts
(no nos referimos a mensajes de tipo
broadcoast). Los bridges y gateways
pueden aislarnos de estos errores.
(Este tipo de fallos son bastante raros. La mayor parte de los problemas
del software
y de protocolos generan broadcoasts).software
que provocan un excesivo tráfico de
broadcast. Los gateways
se aislan de estos problemas. Generalmente, los
bridges no lo hacen, porque deben dejar las peticiones ARP y otros
broadcasts. Los bridges con filtros definidos por el usuario podrían
protegernos contra algunos de estos errores de sobrecarga de broadcast.
Sin embargo, en general, los bridges deben dejar pasar ARP y la
mayoría de estos errores se deben a ARP. Este problema no es tan grave
en redes donde el software
tiene un cuidadoso control, pero tendremos
regularmente problemas de este tipo en redes complejas o con software
experimental.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.
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.
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:
gateways
. Se puede, incluso, reducir este número en el caso de que
usemos una opción de dar un paso mayor de uno a una línea lenta.gateways
).gateways
cambian
con frecuencia.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.
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.
Vamos a reunir todo lo anterior indicando dónde se usa cada tipo de conmutador, normalmente:
gateways
deben situarse de manera que se divida
la red en partes cuyo volumen de tráfico sea manejable. Incluso se
podrían emplazar bridges o gateways
incluso en el caso de que no sean
necesarios por razones de monitorización.bridge
incluye
algunas facilidades de filtrado de datagramas.bridge
para conectar redes que
pertenecen a distintas organizaciones. Las partes de la red "de tipo
experimental" deberán aislarse del resto de la red por gateways
.gateways
.