Hay algunas áreas

María Pascual Navarro
INTER ROUTING
PROTOCOL.
CISCO'S
GATEWAY
IGRP
y
EIGRP
SYSTEM
IGRP :
IGRP es un protocolo de routing interno utilizado en TCP/IP y OSI. La versión original de IP fue diseñada y
desarrollada con éxito en 1986. Se considera un IGP (Interior Gateway Protocol) pero también ha sido
utilizado como un protocolo de routing externo para el routing inter-domain. IGRP utiliza el algoritmo de el
vector distancia. El concepto es que cada router no necesita conocer todas las rutas/enlaces de la red entera.
Cada router, informa acerca de los destinos y su distancia correspondiente. Cada router escuchando
información, ajusta las distancias y las propaga a los routers vecinos.
La información sobre la distancia en IGRP está representada como una combinación de ancho de banda
disponible, retardo, carga y fiabilidad del enlace. Esto permite conseguir rutas óptimas.
Hay algunas áreas en las que la descripción de este protocolo puede esperarse que sea diferente de la
implementación de Cisco. Estas áreas son:
- Cisco no implementa todavía múltiples tipos de servicio, no testea lo que depende de la cuenta de los
saltos. De cualquier modo hacen mantenimiento y propagan la información necesaria.
- Cisco tiene un número de controles administrativos, permitiendo filtros y modificaciones de varias clases
en la información de routing.
- Cisco proporciona varios caminos para definir las rutas por defecto
OBJETIVOS DE IGRP =
IGRP es un protocolo que asigna un número de routers para coordinar su routing. Sus metas son:
- routing estable incluso en redes muy grandes y complejas. No deben producirse bucles, incluso si son
transitorios.
- rápida respuesta a cambios en la topología de la red- pequeño overhead, IGRP no usa más ancho de banda que lo que necesita para su tarea.
- reparte el tráfico entre rutas paralelas diferentes cuando éstas son en términos generales igual de buenas.
- toma en cuenta la tasa de errores y el nivel de tráfico en diferentes caminos
- la capacidad de manejar múltiples "tipos de servicio" con un conjunto simple de información.
La actual implementación de IGRP maneja routing para TCP/IP. De todos modos, el diseño básico esta
propuesto para ser capaz de manejar una variedad de protocolos.
Durante los últimos años, el routing se ha convertido de repente en un problema más difícil al que solíamos.
Hace pocos años, protocolos como RIP eran suficientes, pero el crecimiento de la Internet, y la
descentralización del control de su estructura, ha resultado en un sistema de redes que está muy lejos de
nuestra capacidad de manejarlo. IGRP es una herramienta propuesta para atacar este problema.
Ninguna herramienta va a resolver todos los problemas de routing. Generalmente el problema del routing se
rompe en varias piezas. Protocolos como IGRP son llamados "protocolos de routing interno" (IGPs). Estan
propuestos para su uso en un conjunto simple de redes, bajo una dirección simple o una estrecha coordinación
de los directores. Estos conjuntos de redes son conectados por "protocolos de routing externo" (EGPs). Un
IGP está diseñado para mantener gran cantidad de detalles sobre la topología de la red. Su prioridad es fija en
producir rutas óptimas y respondiendo rápidamente a los cambios. Un EGP está destinado a proteger un
sistema de redes contra errores o una intencionada tergiversación por otros sistemas. Su prioridad está en los
controles de estabilidad y administrativos.
IGRP tiene algunas similitudes con viejos protocolos con Xerox's Routing Information Protocol, Berkeley's
RIP, and Dave Mill's Hello. Difiere con estos protocolos en que está diseñado para redes más grandes y
complejas.
Como estos viejos protocolos, IGRP es un protocolo basado en el algoritmo del vector distancia. Los routers
intercambian información de routing solo con sus routers vecinos. Esta información de routing contiene un
resumen de información sobre el resto de la red. Cada router solo necesita resolver parte del problema, y solo
tiene que recibir una porción de los datos totales.
La principal alternativa es una clase de algoritmos referidos a SPF(shortest-path first). Que estan basados en
la técnica de "flooding"(inundación), donde todo router debe mantener información del estado de toda
interface en todos los otros routers. Cada router independientemente resuelve el problema desde su pinto de
vista usando información de toda la red. En algunas circunstancias SPF puede ser capaz de responder a
cambios más rápidamente. Para prevenir los bucles, IGRP tiene que ignorar nuevos datos durante unos pocos
minutos después de fijar los cambios. Porque SPF tiene información directamente de cada uno de los routers,
es posible evitar estos bucles en el routing. Puede actuar con la nueva información inmediatamente. De todos
modos, SPF tiene más información que IGRP, tanto en las estructuras de datos internas y como en los
mensajes que intercambian los routers. Las implementaciones de SPF tienen más overhead que las
implementaciones de IGRP, en otras cosas son iguales.
EL PROBLEMA DEL ROUTING =
IGRP esta diseñado para usarse en routers que conectan distintas redes. Asumimos que loas redes usan la
tecnología basada en paquetes. De hecho los routers actúan como conmutadores de paquetes. Cuando un
equipo conectado a una red quiere enviar un paquete a otro equipo en una red diferente, dirige el paquete al
router. Si el destino se encuentra en una de las redes conectadas al router, el router mandará el paquete al
destino. Sino lo enviará a otro router que se encuentre cerca del destino. Los routers utilizan las tablas de rutas
para ayudarse a decidir qué hacer con el paquete.
La principal propuesta de IGRP es permitir a los routers construir y mantener las tablas de rutas.
RESUMEN DE IGRP =
IGRP es un protocolo que permite a los routers construir las tablas de routing a partir del intercambio de
información con otros routers. Un router comienza con entradas en sus tablas para todas las redes que están
directamente conectadas a él. En el caso más simple, el router encontrará una ruta que representa la mejor
para llegar a cada red. Un camino se caracteriza por el próximo router al que deben ser enviados los paquetes,
la interface de red que debe utilizarse e información de la métrica. La métrica es un conjunto de números que
determinan cuánto de buena es una ruta. Esto permite al router comparar rutas y elegir la mejor. Hay a
menudo casos donde hace sentir que se reparte el tráfico entre 2 o más rutas. IGRP hará esto cuando 2 o más
rutas sean igualmente buenas. El usuario puede configurarlo para repartir el tráfico cuando las rutas sean
igualmente buenas.
La métrica utilizada por IGRP incluye:
- el retardo de la topología (topological delay time)
- el ancho de banda ( bandwidth of the narrowest bandwidth segment of the path )
- la ocupación de la línea ( channel occupancy of the path )
- la fiabilidad ( reliability of the path )
El retardo de la topología es la cantidad de tiempo que pasa hasta llegar al destino a través de la ruta,
asumiendo una red no cargada. Desde luego hay un retardo adicional cuando la red está cargada.
De todos modos, la carga se mide por la ocupación del canal, no intentando medir el retraso actual.
El ancho de banda de la ruta es simplemente el ancho de banda en bits por segundo del enlace más lento de la
ruta.
La ocupación del canal indica cuánto de este ancho de banda está actualmente en uso. Éste es medido y
cambiará con la carga.
La fiabilidad indica la actual tasa de error. Es una fracción de los paquetes que llegan al destino sin error. Se
mide.
Aunque no son usadas como parte de la métrica, dos piezas de información adicionales son pasadas con ella:
la cuenta de saltos y la MTU (Maximun Transfer Unit). El contador de saltos es simplemente el número de
routers que el paquete debe atravesar para llegar al destino deseado. Y la MTU es el máximo tamaño de
paquete que puede ser enviado a lo largo de todo el trayecto sin fragmentación. Es la mínima de las MTUs de
todas las redes incluidas en la ruta al destino.
Basado en la información de la métrica, una simple "métrica compuesta" es calculada para la ruta. Esta
métrica compuesta combina el efecto de varios componentes métricos en un número simple que representa lo
buena que es la ruta. Esta métrica se usa para decidir la mejor ruta.
Cuando un router es por primera vez encendido, su tabla de routing es inicializada . Esto ,debe ser hecho por
un operador desde un terminal, o bien leyendo la información desde los archivos de configuración. Se
proporciona una descripción de cada red conectada al router, incluyendo el retraso a través del enlace (cuánto
le cuesta a un bit atravesar el enlace) y el ancho de banda del enlace
Periódicamente cada router emite broadcast su tabla entera de routing a los routers vecinos. Cuando un router
recibe esta información de otro router, compara la tabla con la suya. Cualquier nuevo destino o ruta es
añadida a la tabla de routing del router. Las rutas en el broadcast son comparadas con las rutas existentes. Si
una nueva ruta es mejor, reemplazará la que tenía por la nueva. La información en el broadcast es también
utilizada para actualizar la ocupación del canal y otra información sobre las rutas existentes.
El proceso básico de construcción de las tablas de routing por intercambio de información con los vecinos es
descrito por el algoritmo de Bellman - Ford.
En IGRP, el algoritmo general de Bellman-Ford es modificado en tres aspectos críticos:
1.- en lugar de una métrica simple, un vector de métricas es utilizado para caracterizar la ruta. Una simple
métrica compuesta puede ser computada a partir de este vector de acuerdo con la ecuación 1. El uso de un
vector permite al router acomodar diferentes tipos de servicio utilizando coeficientes distintos en la ecu.1.
2.- en lugar de escoger la ruta con la métrica más pequeña, el tráfico es repartido entre diferentes rutas, cuyas
métricas caen dentro de un determinado rango. Esto permite distintas rutas para ser utilizadas en paralelo,
proporcionando un ancho de banda efectivo mayor que con una solo ruta. Una varianza V es especificada por
el administrador de red. Todas las rutas con métrica mínima se mantienen. También, todas las rutas cuya
métrica es menor que VxM se mantienen. El tráfico es distribuido a través de múltiples rutas en una
proporción inversa a las métricas compuestas.
3.-diferentes características son introducidas para proporcionar estabilidad en situaciones donde la topología
está cambiando. Estas características han sido propuestas para prevenir bucles en la topología y el problema
de la cuenta a infinito. Las principales características de estabilidad son : "holddowns", "triggered updates",
"split horizon", and "poisoning".
El reparto de tráfico (punto 2.) entraña un peligro. La varianza V está designada para permitir al router usar
rutas paralelas de diferente velocidad. Si la varianza es 1, solo la mejor ruta será usada. Subiendo la varianza
podemos permitir al tráfico ser repartido entre la mejor ruta y otras rutas que están cerca de ser tan buena
como la mejor. Pero existe el peligro de que con una varianza suficiente grande, rutas que no solo son más
lentas sino que actualmente van en la dirección equivocada, se vuelvan válidas. No se envía tráfico a través de
caminos cuya métrica remota (la métrica calculada en el siguiente salto) sea mayor que la métrica calculada
en el router. En general, los administradores de sistema han llegado al acuerdo de utilizar una varianza de
valor 1, excepto en situaciones específicas donde se necesita usar rutas paralelas.
La mejor ruta es elegida según una métrica compuesta (composite metric) descrita a continuación :
[ (K1 /Be) + (K2 * Dc)] r
ecuación 1
donde:
K1,K2 : constantes  indican el peso asignado al ancho de banda y al delay. Dependerán del "tipo
de servicio"
Be : ancho de banda efectivo. Ancho de banda cuando la red no está cargada x (1 - ocupación del
canal)
Dc : delay
r : (reliability) fiabilidad  % de transmisiones que son recibidas con éxito en el siguinte salto
En principio, Dc (composite delay), puede ser definido como:
Dc = Ds + Dcir + Dt
Donde:
Ds =switching delay
Dcir =delay del circuito (retardo de propagación de 1 bit)
Dt =retardo de transmisión
La ruta que minimice esta métrica será la mejor.
Cuando existe más de una ruta para un mismo destino, el router puede enrutar los paquetes por más de una
ruta.
Se dan 2 ventajas por utilizar un vector de información métrica:
1.-proporciona capacidad de soportar múltiples "tipos de servicio" desde el mismo conjunto de datos.
2.-precisión
Cuando se utiliza una métrica simple, normalmente se trata como si fuera un delay. Cada enlace en el camino
es añadido a la métrica total. Si hay un enlace con un bajo ancho de banda, normalmente se representa por un
gran delay.
IGRP proporciona un sistema para la interconexión de redes de ordenadores que pueden de forma estable
manejar un grafo de la topología incluyendo bucles. El sistema mantiene mucha información métrica de rutas,
o sea, conoce los parámetros de ruta de todas las otras redes a las cuales algún router está conectado. El
tráfico puede ser distribuido sobre caminos paralelos y múltiples parámetros del camino pueden ser
simultáneamente computados sobre la red entera.
IGRP está definido para manejar múltiples tipos de servicio y múltiples protocolos. El "tipo de servicio" es
una especificación en un paquete de datos que modifica las rutas a ser evaluadas. Por ejemplo, en TCP/IP el
protocolo permite al paquete especificar la importancia relativa de un gran ancho de banda, bajo retardo, o
alta fiabilidad. Generalmente, las aplicaciones interactivas especificarán un bajo retardo y las aplicaciones de
transferencia especificarán un gran ancho de banda. Estos requerimientos determinan los valores de K1 y K2
que son utilizados en la ecuación 1. Cada combinación de especificaciones en el paquete que va a ser
soportada se refiere a un "tipo de servicio". Para cada tipo de servicio, un conjunto de parámetros K1 y K2
puede ser elegido. Una tabla de routing es mantenida para cada tipo de servicio. Esto se hace porque las rutas
son elegidas y ordenadas de acuerdo con la métrica compuesta definida por la ecuación 1. Esto es diferente
para cada tipo de servicio. La información procedente de todas estas tablas de routing es combinada para
producir mensajes de actualización de la información de routing que son intercambiados por los routers.
EJEMPLO:
El router S está conectado a las rutas 2 y 3 mediante las interfaces correspondientes. Inicialmente, el router 2
solo sabe que puede alcanzar cualquier destino en las redes 2 y 3. Todos los routers son programados para
periódicamente transmitir a sus vecinos tanto su propia información como la recogida de otros routers.
El router S recibiría actualizaciones de los routers R y T, y aprenderá que puede alcanzar equipos en la red 1 a
través del router R y equipos de la red 4 a través del router T. Cuando el router S envía su tabla entera de
routing, en el próximo ciclo, el router T aprenderá que puede llegra a la red 1 a través del router S.
red 1
red 2
red 3
red 4
128.6.5
128.6.4
128.6.21
128.121
===== ======================= ========== ================
| |
|
| |
| |
|
____|____|_ _____|____ ___|____|__ __|____|____ ___|________
128.6.4.2 128.6.4.3 128.6.4.1 128.6.21.1 128.121.50.2
128.6.5.1
128.6.21.2 128.121.50.1
__________ __________ __________ ____________ ____________
gateway R computer A gateway S gateway T
computer B
Fig 1. Un ejemplo de red
Cada router computa una métrica compuesta para determinar lo buenos que son los caminos a un destino.
En la siguiente figura (2), para un destino en la red 6, el router A computaría las funciones métricas para 2
caminos, via el router B y C. Notar que los caminos son definidos solamente por el próximo salto. Hay 3
posibles rutas desde A a la red 6:
-
directamente a B
a C y luego a B
a C y luego a D
El router A necesita elegir entre las 2 rutas que incluyen a C. La tabla de routing en A tiene una única entrada
representando el camino a C. Su métrica representa el mejor camino para alcanzar el destino a través de C. Si
A envía un paquete a C, éste decidirá si usa B o D.
________ Network 1
|
gw A --nw2-- gw C
|
/|
|
/ |
nw3 nw4 nw5
| /
|
| /
|
gw B
gw D
_|_____________|____ network 6
Fig 2. Ejemplo de caminos alternativos
Aquí, mostramos un ejemplo de cómo podría ser la tabla de routing de S. Notar que los componentes
individuales del vector métrico no son mostrados, por simplicidad. Para construir la tabla a partir de la
información de los vecinos se utiliza, como ya dijimos, el algoritmo de Bellman-Ford.
network 1
network 2
network 3
network 4
network 5
network 6
interface next gateway
metric
------------ ----------------- ----------nw 1
none
directly connected
NW 2
none
directly connected
NW 3
none
directly connected
NW 2
C
1270
NW 3
B
1180
NW 2
C
1270
NW 3
B
2130
NW 2
C
2040
NW 3
B
1180
Fig 3. Un ejemplo de tabla de routing
CARACTERÍSTICAS DE LA ESTABILIDAD =
Estas características son definidas para prevenir a los routers elegir rutas erróneas. Como se describe en el
RFC 1058, esto puede ocurrir cuando una ruta no puede ser utilizada por un fallo en un router o en la red. En
principio, son los routers vecinos los que detectan el fallo. Entonces éstos envían las actualizaciones
necesarias que muestran la vieja ruta como inutilizada. Sin embargo, es posible que las actualizaciones no
alcancen algunas partes de la totalidad de la red, o que sean retrasadas en determinadas routers. Un router que
todavía piensa que la vieja ruta es buena puede continuar propagando esta información, tal que vuelve a
entrar la ruta fallida en el sistema. Finalmente, esta información será propagada a través de la red y volverá al
router que la reinyectó. El resultado es una ruta circular.
De hecho, hay cierta redundancia en los contadores de medida. En principio, holddowns y triggered updates
deberían ser suficientes para prevenir las rutas erróneas. Sin embargo, en la práctica, los fallos de
comunicaciones de varios tipos pueden hacer que éstos sean insuficientes. Split horizon y route poisoning han
sido ideadas para evitar los bucles en cualquier caso.
Normalmente, las nuevas tablas de rutas son enviadas a los routers vecinos regularmente (cada 90 seg. Por
defecto, aunque puede ser fijado por el administrador del sistema).
Un triggered update es una nueva tabla de routing que es enviada inmediatamente, en respuesta a algún
cambio. El cambio más importante es el de una ruta. Esto puede ocurrir porque un timeout ha expirado
(probablemente un router vecino o una línea ha caído), o porque un mensaje de actualización del siguiente
router en el camino muestra que el camino no es el más largo de los utilizables. Cuando un router G detecta
que una ruta no es la más larga, dispara una actualización inmediatamente. Esta actualización mostrará la ruta
como inutilizada. Considerando lo que ocurre cuando esta actualización llega a los routers vecinos, si la ruta
del vecino apunta a G, el vecino de borrar la ruta. Esto hace que el vecino dispare una actualización, etc.
Así, un fallo disparará una ola (serie) de mensajes de actualización, que se propagarán a través de la parte de
la red en cuyas rutas había un fallo en un router o en una red.
Triggered updates serían suficientes si pudiéramos garantizar que la ola de actualizaciones alcanzase todo
router implicado inmediatamente. Sin embargo, hay dos problemas:
1.- los paquetes que contienen el mensaje de actualización pueden ser descartados o corrompidos por
algún enlace en la red
2.- las triggered updates no ocurren instantáneamente
Los Holddowns se han definido para solucionar estos problemas. Cuando una ruta es eliminada, no se
aceptará una nueva ruta para el mismo destino hasta pasado un tiempo. Esto da tiempo a las triggred updates
para llegar al resto de routers, así estamos seguros de que cualquier nueva ruta que tengamos no sea algún
router reinsertando al viejo. El periodo del holddown debe ser suficientemente largo para permitir la ola de
triggered updates a través de la red. Además suele incluir, una pareja de ciclos regulares broadcast, para
manejar los paquetes descartados. Consideremos que pasa si, un triggered update es descartado o corrompido,
el router que emitió esa actualización emitirá otra actualización en la próxima actualización. Esto empezará la
ola de triggered updates en los vecinos que no dieron con la ola inicial.
La combinación de triggered updates y holddowns debería ser suficiente para eliminar las rutas inutilizadas y
prevenir que sean reinsertadas. Sin embargo, algunas precauciones adicionales se han desarrollado, éstas son
el split horizon y el route poisoning.
Split horizon aparece de la observación de que nunca siente que envía una ruta de vuelta en la dirección de
donde viene. Consideremos la siguiente situación:
network 1
network 2
--------------------X----------------------------X
router A
router B
El router A le dirá a B que tiene una ruta a la red1. Cuando B envíe actualizaciones a A, nunca se hará
mención a la red1. Como A está más cerca de red1, no se debe considerar ir vía B. La regla del Split horizon
dice que un mensaje de actualización independiente debe ser generado para cada vecino. La actualización
para un vecino dado debería omitir las rutas que apunten e este vecino. Esto previene bucles entre routers
vecinos. Supongamos que la interface de A con la red1 falla, sin la regla de split horizon, B diría a A que
puede llegar a red1. Ya no tiene una ruta real, A podría escoger esta ruta. En este caso, ambos A y B tienen
ambos rutas a 1. Pero A apuntaría a B y B apuntaría a A. Desde luego, los triggered updates y holddowns
deberían prevenir que esto ocurriera. Pero no hay motivo para mandar información de vuelta al lugar del que
vino. Además de su papel en la prevención de bucles, el split horizon mantiene bajo el tamaño de los
mensajes de actualización.
Split horizon debería evitar los bucles con routers vecinos.
Route poisoning es propuesto para romper bucles más grandes. Su papel es que cuando una actualización
muestre la métrica para una ruta existente y tenga que aumentar suficientemente, hay un bucle. La ruta
debería ser eliminada y aplicar holddown. Actualmente la regla es, una ruta se elimina si la métrica compuesta
aumenta más de un factor de 1.1. El factor de 1.1 es simplemente un heurístico.
DESHABILITAR HOLDDOWNS =
Cisco proporciona la opción de deshabilitar los holddowns. La desventaja de los holddowns es que éstos
retrasan la adopción de la nueva ruta cuando la vieja ruta ha fallado. Con parámetros por defecto,esto puede
taardar varios minutos antes de que el router adopte la nueva ruta después del cambio. Sin embargo, por las
razones antes explicadas, no es seguro evitar los holddowns. El resultado sería una cuenta a infinito. Se
presupone, pero no se puede asegurar, que con una versión más fuerte de route poisoning, los holddowns no
son necesarios para evitar la cuenta a infinito, se podrían deshabilitar.
Esta implementación más fuerte del route poisoning se basa en un contador de saltos. Si el contador de saltos
para un camino aumenta, la ruta se elimina. Eliminará obviamente las rutas que son todavía válidas. Si algo en
la red cambia, como que el camino vaya ahora por un router más, el contador de saltos aumentará. En este
caso, la ruta es todavía válida. Sin embargo, no hay una forma completamente segura de distinguir este caso
de los bucles (cuenta a infinito). La aproximación más segura es eliminar la ruta siempre que el contador de
saltos aumente. Si la ruta es todavía válida, será reinstalada en la próxima actualización, y esto causará un
triggered update que reinstalará la ruta en el sistema.
En general, los algoritmos de vector distancia adoptan nuevas rutas fácilmente. El problema es solamente
eliminar las viejas del sistema.
PROCESO DE ACTUALIZACIÓN =
Un router puede procesar datos de diferentes protocolos. Cada protocolo tiene diferentes estructuras de
direccionamiento y de formato de paquete, por lo que la implementación para cada uno será también
diferente. La principal diferencia de un protocolo a otro será el formato del paquete de actualización de
routing que debe ser diseñado para ser compatible con el protocolo utilizado.
La definición de destino puede variar de un protocolo a otro. El método que describiremos aquí puede ser
usado para enrutar a host individuales, redes o a esquemas de direcciones jerárquicos más complejos. El tipo
de routing utilizado dependerá de la estructura de direcciones del protocolo. La actual implementación de
TCP/IP soporta solamente routing a redes IP. Así, el destino significa una red IP o un número de subred.
Al inicio del código del programa, será necesario definir los protocolos aceptables y los parámetros que
describen cada interface.
Los datos de entrada son:
- redes a las que el router está conectado
- unloaded bandwidth de cada red
- retardo topológico
- reliability
- channel occupancy de cada red
- MTU de cada red
Los tres primeros elementos son mas o menos permanentes. No dependen de la carga. Pueden ser establecidos
desde un fichero de configuración o directamente como entrada. Notar que IGRP no usa delay medido, pues
resultaría muy difícil mantener un routing estable. Hay dos parámetros de medida, reliability (basada en la
tasa de error reportada por la interface de red hardware o firmware) y channel occupancy.
El algoritmo de routing también requiere el valor de varios parámetros: valor de los timers, varianza (en Cisco
siempre vale 1) ,holddowns (si están o no habilitados) .......
Una vez la información inicial ha sido introducida, las operaciones en el router se disparan por eventos,
llegada de un paquete de datos por una interface, o expiración de un timer.
- cuando un paquete llega, se procesa según la siguiente figura 1 (las figuras aparecen después).
- cuando un paquete es aceptado por un router, es analizado según el protocolo específico.
Si es un paquete de actualización de routing se procesa según la figura 2.
- Muestra los eventos disparados por el timer. El timer está puesto tal que genere una interrupción por
segundo. Cuando se produce una interrupción, se ejecuta la figura 3.
- Subrutina de actualización del routing. Figura 3.
- Muestra los detalles de computación de la métrica, figura 4.
Hay 4 constantes de tiempo críticas que controlan la propagación de la ruta y la expiración. Estas constantes
las fija el administrador del sistema. Son:
 broadcast time : las actualizaciones son broadcast por todos los routers en todas las interfaces
conectadas



invalid time : si no se ha recibido la actualización para un camino dado durante este tiempo, se
produce timeout.
Hold time :cuando un destino se ha vuelto desconocido ( o la métrica ha aumentado suficiente
para causar poisoning) el destino va a holddowns. Durante este estado, ningún nuevo camino
será aceptado para el mismo destino durante este período de tiempo.
Flush time :si no se ha recibido la actualización para un camino dado durante este tiempo, la
entrada para él, se elimina de la tabla de routing.
Notar que un mensaje de actualización de routing IGRP (update message )tiene tres partes:
- interior: para rutas a subnets.
- Sistema (que significa ,este "sistema autónomo"), y no interior.
- exterior
La sección interior, no incluye toda la información de la subred. Solo las subredes de una red son incluidas.
Esto es, la red asociada con las direcciones a las cuales la actualización está siendo enviada. Normalmente las
actualizaciones son broadcast en cada interface,. Las redes más grandes (no subredes ) se colocan en la
sección de sistema del mensaje de actualización, amenos que éstas sean marcadas como exteriores.
Una red será marcada como exterior si fue instruida por otro router y la información le llega de la sección
exterior del mensaje de actualización. La implementación de Cisco permite al administrador del sistema
declarar determinadas redes como exteriores. Las rutas exteriores son candidatas por defecto. Hay rutas que
van a o a través de routers que son considerados apropiados por defecto, para ser usados cuando no hay una
ruta explícita para un determinado destino.. La implementación de Cisco elige una ruta por defecto
seleccionando la ruta exterior con la métrica menor.
1.- ROUTING DE PAQUETES :
Este proceso consta de una serie de pasos:
A.-este proceso utiliza la lista de protocolos soportados y la información sobre las interfaces registradas
cuando el router es inicializado. Los detalles de proceso de los paquetes dependen del protocolo utilizado por
el paquete, asimismo el contenido del paquete está especificado en el protocolo.
B.y C.-Las especificaciones del protocolo incluyen procedimientos para determinar destino del paquete,
compara el destino con las direcciones propias del router o determina si éste es broadcast.
D.-Test de búsqueda de los destinos listados en la tabla de routing. Este test se satisface si hay una entrada en
la tabla de routing para ese destino dado, y el destino lleva asociado al menos una ruta válida.
E.-Computa la ruta a utilizar. Las rutas cuya métrica compuesta remota no es menor que su métrica, no son
consideradas. Si más de un camino es aceptable, éstos caminos serán utilizados alternativamente, round-robin.
La frecuencia con la que un camino es usado es inversamente proporcional a su métrica
-----Figura 1: Processing incoming packets----Data packet arrives using interface I
A Determine protocol used by packet
If protocol is not supported then discard packet
B If destination address matches any of gateway's addresses or the broadcast address then
process packet in protocol-specific way
C If destination is on a directly-connected network then send packet direct to the destination,
using the encapsulation appropriate to the protocol and link type
D If there are no paths to the destination in the routing table, or all paths are upstream then send
protocol-specific error message and discard the packet
E Choose the next path to use. If there are more than one, alternate round-robin with frequency
proportional to inverse of composite metric.
Get next hop from path chosen in previous step.
Send packet to next hop, using encapsulation appropriate to protocol and data link type.
2.- RECEPCIÓN DE ACTUALIZACIONES DEL ROUTING:
Cómo las actualizaciones son recibidas de los routers vecinos. Las actualizaciones consisten en una lista de
entradas, cada una de las cuales de información de un destino. Puede haber más de una entrada para el mismo
destino en una sola actualización, para acomodar múltiples tipos de servicio. Cada una de estas entradas es
procesada individualmente.
El proceso de la figura 2, debe ser repetido una vez por cada tipo de servicio soportado por el router (bucle),
utilizando la información asociada a este tipo de servicio. Nota: la actual implementación de IGRP no soporta
múltiples tipos de servicio, por lo que este bucle no se implementa.
Pasos:
A.- Se realizan tests de aceptabilidad al camino. Las actualizaciones son rechazadas si el destino al que se
refieren, está en holddown, es decir, el tiempo de expiración del holddown no es cero y mayor que el tiempo
actual.
B.- La tabla de routing es analizada para ver qué entrada describe un camino que ya es conocido. Un camino
en la tabla de routing está definido por el destino con el que está asociado, el próximo salto en la lista como
parte del camino, la interface de salida a ser utilizada por el camino, y la información de la fuente (S) (la
dirección de donde viene la actualización). La entrada del paquete de actualización describe un camino cuyo
destino está listado en la entrada, cuya interface de salida en la interface por la que llega la actualización, y
cuyo próximo salto y la información de la fuente son la dirección del router que envió la actualización.
H. y T.- El proceso de actualización descrito en la figura 4 es programado. Este proceso actualizará después
de que, este proceso (figura 2) haya acabado. El proceso de actualización solo ocurrirá una vez.
K.- Se realiza si el destino descrito por la entrada actual en el paquete de actualización ya existe en la tabla de
routing. K compara la nueva métrica computada a partir de los datos del paquete de actualización con la mejor
métrica para el destino La mejor métrica no es recalculada en este momento, por lo que si el camino que está
siendo considerado está ya en la tabla de routing, este test puede comparar la nueva y la vieja métrica para el
mismo camino.
L.- Es ejecutado para los caminos que son peores que la mejor métrica existente. Incluye nuevos caminos, el
peor de los existentes y los caminos existentes cuya métrica ha aumentado. L testea cual de los nuevos
caminos es aceptable. Este test implementa, un test para determinar cual de los nuevos caminos es suficiente
bueno para mantenerlo, y también route poisoning. Para ser aceptables, el valor del delay no debe indicar un
destino desconocido, y la métrica debe ser aceptable (se comparará con las métricas del resto de caminos al
mismo destino). Siendo M la mínima de estas métricas, el nuevo camino es aceptable si es VxM, donde V es
la varianza (introducida cuando el router es inicializado, siempre vale 1 en Cisco)
V.- Se realiza cuando la nueva información para el camino indica que la métrica disminuirá. Las métricas de
todos los caminos al destino D se comparan. En esta comparación, la nueva métrica para P es utilizada,
mejor que una que parezca en la tabla de routing. La métrica mínima M es calculada. Entonces todos los
caminos a D son examinados de nuevo. Si, la métrica para cualquier camino es mayor que VxM, ese camino
es eliminado.
--------Figura 2: Processing incoming routing updates--------Routing update arrives from source S
For each type of service supported by gateway Use routing data associated with this type of
service
For each destination D shown in update
A If D is unacceptable or in holddown then ignore this entry and continue loop with next
destination D
B Compute metrics for path P to D via S (see Fig 8)
If destination D is not already in the routing table then Begin
Add path P to the routing table, setting last update times for P and D to current time.
H Trigger an update
Set composite metric for D and P to new composite metric computed in step B.
End
Else begin (dest. D is already in routing table)
K Compare the new composite metric for P with best existing metric for D.
New > old:
L If D is shown as unreachable in the update, or holddowns are enabled and the new composite
metric > (the existing metric for D) * V [use 1.1 instead of V if V = 1, as it is as of Cisco release
8.2] O or holddowns are disabled and P has a new hop count > old hop count then Begin
Remove P from routing table if present
If P was the last route to D then Unless holddowns are disabled Set holddown time for D to
current time + holddown time T and Trigger an update
End
else Begin
Compute new best composite metric for D
Put the new metric information into the entry for P in the routing table
Add path P to the routing table if it was not present.
Set last update times for P and D to current time.
End
New <= OLD:
V Set composite metric for D and P to new composite metric computed in step B.
If any other paths to D are now outside the variance, remove them.
Put the new metric information into the entry for P in the routing table
Set last update times for P and D to current time.
End
End of for
End of for
3.- PERIODIC PROCESSING :
Este proceso se dispara una vez por segundo. Examina varios timers en la tabla de routing, para determinar si
alguno ha expirado.
Pasos:
U.- Se activa el proceso descrito en la figura 4
R. y S.- Son necesarios porque las métricas almacenadas en la tabla de routing dependen de la ocupación del
canal (channel occupancy). Periódicamente, la ocupación del canal es recalculada, haciendo media del tráfico
medido a través de la interface. Si el último valor calculado difiere del existente, todas las métricas de esta
interface deben ser ajustadas. Todos los caminos en la tabla de rutas son examinodos. Todo camino cuyo
próximo salto utilice la interface "I" recalcula su métrica. Esto se hace de acuerdo con la ecuación 1, usando
como ocupación del canal el máximo valor almacenado en la tabla de routing y el último valor calculado de
ocupación del canal de la interface.
---------Figura 3 : Periodic processing---------Process is activated by regular clock, e.g. once per second
For each path P in the routing table (except directly connected interfaces)
If current time < P'S LAST UPDATE TIME + INVALID TIME THEN CONTINUE WITH
THE NEXT PATH P
Remove P from routing table
If P was the last route to D then Set metric for D to inaccessible Unless holddowns are disabled,
Start holddown timer for D and Trigger an update
else Recompute the best metric for D
End of for
For each destination D in the routing table
If D's metric is inaccessible then Begin
Clear all paths to D
If current time >= D's last update time + flush time then Remove entry for D
End
End of for
For each network interface I attached to the gateway
R Recompute channel occupancy and error rate
S If channel occupancy or error rate has changed, then recompute metrics
End of for
At intervals of broadcast time
U Trigger update
4.- GENERACIÓN DE LOS MENSAJES DE ACTUALIZACIÓN :
Aquí se describe cómo el router genera las actualizaciones para ser enviadas a los routers vecinos. Un
mensaje independiente es enviado por cada interface del router.
J.- El mensaje es enviado a todos los routers que son accesibles a través de la interface. Se envía normalmente
como un mensaje broadcast. Si la tecnología de red o el protocolo no permite broadcast, puede ser necesario
enviar el mensaje individualmente a cada router.
G.- El mensaje se construye añadiendo una entrada por cada destino en la tabla de routing. El destino/ la
información sobre el camino asociada con cada tipo de servicio, debe ser utilizada. En el peor caso, una
entrada nueva es añadida a la actualización para cada destino para cada tipo de servicio. De todos modos,
antes de añadir una entrada al mensaje en el paso G., las entradas ya añadidas son examinadas. Si una nueva
entrada está ya presente en el mensaje de actualización no se añade otra vez. Una nueva entrada duplica la
que ya existe cuando los destinos y los routers siguientes (próximo salto) son los mismos.
El pseudo código omite el hecho de que los mensajes de actualización IGRP tienen 3 partes: interior, sistema
y exterior. Así, hay actualmente 3 bucles según el destino.
El primero incluye solo subnets de una red.
El segundo incluye todas las grandes redes (no subnets) no marcadas como exterior.
El tercero incluye todas las grandes redes, no exteriores.
E.- Este paso implementa el test de Split horizon. En le caso normal, este test falla en rutas cuyo mejor
camino salga a la misma interface por la que la actualización está siendo enviada. Sin embargo, si la
actualización está siendo enviada a un destino determinado, (Ej, en respuesta a un IGRP request desde otro
router, o como parte de point-to-point IGRP), split horizon falla solo si el mejor camino viene desde este
destino (su información de fuente es la misma que la del destino) y su interface de salida es la misma por la
que viene el request.
-------Figura 4 : Generate update messages----------Process is caused by "trigger update"
For each network interface I attached to the gateway
Create empty update message
For each type of service S supported
Use path/destination data for S
For each destination D
E If any paths to D have a next hop reached through I then continue with the next destination
If any paths to D with minimal composite metric are already in the update message then continue
with the next destination
G Create an entry for D in the update message, using metric information from a path with minimal
composite metric (see Fig. 8)
End of for
End of for
J If there are any entries in the update message then send it out interface I
End of for
5.-COMPUTACIÓN DE LA INFORMACIÓN MÉTRICA :
Aquí se describe el procedimiento para computar las métricas y la cuenta de saltos con la llegada de una
actualización en el routing.
La entrada a esta función es una entrada para cada destino específico en un paquete de actualización de
routing.
La salida es un vector de métricas que puede ser usado para computar la métrica compuesta y la cuenta de
saltos.
Si este camino es añadido a la tabla de routing, el vector entero de métricas se coloca en la tabla. Los
parámetros de la interface usados en las definiciones siguientes son fijados cuando el router es inicializado,
para la interface por la que llega la actualización de routing, espera que la ocupación del canal y la reliability
estén basadas en una media del tráfico medido a través de la interface.
Delay = delay from packet + interface topological delay
Bandwidth = max ( bandwidth from packet, interface bandwidth)
Reliability = min ( reliability from packet, interface reliability)
Channel occupancy = max ( channel occupancy from packet, interface channel occupancy)
Lo siguiente no forma parte del vector métrico pero si se mantiene en la tabla de routing como características
del camino:
Hop count = hop count from packet
MTU = min ( MTU from packet, interface MTU)
Remote composite metric = calculada con la ecuación 1, usando los valores del paquete
Composite metric =calculados con la ecuación 1, usando los valores métricos calculados según se
describe en esta sección.
Esta sección describe el procedimiento para computar las métricas y el hop count para las actualizaciones de
routing que deben ser enviadas.
La entrada está basada en un determinado camino a un destino. Si hay más de un camino a ese destino, se
elige el camino cuya métrica sea menor.
--------Figura 5.-------If destination is inaccessible, this is indicated by using a specific
value in the delay field. This value is chosen to be larger
than the largest valid delay. For the IP implementation this is
all ones in a 24-bit field.
If destination is directly reachable through one of the interfaces, use the delay, bandwidth,
reliability, and channel occupancy of the interface. Set hop count to 0.
Otherwise, use the vector of metrics associated with the path in the routing table. Add one to
the hop count from the path in the routing table.
A continuación aparece cómo se obtiene la métrica compuesta que es utilizada actualmente en la versión 8.0
de Cisco:
metric = [K1*bandwidth + (K2*bandwidth)/(256 - load) + K3*delay] *
[K5/(reliability + K4)]
If K5 == 0, the reliability term is not included.
The default version of IGRP has K1 == K3 == 1, K2 == K4 == K5 == 0
DETALLES DE LA IMPLEMENTACIÓN IP :
A continuación daré una breve descripción del formato de paquete usado por el IGRP de Cisco. IGRP es
enviado utilizando datagramas IP con protocolo IP 9 (IGP). El paquete empieza con una cabecera, que
empieza justo después de la cabecera IP.
Cabecera:
unsigned version: 4; /* protocol version number */
unsigned opcode: 4; /* opcode */
uchar edition;
/* edition number */
ushort asystem;
/* autonomous system number */
ushort ninterior; /* number of subnets in local net */
ushort nsystem;
/* number of networks in AS */
ushort nexterior; /* number of networks outside AS */
ushort checksum;
/* checksum of IGRP header and data */
Para los mensajes de actualización, la información de routing sigue inmediatamente a la cabecera.
El número de versión es actualmente 1.
El campo opcode indica el tipo del mensaje; de "update" (actualización) o de request (petición).
Edition es el número de serie que aumente si existe un cambio en la tabla de routing. Permite a los routers
evitar procesar actualizaciones que contengan información que ellos ya tienen.( Actualmente no
implementado. Se genera correctamente pero se ignora en la entrada.)
Asystem es número de sistema autónomo. En la implementación de Cisco un router puede participar en más
de un sistema autónomo. Cada sistema tiene su propio protocolo IGRP. Hay tablas de rutas separadas para
cada sistema autónomo. Las rutas que llegan via IGRP desde un sistema autónomo son enviadas solo en
actualizaciones para este AS. Esto permite al router seleccionar que conjunto de tablas de rutas utilizará para
procesar este mensaje. Si el router recibe un mensaje IGRP para un AS para el que no está configurado, lo
ignora.
Ninterior, nsystem , y nexterior indican el número de entradas en cada una de estas tres secciones del mensaje
de actualización.
Checksum es un checksum IP, computado utilizando el mismo algoritmo de checksum que en el checksum de
UDP. El checksum se calcula en la cabecera IGRP y cualquier información de routing que la siga. El
checksum no incluye la cabecera IP, no hay ninguna cabecera virtual como en TCP y UDP.
REQUEST : Una IGRP request, pregunta cuál es el receptor al que tiene que enviar su tabla de routing. El
mensaje request solo incluye la cabecera. Solamente los campos, version, opcode, y asystem son usados. El
resto son puestos a cero. El receptor estará esperando enviar un mensaje update al que le pregunte.
UPDATE : Un IGRP update contiene la cabecera, seguida inmediatamente por entradas de routing. Con la
actual estructura de declaraciones, se permite 104 entradas. Si se necesitan más entradas, varios mensajes
update son enviados. Los mensajes son procesados entrada a entrada.
Estructura de una entrada de routing:
uchar number[3];
uchar delay[3];
/* 3 significant octets of IP address */
/* delay, in tens of microseconds */
uchar bandwidth[3]; /* bandwidth, in units of 1 Kbit/sec */
uchar mtu[2];
/* MTU, in octets */
uchar reliability; /* percent packets successfully tx/rx */
uchar load;
/* percent of channel occupied */
uchar hopcount;
/* hop count */
Number designa el destino. Es una dirección IP. Para ahorrar espacio, solo se ponen los 3 primeros bytes de la
dirección IP, excepto en la sección interior, donde son los 3 últimos bytes. Para el sistema y las rutas
exteriores, no son posibles las subnets, así que los bytes más bajos son siempre cero. Las rutas interiores son
siempre subnets de una red conocida, así que el primer byte del número de red se suprime.
Delay se cuenta en unidades de 10 microsegundos. Con un rango de 10 microsegundos hasta 168 segundos.
Bandwidth es la inversa del ancho de banda en bits por segundo, escalado por un factor de 1.0e10. El rango va
de 1200 BPS a 10Gbps. O sea, si el ancho de banda es N Kbps, el número usado es 10000000/N.
MTU es en bytes.
Reliability es dada como una fracción de 255. Esto es, 255 es 100%.
Load es dada como una fracción de 255.
Hopcount es una cuenta simple.
María Pascual Navarro
EIGRP :
ENHANCED
IGRP
EIGRP es una versión más extendida de IGRP. También está basado en la tecnología del vector distancia Las
propiedades de convergencia y la eficiencia de las operaciones de este protocolo han mejorado
significativamente.
El algoritmo DUAL Distributed Update Algirithm es el algoritmo usado para obtener la computación de una
ruta libre de bucles. Permite a todos los routers incluidos en un cambio en la topología sincronizarse al
mismo tiempo. Los routers no afectados por este cambio, no están incluidos en la re-computación.
EIGRP es extendido para ser un protocolo de capa de red independiente, permitiendo de este modo, a DUAL
soportar otra serie de protocolos.
¿ CÓMO FUNCIONA EIGRP ?
EIGRP tiene 4 componentes básicos:
- neighbor discovery / recovery :es el proceso que los routers usan para dinámicamente aprender
de los otros routers ,de sus redes directamente relacionadas. Los routers deben también averiguar
cuando sus vecinos se vuelven no accesibles o no operativos. Este proceso se lleva acabo con
reducido overhead mediante el envío periódico de paquetes HELLO. Tan pronto estos paquetes
sean recibidos, un router podrá determinar si un vecino está operativo. Una vez se sabe esto, los
routers vecinos podrán intercambiar información.
-
-
reliable transport protocol :es el responsable de garantizar, el envío ordenado de paquetes
EIGRP a todos los vecinos. Soporta tráfico multicast y unicast. Algunos paquetes EIGRP deben
ser transmitidos de forma segura y otros no. Por eficiencia, la fiabilidad se proporciona solo si es
necesario.
DUAL finite state machine : engloba el proceso de decisión de la computación de todas las rutas.
La información de la distancia, la métrica, es usada por DUAL para seleccionar los caminos
eficientes, libre de bucles. DUAL selecciona las rutas a ser introducidas en la tabla de routing
basadas en los posibles sucesores. Un sucesor es un router vecino usado para enviar paquetes
que tiene un camino de coste mínimo a un destino que garantiza no ser parte de un bucle de
routing. Cuando no hay sucesores posibles, pero hay vecinos anunciando el destino, debe
producirse una recomputación . Este es el proceso por el que un nuevo sucesor es definido. La
suma del tiempo que le toma recalcular la ruta afecta al tiempo de convergencia. Cuando ocurre
un cambio en la topología, DUAL testea a los posibles sucesores. Si los hay, tratará de evitar una
recomputación innecesaria.
-
Protocol dependent modules: son responsables de la capa de red, son requerimientos específicos
del protocolo. Por ejemplo, el módulo IP-EIGRP es el responsable de enviar y recibir paquetes
EIGRP encapsulados en IP. IP-EIGRP es responsable de analizar los paquetes EIGRP y de
informar a DUAL de la nueva información recibida. IP-EIGRP pide a DUAL que tomo
decisiones de routing. IP-EIGRP es responsable de redistribuir las rutas aprendidas de otros
protocolos de routing IP.
CONCEPTOS EIGRP :
-
Neighbor table : cada router mantiene el estado de sus routers vecinos. Cuando se descubren
nuevos vecinos, se registra la dirección y la interface del vecino, almacenándola en su estructura
de datos. Hay una neighbor table para cada módulo dependiente del protocolo. Cuando un
vecino envía un paquete Hello, informa de un Holdtime. Si un paquete de Hello no es oído
dentro del holdtime, el holdtime expira. Cuando el holdtime expira , DUAL es informado del
cambio en la topología.
Una entrada en esta tabla, incluye la información requerida por un mecanismo de transporte
seguro. Los números de secuencia son utilizados para proporcionar conocimientos con los
paquetes de datos. El último número de secuencia recibido de un vecino es registrado, para
detectar los paquetes fuera de orden. Una lista de transmisión es utilizada para encolar paquetes
para una posible retransmisión. Los timers round trip se mantienen en la estructura de datos del
vecino para estimar un intervalo óptimo de retransmisión.
-
Topology table: contiene todos los destinos anunciados por los routers vecinos. Asociado con
cada entrada está la dirección de destino y la lista de vecinos que han anunciado este destino.
Para cada vecino, la métrica anunciada es registrada. Esto es, la métrica que el vecino almacena
en su tabla de routing. Si el vecino anuncia este destino, debe usar la ruta para enviar los
paquetes. Esto es una regla importante que debe seguir el protocolo del vector distancia.
También asociado con el destino está la métrica que el router utiliza alcanzar el destino. Esto es
la suma de la mejor de las métricas anunciadas por todos los vecinos mas el costo del enlace al
mejor vecino. Esta métrica la usa el router en la tabla de routing y anunciar a otros routers.
-
Feasible successors: una entrada de destino es movida de la topology table a la tabla de routing
cuando hay un posible sucesor. Todos los caminos de coste mínimo a un destino forman un
conjunto. Desde este conjunto, los vecinos que tengan una métrica menor que la métrica actual
de la tabla de routing son considerados feasible successors (sucesores posibles). Son vistos por
el router como vecinos por debajo con respecto al destino. Estos vecinos y las métricas asociadas
son puestos en la tabla enviada. Cuando un vecino cambia la métrica éste ha sido avisado o un
cambio topológico se ha producido en la red, el conjunto de posibles sucesores pueden tener que
volver a ser evaluados. .
-
Route State: una entrada en la topology table para un destino puede tener uno de dos estados.
Una ruta se considera en estado 'pasivo' cuando un router no está realizando un recomputación
de la misma. Una ruta está en estado 'activo', cuando un router está siendo sometida a una
recomputación. Si hay siempre posibles sucesores, una ruta nunca entra en un estado activo y
evita la recomputación de la ruta. Cuando no hay posibles sucesores, una ruta entra en estado
activo y se produce una recomputación de ésta. Una recomputación de una ruta empieza con el
envío de Query packets a todos los vecinos. Los routers vecinos pueden responder con Reply si
es que tienen posibles sucesores para el destino, o opcionalmente devolver un Query indicando
que están realizando una recomputación. Mientras se está en estado activo, un router no puede
cambiar el salto al siguiente vecino. Una vez todos los Replies son recibidos para una
determinada Query, el destino puede pasar de estado pasivo y un nuevo sucesor puede ser
elegido.
FORMATOS DE PAQUETES EIGRP :
Existen 5 clases:
-
-
-
-
Hello/Acks: los paquetes Hello son multicast. No necesitan reconocimiento. Un Hello sin datos
es un Ack. Los Acks son siempre enviados usando una dirección unicast y contienen un número
de reconocimiento distinto de cero.
Updates : Cuando se descubre un nuevo vecino, estos paquetes son enviados, así el vecino puede
construir su topology table. En este caso, los paquetes Update son unicast. En otros casos, como
el cambio del costo de un enlace, Updates son multicast. Se transmiten siempre de forma segura.
Queries y Replies: son enviadas cuando los destinos pasan a un estado 'activo'. Queries son
siempre multicast menos si son enviadas en respuesta a una Query recibida, entonces será
unicast. Replies son siempre enviadas en respuesta a Queries para indicar el origen que no
necesita pasar a un estado activo porque tiene posibles sucesores. Replies son unicast al origen
de la query. Ambas, replies y queries son transmitidas de forma segura.
Request : son usados para conseguir información específica de uno o más vecinos. Pueden ser
multicast o unicast. Son utilizados en rutas de aplicaciones servidor. No se transmiten de forma
segura.
ETIQUETAR RUTAS:
EIGRP tiene conocimiento de rutas internas y externas. Las rutas internas son las que han sido originadas
dentro de un sistema autónomo EIGRP. Las rutas externas han sido aprendidas a partir de otros protocolos de
routing o bien residen en la tabla de routing como rutas estáticas. Estas rutas son etiquetadas individualmente
con la identificación de su origen.
Las rutas externas son etiquetadas con la siguiente información:
- El ID del router que redistribuye la ruta
- El número de AS donde está el destino
- Una etiqueta configurable para el administrador
El ID del protocolo externo
- La métrica del protocolo externo
- Bit flags para el routing por defecto.
COMPATIBILIDAD :
EIGRP proporciona compatibilidad con routers IGRP. Esto permite a los usuarios beneficiarse de ambos
protocolos.
Hay un mecanismo automático de redistribución utilizado que hace que rutas IGRP sean importadas a EIGRP
y viceversa. Las métricas para ambos protocolos son directamente traducibles, son fácilmente comparables
como si fueran rutas generadas en su propio AS. Las rutas IGRP son consideradas rutas externas en EIGRP.
Las rutas IGRP son preferentes a las EIGRP por defecto. Esto puede cambiarse con un comando de
configuración que no requiere a los procesos de routing volver a empezar.
-
EJEMPLO de DUAL:__
La siguiente topología ilustra cómo el algoritmo DUAL converge. El ejemplo se centra sólo en el destino N.
Cada nodo muestra su coste hasta N ( en saltos). Las flechas muestran el sucesor del nodo. Por ejemplo, C
utiliza A para alcanzar N, y su coste es 2.
N
|
|
^
|
(1) A -------<- B (2)
|
|
|
|
^
^
|
|
(2) C --------- D (3)
Si el enlace entre A y B falla, B envía una Query informando a sus vecinos que ha perdido a su feasible
successor (posible sucesor). D recibe la Query y determina si tiene otro posible sucesor. Si no lo tuviese,
tendría que empezar una computación de ruta y entrar en estado activo. Sin embargo en este caso, C es un
posible sucesor porque su coste (2) es menor que el actual coste de D (3) al destino N. D puede cambiar a C
como su sucesor. Notar que A y C no participan pues no están afectadas por el cambio.
Ahora provocaremos que se produzca la computación de una ruta. En este escenario, supongo que el enlace
entre A y C falla. C determina que ha perdido a su sucesor y que no tiene otro posible. D no se considera un
posible sucesor porque su métrica (3) es mayor que el actual coste de C (2) para alcanzar el destino N. C debe
realizar una computación de ruta hacia el destino N. C envía una Query a su único vecino (D). D envía Reply
porque su sucesor no ha cambiado. D no necesita realizar una computación de ruta. Cuando C recibe el Reply,
sabe que todos los vecinos han procesado la noticia sobre el fallo a N. En este momento, C puede elegir a su
nuevo posible sucesor D con un coste de 4 para alcanzar el destino N. Notar que a A y a B no les afecta el
cambio en la topología y que D necesitaba simplemente responder a C.