IP : Open Shortest Path First (OSPF)

¿Por Qué se Atascan los Vecinos OSPF en el Estado Exstart/Exchange?

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


Contenido


Introducción

Los estados OSPF para la formación de adyacencia son Down, Init, Attempt, 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 MTU entre los vecinos OSPF que da como resultado el estado Exstart/Exchange. Para obtener más detalles sobre el Troubleshooting de OSPF, consulte Troubleshooting de OSPF.

prerrequisitos

Requisitos

Los Quien lea este documento deben ser familiares con

Componentes Utilizados

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

  • Cisco 2503 Router

  • Software Release 12.2(24a) del � del Cisco IOS que se ejecuta en ambo 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 la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Convenciones

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

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 routeres de la vencidad establecen una relación maestro/satélite y determinan el número de secuencia inicial del Database Descriptor (DBD) para utilizar mientras que intercambian los paquetes del DBD.

Estado de intercambio

Una vez que se ha negociado la relación maestro/satélite (el router con el Router-ID más alto hace el master), la transición de los routeres de la vencidad en el estado de intercambio. 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 del estado Exstart/Exchange durante el proceso de creación de adyacencias normal OSPF, él no sea normal para que los vecinos OSPF sean pegados en este estado. A continuación se describe la razón más común por la cual los vecinos OSPF se atascan en este estado. Refiera al estado de vecino OSPF para aprender más sobre los diversos estados OSPF.

Vecinos bloqueados en estado Exstart/Exchange

El problema ocurre lo más frecuentemente al intentar ejecutar el OSPF entre un router Cisco y el router de otro vendedor. El problema ocurre cuando las configuraciones de la Unidad máxima de transmisión (MTU) (MTU) para las interfaces del router de la vencidad no hacen juego. Si el router con el MTU más alto envía un paquete más grande que el MTU fijado en el router de la vencidad, el router de la vencidad ignore el packet.0 cuando ocurre este problema, la salida del comando show ip ospf neighbor visualiza la salida similar eso mostrada abajo.

Una verdadera recreación de este problema se describe en esta sección.

/image/gif/paws/13684/12a_01.gif

El router 6 y el router 7 en la topología antedicha están conectados vía el Frame Relay y han configurado al router 6 con 5 Static rutas redistribuidas en el OSPF. La interfaz serial en el router 6 tiene el MTU predeterminado de 1500, mientras que la interfaz serial en el router 7 tiene un MTU de 1450. Cada configuración del router se muestra en la tabla abajo (solamente se muestra la información de configuración necesaria):

Configuración del Router 6 Configuración del router 7
interface Serial2

!--- MTU sets to it's 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 170.170.11.6 255.255.255.0
no ip directed-broadcast
frame-relay interface-dlci 101
!
router ospf 7
redistribute static subnets
network 170.170.11.0 0.0.0.255 area 0

ip route 192.79.34.0 255.255.255.0 Null0
ip route 192.79.35.0 255.255.255.0 Null0
ip route 192.79.36.0 255.255.255.0 Null0
ip route 192.79.37.0 255.255.255.0 Null0
ip route 192.79.38.0 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 170.170.11.7 255.255.255.0
no ip directed-broadcast
frame-relay interface-dlci 110!
!

router ospf 7
network 170.170.11.0 0.0.0.255 area 0

El comando show ip ospf neighbor hecho salir para cada router es:

router-6# show ip ospf neighbor

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

router-7# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
170.170.11.6      1   EXSTART/  -     00:00:33    170.170.11.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. Utilice el paquete del IP del debug y los comandos debug ip ospf adj en cada router de ver el proceso de la adyacencia OSPF como ocurre. La salida del router 6 y 7 de los pasos 1 a 14 es:

  1. Salida de los debugs del router 6:

    ***ROUTER6 IS SENDING HELLOS BUT HEARS NOTHING, 
    STATE OF NEIGHBOR IS DOWN
    00:03:53: OSPF: 170.170.11.7 address 170.170.11.7 on 
    Serial2.7 is dead
    00:03:53: OSPF: 170.170.11.7 address 170.170.11.7 on 
    Serial2.7 is dead, state DOWN
  2. Salida de los debugs del router 7:

    OSPF NOT ENABLED ON ROUTER7 YET
  3. Salida de los debugs del router 6:

    ***ROUTER6 SENDING HELLOS
    00:03:53: IP: s=170.170.11.6 (local), d=224.0.0.5 
    (Serial2.7), len 64, sending broad/multicast, proto=89
    00:04:03: IP: s=170.170.11.6 (local), d=224.0.0.5 
    (Serial2.7), Len 64, sending broad/multicast, proto=89
  4. Salida de los debugs del router 7:

    OSPF NOT ENABLED ON ROUTER7 YET
  5. Salida de los debugs del router 7:

    ***OSPF ENABLED ON ROUTER7, BEGINS SENDING 
    HELLOS AND BUILDING A ROUTER LSA
    00:17:44: IP: s=170.170.11.7 (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 170.170.11.7, seq 0x80000001
  6. Salida de los debugs del router 6:

    ***RECEIVE HELLO FROM ROUTER7
    00:04:04: IP: s=170.170.11.7 (Serial2.7), d=224.0.0.5, 
    Len 64, rcvd 0, proto=89
    00:04:04: OSPF: Rcv hello from 170.170.11.7 area 0 from 
    Serial2.7 170.170.11.7
    00:04:04: OSPF: End of hello processing
  7. Salida de los debugs del router 6:

    ***ROUTER6 SEND HELLO WITH ROUTER7 ROUTERID 
    IN THE HELLO PACKET
    00:04:13: IP: s=170.170.11.6 (local), d=224.0.0.5 
    (Serial2.7), Len 68, sending broad/multicast, proto=89
  8. Salida de los debugs del router 7:

    ***ROUTER7 RECEIVES HELLO FROM ROUTER6 CHANGES 
    STATE TO 2WAY
    00:17:53: IP: s=170.170.11.6 (Serial0.6), d=224.0.0.5, 
    Len 68, rcvd 0, proto=89
    00:17:53: OSPF: Rcv hello from 170.170.11.6 area 0 from 
    Serial0.6 170.170.11.6
    00:17:53: OSPF: 2 Way Communication to 170.170.11.6 on 
    Serial0.6, state 2WAY
  9. Salida de los debugs del router 7:

    ***ROUTER7 SENDS INITIAL DBD PACKET WITH SEQ# 0x13FD
    00:17:53: OSPF: Send DBD to 170.170.11.6 on Serial0.6 
    seq 0x13FD opt 0x2 flag 0x7 Len 32
    00:17:53: IP: s=170.170.11.7 (local), d=224.0.0.5 
    (Serial0.6), Len 52, sending broad/multicast, proto=89
    00:17:53: OSPF: End of hello processing
  10. Salida de los debugs del router 6:

    ***ROUTER6 RECEIVES ROUTER7'S INITIAL DBD PACKET 
    CHANGES STATE TO 2-WAY
    00:04:13: IP: s=170.170.11.7 (Serial2.7), d=224.0.0.5, 
    Len 52, rcvd 0, proto=89
    00:04:13: OSPF: Rcv DBD from 170.170.11.7 on Serial2.7 
    seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state INIT
    00:04:13: OSPF: 2 Way Communication to 170.170.11.7 on 
    Serial2.7, state 2WAY
  11. Salida de los debugs del router 6:

    ***ROUTER6 SENDS DBD PACKET TO ROUTER7 
    (MASTER/SLAVE NEGOTIATION - ROUTER6 IS SLAVE)
    00:04:13: OSPF: Send DBD to 170.170.11.7 on Serial2.7 
    seq 0xE44 opt 0x2 flag 0x7 Len 32
    00:04:13: IP: s=170.170.11.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. Salida de los debugs del router 7:

    ***RECEIVE ROUTER6'S INITIAL DBD PACKET 
    (MTU MISMATCH IS RECOGNIZED)
    00:17:53: IP: s=170.170.11.6 (Serial0.6), d=224.0.0.5, 
    Len 52, rcvd 0, proto=89
    00:17:53: OSPF: Rcv DBD from 170.170.11.6 on Serial0.6 
    seq 0xE44 opt 0x2 flag 0x7 Len 32 mtu 1500 state EXSTART
    00:17:53: OSPF: Nbr 170.170.11.6 has larger interface MTU 
  13. Salida de los debugs del router 6:

    ***SINCE ROUTER6 IS SLAVE SEND DBD PACKET WITH 
    LSA HEADERS, 
    SAME SEQ# (0x13FD) TO ACK ROUTER7'S DBD. (NOTE SIZE OF PKT)
    00:04:13: OSPF: Send DBD to 170.170.11.7 on Serial2.7 
    seq 0x13FD opt 0x2 flag 0x2 Len 1472
    00:04:13: IP: s=170.170.11.6 (local), d=224.0.0.5 
    (Serial2.7), Len 1492, sending broad/multicast, proto=89
  14. Salida de los debugs del router 7:

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

En este momento, el router 6 guarda el intentar al ACK de la inicial paquete DBD del router 7.

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

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

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

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

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

El router 7 nunca consigue un ACK del router 6 porque paquete DBD del router 7 es demasiado grande para el router 7 MTU. El router 7 retransmite en varias ocasiones paquete DBD.

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

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

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

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

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

Porque el router 6 tiene un MTU más alto, continúa validando paquete DBD del router 7, intenta reconocerlo, y permanece en el estado de intercambio.

Porque el router 7 tiene un MTU inferior, ignora los paquetes del DBD junto con el ACK del router 6, continúa retransmitiendo la inicial paquete DBD, y permanece en el estado EXSTART.

Miremos algunos de los pasos arriba. En el paso 9 y 11, el router 7 y el router 6 envían sus primeros paquetes del DBD con el indicador 0x7 fijado como parte de la negociación maestro/satélite. Después de la determinación maestro/satélite, eligen al router 7 pues el master debido a ella es un Router-ID más alto. Los indicadores en los pasos 13 y 14 muestran claramente que el router 7 es master (indicador 0x7) y el router 6 es auxiliar (indicador 0x2).

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

En el paso 12, el router 7 recibe la inicial del router 6 paquete DBD y reconoce una discordancía 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 DBD inicial del router 6 es rechazado por el router 7. que el router 7 retransmite la inicial paquete DBD.

El paso 13 muestra que el router 6, como esclavo, adopta al router 7 números de secuencia y envía su segundo paquete DBD que contiene las encabezados de sus LSA, que aumenta los tamaños del paquete. Sin embargo, el router 7 nunca recibe esto paquete DBD porque es más grande que el router 7 MTU.

Luego del paso 13, el router 7 continúa con la retransmisión del paquete DBD inicial al router 6, mientras que el router 6 continúa con el envío de paquetes DBD que siguen el número de secuencia maestra. Este loop continúa indefinidamente, que previene a cualquier router del estado Exstart/Exchange de los de la transición.

La solución

Puesto que el problema es causado por la discrepenacia de MTU, la solución es cambiar a cualquier router MTU para hacer juego al vecino MTU. Observe que el Cisco IOS no apoya a un chang del MTU físico en una interfaz LAN (tal como Ethernetes o Token Ring). Cuando el problema ocurre entre un router Cisco y otro router del proveedor sobre el medio LAN, ajuste el MTU en el router del otro vendedor.

Nota: Detección introducida Cisco IOS Software Release 12.0(3) de la discordancía del MTU de interfaz. Esta detección implica el OSPF que hace publicidad del MTU de interfaz en los paquetes del DBD, que está de acuerdo con el RFC 2178 OSPFleavingcisco.com , el apéndice G.9. Cuando un router recibe un paquete DBD que anuncia una MTU mayor a la que el router puede recibir, el router ignora el paquete DBD y el estado del vecino permanece en exstart. Esto previene la formación de una adyacencia. Para reparar este problema, asegúrese de que el MTU es lo mismo en los ambos extremos de un link.

En Cisco IOS Software 12.01(3), presentaron al comando interface configuration del ip ospf mtu-ignore también de apagar la detección de incompatibilidad de MTU; sin embargo, esto se necesita solamente en las instancias poco frecuentes, tal y como se muestra en de este diagrama:

12b.gif

El diagrama antedicho muestra un puerto del Fiber Distributed Data Interface (FDDI) en un Cisco Catalyst 5000 con un (RSM) del Route Switch Module conectado con una interfaz FDDI en el router2. El Virtual LAN (VLAN) en el RS es una interfaz Ethernet virtual con un MTU de 1500, y la interfaz FDDI en el router2 tiene un MTU de 4500. Cuando un paquete se recibe en el puerto FDDI del Switch, va al backplane y el FDDI a la conversión/a la fragmentación de los Ethernetes sucede dentro del Switch sí mismo. Esto es una configuración válida, pero con la característica de la detección de incompatibilidad de MTU, la adyacencia OSPF no se forma entre el router y el RS. Puesto que el FDDI y el MTU de Ethernet son diferentes, el comando ip ospf mtu-ignore es útil en la interfaz VLAN en el RSM para que el OSF deje de detectar discordancias de MTU y forme la adyacencia.

Es importante observar que la discordancía MTU, aunque el más común, no es la única razón que los vecinos OSPF consiguen pegados en el estado Exstart/Exchange. El problema es principalmente causa de la incapacidad de intercambiar satisfactoriamente paquetes DBD. Sin embargo, la causa raíz podía ser ua de los éstos:

  • Discordancía MTU

  • La unidifusión se ha roto. En el estado del exstart, el router envía un paquete de unidifusión al vecino para elegir el master y al esclavo. 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 MTU, que significa que los routers sólo pueden efectuar un ping en un paquete de una determinada longitud.

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

    • El NAT se está ejecutando en el router y está traduciendo el paquete de unidifusión.

  • Vecino entre el PRI y BRI/dialer.

  • Ambos routers tienen el mismo ID (error de configuración).

Además, el RFC 2328 OSPFleavingcisco.com , sección 10.3, estados que el exstart/proceso de intercambio está iniciado para ninguno de estos eventos (ningunos cuyo podría ser causado por los problemas de la interna del software):

  • SequenceNumberMismatch

    • Número de secuencia inesperado DD

    • “Me” bit fijan inesperado

    • Campo de opción diferente del campo de última opción recibido en paquete DBD

  • BadLSReq

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

    • El vecino pidió un LSA durante el proceso de intercambio que no puede ser encontrado

Cuando el OSPF no forma a los vecinos, considere los factores mencionados anteriormente, por ejemplo los medios físicos y el hardware para la conexión en red, para resolver problemas el problema.

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 13684