Gerência de Redes de Computadores

Gerncia de
Redes de
Computadores
Mauro Tapajs Santos
Liane Tarouco
Leandro Bertholdo
Francisco Marcelo Marques Lima
Vanner Vasconcellos
A RNP Rede Nacional de Ensino

e Pesquisa qualificada como
uma Organizao Social (OS),
sendo ligada ao Ministrio da
Cincia, Tecnologia e Inovao
(MCTI)
responsvel
pelo
Programa Interministerial RNP,

que conta com a participao dos
ministrios da Educao (MEC), da
Sade (MS) e da Cultura (MinC).
Pioneira no acesso Internet no
Brasil, a RNP planeja e mantm a
rede Ip, a rede ptica nacional
acadmica de alto desempenho.
Com Pontos de Presena nas
27 unidades da federao, a rede
tem mais de 800 instituies
conectadas. So aproximadamente
3,5 milhes de usurios usufruindo
de uma infraestrutura de redes
avanadas para comunicao,
computao e experimentao,
que contribui para a integrao
entre o sistema de Cincia e
Tecnologia, Educao Superior,
Sade e Cultura.
Ministrio da
Cultura
Ministrio da
Sade
Ministrio da
Educao
Ministrio da
Cincia, Tecnologia
e Inovao
Gerncia de
Redes de
Computadores
Mauro Tapajs Santos
Liane Tarouco
Leandro Bertholdo
Vanner Vasconcellos
Gerncia de
Redes de
Computadores
Mauro Tapajs Santos
Liane Tarouco
Leandro Bertholdo
Vanner Vasconcellos
Rio de Janeiro
Escola Superior de Redes
2015
Copyright 2014 Rede Nacional de Ensino e Pesquisa RNP

Rua Lauro Mller, 116 sala 1103
22290-906 Rio de Janeiro, RJ
Diretor Geral
Nelson Simes
Diretor de Servios e Solues
Jos Luiz Ribeiro Filho

Coordenao
Luiz Coelho
Edio
Lincoln da Mata
Coordenados da rea de Administrao de Projetos de Redes
Luiz Carlos Lobato
Equipe ESR (em ordem alfabtica)
Adriana Pierro, Celia Maciel, Derlina Miranda, Edson Kowask, Elimria Barbosa, Evellyn Feitosa,
Felipe Nascimento, Lourdes Soncin, Luciana Batista, Renato Duarte e Yve Abel Marcial.
Capa, projeto visual e diagramao
Tecnodesign
Verso
2.0.1
Este material didtico foi elaborado com fins educacionais. Solicitamos que qualquer erro encontrado ou dvida com relao ao material ou seu uso seja enviado para a equipe de elaborao de
contedo da Escola Superior de Redes, no e-mail info@esr.rnp.br. A Rede Nacional de Ensino e
Pesquisa e os autores no assumem qualquer responsabilidade por eventuais danos ou perdas, a
pessoas ou bens, originados do uso deste material.
As marcas registradas mencionadas neste material pertencem aos respectivos titulares.
Distribuio
Rua Lauro Mller, 116 sala 1103

22290-906 Rio de Janeiro, RJ
http://esr.rnp.br
info@esr.rnp.br
Dados Internacionais de Catalogao na Publicao (CIP)
G367
Gerncia de Redes de Computadores / Mauro Tapajs Santos [et. al.]. 2. ed.

Rio de Janeiro: RNP/ESR, 2015.
320 p. : il. ; 27,5 cm.
Bibliografia: p.301-304.
1. Gerncia de redes. 2. Qualidade de Servio (telecomunicaes) 3. Protocolos de
comunicao. 4. Redes de computadores diagnostico. I. Santos, Mauro Tapajs.
CDD 005.8
Sumrio
A metodologia da ESRxi
Sobre o curso xii
A quem se destinaxii
Convenes utilizadas neste livroxii
Permisses de usoxiii
Sobre o autorxiv
1. Introduo gerncia de redes

Importncia do gerenciamento1
Atuao do gerente de redes2
Atividades comuns de gerenciamento3
O que gerenciar?4
reas funcionais de gerenciamento (modelo OSI) 5
Gerenciamento de falhas6
Gerenciamento de desempenho7
Gerenciamento de configurao7
Gerenciamento de segurana7
Gerenciamento de contabilizao8
Gerenciamento dentro do modelo OSI8
Conceitos9
Modelo de comunicao9
Deteco dos sintomas do problema11
iii
Gerncia de configurao 17
Ferramentas para a gerncia de contabilizao 18
Gerncia de desempenho 19
Gerncia de segurana 20
Modelo ITIL: Information Technology Infrastructure Library20
Fluxo de mensagens em SNMP23
Modelo operacional SNMP24
RMON Remote 25
Grupos de Objetos da RMON v126
Agentes e gerentes27
Informao de gerenciamento 28
Conceitos de orientao a objetos29
Structure of Management Information (SMI)29
Abstract Sintax Notation (ASN.1)30
Sintaxe ASN.1 de um objeto da MIB31
Regras de codificao BER (Basic Encoding Rules ISO 8825)32
Representao BER (TLV)34
Alguns identificadores ASN.1 (tags)35
ASN.1 e BER (Exemplos)36
2. Ferramentas de inspeo e monitorao de redes

Problemas na rede37
Processo de resoluo de problemas38
Ferramentas para inspeo e monitorao41
Wireshark41
TCPDUMP58
Referncias59
Questionrio para testar os conhecimentos relativos ao uso do Wireshark60
3. SNMPv1, SNMPv2 e SNMPv3

Contextualizao63
MIBs Padronizadas65
iv
rvore de identificadores 66
rvore da MIB II67
MIB para tecnologias de transmisso69
Novos grupos da MIB II69
Extenses privadas MIB70
Structure of Management Information (SMI)71
SNMP Introduo72
SMIv1 Tipos de dados74
SMIv1 Definio de objetos75
SNMPv1 Comunicao e Operaes75
SNMPv1 Formato da mensagem do protocolo SNMP77
SNMPv1 Relao MIB view e Comunidade77
SNMPv1: Formato da PDU de resposta78
SNMPv1: Formato do PDU para a trap79
SNMPv1: Declarao de uma trap especfica (macro ASN.1 TRAP-TYPE)80
SNMPv1: Obteno de valores de uma MIB80
SNMPv1: Modificao de valores em tabelas82
SNMPv2 Uma nova verso82
SNMPv2 Evoluo83
SMIv2 Novos tipos de dados84
SMIv2: Textual conventions (RFC 2579)84
Melhorias na manipulao de tabelas85
SMIv2 Definio de objetos85
SNMPv2: Alteraes no protocolo85
SNMPv2 Operaes86
SNMPv2 Operao InformRequest e o gerenciamento
hierarquizado87
SNMPv2 Operao getBulkRequest88
SNMPv2 Mensagens89
SNMPv2: Tipos de agentes89
Agentes proxy90
SNMPv3: Novo modelo de segurana90
Arquitetura modular SNMPv391
Segurana SNMPv392
Formato da mensagem SNMPv393
SNMP Agente: NET-SNMP94
NET-SNMP Aplicaes95
NET-SNMP Configurao95
Suporte a SNMPv3 no pacote NET-SNMP96
Criao de usurios SNMPv397
Uso das aplicaes com SNMPv397
4. Monitoramento remoto RMON, RMON2, SMON e Host MIB

Monitores99
RMON Objetivos101
Configurao do RMON101
Grupos da MIB RMON102
Eventos e alarmes103
RMON 2103
RMON2: Grupo Protocol Directory105
RMON2: Grupo Protocol Distribution105
RMON2: Grupo Network Layer Host105
RMON2: Grupo Network Layer Matrix106
RMON2: Grupo Application Layer Host106
RMON2: Grupo Application Layer Matrix107
SMON: Remote Network Monitoring MIB Extensions for Switched Networks107
SMON: Grupo smonVlanStats108
SMON: Grupo smonPrioStats108
SMON: Grupo portCopy109
SMON: Grupo dataSourceCaps109
ntop109
Gerenciamento de hosts e sistemas111
Gerenciamento de aplicaes116
5. Aspectos e aplicaes de plataformas de gerncia

Modelos de gerncia119
Network Management System (NMS)125
vi
Arquitetura de um sistema de gerncia128

Obtendo dados da atividade da rede131
Descoberta da rede131
Filtrando as atividades da rede baseando-se em limiares132
Correlao de alarmes132
Priorizao de atividades134
Escalabilidade134
Usando uma anlise FCAPS na definio de um NMS135
Gerncia de falhas135
Gerncia de Configurao137
Gerncia de Performance138
Network Management Systems disponveis no mercado139
HP IMC Intelligent Management Center140
HP NNM: Network Node Manager141
SNMPc da Catlerock142
WhatsUp da IPSwitch143
OPManager, da ManageEngine144
6. Aplicaes e plataformas de gerncia em software livre

Solues OSS/FS147
Framework FCAPS148
Gerncia de Falhas (Fault)148
Gerncia de configurao (Configuration)149
Gerncia de contabilidade (Accounting)150
Gerncia de desempenho (Performance)151
Gerncia de segurana (Security)152
Ferramentas livres153
Zabbix153
Instalao do Zabbix154
Utilizando o Zabbix155
Nagios159
Instalao do Nagios159
Customizaes do software160
OpenVAS 162
OCS Inventory165
Instalao do OCS Inventory166
vii
Spice Works168
Instalao do SpiceWorks168
NTOPng172
Instalao do NTOPng172
7. Tratamento de registros de ocorrncias (logs) e fluxos de dados

Importncia do registro de ocorrncias175
Como registrar os LOGs 176
O servidor de LOGs (LOGHOST)176
LOGHOST178
O volume de informaes 178
A difcil tarefa de interpretar as mensagens de LOGs179
Definindo uma estratgia de LOGs180
O protocolo Syslog182
Configurando diversos clientes syslog184
Analisando os LOGs 186
Automatizando a anlise de LOGs187
Monitoramento de fluxos190
Introduo190
Como realizada a coleta dos fluxos191
Mtodos de exportao196
Onde ativar as sondas196
Implementaes196
Exemplos de Configuraes199
Consideraes finais201
Referncias203
8. Gerenciamento de performance e qualidade de servio

Introduo205
Demonstrao 206
Viso Geral Sobre QoS207
O modelos de servios QoS fim a fim208
Qos na internet209
Servios Diferenciados211
viii
Condies de provisionamento de trfego em dispositivos de borda para provedores

de servios215
Tipos de servios217
Servio melhor que best-eort 217
Provisionamento e configurao220
Service Level Agreements222
Mecanismos para implementar QoS223
Policy-Based Routing226
Gerenciamento de congestionamento228
Mecanismos para evitar congestionamento229
Mecanismos de policiamento e conformao233
Qualidade de servio na prtica234
Concluso236
Mtricas para o gerenciamento de rede236
Padres para monitorao da rede239
Fatores que influenciam o desempenho de rede239
Atraso fim-a-fim em um sentido241
Atraso fim-a-fim bidirecional (ida e volta)243
Variao do atraso Jitter244
Perda de pacotes em um sentido244
Vazo (largura de banda alcanvel)245
Largura de banda de conteno246
Mtricas de medies passivas247
Atraso em um sentido (One-Way Delay OWD)249
Largura de banda usada249
Fluxos250
Disponibilidade251
Ferramentas de diagnstico/monitorao da rede251
perfSONAR261
General Framework Design (GFD)262
9. Montagem em laboratrio de soluo de gerncia

Introduo269
Implementando Gerenciamento270
Avaliao de Plataformas de Gerenciamento271
ix
Trouble Ticket Systemas (TTS)272

Funes e caractersticas de um Sistema TTS273
Fan (Fully Automated Nagios)274
Nagios275
Objetos disponveis no Nagios e seus relacionamentos276
Plugins do Nagios276
Como monitorar roteadores e swtichs utilizando os plugins do Nagios277
Centreon280
Nareto e NagVis280
Primeiras configuraes281
Integrao Nagios com OpenLdap281
Integrao Nagios com Splunk282
Integrao Nagios com o Cacti283
Integrao Nagios com Puppet283
Integrao Nagios com TTS284
10. Tpicos avanados em gerenciamento

A Internet das Coisas287
Gerenciando a Internet do Futuro 294
Novas abordagens em gerenciamento296
Sistemas especialistas297
DISMAN Distributed Management297
Gerenciamento web-based297
DMTF Distributed Management Task Force298
Gerenciamento de capacidade299
Bibliografia 301

A Escola Superior de Redes (ESR) a unidade da Rede Nacional de Ensino e Pesquisa (RNP)
responsvel pela disseminao do conhecimento em Tecnologias da Informao e Comunicao (TIC). A ESR nasce com a proposta de ser a formadora e disseminadora de competncias
em TIC para o corpo tcnico-administrativo das universidades federais, escolas tcnicas e
unidades federais de pesquisa. Sua misso fundamental realizar a capacitao tcnica do
corpo funcional das organizaes usurias da RNP, para o exerccio de competncias aplicveis ao uso eficaz e eficiente das TIC.
A ESR oferece dezenas de cursos distribudos nas reas temticas: Administrao e Projeto
de Redes, Administrao de Sistemas, Segurana, Mdias de Suporte Colaborao Digital e
Governana de TI.
A ESR tambm participa de diversos projetos de interesse pblico, como a elaborao e
execuo de planos de capacitao para formao de multiplicadores para projetos educacionais como: formao no uso da conferncia web para a Universidade Aberta do Brasil
(UAB), formao do suporte tcnico de laboratrios do Proinfo e criao de um conjunto de
cartilhas sobre redes sem fi o para o programa Um Computador por Aluno (UCA).
A metodologia da ESR
A fi losofi a pedaggica e a metodologia que orientam os cursos da ESR so baseadas na
aprendizagem como construo do conhecimento por meio da resoluo de problemas tpicos da realidade do profissional em formao. Os resultados obtidos nos cursos de natureza
terico-prtica so otimizados, pois o instrutor, auxiliado pelo material didtico, atua no
apenas como expositor de conceitos e informaes, mas principalmente como orientador do
aluno na execuo de atividades contextualizadas nas situaes do cotidiano profissional.
A aprendizagem entendida como a resposta do aluno ao desafio de situaes-problema
semelhantes s encontradas na prtica profissional, que so superadas por meio de anlise,
sntese, julgamento, pensamento crtico e construo de hipteses para a resoluo do problema, em abordagem orientada ao desenvolvimento de competncias.
Dessa forma, o instrutor tem participao ativa e dialgica como orientador do aluno para as
atividades em laboratrio. At mesmo a apresentao da teoria no incio da sesso de aprendizagem no considerada uma simples exposio de conceitos e informaes. O instrutor
busca incentivar a participao dos alunos continuamente.
xi
As sesses de aprendizagem onde se do a apresentao dos contedos e a realizao das

atividades prticas tm formato presencial e essencialmente prtico, utilizando tcnicas de
estudo dirigido individual, trabalho em equipe e prticas orientadas para o contexto de atuao do futuro especialista que se pretende formar.
As sesses de aprendizagem desenvolvem-se em trs etapas, com predominncia de tempo
para as atividades prticas, conforme descrio a seguir:
Primeira etapa: apresentao da teoria e esclarecimento de dvidas (de 60 a 90 minutos).
O instrutor apresenta, de maneira sinttica, os conceitos tericos correspondentes ao tema
da sesso de aprendizagem, com auxlio de slides em formato PowerPoint. O instrutor levanta
questes sobre o contedo dos slides em vez de apenas apresent-los, convidando a turma
reflexo e participao. Isso evita que as apresentaes sejam montonas e que o aluno se
coloque em posio de passividade, o que reduziria a aprendizagem.
Segunda etapa: atividades prticas de aprendizagem (de 120 a 150 minutos).
Esta etapa a essncia dos cursos da ESR. A maioria das atividades dos cursos assncrona e
realizada em duplas de alunos, que acompanham o ritmo do roteiro de atividades proposto no
livro de apoio. Instrutor e monitor circulam entre as duplas para solucionar dvidas e oferecer
explicaes complementares.
Terceira etapa: discusso das atividades realizadas (30 minutos).
O instrutor comenta cada atividade, apresentando uma das solues possveis para resolv-la,
devendo ater-se quelas que geram maior dificuldade e polmica. Os alunos so convidados a
comentar as solues encontradas e o instrutor retoma tpicos que tenham gerado dvidas,
estimulando a participao dos alunos. O instrutor sempre estimula os alunos a encontrarem
solues alternativas s sugeridas por ele e pelos colegas e, caso existam, a coment-las.
Sobre o curso
A Gerncia de Redes de Computadores uma funo crtica em redes de grande porte,
uma vez que a complexidade de equipamentos, protocolos e aplicaes torna necessria a
utilizao de ferramentas de software sofisticadas, capazes de diagnosticar em tempo real
potenciais problemas de trfego, falhas de equipamentos e, principalmente, reduo na
qualidade do servio.
Esse curso apresenta os conceitos bsicos de gerenciamento, as arquiteturas de software
envolvidas, aplicaes e ferramentas de diagnstico.
A quem se destina
A profissionais de TI envolvidos na gerncia de redes e controle de qualidade, especialistas
em redes de computadores e demais profissionais de TI interessados na operao e controle
de redes de computadores.
Convenes utilizadas neste livro

As seguintes convenes tipogrficas so usadas neste livro:
Itlico
Indica nomes de arquivos e referncias bibliogrficas relacionadas ao longo do texto.
xii
Largura constante
Indica comandos e suas opes, variveis e atributos, contedo de arquivos e resultado da sada
de comandos. Comandos que sero digitados pelo usurio so grifados em negrito e possuem
o prefixo do ambiente em uso (no Linux normalmente # ou $, enquanto no Windows C:\).
Contedo de slide q
Indica o contedo dos slides referentes ao curso apresentados em sala de aula.
Smbolo w
Indica referncia complementar disponvel em site ou pgina na internet.
Smbolo d
Indica um documento como referncia complementar.
Smbolo v
Indica um vdeo como referncia complementar.
Smbolo s
Indica um arquivo de adio como referncia complementar.
Smbolo !
Indica um aviso ou precauo a ser considerada.
Smbolo p
Indica questionamentos que estimulam a reflexo ou apresenta contedo de apoio ao
entendimento do tema em questo.
Smbolo l
Indica notas e informaes complementares como dicas, sugestes de leitura adicional ou
mesmo uma observao.
Permisses de uso
Todos os direitos reservados RNP.
Agradecemos sempre citar esta fonte quando incluir parte deste livro em outra obra.
Exemplo de citao: TORRES, Pedro et al. Administrao de Sistemas Linux: Redes e Segurana.
Rio de Janeiro: Escola Superior de Redes, RNP, 2013.
Comentrios e perguntas
Para enviar comentrios e perguntas sobre esta publicao:
Escola Superior de Redes RNP
Endereo: Av. Lauro Mller 116 sala 1103 Botafogo
Rio de Janeiro RJ 22290-906
E-mail: info@esr.rnp.br
xiii
Sobre o autor
Mauro Tapajs Santos possui Graduao e Mestrado em Engenharia Eltrica pela Universidade de Braslia. Atualmente servidor Analista de Planejamento e Oramento na rea de
TI da Secretaria de Oramento Federal do Ministrio do Planejamento, Oramento e Gesto.
J foi coordenador de operao na Infovia da CNI (Confederao Nacional da Indstria) pela
Impsat (hoje Global Crossing). Foi analista de TI em empresas do mercado de Telecom e no
Ministrio Pblico da Unio e professor universitrio por quase 10 anos. Tem experincia na
rea de TI em praticamente todas suas vertentes tais como: redes, desenvolvimento, infraestrutura e governana. Atualmente tambm tem conhecimentos sobre Oramento Pblico.
Liane Tarouco possui Graduao em Licenciatura em Fsica pela Universidade Federal do Rio
Grande do Sul (1970), mestrado em Cincias da Computao pela Universidade Federal do
Rio Grande do Sul (1976) e doutorado em Engenharia Eltrica/Sistema Digitais pela Universidade de So Paulo (1990). Atualmente professora titular da Universidade Federal do Rio
Grande do Sul. Desenvolve atividade docente e de pesquisa na rea de Cincia da Computao, com nfase em Redes de Computadores e em Gerncia de Rede. Atua tambm como
pesquisadora e docente junto ao Programa de Ps-Graduao em Informtica na Educao.
Leandro Bertholdo possui graduao em Bacharelado Em Informtica pela Pontifcia
Universidade Catlica do Rio Grande do Sul (1993) e mestrado em Cincias da Computao
pela Universidade Federal do Rio Grande do Sul (1996). Atualmente professor da Universidade Federal do Rio Grande do Sul e coordenador tcnico do POP da RNP no Rio Grande
do Sul (2000). Tem experincia na rea de Cincia da Computao, com nfase em Teleinformtica, atuando principalmente nos seguintes temas: redes de computadores, ipv6,
gerncia de rede, gerncia de segurana e segurana de redes.
Francisco Marcelo Marques Lima Mestre em Engenharia Eltrica pela Universidade de
Braslia (2009), Mestre em Liderana pela Universidade de Santo Amaro (2007) e ps-graduado
em Segurana de Redes de Computadores pela Universidade Catlica de Braslia (2003).
Atualmente exerce as funes de Coordenador dos Cursos de Redes de Computadores e
Segurana da Informao do IESB e Analista em TI do MPOG cedido para a CGU/PR, alm
de atuar como instrutor/revisor dos cursos de segurana e redes na RNP e instrutor dos
cursos de Planejamento Estratgico (PDTI) e Gesto de Contratos de TI (GCTI) na ENAP.
Possui mais de 15 anos de experincia na rea de Cincia da Computao com nfase em
Segurana da Informao, Redes e Construo de Software tendo exercido funes como:
Coordenador Geral de TI do INCRA (DAS 4).
Vanner Vasconcellos trabalha no Ponto de Presena no Estado do Par (PoP-PA) da Rede
Nacional de Ensino e Pesquisa (RNP) como Coordenador Tcnico e tambm professor do
Curso de Especializao em Suporte a Rede de Computadores e Internet da Universidade
Federal do Par (UFPA). graduado em Tecnologia de Processamento de Dados pelo Centro
de Universitrio do Par (CESUPA), especialista em Redes de Computadores pela UFPA.
Com mais de 20 anos de experincia em TI, atua na RNP h 17 anos na rea de gerncia de
infraestrutura de redes e datacenter, tendo participado de projetos pioneiros de conectividade e Internet no Par, Amap e Maranho.
xiv
1
Conhecer a forma de estruturao; Entender os objetos gerenciveis; Compreender
a SMI Estrutura da Informao de Gerenciamento; Entender como funciona o
Management Information Base (MIB); Conhecer ASN.1 e BER.
conceitos
Necessidades de gerenciamento; reas de gerenciamento;

Arquiteturas de gerenciamento.
Importncia do gerenciamento
11 Crescimento vertiginoso das LANs e WANs.
11 Mais aplicaes e usurios gerando complexidade: equipamentos, hardware e software heterogneos; empresas dependentes das redes para elevar eficincia e lucros.
11 Necessidade de gerenciamento visando a coordenao (controle de atividades e
monitorao do uso) de recursos materiais (modems, roteadores, enlaces fsicos etc.)
e lgicos (protocolos, configuraes etc.), fisicamente distribudos na rede, assegurando, na medida do possvel, confiabilidade e performance aceitveis e segurana
das informaes.
O contnuo crescimento em nmero e diversidade dos componentes das redes de computadores tm tornado a atividade de gerenciamento de rede cada vez mais complexa. Isso
se agrava quando esto envolvidos muitos fornecedores. O impacto de uma falha na rede
produz uma perda na receita ou impossibilidade de prestao de servios que causa transtornos financeiros, institucionais e, por vezes, com consequncias bastante srias e implicaes at mesmo de cunho legal.
O isolamento e o teste dos problemas das redes tornaram-se mais difceis devido diversidade dos nveis do pessoal envolvido e variao nas formas de monitorao usadas pelos
fornecedores dos equipamentos.
Uma pesquisa realizada por Blum (2008) apontou as barreiras para o aprimoramento
dos centros de gerncia e operao de rede (Network Operation Center NOC). A tabela
seguinte indica o resultado de uma pesquisa realizada por Blum em relao s principais
barreiras para as metas de qualidade no gerenciamento de rede.
Captulo 1 - Introduo gerncia de redes
objetivos
Introduo gerncia de redes
A tabela seguinte indica o obstculo percebido e a percentagem de instituies que participaram da pesquisa e indicaram aquele fator. Muitas instituies indicaram mais de um
obstculo e por isso a soma dos percentuais maior do que 100%.
Barreira ao aprimoramento Capacidade do NOC
Falta de equipe especializada
56
Justificar custo/benefcio para a administrao
47
Custo dos produtos muito alto
45
Falta de produtos ou ferramentas
40
Dificuldade de implementar produtos ou ferramentas
40
Treinamento disponvel inadequado
37
Produtos e ferramentas disponveis no atendem requisitos
33
Falta de mtricas
33
Falta de Acordos de Nvel e Servio (SLA Service Level Agreement)
30
Rotatividade excessiva do pessoal
28
Segundo essa pesquisa, os principais servios oferecidos pelo centro de gerenciamento de

rede e de TI incluam a administrao de servidores, redes locais, redes virtuais, segurana,
equipamentos dos clientes, conexes de longa distncia, aplicaes, VOIP e at servios
convencionais de telefonia. Gerenciamento da rede local era o mais frequente, seguido das
VPNs e dos servidores. VOIP foi o servio que estava crescendo mais intensamente.
A preocupao com a qualificao da equipe para cuidar de todas essas questes era um dos
pontos destacados e isso deriva do fato de que novas tecnologias surgem constantemente
requerendo um contnuo esforo da equipe para implementar e administrar os novos servios
e tecnologia que so cada vez mais complexas conforme salientado por Farrel (2009).
Em vista desses fatores, o desafio de manter custos sob controle, treinar novamente
a equipe, reter a equipe e recrutar novos profissionais constante.
Atuao do gerente de redes

A atividade de gerenciamento de rede usualmente exercida por um grupo de pessoas que
Gerncia de Redes de Computadores
inclui, no mnimo, um operador de rede e um administrador de rede.
Normalmente, o operador controlador da rede realiza a contnua monitorao da rede a partir

de uma estao onde so exibidos os dados sobre a situao da rede e de seus componentes.
Tabela 1.1
Pesquisa realizada
por Blum (2008).
Figura 1.1
Exemplo do
gerenciamento
de rede.
11 Coleta de dados: processo automtico (ou no) de monitorao dos recursos
gerenciados;
11 Diagnstico: tratamento e anlise realizados a partir dos dados coletados (determinao da causa);
11 Ao: reao (ou no) ao problema.
Gerenciamento significa ter o controle e poder agir em funo de informaes coletadas que
mostram situaes determinadas. Por exemplo: um link de dados pode apresentar atraso;
uma ao possvel seria rotear novamente o trfego para outro link.
A gerncia de redes de computadores uma das reas mais complexas quando falamos em
gerncia de TI, pois os contratos de prestao de servios em TI esto cada vez mais criteriosos, envolvendo compromissos com garantias de qualidade. Portanto, preciso poder
identificar todos os ativos de rede, monitor-los, coletando informaes relevantes que
sero exibidas em grficos e podero ser analisadas na medida em que vo sendo recebidas
e com vistas a determinar anomalias de comportamento e acionar o atendimento, quando
necessrio. Esses procedimentos visam facilitar a identificao e soluo dos problemas de
maneira rpida e eficaz.
Atividades comuns de gerenciamento

11 Monitoramento.
11 Controle.
Para o gerenciamento de redes de computadores, uma alternativa usar a prpria infraestrutura existente para alcanar os elementos ou pontos definidos da rede, na busca por
reconfigurao). Outra opo seria montar uma rede paralela rede existente, que tivesse
interseces nos pontos de interesse.
A situao atual das redes que os equipamentos nelas usados tm condies para prover uma
grande quantidade de informaes sobre seu prprio funcionamento, bem como de outros
dispositivos no gerenciveis e que esto tambm conectados (volume de trfego, erros etc.).
Adicionalmente, os componentes de software tambm tm sido estruturados de modo a usar
a mesma estratgia, e so atualmente desenvolvidos para proporcionar grande quantidade de
informaes sobre seu prprio funcionamento (volume de transaes atendidas, desempenho
etc.). Em funo disso, a quantidade e diversidade de informaes sobre o funcionamento das
redes, passveis de obteno da rede, de seus componentes e servios, cresce continuamente.
informaes e no disparo de aes sobre esses equipamentos (testes ou comandos de
Essa situao tende a ocasionar mais dificuldades na determinao de problemas.

3
Por isso, alm da necessidade de monitorar a rede, existe a necessidade de reconhecer, manipular e tratar toda essa informao obtida de forma a permitir diagnsticos mais precisos
das causas dos problemas e que levem a solues mais rapidamente. A atividade de gerenciamento da rede envolve uma gama de atividades mutuamente interdependentes, tais como:
11 Registrar a ocorrncia de eventos;
11 Estabelecer critrios para o disparo de alarmes;

11 Detectar e diagnosticar a ocorrncia de falhas;
11 Conhecer e controlar alteraes nos equipamentos;
11 Acompanhar o desempenho da rede e dos servios de rede;
11 Garantir a segurana;
11 Contabilizar recursos;
11 Verificar Acordo de Nvel de Servio (ANS) estipulado no contrato.
A figura 1.2 ilustra uma situao tpica nesse contexto. Os elementos gerenciados (roteadores,
switches, servidores etc.) continuamente registram dados sobre seu prprio funcionamento.
Network Management System (NMS)

Elemento gerenciado
Taxa de erros
Limiar
Contador de erros
Figura 1.2
Viso geral do
gerenciamento
de rede.
Polling
Esses dados podem ser enviados sob demanda (polling) ou, periodicamente, para uma estao
de gerncia onde um sistema de gerenciamento de rede (NMS Network Management System)
coleta, soma, compara com limiares pr-estabelecidos informaes sobre indicadores de
desempenho, tais como quantidade de erros por unidade de tempo, volume de trfego etc.).
Os dados tratados so apresentados em grficos para a equipe de gerncia de rede, mas
podem tambm gerar mensagens de alerta, em caso de problemas. Essas mensagens
podem ser encaminhadas de diversas formas (e-mail, torpedos etc.) para os operadores
humanos responsveis por fazer o diagnstico e restaurar os padres de operao da rede
a valores aceitveis.
O que gerenciar?
11 Equipamentos de rede.
11 Aplicaes e servios de rede.
11 Banco de dados.
11 Dispositivos de armazenamento.
Aplicaes de gerenciamento so aplicaes que tratam de dados derivados do funcionamento da rede e de seus servios.
No mbito de redes, vrias so as possibilidades de equipamentos ou itens passveis de

monitoramento e controle. Em um nvel mais baixo, h a figura do elemento de rede (equipamento). J em nvel mais elevado h a considerao das redes como um todo (como servios). Praticamente qualquer coisa na rede pode ser gerenciada para permitir a exata noo
da realidade da rede em questo.
A forma como as informaes de gerenciamento da rede fluem definida por padres de
gerncia de rede que especificam a forma de representar os dados sobre a rede e a forma
de comunicar esses dados para a aplicao de gerenciamento.
Hoje em dia, todos os equipamentos que compem uma rede de comunicao de dados,
mesmo que sejam de fabricantes diferentes, possuem compatibilidade com os protocolos
de gerenciamento de redes de computadores padronizados, possibilitando assim a interoperabilidades entre redes hbridas.
reas funcionais de gerenciamento (modelo OSI)

O modelo Open System Interconection (OSI), definido pela International Standard Organization (ISO), foi um primeiro esforo para produzir uma forma padronizada de interoperao
entre sistemas. Na arquitetura de rede preconizada pela Isso, as funes necessrias para a
interconexo entre sistemas foram organizadas sete camadas, tal como ilustrado na figura 1.3.
Cada camada seria responsvel por uma parte da tarefa. A camada inferior, denominada de
Camada do Nvel Fsico, cuida do envio e recebimento dos dados binrios (bits) atravs do
interface fsico. Essa camada agrupa os bits recebidos em quadros (ou frames), passando
para a camada de enlace, que vai analisar os dados que compem a parte do cabealho e as
demais informaes contidas no quadro. Respostas podem ser geradas diretamente pela
camada de enlace quando necessrio (confirmaes de recebimento correto ou pedidos de
Figura 1.3
Modelo OSI.
Aplicao
Apresentao
Sesso
Transporte
Rede
Enlace de dados
Fsica
Se o quadro contm dados que devem ser tratados pelas camadas superiores, esses so
passados para a camada imediatamente superior. Esse procedimento continua at os dados
chegarem camada de aplicao, quando so ento passados para a aplicao apropriada.
A funo de comunicao das informaes de gerenciamento proposta para ser implementada
na camada de aplicao. Assim, o protocolo de gerenciamento um protocolo entre aplicaes.
Na arquitetura usada na internet, houve uma simplificao desse modelo em camadas, que
passou a contemplar apenas as camadas fsica, de enlace, de rede, de transporte e de aplicao.
Mas a funo de gerenciamento tambm suposta ser realizada na camada de aplicao.
retransmisso dos dados, por exemplo).
Nas duas arquiteturas, a funo de gerenciamento de redes foi organizada em cinco categorias, algumas vezes referidas pela sigla FCAPS (Fault, Configuration, Accounting, Performance,
Security). Assim, o gerenciamento de redes costuma ser estruturado nestas cinco reas:
11 Gerenciamento de falhas;
11 Gerenciamento de desempenho;
11 Gerenciamento de configurao;
11 Gerenciamento de segurana;
11 Gerenciamento de contabilizao.
Esas reas, definidas pelo modelo OSI de gerenciamento, mas tambm usada no modelo
internet de gerenciamento, so uma referncia s atividades e focos possveis dentro de
uma soluo de gerenciamento.
Assim, pode existir mais de uma equipe encarregada de gerenciar diferentes reas. Por
exemplo, uma equipe pode estar encarregada de gerenciar configurao e problemas,
enquanto outra pode estar encarregada da segurana da rede e concentra sua coleta de
informaes nesse sentido.
Itens como nmero de acessos, tentativas de login e servios de rede acessados so
informaes teis caso o objetivo seja o gerenciamento de segurana. Outros itens, como
nmero de quedas de um link ou taxa de erros em uma LAN, no so to importantes para a
gerncia de segurana como seriam para o gerenciamento de desempenho.
Gerenciamento de falhas
O gerenciamento de falhas o conjunto de facilidades que habilita a deteco, isolamento
e correo de condies anormais de operao do ambiente. Tais condies podem ser
persistentes ou transientes, e os problemas so manifestados como erros. O gerenciamento
de falhas demanda facilidades para: manter e examinar logs de erros, receber e registrar
notificao de erros e atuar em funo destas, rastrear problemas, executar sequncias de
testes de diagnstico e corrigir problemas com vistas a assegurar a operao contnua da
rede. As principais funes dessa categoria de gerenciamento da rede so:
11 Detecta, isola e registra o problema;
11 Registra as ocorrncias;
11 Executa testes de diagnstico;
11 Realiza a investigao do ocorrido;
11 Comportamento proativo (prefervel) ou reativo.
O gerenciamento de falhas envolve usualmente as seguintes etapas:

11 Deteco dos sintomas do problema;
11 Isolamento do problema;
11 Reparo do problema automaticamente (se possvel) ou manualmente;
11 Teste do reparo em todos os subsistemas importantes;
11 Registro da deteco e do modo como o problema foi resolvido.
Gerenciamento de desempenho
A preocupao com o desempenho da rede deve ser constante, pois medida que o padro
de uso se altera, mudam as demandas sobre os canais de comunicao, sobre os elementos
ativos da rede (roteadores, switches) e sobre os equipamentos envolvidos na prestao dos
servios. Quando um usurio percebe uma lentido na resposta a suas demandas, no tem
como saber qual o recurso responsvel pelo baixo desempenho; ele apenas diz que a rede
est lenta e leva essa reclamao at a central de atendimento. Mas a equipe de gerenciamento de rede pode e deve ter condies para no apenas identificar a causa de gargalos,
mas tambm antecipar tais situaes a partir da observao sistemtica da tendncia de
crescimento da demanda.
Naturalmente, esse acompanhamento necessita de ferramentas que registrem os dados
relativos demanda e sejam capazes de apresentar o resultado da sua anlise em forma de
mdias, grficos etc. Nesse sentido, a gerncia de desempenho tem um conjunto de incumbncias que envolve:
11 Controlar o comportamento dos recursos de rede;
11 Avaliar as atividades de comunicao oferecidas na rede;

11 Monitorar a operao diria da rede;
11 Localizar pontos crticos no sistema (gargalos ou pontos de falha que inibiriam parte
substancial do uso da rede);
11 Registrar dados de operao;
11 Auxiliar funes anlise da demanda de planejamento de capacidade.
Gerenciamento de configurao
Gerenciamento de configurao o conjunto de facilidades que exerce o controle sobre
o que est na rede: identifica, coleta e prov informaes sobre o status dos recursos da
rede de forma que torne possvel a qualquer instante conhecer o que est operacional, em
uso ou simplesmente disponvel para utilizao em caso de emergncia. Essa categoria de
funes tm as seguintes caractersticas:
11 Considera a rede como um sistema dinmico em permanente transformao;
11 Prov manuteno da estrutura fsica e lgica da rede;

11 Acompanha o ciclo de vida do componente e sua configurao;
11 Monitora cada componente, documentando as trocas que devem manter os requisitos bsicos estabelecidos;
11 Mantm registros dos status de cada componente (topologia e dispositivos);
11 Executa alteraes na configurao do sistema, visando isolar falhas, aliviar situaes
crticas ou atender as necessidades dos usurios.
Gerenciamento de segurana
O gerenciamento de segurana relaciona-se com os aspectos de acompanhamento e controle do uso da rede para assegurar seu uso apropriado. Isso implica no uso de mecanismos
de autenticao, controlar autorizaes e permisses de acesso associadas, gerenciar
chaves de segurana e uso apropriado da rede. Essa categoria de funes a que:
11 Identifica componentes em um nvel apropriado e suas relaes (topologia);
11 Cuida dos mecanismos e procedimentos de proteo;
11 Cria, apaga e controla os servios e mecanismos de segurana;

11 Trata da distribuio da informao relacionada com segurana e seus eventos;
11 Mantm registros de eventos relativos segurana;
11 Suporta e garante a poltica de segurana adotada.
Gerenciamento de contabilizao
O gerenciamento de contabilizao o conjunto de facilidades que permite o controle e
eventualmente a tarifao pelo uso dos recursos. Isso implica em informar os usurios
sobre os custos incorridos ou recursos consumidos, estabelecer limites para o uso dos
recursos, combinar os custos quando so usados recursos variados, tal como por exemplo
meios de comunicao. Nesse sentido, essa categoria de funes de gerenciamento de rede
envolve atribuies tais como:
11 Controla recursos;
11 Permite que tarifas sejam aplicadas aos recursos de rede (discos compartilhados,
banda, arquivamento remoto, servios de telecomunicaes, e-mails etc.);
11 Viabiliza a identificao de custos para a rede e seus recursos;
11 Mantm limites de consumo;
11 Efetua a melhor distribuio de recursos e alimenta trabalhos de planejamento.
Gerenciamento dentro do modelo OSI

Uma aplicao de gerenciamento vai atingir os elementos de rede e suas entidades na
maioria das vezes atravs da prpria rede. Isso cria uma preocupao com o quanto a
soluo de gerenciamento pesar sobre a prpria rede que se quer gerenciar.
Aplicao
Conectividade lgica
Aplicao de Gerenciamento de Rede
Apresentao
Sesso
Interconexo
Transporte
Gerenciamento de Interconexo
Rede
Conectividade local
Enlace de dados
Gerenciamento de Tecnologia de Rede
Fsica
A aplicao de gerenciamento poder visualizar nveis de conectividade e trabalhar em
qualquer um deles:
11 Nvel de conectividade local (tecnologia de rede);
11 Nvel de interconexo;
11 Nvel de conectividade lgica (aplicao).
Figura 1.4
Gerenciamento
dentro do
Modelo OSI.
Conceitos
11 Informao de gerncia.
11 Protocolos de gerncia.
11 Arquitetura de gerenciamento:
22 Fornece a estrutura geral do sistema de gerncia.
22 Descreve componentes dentro do sistema e suas funes.
22 Mostra os relacionamentos entre os componentes.
Uma aplicao de gerncia nada mais do que uma aplicao que trata de dados. Esses
dados devero obedecer a determinada estrutura para que seja possvel criar solues de
gerenciamento que atuem sobre os mais diversos ambientes de rede.
Um protocolo de gerncia normalmente um protocolo de nvel de aplicao (possui especificidade inerente ao gerenciamento de rede). Ele visa atender as demandas de comunicao
entre as entidades definidas na arquitetura de gerenciamento.
As duas arquiteturas clssicas de gerenciamento de rede so:
11 Arquitetura OSI de gerenciamento, derivada dos padres de sistemas abertos Open
Systems Interconnection (OSI), que mais antiga e foi prevista para ser usada em um
contexto de rede onde os sistemas interoperam usando os protocolos padronizados para
cada uma das camadas do modelo OSI. Nesse caso, o protocolo de gerenciamento de
rede usado o Common Management Information Protocol (CMIP).
11 Arquitetura baseada no modelo Simple Network Management Protocol (SNMP), derivada
dos padres internet/TCP-IP, que atualmente a mais disseminada. Embora tenha sido
derivada da arquitetura de gerenciamento OSI, foi simplificada, como destaca o prprio
nome do protocolo.
Modelo de comunicao
11 Preocupa-se em definir como os dados de gerenciamento so comunicados entre os
processos do gerente e do agente.

11 Modelo usado no protocolo SNMP envolve o uso das entidades gerente e agente.
Gerente
SNMP
Figura 1.5
Modelo de
comunicao.
Agente SNMP
Objetos
gerenciados
Nesse modelo, a comunicao estabelecida entre o gerente, onde executado o Network
Management System (NMS), que a aplicao de gerenciamento de rede executada em
uma estao de gerncia, e um agente que um mdulo sendo executado no dispositivo de
rede (roteador, switch, computador de mesa, servidor etc.). A responsabilidade do agente
IP Network
manter e atualizar dados sobre o funcionamento do dispositivo. Esses dados so armazenados sob a forma de objetos gerenciados e consistem em representaes de valores de
contadores, status, limiares etc. Os objetos gerenciados so estruturados em uma Management Information Base (MIB).
Um agente pode conter um grande nmero de objetos gerenciados e atravs deles

que o NMS vai poder descobrir o que est acontecendo em cada dispositivo gerenciado
na rede. Em alguns casos, os agentes tambm podem incluir dados sobre outros dispositivos, a partir da observao direta ou indireta de seu comportamento e transmisses.
Modelo funcional
O modelo funcional de gerenciamento de rede definido em funo das cinco reas de interesse, propostas pela ISO, modelo FCAPS (Fault, Configuration, Accounting, Performance,
Security), que indicam a direo do esforo dos que desenvolvem e empregam solues
para gerenciar redes e sistemas. Assim, os produtos e servios de gerenciamento de rede
so organizados com base nesse modelo funcional, e as aplicaes de gerenciamento de
redes tambm costumam ser organizadas com base nessas cinco reas funcionais:
11 Falhas;
11 Configurao;
11 Contabilizao;
11 Desempenho;
11 Segurana.
Para apoiar essas reas so utilizadas diversas ferramentas de gerenciamento. Algumas
so mais bsicas, acionadas mediante o uso de uma simples interface de linha de comando.
Outras so mais complexas, sendo invocadas atravs do uso de programas com interfaces
grficas e que por vezes envolvem um trabalho prvio de configurao.
Como um exemplo, temos o caso da figura 1.6. Supondo que o usurio da subrede B no
consiga acessar a internet, quais providncias para diagnstico inicial da situao poderiam
ser desencadeadas?
Firewall
Firewall
Proxy
10
Subrede A
Internet
Subrede B
Figura 1.6
Como detectar
se um dispositivo
da rede est
operacional.
Buscando solucionar esse problema usando como base as cinco reas funcionais, vrios
procedimentos poderiam ser desencadeados e envolver o uso de ferramentas de apoio para
diagnosticar e solucionar o problema.
A primeira categoria, o gerenciamento de falhas ou problemas, poderia ser executada de
acordo com as cinco etapas do gerenciamento de falhas anteriormente apresentadas.
Deteco dos sintomas do problema

Nessa fase, seria necessrio investigar se a percepo do usurio de que no conseguia
acessar algum servio remota era derivada de um problema remoto ou local e nesse
segundo caso se o problema era sentido tambm nas demais mquinas e subredes. Umas
das abordagens mais comuns utilizadas tanto por tcnicos da rede como pelos prprios
usurios envolve o uso de comandos bsicos dos sistemas, como ping e traceroute.
Assim, inicialmente, poderia ser invocado o comando ping, atravs da janela de comando da
estao de trabalho do usurio na subrede B, para um primeiro teste. Ping um utilitrio
que usa o protocolo ICMP para testar a conectividade entre equipamentos. Seu funcionamento consiste no envio de pacotes para o equipamento de destino e na escuta das
respostas. Se o equipamento de destino estiver ativo, uma resposta devolvida ao computador solicitante na qual indicado o tempo consumido tal como no exemplo seguinte.
Exemplo de uso do ping para testar conectividade com um roteador em uma rede interna,
que poderia ser o roteador mostrado na figura 1.5 e que interliga as subredes A e B com a
conexo com a internet, que passa pelo firewall. Esse roteador poderia estar usando um
endereamento IP privativo e o comando ping poderia ser direcionado inicialmente para
esse endereo.
C:\>ping 192.168.1.1
Disparando 192.168.1.1 com 32 bytes de dados:
Resposta de 192.168.1.1: bytes=32 tempo=3ms TTL=64
Estatsticas do Ping para 192.168.1.1:
Saiba mais
O tempo, em milissegundos, no exemplo,

mostra que o roteador
estava muito prximo
do computador que
enviou o ping, e a
resposta no tardou
muito.
perda),
Aproximar um nmero redondo de vezes em milissegundos:
Mnimo = 1ms, Mximo = 3ms, Mdia = 2ms
Nesse exemplo, as mensagens ICMP enviadas usaram o tamanho padro de 32 bytes. O TTL
de 64 indica que esse era o nmero mximo de nodos atravessados na rede pelo pacote
para tentar chegar ao endereo IP 192.168.1.1. Isso evita que um pacote gerado pelo ping
fique circulando na rede indefinidamente em caso de problema de roteamento.
Se esse procedimento no tivesse conseguido obter resposta do equipamento ao qual o
ping foi dirigido, a mensagem recebida seria algo tal como:
Pacotes: Enviados = 4, Recebidos = 4, Perdidos = 0 (0% de
11
C:\>ping 198.168.2.1
Disparando 198.168.2.1 com 32 bytes de dados:
Esgotado o tempo limite do pedido.
Estatsticas do Ping para 198.168.2.1:
Pacotes: Enviados = 4, Recebidos = 0, Perdidos = 4 (100% de perda),
Nesse caso, poderamos concluir que o equipamento 198.168.2.1 no existe na rede ou est
inoperante. Essa dvida poderia ser resolvida com um outro comando bsico que indicaria
o caminho (conjunto de roteadores) at o equipamento destino. Esse teste poderia ser realizado com o comando traceroute, que uma ferramenta de diagnstico que rastreia a rota
de um pacote atravs de uma rede de computadores que utiliza o protocolo IP. Seu funcionamento est baseado no uso do campo time-to-live (TTL) do pacote IPv4, destinado a limitar
o tempo de vida dele. Esse valor decrementado a cada vez que o pacote encaminhado
por um roteador. Ao atingir o valor zero, o pacote descartado e o originador alertado por
uma mensagem ICMP TIME_EXCEEDED.
Atravs da manipulao do campo TTL (que recebe valores que vo sendo incrementados
de uma unidade a cada passo), uma srie de datagramas UDP dirigidos ao destino final
vo sendo gerados com diferentes e crescentes valores de TTL. Assim, possvel receber
essa mensagem de TIME-EXCEEDED de cada um dos roteadores no caminho do pacote e
calcular o tempo que foi usado para chegar at cada um dos roteadores intermedirios.
Existem implementaes desse comando para praticamente todos os Sistemas Operacionais, incluindo aqueles usados em roteadores. A maneira de invocar o comando pode variar
ligeiramente (tracert em ambiente Windows, traceroute em outros ambientes). Um exemplo
de resultado passvel de ser obtido com o comando traceroute apresentado a seguir:
C:\>tracert www.rnp.br
Rastreando a rota para www.rnp.br [200.130.35.4] com no mximo 30 saltos:

1
1714 ms
1 ms
2 ms
192.168.1.1
11 ms
16 ms
8 ms
10.79.4.1
12 ms
11 ms
11 ms
c915c002.virtua.com.br [201.21.192.2]
11 ms
10 ms
11 ms
as1916.rs.ptt.br [200.219.143.3]
19 ms
16 ms
17 ms
rs-sc-10g-oi.bkb.rnp.br [200.143.252.58]
28 ms
30 ms
35 ms
sc-sp-10g-oi.bkb.rnp.br [200.143.252.65]
71 ms
48 ms
37 ms
sp-rj-10g-oi.bkb.rnp.br [200.143.252.70]
56 ms
62 ms
57 ms
rj-df-10g-oi.bkb.rnp.br [200.143.252.78]
58 ms
56 ms
88 ms
landf-mxdf-10g-int.bkb.rnp.br
[200.143.255.170]
10
12
63 ms
55 ms
55 ms
rt.pop-df.rnp.br [200.130.101.94]
11
57 ms
58 ms
57 ms
kerberos.na-df.rnp.br [200.130.35.4]
Rastreamento concludo.
Essas duas ferramentas poderiam ser usadas no apenas da mquina onde est o usurio
que experimenta o problema, mas tambm de outras mquinas na mesma subrede e em
outras subredes. Isso permitira conhecer a extenso do problema relatado observando a
resposta, por ausncia de resposta em cada caso. No exemplo anterior, possvel constatar
que o acesso desde a mquina onde o tracert foi disparado at o servidor www.rnp.br est
operacional. O passo seguinte seria isolar o problema relatado pelo usurio.
Um aspecto a ressaltar sobre o uso dessas ferramentas bsicas que elas geram trfego na
rede, e isso precisa ser minimizado, sob pena de prejudicar o funcionamento da rede com
excesso de trfego de teste. Outro ponto a atentar que esse trfego pode ser filtrado por
algum roteador ou firewall ao longo da rota, e a ausncia de uma resposta pode ser causada
Observe que o retardo

informado impreciso, pois depende do
trfego encontrado
pelos pacotes usados
nessas ferramentas
ao longo de sua rota,
bem como da carga dos
roteadores envolvidos
no seu encaminhamento e ambos variam
ao longo do tempo.
Isolamento do problema
O isolamento do problema demanda alguma forma de inspeo ou teste dos equipamentos
envolvidos, desde aquele onde o problema foi constatado, at o destino que seu usurio pretende acessar. Dependendo dos resultados dos testes com ping e traceroute, seria possvel
verificar se o equipamento do usurio era o nico a sentir o problema ou se apenas tinha sido
o primeiro a constatar uma falha mais ampla, que inibiria o acesso de todos os equipamentos
de uma ou mais subredes ou at mesmo de todas as mquinas da intranet. A causa poderia
ser uma falha na conexo de sada daquela rede com a internet ou uma indisponibilidade do
servidor remoto. O comando ping mostraria simplesmente se o servidor remoto estava acessvel. O traceroute mostraria se algum problema e impedimento ou excessivo retardo estaria
ocorrendo na rota, a partir de algum ponto. Os tempos de resposta recebidos de cada passo
do rastreamento com o traceroute permitiram averiguar se a rede tem comportamento
normal, degradado ou sem conexo a partir de algum ponto da rota.
Aps isolar a causa do problema identificando o(a) equipamento(s) ou componente(s) de software com comportamento incorreto, o trabalho passaria para a fase de soluo do problema.
Reparo do problema automaticamente (se possvel) ou manualmente

O reparo do problema pode s vezes ser conseguido de forma automtica (ou quase), com
uma reinicializao do equipamento o que pode dirimir algum estado inconsistente do software sendo executado naquela mquina.
Mas em outros casos h que passar ao diagnstico das causas do mau funcionamento, e
isso implica em inspecionar mais detalhadamente aquele equipamento para obter informaes sobre os fatores que poderiam afetar seu comportamento. Essas informaes podem,
em parte, ser obtidas mediante inspeo dos objetos gerenciados e o uso do protocolo
SNMP para efetuar o polling (consulta aos dados do agente SNMP) daquela mquina permite
obter informaes sobre o sistema usado, portas de comunicao, trfego, erros recebidos,
tabelas de roteamento etc. Isso envolve o uso de algum software que pode ser no mnimo
um MIB Browser para obter os dados da MIB do agente SNMP no equipamento sendo analisado. Uma plataforma de gerncia de rede mais completa, tal como Tivoli ou HP Open View,
entre outras, com banco de dados com a definio de todos os equipamentos da rede, sua
topologia e caractersticas proporciona condies para inspecionar remotamente os componentes da rede, tal como ilustrado na figura 1.7.
Saiba mais
por esse processo de filtragem.
13
Estao de
Gerenciamento
de Rede
SNMP
Roteador
Servidor
Switch
Impressora
O resultado da inspeo dos equipamentos mediante o uso de SNMP poderia retornar informaes tais como:
11 Verso do Sistema Operacional e do software de rede, servios providos pelo
equipamento;
11 Localizao do equipamento e pessoa ou setor responsvel por este;
11 Quantidade e tipo de interfaces de rede bem como sua situao operacional e trfego
recebido e enviado (com taxas de erros);
11 Roteador default, rotas;
11 Conexes estabelecidas com aquele equipamento e portas (TCP ou UDP) em uso.
O reparo do equipamento com problemas pode ter de ser feito manualmente envolvendo
substituio ou alterao do software, ajuste de parmetros de configurao ou mesmo
substituio de hardware (interfaces ou mesmo o equipamento como um todo).
Teste do reparo em todos os subsistemas importantes

Quando o processo de reparo suposto estar finalizado, testes de aceitao precisam ser
feitos para avaliar se todos os subsistemas envolvidos e dependentes daquele que experimentou problemas de funcionamento encontram-se operacionais em condies normais.
Os comandos de ping e traceroute podem ser usados para verificar a conectividade. No caso
de uso de plataformas de gerenciamento, diagramas da rede com cores associadas ao status
dos dispositivos (verde para funcionamento normal, amarelo com erros intermitentes e
vermelho para dispositivo com problema, por exemplo) j passam a mostrar a situao dos
dispositivos da rede.
14
Figura 1.7
SNMP para
inspecionar
equipamentos
da rede.
Figura 1.8
Dados de status
dos dispositivos
na estao de
gerenciamento
da rede.
Todavia, essas indicaes podem ser incompletas, evidenciando apenas que existe conectividade a nvel de rede. Testes realizados a nvel de aplicao tambm necessitam ser
realizados para verificar se os servios envolvidos foram reiniciados apropriadamente. Em
algumas situaes, os servios executados em um servidor no retornam automaticamente
aps uma reinicializao como era de esperar. Em outras situaes, o comportamento
anmalo de uma estao pode ter ocasionado uma alterao nas regras do firewall, que
passou a inibir alguns tipos de acessos daquela estao.
Registro da deteco e do modo como o problema foi resolvido

Problemas tendem a se repetir na rede e a utilizao de um Sistema de Registro de problemas auxilia a equipe de gerncia de rede no diagnstico do problema com a possibilidade de apresentao de problemas anteriores ocorridos com caractersticas similares, mas
tambm agilizam o processo de controle da rede, porque permitem uma comunicao mais
direta com os responsveis pela gerncia da rede. O Registro de Problema deve prover
iniciativa sem que para isso tenha de consultar outro operador que pode ter atuado naquele
caso em um turno anterior.
O sistema de registro de problemas deve permitir um melhor escalonamento de problemas
atribuindo prioridades aos mesmos. Os supervisores e operadores podero tomar decises
acerca da necessidade ou no de mais pessoal ser alocado a um determinado problema, e a
prioridade dos registros pode mudar de acordo com a hora do dia ou em resposta a alarmes
de tempo. Um timeout pode ser associado para cada registro de problema. Caso o problema no seja resolvido em tempo, automaticamente acionado um alarme.
O sistema de registro de problemas fornece mecanismos para a obteno de estatsticas,
tais como Tempo mdio entre falhas (Mean Time Between Failures MTBF) e Tempo
mdio de conserto (Mean Time To Repair MTTR).
um histrico completo do problema, de forma que qualquer operador possa tomar alguma
15
A estrutura de um registro de problema consiste de trs partes: cabealho, atualizaes e

dados da resoluo. O cabealho responsvel pelas informaes de abertura do problema
e inclui informaes como:
11 Hora e data do incio do problema;
11 Operador que est abrindo o registro;
11 Severidade do problema;
11 Uma linha descrevendo o problema (para uso em relatrios);
11 Mquina envolvida;
11 Rede envolvida;
11 Endereo da mquina envolvida;
11 Endereo da mquina destino;
11 Prxima ao;
11 Hora e data para alarme;
11 Para quem esse registro deveria ser enviado;
11 Responsvel pelo registro;
As informaes de atualizao representam as aes e diagnsticos realizados ao longo do
ciclo de vida do problema.
Os dados de resoluo representam as informaes que resumem o problema para futuras
anlises estatsticas e, tambm, para uso em problemas similares contendo informaes tais
como: hora e data da resoluo, descrio da soluo do problema, componentes afetados,
quem verificou o problema depois que foi resolvido e quem foi consultado para auxlio na
resoluo do problema.
O estabelecimento de uma baseline (base de referncia) com dados sobre a rede e sua operao tpica auxilia a reconhecer e identificar comportamento anmalos alm de fornecer a
base para modificar as configuraes com confiabilidade, pois em caso de erro haver uma
configurao conhecida e que funcionou em algum momento anterior mudana a para a
qual se pode retornar.
Esse conjunto de informaes, derivados do processo de resoluo de problemas (troubleshooting) na rede, no apenas proporciona um registro sistemtico das mudanas na
rede, tal como preconizado pelas boas prticas de gerncia de configurao, mas pode
servir como ajuda no diagnstico de problemas futuros. Isso especialmente importante
dada a alta rotatividade na equipe de gerncia de rede que problema importante. Organizar essas informaes de modo que possam ser consultadas, manualmente ou atravs de
um sistema automatizado (sistema especialista), acelera o processo de diagnstico, pois os
16
problemas na rede tendem a repetir-se. Aumentar o nvel de automao no gerenciamento

de rede oferece diversas vantagens, conforme salientado por Comer (2007):
11 Reduo no tempo requerido para realizar a tarefa de diagnosticar e consertar os problemas na rede;
11 Reduo na probabilidade de erro de julgamento sobre as causas e formas de correo
dos problemas;
11 Garantir o uso de estratgias e poltica de uso consistentes na rede como um todo, evitando solues especficas definidas localmente que possam no atender ao acordo de
qualidade de servio da organizao.
Gerncia de configurao
A configurao dos dispositivos da rede controla o comportamento da rede. A gerncia de
configurao o processo de descobrir e configurar os dispositivos crticos que asseguram
o funcionamento do backbone e de todos os demais equipamentos ligados. Nesse sentido,
a organizao dessa funo de gerenciamento deve permitir rpido acesso s informaes
de configurao, que devem ser mantidas continuamente atualizadas. Isso implica em um
conjunto de fases ou etapas para o estabelecimento e continuidade do gerenciamento de
configurao:
Reunio de informaes de configurao (automtica ou manual)

O estabelecimento de uma baseline (base de referncia) com dados sobre a rede e sua operao tpica auxilia a reconhecer e identificar comportamentos anmalos, alm de fornecer
a base para modificar as configuraes com confiabilidade, pois em caso de erro haver uma
configurao conhecida e que funcionou em algum momento anterior mudana a para a
qual se pode retornar.
Armazenamento das informaes de configurao e atualizao dinmica

O registro automtico ou no das alteraes na rede permite conhecer e poder emitir
relatrios atualizados sobre todos os componentes e servios da rede. Quando ocorrem
alteraes na topologia ou nos dispositivos da rede mudanas na configurao precisam
ser desencadeadas sob pena de tornar parte da rede inoperante. Em tais casos conhecer
as relaes de dependncia (que dispositivos dependem ou esto interligados, fsica ou
logicamente) uns dos outros essencial. Como exemplo simples, pode-se citar o caso de um
servio de DNS desativado por problema de hardware ou software e que, mesmo substitudo por outro servidor na rede, pode ocasionar impossibilidade de operao de uma parte
da rede at que as reconfiguraes dos equipamentos que utilizavam aquele servidor como
default sejam reconfiguradas.
Diversas ferramentas podem ser utilizadas para definir ou alterar a configurao dos dispositivos da rede. A forma mais bsica e usual consiste em acessar diretamente o dispositivo
mediante o uso de Telnet/SSH no roteador ou na mquina/servidor para fazer login e depois
utilizar operaes em modo de linha de comando atravs do Command Line Interface (CLI)
daquele equipamento. Esse procedimento bastante manual e trabalhoso.
Em alguns casos, um sistema centralizado de registro e atualizao de configuraes pode ser
mantido. As alteraes so realizadas nas verses ali armazenadas e depois transferidas para
Fornecimento de relatrios peridicos de configurao e de inventrio

Mecanismos de automao do gerenciamento da configurao podem propiciar grande
reduo no esforo e tempo consumido para manter atualizado o registro da rede e seus
componentes, que so muitos e diversificados, tal como comentado por Comer (2007), que
cita uma relao de elementos de rede a controlar: switches (bsicas e com VLAN), pontos
de acesso para redes sem fio, sistemas de modem (ADSL, TV a cabo), interface para redes
de longa distncia, redes metropolitanas (conexes ticas e via rdio), roteadores, firewall,
servidor DNS, servidor DHCP, servidor web, sistemas de balanceamento de carga HTTP.
Assim, a funo de gerenciamento de configurao tem como caractersticas relevantes os
seguintes aspectos:
os dispositivos da rede mediante o uso de algum protocolo de transferncia de arquivos.
17
11 Considera a rede como um sistema dinmico em permanente transformao;
11 Prov e suporta na manuteno da estrutura fsica e lgica da rede;

11 Acompanha o ciclo de vida do componente e sua configurao;
11 Identifica componentes em um nvel apropriado e suas relaes (topologia);
11 Monitora cada componente, documentando as trocas que devem manter os requisitos bsicos estabelecidos;
11 Mantm registros dos status de cada componente (topologia e dispositivos);
11 Apoia a execuo de alteraes na configurao do sistema, visando isolar falhas,
aliviar situaes crticas ou atender a necessidades dos usurios.
Ferramentas para a gerncia de contabilizao

A gerncia de contabilizao o processo usado para medir parmetros de utilizao da
rede para que a atividade dos usurios individuais ou grupos (departamentos, setores,
unidades) possa ser regulada de forma adequada para efeitos de contabilidade ou compensao. semelhante gesto de desempenho, e o primeiro passo para a gesto de contabilizao apropriado medir a utilizao de todos os recursos de rede importantes.
A gerncia de contabilizao prov informaes para o replanejamento e redimensionamento da rede (gerenciamento de desempenho). Mediante o contnuo acompanhamento
e registro dos tipos de uso da rede, possvel identificar, por exemplo, usos no alinhados
com a misso crtica da instituio (uso suprfluo), mas que estejam consumindo recursos
crticos da rede ou dos demais recursos de TI. Diversas ferramentas tm sido usadas para a
gerncia de contabilizao e algumas so relacionadas a seguir:
11 Cisco NetFlow (Cisco 2007);
11 NBAR: Network Based Application Recognition (CISCO 2008).

Entre os benefcios derivados da gerncia de contabilizao, podemos citar:
11 Controle dos recursos;
11 Permitir que tarifas sejam aplicadas aos recursos de rede (discos compartilhados, banda,
arquivamento remoto, servios de telecomunicaes, e-mails etc.);
11 Viabilizar a identificao de custos para a rede e seus recursos;
11 Manter limites de consumo;
11 Efetuar a melhor distribuio de recursos e alimentar trabalhos de planejamento.
18
Network Planning
Accounting/Billing
Flow Proling
RMON Probe*
NetFlow/
Data Export
Network Monitoring
*NetScout
Switch Probe
Flow Collectors
End-User Apps
Gerncia de desempenho
A gerncia de desempenho envolve manter desempenho (performance) da rede em nveis
aceitveis atravs de medies e gerncia de diversas variveis ligadas ao desempenho.
Exemplos variveis indicadores de performance incluem: throughput, tempos de resposta,
utilizao do enlace, atrasos (delay) etc.
A funo da gerncia de desempenho visa:
11 Controlar o comportamento dos recursos de rede;
11 Avaliar as atividades de comunicao oferecidas na rede;
11 Monitorar a operao diria da rede;
11 Localizar pontos crticos no sistema;
11 Registrar dados de operao;
11 Auxiliar funes de planejamento e anlise.
A gerncia de desempenho pode ter um carter reativo ou proativo:
11 Reativo: quando o desempenho se torna inaceitvel (o valor medido est a seguir do
limite: threshold), o dispositivo gerenciado reage enviando um alerta para o SGR.
11 Proativo: na gerncia de desempenho proativa, uma simulao usada para projetar
o modo como o crescimento da rede afetar as mtricas de desempenho. Esses simuladores alertam os administradores no sentido de impedir os problemas, antes que
afetem os usurios da rede. Na gerncia de desempenho proativa, uma simulao
usada para projetar o modo como o crescimento da rede afetar as mtricas de
desempenho. Esses simuladores alertam os administradores no sentido de impedir
os problemas, antes que afetem os usurios da rede.
Figura 1.9
Um cenrio de
gerenciamento de
rede com diversos
componentes.
19
Figura 1.10
Exemplo de
aplicativo que
exibe dados da
rede via grficos
dinamicamente
atualizados.
Gerncia de segurana
A gerncia de segurana tem como meta controlar o acesso a recursos da rede, prevenir
sabotagem (intencional ou no) e acesso no autorizado a informaes sensveis. Ela

auxilia gerentes na criao de um ambiente de rede seguro.
Nesse sentido, envolve o uso de ferramentas como Intrusion Detection System (IDS),
firewall, antivrus, entre outros. Dentre as funes dessa categoria funcional,
podemos ressaltar:
11 Cuidar dos mecanismos e procedimentos de proteo;
11 Criar, apagar e controlar os servios e mecanismos de segurana;
11 Tratar da distribuio da informao relacionada com segurana e seus eventos;
11 Manter registros de eventos relativos segurana;
11 Suportar e garantir a poltica de segurana adotada.
Modelo ITIL: Information Technology Infrastructure Library

Embora a maioria das instituies tenha iniciado a organizao do gerenciamento de rede
com base no modelo FCAPS (ISO/OSI), mesmo no uso da arquitetura de gerenciamento para
a internet, um crescente nmero de instituies est comeando a utilizar o modelo ITIL.
Esse modelo funcional mais abrangente comeou a receber atenes e tem sido adotado
como base para a organizao, no apenas do gerenciamento de rede, mas de toda a infra-
20
estrutura de TI das organizaes.

A ITIL busca promover a gesto com foco no cliente e na qualidade dos servios de tecnologia
da informao (TI). A ITIL enderea estruturas de processos para a gesto de uma organizao
de TI apresentando um conjunto abrangente de processos e procedimentos gerenciais.
Embora o modelo funcional ITIL tambm utilize as reas funcionais definidos pela ISO contempla um entrelaamento entre elas juntamente com outros servios, tal como ilustrado
na figura seguinte.
ITIL
Information Technology
Infrastructure Library
uma biblioteca de boas
prticas (do ingls best
practices) desenvolvida
no final dos anos 80
pela Central Computer
and Telecommunications Agency (CCTA) e
atualmente sob
custdia da Office for
Government Commerce
(OGC), da Inglaterra.
What is
the vision?
Where are
we now?
How do we
check our
milestones have
been reached?
How do we
get where we
want to be?
Where do we
want to be?
Hardware
How do we keep the

momentum going?
Customers
Environments
Business
Relationship
Management
Services
Service
desk
Liaison,
Education and
Comunnication
Conguration
Management
Incident
Management
Supplier Relationship
Management
Review, Planning,
and Development
Deployment
Change
Management
Problem
Management
Release
Management
Availability
Management
Capacity
Management
Networks
Technical
Support
Operations
Maintain
Plan
Financial
Management
for IT Services
Service Level
Management
IT Service
Continuity
Management
Users
Design
and
Planning
Processes
Control
Evaluate
Implement
Databases
Requirements
Software
Optimise
Operate
Deploy
Build
Design
Os principais processos e funes do ITIL para suportar o gerenciamento de servios de TI so:

11 Central de Servios (Service Desk): a Central de Servios um servio bsico do Gerenciamento de Servios de Tecnologia de Informao, tal como definido pela Information Technology Infrastructure Library (ITIL). Ele se destina a fornecer um ponto nico de contato
para atender as necessidades de comunicao dos usurios e funcionrios, mas tambm
tem como meta satisfazer o cliente e os objetivos de TI do provedor. Usurio refere-se ao
usurio real do servio, enquanto o cliente refere-se entidade que est pagando pelo
servio. Muitas organizaes tm implementado um ponto nico de contato para o atendimento do usurio, usando alguns tipos de central de servios que envolvem diferenciados
nveis de habilidade e possibilidade de resoluo para chamadas de servio, tais como:
22 Call center.
22 Contact center.
33 Help desk: um termo da lngua inglesa que designa o servio de apoio a usurios
para suporte e resoluo de problemas tcnicos, informtica, telefonia e tecnologias de informao.
Figura 1.11
Modelo funcional
ITIL.
21
11 Gesto de Incidentes: reduzir o tempo de indisponibilidade (downtime) dos servios,

oferecendo s organizaes a capacidade de primeiro detectar os incidentes e depois
selecionar o suporte correto para resolv-los o mais rpido possvel retornando o servio
ao estado normal, definido como uma operao de servios dentro dos limites do contrato de nvel de servio (SLA). Implica em:
22 Deteco, atendimento e registro;
22 Gerenciamento das solicitaes de servio;
22 Classificao e suporte inicial;
22 Investigao e diagnstico;
22 Soluo e recuperao.
33 Fechamento dos problemas.
11 Gesto de Problemas: minimizar o impacto no negcio dos incidentes e problemas
causados pelos erros na infraestrutura de TI e prevenir incidentes recorrentes desses
mesmos erros. Envolvem:
22 Registro e classificao de problemas;
22 Investigao e diagnstico de problemas;
22 Controle de erro.
33 Fechamento dos problemas.
11 Gesto de Mudana: minimizar o impacto da mudana requerida para resoluo do incidente ou problema, mantendo a qualidade dos servios, bem como melhorar a operacionalizao da infraestrutura;
11 Gesto de Liberao: prevenir a indisponibilidade do servio, garantindo que as instalaes
de verses de hardware e software estejam seguras, autorizadas e devidamente testadas;
11 Gesto de Configurao: identificar e controlar os ativos de TI e itens de configurao
existentes na organizao, estabelecendo o relacionamento destes aos servios prestados. Envolve:
22 Estabelecer itens de configurao;
22 Acessar itens de configurao;
22 Alterar/revisar itens de configurao.
11 Gerenciamento do Nvel de Servio: garantir o acordo de nvel de servio (SLAs) previamente estabelecido entre o fornecedor e o cliente;
11 Gerenciamento financeiro para o servio de TI: demonstrar ao cliente o custo real dos
servios prestados e gerenci-los de forma profissional;
11 Gerenciamento de disponibilidade: garantir a disponibilidade e confiabilidade dos
22
recursos de TI, a fim de assegurar a satisfao do cliente e a reputao do negcio;

11 Gerenciamento de capacidade: assegurar que a capacidade da infraestrutura de TI est
adequada s demandas do negcio conforme a necessidade e no tempo esperado, observando sempre o gerenciamento do custo envolvido;
11 Gerenciamento da continuidade do servio de TI: atender todo o processo de gerenciamento da continuidade do negcio, assegurando que os recursos tcnicos e sistemas
de TI sejam recuperados quando requeridos, no tempo desejado.
Fluxo de mensagens em SNMP

11 Mensagens trocadas no protocolo SNMP poderiam usar TCP ou UDP como protocolo
de transporte, mas o UDP foi o escolhido, por questes de performance. UDP sem
conexo e mais leve que o TCP.
11 O gerente geralmente implementa timeout e retransmisso se no obtiver resposta.
Os objetos gerenciados so nomeados com base em uma rvore de nomeao padronizada.
Essa rvore de nomeao determina uma sequncia de nmeros que identificam cada
objeto gerenciado. A figura seguinte mostra como essa rvore de nomeao estruturada.
Um objeto gerenciado integrante da MIB 2 ter uma identificao que que vai iniciar pela
seguinte sequncia de identificadores: 1.3.6.1.2.1
ccitt (0)
iso (1)
iso-ccitt (2)
...
registrationauthority (1)
memberbody (2)
identiedorganization (3)
...
dod (6)
...
internet (1)
directory (1)
mgmt (2)
mib-2 (1)
...
...
...
DECnet (1)
...
...
Figura 1.12
MID OID.
XNS (2)
...
...
...
...
...
...
snmpV2 (6)
enterprise (1)
...
...
security (5)
private (4)
experimental (3)
cisco (9)
...
...
Novell (3)
...
...
VINES (4)
...
...
temporary
variables (3)
Apple Talk (3)

atlnput (1)
atLocal (2)
atBcastin (3)
atForward (4)
...
...
...
Chassis (5)
...
...
A continuidade dos identificadores dos objetos gerenciados indicar se eles pertencem a

algum dos grupos de objetos nomeados na figura 1.13.
standard (0)
...
23
MIB-II
The MIB sub-tree
mib(1)
system(1) interfaces(2) at(3) ip(4) icmp(5) tcp(6) udp(7) egp(8) transmission(10) snmp(11)
Figura 1.13
MIB II.
Note: There is an object cmot(9) under the mib but it has become almost superuous and
for all intents and purposes is not one of the SNMP manageable groups within mib.
A especificao de um objeto gerenciado incluir, alm de sua identificao, tambm

suas caractersticas, ou seja, se ele um nmero inteiro ou um conjunto de caracteres, se
permite apenas leitura ou pode ser atualizado pelo gerente SNMP etc. A figura 1.14 ilustra a
definio de um objeto gerenciado.
system(1)
sysDescr(1)
sion(10) snmp(11)
sysObjectID(2)
sysUpTime OBJECT-TYPE
SYNTAX TimeTicks
ACCESS read-only
STATUS mandatory
DESCRIPTION
ObjectName
sysUpTime(3)
sysContact(4)
ObjectSyntax
The time (in hundredths of a second)

since the network management portion of
the system was last re-initialized.
Figura 1.14
Definio de
objetos no SNMP.
::= { system 3 }
Modelo operacional SNMP

O protocolo SNMP trabalha utilizando o seguinte conjunto de operaes:
11 GetRequest: requisio para capturar o valor de uma varivel;

11 SetRequest: requisio de mudana de um valor de uma varivel feita pelo gerente;
11 GetNextRequest: requisio para capturar o valor da prxima varivel;
11 Response: mensagem de resposta do agente para as solicitaes de Get e Set;
11 Trap: notificao do agente ao gerente, comunicando o acontecimento de um evento
predeterminado.
24
Essas mensagens so encapsuladas pelo protocolo UDP e transportadas em datagramas

IP. Atravs do seu uso, a estao de gerenciamento da rede pede informaes para o
agente SNMP, altera valores de objetos gerenciados no agente e obtm respostas a esses
comandos. Adicionalmente, o agente SNMP pode gerar mensagens no solicitadas ou notificaes enviadas para o gerente SNMP. A figura 1.15 ilustra essas interaes.
GetRequest
GetResponse
GetNextRequest
GetResponse
GERENTE
SetRequest
AGENTE
GetResponse
Trap
Figura 1.15
Definio de
objetos no SNMP.
O protocolo SNMP foi inicialmente definido pelo RFC 1067 em 1988, mas sofreu uma
evoluo e a verso 2 foi publicada em 1993, no RFC 1442, e logo recebeu ampla aceitao.
Nessa segunda verso, mecanismos de segurana foram adicionados, mas em carter
opcional, e essa a verso mais disseminada. Em 1995, foi publicada a verso, definida no
RFC 1861, que incorpora mecanismos de segurana com autenticao forte e criptografia.
Verso
Nvel
SNMPv1
noAuthNoPriv
Usa o texto community para autenticar
SNMPv2c
noAuthNoPriv
Usa o texto community para autenticar
SNMPv3
noAuthNoPriv
Username
Usa o username community para autenticar
authNoPriv
MD5ou SHA
Usa os algoritmos de autenticao - HMAC-MD5

e HMAC-SHA
authPriv
MD5ou SHA
Criptografia
DES
O que acontece?
Usa criptografia 56-bit DES
RMON Remote
Tendo em vista a necessidade de monitorar e obter informaes sobre todos os dispositivos da
rede, mesmo aqueles que no tenham um agente SNMP ou o que o agente esteja desativado, foi
proposta em 1991 uma ampliao na funo do agente SNMP com vistas sua atuao de modo
anlogo ao de um analisador de rede. A expanso da funo foi proposta mediante o uso de
uma ampliao da MIB (RFC 1271), com novos conjuntos de objetos gerenciados para armazenar
as informaes derivadas da operao do agente em modo de operao com captura de todo o
trfego por ele percebido na rede.
Suas principais caractersticas so:
11 MIB especfica para monitorao de redes;
11 Prov uma maneira efetiva e eficiente de monitorar comportamento de segmentos de rede;
11 Objetivos (segundo a RFC 1271) envolvem:
22 Operao off-line;
22 Monitoramento proativo;
22 Notificao de eventos significativos somente estao de gerncia;
22 O monitor deve suportar gerentes mltiplos;
Tabela 1.2
Protocolo SNMP
verses.
Autenticao
25

11 Statistics: estatsticas de Rede em tempo real;
11 History: histrico de estatsticas pr-selecionadas;
11 Alarm: Traps que sero enviadas caso as estatsticas excedam um determinado valor;
11 Hosts: estatsticas de rede de uma mquina especfica;
11 Hosts top N: Registro de N conexes ativas num determinado perodo;
11 Matrix: Matrix com o trfego entre mquinas;
11 Filter: Filtro para capturar somente o dado interessado;
11 Capture: coleo de dados filtrados pelo grupo filter;
11 Event: envia alertas, Traps SNMP;
11 Token Ring: especfico para enlaces Token Ring;

11 Protocol Directory: lista de protocolos que podem ser monitorados;
11 Protocol Distribution: estatstica de trfego por protocolo;
11 Address Map: mapeamento de IP para MAC ADDRESS;
11 Network-Layer Host: estatstica de trfego de camada 3 separada por mquina;
11 Network-Layer Matrix: trfego de camada 3 com o registro de origem e destino;
11 Application-Layer Host: estatstica de trfego por protocolo e mquina;
11 Application-Layer Matrix: estatstica de trfego por protocolo, mquina, origem e destino;
11 User History: amostras peridicas de uma varivel especfica;
11 Probe Configuration: utilizado para configuraes remotas;
Figura 1.16
Classes de objetos
da RMON MIB.
11 RMON Conformance: requisitos para funcionar com padro RMON v2.

ProbeCong
useHistory
alMatrix
alHost
19
18
17
16
Iso
Organizations
nMatrix
15
DOD
Private
Internet
Management
26
RMON
MIB I and II
14
nlHost
13
AddressMap
12
ProtocolDist
11
ProtocolDir
10
Token Ring
Events
8 Packet Capture
MIB I
Statistics
History
Alarms
Hosts
Filters
Trac Matrix
Host TopN
Console
mensagens
RS-232
Console
IOS
(optional)
syslog
514/udp
cong
timestamp
Severity level
Description
Emergencies
Alerts
Critical
Errors
Warnings
Notications
Informational
Debugging
system log
message
IOS Syslog
Default Level
Um agente RMON pode utilizar o servio syslog para o envio de alertas e notificaes. Syslog
um padro criado pela IETF para a transmisso de mensagens de log em redes IP. O
protocolo syslog tipicamente usado no gerenciamento de computadores e na auditoria de
segurana de sistemas.
O protocolo syslog bastante simples: o remetente envia uma mensagem de texto de
acordo com a RFC 5424 para o destinatrio (tambm chamado syslogd, servio syslog ou
servidor syslog). Essas mensagens podem ser enviadas tanto por UDP quanto por TCP e
seu contedo pode ser puro ou utilizando SSL.
Agentes e gerentes
Entidades com papis definidos:
11 Gerentes.
11 Agentes.
A arquitetura de gerenciamento de redes usada tanto no modelo OSI quanto no modelo
SNMP baseada na existncia das entidades gerente e agente:
11 Gerente: entidade responsvel em coletar as informaes e disparar aes. Atua sobre
os agentes. Agrega inteligncia ao sistema, podendo realizar tarefas mais complexas,
como gerar relatrios para o usurio;
11 Agente: entidade localizada perto do item (ou internamente a ele), gerenciando (como
um equipamento) esse mesmo item e respondendo s solicitaes do gerente via rede.
Permite o acesso s informaes de gerenciamento localizadas localmente, mantendo-as
como um reflexo da realidade do equipamento.
Os protocolos de gerenciamento permitem ao gerente disparar comandos para o agente
atravs da rede, como qualquer outra aplicao de rede. Por isso, os protocolos de gerenciamento normalmente so protocolos de camada de aplicao, especficos para a atividade de
gerenciamento e implementados em aplicaes de gerenciamento.
Figura 1.17
Syslog log de
eventos.
Severity
level
Facility
System Server
logle
syslog
27
Um agente pode funcionar como um proxy representando equipamentos que no so

capazes de prover informaes sobre si mesmo e sobre seu funcionamento, tal como
preconizado na arquitetura de gerenciamento daquela rede. Um agente proxy interage com
dispositivos da rede usando qualquer forma possvel e mantm atualizados na MIB as informaes relativas os dispositivos representados.
Network Management System

(NMS)
Entidade de
Gerenciamento
Protocolos de
Gerenciamento
de Redes
Rede
Agente
Agente
Agente
Proxy
Management Information Base
Dispositivos gerenciados
Informao de gerenciamento
As informaes usadas para fins de gerenciamento da rede so estruturadas de acordo com
padres que determinam sua:
11 Organizao;
11 Nomenclatura;
11 Regras e procedimentos.
Apesar dessa padronizao, ainda restam muitas decises que os responsveis pelo geren Gerncia de Redes de Computadores
ciamento da rede precisam tomar, como:
28
11 Qual o intervalo de tempo para coletar as informaes?

11 Que informao se deseja coletar?
Essas decises precisam ser avaliadas, tendo em vista evitar uma sobrecarga de trfego na
rede de processamento nos equipamentos envolvidos. A deciso sobre quanta informao
interessante e/ou necessria para o gerenciamento depender do equipamento e contexto
de rede onde ele estiver. Mesmo assim, muitas das informaes de gerenciamento relacionadas podem ser assumidas. Por exemplo: uma informao sempre til de um equipamento
como um roteador a sua tabela de roteamento ou a quantidade de pacotes enviados,
recebidos e descartados, por erro ou impossibilidade de reencaminhamento.
Figura 1.18
NMS e agentes.
necessria uma estrutura de informao de gerenciamento para gerenciar a massa de

informaes associadas s complexas redes multifabricantes que existem;
11 Uma nomenclatura deve ser definida para descrever essas informaes;
11 Devem ser definidos procedimentos de acesso e alterao das informaes;
11 O tratamento e a modelagem de informao de gerenciamento normalmente abordam
uma estratgia baseada em objetos. Por isso, importante recordar esses conceitos;
11 A abstrao de objetos permite que sejam capazes de modelar aspectos reais da situao
ou comportamento dos dispositivos da rede. Assim, os objetos representaro uma realidade ou aspecto concreto tal como a quantidade de portas em um roteador, a quantidade de pacotes recebidos em uma porta, os identificadores (nmero IP) de origem e
destino de uma conexo TCP etc.
Conceitos de orientao a objetos

11 Classes.
11 Encapsulamento.
11 Operaes (mtodos).
11 Eventos.
11 Relacionamentos entre os objetos, associao, herana etc.
Uma instncia individual de um objeto gerenciado uma varivel da MIB.
Templates (modelos) so usados para a definio dos objetos. As implementaes devem
seguir as informaes descritas nos templates para uniformizar a compreenso e a manipulao da informao. Exemplo: se um fabricante armazena e trata o endereo IP de um equipamento como do tipo string e outro como do tipo inteiro long, as aplicaes que vo coletar
e tratar essas informaes poderiam estar trabalhando com tipos de dados incompatveis.
Structure of Management Information (SMI)

11 Como organizar os dados de gerenciamento de rede?
11 De que forma podemos identificar um objeto?

11 Como definir e descrever um objeto?
11 De que forma podemos codificar (serializar) um objeto?
11 Como as variveis decorrentes dessas aes devem ser representadas?
um mdulo de informao (um pacote de informaes relevantes usadas pelo gerenciamento com SNMP). Em resumo, a SMI usada para a criao de mdulos de MIB.
Por exemplo, a SMI para arquitetura TCP/IP (SNMP) define:
11 O modo como so definidos os mdulos de MIB;
11 O subconjunto da linguagem de descrio de dados, no padro ASN.1 (explicado adiante),
usado com SNMP;
11 O modo como todas as construes ASN.1 devero ser serializadas para envio pela rede;
11 O formato dos identificadores de objetos na rvore MIB para gerenciamento internet;
11 A descrio dos objetos gerenciados SNMP;
Em um nvel mais alto, a Structure of Management Information (SMI) usada na criao de
29
11 A codificao desses objetos para transmisso na rede, feita atravs das regras bsicas
de codificao (BER, Basic Encoding Rules).
11 A SMI particular para uma determinada arquitetura de gerenciamento de rede.
Abstract Sintax Notation (ASN.1)

Atributos principais para cada objeto:
11 Nome do objeto (identificador).

11 Sintaxe do objeto.
11 Codificao do objeto.
A descrio da MIB formaliza sua estrutura, cada objeto que ela contm e suas caractersticas. necessria uma definio textual da MIB, de forma a padroniz-la e permitir que ela
seja implementada por outros fabricantes e desenvolvedores.
As variveis nas MIBs so descritas por um subconjunto de facilidades de uma linguagem de
descrio de dados chamada Abstract Sintax Notation (ASN.1) que um padro ISO (8824).
A ISO definiu essa notao, derivada da recomendao ITU X.409), que permite definir tipos
de dados simples e complexos, bem como os valores que tais tipos podem assumir. Essa
notao, denominada Notao para Sintaxe Abstrata Um (ASN.1 Abstract Sintax Notation
One). A notao no indica o valor dos dados, apenas sua forma. Adicionalmente existem
algoritmos, denominados Regras Bsicas de Codificao (Basic Encoding Rules) que determinam o valor dos octetos representando tais valores tal como sero transmitidos com os
protocolos de transferncia de dados.
ASN.1 utiliza alguns tipos primitivos (elementos de dados) com os quais podem ser compostas estruturas mais complexas. Os tipos primitivos ou bsicos so:
11 BOOLEAN;
11 INTEGER;
11 BITSTRING;
11 OCTETSYTRING;
11 NULL.
Estruturas complexas so definidas agregando-se tais tipos primitivos de algumas formas previstas na ASN.1. As principais formas de estruturao de tipos compostos ou construdos so:
11 SEQUENCE: lista ordenada de tipos;
11 SEQUENCE OF: iterao ilimitada de um nico tipo;
11 SET: lista no ordenada de tipos estruturao;
30
11 SET OF: interao ilimitada de um nico tipo (a ordem no e importante);

11 CHOICE: um campo que consiste de um valor dentre os tipos listados.
ASN.1 define uma notao para especificao de valores e para definio de tipos. A definio de um tipo consiste em uma coleo de campos que, no mais baixo nvel, consiste em
um identificador, uma possvel etiqueta (rtulo ou tag), uma referncia e uma possvel
indicao de que aquele campo opcional (pode ser omitido).
No menor nvel, os campos da definio so combinados usando mecanismos de estruturao que comeam com o nome do tipo da estrutura e ento, em geral, uma lista de campos
separados por vrgulas e envolvidos em chaves {}. vlido usar aninhamento de estruturas.
Assim, um tipo ser definido, segundo a ASN.1, usando uma das sequncias de tipo vlidas,
do tipo Builtin ou Defined:
Type::= BuiltinType|DefinedType
BuiltinType::= BooleanType|
IntegerType|
BitStringType|
OctetStringType|
NullType|
SequenceType|
SequenceOfType|
SetTypeType|
SetOfType|
ChoiceType|
TaggedType|
AnyType|
CharacterSetType|
UsefulType|
O DefinedType especifica sequncias externas usadas para referir definies de tipos e valores.
Sintaxe ASN.1 de um objeto da MIB

Os objetos de uma MIB so especificados usando ASN.1, bem como o prprio protocolo
SNMP, que tambm especificado com ASN.1. A figura seguinte ilustra a definio do objeto
sysUpTime nessa forma de notao.
SYNTAX
TimeTicks
ACCESS
read-only
STATUS
mandatory
DESCRIPTION
The time (in hundredths of a second) since the network management
Figura 1.19
Definio de um
objeto gerenciado
em ASN.1.
portion of the system was last re-initialized.

::= { system 3 }
Essa definio tanto legvel pelas pessoas como por programas e isso permite que novos
objetos gerenciados sejam incorporados a uma MIB e as aplicaes de gerenciamento de rede
podem ler essa especificao e compilar a definio dos novos objetos, incorporando-os ao
acervo de objetos gerenciados que sero consultados periodicamente (processo de polling)
pelo gerente, usando o protocolo SNMP e cujos valores sero retornados pelo agente SNMP.
31
Regras de codificao BER (Basic Encoding Rules ISO 8825)

As Basic Encoding Rules proveem um algoritmo que especifica como um valor de qualquer estrutura (tipo) definida usando ASN.1 deve ser codificada para transmisso. O uso do
algoritmo no sentido contrrio permite que qualquer receptor que tinha conhecimento da
definio do tipo ASN.1 possa decodificar os bits que chegam em um valor daquele tipo.
A codificao de um tipo de dados ASN.1 (usando as Basic Encoding Rules) permite que um
receptor, sem conhecimento da definio de tipo, reconhea o inicio e o fim das construes
(SEQUENCE, SET, etc.) e os octetos representando os tipos bsicos de dados (BOOLEAN,
INTEGER). No uso mais simples da notao, e tambm possvel determinar, a partir da codificao, as construes efetivamente usadas e os tipos de dados bsicos.).
Cada valor de dados a ser codificado ter uma representao consistindo de:
11 T: tipo;
11 C: comprimento: quando indefinido, termina com dois octetos nulos;
11 V: valor pode ser um valor (nmero ou cadeia de caracteres) ou uma srie de outros
componentes TCV (tipos complexos ou construdo).
02
01
00
integer
1 byte
valor = 0
Tipo
Comprimento
Valor
04
06
70 75 62 6c 69 63
string
6 bytes
valor = public
Tipo
Comprimento
Valor
Figura 1.20
Codificao em
uma informao
de um objeto
gerenciado.
Para se entender melhor essa codificao, vamos analisar o primeiro octeto (oito bits) da
sequncia de bits codificados, que especifica o tipo de identificador (Type), como exibido na
figura 1.21.
8
Class
P/C
Number
1
Figura 1.21
Type na ASN.1
Os bits 7 e 8 identificam a classe, de acordo com a tabela 1.3.
32
Class
bit 8
bit 7
Universal
Application
Context-specific
Private
11 Se a classe for Universal, ou seja, se os bits 8 e 7 contiverem o valor 0, o tipo do valor

do dado ASN.1 nativo;
11 Caso a classe seja Application com o valor do bit 8 igual a 0 e o valor do bit 7 igual a 1,
isso significa que o valor para uma aplicao especfica, como por exemplo o servio de
diretrio definido pela srie de padro X.500 da ITU-T;
Tabela 1.3
Classes em ASN.1
11 Se a classe for do tipo Context-specific, ou seja, o bit 8 com valor 1 e o bit 7 com valor
0, significa que o tipo de dado uma estrutura especfica e TAGs so utilizadas para
fazer a distino entre esses tipos;
11 Se a classe for do tipo Private, significa que o dado especfico de um fabricante.
J o bit 6, tambm conhecido como primitivo/construdo: P/C se estiver com o valor 0 significa que um valor primitivo, como por exemplo, um valor INTEIRO. Caso o bit primitivo/
construdo P/C esteja com o valor 1 significa que o dado do tipo construdo e os bit de
1 5 sero o campo TAG utilizado para identificar esse tipo de dado.
A tabela da figura 1.23 descreve o campo TAG e seus valores correspondentes, ou seja, se os
bits de 1 a 5 tiverem o valor 0, significa que o fim do dado. Caso o bit 5 contenha o valor
1 e os bits de 1 a 4 tiverem o valor 0001, significa que o dado do tipo BOOLEAN, assim
Nmero
Nmero
Nome
P/C
(decimal)
hexadecimal)
Nmero
binrio
EOC (End-of-Content)
00000
BOOLEAN
00001
INTEGER
00010
BIT STRING
P/C
00011
OCTET STRING
P/C
00100
NULL
00101
OBJECT IDENTIFIER
00110
Object Descriptor
00111
EXTERNAL
01000
REAL (float)
01001
ENUMERATED
10
01010
EMBEDDED
11
01011
UTF8String
P/C
12
01100
RELATIVE-OID
13
01101
SEQUENCE and SEQUENCE OF
16
10
10000
SET and SET OF
17
11
10001
NumericString
P/C
18
12
10010
PrintableString
P/C
19
13
10011
T61String
P/C
20
14
10100
VideotexString
P/C
21
15
10101
IA5String
P/C
22
16
10110
UTCTime
P/C
23
17
10111
GeneralizedTime
P/C
24
18
11000
como temos a seguir.
33
Nmero
Nmero
Nome
P/C
(decimal)
hexadecimal)
Nmero
binrio
GraphicString
P/C
25
19
11001
VisibleString
P/C
26
1A
11010
GeneralString
P/C
27
1B
11011
UniversalString
P/C
28
1C
11100
CHARACTER STRING
P/C
29
1D
11101
BMPString P/C 30 1E
P/C
30
1E
11110
Tabela 1.4
Tags usados
em ASN1.
Representao BER (TLV)

Codicao de comprimento denido
(tipos primitivos ou construdos)
Identicador
(tag)
classe P/C T TTTT

ou
OLLL LLLL
1TTT TTTT
No o ltimo byte
Contedo
(valor)
Formato curto de comprimento

(0 <= comprimento <= 127)
ou
Formato longo (127 < comprimento < ?)
tag (1-30)
classe P/C 1 1111
Tamanho
...
0TTT TTTT
1nnn nnnn
ltimo byte
Nmero de bytes de comprimento

(1 <= nnnnnnn <= 127)
0 = Primitivo
LLLL LLLL
...
LLLL LLLL
1 = Construdo
00 = Universal
01 = Aplicao
10 = Especco de um contexto
11 = Privado
Para no limitar os nmeros de ramos na rvore, foi criada uma maneira de representar
nmeros realmente grandes. Se o nmero for menor que 127, ele codificado num nico
byte. Se for maior, codificado em vrios bytes, de acordo com a figura acima.
Um tipo de dado muito comum em gerenciamento o OBJECT IDENTIFIER. Sua codificao
34
no bvia: os primeiros 2 dgitos, x.y, devem ser codificados num nico nmero atravs da
frmula 40x+y em decimal, e depois para hexadecimal.
No caso de 1.3 (x=1, y=3) => 43 em decimal resulta em 2B em hexadecimal.
Figura 1.22
BER Basic Encoding
Rules.
Alguns identificadores ASN.1 (tags)

INTEGER 02
BIT STRING 03
OCTET STRING 04
NULL 05
OBJECT IDENTIFIER 06
SEQUENCE 30
IpAddress 40
Counter 41
Gauge 42
TimeTicks 43
Opaque 44
Counter64 46
Uinteger32 47
Get-Request-PDU A0
GetNextRequest-PDU A1
GetResponse-PDU (response-PDU) A2
SetRequest-PDU A3
Trap-PDU A4
GetBulkRequest-PDU A5
InformRequest-PDU A6
SNMPv2-Trap-PDU A7
11 Exemplos de tipos primitivos: INTEGER, ENUMERATED, OCTET STRING, OBJECT INDENTIFIER, NULL, BOOLEAN, BIT STRING, REAL, Counter, Gauge, TimeTicks, IpAddress,
11 IpAddress (OCTET STRING de tamanho 4);
11 Counter (unsigned 32-bit integer);
11 Gauge (unsigned 32-bit integer);
11 Timeticks (unsigned 32-bit integer);
11 Opaque (tipos no usados em SNMPv1);
11 Outros: DateAndTime, DisplayString, MacAddress, PhysAddress, TimeInterval,
TimeStamp, TruthValue, VariablePointer todos so textual conventions usados
como tipos de dados;
11 Exemplos de tipos construdos (a partir de tipos primitivos): SEQUENCE, SEQUENCE OF,
SET, SET OF, CHOICE etc.
Network Address, Integer32, Counter32, Gauge32, Counter64, UInteger32 etc.
35
ASN.1 e BER (Exemplos)

Struct employee {
employee :: SEQUENCE {
char
name[32];
Name
int
salary;
Salary
INTEGER;
int
entryDate;
entryDate
INTEGER;
int
sex;
Sex
BOOLEAN;
OCTET String, -- 32 characters
};
{Joe Bloggs, 8000, 1290, 0}
31*256+64=8000
5*256+10=1290
[ 5 22 4 10 J o e B l o g g s 1 2 31 64 1 2 5 10 1 0]
Inicio da
sentena
Tamanho inteiro
Tamanho da String
String
Tamanho da sentena em bytes
Falso Booleano
Veja no exemplo como as regras BER determinam uma nica serializao para o conjunto de
dados a ser transmitido.
Mesmo a troca de dados entre aplicaes em plataformas diferentes no corre o risco de ter
incoerncias na compreenso das informaes.
36
Figura 1.23
Exemplo de
codificao
usando BER.
2
Descrever o processo de resoluo de problemas, aprender as caractersticas das
ferramentas de inspeo e monitorao de redes.
e monitorao, Programa Wireshark, Programa TCPDUMP.
conceitos
Problemas na rede, Processo de resoluo de problemas, Ferramentas para inspeo
Inmeros problemas podem ocorrer em uma rede. A capacidade de detectar e diagnosticar

depende das ferramentas disponveis e do conhecimento de quem as utiliza. Esse conhecimento vai alm de conhecer as funes da ferramenta. preciso que exista conhecimento
suficiente para interpretar as informaes que cada tipo de ferramenta capaz de fornecer. Conforme salientado por Sanders (2007), muitas coisas podem causar problemas na
rede, desde uma infeco por spyware simples at um complexo erro de configurao do
roteador, e impossvel resolver todos os problemas imediatamente. O melhor que se pode
fazer estar totalmente preparado com o conhecimento e as ferramentas para reagir a
esses e outros tipos de problemas.
Problemas na rede
Os problemas que ocorrem na rede so caracterizados por sintomas que precisam ser
percebidos e analisados para um diagnstico das causas. O desenho na figura 2.1 mostra
um cartum com um conjunto de possveis causas de um comportamento errtico em um
segmento de rede local:
Captulo 2 - Ferramentas de inspeo e monitorao de redes
objetivos
Ferramentas de inspeo e
monitorao de redes
37
Processo de resoluo de problemas

Os problemas, como se pode verificar nessa figura, podem ser ocasionados por inmeras
causas, tais como mau funcionamento de hardware, software ou mesmo usurio gerando
trfego excessivo. Realizar o diagnstico de um problema de mau funcionamento em rede
requer uma abordagem sistemtica. Uma proposta de abordagem para diagnstico de
problemas de rede foi sugerida em um guia de diagnstico da CISCO (2008) e emprega trs
grandes etapas:
11 Definir o problema, compondo um quadro descritivo em que todos os sintomas esto
relacionados;
11 Identificar os possveis problemas que possam ocasionar aqueles sintomas;
11 Buscar evidncias sobre a ocorrncia de cada um desses possveis problemas, iniciando
pelos mais usuais.
Esse processo de resolver problema detalhado no diagrama da figura 2.2.
38
Figura 2.1
Causas de mau
funcionamento de
uma rede local.
Denir o problema
Obter fatos
Considerar as possibilidades
baseadas nos fatos
Criar um plano de ao
Implementar um plano de ao
Observar resultados
Se o problema persiste
Reiterar procedimento
Problema resolvido
No primeiro passo, para cada sintoma percebido, as causas associadas so relacionadas.

Muitas vezes o registro do problema surge com informaes incompletas ou vagas. Por
exemplo, um usurio pode reclamar que o servidor est lento. Com essa informao, no se
pode saber se a lentido ocorre apenas para um determinado servidor, para uma determinada aplicao ou se tambm h lentido no acesso a outros servidores. Ao efetuar o
registro do problema, importante formular uma srie de perguntas com o objetivo de conseguir uma definio o mais completa possvel para o problema. Em algumas instituies,
so preparados roteiros de perguntas, encadeadas de forma a conduzir a uma caracterizao do problema em determinada rea de possveis causas.
Algumas situaes no so passveis de serem percebidas pelo usurio que relata o
problema, e demandaro inspeo de dados de configurao pela equipe de suporte
de rede e de sistemas.
No exemplo citado, se um sintoma for resposta muito lenta de um servidor, uma lista de
causas poderia incluir desde host mal configurado, sobrecarregado, servio configurado de
forma inadequada, problemas de roteamento ou filtragem de pacotes no meio do caminho
e at interface de rede com defeito no lado do cliente. Esses ltimos motivos poderiam
ocasionar perda intermitente de pacotes, levando necessidade de retransmisso por ocorrncia de timeout no protocolo de transporte ou mesmo na aplicao.
Assim, para avanar no processo de diagnstico, o passo seguinte, conforme ilustrado na
figura 2.2, consiste em obter fatos e isso implica em buscar informaes mais detalhadas
sobre os sintomas e equipamentos e sistemas envolvidos. Essas informaes podem ser
conseguidas mediante o uso de:
11 Uso de comandos de inspeo, como ping e traceroute, alm de outros para testar conectividade ao longo da rota;
Figura 2.2
Processo de
resoluo de
problemas.
Se o sintoma desaparece
39
11 Analise do trfego na rede tanto no segmento ao qual o servidor est ligado quando no
lado do cliente. Essa anlise demanda a captura de trfego, que pode ser feita no prprio
servidor, usando comandos como traceroute, ou com a ajuda de analisadores de rede
que capturam todo o trfego e possibilitam diferentes modos de agregao e filtragem,
permitindo exibir pacotes por endereo originador, destinatrio, protocolo etc., bem
como compor relatrios totalizando o trfego por diferentes critrios, ou ainda mostrar
sequncias de pacotes intercambiados por determinados pares de endereo com o uso
de protocolos especficos, entre outras tcnicas;
11 Anlise do registro de logs do servidor para complementar a inspeo de trfego total em
todos os acessos ao servidor.
Essa informao mais rica e detalhada permitir conhecer a situao da rede, a partir do
trfego capturado e analisado. Isso possibilitar estreitar o escopo da busca, eliminando
classes de problemas. No caso da resposta lenta do servidor no exemplo anterior, a presena de trfego intenso em algum trecho da rede no caminho entre o usurio e o servidor
poderia ser constatada e seria uma possvel causa. Se o problema relatado fosse total falta
de acesso ao servidor, a deteco de algum trfego na rede, proveniente do endereo do
servidor, permitiria eliminar causas intermedirias, tal como roteamento incorreto ou enlace
intermedirio inoperante.
Depois de obter as informaes que permitam conhecer a situao, o passo seguinte
consiste em criar um plano de ao para tratar os problemas potenciais que poderiam
ocasionar os sintomas percebidos. No tarefa fcil identificar as causas possveis. Isso
demanda conhecimento tcnico que permita analisar se os sintomas percebidos e os dados
obtidos da monitorao so os que um sistema operando de condies normais deveria
exibir. Mas tambm demanda conhecimento heurstico, derivado das experincias anteriores de diagnstico de correo de falhas na rede. Possveis fontes de apoio e referncias
nessa fase so:
11 Manuais: explicam o funcionamento esperado e indicam possveis causas para problemas comuns;
11 Tabelas de troubleshooting: associam sintomas a causas provveis;
11 Experincia anterior: aponta causas de sintomas similares em situaes anteriores;
11 Sistemas especialistas: correlacionam causas e sintomas tipicamente relacionados, e
at podem sugerir aes corretivas possveis.
O plano de ao, baseado no conjunto de possibilidades identificadas, busca eliminar uma
a uma as possveis causas para os sintomas, mediante observao e anlise da rede, com
o trfego normal e com trfego de teste de cada uma das hipteses a investigar. O plano
de ao deve limitar-se a investigar uma varivel de cada vez, pois com muitas alteraes
40
sendo realizadas concomitantemente, pode ocorrer um retorno da rede ao estado operacional sem que seja possvel perceber qual ou quais foram as medidas que solucionaram o
problema. Assim, o recomendvel implementar a alterao/correo planejada e ento
observar, testar e avaliar o resultado. A observao/teste envolve o uso de comandos de
inspeo de configurao, de status de equipamentos e monitorao da rede.
Se o problema desapareceu, ento a situao est resolvida e resta apenas fechar o registro
de ocorrncia registrando a causa efetivamente diagnosticada e a forma de resolver o
problema. Isso ampliar a base de conhecimento sobre problemas de rede e suas causas,
facilitando investigaes de futuros problemas tanto pela mesma equipe como por outras
equipes que vierem a substituir os que atuaram na investigao.
Se o problema no pode ser resolvido com a estratgia seguida, o plano de ao deve ser
refinado com base nos resultado e um novo plano de ao deve ser definido e implementado, reiteradamente, at que o problema seja solucionado.
Ferramentas para inspeo e monitorao

Diversas ferramentas para inspeo e monitorao da rede podem ser utilizadas:
11 Analisadores a nvel fsico, como cable scanners, que auxiliam a avaliar as condies
de transferncia de dados da rede e permitem verificar se existe alguma atenuao ou
mesmo rompimento do meio de transmisso (metlico ou tico);
11 Analisadores de protocolos capazes de capturar, registrar, analisar e reconhecer determinados padres de troca de mensagens dos protocolos mais comuns nas redes, tanto nas
camadas de enlace, de rede, de transporte como de aplicao.
Analisadores do meio fsico
Analisadores de rede e protocolos
Cable Scanner:
Hardware e software
11Optical Tome Domain Reflectometer (OTDR):

pode medir o comprimento da fibra, localizar
rompimentos, atenuao anormal etc.
Figura 2.3
Ferramentas de
anlise de rede.
Software
Existem diversas solues comerciais em todas as categorias de analisadores, mas um

produto tem atrado a ateno e interesse da comunidade de rede pelo fato de ser oferecido
como software livre, distribudo com uma licena General Public License (GNU) verso 2.
Trata-se do Wireshark, um software para monitorao de rede e anlise de protocolo.
Wireshark
O Wireshark um programa que captura e analisa o trfego de rede, permitindo diversas
formas de organizao ou apresentao do que foi capturado. As funcionalidades do
Wireshark so parecidas com o tcpdump (abordado posteriormente), mas com interface
grfica, mais informao e com ampla variedade de filtros que podem tanto limitar a captura
como ajustar o que apresentado, para facilitar a anlise.
11Time Domain Reflectometer (TDR):

Um TDR opera transmitindo um sinal no cabo.
Interrupes e outros problemas provocam uma
reflexo do sinal com caractersticas especficas.
O TDR mede quanto tempo leva para o sinal
refletido retornar, e com isso calcula a distncia
at uma avaria no cabo. TDR tambm pode ser
usado para medir o comprimento de um cabo;
41
O desenvolvimento desse software comeou em 1998, com o projeto que inicialmente

foi denominado Ethereal. Aps a migrao do principal autor, Gerald Combs, para outra
empresa, o desenvolvimento prosseguiu, com novo nome para o software. Atualmente
conta com a colaborao de uma imensa comunidade de desenvolvedores que tanto contribuem para o desenvolvimento em si (em modalidade de software livre), como agregam
ferramentas comerciais adicionais (Wireshark 2012).
O Wireshark executa na maioria das plataformas, incluindo Windows, OS X, Linux e UNIX, e
sua marca registrada pertence Wireshark Foundation.
Alguns produtos comerciais, desenvolvidos a partir do Wireshark ou que o incluem, esto
tambm disponveis no mercado. A CACE Technologies oferece um adaptador AirPcap, que
possibilita captura de trfego 802.11 a/b/g/n e sua inspeo com o Wireshark. Adicionalmente, essa empresa vende um produto denominado CACE Pilot, para avaliar tendncia do
trfego a longo prazo. A Cisco embutiu o Wireshark na linha de switch Nexus 7000.
Conhecendo o Wireshark
O funcionamento do Wireshark, analogamente a qualquer outro analisador de rede, envolve
trs passos: coletar, converter e analisar.
11 Coletar
Nesse passo, o equipamento onde o software executado opera com sua interface em
modo promscuo (modo em que captura todo o trfego percebido na rede, mesmo que o
endereo do destinatrio no seja o dessa mquina). Assim, todo o trfego sendo transmitido naquele segmento de rede percebido e coletado pelo software. Esse processo
tambm referido como sniffer, e o equipamento com o software de captura tambm
costuma ser designado como sniffer.
Nesta etapa, preciso escolher apropriadamente o local na rede onde o sniffer vai ser colocado. Supondo uma topologia simples de rede, tal como a ilustrada na figura 2.4, existiriam
vrias alternativas para conectar o sniffer, dependendo dos dados que se deseja coletar.
Internet
Roteador
42
Switch
Snier
Figura 2.4
Locais onde colocar
o sniffer para
capturar o trfego
da rede.
Se o objetivo fosse capturar e analisar o trfego que flui entre o roteador de borda da rede e
a internet, uma soluo seria incluir um hub entre o roteador e o switch (tal como ilustrado
na figura 2.5) interligando nesse hub o sniffer, que poderia ento capturar todos os pacotes,
fluindo entre eles.
Roteador
Snier
Hub
Switch
Figura 2.5
Hub para integrar o
sniffer no caminho
de uma interligao
a investigar.
Se o sniffer fosse interligado em uma das portas do switch, a segmentao de trfego que
naturalmente feita pelo switch impediria o sniffer de capturar e inspecionar o trfego
fluindo entre um dos equipamentos, mostrados na figura 2.4, e o roteador. Para conseguir
capturar e inspecionar esse trfego, poderia ser repetida a mesma estratgia de incluir um
hub no caminho, tal como ilustrado na figura 2.6.
Switch
Snier
Alguns modelos de switch permitem duplicar o trfego de um ou mais portas disponibilizando

uma cpia do trfego em alguma outra porta. Isso costuma ser designado como port
mirroring ou espelhamento de porta. Nesse caso, no seria necessrio o uso do hub para
permitir ao sniffer capturar o trfego da porta desejada. Bastaria configurar o switch para
fazer o espelhamento do trfego e conectar o sniffer na porta designada para receber a
cpia do trfego.
Esse mecanismo de capturar trfego tambm pode existir em alguns equipamentos que
contenham um agente RMON, o que permitir coletar dados sobre o trfego e mesmo capturar seletivamente pacotes, enviado o resultado da captura e anlise do trfego para uma
estao gerenciadora da rede, mediante o uso do protocolo SNMP. Maior detalhamento do
agente RMON ser apresentado em captulo subsequente.
Hub
Figura 2.6
Hub para derivar
um ponto de
captura em uma
porta do switch.
43
11 Converter
Depois de capturar o trfego, o sniffer atua convertendo os dados binrios capturados, de
modo que sejam mais facilmente interpretveis.
Os protocolos usados so reconhecidos e os dados contidos em cada segmento capturado so
identificados e apresentados com os respectivos cabealhos, tal como ilustrado na figura 2.7.
O nvel de detalhamento desejado pode variar, e possvel selecionar interativamente

quais os campos de cada cabealho devem ser apresentados. O pacote exibido na figura 2.7
ilustra uma interao do protocolo ICMP que ocorre quando um teste de ping comandado.
Nesse caso, podemos observar que a mquina cujo endereo IP 192.168.1.103 (enderea-
Figura 2.7
Decodificao de
protocolos feita
pelo Wireshark.
mento privativo) envia um pacote ICMP do tipo Echo request para a mquina 200.130.35.4,
que no momento do teste foi o endereo http://www.rnp.br. A traduo de nmero IP com
o nome e domnio do endereo envolvido no teste pode ser feita pelo software Wireshark
porque ele permite configurar se a resoluo de nomes deve ou no ser feita e, em caso
positivo, ele consulta um servidor de DNS para obter o nome associado ao nmero IP que
apareceu no cabealho do pacote capturado.
11 Analisar os dados capturados o terceiro e mais importante passo do processo.
44
O software trabalha sobre os dados capturados, j decodificados, e permite inspecionar os

cabealhos e demais informaes, tendo em vista os protocolos presentes em cada camada.
Camada
Protocolos
Aplicao
HTTP, SMTP, FTP, SNMP
Transporte
TCP, UDP
Rede
IP, ICMP, ARP, RIP, OSPF
Enlace
Ethernet
Figura 2.8
Protocolos usuais
na internet e
camadas em que
atuam.
A anlise pode ser feita considerando um nico pacote capturado ou sequncias de pacotes.
O trfego pode ser classificado em categorias:
11 Broadcast: trfego que dirigido a todos os dispositivos na rede;
11 Multicast: trfego que dirigido a um endereo destinatrio que representa um grupo.
Equipamentos integrantes do grupo devem ter previamente dirigido um pedido de
ingresso no grupo multicast. Essa informao fica registrada em roteadores que podem
receber um fluxo de pacotes e replicar esse fluxo por vrios caminhos onde existam
receptores registrados;
11 Unicast: trfego de um computador particular para outro computador particular.
Instalando o Wireshark
O software Wireshark pode ser encontrado no site http://www.wireshark.org e, seguindo a
opo de download, poder ser encontrada e ltima verso estvel e tambm verses mais
recentes, mas que ainda esto em desenvolvimento. O software poder ser obtido em verso
preparada para ser instalada em diversos ambientes, ou mesmo em cdigo-fonte, tal como
referido por Chapell (2010). Existem verses para diversos Sistemas Operacionais: Windows,
Apple Mac OS X, Debian GNU /Linux, rPath Linux, Sun Solaris/i386, Sun Solaris/ Sparc e
Ubuntu. As verses de instaladores que podem ser obtidas no site do Wireshark incluem:
11 Windows Installer (64-bit);
11 Windows Installer (32-bit);
11 Windows U3 (32-bit);
11 Windows PortableApps (32-bit);
11 OS X 10.6 and later Intel 64-bit .dmg;
11 OS X 10.5 and later Intel 32-bit .dmg;
11 OS X 10.5 and later PPC 32-bit .dmg;
11 Source Code.
O software Wireshark tambm pode ser instalado em mquina virtual. A instalao feita
a partir da execuo do aplicativo baixado do site do Wireshark. No caso de um ambiente
lao do software que pode comear a ser imediatamente utilizado. Quando o Wireshark
instalado, o acesso interface de rede (cabeado ou sem fio) intermediado por rotinas
de acesso, tais como: WinCap (ambiente Windows), AirCap (interface para capturar trfego
802.11) ou libcap (ambiente *NIX ).
Adicionalmente, o Wireshark pode ser usado para analisar arquivos com trfego capturado
por outros analisadores de protocolos que usam variados formatos, como:
11 libpcap: captures from Wireshark/TShark/dumpcap, tcpdump, and various other tools
using libpcaps/tcpdumps capture format;
11 pcap-ng: next-generation successor to libpcap format;
11 Microsoft Network Monitor captures;
11 AIXs iptrace captures;
11 Cinco Networks NetXRay captures;
11 Network Associates Windows-based Sniffer captures;
11 Network General/Network Associates DOS-based Sniffer (compressed or
Windows (64 bits), por exemplo, o aplicativo Wireshark-win64-1.10.8.exe efetua a insta-
uncompressed) captures;
45
11 WAN/LAN analyzer captures;

11 Network Instruments Observer version 9 captures;
11 files from HP-UXs nettle;
11 the output from VMSs TCPIPtrace/TCPtrace/UCX$TRACE utilities;
11 Linux Bluez Bluetooth stack hcidump -w traces;
11 Juniper Netscreen snoop files;
11 Symbian OS btsnoop files;
11 Apple PacketLogger files;
11 Files from Aethra Telecommunications PC108 software for their test instruments.
Utilizando o Wireshark
Quando o Wireshark executado, a tela inicial exibida na figura 2.9 apresentada.
Essa pgina de abertura tem quatro sees:

11 rea de captura (Capture): configurao do processo de captura;
11 rea de arquivos (Files): permite selecionar e abrir arquivos com capturas previamente
realizadas, para anlise no Wireshark;
11 rea online (Online): permite acessar material de ajuda que est online na rede;
11 rea de ajuda para a captura (Capture Help): contm orientaes e instrues para
realizar a captura.
A rea de captura apresenta uma lista de interfaces ativas reconhecidas pelo Wireshark.
Clicando em Interface List, a janela tal como mostrada na figura 2.10, exibida. Para iniciar a
captura por alguma das interfaces listadas, basta selecion-lo e depois clicar no boto Start.
46
Figura 2.9
Tela inicial do
Wireshark.
Figura 2.10
Interfaces ativas
reconhecidas pelo
Wireshark.
O boto Options permite configurar aspectos especficos da captura, tal como ilustrado na
Figura 2.11
Configurando
opes de captura
no Wireshark.
Se houver dvidas sobre o que escolher, uma sugesto deixar as marcaes de opes no
modo como so encontradas (modo default). Mas tambm possvel ir ajustando as opes
para que o processo de captura e o resultado melhor atendam a necessidade de quem est
investigando um problema na rede. As opes apresentadas so explicadas a seguir:
11 Capture on all interfaces: melhor deixar desmarcado, pois o normal capturar trfego
apenas em uma interface, a menos que seja necessrio combinar a captura de dois segmentos diferentes da rede;
figura 2.11.
47
11 Capture all in promiscuous mode: se o interesse na captura for inspecionar o trfego de

outras mquinas usando algumas das configuraes mostradas nas figuras 2.5 e 2.6 ou
mesmo port mirroring, ento deve ser marcada a opo captura em modo promscuo. Mas
se o interesse da captura for analisar o trfego enviado e recebido pela prpria mquina na
qual o Wireshark est sendo executado, esto essa caixa de opo pode ficar desmarcada;
11 Capture File(s): indicando um diretrio e nome de arquivo, os dados capturados sero
armazenados naquele lugar, alm se serem exibidos na janela de exibio. Mltiplos
arquivos podem ser usados e reusados de forma circular ou sequencial, com o prximo
arquivo comeando a ser utilizado em funo de tempo decorrido (minutos) ou rea
ocupada (megabytes);
11 Stop Capture: permite especificar que a captura deva ser encerrada aps uma determinada quantidade de pacotes terem sido capturados, aps uma quantidade de megabytes
terem sido coletados ou aps um tempo determinado ter decorrido;
11 Display Options:
22 Update list of packets in real time: promove a exibio dos pacotes que esto sendo
capturados;
22 Automatic scrolling in live capture: define se haver rolamento de tela na medida
em que os pacotes esto sendo capturados e exibidos;
22 Hide capture info dialog: ativa uma pequena janela que mostra um resumo do que
est sendo capturado, tal como ilustrado na figura 2.12.
48
Figura 2.12
Janela de
informaes sobre
a captura.
11 Name Resolution:
22 Enable MAC name resolution: se desmarcado, exibe apenas os caracteres hexadecimais do endereo MAC. Se essa opo for marcada, coloca informao sobre o
fabricante da interface, quando possvel;
22 Enable network name resolution: se desmarcado, exibe apenas o endereo IP. Se essa
opo marcada, consultado o servio de DNS para exibir o nome host em vez do
endereo IP. Essa opo pode ocasionar perda de captura de pacotes, pois requer que o
Wireshark consuma processamento e tempo para realizar a resoluo de nomes;
22 Enable transport name resolution: se essa opo marcada, ser exibida a aplicao associada com a porta utilizada pela camada de transporte.
O boto de Start permite iniciar a captura de pacotes com as opes configuradas na janela
de opes. Depois que um arquivo com pacotes capturados previamente aberto ou uma nova
Figura 2.13
Tela principal do
Wireshark.
As reas assinaladas nessa tela so:

1. Ttulo;
2. Menu (texto);
3. Barra de ferramentas principal;
4. Barra de ferramentas de filtragem;
5. Barra de ferramentas de rede sem fio;
6. Painel com a lista de pacotes;
7. Painel com os detalhes dos pacotes;
8. Painel com os bytes dos pacotes;
captura iniciada, a tela principal do Wireshark exibida, tal como ilustrado na figura 2.13.
9. Barra de status.
49
Ttulo
O ttulo pode ser configurado usando a opo de editar o layout em Edit/ Preferences/
Layout.
Menu
O menu localizado logo a seguir do ttulo apresenta todas as funcionalidades de trabalho
com o Wireshark, onde podemos destacar como principais:
11 File: permite abrir ou salvar um arquivo de captura para anlise posterior, alm de
exportar determinados pacotes;
11 Edit: nesse submenu, possvel marcar pacotes para posterior anlise, sinalizar um
novo pacote como sendo o incio da captura ou alterar as preferncias de visualizao da
ferramenta;
11 View: permite alterar as opes de visualizao da ferramenta, com destaque para a
opo Coloring rules, que possibilita trocar as cores de visualizao dos pacotes segundo
as regras determinadas nessa opo;
11 Go: opes de navegao entre os pacotes. Observe as teclas de atalho informadas nesse
submenu, para facilitar navegao;
11 Capture: refere-se s opes de capturas. Essas funcionalidades esto representadas
pelos primeiros cones da barra de ferramentas principal;
11 Analyze:
22 Display Filters...: permite a realizao de filtros especficos, abordado posteriormente
na barra de ferramenta de filtragem;
22 Enabled Protocols: seleo de quais protocolos sero apresentados para visualizao
no Wireshark;
22 Follow TCPStream: apresenta o contedo dos pacotes que fazem parte do mesmo
fluxo (conversa) do pacote selecionado. Por exemplo, se o pacote selecionado referente a uma comunicao HTTP, nessa opo ser possvel visualizar o contedo do
arquivo HTML na ntegra.
11 Statistics: visualizao de estatsticas, abordado posteriormente;
11 Telephony: permite a realizao de filtros sobre protocolos especficos de telefonia ou VoIP.
11 Tools:
22 Firewall ACLs rules: auxilia na criao de regras de firewall, gerando automaticamente regras nas principais plataformas existentes, como CISCO, IPtables, Windows
netsh e outras;
22 LUA: API de programao para o Wireshark.
Barra de ferramentas principal

A barra de ferramentas principal apresenta as principais ferramentas de trabalho. Nos cinco
primeiros cones esto as opes referentes ao controle de capturas de pacotes:
Visualizar a lista de interfaces para realizar uma nova captura, conforme a figura 2.10.
Alterar as opes de captura, conforme a figura 2.11.
Iniciar uma nova captura.
50
Parar uma captura.

Reiniciar a captura atual.
Barra de ferramentas de filtragem

Aps a realizao de uma captura, normalmente precisamos realizar filtros de visualizao
para selecionar apenas as informaes pertinentes ao nosso objetivo. Esse filtro pode ser
realizado por qualquer protocolo ou informao capturada. Como demonstrado na figura
Figura 2.14
Barra de
ferramentas de
filtragem.
2.14, os filtros podem ser realizados diretamente na barra de ferramentas.
Contudo, para facilitar a criao dos filtros, o Wireshark disponibiliza uma interface de
gerao de filtros, que pode ser acessada pela opo Expression.... Nessa opo, conforme
a figura 2.15, apresentada uma relao de todos os protocolos conhecidos pelo Wireshark
e o contedo de seus cabealhos.
Figura 2.15
gerao de filtros
Wireshark.
No exemplo da figura 2.15, est sendo realizado um filtro por todos os pacotes onde a porta
TCP de origem(tcp.srcport) seja igual a 80.
Figura 2.16
Filtro composto/
Filtro com erro
de sintaxe.
Na barra de ferramenta de filtragem, tambm possvel realizar filtros compostos atravs

dos operadores E (&&) e OU ( || ), como no exemplo da figura 2.16. Caso ocorra algum erro
de sintaxe no filtro, o Wireshark altera a cor da pesquisa.
Barra de ferramentas rede sem fio

Nessa barra possvel cadastrar a chave de descriptografia da rede wireless a qual voc
quer monitorar, usando para isso a opo Decription Keys... (figura 2.17). Isso necessrio
quando o WinPcap (software que realiza a captura dos pacotes no Wireshark) no possui
suporte ao adaptador de rede wireless utilizado.
Para mais informaes

e exemplos sobre filtros
de visualizao no
Wireshark, acesse
http://wiki.wireshark.
org/DisplayFilters.
51
Figura 2.17
Cadastro de chaves
descriptogrficas.
Vale resaltar que na rede wireless possvel capturar apenas os pacotes encaminhados
para a estao onde est executando o sniffer. Para capturar todos os pacotes em modo
promscuo, necessrio adquirir a interface wireless tal como o AirPcap.
Figura 2.18
Aircap.
Painel com a lista de pacotes

Nesse painel, so mostrados todos os pacotes em ordem de captura. Observe que a coluna
Time apresenta o tempo em segundos do pacote capturado em relao ao primeiro pacote.
Source e Destination apresentam o endereo de origem e destino do pacote, podendo ser
um endereo MAC ou endereo IP. Protocol apresenta o protocolo de mais alto nvel que
existe no pacote, Length apresenta o tamanho do pacote e Info uma interpretao do
Wireshark de informaes relevantes que o pacote contenha ou represente.
Painel com detalhes do pacote

Nesse painel, possvel visualizar todas as informaes contidas nos cabealhos de todas as
camadas na qual o pacote pertence. Na figura 2.18 temos o exemplo de um pacote de requisio HTTP, onde atravs das reas grifadas possvel observar o endereo MAC de origem
e destino, o endereo IP de origem e destino, o contedo da camada de transporte referente
a um contedo TCP e informaes da camada de aplicao do protocolo HTTP, incluindo o
nome do host acessado e o comando enviado, que nesse exemplo foi um GET.
52
Painel de bytes do pacote

Nesse ltimo painel da figura 2.13 esto as informaes exatamente como foram capturadas
pelo WinPcap. Observe que o pacote est sendo demonstrado em dois formatos, esquerda em
hexadecimal e direita em ASCII. Esse painel importante para sabermos a posio em que as
informaes se encontram dentro do pacote para, se necessrio, realizar pesquisas sobre elas.
Barra de status
A barra de status apresenta informaes de pacotes capturados, mostrados, marcados e,
principalmente, de pacotes perdidos. Isso nos auxilia a descobrir se realmente estamos
capturando todos os pacotes recebidos na interface de rede ou necessitamos alterar alguma
opo do Wireshark para que isso ocorra.
Filtros de captura no Wireshark

Conforme abordado no tpico sobre a barra de filtragem do Wireshark, as opes dessa
barra so filtros de visualizao. Isso significa que os pacotes so capturados em sua totalidade e depois filtrados.
Contudo, dependendo do fluxo de informaes que passam pela estao de captura, muitos
pacotes podem ser perdidos pela grande quantidade de pacotes recebidos. Tambm pode
ocorrer que o objetivo da captura de pacotes seja a busca de algo especfico. Nesses casos,
podemos realizar um filtro de captura, o qual ser realizado pela biblioteca WinPcap no
Figura 2.19
Detalhamento
do pacote.
momento do recebimento dos pacotes na interface de rede, desonerando os recursos de

hardware e software para o armazenamento de todos os pacotes capturadas.
53
Esse filtro dever ser realizado antes do incio da captura, diretamente na tela inicial do
Wireshark na opo Capture Options ou atravs do menu Capture/Options (figura 2.20).
Dentro das opes de captura, selecione a interface na qual ser realizada a captura (1) e
clique duas vezes. Com isso, a janela de configurao da interface ser aberta e a opo de
filtros de captura (2) estar disponvel.
A escolha de filtros de captura apropriados importante para limitar a quantidade de
pacotes capturados, pois em redes com alto trfego a quantidade de pacotes elevada e o
fluxo de trfego contm muitos pacotes que podem no interessar ao processo de diagnsticos em curso. Adicionalmente, quando a quantidade de pacotes capturada muito grande,
o funcionamento do prprio software fica degradado (mais lento).
Outro aspecto a considerar que pode ocorrer perda de pacotes pela incapacidade do equipamento de captura. Mesmo que uma interface de rede de um equipamento, tal como um
notebook, possa ter capacidade de operar em velocidade alta (1 Giga, por exemplo), isso no
significa que o equipamento vai conseguir capturar, decodificar e armazenar um fluxo de
bits por segundo prximo dessa velocidade. Equipamentos dedicados captura de trfego
tm capacidade de captura mais elevada.
54
Figura 2.20
Filtros de captura.
No Wireshark, a sintaxe dos filtros de captura diferente da sintaxe dos filtros de visualizao, pois, como j mencionado, os filtros de captura so realizados pela WinPcap, que
utiliza a mesma sintaxe do aplicativo tcpdump, apresentado posteriormente nesse captulo.
Para melhor entendimento, a explicao dos filtros de capturas mais usuais sero apresentados em exemplos:
Filtro
Sintaxe do filtro
Capturar o trfego de pacotes recebidos e enviados do host 10.10.1.13
host 10.1.1.13
Capturar os pacotes originados da rede 10.1.1.0/24
src net 10.1.1.0/24
Capturar os pacotes que possuem a rede 200.132.0.0/16 como destino e

encaminhados para a porta 80
dst net 200.132.0.0/16 and port 80
Capturar todos os pacotes TCP que a porta no seja 80 e 443
tcp and not ( port 80 or port 443)
Tabela 2.1
Exemplos de filtros
de captura do
Wireshark.
Estatsticas no Wireshark
Alm de capturar pacotes, o Wireshark uma poderosa ferramenta estatstica, que nos
auxilia na anlise da rede. Atravs das estatsticas conseguimos responder perguntas como:
11 Quais so os protocolos mais utilizados na minha rede?
11 Qual o tamanho mdio de pacotes da rede?
Figura 2.21
Sumarizao da
captura realizada.
Atravs do menu Statistics/Summary, conforme a figura 2.21, podemos verificar o tempo

de captura realizada, a quantidade de pacotes capturados, qual o tamanho em bytes da
captura e a mdia de bytes e pacotes por segundo.
w
Outros exemplos de
filtros podem ser
acessados em
http://wiki.wireshark.
org/CaptureFilters
11 Quantos % de broadcast h na rede?
55
No menu Statistics/Protocol Hierarchy, obtemos a proporo de pacotes por protocolos.

Como no exemplo da figura 2.22, que mostra pacotes IPv6 e pacotes IPv4, sendo em sua
maioria TCP e 21,77% transmisso de dados por FTP.
Atravs do menu Statistics/Conversations, visualizamos os fluxos de dados captados, a

figura 2.23 apresenta 6 fluxos Ethernet, os quais contm 54 fluxos IPv4 e 1 fluxo IPv6, divididos em 127 fluxo TCP e 138 UDP. Nos fluxos TCP o Wireshark apresenta a quantidade de
Figura 2.22
Hierarquia de
protocolos.
bytes, pacotes e a durao de cada fluxo separado por endereo e porta.
Grficos de bytes ou pacotes por perodo tambm esto disponveis no Wireshark atravs
do menu Statistics/IO Graph. No exemplo da figura 2.24, foi gerado um grfico de total de
pacotes por segundo dos protocolos TCP e UDP. Essa funcionalidade permite cinco diferentes filtros no mesmo grfico.
56
Figura 2.23
Fluxos de dados.
w
No endereo http://
www.wireshark.org/
docs/wsug_html_
chunked/ voc
encontra o manual
completo do Wireshark,
com todas as suas
funcionalidades.
Figura 2.24
Gerao de grficos
do Wireshark.
Um segundo tipo de grfico est disponvel na ferramenta. Ele demonstra qual o fluxo dos
pacotes entre origem/destino de uma comunicao. Conforme a figura 2.25, onde encontra o
resultado do grfico gerado pela opo Statistics/Flow Graph, podemos observar que em
Figura 2.25
0 Fluxo da
comunicao.
No Wireshark existem mais de 20 tipos de estatsticas, das quais foram abordadas as mais usuais.
No endereo http://www.wireshark.org/docs/wsug_html_chunked/ voc encontra o manual
completo do wireshark com todas as suas funcionalidades.
um determinado momento o IP 10.10.1.3 realizou uma consulta DNS para o destino 10.10.1.1.
57
TCPDUMP
O tcdump outra ferramenta de monitorao que est disponvel para a maioria dos
Sistemas Operacionais derivados do Unix, incluindo MacOS. Nesse aplicativo, que utiliza a
LibPcap, as capturas de pacotes so realizadas sem interface grfica. Sendo assim, os resultados das capturas podero ser visualizadas no terminal do Sistema Operacional, salvas em
formato texto ou no formato LibPcap. Utilizando o formato LibPcap, possvel visualizar a
captura no Wireshark.
Formato simplificado:
#tcpdump [opes] [filtro]

[opes]
11 -i: determina a interface. Dica: execute o comando ifconfig para saber as interfaces de
rede existentes;
11 -s: maior tamanho de pacote a ser capturado;
11 -c: nmero de pacotes a serem capturados;
11 -n: evita a resoluo de nomes para os endereos e portas;
11 -v: modo detalhado, inclui mais informaes do pacote. Teste tambm as opes -vv e
-vvv para ter mais detalhes;
11 -w <arquivo>: nome do arquivo que armazenar a captura no formato LibPcap;
11 -r <arquivo>: utilize essa opo para visualizar os pacotes de uma captura realizada
anteriormente com a opo -r.
[filtro]
Os filtros do TCPDUMP so iguais aos filtros de captura do Wireshark, permitindo filtros por
endereo IP, portas, redes de origem destino ou qualquer campo existente no cabealho do
protocolo a ser capturado. Todas as possibilidades de filtros podem ser acessadas no link
http://www.manpagez.com/man/7/pcap-filter/
Exemplos:
Capturando todo o trfego da interface eth2.
#tcpdump -i eth2
Capturando 500 pacotes com at 1500 bytes e gravando em arquivo.
#tcpdump -i eth2 -s 1500 -c 500 -w
58
pacotesCapturados.pcap
Monitorando os pacotes recebidos de uma mquina especfica.
#tcpdump -i eth2 src host 143.54.1.26
Referncias
11 CHAPPELL, Laura. Wireshark Network Analysis: The Official Wireshark Certified Network
Analyst Study Guide. 2010. Protocol Analisys Institute.
11 CHAPPEL, Laura. Wireshark 101 Essential Skills for Network Analisys. Protocol Analysis
Institute, Inc. 2013
11 CISCO. Cisco BTS 10200 Softswitch Troubleshooting Guide, Release 4.4 2008: Cisco
Systems, Inc.
11 COMBS,Gerald. Wireshark DisplayFilters.
Disponvel em: <http://wiki.wireshark.org/DisplayFilters >
11 HORN,Mike. Wireshark CaptureFilters.
Disponvel em: <http://wiki.wireshark.org/CaptureFilters>
11 JACOBSON, Van; LERES, Craig; MCCANNE, Steven. TCPDUMP man pages: Lawrence
Berkeley National Laboratory, University of California, Berkeley, CA.
Disponvel em <http://www.manpagez.com/man/1/tcpdump/>
11 LAMPING ,Ulf; SHARPE, Richard; WARNICKE, Ed. WiresharkUsers Guide.
Disponvel em <http://www.wireshark.org/docs/wsug_html_chunked/>
11 SANDERS, Ghris. Practical Packet Analysis Using Wireshark to solve real world problems.
2007 No Starch Press Inc. San Francisco.
59
Questionrio para testar os conhecimentos relativos ao uso

do Wireshark
1. Qual funcionalidade fica disponvel somente com o modo de operao promscuo?
FF Permitir a um adaptador WLAN capturar pacotes independente do valor do SSID.
FF Possibilitar que uma interface capture pacotes ARP request/result.
FF Possibilita a uma interface capturar pacotes que so enviados para qualquer
endereo MAC.
FF Possibilitar que uma interface capture pacotes endereados para endereos
broadcast e multicast.
2. Qual afirmativa sobre o trfego TCP ilustrado na figura est correta?
FF O cliente HTTP solicitou um arquivo grfico.

FF O servidor HTTP recusou a tentativa de conexo TCP do cliente.
FF O servidor HTTP redirecionou o pedido do cliente para outro servidor.
FF O cliente HTTP enviou um pedido HTTP GET para o servidor HTTP.
3. Que tipo de trfego pode ser visto quando voc conecta Wireshark diretamente a um
switch sem configurar port spanning ou port mirroring?
FF Broadcast.
FF Rudo e interferncia.
FF Consultas DNS de todos os hosts.
FF Quadros que contm erros de CRC.
4. Quais dos filtros a seguir podem ser usados como filtro de captura ou como filtro de
apresentao (display)?
FF dns.
FF udp.
FF dhcp.
FF broadcast.
60
5. Qual afirmativa sobre as definies na tela de opes de captura mostrada est correta?
FF Wireshark vai resolver endereos IP em nomes de host.

FF Wireshark vai rolar a tela para mostrar o pacote mais recente.
FF Wireshark vai tentar resolver valores OUI para todos os endereos MAC.
FF Wireshark automaticamente vai parar a captura depois que dois arquivos forem salvos.
6. Qual o tipo de pacote pode ser transmitido pelo Wireshark quando voc habilita a resoluo de nomes?
FF DHCP requests.
FF UDP multicasts.
FF invese DNS queries.
FF ping broadcasts.
61
7. Qual entre as afirmativas seguintes relativas janela de Opes de Captura (Capture

Options) mostrada est correta?
FF Wireshark resolve endereos IP em nomes de host.

FF Wireshark rola a tela para exibir os pacotes mais recentemente capturados.
FF Wireshark tenta resolver valores OUI para todos os endereos MAC.
FF Wireshark encerra a captura automaticamente depois que dois arquivos tiverem sido salvos.
8. Que filtro de display pode ser usado para exibir todo o trfego DHCP?
FF bootp
FF dhcp
FF tcp-port == 68
FF ip.addr ==[address_of_dhcp_server]
9. Qual afirmativa entre as seguintes verdadeira?
FF Pacotes marcados so marcados apenas temporariamente.
FF Pacotes marcados podem ser usados para gerar filtros de exibio.
62
FF Pacotes marcados podem ser criados usando regras de colorir pacotes.

FF Pacotes marcados so automaticamente salvos em um arquivo temporrio.
10. Qual tipo de trfego pode ser visto quando se conecta equipamento com Wireshark diretamente em um switch sem configurar port spanning ou port mirroring?
FF Trfego broadcast.
FF Rudo e interferncia.
FF Consultas DNS de todos os hosts.
FF Quadros que contenham erros
3
Conhecer MIB; Aprender sobre Linguagem SMI; Entender os Protocolos SNMP;
Saber sobre os tipos de agentes SNMP.
conceitos
MIB; Linguagem SMI; Protocolo SNMPv1; Protocolo SNMPv2; Protocolo SNMPv3;

Tipos de agentes SNMP.
Contextualizao
Motivao:
11 Necessidade de controlar equipamentos heterogneos.

11 Interligao em redes TCP/IP no possui protocolo nico no nvel de enlace.
11 Os equipamentos podem estar localizados em pontos arbitrrios da interligao de redes.
As atuais redes de computadores apresentam os mais diversos equipamentos: computadores com diferentes Sistemas Operacionais (Windows, Linux e OSX), equipamentos de
comunicao de dados (switches, roteadores e access points para redes sem fio), impressoras conectadas em computadores ou ligadas diretamente nas redes, tablets, telefones
celulares etc. Esses equipamentos esto interconectados em redes heterogneas, isto ,
com diferentes padres fsicos e de enlace: redes com fio, redes sem fio, redes de longa
distncia e redes locais.
Portanto, para realizar a gerncia da rede necessrio obter informaes de uma variedade
considervel de equipamentos, dispostos em redes distintas. Para que essa diversidade no
se constitua em um problema, h necessidade de padres que definam:
11 Um modelo de gerncia: gerente ou agente;
11 As informaes que podem ser obtidas: Management Information Base (MIB);
11 As aes que podem ser realizadas: MIB;
11 A forma como as operaes podem ser requisitadas: protocolo Simple Network Management Protocol (SNMP);
11 A maneira como novas informaes podem ser incorporadas ao modelo: Structure of
Managemento Information (SMI).
A figura 3.1 representa de forma esquemtica o modelo de gerncia utilizado nas redes TCP/IP.
Captulo 3 - SNMPv1, SNMPv2 e SNMPv3
objetivos
SNMPv1, SNMPv2 e SNMPv3
Os equipamentos podem executar um dentre dois papis: gerente ou agente. O gerente

63
a entidade: geralmente software executando em um computador: que coleta informaes

a respeito dos dispositivos que se deseja gerenciar. Alm de coletar informaes a serem
apresentadas aos responsveis tcnicos pela rede, tambm envia comandos aos equipamentos gerenciados. O agente a entidade instalada nos diversos ns da rede que se
pretende gerenciar e que coleta informaes no hardware e no Sistema Operacional para
repass-las ao gerente. Dessa forma, uma impressora ou um computador que deve ser
gerenciado remotamente ter uma implementao de um agente que responde s mensagens enviadas pelo gerente. usual tambm utilizar os termos gerente e agente para indicar
o dispositivo propriamente dito que executa uma ou outra funo.
O agente SNMP tambm pode enviar estao gerente mensagens disparadas em funo
da ocorrncia de eventos pr-determinados. Essas mensagens so chamadas de traps e
costumam ser usadas para gerar alertas de forma assncrona, ou seja, sem depender de
solicitao da estao gerente.
Placa Ethernet
MIB
Agente SNMP
PC
MIB
Software de aplicao
Agente SNMP
Gerente SNMP
Agente SNMP
MIB
Roteador
Agente SNMP
MIB
A comunicao entre gerentes e agentes ocorre atravs de um protocolo chamado Simple

Network Management Protocol (SNMP). J as informaes de gerenciamento so chamadas
de objetos gerenciados. O gerente, quando envia uma mensagem para o agente, solicita o
envio de algum objeto gerenciado ou mesmo de um conjunto deles. Por exemplo, o nmero
de erros de uma interface de rede considerado um objeto gerenciado. Se o gerente
pretende realizar uma configurao remota no agente, atuar sobre um objeto gerenciado.
Por exemplo, o status de uma interface (ligada ou desligada) um objeto gerenciado que
64
poderia ser utilizado para ligar ou deslig-la.

O conjunto de objetos gerenciados conhecidos por um agente, isto , implementado por
ele, recebe a denominao de Management Information Base (MIB). Apesar do nome, a MIB
no indica como os objetos gerenciados esto armazenados, mas define a forma como eles
devem ser disponibilizados aos gerentes. A figura 3.2 mostra como ocorre uma consulta de
um gerente a um agente.
Figura 3.1
Esquematizao do
modelo de gerncia
TCP/IP.
MIB
MIB
SNMP
Agente
Gerente
Grupo
Objetos
SNMP
Figura 3.2
Solicitao de
objeto gerencivel
pelo gerente
ao agente.
Grupo
Objetos
Para que gerentes e agentes possam comunicar-se, existem MIBs padronizadas. A especificao dos objetos gerenciveis de uma MIB, seus significados e operaes permitidas feita
com uma linguagem de definio de dados denominada Structure of Management Information (SMI), que um subconjunto de uma linguagem mais abrangente denominada ASN.1
(Abstract Syntax Notation One).
MIBs Padronizadas
MIB I:
11 Definida pela RFC 1156.

11 Verso inicial da MIB para gerenciamento de redes baseadas em TCP/IP.
MIB II:
11 Definida pela RFC 1213.
11 Superconjunto da MIB I.
11 Estende a MIB I, incluindo novos objetos e mdulos. Tambm tornou alguns objetos
obsoletos.
11 Acrescenta suporte a outros protocolos de interligao.
importante destacar que por MIB entende-se a coletnea dos objetos gerenciados. Em
tese, qualquer um pode definir uma MIB, mas a existncia de MIBs padronizadas permite
que qualquer equipamento ligado internet seja administrado pelos mais diferentes
softwares de gerncia de redes. Se cada fabricante implementasse em seus dispositivos
um conjunto diferente de objetos gerenciados, seria muito difcil desenvolver softwares
gerenciadores de rede genricos.
A MIB I e a MIB II so padres estipulados atravs de Request For Comments (RFCs). Essas
RFCs definem os objetos gerenciados que deve ser implementados por qualquer agente.
A MIB I definida na FRC 1156, de maio de 1990. Ela apresenta oito grupos de objetos, listados na tabela 3.1.
MIB
65
Nome do grupo
Funo dos objetos do grupo
System
Informaes gerais do sistema.
Interfaces
Informaes sobre as interfaces de rede.
Address Translation
Relao endereo fsico: endereo de rede (IP).
IP
Informaes do protocolo IP (pacotes recebidos e enviados, TTL,

erros, tabela de endereos, tabela de roteamento etc.)
ICMP
Estatsticas ICMP.
TCP
Informaes do protocolo TCP e tabela de conexes.
UDP
Informaes do protocolo UDP.
EGP
Informaes do protocolo EGP.
A MIB II definida na RFC 1213 de maro de 1991. Existem RFCs que tratam de grupos
especficos, tais como:
11 RFC 4293, de abril de 2006- grupo IP;
11 RFC 4022, de maro de 2005: grupo TCP;
11 RFC 4113, de junho de 2005: grupo UDP;
Em relao MIB I, as mudanas mais significativas foram:
11 O objeto atTable (tabela que relaciona endereo fsico com endereo de rede) foi marcado
como deprecated, significando que seria removido em verses futuras;
11 Novos objetos foram acrescentados no grupo System;
11 Ajustes foram realizados nos grupos interfaces, IP, TCP, UDP e EGP. O grupo EGP, na
realidade, raramente utilizado;
11 Adio de um novo grupo chamado Transmission, para identificar meios de transmisso;
11 Adio de um grupo chamado SNMP, para guardar informaes do protocolo de
gerncia de redes.
possvel interpretar os padres MIB I e MIB II como definies de classes, sendo que os
objetos armazenados em cada equipamento, no banco de dados MIB, so instncias da
classe MIB I ou MIB II.
rvore de identificadores
Considerando que as operaes de gerncia ocorrem a partir de objetos gerenciados
66
definidos em MIBs que esto implementadas em agentes, necessrio que esses objetos
possam ser identificados de forma unvoca. O identificador de um objeto chamado de
Object Identifier (OID) e formado com base em uma rvore de identificadores de objetos.
A figura 3.3 corresponde a uma parte da rvore de identificadores utilizada. Ela apresenta
todo o caminho do n raiz (iso) at um objeto gerenciado, cujo nome sysDescr. Esse objeto
contm a descrio do agente.
Tabela 3.1
Grupos de objetos
da MIB I (RFC 1156).
iso (1)
org (3)
dod (6)
internet (1)
Figura 3.3
Parte da
rvore de OIDs
(identificadores
de objetos).
mgmt (2)
private (4)
mib-2 (1)
enterprise (1)
sua-empresa (n)
system (1)
smar (27120)
sysDescr (1)
A identificao do objeto gerenciado d-se pela concatenao dos nmeros ou dos nomes
da rvore, separados por pontos (.). Essa concatenao corresponde ao caminho que vai
da raiz at o objeto em questo. Dessa forma, o objeto gerenciado sysDescr tem como iden-
w
O site http://www.
oid-info.com pode ser
utilizado para a busca e
identificao de
identificadores de
objetos (OIDs).
tificador unvoco as seguintes representaes:

11 1.3.6.1.2.1.1.1
11 iso.org.dod.internet.mgmt.mib-2.system.sysDescr
rvore da MIB II
importante conhecer melhor os grupos de objetos gerenciados presentes na definio da
MIB- II. A figura 3.4 apresenta a rvore com esses grupos.
Root-Node
ccitt (0)
iso (1)
joint (2)
org (3)
dod (6)
internet (1)
directory (1)
mgmt (2)
experimental (3)
private (4)
mib-2 (1)
Figura 3.4
rvore com os
grupos da MIB-II.
system (1)
interfaces (2)
at (3)
ip (4)
icmp (5)
tcp (6)
udp (7)
egp (8)
transmission (10)
snmp (11)
67
11 system: define a lista de objetos pertencentes operao do sistema em geral, tais como
identificao, tipo de hardware utilizado, Sistema Operacional e softwares de rede.
Os seguintes objetos fazem parte desse grupo:
22 sysDescr: descrio do dispositivo;
22 sysObjectID: identificao do software que implementa o agente SNMP;
22 sysUpTime: tempo de execuo do agente SNMP;
22 sysContact: dados do responsvel pelo dispositivo;
22 sysName: nome do dispositivo;
22 sysLocation: localizao fsica do dispositivo;
22 sysServices: camadas do modelo OSI implementadas pelos dispositivo.
11 interfaces: apresenta dois objetos principais: o nmero de interfaces de rede do dispositivo (ifNumber) e uma tabela com dados sobre cada interface (ifTable). As informaes da
tabela so semelhantes quelas apresentadas pelo comando show interface nos roteadores Cisco e pelo comando ifconfig em sistemas Unix like: ifDescr, ifType, ifMtu, ifSpeed,
ifPhysAddress, ifAdminStatus, ifOperStatus, ifLastChange, ifInOctets, ifInUcastPkts,
ifInNUcastPkts, ifInDiscards, ifEnErrors, ifInUnknownProtos, ifOutOctets, ifOutUcastPkts,
ifOutNUcastPkts, ifOutDiscards, ifOutQlen e ifSpecific;
11 at: armazena a tabela de mapeamento entre endereos fsicos de rede e endereos de
interligao de redes (IP). Esse grupo possui o status deprecated, ou seja, no est mais
em uso, estando presente somente por motivos de compatibilidade;
11 ip: define aspectos relacionados ao protocolo IP. Alguns objetos so escalares e outros
so do tipo tabela. Como objetos escalares, podem ser citados ipForwarding, ip
DefaultTTL, ipInReceives, ipOutReceives, entre outros. J as tabelas so:
22 ipAddrTable: tabela com endereo, mscara, broadcast e tamanho mximo do datagrama remontado para cada interface;
22 ipRouteTable: tabela com rotas para diferentes destinos;
22 ipNetToMediaTable: tabela de mapeamento entre endereos IP e de enlace.
11 icmp: define contadores para cada uma das mensagens do protocolo ICMP. Alguns exemplos so: icmpInMsgs, icmpInErrors e icmpInDestUnreachs;
11 tcp: define as informaes relacionadas ao protocolo TCP. Nesse grupo, h objetos
escalares que indicam parmetros do protocolo, tais como o timeout mximo de
retransmisso (tcpRtoMax) ou nmero mximo de conexes (tcpMaxConn). Tambm h
uma tabela denominada tcpConnTable que mantm informaes sobre conexes TCP
com os seguintes campos: tcpConnState, tcpConnLocalAddress, tcpConnLocalPort,
tcpConnRemAddress, tcpConnRemPort. importante observar que as informaes rela-
68
cionadas diretamente com conexes especficas esto disponveis apenas enquanto a

conexo estiver ativa. Dessa forma, quando as conexes so encerradas, seus dados
so descartados, restando apenas as informaes contabilizadas nos contadores;
11 udp: esse grupo semelhante ao tcp. Armazena as informaes relacionadas ao protocolo UDP. Foram definidos quatro objetos escalares (udpInDatagrams, udpNoPorts,
udpInErrors e udpOutDatagrams) e uma tabela (udpTable), que relaciona as portas que
aceitam datagramas para cada endereo local;
11 egp: Define as informaes referentes ao protocolo Exterior Gateway Protocol (EGP),

como a tabela de roteamento, a quantidade de mensagens recebidas, permitindo distinguir aqueles que resultaram em erros ou que contm erros, a quantidade de mensagens
enviadas, entre outros. Apesar de ser um protocolo obsoleto, pois foi substitudo pelo
Border Gateway Protocol (BGP), as informaes sobre esse protocolo ainda encontram-se
disponveis na MIB II;
11 transmission: corresponde a um espao para definio de novas MIBs, especificando
os diversos meios de comunicao utilizados. importante observar que esse grupo foi
inserido somente na MIB II, no estando presente na MIB I;
11 snmp: assim como o grupo transmission, o grupo snmp tambm foi inserido na MIB
II. Ele define objetos para o gerenciamento do prprio agente SNMP. Como exemplos
podem ser citados os seguintes objetos:
22 snmpInPkts: contador de pacotes SNMP recebidos;
22 snmpinBadVersions: contador de pacotes recebidos com a verso errada do protocolo.
MIB para tecnologias de transmisso

11 Definida no grupo transmission, com OID 10.
11 Usada para definir o valor da coluna ifType nos objetos ifTable de cada interface.
11 Exemplos:
22 Ethernet RFC 1643
22 Ds1 RFC 1406
22 DS3 RFC 1407
22 PPP RFC 1471
22 Frame-Relay RFC 1315 e 1604
22 Sonet-SDH RFC 1595
22 aal5
O grupo transmission define objetos para a caracterizao do meio de transmisso utilizado,
considerando, tambm, a camada de acesso ao meio (enlace).
Cada RFC (Request for Comment) define um padro de comunicao. Dessa forma, so definidos, em alguns casos, vrios objetos MIB para tratar diferentes aspectos da tecnologia de
enlace e camada fsica. Como exemplo, considere a RFC 1643, que trata do padro Ethernet.
Nessa RFC so definidos os objetos ethernet-csmacd (6), iso88023-csmacd (7) e slarLan (11).
misso, utilizando diferentes OID.
Os dados usados nesse grupo so replicados no atributo ifType de cada linha do objeto
ifTable, que armazena as informaes das interfaces do equipamento. Dessa forma, possvel definir o tipo de tecnologia empregada em cada interface do equipamento monitorado.
Novos grupos da MIB II

A partir da definio da MIB II, novos grupos foram criados:
11 appleTalk (13): RFC 1742
11 ospf (191): RFC 1850
11 bgp (15): RFC 1657
Da mesma forma para a RFC 1471, tambm so definidos vrios objetos sob o grupo trans-
69
11 rmon (16): RFC 1724

11 dns (32): RFC 1611
11 rip2 (23): RFC 1724
11 Application (27): RFC 1565
medida que novas necessidades surgem, novos grupos de objetos so adicionados MIB
II. Esses grupos so definidos em RFCs prprias. Assim, a quantidade de objetos do grupo
mib-2 ampliada medida que essas RFC so publicadas.
interessante observar que o objeto application, definido pela RFC 1565 com OID 27, define
padres para aplicaes de rede, como Mail Transfer Agent (MTAs), facilitando assim o monitoramento, j que as informaes tornam-se padronizadas.
Se, por um lado, os objetos gerenciados definidos diretamente na RFC 1213 so implementados em praticamente todos os dispositivos que permitem a gerncia SNMP, o mesmo no
ocorre para as extenses.
Extenses privadas MIB

Sob a subrvore iso.organization.dod.internet.private (1.3.6.1.4) so alocados os identificadores para instituies privadas, como a Microsoft, Cisco e Oracle, que esto vinculados
ao grupo enterprises (1.3.6.1.4.1). Dessa forma, os diversos fabricantes de equipamentos
podem definir novos objetos gerenciados sob sua responsabilidade, especficos para os
seus produtos. Como exemplo, considere o formato dos arquivos do Microsoft Word, que se
encontra definido em (1.3.6.1.4.1.311.1.2.840.113556.4.2).
Inicialmente, novos objetos so criados no ramo experimental (1.3.6.1.3), sendo transferidos
posteriormente pelo fabricante para o ramo private.
w
A lista completa de
identificadores de
organizaes pode ser
obtida em: http://www.
iana.org/assignments/
enterprise-numbers.
A figura 3.5 apresenta parte da rvore com ns privados.

International Organization for Standardization (ISO) 1
Organization 3
Department of Defense (DOD) 6
Internet 1
Directory 1
Management 2
Experimental 3
mib-2
70
Novell 23
Private 4
Enterprises 1
Lanmanager 77
Microsoft 311
Cisco 9
Software 1
Systems 1
WINS 2
DHCP 3
Figura 3.5
rvore de OIDs com
ns privados.
Um exemplo prtico a MIB definida pela CISCO para suas VLANS (CISCO Private VLAN MIB).
Os objetos constantes nessa MIB permitem a gerncia das redes locais virtuais nos equipamentos da CISCO. Embora, incialmente, possa-se pensar que apenas gerentes da CISCO
fariam uso dessa MIB, por ser um padro publicado na mesma linguagem de todas as MIBs
(SMI), possvel desenvolver gerentes que atuem sobre os objetos ali definidos ou mesmo
compilar a MIB em gerenciadores de redes genricos que permitem a adio de novas MIBs.
Structure of Management Information (SMI)

11 Linguagem usada para definir as informaes de gerenciamento.
11 Assegura que a sintaxe e a semntica dos dados sejam bem definidos e isentos de
ambiguidades.
11 Subconjunto da notao ASN.1 (Abstract Syntax Notation One).
11 Verses:
22 SMIv1.
33 Utilizada com SNMPv1.
33 Definida e alterada nas RFCs1155, 1212 e 1215.
22 SMIv2.
33 Utilizada em SNMPv2 e SNMPv3.
33 Definida e alterada nas RFCs 1442,1902 e 2578.
A Structure of Management Information (SMI) uma linguagem que permite a definio de
objetos gerenciados. Com essa linguagem possvel definir e descrever os objetos da MIB
e agrup-los em subconjuntos. Essa tarefa somente possvel porque a SMI define tipos
bsicos de dados, que sero empregados na definio dos atributos dos objetos.
Uma vez que a SMI um subconjunto da ASN.1, possvel ampli-la para atender demandas
futuras. Atualmente existem duas verses: a primeira, denominada SMIv1 (RFCs 1155, 1212
e 1215), empregada com o protocolo SNMPv1. A segunda verso, denominada SMIv2 (RFC
2578), utilizada com as verses dois e trs do protocolo SNMP.
Como existem diferentes verses de SMI para diferentes verses do protocolo SNMP, estas
sero estudadas em conjunto com as respectivas verses do protocolo em que so empregadas. Nesta sesso, ser apresentado um exemplo bsico para compreenso de qualquer
uma das verses.
A definio de um objeto gerenciado apresenta cinco partes:
11 Sintaxe do objeto que deve corresponder a um tipo primitivo;

11 Definio textual do objeto;
11 A autorizao de acesso do objeto (read-only, read-write, write-only ou not-accessible);
11 A obrigatoriedade de implementao do objeto (mandatory, optional ou obsoleto).
Essa organizao perceptvel na definio do objeto sysDescr, apresentada a seguir.
sysDescr OBJECT-TYPE
SYNTAX
DisplayString (SIZE (0..255))
ACCESS
read-only
11 Nome do objeto e seu identificador (OID);
71
STATUS
mandatory
DESCRIPTION
A textual description of the entity.
This value
should include the full name and version

identification of the systems hardware type,
software operating-system, and networking
software.
It is mandatory that this only contain
printable ASCII characters.

::= { system 1 }
A definio comea com o nome do objeto seguido pela palavra-chave OBJECT-TYPE. O
identificar est localizado no fim da definio, antecedido pelo objeto hierarquicamente
superior na rvore de OIDs (system). A seo SYNTAX indica que limitado a um tipo bsico
chamado DisplayString, que pode ter 0 a 255 caracteres. A seo ACCESS limita o objeto
leitura, isto , ele no pode ser atualizado pelo gerente remoto. A seguir, a seo STATUS
sinaliza a obrigatoriedade de implementao e a seo DESCRIPTION explica a semntica do
objeto gerencivel.
SNMP Introduo
Caractersticas:
11 Aberto.
11 Padro de mercado: TCP/IP.
11 Simples.
22 Especifica poucas operaes.
22 Baseado no paradigma de busca e armazenamento (fetch-store paradigm).
11 Implementado na camada de aplicao.
11 Utiliza o protocolo User Datagram Protocol (UDP) na camada de transporte.
O Simple Network Management Protocol (SNMP) o padro mais popular para protocolo
de gerncia de rede. um padro aberto adotado por vrios fabricantes e operadoras, definindo o funcionamento da arquitetura de gerenciamento de redes TCP/IP.
um protocolo simples de ser implementado em todo tipo de equipamento e flexvel o bas Gerncia de Redes de Computadores
tante para aceitar modificaes posteriores, uma vez que possui poucas operaes, alm de
72
utilizar o paradigma fetch-store. Nesse paradigma, o gerente busca (fetch) as informaes

do agente para descobrir o status deste ltimo. J para atuar sobre o agente, o gerente
altera valores de variveis (store) do agente. Sempre que uma varivel de um agente alterada, uma ao ser executada.
O protocolo SNMP um protocolo de nvel de aplicao na arquitetura de rede TCP/IP. Por
utilizar como transporte o protocolo UDP, ele responsvel pela deteco de mensagens
no recebidas. A figura 3.6 mostra o encapsulamento do protocolo.
PDU da tecnologia de rede

(Ethernet por exemplo)
Pacote IP
Datagrama UDP
Mensagem SNMP
O SNMP faz uso da tcnica de timeout para recuperar eventuais datagramas perdidos. Para
evitar retransmisses infinitas, utilizado um limite de tentativas, cujo valor configurado
pelo administrador do gerente.
Essa soluo implica menor sobrecarga aos links e equipamentos, uma vez que a adoo
do protocolo TCP exigiria o estabelecimento e o encerramento de conexes (three-way
handshake), bem como pacotes de confirmao para as mensagens enviadas (acknowledgement). Isso aumentaria consideravelmente a quantidade de pacotes trafegados pelo link.
Alm disso, o estabelecimento de conexes amplia o consumo de memria nos equipamentos de interligao, que normalmente restrita.
Verses
11 SNMPv1:
22 Padro histrico IETF;
22 RFC 1157 de 1990;
22 Segurana baseada em comunidades;
22 Troca de informao baseada em textos simples.
11 SNMPv2:
22 RFC Principais 3416, 3417 e 3418;
22 Amplia as operaes definidas na verso 1;
22 Unificao dos PDU (Protocol Data Unit);
22 Possui variantes.
11 SNMPv3:
22 RFC 3410 3418 e 2576;
22 Avano em segurana e privacidade.
Existem trs verses principais do protocolo. O SNMPv1 definido pela RFC 1157 de 1990.
Usa SMIv1, apresenta as operaes Get, GetNext, Set e Trap. O controle de acesso baseado
no conceito de comunidade e no seguro.
O SNMPv2 definido pelas RFCs 3416, 3417 e 3418 e introduziu trs modificaes importantes:
11 Nos tipos de dados e nos objetos gerenciados;
11 No modelo de segurana, que acabou por mostrar-se invivel;
11 Nas operaes disponibilizadas pelo protocolo.
O SNMPv3 definido nas RFCs 3410, 3418 e 2576. A grande alterao trazida por esse protocolo o modelo de segurana, que permite uma implementao muito mais robusta do que
o esquema baseado em comunidades.
Figura 3.6
Encapsulamento do
protocolo SNMP.
73
SMIv1 Tipos de dados

11 Integer.
11 Octet String.
11 Counter.
11 Object Identifier.
11 NULL.
11 Sequence.
11 Sequence of.
11 IpAddress.
11 NetworkAddress.
11 Gauge.
11 TimeTicks.
11 Opaque.
O padro SMIv1 define doze tipos de dados, utilizados para a definio de objetos:
11 Integer: nmero inteiro de 32 bits, normalmente utilizado para representar estados de
um equipamento. Independente da arquitetura do equipamento utilizado (32 ou 64 bits),
esse tipo de dados sempre 32 bits;
11 OctetString: define uma string de um ou mais octetos (bytes). Tambm utilizado para
representar endereos Media Access Control (MAC);
11 Counter: nmero inteiro de 32 bits, variando entre 0 e 232: 1. Ao atingir o valor mximo,
as variveis desse tipo voltam a armazenar o valor inicial (zero), uma vez que esse tipo de
dados pode ser apenas incrementado e de forma unitria;
11 ObjectIdentifier: string composta por nmeros decimais separados por pontos. Sua
finalidade representar os OID da rvore de identificao da ISSO;
11 NULL: valor nulo;
11 SEQUENCE: define uma lista que contm zero ou mais tipos;
11 SEQUENCE OF: define um objeto que formado por uma sequncia de um determinado
tipo. A diferena entre o tipo SEQUENCE e SEQUENCE OF que o primeiro composto
por um nmero determinado de tipos variados, j o segundo composto por uma lista
varivel de um determinado tipo. Por exemplo, uma linha de uma tabela um SEQUENCE;
uma tabela um SEQUENCE OF de uma linha;
11 IpAddress: representa um endereo IPv4. importante observar que as verses SMIv1 e
74
SMIv2 no permitem representar nativamente endereos IPv6 de 128 bits;

11 NetworkAddress: representa endereos de redes baseadas em IPv4;
11 Gauge: similar ao tipo Counter, esse tipo de dados constitui um contador do tipo inteiro,
variando entre 0 e 232: 1. No entanto, dados do tipo Gauge podem ser incrementados e
decrementados, diferentemente do tipo Counter;
11 TimeTicks: nmero inteiro de 32 bits utilizado para representar o tempo. Sua representao feita em milsimos de segundos;
11 Opaque: utilizado para permitir que qualquer tipo de dados seja armazenado em forma
de um Octet String.
SMIv1 Definio de objetos

O texto a seguir corresponde definio do objeto sysUpTime.
SYNTAX Time-Ticks
ACCESS read-only
STATUS mandatory
DESCRIPTION
The time (in hundredths of a second)since the network
management portion of the system was last re-initialized.

::= { system 3 }
Os objetos e seus atributos so definidos para representar informaes diretamente
relacionadas como equipamento. Sua definio se d atravs da macro ASN.1 OBJECT-TYPE,
contendo as seguintes informaes:
11 SYNTAX: define o tipo de dados a ser utilizado;
11 ACCESS: d a definio do tipo de acesso permitido. Os valores possveis so read-only,
read-write, write-only e not-accessible. O valor de not-acessible pode no fazer sentido
primeira vista, mas pode ser usado, por exemplo, para evitar que se solicite uma tabela
inteira em uma operao de busca (Get). Isso acontece porque a declarao de uma
tabela, na verdade, a declarao de uma sequncia de linhas. Essa sequncia tem um
OID como qualquer outro item de dado ASN.1. No entanto, o protocolo no permite que
a tabela inteira seja lida em uma nica operao. Assim, declara-se essa sequncia como
not-acessible para evitar pedidos diretos a ela, sem evitar que os objetos que a compes
sejam buscados.
11 STATUS: define o status do objeto, assumindo os valores mandatory, optional e obsolete;
11 DESCRIPTION: descrio livre sobre o tipo de informao a ser armazenada.
Finalmente, ao fim das definies, deve-se indicar a qual n pai o novo objeto ser subordinado e qual o seu OID. No exemplo apresentado, o objeto sysUptime encontra-se na sub-rvore system com o OID 3.
SNMPv1 Comunicao e Operaes

mente, o protocolo UDP. Como possvel perceber na figura 3.7, o protocolo SNMP, independente da verso, utiliza a arquitetura cliente-servidor (pedidos-respostas) nas etapas de
solicitao de informaes.
Interessante observar que o gerente tem o papel de cliente e o agente tem o papel
de servidor, j que o gerente faz solicitaes para o cliente. A exceo so os Traps.
O protocolo SNMPv1 no necessita de um servio de transporte confivel, utilizando, geral-
75
SNMP Management Station
SNMP Agent
Managed Resources
Application managed objects
SNMP Messages
SNMP Manager
Trap
GetResponse
SetRequest
GetNextRequest
SNMP Managed Objetcs
GetRequest
Trap
GetResponse
SetRequest
GetNextRequest
GetRequest
Management Application
SNMP Agent
UDP
UDP
IP
IP
Network dependente protocols
Network dependente protocols

network or internet
O SNMPv1 possui quatro operaes e cinco mensagens. As quatro operaes so:

11 get: utilizada para recuperar um objeto especfico;
11 get-next: usada para recuperar o prximo objeto, a fim de percorrer a MIB de um agente;
11 set: utilizada para modificar ou criar um objeto;
11 trap: usada para que o agente notifique o gerente sobre a ocorrncia de um evento.
Essas quatro operaes so executadas a partir das cinco mensagens disponveis no
protocolo SNMPv1:
11 GetRequest: mensagem enviada pelo gerente ao agente, solicitando um objeto especfico;
11 GetNextRequest: mensagem enviada pelo gerente ao agente solicitando o objeto
imediatamente posterior ao referenciado no pedido;
11 SetRequest: mensagem enviada pelo gerente ao agente, solicitando a modificao do
valor de uma varivel ou a criao de uma linha em uma tabela;
11 GetResponse: mensagem do agente ao gerente, relativa a qualquer uma das trs
mensagens citadas anteriormente nessa lista;
11 Trap: mensagem assncrona enviada pelos agentes ao gerente (no apresenta resposta).
76
A figura 3.8 apresenta as mensagens trocadas entre agentes e gerentes.
Figura 3.7
Arquitetura
cliente-servidor do
protocolo SNMP.
GetRequest
GetResponse
SetRequest
Porta 161
GetResponse
GetNextRequest
MIB
GetResponse
Trap
Porta 162
GERENTE
Figura 3.8
Mensagens do
protocolo SNMP.
AGENTE
SNMPv1 Formato da mensagem do protocolo SNMP

A mensagem do protocolo SNMPv1 composta pelos seguintes campos:
11 Verso: verso do protocolo (0 para a verso 1);
11 Comunidade: espcie de senha usada para recuperar ou alterar objetos da MIB;
11 PDU: especificao do tipo de mensagem.
A figura 3.9 apresenta de forma esquemtica o formato da mensagem.
Comunidade
PDU (Protocol Data Unit)
Nmero inteiro
indicando a
verso SNMP
(0 para SNMPv1)
Este campo carrega

o nome de comunidade que
o originador da mensagem
est usando
Dados efetivos de gerncia

a serem analisados e processados
O protocolo SNMPv1 suporta um esquema muito simples de autenticao. Uma comunidade um nome que especifica o nvel de acesso s facilidades oferecidas pelos agentes.
A ideia prevenir que gerentes desautorizados acessem a MIB de um determinado agente,
restringindo, assim, a informao vista por determinado gerente. Esse fraco esquema de
autenticao inibe o uso da operao de Set pela inerente falta de segurana.
SNMPv1 Relao MIB view e Comunidade

Uma MIB view um subconjunto de objetos de uma MIB de um determinado dispositivo, relacionados por grau de acesso. Assim, o controle de acesso SNMP define que uma determinada
comunidade est restrita s variveis de uma determinada MIB view. A figura 3.10 mostra
que uma MIB view corresponde a um subconjunto de objetos gerenciados de um agente.
Figura 3.9
Esquema de
uma mensagem
MIB
SNMPv1.
Verso
77
Entidade gerenciada
MIB
MIB view
(somente leitura)
Figura 3.10
MIB view.
SNMPv1: Formato da PDU de resposta
Valores de status do erro:

11 0: noError (no houve erro).
11 1: tooBig (a resposta muito grande para a implementao).
11 2: noSuchName (uma das variveis no consta na MIB do agente requisitado).
11 3: badValue (erro no pedido de Set).
11 4: readOnly (uma mensagem Set tenta alterar uma varivel read-only).
11 5: genError (erro desconhecido).
Os campos de um PDU SNMPv1 de resposta (GetResponse), conforme a figura 3.11, so:
11 Tipo de PDU: especifica a operao SNMPv1 entre as cinco apresentadas:
22 GetRequest-PDU = 0
22 GetNextRequest-PDU = 1
22 GetResponse-PDU =2
22 SetRequest-PDU = 3
22 Trap-PDU = 4
11 Request ID: nmero sequencial para associar pedidos com respostas;
11 Error Status: indicao se foi possvel realizar a operao solicitada e eventual cdigo de erro;
11 Error Index: em caso de erro, identifica o objeto no qual houve o problema;
11 Lista de objetos retornados: identifica objetos e valores.
78
Tipo PDU
ID
Status
do erro
ndice
do erro
Objeto 1
Valor 1
Objeto 2
Valor 2
Objeto x
Valor x
Objetos Vinculados
Em uma mensagem do tipo GetResponse, o campo error status indica o que ocorreu e o
campo error index aponta para o primeiro objeto que apresentou falha. Os seguintes cdigos
de falhar so usados:
11 noError (0): no houve falha;
11 tooBig (1): o agente no conseguiu enviar a resposta por ocupar muito espao;
Figura 3.11
Formato da PDU de
um GetResponse.
11 noSuchName (2): o objeto no existe para a comunidade especificada;

11 badValeu (3): houve uma tentativa de alterar um objeto para um valor inconsistente;
11 readOnly (4): houve uma tentativa de alterar um objeto que para a comunidade especificada no pode ser sobrescrito;
11 genErr (5): qualquer outro erro.
SNMPv1: Formato do PDU para a trap
Campo Tipo genrico da trap:

11 0 coldStart: reinicializao do dispositivo; configurao do agente no alterada.
11 1 warmStart: reinicializao do dispositivo com possvel alterao da configurao
do agente.
11 2 linkDown: falha em um dos links do agente.
11 3 linkUp: volta de um link do agente.
11 4 authenticationFailure: falha na autenticao de uma mensagem recebida.
11 5 egpNeighborLoss: perda da comunicao com um vizinho EGP.
11 6 enterpriseSpecific: traps especficas.
A mensagem do tipo Trap reporta ao gerente eventos, problemas e condies anormais.
No entanto, com o aumento da concentrao de equipamentos presentes nas interligaes

de redes, no raro que vrios Traps estejam reportando o mesmo evento. Dessa forma,
necessrio que se realize a correlao de alarmes, a fim de agrupar tais Traps.
Da mesma forma, em redes com muitos dispositivos, fica invivel realizar pollings peridicos. Assim, devem-se adotar estratgias de monitoramento, onde os pollings so realizados com menor frequncia, priorizando os casos em que traps foram recebidas.
Como possvel observar na figura 3.12, os campos que compem as mensagens de Trap no
SNMPv1 so:
11 Tipo de PDU: especifica a operao SNMPv1 entre as cinco apresentadas (0x04);
11 Enterprise: ObjID que indica o tipo de dispositivo que enviou a mensagem;
11 Endereo do agente: endereo IP do objeto que gerou a mensagem;
11 Tipo genrico de Trap: identifica o evento que gerou a mensagem;
11 Cdigo especfico da trap: identifica o evento que gerou a mensagem se no corresponder
a um evento genrico, e sim a algo especfico criado pelo fabricante do equipamento;
cializao (sysUpTime);
11 Lista de pares objeto-valor: objetos reportados pela trap.
Figura 3.12
PDU de uma
mensagem
do tipo Trap.
Tipo
Tipo
Endereo
Cdigo
Enterprise
Genrico
de PDU
do Agente
da trap
da trap
Time
Stamp
Objeto 1
Valor 1
Objeto 2
Valor 2
Objeto x
Valor x
Objetos Vinculados
Os seguintes tipos genricos de Traps esto definidos para o padro:
11 coldStart (0): dispositivo reiniciou;
11 Timestamp: tempo passado entre o momento em que foi gerada a trap e a ltima reini-
11 warmStart (1): agente reiniciou;

79
11 linkDown (2): interface de rede mudou de ativa para desligada;

11 linkUp (3): interface de rede mudou de desligada para ativa;
11 authenticationFailure (4): foi recebida mensagem SNMP com erro de autenticao;
11 egpNeighborLoss (5): houve perda de vizinhana no protocolo EGP;
11 nenhum (6): h um evento especfico do fabricante, que deve ser consultado no campo
posterior.
SNMPv1: Declarao de uma trap especfica (macro ASN.1

TRAP-TYPE)
frDLCIStatusChange TRAP-TYPE
ENTERPRISE frame-relay
VARIABLES {frCircuitIndex, frCircuitDlci, frCircuitState}
DESCRIPTION
This trap indicates that the indicated Virtual Circuit has changed
state. It has either been created or invalidated, or has toggled
between the active and inactive states.
::=1
Traps especficas so definidas pelo valor do enterprise ObjID e o nmero specific trap.
Existe uma macro (TRAP-TYPE) para definio de traps.
SNMPv1: Obteno de valores de uma MIB

Objetos com valor nico (instncia):
11 1.3.6.1.2.1.1.1.0
Objetos com valores mltiplos (mltiplas instncias)
11 1.3.6.1.2.12.2.1.2.1
11 1.3.6.1.2.12.2.1.2.2
11 1.3.6.1.2.12.2.1.2.3
Para fins de recuperao do valor de um objeto gerenciado, pode-se considerar que existem
dois tipos de objetos: aqueles que apresentam uma nica instncia e aqueles que apresentam mltiplas instncias. O primeiro corresponde aos objetos escalares, como sysDescr.
O segundo tipo corresponde a objetos posicionados dentro de tabelas, como ifSpeed, que
apresentar valor para cada interface de rede do equipamento. Essa distino importante
80
porque um objeto gerenciado, no contexto do protocolo SNMP, identificado OID acrescido

de um identificador de instncia. Dependendo do tipo de objeto, o sufixo acrescentado ao
OID para identificao da instncia ser diferente.
Toda instncia de objeto escalar ser identificada pelo OID seguido do algarismo 0 (zero).
Assim, para recuperar uma instncia de sysDescr, o gerente dever enviar ao agente a
seguinte mensagem:
11 GetRequest 1.3.6.1.2.1.1.1.0 ou seja, est solicitando o valor do objeto gerenciado
iso.org.dod.internet.mgmt.mib-2.system.sysDescr.0.
Toda instncia de um objeto de uma tabela ser identificado pelo OID, seguido pelo valor do
campo de ndice. Quando um OID um valor escalar, o ndice tem valor zero. Quando o objeto
gerencivel integrante de uma tabela, o valor do ndice est relacionado com a posio dele
na tabela. Por exemplo, pela definio a seguir, percebe-se que a tabela ifTable formada por
uma sequncia de objetos do tipo ifEntry. O objeto ifEntry, por sua vez, corresponde uma linha
da tabela e define que o ndice utilizado para identificar cada linha o objeto ifIndex.
ifTable OBJECT-TYPE
SYNTAX
SEQUENCE OF IfEntry
ACCESS
not-accessible
STATUS
mandatory
DESCRIPTION
A list of interface entries.
The number of
entries is given by the value of ifNumber.

::= { interfaces 2 }
ifEntry OBJECT-TYPE
SYNTAX
IfEntry
ACCESS
not-accessible
STATUS
mandatory
DESCRIPTION
An interface entry containing objects at the
subnetwork layer and below for a particular
interface.
INDEX
{ ifIndex }
::= { ifTable 1 }
Para identificar a velocidade da segunda interface do dispositivo, utiliza-se o OID seguido pelo
algarismo 2. Pode-se considerar que o gerente envia a seguinte mensagem para o agente:
11 GetRequest 1.3.6.1.2.1.2.2.1.5.2 ou seja deseja obter o valor do objeto gerencivel iso.org.
Nem sempre os identificadores de instncias so nmeros sequenciais (1, 2, 3). O padro

permite que seja usado qualquer valor, como por exemplo utilizar nmeros IP em uma tabela
de rotas. Na tabela ipAddressTable, por exemplo, o ndice corresponde ao endereo IP.
Tambm possvel recuperar objetos gerenciados com a operao GetNextRequest, que
busca o prximo objeto da MIB. Deve-se considerar que a MIB uma rvore percorrida da
esquerda para a direta. Assim, se a operao GetNext do OID iso.org.dod.internet.mgmt.
mib-2.system for executada, ser retornado o valor do objeto mib2.system.sysDescr.0. Ao
executar a operao GetNext...system.sysDescr.0, ser retornado o valor do objeto system.
sysObjectID.0. Portanto, utilizando-se a identificao do objeto retornado pela operao
anterior possvel percorrer toda a MIB.
dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifSpeed.2
81
Ressalte-se que uma tabela ser percorrida com sucessivos GetNext, coluna por coluna.
A operao GetNext...interfaces.ifTable.ifEntry.ifSpeed.1 retornar a velocidade da prxima
interfade (...interface.ifTable.ifEntry.ifSpeed.2) e no o endereo fsico da interface (...interface.ifTable.ifEntry.ifPhysAddress.1).
Tanto a operao Get quanto GetNext podem solicitar mais de um objeto gerenciado.
No entanto, se houver problema em algum deles, nenhum ser retornado.
SNMPv1: Modificao de valores em tabelas

11 Tabelas so conjuntos de objetos com valores mltiplos.
11 Uso do objeto do tipo EntryStatus.

A modificao do valor de um objeto escalar trivial. O protocolo possui a operao
SetRequest e pode-se imaginar que basta enviar, nessa operao, a identificao do objeto
que se quer alterar e o valor correspondente. A modificao de um objeto de uma tabela
segue o mesmo esquema. A diferena est na identificao da instncia.
No entanto, duas outras operaes podem ser feitas em uma tabela: criao e excluso
de uma linha. Para manipular as linhas das tabelas com o protocolo SNMP, independente
da verso, usado um objeto de status, cujo tipo EntryStatus. Esse objeto possui dois
valores possveis: valid ou invalid.
Ao se criar uma linha, uma operao de SetRequest conter valores para os objetos que
compem a tabela. Caso no se tenha todos os valores necessrios, possvel que valores
default sejam usados para inicializar os demais. A linha criada realmente quando o valor
do objeto de status for alterado para valid.
Para excluir uma linha, altera-se o valor do objeto de status para invalid.
SNMPv2 Uma nova verso

11 1992: o IETF anunciou a chamada por propostas para uma nova verso.
11 1992: A primeira resposta veio nas RFCs de 1351 a 1353 e foi chamada de SNMP
seguro (incompatvel com a verso 1).
11 1993: A verso 2 foi oficialmente apresentada e hoje chamada de SNMPv2 clssica
ou SNMPv2p (baseada em parties).
11 1996: A verso SNMPv2 definitiva chamada de SNMPv2c (baseada em comunidades).
A partir das limitaes do protocolo SNMPv1, uma segunda verso foi desenvolvida. Dentre
as limitaes destacam-se:
11 No adequado para coletar grandes volumes de dados, porque precisa indicar a identificao de cada objeto gerencial a ser solicitado ao agente, gerando bastante trfego
de overhead, que pode crescer muito no caso de redes grande porte prejudicando a
performance da rede;
11 Possui autenticao baseada unicamente em nomes de comunidades, que podem ser
facilmente obtidos a partir de uma inspeo de trfego usando um sniffer, pois as mensagens do protocolo SNMPv1 no so criptografadas. Essa facilidade de obter indevidamente o nome da comunidade e ento poder usar essa informao para alterar de forma
no autorizada valores de configurao dos agentes SNMP inviabiliza a sua adoo para
controle (Set). Assim, o SNMP atualmente mais utilizado para fins de obteno de dados
dos agentes (monitoramento);
82
11 No permite comunicao entre gerentes;

11 Funcionalidade limitada em relao ao CMIP/CMIS (protocolo/servio de gerenciamento
da arquitetura OSI);
11 A caracterstica atmica das mensagens, ou seja, o fato de uma mensagem obter total sucesso
ou total fracasso nas operaes (no h a possibilidade de sucesso parcial em um GetRequest
que tenha, por exemplo, solicitado um conjunto de valores de objetos gerenciveis);
11 Impossibilidade de configurao remota dos agentes.
SNMPv2 Evoluo
SNMPv2p Party-based SNMPv2.
11 No obteve sucesso.
11 Contexto de operao baseado em parties.
11 Dificuldade para descoberta automtica.
SNMPv2c Community-based SNMPv2.
11 Contexto de operao baseado em comunidades.
11 Manteve algumas caractersticas do SNMPv2p.
22 Facilidade para declarao de objetos.
22 Melhor desempenho na troca de mensagens.
22 Melhor tratamento de erros.
A abrangente proposta SNMPv2 clssica (SNMPv2p) baseada em parties apresentou
um modelo de comunicao entre gerente e agente que utilizava uma autenticao para
limitar o acesso a um conjunto apenas de objetos gerenciados. Em 1995 foi feita mais uma
reviso do protocolo em resposta baixa aceitao da verso SNMPv2p. Tal reviso se deu
principalmente no que diz respeito ao contexto baseado em parties, configurao dos
agentes (para permitir a autenticao), dificuldade de descoberta automtica da rede e de
implementao do modelo administrativo e de segurana. O nico consenso ento obtido
foi aceitar as novidades no protocolo, porm permanecendo o contexto de operao sob a
antiga forma de nomes de comunidades como elemento de autenticao (fraca).
Posteriormente, foi apresentada mais uma verso de SNMP, agora chamada de SNMPv2c
(baseada em comunidades). Nesta, o modelo administrativo apresentado na verso clssica e baseado em parties foi completamente descartado.
Apesar do fracasso, pode-se considerar que h aspectos positivos apresentados na verso
objetos) e a melhoria da performance do protocolo na troca de informaes com um melhor
tratamento de erros. Uma til experincia prtica foi obtida nas implementaes e testes
com SNMPv2p.
Em resumo, SNMPv2c assimilou somente as novas mensagens, correes e SMIv2, esperando ainda melhorias em:
11 Segurana (o grande problema);
11 Configurao remota;
11 Infraestrutura administrativa.
SNMPv2p, como a criao de extenses da linguagem (que facilitam a declarao de novos
83
SMIv2 Novos tipos de dados

Tipo
Descrio
INTERGER
Inteiros no intervalo de -2 31 a 2 31 -1
UInterger32
Inteiros no intervalo de 0 a 2 32 -1
Counter32
Inteiro no-negativo a ser adicionado ao mdulo 2 32
Counter64
Inteiro no-negativo a ser adicionado ao mdulo 264
Gauge32
Inteiro no-negativo a ser adicionado ou diminudo, mas que no

deve exceder o valos mximo. O valor mximo no pode ser maior
que 2 32 -1
Time Ticks
Inteiro no-negativo que representa a hora (mdulo de 2 32) em

centenas de segundos
Octet String
String de textos binrios; pode ser limitada a 255 octetos
OIPAddress
Endereo IP de 32 bits
Opaque
Campo arbitrrio de bits
Bit String
Lista de nomes dos bits
Object Identifier
Nome do objeto ou outro elemento padronizado. O valor uma

sequncia de at 128 nmeros inteiros no-negativos.
Tabela 3.2
Novos tipos de
dados.
A SMIv2, definida pelas RFCs 2578 e 2579, um superconjunto da SMIv1. Alguns novos tipos
foram criados e houve uma melhora na definio dos tipos antigos. importante observar
que a SMIv2 uma evoluo totalmente compatvel com a SMIv1, com exceo do novo tipo
de dado Counter64 (contador com 64 bits).
SMIv2: Textual conventions (RFC 2579)

11 DisplayString: OCTET STRING (SIZE (0...255))
11 PhysAddress OCTET STRING
11 MacAddress: OCTET STRING (SIZE (6))
11 TruthValue INTEGER { true(1), false(2) }
11 TestAndIncr: INTEGER (0...2147483647)
11 VariablePointer OBJECT IDENTIFIER
11 RowPointer: OBJECT IDENTIFIER
84
11 RowStatus INTEGER { active(1), notInService(2), notReady(3), createAndGo(4), createAndWait(5), destroy(6) }

11 TimeStamp TimeTicks
11 DateAndTime: OCTET STRING (SIZE 8|11)
Melhorias na manipulao de tabelas

Valores de RowStatus:
11 1 active: linha operacional.

11 2 notInService: linha desabilitada.
11 3 notReady: linha ainda no completa.
11 4 createAndGo: criar a linha e disponibiliz-la.
11 5 createAndWait: criar a linha, mas esperar por outros valores.
11 6 destroy: deletar todos os objetos da linha.
E exemplo de conveno de texto muito til a que permite uma melhor manipulao de
tabelas. A nova conveno de texto RowStatus substituiu a antiga coluna EntryStatus.
O tratamento das operaes com linhas de tabelas ficou mais claro. Por exemplo, s vezes
no possvel preencher uma linha da tabela em um nico set, e por isso deve-se mandar
esperar pelo resto dos dados (CreateAndWait).
SMIv2 Definio de objetos

A definio de objetos gerenciados a partir da SMIv2 sofreu algumas modificaes. A clusula MAX-ACCESS substituiu a anteriormente utilizada (ACCESS da SMIv1). Assim, possvel
definir o nvel mximo de acesso, atravs dos valores:
11 not-acessible;
11 acessible-for-notify;
11 read-only;
11 read-write;
11 read-create.
Tambm foram incorporados novos valores para a clusula STATUS:
11 current;
11 obsolet;
11 deprecated.
SNMPv2: Alteraes no protocolo

11 Novas opes de pilhas de transporte.
getNextRequest.
11 Operao setRequest mais segura (Execuo em duas fases).
11 response o novo nome da operao getResponse.
11 Novas mensagens SNMP:
22 getBulkRequest
22 informRequest
22 Report (No implementado em SNMPv2)
22 Notification
11 Remoo de perda de resposta em transaes atmicas do tipo getRequest/
85
Algumas alteraes foram realizadas no SNMPv2, destacando-se:

11 O protocolo de transporte utilizado na primeira verso do protocolo SNMP o UDP. A RFC
1906, depois substituda pela 3417, definiu novos protocolos de transporte para serem
utilizados: SNMP over OSI, SNMP over DDP (Appletalk) ou SNMP over IPX (Novel). Mais
tarde foram definidas outras formas de transporte para o SNMP (RFC 4490 refere SNMP
sobre UDP, TCP, SSH e TLS);
11 As operaes GetRequest e GetNextRequest no SNMPv1 podem solicitar mais de um
objeto gerenciado de cada vez. No entanto, se um identificador apresentar problemas,
ser gerada uma resposta de erro. Ou todos os objetos so retornados, ou nenhum
deles. No SNMPv2, isso no ocorre. Se houver um erro do tipo noSuchObject, noSuchInstance e endOfMibView para um objeto gerenciado pedido, os outros sero retornados;
11 Foi criado um novo tipo de Trap, conhecido pelo nome Inform,
que apresenta a
caracterstica de ser respondido pelo gerente. A inteno diminuir a possibilidade de

perda da notificao;
11 A fim de permitir a rpida recuperao de uma poro de uma tabela, foi criada a operao GetBulkRequest. Como parmetro dessa operao, so passados objetos gerenciados, um contador que indica quantos objetos so escalares e, portanto, no devem
ser pesquisados como uma tabela, e outro contador que indica quantas instncias dos
outros objetos devem ser buscadas no mximo;
11 A operao setRequest passou a ser executada em duas fases. Na primeira, as variveis
so testadas, e somente na segunda so alteradas, com vistas a manter a atomicidade
das alteraes solicitadas (tudo ou nada).
SNMPv2 Operaes
Com a no aceitao do modelo de segurana proposto em SNMPv2p, a mensagem
SNMPv2c possui os mesmos delimitadores e cabealhos da verso SNMPv1, com exceo
do campo verso, que agora tem valor 1 indicando a verso 2, alm da manuteno do
mesmo esquema de comunidades da verso 1.
A figura 3.13 mostra o mesmo cabealho e as diferenas nas operaes: comunicao
entre gerentes, a adio da mensagem InformRequest, a mudana de nome da mensagem
GetResponse para Response e a adio da mensagem GetBulkRequest.
86
GetRequest
Response
InformRequest
Porta 161
Response
SetRequest
Response
Porta 161
GetBulkRequest
MIB
Response
Porta 162
GERENTE
Figura 3.13
Mensagens do
protocolo SNMPv2.
GERENTE
Comunidade
AGENTE
PDU (Protocol Data Unit)
Os valores do campo tipo de PDU no protocolo SNMP v2 so:
GetRequest-PDU = [0]
GetNextRequest-PDU = [1]
Response-PDU = [2]
SetRequest-PDU = [3]
-- [4]
que era o antigo Trap foi obsoletado
GetBulkRequest-PDU = [5]
InformRequest-PDU = [6]
SNMPv2-Trap-PDU = [7]
Report -PDU = [8]
SNMPv2 Operao InformRequest e o gerenciamento

hierarquizado
Como descrito anteriormente, h uma nova mensagem semelhante ao Trap no SNMPv2. O
InformRequest um Trap com confirmao. Essa mensagem muito interessante para a
criao de uma hierarquia de gerentes, conforme a figura 3.14.
Um gerente envia um InformRequest a outro em resposta a eventos complexos, como a
ultrapassagem de um limite mximo de erros ou muitas falhas em operaes. Essa nova
possibilidade permite a hierarquizao da estrutura gerencial do SNMPv2.
Verso
Trap / Notication
87
Manager Server
Management Applications
SNMPv2 manager
MIB
Element Manager
SNMPv2
SNMPv2
manager/agente
manager/agente
MIB
MIB
Agent
SNMPv2 agent
SNMPv2 agent
SNMPv2 agent
MIB
MIB
MIB
SNMPv2 Operao getBulkRequest

No SNMPv1, quando eram desejadas grandes quantidades de dados de uma MIB, a limitao
do tamanho das respostas era funo da implementao no agente distante. Se era pedido
um volume muito grande de informaes para um nico Get, a resposta era vazia com o
campo error status com valor tooBig. Se era pedido um volume muito pequeno de informaes para um nico Get, a coleta de dados no era eficiente.
A nova operao GetBulkRequest otimiza a recuperao de um volume considervel de variveis, pedindo eficientemente o mximo de dados que um agente pode enviar por meio de
uma mensagem response. O pedido realizado em uma mensagem GetBulkRequest pode
ser tanto de variveis individuais ou de linhas de uma tabela.
88
A mensagem GetBulkRequest pode ser constituda de vrios objetos gerenciveis, assim

como a mensagem Get ou GetNext. No entanto, em uma mensagem GetBulkRequest
possvel indicar o nmero de repeties que se deseja realizar. Esse nmero de repeties
corresponde a repetidas operaes getNext sem necessidade de novas mensagens.
A figura 3.15 apresenta um exemplo de GetBulkRequest. Os dois primeiros objetos so
escalares e lidos como uma instncia nica. Os outros objetos fazem parte de uma tabela e
apresentam vrias instncias. No exemplo, so buscadas seis instncias de cada objeto.
Figura 3.14
Hierarquia de
gerentes.
GetBulkRequest (non-repeaters = 2, max-repetitions = 6, X, Y, TA, TB, TC)

Agente
(i.e. roteador)
Estao de Gerncia
Tabela
TA
Gerencia os pedidos com
Response [X, Y, TA(1), TB(1), TC(1),
seis nomes de variveis:
TA(2), TB(2), TC(2),
para as duas primeiras
TA(3), TB(3), TC(3),
(non-repeaters = 2),
TA(4), TB(4), TC(4),
um nico valor pedido;
para as demais variveis,
TA(5), TB(5), TC(5),
seis valores sucessivos
TA(6), TB(6), TC(6)]
(max-repetitions = 6) so pedidos.
Figura 3.15
Exemplo de
consulta usando
GetBulkRequest.
TB
TC
Agente retorna um
valor nico para X e Y,
e seis para a tabela
j
SNMPv2 Mensagens
Como possvel observar na figura 3.16, na verso dois do protocolo SNMP houve uma
unificao de formatos de mensagens, evitando assim o overhead ao processar diferentes
PDU. Dessa forma, ao enviar uma mensagem do tipo Get, envia-se os campos de status e
ndice de erro com valor 0. J nas mensagens getbulkRequest, tais campos so utilizados
para informar os itens:
11 non-repeaters: especifica o nmero mximo de objetos escalares a ser enviado no response;
11 max-repetitions: define o nmero mximo de vezes que deve se seguir pelas variveis
de vrias instncias.
Tipo PDU
Request-ID
Variable-bindings
(a) GetRequest-PDU, GetNextRequest-PDU, SetRequest-PDU, SNMPv2-Trap-PDU,

InformRequest-PDU
Tipo PDU
Request-ID
Status Erro
ndice Erro
Variable-bindings
(b) Response-PDU
Tipo PDU
Variable-bindings
(c) GetBulkRequest-PDU
Nome 1
Valor 1
Nome 2
Valor 2
...
Nome n
Valor n
(d) Variable-bindings
SNMPv2: Tipos de agentes

Agentes extensveis.
11 Arquitetura aberta.
11 Design modular.
11 Permite adaptaes para novos requisitos.
Figura 3.16
Formato das
mensagens do
SNMPv2.
Request-ID Non-repeaters Max-repeaters
89
Agentes monolticos.
11 No so extensveis.
11 Otimizados para determinadas plataformas de hardware e SO.
11 Melhor desempenho.
Agentes SNMP basicamente podem ser construdos de duas formas:
11 Agentes extensveis: so desenvolvidos com arquitetura aberta, com design modular
permitindo adaptaes para novos requisitos de dados de gerenciamento e extenses
operacionais;
11 Agentes monolticos: no so extensveis. So construdos com otimizaes para determinadas plataformas de hardware ou SO, visando melhor desempenho.
Agentes proxy
Um agente proxy uma entidade que repassa uma mensagem para outro agente. Isso pode
ser necessrio para acessar um agente que no fala SNMP ou para acessar um agente que
no apresenta suporte de rede TCP/IP. A figura 3.17 apresenta uma agente proxy interconectando um gerente a um dispositivo gerenciado que no est na rede TCP/IP.
Agente proxy
Estao de gerncia
Funo de mapeamento
Processo de gerncia
Processo de gerncia
SNMP
SNMP
UDP
UDP
IP
IP
Protocolos de rede
Protocolos de rede
Dispositivo gerenciado
Processo de gerncia
Arquitetura do protocolo
utilizada pelo proxy
Arquitetura do protocolo
utilizada pelo proxy
Protocolos de rede
Protocolos de rede
Alm das duas situaes apresentadas, um agente proxy pode ser utilizado para aumentar a
Figura 3.17
Agente proxy.
segurana de um determinado ambiente de rede.
SNMPv3: Novo modelo de segurana

User-based security model.
90
11 autenticao.
11 Privacidade.
View-based access control.
11 tipos de usurios.
11 partes da MIB.
Entre outras modificaes, uma das mais significativas realizadas na verso 3 do protocolo
SNMP est a implementao de um modelo de segurana mais seguro. Cada mensagem
SNMPv3 apresenta parmetros de segurana. So usadas chaves para garantir a autenticao e a privacidade na comunicao entre gerentes e agentes.
w
Para mais informaes:
http://www.snmplink.
org/
A fim de determinar que parte da MIB pode ser vista por determinado usurio, utilizado o
conceito de MIB view. Esse controle feito atravs de vrias tabelas:
11 vacmContextTable;
11 vacmSecurityToGroupTable;
11 vacmAccessTable;
11 vacmViewTreeFamilyTable.
Para cada acesso, necessrio que o agente verifique se o usurio tem direito de faz-lo.
Para tal, o usurio mapeado para uma MIB view que consiste dos objetos que podem ser
acessados. Haver diferentes vises de acordo com os diferentes modelos de segurana (com
criptografia, com autenticao etc.) e de acordo com a operao que est sendo realizada.
Com a implementao do SNMPv3, possvel utilizar o protocolo para atuar sobre agentes,
j que ele apresenta esquema de segurana suficientemente robusto.
Arquitetura modular SNMPv3

A arquitetura SNMPv3 (figura 3.18) composta por mdulos que interagem provendo servios uns aos outros, atravs de primitivas.
Aplicaes
Command
Generator
Notication
Receiver
Proxy forwarder
Command
Responder
Notication
Originator
Outros
Processador SNMP (identicado pelo snmpEngineID)

Subsistema de
processamento
de mensagens
Subsistema
de segurana
Subsistema de
controle de acesso
Os conceitos principais da arquitetura SNMPv3 so:

11 Entidades SNMP: corresponde ao que se chamava de agente e gerente SNMP, composto
por duas partes: aplicaes e engine;
11 SNMP engines: o engine composto por quatro partes:
22 Dispatcher: responsvel por enviar e receber mensagens;
22 Subsistema de processamento de mensagem: responsvel por preparar a mensagem para enviar ou extrair os dados, conforme os protocolos disponveis;
22 Subsistema de segurana: responsvel pelo controle de autenticao e privacidade
(criptografia) das mensagens;
22 Subsistema de controle de acesso: responsvel por determinar se o acesso deve
ser liberado.
11 Aplicaes SNMPv3: existem cinco tipos de aplicaes internas:
22 Geradores de comando: geram comando para coletar dados ou alterar valores;
Figura 3.18
Arquitetura
SNMPv3.
Dispatcher
91
22 Respondedores de comando: proveem acesso aos dados;

22 Originadores de notificao: iniciam uma mensagem do tipo trap ou inform;
22 Recebedores de notificao: recebem as mensagens do tipo trap ou inform;
22 Encaminhadores de proxy: encaminham mensagem entre entidades SNMP.
Um gerente ou agente, agora entidades SNMP, executaro suas funes atravs da interao
dos elementos citados.
Segurana SNMPv3
RFC 3414 The User-Based Security Model for Version 3 of the Simple Network
Management Protocol (SNMPv3).

11 Descrio de ameaas, mecanismos de segurana, algoritmos de segurana e tipos
de dados.
RFC 3415 View-Based Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP).
11 Descrio do mecanismo de controle de acesso s informaes de gerenciamento.
A segurana do protocolo SNMPv3 baseada em dois documentos fundamentais:
11 RFC 3414 The User-Based Security Model for Version 3 of the Simple Network
Management Protocol (SNMPv3): descreve ameaas, mecanismos, algoritmos, servios
de segurana e tipos de dados usados com o objetivo de prover segurana ao protocolo;
11 RFC 3415 View-Based Access Control Model (VACM) for the Simple Network Management
Protocol (SNMP): descreve como definido o controle de acesso s informaes
de gerenciamento.
O modelo proposto de segurana baseado em usurio flexvel, de forma que no futuro
novos algoritmos podem ser usados sem alteraes no modelo. Seu nico protocolo de
privacidade proposto baseado no algoritmo DES.
Ao enviar uma mensagem, pode-se optar por uma das seguintes opes (campo msgFlags):
11 Sem autenticao, sem privacidade;
11 Com autenticao, sem privacidade;
11 Com autenticao, com privacidade.
Nesse modelo, autentica-se um usurio chamado de principal.
O modelo de segurana responsvel pelo processamento da segurana da mensagem e
pela implementao de mecanismos para sua garantia. Um nico modelo de segurana foi
proposto at o momento para SNMPv3: o modelo User-Based Security Model (USM), embora
92
nada impea a oferta de outros modelos de segurana no futuro. As ameaas consideradas

pelo modelo de segurana baseado em usurio concentram-se no trajeto da informao
pela rede, levando em considerao as caractersticas do trfego SNMP (fragmentado em
muitas mensagens).
O modelo de segurana baseado em usurio oferece os seguintes servios:
11 Autenticao: protocolos HMAC-MD5-96 e HMAC-SHA-96;
11 Privacidade: protocolo DES em modo CBC;
11 Proteo contra atrasos e reenvios de mensagens atravs de mecanismos de temporizao.
Tratada?
Mecanismo
Replay de mensagens
Sim
timestamp
Mascaramento
Sim
HMAC (MD5 ou SHA)
Integridade
Sim
HMAC (MD5 ou SHA)
Privacidade
Sim
DES
Negao de servio
No
Anlise de trfego
No
Formato da mensagem SNMPv3

O protocolo SNMPv3 apresenta um novo formato de mensagem, necessrio pela sua maior
complexidade. A figura 3.19 apresenta os campos descritos a seguir:
11 msgVersion: especifica a verso do protocolo em uso (3 SNMPv3);
11 msgID: identificador usado para dar coordenadas requests e responses;
11 msgMaxSize: informa o maior tamanho de mensagem suportado;
11 msgFlags: string de bits que identificam a existncia de report, autenticao e encriptao na mensagem;
11 msgSecurityModel: identifica o modelo de segurana em uso. Valores possveis at o
momento: SNMPv1, SNMPv2c e USM;
11 msgSecurityParameters: string com parmetros a serem processados pelo Security
Subsystem (depende do modelo de segurana);
11 contextEngineID: identifica uma engine que est sob determinado contexto. Define a
aplicao a qual o PDU est relacionado;
11 contextName: identificador do contexto usado pelo PDU. passado como parmetro
para o dispatcher e o View-based Access Control Model (VACM);
11 PDU: o PDU SNMPv2c.
Tabela 3.3
Tabela de ameaas.
Ameaa
93
msgVersion
msgID
msgMaxSize
Gerado e processado pelo

Message Processing Model
msgFlags
msgSecurityModel
msgAuthoritativeEngineID
Escopo autenticado
msgAuthoritativeEngineBoots
msgAuthoritativeEngineTime
msgUserName
Gerado e processado pelo

User Security Model (USM)
msgAuthenticationParameters
msgPrivacyParameters
Escopo criptografado
contextEngineID
contextName
PDU (texto claro ou criptografado)

PDU
SNMP Agente: NET-SNMP

11 Agente SNMP: snmpd
Figura 3.19
Formato da
mensagem do
protocolo SNMPv3.
11 Arquivos de configurao:
22 /etc/snmp/snmp.conf
22 /etc/snmp/snmpd.conf
O pacote NET_SNMP (http://net-snmp.sourceforge.net/) o pacote SNMP padro no mundo
Linux, possuindo tambm verses para Windows. Ele composto de um agente, vrias aplicaes em linha de comando e uma biblioteca SNMP. Ele pode ser encontrado tambm nos repo Gerncia de Redes de Computadores
sitrios dos Sistemas Operacionais Linux, sendo necessrio instalar os pacotes snmp e snmpd.
94
Seu agente, o snmpd, pode ser configurado para qualquer verso SNMP (1, 2 e 3) sobre
IPv4 ou IPv6. Alm disso, o agente suporta vrias MIBs, sendo extensvel (SMUX e AgentX).
Os arquivos de configurao do pacote esto no diretrio /etc/snmp/. Para o agente, os
arquivos relevantes so:
11 snmp.conf: configuraes padro para as aplicaes;
11 snmpd.conf: configuraes especficas para o agente;
11 O arquivo snmpd.conf possui inmeras opes. Para mais informaes, veja a man page
relacionada atravs do comando man snmpd.conf.
NET-SNMP Aplicaes
Snmpget
snmpgetnext
snmpwalk snmptable
snmpdelta
snmpdf
snmpnetstat
snmpstatus
snmpset
snmptranslate
tkmib
snmptrap
snmptrapd
Entre as aplicaes disponveis no pacote, as mais utilizadas so:
11 snmpget, snmpgetnext: obtm informao de dispositivos SNMP com requests;
11 snmpwalk: obtm toda a MIB implementada no agente atravs de mltiplos requests;
11 snmptable: obtm uma tabela SNMP completa;
11 snmpdelta: monitora as alteraes nas variveis de uma MIB;
11 snmpdf: obtm informaes de espao em disco na mquina remota;
11 snmpnetstat: obtm informaes de rede (status e configurao);
11 snmpstatus: obtm informaes de estado do dispositivo remoto;
11 snmpset: altera a configurao de dispositivos SNMP;
11 snmptranslate: mostra o contedo de MIBs em formato numrico ou textual;
11 tkmib: um MIB browser grfico desenvolvido em Tk/Perl;
11 snmptrap: envia traps SNMP;
11 snmptrapd: recebe notificaes SNMP e d destino a elas (log repassa para outro
gerente SNMP ou para outra aplicao). Possui um arquivo de configurao prprio: /etc/
NET-SNMP Configurao
11 Utilitrio para configurao: snmpconf
11 Utilitrio para testes: snmptest

Os arquivos de configurao do pacote esto no diretrio /etc/snmp/.
Cada um deles possui sintaxes com vrias opes. O comando snmpconf auxilia na configurao desses arquivos. Esse comando, inclusive, pode comentar um arquivo de configurao
existente, visando torn-lo mais legvel.
O comando snmptest inicia um dilogo interativo com um agente SNMP. Atravs desse
possvel enviar vrios comandos SNMP e obter respostas.
snmp/snmptrapd.conf.
95
Para que o agente instalado funcione e possa ser testado necessrio:

11 Instalar o pacote snmp-mibs-downloader, que baixa todas as MIBs padro. Sem isso, o
acesso atravs de nomes da rvore de OIDs fica prejudicado;
11 Comentar a linha mibs: , presente no arquivo /etc/snmp/snmp.conf;
11 Atualizar as MIBs com o comando download-mibs;
11 Ajustar no arquivo snmpd.conf para que computadores podem realizar consultas (agentAddress udp:161,udp6:[::1]:161);
11 Permitir que a comunidade pblica leia os objetos a partir de qualquer equipamento
(rocommunity esr-rnp default).
Suporte a SNMPv3 no pacote NET-SNMP

Duas configuraes impactam a troca de mensagens:
11 Configuraes de usurios USM.

11 Configuraes de controle de acesso VACM.
Comandos relacionados:
11 snmpconf
11 snmpusm
11 snmpvacm
Como foi visto nesta sesso de aprendizagem, o SNMPv3 apresenta vrias novidades, principalmente no que diz respeito segurana na troca de mensagens SNMP.
O agente NET-SNMP oferece suporte SNMPv3 atravs de sua configurao. O arquivo de
configurao do agente (/etc/snmpd.conf ) deve ser adequado para uso com SNMPv3.
Mais uma vez, o script snmpconf pode auxiliar nessa configurao; mas lembre-se de que
nem todas as opes possveis so configuradas por ele.
O comando snmpusm usado para a criao de usurios do modelo de segurana USM.
O comando snmpvacm usado para a criao de entradas no controle de acesso VACM.
Para mais informaes, use as man pages:
11 man snmpconf
11 man snmp_config
11 man snmpusm
11 man snmpvacm
96
Figura 3.20
Telas do NET-SNMP.
Criao de usurios SNMPv3

No arquivo /var/lib/snmp/snmpd.conf:
11 createUser [-e ENGINEID] username (MD5|SHA) authpassphrase [DES|AES]

[privpassphrase]
11 rouser USER [noauth|auth|priv [OID]]
Para se criar um usurio de nome initial, acrescenta-se a linha createUser initial MD5 password DES no arquivo no arquivo /var/lib/snmp/snmpd.conf.
Essa linha informar o agente das passwords (de autenticao e privacidade) que sero
usadas pelo usurio nesse agente. Na carga do agente, ele l essa linha, gera as chaves localizadas correspondentes e apaga a linha.
O motivo manter gravadas em disco somente as chaves localizadas, e no mais a password
original do usurio.
Uso das aplicaes com SNMPv3

Opes SNMPv3 para as aplicaes em linha de comando:
11 Na ltima coluna esto palavras-chave para o arquivo snmp.conf (para manter as
Parameter
Command Line Flag
snmp.conf token
securityName
-u NAME
defSecurityname NAME
authProtocol
-a (MD5 | SHA)
defAuthType (MD5|SHA)
privProtocol
-x (AES | DES)
defPrivType DES
authkey
-A PASSPHRASE
defAuthPassphrase PASSPHRASE
privKey
-X PASSPHRASE
defPrivPassphrase PASSPHRASE
securityLevel
-I (noAuthNo Priv|authNoPriv|authPriv)
defSecuritylevel (noAuthNo Priv|authNoPriv|authPriv)
context
-n CONTEXTNAME
defContext CONTEXTNAME
configuraes como default).
97
11 Cada usurio possui um nome (securityName), uma opo de autenticao (authProtocol),

uma opo de privacidade (provProtocol), alm das chaves criptogrficas correspondentes (authKey e privKey);
11 A autenticao feita assinando a mensagem com a chave do usurio em questo,
usando um dos protocolos possveis (HMAC-MD5 ou HMAC-SHA). As chaves so geradas a
partir de uma senha de, no mnimo, 8 caracteres;
11 A encriptao feita codificando a parte de dados da mensagem com um dos protocolos
possveis (AES ou DES);
11 O securityLevel de uma mensagem indica se ela ter autenticao e/ou privacidade;
11 Todas essas informaes so passadas para as aplicaes em linha de comando. Valores
default podem ser armazenados em arquivo snmp.conf.
Exemplo de getRequest SNMPv3 autenticado:
snmpgetnext
-v 3 (verso=SNMPv3)
-n (contexto)
-u MD5User (securityName)
-a MD5 (protocolo de autenticao)
-A Frase (passphrase de autenticao)
-l authNoPriv (securityLevel)
test.net-snmp.org (destino)
sysUpTime (objeto pedido)
Comando
snmpgetnext -v 3 -n -u MD5User -a MD5 -A Frase -l authNoPriv

test.net-snmp.org sysUpTime
Resposta
system.sysUpTime.0 = Timeticks: (83491735) 9 days, 15:55:17.35
98
4
Conhecer os monitores de redes, aprender as caractersticas da MIB RMON e RMON2
e suas extenses SMON. Aprender as caractersticas do monitor de trfego ntop.
Entender o gerenciamento de hosts e sistemas.
RMON 2, SMON, Monitor ntop, Gerenciamento de hosts e sistemas.
conceitos
Monitores, RMON Objetivos e Configurao, Grupos da MIB RMON, Eventos e alarmes,
Monitores
Monitores so equipamentos e/ou softwares usados para observar e controlar uma determinada LAN ou conjunto de dispositivos. So tambm chamados de probes e possuem
algum tipo de inteligncia, alm de armazenar dados coletados.
Monitores so teis na medida em que conhecem o comportamento normal da rede e
alertam um gerente, com uma mensagem de trap, sobre a ocorrncia de uma anormalidade.
Para tal, precisam conhecer limites de erros e perfis de trfego.
Uma caracterstica importante de um monitor a sua independncia em relao ao gerente.
Mesmo que ocorra uma falha no gerente, os monitores continuam a coletar dados e a
armazen-los. Podem ter mltiplas interfaces de rede, permitindo o monitoramento de
vrias redes locais distintas ou do trfego entre elas.
Monitores sabem o que ocorre na rede e possuem inteligncia para reagir a certas situaes, sendo extremamente teis. A figura 4.1 mostra o desenho de uma rede com um
monitor, chamado Probe RMON, e um gerente.
Captulo 4 - Monitoramento remoto RMON, RMON2, SMON e Host MIB
objetivos
Monitoramento remoto RMON,

RMON2, SMON e Host MIB
99
Estao de Gerncia RMON
Figura 4.1
Rede local com
um monitor
(Probe RMON).
Probe RMON
A figura 4.2 apresenta uma rede mais complexa em que a funo de monitoramento est
espalhada por diversos dispositivos. possvel visualizar dois computadores pessoais e um
roteador funcionando como monitores.
Site central
Estao de
Gerncia
RMON
Ethernet
Roteador
c/ RMON
Roteador
Backbone
Gigabit
Roteador
Switch
Ethernet
Backbone
FDDI
100
Ethernet
PC com
agente
RMON
Monitoramento com RMON.
PC com
agente
RMON
Figura 4.2
Rede com trs
monitores.
RMON Objetivos
1. Operao independente da estao gerenciadora;
2. Monitoramento proativo (depende de recursos e da rede);

3. Deteco de problemas monitoramento preemptivo;
4. Dados de valor adicionado (especializao);
5. Suporte a vrios gerentes.
RMON significa Remote Network Monitoring e corresponde a uma MIB definida nas
seguintes RFCs:
11 RFC 2819: RMON1;
11 RFC 4502: RMON2.
As MIBs I e II oferecem somente informaes de dispositivos individuais. RMON oferece
informaes que dizem respeito rede de forma distribuda, como contadores de pacotes e
erros em uma determinada LAN. O objetivo dessa MIB permitir o monitoramento da rede
e o posterior tratamento por um gerente.
Atravs dos objetos gerenciados o monitor RMON configurado, armazena informaes e
envia traps aos gerentes. A gerncia ocorre atravs do protocolo SNMP, permitindo que diferentes gerentes sejam utilizados. Os dados de configurao e monitorao so armazenados
em tabelas definidas na MIB RMON. A MIB tambm permite o compartilhamento do monitor
entre vrias estaes gerentes.
Os grupos de objetos RMON ficam abaixo do ramo da MIB-II.
Configurao do RMON
11 Diz respeito a como o monitor far a coleta dos dados.
11 Usa duas tabelas: tabela de controle (configurao das coletas) e tabela de dados
11 Dois tipos de dados da tabela de controle definem o acesso aos dados:
22 OwnerString: uma string que identifica o dono da entrada na tabela.
22 EntryStatus: um valor inteiro que indica o estado atual da entrada na tabela.
Valores possveis:
33 valid (1), createRequest (2), underCreation (3), invalid (4).
A configurao do RMON basicamente diz respeito ao que se deseja monitorar e aos
limites a serem testados. Para cada estatstica, existem parmetros definidos pelo gerente
(exemplo: intervalo de medio).
Normalmente, existem duas tabelas: uma de controle (control table) e uma de resultados
do monitoramento (data table). A partir do momento em que a tabela de controle configurada, a monitorao vai gerar informaes que sero dispostas na tabela de dados.
As tabelas de controle apresentam dois campos que evitam problemas na coleta de dados:
11 OwnerString: diferentes gerentes podem solicitar determinada monitorao, por isso,
h necessidade de um campo que identifique quem fez o pedido; cada entrada nessa
tabela possui um identificador que ser usado depois para reconhecer o dado coletado
na tabela de resultados;
(resultados).
101
11 EntryStatus: para encerrar uma monitorao, deve-se alterar o status da linha correspondente para invalid, a fim de no perder os dados; para criar uma monitorao, o status
deve ter o valor createRequest; a monitorao inicial quando o status for igual a valid.
Alguns problemas que podem surgir com a utilizao de um mesmo monitor por vrios
gerentes:
11 Muitos pedidos concorrentes de vrios gerentes podem sobrecarregar a capacidade de
um monitor;
11 Uma nica estao gerente pode alocar recursos do monitor e mant-los por muito tempo;
11 Uma estao gerente pode alocar recursos e sofrer um problema, impedindo a liberao
desses recursos para outros gerentes.
Grupos da MIB RMON

11 Grupos de estatsticas de trfego e erro:
22 statistics (1)
22 history (2)
22 host (4)
22 hostTopN (5)
11 Matriz de trfego entre sistemas:
22 matrix (6)
11 Grupos de filtragem e captura de trfego:
22 filter (7)
22 packet capture (8)
11 Grupos de alarmes e eventos:
22 alarm (3)
22 event (9)
A RMON 1 permite o monitoramento do trfego no nvel de enlace. Ela composta por nove
grupos de objetos gerenciados principais:
11 statistics (1): contm estatsticas de trfego (octetos, colises, erros etc.) para cada
interface e rede;
11 history (2): controla a amostragem estatstica peridica dos diversos tipos de rede e
armazena as amostras para posterior recuperao;
11 alarm (3): o grupo contm variveis que devem ser vigiadas, e os eventos que sero dis-
102
parados no caso dessas variveis ultrapassarem certos limites. Esses limites definem os
indicativos de problemas e de normalidade. Sua implementao exige o grupo event;
11 host (4): contm estatstica para cada host na rede;
11 hostTopN (5): controla e armazena relatrios com os hosts que apresentarem nmeros
mais relevantes (tops) para diferentes estatsticas. Os hosts so ordenados e apresentados
em uma tabela para fins de gerao de relatrios. Requer a implementao do grupo host;
11 matrix (6): armazena estatsticas para conversas entre pares de hosts. Aqui h o reconhecimento das origens e destinos dos pacotes que trafegam na rede. Uma entrada
criada para cada nova informao de comunicao entre dois endereos obtida de
pacotes recebidos. til para deteco de intrusos;
11 filter (7): define critrios de filtragem dos pacotes;

11 capture (8): permite o armazenamento dos resultados da filtragem feita. Requer a implementao do grupo filter;
11 event (9): define cada evento, seu tipo e a ltima ocorrncia. Eventos normalmente so
gerados pelo atingimento de um limite previamente estabelecido no grupo alarm ou
como resultado de um filtro definido grupo filter. Pode definir aes, como notificar um
gerente via trap ou atualizar um arquivo de log, ou ainda acionar uma captura de trfego.
Eventos e alarmes
Alarmes podem ser configurados para dispararem em resposta a eventos observados pelo
monitor. Por exemplo, o monitoramento do nmero de erros em um segmento de LAN
pode ser parametrizado com um limite superior (rising threshold) e um inferior (falling
threshold).
Eventos podem ser configurados para que sejam disparados em funo dos parmetros
acima. Por exemplo, o envio de uma trap que alerta para o alto nmero de erros na LAN e de
outra trap informando o retorno a um estado de normalidade (figura 4.3).
Evento gerado
Limiar: 40
Rearmao: 10
Evento gerado
Figura 4.3
Eventos e alarmes.
RMON 2
Diferena para a RMON 1:
11 Camada de rede.
11 Camada de aplicao.
Grupos:
11 Protocol Directory (11).
11 Protocol Distribution (12).
11 Address Map (13).
11 Network Layer Host (14).
11 Network Layer Matrix (15).
11 Application Layer Host (16).
11 Application Layer Matrix (17).
11 User History Collection (18).
11 Probe Configuration (19).
Tempo
103
Como visto, RMON 1 captura e analisa quadros (nvel de enlace). J a MIB RMON2 permite a
anlise das camadas superiores da arquitetura TCP/IP (figura 4.4).
Aplicao
Apresentao
Sesso
Transporte
Rede
Enlace de dados (MAC)
Fsica
RMON 2
RMON 1
Com isso, os fenmenos de trfego podem ser melhor compreendidos (fatos como aplicaes mais pesadas, servidores mais acessados, protocolos mais exigidos, etc.). Qualquer
camada acima de rede chamada de camada de aplicao, o que no significa que seja da
camada 7.
Com a RMON2 possvel analisar questes pertinentes aos protocolos mais utilizados
em uma rede local, por exemplo. Torna-se vivel identificar as aplicaes que causam
momentos de pico no uso da rede e at mesmo tomar decises quanto disposio de equipamentos em switches e VLANs.
Os seguintes grupos de objetos gerenciados so definidos na MIB RMON 2 (RFC 4502):
11 Protocol Directory (protocolDir): informaes sobre os diversos protocolos que o
monitor pode analisar;
11 Protocol Distribution (protocolDist): dados do trfego apresentado por protocolo;
11 Address Map (addressMap): dados do mapeamento de endereos MAC em endereos
de rede e portas;
11 Network Layer Host (nlHost): estatsticas do protocolo de rede por host;
11 Network Layer Matrix (nlMatrix): estatsticas do protocolo de rede por pares de hosts;
11 Application Layer Host (alHost): estatsticas dos protocolos de aplicao hosts;
11 Application Layer Matrix (alMatrix): estatsticas do protocolos de aplicao por pares
de hosts;
11 User History Collection (usrHistory): dados especficos de usurios;
104
11 Probe Configuration (probeConfig): parmetros operacionais de configurao do

monitor RMON (configuraes de interaes com interfaces seriais, aspectos de download de informaes, destinos de traps etc.).
A seguir apresentamos alguns grupos para melhor compreenso do funcionamento da RMON2.
Figura 4.4
Camadas
monitoradas pela
RMON1 e RMON2.
RMON2: Grupo Protocol Directory

Funo do grupo.
11 Configurao geral.
Tabelas do grupo.
11 protocolDirTable.
O grupo Protocol Directory a base para configurao da RMON2. Possui uma tabela (protocolDirTable), na qual so definidos os protocolos monitorados. A MIB considera que podem
ser monitorados protocolos de rede e de aplicao. Deve-se considerar que no contexto da
RMON2 aplicao qualquer protocolo acima da camada de rede. Isso inclui os protocolos
de transporte.
A configurao dessa tabela deve ser realizada antes do agente iniciar. Cada linha dessa
tabela estabelece uma monitorao associada a um dono. Dessa forma, possvel configurar que determinado gerente pretende monitorar vrios protocolos de rede e aplicao.
RMON2: Grupo Protocol Distribution

Funo do grupo.
11 Estatsticas gerais.
Tabelas do grupo.
11 protocolDistControlTable.
11 protocolDistStatTable.
O grupo Protocol Distribution apresenta uma tabela de controle e outra de dados.
Na tabela de controle (protocolDistControlTable), configura-se as interfaces em que se
deseja monitorar os protocolos definidos no grupo anterior. Nela armazenada, alm da
interface, o nmero de quadros no analisados, o momento em que a monitorao foi
A tabela de dados (protocolDistStatTable) armazena a quantidade de quadros e o nmero de

octetos de cada protocolo monitorado.
RMON2: Grupo Network Layer Host

Funo do grupo.
11 Estatsticas do protocolo de rede por host.

Tabelas do grupo.
11 hlHostControlTable.
11 nlHostTable.
O grupo Network Layer Host tambm apresenta duas tabelas. A tabela de controle (hlHostControlTable) permite determinar as interfaces a serem monitoradas (hlHostControlDataSource). A monitorao associada a um gerente e apresenta um tamanho mximo.
Na tabela de dados (nlHostTable) sero armazenadas estatsticas do protocolo de rede
(normalmente IP) para cada endereo: pacotes recebidos sem erro, pacotes enviados sem
erro, octetos recebidos, octetos enviados e pacotes no unicast enviados. A leitura peridica
dessa tabela permite montar relatrios mostrando o trfego no nvel de rede por host.
ativada e o gerente que configurou a entrada.
105
RMON2: Grupo Network Layer Matrix

Funo do grupo:
11 Estatsticas do protocolo de rede por pares de hosts (conversas).

Tabelas do grupo:
11 hlMatrixControlTable
11 nlMatrixSDTable
11 nlMatrixDSTable
11 nlMatrixTopNControlTable
11 nlMatrixTopNTable
O grupo Network Layer Matrix permite analisar o trfego, na camada de rede, entre duas
estaes. Na tabela de configurao hlMatrixControlTable, o gerente deve determinar a
interface a ser monitorada e um determinado limite de armazenamento de pares. Essa
tabela tambm serve para determinar a monitorao de pares de estaes no nvel de aplicao. Nela, no so descritas as conversas a serem monitoradas, mas que se deseja gerar
estatsticas para as mensagens trocadas entre quaisquer pares.
Os resultados da monitorao disparada em hlMatrixControlTable so colocados em
duas tabelas. Ambas as tabelas so indexadas pelo protocolo de rede monitorado e pelos
endereos. A tabela nlMatrixSDTable tem o endereo origem com precedncia na indexao
sobre o endereo destino. A tabela nlMatrixDSTable semelhante primeira, mas o ndice
corresponde ao endereo destino antecede o endereo origem.
Tambm possvel gerar estatsticas sobre os pares que apresentam maior trfego. Para
tal, utiliza-se a tabela nlMatrixTopNControlTable para configurar a monitorao e a tabela
nlMatrixTopNTable para recuperar os resultados.
RMON2: Grupo Application Layer Host

Funo do grupo.
11 Estatsticas dos protocolos de aplicao hosts.

Tabelas do grupo:
11 alHostTable.
11 hlHostControlTable (outro grupo mas controla).
O grupo Application Layer Host apresenta uma tabela denominada alHostTable. Essa tabela
apresenta informaes sobre o trfego dos protocolos aqui denominados de aplicao
(acima da camada de rede) para cada endereo. A configurao de qual interface deve ser
106
monitorada feita na tabela hlHostControlTable, do grupo Network Host Layer. Para cada
protocolo e cada mquina, possvel verificar o nmero de pacotes de entrada e sada e o
nmero de octetos de entrada e sada. Pode-se, por exemplo, determinar o trfego HTTP de
um determinado servidor.
RMON2: Grupo Application Layer Matrix

Funo do grupo.
11 Estatsticas do protocolos de aplicao por pares de hosts (conversas).

Tabelas do grupo:
11 alMatrixSDTable
11 alMatrixDSTable
11 alMatrixTopNControlTable
11 alMatrixTopNTable
11 hlMatrixControlTable (outro grupo mas controla)
O grupo Application Layer Matrix permite coletar estatsticas de pares de mquinas que utilizem determinado protocolo de aplicao. Ele semelhante ao grupo Network Layer Matrix,
com a diferena de coletar dados das camadas mais altas da arquitetura de redes. Inclusive,
a monitorao controlada na tabela hlMatrixControlTable, do grupo Network Layer Matrix.
Os resultados so dispostos nas tabelas alMatrixSDTable e alMatrixDSTable. Tambm possvel gerar uma lista dos pares com maior trfego na tabela alMatrixTopNTable, cujo controle
realizada em hlMatrixControlTable.
SMON: Remote Network Monitoring MIB Extensions for

Switched Networks
1. Dificuldades de uma rede com switches.
2. Extenso da RMON.
22 RCF 2613.
22 Grupo smonVlanStats.
22 Grupo smonPrioStats.
22 Grupo dataSourceCaps.
A utilizao da MIB RMON baseada na capacidade de os monitores capturarem o trfego
de uma rede. Tal tcnica data da poca em que as redes locais eram construdas com hubs
e no switches. A utilizao de hubs fazia com que mensagens encaminhadas para determinado equipamento fossem replicadas para todas as portas. A natureza broadcast de uma
rede baseada em hubs tornava a monitorao do trfego uma tarefa trivial, exigindo apenas
que o monitor tivesse capacidade de processar e armazenar o que estava sendo transmitido.
A utilizao de switches, ao mesmo tempo em que proporcionou melhor desempenho e
maior segurana para as redes Ethernet, introduziu uma dificuldade de monitorao do
trfego. Com switches, os dados so transmitidos apenas para as portas nas quais o destino
est conectado. Dessa forma, a simples colocao de uma estao em um switch no
permite a captura dos pacotes que so transmitidos na rede local. At mesmo quadros de
broadcast so restritos a algumas portas na medida em que se utilizam VLANs.
22 Grupo portCopy.
107
A fim de superar essa dificuldade e permitir o uso de monitores de trfego em redes com
switches, foi criada uma extenso da RMON, denominada SMON. Nessa MIB so definidos
quatro grupos responsveis pela soluo de monitorao:
11 smonVlanStats
11 smonPrioStats
11 dataSource
11 portCopy
SMON: Grupo smonVlanStats

1. Funo: monitorar pelo identificador da VLAN.
2. Tabelas do grupo.
3. Exemplos de dados monitorados.
O grupo smonVlanStat responsvel pela configurao e monitorao das tabelas da
VLANs. A monitorao baseada no identificador da VLAN, conforme definido no padro
802.1Q. Atravs desse grupo, possvel obter informaes de alto nvel de uso total de uma
VLAN e trfego no unicast.
A tabela smonVlanStatsControlTable permite a configurao da monitorao. J a tabela
smonVlanIdStatsTable contm as estatsticas coletadas. Entre os dados coletados, podem
ser citados:
11 Nmero total de pacotes de determinada VLAN;
11 Nmero total de octetos de determinada VLAN;
11 Nmero total de pacotes no unicast de determinada VLAN;
11 Nmero total de octetos no unicast de determinada VLAN;
11 Momento da ltima alterao da estatstica.
SMON: Grupo smonPrioStats

1. Funo: monitorar pelo TCI.
2. Tabelas do grupo.
3. Exemplo de dados monitorados.
O grupo smonPrioStat permite a monitorao a partir da definio codificada no campo Tag
Control Information (TCI) das VLANs. Os dados relativos a determinada TCI so agrupados
em estatsticas. A tabela smonPrioStatsControlTable permite a configurao da monitorao
e a tabela smonPrioStatTable contm os dados monitorados. Podem-se citar os seguintes
108
exemplos de contadores:
11 Nmero total de pacotes contados no nvel de prioridade selecionado;
11 Nmero de octetos contados no nvel de prioridade selecionado.
SMON: Grupo portCopy

1. Funo: copiar quadros para outra porta.
2. Tabela do grupo.
O grupo portCopy permite copiar todos os quadros de determinada origem para uma porta
do switch. possvel realizar cpias um-para-um, um-para-muitas, muitas-para-uma ou
muitas-para-muitas. Ao realizar essa configurao, deve-se estar atento para a possibilidade
de perdas se a porta destino no tiver capacidade de suportar o trfego gerado. Incentiva-se que os dispositivos de rede suportem pelo menos esse grupo da MIB SMON a fim de que
seja possvel configurar o espelhamento e algum monitor que implemente RMON possa
fazer a captura dos dados.
A tabela portCopyTable gerencia o espelhamento. Cada linha da tabela define um relacionamento
entre origem e destino. Os campos portCopySource, portCopyDest, portCopyDestDropEvents,
portCopyDirection e portCopyStatus formam a tabela e definem, respectivamente, a porta
que ter os pacotes redirecionados, a porta para aonde os pacotes sero redirecionados,
o nmero de vezes que pacotes no foram redirecionados por falta de recursos, que tipo de
dado ser redirecionado (recebido, transmitido ou ambos) e o estado operacional do redirecionamento. Deve-se observar que os campos portCopyDestDropEvents e portCopyStatus no
so preenchidos na configurao. So informaes geradas pelo monitor SMON.
SMON: Grupo dataSourceCaps

1. Funo: prover informaes sobre as portas para monitoramento.
2. Tabela principal.
O grupo dataSourceCaps descreve fontes de dados e capacidade de redirecionamento de
portas. Esses dados podem ser utilizados pelo sistema de gerncia da rede para descobrir
os atributos de um agente. A tabela preenchida pelo agente SMON.
cidades associadas a ele (monitorao de erros, monitorao de sucesso, possiblidade de

utilizao em qualquer tabela RMON ou apenas para espelhamento, identificao de frames
gigantes, e possibilidade de espelhamento).
ntop
11 O que .
11 Caractersticas.
O ntop um monitor de trfego que mostra a utilizao de rede, rodando sobre Unix/Linux
e Windows.
Atravs de um web browser, possvel navegar nas informaes de trfego que ele disponibiliza e ter um snapshot da situao da rede. Sua configurao tambm feita via browser.
Ele roda normalmente na porta 3000. A figura 4.5 apresenta uma tela do programa ntop.
A tabela dataSourceCapsTable armazena a identificao do objeto (fonte de dados), as capa-
109
Apesar de no suportar o padro RMON, o ntop se comporta como um monitor remoto com
uma interface web que no consome muitos recursos de CPU e memria.
Caractersticas:
11 Ordena a informao de trfego segundo diversos critrios: protocolo (vrios); origem/
destino; matriz de subredes;
11 Apresenta estatsticas similares ao RMON;
110
11 Apresenta estatsticas de domnios internet, AS (Autonomous Systems) e VLAN;

11 Armazena as informaes em disco (formato RRD);
11 Identifica passivamente usurios e OS;
11 Possui APIs para acesso remoto em Perl/PHP/Python;
11 Possui grficos;
11 Possui suporte a HTTPS.
Figura 4.5
Tela do ntop.
Gerenciamento de hosts e sistemas

11 Hosts representam parcela relevante no tempo de atendimento.
11 Precisam ser apropriadamente:

22 configurados (planejamento de capacidade).
22 protegidos (segurana).
22 monitorados (contabilizao de uso e gerenciamento proativo).
11 Para monitorar a situao de hots: MIB Host-Resources (RFC 2790).
O termo host, no contexto de gerncia de redes, implica em um computador qualquer que
se comunica com outros computadores interligados via internet, e diretamente utilizado
por usurios humanos. preciso monitorar as aplicaes crticas nos hosts e conter em
tempo degradaes de servio isolando aplicaes, segmentos de rede que estejam causando problemas de desempenho ou prevenindo uso frvolo da rede.
Gerenciar um host diferente de dispositivos de rede, porque um host tem mais inteligncia e tem mais dispositivos a ele conectados. Nesse tipo de equipamento, esto disponveis mais informaes sobre sua atividade, como por exemplo, em seu arquivo de log.
Certos produtos (chamados watchdogs) analisam as informaes contidas em arquivos de
log e geram eventos para plataformas de gerncia.
Outra facilidade disponvel em hosts o uso de scripts que automatizam tarefas no prprio
sistema. A gerncia de sistemas pode ser feita sem usar SNMP, mas existe tambm a possibilidade de gerenciar hosts usando SNMP mediante o uso da host resource MIB (RFC 2790)
para esse propsito.
A MIB II oferece informaes bsicas que servem para gerenciar hosts. Os grupos TCP e UDP
proporcionam informaes sobre o volume de dados que so enviados para as aplicaes,
tal como ilustrado a seguir:
Tabela 4.1
Grupo TCP da MIB II
para gerenciamento
de performance.
Objeto
Informao usada para gerenciamento de performance
tcpActiveOpens
Nmero de vezes em que o sistema abriu uma conexo.
tcpPassiveOpens
Nmero de vezes em que o sistema recebeu um pedido de abertura

de conexo.
tcpInSegs
Nmero total de segmentos TCP recebidos.
tcpOutSegs
Nmero total de segmentos TCP emitidos.
tcpConnTable
Tabela das conexes TCP.
As informaes da tabela tcpConTable tambm podem ser usadas para gerenciamento de

segurana, pois permitem o conhecimento dos sistemas que acessam recursos via TCP tal
como referido a seguir:
Exemplo de objetos do grupo TCP da MIB II usados para gerenciamento de performance
111
Exemplo de objetos do grupo TCP da MIB II usados para gerenciamento de segurana

Objeto
Informao usada para gerenciamento de segurana
tConnState
Estado da conexo, que pode ser qualquer um entre os estados assumidos pela
conexo TCP: LISTEN, SYN-SENT, SYNRECEIVED, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2,
CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT e CLOSED, ilustrado na figura 4.6.
tConnLocalAddres
Endereo TCP local (valor 0.0.0.0 usado no caso de conexes que esto no estado de
LISTEN, ou seja, aptas a aceitarem conexes de qualquer endereo IP associado).
tConnLocalPort
Porta IP local da conexo.
tConnRemoteAddres
Endereo TCP remoto.
tConnRemotePort
Porta IP remota.
O campo tcpConLocalPort determina a porta usada pelas aplicaes que esto ativas para
receberem conexes no host. Essas aplicaes fizeram um open passivo, que implica em
serem ativadas e a porta a elas associadas passou do modo CLOSED para o modo LISTEN, tal
como ilustrado no diagrama de estado do protocolo TCP (figura 4.6). A consulta a esse objeto
Tabela 4.2
Grupo TCP da MIB II
para gerenciamento
de segurana.
permite o conhecimento de quais sistemas esto aptos a receber conexes.

O campo tcpConRemAddress determina o endereo do sistema remoto que est conectado
entidade. A consulta frequente a esse campo permite o conhecimento de quais sistemas
usam os recursos da rede e durante quanto tempo.
Saiba mais
connect/SYN
CLOSED
Muitas aplicaes
TCP usam portas bem
definidas, tais como
25-email, 22-ssh, 20
e 21-ftp, tornando
possvel determinar
quais aplicaes esto
fazendo ou recebendo
conexes TCP.
close/listen/SYN/SYN+ACK
close/-
LISTEN
send/SYN
RST/
SYN-RCVD
close/RST
SYN-SENT
timeout/RST
SYN/SYN+ACK
ACK/
SYN/SYN+ACK
close/FIN
112
ESTABLISHED
close/FIN
FIN/ACK
FIN/ACK
FIN-WAIT-1
ACK/
CLOSING
FIN+ACK/ACK
FIN-WAIT-2
ACK/
TIMED-WAIT
CLOSE-WAIT
close/FIN
LAST ACK
FIN/ACK
timeout/
ACK/
Figura 4.6
Diagrama de estado
do protocolo TCP.
O grupo UDP tambm oferece um conjunto de objetos relevante para gerenciamento de

host, pois diversas aplicaes so acessadas mediante o uso desse protocolo, tal como o
servio de nomes (DNS-63) e a prpria gerncia de rede (SNMP-161).
Exemplo de objetos do grupo UDP da MIB II usados para gerenciamento aplicaes
Taxa de datagramas recebidos.
udpOutDatagrams
Taxa de datagramas enviados.
udpNoPorts
Taxa de datagramas que no foram enviados para

uma porta vlida.
udpInErrors
Taxa de datagramas UDP recebidos com erro.
O objeto udpNoPorts informa quando a entidade est recebendo datagramas destinados a

uma aplicao que no est ativada. O objeto udpNoPorts informa quando a mquina est
recebendo datagramas destinados a uma aplicao que no est ativa. Um volume muito alto
de datagramas UDP pode resultar em problemas de performance, e no caso de mltiplas
tentativas de acesso a servios em portas UDP inativas, normalmente indica que o host est
sendo objeto de uma varredura de portas (udp port scan) que usualmente o primeiro passo
dos hackers sondando mquinas na tentativa de encontrar aplicativos que tenham vulnerabilidade passveis de serem exploradas. Em adio s informaes disponveis na MIB CONE
INTERNET, foi definida uma Host MIB (RFC 2790 que contm informaes relevantes para a
gerncia de hosts). Essa MIB contm os seguintes grupos de objetos gerenciados:
11 System group: data do sistema, dispositivo e parmetros de boot, nmero de usurios
logados, nmero de processos em execuo. Os objetos gerenciados desse grupo so:
11 Storage group: quantidade de memria principal, tabela de dispositivos de armazenamento, tipos de dispositivos, descrio, unidades de alocao, tamanho das unidades de
alocao usadas, bem como eventuais falhas de alocao. Esses objetos permitem monitorar continuamente os servidores e detectar se algum recurso est sendo consumido
at seu limite. A falta de rea de disco um problema que pode impedir o funcionamento
de algumas aplicaes.
Tabela 4.3
Grupo UDP
da MIB II para
gerenciamento de
aplicaes.
udpInDatagrams
113
11 Device group: tabela de dispositivos, tipo, descrio, nmero de erros, tabela de processadores, utilizao, placas de rede, tabela de impressoras, status, estado de erro detectado,
tabela de discos e de parties, tabela de sistemas de arquivos, ponto de montagem, permisses de acesso, se bootvel ou no, datas de backup parcial e completo;
11 Running software group: descrio do software carregado em memria (fsica ou virtual)

e pronto para rodar; inclui Sistema Operacional, drivers, aplicaes, variveis da tabela,
nome do software, path do arquivo executvel, parmetros e tipos de execuo, status;
114
11 Running software performance group: para cada processo em execuo, so apresentadas o consumo de CPU (em centsimos de segundo) e de memria do processo.
Esses objetos permitem monitorar remotamente os aplicativos sendo executados na
mquina, e assim avaliar se algum deles est consumindo recursos de forma anormal.
nome do software, tipo (operating system, driver, application) e data de instalao.

Esse grupo de objetos permite auditar remotamente um hpst e averiguar quais softwares
esto instalados naquela mquina.
11 Installed software group: uma tabela tem uma entrada para cada software instalado:
115
Gerenciamento de aplicaes
O propsito das tecnologias de informtica a execuo de aplicaes, que precisam de
recursos para funcionar.
importante poder configurar aplicaes, detectar falhas, monitorar o desempenho de
aplicaes e acompanhar a aplicao ao longo de sua vida, e tudo isso pode ser monitorado
mediante o uso da Host MIB. importante ressaltar que a anlise da rede deve ser feita de
forma holstica, isto , integrando todos os aspectos, pois eles tm impacto mtuo. Um roteador descartando pacotes pode provocar sobrecarga em um servidor e, reciprocamente, um
servidor que esteja recebendo uma carga de trfego superior sua capacidade de processamento/armazenamento pode causar congestionamento na rede em funo das inmeras
perdas de pacote e consequentes retransmisses que ocorreriam.
Network
Manager
Ro
Host MIB
uter MIB
Figura 4.7
Usando a Host MIB.
A gerncia de aplicaes pode ser feita com software especializado, que frequentemente faz
parte do prprio software da aplicao (monitores, logs, consoles etc.). Todavia, em funo
das informaes disponibilizadas pelo Host MIB, a monitorao dos recursos do host pode
ser feita a partir de qualquer plataforma de gerncia de rede, pois as informaes necessrias
podero ser buscadas mediante o uso do protocolo SNMP. A integrao de diversas estrat-
gias de gerenciamento desejvel para que uma viso completa do cenrio seja possvel.
116
Host Resource MIB
HOST
System-Level Application MIB
SISTEMA
OPERACIONAL
Application MIB
Network Services
Monitoring MIB
MIB Genrica do
Tipo de Aplicao
MIB Especca de
Produto (Proprietria)
APLICAO
Figura 4.8
Integrao de
gerenciamento
de redes e de
sistemas.
Algumas formas de gerenciar a aplicao:

11 Sem instrumentao: usando comandos do Sistema Operacional ou utilitrios genricos (por
exemplo: netstat, top, lsof etc.), para ver recursos utilizados, status de processos, logs etc.;
11 Com instrumentao da aplicao: permite uma gerncia mais eficaz, atravs de ferramentas especficas para a aplicao.
11 H esforos de elaborao de MIBs para possibilitar a utilizao de SNMP para monitoramento e controle de aplicaes:
22 System-level application MIB (RFC 2287): MIB para gerenciamento de aplicaes sem
instrumentao;
22 Application Management MIB (RFC 2564): complementa a anterior;
22 Outras MIBs especficas de aplicaes tpicas (DNS, Mail, diretrio, servio web etc.).
A figura seguinte ilustra parte da tela de uma plataforma de gerncia de rede que exibe
dados sobre um servidor, obtidos mediante o uso de SNMP, tanto da MIB CONE INTERNET,
como da Host MIB. Cada um dos dados exibidos no grfico da figura 4.9 pode tambm ser
apresentado na forma de um grfico que exiba a evoluo de determinado parmetro ao
longo do tempo. O grfico da figura 4.10 um exemplo dessa outra forma de exibio do
Figura 4.9
Exemplo de
relatrio de
gerncia de host.
parmetro Response Time dessa mesma estao ao longo de 30 dias.
117
Figura 4.10
Evoluo do tempo
de resposta do
servidor.
Observando esse grfico, percebe-se que h picos peridicos em que o tempo de resposta aumenta. Sabendo que backups semanais so realizados como rotina da instalao,
deduz-se que tais picos de aumento no tempo de resposta devem coincidir com o perodo
em que est sendo realizado o backup semanal.
118
5
objetivos
Aspectos e aplicaes de
plataformas de gerncia
Conhecer os modelos de gerncia; Aprender sobre Network Management System
(NMS); Saber como a arquitetura de um sistema de gerncia; Usar uma anlise
FCAPS na definio de um NMS; Conhecer as Network Management Systems
disponveis no mercado.
conceitos
Modelos de gerncia; Network Management System (NMS); Arquitetura de sistema

de gerncia; Anlise FCAPS na definio de um NMS.
Modelos de gerncia
Quando se planeja a criao de uma infraestrutura de gerncia de redes, um bom incio
uma anlise do modelo de gerncia desejado.

11 Gerncia de Servios do Negcio (BSM).
11 Gerncia de Processos do Negcio (BPM).
Saiba mais
Devido dependncia
crescente da infraestrutura de TI por parte
das organizaes, a
escolha da ferramenta
de gerncia est cada
vez mais passando ao
largo de uma deciso
puramente tcnica para
se tornar uma deciso
estratgica dentro das
organizaes.
11 Gerncia de Rede e Sistemas (NMS).

Quando se identifica a necessidade de gerncia de uma rede e servios, normalmente a
base da anlise est voltada unicamente para a infraestrutura da rede. Entretanto, deve-se
inicialmente identificar as reais necessidades de gerncia da empresa ou instituio de uma
forma mais metdica.
Em um passado no muito distante, a deciso de quais ferramentas usar para ter controle
da rede baseava-se em um critrio unicamente tcnico, j que era somente uma forma de
o prprio administrador da rede possuir algum conhecimento geral da infraestrutura para
saber qual a causa de uma falha e solucion-la atravs de uma interveno manual (reconfigurao, reincio ou substituio de equipamento, solicitao de reparo por parte das
operadoras de telecomunicao etc.).
Decises como virtualizao, contratao de servios na nuvem, Software as a Service (SaaS),
Service Oriented Architecture (SOA), Bring Your Own Device (BYOD), cobertura WiFi, trabalhadores remotos, ampliao do parque de computadores e at mesmo a escolha por um
Captulo 5 - Aspectos e aplicaes de plataformas de gerncia
11 Gerncia de Servios de TI (ITSM).
atendimento a clientes e vendas via internet tm se tornado corriqueira em empresas de todo

o porte, e parte das definies administrativas relativas ao modelo de negcios da empresa.
119
Esse portflio de servios necessita de um acompanhamento quanto qualidade do servio

prestado (SLA) e, obviamente, uma gerncia sobre a sua disponibilidade, desempenho, utili-
SLA
zao e a satisfao dos clientes e usurios. Casos como integrao da telefonia tradicional
Do ingls Service Level

Agreement (Acordo de
Nvel de Servio), um
acordo que geralmente
firmado entre um
cliente e uma empresa,
que descreve o servio
que ser oferecido,
suas metas de nvel de
servio, alm dos papis
e responsabilidades das
partes envolvidas no
acordo.
com servios de voz sobre a rede IP (VOIP), servios de videoconferncia e necessidade de

controle de uma vasta gama de servios dependentes da rede justificam investimentos
financeiros de vrios milhares de reais, geralmente acima da alada financeira do prprio
diretor de TI das instituies. Esse investimento tem como objetivo gerenciar essa complexa
infraestrutura de equipamentos e servios que agora mantm toda a empresa operacional e
direcionar novos investimentos e estratgias de negcio.
Figura 5.1
Gerncia de Redes
e Gerncia de
Servios de TI.
Aquele mundo distante, onde a falha em um equipamento era rapidamente notada pelo
administrador da rede, hoje fica oculta pela resilincia planejada para a prpria infraestrutura, fibras pticas em anel, redundncias de todo o tipo: nobreaks, geradores, servidores,
balanceadores de carga, cabeamento, switches, roteadores, circuitos de comunicao e, em
alguns casos j nem to comuns, a redundncia de todo o datacenter. Esses so fatos cada
vez mais comuns, devido dependncia que as empresas hoje possuem para manter todo o
seu negcio. Em um futuro prximo, conceitos como Internet of Things (IoT) sero aplicados,
gerenciando a utilizao da energia (lmpadas), sistemas de ar-condicionado do datacenter e
at mesmo onde se encontram fisicamente os dispositivos mveis da empresa (Pads, celulares
etc.). Tudo isso tende a ser gerenciado utilizando-se uma plataforma nica como uma maneira
de diminuir a complexidade associado a vrias plataformas de gerncia independentes.
Nesse contexto, muitas instituies necessitam no somente de uma gerncia da infraestrutura bsica baseada nos principais elementos da rede, mas sim da possibilidade de crescimento dessa gerncia at que ela consiga responder de forma unssona a todos os fatores
de TI que possam influenciar a misso da empresa.
120
Uma falha no diagnosticada no sistema de ar-condicionado do datacenter pode

causar o desligamento de todo o datacenter. O atraso na substituio das baterias do
nobreak pode diminuir a autonomia do datacenter nos casos de falhas de energia.
Network
Performance
Monitoring
Network
Management
System
IT Asset
Management
Application &
Server Monitoring
Database
Monitoring
at
io
nT
ech
n olo
g y Infra e
tu
struc
)
IL
fo
Bandwitch &
Trac Analysis
IT
In
re
Li
a
br
ry
O primeiro ponto a se estabelecer quando se fala da definio de gerncia da rede justamente delimitar a gerncia esperada para a instituio, traando as linhas bsicas e as
melhores prticas demandadas para a gerncia de servios do negcio (Business Service
Management BSM) em relao gerncia de TI da empresa (Information Technology
Service Management ITSM), e destas para a gerncia da rede propriamente dita (Network
Management System NMS). Uma definio importante aqui a da integrao desejvel
entre esses elementos.
Um dos modelos frequentemente utilizados nas empresas o Information Technology
Infrastructure Library (ITIL). Nesse modelo, os processos de gesto de TI tm foco no cliente
e permitem definir entre outras coisas a relao de dependncia de cada um dos elementos
de TI da empresa (roteadores, switches, servidores etc.) para cada um dos servios prestados aos clientes.
J as ferramentas do BSM so projetadas para auxiliar a organizao quanto viso da
empresa a respeito da rea de TI, fornecendo recursos a esta, de maneira a melhor manter
os servios prestados pela rea empresa e seus clientes. Em suma, BSM auxilia na gesto
de TI atravs de uma abordagem baseada nos servios de TI (ITSM). Novos sistemas BSM
utilizam uma viso unificada de um datacenter, permitindo que os administradores possam
gerenciar desde as aplicaes individualmente at os menores eventos da rede de forma
unificada (em um mesmo monitor), conseguindo antecipar ou visualizar possveis problemas
antes que os usurios os percebam.
Figura 5.2
BSM, SLM e ITIL
(fonte: http://www.
manageengine.ca/
it360.aspx).
rm
(BSM)
ent
em
ag
an
M
End User
Experience
Monitoring
Se
rv
e
ic
Servic
e Le
vel
M
an
ag
Bus
ine
ss
M)
(SL
t
en
em
121
Process &Services
Business Process 1
Service A
Business Process 2
Service B
Bussiness
Perspective
Service C
Application
Application X
Application Y
Infrastructure
Network
Server
Storage
Databases
Technical
Perspective
Enquanto no modelo de gerncia de redes mais tradicional, a proposta simplesmente

aplicar o modelo IETF-SNMP para gerenciar os componentes da rede de uma forma mais
tcnica, sem se preocupar em mensurar exatamente o peso que cada componente possui
dentro de todo o contexto da empresa, a maioria dos setores de TI j possui alguma forma
de gerncia baseada nos modelos ITIL, BPM ou outros, mas em sua maioria de forma no
integrada, isto , gerncias distintas para servios e elementos distintos da rede. Nesse
ambiente, frequente que as diversas equipes como as de infraestrutura de rede fsica
(cabeamento), infraestrutura L2 (switching), infraestrutura L3 (roteamento), banco de dados,
telefonia, servios em nuvem, atendimento ao usurio etc., tenham um conjunto prprio de
ferramentas para responder aos requisitos demandados.
Sendo assim, o primeiro passo dado em direo definio de uma plataforma de gerncia
de redes deve ser a anlise do que dever ser gerenciado pela empresa no futuro. Esse
passo especialmente importante por justificar o custo-benefcio das solues mais
completas, j que normalmente o esforo de implementao, treinamento e ajustes de
uma plataforma de gerncia at seu uso confivel situa-se em um tempo medido em anos,
incorporando-se nesse tempo vrias melhorias.
Na maioria dos casos, a migrao de uma plataforma para a outra quase sempre traumtico, significando a perda de todo o conhecimento, tempo e esforo utilizado na plataforma
anterior. Geralmente esse tempo medido por customizaes, como a criao de regras de
negcio, relaes de dependncias de servios e equipamento etc., e impactam diretamente
em pontos como confiabilidade, estabilidade, capacitao de equipe e custo de horas tc Gerncia de Redes de Computadores
nicas dedicadas implementao da nova soluo. A contabilizao desse custo-benefcio
122
uma deciso mais administrativa do que tcnica.

Uma vez definidas as linhas bsicas pela administrao da empresa, uma avaliao mais
tcnica/gerencial do modelo a ser usado deve ser realizada. Existem diversos modelos de
gerncia de redes que podem ser implementados. A definio de um modelo baseada
principalmente na necessidade do que se deseja gerenciar, como:
11 Uma gerncia mais voltada ao negcio e servios da empresa;
11 Gerncia visando uma operao especfica, como a das empresas de telecomunicaes;
11 Uma gerncia mnima dos elementos de TI da empresa.
Figura 5.3
Mapeamento
de dependncia
entre processos
de negcio e
elementos da rede.
FCAPS
Falhas
Configurao
Contabilizao
Desempenho
Segurana
Gerncia do Negcio
No
Sim
Sim
Sim
Sim
Gerncia de Servios
Sim
Sim
Sim
Sim
Sim
Gerncia de Redes
Sim
No
Sim
Sim
Sim
Gerncia de Elementos
Sim
No
Sim
Sim
Sim
Operao
No
No
Sim
Sim
Sim
Administrao
No
Sim
Sim
Sim
Sim
Manuteno
Sim
No
Sim
Sim
Sim
Provisionamento
Sim
No
No
No
No
implantao
Sim
No
No
No
No
Garantias
No
Sim
Sim
Sim
Sim
Faturamento
No
Sim
Sim
No
No
Suporte e Facilidades de
Opreao
No
No
No
No
No
IETF SNMP (TCP/IP)
Sim
Sim
Sim
Sim
Sim
ISO CMIP/CMS
Sim
Sim
Sim
Sim
Sim
TMN
OAM&P
TOM /e TOM
As gerncias voltadas ao negcio envolvem a definio prvia dos processos do negcio,

para em um segundo momento definir-se quais as ferramentas sero necessrias para
estabelecer os nveis de servio desejados e o nvel de integrao do sistema ou sistemas de
gerncia da rede com outros, de forma semelhante ao que realiza com o sistema de
Enterprise Resource Management (ERP) da empresa. Normalmente esse processo decisrio
leva anos de planejamento, mas se essa a linha a ser seguida, a escolha de um NMS mais
robusto e escalvel justifica o investimento.
Existe uma tendncia nas empresas de grande porte em uma gerncia mais voltada a servios, enquanto empresas menores tendem a manter um isolamento entre os negcios da
empresa e a infraestrutura de TI. Boa parte dessa deciso associada aos custos de implementao dessa gerncia integrada e, claro, outra parte por desconhecimento dessas possibilidades ou pelas empresas simplesmente possurem uma complexidade dentro dos limites
humanos de compreenso dos detalhes e inter-relacionamento de diversos elementos de
infraestrutura que compem determinado servio.
Figura 5.4
Alguns modelos
de gerncia.
123
Bussiness Topology
Regis
Industries
ACME
limited
Order
Management
Order
Capture
Order
Status
Order
Modication
Application Topology
Finance
FI-1
Order Processing
FI-3
FI-2
OP-NY
OP-UK
CRM
CRM
East
OP-LA
ERP
OP-JP
ERP-NY
Fulllment
CRM
West
Full-1
Full-2
ERP-JP
ERP-UK
SCM
Full-3
SCM-1
SCM-2
Infrastructure Topology
ERP-1
FI-1
FI-2
FI-3
OP-NY
ERP-2
OP-LA
Switch5
OP-UK
Switch1 b
Switch1 a
OP-JP
Switch4
Router3
Router4
Switch0
124
CRM-2
CRM-1
SCM-2
CRM-6
CRM-5
ERP-3
SCM-1
SCM-6
Switch2
CRM-3
CRM-4
Full-1
Switch3
Full-2
Full-3
Switch4 SCM-5
SCM-3
SCM-4
Existem vrias funcionalidades das diversas plataformas de gerncia, e a forma mais comum
de caracterizar suas funes utilizando o modelo Fault, Configuration, Accounting,
Performance e Security (FCAPS).
Figura 5.5
Camadas
de gerncia.
Network Management System (NMS)

11 Simplificam e sumarizam as informaes de gerncia coletadas.
11 Integram-se com outros sistemas, criando uma interface nica.

11 Organizam dados de gerenciamento, apresentando-os de maneira mais adequada
(grficos tabelas e relatrios).
11 Plataforma gratuitas versus comerciais.
Em um conceito simples, um sistema de gerncia de redes (NMS) uma combinao de
hardware, software e protocolos utilizados para administrar todos os elementos da rede.
Os diferentes elementos a serem gerenciados variam de uma organizao para outra e a sua
definio um dos pontos bsicos para a escolha de um sistema de gerncia com o objetivo
de mapear todos os elementos que so importantes para a organizao e, preferencialmente, conseguir visualizar seus relacionamentos de forma conjunta.
Entre as centenas de sistemas de gerncia existentes, preciso que o administrador da rede
consiga escolher qual, ou quais, melhor de adaptam s suas necessidades.
11 As ferramentas escolhidas para o NOC devem ser teis e utilizveis;
11 Muitas ferramentas so excelentes, mas exigem alto nvel de conhecimento para tirar
proveito delas;
11 Uma boa ferramenta permite tanto customizao quanto reconhecimento automatizado da rede;
11 Ideia fundamental: quanto menos informao o usurio precisar inserir, melhor.
O ponto fundamental que rege a escolha do NMS a ser implementado sem dvida que ele
seja adequado s necessidades e expectativas que se tem. Investir em ferramentas caras
nem sempre a melhor soluo, j que as inmeras funcionalidades dispendem um conhecimento no desprezvel para o seu uso.
11 A interface grfica deve mostrar claramente as falhas da rede;
11 Ter suporte a web e nveis de usurios importante.
existem sistemas que exigem a instalao de um cliente especfico para realizar algumas
funes, fazendo distino entre um acesso web e um acesso pelo cliente instalado
(exemplo: edio dos mapas da rede).
Outro ponto relevante a possibilidade de definir-se perfis e grupos de usurios como
administrador e operador, o que evitar que configuraes da gerncia de determinados
segmentos (exemplo: banco de dados) sejam alterados por outra equipe de trabalho
(exemplo: equipe de suporte a redes). Grupos e subgrupos de trabalho so bastante teis,
mas so poucas ferramentas que os implementam de uma forma efetiva e integrada usando
plataformas de autenticao, como Ldap.
11 O software escolhido passvel de integrao?
22 Um bom NMS permite integrao com outros padres da indstria, permitindo

interao via mail, sistema de tickes, SMS etc. Quanto maior a possibilidade de
integrao, melhor.
Na maioria das vezes, no possvel adquirir uma soluo de gerncia totalmente integrada
e completa que abarque todos os elementos e servios da rede. Nesse ponto, a possibili-
Um dos pontos fundamentais para essa definio sempre a interface de uso, j que
125
dade de integrao com as ferramentas existentes acaba sendo necessria. Um fato comum
uma nova soluo de gerncia ter de se integrar com um sistema de registro de problemas
j existente na empresa. Um caso a necessidade de abertura de tickets via API ou e-mail
para realizar essa integrao.
11 Existe uma boa interface de relatrios:
22 possvel extrair diversos relatrio de forma facilitada, customizvel e em tempo real.

Em outros pontos a operao da empresa possui portal de clientes e gostaria de disponibilizar os dados da gerncia e seus relatrios diretamente para os clientes nesse portal ou
emiti-los diretamente e de forma regular aos seus clientes. Algumas ferramentas possuem
mdulos especficos para esse fim (exemplo: integrao com Crystal Reports ou gerao
de relatrios em PDF ou planilhas de Excel), enquanto em outras os relatrios precisam ser
extrados manualmente.
11 Modularidade:
22 Possibilidade de agregao em mdulo de novas funcionalidades prevendo

aumento da gerncia;
22 Permite acompanhar futuras demandas da empresa.
A modularidade das ferramentas um item obrigatrio para empresas maiores ou que pretendem adotar um NMS como uma plataforma de gerncia institucional. Na prtica, a modularidade da ferramenta o que permitir a integrao de novas funcionalidades na gerncia
da rede, permitindo a gerncia de novos servios. Alguns mdulos so desenvolvidos pelo
prprio fabricante e outros por empresas terceiras baseado em APIs que o fabricante do
software prov. Alguns exemplos mdulos que podem ser integrados a posteriori so:
11 Auditoria de sistemas;
11 Service Desk e sistema de registro de problemas;
11 Gerncia de bens e inventrio;
11 VOIP e Telefonia IP;
11 Gerncia de Configurao;
11 Gerncia de Impresso;
11 Gerncia de Processos e Nvel de servio (SLA).
Cada rede tem suas necessidades, defina o seu ideal de gerncia:
11 O que voc quer gerenciar: processo, servios etc.;
11 Defina as reas em que voc quer agir (FCAPS?);
126
11 Defina se uma gerncia integrada ou no vital.

22 Estabelea seu oramento;
22 Defina o tempo para implantao;
22 Planeje o tempo de vida da sua soluo;
22 Defina e treine recursos humanos.
imprescindvel definir anteriormente o que se deseja gerenciar dentro da instituio,
levando em conta que a cada nova gerncia existe um custo considervel associado, tanto
para compra do produto (se for o caso), quanto para a manuteno da soluo e o treinamento da equipe responsvel pelo processo.
Entre a extensa lista de possibilidades de ferramentas, a mxima integrao deve ser um

dos objetivos. Infelizmente, ela acaba sendo cerceada pelo custo das plataformas, fazendo
com que a utilizao de vrias solues gratuitas seja sempre considerada como algo factvel,
muitas vezes se desprezando o custo de manuteno de uma soluo mltipla em vez de
uma soluo integrada. Nesse ponto, alguns itens devem ser considerados, como o tempo
de vida que voc planeja para a soluo e o custo de pessoal. Algo que frequentemente
desconsiderado na adoo de plataformas de gerncia de redes gratuitas que um software
gratuito possa ser descontinuado ou ser incompatvel com a verso anterior, fazendo com que
o trabalho de configurao da gerncia tenha de ser refeito. Outro ponto a considerar que a
curva de aprendizagem de muitas ferramentas freeware no so desprezveis.
11 Plataformas comerciais:
22 Integradas;
22 Curva de aprendizado relativamente rpida;
22 Intuitivas.
11 Plataformas gratuitas:
22 Funcionalidades bsicas;
22 Reaprendizado constante;
22 Risco de descontinuidade.
Quando se chega nesse ponto, uma boa sada novamente a avaliao do modelo FCAPS
para definir quais as funcionalidades so necessrias para definir o que precisa ser gerenciado na instituio. A anlise inevitavelmente passa pelo fator financeiro, e deve-se ter em
mente que muitas vezes existe somente uma substituio entre custo da ferramenta e custo
de pessoal para manter ferramentas gratuitas ou de baixo custo.
Os NMSs de primeira linha geralmente possuem uma plataforma totalmente modular, permitindo o crescimento e melhorias no gerenciamento das organizaes atravs da aquisio de
novos mdulos de gerncia. As plataformas comerciais de primeira linha em geral disponibilizam
centenas de mdulos e plug-ins que aumentam a lista de elementos que podem ser gerenciados,
Entre a lista dos NMS comerciais mais completos, podemos citar:
11 CA Spectrum (www.ca.com/spectrum);
11 HP IMC Intelligent Management Center;
11 HP NNM: Network Node Manager (www.hp.com/go/nnm);
11 IBM Tivoli Netcool Network Management (www.ibm.com/tivoli);
11 BMC Suite.
Existem ainda NMSs que no so to completos no que se refere integrao com diferentes modelos e processos de negcio, mas possuem um crescimento mais limitado e
enfoque mais tcnico (para administradores de sistemas e gerentes de rede).
Alguns NMS tm custos acessveis para empresas pequenas e mdias, como por exemplo:
11 OPManager;
11 SNMPc;
11 WhatsUP Gold;
11 Zabbix;
possibilitando o reconhecimento de praticamente todos os softwares e hardwares conhecidos.
11 Nagios-XI a plataforma paga do Nagios com vrias facilidades de uso.

127
Em redes menores, existe ainda a possibilidade de utilizao de ferramentas comerciais que

permitem o uso limitado de funcionalidades, geralmente disponibilizado como uma verso
gratuita ou como um opensource ou freeware. Normalmente essas limitaes so quanto
quantidade de servios e funcionalidades disponibilizados nessas plataformas gratuitas,
mas em alguns casos podem ser oferecidas o conjunto completo de funcionalidades, porm
para um nmero limitado de dispositivos ou elementos gerenciveis.
Verses opensource/freeware de ferramentas comerciais:
11 HP INM permite uso completo para at 25 nodos;

11 OPManager permite uso gratuito para at 10 elementos de rede;
11 Zabbix possui uma verso comercial e outra gratuita com restrio;
11 Nagios verso opensource.
Existem ainda NMSs para fins especficos, ou seja, atreladas a algum fabricante de hardware,
em geral switches ou roteadores. Essas plataformas normalmente so disponibilizadas
junto com a compra de determinados equipamentos, para a gerncia especfica daqueles
equipamentos. Na maioria dos casos, essas ferramentas permitem a gerncia limitada para
equipamentos de outros fabricantes (exemplo: somente suporte a MIB-II e ICMP), e tm de
ser abandonados no momento da troca dos equipamentos (hardware) da rede.
Alguns exemplos de ferramentas de gerncia especficas:
11 Ericson IPECS NMS (Network Management Solution);

11 Extreme Networks RIDGELINE Network and Service Management;
11 HP Procurve Manager;
11 Cisco Works LMS.
Arquitetura de um sistema de gerncia

Uma soluo de gerncia precisa prover uma viso da infraestrutura de forma confivel e
escalvel. Para que se saiba identificar essas caractersticas em muitas plataformas, necessrio entender como essa arquitetura de funcionamento da prpria plataforma costuma
ser planejada. Em um modelo simplista, o NMS responsvel por receber informaes no
solicitadas (TRAPS) ou questionar os agentes remotos por alguma informao (GET) e eventualmente solicitar que alterem alguma de suas configuraes (SET), porm, como resultado
final, o usurio do NMS espera que cada uma das atividades realizadas sejam contabilizadas,
tarefas repetitivas sejam automatizadas e resolvidas sem a interferncia direta do operador,
alm, claro, que seja possvel exibir o estado da rede atravs de um mapa compreensvel
e multinvel, implementando um processo definido para controle dos problemas e gerando
relatrios capazes de prever possveis problemas baseados no conhecimento armazenado
128
ao longo da operao do sistema, e tudo de forma mais inteligente e automtica possvel.
Banco de dados
Tables
Scalars
notications
Rede gerenciada +
Muitos objetos gerenciados
Clientes
DNS
Respostas,
noticaes
e informes
NMS
Gets, Sets
Para que toda essa automao seja realidade, a soluo torna-se bastante complexa,
exigindo que cada um dos processos e conhecimento seja inicialmente ensinado para o NMS
e, claro, que esse tenha em sua complexa arquitetura as aplicaes que suportam essa
inteligncia. Nesses pontos que se encontram os principais diferenciais das arquiteturas e
implementaes dos diversos NMSs do mercado.
Componentes de um sistema de gerncia:
11 Core do sistema de gerncia;

11 Interface com o usurio;
11 Banco de dados;
11 Agentes a agentes SNMP;
11 Gerao de relatrios;
11 Criao de mapas;
11 Correlao de alarmes;
11 Descoberta da rede;
11 Mdulos e Plug-ins.
A arquitetura bsica das plataformas de gerncia tem no seu ponto mais importante o
Kernel do sistema de gerncia de redes, responsvel por implementar os protocolos de
gerncia e armazenar todas as informaes coletadas em todos os agentes da rede. Essas
informaes so ento armazenas para uso pelo sistema, geralmente atravs de uma srie
de aplicativos que as processam e permitem melhor exibio para o usurio.
Vrios sistemas freeware permitem a utilizao de frontends distintos, mantendo sempre
um mesmo kernel do NMS. Um exemplo bastante comum o NAGIOS, que possui inclusive
uma verso de aplicativos e interfaces pagos, alm das inmeras implementaes gratuitas.
Essa estrutura em camadas bastante til, j que as interfaces com o usurio e aplicativos
de gerncia costumam ser bastante modificados, para incluir novas plataformas (celulares,
por exemplo) e novas funcionalidades, como novos padres de desenvolvimento web,
alm de permitirem a implementao de plataformas mais seguras, como as baseadas em
clientes proprietrios instalados nas mquinas dos prprios administradores da rede.
Outro ponto que possui variaes distintas nas NMSs e dependentes do ambiente para o
qual o sistema de gerncia foi destinado o banco de dados. Na maioria dos NMSs, ele
suportado pelos BDs mais conhecidos (exemplo: BerkeleyDB, mysql, Oracle, Postgress etc.).
Isso um ponto importante pelas caractersticas que cada um desses bancos de dados
possui, como controle de concorrncia e atomicidade, a tradio da organizao em determinado DB e o custo associado a ele.
Figura 5.6
Soluo de
gerncia SNMP.
129
Interface Grca
API
Aplicaes de gerenciamento
Descoberta de Rede
Tratamento de eventos
Ger. Congurao
MIB Browser
Monitoramento
API
Kernel do NMS
Lo
g de eventos
Protocolos
Processamento da informao
DB
Rede
Agente
Agente
Agente
Agente
MIB
MIB
MIB
MIB
Figura 5.7
A arquitetura de um
NMS e suas APIs.
Muitas plataformas de gerncia permitem customizao no ambiente do cliente atravs

do fornecimento de vrias APIs (Application Program Interface) nas diferentes camadas de
software do sistema de gerncia. Caso a customizao da soluo seja um dos objetivos
desejveis para a gerncia da rede, como fornecer uma interface de acesso do cliente a
determinados grficos atravs de um portal, esse pode ser um dos critrios relevantes na
definio da plataforma a ser utilizada.
Normalmente as plataformas possuem APIs para customizao da interface de acesso ao
cliente ou para a criao de scripts que permitam realizar tarefas como a pr-anlise e classificao de problemas antes da gerao de um determinado ticket.
Um exemplo desse processamento a definio de incidente que pode ou no ser classificado
como um problema, dependendo do horrio onde ele ocorre, ou at mesmo a programao
de tratamento de um alerta, gerando uma tarefa automtica em algum sistema/servidor,
como remover determinados arquivos de forma automtica no caso de falta de disco em uma
partio, evitando que haja queda no servio. Alguns exemplos de aplicativos desenvolvidos
a partir dessas APIs no nvel de aplicaes do NMS so o prprio MIB-browser, integrado em
130
algumas plataformas de gerncia ou outras aplicaes, capazes de receber e tratar um TRAP

SNMP que avisa da mudana de configurao de um roteador e automaticamente providencia
o salvamento desta, registrando quem a realizou e em que horrio ela foi realizada. Esse tipo
de API especialmente importante para o caso de o usurio desejar uma gerncia mais granular de sua rede, querendo a possibilidade de programar a ao da estao de gerncia para
o caso de recebimento dos diversos TRAPs enviados pelos equipamentos.
Componentes de um sistema de Gerncia:
11 Controle de SLA;
11 Descoberta automtica de topologia;
11 Arquitetura de plug-ins;
11 Suporte a mltiplos fabricantes de hardware e software;

11 Inventrio;
11 Grficos com viso da rede em camadas (fsico, enlace e rede);
11 Controle de acesso em mltiplos nveis;
11 Gerncia baseada em polticas;
11 Amplo suporte a gerncia de servios (ldap, bancos de dados diversos, www, mail etc.).
Outro ponto que diferencia muitas das solues de gerncia de redes so os inmeros aplicativos existentes, geralmente na forma de mdulos ou plug-ins que permitem o suporte a
novos hardwares, softwares e MIBs proprietrias, alm de agregar outras funcionalidades
plataforma (exemplo: sistema de inventrio).
Componentes de um sistema de Gerncia:
11 Amplo suporte a MIBs do tipo enterprise-especific;

11 Possibilidade de realizar a compilador de MIBs e definir novos objetos.
Uma plataforma de gerncia comumente possui funes que incluem:
11 A descoberta da rede;
11 Mapeamento da topologia dos elementos gerenciados;
11 Manuseio dos eventos;
11 Coleta e graficao de parmetros de desempenho.
Obtendo dados da atividade da rede

De uma forma geral, os sistemas de gerncia de redes (NMS) trabalham realizando a coleta
dos diversos dados de gerncia SNMP (traps, gets) e realizando poolings peridicos em
outros protocolos ou aplicaes (ICMP, http, ssh etc.). Essas informaes juntas espelham a
atividade da rede. Nesse ponto, algumas ferramentas tm a capacidade de coletar informaes com origem em SNMP e ICMP, enquanto em outras possvel obter informaes de
fluxos e de servios (ssh, http, https, bancos de dados, syslog etc.). De uma forma geral,
tratamento ela os faz atravs de agentes snmp padro ou se necessita que seja realizada a
instalao de um agente proprietrio no equipamento/servidor monitorado.
Descoberta da rede
11 Forma ativa.
11 Forma passiva.
A descoberta da rede um item particular de algumas plataformas e possui caractersticas
bastante diferenciadas entre as plataformas. Tem como base dois algoritmos fundamentais,
um que permite a pesquisa de forma ativa (pesquisando por servios e hosts a partir de um
conjunto de endereos IP), ou simplesmente observando o trfego de rede e descobrindo
cada um dos elementos da rede.
A forma ativa envia a informao na rede, na tentativa de descobrir cada um dos elementos,
usando vrios protocolos distintos para descobrir os dispositivos e a topologia, como ARP,
ICMP, SNMP, HTTP, SSH etc. Esses protocolos so indicados pelo administrador da rede no
importante analisar quais servios a plataforma em questo capaz de tratar, e se para esse
momento da descoberta.
131
A forma passiva se utiliza de informaes do prprio trfego coletado pela estao de

gerncia ou atravs de uma consulta a um equipamento central, como um switch ou roteador de core da rede. Atravs das informaes contidas nesse equipamento (tabelas de
rotas, tabelas ARP, informaes de interfaces, agentes RMON etc.), novos equipamentos so
descobertos e novamente sondados de forma a montar um mapa de interconexo de todos
os equipamentos da rede a partir desse ponto central.
11 Monitorao passiva de pacotes ARP: a interface fica em modo promscuo e escutando
todos os pacotes ARP, alm de construir uma lista de endereos MAC/IP. S funciona para
subredes conectadas diretamente na estao de gerncia ou de sensores espalhados
pela rede;
11 Monitorao ativa de pacotes ARP: a estao de gerncia envia pacotes IP/UDP e
monitora as respostas;
11 Scan sequencial de endereos IP com pacotes ICMP: a estao de gerncia gera vrios
pacotes ICMP (ping) tentando obter uma resposta de cada um dos IPs, na tentativa
de saber se existe ou no algum host naquele IP. Essa estratgia pouco eficiente se
utilizada de forma isolada, dado que muitos Sistemas Operacionais realizam filtragem de
ICMP para estaes de usurios.
Assim como estas, existem vrias outras estratgias de descoberta de rede. Em geral, as
melhores ferramentas do mercado possuem um algoritmo misto que utiliza ambas as estratgias para complementar as informaes nos seus bancos de dados topolgicos.
Filtrando as atividades da rede baseando-se em limiares

Outro ponto a ser observado se a plataforma em questo permite ou no a definio de
diversos limiares, e quo granular essa definio pode ser. Em algumas plataformas, possvel realizar a definio de determinados templates e associ-los a conjuntos de interfaces.
Por exemplo: possvel definir-se que nenhuma interface de longa distncia pode ficar mais
de 30 minutos com utilizao superior a 95%. Em outras plataformas, somente possvel
definir que se uma nica amostra passe de 95%, o alarme funcione. Plataformas de gerncia
que permitem a definio baseada em polticas normalmente possuem essa caracterstica.
A gerncia baseada em polticas normalmente uma aplicao parte dos NMSs.
Para as ferramentas comerciais, significa um custo adicional.
Correlao de alarmes
Eventos so informaes relevantes da atividade da rede, que podem ou no representar
uma falha, assim como uma nica falha da rede pode desencadear inmeros eventos. Cabe
plataforma de gerncia reconhecer e agrupar esses eventos de forma a definir qual o
problema em questo e, dessa forma, gerar um ou vrios alarmes para o operador da rede.
Deve portanto haver filtragem de eventos capazes de gerar alarmes:
11 Filtros baseados em limiares determinam um alarme;
11 Filtros que agrupam eventos identificando um nico alarme;
11 Filtros que associam criticidade aos eventos;
11 Filtros que configuram uma ao no caso de vrios alarmes.
Uma vez que todas as informaes das atividades da rede tenham sido devidamente
filtradas e agrupadas (exemplo: o caso de um switch que cai e deixa sem acesso vrios
servidores), os problemas gerados podem acionar um ou vrios alarmes, e a capacidade da
132
plataforma em questo de permitir ou no a correlao desses alarmes ou a definio de

uma dependncia entre esses alarmes um item valioso a ser considerado.
A correlao de alarmes, como chamado, capaz de identificar a dependncia de uma
poro da rede de um nico equipamento, filtrando vrios alarmes e gerando um nico
problema a ser tratado (exemplo: vrios servidores e servios dependem de um nico
roteador). As plataformas aqui variam na inteligncia que o software possui para detectar
sozinho essa interdependncia baseado na topologia da rede, ou que o administrador
Figura 5.8
Fluxo de
informaes dentro
de um NMS.
minimamente possa definir que essa dependncia existe, ou, ainda, em plataformas mais
simples os objetos com falhas simplesmente so colorizados na interface e cabe ao administrador entender a sua interdependncia.
Agentes
Informaes
no solicitadas
o
x
Informaes
solicitadas
x x
o
o
Lo
g de eventos
o
o
x
Atividade da Rede
Filtros com Limiar
Polticas
Eventos na Rede
Correlao de Eventos
(Filtro de agrupamento)
Problemas na Rede
(Gerando Alarmes)
Filtro de Prioridade
Topologia
3
Alarmes Priorizados
1
Noticao de Alarmes
FAX
PAGER
Registro de ocorrncias
(Trouble Tickets)
MAPA
Usurio
NMS
EMAIL
133
Priorizao de atividades
Uma vez que tenham sido agrupados os vrios alarmes, ainda h uma atividade possvel na
automatizao do tratamento dos eventos da rede: a priorizao. Essa prioridade normalmente se refere forma e a quem os eventos sero encaminhados de forma automtica.
Nesse item h vrias possibilidades, como a simples priorizao dos tickets de problema
a serem gerados para o service desk, at o controle do tempo de resoluo do problema
e escalonamento para o gestor da equipe, em caso de demora no restabelecimento do
problema. Por exemplo, caso um alarme do site WWW da empresa continue ativo mesmo
depois de uma hora fora de funcionamento, o mesmo evento encaminhado para o gerente
do service desk, para que este tambm fique cinte de que o servio encontra-se fora do ar.
A priorizao das atividades normalmente est atrelada s polticas definidas no mdulo de
polticas do sistema, e a definio prvia dos escopos para cada uma dessas falhas encontra-se
na correlao de alarmes.
Escalabilidade
11 Modelo centralizado.
11 Modelo Flat e distribudo.

11 Modelo hierrquico.
Um dos pontos importantes a observar, principalmente em redes maiores, a possibilidade
que a ferramenta escolhida possua para replicar ou manter de forma distribuda as informaes de gerncia de redes.
Em grande parte das plataformas, somente possvel gerenciar de forma centralizada. Nesse
modelo existe, somente uma estao de gerncia que realiza o pooling de todos os equipamentos e diversos objetos em cada um desses dispositivos. O problema aqui reside na
capacidade dessa plataforma de realizar todas as medies necessrias na janela de tempo
solicitada pelo administrador. Por exemplo, em uma rede 20 mil objetos gerenciveis e com
amostragem de 5 em 5 minutos necessrio que a estao de gerncia consiga realizar o
pooling em toda a rede a uma taxa aproximada de 70 objetos/segundo, o que pode ser um
tempo curto para o caso de atrasos e timeout na resposta de determinados equipamentos.
Se a escalabilidade da rede for algo relevante, importante analisar quais as outras alternativas
existentes de modelos fornecidos pelo desenvolvedor da soluo. Em geral, muitas ferramentas
tm o conceito de gerente e subgerente, permitindo a criao de uma soluo mais robusta com
estaes de gerncia redundantes e com agregadores locais (como diferentes regionais do pas
ou do continente), ou mesmo atravs de bancos de dados distribudos.
134
Figura 5.9
Modelos de
gerncia e
escalabilidade.
Centralizado
Flat
(horizontal)
Hierrquico
Usando uma anlise FCAPS na definio de um NMS

Uma abordagem que pode auxiliar na hora de se escolher uma soluo de gerncia de redes
partir da definio de quais gerncias se pretende manter na instituio, e para isso a
lembrana das gerncias de Falhas, Configurao, Contabilizao, Desempenho e Segurana
(FCAPS) so um bom ponto de sada.
Gerenciamento de congurao
Gerenciamento de performance
Figura 5.10
Escolhendo o NMS
usando FCAPS.
Gerenciamento de de falhas
Gerente de rede
Gerenciamento de segurana
Gerenciamento de contabilizao
Frequentemente, quando se analisa uma soluo de gerncia, difcil realizar uma comparao, e mais difcil ainda tentar se basear em uma anlise ou comparativos em sites
e revistas. A gerncia de redes sempre um problema de nicho de mercado, e mesmo
comparaes dentro de mesmos nichos (exemplo: educacional) podem levar definio de
produtos diferentes, por isso sempre recomendvel que a instituio faa ela mesma uma
abordagem e uma tabulao dos produtos e de suas necessidades. Uma boa sada para essa
avaliao a definio de quais gerncias a ferramenta deve manter, e as funcionalidades
esperadas dentro daquela gerncia.
Gerncia de falhas
11 Exibir graficamente as falhas da rede.
11 Permite viso em tempo real dessas falhas.
11 Permite configurar limiares.
11 Capacidade para gerenciar excees filtrando rudos na rede.
11 Permite tratar falsos positivos.
11 Desejvel que a soluo alimente diretamente um sistema de tickets com as falhas
detectadas.
Polticas
135
Um bom NMS possui uma interface clara e multinvel, que exibe qual ou quais elementos da
rede possuem problemas, permitindo configurar limiares para esses problemas (exemplo:
erros e descarte mximo em uma interface de rede).
Algo desejvel a criao de templates, como, por exemplo, circuitos de conexo de clientes
MPLS, atrelando a esse conjunto de interfaces determinados limiares de erros e descartes e,
claro, permitindo estabelecer-se excees que permitam filtrar caractersticas j conhecidas da rede, assim como de tratar falsos positivos de falhas.
Outro ponto importante no tratamento de falhas que cada falha gerada seja capaz de
Figura 5.11
Analisando uma
falha na estao
de gerncia.
gerar um registro de problemas para o tratamento de incidente, mesmo que a falha tenha
sido temporria e tenha se resolvido sem a interveno do administrador.
Geralmente voc vai querer mais do que simplesmente uma mensagem Device XX is down.
Sua soluo deve prover informaes sobre o que aconteceu antes da falha:
11 Mudanas de configurao;
11 Alteraes no inventrio de hardware;

11 Mensagens do syslog;
11 Dados sobre performance etc.
Gerncia de Contabilizao
11 Envolve o registro da utilizao dos recursos da rede;
11 Tem a funo de determinar o baseline da rede.
A gerncia de contabilizao normalmente a primeira gerncia implementada em qualquer
instituio, por conseguir responder perguntas bsicas, como: A rede no est funcionando
bem, o que est acontecendo nesse momento que no estava ocorrendo no passado?
Em geral as ferramentas para a gerncia de contabilizao so bastante simples de instalar
e configurar (cacti, mrtg, etc.) e tem como principal funcionalidade registrar a utilizao dos
recursos da rede e permitir conhecer o volume demandado em um momento de operao
normal da rede (baseline).
136
Saiba mais
Em geral, as ferramentas para a gerncia

de contabilizao so
bastante simples de
instalar e configurar
(cacti, mrtg etc.) e tm
como principal
funcionalidade registrar
a utilizao dos
recursos da rede e
permitir conhecer o
volume demandado em
um momento de
operao normal da
rede (baseline).
Um ponto importante a se observar na gerncia de contabilizao a granularidade que se

deseja manter dos dados amostrados ao longo do tempo. Em geral, muitas ferramentas no
mantm os dados histricos na forma como foram coletados, mas sim utilizam algoritmos
que o resumem em estatsticas por horas ou dias, dessa forma armazenando as mdias
por intervalos de tempo das amostras para facilitar a graficao dos dados (exemplo: mrtg e
rrdtool). Caso sua necessidade aponte para manter as sries histricas assim como foram
coletadas em cada perodo, necessrio observar o comportamento da ferramenta em
anlise e considerar que esses dados consomem recursos no desprezveis de armazenamento em banco de dados e em recursos computacionais para visualizar esses mesmos
dados (CPU e memria da estao de gerncia). Praticamente todas as solues de gerncia
integradas realizam a gerncia de contabilizao, cabendo somente ao administrador
determinar o perodo de tempo que a srie histrica ser mantida (um ano, um ms).
Gerncia de Configurao
Analisando a configurao dos elementos gerenciveis, voc vai desejar informaes de
inventrio para facilitar a abertura de chamados.

11 Hardware: tipo de dispositivo, portas, mdulos, memria RAM e Flash.
11 Dados do bem: part number, nmero serial.
11 Dados do contrato: suporte, SLA, id do circuito etc.
Uma boa ferramenta de gerncia de configurao permitir obter esses dados em
tempo real.
Para uma rede sem nenhuma gerncia, a gerncia de configurao acaba por ser algo para
um segundo momento. Entretanto, se o seu levantamento inicial apontou-a como algo
necessrio para a sua instituio, importante consider-la com cuidado na sua definio
de ferramenta. Normalmente, ela uma gerncia de implementao particularmente difcil,
se considerada a diversidade de equipamentos na instituio. Outro ponto relevante aqui
se ela vai se ater somente aos ativos de rede ou a todos os servidores (hardware e software),
backup e configurao dos Sistemas Operacionais e servios destinados ao usurio final.
Figura 5.12
Ferramentas
para gerncia de
contabilizao.
137
Ento, aqui especialmente importante que se faa essa definio.

Caso tenha havido algum problema devido a mudana de configurao voc deve
facilmente:
11 Apontar qual a alterao que causou o problema;
11 Saber quem foi o responsvel pela mudana;
11 Conseguir rapidamente reverter as configuraes conforme necessrio.
Em alteraes na rede, deve ser possvel:
11 Fazer mudanas de configurao simultaneamente em um grande nmero de dispositivos;
11 As alteraes devem realimentar algum tipo de contabilizao ou gerenciador de
mudanas;
11 Deve ser possvel manter um histrico dessas mudanas de forma a poder revert-las
em caso de necessidade.
Figura 5.13
Gerncia de
configuraes
com o Cisco Config
Manager.
Gerncia de Performance
22 Capacidade de estabelecer uma baseline com thresholds que notifiquem quando a
performance comear a cair.
22 Devemos conseguir analisar uma performance vertical abordando o servio
fim-a-fim atravs de toda a rede:
33 Por exemplo: se existe servio de VOIP, seu NMS deve conseguir medir a qualidade de voz, jitter, latncia etc.
33 Se voc usa marcao de QoS, deve ser possvel visualizar a quantidade de
trfego que est sendo classificada em cada uma das categorias. Nesse caso,
voc pode desejar caractersticas como Netflow e IP-SLA.
138
A gerncia de desempenho demanda um esforo adicional de configurao por parte do

gerente da rede. Embora alguns problemas possam ser detectados automaticamente
como o caso da gerncia de falhas, a gerncia de desempenho tem suas prprias nuances.
Em geral necessrio que o administrador estabelea quase que individualmente para
elemento, ou classe, determinando quais os limites aceitveis para o desempenho e em que
casos as violaes sero consideradas uma falha pelo administrador. Um exemplo tpico
dessa dificuldade o uso de uma partio do disco rgido: em um disco de 2GB de dados, 91%
de uso algo preocupante, j em uma partio de 10TB, ter somente 9% de espao disponvel
dificilmente geraria um alarme e seria considerado falha. Provavelmente s seria considerado
no relatrio de crescimento normal dos dados e exigiria ateno no curto ou mdio prazo.
Network Management Systems disponveis no mercado

Existe uma gama muito grande de plataformas de gerncia de rede no mercado. Como
uma avaliao simplificada dessas plataformas comerciais, podemos dividi-las entre as
grandes e modulares plataformas, geralmente na faixa de centenas de milhares de dlares,
as plataformas mdias, tambm modulares e na faixa de alguns milhares de dlares, e as
plataformas menores, geralmente gratuitas, fornecidas por algum fabricante de hardware
ou mesmo custando algumas centenas de dlares.
NMSs comerciais.
11 Plataformas de alto custo:
22 Bastante completas e modulares;
22 Alta escalabilidade e customizao;
22 Custo na ordem de centenas de milhares de dlares;
22 Exemplo: HP-IMC, HP-NMM, Spectrum.
11 Plataformas de mdio custo:
22 Completas para determinadas tarefas;
22 Alguma escalabilidade;
22 Customizao limitada.
Figura 5.14
Gerncia de
desempenho.
139
11 Plataformas gratuitas ou de baixo custo:
22 Funcionalidade limitada a determinados equipamentos ou tipo de gerncia;

22 Em geral, somente permitem gerncia centralizada (menos de 10 mil objetos);
22 Algumas possuem limitaes diversidade de equipamentos;
22 Em geral, atendem somente a um tipo de gerncia especfica e necessita ser complementada com outras ferramentas (mltiplas gerncias).
HP IMC Intelligent Management Center

O HP-IMC tem sua origem nos antigos softwares de gerncia especializada para equipamentos da 3Com e HP-Procurve. Em sua evoluo natural, restam hoje poucas diferenas
em relao a outro software da mesma empresa, o HP-NNM. Normalmente, o HP-IMC tem
maior cunho tcnico e voltado para empresas mdias e pequenas, enquanto o HP-NNM
possui melhor escalonamento para grandes empresas.
Apesar da sua origem, hoje um produto voltado para redes heterogneas e possui uma
arquitetura voltada a servios (SOA).
Entre os diferentes tipos de gerncia e caractersticas dessa ferramenta, podemos citar:
11 Suporte a Linux e Windows;

11 Interface web para acesso;
11 Gerncia de falhas e performance com ICMP e SNMP;
11 Gerncia de configurao (backup, restore e comparao de verses).
11 Interface com diferentes CLI de equipamentos para administrao de VLANs e ACLs;
11 Permite a criao de topologias L2 e L3 entre os diversos elementos da rede;
11 Escalabilidade com um modelo hierrquico;
11 Captura e anlise de flows (netflow);
11 Captura e anlise de LOGs (syslog);
11 Gerncia de virtualizao (VMWare e Hyper-V);
11 Descoberta automatizada da rede;
11 Suporte a redes SDN (exemplo: openflow).
O software possui vrias novidades, alm das conhecidas em todas as outras plataformas,
como permitir que o datacenter seja desenhado em 3D e se tenha a viso dos equipamentos
nos seus racks, integrados topologia da rede e mostrando quais dos equipamentos
possuem algum tipo de alarme.
140
w
Existe uma verso de
testes (60 dias),
disponvel em
http://h17007.www1.
hp.com/us/en/
networking/products/
network-management/
IMC_ES_Platform/
(AVA).
HP NNM: Network Node Manager

11 Sucessor do antigo HP-Openview.
11 Software comercial com verso free para at 25 nodos.

11 Plataforma com suporte a Business Service Management (BSM).
11 Unifica vrias gerncias.
11 Altamente customizvel.
11 Escalvel.
11 Plataforma Modular.
22 Extensa lista de plug-ins.
O HP-NNM tem a sua origem em um dos primeiros e mais difundidos NMSs, o HP-Openview.
Ele teve grande parte do seu cdigo reescrito e hoje em dia possui todas as suas antigas funcionalidades em um sistema baseado em web, podendo ser instalado em sistemas Windows
e Linux (Debian e RH). A HP permite o acesso a uma verso freeware do NNM para at 25
dispositivos em http://www.hp.com/go/nnm. O HP-NNM um dos mais completos sistemas
de gerncia de rede do mercado, voltado para grandes empresas com um foco maior em
Business Service Management (BSM), embora o seu sistema bsico seja semelhante a todos
os outros sistemas de gerncia (ICMP, SNMP, RMON etc.).
Dentre as funcionalidades do software, podemos citar:
11 Instalao possvel em Linux e Windows, com interface de gerncia web;
11 Gerncia de Falhas com ferramentas automatizadas para a anlise (exemplo: roteamento, hardware etc.);
11 Descoberta da Rede e mapeamento da topologia camada 2 e camada 3;
11 Gerncia de performance e gerao de relatrios automatizados para SLA e outros;
11 Gerncia de Configurao e integrao com outras ferramentas (CiscoWorks LMS etc.);
11 Anlise de LOGs e Flows (Netflow);
11 Possibilidade de criao de scripts para o tratamento automatizado de alertas;
Figura 5.15
Interface
do HP-IMC
(fonte: http://
packetpushers.
net/review-hpimc-intelligentmanagementcenter/ ).
141
11 Suporte a milhares de diferentes dispositivos;
11 Suporte a gerncia de protocolos Multicast e IPv6;

11 Plataforma modular, com suporte criao de iSPIs (Plug-in), como para controle de
telefonia de vrios fabricantes.
Figura 5.16
Interface do
HP-NNM (fonte:
http://www8.
hp.com/us/en/
software-solutions/
network-nodemanager-i-networkmanagementsoftware/)
SNMPc da Catlerock
11 Possui suporte a SNMPv1, v2 e v3.
11 Gerncia remota via cliente Windows e Java.

11 Visualizao da MIB em tempo real.
11 Compilador de MIBs.
11 Gerao automtica de relatrios dirios, semanais e mensais.
11 Interface programvel.
11 Estrutura distribuda.
11 Descoberta de rede automtica.
O SNMPc uma ferramenta de gerncia para redes SNMP, que tem como diferencial a ideia
de coletar e gerenciar informaes em tempo real para hubs, switches, roteadores e servidores, funcionando como um painel de controle da rede para um administrador individual.
Ela permite salvar os dados em tempo real, gerando relatrios e alarmes sonoros, e-mails e
SMSs em casos de falhas.
142
WhatsUp da IPSwitch
11 Descoberta e atualizao automtica dos mapas da rede.
11 Suporte a redes wifi.

11 Arquitetura distribuda podendo atender vrios datacenters.
11 Gerncia centralizada.
11 Escalabilidade para mais de 20 mil dispositivos.
11 Suporte a SNMP e WMI.
Outra ferramenta de custo razovel para gerncia de redes pequenas, mdias e de datacenters com mais de 15 anos no mercado de gerncia. Possui foco na gerncia de infraestrutura,
como switches, roteadores, servidores e redes wifi.
Figura 5.17
Interface do SNMPc
(fonte: www.
castlerock.com).
143
OPManager, da ManageEngine
11 Plataforma modular com suporte a Netflow, IP-SLA etc.
11 Descoberta de rede automtica.

11 Permite a criao de mapas fsicos, L2 e L3.
11 Monitoramento de servios.
11 Interface totalmente web.
11 Suporte a vrios plug-ins.
11 Suporte a VOIP e Virtualizao.
11 Gerao automtica de relatrios.
Essa ferramenta na realidade parte de um sute de ferramentas de gerncia de TI, servindo
como uma alternativa para as principais ferramentas do mercado (HP, IBM e CA). Em uma
verso gratuita, permite gerenciar at 10 dispositivos. Na verso bsica, a ferramenta
144
acessvel custando a partir de R$ 10 mil.
Figura 5.18
WhatsUP Gold
(fonte: www.
whatsupgold.com).
Figura 5.19
OPManager
(fonte: http://www.
manageengine.
com/).
145
146
6
objetivos
Aplicaes e plataformas de
gerncia em software livre
Conhecer as solues em Software Livre para gerncia, Descrever o Framework FCAPS.
Conhecer as caractersticas das ferramentas livres disponveis.
conceitos
Solues OSS/FS, Framework FCAPS, Ferramentas livres, Zabbix, Nagios, OpenVAS,

OCS Inventory, Spice Works, NTOPng.
Solues OSS/FS
Permite ao usurio executar o programa para qualquer propsito. Entre os principais
projetos OSS/FS, destacam-se:

11 Linux kernel, Apache, Samba, GNOME, GIMP, MySQL, PostgreSQL, PHP, XFree86, bind,
Mozilla e OpenOffice.org.
Na rea de gerenciamento rede, existem grandes projetos open source:
Solues OSS/FS (Open Source Software/Free Software) para gerenciamento substituem

solues monolticas de fabricantes atravs de uma abordagem modular. Isso permite que
seja montado somente o necessrio, de acordo com as especificaes, sem necessidade de
adquirir sistemas completos e caros.
Solues OSS/FS so desenvolvidas de forma aberta; por isso, normalmente so aderentes
a padres. Essa caracterstica facilita a interoperabilidade e futuras evolues. Alm disso, o
w
Para saber mais:
http://www.gnu.org/
philosophy/free-software-for-freedom.html
mundo de software aberto garante total transparncia no processo de evoluo, garantindo

que os verdadeiros usurios dos sistemas ditem os rumos do software.
Na rea de sistema de gerenciamento existe grande potencial de trabalho conjunto das
comunidades de software aberto com empresas e grandes clientes interessados em boas
alternativas para sistemas de gerenciamento, que pesam muito no oramento.
A gesto global dos recursos de tecnologia da informao de uma organizao um requisito
fundamental. Funcionrios e clientes necessitam e contam com os servios de TI, onde a
disponibilidade e o desempenho so obrigatrios, e os problemas devem ser rapidamente
identificados e resolvidos, diminuindo, assim, o tempo mdio para reparo (MTTR).
Captulo 6 - Aplicaes e plataformas de gerncia em software livre
11 Nagios, OpenNMS, OpenQRM, Zenoss, Netdisco, Ntop, Cacti etc.
147
Framework FCAPS
Framework Fault, Configuration, Accounting, Performance e Security (FCAPS).
11 Desenvolvido pela International Organization for Standardization (ISO).

11 Tem como objetivo definir um modelo de gesto de recursos de telecomunicaes e
de rede.
11 Serve como base para os demais modelos de gesto, como: TMN, OAMP&P, TOM,
CMIP/CMIS, ITIL etc.
Na rea de sistema de gerenciamento existe grande potencial de trabalho conjunto das
comunidades de software aberto, com empresas e grandes clientes interessados em boas
alternativas para sistemas de gerenciamento, que pesam muito no oramento.
A gesto global dos recursos de tecnologia da informao de uma organizao um requisito fundamental. Funcionrios e clientes necessitam e contam com os servios de TI, onde
a disponibilidade e o desempenho so obrigatrios, e os problemas devem ser rapidamente
identificados e resolvidos, diminuindo, assim, o tempo mdio para reparo (MTTR).
O framework Fault, Configuration, Accounting, Performance e Security (FCAPS) foi desenvolvido pela International Organization for Standardization (ISO) e tem como objetivo definir
um modelo de gesto de recursos de telecomunicaes e de rede. Esse modelo serviu
de base para todos os demais modelos de gesto (como exemplo: Telecommunications
Management Network TMN; Operation, Administration, Maintenance and Provisioning
OAM&P; Telecom Operations Map TOM; Common Management Information Protocol/
Common Management Information Service CMIP/CMIS; e outros) por definir as reas
funcionais da gerncia de redes, que so: a gerncia de falhas, a gerncia de configurao, a
gerncia de contabilidade, a gerncia de desempenho e a gerncia de segurana.
Seguindo o framework FCAPS, abordaremos cada uma das reas funcionais apresentadas,
sugerindo ferramentas que atendam suas necessidades.
Gerncia de Falhas (Fault)

O objetivo do gerenciamento de falhas reconhecer, isolar, corrigir e registrar as falhas
que ocorrem em uma rede. Seus principais componentes so:
11 Deteco de Falhas.
11 Notificao.
11 Tendncia.
11 Registro.
148
11 Resposta.
Uma falha um evento que tem um significado negativo. O objetivo do gerenciamento de
falhas reconhecer, isolar, corrigir e registrar as falhas que ocorrem em uma rede.
Seus principais componentes so:
11 Deteco de Falhas: capacidade de reconhecer um erro quando ele ocorrer;
11 Notificao: capacidade de notificar quando a falha ocorre;
11 Tendncia: permitir a configurao de uma linha de base sobre a operao normal do
dispositivo, com o objetivo de detectar desvios ou situaes anormais;
11 Registro: registrar todas as falhas para contabilidade e auditoria futura;
11 Resposta: podendo ser humana ou automatizada.

Alguns exemplos de ferramentas proprietrias so: EMC Smarts, CA Spectrum, HP Network
Node Manager i, IBM Tivoli Network Manager, WhatsUpGold etc.
Para um gerenciamento de falhas bsico, existem vrias ferramentas no mundo livre para a tarefa:
11 CACTI: gerao de grficos a partir de dados de rede com RRDTool
(http://www.cacti.net);
11 Etherape: traa grficos da atividade de rede em formato web
(http://etherape.sourceforge.net/);
11 Flow-tools: ferramentas para tratamento de dados netflow
(http://code.google.com/p/flow-tools/);
11 fprobe: obtm dados do trfego e exporta-os em formato netflow (Cisco)
(http://sourceforge.net/projects/fprobe/);
11 Microsoft Network Monitor: software de captura de pacotes para anlise. Muito parecido com o Wireshark, sua diferena possibilitar realizar filtros de captura pelo nome do
servio que est gerando trfego no host local
(http://www.microsoft.com/en-us/download/details.aspx?id=4865);
11 monit: monitoramento em formato web e disparo de aes em funo das respostas
obtidas (http://mmonit.com/);
11 MRTG: traa grficos de informaes SNMP obtidas de dispositivos de rede. Possui
verses Windows e Linux (http://oss.oetiker.ch/mrtg/);
11 Munin: estatsticas de trfego em formato web (http://munin-monitoring.org/);
11 Net-SNMP: conjunto de aplicaes usadas para implementar o protocolo SNMP verses
1, 2c e 3 (http://www.net-snmp.org/);
11 NETXMS: software para Windows (desktop) e Linux (web) para gerncia de dispositivos e
alertas, com possibilidade de criao de grficos (http://www.netxms.org/);
11 ntopng: sonda (probe) de monitoramento de trfego que mostra a utilizao da rede.
11 RRDTool: ferramentas para armazenamento de dados e criao de grficos
(http://oss.oetiker.ch/rrdtool/);
11 SNMPTT: tradutor de traps SNMP escrito em Perl, que utiliza os programas
Net-SNMP/UCD-SNMP e snmptrapd (http://www.snmptt.org/);
11 SpiceWorks: ferramenta para Windows gratuita para gerenciamento de hosts, que
possibilita a incluso de novos plug-ins gratuitos. (http://www.spiceworks.com);
11 The Dude: ferramenta para Windows de fcil utilizao, para criao de mapas e monitoramento de dispositivos (http://www.mikrotik.com/thedude).
Gerncia de configurao (Configuration)

Responsvel pelo registro e manuteno da configurao dos dispositivos/servios de
uma rede. Seus principais componentes so:
11 Coletor.
11 Depsito.
11 Trilha.
11 Automatizao.
Apresenta os dados em formato web (http://www.ntop.org/products/ntop/);
149
A gerncia de configurao responsvel pelo registro e manuteno dos parmetros de

configurao dos dispositivos/servios de uma rede, tendo como principal objetivo controlar
mudanas e configuraes, documentando todo o ciclo de vida de um sistema de informao.
11 Coletor: rene configuraes de todos os ativos monitorados;
11 Depsito: local onde so armazenadas as configuraes dos dispositivos, para fins de
cpia de segurana e recuperao;
11 Trilha: monitorar e relatar alteraes nas configuraes;
11 Automatizao: capacidade de fazer, automaticamente, alteraes de configurao em
vrios dispositivos, sem interferncia de um usurio.
So exemplos de solues proprietrias: HP Procurve Manager e Cisco Prime. Exemplos de
solues open source:
11 Configurador Automtico e Coletor de Informaes Computacionais (CACIC):
ferramenta de inventrio desenvolvida pelo governo brasileiro. Suporta gerao automtica de inventrio detalhado de estaes Windows e Linux. (http://www.softwarepublico.
gov.br/en/ver-comunidade?community_id=3585);
11 NetCanner: uma ferramenta de gerenciamento de configurao que pode ser utilizada
para mostrar as configuraes dos dispositivos e suas relaes com outros dispositivos
da rede (http://bangj.com/);
11 OCSInventory: ferramenta de inventrio de hardware e software para estaes Windows
e Linux (http://www.ocsinventory-ng.org/);
11 OneCMDB: soluo Configuration Management Database (CMDB) compatvel com

frameworks de tecnologia, como ITIL/COBIT (http://www.onecmdb.org);
11 Puppet: framework utilizado para gerenciamento de configurao e armazenamento
centralizado de dados (http://www.puppetlabs.com/);
11 Rancid: ferramenta para gerncia de configurao de roteadores de diversos fabricantes.
Faz uso de um controle de verso (exemplo: CVSweb) para sinalizar e mostrar alteraes
de configurao (http://www.shrubbery.net/rancid/);
11 Webmin: uma interface web de administrao de sistemas Unix/Linux. permitida a
configurao de inmeros itens dos sistemas (contas de usurios, configurao de servios
como Apache, DNS, compartilhamento de arquivos etc. http://www.webmin.com/).
Gerncia de contabilidade (Accounting)

Responsvel por coletar estatsticas e us-las para definir ou auditar cotas de utilizao,
150
medir ou regular o uso de um servio ou dispositivo. Seus principais componentes so:

11 Gerenciamento de contas, senhas e permisses.
11 Sistema de logs de auditoria.
11 Execuo de cpias de segurana de dados crticos.
Gerncia responsvel por coletar estatsticas de uso dos usurios e usar estas estatsticas
para definir/auditar cotas de utilizao, medir ou regular o uso de um servio/dispositivo.
Uma lista de exemplos

de ferramentas open
source para gerenciamento de configurao
est disponvel para
consulta em: http://en.
wikipedia.org/wiki/
Comparison_of_open_
source_configuration_
management_software.

11 Gerenciamento de contas, senhas e permisses.
22 Servios de diretrios: Microsoft Active Directory, OpenLDAP etc.;
22 Autenticadores: TACACS e FreeRADIUS etc.;
22 Sistemas de armazenamento de senhas: Keepass (http://keepass.info/), Password
Manager Pro (www.manageengine.com/products/passwordmanagerpro/).
11 Sistema de logs de auditoria:
22 Sistema de auditoria bsica disponvel no Windows (Event Viewer) e Linux (syslog);
22 Syslog-ng: Log: consolidao, anlise e envio atravs de rede de logs (http://www.
balabit.com/network-security/syslog-ng);
11 Execuo de cpias de segurana de dados:
22 Microsoft System Center Data Protection Manager e Symantec;
22 Backup Exec and Veritas Netbackup;
22 Windows backup and restore;
22 Amanda (http://www.zmanda.com/);
22 Bacula (http://www.bacula.org/en/).
Gerncia de desempenho (Performance)

Responsvel pela medio e disponibilizao das informaes sobre aspectos de desem-
penho dos servios de rede. Seus principais componentes so:

11 Coleta de Dados.
11 Visualizao.
11 Anlise de Tendncias.
11 Sumarizao.
A gerncia de desempenho responsvel pela medio e disponibilizao das informaes
que a rede opere em conformidade com a qualidade de servio acordado com seus usurios. Tambm so usados para anlise de tendncia.
11 Coleta de Dados: armazena informaes de desempenho para recuperao;
11 Visualizao: transforma dados coletados em imagens para uma rpida compreenso;
11 Anlise de Tendncias: monitora dados com o objetivo de reconhecer padres de
comportamento;
11 Sumarizao: consolida os dados e informaes sobre dispositivos ou servios.
Tipos de ferramentas open source para gerncia de desempenho:
11 Medio de Desempenho: Cacti, MRTG e SmokePing;
11 Anlise Forense: Wireshark, NTOP, Netstumbler e TCPDump;
11 Gerador de Carga: Iperf, D ITG e Internet 2 NDT.
sobre aspectos de desempenho dos servios de rede. Esses dados so usados para garantir
151
Gerncia de segurana (Security)

Responsvel por restringir o acesso rede e impedir o uso incorreto por parte dos usu-
rios. Seus principais componentes so:

11 Polticas e procedimentos.
11 Sistemas de varredura de vulnerabilidades.
11 Segurana fsica.
11 Firewalls.
11 Antivrus, Trojan e proteo contra cdigos do tipo Malware.
Gerncia responsvel por restringir o acesso rede e impedir o uso incorreto por parte de
seus usurios, de forma intencional ou no.
11 Polticas e procedimentos;
11 Sistemas de varredura de vulnerabilidades;
11 Segurana fsica;
11 Firewalls;
11 Antivrus, Trojan e proteo contra cdigos do tipo Malware.
A rea de segurana vasta e possui muita complexidade. Realizar gerenciamento de segurana tarefa para especialistas.
So citadas a seguir algumas ferramentas populares no mundo livre:
11 BackTrack: distribuio Linux utilizada para testes de penetrao e percia forense
(http://www.backtrack-linux.org/);
11 Nmap: scanner de servios em rede. Pode varrer servios de vrias formas e at encontrar detalhes dos servidores que os implementam (http://nmap.org/);
11 The Open Source Security Infrastructure Management System (OpenSIMS): conjunto
de vrias ferramentas de segurana agregadas em um nico pacote
(http://opensims.sourceforge.net/);
11 OpenVas: scanner de vulnerabilidades em servios derivado do Nessus
(http://www.openvas.org/);
11 Osiris: Monitor de integridade de sistemas. Detecta mudanas ocorridas em arquivos do
Sistema Operacional (http://osiris.shmoo.com/);
11 Ossec: Monitor de integridade de sistemas. Detecta mudanas ocorridas em arquivos de
152
instalao e anlise de logs (http://www.ossec.net/);

11 Snort: IDS e sniffer (http://www.snort.org/);
11 Mais ferramentas para segurana: http://sectools.org/
Ferramentas livres
At o momento, foram relacionadas ferramentas disponveis para cada uma das reas
do FCAPS, com o intuito de contribuir com maior proximidade entre essas solues e as
necessidades existentes. Sero abordadas nesse tpico a instalao e a utilizao bsica
das ferramentas que abordam mais de uma rea do FCAPS ou que possuem grande
quantidade de usurios em suas comunidades. So elas:
11 Zabbix.
11 Nagios.
11 OpenVas.
11 SpiceWorks.
11 NTOP.
11 OCSInventory.
Alguns dos sistemas livres para gerenciamento j possuem certa sofisticao e funcionalidades avanadas, que os tornam indicados para vrios cenrios de gerenciamento. Qualquer lista atual conteria algumas das opes:
11 Zabbix: software que permite a monitorao de aplicaes e servios, podendo ser
usado para registrar, monitorar, planejar capacidade, disponibilidade e performance dos
ativos de uma rede (http://www.zabbix.com/);
11 Nagios: popular aplicao de monitorao de rede que permite monitorar tanto hosts
quanto servios, alertando-o quando ocorrerem problemas e tambm quando os problemas forem resolvidos (http://www.nagios.org/);
11 OPenVas: software que possui um repositrio on-line atualizado de vulnerabilidades, as
quais podem ser verificadas nos hosts escolhidos pelo usurio. Ao final do procedimento,
a ferramenta informa qual a severidade das vulnerabilidades encontradas por host;
11 SpiceWorks: ferramenta web para Windows gratuita, permite o Discovery da rede,
realizando inferncias por ICMP, WMI e SNMP. Possui comunidade ativa, que desenvolve
11 Ntop: ferramenta que captura e analisa os fluxos da rede, gerando estatsticas grficas
dos maiores fluxos capturados;
11 OCSInventory: soluo de gerenciamento de configurao que centraliza em uma nica
ferramenta todas as informaes de servidores e estaes da rede. necessrio instalar
um cliente nos hosts a serem inventariados, podendo ser Windows, Linux, Android,
Windows Mobile e MacOS.
Zabbix
O Zabbix uma soluo livre de NMS, sob licena GPL, com monitoramento de dispositivos
SNMP e outros, gerao de alarmes e alertas, grficos de desempenho, armazenamento em
w
Seu site oficial (com
Wiki, documentao e
frum com postagens):
http://www.zabbix.org/
base MySQL ou Postgres.

O servidor deve ser uma mquina Linux que monitora sistemas clientes em diferentes plataformas e elementos de rede. Um recurso til do Zabbix a criao de templates de mquinas.
Usando esses templates, possvel herdar caractersticas comuns e personalizar dispositivos.
Seu funcionamento atestado em vrias distribuies Linux, sendo que em muitas delas j
h pacotes de instalao prontos.
plugins, possibilitando, por exemplo, a gerao de grficos ou o envio de SMS;
153
Caractersticas do Zabbix:
11 Escalvel (testado com 5 mil dispositivos, com vrios tipos de verificao por segundo);
11 Monitoramento em tempo real (desempenho, disponibilidade e integridade);
11 Flexveis de alerta (e-mail, SMS, avisos sonoros e comandos remotos);
11 Gerao de relatrios e estatsticas;
11 Fcil integrao com outros mdulos de terceiros;
11 Service Level Management (SLM), servios de TI hierrquicos e relatrios;
11 Uso de agentes extensveis para vrias plataformas (Unix/Linux, Windows e MacOS);
11 Execuo automtica de comandos remotos;
11 Monitoramento com e sem agentes (IPMI, SNMP e traps);
IPMI
11 Segurana (permisso de usurios e autenticao por IP);
Intelligent Platform
Management Interface
um frontend WEB
para gerenciamento
remoto. Exemplos so:
IMM, da IBM; iLO,
11 Fcil administrao: configurao centralizada e documentao on-line.
Instalao do Zabbix
11 Acesse o Terminal;
11 Execute o comando a seguir para acessar o terminal como usurio root, informando a
sua senha;
sudo su
11 Atualize os pacotes do seu Ubuntu:
apt-get update
11 Instale os pacotes necessrios para o Zabbix (ser instalado o Apache, o MySQL e o PHP).
Informe a palavra root como senha do mysql.
apt-get install apache2 php5 libapache2-mod-php5 mysql-server mysqlclient php-pear libgd-tools libipc-sharedcache-perl lm-sensors php5-mysql
11 Baixe e instale o Zabbix-server:
wget http://repo.zabbix.com/zabbix/2.2/ubuntu/pool/main/z/zabbixrelease/zabbix-release_2.2-1+trusty_all.deb
dpkg -i zabbix-release_2.2-1+trusty_all.deb
apt-get update
11 Instale e configure a conexo do Zabbix com o mysql. Nesse procedimento, pedido o
usurio/senha do Mysql (root/root) e a senha para o front-end (zabbix):
apt-get install zabbix-server-mysql zabbix-frontend-php
154
11 Edite o arquivo de configurao do PHP e coloque as informaes a seguir:
gedit /etc/php5/apache2/php.ini
max_execution_time = 300
memory_limit = 128M
post_max_size = 16M
upload_max_filesize = 2M
da HP; DRAC, da Dell.
max_input_time = 300
date.timezone = America/Sao_Paulo
11 Instale o Zabbix Agent, processo responsvel pela coleta das informaes:
apt-get install zabbix-agent

11 Habilite o Zabbix Server no Apache:
ln -s /etc/zabbix/apache.conf
/etc/apache2/conf-enabled/zabbix.conf
11 Reinicie o servio do Zabbix e do Apache:
service apache2 restart

service zabbix-server restart
11 Abra um Browser em sua mquina virtual e acesse o site a. O usurio padro admin e
a senha zabbix:
Utilizando o Zabbix
O Zabbix est estruturado por:
11 Hosts: so os objetos a serem gerenciados;
11 Itens: so os itens de monitorao do Hosts;
11 Templates: possui as configuraes de que itens sero gerenciados pelo host;
11 Trigger: so regras associadas aos itens, as quais so criadas dentro de hosts ou
templates para gerar alertas;
11 Discovery rules: so regras para detectar determinados itens em um host;
11 Actions: so aes atribudas para triggers que possam executar comandos, como execuo de script, envio de SMS, e-mail etc.
Em nosso exemplo, utilizaremos a monitoria por SNMP. Para realizar isso, primeiramente
precisamos configurar um template com a nossa comunidade SNMP, que ser atribudo a
um Host.
Template SNMP Device, conforme a figura 6.1.
Figura 6.1
Visualizao e
configurao de
templates.
Na prxima tela, clique em Full clone para gerar uma cpia desse template, conforme a
figura 6.2.
11 Acesse Configuration > Templates em sua interface do Zabbix e clique sobre
155
11 Altere o nome do template a clique em Save. Em nosso exemplo, escolhemos o nome

Template_SNMP Device_RNP_ESR.
11 Voc ser encaminhado para a tela anterior, mas agora aparecer seu novo template.
Sobre esse template, clique em Items, conforme a figura 6.4.
156
11 Na tela dos items, selecione todos os itens clicando no canto superior esquerdo e
escolha a opo Mass update, como mostrado na figura 6.5.
Figura 6.2
Gerao de cpia
de template.
Figura 6.3
Cpia de template.
Figura 6.4
Listagem de
templates.
Figura 6.5
Execuo de
update nos itens de
um template.
11 Escolha a opo SNMP community e altere a comunidade para esr-rnp, como mostrado
Figura 6.6
Alterao dos itens
de um template.
11 Terminada a etapa de configurao do template, podemos adicionar nossos hosts

utilizando a comunidade configurada. Para isso, acesse o menu Configuration > Hosts
e clique em Create Hosts, na parte superior direita.
11 Nesta interface, informe o nome do dispositivo, os grupos os quais esse dispositivo faz
parte, seu FDQN, IP e principalmente a porta de gerncia, que em nosso exemplo a
porta do SNMP (161).
na figura 6.6.
157
158
11 Na segunda aba, inclua o template cadastrado anteriormente e salve seu host.
Figura 6.7
Incluso de host
no Zabbix.
11 Agora possvel verificar o status de nossos servidores. Observe que a coluna Availabity
Figura 6.8
Incluso de host
no Zabbix.
(figura 6.9) mostra como a coleta das informaes de nossos hosts realizada.
No exemplo, o servidor1 est monitorado por SNMP, enquanto o Zabbix server est
sendo monitorado pelo Zabbix Agentd.
Nagios
Ferramenta que atende a Fault e Performance no modelo FCAPS. Entre suas principais
caratersticas, podemos destacar:
11 Deteco rpida de falha de infraestrutura;
11 Mais de 10 anos de desenvolvimento ativo;
11 Escalas para monitorar milhares de ns;
11 Monitora servios de rede (SSH, SMTP, POP3, HTTP, NNTP, ICMP e SNMP) e possibilita a
integrao de plugins para monitoria de outros servios;
11 Monitorao remota suportada atravs de tneis criptografados SSH ou SSL;
11 Checagem dos servios paralelizados;
11 Possibilidade de criao de mapas;
11 Rotao automtica de log;
11 Suporte para implementao de monitorao redundante;
11 Software Open Source;
11 Lanado sob a licena GPL;
11 Alertas por SMS;
11 Interao com Banco de Dados;
11 Possibilita a utilizao de outros frontends, incluindo solues para mobile.
Existem outras ferramentas que integram novas interfaces e funcionalidades utilizando o
nagios, como por exemplo o Centreon.
Instalao do Nagios
11 Para instal-lo, siga os procedimentos a seguir:
apt-get install nagios3

11 Durante a instalao, ser solicitado a senha de administrao do Nagios. Digite admin;
11 Para acessar o nagios, digite no seu browser web o endereo: http://localhost/nagios3
com usurio nagiosadmin e senha admin;
11 Se o servio no responder, verifique se o apache est em execuo;
Figura 6.9
Hosts monitorados
pelo Zabbix.
159
11 Para ativar o Nagios, digite:
a2enconf nagios3
etc/init.d/apache2 start
Customizaes do software
11 Nesta etapa, vamos realizar algumas configuraes bsicas do software Nagios. Para
isso, siga atentamente os passos a seguir.
22 1. Definir um dispositivo a ser monitorado: (Mquina Virtual do Professor);
22 2. Definir os servios que sero monitorados;
22 3. Inserir o dispositivo em um grupo de monitorao.
1. Definindo um dispositivo e seus servios:
Edite o arquivo a seguir, inserindo as linhas informadas, alterando de acordo com sua estrutura de rede:
gedit /etc/nagios3/conf.d/servidor1.cfg
;------ inicio
; Define uma estao a ser monitorada
define host{
use generic-host ; Nome do template ( template definido no arquivo
generic-host_nagios3.cfg
host_name <SERVIDOR1.DOMINIO> Nome do host a ser monitorado
alias <SERVIDOR1> Apelido do host a ser monitorado
address <IPSERVIDOR> Endereo IP do host
parents localhost Hierarquia utilizado para traar o grfico veja
a aba Status Map no menu do Nagios
hostgroups esr, all Grupos que a estao faz parte
notification_interval 120 Tempo entre notificaes
notification_period 24x7 Perodo que as notificaes sero
enviadas
notification_options d,u,r Eventos que geram notificaes down,
160
unreachable, and recovered

contact_groups admins Para aonde as notificaes sero enviadas e
como (mail, pager) veja arquivo contact_groups
}
2. Definindo um servio a ser monitorado. Incluindo as linhas a seguir no mesmo arquivo:
define service {
service_description SNMP
use generic-service ;
host_name SERVIDOR1.DOMINIO ; host a ser monitorado
service_description snmp
check_command check_snmp!
-C esr-rnp -o
sysUpTime.0 ;
comunidade SNMP do host

}
No se esquea de salvar as alteraes.
3. Edite o arquivo que contm a definio dos grupos de hosts que sero monitorados:
gedit /etc/nagios3/conf.d/hostgroups_nagios2.cfg #
Edite o arquivo adicionando as linhas a seguir no final do arquivo:
;----- inicio
define hostgroup {
hostgroup_name esr
alias ESR
members <SERVIDOR1.DOMINIO> Altere, informando o nome do host
definido anteriormente
}
;----fim
11 Adicione as seguintes linhas no arquivo /etc/nagios3/commands.cfg:
gedit /etc/nagios3/commands.cfg
; ---- inicio
# check_snmp command definition
define command{
command_name check_snmp
command_line $USER1$/check_snmp -H $HOSTADDRESS$ $ARG1$
}
;----fim
No esquea de salvar as alteraes.
11 Para que as configuraes entrem em vigor, reinicie o servio da seguinte maneira:
No esquea de salvar as alteraes.
/etc/init.d/nagios3 restart
161
11 Visualize no browser e note as alteraes. Verifique o menu Services, conforme a figura 6.10.
11 O intervalo de verificao do sistema de 90 segundos, configurvel no arquivo:

/etc/nagios3/cgi.cfg na diretiva refresh_rate=90
11 Para observar quais servios podem ser monitorados, acesse a pgina de plugins do
nagios: nagios_plugins;
11 possvel utilizar o Nagios com o banco de dados Mysql, no entanto, essa no a configurao padro. O mdulo perfparse facilita a utilizao do banco de dados Mysql pelo nagios.
11 Demais informaes:
11 O Nagios possui uma estrutura de diretrios para a definio de suas diretivas de configurao, representada a seguir:
Plugins: /usr/lib/nagios/plugins/
Arquivos de Configurao: /etc/nagios3
Documentao: /usr/share/nagios3/htdocs
Plugins: /etc/nagios-plugins/config/
CGI: /usr/lib/cgi-bin/nagios3
Binarios: /usr/sbin
Script de inicializao: /etc/init.d/nagios3
162
OpenVAS
O Open Vulnerability Assessment System (OpenVAS) uma estrutura de vrios servios e
ferramentas que oferecem uma soluo abrangente e poderosa para varredura, identificao e gerenciamento de vulnerabilidades nos ativos conectados a uma rede. O projeto
OpenVas nasceu como um subproduto do Nessus, isso porque os plugins do Nessus deixaram de ser fornecidos sobre licena GPL.
O sistema de varredura de segurana alimentado diariamente atravs de uma rede de
desenvolvedores de plugins (NVTs), tendo mais de 30 mil plugins (abril de 2013).
Figura 6.10
Verificao
de servios
monitorados
por host.
Todos os produtos do OpenVAS so software livre, e a maioria dos componentes est licenciado sob a GNU General Public License (GNU GPL).
OpenVAS CLI
GreenBone
Security
Assistant
GreenBone
Security
Desktop
Clients
OpenVAS
Scanner
OpenVAS
manager
OpenVAS
Administrator
Services
Scan Targets
Results,
congs
Data
NVTs
Figura 6.11
Estrutura do
OpenVAS.
Para utilizar o openvas, basta cadastrar qual a rede que ser analisada. Para isso, acesse
Configuration > Targets e informe um nome para sua rede e quais os hosts que sero
analisados (figura 6.12). Observe que o host ou rede informada aqui necessariamente neces-
Figura 6.12
Criao de Targets.
11 Como prxima etapa, acesse Scan Management > New Tasks e crie uma tarefa
informando o nome e o Scan Target criado anteriormente.
sita ser a qual voc analisar.
163
Figura 6.13
Criao de Task.
11 Aps criada a tarefa, selecione o boto de play:
11 Aps o trmino do scan, no menu Asset Management aparecer a relao de hosts que
possuem vulnerabilidades que merecem a ateno do administrador do sistema,
conforme a figura 6.15.
164
Figura 6.14
Execuo de tarefa
no openvas.
Figura 6.15
Resultado da
verificao de
vulnerabilidades.
OCS Inventory
OCS Inventory um software livre utilizado para inventariar o hardware e software de estaes de trabalho e servidores conectados a uma rede atravs de um agente. Para tal, ele usa
um agente, que deve ser instalado em cada estao de trabalho, responsvel por realizar o
inventrio em computadores cliente e enviar essas informaes para um servidor de gerenciamento central que consolida os resultados do inventrio permitindo a gerao de relatrios.
A comunicao entre agentes e servidor de gerenciamento feita usando os protocolos
HTTP/HTTPS. Todos os dados so formatados em XML e comprimidos utilizando a biblioteca
Zlib para reduzir a mdia de trfego de rede.
Ele permite identificar, apenas, softwares instalados via yum ou apt (no linux) ou registrados
pelo Windows Installer (no Windows).
Como j informado, os agentes devem ser instalados nos computadores-clientes, podendo
ser implantados atravs de login scripts ou Active Directory GPO no Windows. No Linux, o
agente deve ser instalado manualmente.
Unix
inventory
agent
Management Server
http
Unix
inventory
agent
Comunication
server
Windows
inventory
agent
Figura 6.16
Estrurura o OCS
Inventory.
Windows
inventory
agent
DNS
Deployment
server
tp
ht
tp
ht
Administrator
console
Administrator with
web browser
O servidor de gerenciamento contm quatro componentes principais:

11 Servio de banco de dados: para armazenamento das informaes enviadas pelos agentes;
11 Servio de Comunicao: que vai tratar das requisies HTTP entre o servidor de banco
de dados e agentes;
11 Servio de Implantao: que armazena todas as configuraes de implantao de
pacote (exige HTTPS);
11 Console de administrao: que permitir aos administradores elaborar relatrios a
partir das informaes armazenadas no servidor.
Esses quatro componentes podem ser hospedados em um nico computador ou em computadores diferentes, para permitir balanceamento de carga. Acima de 10 mil computadores inventariados, interessante usar pelo menos dois servidores diferentes, um para o servio de banco
de dados e comunicao e outro para rplica do banco de dados, administrao e deployment.
Windows
inventory
agent
Database
Server
165
Instalao do OCS Inventory

11 Para instalar o OCS inventory, execute:
apt-get install
ocsinventory-reports
ocsinventory-server
11 Aps a instalao, acesse http://localhost/ocsreports/ para continuar a instalao.

Informe o usurio e a senha root/root.
Figura 6.17
Continuao da
instalao do OCSInventory.
11 Terminada a instalao, acesse a interface com o usurio admin e senha admin;

11 Instale o cliente o ocs-inventory em seu Windows para enviar o inventrio para o servidor.
Baixe o agente no site: https://launchpad.net/ocsinventory-windows-agent/2.x/2.0.5/
+download/OCSNG-Windows-Agent-2.0.5.zip
11 Durante a instalao do agente, informe o IP do servidor.
166
Figura 6.18
Instalao do
agente do OCS
Inventory.
Figura 6.19
Instalao do
agente do OCS
Inventory.
11 Agora, acesse a interface de gerncia do OCSInventory para visualizar o inventrio

realizado. (http://localhost/oscreports).
11 Selecione a ltima opo para realizar um inventrio logo aps acabar a instalao.
167
Figura 6.20
Visualizao do
inventrio do
OCSinventory.
Spice Works
Spiceworks um MNS que, alm de gerenciar falhas e performance, possibilita o gerenciamento de configurao do modelo FCAPS. Sua distribuio gratuita, contudo, possui
propagandas. Entre suas principais caractersticas, podemos destacar:
11 Comparao de configuraes (hardware/software) de duas ou mais estaes de trabalho;
11 Servio de descoberta automtica de sistemas e dispositivos;
11 Possibilidade de anexar documentao extra, notas e anotaes customizadas em qualquer dispositivo;
11 Carrega todos os dados do Active Directory, facilitando o gerenciamento.
11 Monitora Microsoft Exchange;
11 Alertas pr-programados;
11 Controle de licenas de software;
11 Controle de chamados, integrando usurio, chamado e equipamentos, possibilitando
criao de chamado por e-mail.
11 Possibilita a integrao de plugins de forma gratuita.
Instalao do SpiceWorks
Realize o download do SpiceWorks no endereo: http://download.spiceworks.com/ Spiceworks.exe
(existe uma cpia na pasta do curso em seu desktop).
11 Execute o arquivo e responda afirmativamente para as opes solicitadas, clicando em
Next, conforme a figura 6.21.
168
Figura 6.21
Instalao do
Spiceworks.
11 Aps a instalao dos arquivos, ser criado um servio web em seu computador e ser
acessado automaticamente pelo instalador, para terminar o processo de instalao,
Figura 6.22
Segunda etapa
da instalao do
Spiceworks.
11 Ao final desse procedimento necessrio criar uma conta. Retire a seleo das duas
perguntas, conforme a figura 6.23.
conforme a figura 6.22.
169
Figura 6.23
Criao de conta
no SpiceWorks.
Saiba mais
Para gerenciar as
estaes Windows, o
SpiceWorks utiliza o
Windows Management
Instrumentation (WMI).
Para habilit-lo,
necessrio configurar
o acesso, que no
ser abordado neste
material. Para mais
informaes, acesse
a comunidade do
SpiceWorks: http://community.spiceworks.com
11 Selecione Discovery My devices para descobrir os dispositivos da rede local, como mostrado na figura 6.24.
11 Aparecero todos os dispositivos encontrados da rede. Clique em Enter Credentials,
informe a comunidade SNMP rnp-esr e clique em Start Scan, conforme a figura:
170
Figura 6.24
Opes iniciais do
SpiceWorks.
Figura 6.25
Configurao das
credenciais do
discovery.
11 Terminado o processo, ser apresentado os dispositivos reconhecidos. Voc pode repetir

o processo acessando o menu Inventory > Scan;
11 Para visualizar os dispositivos reconhecidos, acesse Inventory > Devices. Sobre o dispositivo escolhido, voc pode editar alguma configurao/informao ou realizar procedimentos
de gerenciamento atravs da opo Tools, conforme as setas existentes na figura 6.26.
Figura 6.27
Adio de
Dispositivos.
11 Na parte superior da prpria interface de Inventory > Devices, voc pode acrescentar
um novo dispositivo, acessando Edit > Add Devices, conforme a figura 6.27.
11 possvel, atravs de plugins, alterar a linguagem do software, acessando Inventory

> Setting.
11 Nesta interface, acesse Advanced & International Options para alterar a linguagem, e
configuraes regionais.
Figura 6.28
Configuraes
Regionais.
Figura 6.26
Visualizao, edio
e gerenciamento de
dispositivos.
171
11 Voc pode adicionar plugins atravs de Inventory > Tools, como por exemplo o
Bandwidth Monitor, que inclui do DashBoard informaes de trfego gerado por dispositivos, conforme a figura 6.29.
Figura 6.29
Plugin Bandwidth
Monitor.
NTOPng
O Network Traffic Probe: New Generation (NTOPng) atua como um analisador de rede,
gerando estatsticas em tempo real do trfego recebido pela interface de rede monitorada.
Possibilita geolocalizao dos hosts.
11 Mostrar distribuio de trfego IP entre os vrios protocolos;
11 Identifica os fluxos de rede;
11 Pode funcionar como um analisador de fluxos exportados por roteadores, como Cisco
e Juniper;
11 Produz estatsticas do trfego da rede atravs da interface grfica utilizando Ajax/HTML5;
11 Armazena as estatsticas de trafego de rede em formato Round Robin Database (RRD).
Instalao do NTOPng
11 Como pr-requisito para a instalao do NTOPng, execute os comandos a seguir:
apt-get install subversion rrdtool libxml2-dev libglib2.0-dev

libpcap-dev libgeoip* redis-server autoconf libsqlite3-dev libtool
11 Execute a instalao do NTOPng:
svn co https://svn.ntop.org/svn/ntop/trunk/ntopng/
cd ntopng
./autogen.sh
./configure
make geoip
make
make install
Para executar o ntop, passe como parmetro a interface de rede que dever se monitorada.
Exemplo: ntopng i eth0

172
Com esse comando, ser habilitada a captura dos fluxos na interface de rede e disponibilizado o acesso atravs da porta 3000, que poder ser acessada pelo browser, como demonstrado na figura 6.30.
Exemplo: http://127.0.0.1:3000
Usurio: admin
Senha: admin
Figura 6.30
Dashboard
do Ntop.
11 Atravs da interface do Ntop, podemos ter acesso de maneira simples s informaes de

fluxos, como aplicaes e hosts como maior trfego ou verificar os fluxos ativos, con-
Figura 6.31
Fluxos ativos
do Ntop.
forme mostrado na figura:
173
174
7
Conhecer o tratamento de Logs; Aprender sobre monitoramento de fluxos.
conceitos
Tratamento de Logs; Monitoramento de fluxos.
Importncia do registro de ocorrncias

Tudo deve ser registrado.
11 Para comprovar uma falha no sistema.

11 Debug e Troubleshooting.
11 Como evidncia de um crime.
Todos os equipamentos conectados rede possuem funcionalidades que permitem registrar problemas e informaes relevantes sobre a operao do dia a dia. Essas informaes
so imprescindveis para detectar mau funcionamento ou esgotamento de recursos do equipamento na execuo das suas atividades. Falhas de equipamentos, erros de configurao
ou at mesmo atividades ilcitas possuem indcios que tm suas atividades registradas pelos
equipamentos nos mais diversos nveis (debug, erros, alertas etc.) na forma de trilhas para a
auditoria (LOGs).
Os LOGs gerados pelos diversos equipamentos possuem vida til bastante variada, que pode
ser desde alguns minutos para comprovar um erro de configurao durante algum teste, ou
de vrios anos para o caso de algum processo judicial em andamento. Nesse ltimo caso,
vrios cuidados precisam ser tomados visando a sua preservao ao longo dos anos.
11 O registro de LOGs deve ser constante;
11 A inspeo dos registros deve ser rotineira.
Um ponto importante que tanto a gerao quanto a inspeo desses LOGs sejam realizadas sistematicamente visando manter registros sobre o mau funcionamento ou mal uso
dos equipamentos e sistemas. O registro de atividades de Log considerado uma forma
complementar de gerncia da rede, e cobre os casos onde no existe a previso ou a configurao de Traps SNMP ou outros objetos gerenciados pelo fabricante para aquela falha
especfica. Esse um caso comum em falhas no software bsico dos equipamentos.
Captulo 7 - Tratamento de registros de ocorrncias (logs) e fluxos de dados
objetivos
Tratamento de registros de
ocorrncias (logs) e fluxos de dados
175
Um desses casos pode ser visualizado a seguir, onde registrado nos logs de um roteador a
falta de memria para que esse realize as suas funes.
2013-04-11T14:58:31-03:00 c12000 94211: C12000 RP/0/4/CPU0:Apr 11 14:58:29.886 :
wdsysmon[429]: %HA-HA_WD-6-IN_DEP_LIST : Process devb-eide-prp2 pid 40991 is
present in Dependency List and will not be killed.
2013-04-11T14:58:31-03:00 c12000 94212: C12000 RP/0/4/CPU0:Apr 11 14:58:29.886
: wdsysmon[429]: %HA-HA_WD-4-MEMORY_STATE_CHANGE : New memory state:
Severe
2013-04-11T14:58:42-03:00 c12000 94230: C12000 RP/0/4/CPU0:Apr 11 14:58:42.722
: l2fib[291]: %OS-SHMWIN-2-ERROR_ENCOUNTERED : SHMWIN: Error encountered:
System memory state is severe, please check the availability of the system memory
2013-04-11T14:58:58-03:00 c12000 94231: C12000 RP/0/4/CPU0:Apr 11 14:58:58.171 :
fib_mgr[215]: %OS-SHMWIN-2-ERROR_ENCOUNTERED : SHMWIN: Error encountered:
System memory state is severe, please check the availability of the system memory
Figura 7.1
Exemplo de LOGs.
Complementarmente, quando se trata de um crime em investigao pelo sistema judicirio,

importante que tudo o que for registrado venha sendo realizado de forma peridica e
constante, eliminando qualquer dvida sobre a possibilidade de perseguio contra o
indivduo em questo, algo que pode ser questionado no caso de provas pontualmente
geradas, iniciadas prximo ao momento do delito.
Como registrar os LOGs

11 LOGs na mquina local no so confiveis.
11 Em uma invaso.
22 Podem ser removidos ou alterados.
22 O sistema de LOGs pode ser desabilitado.
11 O registro remoto necessrio.
22 O conceito de LOGHOST.
Muitos equipamentos, como roteadores e switches, em razo do custo da sua memria de
armazenamento, no mantm seus registros de auditoria por muito tempo. Em geral, estes utilizam uma pequena frao de sua memria voltil (RAM) para armazenamento, utilizada como
um buffer circular. Nesse caso, as mensagens mais antigas acabam sendo sobrepostas pelas
mais atuais. normal que esses equipamentos mantenham somente os registros de atividades
da ordem de dias ou semanas, o que torna-se necessrio que esses LOGs sejam enviados para
176
um equipamento remoto com maior capacidade de armazenamento, em geral um servidor.
O servidor de LOGs (LOGHOST)

11 um Bastion Host.
11 Firewall customizada.
11 Kernel mnimo e customizado.
11 Os poderes do root so limitados (exemplo: securelevel do FreeBSD/OpenBSD).
22 Alteraes de configurao exigem reboot.
22 Sistema de arquivos (parties append-only)
O equipamento que utilizado para armazenar os logs enviados por outros equipamentos
normalmente conhecido pelo nome de LOGHOST. Nesse modo de operao, normal que
os logs sejam gerados em duplicidade: uma cpia no servidor local e outra no Loghost. Essa
abordagem especialmente importante em casos de invases de hackers em servidores,
onde normalmente a primeira atividade do invasor remover e adulterar os registros de
auditoria da mquina invadida. O uso de um servidor de LOGs externo permite que os
registros de auditoria sejam mantidos a salvo no servidor remoto. Esse tipo de atividade
fortemente recomendado e reconhecida como parte necessria reconstruo da linha
do tempo dos eventos ocorridos no caso de uma auditoria na rede ou sistemas.
Pelo tipo e importncia dos dados mantidos pelo servidor de Logs, o servidor que ser escolhido como Loghost deve ser preparado para suportar sozinho um ataque, independente
de outras linhas de defesa que possam existir na rede (exemplo: firewall, IPS etc.). Ele deve
ser construdo obedecendo s mesmas diretivas da construo de um bastion host, ou
seja, deve ser dedicado para a atividade de Logs, suportando somente aplicativos diretamente relacionado a essas atividades e estar preparado para ataques da mesma forma que
uma mquina totalmente exposta internet. Deve possuir seu prprio firewall (exemplo:
iptables, ipfilter etc.) e no rodar nenhum servio ou protocolo desnecessrio. Tambm
aconselhado que se faa uso de outros dispositivos de segurana, como um kernel customizado e proteo adicional ao sistema de arquivos, onde estaro os arquivos de LOGs. Outro
ponto importante a restrio no acesso remoto a esse servidor e as pessoas que eventualmente tm um login para acesso.
Para saber mais sobre

o SELinux: http://
seLinuxproject.org
Controles adicionais de segurana, conhecidos como MLS (Multi-Level Security), so

implementados em diversos Sistemas Operacionais, como mdulos do prprio Sistema
Operacional, ou atravs da customizao direta do kernel. No Linux, uma boa opo o
uso do SELinux, enquanto nos kernels BSD-Like uma boa opo a ativao do mecanismo
securelevel no momento do boot do sistema, associado com o uso de flags atribudos aos
arquivos e partio de logs (comando chflags do BSD). Entre esses flags, os mais teis para a
criao de um servidor de LOGs so:
11 sappnd, sappend: somente permitido o append nos arquivos no possvel fazer edio;
11 uunlnk, uunlink: no possvel deletar arquivos;
11 uchg, uchange, uimmutable: no possvel reverter os flags atribudos aos arquivos
ou filesystems.
Esses mecanismos de segurana permitem controle mais granular sobre o acesso de escrita,
leitura e acesso ao sistema de arquivos, alm de diminuir os poderes do superusurio do
sistema (root). Isso impede o prprio root de alterar regras de firewall ou remover e editar
os arquivos de Logs. Mais informaes podem ser obtidas em http://www.manpages.info/
freebsd/securelevel.8.html.
Outro ponto relevante que o servidor de LOGs faa uso de um GPS ou que minimamente
sincronize seu horrio via o protocolo Network Time Protocol (NTP), e que ele mesmo insira
seu registro de tempo para cada uma das mensagens recebidas de outros servidores,
mesmo que esse timestamp seja colocado em duplicidade nos Logs.
Em empresas maiores, o Network Operation Center (NOC) divide as tarefas de segurana
com o Security Operations Center (SOC), e normalmente a administrao e uso das informaes do servidor de LOGs so compartilhados entre essas equipes, dada a natureza das
informaes armazenadas e a necessidade de seu uso no dia a dia. Nesse ponto, a admi-
nistrao do LOGHOST fica a cargo do SOC, sendo o NOC um usurio dessas informaes.
177
Dessa forma, cria-se uma estratgia de vigilncia cruzada, onde o reincio do servidor de
LOGs (indcio de uma possvel violao) ficar registrado na estao de gerncia (NMS) administrada pelo NOC, e as alteraes nos equipamentos administrados pelo NOC e equipes de
sistemas ficaro registrados no servidor de Logs (LOGHOST) administrado pelo SOC. Complementarmente a essas implementaes de segurana, relevante que o acesso fsico ao
servidor de LOGs seja controlado. Em ambientes mais crticos, o servidor de Logs tratado
de forma semelhante a uma unidade certificadora (acesso fsico restrito e sem login remoto).
LOGHOST
11 exclusivo para o servio de LOGS.
22 No roda outros servios.

22 O acesso remoto restrito ou inexistente.
11 Geralmente administrado pelo SOC.
22 Diferentes equipes dificultam ocultao de vestgios.
22 O NOC usurio desse servio.
11 O horrio de Timezone corretos vital (NTP).
11 Centraliza logs de switches, roteadores, servidores e aplicaes.
O LOGHOST tem papel vital na operao da rede, mantendo uma cpia confivel e centralizada
do registro de todas as operaes realizadas nos diversos nveis, desde o Sistema Operacional da
mquina at a camada de aplicao e controles de acesso e autenticao de usurios:
11 Sistema Operacional (Windows, unix-like);
11 Switches e roteadores (login e log de comandos);
11 Controle de acesso rede e servidores (Radius, Diameter, Ldap);
11 Acesso a servios (Xen, Vmware, dns, ftp, http etc.);
11 Logs dos diversos firewalls.
Essas informaes, com horrio preciso e centralizado em um mesmo local, so vitais para
uma investigao ou anlise forense, principalmente se obtidas de um local confivel, no
caso de uma violao da rede e sistemas.
O volume de informaes
11 Depende do nvel de segurana da instituio:
22 Militar.
22 Educacional.
22 Comercial.
11 Volume de informaes gerado considervel.
11 A anlise manual invivel.
11 Uma empresa mdia gera em torno de 5GB/dia de logs (~100 milhes de eventos distintos).
A quantidade de logs gerada por uma instituio depende muito de quais atividades sero
elegveis para armazenamento e por quanto tempo se pretende guard-las. O Marco Civil da
Internet (Lei n 12.965, de23 de abrilde2014)exige que provedores de acesso mantenham
logs de acesso de seus clientes por 12 meses. Outras recomendaes, como a da Anatel
(Resoluo n 614, de 28 de maio de 2013), indica que as empresas de Servio de Comunicao Multimdia (SCM) devam manter informaes dos registros de conexo e dados dos
178
usurios pelo prazo mnimo de um ano (Artigo 53). J o CGI-BR recomenda que as informaes de acesso rede sejam mantidas pelo prazo mnimo de trs anos
(http://www.cgi.br/publicacoes/documentacao/desenvolvimento.htm).
O Marco Civil (Lei n 12.965, de23 de abrilde2014)especifica:
11 Art. 13. Na proviso de conexo internet, cabe ao administrador de sistema autnomo respectivo o dever de manter os registros de conexo, sob sigilo, em ambiente
controlado e de segurana, pelo prazo de 1 (um) ano, nos termos do regulamento.
11 Art. 15. O provedor de aplicaes de internet constitudo na forma de pessoa jurdica
e que exera essa atividade de forma organizada, profissionalmente e com fins econmicos dever manter os respectivos registros de acesso a aplicaes de internet,
sob sigilo, em ambiente controlado e de segurana, pelo prazo de 6 (seis) meses, nos
termos do regulamento.
Considera-se que esses logs podem posteriormente ficar armazenados de forma off-line, ou
seja, gravados em uma mdia externa (CD-ROM, DVD-ROM) e guardados em local seguro.
Para ter-se ideia do volume das informaes geradas, uma empresa mdia gera em torno de
5GB/dia de logs (~100 milhes de eventos distintos), considerando-se logs de firewall, e-mail,
acesso a sites etc. Entretanto, essas informaes so altamente compactveis, j que se
tratam de informaes textuais. Em ambientes com requisitos maiores de segurana, esse
volume pode ser multiplicado vrias vezes, podendo ser registrados inclusive as informaes de conexes e acessos realizados por cada um dos elementos da rede (exemplo: log de
flows, proxies e NAT).
A difcil tarefa de interpretar as mensagens de LOGs

Ter e manter um servidor de Logs centralizado no uma tarefa fcil, e como qualquer
servio exige cuidado constante para verificar se todos os novos servidores e equipamentos de rede esto sendo corretamente configurados para faz-lo. Entretanto, existe
gerados pelos diversos equipamentos e servios no seguem nenhum padro. Em geral, as
mensagens so definidas pelos prprios programadores segundo algumas regras bsicas da
prpria empresa em que trabalham. Alguns exemplos de logs de equipamentos:
Exemplo de um roteador Cisco
Sep 18 03:28:55.101 UTC: %LINK-3-UPDOWN: Interface FastEthernet1/0/0,

changed state to down
Sep 18 03:29:40.123 UTC: %SEC-6-IPACCESSLOGP: list 112 denied tcp
192.168.0.2(6012) -> 192.168.0.4(23), 1 packet
Sep 18 03:42:50.212 UTC: %FAN-3-FAN_FAILED: Fans had a rotation
error reported
Exemplo de um roteador Juniper
Sep 18 03:36:16 mib2d[152]: SNMP_TRAP_LINK_DOWN: ifIndex 79,

ifAdminStatus down(2),ifOperStatus down(2), ifName ge-3/0/0
Sep 18 03:40:23 mgd[4334]: UI_COMMIT: User bertholdo requested
commit operation (comment: none)
um agravante: realizar pesquisas nesses logs no uma tarefa simples, dado que os logs
Sep 18 03:55:37 Modifying fan speed as high temp is now 53 C

179
Exemplo de um switch extreme
Alpine SYST: Error: Disk full or allocation exceeded

Alpine SYST: Port 1:2 link down
Alpine USER: admin logged in through telnet (192.168.0.225)
Alpine TRXDIAG: Current temperature reading [9] is 37C.
Exemplo de um servidor Linux
Sep 18 16:22:54 intranet sshd[21519]: Accepted password for berthold

from 192.168.1.228 port 52064 ssh2
Sep 18 16:22:54 intranet sshd[21519]: pam_unix(sshd:session):
session opened for user berthold by (uid=0)
Sep 18 16:23:27 intranet su[21817]: Successful su for root by
berthold
Sep 18 16:23:27 intranet su[21817]: + /dev/pts/0 berthold:root
Sep 18 16:23:27 intranet su[21817]: pam_unix(su:session): session
opened for user root by berthold(uid=10002)
Sep 18 16:25:07 intranet kernel: [195362.552961] IN=eth2 OUT= MA
C=ff:ff:ff:ff:ff:ff:2c:27:d7:94:55:b5:08:00 SRC=192.168.0.152
DST=192.168.0.191 LEN=150 TOS=0x00 PREC=0x00 TTL=128 ID=27708
PROTO=UDP SPT=17500 DPT=17500 LEN=130
Essa impossibilidade de padronizar os logs de cada um dos sistemas ou equipamentos,
aliado grande quantidade de informaes produzidas, torna invivel a anlise manual dos
LOGs, salvo em alguma auditoria especializada e procurando por atividades em uma janela
de tempo especfica caso comum somente no campo da anlise forense. Na atividade corriqueira do NOC/SOC, esses logs sero analisados por ferramentas especficas para anlise,
como o AWSTAT, LOGWATCH, SARG, OSSEC e Splunk.
Definindo uma estratgia de LOGs

11 O syslog server coleta todos os LOGs (514/UDP, 514/TCP).
11 Roteadores, switches e servidores em geral implementam o protocolo syslog.

22 RFC 3164 (The BSD syslog Protocol).
22 RFC5424 (The Syslog Protocol), que suprecede a RFC3164.
180
22 RFC 5426 (Transmission of Syslog Messages over UDP).

22 RFC 6587 (Transmission of Syslog Messages over TCP).
22 RFCs 5425 (Transport Layer Security (TLS) Transport Mapping for Syslog).
Um dos pontos importantes quando se define a estratgia de logs a ser utilizada na instituio a verificao da possibilidade de manter toda a informao em um nico servidor
de forma centralizada. Obviamente, essa estratgia depende de uma boa conexo de dados
entre os dispositivos e o servidor de LOGs.
Deve-se observar que o servidor de logs deve minimamente estar situado aps a primeira
barreira de segurana da instituio, ou seja, o seu firewall.
Seguindo a ideia de um conjunto de logs centralizados, assim como o prpria firewall, os

servidores externos e o prprio roteador da instituio tambm devem enviar seus logs
para o LOGHOST.
Servidor
de Log
Servidores Unix/Linux
Internet
Figura 7.2
Servidor de Logs
e sua posio
na rede.
Firewall
Firewall
Servidores Unix/Linux
Para os casos onde a rede da instituio distribuda por uma conexo de baixo desempenho, possvel optar por servidores de logs distribudos, criando a possibilidade de logs
locais para os casos onde o site esteja off-line. Uma boa estratgia nesses casos providenciar a transferncia dos logs rotacionados para o servidor principal em determinados
perodos de tempo. Essa estratgia aumenta a complexidade da soluo e somente deve ser
utilizada em casos especiais.
Intranet
WWW
Printer
Branch-2
loghost
Figura 7.3
Servidores de logs
distribudos.
Branch-1
loghost
Central
loghost
Branch-3
loghost
Normalmente, a soluo de LOGs realizada usando como LOGHOST um equipamento

Unix, embora algumas solues comerciais permitam a uso de servidores Windows. A
maioria dos fabricantes desenvolvem seus clientes minimante obedecendo a RFC 3164 (The
BSD syslog Protocol), j existem definidas as RFC5424 (The Syslog Protocol) que suprecedem
a RFC3164 e a RFC 5426 (Transmission of Syslog Messages over UDP). Outras melhorias previstas j foram definidas pelas RFC 6587 (Transmission of Syslog Messages over TCP) e RFC
5425 (Transport Layer Security (TLS) Transport Mapping for Syslog).
11 Gerncia In-band x Gerncia Out-Of-Band.
22 Logs preferencialmente utilizam gerencia ou-of-band.
File server
181
Como dito, o mais comumente usado mesmo o transporte utilizando a porta 514/UDP, e
nesse caso existe sempre a possibilidade de ataques de negao de servio e ou de falsificao de mensagens para o servidor de LOGs. Outro problema com essa abordagem a
perda eventual de mensagens, j que o protocolo UDP no possui garantia de entrega.
Um dos contornos possveis para esses problemas o uso da rede de gerncia out-of-band
(OOB) para transporte tambm dos logs de equipamentos e servidores, enquanto as novas
solues ainda no so difundidas. A gerncia OOB caracterizada por cada equipamento
possuir uma interface fsica distinta para a gerncia da rede nessa interface no h trfego
de produo, somente trfego de controle (gerncia SNMP, Backup, acesso SSH para configurao etc.). Outra caracterstica que existe na maioria das implementaes de gerncia
OOB que no existe roteamento, todo o acesso realizado em camada 2.
Servidores Unix-like utilizam:
11 Rsyslog, syslogd e syslog-ng

Servidores Windows utilizam o Event Log:
11 Necessitam de software adicional
11 Winsyslog, syslog-win32, ...
Nos servidores Unix, existe uma diversidade de pacotes capazes de manipular as mensagens do syslog, sendo os mais comuns o syslogd, rsyslogd e o syslog-ng. Este ltimo
ainda possui uma verso open source (OSE) e uma segunda verso comercial chamada de
premium (PE). A verso syslog-ng preferida por j implementar suporte TCP (RFC 5424) e
outras facilidades de filtragem e suporte a bancos de dados.
Os servidores Windows por sua vez utilizam por default o Windows Event Log Service e,
no caso de uma rede mista, no existe uma soluo nativa da Microsoft para usar o protocolo syslog. Nesse caso podem ser utilizados aplicativos freeware, como o Winsyslog
(http://www.winsyslog.com) e o syslog-win32 (http://sourceforge.net/projects/syslog-win32/).
O protocolo Syslog
11 Tipos de eventos (facility).

11 A severidade dos eventos.
Apesar das inmeras variaes das RFCs mas atuais, a base do protocolo syslog ainda
formada por um cdigo bsico que duas informaes bsicas: o tipo de evento conhecido
como facility e a severidade do evento que est sendo informado (fonte RFC5424):
182
Cdigo
Facilidade
Descrio
Kern
Mensagens do Kernel
User
Mensagens de nvel do usurio
Mail
Sistema de e-mail
Daemon
Servios do Sistema Operacional (daemons)
Auth
Mensagens de segurana/autorizao/autenticao
Syslog
Mensagens geradas pelo prprio syslogd
Lpr
Subsistema de impresso do Sistema Operacional
Tabela 7.1
Tabela de
Facilidades dos
protocolos syslog.
Cdigo
Facilidade
Descrio
News
Subsistema de News
Uucp
Subsistema UUCP
Cron
Mensagens do servio de clock/cron do sistema
10
Authpriv
Mensagens de segurana/autorizao/autenticao
11
ftp
Servio de transferncia de arquivo
12
ntp
Subsistema NTP
13
audit
Logs do sistema de auditoria
14
console
Mensagens da console do sistema
15
Cron2
Mensagens do servio de clock/cron do sistema
16
Local0
Uso local pelos aplicativos/uso livre
17
Local1
18
Local2
19
Local3
20
Local4
21
Local5
22
Local6
23
Local7
Quanto ao nvel de prioridade, o protocolo define um nvel de severidade do erro para cada
no equipamento ou subsistema em questo. So eles:
Tabela 7.2
Tabela de
Severidade dos
protocolos syslog.
Cdigo
Prioridade
Descrio
Emerg
O sistema est inutilizado. Usualmente conhecido como

panic condition. Necessita de Interveno imediata do
administrador.
Alert
O sistema ainda opera, mas necessita de interveno imediata.
Crit
Condio crtica do sistema, geralmente falha em um sistema

secundrio que, se no tratado, pode afetar o servio.
Error
Condio de erro do subsistema em questo.
Warning
Mensagem de exceo que indica que o sistema precisa de

acompanhamento
Notice
Mensagem considerada importante sobre a operao do

subsistema.
Informational
Mensagem de informao sobre o processamento do

subsistema. No requer ao do administrador.
Debug
Mensagens de debug do sistema.
um dos subsistemas, segundo o impacto e a necessidade de interveno do administrador
183
Segue o exemplo de um tcpdump de uma mensagem do sistema syslog, formada pelo nome
do programa que envia a requisio (proftp), a facilidade utilizada (daemon) e a prioridade
ou severidade da mensagem (6=informativa).
192.168.1.80.514 > 192.168.1.79.514: SYSLOG, length: 125

Facility daemon (3), Severity info (6)
Msg: Sep 23 12:20:59 proftpd[46143]: 192.168.1.80 (192.168.75.186
[192.168.75.186]): Preparing to chroot to directory /mirror
Configurando diversos clientes syslog

11 Configurando um roteador cisco.
11 Configurando um roteador juniper.

11 Configurando um cliente Linux (rsyslog).
11 Configurando um cliente Windows (winsyslog).
As configuraes dos diversos clientes de syslog seguem a mesma linha bsica, sendo
necessrio configurar os parmetros utilizados pelo protocolo:
11 O endereo IP/IPv6 do servidor de logs remoto;
11 A facility a ser utilizada para identificar aquele equipamento;
11 A prioridade ou criticidade mnima a ser enviada para o servidor.
No caso especfico da prioridade, todas as mensagens de mais alta prioridade so sempre
enviadas, ou seja, se o administrador definiu que devam ser enviadas mensagens de prioridade equivalente a 3(error), sero enviadas para o servidor as mensagens 0 (emerg), 1(crit),
2(alert) e 3(error).
Em equipamentos Cisco (IOS), a configurao mnima somente o nome ou endereo IP/
IPv6 do servidor de logs. Mas normalmente recomendada alguma configurao adicional
relativa ao servidor de tempo, o formato das mensagens a ser enviado, o endereo da
interface que identificar o equipamento, o cdigo do servio e a prioridade a ser enviada
para o loghost. Um exemplo dessa configurao o que segue, considere que o endereo
192.168.1.79 o IP do Logserver.
ntp server 192.168.1.1

service timestamps log datetime localtime
logging 192.168.1.79
logging facility local2

logging source-interface Loopback0
Em equipamentos Juniper, a configurao estabelece parmetros similares:
server 192.168.1.1 version 3 prefer;

set system syslog host 192.168.1.79 authorization any
set system syslog host 192.168.1.79 daemon any
set system syslog host 192.168.1.79 security any
set system syslog host 192.168.1.79
184
change-log any
set system syslog host 192.168.1.79
facility-override local2
set system syslog host 192.168.1.79 source-address 192.168.1.2

Em sistemas unix-like, basta acrescentar a linha a seguir no final do arquivo de configurao
do syslogd. Geralmente o arquivo /etc/syslogd.conf (*BSD) ou /etc/rsyslog.conf (Linux).
*.*
@192.168.1.79
Essa configurao enviar uma cpia de todos os logs gerados pelo servidor para o loghost
definido para a rede (@loghost).
Em mquinas Windows, como dito anteriormente, necessrio realizar a configurao de
um software adicional. A tela a seguir refere-se configurao do servidor de logs utilizando
o software freeware Winsyslog (http://www.winsyslog.com). Outra alternativa para os servidores Windows o eventlog-to-syslog (http://code.google.com/p/eventlog-to-syslog/).
Para instal-lo, execute como administrador do sistema os seguintes comandos:
c:\> evtsys.exe -i l 0 t WINDOWS -h endereo.ip.do.logserver

c:\> copy evtsys.exe c:\Windows\System32
A instalao do software far a configurao de alguns registros do sistema. Esses registros
Figura 7.4
Registro EvtSys
no Windows.
11 Facility
(DWORD) Default: 3
11 IncludeOnly
(DWORD) Default: 0
11 LogHost
(String) Default: N/A
11 LogHost2
(String) Default: <empty>
11 LogLevel
(DWORD) Default: 0
11 Port
(DWORD) Default: 514
11 QueryDhcp
(DWORD) Default: 0
11 StatusInterval
(DWORD) Default: 0
so instalados em HKLM\SOFTWARE\ECN\EvtSys\3.0:
185
Uma vez resolvidos os problemas relativos segurana da mquina servidora de LOGs e

configurado individualmente cada um dos clientes (roteadores, switches e servidores), o
passo seguinte a instalao e configurao do servidor de LOGs (loghost). O processo de
instalao relativamente simples, embora seja necessrio que se faa alguma adequao
aos requisitos locais no que trata da forma como sero agrupadas as informaes da instituio geralmente atrelada a permisses para cada uma das equipes de trabalho (exemplo:
NOC, Sistemas e Segurana).
Analisando os LOGs
Anlise Manual:
11 Busca por causas de problemas detectados (gerncia reativa).

11 Busca por problemas em andamento ainda no detectados.
11 Busca por indcios de novos problemas (gerncia proativa).
11 Correlacionamentos.
A ideia bsica de se manter um LOG completo e centralizado fundamentalmente a de
prover uma fonte rica e confivel que possibilite um olhar no passado com o objetivo de
compreender o que exatamente ocorreu em um determinado evento ou incidente.
Uma atividade bastante comum na rea de gerncia de rede a busca por mais informaes
sobre um determinado problema ou identificao de um erro de configurao ou mal funcionamento dos equipamentos. Como visto anteriormente, nesta sesso, bastante usual
que equipamentos com algum tipo de problema deixem algum vestgio registrado. Isso
comum em problemas como falta de memria, problemas de sobreaquecimento, falta de
espao em disco e muitos outros especficos de cada equipamento.
Quando se trata de uma identificao de problema em um equipamento especfico (gerncia
reativa), o sistema de LOGs uma ferramenta indispensvel. Em casos mais extremos,
bastante comum habilitar algum tipo de DEBUG naquele equipamento ou subsistema e
realizar uma leitura mais detalhada do problema.
Os diversos fabricantes costumeiramente proveem esse tipo de funcionalidade e solicitam
que o cliente realize algum procedimento de DEBUG como primeiro passo da soluo do
problema, como um debug no processo OSPF de um cisco (debug ospf 1 hello) ou inspecionando o fluxo de informaes que passa atravs do firewall de um roteador Juniper (debug
flow basic). Essa mesma anlise se aplica a outros processos e servios, um bastante comum
o servio de e-mails, onde por exemplo se deseja identificar os problemas no envio/
recepo de e-mail para um determinado servidor:
# grep -w joe.ufrgs.br mail.log
186
2013-09-03T10:13:08-03:00 beta postfix/smtpd[22983]: connect from

joe.ufrgs.br[143.54.1.200]
2013-09-03T10:13:08-03:00 beta postfix/smtpd[22983]: 25F0718D4A1:
client=joe.ufrgs.br[143.54.1.200]
2013-09-03T10:13:08-03:00 beta postfix/smtpd[22983]: disconnect from
joe.ufrgs.br[143.54.1.200]
Entretanto, para termos as informaes que desejamos, necessria uma inspeo

peridica ou eventualmente pontual nesse banco de informaes. Uma forma rpida de
realizarmos essa busca a procura utilizando comando do Unix, tais como Find, grep, egrep,
cut, paste, sed e uma boa dose de conhecimento de expresses regulares. Ou ento utilizando alguma linguagem com boa capacidade de processamento de textos, como PERL ou
PYTHON.
Algumas vezes, essas buscas podem exigir um conhecimento razovel. Por exemplo, observe
o comando utilizado para obter todos os IPs que tentaram acessar via ssh um determinado
servidor e erraram a senha ou ento tentaram logar com um nome de usurio invlido:
# cat auth.log | grep ssh | egrep invalid user|Failed password |

grep -o [0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\} | sort -u
Automatizando a anlise de LOGs

Anlise Automatizada:
11 Awstat
11 Sarg
11 Splunk
11 Elsa
Embora a anlise manual dos logs seja algo relativamente corriqueiro nas atividades de operao de redes e servidores, e com valia para gerncia reativa, o grande volume de dados
oculta muitas informaes importantes, dificultando a anlise proativa e correlao das
informaes de diversos servios ou servidores, tornando-se imprescindvel um ferramental
que realize uma anlise automatizada desses dados com o objetivo de identificar principalmente problemas menores que tendem a se manifestar com o passar do tempo.
Vrias ferramentas existem nesse sentido, sendo algumas delas bastante conhecidas.
grande problema a falta de padronizao de partes simples das mensagens de log, como
por exemplo o prprio identificador de tempo das mensagens, que varia entre inmeros
servidores conhecidos (codificao ISO, expresso em inteiro, ponto flutuante, ...).
Entre o ferramental conhecido existem alguns que podem ser referenciados como opes
para os diferentes problemas de anlise de logs. Basicamente so softwares com algum tipo
de interface web e que necessitam de acesso aos arquivos de log do sistema:
AWSTAT
Awstats (http://awstats.sourceforge.net/) uma excelente ferramenta para anlise de websites, permitindo gerar relatrios baseados em histricos de acesso aos sites. Informaes
como a origem dos acessos, pginas mais acessadas e navegadores mais utilizados para
acesso ao site so visualizadas em forma grfica e transparente pela ferramenta.
Infelizmente no existe nesse segmento uma ferramenta totalmente gratuita e completa. O
187
Figura 7.5
Exemplo de tela
do AWStats.
SARG
Squid Analysis Report Generator (SARG), http://awstats.sourceforge.net/, uma ferramenta
para anlise de logs do Squid (proxy web), permitindo gerar relatrios de uso individual para
usurios, alm de vrias outras informaes, como uso de banda e sites mais acessados.
Uma opo possvel utiliz-lo para monitorar acessos de usurios em um firewall pfsense.
Figura 7.6
Exemplo de tela
do SARG.
ELSA
Enterprise Log and Search Archive (ELSA), https://code.google.com/p/enterprise-log-search-and-archive/, um projeto relativamente novo e tem por meta processar os logs centralizados com o syslog-ng em um LOGHOST. A ideia bsica do software facilitar a vida do
administrador, que necessita gerar relatrios e buscar informaes nos arquivos de logs
sem necessitar de programao script (shell, perl) ou ter de dispensar um tempo conside Gerncia de Redes de Computadores
rvel pensando em expresses regulares complexas para buscar o que procura. A interface
188
relativamente simples. Esse software uma alternativa ao SPLUNK.
Figura 7.7
Exemplo de tela
do ELSA.
SPLUNK
SPLUNK, http://www.splunk.com, uma ferramenta comercial que tem por objetivo
indexar em um banco de dados todos os arquivos de LOGs de um servidor (exemplo:
LOGHOST) e permitir buscas rpidas nessa base de dados, alm de permitir gerar alarmes
de maneira semelhante a um Log-based Intrusion Detection System (LIDS). Ele possui uma
interface relativamente simples, que permite a gerao de relatrios e buscas rpidas nos
LOGs baseado em operaes lgicas simples para o usurio.
Uma funcionalidade interessante do software a existncia de um Dashboard que o
usurio pode configurar previamente com as consultas e grficos que julgue mais relevantes, como um grfico instantnea de todas as mensagens de erro ou warnings que esto
sendo locados por todos os servidores naquele momento. O software tem uma integrao
Figura 7.8
Exemplo de tela
do Splunk.
interpretao de logs de Cisco, Juniper, Linux, Mysql, Xen, VMWare, NAGIOS e muitos outros.
Porm, um grande ponto negativo que a licena de uso gratuita somente permite a anlise
diria de at 500 MB.
muito boa da parte grfica e da pesquisa nos logs, tendo inclusive vrios add-ons para
189
Monitoramento de fluxos
Introduo
Monitoramento de fluxos:
11 Traa perfis de trfego com base em fluxos.
11 Coleta em pontos-chave da rede.
Fluxo de rede entre ns finais:
11 Sequncia unidirecional de pacotes.
Implementaes:
11 Conjunto de informaes e protocolo.
Monitoramento de fluxos: uma abordagem de monitoramento de rede que traa perfis de

trfego baseado em estatsticas de fluxos coletados de pontos-chave da rede.
Um fluxo uma sequncia unidirecional de pacotes entre dois ns finais. Como exemplo, se
h uma comunicao entre os ns A e B, h um fluxo de A para B e outro fluxo de B para A.
NetFlow Enable Device
Trac
Inspect Packet
NetFlow Cache
Source IP address
Destination IP address
Source port
Destination port
Layer 3 protocol
TOS byte (DSCP)
Flow Information
Packet
Bytes/packet
Address, ports...
11000
1528
...
Create a ow from
the packet attributes
Figura 7.9
Um fluxo de
dados sempre
unidirecional.
Input Interface
As implementaes definem um conjunto de informaes a serem derivadas dos fluxos
e um protocolo que permite a exportao dessas informaes para um equipamento de
coleta e anlise.
Para que serve?
190
11 Informar o que est acontecendo na rede:

22 Contabilizar o uso da rede.
22 Detectar anomalias e atividade maliciosa.
22 Monitorar as atividades da rede.
22 Facilitar o planejamento da rede.
11 Alertar os administradores.
22 Envio de e-mail.
O armazenamento e anlise dos fluxos de dados traz inmeros benefcios,

entre eles a identificao facilitada de problemas na rede ocasionados por mau uso
(exemplo: DoS ou DDoS).
Com as informaes dos cabealhos IP/UDP/TCP coletadas a partir dos fluxos, torna-se
possvel realizar pesquisas sobre esses dados a respeito de um determinado IP, conexo ou
volume de trfego entre determinadas redes. Essa facilidade de uso corriqueiro na engenharia de trfego: uma consulta aos fluxos informa quais os sistemas autnomos (ASNs) so
as maiores origens ou destinos do trfego da instituio, ou at mesmo quais provedores
de acesso tm a maioria dos clientes que acessam o website da empresa. Dessa forma,
pode-se predizer qual a melhor operadora a ser contratada e qual a dimenso aproximada
do circuito de dados que deve ser contratado. Alm disso, os flows possibilitam que sejam
mostrados em grficos os seus dados utilizando algumas ferramentas complementares, como
NFSen e FlowScan, permitindo facilmente identificar variaes na baseline do trfego.
Alguns outros exemplos de uso dos flows podem ser considerados em anlises como:
11 Identificar o trfego demasiado alto entre ns no relacionados;
11 Planejar e avaliar a adio de trfego;
11 Interfaces de rede sobrecarregadas;
11 Trfego de software malicioso worm;
11 Ataques de negao de servio de rede;
11 Enumerao de mquinas e servios disponveis port scan;
11 Envio de e-mail alertando os administradores de problemas.
Como realizada a coleta dos fluxos

11 Sondas so espalhados na rede e identificam os fluxos de dados.
11 Os fluxos so:
22 Capturados.
22 Contabilizados (pacotes, bytes).
22 Exportados para um servidor de fluxos.
Figura 7.10
Detectando um
DoS atravs
da anlise grfica
dos fluxos.
191
Para obter as informaes sobre os fluxos, necessrio identific-los univocamente e registr-los. Essa tarefa fica a cargo de sondas ativadas em equipamentos de rede, tais como:
roteadores, switches, gateways etc. As sondas so projetadas para manter os registros em
um cache pequeno e voltil. A leitura dos registros do cache permite ter um retrato imediato
do que est passando pelo equipamento. No entanto, normalmente as sondas esto instaladas em mquinas que no conseguem armazenar muitos registros, por isso, de tempos
em tempos, esses fluxos so exportados para uma mquina coletora, deixando no cache
somente o registro dos fluxos mais recentes.
As informaes de fluxo so coletadas e guardadas em uma mquina com maior capacidade
de armazenamento, permitindo manter um histrico dos fluxos da rede.
11 Sonda ativada em equipamento de rede:

22 Identificao de fluxos;
22 Registro de poucos fluxos;
22 Cache voltil para consultas imediatas;
22 Exportao de tempos em tempos.
11 Coletor fica em servidor de rede:
22 Captura fluxos exportados;
22 Armazena em mdia no-voltil;
22 O limite o disco da mquina;
22 Mantm histrico de fluxos coletados.
Equipamento com
sonda de uxos
Figura 7.11
Processo de coleta
de fluxos.
Trfego
1
Inspecionar pacote
Cache de Fluxos
Endereo IP de origem
Informaes do uxo Pacotes Bytes/pacote
Endereo IP de destino
Campos de
chave do uxo
1528
Pacotes de uxos
exportados
Protocolo de camada 3
Interface de camada
192
11000
...
Porta de destino
Byte TOS (DSCP)1
Endereos, portas, ...
Porta de origem
Criar uxo com atributos de Pacote
TOS Type of service; DSCP DiServ Code Point
3
Gerar relatrio sobre
1. Inspeciona os campos chave de um pacote e identica os valores

2. Se o conjuntos de valores dos campos chave unico, cria um registro de uxo no cache
3. Quando o uxo termina, exporta o uxo para o coletor
Cada pacote que passa pela sonda incrementa os contadores dos fluxos existentes ou, no caso uma
nova identificao unvoca de fluxo, ele eleito para criar uma nova entrada na tabela de fluxos.
Essa identificao feita atravs da inspeo de campos-chaves contidos em um pacote recebido.
Nas primeiras verses das implementaes, os campos-chave eram fixos:
11 Endereo IP de origem;
11 Endereo IP de destino;
11 Porta de origem da camada de transporte;
11 Porta de destino da camada de transporte;
11 Protocolo da camada de rede;
11 Byte TOS/DSCP (Type of Service/DiffServ Code Point);
11 Interface de entrada (Identificador da interface mesmo obtido pelo SNMP ifIndex).
Nas implementaes mais recentes, possvel definir quais campos sero considerados
chave para a criao de um novo registro no cache de fluxos. As informaes contidas no
registro tambm podem variar de acordo com a implementao, mas no mnimo contm os
seguintes registros originais das primeiras verses:
11 Data e hora de incio e fim;
11 Endereos da origem e do destino;
11 Portas de origem e destino;
11 Protocolo (TCP, UDP, ICMP etc.);
11 Interface de entrada e de sada (valor referente a OID ifIndex da MIB-II do SNMP);
11 Contadores de bytes transferidos e pacotes usados;
Alm dessas informaes, tambm podem aparecer:
11 Cdigo ICMP;
11 Endereo do prximo salto (gateway);

11 Mscara de rede da origem e do destino;
11 Nmero do Sistema Autnomo (ASN) de origem e de destino;
11 Rtulos Multiprotocol Label Switching (MPLS);
11 Endereo fsico (MAC) dos quadros de origem e de destino;
11 VLAN IDs dos quadros de origem e de destino;
11 Identificao (login) do usurio;
11 Em fluxos TCP ainda podem aparecer os flags TCP.
Fluxo s exportado quando termina.
11 No caso do TCP:
22 A flag FIN ou RST marca o trmino do fluxo.
Demais protocolos:
11 Por inatividade na comunicao.
11 Usando contador de tempo de espera configurvel.
11 Na casa das dezenas de segundos.
11 Tipo de servio (Type of Service TOS);
11 Contador reiniciado para cada pacote do fluxo.

193
Assim que um pacote chega sonda, ele inspecionado para determinar se os valores dos
campos-chave coincidem com o fluxo existente. Se coincidir, o pacote contabilizado nesse
fluxo. Caso contrrio, criada uma nova entrada no cache. Quando o fluxo termina, ele
exportado. O processo de trmino o mesmo dos protocolos UDP e TCP, timeout ou encerramento de conexo, existindo ainda a possibilidade de um fluxo mais antigo ser eleito para
envio ao coletor nos casos de falta de memria em cache para armazenar os novos fluxos
que esto chegando. Quando enviados para a mquina coletora, os registros so armazenados em disco para posterior processamento e anlise.
A exportao do fluxo s pode acontecer quando o fluxo termina. No caso do TCP, o
trmino marcado por um pacote com a flag FIN ou RST. No entanto, outros protocolos no
possuem um marcador de trmino natural, nesse caso, supe-se que o fluxo terminou por
inatividade na comunicao. O tempo de espera para supor esse trmino configurvel e
fica normalmente na casa das dezenas de segundos. Para todo pacote visto, iniciado um
contador de inatividade, se aparecer um novo pacote antes do contador atingir a quantidade
de tempo configurada, o contador reiniciado. Caso contrrio, o fluxo exportado.
A principal finalidade do uso de fluxos determinar em tempo hbil a situao da rede, mas
fluxos muitos longos s aparecem no coletor aps seu trmino, mascarando a situao real
da rede at que eles terminem. Por essa razo, a sonda tem uma pr-configurao que fora a
finalizao do fluxo em um prazo mximo. Isso causa o registro de dois ou mais fluxos pertencentes a um nico fluxo. Apesar de ser uma informao incorreta, os processadores conseguem
facilmente associar dois fluxos consecutivos ao fluxo correto. Esse tempo de vida mximo comumente varia entre 1 a 30 minutos, mas podem ser configurados tempos maiores.
A finalizao forada tambm usada para diminuir quantidade de recursos utilizados pela
sonda no equipamento.
Registro por amostragem:
11 Memria da sonda pequena;

11 O processador tem outras tarefas a realizar;
11 Amostra de trfego visto.
22 Exemplo: 1 a cada 1000 pacotes;
22 Tendncias do trfego so mantidas.
Os equipamentos de interligao (roteadores) no foram feitos especificamente para registrar fluxos, e isso pode eventualmente exaurir seus recursos durante esse registro. Para
evitar isso, possvel configurar o equipamento para registrar os fluxos por amostragem do
trfego, ou seja, o equipamento registra informaes apenas para uma frao dos pacotes
vistos, por exemplo, 1 a cada 1000 pacotes.
194
Como o coletor ter apenas uma amostra do trfego, as informaes derivadas sero imprecisas, mas indicaro as tendncias do trfego.
Registro de fluxos agregados:
11 Sumrio de fluxos.
22 Critrio de agregao.
22 Feito pela sonda;
22 Usa cache principal e caches de agregao;
22 Parmetros configurveis na sonda.
11 Exportao.
22 Gera nmero menor de pacotes;

22 Usa menos banda;
22 Diminui o trabalho da mquina coletora.
Algumas vezes, apenas um sumrio do trfego suficiente para entender o que est acontecendo na rede, por exemplo, agregao dos fluxos por sistema autnomo de origem ou
No caso das mquinas

coletoras, comum
usar um Sistema Operacional de uso geral,
onde uma ferramenta
coleta e armazena os
fluxos e outras ferramentas processam,
analisam e geram relatrios e grficos sobres
os fluxos armazenados.
nos fluxos que atendem ao critrio de agregao. A agregao feita pela sonda, atravs do
uso de mltiplos caches, um cache principal e caches auxiliares de agregao. Os registros
terminados ou expirados no cache principal so acumulados nos cache de agregao.
O critrio de agregao e expirao de fluxos dos caches de agregao so configurveis
na sonda. Devido agregao, o nmero de pacotes exportados menor, assim, h uma
diminuio do uso da banda e dos recursos usados pela mquina coletora para processar e
armazenar os fluxos.
As sondas so normalmente implementadas por equipamentos de interligao, tais como:
roteadores e switches, mas tambm podem ser implementadas por software em Sistemas
Operacionais de uso geral, como o Linux, por exemplo.
Tanto as sondas, quanto as coletoras e analisadoras, podem ser implementados por equipamento especificamente projetado para essas funes, com ganhos de desempenho e
facilidade de implantao.
Registros personalizados:
11 Formato definido por modelo (template);

22 Campos-chave.
33 Nmero de fluxos aumenta proporcionalmente.
11 Campos para registro;
11 Informado de tempos em tempos;
22 Registros de fluxos.
33 Contm informaes mnimas sobre o modelo (template).
As verses mais recentes das implementaes so muito flexveis. Elas permitem uso de
registros personalizados, onde possvel definir quais campos so chave para criao de
novas entradas no cache e quais campos devem ser registrados nos fluxos. O nmero de
fluxos criados proporcional ao nmero de campos-chave do registro.
A personalizao feita atravs de modelos (templates) que so enviados da sonda para o
coletor de tempos em tempos. Dessa forma, o coletor passa a ter os subsdios para interpretar os dados contidos nos fluxos recebidos.
Os registros de fluxos propriamente ditos contm informaes mnimas sobre o modelo
para que seja possvel relacionar o conjunto de dados do fluxo ao modelo (template) recebido previamente.
Saiba mais
destino. O registro do fluxo agregado deve conter a somatria das informaes contidas
195
Mtodos de exportao
A exportao dos fluxos pode ocorrer de vrias formas. A transmisso pode ser em unicast
(um destinatrio um coletor) e em multicast (grupo de destinatrios grupo de coletores).
J em relao ao protocolo, apesar da predominncia do uso do User Datagram Protocol
(UDP), tambm possvel usar o Transmission Control Procotol (TCP) e o Stream Control
Transmission Protocol (SCTP).
Depois que os fluxos esto armazenados, ento possvel process-los para derivar informaes mais sintticas sobre a massa de dados coletados, atravs da aplicao de filtros,
agregao de fluxos e correlacionamento de fluxos. Com isso, geram-se relatrios textuais e
grficos com base nos fluxos coletados, tais como protocolos mais usados, banda utilizada
por mquina etc. Algumas dessas ferramentas so de tal forma inteligentes que so capazes
de determinar se h algum tipo de trfego abusivo com base em trfegos considerados
normais previamente coletados ou em limiares predefinidos pelo administrador. As ferramentas NFSen e Plixer Scrutinizer so exemplos de ferramentas com tal inteligncia.
Onde ativar as sondas

O melhor lugar ativ-las so em pontos centralizadores do trfego da rede, tais como
roteadores e switches, mas nada impede que elas sejam ativadas em servidores e estaes
de trabalho rodando softwares como o ntop-ng.
Muitos switches possuem o recurso de espelhamento de porta, que permite a cpia do
trfego visto em uma ou mais portas para uma outra porta do equipamento. Esse recurso
tambm encontrado sob os nomes Switched Port Analyzer (SPAN), na Cisco, e Roving
Analysis Port (RAP), na 3Com. Com isso, possvel colocar uma sonda (exemplo: um servidor
rodando ntop-ng) nessa porta espelhada.
Espelhamento de porta:
11 Porta de espelhamento, SPAN ou RAP;

11 1:1 1 porta espelho e 1 porta de produo;
11 N:1 1 porta espelho e N portas de produo.
O espelhamento pode ser do tipo 1:1, ou seja, 1 porta de espelhamento copia o trfego de
uma porta de produo; ou pode ser N:1, onde 1 porta de espelhamento copia o trfego de
N portas de produo do switch.
Existem tambm equipamento de fim especfico para a coleta de fluxos de forma transpa-
rente e com capacidade de exportar os registros de fluxos para um coletor.
Implementaes
Tecnologias concorrentes:
11 NetFlow (Network Flow), da Cisco Systems.
22 Deu incio a tudo e hoje em dia muito flexvel.
22 Verso 5 a mais usada, mas existe a verso 9.
11 sFlow (Sampling Flow), da InMon Corporation.
22 Introduziu o conceito de amostragem de trfego.
22 Implementada por CHIP dedicado adicionado ao hardware.
22 Tipos de mensagens diferentes. Est na verso 5.
196
11 IPFIX (IP Flow Information Export) da IETF:
22 Baseada na verso 9 do NetFlow.

22 Introduziu o uso de templates (modelos).
22 Pretende ser o padro no monitoramento de fluxos.
Entre as tecnologias para monitoramento de fluxo, existem trs que se destacam:
11 NetFlow (Network Flow): desenvolvida pela Cisco Systems. Outros fabricantes do
nomes diferentes para a mesma tecnologia. Exemplo: Juniper Networks: jFlow, 3Com
NetStream etc. Deu incio a tudo, sendo a plataforma mais usada atualmente. Evoluiu bastante com o tempo e aplica todas as facilidades de monitoramento de fluxo. A verso 5 a
mais usada, atualmente est na verso 9, tambm conhecida pelo nome Flexible Netflow.
muito flexvel, pois permite a definio dos campos-chave e dos dados a serem registrados;
11 sFlow (Sampling Flow): desenvolvida pela InMon Corporation. Introduziu o conceito de
amostragem de trfego. implementada por CHIP dedicado adicionado ao hardware,
liberando o processador principal. Podem ser usados tipos de mensagens diferentes,
flexibilizando a definio de quais dados sero registrados. Est na verso 5;
11 IPFIX (IP Flow Information Export): desenvolvida pela Internet Engineering Task Force
(IETF), baseada na verso 9 do NetFlow. Foi desenvolvida com base no Netflow verso 9.
Introduziu o conceito de templates (modelos) para definir os dados a serem enviados
para o coletor. Pretende ser o padro no monitoramento de fluxos.
Sondas por Hardware:
11 Sondas embutidas nos roteadores e switches;

22 Netflow: Cisco, Juniper Networks etc.
22 sFlow: Foundry, Extreme Networks etc.
11 Stand-alone Appliances.
22 Invea Tech FlowMon Probe.

As sondas implementadas por hardware comumente vm instaladas em equipamentos de
interligao de rede, tais como roteadores e switches. Os equipamentos da Cisco Systems
e Juniper Networks so exemplos que suportam Netflow. J os equipamentos da Foundry e
Extreme Networks so exemplos que suportam sFlow.
Alm dessas, existem tambm mquinas autosuficientes de fim especial (Stand-alone
Appliances) para realizar essa tarefa. Esses equipamentos so preparados para suportar
uma grande quantidade de trfego, e assim evitar a perda de fluxos da rede.
A seguir, dois exemplos desses equipamentos:
11 Nmon nBox;
11 Invea Tech FlowMon Probe.
22 Nmon nBox.
197
Sondas por software:
Figura 7.12
Hardwares
especializados
em coleta de fluxos
na rede.
11 Rodam em S.O. de uso geral.

22 Linux, FreeBSD, Solaris etc.
11 Usam a libpcap.
11 Os formatos de fluxo suportados variam.
As sondas implementadas por software podem ser instaladas e configuradas em Sistemas
Operacionais de uso geral, tais como Linux e FreeBSD. A maioria delas usa a biblioteca
libpcap para fazer a captura dos pacotes da rede para depois process-los e finalmente
exportar o fluxo.
Alguns exemplos de sondas, formatos suportados e respectivos endereos na internet:
Netflow v5
Netflow v9
sFlow v5
fprobe
softflowd
pmacct
nProbe
IPFIX
Coletores:
11 Appliances;
22 Interface de administrao e operao remota.
22 Com cdigo proprietrio ou aberto.
11 Proprietrios;
22 Plixer International Scrutinizer
22 ManageEngine Netflow Analyzer
22 Lancope StealthWatch
22 Arbor Networks Peakflow

22 Cdigo aberto
33 Flow-tools
33 NFDump/NFSen
33 Flowscan
O coletor normalmente implementado em software. Existem dezenas de coletores disponveis do mercado, tanto proprietrios quanto de cdigo aberto.
Alguns integradores embutem software em equipamentos de uso geral, adicionam interfaces grficas para administrao e operao para comercializ-los como appliances de
anlise de fluxos. O software embutido nesses appliances pode ser proprietrio ou aberto.
198
Tabela 7.3
Formatos
suportados por
cada soluo.
Entre os softwares de cdigo proprietrio, destacam-se os seguintes produtos:

11 Scrutinizer FlowAnalizer
11 ManageEngine Netflow Analyzer
11 Lancope StealthWatch
11 Arbor Networks Peakflow
Entre os softwares de cdigo aberto, os seguintes esto entre os mais utilizados
11 Flow-tools
11 NFDump/NFSen
11 Flowscan
11 SiLK
Exemplos de Configuraes
11 Sonda: Cisco Systems IOS (configurao)
interface FastEthernet0/0
description Access to backbone
ip address 192.168.0.1 255.255.255.0
ip route-cache flow
IOS ver
ip flow [ingress|egress] !
IOS ver >= 12.4
< 12.4
duplex auto
speed auto
!
ip flow-export destination 192.168.0.2 2055

ip flow-cache timeout active 5
11 Sonda: Cisco Systems IOS (comandos)
22 show ip flow export: mostra situao, configurao e estatsticas sobre o exportador
22 sh ip cache flow: mostra estatsticas e valores dos registros armazenados no cache
22 sh ip flow top-talkers: mostra os fluxos por ordem decrescente de quantidade de bytes
transferidos.
Os equipamentos da Cisco Systems rodam os Sistemas Operacionais IOS (roteadores) e
CatOS (switches), eles implementam o Flexible Netflow e podem exportar os formatos mais
comuns de pacotes Netflow.
O exemplo ao lado se aplica a um roteador, a configurao habilita o Netflow na interface
FastEthernet0/0, configura o exportador para mandar os pacotes Netflow v5 para o coletor
hospedado no endereo 192.168.0.2 e estabelece que o tempo de vida mximo do fluxo
5 minutos.
ip flow-export version 5
199
11 As sondas fprobe e softflowd rodam em sistemas Linux e FreeBSD e fazem uso da biblioteca libpcap para interceptar o trfego. A seguir seguem os endereos da pgina web
destas ferramentas:
22 fprobe: http://fprobe.sourceforge.net/
22 softflowd: http://www.mindrot.org/projects/softflowd/
11 O Flow-tools uma biblioteca e um conjunto de ferramentas de linha de comando usados
para coletar e processar fluxos NetFlow e para gerar relatrios sobre esses fluxos.
22 flow-capture coleta, comprime, armazena e mantm o espao utilizado no disco.
22 flow-cat concatena arquivos que contm os fluxos coletados.
22 flow-dscan ferramenta simples para detectar alguns tipos de varreduras de rede e
ataques de negao de servio.
22 flow-expire expira fluxos usando as mesmas polticas disponveis no flow-capture.
22 flow-export: exporta fluxos para o formato ASCII ou cflowd.
22 flow-fanout replica os pacotes Netflow para destinos unicast e multicast, permitindo
o uso de mltiplos coletores simultneos.
22 flow-filter filtra fluxos com base em qualquer dos campos contidos no registro do fluxo.
22 flow-gen gera dados de teste.
22 flow-header mostra meta informaes contidas no arquivo de fluxos.
22 flow-import importa fluxos no formato ASCII ou cflowd.
22 flow-log2rrd: processa as linhas STAT (estatsticas) do log provenientes do flow-capture
e flow-fanout e converte para RRD
22 flow-mask: aplica rtulos a arquivos de fluxos
22 flow-merge junta arquivos de fluxos em ordem cronolgica.
22 flow-nfilter: filtra fluxos com base em qualquer dos campos contidos no registro do
fluxo. Filtros definidos em arquivo.
22 flow-print: mostra os fluxos em ASCII usando um formatos predefinido. O formato
selecionvel entre vrios.
22 flow-receive: recebe fluxos exportados no formato Netflow sem armazenar no disco
22 flow-report gera relatrios sobre o conjunto de dados coletados.
22 flow-rpt2rrd: converte a sada do flow-report separado por vrgula para o formato RRD
22 flow-rptfmt: converte a sada do flow-report separado por vrgula para ASCII ou HTML
formatado
22 flow-send envia dados pela rede usado o protocolo NetFlow.
200
22 flow-split: parte arquivos de fluxos em arquivos menores com base em tamanho, data
e hora ou rtulo.
22 flow-stat: gera relatrios com os dados dos fluxos capturados.
22 flow-tag: rotula fluxos com base no endereo IP ou nmero do AS, facilitando o agrupamento desses fluxos.
22 flow-xlate: executa a traduo de alguns campos de registro de fluxos.
11 O NFDump um conjunto de ferramentas de linha de comando para coleta e processamento de fluxos de dados.
22 nfcapd capturador de fluxos no formato NetFlow
22 sfcapd capturador de fluxos no formato sFlow

22 nfdump leitor de fluxos capturados
22 nfprofile processador de filtros para criao e armazenamento de perfis de fluxos.
22 nfreplay replicador de fluxos
22 nfclean.pl coletor de lixo; removedor de fluxos antigos
11 NFSen uma interface web para apresentao dos dados coletados pelo NFDump, que permite
o manuseio dos fluxos de uma forma mais simplificada, permitindo entre outras coisas:
22 Visualizao dos fluxos em relatrios e grficos
22 Navegao pelos fluxos
22 Sumrio de estatsticas
22 Aplicao simplificada de filtros
22 Configurao de perfis de trfego
22 Permite o uso de plugins
22 Permite a configurao de alertas
22 Re-configurao fcil com o comando nfsen
Consideraes finais
11 Problemas
22 Os fluxos no so classificados pelo contedo
22 Fluxos perdidos tornam a informao imprecisa
22 O espao em disco consumido no coletor grande
Figura 7.13
Interface para
anlise de fluxos
do NFSen.
22 Os relatrios e grficos no subtituem o humano na anlise

201
11 Qual o valor agregado com o uso de fluxos?
22 Granularidade nas informaes

22 Inspeo pouco intrusiva
22 Melhor conhecimento da rede
2 Viso ampla, pontual e histrica
2 Apoio na anlise de problemas de rede
O uso de fluxos traz muitas vantagens para os administradores de rede, mas a tecnologia
no perfeita.
As informaes derivadas dos fluxos so baseadas puramente em cabealhos, ou seja, o
contedo no inspecionado. Essa caracterstica interessante, pois h pouca intruso no
trfego passante, porm isso tambm evita a verificao profunda do trfego, tornando a
classificao imperfeita, feita com base apenas nos protocolos e portas utilizadas.
Os fluxos perdidos causam imprecises nos relatrios. As implementaes atuais possuem
mtodos para descobrir se houve perda de fluxo e complementar a informao mostrada
para o administrador. A perda de fluxos pode ser minimizada com um bom acoplamento do
desempenho da sonda e do coletor em relao quantidade de fluxos a ser tratada.
Um fator impeditivo no uso de monitoramento de fluxos a quantidade de espao em disco
utilizada pelo coletor para armazenar o histrico de fluxos. Redes de alta capacidade geram
uma quantidade de fluxos absurdamente alta, muitas vezes, levando ao uso de amostras de
trfego e consequentemente impreciso nos relatrios.
Ainda que os fluxos revelem informaes valiosas, eles de nada servem sem um humano
com a capacidade analis-los corretamente.
A justificativa para se usar fluxos que eles permitem uma granularidade melhor que o
uso de medidores de trfego de interface, por exemplo. Enquanto uma medio por SNMP
fornece apenas a informao da uso de uma interface, o monitoramento de fluxo diz quais
mquinas clientes usaram e a quantidade de banda utilizada por cada uma.
Como o monitoramento de fluxos no inspeciona o contedo, ele menos intrusivo que outras
tecnologias e menos sujeito a reclamaes de invaso de privacidade por parte dos usurios.
O melhor conhecimento da rede calca-se no fato ser possvel verificar facilmente picos de
uso, tendncias, desempenho de aplicaes, atividade maliciosa etc.
Com a tecnologia de fluxos possvel ter uma viso ampla da situao, mas tambm
possvel verificar problemas pontuais e at mesmo ter uma viso do passado para se ter um
referencial de comparao.
202
Com tudo isto, o uso de fluxos mais uma facilidade para resolver problemas de rede, as
informaes deles derivadas podem indicar imediatamente um problema especfico ou
podem ser usadas em conjunto com outras ferramentas para se chegar a uma soluo.
Referncias
11 SINGER, A.; BIRD, T. Building a Logging Infrastructure. The USENIX Association. 2004.
ISBN: 978-1-9319-7125-6
11 KENT, K.; SOUPPAYA, M. Guide to Computer Security Log Management: Recommendations of the National Institute of Standards and Technology. NIST Special Publication
800-92. 2006. http://csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf
11 REID, Gavin. Cisco CSIRT on Advanced Persistent Threat. 2011. Cisco Blogs.
http://blogs.cisco.com/security/cisco-csirt-on-advanced-persistent-threat/ .
Disponvel em 23/09/2013.
11 Cisco IOS Netflow: http://www.cisco.com/web/go/netflow
11 InMon sFlow: http://www.sflow.org/
11 IPFIX: http://www.ietf.org/html.charters/ipfix-charter.html
11 Port Mirroring: http://en.wikipedia.org/wiki/Port_mirroring
11 Libpcap: http://www.tcpdump.org/
11 nBox: http://www.nmon.net/nBox.html
11 FlowMon Probe: http://www.invea-tech.com/products/flowmon-probes
11 fprobe: http://fprobe.sourceforge.net/
11 Softflowd: http://www.mindrot.org/projects/softflowd/
11 Pmacct: http://www.pmacct.net/
11 nProbe: http://www.ntop.org/nProbe.html
11 Plixer Scrutinizer: http://www.plixer.com/products/scrutinizer.php
11 ManageEngine Netflow: http://www.manageengine.com/products/netflow/
11 Lancope StealthWatch: http://www.lancope.com/products/
11 Flow-tools: http://www.splintered.net/sw/flow-tools/
11 NFDump: http://nfdump.sourceforge.net/
11 NFSen: http://nfsen.sourceforge.net/
11 SiLK: http://tools.netsa.cert.org/silk/
11 FlowScan: http://net.doit.wisc.edu/~plonka/FlowScan/
11 Arbor Networks Peakflow: http://www.arbornetworks.com/
203
204
8
Gerenciamento de performance
e qualidade de servio
de QoS. Entender o QoS na Internet. Conhecer as caractersticas do provisionamento
de trfego. Entender os Tipos de Servios. Conhecer o mecanismo de Service Level
Agreements (SLA). Conhecer os mecanismos de implementao de QoS. Entender as
mtricas e os padres para o gerenciamento de rede. Conhecer as ferramentas de
diagnstico/monitorao da rede.
Viso Geral Sobre QoS, Qos na Internet, Servios Diferenciados, Condies de provisioAgreements, Mecanismos para implementar QoS, Gerenciamento de Congestionamento,
Mecanismos de policiamento e conformao, Mtricas para o gerenciamento de rede,
Padres para Monitorao da Rede, Fluxos, Disponibilidade, Ferramentas de diagnstico
conceitos
namento de trfego, Tipos de Servios, Provisionamento e configurao, Service Level
e monitorao da rede
Introduo
Embora a capacidade de banda atualmente disponvel seja bem superior ao que havia h
cinco anos, por exemplo, em funo dos backbones em fibra tica, ainda assim insuficiente,
pois o trfego continuamente cresce at o limite da capacidade instalada. preciso gerenciar
continuamente a performance da rede e desencadear medidas paliativas quando necessrio.
Expandir a capacidade nem sempre a soluo possvel, especialmente por razes de custo,
mas que tambm pode ser inibida por limites da tecnologia disponvel. Por isso, necessrio
avaliar se o uso da rede apropriado, se no est ocorrendo uso suprfluo, com aplicaes
no prioritrias ou que no apoiem a misso da instituio, gerando trfego, em detrimento
de aplicaes relevantes e necessrias. Isso leva necessidade de definio e implantao
de alguma forma de provimento de servios com nveis de qualidade diferenciada. A qualidade de servio pode ser gerenciada na internet com o apoio de solues que permitam
atender diferentes parcelas do trfego com estratgias de priorizao diferenciadas.
O Gerenciamento da Qualidade de Servio, que costuma ser designado como Qos (Quality
of Service), precisa ser acompanhado de gerenciamento de banda. Os mecanismos de Qualidade de Servio a serem utilizados so derivados do que combinado no contrato de pres-
Captulo 8 - Gerenciamento de performance e qualidade de servio
objetivos
Entender o gerenciamento de qualidade de servios (QoS). Aprender os fundamentos
tao de servio, e esse acordo usualmente referido como SLA (Service Level Agreement).
205
Necessidade de redes com o conceito de qualidade de servios (QoS):
11 Novas aplicaes:
22 Videoconferncia e telemedicina;
22 educao a distncia.
11 No funcionam adequadamente em redes baseadas em melhor esforo, como a internet.
A questo : qual o melhor mecanismo para implementar QoS? Na dcada de 1990, foram
propostos modelos para internet, como o Integrated Services e o Differentiated Service
(DiffServ), os quais abordam vrios tipos de servios, incluindo servios best-effort e real-time,
alm de permitir reserva de banda.
O IntServ ou Servios Integrados um modelo de implementao do QoS desenvolvido para
garantir a qualidade do servio para fluxos individuais de trfego, usando para tanto a sinalizao fim-a-fim e a reserva de recursos por toda a rede, dos roteadores intermedirios at o
roteador de destino. O modelo de servios integrados caracterizado pela reserva de recursos.
Antes de iniciar uma comunicao, o emissor solicita ao receptor a alocao de recursos
necessrias para definir-se uma boa qualidade na transmisso dos dados. O protocolo Resource
Reservation Protocol (RSVP) utilizado, nesse modelo, para troca de mensagens de controle de
alocao dos recursos. A alocao de recursos diz respeito largura de banda e ao tempo em
que ser mantida a conexo. Nesse perodo de tempo, o emissor daquele servio tem uma faixa
da largura de banda disponvel para transmitir seus dados (Santos, 1999).
Modelo atual na internet:
11 Servio do tipo best-effort, onde todo o trfego tratado da mesma forma e o

melhor esforo empregado para entreg-lo.
Modelo esperado pela comunidade internet:
11 Aplicaes sensveis ao tempo, como voz e vdeo.
11 Tratamento preferencial para alguns tipos de trfego de aplicaes.
Demonstrao
O modelo de servios diferenciados (DiffSev) implementa QoS com base na definio de
tipos de servios. No cabealho de um pacote IP, existe um campo chamado TOS (Type of
Service), que pode representar o tipo do servio. Esse campo inclui poucos bits, conhecidos
como IP Precedence, que so usados para priorizar trfego atravs de enfileiramento diferenciado dentro de roteadores. Por exemplo, trfego de alta prioridade, indicado pelo valor
mais alto do campo IP Precedence, deve ser colocado na fila de alta prioridade no roteador e
repassado antes dos pacotes das filas de baixa prioridade.

O DiffServ uma arquitetura que foi inicialmente implantada na internet2, mas que se popularizou e atualmente oferecida na maioria dos roteadores. A gerncia da Qualidade de Servio
da rede (Service Level Managament ou SLM) demanda duas estratgias, uma para implantar e
configurar os equipamentos que vo proporcionar o tratamento diferenciado ao trfego e outra
para monitorar a performance da rede com ou sem priorizao. No primeiro caso, preciso
conhecer os mecanismos usados na soluo DiffServ e, no segundo caso, utilizar mtricas e
ferramentas para a medio da performance. Empregar QoS na rede implica em (Cisco 1999):
11 Controle sobre os recursos: controlar quais so os recursos que esto sendo usados
(bandwidth, equipamentos, facilidades de wide-area etc.). Por exemplo, limitar a banda
consumida sobre um backbone por uma transferncia de File Transfer Protocol (FTP) ou
dar prioridade a uma base de dados importante;
206
11 Servios particulares: no caso de um ISP, o controle e a visibilidade providos pelo QoS

habilita o oferecimento de servios diferenciados a seus clientes;
11 Coexistncia de aplicaes de misso crtica: o QoS garante que a rede ser utilizada
eficientemente por aplicaes de misso crtica; que o bandwidth e atrasos requisitados
por aplicaes sensveis ao tempo estaro disponveis; e que outras aplicaes, utilizando
o link, no afetaro o trfego de misso crtica.
Viso Geral Sobre QoS

Quality of Service ou Qualidade de Servio: a qualidade necessria para satisfazer o
usurio de uma dada aplicao.

Aplicaes necessitam de QoS diferentes:
11 Telefonia;
11 Videoconferncia;
11 Download de arquivos;
11 TV.
A necessidade de QoS na internet um fato. At hoje, a internet tem oferecido apenas
servio do tipo best-effort. Outros modelos para internet:
11 Integrated Services;
11 Differentiated Service (DiffServ).
Qualidade de Servio refere-se habilidade da rede em prover melhores servios a um
trfego de rede selecionado, sobre vrios tipos de tecnologias. Em particular, caractersticas
de QoS proveem melhores e mais servios de redes, uma vez que:
11 Suportam bandwidth dedicado;
11 Possuem melhorias em relao perda;
11 Mecanismos para evitar e gerenciar congestionamento de rede;
11 Mecanismos para conformao do trfego da rede;
Dentro da arquitetura de QoS, os seguintes componentes so necessrios para viabilizar o

atendimento do trfego com qualidade diferenciada em redes:
11 Mecanismos de QoS dentro de um nico elemento de rede, o qual inclui funcionalidades
de enfileiramento, tratamento diferenciado de filas e conformao de trfego;
11 Tcnicas de sinalizao QoS fim a fim entre os elementos de rede;
11 Funcionalidades de policiamento e gerenciamento de QoS para controlar e administrar
trfego fim a fim atravs da rede.
Nem todas as tcnicas so apropriadas a todos os roteadores da rede, porque roteadores
de borda e roteadores de backbone necessariamente no realizam as mesmas operaes;
assim, as tarefas de qualidade de servios podem ser diferentes (CISCO 1999).
Em geral, roteadores de borda realizam as seguintes funes de QoS:
11 Classificao de pacotes;
11 Controle de admisso;
11 Gerenciamento de configurao.
11 Mecanismos para configurao de priorizao de trfego atravs da rede.
207
Em geral, roteadores de backbone realizam as seguintes funes de QoS:

11 Gerenciamento de congestionamento;
11 Funo de evita congestionamento.
O modelos de servios QoS fim a fim

11 IntServ 1994 Integrated Services.
11 Protocolo RSVP: Resource Reservation Protocol.

11 Fluxo em tempo-real e fluxo best effort.
11 Gerenciamento de QoS no nvel de micro fluxos.
Cada aplicao que requeira algum tipo de garantia precisa fazer um pedido de reserva, e os
roteadores ao longo da rota podem enviar respostas concordando com o pedido de reserva.
Um modelo de servio, tambm chamado nvel de servio, descreve um conjunto de caractersticas QoS fim a fim. O QoS fim a fim a habilidade da rede em entregar requisitos de
servio para um trfego de rede especfico, de um fim da rede a outro. Encontramos trs
tipos de modelos de servios QoS: best-effort, integrated e differentiated services.
11 Best-Effort Service: o Best-effort um modelo de servio nico no qual uma aplicao
envia dados quando desejar, em qualquer quantidade, e sem requisitar permisso ou
informar primeiro a rede. Para servios best-effort, a rede entrega os dados se ela puder,
sem qualquer tipo de segurana de entrega, atraso associado ou throughput;
11 Servios Integrados: um modelo de servio mltiplo que acomoda mltiplos requisitos
de QoS. Nesse modelo, a aplicao requisita um especfico tipo de servio da rede antes
de enviar os dados. A requisio realizada atravs de sinalizao; a aplicao informa a
rede do seu perfil de trfego e requisita um tipo particular de servio. A aplicao envia
dados apenas depois que ela recebe a confirmao da rede. Envia dados de acordo com
as regras descritas no perfil de trfego. A rede realiza controle de admisso, baseada na
informao da aplicao e recursos de rede disponveis. Ela realiza a manuteno por
estado do fluxo e ento realiza classificao de pacotes, policiamento e enfileiramento
inteligente baseado nesse estado. Esse modelo utiliza o protocolo Resource Reservation
Protocol (RSVP) para sinalizar seus pedidos de QoS para o roteador;
11 Servios Diferenciados: um modelo de servios mltiplos que pode satisfazer diferentes tipos de requisitos de QoS. Entretanto, diferentemente do modelo de Servios
Integrados, uma aplicao usando Servios Diferenciados explicitamente no sinaliza o
roteador antes de enviar o dado. Para os servios diferenciados, a rede tenta entregar um
tipo particular de servio, baseado na especfica QoS de cada pacote. Essa especificao
pode ocorrer de diferentes maneiras. Por exemplo: usando o bit IP Precedence setado
208
em pacotes IP ou endereos de fonte e destino. A rede usa a especificao QoS para classificar, conformar e policiar trfego, e para realizar enfileiramento inteligente.
O modelo de servios diferenciados usado por inmeras aplicaes de misso crtica e
para prover QoS fim a fim. Tipicamente, esse modelo de servio apropriado para fluxos
agregados porque ele realiza classificao de trfego. Caractersticas do modelo de Servios
Diferenciados incluem:
11 O Committed Access Rate (CAR) realiza classificao de pacotes atravs do IP Precedence
e conjuntos de regras de QoS. O CAR realiza medies e policiamento de trfego, provendo gerenciamento de banda;
Random Early Detection

(RED), tambm conhecido como descarte preliminar aleatrio, uma
disciplina de enfileiramento fila para um programador de descartes
na rede que visa evitar
congestionamentos.
Em Weighted RED voc
pode ter diferentes
probabilidades para
diferentes prioridades
(precedncia IP, DSCP)
e/ou filas.
Weighted fair queuing
(WFQ)
Weighted Fair Queuing
(WFQ) uma tcnica de
programao de envio
(Scheduling) de pacotes
de dados que permite
diferentes prioridades
de agendamento para
os fluxos de dados
multiplexados
estatisticamente.
11 Esquemas inteligentes de enfileiramento, tal como Weighted random early detection

(WRED) e Weighted fair queuing (WFQ), podem ser utilizados com CAR para entregar
servios diferenciados.
O objetivo principal da nova internet suportar o avano das novas aplicaes de rede.
Ao contrrio do que deveria ser, muitas dessas aplicaes no so visveis na internet
atual, pelo fato de o modelo presente de entrega best-effort no prover a mnima
solicitao de performance fim a fim assegurada. Para habilitar essas aplicaes, a nova
internet deve prover qualidade de servio (QoS) funcional que permita a estas reservarem
recursos de redes-chave sem causar impacto no trfego best-effort.
Com o passar dos ltimos anos, as aplicaes internet e a comunidade de engenheiros tm
identificado um conjunto de requisitos para QoS na internet, baseado em necessidades de
aplicaes e de engenheiros. Na verdade, o internet2 QoS Working Group tem estudado
esses requisitos e recomendado a adoo de Differentiated Services (DiffServ) para QoS.
O framework DiffServ tem emergido nos ltimos anos como uma forma simples e escalar de
QoS que prov servios significativamente fim a fim atravs de mltiplas nuvens de rede administrativamente separadas, sem necessidade de complexidade. Objetivos que se igualam ao da
internet2 QoS nfase em simplicidade, escalabilidade, interoperabilidade e administrabilidade.
Qos na internet
Na internet atual, cada elemento ao longo do caminho do pacote IP no faz nada mais que o
melhor esforo para entregar o pacote a seu destino. Se a fila do roteador sobrecarregada,
pacotes so descartados com pouca ou nenhuma distino entre trfego de baixa prioridade e trfego urgente. Isso conhecido como servio best-effort.
Para funcionar corretamente, muitas aplicaes avanadas necessitam o mximo de banda
garantida e o mnimo de atraso do pacote (latncia), os quais o meri best-effort no pode
disponibilizar. Por exemplo, ferramentas remotas de colaborao, videoconferncia ou telemedicina geralmente tm requisitos de qualidade mais exigentes que podem ser descritos
em termos de demanda de banda e latncia mnimos. Se tais requisitos no forem atendidos, a aplicao pode ser inviabilizada.
Com vistas a poder oferecer QoS na internet, o internet2 QoS Working Group identificou
alguns requisitos:
11 Habilitar aplicaes avanadas;
11 Escalabilidade;
11 Administrao;
11 Medio;
11 Admitir mltiplas e interoperveis implementaes de pedaos individuais de equipamentos e nuvens;
11 Suporte de Sistemas Operacionais e middleware.
Quando algum pergunta qual a qualidade de servio que uma aplicao necessita da rede,
desenvolvedores de aplicaes costumam dizer coisas como: Eu necessito de toda a banda
que puder ser dada com pouca latncia, pouco jitter e pouca perda. Essa resposta na verdade
uma utopia. A realidade das redes faz com que os responsveis pelo desenvolvimento de
aplicaes procurem tornar o software capaz de ajustar-se a uma grande variedade de throuputs. Mas tudo tem limite. Se a rede no conseguir proporcionar um conjunto de requisitos de
Weighted random
early detection
(WRED)
qualidade mnimo, mesmo uma aplicao flexvel e tolerante no poder funcionar.

209
Para dar suporte ao desenvolvimento de aplicaes ditas avanadas, o protocolo de transporte internet, TCP, tem sido aperfeioado nos ltimos anos com vistas a adaptar-se e tentar
compensar os efeitos de congestionamento na rede. Mas nesse contexto no h limite para
os pedidos de conexo que vo sendo ativados. O que ocorre quando esse nmero aumenta
que a falta de recursos para atendimento de toda a demanda provoca uma degradao
gradual na performance das conexes. Por outro lado, em uma rede com QoS habilitada,
o usurio perceber um modelo de servio parecido com o sistema de telefonia. Ao tentar
estabelecer uma conexo, precisa iniciar a conexo e reservar os recursos necessrios.
Se isso for possvel, o usurio obtm um canal livre para transmitir, com os requisitos
solicitados. Alternativamente, no momento de call setup, o usurio talvez receba um sinal
ocupado e lhe seja negado o privilgio de conectar em um nvel de QoS desejado.
Saiba mais
Algumas aplicaes
requerem tambm
jitter limitado (variao
no atraso dos pacotes),
embora a maioria
mascare o jitter atravs
de buffers.
Uma dimenso fundamental de qualquer requisito de QoS de aplicao o conjunto de

parmetros de transmisso. Os parmetros de transmisso mencionados como requisitos
bsicos so banda passante e latncia.
Existe um aspecto importante a considerar na implementao de um servio com QoS
garantida relativo ao tempo de durao do servio. Para gerenciar a ativao e o ajuste dos
mecanismos de garantia de QoS, necessrio utilizar funcionalidades de gerenciamento de
configurao para propagar na rede os parmetros relativos aos mecanismos de tratamento
diferenciado que so inerentes a um sistema de oferta de servios de rede com QoS. Adicionalmente, existem questes a considerar quando o servio cresce e precisa ser oferecido ao
longo de uma trajetria que envolva mais de um domnio administrativo.
A figura seguinte ilustra os elementos integrantes do sistema de oferta de servios de rede
com QoS. O trfego ingressa na rede atravs de algum dos roteadores de borda, proveniente de algum equipamento final de usurio ou de alguma outra rede interconectada. Nos
roteadores de borda, os pacotes so inspecionados e eventualmente marcados para que os
roteadores de trnsito da rede tenham informaes que apoiem as decises de tratamento
diferenciado ou no para os diversos fluxos de pacotes.
Roteador
de borda
Roteador
de borda
Como qualquer outro recurso, existe a necessidade de mecanismos para alocao e

contabilizao para QoS. Esses mecanismos devem operar eficientemente, provendo aos
usurios o acesso rpido s caractersticas de QoS que a rede capaz de prover.
Considerando a possibilidade de que instituies e eventualmente usurios venham a
pagar por servios de QoS, deve haver maneiras para que o usurio possa medir e auditar a
performance da rede. Os requisitos de medio implicam no apenas a necessidade de ferramentas de medio, mas tambm uma necessidade por mtricas de performance de rede.
Provedores de rede podem necessitar de ferramentas de medio adicionais para assistir o
provisionamento e depurao de servios de QoS, e possivelmente suportar mecanismos de
controle de admisso baseados em medidas automatizadas.
210
Figura 8.1
Elementos
integrantes de uma
rede com QoS.
Qualquer tipo de QoS escolhido para ser implementado deve ser suportado por um ou por
muitos fornecedores de equipamentos. Em redes heterogneas grandes, como a internet, a
interoperabilidade entre equipamentos de diferentes fabricantes absolutamente essencial.
Adicionalmente, a habilitao QoS em fluxos e sinalizao de call setup deve ser tratada de
maneira padronizada em ligaes entre redes sob administraes diferentes, mesmo que
cada uma das redes possa implementar QoS internamente de diferentes maneiras. Implementaes internas de QoS podem variar, dependendo das tecnologias empregadas na rede,
do policiamento interno e das decises de provisionamento.
Interoperabilidade entre
diferentes elementos de rede
Dominio DS
Dominio DS
Interoperabilidade entre nuvens

com administrao separadas
Interoperabilidade crucial
para prover QoS m a m
Figura 8.2
Interoperabilidade
entre redes.
Essa uma situao tpica de ambiente na nova internet. Como as interconexes so

separadas por diferentes controles administrativos, existe a necessidade de padronizar a
noo de QoS atravs rede interoperantes.
Servios Diferenciados
A arquitetura de servios diferenciados (referida como Diffserv) procura prover um espectro
de servios na internet sem ter de manter estados de fluxos para cada roteador. Isso ocorre
atravs da unio de fluxos dentro de um pequeno nmero de agregados, aos quais oferecido
e armazenamento de informaes sobre cada fluxo individual no roteador do core. Cada
fluxo policiado e marcado no primeiro roteador por onde for encaminhado e que integre
o servio Diffserv. Isso acontece de acordo com o perfil de servio contratado. Na viso do
administrador de rede, o primeiro roteador um roteador-de borda na periferia da rede. Esse
roteador responsvel por realizar o policiamento e marcao dos pacotes recebidos dos
hosts usurios da rede. Quando uma deciso de controle de admisso local for feita pela rede,
o roteador configurado com o perfil de contrato do fluxo do servio. No trajeto a partir desse
roteador, todo o trfego integrante daquele perfil tratado como agregado.
definida atravs de um modelo simples no qual trfego que entra na rede :
11 Classificado;
11 Possivelmente condicionado na borda da rede;
11 Atribudo a diferentes agregaes de comportamento.
Cada agregao de comportamento definida por um nico DS field.
Dentro do core da rede, os pacotes so encaminhados de acordo com o per-hop behavior
associado com o DS field.
um tratamento diferenciado pela rede. O Diffserv elimina a necessidade de reconhecimento
211
A arquitetura de servios diferenciados baseada em um modelo simples no qual o trfego

que entra na rede classificado, possivelmente condicionado na borda da rede e atribudo a
diferentes agregaes de comportamento. Cada agregao de comportamento definida
por um nico DS codepoint. Dentro do core da rede, os pacotes so encaminhados de
acordo com o per-hop behavior associado com o DS codepoint.
Ns de sada podem condicionar o trfego

para que esteja de acordo com o SLA
estabelecido com o domnio downstream
SLA agregado
Ns internos escalonam e encaminham;

Podem realizar conformao limitada
(reshaping) de trfego
Ns de entrada asseguram que o trfego

de entrada esteja de acordo com o SLA
estabelecido com o domnio upstream
ou com o cliente
Figura 8.3
Arquitetura
fsica de Servios
Diferenciados.
Essa arquitetura composta por vrios elementos funcionais implementados em nodos de

rede, incluindo um pequeno conjunto de per-hop behaviors, funes de classificao de
pacotes e funes de condicionamento de trfego incluindo: medio, marcao, conformao e policiamento. Essa arquitetura alcana escalabilidade implementando classificao
complexa e funes de condicionamento apenas nos nodos de borda de rede, e implementando per-hop behaviors para agregaes de trfego as quais so apropriadamente
marcadas usando o campo DS. O per-hop behaviors (PHB) definido para permitir uma
mdia granular razovel de alocao de buffer e recursos de largura de banda em cada nodo.
PHB
PHB
Figura 8.4
Comportamento de
encaminhamento.
DS Behavior Aggregate
Tratamento de encaminhamento que os pacotes recebem nos roteadores:
PHB EF (Expedited Forwarding)
212
Encaminhamento expresso (acelerado).

Baixa perda, retardo e variao do retardo (jitter).
Preferncia total de encaminhamento.
DSCP = 101110
PHB AF (Assured Forwarding)
Grupo de PHBs de encaminhamento assegurado.
Quatro classes de servios com trs nveis de descarte.
Define tratamentos diferenciados aos pacotes, do tipo melhor que o melhor esforo.
Assim, o PHB responsvel pelo tratamento de encaminhamento que os pacotes recebem

nos roteadores. H dois tipos bsicos de PHBs (Nichols 98):
11 PHB EF (expedited Forwarding):
22 Encaminhamento expresso (acelerado);
22 Pouca perda, retardo e variao de retardo (jitter);
22 Preferncia total de encaminhamento.
11 PHB AF (Assured Forwarding):
22 Grupo de PHBs de encaminhamento assegurado;
22 Quatro classes de servios com trs nveis de descarte;
22 Define tratamento diferenciado aos pacotes, do tipo melhor que o melhor esforo: BBE.
Esses servios so entregues aps uma negociao de contrato entre o provedor e o cliente,
respeitando os servios a serem providos. Esse contrato conhecido como Service Level
Agreements (SLAs).
Um domnio DS um conjunto contguo de nodos DS os quais operam com um servio de
provisionamento de policiamento comum e um conjunto de grupos de PHB implementados
em cada nodo. Um domnio DS normalmente consiste de uma ou mais redes dentro de uma
mesma administrao. A administrao de um domnio tem a responsabilidade de assegurar que recursos adequados sejam provisionados e/ou reservados para suportar o SLA
oferecido pelo domnio.
Dominio DS
DS Boundary Node
SLA
Dominio DS
SLA
SL
No DS-Compliant
Dominio DS
voz
Figura 8.5
Arquitetura
lgica de Servios
Diferenciados.
SLA
vdeo
DADOS
SLSs e TCSs
Para cada servio, diferentes aspectos tcnicos do servio a ser provido so definidos em
forma de um Service Level Specification (SLS), que especifica todas as caractersticas e a
performance esperadas pelo cliente. Devido ao fato de os servios DS serem unidirecionais,
as duas direes de fluxo devem ser consideradas separadamente. Um subset importante
do SLS o Traffic Conditioning Specification ou TCS.
Dominio DS
Figura 8.6
TCS Traffic
Conditioning
Specification.
SLS
Subset - TCS
Nodo DS-compliant
SLS
Subset - TCS
Cliente
Legacy Node
Nodo DS-compliant
213
O TCS especifica perfis de trfego e aes para pacotes dentro do perfil (in-profile) e fora do
perfil (out-of-profile). Perfis de trfego so responsveis por especificar regras para classificar e medir um fluxo, identificar quais so elegveis e definir regras para determinar se um
pacote est dentro ou fora do perfil. Um pacote dentro do perfil pode ser adicionado a uma
agregao de comportamento diretamente, enquanto um pacote fora do perfil pode ser
conformado antes da entrega da seguinte forma:
11 Pode ser atrasado at que esteja dentro do perfil;
11 Pode ser descartado.
Entre os parmetros de servio para cada nvel de servio que o TCS especifica, temos:
11 Parmetros de performance, tais como: throughput, probabilidade de descarte e latncia;
11 Indicao do escopo de cada servio nos pontos de ingresso e sada;
11 Perfis de trfego;
11 Disposio do trfego submetido em excesso ao perfil especificado;
11 Marcao do servio proporcionado;
11 Conformao do servio proporcionado.
Servios quantitativos e qualitativos

A arquitetura de Servios Diferenciados pode suportar uma grande variedade de diferentes
tipos de servio. Classificar esses servios significa associar um SLS a um servio respectivo.
Alguns servios podem ser claramente classificados como qualitativos ou quantitativos,
dependendo do tipo de parmetros de performance oferecidos. Servios qualitativos so
aqueles que oferecem garantias relativas que somente podem ser avaliadas por comparao. Como exemplo de servios qualitativos, temos:
11 O trfego oferecido no nvel de servio A ser entregue com baixa latncia;
11 O trfego oferecido no nvel de servio B ser entregue com baixa perda.
Servios quantitativos so aqueles que oferecem garantias concretas que podem ser avaliadas por medies convenientes, independentes de outros servios. Como exemplos de
servios quantitativos, temos:
11 90% do trfego entregue dentro do perfil no nvel de servio C no ter mais do que 50ms
de latncia;
11 95% do trfego entregue dentro do perfil no nvel D ser efetivamente entregue.
Como servios que possuem quantificao relativa, temos:
11 O trfego oferecido no nvel de servio E ter duas vezes mais banda do que o nvel F;
11 O trfego com drop precedence AF12 tem uma prioridade de entrega maior de que o
trfego com drop precedence AF13.
De uma forma geral, quando um provedor oferece um servio quantitativo, ser necessrio
especificar perfis de policiamento quantitativo.
SLS dinmico vs. esttico

Os SLSs podem ser estticos ou dinmicos. Os SLSs estticos so a norma atualmente, e
so um resultado da negociao entre o provedor e o cliente. Um SLS esttico definido
por um acordo de data de incio e pode ser periodicamente renegociado (em ordem de dias,
semanas ou meses). Todavia, o SLS pode especificar que o nvel de servio mude em certas
horas ao dia ou certos dias na semana, mas o contrato permanece esttico.
214
O SLS dinmico, ao contrrio, pode mudar frequentemente. Tais mudanas podem resultar,
por exemplo, de variaes na carga de trfego oferecida, relativa a thresholds ou de
mudanas no preo oferecida pelo provedor. Os SLSs dinmicos mudam sem interveno
humana e requerem protocolos automatizados.
Condies de provisionamento de trfego em dispositivos de borda para provedores de servios

Uma vez que um SLS tenha sido negociado, o provedor de servio (e opcionalmente o
cliente) vai configurar componentes de condicionamento de trfego no limite das duas redes.
Assim, o provedor de servio tem como obrigao garantir os recursos ao cliente, porm sem
que os recursos excedam os termos do TCS. E o cliente, ao contrrio, tem como objetivo fazer
o melhor uso do servio adquirido do provedor. O trfego do cliente talvez seja autenticado
por conexes fsicas atravs das quais ele chega ou por sofisticada criptografia.
Os quatro componentes de condicionamento de trfego so:
11 Medidor;
11 Marcador;
11 Conformador;
11 Descartador.
Origem
Destino
Figura 8.7
Componentes do
condicionamento.
Nodo DS
Marcao
de pacotes
Core
Nodo de sada
Conformao
da agregao
Nodo de ingresso
Classicao,
policiamento e
marcao de agregao
A combinao e interao de componentes de condicionamento de trfego so selecionadas

em bases de pacotes por pacotes pelo DS codepoint. Os parmetros de configurao para
componentes em cada codepoint so determinados por policiamento e perfis aplicados;
dessa forma, o condicionador policia o trfego baseado no Behavior Aggregate (BA)
especificado pelo codepoint. Os medidores medem o trfego submetido de acordo com o
perfil de trfego contratado (TCS), provendo controle de entrada para os outros componentes os quais implementam o policiamento:
11 Os conformadores policiam atrasando alguns ou todos os pacotes de uma sequncia de
trfego, de modo a levar o fluxo a tornar-se complacente com o perfil de trfego. Um conformador tem geralmente um tamanho de buffer finito e pacotes podem ser descartados
se no houver espao de buffer para assegurar o atraso dos pacotes;
11 Os descartadores policiam, descartando alguns ou todos os pacotes de uma sequncia
de trfego, de modo a levar o fluxo a tornar-se complacente com o perfil de trfego. Esse
processo conhecido como policiamento de fluxo. Note que o descartador pode ser
Core
implementado como um caso especial de um conformador, setando o tamanho do buffer

para zero (ou quase);
215
11 Os marcadores policiam o trfego remarcando o trfego com um codepoint particular,

somando o pacote a um comportamento DS particular. Isso ocorre:
22 Mapeando codepoint/PHB especfico do domnio;
22 Rebaixando o fluxo fora do perfil de trfego.
Em soma a esses quatro componentes, classificadores de trfego so requisitados para
separar o trfego submetido dentro de diferentes classes. Os classificadores podem separar
o trfego baseado no campo DS ou podem faz-lo baseado em mltiplos campos dentro do
cabealho do pacote e at a partir do payload do pacote. Na maioria da vezes, o trfego vai
chegar ao limite de um DS-domain pr-marcado e pr-modelado. Mesmo que o trfego do
cliente venha pr-marcado e pr-modelado, o provedor de servio poder realizar policiamento de trfego no limite do ponto de ingresso, de modo a atender os prprios interesses
do domnio. Isso pode resultar em que o trfego seja remarcado ou descartado.
Um condicionador de trfego inclui:
11 Classificador;
11 Medidor;
11 Marcador;
11 Suavizador;
Condicionadores de trfego podem ser encontrados dentro de um domnio DS, na borda de
um domnio. Nem todos os quatro elementos do condicionamento precisam estar presentes
em todos os ns de borda. Uma viso lgica de condicionamento de trfego mostrada na
figura a seguir:
Medidor
Pacotes
Classicador
Marcador
Figura 8.8
Viso lgica de
um classificador e
condicionador de
trfego.
Conformador/
Descartador
Note que o condicionamento de trfego pode no necessariamente conter todos os quatro

elementos. Por exemplo, em casos onde no h um profile de trfego, pacotes podem
apenas passar por um classificador e um marcador.
11 Medidor (meter): mede o fluxo para verificar se est de acordo com o perfil de
trfego contratado (TCS).
O provedor deve provisionar nodos internos na sua rede, de modo a atender as garantias
216
oferecidas pelos SLSs negociados no limite da rede. Para fazer isso, o provedor pode usar
mecanismos de condicionamento de trfego similares aos usados no limite da rede. O
provedor pode policiar periodicamente dentro da rede, por remodelagem, remarcao ou
descarte de trfego.
A arquitetura de servios diferenciados prope que um servio fim a fim pode ser construdo pela concatenao de servios de domnios e SLAs associados ao cliente-provedor
para cada um dos domnios onde o trfego venha a passar.
Tipos de servios
Todo tipo de transmisso pode ser tratada como dados. Uma vez que um sinal analgico
convertido para um sinal digital, ele pode ser tratado como se fosse um pedao de dados.
Entretanto, diferentes tipos de transmisso podem possuir diferentes tipos de requisitos.
Tanto voz como transmisses de vdeo de baixa qualidade apresentam alta tolerncia a
erros. Se um pacote ocasionalmente descartado, a fidelidade na reproduo de voz e vdeo
no ser severamente afetada. Em contraste, pacotes de dados tm baixa tolerncia a erros.
Um bit errado pode mudar o significado dos dados.
Transmisso de voz, vdeo e dados tambm tm diferentes requisitos em relao a atrasos.
Para que uma voz, que foi encapsulada em um pacote, possa ser traduzida para um sinal
analgico, o atraso de rede para esses pacotes devem ser constantes e baixos. No caso de
pacotes de dados, o atraso de rede pode variar consideravelmente. Pacotes de dados podem
ser transmitidos de forma assncrona atravs da rede, sem se importar com o tempo entre
o emissor e o receptor. Em contraste, a transmisso de vdeo deve possuir uma relao de
tempo entre o emissor e o receptor.
Pacotes de vdeo e voz, ocasionalmente, podem ser perdidos ou descartados. Em casos
de eventos de excessivo atraso na rede, os pacotes podem ser descartados porque j no
possuem utilidade. Essa perda no afeta severamente a fidelidade da voz, se a perda de
pacotes for menor que 1% do total de pacotes transmitidos.
A transmisso de voz e vdeo tambm requer um tamanho de fila pequeno nos nodos da
rede, de modo a reduzir o atraso e torn-lo previsvel. Um tamanho de fila de pacotes de voz
pequeno pode prevenir um overflow ocasional, o qual poderia resultar na perda de pacotes.
Entretanto, pacotes de dados requerem uma fila de tamanho grande, de modo a prevenir
que pacotes possam ser perdidos em condies de overflow.
A seguir sero descritos exemplos de servios e como eles podem ser suportados por
especficos PHBs. Lembremos que tais exemplos tm carter to-somente ilustrativo, em
se considerando a grande quantidade de servios que podem ser empregados usando o
Internet
SAP
Figura 8.9
Tipos de servios
diferenciados.
Internet
Servio Olmpico
Servio Premiun
Servio Assegurado
Vdeo
SAP
Vdeo
Servio melhor que best-effort

Esse um servio quantitativo que promete transportar trfego de webservers em uma
prioridade maior que a usada no mtodo best-effort. Esse tipo de servio oferece perda de
performance (no quantificada) relativa de um dado ponto de ingresso a qualquer outro
ponto de sada. Tambm conhecido como servio do tipo Olmpico, no qual o contrato
modelo de servios diferenciados.
refere-se ao servio melhor, relativo a quem paga menos. Tem as seguintes caractersticas:
217
11 O PHB nesse caso descarta as classes inferiores primeiro (AF);

11 Tem como regra de policiamento descartar ou remarcar pacotes fora de perfil;
11 Tambm chamado de Classe of Service;
11 Tem como classes olmpicas de servio de melhor esforo:
22 Ouro;
22 Prata;
22 Bronze.
Os pacotes submetidos para o servio BBE devem ser marcados com o codepoint do campo
DS correspondente a AF11 PHB. O provedor tem a promessa de transportar o trfego de
1 Mbps do ponto de ingresso para qualquer ponto de sada a uma prioridade maior que a
do best-effort. Uma classe de servio menor, correspondente a AF13 PHB, ser aplicada ao
trfego submetido pela AF11 PHB, que exceder 1 Mbps.
O provedor tem de prover um policiamento no ponto de ingresso. O trfego submetido at o
limite de 1 Mbps ser direcionado ao AF11 PHB. O trfego submetido em excesso ao 1 Mbps
ser remarcado para o AF13 PHB. Note que o esquema ser preservado ordenando os pacotes
desde que a AF11 e a AF13 usem uma nica fila.
De modo a prover esse servio, o provedor ter de implementar a AF11 PHB e a AF13 PHB
no equipamento do core da rede, que tambm dever ser devidamente provisionado para
receb-las.
A AF11 PHB e a AF13 PHB podem ser implementadas, por exemplo, usando uma fila do tipo
RIO (Red with In or Out). Provisionando parmetros do tipo RED, por exemplo, o provedor est
apto a controlar a prioridade do trfego AF11 relativo ao trfego AF13 em cada nodo da rede.
Servio de emulao de linhas privadas

Esse um servio quantitativo que emula o servio de linhas privadas tradicionais. Ele
promete entregar o trfego do cliente com pouca latncia e pouqussima probabilidade de
descarte, at a taxa negociada. Acima dessa taxa, o trfego descartado. Esse tipo de servio
encontrado tipicamente entre dois pontos especficos. Ele se encaixa para muitas aplicaes de clientes. Entretanto, devido alta garantia de qualidade, ele acaba tendo um preo
mais alto que servios alternativos. Assim, ele acaba sendo utilizado apenas por aplicaes
que necessitam realmente desse tipo de servio. Um exemplo de aplicao a telefonia IP.
Esse servio tambm conhecido como servio do tipo Premium, no qual o contrato se refere
emulao de linha dedicada a uma taxa de pico especfica, e tem as seguintes caractersticas:
11 O PHB nesse caso tem como regra encaminhar o pacote primeiro (EF);
218
11 Tem como regra de policiamento o descarte de pacotes fora de perfil;

11 Na sada, os domnios devem conformar agregaes EF para mascarar rajadas.
Como um exemplo, considere-se um cliente com trs redes geograficamente dispersas,
interconectadas via um nico provedor de rede. Os pontos de conexo do cliente sero
identificados como A, B e C. Em cada ponto conectado, um SLS descreve o servio de linha
privada a ser provido aos outros pontos. A informao a seguir representa a informao
requisitada no TCS da conexo do ponto A:
11 EF-Mark: 100 Kbps: ponto de sada B: descarte de trfego no conforme;
11 EF-Mark: 50 Kbps: ponto de sada C: descarte de trfego no conforme.
Os pacotes submetidos pelo servio de linha privada devem ser marcados com o codepoint
no campo DS correspondente a EF PHB [EF]. Do ponto de ingresso A para o ponto de sada B,
o provedor promete transportar at 100 kbps de trfego. O trfego excedente ser descartado. Do ponto de ingresso A, para o ponto de sada C, o provedor promete transportar
50 Kbps de trfego. claro, existem algumas tolerncias requisitadas em policiamento de
trfego, como jitter e tamanho de rajada. Entretanto, para servios de linha privada, o primeiro parmetro de perfil de trfego pode ser o sustained traffic rate.
O provedor provisionar policiamento no ponto de ingresso A para limitar o trfego destinado ao ponto de sada B a 100 Kbps. Similarmente, um policiamento ser configurado,
de modo a limitar o trfego destinado ao ponto de sada C a 50 Kbps. Esses policiamentos
requerem classificao baseada no DS-mark e o endereo de destino em cada pacote.
A fim de prover esse servio, o provedor ter de implementar a EF PHB no equipamento
do core da rede. A EF PHB pode ser implementada usando strict priority queuing ou,
alternativamente, aplicando pacotes marcados com EF no esquema WFQ (heavily weighted
queue). O provedor ter de provisionar equipamentos no core da sua rede. Por exemplo,
roteadores transportando trfego entre o ponto A e ponto B e/ou C tero que ser provisionados considerando-se os recursos comprometidos pelo TCS no ponto A. Isso significa
que um roteador o qual essa no caminho de A e B e de A e C, ter de ser considerado como
tendo comprometido 150 Kbps de sua largura de banda como resultado do TCS colocado
em A. Um roteador, apenas no caminho entre A e B, ter de ser considerado como tendo um
comprometimento de 100 Kbps como resultado do TCS. claro, o roteamento est sujeito a
mudar, falhas nos caminhos podem tambm ser provisionadas. Para aumentar a segurana
oferecida pelos servios EF, os provedores podem empregar mecanismos de roteamento,
como: route pinning mechanisms ou QoS routing mechanisms.
Servio quantitativo assegurado: Media Playback

Esse servio oferece menor garantia que o servio de linha privada recm-descrito, mas ele
ainda considerado um servio quantitativo. Em particular, ele promete entrega de trfego
com alto grau de confiana e com latncia varivel, porm limitada, at a taxa negociada.
servio tipicamente oferecido entre um conjunto especfico de pontos e empregado em
muitas aplicaes de clientes.
Devido sua variao de latncia, ele acaba saindo mais em conta que o servio de linha
privada. Entretanto, devido ao seu limite de latncia e alto grau de entrega, ele acaba tendo
preo maior que outros servios alternativos. Tal servio destinado particularmente a
playback de udio ou vdeo, no qual uma largura de banda considervel necessria em bases
contnuas, mas a natureza no interativa do trfego torna-o um pouco tolerante a atrasos.
Tambm conhecido como servio do tipo Assegurado, no qual o contrato afirma que a
rede parece estar levemente carregada para trfego em perfil especificado (taxa e rajada).
Tem as seguintes caractersticas:
11 O PHB nesse caso descarta por ltimo (AF);
11 Tem como regra de policiamento remarcar pacotes fora do perfil para que tenham uma
probabilidade de descarte maior;
11 O trfego em uma classe compartilha fila nica;
11 Na sada, os domnios podem tambm visualizar agregaes AF.
Acima dessa taxa, o trfego sujeito a um atraso ou descarte significativo. Esse tipo de
219
Os pacotes submetidos ao servio de playback confivel devem ser marcados com o codepoint do campo DS correspondendo a AF11 PHB. Do ponto de ingresso A para o ponto de
sada B, o provedor promete um transporte at 100 Kbps do trfego tolerado (sustained
traffic) com rajadas (burst) de 100 Kbps de tamanho e taxa de pico de 200 Kbps. Rajadas de
trfego excedentes sero marcadas com o codepoint AF12 e o trfego fora do perfil ser
transportado com o codepoint AF13. To logo essas condies sejam encontradas, a latncia
ser limitada a um segundo. Note-se que para esse servio o perfil de trfego descrito
usando um conjunto completo de parmetros de token bucket. Uma vez que o limite de
latncia para tal servio menos rigoroso que no servio de linhas privadas, um certo grau
de traffic burstiness pode ser tolerado.
O provedor deve suportar as AF11, AF12 e AF13 PHBs nos roteadores do core da rede. Essas
PHBs podem ser providas, por exemplo, direcionando o trfego marcado com AF11, AF12,
AF13 para uma nica fila RIO com alto limite de descarte. Os policiais na borda limitaro a
competio de trfego na linha com o TCS, de modo a assegurar que a latncia possa ser
encontrada. O provedor de servio ter de provisionar dispositivos no core da rede.
O provisionamento discutido em linhas privadas pode ser aplicado aqui, entretanto, em
geral, o provedor de servio tem a liberdade de ser menos conservativo no provisionamento
e realizar melhores ganhos estatsticos.
Provisionamento e configurao
O provisionamento de servios diferenciados requer provisionamento e configurao cuidadosa, e refere-se determinao e alocao de recursos necessrios em vrios pontos na
rede. O provisionamento pode:
11 Ditar a soma ou a remoo de recursos fsicos em vrios pontos (provisionamento fsico);
11 Definir a modificao de parmetros operacionais dentro de equipamentos existentes na
rede, de modo a alterar relativos compartilhamentos de recursos de rede os quais so
alocados a uma ou outra classe de servio (provisionamento lgico).
A configurao refere-se distribuio de parmetros operacionais apropriados para equipamentos de rede, de modo a alcanar objetivos de provisionamento. A configurao pode
ser feita utilizando protocolos como SNMP, CLI, RSVP, COPS e LDAP.
Provisionamento e configurao: Borda vs. Interior

11 Medidor, suavizador e descartador.
11 Classificador e marcador.
11 Mecanismos que permitem ler e escrever contedo de campos.
De modo a ser breve, consideremos o termo provisionamento como referncia a provisiona-
220
mento e configurao. O importante notar aqui que provisionamento na borda da rede deve
ser tratado separadamente de provisionamento no interior da rede. Desde que o provedor
de servios diferenciados vende um contrato (SLA) na borda da rede, podemos considerar o
provisionamento de borda, o qual suporta SLSs, como sendo o responsvel em determinar
o provisionamento do interior do provedor. Por exemplo, um operador de rede no pode
oferecer um SLS o qual no pode localizar recursos disponveis no interior da rede. De uma
forma geral, o processo geral de provisionamento interage entre bordas e interior. De agora
em diante, referenciaremos o provisionamento em respeito a TCS em vez de SLS, j que o TCS
um componente do SLS que define detalhes de parmetros de manipulao de trfego.
Provisionamento de borda
No mnimo, o provedor deve assegurar que recursos fsicos suficientes estejam provisionados
na borda de modo a poder encontrar os requisitos do TCS. Por exemplo, se a soma dos perfis
suportados em um ponto de ingresso permitir 10 Mbps de trfego, inaceitvel provisionar
o link com um acesso T1. Um T3, entretanto, seria suficiente. Uma vez que o provisionamento
fsico implementado, necessrio aplicar o provisionamento lgico apropriado. Isso alcanado via configurao de policiamento que limita a quantidade de trfego aceito pelo link T3,
em cada nvel de acesso e para duplos TCSs finais, para o ponto de sada apropriado.
Tambm pode ser necessrio configurar uma quantidade de buffer para as filas usadas para
o servio. O provisionamento similar tambm apropriado em cada ponto de sada, se o
agregado do perfil provisionado para a sada exceder a capacidade de sada do link.
Distribuindo informaes de configurao

11 Classificador.
11 Controle de congestionamento.
11 Mecanismos de escalonamento de pacotes (disciplinas de servio).
11 Ou seja, enfileiramento.
11 Preveno de congestionamento.
11 Tcnicas para evitar transbordamento das filas.
11 Influncia do controle de congestionamento do protocolo TCP (fonte cooperante).
O processo de provisionamento fsico , por necessidade, relativamente esttico e no pode
ser automatizado, desde que requeira instalao de equipamentos fsicos. Entretanto, o
provisionamento lgico e configuraes podem e devem ser automatizados. Nesta sesso,
abordaremos tcnicas de distribuio de informaes de configurao.
No caso mais simples, os TCSs so estticos e as bordas e o interior da rede so provisionados
estaticamente atravs do processo de envio da informao de configurao para o nodo de
de policiamento. Nesse momento, os nodos so configurados pelo provedor. O administrador
de rede pode usar um dos vrios protocolos para fazer isto, incluindo SNMP ou CLI.
De modo a acomodar o trfego submetido pelo provisionamento de um novo TCS, necessrio provisionar o interior da rede. Nesse caso de configurao top down, as informaes
de configurao de interior so tambm enviadas via protocolo de configurao, tal como
SMNP ou CLI.
Servidores de policiamento podem ser usados para extrair informaes de base de dados e para
convert-las em informaes de configurao, as quais so enviados para nodos individuais.
Nesse cenrio, os servidores de policiamento poderiam utilizar protocolos do tipo diretory
access protocol, tal como LDAP, para buscar informaes do diretrio e usar um protocolo
de configurao como SMNP ou CLI para push down a informao de configurao para o
nodo da rede.
Modificaes de base de informaes de configurao em medies de tempo real

Um terceiro mecanismo para a configurao de nodos interiores poderia ser baseado em
medidas da carga do trfego corrente nos nodos chaves da rede. A configurao baseada
rede apropriado. A configurao dos nodos de borda requer primeiro o envio da informao
em medidas mesmo necessria para provisionamento quantitativo, desde que os padres

221
de trfego quantitativo sejam relativamente previstos. Entretanto, ele pode aumentar significativamente a eficincia com a qual o provisionamento qualitativo pode ser alcanado.
O objetivo final em relao a QoS prover a usurios e aplicaes alta qualidade na entrega
de servios de dados. No ponto de vista do roteador, o suporte qualidade de servio dividida em trs partes: definio de classes de tratamento de pacotes, especificao da quantidade de recursos para cada classe e classificao de todos os pacotes de entrada da rede
dentro de suas classes correspondentes. O modelo DiffServ especifica a primeira e a terceira
parte: ele especifica classes de trfego, bem como prov um mecanismo simples de classificao de pacotes. J o modelo Bandwidth Broker (BB) especifica a segunda parte, mantendo
a informao de alocao atual do trfego marcado e interpretando novas requisies.
O BB tem responsabilidades internas e externas referentes a gerenciamento de recursos
e controle de trfego. Internamente, um BB pode manter informaes de requisies de
QoS de usurios individuais e aplicaes, e alocar recursos internos de acordo com regras
de policiamento usadas para recursos especficos dentro do domnio. Externamente, o BB
tem responsabilidades de configurar e manter acordos bilaterais de servios com os BBs de
domnios vizinhos de modo a assegurar a manipulao de QoS do trfego de dados entre as
bordas.
O Bandwidth Broker (BB) um agente responsvel pela alocao de servios preferenciais
para usurios no momento da requisio, e por configurar os roteadores da rede com o
comportamento de entrega correto para o servio definido. Um BB est associado a uma
regio de confiana particular, um por domnio; tem uma base de dados para policiamento
que mantm as informaes de quem pode fazer o qu, quando e um mtodo de utilizar a
base de dados para autenticao de requisies. Apenas o BB pode configurar o roteador
folha para entregar um servio particular para um fluxo, crucial para o desenvolvimento de
um sistema seguro.
Quando uma alocao desejada para um fluxo particular, uma requisio enviada para
o BB. A requisio inclui o tipo de servio, a taxa-destino, a rajada mxima e o perodo de
tempo que o servio ser utilizado. A requisio pode ser realizada por um usurio ou ela
pode vir de outras regies de BB. Um BB autentica em primeiro as credenciais do requisitor, ento, verifica se existe largura de banda disponvel suficiente para a requisio. Se a
requisio passa por esse teste, a largura de banda disponvel reduzida pela quantidade
requisitada e a especificao do fluxo registrada.
O BB configura o roteador-folha com informaes sobre o fluxo de pacotes a ser dado ao
servio no momento que este se inicia.
A ideia do BB foi introduzida como parte da arquitetura de Servios Diferenciados. O BB
est diretamente envolvido com a administrao do gerenciamento de recursos de servios
222
diferenciados. Dois aspectos importantes so:

11 Gerenciamento de recursos entre domnios;
11 Gerenciamento de recursos dentro do domnio.
Service Level Agreements

O Service Level Agreements (SLA) prov um mecanismo simples para alocao de blocos
de um servio em particular para um cliente especfico. Essa facilidade reserva banda para
usurios ou organizaes, mas no refere-se alocao para fluxos especficos. Um SLA
vlido para fluxo dentro de uma nica regio. Uma vez que o SLA tenha sido estabelecido,
pores desse servio podem ser associadas a fluxos especficos. O SLA inclui as seguintes
informaes:
11 Identificao do cliente;
11 Tipo de servio;
11 Parmetros de tipo de servio;
11 Restries do servio.
O Bandwidth Broker assegura que todas as obrigaes para qualquer servio no exceda a
quantidade desse servio disponvel na regio de confiana.
Requisio de alocao de banda

As requisies de alocao de banda so usadas por clientes de modo a requisitar pores
de um servio alocado por um SLA, para fluxos individuais.
Esses fluxos individuais so descritos por informaes de origem/destino/protocolo, alm
da informao da taxa. O pedido de requisio de banda contm:
11 Identificador de usurio;
11 O ID do SLA para negociar o SLA;
11 Parmetros de nvel de servio (taxa, rajada mxima etc.);
11 Identificador fonte (nmero da porta, endereo IP e protocolo);
11 Destino (nmero da porta, endereo IP e protocolo);
11 Durao da requisio.
O Bandwidth Broker, antes de permitir a requisio, garante que a alocao no vai violar
os limites do SLA e tambm no exceder a quantidade do agregado do servio na regio
de confiana.
Configurao do roteador
O Bandwidth Broker tem de configurar um grupo de roteadores com capacidades de Diff-
O BB configura os roteadores-folhas e de sada no seu domnio, de acordo com o Service

Level Agreements e a requisio de alocao de banda de entrada para os clientes. Depois
da verificao e validao de um SLA, o roteador de sada apropriado conectado e parmetros requeridos para a configurao do servio particular so enviados. Similarmente,
na validao de um BAR, o roteador-folha mencionado no BAR conectado e os parmetros
necessrios para marcao e policiamento do fluxo so passados a ele.
Mecanismos para implementar QoS

Esta sesso tem como objetivo apresentar os mecanismos j desenvolvidos pelo fornecedor
Cisco Systems, no que condiz QoS. So eles:
11 Classificao;
11 Gerenciamento de congestionamento;
11 Mecanismos para evitar congestionamento;
11 Policiamento e conformao;
11 Sinalizao;
Serv, de modo a prover o nvel desejado de servio dentro da regio.
11 Mecanismos de eficincia de link.

223
Classificao
A classificao utiliza um descritor de trfego para categorizar um pacote dentro de um
grupo especfico, e para definir o pacote e marc-lo como acessvel para manipulao de
QoS na rede. Usando classificao de pacotes, podemos particionar o trfego da rede dentro
de mltiplos nveis de prioridade ou classes de servios. Quando os descritores de trfego
so usados para classificar trfego, a origem concorda seguir os termos do contrato e a
rede promete qualidade de servio. O policiamento de trfego, tal como a caracterstica de
limite de taxa do Committed Access Rate (CAR) e conformao de trfego, alm de Frame
Relay Traffic Shaping (FRTS) e Generic Traffic Shaping (GTS), usam um descritor de trfego de
pacotes classificao para assegurar o contrato (Cisco 99b).
A classificao de pacotes primordial para tcnicas de policiamento que selecionam
pacotes que cruzam elementos de rede ou uma interface particular para diferentes tipos de
servios QoS. Os mtodos antigos de classificao eram limitados ao contedo do cabealho
do pacote. Os mtodos atuais de marcao de pacote para classificao permitem configurar informaes em cabealhos de nvel 2, 3 ou 4, ou at configurar informaes dentro
do payload do pacote.
O uso do IP Precedence permite especificar a classe de servio (CoS) para um pacote. So
usados os trs bits precedentes do campo ToS no cabealho IPv4 para esse propsito.
Precedence
Precedence
Tipo de servio
Precedence
Codepoint Servios Diferenciados
Usando os bits ToS, podemos definir at seis classes de servios. Outras caractersticas
configuradas atravs da rede, podem ento usar esses bits para determinar como tratar o
pacote, em vez de considerar o tipo de servio para garanti-lo. Essas outras caractersticas
de QoS podem fornecer polticas apropriadas de manipulao de trfego, incluindo estrat-
gias de gerncia de congestionamento e alocao de banda. Por exemplo, embora o IP
224
Precedence no seja um mtodo de enfileiramento, mtodos de enfileiramento tais como

Weighted Fair Queueing (WFQ) e Weighted Random Early Detection (WRED) podem usar o IP
Precedence para configurar os pacotes para trfego priorizado.
Figura 8.10
Histrico do campo
IP Precedence
Premium
Olimpico
Marcadores
Configurando nveis de precedncia em trfego entrante e usando-os em combinao com

caractersticas de enfileiramento, podemos criar servios diferenciados. Igualmente pode-se
utilizar caractersticas tal como policy-based-routing (PBR) e CAR para configurar a precedncia, baseada em classificao por lista de acesso.
Assim, cada elemento da rede pode prover servios baseados em determinado policiamento
o IP Precedence geralmente implementado o mais perto da borda da rede. Podemos
pensar em IP Precedence com uma funcionalidade da borda que permite o core ou backbone caractersticas de QoS, tal como WRED, reenviar trfego baseado em CoS. O IP Precedence pode tambm ser configurado no host ou na rede do cliente, mas essa configurao
pode ser reescrita por policiamento dentro da rede.
As seguintes tcnicas podem utilizar o IP Precedence para determinar como o trfego deve
ser tratado:
11 Distributed Weighted Random Early Detection (Distributed-WRED);
11 Weighted Fair Queueing (WFQ);
11 Committed Access Rate (CAR).
Como os bits do IP Precedence so utilizados para classificar pacotes

DS-Field.
11 Pacotes so marcados para receber servios diferenciados nos Domnios DS.

11 Campo TOS do IPv4 ou Traffic Class do IPv6.
11 codepoint (DSCP).
22 identifica o PHB (Per-Hop Behavior).
Podemos utilizar os trs bits do campo ToS no cabealho IP para especificar o CoS dado para
cada pacote, particionar o trfego em at seis classes os dois restantes so reservados
para uso interno e ento usar mapas de policiamento e lista de acesso para definir polticas de rede, em termos de manipulao de congestionamento e alocao de bandwidth
para cada classe.Por razes histricas, cada precedente corresponde a um nome, os quais
so definidos no RFC 791. A seguinte tabela lista os nmeros e seus correspondentes nomes.
Figura 8.11
IP Precedence.
225
Nmero
Nome
Rotineira
Prioritria
Imediata
Flash
Flash override
Crtica
Internet
Network
Os bits 6 e 7 de IP Precedence so reservados para informaes de controle, tal como

atualizaes de roteamento. Embora caractersticas de IP Precedence permitam flexibilidade
considervel para dar precedncia, possvel definir um mecanismo de classificao
especfico. Por exemplo, pode ser desejvel atribuir precedncia baseada em aplicaes.
Por default, o valor do IP Precedence no alterado, preservando-se o valor configurado no
cabealho. Permite-se assim que os dispositivos da rede possam prover servios baseados
no valor configurado.
Essa poltica de policiamento segue o padro, no qual o trfego de rede deve ser agrupado dentro de vrios tipos de servios no permetro da rede, e esses servios devem ser
implementados no core da rede. Os roteadores no core da rede podem utilizar os bits do IP
Precedence, por exemplo, para determinar a ordem de transmisso, o seu descarte, e assim
por diante.
Podemos utilizar um dos seguintes mecanismos para configurar IP Precedence nos pacotes:
11 Policy-Based Routing;
11 QoS Policy Propagation via Border Gateway Protocol (PB-BGP);
11 Committed Access Rate (CAR).
Depois que um pacote tenha sido classificado, pode-se usar outro mecanismo, tal como CAR
e WRED, para especificar e forar policiamento.
Policy-Based Routing
O PBR permite configurar IP Precedence, para especificar o caminho correto do trfego, ou o

caminho baseado em configuraes de policiamento. O PBR permite:
11 Classificar o trfego baseado em critrios de lista de acesso, assim estabelecendo
critrios de associao;
11 Configurar IP Precedence, dando rede a habilidade de habilitar diferentes classes
de servios;
11 Rotear pacotes para especificar caminhos; rotear para permitir servios QoS atravs
da rede.
O policiamento pode ser baseado em endereo IP, nmero da porta, protocolo ou tamanho
do pacote. Para um simples policiamento, podemos usar um desses descritores; para um
policiamento complexo, podemos usar todos eles.
226
Tabela 8.1
Valores do IP
Precedence.
Por exemplo, a classificao de trfego por PBR permite identificar trfego por diferentes
tipos de servio na borda da rede e ento implementar QoS definido por cada CoS no core
da rede, usando tcnicas de prioridade ou weighted fair queueing. Esse processo obviamente necessita classificao de trfego, explicitamente em cada interface no core da rede.
Todos os pacotes recebidos, com PBR habilitado na interface, so passados atravs de
filtros conhecidos como mapas de rotas. O mapa de rotas usado pelo PBR dita o policiamento, determinando para onde os pacotes devem ser encaminhados. Algumas aplicaes
ou trfegos podem ser beneficiados por roteamento; por exemplo, poderamos transferir
registros de estoque para um escritrio com alta largura de banda, enquanto transmitimos
aplicaes rotineiras tal como e-mail, atravs de links de baixa velocidade.
O Border Gateway Protocol (BGP) um protocolo de roteamento entre domnios, que troca
informaes de roteamento com outros sistemas BGP (definido no RFC 1163). Polticas de
propagao via BGP permitem classificar pacotes baseados em:
11 Lista de acesso;
11 Lista de community BGP;
11 Caminhos de sistemas autnomos BGP;
11 IP Precedence;
11 Endereos de origem e destino.
Depois de o pacote ter sido classificado usando BGP, pode-se usar caractersticas de QoS,
tal como CAR e WRED, para especificar policiamento compatveis com o modelo do negcio
da organizao. O CAR um mecanismo que implementa classificao de servios e policiamento atravs de limites de taxa. Podemos utilizar servios de classificao por CAR
para configurar IP Precedence em pacotes que entram na rede. Essa caracterstica do CAR
permite particionar a rede em mltiplos nveis de prioridade ou classes de servio. Dispositivos de rede dentro da rede podem utilizar o IP Precedence para determinar como o trfego
deve ser tratado. Depois do pacote ser classificado, a rede pode aceitar ou reescrever e
reclassificar o pacote, de acordo com um policiamento especfico.
tica de gerenciamento da alocao da largura de banda, a qual foi determinada na criao

da conexo. Entre as aes tomadas, pode ocorrer a mudana de classe (IP precedence) ou o
descarte de pacotes (RED-like). Como exemplo de poltica aplicveis pode-se citar:
11 Firm CAR: pacotes que excedem a banda alocada so descartados;
11 CAR + Premium: pacotes que excedem a banda alocada so recoloridos com alta ou
baixa preferncia;
11 CAR + Best Effort: pacotes que excedem a banda alocada so recoloridos at o estouro
do threshold, depois so descartados;
11 Per Application CAR: diferentes CARs so especificados para diferentes aplicaes.
O Committed Access Rate (CAR) tem como objetivo prover ao operador da rede a caracters-
227
CAR
CAR
Figura 8.12
Committed
Access Rate.
Gerenciamento de congestionamento
As caractersticas de gerenciamento de congestionamento permitem o controle de congestionamento, pela determinao da ordem com que os pacotes so transmitidos para fora
da interface, baseada em prioridades para esses pacotes. O gerenciamento de congestionamento est diretamente ligado criao de filas; o direcionamento dos pacotes para essas
filas baseia-se na classificao dos pacotes e na programao dos pacotes em uma fila para
transmisso. A caracterstica de gerenciamento de congestionamento oferece quatro tipos
de protocolos, cada um dos quais permite que se especifique a criao de um nmero diferente de fila, de acordo com o tipo de trfego e a ordem na qual os pacotes so transmitidos.
Durante perodos onde no existe congestionamento, os pacotes so transmitidos para fora
da interface assim que chegam. Durante perodos de congestionamento, os pacotes chegam
mais rpido que a interface de sada pode suportar. Se for utilizado o gerenciamento de
congestionamento, os pacotes acumulados na interface so enfileirados at que a interface esteja livre novamente; o envio dos pacotes ento programado para transmisso, de
acordo com sua prioridade, e o mecanismo de enfileiramento configurado para a interface.
O roteador determina a ordem com que os pacotes so transmitidos, controlando quais
pacotes so colocados nas filas e como filas so servidas com respeito as outras.
Existem esses quatro tipos bsicos de enfileiramento, os quais constituem os mecanismos
de gerenciamento de congestionamento para QoS:
11 First-In, First-Out Queueing (FIFO): o mtodo FIFO no utiliza o conceito de priorizao
ou classes de trfego. Com FIFO, a transmisso de pacotes para fora da interface ocorre
de acordo com a chegada destes;
228
11 Weighted Fair Queueing (WFQ): o WFQ divide o bandwidth atravs de filas de trfego
baseado em pesos. O WFQ assegura que todo o trfego tratado de acordo com as
regras, dado seu peso. Para ajudar a entender como o WFQ trabalha, considere uma
fila para pacotes FTP como uma fila coletiva, e uma fila para trfego de pacotes interativos como uma fila individual. Dado o peso das filas, o WFQ assegura que para todos
os pacotes da fila coletiva transmitidos, um nmero igual de pacotes da fila individual
transmitido. Assim, o WFQ assegura, satisfatoriamente, o tempo de resposta a aplicaes
crticas, tal como as interativas, aplicaes baseadas em transaes que so intolerantes
a degradaes de performance;
11 Custom Queueing (CQ): com CQ, o bandwidth alocado proporcionalmente para cada
classe de trfego diferente. O CQ permite especificar o nmero de bytes ou pacotes para
a fila. Nesse caso, o CQ usado geralmente para interface de baixa velocidade;
11 Priority Queueing (PQ): com PQ, pacotes com prioridade maior so enviados antes
que todos os pacotes com prioridade menor, de modo a assegurar o tempo de entrega
desses pacotes.
Atualmente, existe uma necessidade real de que o trfego seja compartilhado entre aplicaes, de modo que no venha a afetar a performance. Nesse caso, deve-se considerar cada
vez mais o uso de tcnicas de gerenciamento de congestionamento para assegurar o tratamento atravs dos vrios tipos de trfego. Isso derivado de necessidades tais como:
11 A priorizao de trfego especialmente importante para aplicaes sensveis ao atraso
e transaes interativas por exemplo, vdeo-conferncia que necessitam prioridade
maior que aplicaes de transferncia de arquivos;
11 A priorizao mais efetiva em links WAN nos quais a combinao entre trfego em
rajadas e taxas menores de dados podem causar congestionamentos temporrios;
11 Dependendo do tamanho mdio dos pacotes, a priorizao mais efetiva quando aplicada a links T1/E1 ou menores;
11 Se os usurios de aplicaes que rodam atravs da rede identificam uma resposta pobre
em relao ao tempo, deve ser considerada o uso de caractersticas de gerenciamento de
congestionamento. Caractersticas de gerenciamento de congestionamento so dinmicas, podendo se ajustar sozinha s condies existentes na rede. Entretanto, considerando que se um link WAN est constantemente congestionado, a priorizao de trfego
pode no resolver o problema. A melhor soluo seria aumentar o tamanho do link;
11 Se no existe congestionamento no link WAN, no h razo para implementar priorizao
de trfego.
Mecanismos para evitar congestionamento

As tcnicas para evitar congestionamento monitoram a carga do trfego de rede, de modo
namento tem como base o descarte de pacotes. Entre as mais variadas tcnicas de evitar
congestionamento usadas, encontramos a Random Early Detection (RED), a qual se destina
a redes de transmisso de alta velocidade.
Esta sesso disponibiliza uma descrio dos tipos de caractersticas para evitar congestionamento, tais como:
11 Tail Drop: essa tcnica a padro para evitar comportamentos de congestionamento;
11 Weighted Random Early Detection (WRED): combina as caractersticas do algoritmo
RED com IP Precedence.
Tail Drop
O mecanismo de tail drop trata todo trfego da mesma maneira e no faz diferenciao
entre as classes de servios. As filas so preenchidas em perodos de congestionamento.
Quando a fila de sada completada e o mecanismo de tail drop est em vigor, os pacotes
so descartados at que o congestionamento seja eliminado e a fila no esteja mais cheia.
a antecipar e evitar o congestionamento em pocas de gargalos de rede. Evitar congestio-
229
Weighted Random Early Detection

11 Policiamento de trfego, de modo a maximizar o throughput em condies
de congestionamento.
11 O RED trabalha em conjunto com protocolos como TCP, de modo a evitar
congestionamento da rede.
Esta sesso de aprendizagem oferece uma introduo breve dos conceitos de RED e enderea o WRED, uma implementao de RED. O mecanismo RED foi proposto por Sally Floyd e
Van Jacobson em 1990, para enderear congestionamento de rede em resposta maneira
tradicional. O mecanismo RED est baseado na premissa de que a maioria do trfego roda
em implementaes de transporte de dados, as quais so sensveis perda, e em determinados perodos sofre um atraso devido ao descarte do seu trfego. O TCP, que responde
apropriadamente ao descarte do trfego atravs de tcnicas de atraso no envio deste,
permite o uso do RED com um mecanismo de sinalizao para evitar congestionamento.
importante considerar que o uso do RED deve ser empregado em transportes de rede tal
como TCP, onde o protocolo robusto, em resposta perda de pacotes. No caso do protocolo Novell Netware e AppleTalk, nenhum deles robusto em resposta perda de pacotes,
assim no devemos utilizar RED nesses casos.
O objetivo do RED controlar o tamanho mdio da fila indicando aos hosts quando eles
devem transmitir seus pacotes mais lentamente. O RED leva vantagem ao utilizar-se do
mecanismo de controle de congestionamento do TCP. Atravs do descarte randmico de
pacotes em perodos de grande congestionamento, o RED conta a origem dos pacotes nos
quais deve ocorrer uma diminuio na sua taxa de transmisso. Assumindo que o pacote
de origem est utilizando TCP, a fonte vai diminuir sua taxa de transmisso at que todos
os pacotes possam alcanar o seu destino, indicando que o congestionamento no ocorre
mais. Na verdade, o TCP no para totalmente, ele reinicia rapidamente e adapta-se taxa de
transmisso que a rede pode suportar.
RE
230
Figura 8.13
Random Early
Detection.
Como o TCP manipula a perda de trfego

Quando o recipiente do trfego TCP chamado de receptor recebe o segmento de dados,
ele verifica se os quatro octetos, os quais identificam o nmero de sequncia, esto de
acordo com o esperado, indicando, assim, que o segmento de dados foi recebido em ordem.
Se o nmero bate, o receptor envia todos os dados para a aplicao destino, para ento atualizar o nmero de sequncia de modo a refletir o prximo nmero, e finalmente transmitir
um reconhecimento (ACK) para o emissor ou programa um ACK para ser transmitido

aps um pequeno perodo de tempo. O ACK notifica o emissor que o receptor recebeu todos
os segmentos.
Os receptores geralmente tentam enviar um ACK, em resposta a alternativos segmentos de
dados que recebem; esse envio se d porque, para muitas aplicaes, se o receptor espera
mais que o atraso esperado, ele pode enviar um ack de resposta como uma resposta normal
para o emissor. Entretanto, quando o receptor recebe um segmento de dados fora de ordem,
ele responde imediatamente com um ACK para retransmitir o segmento de dados perdido.
Quando um emissor recebe um ACK, ele realiza as seguintes determinaes: pode determinar se o dado foi entregue ou no; pode determinar que o ACK um Keepalive, utilizado para manter a linha ativa. No caso da no recepo do dado, o ACK determina que
o receptor recebeu algum ou nenhum dado. No caso da recepo de algum dado, o ACK
determina se novos crditos para envio dos dados sero permitidos. Quando um reconhecimento de ACK recebido, sendo que no houve dados enviados e no h mais dados a
serem enviados, o emissor interpreta o ACK como um ACK repetido. Essa condio indica
que alguns dados foram recebidos fora de ordem, forando com que o receptor envie o primeiro ACK, e que o segundo segmento de dados foi recebido fora de ordem, forando assim
com que o receptor envie o segundo ACK. Na maioria dos casos, o receptor receber dois
segmentos fora de ordem porque um dos segmentos foi descartado.
Quando um emissor de TCP detecta um segmento de dados descartado, ele retransmite o
segmento. Ento ele ajusta a taxa de transmisso, que a metade da existente antes do descarte detectado. Esse o comportamento conhecido como back-off ou slow down. Embora
esse comportamento seja apropriado para tratar congestionamento, problemas podem
ocorrer quando mltiplas sesses concorrentes TCP encontram-se no mesmo roteador e
todos os emissores TCP atrasam a transmisso dos pacotes ao mesmo tempo.
Roteadores podem manipular mltiplas sesses TCP concorrentes. Como os fluxos de rede
so adicionados aos poucos, existe uma probabilidade de que o trfego exceda o Transmit
Queue Limit (TQL). Entretanto, existe uma grande probabilidade de que o trfego excessivo
encontro entre trfegos ou em roteadores das bordas.
Se um roteador descarta todo o trfego que excede o TQL, como ocorre quando usado
o mecanismo tail drop, muitas sesses TCP iro simultaneamente se iniciar. Consequentemente, todo o trfego vai ser afetado e todos os fluxos precisaro ir sendo gradualmente
iniciados; essa atividade cria uma condio de sincronismo global.
Entretanto, se o roteador no descarta trfego, como o caso de mecanismos de filas como
fair queueing (FQ) ou custom queueing (CQ), ento o dado opera como se fosse armazenado
na memria principal, degradando dramaticamente a performance do roteador.
No caso do RED, ele resolve o problema recm-descrito levando uma sesso TCP ao retardo
por vez, permitindo o uso completo do bandwidth. J no caso do mecanismo WRED, ele
combina as caractersticas do algoritmo RED com o IP Precedence, de modo a prover uma
manipulao de trfego preferencial para pacotes com maior prioridade. O WRED pode
seletivamente descartar trfego de baixa prioridade quando a interface inicia o congestionamento e prov diferentes caractersticas de performance para diferentes classes de
servios. Para interfaces configuradas para utilizar Resource Reservation Protocol (RSVP),
o WRED escolhe pacotes de outros fluxos a serem descartados em vez de fluxos RSVP.
seja temporrio e que o trfego no fique excessivo, exceto nos pontos nos quais ocorre o
231
Tambm o IP Precedence governa quais pacotes so descartados o trfego de baixa prioridade tem uma taxa de descarte maior que a dos de alta prioridade.
O WRED difere de outras tcnicas para evitar congestionamento tal como estratgias de
filas, porque uma vez que ocorra congestionamento, no lugar de control-lo, ele procura se
antecipar e evit-lo.
Teste de
descarte
Passa
Pacotes que
chegam
Fila
transmitida
Pacotes
de sada
Saiba mais
O Weighted RED
trabalha com mltiplos
thresholds, um para
cada classe de servio.
Servios de baixa prioridade so descartados
antes dos servios de
alta prioridade.
Falha
Programao FIFO
Descarte baseado
Recursos de buer
no teste:
de enleiramento
Profundidade da la
IP Precedence
Sesso RSVP
O WRED faz a antecipao de deteco de congestionamento possvel e prov para mltiplas classes de trfego. Ele tambm protege contra a sincronizao global. Por essa razo,
o WRED utilizado em qualquer interface de sada na qual esperada uma ocorrncia de
congestionamento. Entretanto, o WRED geralmente usado em roteadores do core da rede,
e no nos roteadores da borda. Roteadores de borda marcam precedncia IP para pacotes
quando eles entram na rede. O WRED usa essa precedncia para determinar como tratar
diferentes tipos de trfego. O WRED prov thresholds e pesos separados para diferentes IP
Precendence, permitindo prover diferentes qualidades de servios com descarte de pacotes
para diferentes tipos de trfego. Nesse caso, o trfego tradicional pode ser descartado mais
frequentemente que o trfego do tipo premium durante perodos de congestionamento.
Em perodos de congestionamento, quando os pacotes comeam a ser descartados, o WRED
avisa a fonte dos pacotes para decrescer sua taxa de transmisso. Se a fonte dos pacotes
est utilizando TCP, ela decrescer a taxa de transmisso de pacotes at que todos os
pacotes alcancem o seu destino, que indica que o congestionamento no existe mais.
O WRED geralmente descarta pacotes seletivamente baseados no IP Pecedence. Os pacotes
com o maior IP Precedence so descartados em menor proporo do que os de menor
precedncia. Assim, quanto mais alta a prioridade dos pacotes, mais alta a probabilidade
232
de que os pacotes sejam entregues. O WRED reduz as chances do tail drop atravs da
seleo do descarte dos pacotes quando a interface de sada comea a mostrar sinais de
congestionamento. Dropando alguns pacotes antecipadamente, em vez de esperar que a
fila complete, o WRED evita um descarte numeroso de pacotes de uma s vez e minimiza
as chances de sincronismo global. Assim, o WRED permite que a linha seja usada completamente. O WRED til quando o trfego do tipo TCP/IP. Com TCP, pacotes descartados
indicam congestionamento, ento a fonte dos pacotes reduz a taxa de transmisso.
Figura 8.14
Weighted Random
Early Detection.
Mecanismos de policiamento e conformao

Nesta sesso, descreveremos dois mecanismos para regular trfego: o rate-limite do
committed access rate (CAR) para policiamento de trfego e o Generic Traffic Shaping (GTS)
e Frame Relay Traffic Shaping (FRTS) para conformar o trfego. Implementar esses mecanismos atravs da rede significa assegurar que um pacote, ou dado origem, siga o contrato
estipulado. Tanto o policiamento como o mecanismo de conformao usam o descritor de
trfego para um pacote indicado pela classificao do pacote para assegurar o caminho e
o servio.
Policiais e conformadores geralmente identificam as violaes no descritor de trfego de
maneiras idnticas. Eles geralmente diferem, entretanto, no modo como respondem violao.
Por exemplo:
11 Um policial tipicamente descarta o trfego. (Por exemplo, o policial da taxa limite no CAR
ou descarta o pacote ou reescreve seu IP Precedence, reconfigurando os bits do tipo de
servio do cabealho do pacote.);
11 Um conformador tipicamente atrasa o trfego excessivo, usando um buffer ou mecanismos de enfileiramento, para segurar pacotes e conformar o fluxo quando a taxa de
dados da origem mais alta do que o esperado. (Por exemplo, o GTS usa o Weighted fair
queue para atrasar os pacotes para conformar o fluxo, e o FRTS usa o Priority Queue
(PQ), Custom Queue (CQ) ou first-in, first-out (FIFO) para a mesma situao, dependendo
de como configurado.)
A conformao de trfego e o policiamento podem trabalhar em conjunto. Por exemplo,
um bom esquema de conformao de trfego poderia ser usado para detectar fluxos com
problemas de comportamento. Essa atividade muitas vezes chamada de policiamento de
fluxo de trfego.
O CAR incorpora uma caracterstica de taxa-limite para policiamento de trfego, somado
sua caracterstica de classificao. Essa caracterstica gerencia o policiamento do acesso ao
bandwidth da rede, assegurando que o trfego, de acordo com os parmetros de taxa espeou transmitindo-os com uma prioridade diferente.
As funes do limitador de taxa so:
11 Permite controlar a taxa mxima de trfego transmitido ou recebido em uma interface;
11 D a habilidade de definir agregados de nvel 3 ou taxa-limite de bandwidth de ingresso
ou sada e para especificar polticas de manipulao de trfego quando o trfego est
conforme ou excede taxas- limites especificadas.
O CAR examina o trfego recebido na interface ou um subset desse trfego selecionado por
critrios da lista de acesso. Ele ento compara a taxa de trfego a um token bucket configurado, e age de acordo com os resultados. Por exemplo, o CAR descartar o pacote ou
reescrever o IP Precedence, reconfigurando os bits type-of-service (ToS).
A primeira razo para se utilizar conformao de trfego o controle de acesso para com
o bandwidth disponvel, assegurando que o trfego seja conforme ao policiamento estabelecido para ele, e para regular o fluxo do trfego, de modo a evitar congestionamentos que
possam ocorrer quando o trfego excede a velocidade da interface remota. Por exemplo:
cificados seja transmitido, enquanto descarta pacotes que excedam a quantidade de trfego
233
11 Controle de acesso ao bandwidth quando o policiamento dita que a taxa de uma dada
interface no deveria, na mdia, exceder uma certa taxa, embora a taxa de acesso exceda
a velocidade;
11 Configurar conformao de trfego na interface tendo uma rede com diferentes taxas de
acesso. Suponha que os links Frame Relay tenha 128 kbps e 256 kbps. Enviar pacotes a
256 kbps pode causar falha na aplicao.
O conformador de trfego previne perda de pacotes. O seu uso especialmente importante em
redes Frame relay porque o switch no pode determinar quais pacotes tm precedncia, alm
de quais pacotes devem ser descartados quando o congestionamento ocorre. de importncia
crtica para o trfego do tipo real-time, tal como Voz sobre Frame relay, cuja latncia limitada,
limitando assim a quantidade de trfego e perda de trfego em links de redes de dados em
qualquer tempo, mantendo o dado em roteadores que fazem a garantia. A reteno do dado
em roteadores permite que o roteador priorize o trfego de acordo com a garantia. (A perda de
pacotes pode ser resultante da consequncia de aplicaes real-time e interativas.)
O conformador de trfego limita a taxa de transmisso de dados atravs de:
11 Uma taxa especfica configurada;
11 Uma taxa derivada, baseada no nvel de congestionamento.
Como mencionado, a taxa de transferncia depende de trs componentes que constituem o
token bucket: tamanho da rajada, taxa resultante e intervalo de tempo. A taxa resultante
igual ao tamanho da rajada dividido pelo intervalo.
Quando o conformador de trfego habilitado, a taxa de bits da interface no vai exceder a
taxa resultante sobre qualquer intervalo mltiplo do integral. Em outras palavras, durante
todo o intervalo, um tamanho mximo de rajada pode ser transmitido. Dentro do intervalo,
entretanto, a taxa de bit pode ser mais rpida que a taxa resultante em qualquer tempo dado.
Pode-se especificar qual pacote Frame Relay tem baixa prioridade ou baixa sensibilidade ao
tempo e ser o primeiro a ser descartado quando um Frame Relay estiver congestionado.
O mecanismo que permite um Frame Relay identificar tal pacote o bit DE.
Pode-se definir listas de DE que identificam caractersticas de pacotes a serem descartados.
Uma lista DE pode ser baseada em protocolos ou interfaces e em caractersticas, tal como
fragmentao de pacotes, um TCP especfico ou porta User Datagram Protocol (UDP), um
nmero de lista de acesso ou tamanho de pacote.
Qualidade de servio na prtica

Uma vez que j foram definidas as tcnicas para empregar QoS, como tambm a definio
da arquitetura DiffServ, ser apresentada a seguir uma soluo de Qualidade de Servio.
234
Nela o ambiente em questo requer diferenciao de trfego, devido ao fato da necessidade

de cobrana diferenciada deste, bem como garantia do Service Level Agreement.
A topologia de rede da soluo dividida em trs nveis.
11 Acesso;
11 Distribuio;
11 Core.
Backbone
WAN core
POS, ATM, T3
Backbone
Backbone
Core
Backbone
Connectivity
Backbone
Connectivity
Concentration
Concentration
Distribuition
Dial Access
SOHO
Cable Access
Direct Access
SOHO
or Campus
SOHO
or Campus
Frame/Leased
to Campus
Access / Services
Acesso
no nvel de acesso que o policiamento deve ser empregado. Isso ocorre devido ao fato da
necessidade de limitar a taxa do trfego de cada cliente requerido pelo SLA. Ou seja, cada
cliente dentro da soluo cobrado pela banda que utiliza. Assim, para cada cliente o policiamento deve ser empregado.
Nesse nvel tambm classificado o trfego do cliente de modo a se enquadrar em um dos
seguintes tipos (classificao por DiffServ): Ouro (Gold traffic), Prata (Silver traffic) e Bronze
(Bronze traffic). Esses tipos so relacionados usualmente a aplicaes especficas:
11 Ouro: voz e outras aplicaes em tempo real;
11 Prata: comrcio eletrnico;
11 Bronze: e-mail e web.
As tcnicas para garantir o SLA do cliente podem envolver o uso de CAR ou WFQ.
11 Commited Access Rate (CAR):
22 Marcao/Classificao de pacotes: IP Precedence e QoS group setting;
22 Gerncia de acesso a banda: limitao de banda (policiamento).
11 Class-Based WFQ;
22 Configurao de limite mnimo de bandwidth;
22 Servio de enfileiramento para controlar a latncia.
Distribuio
O nvel de distribuio tem como funo definir quais sero as polticas de descarte de
rede quando a rede estiver congestionada. Ou seja, a distribuio tem como funo evitar
e gerenciar o congestionamento da rede. Assim, quando ocorre um congestionamento, o
trfego Silver ou Bronze descartado, de modo a no afetar o trfego Gold.
Figura 8.15
Nveis de rede.
DSL Access
235
O que vale ressaltar que o trfego que ser descartado em caso de congestionamento ser
o trfego de um agregado de menor priorizao, e no aleatrio.
Gold
High Precedence
(Guarantees
Mission-Critical App,
I.e., Great Plains, Claris,
Plvotal, Peoplesoft,
Unied in Messaging)
Silver
Medium Precedence
E-mail, Interactive,
Video, Web
Bronze
E-fax, FTP
Figura 8.16
Tcnica de
descarte.
Core
Como o nvel de distribuio, o Core tambm tem a funo de prevenir o congestionamento
da rede. Esse nvel tem tambm a responsabilidade de interagir com o trfego de ingresso e
de sada. Ou seja, nesse nvel que os acordos bilaterais para fazer valer o QoS entre domnios devem ocorrer.
Concluso
A internet global est mudando tudo e todos. O mundo est convergindo para o protocolo
da internet e para suas necessidades de rede. Porm, nesse processo, o projeto original do IP
tornou-se muito dbil. Como resultado, a internet necessita mudar para acomodar a demanda
de novas aplicaes. A largura de banda uma soluo, mas no suficiente. De um modo
geral, a internet necessita gerenciamento dessa largura de banda, ela necessita de inteligncia.
At agora, a internet tem provido apenas o servio best-effort, no qual os recursos so
compartilhados igualmente. Somar QoS significa somar inteligncia internet, o que uma
necessidade imediata, uma vez que habilita a possibilidade de diferenciao dos servios.
Nos provedores, essa necessidade torna-se uma prioridade, uma vez que precisamos disponi-
bilizar mais formas de acomodar o mundo da internet em um ambiente rico em servios. Pois,
236
com esse tipo de arquitetura, os ISPs podero segmentar seu mercado, entregar mais valor ao
cliente, alcanar negcios mais lucrativos e esquentar o crescimento mundial na internet.
Mtricas para o gerenciamento de rede

Est se tornando uma prtica comum para os provedores instrumentarem suas redes com
ambientes de gerncia com suporte a medies ativas e passivas:
11 Provedores de servio:
22 Querem identificar gargalos de performance e tendncias na rede (disponibilidade,
taxa de perdas, utilizao de banda, atraso) para fins de planejamento de capacidade.
11 Pesquisadores:
22 Querem estudar as caractersticas das redes que podem ser adotados em

modelos de simulao para o desenvolvimento de novos protocolos de rede para
aplicaes avanadas.
22 Usurio final:
33 Est interessado em conhecer a performance de rede que est sendo oferecida
em seu computador.
33 Ainda no costuma fazer uso das medies ativas, porm ferramentas esto
surgindo para facilitar o uso pelo usurio final (exemplo: NDT).
33 Aplicaes teis a ele:
33 Por que a qualidade da vdeo-conferncia est ruim?
33 Qual a largura de banda ele consegue utilizar at um provedor?
33 E o suporte a multicast, conectividade com outras redes?
Aplicaes avanadas baseadas em rede tais como visualizao remota, ferramentas de colaborao e compartilhamento, e escalamento de servios computacionais em cluster podem
ser mais eficientes se tiverem dados de previso de desempenho da rede. Ou seja, a necessidade de realizar medies nas redes atender as demandas dos provedores na questo de
planejamento de capacidade e responder as necessidades dos usurios e dos pesquisadores.
O que desempenho de rede

Algo que intrinsecamente ligado a desempenho de rede a definio de lentido da rede.
O que exatamente uma rede lenta, e como se pode definir?
Como determinar quando a rede est lenta, e como se pode fazer isso? Existem usualmente
mais questes que respostas quando se est lidando com o desempenho de rede em
ambientes de produo.
A maioria dos elementos envolvidos no desempenho da rede pode ser resumida a poucos
de rede.
A maioria das ferramentas de desempenho da rede usa uma combinao de cinco elementos distintos para medir o desempenho:
11 Disponibilidade;
11 Tempo de resposta;
11 Utilizao da rede;
11 Vazo da rede;
11 Largura de banda da rede.
A monitorao da rede atravs de medies envolve 3 conceitos fundamentais:
11 Mtrica.
11 Metodologia de Medio.
11 Medio da rede propriamente dita.
princpios simples que podem ser medidos, monitorados e controlados pelo administrador
237
Mtrica, Metodologia de medio e Medio

Mtrica
Uma mtrica do contexto da monitorao de redes definida como:

11 Uma propriedade de um componente da rede, definido cuidadosamente e quantificada usando unidades padro;
11 uma entidade que permite descrever o desempenho, a confiabilidade e o estado
operacional de uma rede ou seus elementos;
11 uma descrio formal dos servios ou das condies operacionais na rede.
11 Metodologia de medio.
22 A metodologia de medio uma forma sistematizada de estimar a mtrica;
22 Pode existir mais que uma metodologia para uma mesma mtrica.
11 Medio:
22 A medio o resultado da aplicao de uma metodologia.
22 Em geral, uma medio tem incertezas ou erros.
22 O valor de uma mtrica calculado a partir de um ou mais resultados.
Medio Ativa e Medio Passiva

Medio Ativa
11 Na medio ativa, um trfego artificial trocado entre os ns de monitoramento/
medio, com o objetivo de conhecer o desempenho da rede;
11 A tcnica de medio ativa requer a injeo de pacotes de teste na rede para determinar a performance fim-a-fim de um caminho de rede;
11 Pacotes (sondas) so enviados entre um ponto emissor e um ponto receptor na rede e
a partir de seu comportamento na rede se determina o desempenho;
11 Pontos positivos:
22 Caracteriza melhor a percepo de qualidade da aplicao pelo usurio, pois
emula o comportamento de trfego da aplicao usando pacotes de teste.
11 Pontos negativos:
22 Consome largura de banda utilizada pelo trfego da aplicao;
22 Compete com as aplicaes pelo uso de recursos da rede.
Medio Passiva
11 Na medio passiva, o trfego da rede ou uma amostra desse avaliado pelos ns de

monitoramento;
11 Nesta tcnica no existe a necessidade da injeo de pacotes de teste na rede;
11 Requer a captura de pacotes e seus correspondentes timestamps por aplicaes
rodando em dispositivos conectados na rede em diversos pontos;
11 Pontos positivos:
22 No injeta trfego de teste e os dados so obtidos de dispositivos que esto envolvidos no funcionamento da rede.
11 Pontos negativos:
22 Impe certa sobrecarga nos dispositivos de rede para disponibilizar as informaes em adio a sua funo de encaminhar pacotes.
238
Padres para monitorao da rede

O Padro IPPM
11 IPPM IP Performance Metrics work group;

11 Desenvolveu um conjunto de mtricas padro que podem ser aplicadas para qualidade, desempenho e confiabilidade dos servios de entrega de dados da internet;
11 Os padres do IPPM so teis para uniformizao das medies, que podem ser realizadas na internet ou em redes IP privadas.
Por exemplo, as mtricas de atraso de pacotes em um sentido (one-way packet delay) e a
perda de pacotes em um sentido (one-way packet loss) j foram utilizadas em plataformas
de medies, como Surveyor.
Esses so exemplos de unificao de procedimentos. As medies de um nico sentido
(one-way) so antagnicas em relao s medies de ida-e-volta (round-trip), pois existem
muitas instncias nas quais os caminhos de ida e volta so diferentes entre si (em termos
de rota). Com isto, produz-se valores para mtricas de atraso mnimo, variao de atraso ou
perda de pacotes distintas.
O projeto perfSONAR
22 O projeto perfSONAR adota a abordagem de medio ativa e medio passiva,

alm dos procedimentos e mtricas definidas pelo IPPM para obteno de dados
de desempenho unidirecionais em redes IP;
22 A infraestrutura desenvolvida para realizar as medies composta de dispositivos de medio, servidores de anlise e bases de dados;
22 Os dispositivos de medio so equipamentos dedicados, com relgios GPS e
Sistema Operacional modificado para melhorar a preciso no relgio do sistema.
Fatores que influenciam o desempenho de rede

Bandwidth Delay Product (BDP):
banda de conteno/gargalo e o atraso do caminho.

11 Pode-se pensar BDP como uma capacidade memria de um caminho fim-a-fim, isto , a
quantidade de dados que cabem inteiramente no caminho entre os dois sistemas finais.
11 O BDP ajuda a estimar o tamanho timo da janela do TCP.
Unidade Mxima de Transmisso (MTU):
11 A MTU descreve o tamanho mximo de um pacote IP que pode ser transferido sobre
um canal de comunicao sem fragmentao
11 Tamanhos comuns de MTU so:
22 1500 bytes (Ethernet, 802.11 WLAN).
22 4470 bytes (FDDI, padro para POS e links seriais).
22 9000 bytes (Conveno da internet2 e GEANT, limite de alguns adaptadores
Gigabit Ethernet, Jumbo Frame).
22 9180 bytes (ATM, SMDS).
11 O Bandwidth Delay Product (BDP) de um caminho fim-a-fim o produto da largura de
239
Exemplo: resultados da medio da vazo mxima obtida entre dois servidores HPML385.
Na tabela 1, a vazo foi medida com Jumbo frame no habilitado, enquanto na tabela 2 o
MTU foi definido em 9000 Bytes (Jumbo frame habilitado).
Exemplo: Canal de 2Mbps e atraso RTT = 300ms
2000000 x 0,30 = 60.000 / 8 = 75.000 bytes = Valor da janela TCP, ou 2/8 = 0,25 * 0,3 =
0,75M = 75Kbytes.
Tabela 8.2
Servidor HP ML385
sem Jumbo frame.
Canal de 10Mbps, atraso RTT = 100ms

10000000 x 0,10 = 1.000.000 / 8 = 125000Bytes = 125Kbytes = Valor da janela TCP.
Caminhos de redes com BDP alto so chamados de Long Fat Networks ou LFN.
Exemplo:Exemplo: Redes de satlite tem alta banda e alto atraso.

O BDP um parmetro importante para o desempenho de protocolos baseados em janela
(window-based protocols). Exemplo:Exemplo: TCP.
Vazo e Perdas Camada 3

[ 3]
569 MBytes
955 Mbits/sec
0.034 ms
1024/406888 (0.25%)
[ 3]
569 MBytes
955 Mbits/sec
0.003 ms
1056/406915 (0.26%)
[ 3]
569 MBytes
955 Mbits/sec
0.012 ms
1088/406946 (0.27%)
[ 3]
569 MBytes
955 Mbits/sec
0.002 ms
1056/406915 (0,26%)

[ 3]
569 MBytes
955 Mbits/sec
0.003ms
1024/406889 (0.25%)
[ 3]
569 MBytes
955 Mbits/sec
0.002ms
1056/406915 (0.26%)
[ 3]
569 MBytes
955 Mbits/sec
0.002ms
1088/406947 (0.27%)
[ 3]
569 MBytes
955 Mbits/sec
0.024ms
1056/406916 (0,26%)
240
[ 3]
0.0 - 5.0 sec
591 Mbytes
992 Mbits/sec 0.002 ms
25/69704 (0036%)
[ 3]
5.0 - 10.0 sec
591 Mbytes
35/69715 (005%)
[ 3]
10.0 - 15.0 sec
591 Mbytes
30/69709 (0043%)
[ 3]
15.0 - 20.0 sec
591 Mbytes
35/69714 (005%)

[ 3]
0.0 - 5.0 sec
591 Mbytes
25/69704 (0036%)
[ 3]
5.0 - 10.0 sec
591 Mbytes
35/69714 (005%)
[ 3]
10.0 - 15.0 sec
591 Mbytes
30/69709 (0043%)
[ 3]
15.0 - 20.0 sec
591 Mbytes
35/69715 (005%)
Tabela 8.3
Servidor HP ML385
com Jumbo frame.
Atraso fim-a-fim em um sentido

11 O atraso fim-a-fim em um sentido (One-Way Delay OWD) o tempo que um pacote
leva para atingir seu destino de fim-a-fim.

11 o tempo entre a ocorrncia do primeiro bit de um pacote no primeiro ponto de
observao (interface de monitoramento transmissora) e a ocorrncia do ltimo bit
do pacote no segundo ponto de observao.
11 Padro que define a mtrica Atraso fim-a-fim em um sentido.
11 RFC 2679: A One-way Delay Metric for IPPM.
11 Formas de medio.
11 RFC 3763: One-way Active Measurement Protocol (OWAMP).
O atraso fim-a-fim em um sentido (OWD) pode ser decomposto em atraso por hop, ou
seja, o atraso observando entre um salto e outro na rede. O atraso por hop ainda pode ser
w
Para saber mais, acesse
http://www.ietf.org/
rfc/rfc2679.txt.
decomposto em atraso por canal de comunicao (link) e por n de rede (roteador).

O atraso em um sentido uma mtrica de desempenho definida pelo IPPM segundo o RFC
2679: A One-way Delay Metric for IPPM.
A medio do atraso em um sentido fim-a-fim exige a sincronizao precisa dos relgios de
ambos os sistemas finais.
O RFC 3763: One-way Active Measurement Protocol (OWAMP) Requirements define como
essa mtrica pode ser medida.
11 Erros e Incertezas na medio;
11 Sincronizao entre pontos de observao;

11 Perda de pacotes;
11 Fragmentao;
11 Impreciso dos carimbos de tempo (timestamps);
11 Aplicabilidade:
22 Detectar sintomas de congestionamento na rede e determinar exatamente em
qual sentido da comunicao o congestionamento est ocorrendo;
22 Realizar a medio com alta preciso;
VoIP
Voz sobre IP.
22 Validar certas aplicaes na rede, tais como VoIP e vdeo.

Os seguintes fatores a seguir contribuem para a existncia de erros e incertezas na medio
do atraso em um sentido:
11 Sincronizao entre pontos de observao;
11 Perda de pacotes;
11 Fragmentao;
11 Impreciso dos carimbos de tempo (timestamps).
A sincronizao dos relgios dos pontos de medio em fontes de sincronizao de alta preciso do tipo GPS faz com que se obtenha preciso da ordem de microssegundos.
A medio do atraso em um sentido permite validar certas aplicaes na rede, tais como
VoIP e Vdeo. Essas aplicaes possuem restries quanto ao atraso mximo em um sentido.
11 Unidade de Medio: ms (milissegundos);
241
11 Composio do OWD:
22 Atraso por canal de comunicao (link):
33 Atraso de serializao;
33 Atraso de propagao.
22 Atraso por n de rede (roteador)
33 Atraso de enfileiramento;
33 Atraso de encaminhamento (forwarding).
22 Atraso de Serializao:
33 O atraso de serializao o tempo necessrio para separar um pacote em unidades de transmisso sequenciais no canal (link).
22 Atraso de propagao:
33 O atraso de propagao o tempo de durao para mover os sinais (bits) do
transmissor para o receptor de um canal de comunicao.
33 Fonte: http://kb.pert.geant.net/PERTKB/SerializationDelay
Fibre lenght
One-way delay
Round-trip time
1m
5 ns
10 ns
1km
5 s
10 s
10km
50 s
100 s
100km
500 s
1 ms
1000km
5 ms
10 ms
10000km
50 ms
100 ms
Atraso de propagao na fibra ptica em diferentes distncias

Fonte: http://kb.pert.geant2.net/PERTKB/PropagationDelay
11 Atraso por n de rede;

11 Atraso de Enfileiramento:
22 Tempo que um pacote permanece dentro de um n tal (como um roteador)
enquanto espera pela disponibilidade do canal de sada.
11 Atraso de encaminhamento:
22 Refere-se ao processamento feito no n.
242
Link Rate
64 kb/s
1 Mb/s
10 Mb/s
100 Mb/s
1Gb/s
64 bytes
8 ms
0,512 ms
5.12 s
5.12 s
0.512 s
512 bytes
64 ms
4.096 ms
409,6 s
40.96 s
4.096 s
1500 bytes
185,5 ms
12 ms
1.2 ms
120 s
12 s
9000 bytes
1125 ms
72 ms
7.2 ms
720 s
72 s
Packet Size
Saiba mais
O traceroute incrementa o TTL em uma
unidade para cada
conjunto de pacotes
que ele envia, conseguindo assim realizar
o rastreamento dos
gateways/roteadores
pelo caminho.
Na tabela so apresentados os tempos de atraso de serializao para diferentes tamanhos

de pacotes em canais de comunicao com diferentes capacidades de transmisso ou diferentes taxas de bits por segundo.
O atraso de serializao o tempo necessrio para separar um pacote em unidades de
transmisso sequenciais no canal (link).
A unidade sequencial de transmisso em geral o bit. O atraso de serializao obtido pela
diviso do tamanho do pacote (em bits) pela capacidade do canal em bits por segundo.
Atualmente, com a existncia de links com alta taxa de bits, o atraso de serializao
pouco relevante.
Atraso fim-a-fim bidirecional (ida e volta)

11 O atraso bidirecional (ida e volta) ou (Round Trip Time RTT) a soma do atraso em
um sentido da fonte para o destino, do destino para a fonte e mais o tempo que o
destino leva para formular a resposta.
11 Padro que define a mtrica:
22 IPPM RFC 2681: A Round-trip Delay Metric for IPPM
11 Formas de medio:
22 Injeo de pacotes na rede, podendo usar os protocolos ICMP, UDP ou TCP.
11 Unidade de medio:
22 Tipicamente em milissegundos.
11 Aplicabilidade:
22 Detectar sintomas de congestionamento na rede.
22 Identificar baixo desempenho em TCP, em canais de alta capacidade.
22 Medir a disponibilidade de dispositivos de rede.
22 Estimar o atraso sem a necessidade de sincronizao de relgios.
de requisio enviado pelo n fonte e o instante de tempo que ele recebe o pacote de
resposta correspondente. O pacote de resposta deve ser enviado ao n fonte assim que o
pacote de requisio for recebido.
Valores altos de RTT podem causar problemas para o TCP e outros protocolos de transporte
baseados em janela.
Esse comportamento do TCP pode ser exemplificado no clculo da vazo TCP terica entre o
PoP-SC -> internet2.edu.
Ou seja, o atraso entre esses dois sites na internet da ordem de 200ms a janela TCP
padro de 64Kbps. Pela frmula do BDP, visto anteriormente, conclui-se que a vazo
mxima ser da ordem de 2,6Mbps.
Exemplo do clculo do BDP com janela de 64K e atraso de 200ms:
O RTT pode ser definido tambm como o perodo entre o instante de tempo que um pacote
243
Janela(Bytes) = banda(Bytes) X Delay(seg)

Banda = 65.536 / 0.2
Banda = 327.680 / 0.2
Banda = 2.621.440 bits/s ou 2.62 Mbps
Variao do atraso Jitter

11 O atraso unidirecional (OWD One Way Delay) no constante em uma rede real.
11 Define-se variao de atraso, comumente jitter, como sendo a diferena entre o OWD
do pacote atual e a mdia do OWD.
11 Segundo o IETF, dados um conjunto de pelo menos dois pacotes entre A e B, a
variao do atraso a diferena do atraso em um sentido (OWD) de um par selecionado de pacotes no conjunto.
11 Erros e incertezas na medio:
22 Sincronizao entre pontos de observao.
22 Perda de pacotes; Fragmentao.
22 Impreciso dos carimbos de tempo (timestamps).
22 RFC 3393: IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)
22 Tipicamente em milissegundos
11 Aplicabilidade:
22 Predio de desempenho de aplicaes sensveis variao do atraso (VoIP).
22 Dimensionamento do de-jitter buffer.
O ITU-T define a variao do atraso com a diferena entre o percentil 99,9 do OWD e um
atraso referncia (aconselhado atraso mnimo do caminho).
Perda de pacotes em um sentido

11 A mtrica perda de pacotes definida como a probabilidade de um pacote ser
perdido no trnsito de uma origem A para um destino B.
11 A taxa de perda indica o percentual de pacotes perdidos quando observado em um
ponto de recepo em relao ao nmero de pacotes transmitidos em um ponto de
244
transmisso em um intervalo de tempo.

22 RFC2680: A One-way Packet Loss Metric for IPPM
11 Formas de medio:
22 A perda de pacotes pode ser medida de forma ativa atravs do envio de pacotes de
uma fonte para um destino.
22 Esse valor mensurado atravs da razo entre o nmero de pacotes recebidos
sobre o nmero total de pacotes enviados.
22 Sincronizao entre pontos de observao.

22 Perda de pacotes.
22 Fragmentao.
11 Unidade tpica de medio:
22 % (percentual) = total de pacotes recebidos/total de pacotes transmitidos.
11 Aplicabilidade:
22 Predio de desempenho de aplicaes sensveis a perdas de pacotes.
22 Identificar problemas de comunicao na camada fsica.
22 As suas principais razes para se ter perdas de pacotes na rede o congestionamento e os erros.
11 Perdas por congestionamento:
22 Quando a carga excede a capacidade de uma parte da rede, pacotes so enfileirados (bufferizados).
22 O congestionamento pode estourar as filas e se conduzir a perdas de pacotes.
11 Perdas por erro:
22 Uma razo para a perda de pacotes a degenerao dos dados, onde partes do
pacote so modificadas em trnsito.
22 Rudos das linhas normalmente so detectados pelo checksum (CRC) na camada
de enlace na recepo, quando ento o pacote descartado.
Aplicaes que requerem transmisso confivel (exemplo: Transferncia de arquivos) usam
retransmisso, tcnica que pode reduzir o desempenho.
Protocolos sensveis a congestionamento, tal como o TCP padro, assumem que a perda de
pacotes ocorre devido a congestionamento e respondem reduzindo sua taxa de transmisso
proporcionalmente.
longos perodos de tempo ou pela chegada repentina de uma quantidade muito grande de
trfego (trfego em rajada).
Vazo (largura de banda alcanvel)

11 a taxa mxima (camada IP) que um fluxo pode alcanar em um caminho na presena de trfego (com carga).
11 A vazo o montante de trfego de dados movidos de um n da rede para outro em
um determinado perodo de tempo.
22 Equipamentos para testes disponveis e adequados.
22 Protocolo de transporte utilizado (TCP/UDP).
11 Formas de medio:
22 Realizao de testes especficos usando equipamentos adequados nas extremidades do caminho desejado.
22 Unidade de medio.
O congestionamento pode ser causado por condies de carga moderada mantidas por
22 Bits por segundo (bps) ou mltiplos (Mbps, Gbps).

245
11 Aplicabilidade:
22 Certificao do enlace contratado.

22 Dimensionamento de aplicaes.
22 Simulao e aplicao rodando na rede.
A largura de banda alcanvel ou vazo a mtrica definida como a quantidade mxima de
dados (bits de pacotes IP) por unidade de tempo que pode ser transmitida atravs de um
caminho consistindo de mltiplos canais, cada um deles exibindo um nvel especfico de
utilizao, entre dois ns finais da rede.
Os seguintes fatores a seguir contribuem para a existncia de erros e incertezas na medio
do atraso em um sentido:
11 Equipamentos para testes disponveis e adequados: para medir a largura de banda
alcanvel, devemos possuir equipamentos capazes de gerar trfego na capacidade
nominal mxima do canal de comunicao sendo medido. Por exemplo, para a medio
do canal/caminho de comunicao de 1Gbps, devemos ter disposio equipamentos
com capacidade para gerar trfego (TCP ou UDP) nessa capacidade;
11 Protocolo de transporte utilizado (TCP/UDP): em redes IP geralmente se faz a medio
utilizando o protocolo TCP ou UDP. O TCP possui capacidade de recuperao de erros
e controle de fluxo, e til para estimar a vazo mxima do canal/caminho quando
utilizando o protocolo utilizado pela maioria das aplicaes. O UDP, protocolo de controle
de fluxo, pode ser usado quando se deseja estressar a capacidade mxima do canal/
caminho ou mesmo verificar se este capaz de suportar uma determinada vazo sem
apresentar perdas.
Largura de banda de conteno

11 a mtrica que define a capacidade do enlace de menor capacidade em um caminho.
11 O que implica ser a taxa mxima (camada IP) que um fluxo pode alcanar em um
caminho quando no existe trfego (sem carga).
22 So os mesmos que implicam nos erros e incertezas das mtricas de vazo.
11 Formas de medio:
22 Realizao de testes especficos usando equipamentos adequados nas extremidades do caminho desejado.
22 Bits por segundo (bps) ou mltiplos (Mbps, Gbps).
246
11 Aplicabilidade:
22 Certificao do enlace contratado.
22 Dimensionamento de aplicaes.
22 Simulao e aplicao rodando na rede.
Mtricas de medies passivas

Mtricas que podem ser obtidas atravs de medies passivas:
11 Descartes.
11 Erros.
11 Atraso em um sentido.
11 Largura de banda utilizada.
11 Fluxos.
11 Disponibilidade.
Descartes
11 um contador representando o nmero de pacotes descartados para uma determi-
nada interface de rede.

11 Coletado via SNMP ou CLI do equipamento.
11 Usado para deteco de links congestionados ou mal provisionados (descartes na
sada da interface).
uma mtrica normalmente obtida atravs do SNMP ou CLI que indica o nmero de pacotes
descartados para uma determinada interface de rede. Um descarte pode ser ocasionado
em condies normais devido ao congestionamento de um enlace. Na maioria dos equipamentos de rede, possvel configurar as polticas de enfileiramento e descartes, como FIFO,
RED, WRED etc.
Erros e incertezas na medio:
11 Equipamentos de rede indevidamente configurados;
11 Problemas de buffer overflow dos contadores;
11 Processador lento.
11 Atravs da coleta de dados via SNMP;

11 Atravs da visualizao dos contadores via CLI.
Unidade de medio:
11 Contador.
Aplicabilidade:
11 Deteco de links congestionados ou mal provisionados (descartes na sada da interface);
11 Descartes na entrada da interface podem indicar erro de configurao, como, por exemplo,
uma vlan incorretamente permitida em uma ponta do link e no existente na outra.
Erros
11 um contador que representa o nmero de erros em uma determinada interface
(CRC e FCS).
11 Coletado via SNMP ou comandos remotos nos ativos de rede.
11 Dessa mtrica derivada a taxa de erros, que a razo entre o nmero de pacotes
que no foram entregues ao destino final e o nmero total de pacotes, em um deter-
Formas de medio:
minado perodo de tempo (unidade em percentual).

247
11 usado para deteco de links intermitentes ou problemas de hardware.
11 Ocorrem devido a:
22 Erros nos pacotes.
22 Erros de transmisso.
22 Insuficincia da taxa de transmisso.
uma mtrica normalmente obtida atravs de SNMP, que indica o nmero de erros em uma
determinada interface.
11 Frame Check Sequence (FCS);
11 Cyclic Redundancy Check (CRC).
Valores elevados de erros de FCS/CRC so indicativos de problemas no meio de transmisso,
como por exemplo um link WAN fornecido pela operadora ou uma fibra ptica mal conectada em uma rede de Campus.
Taxa de erros:
a razo entre o nmero de pacotes que no foram entregues ao destino final e o nmero
total de pacotes, em um determinado perodo de tempo.
As perdas de pacotes normalmente ocorrem devido a:
11 Erros nos pacotes:
22 Cabealhos: descarte em roteadores;
22 Dados (payload): descarte pelo Sistema Operacional;
22 Erros de transmisso em geral, inerentes aos meios de transmisso, falhas em equipamentos ou ocorridos no nvel de enlace;
22 Insuficincia da taxa de transmisso (banda de rede) em relao aos requisitos da taxa
de transferncia: estouros de buffer e descartes de pacotes.
11 Equipamentos de rede indevidamente configurados;
11 Problemas de buffer overflow dos contadores.
Formas de medio:
11 Atravs da coleta de dados via SNMP;
11 Atravs de comandos remotos nos ativos de rede.
Unidade de medio:
248
11 A unidade de medio de erros o contador de erros. J a taxa de erros o percentual de

pacotes com erros, ou seja, total de pacotes com erros sobre o total de pacotes.
Aplicabilidade:
11 Deteco de links intermitentes;
11 Deteco de problemas de hardware.
Atraso em um sentido (One-Way Delay OWD)

11 a coleta de cabealho de um trfego real, passando em ns observadores, onde
agregado o timestamp e correlacionados os dados para medir o OWD, resultando em

uma mtrica em milissegundos.
11 Podem ocorrer erros de sincronismos, que podem deturpar os resultados.
11 Aplica-se para medir o tempo de propagao de um pacote entre dois pontos na rede.
Em redes de alta velocidade possui limitaes de implementao e escalabilidade.
11 Erros de sincronismo de relgio.
Formas de medio:
11 Coleta dos timestamps nos pontos de observao. A ferramenta Coralreef, desenvolvida
no contexto do projeto Cooperative Association for internet Data Analysis (CAIDA), pode
ser utilizada para realizar esse tipo de medio: http://www.caida.org;
11 Unidade de medio: Milissegundos;
11 Aplicabilidade: medir o tempo de propagao de um pacote entre dois pontos na rede.
Largura de banda usada

11 Quantidade de trfego (calculada em bits por segundo ou mltiplos) em um enlace
em um determinado momento.
11 limitada pela capacidade dos contadores de medio.
11 Usada para planejamento de capacidade, contabilizao e perfil de comportamento
do trfego e deteco de anomalias.
11 Pode ser obtida atravs de contadores de trfego dos roteadores, SNMP e CLI.
Quantidade de trfego em um enlace em um determinado momento. A quantia da capaci(perodo) (normalmente 5-15 minutos).
Erros e incertezas na medio
Capacidades dos contadores. O SNMPv1 possui limitao de capacidade dos contadores.
Em redes com muito trfego, esses podem estourar e reiniciar para zero entre uma coleta e
outra.
Formas de medio
11 Contadores de trfego dos roteadores;
11 SNMP e CLI.
Com SNMP, a varivel ifInOctets contm o nmero total de octetos recebidos pela interface
e a varivel ifOutOctets contm o total de octetos transmitidos pela interface.
Unidade de medio
11 Bits por segundo (bps) ou mltiplos (Mbps e Gbps).
dade usada por pacotes IP (ambos cabealho e dados) sobre uma janela de tempo especfica
249
Aplicabilidade
11 Planejamento de capacidade;
11 Contabilizao;
11 Perfil de comportamento do trfego e deteco de anomalias.
Fluxos
11 utilizada para avaliar o trfego sendo transmitido na rede (amostra ou total),
podendo prover informao de utilizao.

11 Fluxo: IP fonte, IP destino, protocolo sobre o IP, porta fonte e porta destino.
11 usualmente obtida nos roteadores.
11 Pode ser utilizada para determinar, por tipo de fluxo, a durao e a quantidade do
trfego de uma aplicao que est cruzando a rede.
11 medida atravs de protocolos presentes nos roteadores (Netflow, J-FLow, Sflow) e/
ou espelhamento de interfaces.
11 Aplica-se principalmente para segurana, contabilizao, planejamento de rede e
engenharia de trfego.
Mtricas relacionadas a fluxos de dados usualmente obtidas dos roteadores.
Erros e incertezas na medio
11 Medio por amostragem, podendo ser em diversas escalas, como 1 para 1, 1 para 200,
1 para 1000, 1 para N;
11 Depende do processamento dos roteadores, se estiverem congestionados pode haver
perda na medio;
11 Pode existir perda na hora de exportar os fluxos para os coletores, pois normalmente
esse processo realizado atravs de UDP.
Formas de medio
11 Atravs de protocolos presentes nos roteadores, como Netflow, J-FLow e Sflow;
11 Atravs do espelhamento de interfaces para gerar a contabilizao, como Flow-Capture
(flow-tools) e CoralReef.
Unidade de medio
11 Dependente da mtrica.
Aplicabilidade
250
11 Segurana/Deteco de anomalias;
11 Estudo de padres de trfego;
11 Planejamento de redes;
11 Engenharia de trfego;
11 Contabilizao (Accounting);
11 Bilhetagem (Billing).
Disponibilidade
11 a medida percentual do tempo durante o qual um canal de comunicao, dispositivo
de rede ou servio est totalmente funcional em relao ao estado no funcional.

11 aplicada principalmente em acordos de nveis de servios (SLA), onde paradas programadas podem ser consideradas para o clculo da mtrica.
11 Pode ser obtida atravs do monitoramento de Variveis SNMP, anlise de comandos
de CLI, monitoramento do estado do servio e/ou ferramenta baseada em ICMP.
A disponibilidade calculada pela medio do uptime ou downtime de um dispositivo da
rede ou servio usando medies passivas.
Paradas programadas (exemplo: dispositivos de rede ou servios que so derrubados para
manuteno) podem no serem consideradas no clculo da disponibilidade, dependendo do
Acordo de Nvel de Servio (SLA) firmado entre o provedor e o cliente.
11 A medio do estado operacional do dispositivo em intervalos de tempos muito grandes
pode acarretar na falta de preciso dessa medio. Com SNMP o uso de mecanismos de
trap (alerta) pode ser avaliada como opo para melhora da preciso.
Formas de medio
11 Monitoramento de Variveis SNMP;
11 Anlise de comandos de CLI;
11 Monitoramento do estado do servio;
11 Ferramenta baseada em ICMP.
Unidade de medio
11 A disponibilidade ou ndice de disponibilidade em geral expresso em % de tempo em
Aplicabilidade
11 Acordos de Nvel de Servio (SLA);
11 Largura de banda utilizada;
11 Fluxos;
11 Disponibilidade.
Ferramentas de diagnstico/monitorao da rede

11 Existem inmeras ferramentas desenvolvidas para esse fim.
11 As seguintes ferramentas so relevantes para o diagnstico e monitorao das redes:
22 Ping.
22 Traceroute.
22 OWAMP.
22 IPERF.
22 NDT etc.
que o estado foi funcional em relao ao tempo total observado.
251
Existem inmeras ferramentas que auxiliam o diagnstico e desempenho da rede. Como Ping,
Traceroute, OWAMP, IPERF, NDT etc. As principais ferramentas sero abordadas a seguir.
Ping
11 Uma das mais antigas e utilizadas ferramentas de diagnstico.
11 Baseada em mensagens ICMP (Echo Request/Echo Reply).

11 Reporta:
22 RTT entre os pacotes enviados, sumarizando.
22 Tempo (Mnimo, Mdio, Mximo e desvio padro).
22 Pacotes Enviados/perdidos (nmero e percentual).
Ping uma das mais antigas ferramentas que tem como intuito medir a alcanabilidade de
um host e o atraso de ida-e-volta atravs do envio de mensagens ICMP do tipo echo Reques/
Echo Reply. Essa ferramenta est presente na maioria dos dispositivos de rede e Sistemas
Operacionais, e permite mostrar o atraso e perdas de pacotes.
Quando existe um congestionamento na rede, na maioria dos casos observando a mtrica
de variao do atraso (jitter), quanto maior seu tempo, maior o congestionamento na rede.
Um atraso alto e constante pode representar uma caracterstica do meio de propagao,
como por exemplo, o satlite que possui aproximadamente 500ms de ida-e-volta.
Cabe salientar que se dispararmos pings para equipamentos de rede, como roteadores e
switches, podemos ter uma falsa impresso de congestionamento, pois estes no priorizam
a resposta do ping, pois sua finalidade rotear/comutar os pacotes. A melhor forma sempre
realizar medies com hosts finais ou mquinas dedicadas para medies.
Traceroute
11 Baseada no campo TTL do pacote IP.
11 Incrementa o TTL em uma unidade para cada conjunto de pacotes.

11 O roteador, ao receber o pacote, decrementa-o em uma unidade e, como seu valor
chega a zero, envia uma mensagem ICMP (time exceeded in-transit).
11 Reporta:
22 Caminho percorrido de um pacote at seu destino.
22 Reporta o atraso (RTT) em cada n.
Traceroute um utilitrio que mostra o caminho que um pacote percorreu em uma rede
IP at chegar ao destino. Essa ferramenta tambm pode ajudar a diagnosticar se existem
pontos de congestionamento at o destino de final, pois reporta o atraso de cada n.
252
Para realizar esse rastreamento do caminho por onde o pacote passou, o traceroute utiliza
o campo TTL (Time to Live) do cabealho IP. O TTL um mecanismo criado para evitar que
loops de roteamento acabem fazendo com que os pacotes fiquem circulando para sempre
na rede. Para contornar isso, o campo TTL decrescido de 1 unidade a cada roteador por
onde o pacote passa. Quando esse nmero chega a 0 (zero), uma mensagem ICMP time
exceeded in-transit enviada pelo roteador.
OWAMP
11 One-way Active Measurement Protocol.
11 Baseado na RFC 4656.

11 Protocolo que define as medies em um sentido.
22 One Way Delay (OWD).
11 Ferramenta OWAMP:
22 Implementa o protocolo.
22 Tambm conhecida como One-Way Ping.
11 Finalidade: realizar medies em um sentido.
11 Requer sincronismo dos hosts via NTP.
22 Recomenda-se Stratum 1 para melhor acuracidade.
O One-way Active Measurement Protocol (OWAMP) um protocolo definido na RFC 4656
que define o protocolo para a implementao de medies ativas em um sentido. Uma
implementao desse protocolo que leva o mesmo nome do protocolo a ferramenta
OWAMP (tambm chamada de One-Way Ping).
Essa ferramenta tem como finalidade medir o atraso em um sentido, diferente da ferramenta ping, que mede o atraso de ida-e-volta.
Para realizar medies de atraso em um sentido, imprescindvel que os hosts estejam
com seu relgio sincronizado, pois um carimbo de tempo marcado na origem e em sua
chegada, sendo a diferena do tempo de chegada e sada o atraso.
Caso o relgio do host A esteja com horrio diferente de B, mesmo que esteja no mesmo
segundo de tempo, haver um erro na medio que poder influenciar no atraso em um
sentido. Normalmente os pontos de medio so sincronizados com o protocolo Network
Time Protocol (NTP) e, para possuir uma melhor preciso, recomenda-se o uso de uma
fonte externa de sincronismo ao NTP, como o GPS, conectado diretamente nos pontos de
OWAMP Para que serve medies em um sentido

11 Identificar sentido de congestionamento.
11 Que geralmente ocorre primeiro em um sentido.

11 Roteamento (assimtrico ou pode sofrer mudanas).
11 Intervalos de Pooling SNMP mascaram grandes nveis de enfileiramento.
11 Medies ativas podem identificar esses pequenos congestionamentos.
Detectar congestionamentos na rede de forma mais precisa que com as ferramentas que implementam RTT, pois os congestionamentos geralmente acontecem primeiramente em um sentido,
j que a maioria dos canais de comunicao utilizados nas redes atuais so Full-DUPLEX.
Em um exemplo simples, geralmente na maioria das redes, o download dos usurios saturado, enquanto o pload est livre. Isso s vezes tambm notado em ligaes VoIP, quando um
dos locutores ouve perfeitamente a ligao e o outro sente que a ligao est picotada; com o
OWAMP, esse gargalo poderia ser identificado nos sistemas finais.
medio, capacitando o NTP a ser um servidor do tipo Stratum 1.
253
Roteamento (assimtrico ou existem mudanas)

Os intervalos de Pooling SNMP mascaram grandes nveis de enfileiramento que podem ser
melhor mostrados por medies ativas.
Existem muitas implementaes de One-Way delay (Surveyor, Ripe, MGEN etc.), mas so no
interoperveis, para isso o protocolo One-Way Delay (OWD) foi especificado na RFC.
A figura a seguir apresenta o funcionamento do OWAMP, no modo clssico, entre um cliente
e servidor.
Server
owampd
[Resource Broker]
Spawn
Child
Client
Inicial Connection
esult
st / R
e
Requ
owping Client
[Control]
Spawn
Child
owampd
[Control]
Spawn
Child
OWD
kets
t Pac
OWD Test Endpoint
Tes
OWD Test Endpoint
OWAMP Funcionalidades
11 Suporte a AAA.
Figura 8.17
OWAMP
Protocolo.
11 Controle de recursos de rede.

22 Banda mxima para um teste.
22 Com ou sem autenticao.
Com o OWAMP, possvel implementar autenticao, autorizao e contabilizao (do termo
em ingls AAA). Possibilita criar um arquivo com diversos parmetros de configurao, como
IPs autorizados para realizar testes, classes hierarquizadas de alocao de recursos (banda,
testes, autenticao etc.), suporte a autenticao usurio/senha, chave criptografa, IP ou
sem autenticao, se realizar ou no armazenamento das medies locais e onde, entre
outras inmeras configuraes.
254
$ owping owamp.pop-am.rnp.br
Approximately 13.8 seconds until results available
--- owping statistics from [owamp.pop-sc.rnp.br]:53874 to [owamp.pop-am.rnp.br]:50630 --SID: c8819c6acf40067165b5c233e151be3d
first: 2010-03-08T20:27:47.342
last:
2010-03-08T20:27:57.591
100 sent, 13 lost (13.000%), 0 duplicates

one-way delay min/median/max = 43.8/89.3/115 ms, (err=0.0763 ms)
one-way jitter = nan ms (P95-P50)
Hops = 7 (consistently)
no reordering
--- owping statistics from [owamp.pop-am.rnp.br]:53751 to [owamp.pop-sc.rnp.br]:64715 --SID:c8edc105cf4006717537c996cfb89310
first: 2010-03-08T20:27:47.163
last:
2010-03-08T20:27:57.213
100 sent, 0 lost (0.000%), 0 duplicates

one-way delay min/median/max = 36.1/40.6/94.2 ms, (err=0.0763 ms)
one-way jitter = 32.9 ms (P95-P50)
Hops = 7 (consistently)
no reordering
O uso bsico da ferramenta bastante simples nos parmetros padres, com o cliente
owping especificado um endereo de ponto de medio owamp e a ferramenta executa
100 testes da origem para o destino e mais 100 do destino para a origem. Conforme o
exemplo apresentado no slide ao lado.
Em negrito esto marcados os principais resultados obtidos com essa ferramenta, sendo
pacotes enviados (sent), pacotes perdidos (lost) e seu percentual, e se houve ou no pacotes
duplicados (duplicates).
Na prxima linha, apresenta o atraso em um sentido (one-way delay), sendo o tempo
mnimo/mediana/mximo e entre parnteses o erro da medio, em milissegundos,
baseado na soma dos erros fornecido pelo NTP em ambos os hosts. Alm disso, observa-se
duas medies, sendo a primeira os resultados da origem para o destino e a prxima do
destino para origem.
Analisando os testes acima, podemos observar facilmente que existe perda de pacotes de
SC g AC (13%) e no no sentido contrrio e ainda que essas perdas esto sendo provavelmente causadas por causa de congestionamento de algum enlace no caminho SC g AC,
pois o tempo da mediana referente ao atraso de 89.3ms, muito superior ao tempo mnimo
de 43.8ms. Outro indicativo de congestionamento o One-Way Jitter, quanto mais varivel
indica oscilaes no atraso. Dependendo do nmero elevado de perdas, a One-Way Jitter
desconsiderado e marcada como nan.
O One-Way Jitter, ou simplesmente variao de atraso em um sentido, calculado pela ferramenta se utilizando os percentis 95 e 50 (P95 e P50). A ferramenta obtm esse valor atravs
da subtrao do P95 com o P50, variveis que so mais explanadas a seguir.
Figura 8.18
OWPING Exemplo.
255
IPERF
11 Realiza testes de vazo em TCP e UDP.
11 Com ela, possvel medir a largura de banda mxima alcanvel em TCP.

11 Suporte a Ipv4, IPv6 e Multicast.
11 Resultados so apresentados pelo servidor, com os dados que ela realmente recebeu.
O IPERF uma ferramenta para mensurar desempenho da rede realizando testes de vazo
TCP e UDP.
Com ela, possvel medir a largura de banda mxima alcanvel em TCP, permitindo o
tunning de diversos parmetros e caractersticas do UDP.
Os testes so de memria para memria, evitando que operaes de I/O em disco
influenciem nos resultados.
O IPERF uma ferramenta que roda tanto como cliente quanto como servidor.
Possui suporte a Ipv4, IPv6 e Multicast.
Os resultados so apresentados pelo que o servidor realmente receber para medio em
UDP e TCP.
O UDP envia pacotes a uma taxa solicitada sem garantia de entrega.
O TCP reconhece a recepo de todos os pacotes e retransmite qualquer pacote que falte.
IPERF Caractersticas TCP

11 TCP.
22 O teste tenta utilizar toda a banda disponvel at ocorrer um congestionamento,

em caso de falha na entrega o TCP realiza a retransmisso.
22 Realiza a medio de largura de banda.
22 Reporta MSS e MTU.
22 Suporta o ajuste do tamanho das janelas do TCP.
Caractersticas especficas do TCP:
11 O teste em TCP reconhece a recepo de todos os pacotes, no caso de falta, h retransmisso de pacotes;
11 Realiza medio de largura de banda;
11 Reporta o tamanho do MSS e MTU;

11 Suporta o ajuste do tamanho das janelas do TCP;
11 Pode atuar com Multithread, ou seja, cliente e servidor podem ter mltiplas conexes
simultneas.
IPERF Caractersticas UDP

11 UDP:
22 O teste envia pacotes UDP na taxa especificada, sem garantia de entrega.
22 Usurio especifica a banda que quer enviar.
22 Medio de perda de pacotes, Jitter e pacotes fora de ordem.
22 Suporte a Multicast.
256
Caractersticas especficas UDP:

11 O teste em UDP envia pacotes a uma taxa solicitada sem garantia de entrega;
11 Clientes podem criar fluxos UDP para uma banda especfica, exemplo: 10Mbps;
11 H a medio de perda de pacotes, variao do atraso (jitter) e pacotes fora de ordem;
11 Suporte Multicast;
11 Pode atuar com Multithread, ou seja, cliente e servidor podem ter mltiplas conexes
simultneas.
(servidor) (ouvindo em TCP)

servidor$ iperf -s
....
(cliente)
cliente$ iperf -c 200.237.XXX.XXX -t 10
---------------------------------------------------------------------------------------------Client connecting to 200.237.XXX.YYY, TCP port 5001
TCP window size: 16.0 KByte (default)
---------------------------------------------------------------------------------------------[
3] local 200.237.XXX.XXX port 32908 connected with 200.237.XXX.YYY port 5001
3] 0.0-10.0 sec 1017 MBytes
11 Servidor ouvindo em TCP (Host remoto);

11 Cliente disparando testes para o servidor (-c), com durao de 10 segundos (-t).
Parmetros de rede relacionados

11 TCP (MSS) = MTU-40 Bytes.
11 Tamanho da janela do TCP.
11 MTU.
11 Tabela de parmetros de Sistemas Operacionais.
Existem diversos parmetros relacionados com o desempenho da rede que podem ser
utilizados para especificar melhor os testes realizados pela ferramenta. Destacam-se os
seguintes parmetros:
11 TCP(MSS) = MTU-40: esse indica o tamanho dos pacotes utilizados pelo TCP;
11 Tamanho da janela TCP: o mais relevante na questo de desempenho;
11 MTU: MTUs grandes reduzem o nmero de interrupes recebidas pelo sistema, incrementando a performance: Path MTU Discovery.
A seguir, h uma tabela que lista alguns parmetros de diferentes Sistemas Operacionais
que podem ser ajustados para aumentar as taxas de transferncias.
Figura 8.19
IPERF Exemplo.
853 Mbits/sec
257
Operating
System
RFC Path
MTU
Discovery
RFC1323
Suport
Default maximum
socket buffer size
Defalt TCP
socket
buffer size
Defalt UDP
socket buffer
size
EFC2018
SACK
Support
FreeBSD
Yes
Yes
256kB
32Kb
40Kb
Yes
Linux 2.4 and 2.6
Yes
Yes
64kB
32Kb
32Kb(?)
Yes
Mac OS X
Yes
Yes
256kB
32Kb
42kb (receive)
Yes!
Sun Solaris 10
Yes
Yes
1 MB TCP, 256kB UDP
48Kb
8kB
Yes
Windows XP
Yes
Yes
Clculo do BDP para utilizar o IPERF

11 Para melhorar os testes de vazo com TCP.
11 BDP = Banda em Mbytes/s * Atraso RTT (Segundos).
Yes
Tabela 8.4
Podem ser
ajustados para
aumentar as taxas
de transferncias.
11 RTT SC <-> PA ~ 60 ms
11 Menor enlace no caminho a 100 Mbps / 8 =12,5MB/s
11 BDP = 12,5 * 0,06 = 0,75 Mbytes
11 Janela TCP recomendada para vazo mxima = 750KB.
11 Para medir no IPERF, parmetro -W 750k
IPERF::SC <- PA Janela padro 64K
Figura 8.20
IPERF: Exemplo
1: Uso do BDP na
medio entre
SC e PA.
RECEIVE START
iperf -B 200.237.193.1 -P 1 -s -f -m -p 5045 -w 65536 -t 10
----------------------------------------------------------------Server listening on TCP port 5045
Binding to local address 200.237.193.1
TCP window size: 65536 byte
----------------------------------------------------------------[ 14] local 200.237.193.1 port 5045 connected with 200.129.132.13 port 5045
[ 14] 0.0-10.0 sec 9969664 Bytes 7.960.334 bits/sec
[ 14] MSS size 1448 bytes (MTU 1500 bytes, ethernet)
RECEIVER END
BWCTL::SC<-PA Janela Calculada 750K

RECEIVE START
iperf -B 200.237.193.1 -P 1 -s -f -m -p 5046 -w 768000 -t 10
258
----------------------------------------------------------------Server listening on TCP port 5046

Binding to local address 200.237.193.1
TCP window size: 768000 byte
----------------------------------------------------------------[ 14] local 200.237.193.1 port 5046 connected with 200.129.132.13 port 5046
[ 14] 0.0-10.2 sec 29802496 Bytes 23.405.799 bits/sec
[ 14] MSS size 1448 bytes (MTU 1500 bytes, ethernet)
RECEIVER END
O exemplo de medio mostra o emprego do clculo do BDP para realizar o ajuste da janela;
possvel observar uma tima melhora na vazo, de 7.9Mbps para 23.4Mbps.
Figura 8.21
IPERF: Exemplo 2
(parte 1): Efeito do
tamanho da janela
TCP na vazo.
As figuras mostram o efeito do tamanho da janela TCP na vazo mxima alcanada.
Figura 8.22
IPERF Exemplo 2
(parte 2).
Nesse caso, a janela TCP com a vazo correspondente foram:

(RTT ~ 6ms):
11 Janela TCP de 75KB = Largura de banda de 100 Mbps;

11 Janela TCP de 420K = Largura de banda de 413Mbps.
NDT
11 Network Diagnostic Tool.
11 Prov testes de diagnstico de configurao e desempenho de rede.

11 Baseado no kernel WEB100.
11 O usurio final realiza a diagnstico atravs de seu navegador WEB.
11 Recomendado para testes de ltima milha.
O NDT um aplicao cliente/servidor que prov testes de configurao e performance de
rede para os usurios finais. Ela composta por um cliente (linha de comando ou Applet
Java) e um servidor (servidor pginas web e um engine de teste/anlise). O servidor utilizar
um kernel de Linux modificado (WEB100) para capturar estatsticas de fluxos TCP e retorna
aps os testes resultados multinveis, permitindo aos usurios novatos ou avanados compreenderem melhor os resultados.
11 Janela TCP de 64KB = Largura de banda de 42 Mbps;
259
Uma das grandes vantagens que ela pode ser utilizada pelo usurio final em qualquer
lugar e em qualquer tempo, sem a necessidade de um software adicional, sendo necessrio
somente um navegador WEB com suporte a Java instalado. Ela foi projetada para identificar de forma rpida e fcil condies especficas de problemas normalmente encontrados
prximos ao usurio que impactam o desempenho da rede, pois a grande maioria dos problemas de desempenho ocorrem na ltima milha prximos dos usurios em suas estaes
de trabalho; sendo assim, essa ferramenta recomendada para testes de ltima milha.
Ela possibilita o usurio final ter uma viso do desempenho da rede, facilitando a ajuda na
identificao de problemas de configurao de rede (falha na negociao do Duplex, por
exemplo), desempenho (incluindo problemas na estao do usurio), fornecendo algumas
evidncias que podem ajudar usurios e administradores a isolar problemas.
uma ferramenta de diagnstico em tempo real, no utilizando dados histricos de
medies. Ela funciona atravs de assinaturas de rede, desenvolvidas para identificar
problemas tpicos que acontecem na maioria das redes, alm de realizar alguns aconselhamentos para melhorar o desempeno de uma conexo.
O modo de operao do NDT funciona atravs da execuo de testes de ida e volta para
obteno de dados fim-a-fim, alm da obteno de dados de mltiplas variveis do servidor.
Aps ser realizada a comparao do desempenho atravs de valores analticos, realizada a
traduo de valores de rede em mensagens de texto, gerando um diagnstico mais voltado a
rede de campus, onde os usurios esto geralmente bem conectados no backbone da universidade e participando de uma rede acadmica de alta capacidade de transmisso de dados.
O que o NDT pode fazer

11 Identificar se o Cliente, Servidor ou a Rede esto operando conforme esperado.
11 Fornecer informaes para ajuste da aplicao.

11 Sugerir mudanas para melhorar o desempenho.
11 Dizer ao usurio final que tem algo errado mesmo quando o administrador da rede
diz Tudo est normal, o problema deve ser sua mquina ou aplicao.
O NDT pode detectar o canal mais lento em um caminho fim-a-fim, medindo o tempo de
chegada entre os pacotes (atravs da libpcap) e conhecendo o tamanho de cada pacote. Ele
pode calcular a taxa de transferncia (velocidade) para cada par de pacotes enviados ou
recebidos. Os resultados so quantificados segundo os padres de tecnologias (Ethernet,
FE, t3). O NDT no reporta velocidades fracionadas ou agregadas (LACP). Em implementaes futuras identificar redes sem fio.
Outra informao interessante que o NDT pode reportar a deteco de erro na negociao do
modo Duplex, que uma falha de negociao entre a placa de rede do PC e do switch. Ela acar-
260
reta alto impacto no desempenho, embora exista a conectividade bsica. No pode ser detectado por ping, traceroute e faz com que as aplicaes de rede rodem extremamente lentas.
Alm disso, pode ser til na deteco de perdas ocorridas sem congestionamento, como
falha na placa de rede ou Interface do Switch, problemas no cabo UTP, sujeira no conector
ptico etc. Trabalhos preliminares indicam que possvel distinguir entre perdas ocorridas
por congestionamento e ocorridas sem congestionamento.
Possibilita a deteco de conexo half-duplex em caminho fim-a-fim, identificando quando a
vazo limitada por operaes half-duplex.
As infraestruturas de redes compartilhadas causam episdios de congestionamentos peridicos, possibilitando a deteco e relatrio quando a vazo limitada por trfego cruzado
ou pelo prprio trafego gerado pelo NDT.
O que o NDT no pode fazer

11 Dizer exatamente onde est o problema na rede.
11 Dizer como os outros servidores esto operando.

11 Dizer como os outros clientes esto operando.
A figura mostra um exemplo do applet Java executado pelo cliente reportando a banda
enviada e recebida.
Tenta detectar o menor link no caminho essa informao no muito precisa.
Caso o usurio clique em estatsticas e mais detalhes, nveis de diagnstico mais detalhados
sero apresentados.
perfSONAR
11 uma infraestrutura de monitoramento de desempenho de redes para resolver
problemas de desempenho fim-a-fim.

11 Arquitetura baseada em servios.
11 definido em trs contextos:
22 Um consrcio de organizaes.
22 Um protocolo.
22 Pacotes de software interoperveis.
11 Parceiros:
22 RNP, internet2, GANT e Esnet.
11 Principais Servios:
22 MP, MA, LS, AS, entre outros.
O perfSONAR uma infraestrutura de monitoramento de desempenho de redes, o qual foi
projetado para facilitar a resoluo de problemas de desempenho fim-a-fim. Contm um
conjunto de servios que entregam medies de desempenho em um ambiente federativo.
Esses servios formam uma camada intermediria entre as ferramentas de medies de
Figura 8.23
NDT Exemplo
de uso.
261
performance e as aplicaes de visualizao e/ou diagnstico. Essa camada foi projetada

para realizar e trocar ou exportar medies de desempenho entre as redes, usando protocolos bem definidos.
uma arquitetura orientada a servios. Isso significa que o conjunto de funes elementares tm sido isoladas e podem ser providas por diferentes entidades chamadas servios.
Todos esses servios se comunicam entre si usando protocolos bem definidos. O perfSONAR
definido em trs contextos: um consrcio de organizaes, um protocolo e pacotes de
software interoperveis.
Os principais servios disponibilizados pelo perfSONAR so: Measurement Point Service,
Measurement Archive Service, Lookup Service, Authentication Service, Transformation
Service, Resource Protector Service e Toplogy Service, servios que so definidos pelo GFD.
Os parceiros envolvidos nessa iniciativa so contemplados nas redes da ESnet, GANT,
internet2 e RNP.
General Framework Design (GFD)

11 a especificao da arquitetura de monitoramento orientada a servios.
11 Ao conjunta entre a atividade GN2-JRA1 (Performance Measurement) e o internet2

piPEs (End-to-End Performance Initiative, Peformance Environment System).
O General Framework Design (GFD) a especificao de uma arquitetura de monitoramento
orientada a servios. Ele foi definido por uma ao conjunta entre a atividade GN2-JRA1
(Performance Measurement) e o internet2 piPEs (End-to-End Performance Initiative,
Peformance Environment System).
Identificao e definio de servios

definido por:
11 Servios de infraestrutura: LS, TopS e AA.

11 Servios produtores e consumidores de dados: MP, MA, RP e TS.
Infraestrutura mnima composta pelos seguintes servios:
11 MP, MA e LS (AA opcional porm fortemente recomendado).
O GFD definiu um conjunto de servios de monitoramento. Ele definido por servios
produtores e consumidores de dados e por servios de infraestrutura. No que se refere
infraestrutura, podem-se citar os seguintes servios:
11 Lookup Service (LS);
11 Topology Service (TopS);
262
11 Authentication Service (AA).

Para os servios produtores e consumidores de dados, citamos:
11 Measurement Point Service (MP);
11 Measurement Archive Service (MA);
11 Resource Protector Service (RP);
11 Transformation Service (TS).
A infraestrutura mnima para formar uma arquitetura perfSONAR composta por pelo menos
os seguintes servios: MP, MA e LS, tendo o AA como opcional porm fortemente recomendado.
MP e MA
Principais funes do MP:
11 Realizao de medies de rede.

11 Publicao dos dados de medies.
11 Gerenciamento do servio.
Principais funes do MA:
11 Armazenar dados de medies de rede.
11 Buscar e fornecer esses dados.
11 Permitir o gerenciamento do servio.
Measurement Point Service (MP)
o produtor efetivo dos dados (medies ativas ou passivas). Formalmente, esse servio
no armazena ou transforma os dados. Entre suas principais tarefas, se enquadram:
11 Realizao de medies de rede;
11 Publicao dos dados de medies;
11 Gerenciamento do servio.
Diferentes tipos de funcionalidades de medio podem ser implementadas:
11 Atraso unidirecional ou bidirecional, perdas, e jitter;
11 Medies baseadas em fluxos;
11 Vazo alcanvel atravs de medio ativa de stress.
Measurement Archive Service (MA)
usado para armazenar e publicar dados histricos. Esse servio essencial na anlise de
tendncias e responsvel em garantir alta disponibilidade dos dados. As suas principais
11 Armazenar dados de medies de rede;

11 Buscar e fornecer esses dados;
Nota-se que para diferentes tipos de dados existem melhores formas de armazenamento,
podendo-se adequar melhor a diferentes tipos de banco de dados. Com isso, diferentes MAs
podem ser implementados: RRD, BD Relacional, BD XML, entre outros.
LS e AS
Principais funes do LS:
11 Manter as informaes sobre a infraestrutura atual existente.
11 Manter informaes sobre os recursos de cada servio e publicar para os demais
servios.
11 Permite que os servios sejam visveis a arquitetura.
Principais funes do AS:
11 Autenticar clientes e servios.
atribuies so:
263
11 Manipular informaes de atributos de identidades especficas.
11 Gerenciar relaes de confiana em confederao com outros ASs.

Lookup Service (LS)
Esse o servio que realiza a descoberta de outros servios. Sua atribuio principal registrar e manter atualizado as informaes sobre a infraestrutura do perfSONAR. Essencialmente age como um diretrio de servios. Entre as principais atribuies, encontram-se:
11 Manter as informaes sobre a infraestrutura atual existente;
11 Manter informaes sobre os recursos de cada servio e publicar para os demais servios;
11 Permite que os servios sejam visveis a arquitetura.
parte essencial da arquitetura permitir a descentralizao dos servios. Deve dar informaes
suficientes para que o usurio saiba se um determinado servio atende a sua necessidade.
Authentication Service (AS)
O Authentication Service (AS) o servio de autenticao. um servio opcional na arquitetura do perfSONAR, porm muito recomendado, especialmente por garantir a autenticidade das transaes, entre os servios.
As necessidades definidas no GFD so:
11 Suportar clientes com mltiplas identidades;
11 Suporte de autenticao por papis;
11 Formao de comunidades confederadas que aceitem autenticaes umas das outras;
11 Detalhes de confederao devem ser escondidos de outros servios dentro de um
domnio administrativo.
As tarefas que deve atender so:
11 Autenticar clientes e servios;
11 Manipular informaes de atributos de identidades especficas;
11 Gerenciar relaes de confiana em confederao com outros AS;
RP, TS e TopS
Principais funes do RP:
11 Mediar o consumo de recursos limitados.
264
Principais funes do TS:

11 Utilizado para agregao, correlao, filtragem e traduo das informaes geradas
pelo perfSONAR.
Principais funes do TopS:
11 Prover informaes topolgicas sobre as redes disponveis ao arcabouo perfSONAR.
Resource Protector (RP)

Esse servio usado para mediar o consumo de recursos limitados. Possui um componente
de agendamento para tratar o consumo de recursos dependentes de tempo. Cada MP
administra seus recursos localmente com um gerenciador de recursos interno, e esse gerenciador pode ser configurado para contatar um MP dependendo dos recursos necessrios
para uma medio.
Transformation Service (TS)
O Transformation Service o servio de transformao. utilizado para fazer o pipelining
dos dados, entre os outros servios do arcabouo. Pode ser usado para realizar qualquer
tipo de operao sobre os dados. Fica entre os geradores e os consumidores dos dados.
Existem muitas funes em potencial, entre elas:
11 Agregao;
11 Correlao;
11 Filtragem;
11 Traduo.
As operaes de transformao podem ser realizadas com dados de diversos produtores.
Um exemplo especfico de transformao o Servio de Topologia.
Topology Service (TopS)
O Servio de Topologia (TopS) responsvel em prover informaes topolgicas sobre as
redes disponveis ao arcabouo perfSONAR. um servio que transforma as informaes
coletadas de diversos MPs em informao de topologia atravs de algoritmos definidos.
As informaes que esse servio prov pode refletir mltiplas camadas de rede. Entender a
topologia essencial para o sistema de medio otimizar as operaes.
11 Atravs das premissas mnimas identificadas pelo GFD, foi escolhida a Arquitetura
Orientada a Servio (SOA) para o desenvolvimento do perfSONAR.

11 Usam-se tecnologias XML.
11 Implementa-se o SOA atravs de Servios web.
11 O arcabouo de servios definido por trs camadas bem definidas:
22 Cliente.
22 Servios.
22 Ferramentas.
A arquitetura do pacote de software dividida em trs camadas:
11 Camada de cliente: essa a camada dos clientes, as quais se encontram as ferramentas
de visualizao e anlise dos usurios;
11 Camada de servios: essa a camada dos servios que compe a infraestrutura dos
servios definidos pelo GFD;
11 Camada de ferramentas: na camada de ferramentas se encontram os programas responsveis em realizar as medies de fato, que so controladas pelos servios.
Definio da arquitetura/tecnologia
265
User visualisation Client
Network
Monitoring
Web Services
perfSONAR
Web Services
Local Measurement
Points and Database
AB: Available Bandwidth
Network
Monitoring
Web Services
Network
Monitoring
Web Services
AB
OWD
PL
OWD
PL
AB
OWD
PL
DV
Domain A
Domain B
Domain C
PL: Packet Loss
OWD: One-Way-Delay
Interao multidomnio
11 implcito a questo de se possuir mltiplos domnios, pois a infraestrutura
Start/Stop
Archive
Discovery
AA
Transformation
DV: Delay Variation
baseada em servios.
Figura 8.24
Definio da
arquitetura/
tecnologia.
11 A interao multidomnio se d atravs dos servios de localizao, para descobrir os

componentes pertencentes infraestratura perfSONAR e/ou atravs das ferramentas
dos clientes diretamente.
Figura 8.25
Interao
Multidomnio.
AA A
Cliente
LS A
266
MA A
AA B
LS B
MA B
No perfSONAR h implcita a questo de se possuir mltiplos domnios. Como a infraestrutura baseada em servios, a interao multidomnio se d atravs dos servios de
localizao, para descobrir os componentes pertencentes infraestratura perfSONAR e/ou
atravs das ferramentas dos clientes diretamente.
Servios implementados na RNP

11 Os componentes do perfSONAR implantados na RNP so: MP, MA, LS e AS.
11 Ferramentas de visualizao:
22 CACTISonar: para usurios administradores de rede que tenham necessidade de
realizar testes regulares agendados.
22 ICE: para usurios finais que desejem realizar testes sob demanda.
Os componentes perfSONAR implantados na malha de medio da RNP so:
11 MPs: o servio definido para gerenciar os testes, realizando agendamentos e testes sob
demanda, o Command Line MP (CLMP);
11 MAs: para realizar o armazenamento dos testes utilizado o SQL-MA, com o intuito de
armazenar dados histricos e o RRD-MA, que guarda informaes das medies utilizando arquivos RRD;
11 LS: o servio de descoberta implantando o gLS (escopo global) e hLS (escopo local);
11 AS: o servio de autenticao (AS) fornecido pelo perfSONAR foi implantado.
As ferramentas de visualizao usadas pela RNP so o CACTISonar, para usurios administradores de rede que tenham necessidade de realizar testes regulares agendados, e o ICE,
ferramenta para usurios finais que desejem realizar testes sob demanda.
267
268
9
Aprender a definir requisitos de gerncia; Conhecer o Sistema de Registro de
Problemas (Trouble Ticket System); Montar uma soluo de gerncia.
conceitos
Requisitos de gerncia; Sistema de Registro de Problemas (Trouble Ticket System);

Soluo de gerncia.
Introduo
11 Definindo seus requisitos de gerncia.
22 Identificando o seu estado atual.

22 Avaliando opes de plataformas de gerncia.
11 Sistema de Registro de Problemas (Trouble Ticket System).
11 Montando uma soluo de gerncia.
22 Fully Automated Nagios (FAN).
Como visto em captulos anteriores, existem sistemas com grau de integrao bastante
varivel que permitem a operao correta de atividades de uma empresa atravs de suas
vrias reas. Ou ento existe a opo de vrias plataformas de gerncia com uma integrao
razovel. Cabe ao administrador da rede definir junto com seus pares e superiores qual o
nvel de integrao e qual o nvel de gerncia esperada para a sua rede.
Em redes que contemplam um nvel de gerncia razovel, o sistema de gerenciamento de
rede e servios costuma encontrar-se alinhado com o funcionamento interno da prpria
empresa, refletindo com a maior proximidade possvel os processos internos da rea de TI.
Para isso, deve haver adequao de sistemas de gerenciamento de rede, at porque a informao tcnica de gerenciamento tem grande impacto no negcio da empresa.
Em vrios casos, essas mesmas reas esto envolvidas:
11 Atendimento ao cliente: call center e help desk;
11 Network Operation Center (NOC);
11 Equipes de engenharia de redes, sistemas e P&D;
Captulo 9 - Montagem em laboratrio de soluo de gerncia
objetivos
Montagem em laboratrio de
soluo de gerncia
269
11 Equipes de manuteno (eletricidade, ar-condicionado, fibras ticas etc.);

11 Controle de qualidade do servio (administrao de contratos de TI);
11 Vendedores, responsveis por contas de clientes.
Cada uma dessas reas utiliza as informaes coletadas pelos sistemas de gerncia como
uma forma de coordenar suas atividades e obter informaes sobre cada um dos sistemas
que possui responsabilidade.
Entre as atividades esperadas pela gerncia da rede, pode-se citar:
11 Registro de pedidos e reclamaes de servios;

11 Atendimento e manuteno (agendados ou no);
11 Acompanhamento e registro da soluo;
11 Gerao de relatrios de SLA (Service Level Agreement).
O processo de autoconhecimento da situao atual da gerncia da sua rede o ponto de
partida em qualquer das situaes, seguida da definio do escopo da gerncia desejvel
para a sua rede. Um exerccio simples para diagnosticar o seu nvel atual de gerncia sugerido nas atividades desta sesso.
Implementando Gerenciamento
11 Identificar:
22 Restries e necessidades servios.

22 Recursos de rede, desenhar a topologia da rede.
11 Determinar etapas (abrangncia e recursos).
11 Poltica de gerncia:
22 Indicadores de SLA.
22 Funes e executores.
11 Definio de produtos de gerenciamento:
22 Requisitos do produto e do fornecedor.
22 Definio de roteiro de avaliao e seleo.
11 Implementao.
O passo seguinte ao autoconhecimento da sua rede a definio de at aonde voc pretende
chegar com o desenvolvimento da gerncia da sua rede. Essa questo, na maioria das vezes,
envolve as esferas administrativas da empresa, j que o nvel de integrao e gerncia dese-
jvel diretamente proporcional aos recursos humanos e financeiros destinados a esse fim.
270
necessrio um planejamento dos processos e servios que se deseja gerenciar dentro

da empresa. Esse planejamento ter como resultado um projeto de implementao, que
define as etapas, equipes e acompanhamento adequado, pois vai alterar vrios processos
internos junto a diversas reas da empresa novamente, diretamente relacionado ao grau
de gerncia definido anteriormente.
Uma maneira simples de realizar esse planejamento o uso do modelo FCAPS como ponto de
partida, agrupando as necessidades de gerenciamento dentro de suas cinco reas: falha, configurao, contabilizao, desempenho e segurana. Dessa forma so divididas as tarefas das
equipes, e cada um dos executores responsveis por cada etapa do projeto de implementao.
Outro ponto que tambm deve ser definido nesse momento o SLA. O nvel de servio tem
impacto direto na escolha de equipamentos, softwares e fornecedores de servios a serem
utilizados pela empresa, tendo impacto direto na soluo de NMS a ser utilizada.
O passo seguinte a escolha dos produtos a serem utilizados na soluo de gerenciamento,
de forma a contemplar todos os requisitos listados (incluindo aqui o financeiro). importante
definir o modelo de distribuio das aplicaes, baseado nas caractersticas do ambiente a
ser gerenciado, como a possibilidade de criar diferentes domnios de gerenciamento, comuns
em redes maiores. Tpicos como protocolos a serem usados e a modelagem da informao
de gerenciamento, com base no modelo adotado, tambm sero importantes.
Em muitos casos, ser concebido um Network Operations Center (NOC): uma infraestrutura
centralizada de apoio atividade de gerncia, composta de recursos de rede (sistemas e
humanos) para uma melhor resposta da atividade de gerenciamento.
Pode ser necessrio o desenvolvimento de novas aplicaes de gerenciamento que atendam
s necessidades locais. Muitas vezes so customizaes ou scripts; em outras, sistemas
inteiros complementam o conjunto de aplicaes. O NMS a ser definido est diretamente
relacionado a esses itens.
Outros tpicos no menos importantes so o planejamento do suporte e do treinamento
da equipe.
Instalao e configurao dos produtos de gerenciamento:
11 Identificao e contratao dos executores;

11 Preparao da infraestrutura;
11 Treinamento da equipe.
Avaliao de Plataformas de Gerenciamento

11 Fornecedor: localizao, suporte, parcerias e integrao.
11 Arquiteturas de protocolos suportados.

11 Plataformas de hardware e SO suportadas.
11 Interface com programas aplicativos.

11 Integrao com outras plataformas.
11 Documentao.
Conforme visto nas sesses anteriores, pontos como integrao e modelo de gerncia a ser
utilizados so cruciais nessa definio. A maior integrao de facilidades de modelagem de
processos geralmente so caractersticas difceis de obter em plataformas gratuitas.
Normalmente a ferramenta est diretamente relacionada ao conhecimento e disponibilidade de recursos humanos para a sua integrao, ou ento aquisio de uma plataforma
comercial com suporte do prprio fornecedor.
No caso de um NMS comercial, alm do custo inicial, deve-se lembrar da necessidade de
um contrato de suporte para que se tenham as atualizaes necessrias do produto uma
plataforma com trs anos sem atualizao costumeiramente se torna obsoleta configurao de novos servios e equipamentos. No caso de um NMS freeware/open source, existe
sempre o risco de o desenvolvimento ser descontinuado, ento o tempo de vida que essa
11 Suporte a um ou mais padres de gerncia.
plataforma j possui e a regularidade das suas atualizaes deve ser levada em conta.
271
O que avaliar em uma soluo de gerncia:
11 Viso grfica dos elementos gerenciados;

11 Relacionamentos entre elementos de rede;
11 Modelos adotados (agente-gerentes, objetos distribudos etc.);
11 Visualizao de notificaes de eventos e alarmes; graus de severidade para os
eventos reportados;
11 Logs de eventos;
11 MIB Browser;
11 Utilizao de SGBD padro;
11 Importao e exportao de informaes da MIB;
11 Software livre: provedores de servios disponveis;
11 Interface com outros programas aplicativos;
11 APIs para desenvolvimento de aplicaes de gerenciamento; linguagens oferecidas;
Integrated Development Environment (IDE); ferramentas;
11 Facilidade de operao e curva de aprendizagem da ferramenta;
11 Integrao entre as diversas gerncias FCAPS e sistemas de ticket.
Trouble Ticket Systemas (TTS)

Registra chamados de problemas que estejam ocorrendo. Informaes constantes
em um TTS:
11 Hora e data do incio do problema.
11 Operador que est abrindo o registro.
11 Descrio e seriedade do problema.
11 Equipamentos envolvidos e seus detalhes.
11 Destinatrio (e responsvel) do registro.
11 Prxima ao e recomendaes de ao baseada em ocorrncias semelhantes.
Depois:
11 Hora e data da resoluo.
11 Descrio da soluo.
11 Outros.
A utilizao de um Sistema de Registro de Problema (Trouble Ticket System) auxilia o NOC
272
no diagnstico do problema e permite criar um Banco de Dados (BD) de experincias com

problemas, viabilizando o uso de sistemas especialistas na soluo. Muitos desses sistemas
identifica j na abertura do problema possveis solues baseadas no sistema em questo e
nas palavras chaves que descrevem questo a ser resolvida.
Os TTSs tambm agilizam o processo de controle da rede, porque permitem comunicao
direta com os responsveis pelo NOC [RFC 1297], seja pela abertura de muitos chamados
semelhantes, seja pelo repasse direto de informaes entre a fila de problemas do service
desk diretamente para a equipe do NOC.
Funes e caractersticas de um Sistema TTS

O Registro de Problema (o cadastro que realizado a cada novo registro no sistema TTS)
deve prover um histrico completo do problema de forma que qualquer operador possa
tomar alguma iniciativa sem que para isso tenha de consultar outro operador:
11 Deve permitir um melhor escalonamento de problemas atribuindo prioridades a estes.
Os supervisores e operadores podero tomar decises acerca da necessidade ou no de
mais pessoal pela carga corrente do Centro de Operaes de Rede. Seria interessante
permitir que a prioridade dos registros mudasse de acordo com a hora do dia ou em
resposta a alarmes de tempo;
11 Se o TTS for suficientemente integrado ao sistema de e-mail, ento alguns registros
podem ser despachados diretamente aos responsveis;
11 Deve-se atribuir um timeout para cada registro de problema. Caso o problema no seja
resolvido em tempo, automaticamente acionado um alarme. A fim de se evitar postergao indefinida, pode-se adotar um escalonamento baseado no tempo de espera, no
tipo de rede e na severidade do problema;
11 Caso a empresa opere em mais de um Centro de Operaes de Rede, devem-se canalizar
os registros ao grupo de engenheiros, operadores ou representantes de clientes responsveis por aquela rede de onde provem o registro de problema;
11 Os sistemas de ticket normalmente fornecem mecanismos para a obteno de estatsticas,
tais como: Tempo Mdio entre Falhas (MTBF Mean Time Between Failure), Tempo
Mdio de Conserto (MTBR Mean Time Between Repair) e Tempo Mdio para Falhas
(MTTF Mean Time ToFailure). Uma coleta e anlise apropriadas de tais estatsticas permitem que se tomem medidas preventivas a eventuais falhas em dispositivos do sistema;
11 Do ponto de vista de gesto de equipes, os TTSs permitem que se obtenham tambm
informaes sobre o tempo mdio de resoluo de problemas por equipe ou indivduo da
equipe, obtendo tambm informaes da sua produtividade.
Uma opo no uso de TTS adotada em vrias instituies a permisso de abertura direta
de chamados ao usurio final, diminuindo a burocracia na soluo de problemas e permitindo linha direta entre o usurio e quem mantm os servios dentro da empresa. Alguns
a resoluo dos problemas mais comuns encontrados pelo usurio, ou simplesmente a
comunicao de problemas j conhecidos e em tratamento, evitando que o usurio registre
como um novo problema algo que j se encontra em tratamento.
Algumas opes em FS/OSS so:
11 Request Tracker (RT): sistema utilizado por vrias organizaes para rastreamento
de bugs, chamados de help desk, atendimento ao cliente, documentao de workflow,
gerenciamento de mudanas e operaes de rede. um software bastante maduro e
com atualizaes constantes desde a sua primeira verso. (http://bestpractical.com/rt);
11 OTRS: sistema de gerenciamento para uma ampla gama de processos de negcios.
Baseado em um conjunto de funes construdas sobre um ticket (problem report), o
OTRS permite o suporte tanto de TI como de qualquer outro departamento da empresa
que preste servios aos usurios (http://otrs.org/);
11 Ocomon: projeto nacional criado em 2002, atualmente possui mdulos para cadastro,
acompanhamento, controle, consulta de ocorrncias de suporte, alm de um mdulo de
TTSs possuem integrados a eles sistemas de pergunta-resposta, como um wiki que exprime
inventrio no automatizado. Em 2004, foram adicionadas caractersticas de gerenciamento de SLAs (http://ocomonphp.sourceforge.net/);

273
11 Simpleticket: sistema de controle de tickets, possui funcionalidades como: informaes

bsicas sobre o cliente; criao de ticket; rastreamento da vida do ticket (aberto, fechado, em
anlise etc.); notificaes por e-mail sobre status do ticket; etc. (http://simpleticket.net/);
11 Liberum: fornece uma maneira simples e fcil de usar a interface web para gerenciar e
controlar os problemas de suporte tcnico, sendo necessrio para seu funcionamento
um servidor Windows configurado com o Internet Information Service (IIS). Seu foco
para pequenas empresas (http://www.liberum.org/).
Algumas opes comerciais:
11 BMC Remedy: possivelmente o mais completo sistema de TTS existente no mercado.
Entre seus pontos fortes est a integrao com as melhores plataformas de NMS comerciais (http://www.bmc.com/remedy/).
11 Frontrange Heat Service Management: oferece uma soluo bastante completa
para gerncia de servios, permitindo controlar requisies de usurios e definir um
workflow para as requisies recebidas, conforme previsto pelo modelo ITIL
(http://www.frontrange.com/heat/products/service-management).
Fan (Fully Automated Nagios)

11 O principal objetivo dessa distribuio fornecer uma instalao customizada da
soluo Nagios, incluindo a maioria das ferramentas/plugins fornecidos pela Comunidade Nagios.
11 As principais ferramentas integradas so:
22 Nagios: aplicativo de monitoramento central.
22 Nagios plugins: plugins para monitorar diferentes tipos de equipamentos/servios.
22 Centreon: interface web para o Nagios.
22 NagVis: permite a criao de mapas para visualizar o sistema de monitoramento
(geogrfica, funcional, pelos servios ...).
22 NDOUtils: armazena os dados do Nagios em um banco de dados MySQL.
22 NRPE: torna possvel monitorar os servidores Windows (o daemon NRPE no
fornecido).
22 NaReTo (Nagios Reporting Tools): ferramenta de gerao de relatrio de disponibilidade.
FAN significa Fully Automated Nagios (Nagios Totalmente Automatizado). O principal objetivo dessa distribuio fornecer uma instalao customizada da soluo Nagios, incluindo
a maioria das ferramentas/plugins fornecidos pela Comunidade Nagios.
O FAN fornece uma imagem ISO baseado no CentOS. Todos os pacotes do CentOS perma-
274
necem disponveis, de modo que voc pode manter todas as vantagens do CentOS, alm de
possuir todas as ferramentas Nagios j instaladas e configuradas para voc.
As ferramentas integradas:
11 Nagios: aplicativo de monitoramento central;
11 Nagios plugins: plugins para monitorar diferentes tipos de equipamentos/servios;
11 Centreon: interface web para o Nagios;
11 NagVis: permite a criao de mapas para visualizar o sistema de monitoramento
(geogrfica, funcional e pelos servios);
11 NDOUtils: armazena os dados do Nagios em um banco de dados MySQL;
11 NRPE: torna possvel monitorar os servidores Windows (o daemon NRPE no fornecido);

11 NaReTo (Nagios Reporting Tools): ferramenta de gerao de relatrio de disponibilidade.
NagVis
Nagios
NaReTo
Centreon
Nagios
Conhecido como Netsaint, um aplicativo desenvolvido com o objetivo de realizar o
monitoramento de ativos de uma rede. Basicamente dividido em trs partes:

1. Uma engine central que agenda a realizao de tarefas de monitoramento.
2. Uma interface web, o que d uma viso geral do sistema de informao e as possveis
anomalias.
3. Um conjunto de plug-ins que podem ser configurados de acordo com as necessidades do
administrador da rede.
Principais caractersticas:
11 Monitoramento de servios de rede (SMTP, POP3, HTTP, NNTP, ICMP e SNMP).
11 Monitoramento de recursos de computadores ou equipamentos de rede (carga do
processador, uso de disco, logs do sistema).
11 Monitorao remota suportada atravs de tneis encriptados SSH ou SSL.
11 Desenvolvimento simples de plugins (fcil customizao). Os plug-ins podem ser
desenvolvidos em diferentes linguagens de programao: shell script (bash, ksh ...),
C, Perl, Python, Ruby, PHP, C # etc.
11 Checagem paralelizada.
Capacidade de definir a rede hierarquicamente.
11 Capacidade de notificar quando um servio ou equipamento apresenta problemas e
quando o problema resolvido (via e-mail, pager, SMS ou qualquer outro meio definido pelo usurio por plugin).
11 Capacidade de definir tratadores de eventos.
11 Rotao automtica de log.
11 Excelente interface web para visualizao do status atual da rede, notificaes, histrico de problemas, arquivos de log etc.
11 Cada teste retorna um estado especial:
1. OK (tudo bem).
2. WARNING (o limiar de alerta foi ultrapassado).
3. CRITICAL (o servio tem um problema).
Figura 9.1
Ferramentas
integradas
ao Nagios.
4. UNKNOWN ( impossvel saber o estado do servio).

275
Nagios (anteriormente conhecido como Netsaint), um aplicativo GPL (General Public

License) desenvolvido com o objetivo de realizar o monitoramento de ativos de uma rede.
Ele monitora os hosts e servios, e informa sobre o estado do sistema. Foi desenvolvido de
forma modular, dividido em trs partes:
1. Uma engine central, que agenda a realizao de tarefas de monitoramento;
2. Uma interface web, o que d uma viso geral do sistema de informao e as possveis
anomalias;
3. Um conjunto de plug-ins que podem ser administrador da rede para o monitoramento
de cada servio ou recurso disponvel em todos os computadores ou dispositivos de rede
do Sistema de Informao. Graas ao sistema de plug-ins, o Nagios pode ser expandido
existindo vrios com essas extenses para o software.
acts
Service
tgro
ou
ps
Service Group
rio
pe
k_
ec
rio
_pe
hos
contact_groups
nam
e
m
up_
na
st_
ho
gr
ch
ion
ion_
peri
chec
ac
od
k_pe
riod
Time Period
up
ro
t_g
Figura 9.2
Objetos disponveis
no Nagios e seus
relacionamentos.
hostgroups
ice
cat
cat
nt
Host Group
noti
co
Parents
rv
ti
ts
ac
nt
co
Host
se
no
Contact
cont
Contact Group
Objetos disponveis no Nagios e seus relacionamentos
A figura anterior representa os principais objetos disponveis no Nagios e como estes esto
associados entre si. Como pode ser observador, o fundamento central de um sistema de
gerncia de falhas identificar problemas nos servios da rede. Portanto, as primeiras definies para a implantao desse tipo de sistema identificar quais sero os servios (Service) e
dispositivos (hosts) monitorados, e quem ser avisado em caso de falhas (contact).
Plugins do Nagios
276
Uma das muitas vantagens do Nagios a sua excelente API para criao de plugins.
Entre os principais plug-ins, destacamos:
11 Nagios::Plug-in::SNMP (./check_snmp_procs, ./check_snmp_loads etc.).
11 HTTP Scraping Plug-ins (./check_http).
11 Testing Telnet/SSH-like Interfaces (./check_port).
11 Monitoring LDAP (./check_ldap_replication.pl)
11 Monitoring Databases (./check_mysql, ./check_postgres etc.).
Saiba mais
O Nagios possui formas
interessantes de agrupamento de Servio
(Service Group), Contatos (Contact Group)
e dispositivos (Host
Group), que permitem
customizar e facilitar
o desenho da soluo
como um todo.
Uma das muitas vantagens do Nagios a sua excelente API para criao de plugins. A API de
plugins do Nagios aberta, fcil de usar e bem documentada. Voc pode desenvolver seus
plugins em qualquer linguagem que voc queira, permitindo monitorar tudo o que voc
considerar importante. Principais plug-ins:
11 Nagios::Plug-in::SNMP (./check_snmp_procs, ./check_snmp_loads, etc.): permite o
monitoramento, via SNMP, de informaes como: uso de CPU, utilizao de swap, uso de
memria RAM e uso de partio de disco, entre outros;
11 HTTP Scraping Plug-ins (./check_http): define cdigos de erro, realiza testes com robs
e monitora atividades referente ao protocolo HTTPe linguagem HTML;
11 Testing Telnet/SSH-like Interfaces (./check_port): verifica se os servios Telnet e SSH
esto ativos e disponveis na mquina alvo. Esse plugin pode, tambm, ser utilizado para
verificar se uma determinada porta TCP est aberta na mquina alvo;
11 Monitoring LDAP (./check_ldap_replication.pl): permite avaliar a replicao, integrao
e escalabilidade de servidores LDAP;
11 Monitoring Databases (./check_mysql, ./check_postgres etc.): conecta a um banco de
dados SGBP e realiza um comando SQL com o objetivo de medir o desempenho e resposta.
Como monitorar roteadores e swtichs utilizando os plugins do Nagios

Dispositivos de rede gerenciveis oferecem grande variedade de informaes atravs de
SNMP, por isso, pode ser difcil decidir o que importante para monitorar.
Para os exemplos a seguir, vamos assumir que:
11 Todos os dispositivos gerenciados so do fabricante CISCO;
11 A verso do protocolo SNMP a 2;
11 A string referente comunidade pblica est armazenada na varivel snmp_community.
Objetivo
MIBs necessrias
OIDs necessrios
Exemplo de comando
Utilizao
de CPU
CISCO-PROCESS-MIB
CISCO-PROCESS-MIB
/check_snmp_cisco_cpu.pl --hostname rtr1.

example.com --snmp-version 2c -rocommunity mycommunity -w 90 -c 95
ENTITY-MIB
cpmCPUTotal5secRev:
1.3.6.1.4.1.9.9.109.1.1.1.1.6
cpmCPUTotal1minRev:
1.3.6.1.4.1.9.9.109.1.1.1.1.7
cpmCPUTotal5minRev:
1.3.6.1.4.1.9.9.109.1.1.1.1.8
cpmCPUTotalPhysicalIndex:
1.3.6.1.4.1.9.9.109.1.1.1.1.2
ENTITY-MIB
entPhysicalName:
1.3.6.1.2.1.47.1.1.1.1.7
Utilizao
de memria
CISCO-MEMORY-POOL-MIB
ciscoMemoryPoolName:
1.3.6.1.4.1.9.9.48.1.1.1.2
ciscoMemoryPoolUsed:
1.3.6.1.4.1.9.9.48.1.1.1.5
ciscoMemoryPoolFree:
1.3.6.1.4.1.9.9.48.1.1.1.6
./check_snmp_cisco_mem_pool.pl -hostname rtr1.example.com --snmp-version

2c --rocommunity mycommunity -w 90 -c 95
Tabela 9.1
Exemplos de
monitoramento
no Nagios.
277
Objetivo
MIBs necessrias
OIDs necessrios
Exemplo de comando
Controle de
temperatura
ENTITY-MIB
ENTITY-MIB:
CISCO-ENTITY-SENSOR-MIB
entPhysicalDescr:
1.3.6.1.2.1.47.1.1.1.1.2
./check_snmp_cisco_temp.pl -hostname 192.168.3.1 --snmp-version

2c --rocommunity mycommunity
--warning 30 --critical 36 --snmp-max-msg-size 50000 --sensor-regex inlet
CISCO-ENTITY-SENSOR-MIB
entSensorType:
1.3.6.1.4.1.9.9.91.1.1.1.1.1
entSensorScale:
1.3.6.1.4.1.9.9.91.1.1.1.1.2
entSensorValue:
1.3.6.1.4.1.9.9.91.1.1.1.1.4
entSensorStatus:
1.3.6.1.4.1.9.9.91.1.1.1.1.5
Utilizao
de banda
IF-MIB
IF-MIB
ETHERLIKE-MIB
ifDescr: 1.3.6.1.2.1.2.2.1.2
ifSpeed: 1.3.6.1.2.1.2.2.1.5
ifOperStatus: 1.3.6.1.2.1.2.2.1.8
ifInOctets: 1.3.6.1.2.1.2.2.1.10
ifOutOctets: 1.3.6.1.2.1.2.2.1.16
ETHERLIKE-MIB:
./check_snmp_if_bw_util.pl --snmp-version 2c --hostname rtr1.example.

com --rocommunity mycommunity
--warning in_util,gt,90:out_util,gt,90
--critical
in_util,gt,98:out_util,gt,98 --interface
FastEthernet0/1 --sleep-time 5 --max-speed 100m
dot3StatsIndex:1.3.6.1.2.1.10.7.2.1.1
dot3StatsDuplexStatus:
1.3.6.1.2.1.10.7.2.1.19
Utilizao
de CPU
UCD-SNMP-MIB
Raw user ticks:

.1.3.6.1.4.1.2021.11.50.0
./check_net_snmp_cpu.pl --hostname
host.example.com --snmp-version 3
Raw nice ticks:

.1.3.6.1.4.1.2021.11.51.0
--auth-username user --auth-password password --auth-protocol

md5 -c user,gt,80:system,gt,80 -w
idle,gte,10
Raw system ticks:

.1.3.6.1.4.1.2021.11.52.0
Raw idle ticks:
.1.3.6.1.4.1.2021.11.53.0
Raw wait ticks:
.1.3.6.1.4.1.2021.11.54.0
Raw kernel ticks:
.1.3.6.1.4.1.2021.11.55.0
Raw interrupt ticks:

.1.3.6.1.4.1.2021.11.56.0
278
Objetivo
MIBs necessrias
OIDs necessrios
Exemplo de comando
Uso de partio
HOST-RESOURCES-MIB
hrFSMountPoint:
1.3.6.1.2.1.25.3.8.1.2
/check_snmp_hr_storage.pl --hostname 192.168.3.1 --snmp-version

3 auth-username my_user --auth-password my_pass -w 90 -c 95 -U %
-P all
hrFSIndex: 1.3.6.1.2.1.25.3.8.1.1
hrFSStorageIndex:
1.3.6.1.2.1.25.3.8.1.7 -> link to hrStorageEntry for this device
hrFSType: 1.3.6.1.2.1.25.3.8.1.4 ->
FS type from hrFSTypes
HR FS Types: 1.3.6.1.2.1.25.3.9
hrStorageDescr:
.1.3.6.1.2.1.25.2.3.1.3.1
hrStorageAllocationUnits:
1.3.6.1.2.1.25.2.3.1.4
hrStorageSize: 1.3.6.1.2.1.25.2.3.1.5
hrStorageUsed:
1.3.6.1.2.1.25.2.3.1.6
hrStorageAllocationFailures:
1.3.6.1.2.1.25.2.3.1.7
hrStorageType: 1.3.6.1.2.1.25.2.1
type of storage device; e.g., (hrStorageFixed
Disk, hrStorageRemovableDisk)
Device Type
Index:.1.3.6.1.2.1.25.3.2.1.2
Carga
UCD-SNMP-MIB
1-minute load average:

.1.3.6.1.4.1.2021.10.1.3.1
5-minute load average:
.1.3.6.1.4.1.2021.10.1.3.2
./check_net_snmp_load.pl -H
hostname --snmp-version 3 --auth-username joesmith --auth-password
mypassword -w 20:15:10 -c 40:30:20
Nmero de
processos
por status
HOST-RESOURCES MIB
hrSWRunName:
1.3.6.1.2.1.25.4.2.1.2
hrSWRunPath: 1.3.6.1.2.1.25.4.2.1.4
hrSWRunParameters:
1.3.6.1.2.1.25.4.2.1.5
hrSWRunStatus:
1.3.6.1.2.1.25.4.2.1.7
./check_snmp_procs.pl --hostname
host1.example.com --snmp-version
3 auth-username myuser --auth-password mypass --auth-protocol
md5 ./check_snmp_procs.pl mode
count --match /bin/httpd:apache
--match mysqld.+basedir:mysql
--critical apache,lt,1:apache,gt,150:my
sql,lt,1: mysql,gt,20 --snmp-max-msg-size 50000
ou
Para saber mais,

acesse o site oficial
do Nagios: http://www.
nagios.org/. E conhea
seus plug-ins: http://
nagiosplug.sourceforge.net/
./check_snmp_procs.pl --hostname
host1.example.com --snmp-version 3
auth-username myuser --auth-password mypass --auth-protocol md5 ./
check_snmp_procs.pl --mode state
--match mysqld.+basedir:mysql
--warning runnable,gt,30 --critical
total,gt,100 --snmp-max-msg-size
50000
15 minute load average:

.1.3.6.1.4.1.2021.10.1.3.3
279
Centreon
11 Tem como objetivo fornecer uma interface amigvel, o que torna possvel para um
grande nmero de usurios (incluindo pessoas no tcnicas) ver o estado do sistema,

especialmente com grficos.
11 Suas principais caractersticas so:
22 Interface intuitiva e customizvel multiusurio.
22 Gesto de todos os arquivos de configurao do Nagios (cgi, nagios.cfg ...).
22 Configurao do mdulo de carga do Nagios.
22 Compatibilidade com Nagios 1.x, 2.x Nagios e Nagios 3.x.
22 A verificao da validade de configurao com o depurador Nagios.
22 Configurao de servidor de rede/hardware arquivos utilizando arquivos de identificao, que incluem todas as informaes bsicas sobre esses tipos de recursos.
22 Representaes grficas avanadas e personalizvel.
22 Gesto dos direitos de acesso, incluindo os recursos, bem como pginas de interface.
22 Modular.
22 Um relatrio de incidente completo.
22 Um sistema de clculo em tempo real para avaliar a qualidade do servio, que
notifica o utilizador sempre que diminui a qualidade do servio.
22 Um mapa em Java, que oferece uma verso simplificada do estado do sistema de
informao (de propriedade da Companhia Merethis).
Centreon um software de monitoramento de rede com base na ferramenta open source
Nagios, tendo como objetivo fornecer uma interface amigvel que torna possvel para um
grande nmero de usurios (incluindo pessoas no-tcnicas) ver o estado do sistema, especialmente com grficos.
Em julho de 2007, o software Oron mudou de nome para se tornar Centreon.
Nareto e NagVis
11 Nareto: utiliza as informaes Nagios para fornecer vises de alto nvel para dife-
rentes grupos de usurios.

11 NagVis: mdulo de visualizao que torna possvel a criao de pontos de vista fun-
cionais de monitoramento. NagVis pode usar como plano de fundo um diagrama da
280
rede, permitindo ao Nagios atualizar o diagrama em tempo real.

O Nagios Reporting Tools (NaReTo) utiliza as informaes Nagios para fornecer vises de
alto nvel para diferentes grupos de usurios. possvel criar uma rvore de navegao com
NaReTo: mediante a atribuio de direitos especficos para alguns ns da rvore, permitindo
restringir a viso. Trs tipos de visualizao esto disponveis atualmente: em tempo real,
relatrios, Histria e Acompanhamento dos alertas.
NagVis o mdulo de visualizao. Ele torna possvel a criao de pontos de vista funcionais
de monitoramento. NagVis pode utilizar como plano de fundo um diagrama da rede, permitindo ao Nagios atualizar o diagrama em tempo real.
XCC
RZ_Hagen / ESXFarm-1
ESX1F1
ESX2F1
XCC1
ESX3F1
SSN / DMZ
ESX2
Firewall
SSN
LAN
VMFS Volumes
DIS / Standard
60229627:VMFS_Data_1
ESX3
ESX6
ESX5
ESX7
058100_1_1000:VMFS_Data_2
ESX8
40023627:VMFS_Data_3
Management
60023627:VMFS_OS_1
70223627:VMFS_OS_2
DIS3
Figura 9.3
NagVis.
OK
Warning
Critical
Unknows
Acknowfedgs
Primeiras configuraes
Antes da primeira linha de comando, importante definir com preciso os requisitos.
As seguintes perguntas devem ser feitas:

11 Quais dispositivos sero monitorados?
11 Quais servios sero monitorados?
11 Quem vai receber os e-mails ou comunicados de alerta?
11 Quem vai usar essa plataforma e modific-la?
No existe um mtodo de milagre, mas os conselhos a seguir podem ser teis:
11 Faa uma lista de todos os dispositivos a serem monitorados (nome e endereo IP).
11 Identifique os servios crticos e associe-os aos dispositivos.
11 Defina uma poltica de comunicao de alerta (definio de contatos e grupos
de contato).
11 Crie um diagrama de rede que especifique a dependncia entre os dispositivos.
Integrao Nagios com OpenLdap

11 O Nagios no possui integrao com o OpenLDAP.
11 A nica forma de utilizarmos um usurio do LDAP para gerenciar o servidor Nagios
configurar o servidor Apache para autenticar no servidor LDAP.
Legenda:
60123627:VMFS_Snaoshots
VCONTROL
281
O Nagios no possui integrao com o OpenLDAP. A nica forma de utilizarmos um usurio

do LDAP para gerenciar o servidor Nagios configurar o servidor Apache para autenticar no
servidor LDAP. Para tal, torna-se necessrio instalar no servidor Apache o mdulo de autenticao LDAP (mod_authnz_ldap) e configurar, no diretrio do Nagios, o arquivo .htaccess
seo <Location> o mdulo mod_authnz_ldap.
No Nagios ser necessrio desativar qualquer mecanismo de autenticao, garantindo o
acesso de qualquer objeto para qualquer usurio. A figura a seguir representa como seria
esse processo de autenticao.
End_User
Apache
mod_authnz_ldap
LDAP
Nagios
GET/nagios/status.cgi
.htaccess le or
httpd.conf <location>
section
Search LDAP for user
User found,
password matches
Request passes to status.cgi,
user in REMOTE_USER variable
Integrao Nagios com Splunk

11 Splunk um produto comercial que atua como uma espcie de Google para os
registros gerados pelo Nagios. O Nagios nos permite monitorar qualquer dispositivo
ou servio, enquanto o Splunk nos permite pesquisar praticamente qualquer formato
de arquivo ou produo textual.
11 Aps instalar o Splunk, para integrao, modifique o arquivo de configurao do
Nagios (cgi.cfg), modificando as seguintes opes:
enable_splunk_integration=1
splunk_url=http://splunk.localhost.net:8000/
Splunk um produto comercial que atua como uma espcie de Google para os registros
gerados pelo Nagios. O Nagios nos permite monitorar qualquer dispositivo ou servio,
282
enquanto o Splunk nos permite pesquisar praticamente qualquer formato de arquivo ou

produo textual.
Aps instalar o Splunk, para integrao, modifique o arquivo de configurao do Nagios
(cgi.cfg), modificando as seguintes opes:
enable_splunk_integration=1
splunk_url=http://splunk.localhost.net:8000/
Figura 9.4
Nagios e LDAP.
Integrao Nagios com o Cacti

11 Quando integrado com o Nagios, MySQL e SNMPTT, o Cacti pode ser usado para criar
vrios relatrios de acompanhamento de tendncias e grficos.

11 Uma das dificuldades de integrao Cacti e Nagios a autenticao. A utilizao do
mdulo mod_authnz_ldap do Apache vai trazer os mesmos problemas j citados.
11 Outra forma de integrar os dois programas o uso do Cacinda add-on
(http://cacinda.sf.net/).
Cacti (www.cacti.net) uma aplicao open source que utiliza a ferramenta de dados
round-robin (RRD Tool) para criar grficos de desempenho e disponibilidade. Quando integrado com o Nagios, MySQL e SNMPTT, o Cacti pode ser usado para criar vrios relatrios de
acompanhamento de tendncias e grficos.
Uma das dificuldades de integrao Cacti e Nagios a autenticao. O Cacti suporta autenticao LDAP, enquanto a autenticao do Nagios no suporta tal mecanismo de autenticao.
A utilizao do mdulo mod_authnz_ldap do Apache vai trazer os mesmos problemas j citados.
Outra forma de integrar os dois programas o uso do Cacinda add-on (http://cacinda.sf.net/).
O Cacinda um programa feito em PHP, que permite que voc configure painis para
dispositivos em sua rede por tipo de dispositivo e, em seguida, exiba informaes a partir
desses dispositivos no Nagios. Ele acessa diretamente o banco de dados do Cacti e permite
a autenticao em ambos os sistemas (Cacti/Nagios).
Integrao Nagios com Puppet

11 O Puppet (http://www.reductivelabs.com/projects/puppet) um software open source
utilizado para automatizao das atividades de administrao e gerenciamento.

11 O Puppet e o Nagios formam uma boa equipe. Puppet ajuda a automatizar muitos tipos
de tarefas de administrao do sistema, enquanto o Nagios, por outro lado, muito
bom em fornecer uma viso de fora para dentro de aplicaes, sistemas e redes.
O Puppet (http://www.reductivelabs.com/projects/puppet) um software open source
utilizado para automatizao das atividades de administrao e gerenciamento. As polticas
semelhante ao Ruby. Cada servidor da rede executa um agente Puppet, que recupera a
sua configurao e a envia para o servidor central Puppet. Uma vez que um agente tem
uma configurao vlida, ele vai periodicamente aplicar as polticas e regras que recebe do
servidor central no sistema gerenciado e pode tambm enviar os resultados dessa aplicao
para o servidor central de forma a produzir relatrios.
O Puppet e o Nagios formam uma boa equipe. Puppet ajuda a automatizar muitos tipos
de tarefas de administrao do sistema enquanto o Nagios, por outro lado, muito bom
em fornecer uma viso de fora para dentro de aplicaes, sistemas e redes. Um arranjo
tpico seria o Nagios produzindo relatrios de status de um servio em um host gerenciado,
enquanto o Puppet executa as tarefas de administrao de sistemas, que normalmente
seriam feitas com interveno humana (figura a seguir).
do sistema so configuradas usando uma linguagem declarativa de configurao muito
283
Nagios
Puppet
Agent does the following:
Can manage critical services
on a host
Sends reports to server after every
periodic run; Reports show what
policies were checked and what
changed between runs.
Can watch critical les and replace
them with clean server copies if
they change.
Performs system management and
administration jobs; jobs can be
scheduled like cron jobs or can be
triggered by changes in the system.
Puppet server sends

conguration associated
with agent to managed
system when agent checks
in with the server.
Host, Service, and

application checks
Submit to Nagios
as passive checks
SNMPTT
SNMP Traps
SNMP
Agent
Puppet
Agent
Figura 9.5
Puppet e Nagios.
Managed Device
Integrao Nagios com TTS

11 Uma funcionalidade interessante permitir que o Nagios crie, automaticamente,
tickets de problemas em seu sistema de chamados.

11 A nica recomendao que essa funcionalidade deve ser avaliada com cuidado, com
o objetivo de evitar falsos positivos.
Uma funcionalidade interessante permitir que o Nagios crie, automaticamente, tickets de
problemas em seu sistema de chamados. A nica recomendao que essa funcionalidade
deve ser avaliada com cuidado, com o objetivo de evitar falsos positivos.
O Nagios possui um grande nmero de macros que permite que os scripts possam reunir
informaes sobre o host, servios etc. As macros podem ser empregadas por manipuladores de eventos e executar scripts para envio de e-mail, de SMS ou inserir um chamado no
seu sistema de trouble ticketing, por exemplo.
Nagios
284
Managed Device
Host Event Handler
Trouble Ticketing System
Executes host check_command|

No response -host down!
Call event handler
Open trouble ticket
Figura 9.6
Integrao Nagios
com TTS.
10
objetivos
Tpicos avanados em gerenciamento

Entender o gerenciamento de rede no contexto ISO/OSI e TCP/IP. Conhecer a gerncia
da Internet do Futuro. Conhecer as novas abordagens em gerenciamento.
Entender os Sistemas Especialistas.
gerenciamento. Sistemas especialistas. Gerenciamento de capacidade.
conceitos
A Internet das Coisas. Gerenciando a Internet do Futuro. Novas abordagens em
Os dois principais arcabouos sobre os quais foram construdas as solues de gerncia

de redes, o modelo baseado na arquitetura ISO/OSI e o modelo baseado na arquitetura da
internet (TCP/IP), evoluram de forma bem diferente.
O modelo de gerncia baseado no modelo ISO/OSI, que usava o protocolo de aplicao
Common Management Information Protocol (CMIP), apoiado pela arquitetura ISO/OSI, e
todas as camadas nela previstas, como mostra a figura 10.1, no prosperou e foi sendo
gradativamente abandonado pelo mercado, mesmo tendo sido o oficialmente o adotado
pelo International Telecommunication Unit (ITU) para uso no mbito das administraes de
telecomunicaes. A complexidade do software para implementar essa soluo, o excesso
de overhead nos protocolos utilizados, bem como o custo dos produtos disponveis no
mercado, foram elementos decisivos para o abandono das solues de gerncia de rede
CMIP
SNMP
Aplicao
Apresentao
Sesso
Figura 10.1
Gerenciamento de
rede no contexto
ISO/OSI e TCP/IP.
Aplicao
TELNET, FTP,
SMTP, DNS
Transporte
TCP/UDP
Rede
IP
Enlace
Fsica
Enlace e fsica
CSMA/CD
HDLC, PPP
ISO/OSI
TCP/IP
Captulo 10 - Tpicos avanados em gerenciamento
baseadas nesse modelo.
285
Por outro lado, a soluo de gerncia de rede baseada na arquitetura TCP/IP e que tinha no
prprio nome do protocolo de gerncia, Simple Network Management Protocol (SNMP) a
ideia de uma soluo simples e leve, teve continuidade e foi disseminada amplamente. Atualmente, pode-se afirmar que a arquitetura SNMP de gerenciamento um padro de fato,
apesar de a arquitetura OSI de gerenciamento oferecer uma estrutura mais robusta que
SNMP, permitindo a execuo de tarefas mais sofisticadas.
Apesar da disseminao da soluo de gerncia de rede, so bem conhecidas as limitaes do
protocolo SNMP, especialmente em suas verses iniciais, que no usam mecanismos fortes de
segurana para proteo contra acesso no autorizado. Como os dados de controle de acesso
(community name) so transmitidos sem criptografia nas verses SNMP v1 e v2, seu uso tem
sido limitado a funes de monitorao. Gerenciamento de configurao tem sido realizado
mediante o uso de solues envolvendo acesso direto aos recursos da rede (com SSH) e alguma
linguagem de comando (CLI Command Line Interface) especfica de famlias de produtos
produzidos por fornecedores. Diversas solues e estratgias de evoluo foram propostas
para a internet em si e para a gerncia da futura internet. Tais solues tm sido classificadas
como evolutivas ou clean state. No primeiro grupo temos solues que consideram a rede
atualmente existente e as propostas indicam adaptaes nos protocolos para atender s novas
necessidades de redes com maior velocidade, mobilidade e heterogeneidade de dispositivos.
O grupo clean state mais radical e prope uma arquitetura totalmente nova para a internet
e solues de gerncia que separam a parte de comando da parte de dados.
As novas solues tm sido demandadas especialmente porque o contexto de gerncia
de rede est sendo ampliado muito em relao ao que inicialmente estava previsto, que
inclua apenas roteadores e equipamentos de rede de modo geral, e informaes bsicas
sobre os servidores e computadores conectados internet. Atualmente, a quantidade de
equipamentos que comea a ser interligada est crescendo. A proliferao de dispositivos
interconectveis em rede, com baixo custo e tamanho cada vez menor, levou ampliao
no espectro de solues para servios de Tecnologia de Informao (TI) bem diferenciados
daquelas que foram usadas nos primrdios da computao e das redes.
Estimativas do Silicom Labs (2014) indicam que em 2015 mais pessoas vo acessar a internet a
partir de dispositivos mveis do que de computadores convencionais. Em 2015, 14 bilhes de
dispositivos e aparelhos estaro conectados internet mvel, incluindo no apenas dispositivos do tipo smartphone e tablet, mas tambm mquinas de lavar, carros e roupas, que sero
conectados. A figura 10.2 salienta essa tendncia de reduo no custo dos dispositivos interligados internet em funo de miniaturizao de componentes, o que enseja um crescimento
em seu uso, bem como ampliao na quantidade e variedade de equipamentos interligados.
A operao e gesto da internet considerando o contexto da Internet das Coisas vai ser uma
tarefa importante na operao do backbone da rede. Para migrar para a Internet das Coisas
286
a partir dos ambientes atuais, a tarefa de integrar esse novo conjunto mais heterognea de
dispositivos complexo, mas importante. Nesse tipo de rede, a qualidade da comunicao
entre objetos ou coisas precisa contemplar novas solues e ser melhorada.
Custo
Miniaturizao
4 Smart things
3
Mobiles / Smart Cards
PCs
2
Mainframe
1
Tempo
Figura 10.2
Evoluo dos
equipamentos
interligados
internet.
A gerncia de rede precisa contemplar solues para atender as necessidades de gerenciamento tambm da Internet das Coisas, pois esse segmento parte integrante da Internet do
Futuro. A rede para a Internet das Coisas pode ser definida como uma infraestrutura de rede
global dinmica baseada em protocolos de comunicao padro, com recursos de autoconfigurveis e interoperveis onde
coisas fsicas e virtuais tm identidades, atributos fsicos,

personalidades virtuais e usam interfaces inteligentes estando perfeitamente integrados na
rede de informao. As caractersticas diferenciadas desses dispositivos demanda um
atendimento diferenciado da rede para que eles possam ser atendidos, a despeitos das
limitaes que os caracterizam e que sero analisadas a seguir.
A Internet das Coisas

O termo Internet das Coisas comeou a ser usado por volta de 2000 pela comunidade de
RFID
desenvolvimento de RFID, e referia possibilidade de descobrir informao sobre objetos
Identificao por
radiofrequncia ou
RFID (Radio-Frequency
IDentification)
um mtodo de identificao automtica
atravs de sinais de
rdio, recuperando e
armazenando dados
remotamente atravs
de dispositivos denominados etiquetas RFID.
vasculhando um endereo na internet que corresponderia a um particular RFID (SRI 2014).

A partir desse incio, mais limitado, a expresso Internet das Coisas, tambm conhecida
objetos do dia a dia que podem ser lidos, reconhecidos, localizados, endereados e/ou
controlados via internet, seja por RFID, rede local sem fio, rede de longa distncia ou outros
meios. Os objetos do dia a dia incluem no apenas dispositivos eletrnicos e nem tampouco
apenas produtos de mais alto desenvolvimento tecnolgico, tais como veculos e equipamentos, mas considera coisas nas quais no se pensaria em termos de serem dispositivos
eletrnicos, tais como:
11 Alimento, vesturio e abrigo;
11 Materiais, partes e montagens;
11 Bens e itens de conforto;
11 Limites de locais e monumentos;
11 Toda a miscelnea de itens de comrcio e cultura.
pela sigla IoT (Internet of Things), passou a se referir ideia geral de coisas, especialmente
287
Tecnologia
Fuso de agentes de software

e sensores avanados
Miniaturizao,
eletrnica eciente
(em potncia)
e espectro disponvel
habilidade de
recepo de sinais
de geolocalizao
por dispositivos em
ambientes internos
Reduo de custo
levando segunda
onda de aplicaes
Demandas para
agilizar logstica
Web e
mundo fsico
Localizao de pessoas
e objetos comuns
Vigilncia, segurana, sade,

transporte, controle alimentao,
gerenciamento documentos
Etiquetas RFID para facilitar

encaminhamento, acompanhamento
e preveno de perda
Teleoperao e telepresena:
monitorar e controlar objetos
Posicionamento
onipresente
Aplicao de mercado
verticalizadas
Auxlio na cadeia
de suprimento
Tempo
A figura 10.3 mostra a evoluo do uso da Internet das Coisas no escopo de servios de TI
com tecnologias cada vez mais baseadas em dispositivos de pequeno porte e software
altamente sofisticado. Um exemplo de novas aplicaes a derivada da wearable computing. Uma tendncia atual de uso de novos tipos de equipamentos que as pessoas usam
est sendo designada como Bring Your Own Wearables (BYOW) traz para o contexto das
empresas tecnologia de vestir, tais como monitores de aptido fsica e sade, relgios
inteligentes ligados a telefones celulares, alm de culos com funcionalidades avanadas de
captura e exibio de dados, tal como o Google Glass. Isso vai demandar das empresas uma
reavaliao das polticas existentes para acomodar esses novos dispositivos, tendo em vista
potenciais ameaas segurana, por exemplo.
Na viso do Internet Engineering Task Force (IETF), o novo paradigma inerente Internet
das Coisas implica em muitas vises por parte de um rgo de padronizao. Usualmente,
o IETF concentra seus esforos da definio de novos objetos com funes de comunicao,
sensoriamento e ao que possam interoperar via IP (Lee 2013). Mas embora sensores
sejam baseados em IP ou dispositivos com restries (memria e recursos de CPU muito
limitados) possam usar protocolos de camada de aplicao para fazer o monitoramento e

gesto de recursos simples, solues adaptadas que contemplem essas limitaes precisam
ser delineadas (Ersue 2014). O IETF est investigando uma nova estrutura de arquitetura
para suportar escalabilidade e interoperabilidade para a Internet das Coisas. As metas para
alcanar esse objetivo envolvem identificar vrios problemas nos protocolos existentes e
encontrar possveis solues para resolver esses problemas. Uma lista de possveis problemas apresentada a seguir:
11 Aspectos gerais: a Internet das Coisas tem como caracterstica inerente uma quantidade
de dispositivos pelo menos uma ordem de grandeza maior do que a internet atual, no
opera com pessoas diretamente comandando seu funcionamento, possui mobilidade
inerente, opera em modo desconectado e sem superviso direta;
288
Figura 10.3
Evoluo de uso da
Internet das Coisas.
11 Aplicaes: cada dispositivo pode ser usado por mltiplas aplicaes e servios, com
diferentes caractersticas;
11 Rede: necessria uma tecnologia de comunicao comum que suporte todas as aplicaes
ou servios, bem como equipamentos heterogneos;
11 Aspecto de camada de enlace: h vrios tipos de interface de rede com cobertura e
velocidade diferenciados. Esses ambientes tm caractersticas de operao para baixo
consumo de energia e redes com perda, tais como Bluetooth ou IEEE 802.15.4;
11 Aspectos dos objetos inteligentes: os objetos inteligentes interconectados so heterogneos e tm tamanho, mobilidade, potncia, conectividade e protocolos diferentes. Podem
operar tambm em modo federado com sensores e atuadores interagindo diretamente em
escala residencial ou em escopo mais amplo, tais como no contexto de cidades inteligentes.
Os dispositivos da Internet das Coisas so tipicamente dispositivos de uso especfico, com
CPU, memria e recursos de energia limitados. Esses dispositivos limitados (sensores, objetos
inteligentes ou dispositivos inteligentes) podem ser conectados a uma rede. Essa rede dos
dispositivos limitados pode ser em si limitada ou prejudicada por canais no confiveis ou
com perdas, tecnologias sem fio com largura de banda limitada e uma topologia dinmica,
necessitando o servio de um gateway ou proxy para se conectar internet tal como exemplificado na figura 10.4. Em outras situaes, os dispositivos limitados podem ser conectados
a uma rede no limitada usando pilhas de protocolos normais. Dispositivos limitados podem
ser responsveis pela coleta de informaes em diversas situaes, incluindo os ecossistemas
naturais, edifcios e fbricas, e enviar as informaes para um ou mais servidores.
Imager
PAR
sensor
Figura 10.4
Sensores em
ecossistemas.
Air temperature
windspeed,
humidity sensors
Microclimate
station
Air CO2
sensor
Minirhizotron
Soil moisture, soil CO2, and temperature
Nitrate sensor
A gerncia da rede caracterizada por monitorar o status da rede, deteco de falhas e

inferir as suas causas. Envolve a definio de parmetros de rede e contempla realizar aes
para eliminar falhas, manter a operao normal, melhorar a eficincia da rede e desempenho
do aplicativo. A aplicao tradicional de gerenciamento de rede recolhe periodicamente as
informaes a partir de um conjunto de elementos que so necessrios para gerenciar,
processar os dados e apresenta resultados aos usurios de gerenciamento de rede. Dispositivos limitados, no entanto, muitas vezes tm poder limitado, faixa de transmisso baixa
e podem no ser confiveis. Eles tambm podem precisar operar em ambientes hostis com
requisitos de segurana avanadas ou podem necessitar serem usados em ambientes
Infrared
and net
radiation
sensors
agressivos por um longo tempo sem superviso.

289
Devido a essas limitaes, a gesto de uma rede com dispositivos restritos oferece
vrios tipos de desafios em comparao com a gesto de uma rede IP tradicional.
Alm dos requisitos de gesto impostas pelos diferentes casos de uso, as tecnologias de
acesso usadas por
dispositivos limitados pode impor restries e exigncias sobre o sistema

de gerenciamento de rede e protocolo passveis de uso.
possvel que algumas redes de dispositivos limitados possam utilizar tecnologias de acesso
no restritas ou tradicionais de acesso rede, como por exemplo, redes de rea local com
plena capacidade. Em tais cenrios, a limitao dos dispositivos apresenta restries especiais de gesto e requisitos em vez da tecnologia de acesso utilizada.
No entanto, em outras situaes, tecnologias de acesso mvel ou limitado podem ser
usadas para acesso rede, ocasionando limitaes nos requisitos de gesto devido s tecnologias de acesso usadas.
Devido a restries de recursos, dispositivos embarcados implantados como sensores e
atuadores em diversos casos usam tecnologias de acesso sem fio de baixa potncia e baixa
velocidade, tais como as solues previstas em diversos padres:
IEEE 802.15.4
Para conectividade da rede. IEEE 802.15.4 um padro que especifica a camada fsica e
efetua o controle de acesso para redes sem fio pessoais de baixas taxas de transmisso.
O padro IEEE 802.15.4 pretende oferecer os fundamentos para as camadas inferiores em
uma rede do tipo de rea pessoal e sem fio (WPAN-Wireless Personal Area Network), que
tem foco no baixo custo, a comunicao de baixa velocidade onipresente entre os dispositivos em contraste com outros, mais o usurio final abordagens orientadas, tais como Wi-Fi.
A estrutura bsica pressupe uma distncia mdia de 10 metros para comunicaes com
uma taxa de transferncia de 250 kbit/s. A figura seguinte ilustra os padres que integram a
definio a soluo IEEE 802.15.4
Camadas superiores
IEEE 802.15.4 LLC
IEEE 802.2 LLC,

Type 1
IEEE 802.15.4 MAC
290
IEEE 802.15.4
868/915 MHz
PHY
Zigbee
802.15.4
IEEE 802.15.4
2400 MHz
PHY
O termo ZigBee designa um conjunto de especificaes para a comunicao sem fio entre dispositivos eletrnicos, com nfase na baixa potncia de operao, na baixa taxa de transmisso
de dados e no baixo custo de implantao. Tal conjunto de especificaes define camadas do
modelo OSI subsequentes quelas estabelecidas pelo padro IEEE 802.15.4 (IEEE 2003).
Foi pensada para inteligar pequenas unidades de coleta de dados e controle recorrendo
a sinais de radiofrequncia no licenciados. A tecnologia utilizada comparvel s redes
Figura 10.5
Padro IEEE
802.15.4.
Wi-Fi e Bluetooth, e diferencia-se dessas por desenvolver menor consumo, por um alcance
reduzido (cerca de 100 metros) e a comunicao entre duas unidades poder ser repetida
sucessivamente pelas unidades existentes na rede at atingir o destino final. Todos os
pontos da rede podem funcionar como retransmissores de informao. Uma malha (Mesh)
de unidades ZigBee pode realizar-se em uma extenso domstica ou industrial sem necessidade de utilizar ligaes elctricas entre elas.
DECT ULE
Digital Enhanced Cordless Telecommunications (DECT) foi definido em 1987 como um
padro para comunicao com telefones sem fio. A ltima verso DECT Ultra Low Energy
(ULE) e popularizou-se como uma tecnologia para automao e segurana nas residncias.
Suas caractersticas incluem baixo custo, baixo consumo de energia, longo alcance (pode
alcanar a casa toda com uma topologia estrela), resistente a interferncias, estvel permitindo transmisso de voz e vdeo.
sensor de
movimento
Tomada
eltrica
Monitor
de bebs
Healthcare
Fumaa
Gateways & Midleware

A automao das residncias pode envolver a interligao de dispositivos tais como:
11 Smart Plugs: proporcionam monitorao inteligente e controle para aparelhos conectados s tomadas de energia;
11 Indicao e alerta de consumo: proporciona ao usurio na casa a indicao do consumo
de energia monitorado;
11 Controle de luz: proporciona ao usurio a possibilidade de controlar a iluminao na
casa com controle remoto;
11 Controle de aparelhos domsticos: proporciona ao usurio a possibilidade de controlar
aparelhos domsticos com controle remoto, incluindo temporizao e desligamento em
perodos de pico, quando o custo da energia maior;
11 Controle ambiental: Termostatos, AVAC (aquecimento, ventilao e ar-condicionado) e
persianas remotamente controlveis.
BT- LE: Bluetooth low energy, Bluetooth LE ou BLE

uma tecnologia de rede de rea pessoal sem fio, desenvolvida e comercializada pelo Grupo
de Interesse Especial Bluetooth, destinado a novas aplicaes nas indstrias de sade, de
aptido, de segurana e de entretenimento domstico. Comparado ao Bluetooth clssico,
BLE se destina a operar com consumo de energia e custo consideravelmente reduzido, mantendo alcance de comunicao similar. Bluetooth LE usa as mesmas frequncias de rdio de
2,4 GHz, como o Bluetooth clssico.
Figura 10.6
Soluo DECT para
automao nas
residncias.
Painel de
controle
291
Na rea da sade, esse padro usado para interligar dispositivos tais como:
11 Dispositivos mdicos de medio de temperatura;
11 Monitores de glicose no sangue;
11 Monitores de presso sangunea;
11 Na rea de esportes e aptido, pode permitir interligar dispositivos como:
11 Medidos de ritmo cardaco;
11 Sensores ligados a bicicletas ou aparelhos de exerccios, para medir cadncia e velocidade;
11 Velocidade e cadncia do perfil de corrida;
11 Perfil e potncia ao pedalar;
11 Perfil de localizao e navegao.
Para sensoriamentos de proximidade, essa tecnologia pode ser usada em dispositivos de:
11 Localizao;
11 Deteco de proximidade.
Figura 10.7
Exemplos de uso
de dispositivos
operando com
BT-LE.
Em todos esses cenrios, importante para o sistema de gerncia de rede estar ciente das
restries impostas por essas tecnologias de acesso, para gerenciar com eficincia esses
dispositivos limitados.
Os dispositivos que utilizam essas tecnologias de acesso podem funcionar atravs de um

gateway que realiza a traduo dessas tecnologias de acesso para protocolos de internet
mais tradicionais, tal como ilustrado na figura 10.6. A abordagem hierrquica para o gerenciamento de dispositivos em tal situao pode ser til, sendo o dispositivo de gateway
encarregado de gerenciar os dispositivos conectados a ele, enquanto que um sistema de
gerncia de nvel mais alto realiza operaes de gesto apenas para o gateway.
Servios baseados em comunicao mquina a mquinas (M2M) tambm esto sendo cada
vez mais usados pelos prestadores de servios mveis, na medida em que vrios dispositivos, eletrodomsticos, medidores de servios pblicos, carros, cmeras de vigilncia de
vdeo e monitores de sade podem ser conectados com tecnologias de banda larga. Diferentes aplicaes, por exemplo, em um aparelho em casa ou na rede do carro, podem usar
292
Bluetooth, Wi-Fi ou Zigbee localmente e se conectar a um mdulo celular agindo como um

gateway entre o ambiente restrito e da rede celular mvel, tal como ilustrado na figura 10.7.
O gateway pode ser responsvel pela filtragem e agregao dos dados recebidos a partir
do dispositivo, uma vez que as informaes enviadas pelo dispositivo podem ser na maior
parte redundantes.
Um gateway pode fornecer diferentes opes para a conectividade de redes mveis e dispositivos com restries:
11 Um telefone inteligente com 3G/4G e WLAN rdio pode usar BT- LE para se conectar com
os dispositivos em uma rede de rea local;
11 Um femtocell (pequenas estaes rdio base ou ERBs, desenvolvidas para operar dentro
de residncias) pode ser combinado com uma funcionalidade de gateway domstico
atuando como estao base celular de baixa potncia, conectando dispositivos inteligentes com o servidor de aplicativos de uma operadora de telefonia mvel.
femtocell
Internet
Roteador
Figura 10.8
Rede usando
tecnologia
femtocell.
A soluo femtocell envolve operao em baixa potncia, nas frequncias utilizadas pelas
operadoras de celular, e a conexo com a rede da operadora feita atravs de conexo
banda larga existente na residncia (ADSL, Cabo etc.).
11 Um mdulo celular incorporado com rdio LTE pode conectar os dispositivos na rede
de um carro com o servidor que est executando o servio de telemtica. LTE sigla de
Long Term Evolution (em portugus, Evoluo a Longo Prazo), cujo significado se refere
um padro de redes celulares que permite banda larga mvel com velocidades de
conexo de at 100 Mbps, possibilitando maior abrangncia de comunicaes de voz e
transferncia de dados.
a uma tecnologia de telefonia mvel tambm conhecida como 4G (quarta gerao). LTE
293
Figura 10.9
Carro com servios
proporcionados
pela tecnologia LTE
(4G).
11 Um gateway M2M ligado rede do operador mvel apoiando diversas tecnologias de

conectividade da Internet das Coisas, incluindo ZigBee e CoAP sobre 6LoWPAN (IPv6 Over
Low Power Wireless Personal Network e o nome do grupo de desenvolvimento da IETF,
ZigBee
que cria e mantm as especificaes para uso do IPv6 nas redes IEEE 802.15.4).
Padro de rede sem

fio para arquitetura em
malha de baixo custo e
baixa potncia, usualmente implementado
em chips com rdios
integrados e microcontroladores com
memria flash entre 60
KB e 256 KB, operando
nas faixas de rdio
industriais, cientficas
e mdicas: 868 MHz
na Europa, 915 MHz
nos EUA e Austrlia, e
2,4 GHz na maioria das
jurisdies em todo o
mundo.
Constrained Application Protocol (CoAP) um protocolo de software destinado a ser

utilizado em dispositivos eletrnicos muito simples e que permite a sua comunicao
de forma interativa atravs da internet. particularmente direcionado para pequenos
sensores de baixa potncia, interruptores, vlvulas e componentes semelhantes, que precisam ser controlados ou supervisionados remotamente, por meio de redes de internet
padro. CoAP um protocolo de camada de aplicao que se destina para uso em dispositivos de internet com recursos limitados, como ns de RSSF. CoAP projetado para
facilitar a traduo para HTTP visando a integrao simplificada com a web e, ao mesmo
tempo, atender aos requisitos especializados, como suporte a multicast, muito baixo em
cima, e simplicidade.
O comum a todos os cenrios descritos que eles so incorporados em um servio e ligados
a uma rede de provedor de servios mveis. Geralmente h uma implantao hierrquica na
topologia e gerenciamento ao invs de serem os dispositivos gerenciados diretamente, pois
a quantidade de dispositivos para gerenciar elevada (por exemplo, muitos milhares). Em
geral, a rede constituda por mltiplos tipos de dispositivos. Como tal, a entidade gestora
tem de estar preparado para gerenciar dispositivos com capacidades diversas, utilizando
diferentes protocolos de comunicao ou de gesto. No caso de os dispositivos que so
conectados diretamente a um gateway, eles provavelmente so geridos por uma entidade
de gesto integrada com o gateway, que em si parte do Sistema de Gerenciamento de
Rede. Telefones inteligentes ou mdulos embarcados conectados a um gateway podem ser
responsveis por gerenciar os dispositivos a eles conectados. A configurao inicial e subse-
294
quente desse tipo de dispositivo utiliza principalmente a autoconfigurao e acionada pelo

prprio dispositivo.
Gerenciando a Internet do Futuro

Um modelo de transporte seguro para o SNMP foi proposto como uma alternativa para os
modelos de segurana existentes no SNMP V1 e V2, baseados em comunidades e para o
modelo de segurana baseado em usurio.
A internet desempenha um papel central na sociedade e em consequncia surgiram muitos
novos servios de trabalho, negcios, educao e entretenimento.
Nos ltimos anos, o equilbrio, a evoluo e as relaes entre os vrios requisitos de rede
mudaram significativamente, criando a necessidade de novos sistemas de rede. Essas
alteraes incluem diferentes novos equipamentos e dispositivos mveis conectados rede
pblica de telecomunicaes, nmero significativo de centros de dados, solues de computao em nuvem e grande nmero de diferentes sensores, atuadores e outras coisas
conectadas na rede, operando com comunicao Machine-to-Machine (M2M) e provendo
servios envolvendo Internet das Coisas.
A comunidade de pesquisa, bem como a indstria, tem dedicado esforo contnuo para
investigar tecnologias e sistemas para as redes futuras. Vrias tecnologias, tais como virtualizao de redes, redes centradas em informao, gerenciamento autonmico e conectividade aberta tem sido consideradas.
Diversas organizaes e grupos se esforam para levar padres para esse novo cenrio.
A International Telecommunication Union Telecommunication Standardization Sector (ITU-T)
iniciou um esforo de padronizao da futura internet visando as redes para o perodo de
2015-2020. O resultado da anlise refletiu na Recomendao ITU-T Y.3001 do ITU (Matsabura
2013). Ela inclui diversas tecnologias candidatas a serem usadas como parte da futura rede,
tais como tecnologia de virtualizao de rede nos moldes das solues Software Defined
Networks (SDN), que j comeam a ser usadas.
No que concerne especificamente ao gerenciamento da futura internet, Festor, Pras e Stilles
(2010) destacaram as seguintes necessidades:
11 Mecanismos de Gesto para a futura internet: embora uma srie de futuras arquiteturas de internet estivessem sendo debatidas, o conjunto de princpios de gesto relacionados no haviam sido abordadas;
11 Falha, Configurao e Operao de Segurana na Internet do Futuro: o design, modelagem e avaliao de algoritmos em trs reas funcionais tm de lidar com sistemas de
larga escala;
11 Gesto autonmica intra e interdomnio na Internet do Futuro: para redes fixas,
o grau de gerenciamento automatizado de QoS interdomnio, a autogesto de redes
pticas usando MPLS, o gerenciamento de falhas automatizado intra e interdomnio, isto
, a recuperao de servio e sua resilincia precisam ser determinados;
11 Gesto de Rede e Servios econmica na internet do Futuro: em apoio a uma aborforma eficiente, necessrio a gerenciamento de rede e servio baseados em consideraes tecnolgicas e econmicas.
Existem diversos problemas no gerenciamento de rede para o contexto da Internet das
Coisas, tal como identificado por Lee (2013):
11 Identificao: os cdigos de identificao usados nos dispositivos so diferentes e derivados de seu uso. Embora o esquema de endereamento do IPv6 possa contemplar, h
a necessidade de esquemas de identificao diferenciados, pois alguns itens, tais como
livros, medicamentos e roupas podem no requerer identificao global alguns objetos
tm existncia temporria e desaparecem aps algum tempo;
dagem tecnicamente vivel de operar uma rede para numerosos servios comerciais, de
295
11 Servios de nomes: servios de suporte a nomes na internet, tal como Domain Name
Services (DNS) so indispensveis para o funcionamento da internet. De modo similar,
so necessrios servios de traduo que convertam nomes apropriados para as
coisas e que podem seguir um esquema de identificao heterogneo de um particular espao de nomeamento em diferentes redes. Essa compatibilizao de esquemas
de nomeamento usados na internet e no contexto da IoC um dos aspectos mais
importantes a serem resolvidos. Esquemas de endereamento Ip e no IP vo precisar
conviver. IPv6 vai ser especialmente necessrio para acomodar a quantidade de dispositivos a serem endereados;
11 Segurana, privacidade, autoridade: a perda de segurana e privacidade na comunicao e servios que tratam com dados pessoais um dos problemas que crescem muito
atualmente. A necessidade de assegurar confiabilidade e sigilo na comunicao colide
com a limitada capacidade de tratar algoritmos mais complexos de autenticao, autorizao e controle de uso (AAA Authentication, Authorization, Accounting);
11 Deteco de presena: refere-se a mecanismos que aceitem, armazenem e distribuam
informao relativa presena e proximidade de pessoas e dispositivos. Como a mobilidade uma caracterstica intrnseca, protocolos que contemplem as mudanas derivadas
da mobilidade so relevantes e necessrios;
11 Descoberta e pesquisa: cada objeto pode ser uma fonte de informao que deve poder
ser armazenada e descoberta para que possa ser usada pelas pessoas;
11 Autonomia: autoconfigurao necessria nesse contexto e os dispositivos devem
poder estabelecer automaticamente os parmetros necessrios para sua conectividade
de forma fcil e automatizada. Os mecanismos de autoconfigurao do IPv6 so teis
nesse sentido. Objetos com recursos limitados podem ter menor capacidade de adaptao e autoconfigurao;
11 Energia: dadas as limitaes de energia dos dispositivos, importante que os mecanismos de comunicao sejam eficientes. Modos ativo e suspenso podem ser usados
alternativamente para economizar energia. Face variedade de volume de trfego
transmitido/recebido, esse tipo de soluo apropriado e necessrio para prolongar a
operao do dispositivo;
11 Servios web: o acesso aos objetos pode ser realizado via web e, nesse sentido, catalogao de objetos e associao com URLs devem ser realizadas.
Novas abordagens em gerenciamento

11 Sistemas especialistas (AI).
11 Objetos distribudos.
296
11 Gerenciamento web-based.
11 Distributed Management Task Force (DMTF).
Tudo indica que SNMP ter um futuro promissor por muito tempo. Apesar disso, a crescente
diversidade de contextos e oramentos busca alternativas para gerenciamento, especialmente
tendo em vista a quantidade de objetos gerenciados que continuamente so definidos.
O uso de SNMP em dispositivos limitados foi analisado por Schenwalder (2013), que demonstrou ser possvel implementar uma pilha SNMP (Contiki-SNMP) em dispositivos limitados.
Essa implementao do SNMP oferece mecanismos bsicos e mesmo mais complexos:
11 Mensagens SNMP com at 484-bytes de comprimento;

11 Operaes Get, GetNext e Set;
11 SNMPv1 e SNMPv3;
11 Modelos de segurana USM (User Security Model do SNMPv3) sem VACM;
11 API para definir e implementar objetos.
Os mdulos de MIB testados foram:
11 SNMPv2-MIB { SNMP entity information
11 IF-MIB { network interface information
11 ENTITY-SENSOR-MIB { temperature sensor readings
Sistemas especialistas
DISMAN Distributed Management
11 Distributed Management Expression MIB (RFC 2982).
11 Event MIB (RFC 2981).

11 Notification Log MIB (RFC 3014).
11 Definitions of Managed Objects for the Delegation of Management Scripts (RFC 3165).
11 Definitions of Managed Objects for Scheduling Management Operations (RFC 3231).
11 Alarm MIB (RFC 3877).
11 Alarm Reporting Control MIB (RFC 3878).
11 Definitions of Managed Objects for Remote Ping, Traceroute and Lookup Operations
(RFC 4560).
O gerenciamento de redes distribudo reconhecido como uma necessidade atualmente.
Uma aplicao gerente uma boa candidata a ser distribuda.
O DISMAN um esforo do IETF para o desenvolvimento de objetos gerenciados padronizados para gerenciamento distribudo. Prev a distribuio das atribuies da aplicao
gerente: funes de gerenciamento. Inicialmente, usar como mecanismo de comunicao o
framework SNMP. Seus objetos sero criados para serem consistentes com SNMP.
notificaes, alarmes, eventos etc.
Gerenciamento web-based
11 HTTP/HTML.
11 CGI.
11 XML.
11 SSL.
11 SOAP.
11 LDAP.
Definir objetos para tratar itens como: agendamento de operaes de gerenciaamento,
297
Aplicaes web em servidores disponibilizariam a informao e as operaes de gerenciamento com o uso de tecnologias presentes na internet.
Entre as vantagens das ferramentas de gerncia baseadas em web, encontram-se:
11 A possibilidade de monitorar e controlar os elementos da rede usando qualquer navegador em qualquer n da rede. Antes, quando falvamos de aplicaes de gerncia
standalone, os gerentes de rede s podiam usar a ferramenta em mquinas onde ela
estivesse instalada e devidamente configurada;
11 A interface grfica da web j bem conhecida, e as operaes realizadas em um navegador tambm, no sendo necessrios gastos com treinamento de pessoal;
11 Usar a web para distribuir as informaes sobre a operao da rede tem se mostrado
uma tarefa eficaz. Por exemplo, em um determinado endereo da intranet poderamos
disponibilizar informaes para os usurios sobre o estado da rede e atualizaes que
precisam ser realizadas. Isso evitaria, entre outras perturbaes, ligaes excessivas ao
help desk;
11 Alm disso, no precisamos usar ferramentas diferentes para gerenciar os diversos elementos da infraestrutura de TI, inclusive os servios.
Web Browser
Element Manager
HTTP
SNMP
SNMP Agent
HTTP Server
Application Specic
HTTP functionality
Application Specic
SNMP functionality
Equipment
Handler
298
Alarm
Handler
Figura 10.10
Gerenciamento
Web-based.
Connection Other
Handler
Subsystems
DMTF Distributed Management Task Force

11 Common Information Model (CIM).
11 Web-Based Enterprise Management (WBEM).

11 Distributed Management Interface (DMI).
11 Directory Enabled Networks (DEN).
Esforo de um consrcio de empresas para criar um padro de gerenciamento desktop.
Evoluiu de gerenciamento de desktops para gerenciamento Web-based dentro de empresas.
Usa como modelo de informao o Common Information Model (CIM), especificao

orientada a objetos para compartilhamento de informaes de gerenciamento, alm de
Managed Object Format (MOF) para descrever objetos. usado tambm por outras iniciativas (modelo unificado).
Outras iniciativas do DMTF:
11 Distributed Management Interface (DMI): ramework para gerenciamento de sistemas
desktop, notebooks, PCs e servidores;
11 Web-Based Enterprise Management (WBEM): iniciativa que usa tecnologias web (browsers, XML, SOAP, WSDL etc.) para gerenciamento de sistemas. Serviu de origem para o
desenvolvimento do CIM. O objetivo principal do WBEM alcanar a gerncia unificada
de todos os sistemas e redes de uma organizao;
11 Directory Enabled Networks (DEN): formatos padro para diretrios interoperveis,
onde administradores podem usar os servios de diretrios para gerenciar servios de
rede (como um diretrio LDAP).
Gerenciamento de capacidade
Gerenciamento de capacidade (capacity planning) o processo de determinao dos
recursos de rede necessrios para evitar um impacto de desempenho ou disponibilidade
sobre aplicaes crticas.
Costuma-se dizer que gerenciamento de performance a prtica de gerenciar tempo de
resposta, consistncia e qualidade da rede para servios, individualmente e de modo global.
Problemas de performance normalmente so relacionados com capacidade. Dois aspectos
envolvem a capacidade de uma rede:
11 O chamado data plane a poro da capacidade gasta efetivamente com os dados no
percurso pela rede. So os dados de usurio;
11 O chamado control plane, por outro lado, a poro relativa aos mecanismos de rede
que a mantm em operao. Pode-se incluir a o trfego adicional gerado por protocolos de gerncia, spanning-tree, protocolos de roteamento, keep alives, alm de CPU,
memria e buffering;
11 Anlise what-if: a forma como as mudanas propostas poderiam alterar o uso da rede;
antes que problemas de capacidade causem piora significativa na performance ou at a

queda do servio. Trata-se de comparar medies de utilizao no decorrer do tempo, de
forma a tornar mais claro o comportamento de indicadores que refletem a resposta da
Figura 10.11
Gerenciamento de
capacidade.
rede. necessria uma grande quantidade de informaes para que isso seja realizado
em uma rede grande.
Obter congurao
e informaes de trfego
Implementar mudanas
Observar estatsticas
Coletar dados de capacidade
Analisar trfego
Resolver problemas
Planejar mudanas
Avaliar
Baselining
de performance
Anlise e-se ?
11 Baselining e anlise de tendncias: permitem que se planeje melhorias em uma rede
299
300
Bibliografia
11 BACKMAN, Dan. Basking in Glory-SNMPv3.
http://www.networkcomputing.com/915/915f1.html
11 BALLEW, Scott. Managing IP Networks. OReilly, 1997.
11 BLUM, Rick. IT Operations Centers (ITOCs),
http://www.ins.com/resources/surveys/ 2008
11 BRISA (Nome de conjunto de 19 autores). Gerenciamento de Redes:
Uma abordagem de sistemas abertos, Makron Book, 1993.
11 CASE, J.; FEDOR, M.; SCHOFFSTALL, M.; DAVIN, J. Simple Network Management
Protocol: RFC 1157. [S.l.]: Internet Engineering Task Force, Network
Working Group, 1990.
11 CISCO. Capacity and Performance Management: Best Practices White
Paper. Cisco Systems. 2009-2010
http://www.cisco.com/image/gif/paws/20769/performwp.pdf
11 CISCO. Change Management: Best Practices White Paper. Cisco Systems. 2008.
http://www.cisco.com/en/US/technologies/collateral/tk869/tk769/white_
paper_c11-458050.pdf
11 CISCO. Network Management System: Best Practices White Paper. Cisco
Systems. 2007.
http://www.cisco.com/image/gif/paws/15114/NMS_bestpractice.pdf
11 CHIU, Dah. SUDAMA, Ram. Network Monitoring Explained. Ellis Horwood
Limited. 1992.
11 CLEMM, Alexander. Network Management Fundamentals.. Cisco Press.
Morgan Kaufman Publishers. 2007.
11 CHAPPEL, Laura. Wireshark Network Analysis. Protocol Analysis
Institute. 2010.
11 COELHO, Josiane et all. How much management is management enough?
Providing Monitoring Processes with Online Adaptation and Learning
Management. New York. 2009.
Bibliografia
Capability. IFIP/IEEE International Symposium on Integrated Network
301
11 COMER, Douglas. Automated Network Management System Current and

Future Capabilities. Prentice-Hall, 2007.
11 FARRIEL, Adrian et all. Network Management Know It All. Morgan Kaufman
Publishers. 2009.
11 FEIT, Sidnie. SNMP A Guide to Network Management. McGraw-Hill, 1995.
11 FIOREZE, T., GRANVILLE, L.Z., ALMEIDA, M.J., TAROUCO, L.R. Comparing
web services with SNMP in a management by delegation environment. In:
IFIP/IEEE INTERNATIONAL SYMPOSIUM, 9, 2005. INTEGRATED NETWORK
MANAGEMENT, IM, 2005, Nice, France.
11 GASPARY, L et all. Charcaterization and Measurement of Enterprise
Network Traffic with RMON2. In ternational Workshop on Distributed
Systems, Operatiions & Management. DSOM. 1999 Zurich, Switerland.
Springer-Verlag.
11 GRANVILLE, Lisandro. Gerenciamento integrado de QoS em redes de computadores. PGCC-UFRGS. 2001.
11 GUNTHER, Neil. The Practical Performance Analyst. Mc GRaw-Holl. 1998.
11 HARNEDY, Sean. Total SNMP. Prentice-Hall, 2 edio, 1998.
11 HARNEDY, Sean. Total SNMP. Prentice-Hall, 2 edio, 1998.
11 HELD, Gilbert. LAN testing and troubleshooting. John Wiley & Sons. 1996.
11 INTERNET2. Performance Initiative.
Disponvel em http://www.internet2.edu/performance/index.html
11 Jakobson, Van ET all. TCPDUMP. Lawrence Berkeley National Labs.
http://ee.lbl.gov/. acessado em novembro de 2012.
11 JOHNSON, D. NOC Integrated Trouble Ticket System: Functional Specification
Wishlist. RFC 1297. IAB 1992.
11 NLANR DAST Iperf. Disponvel em: < http://iperf.sourceforge.net/>
Acesso em: 19 de novembro de 2012.
11 LEINWAND, Allan. CONROY, Karen. Network Management A practical
Perspective. Addison Wesley. 2nd edition. 1996.
11 LOPES, Raquel; SAUV, Jacques; NICOLLETTI, Pedro. Melhores Prticas
para Gerncia de Redes de Computadores. Campus, 2003.
11 MCCANNE, Steven ET all. Packet Capture Library (Libcap). Lawrence
Berkeley National Labs. http://ee.lbl.gov/. acessado em novembro de 2012.
302
11 McCLOGHRIE, K.; PERKINS, D.; SCHOENWAELDER, J.; CASE, J.; ROSE, M.;
WALDBUSSER, S. Structure of Management Information Version 2
(SMIv2): RFC 2578. [S.l.]: Internet Engineering Task Force, Network
11 MELCHIORS. Cristina. TAROUCO, Liane. Fault Management in Computer
Networks Using Case Based Reasoning: DUMBO System. Lecture Notes on
Artiticial Intelligence. Springer-Verlag 1999 p 510-524.
11 MILLER, Mark A. Troubleshooting Internetworks: Tools, Techniques and

Protocols. San Mateo, California: M&T Books, 1991.
11 MILLER, Mark. Managing Internetworks with SNMP. 2nd edition. M & T
Books. 1997.
11 NASSER, Dan. Network Optimization and TroubleShooting: Achieve
Maximum Network Performance. NRP, 1994.
11 NET-SNMP. http://www.net-snmp.org/
11 PERKIN, David. RMON: Remote Monitoring Monitoring of SNMP Managed
LANS. Prentice-Hall. 1999
11 PRAS, A. Network Management Architectures. 1995. Tese (Doutorado)
University Twente, Enschede, Netherlands.
11 PRESUHN, R.; CASE, J.; McCLOGHRIE, K.; ROSE, Marschal.; WALDBUSSER, S.
Management Information Base (MIB) for the Simple Network Management
Protocol (SNMP): RFC 3418, [S.l.]: Internet Engineering Task Force, Network
11 ROSE, Marshal. A Convention for Defining Traps for use with the SNMP: RFC
1215. [S.l.]: Internet Engineering Task Force, Network Working Group, 1991.
11 ROSE, Marschal.; McCLOGHRIE, Keith. Concise MIB Definitions: RFC 1212.
[S.l.]: Internet Engineering Task Force, Network Working Group, 1991.
11 ROSE, Marschal.; McCLOGHRIE, Keith. How to Manage your Network Using
SNMP. Prentice Hall. 1995.
11 SANDERS, Cris. Practical Packet Analysis. 2nd edition. No Starch Press. 2011.
11 SANTOS, Rafael et all. DOS SANTOS, C. R. P. et al. On using mashups for
composing network management applications. IEEE Communications
Magazine, Piscataway, NJ, USA, v.48, p.112122, December 2010.
11 SCHONWALDER, J. et al. Future Internet = content + services + management.
Communications Magazine, IEEE, [S.l.], v.47, n.7, p.27 33, 7 2009.
11 SCHONWALDER, J.; QUITTEK, J.; KAPPLER, C. Building distributed management
applications with the IETF Script MIB. Selected Areas in Communications,
IEEE Journal on, [S.l.], v.18, n.5, p.702714, 2000.
11 Service Level Management: Best Practices White Paper. Cisco Systems.
http://www.cisco.com/en/US/tech/tk869/tk769/tech_white_papers_list.html
11 SNMP White Paper. http://www.snmp.com/snmpv3/v3white.html
11 STALLINGS, William. SNMP, SNMPv2, SNMPv3 and RMON 1 and 2. Addison-Wesley, 3 edio, 1999.
11 STALLINGS, W. SNMP, SNMPv2 and CMIP The practical guide to network
management standards. Reading: Addison-Wesley, 1993.
11 SWISHER, Valerie, HARRIS, David. MARNEY-PETIX, V.C. Mastering Network
11 TANENBAUM, Andrew S. Redes de Computadores. 3 edio. Prentice Hall, 1997.
Bibliografia
Managemetn Self Paced Learning Series. Numidia-Press. 1967.
303
11 TAROUCO, Liane M.R. Inteligncia Artificial Aplicada ao Gerenciamento de

Redes de Computadores. So Paulo: USP-Escola Politcnica, 1990.
11 VERNA, Dinesh. Policy-Based Networking. New Riders. 2001.
304
Mauro Tapajs mestre em Engenharia Eltrica pela

Universidade de Braslia.
Liane Tarouco mestre em Cincias da Computao pela
Universidade Federal do Rio Grande do Sul e doutora em
Engenharia Eltrica/Sistema Digitais pela Universidade de
So Paulo.
Leandro Bertholdo mestre em Cincias da Computao
pela Universidade Federal do Rio Grande do Sul.
Francisco Marcelo Marques Lima Mestre em Engenharia Eltrica pela Universidade de Braslia e Mestre em Liderana pela Universidade de Santo Amaro.
Vanner Vasconcellos especialista em Redes de Computadores pela UFPA.
LIVRO DE APOIO AO CURSO
O curso desenvolve competncias para analisar as necessidades da gerncia de redes, entendendo a estrutura
de uma soluo de gerncia e o suporte adequado a ela.
O conhecimento adquirido sobre as principais ferramentas do mercado permitir ao aluno montar em laboratrio
uma soluo integrada de gerenciamento de redes. Sero
estudados os conceitos bsicos de Gerncia de Redes, as
reas funcionais de gerenciamento (modelo OSI), o modelo ITIL, os protocolos de gerenciamento mais utilizados
na prtica, as MIBs padronizadas, os Sistemas de Gerenciamento de Redes (NMS), ferramentas livres de gerenciamento, Service Level Agreements (SLA), mecanismos de
QoS, as principais plataformas de gerenciamento e as ferramentas de diagnstico e monitorao de redes.

Gerência de Redes de Computadores

Caricato da

Informazioni sul documento

Copyright

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Gerência de Redes de Computadores

Caricato da

Copyright:

Gerncia de

A RNP Rede Nacional de Ensino

Programa Interministerial RNP,

Copyright 2014 Rede Nacional de Ensino e Pesquisa RNP

Escola Superior de Redes

Escola Superior de Redes

Rua Lauro Mller, 116 sala 1103

Gerncia de Redes de Computadores / Mauro Tapajs Santos [et. al.]. 2. ed.

1. Introduo gerncia de redes

2. Ferramentas de inspeo e monitorao de redes

3. SNMPv1, SNMPv2 e SNMPv3

4. Monitoramento remoto RMON, RMON2, SMON e Host MIB

5. Aspectos e aplicaes de plataformas de gerncia

Arquitetura de um sistema de gerncia128

6. Aplicaes e plataformas de gerncia em software livre

7. Tratamento de registros de ocorrncias (logs) e fluxos de dados

8. Gerenciamento de performance e qualidade de servio

Condies de provisionamento de trfego em dispositivos de borda para provedores

9. Montagem em laboratrio de soluo de gerncia

Trouble Ticket Systemas (TTS)272

10. Tpicos avanados em gerenciamento

Escola Superior de Redes

As sesses de aprendizagem onde se do a apresentao dos contedos e a realizao das

Convenes utilizadas neste livro

Necessidades de gerenciamento; reas de gerenciamento;

Captulo 1 - Introduo gerncia de redes

Introduo gerncia de redes

Falta de equipe especializada

Justificar custo/benefcio para a administrao

Custo dos produtos muito alto

Falta de produtos ou ferramentas

Dificuldade de implementar produtos ou ferramentas

Treinamento disponvel inadequado

Produtos e ferramentas disponveis no atendem requisitos

Falta de Acordos de Nvel e Servio (SLA Service Level Agreement)

Rotatividade excessiva do pessoal

Segundo essa pesquisa, os principais servios oferecidos pelo centro de gerenciamento de

Atuao do gerente de redes

Gerncia de Redes de Computadores

inclui, no mnimo, um operador de rede e um administrador de rede.

Normalmente, o operador controlador da rede realiza a contnua monitorao da rede a partir

11 Coleta de dados: processo automtico (ou no) de monitorao dos recursos

Atividades comuns de gerenciamento

Captulo 1 - Introduo gerncia de redes

informaes e no disparo de aes sobre esses equipamentos (testes ou comandos de

Essa situao tende a ocasionar mais dificuldades na determinao de problemas.

11 Estabelecer critrios para o disparo de alarmes;

Network Management System (NMS)

Gerncia de Redes de Computadores

No mbito de redes, vrias so as possibilidades de equipamentos ou itens passveis de

reas funcionais de gerenciamento (modelo OSI)

Captulo 1 - Introduo gerncia de redes

retransmisso dos dados, por exemplo).

Gerncia de Redes de Computadores

11 Comportamento proativo (prefervel) ou reativo.

O gerenciamento de falhas envolve usualmente as seguintes etapas:

11 Avaliar as atividades de comunicao oferecidas na rede;

11 Prov manuteno da estrutura fsica e lgica da rede;

Captulo 1 - Introduo gerncia de redes

11 Identifica componentes em um nvel apropriado e suas relaes (topologia);

11 Cuida dos mecanismos e procedimentos de proteo;

11 Cria, apaga e controla os servios e mecanismos de segurana;

Gerenciamento dentro do modelo OSI

Aplicao de Gerenciamento de Rede

Gerncia de Redes de Computadores

Gerenciamento de Tecnologia de Rede

processos do gerente e do agente.