Introdução Ao SNMP-Simple Network Management Protocol

O Protocolo de Gestão da Internet
O protocolo de Gestão da Rede (SNMP - Simple Network

Management Protocol) é uma importante ferramenta, que faz
parte do TCP/IP e que serve para gestão dos dispositivos
activos de interligação na internet . O SNMP fornece um
conjunto de operações para monitorização e manutenção da
internet.
O SNMP utiliza o conceito de gestor e agente. O gestor é

normalmente um host, que controla e monitoriza um conjunto
de agentes, que são normalmente os routers.
O SNMP é um protocolo da camada de aplicação que pode

ser instalado em algumas estações de trabalho, visando o
controlo de um conjunto de agentes. O facto de estar situado
ao nível aplicacional, permite que a gestão se faça a uma
variedade de dispositivos, independentemente do fabricante
e da rede física.
A estação de gestão, que se chama gestor é uma estação de

trabalho onde se executa um programa SNMP cliente,
enquanto que a estação gerida, que se chama agente, é
normalmente um router (e em raras situações, estações
terminais – hosts) onde se executam os programas SNMP
server. A gestão é observada através da interação entre o
manager e um agent, em que o agente armazena toda a
informação de sua performance em uma base de dados e o
gestor tem acesso aos valores nesta base de dados. Por
exemplo, um agente pode armazenar em variáveis
apropriadas o número de pacotes que recebeu e enviou. Por
sua vez o gestor pode ir buscar e comparar valores em tais
variáveis, para ver, por exemplo, o estado de
congestionamento do router. O gestor pode também
direccionar um agente para a execução de determinadas
acções. Por exemplo, um router periódicamente verifica o
1
Administração de Sistemas e Redes SNMP - Simple Network Management Protocol Chicapa, E 2021
valor do contador de reinicialização (reboot), para verificar o
estado de reinicialização, que normalmente acontece se o
valor do contador for zero. O gestor pode assim fazer uso desta
caracteristica, para remotamente obrigar a reinicialização do
agente em qualquer altura. Para tal, basta enviar um pacote
com instruções para forçar o valor do contador a zero. Os
agentes podem por seu turno, contribuir para o processo de
gestão. O programa servidor em execução no agente, pode
verificar o ambiente de configuração e parâmetros e em
presença de alguma situação anormal, pode então enviar ao
gestor, uma advertência (warning), conhecida com o nome
técnico de trap (que não é exactamente uma armadilha, mas
pelo contrário, um sinal de que existe uma armadilha!)
Podemos assim dizer que o management através do SNMP,

faz-se de acordo com três princípios básicos:
� O gestor verifica um agente através de solicitações ou

consultas de rede (polling), a cerca da informação que
reflicta o comportamento deste agente.
� O gestor força um agente a proceder com determinadas
tarefas, através da anulação ou activação (resetting) dos
valores na base de dados do agente.
� O agente contribui para o processo de gestão através de
advertências ou eventos não solicitados (trap) feitas ao
gestor, sobre situações anómalas.
2
A figura abaixo mostra, genericamente, como funciona o
sistema de gestão:
Componentes
A gestão da internet não é apenas suportada através do

protocolo SNMP, mas também por meio da cooperação de
outros protocolos, que são o Struture of Management
Information (SMI) e o Management Information Base (MIB), que
são, respectivamente, a Estrutura e a Base de Dados de
Informação de Gestão da Rede. O SNMP utiliza os serviços
fornecidos por estes dois protocolos de aplicação, para
realizar suas tarefas, o que significa que a gestão é feita
através da cooperação entre o SNMP, SMI e o MIB. Estes três
componentes fazem ainda uso dos serviços fornecidos pelos
protocolos Abstract Syntax Notation 1 (ASN.1) e o Basic
Encoding Rules (BER).
3
Estrutura da Informação de Gestão
(SMI - Structure of Management Information)
O SMI é um componente que desempenha as seguintes

funções:
� Nomeação dos objectos
� Definição do tipo de dados que podem ser armazenados
em objectos
� Codificação dos dados para transmissão em rede
O SMI define três atributos que caracterizam um objecto: o

nome, o tipo de dados e o método de codificação.
Nomes
O SMI requer que cada objecto, seja este um router, uma

variável em um router, um valor, etc, tenha um único nome.
Para a sua nomeação global, o SMI usa o conceito de
identificador de objecto (object identifier) que é uma estrutura
hierárquica de nomeação, baseada em árvore. A estrutura da
4
árvore começa por uma raíz, não nomeada. Cada objecto
pode ser definido usando uma sequência de inteiros
separados por pontos. A estrutura da árvore pode também
definir um objecto como uma sequência de nomes textuais
separados por pontos. Por exemplo, seguem as duas
representações para um mesmo objecto:
iso.org.dod.internet.mgmt.mib ===== 1.3.6.1.2.1
Todos os objectos definidos pelo SNMP, são localizáveis sob o

objecto mib, de tal modo que todos os seus identificadores
começam sempre com a sequência 1.3.6.1.2.1.
5
Tipo
O segundo atributo de um objecto é o tipo de dados a si

armazenado. Para definir o tipo de dados, o SMI usa algumas
definições fundamentais do ASN.1, mas também adiciona
algumas novas definições. Em outras palavras o SMI é ao
mesmo tempo subconjunto e superconjunto do ASN.1.
O SMI usa duas principais categorias de tipo de dados: simples

e combinados ou estruturados.
6
Tipos simples: São os tipos de dados atómicos. Parte deles
podem ser obtidos directamente a partir do ASN.1, enquanto
que outros são adicionados pelo SMI. Os mais importantes
estão definidos na tabela abaixo, sendo que os primeiros três
são a partir do ASN.1 e os restantes quatro definidos pelo SMI.
Tipo Tamanho Descrição
Integer 4 bytes Números inteiros de 231 – 1 á 232 – 1

Integer32 4 bytes
Unsigned32 4 bytes Número inteiro sem sinal ( 0 á 2 32 – 1)
Octet String Variável Sequência de zero ou mais caracteres ASCII
Object Identifier Variável Identificador representado por digitos
decimais.
IPAddress 4 bytes Endereço IP de 4 inteiros
Counter32 4 bytes Um inteiro cujo o valor pode ser incrementa
do de zero a 4,294,967,295. Quando atingir
o valor máximo é reinicializado a zero.
Counter64 8 bytes
Gauge32 (medida) 4 bytes O mesmo que contador; mas mantém o valor
quando atinge o máximo.
TimeTicks 4 bytes Um valor contador que regista o tempo em
1/100 de segundo
Tipos estruturados
Podemos combinar os tipos simples e estruturados para formar

novos tipos de dados. O SMI define dois tipos de dados
estruturados: a sequência e a sequência de ( sequence and
sequence of)
� O tipo de dado sequence é a combinação de tipos
simples, não necessáriamente do mesmo tipo. Este
conceito é análogo ao de struct ou record utilizado em
linguagens de programação como C, etc.
� O tipo de dado sequence of é a combinação de tipos de
dados todos do mesmo tipo como acontece com os
array.
7
Método de Codificação
O SMI usa uma outra norma, a Basic Encoding Rules (BER) para
codificar os dados antes de serem transmitidos através da
rede. O BER define que cada peça de informação seja cifrada
num formato com três campos, no formato TLV, combinando a
etiqueta (tag, o tamanho (length) e valor (value).
Etiqueta: A etiqueta é de 1 byte de tamanho e define o tipo

de dados do objecto. É composto por três subcampos:
class (2 bits)
format (1 bit)
number (5 bits)
Classe: define o âmbito dos dados. Foram definidas quatro

classes:
universal (00)
application-wide (01)
context-specific (10)
private (11)
� Os tipos de dados de âmbito universal são aqueles

definidos através do ASN.1 (Integer, String e
ObjectIdentifier).
� Os de âmbito aplicacional são aqueles adicionados pelo
SMI (IPAddress, Counter, Gauge e TimeTicks).
� Existem classes de tipos de dados que são definidos no

contexto de um protocolo, bem como os que são
definidos ao nível privado de vendedores, ou seja,
dependentes de fabricantes. Os cinco tipos diferentes de
mensagens que abordaremos mais adiante, são definidos
no contexto específico, variando de acordo com o
protocolo.
8
Formato: O formato indica se o tipo é simples (0) ou
estruturado (1).
Número: O número por seu turno, divide os tipos simples ou

estruturados em subgrupos. Por exemplo, dentro da classe
universal, com o formato simples, os inteiros têm o valor igual a
2, a sequência igual a 4, etc. A tabela a seguir, mostra os tipos
de dados e suas etiquetas em binário e em hexadecimal.
Tipo de Dados Classe Formato Número Etiqueta

em Binário em
Hexadecimal
Integer 00 0 00010 00000010 02
String 00 0 00100 00000100 04
Null 00 0 00101 00000101 05
ObjectIdentifier 00 0 00110 00000110 06
Sequence, 00 1 10000 00110000 30
Sequence of
IPAddress 01 0 00000 01000000 40
Counter 01 0 00001 01000001 41
Gauge 01 0 00010 01000010 42
TimeTicks 01 0 00011 01000011 43
Tamanho: é um campo de um ou mais bytes. Se fôr de um

byte, o bit mais significativo deverá ser zero; Os sete bits
restantes definem o comprimento dos dados. Se fôr mais de
um byte, o bit mais significativo do primeiro byte deverá ser um
(1). Os restantes sete bits do primeiro byte definem o número
de bytes necessários para definir o comprimento dos dados:
Tamanho unibyte: O campo tamanho do objecto com apenas
um byte. O primeiro bit deve ser zero (0). No exemplo abaixo, o
tamanho é igual a 2 bytes.
0 0 0 0 0 0 1 0
9
Tamanho multibyte: O campo tamanho com mais de um byte.
O primeiro bit do byte inicial deve ser um (1) e os restantes sete
indicam o número de bytes adicionais.
No exemplo abaixo, o tamanho do objecto é igual a 260

bytes. Repare que nos restantes sete bits do primeiro byte
temos 2, que indicam o número de bytes adicionais. É fácil
perceber que para representar o número 260, precisamos de
mais de um byte.
1 0 0 0 0 0 1 0 1 0 0 0 0 0 1 0 0
Valor: O valor guarda a codificação dos dados de acordo

com as regras definidas no BER.
Vejamos os exemplos abaixo:
� Representação do valor inteiro 14
02 04 00 00 00 0E
0000 0010 0000 0100 0000 0000 0000 0000 0000 0000 0000 1110
Etiqueta: Tamanho: Valor:
Inteiro (4 bytes) (14)
� Representação da string “HI”
04 02 48 49
0000 0100 0000 0010 0100 1000 0100 1001
Etiqueta: Tamanho: Valor: Valor:
String (2 bytes) (H) (I)
10
� Representação do identificador de objecto (OID)
ObjectIdentifier: 1.3.6.1 (iso.org.dod.internet)

06 04 01 03 06 01
0000 0110 0000 0100 0000 0001 0000 0011 0000 0110 0000 0001
Etiqueta: Tamanho: Valor: Valor: Valor: Valor:
ObjectId (4 bytes) (1) (3) (6) (1)
| -------- 1.3.6.1 (iso.org.dod.internet) ------------------|
� Representação do endereço IPAddress: 131.21.14.8
40 04 83 15 0E 08
0100 0000 0000 0100 1000 0011 0001 0101 0000 1110 0000 1000
Etiqueta: Tamanho: Valor: Valor: Valor: Valor:
IPAddress (4 bytes) (131) (21) (14) (8)
| ----------- 131.21.14.8 ------------------|
Para todos os casos acima, a codificação final é feita em

Hexadecimal.
11
Base de Dados de Informações de Gestão
(MIB - Management Information Base)
Trata-se do segundo componente usado na gestão de redes.

Cada agente possui o seu próprio MIB, que é a colecção de
todos os objectos que podem ser manejados por um gestor.
Os objectos no MIB encontram-se classificados em oito
categorias ou grupos diferentes: System, Interface, Address
Translation (AT), IP, ICMP, TCP, UDP, e EGP. Todos estes grupos
encontram-se sob o nível mib (ou mib-II), na árvore hierárquica
de identificadores.
mib
sys (1) If (2) at (3) ip (4) Icmp (5) Tcp (6) Udp (7) Egp (8)
Cada grupo tem definido um conjunto de variáveis e/ou

tabelas. Vamos á título de exemplo, mostrar a ramificação do
grupo udp.
12
1.3.6.1.2.1.7
udp
udpTable (5)
udpIn (1) udpNo (2) udpIn (3) udpOut (4)

Datagrams Ports Errors Datagrams udpEntry (1)
udpLocal (1) udpLocal (2)

Address Port
Vejamos como se pode ter acesso a cada entidade deste

grupo:
Variáveis simples
Para aceder a variáveis simples, utiliza-se o ID do grupo

(1.3.6.1.2.1.7), seguido do identificador da variável.
udpInDatagrams � 1.3.6.1.2.1.7.1
udpNoPorts � 1.3.6.1.2.1.7.2
udpInErrors � 1.3.6.1.2.1.7.3
udpOutDatagrams � 1.3.6.1.2.1.7.4
Contudo, estes identificadores de objectos definem variáveis e

não suas respectivas instâncias ou conteúdos. Para aceder ao
conteúdo de cada variável, devemos adiccionar um sufixo
para instanciação. Para instânciar uma simples variável, basta
13
acrescentar zero á direita. Por exemplo, para as variáveis
acima, teremos:
udpInDatagrams.0 � 1.3.6.1.2.1.7.1.0
udpNoPorts.0 � 1.3.6.1.2.1.7.2.0
udpInErrors.0 � 1.3.6.1.2.1.7.3.0
udpOutDatagrams.0 � 1.3.6.1.2.1.7.4.0
Variáveis estruturadas - Tabelas
Para identificar uma tabela, usamos primeiro o ID da tabela.

O grupo udp possui apenas uma tabela (com o id igual a 5).
Assim para aceder a tabela udpTable, teremos:
udpTable � 1.3.6.1.2.1.7.5
O objecto ora definido não se encontra ao nível mais baixo,

por isso precisamos definir uma entrada à tabela, como sendo
uma sequência:
udpEntry � 1.3.6.1.2.1.7.5.1
A partir deste nível podemos definir os elementos da tabela,

como sendo o conjunto de “registos” ou entradas que
constituem a sequência. Cada entrada será assim definida:
udpLocalAddress � 1.3.6.1.2.1.7.5.1.1
udpLocalPort � 1.3.6.1.2.1.7.5.1.2
Estas duas últimas variáveis, estão ao nível mais baixo da

estrutura em árvore, ou seja, são os que devem conter dados.
Embora possamos instânciar tais variáveis, teremos que definir
que instâncias vão ser utilizadas.
A qualquer momento, a tabela pode ter vários valores para

cada entrada com o par endereço/porta local. Para ter
14
acesso a uma instância específica (fila) da tabela, devemos
adiccionar um índice aos ids situados aos níveis superiores.
Na MIB, os índices de vectores não são inteiros como em
linguagens de programação. Os índices são baseados em
valores de um ou mais campos que constituem cada entrada.
No nosso exemplo acima, o udpTable fica indexado
baseando-se no par endereço local e porto local.
Assim para aceder á instância duma das entradas, podemos

ter o seguinte:
udpLocalAddress.181.23.45.14.23 � 1.3.6.1.2.1.7.5.1.1.181.23.45.14.23
Note-se que nem todas as tabelas são indexadas da mesma

maneira, podem ter, portanto, um, dois ou mais campos em
cada entrada. Por exemplo, o grupo interface detém uma
única tabela, ifTable, (sequência de sequências, ou melhor,
vector de registos) indexada com 22 campos.
O MIB define igualmente uma ordem lexicográfica dos seus

identificadores bem como suas instâncias. As tabelas estão
organizadas seguindo a regra coluna-fila, o que significa que a
ordem de acesso é feita de coluna a coluna, da esquerda a
direita e em cada coluna, do topo á base, ou seja, em ordem
descendente.
15
O Protocolo SNMP
O SNMP, como já foi referido antes, utiliza ambos o SMI e o MIB,

na gestão da internet. Funcionando ao nível aplicacional,
permite:
� Que um gestor possa obter o valor de um objecto
definido em um agente.
� Que um gestor possa armazenar um valor a um objecto
definido no agente.
� Que o agente, em certas ocasiões, possa enviar ao
gestor, mensagens a cerca de uma situação anormal,
em seu ambiente.
16
Mensagens
O SNMP actualmente define mais do que os cinco (5) tipos de

mensagens inicialmente definidos na sua versão 1:
Get Request
GetNextRequest
Response
SetRequest
GetBulkRequest
InformRequest
Trap
Report
� GetRequest: é enviada a partir de um gestor (cliente),

para um agente (servidor), por forma a solicitar um valor
de uma variável.
� GetNextRequest: é igualmente no sentido gestor - agente
e visa solicitar um valor de uma variável. O valor
retribuido é o valor do objecto que segue ao definido em
ObjectId, na mensagem. Esta mensagem é comumente
usada, para retribuição de valores das entradas de uma
tabela. Se o gestor não conhecer os índices das
entradas, não saberá como obter os valores, mas neste
caso poderá usar o GetNextRequest e definir o ObjectId
da tabela. Uma vez que a primeira entrada possui o valor
imediatamente após ao do ObjectId da tabela, então o
valor desta entrada será retribuido nesta ordem. Logo, o
manager, deverá fazer o uso do ObjectId, para obter o
valor seguinte e assim por adiante.
� GetResponse: é enviada do agente para o gestor, em
resposta a uma solicitação por GetRequest ou
GetNextRequest. Deverá conter o valor da ou das
variáveis solicitadas.
� SetRequest: é uma mensagem enviada do gestor ao
agente e serve para atribuição de valores ás variáveis.
17
� Trap: o trap é uma mensagem enviada a partir do
agente, visando o reportório de uma ocorrência de
evento. Por exemplo, se um agente tiver que ser
reinicializado, esta informa ao gestor, reportando a hora
para tal acção.
� InformRequest: A PDU do tipo InformRequest é trocada
entre dois gestores. Um gestor solicita informações
acerca de um agente, através de um gestor remoto.
Uma vez obtida a resposta do agente, o gestor remoto a
faz chegar a entidade solicitante, através de uma
mensagem do tipo Response.
Formato das Mensagens
No SNMPv1 o formato das mensagens é igual, excepto a do

tipo trap, que se apresenta ligeiramente diferente.
A seguir os campos que compõem o referido formato:
Formato das mensagens GetRequest,

GetNextRequest, SetRequest e Response
| � .................................. Mensagem ......................................................................� |

| |�…………….. PDU …………………………………..� |
Version Community Request Error Error VarBindList
ID Status Index
Variável Valor ........ Variável Valor
Formato da Mensagem Trap
| � .................................. Mensagem................................................................... � |
| |�…………….. PDU ……………………………� |
Version Community Enterprise Agent Trap Specific Time
Address Type Code Stamp VarBind
List
Variável Valor ........ Variável Valor
18
Definição dos Campos
Version: Define o número da versão do SNMP. O valor neste

campo o número da versão menos 1, o que significa que se
este valor for zero, tratar-se-á da SNMPv1, etc.
Actualmente temos a versão 3 do SNMP, que foi elaborada
para oferecer um melhor suporte a segurança,
nomeadamente, a autenticação, privacidade e controlo de
acesso.
No nosso exemplo, assumimos como valor deste campo, igual

a zero.
Community: Define a password. Se não houver uma password
explícita, o valor do campo é “public”.
O acesso aos agentes pode ser feito de duas formas:
read-only ou read-write. O valor “public”, corresponde ao
acesso default (read-only)
Request ID: É um número de sequência, utilizado pelo gestor

numa solicitação para ser confirmado pelo agente na
resposta, por forma a identificar o par pergunta – resposta.
Error status: É um número inteiro utilizado apenas nas respostas,
para mostrar o tipo de erros reportados pelo agente. O seu
valor é zero, se se tratar de mensagens de solicitação.
A tabela seguinte lista os principais tipos de erros, que podem

ocorrer:
Status Nome Significado
0 noError Não há erros

1 tooBig Resposta muito extensa para caber numa mensagem
2 noSuchName A variável não existe
3 badValue O valor a armazenar é incorrecto
4 readOnly O valor não pode ser modificado
5 genErr Outros erros
19
Error index: Este indica o offset (deslocamento, desde a origem
da lista VarBindList) para informar ao gestor que variável estará
na origem do erro.
VarBindList: Este é o conjunto de variáveis e respectivos valores,
que o gestor pretende obter ou atribuir. Nas mensagens
GetRequest e GetNextRequest, os valores são nulos. Na
mensagem trap, esta lista mostra as variáveis e valores
específicos a uma dada mensagem.
Enterprise: Este campo define o ObjectId do pacote de
software que terá estado na origem da trap.
Agent address: Define o endereço IP do agente gerador da

trap.
Trap Type: Encontram-se definidos sete (7) tipos de traps, tal
como mostra a tabela abaixo:
Status Nome Significado
0 coldStart O agente foi inicializado

1 warmStart O agente foi reinicializado
2 linkDown Uma interface foi desactivada
3 linkUp Uma inteface foi activada
4 authenticationFailure Detectado campo community incorrecto
5 egpNeighborLoss Um router EGP foi desabilitado
6 enterpriseSpecific Outras mensagens
Specific code: Se o tipo da trap for 6, este campo define o

código específico usado pelo vendedor.
Time stamp: Mostra o tempo decorrido desde a ocorrência do
evento que provocou o trap.
20
Codificação das mensagens
Para a codificação das mensagens, o SNMP utiliza também a

norma BER. Antes de mais, as mensagens são definidas através
de etiquetas, em que a classe é a context-specific(10), o
formato é estruturado (1) e os números são 0, 1, 2, 3 e 4, para
os diferentes tipos de mensagens, como se mostra na tabela
abaixo.
Tabela para Códigos de Mensagens (SNMPv1)
Data Class Format Number Whole tag Whole tag

(Binary) (Hex)
GetRequest 10 1 00000 10100000 A0

GetNextRequest 10 1 00001 10100001 A1
GetResponse 10 1 00010 10100010 A2
SetRequest 10 1 00011 10100011 A3
Trap 10 1 00100 10100100 A4
Uma mensagem é uma combinação de três elementos:

versão, comunidade e PDU (unidade protocolar de dados).
� A versão é codificada como um triplet
(etiqueta, tamanho e valor).
� A comunidade é codificada também como um trio
(tag, length , value).
� O PDU, por sua vez, contém o código para o tipo do PDU,
o tamanho e os dados propriamente.
� Os dados PDU são feitos para um:
request id (etiqueta, tamanho e valor),
estado de erro (etiqueta, tamanho e valor),
índice de erro (etiqueta, tamanho e valor);
e para a
VarBindList, que é uma sequência de sequências
(sendo cada sequencia, uma combinação de
variável e dado).
21
Message Sequence, length
Version
Integer, length, value
Community
String, length, value
PDU PDU-type, length
Request ID
Error Status
Error Index
VarBindList Sequence, length
Object Identifier
Sequence, length
Value to be stored
ObjectId, length, value
Object Identifier Data-type, length, value
Value to be stored As últimas três definições se repetem para as

entradas seguintes de VarBindList, se as houver.
É preciso notar que a versão 3 do SNMP, apresenta ligeiras

alterações aos valores das tabelas anteriores, visto terem sido
acrescentados novos tipos de mensagens. Assim, a tabela
para códigos de mensagens passa a ser:
Data Class Format Number Whole tag Whole tag

(Binary) (Hex)
GetRequest 10 1 00000 10100000 A0

GetNextRequest 10 1 00001 10100001 A1
Response 10 1 00010 10100010 A2
SetRequest 10 1 00011 10100011 A3
GetBulkRequest 10 1 00100 10100101 A5
InformRequest 10 1 00101 10100110 A6
Trap (SNMPv3) 10 1 00111 10100111 A7
Report 10 1 01000 10101000 A8
22
Esta nova tabela de codificação preserva o código da
mensagem trap na versão anterior (A4).
Exemplo de codificação (SNMPv1)
Seja uma estação gestora, com um cliente SNMPv1, que

através da mensagem GetRequest, pretende obter o número
de datagramas UDP, que um router – agente - recebeu. O
agente, para satisfazer o pedido, devolverá a mensagem
GetResponse (ou simplesmente, Response).
Portanto, o gestor pretende saber quantos pacotes UDP, um

dado router recebeu. Como já foi visto antes, a variável MIB
correspondente a esta informação é
udpInDatagrams
com o identificador,
1.3.6.1.2.1.7.1
O manager irá obter o valor daquela variável, logo se

repararmos na figura acima, a última secção do formato da
mensagem – a que armazena o valor da variável – estará
vazia (na solicitação, GetRequest, o seu valor é nulo).
O valor nulo será codificado com um tipo especial de dados,
cujo valor é zero, resultando no código 05 00, ( possui apenas
a etiqueta: 05 e o campo tamanho, com valor nulo,
representado por zero: 00 )
23
Codificação da mensagem que solicita (GetRequest), o
número de segmentos udp recebidos (udpInDatagrams)
Codificação Significado
30 2A Sequência de tamanho 2A16

02 01 00 Inteiro de tamanho 01 16, versão = 0
04 06 70 75 62 6C 69 63 String de tamanho 0616, valor = “public”
A0 1D GetRequest de tamanho 1D16 (todo o conteúdo da pdu)
02 04 00 01 06 11 Inteiro, tamanho: 04 16, RequestId = 0001061116
02 01 00 Inteiro, tamanho: 01 16, Error Status = 00 16
02 01 00 Inteiro, tamanho: 04 16, Error Index = 0016
30 0F Sequência, tamanho: 0F16
30 0D Sequência, tamanho: 0D16
06 09 01 03 06 01 02 01 07 01 00 ObjectId, tamanho: 09 udpInDatagram

05 00 Entrada nula, tamanho: 00 16
Exemplo de Codificação com SNMPv3
No SNMPv3 o empacotamento de uma mensagem

compreende uma sequência compendo 4 elementos:
Version, GlobalData, SecurityParameters e ScopePDU (que
inclui a codificação da PDU).
A estrutura da mensagem abaixo indicada é comum a todos
os tipos de PDU, excepto a GetBulkRequest, que substitui os
campos error-status e error-index, pelos campos no-repeater e
max-repetitions, respectivamente.
A secção SecurityParameters é uma sequência cuja
composição pode variar em função do tipo provisões de
segurança aplicados na versão 3.
24
A figura abaixo mostra a estrutura de empacotamento da
mensagem GetRequest contendo a solicitação da variável
udpInDatagrams. Refira-se que a título de exemplo, os
parametros de segurança, cujo conteúdo não é especificado,
representa uma sequência de 40 bytes.
25
A sequencia hexadecimal resultante é a seguinte:
Normalmente é representada em filas de 4 bytes, mas reduzir o
tamanho da tabela aparece em filas maiores.
26
Principais Objectos MIB
Apresentaremos a seguir alguns grupos mais importantes:
Grupo de Sistema
Este grupo fornece informações globais do sistema.

É composto por apenas variáveis simples:
ID Nome Tipo Descrição

1 sysDescr String Descrição do Sistema
2 sysObjectId ObjectID Identificação do Vendedor
3 sysUpTime TimesTicks Tempo do último arranque do sistema
4 sysContact String Pessoa de Contacto
5 sysName String Nome do Domínio
6 sysLocation String Localização
7 sysService Integer Total tempo de Serviço
Grupo de Interface
Fornece informações acerca das interfaces. É composto por

apenas uma variável simples e uma variável combinada –
tabela.

1 ifNumber Integer Número de interfaces
A única tabela do grupo interface, ifTable, é uma sequência

de sequências (vector de registos), sendo cada sequência
(registo ou coluna) composta por 22 campos. O índice da
tabela é o valor do campo ifIndex.

2.1.1 ifIndex Integer Índice da Interface
2.1.2 ifDescr String Descrição da Interface
2.1.3 ifType Integer Tipo da Interface
2.1.4 ifMtu Integer MTU da Interface
2.1.5 ifSpeed Gauge (Medida) Velocidade (bits/segundos)
2.1.6 ifPhysAddress PhysAddress Endereço Físico
27
2.1.7 ifAdminStatus Integer O Estado esperado da Interface

2.1.8 ifOperStatus Integer O Estado actual da Interface
2.1.9 ifLastChange TimesTicks Tempo desde último arranque do sistema
2.1.10 ifInOctets Counter Total bytes recebidos
2.1.11 ifInUcastPkts Counter Total pacotes unicast enviados
2.1.12 ifInNUcastPkts Counter Total pacotes não unicast enviados
2.1.13 ifInDiscards Counter Total pacotes recebidos e descartados
2.1.14 ifInErrors Counter Número pacotes recebidos em erro
2.1.15 ifInUnknownProtos Counter Número pacotes recebidos com protocolo
desconhecido
2.1.16 ifOutOctects Counter Total bytes enviados
2.1.17 ifOutUcastPkts Counter Total pacotes unicast recebidos protocolos
superiores
2.1.18 ifOutNUcastPkts Counter Total pacotes não unicast recebidos
protocolos superiores
2.1.19 ifOutDiscards Counter Número de pacotes saídos e descartados
2.1.20 ifOutErrors Counter Número de pacotes saídos em erro
2.1.21 ifOutQLen Counter Número de pacotes a espera na fila de saída
2.1.22 ifSpecific ObjectID Referência a definição MIB
Grupo IP
Variáveis

1 ipForwarding Inteiro Mostra se o sistema encaminha ou não
2 ipDefaultTTL Inteiro O valor TTL por defeito
3 ipInReceive Contador Número de pacotes recebidos
4 ipInHdrErrors Contador Número de pacotes com erros de cabeçalho
5 ipInAddrErrors Contador Número de pacotes com erros de endereço
6 ipForwdatagrams Contador Número de pacotes encaminhados
7 ipInUnknownProtos Contador Número de pacotes com protocolos
desconhecidos
8 ipInDiscards Contador Número de pacotes entrados e descartados
9 ipInDelivers Contador Número de pacotes enviados ás camadas
superiores
10 ipOutRequests Contador Número de pacotes passados ao IP para
transmissão
11 ipOutDiscards Contador Número de pacotes saídos e descartados
12 ipOutNoRoutes Contador Número de pacotes para os quais não foi
28
encontrada uma rota
13 ipReasmTimeout Inteiro Tempo de expiração da Reassemblagem
14 ipReasmReqds Contador Número de pacotes a serem reagrupados
15 ipReasmOKs Contador Número de pacotes já reagrupados

16 ipReasmFails Contador Número de reagrupamentos falhados
17 ipFragOKs Contador Número de pacotes fragmentados
18 ipFragFails Contador Número de pacotes que precisam ser
fragmentados, mas não podem
19 ipFragCreates Contador Número de fragmentos criados
20 ipRoutingDiscards Contador Número de entradas de routing eliminadas
Tabela 1
Nome da tabela: ipAddrTable

Número de Campos: 5
Índice: ipAdEntAddr

21.1.1 ipAdEntAddr IpAddress Endereço IP da Interface
21.1.2 ipAdEntIfIndex Inteiro Número da Interface
21.1.3 ipAdEntNetMask IpAddress Máscara de Subrede
21.1.4 ipAdEntBcastAddr Inteiro Endereço de Difusão
21.1.5 ipAdEntReasmMaxSize Inteiro Número de entradas de routing eliminadas
Tabela 2
Nome da tabela: ipRouteTable

Índice: ipRouteDest

22.1.1 ipRouteDest ipAddress Endereço IP de Destino
29
22.1.2 ipRouteIfIndex Inteiro Número da Interface
22.1.3 IpRouteMetric1 Inteiro Métrica primária de Encaminhamento
22.1.4 IpRouteMetric2 Inteiro Métrica alternativa de Encaminhamento
22.1.7 IpRouteNextHop ipAddress Endereço IP próxima transição (next hop)
22.1.8 IpRouteType Inteiro Tipo de Rota
22.1.9 IpRouteProto Inteiro Protocolo de Encaminhamento
22.1.10 IpRouteAge Inteiro Idade de actualização
22.1.11 IpRouteMask ipAddress Máscara de Subrede
22.1.13 IpRouteInfo ObjectID Objecto MIB para este protocolo de routing
Tabela 3
Nome da tabela: ipNetToMedia

Índice: combinação dos valores de ipNetToMediaIfIndex
e ipNetToMediaNetAddress

23.1 ipNetToMediaIfIndex Inteiro Número da Interface
23.2 ipNetToMediaPhysIndex Endereço Físico Endereço Físico
23.3 ipNetToMediaNetAddress Endereço IP Endereço IP
23.4 ipNetToMediaType Inteiro Tipos de Mapeamento
30
Referencias Bibliográficas
th
Data Communication and Networking 5 edition
Behrouz A. Forouzan
Data and Computer Communications 8th edition
William Stallings
31
��
��
��

Introdução Ao SNMP-Simple Network Management Protocol

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Introdução Ao SNMP-Simple Network Management Protocol

Enviado por

Direitos autorais:

Formatos disponíveis

O Protocolo de Gestão da Internet

O protocolo de Gestão da Rede (SNMP - Simple Network

O SNMP utiliza o conceito de gestor e agente. O gestor é

O SNMP é um protocolo da camada de aplicação que pode

A estação de gestão, que se chama gestor é uma estação de

Podemos assim dizer que o management através do SNMP,

� O gestor verifica um agente através de solicitações ou

A gestão da internet não é apenas suportada através do

O SMI é um componente que desempenha as seguintes

O SMI define três atributos que caracterizam um objecto: o

O SMI requer que cada objecto, seja este um router, uma

iso.org.dod.internet.mgmt.mib ===== 1.3.6.1.2.1

Todos os objectos definidos pelo SNMP, são localizáveis sob o

O segundo atributo de um objecto é o tipo de dados a si

O SMI usa duas principais categorias de tipo de dados: simples

Tipo Tamanho Descrição

Integer 4 bytes Números inteiros de 231 – 1 á 232 – 1

Podemos combinar os tipos simples e estruturados para formar

Etiqueta: A etiqueta é de 1 byte de tamanho e define o tipo

Classe: define o âmbito dos dados. Foram definidas quatro

� Os tipos de dados de âmbito universal são aqueles

� Existem classes de tipos de dados que são definidos no

Número: O número por seu turno, divide os tipos simples ou

Tipo de Dados Classe Formato Número Etiqueta

Tamanho: é um campo de um ou mais bytes. Se fôr de um

No exemplo abaixo, o tamanho do objecto é igual a 260

Valor: O valor guarda a codificação dos dados de acordo

Vejamos os exemplos abaixo:

� Representação do valor inteiro 14

� Representação da string “HI”

ObjectIdentifier: 1.3.6.1 (iso.org.dod.internet)

� Representação do endereço IPAddress: 131.21.14.8

Para todos os casos acima, a codificação final é feita em

Trata-se do segundo componente usado na gestão de redes.

Cada grupo tem definido um conjunto de variáveis e/ou

udpIn (1) udpNo (2) udpIn (3) udpOut (4)

udpLocal (1) udpLocal (2)

Vejamos como se pode ter acesso a cada entidade deste

Para aceder a variáveis simples, utiliza-se o ID do grupo

Contudo, estes identificadores de objectos definem variáveis e

Variáveis estruturadas - Tabelas

Para identificar uma tabela, usamos primeiro o ID da tabela.

O objecto ora definido não se encontra ao nível mais baixo,

A partir deste nível podemos definir os elementos da tabela,

Estas duas últimas variáveis, estão ao nível mais baixo da

A qualquer momento, a tabela pode ter vários valores para

Assim para aceder á instância duma das entradas, podemos

Note-se que nem todas as tabelas são indexadas da mesma

O MIB define igualmente uma ordem lexicográfica dos seus

O SNMP, como já foi referido antes, utiliza ambos o SMI e o MIB,

O SNMP actualmente define mais do que os cinco (5) tipos de

� GetRequest: é enviada a partir de um gestor (cliente),

Formato das Mensagens

No SNMPv1 o formato das mensagens é igual, excepto a do

Formato das mensagens GetRequest,

| � .................................. Mensagem ......................................................................� |

Variável Valor ........ Variável Valor

Formato da Mensagem Trap

Variável Valor ........ Variável Valor

Version: Define o número da versão do SNMP. O valor neste

No nosso exemplo, assumimos como valor deste campo, igual

Request ID: É um número de sequência, utilizado pelo gestor