Intro Admon Redes v1.1

Introduccin a la Administracin de una Red Local basada o o en Internet
Charles L. Hedrick Traducido por Juanjo Mar juanjo96@arrakis.es n Maquetacin SGML por Paco Brufal pbrufal@ctv.es y Fernando ffddoo@openbank.es v 1.1, 27 de Julio o de 1999
Introduccin para aquellos que pretenden administrar una red basada en los protocolos de red de Internet o (TCP/IP).
Indice General
1 El problema. 1.1 Terminolog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a. 2 3 3 4 5 6 7 7 8 9 9 10 10 12 13 16 17 19 20 22 22 23 26
2 Asignacin de direcciones y enrutamiento. o 3 Eligiendo una estructura de direcciones. 3.1 3.2 3.3 3.4 Debemos subdividir nuestro espacio en direcciones? . . . . . . . . . . . . . . . . . . . . . . . Subredes y mltiples numeros de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . u Cmo asignar las subredes o los numeros de red. . . . . . . . . . . . . . . . . . . . . . . . . . o Trabajar con mltiples subredes virtualesen una red. . . . . . . . . . . . . . . . . . . . . . . u 3.4.1 3.4.2 3.5 3.6 Otra forma de trabajar con mltiples subredes. . . . . . . . . . . . . . . . . . . . . . . u Mltiples subredes: Consecuencias en el Broadcasting. . . . . . . . . . . . . . . . . . . u
Eligiendo una clase de direccin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o Lineas IP y micro gateways: direcciones asignadas dinmicamente. . . . . . . . . . . . . . . . a 3.6.1 3.6.2 L neas IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Micro gateways. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Servicios a nivel de red, nombres. 5 Congurando el enrutamiento de cada ordenador 5.1 5.2 5.3 5.4 Como enrutar los datagramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rutas jas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reconducir el enrutamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Otros mtodos para que los hosts encuentren rutas . . . . . . . . . . . . . . . . . . . . . . . . e 5.4.1 5.4.2 5.4.3 Espiar el enrutamiento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Proxy ARP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Establecer nuevas rutas tras fallos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1. El problema.
6 Puentes y gateways 6.1 Diseos alternativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . n 6.1.1 6.1.2 6.1.3 6.1.4 6.2 Una red de l neas punto a punto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tecnolog de los circu a tos de conmutacin. . . . . . . . . . . . . . . . . . . . . . . . . o Redes de un slo nivel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o Diseos mixtos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . n . . . . . . . . . . . . . . . . . . . . .
28 29 29 30 31 32 32 33 33 35 36 37 37 38 39 41 43 43 45 47
Introduccin a las distintas tecnolog de conmutacin o as o 6.2.1 6.2.2 6.2.3 6.2.4
Repetidores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bridges y gateways. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ms sobre bridges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a Ms sobre gateways. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a
6.3
Comparando las tecnolog de conmutacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . as o 6.3.1 6.3.2 6.3.3 6.3.4 6.3.5 Aislamiento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prestaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enrutamiento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Administracin de Redes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o Una evaluacin nal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o
7 Congurando gateways 7.1 Congurando el enrutamiento de los gateways . . . . . . . . . . . . . . . . . . . . . . . . . . .
8 Anexo: Copyright
El problema.
Este trabajo trata fundamentalmente sobre los aspectos lgicosde la arquitectura de red. Lo que puede o o no puede hacer una red est generalmente determinado por los protocolos que dicha red soporta y la calidad a de sus implementaciones, ms que por la tecnolog concreta de red usada, como Ethernet, Token Ring, etc. a a Adems, en la prctica, la eleccin de la tecnolog de red est basada en decisiones puramente pragmticas: a a o a a a qu tipo de red soporta el tipo de ordenadores que queremos conectar, las distancias entre los equipos, las e caracter sticas del cableado, etc. Por regla general, se suele usar Ethernet para sistemas de media escala, Ethernet o una red basada en el cableado de par trenzado para pequeas redes, o redes de alta velocidad n (t picamente Token Ring) para la red principal de un campus y para redes de superordenadores, que ejecutan aplicaciones de altas prestaciones. Por tanto, vamos a asumir que hemos llegado a conectar f sicamentenas redes individuales, del tipo Etu hernet o Token Ring. Ahora nos enfrentamos a los siguientes problemas interrelacionados: congurar el software necesario, conectar las distintas Redes Ethernet, Token Ring, etc, para formar una unica red de forma coherente, conectar las redes al mundo exterior, o sea, Internet.
2. Asignacin de direcciones y enrutamiento. o
Las anteriores decisiones requieren un pequeo anlisis. De hecho, la mayor de las redes necesitan una n a a a rquitectura, que determina la manera en que se asignan las direcciones, cmo se hace el enrutado y otras o elecciones, sobre cmo los ordenadores interaccionan con la red. Estas decisiones deben hacerse para la red o en su conjunto, preferiblemente cuando se esta procediendo a su instalacin inicial. o
1.1
Terminolog a.
Vamos a usar el trmino IP para referirnos a las redes diseadas para trabajar con TCP/IP. IP es el protocolo e n a nivel de red de la familia de protocolos TCP/IP, usados en Internet. Es una prctica comn usar el trmino a u e IP cuando nos referimos a direcciones, enrutamiento y otros elementos a nivel de red. La distincin muchas o veces no es lo sucientemente clara. As que, en la prctica, los trminos Internet TCP/IP e IP pueden a e parecer incluso intercambiables. Los trminos paquete y datagrama tambin suelen parecer intercambiables. Conceptualmente, un pae e quete es la unidad f sica de ms bajo nivel, mientras que datagrama se reere a la unidad de datos a nivel a IP. Sin embargo, en la mayor de las redes no se pueden distinguir porque coinciden, as que la gente suele a usar los dos trminos indistintamente. e Otro trmino conflictivo es el de pasarela (gateway) y enrutador (router). Pasarela es el trmino e e original usado en Internet. Sin embargo, la comunidad OSI empez a usar esta palabra con un signicado o distinto, as que la gente empez a usar enrutador para evitar dicha ambigedad. Nosotros, no obstante, o u seguiremos usando el trmino gateway. e
Asignacin de direcciones y enrutamiento. o
Muchas de las decisiones que se necesitan para la conguracin de una red IP depende del enrutamiento. En o general, un datagrama IP pasa a travs de numerosas redes mientras se desplaza entre el origen y el destino. e Veamos un ejemplo t pico:
Red 1 Red 2 Red 3 128.6.4 128.6.21 128.121 ============================== ========== ==================== | | | | | | | ___|______ _____|____ __|____|__ __|____|____ ___|________ 128.6.4.2 128.6.4.3 128.6.4.1 128.6.21.1 128.121.50.2 128.6.21.2 128.121.50.1 ___________ __________ __________ ____________ ____________ ordenador A ordenador B gateway R gateway S ordenador C
Este grco muestra tres ordenadores, 2 gateways y tres redes. Las redes pueden ser Ethernet, Token Ring a o de cualquier otro tipo. La red 2 podr ser una l a nea punto a punto que conecta los gateways R y S. El ordenador A puede enviar datagramas al B directamente, usando la red 1. Sin embargo, no puede llegar al ordenador C directamente, puesto que no estn en la misma red. Hay varias maneras de conectar redes. a En el grco asumimos el uso de gateways (ms adelante veremos otras alternativas). En este caso, los a a datagramas que van desde A a C deben ser enviados a travs del gateway R, red 2 y gateway S. Todos e los ordenadores que usan TCP/IP necesitan que se les suministre la informacin y algoritmos apropiados o para que puedan saber cundo un datagrama debe ser enviado a travs de un gateway, y elegir el gateway a e apropiado. El enrutado est a ntimamente relacionado con la asignacin de direcciones. Podemos apreciar que la direccin o o de cada ordenador comienza con el nmero de la red a la que pertenece. Por tanto, 128.6.4.2 y 128.6.4.3 se u
3. Eligiendo una estructura de direcciones.
encuentran en la red 128.6.4. Luego los gateways, cuyo trabajo es conectar dos redes, tienen una direccin o de ambas redes. Por ejemplo, el gateway R conecta la red 128.6.4 y 128.6.21. Su conexin a la red 128.6.4 o tiene la direccin 128.6.4.1. Su conexin a la red 128.6.21 tiene la direccin 128.6.21.2. o o o Debido a esta relacin entre direcciones y redes, las decisiones de enrutado deben basarse estrictamente en o el nmero de red de destino. La informacin de enrutamiento del ordenador A tendr el siguiente aspecto: u o a
red ----------128.6.4 128.6.21 128.121 gateway --------128.6.4.1 128.6.4.1 mtrica e ------0 1 2
En esta tabla, el ordenador A puede enviar datagramas a los ordenadores de la red 128.6.4 directamente, y para los datagramas a los ordenadores de las redes 128.6.21 y 128.121 es necesario usar el gateway R. La mtricaser usada por algn tipo de algoritmo de enrutamiento, como medida de la lejan del destinatario. e a u a En nuestro caso, la mtrica simplemente indica cuantos diagramas tiene que atravesar para llegar a su destino e (conocida como cuenta de saltos). Cuando el ordenador A est listo para enviar un datagrama se examina la direccin del destinatario. Coma o paramos el inicio de dicha direccin de red con las direcciones de la tabla de enrutamiento. Las distintas o entradas de la tabla indican si el datagrama debe ser enviado directamente, o a un gateway. Un gateway consiste simplemente en un ordenador conectado a dos redes diferentes, y est habilitado para a enviar datagramas entre ellos. En muchos casos es ms eciente usar un equipo especialmente diseado a n para desempear el papel de gateway. Sin embargo, es perfectamente posible usar un ordenador, siempre y n cuando tenga ms de un interfaz de red y un software capaz de enviar datagramas. a Un gateway tiene varias direcciones, una para cada red a la que est conectado. Aqu encontramos una e diferencia entre IP y otros protocolos de red: cada interface de un ordenador tiene una direccin. Con otros o protocolos, cada ordenador tiene una unica direccin, aplicable a todos sus interfaces. Un gateway entre o las redes 128.6.4 y 128.6.21 tendr una direccin que comience por 128.6.4 (por ejemplo, 128.6.4.1). Esta a o direccin se reere a su conexin a la red 128.6.4. Tambin tendr una direccin que comience con 128.6.21 o o e a o (por ejemplo, 128.6.21.2). Esta se reere a su conexin a la red 128.6.21. o El trmino redgeneralmente se suele identicar a dispositivos del tipo Ethernet, en la cual varias mquinas e a estn conectadas. Sin embargo, tambin se aplica a l a e neas punto a punto. En el grco anterior, las redes a 1 y 3 podr estar en ciudades distintas; la red 2 podr ser una l an a nea serie, un enlace satlite, u otro e tipo de conexin punto a punto. Una l o nea punto a punto es tratada como una red que consta slo de dos o ordenadores. Como cualquier otra red, una l nea punto a punto tiene una direccin de red (en este caso, o 128.6.21). Los sistemas conectados por la l nea (gateways R and S) tienen direcciones en dicha red (en este caso, 128.6.21.1 y 128.6.21.2). Es posible disear software que no necesite distintos nmeros de red para cada l n u nea punto a punto. En este caso, el interface entre el gateway y la l nea punto a punto no tiene una direccin. Esta solucin o o es apropiada cuando la red es tan grande que peligra el hecho de que nos quedemos sin direcciones. Sin embargo, tales interfaces annimaspueden dicultar bastante el manejo de la red. Puesto que no tienen o direccin, el software de red no tiene manera de referirse a dicho interface, y, por tanto, no es posible o obtener informacin sobre el ujo y los errores de la interface. o
Eligiendo una estructura de direcciones.
Antes de comenzar a montar una estructura de IP, necesitamos uno o ms nmeros de red ociales. Una a u direccin IP tiene un aspecto como el siguiente: 128.6.4.3. Esta direccin slo podr ser usada por un o o o a
ordenador de la Universidad de Marx. La primera parte de dicha direccin, 128.6, es un nmero de red o u asignado a dicha Universidad por una autoridad central. Por tanto, antes de asignar direcciones a nuestros ordenadores, deberemos obtener una direccin ocial de red. Sin embargo, alguna gente congura sus redes o usando, o bien una direccin aleatoria o usando una direccin genrica suministrada por defecto en el equipo. o o e Esta forma de trabajar podr funcionar en pequeas redes, pero seguramente no lo har en una mayor. a n a Adems, es posible que quisiramos conectar nuestra red con la red de otra organizacin. Incluso si nuestra a e o organizacin tuviese un gran control de seguridad, es posible que tuviramos un ordenador dedicado a la o e investigacin que estuviese conectado a una universidad u otra organizacin investigadora. Esta universidad o o o entidad estar seguramente conectada a una red de nivel nacional. Tan pronto como uno de nuestros a datagramas salga de nuestra red local va a provocar un estado de confusin en la organizacin con la que o o nos comuniquemos, porque la direccin que aparece en nuestros datagramas est probablemente asignada o a ocialmente a alguien distinto. La solucin es simple: obtener una direccin propia desde el principio. Adems, no cuesta nada. o o a La decisin ms importante que tenemos que hacer para congurar una red es, sin lugar a dudas, cmo o a o asignar las direcciones IP a los ordenadores. Esta eleccin debe de hacerse desde el punto de vista de cmo o o 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 direccin. o Por ejemplo, las direcciones de la Universidad Rutgers tienen una estructura de dos niveles. Una direccin o t pica puede ser 128.6.4.3. La direccin 128.6 es la asignada a dicha Universidad. Visto desde el exterior, o 128.6 es una simple red. Cualquier datagrama enviado desde el exterior, que comience por 128.6, se dirigir a al gateway ms cercano de la Universidad Rutgers. Sin embargo, dentro de Rutgers dividimos el espacio a de direcciones en subredes. Usamos los siguientes 8 bits de direccin para indicar a qu subred pertenece o e el ordenador. As 128.6.4.3 pertenece a la subred 128.6.4. Generalmente, las subredes se corresponden con , a redes f sicaso reales, por ejemplo una red Ethernet; sin embargo, veremos algunas excepciones ms adelante. Los sistemas dentro de Rutgers, a diferencia de los de fuera, contienen informacin sobre la estructura de o 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 a subred 128.6.4. Cuando queremos congurar 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? Cmo debe ser de grande el espacio de direcciones que necesitamos? o
3.1
Debemos subdividir nuestro espacio en direcciones?
No es absolutamente necesario usar subredes. Hay mecanismos que permiten actuar a un campus o compa na completa como una simple y gran Ethernet, as que no es necesario un enrutamiento interno. Si usamos estas tecnolog entonces no necesitaremos dividir nuestro espacio de direcciones. En este caso, la unica decisin as, o que tenemos que tomar es la de qu clase de direccin debemos de usar. Sin embargo, recomendamos usar e o un enfoque de subredes o cualquier otro mtodo de subdividir nuestro espacio de direccin en varias redes: e o En la seccin 6.2. discutiremos que los gateways internos son recomendables para todas las redes, ms o a all de su simplicidad. a 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, a 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 edicio.
3.2
Subredes y m ltiples numeros de red u
Supongamos que estamos convencidos de que es una buena idea imponer alguna estructura en nuestras direcciones. La siguiente cuestin es cul es la ms adecuada. Hay dos enfoques bsicos: subredes y o a a a mltiples nmeros de red. u u Los estndares de Internet especican el formato de las direcciones. Para las direcciones que comienzan entre a 128 y 191 (las ms usadas actualmente), los dos primeros octetos forman el nmero de red; por ejemplo, en a u 140.3.50.1, 140.3 es el nmero de red. Los nmeros de red estn asignados a una organizacin particular. u u a o Qu hacemos con los dos siguientes octetos que le siguen?. Podr e amos optar por hacer al siguiente octeto un nmero de subred, u otro esquema completamente distinto. Los gateways dentro de nuestra organizacin u o deben congurarse para conocer qu esquema de divisin de redes estamos usando. Sin embargo, fuera de la e o organizacin nadie sabr si 140.3.50 es una subred y 140.3.51 es otra; simplemente, fuera se sabe que 140.3 es o a una organizacin. Desafortunadamente, esta habilidad de aadir una estructura adicional a las direcciones, o n mediante el uso de subredes, no estaba presente en las especicaciones originales y, por tanto, un software antiguo ser incapaz de trabajar con subredes. Si una parte importante del software que hemos de usar a tiene este problema, entonces no podremos dividir nuestra red en subredes. Algunas organizaciones usan un enfoque distinto. Es posible que una organizacin use varios nmeros de o u red. En lugar de dividir un simple nmero de red, por ejemplo 140.3, en varias subredes, como de 140.3.1 a u 140.3.10, podr amos usar 10 nmeros distintos de red. De esta manera har u amos una asignacin desde 140.3 o hasta 140.12. Todo el software IP sabr que estas direcciones se corresponden con redes distintas. a A pesar de que usando nmeros de red distintos todo funciona correctamente dentro de la organizacin, hay u o 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 organizacin, a no ser que sea bastante grande. Esta objeccin es menos seria, porque podr o o amos pedir una direccin C para este propsito y hay sobre 2 millones de direcciones C. o o El problema ms serio para usar varias direcciones de red, en lugar de subredes, es que sobrecarga las tablas a de enrutamiento en el resto de Internet. Como comentamos anteriormente, cuando dividimos nuestro nmero u de red en subredes, esta divisin slo es conocida dentro de la organizacin, pero no fuera. Los sistemas o o o externos a la organizacin slo necesitan una entrada en sus tablas para ser capaces de llegar. Por tanto, o o otras Universidades tienen entradas en sus tablas de enrutamiento para 128.6, similar al nmero de la red u de Rutgers. Si usa un rango de redes en lugar de subredes, dicha divisin ser visible en todo Internet. Si o a usamos los nmeros 128.6 a 128.16, en lugar de 128.6, las otras universidades necesitar tener una entrada u an para cada uno de estos nmeros de red en sus tablas de enrutamiento. La mayor de los expertos de TCP/IP u a recomiendan el uso de subredes, en lugar de mltiples redes. La unica razn para considerar mltiples redes u o u es el uso de un software que no puede manejar subredes. Esto era un problema hace algunos aos, pero n actualmente es poco frecuente. Una ultima indicacin sobre subredes: Las subredes deben ser adyacentes. Esto signica que no podemos o 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 nmero de red u 128.121, los gateways y l neas de serie que usar empezar por 128.121. Esto viola las reglas. No an an est permitido tener gateways o l a 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 nmeros de red u para los dos campus. (Esta regla es un resultado de las limitaciones de la tecnolog de enrutamiento. a Eventualmente podr desarrollarse un software para un gateway para manejar conguraciones cuyas redes a no son contiguas).
3.3
Cmo asignar las subredes o los numeros de red. o
Ahora, una vez decidido si vamos a usar subredes o mltiples nmeros de red, tenemos que asignarlos. u u Normalmente es bastante fcil. Cada red f a sica, ya sea Ethernet o Token Ring, ..., se le asigna un nmero u distinto de subred. Sin embargo, existen otras opciones. En algunos casos, puede que tenga sentido asignar varios nmeros de subred a una unica red f u sica. En Rutgers hay una unica Ethernet que ocupa tres edicios, usando repetidores. Est claro que a medida que a vayamos aadiendo ordenadores a esta Ethernet se ir dividiendo en varias Ethernets separadas. Para evitar n a tener que cambiar de direcciones cuando esto suceda, hemos asignado tres nmeros de red distintas a esta u Ethernet, una por edicio. (Esto podr ser util, incluso, si no hubisemos dividido la Ethernet con el n de a e ayudar a localizarlos). Pero, antes de hacer esto, debemos estar muy seguros de que el software de todos los ordenadores puede manejar una red que tiene tres nmeros de red. Esta prctica se ver ms detalladamente u a a a en la seccin 3.4. o Tambin hemos de elegir una mscara de subred, que ser usada por el software del sistema para separar e a a la parte de subred del resto de la direccin. Hasta ahora hemos asumido que los dos primeros octetos son el o nmero de red y el siguiente es el nmero de subred. Para las direcciones de clase B, el estndar especica u u a que los dos primeros octetos pertenecen al nmero de red. Y, por otro lado, tenemos libertad para establecer u el l mite del nmero de subred y el resto de la direccin. Es bastante usual utilizar un octeto de nmero u o u de subred, pero no es la unica posibilidad. Veamos de nuevo esta direccin de clase B, 128.6.4.3. Es fcil o a deducir que, si el tercer octeto es usado como nmero de subred, entonces habr 256 posibles subredes y, u a en cada subred, habr 256 posibles direcciones. (En realidad es ms acertado decir que disponemos de 254, a a ya que no es buena idea usar 0 255 como nmeros de subred o direccin). Supongamos que sabemos que o u o nunca vamos a tener ms de 128 ordenadores por subred, pero es probable que necesitemos ms de 256 a a subredes (por ejemplo, un campus con una gran cantidad de pequeos edicios). En ese caso, podr n amos establecer 9 bits como nmero de red, dejando 7 bits para el direccionamiento de cada subred. Esta decisin u o queda plasmada en una mscara de bits, usando unos para los bits usados por los nmeros de red y de a u subred y ceros para los bits usados para el direccionamiento individual. La mscara de red ms comn es a a u 255.255.255.0. Si elegimos 9 bits para el nmero de subredes y 7 para las direcciones, la mscara de subred u a ser 255.255.255.128. a Generalmente, es posible especicar la mscara de subred como parte de la conguracin del software a o IP. Los protocolos IP tambin permiten a los ordenadores que env un mensaje preguntando cul es su e en a mscara de subred. Si nuestra red soporta el env de estos mensajes, y hay, al menos, un ordenador o a o gateway de la red que conoce dicha mscara de subred, posiblemente ser innecesario especicarlo en cada a a uno de los restantes ordenadores. Pero esta posibilidad puede traer muchos problemas. En caso de que nuestra implementacin TCP/IP diera una mscara de subred errnea, se causar una mala conguracin o a o a o en toda la red. Por lo tanto, es ms seguro poner cada mscara de subred expl a a citamente en cada sistema.
3.4
Trabajar con m ltiples subredes virtualesen una red. u
La mayor del software est desarrollado bajo el supuesto de que cada red local tiene el mismo nmero de a a u subred. Cuando existe un ujo hacia una mquina con un distinto nmero de subred, el software espera a u
encontrar un gateway que pueda dirigirlo hacia esa subred. Veamos detalladamente qu ocurre en este e caso. Supongamos que tenemos las subredes 128.6.19 y 128.6.20 en la misma Ethernet. Consideremos las cosas que ocurren desde el punto de vista de un ordenador con direcci`n 128.6.19.3. Dicho ordenador no o tendr problemas para comunicarse con las mquinas de direccin 128.6.19.x. Estas mquinas estn en la a a o a a misma subred, y nuestro ordenador simplemente deber enviar los datagramas al 128.6.20.2. Puesto que esta a direccin indica que est en una subred distinta, la mayor del software esperar encontrar un gateway que o a a a haga de puente entre ambas subredes. Por supuesto, no existe un gateway entre las subredes128.6.19 y 128.6.20, puesto que estn en la misma Ethernet. De aqu se deduce que tenemos que encontrar una manera a de indicarle al software que el 128.6.20 se encuentra realmente en la misma Ethernet. La mayor de las implementaciones TCP/IP pueden manejar ms de una subred en la misma red. Por a a ejemplo, el Berkeley Unix nos permite hacerlo usando una ligera modicacin del comando usado para o denir gateways. Si, por ejemplo, queremos que para pasar de la subred 128.6.19 a la subred 128.6.4 se use el gateway con direccin 128.6.19.1, podemos usar el comando o
route add 128.6.4.0 128.6.19.1 1
Esto indica que para llegar a la subred 128.6.4 el ujo debe ser enviado a travs del gateway 128.6.19.1. e El 1se reere a la mtrica de enrutamiento. Si usamos la mtrica 0, estamos diciendo que la subred e e de destino est en la misma red y, por consiguiente, no se necesita ningn gateway. En nuestro ejemplo, a u deberemos usar en el sistema 128.6.19.3
route add 128.6.20.0 128.6.19.1 0
La direccin usada en el lugar de 128.6.19.1 es irrelevante. La mtrica 0nos informa de que no va a usarse o e ningn gateway, luego no se usar dicha direccin. Sin embargo, deber ampliarse una direcin legal de la u a o a o red local. 3.4.1 Otra forma de trabajar con m ltiples subredes. u
Hay otro modo de manejar varias subredes sobre una red f sica. Este mtodo supone la desconguracin e o de nuestros antriones o hosts y, por ello, es potencialmente peligrosa, si no sabemos exactamente lo que estamos haciendo. Sin embargo, puede resultar ms cmodo cuando trabajamos con una gran cantidad de a o subredes en una red f sica. Un ejemplo de este tipo ser una instalacin que use bridges, y usa subredes a o simplemente por facilidades de administracin. El truco est en congurar el software de nuestros hosts o a como si no usasen subredes. As nuestros hosts no harn ninguna distincin entre las distintas subredes y, , a o por tanto, no habr problemas para trabajar con todas ellas. Ahora, el unico problema es cmo comunicarnos a o con subredes que no estn en esta red de mltiples subredes. Pero, si nuestros gateways manejan proxy e u ARP, ellos resolvern este problema por nosotros. Este enfoque est especialmente indicado cuando la a a misma red contiene mltiples subredes y, particularmente, si se van a aadir algunas ms en un futuro. u n a Desgraciadamente, tiene dos problemas: 1. Si tenemos hosts con mltiples interfaces, deberemos ser muy cuidadosos. En primer lugar, slo u o deber haber mquinas con un interface en la red con mltiples subredes. Por ejemplo, supongamos a a u que disponemos de una red que consta de varias Ethernets conectadas mediante bridges; no podemos tener una mquina con interfaces en dos de estas Ethernets, pero podemos tener un sistema con un a interface en esta red de subredes mltiples y otra en otra subred apartada de sta. En segundo lugar, u e cualquier mquina con mltiples interfaces deber conocer la verdadera mscara de subred, y necesitar a u a a a estar informada expl citamente de cules de las subredes estn en la red de mltiples subredes. Estas a a u restricciones son consecuencia de que un sistema con mltiples interfaces tiene que conocer qu interface u e ha de usar en cada caso.
2. Tambin deberemos prestar atencin a la facilidad ICMP de la mscara de subredes. Esta facilidad e o a permite a los sistemas emitir una consulta para conocer cul es la mscara de subred. Si la mayor de a a a los hosts piensan que la red no est dispuesta en subredes, pero los gateways y los hosts con varias a interfaces piensan lo contrario, tenemos aqu un foco potencial de confusin. Si un gateway o hosts o con varios interfaces env una rplica a una ICMP de mscara de red, dando la verdadera mscara a e a a de subred, alguno de los restantes hosts puede interceptarlo. La situacin contraria tambin ser o e a posible. Esto signica que tendremos que: deshabilitar las rplicas a las ICMP de mscara de subred en todos aquellos sistemas que conocen e a la mscara real de subred (esto es especialmente fcil si solamente los gateways lo conocen); a a asegurar que nuestros hosts ignoran las rplicas ICMP. e A medida que establecemos una mscara de subred expl a citamente, se supone que los hosts ignoran los ICMP de mscara de subred, as que deberemos ser capaces de establecer diferentes mscaras en diferentes hosts a a sin causar ningn problema, siempre y cuando podamos establecer la mscara expl u a citamente en todos ellos. Sin embargo, existen implementaciones IP que cambiarn su mscara de subred cuando vean una rplica de a a e ICMP de mscara de subred. a 3.4.2 M ltiples subredes: Consecuencias en el Broadcasting. u
Cuando tenemos ms de una subred en una misma red f a sica, hay que tener cuidado respecto a las direcciones de broadcasting. De acuerdo con los ultimos estndares, hay dos formas distintas para que un host de a la subred 128.6.20 pueda enviar un broadcast en la red local. Una es usar la direccin 128.6.20.255. La o otra es usar la direccin 255.255.255.255. La direccin 128.6.20.255 dice, expl o o citamente, todos los hosts de la subred 128.6.20; la 255.255.255.255 expresa todos los hosts de mi red local. Normalmente, ambas tienen el mismo efecto. Pero no lo tienen cuando hay varias subredes en una red f sica. Si la red 128.6.19 est en la misma red, tambin recibir el mensaje enviado a 255.255.255.255. Sin embargo, los hosts con a e a nmeros 128.6.19.x no escucharn los mensajes enviados a 128.6.20.255. El resultado es que ah tenemos dos u a tipos distintos de direcciones de broadcast con dos signicados distintos. Esto conlleva que debemos tener cuidado congurando el software de red, para asegurarnos de que nuestros broadcasting llegan a donde queremos que lo hagan.
3.5
Eligiendo una clase de direccin. o
Cuando solicitamos un nmero ocial de red se nos preguntar qu clase de nmero de red necesitamos. Las u a e u posibles respuestas son A, B y C. La decisin elegida limitar nuestro espacio de direcciones a usar. Las o a direcciones de clase A ocupan un octeto; las de clase B, dos octetos, y la clase C, tres octetos. Luego, hay ms direcciones de clase C que direcciones de clase A, pero las de clase C no pueden tener muchos hosts. a La idea que podemos sacar de lo anterior es que deber haber pocas grandes redes, un nmero moderado a u de redes de tamao mediano y bastantes pequeas redes. En la siguiente tabla observamos dicha distincin: n n o
Clase A B C Rango 1er. octeto 1 - 126 128 - 191 192 - 223 red p p.q p.q.r resto q.r.s r.s s direcciones posibles 16777214 65534 254
Por ejemplo, la red 10 es de la clase A y por tanto tiene direcciones entre 10.0.0.1 y 10.255.255.254. Esto signca 2543, que son sobre unos 16 millones de posibles direcciones (realmente, la red 10 tiene algunas direcciones con octetos a cero, as que habr algunas direcciones posibles ms). La red 192.12.88, una a a
10
direccin de clase C, tendr sus hosts entre el 192.12.88.1 y el 192.12.88.254 y, por lo tanto, habr 254 o a a posibles hosts. En general, deberemos elegir la clase menor que nos proporcione sucientes direcciones capaces de direccionar nuestra red, con sus posibles futuras ampliaciones. Aquellas organizaciones que usan ordenadores en varios edicios, probablemente necesitarn una direccin de clase B, suponiendo que vamos a usar subredes. (Y a o si vamos a tratar con distintos nmeros de red, deber u amos solicitar varias direcciones de clase C). Las direcciones de clase A, normalmente, slo se usan en grandes redes pblicas y algunas pocas redes de grandes o u corporaciones. En la asignacin de Direcciones IP, la autoridad mxima es la IANA (Internet Assigned Number Authority). o a A escala continental, la IANA delega grandes bloques de direcciones IP a los denominados registros regionales, de los que, de momento, existen tres en el mundo: El RIPE NCC (RIPE Network Coordination Center) es el registro delegado de Internet a nivel europeo y se encarga, entre otras tareas, de la asignacin de bloques de direcciones IP a los proveedores de o servicios Internet en Europa y su rea de inuencia. a El AP-NIC lleva a cabo la tarea de asignacin de bloques de direcciones IP a los proveedores de la o regin del Asia-Pac o co. El InterNIC se encarga de la asignacin de bloques de direcciones IP a los proveedores de Internet en o Amrica del Norte y, de momento, en el resto del mundo. e Las organizaciones y usuarios nales han de obtener las direcciones IP necesarias para conectarse a Internet a travs de su proveedor de acceso a Internet, quien a su vez las habr obtenido bien de su proveedor de e a trnsito, bien del registro regional correspondiente. a
3.6
Lineas IP y micro gateways: direcciones asignadas dinmicamente. a
En la mayor de los casos, cada uno de los ordenadores tendr su propia direccin IP permanente. No a a o obstante, hay algunas situaciones donde tiene ms sentido asignar direcciones dinmicamente. La mayor a a a de los casos que manejan l neas IP constan de gateways destinados principalmente a microcomputadoras. 3.6.1 L neas IP.
Es posible usar IP sobre l neas telefnicas. Uno de los protocolos para hacer esto es el SLIP (Serial line o IP). SLIP se usa frecuentemente en, al menos, dos circunstancias distintas: Como una alternativa barata a l neas punto a punto permanentes, para aquellos casos en los que no est sucientemente justicado una l a nea dedicada. Como una manera de conectar individualmente un PC a una red, cuando se encuentran localizados en edicios que no tienen Ethernets o cualquier otro tipo LAN. Vamos a usar el trmino servidor SLIPpara referirnos a un sistema de ordenador(es) que incluye una e serie de modems, con los que otros sistemas pueden conectarse usando SLIP. Se trata de un sistema que proporciona un gateway de nuestra red para usuarios de PC, o para otras redes que se conectan usando SLIP. Si tenemos varios PCs conectados mediante SLIP, muchas veces no es prctico usar una direccin IP propia a o para cada PC. Una de las razones puede ser que no haya sucientes direcciones. Para que el enrutamiento funcione correctamente, estos sistemas conectados deben tener sus direcciones en la misma subred que el
11
servidor SLIP. Por lo general, hay solamente del orden de 256 direcciones disponibles en cada subred. Si el nmero de PCs que pueden conectarse es mayor que esa cifra, no podremos asignarles su propia direccin. u o Si, adems, tenemos servidores SLIP en ms de una subred, la asignacin permanente de direcciones se hace a a o an ms complicada. Si un usuario es capaz de llamar a dos servidores, su PC necesitar dos direcciones, u a a una para cada subred. Para solucionar estos problemas, la mayor de las implementaciones SLIP asignan las direcciones a dinmicamente. Cuando un PC se conecta con el servidor SLIP, el servidor busca una direccin IP que a o no se est usando y se la asigna al PC. La forma ms simple de manejar esto es dando a cada servidor SLIP e a un rango de direcciones IP que controle y pueda asignar. Cuando usamos este esquema, el software SLIP debe comunicar al PC, de alguna manera, qu direccin e o debe usar. Si cada PC tiene una direccin permanente, tendr o amos el problema contrario: cuando un PC se conecta con un servidor debe de haber algn mtodo para que el PC comunique al servidor su direccin. u e o Este problema debe ser estudiado cuidadosamente, porque en otro caso alguien podr usar la direccin de a o otro y tener acceso a sus cheros. Desafortunadamente, no hay un estndar para manejar estos problemas de direccionamiento con SLIP. Hay a varias implementaciones SLIP que lo hacen, pero todav no hay un estndar. Hasta que no se elabore a a ste, deberemos tener cuidado con el software SLIP. Tenemos que asegurarnos de que dicha asignacin de e o direccin se lleva a cabo de la manera que queremos y que nuestro servidor SLIP y los PCs tienen claro la o forma en que se asignan las direcciones. Recomendamos dar direcciones permanentes a los PCs en aquellos casos en que los dems ordenadores tienen a que ser capaces de conocer con qu PC estn hablando. Este podr ser el caso de un PC para recibir correo e a a privado, o cualquier otro servicio con transacciones delicadas. Y recomienda el direccionamiento dinmico a cuando tenemos un gran nmero de PCs y las aplicaciones que utilizan para acceder a la red tienen sus u propios mecanismos de seguridad. Cuando usemos SLIP para conectar dos redes, hay que considerar tres elecciones para el manejo de direcciones (teniendo en cuenta que no todo el software SLIP puede controlar los tres apartados): Tratar a las conexiones SLIP como si se tratasen de l neas punto a punto que no estn disponibles a permanentemente. Si podemos conectar con ms de un ordenador, cada par de ordenadores que se a comunican tienen un nmero de red distinto del que ellos usar cuando se comunican con el otro. u an Usar un software de enrutamiento que permita interfaces annimos. En este caso, no ser necesarias o an las direcciones. Asignar direcciones dinmicamente cuando la conexin est abierta, tan pronto como el PC haya a o a contactado. Si hacemos slo una o dos conexiones a otro sistema, es bastante razonable usar un nmero de red para cada o u conexin. Este mtodo es fcil de usar y limita los errores estad o e a sticos. Si tenemos muchas conexiones distintas, probablemente es mejor usar interfaces annimos. Aunque si los o sistemas de enrutamiento no lo soportan, debemos usar asignacin dinmica. o a Al igual que SLIP, PPP Point to Point Protocoles un protocolo serie distinto utilizado para enviar datagramas a travs de una conexin serie, pero mejora algunas de las carencias del anterior. El PPP permite a e o las partes comunicantes negociar opciones como las direcciones IP y el tamao mximo de los datagramas n a al comenzar la conexin, y proporciona permisos de conexin a los clientes (autorizaciones). Para cada una o o de estas capacidades, el PPP tiene un protocolo concreto. A continuacin, citaremos los elementos bsicos que constituyen el PPP. Esta descripcion esta muy lejos o a de ser completa; si quiere saber mas sobre el PPP, lea sus especicaciones en el RFC 1548, asi como en la docena de RFCs que le acompaan. n
12
En la parte ms baja del PPP est el protocolo de Control de Conexin de Datos de Alto-Nivel, abreviaa a o damente HDLC. ( En realidad, el HDLC es un protocolo mucho ms general publicado por la Organizacin a o Internacional de Estndares, ISO ) que dene los l a mites de las tramas PPP individuales, y proporciona un control de errores de 16 bit. Al contrario de lo que ocurr en las encapsulaciones SLIP ms antiguas, a a una trama PPP es capaz de llevar paquetes de otros protocolos distintos al IP, como los IPX de Novell o Appletalk. El PPP consigue esto aadiendo a la trama bsica HDLC un campo de control que identica el n a tipo de paquete contenido en la trama. El LCP, Protocolo de Control de Enlace, es utilizado en la parte ms alta del HDLC para negociar las a opciones concernientes a la conexin de datos, tales como la Unidad Mxima de Recepcin (MRU) que o a o establece el tamao mximo del datagrama que una de las partes de la conexin acepta recibir. n a o 3.6.2 Micro gateways.
Es perfectamente posible que un microcomputador forme parte de una red IP. Pero hay una tendencia de que los micros utilicen distintas tecnolog de red que la de los grandes sistemas. Esto es debido a que as muchos de los usuarios de micros empiezan a demandar un software de red diseado espec n camente para las necesidades de un micro, incluso para un particular tipo de micro. Muchos usuarios estn interesados a en usar TCP/IP sin tener que abandonar su red especial de micro, a la que estn acostumbrados. Por esta a razn, hay un creciente nmero de productos, especialmente gateways, que dan acceso a los PCs tanto a o u redes orientadas a micros como a TCP/IP. En esta seccin vamos a hablar del AppleTalk, de Apple, a modo de ejemplo. No obstante, existen productos o similares para otros tipos de redes de micros. Hay que aclarar que el trmino AppleTalk se asocia a los e protocolos de red de Apple, mientras que LocalTalk se asocia a una tecnolog espec a ca de par trenzado, en la que AppleTalk fue inicialmente implementada. Por tanto, el AppleTalk es anlogo a los protocolos a TCP/IP, mientras que LocalTalk es anlogo a medio Ethernet. a Algunas compa ofrecen gateways para conectar una red AppleTalk corriendo sobre LocalTalk, con redes nas IP corriendo sobre Ethernet. A pesar de que hay varios productos de este tipo, la mayor de ellos incluyen a los siguientes servicios: Las aplicaciones TCP/IP de un PC pueden conectarnos a sistemas TCP/IP de la Ethernet. Se denen utilidades especiales para permitirnos llevar datagramas IP desde el PC hasta el gateway, a travs e del LocalTalk. Las aplicaciones TCP/IP de PC han sido escritas usando unas librer especiales que as mezclan AppleTalk y TCP/IP. Las utilidades AppleTalk se necesitan para llevar los datagramas hasta el gateway, donde se transformarn en datagramas 100% TCP/IP, antes de dejarlos en la Ethernet. a Se pueden escribir aplicaciones AppleTalk para grandes sistemas, de tal manera que un PC podr a usarlos como servidores. Dichas aplicaciones tambin han sido escritas haciendo uso de una librer e a especial que mezcla AppleTalk y TCP/IP. Pero, en esta ocasin, son utilidades TCP/IP para dejar o datagramas en el gateway, donde se transformarn totalmente en AppleTalk, antes de dejarlos en la a AppleTalk y lleguen al PC. Una red IP de un campus o una corporacin puede ser usada para conectar redes AppleTalk. Los o gateways de cada Apple realizarn las conversiones necesarias antes de enviar los datagramas a la red a IP. Adems, algunos gateways pueden hacer traducciones a nivel de aplicacin. Por ejemplo, algunos gateways a o pueden hacer traducciones entre el sistema de cheros de Apple y el sistema de chero de red de Sun (NFS). Esto permite a un PC acceder al sistema de cheros Unix, donde el PC usa el sistema de cheros Apple, y el acceso al sistema Unix se hace mediante el uso del sistema NFS, o sistema de cheros de red (Network File System ), de Sun.
4. Servicios a nivel de red, nombres.
13
Desafortunadamente, la gran exibilidad de estos productos se traduce en una gran complejidad. El tema de direcciones es especialmente complicado. Por las mismas razones que SLIP, y PPP estos gateways usan frecuentemente asignacin dinmica de direcciones IP. Para ello asignaremos un rango de direcciones IP a o a cada gateway. Cuando un PC intenta abrir una conexin TCP/IP, el gateway se hace con una direccin o o IP libre y se la asigna al PC. Al igual que SLIP, en muchos casos necesitaremos elegir si queremos que las direcciones se asignen de esta manera, o bien queremos que cada PC tenga su propia direccin. Otra vez, o la eleccin depender del nmero de PCs que tengamos y de si tenemos aplicaciones capaces de usar la o a u direccin IP para identicar qu PC, en particular, es el que est conectado. o e a El direccionamiento es mucho ms complejo, debido a que AppleTalk tiene su propia estructura de direcciones. a Deberemos establecer una correspondencia entre direcciones AppleTalk y nmeros de red IP. Tambin habr u e a una correspondencia entre direcciones IP y AppleTalk, que se establecer dinmicamente en los gateways. a a
Servicios a nivel de red, nombres.
Si vamos a tener una red TCP/IP, hay algunas tareas importantes que realizar. Algunas de ellas son simplemente de tipo administrativo. La ms importante es crear un registro central de nombres y direcciones a IP. Existen organizaciones que realizan esta labor para toda la red Internet. Si estamos conectados a Internet, el administrador de nuestro sistema necesita registrarse a una de estas organizaciones, para que cualquier demanda por parte de otra institucin sobre nuestros hosts sean dirigidos a nuestros servidores. o Queremos mantener una base de datos que contenga la informacin de cada sistema de la red. Como o m nimo, necesitaremos el nombre y la direccin IP de cada sistema. Probablemente, el registro central ser o a el encargado de asignar las direcciones IP. Si nuestra red est estructurada en subredes, o si usamos varios a nmeros de clase C, el registro posiblemente asignar los nmeros de red a las nuevas redes o subredes. u a u Pero, habitualmente, se permitir que los propios administradores de los hosts elijan el nombre del host. a Sin embargo, el registro debe de, al menos, vericar que no haya nombres duplicados. Si estamos trabajando con una gran red, puede que sea buena idea delegar algunas de estas tareas a subregistros, posiblemente uno para cada departamento. Se recomienda asignar las direcciones de la forma ms simple: empezando por 1. As si nuestra red es a , la 128.6, podr amos asignar como 128.6.1 a la primera subred; 128.6.2, a la segunda, etc. La asignacin o de direcciones IP para hosts individuales podr empezar por 2. De esta manera reservamos la direccin an o 1 de cada subred para que sea usada por el gateway correspondiente. Por consiguiente, el primer host de la subred 128.6.4 ser el 128.6.4.2; el siguiente ser 128.6.4.3, y as sucesivamente. Hay una razn a a o bsica para mantener las direcciones tan cortas como sean posibles. Si tenemos una gran organizacin, a o podr amos quedarnos sin nmeros de subred. Si esto ocurriera, y nuestros hosts tienen nmeros de red u u bajos, podr amos asignar otro bit para el direccionamiento de las subredes. Si, por ejemplo, usamos el tercer octeto como nmero de subred, en tanto en cuanto nuestros hosts tengan unos nmeros inferiores a 128, u u podremos ampliar el nmero de red a 9 bits. As por ejemplo, la subred 128.6.4 podr dividirse en dos u , a subredes distintas: 128.6.4.0 y 128.6.4.128. Si hubisemos asignado a los hosts nmeros por encima de 128, e u la divisin habr sido imposible. o a La asignacin de nombres de los hosts no es tan sistemtica. Pueden ser cualquier expresin compuesta de o a o letras, nmeros y guiones. Es ms seguro que el primer carcter sea una letra. Y, desde el punto de vista u a a de los usuarios, es recomendable que los nombres sean lo ms cortos posibles (incluso hay software que a tiene problemas trabajando con nombres ms largos de 16 caracteres). Muchas veces, los departamentos o a proyectos eligen un tema o nombre relacionado con ellos. Por ejemplo, las mquinas usadas por los estudiantes a de Informtica de Rutgers tienen nombres de bandas de rock: OASIS, BLUR, IRONMAIDEN, SAVOY, etc. a Nuestro departamento de Matemticas usa el nombre de famosos matemticos: GAUSS, FERMAT, etc. Si a a la institucin no tiene ninguna relacin con el mundo exterior, cualquier nombre es adecuado. o o
14
Si estamos conectados a Internet, nuestra organizacin necesitar un nombre de dominio(domain name). o a Al igual que en el caso del espacio de direcciones IP, la autoridad mxima del espacio de nombres de Internet a (DNS, Domain Name System) es la IANA (Internet Assigned Number Authority). La ra del DNS es z gestionada por el InterNIC por delegacin de la IANA. Bajo la ra se encuentran los distintos dominios de o z primer nivel (Top Level Domains o TLDs) gestionados por distintos registros delegados de Internet. Algunos de ellos son: Dominios especialescomo COM, ORG, NET, EDU,... controlados por InterNIC ( nodo central del Network Internet Center ); y dentro de los dominios nacionales, el dominio ES, correspondiente a Espaa, n est delegado a ES-NIC. a A diferencia del nmero de red, podremos arreglrnosla sin l si la red est aislada. Si posteriormente lo u a e a necesitamos, es fcil de aadir un nombre de dominio. (Recomendamos usar un nmero de red desde el a n u principio, porque cambiar nmeros de red posteriormente puede ser traumtico). Los nombres de dominio, u a normalmente, terminan en .EDU para las instituciones educativas, .COM, para las compa etc. Por ejemnas, plo, la Universidad de Rutgers tiene como nombre de dominio RUTGERS.EDU. El formato de los nombres completos de dominio consiste en un nombre interno, seguido del nombre de dominio de la organizacin. As o , si un ordenador es conocido internamente como GAUSS, su nombre completo ser GAUSS.RUTGERS.EDU. a Si tenemos una gran organizacin, es posible tener subdominios. Por ejemplo, puede que haya un subdominio o para cada departamento; esto aadir otro trmino en los nombres. Si, por ejemplo, el departamento de Man a e temticas decide crear su subdominio, el anterior ordenador se llamar GAUSS.MATHS.RUTGERS.EDU. a a Una vez asignado el nombre de dominio, se procede a cambiar los cheros de conguracin donde aparece o la forma completa del nombre. En algunos casos, se pueden usar apodos o nombres cortos, de manera que no ser necesario incluir el nombre completo. a Si tenemos ms de uno o dos sistemas, necesitaremos tener algn mecanismo para tener al d la informacin a u a o de los distintos hosts. El software TCP/IP necesita ser capaz de traducir nombres de hosts en direcciones IP. Cuando un usuario intenta conectarse con otro sistema, generalmente se referir a l usando su nombre. a e El software tendr que traducir el nombre en una direccin IP, para poder abrir la conexin. La mayor a o o a del software incluye dos vias para hacer esta traduccin: una tabla esttica o un servidor de nombres. La o a solucin de la tabla est indicada para pequeas organizaciones, siempre y cuando no estn conectadas a o a n e otra red. Simplemente se crea un chero que lista los nombres y direcciones de todos los hosts. Veamos parte de una tabla de este tipo:
HOST: 128.6.4.2, 128.6.25.2: ARAMIS.RUTGERS.EDU, ARAMIS: SUN-3-280: UNIX :: HOST: 128.6.4.3: GAUSS.RUTGERS.EDU, GAUSS: SUN-3-180: UNIX :: HOST: 128.6.4.4, 128.6.25.4: ATHOS.RUTGERS.EDU, ATHOS: SUN-4-280: UNIX ::
Como se puede apreciar, el formato es el siguiente: una l nea para cada sistema y listar sus direcciones, nombres y otra informacin sobre l. En el ejemplo, tanto ARAMIS como ATHOS estn en dos redes, as que o e a tienen dos direcciones. Adems, ambos tienen un nombre principal, por ejemplo ARAMIS.RUTGERS.EDU, a y apodos, por ejemplo ARAMIS. En caso de estar conectados a Internet, el nombre principal ser el nombre a de dominio completamente especicado. Se incluyen apodos cortos, para facilitar la tarea a nuestros usuarios. Hay otro formato muy frecuente para las tablas de hosts. Veamos un ejemplo:
128.6.4.2 128.6.25.2 128.5.4.3 128.6.4.4 128.6.25.4 aramis.rutgers.edu aramis.rutgers.edu gauss.rutgers.edu athos.rutgers.edu athos.rutgers.edu aramis aramis gauss athos athos
En este formato, cada l nea representa una direccin IP. Si el sistema tiene dos interfaces, hay dos l o neas de l en la tabla. Se debe procurar poner, en primer lugar, aquellas direcciones de uso ms comn. La e a u documentacin de su sistema le informar sobre el formato usado por l. o a e
15
En la conguracin ms simple, cada ordenador tiene su propia copia de la tabla de hosts en /etc/hosts. o a En caso de elegir esta conguracin, deberemos establecer procedimientos para asegurarnos que todas las o copias son actualizadas regularmente. En una red pequea no es dif mantener una tabla /etc/hosts en n cil cada mquina, y modicarla al agregar, eliminar o modicar nodos. Aunque resulta complicado cuando hay a muchas mquinas, ya que, en principio, cada una necesita una copia de /etc/hosts. a Una solucin a esto es compartir sta y otras bases de datos con el NIS, o sistema de informacin de red o e o ( Network Information System ), desarrollado por Sun Microsystems y conocido tambin como pginas e a amarillas o YP. En este caso, las bases de datos como la de /etc/hosts se mantienen en un servidor NIS central y los clientes accedern a ellas de forma transparente al usuario. En todo caso, esta solucin slo a o o es aconsejable para redes pequeas o medianas, ya que implican mantener un chero central /etc/hosts que n puede crecer mucho, y luego distribuirlo entre los servidores NIS. En redes grandes, y todos aquellos que estn conectados a Internet, debemos adoptar un nuevo sistea ma, el DNS o sistema de nombres por dominios (Domain Name System) diseado por Paul Mockapetris. n Tcnicamente, el DNS es una inmensa base de datos distribu jerrquicamente por toda la Internet; exise da a ten innidad de servidores que interactan entre si para encontrar y facilitar a las aplicaciones clientes que u los consultan la traduccin de un nombre a su direccion de red IP asociada, con la que poder efectuar la o conexin deseada. Cada parte de la base de datos est replicada en, al menos, dos servidores, lo que asegura o a una debida redundancia. Un servidor de nombres es un programa que se ejecuta en algunos de nuestros sistemas para tener conocimiento de los nombres. Cuando un programa necesita buscar un nombre, en lugar de hacerlo en una copia de la tabla de host, env una peticin al servidor de nombres. Este enfoque tiene a o dos ventajas: Para los grandes sistemas, es ms fcil tener al d las tablas en algunos servidores de nombres que en a a a todo el sistema. Si nuestra red est conectada a Internet, nuestro servidor de nombres ser capaz de dialogar con los a a servidores de nombres de otras organizaciones, para buscar nombres de cualquier sitio. Usar un servidor de nombres es el unico camino para tener un acceso completo a la informacin del resto de o los hosts de Internet. Es importante comprender la diferencia entre un servidor de nombres y un resolvedor. Un servidor de nombres es un programa que tiene acceso a una base de datos de hosts, y responde peticiones de otros programas. Un resolvedor es un conjunto de subrutinas que pueden cargarse con un programa. El resolvedor genera las peticiones que se enviarn al servidor de nombres, y procesa sus correspondientes respuestas. a Cada sistema deber usar un resolvedor (en general, el resolvedor es cargado por cada programa que va a a hacer uso de la red, puesto que slo es un conjunto de subrutinas). Hay que recalcar que slo se necesitarn o o a unos pocos servidores de nombres. Mucha gente confunde los dos enfoques y llega a creer que es necesario tener un servidor de nombres en cada ordenador. Para usar un resolvedor, cada ordenador necesitar un chero de conguracin, u otro mtodo, para espea o e cicar la direccin del servidor de nombres al que enviar nuestras peticiones. Por regla general, se pueden o declarar varios servidores de nombres, para el caso de que alguno de ellos no funcione correctamente. En el caso de que nuestro sistema no pudiera contactar satisfactoriamente con ningn servidor, la mayor de u a nuestro software empezar a fallar. Por tanto, hay que ser muy cuidadoso y declarar tantos servidores a como podamos para intentar asegurar un buen funcionamiento. Los servidores de nombres, generalmente, tienen un conjunto de opciones para su conguracin. En lugar de o dar algunos consejos sobre cmo congurar un servidor de nombres, vamos a recomendar dos documentos o ociales de los estndares de Internet. El RFC 1032 contiene las instrucciones sobre cmo conseguir un a o nombre de dominio del Centro de Informacin de Red, incluyendo los formularios necesarios. El RFC 1033 o contiene las instrucciones sobre cmo congurar un servidor de nombres. Todos estos documentos son de tipo o
5. Congurando el enrutamiento de cada ordenador
16
conceptual. Seguramente, tambin necesitar documentacin sobre el software espec e a o co de su servidor de nombres. En algunos casos, puede que se necesiten, a la vez, tablas y servidores de nombres. Si tenemos alguna implementacin de TCP/IP que no incluyan resolvers, estamos obligados a instalar tablas de hosts en o estos sistemas. Si nuestra red est conectada a Internet, vamos a tener problemas con aquellos sistemas que a no dispongan de resolvers, ya que Internet es demasiado grande para tener unas tablas de hosts de todos sus hosts. Por lo tanto, lo que se puede hacer es incluir una tabla de hosts con los hosts que realmente se tiene pensado usar. InterNIC tiene a su cargo una tabla de host que puede ser un buen punto de comienzo, aunque no es completa de ningn modo. As que tendremos que aadir los hosts favoritos de los usuarios. u n Los sistemas que usan resolvers no tendrn este problema, puesto que un servidor de nombres es capaz de a traducir cualquier nombre legal de host. Los nombres de hosts y la asignacin de nmeros son los unicos elementos que deben de tener una estructura o u centralizada. Sin embargo, puede haber otros elementos susceptibles de centralizacin. Es bastante frecuente o tener uno o dos ordenadores que se hagan cargo de todo el correo electrnico. Si estamos conectados a o Internet, es bastante simple establecer comunicaciones con otros ordenadores de Internet. No obstante, hay muchas instituciones que quieren comunicarse con sistemas de otras redes, como Bitnet o Usenet. Hay gateways entre varias de estas redes. Pero la eleccin del gateway correcto, y transformar la direccin de o o correo electrnico correctamente, es una tarea muy especializada. Por esto, en muchas ocasiones se congura o el software apropiado slo en un lugar, y todo el correo externo (o todo el correo externo a hosts que no o estn en Internet) se dirige a este sistema. a
Congurando el enrutamiento de cada ordenador
Todas las implementaciones TCP/IP necesitan alguna conguracin en cada host. En algunos casos, esto se o hace durante la instalacin del sistema de forma casi automtica. En otros casos, mediante la conguracin o a o de ciertos programas o cheros. Y, por ultimo, otros sistemas obtienen la informacin de conguracin a o o travs de la red de un servidor. e A pesar de que los detalles de la conguracin pueden diferir bastante, existen ciertos datos que deben o incluirse en todos los casos. Entre ellos: parmetros que describan a una mquina en particular, como su direccin IP; a a o parmetros que describan la red, como su submscara de red (si hubiera); a a software de enrutamiento y las tablas que use; otros programas necesarios para el funcionamiento de otras tareas de red. Antes de que se instale un ordenador en una red, un coordinador deber asignarle un nombre de red y su a direccin IP, como describimos anteriormente. Una vez otorgado un nombre y una direccin estamos en o o disposicin de congurarlo. En numerosas ocasiones, lo que debemos hacer es poner la direccin y el nombre o o en un chero de conguracin. Sin embargo, algunos ordenadores (especialmente aquellos que no disponen de o un disco propio en el que dicha informacin pueda ser almacenada) deben obtener esta informacin a travs o o e de la red. En el momento en que un sistema arranca, se realiza un broadcast a la red con la peticin quin o e soy?. En el caso de poseer ordenadores de este tipo, debemos asegurarnos de que nuestra red est preparada a para responder adecuadamente. La pregunta lgica es: cmo otro sistema sabe quin eres?. Generalmente, o o e esto se soluciona haciendo uso de las direcciones Ethernet (o las direcciones anlogas para otro tipo de redes). a Las direcciones Ethernet son asignadas por los fabricantes hardware. Est garantizado que slo una mquina a o a en todo el mundo tiene una determinada direccin Ethernet. Por lo general, dicha direccin est grabada en o o a una ROM en la tarjeta Ethernet de la mquina. La mquina, probablemente, no conozca su direccin IP, a a o
17
pero sin duda conoce su direccin Ethernet. Por esta razn, la peticin quin soy?incluye la direcci`n o o o e o Ethernet. Y habr sistemas congurados para responder a estas peticiones, buscando en una tabla que a hace corresponder a cada direccin Ethernet su direccin IP. Pero, por desgracia, deberemos congurar y o o actualizar esta tabla periodicamente. Para este n se usa el protocolo de RARP (Reverse Address Resolution Protocol); existe adems otro protocolo, el BOOTP o protocolo de arranque. En general, los ordenadores a estn diseados de tal manera que muestran su direccin Ethernet por pantalla, tan pronto como se enciende a n o el mismo. Y, en la mayor de los casos, disponemos de un comando que muestra esta informacin del interfaz a o Ethernet. Generalmente, la mscara de subred debe especicarse en un determinado archivo (en los sistemas Unix, el a comando ifcong , donde ifsignica interface, se usa para especicar tanto la direccin Internet como la o mscara de subred). No obstante, hay previsiones en los protocolos IP para permitir un broadcast de un a ordenador, preguntando por la mscara de red. La submscara de red es un atributo de la red y, por ello, es a a el mismo para todos los ordenadores de una determinada subred. No hay una tabla de subred independiente de la tabla de las correspondencias Ethernet/Internet, usada para consulta de direcciones. Idealmente, slo o determinados ordenadores contestan peticiones de la mscara de red, pero, en muchas implementaciones a TCP/IP, estn diseadas de tal manera que si un ordenador cree conocer la mscara de red debe contestar, a n a y, por tanto, en estas implementaciones, la mala conguracin de la mscara de subred en un solo ordenador o a puede causar un mal funcionamiento de la red. Por regla general, los cheros de conguracin hacen, a grosso modo, las siguientes cosas: o Cargar un driver especial para los dispositivos que sean necesarios (esto es bastante usual en los PCs, donde los accesos a red son controlados por una tarjeta controladora y un software que no forma parte del sistema operativo). Habilitar cada interfaz de red (Ethernet, l neas serie, etc.). Normalmente, esto conlleva la especicacin o de una direccin Internet y una mscara de red para cada uno, as como otras opciones especiales de o a cada dispositivo. Establecimiento de la informacin de enrutamiento de la red, tanto por comandos que establecen rutas, o como ejecucando un programa que las obtiene dinmicamente. a Activar el sistema de dominios (usado para buscar nombres y encontrar la correspondiente direccin o Internet -mirar la seccin del sistema de dominio, en la Introduccin al TCP/IP-). Los detalles depeno o dern del sistema de dominios usado. En la mayor de los casos, slo algunos hosts debern ejecutar a a o a el servidor de nombres de dominios. Los otros hosts, simplemente, necesitan cheros de conguracin, o que especican dnde se encuentra el servidor ms cercano. o a Establecer otro tipo de informacin necesaria para el sistema software, como, por ejemplo, el nombre o del propio sistema. Lanzar varios demonios (daemons). Hay programas que proveen de servicios de red a otros sistemas de la red, y a los usuarios de estos sistemas. En el caso de los PCs, que en muchos casos no soportan el multiproceso, y dichos servicios, se establecen mediante los llamados TSR, o mediante los drivers del dispositivo.
5.1
Como enrutar los datagramas
Si nuestro sistema consiste en una simple Ethernet, o un medio similar, no ser necesario prestar demasiada a atencin al enrutamiento. Pero, para sistemas ms complejos, cada una de las mquinas necesita una tabla o a a que contenga el gateway y el interfaz necesario para cada posible destino. Vimos un ejemplo simple en una seccin anterior, pero ahora es necesario describir el modo como funciona el enrutamiento, con un poco ms o a
18
de detalle. En la inmensa mayor de los sistemas, la tabla de enrutamiento tendr un aspecto similar (este a a ejemplo ha sido tomado de un sistema con Berkeley Unix, usando el comando "netstat -n -r" ; algunas columnas que contienen informacin estad o stica han sido omitidas):
Destino 128.6.5.3 128.6.5.21 127.0.0.1 128.6.4 128.6.6 128.6.7 128.6.2 10 128.121 default Gateway 128.6.7.1 128.6.7.1 127.0.0.1 128.6.4.61 128.6.7.26 128.6.7.26 128.6.7.1 128.6.4.27 128.6.4.27 128.6.4.27 Bandera UHGD UHGD UH U U U UG UG UG UG Interface il0 il0 lo0 pe0 il0 il0 il0 pe0 pe0 pe0
El sistema del ejemplo est conectado a dos Ethernet: a

Controlador il0 pe0 Red 128.6.7 128.6.4 Direccion 128.6.7.26 128.6.4.61 Otras Redes 128.6.6 ninguna
La primera columna muestra el nombre de la interface Ethernet; la segunda, es el nmero de red para esa u Ethernet; la tercera columna es la direccin Internet de esa red, y, la ultima muestra otras subredes que o comparten la misma red f sica. Estudiemos la tabla de enrutamiento; por el momento, ignoraremos las tres primeras l neas. La mayor parte de la tabla consiste en un conjunto de entradas describiendo las redes. Para cada red, las otras tres columnas muestran a dnde deben ser enviados los datagramas destinados a dicha red. Si aparece la bandera Gen o la tercera columna, los datagramas tienen que enviarse a travs de un gateway; en caso de no aparecer, el e ordenador est directamente conectado a la red en cuestin. As que los datagramas para dichas redes deben a o enviarse usando el controlador especicado en la cuarta columna. La bandera U, de la tercera columna, slo indica que la ruta especicada por esa l o nea est activa (generalmente, se asume que estar abierta, a a a no ser que se produzcan errores tras varios intentos). Las tres primera l neas muestran rutas a hosts, indicndose con Hen la tercera columna. Las tablas de a enrutamiento, normalmente, tienen entradas para redes o subredes. Por ejemplo, la entrada
128.6.2 128.6.7.1 UG il0
indica que un datagrama para cualquier ordenador de la red 128.6.2 (es decir, direcciones desde 128.6.2.1hasta 128.6.2.254) debe enviarse al gateway 128.6.7.1, para llevarlo a cabo. En algunas ocasiones, se establecen rutas para un ordenador espec co, en lugar de una red entera. En este caso, se usa una ruta al host. En la primera columna aparece una direccin completa, y la bandera Hest presente en la columna tres; por o a ejemplo, la entrada
128.6.5.21 128.6.7.1 UHGD il0
indica que un datagrama, dirigido en concreto a la direccin 128.6.5.21, debe ser enviado al gateway 128.6.7.1. o Al igual que en los enrutamientos a redes, la bandera Gse usa cuando en el enrutamiento se ve involucrado un gateway, y la bandera Dindica que el enrutamiento fue aadido dinmicamente, usando un mensaje n a ICMP de redireccin desde un gateway (ms adelante daremos ms detalles). o a a El siguiente enrutamiento es especial:
19
127.0.0.1
127.0.0.1
UH
lo0
donde, 127.0.0.1 es el dispositivo de lazo cerrado, o loopback. Cualquier datagrama enviado a travs de e este dispositivo aparece inmediatamente como entrada. Es muy util para hacer pruebas. Las direcciones de lazo cerradopueden, tambin, ser usadas para comunicar aplicaciones que estn en el propio ordenador. e a (Por qu molestarnos en usar la red para comunicarnos con programas que se encuentran en la misma e mquina?). a Por ultimo, hay una ruta por defecto (default), como es
default 128.6.4.27 UG pe0
Esta ruta ser seguida por aquellos datagramas que no se correspondan con ninguna de las anteriores. En a nuestro ejemplo, se enviarn a un gateway de direccin 128.6.4.27. a o Como ultimo ejemplo veamos la tabla de enrutamiento de un sistema Linux conectado a Internet mediante una linea PPP, usando el comando netstat -n -r; algunas columnas que contienen informacin estad o stica han sido omitidas.
Destino 172.16.1.33 128.0.0.1 0.0.0.0 Gateway 0.0.0.0 0.0.0.0 172.16.1.33 Bandera UH U UG Interface ppp0 l0 ppp0
Hay que aclarar que 0.0.0.0 representa al enrutamiento por defecto, es el valor numrico de default. En este e ejemplo, al sistema se le ha asignado la direccin IP 172.16.1.3 de forma dinmica, de manera que usa la o a linea PPP para conectarse con Internet, y 127.0.0.1 es el dispositivo loopback. Antes de la conexin PPP o solamente estaba activo el dispositivo de lazo cerrado, pero una vez establecida la conexin PPP se activa o el interface ppp0 ( 0 indica un identicativo de interface ppp; es decir, si hubiera otra l nea ppp se etiquetar a como ppp1, etc), se usa el sistema del otro lado de la linea como un gateway por defecto, como se puede apreciar en la ultima linea. En muchos sistemas, los datagramas son enrutados consultando la direcin de destino en una tabla como la o que acabamos de describir. Si la direccin se corresponde con una ruta espec o ca a un host, sta ser usada; e a en otro caso, si se corresponde con un enrutamiento a red, se usar sta; y, si nada de lo anterior acontece, ae se usar el enrutamiento por defecto. En caso de no existir uno por defecto, aparecer un mensaje de tipo a a red inalcanzable(network is unreachable). En las siguientes secciones describiremos varias maneras de congurar estas tablas de enrutamiento. Generalmente, la operacin de enviar datagramas no depende del mtodo usado en la conguracin de estas o e o tablas. Cuando un datagrama va a ser enviado, su destino es consultado en la tabla. Los distintos mtodos e de enrutamiento son simplemente, ms o menos, una serie de sosticadas formas de congurar y mantener a las tablas.
5.2
Rutas jas
La forma ms fcil de congurar el enrutamiento es usar comandos que lo jan. Nuestros archivos de a a inicializacin contienen comandos que conguran el enrutamiento. Si es necesario algn cambio, deber o u a hacerse, normalmente, usando comandos que aaden y borran entradas de la tabla de enrutamiento (cuando n se realice un cambio, no debemos olvidar actualizar el chero de inicializacin tambin). Este mtodo es o e e prctico para redes relativamente pequeas, especialmente cuando los cambios no son muy frecuentes. a n Muchos ordenadores conguran automticamente algunas entradas de enrutamiento por nosotros. Unix a aade una entrada para las redes a las que estamos directamente conectados. Por ejemplo, un chero de n inicializacin podr ser o a
20
ifconfig ifconfig
ie0 ie1
128.6.4.4 128.6.5.35
netmask netmask
255.255.255.0 255.255.255.0
Este especica que hay dos interfaces de red y sus direcciones en ellas. El sistema crea automticamente a estas entradas en la tabla de enrutamiento
128.6.4 128.6.5 128.6.4.4 128.6.5.35 U U ie0 ie1
y, en sta, se especica que los datagramas para las redes locales 128.6.4 y 128.6.5 deben ser enviados a las e corespondientes interfaces. Adems de stos, el chero de inicializacin podr contener comandos para denir rutas a cualquier otra a e o a red a la que queramos acceder. Por ejemplo,
route route add add 128.6.2.0 128.6.6.0 128.6.4.1 128.6.5.35 1 0
Estos comandos determinan que para alcanzar la red 128.6.2 debemos usar el gateway de direccin 128.6.5.1, o y esa red 128.6.6 es, realmente, un nmero de red adicional para una red f u sica conectada al interface 128.6.5.35. Otro tipo de software puede usar comandos distintos a estos casos. Unix se diferencia de ellos por el uso de una mtrica, que es el nmero nal del comando. La mtrica indica cuntos gateways tiene que e u e a atravesar un datagrama para alcanzar su destino. Rutas de mtrica 1 ms indican que hay en el camino e o a slo un gateway hasta el destino. Rutas de mtrica 0 indican que no hay ningn gateway implicado -es un o e u nmero de red adicional para la red local-. u En ultimo lugar, podemos denir un enrutamiento por defecto, usado cuando el destino no est listado a expl citamente. Normalmente, se suele acompaar de la direccin de un gateway que tiene suciente inforn o macin como para manejar todos los posibles destinos. o Si nuestra red slo dispone de un gateway, entonces slo necesitaremos una sola entrada por defecto. En o o este caso, no deberemos preocuparnos ms de la conguracin del enrutamiento de los hosts (el gateway, a o en s necesitar ms atencin, como veremos). Las siguientes secciones nos ayudarn para congurar redes , a a o a donde hay varios gateways.
5.3
Reconducir el enrutamiento
La mayor de los expertos recomiendan dejar las decisiones de enrutamiento a los gateways. Por tanto, a probablemente, ser una mala idea tener largas tablas estticas de enrutamiento en cada ordenador. El a a problema est en que cuando algo cambia en la red tenemos que actualizar las tablas en demasiados ordea nadores. Si el cambio ocurre debido a que cae una l nea, el servicio no se restablecer hasta que alguien se a de cuenta del problema y cambie todas las tablas de enrutamiento. La manera ms fcil de tener actualizado el enrutamiento es depender slo de un unico gateway y actualizar a a o su tabla de enrutamiento. Este gateway debe jarse como gateway por defecto. (En Unix esto signica usar un comando como route add default 128.6.4.27 1, donde 128.6.4.27 es la direccin del gateway). Como o describimos anteriormente, el sistema enviar todos aquellos datagramas a dicho gateway cuando no haya a una ruta mejor. En principio, parece que esta estrategia no es demasiado buena cuando poseemos ms de a un gateway; mxime, cuando todo lo que tenemos es slo la entrada por defecto. Cmo usaremos los a o o otros gateways en los casos en los que stos sean ms recomendables? La respuesta es que los datagramas e a correspondientes sern redirigidos a estos gateways en estos casos. Un redireccionamientoes una clase a espec ca de mensaje ICMP (Internet Control Message Protocol), que contiene informacin del tipo En el o futuro, para llegar a la direccin XXXXX, intenta usar YYYYY en lugar de m Las implementaciones o .
21
que cumplen completamente los protocolos TCP/IP usan estas tcnicas de redireccionamiento para aadir e n entradas a las tablas de enrutamiento. Supongamos que una tabla inicialmente es como sigue:
Destino Gateway Bandera Interface +------------------------------------------------------------+ | 127.0.0.1 | 127.0.0.1 | UH | lo0 | +--------------+--------------+---------------+--------------+ | 128.6.4 | 128.6.4.61 | U | pe0 | +--------------+--------------+---------------+--------------+ | default | 128.6.4.27 | UG | pe0 | +------------------------------------------------------------+
donde hay una entrada para la red local 128.6.4, y una entrada por defecto del gateway 128.6.4.27. Supongamos que hay tambin un gateway 128.6.4.30, que es el mejor camino para acceder a la red 128.6.7. Cmo e o podemos llegar a usar este camino? Supongamos que tenemos unos datagramas para enviar a 128.6.7.23. El primer datagrama llegar al gateway por defecto, puesto que es el unico que aparece en la tabla de a enrutamiento, y el gateway se dar cuenta de que el mejor camino debe pasar por 128.6.4.30 (Hay distina tos mtodos para que un gateway determine que debe usarse otro para un mejor enrutamiento). Por tanto, e 128.6.4.27 contestar con un mensaje de redireccionamiento especicando que los datagramas para 128.6.7.23 a deben enviarse a travs del gateway 128.6.4.30. El software TCP/IP aadir una entrada a la tabla de e n a enrutamiento
128.6.7.23 128.6.4.30 UDHG pe0
De esta manera, los restantes datagramas al 128.6.7.23 se enviarn directamente al gateway apropiado. a Esta estrategia ser perfecta si no fuera por los siguientes tres problemas: a Necesita que cada ordenador contenga la direccin de un gateway por defecto en los cheros de cono guracin. o En caso de que un gateway falle, las entradas de las tablas de enrutamiento que usan dicho gateway no se eliminan. Si la red usa subredes y la implementacin TCP/IP usada no las maneja, esta estrategia no podr o a emplearse. El alcance del problema depende del tipo de red de la que disponemos. Para redes pequeas, apenas n supondr un problema cambiar los cheros de conguracin de algunas mquinas. Sin embargo, para algunas a o a organizaciones este trabajo es dif de llevar a cabo. Si, por ejemplo, la topolog de la red cambia y un cil a gateway es eliminado, cualquier sistema que tenga dicho gateway por defecto deber ser ajustado. Este a problema ser especialmente grave si el personal encargado del mantenimiento de la red es distinto del a encargado de mantener a los sistemas individualmewnte. La solucin ms simple consiste en asegurarnos de o a que la direccin por defecto nunca cambiar. Por ejemplo, podr o a amos adoptar el convenio de que la direccin o 1 de cada subred se corresponde con el gateway por defecto de cada subred; as en la subred 128.6.7, el , gateway por defecto ser siempre el 128.6.7.1. Si dicho gateway es eliminado, habr que asignarle dicha a a direccin a algn otro gateway (siempre tendr que haber, al menos, un gateway, puesto que si no es as o u a estaremos completamente incomunicados). Hasta ahora hemos visto cmo aadir rutas, pero no cmo deshacernos de ellas. Qu ocurre si un gateway o n o e no funciona correctamente?. Nuestro deseo ser que se recondujera a un gateway operativo, pero desgraa ciadamente, un gateway en mal funcionamiento no tendr en general esta capacidad de redireccionamiento. a La solucin ms obvia es usar gateways ables. El redireccionamiento puede usarse para controlar distintos o a tipos de fallos.
22
La mejor estrategia para controlar gateways averiados es que nuestra implementacin TCP/IP detecte las o rutas que no tienen xito. TCP mantiene varios contadores que permiten al software detectar cundo una e a conexin se ha roto. Cuando esto ocurre, se puede marcar esta ruta como fallida y volver al gateway por o defecto. Una solucin similar puede usarse para manejar fallos en el gateway por defecto. Si conguramos dos o gateways por defecto, entonces el software deber ser capaz de cambiar el gateway cuando las conexiones a en uno de ellos empiecen a fallar. Sin embargo, algunas implementaciones TCP/IP no pueden marcar rutas como fallidas y empezar a usar otras. En particular, Berkeley 4.2 Unix no lo hace; pero Berkeley 4.3 Unix s lo que empieza a hacerse cada vez ms comn. Hasta implementaciones de Unix para PC como Linux ya , a u incorporan esta posibilidad (Linux en concreto puede controlar hasta cuatro gateways por defecto).
5.4
Otros mtodos para que los hosts encuentren rutas e
En tanto en cuanto las implementaciones TCP/IP manejan ca das de las conexiones adecuadamente, estableciendo una o ms rutas por defecto en el chero de conguraciones, se produce probablemente la foma a ms simple de controlar el enrutamiento. No obstante, hay otras dos tcnicas de enrutamiento dignas de a e consideracin para algunos casos especiales: o espiar el protocolo de enrutamiento, usar un proxy ARP. 5.4.1 Espiar el enrutamiento.
Los gateways, por regla general, tienen un protocolo especial que usan entre ellos. Hay que aclarar que el redireccionamiento no puede ser usado por los gateways, ya que ste es simplemente el mecanismo por el e cul ellos informan a simples hosts que tienen que usar otro gateway. Los gateways deben tener una visin a o completa de la red y un mtodo para para calcular la ruta ptima a cada subred. Generalmente, los gateways e o mantienen esta visin mediante el intercambio de informacin entre ellos. Hay varios protocolos distintos o o de enrutamiento para este propsito. Una alternativa para que un ordenador siga la pista a los gateways o esescuchar los mensajes que se intercambian entre ellos. Hay software capaz de hacer esto para la mayor a de los protocolos. Cuando ejecutamos este software, el ordenador mantendr una visin completa de la a o red, al igual que los gateways. Este software normalmente est diseado para mantener dinmicamente las a n a tablas de enrutamiento del ordenador, as que los datagramas se enviarn siempre al gateway ms adecuado. a a De hecho, el enrutamiento realizado es equivalente a ejecutar los comandos Unix route addy route deletea medida que la topolog cambia. El resultado suele ser una completa tabla de enrutamiento, en lugar de a una con unas rutas por defecto. (Este enfoque asume que los gateways mantienen entre ellos una tabla completa. Algunas veces los gateways tienen constancia de todas nuestras redes, pero usan una ruta por defecto para las redes ajenas al campus, etc.). Ejecutando el software de enrutamiento en cada host resolveremos de alguna manera el problema de enrutamiento, pero hay algunas razones por las que normalmente no es recomendable, reservndola como ultima a alternativa. El problema ms serio incorpora numerosas opciones de conguracin, que deben mantenerse a o en cada ordenador. Adems, los actuales gateways suelen aadir opciones cada vez ms complejas. Por a n a tanto, no es deseable extender el uso de este software en todos los hosts. Hay otro problema ms espec a co referido a los ordenadores sin discos. Como es natural, un ordenador sin discos depende de la red y de los servidores de cheros para cargar los programas y hacer swapping. No es recomendable que estos ordenadores escuchen las emisiones de la red. Por ejemplo, cada gateway de la red debe emitir sus tablas de enrutamiento cada 30 segundos. El problema es que el software que escucha estas emisiones debe ser cargado a travs de la red. En un ordenador ocupado, los programas que no e son usados durante algunos segundos deben guardarse haciendo swapping o paginacin. Cuando se activan o de nuevo, han de recuperarse. Cuando una emisin de un gateway es enviada en la red, cada ordenador o
23
activa su software de red para procesar dicha emisin, lo cual signica que todos ellos intentan hacer una o recuperacin al mismo tiempo y, por tanto, es probable que se produzca una sobrecarga temporal de la red. o 5.4.2 Proxy ARP.
Los proxy ARP son otra tcnica para permitir a los gateways tomar todas las decisiones de enrutamiento. e Son aplicables a aquellas redes que usan ARP (Address Resolution Protocol), o una tcnica similar para e corresponder las direcciones Internet con direcciones de redes espec cas, como las direcciones Ethernet. Para facilitar la explicacin, vamos a asumir redes Ethernet. Los cambios necesarios para otros tipos de o redes consistirn en poner la correspondiente direccin de red, en lugar de direccin Ethernet, y protocolo a o o anlogo a ARP para dicha red. a En muchos aspectos, los proxy ARP son semejantes al uso de una ruta por defecto y redireccionamiento, y la mayor diferencia radica en que tienen distintos mecanismos para comunicar rutas a los hosts. Con el redireccionamiento se usa una tabla completa de enrutamiento, de forma que en cualquier momento un host sabe a cual gateway debe enviar los datagramas. En cambio, los proxy ARP prescinden de las tablas de enrutamiento y hacen todo el trabajo a nivel de direcciones Ethernet. Los proxy ARP pueden usarse para todos los destinos, tanto para aquellos que estn en nuestra red como para algunas combinaciones de a destinos. El caso ms sencillo de explicar es el de todas las direcciones; para ello ordenamos al ordenador a que simule que todos los ordenadores del mundo estn conectados directamente a nuestra Ethernet local. a En Unix, esto se hace usando el comando
route add default 128.6.4.2 0
donde, 128.6.4.2 es la direccin IP de nuestro host. Como ya hemos visto, la mtrica 0 provoca que todo o e aquello que se identique con esta ruta se enviar directamente a la red local Ethernet. Alternativamente, a otros sistemas nos permiten conseguir el mismo efecto jando una mscara de red de ceros, en cuyo caso a debemos asegurarnos de que no ser alterada por un mensaje ICMP de mscara de subred debido a que un a a sistema conoce la verdadera mscara de red. a Cuando un datagrama va a ser enviado a un destino dentro de la Ethernet local, el ordenador necesita conocer la direccin Ethernet del destino, y para ello, generalmente, se usa la llamada tabla ARP, que contiene las o correspondencias entre las direcciones Internet y las direcciones Ethernet. Veamos un ejemplo t pico de tabla ARP (en la mayor de los sistemas se visualiza usando el comando @.): a
FOKKER.RUTGERS.EDU (128.6.5.16) at 8:0:20:0:8:22 temporary CROSBY.RUTGERS.EDU (128.6.5.48) at 2:60:8c:49:50:63 temporary CAIP.RUTGERS.EDU (128.6.4.16) at 8:0:8b:0:1:6f temporary DUDE.RUTGERS.EDU (128.6.20.16) at 2:7:1:0:eb:cd temporary W2ONS.MIT.EDU (128.125.1.1) at 2:7:1:0:eb:cd temporary OBERON.USC.EDU (128.125.1.1) at 2:7:1:2:18:ee temporary gatech.edu (128.61.1.1) at 2:7:1:0:eb:cd temporary DARTAGNAN.RUTGERS.EDU (128.6.5.65) at 8:0:20:0:15:a9 temporary
Como dijimos anteriormente, simplemente es una lista de direcciones IP y su correspondiente direccin o Ethernet. El trmino temporaryindica que la entrada fue aadida dinmicamente usando ARP, en lugar e n a de ser puesta manualmente. Si hay una entrada para una direccin determinada en la tabla ARP, los datagramas sern puestos en la o a Ethernet con su correspondiente direccin Ethernet. Si esto no ocurre, se enviar una peticin ARP, o a o solicitando que el host destino se identique. La peticin es, en efecto, una pregunta: Puede decirme el o host con direccin Internet 128.6.4.194 cul es su direccin Ethernet?. Cuando llega una respuesta, esta se o a o aade a la tabla ARP y los futuros datagramas con ese destino sern enviados directamente. n a
24
Este mecanismo fue diseado inicialmente slo para hosts que estuvieran directamente conectados a una n o simple Ethernet. Si necesitamos comunicarnos con un host que se encuentra en otra Ethernet, se supone que la tabla de enrutamiento lo dirigir a un gateway. Dicho gateway, como es obvio, deber tener una a a interface en nuestra Ethernet. El host deber averiguar la direccin de dicho gateway usando ARP. Este a o procedimiento es ms util que hacer que el ARP trabaje directamente con un ordenador en una red lejana, a puesto que no estn en la misma Ethernet, no disponemos de una direccin Ethernet para poder enviar los a o datagramas y, al enviar peticiones ARPpor ellas, nadie nos responder. a Los proxies ARP se basan en la idea de que los gateways acten como proxies de hosts lejanos. Supongamos u que tenemos un host en la red 128.6.5, con direcciones (es el ordenador A en diagrama siguiente), que va a enviar un datagrama al host 128.6.5.194 (el ordenador C) que se encuentra en una Ethernet distinta (subred 128.6.4). Hay un gateway que conecta ambas subredes, de direcciones 128.6.5.1 (gateway R)
red 1 red 2 128.6.5 128.6.4 ============================ ================== | | | | | | ___|______ _____|____ __|____|__ __|____|____ 128.6.5.2 128.6.5.3 128.6.5.1 128.6.4.194 128.6.4.1 ___________ ___________ __________ ____________ ordenador A ordenador B gateway R ordenador C
Ahora supongamos que el ordenador A env una peticin ARP al ordenador C, pero C no es capaz de a o responder por s mismo. Al estar en redes distintas, C nunca ver la peticin ARP; sin embargo, el gateway a o actuar en su lugar. En efecto, nuestro ordenador pregunta: Puede decirme el host con direccin de Intera o net 128.6.4.194 cul es su direccin Ethernet?, y el gateway contesta: Yo soy 128.6.4.194 es 2:7:1:0:eb:cd, a o donde 2:7:1:0:eb:cd es la direccin Ethernet del gateway. Este pequeo truco funciona correctamente y hace o n pensar a nuestro host que 128.6.4.194 est conectado a la Ethernet local con direccin 2:7:1:0:eb:cd, pero, a o por supuesto, no es cierto. Cada vez que enviamos un datagrama a 128.6.4.194, nuestro host lo env a la a direccin Ethernet especicada y, puesto que es la direccin del gateway R, llega hasta dicho gateway. Y es o o entonces cuando se env a su destino. a Veamos que esto tiene el mismo efecto que tener una entrada en la tabla de enrutamiento diciendo que la ruta de 128.6.4.194 al gateway 128.6.5.1 es:
128.6.4.194 128.6.5.1 UGH pe0
Con la excepcin de que, en lugar de tener el enrutamiento hecho a nivel de tabla de enrutamiento, se hace o a nivel de tabla ARP. Generalmente, es mejor usar tablas de enrutamiento, pero hay algunos casos en los que tiene sentido los usar proxyes ARP: cuando tenemos un host que no trabaja con subredes; cuando tenemos un host que no responde adecuadamente al redireccionamiento; cuando no queremos elegir un gateway determinado por defecto; cuando el software no es capaz de recuperarse de un enrutamiento fallido. La tcnica fue diseada originariamente para trabajar con hosts que no soportan subredes. Supongamos e n que tenemos una red dividida en subredes. Por ejemplo, hemos decidido dividir la red 128.6 en subredes,
25
obteniendo las subredes 128.6.4 y 128.6.5. Supongamos tambin que tenemos un host que no trabaja con e subredes y, por tanto, creer que 128.6 es tan slo una red. Esto ultimo signica que ser dif establecer a o a cil las entradas para la tabla de enrutamiento para la conguracin vista. No podemos decirle nada sobre la o existencia del gateway, de forma expl cita, usando route add 128.6.4.0 128.6.5.1 1, puesto que, al considerar que toda la 128.6 es una simple red, no entender que intentamos enviarlo a una subred. En su lugar, a interpretar este comando como un intento de congurar una ruta a un host de direccin 128.6.4.0. La unica a o manera que podr hacerlo funcionar ser establecer rutas expl a a citas a los host, para cada host individual sobre cada subred. Tampoco podr amos depender del gateway por defecto y redireccionar. Supongamos que establecemos route add default 128.6.5.1 1, en el que jamos el gateway 128.6.5.1 por defecto; esto no podr funcionar para enviar datagramas a otras subredes. En el caso de que el host 128.6.5.2 quiera a enviar un datagrama al 128.6.4.194, puesto que el destino es parte de 128.6, el ordenador lo considerar en a la misma red y no se preocupar por buscarle un gateway adecuado. a Los proxy ARP resuelven el problema haciendo ver el mundo de un modo simplista que espera encontrarse. Puesto que el host piensa que todas las restantes subredes forman parte de su propia red, simplemente usar una peticin ARP para comunicarse con ellas, esperando recibir una direccin Ethernet que pueda a o o usarse para establecer comunicaciones directas. Si el gateway ejecuta un proxy ARP, responder con la a direccin Ethernet del gateway. Por tanto, los datagramas sern enviados al gateway y todo funcionar o a a correctamente. Como se puede observar, no se necesita una conguraci`n espec o ca para usar una proxy ARP con hosts que no trabajan con subredes. Lo que necesitamos es que todos nuestros gateways ARP tengan implementado un proxy ARP. Para poder usarlos, deberemos especicar la conguracin de la tabla de enrutamiento. Por o defecto, las implementaciones TCP/IP esperarn encontrar un gateway para cualquier destino que est en a e otra red y, para hacerlo, deberemos expl citamente instalar una ruta de mtrica 0, como por ejemplo route e add default 128.6.5.2 0, o poner la mscara de subred a ceros. a Es obvio que los proxy ARP son adecuados cuando los hosts no son capaces de entender subredes. Generalmente, las implementaciones TCP/IP son capaces de manejar mensajes de redireccin ICMP correctamente, o y, por tanto, normalmente lo que se har es congurar la ruta por defecto a algn gateway. Sin embargo, a u en caso de contar con una implementacin que no reconoce los redireccionamientos, o no puede congurarse o un gateway por defecto, podemos usar proxy ARP. A veces se usa proxy ARP por conveniencia. El problema de las tablas de enrutamiento es que hay que congurarlas. La conguracin ms simple es jar una ruta por defecto; pero, incluso en este caso, hay que o a incluir un comando equivalente al de Unix @. En el caso de que hubiese cambios en las direcciones de los gateways, deber amos modicar este comando en todos los hosts. Si conguramos una ruta por defecto que depende de proxy ARP (con mtrica 0), no deberemos cambiar los cheros de conguracin cuando los e o gateways cambian. Con los proxy ARP, no hace falta poner ninguna direccin de un gateway. Cualquier o gateway puede responder a una peticin ARP, no importa cul sea su direccin. o a o Para evitarnos tener que congurar los sistemas, algunas implementaciones TCP/IP usan ARP por defecto, cuando no tienen otra ruta. Las implementaciones ms exibles nos permiten usar estrategias mixtas. As a , si tenemos que especicar una ruta para cada red en particular, o una ruta por defecto, se usar esa ruta, a pero si no hay rutas para un destino lo tratar como si fuese local y usar una peticin ARP. En tanto a a o en cuanto sus gateways soporten proxy ARP, esto permitir que los hosts alcancen cualquier destino sin a necesitar ninguna tabla de enrutamiento. Finalmente, podr amos elegir usar una proxy ARP porque se recuperan mejor de los fallos. La eleccin o depender en gran medida de la implementacin. a o En aquellas situaciones en las que hay varios gateways en una red, veamos cmo los proxy ARP permiten o elegir el mejor. Como hemos mencionado anteriormente, nuestro computador simplemente env un mensaje a preguntando por la direccin Ethernet del destino. Suponemos que los gateways estn congurados para o a responder a estos mensajes. Si hay ms de un gateway, ser necesaria una coordinacin entre ellos. Cona a o
26
ceptualmente, los gateways tendrn una visin completa de la topolog de la red. Por consiguiente, sern a o a a capaces de determinar la mejor ruta desde nuestro host a cualquier destino. Si hay una coordinacin entre o los gateways, ser posible que el mejor gateway pueda responder a la peticin ARP. En la prctica no es a o a siempre posible, por ello se disean algoritmos para evitar rutas malas. Veamos por ejemplo la siguiente n situacin: o
1 2 3 ------------ A ------------ B -----------
donde, 1, 2 y 3 son redes; y A y B gateways conectando 2 con 1 con 3. Si un host de la red 2 quiere o comunicarse con otro de la red 1 es bastante fcil para el gateway A decidirse a contestar, y el gateway B no a lo har. Veamos cmo: si el gateway B acepta un datagrama para la red 1, tendr que remitirlo al gateway a o a A para que lo entregue. Esto signicar que deber tomar un datagrama de la red 2 y enviarlo de vuelta a a a la red 2. Es muy fcil manejar las rutas que se dan en este tipo de redes. Es mucho ms dif de controlar a a cil en una situacin como la siguiente: o
1 --------------A B | | 4 | | 3 | C | | | | 5 D E --------------2
Supongamos que un ordenador en la red 1 quiere enviar un datagrama a otro de la red 2. La ruta v A y a D es probablemente la mejor, porque slo hay una red (3) entre ambas. Tambin es posible la ruta v B, o e a C y E, pero este camino probablemente es algo ms lento. Ahora supongamos que el ordenador de la red 1 a env peticiones ARP para alcanzar 2. Seguramente A y B respondern a dicha peticin. B no es tan buena a a o como A, pero no hay tanta diferencia como en el caso anterior. B no devolver el datagrama a 1. Adems, a a no es posible determinar qu camino es mejor sin realizar un costoso anlisis global de la red. En la prctica e a a no disponemos de tanta cantidad de tiempo para responder a una peticin ARP. o 5.4.3 Establecer nuevas rutas tras fallos.
En principio, IP es capaz de controlar l neas con fallos y ca das de gateways. Hay varios mecanismos para recticar las tablas de enrutamiento y las tablas de ARP y mantenerlas actualizadas. Pero, por desgracia, muchas de las implementaciones TCP/IP no implementan todos estos mecanismos, por lo que deberemos estudiar detalladamente la documentacin de nuestra implementacin y, teniendo en cuenta los fallos ms o o a frecuentes, deberemos denir una estrategia para asegurar la seguridad de nuestra red. Las principales elecciones son las siguientes: espiar el protocolo de enrutamiento de los gateways, establecer una ruta por defecto y hacer uso del redireccionamiento y usar proxy ARP. Todos estos mtodos tienen sus propias e limitaciones dependiendo del tipo de red. Espiar el protocolo de enrutamiento de los gateways es, en teor la solucin ms directa y simple. Si a, o a suponemos que los gateways usan una buena tecnolog de enrutamiento, las tablas que ellos env deber a an an contener la informacin necesaria para mantener unas rutas ptimas para todos los destinos. Si algo cambia o o en la red (una l nea o un gateway falla), esta informacin deber reejarse en las tablas y el software de o a enrutamiento deber ser capaz de actualizar adecuadamente las tablas de enrutamiento de los hosts. Las a
27
desventajas de esta estrategia son meramente prcticas, pero, en algunas situaciones, la robustez de este a enfoque puede pesar ms que dichas desventajas. Veamos cules son estas desventajas: a a Si los gateways usan un protocolo de enrutamiento sosticado, la conguracin puede ser bastante o compleja, lo que se convierte en un problema ya que debemos congurar y mantener los cheros de conguracin de cada host. o Algunos gateways usan protocolos espec cos de alguna marca comercial. En este caso, es posible que no encontremos un software adecuado para nuestros hosts. Si los hosts carecen de disco, puede que haya serios problemas a la hora de escuchar las emisiones. Algunos gateways son capaces de traducir su protocolo interno de enrutamiento en otro ms simple a que puede ser usado por los hosts. Esta podr ser una forma de resolver las dos primeras desventajas. a Actualmente no hay una solucin denitiva para la tercera. o Los problemas de los mtodos de rutas por defecto/redireccionamiento y de los proxy ARP son similares: e ambos tienen problemas para trabajar con situaciones donde las entradas a las tablas no se usan durante un largo periodo de tiempo. La unica diferencia real entre ellos son las tablas que se ven involucradas. Supon gamos que un gateway cae, si alguna de las actuales rutas usan ese gateway no podr ser usada. En el caso a de que estemos usando tablas de enrutamiento, el mecanismo para ajustar las rutas es el redireccionamiento. Esto funciona perfectamente en dos situaciones: cuando el gateway por defecto no est en la mejor ruta. El gateway por defecto puede dirigirlo a un a gateway mejor; cuando una l nea distante o un gateway falla. Si esto cambia la mejor ruta, el gateway actual nos dirigir hacia el gateway que ahora es el mejor. a El caso que no est a salvo de problemas es cuando el gateway a que se le env datagramas falla en ese a a momento. Puesto que est fuera de servicio, es imposible que redireccione a otro gateway. En muchos casos, a tampoco estamos a salvo si el gateway por defecto falla, justo cuando el enrutamiento empieza a enviar al gateway por defecto. La casu stica de los proxy ARP es similar. Si los gateways se coordinan adecuadamente, en principio el gateway indicado responder adecuadamente. Si algo en la red falla, el gateway que actualmente se est a a usando nos reconducir a un nuevo y mejor gateway. (Normalmente es posible usar redireccionamiento para a ignorar las rutas establecidas por el proxy ARP). Otra vez, el caso que no podemos proteger de fallos es cuando el gateway actual falla. No hay equivalencia al fallo de los gateways por defecto, puesto que cual quier gateway puede responder a una peticin ARP. o As que el gran problema es el fallo debido a que el gateway en uso no se puede recuperar, por el hecho de que el principal mecanismo para alterar las rutas es el redireccionamiento, y un gateway en mal funciona miento no puede redirigir. Tericamente, este problema podr solucionarse a travs de la implementacin TCP/IP, o a e o usando timeout". Si un ordenador no recibe respuesta una vez terminado el timeout, debera de cancelar la ruta actual y tratar de encontrar otra nueva. Cuando usamos una ruta por defecto, esto significa que la implementacin TCP/IP puede ser capaz de declarar o una ruta como fallida en base al timeout. En caso de que se haya redirigido a un gateway distinto del de por defecto, y la ruta se declare fallida, el trfico se devolver al a a gateway por defecto. El gateway por defecto puede entonces empezar a manejar el trfico, a o redirigirlo a un gateway diferente. Para manejar los fallos del gateway por defecto es posible tener ms de un gateway por defecto; si uno de ellos se declara fallido, se usar a a el otro. En conjunto, estos mecanismos nos salvaguardan de cualquier fallo.
6. Puentes y gateways
28
Mtodos similares pueden usarse en sistemas que dependen de proxy ARP. Si una conexin e o sobrepasa el timeout, la entrada de la tabla ARP usada se debe borrar. Esto causar una a peticin ARP, que podr ser contestada por un gateway que funcione correctamente. El o a mecanismo ms simple para llevar esto a cabo podra ser usar los contadores de timeout a para todas las entradas ARP. Puesto que las peticiones ARP no son muy costosas en tiempo, cada entrada cuyo timeout concluya ser borrada, incluso si estaba funcionando a perfectamente. As, su prximo datagrama ser una nueva peticin. Las respuestas, o a o normalmente, son suficientemente rpidas para que el usuario no se de cuenta del retraso a introducido. Sin embargo, algunas implementaciones no usan estas estrategias. En Berkeley 4.2 no hay manera de librarse de ningn tipo de entrada, ni de la tabla de enrutamiento ni de u la tabla ARP. Estas implementaciones no invalidan las entradas, stas fallan. Luego si e los problemas de fallos de gateways son ms o menos comunes, no habr otra opcin que a a o ejecutar un software que escuche el protocolo de enrutamiento. En Berkeley 4.3, las entradas son eliminadas cuando las conexiones TCP fallan, pero no las ARP. Esto hace que la estrategia de la ruta por defecto sea ms atractiva que la de proxys ARP, si usamos a Berkeley 4.3. Si, adems, inclumos ms de una ruta por defecto se posibilitar la a a a recuperacin de fallos cuando falle un gateway por defecto. Si una ruta est siendo o a usada slo por servicios basados en el protocolo UDP, no habr una recuperacin de fallos o a o si el gateway implicado cae. Mientras que los servicios "tradicionales"TCP/IP hacen uso del protocolo TCP, algunos otros, como el sistema de ficheros de red, no lo hacen. Por tanto, la versin 4.3 no nos garantiza una recuperacin de fallos absoluta. o o Por ltimo, tambin podemos hablar de otras estrategias usadas por algunas antiguas u e implementaciones. Aunque estn casi en desuso, vamos a describirlas de forma a esquemtica. Estas implementaciones detectan un fallo de un gateway haciendo a comprobaciones de qu gateways estn en uso. Para ello, la mejor forma de hacer estas e a comprobaciones es hacer una lista de gateways que actualmente se estn usando (para lo e que se ayuda de la tabla de enrutamiento) y cada minuto se enva una peticin de "echoa o cada gateway de la citada lista; si el gateway no enva una respuesta se declara como fallido, y todas las rutas que hacen uso de l se reconducirn al gateway por defecto. e a Generalmente, se deber de proporcionar ms de un gateway por defecto, de manera que a a si el gateway por defecto falla se elige uno de los alternativos. En otros casos no es necesario especificar un gateway por defecto, ya que el software, aleatoriamente, eligir a un gateway que responda. Estas implementaciones son muy flexibles y se recuperan bien de los fallos, pero una gran red con esta implementacin malgastar el ancho de banda con o a datagramas "echo"para verificar qu gateways funcionan correctamente. Esta es la razn e o por la que esta estrategia est en desuso. a
Puentes y gateways
En esta seccin vamos a tratar con ms detalle la tecnologa usada para construir grandes o a redes. Vamos a centrarnos especialmente en cmo conectar varias Ethernet, token rings, o etc. Hoy da la mayora de las redes son jerrquicas. Los hosts estn includos en a a una red de rea local, como una Ethernet o un token ring. Estas redes se conectan a entre s mediante alguna combinacin de redes principales o enlaces punto a punto. Una o universidad puede tener una red como se muestra, en parte, a continuacin: o
________________________________ | red 1 red 2 red 3 |
red 4
red 5
29
| ---------X---------X-------- | --------------| | | | | | Edificio A | | | | | ----------X--------------X-----------------X | | red principal del campus : |______________________________| : lnea : serie : -------X----red 6
Las redes 1, 2 y 3 estn en un edificio. Las redes 4 y 5 estn en edificios distintos a a del campus. La red 6 puede estar en una localizacin ms distante. El diagrama anterior o a nos muestra que las redes 1, 2 y 3 estn conectadas directamente, y los mecanismos que a manejan las conexiones se marcan con "X". El edificio A est conectado a otros edificios a en el mismo campus por una red principal. El trfico desde la red 1 a la red 5 tomar el a a siguiente camino: de 1 a 2 a travs de la conexin entre estas redes; e o de 2 a 3 a travs de su conexin directa; e o de 3 a la red principal; a travs de la red principal, desde el edificio A al edificio donde la red 5 est e a emplazada; de la red principal a la red 5. El trfico hacia la red 6 debera pasar adicionalmente a travs de la lnea serie. Con a e la misma configuracin, se usara la misma conexin para conectar la red 5 con la red o o principal y con la lnea serie. As, el trfico de la red 5 a la red 6 no necesita pasar a a travs de la red principal, al existir esa conexin directa entre la red 5 y la lnea e o serie. En esta seccin vamos a ver qu son realmente estas conexiones marcadas con "x". o e
6.1
Dise os alternativos n
Hay que hacer constar que hay distintos dise~os alternativos al mostrado anteriormente. n Uno de ellos es usar lneas punto a punto entre los hosts, y otro puede ser usar una tecnologa de red a un nivel capaz de manejar tanto redes locales como redes de larga distancia. 6.1.1 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 travs de lneas serie de e largo alcance. Si nuestra red consiste primordialmente en un conjunto de ordenadores situados en localizaciones distintas, esta opcin tiene sentido. Veamos un peque~o o n dise~o de este tipo: n
30
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 travs de red era n e realizada por unos mecanismos de propsito especfico que marcbamos con "x". Si hay o a lneas que conectan directamente un par de hosts, los propios hosts harn esta labor de a enrutamiento, al mismo tiempo que realizan sus actividades normales. A no ser que haya lneas que comuniquen directamente todos los hosts, algunos sistemas tendrn que manejar a un trfico destinado a otros. Por ejemplo, en nuestro dise~o, el trfico de 1 a 3 deber a n a a pasar a travs de 4, 5 y 6. Esto es perfectamente posible, ya que la inmensa mayora de e las implementaciones TCP/IP son capaces de reenviar datagramas. En redes de este tipo podemos pensar que los propios hosts actan como gateways. Y, por tanto, deberamos u configurar el software de enrutamiento de los hosts como si se tratase de un gateway. Este tipo de configuraciones no es tan comn como podra pensarse en un principio debido, u principalmente, a estas dos razones: la mayora de las grandes redes tienen ms de un ordenador por localizacin. a o En estos casos es menos caro establecer una red local en cada localizacin que o establecer lneas punto a punto entre todos los ordenadores; las unidades de propsito especial para conectar redes son ms baratas, lo que hace o a que sea ms lgico descargar las tareas de enrutamiento y comunicaciones a estas a o unidades. Por supuesto, es factible tener una red que mezcle los dos tipos de tecnologas. As, las localizaciones con ms equipos podra manejarse usando un esquema jerrquico, con a a redes de rea local conectadas por este tipo de unidades, mientras que las localizaciones a lejanas con un slo ordenador podran conectarse mediante lneas punto a punto. En este o caso, el software de enrutamiento usado en los ordenadores lejanos deber ser compatible a con el usado por las unidades conmutadoras, o bien tendr que haber un gateway entre las a dos partes de la red. Las decisiones de este tipo generalmente se toman tras estudiar el nivel de trfico de la a 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 trfico de la red. a 6.1.2 Tecnolog de los circu a tos de conmutacin. o
Otro enfoque alternativo al esquema jerrquico LAN/red principal es usar circutos a conmutadores en cada ordenador. Realmente, estamos hablando de una variante de la tcnica de las lneas punto a punto, donde ahora el circuto conmutador permite tener e a cada sistema aparentar que tiene lnea directa con los restantes. Esta tecnologa no es usada por la mayora de la comunidad TCP/IP debido a que los protocolos TCP/IP suponen que el nivel ms bajo trabaja con datagramas aislados. Cuando se requiere una conexin a o continuada, el nivel superior de red la implementa usando datagramas. Esta tecnologa orientada al datagrama no coincide con este sistema orientado a los circutos de forma directa. Para poder usar esta tecnologa de circutos conmutadores, el software IP debe modificarse para ser posible construir circutos virtuales de forma adecuada. Cuando hay un datagrama para un destino concreto se debe abrir un circuto virtual, que se cerrar a
31
cuando no haya trfico para dicho destino por un tiempo. Un ejemplo de este enfoque a es la DDN (Defense Data Network). El protocolo principal de esta red es el X.25. Esta red parece desde fuera una red distribuda X.25. El software TCP/IP trata de manejar la DDN mediante el uso de canales virtuales. Tcnicas similares podran usarse con otras e tecnologas de circutos de conmutacin, como, por ejemplo, ATTs DataKit, aunque no hay o demasiado software disponible para llevarlo a cabo. 6.1.3 Redes de un slo nivel. o
En algunos casos, los adelantos en el campo de las redes de larga distancia pueden sustituir el uso de redes jerrquicas. Muchas de las redes jerrquicas fueron a a configuradas as para permitir el uso de tecnologas tipo Ethernet y otras LAN, las cules no pueden extenderse para cubrir ms de un campus. As que era mecesario el uso a a de lneas serie para conectar las distintas LANs de varios lugares. Sin embargo, ahora hay tecnologas de caractersticas similares a Ethernet, pero que pueden abarcar ms de a un campus y, por tanto, pensar en una sola red de larga distancia que no hace uso de una estructura jerrquica. a 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 fcil que se a sobrecargue. Las redes jerrquicas pueden manejar un volumen de trabajo mucho mayor a que las redes de un solo nivel. Adems, el trfico dentro de los departamentos tiende a a a ser mayor que el trfico entre departamentos. a Veamos un ejemplo concreto. Sumpongamos que hay diez departamentos, cada uno de los cuales genera 1 Mbit/seg de trfico. Supongamos que el 90% del trfico se realiza entre a a sistemas del mismo departamento y el 10% restante hacia los dems departamentos. Si a cada departamento tiene su prop`a red, stas deberan ser capaces de manejar 1 Mbit/seg, e 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 situacin con una o red de un solo nivel, puesto que debe manejar simultneamente los diez departamentos, se a resuelve con una red que soporte 10 Mbit/seg. Est claro que el ejemplo anterior est pensado para que el sistema jerrquico sea a a a ventajoso o, al menos, que sea ms fcil de llevar a cabo. Si el trfico destinado a a a a los otros departamentos fuese mayor, el ancho de banda de la red principal deber ser a mayor. Por ejemplo, si en un campus hay algunos recursos centraliza dos, como mainframes u otros grandes sistemas en un centro de clculo. Si la mayora del trfico procede de a a peque~os sistemas que intentan comunicarse con el sistema central, entonces el argumento n anterior no es vlido. Aunque un enfoque jerrquico puede que todava sea til, sin a a u 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 debera 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 limitacin se refieren a consideraciones respecto a la fiabilidad, o mantenibilidad y seguridad. Las redes de rea amplia son ms difciles de diagnosticar a a y mantener que las redes de rea local, porque los problemas pueden localizarse en el a edificio donde la red se ubica. Adems, hacen que el trfico sea ms fcil de controlar. a a a a Por estas razones es ms lgico manejar un trfico local dentro del edificio y usar las a o a redes de rea amplia slo para el trfico entre edificios. No obstante, si se da el caso a o a de que en cada localizacin hay slo uno o dos ordenadores, no tiene sentido montar una o o
32
red local en cada lugar y s usar una red de un solo nivel. 6.1.4 Dise os mixtos. n
En la prctica, pocas redes se permiten el lujo de adoptar un dise~o tericamente puro. a n o Es poco probable que una red grande sea capaz de evitar el uso de un dise~o jerrquico. n a Supongamos que la configuramos como una red de un solo nivel. Incluso si la mayora de los edificios tienen slo uno o dos ordenadores, habr alguna localizacin donde o a o 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 jerrquica. En la mayora de los a edificios sus ordenadores estn conectados directamente a una red de rea amplia, como a a una red de un solo nivel, pero en un edificio hay una red de rea local usando su red de a a rea amplia como red principal, a la cul se conecta a travs de unidades conmutadoras. a e Por otro lado, incluso los dise~adores de redes que defienden el uso de una enfoque n jerrquico, en muchas ocasiones encuentran partes de redes donde simplemente no resulta a econmico instalar una red de rea local, as que algunos hosts se enganchan directamente o a a la red principal, o bien se usa una lnea serie. Adems de las razones econmicas de la instalacin en s, hay que tener en cuenta que a a o o la larga hay que valorar aspectos de mantenimiento, de manera que a veces es mejor hacer un desembolso econmico en el dise~o para ahorrarnos dinero en el mantenimiento futuro. o n Por tanto, el dise~o ms consistente ser aqul que podamos ser capaces de mantener ms n a a e a fcilmente. a
6.2
Introduccin a las distintas tecnolog de conmutacin o as o
En esta seccin discutiremos las caractersticas de varias tecnologas usadas para o intercambiar datagramas entre redes. En efecto, trataremos de dar ms detalles sobre a esas "cajas negras"que hemos visto en las anteriores secciones. Hay tres tipos bsicos a de conmutadores, como repetidores, bridges (o puentes) y gateways (o pasarelas), o, alternativamente, switches de nivel 1, 2 y 3 (basndonos en el nivel del modelo OSI en a el que operan). Tambin hay que aclarar que hay sistemas que combinan caractersticas de e ms de uno de estos dispositivos, especialmente bridges y gateways. a Las diferencias ms importantes entre estos tipos de dispositivos residen en el grado de a aislamiento a fallos, prestaciones, enrutamiento y las facilidades que ofrecen para la administracin de la red. Ms adelante examinaremos esto con ms detalle. o a a 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 tecnologas. Los gateways estn empezando a adoptar un hardware de a propsito especfico que antes era caracterstico de los bridges. Los bridges estn o a empezando a adoptar un enrutamiento ms sofisticado, caractersticas de aislamiento a y de administracin de redes que antes slo se podan encontrar en los gateways. o o Incluso hay sistemas que pueden funcionar como bridges y gateway. Esto significa que la decisin crucial no es decidir si tenemos que usar un bridge o un gateway, sino qu o e caractersticas necesitamos en un switch y cmo ste afecta el dise~o global de la red. o e n
33
6.2.1
Repetidores.
Un repetidor es un equipo que conecta dos redes que usan la misma tecnologa. Recibe los paquetes de datos de cada red y los retransmite a la otra red. La red resultante se caracteriza por tener la unin de los paquetes de ambas redes. Para las redes Ethernet, o o que cumplen el protocolo IEEE 802.3, hay dos tipos de repetidores (otras tecnologas 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 prdidas de se~al, dispersin e n o temporal, etc. Nos permiten construir redes ms grandes y liberarnos de las limitaciones a de la longitud del cable. Podramos pensar que un repetidor se comporta como un amplificador a ambos lados de la red, pasando toda la informacin contenida en la o se~al (incluso las colisiones) sin hacer ningn procesamiento a nivel de paquetes. No n u obstante, hay un nmero mximo de repetidores que pueden introducirse en una red. Las u a especificaciones bsicas de Ethernet requieren que las se~ales lleguen a su destino a n dentro de un lmite de tiempo, lo que determina que haya una longitud mxima de la red. a Poniendo varios repetidores en el camino se introducen dificultades para estar dentro del lmite (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 informacin contenida en la se~al, almacena paquetes enteros de una red en un buffer o n interno y, luego, lo retranstime a la otra red, por lo que no deja pasar las colisiones. Debido a que los fenmenos de bajo nivel, como las colisiones, no son repetidos, se o 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 nmero de u 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 mximo para los paquetes), o entre dos redes de n a otra familia. Adems, un par de repetidores con buffer pueden usarse para conectar dos a redes mediante una lnea serie. Los repetidores con buffer y los repetidores bsicos tienen una caracterstica en comn: a u 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. 6.2.2 Bridges y gateways.
Un bridge se diferencia principalmente de un repetidor en que realiza algn tipo de u seleccin de qu datagramas se pasan a las otras redes. Persiguen alcanzar el objetivo o e de aumentar la capacidad de los sistemas, al mantener el trfico local confinado a la a red donde se originan. Solamente el trfico destinado a otras redes ser reenviado a a a travs del bridge. Esta descripcin tambin podra aplicarse a los gateways. Bridges y e o e gateways se distinguen por la manera de determinar qu datagramas deben reenviarse. Un e bridge usa slo las direcciones del nivel 2 de OSI; en el caso de las redes Ethernet, o o IEEE 802.x, nos referimos a las direcciones de 6 bytes de Ethernet o direcciones del nivel-MAC (el trmino "direcciones del nivel MAC"es ms general. Sin embargo, con la e a intencin de aclarar ideas, los ejemplos de esta seccin se referirn a redes Ethernet o o a y as slo deberemos reemplazar el trmino "direccin Ethernet"por el equivalente de o e o
34
direccin de nivel MAC en cualquier otra tecnologa). Un bridge no examina el datagrama o 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 direccin usada para tomar una o decisin. La primera de ellas afecta a cmo interactan dichos dispositivos conmutadores o o u con los niveles superiores del protocolo. Si el reenvo se hace a nivel de las direcciones de nivel- MAC (bridge), dicho dispositivo ser invisible a los protocolos. a Si se hace a nivel IP, ser visible. Veamos un ejemplo en el que hay dos redes a 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 direccin IP. En lo que se refiere a los o ordenadores A, B y C, hay una sola Ethernet a la que estn conectados. Esto se traduce a 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 conexin o con el ordenador B, primero se enva una peticin ARP preguntando por la direccin o o Ethernet del ordenador B. El bridge debe dejar pasar esta peticin de la red 1 a la red o 2. (En general, los bridges deben atender todas las peticiones). Una vez que ambos ordenadores conocen las direcciones Ethernet del otro, las comunicaciones usarn las a direcciones Ethernet en el destino. Llegados a este punto, el bridge puede empezar a ejecutar alguna seleccin, y dejar pasar aquellos datagramas cuya direccin Ethernet de o a o destino se encuentren en una mquina de la otra red. De esta manera un datagrama desde A a hasta Bpasar de la red 2 a la red 1, pero un datagrama desde B hasta C se ignorar. a a Con objeto de hacer esta seleccin, el bridge necesita saber en qu red est cada o e a mquina. La mayora de los bridges modernos construyen una tabla para cada red a la a que se conecta, listando las direcciones Ethernet de las mquinas de las que se sabe en a qu red se encuentran, y para ello vigilan todos los datagramas de cada red. Cuando un e datagrama aparece primero en la red 1 es razonable pensar que la direccin del remitente o corresponde a una mquina de la red 1. a Un bridge debe examinar cada datagrama por dos razones: la primera, para usar la direccin de procedencia y aprender qu mquinas estn en cada red, y, la segunda, para o e a a decidir si el datagrama ha de ser reenviado o no en base a la direccin de destino. o 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 algn u recurso. Una peticin ARP es un tpico ejemplo de lo anterior. Debido a que un bridge o no tiene manera de saber si un host va a responder a dicha peticin, deber dejarla o a 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
35
cualquier otro sistema, o podemos decidir que rwhod slo pueda tener acceso a una parte o 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 direccin IP por cada interface. Las tablas de o enrutamiento de los ordenadores debern configurarse para hacer los envos a las a 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 enviarn datagramas cuando sea apropiado. Por ejemplo, supongamos que el ordenador a 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 peticin ARP para a o esa direccin, respondindonos el gateway a la peticin como si se tratase de un host o e o cualquiera. A partir de entonces, los datagramas destinados a B sern enviados a la a direccin Ethernet del gateway. o 6.2.3 Ms sobre bridges. a
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 direccin se localiza en el mismo lugar en cada paquete, incluso si es IP, DECnet, o o de cualquier otro protocolo. De tal manera que es relativamente rpido obtener la a direccin de cada paquete. Por otro lado, un gateway debe decodificar toda la cabecera o IP y, si soporta otros protocolos distintos a IP, debe tener un software distinto para cada protocolo. Esto significa que un bridge soporta automticamente cualquier protocolo a posible, mientras que un gateway debe preveer qu protocolo debe soportar. e Sin embargo, tambin hay desventajas. e La principal se refiere al dise~o de un puente n
Un puente debe mirar cada paquete de la red, no solo aqullos a los que se le e destinan. Esto hace posible que haya sobrecargas en el bridge si se coloca en una red muy concurrida, incluso si el trfico que atraviesa el bridge es peque~o. a n No obstante, existe otra desventaja basada en la manera como los bridges estn a dise~ados. Sera posible, en principio, dise~ar bridges sin estas desventajas, pero n n 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 slo tienen una simple lista con las direcciones Ethernet que se encuentran en o sus redes. Lo que significa que Las redes que usan bridges no pueden tener bucles en su dise~o. Si hubiera un n bucle, algunos bridges veran el trfico procedente de una misma direccin Ethernet a o
36
venir de ambas direcciones, por lo que le sera imposible decidir en qu tabla debe e poner dicha direccin. Hay que aclarar que un camino paralelo en la misma direccin o o constituye un bucle y, por tanto, no se podrn usar mltiples caminos con el fin de a u descargar el trfico de la red. a Hay algunos mtodos para afrontar el problema de los bucles. Muchos puentes e permiten configuraciones con conexiones redundantes, pero desactivando enlaces de manera que no haya bucles. Si un enlace falla, uno de los desactivados entra en servicio. As, los enlaces redundantes nos proporcionan una fiabilidad extra, pero nos proporcionan nuevas capacidades. Tambin es posible construir un bridge capaz e de manejar lneas punto a punto paralelas, en un caso especial donde dichas lneas tienen en sus extremos un bridge. Los bridges trataran las dos lneas como una u nica lnea virtual y usarlas alternativamente, siguiendo algn algoritmo aleatorio. u El proceso de desactivar conexiones redundantes hasta que no queden bucles es conocido como un algoritmo de expansin de rboles". Este nombre se debe a que o a un rbol se define como un patrn de conexiones sin bucles. Lo que se hace es ir a o desactivando conexiones, ya que las conexiones restantes en el rbol incluyen a 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 expansin resultantes cargan demasiado a la a o red en alguna parte del sistema. Las redes cercanas a la "raiz del rbol"manejan a todo el trfico entre las distintas partes de la red. En una red que usa gateways, a sera posible poner enlaces extras entre partes de la red que tengan un gran trfico, pero dichos enlaces extras no pueden ser usados por un conjunto de bridges. a 6.2.4 Ms sobre gateways. a
Los gateways tienen sus propias ventajas y desventajas. En general, un gateway es ms a complejo de dise~ar y administrar que un bridge. Un gateway debe participar en todos n los protocolos para los que est dise~ado para reenviar. Por ejemplo, un gateway IP debe a n responder a peticiones ARP. El estndar IP tambin necesita estudiar por completo las a e cabeceras IP, decrementando el tiempo para activar campos y obedecer cualquier opcin IP. o Los gateways son dise~ados para manejar topologas de redes ms complejas que las que n a son capaces de manejar los bridges. Y, como ya hemos mencionado, tienen diferentes (y ms complejas) decisiones que estudiar. En general, un bridge tiene decisiones ms a a fciles que tomar: si se debe reenviar un datagrama y, en caso de que deba hacerse, a qu interface hemos de elegir. Cuando un gateway reenva un datagrama, debe decidirse e a qu host o gateway hay que enviarlo a continuacin. Si un gateway enva un datagrama e o de vuelta a la red de donde procede, tambin debe enviar una redireccin al emisor del e o datagrama indicando que use una mejor ruta. Muchos gateways pueden tambin manejar e caminos paralelos. Si hay varios caminos igual mente buenos para un destino, el gateway usar uno de ellos determinado por algn tipo de algoritmo aleatorio. (Esto se hace a u tambin en algunos bridges, pero no suele ser lo usual. En ambos casos, se elige uno de e ellos mediante algn tipo de algoritmo aleatorio. Esto tiende a hacer que la llegada de u 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 a 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 nmero de red. Para cada red hay, o u
37
bien una entrada indicando que la red est conectada directamente al gateway, o hay una a entrada indicando que el trfico para esa red debe reenviarse hacia algn otro gateway a u o gateways. Describiremos posteriormente los "protocolos de enrutamientosados para u elaborar esta informacin, en la discusin sobre cmo configurar un gateway. o o o
6.3
Comparando las tecnolog de conmutacin as o
Los repetidores, repetidores con buffer, bridges y gateways forman un espectro. Los dispositivos del principio de la lista son mejores para redes peque~as, adems son ms n a a baratos y fciles de configurar aunque tienen menos servicios. Los del final de la a lista son apropiados para construir redes ms complejas. Muchas redes usan mezclas a de dispositivos, con repetidores para conectar peque~os segmentos de red, bridges para n algunas reas grandes y gateways para enlaces de larga distancia. a Hasta ahora hemos asumido que slo usan gateways. La seccin de cmo configurar un host o o o describe cmo configurar una tabla de enrutamiento, listando los gateways que se deban o 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 seccin 3.4. se describe cmo configurar u o o un host en el caso en que varias subredes se traten como una nica red fsica; la misma u configuracin debera usarse cuando varias subredes se conectan mediante repetidores o o bridges. Como ya mencionamos, las caractersticas a tener en cuenta en un dispositivo conmutador son: aislamiento, rendimiento, enrutamiento y las facilidades de mantenimiento de la red. 6.3.1 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 a la nuestra tambin. Asimismo, dos redes juntas pueden tener suficiente trfico como para e a saturar la nuestra. Es por lo tanto conveniente elegir un nivel apropiado de proteccin. o El aislamiento puede llegar de dos maneras: aislamiento frente al mal funcionamiento y frente al trfico. Con el objeto de discutir el aislamiento debido a errores de a funcionamiento, vamos a se~alar una clasificacin de malfunciones: n o Fallos elctricos, como por ejemplo una bajada de tensin o algn tipo de fallo que e o u distorsiona la se~al. Todos los tipos de dispositivos debern confinarlo a un lado n a del dispositivo (repetidor, repetidor con buffer, bridge, gateway). Problemas con los transceiver y controladores que, en general, generan se~ales n elctricamente correctas, pero de contenido errneo (por ejemplo, paquetes de e o tama~o infinito o demasiado grandes, falsas colisiones, portadora continua). Todos, n excepto el repetidor, nos protegen de estos problemas, que no son muy comunes. Errores en el software que provocan un excesivo trfico entre algunos hosts (no nos a 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).
38
Errores en el software que provocan un excesivo trfico de broadcast. Los gateways a 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 podran protegernos contra algunos de estos errores de sobrecarga de broadcast. Sin embargo, en general, los bridges deben dejar pasar ARP y la mayora 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 trfico es proporcionado por bridges y gateways. La decisin ms a o a importante al respecto es conocer el nmero de ordenadores que podemos poner en una red u sin sobrecargarla. Esto requiere el conocimiento de la capacidad de la red, y el uso al que se destinarn los hosts. Por ejemplo, una Ethernet puede soportar cientos de a 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 podra soportar entre 10 y 40, dependiendo de su velocidad y sus caractersticas de E/S. Cuando ponemos ms ordenadores en una red de los que es capaz de manejar, deberemos a dividirla en varias redes y poner algn dispositivo conmutador entre ellos. Si esto u se hace correctamente, la mayora del trfico deber realizarse entre mquinas de la a a a misma parte de la divisin, lo que significa poner los clientes en la misma red que su o servidor, poner los servidores de terminales en la misma red que los hosts a los que se accede ms frecuentemente. a Bridges y gateways, generalmente, suministran el mismo grado de aislamiento al trfico. a En ambos casos, slo el trfico destinado a los hosts del lado de la unidad conmutadora o a se pasar. Veremos esto ms detalladamente en la seccin del enrutamiento. a a o 6.3.2 Prestaciones.
Los lmites de las prestaciones empiezan a ser menos claros, puesto que las tecnologas de conmutacin estn mejorando continuamente. Generalmente, los repetidores pueden o a manejar todo el ancho de banda de la red (por su propia naturaleza, un repetidor bsico ha de ser capaz de hacer esto). Los bridges y gateways frecuentemente tienen a limitaciones en sus prestaciones de varios tipos. Los bridges tienen dos estadsticos de inters: la tasa de paquetes analizados y el rendimiento. Como explicamos e anteriormente, los bridges deben analizar cada paquete que se encuentra en la red, incluso aquellos que no van a ser reenviados. El nmero de paquetes analizados por u 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 trfico que ha sido a reenviada; generalmente, depende del tama~o del datagrama. As, el nmero de datagramas n u por segundo que una unidad puede manejar ser mayor cuanto haya ms datagramas peque~os a a n 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 propsito especfico para acelerar la labor de anlisis de paquetes. o a La primera generacin de gateways podan procesar entre algunos cientos de datagramas o por segundo hasta unos 1.000 ms; sin embargo, los gateways de segunda generacin, o a o ampliamente extendidos, usan un hardware de propsito especfico igual de sofisticado o 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
39
razn para elegir entre un tipo u otro de dispositivo. Sin embargo, para un tipo dado de o dispositivo, hay todava grandes diferencias entre los distintos modelos, sobre todo en la relacin precio/prestaciones. Esto es especialmente cierto en los modelos de la gama o baja. Los bridges ms baratos cuestan menos de la mitad que los gateways ms baratos. a a Desgraciadamente, no hay un nico estadstico para poder estimar las prestaciones de u un dispositivo. No obstante, el que ms se usa es el de paquetes por segundo. Hay a que tener en cuenta que la mayora de las empresas cuentan los datagramas una sola vez, cuando pase por el gateway; hay una compa~a importante que cuenta los datagramas n 2 veces, y, por tanto, deben dividirse por 2 para poder comparar. Tambin hay que e asegurarse, para hacer una comparacin correcta, que los datagramas son del mismo tama~o. o n Un modelo para poder comparar prestaciones es
tiempo_de_procesamiento = tiempo_conmutacin + tama~o_datagrama * tiempo_por_byte o n
Aqu, el tiempo de conmutacin suele ser una constante; representa la interrupcin o o latente, el procesamiento de las cabeceras, buscar en la tabla de enrutamiento, etc., ms un componente proporcional al tama~o del datagrama, representando el tiempo necesario a n para hacer cualquier copia de datagrama. Un enfoque razonable para estudiar las prestaciones es dar los datagramas por segundo por los tama~os mnimos y mximos de n a los datagramas. Otra forma de conocer los lmites de un dispositivo es conociendo la velocidad de los datagramas por segundo y el rendimiento en bytes por segundo, y aplicando la frmula anterior. o 6.3.3 Enrutamiento.
Vamos a estudiar las tecnologas usadas para decidir hacia dnde debe enviarse un o datagrama. Por supuesto, no haremos esto para los repetidores, ya que stos reenvan e todos los paquetes. La estrategia de enrutamiento de un bridge conlleva tomar dos decisiones: activar o desactivar los enlaces de manera que se mantenga el rbol de expansin; y, a o decidir si debemos reenviar un paquete en particular y a travs de cul interface e a (si el puente es capaz de manejar ms de dos interfaces). a La segunda decisin se toma en base a una tabla de direcciones del nivel-MAC. Como ya o hemos descrito anteriormente, esta tabla se construye analizando el trfico que pasa por a cada interface. El objetivo es reenviar aquellos paquetes cuyo destino se encuentre a otro lado del bridge. Este algoritmo requiere tener una configuracin de red que no o contenga bucles o lneas 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 n n ms sofisticados permiten una topologa cualquiera, pero ir desactivando enlaces hasta a a que no haya bucles; adems, nos proporciona una fiabilidad extra, ya que, en caso de a fallo de un enlace, se activar automticamente un enlace alternativo. Los bridges que a a funcionan de este modo tienen un protocolo que les permite detectar cundo una unidad a debe desactivarse o activarse, de manera que el conjunto activo de enlaces abarquen el rbol de expansin. Si necesitamos la fiabilidad proporcionada por los enlaces a o redundantes, debemos asegurarnos que nuestros bridges sean capaces de trabajar de esta manera. Actualmente no hay un protocolo estndar para este tipo de bridges, pero est a a en camino. En caso de comprar bridges de ms de una marca, debemos asegurarnos que sus a protocolos para trabajar con los rboles de expansin pueden entenderse. a o
40
Por otro lado, los gateways permiten cualquier tipo de topologa, incluyendo bucles y enlaces redundantes. Debido a que tienen algoritmos ms generales de enrutamiento, los a gateways deben mantener un modelo de toda la red. Diferentes tcnicas de enrutamiento e mantienen modelos de redes con ms o menos complejidad, y usan esta informacin con a o distinto tipo de sofisticacin. Los gateways que pueden manejar IP, normalmente soportan o los dos protocolos estndares de Internet: RIP (Routing Information Protocol) y EGP a (External Gateway Protocol). El EGP es un protocolo de propsito especfico usado en o redes donde hay una red principal, y permite intercambiar informacin de "cmo llegar"con o o 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 n n velocidad de las lneas no difieren demasiado. Sus principales limitaciones son: No puede usarse con redes donde los caminos pasan por ms de 15 gateways. Se puede, a incluso, reducir este nmero en el caso de que usemos una opcin de dar un paso u o mayor de uno a una lnea lenta. No puede compartir el trfico entre lneas paralelas (algunas implementaciones a permiten hacer esto si dichas lneas se encuentran entre el mismo par de gateways). No puede adaptarse a la sobrecarga de redes. No es adecuada para situaciones en las que hay rutas alternativas a travs de lneas e con muy distinta velocidad. No es estable en redes donde las lneas o los gateways cambian con frecuencia. Algunas compa~as venden modificaciones de RIP que mejoran su funcionamiento con EGP, o n que incrementan la longitud del camino mximo ms all de 15, pero no incluyen otro tipo a a a de modificaciones. En caso de que nuestra red disponga de gateways de ms de una marca, a en general necesitaremos que soporten RIP, puesto que suele ser el nico protocolo de u enrutamiento disponible. Si vamos a trabajar, adems, con otro tipo de protocolo, pueden a sernos tiles gateways que traduzcan su propio protocolo y RIP. Sin embargo, para redes u muy grandes o complejas no nos queda otro remedio que usar otros protocolos. Tambin existen otros protocolos ms sofisticados. Los principales son IGRP y los e a basados en los algoritmos SPF (el camino ms corto primero - short path fist). a Usualmente, estos protocolos han sido dise~ados para redes ms grandes o complejas y, n a en general, son estables bajo una gran variedad de condiciones, pudiendo manejar lneas 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 tecnologas de enrutamiento, y stas se estn modificando e a rpidamente, as que deberemos tener en cuenta la topologa de nuestra red para elegir un a producto en concreto; tenemos que asegurarnos que puede manejar nuestra topologa y que puede soportar otros requerimientos especiales, como compartir el trfico entre lneas a paralelas, o ajustar la topologa ante fallos. A largo plazo, se espera que aparezcan nuevos protocolos que estandaricen estos trabajos. Pero, por el momento, no se usa otra tecnologa 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 ms corto o ms rpido posible para cada datagrama. En algunos casos, esto no es lo a a a
41
deseable; a veces, por razones de seguridad, razones econmicas, etc, puede que deseemos o reservar algunos caminos para algn uso especfico. La mayora de los gateways tienen u la capacidad de controlar la propagacin de la informacin de enrutamiento, lo que nos o o da algunas facilidades de administracin sobre la forma en que estas rutas se usan, y el o grado de control que soportan vara de un gateway a otro. 6.3.4 Administracin de Redes. o
La administracin de redes abarca un amplio nmero de asuntos. En general, se suelen o u tratar con muchos datos estadsticos e informacin sobre el estado de distintas partes de o la red, y se realizan las acciones necesarias para ocuparse de fallos y otros cambios. La tcnica ms primitiva para la monitorizacin de una red es hacer "pinginga los e a o hosts crticos; el "pinging"se basa en un datagrama de "echo"(eco), que es un tipo de datagrama que produce una rplica inmediata cuando llega al destino. La mayora de las e implementaciones TCP/IP incluyen un programa (generalmente, llamado "ping") que enva un echo a un host en concreto. Si recibimos rplica, sabremos que host se encuentra activo, e y que la red que los conecta funciona; en caso contrario, sabremos que hay algn error. u Mediante "pinginga un razonable nmero de ciertos hosts, podremos normalmente conocer qu u e ocurre en la red. Si los ping a todos los hosts de una red no dan respuesta, es lgico o concluir que la conexin a dicha red, o la propia red, no funciona. Si slo uno de los o o hosts no da respuesta, pero los dems de la misma red responden, es razonable concluir a que dicho host no funciona. Tcnicas ms sofisticadas de monitorizacin necesitan conocer informacin estadstica e a o o y el estado de varios dispositivos de la red. Para ello necesitar llevar la cuenta a de varias clases de datagramas, as como de errores de varios tipos. Este tipo de informacin ser ms detallada en los gateways, puesto que el gateway clasifica los o a a datagramas segn protocolos e, incluso, l mismo responde a ciertos tipos de datagramas. u e Sin embargo, los bridges e incluso los repetidores con buffer contabilizan los datagramas reenviados, errores de interface. Es posible recopilar toda esta informacin en un punto o de monitorizacin central. o Tambin hay un enfoque oficial TCP/IP para llevar a cabo la monitorizaci`n. En la e o primera fase, usamos un conjunto de protocolos SGMP y SNMP, ambos dise~ados para n permitirnos recoger informacin y cambiar los parmetros de la configuracin y otras o a o 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 a sistemas Unix que actan como gateway. Cualquier implementacin SGMP necesita que se u o proporciones un conjunto de datos para que pueda empezar a funcionar, y tienen mecanismos para ir a~adiendo informaciones que varan de un dispositivo a otro. A finales de n 1988 apareci una segunda generacin de este protocolo, SNMP, que es ligeramente ms o o a sofisticado y necesita ms informacin para trabajar y, para ello, usa el llamado MIB a o (Management Information Base). En lugar de usar una coleccin de variable SNMP, el MIB o es el resultado de numerosas reuniones de Comits formados por vendedores y usuarios. e Tambin se espera la elaboracin de un equivalente de TCP/IP de CMIS, el servicio ISO e o de monitorizacin de redes. Sin embargo, CMIS y sus protocolos, CMIP, todava no son o estndares oficiales ISO, pero estn en fase experimental. a a En trminos generales, todos estos protocolos persiguen el mismo objetivo: permitirnos e recoger informacin crtica de una forma estandarizada. Se ordena la emisin de o o datagramas UDP desde un programa de administracin de redes que se encuentra ejecutando o en alguno de los hosts de red. Generalmente, la interaccin es bastante simple, con o
42
el intercambio de un par de datagramas: una orden y una respuesta. El mecanismo de seguridad tambin es bastante simple, siendo posible que se incluyan passwords e en las rdenes. (En SGMP nos referiremos a stos como una "session name", en lugar o e de password). Tambin existen mecanismos de seguridad ms elaborados, basados en la e a criptografa. Probablemente querremos configurar la administracin de la red con las herramientas que o tenemos a nuestra disposicin para controlar diversas actividades. Para redes con pocas o terminales, queremos controlar cundo nuestros dispositivos de conmutacin fallan, estn a o a fuera de servicio por mantenimiento, y cuando haya fallos en las lneas de comunicacin o 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 crtico (por ejemplo, lneas activas o desactivas). No obstante, no es realista esperar que un dispositivo de conmutacin nos notifique cuando falla. Tambin es posible que o e 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 conmutacin renan regularmente este tipo de informacin. Hay varias o u o herramientas que visualizan un mapa de la red, donde los objetos cambian de color cuando cambian de estado, y hay cuadros que muestran estadsticas sobre los datagramas y otros objetos. Otro tipo de monitorizacin deseable es recolectar informacin para hacer informes o o peridicos del porcentaje de uso de la red y prestaciones. Para ello, necesitamos o analizar cada dispositivo de conmutacin y quedarnos con los datos de inters. En o e la Universidad de Rutgers esto se hace cada hora, y se obtienen datos del nmero de u datagramas reenviados a Internet u otra red, errores, varios, etc.; y se almacenan informes detallados de cada da. Hay informes mensuales en los que se refleja el trfico a que soporta cada gateway y algunas estadsticas de errores, elegidas para ver si hay un gateway que est sobrecargado (datagramasperdidos). a Sera posible que cualquier tipo de conmutador pudiese usar cualquier tipo de tcnica e de monitorizacin. Sin embargo, generalmente los repetidores no proporcionan ningn o u tipo de estadstica, debido a que normalmente no tienen ningn procesador para abaratar u su precio. Por otro lado, es posible usar un software de administracin de redes con o repetidores con buffer, bridges y gateways. Los gateways, en la mayora de los casos, incluyen un avanzado software de administracin de redes. La mayora de los gateways o pueden manejar IP y los protocolos de monitorizacin anteriormente mencionados. Y la o mayora de los bridges tienen medios para poder recoger algunos datos de prestaciones. Puesto que los bridges no estn dirigidos a ningn protocolo en particular, la mayora a u de ellos no tienen el software necesario para implementar los protocolos TCP/IP de administracin de redes. En algunas ocasiones, la monitorizacin puede hacerse tecleando o o algunos comandos a una consola a la que est directamente conectada. (Hemos visto un e caso donde era necesario dejar el puente fuera de servicio para recoger estos datos). En los restantes casos, es posible recoger datos a travs de la red, pero el protocolo e requerido no suele ser ningn estndar. u a Excepto para algunas peque~as redes, debemos insistir en que cualquier dispositivo n conmutador ms complejo que un simple repetidor es capaz de recolectar estadsticas y a algn mecanismo para hacernos con ellas de forma remota. Aquellas partes de la red que u no soporten dichas operaciones pueden monitorizarse mediante pinging (aunque el ping slo o detecta errores graves, y no nos permite examinar el nivel de ruido de una lnea serie y otros datos necesarios para llevar a cabo un mantenimiento de alta calidad). Se espera que la mayora del software disponible cumpla los protocolos SGMP/SNMP y CMIS. Tambin e
7. Congurando gateways
43
un software de monitorizacin no estndar, siempre y cuando sea soportado por los equipos o a que tenemos. 6.3.5 Una evaluacin nal. o
Vamos a reunir todo lo anterior indicando dnde se usa cada tipo de conmutador, o normalmente: Los repetidores, normalmente, se restringen a un solo edificio. Puesto que no nos proveen de un aislamiento al trfico, debemos asegurarnos en todas las redes a concectadas por los repetidores que pueden hacer llegar todos sus ordenadores. Puesto que no suelen tener herramientas de monitorizacin, no ser deseable su uso o a para aquellos enlaces que fallan a menudo. Los bridges y gateways deben situarse de manera que se divida la red en partes cuyo volumen de trfico sea manejable. Incluso se podran emplazar bridges o gateways a incluso en el caso de que no sean necesarios por razones de monitorizacin. o Debido a que los bridges deben dejar pasar datagramas de broadcast, hay un lmite en el tama~o de las redes que pueden conectar. Por lo general, basta limitar estas n redes con un ciento de mquinas, aproximadamente. Este nmero puede ser mayor, si a u el bridge incluye algunas facilidades de filtrado de datagramas. Debido a que algunos tipos de redes son proclives al mal funcionamiento, deberemos usar los bridges slo entre partes de la red donde un solo grupo es responsable de o diagnosticar los problemas. Debemos estar locos para usar un bridge para conectar redes que pertenecen a distintas organizaciones. Las partes de la red "de tipo experimental"debern aislarse del resto de la red por gateways. a En muchas aplicaciones es ms importante elegir un producto con la adecuada a combinacin de prestaciones, herramientas de administracin de la red y otras o o caractersticas, para tomar la decisin de elegir entre bridges y gateways. o
Congurando gateways
Vamos a ver algunos aspectos especficos de la configuracin de gateways. Aquellos o gateways que entienden el protocolo IP son, al mismo tiempo, hosts de Internet y, por tanto, podemos poner en prctica lo visto para configurar las direcciones y el a enrutamiento en los hosts. No obstante, la forma exacta de cmo debemos configurar o un gateway depende del modelo en concreto. En algunos casos, deberemos editar algunos ficheros includos en un disco del propio gateway. Sin embargo, por razones de fiabilidad, la mayora de los gateways no tienen discos propios; en su lugar, esta informacin se almacena en una memoria no voltil o en ficheros que se cargan desde uno o o a varios hosts de la red. Como mnimo, para configurar el gateway hay que especificar la direccin IP y la mscara o a de cada interface, y activar un protocolo de enrutamiento adecuado. Normalmente ser a deseable configurar otros parmetros. a Un parmetro importante a tener en cuenta es la direccin de broadcast. Como explicamos a o con anterioridad, hay cierto software antiguo que no funciona bien cuando se envan broadcasts usando los nuevos protocolos de direcciones de broadcast. Por esta razn, o
44
algunos modelos nos permiten elegir una direccin broadcast para cada interface. Por o tanto, en ese caso, se debern configurar teniendo en cuenta los ordenadores que hay a en la red. En general, si los ordenadores soportan los actuales estndares, podr a a usarse una direccin del tipo 255.255.255.255. No obstante, antiguas implementaciones o deben comportarse mejor con otro tipo de direcciones, especialmente con aquellas direcciones que usan ceros para los nmeros del host (para la red 128.6 sta tendra u e que ser 128.6.0.0. Para mantener la compatibilidad con redes que no soportan sub-redes deberamos usar 128.6.0.0 como direccin de broadcast, incluso para una subred del tipo o 128.6.4). Podemos observar nuestra red con un monitor de red y ver los resultados de las distintas elecciones de direciones de broadcast; en caso de que hagamos una mala eleccin, cada vez que hagamos un broadcast para actualizar el enrutamiento, muchas o mquinas de nuestra red nos responderan con errores ARP o ICMP. Hay que hacer notar a que cuando cambiamos las direcciones de broadcast en el gateway, necesitaremos cambiarla tambin en cada uno de los ordenadores. Lo que se suele hacer es cambiar la direccin e o de aquellos sistemas que podemos configurar, para hacerlos compatibles con los otros sistemas que no podemos configurar. Hay otros parmetros de la interface que pueden que sea necesario configurar para a trabajar con las peculiaridades de la red a la que se conectan. Por ejemplo, muchos gateways comprueban sus interfaces a Ethernet para asegurarse de que el cable al que se conectan y el transceiver funcionan correctamente. Algunos de estos tests no funcionan correctamente con la antigua versin 1 de transceiver Ethernet. En caso de que usemos un o transceiver de este tipo, deberemos desactivar este tipo de test. De forma similar, los gateways conectados a lneas en serie normalmente hacen este tipo de test para verificar su buen funcionamiento, y tambin hay situaciones en las que necesitaremos deactivar el e test. Es bastante usual que tengamos que activar las opciones necesarias para el software que tengamos que usar. Por ejemplo, muchas veces es necesario activar explcitamente el protocolo de administracin de red, y dar el nombre o la direccin del host donde se o o ejecuta el software que acepta traps (mensajes de error). La mayora de los gateways tienen opciones relacionadas con la seguridad. Como mnimo, hay que indicar un password para poder hacer cambios de forma remota (y una "session name"para SGMP). Si queremos controlar el acceso a ciertas partes de la red, tambin e deberemos definir una lista de control de accesos, o cualquier otro mecanismo que use el gateway en cuestin. o Los gateways cargan la informacin de la configuracin a travs de la red. Cuando un o o e gateway arranca, enva una peticin broadcast de varias clases, intentando conocer su o direccin Internet para luego cargar su configuracin. As, hay que asegurarse que o o haya algunos ordenadores capaces de responder a dichas peticiones. En algunos casos, hay algn micro dedicado ejecutando un software especial. Otras veces, hay un software u genrico que podemos ejecutar en varias mquinas. Por razones de fiabilidad, debemos e a comprobar que hay ms de un host con la informacin y los programas que necesita. En a o algunos casos tendremos que mantener varios archivos distintos. Por ejemplo, los gateways usados en Groucho usan un programa llamado "bootp"para que le proporcione su direccin Internet, y luego cargan el cdigo y la informacin de la configuracin usando o o o o TFTP. Esto significa que tenemos que mantener un archivo para "bootp"que contiene las direcciones Ethernet e Internet para cada gateway, y un conjunto de archivos para la restante informacin de cada uno de ellos. Si una red es muy grande, podemos tener o problemas para asegurarnos de que esta informacin permanece consistente. Podemos o mantener copias nuestras de todas las configuraciones en un nico ordenador y que se u
45
distribuya a otros sistemas cuando haya algn cambio, usando las facilidades make y u rdist de Unix. Si nuestro gateway tiene la opcin de almacenar la informacin de o o la configuracin en una memoria no voltil, podremos eliminar todos estos problemas o a logsticos, pero presenta sus propios problemas. El contenido de esta memoria debera almacenarse en alguna localizacin central, porque de todas maneras es difcil para el o personal de administracin de la red revisar la configuracin si se encuentra distribuda o o entre los distintos gateways. Arrancar un gateway que carga la informacin de su configuracin desde una localizacin o o o distante es especialmente arriesgado. Los gateways que necesitan cargar su informacin o de configuraci`n a travs de la red, generalmente emiten una peticin broadcast a todas o e o las redes que conectan. Si algn ordenador de una de esas redes es capaz de responder, u no habr ningn problema. Sin embargo, algunos gateways que se encuentren a gran a u distancia donde los ordenadores de su alrededor no soportan los protocolos necesarios, en cuyo caso es necesario que las respuestas le lleguen a travs de una red donde haya e unos ordenadores apropiados. Desde un punto de vista estricto, esto va en contra de la filosofa de trabajo de los gateways, ya que normal mente un gateway no permite que un broadcast procedente de una red pase a travs de una red adyacente. Para permitir que e un gateway obtenga informacin de un ordenador en una red distinta, al menos uno de los o gateways que est entre ellos tendr que configurarse para que pase una clase especial a a de broadcast usado para recuperar este tipo de informacin. Si tenemos este tipo de o configuracin, tendremos que comprobar este proceso peridicamente, ya que no es raro que o o nos encontremos con que no podamos arrancar un gateway tras un fallo de energa, debido a un cambio en la configuracin en otro gateway que hace imposible cargar esta informacin. o o
7.1
Congurando el enrutamiento de los gateways
Por ltimo, vamos a tratar cmo configurar el enrutamiento. Este tipo de configuracin u o o es ms difcil para un gateway que para un host. La mayora de los expertos TCP/IP a recomiendan dejar las cuestiones de enrutamiento a los gateways. As, los hosts simplemente tienen una ruta por defecto que apunta al gateway ms cercano (por supuesto, a los gateways no pueden configurarse de esta manera. Ellos necesitan tablas completas de enrutamiento). Para entender cmo configurar un gateway, vamos a examinar con un poco ms de detalle o a cmo los gateways se comunican las rutas. o Cuando encendemos un gateway, la nica red de la que tiene informacin es aqulla a la u o e que est directamente conectado (lo que se especifica en la configuracin). Para llegar e o a saber cmo se llega a partes ms distantes de la red, marca algn tipo de "protocolo o a u de enrutamiento", que simplemente es un protocolo que permite a cada gateway anunciar a qu redes tiene acceso, y extender esa informacin de un gateway a otro. Eventualmente, e o cada gateway debera saber cmo llegar a cada red. Hay distintos tipos de protocolos o de enrutamiento; en el ms comn, los gateways se comunican exclusivamente con los a u ms cercanos; en otra clase de protocolos, cada gateway construye una base de datos a describiendo cada gateway del sistema. No obstante, todos estos protocolos encuentran cmo llegar a cualquier destino. o Una mtrica es un nmero, o conjunto de nmeros, usado para comparar rutas. La tabla de e u u enrutamiento se construye recogiendo informacin de otros gateways. Si dos gateways son o capaces de llegar a un mismo destino, debe de haber algn mtodo para decidir cul usar. u e a La mtrica se usa para tomar esta decisin. Todas las mtricas indican de alguna forma e o e
46
lo "costoso"de una ruta. Podra ser cuntos dlares costara enviar un datagrama por a o una ruta, el retraso en milisegundos, o cualquier otra medida. La mtrica ms simple e a es el nmero de gateways que hay hasta el destino ("cuenta de saltos"), y es la que u generalmente se encuentra en los ficheros de configuracin. o Como mnimo, una configuracin de enrutamiento consistira en un comando para activar o el protocolo de enrutamiento que vayamos a usar. La mayora de los gateways estn a orientados para usar un protocolo; a no ser que tengamos razones para usar otro, es recomendable usar dicho protocolo. Una razn habitual para elegir otro protocolo es o para hacerlo compatible con otros gateways. Por ejemplo, si nuestra red est conecta a da a una red nacional que nos exige usar EGP ("exterior gateway protocol") para que se pueda intercambiar rutas con ella, EGP slo es apropiado para este caso especfico. o No deberemos usar EGP dentro de nuestra propia red, sino slo para comunicarnos con la o red nacional. Si tenemos varias clases de gateways, necesitaremos usar un protocolo entendible por todos ellos. En muchas ocasiones este protocolo ser RIP (Routing a Information Protocol). A veces podremos usar protocolos ms complejos entre los gateways a que los soporten, y usar RIP slo cuando nos comuniquemos con gateways que no entiendan o estos protocolos. Si ya hemos elegido un protocolo de enrutamiento y lo hemos puesto en marcha, todava nos quedan por tomar algunas decisiones. Una de las tareas mas bsicas de configuracin a o que tenemos que completar es uministrar la informacin de la mtrica. Los protocolos o e ms simples, como RIP, normalmente usan "cuenta de saltos", de manera que una ruta a que pasa a travs de dos gateways es mejor que una que pasa por tres. Por supuesto, e si la ltima ruta usa lneas de 15 Mbps y la primera lneas de 9.600 bps, sera una u mala eleccin. La mayora de los protocolos de enrutamiento tienen medios para tomar o esto en cuenta. Con RIP, podramos tratar las lneas de 9.600 bps como si fueran a a e "saltosadicionales, de manera que la mejor lnea (la ms rpida) tenga una mtrica menor. Otros protocolos ms sofisticados tendrn en cuenta la velocidad de la lnea a a de forma automtica. Generalmente, estos parmetros debern asociarse a una interface a a a en particular. Por ejemplo, con RIP deberemos establecer explcitamente el valor de la mtrica, si se est conectado con una lnea de 9.600 bps. Con aquellos protocolos que e a tienen en cuenta la velocidad de las lneas, deberemos de especificar la velocidad de las lneas (si el gateway no los puede configurar automticamente). a La mayor parte de los protocolos de enrutamiento han sido dise~ados para que cada n gateway se aprenda la topologa de toda la red, y elegir la mejor ruta posible para cada datagrama. En algunos casos no estaremos interesados en la mejor ruta; por ejemplo, puede que estemos interesados en que el datagrama se desplace por una parte de la red por razones de seguridad o econmicas. Una manera de tener este control es especificando o opciones de enrutamiento. Dichas opciones varan mucho de un gateway a otro, pero la estrategia bsica es que si el resto de la red no conoce dicha ruta, no ser utilizada. a a Estos controles limitan la forma en la que se van a usar las rutas. Hay mtodos para que el usuario ignore las decisiones de enrutamiento hechas por los e gateways. Si realmente necesitamos controlar el acceso a ciertas redes, podemos hacer dos cosas: los controles de enrutamiento nos aseguran que los gateways usan slo las rutas que o queremos; usar listas de control de acceso en los gateways adyacentes a las redes controladas. Estas dos opciones trabajan a distinto nivel. Los controles de enrutamiento afectan
8. Anexo: Copyright
47
a lo que ocurre a la mayora de los datagramas: aqullos en los que el usuario no ha e especificado manualmente una ruta. Nuestro mecanismo de enrutamiento ha de ser capaz de elegir una ruta aceptable para ellos. Una lista de control de acceso a~ade una n limitacin adicional, preservndonos de usuarios que incluyesen su propio enrutamiento o a y pasasen nuestros controles. Por razones de fiabilidad y seguridad, puede que tambin haya controles con listas e de gateways de las que podemos aceptar informacin. Tambin es posible hacer una o e clasificacin de prioridad. Por ejemplo, podemos decidir hacer antes los enrutamientos o de nuestra propia organizacin antes que los de otras organizaciones, u otras partes de o la organizacin. Esto tendr el efecto de dar preferencia al trfico interno frente al o a a externo, incluso si el externo parece ser mejor. Si usamos varios protocolos distintos de enrutamiento, probablemente tendremos que afrontar algunas decisiones respecto a la informacin que se pasan entre ellos. Puesto o que el uso de varios protocolos de enrutamiento est frecuentemente asociado a la a existencia de varias organizaciones, deberemos de tomar la precaucin de hacer estas o decisiones consultando con los administradores de las redes de dichas organizaciones. Este tipo de decisiones puede tener consecuencias en las otras redes bastante difciles de detectar. Podramos pensar que la mejor forma de configurar un gateway es que fuese capaz de entender todos los protocolos, pero hay algunas razones por las que esto no es recomendable: Las mtricas usadas por los distintos protocolos no son compatibles en muchas e ocasiones. Si estamos conectados a dos redes externas distintas, podemos especificar que una siempre debe usarse preferentemente a la otra, o que la ms a cercana es la que debe usarse, en lugar de comparar la mtrica recibida de las dos e redes para ver cul tiene la mejor ruta. a EGP es especialmente delicado, ya que no admite bucles. Por esto hay unas reglas estrictas para regular la informacin que hay que intercambiar para comunicarse con o una red principal usando EGP. En aquellos casos en que se use EGP, el administrador de la red principal debera ayudarnos a configurar el enrutamiento. Si tenemos lneas lentas en nuestra red (9.600 bps o menos), puede que no queramos enviar la tabla de enrutamiento completa a travs de la red. Si nos conectamos a e una red exterior, tenemos la posibilidad de tratarla como una ruta por defecto, en lugar de introducir toda su informacin en nuestro protocolo de enrutamiento. o
Anexo: Copyright
Computer Science Facilities Group. RUTGERS. The State University of New Jersey Center for Computers and Information Services. Laboratory for Computer Science Research. Copyright c 1988 Charles L. Hedrick. Cualquiera puede reproducir este documento en su totalidad o en parte, comprometindose a: (1) que en cualquier copia o publicacin debe e o aparecer Rutgers University como fuente, y debe incluir este mensaje; y (2) cualquier otro uso de este material debe hacer referencia a este manual y a Rutgers University, y al hecho de que este material es copyright de Charles Hedrick y es usado bajo su permiso.
8. Anexo: Copyright
48
Unix es una marca registrada de AT&T Technologies. 23 de Septiembre de 1988

Intro Admon Redes v1.1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Intro Admon Redes v1.1

Uploaded by

Copyright:

Available Formats

Introduccin a la Administracin de una Red Local basada o o en Internet

Introduccin a las distintas tecnolog de conmutacin o as o 6.2.1 6.2.2 6.2.3 6.2.4

7 Congurando gateways 7.1 Congurando el enrutamiento de los gateways . . . . . . . . . . . . . . . . . . . . . . . . . . .

2. Asignacin de direcciones y enrutamiento. o

Asignacin de direcciones y enrutamiento. o

3. Eligiendo una estructura de direcciones.

Eligiendo una estructura de direcciones.

3. Eligiendo una estructura de direcciones.

Debemos subdividir nuestro espacio en direcciones?

3. Eligiendo una estructura de direcciones.

Subredes y m ltiples numeros de red u

3. Eligiendo una estructura de direcciones.

Cmo asignar las subredes o los numeros de red. o

Trabajar con m ltiples subredes virtualesen una red. u

3. Eligiendo una estructura de direcciones.

3. Eligiendo una estructura de direcciones.

Eligiendo una clase de direccin. o

3. Eligiendo una estructura de direcciones.

Lineas IP y micro gateways: direcciones asignadas dinmicamente. a

3. Eligiendo una estructura de direcciones.

3. Eligiendo una estructura de direcciones.

4. Servicios a nivel de red, nombres.

Servicios a nivel de red, nombres.

4. Servicios a nivel de red, nombres.

4. Servicios a nivel de red, nombres.

5. Congurando el enrutamiento de cada ordenador

Congurando el enrutamiento de cada ordenador

5. Congurando el enrutamiento de cada ordenador

Como enrutar los datagramas

5. Congurando el enrutamiento de cada ordenador

El sistema del ejemplo est conectado a dos Ethernet: a

5. Congurando el enrutamiento de cada ordenador

5. Congurando el enrutamiento de cada ordenador

5. Congurando el enrutamiento de cada ordenador

5. Congurando el enrutamiento de cada ordenador

Otros mtodos para que los hosts encuentren rutas e

5. Congurando el enrutamiento de cada ordenador

5. Congurando el enrutamiento de cada ordenador

5. Congurando el enrutamiento de cada ordenador

5. Congurando el enrutamiento de cada ordenador

5. Congurando el enrutamiento de cada ordenador

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

Introduccin a las distintas tecnolog de conmutacin o as o

Comparando las tecnolog de conmutacin as o

Congurando el enrutamiento de los gateways

Unix es una marca registrada de AT&T Technologies. 23 de Septiembre de 1988

You might also like