RFC 2453 Spa

Grupo de trabajo de la red G.
Malkin
Solicitar comentarios: 2453 Bay Networks
Obsoletes: 1723, 1388 noviembre de 1998
STD: 56
Categoría: Normas pista
RIP versión 2
Estado de este memorándum
Este documento especifica un Internet, seguimiento de normas de
protocolo para el
Comunidad de Internet y discusión de las peticiones y sugerencias
para
mejoras. Consulte la edición actual de la Internet"
Normas de protocolo oficiales"(STD 1) para el estado de normalización
y el estado de este protocolo. Distribución de este memorándum es
ilimitado.
Aviso de copyright
Copyright (C) la Internet Society (1998). Todos los derechos
reservados.
Resumen
Este documento especifica una extensión de la información de
enrutamiento
Protocolo (RIP), tal como se define en [1], para ampliar la cantidad de
útiles
información transportada en RIP mensajes y agregar una medida de
seguridad.
Un documento del compañero definirán los objetos SNMP MIB de RIP-
2 [2].
Un documento adicional definirá seguridad criptográfica
mejoras de RIP-2 [3].
Agradecimientos
Me gustaría dar las gracias al grupo de trabajo de RIP IETF por su
ayuda en
mejorar el protocolo RIP-2. Gran parte del texto para el fondo
discusiones sobre la distancia del vector protocolos y algunos de los
descripciones de la operación de corte se tomaron de "enrutamiento
Protocolo de información"por C. Hedrick [1]. Algunas de la edición final
en
el documento fue realizado por Scott Bradner.
Normas de Malkin pista [Página 1]
RFC 2453 RIP versión 02 de noviembre de 1998
Tabla de contenidos
1. Justificación........................ 3
2. Current RIP . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Basic protocolo........................ 3
3.1 Introducción. . 3
3.2 Limitaciones del Protocolo............... . 5
3.3. La organización de este documento. 6
3.4 Algoritmos de Vector de distancia........ 6
3.4.1 Relacionados con cambios en la topología. 12
3.4.2 Prevención de inestabilidad. 13
3.4.3 Horizonte Split. 15
3.4.4 Actualizaciones desencadenadas de................. 17
3.5 Especificación del Protocolo de. 18
3.6 Formato de mensaje de. . 20
3.7 Abordar consideraciones........ 22
3.8 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.9 Entrada de procesamiento............... 25
3.9.1 Solicitar mensajes............ 25
3.9.2 Mensajes de respuesta................. 26
3.10 Salida de procesamiento..................... 28
3.10.1 Actualizaciones desencadenadas de................. 29
3.10.2 Generar mensajes de respuesta............... 30
4. Protocolo extensiones..................... 31
4.1 Autenticación. . 31
4.2 Route Tag . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Subnet Mask . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4 Next Hop . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5 Multidifusión........................ 33
4.6 Queries . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5. Compatibilidad........................ 34
5.1 Compatibilidad interruptor................. 34
5.2 Autenticación. . 34
5.3 Más infinito. 35
5.4 Addressless enlaces..................... 35
6. Interacción entre la versión 1 y versión 2........ . 35
7. Consideraciones de seguridad............. 36
Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Dirección del autor............... 38
Declaración de Copyright completa..................... 39
1. Justificación
Con la llegada de OSPF y IS-IS, hay quienes creen
RIP está obsoleto. Si bien es cierto que el trayecto de IGP más nuevos
protocolos son muy superiores a RIP, RIP tiene algunas ventajas.
Sobre todo, en una red pequeña, RIP tiene muy poca sobrecarga en
términos
de ancho de banda utilizado y el tiempo de configuración y
administración. RIP es también
muy fácil de implementar, especialmente en lo referente a la IGP más
nuevo.
Además, hay muchos, muchos más implementaciones de RIP en la
campo de OSPF y IS-IS combinado. Es probable que así permanezca
por algunos años todavía.
Dado que el RIP serán útil en muchos ambientes durante algún
tiempo, es razonable aumentar la utilidad de RIP. Se trata de
especialmente cierto ya que la ganancia es mucho mayor que el costo
de la
cambio.
2. Actual RIP
El mensaje actual de RIP-1 contiene la cantidad mínima de
información
necesarios para routers para enrutar los mensajes a través de una red.
Él también
contiene una gran cantidad de espacio no utilizado, debido a sus
orígenes.
El actual Protocolo RIP-1 no considera sistemas autónomos y
IGP/EGP interacciones, las subredes [11] y autenticación desde
las implementaciones de estos posdata RIP-1. La falta de máscaras
de subred es
un problema particularmente grave para los routers ya que necesitan
una subred
máscara para saber cómo determinar una ruta. Si una ruta RIP-1 es
una red
Ruta (bit 0 de todos fuera de la red), la máscara de subred es igual a
la red
máscara. Sin embargo, si algunos de los bits de red no se establecen,
el router
no se puede determinar la máscara de subred. Y lo que es peor, no el
router
determinar si la ruta de RIP-1 es una ruta de subred o una ruta de
host.
Actualmente, algunos routers simplemente elegir la máscara de
subred de la
interfaz que la ruta fue aprendido y determinar la ruta
tipo de eso.
3. Protocolo básico
3.1 Introducción
RIP es un protocolo de enrutamiento basado en el Bellman-Ford (o
distancia
algoritmo de Vector). Este algoritmo se ha utilizado para el
encaminamiento
cómputos en redes informáticas desde los primeros días de la
ARPANET. Los formatos de paquete especial y protocolo descrito aquí
se basan en el programa "enrutado", que se incluye en el
Distribución de Unix en Berkeley.
En una red internacional, como Internet, es muy
poco probable que un protocolo de enrutamiento solo será utilizado
para todo el
red. Por el contrario, la red se organizará como una colección de
Sistemas autónomos (AS), en general, cada una de ellas será
administrado por una sola entidad. Cada como tendrá su propio
enrutamiento
tecnología, que puede diferir entre como es El protocolo de
enrutamiento utilizado
dentro de un AS se conoce como un protocolo de Gateway Interior
(IGP). A
se utiliza el protocolo separado, llamado un protocolo de Gateway
Exterior (EGP)
para transferir información de enrutamiento entre el AS de RIP ha sido
diseñado para
trabajar como un IGP en tamaño moderado como No está diseñado
para su uso en
entornos más complejos. Para obtener información sobre el contexto
en el cual
RIP-1 se espera al tamaño, ver Braden y Postel [6].
RIP utiliza una clase de algoritmos de encaminamiento denominada
distancia
Algoritmos de vector. La descripción más temprana de esta clase de
algoritmos sabe que el autor está en Ford y Fulkerson [8]. Porque
Esto, a veces se conocen como algoritmos de Ford-Fulkerson. El
término Bellman-Ford también se utiliza y deriva del hecho que la
formulación se basa en la ecuación de Bellman [4]. La presentación en
Este documento se basa estrechamente en [5]. Este documento
contiene un
Especificación del Protocolo. Una introducción a la matemática de
algoritmos de encaminamiento, véase [1]. Los algoritmos básicos
utilizados por este
Protocolo fueron utilizados en el ordenador enrutamiento desde 1969
en el
ARPANET. Sin embargo, la ascendencia específica de este protocolo
se encuentra
los protocolos de red de Xerox. Los protocolos PUP [7] utilizan la
puerta de entrada
Protocolo de información de intercambio de información de
enrutamiento. Un poco
versión actualizada de este protocolo fue adoptado para la red de
Xerox
Arquitectura de sistemas (XNS), con el nombre de información de
enrutamiento
Protocolo [9]. Berkeley de enrutado en gran medida es igual a la de la
encaminamiento
Protocolo de información, con direcciones XNS sustituida por una más
general
formato de dirección capaz de manejar IPv4 y otros tipos de dirección,
y con las actualizaciones de enrutamiento se limita a uno cada 30
segundos. Debido
esta semejanza, el término Routing Information Protocol (o
simplemente RIP)
se utiliza para referirse al protocolo XNS y el protocolo utilizado por
enrutado.
RIP está diseñado para uso en Internet basadas en IP. Internet
se organiza en una serie de redes conectadas a través de propósito
especial
Gateways conocidos como routers. Las redes pueden ser de cualquier
punto a punto
enlaces o redes más complejas, como Ethernet o token ring. Hosts
y enrutadores se presentan con datagramas IP dirigidos a un host.
El enrutamiento es el método por el cual el host o router decide dónde
Enviar el datagrama. Puede ser capaz de enviar el datagrama
directamente a
el destino, si ese destino se encuentra en una de las redes que
están directamente conectados al host o router. Sin embargo, la
interesante caso es cuando el destino no es directamente accesible.
En este caso, el host o router intenta enviar el datagrama a un
router que está más cerca el destino. El objetivo de una ruta
Protocolo es muy simple: debe suministrar la información que se
tenía que hacer el enrutamiento.
3.2 Limitaciones del Protocolo
Este protocolo no resuelve todos los problemas de enrutamiento
posible. Como
mencionado, es principal destinado a usarse como un IGP en redes
de tamaño moderado. Además, las siguientes limitaciones específicas
se mencionan:
-El protocolo se limita a redes cuya trayectoria más larga (la
diámetro de la red) es 15 saltos. Los diseñadores creen que el
diseño de protocolo básico es inadecuado para redes más grandes.
Nota
que esta declaración del límite asume que se utiliza un coste de 1
para cada red. Esta es la forma que RIP normalmente está
configurado. If
el administrador del sistema decide utilizar mayores costos, la parte
superior
límite de 15 puede fácilmente convertirse en un problema.
-El protocolo depende de "contar hasta el infinito" para resolver ciertos
situaciones inusuales. (Esto se explica en la siguiente sección).
Si el sistema de redes tiene varias redes de cientos y un
bucle de enrutamiento se formó con todos ellos, la resolución de
el bucle o requeriría mucho tiempo (si la frecuencia de
actualizaciones de enrutamiento fueron limitadas) o ancho de banda
(si las actualizaciones fueron enviadas
siempre que los cambios fueron detectados). Tal lazo consumiría un
grande
ancho de banda de red antes de que el bucle se corrigió. Nos
Creo que en casos realistas, esto no será un problema excepto
en las líneas lentas. Aun así, el problema será bastante inusual,
puesto que varias precauciones que debe evitar que estos
problemas en la mayoría de los casos.
-Este protocolo utiliza fijos "métricas" Comparar rutas alternativas.
No es adecuado para situaciones donde las rutas deban ser elegido
en función de parámetros en tiempo real tal un retraso medido,
confiabilidad,
o carga. Las extensiones obvias para permitir mediciones de este tipo
son
probabilidades de presentar inestabilidades de un tipo que es el
protocolo
no diseñado para manejar.
3.3. La organización de este documento
El cuerpo principal de este documento está organizado en dos partes,
que
ocupan las siguientes dos secciones:
Un desarrollo conceptual y justificación de vector de distancia
algoritmos en general.
La descripción del protocolo real.
Cada una de estas dos secciones puede en gran medida valerse por
sí mismo. Sección 3.4
intenta dar una presentación informal de la matemática
Fundamentos del algoritmo. Tenga en cuenta que la presentación
sigue un
método de la "espiral". Se describe un algoritmo inicial, bastante
simple.
Entonces refinamientos se agregan que en sucesivas secciones.
Sección 3.5
es la descripción del protocolo real. Excepto donde referencias
específicas
se hacen a la sección 3.4, sería posible implementar RIP
de las especificaciones dadas en la sección 3.5.
3.4 Algoritmos de Vector de distancia
El enrutamiento es la tarea de encontrar un camino de un remitente a
un deseado
destino. En el período "Modelo de Internet" Esto reduce principalmente
a un
trata de encontrar una serie de routers entre la fuente y
redes de destino. Como un mensaje o datagrama permanece en un
única red o subred, problemas de transporte son la
responsabilidad de la tecnología que es específica de la red. Para
ejemplo, Ethernet y ARPANET cada uno definir la manera en que
cualquiera
remitente puede hablar con cualquier destino especificado dentro de
esa uno red.
Enrutamiento IP viene en sobre todo cuando mensajes deben
encenderse de un remitente
una red a un destino en otro diferente. En ese caso, la
mensaje debe pasar a través de uno o más routers conectar el
redes. Si las redes no son adyacentes, puede pasar el mensaje
a través de varias redes de intervención y los routers de conexión
ellos. Una vez que el mensaje llega a un router que está en la misma
red
como el destino, que la tecnología de red se utiliza para llegar a
el destino.
A lo largo de esta sección, el término "red" se utiliza genéricamente
para
cubrir una sola red de difusión (p. ej., un Ethernet), un punto a
línea de punto, o ARPANET. El punto crítico es que es una red
tratada como una sola entidad por IP. No es bien ninguna decisión de
reenvío
necesario (como con una línea punto a punto), o que se realiza la
expedición
de una manera transparente para IP, permitiendo IP tratar la
toda la red como un único sistema completamente conectado (como
con un
Ethernet o ARPANET). Tenga en cuenta que el término "red" se utiliza
en un
forma un poco diferente en discusiones de direccionamiento IP.
Estamos utilizando
el término "red" aquí para referirse a subredes en casos en que subred
abordar está en uso.
Un número de diferentes enfoques para encontrar rutas entre redes
son posibles. Es una forma útil de clasificar estos enfoques en
la base del tipo de información necesitan intercambiar en los routers
para poder encontrar rutas. Los algoritmos de vector de distancia son
basado en el intercambio de sólo una pequeña cantidad de
información. Cada
entidad (router o host) que participa en el protocolo de enrutamiento es
asumido para mantener información sobre todos los destinos dentro
de la
sistema. En general, información sobre todas las entidades conectado
a una
red es resumida por una sola entrada, que describe la ruta al
todos los destinos en esa red. Este resumen es posible
porque en cuanto a la IP, el enrutamiento dentro de una red es
invisible. Cada entrada en esta base de datos de enrutamiento incluye
la siguiente
deberá enviar el router para que los datagramas destinados a la
entidad. En
Además, incluye una "métrica" medición de la distancia total para el
entidad. Distancia es un concepto algo generalizado, que puede cubrir
el tiempo de retardo en mensajes a la entidad, el costo del dólar de
envío de mensajes, etc.. Algoritmos de vector de distancia Obtén su
nombre del hecho de que es posible calcular rutas óptimas cuando
la única información que se intercambia es la lista de estas distancias.
Además, sólo se intercambia información entre las entidades que son
adyacentes, es decir, entidades que comparten una red común.
Aunque comúnmente enrutamiento se basa en información sobre
redes, a veces es necesario hacer un seguimiento de las rutas a
hosts individuales. El protocolo RIP no establece ninguna distinción
formal
entre redes y hosts. Simplemente describe intercambio de
información sobre destinos, que pueden ser tanto redes o
hosts. (Note sin embargo, que es posible que un implementador a
Elija no apoyar las rutas host. Consulte la sección 3.2). De hecho, la
desarrollos matemáticos se considera más conveniente en términos
de rutas desde un host o router a otro. Cuando se habla de la
algoritmo en términos abstractos, es mejor pensar en una entrada de
enrutamiento
para una red como una abreviatura para enrutamiento entradas para
todos los
entidades conexión a esa red. Este tipo de abreviatura hace
sentido sólo porque pensamos de redes como teniendo no internas
estructura que es visible en el nivel de IP. Por lo tanto, nosotros no
generalmente
asignar la misma distancia a cada entidad en una red determinada.
Hemos dicho que cada entidad mantiene una base de datos de
enrutamiento con uno
entrada para todos los destinos posibles en el sistema. Un real
aplicación es probable que tenga la siguiente información
sobre cada destino:
-Dirección: en implementaciones de IP de estos algoritmos, esto será
la dirección IP del host o red.
-router: el router primero a lo largo de la ruta hacia el destino.
-interfaz: la red física que debe utilizarse para alcanzar el
primer router.
-métrica: un número, que indica la distancia al destino.
-temporizador: la cantidad de tiempo desde la última actualización de
la entrada.
Además, varias banderas y otra información interna será
probablemente se incluirán. Esta base de datos se inicializa con un
Descripción de las entidades que están conectados directamente a la
sistema. Se actualiza según la información recibida en los mensajes
de enrutadores vecinos.
Es la más importante información intercambiada por los hosts y
encaminadores
llevado en mensajes de actualización. Cada entidad que participa en la
esquema de enrutamiento envía mensajes de actualización que
describen la ruta
base de datos que actualmente existe en esa entidad. Es posible
mantener las rutas óptimas para todo el sistema utilizando sólo
información obtenida de entidades vecinas. El algoritmo utilizado
para los se describen en la siguiente sección.
Como mencionamos anteriormente, el propósito de enrutamiento es
encontrar una manera de conseguir
datagramas a su destino final. Algoritmos de vector de distancia
se basa en una tabla en cada router listado la mejor ruta a cada
destino en el sistema. Por supuesto, con el fin de definir el camino que
es mejor, que tenemos que tener alguna forma de medir la bondad. Se
trata de
conoce como la "métrica".
En redes simples, es común el uso de una métrica que simplemente
cuenta
¿Cuántos routers debe atravesar un mensaje. En el complejo más
redes, una métrica es elegida para representar la cantidad total de
retraso
que sufre el mensaje, el costo de envío, o algún otro
cantidad que puede ser reducido al mínimo. El principal requisito es
que
debe ser posible representar la métrica como la suma de los "costos"
para
saltos individuales.
Formalmente, si es posible llegar de entidad i j entidad directamente
(es decir, sin pasar por otro router entre), entonces un costo,
d(i,j), se asocia con el salto entre i y j. En la normal
caso donde todas las entidades en una determinada red se consideran
que la
mismo, d(i,j) es el mismo para todos los destinos en una red
determinada, y
representa el costo del uso de esa red. Para obtener la métrica de un
completar la ruta, uno se suma a los costos de los saltos individuales
que componen la ruta. A los efectos de este memorándum, asumimos
que los costos son enteros positivos.
Deje D(i,j) representan la métrica de la mejor ruta de entidad i
j de la entidad. Deben definirse para cada par de entidades. d(i,j)
representa los costos de los pasos individuales. Dejó formalmente,
d(i,j)
representan el costo de ir directamente de la entidad a j. de la entidad
es infinito si i y j no son vecinos inmediatos. (Tenga en cuenta d(i,i)
es infinito. Es decir, no consideramos que haya directa
conexión de un nodo a sí mismo). Puesto que los costos son aditivos,
es
fácil demostrar que la mejor métrica debe ser descrita por
D(i,i) = 0, todos me
D(i,j) = min [d(i,k) + D(k,j)], de lo contrario
k
y que las mejores rutas empezar dirigiendote de i a los k vecinos
para que d(i,k) + D(k,j) tiene el valor mínimo. (Estas cosas puede
demostrar por inducción en el número de pasos en las rutas.) Nota
que podemos limitar la segunda ecuación a k que es inmediatos
vecinos de i. Para otros, d(i,k) es infinita, así que el término
involucrándolos nunca pueden ser el mínimo.
Resulta que uno puede computar la métrica por un algoritmo simple
en base a esto. Entidad obtiene sus vecinos k que le envíe sus
estimaciones de sus distancias a la j de destino. Cuando yo entre el
las estimaciones de k, agrega d(i,k) a cada uno de los números. Se
trata de
simplemente el coste de atravesar la red entre i y k. Ahora y
entonces compara los valores de todos sus vecinos y recoge el
más pequeño.
Una prueba se da en [2] que este algoritmo se acercarán a la
estimaciones correctas de D(i,j) en tiempo finito en la ausencia de
topología
cambios. Los autores hacen muy pocos supuestos sobre el orden en
que las entidades mutuamente envían su información, o cuando el
minuto
se recalcula. Básicamente, entidades simplemente no pueden dejar de
enviar las actualizaciones
o métricas de recomputing y las redes no pueden retrasar mensajes
para siempre. (El desplome de una entidad de enrutamiento es un
cambio de topología). También,
su prueba no hace ninguna suposición sobre las estimaciones iniciales
de D(i,j), excepto que debe ser no negativo. El hecho de que
estos supuestos bastante débiles son buenos lo suficiente es
importante. Porque
no tenemos que hacer suposiciones acerca de Cuándo se envían las
actualizaciones, es
seguro para ejecutar el algoritmo de forma asincrónica. Es decir, cada
entidad puede
enviar actualizaciones según su propio reloj. Las actualizaciones
pueden descartarse
Haz caer la red, siempre y cuando no lo hacen todos. Porque nosotros
no
hay que hacer suposiciones acerca de la situación de partida, el
algoritmo
puede manejar los cambios. Cuando el sistema cambia, el algoritmo
de enrutamiento
comienza hacia un nuevo equilibrio, usando una vieja como su partida
punto. Es importante que el algoritmo se reunirán en finito
tiempo sin importar el punto de partida. De lo contrario ciertas clases
de
cambios podrían conducir a un comportamiento no convergente.
Asume que la declaración del algoritmo mencionadas (y la prueba)
que cada entidad mantiene copias de las estimaciones que provienen
de cada uno de
sus vecinos, y ahora y después hace un minuto todos los vecinos.
De hecho las implementaciones reales no necesariamente hacen.
Ellos simplemente
Recuerde la métrica mejor visto hasta ahora y la identidad de la
vecino que lo envió. Reemplazan esta información siempre que se
ver una mejor métrica (más pequeña). Esto les permite calcular la
mínimo de forma incremental, sin tener que almacenar los datos de
todos los
vecinos.
Hay otra diferencia entre el algoritmo como se describe en
textos y los que se utilizan en protocolos reales como RIP: la
descripción
sobre tendría cada entidad incluye una entrada para sí mismo,
mostrando un
distancia de cero. De hecho generalmente contrario. Recordar que
todas las entidades en una red normalmente se resumen en una sola
entrada
para la red. Consideramos la situación de un host o router G.
se conecta a la red A. C representa el costo de uso de red A
(generalmente una métrica de uno). (Recordar que estamos
suponiendo que la
estructura interna de una red no es visible a la propiedad intelectual y
por lo tanto la
costo de ir entre cualquier dos entidades en él es el mismo). En
principio, G debe recibir un mensaje de cada otra entidad H
A, de la red con un costo de 0 para obtener de esa entidad a sí mismo.
G
¿calcular C + 0 como la distancia a H. algo que G
mirar todos estos mensajes idénticos, simplemente empieza por
hacer una entrada para la red A su tabla y asignándole una métrica
de C. Esta entrada para la red A debe considerarse como Resumen
las entradas para todas las demás entidades de red A. La única
entidad en
Eso no puede ser resumida por que entrada común es G, desde
el costo de ir de G a G es 0, no C. Pero ya que no necesitamos
esas entradas 0, con seguridad podemos conseguir junto con sólo la
entrada
para la red A. Nota una de las otra implicaciones de esta estrategia:
porque
no necesitamos utilizar las entradas 0 para cualquier cosa, hosts que
no
funcionan como routers no es necesario enviar los mensajes de
actualización. Claramente
hosts que no funcionan como routers (es decir, hosts conectados
una única red) no puede tener ninguna información útil para contribuir
que no sea su propia entrada D(i,i) = 0. Como lo han hecho el
interfaz, es fácil ver que una ruta a cualquier otra red
a través de ellos simplemente iremos en la interfaz y luego vienen
derecho
vuelve a salir de él. Así el costo de dicha ruta será mayor que la
mejor costo por al menos C. Ya que no necesitamos las entradas 0,
nonrouters
es necesario no participar en el protocolo de enrutamiento en todos.
Resumamos lo que hace un host o router G. Para cada destino
en el sistema, G mantendrá una estimación actual de la métrica para
destino (es decir, el costo total de llegar a ella) y la identidad
del router vecino en cuyos datos métricos que se basa. Si el
destino está en una red que está conectada directamente a G,
entonces G
simplemente usa una entrada que se muestra el costo del uso de la
red, y
el hecho de que no es necesario para llegar al destino. Es
fácil demostrar una vez que el cómputo ha convergido a la correcta
métricas, el vecino que se registra mediante esta técnica es de hecho
el primer router en el camino hacia el destino. (Si hay
varios caminos igualmente buenas, es el primer router en uno de
ellos.)
Esta combinación de destino, la métrica y el router es típicamente
contemplados como una ruta al destino con esa métrica, utilizando
que el router.
4 ne el método hasta ahora sólo tiene una forma de bajar la métrica,
como la
métricas existentes se mantienen hasta que uno más pequeño. Es
posible
que la estimación inicial podría ser insuficiente. Por lo tanto, debe
haber un
manera de aumentar la métrica. Resulta suficiente utilizar el
siguiente regla: Supongamos que la ruta actual a un destino tiene
métrica
D y usos router G. Si llega un nuevo sistema de información de
algunos
fuente de G, sólo actualizar la ruta si la nueva métrica es
mejor que D. Pero si llega un nuevo sistema de información de G
sí, siempre actualizar D con el nuevo valor. Es fácil mostrar que
con esta regla, el proceso de actualización incremental produce el
mismo
rutas como un cálculo que recuerda la última información de
todos los vecinos y hace una mínima explícita. (Tenga en cuenta que
la
discusión hasta ahora supone que la configuración de red es estática.
No permite la posibilidad de que un sistema puede producir un error.)
Para resumir, aquí es el algoritmo de vector de distancia básica que
ofrece el
ha desarrollado hasta ahora. (Tenga en cuenta que no se trata de una
declaración de la RIP
Protocolo. Hay varios refinamientos todavía añadir). El
siguiendo el procedimiento se lleva a cabo por cada entidad que
participa
en el protocolo de enrutamiento. Esto debe incluir todos los routers en
la
sistema. Hosts que no son routers pueden participar también.
-Mantener una tabla con una entrada para cada destino posible en la
sistema. La entrada contiene la distancia D al destino, y
el primer router G en la ruta a esa red. Conceptualmente,
debe haber una entrada para la entidad, con métricas 0, pero
Esto no es realmente incluido.
-Periódicamente, envíe una actualización de enrutamiento a cada
vecino. La actualización
es un conjunto de mensajes que contengan toda la información de la
tabla de enrutamiento. Contiene una entrada para cada destino, con la
distancia mostrada a ese destino.
-Cuando llega una actualización de enrutamiento de un vecino G',
agregar el costo
asociado a la red que se comparte con G'. (Esto debe
ser la red que llegó la actualización). Llame a la resultante
distancia D'. Comparar las distancias resultantes con la corriente
entradas de la tabla de enrutamiento. Si la nueva distancia D' N es
más pequeño
que el valor existente D, adoptar la nueva ruta. Es decir, cambiar
la entrada de la tabla para N tener métricas D 'y router G'. Si G' es
el router del que partió la ruta existente, es decir, G' = G, luego
Utilice la nueva métrica incluso si es más grande que la anterior.
3.4.1 Enfrentar cambios en la topología
La discusión anterior asume que la topología de la red es
se ha corregido. En la práctica, routers y líneas a menudo fallan y
regresar.
Para manejar esta posibilidad, tenemos que modificar un poco el
algoritmo.
La versión teórica del algoritmo implicó un mínimo sobre todo
vecinos inmediatos. Si cambia la topología, el conjunto de vecinos
cambios. Por lo tanto, la próxima vez que se realiza el cálculo, la
cambio se verá reflejado. Sin embargo, como mencionado arriba, real
implementaciones utilizan una versión incremental de la minimización.
Sólo
se recuerda la mejor ruta hacia cualquier destino determinado. Si el
router
en que ruta debe chocar, o la conexión de red
se rompe, el cálculo nunca podría reflejar el cambio. El algoritmo
como se muestra hasta ahora depende de un enrutador de notificar a
sus vecinos si su
métricas cambian. Si el router se bloquea, entonces no tiene forma de
notificación a vecinos de un cambio.
Con el fin de manejar los problemas de este tipo, protocolos de vector
de distancia
deben tomar algún tiempo rutas. Dependen de los detalles
sobre el protocolo específico. Por ejemplo, en RIP cada router que
participa en el enrutamiento envía un mensaje de actualización a todos
sus vecinos
una vez cada 30 segundos. Supongamos que utiliza la ruta actual para
red N
router G. Si no escuchamos de G para 180 segundos, podemos
suponer
que sea el router colapsó o la red que nos conecta a él
se ha convertido en inservible. Así, marcamos la ruta como no válidos.
Cuando nos
escuchar a otro vecino que tiene una ruta válida a N, el válido
Ruta reemplazará el uno no válido. Tenga en cuenta que esperamos
180
segundos antes de tiempo una ruta aunque esperamos oír de
cada vecino cada 30 segundos. Por desgracia, son mensajes
de vez en cuando perdió por redes. Así, probablemente no es una
buena idea
para invalidar una ruta partiendo de un único mensaje perdido.
Como veremos a continuación, es útil contar con una forma de
notificar a los vecinos
que actualmente hay una ruta válida a una red. RIP, junto
con varios otros protocolos de esta clase, lo hace a través de un
mensaje de actualización normal, marcando esa red como
inalcanzable. A
valor de métrica específica es elegido para indicar un inalcanzable
destino; que valor métrico es más grande que el más grande válido
métrica que esperamos ver. En la implementación existente de RIP,
16 se utiliza. Este valor se conoce normalmente como "infinito", desde
es más grande que la métrica válida más grande. 16 puede parecer un
número sorprendentemente pequeño. Es elegido para ser tan pequeña
por razones
que pronto veremos. En la mayoría de las implementaciones, el mismo
Convención se utiliza internamente para marcar una ruta como no
válida.
3.4.2 Prevención inestabilidad
El algoritmo presentado hasta este punto siempre permitirá un host
o router para calcular una tabla de encaminamiento correcta. Sin
embargo, es
todavía no es suficiente para que sea útil en la práctica. Las pruebas
mencionadas sólo mostrar que las tablas de encaminamiento se
reunirán a
los valores correctos en tiempo finito. No garantizan esto
el tiempo será lo suficientemente pequeño para ser útil, ni dicen lo que
pasar a las métricas para redes que sean inaccesibles.
Es bastante fácil de extender las matemáticas para manejar rutas cada
vez
inaccesible. La Convención dicha antes lo haré. Nos
Elija un valor métrico grande para representar "infinito". Este valor
debe
ser lo suficientemente grande como para que no métrico real nunca
conseguiría grande. Para
los efectos de este ejemplo, utilizaremos el valor 16. Supongamos que
un
red se vuelve inaccesible. Todos los vecinos inmediatamente
routers time out y sistema métrico para esa red a 16. Para
efectos del análisis, podemos suponer que todos los routers vecinos
han conseguido una nueva pieza de hardware que los conecta a
la red desaparecida, con un costo de 16. Ya que es el único
conexión a la red desaparecida, todos los otros routers en el
sistema convergerán a nuevas rutas que pasan por uno de los
routers. Es fácil ver que una vez convergencia ha ocurrido, todos
los routers tendrán métricas de al menos 16 para el desaparecido
red. Routers terminaría con un salto de los vecinos originales
hasta con métricas de al menos 17; dos saltos routers lejos acabaría
por
con al menos 18, etc. Como estas métricas son más grandes que el
máximo
valor métrico, ellos están todos listos para 16. Es obvio que el sistema
ahora se acercarán a una métrica de 16 para la red desaparecida en
absoluto
routers.
Por desgracia, la cuestión de cuánto será la convergencia tomar no es
susceptibles de una respuesta tan simple. Antes de ir a ninguno más,
se
nos servirá ver un ejemplo (tomado de [2]). Tenga en cuenta que
Estamos a punto de Mostrar voluntad ocurre con un correcto
implementación de RIP. Estamos tratando de mostrar por qué ciertas
características
se necesitan. En el ejemplo siguiente las letras corresponden a
routers y las líneas de las redes.
A---B
\/\
\/|
C / todas las redes han costado 1, excepto
| / para el enlace directo de C a D, que
| / ha costado 10
D
| < === red de destino
Cada router tendrá una tabla que muestra una ruta a cada red.
Sin embargo, para los propósitos de esta ilustración, mostramos sólo
las rutas
desde cada router a la red marcada en la parte inferior del diagrama.
D: métrica directamente conectada, 1
B: ruta vía D, métrico 2
C: ruta vía B, métrica 3
A: ruta vía B, métrica 3
Ahora Supongamos que falla el enlace de B a D. Las rutas deben
ahora
ajuste para utilizar el enlace de C a D. Lamentablemente, llevará un
mientras que respecto a que esto ocurra. Los cambios de
enrutamiento empezar cuando B
Nota que el camino hacia D ya no es utilizable. Por simplicidad, la
tabla asume que todos los routers envían los cambios al mismo
tiempo.
El gráfico muestra la métrica para la red de destino, tal como aparece
en
la tabla de enrutamiento en cada router.
tiempo--->
D: dir, 1 dir, 1... 1 dir, 1 dir dir, 1 dir, 1
B: unreach C, 4C, 5C, 6C, 11C, 12
C: B, 3, 4, 5, 6, 11D, 11
R: B, 3C, 4C, 5C, 6C, 11C, 12
dir = conectado directamente
unreach =
Aquí está el problema: B es capaz de deshacerse de su fallido ruta
utilizando un
mecanismo de tiempo de espera, pero los vestigios de esa ruta
persisten en el sistema
durante mucho tiempo. Inicialmente, A y C creo que pueden llegar a D
Via B. Por lo tanto, ellos seguir enviándonos actualizaciones listado
métricas de 3. En
siguiente iteración, B entonces afirman que puede llegar a D via A
o C. Por supuesto, no puede. Las rutas están reclamadas por un y C
son
pasado, pero tienen ninguna manera de saber que todavía. Y aun
cuando
descubren que sus rutas B han desaparecido, cada uno de ellos
piensa
hay una ruta disponible a través de la otra. Eventualmente el sistema
converge, como todas las matemáticas reclama debe. Pero puede
adoptar
poco tiempo para hacerlo. El peor caso es cuando se convierte una
red
totalmente inaccesible desde alguna parte del sistema. En ese caso,
la métrica puede aumentar lentamente en un patrón como uno arriba
hasta
finalmente alcanzan el infinito. Por esta razón, el problema se llama
"contar hasta el infinito".
Ahora debería ver por qué "infinity" es elegido para ser tan pequeño
como
posible. Si una red se convierte en totalmente inaccesible, queremos
contar hasta el infinito que se detenga tan pronto como sea posible.
Infinity
debe ser lo suficientemente grande como para que ningún camino real
es tan grande. Pero
no debería ser algo mejor de lo que se requiere. Por lo tanto la
elección del infinito
es un equilibrio entre el tamaño de la red y la velocidad de
convergencia en caso
contar hasta el infinito sucede. Los diseñadores de RIP creían que el
Protocolo era poco probable que sea práctico para redes con un
diámetro
más de 15.
Hay varias cosas que pueden hacer para prevenir problemas como
esto. Los utilizados por RIP se llaman "split horizon envenenada
revertir"y"provocó versiones".
3.4.3 Horizonte Split
Tenga en cuenta que algunos de los problemas arriba es causado por
el hecho de que A y
C participan en un patrón de engaño mutuo. Cada uno pretende ser
capaces de llegar a D, por el otro. Esto puede evitarse por ser un poco
más cuidadosos acerca de donde se envía la información. En
particular, es
nunca útil pretender accesibilidad para una red de destino para el
Neighbor(s) desde que se supo la ruta. "Split horizon" es un
esquema para evitar problemas causados por incluyendo rutas en
versiones
enviado al router que aprendieron. La escisión simple"
esquema de horizonte"omite rutas aprendidas de un vecino de
actualizaciones
enviado a ese vecino. "Dividir el horizonte con revés envenenado"
incluye tales rutas en las actualizaciones, pero establece sus métricas
hasta el infinito.
Si una piensa que puede llegar a D via C, deben indicar sus mensajes
aC
que D es inalcanzable. Si la ruta a través de C es real, entonces C o
tiene una conexión directa a D, o una conexión a través de algún otro
router. Ruta de C no puede posiblemente volver a, desde que
conforma un
lazo. Diciéndole que C que D es inalcanzable, A simplemente protege
contra
la posibilidad que C puede confundirse y creer que hay un
Itinerario a través A. Esto es obvio para una línea punto a punto. Pero
considerar la posibilidad de que A y C están conectadas por una
emisión
como una Ethernet de red, y hay otros los enrutadores
red. Si A tiene una ruta a través de C, debe indicar que D es
inalcanzable al hablar con cualquier otro router en esa red. El
otros routers en la red pueden llegar a C ellos mismos. Lo harían
nunca necesita para llegar a C via A. Si A los mejor del recorrido es
realmente a través de C,
ningún otro enrutador en esa red tiene que saber que A puede llegar a
D.
Esto es una suerte, porque significa que el mismo actualizar mensaje
se utiliza para C se puede utilizar para todos los routers en la misma
red.
Así, se pueden enviar mensajes de actualización por difusión.
En general, es más segura que la simple split horizon con revés
envenenado
dividir el horizonte. Si dos routers tienen rutas apuntando mutuamente,
publicidad inversas rutas con una métrica de 16 romperá el lazo
inmediatamente. Si no simplemente se anuncian las rutas inversas, la
rutas erróneas tendrá que eliminarse por esperando un tiempo de
espera.
Sin embargo, el revés envenenado tiene una desventaja: aumenta la
tamaño de los mensajes de enrutamiento. Consideremos el caso de la
columna vertebral de un campus
conexión de un número de diferentes edificios. En cada edificio, allí
es un router conecta la columna vertebral a una red local. Considerar
¿Qué enrutamiento actualiza los routers debe transmitir en la columna
vertebral
red. Todo lo que el resto de la red realmente necesita saber sobre
cada router es lo que está conectado a las redes locales. Uso simple
dividir el horizonte, sólo estas rutas aparecería en mensajes de
actualización
el enrutador de la red troncal. Si split horizon con
se utilizan el revés envenenado, el router debe mencionar todas las
rutas ti
Aprende de la columna vertebral, con métricas de 16. Si el sistema es
grande, esto puede resultar en un mensaje de actualización grande,
casi todos de que
entradas indican redes inalcanzables.
En un sentido estático, publicidad inversas rutas con una métrica de
16
no proporciona ninguna información adicional. Si hay muchos routers
en uno
red de difusión, estas entradas extras pueden utilizar el ancho de
banda significativo.
La razón que hay para mejorar el comportamiento dinámico. Cuando
cambios en la topología, mencionando las rutas que no deben pasar
por el
router, así como a las que debe puede acelerar la convergencia.
Sin embargo, en algunas situaciones, los administradores de red
pueden preferir a aceptar
convergencia algo más lento para reducir al mínimo la ruta aérea.
Así implementadores pueden a su discreción aplicar simple split
horizon
en lugar de horizonte dividido con revés envenenado o se pueden
proporcionar
una opción de configuración que permite la red manager elegir
que comportamiento a utilizar. También está permitido aplicar híbrido
los planes que se anuncian algunas rutas inversas con una métrica de
16 y
omitir otros. Un ejemplo de ese plan sería utilizar una métrica de
16 rutas inversa para un determinado período de tiempo después de
enrutamiento
cambios que participen y después de eso los omitiendo de
actualizaciones.
Los requisitos de router RFC [11] especifica que toda implementación
de
RIP debe usar split horizon y también debe usar split horizon con
revés envenenado, aunque puede haber un botón para desactivar
envenenado
inversa.
3.4.4 Actualizaciones desencadenadas
Horizonte de Split con revés envenenado evitará que los bucles de
enrutamiento
involucran sólo dos routers. Sin embargo, es todavía posible poner fin
a
hasta con los patrones en que participan tres routers en el mutuo
engaño. Por ejemplo, A cree que tiene un recorrido a través de B, B
a través de C y C a través de A. Split horizon no puede dejar de tal
lazo.
Este bucle sólo se resolverá cuando la métrica alcance infinito y
las redes en cuestión se declaran entonces inalcanzable.
Actualizaciones desencadenadas
son un intento de acelerar esta convergencia. Para obtener accionado
actualizaciones, simplemente agregue una regla que siempre que un
router cambia el
métrica de una ruta, es necesario enviar mensajes de actualización
casi
inmediatamente, incluso si aún no es tiempo para una de actualizar
regularmente
Mensaje. (Los detalles de la sincronización serán diferente para cada
protocolo.
Algunos protocolos de vector distancia, incluyendo RIP, especifican un
tiempo pequeño
generar excesiva demora, para evitar tener activado actualizaciones
tráfico de red.) Observe cómo esto se combina con las reglas para
nuevas métricas de computación. Supongamos que la ruta de un
router a destino N
va a través de router G. Si llega una actualización de G, la
router receptor está obligado a creer si la nueva información,
el nuevo sistema es mayor o menor que la anterior. Si el resultado es
un cambio en sistema métrico, entonces el router receptor enviará
disparada
actualizaciones de todos los hosts y encaminadores conexión
directamente a ella. Que
a su vez cada uno puede enviar actualizaciones a sus vecinos. El
resultado es un
cascada de actualizaciones desencadenadas. Es fácil de demostrar
que routers y
anfitriones están implicados en la cascada. Suponga que un router G
se agote un
ruta hacia destino enviará N. G activado actualizaciones a todos sus
vecinos. Sin embargo, los vecinos sólo creyentes el nuevo
información son aquellos cuyas rutas n pasan por G. El otro
routers y hosts verá esto como información acerca de una nueva ruta
que
es peor que el que ya están utilizando e ignoran. El
vecinos cuyas rutas pasan por G actualizará sus métricas y
enviar actualizaciones desencadenadas a todos sus vecinos. Una vez
más, sólo aquellos
vecinos cuyas rutas pasan por ellos prestarán atención. Así, la
actualizaciones desencadenadas se propagarán hacia atrás a lo largo
de todos los caminos conducen a
router G, actualizando las métricas hasta el infinito. Esta voluntad de
propagación
parada tan pronto como llegue a una parte de la red cuyo recorrido a
destino N toma algún otro camino.
Si el sistema se podría hacer a sentarse aún mientras la cascada de
actualizaciones desencadenadas sucede, sería posible demostrar que
contar hasta el infinito nunca sucederá. Malas rutas siempre sería
podrían formar bucles quitados inmediatamente y así no enrutamiento.
Lamentablemente, las cosas no son tan agradables. Mientras que las
actualizaciones desencadenadas
se están enviando, actualizaciones regulares pueden estar ocurriendo
al mismo tiempo.
Routers que no han recibido la disparada actualización pero serán
siendo
envío de información basada en la ruta que ya no existe. Se
es posible que después de la actualización disparada ha atravesado
un
router, podría recibir una actualización normal de uno de estos routers
sin embargo, no ha recibido la palabra. Esto podría restablecer un
huérfano
remanente de la ruta defectuosa. Si activa las actualizaciones ocurren
rápidamente
suficiente, esto es muy poco probable. Sin embargo, contar hasta el
infinito es
todavía posible.
de
RIP debe implementar la actualización disparada para rutas
eliminadas y puede
implementar actualizaciones desencadenadas por nuevas rutas o
cambio de rutas. RIP
implementaciones deben limitar también la tasa que desencadenó las
actualizaciones
puede ser trandmitted. (ver sección 3.10.1)
3.5 Especificación del Protocolo de
RIP está diseñado para permitir que los routers intercambiar
información para
cálculo de rutas a través de una red IPv4. Cualquier router que utiliza
RIP se supone que tienen interfaces a una o más redes, de otra
manera
no es realmente un router. Estos se conocen como su
directlyconnected
redes. El protocolo se basa en el acceso a ciertos
información sobre cada una de estas redes, el más importante de los
cuales
es su métrica. La métrica RIP de una red es un número entero entre 1
y 15, inclusive. Se encuentra de alguna manera no especificado en
este
Protocolo; sin embargo, dado el límite máximo del camino de 15, un
valor de 1
se utiliza generalmente. Implementaciones deben permitir que el
sistema
Administrador configure la métrica de cada red. Además el
métrica, cada red tendrá una dirección de destino IPv4 y subred
máscara asociada. Estos deben ser fijados por el sistema
Administrador de una forma no especificada en el presente Protocolo.
Cualquier host que utiliza RIP se supone que tienen interfaces a uno o
más
redes. Estos se conocen como su "directamente conectados
redes". El protocolo se basa en el acceso a cierta información
sobre cada una de estas redes. Lo más importante es su métrica o
"costo". La métrica de una red es un número entero entre 1 y 15
inclusive. Se encuentra de alguna manera no especificado en el
presente Protocolo.
Mayoría de las implementaciones existente siempre utiliza una métrica
de 1. Nuevo
implementaciones deben permitir que el administrador del sistema
establecer el costo
de cada red. Además del costo, cada red tendrá un
Número de red IPv4 y una máscara de subred asociada a ella. Se trata
de
establecido por el administrador del sistema de una forma no
especificada en
Este protocolo.
Tenga en cuenta que las reglas especificadas en la sección 3.7
asumen que hay un
aplicación de Máscara subred única a cada red IPv4 y que sólo el
máscaras de subred para las redes directamente conectadas son
conocidas. Puede haber
sistemas que utilizan máscaras de subred diferente para distintas
subredes dentro de
una única red. También puede haber casos donde es deseable
para un sistema conocer las máscaras de subredes de redes
distantes. Networkwide
distribución de información de enrutamiento que contiene diferentes
máscaras de subred se permite si apuntan a todos los routers en la
red
las extensiones presentadas en este documento. Sin embargo, si
todos los routers en
la red no apuntan a la distribución de estas extensiones de
enrutamiento
información que contienen máscaras de subred diferente debe
limitarse a
Evite problemas de interoperabilidad. Véanse las secciones 3.7 y 4.3
para el
Reglamento de distribución de la subred.
Cada router que implementa RIP supone tener una tabla de
encaminamiento.
Esta tabla tiene una entrada para cada destino que es accesible
en todo el sistema operativo RIP. Cada entrada contiene por lo menos
la siguiente información:
-La dirección IPv4 del destino.
-Una métrica, que representa el costo total de un datagrama
desde el router a ese destino. Esta medida es la suma de la
costos asociados con las redes que se atravesó para obtener
al lugar de destino.
-La dirección IPv4 del router siguiente a lo largo de la ruta de acceso a
la
destino (es decir, el próximo salto). Si el destino está en uno de
las redes conectadas directamente, este artículo no es necesaria.
-Una bandera para indicar que ha cambiado la información sobre la
ruta
recientemente. Esto se conoce como la "bandera de cambio de ruta".
-Varios temporizadores asociados a la ruta. Consulte Sección 3.6 para
más
información sobre contadores de tiempo.
Las entradas para las redes directamente conectadas son instaladas
por la
router utilizando información obtenida por medios no especificados en
este
Protocolo. La métrica para una red conectada directamente se
establece en el
costo de esa red. Como se mencionó, 1 es el coste habitual. En eso
caso, la métrica RIP se reduce a un simple número de saltos. Más
complejo
métricas pueden utilizarse cuando es deseable Mostrar preferencia por
algunos
redes sobre otros (por ejemplo, para indicar las diferencias en el ancho
de banda
o fiabilidad).
Para apoyar las extensiones que se detallan en este documento, cada
entrada debe
Además contiene una máscara de subred. La máscara de subred
permite que el enrutador
(junto con la dirección IPv4 del destino) para identificar la
subredes diferentes dentro de una única red, así como las subredes
máscaras de redes distantes.
Implementadores también pueden optar por permitir que al
administrador del sistema
entrar en rutas adicionales. Estos serían probablemente rutas a hosts
o redes fuera del alcance del sistema de enrutamiento. Son
denominado "rutas estáticas". Entradas para destinos que
éstas iniciales se agregan y actualizados por los algoritmos descritos
en las secciones siguientes.
En orden para el protocolo proporcionar información completa sobre el
encaminamiento,
cada router en la que debe participar en el protocolo. En los casos
cuando múltiples IGPs en uso, debe haber al menos un router
que puede tener fugas de información de enrutamiento entre los
protocolos.
3.6 Formato de mensaje de
RIP es un protocolo basado en UDP. Cada router que utiliza RIP tiene
una ruta
proceso que envía y recibe datagramas en número de puerto UDP
520, la
Puerto de RIP-1/RIP-2. Todas las comunicaciones destinadas a otro
routers
Proceso RIP son enviados al puerto RIP. Todos los mensajes de
actualización de enrutamiento
se envían desde el puerto RIP. Tienen mensajes no solicitados de
actualización de enrutamiento
Puerto de la fuente y el destino igual al puerto RIP. Actualización
se envían mensajes enviados en respuesta a una petición al puerto de
que partió la demanda. Se puede enviar consultas específicas de
puertos
Aparte del puerto RIP, pero deben dirigirse al puerto RIP en
el equipo de destino.
El formato de paquetes RIP es:
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| comando (1) | versión (1) | debe ser cero (2) |
+---------------+---------------+-------------------------------+
||
~ Entrada RIP (20) ~
||
+---------------+---------------+---------------+---------------+
Puede haber entre 1 y 25 entradas RIP (incluidas). Una entrada de
RIP-1
tiene el siguiente formato:
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dirección familia identificador (2) | debe ser cero (2) |
+-------------------------------+-------------------------------+
| Dirección IPv4 (4) |
+---------------------------------------------------------------+
| debe ser cero (4) |
+---------------------------------------------------------------+
| debe ser cero (4) |
+---------------------------------------------------------------+
| métrico (4) |
+---------------------------------------------------------------+
Tamaños de campo se dan en octetos. A menos que se especifique lo
contrario, los campos
contienen binarios enteros, en orden de bytes de la red, con el
mostsignificant
octeto primero (big-endian). Cada marca tick representa una
bit.
Cada mensaje contiene un encabezado RIP que consiste en un
comando y una
número de versión. Esta sección del documento describe la versión 1
de
el protocolo; Sección 4 describe las extensiones de la versión 2. El
campo de comando se utiliza para especificar el propósito de este
mensaje. El
comandos implementados en versión 1 y 2 son:
1 - solicitar una petición para que el sistema responde a enviar todos o
parte de su tabla de enrutamiento.
2 - mensaje respuesta que contenga todo o parte del remitente
tabla de enrutamiento. Este mensaje puede ser enviado en respuesta
a la solicitud, o puede ser un enrutamiento no solicitados
actualización generada por el remitente.
Para cada uno de estos tipos de mensajes, en la versión 1, el resto de
la
datagrama contiene una lista de entradas de la ruta (EMR). Cada RTE
en este
lista contiene un identificador de dirección de la familia (AFI), destino
IPv4
Dirección y el costo para llegar a ese destino (métrico).
La AFI es el tipo de dirección. RIP-1, sólo AF_INET (2) es
generalmente apoyado.
El campo métrico contiene un valor entre 1 y 15 (inclusive) que
especifica la métrica actual para el destino; o el valor 16
(infinito), que indica que el destino no es accesible.
3.7 Abordar consideraciones
Enrutamiento de vector de distancia puede utilizarse para describir
rutas a individuo
hosts y redes. El protocolo RIP permite cualquiera de estas
posibilidades. Los destinos que figuran en la solicitud y respuesta
los mensajes pueden ser redes, hosts o un código especial que se
utiliza para indicar un
Dirección predeterminada. En general, las clases de rutas utilizadas
realmente será
depende de la estrategia de enrutamiento utilizada para la red
particular.
Muchas redes configuradas para que el enrutamiento de la
información para el individuo
hosts no es necesaria. Si cada nodo en una red o subred es
accesible a través de los routers de la mismos, entonces no hay razón
para
mención a hosts individuales en las tablas de encaminamiento. Sin
embargo, redes
que incluyen líneas punto a punto a veces requieren routers para
mantener
pista de rutas a determinados nodos. Si esta función es necesaria
depende de la estrategia de direccionamiento y enrutamiento utilizada
en el sistema.
Así, algunas implementaciones pueden elegir no apoyar rutas host. If
rutas de host no se admiten, deben descartarse cuando estén
recibió en mensajes de respuesta (consulte la sección 3.7.2).
El formato de paquetes RIP-1 no distingue entre varios tipos de
Dirección. Campos que están etiquetados como "dirección" pueden
contener cualquiera de los
siguiente:
subred de dirección de host de red número cero (ruta por defecto)
Entidades que utilizan RIP-1 se supone que utiliza lo más específico
información disponible al encaminar un datagrama. Es decir, al
encaminar el
un datagrama, la dirección de destino en primer lugar se debe cotejar
con el
lista de direcciones de nodo. Debe ser comprobado para ver si se
coincide con cualquier número de subred o red conocido. Finalmente,
si ninguna de
Estos emparejar, se utiliza la ruta por defecto.
Cuando un nodo evalúa la información que recibe mediante RIP-1, su
interpretación de una dirección depende de si sabe la subred
máscara que se aplica a la red. Si es así, es posible
determinar el significado de la dirección. Por ejemplo, considere neto
128.6. Tiene una máscara de subred de 255.255.255.0. Así 128.6.0.0
es un
número de red, 128.6.4.0 es un número de subred, y 128.6.4.1 es un
nodo
Dirección. Sin embargo, si el nodo no sabe la máscara de subred,
la evaluación de una dirección puede ser ambigua. Si hay un cero
parte del nodo, no hay ninguna forma clara para determinar si la
dirección
representa un número de subred o una dirección de nodo. Como un
número de subred
sería inútil sin la máscara de subred, direcciones se supone que
representan los nodos en esta situación. Para evitar este tipo de
ambigüedad, cuando se utiliza la versión 1, nodos deben enviar en no
rutas de subred
nodos que no se puede esperar para conocer la máscara de subred
apropiada.
Normalmente anfitriones sólo saben las máscaras de subred para
conectar directamente
redes. Por lo tanto, salvo disposiciones especiales han realizado,
rutas en una subred no deben ser enviadas fuera de la red de los
cuales el
subred es una parte. RIP-2 (vea la sección 4) elimina la subred/host
ambigüedad mediante la inclusión de la máscara de subred en la
entrada de enrutamiento.
Este "filtrado de subred" corre a cargo de los routers en la "frontera"
de la red de la subred. Se trata de routers que conectan
red con alguna otra red. Dentro de la red de la subred, cada
subred es tratada como una red individual. Enrutamiento entradas
para cada uno
subred se distribuyen por RIP. Sin embargo, enrutadores de borde de
envían sólo una
entrada única para la red como un conjunto de nodos en otras redes.
Esto significa que un router de frontera le enviará información diferente
a
diferentes vecinos. Para los vecinos conexión a la subred
red, genera una lista de todas las subredes a las que está
directamente
conectados, utilizando el número de subred. Para los vecinos
conectan a otro
redes, hace una sola entrada para la red en su conjunto, mostrando
la métrica asociada a esa red. Esta medida haría normalmente
ser la medida más pequeña para las subredes a las que el router es
Adjunto.
Del mismo modo, enrutadores de borde no deben mencionar rutas de
host para los nodos
dentro de una de las redes conectadas directamente en mensajes a
otro
redes. Estas rutas se subsumido por la entrada individual para el
red en su conjunto.
de
RIP debe apoyar rutas host pero si no lo hacen entonces deben
ignorar cualquier ruta de acogida recibida.
La dirección especial 0.0.0.0 se utiliza para describir una ruta
predeterminada. A
la ruta predeterminada se utiliza cuando no es conveniente listar cada
red posibles en las actualizaciones RIP y cuando uno o más
closelyconnected
routers en el sistema están preparadas para manejar el tráfico a la
redes que no aparecen explícitamente. Estos routers deben crear
RIP entradas para la dirección 0.0.0.0, como si se tratara de una red a
que están conectados. La decisión sobre cómo crean routers
entradas para 0.0.0.0 queda para el implementador. Por lo general, la
Administrador del sistema se prestará con una manera de especificar
que
routers deben crear entradas para 0.0.0.0; sin embargo, otros
mecanismos
son posibles. Por ejemplo, un implementador puede decidir que
cualquier
router que habla BGP debe declararse que un encaminador
predeterminado.
Puede ser útil permitir que el administrador de red elegir el
métricas para usarse en estas entradas. Si hay más de uno
encaminador predeterminado, esto hará que sea posible expresar una
preferencia
para uno sobre el otro. Las entradas para 0.0.0.0 están manejadas por
el RIP
en exactamente la misma manera como si hubiera una red real con
esta dirección. Los administradores de sistemas deben tener cuidado
para asegurarse de que
que rutas a 0.0.0.0 no se propagan más es la intención.
Generalmente, cada sistema autónomo tiene predeterminado
recomendado:
router. Por lo tanto, rutas de 0.0.0.0 generalmente no deben
abandonarse
el límite de un sistema autónomo. Los mecanismos para hacer cumplir
Esto no se especifican en este documento.
3.8 Temporizadores
Esta sección describe todos los eventos que se desencadenan por
temporizadores.
Cada 30 segundos, el proceso RIP se despierta para enviar un no
solicitados
Mensaje de respuesta que contiene la tabla de enrutamiento completa
(véase la sección
3.9 en Split Horizon) a cada router vecino. Cuando hay
muchos routers en una única red, hay una tendencia que
sincronizar con otros que emiten todas las actualizaciones en el
mismo tiempo. Esto puede suceder cuando el temporizador de 30
segundo se ve afectado
por la carga de procesamiento en el sistema. Es deseable para el
Actualizar mensajes para ser sincronizado, puesto que puede conducir
a
colisiones innecesarias en las cadenas de televisión. Por lo tanto,
las implementaciones están obligadas a tomar una de dos
precauciones:
-Las actualizaciones de 30 segundos se activan mediante un reloj
cuya tasa no es
afectados por la carga del sistema o el tiempo necesario al servicio de
la
contador de tiempo de actualización anterior.
-El contador de 30 segundos se compensa por un tiempo aleatorio
pequeño (+ /-de 0 a 5
segundos) cada vez que se encuentra. (Implementadores tal vez
desee considerar
mayor variación a la luz de los recientes resultados de la investigación
[10])
Hay dos contadores de tiempo asociadas a cada ruta, un "timeout" y
tiempo de "recolección de basura". Una vez transcurrido el tiempo de
espera, la ruta
ya no es válido; sin embargo, se mantiene en la tabla de enrutamiento
para
un tiempo de poco para que los vecinos pueden notificarse que tiene
la ruta
ha caído. Una vez transcurrido el contador de tiempo de recolección
de basura, la
Ruta finalmente se elimina de la tabla de enrutamiento.
El tiempo de espera se inicializa cuando se establece una ruta y en
cualquier momento
se recibe un mensaje de actualización para la ruta. Si transcurren 180
segundos
la última vez que se inicializa el tiempo de espera, la ruta es
considera que han caducado, y el proceso de eliminación se describe
a continuación
comienza por esa ruta.
Eliminaciones pueden ocurrir por una de dos razones: expira el tiempo
de espera, o
la métrica se establece en 16 debido a una actualización que recibió
de la
router actual (vea la sección 3.7.2 para una discusión de
procesamiento
versiones de otros routers). En cualquier caso, los siguientes eventos
ocurrir:
-La recolección de basura temporizador de 120 segundos.
-La métrica para la ruta se encuentra a 16 (infinito). Esto hace que el
ruta a retirarse del servicio.
-La bandera del cambio de ruta se establece para indicar que esta
entrada ha sido
cambiado.
-El proceso de salida está indicado para desencadenar una respuesta.
Hasta que expire el temporizador de recolección de basura, la ruta
está incluida en
todas las actualizaciones enviadas por este router. Cuando el contador
de tiempo de recolección de basura
expira, la ruta se elimina de la tabla de enrutamiento.
Debe establecerse una nueva ruta a esta red mientras el
garbagecollection
temporizador está funcionando, la nueva ruta reemplazará a la que
está a punto de ser eliminado. En este caso el contador de tiempo de
recolección de basura
debe ser liberado.
Actualizaciones desencadenadas también utilizan un pequeño
temporizador; sin embargo, esta es la mejor
se describe en la sección 3.9.1.
3.9 Proceso de entrada
Esta sección describirá el manejo de los datagramas recibidos en el
Puerto RIP. Procesamiento dependerá el valor en el comando
campo.
Ver secciones 4.6 y 5.1 para obtener más información sobre el manejo
de los números de versión.
3.9.1 Mensajes de solicitud de
Se utiliza una solicitud para pedir una respuesta que contiene la
totalidad o una parte de un
tabla de enrutamiento del router. Normalmente, las solicitudes se
envían como difusiones
(difunde para RIP-2), desde el puerto RIP, enrutadores que acaba
suben y están tratando de llenar en sus tablas de enrutamiento tan
rápidamente como
posible. Sin embargo, puede haber situaciones (por ejemplo, router
control)
donde se necesita la tabla de enrutamiento de sólo un único enrutador.
En esto
caso, la solicitud debe enviarse directamente a que el router de un
UDP
Puerto que no sea el puerto RIP. Si se recibe una solicitud, la
router responde directamente a la dirección del solicitante y el puerto.
La solicitud es procesada entrada por entrada. Si no no hay ninguna
entrada
se da la respuesta. Hay un caso especial. Si hay exactamente
una entrada en la solicitud y tiene un identificador de dirección familiar
de
cero y una métrica de infinito (es decir, 16), entonces esto es una
solicitud para
Envíe toda la tabla de enrutamiento. En ese caso, se realiza una
llamada a la
proceso de salida para enviar la tabla de enrutamiento para la petición
Dirección/puerto. Excepto en este caso especial, el proceso es
bastante
simple. Examinar la lista de PYME en la solicitud uno por uno. Para
cada entrada, ver el destino en la base de datos de enrutamiento del
router
y, si hay una ruta, métrica de la ruta en el campo métrica
de la RTE. Si no hay una ruta explícita a la especificada
destino, poner infinito en cuanto a métrica. Una vez todas las entradas
haya sido rellenado, cambiar el comando de petición a respuesta y
Enviar el datagrama al solicitante.
Tenga en cuenta que hay una diferencia en sistema métrico para
específicos y
conjunto mesa peticiones. Si la solicitud es para una ruta completa
mesa, procesamiento de salida normal se realiza, incluyendo Split
Horizon (véase
Sección 3.9 en Split Horizon). Si la petición es para obtener
las entradas, se buscan en la tabla de enrutamiento y la información
se devuelve como es; no se realiza procesamiento de horizonte
dividido. La razón
Esta distinción es la expectativa de que estas solicitudes son
puedan ser utilizados para diversos propósitos. Cuando un router
viene primero
multicasts una solicitud en cada red conectada pidiendo una
tabla de enrutamiento completa. Se supone que éstos completen
enrutamiento
tablas deben utilizarse para actualizar la tabla de enrutamiento del
solicitante. Para
ello, Split Horizon debe hacerse. Además se asume
se realiza una solicitud para redes específicas sólo por software de
diagnóstico,
y no es usada para enrutar. En este caso, el solicitante querría
para conocer el contenido exacto de la encaminamiento de la tabla y
no querría
cualquier información oculta o modificado.
3.9.2 Mensajes de respuesta
Puede recibir una respuesta para una de varias razones diferentes:
-respuesta a una consulta específica
-actualización regular (respuesta no solicitado)
-activa la actualización causado por un cambio de ruta
Proceso es el mismo sin importar por qué se generó la respuesta.
Porque el procesamiento de una respuesta puede actualizar el router
de enrutamiento
mesa, la respuesta debe revisarse cuidadosamente para la validez. El
Respuesta debe ser ignorado si no es desde el puerto RIP. El
Dirección de origen del datagrama IPv4 debe medirse para ver si el
datagrama es de un vecino válido; la fuente del datagrama debe
en una red conectada directamente. También vale la pena comprobar
Si la respuesta es de una de las direcciones del router.
Interfaces en las cadenas de televisión pueden recibir copias de sus
propios
emisiones/multidifusiones inmediatamente. Si un router procesa su
propia
confusión, salida como entrada nueva, es probable que estos
datagramas deben ser
ignorado.
Una vez validado el datagrama en su conjunto, procesar las PYME en
la respuesta uno por uno. Otra vez, empezar por hacer la validación.
Mediciones incorrectas y otros errores de formato generalmente
indican
portarse mal vecinos y probablemente deben ser llevado la
atención del administrador. Por ejemplo, si la métrica es mayor
que infinito, ignora la entrada pero registrar el suceso. El basic
pruebas de validación son:
-es válida la dirección de destino (por ejemplo, unicast; no neto 0 o
127)
-es la métrica válida (es decir, entre 1 y 16, inclusive)
Si cualquier cheque no, ignorar esa entrada y proceder a la siguiente.
Otra vez, registrar el error es probablemente una buena idea.
Una vez que se ha validado la entrada, actualizar la métrica
agregando el
costo de la red en la que llegó el mensaje. Si el resultado es
mayor de infinity, uso infinito. Es decir
métrico = MIN (métrica + costo, infinito)
Ahora, revise para ver si ya hay una ruta explícita para el
Dirección de destino. Si no hay ninguna ruta de tal, añadir esta ruta a
Mesa de la ruta, a menos que la métrica es infinito (no tiene ningún
sentido
en la adición de una ruta que es inutilizable). Agregar una ruta a la ruta
tabla consiste en:
-Configuración de la dirección de destino a la dirección de destino en
el
RTE
-Establecer la métrica en la métrica recién calculada (como se
describe
arriba)
-Establecer la dirección de salto siguiente que la dirección del router
que
vino el datagrama
-Inicializar el tiempo de espera para la ruta. Si la recolección de basura
temporizador está funcionando para esta ruta, detenerlo (vea sección
3.6 para una
discusión de los temporizadores)
-Establece el indicador de cambio de ruta
-El proceso de salida para activar una actualización (véase la sección
3.8.1) de la señal
Si hay una ruta existente, comparar la dirección de salto siguiente a la
Dirección del router del que partió el datagrama. Si este datagrama
es desde el mismo router como la ruta existente, reiniciar el
tiempo de espera. A continuación, comparar las métricas. Si el
datagrama es de la
mismo router como la ruta existente y la nueva métrica es diferente
que la anterior; o, si el nuevo sistema es más baja que la anterior;
hacer
las siguientes acciones:
-Adopta la ruta desde el datagrama (es decir, poner la nueva métrica y
Ajuste la dirección de salto siguiente, si es necesario).
-Establece el indicador de cambio de ruta y el proceso de salida para
activar la señal
una actualización
-Si el nuevo sistema es infinito, iniciar el proceso de eliminación
(ver arriba); de lo contrario, reiniciar el tiempo de espera
Si el nuevo sistema es infinito, el proceso de eliminación comienza
para el
Itinerario, que ya no se utiliza para direccionar paquetes. Tenga en
cuenta que la
proceso de eliminación se inicia sólo cuando la métrica es primero
infinito. Si la métrica ya era infinito, entonces una nueva eliminación
no se inicia el proceso.
Si el nuevo sistema es el mismo que el viejo, es más sencillo hacerlo
nada más (más allá de reiniciar el tiempo de espera, tal como se
especifica
arriba); sin embargo, existe un heurístico que podría ser aplicado.
Normalmente,
es insensato reemplazar una ruta si la nueva ruta tiene el mismo
métricas como la ruta existente; Esto haría que la ruta de rebote
ida y vuelta, que generaría una cantidad intolerable de
actualizaciones desencadenadas. Sin embargo, si la ruta existente
está mostrando signos
de tiempo hacia fuera, puede ser mejor cambiar a un igualmente bien
ruta alternativa inmediatamente, en lugar de esperar el tiempo de
espera para
suceder. Por lo tanto, si el nuevo sistema es el mismo que el viejo,
examinar el tiempo de espera para la ruta existente. Si es por lo
menos
a mitad de camino hasta el punto de vencimiento, cambiar a la nueva
ruta. Esto
heurística es opcional, pero muy recomendable.
Se omite cualquier entrada que no estas pruebas, como no es mejor
que
la ruta actual.
3.10 Procesamiento de salida
Esta sección describe el proceso utilizado para crear la respuesta
mensajes que contengan todo o parte de la tabla de enrutamiento.
Esto
procesamiento se puede desencadenar en cualquiera de las
siguientes maneras:
-Por el proceso de entrada, cuando se reciba una solicitud (esta
respuesta es
unidifusión al solicitante; Consulte la sección 3.7.1)
-Por la actualización regular de enrutamiento (difusión/multidifusión
cada 30
router de segundos).
-Por activa las actualizaciones (difusión/multidifusión cuando un
cambio de ruta)
Cuando una respuesta debe enviarse a todos los vecinos (es decir, un
regular o
activa la actualización), un mensaje de respuesta se dirige al router en
el extremo de cada enlace de conexión punto a punto y se emite
(multidifusión para RIP-2) en todos conectados a las redes que apoyan
difusión. Por lo tanto, se prepara una respuesta para cada
directlyconnected
la red y enviado a la dirección adecuada (directo o
difusión/multidifusión). En la mayoría de los casos, esto alcanza todos
los vecinos
routers. Sin embargo, hay algunos casos donde esto no puede ser
bueno
suficiente. Esto puede implicar una red que no es una red de difusión
(por ejemplo, ARPANET), o una situación que implica routers mudos.
De tal
casos, puede ser necesario especificar una lista real de los vecinos
routers y enviar un datagrama a cada uno explícitamente. Se deja a
El implementador para determinar si se necesita un mecanismo de esa
índole, y
para definir cómo se especifica la lista.
3.10.1 Actualizaciones desencadenadas
Actualizaciones desencadenadas requieren un manejo especial por
dos razones. Primero,
la experiencia demuestra que actualizaciones desencadenadas
pueden causar una carga excesiva en
redes con capacidad limitada o redes con muchos routers en ellos.
Por lo tanto, el protocolo requiere que los implementadores incluyen
disposiciones
limitar la frecuencia de actualizaciones desencadenadas. Después de
un disparo
se envía la actualización, debe establecerse un temporizador para un
intervalo aleatorio entre 1
y 5 segundos. Si se producen otros cambios que activan las
actualizaciones
antes de que expire el temporizador, una actualización sola se activa
cuando el temporizador
caduca. El temporizador se restablece luego a otro valor aleatorio
entre 1
y 5 segundos. Una actualización activada debe suprimirse si un
regular
actualización es debido por el tiempo que se enviaría la actualización
disparada.
Actualizaciones desencadenadas y segunda no es necesario incluir la
ruta completa
mesa. En principio, deben ser sólo aquellas rutas que han cambiado
incluido. Por lo tanto, los mensajes generados como parte de una
disparada
actualización debe incluir al menos las rutas que tienen su ruta
Bandera de cambios. Pueden incluir rutas adicionales, en el
discreción de implementador; sin embargo, envío de enrutamiento
completa
las actualizaciones se desaconseja. Cuando es una actualización
activada
procesados, los mensajes deben generarse para cada conectado
directamente
red. Procesamiento de horizonte dividido se realiza cuando la
generación impulsada
actualizaciones, así como versiones normales (véase la sección 3.9).
Si, después de Split
Horizonte de procesamiento para una determinada red, aparecerá una
ruta cambiante
sin cambios en la red (por ejemplo, aparece con una métrica infinita),
la ruta no necesita ser enviada. Si ninguna vía debe enviarse en eso
red, la actualización puede ser omitida. Una vez todos de la disparada
las actualizaciones se han generado, los indicadores de cambio de
ruta deben ser
despejado.
Normas de Malkin pista [página 29]
Si se permite la entrada de procesamiento mientras que se está
generando la salida,
enclavamiento adecuado debe hacerse. Los indicadores de cambio de
ruta debe
no ser cambiado como resultado de la entrada mientras una disparada
de procesamiento
mensaje de actualización se está generando.
La única diferencia entre una actualización disparada y otro
actualización
mensajes es la posible omisión de rutas que no han cambiado.
Los restantes mecanismos, descritos en la sección siguiente, deben
ser
aplicado a todas las actualizaciones.
3.10.2 Generar mensajes de respuesta
Esta sección describe cómo se genera un mensaje de respuesta para
un
red particular directamente conectado:
Establecer el número de versión en 1 o 2. El mecanismo para decidir
la versión para enviar es aplicación específica; sin embargo, si se trata
la respuesta a una petición, la versión de respuesta debe coincidir con
el
Versión de la solicitud. El comando set para respuesta. Establecer los
bytes con la etiqueta
"debe ser cero" a cero. Empezar a llenar en RTEs. recordar que hay
un límite de 25 RTEs a una respuesta; Si hay más, enviar la corriente
Respuesta y empezar uno nuevo. No hay ningún límite definido para el
número de datagramas que forman parte de una respuesta.
Para rellenar el EMR, examinar cada ruta en la tabla de enrutamiento.
Si un
se está generando la disparada de la actualización, sólo las entradas
cuyo recorrido cambiar
banderas se establecen la necesidad de ser incluidos. Si, tras el
procesamiento de horizonte dividido,
la ruta no debe incluirse, saltarlo. Si la ruta debe ser
incluido, entonces la dirección de destino y la métrica se ponen en el
RTE. vías deben ser incluido en el datagrama incluso si sus métricas
son infinitas.
4. Las extensiones del Protocolo
Esta sección no cambia el protocolo RIP por se algo, lo
proporciona extensiones al formato de mensaje que permite routers a
compartir información adicional importante.
El mismo formato del encabezado se utiliza para mensajes RIP-1 y 2
de RIP (véase
Sección 3.4). El formato para la entrada de la ruta 20 octetos (RTE)
para
RIP-2 es:
01233
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dirección familia identificador (2) | Itinerario de etiqueta (2) |
+-------------------------------+-------------------------------+
| Dirección IP (4) |
+---------------------------------------------------------------+
| Máscara de subred (4) |
+---------------------------------------------------------------+
| Próximo salto (4) |
+---------------------------------------------------------------+
| Métrico (4) |
+---------------------------------------------------------------+
La familia identificador de dirección, la dirección IP y la métrica todos
tienen la
significados definidos en la sección 3.4. El campo versión especificará
número de la versión 2 de RIP mensajes que usar autenticación o
llevar
información en cualquiera de los campos acaba de definir.
4.1 Autenticación
Puesto que la autenticación es una por la función de mensaje y puesto
que hay
sólo un campo de 2 octetos disponible en el encabezado del mensaje
y desde cualquier
esquema de autenticación razonable requerirá más de dos octetos,
el esquema de autenticación para RIP versión 2 utilizará el espacio de
un
toda entrada RIP. Si el identificador de la familia de dirección de los
primeros (y
sólo el primero) en el mensaje es 0xFFFF, luego el resto de
la entrada contiene la autentificación. Esto significa que puede haber,
a lo sumo, 24 RIP en entradas en el resto del mensaje. If
autenticación no está en uso, entonces no hay entradas en el mensaje
debe
tiene un identificador de familia de la dirección de 0xFFFF. Un RIP de
mensajes que
contiene una autentificación entrada comenzaría con las siguientes
formato:
01233
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Comando (1) | Versión (1) | sin usar |
+---------------+---------------+-------------------------------+
| 0xFFFF | Tipo de autenticación (2) |
+-------------------------------+-------------------------------+
~ Autenticación (16) ~
+---------------------------------------------------------------+
Actualmente, el único tipo de autenticación es simple contraseña y es
tipo 2. Los restantes 16 octetos contienen la contraseña de texto sin
formato. If
la contraseña es bajo 16 octetos, debe ser alineado a la izquierda y
rellenado
a la derecha con valores nulos (0 x 00).
4.2 Ruta etiqueta
El campo de etiqueta de ruta (RT) es un atributo asignado a una ruta
que
debe ser preservada y readvertised con una ruta. El uso de
la etiqueta de ruta es proporcionar un método de separación RIP
"interno"
rutas (para redes dentro del dominio de enrutamiento RIP) de
las rutas RIP "externas", que pueden se han importado de un EGP o
otro IGP.
Routers protocolos que no sean RIP deben ser configurables para
permite la etiqueta de ruta a configurarse para las rutas procedentes
de
diversas fuentes. Por ejemplo, rutas importadas de EGP o BGP
deben ser capaces de tener su etiqueta de ruta o conjunto a una
arbitraria
valor, o al menos a la cantidad del sistema autónomo de que
las rutas fueron aprendidas.
Otros usos de la etiqueta de ruta son válidos, siempre y cuando todos
los routers en la
RIP dominio usarlo constantemente. Esto permite la posibilidad de un
Documento de interacciones de protocolo BGP-RIP, que se describe
métodos
para la sincronización de enrutamiento en una red de tránsito.
4.3 Máscara de subred de
El campo de la máscara de subred contiene la máscara de subred que
se aplica a
la dirección IP a la porción no-host de la dirección de la producción. Si
este
campo es cero, entonces ninguna máscara de subred ha incluido para
esta entrada.
En una interfaz donde un router RIP-1 puede escuchar y operar en el
información en una entrada de enrutamiento RIP-2 se aplicarán las
reglas siguientes:
1) interna a una red de información nunca debe ser anunciada en
otra red,
2) información acerca de una subred más específica no puede ser
anunciada
donde los enrutadores RIP-1 lo consideraría una ruta de host, y
3) supernet rutas (rutas con una máscara de red menos específica que
la
máscara de red "natural") no debe anunciarse donde podían
encontrarse
interpretado por enrutadores RIP-1.
4.4 Próximo salto
La inmediata dirección IP de salto siguiente a que paquetes al destino
especificado por esta ruta se debe remitir la entrada. Especificar un
valor 0.0.0.0 en este campo indica que la ruta debe ser via
el autor del anuncio de RIP. Una dirección especificada como una
próximo salto debe, por fuerza, ser directamente accesible en la
subred lógica
sobre el cual se hace el anuncio.
El propósito del campo siguiente salto es eliminar paquetes que
enrutan a través de saltos adicionales en el sistema. Es
particularmente útil
Cuando RIP no se ejecuta en todos los routers en una red. A
ejemplo simple se da en el apéndice A. tenga en cuenta que el
próximo salto es un
campo "consultivo". Es decir, si se omite la información facilitada, un
posiblemente puede tomar ruta subóptima, pero absolutamente válido.
If
el salto siguiente recibida no es directamente accesible, debe ser
tratada
como 0.0.0.0.
4.5 La multidifusión
Con el fin de reducir la carga innecesaria en los hosts que no son
escuchar mensajes de RIP-2, un IP multicast address se utilizará para
emisiones periódicas. La IP dirección de multidifusión es 224.0.0.9.
Nota
que IGMP no es necesario ya que estos son inter-router mensajes que
no se reenvían.
En redes NBMA, direccionamiento unicast puede utilizarse. Sin
embargo, si un
respuesta dirigida al RIP-2 dirección de multidifusión se recibe, se
debe ser aceptado.
Con el fin de mantener al revés la compatibilidad, el uso de la
Dirección de multidifusión será configurable, como se describe en la
sección 5.1.
Si se utiliza la multidifusión, debe utilizarse en todas las interfaces que
apoyarlo.
4.6 Consultas
Si un router RIP-2 recibe una solicitud de RIP-1, debe responder con
una
Respuesta de RIP-1. Si el router está configurado para enviar sólo
RIP-2
mensajes, no debe responder a una solicitud de RIP-1.
5. Compatibilidad
RFC [1] demostró previsión considerable en su especificación de la
manejo de los números de versión. Especifica que los mensajes RIP
de
versión 0 deben descartarse, que son mensajes RIP versión 1
desecharse si cualquiera de los campos debe ser cero (MBZ) es
distinto de cero y que
RIP mensajes de cualquier versión superior a 1 no debe ser
desechado
simplemente porque un campo MBZ contiene un valor distinto de cero.
Esto
significa que la nueva versión de RIP es totalmente compatible
con implementaciones existentes de RIP que se adhieran a esta parte
de la
especificación.
5.1 Compatibilidad interruptor
Un interruptor de compatibilidad es necesario por dos razones. Allí
primero,
son implementaciones de RIP-1 en el campo que no siguen la RFC [1]
como se describió anteriormente. En segundo lugar, se evitaría el uso
de la multidifusión
RIP-1 sistemas de recibir actualizaciones de RIP-2 (que pueden ser un
deseado
característica en algunos casos). Este interruptor debe ser
configurable en un
base de la interfaz.
El interruptor tiene cuatro posiciones: RIP-1, en el cual son sólo
mensajes de RIP-1
Enviado; Compatibilidad de RIP-1, en que RIP-2 se emiten mensajes;
RIP-2, en los cuales RIP-2 mensajes son multicast; y "ninguno", que
desactiva el envío de mensajes RIP. Se recomienda que el
por defecto ser o 1 RIP o RIP-2, pero no RIP-1
compatibilidad. Esto es debido a los problemas potenciales que
pueden
se producen en algunas topologías. Compatibilidad de RIP-1 debe ser
utilizado
Cuando todas las consecuencias de su uso son bien entendidos por el
Administrador de red.
Integridad, routers también deben implementar un control de recepción
interruptor que determinaría si se acepta, RIP-1, RIP-2
sólo, ambos o ninguno. También debe ser configurable en un
perinterface
base. Se recomienda que el defecto sea compatible
con el valor predeterminado para el envío de actualizaciones.
5.2 Autenticación
El siguiente algoritmo debe utilizarse para autenticar un mensaje RIP.
Si el router no está configurado para autenticar mensajes RIP-2,
entonces
Se aceptarán mensajes de RIP-2 RIP-1 y no autenticados;
mensajes autenticados de RIP-2 deberán desecharse. Si el router es
configurado para la autenticación de mensajes RIP-2, a continuación,
RIP-1 mensajes y
Se aceptarán mensajes RIP-2 que superar las pruebas de
autenticación;
mensajes de autenticación no autenticados y no RIP-2 será
descartan. Para mayor seguridad, deben ser ignorados de RIP-1
mensajes
Cuando la autenticación está en uso (ver sección 4.1); de lo contrario,
la
información de enrutamiento de mensajes autenticados se propagará
por
Enrutadores RIP-1 de una manera no autenticada.
Puesto que una entrada de autenticación está marcada con una
familia de dirección
Identificador de 0xFFFF, un sistema de RIP-1 ignoraría esta entrada
puesto que
¿pertenecen a una familia de dirección que no sea de propiedad
intelectual. Cabe señalar,
por lo tanto, que el uso de autenticación no impedirá RIP-1 sistemas
ver mensajes de RIP-2. Si lo desea, puede hacerse usando
multidifusión, descrito en las secciones 4.5 y 5.1.
5.3 Mayor Infinity
Mientras que sobre el tema de compatibilidad, hay un punto que la
gente
han solicitado: aumento de infinito. La razón principal de que esto
no se puede hacer es que violaría hacia atrás compatibilidad. A
infinito más grande obviamente confundirían más viejas versiones de
rip. En
mejor de los casos ignoraría la ruta como ignoraría una métrica de
16. También hubo una propuesta para hacer la métrica un solo octeto
y
reutilizar los altos tres octetos, pero eso rompería cualquier
implementaciones
que tratan la métrica como una entidad de 4 octetos.
5.4 Addressless enlaces
Como en RIP-1, addressless enlaces no se admitirán por RIP-2.
6. Interacción entre versión 1 y 2
Porque los paquetes de la versión 1 no contienen información de
subred, la
semántica de encaminadores de redes que contienen tanto en versión
1
y redes de la versión 2 deben limitarse a la versión 1.
Si no es posible tampoco crear negras rutas (es decir,
rutas para las redes que no existen) o crear excesiva de enrutamiento
información en un entorno de versión 1.
Algunas implementaciones de intentan resumir automáticamente
grupos de
rutas adyacentes en una de las entradas, el objetivo es reducir la
número total de entradas. Esto se llama auto-Resumen.
En concreto, cuando se utiliza la versión 1 y versión 2 dentro de un
red, debe utilizarse una máscara de subred única en toda la red.
Además, deberían deshabilitarse mecanismos de auto-Resumen
tales redes e implementaciones deben proporcionar mecanismos para
desactivar
auto-Resumen.
7. Consideraciones de seguridad
El protocolo básico de RIP no es un protocolo seguro. Traer RIP-2
línea con protocolos de encaminamiento más modernos, una
autenticación ampliable
mecanismo se ha incorporado en las mejoras del Protocolo. Esto
mecanismo se describe en los puntos 4.1 y 5.2. La seguridad es más
mejorado por el mecanismo descrito en [3].
Apéndice A
Se trata de un ejemplo simple del uso del campo de salto siguiente en
un rip
entrada.
----- ----- ----- ----- ----- -----
|IR1| |IR2| |IR3| |XR1| |XR2| |XR3|
--+-- --+-- --+-- --+-- --+-- --+--
||||||
--+-------+-------+---------------+-------+-------+--
<-------------RIP-2------------->
Suponer que todos los routers "internos" que son IR1, IR2 y IR3
bajo una administración (por ejemplo un campus) que ha elegido
utilizar
RIP-2 como su IGP. XR1 XR2 y XR3, por el contrario, están bajo
separar la administración (por ejemplo una red regional, de los cuales
el campus
es un miembro) y algunos otros protocolos enrutamiento (por ejemplo
OSPF).
XR1 XR2 y XR3 intercambian información de enrutamiento entre ellos
tal
que saben que las mejores rutas a redes N1 y N2 son via
XR1, N3, N4 y N5 son via XR2 y N6 y N7 via XR3. Por
estableciendo el campo de salto siguiente correctamente (para XR2
para N3/N4/N5, a XR3 para
N6/N7), sólo XR1 necesita intercambiar RIP-2 rutas con IR1/IR2/IR3
para
enrutamiento se produzca sin saltos adicionales a través de XR1. Sin
el
A continuación Hop (por ejemplo, si se utilizaron RIP-1) sería
necesario para
XR2 y XR3 a participar en el protocolo RIP-2 para eliminar
lúpulo extra.
Referencias
[1] Hedrick, C., STD 34, "Routing Information Protocol", RFC 1058,
La Universidad de Rutgers, junio de 1988.
[2] Malkin, G. y F. Baker, "Extensión MIB de RIP versión 2", RFC
1389, Enero de 1993.
[3] Baker, f el. y R. Atkinson, "Autenticación MD5 de RIP-II", RFC
2082, Enero de 1997.
[4] Bellman, R. E., "Programación dinámica", Universidad de Princeton
Press, Princeton, Nueva Jersey, 1957.
[5] Bertsekas, D. P. y Gallaher, G. r., "Redes de datos",
Prentice-Hall, Englewood Cliffs, Nueva Jersey, 1987.
[6] Braden, R. y Postel, J., "Requirements for Internet Gateways",
STD 4, RFC 1009, junio de 1987.
[7] Boggs, D. R., Shoch, J. F., Taft, e. A. y Metcalfe, r. M.,
"Pup: una arquitectura de redes", IEEE Transactions on
Comunicaciones, abril de 1980.
[8] Ford, Jr. de R. L. y Fulkerson, D.r., "Fluye en redes",
Princeton University Press, Princeton, Nueva Jersey, 1962.
[9] Xerox Corp., "Protocolos de transporte de Internet", sistema de
Xerox
XSIS estándar de integración 028112, diciembre de 1981.
[10] Floyd, S. y V. Jacobson, "la sincronización de periódica
Enrutamiento de mensajes,"Simposio de ACM Sigcom 93, septiembre
de 1993.
[11] Baker, f el., "Requisitos para Routers de la versión 4 de IP". RFC
1812,
Junio de 1995.
Dirección del autor
Gary Scott Malkin
Bay Networks
8 Federal Street
Billerica, MA 01821
Teléfono: (978) 916-4237
Correo electrónico: gmalkin@baynetworks.com
Declaración de Copyright completa
Copyright (C) la Internet Society (1998). Todos los derechos
reservados.
Este documento y las traducciones de pueden copiarse y equipadas a
otros, y trabajos derivados que comentar por o de otra manera
explican
o ayuda en su aplicación puede ser preparado, copiado, publicado
y distribuida, en todo o en parte, sin restricción de alguna
clase, siempre que el aviso de copyright anterior y este párrafo
incluido en todas esas copias y trabajos derivados. Sin embargo, esto
documento no puede ser modificada en cualquier forma, tales como
quitando
el aviso de copyright o referencias a la sociedad de Internet u otros
Organizaciones de Internet, excepto según sea necesario con el fin de
desarrollar estándares de Internet en que caso los procedimientos
para
Copyrights definidos en el proceso de estándares de Internet deben
ser
seguido, o como sea necesario para traducir a idiomas distinto
Inglés.
Los permisos limitados concedidos por encima son perpetuos y no
será
revocado por la sociedad de Internet o sus sucesores o cesionarios.
Este documento y la información contenida en este documento se
proporciona en un
"Tal como estan" y la INTERNET SOCIETY y la INTERNET
ENGINEERING
TASK FORCE SE EXIME DE TODA GARANTÍA, EXPRESA O
IMPLÍCITA, INCLUYENDO
PERO SIN LIMITARSE A CUALQUIER GARANTÍA DE QUE EL USO
DE LA INFORMACIÓN
EN ESTE DOCUMENTO NO INFRINGIRÁ NINGÚN DERECHO O
CUALQUIER GARANTÍA IMPLÍCITA DE
COMERCIABILIDAD O IDONEIDAD PARA UN PROPÓSITO EN
PARTICULAR.

RFC 2453 Spa

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

RFC 2453 Spa

Загружено:

Авторское право:

Доступные форматы

Grupo de trabajo de la red G.

Вам также может понравиться