Disponibilidade : Alta disponibilidade

Gerenciamento de configuração OSPF com SNMP

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


Índice


Introdução

O Open Shortest Path First (OSPF) Routing Protocol é definido pelo RFC 2328 OSPF Version 2.leavingcisco.com O objetivo deste documento é fornecer uma estrutura de procedimentos que possibilite às organizações implementar procedimentos de gerenciamento de configuração para verificar a implantação de OSPF em relação aos planos de projeto de OSPF e realizar auditorias periódicas na implantação de OSPF para assegurar a consistência a longo prazo com o projeto pretendido.

Este papel centra-se sobre as funções de gerenciamento de configuração do modelo definido ITU-T FCAPS (falha, configuração, explicar/inventário, desempenho, Segurança). O gerenciamento de configuração é definido por ITU-T M.3400 como fornecedor de funções para exercer controle, identificar, coletar dados e fornecer dados para NEs (elementos de rede).

As informações deste documento são apresentadas em várias seções importantes descritas abaixo.

A seção OSPF background fornece uma visão geral tecnológica do OSPF que inclui a informações de fundo em aspectos importantes de uma distribuição de OSPF.

A seção de definições de processo fornece uma vista geral das definições de processo usadas para realizar o Gerenciamento de configuração de OSPF. Os detalhes do processo são descritos em termos de metas, indicadores de desempenho, entradas, saídas e tarefas individuais.

A seção Task Definitions (Definições de tarefas) fornece definições detalhadas sobre as tarefas do processo. Cada tarefa é descrita em termos dos objetivos, das entradas de tarefa, das saídas das tarefas, dos recursos exigidos para realizar a tarefa, e das habilidades de trabalho necessárias para um implementador de tarefas.

A seção Identificação de dados descreve a identificação de dados para OSPF. A identificação de dados considera a origem da informação ou onde ela está localizada. Por exemplo, as informações são contidas pelo sistema no Protocolo Simples de Gestão de Rede (SNMP) Base de Informações de Gerenciamento (MIB), arquivos de registro gerados pelo Syslog ou estruturas internas de dados que só podem ser acessadas pela interface de linha de comando (CLI).

A seção Coleta de dados deste documento descreve a coleta dos dados de OSPF. A coleta dos dados está intimamente ligada à localização dos dados. Por exemplo, dados de SNMP MIB são coletados por vários mecanismos, como armadilhas, alarmes e eventos de Remote Monitoring (RMON) ou eleição. Os dados mantidos pelas estruturas internas de dados são coletados por scripts automáticos ou manualmente por um usuário que efetua logon no sistema para emitir o comando CLI e, em seguida, registrar a saída.

A seção Apresentação de Dados fornece exemplos de como os dados são apresentados em formatos de relatório. Depois que os dados são identificados e recolhidos, estão analisados. Este documento oferece relatórios de exemplo que podem ser usados para registrar e comparar dados de configuração OSPF.

As seções Ferramentas Comerciais e Públicas de Monitoramento da Internet, Dados de Poll de SNMP e Exemplos de Algoritmos de Coleta de Dados fornecem informações sobre como desenvolver ferramentas para implementar o procedimento de gerenciamento de configuração do protocolo OSPF.

OSPF background

O OSPF é um protocolo de gateway interno projetado para ser utilizado em um único sistema autônomo. OSPF usa tecnologia baseada no Link-State ou no Shortest-Path First (SPF), em comparação com a tecnologia de vetor de distância ou Bellman-Ford encontrada nos protocolos de roteamento, como o Routing Information Protocol (RIP). Individual Link-State Advertisements (LSAs) descrevem partes do OSPF Routing Domain, por exemplo, o sistema autônomo inteiro. Esses LSAs são inundados em todo o domínio do roteamento, formando o banco de dados de estados do enlace. Cada roteador de um domínio possui um banco de dados de link-state idêntico. A sincronização das bases de dados de link-state é mantida com um algoritmo de inundação confiável. A partir do Link-State Database, cada roteador constrói uma tabela de roteamento ao calcular uma árvore de caminho mais curto, com a raiz da árvore sendo o próprio roteador que calcula. Este cálculo é geralmente chamado de algoritmo Dijkstra.

Os LSAs são menores e cada LSA descreve uma pequena parte do domínio de roteamento do OSPF, especificamente, a vizinhança de um único roteador, a vizinhança de uma única rede de trânsito, uma única rota entre áreas ou uma única rota externa.

Esta tabela define recursos chaves do OSPF:

Recurso Descrição
Adjacência Quando os pares de OSPF Router se tornam adjacentes, os dois Roteadores sincronizam suas bases de dados de link-state trocando sumários de banco de dados sob a forma dos pacotes de intercâmbio da base de dados do OSPF. Em seguida, as roteadores adjacentes mantêm a sincronização de seus bancos de dados de estados de enlaces por meio do algoritmo de inundação confiável. Roteadores conectados por linhas seriais tornam-se sempre adjacentes. Nas redes multiacesso (Ethernets), todos os roteadores anexados à rede se tornam adjacentes ao roteador designado (DR) e ao roteador designado de backup (BDR).
Roteador designado Quando um DR é eleito em todas as redes de multi-acesso, ele origina o LSA de rede que descreve o ambiente local das redes. Igualmente joga um papel especial no algoritmo de inundação, desde que todo o Roteadores na rede está sincronizando suas bases de dados de link-state enviando e recebendo LSA a e do DR durante o processo de inundação.
Backup Designated Router Quando o DR atual desaparece, um BDR está elegido em redes de multi-acesso para apressar a transição dos DR. Quando o BDR toma sobre, não precisa de examinar o processo adjacente na rede de área local (LAN). O BDR também permite que o algoritmo de inundação confiável continue na ausência de DRs antes que o desaparecimento do DR seja percebido.
Suporte para rede sem difusão multiacesso O protocolo OSPF trata redes, como redes de dados públicas (PDNs) de Frame Relay, como se fossem LANs. Contudo, a informação de configuração adicional é precisada para o Roteadores anexado a estas redes para encontrar-se inicialmente.
Áreas de gerenciamento da configuração de OSPF O OSPF permite que os sistemas autônomos sejam divididos em áreas. Isto fornece um nível extra da proteção do roteamento de modo que distribuir dentro de uma área seja protegida de toda a informação externo à área. Além disso, a divisão de um sistema autônomo em áreas reduz o custo do procedimento Dijkstra em termos de ciclos da CPU.
Links virtuais Permitindo a configuração de enlaces virtuais, o OSPF remove as restrições topológicas nos layouts de área em um sistema autônomo.
Autenticação dos intercâmbios de protocolo de roteamento Cada vez que um OSPF Router recebe um pacote de protocolo de roteamento, pode opcionalmente autenticar o pacote antes de processá-lo mais.
Métrica de roteamento flexível No OSPF, as métricas são atribuídas a interfaces de roteador de saída. O custo de um caminho é a soma das interfaces de componente do caminho. A métrica de roteamento, é derivada à revelia da largura de banda do link. Ela pode ser designada pelo administrador de sistema para indicar qualquer combinação de características de rede, como retardo, largura de banda e custo.
Equal-cost multi-path Quando as rotas múltiplas do melhor-custo a um destino existem, o OSPF encontra-as e usa- para carregar o tráfego da parte ao destino.
Suporte a sub-rede de comprimento variável Apoia máscaras de sub-rede de comprimento variável levando uma máscara de rede com cada destino anunciado.
Suporte de área stub Para oferecer suporte a roteadores que não têm memória suficiente, as áreas podem ser configuradas como de stub. Não há inundação de LSAs externos nas áreas de stub nem através delas. O roteamento aos destinos externos nas áreas de stub é baseado unicamente no padrão.

Definições de processo

Uma definição de processo é uma série de ações, atividades e alterações relacionadas executadas por agentes com a intenção de atender a uma finalidade ou de alcançar uma meta.

Controle de processo é o processo de planejar e regular com o objetivo de executar um processo de maneira eficiente.

Graficamente, isso é representado na figura a seguir.

/image/gif/paws/15408/ospf_a.gif

A saída do processo deve estar de acordo com as normas operacionais definidas por uma organização e tem base nos objetivos comerciais. Se o processo estiver conforme o conjunto de normas, o processo é considerado eficaz porque pode ser repetido, medido, gerenciado e contribui para objetivos comerciais. Se as atividades forem realizadas com um esforço mínimo, o processo também será considerado eficiente.

Proprietário de processo

Os processos englobam diversos limites organizacionais. Portanto, é importante ter um único proprietário de processo que seja responsável pela definição do processo. O proprietário é o ponto focal para determinar e relatar se o processo é efetivo e eficiente. Se o processo não for eficiente, seu proprietário providenciará a modificação. A modificação do processo é regida pelos processos de controle e revisão de alterações.

Objetivos do processo

Metas do processo são estabelecidas para definir a direção e o escopo para a definição do processo. Os objetivos são usados também para definir a métrica a ser usada para medir a eficácia de um processo.

O objetivo deste processo é fornecer uma estrutura para verificar a configuração distribuída de uma implementação OSPF contra um projeto pretendido e para fornecer um mecanismo para examinar periodicamente a distribuição de OSPF para assegurar ao longo do tempo a consistência no que diz respeito ao projeto pretendido.

Indicadores de desempenho do processo

Os indicadores de desempenho do processo são utilizados para medir a eficiência da definição do processo. Os indicadores de desempenho devem ser mensuráveis e determináveis. Os indicadores de desempenho listados abaixo são numéricos ou medidos por tempo. Indicadores de desempenho para o processo de gerenciamento de configuração OSPF são definidos da seguinte maneira:

  • O tempo necessário para fazer um ciclo por todo o processo.

  • A freqüência de execução necessária para detectar proativamente problemas de OSPF antes que eles afetem os usuários.

  • A carga da rede associada à execução do processo.

  • O número de ações corretivas recomendadas pelo processo.

  • O número de ações corretivas implementadas como resultado do processo.

  • O período de tempo necessário para implementar ações corretivas.

  • O período de tempo necessário para implementar ações corretivas.

  • O acúmulo de ações corretivas.

  • O tempo ocioso da máquina atribuído aos problemas relacionados OSPF.

  • O número de itens adicionados, removidos ou modificados no arquivo de seed. Essa é uma indicação de exatidão e estabilidade.

Entradas de processo

As entradas de processo são utilizadas para definir critérios e pré-requisitos de um processo. Muitas vezes, a identificação de entradas de processo fornece informações sobre dependências externas. Uma lista de entradas relacionadas ao gerenciamento de configuração de OSPF é fornecida abaixo.

  • Documentação de design OSPF

  • Dados de MIB de OSPF coletados por chamada seletiva de SNMP

  • Informações de syslog

Saída do processo

As saídas de processo são definidas abaixo:

  • Relatórios da configuração de OSPF definidos na seção da apresentação de dados deste papel

  • Recomendações da configuração de OSPF para que as ações corretiva sejam conduzidas

Definições de tarefas

As seções a seguir definem a inicialização e tarefas repetitivas associadas ao gerenciamento de configuração de OSPF.

Tarefas de inicialização

As tarefas de inicialização são executadas uma vez durante a implementação do processo e não devem ser executadas a cada repetição do processo.

Verifique as tarefas pré-requisito

Na verificação de tarefas de pré-requisito, se for determinado que nenhuma das tarefas está implementada ou não fornece informações suficientes para servir com eficiência as necessidades desse procedimento, esse fato deverá ser documentado pelo proprietário do processo e enviado ao gerenciamento. A tabela abaixo descreve as tarefas de inicialização de pré-requisito.

Tarefa de pré-requisito Descrição
Objetivos da tarefa e entradas
  1. Verifique se os documentos de projeto do OSPF existem e se as informações a seguir estão prontamente disponíveis na documentação de projeto da rede:
    1. Definições de área — Nomes, escalas de endereço, e tipo de área
    2. Identificações de Area border router/autonomous system border router (ABR/ASBR)
    3. Identificações DR/BDR
    4. As interfaces e os nós de IR (Internet Registry) são atribuídos a áreas
  2. Use um molde de configuração padrão de SNMP para verificar se o SNMP está sendo configurado na rede.

    Nota: Isto é usado mais tarde como a entrada criando o arquivo de seed.

  3. Use um modelo de configuração padrão Syslog para verificar se o Syslog está sendo distribuído na rede.
saída de tarefas O resultado da tarefa é um relatório de status das tarefas de pré-requisito. Se todas as tarefas de suporte forem consideradas ineficazes, o proprietário do processo deverá enviar uma solicitação para que os processos de suporte sejam atualizados. Se os processos de suporte não puderem ser atualizados, realize uma avaliação do impacto neste processo.
Função da tarefa Grupo da habilidade do engenheiro de rede

Criar um arquivo de seed

O processo de gerenciamento de configuração de OSPF requer o uso de um arquivo de seed para remover a necessidade de uma função de descoberta de rede. O arquivo de seed registra o conjunto de roteadores regidos pelo processo OSPF e é também usado como ponto focal para coordenar juntamente com os processos de gerenciamento de alterações de uma organização. Por exemplo, se novos nós forem inseridos na rede, eles precisarão ser adicionados ao arquivo de seed OSPF. Se forem feitas alterações nos nomes da comunidade de SNMP devido a requisitos de segurança, essas modificações precisarão ser refletidas no arquivo de seed. A tabela abaixo resume os processos para criação de um arquivo de seed.

Processo Descrição
Objetivos da tarefa Crie um arquivo de seed que seja usado para inicializar o software de gerência de configuração do OSPF. A formatação do arquivo de seed depende dos recursos utilizados para implementar o processo de gerenciamento de configuração OSPF. Se os scripts personalizados são desenvolvidos, o formato do arquivo de seed está definido pela design de software. Se um sistema de gerenciamento de rede for usado, o formato do arquivo de seed será definido pela documentação do NMS.
Entradas da tarefa
  1. Formate o arquivo de seed.
  2. Use a documentação de design do OSPF para identificar os seguintes dados:
    • Endereços IP de todos os nós
    • Strings de comunidade SNMP
    • Contas e senhas de logon de Telnet e CLI
  3. Programação e/ou nomes de contato para o processo de gerenciamento da alteração de rede.
Saídas de tarefa Um arquivo de seed para o processo de gerenciamento da configuração de OSPF.
Recursos da tarefa
  • Sistema NMS comercial
  • Sistema de software desenvolvido por cliente
  • Processo manual — O log em cada elemento de rede e em linhas de comando da edição e grava a saída.
Função da tarefa
  • NMS — Engenheiro de rede, administrador NMS, e grupos da habilidade do script NMS.
  • Scripts personalizados — Grupos do engenheiro de rede e da habilidade do script NMS.
  • Processos manuais — Engenheiro de rede.

Tarefas repetidas

As tarefas repetitivas são executadas com cada iteração do processo e sua frequência é determinada e alterada a fim melhorar os indicadores de desempenho.

Manter o arquivo de propagação

O arquivo de seed é crítico para a implementação eficaz do processo de gerenciamento da configuração de OSPF. Portanto, o estado atual do arquivo de seed deve ser administrado ativamente. Muda à rede que impacta os índices da necessidade do arquivo de seed de ser seguido pelo proprietário do processo de gerenciamento da configuração de OSPF.

Processo Descrição
Objetivos da tarefa
  1. Mantenha a moeda do arquivo de seed com do seguimento e as interações com funções de organização que controlam movimentos da rede, adicionam, mudanças, e/ou alterações da configuração de rede.
  2. Mantenha o controle de versão e de backup do arquivo de seed.
Entradas da tarefa
  1. Informações de gerenciamento de alterações, como movimentações, adições e alterações, as quais impactam o conteúdo do arquivo seed.
  2. Informações de engenharia/design que impactam o conteúdo do arquivo de seed.
Saídas de tarefa
  1. Relatório semanal sobre o status da moeda do arquivo de seed.
  2. A definição e a documentação que descreve o local e os procedimentos de restauração para backups de arquivos de seed.
Recursos da tarefa
  • Sistema NMS comercial
  • Sistema de software desenvolvido por cliente
  • Processo manual — O log em cada elemento de rede e em linhas de comando da edição e grava a saída.
Função da tarefa
  • NMS — Engenheiro de rede, administrador NMS, e grupos da habilidade do script NMS.
  • Scripts personalizados — Grupos do engenheiro de rede e da habilidade do script NMS.
  • Processos manuais — Engenheiro de rede.

Execute o OSPF Scan

As duas etapas usadas para executar a varredura de OSPF são:

  1. Coletando os dados.

  2. Analisando os dados.

A freqüência desses dois passos vai variar de acordo como a forma como o processo é usado. Por exemplo, este processo pode ser usado para verificar modificações de instalação. Neste caso, a coleta de dados é executada antes e depois da alteração, e a análise de dados é conduzida após a alteração para determinar o sucesso da mesma.

Se esse processo for utilizado para verificar os registros de projetos de gerenciamento da configuração de OSPF, a freqüência de coleta e análise de dados dependerá da taxa de alteração na rede. Por exemplo, se houver um número significativo de alterações na rede, as verificações de projeto serão realizadas uma vez por semana. Se há muito uma pequena alteração na rede, as verificações desejadas estão conduzidas não mais do que uma vez por mês.

Revise os relatórios de OSPF

O formatos dos relatórios de gerenciamento de configuração do OSPF é dependente dos recursos usados para implementar o processo de gerenciamento de configuração do OSPF. A tabela a seguir apresenta sugestões de formatos de relatório, desenvolvidos de forma personalizada.

Relatório Formato
Entradas da tarefa Para relatórios do Gerenciamento de configuração de OSPF, veja a seção da apresentação de dados dentro deste documento.
Saídas de tarefa Se problemas foram identificados entre os relatórios de varredura e os registros lógicos do projeto, uma decisão deverá ser tomada quanto à identificação do item correto e do item incorreto. O item incorreto deve ser corrigido. Isso pode envolver a modificação dos registros de design ou uma ordem de alteração de rede.
Recursos da tarefa
  • Sistema NMS comercial
  • Sistema de software desenvolvido por cliente
  • Manual — O log em cada elemento de rede e em linhas de comando da edição e grava a saída
Função da tarefa
  • NMS — Engenheiro de rede, administrador NMS, e grupos da habilidade do script NMS.
  • Scripts personalizados — Grupos do engenheiro de rede e da habilidade do script NMS.
  • Processos manuais — Engenheiro de rede.

Identificação de dados

Características de dados gerais

A tabela a seguir descreve os dados que podem ser aplicados ao gerenciamento de configuração de OSPF.

Dados Descrição
Áreas de OSPF As informações que descrevem as áreas associadas do roteador incluem:
  • ID da área
  • Autenticação de área
  • execuções do SPF
  • Número de ABRs em uma área
  • Número de ASBR em uma área
  • Contagem da área LSA — Consistência através do Roteadores em uma área
  • Soma de verificação da área LSA — Consistência através do Roteadores na área
  • Frequência dos descartes de pacote de informação devido aos erros de endereçamento pela área
  • Descartes de freqüência de pacote de protocolo por processo de roteamento por área
  • Freqüência dos descartes de pacotes roteados devido à condição de localização de rota por área
Interfaces OSPF Descreve uma interface a partir do ponto de vista do OSPF, tal como:
  • Endereço IP
  • ID da área
  • Status administrativo
  • Métricas de OSPF atribuídas à interface
  • Temporizadores OSPF atribuídos à relação
  • Estado OSPF
Estado do vizinho OSPF Descreve um vizinho de OSPF.
  • ID de roteador vizinho
  • Estado do vizinho
  • Eventos vizinhos — O número de vezes o relacionamento vizinho mudou o estado, ou um erro ocorreu.
  • Fila de retransmissão vizinha — O comprimento atual da fila de retransmissão.

Identificação de dados de SNMP

Cisco apoia atualmente a versão 2 MIB do RFC 1253 OSPFleavingcisco.com . O RFC 1253 não contém definições de armadilha SNMP para OSPF. A versão a mais atrasada do OSPF MIB é SNMP traps da versão 2. do RFC 1850leavingcisco.com OSPF é definida para o OSPF no RFC 1850. O RFC 1850 não é apoiado na aplicação de Cisco do OSPF MIB.

Consulte a seção Dados de chamada seletiva de SNMP deste documento para obter mais detalhes.

Refira por favor a página do software de gerenciamento de rede da Cisco para uma lista definitiva de que o MIBs é apoiado em que plataforma e versão de código.

Identificação de dados RMON

Não há nenhum dados específico RMON exigido para este procedimento.

Identificação de dados de syslog

Em geral, o Syslog gera mensagens específicas de serviço para tecnologias diferentes. Embora as informações do syslog sejam mais apropriadas para o gerenciamento de falhas e de desempenho, as informações fornecidas aqui são uma referência. Para obter um exemplo de informações OSPF Syslog geradas por dispositivos da Cisco, consulte Mensagens de Erro de OSPF.

Para uma lista completa dos mensagens de sistema pela facilidade, refira por favor mensagens e procedimentos de recuperação.

Identificação de dados de CLI do Cisco IOS

Nesta versão do procedimento de gerenciamento de configuração OSPF, não há nenhum dados de CLI exigido.

Levantamento de dados

Levantamento de dados de SNMP

A tabela abaixo define os componentes diferentes do levantamento de dados SNMP.

Componente de dados de SNMP Definição
Configuração geral de SNMP Refira configurar o SNMP para obter informações gerais sobre dos melhores prática da configuração de SNMP.
Preste serviços de manutenção à configuração de SNMP específica Não há configurações SNMP específicas para o serviço exigidas para esse procedimento.
Requisitos MIB SNMP Consulte a seção Identificação de Dados, abaixo.
Coleção de eleição MIB SNMP Os dados eleitos SNMP são recolhidos por um sistema comercial tal como o HP OpenViewleavingcisco.com ou por scripts personalizados. Para um exame mais adicional dos algoritmos de levantamento, veja a seção dos exemplos de algoritmo do levantamento de dados deste documento.
Coleção da armadilha do SNMP MIB A versão atual do MIB de OSPF suportada nos dispositivos Cisco não suportam armadilhas de SNMP. Não há armadilhas SNMP necessárias para este procedimento.

Levantamento de dados de RMON

Não há nenhuns configuração de rmon e dados exigidos nesta versão do procedimento.

Conjunto de dados Syslog

As diretrizes de configuração gerais do Syslog são fora do âmbito deste documento. Consulte Configuração e Troubleshooting do Cisco Secure PIX Firewall com uma Única Rede Interna para obter mais informações.

Requisitos específicos do OSPF são endereçados pela configuração do roteador OSPF para registrar as alterações de vizinhos com uma mensagem de syslog usando o seguinte comando:

OSPF_ROUTER(config)# ospf log-adj-changes

Coleta de dados CLI do Cisco IOS

Em geral, o CLI do Cisco IOS permite o acesso mais direto às informações brutas contidas no NE. Entretanto, o acesso CLI é o melhor para os procedimentos de Troubleshooting e atividades de gerenciamento de alterações do que o gerenciamento da configuração global como definido por este procedimento. O acesso pelo CLI não será escalonado para o gerenciamento de uma grande rede. Nesses casos, é necessário ter acesso a informações automatizadas.

Nesta versão do procedimento de gerenciamento de configuração OSPF, não há nenhuns configuração de CLI e dados exigidos.

Apresentação de dados

Relatório de área de OSPF

O seguinte é um formato de exemplo para os relatórios de área de OSPF. O formato do relatório é determinado pelos recursos de um NMS comercial, se utilizado, ou da saída programada dos scripts personalizados.

Área Campos de dados Última execução Esta execução
ID da área #1 Autenticação    
execuções do SPF    
Contagem ABR    
Contagem ASBR    
Contagem LSA    
Soma de verificação LSA    
Erros do endereço    
Descartes de Roteamento    
Nenhuma rota encontrada    
ID da área #n Autenticação    
execuções do SPF    
Contagem ABR    
Contagem ASBR    
Contagem LSA    
Soma de verificação LSA    
Erros do endereço    
Descartes de Roteamento    
Nenhuma rota encontrada    

Relatório de interface OSPF

O seguinte é um formato de exemplo para os relatórios de interface OSPF. Na prática, o formato do relatório é determinado por capacidades de um NMS comercial, caso algum seja utilizado, da saída programada dos scripts personalizados.

Área Dispositivo Interface Campos de dados Última execução Esta execução
ID da área #1 ID de nó 1 ID de interface nº 1 Endereço IP    
ID da área    
Estado de administração    
Estado OSPF    
Métrica/Custo/Temporizadores    
ID da interface #n Endereço IP    
ID da área    
Estado de administração    
Estado OSPF    
Métrica/Custo/Temporizadores    
ID do nó #n ID de interface nº 1 Endereço IP    
ID da área    
Estado de administração    
Estado OSPF    
Métrica/Custo/Temporizadores    
ID da interface #n Endereço IP    
ID da área    
Estado de administração    
Estado OSPF    
Métrica/Custo/Temporizadores    
ID da área #n ID de nó 1 ID de interface nº 1 Endereço IP    
ID da área    
Estado de administração    
Estado OSPF    
Métrica/Custo/Temporizadores    
ID da interface #n Endereço IP    
ID da área    
Estado de administração    
Estado OSPF    
Métrica/Custo/Temporizadores    
ID do nó #n ID de interface nº 1 Endereço IP    
ID da área    
Estado de administração    
Estado OSPF    
Métrica/Custo/Temporizadores    
ID da interface #n Endereço IP    
ID da área    
Estado de administração    
Estado OSPF    
Métrica/Custo/Temporizadores    

Relatório de vizinhos de OSPF

O seguinte é um formato de exemplo para os Relatórios vizinho de OSPF. Na prática, o formato do relatório é determinado por capacidades de um NMS comercial, caso algum seja utilizado, da saída programada dos scripts personalizados.

Área Dispositivo Vizinhos Campos de dados Última execução Esta execução
ID da área #1 ID de nó 1 ID de vizinho #1 ID de Roteador    
IP Address de Roteador:    
Estado    
Eventos    
Retrans Que    
ID de vizinho #n ID de Roteador    
IP Address de Roteador:    
Estado    
Eventos    
Retrans Que    
ID do nó #n ID de vizinho #1 ID de Roteador    
IP Address de Roteador:    
Estado    
Eventos    
Retrans Que    
ID de vizinho #n ID de Roteador    
IP Address de Roteador:    
Estado    
Eventos    
Retrans Que    
ID da área #n ID de nó 1 ID de vizinho #1 ID de Roteador    
IP Address de Roteador:    
Estado    
Eventos    
Retrans Que    
ID de vizinho #n ID de Roteador    
IP Address de Roteador:    
Estado    
Eventos    
Retrans Que    
ID do nó #n ID de vizinho #1 ID de Roteador    
IP Address de Roteador:    
Estado    
Eventos    
Retrans Que    
ID de vizinho #n ID de Roteador    
IP Address de Roteador:    
Estado    
Eventos    
Retrans Que    

Ferramentas comerciais e públicas de monitoração da Internet

Existem ferramentas comerciais para ajudar na coleta e processamento de informações de syslog e para a coleta seletiva de variáveis gerais de SNMP MIB.

Não se conhece nenhuma ferramenta de monitoramento de Internet comercial ou pública com suporte para o gerenciamento de configurações OSPF conforme definido por esse procedimento. Portanto, são necessários scripts e procedimentos personalizados locais.

Dados de eleição SNMP

RFC 1213 da tabela de rotaleavingcisco.com

Nome do objeto Descrição do objeto
ipRouteDest O endereço IP de destino da rota. Uma entrada com um valor de 0.0.0.0 é considerada uma rota padrão. As rotas múltiplas a um destino único podem aparecer na tabela, mas o acesso a tais entradas múltiplas é dependente dos mecanismos do tabela-acesso definidos pelo protocolo de gerenciamento de rede no uso. :: = identificador de objeto do {iprouteentry 1} = 1.3.6.1.2.1.4.21.1.1
ipRouteMask Indica a máscara para ser lógico com o endereço de destino antes de ser comparada ao valor no campo de ipRouteDest. Para os sistemas que não suportam máscaras de sub-rede arbitrárias, um agente constrói o valor do ipRouteMask, determinando se o valor do campo ipRouteDest correspondente pertence a uma rede da classe A, B ou C, usando uma das seguintes redes de máscara:
  • Classe A = 255.0.0.0
  • Classe B= 255.255.0.0
  • Classe C = 255.255.255.0
Se o valor de ipRouteDest é 0.0.0.0, a rota padrão, o valor da máscara também é 0.0.0.0.

Nota: Todos os subsistemas de IP Routing utilizam implicitamente esse mecanismo.

:: = identificador de objeto do {iprouteentry 11} = 1.3.6.1.2.1.4.21.1.11
ipRouteNextHop O IP Address do Next Hop desta rota. No caso de uma rota destinada a uma interface que é realizada com um meio de difusão, o valor desse campo é o endereço IP do agente na interface. :: = identificador de objeto do {iprouteentry 7} = 1.3.6.1.2.1.4.21.1.7
ipRouteIfIndex O valor de índice que identifica excepcionalmente a interface local através de que o salto seguinte da rota é alcançado. Essa interface é a mesma identificada pelo valor IfIndex. :: = identificador de objeto do {iprouteentry 2} = 1.3.6.1.2.1.4.21.1.2

Objetos diversos RFC 1213

Nome do objeto Descrição do objeto
ipAdEntIfIndex O valor do índice que identifica exclusivamente a interface aplicável à entrada. Essa interface é a mesma identificada pelo valor IfIndex. :: = identificador de objeto do {ipaddrentry 2} = 1.3.6.1.2.1.4.20.1.2
ipInAddrErrors O número de datagramas de entrada descartados devido ao endereço IP em seus cabeçalhos IP ser um campo de destino inválido para a entidade. Esta contagem inclui endereços inválidos (0.0.0.0) e endereços unsupported da classe (classe E). Para entidades que não sejam gateways de IP e não encaminhem datagramas, o contador inclui datagramas descartados porque o endereço de destino não era um endereço local. identificador de objeto do {ip 5} = 1.3.6.1.2.1.4.5
ipRoutingDiscards O número de entradas de roteamento válidas rejeitadas. Uma razão possível para rejeitar tal entrada está livrar acima o espaço de buffer para outras entradas de roteamento. identificador de objeto do {ip 23} = 1.3.6.1.2.1.4.23
ipOutNoRoutes Quantidade de datagramas de IP descartados porque nenhuma rota foi encontrada para transmiti-los a seus destinos. identificador de objeto do {ip 12} = 1.3.6.1.2.1.4.12

Tabela de área de OSPFleavingcisco.com do RFC 1253

Nome do objeto Descrição do objeto
ospfAreaID Um inteiro de 32 bits que identifica excepcionalmente uma área. O ID da área 0.0.0.0 é usado para o backbone OSPF. :: = identificador de objeto do {ospfareaentry 1} = 1.3.6.1.2.1.14.2.1.1
ospfAuthType O tipo de autenticação especificada para esta área. É possível atribuir outros tipos de autenticação localmente por área. O valor padrão é 0.:: = identificador de objeto do {ospfareaentry 2} = 1.3.6.1.2.1.14.2.1.2
OspfSpfRuns O número de vezes a tabela da rota intra-área foi calculado usando a base de dados de link-state desta área. identificador de objeto = 1.3.6.1.2.1.14.2.1.4
ospfAreaBdrRtrCount O número total de ABRs que podem ser atingidos dentro desta área. Inicialmente, é 0, o valor padrão, sendo calculado em cada passagem SPF. :: = identificador de objeto do {ospfareaentry 5} = 1.3.6.1.2.1.14.2.1.5
ospfASBdrRtrCount O número total de ABSRs acessível nessa área. Este é inicialmente 0 (o valor padrão), e é calculado em cada passagem SPF. :: = identificador de objeto do {ospfareaentry 6} = 1.3.6.1.2.1.14.2.1.6
ospfAreaLSACount O número total de LSA na base de dados de link-state de uma área, com exclusão do LSAs externo. O valor padrão é 0.:: = identificador de objeto do {ospfareaentry 7} = 1.3.6.1.2.1.14.2.1.7
ospfAreaLSACksumSum A soma não atribuída de 32 bits das somas de verificação LS de LSA contida no banco de dados de estado de enlace da área. Esta soma exclui (tipo 5 LS) LSA externos. A soma pode ser usada para determinar se houve uma alteração no banco de dados de link-state do roteador e para comparar o banco de dados de link-state de dois roteadores. O valor padrão é 0.:: = identificador de objeto do {ospfareaentry 8} = 1.3.6.1.2.1.14.2.1.8

Tabela de Interface RFC 1253 OSPF

Nome do objeto Descrição do objeto
OspfIfIpAddress O endereço IP da interface OSPF. identificador de objeto = 1.3.6.1.2.1.14.7.1.1
OspfIfEvents O número de vezes a interface de OSPF mudou seu estado, ou um erro ocorreu. identificador de objeto = 1.3.6.1.2.1.14.7.1.15
OspflfState O estado da interface de OSPF. identificador de objeto = 1.3.6.1.2.1.14.7.1.12

Tabela de vizinhos de OSPF RFC 1253

Nome do objeto Descrição do objeto
OspfNbrIpAddr O endereço IP do vizinho. :: = identificador de objeto do {ospfnbrentry 1} = 1.3.6.1.2.1.14.10.1.1
ospfNbrAddressLessIndex O valor correspondente de IfIndex no MIB padrão da Internet em um índice que não tem um endereço IP. Na criação da fileira, isto pode ser derivado do exemplo. :: = identificador de objeto do {ospfnbrentry 2} = 1.3.6.1.2.1.14.10.1.2
ospfNbrRtrId Um número inteiro de 32 bits, representado como um endereço IP, identificando exclusivamente o roteador vizinho no sistema autônomo. O valor padrão é 0.0.0.0. :: = identificador de objeto do {ospfnbrentry 3} = 1.3.6.1.2.1.14.10.1.3
ospfNbrState O estado de relacionamento com o vizinho. Os estados são:
  • para baixo (1)
  • tentativa (2)
  • init (3)
  • twoWay (4)
  • exchangeStart (5)
  • exchange (6)
  • carregamento (7)
  • full (8)
:: = identificador de objeto do {ospfnbrentry 6} = 1.3.6.1.2.1.14.10.1.6
ospfNbrEvents O número de vezes que o relacionamento vizinho alterou o estado ou o número de ocorrências de erro. O valor padrão é 0.:: = identificador de objeto do {ospfnbrentry 7} = 1.3.6.1.2.1.14.10.1.7
ospfNbrLSRetransQLen O comprimento atual da fila de retransmissão. O valor padrão é 0.:: = identificador de objeto do {ospfnbrentry 8} = 1.3.6.1.2.1.14.10.1.8

Exemplo de algoritmo do levantamento de dados

Durante a investigação deste papel, um programa do “C” do protótipo foi desenvolvido. O programa, denominado oscan, foi projetado usando o Microsoft Developer Studio 97 com o Visual C++ versão 5.0. Existem duas bibliotecas específicas que fornecem a interface de programação de aplicativo (API) da função SNMP. Essas bibliotecas são snmpapi.lib e mgmtapi.lib

As funções fornecidas por Microsoft API são agrupadas em três categorias principal e alistadas na tabela abaixo.

Funções do Agente Funções do gerente Funções do utilitário
SnmpExtensionInit SnmpExtensionInitEx SnmpExtensionQuery SnmpExtensionTrap SnmpMgrClose SnmpMgrGetTrap SnmpMgrOidToStr SnmpMgrOpen SnmpMgrRequest SnmpMgrStrToOid SnmpMgrTrapListen SnmpUtilMemAlloc SnmpUtilMemFree SnmpUtilMemReAlloc SnmpUtilOidAppend SnmpUtilOidCmp SnmpUtilOidCpy SnmpUtilOidFree SnmpUtilOidNCmp SnmpUtilPrintAsnAny SnmpUtilVarBindCpy SnmpUtilVarBindListCpy SnmpUtilVarBindFree SnmpUtilVarBindListFree

O código de protótipo oscan encapsulado no Microsoft API com um conjunto de funções adicionais listadas abaixo.

  • snmpWalkStrOid

  • snmpWalkAsnOid

  • snmpWalkVarBind

  • snmpWalkVarBindList

Essas funções fornecem uma API genérica que permite o acesso às várias tabelas MIB do SNMP utilizadas para manter os dados de configuração do OSPF. O OID (identificador de objeto) da tabela a ser acessada é passado para o oscan API juntamente com uma função de call back especifica da tabela. A função de rechamada é inteligente e age nos dados retornados das tabelas.

Rotina principal

A primeira tarefa é a construção de uma lista de nós que serão o destino do programa oscan. A fim evitar o problema da “descoberta do dispositivo”, um arquivo de seed é exigido para identificar os Nós a ser feitos a varredura. O arquivo de seed oferece informações tais como o endereço IP e as strings de comunidade de somente-leitura de SNMP.

O programa oscan necessita manter diversas estruturas de dados internas para armazenar informações de SNMP coletadas dos roteadores. Em geral, existe uma estrutura de dados interna para cada tabela MIB SNMP coletada.

Main
	load node array based on information in the seed file.
	while more entries in the node array
		start SNMP session for this node
		collect IP route table for this node
		collect OSPF area table for this node
		collect OSPF Neighbor table for this node
		collect  sysName for this node
		collect OSPF Interface table for this node
		end SNMP session for this node
	end while

Tabela de rotas IP

Deve ser tomado ao alcançar a tabela de rotas IP com SNMP desde que é simples sobrecarregar o CPU de um roteador durante esta operação. Dessa forma, o programa oscan utiliza um parâmetro de retardo configurável pelo usuário. O parâmetro fornece um retardo entre cada solicitação de SNMP. Para grandes ambientes, isto significa que o tempo total recolher a informação pode ser muito significativo.

A tabela de rotas contém quatro informações que interessam ao oscan:

  • ipRouteDest

  • ipRouteMask

  • ipRouteNextHop

  • ipRouteIfIndex

A tabela de rotas é indexada pelo ipRouteDest. Consequentemente, cada objeto que é retornado do GET-pedido SNMP tem o ipRouteDest adicionado ao OID.

O objeto ipRouteIfIndex é um número inteiro que indexa a tabela de endereços de IP (ipAddrTable). A ipAddrTable foi indexada com o uso do objeto ipAdEntAddr (o endereço IP da interface). Para obter o endereço IP da interface, é necessário um processo de quatro etapas:

  1. Colete o ipRouteIfIndex da tabela de roteamento.

  2. Acesse o ipAddrTable usando o ipRouteIfIndex para correspondência de padrão.

  3. Encontrado um padrão, converta o OID em uma série e colete os últimos quatro campos de ponto decimal que representarão o endereço IP da interface.

  4. Armazene o IP Address da interface novamente na tabela de IP Routing.

O algoritmo geral para acessar a tabela de rotas de IPs é mostrado abaixo. Neste ponto, somente o valor inteiro do ipRouteIfIndex está armazenado. Posteriormente no processo, ao coletar as informações da interface, a ipAddrTable é acessada e as informações restantes são coletadas e colocadas na tabela de rotas de IPs internos.

OID List =
	ipRouteDestOID,
	ipRouteMaskOID,
	ipRouteNextHopOID,
	ipRouteIfIndexOID;

For each object returned by  SNMP route table walk
	Sleep // user configurable polling delay.
	check varbind oid against OID list
	if OID is ipRouteDestOID
		add new entry in the internal route table array
	if OID is one of the others
		search internal route array for matching index value
		store information in array

As informações coletadas são representadas em uma tabela semelhante à saída conhecida do CLI de roteador abaixo.

ROUTE TABLE
**********************************************************
Destination     Mask                GW              Interface       
10.10.10.4      255.255.255.252     10.10.10.5      10.10.10.5      
10.10.10.16     255.255.255.252     10.10.10.6      10.10.10.5      
10.10.10.24     255.255.255.252     10.10.10.25     10.10.10.25     
10.10.10.28     255.255.255.252     10.10.11.2      10.10.11.1      
10.10.10.36     255.255.255.252     10.10.10.6      10.10.10.5      
10.10.11.0      255.255.255.0       10.10.11.1      10.10.11.1      
10.10.13.0      255.255.255.0       10.10.11.2      10.10.11.1 

Tabela de área de OSPF

O levantamento de informações da tabela de área de OSPF é feito através da exploração da tabela de área de OSPF (ospfAreaTable) e do processamento dos dados conforme são enviados. O índice para a ospfAreaTable é o osfpAreaId. ospfAreaId é armazenado no formato decimal com pontos, que é idêntico a um endereço IP. Consequentemente, as mesmas sub-rotinas que foram usadas para processar e procurar pelo ipRouteTable e o ipRouteIfIndex podem ser reutilizados aqui.

Há diversos itens de dados que não estão realmente na tabela de área de OSPF que é incluído nesta seção. Por exemplo, os objetos ipInAddrErrors, IpRoutingDiscards e ipOutNoRoute estão na definição MIB-2, mas não estão associados a uma área OSPF. Estes objetos são associados com um roteador. Portanto, esses contadores são usados como uma métrica de área adicionando os valores de cada nó em uma área a um contador de área. Por exemplo, no relatório de área de OSPF, o número de pacotes descartados porque nenhuma rota foi encontrada é, na verdade, a soma dos pacotes descartados por todos os roteadores dessa área. Esta é uma métrica de alto nível, que fornece uma visão geral da integridade do roteamento da área.

OID List =
	ipInAddrErrorsOID,
	ipRoutingDiscardsOID,
	ipOutNoRouteOID,
	areaIdOID,
	authTypeOID,
	spfRunsOID,
	abrCountOID,
	asbrCountOID,
	lsaCountOID,
	lsaCksumSumOID;

	For object returned from the SNMP walk of  the Area Table
		Sleep // user configurable polling delay.
		check varbind oid against OID list.
		if OID is ospfAreaId
			add new entry in the internal route table array
		if OID one of the others
			search internal array for matching index value
			store information in array
	end of for loop
	get ipInAddrErrors, ipRoutingDiscards, ipOutNoRoute
	add values to overall Area counters

As informações coletadas estão representadas na tabela ASCII a seguir.

AREAS
**********************************************************
AREA = 0.0.0.0			AREA = 0.0.0.2
authType = 0			authType = 0
spfRuns = 38			spfRuns = 18
abrCount = 2			abrCount = 1
asbrCount = 0			asbrCount = 0
lsaCount = 11			lsaCount = 7
lsaCksumSum = 340985		lsaCksumSum = 319204
ipInAddrErrors = 0		   ipInAddrErrors = 0
ipRoutingDiscards = 0		ipRoutingDiscards = 0
ipOutNoRoutes = 0		ipOutNoRoutes = 0

Tabela do vizinho OSPF

O índice para a tabela de vizinhos consiste em dois valores:

  • ospfNbrIpAddr — O ospfNbrIpAddr é o endereço IP de Um ou Mais Servidores Cisco ICM NT do vizinho.

  • ospfNbrAddressLessIndex — O ospfNbrAddressLessIndex pode ser um de dois valores:

    • Para uma interface que tem um endereço IP atribuído, o valor é zero.

    • Para uma interface que não tenha um endereço IP atribuído, isto será interpretado como o IfIndex do MIB padrão de Internet.

Por haver dois valores para o índice, você precisa ajustar os algoritmos utilizados anteriormente para as informações extras anexadas aos OIDs devolvidos. Após ter feito este ajuste, as mesmas sub-rotinas que foram usadas para processar e procurar pelo ipRouteTable e o ipRouteIfIndex podem ser reutilizados aqui.

OID List =
	ospfNbrIpAddrOID,
	ospfNbrAddressLessIndexOID,
	ospfNbrRtrIdOID,
	ospfNbrStateOID,
	ospfNbrEventsOID,
	ospfNbrLSRetransQLenOID,

	For object returned from the SNMP walk of the Neighbor Table
		Sleep // user configurable polling delay.
		check varbind OID against OID list.
		if OID matches ospfNbrIpAddr
			add new entry in the internal neighbor table array
		if OID matches one of the others
			search array for matching index value
			store information in array

As informações coletadas estão representadas na tabela ASCII a seguir.

NEIGHBORS
************************************************************
NEIGHBOR #0				NEIGHBOR #1
Nbr Ip Addr = 10.10.10.6		Nbr Ip Addr = 10.10.11.2
Nbr Rtr Id = 10.10.10.17		Nbr Rtr Id = 10.10.10.29
Nbr State = 8				Nbr State = 8
Nbr Events = 6				Nbr Events = 30
Nbr Retrans = 0				Nbr Retrans = 0

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 15408