IP : Open Shortest Path First (OSPF)

Troubleshooting complexo do Mensagem de Erro OSPF

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback

Introdução

Este documento descreve como pesquisar defeitos os Mensagens de Erro do Open Shortest Path First (OSPF) que são encontrados em operações da rede normal e puderam degradar a conectividade de rede.

Contribuído por Mohammed Muddasir Khan, engenheiro de TAC da Cisco.

Pré-requisitos

Requisitos

Cisco recomenda que você tem o conhecimento de fundamentos OSPF.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

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 sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Informações de Apoio

O protocolo de OSPF é um Interior Gateway Protocol (IGP) extensamente distribuído na empresa e nas redes de provedor de serviços.

Este protocolo era desenvolvido devido a uma necessidade na comunidade do internet de introduzir uma funcionalidade alta, IGP NON-proprietário para a família de protocolo TCP/IP. As discussões para a criação de um IGP interoperáveis comum para o Internet começado em 1988 e não foram formalizadas até 1991. Naquele tempo, o grupo em funcionamento OSPF pediu que o OSPF estivesse considerado para que o avanço esboce o padrão do Internet.

O protocolo de OSPF é baseado na tecnologia de estado de enlace, que é uma partida dos algoritmos baseado em vetor Bellman-Ford que são usados nos protocolos de roteamento de Internet tradicionais, tais como o Routing Information Protocol (RIP).

Problemas

Esta seção descreve três edições OSPF que puderam degradar a conectividade de rede.

Problema 1

Você recebe o Mensagem de Erro OSPF-4-FLOOD_WAR. A guerra da inundação OSPF ocorre quando o roteador recebe repetidamente sua própria propaganda do estado do link (LSA) e nivela-a da rede ou envia-a uma nova versão dela. Isto é significado detectar edições com Tipo 2 LSA quando os endereços de IP duplicados estam presente na rede, ou com Tipo 5 LSA quando há um ID do roteador duplicado em áreas do OSPF diferentes.

Em um cenário típico, há um roteador na rede que origina o LSA e um segundo roteador que nivele o LSA.

Esta imagem ilustra as origens e os eventos nivelados entre o primeiro e segundo Roteadores (R1 Nomeado e R2, respectivamente):

Problema 2

Você recebe o Mensagem de Erro %OSPF-4-CONFLICTING_LSAID. Este Mensagem de Erro indica que uma origem LSA era impedido devido a um conflito com um LSA atual que tenha o mesmo estado ID do link mas uma máscara de sub-rede diferente.

O algoritmo no RFC 2328, o apêndice E está usado a fim resolver conflitos quando os LSA múltiplos com o mesmo prefixo e as máscaras diferentes são anunciados. Quando este algoritmo está usado, e as rotas do host estão anunciadas, há as situações onde a resolução de conflito é impossível e a rota do host ou o prefixo que opõe não são anunciados.

Está aqui um snippet do exemplo do Mensagem de Erro:

%OSPF-4-CONFLICTING_LSAID: LSA origination prevented by existing LSA with same LSID
but a different mask

Existing Type 5 LSA: LSID 192.168.1.0/31
New Destination: 192.168.1.0/32

Problema 3

Você configura o OSPF a fim usar a característica rápida dos pacotes Hello, que causa a alta utilização da CPU. O apoio OSPF para a característica rápida dos pacotes Hello permite a configurações tais que os pacotes Hello estão enviados nos intervalos menos do que o segundo. Estes tipos de configurações conduzem a uma convergência mais rápida em uma rede de OSPF.

Este comando é usado a fim ajustar o intervalo durante que pelo menos um pacote Hello deve ser recebido, ou o vizinho é considerado para baixo:

ip ospf dead-interval minimal hello-multipliermultiplier

Aqui está um exemplo:

Router(config-if)# ip ospf dead-interval minimal hello-multiplier 5

Neste exemplo, o apoio OSPF para pacotes Hello rápidos é permitido com a especificação da palavra-chave mínima, da palavra-chave do olá!-multiplicador, e do valor. Porque o multiplicador é ajustado a 5, cinco pacotes Hello são enviados cada segundo.

Soluções

Esta seção descreve algumas soluções possíveis aos problemas que são descritos na seção anterior.

Solução da edição 1

É importante que você compreende o Mensagem de Erro durante tentativas de pesquisar defeitos mensagens da guerra da inundação. As mensagens aparecem diferentemente nas origens e no Roteadores nivelado. Por este motivo, é crucial centrar-se sobre o tipo LSA para que a mensagem da guerra da inundação é relatada, porque cada tipo LSA é pesquisado defeitos diferentemente.

Está aqui um snippet do exemplo da mensagem da guerra da inundação OSPF:

%OSPF-4-FLOOD_WAR: Process 1 re-originates LSA ID 172.16.254.25 type-2 adv-rtr
172.16.253.1 in area 0

%OSPF-4-FLOOD_WAR: Process 1 flushes LSA ID 172.16.254.25 type-2 adv-rtr
172.16.253.1 in area 0

Estão aqui os componentes da mensagem descritos:

  • Processo – Este é o processo de OSPF que relata o erro.

  • re-origina ou resplendores – Isto indica se este roteador origina ou nivela o LSA.

  • LSA ID – Este é o LSA ID para que a guerra da inundação é detectada.

  • Tipo – Este é o tipo LSA.

    Nota: A guerra da inundação para cada LSA tem uma causa de raiz diferente.

  • adv-RTR – Este é o roteador de anúncio que origina o LSA.

  • Área – Esta é a área a que o LSA pertence.

Tipo 2 LSA

Nota: Refira o RFC 2328 (capítulo 13.4, caso 3) para a informação adicional se a guerra da inundação é imprimida para um Tipo 2 LSA.

Se um roteador recebe uma rede LSA do Tipo 2 cujo LSA ID seja o mesmo que o endereço IP de Um ou Mais Servidores Cisco ICM NT para uma das relações que são associadas com esse roteador, a seguir o roteador deve nivelar o LSA. A causa de raiz nesta encenação é os endereços de IP duplicados nas origens e no Roteadores nivelado.

A fim resolver esta edição, reconfigure o endereço IP de Um ou Mais Servidores Cisco ICM NT em uma das relações ou da parada programada a relação que tem o endereço de IP duplicado.

Nota: Esta verificação para endereços de IP duplicados é executada nas relações que estão para baixo também. A relação deve reagir do modo admin-para baixo a fim contornear a verificação. Em alguns casos secundários, a guerra da inundação é relatada igualmente para uma relação administrativamente fechada, assim que a solução permanente é remover os endereços de IP duplicados na rede.

Type-3 LSA

É raro encontrar edições da guerra da inundação para um Type-3 LSA. Os Mensagens de Erro da guerra da inundação para Type-3 LSA foram gravados nas encenações em que a sub-rede IP de um link não sincronizado é propagada pesadamente no domínio de OSPF.

Cisco recomenda que você abre um caso de suporte com o centro de assistência técnica da Cisco (TAC) se você encontra as edições da guerra da inundação devido a Type-3 LSA.

Tipo 5 LSA

As guerras da inundação devido ao Tipo 5 LSA ocorrem quando há ID do roteador duplicado no Roteadores que está ficado situado em áreas diferentes. É obrigatório mudar o Router ID em um do Roteadores.

Um outro exemplo de guerras da inundação do Tipo 5 é quando há dois Roteadores que manda a mesma instrução de rede do Border Gateway Protocol (BGP) e ambo o Roteadores redistribuir aquelas redes BGP no OSPF. Se qualquer um daqueles BGP Router alcança a rede com o OSPF, a seguir uma guerra da inundação OSPF devido a um Tipo 5 LSA está relatada.

Em resumo, assegure-se de que o roteador ID não seja o mesmo, e a redistribução correta do LSAs externo deve impedir as edições da guerra da inundação devido ao Tipo 5 LSA.

Solução da edição 2

A etapa inicial que você deve tomar com tentativas de resolver o Mensagem de Erro OSPF-CONFLICTING_LSAID é encontrar o prefixo que não é anunciado assim como o prefixo que opõe.

A fim encontrar estes, inscreva a rota e os comandos show ip ospf database da mostra IP no CLI. O administrador deve seguir a origem do destino novo: 192.168.1.0/32, segundo as indicações do exemplo de caso descrito na seção da edição 2, e corrigem a máscara de sub-rede da rede.

O exemplo usual de LSA oposto ID está registrado após uma alteração recente no OSPF e é resolved depois que você corrige a configuração das máscaras de sub-rede nas indicações da rede de OSPF.

Solução da edição 3

Os casos da alta utilização da CPU estão registrados com o tac Cisco quando os clientes distribuem hellos rápidos OSPF em Series Switch do Cisco catalyst.

Nota: Cisco recomenda que você não configura hellos OSPF rapidamente.

O ® do Cisco IOS é executado em um modelo nonpreemptive, e a característica rápida do pacote Hello exige que os hellos OSPF estejam processados mais frequentemente do que o intervalo inoperante do segundo. Pôde haver umas possibilidades que o OSPF não obtém os recursos requerido em um sistema com outros processos longos. O dependente em cima de seu ambiente e os outros protocolos e aplicativos que são configurados no roteador, o uso desta capacidade pode ser problemático.

A substituição do secundário-segunda olá! foi introduzida com a detecção bidirecional da transmissão (BFD), onde o BFD é desenvolvido para a detecção rápida do vizinho para baixo. O BFD é executado no modo da interrupção e não se submete aos problemas que são observados com os hellos OSPF rapidamente. Cisco recomenda que você usa o BFD para uma convergência mais rápida.

Estão aqui dois defeitos conhecidos devido aos hellos rápidos OSPF:

  • Identificação de bug Cisco CSCut14044: Olá! rápido 333msec WS-C3750X-48/OSPF/gota da adjacência/15.0(2)SE6

  • Identificação de bug Cisco CSCsd17835: as adjacências rápidas do olá! OSPF/hsrp estão batendo continuamente

Informações Relacionadas



Document ID: 118880