INTRODUO AO PROTOCOLO SNMP

O protocolo SNMP - Simple Network Management Protocol (Protocolo Simples de Gerenciamento de

Redes) , foi desenvolvido para gerenciar ns, dispositivos e equipamentos dentro de uma rede TCP/IP. Projetado
inicialmente para aplicaes de gerncia de redes simples, o protocolo firmou-se no mercado e atualmente o
protocolo de gerncia mais utilizado em redes de comunicao de dados.
Conforme indica o prprio nome do protocolo, sua estrutura simples em todos os sentidos, o que facilita
muitos aspectos importantes da sua implementao. Na prtica, um protocolo de gerncia deve ser realizvel num
grau que permita aos produtos nele baseados um fcil desenvolvimento e alto nvel de interoperabilidade, de forma
transparente. Por outro lado, alm da despretenso, o protocolo foi projetado visando no interferir no desempenho
das redes gerenciadas, procurando reduzir o trfego de mensagens de gerncia necessrias.
SNMP um protocolo de gerncia baseado em poucas mensagens que so trocadas entre elementos
gerenciadores (gerentes) e gerenciados (agentes). Estes componentes utilizam a prpria estrutura da rede gerenciada
para comunicar-se. As poucas mensagens SNMP definidas procuram limitar as restries impostas s ferramentas de
gerenciamento, pois, medida em que se aumenta a complexidade do protocolo e as possibilidades de suas
mensagens, dificulta-se a criao das ferramentas de gerenciamento devido ao uso de operaes complicadas.
A flexibilidade oferecida por todas estas caractersticas possibilitam a existncia de um maior nmero de
funes de gerenciamento suportadas remotamente nos elementos de rede, tornando a arquitetura de gerncia SNMP
extensvel para acomodar funcionalidades adicionais, de forma independente da plataforma onde est sendo
executada.

1. Surgimento do Protocolo SNMP

Em resposta necessidade de um protocolo de gerncia para as redes baseadas em TCP/IP, o IAB (Internet
Architecture Board) realizou o primeiro esforo para uma padronizao de um protocolo simples de gerncia de
redes consolidado na RFC 1052 (Recommendations for the Development of Internet Network Managements
Standards) . Este documento descrevia as diretrizes recomendadas no projeto de protocolos de gerncia.
O passo seguinte foi a especificao do protocolo proposto, na forma de documentos RFCs candidatos a se
tornarem padro , e .
A partir da, a primeira verso do SNMP (SNMPv1) foi especificadas nos documentos apresentados na
Tabela 2-1.

Tabela 2 1 Documentos de Especificao do protocolo SNMPv1

RFC Ttulo Ano
RFC Structure and Identification of Management Information for TCP/IP-based 199
1155 Internets 0
RFC A Simple Network management Protocol 199
 1157 0
RFC Management Information Base for Network Management of TCP/IP-based 199
1213 Internets: MIB-II 1

Estes documentos alcanaram o status de Internet standard e foram o alicerce para a aceitao da
arquitetura SNMP. Neles esto as descries de como devem ser organizadas as informaes de gerenciamento
numa base de dados local ao elemento gerenciado e como o protocolo SNMP pode ser usado para colet-las e
alter-las, sendo, para tanto, definidas as mensagens a serem utilizadas e seus campos. A partir destes documentos,
houve um rpido desenvolvimento de bases de dados de gerncia (MIB Management Information Bases) para
vrios tipos de equipamentos e interfaces, alm de especificaes para adaptao do SNMP a protocolos de
transporte proprietrios j conhecidos.
Como ser visto adiante, vrios documentos foram apresentados durante o processo de amadurecimento do
protocolo, entre eles vrias revises e documentos secundrios objetivando esclarecer e firmar a arquitetura de
gerenciamento oferecida pelo protocolo.

2. Arquitetura SNMP
A arquitetura inicial SNMP deriva do SGMP (Simple Gateway Management Protocol) , protocolo
desenvolvido para gerenciar roteadores e equipamentos de interconexo de uma rede TCP/IP. A propsito, a
primeira verso do SNMP apresentava informaes para gerenciamento e controle desses dispositivos de
interconexo, o que determinou as escolhas dos elementos componentes da arquitetura SNMP.
Assim, em uma rede sendo gerenciada segundo a arquitetura SNMP, pode-se distinguir os seguintes
elementos especficos de gerncia de rede:

1. vrios equipamentos, dispositivos e softwares que contm cada um uma entidade de

processamento SNMP chamada de agente;
2. pelo menos uma estao gerenciadora (gerente) que contm a inteligncia e o domnio das
operaes de gerncia. Esta estao executa aplicaes de gerncia que monitoram e
controlam os elementos da rede, por meio de acesso remoto informao de
gerenciamento armazenada nesses elementos;
3. um protocolo especfico usado para transferir informaes de gerncia entre agentes e
gerentes.

Os agentes possuem um repositrio de informaes de gerncia que chamado MIB (Management

Information Base - Base de Informaes de Gerncia). de responsabilidade do agente manter na MIB um reflexo
da realidade operacional e administrativa do dispositivo sendo gerenciado. Desta forma, o gerente pode saber o que
est acontecendo por meio de pedidos de informaes da MIB do agente. A estratgia implcita do SNMP o
polling das informaes nos diversos agentes, ou seja, o gerente faz constantemente o pedido de informaes sobre o
elementos gerenciados.
 A organizao das informaes na MIB de um agente SNMP estruturada na forma de objetos gerenciados.
Estes objetos, que so unidades de armazenamento de dados representados na MIB por suas instncias nicas ou
mltiplas, compem a base de informaes de gerncia referente quele determinado elemento da rede.
A primeira especificao de MIB, chamada MIB-1 , continha grupos de dados para identificao dos
equipamentos, descrio de interfaces de rede dos mesmos e informaes operacionais dos protocolos TCP, UDP,
IP, ICMP e EGP. A evoluo da MIB-I foi chamada MIB-2 e permitia acesso a um conjunto de informaes mais
abrangente acerca dos dispositivos gerenciados.
Portanto, o modelo arquitetural SNMP centralizado e composto de estaes de gerncia e elementos de
rede, estes contendo (ou sendo representados) por agentes SNMP. O agente pode estar localizado nos prprios
elementos de rede, como roteadores e servidores; ou pode ser colocado em algum componente que monitora os
elementos de rede, a exemplo da situao onde um hub monitorado por um agente residente num servidor ligado a
este hub (Figura 2-1).
Vale observar que cabe estao gerente fazer a coleta de dados de cada elemento gerenciado por
intermdio do agente correspondente. O protocolo SNMP ento responsvel pelo transporte das informaes de
gerenciamento entre o gerente e os agentes existentes nos elementos de rede.
Os agentes, normalmente componentes de software, operam no elemento de rede gerenciado e funcionam
basicamente respondendo solicitaes (requests) de um gerente SNMP e enviando ou respostas a tais solicitaes
(responses), ou ainda notificaes espontneas (traps) sobre o estado do elemento.
 Figura 2 1 Exemplo de rede gerenciada segundo arquitetura SNMP
3. Estrutura da Informao de Gerncia (SMI Structure of
Management Information)
A estrutura da informao de gerncia a ser usada por agentes e gerentes SNMP foi padronizada de forma a
descrever os objetos que compem a informao de gerncia armazenada num agente SNMP .
A informao de gerncia vista como uma coleo de objetos gerenciveis, residentes num reservatrio
virtual de informaes, a j citada MIB (Management Information Base). Colees de objetos relacionados so
descritas em mdulos de MIB. Estes mdulos so escritos em uma verso simplicada de ASN.1 (Abstract Sintax
Notation version one), uma linguagem para definio de dados estabelecida como norma ISO . A maneira como os
dados so codificados em octetos para efeito de transmisso obedece a regras BER (Basic Encoding Rules), que
tambm constituem uma padronizao ISO . Tais regras descrevem, de modo nico, a forma como os dados devem
transitar na rede, qualquer que seja o dispositivo ou tecnologia utilizados.
Segundo ASN.1, cada objeto na MIB possue 3 atributos principais que o descrevem:

Nome do objeto (identificador): uma sequncia de nmeros inteiros separados por pontos,
onde cada nmero um indicador numa rvore hierrquica que serve para a classificao de
objetos de redes. Esta rvore , portanto, a estrutura de informao que contm todos os
 objetos existentes. Mais detalhes sobre o assunto sero vistos adiante na descrio de uma
MIB.

Sintaxe do objeto: o elemento que especifica o tipo de dados ASN.1, seu modo de acesso, seu
status e seu nome descritivo, com as seguintes caractersticas:

Tipo de dado ASN.1, pode ser:

Bsico: INTEGER, OCTET STRING, OBJECT IDENTIFIER e NULL
Application-wide: IpAddress, Network Address, Counter, Gauge, Opaque e Timeticks
Simply-constructed: list e table
Modo de acesso: read-only, read-write, write-only e not-acessible
Status: mandatory, optional e obsolete
Nome textual: nome em caracteres para tornar a identificao do objeto mais legvel

Codificao do objeto: formato de transmisso do objeto, segundo as regras BER, para todas as
operaes SNMP.

A SMI define algumas macro-instrues ASN.1 com a finalidade de garantir a consistncia da sintaxe e a
semntica das definies SNMP. A declarao de um objeto na MIB, por exemplo, feita pela macro
OBJECT-TYPE. O exemplo abaixo ilustra a utilizao da macro OBJECT-TYPE para declarao do objeto
sysUptime (objeto que representa o tempo desde a ltima reinicializao de um elemento gerenciado) do grupo
system (mdulo contendo um grupo de objetos para identificao de um elemento ou sistema gerenciado):

sysUptime OBJECT-TYPE
SYNTAX Time-Ticks
ACCESS read-only
STATUS mandatory
DESCRIPTION
The time (in hundredths of a second) since the
network management portion of the system was last
re-initialized.
::= { system 3 }

A sintaxe do objeto definida pelas informaes declaradas em cada uma das clusulas da macro, assim
especificadas:

Descritor: a cadeia de caracteres (string) descritiva contendo o nome textual do objeto.

Vale lembrar que o identificador do objeto a notao numrica separada por pontos que
 representa o objeto na rvore da MIB.
Sintaxe: a definio ASN.1 do tipo de dado deste objeto.
Acesso: o mnimo grau de acesso que deve ser implementado para este objeto. As opes
para este campo sero apresentadas brevemente na discusso de segurana.
Status: o estado de implementao atual do objeto. Esta situao pode mudar com a
evoluo da MIB. As opes so: mandatory (deve ser implementado), optional (pode ser
implementado), obsolete (no precisa mais ser implementado) e deprecated (a informao
apresentada por este objeto redundante, mas ele ainda obrigatrio).
Descrio: um texto explicativo do objeto que visa esclarecer o que ele representa e
como funciona. Deve estar entre aspas.

Um formato mais detalhado de declarao para os objetos da MIB apresentado na RFC 1212 (Concise
MIB Definitions) , formato este recomendado para todas as novas MIB da verso 1 do SNMP.

4. As MIBs SNMP
A coleo de objetos que constitui a MIB est organizada em grupos de objetos similares. Conforme j
citado, tais objetos so descritos por identificadores de forma a construir uma estrutura hierrquica em rvore, onde
cada n um nmero inteiro. Um objeto nesta estrutura referenciado por um identificador nico composto de uma
sequncia destes nmeros separados por pontos. A Figura 2-2 ilustra esta organizao, exemplificando a localizao
do objeto 1.3.6.1.2.1.1 do grupo system na rvore da MIB.

Figura 2 2 Exemplo de localizao de um objeto na rvore da MIB

Vale notar que uma instncia de um objeto na MIB descrita pela mesma sequncia que define o objeto
acrescida de um ltimo nmero. Este ter valor zero se o objeto possuir somente uma instncia ou um nmero maior
que zero se existir mais de uma instncia do objeto, sendo neste caso as instncias organizadas em tabelas. No
exemplo da Figura 2-2, o objeto sysDescr possui somente uma instncia, logo a referenciamos como 1.3.6.1.2.1.1.0 .
Uma certa manipulao de dados na forma de tabelas possvel em SNMPv1. Uma tabela pode ser definida
na MIB de um agente. O processo de criao e deleo de itens destas tabelas feito por meio de operaes
denominadas set. Problemas podem ocorrer quando vrios gerentes tentam criar ou eliminar itens numa mesma
tabela. Em funo disso, alm de um campo index para indexar individualmente os itens, necessrio um campo em
cada item chamado status que ser o responsvel em dizer qual o estado da linha (criada, deletada, apagada, etc...),
para evitar inconsistncias causadas pela manipulao dos dados por mais de um gerente.
A coleta de dados nestas tabelas no muito eficiente por que na verso 1 so enviados seguidamente,
atravs de mensagens denominadas getNextRequest, vrios pedidos ao agente com o intuito de obter tabelas inteiras
acessando cada item de maneira sequencial. Algumas discusses visando melhorar a eficincia do protocolo
propuseram outros algoritmos baseados na correlao dos valores coletados da sequncia de getNextRequest. A
verso 2 do protocolo (SNMPv2) viria a mudar esta estratgia com novidades nas mensagens do protocolo.
Por outro lado, como resultado da evoluo da MIB-I, a RFC 1213 (Management Information Base for
Network Management of TCP/IP-based Internets: MIB-II ) define os objetos para a MIB padro SNMP chamada de
MIB-II. Esta MIB, total ou parcialmente, implementada em produtos comerciais. Acrscimos podem ser feitos
adicionando novos mdulos da MIB (sejam novas padronizaes definidas em RFC dos grupos de trabalho do IETF
ou objetos proprietrios criados por um determinado fabricante). Estes novos objetos so concatenados nas suas
devidas posies na rvore, sem alterar de maneira nenhuma os objetos j existentes. Os objetos nunca so
redefinidos, mesmo se um objeto for declarado obsoleto pelo IETF, sua identificao na rvore permanece.
Cabe observar que um determinado agente pode ter um conjunto de objetos que na verdade uma parte do
universo da MIB descrito acima. O que deve ser realmente implementado num agente so as informaes
pertinentes ao seu funcionamento e estado.
Inmeras novas MIBs foram padronizadas para necessidades especficas e tecnologias emergentes. Assim,
uma MIB pode conter exatamente os objetos de interesse para um determinado equipamento ou componente da rede,
tornando os dados um reflexo da realidade gerencial.
Deve-se notar que a informao de gerenciamento possui suas prprias regras de definio, o que torna as
MIBs reservatrios de informao completamente desvinculados do protocolo de gerncia. No princpio da
definio do SNMP, pretendia-se facilitar a migrao da infra-estrutura de informaes de gerncia do protocolo
SNMP para um protocolo de gerncia OSI. O tempo mostrou que isto no iria acontecer, mas esta separao
facilitou a migrao da verso 1 para novas verses.

5. Protocolo SNMP v1
A funo do protocolo de gerncia permitir a troca de informaes entre as entidades que compem o
sistema de gerncia da rede, no caso, gerentes e agentes. O protocolo ainda delineia o mecanismo de segurana
usado pelo contexto administrativo. Na verso 1, somente os servios de autenticao e autorizao de acesso so
oferecidos, como ser visto adiante.
O protocolo SNMP possui poucas mensagens. Estas so operaes bsicas a serem executadas pelos
gerentes e agentes, incluindo pedidos de informao, respostas a estes pedidos e notificaes espontneas de eventos
nos dispositivos gerenciados.
O protocolo de transporte sugerido para transferncia das mensagens SNMP o UDP (User Datagram
Protocol) . Cada mensagem SNMP deve estar totalmente contida num pacote UDP. O padro especifica que
nenhuma entidade receba mensagens maiores que 484 octetos. O padro ainda especifica que todas as mensagens
SNMP (com exceo da trap) devero ser encaminhadas entidade de destino em questo para a porta definida com
o nmero 161. As notificaes (traps) devem ser enviadas porta nmero 162 do gerente.
Cada mensagem uma ao de comunicao entre entidades SNMP. Para a verso 1 do protocolo foram
padronizadas as seguintes operaes :

1. GetRequest: operao na qual o gerente pede o valor de determinados objetos na MIB do

agente
2. GetNextRequest: operao na qual o gerente pede o valor do prximo objeto na MIB do
agente
3. SetRequest: operao na qual o gerente altera o valor de um determinado objeto na MIB do
agente
4. GetResponse: operao que a resposta ou confirmao do agente s mensagens anteriores
5. Trap: operao que a comunicao espontnea de um evento do agente para um gerente

Figura 2 3 Comunicaes SNMPv1 possveis

Uma operao GET ou SET somente se refere a uma nica instncia de um objeto representada atravs de
seu nome.
O formato geral da mensagem SNMP descrito na

Figura 2 4 Formato geral da mensagem SNMP

As regras de codificao BER, citadas anteriormente, traduzem um item de dados (seja ele a mensagem
toda ou um de seus subcampos) em triplas denominadas TLV (Tag, Length, Value), onde:

1. Tag (etiqueta) o primeiro campo e deve especificar o tipo do dado que vem a seguir (no
exemplo, uma sequence de campos pr-determinados: a mensagem SNMPv1)
2. Length o comprimento do dado (aqui no caso, a mensagem SNMPv1 toda)
3. Value o dado (a mensagem SNMPv1)

Deve-se notar que este tipo de codificao tambm ser usado para cada item de dados dentro da PDU
(Protocol Data Unit).
A mensagem SNMPv1 composta de 3 campos bsicos: verso, nome da comunidade e a PDU.
O campo verso um inteiro igual a zero para a verso 1 do protocolo. A checagem desta verso analisa se
o valor zero ou no. Se no for, o pacote simplesmente descartado.
 O campo comunidade usado para autenticao da fonte da mensagem. A maneira como isto feito
apresentada com mais detalhes na discusso da segurana do protocolo nos prximos captulos.
A PDU deve ter o formato prprio de uma das 5 possveis operaes SNMPv1 citadas anteriormente. No
caso das operaes de Get, GetNext, Set e GetResponse, as mensagens tm formato de PDU similar descrito na
Figura 2-5.

Figura 2 5 Formato do campo PDU geral SNMPv1

Cada campo dentro da PDU representado pelo mesmo tipo de codificao BER descrito anteriormente e
no detalhado aqui por motivo de simplicidade. A descrio dos campos a seguinte:

1. ID do request: um nmero de sequncia inteiro que permite associar os pedidos com as

respectivas respostas e permite o controle de fluxo das mensagens por parte de quem as
envia (gerente)
2. Status do erro: um inteiro de 0 a 5 usado pelo agente para indicar condies de erro nas
respostas geradas (GetResponse)
3. Index do erro: um inteiro que indica em qual dos objetos ocorreu o erro, apontando para
tal objeto na lista de objetos e valores do prximo campo da mensagem
4. Lista de Objetos e valores: uma sequncia de pares de valores Object ID / Value, que
representam os objetos da MIB e seus valores sendo utilizados na operao.

A operao de Trap apresenta uma PDU um pouco diferente das demais por causa das informaes que ela
deve transmitir, conforme mostrado na Fig. 2-6.

Figura 2 6 PDU da mensagem trap SNMPv1

Os campos da PDU da Trap so diferentes, tendo o seguinte significado:

5. Enterprise: o identificador do objeto que representa o dispositivo de rede que enviou a
mensagem. Este valor um objeto na MIB, normalmente o objeto sysObjectID do grupo
system (1.3.6.1.2.1.1.2);
6. Endereo do Agente: o endereo de rede do agente que enviou a trap;
7. Generic: um nmero inteiro que representa qual o tipo da trap. Os tipos padres esto
descritos na RFC 1157 ;
8. Specific: um nmero inteiro que representa um tipo de trap especificada pelo fabricante
do equipamento. Este campo permite que se defina mais opes para uma trap;
9. Time Stamp: o momento no qual a trap foi gerada. medido em centsimos de segundos
a partir da inicializao do agente;
 10. Lista de Objetos e Valores: uma sequncia de pares de valores Object ID / Value, que
representam os objetos da MIB interessantes como informao adicional para cada tipo de
trap especfica.

No protocolo SNMP, as operaes so consideradas atmicas, isto , cada operao requisitada deve ser
executada sobre todos os objetos citados na operao, caso contrrio nada feito. No existem execues parciais de
um pedido. Se ocorrer algum erro durante a execuo de uma operao, os resultados produzidos por esta operao
so ignorados e os indicadores de erro ajustados de acordo.
Um cliente SNMP, ou seja, o gerente no caso das mensagens Get, GetNext e Set, deve construir e enviar o
seu pedido ao servidor, ou seja, o agente. O gerente deve, ento, esperar pela resposta de seu pedido e verificar se a
resposta concorda com a resposta do que foi pedido. Devido ao fato de o protocolo de transporte UDP no garantir a
entrega dos pacotes, o cliente deve implementar estratgias para timeout e retransmisso das mensagens que contm
os pedidos.

6. SNMP verso 2 e suas alteraes

A primeira verso do SNMP apresentava falhas que motivaram a inevitvel evoluo do protocolo.
Basicamente, os aspectos falhos mais apontados foram :

Pouca funcionalidade comparativamente ao CMIP/CMIS (protocolo/servio de

gerenciamento da arquitetura OSI).
Segurana rudimentar.
Impossibilidade de comunicao entre gerentes.
Limitaes no protocolo e suas mensagens.
A caracterstica atmica das mensagens, ou seja, o fato de uma mensagem obter ou total
sucesso ou total fracasso nas operaes, no havendo a possibilidade de sucesso parcial
num request, diminuindo a eficincia do protocolo.
Impossibilidade de configurao remota dos agentes.

No comeo de 1992, o IETF anunciou a chamada por propostas para uma nova verso. A primeira resposta
veio nas RFC 1351 a 1353 e foi chamada SNMP seguro (, ,).
O SNMP seguro apresentava um modelo de segurana que integrava autenticao e criptografia ao
protocolo para proteg-lo de ameaas como interrupo, interceptao, modificao e mascaramento de
informaes. A comunicao poderia assim ser totalmente aberta, ou autenticada mas no privada, ou privada mas
no autenticada ou ambas. O novo conceito de party era muito importante nesta proposta. Uma party definida
como um contexto de execuo virtual onde a operao do protocolo restringe-se a um subconjunto de possveis
operaes. A estrutura da party substituia as comunidades da verso 1, acrescentando informaes de tempo
(clocks), chaves e polticas de acesso s entidades SNMP.
O MD5 foi o algoritmo proposto para autenticao e o DES (Data Encription Standard) foi o proposto para
a criptografia das mensagens. O prximo captulo discutir com mais detalhes todos estes aspectos de segurana.
 Foi difcil a aceitao deste novo protocolo principalmente por causa de sua incompatibilidade com a
verso 1, j que as novas mensagens criptografadas no eram compreendidas pelas entidades SNMP anteriores. Em
conseqncia, novos esforos foram direcionados para manter a caracterstica de simplicidade do protocolo original.
Entre os novos aprimoramentos que foram apresentados esto as seguintes diretrizes:

Manter as caractersticas de segurana oferecidas pelo SNMP seguro com a possibilidade

de opo por outro algoritmo de criptografia alternativo ao DES.
Permitir o gerenciamento hierrquico por meio de comunicao entre gerentes. Foi
apresentada uma MIB para a comunicao gerente-gerente .
Aceitar vrios servios de transporte (Appletalk da Apple, IPX da Novell e pilhas CLNP
da arquitetura OSI).
Apresentar um mecanismo de coleta de informaes mais eficiente.
Introduzir um novo modelo administrativo.
Alterar as mensagens do protocolo.
Aceitar mensagens recebidas fora de ordem ou duplicadas pela operao da rede.

A verso 2 foi oficialmente apresentada em 1993 e hoje chamada de SNMPv2 clssica ou SNMPv2p
(baseada em parties). A Tabela 2-2 apresenta os documentos descritores desta nova verso:

Tabela 2 2 Conjunto de RFC do protocolo SNMPv2 clssico (SNMPv2p)

RFC Ttulo
RFC Introduction to version 2 of the Internet-standard Network Management framework
1441
RFC Structure of Management Information for version 2 of the Simple Network
1442 Management Protocol (SNMPv2)
RFC Textual Conventions for version 2 of the Simple Network Management Protocol
1443 (SNMPv2)
RFC Conformance Statements for version 2 of the Simple Network Management
1444 Protocol (SNMPv2)
RFC Adminstrative Model for version 2 of the Simple Network Management Protocol
1445 (SNMPv2)
RFC Security Protocols for version 2 of the Simple Network Management Protocol
1446 (SNMPv2)
RFC Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2)
1447
RFC Protocol Operations for version 2 of the Simple Network Management Protocol
 1448 (SNMPv2)
RFC Transport Mappings for version 2 of the Simple Network Management Protocol
1449 (SNMPv2)
RFC Management Information Base for version 2 of the Simple Network Management
1450 Protocol (SNMPv2)
RFC Manager-to-manager Management Information Base
1451
RFC Coexistence between version 1 and version 2 of the Internet-standard Network
1452 Management Framework

Estes documentos objetivaram portanto implementar uma srie de melhorias no protocolo no que se refere
ao modelo administrativo, MIB e ao protocolo (mensagens).
Na verdade, foram tantos os aspectos novos que as especificaes formais do SNMP expandiram-se de 36
para 416 pginas na verso 2 clssica.
A pilha de transporte necessria para rodar SNMP sempre foi UDP. Esta caracterstica ficou mais flexvel
em SNMPv2, onde outras pilhas de protocolos podem ser usadas mudando algumas informaes de configurao.
Entre as possibilidades esto: protocolos de transporte OSI, Appletalk (protocolo usado por mquinas macintosh) e o
protocolo de transporte usado pelas redes Novell IPX.
No que diz respeito ao protocolo, houveram mudanas substanciais. Em SNMPv2, o conjunto de operaes
sofreu algumas alteraes e adies comparativamente verso 1, possibilitando a comunicao slida, inclusive
entre gerentes, criando hierarquias de gerncia.
As seguintes alteraes no conjunto de operaes refletem estas preocupaes:

getRequest: no existe mais a perda da resposta toda, caso seja problemtico obter o valor
de apenas uma das variveis. Se ocorrer problema na obteno de um valor especfico, o
campo daquela varivel preenchido com cdigos de erro.
getNextRequest: se um pedido de getNext ultrapassar o tamanho da MIB (ou sua database
view), o valor da varivel ser preenchido com o cdigo endOfMibView e o status de erro
ser tambm o correspondente a sucesso (zero), ao contrrio do que era antes na verso 1,
que entendia a mensagem do fim da MIB como um erro.
setRequest: a operao de set executada em duas fases: na primeira, as variveis so
testadas; na segunda, elas so propriamente setadas. Caso alguma delas no passe no
teste, toda a operao falha. Este operao, como em SNMPv1, continuou funcionando de
forma atmica (tudo ou nada).
response: o novo nome da operao getResponse.
snmpV2-trap: o formato das traps foi modificado para ficar semelhante quele usado em
operaes de get e set. Os campos especiais de enterprise, agent-addr, generic-trap,
specific-trap e timestamp foram eliminados e toda informao necessria inserida no
campo de variveis da mensagem. Esta informao contm o nome da trap e o tempo de
 sysUptime, alm da lista de variveis definida para cada trap especfica.

A nova definio de uma trap pode ser feita pela macro NOTIFICATION-TYPE e apresenta basicamente
seu nome e sua lista de variveis. Percebe-se que houve uma uniformizao do formato da PDU, de forma a evitar o
processamento extra para lidar com dois diferentes tipos de PDU.
Alm do mais, SNMPv2 adiciona dois tipos novos de operaes ao protocolo. As mensagens denominadas
GetBulkRequest e InformRequest permitem um aumento das funcionalidades dos agentes e gerentes intermedirios e
tambm a coleta de grandes quantidades de dados.
A nova mensagem InformRequest permite a um gerente enviar, de forma assncrona, uma notificao de
algum evento outro gerente, algo anlogo mensagem trap s que entre gerentes. A diferena com relao ao trap
que o InformRequest um servio confirmado pelo gerente que recebe a mensagem. Isto quer dizer que
necessrio o envio de uma mensagem response para o gerente que originou o inform. Esta nova possibilidade
permite a hierarquizao da estrutura gerencial do SNMPv2, de forma que estaes gerenciadoras locais enviem
informaes a uma estao gerenciadora central, como na Figura 2-7.

Figura 2 7 Comunicao hierarquizada entre gerentes

Em muitos aspectos, a operao de InformRequest semelhante s operaes traps: ambas so declaradas

com a macro NOTIFICATION-TYPE e ambas tm o mesmo formato, inclusive com os valores de identificao e
timestamp encabeando a lista de variveis. Porm, mensagens inform-request so uma resposta eventos
sofisticados, como aumento da taxa de erros alm de um limiar. Outra diferena importante a necessidade de
confirmao por parte do receptor da mensagem. A resposta deve ser por meio de uma mensagem response
retornando a mesma lista de variveis contida no InformRequest.
J a nova mensagem chamada GetBulkRequest otimiza a recuperao de um volume considervel de
variveis, principalmente em relao recuperao de entradas de tabelas. Acontecia um problema com SNMPv1
quando se desejava grandes quantidades de dados de uma MIB: a limitao do tamanho das respostas era funo da
implementao no agente distante. A operao getBulkRequest oferece uma maneira de se pedir eficientemente o
mximo de dados que um agente pode enviar por meio de uma mensagem response.
O pedido pode ser de variveis individuais ou de linhas de uma tabela. A diferena entre as operaes
getBulkRequest e getNextRequest est na capacidade da primeira enviar linhas inteiras de uma tabela, alm de
navegar na MIB de forma sequencial exatamente como get-next.
Por isso, a mensagem getBulkRequest tem uma ligeira diferena com relao ao formato padro para
especificar o nmero de dados a serem enviados pelo agente em resposta a este pedido (Figura 2-8). O campo
No-repetidas define num nmero inteiro, o mximo conjunto de variveis simples a serem enviadas neste pedido.
O campo Max-repetidas define as repeties mximas de uma varivel mltipla (objeto de muitas instncias). Na
verdade, este campo limita o nmero de linhas a serem transmitidas.:

Figura 2 8 PDU SNMPv2 clssica

Caso as informaes no caibam num nico response, cabe ao gerente formular outro getBulkRequest a
partir da ltima varivel na lista. Assim, em SNMPv1, para a recuperao de 10 entradas de uma tabela necessrio
o envio de 10 operaes GetNextRequest. Na verso 2, somente uma operao GetBulkRequest suficiente.

Figura 2 9 - Comunicaes SNMPv2 possveis

Em resumo, as mudanas nos formatos das mensagens refletiram as mudanas nas operaes e as inovaes
do protocolo em termos de segurana.
J o conceito de party restringe as operaes permitidas por entidades SNMPv2, assim como as variveis
que elas enxergam na MIB ou as parties com quem elas podem trocar dados. Com isso, todas as informaes de
controle so agora necessrias dentro da mensagem para um processamento correto. Vale dizer tambm que as
mensagens de erro foram incrementadas de forma a melhorar o tratamento de erros em requests para todas as
operaes.
Elementos especficos de implementao tambm tiveram que ser criados para manter a consistncia das
informaes de gerncia armazenadas na MIB. Um procedimento de lock (trava) foi desenvolvido para manter a
consistncia nas operaes de set na verso 2, para os casos em que vrios gerentes operam num mesmo agente.
Segundo este esquema, o agente devolver ao gerente um nmero de sequncia que permite a alterao de uma
objeto por meio de uma operao de set, assim vrios pedidos para um mesmo agente so executados de forma coesa
um por um.
A Estrutura da Informao de gerenciamento (SMI) foi alterada e tornou-se um superconjunto da primeira
SMI. As maiores vantagens apresentadas nesta nova verso foram os novos tipos de dados, novas macros mais
claramente definidas e os novas declaraes que explicitam os requisitos de conformidade das MIB.
Entre as novidades na MIB, est a possibilidade de melhores declaraes de variveis. Os tipos de dados
tambm sofreram alteraes, tais como os contadores que antes eram de 32 bits, podendo agora ser de 64 bits para
acomodar caractersticas que incrementam com grande velocidade, como o nmeros de pacotes que passa por um
dispositivo num ms.
Ainda dentro do contexto da verso 2, foi definida uma MIB, denominada de M2M (Manager to Manager)
, que suporta a distribuio de funes de monitorao entre os gerentes da rede. Tal monitorao baseada em
amostras realizadas em variveis do tipo counter, gauge e timeticks de agentes. Os valores de tais atributos so
comparados com valores-limites configurados, e caso sejam atingidos, uma mensagem InformRequest ou uma trap
podem ser enviadas pelo gerente que implementa a MIB M2M a outro gerente. Por essa razo, a M2M composta
de dois grupos de objetos: grupo alarm e grupo events. O grupo alarm contm objetos que permitem a configurao
de qualquer gerente para o disparo de uma notificao em funo de valores de variveis da MIB. O grupo events,
por sua vez, permite a definio do formato e da temporizao destas notificaes. Estas podem ser alarmes ou
eventos determinados como a queda de um link.

7. SNMPv2c
Em 1995, foi feita mais uma reviso do protocolo em resposta baixa aceitao da verso SNMPv2
clssica. Tal reviso se deu principalmente no que diz respeito ao contexto baseado em parties, configurao dos
agentes, dificuldade de descoberta da rede e implementao do modelo administrativo e de segurana.
O nico consenso ento obtido foi o da aceitao das novidades no protocolo, porm permanecendo o
contexto de operao sob a antiga forma de comunidades (sem a estrutura de segurana proposta) e,
consequentemente, com o antigo formato das mensagens.
Assim, foi apresentada mais uma verso SNMP, agora chamada de SNMPv2c (baseado em comunidades).
Nesta, o modelo administrativo apresentado na verso clssica e baseado em parties, foi completamente
descartado.
As RFC mostradas na Tabela 2-3 modificaram a verso clssica segundo as novas determinaes (alguns
dos antigos documentos chegaram a ser relegados a status histrico):

Tabela 2 3 RFCs do protocolo SNMPv2c (baseada em comunidades)

RFC Ttulo
RFC Introduction to Community based SNMPv2
1901
 RFC Structure of Management Information for version 2 of the Simple Network
1902 Management Protocol (SNMPv2)
RFC Textual Conventions for version 2 of the Simple Network Management Protocol
1903 (SNMPv2)
RFC Conformance Statements for version 2 of the Simple Network Management Protocol
1904 (SNMPv2)
RFC Protocol Operations for version 2 of the Simple Network Management Protocol
1905 (SNMPv2)
RFC Transport Mappings for version 2 of the Simple Network Management Protocol
1906 (SNMPv2)
RFC Management Information Base for version 2 of the Simple Network Management
1907 Protocol (SNMPv2)
RFC Coexistence between version 1 and version 2 of the Internet-standard Network
1908 Management Framework

Com a no aceitao do modelo de segurana, a mensagem SNMPv2c no incorporou as mudanas

propostas no contexto de parties. Desta forma, a mensagem SNMPv2c possui os mesmos delimitadores e cabealhos
da verso SNMPv1 apresentada anteriormente , com a exceo de que o campo verso agora tem valor 1 indicando a
versao 2 e possibilitando o processamento diferenciado das mensagens recebidas.
O que acabou acontecendo foi a aceitao das novas mensagens (como get-bulk-request), a nova SMI e a
nova MIB, mas mantendo o mesmo modelo administrativo e o mesmo esquema de comunidades da verso 1.
Com isso, apesar do fracasso, pode-se considerar que h aspectos positivos apresentados na verso
SNMPv2p, como a criao de extenses da linguagem (que facilitam a declarao de novos objetos), a melhoria da
performance do protocolo na troca de informaes com um melhor tratamento de erros. Alm disso, uma til
experincia prtica foi obtida nas implementaes e testes com SNMPv2p, possibilitando uma compreenso melhor
dos problemas do protocolo.