Estados de OSPF al buscar convergencia

Posted on Actualizado enn

Al configurar OSPF, los routers buscan convergencia.

El estado de convergencia de cada enlace viene definido en un campo que se ve al ejecutar el siguiente comando

R3#sh ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface

1.1.1.1 1 FULL/BDR 00:00:36 10.1.1.1 GigabitEthernet0/0

2.2.2.2 1 EXSTART/DR 00:00:34 1.1.3.2 GigabitEthernet0/1

 

El significado de este campo lo vamos ea definir en esta entrada

 

DOWN

Este es el primer estado vecino OSPF. Significa que no se ha recibido información (hellos) de este vecino, pero los paquetes hola pueden enviarse al vecino en este estado. Durante el estado vecino totalmente adyacente, si un enrutador no recibe el paquete Hello de un vecino dentro del tiempo RouterDeadInterval (RouterDeadInterval = 4 * HelloInterval por defecto) o si el vecino configurado manualmente se está eliminando de la configuración, el estado vecino cambia Desde Full hasta Down.

ATTEMT

Este estado sólo es válido para vecinos configurados manualmente en un entorno NBMA. En el estado de intento, el enrutador envía unicast paquetes hola cada intervalo de sondeo al vecino, de la cual no se han recibido hellos dentro del intervalo muerto.

INIT

Este estado especifica que el enrutador ha recibido un paquete hello de su vecino, pero el ID del enrutador receptor no se incluyó en el paquete Hello. Cuando un enrutador recibe un paquete hello de un vecino, debe enumerar el ID del enrutador del remitente en su paquete hello como un reconocimiento de que recibió un paquete de hola válido.

2 WAY

Este estado designa que se ha establecido comunicación bidireccional entre dos routers. Bidireccional significa que cada enrutador ha visto el paquete de saludo del otro. Este estado se alcanza cuando el enrutador que recibe el paquete hello ve su propio ID de enrutador dentro del campo vecino del paquete recibido de hello. En este estado, un enrutador decide si debe ser adyacente con este vecino.

En los medios de difusión (broadcast media)  y las redes de multiacceso no de difusión ( non-broadcast multiaccess networks), un enrutador sólo se llena con el enrutador designado (DR) y el enrutador designado de respaldo (BDR); Permanece en el estado de 2 vías con todos los demás vecinos. En las redes punto a punto (point-to-point) y punto a multipunto (point-to-multipoint), un enrutador se llena con todos los routers conectados.

Al final de esta etapa, se eligen el DR y el BDR para las redes de broadcast y no non-broadcast.

Para más información sobre el proceso electoral de DR, refiérase a Elección DR.

Nota: Recibir un paquete de descriptor de base de datos (DBD) de un vecino en el estado de init también provocará una transición al estado de 2 vías.

EXSTART

Una vez que el DR y BDR son elegidos, el proceso real de intercambio de información de estado del enlace puede comenzar entre los routers y su DR y BDR. En este estado, los enrutadores y sus DR y BDR establecen una relación maestro-esclavo y eligen el número de secuencia inicial para la formación de adyacencia. El enrutador con el ID de enrutador más alto se convierte en el maestro e inicia el intercambio y, como tal, es el único enrutador que puede incrementar el número de secuencia. Obsérvese que uno lógicamente concluiría que el DR / BDR con el ID de enrutador más alto se convertirá en el maestro durante este proceso de relación maestro-esclavo. Recuerde que la elección de DR / BDR puede ser puramente en virtud de una mayor prioridad configurada en el enrutador en lugar del ID de enrutador más alto. Por lo tanto, es posible que un DR desempeña el papel de esclavo. Y también tenga en cuenta que la elección maestro / esclavo es por vecino.

EXCHANGE

En el estado de intercambio, los routers OSPF intercambian paquetes de descriptor de base de datos (DBD). Los descriptores de base de datos contienen únicamente encabezados de anuncios de estado de enlace (LSA) y describen el contenido de toda la base de datos de estado de enlace. Cada paquete DBD tiene un número de secuencia que puede ser incrementado sólo por el maestro que es reconocido explícitamente por el esclavo. Los enrutadores también envían paquetes de solicitud de estado de enlace y paquetes de actualización de estado de enlace (que contienen todo el LSA) en este estado. El contenido del DBD recibido se compara con la información contenida en la base de datos de estado de enlace de los enrutadores para comprobar si se dispone de información de estado de enlace nueva o más reciente con el vecino.

LOADING

En este estado, se produce el intercambio real de información de estado de enlace. Basándose en la información proporcionada por los DBD, los enrutadores envían paquetes de solicitud de estado de enlace. El vecino proporciona entonces la información de estado de enlace solicitada en paquetes de actualización de estado de enlace. Durante la adyacencia, si un enrutador recibe una LSA obsoleta o ausente, solicita que LSA envíe un paquete de solicitud de estado de enlace. Todos los paquetes de actualización del estado del enlace son reconocidos.

 

FULL

En este estado, los routers son totalmente adyacentes entre sí. Todos los enrutadores y LSA de red se intercambian y las bases de datos de los routers están totalmente sincronizadas. Full es el estado normal de un enrutador OSPF. Si un enrutador está atascado en otro estado, es una indicación de que hay problemas en la formación de adyacencias. La única excepción a esto es el estado de 2 vías, que es normal en una red de difusión. Los enrutadores alcanzan el estado LLENO con su DR y BDR en NBMA / medios de difusión y estado FULL con cada vecino en el resto del medio, tal como punto a punto y punto a multipunto. Nota: El DR y el BDR que alcanzan el estado LLENO con cada enrutador en el segmento exhibirán FULL / DROTHER cuando usted entra el comando show ip ospf neighbor en un DR o BDR. Esto simplemente significa que el vecino no es un DR o BDR, pero dado que el enrutador en el que se ingresó el comando es un DR o BDR, esto muestra al vecino como FULL / DROTHER.

 

Fuente: https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13685-13.html

AUTOR: David Perez Martorell davidperezmartorell@gmail.com

Nota: Si te sirvió lo que postié, te pido 2 segundos para contestar las encuestas que figuran abajo.

Gracias!

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s