lunes, 12 de diciembre de 2016

TCP/IP (8): Manejo de la tabla de rutas


Comandos para el manejo de la tabla de rutas
Los comandos para mantener la tabla de rutas se desarrollaron inicialmente en Unix. En otros sistemas, los comandos son similares. 
Vamos a ver ejemplos de comandos válidos para Linux. Casi todos ellos requieren permisos de administrador, así que probablemente necesites usar "sudo" para ejecutarlos. 
route add 128.6.2.0 128.6.4.1 1
Este comando añade una entrada en la tabla para que las comunicaciones con la red 128.6.2 se dirijan a la pasarela 128.6.4.1, con métrica 1. La primera dirección del par se puede cambiar por la palabra default, para crear una entrada por defecto.
ifconfig ie0 128.6.4.4 netmask 255.255.255.0
Esto añade una entrada que especifica que la dirección propia 128.6.4.4 corresponde a la interfaz de red ie0, con la máscara 255.255.255.0. Este comando se incluye en el fichero de arranque, y si la máquina tiene varias interfaces se añade una orden por cada uno.
netstat -n -r
Esto presenta por pantalla el estado actual de la tabla de rutas, con diferentes estadísticas, etc. Básicamente, netstat indica para cada nodo o red de destino, el gateway a usar, la interfaz de red (si hay varios) y una serie de banderas (flags) que indican diferentes aspectos de rutado. Los más importantes son:
* G: Indica si la ruta usa una pasarela para llegar al nodo de destino. Cuando esta bandera no está presente, el destino está conectado directamente, y la dirección de pasarela indicada no está siendo usada en realidad.
* U: Indica si la ruta está activa (up) en este momento. Cuando se han registrado varios fallos de conexión consecutivos, esta bandera se elimina, para que se deje de usar esta ruta.
* H: Indica que esta ruta se refiere a un nodo (host), y no a una red. Normalmente, las entradas de la tabla de rutas no son de este tipo, aunque puede darse el caso que esto sea necesario.
* D: Indica que esta ruta ha sido establecida dinámicamente por medio de una redirección ICMP.Una entrada en la tabla de rutas indicará la ruta por defecto, con la palabra default en la columna de direcciones de destino.
Manejo de errores en el rutado
Cuando un nodo que no sea una pasarela, por error en el rutado, recibe un datagrama no destinado a él, no debe intentar reenviarlo a su correcto destinatario. En vez de ello, el datagrama debe ser descartado. Las razones para establecer esta norma son varias:
* La acción correctiva evitaría que el error en el rutado se hiciera patente, de manera que éste persistiría.
* El rutado añadido genera mayor tráfico de red de manera innecesaria, además del gasto adicional en tiempo de CPU de la máquina que reenvía.
* Cualquier error simple puede reproducirse en cadena hasta convertir la red en un caos.
* Los nodos no participan de los mecanismos de control de rutado por medio de los cuales las pasarelas se informan unas a otras y mantienen actualizadas sus tablas. Las propias pasarelas no podrían detectar el rutado adicional producido por los nodos, y las consecuencias serían imprevisibles.
Separación estricta del direccionamiento IP
Durante su viaje desde el nodo origen al destino final, los datagramas no se ven alterados, a excepción del tiempo de vida y el checksum, que se recalculan. Esto implica que, aunque un datagrama atraviese muchas pasarelas, las direcciones de origen y destino en la cabecera del mismo siempre reflejan las del origen y destino finales.
Cuando una pasarela se dispone a reenviar un datagrama al salto siguiente, la dirección IP de dicho salto no es guardada en ningún lugar del datagrama, sino que simplemente es puesta en manos de la interfaz de red, el cual se encargará de resolver la dirección MAC correspondiente, empaquetar el datagrama en una trama física y transmitirlo. Luego, tanto la dirección IP como la física son desechadas.
Este comportamiento resulta paradójico; se puede pensar que si el rutado manejase directamente la dirección física, resultaría mucho más eficiente. Si en vez de un sólo datagrama, el nodo origen ha emitido una secuencia larga de ellos hacia el mismo destino, como suele ocurrir, resulta especialmente costoso resolver una y otra vez la misma dirección MAC. Las razones para que IP trabaje así son varias:
* Se ha de respetar escrupulosamente la frontera de direcciones entre el software IP y la red física. Si no se hiciera así, todo el sentido del protocolo de la red de redes y la independencia de la red física se vendrían abajo.
* La tabla de rutado es una interfaz muy transparente entre el software IP y el software de alto nivel con el que los administradores monitorizan y controlan las rutas. Habitualmente se suelen examinar las tablas de rutado, resultando mucho más fácil este trabajo usando direcciones IP.
* Al respetar la frontera se facilita el desarrollo y actualización de los restantes protocolos TCP/IP, que de esta manera sólo tienen que entender de direcciones de la red de redes.
Por tanto, IP establece una estricta frontera de direcciones entre el esquema de direccionamiento IP y otros esquemas, como pueden ser las direcciones MAC que se usan en Ethernet y otros protocolos similares. La traducción entre un tipo de dirección y otra la realizan otros protocolos que veremos en próximos artículos.
Protocolos para gestión del rutado
Para que las pasarelas mantengan actualizadas sus tablas de rutas, se impone la presencia de unos protocolos que les permitan mantenerse en contacto e intercambiar información de manera automática. 
Los protocolos clásicos de gestión del rutado son:
RIP (Routing Information Protocol): Es un protocolo diseñado para redes de pequeño y mediano tamaño, donde las velocidades de las diferentes líneas no difieren demasiado. Tiene una serie de limitaciones:
  • No se puede usar en redes donde los paquetes puedan atravesar más de 15 pasarelas.
  • No puede repartir el tráfico en conexiones en paralelo (dos o mas líneas con el mismo inicio y fin).
  • No se adapta a los cambios en la carga de la red.
  • No maneja bien las rutas alternativas cuando hay demasiada diferencia de velocidades entre ellas.
  • No es estable en las redes dónde hay contínuos cambios de líneas o de pasarelas.
La principal ventaja que tiene este protocolo es ser el único que es totalmente estándar. Así pues, es fundamental cuando se usan pasarelas de diferentes fabricantes.
EGP (External Gateway Protocol): Es un protocolo especialmente diseñado para redes dispersas unidas por medio una línea central. Permite intercambiar información sobre accesibilidad con la línea central.
Por otra parte, se han desarrollado también protocolos específicos para monitorización:
SGMP: Permite recoger información y hacer ajustes en los parámetros de los pasarelas y otros elementos de la red. El correspondiente conjunto de programas interfaz pueden ejecutarse desde cualquier nodo de la red. Está aceptado como un estándar por la mayoría de los fabricantes; existe un limitado conjunto de datos que se espera que proporcione, así como unos mecanismos comunes para la información añadida propia.
SNMP: Es la generación siguiente al SGMP. Prácticamente efectúa la misma misión, pudiendo monitorizar un conjunto de parámetros más completo, llamado MIB (Management Information Base). Esta base estándar de parámetros es el resultado de las aportaciones más o menos desorganizadas de los diferentes fabricantes a su antecesor, una vez pasadas por los comités de estandarización.
CMIP: Es el protocolo oficialmente propuesto por el ISO dentro de su especificación CMIS de monitorización.

No hay comentarios:

Publicar un comentario

Expresa tu opinión respetando a los demás y a unas mínimas reglas del lenguaje castellano.

Nota: solo los miembros de este blog pueden publicar comentarios.