O Open Shortest Path First (OSPF) Routing Protocol é definido pelo RFC 2328 OSPF Version 2. 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 documento concentra-se nas funções de gerenciamento de configuração do modelo FCAPS definido pela ITU-T (falha, configuração, contabilidade/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 Informações gerais do OSPF fornece uma visão geral tecnológica do OSPF, incluindo informações de fundo sobre aspectos importantes de uma implantação do OSPF.
A seção Definições do processo fornece uma visão geral das definições do processo usadas para realizar o gerenciamento da configuração do 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 de objetivos, entradas de tarefas, saídas de tarefas, recursos necessários para realizar a tarefa e 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 coletados, eles sã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.
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 dos bancos de dados 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 os principais recursos do OSPF:
Recurso | Descrição |
---|---|
Adjacência | Quando os pares de roteadores OSPF tornam-se adjacentes, os dois roteadores sincronizam seus bancos de dados link-state trocando resumos de banco de dados na forma de pacotes de intercâmbio de banco de dados 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. Ele também desempenha um papel especial no algoritmo de inundação, uma vez que todos os roteadores na rede estão sincronizando seus bancos de dados de link-state enviando e recebendo LSAs para e do DR durante o processo de inundação. |
Fazer backup do roteador designado | Quando o DR atual desaparece, um BDR é eleito em redes multiacesso para acelerar a transição de DRs. Quando o BDR assume o controle, ele não precisa passar pelo processo de adjacência na rede 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. No entanto, informações adicionais de configuração são necessárias para que os roteadores conectados a essas redes se encontrem inicialmente. |
Áreas de gerenciamento de configuração do OSPF | O OSPF permite que os sistemas autônomos sejam divididos em áreas. Isso fornece um nível extra de proteção de roteamento para que o roteamento dentro de uma área seja protegido de todas as informações externas à á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 de trocas de protocolos de roteamento | Cada vez que um roteador OSPF recebe um pacote de protocolo de roteamento, ele pode, opcionalmente, autenticar o pacote antes de processá-lo ainda 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 é, por padrão, derivada 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 existem várias rotas de melhor custo para um destino, o OSPF as localiza e as usa para carregar o tráfego de compartilhamento para o destino. |
Suporte a sub-rede de comprimento variável | Suporta máscaras de sub-rede de comprimento variável transportando 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 para destinos externos em áreas de stub é baseado somente no padrão. |
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.
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.
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.
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 implantada de uma implementação OSPF em relação a um projeto planejado e fornecer um mecanismo para auditar periodicamente a implantação do OSPF, a fim de garantir a consistência ao longo do tempo em relação ao projeto pretendido.
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 de inatividade atribuído a problemas relacionados ao OSPF.
O número de itens adicionados, removidos ou modificados no arquivo de seed. Essa é uma indicação de exatidão e estabilidade.
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 projeto OSPF
Dados de MIB de OSPF coletados por chamada seletiva de SNMP
Informações de syslog
As saídas de processo são definidas abaixo:
Relatórios de configuração do OSPF definidos na seção Apresentação de Dados deste documento
Recomendações de configuração do OSPF para ações corretivas a serem realizadas
As seções a seguir definem a inicialização e tarefas repetitivas associadas ao gerenciamento de configuração de OSPF.
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.
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 |
|
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 | Conjunto de habilidades do engenheiro de rede |
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 será usado para inicializar o software de gerenciamento de configuração OSPF. A formatação do arquivo de seed depende dos recursos utilizados para implementar o processo de gerenciamento de configuração OSPF. Se scripts personalizados forem desenvolvidos, o formato do arquivo de seed será definido pelo design do 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 |
|
Saídas de tarefa | Um arquivo de seed para o processo de gerenciamento da configuração do OSPF. |
Recursos da tarefa |
|
Função da tarefa |
|
As tarefas iterativas são executadas com cada iteração do processo e sua frequência é determinada e modificada para melhorar os indicadores de desempenho.
O arquivo de seed é essencial para a implementação efetiva do processo de gerenciamento de configuração do OSPF. Portanto, o estado atual do arquivo de seed deve ser administrado ativamente. As alterações na rede que afetam o conteúdo do arquivo de seed precisam ser rastreadas pelo proprietário do processo de gerenciamento da configuração do OSPF.
Processo | Descrição |
---|---|
Objetivos da tarefa |
|
Entradas da tarefa |
|
Saídas de tarefa |
|
Recursos da tarefa |
|
Função da tarefa |
|
As duas etapas usadas para executar a verificação do OSPF são:
Coletando os dados.
Analisando os dados.
A freqüência desses dois passos vai variar de acordo como a forma como o processo é usado. Por exemplo, esse 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 houver muito pouca alteração na rede, as verificações de projeto serão realizadas no máximo uma vez por mês.
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 de gerenciamento de configuração do OSPF, consulte a seção Apresentação de Dados neste 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 |
|
Função da tarefa |
|
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:
|
Interfaces OSPF | Descreve uma interface a partir do ponto de vista do OSPF, tal como:
|
estado vizinho OSPF | Descreve um vizinho OSPF.
|
A Cisco atualmente suporta o RFC 1253 OSPF versão 2 MIB . O RFC 1253 não contém definições de armadilha SNMP para OSPF. A versão mais recente do OSPF MIB é RFC 1850 OSPF versão 2
. As interceptações SNMP são definidas para OSPF no RFC 1850. O RFC 1850 não é suportado na implementação do MIB OSPF da Cisco.
Consulte a seção Dados de chamada seletiva de SNMP deste documento para obter mais detalhes.
Consulte a página do Cisco Network Management Software para obter uma lista definitiva sobre quais MIBs são suportadas em qual plataforma e versão de código.
Não há dados específicos de RMON necessários para este procedimento.
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 obter uma lista completa de mensagens do sistema por instalação, consulte Mensagens e procedimentos de recuperação.
Nesta versão do procedimento de gerenciamento de configuração do OSPF, não há dados CLI necessários.
A tabela abaixo define os diferentes componentes da coleta de dados SNMP.
Componente de dados de SNMP | Definição |
---|---|
Configuração geral do SNMP | Consulte Configuração do SNMP para obter informações gerais sobre as melhores práticas de configuração do SNMP. |
Configuração SNMP específica do serviço | 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 sondados SNMP são coletados por um sistema comercial, como o hp OpenView ![]() |
coleção de armadilha de MIB SNMP | 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. |
Não há configurações e dados de RMON necessários nesta versão do procedimento.
As diretrizes gerais de configuração de syslog estão fora do escopo 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
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 do OSPF, não há configurações de CLI e dados necessários.
A seguir está um formato de exemplo para o relatório de área 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 |
O seguinte é um formato de exemplo para o relatório 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 | IP Address | ||
ID da área | |||||
Estado de administração | |||||
Estado OSPF | |||||
Métrica/Custo/Temporizadores | |||||
ID da interface #n | IP Address | ||||
ID da área | |||||
Estado de administração | |||||
Estado OSPF | |||||
Métrica/Custo/Temporizadores | |||||
ID do nó #n | ID de interface nº 1 | IP Address | |||
ID da área | |||||
Estado de administração | |||||
Estado OSPF | |||||
Métrica/Custo/Temporizadores | |||||
ID da interface #n | IP Address | ||||
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 | IP Address | ||
ID da área | |||||
Estado de administração | |||||
Estado OSPF | |||||
Métrica/Custo/Temporizadores | |||||
ID da interface #n | IP Address | ||||
ID da área | |||||
Estado de administração | |||||
Estado OSPF | |||||
Métrica/Custo/Temporizadores | |||||
ID do nó #n | ID de interface nº 1 | IP Address | |||
ID da área | |||||
Estado de administração | |||||
Estado OSPF | |||||
Métrica/Custo/Temporizadores | |||||
ID da interface #n | IP Address | ||||
ID da área | |||||
Estado de administração | |||||
Estado OSPF | |||||
Métrica/Custo/Temporizadores |
O seguinte é um formato de exemplo para o relatório de vizinhos 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 | |||||
Events | |||||
Retrans Que | |||||
ID de vizinho #n | ID de Roteador | ||||
IP Address de Roteador: | |||||
Estado | |||||
Events | |||||
Retrans Que | |||||
ID do nó #n | ID de vizinho #1 | ID de Roteador | |||
IP Address de Roteador: | |||||
Estado | |||||
Events | |||||
Retrans Que | |||||
ID de vizinho #n | ID de Roteador | ||||
IP Address de Roteador: | |||||
Estado | |||||
Events | |||||
Retrans Que | |||||
ID da área #n | ID de nó 1 | ID de vizinho #1 | ID de Roteador | ||
IP Address de Roteador: | |||||
Estado | |||||
Events | |||||
Retrans Que | |||||
ID de vizinho #n | ID de Roteador | ||||
IP Address de Roteador: | |||||
Estado | |||||
Events | |||||
Retrans Que | |||||
ID do nó #n | ID de vizinho #1 | ID de Roteador | |||
IP Address de Roteador: | |||||
Estado | |||||
Events | |||||
Retrans Que | |||||
ID de vizinho #n | ID de Roteador | ||||
IP Address de Roteador: | |||||
Estado | |||||
Events | |||||
Retrans Que |
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.
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. Várias rotas para um único destino podem aparecer na tabela, mas o acesso a essas várias entradas depende dos mecanismos de acesso à tabela definidos pelo protocolo de gerenciamento de rede em uso. ::= { ipRouteEntry 1 } identificador de objeto = 1.3.6.1.2.1.4.21.1.1 |
ipRouteMask | Indica a máscara a ser lógica com o endereço de destino antes de ser comparada ao valor no campo 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:
Observação: todos os subsistemas de roteamento IP usam implicitamente esse mecanismo. ::= { ipRouteEntry 11 } identificador de objeto = 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. ::= { ipRouteEntry 7 } identificador de objeto = 1.3.6.1.2.1.4.21.1.7 |
ipRouteIfIndex | O valor de índice que identifica exclusivamente a interface local através da qual o próximo salto da rota é alcançado. Essa interface é a mesma identificada pelo valor IfIndex. ::= { ipRouteEntry 2 } identificador de objeto = 1.3.6.1.2.1.4.21.1.2 |
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. ::= { ipAddrEntry 2 } identificador de objeto = 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. Essa contagem inclui endereços inválidos (0.0.0.0) e endereços de classe não suportados (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. { ip 5 } identificador de objeto = 1.3.6.1.2.1.4.5 |
ipRoutingDiscards | O número de entradas de roteamento válidas descartadas. Um possível motivo para descartar tal entrada é liberar espaço de buffer para outras entradas de roteamento. { ip 23 } identificador de objeto = 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. { ip 12 } identificador de objeto = 1.3.6.1.2.1.4.12 |
Nome do objeto | Descrição do objeto |
---|---|
ospfAreaID | Um inteiro de 32 bits identificando exclusivamente uma área. O ID de área 0.0.0.0 é usado para o backbone OSPF. ::= { ospfAreaEntry 1 } identificador de objeto = 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. ::= { ospfAreaEntry 2 } identificador de objeto = 1.3.6.1.2.1.14.2.1.2 |
OspfSpfRuns | O número de vezes que a tabela de rotas intra-área foi calculada usando o banco de dados link-state dessa á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. ::= { ospfAreaEntry 5 } identificador de objeto = 1.3.6.1.2.1.14.2.1.5 |
ospfASBdrRtrCount | O número total de ABSRs acessível nessa área. Inicialmente é 0 (o valor padrão) e é calculado em cada passagem SPF. ::= { ospfAreaEntry 6 } identificador de objeto = 1.3.6.1.2.1.14.2.1.6 |
ospfAreaLSACount | O número total de LSAs em um banco de dados link-state de uma área, excluindo LSAs externos. O valor padrão é 0. ::= { ospfAreaEntry 7 } identificador de objeto = 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 LSAs externos (LS tipo 5). 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. ::= { ospfAreaEntry 8 } identificador de objeto = 1.3.6.1.2.1.14.2.1.8 |
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 que a interface OSPF alterou seu estado ou ocorreu um erro. 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 |
Nome do objeto | Descrição do objeto |
---|---|
OspfNbrIpAddr | O endereço IP do vizinho. ::= { ospfNbrEntry 1 } identificador de objeto = 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 linha, isso pode ser derivado da instância. ::= { ospfNbrEntry 2 } identificador de objeto = 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. ::= { ospfNbrEntry 3 } identificador de objeto = 1.3.6.1.2.1.14.10.1.3 |
ospfNbrState | O estado de relacionamento com o vizinho. Os estados são:
|
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. ::= { ospfNbrEntry 7 } identificador de objeto = 1.3.6.1.2.1.14.10.1.7 |
ospfNbrLSRetransQLen | O comprimento atual da fila de retransmissão. O valor padrão é 0. ::= { ospfNbrEntry 8 } identificador de objeto = 1.3.6.1.2.1.14.10.1.8 |
Durante a investigação desse artigo, foi desenvolvido um protótipo 'C'. 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 pela API da Microsoft estão agrupadas em três categorias principais e listadas 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 SnmpUtilPrintAsn Qualquer 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.
A primeira tarefa é a construção de uma lista de nós que serão o destino do programa oscan. Para evitar o problema de "descoberta de dispositivos", um arquivo de seed é necessário para identificar os nós a serem verificados. 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
Deve-se ter cuidado ao acessar a tabela de rotas IP com SNMP, pois é simples sobrecarregar a CPU de um roteador durante essa 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, isso significa que o tempo total de coleta de informações 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. Portanto, cada objeto retornado do SNMP get-request tem o ipRouteDest anexado 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:
Colete o ipRouteIfIndex da tabela de roteamento.
Acesse o ipAddrTable usando o ipRouteIfIndex para correspondência de padrão.
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.
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
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. Portanto, as mesmas subrotinas que foram usadas para processar e pesquisar por ipRouteTable e ipRouteIfIndex podem ser reutilizadas aqui.
Há vários itens de dados que não estão na tabela de área OSPF incluídos 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. Esses objetos estão associados a 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
O índice para a tabela de vizinhos consiste em dois valores:
ospfNbrIpAddr—O ospfNbrIpAddr é o endereço IP 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. Depois de fazer esse ajuste, as mesmas subrotinas que foram usadas para processar e pesquisar por ipRouteTable e ipRouteIfIndex podem ser reutilizadas 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