Seção: Tutoriais Infraestrutura

Hoje, o complexo mundo de rede de computadores composto por roteadores, switches e servidores torna a tarefa de gerenciamento um tanto difícil. Não é necessário apenas que tudo esteja funcionando, é importante também o desempenho dos componentes da rede. É nesse patamar que o SNMP entra. Ele nasceu para atender a necessidade crescente de um padrão para gerenciamento de redes. Esse protocolo oferece aos administradores um conjunto de operações simples que permitem o monitoramento remoto de diversos dispositivos em uma rede.

Nesta seção será estudado o protocolo SNMP, para entender seu significado, analisar brevemente as três versões, conhecer os RFCs, entender o papel do gerente e agente e por fim, ver suas vantagens e desvantagens.

Definição

O SNMP (Simple Network Management Protocol) é um protocolo desenvolvido para gerenciar dispositivos em uma rede. Ele permite que os administradores gerenciem o desempenho da rede, encontrem e solucionem problemas, além de planejar o crescimento. Está especificado no RFC 1157 e utiliza o protocolo UDP para envio de mensagens. Este protocolo é o centro do desenvolvimento do gerenciamento SNMP.

O conjunto de padrões SNMP [27] é formado por:

• Um conjunto de especificações de estrutura e identificação para as informações gerenciais. Este padrão é chamado SMI (Structure of Management Information). Estas especificações são encontradas no RFC 1155 [24].
• Um protocolo de comunicação entre o gerente e o agente, chamado simplesmente de SNMP (Simple Network Management Protocol). A especificação deste protocolo e apresentada no RFC 1157 [24].
• Uma base de informações gerenciais que especifica quais variáveis são mantidas pelos elementos de rede. Esta base de informações é denominada MIB (Management Information Base), e a sua segunda versão, MIB-II, está especificada pelo RFC 1213 [24].

Este conjunto de padrões pode ser utilizado para outros tipos de aplicações, além daquelas convencionais de gerência. Uma utilização possível é o uso do SNMP para fazer o balanceamento de carga em ambientes distribuídos [33].

Gerenciamento de Redes e Monitoramento

O núcleo do protocolo SNMP é um conjunto de operações simples que permite os administradores mudar o estado de algum dispositivo que suporte o SNMP. Por exemplo, ele pode ser usado para desligar a interface de um roteador ou verificar a velocidade com que uma interface Ethernet está trabalhando. O SNMP pode inclusive controlar a temperatura de um switch e advertir quando esta estiver muito alta.

O SNMP é normalmente associado a gerenciamento de roteadores, mas é importante entender que ele pode ser usado para gerenciar muitos tipos de dispositivos. Enquanto o Simple Gateway Management Protocol (SGMP) foi desenvolvido para gerenciar roteadores, o SNMP foi desenvolvido para gerenciar sistemas Unix, Windows, impressoras, modems, fontes de alimentação e muito mais. Isso inclui não apenas dispositivos físicos, mas também software, como servidores web e banco de dados.

Outro aspecto do gerenciamento de rede é o monitoramento da rede. O RMON foi desenvolvido para ajudar a entender como a rede está funcionando, bem como a forma que os dispositivos da rede estão afetando-a como um todo. Ele pode ser usado para acompanhar não apenas o tráfego LAN, WAN, mas interfaces também. O RMON será visto em maiores detalhes adiante.

RFCs e Versões SNMP

O IETF é responsável pela definição de padrões de protocolos que governam o trafego de Internet. O IETF é responsável pelos RFCs que são especificações para muitos protocolos que existem no mundo IP. Os RFCs são numerados sequencialmente, na ordem cronológica em que são escritos. Quando um padrão é revisto, as alterações são escritas com um novo número.

RFC é uma abreviação para Request for Comments. Estes documentos definem o conjunto de protocolos TCP/IP. Para que um protocolo vire um padrão na Internet, antes é necessário que seja documentando em um RFC.

A tabela 4 [16] contém as RFCs relacionadas ao gerenciamento de redes no TCP/IP.

Tabela 4: RFCs relacionadas ao gerenciamento de redes no TCP/IP

O protocolo SNMP foi ao longo do tempo sendo modificado e com isso foram criadas três principais versões:

• SNMP Versão 1 (SNMPv1) foi a primeira versão padrão do protocolo SNMP. É definida na RFC 1157. A segurança dessa versão baseia-se em communities, que nada mais são do que senhas: strings de texto simples que permitem que qualquer aplicativo baseado em SNMP que conheça os strings obtenha acesso à informação gerenciada de dispositivo. Há tipicamente três communities SNMPv1: somente leitura, leitura e escrita, e trap.
• SNMP Versão 2 (SNMPv2): Melhorias no aspecto de segurança. É uma versão experimental, mas alguns fabricantes oferecem suporte, tabela 5 [16].

Tabela 5: RFCs relacionadas ao SNMPv2

• SNMP Versão 3 (SNMPv3): Versão atual padrão, mas ainda pouco utilizada. Com suporte a autenticação e comunicação privada entre as entidades gerenciadas, tabela 6 [16].

Tabela 6: RFCs relacionadas ao SNMPv3

Formato das Mensagens SNMP

As informações são trocadas entre a estação gerenciadora e o agente na forma de mensagens SNMP. Em cada mensagem está incluso o número da versão, o nome de comunidade e um dos cinco tipos de PDU do protocolo como mostrado na figura 4 [17].

Figura 4: Mensagem SNMP com seus campos e componentes

A tabela 7 [27] explica o significado de cada campo do cabeçalho de mensagens.

Tabela 7: Formato das mensagens utilizadas no SNMP

UDP

O User Datagram Protocol (UDP) é usado como protocolo de transporte na comunicação de dados entre os gerentes e agentes no SNMP. A RFC 768 define o UDP e ele foi escolhido porque nenhuma conexão ponto-a-ponto é feita entre agente e gerente quando os pacotes são enviados e recebidos. Esse aspecto do UDP o deixa menos confiável, por não haver confirmação de pacotes perdidos. Cabe ao SNMP determinar se os pacotes foram perdidos e serão retransmitidos, se necessários. O gerente envia um pedido para um agente e espera uma resposta. O intervalo de tempo que o gerente espera depende de como ele foi configurado. Se ocorre um timeout e o gerente não recebe a resposta do agente, ele assume que o pacote foi perdido e retransmite a solicitação. O número de vezes que o gerente retransmite pacotes é também configurável.

A vantagem é que o UDP requer uma carga baixa e não causa impacto na rede. Em uma rede com muito tráfego de dados, o SNMP por meio do TCP seria uma má ideia.

O SNMP usa a porta UDP 161 para envio e recebimento de solicitações, e a porta UDP 162 para receber traps dos dispositivos gerenciados. Essas portas podem ser alteradas em alguns dispositivos.

A figura 5 [21] mostra como ocorre a comunicação entre o agente e o gerente (NMS).

Figura 5: Modelo de comunicação TCP/IP e SNMP

Quando um gerente ou agente deseja realizar uma função SNMP (como um pedido ou trap), ocorrem os seguintes eventos na pilha de protocolos:

• Aplicação: Em primeiro lugar, a aplicação SNMP (agente ou gerente) determina o que vai fazer.
• UDP: Essa camada permite que dois hosts se comuniquem. O cabeçalho do UDP contém, entre outras coisas, a porta de destino do dispositivo para o qual ela está enviando o pedido ou um trap.
• IP: Tenta entregar o pacote de SNMP ao destino pretendido, conforme especificado pelo seu endereço IP.
• Medium Access Control (MAC): O evento final que acontece para o pacote SNMP chegar a seu destino é ser entregue a rede física, onde ele possa ser encaminhado para o destino final.

Agentes e Gerentes

No mundo SNMP existem dois tipos de entidades: gerentes e agentes. Um gerente é um servidor que executa algum tipo de software de gerenciamento de rede. Os gerentes são frequentemente denominados Network Management Stations (NMS). Um NMS é responsável pelo polling e recebimento de traps de agentes na rede. O polling, no contexto de gerência de rede, é o ato de consultar um agente (roteador, switch, servidor Unix, etc.) por alguma informação. Esta informação pode ser posteriormente usada para determinar se algum tipo de evento catastrófico ocorreu. O trap é uma forma do agente dizer ao NMS que alguma coisa aconteceu. Os traps são enviados de forma assíncrona, não em resposta às consultas do NMS. O NMS é mais responsável por executar uma ação baseado nas informações que recebe do agente.

A segunda entidade, o agente, é um pedaço de software que é executado nos dispositivos de rede que você está gerenciando.

Hoje, as maiorias dos dispositivos IP vêm com algum tipo de agente SNMP embutido. O fato de que os fabricantes estão dispostos a implementar agentes em muitos de seus produtos faz com que o trabalho do administrador de rede ou gerente de rede seja de maneira mais fácil. O agente fornece gerenciamento informações para o NMS, mantendo o controle de vários aspectos operacionais do dispositivo. Por exemplo, o agente em um roteador é capaz de acompanhar o estado de cada uma das suas interfaces: quais estão em funcionamento, quais não, etc. O NMS pode consultar o status de cada interface em um roteador e tomar as medidas adequadas ação se algum deles estiver fora do ar.

A figura 6 [21] mostra a relação entre o NMS e um agente.

Figura 6: Relação entre o NMS e o Agente

É importante saber que os pollings e os traps podem ocorrer ao mesmo tempo. Não há restrições sobre quando o NMS pode consultar o agente ou quando o agente pode enviar um trap.

SMI e MIB

A Structure of Management Information (SMI) fornece uma maneira de definir objetos gerenciados e seus comportamentos. Um agente tem em posse uma lista de objetos controlados por ele. Um desses objetos é o status operacional de uma interface de roteador. Essa lista define as informações que a NMS pode usar para determinar o funcionamento geral do dispositivo no qual o agente reside.

A SMI tem duas versões: a Structure of Management Information Version 1 (SMIv1) (RFC 1155) que define precisamente como objetos gerenciados são nomeados e especifica seus tipos de dados associados e a Structure of Management Information Version 2 (SMIv2) (RFC 2578) que prevê melhorias para o SNMPv2.

A definição de objetos gerenciados pode ser dividida em três atributos:

• Nome: O nome ou identificador de objeto (OID) define um único objeto gerenciado. Os nomes aparecem geralmente em duas formas: número ou “legível”. Em ambos os casos, os nomes são extensos e inconvenientes.
• Tipo e Sintaxe: Um objeto gerenciado é definido usando um subconjunto do Abstract Syntax Notation One (ASN.1). A ASN.1 é uma forma de especificar a forma como os dados são representados e transmitidos entre agentes e gerentes, no âmbito do SNMP. O lado bom do ASN.1 é que a notação é independente da máquina.
• Codificação: Uma única instância de um objeto gerenciado é codificada em uma string de octetos usando o Basic Encoding Rules (BER). O BER define como os objetos são codificados e decodificados para que eles possam ser transmitidos através de um meio de transporte, tais como a Ethernet.

Nomeando OIDs

Os objetos gerenciados são organizados em uma hierarquia em árvore. Esta estrutura é a base do esquema de nomeação SNMP. O ID de objeto é composto de uma série de inteiros baseada em nós de uma árvore, separadas por pontos (.). Embora haja uma forma, mas amigável que é legível para um administrador, esta forma nada mais é que uma série de nomes separados por pontos, cada qual representa um nó da árvore. Assim, pode ser usado a sequência de nomes ou a sequência de números. A figura 7 [21] mostra alguns níveis principais da árvore.

Figura 7: Árvore de objeto SMI

Na árvore de objetos, o nó no topo da árvore é chamado de raiz, qualquer coisa que tiver filhos é chamada de sub-árvore e o que não tiver nada é chamado de folha.

Por exemplo, analisando a figura 7:

• Root-Node – nó raiz e a sub-árvore composta por ccitt(0), iso(1), joint(2);
• iso(1) – único nó que contém uma sub-árvore;
• ccitt(0), joint(2), directory(1), mgmt(2), experimental(3), private(4) – são folhas.

Na tabela 8 [21], examinando a definição da sub-árvore internet e quatro sub-árvores:

Tabela 8: Definição da sub-árvore internet

A primeira linha declara internet como a OID 1.3.6.1 que é definida como uma sub-árvore de iso.org.dod ou 1.3.6 (::= é um operador de definição). As quatro últimas declarações são semelhantes, mas que definem os outros ramos que pertencem a internet. Para o ramo directory, a notação { internet 1 } diz que ela faz parte do ramo internet e que sua OID é 1.3.6.1.1. A OID para mgmt é 1.3.6.1.2, e assim por diante.

A Internet Assigned Numbers Authority (IANA) atualmente gerencia todas as atribuições de números de empresas privadas para instituições, organizações, empresas, etc.

Definindo OIDs

A sintaxe de atributo fornece as definições dos objetos gerenciados através de um subconjunto do ASN.1. A SMIv1 define vários tipos de dados que são fundamentais para o gerenciamento de redes e os dispositivos destas. É importante saber que estes tipos de dados são simplesmente uma maneira de definir que tipo de informação um objeto gerenciado pode conter. A tabela 9 [21] lista os tipos de dados suportados pelo SMIv1.

Tabela 9: Tipo de Dados SMIv1

O objetivo de todos esses tipos de objetos é definir os objetos gerenciados. Como já dito antes, a MIB é um agrupamento lógico de objetos gerenciados que diz respeito a uma tarefa de gerência específica. A MIB pode ser pensada como uma especificação que define os objetos gerenciados de um fabricante ou de dispositivos suportados. A Cisco, por exemplo, tem centenas de MIBs definidas para sua vasta linha de produtos.

MIB

O Management Information Base (MIB) pode ser pensado como um banco de dados de objetos gerenciados que o agente vasculha. Qualquer tipo de estatística ou dados que podem ser acessados pelo NMS é definido em uma MIB. O SMI fornece uma maneira de definir objetos gerenciados, enquanto a MIB é a definição (utilizando a sintaxe SMI) dos próprios objetos.

Um agente pode implementar muitas MIBs, mas todos os agentes implementam uma MIB particular chamada MIB-II (RFC 1213). Esse padrão define as variáveis para coisas como estatísticas de interfaces assim como várias coisas relacionadas ao próprio sistema. O objetivo principal da MIB-II é fornecer informações gerais do TCP/IP para gerência.

Durante os anos 90, muitas MIBs foram criadas para permitir a gerência de vários elementos. Um exemplo dessas MIBs e seus respectivos RFCs são listadas abaixo:

• ATM MIB (RFC 2515);
• Frame Relay DTE Interface Type MIB (RFC 2115);
• BGP version 4 MIB (RFC 1657);
• RDBMS MIB (RFC 1697);
• RADIUS Authentication Server MIB (RFC 2619);
• Mail Monitoring MIB (RFC 2249);
• Uninterruptible Power Supply MIB (RFC 1628).

RMON

Os dispositivos de monitoramento de rede, muitas vezes chamados de monitores ou probes, são instrumentos que existem com o propósito de gerenciar e/ou monitorar uma rede. Muitas vezes esses probes remotos são dispositivos stand-alone e são dedicadas a monitorar um único dispositivo em uma rede. Uma empresa pode utilizar vários dispositivos desse tipo para gerir sua rede. Além disso, esses dispositivos podem também serem usados para gerenciar uma rede remota.

O Remote Monitoring (RMON) é uma especificação padrão de monitoramento que permite que vários monitores de rede e sistemas de gerenciamento troquem informações de monitoramento na rede. O RMON fornece aos administradores de rede mais liberdade na seleção de probes de monitoramento de rede com características que melhor atendem suas necessidades.

O RMON foi desenvolvido originalmente para resolver o problema de gerenciamento dos nós de uma LAN e nós remotos a partir de uma central local. A especificação RMON (RFC 1757), que é uma extensão da MIB SNMP, é uma especificação padrão de monitoramento. Ele é usado para planejar uma rede, melhorar o desempenho e auxiliar no diagnóstico de falhas.

Visão geral

Existem duas versões do RMON: RMON1 (RMONv1) e RMON2 (RMONv2). A primeira versão define dez MIBs para monitoramento básico de rede, que hoje podem ser encontradas em hardwares mais modernos. A segunda versão é uma extensão do RMON que foca nas camadas mais altas de tráfego acima da camada de rede. O RMONv2 permite que os aplicativos de gerenciamento monitorem os pacotes em todas as camadas da rede.

As soluções RMON são compostas de dois componentes: um probe ou agente e um cliente, normalmente uma estação de gerenciamento. Os agentes armazenam informações da rede dentro de suas MIBs. Os agentes só conseguem ver o tráfego que flui através deles, então é necessário colocar um em cada nó da rede a ser monitorada. As estações de gerenciamento se comunicam com o agente usando o SNMP para obter e correlacionar os dados.

O RMON deve observar alguns objetivos gerenciais, eles serão vistos a seguir [35].

Operação offline

Às vezes existirão condições em que uma estação de gerenciamento não estará em contato constante com dispositivos de gerenciamento remotos. Esta situação pode acontecer como consequência de projeto, em uma tentativa de reduzir custos de comunicação, ou por falha da rede que afetam a comunicação entre a estação de gerenciamento e o monitor.

Por esse motivo, o RMON permite que um monitor seja configurado para realizar diagnósticos e coletar estatísticas continuamente, mesmo quando a comunicação entre estação e monitor esteja disponível. O monitor pode então tentar notificar a estação de gerenciamento quando uma condição excepcional ocorrer.

Monitoramento Proativo

Levando em conta os recursos disponíveis no monitor, é potencialmente útil para ele executar continuamente diagnósticos e guardar dados de performance da rede. O monitor está sempre disponível no aparecimento de qualquer falha. Ele pode notificar a estação de gerenciamento da falha e pode armazenar informações estatísticas sobre esta falha. Essa informação poderá ser vista depois pela estação de gerenciamento para diagnosticar as possíveis causas do problema.

Detecção e Notificação de Problemas

O monitor pode ser configurado para reconhecer condições, erros mais comuns, e checa-los continuamente. Quando uma dessas condições ocorrer, o evento pode ser registrado e as estações de gerenciamento podem ser notificadas em várias maneiras.

Valor agregado aos dados

Um dispositivo de monitoramento remoto representa um dedicado recurso de rede exclusivamente a funções de gerenciamento e os mesmos estão localizados nas partes monitoradas da rede, os dispositivos de monitoramento remoto de rede têm a oportunidade de agregar valor significativo aos dados que recolhe. Por exemplo, ao destacar os hosts de rede que geram mais tráfego ou erros, o monitor pode dar a estação de gerenciamento informações precisas para resolver vários problemas.

Gerenciamento múltiplo

Uma organização pode ter múltiplas estações de gerenciamento para diferentes unidades da organização, para diferentes funções e/ou como tentativa de proporcionar recuperação em caso de desastre. Na prática, esses ambientes são comuns, então um dispositivo de gerenciamento remoto deve ser capaz de lidar com várias estações de gerenciamento utilizando seus recursos simultaneamente.

Um exemplo disso é o PPT Metro São Paulo, que gerencia o tráfego das outras capitais. O PTT Metro é o nome dado ao projeto do Comitê Gestor da Internet no Brasil (CGI.br) que promove e cria a infraestrutura necessária (Ponto de Troca de Tráfego - PTT) para a interconexão direta entre as redes ("Autonomous Systems" - ASs) que compõem a Internet Brasileira. A atuação do PTT Metro volta-se às regiões metropolitanas no país que apresentam grande interesse de troca de tráfego Internet.

Um PTT Metro é, assim, uma interligação em área metropolitana de pontos de interconexão de redes (PIXes), comerciais e acadêmicos, sob uma gerência centralizada.

Na figura 8 é mostrado um gráfico que representa o tráfego agregado de todos os PTTs que estão em operação atualmente.

Figura 8: Tráfego agregado de todos os PTTs em operação

MIB-II

MIB-II é um grupo de gerenciamento muito importante, porque todo dispositivo com suporte a SNMP deve também suportar MIB-II (RFC 1213). A raiz da MIB-II é iso.org.dod.internet.mgmt.mib-2 e seus filhos podem ser vistos na figura 9 [21].

Figura 9: Sub-árvore MIB-II

A tabela 10 [21] descreve brevemente cada um dos grupos de gerenciamento definidos na MIB-II.

Tabela 10: Breve descrição de grupos da MIB-II

Operações do SNMP

Protocol Data Unit (PDU) é o formato de mensagem que os gerentes e agentes utilizam para enviar e receber informações. Existe um formato PDU padrão para cada uma das seguintes operações do SNMP [21]:

• get;
• get-next;
• get-bulk;
• set;
• get-response;
• trap;
• notification;
• inform;
• report.

Operação get

A operação get é iniciada pelo NMS, que envia um pedido ao agente. Este recebe a solicitação e a executa. Alguns dispositivos que possam estar sobrecarregados, como roteadores, talvez não estejam aptos a responder ao pedido e o ignora. Se o agente obtiver com sucesso a informação pedida, ele envia uma resposta de volta ao NMS, onde é processado. Esse comando serve para trazer apenas um objeto da MIB por vez.

Operação get-next

A operação get-next permite emitir uma sequência de comandos para recuperar um conjunto de valores de uma MIB. Em outras palavras, para cada objeto que deseja recuperar, um pedido separado de get-next e get-response é gerado. O comando get-next atravessa a sub-árvore de maneira lexigráfica. Uma vez que um OID é uma sequência de inteiros, é fácil para um agente iniciar na raiz da sua árvore de objetos e trabalhar até encontrar o OID que está procurando. Quando o NMS recebe uma resposta do agente ao comando get-next emitido, ele mandará outro comando get-next e irá continuar repetindo até que o agente retorne um erro, significando a MIB chegou ao fim e não há mais objetos a serem pesquisados.

Operação get-bulk

O SNMPv2 define a operação get-bulk que permite um aplicativo de gerenciamento recuperar uma grande parte de uma tabela de uma vez. Os tamanhos das mensagens são limitados pela capacidade do agente. Se ele não retornar todos os dados, retorna uma mensagem de erro sem os dados.

Operação set

O comando set é usado para alterar o valor de um objeto gerenciado ou criar uma nova linha em uma tabela. Os objetos que são definidos em uma MIB como read-write ou write-only podem ser alterados ou criados usando esse comando. É possível um NMS definir mais de um objeto por vez.

Vantagens do SNMP

Uma das maiores vantagens do SNMP é que ele é popular. Muitos dispositivos existentes no mercado oferecem suporte a esse protocolo.

O SNMP é mundialmente usado por ser simples e não sobrecarregar a rede. Para um administrador de redes com certo conhecimento, ele também é fácil de ser implementado. Outra vantagem é que a rede pode ser expandida, porque esse protocolo se adequada as novas necessidades.

Desvantagens do SNMP

O SNMP não é um protocolo perfeito, ele também possui falhas, mas por sua natureza ser flexível, muitas delas podem ser contornadas. Uma das falhas é a questão de segurança, os dados transitados pela rede são fáceis de serem capturados por invasores. De posse desses dados, estes invasores podem até desligar dispositivos. A versão 3 desse protocolo adicionou mecanismos para melhorar a segurança.

Outra falha é em relação a sua eficiência, muitos dados desnecessários trafegam pela rede, a árvore da MIB não é muito organizada, tornando-a ineficiente e se houver problemas de roteamento na rede, algum dispositivo não poderá ser monitorado ou reconfigurado.