CURSO DE INFORMÁTICA (BACHARELADO)
DESENVOLVIMENTO DE UM PROTÓTIPO DE MIB-BROWSER EM DELPHI
Relatório do Trabalho de Conclusão de Curso submetido à Universidade do Planalto Catarinense para obtenção dos créditos de disciplina com nome equivalente no curso de Informática - Bacharelado.
ANDRÉ COELHO RAMOS
UNIVERSIDADE DO PLANALTO CATARINENSE
DEPARTAMENTO DE CIÊNCIAS EXATAS E TECNOLÓGICAS CURSO DE INFORMÁTICA
(BACHARELADO)
DESENVOLVIMENTO DE UM PROTÓTIPO DE MIB-BROWSER EM DELPHI
Relatório do Trabalho de Conclusão de Curso submetido à Universidade do Planalto Catarinense para obtenção dos créditos de disciplina com nome equivalente no curso de Informática - Bacharelado.
ANDRÉ COELHO RAMOS
Orientador : Prof. Silvio Costa Sampaio, MSc
DESENVOLVIMENTO DE UM PROTÓTIPO DE MIB-BROWSER EM DELPHI
ANDRÉ COELHO RAMOS
ESTE RELATÓRIO, DO TRABALHO DE CONCLUSÃO DE CURSO, FOI JULGADO ADEQUADO PARA OBTENÇÃO DOS CRÉDITOS DA DISCIPLINA DE TRABALHO DE CONCLUSÃO DE CURSO DO VIII
SEMESTRE, OBRIGATÓRIA PARA OBTENÇÃO DO TÍTULO DE: BACHAREL EM INFORMÁTICA
Prof. Silvio Costa Sampaio, MSc. Orientador
BANCA EXAMINADORA:
Prof. Marcos André Pisching, MSc. Universidade do Planalto Catarinense
Prof. Douglas Nazareno Vargas, MSc. Universidade do Planalto Catarinense
Prof. Angelo Augusto Frozza, Esp. Supervisor de TCC
Prof. Alexandre Perin de Souza Coordenador de Curso
iv
Dedico este trabalho a todos os meus familiares e amigos.
Agradeço a minha família pelo apoio recebido, a meus amigos na ajuda com os estudos, os professores e a Deus.
vi
SUMÁRIO
SUMÁRIO... VI LISTA DE FIGURAS... VIII RESUMO... IX ABSTRACT ...X 1.INTRODUÇÃO...1 1.1. Definição do problema ...1 1.2. Justificativa...1 1.3. Objetivos...2 1.3.1. Objetivo geral... 2 1.3.2. Objetivos específicos ... 2 1.4. Metodologia...3 2.GERÊNCIA DE REDES...4 2.1. Ambiente Gerenciado...5 2.2. Mecanismo Gerenciado ...5
2.3. Sistema de Gerenciamento de Rede ...5
2.4. Gerente...6
2.5. Agente...6
2.6. Base de Informações de Gerenciamento ...6
2.7. Protocolo de Gerenciamento ...7
2.8. Monitoramento ...7
2.9. Controle ...7
3.ARQUITETURAS DE GERENCIAMENTO...8
3.1. Modelo de Gerenciamento OSI ...9
3.1.1. Principais Componentes... 10
3.1.2. Áreas Funcionais... 11
3.2. Modelo de Gerenciamento TCP/IP – Internet ...12
3.2.1. Principais Elementos... 12
4.OPROTOCOLO SNMP ...14
4.1. Mensagens no protocolo SNMP...16
4.2. Operações disponíveis no protocolo SNMP...19
4.3. Aplicação Gerente ...23
4.4.1. Diagrama de um Agente... 26
5.BASE DE INFORMAÇÕES DE GERENCIAMENTO (MIB)...28
5.1. MIB da Internet (TCP/IP)...28
5.2. A MIB no modelo OSI ...29
5.2.1. Hierarquia de Herança ... 30
5.2.2. Hierarquia de Nomeação ... 30
5.3. Componentes Básicos de Uma MIB ...30
5.3.1. A Estrutura de Gerenciamento da Informação – SMI... 32
5.3.2. Identificadores de Objetos (OIDs) ... 32
5.3.3. Módulos MIB ... 35
5.3.4. Mecânica da Especificação de Módulos ... 35
5.3.5. Itens Object Identifier... 35
5.3.6. Definições dos Objetos Gerenciados... 36
5.3.7. Traps... 40
5.3.8. Padrões utilizados em uma mib... 41
5.3.9. MIBs proprietárias ... 42
6.IMPLEMENTAÇÃO...44
6.1. Descrição da biblioteca Synapse ...45
6.1.1. Detalhes para utilização de SNMP com Synapse - Classe TSNMPSend ... 46
6.1.2. Classe TSNMPMib ... 48
6.1.3. Classe: TSNMPrec ... 48
6.1.4. Classe TSNMPSend ... 50
6.1.5. Outras funções: ... 50
6.2. Descrição do MIB-BROWSER...51
6.2.1. Instruções de uso do MIB-BROWSER... 53
6.3. Descrição do MIB-PARSER ...55
6.3.1. Instruções de uso do MIB-PARSER... 56
6.4. Análise dos Resultados...56
CONCLUSÃO...62
REFERÊNCIAS ...63
LISTA DE FIGURAS
FIGURA 1: Principais Componentes do Gerenciamento OSI. ...10
FIGURA 2: Modelo SNMP para o gerenciamento de rede. ...13
FIGURA 3: Formato da mensagem SNMP. ...18
FIGURA 4: Tipos de aplicações de gerenciamento e forma de comunicação...23
FIGURA 5: Componentes de uma Aplicação Gerente. ...24
FIGURA 6: Funções desempenhadas por um Agente SNMP. ...27
FIGURA 7: A árvore MIB II. ...33
FIGURA 8: Posição do objeto sysDescr na árvore de dados da MIB. ...34
FIGURA 9: Organização da sub-árvore de algum fornecedor...43
FIGURA 10: MIB-BROWSER...53
FIGURA 11: MIB-PARSER. ...55
FIGURA 12: Resultado do Get. ...57
FIGURA 13: Resultado do Get Next. ...58
FIGURA 14: Resultado do Get Table. ...59
FIGURA 15: Resultado do SNMP Scan...60
RESUMO
A gerência de redes é um assunto complexo, principalmente pelo constante desenvolvimento e adição de novas tecnologias ás redes de computadores, novos tipos de equipamentos e implementações proprietárias, tornando o ambiente gerenciado cada vez mais heterogêneo e mais difícil de ser controlado. Para gerenciar esta complexidade foi criado o protocolo SNMP (Simple Network Management Protocol) que visa oferecer um meio simples, rápido e eficiente de se obter dados dos equipamentos gerenciáveis que formam a rede para posterior análise, auxiliando ao gerente da rede através da análise destes dados a identificar problemas e possíveis melhorias na rede. O SNMP utiliza-se de agentes implementados nos equipamentos gerenciáveis da rede para obter dados gerenciais, pois cada um destes equipamentos possui um banco de dados de informação chamado de MIB (Management Information
Base). Este trabalho visa à implementação de um software capaz de visualizar os
dados contidos na MIB, utilizando o protocolo SNMP – o MIB-BROWSER. Ao longo deste trabalho são apresentados diversos tópicos sobre gerência de redes, as principais características do protocolo SNMP, o modelo Gerente/Agente e como eles se comunicam, a estrutura das MIBs, suas sintaxe e forma de acesso, finalizando com a descrição de como foi realizada a implementação do software.
ABSTRACT
Network management is a complex subject mainly by the constant development and addiction of new technologies in the network, new kinds of equipments and private implementations, making the environment more and more heterogeneous and harder to be controlled. To manage all this complexity was created the SNMP (Simple Network Management Protocol) protocol which intends to offer simple, fast and effective way to get data from the network equipments to posterior analysis to help the network manager through of the analysis of these data to identify troubles and possible improvements in the network. SNMP uses the agents implemented within network equipments to get this data and each agent has a database of information’s called MIB (Management Information Base). This work intends to implement a software tool to view the data stored in the MIB by using the SNMP protocol – the MIB-BROWSER. Through this work are presented many topics of network management, the main issues of SNMP protocol, Manager/Agent model and its communication, MIBs structure, its syntax and access mode finalizing with a description of how is made the implementation of the software .
1. INTRODUÇÃO
Com o grande aumento de equipamentos nas redes de computadores torna-se necessário à criação de ferramentas que auxiliem, de alguma forma, o controle destas redes. Para gerenciar estas redes, o protocolo mais utilizado é o SNMP (Simple
Network Management Protocol), que permite realizar consultas a agentes instalados
em equipamentos na rede que monitoram e fornecem informações a respeito do próprio equipamento, como tráfego da rede, taxa de erros, problemas de hardware entre outros. Todos estes dados são armazenados numa base de dados, chamada MIB (Management Information Base).
1.1. Definição do problema
Quando se pensa em gerenciar redes baseadas em TCP/IP, logo se pensa em
SNMP e o conceito de gerentes e agentes. Para a plena utilização do protocolo SNMP e
para a criação de programas gerenciadores eficientes, necessita-se saber dos objetos gerenciáveis da rede, como hubs ou roteadores, as variáveis que eles disponibilizam em suas MIBs para consulta ou modificação.
Pensando em facilitar a criação de gerentes SNMP pensou-se na criação de uma ferramenta que permitisse visualizar as características gerenciáveis dos equipamentos de rede atuais.
1.2. Justificativa
2
computadores foram se tornando cada vez maiores e mais complexas. Neste contexto, se torna cada vez mais difícil o controle sobre estas, de modo que, é útil um software que auxilie de alguma forma esta evolução. Também gera uma ótima fonte de conhecimento sobre gerência de redes de computadores.
Já existem muitas implementações semelhantes à desenvolvida neste trabalho, porém esta tem a característica de ser desenvolvida em Delphi que é um ambiente de programação bastante conhecido, tornando-se uma ferramenta didática para o ensino de conceitos de gerência de redes além de estar sendo disponilibilizado o código-fonte do software a todos que se interessarem.
1.3. Objetivos
1.3.1. Objetivo geral
O objetivo é desenvolver uma ferramenta para a visualização de MIBs SNMP de equipamentos de rede, podendo percorrendo sua estrutura em busca de seus objetos gerenciáveis, implementada utilizando o ambiente de programação Delphi com auxílio da biblioteca Winsock 1e o conjunto de módulos do projeto Synapse2.
1.3.2. Objetivos específicos
Os objetivos específicos do trabalho são:
a) Revisar a bibliografia disponível e existente sobre gerência de redes, SNMP e
MIBs;
b) Pesquisar e estudar RFCs (Request for Comments) disponíveis na Internet para entender a estrutura das MIBs;
c) Pesquisar implementações semelhantes para servir como base de referência ao estado da arte;
1 Windows Sockets: Biblioteca de funções padrão que fornece uma interface TCP/IP para aplicações no
ambiente Windows.
2 Fornece uma biblioteca completa de classes e funções para o desenvolvimentos de aplicações de redes no
d) Analisar posteriormente as ferramentas necessárias para a codificação deste programa;
e) Implementar um protótipo de MIB-BROWSER.
1.4. Metodologia
O trabalho será desenvolvido observando as seguintes etapas:
− Levantamento bibliográfico: Consulta à Internet, universidades, sites específicos, empresas que implementam esta tecnologia, listas de discussão;
− Implementação: Para a implementação será usado o ambiente de programação Delphi 5.0 da Inprise Corporation fazendo-se uso da biblioteca Winsock do Windows;
− Testes: como mesa de testes a Internet se faz apropriada, e possivelmente máquinas da universidade;
− Validação: com a ajuda do professor buscaremos um alto grau de qualidade no projeto;
2. GERÊNCIA DE REDES
Para garantir uma certa qualidade dos serviços a seus usuários, as redes de computadores devem ser gerenciadas. Este gerenciamento envolve o monitoramento e o controle de recursos distribuídos em redes. Em essência, o gerenciamento de redes busca assegurar que sistemas de informação, disponíveis em redes, estejam operacionais e eficazes a todo instante.
Segundo SOARES, L. F. (1995), o gerenciamento de redes deve ser visto como uma parte essencial de qualquer rede da atualidade.
No entanto, o gerenciamento de redes de computadores é complexo. Na proporção que as redes tornam-se maiores (extensão), complexas (tecnologia) e heterogêneas (plataformas de hardware e software distintas), tornam o gerenciamento em si mais complexo ainda. Conseqüentemente o gerenciamento não pode ser realizado somente pelo esforço humano. A complexidade do gerenciamento de redes impõe o uso de soluções automatizadas de gerenciamento.
Segundo SOARES, L. F. (1995), O SNMP tornou-se a solução de gerência de redes mais popular em uso atualmente.
A gerência está associada ao controle de atividades e ao monitoramento do uso de recursos da rede. As tarefas básicas da gerência em redes, simplificadamente, são obter informações da rede, tratar estas informações, possibilitando um diagnóstico, e encaminhar as soluções dos problemas. Para cumprir estes objetivos, funções de gerência devem ser embutidas nos diversos componentes de uma rede, possibilitando descobrir e prever problemas.
Faz-se necessário definir alguns conceitos para se entender o gerenciamento de redes e como será implementado um MIB-BROWSER neste contexto.
Segundo MEIRELLES, L. F. T. (1999), existe um conjunto de conceitos e definições que são úteis para o entendimento geral do conceito de gerência de redes que são apresentados a seguir.
2.1. Ambiente Gerenciado
O ambiente gerenciado compreende mecanismos com suporte a funcionalidades de gerenciamento, juntamente com os aspectos de comunicação que permitem suas interconexões. Desta forma, o ambiente gerenciado pode ser constituído de um ou mais mecanismos, como exemplos, temos:
• um roteador;
• as conexões TCP de um determinado número de servidores; • todos os dispositivos gerenciáveis de uma mesma sub-rede;
• todos os dispositivos gerenciáveis de um conjunto de LANs interligadas.
2.2. Mecanismo Gerenciado
Compreende tanto hardware como software que apresente necessidade e condições de ser gerenciado. Como exemplo de hardware pode-se citar: interfaces de rede, discos e impressoras. O software poderá compreender, por exemplo, aspectos relacionados à implementação da pilha TCP/IP, como estatísticas sobre o processamento de datagramas IP.
2.3. Sistema de Gerenciamento de Rede
Um sistema de gerenciamento de rede é formado por uma coleção de ferramentas utilizadas no monitoramento e controle da rede. A coleção de software de um sistema de gerenciamento de rede é também organizada para assumir o papel de gerente, agente ou ambos.
6
2.4. Gerente
O gerente compreende um tipo de software que permite a obtenção e o envio de informações de gerenciamento junto aos mecanismos gerenciados mediante comunicação com um ou mais agentes. As informações de gerenciamento podem ser obtidas com o uso de requisições efetuadas pelo gerente ao agente, como também, mediante envio automático disparado pelo agente a um determinado gerente. Tipicamente um gerente está presente em uma estação de gerenciamento de rede.
2.5. Agente
O agente compreende um tipo de software presente junto aos dispositivos gerenciados. A função principal de um agente compreende o atendimento das requisições enviadas por um software gerente e o envio automático de informações de gerenciamento ao software gerente, indicando a ocorrência de um evento previamente programado. Também compete ao agente efetuar a interface entre os diferentes mecanismos usados na instrumentação das funcionalidades de gerenciamento inseridas em um determinado dispositivo gerenciado.
2.6. Base de Informações de Gerenciamento
Compreende um conjunto de variáveis usadas para representar informações estáticas ou dinâmicas vinculadas a um determinado dispositivo gerenciado. Grande parte das funcionalidades de um software Gerente/Agente destina-se a troca de dados existente na base de informações de gerenciamento, conhecida na literatura como
Management Information Base - MIB.
Como exemplo temos a MIB-II, presente e diversos dispositivos na rede, que possui, entre muitas outras, as seguintes características:
• sysDescr: Descrição textual do dispositivo;
• sysUpTime: Tempo desde a última reinicialização.
2.7. Protocolo de Gerenciamento
O protocolo de gerenciamento compreende o conjunto de regras e formatos de mensagens. Os mecanismos de comunicação entre gerentes e agentes são implementados com base nas especificações de um determinado protocolo de gerenciamento. O SNMP e o CMIP são os usados atualmente na indústria e serão vistos adiante.
2.8. Monitoramento
O monitoramento é uma função de gerenciamento da rede destinada à observação e análise do estado e comportamento dos dispositivos gerenciados. Um usuário, ao utilizar um software gerente para verificar o estado operacional (up ou
down) de uma ou mais interfaces de rede, está efetuando uma função de
monitoramento.
2.9. Controle
O controle é uma função de gerenciamento da rede destinada à alteração de parâmetros de gerenciamento que acarretam ações junto aos dispositivos gerenciados. Um usuário, ao utilizar um software gerente para desabilitar o funcionamento temporário de uma determinada interface de rede, está executando uma função de controle.
3. ARQUITETURAS DE GERENCIAMENTO
Segundo PRAS, A. (1995), arquiteturas para o Gerenciamento de Redes são desenvolvidas para que projetistas estabeleçam uma discussão das funções de gerenciamento de redes em um alto nível de abstração, orientando, desta forma, o projeto de protocolos e serviços de gerenciamento.
Durante a década de 80, os principais fornecedores de equipamentos e serviços de rede, dentre eles: IBM, DEC e AT&T, tentaram impor seus padrões para o gerenciamento. Embora eficientes, dentro do escopo de produtos de cada fabricante, uma solução universal e padronizada tornava-se cada vez mais necessária.
Segundo MEIRELLES, L. F. T. (1999), a ISO (International Organization
for Standardization), em 1989 adicionou ao modelo de referência OSI (Open Systems Interconnection) um esquema básico da arquitetura de gerenciamento de rede. Uma
série de documentos, denominada como série X.700, resultante do trabalho cooperativo entre a ISO e o CCITT (Comité Consultatif International Télégraphique et
Téléphonique, agora chamado de International Telecommunication Union-Telecommunication Standardization Sector (ITU-TSS, freqüentemente abreviado como ITU-T).), destina-se a criar condições para o desenvolvimento de produtos de
gerenciamento de redes de computadores e sistemas de comunicações heterogêneos. Segundo STALLINGS, W. (1998), com a especificação do Simple Network
Management Protocol - SNMP, efetuada na sua primeira versão (SNMPv1) em 1988
pela IETF (Internet Engineering Task Force), iniciou-se o processo de padronização do principal modelo utilizado no gerenciamento de redes, mais especificamente, redes que adotam a pilha de protocolos TCP/IP (Transmission Control Protocol/Internet
Funcionalidade de gerenciamento vem sendo cada vez mais incorporadas em diferentes dispositivos de rede, assumindo total conformidade com a versão 1 e 2 do
SNMP. No final de 1997, foi iniciado o processo de aprovação do SNMPv3 junto a IETF. A nova versão, dentre outros aspectos, visa ampliar as funções de
gerenciamento existentes no modelo, tratando questões de segurança.
3.1. Modelo de Gerenciamento OSI
Segundo BRISA. (1997), preocupada com a questão do gerenciamento de redes, a ISO propôs, em 1989, uma arquitetura de gerenciamento capaz de viabilizar o controle e monitoramento de redes que utilizem os protocolos OSI. Dessa forma o modelo de referência ISO/OSI (também conhecido como modelo de referência OSI) foi estendido para acomodar a capacidade de gerenciamento, e foram especificados protocolos para o transporte de informações de gerenciamento entre sistemas abertos.
O modelo de dados definidos para a Estrutura de Gerenciamento ISO/OSI é mais rico, apresentando uma melhor qualidade de informações. Por outro lado, uma implementação CMIP tende a ser mais lenta e maior, uma vez que requer maior capacidade de processamento e memória.
Para resolver os problemas associados à gerência em redes, a ISO propôs três modelos:
• O Modelo Organizacional - estabelece a hierarquia entre sistemas de gerência em um domínio de gerência, dividindo o ambiente a ser gerenciado em vários domínios;
• O Modelo Informacional - define os objetos de gerência, as relações e as operações sobre esses objetos. Uma MIB é necessária para armazenar os objetos gerenciados;
• O Modelo Funcional - descreve as funcionalidades de gerência: gerência de falhas, gerência de configuração, gerência de desempenho, gerência de contabilidade e gerência de segurança.
10
3.1.1. Principais Componentes
Os principais componentes no Modelo de Gerenciamento OSI são o Gerente, Agente, Objeto Gerenciado e Protocolo de Gerenciamento, revestidos de maiores funcionalidades e implementados diante de uma maior complexidade.
Segundo BRISA. (1997), no Modelo de Gerenciamento OSI, um gerente transmite operações de gerenciamento aos agentes a fim de obter informações atualizadas sobre os objetos gerenciados, visando monitoramento e/ou controle. Um agente recebe as operações de gerenciamento emitidas pelo gerente e executa as ações necessárias sobre os objetos gerenciados. Um agente pode, ainda, transmitir ao gerente notificações geradas pelos objetos gerenciados ou notificações sobre a ocorrência de eventos. Um objeto gerenciado representa um recurso sujeito ao gerenciamento, sua definição é efetuada em termos de atributos, das operações a que pode ser submetido, das notificações que pode emitir e de seus relacionamentos com outros objetos gerenciados. O conjunto de objetos gerenciados constitui a Base de Informações de Gerenciamento (MIB - Management Information Base).
O Modelo de Gerenciamento OSI possui um serviço e um protocolo para troca de informações de gerenciamento, denominados respectivamente CMIS (Common Management Information Service) e CMIP (Common Management
Information Protocol). A Figura 1 apresenta os seus principais componentes.
FIGURA1: Principais Componentes do Gerenciamento OSI. (Fonte: BRISA. 1997)
Comparando-se o protocolo CMIP com o protocolo SNMP, o primeiro possui uma quantidade bem menor de produtos que o implementam e possui uma quantidade maior de operações, permitindo uma maior versatilidade no controle exercido sobre os elementos de rede.
3.1.2. Áreas Funcionais
Segundo STALLINGS, W. (1996), em virtude da complexidade natural das redes de computadores, gerenciá-las de forma eficiente e eficaz representa um grande desafio. Preocupada em facilitar e organizar o desenvolvimento de projetos (construção e ou utilização de software) destinados ao gerenciamento de redes, a ISO propõe no Modelo de Gerenciamento OSI, a divisão das Tarefas/Processos de gerenciamento em cinco áreas funcionais:
• Gerenciamento de Falha: Compreende um conjunto de facilidades que habilitam a detecção, o isolamento e a correção de operações anormais no ambiente de rede gerenciado.
• Gerenciamento de Contabilização: Compreende um conjunto de facilidades que permitem a apropriação dos custos e tarifação em decorrência da utilização dos objetos gerenciados.
• Gerenciamento de Configuração: Tem como função controlar e monitorar as condições do ambiente de rede, identificando e ocasionando mudanças no estado dos objetos gerenciados.
• Gerenciamento de Desempenho: Oferece um conjunto de funções para medir, monitorar, avaliar e relatar os níveis de desempenho alcançados pela rede.
• Gerenciamento de Segurança: Trata de questões relacionadas a garantir a política de segurança definida para rede, além de cuidar da segurança do próprio gerenciamento.
Embora esta classificação tenha sido desenvolvida para ambientes de rede
OSI, esta forma de organizar o gerenciamento da rede tem sido amplamente aceita por
12
do gerenciamento do Modelo Internet.
3.2. Modelo de Gerenciamento TCP/IP – Internet
Segundo MEIRELLES, L. F. T. (1999), a arquitetura TCP/IP foi elaborada pela IETF, uma organização aberta que define os padrões para Internet. As definições para os protocolos e para o gerenciamento de redes TCP/IP encontram-se em documentos chamados de RFCs (Request for Comments) que podem ser acessados através da própria rede.
Este modelo de gerenciamento Internet também é conhecido como abordagem SNMP ou módulo de gerenciamento SNMP, possuindo uma abordagem genérica, podendo ser aplicado no gerenciamento de diferentes sistemas.
O SNMP pode ser visto como um protocolo padrão para troca de informação de gerenciamento de redes.
Segundo PERKINS, D. M. E. (1997), sua operação é bastante simples, sendo as mensagens (primitivas de serviço) utilizadas por ele as citadas a seguir:
• Get (Request, Next Request, Response): Trata-se do pedido do gerente para ler os dados de gerenciamento da MIB do agente. A Get Request faz o pedido inicial pelo gerente, a Response envia os dados para o gerente e a Next Request pede outro trecho da tabela seqüencialmente.
• Set (Request): Serve para alteração de dados da MIB. O agente recebe um pedido de Set Request para alterar determinado dado.
• Trap: É um informe dado ao gerente de que algo de anormal está acontecendo no sistema, tem funcionamento semelhante a um alarme.
3.2.1. Principais Elementos
PERKINS, D. M., E. (1997) descreve que o modelo SNMP consiste dos seguintes elementos:
• No mínimo uma estação de gerenciamento, contendo uma ou mais entidades SNMP chamadas de Gerente;
• Um ou mais nodos gerenciados, cada um contendo uma entidade SNMP chamada de Agente;
• Opcionalmente, entidades SNMP chamadas de entidades com dupla função, capazes de desempenhar o papel de Agente-Gerente;
• Informações de gerenciamento em cada nodo gerenciado, as quais descrevem a configuração, o estado, as estatísticas e as ações que controlam os nodos gerenciados;
• Um protocolo para comunicação de gerenciamento utilizado pelos Gerentes e Agentes durante a troca de mensagens de gerenciamento. A figura 2 mostra Modelo SNMP para o gerenciamento de rede
FIGURA2: Modelo SNMP para o gerenciamento de rede. (Fonte: PERKINS, D. M., E. 1997)
4. O PROTOCOLO SNMP
Segundo STALLINGS, W. (1996), o protocolo SNMP (Simple Network
Management Protocol) é a solução adotada na Internet para permitir que gerentes de
redes possam localizar e corrigir problemas. Geralmente, é utilizado um processo na máquina do administrador chamado de cliente (uma Workstation ou um gateway, por exemplo) que se conecta a um ou mais servidores SNMP localizados em máquinas remotas, para executar operações sobre os objetos gerenciados (por exemplo, para obter informações sobre estes objetos).
O SNMP teve sua origem baseada em um outro protocolo chamado SGMP (Simple Gateway Management Protocol), o qual é utilizado para monitoramento de Gateway. Além das modificações em relação ao protocolo SGMP, o SNMP passou a adotar algumas características do gerenciamento OSI. Sua localização é equivalente à camada de aplicação do modelo OSI.
O SNMP utiliza o protocolo UDP na comunicação entre cliente e servidor. Para o cliente da rede, o SNMP executa as operações sobre os objetos de forma transparente, o que permite a interface do software de gerenciamento da rede criar comandos imperativos para executar operações sobre os objetos gerenciados. Esta é a grande diferença entre gerenciar uma rede usando o protocolo SNMP e gerenciar a mesma rede usando outros protocolos.
No protocolo SNMP são definidas tanto a sintaxe (forma e a representação dos nomes e dos valores) como o significado das mensagens trocadas entre os clientes e os servidores. O formato das mensagens e dos objetos gerenciados de uma MIB são especificados com a linguagem ASN.13.
O SNMP também define as relações administrativas entre os vários gateways que estão sendo gerenciados, determinando a autenticação necessária para os clientes acessarem os objetos gerenciados.
Segundo STALLINGS, W. (1996), ao contrário dos outros protocolos de gerenciamento que apresentam muitos comandos (operações), o SNMP apresenta somente um conjunto limitado de comandos, baseado num simples mecanismo de Busca/Alteração (fetch-store). Portanto, é muito mais simples de ser implementado do que um protocolo com muitas operações, em que cada operação sobre um objeto necessita de um comando diferente para implementá-la.
O mecanismo de Busca/Alteração conceitualmente só apresenta duas operações: uma que permite ao cliente alterar atributos de um objeto de uma MIB (SET), e outra para obter os valores dos atributos de um objeto (GET). Somente estão disponíveis estas operações, e suas variações, para o gerenciamento da rede, que serão aplicadas sobre os objetos de uma MIB. A principal vantagem de um mecanismo como este é a simplicidade e a flexibilidade que este mecanismo dá ao protocolo, o que permite ao SNMP ser um protocolo bem estável porque a sua estrutura básica continuará fixa, mesmo que novos objetos sejam adicionados na MIB, ou que novas operações sejam definidas sobre estes objetos (elas serão constituídas por estas operações básicas).
A MIB define o conjunto e a semântica dos objetos que os servidores SNMP devem controlar, ou seja, define o conjunto conceitual de objetos que um servidor
SNMP controla. A MIB é usada para armazenar em seus objetos os estados internos
das entidades de uma rede.
Ao receber e enviar mensagens no protocolo SNMP, os nomes dos objetos não devem ser armazenados na forma textual, e sim na forma numérica definida pela sintaxe ASN.1, que representa o objeto univocamente, com o objetivo de tornar o pacote SNMP mais compacto. Quando a forma numérica que representa um objeto terminar com um zero (como em 1.3.6.1.2.1.4.3.0), representa que o objeto é a única instância existente. Por exemplo, o objeto gerenciável
16
como “1.3.6.1.2.1.4.3.0.”.
Para minimizar o espaço interno necessário para representar um objeto, e considerando que todos os objetos em uma MIB apresentam o mesmo prefixo no seu nome, podemos retirar o prefixo após a mensagem chegar na máquina, e recolocá-lo imediatamente antes de enviar a mensagem para outra máquina.
Pode-se, resumidamente, dizer que os principais objetivos do protocolo
SNMP, por ser flexível e simples, são:
• Reduzir o custo da construção de um agente que suporte o protocolo; • Reduzir o tráfego de mensagens de gerenciamento pela rede necessária
para gerenciar os seus recursos;
• Reduzir o número de restrições impostas às ferramentas de gerenciamento da rede, devido ao uso de operações complexas e pouco flexíveis;
• Apresentar operações simples de serem entendidas, sendo facilmente usadas pelos desenvolvedores de ferramentas de gerenciamento;
• Permitir facilmente a introdução de novas características e novos objetos não previstos ao se definir o protocolo;
• Construir uma arquitetura que seja independente de detalhes relevantes à somente algumas implementações particulares.
Um gerente interage com um agente de acordo com as regras estabelecidas pela arquitetura de gerenciamento.
4.1. Mensagens no protocolo SNMP
Segundo STALLINGS, W. (1996), ao contrário de muitos outros protocolos
TCP/IP, as mensagens no protocolo SNMP além de não apresentarem campos fixos,
são codificadas usando a sintaxe ASN.1 (tanto a mensagem de pedido, como a de resposta) o que dificulta o entendimento e a decodificação das mensagens, a figura 3 mostra o formato da mensagem SNMP. As partes mais importantes de uma mensagem são: as operações (GET, SET e GET-NEXT) e a identificação, no formato ASN.1, dos
objetos em que as operações devem ser aplicadas.
Existe um cabeçalho que informa o tamanho da mensagem, que só será conhecido após a representação de cada campo ter sido computada. Na verdade, o tamanho da mensagem depende do tamanho de sua parte remanescente (que contém os dados), portanto o tamanho só poderá ser computado após a construção da mensagem. Uma maneira de evitar este problema é construir a mensagem de trás para frente.
Uma mensagem SNMP deve definir o servidor do qual obtemos ou alteramos os atributos dos objetos, e que será responsável por converter as operações requisitadas em operações sobre as estruturas de dados locais. Após verificar os campos de uma mensagem, o servidor deve usar as estruturas internas disponíveis para interpretar a mensagem e enviar a resposta da operação ao cliente que requisitou o pedido.
Uma mensagem é constituída por três partes principais: • A versão do protocolo (Version);
• A identificação da comunidade (Community), usada para permitir que um cliente acesse os objetos gerenciados através de um servidor SNMP; • A área de dados, que é dividida em unidades de dados de protocolo
(Protocol Data Units - PDUs). Cada PDU é constituída ou por um pedido do cliente, ou por uma resposta de um pedido (enviada pelo servidor). O primeiro campo de uma mensagem SNMP é um operador seqüencial, seguido por um campo com o tamanho total da mensagem (se este tamanho não for igual ao do datagrama, será retornado um código de erro). O próximo campo é um número inteiro que identifica a versão do protocolo SNMP, seguido por um campo usado para a autentificação, indicando a comunidade que o cliente pertence (a comunidade public permite a qualquer cliente acessar os objetos, não precisando o servidor verificar se o cliente pode ou não acessar o objeto). O quarto campo contém a operação que será executada, devendo ser um GET, SET ou GET-NEXT, pois a operação de TRAP só é gerada pelo agente. O quinto campo é usado para o servidor ter certeza de que o valor deste campo é igual ao tamanho da parte da mensagem que contém os dados. O sexto campo é uma identificação para o pedido, e o sétimo e o oitavo campos são flags que indicam erros quando estão setadas (campos de status e de
18
índice de erro).
Na definição de uma mensagem, cada uma das PDUs são constituídas ou por um dos cinco tipos de PDUs para as operações ou por uma PDU para a resposta. Na definição da mensagem SNMP, deve-se ter uma sintaxe individual para cada um das cinco operações da PDU. Alguns termos encontrados nas sintaxes das PDUs das operações são:
• O campo RequestID é um inteiro de 4 bytes (usado para identificar as respostas);
• Os campos ErrorStatus e ErrorLevel são inteiros de um byte (sendo nulos em um pedido de um cliente);
• O campo VarBindList é uma lista de identificadores de objetos na qual o servidor procura os nomes dos objetos, sendo definida como uma seqüência de pares contendo os nomes dos objetos (em ASN.1 este par é representado como uma seqüência de dois itens). Na sua forma mais simples (com um objeto) apresenta dois itens: o nome do objeto e um ponteiro nulo.
FIGURA3: Formato da mensagem SNMP. (Fonte: PRAS, A. 2000)
4.2. Operações disponíveis no protocolo SNMP
Após a definição de como são armazenadas as informações em uma MIB (que será visto nos próximos capítulos) pelas entidades do protocolo SNMP, é importante saber o que deve ser feito com estas informações. O que deve ser feito com os objetos num ambiente de gerenciamento é definido através das operações aplicadas nos objetos, que são enviadas ao servidor pelo cliente. Duas operações (comandos) básicas no protocolo SNMP são:
• A operação SET é usada por um cliente para alterar um ou mais atributos de um objeto gerenciado (set-request);
• A operação GET é usada por um cliente para obter o valor de um atributo de um objeto gerenciado (get-request para o pedido e get-response para obter o retorno deste pedido).
Segundo STALLINGS, W. (1996), uma operação GET ou SET somente se refere a uma única instância de um objeto representada através de seu nome. No protocolo SNMP, as operações são atômicas, isto é, todas as operações de um pedido devem ser executadas. Não existem execuções parciais de um pedido (no caso, operações aplicadas a múltiplos objetos). Se ocorrer algum erro durante a execução de uma operação, os resultados produzidos por esta operação devem ser ignorados.
Antes de executar um pedido, o servidor deve mapear apropriadamente os nomes dos objetos codificados em ASN.1 nos objetos internos que armazenam as características das entidades da rede (através dos atributos do objeto).
Além das operações padrões, existem mais outras duas operações:
• Numa operação GET-NEXT o nome do objeto não só especifica o objeto a acessar (para obter seus atributos, como na operação GET), como também é usado para descobrir qual o próximo objeto na seqüência léxica. Como retorno, a operação informa o nome do próximo objeto na hierarquia da MIB, e os valores dos seus atributos (obtidos através da execução de uma operação GET sobre o objeto);
20
permitindo aos servidores SNMP enviarem informações aos clientes sempre que ocorrer algum evento que informa a ocorrência de alterações nos objetos (no protocolo, foram definidas somente algumas traps). A operação GET-NEXT é útil para obter os atributos dos objetos de uma tabela de tamanho desconhecido, pois um cliente pode enviar continuamente requisições GET-NEXT a um servidor que se encarregará de enviar os atributos do objeto e o nome do próximo objeto. Cada novo pedido deve especificar o nome do objeto retornado pelo pedido anterior, o que permite percorrer a tabela sem saber qual o próximo objeto desta. Este processo é chamado de caminhamento na tabela. Devido ao ASN.1 não apresentar nenhum mecanismo para implementar tabelas ou para indexá-las, denotamos os elementos individuais (objetos) de uma tabela através de um sufixo. Para facilitar o uso do comando GET-NEXT em tabelas, alguns nomes de objetos na MIB correspondem tabelas completas ao invés de objetos individuais, não podendo ser usados em uma operação GET (pois esta falhará), mas podem ser usados como parâmetro para a operação GET-NEXT, indicando o primeiro objeto da tabela. Não será necessário conhecer o nome do próximo objeto, pois cada comando
GET-NEXT retornará o nome do próximo item da tabela. Executando este processo
sucessivamente até que todos os itens da tabela tenham sido acessados, se conseguira percorrer toda a tabela.
A implementação de uma estrutura de dados que suporte o comando
GET-NEXT pode ser complicada devido a esta operação poder pular o próximo objeto
simples (na ordem lexicográfica) devido à existência de objetos vazios. Como conseqüência, não se pode usar simplesmente a ordem lexicográfica presente na árvore para determinar quais objetos satisfazem a um comando GET-NEXT, devendo também existir um programa que examine os objetos, ignore aqueles objetos que estejam vazios e descubra o primeiro objeto simples pertencente a um objeto não vazio.
Como exemplo, a tabela ipAddrTable usa o endereço IP do objeto para identificar uma entrada particular na tabela. Se um cliente não souber este endereço IP, não poderá completar o identificador para a realização do pedido, a menos que utilize o prefixo iso.org.dod.internet.mgmt.mib.ip.ipAddrTable.ipAddrEntry.ipAdEntNetMask
(forma numérica 1.3.6.1.2.1.4.20.1.3) com a operação GET-NEXT, fazendo o servidor retornar a máscara da primeira entrada da tabela, junto com o nome do próximo objeto desta tabela. O cliente então, usa este nome no próximo pedido enviado ao servidor. O quadro 2 mostra as operações do protocolo SNMP.
Segundo STALLINGS, W. (1996), para o suporte das funções GET, SET e
GET-NEXT sobre tabelas, ao contrário do que acontece com objetos simples mapeados
em memória, é necessário um software adicional para mapear a tabela numa estrutura interna de dados. No caso das tabelas MIB, o servidor SNMP deve providenciar algum mecanismo que permita a cada tabela ter três funções para implementar as operações
QUADRO 1: Operações do protocolo SNMP.
GET, SET e GET-NEXT. Para o servidor descobrir qual função deve ser
usada, o software que implementa o servidor deve usar a tabela para escolher a função correta, através do uso de um ponteiro para uma tabela que conterá ponteiros para cada uma das operações.
As entradas em uma tabela apontam para outras tabelas que não contém o identificador completo do objeto, mas somente o prefixo deste identificador, porque o identificador completo do objeto para um item da tabela é formado pelo prefixo que identifica a tabela, mais um sufixo que identifica uma entrada particular na tabela em que o objeto está armazenado.
Uma vez determinado o prefixo correspondente ao objeto, é formado o nome
Operação e descrição De Mensagem enviada Para Mensagem retornada GET recupera o valor de informações
de gerenciamento. Gerente get-request Agente
Get-response (v1) ou
response (v2) GETNEXT recupera o valor de
informações de gerenciamento existentes após um determinado identificador.
Gerente get-next-request Agente get-response (v1) ou response (v2) GETBULK estende a funcionalidade
da operação GETNEXT.
Gerente get-bulk-request(v2) Agente response(v2) SET modifica o valor de informações
de gerenciamento. Gerente set-request Agente
get-response(v1) ou response (v2) TRAP informa um evento ocorrido no
sistema gerenciado. Agente
trap(v1) ou
snmpV2-trap(v2) Gerente não ocorre
INFORM fornece uma informação de gerenciamento não-solicitada.
22
do objeto, a função de acesso correspondente à operação pedida é invocada. No caso das tabelas, a função de acesso obtém o sufixo do identificador do objeto, e o usa para selecionar uma das entradas da tabela. Para a maioria das tabelas, é usado o endereço
IP para selecionar uma entrada. O endereço IP é codificado no identificador do objeto
usando-se a representação decimal com pontos.
O quadro 3 relaciona os documentos que definem a estrutura do modelo
SNMP nas versões 1 e 2. A próxima geração do protocolo (versão 3) está sendo
definida pelo SNMPv3 Working Group do IETF.
QUADRO 2: Documentos que definem a estrutura do modelo SNMPv1 e v2.
Escopo Descrição Publicação RFC
Protocolo de Gerenciamento SNMPv1 Protocol SNMPv2 Protocol Operations SNMPv2 Transport Mappings Maio 1990 Janeiro 1996 Janeiro 1996 1157 1905 1906 Estrutura de Informações de Gerenciamento
SMIv1 with types fixed SMIv1 Concise MIB format SMIv1 Traps formats SMIv2
SMIv2 Textual Conventions SMIv2 Conformances Maio 1990 Março 1991 Março 1991 Janeiro 1996 Janeiro 1996 Janeiro 1996 1155 1212 1215 1902 1903 1904 Núcleo de Informações de
Gerenciamento MIB II SNMPv2 Core Março 1991 Janeiro 1996 1213 1907
Segundo HARNEDY, S. (1998), para o desenvolvimento de aplicações de gerenciamento, o modelo SNMP poderá ser visto como composto por dois tipos de aplicações denominadas Aplicação Gerente e Aplicação Agente, as quais se comunicam via interconexão e protocolos de rede, conforme apresentado na Figura 4.
FIGURA4: Tipos de aplicações de gerenciamento e forma de comunicação. (Fonte: HARNEDY, S. 1998)
No modelo SNMP, a interconexão de rede consiste da coleção de uma ou mais redes que usam protocolos comuns e são conectadas por gateways. Qualquer dois pontos finais podem se comunicar através da implementação de um esquema de endereçamento global e do uso de protocolos padronizados como os que formam a pilha TCP/IP (Transmission Control Protocol/Internet Protocol). Nos protocolos existem regras, as quais permitem que a comunicação entre redes seja possível.
A comunicação de redes que utilizam a pilha TCP/IP é realizada por diferentes protocolos, os quais operam ao longo das camadas que formam a arquitetura. Um host, por exemplo, deverá possuir, a implementação de ao menos um protocolo em cada uma das camadas (camada de acesso à rede, camada de rede, camada de transporte e camada de aplicação).
4.3. Aplicação Gerente
Segundo MEIRELLES, L. F. T. (1999), o modelo SNMP apresenta a aplicação gerente como uma entidade de rede que usa determinados protocolos das camadas de transporte, de rede, de acesso à rede e de aplicação, para a comunicação com a entidade de rede gerenciada.
24
Conforme apresentado na figura 5, a aplicação gerente poderá ser constituída de cinco componentes principais:
• Operações de gerenciamento
• Management Information Base – MIB • Banco de Dados
• Aplicações de gerenciamento • Interface de usuário
FIGURA5: Componentes de uma Aplicação Gerente. (Fonte: MEIRELLES, L. F. T. 1999)
4.4. O Agente
Segundo MEIRELLES, L. F. T. (1999), todo sistema diretamente gerenciado por SNMP deverá conter uma entidade chamada Agente, processando em modo
background. O Agente é um tipo de programa que recebe requisições da Aplicação
Gerente, pertencente a uma determinada comunidade de gerenciamento, verifica se as requisições são válidas e envia as respostas apropriadas. O Agente pode também ser configurado para enviar mensagens de trap na forma de relatórios assíncronos para
eventos pré-definidos. O Agente utiliza rotinas de instrumentação que manipulam estruturas de dados locais para recuperar e configurar os vários objetos (variáveis) da
MIB.
Um Agente necessita de um mecanismo de transporte baseado em datagramas para a troca de mensagens com entidades do tipo Gerente. Quando se utiliza o mesmo mecanismo e/ou rede para operações de gerenciamento e outras operações de um sistema, o gerenciamento é chamado de in-band. O caminho utilizado para a troca de mensagens é chamado de “canal de gerenciamento in-band”. Utilizando um mecanismo e/ou rede separadas, somente para operações de gerenciamento, o gerenciamento é chamado de out-of-band. Neste caso, o caminho utilizado para a troca de mensagens de gerenciamento é chamado de “canal de gerenciamento out-of-band”.
Um Agente poderá suportar um ou mais protocolos de transporte. O User
Datagrama Protocol - UDP é o protocolo da pilha TCP/IP escolhido.
O protocolo de transporte UDP foi selecionado, por aumentar a possibilidade de ser um protocolo compatível e por possibilitar a interoperação entre qualquer Gerente e Agente.
Um Agente SNMP deverá ser habilitado a acessar informações de gerenciamento em um subsistema, para que este seja gerenciado. Um Agente (via rotinas e métodos) deverá ser capaz de acessar informações de gerenciamento do sistema e ser habilitado para receber notificações de eventos que ocorreram no sistema. Cada subsistema gerenciado deverá incluir um mecanismo de acesso para instrumentação de gerenciamento para o Agente contido no subsistema.
Segundo PERKINS, D. M. E. (1997) existem diferentes abordagens que poderão ser utilizadas na construção de um Agente. Contudo, em todas as abordagens, um Agente poderá consistir das seguintes áreas funcionais:
• Acesso para uma ou mais pilhas de transporte.
• Uma máquina de protocolo (que inclui mecanismos de segurança). • Uma tabela de mapeamento para rotinas e métodos.
26
4.4.1. Diagrama de um Agente
Diferentes abordagens podem ser usadas para decompor as áreas funcionais de um Agente. Algumas abordagens podem dimensioná-lo na forma de um pacote com a adição de outros componentes, tais como: rotinas, métodos e mecanismos de instrumentação.
Com base no diagrama apresentado, nota-se que o Agente contém: uma
engine de protocolo (incluindo aspectos de segurança), uma dispatch table, acesso
para uma interface de transporte, acesso para métodos e rotinas (incluindo registration e deregistration) e uma interface local para acessar informações de gerenciamento via Agente.
Nas implementações atuais, as áreas funcionais de um Agente e as adições para atendimento dos requisitos necessários ao gerenciamento baseado no modelo
SNMP são claramente separadas. Os fatores que afetam a escolha são os seguintes: o
responsável por adicionar gerenciamento; o total de software no sistema; o uso de um simples processador ou de múltiplos processadores no sistema e configuração do sistema de forma estática ou dinâmica.
Os dois primeiros fatores relacionam-se ao modo como o software para o gerenciamento do sistema é desenvolvido. Em um sistema pequeno, dedicado e fechado, uma única pessoa ou grupo poderá ser responsável por adicionar capacidade de gerenciamento SNMP. Em grandes projetos (incluindo a segunda ou terceira geração de um pequeno Agente), em sistemas multiprocessados e sistemas configurados dinamicamente, as rotinas e métodos tendem a ser implementados separadamente. Isso simplifica o desenvolvimento de um Agente, permitindo sua modificação independente do subsistema gerenciado e possibilitando que novas informações de gerenciamento sejam adicionadas em um subsistema já existente ou novo, sem a necessidade de alterar o Agente. O Agente pode ser representado como um conjunto de 6 funções conforme é mostrado na figura 6.
FIGURA6: Funções desempenhadas por um Agente SNMP. (Fonte: MEIRELLES, L. F. T. 1999)
Se as informações de gerenciamento estão contidas em um banco de dados, então as MIBs projetadas e a implementação dos Agentes poderão ser consideradas uma tarefa fácil. Entretanto, o sistema gerenciado poderá sofrer sobrecarga pelo consumo de mais recursos de memória e de processamento. Todas as informações que possuem troca de valores, tais como counters e gauges, poderão causar atualizações do banco de dados.
5. BASE DE INFORMAÇÕES DE GERENCIAMENTO (MIB)
Segundo STALLINGS, W. (1996), todo sistema complexo necessita armazenar as informações manipuladas em algum tipo de base de dados. A Base de Informação Gerencial (MIB – Management Information Base) é o nome conceitual para a informação de gerenciamento, incluindo os objetos gerenciados e seus atributos. Pode-se considerar as informações para a configuração do sistema como também pertencentes a MIB.
A SMI (Structure and Identification of Management Information) descreve o cenário no qual a Base de Informação Gerencial pode ser definida. A SMI, baseada na abordagem orientada a objetos, introduz os conceitos de hierarquia, herança, nomeação e registros usados na caracterização e identificação de objetos gerenciados. Além disso, ela define o conjunto de operações que pode ser realizado sobre os objetos gerenciados da MIB e o comportamento desses objetos mediante a execução destas operações.
Dentro deste contexto, a MIB é definida como um conjunto de objetos gerenciados dentro de um Sistema Aberto, na qual um objeto gerenciado é a visão abstrata de um recurso real dentro deste sistema.
5.1. MIB da Internet (TCP/IP)
Segundo STALLINGS, W. (1996), a MIB da Internet define os objetos que podem ser gerenciados por cada camada do protocolo TCP/IP. Estes objetos estão sob a guarda de um agente de gerenciamento e a comunicação entre este agente e um gerente, localizado na estação de gerenciamento, é feita utilizando o protocolo SNMP.
A MIB e o protocolo SNMP utilizam o padrão ASN.1 do OSI para a definição dos objetos e dos Protocol Data Units (PDUs). Inicialmente, esta escolha foi feita para permitir uma compatibilidade com o protocolo CMIP do modelo OSI, mas este objetivo não existe mais.
Como todos os padrões da tecnologia TCP/IP, as definições usadas no gerenciamento SNMP foram publicadas na série RFC (Requests For Comments). As definições originais do protocolo SNMP, bem como dos objetos gerenciados foram publicados em 1989. Em 1990, foi feita uma revisão da MIB, que passou a se chamar de MIB-II. Em 1993, foi publicado um conjunto de padrões novos, chamado SNMPv2, com alterações ao protocolo e extensões às definições dos objetos.
A MIB divide os objetos em vários grupos. O quadro 4 mostra os grupos definidos na MIB-I.
QUADRO 3: Número de objetos nos grupos.
Grupo Objetos para Número
System Informações básicas do sistema 3
Interfaces Interfaces de rede 22
at Tradução de endereço 3
ip Software de protocolo IP 33
Icmp Proto. De estatísticas 26
tcp Software de protocolo TCP 17
udp Software de protocolo UDP 4
egp Software de protocolo EGP 6
A lista de objetos gerenciáveis foi derivada daqueles elementos considerados essenciais. Esta modo de implementação onde se pegam somente os objetos essenciais não é restrita, uma vez que a SMI proporciona mecanismos de extensão como uma nova definição de uma MIB e uma definição de um objeto privado ou que não seja padrão.
5.2. A MIB no modelo OSI
Existem três tipos de hierarquias de gerenciamento usadas pelos Sistemas de Gerenciamento OSI: Herança, Nomeação e Registro.
30
5.2.1. Hierarquia de Herança
A hierarquia de herança, também denominada de hierarquia de classe, está relacionada às propriedades associadas aos objetos, descritas através de seus atributos, comportamento, pacotes condicionais, operações e notificações. Dentro desta hierarquia, define-se então, o conceito de classes de objeto hierarquizadas às quais pertencem objetos com propriedades similares. Existem, então, superclasses às quais estão subordinadas subclasses. Uma subclasse herda todas propriedades de sua superclasse, de maneira irrestrita, independentemente da necessidade ou não destas propriedades. A estas subclasses podem ser aglutinadas propriedades adicionais.
5.2.2. Hierarquia de Nomeação
A hierarquia de nomeação, também chamada de hierarquia de containment, descreve as relações entre instâncias de objetos com seus respectivos nomes.
5.2.2.1. Hierarquia de Registro
A hierarquia de registro, por sua vez, é usada para identificar de maneira universal os objetos, independentemente das hierarquias de heranças e nomeação. Esta hierarquia é especificada segundo as regras estabelecidas pela notação ASN.1 para árvore de registros usada na atribuição de identificadores a objetos. Cada nó desta árvore está associado a uma autoridade de registro (por exemplo, ISO - International
Organization for Standardization e CCITT - Consultative Commitee for International Telegraph and Telephone) que determina como são atribuídos os seus números. Desta
maneira, cada objeto é identificado por uma seqüência de números, cada um correspondente a um nó.
5.3. Componentes Básicos de Uma MIB
Como vimos, a MIB descreve as informações que podem ser obtidas ou modificadas via um protocolo de gerenciamento e essas informações habilitam um
equipamento a ser gerenciável.
Segundo PERKINS, D. T. (1993), o termo MIB possui diferentes significados baseado em seu contexto. Geralmente, uma MIB descreve informações que podem ser obtidas e/ou modificadas via um protocolo de gerência de redes. Esta informação permite que equipamentos de uma rede serem gerenciáveis.
Equipamentos gerenciáveis são aqueles que podem ser monitorados e controlados e são capazes de reportar eventos.
O modelo OSI inclui as seguintes operações:
• Get recupera a informação especificada • Set muda o valor da informação especificada
• Action realiza um comando imperativo, como reinicializar uma interface.
• Create cria uma nova instância do objeto gerenciado • Delete remove a instância especificada de um objeto
• Event-report sinaliza para o gerente que um evento de importância ocorreu
Já no modelo da Internet, cujo protocola é o SNMP inclui as seguintes operações:
• Get mesma função que o Get do OSI • Get-next usada para percorrer uma tabela • Set mesma função que o Set do OSI
• Trap mesma função que o event-report do OSI
As funções action, create e delete do modelo OSI não possuem mapeamento em SNMP, contudo a funcionalidade destas operações pode ser implementada em
SNMP através das funções set e get com a apropriada construção dos módulos MIB.
O modelo OSI e SNMP são muito diferentes, no início tentou-se fazer uma
MIB que servisse aos dois modelos, mas o tempo mostrou que é praticamente
32
Abaixo será descrito as principais partes e características de uma MIB, que serão utilizadas na construção do MIB-BROWSER.
5.3.1. A Estrutura de Gerenciamento da Informação – SMI
Os objetos na MIB são definidos usando Abstract Syntax Notation One (ASN.1) utilizando uma estrutura de gerenciamento da informação definida para isso.
Segundo PERKINS, D. T. (1993), O SMI define como a informação é estruturada e nomeada, os tipos permitidos, as operações permitidas, os tipos de dados e a sintaxe para a especificação da MIB, para as suas estruturas. Muito semelhante a um esquema de banco de dados.
Objetos gerenciáveis são uma abstração dos recursos dos sistemas que irão ser gerenciados. Alguns objetos possuem somente uma instância enquanto outros possuem várias instâncias, e objetos que são semelhantes são organizados em tabelas nas MIBs SNMP.
A SMI no OSI é semelhante a um modelo orientado a objetos enquanto no
SNMP é mais semelhante a um modelo de dados relacional. 5.3.2. Identificadores de Objetos (OIDs)
Em SNMP os objetos gerenciáveis ou nós de árvore são nomeados de tal forma que sejam únicos, através de OIDs, que são identificadores de objetos, eles recebem um nome que os identificada dentro das MIBs.
Este OID é uma seqüência de números inteiros positivos que podem ser associados a nomes textuais para facilitar o seu uso. A figura 7 mostra a árvore da
FIGURA 7: A árvore MIB II. (Fonte: OTSUKA, J. L. 1995)
O IETF estabelece os seguintes assinalamentos administrativos:
• internet nodo raiz para o domínio administrativo controlado pelo
IETF;
• mgmt nodo para os módulos da MIB padronizados pelo IETF; • mib área primária para definições de informações de
gerenciamento;
• experimental área para itens experimentais definidos junto ao IETF; • private nodo para delegação de subnodos de enterprises;
• enterprises nodo para delegação de subnodos de outras organizações; • snmpv2 área para itens que estão relacionados com Agentes
SNMPv2.
Cada nodo na árvore consiste de um identificador de objeto (OID – Object
Identifier), que é uma seqüência de números separados por pontos e/ou uma pequena
descrição textual. Abaixo vemos a sintaxe de um OID especificada pela SMI. “{“ { { <name>[“(“<number>”)”} | <number>}... “}”
ou
34
Onde:
• <name>: é o nome do componente, ou objeto; • <number>: é o valor do componente.
Um nó rotulado pode ter sub-árvores contendo outros nós rotulados. Caso não tenha sub-árvore, ou nós folhas, ele conterá um valor e será uma variável instanciada. Observando a figura 8, poderemos concluir que o identificador numérico para o objeto sysDescr, que faz parte do grupo system, é: 1.3.6.1.2.1.1.1, enquanto seu nome simbólico é a concatenação de todos os nodos que estão acima dele, ou seja:
iso.org.dod.internet.mgmt.mib.system.sysDescr
FIGURA 8: Posição do objeto sysDescr na árvore de dados da MIB. CCITT (0) ISO (1) JOINT-ISO-CCITT (2) ORG (3) DOD (6) INTERNET (1) MGMT (2) MIB-II (1) SYSTEM (1) sysDescr (1) Object sysDescr Identificador: 1.3.6.1.2.1.1.1
5.3.3. Módulos MIB
A MIB em SNMP é definida como um conjunto de definições de módulos que podem estar contidos em um ou mais documentos.
Segundo PERKINS, D. T. (1993), os módulos que compreendem uma determinada MIB são formalmente especificados em Request For Comments (RFCs), obedecendo-se às regras estabelecidas pelo IETF, no que tange ao Modelo SNMP. Um Dispositivo/Recurso poderá suportar módulos de MIB definidos por grupos de trabalho do IETF, como também, módulos exclusivos, definidos pelo próprio fabricante do equipamento ou software. A quantidade e origem dos módulos da MIB de um determinado Dispositivo/Recurso dependerá dos requisitos e funcionalidades de gerenciamento desejadas.
Diversas MIB, proprietárias ou padrões como a MIB-II juntas formam módulos MIB. Geralmente quando se criam novas MIBs, o código de outras MIBs é inserido dentro da nova MIB através de cláusulas IMPORT obedecendo às regras de sintaxe definidas no SMI.
5.3.4. Mecânica da Especificação de Módulos
Antes de se criar novas MIBs deve-se saber onde ela irá ficar na árvore da
MIB. Depois de possuir o seu OID, respeitando a sua posição na árvore, se for privada
deverá ficar embaixo do galho “enterprises”, em outros casos pode-se criar suas MIBs embaixo do galho “experimental”, para depois de testadas e aprovadas serem movidas para o galho “standard”.
5.3.5. Itens Object Identifier
São pontos de registro de alto nível na árvore, grupo ou valores para itens que possuem a sintaxe para o identificador do objeto. Também servem como títulos nas árvores como o grupo “system”. Novos itens devem ser criados seguindo a sintaxe definida pelo ASN.1. Abaixo é mostrado sua sintaxe:
36
<oidItem> = <oidName> “OBJECT” “IDENTIFIER” “::=” “{” <parent> <number> “}” Onde:
• <oidName> é o nome do item OID sendo definido; • <parent> é o nome item diretamente superior na árvore; • <number> é o valor do último componente sendo definido. Exemplo:
Egp OBJECT IDENTIFIER ::= { mib-2 8 }
5.3.6. Definições dos Objetos Gerenciados
Para se escrever MIBs, a macro “OBJECT-TYPE” especificada no ASN.1 pode definir três tipos de objetos, table, row e leaf. O nome destes itens deve começar com letra minúscula seguindo um número arbitrário de letras, números e hífens.
• Objeto Table
Uma tabela consiste de linhas, e em SNMP tabelas não são recuperáveis, somente as linhas independentemente são. A sua sintaxe precisa ser “SEQUENCE OF
<sequence>”.
• Objeto Row
Uma linha consiste de colunas, e somente os objetos colunares das linhas são recuperáveis. Usando get ou getnext pode-se recuperar todas as colunas de uma linha. O nome da linha é tirado da tabela associada somente substituindo o sufixo “Table” com “Entry”.
• Sequence Definitions
Uma seqüência é usada para especificar colunas em uma linha. Para a maioria das tabelas e linhas os itens de seqüência são filhos do objeto linha.
• Objeto Leaf
É o menor grupo de informação dentro da MIB. É onde está à informação, são as variáveis SNMP.
Abaixo é mostrado a sintaxe simples para a declaração desses objetos: <objectItem> = <objectName> "OBJECT-TYPE"
"SYNTAX" <syntax> "ACCESS" <access> "STATUS" <status> [ "DESCRIPTION" <description> ] [ "REFERENCE" <reference> ] [ "INDEX" "{" <indexItems> "}" ] [ "DEFVAL" "{" <defaultValue> "}" ] "::=" "{" <parent> <number> "}"
<objectName> = <tableName> | <rowName> | <leafName> <syntax> = { "SEQUENCE" "OF" <SequenceName> } |
<SequenceName> | <leafSyntax> Onde:
<objectName> e o nome do item sendo definido;
<parent> e o nome do item que diretamente o contém na arvore de OIDs; <number> e o valor do último componente sendo definido;
Outros campos de importância na sintaxe mostrada acima entre outros: • SYNTAX
O campo SYNTAX determina o tipo de objeto gerenciável. Pode ser dentre outros, INTEGER, OCTET STRING, Network address, IpAddress etc.
• ACCESS
São os tipos de acesso ao objeto, podem ser “read-only”, “read-write”, “write-only” e “not-acessible” em SMI.
• STATUS
Podem ser “mandatory”, “optional”, “obsolete” e “deprecated”. • DESCRIPTION
38
necessária para a sua implementação. Utilizada por desenvolvedores. • REFERENCE
É um texto que referência outro documento que descreve o mesmo objeto. • INDEX
Precisa estar inclusa somente em objetos de linha, eles listam as colunas de uma linha que são usadas como especificadores de instância.
• DEFVAL
Esta cláusula é somente usada em objetos folha que são colunas em tabelas que não são usadas como itens de instância.
5.3.6.1. Considerações sobre Instâncias de Objetos Gerenciados
Segundo PERKINS, D. T. (1993), uma variável SNMP é uma entidade objeto e o valor de sua instância é representado como um OID. Objetos que não estão em uma tabela são considerados quando instância como um simples componente de valor zero. Para objetos em tabelas, a definição do objeto row precisa indicar com a cláusula INDEX a coluna e a ordem em qual eles precisam ser usados para especificar os valores das instâncias para os itens nas linhas. Para realmente consultar valores nos agentes é preciso utilizar instancias.
Exemplo:
Uma instancia de um objeto simples:
sysDescr.0 ou 1.3.6.1.2.1.1.1.0: para o gerente consultar o valor de sysDescr ele deve incluir no campo apropriado da mensagem Get o valor 1.3.6.1.2.1.1.1.0.
Uma instancia de um objeto de tabela:
ifSpeed.1 ou 1.3.6.1.2.1.2.2.1.5.1: onde o último valor significa que é da interface 1, onde podem ocorrer diversas interfaces.
5.3.6.2. Instruções para definição de Objetos
Para definir quais objetos irão compor um MIB deve-se seguir as regras abaixo:
