IP : Open Shortest Path First (OSPF)

¿Por qué OSPF no forma adyacencia en una interfaz de marcador, PRI o BRI?

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

Esta nota técnica explica un problema con la formación de adyacencia OSPF cuando las interfaces del dialer se configuran como enlaces punto a punto.

prerrequisitos

Requisitos

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte las Convenciones de Consejos Técnicos de Cisco.

El problema

El tipo de red OSPF en la interfaz de la velocidad primaria (PRI), Basic Rate Interface (BRI), y las interfaces del dialer son de punto a punto, así que él significa que una interfaz no puede formar la adyacencia con más de un vecino. Un problema común cuando un PRI, un BRI, o las interfaces del dialer intentan formar una adyacencia OSPF es el vecino consigue pegado en el exstart/proceso de intercambio. Veamos un ejemplo.

/image/gif/paws/13691/20a.gif

Usando el comando show ip ospf neighbor, podemos ver que pegan al estado de vecino en el “EXSTART”.

RTR-A# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.3           1   EXSTART/  -     00:00:37    3.3.3.3         Serial6/0:23
3.3.3.4           1   EXSTART/  -     00:00:39    3.3.3.4         Serial6/0:23

RTR-B# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.2           1   EXSTART/  -     00:00:36    3.3.3.2         BRI0

RTR-C# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.2           1   EXSTART/  -     00:00:35    3.3.3.2         BRI0

La configuración RTR-B muestra que el tipo de red es de punto a punto:

RTR-B# show ip ospf interface bri0 
     BRI0 is up, line protocol is up (spoofing) 
       Internet Address 3.3.3.3/24, Area 2 
       Process ID 1, Router ID 3.3.3.3, Network Type POINT_TO_POINT, Cost: 1562 
       Transmit Delay is 1 sec, State POINT_TO_POINT, 
       Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 
         Hello due in 00:00:06 
       Index 1/1, flood queue length 0 
       Next 0x0(0)/0x0(0) 
       Last flood scan length is 1, maximum is 1 
       Last flood scan time is 0 msec, maximum is 0 msec 
       Neighbor Count is 1, Adjacent neighbor count is 0 
       Suppress hello for 0 neighbor(s) 

Podemos hacer el debug de esta situación usando el comando debug ip ospf adj. Miremos una cierta salida de muestra tomada mientras que funciona con este comando en el RTR-B en la figura arriba:

1: Send DBD to 3.3.3.2 on BRI0 seq 0xB41 opt 0x42 flag 0x7 len 32 
2: Rcv DBD from 3.3.3.2 on BRI0 seq 0x1D06 opt 0x42 flag 0x7 len 32 
   mtu 1500 state EXSTART 
3: First DBD and we are not SLAVE 
4: Rcv DBD from 3.3.3.2 on BRI0 seq 0xB41 opt 0x42 flag 0x2 len 92 mtu 
   1500 state EXSTART 
5: NBR Negotiation Done. We are the MASTER 
6: Send DBD to 3.3.3.2 on BRI0 seq 0xB42 opt 0x42 flag 0x3 len 92 
7: Database request to 3.3.3.2 
8: sent LS REQ packet to 3.3.3.2, length 12 
9: Rcv DBD from 3.3.3.2 on BRI0 seq 0x250 opt 0x42 flag 0x7 len 32 
   mtu 1500 state EXCHANGE 
10: EXCHANGE - inconsistent in MASTER/SLAVE 
11: Bad seq received from 3.3.3.2 on BRI0 
12: Send DBD to 3.3.3.2 on BRI0 seq 0x2441 opt 0x42 flag 0x7 len 32 
13: Rcv DBD from 3.3.3.2 on BRI0 seq 0x152C opt 0x42 flag 0x2 len 92 
    mtu 1500 state EXSTART 
14: Unrecognized dbd for EXSTART 
15: Rcv DBD from 3.3.3.2 on BRI0 seq 0xB42 opt 0x42 flag 0x0 len 32 
    mtu 1500 state EXSTART 
16: Unrecognized dbd for EXSTART 

Líneas 1 - 3: El RTR-B envía el primer DBD a 3.3.3.2 (RTR-A) con 0xB41 seq y recibe el primer DBD de 3.3.3.2 (RTR-A) con el seq# 0x1D06. La negociación de vecino todavía no es completa.

Líneas 4 - 6: El RTR-B recibe una contestación de 3.3.3.2 (RTR-A) que indica que el RTR-A recibió el DBD RTR-B primer. Puesto que el RTR-B tiene el Router ID más alto, el RTR-A se elige auxiliar. Después de recibir el acuse de recibo del RTR-A, el RTR-B se declara principal y envía el primer DBD con los datos en él. Observe el número de secuencia, que es 0xB42. Puesto que el RTR-B es el master, sólo puede incrementar el número de secuencia.

Línea 7: El RTR-B pide los datos del RTR-A puesto que el RTR-A indicó que tiene más datos a enviar (indicador fijado a 0x2 en el DBD más reciente recibido del RTR-A).

Línea 8: El RTR-B envía un paquete de pedido de estado de link a 3.3.3.2 (RTR-A). Esto es un tipo 3. del paquete OSPF. Este paquete se envía generalmente a la dirección IP del vecino. En este caso, la dirección IP del vecino es su Router ID.

Líneas 9 - 11: El RTR-B recibe una contestación del esclavo (RTR-A) con un número de secuencia totalmente diverso y de un indicador de 0x7, que es el indicador del init. Este DBD fue pensado para otro router (RTR-C más probable), pero el RTR-B lo recibió incorrectamente. El RTR-B declara hay una discrepancia porque un indicador de 0x7 significa que el esclavo ha cambiado su estatus para dominar fijando el bit (maestro/satélite) MS durante el intercambio de la adyacencia. El RTR-B también se queja por el número de secuencia porque está fuera de servicio. El esclavo debe seguir siempre el número de secuencia del master.

Línea 12: El RTR-B reinicializa la adyacencia enviando el primer DBD a 3.3.3.2 para reelegir el master y al esclavo.

Líneas 13 - 14: El RTR-B recibe un DBD de 3.3.3.2 (RTR-A), indicando que es un esclavo, sin el reconocimiento del número de secuencia RTR-B. El RTR-B declara que no reconoce este DBD puesto que la negociación del master y del esclavo no es completa todavía. Esto paquete DBD fue pensada para otro router.

Línea 15: El RTR-B recibe una contestación de 3.3.3.2 (RTR-A) para el DBD viejo, pero es demasiado atrasado porque el RTR-B ha reinicializado ya el proceso de adyacencia.

Línea 16: El RTR-B no puede reconocer este DBD porque está para una “vieja” adyacencia, que el RTR-B ha derribado ya.

Este proceso relanzará sin fin.

La solución

Según la sección 8.1 del RFC 2328leavingcisco.com , el OSPF envía un paquete de multidifusión para un tipo de red punto a punto incluso después la interfaz alcanza al estado bidireccional. Puesto que el RTR-A está intentando formar las adyacencias con ambo RTR-B y RTR-C, el RTR-B recibe los paquetes del DBD significados para el RTR-C y el RTR-C recibe los paquetes del DBD significados para el RTR-B.

Para solucionar este problema, cambie el tipo de red en todo el Routers a la punta a de múltiples puntos. Esto cambia el comportamiento del OSPF para enviar los paquetes de unidifusión después del estado bidireccional. Ahora el RTR-B recibe solamente los paquetes destinados para sí mismo y el RTR-C recibe los paquetes destinados para sí mismo. El cambio del tipo de red de esta manera se asegura de que el router para OSPF formará la adyacencia en un PRI, un BRI, o una interfaz del dialer.

Para cambiar el tipo de red, ingrese los comandos configuration siguientes, terminando cada línea presionando INGRESAN. Cambiaremos el RTR-B como un ejemplo.

RTR-B# configure terminal 
RTR-B(config)# int bri 0 
RTR-B(config-if)# ip ospf network point-to-multipoint 
RTR-B(config-if)# end 

Ahora si miramos los comandos show para el RTR-B, podemos verificar que el tipo de red sea punta a de múltiples puntos y el estado es lleno.

RTR-B# show ip ospf interface bri0 
BRI0 is up, line protocol is up (spoofing) 
  Internet Address 3.3.3.3/24, Area 2 
  Process ID 1, Router ID 3.3.3.3, Network Type POINT_TO_MULTIPOINT, Cost: 1562 
  Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT, 
  Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5 
    Hello due in 00:00:16 
  Index 1/1, flood queue length 0 
  Next 0x0(0)/0x0(0) 
  Last flood scan length is 1, maximum is 1 
  Last flood scan time is 0 msec, maximum is 0 msec 
  Neighbor Count is 1, Adjacent neighbor count is 1 
    Adjacent with neighbor 172.16.141.10 
  Suppress hello for 0 neighbor(s) 
  
RTR-B# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
172.16.141.10     1   FULL/  -        00:01:36    3.3.3.2         BRI0 

Información Relacionada


Document ID: 13691