RIP - Routing Information Protocol
Introducción Histórica
Uno de los protocolos de routing más antiguos es el Routing Informacition
Protocol o más comúnmente llamado RIP. RIP utiliza algoritmos de vector
distancia para calcular sus rutas. Este tipo de algoritmos para calcular rutas
fueron utilizados durante décadas en sus distintas variantes. De hecho los
algoritmos de vector distancia utilizados por RIP están basados en aquellos
algoritmos utilizados por ARPANET en el año 1969.
Los protocolos vector distancia fueron descritos académicamente por: R.E.
Bellman, L.R. Ford Jr y D.R. Fulkerson .
La primera organización que implementó un protocolo de vector distancia fue
la compañía Xerox en su protocolo GIP (Gateway Information Protocol), este
protocolo estaba incluido dentro de la arquitectura XNS (Xerox Network Systems).
GIP se utilizaba para intercambiar información de routing entre redes o sistemas
autónomos no adyacentes. Pero claro, Xerox había implementado su propio
protocolo propietario.
Poco después la University of California en Berkeley creo una variante
llamada “routed ”, esta variante del GIP introdujo novedades como modificación
del campo de direccionamiento, que se consiguió más flexible , también se añadió
un temporizador que limitaba a 30 segundos el tiempo máximo de actualización, es
decir, el tiempo máximo permitido sin saber la información de los vecinos, y por
supuesto se integró dentro de UNIX, con lo cual pasó a ser abierto.
El protocolo RIP, tal cual lo conocemos actualmente, fue descrito por primera
vez en el RFC 1058 (http://www.rfc-editor.org/rfc/rfc1058.txt)
por C. Hedrick de la Rutgers University en Junio de 1988, y posteriormente fue
mejorado en la RFC 2453 (http://www.rfc-editor.org/rfc/rfc2453.txt)
por G.Malkin de la compañía Bay Networks en Noviembre de 1998.
Desde el año 1998 el protocolo RIP se ha mantenido estable, aunque
posteriormente salió la versión para Ipv6, la cual tiene su propio capítulo.
Introducción Técnica
RIP es un protocolo de routing de vector distancia muy extendido en todo el
Mundo por su simplicidad en comparación a otros protocolos como podrían ser OSPF,
IS-IS o BGP. RIP se trata de un protocolo abierto a diferencia de otros
protocolos de routing como por ejemplo IGRP y EIGRP propietarios de Cisco
Systems o VNN propietario de Lucent Technologies.
RIP está basado en el algoritmo de Bellman Ford y busca su camino óptimo
mediante el conteo de saltos, considerando que cada router atravesado para
llegar a su destino es un salto.
RIP, al contar únicamente saltos, como cualquier protocolo de vector
distancia no tiene en cuenta datos tales como por ejemplo ancho de banda o
congestión del enlace.
RFC 1058: Routing Information Protocol
En Junio de 1988, C. Hedrick publicó el RFC 1058 correspondiente a RIP
versión 1, y lo encabezó de la siguiente manera:
“This RFC describes an existing protocol for exchanging routing
information among gateways and other hosts. It is intended to be used as a basis
for developing gateway software for use in the Internet community. Distribution
of this memo is unlimited.”
El protocolo RIPv1, al igual que sus antecesores propietarios es un protocolo
de routing que fue diseñado para funcionar como protocolo vector distancia.
RIPv1 fue diseñado para funcionar en redes pequeñas de pasarela interior . RIPv1
está basado según el autor del RFC en la versión 4.3 de la distribución de UNIX
de Berkeley.
En cuanto al protocolo tenemos que tener en cuenta las tres limitaciones que
C. Hedrick describe en la página 3 del RFC 1058:
- El protocolo no permite más de quince saltos, es decir, los dos routers
más alejados de la red no pueden distar más de 15 saltos, si esto ocurriera no
sería posible utilizar RIP en esta red.
- Problema del “conteo a infinito”. Este problema puede surgir en
situaciones atípicas en las cuales se puedan producir bucles, ya que estos
bucles pueden producir retardos e incluso congestión en redes en las cuales el
ancho de banda sea limitado. El autor del RFC 1058 también comenta que en la
realidad esto sólo puede ser un problema en redes lentas, pero el problema
existe.
- El protocolo utiliza métricas fijas para comparar rutas alternativas, lo
cual implica que este protocolo no es adecuado para escoger rutas que dependan
de parámetros a tiempo real como por ejemplo retardos o carga del enlace.
Además de los problemas que cita el autor del protocolo tenemos que tener en
cuenta que el protocolo RIPv1 es un protocolo classfull , con lo que existe el
problema de la discontinuidad de redes. El problema de la discontinuidad de
redes se produce en el momento que tenemos una red dividida en varias subredes y
no pueden ser sumarizadas en una misma ruta, ya que físicamente cada una de las
subredes está ubicada en un lugar que depende de un interfaz distinto una subred
de la otra. Pero claro, en la época en la que se escribió este RFC, que era en
1988 estos problemas no estaban contemplados y con el tiempo se detectó este
problema, esta es una de las razones de la existencia de RIPv2.
Tabla de routing de RIP
Si continuamos la lectura detallada del RFC1058, podemos ver que el autor nos
dice que la base de datos de routing de cada uno de los hosts de la red que
están utilizando el protocolo de routing RIP tiene los siguientes campos:
- Dirección de destino
- Siguiente salto
- Interfaz de salida del router
- Métrica
- Temporizador
Para obtener esta tabla, el protocolo de routing RIP utiliza el siguiente
procedimiento para mantener actualizada la tabla de routing de cada uno de los
nodos o routers de la red:
- Mantener una tabla con una entrada por cada posible destino en la red. La
entrada debe contener la distancia D al destino, y el siguiente salto S del
router a esa red. Conceptualmente también debería de existir una entrada para
el router mismo con métrica 0, pero esta entrada no existirá.
- Periódicamente se enviará una actualización de la tabla a cada uno de los
vecinos del router mediante la dirección de broadcast. Esta actualización
contendrá toda la tabla de routing.
- Cuando llegue una actualización desde un vecino S, se añadirá el coste
asociado a la red de S, y el resultado será la distancia D'. Se comparará la
distancia D' y si es menor que el valor actual de D a esa red entonces se
sustituirá D por D'.
El protocolo de routing RIP como ya hemos dicho mantiene una tabla de routing,
como cualquier protocolo de routing, seguidamente pasamos a comentar cada uno de
los campos de la tabla.
Dirección de destino
La dirección de destino en la tabla de routing de RIP será la red de destino,
es decir, la red final a la que deseamos acceder, esta red en la versión 1 del
protocolo RIP tendrá que ser obligatoriamente clasfull, es decir tendrá que
tener en cuenta la clase, es decir, no se permite el subneting en RIP versión 1,
por ejemplo si la red de destino es la 192.168.4.0, sabemos que al ser RIP
classfull la red de destino tiene 256 direcciones, de las cuales 254 son útiles,
una vez descontada la dirección de red y la dirección de broadcast, ya que la
red 192.168.4.0 es de clase C, es decir que los 24 primeros bits de la dirección
IP identifican la red y los 8 últimos identifican los hosts de dentro de la red.
Siguiente salto
El siguiente salto lo definimos como el siguiente router por el que nuestro
paquete va a pasar para llegar a su destino, este siguiente salto será
necesariamente un router vecino del router origen.
Interfaz de salida del router
Entendemos por interfaz de salida del router al interfaz al cual está
conectado su siguiente salto.
Métrica
La métrica utilizada por RIP como ya hemos comentado consiste en el conteo de
saltos, como métrica se considera cada salto como una única unidad,
independientemente de otros factores como tipo de interfaz o congestión de la
línea. La métrica total consiste en el total de saltos desde el router origen
hasta el router destino, con la limitación que 16 saltos se considera destino
inaccesible, esto limita el tamaño máximo de la red.
Temporizador
El temporizador nos indica el tiempo transcurrido desde que se ha recibido la
última actualización de esa ruta. RIP utiliza dos tiempos importantes, el tiempo
de actualización que se estable en 30 segundos, el tiempo de desactivación que
se establece en 180 segundos y el tiempo de borrado se establece en 300
segundos.
El tiempo de actualización se considera al tiempo máximo a transcurrir entre
el envío de los mensajes de actualización de los vecinos.
El tiempo de desactivación se considera al tiempo máximo que puede esperar un
router sin recibir actualizaciones de vecino, una vez pasado este tiempo, el
vecino que no ha enviado la actualización se considera que ha caído y con lo
cual el router no está activo en la red, se establece la métrica a valor 16, es
decir destino inalcanzable.
El tiempo de borrado implica que una vez transcurrido ese tiempo todas las
rutas de ese router supuestamente caído son eliminadas de la tabla de routing.
RFC 2453: RIP Versión 2
Diez años después de que se publicara la versión 1 de RIP se publicó la
versión 2, por G.Malkin de la compañía Bay Networks en Noviembre de 1998 en el
RFC 2453.
RIPv2 establece una serie de mejoras muy importantes con su antecesor que son
las siguientes:
- Autenticación para la transmisión de información de RIP entre vecinos.
- Utilización de mascaras de red, con lo que ya es posible utilizar VLSM .
- Utilización de máscaras de red en la elección del siguiente salto, lo cual
nos puede permitir la utilización de arquitecturas de red discontinuas.
- Envío de actualizaciones de tablas de RIP mediante la dirección de
multicast 224.0.0.9.
- Inclusión de RIPv2 en los bloques de información de gestión (MIB ).
Por supuesto además de estas mejoras RIPv2 nos permite la redistribución de
rutas externas aprendidas por otros protocolos de routing.
Pero RIPv2 aunque haya tenido una serie de mejoras muy importantes desde la
versión 1 del protocolo sigue teniendo una serie de carencias muy importantes
como:
- Limitación en el tamaño máximo de la red. Con RIPv2 sigue existiendo la
limitación de 15 saltos como tamaño máximo de la red, lo cual implica que no
nos permite la utilización de RIPv2 en redes de un tamaño más grande.
- Conteo a infinito, RIPv2 sigue sin solucionar el problema del conteo hasta
el infinito si se forman bucles, aunque existen técnicas externas al protocolo
como pueden ser la inversa envenenada y el horizonte dividido, técnicas
brevemente descritas por William Stallings en su libro “Comunicaciones y Redes
de Computadoras”, las cuales consisten básicamente en no anunciar una ruta por
el interfaz por el que se ha recibido en algún momento.
- Métricas estáticas que pueden ser cambiadas por el administrador de la
red, pero que no nos dan ninguna información del estado de la red.
- RIPv2 sólo permite al igual que su antecesor una ruta por cada destino, lo
cual implica la imposibilidad de realizar balanceos de carga por ejemplo, lo
que redunda en una pobre y poco óptima utilización de los enlaces.
RIPv2 es un protocolo que al igual que su antecesor genera muchísimo tráfico
al enviar toda la tabla de routing en cada actualización, con la carga de
tráfico que ello conlleva.
|
