Identificar e Solucionar Problemas de Vizinhos OSPF Presos no Estado Exstart/Exchange

Introdução

Este documento descreve como solucionar problemas em situações em que os vizinhos do OSPF (Open Shortest Path First) estão presos nos estados Exstart e Exchange. 

Pré-requisitos

Requisitos

Recomenda-se que o usuário esteja familiarizado com a operação e a configuração básicas do OSPF, em particular, os estados vizinhos do OSPF.

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

• Cisco 2503 Routers

• Cisco IOS^®Software Release 12.2(24a) para ser executado em ambos os roteadores

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Conventions

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Informações de Apoio

Os estados do OSPF para formação de adjacência são Down, Init, 2-way, Exstart, Exchange, Loading e Full. Pode haver vários motivos pelos quais os vizinhos do OSPF (Open Shortest Path First) estão presos no estado Exstart/Exchange. Este documento enfoca uma incompatibilidade de MTU entre vizinhos OSPF que resulta no estado Exstart/Exchange. Para obter mais detalhes sobre como solucionar problemas do OSPF, consulte Identificar e Solucionar Problemas Comuns com o OSPF.

Estado de Exstart

Depois de dois roteadores vizinhos de OSPF estabelecerem comunicação bidirecional e concluírem a eleição VR/BDR (em redes multiacesso), os roteadores fazem transição para o estado exstart. Nesse estado, os roteadores vizinhos estabelecem uma relação Primária/Subordinada e determinam o número de sequência do descritor de banco de dados (DBD) inicial a ser usado enquanto os pacotes DBD são trocados.

Estado de intercâmbio

Uma vez negociada a relação (o roteador com o maior Router-ID se torna o Principal), Primary/Subordinate os roteadores vizinhos passam para o estado Exchange. Nesse estado, os roteadores trocam pacotes de DBD, que descrevem todo o banco de dados do estado de link. Os roteadores também enviam pacotes de solicitação de estado de enlace, que solicitam mais Anúncios de estado de enlace (LSA) dos vizinhos.

Embora os vizinhos OSPF façam a transição pelos estados Exstart/Exchange durante o processo normal de construção de adjacências OSPF, não é normal que os vizinhos OSPF fiquem presos nesse estado. A próxima seção descreve o motivo mais comum pelo qual os vizinhos OSPF ficam presos nesse estado. Consulte Compreender os Estados Vizinhos OSPF para saber mais sobre os diferentes estados OSPF.

Vizinhos presos no estado Exstart/Exchange

O problema ocorre com mais frequência quando você tenta executar o OSPF entre um roteador Cisco e outro roteador fornecedor. O problema ocorre quando as configurações da unidade máxima de transmissão (MTU) para neighboring as interfaces do roteador não correspondem. Se o roteador com a MTU mais alta enviar um pacote maior que a MTU definida no roteador vizinho, o roteador vizinho ignorará o pacote. Quando esse problema ocorre, a saída doshow ip ospf neighborcomando exibe uma saída semelhante à mostrada na figura.

Esta seção descreve uma recriação real deste problema.

O Roteador 6 e o Roteador 7 nesta figura estão conectados através do Frame Relay e o Roteador 6 foi configurado com 5 rotas estáticas redistribuídas no OSPF. A interface serial no Roteador 6 tem o MTU padrão de 1500, enquanto a interface serial no Roteador 7 tem um MTU de 1450. Cada configuração do roteador é mostrada na tabela (apenas as informações de configuração necessárias são mostradas):

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

A saída do comando show ip ospf neighbor para cada roteador é:

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#

O problema ocorre quando o roteador 6 envia um pacote DBD com mais de 1450 bytes (MTU do roteador 7) enquanto está no estado de intercâmbio. Use os comandos debug ip packet e em cada debug ip ospf adj roteador para ver o processo de adjacência OSPF à medida que ele ocorre. A saída dos Roteadores 6 e 7 das etapas 1 a 14 é:

1. Saída de depuração do roteador 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. Saída de depuração do roteador 7:

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

3. Saída de depuração do roteador 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. Saída de depuração do roteador 7:

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

5. Saída de depuração do roteador 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. Saída de depuração do roteador 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. Saída de depuração do roteador 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. Saída de depuração do roteador 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. Saída de depuração do roteador 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. Saída de depuração do roteador 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. Saída de depuração do roteador 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. Saída de depuração do roteador 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. Saída de depuração do roteador 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. Saída de depuração do roteador 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]

Neste ponto, o Roteador 6 continua tentando ACK do pacote DBD inicial do Roteador 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

O Roteador 7 nunca recebe um ACK do Roteador 6 porque o pacote DBD do Roteador 7 é muito grande para o MTU do Roteador 7. O roteador 7 retransmite repetidamente o pacote 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#

Como o Roteador 6 tem uma MTU mais alta, ele continua a aceitar o pacote DBD do Roteador 7, tenta confirmá-lo e permanece no estado EXCHANGE.

Como o Roteador 7 tem uma MTU mais baixa, ele ignora os pacotes de DBD junto com o ACK do Roteador 6, continua a retransmitir o pacote de DBD inicial e permanece no estado EXSTART.

Nas etapas 9 e 11, o Roteador 7 e o Roteador 6 enviam seus primeiros pacotes DBD com flag 0x7 definido como parte da negociação Primária/Subordinada. Após Primary/Subordinate a determinação, o Roteador 7 é eleito como Primário devido ao seu Router-ID mais alto. Os sinalizadores nas etapas 13 e 14 mostram claramente que o Roteador 7 é Primário (Sinalizador 0x7) e o Roteador 6 é Subordinado (Sinalizador 0x2).

Na etapa 10, o Roteador 6 recebe o pacote DBD inicial do Roteador 7 e faz a transição do seu estado para 2-way.

Na etapa 12, o roteador 7 recebe o pacote DBD inicial do roteador 6 e reconhece uma incompatibilidade de MTU. (O Roteador 7 é capaz de reconhecer uma incompatibilidade de MTU porque o Roteador 6 inclui a interface de MTU no campo de MTU da interface do pacote de DBD). O DBD inicial do Roteador 6 é rejeitado pelo Roteador 7. O roteador 7 retransmite o pacote DBD inicial.

A Etapa 13 mostra que o Roteador 6, como subordinate, adota o número de sequência do Roteador 7 e envia seu segundo pacote DBD que contém os cabeçalhos de seus LSAs, o que aumenta o tamanho do pacote. No entanto, o Roteador 7 nunca recebe esse pacote de DBD porque ele é maior que a MTU do Roteador 7.

Após a etapa 13, o Roteador 7 continua a retransmitir o pacote DBD inicial para o Roteador 6, enquanto o Roteador 6 continua a enviar pacotes DBD que aderem ao número de sequência principal. Esse loop continua indefinidamente, o que impede que qualquer um dos roteadores faça a transição para fora do estado exstart/exchange.

Solução

Como o problema é causado por MTUs incompatíveis, a solução é alterar o MTU do roteador para corresponder ao MTU vizinho.

Observação: o Cisco IOS Software Release 12.0(3) introduziu a detecção de incompatibilidade de MTU da interface. Essa detecção envolve o OSPF que anuncia o MTU da interface nos pacotes de DBD, que está de acordo com o RFC 2178 do OSPF, apêndice G.9. Quando um roteador recebe um pacote DBD que é anunciado, um MTU maior do que o roteador pode receber, o roteador ignora o pacote DBD e o estado do vizinho permanece em Exstart. Isso evita a formação de uma adjacência. Para corrigir esse problema, assegure-se de que a MTU seja a mesma nas duas extremidades de um link.

No Cisco IOS Software 12.01(3), o comando de configuração de interface ip ospf mtu-ignore também foi introduzido para desativar a detecção de incompatibilidade de MTU; no entanto, isso só é necessário em casos raros, como mostrado neste diagrama:

O diagrama anterior mostra uma porta de Interface de Dados Distribuídos em Fibra Óptica (FDDI - Fiber Distributed Data Interface) em um Cisco Catalyst 5000 com um Módulo de Comutação de Rotas (RSM - Route Switch Module) conectado a uma interface FDDI no Roteador 2. A LAN Virtual (VLAN) no RSM é uma interface Ethernet virtual com um MTU de 1500, e a interface FDDI no Roteador 2 tem um MTU de 4500. Quando um pacote é recebido na porta FDDI do switch, ele vai para o painel traseiro e a conversão/fragmentação de FDDI para Ethernet acontece dentro do próprio switch. Essa é uma configuração válida, mas com o recurso de detecção de incompatibilidade de MTU, a adjacência OSPF não é formada entre o roteador e o RSM. Como a FDDI e a Ethernet MTU são diferentes, esse comando ip ospf mtu-ignore é útil na interface VLAN do RSM para interromper a detecção de incompatibilidade de MTU no OSPF e forma a adjacência.

É importante observar que a incompatibilidade de MTU, embora seja a mais comum, não é a única razão pela qual os vizinhos OSPF ficam presos no estado Exstart/Exchange. O problema é causado com mais freqüência pela incapacidade de trocar com êxito os pacotes DBD. No entanto, a causa raiz pode ser qualquer um destes:

• incompatibilidade de MTU

• O Unicast foi quebrado. No estado Exstart, o roteador envia um pacote unicast ao vizinho para eleger Primary e Subordinate. Isso é verdade, exceto se você tem um link ponto a ponto; nesse caso, ele envia um pacote de transmissão múltipla. Estas são as possíveis causas:

  • Mapeamento incorreto de VC (circuito virtual) em um ATM (Asynchronous Transfer Mode, Modo Assíncrono de Transferência) ou em um ambiente Frame Relay de rede altamente redundante.

  • Problema de MTU, que significa que os roteadores podem fazer ping apenas em um pacote de um determinado comprimento.

  • A lista de acesso bloqueia o pacote unicast.

  • O NAT é executado no roteador e converte o pacote unicast.

• Vizinho entre PRI e BRI/discador.

• Ambos os roteadores têm o mesmo Router-ID (configuração incorreta).

Além disso, o OSPF RFC 2328, seção 10.3, afirma que o processo Exstart/Exchange é iniciado para qualquer um desses eventos (qualquer um dos quais pode ser causado por problemas internos de software):

• Número de sequência incompatível.

  • Número de sequência DD inesperado.

  • O bit "I" é definido inesperadamente.

  • Campo de opção diferente do último campo de opção recebido no pacote DBD.

• BadLSReq

  • O vizinho envia LSA não reconhecido durante um processo de troca.

  • O vizinho solicitou um LSA durante o processo de troca que não foi encontrado.

Quando o OSPF não formar vizinhos, considere os fatores mencionados anteriormente, como o meio físico e o hardware de rede, para solucionar o problema.

Informações Relacionadas

• Entender os Estados Vizinhos do OSPF
• Solucionar problemas de vizinhos OSPF
• Suporte técnico e downloads da Cisco