Por que os vizinhos OSPF estão travados no estado Exstart/Exchange?

Introduction

Os estados OSPF para a formação de adjacência são Down, Init, Attempt, 2-way, Exstart, Exchange, Loading e Full. Pode haver um número de motivos pelos quais os vizinhos Open Shortest Path First (OSPF) estejam presos em estado exstart/exchange. Este documento concentra-se em uma compatibilidade da MTU entre os vizinhos OSPF, resultando em um estado exstart/exchange. Para obter mais detalhes sobre o troubleshooting do OSPF, consulte Troubleshooting OSPF.

Prerequisites

Requirements

Os leitores deste documento devem estar familiarizados com a operação e configuração básicas do OSPF, especialmente sobre 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) em execução em ambos os roteadores

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Convenções

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

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 mestre/escravo e determinam o número de sequência do descritor de banco de dados inicial (DBD) a ser usado durante a troca de pacotes DBD.

Estado de intercâmbio

Depois que a relação mestre/escravo tiver sido negociada (o roteador com o maior Router-ID se tornará o mestre), os roteadores vizinhos farão a transição para o estado de troca. 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 através dos 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. O motivo a seguir é o mais comum para a estabilização de vizinhos OSPF nesse estado. Consulte Estados vizinhos do OSPF para saber mais sobre os diferentes estados do OSPF.

Vizinhos presos no estado Exstart/Exchange

O problema ocorre com mais frequência ao tentar executar o OSPF entre um roteador Cisco e o roteador de outro fornecedor. O problema ocorre quando as configurações de MTU (Maximum Transmission Unit, unidade máxima de transmissão) para interfaces de roteador vizinhas não correspondem. Se o roteador com MTU maior enviar um pacote maior que o MTU definido no roteador vizinho, o roteador vizinho ignorará o pacote.0 Quando esse problema ocorre, a saída do comando show ip ospf neighbor exibe uma saída semelhante à mostrada abaixo.

Uma recriação real deste problema é descrita nesta seção.

Os roteadores 6 e 7 na topologia acima estão conectados via 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 abaixo (somente as informações de configuração necessárias são mostradas):

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

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
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#

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 debug ip ospf adj em cada 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:

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

   OSPF NOT ENABLED ON ROUTER7 YET

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

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

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=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#

Como o Roteador 6 tem um MTU maior, ele continua a aceitar o pacote DBD do Roteador 7, tenta confirmá-los e permanece no estado EXCHANGE.

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

Vejamos alguns dos passos acima. Nas etapas 9 e 11, os roteadores 7 e 6 enviam seus primeiros pacotes DBD com o flag 0x7 definido como parte da negociação Master/Slave. Após a determinação de Mestre/Escravo, o Roteador 7 é eleito Mestre por causa de seu Router-ID mais alto. Os flags nas etapas 13 e 14 mostram claramente que o Roteador 7 é Mestre (Flag 0x7) e o Roteador 6 é Escravo (Flag 0x2).

Na etapa 10, o Roteador 6 recebe o pacote DBD inicial do Roteador 7 e faz a transição de 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 escravo, adota o número de sequência do Roteador 7 e envia seu segundo pacote DBD contendo os cabeçalhos de seus LSAs, o que aumenta o tamanho do pacote. No entanto, o Roteador 7 nunca recebe esse pacote DBD porque é maior que o MTU do Roteador 7.

Após o passo 13, o roteador 7 continua retransmitindo o pacote DBD inicial ao roteador 6, enquanto o roteador 6 continua enviando os pacotes DBD que seguem o número de seqüência mestre. Esse loop continua indefinidamente, o que impede que qualquer um dos roteadores faça a transição para fora do estado exstart/exchange.

A solução

Como o problema é causado por MTUs incompatíveis, a solução é alterar o MTU do roteador para corresponder ao MTU do vizinho. Observe que o Cisco IOS não suporta uma alteração do MTU físico em uma interface LAN (como Ethernet ou Token Ring). Quando o problema ocorre entre um roteador Cisco e outro roteador de fornecedor sobre a mídia de LAN, ajuste a MTU no roteador de outro fornecedor.

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 anúncio do OSPF sobre a MTU da interface nos pacotes DBD, que está de acordo com o RFC 2178 do OSPF, apêndice G.9. Quando um roteador recebe um pacote DBD anunciando um MTU maior do que pode receber, esse roteador ignora o pacote DBD e o estado do vizinho permanece em exstart. Isso impede a formação de uma adjacência. Para corrigir esse problema, certifique-se de que a MTU seja a mesma em ambas as 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 acima mostra uma porta FDDI (Fiber Distributed Data Interface) em um Cisco Catalyst 5000 com um RSM (Route Switch Module) conectado a uma interface FDDI no Roteador 2. A LAN virtual (VLAN) no RSM é uma interface Ethernet virtual com MTU de 1500, e a interface FDDI no Roteador 2 tem MTU de 4500. Quando um pacote é recebido na porta FDDI do switch, ele vai para o backplane 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 de OSPF não é formada entre o roteador e o RSM. Como o FDDI e o Ethernet MTU são diferentes, este comando ip ospf mtu-ignore é útil na interface VLAN do RSM para que o OSPF pare de detectar incompatibilidade e de MTU e forme a adjacência.

É importante observar que a incompatibilidade de MTU, embora 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 principal pode ser qualquer uma destas:

• incompatibilidade de MTU

• O Unicast foi quebrado. No estado exstart, o roteador envia um pacote unicast ao vizinho para eleger master e slave. 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, o que significa que os roteadores podem fazer ping apenas de pacotes com um determinado tamanho.

  • A lista de acesso está bloqueando o pacote unicast.

  • O NAT está sendo executado no roteador e está convertendo o pacote unicast.

• Vizinho entre PRI e BRI/dialer.

• Ambos os roteadores possuem o mesmo ID de roteador (erro de configuração).

Além disso, a RFC 2328 do OSPF, seção 10.3, afirma que o processo de exstart/exchange é iniciado para qualquer um desses eventos (qualquer um deles pode ser causado por problemas internos de software):

• SequenceNumberMismatch

  • Número de sequência DD inesperado

  • O bit "I" está definido inesperadamente

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

• LSReqIncorreto

  • 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 acima, como a mídia física e o hardware de rede, para solucionar o problema.

Informações Relacionadas

• Estados vizinhos de OSPF
• Problemas vizinhos ao OSPF explicados
• Suporte Técnico - Cisco Systems