Do que se trata o artigo:

O SNMP (Simple Network Management Protocol) é um padrão de gerência para redes IP criado pelo IETF (Internet Engineering Task Force) em 1988. Ele opera segundo o modelo gerente-agente, no qual uma estação de gerência é responsável por controlar e monitorar recursos de diversos elementos da rede gerenciada por meio da interação com agentes implantados nos elementos desta rede. As informações gerenciais de cada um destes elementos são armazenadas em MIBs (Management Information Base), que são implantadas juntamente com os agentes nos elementos gerenciados.


Em que situação o tema é útil:

As redes IP têm sido utilizadas como plataforma para diversos serviços que envolvem a transmissão de dados, vídeo e voz. Desta forma, estas redes têm crescido em complexidade e importância, fazendo com que seja fundamental gerenciá-las com eficácia para garantir tranquilidade aos usuários e organizações. O SNMP é um dos principais pilares deste cenário, pois ele é amplamente adotado pelos fabricantes de equipamentos e definido pelo IETF como o padrão para gerência de redes IP.

Resumo DevMan:

Para que as redes IP proporcionem a confiabilidade desejada pelos seus usuários, os administradores de rede devem implementar práticas eficazes de gerência. No caso das redes IP, o padrão para gerência é o SNMP. A primeira versão do SNMP foi lançada em 1988 e rapidamente adotada por grande parte dos fabricantes de equipamentos de rede. A segunda versão e a terceira versão foram lançadas em 1993 e em 1998, respectivamente, solucionando problemas de desempenho e segurança que ficaram evidentes na primeira versão, quando ela passou a ser usada em ambientes de rede mais complexos. Atualmente, o SNMP ainda é amplamente utilizado na gerência de redes IP e a perspectiva para o futuro é que este cenário permaneça, mesmo que a utilização do SNMP seja complementada pela adoção de outros padrões como o IPFIX.

As redes IP e seus serviços formam ambientes heterogêneos e complexos, nos quais conjuntos de software e hardware de diferentes fabricantes interagem constantemente para atender os usuários com rapidez e precisão. Atualmente, as redes IP são capazes de suportar diversos serviços simultâneos como acesso à Internet, telefonia, transmissão de vídeo, transmissão de TV, telemedicina, etc. e se tornaram essenciais para seus usuários. Problemas decorrentes de falhas ou paradas nestas redes representam perdas enormes. A solução para diminuir os riscos de perdas decorrentes de falhas nas redes é a adoção de práticas eficientes de gerência de redes, que incluem o monitoramento, a avaliação, a configuração e o controle de elementos de software e hardware. Dentro desta solução, o desafio passa a ser encontrar ferramentas que permitam a gerência de tantos elementos heterogêneos, com funções, propriedades e fabricantes diferentes. No caso do gerenciamento de redes IP, a resposta para este desafio é o SNMP (Simple Network Management Protocol).

O SNMP é um padrão de gerência de redes definido pelo IETF (Internet Engineering Task Force) que inclui um protocolo para comunicação entre estações de gerência e dispositivos gerenciados e especificações relacionadas à modelagem, à disponibilização e ao armazenamento de informações sobre os dispositivos gerenciados. O SNMP foi introduzido pelo IETF em 1988 por meio do RFC 1067 e sua principal característica era a simplicidade. Inicialmente, o SNMP foi tratado como uma solução provisória que seria substituída em longo prazo pelo CMIP (Common Management Information Protocol), que era mais complexo e sofisticado. Justamente por esta razão, tanto o SNMP quanto o CMIP são baseados no mesmo modelo gerente-agente. Entretanto, a indústria passou a adotar o SNMP massivamente, justamente por sua simplicidade. Desta forma, em poucos anos, grande parte dos equipamentos de rede passaram a dar suporte ao SNMP, que passou a ser, de maneira concreta, um padrão de gerência. Ainda hoje, mais de duas décadas depois de sua criação, o SNMP continua sendo o padrão de gerência mais utilizado nas redes IP.

Aspectos básicos do SNMP

O padrão SNMP é baseado no modelo gerente-agente, ilustrado na Figura 1. Primeiramente, temos a estação de gerência com um NMS (Network Management System) implantado. O NMS é responsável por reunir os dados coletados sobre a rede monitorada e apresentar ao administrador de rede. Para que o administrador compreenda melhor o que está ocorrendo com a rede, é desejável que o NMS seja capaz de gerar relatórios e gráficos sobre os dados coletados na rede. Por meio do NMS, o administrador também pode enviar comandos de forma a configurar parâmetros de funcionamento da rede. Por fim, o NMS repassa ao administrador de rede alarmes que o notificam sobre a ocorrência de eventos importantes como interrupções, falhas, falta de energia elétrica, etc. Uma única estação de gerência pode ser utilizada para monitorar vários elementos na rede. Em resumo, o NMS e a estação de gerência são a interface de controle entre o administrador e a rede que está sendo monitorada.

Do outro lado da arquitetura, temos agentes que são implantados nos dispositivos gerenciados. Cada agente é responsável por coletar os dados sobre o elemento gerenciado e armazená-los em uma base de dados local, conhecida como MIB (Management Information Base). Quando a estação de gerência requisita um determinado dado sobre o elemento gerenciado, o agente coleta este dado no respectivo objeto e responde ao gerente enviando o dado requisitado. O agente também é responsável por receber e processar requisições de alteração de dados da MIB enviadas pela estação de gerência e por enviar notificações sobre eventos importantes para o gerente. Na MIB, são armazenadas informações como a quantidade de pacotes IP que ingressaram e partiram do equipamento, a quantidade de bytes que ingressaram e partiram das interfaces do equipamento, a quantidade de conexões TCP que estão ativas, quantos pacotes foram descartados, o nome do equipamento, a localização física do equipamento, etc.

Figura 1. Visão geral da arquitetura gerente-agente.

As MIBs são organizadas de maneira hierárquica, segundo especificação documentada no RFC 1155 – Structure of Management Information. Os criadores do SNMP padronizaram a estruturação das informações de gerência na MIB para garantir que haveria interoperabilidade entre equipamentos de diferentes fabricantes. A Figura 2 ilustra esta organização. No topo da organização hierárquica temos um nó raiz. Logo abaixo dele, temos três divisões principais: ccitt, iso e joint. Todos os nós posicionados hierarquicamente abaixo do nó ccitt (0) são administrados pela International Telegraph and Telephone Consultative Committee (CCITT). Os nós posicionados abaixo do nó iso (1) são administrados pela International Organization for Standardization (ISO). Por fim, os nós posicionados abaixo do nó joint (2) são administrados conjuntamente pela CCITT e pela ISO. Logo abaixo do nó iso (1), a ISO reservou um nó a ser usado por outras organizações internacionais: o nó org (3). Abaixo do nó org (3), foi reservado um nó para o departamento de defesa dos Estados Unidos: o nó dod (6). O departamento de defesa, por sua vez, designou um nó para o Internet Activities Board (IAB), que foi nomeado de internet (1). Abaixo deste nó, temos quatro nós. Os principais são o mgmt (2), sob o qual são alocadas as informações aprovadas em documentos do IAB e o private (4), sob o qual podem ser incluídas informações definidas por fabricantes e desenvolvedores de equipamentos de rede. As informações incluídas abaixo do nó mgmt (2) devem estar presentes nas MIBs de todos os equipamentos que seguem o padrão SNMP.

O último nível hierárquico da MIB traz os nós que realmente contêm dados sobre os equipamentos que estão sendo gerenciados. O termo apropriado para designar o nó que contém um dado sobre o equipamento gerenciado é objeto de gerência. O objeto ipInReceives, por exemplo, é responsável por registrar quantos pacotes IP ingressaram nas interfaces do equipamento monitorado até o momento. Há objetos para os mais diversos atributos, que cobrem desde medidas de desempenho como a quantidade de bytes e pacotes que ingressaram no equipamento até dados descritivos como identificação e localização do equipamento. Para acessar um determinado objeto, seja para consultar ou para modificar seu conteúdo, o gerente deve informar ao agente toda a cadeia hierárquica de nós que leva ao objeto em questão. Desta forma, se o gerente deseja conhecer o valor atual do objeto ipInReceives, ele deve requisitar esta informação passando o identificador do objeto: 1.3.6.1.2.1.4.3. Cada número do identificador corresponde ao número de um nó que deve ser percorrido pelo agente na hierarquia da MIB para chegar ao objeto ipInReceives.

Figura 2. Estrutura hierárquica das MIBs.

Para atender a questão da interação entre os gerentes e os agentes, o SNMP especifica um protocolo que opera na camada de aplicação da arquitetura TCP/IP. O protocolo utilizado na camada de transporte é o UDP, uma vez que este protocolo, ao contrário do TCP, dispensa o estabelecimento de conexão lógica entre os dois pontos finais de comunicação, proporcionando maior agilidade no transporte dos dados. A porta normalmente utilizada pelo SNMP é a 161. O SNMP disponibiliza três operações básicas de interação entre agente e gerente, conforme é apresentado na Figura 3. A operação get permite que o gerente requisite um determinado dado disponível na MIB do agente. A operação set é utilizada para que o gerente requisite que um novo valor seja atribuído a um determinado objeto presente na MIB do elemento gerenciado. Por fim, a operação trap permite que o agente notifique o gerente sobre a ocorrência de algum evento importante no elemento monitorado.

Figura 3. Operações básicas do SNMP.

SNMP v1

A primeira versão do padrão SNMP foi especificada em 1988 e ainda é amplamente utilizada. Sua principal característica é a simplicidade, que é a razão pela qual esta versão é tão popular. Os seguintes documentos especificam a primeira versão do SNMP:

· RFC 1155, que define como devem ser especificados os objetos contidos na MIB;

· RFC 1213, que define a MIB padrão para gerenciamento de redes IP, denominada MIB-II. Este documento especifica quais objetos de gerência devem estar presentes em uma MIB de um equipamento TCP/IP;

· RFC 1157, que define o protocolo utilizado para comunicação entre os gerentes e os agentes.

O SNMPv1 segue estritamente a arquitetura gerente-agente, na qual um único gerente é responsável por gerenciar todos os elementos da rede. O SNMPv1 permite as seguintes operações de interação entre o gerente e o agente:

· GetRequest: este comando é utilizado pelo gerente para requisitar o valor de um determinado objeto ao agente;

· GetNextRequest: este comando é uma variação do GetRequest, utilizada para percorrer a hierarquia da MIB;

· SetRequest: este comando permite que o gerente atribua um novo valor para um determinado objeto. O objeto sysLocation, por exemplo, é utilizado para que seja cadastrada a localização do equipamento gerenciado. Caso o equipamento seja mudado de lugar, o gerente pode enviar um comando SetRequest para o agente pedindo que a nova localização seja atribuída ao objeto sysLocation;

· GetResponse: é a resposta dada pelo agente para os comandos GetRequest, GetNextRequest e SetRequest enviados pelo gerente;

· Trap: é uma notificação enviada pelo agente para o gerente que informa a ocorrência de algum evento não esperado como uma falha em um enlace ou um reboot do equipamento.

Na primeira versão do SNMP, os objetos da MIB podem assumir os seguintes tipos:

· NetworkAddress: tipo utilizado para objetos que vão receber endereços IPv4;

· Counter: representa um número inteiro não negativo que pode ser incrementado, mas não pode ser decrementado. O objeto ifInOctets, que registra a quantidade de bytes que ingressaram em uma determinada interface, é do tipo Counter;

· Gauge: representa um número inteiro não negativo que pode ser incrementado ou decrementado. O objeto tcpCurrEstab, que registra a quantidade de conexões TCP ativas no momento, é do tipo Gauge;

· Timeticks: representa um inteiro não negativo que conta o tempo em centésimos de segundo a partir de um determinado momento. O objeto sysUpTime, que registra o tempo percorrido desde quando o equipamento foi ligado pela última vez, é do tipo Timeticks;

· Opaque: permite a atribuição de formatos binários específicos a um determinado objeto.

É importante fazer mais uma observação com relação a objetos do tipo Counter. Iniciantes em SNMP frequentemente apresentam dificuldade em tratar estes objetos para obter séries temporais, as quais são bastante importantes quando queremos acompanhar indicadores de desempenho. Ao medir o tráfego em bytes de uma determinada interface para construir a série temporal, por exemplo, o administrador pode desenvolver uma rotina que busque o valor do objeto ifInOctets de 10 em 10 segundos. O problema é que, muitas vezes, a rotina é programada para coletar o valor presente no objeto e assumir que ele representa o tráfego nos últimos 10 segundos, o que não é correto. Um objeto do tipo Counter é incrementado continuamente com os novos valores que são medidos. Se às 10:50:15 o ifInOctets retornou um valor igual a 1.200.560 bytes e às 10:50:25, em uma nova coleta, o ifInOctets retornou um valor igual a 1.300.000 bytes, isso quer dizer que 99.440 bytes ingressaram na interface no intervalo de 10 segundos. O gerente pode então registrar que, neste momento, o tráfego de ingresso da interface era de 9.944 bytes/s.

Uma das principais críticas realizadas ao SNMPv1 tem relação com a segurança. Para que um gerente possa acessar os dados de um agente, basta que ele conheça um atributo do agente denominado comunidade. O Windows 7, por exemplo, tem um agente SNMP implantado. Por meio deste agente, é possível que um gerente monitore diversos objetos do equipamento no qual o Windows 7 está instalado. A Figura 4 mostra a tela na qual é possível configurar a segurança do agente SNMP no Windows 7. Podemos observar que há comunidades cadastradas com os respectivos direitos de acesso de cada uma delas. O gerente que fizer uma requisição ao agente utilizando a comunidade1, por exemplo, poderá apenas ler valores dos objetos do agente. Em resumo, para que um gerente envie uma requisição a um agente SNMP, ele precisa conhecer apenas o endereço IP do elemento monitorado, a porta que está sendo utilizada pelo serviço e o nome da comunidade. A solução para este problema de segurança está implantada no SNMPv3, que será apresentado mais adiante neste artigo.

Figura 4. Tela de configuração de segurança de agente SNMPv1 no Windows 7.

SNMP v2

A primeira versão do SNMP foi proposta no final da década de 80 como uma solução provisória que seria substituída posteriormente pelo CMIP. Entretanto, a transição entre o SNMP e o CMIP não seria simples, pois as especificações da SMI e da MIB não eram compatíveis com a estrutura complexa de objetos que havia sido projetada para o CMIP.

Quando o SNMP passou a ser utilizado em larga escala, alguns problemas começaram a ser detectados. O primeiro problema estava relacionado à segurança. Não era possível autenticar a estação que tinha enviado a requisição ao agente. O conceito de comunidade utilizado para prover segurança era bastante vulnerável. Como o tráfego SNMP não era cifrado, um atacante poderia interceptar os pacotes que trafegavam sem qualquer proteção e descobrir o nome da comunidade. De posse deste nome de comunidade, o atacante poderia passar a acessar o agente SNMP legitimamente. Consequentemente, muitos fabricantes não implementaram a operação set em seus equipamentos. Outro problema do SNMPv1 tinha relação com o desempenho. A busca por dados realizada por meio da operação GetRequest era ineficiente em situações nas quais o gerente necessitava de vários dados de uma única vez, já que era necessário enviar uma requisição para cada dado que se desejava buscar. Tendo em vista estes problemas e o fato de que o SNMP tinha deixado de ser um protocolo provisório para se tornar um padrão amplamente adotado por toda a indústria, os pesquisadores passaram a trabalhar em uma nova versão do SNMP, que foi lançada no início de 1993. Em 1996, o IETF determinou uma revisão no SNMPv2. As soluções de segurança especificadas em 1993 não haviam sido bem recebidas pela indústria e acabaram sendo eliminadas do SNMPv2 nesta revisão. A Tabela 1 traz a lista de RFCs que compõem o SNMPv2 após a revisão de 1996.

Número do RFC

Título

1901

Introduction to Community-Based SNMPv2

1902

Structure of Management Information (SMI) for SNMPv2

1903

Textual Conventions for SNMPv2

1904

Conformance Statements for SNMPv2

1905

Protocol Operations for SNMPv2

1906

Transport Mappings for SNMPv2

1907

Management Information Base for SNMPv2

1908

Coexistence Between Version 1 and Version 2 of the Internet-Standard Network Management Framework

Tabela 1. RFCs do padrão SNMPv2.

Três mudanças principais foram, então, consolidadas no SNMPv2. A primeira delas é a comunicação entre gerentes. Foi criada uma nova operação denominada InformRequest, que permite que um gerente notifique outro gerente sobre eventos inesperados ou importantes que ocorreram em sua rede. A segunda principal mudança é a criação da operação GetBulkRequest, que permite que o gerente requisite um grande volume de dados ao agente sem ter de enviar várias requisições. A terceira mudança tem relação com a SMI. Na SMIv1, o tipo Counter era limitado a 32 bits, causando dificuldades principalmente quando ele era usado em objetos que monitoravam interfaces com tráfego intenso. Na SMIv2, foi introduzido um tipo Counter de 64 bits.

SNMP v3

Após a revisão do SNMPv2 realizada em 1996, as discussões com relação à segurança do protocolo continuaram. No início de 1998, então, o IETF publicou os RFCs 2271, 2272, 2273, 2274 e 2275, que definem o SNMPv3. O principal destaque da versão 3 do SNMP é a introdução de uma infraestrutura completa de segurança. Além disso, na versão 3, o SNMP foi formalizado como uma arquitetura modular, que teve como objetivo facilitar a implementação do SNMP. Ao definir uma arquitetura modular para o SNMP, os pesquisadores permitiram que ele fosse implementado parcialmente pelos fabricantes, respeitando aqueles que desejam uma solução mais simples sem deixar de atender aqueles que necessitam de uma solução mais complexa.

A infraestrutura de segurança do SNMPv3 é composta por dois elementos: o USM (User-Based Security Model) e o VACM (View-Based Access Control Model).

O USM provê as seguintes funcionalidades:

· Cifragem dos dados: o algoritmo DES é utilizado para cifrar os dados que são transmitidos por meio do SNMP, garantindo que um agente mal intencionado, mesmo que intercepte os dados, não consiga interpretá-los;

· Integridade da mensagem: o USM permite que o destinatário de uma mensagem SNMP verifique se ela foi modificada no seu trajeto;

· Autenticação: o USM permite verificar se um indivíduo mal intencionado está fingindo ser um agente legítimo para enviar mensagens SNMP. Não há mais o conceito de comunidade como havia no SNMPv1. O usuário que pretende acessar um agente SNMP passa a ser identificado por um nome de usuário e senha.

O VACM, por sua vez, permite que seja controlado o acesso aos recursos gerenciados. Por meio do VACM, podem ser criados grupos que têm diferentes permissões de acesso aos objetos da MIB. Além disso, podem ser estabelecidos diferentes níveis de segurança para diferentes grupos que pretendem acessar os recursos gerenciados. Entre os níveis de segurança disponíveis temos:

· No authentication and no privacy: neste nível de segurança, as mensagens SNMP não são cifradas e nem autenticadas;

· Authentication and no privacy: neste nível de segurança, as mensagens SNMP são autenticadas, mas não são cifradas;

· Authentication and privacy: este é o nível de segurança mais alto, no qual as mensagens SNMP são cifradas e autenticadas.

MIB-II

A MIB-II foi definida no RFC 1213 e é a MIB padrão para o gerenciamento de equipamentos TCP/IP. Esta MIB possui 171 objetos divididos em 10 grupos:

· system: agrupa objetos com informações gerais sobre o elemento que está sendo gerenciado;

· interfaces: agrupa objetos com informações sobre as interfaces do elemento que está sendo monitorado;

· at (address translation): agrupa objetos que trazem a tradução de endereços IP para endereços físicos

· ip: agrupa objetos que trazem informações relacionadas à operação do protocolo IP no elemento gerenciado;

· icmp: agrupa objetos que trazem informações relacionadas à operação do protocolo ICMP no elemento gerenciado;

· tcp: agrupa objetos que trazem informações relacionadas à operação do protocolo TCP no elemento gerenciado;

· udp: agrupa objetos que trazem informações relacionadas à operação do protocolo UDP no elemento gerenciado;

· egp: agrupa objetos que trazem informações relacionadas à operação do protocolo EGP no elemento gerenciado;

· dot3: agrupa objetos que trazem informações sobre os meios físicos de transmissão utilizados pelo elemento gerenciado;

· snmp: agrupa objetos que trazem informações relacionadas à operação do protocolo SNMP no elemento gerenciado.

Para evitar que o envio de requisições SNMP sobrecarregue a rede, o administrador de rede deve ser cauteloso quanto à quantidade de objetos SNMP que ele monitorará constantemente. Dentre os 171 objetos disponibilizados na MIB-II, é possível escolher objetos que sejam mais úteis no dia a dia do gerenciamento.

No grupo system, há objetos interessantes para apoiar a gerência de configuração da rede como o sysDescr, que armazena uma descrição do sistema monitorado, o sysLocation, que traz a localização do elemento, o sysContact, que traz o contato do responsável pelo elemento e o sysName, que armazena o nome do elemento de rede. Ainda no grupo system, há o objeto sysUpTime, que permite que o administrador de rede verifique há quanto tempo o sistema está operando sem interrupções. Ao monitorar este objeto continuamente, o administrador pode verificar qual é o tempo médio que o sistema opera sem interrupções. A diminuição neste tempo médio pode evidenciar defeitos no elemento monitorado, ajudando o administrador a tratar possíveis problemas de maneira preventiva.

No grupo interfaces também há diversos objetos úteis. O objeto ifOperStatus pode ser utilizado na detecção de falhas, pois permite que o administrador verifique se uma determinada interface está operando ou não. Há, também, diversos objetos que podem ser interessantes para monitorar o volume de tráfego de uma determinada interface. Entre estes objetos temos o ifInOctets, que mostra a quantidade de bytes recebidos pela interface, o ifOutOctets, que mostra a quantidade de bytes que foram enviados pela interface, o ifInDiscards, que mostra a quantidade de pacotes ingressantes que foram descartados e o ifOutDiscards, que mostra a quantidade de pacotes que foram descartados ao deixar a interface.

O grupo ip também traz uma série de objetos que podem ser utilizados para gerência do tráfego no equipamento. O objeto ipInReceives mostra quantos pacotes IP foram entregues à camada de rede. O objeto ipInDelivers mostra quantos pacotes IP foram processados com sucesso na camada de rede e entregues à camada de transporte. O objeto ipInDiscards, por outro lado, mostra a quantidade de pacotes que não puderam ser processados pela camada de rede e foram descartados. Ainda há objetos que trazem informações mais detalhadas, como o ipHdrErrors, que mostra a quantidade de pacotes descartados por problemas com o cabeçalho e o ipAddrErrors, que traz a quantidade de pacotes descartados por problemas com o endereço IP do pacote.

O grupo tcp, por sua vez, traz uma série de objetos com informações interessantes para a gerência do tráfego de pacotes TCP e das conexões TCP estabelecidas. Os objetos tcpInSegs e tcpOutSegs trazem a quantidade de segmentos TCP que ingressaram e deixaram o equipamento, respectivamente. Os objetos tcpAttemptFails, tcpEstabResets e tcpRetransSegs podem indicar a confiabilidade da rede. O tcpAttempFails traz a quantidade de tentativas de conexão que falharam. O tcpEstabResets informa o número de conexões estabelecidas que foram reiniciadas. O tcpRetransSegs informa a quantidade de segmentos TCP que foram retransmitidos. Há ainda os objetos que monitoram o número de conexões ativas e passivas: tcpActiveOpens e tcpPassiveOpens. Um crescimento elevado e rápido no número de conexões estabelecidas em um elemento que contém um servidor HTTP, por exemplo, pode indicar uma tentativa de ataque de negação de serviço. O grupo udp também reúne objetos que podem prover informações importantes para a gerência do tráfego no elemento monitorado. Os objetos udpInDatagrams e udpOutDatagrams retornam a quantidade de datagramas UDP que ingressaram e deixaram o equipamento, respectivamente.

Conclusão

As redes IP têm sido utilizadas para disponibilização de serviços diversificados e importantes para o cotidiano das pessoas e das organizações. Com isso, é fundamental que as redes IP sejam seguras, confiáveis e apresentem alta disponibilidade. Um dos caminhos para que estes requisitos sejam atendidos é a adoção do padrão de gerência para redes IP, conhecido como SNMP.

O SNMP foi lançado pelo IETF em 1988. Sua principal característica era a simplicidade, pois o objetivo do IETF era que ele fosse implementado com rapidez pelos fabricantes que sentiam falta de um padrão para gerenciar as redes IP. O SNMP foi criado como uma solução provisória, que seria substituída em longo prazo pelo CMIP, um padrão construído pela ISO que era bem mais sofisticado e complexo que o SNMP. Contudo, o SNMP, desde o seu lançamento, foi amplamente adotado pelos fabricantes, que depois não demonstraram desejo de trocá-lo por outro padrão mais complexo como o CMIP. Desde então, foram lançadas mais duas versões do SNMP: a versão 2 foi lançada em 1993 e a versão 3 foi lançada em 1998. Ambas buscaram solucionar questões de desempenho e segurança que não haviam sido bem tratadas na versão 1 e que passaram a merecer mais atenção assim que o SNMP passou a ser adotado em massa pelos fabricantes de equipamentos e softwares de rede. Mesmo com o lançamento das versões 2 e 3, a simplicidade presente na versão 1 nunca deixou de ser a principal característica do SNMP, que ainda hoje é o protocolo de gerência mais utilizado em redes IP. A expectativa para o futuro é que, mesmo que seja acompanhado por outros padrões como o IPFIX (IP Flow Information Export), o SNMP continue sendo um dos principais pilares da gerência de redes IP.

Links

IETF Request for Comments (RFCs)http://www.ietf.org/rfc.html.

Livro “SNMP, SNMPv2, SNMPv3 and RMON 1 and 2”, escrito por William StallingsEditora Addison Wesley, 3.ª edição, 1999.

Livro “Essential SNMP”, escrito por Douglas Mauro e Kevin SchmidtEditora O’Reilly, 2.ª edição, 2001.