O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
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.
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.
Recomenda-se que o usuário esteja familiarizado com a operação e a configuração básicas do OSPF, particularmente com 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) para executar em ambos os roteadores
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. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Os estados do OSPF para a formação de adjacência são Desativado, Init, 2-way, Exstart, Exchange, Carregando e Completo. Pode haver um número de motivos pelos quais os vizinhos Open Shortest Path First (OSPF) estejam presos em 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 Solucionar problemas do OSPF .
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 Principal/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.
Quando a Primary/Subordinate
foi negociada (o roteador com o maior Router-ID se torna o Primário), 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 Estados vizinhos do OSPF para saber mais sobre os diferentes estados do OSPF.
O problema ocorre mais frequentemente 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 do comando show ip ospf neighbor
exibe uma saída semelhante à mostrada nesta figura.
O roteador 6 e o roteador 7 se conectam via Frame Relay
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):
Configuração do Roteador 6 | Configuração do Roteador 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 |
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 o 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:
<<<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
Saída de depuração do roteador 7:
<<<OSPF NOT ENABLED ON ROUTER7 YET>>>
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
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 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
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
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
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
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
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
Saída de depuração do roteador 6:
<<<ROUTER 6 SENDS DBD PACKET TO ROUTER 7 (PRIMARY/SUBORDINATE
NEGOTIATION - ROUTER 6 ISSUBORDINATE
)>>>
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 theSLAVE
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
Saída de depuração do roteador 6:
<<<SINCE ROUTER 6 ISSUBORDINATE
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
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 DBD junto com o ACK do Roteador 6, continua a retransmitir o pacote 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 Principal/Subordinada. Após Primary/Subordinate
, o Roteador 7 é eleito como Primário devido à sua maior Router-ID. 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 seguem o 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.
Como o problema é causado por MTUs incompatíveis, a solução é alterar o MTU do roteador para corresponder ao MTU vizinho.
Note: 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 OSPFRFC 2178, apêndice G.9. Quando um roteador recebe um pacote de DBD que é anunciado como um MTU maior do que o roteador pode receber, o roteador ignora o pacote de DBD e o estado do vizinho permanece em Exstart. Isso impede 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 ip ospf mtu-ignore
O comando de configuração de interface 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:
Porta de Interface de Dados Distribuídos em Fibra Óptica (FDDI - Fiber Distributed Data Interface)
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 - Virtual LAN) no RSM é uma interface Ethernet virtual com uma MTU de 1500 e a interface FDDI no Roteador 2 tem uma 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, isso ip ospf mtu-ignore
é útil na interface VLAN do RSM para interromper a detecção OSPF de incompatibilidade de MTU 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, a seção 10.3 do OSPFRFC 2328 declara que o processo Exstart/Exchange é iniciado para qualquer um desses eventos (qualquer um deles pode ser causado por problemas internos de software):
Incompatibilidade de Número de Sequência.
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.
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
10-Dec-2001 |
Versão inicial |