A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
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.
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.
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.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
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.
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.
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):
Configuração do Roteador 6 | Configuração do Roteador 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 |
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 é:
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
Saída de depuração do roteador 7:
OSPF NOT ENABLED ON ROUTER7 YET
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
Saída de depuração do roteador 7:
OSPF NOT ENABLED ON ROUTER7 YET
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
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
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
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
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
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
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
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
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
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.
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.