Solución de problemas de abrir los primeros vecinos de la ruta más corta atascados en el estado Exstart/Exchange

Introducción

Este documento describe cómo resolver situaciones en las que vecinos OSPF (Open Shortest Path First) se atascan en los estados Exstart y Exchange. 

Prerequisites

Requirements

Se recomienda que el usuario esté familiarizado con la operación y configuración básicas de OSPF, en particular, los estados vecinos OSPF.

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• Routers Cisco 2503

• Cisco IOS^®Software Release 12.2(24a) para ejecutarse en ambos routers

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Convenciones

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

Antecedentes

Los estados OSPF para la formación de adyacencia son Down, Init, 2-way, Exstart, Exchange, Loading y Full. Puede haber una serie de razones por las que los vecinos OSPF (Open Shortest Path First) están bloqueados en el estado Exstart/Exchange. Este documento se centra en una discordancia de MTU entre vecinos OSPF que resulta en el estado Exstart/Exchange. Para obtener más detalles sobre cómo resolver problemas de OSPF, refiérase a Resolución de Problemas Comunes con OSPF .

Estado Exstart

Después de que dos routers OSPF vecinos establezcan una comunicación bidireccional y finalicen la elección de DR/BDR (en redes de acceso múltiple), los routers efectuarán una transición al estado exstart. En este estado, los routers vecinos establecen una relación Primario/Subordinado y determinan el número de secuencia del descriptor de base de datos (DBD) inicial que se utilizará mientras se intercambian los paquetes DBD.

Estado de intercambio

Una vez que Primary/Subordinate se ha negociado (el router con el ID de router más alto se convierte en el principal), los routers vecinos pasan al estado de Exchange. En este estado, los routers intercambian paquetes DBD, que describen la base de datos de estados de link completa. Los routers también envían paquetes de solicitud del estado del link, que solicitan anuncios más recientes del estado del link (LSA) de sus vecinos.

Aunque la transición de los vecinos OSPF a través de los estados Exstart/Exchange durante el proceso normal de construcción de adyacencia OSPF, no es normal que los vecinos OSPF se atasquen en este estado. La siguiente sección describe la razón más común por la que los vecinos OSPF se atascan en este estado. Consulte Comprensión de los Estados Vecinos OSPF para obtener más información sobre los diferentes estados OSPF.

Vecinos bloqueados en estado Exstart/Exchange

El problema ocurre con mayor frecuencia cuando intenta ejecutar OSPF entre un router de Cisco y otro router de proveedor. El problema se produce cuando los parámetros de la unidad de transmisión máxima (MTU) para neighboring las interfaces del router no coinciden. Si el router con la MTU más alta envía un paquete mayor que la MTU establecida en el router vecino, el router vecino ignora el paquete. Cuando se produce este problema, el resultado de la show ip ospf neighbor muestra un resultado similar al que se muestra en esta figura.

Router 6 y Router7 Connect via Frame Relay

Esta sección describe una recreación real de este problema.

Los routers 6 y 7 de esta figura están conectados a través de Frame Relay y el router 6 se ha configurado con 5 rutas estáticas redistribuidas en OSPF. La interfaz serial en el Router 6 tiene la MTU predeterminada de 1500, mientras que la interfaz serial en el Router 7 tiene una MTU de 1450. Cada configuración del router se muestra en la tabla (solo se muestra la información de configuración necesaria):

interface Serial2

!--- MTU is set to its default value of 1500.

 no ip address
 no ip directed-broadcast
 encapsulation frame-relay
 no ip mroute-cache
 frame-relay lmi-type ansi
!
interface Serial2.7 point-to-point
 ip address 10.170.10.6 255.255.255.0
 no ip directed-broadcast
 frame-relay interface-dlci 101
!
router ospf 7
 redistribute static subnets
 network 10.170.10.0 0.0.0.255 area 0
!
ip route 192.168.0.10 255.255.255.0 Null0
ip route 192.168.10.10 255.255.255.0 Null0
ip route 192.168.10.0 255.255.255.0 Null0
ip route 192.168.37.10 255.255.255.0 Null0
ip route 192.168.38.10 255.255.255.0 Null0

interface Serial0
 mtu 1450
 no ip address
 no ip directed-broadcast
 encapsulation frame-relay
 frame-relay lmi-type ANSI
!
interface Serial0.6 point-to-point
 ip address 172.16.7.11 255.255.255.0
 no ip directed-broadcast
 frame-relay interface-dlci 110
!
router ospf 7
 network 172.16.11.6 0.0.0.255 area 0

El resultado del comando show ip ospf neighbor para cada router es:

router-6#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
172.16.7.11      1   EXCHANGE/  -    00:00:36    172.16.7.11    Serial2.7
router-6#

router-7#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.170.10.6      1   EXSTART/  -     00:00:33    10.170.10.6    Serial0.6
router-7#

El problema sucede cuando el router 6 envía un paquete DBD mayor a 1450 bytes (MTU del router 7) mientras se encuentra en estado de intercambio. Use el comando debug ip packet y debug ip ospf adj en cada router para ver el proceso de adyacencia OSPF a medida que tiene lugar. El resultado del Router 6 y 7 de los pasos 1 al 14 es:

1. Resultado de depuración del router 6:

   <<<ROUTER 6 IS SENDING HELLOS BUT HEARS NOTHING, STATE OF NEIGHBOR IS DOWN>>>
   
   00:03:53: OSPF: 172.16.7.11 address 172.16.7.11 on 
   Serial2.7 is dead
   00:03:53: OSPF: 172.16.7.11 address 172.16.7.11 on 
   Serial2.7 is dead, state DOWN

2. Resultado de depuración del router 7:

   <<<OSPF NOT ENABLED ON ROUTER7 YET>>>

3. Resultado de depuración del router 6:

   <<<ROUTER 6 SENDING HELLOS>>>
   
   00:03:53: IP: s=10.170.10.6 (local), d=224.0.0.5 
   (Serial2.7), len 64, sending broad/multicast, proto=89
   00:04:03: IP: s=10.170.10.6 (local), d=224.0.0.5 
   (Serial2.7), Len 64, sending broad/multicast, proto=89

4. Resultado de depuración del router 7:

   <<<OSPF NOT ENABLED ON ROUTER7 YET>>>

5. Resultado de depuración del router 7:

   <<<OSPF ENABLED ON ROUTER 7, BEGINS SENDING HELLOS AND BUILDING A ROUTER LSA>>>
   
   00:17:44: IP: s=172.16.7.11 (local), d=224.0.0.5 
   (Serial0.6), Len 64, sending broad/multicast, proto=89
   00:17:44: OSPF: Build router LSA for area 0, 
   router ID 172.16.7.11, seq 0x80000001

6. Resultado de depuración del router 6:

   <<<RECEIVE HELLO FROM ROUTER7>>>
   
   00:04:04: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5, 
   Len 64, rcvd 0, proto=89
   00:04:04: OSPF: Rcv hello from 172.16.7.11 area 0 from 
   Serial2.7 172.16.7.11
   00:04:04: OSPF: End of hello processing

7. Resultado de depuración del router 6:

   <<<ROUTER 6 SEND HELLO WITH ROUTER7 ROUTERID IN THE HELLO PACKET>>>
   
   00:04:13: IP: s=10.170.10.6 (local), d=224.0.0.5 
   (Serial2.7), Len 68, sending broad/multicast, proto=89

8. Resultado de depuración del router 7:

   <<<ROUTER 7 RECEIVES HELLO FROM ROUTER6 CHANGES STATE TO 2WAY>>>
   
   00:17:53: IP: s=10.170.10.6 (Serial0.6), d=224.0.0.5, 
   Len 68, rcvd 0, proto=89
   00:17:53: OSPF: Rcv hello from 10.170.10.6 area 0 from 
   Serial0.6 10.170.10.6
   00:17:53: OSPF: 2 Way Communication to 10.170.10.6 on 
   Serial0.6, state 2WAY

9. Resultado de depuración del router 7:

   <<<ROUTER 7 SENDS INITIAL DBD PACKET WITH SEQ# 0x13FD>>>
   
   00:17:53: OSPF: Send DBD to 10.170.10.6 on Serial0.6 
   seq 0x13FD opt 0x2 flag 0x7 Len 32
   00:17:53: IP: s=172.16.7.11 (local), d=224.0.0.5 
   (Serial0.6), Len 52, sending broad/multicast, proto=89
   00:17:53: OSPF: End of hello processing

10. Resultado de depuración del router 6:

    <<<ROUTER 6 RECEIVES ROUTER7'S INITIAL DBD PACKET CHANGES STATE TO 2-WAY>>>
    
    00:04:13: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5, 
    Len 52, rcvd 0, proto=89
    00:04:13: OSPF: Rcv DBD from 172.16.7.11 on Serial2.7 
    seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state INIT
    00:04:13: OSPF: 2 Way Communication to 172.16.7.11 on 
    Serial2.7, state 2WAY

11. Resultado de depuración del router 6:

    <<<ROUTER 6 SENDS DBD PACKET TO ROUTER 7 (PRIMARY/SUBORDINATE NEGOTIATION - ROUTER 6 IS SUBORDINATE)>>>
    
    00:04:13: OSPF: Send DBD to 172.16.7.11 on Serial2.7 
    seq 0xE44 opt 0x2 flag 0x7 Len 32 
    00:04:13: IP: s=10.170.10.6 (local), d=224.0.0.5 (Serial2.7), 
    Len 52, sending broad/multicast, proto=89 
    00:04:13: OSPF: NBR Negotiation Done. We are the SLAVE

12. Resultado de depuración del router 7:

    <<<RECEIVE ROUTER 6'S INITIAL DBD PACKET (MTU MISMATCH IS RECOGNIZED)>>>
    
    00:17:53: IP: s=10.170.10.6 (Serial0.6), d=224.0.0.5, 
    Len 52, rcvd 0, proto=89
    00:17:53: OSPF: Rcv DBD from 10.170.10.6 on Serial0.6 
    seq 0xE44 opt 0x2 flag 0x7 Len 32 mtu 1500 state EXSTART
    00:17:53: OSPF: Nbr 10.170.10.6 has larger interface MTU 

13. Resultado de depuración del router 6:

    <<<SINCE ROUTER 6 IS SUBORDINATE SEND DBD PACKET WITH LSA HEADERS, SAME SEQ# (0x13FD) TO ACK ROUTER 7'S DBD. (NOTE SIZE OF PKT)>>>
    
    00:04:13: OSPF: Send DBD to 172.16.7.11 on Serial2.7 
    seq 0x13FD opt 0x2 flag 0x2 Len 1472 
    00:04:13: IP: s=10.170.10.6 (local), d=224.0.0.5 (Serial2.7), 
    Len 1492, sending broad/multicast, proto=89

14. Resultado de depuración del router 7:

    <<<NEVER RECEIVE ACK TO ROUTER7'S INITIAL DBD, RETRANSMIT>>>
    
    00:17:54: IP: s=172.16.7.11 (local), d=224.0.0.5 
    (Serial0.6), Len 68, sending broad/multicast, proto=89
    00:18:03: OSPF: Send DBD to 10.170.10.6 on Serial0.6 
    seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: 
    Retransmitting DBD to 10.170.10.6 on Serial0.6 [1]

En este punto, el Router 6 continúa intentando ACEPTAR el paquete DBD inicial del Router 7.

00:04:13: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5,
Len 68, rcvd 0, proto=89
00:04:13: OSPF: Rcv hello from 172.16.7.11 area 0 from
Serial2.7 172.16.7.11
00:04:13: OSPF: End of hello processing

00:04:18: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5,
Len 52, rcvd 0, proto=89
00:04:18: OSPF: Rcv DBD from 172.16.7.11 on Serial2.7 
seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state EXCHANGE

00:04:18: OSPF: Send DBD to 172.16.7.11 on Serial2.7 
seq 0x13FD opt 0x2 flag 0x2 Len 1472
00:04:18: IP: s=10.170.10.6 (local), d=224.0.0.5 
(Serial2.7), Len 1492, sending broad/multicast, proto=89

00:04:23: IP: s=10.170.10.6 (local), d=224.0.0.5 
(Serial2.7), Len 68, sending broad/multicast, proto=89

00:04:23: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5,
Len 52, rcvd 0, proto=89
00:04:23: OSPF: Rcv DBD from 172.16.7.11 on Serial2.7
seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state EXCHANGE

El Router 7 nunca obtiene una ACK del Router 6 porque el paquete DBD del Router 7 es demasiado grande para la MTU del Router 7. El router 7 retransmite repetidamente el paquete DBD.

0:17:58: IP: s=172.16.7.11 (local), d=224.0.0.5
(Serial0.6), Len 52, sending broad/multicast, proto=89
00:18:03: OSPF: Send DBD to 10.170.10.6 on Serial0.6 
seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: 
Retransmitting DBD to 10.170.10.6 on Serial0.6 [2]

00:18:03: IP: s=172.16.7.11 (local), d=224.0.0.5 
(Serial0.6), Len 52, sending broad/multicast, proto=89
00:18:03: IP: s=10.170.10.6 (Serial0.6), d=224.0.0.5, 
Len 68, rcvd 0, proto=89
00:18:03: OSPF: Rcv hello from 10.170.10.6 area 0 from
Serial0.6 10.170.10.6
00:18:03: OSPF: End of hello processing

00:18:04: IP: s=172.16.7.11 (local), d=224.0.0.5 
(Serial0.6), Len 68, sending broad/multicast, proto=89

00:18:03: OSPF: Send DBD to 10.170.10.6 on Serial0.6 
seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: 
Retransmitting DBD to 10.170.10.6 on Serial0.6 [3]

00:18:08: IP: s=172.16.7.11 (local), d=224.0.0.5 
(Serial0.6), Len 52, sending broad/multicast, proto=89
router-7#

Debido a que el Router 6 tiene una MTU más alta, continúa aceptando el paquete DBD del Router 7, intenta reconocerlos y permanece en el estado EXCHANGE.

Debido a que el Router 7 tiene una MTU más baja, ignora los paquetes DBD junto con el ACK del Router 6, continúa retransmitiendo el paquete DBD inicial y permanece en el estado EXSTART.

En los pasos 9 y 11, el router 7 y el router 6 envían sus primeros paquetes DBD con el indicador 0x7 configurado como parte de la negociación principal/subordinada. Después de Primary/Subordinate , el Router 7 se elige como Principal debido a su mayor Router-ID. Los indicadores de los pasos 13 y 14 muestran claramente que el router 7 es principal (indicador 0x7) y el router 6 es secundario (indicador 0x2).

En el paso 10, el router 6 recibe el paquete DBD inicial del router 7 y pasa su estado a bidireccional.

En el paso 12, el Router 7 recibe el paquete DBD inicial del Router 6 y reconoce una discordancia de MTU. (El Router 7 puede reconocer una falta de coincidencia de MTU ya que el Router 6 incluye su MTU de interfaz en el campo de MTU de interfaz del paquete DBD). El router 7 rechaza el DBD inicial del router 6. El router 7 retransmite el paquete DBD inicial.

El paso 13 muestra que el router 6, como subordinate, adopta el número de secuencia del router 7 y envía su segundo paquete DBD que contiene los encabezados de sus LSA, lo que aumenta el tamaño del paquete. Sin embargo, el Router 7 nunca recibe este paquete DBD porque es más grande que la MTU del Router 7.

Después del paso 13, el Router 7 continúa retransmitiendo el paquete DBD inicial al Router 6, mientras que el Router 6 continúa enviando paquetes DBD que se adhieren al número de secuencia primario. Este loop continúa indefinidamente, lo que evita que cualquiera de los routers realice la transición fuera del estado exstart/exchange.

Solución

Dado que el problema es causado por MTU no coincidentes, la solución es cambiar la MTU del router para que coincida con la MTU del vecino.

Nota: Cisco IOS Software Release 12.0(3) introdujo la detección de discordancia de MTU de interfaz. Esta detección involucra el OSPF que anuncia la MTU de interfaz en los paquetes DBD, que está de acuerdo con el OSPF RFC 2178, apéndice G.9. Cuando un router recibe un paquete DBD que se anuncia con una MTU mayor que la que el router puede recibir, el router ignora el paquete DBD y el estado vecino permanece en Exstart. Esto evita la formación de una adyacencia. Para solucionar este problema, asegúrese de que la MTU sea la misma en ambos extremos de un link.

En Cisco IOS Software 12.01(3), el comando de configuración de interfaz ip ospf mtu-ignore también se introdujo para desactivar la detección de discordancia de MTU; sin embargo, esto sólo es necesario en casos raros, como se muestra en este diagrama:

Puerto de interfaz de datos distribuidos por fibra (FDDI)

El diagrama anterior muestra un puerto de Interfaz de datos distribuidos por fibra (FDDI) en un Cisco Catalyst 5000 con un Módulo de switch de ruta (RSM) conectado a una interfaz FDDI en el Router 2. La LAN virtual (VLAN) en el RSM es una interfaz Ethernet virtual con una MTU de 1500, y la interfaz FDDI en el Router 2 tiene una MTU de 4500. Cuando se recibe un paquete en el puerto FDDI del switch, se dirige a la placa de interconexiones y la conversión/fragmentación de FDDI a Ethernet ocurre dentro del propio switch. Esta es una configuración válida, pero con la función de detección de discordancia de MTU, la adyacencia OSPF no se forma entre el router y el RSM. Dado que FDDI y Ethernet MTU son diferentes, este comando ip ospf mtu-ignore es útil en la interfaz VLAN del RSM para detener la detección OSPF de discordancia de MTU y forma la adyacencia.

Es importante notar que la discordancia de MTU, aunque la más común, no es la única razón por la que los vecinos OSPF se atascan en el estado Exstart/Exchange. El problema es principalmente causa de la incapacidad de intercambiar satisfactoriamente paquetes DBD. Sin embargo, la causa principal podría ser cualquiera de las siguientes:

• discrepancia de MTU

• La unidifusión se ha roto. En el estado Exstart, el router envía un paquete de unidifusión al vecino para seleccionar Primary y Subordinate. Esto es real salvo que exista un link punto a punto, en cuyo caso envía un paquete multidifusión. Estas son las posibles causas:

  • Una asignación incorrecta del circuito virtual (VC) en un Asynchronous Transfer Mode (ATM) o un entorno Frame Relay en una red de alta redundancia.

  • Problema de MTU, que significa que los routers sólo pueden hacer ping a un paquete de cierta longitud.

  • La lista de acceso bloquea el paquete de unidifusión.

  • NAT se ejecuta en el router y traduce el paquete de unidifusión.

• Vecino entre PRI y BRI/dialer.

• Ambos routers tienen el mismo Router-ID (configuración incorrecta).

Además, la sección 10.3 de OSPF RFC 2328, establece que el proceso Exstart/Exchange se inicia para cualquiera de estos eventos (cualquiera de los cuales podría ser causado por problemas internos de software):

• No Coincide El Número De Secuencia.

  • Número de secuencia DD inesperado.

  • El bit "I" está configurado inesperadamente.

  • Campo de opción diferente del último campo de opción recibido en el paquete DBD.

• BadLSReq

  • El vecino envía LSA no reconocidos durante el proceso de intercambio.

  • El vecino solicitó un LSA durante el proceso de intercambio que no se puede encontrar.

Cuando OSPF no forma vecinos, considere los factores mencionados anteriormente, como el medio físico y el hardware de red, para resolver el problema.

Información Relacionada

• Estados vecinos OSPF
• Explicación de problemas del vecino OSPF
• Asistencia técnica y descargas de Cisco