Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Convenciones

Antecedentes

Estado Exstart

Estado de intercambio

Vecinos bloqueados en estado Exstart/Exchange

Solución

Información Relacionada

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

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. 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, consulte Solución de problemas de 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 Estados de Vecino 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 ocurre 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 delshow 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 mediante 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):

Configuración del Router 6

Configuración del router 7

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 comandodebug ip packety debug ip ospf adjen 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 siguen el número de secuencia principal. 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 al OSPF que anuncia la MTU de interfaz en los paquetes DBD, lo cual está de acuerdo con el OSPFRFC 2178, apéndice G.9. Cuando un router recibe un paquete DBD que se anuncia 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), elip ospf mtu-ignoreEl comando de configuración de interfaz 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, estoip ospf mtu-ignorees ú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 OSPFRFC 2328, sección 10.3, 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 encuentra.

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

- Soporte Técnico - Cisco Systems