Administraci�n de una red local basada en Internet\nbasada en Internet\nIntroducci�n para aquellos que pretenden administrar una red basada en los protocolos de red de Internet (TCP/IP)\nCopyright � 1988 Charles L. Hedrick. Cualquiera puede reproducir este documento en su totalidad o en parte, comprometi�ndose a: (1) que en cualquier copia o publicaci�n debe aparecer Rutgers University como fuente, y debe incluir este mensaje; y (2) cualquier otro uso de este material debe hace referncia 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.\nTraducci�n al castellano por\nJuanjo Mar�n <juanjo96@arrakis.es>\n3.1. �DEBEMOS SUBDIVIDIR NUESTRO ESPACIO DE DIRECCIONES?\n3.4.1. Otra forma de trabajar con m�ltiples subredes.\n3.4.2. M�ltiples subredes: Consecuencias en el Broadcasting.\n3.6.1. L�neas IP.\n6.1. DISE�OS ALTERNATIVOS.\n6.1.1. Una red de l�neas punto a punto.\n6.1.2. Tecnolog�a de los circu�tos de conmutaci�n.\n6.1.3. Redes de un s�lo nivel.\n6.1.4. Dise�os mixtos.\n6.2.3. M�s sobre bridges.\n6.2.4. M�s sobre gateways.\n6.3.4. Administraci�n de Redes.\n6.3.5. Una evaluaci�n final.\nEste trabajo trata fundamentalmente sobre los aspectos "l�gicos" de la arquitectura de red. Lo que puede o no puede hacer una red est� generalmente determinado por los protocolos que dicha red soporta y la calidad de sus implementaciones, m�s que por la tecnolog�a concreta de red usada, como Ethernet, Token Ring, etc. Adem�s, en la pr�ctica, la elecci�n de la tecnolog�a de red est� basada en decisiones puramente pragm�ticas: qu� tipo de red soporta el tipo de ordenadores que queremos conectar, las distancias entre los equipos, las 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 peque�as redes, o redes de alta velocidad (t�picamente Token Ring) para la red principal de un campus y para redes de super ordenadores, que ejecutan aplicaciones de altas prestaciones.\nPor tanto, vamos a asumir que hemos llegado a conectar "f�sicamente" unas redes individuales, del tipo Ethernet o Token Ring. Ahora nos enfrentamos a los siguientes problemas interrelacionados:\n* conectar las distintas Redes Ethernet, Token Ring, etc, para formar una �nica red de forma coherente;\nLas anteriores decisiones requieren un peque�o an�lisis. De hecho, la mayor�a de las redes necesitan una "arquitectura" , que determina la manera en que se asignan las direcciones, c�mo se hace el enrutado y otras elecciones, sobre c�mo los ordenadores interaccionan con la red. Estas decisiones deben hacerse para la red en su conjunto, preferiblemente cuando se esta procediendo a su instalaci�n inicial.\nVamos a usar el t�rmino "IP" para referirnos a las redes dise�adas para trabajar con TCP/IP. IP es el protocolo a nivel de red de la familia de protocolos TCP/IP, usados en Internet. Es una pr�ctica com�n usar el t�rmino "IP" cuando nos referimos a direcciones, enrutamiento y otros elementos a nivel de red. La distinci�n muchas veces no es lo suficientemente clara. As� que, en la pr�ctica, los t�rminos Internet TCP/IP e IP pueden parecer incluso intercambiables.\nLos t�rminos "paquete" y "datagrama" tambi�n suelen parecer intercambiables. Conceptualmente, un "paquete" es la unidad f�sica de m�s bajo nivel, mientras que "datagrama" se refiere a la unidad de datos a nivel IP. Sin embargo, en la mayor�a de las redes no se pueden distinguir porque coinciden, as� que la gente suele usar los dos t�rminos indistintamente.\nOtro t�rmino "conflictivo" es el de pasarela ("gateway") y enrutador ("router"). Pasarela es el t�rmino original usado en Internet. Sin embargo, la comunidad OSI empez� a usar esta palabra con un significado distinto, as� que la gente empez� a usar enrutador para evitar dicha ambig�edad. Nosotros, no obstante, seguiremos usando el t�rmino gateway.\nMuchas de las decisiones que se necesitan para la configuraci�n de una red IP depende del enrutamiento. En general, un datagrama IP pasa a trav�s de numerosas redes mientras se desplaza entre el origen y el destino. Veamos un ejemplo t�pico:\nEste gr�fico muestra tres ordenadores, 2 gateways y tres redes. Las redes pueden ser Ethernet, Token Ring o de cualquier otro tipo. La red 2 podr�a ser una l�nea punto a punto que conecta los gateways R y S.\nEl ordenador A puede enviar datagramas al B directamente, usando la red 1. Sin embargo, no puede llegar al ordenador C directamente, puesto que no est�n en la misma red. Hay varias maneras de conectar redes. En el gr�fico asumimos el uso de gateways (m�s adelante veremos otras alternativas). En este caso, los datagramas que van desde A a C deben ser enviados a trav�s del gateway R, red 2 y gateway S. Todos los ordenadores que usan TCP/IP necesitan que se les suministre la informaci�n y algoritmos apropiados para que puedan saber cu�ndo un datagrama debe ser enviado a trav�s de un gateway, y elegir el gateway apropiado.\nEl enrutado est� �ntimamente relacionado con la asignaci�n de direcciones. Podemos apreciar que la direcci�n de cada ordenador comienza con el n�mero de la red a la que pertenece. Por tanto, 128.6.4.2 y 128.6.4.3 se encuentran en la red 128.6.4. Luego los gateways, cuyo trabajo es conectar dos redes, tienen una direcci�n de ambas redes. Por ejemplo, el gateway R conecta la red 128.6.4 y 128.6.21. Su conexi�n a la red 128.6.4 tiene la direcci�n 128.6.4.1. Su conexi�n a la red 128.6.21 tiene la direcci�n 128.6.21.2.\nDebido a esta relaci�n entre direcciones y redes, las decisiones de enrutado deben basarse estrictamente en el n�mero de red de destino. La informaci�n de enrutamiento del ordenador A tendr� el siguiente aspecto:\nred gateway m�trica\nEn 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 "m�trica" ser� usada por alg�n tipo de algoritmo de enrutamiento, como medida de la lejan�a del destinatario. En nuestro caso, la m�trica simplemente indica cuantos diagramas tiene que atravesar para llegar a su destino (conocida como "cuenta de saltos" ).\nCuando el ordenador A est� listo para enviar un datagrama se examina la direcci�n del destinatario. Comparamos el inicio de dicha direcci�n de red con las direcciones de la tabla de enrutamiento. Las distintas entradas de la tabla indican si el datagrama debe ser enviado directamente, o a un gateway.\nUn gateway consiste simplemente en un ordenador conectado a dos redes diferentes, y est� habilitado para enviar datagramas entre ellos. En muchos casos es m�s eficiente usar un equipo especialmente dise�ado para desempe�ar el papel de gateway. Sin embargo, es perfectamente posible usar un ordenador, siempre y cuando tenga m�s de un interfaz de red y un software capaz de enviar datagramas.\nUn gateway tiene varias direcciones, una para cada red a la que est� conectado. Aqu� encontramos una diferencia entre IP y otros protocolos de red: cada interface de un ordenador tiene una direcci�n. Con otros protocolos, cada ordenador tiene una �nica direcci�n, aplicable a todos sus interfaces. Un gateway entre las redes 128.6.4 y 128.6.21 tendr� una direcci�n que comience por 128.6.4 (por ejemplo, 128.6.4.1). Esta direcci�n se refiere a su conexi�n a la red 128.6.4. Tambi�n tendr� una direcci�n que comience con 128.6.21 (por ejemplo, 128.6.21.2). Esta se refiere a su conexi�n a la red 128.6.21.\nEl t�rmino "red" generalmente se suele identificar a dispositivos del tipo Ethernet, en la cual varias m�quinas est�n conectadas. Sin embargo, tambi�n se aplica a l�neas punto a punto. En el gr�fico anterior, las redes 1 y 3 podr�an estar en ciudades distintas; la red 2 podr�a ser una l�nea serie, un enlace sat�lite, u otro tipo de conexi�n punto a punto. Una l�nea punto a punto es tratada como una red que consta s�lo de dos ordenadores. Como cualquier otra red, una l�nea punto a punto tiene una direcci�n de red (en este caso, 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).\nEs posible dise�ar software que no necesite distintos n�meros de red para cada l�nea punto a punto. En este caso, el interface entre el gateway y la l�nea punto a punto no tiene una direcci�n. Esta soluci�n es apropiada cuando la red es tan grande que peligra el hecho de que nos quedemos sin direcciones. Sin embargo, tales "interfaces an�nimas" pueden dificultar bastante el manejo de la red. Puesto que no tienen direcci�n, el software de red no tiene manera de referirse a dicho interface, y, por tanto, no es posible obtener informaci�n sobre el flujo y los errores de la interface.\nAntes de comenzar a montar una estructura de IP, necesitamos uno o m�s n�meros de red oficiales. Una direcci�n IP tiene un aspecto como el siguiente: 128.6.4.3. Esta direcci�n s�lo podr� ser usada por un ordenador de la Universidad de Marx. La primera parte de dicha direcci�n, 128.6, es un n�mero de red asignado a dicha Universidad por una autoridad central. Por tanto, antes de asignarse direcciones a nuestros ordenadores, deberemos obtener una direcci�n oficial de red. Sin embargo, alguna gente configura sus redes usando, o bien una direcci�n aleatoria o usando una direcci�n gen�rica suministrada por defecto en el equipo. Esta forma de trabajar podr�a funcionar en peque�as redes, pero seguramente no lo har� en una mayor. Adem�s, es posible que quisi�ramos conectar nuestra red con la red de otra organizaci�n. Incluso si nuestra organizaci�n tuviese un gran control de seguridad, es posible que tuvi�ramos un ordenador dedicado a la investigaci�n que estuviese conectado a una universidad u otra organizaci�n investigadora. Esta universidad o entidad estar�a seguramente conectada a una red de nivel nacional. Tan pronto como uno de nuestros datagramas salga de nuestra red local va a provocar un estado de confusi�n en la organizaci�n con la que nos comuniquemos, porque la direcci�n que aparece en nuestros datagramas est� probablemente asignada oficialmente a alguien distinto.\nLa soluci�n es simple: obtener una direcci�n propia desde el principio. Adem�s, no cuesta nada.\nLa decisi�n m�s importante que tenemos que hacer para configurar una red es, sin lugar a dudas, c�mo asignar las direcciones IP a los ordenadores. Esta elecci�n debe de hacerse desde el punto de vista de c�mo nuestra red puede crecer. Si no se hiciese as�, es casi seguro que tendremos que cambiar las direcciones en un futuro. Y cuando tengamos varios cientos de ordenadores, cambiar tantas direcciones es casi imposible.\nLas direcciones son muy importantes porque los datagramas IP son enrutados en base a dicha direcci�n. Por ejemplo, las direcciones de la Universidad Groucho Marx tienen una estructura de dos niveles. Una direcci�n t�pica puede ser 128.6.4.3. La direcci�n 128.6 es la asignada a dicha Universidad. Visto desde el exterior, 128.6 es una simple red. Cualquier datagrama enviado desde el exterior, que comience por 128.6, se dirigir� al gateway m�s cercano de la Universidad Groucho Marx. Sin embargo, dentro de Groucho Marx dividimos el espacio de direcciones en "subredes" . Usamos los siguientes 8 bits de direcci�n para indicar a qu� subred pertenece el ordenador. As�, 128.6.4.3 pertenece a la subred 128.6.4. Generalmente, las subredes se corresponden con redes "f�sicas" o reales, por ejemplo una red Ethernet; sin embargo, veremos algunas excepciones m�s adelante. Los sistemas dentro de Groucho Marx, a diferencia de los de fuera, contienen informaci�n sobre la estructura de subredes de Groucho Marx. As�, una vez que un datagrama para 128.6.4.3 llega a Groucho Marx, la red de Groucho Marx lo enrutar� hacia la Ethernet, Token Ring o cualquier otro tipo de red del departamento que tiene asignado la subred 128.6.4.\n* �Dividimos nuestro espacio de direcciones?\n* Si lo hacemos, �usamos subredes o direcciones de clase C?\n* �C�mo debe ser de grande el espacio de direcciones que necesitamos?\nNo es absolutamente necesario usar subredes. Hay mecanismos que permiten actuar a un campus o compa��a completa como una simple y gran Ethernet, as� que no es necesario un enrutamiento interno. Si usamos estas tecnolog�as, entonces no necesitaremos dividir nuestro espacio de direcciones. En este caso, la �nica decisi�n que tenemos que tomar es la de qu� clase de direcci�n debemos de usar. Sin embargo, recomendamos usar un enfoque de subredes o cualquier otro m�todo de subdividir nuestro espacio de direcci�n en varias redes:\n* En la secci�n 6.2. discutiremos que los gateways internos son recomendables para todas las redes, m�s all� de su simplicidad.\n* Incluso si no necesitamos gateways en estos momentos, podemos descubrir que tarde o temprano necesitaremos usarlos. De esta manera, probablemente tiene sentido asignar direcciones como si cada Ethernet o Token Ring fuera una subred separada. Esto permitir� hacer conversiones a subredes reales, si esto es necesario.\nSupongamos que estamos convencidos de que es una buena idea imponer alguna estructura en nuestras direcciones. La siguiente cuesti�n es cu�l es la m�s adecuada. Hay dos enfoques b�sicos: subredes y m�ltiples n�meros de red.\nLos est�ndares de Internet especifican el formato de las direcciones. Para las direcciones que comienzan entre 128 y 191 (las m�s usadas actualmente), los dos primeros octetos forman el n�mero de red; por ejemplo, en 140.3.50.1, 140.3 es el n�mero de red. Los n�meros de red est�n asignados a una organizaci�n particular. �Qu� hacemos con los dos siguientes octetos que le siguen?. Podr�amos optar por hacer al siguiente octeto un n�mero de subred, u otro esquema completamente distinto. Los gateways dentro de nuestra organizaci�n deben configurarse para conocer qu� esquema de divisi�n de redes estamos usando. Sin embargo, fuera de la organizaci�n nadie sabr� si 140.3.50 es una subred y 140.3.51 es otra; simplemente, fuera se sabe que 140.3 es una organizaci�n. Desafortunadamente, esta habilidad de a�adir una estructura adicional a las direcciones, mediante el uso de subredes, no estaba presente en las especificaciones originales y, por tanto, un software antiguo ser�a incapaz de trabajar con subredes. Si una parte importante del software que hemos de usar tiene este problema, entonces no podremos dividir nuestra red en subredes.\nAlgunas organizaciones usan un enfoque distinto. Es posible que una organizaci�n use varios n�meros de red. En lugar de dividir un simple n�mero de red, por ejemplo 140.3, en varias subredes, como de 140.3.1 a 140.3.10, podr�amos usar 10 n�meros distintos de red. De esta manera har�amos una asignaci�n desde 140.3 hasta 140.12. Todo el software IP sabr� que estas direcciones se corresponden con redes distintas.\nA pesar de que usando n�meros de red distintos todo funciona correctamente dentro de la organizaci�n, hay dos serias deventajas. La primera, y menos importante, es que se malgasta un gran espacio de direcciones. Hay solamente sobre unas 16.000 posibles direcciones de clase B. No queremos malgastar diez de ellas en nuestra organizaci�n, a no ser que sea bastante grande. Esta objecci�n es 'menos seria', porque podr�amos pedir una direcci�n C para este prop�sito y hay sobre 2 millones de direcciones C.\nEl problema m�s serio para usar varias direcciones de red, en lugar de subredes, es que sobrecarga las tablas de enrutamiento en el resto de Internet. Como comentamos anteriormente, cuando dividimos nuestro n�mero de red en subredes, esta divisi�n s�lo es conocida dentro de la organizaci�n, pero no fuera. Los sistemas externos a la organizaci�n s�lo necesitan una entrada en sus tablas para ser capaces de llegar. Por tanto, otras Universidades tienen entradas en sus tablas de enrutamiento para 128.6, similar al n�mero de la red de Groucho Marx. Si usa un rango de redes en lugar de subredes, dicha divisi�n ser� visible en todo Internet. Si usamos los n�meros 128.6 a 128.16, en lugar de 128.6, las otras universidades necesitar�an tener una entrada para cada uno de estos n�meros de red en sus tablas de enrutamiento. La mayor�a de los expertos de TCP/IP recomiendan el uso de subredes, en lugar de m�ltiples redes. La �nica raz�n para considerar m�ltiples redes es el uso de un software que no puede manejar subredes. Esto era un problema hace algunos a�os, pero actualmente es poco frecuente.\nUna �ltima indicaci�n sobre subredes: Las subredes deben ser "adyacentes". Esto significa que no podemos conectar la subred 128.6.4 con la subred 128.6.5 mediante otra red, como la 128.121. Por ejemplo, Groucho Marx tiene campus en Simon City y Garfunken City. Es perfectamente posible conectar redes en ciudades distintas que sean subred de 128.6. Sin embargo, en este caso, las l�neas entre Simon City y Garfunken City deben ser parte de 128.6. Supongamos que decidimos usar una red regional como la RegionaLnet para comunicarnos entre dos campus, en lugar de usar su propia l�nea. Puesto que RegionaLnet tiene de n�mero de red 128.121, los gateways y l�neas de serie que usar�an empezar�an por 128.121. Esto viola las reglas. No est� permitido tener gateways o l�neas que son parte de 128.121 conectando dos partes de 128.6. As�, si queremos usar RegionaLnet entre nuestros dos campus, tendr�amos que obtener diferentes n�meros de red para los dos campus. (Esta regla es un resultado de las limitaciones de la tecnolog�a de enrutamiento. Eventualmente podr�a desarrollarse un software para un gateway para manejar configuraciones cuyas redes no son contiguas).\nAhora, una vez decidido si vamos a usar subredes o m�ltiples n�meros de red, tenemos que asignarlos. Normalmente es bastante f�cil. Cada red f�sica, ya sea Ethernet o Token Ring, ..., se le asigna un n�mero distinto de subred. Sin embargo, existen otras opciones.\nEn algunos casos, puede que tenga sentido asignar varios n�meros de subred a una �nica red f�sica. En Groucho Marx hay una �nica Ethernet que ocupa tres edificios, usando repetidores. Est� claro que a medida que vayamos a�adiendo ordenadores a esta Ethernet se ir� dividiendo en varias Ethernets separadas. Para evitar tener que cambiar de direcciones cuando esto suceda, hemos asignado tres n�meros de red distintas a esta Ethernet, una por edificio. (Esto podr�a ser �til, incluso, si no hubi�semos dividido la Ethernet con el fin de 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 n�meros de red. Esta pr�ctica se ver� m�s detalladamente en la secci�n 3.4.\nTambi�n hemos de elegir una "m�scara de subred", que ser� usada por el software del sistema para separar la parte de subred del resto de la direcci�n. Hasta ahora hemos asumido que los dos primeros octetos son el n�mero de red y el siguiente es el n�mero de subred. Para las direcciones de clase B, el est�ndar especifica que los dos primeros octetos pertenecen al n�mero de red. Y, por otro lado, tenemos libertad para establecer el l�mite del n�mero de subred y el resto de la direcci�n. Es bastante usual utilizar un octeto de n�mero de subred, pero no es la �nica posibilidad. Veamos de nuevo esta direcci�n de clase B, 128.6.4.3. Es f�cil deducir que, si el tercer octeto es usado como n�mero de subred, entonces habr� 256 posibles subredes y, en cada subred, habr� 256 posibles direcciones. (En realidad es m�s acertado decir que disponemos de 254, ya que no es buena idea usar 0 � 255 como n�meros de subred o direcci�n). Supongamos que sabemos que nunca vamos a tener m�s de 128 ordenadores por subred, pero es probable que necesitemos m�s de 256 subredes (por ejemplo, un campus con una gran cantidad de peque�os edificios). En ese caso, podr�amos establecer 9 bits como n�mero de red, dejando 7 bits para el direccionamiento de cada subred. Esta decisi�n queda plasmada en una m�scara de bits, usando unos para los bits usados por los n�meros de red y de subred y ceros para los bits usados para el direccionamiento individual. La m�scara de red m�s com�n es 255.255.255.0. Si elegimos 9 bits para el n�mero de subredes y 7 para las direcciones, la m�scara de subred ser�a 255.255.255.128.\nGeneralmente, es posible especificar la m�scara de subred como parte de la configuraci�n del software IP. Los protocolos IP tambi�n permiten a los ordenadores que env�en un mensaje preguntando cu�l es su m�scara de subred. Si nuestra red soporta el env�o de estos mensajes, y hay, al menos, un ordenador o gateway de la red que conoce dicha m�scara de subred, posiblemente ser� innecesario especificarlo en cada uno de los restantes ordenadores. Pero esta posibilidad puede traer muchos problemas. En caso de que nuestra implementaci�n TCP/IP diera una m�scara de subred err�nea, se causar�a una mala configuraci�n en toda la red. Por lo tanto, es m�s seguro poner cada m�scara de subred expl�citamente en cada sistema.\nLa mayor�a del software est� desarrollado bajo el supuesto de que cada red local tiene el mismo n�mero de subred. Cuando existe un flujo hacia una m�quina con un distinto n�mero de subred, el software espera encontrar un gateway que pueda dirigirlo hacia esa subred. Veamos detalladamente qu� ocurre en este 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 tendr� problemas para comunicarse con las m�quinas de direcci�n 128.6.19.x. Estas m�quinas est�n en la misma subred, y nuestro ordenador simplemente deber� enviar los datagramas al 128.6.20.2. Puesto que esta direcci�n indica que est� en una subred distinta, la mayor�a del software esperar� encontrar un gateway que haga de puente entre ambas subredes. Por supuesto, no existe un gateway entre las "subredes" 128.6.19 y 128.6.20, puesto que est�n en la misma Ethernet. De aqu� se deduce que tenemos que encontrar una manera de indicarle al software que el 128.6.20 se encuentra realmente en la misma Ethernet.\nLa mayor�a de las implementaciones TCP/IP pueden manejar m�s de una subred en la misma red. Por ejemplo, el Berkeley Unix nos permite hacerlo usando una ligera modificaci�n del comando usado para definir 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 direcci�n 128.6.19.1, podemos usar el comando\nEsto indica que para llegar a la subred 128.6.4 el flujo debe ser enviado a trav�s del gateway 128.6.19.1. El "1" se refiere a la "m�trica de enrutamiento". Si usamos la m�trica "0", estamos diciendo que la subred de destino est� en la misma red y, por consiguiente, no se necesita ning�n gateway. En nuestro ejemplo, deberemos usar en el sistema 128.6.19.3\nLa direcci�n usada en el lugar de 128.6.19.1 es irrelevante. La m�trica "0" nos informa de que no va a usarse ning�n gateway, luego no se usar� dicha direcci�n. Sin embargo, deber� ampliarse una direci�n legal de la red local.\nHay otro modo de manejar varias subredes sobre una red f�sica. Este m�todo supone la desconfiguraci�n de nuestros anfitriones o hosts y, por ello, es potencialmente peligrosa, si no sabemos exactamente lo que estamos haciendo. Sin embargo, puede resultar m�s c�modo cuando trabajamos con una gran cantidad de subredes en una red f�sica. Un ejemplo de este tipo ser�a una instalaci�n que use bridges, y usa subredes simplemente por facilidades de administraci�n. El truco est� en configurar el software de nuestros hosts como si no usasen subredes. As�, nuestros hosts no har�n ninguna distinci�n entre las distintas subredes y, por tanto, no habr� problemas para trabajar con todas ellas. Ahora, el �nico problema es c�mo comunicarnos con subredes que no est�n en esta red de m�ltiples subredes. Pero, si nuestros gateways manejan proxy ARP, ellos resolver�n este problema por nosotros. Este enfoque est� especialmente indicado cuando la misma red contiene m�ltiples subredes y, particularmente, si se van a a�adir algunas m�s en un futuro. Desgraciadamente, tiene dos problemas:\n- Si tenemos hosts con m�ltiples interfaces, deberemos ser muy cuidadosos. En primer lugar, s�lo deber�a haber m�quinas con un interface en la red con m�ltiples subredes. Por ejemplo, supongamos que disponemos de una red que consta de varias Ethernets conectadas mediante bridges; no podemos tener una m�quina con interfaces en dos de estas Ethernets, pero podemos tener un sistema con un interface en esta red de subredes m�ltiples y otra en otra subred apartada de �sta. En segundo lugar, cualquier m�quina con m�ltiples interfaces deber� conocer la verdadera m�scara de subred, y necesitar� estar informada expl�citamente de cu�les de las subredes est�n en la red de m�ltiples subredes. Estas restricciones son consecuencia de que un sistema con m�ltiples interfaces tiene que conocer qu� interface ha de usar en cada caso.\n- Tambi�n deberemos prestar atenci�n a la facilidad ICMP de la m�scara de subredes. Esta facilidad permite a los sistemas emitir una consulta para conocer cu�l es la m�scara de subred. Si la mayor�a de los hosts piensan que la red no est� dispuesta en subredes, pero los gateways y los hosts con varias interfaces piensan lo contrario, tenemos aqu� un foco potencial de confusi�n. Si un gateway o hosts con varios interfaces env�a una r�plica a una ICMP de m�scara de red, dando la verdadera m�scara de subred, alguno de los restantes hosts puede interceptarlo. La situaci�n contraria tambi�n ser�a posible. Esto significa que tendremos que\n* deshabilitar las r�plicas a las ICMP de m�scara de subred en todos aquellos sistemas que conocen la m�scara real de subred (esto es especialmente f�cil si solamente los gateways lo conocen);\n* asegurar que nuestros hosts ignoran las r�plicas ICMP.\nA medida que establecemos una m�scara de subred expl�citamente, se supone que los hosts ignoran los ICMP de m�scara de subred, as� que deberemos ser capaces de establecer diferentes m�scaras en diferentes hosts sin causar ning�n problema, siempre y cuando podamos establecer la m�scara expl�citamente en todos ellos. Sin embargo, existen implementaciones IP que cambiar�n su m�scara de subred cuando vean una r�plica de ICMP de m�scara de subred.\nCuando tenemos m�s de una subred en una misma red f�sica, hay que tener cuidado respecto a las direcciones de broadcasting. De acuerdo con los �ltimos est�ndares, hay dos formas distintas para que un host de la subred 128.6.20 pueda enviar un broadcast en la red local. Una es usar la direcci�n 128.6.20.255. La otra es usar la direcci�n 255.255.255.255. La direcci�n 128.6.20.255 dice, expl�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, tambi�n recibir� el mensaje enviado a 255.255.255.255. Sin embargo, los hosts con n�meros 128.6.19.x no escuchar�n los mensajes enviados a 128.6.20.255. El resultado es que ah� tenemos dos tipos distintos de direcciones de broadcast con dos significados distintos. Esto conlleva que debemos tener cuidado configurando el software de red, para asegurarnos de que nuestros broadcasting llegan a donde queremos que lo hagan.\nCuando solicitamos un n�mero oficial de red se nos preguntar� qu� clase de n�mero de red necesitamos. Las posibles respuestas son A, B y C. La decisi�n elegida limitar� nuestro espacio de direcciones a usar. Las direcciones de clase A ocupan un octeto; las de clase B, dos octetos, y la clase C, tres octetos. Luego, hay m�s direcciones de clase C que direcciones de clase A, pero las de clase C no pueden tener muchos hosts. La idea que podemos sacar de lo anterior es que deber�a haber pocas grandes redes, un n�mero moderado de redes de tama�o Mediano y bastantes peque�as redes. En la siguiente tabla observamos dicha distinci�n:\nPor 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 signfica 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 m�s). La red 192.12.88, una direcci�n de clase C, tendr� sus hosts entre el 192.12.88.1 y el 192.12.88.254 y, por lo tanto, habr� 254 posibles hosts.\nEn general, deberemos elegir la clase menor que nos proporcione suficientes direcciones capaces de direccionar nuestra red, con sus posibles futuras ampliaciones. Aquellas organizaciones que usan ordenadores en varios edificios, probablemente necesitar�n una direcci�n de clase B, suponiendo que vamos a usar subredes. (Y si vamos a tratar con distintos n�meros de red, deber�amos solicitar varias direcciones de clase C). Las direcciones de clase A, normalmente, s�lo se usan en grandes redes p�blicas y algunas pocas redes de grandes corporaciones.\nEn la asignaci�n de Direcciones IP, la autoridad m�xima es la IANA (Internet Assigned Number Authority). 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:\n* El RIPE NCC (RIPE Network Coordination Center) es el registro delegado de Internet a nivel europeo y se encarga, entre otras tareas, de la asignaci�n de bloques de direcciones IP a los proveedores de servicios Internet en Europa y su �rea de influencia.\n* El AP-NIC lleva a cabo la tarea de asigacion de bloques de direcciones IP a los proveedores de la regi�n del Asia-Pac�fico.\n* El InterNIC se encarga de la asignaci�n de bloques de direcciones IP a los proveedores de Internet en Am�rica del Norte y, de momento, en el resto del mundo.\nLas organizaciones y usuarios finales han de obtener las direcciones IP necesarias para conectarse a Internet a trav�s de su proveedor de acceso a Internet, quien a su vez las habr� obtenido bien de su proveedor de tr�nsito, bien del registro regional correspondiente.\nEn la mayor�a de los casos, cada uno de los ordenadores tendr� su propia direcci�n IP permanente. No obstante, hay algunas situaciones donde tiene m�s sentido asignar direcciones din�micamente. La mayor�a de los casos que manejan l�neas IP constan de gateways destinados principalmente a microcomputadoras\nEs posible usar IP sobre l�neas telef�nicas. Uno de los protocolos para hacer esto es el SLIP ("Serial line IP"). SLIP se usa frecuentemente en, al menos, dos circunstancias distintas:\n* Como una alternativa barata a l�neas punto a punto permanentes, para aquellos casos en los que no est� suficientemente justificado una l�nea dedicada.\nVamos a usar el t�rmino "servidor SLIP" para referirnos a un sistema de ordenador(es) que incluye una 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.\nSi tenemos varios PC's conectados mediante SLIP, muchas veces no es pr�ctico usar una direcci�n IP propia para cada PC. Una de las razones puede ser que no haya suficientes direcciones. Para que el enrutamiento funcione correctamente, estos sistemas conectados deben tener sus direcciones en la misma subred que el servidor SLIP. Por lo general, hay solamente del orden de 256 direcciones disponibles en cada subred. Si el n�mero de PC's que pueden conectarse es mayor que esa cifra, no podremos asignarles su propia direcci�n. Si, adem�s, tenemos servidores SLIP en m�s de una subred, la asignaci�n permanente de direcciones se hace a�n m�s complicada. Si un usuario es capaz de llamar a dos servidores, su PC necesitar�a dos direcciones, una para cada subred.\nPara solucionar estos problemas, la mayor�a de las implementaciones SLIP asignan las direcciones din�micamente. Cuando un PC se conecta con el servidor SLIP, el servidor busca una direcci�n IP que no se est� usando y se la asigna al PC. La forma m�s simple de manejar esto es dando a cada servidor SLIP un rango de direcciones IP que controle y pueda asignar.\nCuando usamos este esquema, el software SLIP debe comunicar al PC, de alguna manera, qu� direcci�n debe usar. Si cada PC tiene una direcci�n permanente, tendr�amos el problema contrario: cuando un PC se conecta con un servidor debe de haber alg�n m�todo para que el PC comunique al servidor su direcci�n. Este problema debe ser estudiado cuidadosamente, porque en otro caso alguien podr�a usar la direcci�n de otro y tener acceso a sus ficheros.\nDesafortunadamente, no hay un est�ndar para manejar estos problemas de direccionamiento con SLIP. Hay varias implementaciones SLIP que lo hacen, pero todav�a no hay un est�ndar. Hasta que no se elabore �ste, deberemos tener cuidado con el software SLIP. Tenemos que asegurarnos de que dicha asignaci�n de direcci�n se lleva a cabo de la manera que queremos y que nuestro servidor SLIP y los PC's tienen claro la forma en que se asignan las direcciones.\nRecomendamos dar direcciones permanentes a los PC's en aquellos casos en que los dem�s ordenadores tienen que ser capaces de conocer con qu� PC est�n hablando. Este podr�a ser el caso de un PC para recibir correo privado, o cualquier otro servicio con transacciones delicadas. Y recomienda el direccionamiento din�mico cuando tenemos un gran n�mero de PC's y las aplicaciones que utilizan para acceder a la red tienen sus propios mecanismos de seguridad.\n* Tratar a las conexiones SLIP como si se tratasen de l�neas punto a punto que no est�n disponibles permanentemente. Si podemos conectar con m�s de un ordenador, cada par de ordenadores que se comunican tienen un n�mero de red distinto del que ellos usar�an cuando se comunican con el otro.\n* Usar un software de enrutamiento que permita interfaces an�nimos. En este caso, no ser�an necesarias las direcciones.\n* Asignar direcciones din�micamente cuando la conexi�n est� abierta, tan pronto como el PC haya contactado.\nSi hacemos s�lo una o dos conexiones a otro sistema, es bastante razonable usar un n�mero de red para cada conexi�n. Este m�todo es f�cil de usar y limita los errores estad�sticos.\nSi tenemos muchas conexiones distintas, probablemente es mejor usar interfaces an�nimos. Aunque si los sistemas de enrutamiento no lo soportan, debemos usar asignaci�n din�mica.\nAl igual que SLIP, PPP "Point to Point Protocol" es un protocolo serie distinto utilizado para enviar datagramas a trav�s de una conexi�n serie, pero mejora algunas de las carencias del anterior. El PPP permite a las partes comunicantes negociar opciones como las direcciones IP y el tama�o m�ximo de los datagramas al comenzar la conexi�n, y proporciona permisos de conexi�n a los clientes (autorizaciones). Para cada una de estas capacidades, el PPP tiene un protocolo concreto.\nA continuaci�n, citaremos los elementos b�sicos que constituyen el PPP. Esta descripcion esta muy lejos de ser completa; si quiere saber mas sobre el PPP, lea sus especificaciones en el RFC 1548, asi como en la docena de RFCs que le acompa�an.\nEn la parte m�s baja del PPP est� el protocolo de Control de Conexi�n de Datos de Alto-Nivel, abreviadamente HDLC. ( En realidad, el HDLC es un protocolo mucho m�s general publicado por la Organizaci�n Internacional de Est�ndares, ISO ) que define los l�mites de las tramas PPP individuales, y proporciona un control de errores de 16 bit. Al contrario de lo que ocurr�a en las encapsulaciones SLIP m�s antiguas, 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 a�adiendo a la trama b�sica HDLC un campo de control que identifica el tipo de paquete contenido en la trama.\nEl LCP, Protocolo de Control de Enlace, es utilizado en la parte m�s alta del HDLC para negociar las opciones concernientes a la conexi�n de datos, tales como la Unidad M�xima de Recepci�n (MRU) que establece el tama�o m�ximo del datagrama que una de las partes de la conexi�n acepta recibir.\nEs perfectamente posible que un microcomputador forme parte de una red IP. Pero hay una tendencia de que los micros utilicen distintas tecnolog�as de red que la de los grandes sistemas. Esto es debido a que muchos de los usuarios de micros empiezan a demandar un software de red dise�ado espec�ficamente para las necesidades de un micro, incluso para un particular tipo de micro. Muchos usuarios est�n interesados en usar TCP/IP sin tener que abandonar su red especial de micro, a la que est�n acostumbrados. Por esta raz�n, hay un creciente n�mero de productos, especialmente gateways, que dan acceso a los PC's tanto a redes orientadas a micros como a TCP/IP.\nEn esta secci�n vamos a hablar del AppleTalk, de Apple, a modo de ejemplo. No obstante, existen productos similares para otros tipos de redes de micros. Hay que aclarar que el t�rmino AppleTalk se asocia a los protocolos de red de Apple, mientras que LocalTalk se asocia a una tecnolog�a espec�fica de par trenzado, en la que AppleTalk fue inicialmente implementada. Por tanto, el AppleTalk es an�logo a los protocolos TCP/IP, mientras que LocalTalk es an�logo a medio Ethernet.\nAlgunas compa��as ofrecen gateways para conectar una red AppleTalk corriendo sobre LocalTalk, con redes IP corriendo sobre Ethernet. A pesar de que hay varios productos de este tipo, la mayor�a de ellos incluyen los siguientes servicios:\n* Las aplicaciones TCP/IP de un PC pueden conectarnos a sistemas TCP/IP de la Ethernet. Se definen utilidades especiales para permitirnos llevar datagramas IP desde el PC hasta el gateway, a trav�s del LocalTalk. Las aplicaciones TCP/IP de PC han sido escritas usando unas librer�as especiales que mezclan AppleTalk y TCP/IP. Las utilidades AppleTalk se necesitan para llevar los datagramas hasta el gateway, donde se transformar�n en datagramas 100% TCP/IP, antes de dejarlos en la Ethernet.\n* Se pueden escribir aplicaciones AppleTalk para grandes sistemas, de tal manera que un PC podr� usarlos como servidores. Dichas aplicaciones tambi�n han sido escritas haciendo uso de una librer�a especial que mezcla AppleTalk y TCP/IP. Pero, en esta ocasi�n, son utilidades TCP/IP para dejar datagramas en el gateway, donde se transformar�n totalmente en AppleTalk, antes de dejarlos en la AppleTalk y lleguen al PC.\n* Una red IP de un campus o una corporaci�n puede ser usada para conectar redes AppleTalk. Los gateways de cada Applet realizar�n las conversiones necesarias antes de enviar los datagramas a la red IP.\nAdem�s, algunos gateways pueden hacer traducciones a nivel de aplicaci�n. Por ejemplo, algunos gateways pueden hacer traducciones entre el sistema de ficheros de Apple y el sistema de fichero de red de Sun (NFS). Esto permite a un PC acceder al sistema de ficheros Unix, donde el PC usa el sistema de ficheros Apple, y el acceso al sistema Unix se hace mediante el uso del sistema NFS, o sistema de ficheros de red ( Network File System ), de Sun.\nDesafortunadamente, la gran flexibilidad 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 asignaci�n din�mica de direcciones IP. Para ello asignaremos un rango de direcciones IP a cada gateway. Cuando un PC intenta abrir una conexi�n TCP/IP, el gateway se hace con una direcci�n 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 direcci�n. Otra vez, la elecci�n depender� del n�mero de PC's que tengamos y de si tenemos aplicaciones capaces de usar la direcci�n IP para identificar qu� PC, en particular, es el que est� conectado.\nEl direccionamiento es mucho m�s complejo, debido a que AppleTalk tiene su propia estructura de direcciones. Deberemos establecer una correspondencia entre direcciones AppleTalk y n�meros de red IP. Tambi�n habr� una correspondencia entre direcciones IP y AppleTalk, que se establecer� din�micamente en los gateways.\nSi vamos a tener una red TCP/IP, hay algunas tareas importantes que realizar. Algunas de ellas son simplemente de tipo administrativo. La m�s importante es crear un registro central de nombres y direcciones 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 instituci�n sobre nuestros hosts sean dirigidos a nuestros servidores.\nQueremos mantener una base de datos que contenga la informaci�n de cada sistema de la red. Como m�nimo, necesitaremos el nombre y la direcci�n IP de cada sistema. Probablemente, el registro central ser� el encargado de asignar las direcciones IP. Si nuestra red est� estructurada en subredes, o si usamos varios n�meros de clase C, el registro posiblemente asignar� los n�meros de red a las nuevas redes o subredes. Pero, habitualmente, se permitir� que los propios administradores de los hosts elijan el nombre del host. Sin embargo, el registro debe de, al menos, verificar 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.\nSe recomienda asignar las direcciones de la forma m�s simple: empezando por 1. As�, si nuestra red es la 128.6, podr�amos asignar como 128.6.1 a la primera subred; 128.6.2, a la segunda, etc. La asignaci�n de direcciones IP para hosts individuales podr�an empezar por 2. De esta manera reservamos la direcci�n 1 de cada subred para que sea usada por el gateway correspondiente. Por consiguiente, el primer host de la subred 128.6.4 ser�a el 128.6.4.2; el siguiente ser�a 128.6.4.3, y as� sucesivamente. Hay una raz�n b�sica para mantener las direcciones tan cortas como sean posibles. Si tenemos una gran organizaci�n, podr�amos quedarnos sin n�meros de subred. Si esto ocurriera, y nuestros hosts tienen n�meros de red bajos, podr�amos asignar otro bit para el direccionamiento de las subredes. Si, por ejemplo, usamos el tercer octeto como n�mero de subred, en tanto en cuanto nuestros hosts tengan unos n�meros inferiores a 128, podremos ampliar el n�mero de red a 9 bits. As�, por ejemplo, la subred 128.6.4 podr�a dividirse en dos subredes distintas: 128.6.4.0 y 128.6.4.128. Si hubi�semos asignado a los hosts n�meros por encima de 128, la divisi�n habr�a sido imposible.\nLa asignaci�n de nombres de los hosts no es tan sistem�tica. Pueden ser cualquier expresi�n compuesta de letras, n�meros y guiones. Es m�s seguro que el primer car�cter sea una letra. Y, desde el punto de vista de los usuarios, es recomendable que los nombres sean lo m�s cortos posibles (incluso hay software que tiene problemas trabajando con nombres m�s largos de 16 caracteres). Muchas veces, los departamentos o proyectos eligen un tema o nombre relacionado con ellos. Por ejemplo, las m�quinas usadas por los estudiantes de Inform�tica de Groucho Marx tienen nombres de bandas de rock: OASIS, BLUR, IRONMAIDEN, SAVOY, etc. Nuestro departamento de Matem�ticas usa el nombre de famosos matem�ticos: GAUSS, FERMAT, etc. Si la instituci�n no tiene ninguna relaci�n con el mundo exterior, cualquier nombre es adecuado.\nSi estamos conectados a Internet, nuestra organizaci�n necesitar� un "nombre de dominio" (domain name ). Al igual que en el caso del espacio de direcciones IP, la autoridad m�xima del espacio de nombres de Internet (DNS, Domain Name System) es la IANA (Internet Assigned Number Authority). La ra�z del DNS es gestionada por el InterNIC por delegaci�n de la IANA. Bajo la ra�z se encuentran los distintos dominios de primer nivel (Top Level Domains o TLD's) gestionados por distintos registros delegados de Internet. Algunos de ellos son: Dominios "especiales" como COM, ORG, NET, EDU,... controlados por InterNIC ( nodo central del Network Internet Center ); y dentro de los dominios nacionales, el dominio ES, correspondiente a Espa�a, est� delegado a ES-NIC.\nA diferencia del n�mero de red, podremos arregl�rnosla sin �l si la red est� aislada. Si posteriormente lo necesitamos, es f�cil de a�adir un nombre de dominio. (Recomendamos usar un n�mero de red desde el principio, porque cambiar n�meros de red posteriormente puede ser traum�tico). Los nombres de dominio, normalmente, terminan en .EDU para las instituciones educativas, .COM, para las compa��as, etc. Por ejemplo, la Universidad de Groucho Marx tiene como nombre de dominio GROUCHO.EDU. El formato de los nombres completos de dominio consiste en un nombre interno, seguido del nombre de dominio de la organizaci�n. As�, si un ordenador es conocido internamente como ATHOS, su nombre completo ser� GAUSS.GROUCHO.EDU. Si tenemos una gran organizaci�n, es posible tener subdominios. Por ejemplo, puede que haya un subdominio para cada departamento; esto a�adir�a otro t�rmino en los nombres. Si, por ejemplo, el departamento de Matem�ticas decide crear su subdominio, el anterior ordenador se llamar�a GAUSS.MATHS.GROUCHO.EDU. Una vez asignado el nombre de dominio, se procede a cambiar los ficheros de configuraci�n donde aparece 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.\nSi tenemos m�s de uno o dos sistemas, necesitaremos tener alg�n mecanismo para tener al d�a la informaci�n 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. El software tendr� que traducir el nombre en una direcci�n IP, para poder abrir la conexi�n. La mayor�a del software incluye dos vias para hacer esta traducci�n: una tabla est�tica o un servidor de nombres. La soluci�n de la tabla est� indicada para peque�as organizaciones, siempre y cuando no est�n conectadas a otra red. Simplemente se crea un fichero que lista los nombres y direcciones de todos los hosts. Veamos parte de una tabla de este tipo:\nComo se puede apreciar, el formato es el siguiente: una l�nea para cada sistema y listar sus direcciones, nombres y otra informaci�n sobre �l. En el ejemplo, tanto ARAMIS como ATHOS est�n en dos redes, as� que tienen dos direcciones. Adem�s, ambos tienen un nombre principal, por ejemplo ARAMIS.GROUCHO.EDU, y apodos, por ejemplo ARAMIS. En caso de estar conectados a Internet, el nombre principal ser� el nombre de dominio completamente especificado. Se incluyen apodos cortos, para facilitar la tarea a nuestros usuarios. Hay otro formato muy frecuente para las tablas de hosts. Veamos un ejemplo:\nEn este formato, cada l�nea representa una direcci�n IP. Si el sistema tiene dos interfaces, hay dos l�neas de �l en la tabla. Se debe procurar poner, en primer lugar, aquellas direcciones de uso m�s com�n. La documentaci�n de su sistema le informar� sobre el formato usado por �l.\nEn la configuraci�n m�s simple, cada ordenador tiene su propia copia de la tabla de hosts en /etc/hosts. En caso de elegir esta configuraci�n, deberemos establecer procedimientos para asegurarnos que todas las copias son actualizadas regularmente. En una red peque�a no es dificil mantener una tabla /etc/hosts en cada m�quina, y modificarla al agregar, eliminar o modificar nodos. Aunque resulta complicado cuando hay muchas m�quinas, ya que, en principio, cada una necesita una copia de /etc/hosts.\nUna soluci�n a esto es compartir �sta y otras bases de datos con el NIS, o sistema de informaci�n de red ( Network Information System ), desarrollado por Sun Microsystems y conocido tambi�n como p�ginas 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 acceder�n a ellas de forma transparente al usuario. En todo caso, esta soluci�n s�lo es aconsejable para redes peque�as o medianas, ya que implican mantener un fichero central /etc/hosts que puede crecer mucho, y luego distribuirlo entre los servidores NIS.\nEn redes grandes, y todos aquellos que est�n conectados a Internet, debemos adoptar un nuevo sistema, el DNS o sistema de nombres por dominios ( Domain Name System) dise�ado por Paul Mockapetris. T�cnicamente, el DNS es una inmensa base de datos distribu�da jer�rquicamente por toda la Internet; existen infinidad de servidores que interact�an entre si para encontrar y facilitar a las aplicaciones clientes que los consultan la traducci�n de un nombre a su direccion de red IP asociada, con la que poder efectuar la conexi�n deseada. Cada parte de la base de datos est� replicada en, al menos, dos servidores, lo que asegura 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�a una petici�n al servidor de nombres. Este enfoque tiene dos ventajas:\n* Para los grandes sistemas, es m�s f�cil tener al d�a las tablas en algunos servidores de nombres que en todo el sistema.\n* Si nuestra red est� conectada a Internet, nuestro servidor de nombres ser� capaz de dialogar con los servidores de nombres de otras organizaciones, para buscar nombres de cualquier sitio.\nUsar un servidor de nombres es el �nico camino para tener un acceso completo a la informaci�n del resto de los hosts de Internet.\nEs 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 enviar�n al servidor de nombres, y procesa sus correspondientes respuestas. Cada sistema deber�a usar un resolvedor (en general, el resolvedor es cargado por cada programa que va a hacer uso de la red, puesto que s�lo es un conjunto de subrutinas). Hay que recalcar que s�lo se necesitar�n 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.\nPara usar un resolvedor, cada ordenador necesitar� un fichero de configuraci�n, u otro m�todo, para especificar la direcci�n del servidor de nombres al que enviar nuestras peticiones. Por regla general, se pueden 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 ning�n servidor, la mayor�a de nuestro software empezar�a a fallar. Por tanto, hay que ser muy cuidadoso y declarar tantos servidores como podamos para intentar asegurar un buen funcionamiento.\nLos servidores de nombres, generalmente, tienen un conjunto de opciones para su configuraci�n. En lugar de dar algunos consejos sobre c�mo configurar un servidor de nombres, vamos a recomendar dos documentos oficiales de los est�ndares de Internet. El RFC 1032 contiene las instrucciones sobre c�mo conseguir un nombre de dominio del Centro de Informaci�n de Red, incluyendo los formularios necesarios. El RFC 1033 contiene las instrucciones sobre c�mo configurar un servidor de nombres. Todos estos documentos son de tipo conceptual. Seguramente, tambi�n necesitar� documentaci�n sobre el software espec�fico de su servidor de nombres.\nEn algunos casos, puede que se necesiten, a la vez, tablas y servidores de nombres. Si tenemos alguna implementaci�n de TCP/IP que no incluyan resolvers, estamos obligados a instalar tablas de hosts en estos sistemas. Si nuestra red est� conectada a Internet, vamos a tener problemas con aquellos sistemas que 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 ning�n modo. As� que tendremos que a�adir los hosts favoritos de los usuarios. Los sistemas que usan resolvers no tendr�n este problema, puesto que un servidor de nombres es capaz de traducir cualquier nombre legal de host.\nLos nombres de Hosts y la asignaci�n de n�meros son los �nicos elementos que deben de tener una estructura centralizada. Sin embargo, puede haber otros elementos susceptibles de centralizaci�n. Es bastante frecuente tener uno o dos ordenadores que se hagan cargo de todo el correo electr�nico. Si estamos conectados a 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 elecci�n del gateway correcto, y transformar la direcci�n de correo electr�nico correctamente, es una tarea muy especializada. Por esto, en muchas ocasiones se configura el software apropiado s�lo en un lugar, y todo el correo externo (o todo el correo externo a hosts que no est�n en Internet) se dirige a este sistema.\nTodas las implementaciones TCP/IP necesitan alguna configuraci�n en cada host. En algunos casos, esto se hace durante la instalaci�n del sistema de forma casi autom�tica. En otros casos, mediante la configuraci�n de ciertos programas o ficheros. Y, por �ltimo, otros sistemas obtienen la informaci�n de configuraci�n a trav�s de la red de un "servidor".\nA pesar de que los detalles de la configuraci�n pueden diferir bastante, existen ciertos datos que deben incluirse en todos los casos. Entre ellos:\n- par�metros que describan a una m�quina en particular, como su direcci�n IP;\n- par�metros que describan la red, como su subm�scara de red (si hubiera);\nAntes de que se instale un ordenador en una red, un coordinador deber� asignarle un nombre de red y su direcci�n IP, como describimos anteriormente. Una vez otorgado un nombre y una direcci�n estamos en disposici�n de configurarlo. En numerosas ocasiones, lo que debemos hacer es poner la direcci�n y el nombre en un fichero de configuraci�n. Sin embargo, algunos ordenadores (especialmente aquellos que no disponen de un disco propio en el que dicha informaci�n pueda ser almacenada) deben obtener esta informaci�n a trav�s de la red. En el momento en que un sistema arranca, se realiza un broadcast a la red con la petici�n "�qui�n soy?" . En el caso de poseer ordenadores de este tipo, debemos asegurarnos de que nuestra red est� preparada para responder adecuadamente. La pregunta l�gica es: �c�mo otro sistema sabe qui�n eres?. Generalmente, esto se soluciona haciendo uso de las direcciones Ethernet (o las direcciones an�logas para otro tipo de redes). Las direcciones Ethernet son asignadas por los fabricantes hardware. Est� garantizado que s�lo una m�quina en todo el mundo tiene una determinada direcci�n Ethernet. Por lo general, dicha direcci�n est� grabada en una ROM en la tarjeta Ethernet de la m�quina. La m�quina, probablemente, no conozca su direcci�n IP, pero sin duda conoce su direcci�n Ethernet. Por esta raz�n, la petici�n "�qui�n soy?" incluye la direcci�n Ethernet. Y habr� sistemas configurados para responder a estas peticiones, buscando en una tabla que hace corresponder a cada direcci�n Ethernet su direcci�n IP. Pero, por desgracia, deberemos configurar y actualizar esta tabla perodicamente. Para este fin se usa el protocolo de RARP (Reverse Address Resolution Protocol); existe adem�s otro protocolo, el BOOTP o protocolo de arranque. En general, los ordenadores est�n dise�ados de tal manera que muestran su direcci�n Ethernet por pantalla, tan pronto como se enciende el mismo. Y, en la mayor�a de los casos, disponemos de un comando que muestra esta informaci�n del interfaz Ethernet.\nGeneralmente, la m�scara de subred debe especificarse en un determinado archivo (en los sistemas Unix, el comando "ifconfig" , donde "if" significa interface, se usa para especificar tanto la direcci�n Internet como la m�scara de subred). No obstante, hay previsiones en los protocolos IP para permitir un broadcast de un ordenador, preguntando por la m�scara de red. La subm�scara de red es un atributo de la red y, por ello, es 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, s�lo determinados ordenadores contestan peticiones de la m�scara de red, pero, en muchas implementaciones TCP/IP, est�n dise�adas de tal manera que si un ordenador cree conocer la m�scara de red debe contestar, y, por tanto, en estas implementaciones, la mala configuraci�n de la m�scara de subred en un solo ordenador puede causar un mal funcionamiento de la red.\nPor regla general, los ficheros de configuraci�n hacen, a grosso modo, las siguientes cosas:\n* Habilitar cada interfaz de red (Ethernet, l�neas serie, etc.). Normalmente, esto conlleva la especificaci�n de una direcci�n Internet y una m�scara de red para cada uno, as� como otras opciones especiales de cada dispositivo.\n* Establecimiento de la informaci�n de enrutamiento de la red, tanto por comandos que establecen rutas, como ejecucando un programa que las obtiene din�micamente.\n* Activar el sistema de dominios (usado para buscar nombres y encontrar la correspondiente direcci�n Internet -mirar la secci�n del sistema de dominio, en la Introducci�n al TCP/IP-). Los detalles depender�n del sistema de dominios usado. En la mayor�a de los casos, s�lo algunos hosts deber�n ejecutar el servidor de nombres de dominios. Los otros hosts, simplemente, necesitan ficheros de configuraci�n, que especifican d�nde se encuentra el servidor m�s cercano.\n* Establecer otro tipo de informaci�n necesaria para el sistema software, como, por ejemplo, el nombre del propio sistema.\nSi nuestro sistema consiste en una simple Ethernet, o un medio similar, no ser� necesario prestar demasiada atenci�n al enrutamiento. Pero, para sistemas m�s complejos, cada una de las m�quinas necesita una tabla que contenga el gateway y el interfaz necesario para cada posible destino. Vimos un ejemplo simple en una secci�n anterior, pero ahora es necesario describir el modo como funciona el enrutamiento, con un poco m�s de detalle. En la inmensa mayor�a de los sistemas, la tabla de enrutamiento tendr� un aspecto similar (este ejemplo ha sido tomado de un sistema con Berkeley Unix, usando el comando "netstat -n -r"; algunas columnas que contienen informaci�n estad�stica han sido omitidas):\nEl sistema del ejemplo est� conectado a dos Ethernet:\nLa primera columna muestra el nombre de la interface Ethernet; la segunda, es el n�mero de red para esa Ethernet; la tercera columna es la direcci�n Internet de esa red, y, la �ltima muestra otras subredes que comparten la misma red f�sica.\nEstudiemos 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 d�nde deben ser enviados los datagramas destinados a dicha red. Si aparece la bandera "G" en la tercera columna, los datagramas tienen que enviarse a trav�s de un gateway; en caso de no aparecer, el ordenador est� directamente conectado a la red en cuesti�n. As� que los datagramas para dichas redes deben enviarse usando el controlador especificado en la cuarta columna. La bandera "U", de la tercera columna, s�lo indica que la ruta especificada por esa l�nea est� activa (generalmente, se asume que estar� abierta, a no ser que se produzcan errores tras varios intentos).\nLas tres primera l�neas muestran "rutas a hosts", indic�ndose con "H" en la tercera columna. Las tablas de enrutamiento, normalmente, tienen entradas para redes o subredes. Por ejemplo, la entrada\nindica que un datagrama para cualquier ordenador de la red 128.6.2 (es decir, direcciones desde 128.6.2.1 hasta 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�fico, en lugar de una red entera. En este caso, se usa una ruta al host. En la primera columna aparece una direcci�n completa, y la bandera "H" est� presente en la columna tres; por ejemplo, la entrada\nindica que un datagrama, dirigido en concreto a la direcci�n 128.6.5.21, debe ser enviado al gateway 128.6.7.1. Al igual que en los enrutamientos a redes, la bandera "G" se usa cuando en el enrutamiento se ve involucrado un gateway, y la bandera "D" indica que el enrutamiento fue a�adido din�micamente, usando un mensaje ICMP de redirecci�n desde un gateway (m�s adelante daremos m�s detalles).\ndonde, 127.0.0.1 es el dispositivo de "lazo cerrado", o loopback. Cualquier datagrama enviado a trav�s de este dispositivo aparece inmediatamente como entrada. Es muy �til para hacer pruebas. Las direcciones de "lazo cerrado" pueden, tambi�n, ser usadas para comunicar aplicaciones que est�n en el propio ordenador. (�Por qu� molestarnos en usar la red para comunicarnos con programas que se encuentran en la misma m�quina?).\nPor �ltimo, hay una ruta por defecto ("default"), como es\nEsta ruta ser� seguida por aquellos datagramas que no se correspondan con ninguna de las anteriores. En nuestro ejemplo, se enviar�n a un gateway de direcci�n 128.6.4.27.\nComo �ltimo 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 informaci�n estad�stica han sido omitidas.\nHay que aclarar que 0.0.0.0 representa al enrutamiento por defecto, es el valor num�rico de default. En este ejemplo, al sistema se le ha asignado la direcci�n IP 172.16.1.3 de forma din�mica, de manera que usa la linea PPP para conectarse con Internet, y 127.0.0.1 es el dispositivo loopback. Antes de la conexi�n PPP solamente estaba activo el dispositivo de "lazo cerrado", pero una vez establecida la conexi�n PPP se activa el interface ppp0 ( 0 indica un identificativo 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 �ltima linea.\nEn muchos sistemas, los datagramas son enrutados consultando la direci�n de destino en una tabla como la que acabamos de describir. Si la direcci�n se corresponde con una ruta espec�fica a un host, �sta ser� usada; en otro caso, si se corresponde con un enrutamiento a red, se usar� �sta; y, si nada de lo anterior acontece, se usar� el enrutamiento por defecto. En caso de no existir uno por defecto, aparecer�a un mensaje de tipo "red inalcanzable" ("network is unreachable").\nEn las siguientes secciones describiremos varias maneras de configurar estas tablas de enrutamiento. Generalmente, la operaci�n de enviar datagramas no depende del m�todo usado en la configuraci�n de estas tablas. Cuando un datagrama va a ser enviado, su destino es consultado en la tabla. Los distintos m�todos de enrutamiento son simplemente, m�s o menos, una serie de sofisticadas formas de configurar y mantener las tablas.\nLa forma m�s f�cil de configurar el enrutamiento es usar comandos que lo fijan. Nuestros archivos de inicializaci�n contienen comandos que configuran el enrutamiento. Si es necesario alg�n cambio, deber� hacerse, normalmente, usando comandos que a�aden y borran entradas de la tabla de enrutamiento (cuando se realice un cambio, no debemos olvidar actualizar el fichero de inicializaci�n tambi�n). Este m�todo es pr�ctico para redes relativamente peque�as, especialmente cuando los cambios no son muy frecuentes.\nMuchos ordenadores configuran autom�ticamente algunas entradas de enrutamiento por nosotros. Unix a�ade una entrada para las redes a las que estamos directamente conectados. Por ejemplo, un fichero de inicializaci�n podr�a ser\nEste especifica que hay dos interfaces de red y sus direcciones en ellas. El sistema crea autom�ticamente estas entradas en la tabla de enrutamiento\ny, en �sta, se especifica que los datagramas para las redes locales 128.6.4 y 128.6.5 deben ser enviados a las corespondientes interfaces.\nAdem�s de �stos, el fichero de inicializaci�n podr�a contener comandos para definir rutas a cualquier otra red a la que queramos acceder. Por ejemplo,\nEstos comandos determinan que para alcanzar la red 128.6.2 debemos usar el gateway de direcci�n 128.6.5.1, y esa red 128.6.6 es, realmente, un n�mero de red adicional para una red f�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 m�trica, que es el n�mero final del comando. La m�trica indica cu�ntos gateways tiene que atravesar un datagrama para alcanzar su destino. Rutas de m�trica 1 � m�s indican que hay en el camino s�lo un gateway hasta el destino. Rutas de m�trica 0 indican que no hay ning�n gateway implicado -es un n�mero de red adicional para la red local-.\nEn �ltimo lugar, podemos definir un enrutamiento por defecto, usado cuando el destino no est� listado expl�citamente. Normalmente, se suele acompa�ar de la direcci�n de un gateway que tiene suficiente informaci�n como para manejar todos los posibles destinos.\nSi nuestra red s�lo dispone de un gateway, entonces s�lo necesitaremos una sola entrada por defecto. En este caso, no deberemos preocuparnos m�s de la configuraci�n del enrutamiento de los hosts (el gateway, en s�, necesitar� m�s atenci�n, como veremos). Las siguientes secciones nos ayudar�n para configurar redes donde hay varios gateways.\nLa mayor�a de los expertos recomiendan dejar las decisiones de enrutamiento a los gateways. Por tanto, probablemente, ser� una mala idea tener largas tablas est�ticas de enrutamiento en cada ordenador. El problema est� en que cuando algo cambia en la red tenemos que actualizar las tablas en demasiados ordenadores. Si el cambio ocurre debido a que cae una l�nea, el servicio no se restablecer� hasta que alguien se de cuenta del problema y cambie todas las tablas de enrutamiento.\nLa manera m�s f�cil de tener actualizado el enrutamiento es depender s�lo de un �nico gateway y actualizar su tabla de enrutamiento. Este gateway debe fijarse como gateway por defecto. (En Unix esto significa usar un comando como "route add default 128.6.4.27 1" , donde 128.6.4.27 es la direcci�n del gateway). Como describimos anteriormente, el sistema enviar� todos aquellos datagramas a dicho gateway cuando no haya una ruta mejor. En principio, parece que esta estrategia no es demasiado buena cuando poseemos m�s de un gateway; m�xime, cuando todo lo que tenemos es s�lo la entrada por defecto. �C�mo usaremos los otros gateways en los casos en los que �stos sean m�s recomendables? La respuesta es que los datagramas correspondientes ser�n redirigidos a estos gateways en estos casos. Un "redireccionamiento" es una clase espec�fica de mensaje ICMP (Internet Control Message Protocol), que contiene informaci�n del tipo "En el futuro, para llegar a la direcci�n XXXXX, intenta usar YYYYY en lugar de m�". Las implementaciones que cumplen completamente los protocolos TCP/IP usan estas t�cnicas de redireccionamiento para a�adir entradas a las tablas de enrutamiento. Supongamos que una tabla inicialmente es como sigue:\n� 127.0.0.1 � 127.0.0.1 � UH � lo0 �\n� 128.6.4 � 128.6.4.61 � U � pe0 �\n� default � 128.6.4.27 � UG � pe0 �\ndonde hay una entrada para la red local 128.6.4, y una entrada por defecto del gateway 128.6.4.27. Supongamos que hay tambi�n un gateway 128.6.4.30, que es el mejor camino para acceder a la red 128.6.7. �C�mo 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 �nico que aparece en la tabla de enrutamiento, y el gateway se dar� cuenta de que el mejor camino debe pasar por 128.6.4.30 (Hay distintos m�todos para que un gateway determine que debe usarse otro para un mejor enrutamiento). Por tanto, 128.6.4.27 contestar� con un mensaje de redireccionamiento especificando que los datagramas para 128.6.7.23 deben enviarse a trav�s del gateway 128.6.4.30. El software TCP/IP a�adir� una entrada a la tabla de enrutamiento\nDe esta manera, los restantes datagramas al 128.6.7.23 se enviar�n directamente al gateway apropiado.\nEsta estrategia ser�a perfecta si no fuera por los siguientes tres problemas:\n* Necesita que cada ordenador contenga la direcci�n de un gateway por defecto en los ficheros de configuraci�n.\n* Si la red usa subredes y la implementaci�n TCP/IP usada no las maneja, esta estrategia no podr� emplearse.\nEl alcance del problema depende del tipo de red de la que disponemos. Para redes peque�as, apenas supondr� un problema cambiar los ficheros de configuraci�n de algunas m�quinas. Sin embargo, para algunas organizaciones este trabajo es dif�cil de llevar a cabo. Si, por ejemplo, la topolog�a de la red cambia y un gateway es eliminado, cualquier sistema que tenga dicho gateway por defecto deber� ser ajustado. Este problema ser� especialmente grave si el personal encargado del mantenimiento de la red es distinto del encargado de mantener a los sistemas individualmewnte. La soluci�n m�s simple consiste en asegurarnos de que la direcci�n por defecto nunca cambiar�. Por ejemplo, podr�amos adoptar el convenio de que la direcci�n 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�a siempre el 128.6.7.1. Si dicho gateway es eliminado, habr� que asignarle dicha direcci�n a alg�n otro gateway (siempre tendr� que haber, al menos, un gateway, puesto que si no es as� estaremos completamente incomunicados).\nHasta ahora hemos visto c�mo a�adir rutas, pero no c�mo deshacernos de ellas. �Qu� ocurre si un gateway no funciona correctamente?. Nuestro deseo ser�a que se recondujera a un gateway operativo, pero desgraciadamente, un gateway en mal funcionamiento no tendr� en general esta capacidad de redireccionamiento. La soluci�n m�s obvia es usar gateways fiables. El redireccionamiento puede usarse para controlar distintos tipos de fallos.\nLa mejor estrategia para controlar gateways averiados es que nuestra implementaci�n TCP/IP detecte las rutas que no tienen �xito. TCP mantiene varios contadores que permiten al software detectar cu�ndo una conexi�n se ha roto. Cuando esto ocurre, se puede marcar esta ruta como fallida y volver al gateway por defecto. Una soluci�n similar puede usarse para manejar fallos en el gateway por defecto. Si configuramos dos gateways por defecto, entonces el software deber� ser capaz de cambiar el gateway cuando las conexiones 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 m�s com�n. Hasta implementaciones de Unix para PC como Linux ya incorporan esta posibilidad (Linux en concreto puede controlar hasta cuatro gateways por defecto).\nEn tanto en cuanto las implementaciones TCP/IP manejan ca�das de las conexiones adecuadamente, estableciendo una o m�s rutas por defecto en el fichero de configuraciones, se produce probablemente la foma m�s simple de controlar el enrutamiento. No obstante, hay otras dos t�cnicas de enrutamiento dignas de consideraci�n para algunos casos especiales:\nLos 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 cu�l ellos informan a simples hosts que tienen que usar otro gateway. Los gateways deben tener una visi�n completa de la red y un m�todo para para calcular la ruta �ptima a cada subred. Generalmente, los gateways mantienen esta visi�n mediante el intercambio de informaci�n entre ellos. Hay varios protocolos distintos de enrutamiento para este prop�sito. Una alternativa para que un ordenador siga la pista a los gateways es escuchar 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 visi�n completa de la red, al igual que los gateways. Este software normalmente est� dise�ado para mantener din�micamente las tablas de enrutamiento del ordenador, as� que los datagramas se enviar�n siempre al gateway m�s adecuado. De hecho, el enrutamiento realizado es equivalente a ejecutar los comandos Unix "route add" y "route delete" a medida que la topolog�a cambia. El resultado suele ser una completa tabla de enrutamiento, en lugar de 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.).\nEjecutando 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, reserv�ndola como �ltima alternativa. El problema m�s serio incorpora numerosas opciones de configuraci�n, que deben mantenerse en cada ordenador. Adem�s, los actuales gateways suelen a�adir opciones cada vez m�s complejas. Por tanto, no es deseable extender el uso de este software en todos los hosts.\nHay otro problema m�s espec�fico referido a los ordenadores sin discos. Como es natural, un ordenador sin discos depende de la red y de los servidores de ficheros 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 trav�s de la red. En un ordenador ocupado, los programas que no son usados durante algunos segundos deben guardarse haciendo swapping o paginaci�n. Cuando se activan de nuevo, han de recuperarse. Cuando una emisi�n de un gateway es enviada en la red, cada ordenador activa su software de red para procesar dicha emisi�n, lo cual significa que todos ellos intentan hacer una recuperaci�n al mismo tiempo y, por tanto, es probable que se produzca una sobrecarga temporal de la red.\nLos proxy ARP son otra t�cnica para permitir a los gateways tomar todas las decisiones de enrutamiento. Son aplicables a aquellas redes que usan ARP (Address Resolution Protocol), o una t�cnica similar para corresponder las direcciones Internet con direcciones de redes espec�ficas, como las direcciones Ethernet. Para facilitar la explicaci�n, vamos a asumir redes Ethernet. Los cambios necesarios para otros tipos de redes consistir�n en poner la correspondiente direcci�n de red, en lugar de "direcci�n Ethernet", y protocolo an�logo a ARP para dicha red.\nEn 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 est�n en nuestra red como para algunas combinaciones de destinos. El caso m�s sencillo de explicar es el de todas las direcciones; para ello ordenamos al ordenador que simule que todos los ordenadores del mundo est�n conectados directamente a nuestra Ethernet local. En Unix, esto se hace usando el comando\ndonde, 128.6.4.2 es la direcci�n IP de nuestro host. Como ya hemos visto, la m�trica 0 provoca que todo aquello que se identifique con esta ruta se enviar� directamente a la red local Ethernet. Alternativamente, otros sistemas nos permiten conseguir el mismo efecto fijando una m�scara de red de ceros, en cuyo caso debemos asegurarnos de que no ser� alterada por un mensaje ICMP de m�scara de subred debido a que un sistema conoce la verdadera m�scara de red.\nCuando un datagrama va a ser enviado a un destino dentro de la Ethernet local, el ordenador necesita conocer la direcci�n Ethernet del destino, y para ello, generalmente, se usa la llamada tabla ARP, que contiene las correspondencias entre las direcciones Internet y las direcciones Ethernet. Veamos un ejemplo t�pico de tabla ARP (en la mayor�a de los sistemas se visualiza usando el comando "arp -a". ):\nComo dijimos anteriormente, simplemente es una lista de direcciones IP y su correspondiente direcci�n Ethernet. El t�rmino "temporary" indica que la entrada fue a�adida din�micamente usando ARP, en lugar de ser puesta manualmente.\nSi hay una entrada para una direcci�n determinada en la tabla ARP, los datagramas ser�n puestos en la Ethernet con su correspondiente direcci�n Ethernet. Si esto no ocurre, se enviar� una "petici�n ARP", solicitando que el host destino se identifique. La petici�n es, en efecto, una pregunta: "�Puede decirme el host con direcci�n Internet 128.6.4.194 cu�l es su direcci�n Ethernet?". Cuando llega una respuesta, esta se a�ade a la tabla ARP y los futuros datagramas con ese destino ser�n enviados directamente.\nEste mecanismo fue dise�ado inicialmente s�lo para hosts que estuvieran directamente conectados a una 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 interface en nuestra Ethernet. El host deber� averiguar la direcci�n de dicho gateway usando ARP. Este procedimiento es m�s �til que hacer que el ARP trabaje directamente con un ordenador en una red lejana, puesto que no est�n en la misma Ethernet, no disponemos de una direcci�n Ethernet para poder enviar los datagramas y, al enviar "peticiones ARP" por ellas, nadie nos responder�.\nLos proxy ARP se basan en la idea de que los conceptos act�en como proxyes de hosts lejanos. Supongamos 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)\nAhora supongamos que el ordenador A env�a una petici�n ARP al ordenador C, pero C no es capaz de responder por s� mismo. Al estar en redes distintas, C nunca ver� la petici�n ARP; sin embargo, el gateway actuar� en su lugar. En efecto, nuestro ordenador pregunta: "�Puede decirme el host con direcci�n de Internet 128.6.4.194 cu�l es su direcci�n Ethernet?", y el gateway contesta: "Yo soy 128.6.4.194 es 2:7:1:0:eb:cd", donde 2:7:1:0:eb:cd es la direcci�n Ethernet del gateway. Este peque�o truco funciona correctamente y hace pensar a nuestro host que 128.6.4.194 est� conectado a la Ethernet local con direcci�n 2:7:1:0:eb:cd, pero, por supuesto, no es cierto. Cada vez que enviamos un datagrama a 128.6.4.194, nuestro host lo env�a a la direcci�n Ethernet especificada y, puesto que es la direcci�n del gateway R, llega hasta dicho gateway. Y es entonces cuando se env�a a su destino.\nCon la excepci�n de que, en lugar de tener el enrutamiento hecho a nivel de tabla de enrutamiento, se hace a nivel de tabla ARP.\nLa t�cnica fue dise�ada originariamente para trabajar con hosts que no soportan subredes. Supongamos que tenemos una red dividida en subredes. Por ejemplo, hemos decidido dividir la red 128.6 en subredes, obteniendo las subredes 128.6.4 y 128.6.5. Supongamos tambi�n que tenemos un host que no trabaja con subredes y, por tanto, creer� que 128.6 es tan s�lo una red. Esto �ltimo significa que ser� dif�cil establecer las entradas para la tabla de enrutamiento para la configuraci�n vista. No podemos decirle nada sobre la 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, interpretar� este comando como un intento de configurar una ruta a un host de direcci�n 128.6.4.0. La �nica manera que podr�a hacerlo funcionar ser�a establecer rutas expl�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 fijamos el gateway 128.6.5.1 por defecto; esto no podr�a funcionar para enviar datagramas a otras subredes. En el caso de que el host 128.6.5.2 quiera enviar un datagrama al 128.6.4.194, puesto que el destino es parte de 128.6, el ordenador lo considerar� en la misma red y no se preocupar� por buscarle un gateway adecuado.\nLos 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 petici�n ARP para comunicarse con ellas, esperando recibir una direcci�n Ethernet que pueda usarse para establecer comunicaciones directas. Si el gateway ejecuta un proxy ARP, responder� con la direcci�n Ethernet del gateway. Por tanto, los datagramas ser�n enviados al gateway y todo funcionar� correctamente.\nComo se puede observar, no se necesita una configuraci�n espec�fica 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 especificar la configuraci�n de la tabla de enrutamiento. Por defecto, las implementaciones TCP/IP esperar�n encontrar un gateway para cualquier destino que est� en otra red y, para hacerlo, deberemos expl�citamente instalar una ruta de m�trica 0, como por ejemplo "route add default 128.6.5.2 0", o poner la m�scara de subred a ceros.\nEs 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 redirecci�n ICMP correctamente, y, por tanto, normalmente lo que se har� es configurar la ruta por defecto a alg�n gateway. Sin embargo, en caso de contar con una implementaci�n que no reconoce los redireccionamientos, o no puede configurarse un gateway por defecto, podemos usar proxy ARP.\nA veces se usa proxy ARP por conveniencia. El problema de las tablas de enrutamiento es que hay que configurarlas. La configuraci�n m�s simple es fijar una ruta por defecto; pero, incluso en este caso, hay que incluir un comando equivalente al de Unix "route add default...". En el caso de que hubiese cambios en las direcciones de los gateways, deber�amos modificar este comando en todos los hosts. Si configuramos una ruta por defecto que depende de proxy ARP (con m�trica 0), no deberemos cambiar los ficheros de configuraci�n cuando los gateways cambian. Con los proxy ARP, no hace falta poner ninguna direcci�n de un gateway. Cualquier gateway puede responder a una petici�n ARP, no importa cu�l sea su direcci�n.\nPara evitarnos tener que configurar los sistemas, algunas implementaciones TCP/IP usan ARP por defecto, cuando no tienen otra ruta. Las implementaciones m�s flexibles nos permiten usar estrategias mixtas. As�, si tenemos que especificar una ruta para cada red en particular, o una ruta por defecto, se usar� esa ruta, pero si no hay rutas para un destino lo tratar� como si fuese local y usar� una petici�n ARP. En tanto en cuanto sus gateways soporten proxy ARP, esto permitir� que los hosts alcancen cualquier destino sin necesitar ninguna tabla de enrutamiento.\nFinalmente, podr�amos elegir usar una proxy ARP porque se recuperan mejor de los fallos. La elecci�n depender� en gran medida de la implementaci�n.\nEn aquellas situaciones en las que hay varios gateways en una red, veamos c�mo los proxy ARP permiten elegir el mejor. Como hemos mencionado anteriormente, nuestro computador simplemente env�a un mensaje preguntando por la direcci�n Ethernet del destino. Suponemos que los gateways est�n configurados para responder a estos mensajes. Si hay m�s de un gateway, ser� necesaria una coordinaci�n entre ellos. Conceptualmente, los gateways tendr�n una visi�n completa de la topolog�a de la red. Por consiguiente, ser�n capaces de determinar la mejor ruta desde nuestro host a cualquier destino. Si hay una coordinaci�n entre los gateways, ser� posible que el mejor gateway pueda responder a la petici�n ARP. En la pr�ctica no es siempre posible, por ello se dise�an algoritmos para evitar rutas malas. Veamos por ejemplo la siguiente situaci�n:\n������������ A ������������ B �����������\ndonde, 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 comunicarse con otro de la red 1 es bastante f�cil para el gateway A decidirse a contestar, y el gateway B no lo har�. Veamos c�mo: si el gateway B acepta un datagrama para la red 1, tendr� que remitirlo al gateway A para que lo entregue. Esto significar�a que deber�a tomar un datagrama de la red 2 y enviarlo de vuelta a la red 2. Es muy f�cil manejar las rutas que se dan en este tipo de redes. Es mucho m�s dif�cil de controlar en una situaci�n como la siguiente:\n3 � C\nSupongamos que un ordenador en la red 1 quiere enviar un datagrama a otro de la red 2. La ruta v�a A y D es probablemente la mejor, porque s�lo hay una red (3) entre ambas. Tambi�n es posible la ruta v�a B, C y E, pero este camino probablemente es algo m�s lento. Ahora supongamos que el ordenador de la red 1 env�a peticiones ARP para alcanzar 2. Seguramente A y B responder�n a dicha petici�n. B no es tan buena como A, pero no hay tanta diferencia como en el caso anterior. B no devolver� el datagrama a 1. Adem�s, no es posible determinar qu� camino es mejor sin realizar un costoso an�lisis global de la red. En la pr�ctica no disponemos de tanta cantidad de tiempo para responder a una petici�n ARP.\nEn principio, IP es capaz de controlar l�neas con fallos y ca�das de gateways. Hay varios mecanismos para rectificar 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 documentaci�n de nuestra implementaci�n y, teniendo en cuenta los fallos m�s frecuentes, deberemos definir 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 m�todos tienen sus propias limitaciones dependiendo del tipo de red.\nEspiar el protocolo de enrutamiento de los gateways es, en teor�a, la soluci�n m�s directa y simple. Si suponemos que los gateways usan una buena tecnolog�a de enrutamiento, las tablas que ellos env�an deber�an contener la informaci�n necesaria para mantener unas rutas �ptimas para todos los destinos. Si algo cambia en la red (una l�nea o un gateway falla), esta informaci�n deber� reflejarse en las tablas y el software de enrutamiento deber� ser capaz de actualizar adecuadamente las tablas de enrutamiento de los hosts. Las desventajas de esta estrategia son meramente pr�cticas, pero, en algunas situaciones, la robustez de este enfoque puede pesar m�s que dichas desventajas. Veamos cu�les son estas desventajas:\n* Si los gateways usan un protocolo de enrutamiento sofisticado, la configuraci�n puede ser bastante compleja, lo que se convierte en un problema ya que debemos configurar y mantener los ficheros de configuraci�n de cada host.\n* Algunos gateways usan protocolos espec�ficos de alguna marca comercial. En este caso, es posible que no encontremos un software adecuado para nuestros hosts.\nAlgunos gateways son capaces de traducir su protocolo interno de enrutamiento en otro m�s simple que puede ser usado por los hosts. Esta podr�a ser una forma de resolver las dos primeras desventajas. Actualmente no hay una soluci�n definitiva para la tercera.\nLos problemas de los m�todos de rutas por defecto/redireccionamiento y de los proxy ARP son similares: ambos tienen problemas para trabajar con situaciones donde las entradas a las tablas no se usan durante un largo periodo de tiempo. La �nica diferencia real entre ellos son las tablas que se ven involucradas. Supongamos que un gateway cae, si alguna de las actuales rutas usan ese gateway no podr� ser usada. En el caso de que estemos usando tablas de enrutamiento, el mecanismo para ajustar las rutas es el redireccionamiento. Esto funciona perfectamente en dos situaciones:\n- cuando el gateway por defecto no est� en la mejor ruta. El gateway por defecto puede dirigirlo a un gateway mejor;\n- 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.\nEl caso que no est� a salvo de problemas es cuando el gateway a que se le env�a datagramas falla en ese momento. Puesto que est� fuera de servicio, es imposible que redireccione a otro gateway. En muchos casos, tampoco estamos a salvo si el gateway por defecto falla, justo cuando el enrutamiento empieza a enviar al gateway por defecto.\nLa 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� usando nos reconducir� a un nuevo y mejor gateway. (Normalmente es posible usar redireccionamiento para 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 cualquier gateway puede responder a una petici�n ARP.\nAs� 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 funcionamiento no puede redirigir. Te�ricamente, este problema podr�a solucionarse a trav�s de la implementaci�n TCP/IP, usando "timeout". Si un ordenador no recibe respuesta una vez terminado el timeout, deber�a de cancelar la ruta actual y tratar de encontrar otra nueva. Cuando usamos una ruta por defecto, esto significa que la implementaci�n TCP/IP puede ser capaz de declarar 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 tr�fico se devolver� al gateway por defecto. El gateway por defecto puede entonces empezar a manejar el tr�fico, o redirigirlo a un gateway diferente. Para manejar los fallos del gateway por defecto es posible tener m�s de un gateway por defecto; si uno de ellos se declara fallido, se usar� el otro. En conjunto, estos mecanismos nos salvaguardan de cualquier fallo.\nM�todos similares pueden usarse en sistemas que dependen de proxy ARP. Si una conexi�n sobrepasa el timeout, la entrada de la tabla ARP usada se debe borrar. Esto causar� una petici�n ARP, que podr� ser contestada por un gateway que funcione correctamente. El mecanismo m�s simple para llevar esto a cabo podr�a ser usar los contadores de timeout 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 perfectamente. As�, su pr�ximo datagrama ser� una nueva petici�n. Las respuestas, normalmente, son suficientemente r�pidas para que el usuario no se de cuenta del retraso introducido.\nSin embargo, algunas implementaciones no usan estas estrategias. En Berkeley 4.2 no hay manera de librarse de ning�n tipo de entrada, ni de la tabla de enrutamiento ni de la tabla ARP. Estas implementaciones no invalidan las entradas, �stas fallan. Luego si los problemas de fallos de gateways son m�s o menos comunes, no habr� otra opci�n que 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 m�s atractiva que la de proxys ARP, si usamos Berkeley 4.3. Si, adem�s, inclu�mos m�s de una ruta por defecto se posibilitar� la recuperaci�n de fallos cuando falle un gateway por defecto. Si una ruta est� siendo usada s�lo por servicios basados en el protocolo UDP, no habr� una recuperaci�n de fallos 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 versi�n 4.3 no nos garantiza una recuperaci�n de fallos absoluta.\nPor �ltimo, tambi�n podemos hablar de otras estrategias usadas por algunas antiguas implementaciones. Aunque est�n casi en desuso, vamos a describirlas de forma esquem�tica. Estas implementaciones detectan un fallo de un gateway haciendo comprobaciones de qu� gateways est�n en uso. Para ello, la mejor forma de hacer estas comprobaciones es hacer una lista de gateways que actualmente se est�n usando (para lo que se ayuda de la tabla de enrutamiento) y cada minuto se env�a una petici�n de "echo" a cada gateway de la citada lista; si el gateway no env�a una respuesta se declara como fallido, y todas las rutas que hacen uso de �l se reconducir�n al gateway por defecto. Generalmente, se deber� de proporcionar m�s de un gateway por defecto, de manera que 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� un gateway que responda. Estas implementaciones son muy flexibles y se recuperan bien de los fallos, pero una gran red con esta implementaci�n malgastar� el ancho de banda con datagramas "echo" para verificar qu� gateways funcionan correctamente. Esta es la raz�n por la que esta estrategia est� en desuso.\nEn esta secci�n vamos a tratar con m�s detalle la tecnolog�a usada para construir grandes redes. Vamos a centrarnos especialmente en c�mo conectar varias Ethernet, token rings, etc. Hoy d�a la mayor�a de las redes son jer�rquicas. Los hosts est�n inclu�dos en una red de �rea local, como una Ethernet o un token ring. Estas redes se conectan entre s� mediante alguna combinaci�n de redes principales o enlaces punto a punto. Una universidad puede tener una red como se muestra, en parte, a continuaci�n:\nLas redes 1, 2 y 3 est�n en un edificio. Las redes 4 y 5 est�n en edificios distintos del campus. La red 6 puede estar en una localizaci�n m�s distante. El diagrama anterior nos muestra que las redes 1, 2 y 3 est�n conectadas directamente, y los mecanismos que manejan las conexiones se marcan con "x". El edificio A est� conectado a otros edificios en el mismo campus por una red principal. El tr�fico desde la red 1 a la red 5 tomar� el siguiente camino:\n- de 1 a 2 a trav�s de la conexi�n entre estas redes;\n- de 2 a 3 a trav�s de su conexi�n directa;\n- a trav�s de la red principal, desde el edificio A al edificio donde la red 5 est� emplazada;\nEl tr�fico hacia la red 6 deber�a pasar adicionalmente a trav�s de la l�nea serie. Con la misma configuraci�n, se usar�a la misma conexi�n para conectar la red 5 con la red principal y con la l�nea serie. As�, el tr�fico de la red 5 a la red 6 no necesita pasar a trav�s de la red principal, al existir esa conexi�n directa entre la red 5 y la l�nea serie.\nEn esta secci�n vamos a ver qu� son realmente estas conexiones marcadas con "x".\nHay que hacer constar que hay distintos dise�os alternativos al mostrado anteriormente. Uno de ellos es usar l�neas punto a punto entre los hosts, y otro puede ser usar una tecnolog�a de red a un nivel capaz de manejar tanto redes locales como redes de larga distancia.\nEn lugar de conectar los hosts a una red local como una Ethernet, y luego conectar dichas Ethernets, es posible conectar directamente los ordenadores a trav�s de l�neas serie de largo alcance. Si nuestra red consiste primordialmente en un conjunto de ordenadores situados en localizaciones distintas, esta opci�n tiene sentido. Veamos un peque�o dise�o de este tipo:\nordenador 4���������ordenador 5���������ordenador 6\nEn el primer dise�o, la tarea de enrutamiento de los datagramas a trav�s de red era realizada por unos mecanismos de prop�sito espec�fico que marc�bamos con "x". Si hay l�neas que conectan directamente un par de hosts, los propios hosts har�n esta labor de enrutamiento, al mismo tiempo que realizan sus actividades normales. A no ser que haya l�neas que comuniquen directamente todos los hosts, algunos sistemas tendr�n que manejar un tr�fico destinado a otros. Por ejemplo, en nuestro dise�o, el tr�fico de 1 a 3 deber� pasar a trav�s de 4, 5 y 6. Esto es perfectamente posible, ya que la inmensa mayor�a de las implementaciones TCP/IP son capaces de reenviar datagramas. En redes de este tipo podemos pensar que los propios hosts act�an como gateways. Y, por tanto, deber�amos configurar el software de enrutamiento de los hosts como si se tratase de un gateway. Este tipo de configuraciones no es tan com�n como podr�a pensarse en un principio debido, principalmente, a estas dos razones:\n* la mayor�a de las grandes redes tienen m�s de un ordenador por localizaci�n. En estos casos es menos caro establecer una red local en cada localizaci�n que establecer l�neas punto a punto entre todos los ordenadores;\n* las unidades de prop�sito especial para conectar redes son m�s baratas, lo que hace que sea m�s l�gico descargar las tareas de enrutamiento y comunicaciones a estas unidades.\nPor supuesto, es factible tener una red que mezcle los dos tipos de tecnolog�as. As�, las localizaciones con m�s equipos podr�a manejarse usando un esquema jer�rquico, con redes de �rea local conectadas por este tipo de unidades, mientras que las localizaciones lejanas con un s�lo ordenador podr�an conectarse mediante l�neas punto a punto. En este caso, el software de enrutamiento usado en los ordenadores lejanos deber� ser compatible con el usado por las unidades conmutadoras, o bien tendr� que haber un gateway entre las dos partes de la red.\nLas decisiones de este tipo generalmente se toman tras estudiar el nivel de tr�fico de la red, la complejidad de la red, la calidad del software de enrutamiento de los hosts y la habilidad de los hosts para hacer un trabajo extra con el tr�fico de la red.\nOtro enfoque alternativo al esquema jer�rquico LAN/red principal es usar circu�tos conmutadores en cada ordenador. Realmente, estamos hablando de una variante de la t�cnica de las l�neas punto a punto, donde ahora el circu�to conmutador permite tener a cada sistema aparentar que tiene l�nea directa con los restantes. Esta tecnolog�a no es usada por la mayor�a de la comunidad TCP/IP debido a que los protocolos TCP/IP suponen que el nivel m�s bajo trabaja con datagramas aislados. Cuando se requiere una conexi�n continuada, el nivel superior de red la implementa usando datagramas. Esta tecnolog�a orientada al datagrama no coincide con este sistema orientado a los circu�tos de forma directa. Para poder usar esta tecnolog�a de circu�tos conmutadores, el software IP debe modificarse para ser posible construir circu�tos virtuales de forma adecuada. Cuando hay un datagrama para un destino concreto se debe abrir un circu�to virtual, que se cerrar� cuando no haya tr�fico para dicho destino por un tiempo. Un ejemplo de este enfoque es la DDN (Defense Data Network). El protocolo principal de esta red es el X.25. Esta red parece desde fuera una red distribu�da X.25. El software TCP/IP trata de manejar la DDN mediante el uso de canales virtuales. T�cnicas similares podr�an usarse con otras tecnolog�as de circu�tos de conmutaci�n, como, por ejemplo, ATT's DataKit, aunque no hay demasiado software disponible para llevarlo a cabo.\nEn algunos casos, los adelantos en el campo de las redes de larga distancia pueden sustituir el uso de redes jer�rquicas. Muchas de las redes jer�rquicas fueron configuradas as� para permitir el uso de tecnolog�as tipo Ethernet y otras LAN, las cu�les no pueden extenderse para cubrir m�s de un campus. As� que era mecesario el uso de l�neas serie para conectar las distintas LANs de varios lugares. Sin embargo, ahora hay tecnolog�as de caracter�sticas similares a Ethernet, pero que pueden abarcar m�s de un campus y, por tanto, pensar en una sola red de larga distancia que no hace uso de una estructura jer�rquica.\nLas principales limitaciones de este tipo de redes son cuestiones de rendimiento y flexibilidad. Si una sola red es usada por todo el campus es muy f�cil que se sobrecargue. Las redes jer�rquicas pueden manejar un volumen de trabajo mucho mayor que las redes de un solo nivel. Adem�s, el tr�fico dentro de los departamentos tiende a ser mayor que el tr�fico entre departamentos.\nVeamos un ejemplo concreto. Sumpongamos que hay diez departamentos, cada uno de los cuales genera 1 Mbit/seg de tr�fico. Supongamos que el 90% del tr�fico se realiza entre sistemas del mismo departamento y el 10% restante hacia los dem�s departamentos. Si cada departamento tiene su prop�a red, �stas deber�an ser capaces de manejar 1 Mbit/seg, al igual que la red principal que las maneja, para poder posibilitar el 10% que cada departamento destina a otros departamentos. Para resolver la misma situaci�n con una red de un solo nivel, puesto que debe manejar simult�neamente los diez departamentos, se resuelve con una red que soporte 10 Mbit/seg.\nEst� claro que el ejemplo anterior est� pensado para que el sistema jer�rquico sea ventajoso o, al menos, que sea m�s f�cil de llevar a cabo. Si el tr�fico destinado a los otros departamentos fuese mayor, el ancho de banda de la red principal deber� ser mayor. Por ejemplo, si en un campus hay algunos recursos centralizados, como mainframes u otros grandes sistemas en un centro de c�lculo. Si la mayor�a del tr�fico procede de peque�os sistemas que intentan comunicarse con el sistema central, entonces el argumento anterior no es v�lido. Aunque un enfoque jer�rquico puede que todav�a sea �til, sin embargo no reduce el ancho de banda requerido. Siguiendo con el ejemplo dado, si los diez departamentos se comunicasen primordialmente con los sistemas del ordenador central, la red principal deber� ser capaz de manejar 10 Mbit/seg. El ordenador central deber�a de conectarse directamente a la red principal, o tener una red "departamental" con una capacidad de 10 Mbist/seg, en lugar de los 1 Mbit/seg de los otros departamentos.\nLa segunda limitaci�n se refieren a consideraciones respecto a la fiabilidad, mantenibilidad y seguridad. Las redes de �rea amplia son m�s dif�ciles de diagnosticar y mantener que las redes de �rea local, porque los problemas pueden localizarse en el edificio donde la red se ubica. Adem�s, hacen que el tr�fico sea m�s f�cil de controlar. Por estas razones es m�s l�gico manejar un tr�fico local dentro del edificio y usar las redes de �rea amplia s�lo para el tr�fico entre edificios. No obstante, si se da el caso de que en cada localizaci�n hay s�lo uno o dos ordenadores, no tiene sentido montar una red local en cada lugar y s� usar una redde un solo nivel.\nEn la pr�ctica, pocas redes se permiten el lujo de adoptar un dise�o te�ricamente puro.\nEs poco probable que una red grande sea capaz de evitar el uso de un dise�o jer�rquico. Supongamos que la configuramos como una red de un solo nivel. Incluso si la mayor�a de los edificios tienen s�lo uno o dos ordenadores, habr� alguna localizaci�n donde haya bastantes ordenadores para justificar el uso de una red local. El resultado es una mezcla entre una red de un solo nivel y una red jer�rquica. En la mayor�a de los edificios sus ordenadores est�n conectados directamente a una red de �rea amplia, como una red de un solo nivel, pero en un edificio hay una red de �rea local usando su red de �rea amplia como red principal, a la cu�l se conecta a trav�s de unidades conmutadoras.\nPor otro lado, incluso los dise�adores de redes que defienden el uso de una enfoque jer�rquico, en muchas ocasiones encuentran partes de redes donde simplemente no resulta econ�mico instalar una red de �rea local, as� que algunos hosts se enganchan directamente a la red principal, o bien se usa una l�nea serie.\nAdem�s de las razones econ�micas de la instalaci�n en s�, hay que tener en cuenta que a la larga hay que valorar aspectos de mantenimiento, de manera que a veces es mejor hacer un desembolso econ�mico en el dise�o para ahorrarnos dinero en el mantenimiento futuro. Por tanto, el dise�o m�s consistente ser� aqu�l que podamos ser capaces de mantener m�s f�cilmente.\nEn esta secci�n discutiremos las caracter�sticas de varias tecnolog�as usadas para intercambiar datagramas entre redes. En efecto, trataremos de dar m�s detalles sobre esas "cajas negras" que hemos visto en las anteriores secciones. Hay tres tipos b�sicos de conmutadores, como repetidores, bridges (o puertas) y gateways (o pasarelas), o, alternativamente, switches de nivel 1, 2 y 3 (bas�ndonos en el nivel del modelo OSI en el que operan). Tambi�n hay que aclarar que hay sistemas que combinan caracter�sticas de m�s de uno de estos dispositivos, especialmente bridges y gateways.\nLas diferencias m�s importantes entre estos tipos de dispositivos residen en el grado de aislamiento a fallos, prestaciones, enrutamiento y las facilidades que ofrecen para la administraci�n de la red. M�s adelante examinaremos esto con m�s detalle.\nLa diferencia mayor se encuentra entre los repetidores y los otros dos tipos de switches. Hasta hace relativamente poco tiempo, los gateways proporcionaban unos servicios muy distintos a los ofrecidos por los bridges, pero ahora hay una tendencia a unificar estas dos tecnolog�as. Los gateways est�n empezando a adoptar un hardware de prop�sito espec�fico que antes era caracter�stico de los bridges. Los bridges est�n empezando a adoptar un enrutamiento m�s sofisticado, caracter�sticas de aislamiento y de administraci�n de redes que antes s�lo se pod�an encontrar en los gateways. Incluso hay sistemas que pueden funcionar como bridge y gateway. Esto significa que la decisi�n crucial no es decidir si tenemos que usar un bridge o un gateway, sino qu� caracter�sticas necesitamos en un switch y c�mo �ste afecta el dise�o global de la red.\nUn repetidor es un equipo que conecta dos redes que usan la misma tecnolog�a. Recibe los paquetes de datos de cada red y los retransmite a la otra red. La red resultante se caracteriza por tener la uni�n de los paquetes de ambas redes. Para las redes Ethernet, o que cumplen el protocolo IEEE 802.3, hay dos tipos de repetidores (otras tecnolog�as de red no hacen estas distinciones).\nUn repetidor trabaja a muy bajo nivel. Su objetivo principal es subsanar las limitaciones de la longitud del cable que provocan p�rdidas de se�al, dispersi�n temporal, etc. Nos permiten construir redes m�s grandes y liberarnos de las limitaciones de la longitud del cable. Podr�amos pensar que un repetidor se comporta como un amplificador a ambos lados de la red, pasando toda la informaci�n contenida en la se�al (incluso las colisiones) sin hacer ning�n procesamiento a nivel de paquetes. No obstante, hay un n�mero m�ximo de repetidores que pueden introducirse en una red. Las especificaciones b�sicas de Ethernet requieren que las se�ales lleguen a su destino dentro de un l�mite de tiempo, lo que determina que haya una longitud m�xima de la red. Poniendo varios repetidores en el camino se introducen dificultades para estar dentro del l�mite (de hecho, cada repetidor introduce un retraso, as� que de alguna manera se introducen nuevas dificultades).\nUn "repetidor con buffer" trabaja a nivel de paquetes de datos. En lugar de pasar la informaci�n contenida en la se�al, almacena paquetes enteros de una red en un buffer interno y, luego, lo retranstime a la otra red, por lo que no deja pasar las colisiones. Debido a que los fen�menos de bajo nivel, como las colisiones, no son repetidos, se puede considerar como si las dos redes continuasen separadas en lo que se refiere a las especificaciones Ethernet. Por tanto, no hay restricciones respecto al n�mero de repetidores con buffer que se pueden usar. De hecho, no es necesario que ambas redes sean del mismo tipo, pero han de ser suficientemente similares, de manera que tengan el mismo formato de paquete. Generalmente, esto significa que se emplean repetidores con buffer entre redes de la familia IEEE 802.x (asumiendo que elegimos la misma longitud para las direcciones y el mismo tama�o m�ximo para los paquetes), o entre dos redes de otra familia. Adem�s, un par de repetidores con buffer pueden usarse para conectar dos redes mediante una l�nea serie.\nLos repetidores con buffer y los repetidores b�sicos tienen una caracter�stica en com�n: repiten cada paquete de datos que reciben de una red en la otra. Y as� ambas redes, al final, tienen exactamente el mismo conjunto de paquetes de datos.\nUn bridge se diferencia principalmente de un repetidor en que realiza alg�n tipo de selecci�n de qu� datagramas se pasan a las otras redes. Persiguen alcanzar el objetivo de aumentar la capacidad de los sistemas, al mantener el tr�fico local confinado a la red donde se originan. Solamente el tr�fico destinado a otras redes ser� reenviado a trav�s del bridge. Esta descripci�n tambi�n podr�a aplicarse a los gateways. Bridges y gateways se distinguen por la manera de determinar qu� datagramas deben reenviarse. Un bridge usa s�lo las direcciones del nivel 2 de OSI; en el caso de las redes Ethernet, o IEEE 802.x, nos referimos a las direcciones de 6 bytes de Ethernet o direcciones del nivel-MAC (el t�rmino "direcciones del nivel MAC" es m�s general. Sin embargo, con la intenci�n de aclarar ideas, los ejemplos de esta secci�n se referir�n a redes Ethernet y as� s�lo deberemos reemplazar el t�rmino "direcci�n Ethernet" por el equivalente de direcci�n de nivel MAC en cualquier otra tecnolog�a). Un bridge no examina el datagrama en s�, as� que no usa las direcciones IP, o su equivalente para tomar las decisiones de enrutamiento. Como contraste, un gateway basa sus decisiones en las direcciones IP, o su equivalente en otros protocolos.\nHay varias razones por las que importa el tipo de direcci�n usada para tomar una decisi�n. La primera de ellas afecta a c�mo interact�an dichos dispositivos conmutadores con los niveles superiores del protocolo. Si el reenv�o se hace a nivel de las direcciones de nivel-MAC (bridge), dicho dispositivo ser� invisible a los protocolos. Si se hace a nivel IP, ser� visible. Veamos un ejemplo en el que hay dos redes conectadas por un bridge:\nHay que decir que un bridge no tiene una direcci�n IP. En lo que se refiere a los ordenadores A, B y C, hay una sola Ethernet a la que est�n conectados. Esto se traduce en que las tablas de enrutamiento deben configurarse de manera que los ordenadores de ambas redes se traten como si fuesen locales. Cuando el ordenador A abre una conexi�n con el ordenador B, primero se env�a una petici�n ARP preguntando por la direcci�n Ethernet del ordenador B. El bridge debe dejar pasar esta petici�n de la red 1 a la red 2. (En general, los bridges deben atender todas las peticiones). Una vez que ambos ordenadores conocen las direcciones Ethernet del otro, las comunicaciones usar�n las direcciones Ethernet en el destino. Llegados a este punto, el bridge puede empezar a ejecutar alguna selecci�n, y dejar� pasar aquellos datagramas cuya direcci�n Ethernet de destino se encuentren en una m�quina de la otra red. De esta manera un datagrama desde A hasta B pasar� de la red 2 a la red 1, pero un datagrama desde B hasta C se ignorar�.\nCon objeto de hacer esta selecci�n, el bridge necesita saber en qu� red est� cada m�quina. La mayor�a de los bridges modernos construyen una tabla para cada red a la que se conecta, listando las direcciones Ethernet de las m�quinas de las que se sabe en qu� red se encuentran, y para ello vigilan todos los datagramas de cada red. Cuando un datagrama aparece primero en la red 1 es razonable pensar que la direcci�n del remitente corresponde a una m�quina de la red 1.\nUn bridge debe examinar cada datagrama por dos razones: la primera, para usar la direcci�n de procedencia y aprender qu� m�quinas est�n en cada red, y, la segunda, para decidir si el datagrama ha de ser reenviado o no en base a la direcci�n de destino.\nComo mencionamos anteriormente, por regla general los bridges dejan pasar las peticiones de una red a la otra. En varias ocasiones hay peticiones para localizar alg�n recurso. Una petici�n ARP es un t�pico ejemplo de lo anterior. Debido a que un bridge no tiene manera de saber si un host va a responder a dicha petici�n, deber� dejarla pasar a la otra red. Algunos bridges tienen filtros definidos por el usuario, que les posibilita dejar pasar algunos y bloquear a otros. Podemos permitir peticiones ARP (que son esenciales para que el protocolo IP funcione) y restringir otras peticiones menos importantes a su propia red de origen. Por ejemplo, podemos elegir no dejar pasar las peticiones rwhod, que usan algunos sistemas para conocer los usuarios conectados en cada sistema, o podemos decidir que s�lo pueda tener acceso a una parte de la red.\nLos gateways tienen asignada una direcci�n IP por cada interface. Las tablas de enrutamiento de los ordenadores deber�n configurarse para hacer los env�os a las direcciones adecuadas. As�, por ejemplo, el ordenador A tienen una entrada estableciendo que debe usarse el gateway 128.6.5.1 para alcanzar la red 128.6.4.\nDebido a que los ordenadores tienen conocimiento de la existencia del gateway, el gateway no necesita inspeccionar todos los paquetes de la Ethernet. Los ordenadores le enviar�n datagramas cuando sea apropiado. Por ejemplo, supongamos que el ordenador A necesita enviar un mensaje al ordenador B. En la tabla de enrutamiento de A se indica que deberemos usar el gateway 128.6.5.1, y entonces se le enviar� una petici�n ARP para esa direcci�n, respondi�ndonos el gateway a la petici�n como si se tratase de un host cualquiera. A partir de entonces, los datagramas destinados a B ser�n enviados con la direcci�n Ethernet del gateway.\nHay varias ventajas para usar direcciones del nivel MAC, como lo hace un bridge. La primera es que cada paquete en una Ethernet, o en una red IEEE, usa dichas direcciones, y la direcci�n se localiza en el mismo lugar en cada paquete, incluso si es IP, DECnet, o de cualquier otro protocolo. De tal manera que es relativamente r�pido obtener la direcci�n de cada paquete. Por otro lado, un gateway debe decodificar toda la cabecera IP y, si soporta otros protocolos distintos a IP, debe tener un software distinto para cada protocolo. Esto significa que un bridge soporta autom�ticamente cualquier protocolo posible, mientras que un gateway debe preveer qu� protocolo debe soportar.\nSin embargo, tambi�n hay desventajas. La principal se refiere al dise�o de un puente\n* Un puente debe mirar cada paquete de la red, no solo aqu�llos a los que se le destinan. Esto hace posible que haya sobrecargas en el bridge si se coloca en una red muy concurrida, incluso si el tr�fico que atraviesa el bridge es peque�o.\nNo obstante, existe otra desventaja basada en la manera como los bridges est�n dise�ados. Ser�a posible, en principio, dise�ar bridges sin estas desventajas, pero no hay indicios de que se cambie. La desventaja se debe al hecho de que los bridges no tienen una tabla de enrutamiento completa con todos los sistemas de las redes, ya que s�lo tienen una simple lista con las direcciones Ethernet que se encuentran en sus redes. Lo que significa que\n* Las redes que usan bridges no pueden tener bucles en su dise�o. Si hubiera un bucle, algunos bridges ver�an el tr�fico procedente de una misma direcci�n Ethernet venir de ambas direcciones, por lo que le ser�a imposible decidir en qu� tabla debe poner dicha direcci�n. Hay que aclarar que un camino paralelo en la misma direcci�n constituye un bucle y, por tanto, no se podr�n usar m�ltiples caminos con el fin de descargar el tr�fico de la red.\nHay algunos m�todos para afrontar el problema de los bucles. Muchos puentes 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. Tambi�n es posible construir un bridge capaz de manejar l�neas punto a punto paralelas, en un caso especial donde dichas l�neas tienen en sus extremos un bridge. Los bridges tratar�an las dos l�neas como una �nica l�nea virtual y usarlas alternativamente, siguiendo alg�n algoritmo aleatorio.\nEl proceso de desactivar conexiones redundantes hasta que no queden bucles es conocido como un "algoritmo de expansi�n de �rboles". Este nombre se debe a que un �rbol se define como un patr�n de conexiones sin bucles. Lo que se hace es ir desactivando conexiones, ya que las conexiones restantes en el �rbol incluyen a todas las redes del sistema. Para llevarlo a cabo, todos los bridges del sistema de redes deben comunicarse entre ellos.\nHay una tendencia a que los �rboles de expansi�n resultantes cargan demasiado a la red en alguna parte del sistema. Las redes cercanas a la "raiz del �rbol" manejan todo el tr�fico entre las distintas partes de la red. En una red que usa gateways, ser�a posible poner enlaces extras entre partes de la red que tengan un gran tr�fico, pero dichos enlaces extras no pueden ser usados por un conjunto de bridges.\nLos gateways tienen sus propias ventajas y desventajas. En general, un gateway es m�s complejo de dise�ar y administrar que un bridge. Un gateway debe participar en todos los protocolos para los que est� dise�ado para reenviar. Por ejemplo, un gateway IP debe responder a peticiones ARP. El est�ndar IP tambi�n necesita estudiar por completo las cabeceras IP, decrementando el tiempo para activar campos y obedecer cualquier opci�n IP.\nLos gateways son dise�ados para manejar topolog�as de redes m�s complejas que las que son capaces de manejar los bridges. Y, como ya hemos mencionado, tienen diferentes (y m�s complejas) decisiones que estudiar. En general, un bridge tiene decisiones m�s f�ciles que tomar: si se debe reenviar un datagrama y, en caso de que deba hacerse, qu� interface hemos de elegir. Cuando un gateway reenv�a un datagrama, debe decidirse a qu� host o gateway hay que enviarlo a continuaci�n. Si un gateway env�a un datagrama de vuelta a la red de donde procede, tambi�n debe enviar una redirecci�n al emisor del datagrama indicando que use una mejor ruta. Muchos gateways pueden tambi�n manejar caminos paralelos. Si hay varios caminos igualmente buenos para un destino, el gateway usar� uno de ellos determinado por alg�n tipo de algoritmo aleatorio. (Esto se hace tambi�n en algunos bridges, pero no suele ser lo usual. En ambos casos, se elige uno de ellos mediante alg�n tipo de algoritmo aleatorio. Esto tiende a hacer que la llegada de los datagramas tenga un orden distinto al que fueron enviados. Lo que puede complicar la labor de procesamiento de los datagramas de los hosts de destino, e, incluso, hay viejas implementaciones TCP/IP que tienen errores a la hora de ordenar los datagramas).\nPara poder analizar todas estas decisiones, un gateway tendr� una tabla de enrutamiento muy similar a la de los hosts. Al igual que las tablas de enrutamiento, las tablas de los gateways contienen una entrada por cada posible n�mero de red. Para cada red hay, o bien una entrada indicando que la red est� conectada directamente al gateway, o hay una entrada indicando que el tr�fico para esa red debe reenviarse hacia alg�n otro gateway o gateways. Describiremos posteriormente los "protocolos de enrutamiento" usados para elaborar esta informaci�n, en la discusi�n sobre c�mo configurar un gateway.\nLos repetidores, repetidores con buffer, bridges y gateways forman un espectro. Los dispositivos del principio de la lista son mejores para redes peque�as, adem�s son m�s baratos y f�ciles de configurar aunque tienen menos servicios. Los del final de la lista son apropiados para construir redes m�s complejas. Muchas redes usan mezclas de dispositivos, con repetidores para conectar peque�os segmentos de red, bridges para algunas �reas grandes y gateways para enlaces de larga distancia.\nHasta ahora hemos asumido que s�lo usan gateways. La secci�n de c�mo configurar un host describe c�mo configurar una tabla de enrutamiento, listando los gateways que se deb�an usar para alcanzar a distintas redes. Los repetidores y bridges son invisibles a IP, y, en lo que a las anteriores secciones se refiere, las redes conectadas mediante ellos se deben considerar como una �nica red. En la secci�n 3.4. se describe c�mo configurar un host en el caso en que varias subredes se traten como una �nica red f�sica; la misma configuraci�n deber�a usarse cuando varias subredes se conectan mediante repetidores o bridges.\nComo ya mencionamos, las caracter�sticas a tener en cuenta en un dispositivo conmutador son: aislamiento, rendimiento, enrutamiento y las facilidades de mantenimiento de la red.\nGeneralmente, los dispositivos conmutadores se usan para conectar redes. As� que, normalmente, pensamos en ganar conectividad, no en el aislamiento. Sin embargo, el aislamiento es algo digno de tener en cuenta. Si conectamos dos redes y no tenemos en cuenta el aislamiento para nada, entonces cualquier problema en otras redes aparecer� en la nuestra tambi�n. Asimismo, dos redes juntas pueden tener suficiente tr�fico como para saturar la nuestra. Es por lo tanto conveniente elegir un nivel apropiado de protecci�n.\nEl aislamiento puede llegar de dos maneras: aislamiento frente al mal funcionamiento y frente al tr�fico. Con el objeto de discutir el aislamiento debido a errores de funcionamiento, vamos a se�alar una clasificaci�n de malfunciones:\n* Fallos el�ctricos, como por ejemplo una bajada de tensi�n o alg�n tipo de fallo que distorsiona la se�al. Todos los tipos de dispositivos deber�n confinarlo a un lado del dispositivo (repetidor, repetidor con buffer, bridge, gateway).\n* Problemas con los transceiver y controladores que, en general, generan se�ales el�ctricamente correctas, pero de contenido err�neo (por ejemplo, paquetes de tama�o infinito o demasiado grandes, falsas colisiones, portadora continua). Todos, excepto el repetidor, nos protegen de estos problemas, que no son muy comunes.\n* Errores en el software que provocan un excesivo tr�fico entre algunos hosts (no nos referimos a mensajes de tipo broadcoast). Los bridges y gateways pueden aislarnos de estos errores. (Este tipo de fallos son bastante raros. La mayor parte de los problemas del software y de protocolos generan broadcoasts).\n* Errores en el software que provocan un excesivo tr�fico de broadcast. Los gateways se aislan de estos problemas. Generalmente, los bridges no lo hacen, porque deben dejar las peticiones ARP y otros broadcasts. Los bridges con filtros definidos por el usuario podr�an protegernos contra algunos de estos errores de sobrecarga de broadcast. Sin embargo, en general, los bridges deben dejar pasar ARP y la mayor�a de estos errores se deben a ARP. Este problema no es tan grave en redes donde el software tiene un cuidadoso control, pero tendremos regularmente problemas de este tipo en redes complejas o con software experimental.\nEl aislamiento al tr�fico es proporcionado por bridges y gateways. La decisi�n m�s importante al respecto es conocer el n�mero de ordenadores que podemos poner en una red sin sobrecargarla. Esto requiere el conocimiento de la capacidad de la red, y el uso al que se destinar�n los hosts. Por ejemplo, una Ethernet puede soportar cientos de sistemas si se van a destinar para logins remotos y, ocasionalmente, para transferencia de ficheros. Sin embargo, si los ordenadores carecen de disco, y usamos la red para swapping, una Ethernet podr�a soportar entre 10 y 40, dependiendo de su velocidad y sus caracter�sticas de E/S.\nCuando ponemos m�s ordenadores en una red de los que es capaz de manejar, deberemos dividirla en varias redes y poner alg�n dispositivo conmutador entre ellos. Si esto se hace correctamente, la mayor�a del tr�fico deber� realizarse entre m�quinas de la misma parte de la divisi�n, lo que significa poner los clientes en la misma red que su servidor, poner los servidores de terminales en la misma red que los hosts a los que se accede m�s frecuentemente.\nBridges y gateways, generalmente, suministran el mismo grado de aislamiento al tr�fico. En ambos casos, s�lo el tr�fico destinado a los hosts del lado de la unidad conmutadora se pasar�. Veremos esto m�s detalladamente en la secci�n del enrutamiento.\nLos l�mites de las prestaciones empiezan a ser menos claros, puesto que las tecnolog�as de conmutaci�n est�n mejorando continuamente. Generalmente, los repetidores pueden manejar todo el ancho de banda de la red (por su propia naturaleza, un repetidor b�sico ha de ser capaz de hacer esto). Los bridges y gateways frecuentemente tienen limitaciones en sus prestaciones de varios tipos. Los bridges tienen dos estad�sticos de inter�s: la tasa de paquetes analizados y el rendimiento. Como explicamos anteriormente, los bridges deben analizar cada paquete que se encuentra en la red, incluso aquellos que no van a ser reenviados. El n�mero de paquetes analizados por segundo es la unidad usada para medir la tasa de paquetes analizados. El rendimiento se puede aplicar tanto a bridges como a gateways, y refleja la parte del tr�fico que ha sido reenviada; generalmente, depende del tama�o del datagrama. As�, el n�mero de datagramas por segundo que una unidad puede manejar ser� mayor cuanto haya m�s datagramas peque�os que grandes. Normalmente, un bridge puede manejar desde algunos cientos de datagramas hasta unos 7.000. Se puede obtener mayor capacidad de procesamiento con equipos que usan una hardware de prop�sito espec�fico para acelerar la labor de an�lisis de paquetes. La primera generaci�n de gateways pod�an procesar entre algunos cientos de datagramas por segundo hasta unos 1.000 � m�s; sin embargo, los gateways de segunda generaci�n, ampliamente extendidos, usan un hardware de prop�sito espec�fico igual de sofisticado que el usado en los bridges y con ellos se pueden manejar alrededor de 10.000 datagramas por segundo. Debido a que en este momento los bridges y gateways de altas prestaciones pueden manejar casi todo el ancho de banda de una Ethernet, las prestaciones no son una raz�n para elegir entre un tipo u otro de dispositivo. Sin embargo, para un tipo dado de dispositivo, hay todav�a grandes diferencias entre los distintos modelos, sobre todo en la relaci�n precio/prestaciones. Esto es especialmente cierto en los modelos de la gama baja. Los bridges m�s baratos cuestan menos de la mitad que los gateways m�s baratos.\nDesgraciadamente, no hay un �nico estad�stico para poder estimar las prestaciones de un dispositivo. No obstante, el que m�s se usa es el de paquetes por segundo. Hay que tener en cuenta que la mayor�a de las empresas cuentan los datagramas una sola vez, cuando pase por el gateway; hay una compa��a importante que cuenta los datagramas 2 veces, y, por tanto, deben dividirse por 2 para poder comparar. Tambi�n hay que asegurarse, para hacer una comparaci�n correcta, que los datagramas son del mismo tama�o. Un modelo para poder comparar prestaciones es\ntiempo_de_procesamiento = tiempo_conmutaci�n + tama�o_datagrama * tiempo_por_byte\nAqu�, el tiempo de conmutaci�n suele ser una constante; representa la interrupci�n latente, el procesamiento de las cabeceras, buscar en la tabla de enrutamiento, etc., m�s un componente proporcional al tama�o del datagrama, representando el tiempo necesario para hacer cualquier copia de datagrama. Un enfoque razonable para estudiar las prestaciones es dar los datagramas por segundo por los tama�os m�nimos y m�ximos de los datagramas. Otra forma de conocer los l�mites de un dispositivo es conociendo la velocidad de los datagramas por segundo y el rendimiento en bytes por segundo, y aplicando la f�rmula anterior.\nVamos a estudiar las tecnolog�as usadas para decidir hacia d�nde debe enviarse un datagrama. Por supuesto, no haremos esto para los repetidores, ya que �stos reenv�an todos los paquetes.\n(1) activar o desactivar los enlaces de manera que se mantenga el �rbol de expansi�n; y,\n(2) decidir si debemos reenviar un paquete en particular y a trav�s de cu�l interface (si el puente es capaz de manejar m�s de dos interfaces).\nLa segunda decisi�n se toma en base a una tabla de direcciones del nivel-MAC. Como ya hemos descrito anteriormente, esta tabla se construye analizando el tr�fico que pasa por cada interface. El objetivo es reenviar aquellos paquetes cuyo destino se encuentre a otro lado del bridge. Este algoritmo requiere tener una configuraci�n de red que no contenga bucles o l�neas redundantes. Los bridges menos sofisticados dejan esta tarea al dise�ador de la red, y debemos dise�ar y configurar una red sin bucles. Los bridges m�s sofisticados permiten una topolog�a cualquiera, pero ir� desactivando enlaces hasta que no haya bucles; adem�s, nos proporciona una fiabilidad extra, ya que, en caso de fallo de un enlace, se activar� autom�ticamente un enlace alternativo. Los bridges que funcionan de este modo tienen un protocolo que les permite detectar cu�ndo una unidad debe desactivarse o activarse, de manera que el conjunto activo de enlaces abarquen el �rbol de expansi�n. Si necesitamos la fiabilidad proporcionada por los enlaces redundantes, debemos asegurarnos que nuestros bridges sean capaces de trabajar de esta manera. Actualmente no hay un protocolo est�ndar para este tipo de bridges, pero est� en camino. En caso de comprar bridges de m�s de una marca, debemos asegurarnos que sus protocolos para trabajar con los �rboles de expansi�n pueden entenderse.\nPor otro lado, los gateways permiten cualquier tipo de topolog�a, incluyendo bucles y enlaces redundantes. Debido a que tienen algoritmos m�s generales de enrutamiento, los gateways deben mantener un modelo de toda la red. Diferentes t�cnicas de enrutamiento mantienen modelos de redes con m�s o menos complejidad, y usan esta informaci�n con distinto tipo de sofisticaci�n. Los gateways que pueden manejar IP, normalmente soportan los dos protocolos est�ndares de Internet: RIP (Routing Information Protocol) y EGP (External Gateway Protocol). El EGP es un protocolo de prop�sito espec�fico usado en redes donde hay una red principal, y permite intercambiar informaci�n de "c�mo llegar" con la red principal. Por regla general, es bastante recomendable que nuestros gateways soporten EGP.\nRIP es un protocolo dise�ado para manejar rutas en redes peque�as o medianas, donde la velocidad de las l�neas no difieren demasiado. Sus principales limitaciones son:\n* No puede usarse con redes donde los caminos pasan por m�s de 15 gateways. Se puede, incluso, reducir este n�mero en el caso de que usemos una opci�n de dar un paso mayor de uno a una l�nea lenta.\n* No puede compartir el tr�fico entre l�neas paralelas (algunas implementaciones permiten hacer esto si dichas l�neas se encuentran entre el mismo par de gateways).\n* No es adecuada para situaciones en las que hay rutas alternativas a trav�s de l�neas con muy distinta velocidad.\n* No es estable en redes donde las l�neas o los gateways cambian con frecuencia.\nAlgunas compa��as venden modificaciones de RIP que mejoran su funcionamiento con EGP, o que incrementan la longitud del camino m�ximo m�s all� de 15, pero no incluyen otro tipo de modificaciones. En caso de que nuestra red disponga de gateways de m�s de una marca, en general necesitaremos que soporten RIP, puesto que suele ser el �nico protocolo de enrutamiento disponible. Si vamos a trabajar, adem�s, con otro tipo de protocolo, pueden sernos �tiles gateways que traduzcan su propio protocolo y RIP. Sin embargo, para redes muy grandes o complejas no nos queda otro remedio que usar otros protocolos.\nTambi�n existen otros protocolos m�s sofisticados. Los principales son IGRP y los basados en los algoritmos SPF (el camino m�s corto primero - short path fist). Usualmente, estos protocolos han sido dise�ados para redes m�s grandes o complejas y, en general, son estables bajo una gran variedad de condiciones, pudiendo manejar l�neas de cualquier velocidad. Algunos de ellos permiten tener en cuenta la sobrecarga de algunos caminos, pero hasta el moemento no conozco un gateway que sea capaz de hacer esto. (Hay serios problemas para mantener un enrutamiento estable para realizarlo). Hay numerosas variantes de tecnolog�as de enrutamiento, y �stas se est�n modificando r�pidamente, as� que deberemos tener en cuenta la topolog�a de nuestra red para elegir un producto en concreto; tenemos que asegurarnos que puede manejar nuestra topolog�a y que puede soportar otros requerimientos especiales, como compartir el tr�fico entre l�neas paralelas, o ajustar la topolog�a ante fallos. A largo plazo, se espera que aparezcan nuevos protocolos que estandaricen estos trabajos. Pero, por el momento, no se usa otra tecnolog�a de enrutamiento que la RIP.\nOtro asunto concerniente al enrutamiento es la politica en la que se basa el enrutamiento. En general, los protocolos de enrutamiento pretenden encontrar el camino m�s corto o m�s r�pido posible para cada datagrama. En algunos casos, esto no es lo deseable; a veces, por razones de seguridad, razones econ�micas, etc, puede que deseemos reservar algunos caminos para alg�n uso espec�fico. La mayor�a de los gateways tienen la capacidad de controlar la propagaci�n de la informaci�n de enrutamiento, lo que nos da algunas facilidades de administraci�n sobre la forma en que estas rutas se usan, y el grado de control que soportan var�a de un gateway a otro.\nLa administraci�n de redes abarca un amplio n�mero de asuntos. En general, se suelen tratar con muchos datos estad�sticos e informaci�n sobre el estado de distintas partes de la red, y se realizan las acciones necesarias para ocuparse de fallos y otros cambios. La t�cnica m�s primitiva para la monitorizaci�n de una red es hacer "pinging" a los hosts cr�ticos; el "pinging" se basa en un datagrama de "echo" (eco), que es un tipo de datagrama que produce una r�plica inmediata cuando llega al destino. La mayor�a de las implementaciones TCP/IP incluyen un programa (generalmente, llamado "ping") que env�a un echo a un host en concreto. Si recibimos r�plica, sabremos que host se encuentra activo, y que la red que los conecta funciona; en caso contrario, sabremos que hay alg�n error. Mediante "pinging" a un razonable n�mero de ciertos hosts, podremos normalmente conocer qu� ocurre en la red. Si los ping a todos los hosts de una red no dan respuesta, es l�gico concluir que la conexi�n a dicha red, o la propia red, no funciona. Si s�lo uno de los hosts no da respuesta, pero los dem�s de la misma red responden, es razonable concluir que dicho host no funciona.\nT�cnicas m�s sofisticadas de monitorizaci�n necesitan conocer informaci�n estad�stica y el estado de varios dispositivos de la red. Para ello necesitar� llevar la cuenta de varias clases de datagramas, as� como de errores de varios tipos. Este tipo de informaci�n ser� m�s detallada en los gateways, puesto que el gateway clasifica los datagramas seg�n protocolos e, incluso, �l mismo responde a ciertos tipos de datagramas. Sin embargo, los bridges e incluso los repetidores con buffer contabilizan los datagramas reenviados, errores de interface. Es posible recopilar toda esta informaci�n en un punto de monitorizaci�n central.\nTambi�n hay un enfoque oficial TCP/IP para llevar a cabo la monitorizaci�n. En la primera fase, usamos un conjunto de protocolos SGMP y SNMP, ambos dise�ados para permitirnos recoger informaci�n y cambiar los par�metros de la configuraci�n y otras entidades de la red. Podemos ejecutar los correpondientes programas en cualquier host de nuestra red. SGMP est� disponible para varios gateways comerciales, as� como para sistemas Unix que act�an como gateway. Cualquier implementaci�n SGMP necesita que se proporciones un conjunto de datos para que pueda empezar a funcionar, y tienen mecanismos para ir a�adiendo informaciones que var�an de un dispositivo a otro. A finales de 1988 apareci� una segunda generaci�n de este protocolo, SNMP, que es ligeramente m�s sofisticado y necesita m�s informaci�n para trabajar y, para ello, usa el llamado MIB (Management Information Base). En lugar de usar una colecci�n de variable SNMP, el MIB es el resultado de numerosas reuniones de Comit�s formados por vendedores y usuarios. Tambi�n se espera la elaboraci�n de un equivalente de TCP/IP de CMIS, el servicio ISO de monitorizaci�n de redes. Sin embargo, CMIS y sus protocolos, CMIP, todav�a no son est�ndares oficiales ISO, pero est�n en fase experimental.\nEn t�rminos generales, todos estos protocolos persiguen el mismo objetivo: permitirnos recoger informaci�n cr�tica de una forma estandarizada. Se ordena la emisi�n de datagramas UDP desde un programa de administraci�n de redes que se encuentra ejecutando en alguno de los hosts de red. Generalmente, la interacci�n es bastante simple, con el intercambio de un par de datagramas: una orden y una respuesta. El mecanismo de seguridad tambi�n es bastante simple, siendo posible que se incluyan passwords en las �rdenes. (En SGMP nos referiremos a �stos como una "session name", en lugar de password). Tambi�n existen mecanismos de seguridad m�s elaborados, basados en la criptograf�a.\nProbablemente querremos configurar la administraci�n de la red con las herramientas que tenemos a nuestra disposici�n para controlar diversas actividades. Para redes con pocas terminales, queremos controlar cu�ndo nuestros dispositivos de conmutaci�n fallan, est�n fuera de servicio por mantenimiento, y cuando haya fallos en las l�neas de comunicaci�n u otro hardware. Es posible configurar SGMP y SNMP para que usen "traps" (mensajes no solicitados) para un host en particular o para una lista de hosts cuando ocurre un evento cr�tico (por ejemplo, l�neas activas o desactivas). No obstante, no es realista esperar que un dispositivo de conmutaci�n nos notifique cuando falla. Tambi�n es posible que los mensajes "traps" se pierdan por un fallo en la red, o por sobrecarga, as� que no podemos depender completamente de los traps. No obstante, es conveniente que nuestros dispositivos de conmutaci�n re�nan regularmente este tipo de informaci�n. Hay varias herramientas que visualizan un mapa de la red, donde los objetos cambian de color cuando cambian de estado, y hay cuadros que muestran estad�sticas sobre los datagramas y otros objetos.\nOtro tipo de monitorizaci�n deseable es recolectar informaci�n para hacer informes peri�dicos del porcentaje de uso de la red y prestaciones. Para ello, necesitamos analizar cada dispositivo de conmutaci�n y quedarnos con los datos de inter�s. En la Universidad de Groucho Marx esto se hace cada hora, y se obtienen datos del n�mero de datagramas reenviados a Internet u otra red, errores, varios, etc.; y se almacenan informes detallados de cada d�a. Hay informes mensuales en los que se refleja el tr�fico que soporta cada gateway y algunas estad�sticas de errores, elegidas para ver si hay un gateway que est� sobrecargado (datagramas perdidos).\nSer�a posible que cualquier tipo de conmutador pudiese usar cualquier tipo de t�cnica de monitorizaci�n. Sin embargo, generalmente los repetidores no proporcionan ning�n tipo de estad�stica, debido a que normalmente no tienen ning�n procesador para abaratar su precio. Por otro lado, es posible usar un software de administraci�n de redes con repetidores con buffer, bridges y gateways. Los gateways, en la mayor�a de los casos, incluyen un avanzado software de administraci�n de redes. La mayor�a de los gateways pueden manejar IP y los protocolos de monitorizaci�n anteriormente mencionados. Y la mayor�a de los bridges tienen medios para poder recoger algunos datos de prestaciones. Puesto que los bridges no est�n dirigidos a ning�n protocolo en particular, la mayor�a de ellos no tienen el software necesario para implementar los protocolos TCP/IP de administraci�n de redes. En algunas ocasiones, la monitorizaci�n puede hacerse tecleando algunos comandos a una consola a la que est� directamente conectada. (Hemos visto un caso donde era necesario dejar el puente fuera de servicio para recoger estos datos). En los restantes casos, es posible recoger datos a trav�s de la red, pero el protocolo requerido no suele ser ning�n est�ndar.\nExcepto para algunas peque�as redes, debemos insistir en que cualquier dispositivo conmutador m�s complejo que un simple repetidor es capaz de recolectar estad�sticas y alg�n mecanismo para hacernos con ellas de forma remota. Aquellas partes de la red que no soporten dichas operaciones pueden monitorizarse mediante pinging (aunque el ping s�lo detecta errores graves, y no nos permite examinar el nivel de ruido de una l�nea serie y otros datos necesarios para llevar a cabo un mantenimiento de alta calidad). Se espera que la mayor�a del software disponible cumpla los protocolos SGMP/SNMP y CMIS. Tambi�n un software de monitorizaci�n no est�ndar, siempre y cuando sea soportado por los equipos que tenemos.\nVamos a reunir todo lo anterior indicando d�nde se usa cada tipo de conmutador, normalmente:\n* Los repetidores, normalmente, se restringen a un solo edificio. Puesto que no nos proveen de un aislamiento al tr�fico, debemos asegurarnos en todas las redes concectadas por los repetidores que pueden hacer llegar todos sus ordenadores. Puesto que no suelen tener herramientas de monitorizaci�n, no ser� deseable su uso para aquellos enlaces que fallan a menudo.\n* Los bridges y gateways deben situarse de manera que se divida la red en partes cuyo volumen de tr�fico sea manejable. Incluso se podr�an emplazar bridges o gateways incluso en el caso de que no sean necesarios por razones de monitorizaci�n.\n* Debido a que los bridges deben dejar pasar datagramas de broadcast, hay un l�mite en el tama�o de las redes que pueden conectar. Por lo general, basta limitar estas redes con un ciento de m�quinas, aproximadamente. Este n�mero puede ser mayor, si el bridge incluye algunas facilidades de filtrado de datagramas.\n* Debido a que algunos tipos de redes son proclives al mal funcionamiento, deberemos usar los bridges s�lo entre partes de la red donde un solo grupo es responsable de diagnosticar los problemas. Debemos estar locos para usar un bridge para concectar redes que pertenecen a distintas organizaciones. Las partes de la red "de tipo experimental" deber�n aislarse del resto de la red por gateways.\n* En muchas aplicaciones es m�s importante elegir un producto con la adecuada combinaci�n de prestaciones, herramientas de administraci�n e la red y otras caracter�sticas, para tomar la decisi�n de elegir entre bridges y gateways.\nVamos a ver algunos aspectos espec�ficos de la configuraci�n de gateways. Aquellos gateways que entienden el protocolo IP son, al mismo tiempo, hosts de Internet y, por tanto, podemos poner en pr�ctica lo visto para configurar las direcciones y el enrutamiento en los hosts. No obstante, la forma exacta de c�mo debemos configurar un gateway depende del modelo en concreto. En algunos casos, deberemos editar algunos ficheros inclu�dos en un disco del propio gateway. Sin embargo, por razones de fiabilidad, la mayor�a de los gateways no tienen discos propios; en su lugar, esta informaci�n se almacena en una memoria no vol�til o en ficheros que se cargan desde uno o varios hosts de la red.\nComo m�nimo, para configurar el gateway hay que especificar la direcci�n IP y la m�scara de cada interface, y activar un protocolo de enrutamiento adecuado. Normalmente ser� deseable configurar otros par�metros.\nUn par�metro importante a tener en cuenta es la direcci�n de broadcast. Como explicamos con anterioridad, hay cierto software antiguo que no funciona bien cuando se env�an broadcasts usando los nuevos protocolos de direcciones de broadcast. Por esta raz�n, algunos modelos nos permiten elegir una direcci�n broadcast para cada interface, y se debe configurar teniendo en cuenta el n�mero de ordenadores que hay en la red. En general, si los ordenadores soportan los actuales est�ndares, podr� usarse una direcci�n del tipo 255.255.255.255. No obstante, antiguas implementaciones deben comportarse mejor con otro tipo de direcciones, especialmente con aquellas direcciones que usan ceros para los n�meros del host (para la red 128.6 �ste tendr�a que ser 128.6.0.0. Para mantener la compatibilidad con redes que no soportan subredes podr�amos usar 128.6.0.0 como direcci�n de broadcast, incluso para una subred como 128.6.4). Podemos observar la 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 elecci�n, cada vez que hagamos un broadcast para ponerse al d�a del enrutamiento, muchas m�quinas de nuestra red nos responder�n con errores ARP o ICMP. Hay que hacer notar que cuando cambiamos las direcciones de broadcast en el gateway, necesitaremos cambiarla en los ordenadores individuales tambi�n. Lo que se suele hacer es cambiar la direcci�n de aquellos sistemas que podemos configurar, para hacerlos compatibles con los otros sistemas que no pueden configurarse.\nHay otros par�metros de la interface que pueden que sea necesario configurar para 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 versi�n 1 de transceiver Ethernet. En caso de que usemos un transceiver de este tipo, deberemos desactivar este tipo de test. De forma similar, los gateways conectados a l�neas en serie normalmente hacen este tipo de test para verificar su buen funcionamiento, y tambi�n hay situaciones en las que necesitaremos deactivar el test.\nEs bastante usual que tengamos que activar las opciones necesarias para el software que tengamos que usar. Por ejemplo, muchas veces es necesario activar expl�citamente el protocolo de administraci�n de red, y dar el nombre o la direcci�n del host donde se ejecuta el software que acepta traps (mensajes de error).\nLa mayor�a de los gateways tienen opciones relacionadas con la seguridad. Como m�nimo, 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, tambi�n deberemos definir una lista de control de accesos, o cualquier otro mecanismo que use el gateway en cuesti�n.\nLos gateways cargan la informaci�n de la configuraci�n a trav�s de la red. Cuando un gateway arranca, env�a una petici�n broadcast de varias clases, intentando concer su direcci�n Internet para luego cargar su configuraci�n. As�, hay que asegurarse que haya algunos ordenadores capaces de responder a dichas peticiones. En algunos casos, hay alg�n micro dedicado ejecutando un software especial. Otras veces, hay un software gen�rico que podemos ejecutar en varias m�quinas. Por razones de fiabilidad, debemos comprobar que hay m�s de un host con la informaci�n y los programas que necesita. En 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 direcci�n Internet, y luego cargan el c�digo y la informaci�n de la configuraci�n usando 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 informaci�n de cada uno de ellos. Si una red es muy grande, podemos tener problemas para asegurarnos de que esta informaci�n permanece consistente. Podemos mantener copias nuestras de todas las configuraciones en un �nico ordenador y que se distribuya a otros sistemas cuando haya alg�n cambio, usando las facilidades make y rdist de Unix. Si nuestro gateway tiene la opci�n de almacenar la informaci�n de la configuraci�n en una memoria no vol�til, podremos eliminar todos estos problemas log�sticos, pero presenta sus propios problemas. El contenido de esta memoria deber�a almacenarse en alguna localizaci�n central, porque de todas maneras es dif�cil para el personal de administraci�n de la red revisar la configuraci�n si se encuentra distribu�da entre los distintos gateways.\nx Arrancar un gateway que carga la informaci�n de su configuraci�n desde una localizaci�n distante es especialmente arriesgado. Los gateways que necesitan cargar su informaci�n de configuraci�n a trav�s de la red, generalmente emiten una petici�n broadcast a todas las redes que conectan. Si alg�n ordenador de una de esas redes es capaz de responder, no habr� ning�n problema. Sin embargo, algunos gateways que se encuentren a gran distancia donde los ordenadores de su alrededor no soportan los protocolos necesarios, en cuyo caso es necesario que las respuestas le lleguen a trav�s de una red donde haya unos ordenadores apropiados. Desde un punto de vista estricto, esto va en contra de la filosof�a de trabajo de los gateways, ya que normalmente un gateway no permite que un broadcast procedente de una red pase a trav�s de una red adyacente. Para permitir que un gateway obtenga informaci�n de un ordenador en una red distinta, al menos uno de los gateways que est� entre ellos tendr� que configurarse para que pase una clase especial de broadcast usado para recuperar este tipo de informaci�n. Si tenemos este tipo de configuraci�n, tendremos que comprobar este proceso peri�dicamente, ya que no es raro que nos encontremos con que no podamos arrancar un gateway tras un fallo de energ�a, debido a un cambio en la configuraci�n en otro gateway que hace imposible cargar esta informaci�n.\nPor �ltimo, vamos a tratar c�mo configurar el enrutamiento. Este tipo de configuraci�n es m�s dif�cil para un gateway que para un host. La mayor�a de los expertos TCP/IP recomiendan dejar las cuestiones de enrutamiento a los gateways. As�, los hosts simplemente tienen una ruta por defecto que apunta al gateway m�s cercano (por supuesto, los gateways no pueden configurarse de esta manera. Ellos necesitan tablas completas de enrutamiento).\nPara entender c�mo configurar un gateway, vamos a examinar con un poco m�s de detalle c�mo los gateways se comunican las rutas.\nCuando encendemos un gateway, la �nica red de la que tiene informaci�n es aqu�lla a la que est� directamente conectado (lo que se especifica en la configuraci�n). Para llegar a saber c�mo se llega a partes m�s distantes de la red, marca alg�n tipo de "protocolo de enrutamiento", que simplemente es un protocolo que permite a cada gateway anunciar a qu� redes tiene acceso, y extender esa informaci�n de un gateway a otro. Eventualmente, cada gateway deber�a saber c�mo llegar a cada red. Hay distintos tipos de protocolos de enrutamiento; en el m�s com�n, los gateways se comunican exclusivamente con los m�s cercanos; en otra clase de protocolos, cada gateway construye una base de datos describiendo cada gateway del sistema. No obstante, todos estos protocolos encuentran c�mo llegar a cualquier destino.\nUna m�trica es un n�mero, o conjunto de n�meros, usado para comparar rutas. La tabla de enrutamiento se construye recogiendo informaci�n de otros gateways. Si dos gateways son capaces de llegar a un mismo destino, debe de haber alg�n m�todo para decidir cu�l usar. La m�trica se usa para tomar esta decisi�n. Todas las m�tricas indican de alguna forma lo "costoso" de una ruta. Podr�a ser cu�ntos d�lares costar�a enviar un datagrama por una ruta, el retraso en milisegundos, o cualquier otra medida. La m�trica m�s simple es el n�mero de gateways que hay hasta el destino ("cuenta de saltos"), y es la que generalmente se encuentra en los ficheros de configuraci�n.\nComo m�nimo, una configuraci�n de enrutamiento consistir�a en un comando para activar el protocolo de enrutamiento que vayamos a usar. La mayor�a de los gateways est�n orientados para usar un protocolo; a no ser que tengamos razones para usar otro, es recomendable usar dicho protocolo. Una raz�n habitual para elegir otro protocolo es para hacerlo compatible con otros gateways. Por ejemplo, si nuestra red est� conectada a una red nacional que nos exige usar EGP ("exterior gateway protocol" ) para que se pueda intercambiar rutas con ella, EGP s�lo es apropiado para este caso espec�fico. No deberemos usar EGP dentro de nuestra propia red, sino s�lo para comunicarnos con la red nacional. Si tenemos varias clases de gateways, necesitaremos usar un protocolo entendible por todos ellos. En muchas ocasiones este protocolo ser� RIP (Routing Information Protocol ). A veces podremos usar protocolos m�s complejos entre los gateways que los soporten, y usar RIP s�lo cuando nos comuniquemos con gateways que no entiendan estos protocolos.\nSi ya hemos elegido un protocolo de enrutamiento y lo hemos puesto en marcha, todav�a nos quedan por tomar algunas decisiones. Una de las tareas mas b�sicas de configuraci�n que tenemos que completar es suministrar la informaci�n de la m�trica. Los protocolos m�s simples, como RIP, normalmente usan "cuenta de saltos", de manera que una ruta que pasa a trav�s de dos gateways es mejor que una que pasa por tres. Por supuesto, si la �ltima ruta usa l�neas de 1'5 Mbps y la primera l�neas de 9.600 bps, ser�a una mala elecci�n. La mayor�a de los protocolos de enrutamiento tienen medios para tomar esto en cuenta. Con RIP, podr�amos tratar las l�neas de 9.600 bps como si fueran "saltos" adicionales, de manera que la mejor l�nea (la m�s r�pida) tenga una m�trica menor. Otros protocolos m�s sofisticados tendr�n en cuenta la velocidad de la l�nea de forma autom�tica. Generalmente, estos par�metros deber�n asociarse a una interface en particular. Por ejemplo, con RIP deberemos establecer expl�citamente el valor de la m�trica, si se est� conectado con una l�nea de 9.600 bps. Con aquellos protocolos que tienen en cuenta la velocidad de las l�neas, deberemos de especificar la velocidad de las l�neas (si el gateway no los puede configurar autom�ticamente).\nLa mayor parte de los protocolos de enrutamiento han sido dise�ados para que cada gateway se aprenda la tipolog�a 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 econ�micas. Una manera de tener este control es especificando opciones de enrutamiento. Dichas opciones var�an mucho de un gateway a otro, pero la estrategia b�sica es que si el resto de la red no conoce dicha ruta, no ser� utilizada. Estos controles limitan la forma en la que se van a usar las rutas.\nHay m�todos para que el usuario ignore las decisiones de enrutamiento hechas por los gateways. Si realmente necesitamos controlar el acceso a ciertas redes, podemos hacer dos cosas:\n- los controles de enrutamiento nos aseguran que los gateways usan s�lo las rutas que queremos;\nEstas dos opciones trabajan a distinto nivel. Los controles de enrutamiento afectan a lo que ocurre a la mayor�a de los datagramas: aqu�llos en los que el usuario no ha 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 limitaci�n adicional, preserv�ndonos de usuarios que incluyesen su propio enrutamiento y pasasen nuestros controles.\nPor razones de fiabilidad y seguridad, puede que tambi�n haya controles con listas de gateways de las que podemos aceptar informaci�n. Tambi�n es posible hacer una clasificaci�n de prioridad. Por ejemplo, podemos decidir hacer antes los enrutamientos de nuestra propia organizaci�n antes que los de otras organizaciones, u otras partes de la organizaci�n. Esto tendr� el efecto de dar preferencia al tr�fico interno frente al externo, incluso si el externo parece ser mejor.\nSi usamos varios protocolos distintos de enrutamiento, probablemente tendremos que afrontar algunas decisiones respecto a la informaci�n que se pasan entre ellos. Puesto que el uso de varios protocolos de enrutamiento est� frecuentemente asociado a la existencia de varias organizaciones, deberemos de tomar la precauci�n de hacer estas decisiones consultando conlos administradores de las redes de dichas organizaciones. Este tipo de decisiones puede tener consecuencias en las otras redes bastante dif�ciles de detectar. Podr�amos 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:\n* Las m�tricas usadas por los distintos protocolos no son compatibles en muchas ocasiones. Si estamos conectados a dos redes externas distintas, podemos especificar que una siempre debe usarse preferentemente a la otra, o que la m�s cercana es la que debe usarse, en lugar de comparar la m�trica recibida de las dos redes para ver cu�l tiene la mejor ruta.\n* EGP es especialmente delicado, ya que no admite bucles. Por esto hay unas reglas estrictas para regular la informaci�n que hay que intercambiar para comunicarse con una red principal usando EGP. En aquellos casos en que se use EGP, el administrador de la red principal deber�a ayudarnos a configurar el enrutamiento.\n* Si tenemos l�neas lentas en nuestra red (9.600 bps o menos), puede que no queramos enviar la tabla de enrutamiento completa a trav�s de la red. Si nos conectamos a una red exterior, tenemos la posibilidad de tratarla como una ruta por defecto, en lugar de introducir toda su informaci�n en nuestro protocolo de enrutamiento.