CENTRO UNIVERSITÁRIO UNIVATES 

CURSO DE SISTEMAS DE INFORMAÇÃO 

 

 

 

 

 

 

 

 

 

 

PROJETO DE GERENCIAMENTO DE UNIDADES 

GEOGRAFICAMENTE DISTRIBUÍDAS 

A PARTIR DE UM NÓ CENTRAL 

 

 

Flávio André Johann 

 

 

 

 

 

 

 

 

 

 

 

Lajeado, dezembro de 2013



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

Flávio André Johann 

 

 

 

 

 

 

 

 

 

 

 

 

PROJETO DE GERENCIAMENTO DE UNIDADES 

GEOGRAFICAMENTE DISTRIBUÍDAS 

A PARTIR DE UM NÓ CENTRAL 

 

 

Monografia apresentada na disciplina de 

Trabalho de Conclusão de Curso – Etapa II, 

do curso de Sistemas de Informação, do 

Centro Universitário UNIVATES, como parte 

da exigência para a obtenção do título de 

Bacharel em Sistemas de Informação. 

 

Orientador: Prof. Ms. Luis Antônio 

Schneiders 

 

 

 

 

 

Lajeado, dezembro de 2013 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

 
 

Flávio André Johann 

 

 

 

 

 

 

 

 

 

 

 

 

PROJETO DE GERENCIAMENTO DE UNIDADES 

GEOGRAFICAMENTE DISTRIBUÍDAS 

A PARTIR DE UM NÓ CENTRAL 

 

 

A banca examinadora abaixo aprova a Monografia apresentada na disciplina de Trabalho 

de Conclusão de Curso – Etapa II, na linha de formação específica em Sistemas de 

Informação, do Centro Universitário Univates, como parte da exigência para a obtenção 

do grau de Bacharel em Sistemas de Informação: 

 

 

Prof. Ms. Luis Antônio Schneiders - orientador 

Centro Universitário UNIVATES. 

 

Prof. Esp. Edson Moacir Ahlert, UNIVATES 

Centro Universitário UNIVATES 

 

Prof. Ms. Marcus Vinícius Lazzari 

Centro Universitário UNIVATES 

 

   

Lajeado, 06 de dezembro de 2013



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

DEDICATÓRIA 

 

 

 

 

 

 

 

 

 

Dedico... 

A Flávio Ardi Johann e Ritta Bottega Johann, meus pais e mestres desde o 

ínicio da minha existência, por tudo que me ensinaram e pelo apoio que sempre me 

deram para que fosse possível trilhar os caminhos de minha formação pessoal e 

profissional. Dedico também a minha namorada, Júlia Tresoldi, e a toda a sua 

família, pelo carinho, atenção, compreensão e ajuda nos momentos de dificuldade. 

Dedico esta obra também aos entusiastas e aficcionados pelo Zabbix, a Vinício 

Zanchettin, que despertou o meu interesse por este software, a Luciano Alves e  

toda a equipe da Unirede de Porto Alegre pelo tratamento diferenciado e 

excepcional treinamento prestado. A Eduardo Johann e toda a equipe da 

Costaneira, pelos ensinamentos diários e credibilidade disposta neste projeto. 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

 
 

AGRADECIMENTOS 

 

 

 

 

 

 

 

 

 

 

 

Agradeço ao meu orientador, prof. Ms. Luís Antônio Schneiders pelo tempo 

dedicado para auxiliar-me na redação e organização desta monografia. Aos demais 

integrantes do corpo docente do CCTEC pelo excelente trabalho desempenhado ao 

longo dos anos, contribuindo não só para a formação acadêmica como também 

humanitária de seus discentes. A Ana Paula Ferreira Antunes pelo auxílio na edição 

final das imagens e a todos os meus amigos, companheiros e colegas por 

compartilharem comigo momentos inesquecíveis desta vida.  

Gratidão eterna! 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

RESUMO 

 

 

Com a expansão da Internet e da tecnologia, tornou-se imprescindível o uso de 
mecanismos para o controle e gerenciamento das infraestruturas de redes de 
computadores e dos sistemas que armazenam informações. Assim, essa monografia 
visa apresentar um projeto que permita controlar e monitorar ativos em unidades 
geograficamente distribuídas a partir de um nó central. Desse modo, estima-se que 
um administrador de redes possa identificar e prevenir possíveis pontos críticos de 
falhas na rede de forma proativa, tendo um maior controle sobre os ativos 
monitorados, podendo dimensionar melhor as tecnologias utilizadas e planejar 
futuras expansões, caso seja necessário. Para tanto, foi proposto o estudo da 
infraestrutura de redes na empresa Costaneira S/A, com sede na cidade de Lajeado-
RS, e filiais distribuídas em todo o Estado. A metodologia desse estudo envolveu 
conceituar os princípios e protocolos utilizados para o gerenciamento de redes, 
descrever o cenário da empresa sugerida, analisar e comparar algumas das 
soluções de software livre mais utilizadas nessa área de pesquisa, implantar a 
solução que melhor se adaptou ao ambiente da empresa, avaliar e discutir os 
resultados obtidos, propondo melhorias. 
 
Palavras-chave: Gerenciamento de redes. Protocolos de gerenciamento de redes. 

Software de gerenciamento de redes. Zabbix. 

 
 
 
 
 
 
 
 
 
 
 

 

 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

 
 

ABSTRACT 

 

 

With the expansion of Internet and technology, it became essential to use 
mechanisms for the control and management of the infrastructure of computer 
networks and systems that store information. Therefore, this monograph aims to 
present a project that allows control and monitor assets in geographically units 
distributed from a central node. Because of that, it is estimated that a network 
administrator can identify and prevent potential critical points of network failures 
proactively taking greater control over the assets monitored and can dimension better 
the technologies used and to plan future expansion if needed. Therefore, it was 
proposed to study the network infrastructure in Costaneira S/A company, with 
headquarters in Lajeado – RS and branches distributed throughout the state. The 
methodology of this study involved conceptualizing the principles and protocols used 
for network management, describe the scenario of the suggested company, analyze 
and compare some of the open source solutions commonly used in this area of 
search, deploy the solution best adapted to the environment company, evaluate and 
discuss the results and propose improvements. 

 

Keywords: Network management. Network management protocols. Network 
management software. Zabbix. 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

 

 

 

 

 

 

LISTA DE FIGURAS 

 

 

Figura 1 - Modelo de gerenciamento de redes .......................................................... 24 

Figura 2 -  Áreas-chave de um gerenciamento de redes .......................................... 25 

Figura 3 - Modelo de gerenciamento centralizado .................................................... 32 

Figura 4 - Modelo de gerenciamento distribuído. ...................................................... 32 

Figura 5 - Interação entre o gerente e um agente ..................................................... 35 

Figura 6 - Árvore MIB ................................................................................................ 36 

Figura 7 - Configurações do serviço SNMP em um ambiente Windows 7. ............... 38 

Figura 8 - Arquitetura de gerenciamento de redes utilizando o protocolo SNMP. ..... 39 

Figura 9 - Arquitetura de gerenciamento SNMP ........................................................ 42 

Figura 10 - Formato SNMP ....................................................................................... 43 

Figura 11 - Formato da mensagem de Requisições do SNMP. ................................ 46 

Figura 12 - Formato da mensagem de resposta. ...................................................... 46 

Figura 13 - Formato de mensagem de Trap no SNMPv1. ......................................... 47 

Figura 14 - Sequência do PDU SNMP. ..................................................................... 48 

Figura 15 - Arquitetura SNMPv2. .............................................................................. 50 

Figura 16 - Formato de mensagem PDU do SNMPv2. ............................................. 51 

Figura 17 - Evolução do SNMP. ................................................................................ 54 

Figura 18 - Arquitetura de uma entidade SNMPv3 .................................................... 55 

Figura 19 - Formato de mensagem SNMPv3 ............................................................ 56 

Figura 20 - Imagem de um gráfico gerado pelo MRTG. ............................................ 60 

Figura 21 - Imagem de um gráfico gerado pelo RRDTool ......................................... 61 

Figura 22 - Informações de host no NTop ................................................................. 62 

Figura 23 - Tela do software Nagios ......................................................................... 64 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

 
 

Figura 24 - Tela de gráficos do software Cacti .......................................................... 65 

Figura 25 - Interface do OpenNMS ........................................................................... 66 

Figura 26 - Interface do Pandora FMS ...................................................................... 67 

Figura 27 - Interface do Zabbix ................................................................................. 69 

Figura 28 - Interface do Zenoss ................................................................................ 70 

Figura 29 - Cenário da administração central da Costaneira .................................... 76 

Figura 30 - Cenário das filiais da Costaneira ............................................................ 77 

Figura 31 - Tipos de abordagens do Zabbix .............................................................. 80 

Figura 32 - Diagrama de operação do Zabbix utilizando proxies .............................. 81 

Figura 33 - Componentes do Zabbix Server ............................................................. 82 

Figura 34 - Fluxograma de operação do Zabbix........................................................ 83 

Figura 35 - Modelo proposto de implantação do Zabbix ........................................... 85 

Figura 36 - Tela de templates personalizados........................................................... 88 

Figura 37 - Regra de auto busca para descoberta de interfaces de rede ................. 89 

Figura 38 - Monitoramento JMX na empresa Costaneira .......................................... 90 

Figura 39 - Monitoramento do banco de dados PostgreSQL .................................... 91 

Figura 40 - Tela de ações do Zabbix ......................................................................... 92 

Figura 41 - Tela de status do Zabbix ......................................................................... 94 

Figura 42 - Gráfico de porcentagem de processos de coleta de dados ocupados no 

Zabbix ....................................................................................................................... 97 

Figura 43 - Fila de itens a serem atualizados por proxy usando configurações padrão

 .................................................................................................................................. 97 

Figura 44 - Fila de itens a serem atualizados por proxy após ajustes de 

configurações ............................................................................................................ 98 

Figura 45 - Gráfico de performance do servidor Zabbix ............................................ 98 

Figura 46 - Comparativo de tráfego de rede na interface do Zabbix antes e depois de 

sua implantação ........................................................................................................ 99 

Figura 47 - Comparativo de tráfego de rede na interface da VPN na administração 

central antes e depois da implantação do Zabbix ................................................... 100 

Figura 48 - Comparativo de tráfego de rede antes e depois da implantação do Zabbix 

na interface do Zabbix Proxy em uma filial remota .................................................. 100 

Figura 49 - Comparativo de tráfego de rede antes e depois da implantação do Zabbix 

na interface da VPN em uma filial remota ............................................................... 101 

Figura 50 - Consumo de CPU e memória do Zabbix ............................................... 102 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

 
 

Figura 51 - Consumo de CPU e memória do Zabbix Prox. ..................................... 102 

Figura 52 - Consumo de CPU do servidor Zabbix sem monitoramento x com 

monitoramento ........................................................................................................ 103 

Figura 53 - Consumo de CPU do Zabbix Proxy sem monitoramento x com 

monitoramento ........................................................................................................ 104 

Figura 54 - Gráfico de tráfego de rede do link ADSL de uma filial remota .............. 105 

Figura 55 - Tela contendo gráficos de tráfego de rede em todas as interfaces de um 

servidor ................................................................................................................... 105 

Figura 56 - Mapa contendo elementos de um grupo de host .................................. 106 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

 

 

 

 

 

 

LISTA DE QUADROS 

 

 

Quadro 1 - Definição e objetivos das técnicas de polling e event-reporting. ............. 29 

Quadro 2 - Descrição dos controles de segurança e configuração. .......................... 29 

Quadro 3 - Tipos de objetos da MIB. ......................................................................... 36 

Quadro 4 - Controles suportados de uma MIB. ......................................................... 37 

Quadro 5 - Mensagens SNMP .................................................................................. 43 

Quadro 6 - Tipos e descrições de PDUs ................................................................... 51 

Quadro 7 - Códigos de erros do SNMPv2 ................................................................. 52 

Quadro 8 - Componentes do protocolo SNMPv3 ...................................................... 54 

Quadro 9 - Campos utilizados em uma mensagem SNMPv3 ................................... 56 

Quadro 10 - Comparativo entre softwares de Gerenciamento .................................. 71 

Quadro 11 - Informações dos links na administração da Costaneira ........................ 74 

Quadro 12 - Informações dos links nas filiais da Costaneira ..................................... 77 

Quadro 13 - Equipamentos gerenciados x risco ao negócio ..................................... 78 

Quadro 14 - Equipamentos a serem monitorados ..................................................... 79 

Quadro 15 - Comparativo entre monitoramento em node e monitoramento baseado 

em proxy do Zabbix ................................................................................................... 80 

Quadro 16 - Parâmetros alterados no arquivo de configuração do Zabbix Server .... 86 

Quadro 17 - Parâmetros alterados no arquivo de configuração do Zabbix Proxy ..... 87 

Quadro 18 - Parâmetros alterados no arquivo de configuração dos agentes Zabbix 87 

Quadro 19 - Fórmula para estimar o espaço em disco do Zabbix ............................. 94 

Quadro 21 - Comparativo de ativos e serviços monitorados antes e depois da 

implantação do Zabbix ............................................................................................ 107 

 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

 

 

 

 

 

 

LISTA DE ABREVIATURAS 

 

 

ASN.1   Abstract Syntax Notation One 

CMOT            Common Management Information Protocol Over Tcp/IP 

CPU              Central Processing Unit 

GPL  General Public License 

HMP  Host Monitoring Protocol 

HTML  HyperText Markup Language  

IP  Internet Protocol 

IPv4  Internet Protocol version 4 

IPv6  Internet Protocol version 6 

ISO  International Organization for Standarization 

JMX  Java Management Extensions 

JSON  Javascript Object Notation 

LAN  Local Area Network 

LDAP  Lightweight Directory Access Protocol 

MIB  Management Information Base 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

 
 

MRTG            Multi Router Traffic Grapher 

NMP  Network Management Protocol 

OID  Object Identifier 

OSI  Open Systems Interconnection 

PDU  Protocol Data Unit 

RFC  Request for Comments 

RMON Remote Network Monitoring 

RRDTOOL Round Robin Database Tool 

ICMP  Internet Control Message Protocol 

SLA  Service-Level Agreement 

SGMP Simple Gateway Monitoring Protocol 

SMI  Structure of Management Information 

SNMP  Simple Network Management Protocol 

SMS  Short Message Service 

TI  Tecnologia da Informação 

TCP  Transmission Control Protocol 

UDP  User Datagram Protocol 

USM  User-based Security Model 

VACM  View-based Access Control Mode 

VPN  Virtual Private Network 

XMPP  Extensible Messaging and Presence Protocol 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

 

 

 

 

 

 

SUMÁRIO 

 
1 INTRODUÇÃO ....................................................................................................... 17 
1.1 Motivação ........................................................................................................... 19 
1.2 Objetivos ............................................................................................................ 21 

1.2.1 Objetivos Gerais ............................................................................................. 21 

1.2.2 Objetivos Específicos .................................................................................... 21 

1.3 Descrição dos Capítulos ................................................................................... 22 

 
2 CONCEITOS BÁSICOS DE GERÊNCIA DE REDES ............................................ 23 

2.1 A importância do gerenciamento de redes ..................................................... 23 
2.2 Áreas de gerenciamento ................................................................................... 25 
2.2.1 Gerenciamento de Configuração .................................................................. 25 

2.2.2 Gerenciamento de Contabilidade ................................................................. 26 

2.2.3 Gerenciamento de Desempenho ................................................................... 26 

2.2.4 Gerenciamento de Falhas .............................................................................. 26 

2.2.5 Gerenciamento de Segurança ....................................................................... 27 

2.3 Monitoramento e controle da rede ................................................................... 28 

2.3.1 Monitoramento ............................................................................................... 28 

2.3.2 Controle de Rede ............................................................................................ 29 

2.4 Arquitetura do Gerenciamento de Redes ........................................................ 30 
2.4.1 Estação de gerenciamento ............................................................................ 30 

2.4.1.1 Gerenciamento centralizado ...................................................................... 31 

2.4.1.2 Gerenciamento distribuído ......................................................................... 32 

2.4.2 Agentes coletores .......................................................................................... 33 

2.4.3 Management Information Base (MIB) ........................................................... 34 

2.4.3.1 Tipos de objetos da MIB ............................................................................. 36 

2.4.3.2 Controle de acesso aos valores da MIB .................................................... 37 

 
3 PROTOCOLO SNMP ............................................................................................. 39 
3.1 Structure of Management Information (SMI) ................................................... 40 
3.2 Protocolo SNMPv1 ............................................................................................ 41 
3.2.1 Arquitetura do protocolo SNMPv1 ................................................................ 41 

3.2.2 Formato da mensagem SNMPv1 ................................................................... 43 

3.2.3 Transmissão de uma mensagem SNMPv1 ................................................... 44 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

 
 

3.2.4 Recepção de uma mensagem SNMPv1 ........................................................ 44 

3.2.5 Variable bindings do protocolo SNMPv1 ..................................................... 45 

3.2.6 GetRequest PDU do protocolo SNMPv1 ....................................................... 45 

3.2.7 GetNextRequest PDU do protocolo SNMPv1 ............................................... 46 

3.2.8 SetRequest PDU do protocolo SNMPv1 ....................................................... 47 

3.2.9 Trap PDU do protocolo SNMPv1 ................................................................... 47 

3.2.10 Limitações do protocolo SNMPv1............................................................... 48 

3.3 Protocolo SNMPv2 ............................................................................................ 49 

3.3.1 Arquitetura do protocolo SNMPv2 ................................................................ 49 

3.3.2 Formato da mensagem do protocolo SNMPv2 ............................................ 51 

3.3.3 Limitações do protocolo SNMPv2 ................................................................ 53 

3.4 Protocolo SNMPv3 ............................................................................................ 53 
3.4.1 Arquitetura do protocolo SNMPv3 ................................................................ 54 

3.4.2 Formato da mensagem do protocolo SNMPv3 ............................................ 55 

3.4.3 Segurança e controle de acesso do protocolo SNMPv3 ............................. 57 

 
4 FERRAMENTAS DE GERENCIAMENTO E MONITORAMENTO DE REDES ..... 59 
4.1 MRTG .................................................................................................................. 60 

4.2 RRDTool ............................................................................................................. 60 
4.3 NTOP .................................................................................................................. 61 

4.4 Nagios ................................................................................................................ 62 
4.5 Cacti.................................................................................................................... 65 
4.6 OpenNMS ........................................................................................................... 66 

4.7 Pandora FMS ..................................................................................................... 67 
4.8 Zabbix ................................................................................................................. 67 

4.9 Zenoss ................................................................................................................ 69 
4.10 Comparativo entre as ferramentas de gerenciamento ................................. 71 
4.11 Análise dos resultados obtidos ..................................................................... 71 

 
5 PROPOSTA ........................................................................................................... 73 
5.1 Caracterização da empresa .............................................................................. 73 

5.1.1 Infraestrutura de TI ......................................................................................... 74 

5.1.2 Administração Central ................................................................................... 74 

5.1.3 Centro de Distribuição ................................................................................... 76 

5.1.4 Filiais ............................................................................................................... 76 

5.1.5 Análise do ambiente....................................................................................... 78 

5.2 Modelo de implantação do Zabbix ................................................................... 79 

5.3 Componentes do Zabbix ................................................................................... 82 
5.4 Fluxo de operação do Zabbix ........................................................................... 83 

5.5 Cenário proposto .............................................................................................. 84 
5.6 Uso de templates personalizados .................................................................... 88 

5.7 Uso de regras de auto busca ........................................................................... 89 
5.8 Monitoramento de aplicações Java ................................................................. 90 
5.9 Monitoramento do banco de dados PostgreSQL ........................................... 91 

5.10 Monitoramento proativo ................................................................................. 92 
 
6 RESULTADOS OBTIDOS ..................................................................................... 93 
6.1 Equipamentos monitorados ............................................................................. 93 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

 
 

6.2 Cálculo para estimativa do banco de dados Zabbix ...................................... 94 
6.3 Performance ...................................................................................................... 96 
6.4 Consumo de banda de rede ............................................................................. 98 
6.5 Consumo de CPU e memória ......................................................................... 101 
6.7 Formas de análise dos itens coletados ......................................................... 105 

6.8 Comparativo de ativos monitorados antes e depois da implantação do 
Zabbix ..................................................................................................................... 106 
 
7 CONSIDERAÇÕES FINAIS ................................................................................. 108 
7.1 Trabalhos Futuros ........................................................................................... 110 

 
REFERÊNCIAS ....................................................................................................... 111 
 
 
 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

17 

1 INTRODUÇÃO 

 

 

O surgimento das redes de computadores, em meados da década de 60, 

marcou o início de uma era digital, na qual a informação tornaria-se um bem 

intangível extremamente valioso não somente para a competitividade econômica, 

como também para aspectos sociais, culturais, governamentais, entre outros. Neste 

período inicial, as redes de computadores eram limitadas apenas para o uso militar 

ou universidades. Pelo fato de serem relativamente simples e pequenas, com 

poucos nós e distribuídas localmente, a necessidade de gerenciamento era mínima, 

podendo ser efetuada de forma centralizada.  

Alguns protocolos de gerenciamento foram inicialmente implementados na 

década de 70, como o Internet Control Message Protocol (ICMP), que possibilitava a 

troca de mensagens entre roteadores e hosts, permitindo que houvesse uma 

interação entre ambas as partes, a fim de monitorar o status da comunicação por 

meio de mensagens de echo/echo reply (STALLINGS, 1999). 

A partir da década de 80, com a expansão do Transmission Control Protocol 

over Internet Protocol(TCP/IP), as redes de computadores passaram a ser mais 

difundidas, e, com isso, aumentou a necessidade de mecanismos para o 

gerenciamento das mesmas. Alguns protocolos surgiram nessa época como o Host 

Monitoring Protocol (HMP), Simple Gateway Monitoring Protocol (SGMP), que mais 

tarde foi substituído pelo Simple Network Management Protocol (SNMP) e o 

Common Management Information Protocol Over Tcp/IP (CMOT) (STALLINGS, 

1999). 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

18 

Desde então, as redes de computadores tornaram-se extremamente 

complexas. É possível interligar dispositivos dos mais diversos tipos e funções como 

smartphones, câmeras de vigilância, impressoras, notebooks, servidores, entre 

outros, não apenas limitando-os em áreas locais, como também geograficamente 

distribuídas, inclusive entre continentes.  

Alguns aspectos comuns que afetam a infraestrutura de Tecnologia da 

Informação (TI) nas organizações e podem acarretar algum tipo de perda, seja 

financeira ou de informação, são a contaminação por vírus, a indisponibilidade de 

algum serviço como o acesso à Internet, hardware com defeito, queda de luz, entre 

outros.           

Com isso, cinco áreas de gerência de redes foram definidas pela 

 International Organization for Standardization/International Electrotechnical 

Comission (ISO/IEC 10040,1998), são elas:  

a) gerenciamento de configuração; 

b) gerenciamento de contabilidade; 

c) gerenciamento de desempenho; 

d) gerenciamento de falhas; 

e) gerenciamento de segurança. 

Essas áreas provêm medidas que devem ser tomadas para um melhor 

gerenciamento da área de redes, favorecendo, assim, a qualidade e disponibilidade 

dos serviços aos quais estão relacionados.  

Ao passo que uma rede se torna geograficamente distante, sua complexidade 

em relação à infraestrutura e o gerenciamento aumenta de tal forma que é 

imprescindível utilizar algum mecanismo automatizado para auxiliar no seu controle 

e monitoramento. É nesse ponto que muitas soluções em forma de software 

surgiram e muitas delas utilizam características semelhantes que visam, no mínimo: 

a) monitoramento distribuído com um gerenciamento centralizado: Toda a    

informação de um host monitorado é coletada através de um software agente 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

19 

(remoto, local ou móvel) e armazenada em uma estação de gerenciamento, 

sendo possível visualizar as informações através de um browser, utilizando o 

modelo Web-based; 

b)  proatividade: os agentes monitores devem ter a capacidade de prever 

situações adversas baseadas em eventos, estatísticas, entre outros, e, 

através disso, executarem alguma ação visando alertar, amenizar e/ou corrigir 

o problema; 

c) eficiência e disponibilidade: a arquitetura de um software de gerenciamento 

deve otimizar ao máximo o uso dos recursos computacionais, de forma que o 

mesmo possa garantir disponibilidade adequada aos serviços geridos com o 

máximo de eficiência; 

d) integração e customização: capacidade de integração com outros serviços e 

possibilidade de customizar novas funcionalidades; 

e) segurança: controle de acesso e permissões para executar determinadas 

ações. 

Logo, busca-se atingir cada vez mais níveis de maturidade quanto à 

governança de TI, melhorando o serviço prestado, garantindo a disponibilidade, 

aumentando a eficiência e alinhando os requisitos de TI com os requisitos do 

negócio, agregando valor ao mesmo. 

 

1.1 Motivação 

 

Para quem trabalha na área de administração de redes ou entende da 

importância de manter os ativos em condições de propiciar uma disponibilidade de 

serviço aos seus utilizadores, sabe dos riscos expostos ao negócio quando ele está 

defeituoso ou indisponível.  

Na empresa Costaneira, a infraestrutura de redes de computadores está 

distribuída entre nove filiais, mais o prédio da administração e o centro de 

distribuição. As ferramentas utilizadas para o gerenciamento e monitoramento da 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

20 

rede mostram-se ineficientes, pois atendem a uma pequena parcela do que poderia 

ser gerenciado. Dessa forma, quando algum problema surge, muitas vezes sua 

identificação demora a ser detectada e consequentemente corrigida, acarretando em 

problemas de indisponibilidade de serviços que são essenciais para a empresa. 

Por causa de limitações tecnológicas na época em que foi iniciado o 

desenvolvimento do sistema de gestão interno da empresa, em meados de 2005, 

houve a necessidade de utilizar servidores fisicamente alocados em cada uma das 

filiais, contendo uma cópia do banco de dados principal que, através de um sistema 

complexo de replicação, pudesse garantir a consistência das informações ali 

contidas para todas as empresas afiliadas. Portanto, a disponibilidade do link de 

Internet na empresa é imprescindível para que este processo funcione de forma 

satisfatória, evitando possíveis problemas de inconsistência e perda de dados. Vale 

ressaltar, também, que diversos setores da empresa são prejudicados quando não é 

possível acessar a Internet - como a área de vendas - por não poderem emitir notas 

fiscais eletrônicas, solicitar liberações de crédito, entre outros fatores.     

Outra questão que merece relevância é o gerenciamento dos servidores 

localizados em cada uma das filiais. Pelo fato de os usuários utilizarem terminais thin 

client, todas as informações pertinentes a eles estão armazenadas no servidor local, 

além, como já mencionado, do banco de dados da aplicação e arquivos de projetos 

de móveis específicos para cada cliente. Caso aconteça algum problema com o 

servidor em uma filial que não possa ser corrigido remotamente, provavelmente 

determinará o deslocamento de um integrante da equipe de suporte até aquela filial, 

para avaliar e buscar uma solução. Durante esse período, a ameaça gerou um 

grande risco de a loja ficar parada em termos de acesso aos sistemas, 

impossibilitando ou dificultando as vendas e, consequentemente, trazendo 

problemas ao negócio. 

Utilizar um software que possa gerenciar todos os nós da rede, mesmo estes 

estando em locais geograficamente distribuídos, armazenando e apresentando as 

informações obtidas em um nó central, de forma que o gerenciamento torne-se 

eficiente e eficaz, é o principal estímulo desse trabalho, bem como uma grande 

motivação da área de TI da empresa Costaneira. Dessa forma, o adminsitrador de 

redes poderá dispor de uma ferramenta completa de gerenciamento, capaz de 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

21 

monitorar, prevenir, detectar e/ou corrigir determinadas falhas que, do ponto de vista 

do negócio, podem acarretar perdas significativas. 

 

1.2 Objetivos 

 

1.2.1 Objetivos Gerais 

 

O objetivo desse trabalho é apresentar uma proposta de gerenciamento de 

unidades geograficamente distribuídas a partir de um nó central, atendendo aos 

conceitos teóricos e padrões de arquitetura necessários para obter o grau de 

excelência na área de gerenciamento de redes.  

  

1.2.2 Objetivos Específicos 

 

No que toca aos objetivos específicos, pretende-se demonstrar que é possível 

implantar uma solução definitiva para o problema de gerenciamento de ativos e 

serviços de rede, de forma eficiente, utilizando poucos recursos computacionais e de 

comunicação de dados, e que seja passível de monitorar qualquer equipamento ou 

serviço, de forma proativa, sem a necessidade de investimentos em software 

proprietário.  

Para que isso seja satisfeito, será necessário compreender metodologias, 

protocolos e conceitos envolvidos no monitoramento de redes, bem como o 

planejamento de estratégias para o controle e gerenciamento das mesmas. 

Assim, espera-se não só melhorar a qualidade e disponibilidade dos serviços 

de TI do ambiente monitorado, reduzindo as taxas de incidentes, como também 

poder analisar padrões para melhorar o desempenho dos diversos componentes que 

englobam a infraestrutura de TI, e verificar tendências para planejar futuras 

expansões, contribuindo para o sucesso do negócio como um todo.   

Também é esperado que essa proposta seja útil a todos que estejam 

buscando algum software que os auxiliem na gerência de suas redes, de forma que 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

22 

possam  concentrar seus esforços em melhorias para a infraestrutura das mesmas, 

e, ao mesmo tempo, terem a capacidade de identificar, prevenir e remediar 

determinados problemas comuns às redes de computadores, de forma centralizada, 

mesmo apresentando um cenário distribuído.  

 

1.3 Descrição dos Capítulos 

 

O presente trabalho está estruturado da seguinte forma: no Capítulo 2 é feita 

uma introdução sobre os conceitos básicos da gerência de redes, as áreas 

funcionais de gerenciamento, definição de monitoramento e controle e uma breve 

introdução à arquitetura de gerência de redes. No Capítulo 3 é contextualizado o 

protocolo de gerenciamento de redes, o SNMP, em suas três versões: SNMPv1, 

SNMPv2 e SNMPv3. Já no Capítulo 4 são apresentadas algumas ferramentas em 

nível de software, que auxiliam no gerenciamento de redes. Também é feito um 

comparativo entre essas ferramentas e uma análise dos resultados obtidos. O 

Capítulo 5 é destinado a abordar a proposta de implantação do software Zabbix na 

empresa analisada, verificando o cenário de TI da mesma, itens com maior 

necessidade de gerenciamento, entre outros fatores. No Capítulo 6 discute-se os 

resultados obtidos com a implantação do software referido, fazendo uma análise do 

cenário antes e depois de sua implementação e o impacto que o mesmo causou na 

rede da empresa.  



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

23 

2 CONCEITOS BÁSICOS DE GERÊNCIA DE REDES 

 

 

Uma rede de computadores pode ser definida como um meio de interligar 

recursos físicos e lógicos entre dois ou mais computadores. Tais recursos podem 

ser o compartilhamento de uma impressora, arquivos, unidades de discos, entre 

outros. Por existirem inúmeros dispositivos capacitados para interligarem-se em 

ambientes tanto homogêneos como heterogêneos, e pelo crescimento das redes de 

computadores, existe a necessidade de gerenciar todos esses recursos. 

Esse capítulo apresenta os conceitos envolvidos na gerência de redes, 

mostrando na seção 2.1 a sua importância em um cenário organizacional. Já a 

seção 2.2 descreve as áreas funcionais envolvidas no gerenciamento de acordo com 

a ISO/IEC 10040 (1998). A seção 2.3 caracteriza o monitoramento e controle de 

rede e a seção 2.4 caracteriza a arquitetura envolvida no gerenciamento da mesma. 

 

2.1 A importância do gerenciamento de redes 

 

O papel fundamental da gerência de redes de computadores é controlar o seu 

uso a fim de garantir um funcionamento adequado aos seus usuários (SANTOS, 

2004). Maximizar a eficiência e a produtividade da mesma pode se tornar uma tarefa 

difícil, uma vez que se tem cenários cada vez mais complexos, aglomerando 

inúmeros ativos, tanto físicos (hardware) como lógicos (software), em pontos 

distribuídos da rede. Por esta razão, o profissional responsável pela administração 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

24 

da rede de computadores, em uma organização, deve dispor de formas 

automatizadas para monitorar e controlar a parte física e a parte lógica da rede. 

Ter um software de gerenciamento é essencial, porém, é necessário que o 

administrador conheça bem cada item que deseja monitorar e o que este representa 

em um contexto geral da rede (SPECIALSKI, [2002]). Caso ele não tenha muito 

conhecimento, provavelmente deixará de obter os melhores resultados, uma vez que 

são inúmeros os padrões e as características envolvidas nos objetos gerenciados.  

De acordo com Carvalho e Brisa (1993), um esquema de gerenciamento deve 

conter algumas características, tais como: 

a) gerenciamento da rede como parte integral dela mesma; 

b) conter todas as informações sobre a rede, estatísticas, eventos, entre outros 

devem dispor de um meio centralizado de visualização, de modo que seja 

facilmente compreendido através de gráficos, por exemplo;  

c) haver mecanismos de prioridades sobre mensagens de controle de rede 

quanto a outros tipos de tráfego; 

d) ter mecanismos de segurança e detecção de acesso não autorizado; 

e) conter em um banco de dados as informações referentes aos componentes 

da rede e seus usuários; 

f) o funcionamento dos processos referentes ao gerenciamento, independente 

do meio de transmissão; 

g) a implementação de forma simples e flexível de qualquer alteração na rede. 

Figura 1 - Modelo de gerenciamento de redes 

 

Fonte: Santos et al. (2003, p. 122). 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

25 

2.2 Áreas de gerenciamento 

 

Segundo disposto pela ISO/IEC 10040 apud Azevedo ([2009?], texto digital)        

“o gerenciamento de redes provê mecanismos para monitoração, controle e 

coordenação de recursos em um ambiente OSI e define padrões do protocolo OSI 

para troca de informações entre estes recursos”. Através deste entendimento, foram 

estabelecidas cinco áreas da gerência de redes que possuem necessidade de 

gerenciamento: configuração, contabilidade, desempenho, falhas e segurança 

(Figura 2). Cada uma destas áreas será analisada a seguir. 

Figura 2 -  Áreas-chave de um gerenciamento de redes 

 
Fonte: Bonomo (2006, p. 7). 

 

2.2.1 Gerenciamento de Configuração 

 

Essa área é responsável por todas as mudanças relacionadas à estrutura 

física e lógica da rede. Ela efetua a descoberta de elementos, coleta as suas 

informações de configuração, adiciona, mantém e atualiza os mesmos, além de 

descobrir interconectividade entre os objetos gerenciados. Também é responsável 

por manter um inventário atualizado, registrando informações de configurações, 

gerando eventos e relatórios, quando necessário, uma vez que todos os itens 

gerenciados iniciam e terminam nessa etapa (SPECIALSKI, [2002]). 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

26 

2.2.2 Gerenciamento de Contabilidade 

 

O gerenciamento de contabilidade é utilizado para analisar, mensurar e limitar 

os recursos da rede por usuários ou grupo de usuários, garantindo, assim, a sua 

utilização de forma correta, ou seja, sem abuso de privilégios de acessos ou 

consumo exagerado desses recursos por parte dos usuários. São efetuadas coletas 

de utilização da rede para conhecer o perfil dos usuários, fornecendo detalhes 

suficientes para planejar o crescimento da mesma. O gerente de redes pode ainda 

limitar o uso de certos recursos por usuários e/ou grupos de usuários quando 

verificar o abuso por parte destes de seus privilégios. 

 

2.2.3 Gerenciamento de Desempenho 

 

Consiste em analisar, monitorar e planejar a capacidade da rede de acordo 

com o seu desempenho. É útil, pois mantém a qualidade do serviço, utilizando 

indicadores de desempenho que analisam, entre outros fatores, a existência de 

gargalos, se o tráfego é excessivo, ou se o nível de capacidade de utilização é 

aceitável  (SPECIALSKI, [2002]). 

Com isso é possível prevenir situações adversas antes que estas causem 

problemas para o usuário final, efetuando as devidas correções de forma proativa, 

ou ainda, indicando a necessidade de futuras expansões da rede. 

 

2.2.4 Gerenciamento de Falhas 

 

Esse gerenciamento fica a cargo de notificar, isolar e consertar falhas que 

ocasionam prejuízos ou indisponibilidade do fluxo normal da rede. Segundo 

Specialski ([2002], p. 3) “uma falha normalmente é causada por operações 

incorretas ou um número excessivo de erros”. Quando isso ocorre, caso não seja 

gerenciado, dependendo do nível da falha, poderá gerar indisponibilidade de 

serviços que podem ser cruciais para o negócio de uma empresa, acarretando, 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

27 

assim, prejuízos financeiros a esta. Por isso, quando uma falha ocorrer, é necessário 

possuir um mecanismo que propicie (SPECIALSKI, [2002]): 

a) determinar a origem da falha; 

b) isolar a falha, deixando a rede funcional (sem interferências); 

c) reorganizar a rede de modo que o impacto do componente que falhou seja 

mínimo para a estrutura geral; 

d) providenciar o reparo ou a troca do elemento que acarretou a falha, 

restaurando, assim, seu estado anterior. 

É interessante utilizar elementos redundantes, tanto para equipamentos 

quanto para rotas de comunicação, pois isso gera um impacto minimizado quando 

ocorre uma falha, gerando certo nível de tolerância a falhas (SPECIALSKI, [2002]). 

 

2.2.5 Gerenciamento de Segurança 

 

De acordo com Carvalho e Brisa (1993), o gerenciamento de segurança 

assegura os dados da rede desde a proteção de senhas, utilizando a criptografia, 

até a obrigatoriedade de alteração periódica das mesmas. Dessa forma, informações 

pertinentes aos usuários devem ser acessadas somente por quem estiver 

autorizado. 

Segundo Specialski ([2002]), o gerenciamento de segurança trata de 

questões como:  

a) gerar, distribuir e armazenar chaves de criptografia; 

b) manter e distribuir senhas e mecanismos de controle de acesso; 

c) monitorar e controlar o acesso aos nodos da rede e suas informações; 

d) coletar, armazenar e examinar logs de auditoria e segurança, permitindo 

ativar/desativar estas atividades.  



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

28 

2.3 Monitoramento e controle da rede 

 

Para que se tenha um ambiente de rede gerenciável, deve-se destacar duas 

categorias: monitoramento e controle da rede. Conforme Specialski ([2002]), o 

monitoramento da rede é uma função de “leitura”, pois esta tem como finalidade 

observar e analisar o estado e configuração da rede. Já o controle da rede, por 

englobar tarefas como alterações de valores de algum parâmetro ou executar 

determinada ação, é considerado uma função de “escrita”. Abaixo serão descritas 

algumas funções pertinentes a cada uma destas categorias. 

 

2.3.1 Monitoramento  

 

Consoante Stallings (1999), as informações disponíveis para monitoramento 

de rede podem ser classificadas em três categorias: 

a) estática: informações geralmente pouco ou nada modificadas. Informa a 

configuração atual e os elementos que estão envolvidos nessa configuração, 

tal como número de portas de um switch ou roteador; 

b) dinâmica: provê informações relacionadas com eventos na rede como, por 

exemplo, a transmissão de um pacote na rede; 

c) estatística: normalmente derivada de informações dinâmicas, possibilitando a 

verificação de estatísticas sobre determinado item, tal como a média de 

pacotes transmitidos por unidade de tempo provinda de algum sistema.  

Também são utilizadas duas técnicas para disponibilizar as informações 

vindas dos agentes para o gerente. Essas técnicas são chamadas de polling e 

event-reporting e seus conceitos estão definidos conforme o Quadro a seguir: 

 

 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

29 

Quadro 1 - Definição e objetivos das técnicas de polling e event-reporting. 

TÉCNICA DESCRIÇÃO OBJETIVOS 

Polling Gerente solicita alguma 

informação (pesquisa, estrutura, 

variável, etc) da MIB de um 

agente e este responde com as 

informações pertinentes.  

 

- Aprendizado sobre configuração de algum 

item gerenciado; 

- Informação sobre condição de algum item 

gerenciado; 

- Informações periódicas para melhor 

detalhamento de alguma área crítica. 

Event-

reporting 

Agente gera relatórios periódicos 

e envia para o gerente. Gerente 

fica apenas aguardando as 

informações recebidas.  

- Relatório sobre estado atual de um agente; 

- Relatório sobre algum evento importante ou 

não habitual; 

- Detectar problemas assim que ocorrerem. 

Fonte: Adaptado pelo autor com base em Stallings (1999, p. 27 a 29). 

 

2.3.2 Controle de Rede 

 

A área de controle de redes está diretamente ligada à questão de modificação 

de parâmetros de variáveis e execução de ações em um sistema gerenciado. De 

acordo com as cinco áreas do gerenciamento de redes (configuração, 

contabilização, desempenho, falhas e segurança) definidas pela ISO/IEC 10040 

(1998), o controle de redes está voltado mais ao gerenciamento de configuração e 

segurança, enquanto o monitoramento de redes está direcionado aos outros 

elementos restantes. 

Os aspectos mais relevantes sobre gerência de configuração e de segurança, 

conforme Specialski ([2002]), são descritos conforme segue (Quadro 2): 

Quadro 2 - Descrição dos controles de segurança e configuração. 

CONTROLE FUNÇÃO 

Configuração - Definir informações de configuração para os recursos e seus atributos sujeitos ao 

gerenciamento; 

- Atribuir, modificar e examinar valores de parâmetros; 

- Definir, modificar e examinar a relação entre recursos/componentes da rede; 

- Iniciar/Parar as operações de rede; 

- Relatório de status de configuração. 

CONTINUA 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

30 

CONCLUSÃO 

CONTROLE FUNÇÃO 

Segurança - Manter a informação segura; 

- Controlar o acesso aos recursos; 

- Controlar o processo de criptografia. 

Fonte: Specialski ([2002], p. 6). 

Quanto ao controle de segurança, vale ressaltar que as principais ameaças 

relacionadas à segurança vêm de aspectos como interrupção, interceptação, 

modificação e mascaramento. Com isso, os objetivos principais da segurança em 

redes é manter a confidencialidade, integridade e disponibilidade de seus serviços 

(STALLINGS, 1999). 

 

2.4 Arquitetura do Gerenciamento de Redes 

 

Em conformidade com Stallings (1999), para gerenciar uma rede que usa o 

protocolo TCP/IP é necessário especificar os seguintes elementos: 

a) estação de gerenciamento ou gerente; 

b) agentes coletores; 

c) Management Information Base (MIB); 

d) protocolo de gerenciamento de redes (SNMP). 

As próximas subseções destinam-se a descrever cada um destes elementos. 

 

2.4.1 Estação de gerenciamento 

 

Um gerente SNMP capta as informações fornecidas pelos seus agentes 

através das MIB’s e serve como modelo de interação homem-máquina, através de 

uma interface, via aplicação, possibilitando que o administrador da rede possa 

visualizar, monitorar e controlar os elementos gerenciados em uma rede de 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

31 

computadores. Ele pode ser instalado tanto em um servidor dedicado, como em um 

compartilhado, e aborda alguns itens que são necessários para um gerenciamento 

mínimo, como: 

a) possuir meios para a gestão de análise de dados como gráficos e mapas, 

recuperação de falhas, log de eventos, entre outros; 

b) ter uma interface na qual o administrador possa monitorar e controlar a rede; 

c) ter capacidade de transformar os requisitos do administrador em informações 

úteis para o monitoramento e controle efetivo dos elementos na rede; 

d) conter um banco de dados para armazenar as informações extraídas dos 

objetos gerenciados (STALLINGS, 1999). 

Em um ambiente onde há necessidade de gerenciamento, pode-se classificar 

o uso dos gerentes de duas formas: centralizado e distribuído.  

 

2.4.1.1 Gerenciamento centralizado 

 

Quando utilizada a gerência centralizada, todo o fluxo de controle e 

monitoramento da rede é estabelecido em uma única estação, ou seja, pode ser 

usado um servidor dedicado, por exemplo, que será responsável pela interação 

entre os objetos gerenciados (elementos da rede), o gerente (aplicação) e a pessoa 

responsável pela administração da rede (interface). Esse tipo de arquitetura é 

normalmente indicado para redes de menor porte, por não necessitar de muita 

complexidade. 

 

 

 

 

 

 

 

 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

32 

Figura 3 - Modelo de gerenciamento centralizado 

 
Fonte: Do autor. 

 

2.4.1.2 Gerenciamento distribuído 

 

Já na gerência distribuída, o controle é feito de forma descentralizada, sendo 

este dividido em domínios de gerência, onde cada domínio é controlado por um 

gerente. Esse gerente é responsável por coletar as informações e tomar as decisões 

pertinentes ao seu domínio, e, dentro de um escopo global, existe um gerente 

principal que recebe as informações vindas de todos os seus subgerentes, 

formando, assim, uma hierarquia entre domínios. Esse modelo é mais difundido nas 

redes que se encontram geograficamente distantes (WALSH, 2008) e possuem 

equipes de suporte em cada nó gerenciado. 

Figura 4 - Modelo de gerenciamento distribuído. 

 
Fonte: Do autor. 

 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

33 

2.4.2 Agentes coletores 

 

Todos os dispositivos de uma rede que podem ser gerenciados como 

roteadores, servidores, switches, estações de trabalho, entre outros, para que seja 

satisfeita essa necessidade de gestão, devem possuir agentes SNMP em nível de 

software, que são responsáveis por todas as informações trocadas entre as 

estações de gerenciamento e os elementos gerenciados.  

De acordo com Stallings (1999), a ligação entre um gerente e seus agentes é 

estabelecida pelo protocolo Network Management Protocol (NMP), e, ao utilizar uma 

rede TCP/IP, a troca de mensagens entre os dois é feita pelo protocolo SNMP, que 

inclui algumas operações principais aplicáveis às MIBs:  

a) get: provê que o gerente possa recuperar valores dos objetos no agente;  

b) getNext: tem o mesmo princípio do get, porém, é utilizado para capturar 

valores de variáveis em tabelas da MIB onde o tamanho é desconhecido. 

Assim, é necessário utilizar um comando getNext inicial com o nome da 

tabela para capturar o seu primeiro valor e ir repetindo o comando sempre 

com a resposta do anterior para continuar a sequência, até chegar ao final, 

recuperando todos os valores;  

c) response: permite ao agente responder alguma requisição vinda do gerente. 

Após receber qualquer operação SNMP, exceto o trap, o agente executa essa 

operação, e, obtendo ou não sucesso, envia uma mensagem de resposta ao 

gerente (MELLO, 2000); 

d) set: permite que a estação de gerenciamento defina o valor dos objetos no 

agente; 

e) trap: permite que um agente possa notificar a estação de gerenciamento de 

eventos significativos (STALLINGS, 1999). 

A aplicação gerente solicita alguma informação (get) ou envia uma mensagem 

contendo uma ação (set), que deve ser tomada para o agente, e este, através do 

protocolo SNMP, se encarrega de validar, interpretar e responder às devidas 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

34 

requisições de forma que o processamento pode ser assíncrono, ou seja, as 

informações retornadas pelo agente podem não ter sido solicitadas pelo gerente, 

porém, caso o agente assumir que é algo crítico (trap), a informação é transmitida.  

A priori, um agente não deve originar mensagens SNMP, mas apenas 

respondê-las. Todavia, há casos em que um agente necessita realizar alguma 

interceptação direta no dispositivo gerenciado, por algum motivo de segurança, 

forçando-o a realizar um evento. Esse evento gera um alarme no agente, que se 

encarrega de executar alguma tarefa crítica, como reinicializar ou desligar um 

sistema, por exemplo, e agindo, assim, de modo proativo. 

Para que haja uma maior segurança na comunicação entre gerente e 

agentes, existe a possibilidade de criar comunidades SNMP, nas quais são 

explicitamente definidos quais hosts pertencerão ao grupo e somente trocarão 

informações os agentes e estações de gerenciamento pertencentes a determinada 

comunidade.  

 

2.4.3 Management Information Base (MIB) 

 

Para que um gerente e agente consigam trocar informações sobre os 

elementos gerenciados na rede é necessário que haja um padrão de nomenclatura 

para cada objeto. Dessa forma, através do protocolo SNMP, é possível interagir com 

os mesmos.  

De acordo com Comer (2007), o protocolo SNMP descreve de forma 

detalhada apenas o formato da mensagem e a codificação desta; outro padrão é 

utilizado para especificar as variáveis MIB, juntamente com a definição das 

operações de carga e armazenamento em cada variável. 

Já para Specialski ([2002]), uma MIB situada em um agente deve conter 

informações sobre a configuração e comportamento do mesmo, bem como 

parâmetros que possibilitem controlar alguma operação no nodo do agente. Da 

mesma forma, a MIB inserida no gerente também possui as informações da sua 

localização, entretanto, necessita ter informações sobre os agentes que fazem parte 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

35 

de seu domínio. A Figura 5 simboliza a interação entre um gerente e um agente, 

com suas respectivas MIBs. 

Figura 5 - Interação entre o gerente e um agente 

 

Fonte: Rocha e Serradourada (2008, p. 10). 

A versão inicial da MIB foi designada através do documento Request For 

Comments  (RFC) 1066 (MCCLOGHRIE; ROSE, 1988) e passou por um processo 

de evolução, sendo substituída pela MIB II, definida pelo RFC 1213 (MCCLOGHRIE; 

ROSE, 1991). 

Uma MIB obedece a uma regra de nomenclatura chamada Abstract Syntax 

Notation One (ASN.1) e a sua estrutura é descrita através de uma Structure of 

Management Information (SMI). Com esse modelo é possível representar, 

armazenar e transferir informações de gerenciamento, bem como criar novas MIBs.  

Quanto aos objetos de uma MIB, estes são organizados em um formato de 

árvore hierárquica e não possuem limites de expansão, tornando esse tipo de 

arquitetura flexível a mudanças.  Cada objeto também possui um identificador Object 

Identifier (OID). Este OID nada mais é do que uma sequência de inteiros que serve 

para identificar a posição do objeto inserido na árvore da MIB. Para deixar mais claro 

essa questão, a Figura 6 mostra uma árvore MIB e seus objetos. Caso seja 

necessário resgatar a posição de um objeto do tipo icmp, por exemplo, este seria 

referenciado por iso.org.dod.internet.mgmt.Icmp e seu valor seria 1.3.6.1.2.5. 

 

 

 

 

 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

36 

Figura 6 - Árvore MIB 

 

Fonte: Do autor, adaptado de Gta.ufrj (2004, texto digital). 

 

2.4.3.1 Tipos de objetos da MIB 

 

Conforme Mello (2000), uma MIB possui alguns tipos primitivos de valores 

para os objetos, dentre eles: 

Quadro 3 - Tipos de objetos da MIB. 

TIPO NOME DESCRIÇÃO 

Texto Display String Texto puro de no máximo 256 caracteres 

Contador Counter Valor numérico maior que zero que só pode 

ser incrementado. 

Medida Gauer Valor numérico que pode aumentar e diminuir. 

Inteiro Integer Valor inteiro positivo ou negativo. 

Enumerados Enumerated Value Associa um campo texto a um valor numérico. 

Tempo Time Tricks Tempo decorrido. 

Objeto Object Contém um identificador para outro objeto da 

MIB. 

CONTINUA 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

37 

CONCLUSÃO 

TIPO NOME DESCRIÇÃO 

Endereço IP IP address Endereço IP de algum dispositivo da rede. 

Endereço Físico Physical address Endereço físico de um dispositivo da rede. 

String String Cadeia de caracteres arbitrários 

Tabela Table Entradas da tabela MIB. 

Auxiliar Branch Tipos adicionais. 

Fonte: Do autor, adaptado de Mello (2000). 

 

2.4.3.2 Controle de acesso aos valores da MIB 

 

Para que se tenha maior segurança para o acesso a valores de uma MIB 

foram definidas algumas diretivas de controle para serem suportadas por ela. Tais 

diretivas estão descritas no quadro abaixo (WALSH, 2008): 

Quadro 4 - Controles suportados de uma MIB. 

Fonte: Walsh (2008). 

Outra forma de obter mais segurança é a utilização de comunidades. Assim, 

antes de qualquer interação com algum objeto da MIB, deve-se primeiro informar o 

nome comunitário do SNMP. Essa diretiva é configurada pelo próprio administrador 

da rede e garante que somente aquela comunidade cadastrada terá acesso aos 

objetos da MIB em questão (MELLO, 2000). Um exemplo disso está na Figura 7, na 

qual é apresentada uma tela de propriedades do serviço SNMP em um ambiente 

com sistema operacional Windows 7. É possível notar as configurações de controle 

de acesso, como a criação das comunidades e diretivas das mesmas. 

 

 

 

CONTROLE  SUPORTADO 

Apenas leitura Sim 

Leitura e escrita Sim 

Não acessível Sim 

Acessível para notificação Sim 

Leitura e criação Sim 

Apenas escrita Não 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

38 

Figura 7 - Configurações do serviço SNMP em um ambiente Windows 7. 

 

Fonte: Do autor. 

O próximo capítulo será destinado a uma apresentação básica do protocolo 

de gerenciamento de redes, chamado Simple Network Management Protocol 

(SNMP) e a diferenciar as suas versões. 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

39 

3 PROTOCOLO SNMP 

 

 

O SNMP é o protocolo padrão utilizado para administração de redes 

(COMER, 2007) e atualmente está na sua versão 3. Segundo o RFC 1157 (CASE et 

al., 1990), o SNMP deve especificar a forma como um gerente e os agentes devem 

se comunicar, de acordo com uma codificação de mensagem específica nomeada 

ASN.1. A (Figura 8), esboça a arquitetura de uma rede gerenciada utilizando o 

procotolo SNMP. 

Figura 8 - Arquitetura de gerenciamento de redes utilizando o protocolo SNMP. 

 

Fonte: Salvo ([2011?], texto digital). 

Em sua proposta inicial, o SNMP utilizava essas duas características 

(Stallings,1999): 

a) Structure of Management Information (SMI): estrutura única para gestão da 

informação; 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

40 

b) MIB: Estrutura global ou esquema global para o banco de dados de objetos. 

Por utilizar o modelo TCP/IP no lugar do modelo  Open Systems 

Interconnection (OSI), o SNMP tornou-se muito difundido, fato este comprovado pela 

grande implementação deste protocolo nos equipamentos de rede modernos. Desde 

a sua criação, o SNMP tem sofrido melhorias quanto à segurança, funcionalidades, 

entre outros, chegando a ser especificadas novas versões do protocolo, como a 

versão 2 e 3 (SNMPv2 e SNMPv3, respectivamente), e também extensões 

adicionais às MIBs, como o Remote Network Monitoring (RMON), versão 1 e 2, que 

visa monitoramento remoto baseado em fluxo e não somente em dispositivos.  

(MURRAY;STALVIG, 2008). 

A seção 3.1 apresenta uma definição ao SMI. Já a seção 3.2 mostrará o 

princípio de funcionamento do protocolo SNMPv1, sua arquitetura, o formato de 

envio das mensagens, bem como métodos de transmissão e recebimento das 

mesmas e suas limitações. A seção 3.3 introduz o protocolo SNMPv2 e as melhorias 

que este apresenta em relação ao seu antecessor e suas limitações. A seção 3.4 é 

destinada a apresentar a terceira versão do protocolo SNMP, o SNMPv3, com uma 

breve descrição das melhorias implementadas, principalmente no que se refere à 

segurança. 

 

3.1 Structure of Management Information (SMI) 

 

Uma SMI, ou estrutura de informação de gerenciamento, está especificada 

pelo documento RFC 1155 (MCCLOGHRIE; ROSE, 1990) e define um modelo de 

como uma MIB deve ser definida e construída. A SMI é responsável por identificar 

os tipos de dados contidos em uma MIB e especificar como os recursos desta são 

representados e nomeados. A filosofia da SMI é encorajar a simplicidade e 

extensibilidade dentro da MIB, o que gera um contraste quanto à tentativa de utilizá-

la no modelo OSI, pois este é extremamente complexo. Para fornecer uma maneira 

padronizada de representar a informação de gestão, a SMI deve fazer o seguinte: 

a) oferecer uma forma padronizada de definir a estrutura de uma MIB; 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

41 

b) utilizar uma técnica padronizada para definição de objetos individuais, como 

sintaxe e o valor de cada objeto; 

c) padronizar a codificação dos valores de objetos. 

 

3.2 Protocolo SNMPv1 

 

Os estudos abordados até esta seção sobre gerenciamento de redes nos dão 

uma visão geral do que, na prática, é o protocolo SNMP. Dentre os seus objetivos 

destacam-se (SPECIALSKI, [2002]): 

a) minimizar o número e complexidade das funções de gerenciamento; 

b) possuir flexibilidade para futuras extensões; 

c) ser independente de arquitetura e mecanismos dos dispositivos gerenciados. 

Para Rocha e Serradourada (2008, p. 22), a definição do protocolo SNMP é a 

seguinte: 

O SNMP é um protocolo de gerência definido no nível de aplicação, e 

utilizado para obter informações de servidores SNMP. Os dados são obtidos 

através de requisições de um gerente a um ou mais agentes utilizando os 

serviços do protocolo de transporte UDP (User Datagram Protocol). 

 

3.2.1 Arquitetura do protocolo SNMPv1 

 

O gerenciamento por SNMP é baseado no conceito de arquitetura 

cliente/servidor. Uma aplicação de gerenciamento contendo um software gerente é 

instalada em uma máquina tornando-se assim o servidor. O gerente pode efetuar 

duas operações básicas de gerenciamento: get e set (operam na porta 161 através 

do protocolo UDP). Essas operações fazem uma comunicação com cada dispositivo 

que será gerenciado, efetuando um polling, ou seja, requisitando algum tipo de 

informação sobre o seu estado naquele instante. Tais dispositivos (clientes) 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

42 

possuem um software agente instalado, sendo responsável por interpretar as 

requisições via SNMP-get ou SNMP-set (o get corresponde a algum tipo de 

pesquisa e o set uma alteração no parâmetro de alguma variável do objeto 

gerenciado), consultar uma base que detém todas as informações referentes ao 

objeto gerenciado (MIB), e retornar ao servidor uma mensagem SNMP (get-

response) contendo o valor da informação solicitada pelo gerente. 

O software agente pode, igualmente, gerar notificações, também conhecidas 

como traps (opera na porta 162 através do protocolo UDP), sem que o gerente tenha 

solicitado, quando alguma situação anormal esteja acontecendo. A aplicação 

gerente recebe este alerta e o administrador da rede pode analisá-lo como bem 

entender. Esta arquitetura pode ser mais bem exemplificada abaixo (Figura 9). 

Figura 9 - Arquitetura de gerenciamento SNMP 

 

Fonte: Filho (2009, texto digital). 

 

 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

43 

3.2.2 Formato da mensagem SNMPv1 

 

O SNMP é um protocolo orientado a pacotes, sendo que cada pacote é 

denominado Protocol Data Unit (PDU), possuindo uma estrutura que contém 

cabeçalho, dados e informações de verificação do pacote (FILHO, 2009). Para 

Stallings (1999), as mensagens SNMP são utilizadas para efetuar a troca de 

informação entre a estação de gerenciamento e os agentes.     

Cada mensagem possui o número da versão do protocolo SNMP, a 

comunidade utilizada para intermediação entre o gerente e o agente e um dos cinco 

tipos de operações do protocolo (getRequest, getNextRequest, setRequest, 

getResponse, trap), conforme ilustrado na Figura 10. 

Figura 10 - Formato SNMP 

 
Fonte: Stallings (1999). 

Quadro 5 - Mensagens SNMP 

CAMPO DESCRIÇÃO 

Version Versão do SNMP. 

community Nome da comunidade SNMP. 

request-id Identificador único dos pedidos tratados. 

error-status 
Indica alguma exceção quanto ao comportamento do pedido. Gera valores como: 
noError(0); tooBig (1); noSuchName(2); badValue(3); readOnly(4) e genErr(5). 

error-index 
Provê informação adicional quando um erro ocorre, desde que o status dele seja 
diferente de 0. 

variablebindings Lista de nomes de variáveis e seus valores correspondentes. 

Enterprise Tipo de trap de produção de objeto. 

agent-addr Endereço do trap de produção de objeto. 

generic-trap 
Tipos genéricos de valores trapsão: coldStart(0); warmStart(1); linkDown(2); 
linkUp(3); authentication-Failure(4); egpNeighborLoss(5) e enterprise-specific(6). 

CONTINUA 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

44 

CONCLUSÃO 

CAMPO DESCRIÇÃO 

specific-trap Código de trap específico. 

time-stamp 
Tempo decorrido entre a última inicialização da entidade de rede com a produção 
de trap; contém os valores de sysUpTime. 

Fonte: Barreto (2008, p. 15). 

 

3.2.3 Transmissão de uma mensagem SNMPv1 

 

De acordo com o RFC 1157 (CASE et al., 1990) e Stallings (1999), uma 

mensagem SNMP é transmitida da seguinte forma: 

Uma estrutura ASN.1 é utilizada para montar o PDU. O PDU é encaminhado 

para um serviço de autenticação, juntamente com o endereço de origem e destino e 

à comunidade da qual faz parte. Este serviço de autenticação se encarrega de gerar 

uma transformação como criptografia ou inclusão de algum código de autenticação e 

retorna o resultado. A entidade que será a transmissora do pacote constrói a 

mensagem que é constituída por campos contendo a versão do protocolo, nome da 

comunidade e o resultado da etapa anterior. Através da codificação ASN.1, um novo 

objeto é representado e passado ao serviço de transporte. 

 

3.2.4 Recepção de uma mensagem SNMPv1 

 

Quanto à recepção de uma mensagem SNMP, segundo Barreto (2008), esta 

ocorre da seguinte forma: 

O receptor analisa a sintaxe da mensagem, procurando inconformidades. 

Caso contenha, descarta a mensagem. Verifica o número da versão, e ,caso haja 

algum erro de combinação, descarta a mensagem. A entidade receptora do 

protocolo informa o nome de usuário (comunidade), a PDU da mensagem, e a 

origem e o destino do endereço de transporte para que seja efetuada uma 

autenticação. Essa autenticação é feita da seguinte forma: se houver falha de 

autenticação, a mensagem é descartada, sinalizando o receptor SNMP, que, por sua 

vez, gera um trap. Caso a autenticação seja validada com sucesso, um PDU 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

45 

adequado à estrutura é gerado. O PDU é processado, e, caso o receptor SNMP 

obtiver falha na combinação da PDU, a mesma é descartada. 

 

3.2.5 Variable bindings do protocolo SNMPv1 

 

Uma variable binding é um campo da mensagem PDU, responsável por 

implementar múltiplas trocas entre objetos gerenciados. Com ela é possível enviar 

em uma única mensagem, operações do tipo get, set, trap. Dessa forma, se a 

aplicação gerente necessita receber os valores de todos os objetos escalares em um 

grupo particular de um agente, pode enviar esta única mensagem, solicitando todos 

os valores e obtendo uma resposta única, listando todos os valores (STALLINGS, 

1999). Através dessa técnica, pode-se reduzir consideravelmente a carga de 

comunicações de gerenciamento de rede. 

 

3.2.6 GetRequest PDU do protocolo SNMPv1 

 

Uma operação do tipo GetRequest PDU, provém de um gerente, solicitando 

algo a um agente. Para que isso seja possível, a PDU deve conter os seguintes 

campos (Figura 11): 

a) tipo PDU: indica o tipo da PDU, no caso, um GetRequest; 

b) request-id: É um valor único que identifique a requisição em questão. Deve 

possibilitar a detecção de PDUs duplicadas; 

c) variablebindings: Contém uma lista de objetos que serão requisitados 

(STALLINGS,1999). 

 

 

 

 

 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

46 

Figura 11 - Formato da mensagem de Requisições do SNMP. 

 

Fonte: Rocha (2011, texto digital). 

No lado do agente, a resposta a um GetRequest será dada por um 

GetResponse utilizando o mesmo request-id. Isso torna esta operação atômica, ou 

seja, todos os valores de objetos solicitados são respondidos ou nenhum. Caso um 

erro seja reportado, este retorna para o gerente através de um campo error-status, 

contido no GetResponse PDU. A entidade de resposta também pode indexar um 

objeto que contenha erro, usando o campo error-index e enviar a informação para a 

estação de gerenciamento (Figura 12). 

Figura 12 - Formato da mensagem de resposta. 

 
Fonte: Rocha (2011, texto digital). 

 

 

3.2.7 GetNextRequest PDU do protocolo SNMPv1 

 

O GetNextRequest PDU utiliza os princípios do GetRequest, possuindo o 

mesmo formato e troca de mensagem. A única diferença é que, enquanto um 

GetRequest possui em sua variablebindings uma referência a um objeto, obtendo o 

seu valor através do agente, no GetNextRequest este valor é dado pelo próximo 

objeto existente na árvore de sua MIB. Com isso, é possível descobrir e percorrer 

estruturas de uma MIB, na qual o tamanho das tabelas ou o formato é desconhecido 

(ROCHA, 2011). 

 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

47 

3.2.8 SetRequest PDU do protocolo SNMPv1 

 

Nas operações do tipo SetRequest PDU, sua principal função, se acordo com 

Barreto (2008), é alterar valores de variáveis do objeto de gerenciamento, utilizando 

assim, a mesma estrutura de um GetRequest ou GetNextRequest. O campo 

variablebindings recebe a lista dos valores de objetos que serão alterados. No 

agente, a resposta é feita utilizando o mesmo formato de mensagem de um 

GetResponse, contendo, também, o mesmo request-id informado (ROCHA, 2011). O 

SetRequest também pode ser usado para adicionar ou eliminar linhas, como afirma 

Barreto (2008). 

 

3.2.9 Trap PDU do protocolo SNMPv1 

 

Informa um alerta de evento provindo de um agente para um gerente, de 

forma que essa interação seja assíncrona, ou seja, não possui uma ordem 

cronológica de acontecimento. 

Algumas notificações mais comuns são: 

a) cold e warm start: reinicialização de um agente recorrente ou não de alguma 

falha; 

b) link down ou up: Falha ou retorno de algum link identificado no campo 

variablebindings (ROCHA, 2011); 

c) authentication failure: Informa que houve falha na autenticação de alguma 

mensagem. 

Figura 13 - Formato de mensagem de Trap no SNMPv1. 

 

Fonte: Rocha (2011). 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

48 

Figura 14 - Sequência do PDU SNMP. 

 
Fonte: Barreto (2008, p. 17). 

 

3.2.10 Limitações do protocolo SNMPv1 

 

O SNMP, mesmo sendo o protocolo mais utilizado na gerência de redes, 

possui algumas limitações, dentre outras, determinadas por Stallings (1999). São 

elas: 

a) desempenho limitado em grandes redes devido a performance da técnica de 

polling, onde sempre é necessário enviar um pacote para obter de volta outro 

pacote de informações. 

b) mensagens críticas de trap podem não ser entregues e não ocorre uma 

garantia da sua entrega por usar UDP/IP. 

c) autenticação simples para o padrão básico SNMP. 

d) não suporta comunicação entre gerentes. Não há como uma rede gerenciada, 

aprender sobre os dispositivos de outra rede gerenciada. 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

49 

3.3 Protocolo SNMPv2 

 

A segunda versão do Protocolo SNMP surgiu das limitações encontradas na 

versão original, principalmente quanto à questão de segurança, que praticamente 

não existia na versão 1. Porém, na prática, houve muita controvérsia por parte da 

equipe de desenvolvimento, quanto a este quesito, fazendo com que o seu 

mecanismo de segurança permanecesse o mesmo da primeira versão. Mesmo 

assim, outras funcionalidades foram implantadas em sua arquitetura como, por 

exemplo, novas operações que permitem a transferência de grandes blocos de 

dados (bulk), maior padronização estrutural da PDU, melhor detalhamento dos 

códigos de erros, possibilidade de interação entre entidades gerentes, suporte a 

multiprotocolos na camada de transporte, entre outros (SPECIALSKI, [2002]).  

A complexidade do protocolo aumentou consideravelmente e, por causa 

disso, não houve uma ampla aceitação (SPECIALSKI, [2002]). Os documentos 

RFC’s, que descrevem essa nova versão, vão do RFC 1901 a 1908 (CASE et al., 

1996), o que, de fato, mostra o tamanho da complexidade desta extensão do SNMP, 

pois a sua versão original era contida em apenas um RFC, o 1157 (CASE et al., 

1990). 

 

3.3.1 Arquitetura do protocolo SNMPv2 

 

Enquanto que o SNMPv1 possui dois tipos de interação para acessar valores 

de objetos gerenciados, o SNMPv2 pode utilizar três. São eles (Figura 15): 

a) gerente-agente ou request-response: ocorre quando um gerente envia uma 

requisição a um agente e este o responde (presente no SNMPv1);  

b) gerente-gerente: uma entidade gerente solicita uma informação à outra 

entidade gerente, que por sua vez retorna o pedido. Funciona como um 

request-response, porém é efetuado entre gerentes (presente somente no 

SNMPv2); 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

50 

c) agente-gerente não confirmado ou trap: Esta interação ocorre quando um 

agente envia uma mensagem não solicitada, de forma assíncrona, para um 

gerente sem que este retorne nada (presente no SNMPv1). 

Figura 15 - Arquitetura SNMPv2. 

 

Fonte: SpeciaIski ([2002], p. 30).  

No SNMPv2 foram incluídas duas novas PDU’s para operações do protocolo, 

GetBulkRequest PDU e InformationRequest PDU. A primeira trata de recuperar 

grandes blocos de dados, de forma eficiente, como linhas de tabelas, eliminando, 

assim, uma das principais limitações da primeira versão. Já a segunda operação, é 

utilizada na troca de mensagens entre gerentes SNMP, onde um gerente informa a 

outro informações contidas na sua MIB, permitindo, assim, o gerenciamento 

distribuído. Quando o destinatário recebe a mensagem gera um Response PDU 

para o remetente, contendo a mesma informação recebida (Quadro 6). 

 

 

 

 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

51 

Quadro 6 - Tipos e descrições de PDUs 

VALOR DO 
TIPO DE PDU 

TIPO DE PDU DESCRIÇÃO 

0 GetRequest Retorna o valor de uma instância da variável. 

1 GetNextRequest Retorna o valor da variável sucessora lexográfica. 

2 Response Retorna o resultado de uma operação. 

3 SetRequest Atribui valor a uma variável. 

4 Trap (obsoleto) Não usado. Era o antigo Trap do SNMPv1. 

5 GetBulkRequest Permite a recuperação de grande quantidade de dados, 
normalmente o conteúdo de tabelas. 

6 InformRequest Permite que um gerente envie informações para outro gerente. 

7 Trapv2 Envia sinalizações de eventos. 

8 Report Usado para comunicação interna do protocolo para relatar 
erros excepcionais ocorridos durante o processamento das 
requisições. 

Fonte: Fassi ([2008?], texto digital). 

 

3.3.2 Formato da mensagem do protocolo SNMPv2 

 

O formato estrutural da PDU (Figura 16) também foi agrupado, tornando-se, 

assim, mais padronizado. Inclusive as mensagens de trap, que no SNMPv1 

continham uma PDU exclusiva, na versão 2 foi modificada para se enquadrar ao 

restante das operações. Com isso houve um aumento de eficiência e performance 

durante a troca de mensagens entre as entidades (SPECIALSKI, [2002]). 

Figura 16 - Formato de mensagem PDU do SNMPv2. 

 

Fonte: Barreto (2008, p.22). 

Quanto aos códigos de erros, o SNMPv2 possibilitou novas informações, 

permitindo que houvesse uma análise mais apurada dos problemas ocorridos nas 

trocas de mensagens. O Quadro 7 informa uma lista de todos códigos de erros 

possíveis, bem como sua descrição, conforme Fassi ([2008?]). 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

52 

Quadro 7 - Códigos de erros do SNMPv2 

 

Fonte: Do autor, adaptado de Fassi ([2008?], texto digital). 

De acordo com Spescialski ([2002]), o SNMPv2, através da RFC 1906 (CASE, 

et al., 1996), pode atuar não somente através de transmissão sobre o UDP, como 

também é possível especificar outros protocolos de transporte. Exemplos disso são 

os protocolos OSI (RFC 1418),  appletalk  (RFC  1419) e o Internetwork Packet 

Exchange (IPX)  (RFC  1420). 

 

 

 

 

 

Valor do Código de Erro Código de Erro Descrição

0 noError Nenhum erro ocorrido.

1 tooBig

O tamanho do PDU Response muito grande para ser 

transmitido. 

2 noSuchName O nome do objeto requisitado não foi encontrado.

3 badValue Valor incorreto.

4 readOnly

Impossibilidade de alterar o valor de uma variável pois a 

mesma é somente leitura.

5 genErr Erro desconhecido.

6 noAccess Sem acesso ao objeto por motivos de segurança.

7 wrongType Tipo de dado do objeto é incorreto.

8 wrongLength Tamanho do objeto incorreto.

9 wrongEncoding O valor codificado é inconsistente com o tipo do objeto.

10 wrongValue Valor da variável inválido.

11 noCreation Variável especificada não existe ou não pode ser criada.

12 inconsistentValue

Condição temporária de inconsistência no valor do 

objeto.

13 resourceUnavailable

Alocação de recursos indisponíveis no momento de 

atribuir valor a uma variável.

14 commitFailed Falha na atribuição de valores de uma variável.

15 undoFailed

Impossibilita desfazer atribuições de variáveis após 

ocorrência de uma falha.

16 authorizationError Erro de autorização.

17 notWritable Variável não pode ser modificada.

18 inconsistentName

o nome da variável é inconsistente e não pode ser criada 

nestas circunstâncias.



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

53 

3.3.3 Limitações do protocolo SNMPv2 

 

Apesar de possuir vantagens sobre a primeira versão do SNMP, o SNMPv2  

apresenta  algumas limitações mencionadas abaixo:  

a) dificuldade de implementação devido a grande complexidade; 

b) muitas variações do protocolo, como por exemplo, SNMPv2c, SNMPv2u e 

SNMPv2*  (as duas últimas foram destinadas a melhorias de segurança 

porém na prática não são utilizadas); 

c) baixa aceitação pela comunidade de gerência.  

 

3.4 Protocolo SNMPv3 

 

Como o SNMPv2 não conseguiu trazer as melhorias de segurança propostas, 

houve a necessidade destas serem inclusas ao protocolo, fazendo com que 

surgisse, em meados de 1999, a terceira versão do SNMP, o SNMPv3. 

Basicamente, o SNMPv3 utiliza os mesmos mecanismos das troca de mensagem 

PDU do SNMPv2, porém, sua estrutura geral é diferente das outras versões do 

protocolo.  

Dentre as melhorias implementadas, pode-se destacar a inclusão de um 

modelo de segurança baseado em usuários, chamado User-based Security Model 

(USM), e um modelo de controle de acesso baseado em visão, o View-based 

Access Control Model (VACM). Também vale ressaltar a inclusão de módulos na 

arquitetura que permitem a integração com as versões anteriores do protocolo 

(SPECIALSKI, [2002]). Esta seção não irá se aprofundar nessa versão do protocolo, 

limitando-se a abordar, de forma geral, o seu funcionamento. A Figura 17 mostra a 

evolução do protocolo SNMP. 

 

 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

54 

Figura 17 - Evolução do SNMP. 

 

Fonte: Helcio; Iguatemi (2009, texto digital). 

 

3.4.1 Arquitetura do protocolo SNMPv3 

 

Através da RFC 2571 (HARRINGTON et al., 1999), definiu-se o conceito de 

entidades SNMP, onde cada entidade pode interagir com outra, atuando, assim, 

como agente, gerente ou ambos. Tais entidades possuem módulos que se 

comunicam entre si para dispor algum serviço, como afirma Fassi ([2008?]). 

Uma entidade SNMPv3 (Figura 18) pode ser definida pelos componentes 

abaixo (SPECIALSKI, [2002]): 

Quadro 8 - Componentes do protocolo SNMPv3 

COMPONENTE DESCRIÇÃO 

Dispatcher 
gerenciador de tráfego, permitindo suporte concorrente a múltiplas 
versões de mensagens SNMP 

subsistema de 
processamento de 
mensagens 

prepara mensagens para transmissão e extrai dados de mensagens 
recebidas 

subsistema de segurança 
provê mecanismos de autenticação e privacidade. Pode conter vários 
modelos de segurança 

subsistema de controle de 
acesso checa as diretivas de acesso que uma aplicação terá direito 

CONTINUA 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

55 

CONCLUSÃO 

COMPONENTE DESCRIÇÃO 

gerador de comandos 
responsável por inicializar as PDUs SNMP (get, getNext, getBulk, 
setRequest) e processar as resposta provindas de uma requisição 

respondedor de 
comandos 

responsável por receber as PDUs SNMP, executar alguma operação 
definida pelo protocolo usando o controle de acesso e criar a 
mensagem de resposta que será encaminhada 

originador de notificação 

origina as mensagens de trap/inform baseado em eventos e condições 
monitoradas. Responsável também por determinar qual será o destino 
da mensagem, a versão do SNMP que será usada e quais serão os 
mecanismos de segurança utilizados 

receptor de notificação responde as requisições de notificação referentes ao PDU inform 

encaminhador de proxy Serve para repassar as mensagens SNMP. É de uso opcional. 

Fonte: Specialski ([2002, p. 33]). 

 

Figura 18 - Arquitetura de uma entidade SNMPv3 

 

Fonte: Do autor. 

 

3.4.2 Formato da mensagem do protocolo SNMPv3 

 

O formato da mensagem SNMPv3 é mostrado na (Figura 19) e possui uma 

estrutura baseada em módulos, sendo que a parte escura representa a área 

utilizada pelo susbsistema de processamento de mensagem. Os campos utilizados 

em uma mensagem SNMPv3 são descritos no Quadro abaixo, conforme Barreto 

(2008) e Karing (2002): 

 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

56 

Quadro 9 - Campos utilizados em uma mensagem SNMPv3 

CAMPO DESCRIÇÃO 

msgVersion versão SNMP utilizada na mensagem 

msgID 
identificador único usado entre duas entidades SNMP e pelo processador 
de mensagens. 

msgMaxSize tamanho máximo das mensagens. Medido em octetos. 

msgFlags 

representa um octeto contendo três flags nos três últimos bits significativos. 
Tais flags são: reportableFlag, privFlag, authFlag. A primeira é utilizada 
somente quando uma porção PDU de uma mensagem não pode ser 
decodificada. Já a privFlag e authFlag são elementos de segurança usados 
para o processo de criptografia e autenticação, respectivamente 

msgSecurityModel 

indica qual modelo de segurança foi usado pelo remetente ao preparar e 
mensagem e, com isso, qual modelo de segurança deve ser usado pelo 
destinatário para processar a mensagem. Alguns valores aceitos incluem: 
“1” para SNMPv1, “2” para SNMPv2c e “3” para USM. 

msgSecurityParameters 
representa um octeto que contém informações geradas pelo subsistema de 
segurança da entidade SNMP que enviou a mensagem e processado pelo 
subsistema de segurança da entidade receptora. 

contextEngineID identificador único da entidade SNMP. É representado por um octeto. 

contextName 
octeto que identifica de forma única um contexto a um motor de contexto 
associado. 

PDU SNMPv2 a PDU utilizada segue os mesmos padrões da versão 2 do protocolo. 

Fonte: Do autor, adaptado de Barreto (2008) e Karing (2002). 

 

Figura 19 - Formato de mensagem SNMPv3 

 

Fonte: Karing (2002, p.51). 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

57 

3.4.3 Segurança e controle de acesso do protocolo SNMPv3 

 

Segundo Walsh (2008), no modelo SNMPv3 é definida a autenticação de 

usuários, através da qual cada um possui seu nome de usuário e senha. Tanto as 

entidades gerentes como os agentes possuem as suas chaves de segurança e têm 

seus usuários válidos,  juntamente com uma chave secreta única, definida para cada 

usuário. Quando uma entidade envia uma mensagem SNMPv3, a chave secreta de 

seu utilizador é usada para criar um hash da mensagem, e este valor é inserido na 

mesma. Caso a entidade receptora consiga recriar esse hash através de sua chave 

secreta compartilhada, então a mensagem é autenticada e provém de um usuário 

válido.  

As mensagens de traps também são enviadas a partir de usuários válidos e 

as entidades agentes podem ser configuradas para exercer um controle mais 

detalhado sobre a transmissão destes traps para os gerentes. 

Esse tipo de modelo é conhecido como modelo de segurança baseado em 

usuários (USM), e garante que as mensagens enviadas de forma atemporal não 

sejam atrasadas ou reproduzidas por quem não pertence ao grupo autenticado.  

As entidades SNMP, que atuam como agentes, podem ser configuradas para 

controlar quem pode acessar e o que pode ser acessado dentre os objetos 

pertencentes à MIB por elas gerenciada (WALSH, 2008). Nas versões anteriores do 

SNMP, esse quesito era gerenciado através do conceito de nomes de comunidade. 

Já no SNMPv3, segundo Specialski ([2002], p. 35), “o controle de acesso tornou-se 

muito mais seguro e flexível pela introdução do modelo de controle de acesso 

baseado em visão (VACM – View-based Access Control Model)”. Por exemplo, um 

usuário = Supervisor de Operações pode acessar os dados críticos de leitura e 

escrita de controle, enquanto o usuário = Manutenção de planta pode acessar 

somente os dados específicos com permissão de apenas leitura (WALSH, 2008). 

De acordo com Specialski ([2002]), o  SNMPv3  é  projetado  para  prover  

segurança  contra  as  seguintes ameaças: 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

58 

a) modificação da informação: uma entidade poderia alterar uma mensagem em 

trânsito que tivesse sido gerada por alguma entidade autorizada; 

b) masquerade: uma entidade possuir o privilégio de entidade autorizada, 

mesmo não sendo autorizada; 

c) modificação da cadeia de mensagem: uma mensagem SNMP está sujeita a 

ser reordenada, atrasada ou repetida pelo fato de o protocolo ter sido 

projetado a operar sobre um protocolo não orientado à conexão (UDP); 

d) descoberta: através da observação de troca de mensagens entre gerentes e 

agentes, uma entidade poderia descobrir valores de objetos gerenciados e 

assim, alterá-los. 

Mesmo assim, ainda existem limitações quanto à segurança como nas 

seguintes ameaças: 

a) negação de Serviço (Denial of Service – DoS): ocorre quanto um atacante 

consegue impossibilitar o serviço de troca de mensagens entre gerente e 

agente; 

b) análise de tráfego: observação do comportamento de tráfego entre gerente e 

agente. 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

59 

4 FERRAMENTAS DE GERENCIAMENTO E MONITORAMENTO DE 

REDES 

 

 

A fim de atingir um maior número de elementos gerenciados, torna-se viável 

fazer uso de uma ferramenta capaz de auxiliar, de forma eficaz, toda a parte de 

gerenciamento e monitoramento de redes. Essa ferramenta deve, no mínimo, ser 

capaz de prover uma interface única ao usuário e demonstrar informações em tempo 

real sobre os objetos gerenciados, de forma clara, para que seja efetuada uma 

análise correta do ambiente gerenciado. A partir disso, esse Capítulo tem como 

objetivo analisar alguns sistemas baseados em software livre utilizados para efetuar 

o gerenciamento e monitoramento de redes de computadores. 

Na seção 4.1 e 4.2 serão introduzidas algumas das principais soluções em 

software para geração de gráficos de estado, o MRTG e o RRDTOOL, 

respectivamente, sendo que os mesmos mostram-se como precursores das atuais 

soluções de sistemas para gerenciamento. Já na seção 4.3 será abordada a 

ferramenta NTOP, um analisador e monitorador de tráfego de rede. As seções 4.4, 

4.5, 4.6, 4.7, 4.8 e 4.9 informam um breve resumo e características principais das 

ferramentas Nagios, Cacti, OpenNMS, Pandora FMS, Zabbix e Zenoss, nessa 

ordem. Na seção 4.10 será apresentado um quadro comparativo entre as 

ferramentas estudadas, e na seção 4.11 será mostrada a análise dos resultados 

comparativos referente aos  tipos de software propostos. 

 

 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

60 

4.1 MRTG 

 

O Multi Router Traffic Grapher (MRTG) é um software escrito em perl e 

funciona em Unix/Linux, bem como nos sistemas Windows e até mesmo Netware.  

Além disso, é software livre, licenciado sob a GNU General Public License (GPL) 

(MRTG, 2013). 

O desenvolvimento dessa ferramenta foi originalmente iniciado em 1994 e sua 

proposta principal é monitorar o tráfego de rede, baseado em páginas HyperText 

Markup Language (HTML), que mostram, através de imagens gráficas, o estado em 

tempo real deste tráfego.  

Essa ferramenta utiliza agentes SNMP ou scripts personalizados para coletar 

as informações e expor em forma de gráficos (Figura 20), desde que o software ou 

hardware monitorado tenham suporte a isso (MRTG, 2013). 

Figura 20 - Imagem de um gráfico gerado pelo MRTG. 

 

Fonte: MRTG (2013). 

 

4.2 RRDTool 

 

O Round Robin Database (RRDTool) originou-se a partir do MRTG e utiliza o 

algoritmo de Round Robin para gerar uma base de dados em séries temporais com 

valores numéricos, contendo informações sobre estado de diversos elementos como 

temperatura, carga de Central Processing Unit (CPU), uso de memória e disco, 

estado da rede, entre outros. É possível coletar dados vindos de agentes SNMP e 

gerar diversos tipos de gráficos (Figura 21) para monitorar a informação (RRDTOOL, 

2013). 

 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

61 

Figura 21 - Imagem de um gráfico gerado pelo RRDTool 

 

Fonte: RRDTool (2013). 

 

4.3 NTOP 

 

A principal característica do NTOP é poder monitorar a utilização dos recursos 

de rede de computadores como tráfego e consumo de banda, por exemplo (NTOP, 

2013). As informações são mostradas de forma clara através de uma página web 

(Figura 22), onde é possível verificar todas as conexões estabelecidas dentro da 

rede interna, identificando o host através de seu endereço IP e outros protocolos 

envolvidos na conexão. 

Com essa ferramenta é possível avaliar de forma bem ampla como o estado 

da rede está se comportando em determinado momento, possibilitando ao 

administrador de redes observar anomalias e solucionar eventuais problemas em 

sua rede. 

O NTOP também possui suporte a múltiplas plataformas como UNIX, LINUX e 

Windows. Como foi projetado para ser uma aplicação ao nível de kernel, ele visa 

utilizar poucos recursos de processador e memória. Por ser uma ferramenta simples 

e com uma análise bem completa do estado da rede, tem-se como um software 

bastante útil para redes locais, nesse quesito. 

 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

62 

Figura 22 - Informações de host no NTop 

 

Fonte: NTOP (2013). 

 

4.4  Nagios 

 

O Nagios é um dos mais conhecidos sistemas de gerenciamento de rede, de 

código aberto e licenciado pelo sistema GPL. Com ele é possível gerenciar tanto 

equipamentos de hardware (switch, roteadores, servidores, estações de trabalho, 

etc), como serviços funcionais a nível de software em uma rede. Também possui 

mecanismos de alerta quanto à descoberta de problemas na rede e/ou resolução 

dos mesmos. 

Esse software foi originalmente desenvolvido por Ethan Galstad, em 1999, 

sob o nome de NetSaint, e, em 2001, teve seu nome alterado e registrado para 

Nagios (Nagios Ain't Gonna Insist On Sainthood), por ter sido acusado de utilizar o 

mesmo nome, na época, de uma outra marca. Em 2007, Ethan fundou a Nagios 

Enterprises, que é atualmente a patrocinadora oficial do projeto e possui, além da 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

63 

versão comunitária, uma versão comercial que conta com um suporte mais 

específico e algumas características inicialmente não disponíveis na versão 

comunitária (NAGIOS, 2013).  

Em consonância com o site oficial do projeto (NAGIOS, 2013) serão listadas 

algumas características desta ferramenta, tais como: 

a) monitoramento de serviços de rede, tais como: SMTP, POP3, HTTP, ICMP, 

SMNP, entre outros; 

b) monitoramento da infraestrutura de hardware (uso de memória, carga da 

CPU, espaço em discos, log de sistema, etc); 

c) detecção de problemas antes que estes ocorram;  

d) alertas instantâneos ao surgimento de problemas; 

e) compartilhamento de informações de disponibilidade entre as partes 

interessadas; 

f) detecção de falhas de segurança; 

g) informações pertinentes para expansão e/ou atualização da TI; 

h) redução de perdas de tempo de inatividade e de negócios. 

Com o Nagios é possível, ainda, desenvolver plug-ins em diferentes 

linguagens para determinadas tarefas. Sua comunidade já disponibilizou uma série 

deles para auxiliar no gerenciamento de redes. 

 

 

 

 

 

 

 

 



B
D

U
 –

 B
ib

lio
te

ca
 D

ig
ita

l d
a 

U
N

IV
AT

E
S 

(h
tt

p:
//w

w
w

.u
ni

va
te

s.b
r/

bd
u)

64 

Figura 23 - Tela do software Nagios 

 

Fonte: Nagios (2013). 

Algumas desvantagen