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:
software
de enrutamiento y las tablas que use;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:
software
que no forma parte del sistema
operativo).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.software
, como, por ejemplo, el nombre del propio sistema.daemons
). Hay programas que
proveen de servicios de red a otros sistemas de la red, y a los usuarios de
estos sistemas. En el caso de los PC's, que en muchos casos no soportan
el multiproceso, y dichos servicios, se establecen mediante los llamados
"TSR", o mediante los drivers del dispositivo. 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.
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
.
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:
gateway
por defecto en los ficheros de configuración.gateway
falle, las entradas de las tablas de
enrutamiento que usan dicho gateway
no se eliminan.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).
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:
proxy
ARP. 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.
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:
host
que no trabaja con subredes;host
que no responde adecuadamente
al redireccionamiento;gateway
determinado por defecto;software
no es capaz de recuperarse de un enrutamiento fallido.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.
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:
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
.gateways
usan protocolos específicos de alguna marca
comercial. En este caso, es posible que no encontremos un software
adecuado para nuestros hosts
.hosts
carecen de disco, puede que haya serios
problemas a la hora de escuchar las emisiones. Algunos gateways
son
capaces de traducir su protocolo interno de enrutamiento en otro 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.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:
gateway
por defecto no está en la mejor ruta. El gateway
por
defecto puede dirigirlo a un gateway
mejor;gateway
falla. Si esto cambia la mejor
ruta, el gateway
actual nos dirigirá hacia el gateway
que ahora es el
mejor.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.