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

Introducción

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

Prerequisites

Requirements

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

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

El problema

El tipo de red OSPF en la interfaz de velocidad primaria (PRI), la interfaz de velocidad básica (BRI) y las interfaces de marcador es punto a punto, lo que significa que una interfaz no puede formar adyacencia con más de un vecino. Un problema común cuando una interfaz PRI, BRI o dialer intenta formar una adyacencia OSPF es que el vecino se atasca en el proceso exstart/exchange. Veamos un ejemplo.

Con el comando show ip ospf neighbor, podemos ver que el estado vecino está atascado en "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 de RTR-Bs muestra que el tipo de red es 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 depurar esta situación usando el comando debug ip ospf adj. Veamos algunos ejemplos de salida tomados mientras se ejecuta este comando en RTR-B en la figura anterior:

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 seq 0xB41 y recibe el primer DBD de 3.3.3.2 (RTR-A) con el nº de cola 0x1D06. La negociación de vecino todavía no ha finalizado.

Líneas 4 - 6: RTR-B recibe una respuesta de 3.3.3.2 (RTR-A) que indica que RTR-A recibió el primer DBD de RTR-B. Dado que RTR-B tiene el ID de router más alto, RTR-A se elige como esclavo. Después de recibir el reconocimiento del RTR-A, el RTR-B se declara maestro y envía el primer DBD con los datos en él. Observe el número de secuencia, que es 0xB42. Dado que RTR-B es el maestro, sólo puede incrementar el número de secuencia.

Línea 7: El RTR-B solicita datos del RTR-A ya que el RTR-A indicó que tiene más datos para enviar (el indicador se establece en 0x2 en el último DBD recibido del RTR-A).

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

Líneas 9 - 11: El RTR-B recibe una respuesta del esclavo (RTR-A) con un número de secuencia completamente diferente y un indicador de 0x7, que es el indicador de inicio. Este DBD estaba destinado a otro router (probablemente RTR-C), pero RTR-B lo recibió incorrectamente. RTR-B declara que hay una discrepancia porque un indicador de 0x7 significa que el esclavo ha cambiado su estado a maestro configurando el bit MS (maestro/esclavo) durante el intercambio de adyacencia. RTR-B también se queja del número de secuencia porque está fuera de servicio. El esclavo siempre debe seguir el número de secuencia del maestro.

Línea 12: RTR-B reinicializa la adyacencia enviando el primer DBD a 3.3.3.2 para volver a elegir maestro y esclavo.

Líneas 13 - 14: RTR-B recibe un DBD de 3.3.3.2 (RTR-A), indicando que es un esclavo, sin reconocer el número de secuencia de RTR-B. RTR-B declara que no reconoce este DBD ya que la negociación maestra y esclava todavía no está completa. Este paquete DBD estaba destinado a otro router.

Línea 15: RTR-B recibe una respuesta de 3.3.3.2 (RTR-A) para el DBD antiguo, pero es demasiado tarde porque RTR-B ya ha reinicializado el proceso de adyacencia.

Línea 16: RTR-B no reconoce este DBD porque es para una adyacencia "antigua", que RTR-B ya ha caído.

Este proceso se repetirá sin cesar.

La solución

Según la sección 8.1 de RFC 2328 , OSPF envía un paquete multicast para un tipo de red punto a punto incluso después de que la interfaz alcance el estado bidireccional. Dado que RTR-A intenta formar adyacencias con RTR-B y RTR-C, RTR-B recibe paquetes DBD destinados a RTR-C y RTR-C recibe paquetes DBD destinados a RTR-B.

Para solucionar este problema, cambie el tipo de red en todos los routers a punto a multipunto. Esto cambia el comportamiento de OSPF para enviar paquetes de unidifusión después del estado bidireccional. Ahora RTR-B recibe sólo paquetes destinados a sí mismo y RTR-C recibe paquetes destinados a sí mismo. El cambio del tipo de red de esta manera asegura que el router OSPF formará adyacencia en una interfaz PRI, BRI o dialer.

Para cambiar el tipo de red, introduzca los siguientes comandos de configuración, para finalizar cada línea, pulse ENTER. Cambiaremos RTR-B como 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 observamos los comandos show para RTR-B, podemos verificar que el tipo de red es punto a multipunto y que el estado está completo.

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

• Configuración del marcado manual BRI a BRI con correspondencias de marcador de DDR
• Página de Soporte OSPF
• Soporte Técnico - Cisco Systems