Página siguiente Página anterior Índice general

5. Configurando el enrutamiento de cada ordenador

Todas 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".

A pesar de que los detalles de la configuración pueden diferir bastante, existen ciertos datos que deben incluirse en todos los casos. Entre ellos:

Antes 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 periodicamente. 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.

Generalmente, 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.

Por regla general, los ficheros de configuración hacen, a grosso modo, las siguientes cosas:

5.1 Como enrutar los datagramas

Si 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):

     Destino            Gateway          Bandera     Interface
    128.6.5.3          128.6.7.1          UHGD         il0
    128.6.5.21         128.6.7.1          UHGD         il0
    127.0.0.1          127.0.0.1          UH           lo0
    128.6.4            128.6.4.61         U            pe0
    128.6.6            128.6.7.26         U            il0
    128.6.7            128.6.7.26         U            il0
    128.6.2            128.6.7.1          UG           il0
    10                 128.6.4.27         UG           pe0
    128.121            128.6.4.27         UG           pe0
    default            128.6.4.27         UG           pe0

El sistema del ejemplo está conectado a dos Ethernet:

   Controlador    Red      Direccion    Otras Redes
       il0      128.6.7   128.6.7.26     128.6.6
       pe0      128.6.4   128.6.4.61     ninguna

La 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.

Estudiemos la tabla de enrutamiento; por el momento, ignoraremos las tres primeras líneas. La mayor parte de la tabla consiste en un conjunto de entradas describiendo las redes. Para cada red, las otras tres columnas muestran a 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).

Las 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

     128.6.2         128.6.7.1         UG         il0

indica que un datagrama para cualquier ordenador de la red 128.6.2 (es decir, direcciones desde 128.6.2.1hasta 128.6.2.254) debe enviarse al gateway 128.6.7.1, para llevarlo a cabo. En algunas ocasiones, se establecen rutas para un ordenador especí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

     128.6.5.21         128.6.7.1         UHGD         il0

indica 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).

El siguiente enrutamiento es especial:

     127.0.0.1         127.0.0.1         UH         lo0

donde, 127.0.0.1 es el dispositivo de "lazo cerrado", o loopback. Cualquier datagrama enviado a 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?).

Por último, hay una ruta por defecto ("default"), como es

     default         128.6.4.27    UG         pe0

Esta ruta será seguida por aquellos datagramas que no se correspondan con ninguna de las anteriores. En nuestro ejemplo, se enviarán a un gateway de dirección 128.6.4.27.

Como ú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.

    Destino           Gateway        Bandera     Interface
    172.16.1.33       0.0.0.0          UH           ppp0
    128.0.0.1         0.0.0.0          U            l0
    0.0.0.0           172.16.1.33      UG           ppp0     

Hay 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.

En 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").

En 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.

5.2 Rutas fijas

La 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.

Muchos 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

   ifconfig     ie0        128.6.4.4       netmask       255.255.255.0
   ifconfig     ie1        128.6.5.35      netmask       255.255.255.0

Este especifica que hay dos interfaces de red y sus direcciones en ellas. El sistema crea automáticamente estas entradas en la tabla de enrutamiento

   128.6.4      128.6.4.4           U         ie0
   128.6.5      128.6.5.35          U         ie1

y, 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.

Ademá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,

   route  add      128.6.2.0       128.6.4.1            1
   route  add      128.6.6.0       128.6.5.35           0

Estos 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-.

En ú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.

Si 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.

5.3 Reconducir el enrutamiento

La 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.

La 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:

    Destino        Gateway        Bandera        Interface   
+------------------------------------------------------------+
|  127.0.0.1   |  127.0.0.1   |       UH      |      lo0     |
+--------------+--------------+---------------+--------------+
|  128.6.4     |  128.6.4.61  |       U       |      pe0     |
+--------------+--------------+---------------+--------------+
|  default     |  128.6.4.27  |       UG      |      pe0     |
+------------------------------------------------------------+

donde hay una entrada para la red local 128.6.4, y una entrada por defecto del gateway 128.6.4.27. Supongamos que hay 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

     128.6.7.23   128.6.4.30   UDHG   pe0

De esta manera, los restantes datagramas al 128.6.7.23 se enviarán directamente al gateway apropiado.

Esta estrategia sería perfecta si no fuera por los siguientes tres problemas:

El 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).

Hasta 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.

La 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).

5.4 Otros métodos para que los hosts encuentren rutas

En 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:

Espiar el enrutamiento.

Los gateways, por regla general, tienen un protocolo especial que usan entre ellos. Hay que aclarar que el redireccionamiento no puede ser usado por los gateways, ya que éste es simplemente el mecanismo por el 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 esescuchar los mensajes que se intercambian entre ellos. Hay software capaz de hacer esto para la mayoría de los protocolos. Cuando ejecutamos este software, el ordenador mantendrá una 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.).

Ejecutando el software de enrutamiento en cada host resolveremos de alguna manera el problema de enrutamiento, pero hay algunas razones por las que normalmente no es recomendable, 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.

Hay 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.

Proxy ARP.

Los 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.

En muchos aspectos, los proxy ARP son semejantes al uso de una ruta por defecto y redireccionamiento, y la mayor diferencia radica en que tienen distintos mecanismos para comunicar rutas a los hosts. Con el redireccionamiento se usa una tabla completa de enrutamiento, de forma que en cualquier momento un host sabe a cual gateway debe enviar los datagramas. En cambio, los proxy ARP prescinden de las tablas de enrutamiento y hacen todo el trabajo a nivel de direcciones Ethernet. Los proxy ARP pueden usarse para todos los destinos, tanto para aquellos que 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

     route add default 128.6.4.2 0

donde, 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.

Cuando 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".):

 FOKKER.RUTGERS.EDU (128.6.5.16) at 8:0:20:0:8:22 temporary
 CROSBY.RUTGERS.EDU (128.6.5.48) at 2:60:8c:49:50:63 temporary
 CAIP.RUTGERS.EDU (128.6.4.16) at 8:0:8b:0:1:6f temporary
 DUDE.RUTGERS.EDU (128.6.20.16) at 2:7:1:0:eb:cd temporary
 W2ONS.MIT.EDU (128.125.1.1) at 2:7:1:0:eb:cd temporary
 OBERON.USC.EDU (128.125.1.1) at 2:7:1:2:18:ee temporary
 gatech.edu (128.61.1.1) at 2:7:1:0:eb:cd temporary
 DARTAGNAN.RUTGERS.EDU (128.6.5.65) at 8:0:20:0:15:a9 temporary

Como dijimos anteriormente, simplemente es una lista de direcciones IP y su correspondiente dirección Ethernet. El término "temporary" indica que la entrada fue añadida dinámicamente usando ARP, en lugar de ser puesta manualmente.

Si 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.

Este 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á.

Los proxies ARP se basan en la idea de que los gateways actúen como proxies 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)

           red 1                      red 2
          128.6.5                    128.6.4
   ============================  ==================
     |              |        |    |      |    |
  ___|______   _____|____  __|____|__  __|____|____
  128.6.5.2    128.6.5.3   128.6.5.1   128.6.4.194
                           128.6.4.1
 ___________  ___________  __________  ____________
 ordenador A  ordenador B   gateway R   ordenador C

Ahora supongamos que el ordenador A enví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.

Veamos que esto tiene el mismo efecto que tener una entrada en la tabla de enrutamiento diciendo que la ruta de 128.6.4.194 al gateway 128.6.5.1 es:

     128.6.4.194   128.6.5.1   UGH   pe0

Con la excepción de que, en lugar de tener el enrutamiento hecho a nivel de tabla de enrutamiento, se hace a nivel de tabla ARP.

Generalmente, es mejor usar tablas de enrutamiento, pero hay algunos casos en los que tiene sentido los usar proxyes ARP:

La 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.

Los proxy ARP resuelven el problema haciendo ver el mundo de un modo simplista que espera encontrarse. Puesto que el host piensa que todas las restantes subredes forman parte de su propia red, simplemente usará una 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.

Como 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.

Es obvio que los proxy ARP son adecuados cuando los hosts no son capaces de entender subredes. Generalmente, las implementaciones TCP/IP son capaces de manejar mensajes de 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.

A 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.

Para 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.

Finalmente, 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.

En 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:

         1              2              3
    ------------ A ------------ B -----------

donde, 1, 2 y 3 son redes; y A y B gateways conectando 2 con 1 ó con 3. Si un host de la red 2 quiere 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:

               1
        ---------------
          A        B
          |        | 4
          |        |
        3 |        C
          |        |
          |        | 5
          D        E
        ---------------
               2

Supongamos que un ordenador en la red 1 quiere enviar un datagrama a otro de la red 2. La ruta vía 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.

Establecer nuevas rutas tras fallos.

En principio, IP es capaz de controlar líneas con fallos y caídas de gateways. Hay varios mecanismos para 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.

Espiar 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:

Los 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:

El 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.

La casuística de los proxy ARP es similar. Si los gateways se coordinan adecuadamente, en principio el gateway indicado responderá adecuadamente. Si algo en la red falla, el gateway que actualmente se está 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 cual quier gateway puede responder a una petición ARP.

Así que el gran problema es el fallo debido a que el gateway en uso no se puede recuperar, por el hecho de que el principal mecanismo para alterar las rutas es el redireccionamiento, y un gateway en mal funciona miento no puede redirigir. 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.

Mé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.

Sin 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.

Por ú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.


Página siguiente Página anterior Índice general