GERÊNCIA DE REDES DE COMPUTADORES PROGRAMApaginas.unisul.br/carlos.luz/gerencia/gerencia.pdf ·...

Mestrado em Informática Gerência de Redes Página - 1

Gerência de Redes de Computadores

Objetivos GeraisAprender os conceitos, protocolos, ferramentas e técnicas utilizados na gerência de uma rede de computadores. Ao terminar adisciplina, o aluno terá noções não apenas das formas de gerenciar uma rede mas também terá adquirido noções sobre odesenvolvimento de novas soluções de gerência de redes de computadores.

Objetivos Específicos• Entender a necessidade da gerência de redes e as áreas nas quais a gerência de redes pode ser decomposta.• Entender a arquitetura genérica empregada em soluções de gerência de redes de computadores.• Entender a funcionalidade básica dos componentes utilizados na gerência de redes, incluindo plataformas e aplicações

de gerência.• Entender a solução SNMP de gerência de redes, a mais largamente utilizada no mercado, incluindo o modelo de

informação, as MIBs mais importantes e o funcionamento do protocolo SNMP.• Aprender a escrever MIBs proprietárias.• Entender como agentes e gerentes são implementados na arquitetura SNMP, incluindo o desenvolvimento de soluções

finais utilizando Java como linguagem de programação.• Aprender a especificar uma solução de gerência de redes• Aprender as técnicas básicas empregadas na gerência de configuração, de faltas e de desempenho de redes, incluindo

o uso da MIB RMON.• Ser introduzido às alternativas de gerência (CMIP, TMN, DMTF).• Entender o que o futuro poderá reservar para a área de gerência de redes: WBEM, JMAPI

GERÊNCIA DE REDES DE COMPUTADORES

PROGRAMA1.INTRODUÇÃO À GERÊNCIA DE REDES DE COMPUTADORES

1.1 A NECESSIDADE DE GERÊNCIA1.2 O QUE É GERÊNCIA1.3 ARQUITETURA GERAL DE UMA SOLUÇÃO DE GERÊNCIA1.4 DEMONSTRAÇÕES DE SOLUÇÕES DE GERÊNCIA

2. O NÍVEL DE INSTRUMENTAÇÃO: MODELO DE INFORMAÇÃO2.1 PADRÕES NO MUNDO DA GERÊNCIA2.2ARQUITETURA DA SOLUÇÃO SNMP2.3 OBJETOS, INSTÂNCIAS E MIBs2.4 A MIB-22.5 STRUCTURE OF MANAGEMENT INFORMATION (SMIv1)

2.5.1 OBJECT IDENTIFIERS2.5.2 MÓDULOS MIB2.5.3 A ESPECIFICAÇÃO DE UM MÓDULO2.5.4 DEFINIÇÃO DE OBJETOS GERENCIADOS2.5.5 REGRAS PARA A DEFINIÇÃO DE OBJETOS E MIBs2.5.6 DIAGRAMAS CASE2.5.7 TRAPS2.5.8 DICAS PARA CRIAR MIBs PROPRIETÁRIAS

2.6 SMI VERSÃO 23. O NÍVEL DE INSTRUMENTAÇÃO: MODELO OPERACIONAL

3.1 O PROTOCOLO SNMP3.2 OPERAÇÕES GET, GETNEXT, GETBULK3.3 OPERAÇÕES SET, TRAP, INFORM3.4 MAPEAMENTO PARA A CAMADA DE TRANSPORTE3.5 BASIC ENCODING RULES (BER)

4. O NÍVEL DE INSTRUMENTAÇÃO: IMPLEMENTAÇÃO4.1 FONTES DE INFORMAÇÃO E DE CÓDIGO4.2 USO DO PROTOCOLO SNMP EM JAVA: UMA API E UM GERENTE

5. O NÍVEL DE APLICAÇÃO5.1 APLICAÇÕES E PLATAFORMAS DE GERÊNCIA5.2 GERÊNCIA DE CONFIGURAÇÃO5.3 GERÊNCIA DE FALTAS


5.4 GERÊNCIA DE DESEMPENHO5.5 REMOTE MONITORING (RMON)5.6 GERÊNCIA DE HOSPEDEIROS5.7 GERÊNCIA DE APLICAÇÕES

INTRODUÇÃO À GERÊNCIA DE REDES DECOMPUTADORES

A NECESSIDADE DE GERÊNCIA• AS REDES ESTÃO FICANDO CADA VEZ MAIS IMPORTANTES PARA AS EMPRESAS

• NÃO SÃO MAIS INFRA-ESTRUTURA DISPENSÁVEL: SÃO DE MISSÃO CRÍTICA (NÃO PODEMPARAR!)

• AS REDES SÃO CADA VEZ MAIORES• ATINGEM MAIS GENTE NA EMPRESA• ATINGEM MAIS LUGARES FÍSICOS DA EMPRESA• ATINGEM MAIS PARCEIROS DA EMPRESA• ATINGEM ATÉ OS CLIENTES DA EMPRESA

• AS REDES SÃO CADA VEZ MAIS HETEROGÊNEAS• MESCLAGEM DE TECNOLOGIAS• MESCLAGEM DE FORNECEDORES

• AS TECNOLOGIAS SÃO CADA VEZ MAIS COMPLEXAS• EXEMPLO: PARA SUPORTAR SERVIÇOS QUE NÃO SEJAM BEST-EFFORT (VÍDEO

CONFERÊNCIA, ...)• A FALTA DE PESSOAL QUALIFICADO CONTINUA• RESULTADO: PRECISAMOS DE BOAS SOLUÇÕES PARA GERENCIAR AS REDES

• GERÊNCIA = TUDO QUE É NECESSÁRIO PARA MANTER AS REDES FUNCIONANDO BEM

O QUE É GERÊNCIA?• CINCO ÁREAS DA GERÊNCIA (EM ORDEM DE IMPORTÂNCIA)

GERÊNCIA DE CONFIGURAÇÃO• RESPONSÁVEL PELA DESCOBERTA, MANUTENÇÃO E MONITORAÇÃO DE MUDANÇAS À

ESTRUTURA FÍSICA E LÓGICA DA REDE• DEVE-SE LEMBRAR QUE A REDE É MUITO DINÂMICA: HAVERÁ CONSTANTES "MOVES, ADDS AND

CHANGES" (MAC)• FUNÇÕES BÁSICAS:

• COLETA DE INFORMAÇÕES DE CONFIGURAÇÃO• DESCOBRIMENTO DE ELEMENTOS• DESCOBRIMENTO DA INTERCONECTIVIDADE ENTRE ELEMENTOS

• GERAÇÃO DE EVENTOS• EMISSÃO DE EVENTOS QUANDO RECURSOS SÃO ADICIONADOS OU REMOVIDOS• PERMITE MANTER UM INVENTÁRIO ATUALIZADO

• ATRIBUIÇÃO DE VALORES INICIAIS AOS PARÂMETROS DOS ELEMENTOS GERENCIADOS• REGISTRO DE INFORMAÇÕES

• REGISTRO DAS INFORMAÇÕES DE CONFIGURAÇÃO, PERMITINDO A EMISSÃO DERELATÓRIOS

• FEITO A PARTIR DA INFORMAÇÃO COLETADAS NAS 3 FUNÇÕES ANTERIORES• ALTERAÇÃO DE CONFIGURAÇÃO DOS ELEMENTOS GERENCIADOS

• PARA CORRIGIR FALHA OU PROBLEMA DE SEGURANÇA OU REDIMENSIONAR OUMUDAR A ALOCAÇÃO DE RECURSOS PARA MELHORAR O DESEMPENHO

• VÊ-SE PORTANTO QUE HÁ RELAÇÃO ENTRE AS VÁRIAS ÁREAS• INÍCIO E ENCERRAMENTO DE OPERAÇÃO DOS ELEMENTOS GERENCIADOS

GERÊNCIA DE FALTAS• RESPONSÁVEL PELA DETECÇÃO, ISOLAMENTO E CONSERTO DE FALHAS NA REDE• DETECÇÃO DE FALTAS

• MANUTENÇÃO E MONITORAÇÃO DO ESTADO DE CADA UM DOS ELEMENTOSGERENCIADOS

• PERCEPÇÃO DE QUE ESTÁ HAVENDO UM PROBLEMA• ISOLAÇÃO DE FALHAS

• UMA FALTA PODE GERAR UMA FALHA


• USO DE TÉCNICAS PARA DIAGNOSTICAR A LOCALIZAÇÃO E RAZÃO DA FALHA• TÉCNICAS PODEM USAR CORRELAÇÃO DE EVENTOS, TESTES DE DIAGNÓSTICOS, ...

• ANTECIPAÇÃO DE FALHAS• MONITORAÇÃO DE INDICADORES QUE POSSAM PREVER A OCORRÊNCIA DE FALHAS• TAXAS CRESCENTES DE ERRO, ATRASOS DE TRANSMISSÃO• USO DE LIMIARES (THRESHOLD) PARA GERAR ALARMES

• SUPERVISÃO DE ALARMES• INTERFACE DO USUÁRIO INDICA QUAIS ELEMENTOS ESTÃO FUNCIONANDO, QUAIS ESTÃO

FUNCIONANDO PARCIALMENTE E QUAIS ESTÃO FORA DE OPERAÇÃO• INCLUI NÍVEIS DE SEVERIDADE• PODE INDICAR POSSÍVEIS CAUSAS• PODE AVISAR VISUALMENTE, COM EMAIL, PAGER, ...

• AÇÕES NECESSÁRIAS AO RESTABELECIMENTO DOS ELEMENTOS COM PROBLEMAS• AÇÕES PODE SER SUGERIDAS AUTOMATICAMENTE

• TESTES• PARA PERMITIR A VERIFICAÇÃO DO FUNCIONAMENTO DE RECURSOS DA REDE EM

CONDIÇÕES NORMAIS OU ARTIFICIAIS• EXEMPLOS: TESTES DE ECO, DE CONECTIVIDADE

• PROVÊ REGISTRO DE OCORRÊNCIAS E EMISSÃO DE RELATÓRIOS PARA ANÁLISE

GERÊNCIA DE DESEMPENHO• RESPONSÁVEL PELA MONITORAÇÃO DE DESEMPENHO, A ANÁLISE DESSE DESEMPENHO E

PLANEJAMENTO DE CAPACIDADE• SELEÇÃO DE INDICADORES DE DESEMPENHO

• O DESEMPENHO CORRENTE DA REDE DEVE SE BASEAR EM INDICADORES TAIS COMOATRASO, VAZÃO, DISPONIBILIDADE, UTILIZAÇÃO, TAXA DE ERROS, ETC.

• MONITORAÇÃO DE DESEMPENHO• MONITORA OS INDICADORES DE DESEMPENHO• BASELINE (COMPORTAMENTO NORMAL) PODE SER ESTABELECIDO• LIMIARES PODEM SER DEFINIDOS PARA GERAR EVENTOS OU ALARMES• MANTÉM REGISTROS HISTÓRICOS PARA PERMITIR A ANÁLISE E PLANEJAMENTO FUTUROS

• ANÁLISE DE DESEMPENHO E PLANEJAMENTO DE CAPACIDADE• ALTERAÇÃO DO MODO DE OPERAÇÃO

• EXEMPLO: PASSAR DE UM SEGMENTO COMPARTILHADO PARA UMA REDE COMUTADA

GERÊNCIA DE SEGURANÇA• RESPONSÁVEL PELA PROTEÇÃO DOS ELEMENTOS DA REDE, MONITORANDO E DETECTANDO

VIOLAÇÕES DA POLÍTICA DE SEGURANÇA ESTABELECIDA• PREOCUPA-SE COM A PROTEÇÃO DOS ELEMENTOS DA REDE

• DEVE APOIAR A POLÍTICA DE SEGURANÇA DA EMPRESA• CRIAÇÃO E MANUTENÇÃO DE SERVIÇOS DE SEGURANÇA

• PROVÊ MECANISMOS PARA CRIAR, REMOVER E CONTROLAR OS SERVIÇOS DE SEGURANÇA• MONITORAÇÃO DOS SERVIÇOS DE SEGURANÇA

• PODE DISPARAR ALARMES AO DETECTAR VIOLAÇÕES DE SEGURANÇA• MANUTENÇÃO DE LOGS DE SEGURANÇA

• PARA DETECTAR VIOLAÇÕES NÃO ÓBVIAS MANUALMENTE (OU COM PROGRAMAS BATCHAUTOMÁTICOS)

GERÊNCIA DE CONTABILIDADE• RESPONSÁVEL PELA CONTABILIZAÇÃO E VERIFICAÇÃO DE LIMITES DA UTILIZAÇÃO DE

RECURSOS DA REDE, COM A DIVISÃO DE CONTAS FEITA POR USUÁRIOS OU GRUPOS DE USUÁRIOS.• COLETA DE INFORMAÇÕES DE UTILIZAÇÃO

• MONITORA QUAIS RECURSOS E QUANTO DESSES RECURSOS ESTÃO SENDO UTILIZADOSPOR QUE ENTIDADE

• ESTABELECIMENTO DE COTAS DE UTILIZAÇÃO• LIMITES DE USO DE RECURSOS POR USUÁRIO OU GRUPO DE USUÁRIOS

• ESTABELECIMENTO DE ESCALAS DE TARIFAÇÃO• PARA DIVIDIR O CUSTO ENTRE USUÁRIOS OU DEPARTAMENTOS DE UMA EMPRESA• AS INFORMAÇÕES PODEM SER UTILIZADAS APENAS PARA ESTATÍSTICAS

• APLICAÇÃO DAS TARIFAS E FATURAMENTO

ARQUITETURA GERAL DE UMA SOLUÇÃO DE GERÊNCIA


• OS 4 COMPONENTES DA ARQUITERURA DE GERÊNCIA• OS ELEMENTOS GERENCIADOS

• DEVEM POSSUIR UM SOFTWARE ESPECIAL PARA PERMITIR SUA GERÊNCIA• O SOFTWARE CHAMA-SE DE AGENTE

• AS ESTAÇÕES DE GERÊNCIA• NORMALMENTE CENTRALIZADAS PARA FACILITAR A GERÊNCIA• FREQUENTEMENTE SÓ TEM UMA• O SOFTWARE QUE CONVERSA DIRETAMENTE COM OS AGENTES NOS ELEMENTOS

GERENCIADOS É CHAMADO DE GERENTE• POSSUEM FUNÇÕES AUTOMÁTICAS DE GERÊNCIA (EX. POLL REGULAR DOS

AGENTES)• PODE OBTER INFORMAÇÃO DE GERÊNCIA PRESENTE NOS AGENTES• PODEM ALTERAR ESTA INFORMAÇÃO• POSSUEM INTERFACE COM O USUÁRIO PARA FACILITAR A GERÊNCIA• VEREMOS DETALHES LOGO ADIANTE

• PROTOCOLO DE GERÊNCIA• USADO ENTRE GERENTE E AGENTES PARA TROCAR INFORMAÇÃO DE GERÊNCIA• PERMITE OPERAÇÕES DE MONITORAMENTO (READ) E OPERAÇÕES DE CONTROLE

(WRITE)• INFORMAÇÃO DE GERÊNCIA

• DEFINE OS DADOS QUE PODEM SER REFERENCIADOS EM OPERAÇÕES DOPROTOCOLO

• EXEMPLOS: TAXA DE ERRO, STATUS DE UMA LINHA DE COMUNICAÇÃO, ETC.• A VISÃO FÍSICA DA REDE GERENCIADA

• A GERÊNCIA DE REDE NA ARQUITETURA RM-OSI DA ISO


• ESTRUTURA DE UMA ESTAÇÃO DE GERÊNCIA DE REDES• OFERECE UMA VISÃO DA REDE NUM PONTO CENTRALIZADO

NORMALMENTE CONSTRUÍDA COM UMA PLATAFORMA E APLICAÇÕES SOBRE ESTAPLATAFORMA DE GERÊNCIA

• É O "SISTEMA OPERACIONAL" DA GERÊNCIA• OFERECE FUNÇÕES BÁSICAS DE GERÊNCIA (COMUNS A MUITAS APLICAÇÕES)• OFERECE UM AMBIENTE PARA O DESENVOLVIMENTO E A INTEGRAÇÃO DE APLICAÇÕES

SOBRE AS PLATAFORMAS ESTÃO AS DIVERSAS APLICAÇÕES USADAS PELOS OPERADORESA PLATAFORMA DEVE PROVER SERVIÇOS BÁSICOS PARA AS APLICAÇÕES QUE A USAM


• EXEMPLOS DE PLATAFORMAS• OPENVIEW DA HP• SUNNET MANAGER DA SUN MICROSYSTEMS• NETVIEW DA IBM• SPECTRUM DA CABLETRON• CA-UNICENTER DA COMPUTER ASSOCIATES

• PRECISA DE MUITAS APLICAÇÕES PORQUE NÃO HÁ COMO TER UMA ÚNICA APLICAÇÃOZONA DEGERÊNCIA

• A DIFICULDADE DE FAZER APLICAÇÕES SIGNIFICA QUE FORNECEDORES SE ESPECIALIZAM• EXEMPLOS DE APLICAÇÕES DE GERÊNCIA

FUNCIONALIDADE APLICAÇÃO FABRICANTEGERÊNCIA DE DESEMPENHO NETCLARITY LANQUEST

GERÊNCIA DE FALTASSPECTRUM'S ALARMMANAGERS

CABLETRON

MANIPULAÇÃO DE ALARMES TRAP EXPLODER EMPIRE TECHNOLOGIESGERÊNCIA DE SEGURANÇA BOKS SECURIXGERÊNCIA DE BENS ASSETVIEW HPCONFIGURAÇÃO NETBUILDER 3COMCONFIGURAÇÃO CISCO WORKS CISCO

DEMONSTRAÇÕES DE SOLUÇÕES DE GERÊNCIA• GERÊNCIA AD HOC

C:> ping rtbbdsc.campus-ii.ufpb.brDisparando contra rtbbdsc.campus-ii.ufpb.br [150.165.13.61] com 32 bytes de dados:Resposta de 150.165.13.61: bytes=32 tempo=553msResposta de 150.165.13.61: bytes=32 tempo=458msResposta de 150.165.13.61: bytes=32 tempo=512msResposta de 150.165.13.61: bytes=32 tempo=393msEstatísticas do Ping para 150.165.13.61:Pacotes: Enviados=4, Recebidos=4, Perdidos=0 (0%)Tempos aproximados de ida e volta em milissegundos:Mínimo = 393ms, Máximo=553ms, Média=479ms traceroute www.playboy.comRastreando a rota para www.playboy.com [206.251.29.10]com no máximo 30 saltos:

1 145 ms 140 ms 136 ms 200.241.195.282 142 ms 138 ms 136 ms cgnet2.cgnet.com.br [200.241.195.30]3 153 ms 143 ms 147 ms cgnet-S4-4-dist01.rce.embratel.net.br [200.249.241.13]4 220 ms 226 ms 220 ms ebt-A11-0-0-3-dist01.rjo.embratel.net.br [200.244.40.118]5 201 ms 196 ms 190 ms ebt-F5-0-0-core01.rjo.embratel.net.br [200.255.197.33]


6 346 ms 345 ms 346 ms 204.189.136.1377 * 387 ms 366 ms core1-fddi-0.NewYork.cw.net [204.70.2.17]8 365 ms 328 ms 413 ms core1-hssi-3.WestOrange.cw.net [204.70.10.14]9 403 ms 391 ms 430 ms core2.Sacramento.cw.net [204.70.4.49]10 439 ms 523 ms 449 ms border8-fddi-0.Sacramento.cw.net [204.70.164.67]11 610 ms 634 ms 639 ms globalcenter.Sacramento.cw.net [204.70.123.6]12 612 ms 574 ms 593 ms pos4-3-155M.cr1.SNV.globalcenter.net [206.132.150.29]13 * 688 ms 654 ms pos6-0-0-155M.hr2.SNV.globalcenter.net [206.251.0.109]14 638 ms 630 ms 635 ms www.playboy.com [206.251.29.10]

Rastreamento completo.• RESULTADO DISSO: TÉCNICA DA PORTA ABERTA

• GERENCIAMENTO REATIVO (POR INTERRUPÇÃO)• NÃO TEM GERENCIAMENTO PRÓ-ATIVO• NÃO TEM ESCALA• O QUE FAZER QUANDO ALGUÉM FALA "A REDE ESTÁ LENTA!"?

• GERÊNCIA MANUAL COM INSTRUMENTAÇÃO SNMP• SNMP É O PROTOCOLO DE GERÊNCIA MAIS USADO NO MUNDO• USA OS COMANDOS SNMPGET E SNMPWALK DA CARNEGIE-MELLON UNIVERSITY (CMU)

PARA OBTER DADOS DE GERÊNCIA• EXEMPLO: ALGUÉM RECLAMA QUE NÃO CONSEGUE NAVEGAR NA INTERNET

• O ROTEADOR ESTÁ NO AR?snmpget rtbbdsc.ufpb.br <senha> system.sysUpTime.0system.sysuptime = Timeticks: (836503909) 96 days, 19:37:19

• A LINHA DE COMUNICAÇÃO PARA A INTERNET ESTÁ NO AR?interfaces.ifTable.ifEntry.ifOperStatus.1 = up(1)

• VAMOS VER O NÚMERO DE ERROSinterfaces.ifTable.ifEntry.ifInErrors.1 = 220153(ESPERA 5 SEGUNDOS)interfaces.ifTable.ifEntry.ifInErrors.1 = 220364

• MUITOS ERROS!! (211 EM 5 SEGUNDOS)• VAMOS AVISAR O RESPONSÁVEL, PASSANDO A INFORMAÇÃO CORRETA

system.sysContact.0 = "Fernando Barros"system.sysName.0 = "fw.xpto.com.br"system.sysLocation.0 = "Sala 202"system.sysDescr.0 = "CISCO ROUTER ABC, MODEL XYZ, VER. 11.0"

• COMO AGUENTAR 1000 DISPOSITIVOS COM ESSA TÉCNICA???• GERÊNCIA AUTOMÁTICA WEBMANAGER

• APLICAÇÃO DESENVOLVIDA NA UFPb POR JACQUES E PETER• GERÊNCIA AUTOMÁTICA DO FUTURO (PRÓXIMO!)

• WBEM DA FREERANGE

O NÍVEL DE INSTRUMENTAÇÃO: MODELO DEINFORMAÇÃO

PADRÕES NO MUNDO DA GERÊNCIAINTERNET-STANDARD NETWORK MANAGEMENT FRAMEWORK

• TAMBÉM CHAMADO "GERÊNCIA SNMP" DEVIDO AO PROTOCOLO PRINCIPAL: SIMPLE NETWORKMANAGEMENT PROTOCOL (SNMP)

• USADO EM PRATICAMENTE TODO O MUNDO DA GERÊNCIA• MENOS COMPLEXO DO QUE OUTRAS ALTERNATIVAS E, POR ISSO MESMO, APARECEU PRIMEIRO E

DE DIFUNDIU• LIÇÃO: "ROUGH CONSENSUS AND WORKING CODE" É MELHOR DO QUE UM MONTE DE COMITÊS• AXIOMA FUNDAMENTAL: O IMPACTO DE ADICIONAR GERÊNCIA DE REDE AOS ELEMENTOS

GERENCIADOS DEVE SER MÍNIMO, REFLETINDO UM MENOR DENOMINADOR COMUM• RESULTADO: A SOLUÇÃO BÁSICA DE GERÊNCIA (INSTRUMENTAÇÃO) E O PROTOCOLO SNMP

(VERSÃO 1) SÃO MUITO SIMPLES• RESULTADO: A COMPLEXIDADE ESTÁ NAS POUCAS NMSs (NETWORK MANAGEMENT STATIONS) E

NÃO NOS MILHARES DE ELEMENTOS GERENCIADOS


• FRAMEWORK (VERSÃO 1) BASEADO EM TRÊS DOCUMENTOS• STRUCTURE OF MANAGEMENT INFORMATION (SMI) - RFC 1155

• A LINGUAGEM USADA PARA ESPECIFICAR A INFORMAÇÃO GERENCIADA• MANAGEMENT INFORMATION BASE (MIB) PRINCIPAL - RFC 1156

• DEFINE AS VARIÁVEIS DE GERÊNCIA QUE TODO ELEMENTO GERENCIADO DEVETER

• OUTRAS MIBs EXISTEM PARA FINS PARTICULARES• SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) - RFC 1157

• O PROTOCOLO USADO ENTRE GERENTE E AGENTE PARA A GERÊNCIA,PRINCIPALMENTE TROCANDO VALORES DE VARIÁVEIS DE GERÊNCIA

• MODELO BÁSICO OPERACIONAL: "TRAP-BASED POLLING"• TRAPS SÃO EVENTOS COMUNICADOS DO AGENTE PARA O GERENTE• POLLINGS SÃO CONSULTAS PERIÓDICAS FEITAS PELO GERENTE AOS AGENTES

DMTF• DESKTOP MANAGEMENT TASK FORCE• LIDERADO PELA MICROSOFT• FEITO PARA GERENCIAR PCs NA MESA• MODELO DE INFORMAÇÃO ORIENTADO A OBJETO

• CIM = COMMON INFORMATION MODEL

ARQUITETURA OSI DE GERENCIAMENTO• VEIO DO MUNDO OSI DA ISO• DEMOROU MUITO PARA SER FEITO E FOI ADOTADO MUITO POUCO

• SÓ NO MUNDO DAS TELECOMUNICAÇÕES, JUNTO COM TMN• USA MIBs TAMBÉM• PROTOCOLO CMIP MUITO MAIS COMPLEXO DO QUE SNMP

• CMIP = COMMON MANAGEMENT INFORMATION PROTOCOL• DEFINE TAMBÉM DE SERVIÇO DE GERÊNCIA (CMIS)

• CMIS = COMMON MANAGEMENT INFORMATION SERVICE• UMA TENTATIVA DE RESGATE FOI FEITA COM CMOT

• CMOT = CMIP OVER TCP/IP• NÃO SERÁ DISCUTIDO NESTE CURSO DEVIDO A SUA POUCA UTILIZAÇÃO

TELECOMMUNICATIONS MANAGEMENT NETWORK (TMN)• ESPECIALMENTE FEITO PARA GERENCIAR REDES DE TELECOMUNICAÇÕES (TELEFÔNICAS,

BASICAMENTE)• DESENVOLVIDO PELA CCITT (HOJE ITU-T)• BASTANTE USADO ENRE AS OPERADORAS DE TELECOMUNICAÇÕES• INCIPIENTE NO BRASIL• TMN É UMA REDE PARALELA PARA GERENCIAR A REDE PRINCIPAL

• INTERCONECTA SISTEMAS DE SUPORTE À OPERAÇÃO (OPERATIONS SYSTEMS)• FEITO PARA GERENCIAR:

• A PRÓPRIA TMN• REDES DE TELEFONIA, INCLUINDO TELEFONIA MÓVEL• TERMINAIS DE TRANSMISSÃO (MULTIPLEXADORES, EQUIPAMENTOS SDH , ...)• SISTEMAS DE TRANSMISSÃO ANALÓGICOS E DIGITAIS• PABX• INFRA-ESTRUTURA (MÓDULOS DE TESTES, SISTEMAS DE ENERGIA, ...)• ETC.

• USA PROTOCOLOS OSI

ARQUITETURA DA SOLUÇÃO SNMP• USA O MODELO FETCH-STORE DE VARIÁVEIS DE GERÊNCIA MANTIDAS NOS AGENTES

• MUITO SIMPLES MAS PODEROSO• AÇÕES ESPECIAIS SÃO EFEITOS COLATERIAIS DE OPERAÇÕES STORE

• EXEMPLOS: LINK UP, LINK DOWN• TRÊS VERSÕES: SNMPv1, SNMPv2, SNMPv3• PRIMITIVAS BÁSICAS (SNMPv1)

• GET - OBTER O VALOR DE UMA VARIÁVEL• GET-NEXT - PERMITE CAMINHAR NAS VARIÁVEIS

• PARA CAMINHAR EM TABELAS DE TAMANHO DESCONHECIDO; OU• QUANDO NÃO SE SABE QUE VARIÁVEIS SÃO SUPORTADAS PELO AGENTE


• SET - ALTERAR O VALOR DE UMA VARIÁVEL• TRAP - INFORMAR EVENTOS EXTRAORDINÁRIOS

• DO AGENTE PARA O GERENTE• MODELO BÁSICO: TRAP-DIRECTED POLLING• ONDE SNMP SE INSERE NA PILHA TCP/IP:

• O MODELO CLIENTE-SERVIDOR DO SNMP:

A SEGURANÇA SNMP


• BASEADA EM UMA SENHA APENAS (COMMUNITY NAME )• UM DOS MOTIVOS DA GERÊNCIA INCOMPLETA DE REDES COM SNMP

• SET É POUCO USADO PARA CONTROLAR DISPOSITIVOS• MUITOS FABRICANTES NEM IMPLEMENTAM SET!

• UM AGENTE PODE IMPLEMENTAR VÁRIAS COMUNIDADES• CADA COMUNIDADE DÁ ACESSO A UMA "MIB VIEW" DEFINIDA LOCALMENTE• CADA COMUNIDADE PODE TER CERTOS DIREITOS DE ACESSO (DEFINIDOS LOCALMENTE)• DUAS COMUNIDADES COMUMENTE IMPLEMENTADAS:

• READ COMMUNITY• WRITE COMMUNITY

OBJETOS, INSTÂNCIAS E MIBsMODELO ESTRUTURADO EM ÁRVORE

• PARA IDENTIFICAR AS VARIÁVEIS DE GERÊNCIA• ÁRVORE USADA DEVIDO AO NÚMERO DE VARIÁVEIS• CADA ÓRGÃO DE PADRONIZAÇÃO INTERNACIONAL TEM SEU ESPAÇO DENTRO DA ESTRUTURA• CADA NODO DA ÁRVORE POSSUI UM RÓTULO

• RÓTULO = DESCRIÇÃO TEXTUAL + NÚMERO

• O TOPO DA ÁRVORE É MOSTRADO ABAIXO (SNMPv1)

OBJETOS, INSTÂNCIAS E MIBs - 2OBJETOS E INSTÂNCIAS

• CADA NODO DA ÁRVORE AGRUPA UM CONJUNTO DE OBJETOS RELACIONADOS• "OBJETO" NÃO É USADO NO SENTIDO DA ORIANTEÇÃO A OBJETO

• OS OBJETOS DESCREVEM A INFORMAÇÃO MANTIDA NOS AGENTES• UMA INSTÂNCIA DE UM OBJETO (UMA VARIÁVEL) É O QUE REALMENTE É MANIPULADO PELO

PROTOCOLO• OBJETOS PODEM SER DE DOIS TIPOS BÁSICOS:

• SIMPLES (ESCALARES)• UMA LINHA DE UMA TABELA

• SE HOUVER VÁRIAS INSTÂNCIAS, A TABELA TERÁ VÁRIAS LINHAS• SÓ HÁ TABELAS BI-DIMENSIONAIS CONTENDO OBJETOS SIMPLES

• IDENTIFICAÇÃO DE UM OBJETO


• iso.org.dod.internet.mgmt.mib-2.system.sysDescr• 1.3.6.1.2.1.1.1

• IDENTIFICAÇÃO DE UMA VARIÁVEL SIMPLES• iso.org.dod.internet.mgmt.mib-2.system.sysDescr.0• 1.3.6.1.2.1.1.1.0

• LINHAS DE TABELAS SÃO IDENTIFICADAS UNICAMENTE ATRAVÉS DE UMA (OU MAIS) COLUNASCOM CONTEÚDO ÚNICO

• A "CHAVE" DA TABELA

OBJETOS, INSTÂNCIAS E MIBs - 3OBJETOS E INSTÂNCIAS

• EXEMPLO:• A TABELA DE INTERFACES DE REDE SE CHAMA iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable• A LINHA SE CHAMA ifEntry E CONTÉM VÁRIOS OBJETOS, ENTRE OS QUAIS ifIndex E ifDescr• CADA INTERFACE TEM UM ifIndex ÚNICO (1, 2, ...)• A DESCRIÇÃO DA PRIMEIRA INTERFACE SERIA: iso.org.dod.internet.mgmt.mib-

2.interfaces.ifTable.ifEntry.ifDescr.1• EXEMPLO:

• UMA CONEXÃO TCP É IDENTIFICADA POR 4 COLUNAS DA TABELA tcpConnTable:• tcpConnLocalAddress (DIGAMOS 89.1.1.42)• tcpConnLocalPort (DIGAMOS 21)• tcpConnRemAddress (DIGAMOS 10.0.0.51)• tcpConnRemPort (DIGAMOS 2059)

• O VALOR DA COLUNA DE ESTADO DESSA CONEXÃO TERIA IDENTIFICADOR:• 1.3.6.1.2.1.6.13.1.1.89.1.1.42.21.10.0.0.51.2059

• ESSES IDENDIFICADORES (OBJECT IDENTIFIERS - OIDs) SÃO USADOS NOS COMANDOS GET, GET-NEXT, SET, TRAP

OBJETOS, INSTÂNCIAS E MIBs - 4MIBs

• UM "MÓDULO MIB" É UM AGRUPAMENTO DE OBJETOS RELACIONADOS• HÁ UMA MIB PADRÃO (mib-2) QUE TODOS OS AGENTES DEVEM SUPORTAR• MIBs SÃO CONHECIDAS PELOS AGENTES E PELO GERENTE

• O GERENTE NÃO SABE EXATAMENTE QUE MIBs SÃO SUPORTADAS POR UM DETERMINADOAGENTE

• AGENTES NORMALMENTE SUPORTAM MAIS MIBs, DEPENDENDO DO TIPO DE EQUIPAMENTO OUSOFTWARE QUE ELES SÃO:

• MIB DE REPETIDORES• MIB DE ROTEADORES• MIB ETHERNET• MIB ATM• MIB DE MONITORAÇÃO REMOTA (RMON)• MIB DE DNS• MIB DE SERVIDOR WEB• E MAIS VÁRIAS DEZENAS DE MIBs

• FREQUENTEMENTE, AGENTES SUPORTAM MIBs PROPRIETÁRIAS• EMBAIXO DE iso.org.dod.internet.private.enterprises

A MIB-2


• A mib-2 TEM MUDADO DE SNMPv1 PARA SNMPv2• DESCREVEMOS A VERSÃO ORIGINAL (MAIS USADA)

A MIB-2GRUPO system (RFC 1907)

• DESCRIÇÃO DO DISPOSITIVO (sysDescr)• NOME DO DISPOSITIVO (sysName)• IDENTIFICAÇÃO DO AGENTE (sysObjectID)

• DEVERIA IDENTIFICAR O HARDWARE, SOFTWARE, RECURSOS DO AGENTE• NA PRÁTICA, UM OID DIFERENTE É DADO A CADA VERSÃO DE CADA PRODUTO

• HÁ QUANTO TEMPO O AGENTE ESTÁ NO AR (sysUpTime)• LOCALIZAÇÃO FÍSICA DO DISPOSITIVO (sysLocation)• PESSOA RESPONSÁVEL PELO ELEMENTO (sysContact)• SERVIÇOS OFERECIDOS PELO DISPOSITIVO (sysServices)

• USA UM BIT PARA CADA CAMADA OSI• NO SNMPv2, FOI MOVIDO PARA A MIB SNMPv2-MIB

GRUPO interfaces (RFC 1573)• QUANTIDADE DE INTERFACES (ifNumber)• A TABELA DE INTERFACES (ifTable.ifEntry)

• DESCRIÇÃO DA INTERFACE (ifDescr)• TIPO DA INTERFACE (ifType)• VELOCIDADE DE TRANSMISSÃO (ifSpeed)• ENDEREÇO FÍSICO DO MEIO (ifPhysAddress)• CONTADOR DE BYTES NA ENTRADA (ifInOctets)

• UM VALOR ÚNICO DE CONTADOR NÃO DÁ INFORMAÇÃO• PRECISA PEGAR DOIS VALORES E CALCULAR A DIFERENÇA

• CONTADOR DE BYTES NA SAÍDA (ifOutOctets)• CONTADOR DE ERROS NA ENTRADA (ifInErrors)• CONTADOR DE ERROS NA SAÍDA (ifOutErrors)

• EM SNMPv2, FOI SUBSTITUIDA PELA IF-MIB

A MIB-2GRUPO at (ADDRESS TRANSLATION - RFC 1213)

• NÃO É MAIS USADO• SÓ TEM VALOR HISTÓRICO

GRUPO ip (RFC 1573, RFC 1354)• VÁRIOS CONTADORES, ENDEREÇOS, MAPEAMENTO DE ENDEREÇOS, ROTAS, ETC.• EM SNMPv2, FOI MOVIDA PARA A IP-MIB E A IP-FORWARDING-MIB


GRUPO icmp (RFC 1573, RFC 1354)• VÁRIOS CONTADORES

• MENSAGENS ENVIADAS E RECEBIDAS, CONTADOR POR TIPO, COM E SEM ERRO, ETC.• EM SNMPv2, FOI MOVIDA PARA A IP-MIB E A IP-FORWARDING-MIB

GRUPO tcp (RFC 1354)• IDENTIFICADOR DO ALGORITMO DE RETRANSMISSÃO• NÚMERO MÁXIMO DE CONEXÕES SIMULTÂNEAS PERMITIDAS• NÚMERO DE SEGMENTOS ENVIADOS E RECEBIDOS• TABELA DE CONEXÕES• ETC.• EM SNMPv2, FOI MOVIDA PARA A TCP-MIB

A MIB-2GRUPO udp (RFC 1354)

• DATAGRAMAS DESTINADOS A PORTAS DESCONHECIDAS• CONTADORES DE DATAGRAMAS ENTRANDO E SAINDO• ETC.• EM SNMPv2, FOI MOVIDA PARA A UDP-MIB

GRUPO snmp (RFC 1907)• VÁRIAS INFORMAÇÕES (CONTADORES, ETC.) SOBRE O PROTOCOLO SNMP• EM SNMPv2, FOI MOVIDA PARA A SNMPv2-MIB

MIB-2: WALK NUM AGENTEFEITO COM O PACOTE CMU-SNMP NUMA ESTAÇÃO SUNsystem.sysDescr.0 = "Sun SPARCstation Solaris2. CheckPoint FireWall-1 Version 2.1"system.sysObjectID.0 = OID: enterprises.1919.1.1system.sysUpTime.0 = Timeticks: (836503909) 96 days, 19:37:19system.sysContact.0 = "Fernando Barros"system.sysName.0 = "fw.xpto.com.br"system.sysLocation.0 = "Sala 202"system.sysServices.0 = 72interfaces.ifNumber.0 = 3interfaces.ifTable.ifEntry.ifIndex.1 = 1interfaces.ifTable.ifEntry.ifIndex.2 = 2interfaces.ifTable.ifEntry.ifIndex.3 = 3interfaces.ifTable.ifEntry.ifDescr.1 = "lo0" Hex: 6C 6F 30interfaces.ifTable.ifEntry.ifDescr.2 = "le0" Hex: 6C 65 30interfaces.ifTable.ifEntry.ifDescr.3 = "le1" Hex: 6C 65 31interfaces.ifTable.ifEntry.ifType.1 = softwareLoopback(24)interfaces.ifTable.ifEntry.ifType.2 = ethernet-csmacd(6)interfaces.ifTable.ifEntry.ifType.3 = ethernet-csmacd(6)interfaces.ifTable.ifEntry.ifMtu.1 = 8232interfaces.ifTable.ifEntry.ifMtu.2 = 1500interfaces.ifTable.ifEntry.ifMtu.3 = 1500interfaces.ifTable.ifEntry.ifSpeed.1 = Gauge: 10000000interfaces.ifTable.ifEntry.ifSpeed.2 = Gauge: 10000000interfaces.ifTable.ifEntry.ifSpeed.3 = Gauge: 10000000interfaces.ifTable.ifEntry.ifPhysAddress.1 = ""interfaces.ifTable.ifEntry.ifPhysAddress.2 = Hex: 08 00 20 7E 88 2Binterfaces.ifTable.ifEntry.ifPhysAddress.3 = Hex: 08 00 20 7E 88 2Binterfaces.ifTable.ifEntry.ifAdminStatus.1 = up(1)interfaces.ifTable.ifEntry.ifAdminStatus.2 = up(1)interfaces.ifTable.ifEntry.ifAdminStatus.3 = up(1)interfaces.ifTable.ifEntry.ifOperStatus.1 = up(1)interfaces.ifTable.ifEntry.ifOperStatus.2 = up(1)interfaces.ifTable.ifEntry.ifOperStatus.3 = up(1)interfaces.ifTable.ifEntry.ifLastChange.1 = Timeticks: (0) 0:00:00interfaces.ifTable.ifEntry.ifLastChange.2 = Timeticks: (0) 0:00:00interfaces.ifTable.ifEntry.ifLastChange.3 = Timeticks: (0) 0:00:00


interfaces.ifTable.ifEntry.ifInOctets.1 = 610783interfaces.ifTable.ifEntry.ifInOctets.2 = 99903685interfaces.ifTable.ifEntry.ifInOctets.3 = 94029823interfaces.ifTable.ifEntry.ifInUcastPkts.1 = 0interfaces.ifTable.ifEntry.ifInUcastPkts.2 = 0interfaces.ifTable.ifEntry.ifInUcastPkts.3 = 0interfaces.ifTable.ifEntry.ifInNUcastPkts.1 = 0interfaces.ifTable.ifEntry.ifInNUcastPkts.2 = 0interfaces.ifTable.ifEntry.ifInNUcastPkts.3 = 0interfaces.ifTable.ifEntry.ifInDiscards.1 = 0interfaces.ifTable.ifEntry.ifInDiscards.2 = 0interfaces.ifTable.ifEntry.ifInDiscards.3 = 0interfaces.ifTable.ifEntry.ifInErrors.1 = 0interfaces.ifTable.ifEntry.ifInErrors.2 = 0interfaces.ifTable.ifEntry.ifInErrors.3 = 0

MIB-2: WALK NUM AGENTEinterfaces.ifTable.ifEntry.ifInUnknownProtos.1 = 0interfaces.ifTable.ifEntry.ifInUnknownProtos.2 = 0interfaces.ifTable.ifEntry.ifInUnknownProtos.3 = 0interfaces.ifTable.ifEntry.ifOutOctets.1 = 610783interfaces.ifTable.ifEntry.ifOutOctets.2 = 98517639interfaces.ifTable.ifEntry.ifOutOctets.3 = 88755644interfaces.ifTable.ifEntry.ifOutUcastPkts.1 = 0interfaces.ifTable.ifEntry.ifOutUcastPkts.2 = 0interfaces.ifTable.ifEntry.ifOutUcastPkts.3 = 0interfaces.ifTable.ifEntry.ifOutNUcastPkts.1 = 0interfaces.ifTable.ifEntry.ifOutNUcastPkts.2 = 0interfaces.ifTable.ifEntry.ifOutNUcastPkts.3 = 0interfaces.ifTable.ifEntry.ifOutDiscards.1 = 0interfaces.ifTable.ifEntry.ifOutDiscards.2 = 0interfaces.ifTable.ifEntry.ifOutDiscards.3 = 0interfaces.ifTable.ifEntry.ifOutErrors.1 = 0interfaces.ifTable.ifEntry.ifOutErrors.2 = 5422interfaces.ifTable.ifEntry.ifOutErrors.3 = 8interfaces.ifTable.ifEntry.ifOutQLen.1 = Gauge: 0interfaces.ifTable.ifEntry.ifOutQLen.2 = Gauge: 0interfaces.ifTable.ifEntry.ifOutQLen.3 = Gauge: 0interfaces.ifTable.ifEntry.ifSpecific.1 = OID: .ccitt.nullOIDinterfaces.ifTable.ifEntry.ifSpecific.2 = OID: .ccitt.nullOIDinterfaces.ifTable.ifEntry.ifSpecific.3 = OID: .ccitt.nullOIDip.ipForwarding.0 = forwarding(1)ip.ipDefaultTTL.0 = 255ip.ipInReceives.0 = 189046788ip.ipInHdrErrors.0 = 241ip.ipInAddrErrors.0 = 0ip.ipForwDatagrams.0 = 186087726ip.ipInUnknownProtos.0 = 0ip.ipInDiscards.0 = 783ip.ipInDelivers.0 = 1384691ip.ipOutRequests.0 = 904804ip.ipOutDiscards.0 = 0ip.ipOutNoRoutes.0 = 0ip.ipReasmTimeout.0 = 60ip.ipReasmReqds.0 = 1624ip.ipReasmOKs.0 = 1624ip.ipReasmFails.0 = 0ip.ipFragOKs.0 = 4ip.ipFragFails.0 = 0ip.ipFragCreates.0 = 22ip.ipAddrTable.ipAddrEntry.ipAdEntAddr.127.0.0.1 = IpAddress: 127.0.0.1ip.ipAddrTable.ipAddrEntry.ipAdEntAddr.200.252.241.2 = IpAddress: 200.252.241.2ip.ipAddrTable.ipAddrEntry.ipAdEntAddr.200.252.242.53 = IpAddress: 200.252.242.53ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = 1


ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.200.252.241.2 = 3ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.200.252.242.53 = 2ip.ipAddrTable.ipAddrEntry.ipAdEntNetMask.127.0.0.1 = IpAddress: 255.0.0.0ip.ipAddrTable.ipAddrEntry.ipAdEntNetMask.200.252.241.2 = IpAddress: 255.255.255.248ip.ipAddrTable.ipAddrEntry.ipAdEntNetMask.200.252.242.53 = IpAddress: 255.255.255.128ip.ipAddrTable.ipAddrEntry.ipAdEntBcastAddr.127.0.0.1 = 0ip.ipAddrTable.ipAddrEntry.ipAdEntBcastAddr.200.252.241.2 = 1ip.ipAddrTable.ipAddrEntry.ipAdEntBcastAddr.200.252.242.53 = 1

MIB-2: WALK NUM AGENTEicmp.icmpInMsgs.0 = 61390icmp.icmpInErrors.0 = 0icmp.icmpInDestUnreachs.0 = 27icmp.icmpInTimeExcds.0 = 57101icmp.icmpInParmProbs.0 = 0icmp.icmpInSrcQuenchs.0 = 0icmp.icmpInRedirects.0 = 0icmp.icmpInEchos.0 = 4208icmp.icmpInEchoReps.0 = 54icmp.icmpInTimestamps.0 = 0icmp.icmpInTimestampReps.0 = 0icmp.icmpInAddrMasks.0 = 0icmp.icmpInAddrMaskReps.0 = 0icmp.icmpOutMsgs.0 = 182290icmp.icmpOutErrors.0 = 0icmp.icmpOutDestUnreachs.0 = 90030icmp.icmpOutTimeExcds.0 = 87547icmp.icmpOutParmProbs.0 = 0icmp.icmpOutSrcQuenchs.0 = 0icmp.icmpOutRedirects.0 = 505icmp.icmpOutEchos.0 = 0icmp.icmpOutEchoReps.0 = 4208icmp.icmpOutTimestamps.0 = 0icmp.icmpOutTimestampReps.0 = 0icmp.icmpOutAddrMasks.0 = 0icmp.icmpOutAddrMaskReps.0 = 0tcp.tcpRtoAlgorithm.0 = vanj(4)tcp.tcpRtoMin.0 = 200tcp.tcpRtoMax.0 = 60000tcp.tcpMaxConn.0 = -1tcp.tcpActiveOpens.0 = 9892tcp.tcpPassiveOpens.0 = 3575tcp.tcpAttemptFails.0 = 175tcp.tcpEstabResets.0 = 55tcp.tcpCurrEstab.0 = Gauge: 2tcp.tcpInSegs.0 = 145450tcp.tcpOutSegs.0 = 108150tcp.tcpRetransSegs.0 = 11268...tcp.tcpConnTable.tcpConnEntry.tcpConnState.127.0.0.1.32773.127.0.0.1.33692 =established(5)...tcp.tcpConnTable.tcpConnEntry.tcpConnLocalAddress.127.0.0.1.32773.127.0.0.1.33692 = IpAddress: 127.0.0.1...tcp.tcpConnTable.tcpConnEntry.tcpConnLocalPort.127.0.0.1.32773.127.0.0.1.33692 = 32773...tcp.tcpConnTable.tcpConnEntry.tcpConnRemAddress.127.0.0.1.32773.127.0.0.1.33692 = IpAddress: 127.0.0.1...tcp.tcpConnTable.tcpConnEntry.tcpConnRemPort.127.0.0.1.32773.127.0.0.1.33692 = 33692...


udp.udpInDatagrams.0 = 1246911udp.udpNoPorts.0 = 1246911udp.udpInErrors.0 = 0udp.udpOutDatagrams.0 = 638087

COMO ESCREVER UMA MIBEXEMPLO DE UMA MIB

• RFC1213-MIB (MIB-2 QUE TODO AGENTE SNMPv1 TEM)• SNMPv2-MIB (MIB QUE TODO AGENTE SNMPv2 TEM)

STRUCTURE OF MANAGEMENT INFORMATION (SMI)LINGUAGEM USADA PARA ESCREVER MIBs

• BASEADA NA ABSTRACT SYNTAX NOTATION ONE (ASN.1)• UMA LINGUAGEM DA OSI/ISO

• APENAS UM PEQUENO SUBCONJUNTO DE ASN.1 É USADO• VÁRIAS MACROS SÃO DEFINIDAS (EM ASN.1) PARA SIMPLIFICAR A ESCRITA DE MIBs• DESCREVEREMOS A SMI DO SNMPv1 (RFC1155)

• DEPOIS, TRATAREMOS DAS DIFERENÇAS NO SMIv2 (RFC1902)

SMI DESCREVE:• COMO A INFORMAÇÃO DE GERÊNCIA É AGRUPADA E NOMEADA• AS OPERAÇÕES PERMITIDAS• OS TIPOS DE DADOS PERMITIDOS• A SINTAXE PARA ESPECIFICAR MIBs

SMI - 2• A MIB NÃO ESPECIFICA COMO É A REALIZAÇÃO (IMPLEMENTAÇÃO) DOS RECURSOS• ALGUNS OBJETOS SÓ TÊM UMA INSTÂNCIA E OUTROS TÊM VÁRIAS INSTÂNCIAS• TABELAS SÃO USADAS PARA AGRUPAR OBJETOS SEMELHANTES• A IDENTIDADE DE UM OBJETO E UMA INSTÂNCIA FORMAM UMA VARIÁVEL SNMP• SMI É O "META-SCHEMA" DO BANCO DE DADOS• A ABORDAGEM É SEMELHANTE AO MODELO RELACIONAL

SMI: IDENTIFICADORES DE OBJETOS (OIDs)OBJETOS SÃO IDENTIFICADOS UNICAMENTE ATRAVÉS DE UM OID

• SEQUÊNCIA DE INTEIROS NÃO NEGATIVOS• ORGANIZADOS HIERARQUICAMENTE• ÚNICOS NO TEMPO E NO ESPAÇO

PARA FACILITAR A LEITURA, UM NOME TEXTUAL É ASSOCIADO A CADACOMPONENTE DA SEQUÊNCIA DO OID

• O ÚLTIMO NOME É UMA FORMA CURTA DE REFERENCIAR O OBJETO• UNICIDADE GLOBAL ATRAVÉS DE USO DE PREFIXOS (sys, if, tcp, ...)• EXEMPLO: sysDescr

SINTAXE PARA ESPECIFICAR O VALOR DE UM OID• { iso org(3) dod(6) internet(1) } OU 1.3.6.1• { internet 4 } OU 1.3.6.1.4• { tcp 4 } OU 1.3.6.1.2.1.6.4• O PRIMEIRO NOME DEVE SER ÚNICO NO CONTEXTO ONDE É USADO• NÃO HÁ FORMA CURTA QUANDO USANDO A NOTAÇÃO NUMÉRICA


SMI: IDENTIFICADORES DE OBJETOS (OIDs) - 2OIDs PODEM REPRESENTAR QUALQUER COISA, NÃO APENAS OBJETOS

• EXEMPLO: IDENTIFICADOR DE PRODUTO (sysObjectID)

SMI: IDENTIFICADORES DE OBJETOS (OIDs) - 3OIDs IMPORTANTES

• mib-2• experimental É USADO PARA EXPERIÊNCIAS AINDA NÃO CONCLUSIVAS DOS GRUPOS DE TRABALHO

DA IETF• EMPRESAS DEFINEM SUAS MIBs PROPRIETÁRIAS ABAIXO DE enterprises

• NÚMEROS DE EMPRESAS PODEM SER OBTIDAS DA IANA• A EMPRESA DECIDE O QUE FAZER NA SUA ÁRVORE

• DAREMOS DICAS À FRENTE

SMI: MÓDULOS MIBA MIB SNMP É DEFINIDA POR UM CONJUNTO DE MÓDULOS MIB

• "A" MIB SNMP CONSISTE DE VÁRIAS MIBs DEFINIDAS EM DOCUMENTOS SEPARADOS• FRONTEIRAS ENTRE MIBs NÃO APARECEM NA OPERAÇÃO DO PROTOCOLO• A PALAVRA "MIB" NORMALMENTE É USADA PARA SIGNIFICAR UMA MIB ESPECÍFICA, NÃO A MIB

CONCEITUAL GLOBAL

MÓDULOS SÃO UM MECANISMO DE ESCOPO DE NOMES• OS NOMES DEVEM SER ÚNICOS NUM MÓDULO• PARA MIBs PADRÃO, OS NOMES DEVEM SER ÚNICOS GLOBALMENTE• SE NOMES DE MÓDULOS FOREM ÚNICOS E NOMES DENTRO DE UM MÓDULO TAMBÉM, NÃO HÁ

CONFUSÃO

REGRAS DE FORMAÇÃO DE NOMES DE MÓDULOS• INICIAM COM LETRA MAIÚSCULA• PODEM USAR LETRAS, NÚMEROS E HIFEN


• NÃO PODEM TERMINAR COM HIFEN• HIFEN NÃO PODE SER SEGUIDO DE HIFEN• NÃO HÁ RESTRIÇÃO DE TAMANHO

• MAS COMPILADORES E SOFTWARE DE NMS PODEM IMPOR LIMITES

SMI: MÓDULOS MIB - 2O QUE UM MÓDULO CONTÉM

• PONTOS DE REGISTRO NA ÁRVORE DE OIDs• OBJETOS GERENCIADOS• VALORES PARA OIDs• TRAPS• SEQUÊNCIAS (PARA DEFINIR TABELAS)• CONVENÇÕES TEXTUAIS

O QUE UM MÓDULO NÃO PODE CONTER• NOVAS MACROS EM ASN.1• NOVOS TIPOS ETIQUETADOS EM ASN.1

• UM TIPO ETIQUETADO É UM TIPO NOVO QUE AFETA A CODIFICAÇÃO BER• JÁ QUE AFETAM A CODIFICAÇÃO, AS ETIQUETAS DEVEM SER CONHECIDAS POR AMBOS OS

LADOS (DEVEM FAZER PARTE DO PADRÃO)• TIPOS ETIQUETADOS SÃO DEFINIDOS NA SMI, NUNCA NUMA MIB• VEREMOS DETALHES À FRENTE

SINTAXE DA DEFINIÇÃO DE UM MÓDULOSintaxe:

<mib> = <module>...<module> = <ModName> "DEFINITIONS" "::=" "BEGIN"

[ "IMPORTS" <importList>... ";" ][ <smiItem>... ][ <textConvItem>... ]{ <oidItem> | <objectItem> | <seqItem> | <trapItem> }..."END"

<importList> = <importItem> [ "," <importItem> ]..."FROM" <ImportModName>

Onde<ModName> é o nome de um módulo MIB;<smiItem> é uma definição de itne SMI tais como tipos sintáticos,

as marcos OBJECT-TYPE e TRAP-TYPE;<importItem> é um item definido em outro módulo MIB;<ImportModName> é o nome de ou outro módulo MIB previamente definido;<textConvItem> é a definição da convenção textual;<oidItem> é a definição de um object identifier;<objectItem> é a definição de um item com a macro OBJECT-TYPE;<seqItem> é a definição de uma sequência; e<trapItem> é a definição de um item com a macro TRAP-TYPE.

SMI: MÓDULOS MIB - 3SINTAXE DA DEFINIÇÃO DE UM MÓDULO

• NOMES PODEM SER IMPORTADOS DE MÓDULOS DEFINIDOS ANTERIORMENTE• CONVENÇÕES TEXTUAIS SÃO UM MECANISMO PARA ESTENDER OS TIPOS SINTÁTICOS SEM

ADICIONAR UM NOVO TIPO• PORQUE UM NOVO TIPO IMPLICA NUMA NOVA CODIFICAÇÃO DO PROTOCOLO, E O

PROTOCOLO DEVE SER MUDADO MUITO RARAMENTE• ITENS OBJECT IDENTIFIER SÃO:

• PONTOS DE REGISTRO NA ÁRVORE DE OIDs• VALORES DE ITENS COM A SINTAXE OBJECT IDENTIFIER• GRUPOS DE OBJETOS SNMP

• A MACRO OBJECT-TYPE É USADA PARA DEFINIR• TABELAS, LINHAS, OBJETOS SIMPLES E COLUNARES

• SEQUÊNCIAS SÃO USADAS PARA DEFINIR TABELAS CONCEITUAIS


• A MACRO TRAP-TYPE É USADA PARA DEFINIR TRAPS• COMENTÁRIOS INICIAM COM -- E TERMINAM COM -- OU NO FIM DA LINHA

SMI: A ESPECIFICAÇÃO DE UM MÓDULOA POSIÇÃO DE OBJETOS DA ÁRVORE DE OIDs DEVE SER DETERMINADAANTES DE ESCREVER UM MÓDULO MIB

• QUANDO UMA MIB É PUBLICADA, ITENS NÃO PODEM MUDAR• PODEM FICAR OBSOLETOS OU PODEM SER RECRIADOS COM OUTROS OIDs• EMPRESAS PODEM CRIAR UM GALHO PRIVADO experimental E MUDAR AS MIBs ATÉ QUE

SEJAM PUBLICADAS EM OUTRO LOCAL DA ÁRVORE

FORMATO BÁSICO DO MÓDULO• UM NOME ÚNICO É ESCOLHIDO PARA O MÓDULO• IMPORTAÇÕES SÃO FEITAS PARA

• OS PONTOS DE REGISTRO DOS OBJETOS• OS TIPOS SINTÁTICOS USADOS NO MÓDULO• PARA AS MACROS OBJECT-TYPE E TRAP-TYPE

• EXEMPLOEXAMPLE-MIB DEFINITIONS ::= BEGIN-- A MIB is always written in English-- Copyright notice-- MIB Descriptions-- Some or all the the following IMPORTS...IMPORTS

enterprises, Counter, Gauge,TimeTicks, IpAddress FROM RFC1155-SMIDisplayString, PhysAddress FROM RFC1213-MIBOBJECT-TYPE FROM RFC-1212TRAP-TYPE FROM RFC-1515;

-- Some or all of the following:-- Textual Conventions-- Registration points-- Groups-- SNMP managed Objects-- SNMP trapsEND

SMI: IDENTIFICADORES DE OBJETOSOBJECT IDENTIFIER É USADO PARA

• PONTOS DE REGISTRO DE ALTO NÍVEL NA ÁRVORE• GRUPOS DE OBJETOS• VALOR PARA ITENS COM A SINTAXE OBJECT IDENTIFIER

REGRAS PARA NOMES• COMO PARA NOMES DE MÓDULOS MAS INICIANDO COM LETRA MINÚSCULA

GRUPOS• ORGANIZAM OBJETOS EM ÁRVORE• EXEMPLO: system• SÃO USADOS COMO UNIDADE DE CONFORMIDADE

• GRUPOS PODEM SER DE IMPLEMENTAÇÃO OBRIGATÓRIA OU OPCIONAL• QUANDO SÃO OBRIGATÓRIOS, TODOS OS SUB-OBJETOS DEVEM SER SUPORTADOS• QUANDO SÃO OPCIONAIS, PODEM SER IMPLEMENTADOS COMPLETAMENTE OU NÃO

IMPLEMENTADOS

EXEMPLOSsystem OBJECT IDENTIFIER ::= { mib-2 1 }

SMI: DEFINIÇÃO DE OBJETOS GERENCIADOSTRÊS TIPOS DE OBJETOS PODEM SER DEFINIDOS USANDO A MACRO


OBJECT-TYPE• TABELAS• LINHAS DE TABELAS• OBJETOS FOLHA (SIMPLES E COLUNARES)• OS NOMES SÃO COMO PARA NOMES DE MÓDULOS MAS DEVEM INICIAR COM LETRA MINÚSCULA

<objectItem> = <objectName>"OBJECT-TYPE""SYNTAX" <syntax>"ACCESS" <access>"STATUS" <status>[ "DESCRIPTION" <description> ][ "REFERENCE" <reference> ][ "INDEX" "{" <indexItems>"}" ][ "DEFVAL" "{" <defaultValue>"}" ]"::=" "{" <parent> <number>"}"

<objectName> = <tableName> | <rowName> | <leafName><syntax> = { "SEQUENCE" "OF"<SequenceName> } |

<SequenceName> |<leafSyntax>

Onde:<objectName> é o nome do item sendo definido;<parent> é o nome do item que contem este na arvore de OIDs;<number> é o valor do último componente do item sendo definido; eValores para <access>, <status>, <leafSyntax>, etc.

serão definidos depois.

OBJETOS DO TIPO TABELA• UMA TABELA CONSISTE DE LINHAS• O PROTOCOLO SNMP NÃO PERMITE MANIPULAR TABELAS OU LINHAS, APENAS ITENS INDIVIDUAIS

DAS COLUNAS (ITENS COLUNARES)• PORTANTO, AS TABELAS SÃO "CONCEITUAIS"

• A SINTAXE É SEQUENCE OF <SEQUÊNCIA>• POR CONVENÇÃO, O NOME DE TABELAS USA O SUFIXO Table• POR CONVENÇÃO, O NOME DA SEQUÊNCIA ASSOCIADA É O PREFIXO DO NOME DA TABELA (SEM

Table) INICIANDO COM LETRA MAIÚSCULA (IDENTIFICANDO UM TIPO) E COM O SUFIXO Entry• EXEMPLO: PARA A TABELA ifTable, A SEQUÊNCIA SERIA DO TIPO IfEntry• O VALOR DE ACCESS DEVE SER not-accessible, JÁ QUE SNMP NÃO MANIPULA TABELAS

(DIRETAMENTE)

OBJETOS DO TIPO TABELA• A SINTAXE DE DEFINIÇÃO DE OBJETOS GERENCIADOS SEGUE

• UMA MIB CONSISTE DE TAIS DEFINIÇÕES, EM GRANDE PARTE<tableName> "OBJECT-TYPE"

"SYNTAX" "SEQUENCE" "OF" <SequenceName>"ACCESS" "not-accessible""STATUS" <status>[ "DESCRIPTION" <description> ][ "REFERENCE" <reference> ]"::=" "{" <parent> <number>"}"

<tableName> = <name>"Table"<SequenceName> = <Name>"Entry"

Onde:<name> é o prefixo da tabela sendo definida;<Name> é o prefixo da sequência associada;<parent> é o nome do item que contem este diretamente na arvore de OIDs;<number> é o valor do último componente do item sendo definido; eValores para <status>, <description>, etc. são definidos depois.

Exemplo:ifTable OBJECT-TYPE

SYNTAX SEQUENCE OF IfEntry


ACCESS not-accessibleSTATUS mandatory::= { interfaces 2 }

OBJETOS DO TIPO LINHA• UMA LINHA CONSISTE DE COLUNAS• O PROTOCOLO SNMP NÃO MANIPULA COLUNAS DIRETAMENTE

• MAS GET E GET-NEXT PODEM SER USADOS PARA ACESSAR TODAS AS COLUNAS DE UMADETERMINADA LINHA DE UMA ÚNICA VEZ

• POR CONVENÇÃO, O NOME DA LINHA É O NOME DA TABELA COM Table SUBSTITUIDO POR Entry• O TIPO SINTÁTICO DA LINHA DEVE SER A SEQUÊNCIA USADA PARA DEFINIR A TABELA• O VALOR DE OID PARA O OBJETO LINHA DEVE SER O OID DA TABELA COM A ADIÇÃO DE 1• A CLÁUSULA INDEX ESPECIFICA COMO IDENTIFICAR INSTÂNCIAS DA LINHA UNICAMENTE

• VIDE DETALHES À FRENTE

OBJETOS DO TIPO LINHA• A SINTAXE DE DEFINIÇÃO DE OBJETOS DO TIPO LINHA SEGUE

<rowName> "OBJECT-TYPE""SYNTAX" <SequenceName>"ACCESS" "not-accessible""STATUS" <status>[ "DESCRIPTION" <description> ][ "REFERENCE" <reference> ]"INDEX" "{" <indexItems> "}""::=" "{" <tableName> 1 "}"

<rowName> = <name>"Entry"<SequenceName> = <Name>"Entry"<tableName> = <name>"Table"<indexItems> = <indexItem> [ ","<indexItem> ]...

Onde:

<name> é o prefixo da linha sendo definida eo prefixo da tabela associada;

<Name> é o prefixo da sequência associada;<indexItem> é o nome de um item na sequência

para a linha (ou o nome de um tipo sintático); eValores para <status>, <description>, etc. serão

definidos depois.

Exemplo:

ifEntry OBJECT-TYPESYNTAX IfEntryACCESS not-accessibleSTATUS mandatoryINDEX { ifIndex }::= { ifTable 1 }

DEFINIÇÕES DE SEQUÊNCIA• UMA SEQUÊNCIA DEFINE AS COLUNAS DA LINHA• O NOME DA SEQUÊNCIA INICIA COM LETRA MAIÚSCULA• NORMALMENTE, OS ITENS DA SEQUÊNCIA SÃO FILHOS DO OBJETO LINHA

• MAS QUANDO SE ESTENDE UMA TABELA, ALGUNS DOS OBJETOS COLUNARES DA TABELAEXISTENTE PODEM SER ADICIONADOS À NOVA SEQUÊNCIA

• ALÉM DO NOME, A SINTAXE DE CADA OBJETO COLUNAR DEVE SER DEFINIDA• NORMALMENTE É UM RESUMO DA SINTAXE TOTAL DO ITEM

• NÃO PRECISA DE TAMANHO, FAIXA, ENUMERAÇÕES DE INTEIROS• UMA SEQUÊNCIA PODE SER USADA APENAS PARA UMA TABELA E UMA LINHA• UMA SEQUÊNCIA NÃO PODE SER IMPORTADA DE OUTRO MÓDULO

DEFINIÇÕES DE SEQUÊNCIA• A SINTAXE SEGUE:


<seqItem> = <SequenceName> "::=""SEQUENCE" "{"

<columnItem> <leafSyntax>{ "," <columnItem> <leafSyntax> }...

"}"<SyntaxName> = <Name>"Entry"

Onde:

<Name> é o prefixo da sequ6encia sendo definida;<columnItem> é o nome de um item da sequência; e<leafSyntax> é a sintaxe simplificada do item.

Exemplo:

IpAddrEntry ::= SEQUENCE {ipAdEntAddr IpAddress,ipAdEntIfIndex INTEGER,ipAdEntNetMask IpAddress,ipAdEntBcastAddr INTEGER,ipAdEntReasmMaxSize INTEGER

}

OBJETOS FOLHA• O MENOR OBJETO DE AGRUPAMENTO• UM OBJETO FOLHA MAIS UMA INSTÂNCIA FORMAM UMA VARIÁVEL SNMP

• VARIÁVEIS SÃO OPERANDOS DO PROTOCOLO• PODEM SER SIMPLES

• EX. O NÚMERO DE INTERFACES DE UM DISPOSITIVO• SÓ TÊM UMA INSTÂNCIA• A INSTÂNCIA TEM OID COM COMPONENTE FINAL 0• OBJETOS SIMPLES NORMALMENTE TÊM O MESMO PREFIXO DO GRUPO AO QUAL

PERTENCEM

OBJETOS FOLHA• PODEM SER COLUNARES

• ORGANIZADOS EM TABELAS CONCEITUAIS• PODE HAVER VÁRIAS INSTÂNCIAS• EX. A VELOCIDADE DE UMA INTERFACE• A INSTÂNCIA É FORMADA ATRAVÉS DO OID DO OBJETO COLUNAR MAIS O VALOR DA

CLÁUSULA INDEX DA LINHA CORRESPONDENTE• OBJETOS COLUNARES NORMALMENTE TÊM O MESMO PREFIXO DA LINHA

• A SINTAXE SEGUE<leafName> "OBJECT-TYPE"

"SYNTAX" <leafSyntax>"ACCESS" <access>"STATUS" <status>[ "DESCRIPTION" <description> ][ "REFERENCE" <reference> ][ "DEFVAL" "{" <defaultValue>"}" ]"::=" "{" <parent> <number>"}"

Onde:<leafName> é o nome do objeto folha sendo definido;<parent> é o nome do item que contem este

na árvore de OIDs (ou uma linha ou um grupo);<number> é o valor do último componente do item

sendo definido; eValores para <leafSyntax>, <access>, <status>, etc.


Exemplos:sysUpTime OBJECT-TYPE

SYNTAX TimeTicksACCESS read-only


STATUS mandatory::= { system 2 }

ipAdEntAddr OBJECT-TYPESYNTAX IpAddressACCESS read-onlySTATUS mandatory::= { ipAddrEntry 1 }

CONVENÇÕES TEXTUAIS• USADAS PARA ESPECIFICAR SEMÂNTICA ADICIONAL A UM TIPO SINTÁTICO EXISTENTE

• É A ÚNICA FORMA DE "ESTENDER" OS TIPOS SINTÁTICOS DA SMI• DUAS CONVENÇÕES TEXTUAIS SÃO DEFINIDAS

• DisplayString (CARACTERES ASCII IMPRIMÍVEIS)• PhysAddress• AMBAS SÃO BASEADAS EM OCTET STRING• NENHUMA CODIFICAÇÃO NOVA DE TIPOS É NECESSÁRIA

• AS RESTRIÇÕES SÃO DESCRITAS EM COMENTÁRIOS ANEXADOS À CONVENÇÃO TEXTUAL• A SINTAXE SEGUE:

<textConvItem> = <textConvName> "::=" <leafSyntax>

Onde:<textConvName> é o nome da convenção textual

sendo definida; e<leafSyntax> é qualquer tipo sintático.

Exemplos:DisplayString ::= OCTET STRING (SIZE(0..255))Status ::= INTEGER { enabled(1), disabled(2) }

VALORES PARA SYNTAX• PARA TABELAS, É SEQUENCE OF <NomeDeSequência>• PARA OBJETO DO TIPO LINHA, É <NomeDeSequência>• PARA FOLHAS, NÃO PODE USAR UMA SEQUÊNCIA

• ANS.1 PERMITE, MAS NÃO SMI• A SINTAXE SEGUE:

<leafSyntax> = { "INTEGER" [ <range> | <enums> ] } |{ "OCTET" "STRING" [ <size> ] } |{ "OBJECT" "IDENTIFIER" } |{ <smiApplType> } |{ <textConvName> [ <range> | <size> ] }

<smiApplType> = "NetworkAddress" | "IpAddress" |"Counter" | "Gauge" | "TimeTicks" |"Opaque"

<range> = "(" <lower> ".." <higher> ")"<enums> = "{" <enumItem> [ "," <enumItem> ]... "}"<enumItem> = <enumName> "(" <enumValue> ")"<size> = "(" "SIZE" "(" <smallest> [ ".." <largest>] ")" ")"

Onde:<lower> and <higher> podem ser inteiros positivos

ou negativos, strings de bits constantes, ou constantes hexstring;

<enumName> inicia com letra minuscula seguida deum número arbitrário de letras, dígitos, e hifen.

<enumValue> é um inteiro positivo, constante bitstringou hexstring que não tenha valor zero

<smallest> e <largest> podem ser inteirosnão negativos, constantes bitstring ou hexstring.

• INTEGER• 32 BITS• PODEM ESPECIFICAR UMA FAIXA

SYNTAX INTEGER (0..65535)SYNTAX INTEGER (0..'ffff'h)


SYNTAX INTEGER (0..'ff'H)

VALORES PARA SYNTAX• <enums>

• CASO ESPECIAL DE INTEGER• NÃO PODE USAR ZERO OU NEGATIVO• VARIÁVEIS SÓ PODEM TER OS VALORES ESPECIFICADOS• DEVERIA TER UMA OPÇÃO "other" MAS MUITAS MIBs NÃO USAM• A DESCRIÇÃO DEVERIA EXPLICAR VALORES NÃO ÓBVIOS

SYNTAX INTEGER { gateway(1), host(2) } SYNTAX INTEGER {other(1), invalid(2), direct(3), indirect(4)

}• OCTET STRING

• STRING DE BYTES COM INFORMAÇÃO BINÁRIA• PODE TER UM TAMANHO

SYNTAX OCTET STRING (SIZE (0..9)) tamanho variávelSYNTAX OCTET STRING tamanho variávelSYNTAX OCTET STRING (SIZE (6)) tamanho fixo

• DisplayString• CONVENÇÃO TEXTUAL• É UM OCTET STRING COM CARACTERES ASCII IMPRIMÍVEIS• DEVE TER UM TAMANHO MAS É FREQUENTEMENTE OMITIDO

SYNTAX DisplayString (SIZE (0..255))

VALORES PARA SYNTAX• PhysAddress

• CONVENÇÃO TEXTUAL• É UM OCTET STRING ONDE OS BYTES REPRESENTAM UM ENDEREÇO FÍSICO EM "NETWORK

ORDER" (BIG-ENDIAN)SYNTAX PhysAddress (SIZE (6))

• OBJECT IDENTIFIER• UM VALOR DE OID

SYNTAX OBJECT IDENTIFIER• NetworkAddress

• SÓ ENDEREÇOS IP SÃO SUPORTADOS• TIPO DISCONTINUADO: NÃO USE

• IpAddress• OCTET STRING DE 4 BYTES EM "NETWORK ORDER"

• Counter• INTEIRO NÃO NEGATIVO QUE CONTA ATÉ 232-1 E VOLTA PARA ZERO• NÃO PODE TER FAIXA• VALOR ABSOLUTO NÃO SIGNIFICA NADA

• PRECISA DE 2 VALORES E USAR A DIFERENÇA• Gauge

• INTEIRO NÃO NEGATIVO QUE PODE AUMENTAR OU DIMINUIR MAS RETORNA 232-1 COMOVALOR MÁXIMO

• NÃO PODE TER FAIXA• EXEMPLO: ifOutQLen

VALORES PARA SYNTAX• TimeTick

• INTEIRO NÃO NEGATIVO QUE CONTA CENTÉSIMOS DE SEGUNDOS DESDE UM MARCO DETEMPO (EPOCH)

• O MARCO DE TEMPO DEVE SER ESPECIFICADO NA DESCRIÇÃO• NÃO PODE TER FAIXA

• Opaque• USADOS EM MIBs PRIVADAS PARA REPRESENTAR UM VALOR QUALQUER QUANDO NÃO

TEM OUTRO DISPONÍVEL• NÃO DEVE SER USADO MAIS

VALORES PARA ACCESS• read-only


• read-write• write-only• not-accessible

• NECESSÁRIO PARA TABELAS E LINHAS

VALORES PARA STATUS• mandatory

• SE UMA IMPLEMENTAÇÃO NÃO SUPORTA O OBJETO, ELA É "NON-CONFORMANT" PARAESTA MIB

• optional• "optional" NÃO DEVE SER USADO

• OS CRIADORES DE SNMP ADMITEM QUE FOI UM ERRO• GRUPOS INTEIROS PODEM SER OPCIONAIS MAS NÃO OBJETOS INDIVIDUAIS

• COMENTÁRIOS INDICAM OS GRUPOS OBRIGATÓRIOS E OPCIONAIS• obsolete

• INDICA QUE O OBJETO NÃO DEVE SER USADO MAIS• deprecated

• INDICA QUE O OBJETO PODE SER USADO MAS VAI DESAPARECER COM TEMPO

VALORES PARA DESCRIPTION• STRING ENTRE ASPAS DUPLAS

• PODE TER VÁRIAS LINHAS• DESCREVE A SEMÂNTICA DO OBJETO• AJUDA OS ESCRITORES DE GERENTES E AGENTES• SERVE DE HELP PARA O OPERADOR QUANDO FAZ MIB BROWSING

VALORES PARA REFERENCE• STRING DE DESCRIÇÃO PARA APONTAR UM OUTRO LUGAR (OBJETO, DOCUMENTO) QUE

DESCREVE O MESMO OBJETO OU DO QUAL O OBJETO DEPENDE

VALORES PARA INDEX• SÓ PARA OBJETO DO TIPO LINHA• LISTA AS COLUNAS QUE SERVEM DE ESPECIFICADORES DE INSTÂNCIAS PARA OBJETOS

COLUNARES• A ORDEM DOS ITENS INDICA COMO A INSTÂNCIA É MONTADA• A DESCRIÇÃO DEVE INFORMAR A SEMÂNTICA DOS ITENS DO INDEX

VALORES PARA DEFVAL• USADO COMO DICA PARA A IMPLEMENTAÇÃO DE AGENTES PARA A CRIAÇÃO DE LINHAS USANDO

SET E QUANDO O SET NÃO ESPECIFICA TODOS OS VALORES DAS COLUNAS• SÓ DEVE SER USADO PARA OBJETOS COLUNARES QUE NÃO PARTICIPAM DO INDEX

CONSIDERAÇÕES PARA INSTÂNCIAS• PARA OBJETOS SIMPLES QUE NÃO ESTÃO EM TABELA

iso org dod internet mgmt mib system sysDescr (instance) 1 3 6 1 2 1 1 1 0

ou 1.3.6.1.2.1.1.1.0 ou sysDescr.0• PARA OBJETOS QUE ESTÃO EM TABELA, USAR OS ITENS DE INDEX COMO SEGUE

TIPO SINTÁTICO CODIFICAÇÃO DA INSTÂNCIA

INTEGER UM ÚNICO COMPONENTE É USADO

STRING DE TAMANHOFIXO

N COMPONENTES SÃO USADOS, UM PARA CADA BYTE DO STRING. OTIPO DEVE INDICAR O TAMANHO (VIA CONVENÇÃO TEXTUAL OU NÃO)

STRING DE TAMANHOVARIÁVEL

N+1 COMPONENTES SÃO USADOS: O TAMANHO EM BYTES SEGUIDODOS BYTES, UM POR COMPONENTE

IpAddress4 COMPONENTES SÃO USADOS: CADA BYTE DO ENDEREÇO EM"NETWORK ORDER"

IDENTIFICADOR DEOBJETO

N+1 COMPONENTES SÃO USADOS: O NÚMERO DE COMPONENTES NOVALOR DO OID SEGUIDO DOS COMPONENTES DO VALOR DO OID


NetworkAddressCINCO COMPONENTES SÃO USADOS. O PRIMEIRO COMPONENTE TEMVALOR 1 PARA INDICAR UM ENDEREÇO IP. SEGUE COMO IpAddress

REGRAS PARA A DEFINIÇÃO DE OBJETOS• COLOCAR OBJETOS EM GRUPOS LÓGICOS HIERÁRQUICOS

• UM GRUPO COMPLETO PODE SER DESIGNADO COMO OPCIONAL OU OBRIGATÓRIO• O COMPONENTE ZERO (0) NÃO PODE SER USADO PARA UM OBJETO• O OID DE UM OBJETO DO TIPO LINHA PARA UMA TABELA DEVE ESTAR UM NÍVEL ABAIXO DA

TABELA E DEVE TER O ÚLTIMO COMPONENTE IGUAL A 1• NÃO DEVE HAVER IRMÃOS PARA ESTE OBJETO LINHA• OS OBJETOS COLUNARES DEVEM ESTAR UM NÍVEL ABAIXO DO OBJETO LINHA

• EM SNMP, OBJETOS AGREGADOS SÃO DEFINIDOS COMO TABELAS• UMA OU MAIS COLUNAS SÃO DESIGNADAS COMO ÍNDICES DAS LINHAS• NÃO PODE TER TABELAS DENTRO DE TABELAS• PARA SIMULAR TABELAS ANINHADAS, ELEVE O NÍVEL DA OUTRA TABELA AO NÍVEL DA

PRIMEIRA, E COLUNAS QUE SÃO ÍNDICES DA TABELA ORIGINAL PODEM SER ADICIONADASÀ TABELA NOVA COM OUTRO NOME

• OS ÍNDICES DA NOVA TABELA SERÃO OS ÍNDICES DA TABELA ORIGINAL(RENOMEADOS) MAIS OS ÍNDICES NATURAIS DA NOVA TABELA

REGRAS PARA A DEFINIÇÃO DE OBJETOS• TABELAS QUE PERMITEM A CRIAÇÃO E REMOÇÃO DE LINHAS (DISCUTIDAS À FRENTE) DEVEM TER

UMA COLUNA xxxType OU xxxStatus QUE É UMA ENUMERAÇÃO• POR CONVENÇÃO, O PRIMEIRO VALOR DEVE SER other OU valid E O SEGUNDO VALOR

DEVERIA SER invalid• PARA REMOVER UMA LINHA, COLOCAR invalid NESTA VARIÁVEL• UMA NOVA LINHA É CRIADA COM UMA ÚNICA OPERAÇÃO SET

• AS VARIÁVEIS DO SET SÃO AS COLUNAS OBRIGATÓRIAS• A CLÁUSULA DESCRIPTION DEVE DESCREVER A SEMÂNTICA DA CRIAÇÃO E REMOÇÃO

• A CLÁUSULA DESCRIPTION DEVE SER USADA PARA CADA OBJETO FOLHA PARA DESCREVER SUAFUNÇÃO E SEU USO

• TODOS OS NOMES DE UM MÓDULO MIB DEVEM SER ÚNICOS• NOMES DE OBJETOS INICIAM COM LETRA MINÚSCULA• NOMES DE OBJETOS QUE SÃO CONTADORES DEVEM TERMINAR COM "s" (PLURAL)

• OBJETOS QUE SÃO STRINGS IMPRIMÍVEIS DEVEM USAR A CONVENÇÃO TEXTUAL DisplayString• OBJETOS QUE CONTÊM INFORMAÇÃO BINÁRIA DEVEM USAR OCTET STRING

• ENDEREÇO FÍSICOS DEVEM USAR PhysAddress E NÃO OCTET STRING

REGRAS PARA A DEFINIÇÃO DE OBJETOS• OBJETOS DEVEM SER PROJETADOS PARA A IDEMPOTÊNCIA

• SNMP USA UDP E O GERENTE PODE DUPLICAR O PEDIDO SE NÃO HOUVER RESPOSTA APÓSUM TIMEOUT

• O NÚMERO DE COLUNAS DE UMA TABELA DEVE SER PEQUENO O SUFICIENTE PARA QUE UMALINHA INTEIRA POSSA SER RECUPERADA COM UMA ÚNICA OPERAÇÃO GET

REGRAS GERAIS PARA O PROJETO DE MIBs• INFORMAÇÃO DEMAIS CRIA TANTO PROBLEMA QUANTO INFORMAÇÃO INSUFICIENTE

• INICIE LENTAMENTE E SÓ INCLUA OBJETOS IMPORTANTES PARA A GERÊNCIA• INICIE COM OS OBJETOS QUE SÃO IMPORTANTES PARA A GERÊNCIA DE CONFIGURAÇÃO E FALTAS

(AS DUAS ÁREAS MAIS IMPORTANTES)• LEMBRE QUE A SEGURANÇA DO SNMPv1 E SNMPv2 É FRACA

• NÃO DEPENDA DEMAIS NO CONTROLE REMOTO USANDO SET• NÃO COLOQUE OBJETOS PARA "GUARDAR LUGAR" PARA ADIÇÕES FUTURAS

• CADA OBJETO DEVE SER USADO DE FATO• EVITE REDUNDÂNCIA

• NÃO DEFINA OBJETOS QUE PODEM FACILMENTE SER CALCULADOS COM O VALOR DEOUTROS

• USE DIAGRAMAS CASE (VIDE À FRENTE) PARA MOSTRAR A RELAÇÃO ENTRE CONTADORES• ESCOLHA OBJETOS GENÉRICOS QUE PODERÃO SER USADOS EM OUTROS PRODUTOS• SEÇÕES CRÍTICAS DE CÓDIGO NÃO DEVEM SER INSTRUMENTADAS DEMAIS


• APÓS COLOCAR INSTRUMENTAÇÃO SNMP NUM DISPOSITIVO, ESTE DEVE AINDA FUNCIONAR BEMNO SEU PAPEL ORIGINAL

DIAGRAMAS CASE• MOSTRAM VISUALMENTE A RELAÇÃO ENTRE CONTADORES

SMI: TRAPSUSADOS PELO AGENTE PARA INDICAR UM EVENTO EXTRAORDINÁRIOPARA O GERENTE

• SINTAXE FRACA EM SNMPv1• NÃO USA OIDs PARA IDENTIFICAR TRAPS• USA NUMERAÇÃO "FLAT" COM 6 EVENTOS• MECANISMO DE EXTENSÃO QUANDO O VALOR DO CAMPO DE TRAP É enterpriseSpecific(6)

• NESTE CASO, O VALOR DO TRAP E O CAMPO enterprise SÃO USADOSCONJUNTAMENTE PARA IDENTIFICAR O TRAP

• NINGUÉM USA ESTE MECANISMO• MUDANÇAS GRANDES EM SNMPv2

A MACRO TRAP-TYPE• USADO PARA DEFINIR TRAPS• SINTAXE SEGUE:

<trapItem> = <trapName> "TRAP-TYPE""ENTERPRISE" <oidName>[ "VARIABLES" "{" <varName>["," <varName>]... "}" ][ "DESCRIPTION" <description> ][ "REFERENCE" <reference> ]"::=" <value>

Onde:<trapName> é o nome do trap sendo definido;<oidName> pode ser "snmp" ou o valor a retornarno campo "enterprise";<value> é o valor do trap retornado em um dos campos"generic-trap" ou "specific-trap"; eValores para <varName>, <description>, e <reference>


VALORES PARA ENTERPRISE• DETERMINA O VALOR A RETORNAR NO CAMPO enterprise DA PDU TRAP DO PROTOCOLO SNMP• SE O VALOR ESPECIFICADO FOR "snmp", USA-SE O VALOR DE sysObjectID DO AGENTE QUE GEROU O

TRAP• O TRAP É DO TIPO snmp-generic


• COM OUTRO VALOR, ESTE DEVE SER RETORNADO NA PDU• O TRAP É DO TIPO enterprise-specific

VALORES PARA VARIABLES• OPCIONAL• INDICA QUAIS OBJETOS INTERESSANTES DEVEM SER RETORNADOS NO TRAP• DESCRIPTION DEVE INDICAR QUE INSTÂNCIAS RETORNAR• O AGENTE PODE RETORNAR MAIS VARIÁVEIS

• ATÉ UM MÁXIMO DE 484 BYTES• O GERENTE DEVE ESTAR PRONTO PARA RECEBER QUAISQUER VARIÁVEIS, NÃO SÓ

AQUELAS ESPECIFICAS NA CLÁUSULA VARIABLES

VALORES PARA DESCRIPTION• PROVÊ TODA A SEMÂNTICA NECESSÁRIA À IMPLEMENTAÇÃO

VALORES PARA REFERENCE• COMO PARA OBJECT-TYPE

VALORES PARA TRAP-TYPE• SE FOR ENTERPRISE snmp, O VALOR DEVE ESTAR ENTRE 0 E 5 (GENERIC TRAP)

• O CAMPO GENERIC-TRAP DA PDU CONTÉM ESTE VALOR• O CAMPO SPECIFIC-TRAP DA PDU CONTÉM ZERO

• CASO CONTRÁRO, É UM ENTERPRISE-SPECIFIC TRAP• O CAMPO GENERIC-TRAP DA PDU CONTÉM enterpriseSpecific(6)• O CAMPO SPECIFIC-TRAP DA PDU CONTÉM ESTE VALOR

• EXEMPLOS SEGUEM:coldStart TRAP-TYPE

ENTERPRISE snmp::= 0

fooTrap TRAP-TYPEENTERPRISE foo::= 45

OndecoldStart é um generic trap;e fooTrap é um enterprise-specific trap.

CONSIDERAÇÕES PARA TRAPS• TRAPS NÃO SÃO CONFIRMADOS (PODEM NÃO SER RECEBIDOS) E NÃO TÊM IDENTIFICAÇÃO ÚNICA

(NÃO TEM CAMPO REQUEST-ID NA PDU)• AGENTE NÃO SABE SE O GERENTE RECEBEU O TRAP• GERENTE NÃO SABE SE O TRAP É UMA DUPLICATA• NÃO HÁ FORMA DE GARANTIR A RECEPÇÃO DO TRAP

DICAS PARA CRIAR MIBs PROPRIETÁRIASPOR QUE CRIAR UMA MIB PROPRIETÁRIA?

• MIBs SNMP PADRÃO OFERECEM POUCOS OBJETOS PARA CONTROLAR DISPOSITIVOS• DEVIDO À FRACA SEGURANÇA DO SNMP (v1 E v2)

• PARA MONITORAR/CONTROLAR CARACTERÍSTICAS ESPECÍFICAS DOS DISPOSITIVOS DOFABRICANTE

• PARA ESTENDER AS MIBs PADRÃO E AUMENTAR A MONITORAÇÃO E CONTROLE

DEVE ADICIONAR NO GALHO enterprises.nomeDaEmpresaCOMO ORGANIZAR A ÁRVORE PROPRIETÁRIA?

• CADA FABRICANTE ORGANIZA COMO QUISER• A LINHA DE PRODUTOS DO FABRICANTE AFETA A ORGANIZAÇÃO DA ÁRVORE• UMA FORMA DE ORGANIZAÇÃO USA 4 GALHOS

• UM GALHO PARA REGISTRO DE OIDs DE PRODUTOS• PARA sysObjectID

• UM GALHO EXPERIMENTAL• PARA EXPERIMENTOS, DEMOS EM FEIRAS, ETC.

• UM GALHO PARA ESTENDER MIBs PADRÃO• PODE DUPLICAR A ÁRVORE mib-2 (SHADOW TREE)


• UM GALHO PARA MIBs PROPRIETÁRIAS ORGANIZADAS POR LINHA DE PRODUTO.

SMIv2DESCREVEMOS AS MUDANÇAS PRINCIPAIS NA SMIv2 COMPARADA COMSNMv1 DESCRITA ACIMAHÁ TRÊS TIPOS DE MÓDULOS

• MÓDULOS MIB• DEFINEM OBJETOS GERENCIADOS

• COMPLIANCE STATEMENTS• DESCREVEM OS REQUISITOS DOS NODOS GERENCIADOS COM RESPEITO A UMA OU MAIS

MIBs• VER À FRENTE

• CAPABILITY STATEMENTS• DESCREVEM QUÃO BEM UM NODO GERENCIADO PARTICULAR IMPLEMENTA OS OBJETOS

DE UMA OU MAIS MIBs• VER À FRENTE

A NOVA ÁRVORE DO SNMPv2

MÓDULOS SÃO MELHOR IDENTIFICADOS• EXEMPLO

snmpMIB MODULE-ENTITYLAST-UPDATED "9303040000Z"ORGANIZATION "IETF SNMPv2 Working Group"CONTACT-INFO

" Marshall T. Rose Postal: Dover Beach CONsulting, Inc. 420 Whisman Court Mountain View, CA 94043-2186 US Tel: +1 415 968 1052 Fax: +1 415 968 2510

E-mail: [email protected]"DESCRIPTION

"The MIB nodule for SNMPv2 entities."::= { snmpModules 1 }


• OBSERVE QUE MÓDULOS SÃO IDENTIFICADOS COM OIDs TAMBÉM EMiso.org.dod.internet.snmpV2.snmpModules (1.3.6.1.6.3)

• TAMBÉM PODE CONTER REVISÕES COM DATA E DESCRIÇÃO

sysObjectID MELHOR DEFINIDOS• OIDs DE PRODUTOS PODEM SER DEFINIDOS COM A MACRO OBJECT-IDENTITY

router2522 OBJECT-ODENTITYSTATUS currentDESCRIPTION

"The authoritative identity of the model 2522 router.":: = { routers 1 }

DEFINIÇÕES DE OBJETOS GERENCIADOS MUDARAM UM POUCO• UNITS DESCREVEM AS UNIDADES DO OBJETO

• USADO PARA O GERENTE MELHOR APRESENTAR A INFORMAÇÃO EM GRÁFICOS, ETC.• ACCESS VIROU MAX-ACCESS

• read-create (PODE LER, CRIAR, GRAVAR)• read-write (NÃO PODE SER CRIADO)• read-only (SÓ LEITURA)• accessible-for-notify (PODE USAR EM TRAPS APENAS: SÓ AGENTE ACESSA)• not-accessible (COMO ANTES)

• STATUS MUDOU UM POUCO• NÃO TEM mandatory E optional• SÓ TEM current, deprecated, obsolete

• INDEX MUDOU UM POUCO• EM STRINGS DE TAMANHO VARIÁVEL USADOS PARA FORMAR INSTÂNCIAS E COM O USO

DE INDEX {IMPLIED ...}, NÃO PRECISA DO PRIMEIRO BYTE (PARA FORÇAR A ÓRDEMLEXICOGRÁFICA A FAZER MAIS SENTIDO)

• SEM IMPLIED, UM STRING MENOR VIRIA SEMPRE ANTES DE UM MAIOR• CLÁUSULA AUGMENTS

• PARA CRIAR UMA TABELA QUE É UMA EXTENSÃO DE OUTRA TABELA• DEVE SEMPRE HAVER UMA LINHA NA NOVA TABELA PARA CADA LINHA NA

ANTIGA• SE NÃO HOUVER, É MELHOR USAR O MECANISMO ANTIGO COM INDEX

DEFINIÇÕES DE OBJETOS GERENCIADOS MUDARAM UM POUCO• A CLÁUSULA SYNTAX MUDOU

• PODE USAR BITS• SYNTAX BITS { readable(0), writable(1), creatable(2) }• CODIFICADOS COMO OCTET STRING

• VÁRIOS TIPOS ETIQUETADOS NOVOS• Counter32• Gauge32• Counter64 (SE Counter32 CAUSAR WRAP-AROUND EM MENOS E 1 HORA)• Unsigned32 (COMO Gauge32)

TEXTUAL CONVENTIONS FORMALIZADAS• EXEMPLO

DisplayString ::= TEXTUAL-CONVENTIONDISPLAY-HINT "255a"STATUS currentDESCRIPTION

"Represents textual information takenfrom the NVT ASCII character set, as defined in pages4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCIIrepertoire specifies:- the use of character codes 0-127 (decimal)- the graphics characters (32-126) are interpreted as US ASCII- NUL, LF, CR, BEL, BS, HT,VT and FF have the special

meanings specified in RFC 854- the other 25 codes have no standard interpretation- the sequence 'CR LF' means newline- the sequence 'CR NUL' means carriage-return- an 'LF' not preceded by a 'CR' means moving to the


same column on the next line.- the sequence 'CR x' for any x other than

LF or NUL is illegal.(Note that this also means that a string mayend with either 'CR LF' or 'CR NUL', but not with CR.)Any object defined using this syntax may not exceed255 characters in length."

SYNTAX OCTET STRING (SIZE (0..255))

VÁRIAS TEXTUAL CONVENTIONS PRÉ-DEFINIDAS NO MÓDULO SNMPv2-TC

• DisplayString• OCTET STRING (SIZE(0..255))

• PhysAddress• OCTET STRING

• MacAddress• OCTET STRING (SIZE(6))

• TruthValue• INTEGER { true(1), false(2) }

• TestAndIncr• INTEGER (0..2147483647)• UM SEMÁFORO PARA SINCRONIZAR APLICAÇÕES DE GERÊNCIA

• AO FAZER SET, SE O VALOR DADO FOR IGUAL AO VALOR ATUAL: OK E O VALOR ÉINCREMENTADO

• SENÃO RETORNA ERRO NO SET• TimeInterval

• INTEGER (0..2147483647)• PARA MEDIR A DIFERENÇA ENTRE TimeTicks)

• DateAndTime• PARA ESPECIFICAR UMA DATA/HORA

• E VÁRIAS OUTRAS CONVENÇÕES TEXTUAIS ...

DEFINIÇÃO DE TRAPS MUDOU• FINALMENTE, OS TRAPS TÊM OID

• IDENTIFICAÇÕES DE TRAPS SÃO HIERÁRQUICAS• TRÊS TRAPS FORAM DEFINIDOS

• coldStart• warmStart (OBJETOS NÃO MUDARÃO DE VALOR COM EXCEÇÃO DE sysUpTime E

CONTADORES)• authenticationFailure

• EXEMPLOlinkUp NOTIFICATION-TYPE

OBJECTS { ifIndex }STATUS currentDESCRIPTION

"A linkUp trap signifies that the SNMPv2 entity, acting in an agent role, recognizes that one of the communication links has come up."

::= { snmpTraps 4 }

EXEMPLO DE COMPLIANCE STATEMENT• USA O CONCEITO DE GRUPO DE OBJETOS DEFINIDOS FORMALMENTE

snmpCommunityGroup OBJECT-GROUP OBJECTS { snmpInBadCommunityNames, snmpInBadCommunityUses }

STATUS currentDESCRIPTION

"A collection of objects providing basic instrumentation of an SNMPv2 entity which supports community-based communication." ::= { snmpMIBGroups 2 }


snmpBasicCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for the SNMPv2 entities which implement the SNMPv2 MIB."

MODULE -- this module MANDATORY-GROUPS { snmpGroup, snmpSetGroup, systemGroup, snmpBasicNotificationsGroup } GROUP snmpCommunityGroup DESCRIPTION "The snmpCommunity group is mandatory only for those SNMPv2 entities which support community-based authentication." ::= { snmpMIBCompliances 1 }

• A ÁRVORE AQUI LOCALIZA PONTOS CHAVES DA ÁRVORE PARA O EXEMPLO ACIMA

CAPABILITY STATEMENT• DETALHA COMO UM AGENTE ESPECÍFICO SE COMPORTA• EXEMPLO

exampleAgent AGENT_CAPABILITIES PRODUCT-RELEASE "ACME Agent release 1.1 for Windows NT" STATUS current DESCRIPTION "..."

SUPPORTS IF-MIB INCLUDES {ifGeneralGroup } VARIATION ifAdminStatus DESCRIPTION "Unable to set test mode on Windows NT." SUPPORTS IP-MIB INCLUDES {ipGroup, icmpGroup }

VARIATION ipDefaultTTL SYNTAX INTEGER (255..255) DESCRIPTION "Hardwired in Windows NT." VARIATION ipInAddrErrors ACCESS not-implemented DESCRIPTION "Information not available on Windows NT." VARIATION ipRouteType SYNTAX INTEGER { direct(3), indirect(4) } WRITE-SYNTAX INTEGER{ invalid(2), direct(3), indirect(4) } DESCRIPTION "Information limited on Windows NT."

SUPPORTS TCP-MIB INCLUDES { tcpGroup } VARIATION tcpConnState ACCESS read-only DESCRIPTION "Unable to set this on Windows NT." ::= { acme-agents 1 }


O NÍVEL DE INSTRUMENTAÇÃO

MODELO OPERACIONAL: O PROTOCOLO SNMP

ITERAÇÕES DE PROTOCOLOAS ITERAÇÕES CONSISTEM GERALMENTE DE UM PEDIDO SEGUIDO DEUMA RESPOSTAAS PROTOCOL DATA UNITS (PDUs) (SNMPv2)

• TODAS AS PDUs TÊM O MESMO FORMATO MESMO QUE CERTOS CAMPOS NÃO SEJAM USADOS• OS CAMPOS:

• O TIPO• PEDIDOS: GET, GET-NEXT, GET-BULK• MODIFICAÇÕES: SET• RESPOSTAS: RESPONSE• TRAP• MANAGER-TO-MANAGER: INFORM

• REQUEST-ID• PARA A APLICAÇÃO ASSOCIAR RESPOSTAS A PEDIDOS

• ERROR-STATUS• SE NÃO ZERO, INDICA UM ERRO E QUE AS VARIABLE BINDINGS DEVEM SER

IGNORADAS• SÓ USADO EM RESPOSTAS

• ERROR-INDEX• SE NÃO ZERO, INDICA QUAL VARIÁVEL ESTÁ EM ERRO• SÓ USADO EM RESPOSTAS

• VARIABLE-BINDINGS• LISTA DE VARIÁVEIS COM UM NOME E UM VALOR

QUATRO POSSIBILIDADES PARA UM PEDIDO• RESPOSTA SEM ERRO OU EXCEÇÃO• RESPOSTA COM UMA OU MAIS EXCEÇÕES• RESPOSTA COM ERRO• TIMEOUT

REPOSTA SEM ERRO• PEDIDO VAI CONTENDO:

• UM REQUEST-ID ÚNICO• ERROR-STATUS E ERROR-INDEX IGUAIS A ZERO• ZERO OU MAIS VARIABLE BINDINGS COM AS VARIÁVEIS CONTENDO O VALOR unSpecified

• SE A OPERAÇÃO NÃO FOR TRAP, A RESPOSTA VEM COM• O MESMO REQUEST-ID• ERRO-STATUS = 0• OS MESMOS VARIABLE BINDINGS COM OS VALORES CORRETOS PREENCHIDOS

• SE A OPERAÇÃO NÃO FOR DE ACESSO, OS VARIABLE BINDINGS VOLTAM COM OS MESMOSVALORES DE VARIÁVEIS

REPOSTA COM EXCEÇÃO• O VALOR DE QUALQUER UMA (OU MAIS) DAS VARIÁVEIS PODE CONTER:

• noSuchObject (VARIÁVEL NÃO É IMPLEMENTADA PELO AGENTE)• noSuchInstance (A INSTÂNCIA PEDIDA NÃO EXISTE)• endOfMIBView (COM GET-NEXT, SIGNIFICA QUE NÃO TEM MAIS INFORMAÇÃO)

• NO SNMPv1, NÃO TEM EXCEÇÃO• OS CASOS ACIMA GERAM O ERRO noSuchInstance

REPOSTA COM ERRO• ERROS SE APLICAM À OPERAÇÃO INTEIRA• OS ERROS POSSÍVEIS SÃO:

• tooBig (A REPOSTA NÃO CABE NA PDU DE RESPOSTA)• genErr (ERRO GERAL NÃO ESPECIFICADO INDICANDO QUE O PEDIDO NÃO FOI PROCESSADO)


• TEM OUTROS ERROS POSSÍVEIS PARA SET• VER ADIANTE

DETALHES ADICIONAIS PARA A OPERAÇÃO GET-NEXT• OIDs SÃO CONSIDERADAS ORDENADAS LEXICOGRAFICAMENTE

• ALGUNS AGENTES TÊM BUGS!• GET-NEXT RETORNA A PRÓXIMA INSTÂNCIA

• get-next( {sysDescr, unSpecified} ) RETORNA• sysDescr.0 E SEU VALOR• OBSERVE QUE PODE-SE FAZER GET-NEXT DE UM OBJETO OU DE UMA INSTÂNCIA

• GET-NEXT PODE SER USADO PARA VER SE UM DETERMINADO OBJETO É SUPORTADO PELOAGENTE

• A OPERAÇÃO DE ENCAMINHAMENTO (TRAVERSAL, WALK) RESULTA DA APLICAÇÃO REPETIDA DEGET-NEXT COM O VALOR RETORNADO PELO GET-NEXT ANTERIOR

• AO CAMINHAR NUMA TABELA, CADA INSTÂNCIA DA PRIMEIRA COLUNA É RETORNADA, DEPOISDA SEGUNDA COLUNA, ETC.

• GET-NEXT PODE CONTER VÁRIAS VARIÁVEIS:

get-next( {ipRouteDest, unSpecified} ) --> ipRouteDest.0.0.0.0 (supõe rota default instalada)

get-next( {ipRouteDest.0.0.0.0, unSpecified} ) --> ipRouteDest.192.33.4.0

get-next( {ipRouteDest.192.33.4.0, unSpecified} ) --> ipRouteIfIndex.0.0.0.0

get-next( {ipRouteDest, unSpecified} {ipRouteIfIndex, unSpecified} {ipRouteNextHop, unSpecified}) --> ipRouteDest.0.0.0.0 ipRouteIfIndex.0.0.0.0 ipRouteNextHop.0.0.0.0

DETALHES ADICIONAIS PARA A OPERAÇÃO GET-BULK• EQUIVALENTE A VÁRIOS GET-NEXT• EXISTE POR RAZÕES DE EFICIÊNCIA (SÓ NO SNMPv2)

• APROXIMADAMENTE 10 VEZES MAIS EFICIENTE PARA VARRER GRANDES TABELAS• OS CAMPOS:

• request-id• non-repeaters (NÚMERO DE VARIÁVEIS A RECUPERAR UMA ÚNICA VEZ)• max-repetitions (NÚMERO MÁXIMO QUE OUTRAS VARIÁVEIS SERÃO RETORNADAS)• variable-bindings (INICIAM COM AS VARIÁVEIS non-repeaters)

• GET-BULK PODE TERMINAR ANTES DE PREENCHER TUDO QUE FOI PEDIDO• GARANTE NÃO RETORNAR tooBig

• EXEMPLO

get-bulk [non-repeaters = 1, max-repetitions = 2] ({sysUpTime, unSpecified} {ipNetToMediaPhysAddress, unSpecified} {ipNetToMediaType, unSpecified}) --> ({sysUpTime.0, 123456}, {ipNetToMediaPhysAddress.1.9.2.3.4, "000010543210"}, {ipNetToMediaType.1.9.2.3.4, dynamic}, {ipNetToMediaPhysAddress.1.10.0.0.51, "000010012345"}, {ipNetToMediaType.1.1.10.0.0.51, static})

DETALHES ADICIONAIS PARA A OPERAÇÃO SET• A OPERAÇÃO É ATÔMICA

• SE RETORNAR OK, TODAS AS VARIÁVEIS FORAM MODIFICADAS• O AGENTE TEM QUE USAR UM ALGORITMO TWO-PHASE COMMIT OU ALGO SEMELHANTE PARA

GARANTIR A SEMÂNTICA DE ATOMICIDADE• NO PRIMEIRO PASSO, O AGENTE PODE VERIFICAR QUE:


• A VARIÁVEL EXISTE• O AGENTE PODE MODIFICAR INSTÂNCIAS DO OBJETO• O VALOR É SINTATICAMENTE CORRETO• SE A VARIÁVEL NÃO EXISTE, O AGENTE PODE CRIAR INSTÂNCIAS DO OBJETO• OS NOMES E VALORES SÃO SEMANTICAMENTE CORRETOS E CONSISTENTES COM OUTROS

VALORES NO PEDIDO• TODOS OS RECURSOS NECESSÁRIOS PARA FAZER A MUDANÇA SÃO TRAVÁVEIS

DETALHES ADICIONAIS PARA A OPERAÇÃO SET• SNMPv1 NÃO RETORNAVA UMA INDICAÇÃO DO TIPO DE ERRO QUE OCORREU, MAS SNMPv2 PODE

RETORNAR:• ERROS PERMANENTES

• noAccess (VARIÁVEL NÃO EXISTE)• noCreation• notWritable

• ERROS DE PROGRAMAÇÃO• wrongType (TIPO ASN.1 ERRADO)• wrongLength• wrongEncoding (CODIFICAÇÃO ASN.1 ERRADA)• wrongValue (FORA DE FAIXA)

• ERROS TRANSIENTES• inconsistentName (NÃO PODE CRIAR POR RAZÕES DE CONSISTÊNCIA COM OUTROS

OBJETOS GERENCIADOS NO AGENTE)• inconsistentValue• resourceUnavailable (NÃO PODE RESERVAR UM RECURSO)

• NO SEGUNDO PASSO, PODE TER MAIS DOIS ERROS (GRAVES!):• commitFailed (AS MUDANÇAS FORAM DESFEITAS)• undoFailed (AS MUDANÇAS NÃO FORAM DESFEITAS)

• FINALMENTE: CUIDADO COM IDEM POTÊNCIA!

DETALHES ADICIONAIS PARA A OPERAÇÃO SET: CRIAÇÃO E REMOÇÃODE LINHAS CONCEITUAIS

• TEM UMA CONVENÇÃO TEXTUAL (RowStatus) QUE AJUDA A GERENCIAR ISSO• TEM MUITOS DETALHES PARA USO CORRETO E APRESENTAMOS APENAS OS PRINCIPAIS

RowStatus ::= TEXTUAL-CONVENTION ... SYNTAX INTEGER { -- two state/action values, may be read or written active(1), notInService(2),

-- a state value, may only be read notReady(3),

-- three action values, may only be written createAndGo(4), createAndWait(5), destroy(6) }

DUAS FORMAS DE CRIAR UMA LINHA• ONE SHOT

• O GERENTE FAZ UM GET COM AS COLUNAS OBRIGATÓRIAS (ÍNDICES) E COLOCAcreateAndGo NA COLUNA status

• QUANDO A LINHA ESTIVER OK, O AGENTE AUTOMATICAMENTE COLOCA active NO STATUS• NEGOCIADO (PARA FAZER A CRIAÇÃO EM PARTES)

• O AGENTE NÃO É OBRIGADO A ACEITAR CRIAR AS LINHAS DESTA FORMA• O GERENTE COLOCA createAndWait NA COLUNA status DA INSTÂNCIA A SER CRIADA• O AGENTE COLOCA notReady NO status• O GERENTE VAI USANDO SET (OU QUALQUER OUTRA OPERAÇÃO) ATÉ TERMINAR DE

CRIAR A COLUNA


• QUANDO O AGENTE COLOCAR O VALOR DO status EM notInService, ELE INDICA QUE JÁ TEMCOLUNAS SUFICIENTES E QUE A LINHA PODE SER USADA (ELA EXISTE NO DISPOSITIVO,NÃO SÓ NA REPRESENTAÇÃO MIB)

• O GERENTE COLOCA active NO status• PARA DESTRUIR UMA COLUNA, O GERENTE COLOCA destroy NO status

DETALHES ADICIONAIS PARA A OPERAÇÃO TRAP• NO SNMPv1, A PDU É DIFERENTE• NO SNMPv2, A PDU É IDÊNTICA ÀS DEMAIS• OS PRIMEIROS DOIS BINDINGS SÃO SEMPRE:

• (NAME=sysUpTime.0; VALOR=TEMPO LOCAL DE GERAÇÃO DO TRAP)• (NAME=snmpTrapOID.0; VALOR=IDENTIFICAÇÃO DO TRAP)

• EXEMPLO, com O TRAP linkUp MOSTRADO ANTERIORMENTE, SE A INTERFACE #7 ENTRAR NO AR0.06 SEGUNDOS DEPOIS QUE O AGENTE ENTRAR NO AR, OS VARIABLE BINDINGS SERIAM:

• { sysUpTime.0, 6 }• { snmpTrapOID.0, linkUp },• { ifIndex.7, 7 }

DETALHES ADICIONAIS PARA A OPERAÇÃO INFORM• PARA COMUNICAÇÃO GERENTE-A-GERENTE

• PARA GANHAR ESCALABILIDADE• SNMP NUNCA FOI FELIZ NESSA ÁREA• MUITO POUCO USADO

TRANSPORT MAPPINGSENVOLVE A CAMADA DE TRANSPORTE, ENDEREÇAMENTO E CODIFICAÇÃO DE MENSAGENS

MAPPING PARA UDP• AGENTES ESCUTAM NA PORTA UDP 161• AGENTES ENVIAM TRAPS PARA A PORTA UDP 162• MENSAGENS DE PELO MENOS 1472 BYTES DEVEM SER ACEITAS POR QUALQUER ENTIDADE DE

PROTOCOLO

BASIC ENCODING RULES (BER)COMO SERIALIZAR OS TIPOS DE DADOS DA ASN.1?O ALGORITMO PRODUZ UMA CODIFICAÇÃO COMPACTA MAS USA CAMPOS DE TAMANHO VARIÁVEL OQUE COMPLICA O CÓDIGO

• É O ÚNICO PROTOCOLO DA FAMÍLIA TCP/IP QUE FAZ ISSO!• SE FOI UMA BOA IDÉIA OU NÃO GERA CONTROVÉRSIA ATÉ HOJE

PARA ENTENDER AS REGRAS, LEMBRE QUE UM TIPO COMPLEXO EM ASN.1 NADA MAIS É DO QUE UMACOLEÇÃO DE TIPOS MENOS COMPLEXOS

• A DECOMPOSIÇÃO GRADUAL CHEGA EVENTUALMENTE A TIPOS SIMPLES COMO INTEGERCADA TIPO ASN.1 É CODIFICADO COM 3 CAMPOS:

• UM TAG QUE INDICA O TIPO ASN.1• UM TAMANHO QUE ESPECIFICA O TAMANHO DA CODIFICAÇÃO QUE SEGUE• UM VALOR

CADA UM DESSES CAMPOS É DE TAMANHO VARIÁVEL!

ORDEM DOS BITS• O BIT MAIS SIGNIFICATIVO DE UM BYTE VAI PARA A REDE PRIMEIRO (BIG-ENDIAN)


REPRESENTAÇÃO NUMÉRICA• QUALQUER NÚMERO COM SINAL É REPRESENTADO EM COMPLEMENTO DE DOIS, MAS COM O

NÚMERO MÍNIMO DE BYTES POSSÍVEL• NUNCA HÁ SEQUÊNCIA INICIAL DE 9 OU MAIS BITS 0 OU 1

• QUALQUER NÚMERO SEM SINAL É REPRESENTADO NORMALMENTE EM BINÁRIO COM O NÚMEROMÍNIMO DE BYTES

O CAMPO TAG• NA DISCUSSÃO DE SMI, NÃO FALAMOS DE TAGS ASN.1• CADA TIPO ASN.1 TEM UM TAG DE UMA DAS SEGUINTES CLASSES:

• UNIVERSAL (PARA TIPOS DE DADOS BEM CONHECIDOS TAIS COMO INTEGER, OCTETSTRING, OBJECT IDENTIFIER)

• APPLICATION-WIDE (PARA TIPOS DEFINIDOS NUM MÓDULO ASN.1 ESPECÍFICO TAIS COMOCounter32)

• CONTEXT-SPECIFIC (PARA USO EM TIPOS CONSTRUÍDOS COMO SEQUENCE)• PRIVATE-USE, PARA USO CONSENSUAL ENTRE PARTES

O CAMPO TAG• O TAG TAMBÉM TEM UM NÚMERO ÚNICO NA SUA CLASSE, POR EXEMPLO:

• Counter32 [APPLICATION 1] IMPLICIT INTEGER (0..4294967295)• ASN.1 TEM TIPOS SIMPLES E CONSTRUÍDOS (COMO SEQUENCE)• COMBINANDO TUDO ISSO, A CODIFICAÇÃO DO TAG É COMO SEGUE:

• OBSERVE QUE AO ESCREVER UMA MIB, NÃO SE PODE CRIAR NOVOS TIPOS ETIQUETADOS• PORQUE ELES AFETAM A CODIFICAÇÃO E FAZEM PORTANTO PARTE DO PADRÃO QUE

AMBOS OS LADOS DEVEM CONHECER• NÓS POBRES MORTAIS NÃO PODEMOS ALTERAR O PADRÃO INTRODUZINDO UMA NOVA

CODIFICAÇÃO

O CAMPO TAG• COMO SÓ TEM 5 BITS PARA O NÚMERO DO TAG, O VALOR É CODIFICADO DIRETAMENTE SE FOR

MENOR QUE 31• SE FOR MAIOR OU IGUAL A 31, USA-SE 11111 NESTE LUGAR E OS PRÓXIMOS BYTES CONTÊM O

NÚMERO DO TAG• CADA OCTETO USA 7 BITS PARA FORMAR O NÚMERO DO TAG, COM O PRIMEIRO BIT DE

CADA OCTETO SENDO 1 (E 0 PARA O ÚLTIMO)


O CAMPO TAMANHO

• SE O TAMANHO FOR MENOR QUE 128, USA-SE UM ÚNICO BYTE:

• SE O TAMANHO FOR MAIOR OU IGUAL A 128, USA-SE UM BYTE DIZENDO QUANTOS BYTES SEGUEMPARA CODIFICAR O TAMANHO

• TODOS OS BYTES SEGUINTES SÃO CONCATENADOS PARA DAR O TAMANHO

VAMOS PASSAR PARA O CAMPO VALORO TIPO SIMPLES INTEGER

• USA COMPLEMENTO DE 2• NÃO TEM SEQUÊNCIA INICIAL DE 9 OU MAIS 0s OU 1s

• EXEMPLO: O INTEIRO 100

O TIPO SIMPLES OCTET STRING• ZERO OU MAIS BYTES DE VALOR• EXEMPLO PARA "anon"

O TIPO SIMPLES BITS• CODIFICADO COMO COMO OCTET STRING• EXEMPLO: '101'B

O TIPO SIMPLES NULL• TAG ESPECIAL E TAMANHO 0


O TIPO SIMPLES OBJECT IDENTIFIER• TAG UNIVERSAL 6• PRIMEIROS 2 COMPONENTES (a.b) SÃO JUNTADOS NO PRIMEIRO BYTE COM 40a+b

• ESTRANHEZAS DA ISO!

• EXEMPLO: 1.0.8571.5.1

OS TIPOS CONSTRUÍDOS SEQUENCE E SEQUENCE OF• USA A FORMA CONSTRUCTED (F = 1 NO TAG)• BASTA GERAR O TAG E TAMANHO E CODIFICAR CADA ELEMENTO UM APÓS O OUTRO

• EXEMPLO DE UMA SEQUÊNCIA COM 2 ELEMENTOS

OS TIPOS ETIQUETADOS• SMI USA TIPOS ETIQUETADOS PARA REPRESENTAR VÁRIAS COISAS, POR EXEMPLO: TODAS AS

PDUs SÃO DO MESMO TIPO (PDU) MAS COM TAGS DIFERENTES (O QUE PERMITE DIFERENCIA-LAS)• TAGS TAMBÉM SÃO USADOS EM OUTROS PONTOS DA SMI

• TEM DOIS TIPOS DE TAGS: IMPLICIT E NÃO IMPLICIT• EXEMPLO DE TAG IMPLICIT:

• NovoTipo ::= [tag] IMPLICIT TipoOriginal• BASTA COdIFICAR COMO TipoOriginal MAS COM O NOVO TAG

• EXEMPLO DE TAG NÃO IMPLICIT• NovoTipo ::= [tag] TipoOriginal• CODIFICA O TipoOriginal NUM ENVELOPE COM OUTRO TAG• EXEMPLO PARA NovoTipo ::= [APPLICATION 7] TipoOriginal


UM EXEMPLO COMPLETO DE CODIFICAÇÃO BER• PRECISAREMOS ENTENDER PRIMEIRO COMO UMA MENSAGEM DO PROTOCOLO É FORMADA

Message ::= SEQUENCE { version INTEGER { snmpV1(0), current(1) }, community OCTET STRING, data PDUs } PDUs ::= CHOICE { get-request [0] IMPLICIT PDU, get-next-request [1] IMPLICIT PDU, response [2] IMPLICIT PDU, set-request [3] IMPLICIT PDU, -- tag [4] is obsolete get-bulk-request [5] IMPLICIT PDU, inform-request [6] IMPLICIT PDU, trap [7] IMPLICIT PDU } max-bindings INTEGER ::= 2147483647 PDU ::= SEQUENCE { request-id Integer32, error-status INTEGER { noError(0), tooBig(1), ... }, error-index INTEGER (0..max-bindings), variable-bindings VarBindList } VarBindList ::= SEQUENCE (SIZE(0..max-bindings)) OF VarBind VarBind ::= SEQUENCE { name ObjectName, CHOICE { value ObjectSyntax, unSpecified NULL, noSuchObject [0] IMPLICIT NULL, noSuchInstance [1] IMPLICIT NULL, endOfMibView [2] IMPLICIT NULL } }

UM EXEMPLO COMPLETO DE CODIFICAÇÃO BER - 2• SUPÕE A SEGUINTE MENSAGEM (UM RESPONSE SNMP)

example MSG ::= { version 0, community "public", response { request-id 17,


error-status noError, error-index 0, variable-bindings { { name 1.3.6.1.2.1.1.1.0 value "unix" } } } }

• CONCEITUALMENTE, PODEMOS TRADUZIR ISSO PARA OS TIPOS SIMPLES E CONSTRUÍDOS DAASN.1:

{ 0, "public", [2] { 17, 0, 0, { { 1.3.6.1.2.1.1.1.0 "unix" } } } }

• ESTA FORMA PERMITE VISUALIZAR MELHOR O QUE DEVE SER CODIFICADO

UM EXEMPLO COMPLETO DE CODIFICAÇÃO BER - 3• VAMOS CODIFICAR UMA SEQUÊNCIA E OS PRIMEIROS DOIS ELEMENTOS (VERSÃO E COMMUNITY):

• OBSERVE QUE O TAMANHO TOTAL JÁ DEVE SER CONHECIDO• POR ISSO, IMPLEMENTAÇÕES FREQUENTEMENTE CODIFICAM AO CONTRÁRIO E INVERTEM

NO FIM

UM EXEMPLO COMPLETO DE CODIFICAÇÃO BER - 4• AGORA, VAMOS CODIFICAR UM TIPO PDU DO TIPO RESPONSE DEFINIDO NO MÓDULO SNMPv2-SMI• ISTO É UM TIPO ETIQUETADO [2] COM A PALAVRA IMPLICIT

• PORTANTO, VAMOS CODIFICAR O TIPO ORIGINAL (PDU)• PDU É UMA SEQUÊNCIA, MAS USAREMOS O NOVO TAG (2)

• INICIAMOS GERANDO O TAG E TAMANHO• SÓ SABEMOS O TAMANHO NO FIM MAS AQUI JÁ COLOCAMOS O VALOR 29


• EM SEGUIDA, COLOCAMOS OS CAMPOS request-id, error-status e error-index QUE SÃO TODOS INTEIROS

UM EXEMPLO COMPLETO DE CODIFICAÇÃO BER - 5• FINALMENTE, TEMOS AS VARIABLE BINDINGS

• É UM VALOR DO TIPO SEQUENCE OF E PODEMOS INICIAR GERANDO OS CAMPOS DE TAG ETAMANHO

• CADA ELEMENTO (SÓ TEM UM) É UM VALOR DO TIPO VarBind QUE É UMA SEQUÊNCIA• PRIMEIRO GERA O TAG E TAMANHO

• O PRIMEIRO COMPONENTE DA SEQUÊNCIA CONTÉM UM OBJECT IDENTIFIER (1.3.6.1.2.1.1.1.0)


UM EXEMPLO COMPLETO DE CODIFICAÇÃO BER - 6

• O SEGUNDO COMPONENTE DA SEQUÊNCIA É UM ObjectValue (QUE É OCTET STRING)

• OS 44 BYTES FINAIS GERADOS SÃO OS SEGUINTES (EM HEXADECIMAL):

30 2a 02 01 00 04 06 70 75 62 6c 69 63 a2 1d 02 01 11 02 01 00 02 01 00 30 12 30 10 06 08 2b 06 01 02 01 01 01 00 04 04 75 6e 69 78

O NÍVEL DE INSTRUMENTAÇÃOCONSIDERAÇÕES DE IMPLEMENTAÇÃO

FONTES DE INFORMAÇÃO E CÓDIGOUNIX

• MUITAS IMPLEMENTAÇÕES DISPONÍVEIS GRATIS• INCLUI AGENTES, GERENTES, COMPILADORES, ETC.

• COMPILADOR MAIS USADO É SMICNG• VER LISTA AQUI• IMPLEMENTAÇÃO COMPLETA COMENTADA DE AGENTE E GERENTE SNMPv1 NO LIVRO DE COMER

(INTERNETWORKING WITH TCP/IP - VOL II)

JAVA• JAVA DYNAMIC MANAGEMENT KIT (JDMK) DA SUN


• INCLUI JAVA MANAGEMENT EXTENSIONS (JMX; EX-JMAPI)• VERSÃO VELHA DA JMAPI (MAS GRÁTIS) ESTÁ AQUI

FONTES DE INFORMAÇÃO E CÓDIGOWINDOWS

• MICROSOFT TEM DOIS PACOTES• MANAGEMENT API (MGMTAPI)• WINSNMP

• AMBAS AS SOLUÇÕES ESCONDEM O TRATAMENTO DE:• PROTOCOLO SNMP• ASN.1• BASIC ENCODING RULES

• MANAGEMENT API• PARA WINDOWS 95 (PARCIALMENTE) E WINDOWS NT (>= 3.1)• TEM UM COMPILADOR DE MIBs (MIBCC.EXE) QUE GERA UM ARQUIVO (MIB.BIN)

CONSULTADO PELA BIBLIOTECA• PERMITE CRIAR "EXTENSION AGENTS" ATRAVÉS DO "EXTENDIBLE AGENT"

• EXTENSION AGENT É UMA DLL CRIADA PELO DESENVOLVEDOR PARA DARSUPORTE A UMA NOVA MIB

• SÓ PARA WINDOWS NT• WINSNMP

• APENAS PARA WINDOWS NT 5.0• A VERSÃO 1.1a SÓ TEM SUPORTE PARA GERENTES• A VERSÃO 2.0 PERMITE DESENVOLVER AGENTES• SUPORTA SNMPv1 E SNMPv2 E CONVERTE AUTOMATICAMENTE DE SNMPv2 PARA SNMPv1

USANDO AS REGRAS DA RFC1908

USO DO PROTOCOLO SNMP EM JAVA:UMA API E UM GERENTE

• LEMBRE QUE JMAPI FOI SUBSTITUIDO POR JMX E QUE A API JMX PODERÁ SER UM POUCODIFERENTE

• EXEMPLOS E DOCUMENTAÇÃO AQUI• ACOMPANHE O EXEMPLO getExample.java ENQUANTO LÊ A INFORMAÇÃO ABAIXO

• AS CLASSES E MÉTODOS DISCUTIDOS AQUI SÃO APENAS AQUELES QUE APARECEM NOEXEMPLO

• CONSULTE A DOCUMENTAÇÃO PARA DETALHES

INICIALIZAÇÃO E FINALIZAÇÃO• SnmpMain

• initializeSNMP()• INICIALIZA OS SERVIDORES NECESSÁRIOS PARA A OPERAÇÃO DO PACOTE

• SnmpSession• CRIA, CONTROLE E GERENCIA UM OU MAIS PEDIDOS• setDefaultPeer(SnmpPeer)

• SE TODOS OS PEDIDOS SE COMUNICAREM COM O MESMO PAR (O OUTRO LADO), OPAR PODE SER ESPECIFICADO AQUI PARA ELIMINAR O PARÂMETRO "PEER" NOSPEDIDOS

• snmpGet(SnmpPeer, SnmpHandlerIf, SnmpVarbindList)• O SnmpHandlerIf PODE INDICAR UM HANDLER CONTENDO MÉTODOS DE CALLBACK

QUANDO O GET É ASSÍNCRONO• snmpGetNext(SnmpPeer, SnmpHandlerIf, SnmpVarbindList)• destroySession()

• DESTROI PEDIDOS PENDENTES E PÁRA A SESSÃO• SnmpPeer

• CRIA UM OBJETO QUE REPRESENTA O PAR• O CONSTRUTOR FORNECER O NOME (DNS OU IP) DO PAR COMO STRING• setSnmpParam(SnmpParameters)


• ASSOCIA PARÂMETROS A UM OBJETO PAR• PARÂMETROS PODEM SER: ENDEREÇO IP, PORTA, NOME DE COMUNIDADE READ E

WRITE, VALORES DE RETRY E TIMEOUT, ETC.)• SnmpParameters

• O CONSTRUTOR ACEITA, POR EXEMPLO, OS NOMES DE COMUNIDADES "READ" E "WRITE"COMO PARÂMETROS

• O OBJETO RESULTADO É USADO COM SnmpPeer.setSnmpParam• EXEMPLO DE INICIALIZAÇÃO E FINALIZAÇÃO

SnmpSession session = new SnmpSession("Uma instância de sessão");SnmpPeer agentInfo = new SnmpPeer("cpsw.campus-ii.ufpb.br");// comunidades read e writeSnmpParameters param = new SnmpParameters("ufpbnet", "naosei");// associa os parametros ao agenteagentInfo.setSnmpParam(param);session.setDefaultPeer(agentInfo);... // faz pedidos, trata respostassession.destroySession();

CRIAÇÃO DE VARIABLE BINDINGS LIST• SnmpVar

• REPRESENTA UMA VARIÁVEL MIB (OID E VALOR)• O CONSTRUTOR FORNECE O NOME DO OBJETO (EX. sysDescr)• addInstance(...)

• TRANSFORMA A OID DE UM OBJETO NUMA OID DE INSTÂNCIA (CONCATENANDOUM INTEIRO, ARRAY DE INTEIROS OU UM STRING)

• SnmpVarbindList• CRIA UMA VARIABLE BINDINGS LIST A PARTIR DE UMA OU MAIS VARIÁVEIS (SnmpVar)• addVariable(SnmpVar)

• ADICIONA UMA NOVA VARIÁVEL A UMA VARIABLE BINDINGS LIST• EXEMPLO DE CRIAÇÃO DE VARIABLE BINDINGS LIST

SnmpVar aOctetVar = new SnmpVar("sysDescr");aOctetVar.addInstance(0);SnmpVarbindList varBindList = new SnmpVarbindList();varBindList.addVariable(aOctetVar);

FAZENDO UM PEDIDO GET• SnmpSession

• CRIA, CONTROLE E GERENCIA UM OU MAIS PEDIDOS• snmpGet(SnmpPeer, SnmpHandlerIf, SnmpVarbindList)

• O SnmpHandlerIf PODE INDICAR UM HANDLER CONTENDO MÉTODOS DE CALLBACKQUANDO O GET É ASSÍNCRONO

• snmpGetNext(SnmpPeer, SnmpHandlerIf, SnmpVarbindList)• SnmpRequest

• CRIA UM PEDIDO PARA USO POSTERIOR COM GET, GET-NEXT, GET-BULK OU SET• A CLASSE CONTROLAR O TRATAMENTO DO PEDIDO (RETRY, TIMEOUTS, PROCESSAMENTO

DE RESPOSTAS)• O USUÁRIO É AVISADO DO TRATAMENTO ATRAVÉS DE MÉTODOS CALLBACK

ESPECIFICADOS PELO USUÁRIO• UMA SUBCLASSE SnmpPollRequest PODE FAZER PEDIDOS REGULARES AUTOMATICAMENTE• A QUEBRA DA VARIABLE BINDINGS LIST EM PEDIDOS SERÁ AUTOMATICAMENTE FEITA

PELO PACOTE• PODE-SE AINDA INFORMAR COMO SITUAÇÕES DE ERRO DEVEM SER TRATADAS• REQUEST IDs NECESSÁRIAS PARA CASAR PEDIDOS COM RESPOSTAS SÃO

AUTOMATICAMENTE ESCOLHIDOS• waitForCompletion(long)

• PARA O PROGRAMA OPERAR SINCRONAMENTE COM O PEDIDO• getErrorStatus()

• RETORNA O STATUS ASSOCIADO AO PEDIDO• getErrorIndex()

• RETORNA O INDEX DO ERRO ASSOCIADO AO PEDIDO


• EXEMPLO DE PEDIDO GET

SnmpRequest umPedido = session.snmpGet(agentInfo, null, varBindList);boolean terminou = umPedido.waitForCompletion((long) 10000);// verifica timeout para o pedidoif(!terminou) { System.out.println("timeout no pedido"); System.exit(0);}

int errorStatus = umPedido.getErrorStatus();if (errorStatus != SnmpStatusEnums.snmpRspNoError) { System.out.print("Error Status = "); System.out.println(SnmpDebug.snmpErrorToString(errorStatus)); System.out.print("Error Index = "); System.out.println(umPedido.getErrorIndex()); System.exit(0);}

ANALIZANDO A RESPOSTA• SnmpRequest

• getResponseVbList• RETORNA A VARIABLE BINDINGS LIST QUE ESTÁ NA RESPOSTA ASSOCIADA AO

PEDIDO• EXEMPLO DE ANÁLISE (SIMPLES) DA RESPOSTA

SnmpVarbindList resultadoVBList = umPedido.getResponseVbList();System.out.println("resultado = " + resultVBList);

INTRODUZINDO NOVOS OIDs NA MIB CONHECIDA PELOPACOTE

• O PACOTE JÁ CONHECE ALGUNS OIDs (MAPEAMENTO NOME DE/PARA OID)• TEM UM SUPORTE MUITO INCIPIENTE PARA O TRATAMENTO DE MIBs

• NÃO PODE ACESSAR TODOS OS ATRIBUTOS DE UM OBJETO (SYNTAX, ACCESS,DESCRIPTION, ...)

• NÃO TEM COMPILADOR MIB• COMPILADOR TRANSFORMA O TEXTO DA MIB NUMA REPRESENTAÇÃO ÚTIL PARA

ALGUM PACOTE• PODE SER REPRESENTAÇÃO BINÁRIA EM ARQUIVO PARA CARGA POR UMA

APLICAÇÃO• PODE SER ESQUELETO DE CÓDIGO PARA DEFINIR A MIB NUMA CERTA

LINGUAGEM• TEM ALGUNS MÉTODOS QUE AJUDAM UM POUCO• MibStore

• MANTÉM UM BANCO DE DADOS DE OBJETOS

• ATRIBUTOS MANTIDOS:

• NOME

• OID (UM STRING COM NÚMEROS SEPARADOS POR PONTO)

• O TIPO SMI DA VARIÁVEL

• loadMib(String[][])

• CARREGA UMA LISTA DE DEFINIÇÕES DE OBJETOS NA MIB EM MEMÓRIA

• O ARRAY BI-DIMENSIONAL CONTÉM UMA LINHA PARA CADA OBJETO

• A LINHA CONTÉM 3 ATRIBUTOS: NOME, OID E TIPO, ONDE TIPO PODE SER:


• I = IntegerC = CounterT = TimeTicksG = GaugeS = Octet StringO = Object IDIP = IP Address

• EXEMPLO DE EXTENSÃO À MIB

String mibSupplement [] [] = { { "ifNumber", ".1.3.6.1.2.1.2.1", "I" }, { "ifOutOctets", ".1.3.6.1.2.1.2.2.1.16", "C"}};

MibStore.loadMib(mibSupplement);

MANIPULAÇÃO DA VARIABLE BINDINGS LIST• SnmpVarbindList

• indexOfOid(SnmpVar)• ACHA O ÍNDICE DA VARIÁVEL INDICADA NA VARIABLE BINDINGS LIST DA

RESPOSTA• getSnmpVarAt(int)

• RETORNA A VARIÁVEL PRESENTE NA RESPOSTA NO ÍNDICE INDICADO• SnmpVar

• getIntegerValue()• RETORNA O VALOR DE UMA VARIÁVEL COMO UM INTEIRO

• EXEMPLO DA MANIPULAÇÃO DA VARIABLE BINDINGS LIST varBindList = new SnmpVarbindList(); SnmpVar ifNumber = new SnmpVar("ifNumber"); ifNumber.addInstance(0); varBindList.addVariable(ifNumber);

umPedido = session.snmpGet(agentInfo, null, varBindList); completed = umPedido.waitForCompletion((long) 10000); if(!completed) { ... }

errorStatus = umPedido.getErrorStatus(); if (errorStatus != SnmpStatusEnums.snmpRspNoError) { ... }

int númeroDeInterfaces = 0; resultVBList = umPedido.getResponseVbList();

// achar a SnmpVar na varbind list resultante

int vBIndex = resultVBList.indexOfOid(ifNumber); SnmpVar ifNumberResult = resultVBList.getSnmpVarAt(vBIndex); númeroDeInterfaces = ifNumberResult.getIntegerValue();

FAZENDO E TRATANDO UM PEDIDO GET-NEXT• SnmpVar

• SnmpVar.getOid()• RETORNA O SnmpOid ASSOCIADO À VARIÁVEL

• SnmpVar.getOctet()• RETORNA UM OBJETO DO TIPO SnmpOctet PARA O VALOR ASSOCIADO À VARIÁVEL

• SnmpVar.getCounter32()• RETORNA UM OBJETO DO TIPO SnmpCounter32 PARA O VALOR ASSOCIADO À

VARIÁVEL• SnmpOctet

• ARMAZENA UM VALOR DO TIPO SMI "OCTET STRING"• SnmpCounter32

• ARMAZENA UM VALOR DO TIPO SMIv2 "Counter32" (OU SMIV1 Counter)


• SnmpOid• UMA CLASSE QUE CONSTROI E MANIPULA IDENTIFICADORES DE OBJETOS• isASubset(SnmpOid)

• IDENTIFICA SE O OID DADO NO PARÂMETRO É UM SUBCONJUNTO DE this• SnmpVarbindList

• getVarbindEnumeration()• UMA ENUMERAÇÃO QUE PERMITE VARRER A LISTA DE VARIÁVEIS SEM CONHECER

A ESTRUTURA INTERNA (UM ITERADOR)• cloneWithoutValue()

• UM "DEEP CLONING" DE UMA VARIABLE BINDINGS LIST (SEM CLONAR OS OBJETOS-VALOR)

• EXEMPLO DO USO DE GET-NEXT varBindList = new SnmpVarbindList(); varBindList.addVariable("ifIndex"); SnmpVar ifDescr = new SnmpVar("ifDescr"); SnmpVar ifOutOctets = new SnmpVar("ifOutOctets");

// Os OIDs seguintes serão usados depois // para pegar SnmpVars específicos da varbind list resultante // OIDs para ifDescr e ifOutOctetsOid sem instância SnmpOid ifDescrOid = ifDescr.getOid(); SnmpOid ifOutOctetsOid = ifOutOctets.getOid();

// preprae a varbind list do pedido varBindList.addVariable(ifDescr); varBindList.addVariable(ifOutOctets);

SnmpOctet descr; SnmpCounter32 enviados;

for(int i = 0; i < númeroDeInterfaces; i++) { // manda pedido get-next umPedido = session.snmpGetNext(agentInfo, null, varBindList); if(!umPedido.waitForCompletion((long) 10000)) { System.out.println("timeout no pedido"); System.exit(0); }

// verifica se tudo ok errorStatus = umPedido.getErrorStatus();

if(errorStatus != SnmpStatusEnums.snmpRspNoError) { System.out.print("Error Status = "); System.out.println(SnmpDebug.snmpErrorToString(errorStatus)); System.out.print("Error Index = "); System.out.println(umPedido.getErrorIndex()); break; }

resultVBList = umPedido.getResponseVbList();

// Agora, pega os SnmpVars que deseja na resposta enviados = null; descr = null; // itera na varbind list for(Enumeration enum = resultVBList.getVarbindEnumeration(); enum.hasMoreElements();) { SnmpVar umaVar = (SnmpVar) enum.nextElement();

if(umaVar.getOid().isASubset(ifDescrOid) ){ // se houve casamento ate ifDescrOid, entao umaVar // é uma instância de ifDescrOid

descr = umaVar.getOctet();


} else if(umaVar.getOid().isASubset(ifOutOctetsOid) ) { enviados = umaVar.getCounter32(); } }

//imprime a informação desejada if (descr != null && enviados != null) { System.out.println("interface: " + descr + " octets enviados = " + enviados); } // cria o próximo pedido get-next varBindList = resultVBList.cloneWithoutValue(); }

O NÍVEL DE APLICAÇÃOCONTEÚDO DO CAPÍTULO:

• APLICAÇÕES E PLATAFORMAS DE GERÊNCIA• ALGUMAS MIBs IMPORTANTES• GERÊNCIA DE CONFIGURAÇÃO• GERÊNCIA DE FALTA• GERÊNCIA DE DESEMPENHO• MONITORAÇÃO REMOTA (RMON)• GERÊNCIA DE HOSPEDEIROS• GERÊNCIA DE APLICAÇÕES

APLICAÇÕES E PLATAFORMAS DE GERÊNCIA

GERÊNCIA DE REDE E GERÊNCIA DE SISTEMA• UMA REDE CORPORATIVA NÃO CONSISTE APENAS DA INFRA-ESTRUTURA DE REDE

• TUDO TEM QUE FUNCIONAR, NÃO APENAS A INFRA-ESTRUTURA DE REDE


• A GERÊNCIA DE REDE:• ELEMENTOS GERENCIADOS:

• ROTEADORES• PONTES• SWITCHES• HUBS• REPETIDORES• CABEAMENTO• MODEMS• SERVIDORES DE TERMINAIS• MULTIPLEXADORES• ENLACES SÍNCRONOS PRIVADOS• ENLACES FRAME RELAY• CONEXÕES ATM• ETC.

• TAREFAS TÍPICAS DE GERENCIAMENTO DESSES ELEMENTOS• CONFIGURAÇÃO DE DISPOSITIVOS• ADMINISTRAÇÃO DE ENDEREÇOS IP• SERVIÇOS DE DIRETÓRIO• MONITORAÇÃO DE TRÁFEGO• DIAGNÓSTICO DE FALTAS• TRATAMENTO DE ALARMES• RESTAURAÇÃO DE SERVIÇO• ANÁLISE DE DADOS E RELATÓRIOS• TROUBLE TICKETING• SEGURANÇA DE REDE• INVENTÁRIO

• A GERÊNCIA DE SISTEMAS• ELEMENTOS GERENCIADOS:

• SERVIDORES DE ARQUIVOS


• SERVIDORES DE IMPRESSÃO• SERVIDORES DE BANCO DE DADOS• SERVIDORES DE APLICAÇÃO• ESTAÇÕES DE TRABALHO• BANCOS DE DADOS• SISTEMAS OPERACIONAIS• CORREIO ELETRÔNICO• APLICAÇÕES (SHRINK-WRAPPED, IN-HOUSE, ETC.)

• TAREFAS TÍPICAS DE GERENCIAMENTO DESSES ELEMENTOS• AUTOMAÇÃO DE CONSOLE• MONITORAÇÃO DE DESEMPENHO• DIAGNÓSTICO DE FALTAS• INVENTÁRIO• DISTRIBUIÇÃO DE SOFTWARE• CONTROLE DE LICENÇAS DE SOFTWARE• ADMINISTRAÇÃO DE USUÁRIOS (CONTAS)• TROUBLE TICKETING• GERÊNCIA DE ARMAZENAMENTO• BACKUP• GERÊNCIA DE SPOOL• SEGURANÇA DE SISTEMA

AS ÁREAS DE GERÊNCIA• A CLASSIFICAÇÃO ACIMA MOSTRA DUAS DIMENSÕES• PARA CADA DIMENSÃO, PODEMOS SUB-DIVIDIR EM 5 ÁREAS (CLASSIFICAÇÃO ISO):

• GERÊNCIA DE CONFIGURAÇÃO• GERÊNCIA DE FALTAS• GERÊNCIA DE DESEMPENHO• GERÊNCIA DE SEGURANÇA• GERÊNCIA DE CONTABILIDADE

• NESTA LISTA, AS ÁREAS DA ISO ESTÃO EM ORDEM DE IMPORTÂNCIA PARA O USUÁRIO• JÁ VIMOS ALGUNS DETALHES DE CADA ÁREA ANTES E VEREMOS MAIS DETALHES À FRENTE

APLICAÇÕES DE GERÊNCIA• LISTAMOS ABAIXO ALGUMAS APLICAÇÕES TÍPICAS DE UM AMBIENTE DE GERÊNCIA

• O PROPÓSITO É MOSTRAR A VARIEDADE (E COMPLEXIDADE!) DAS APLICAÇÕES DEGERÊNCIA NECESSÁRIAS NUMA SOLUÇÃO DE GERÊNCIA COMPLETA

• TAMBÉM MOSTRA COMO A FUNCIONALIDADE É TIPICAMENTE JUNTADA EM APLICAÇÕES• NENHUMA APLICAÇÃO DE GERÊNCIA FAZ TUDO!

• POLLING SNMP E MIB BROWSING• TRATAMENTO DE TRAPS• AUTODESCOBRIMENTO E AUTOTOPOLOGIA• TRATAMENTO DE EVENTOS (RECEPÇÃO, FILTRAGEM, CORRELAÇÃO) E ALARMES• AUTOMAÇÃO DE DIAGNÓSTICO (SISTEMAS ESPECIALISTAS)• TOUBLE TICKETING, HELP DESK• CONFIGURAÇÃO DE DISPOSITIVOS DE REDE• MONITORAÇÃO E ANÁLISE DE TRÁFEGO• ANÁLISE ESTATÍSTICA, TRENDING, EMISSÃO DE RELATÓRIOS• INVENTÁRIO, GERÊNCIA DA PLANTA BAIXA DE CABEAMENTO• PLANEJAMENTO DE CAPACIDADE, PROJETO DE REDE• GERÊNCIA DE ESTAÇÕES CLIENTES (PCs)• AUTOMAÇÃO DE CONSOLE, CONSOLIDAÇÃO DE MENSAGENS PARA O OPERADOR• GERÊNCIA DE BANCOS DE DADOS• GERÊNCIA DE APLICAÇÕES• GERÊNCIA DE CONFIGURAÇÃO E CONTROLE DE MUDANÇA• GERÊNCIA DE HOSPEDEIRO (GERÊNCIA DE WORKLOAD, ARMAZENAMENTO, BACKUP, CONTAS DE

USUÁRIOS, ...)• GERÊNCIA DE IMPRESSÃO (SPOOL)• DISTRIBUIÇÃO DE SOFTWARE, GERÊNCIA DE LICENÇAS• CONTABILIDADE DE RECURSOS E FATURAMENTO


• GERÊNCIA DE SEGURANÇA

PLATAFORMAS DE GERÊNCIA• FRAMEWORK DE GERENCIAMENTO

• FRAMEWORK É UMA SOLUÇÃO QUASE PRONTA PARA RESOLVER UM PROBLEMA DE UMCERTO DOMÍNIO E QUE PODE SER ADEQUADO A UMA SOLUÇÃO PARTICULAR ATRAVÉS DOFORNECIMENTO (OU REDEFINIÇÃO) DE CERTOS MÓDULOS

• BASEADO NO HOLLYWOOD PRINCIPLE: "DON'T CALL US, WE'LL CALL YOU"• CAPTURA AS COISAS COMUNS QUE QUALQUER APLICAÇÃO DE GERÊNCIA QUER• PERMITE INTEGRAR AS VÁRIAS APLICAÇÕES DE GERÊNCIA

• AS APLICAÇÕES PODEM SE INTEGRAR MELHOR SE USAREM A API DA PLATAFORMA• PORTANTO, A PLATAFORMA É TAMBÉM UM AMBIENTE DE DESENVOLVIMENTO

• ARQUITETURA GERAL DE UMA PLATAFORMA DE GERÊNCIA


• OBSERVE OS SEGUINTES COMPONENTES/CARACTERÍSTICAS:• A PLATAFORMA EXECUTA NUMA NETWORK MANAGEMENT STATION (NMS)• A NMS É ACESSADA ATRAVÉS DE ESTAÇÕES DE DISPLAY

• AS VEZES, DIZ-SE QUE A NMS É UM "SERVIDOR DE GERENCIAMENTO" E ASESTAÇÕES DE DISPLAY SÃO "ESTAÇÕES DE GERÊNCIA"


• VÁRIAS OPÇÕES DE ARQUITETURA GRÁFICA (SISTEMA DE JANELAS, LOOK-AND-FEEL)PODE EXISTIR

• AS APLICAÇÕES DE GERÊNCIA SE "PLUGAM" NA PLATAFORMA• UMA API (APPLICATION PROGRAMMING INTERFACE) PERMITE QUE AS APLICAÇÕES

ACESSEM OS RECURSOS INTERNOS DA PLATAFORMA (EXEMPLO: BANCO DE DADOSDE TOPOLOGIA)

• A PLATAFORMA TRATA DE COMUNICAÇÃO DE BAIXO NÍVEL• A PLATAFORMA MONITORA (FAZ POLLING E RECEBE TRAPS)

• A PLATAFORMA PODE SUPORTAR VÁRIOS PROTOCOLO DE GERÊNCIA PADRONIZADOS• OU NÃO-PADRONIZADOS, USANDO GATEWAYS

• A PLATAFORMA MANTÉM VÁRIOS BANCOS DE DADOS• DE ELEMENTOS GERENCIADOS E TOPOLOGIA• DE USUÁRIOS• DE POLÍTICAS DE GERÊNCIA (REGRAS DE GERÊNCIA)• DE LOG DE EVENTOS• DE SCRIPTS DE AUTOMAÇÃO

• EX.: CARGA DE PARÂMETROS DE UM ROTEADOR• DE HELP• DE MIBs

• AS FUNÇÕES PRINCIPAIS DE UMA PLATAFORMA• LEVANTAMENTO DA TOPOLOGIA DA REDE• ELABORAÇÃO DE MAPAS DE REDE

• DANDO VÁRIAS VISÕES DA REDE (FÍSICA, CONECTIVIDADE, DEPARTAMENTAL, ...)• NOTIFICAÇÕES DE ALARME SÃO FREQUENTEMENTE FEITAS NO MAPA COM UM

CÓDIGO DE COR• CARGA E MANIPULAÇÃO DE MIBs• BROWSING DE MIBs• TRATAMENTO DE EVENTOS

• EVENTOS SÃO GERADOS COM TRAPS OU VIA POLLING• PODENDO INCLUIR FILTRAGEM, CORRELAÇÃO, TRANSFORMAÇÃO EM ALARMES• INCLUI AVISOS AO USUÁRIO (SONOROS, VISUAIS, EMAIL, PAGER, ...)• O DIAGNÓSTICO DE FALHAS (ISOLAÇÃO) É FREQUENTEMENTE FEITO PELAS

APLICAÇÕES ADICIONAIS• LOG TOTAL DE EVENTOS INTERESSANTES• GERAÇÃO DE RELATÓRIOS• HELP INTEGRADO• INTERFACE VIA EMULAÇÃO DE TERMINAL (TELNET)

• GERÊNCIA PELA "PORTA DOS FUNDOS"• FREQUENTEMENTE USADO DEVIDO À FRACA SEGURANÇA DO SNMP

• EMPRESAS FREQUENTEMENTE DESABILITAM A OPERAÇÃO "SET" DO SNMP• INTEGRAÇÃO DAS APLICAÇÕES (VIDE À FRENTE)

• VISÃO LÓGICA DE UMA PLATAFORMA COM APLICAÇÕES


• INTEGRAÇÃO DAS APLICAÇÕES À PLATAFORMA• NECESSIDADE DE TER INTEGRAÇÃO SEAMLESS ("SEM COSTURAS")• HÁ ENORMES DIFERENÇAS DE NÍVEL DE INTEGRAÇÃO ENTRE APLICAÇÕES E A

PLATAFORMA• VÁRIAS FORMAS DE INTEGRAÇÃO SEGUEM• INTERFACE DO USUÁRIO

• A APLICAÇÃO POSSUI O MESMO TIPO DE INTERFAEC QUE A PLATAFORMA COMLOOK-AND-FEEL SIMILAR (EX. MOTIF, WINDOWS, ...)

• INTEGRAÇÃO PELO MENU• A APLICAÇÃO PODE SER EXECUTADA A PARTIR DO MENU DA PLATAFORMA

• HELP• O HELP DA APLICAÇÃO ESTÁ INTEGRADO COM O HELP DA PLATAFORMA• NAVEGAÇÃO ÚNICA, ÍNDICE INTERGADO, ...

• TOPOLOGIA• A APLICAÇÃO ACESSA O BD DE OBEJTOS E TOPOLOGIA MANTIDA PELA

PLATAFORMA• EVITA DUPLICAÇÃO• MUITAS APLICAÇÕES FAZEM SEU PRÓPRIO DISCOVERY

• IMAGINE CADASTRAR 500 ELEMENTOS NA PLATAFORMA E EM 3APLICAÇÕES DIFERENTES!!

• BASE DE DADOS• A APLICAÇÃO USA O BD DA PLATAFORMA PARA ARMAZENAR SEUS PRÓPRIOS

DADOS• EVITA DUPLICAÇÃO E PERMITE ACESSO A DADOS VIA SQL• PROVAVELMENTE PERMITE MELHORES RELATÓRIOS COM FERRAMENTAS MAIS

PODEROSAS DE GERAÇÃO DE RELATÓRIOS


• MIB• AS MIBs NECESSÁRIAS PARA A APLICAÇÃO SÃO CARREGADAS PELA PLATAFORMA

E DISPONIBILIZADAS PARA A APLICAÇÃO• COMUNICAÇÃO

• A APLICAÇÃO USA A PLATAFORMA PARA ACESSAR OS ELEMENTOS GERENCIADOS• POLL SNMP, ATENDIMENTO A TRAPS, ETC.• EVITA POLL DUPLICADO AOS ELEMENTOS

• EVENTOS• OS EVENTOS GERADOS PELA APLICAÇÃO PODEM SER MANIPULADOS PELA

PLATAFORMA• INSTALAÇÃO

• A APLICAÇÃO POSSUI UM PROCESSO DE INSTALAÇÃO COMPATÍVEL COM AINSTALAÇÃO DA PLATAFORMA

• PROCESSOS• A APLICAÇÃO ESTÁ INTEGRADA COM OS PROCESSOS QUE EXECUTAM A

PLATAFORMA• POR EXEMPLO, AO ENCERRAR A PLATAFORMA, A APLICAÇÃO TAMBÉM É

ENCERRADA• DIAGNÓSTICO (TRACING/LOGGING)

• A APLICAÇÃO PROVÊ A PLATAFORMA DE INFORMAÇÕES DE DIAGNÓSTICO ARESPEITO DE CONDIÇÕES INESPERADAS

• PODE-SE ASSIM MANTER UMA ÚNICA BASE DE DADOS DE INFORMAÇÕES DEDIAGNÓSTICO

• LOCALIZAÇÃO DE ARQUIVOS• A APLICAÇÃO SEGUE AS NORMAS DA PLATAFORMA PRAA DAR NOMES AOS

ARQUIVOS E EVITAR CONFLITOS DE NOMES COM A PLATAFORMA E COM OUTRASAPLICAÇÕES

• AS GRANDES PLATAFORMAS• OPEN VIEW (HEWLETT PACKARD)• NETVIEW (IBM)• TIVOLI (IBM)• SUNNET MANAGER (SUN MICROSYSTEMS)• SPECTRUM (CABLETRON)• CA-UNICENTER (COMPUTER ASSOCIATES)

GERÊNCIA DISTRIBUÍDA• FALTA DE ESCALA NA SOLUÇÃO CENTRALIZADAS APRESENTADA ATÉ AGORA

• TRÁFEGO DEMAIS INDO PARA A NMS• GARGALO DE COMUNICAÇÃO

• EVENTOS DEMAIS A SEREM TRATADOS PELA NMS• GARGALO DE PROCESSADOR

• FALTA DE MOBILIDADE NA CONSOLE• NÃO É PROBLEMA SE USAR INTERFACE WEB

• NÚMERO LIMITADO DE USUÁRIOS PODEM EXECUTAR A GERÊNCIA SIMULTANEAMENTE• SOLUÇÕES INCIPIENTES AINDA

• VEREMOS ALGUMAS NUM CAPÍTULO À FRENTE• A ÚNICA SOLUÇÃO (PARCIAL) MADURA É O USO DE REMOTE MONITORING PROBES

(SONDAS DE MONITORAÇÃO REMOTA)

ALGUMAS MIBs IMPORTANTES• A LISTA COMPLETA DE MIBs DE GERÊNCIA ESTA AQUI• FALAREMOS DO CONTEÚDO DE ALGUMAS DESSAS MIBs E DE SUA UTILIDADE PARA O

GERENCIAMENTO ADIANTE

SNMPv1RFC Título Status1213 Management Information Base for Network Management of TCP/IP-based internets: MIB-II standard1157 A Simple Network Management Protocol (SNMP) standard1155 Structure and Identification of Management Information for TCP/IP-based Internets standard


SNMPv2RFC Título Status1908 Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework draft1907 Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2) draft1906 Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2) draft1905 Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2) draft1904 Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2) draft1903 Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2) draft

1902Structure of Management Information for Version 2 of the Simple Network Management Protocol(SNMPv2)

draft

1901 Introduction to Community-based SNMPv2 experimental

SNMPv3RFC Título Status2275 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) proposed2274 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) proposed2273 SNMPv3 Applications proposed2272 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) proposed2271 An Architecture for Describing SNMP Management Frameworks proposed

NetworkRFC Título Status2096 IP Forwarding Table MIB proposed2021 Remote Network Monitoring Management Information Base Version 2 using SMIv2 proposed2011 SNMPv2 Management Information Base for the Internet Protocol using SMIv2 proposed1757 Remote Network Monitoring Management Information Base draft1213 Management Information Base for Network Management of TCP/IP-based internets: MIB-II standard

TransmissionRFC Título Status2515 Definitions of Managed Objects for ATM Management proposed2358 Definitions of Managed Objects for the Ethernet-like Interface Types proposed2320 Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 (IPOA-MIB) proposed2233 The Interfaces Group MIB using SMIv2 proposed2108 Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2 proposed1493 Definitions of Managed Objects for Bridges draft

ApplicationRFC Título Status2249 Mail Monitoring MIB proposed1697 Relational Database Management System (RDBMS) Management Information Base (MIB) using SMIv2 proposed1612 DNS Resolver MIB Extensions proposed1611 DNS Server MIB Extensions proposed1514 Host Resources MIB proposed

GERÊNCIA DE CONFIGURAÇÃO• CONTEÚDO

• GERÊNCIA DE TOPOLOGIA• GERÊNCIA DE DISPOSITIVOS

GERÊNCIA DE TOPOLOGIA• HÁ VÁRIOS TIPOS DE TOPOLOGIA• VISÃO DE CONECTIVIDADE FÍSICA (TOPOLOGIA FÍSICA): INDICA QUEM ESTÁ FISICAMENTE

CONECTADO A QUEM• NESTA VISÃO DE TOPOLOGIA, GOSTARÍAMOS DE IR MAIS LONGE AINDA E VER OS

DOMÍNIOS DE COLISÃO (ISTO É, ONDE HÁ SEGMENTOS COMPARTILHADOS E ONDE HÁSWITCHING)

• VISÃO DE CONECTIVIDADE LÓGICA: ENXERGAR APENAS AS CONEXÕES ENTRE ENDEREÇOS IP(ISTO É, ONDE HÁ ROTEAMENTO)


• PORTANTO, ESTE TIPO DE TOPOLOGIA EVIDENCIA OS DOMÍNIOS DE BROADCAST E ONDEHÁ ROTEADORES PARA CRUZAR DE UM DOMÍNIO DE BROADCAST PARA OUTRO

• ESTA VISÃO NÃO MOSTRA HUBS, PONTES E SWITCHES• DOMÍNIOS DE BROADCAST PODEM SER FÍSICOS (AGRUPAMENTO FÍSICO VIA

HUB/PONTE/SWITCH) OU LÓGICOS (LANs VIRTUAIS - VLANs)• VISÃO ADMINISTRATIVA (OU DEPARTAMENTAL): AGRUPAMENTO DOS DISPOSITIVOS DE REDE DE

ACORDO COM UM AGRUPAMENTO ADMINISTRATIVO, SEM RELAÇÃO COM ASPECTOS DECONECTIVIDADE FÍSICA OU LÓGICA

• VISÃO DE SERVIÇOS: EVIDENCIA OS DISPOSITIVOS DE REDE UTILIZADOS PELOS VÁRIOS SERVIÇOS(EXEMPLO: EMAIL)

• DESTA FORMA, SE O EMAIL DEIXAR DE FUNCIONAR, PODE-SE DIAGNOSTICAR P PROBLEMAMAIS RAPIDAMENTE

• MESMO ENTRE AS PRIMEIRAS 2 VISÕES, TEM MUITA DIFERENÇA DEVIDO A• EQUIPAMENTOS TRANSPARENTES (HBS, PONTES, SWITCHES)• LANS VIRTUAIS (VLANs OU DOMÍNIOS DE BROADCAST CONFIGURÁVEIS)• PORT SWITCHING HUBS

• NÃO TEM "SWITCHING", APESAR DO NOME• HUBS COM SEGMENTAÇÃO CONFIGURÁVEL• EQUIVALENTE A DOMÍNIO DE COLISÃO CONFIGURÁVEL• MESNOS POPULARES HOJE DEVIDO A QUEDA DE PREÇO DE SWITCHES

• GOSTARÍAMOS DE LEVANTAR AS TOPOLOGIAS DE FORMA AUTOMÁTICA• É MUITO IMPORTANTE PARA UMA SOLUÇÃO DE GERÊNCIA, JÁ QUE ENTRAR COM TODA

ESTA INFORMAÇÃO MANUALMENTE E MANTÊ-LA ATUALIZADA É DIFÍCIL OU IMPOSSÍVEL• PARA REDES GRANDES, É IMPOSSÍVEL. BASTA PENSAR QUE NUMA REDE GRANDE,

HÁ DEZENAS DE MUDANÇAS DIÁRIAS DE TOPOLOGIA E ELAS NÃO SÃO SEQUERINFORMADAS AO "PESSOAL DE GERÊNCIA"

• HOJE, A VISÃO DE CONECTIVIDADE LÓGICA PODE SER LEVANTADA• A CONECTIVIDADE FÍSICA TAMBÉM, MAS DEPENDENDO DE TER DISPOSITIVOS

GERENCIÁVEIS EM TODO LUGAR, MESMO NOS DISPOSITIVOS NORMALMENTETRANSPARENTES (HUBS, SWITCHES)

• OS OUTROS TIPOS DE CONECTIVIDADE DEVEM SER INFORMADAS (CONFIGURADAS)MANUALMENTE

• FALAREMOS ABAIXO DE ALGUNS ALGORITMOS PARA:• O DESCOBRIMENTO DE DISPOSITIVOS• O DESCOBRIMENTO DA TOPOLOGIA LÓGICA (CONECTIVIDADE LÓGICA)

• O RESULTADO É ARMAZENADO NUM BANCO DE DADOS, NORMALMENTE PELA ESTAÇÃO DEGERÊNCIA

• HÁ DUAS FORMAS BÁSICAS DE DESCOBRIR DISPOSITIVOS E TOPOLOGIA• FORMA ATIVA, ONDE A NMS ENVIA INFORMAÇÃO NA REDE PARA DESCOBRIR

INFORMAÇÃO• DESCOBRIMENTO MAIS VELOZ MAS COM MAIOR INTERFERÊNCIA

• A FORMA PASSIVA EM QUE A NMS (OU OUTROS DISPOSITIVOS) ESCUTA A REDE DE FORMAPASSIVA E DESCOBRE DISPOSITIVOS SEM CARREGAR A REDE COM TRÁFEGO ADICIONAL

• VÁRIOS PROTOCOLOS PODEM SER USADOS PARA DESCOBRIR DISPOSITIVOS E TOPOLOGIA:• ARP (ADDRESS RESOLUTION PROTOCOL)• ICMP (INTERNET CONTROL MESSAGE PROTOCOL)• RIP (ROUTING INFORMATION PROTOCOL)• DNS (DOMAINS NAME SERVICE)• SNMP (SIMPLE NETWORK MANAGEMENT PROTOCOL)

• 1. MONITORAÇÃO PASSIVA DE PACOTES ARP• INTERFACE TEM QUE ENTRAR EM MODO PROMÍSCUO• ESCUTA TODOS OS PACOTES ARP E CONSTROI UMA LISTA DE ENDEREÇOS MAC/IP• SÓ FUNCIONA PARA SUB-REDES CONECTADAS DIRETAMENTE À ESTAÇÃO QUE ESCUTA

• 2. MONITORAÇÃO ATIVA DE PACOTES ARP• ENVIA PACOTES IP USANDO UDP PARA UMA PORTA SEM UTILIZAÇÃO PROVÁVEL E

MONITORA O ARP QUE SAÍ E A RESPOSTA ARP• PODE MONITORAR TAMBÉM O PACOTE DE ERRO (PORT UNREACHABLE) QUE VOLTA• LIMITA A GERAÇÃO A MAIS OU MENOS 4 PACOTES/SEG. PARA NÃO CARREGAR A REDE

DEMAIS• SÓ FUNCIONA PARA SUB-REDES CONECTADAS DIRETAMENTE À ESTAÇÃO QUE ESCUTA

• 3. SCAN SEQUENCIAL DE ENDEREÇOS IP COM PACOTE ICMP ECHO• PARA UMA REDE CLASSE B, VAI GERAR: 65000 ECHOS, 65000 RESPOSTAS, 65000 PACOTES


ARPs (EM BROADCAST!), 65000 RESPOSTAS ARP• O QUE MATA É O BROADCAST DE ARP

• MUITO USADO, APESAR DA CARGA• 4. BROADCAST DE UM PACOTE ICMP ECHO

• USA DIRECTED BROADCAST (ENVIO PARA UMA REDE REMOTA PEDINDO BROADCAST)• PARECE BOM SE O ESPAÇO DE ENDEREÇAMENTO É GRANDE (CLASS A, B) MAS TEM

POUCOS DISPOSITIVOS NA REDE• PODE GERAR MUITO TRÁFEGO E MUITAS COLISÕES NAS PESPOSTAS• POR ISSO, NÃO É SUPORTADO EM TODO LUGAR PORQUE MUITOS ROTEADORES DESLIGAM

O BROADCAST PARA EVITAR GRANDE TRÁFEGO• PODE CRIAR BROADCAST STORMS DEVIDO A MÁS IMPLEMENTAÇÕES DE IP (BROADCAST

DE BROADCAST, ...)• 5. PEDIDO ICMP PARA OBTER MÁSCARA DE SUBREDE

• AJUDA A DETERMINAR A ESTRUTURA DA REDE• PODE AJUDAR A DETECTAR UM PROBLEMA COMUM: MÁSCARAS DE SUBREDE ERRADAS

EM INTERFACES DA MESMA REDE• 6. PACOTE ICMP ECHO COM TIME-TO-LIVE CRESCENTE

• TÉCNICA USADA POR TRACEROUTE• EXECELENTE PARA DESCOBRIR ROTAS E PORTANTO ROTEADORES• MANDA O PACOTE PARA ALGUNS ENDEREÇOS DA REDE REMOTA, NÃO TODOS PORQUE O

ROTEAMENTO VAI SER IGUAL• 7. ESCUTA BROADCASTS DO PROTOCOLO RIP

• OS PACOTES RIP CONTÊM TABELAS DE ROTEAMENTO E, PORTANTO, ENDEREÇOS DE REDEE DE ROTEADORES

• 8. EXAMINAR MAPAS DNS PARA DESCOBRIR MÁQUINAS IMPORTANTES E ROTEADORES• USA ZONE TRANSFERS• HOJE, ZONE TRANSFERS SÃO FREQUENTEMENTE DESABILITADO POR MOTIVOS DE

SEGURANÇA• 9. BROADCAST DE PACOTE SNMP

• TEMPESTADE DE RESPOSTAS PODE ENGARGALAR A REDE• QUEM NÃO TEM AGENTE SNMP NÃO É DESCOBERTO

• 10. USANDO SNMP, EXAMINAR A CACHE ARP DOS ROTEADORES• FAZ PARTE DA MIB• SÓ PODE SER FEITO QUANDO OS ROTEADORES SÃO DECOBERTOS (VER ADIANTE)

• 11: USANDO SNMP, APROVEITAR A MONITORAÇÃO PASSIVA DE RMON• VEREMOS RMON ADIANTE• RMON MANTÉM INFORMAÇÃO SOBRE TUDO QUE VÊ PASSANDO NA REDE E MANTÉM

TABELAS QUE DIZEM QUE ENDEREÇOS EXISTEM (INCLUINDO MAC, IP)• ESTE É O MÉTODO PREFERIDO MAS AINDA NÃO TEM IMPLANTAÇÃO DE RMON EM ESCALA

SUFICIENTE PARA DECOBRIR TUDO• SOLUÇÃO TÍPICA:

• TÉCNICA 3: PING SEQUENCIAL PARA DESCOBRIR DISPOSITIVOS• UM POUCO DE AJUDA MANUAL PARA INICIAR (EX.: REDES DE INTERESSE)

• TÉCNICA 6: TRACEROUTE DE CADA DISPOSITIVO DESCOBERTO PARA DESCOBRIRROTEADORES

• TÉCNICA 5: DESCOBRE MÁSCARA DE CADA INTERFACE DE ROTEADORES DESCOBERTAACIMA

• TÉCNICA 2 (SEGUNDA PARTE): MANDA ECHO PARA UDP PORTA NÃO USADA(PROVAVELMENTE) E ANOTA O ENDEREÇO IP DA MENSAGEM QUE VOLTA (PARADESCOBRIR A INTERFACE REMOTA NA QUAL O REPLY SAIU E, ASSIM, DESCOBRIR MULTI-HOMED HOSTS)

• IDENTIFICA REDES ATRAVÉS DAS CLASSES IP DESCOBERTAS• IDENTIFICA SUB-REDES ATRAVÉS DE MÁSCARAS DE SUBREDE• TÉCNICA 10: VERIFICA CACHE ARP DE ROTEADORES PARA DESCOBRIR NOVOS

DISPOSITIVOS COM TEMPO SEM FAZER UM DESCOBRIMENTO TOTAL• DESCOBRIMENTO DA TOPOLOGIA FÍSICA

• VER LIVRO "HOW TO MANAGE YOUR NETWORK USING SNMP: THE NETWORKMANAGEMENT PRACTICUM", PÁGINA 308

• BASEADO NO SNMP E DEPENDE PORTANTO DE TER AGENTES SNMP NOS HUBS, PONTES ESWITCHES

• DEPENDE DAS MIBS DE REPETIDORES (HUBS) E PONTES• HÁ UMA MIB DE DESCOBRIMENTO SENDO ELABORADA PELA IETF MAS PARECE QUE O TRABALHO


PAROU NO FINAL DE 1998 DEVIDO A UMA PATENTE DA IBM• SEGUEM RESULTADOS DE "DESCOBRIR" A INTERNET:

• OBTIDO DAQUI: http://www.caida.org/Tools/Skitter• COMECE AQUI: hopdistance.htm


• APÓS DESCOBRIR OS DISPOSITIVOS E A TOPOLOGIA, QUEREMOS TRAÇAR UM MAPA QUE MOSTREOS RESULTADOS E EVIDENCIE A CONECTIVIDADE

• É COMUM QUERER MOSTRAR APENAS OS DISPOSITIVOS MAIS IMPORTANTES PARA OUSUÁRIO

• COMO DESCOBRIR O QUE E IMPORTANTE?• HEURÍSTICAS:

• ipForwarding = 1 (gateway ou roteador)• ifNumber > 2• sysObject IDENTIFICA O DISPOSITIVO COMO SWITCH OU ROTEADOR OU SERVIDOR• ipOutRequests/sec > 100• etc., etc.

• O OPERADOR DA REDE AINDA TEM QUE AJUDAR PARA JUNTAR OS DISPOSITIVOS DO MAPANAS VISÕES MAIS ÚTEIS PARA ELE

• O MÁXIMO QUE O SOFTWARE DE DESCOBRIMENTO PODE FAZER É AGRUPAR EMSUBREDES IP

• ALÉM DO DESCOBRIMENTO DE TOPOLOGIA, A GERÊNCIA DE TOPOLOGIA TAMBÉM ENVOLVE:• DEFINIÇÃO DE LANS VIRTUAIS (VLANs) PARA FACILIAR MOVES, ADDS, CHANGES• CONFIGURAÇÃO DE SPANNING TREE (ESCOLHER A RAIZ DA ÁRVORE, POR EXEMPLO)

• VEREMOS MAIS SOBRE ISSO ADIANTECONFIGURAÇÃO DE DISPOSITIVOS

• A CONFIGURAÇÃO DE DISPOSITIVOS DEVE BASEAR-SE EM IMAGENS QUE REPRESENTEM OSDISPOSITIVOS FÍSICOS FIELMENTE

• PODE-SE CONFIGURAR GRAFICAMENTE:• STATUS DE CADA PORTA• ENDEREÇOS MAC E/OU IP ASSOCIADOS ÀS PORTAS• ATRIBUTOS DE PORTAS OU DO DISPOSITIVO• FAZER UM RESET REMOTO, ETC.• PARA ROTEADORES, PODE-SE CONFIGURAR O TIPO DE ROTEAMENTO (IP, IPX, APPLETALK),

REGRAS DE FILTRAGEM, SE FAZ BRIDGING TAMBÉM OU NÃO, ETC.


• BASELINING• AS CONFIGURAÇÕES DE DISPOSITIVOS DEVEM SER GUARDADOS EM ARQUIVOS

(FORMANDO O BASELINE) DE FORMA A:• PERMITIR CONFIGURAR UM OU MAIS DISPOSITIVOS SEMELHANTES A PARTIR DE

UM ARQUIVO DE BASELINE ARMAZENADO• VERIFICAR SE A CONFIGURAÇÃO DA REDE INTEIRA ESTÁ DE ACORDO COM O

BASELINE• RECONFIGURAR A REDE PARCIAL OU TOTALMENTE A PARTIR DO BASELINE EM

CASO DE PROBLEMA• A CONFIGURAÇÃO DE DISPOSITIVOS PERMITE AINDA:

• INSTALAR NOVAS VERSÕES DO SOFTWARE DE CONTROLE, INCLUINDO AGENTES• PERMITE FAZER UPDATE EM BULK (VÁRIOS DISPOSITIVOS)• PERMITE FAZER UPDATE ESCALONADO (À NOITE)• PERMITE FAZER UPDATE AUTOMÁTICO (SEM ATENDIMENTO HUMANO)• NORMALMENTE USA TFTP (TRIVIAL FILE TRANSFER PROTOCOL)

• RASTREAR O HISTÓRICO DE TODOS OS UPGRADES E MUDANÇAS DE CONFIGURAÇÃO DOSDISPOSITIVOS

• FREQUENTEMENTE FEITO A PARTIR DE UM SOFTWARE DE COTROLE DEINVENTÁRIO QUE PODE CONTROLAR TAMBÉM OS CONTRATOS DE MANUTENÇÃO,ETC.

• A PLANTA BAIXA DE CABEAMENTO, INCLUINDO LAYOUT DOS PRÉDIOS, ETC.

GERÊNCIA DE FALTASA GERÊNCIA DE FALTAS PODE SER DIVIDIDA NAS SEGUINTES TAREFAS BÁSICAS:

• COLETA DE DADOS E DETECÇÃO DE FALTAS• MANUTENÇÃO E MONITORAÇÃO DO ESTADO DE CADA UM DOS ELEMENTOS

GERENCIADOS• PERCEPÇÃO DE QUE ESTÁ HAVENDO UM PROBLEMA• PODE INCLUIR A ANTECIPAÇÃO DE FALHAS

• MONITORAÇÃO DE INDICADORES QUE POSSAM PREVER A OCORRÊNCIA DE FALHAS


• TAXAS CRESCENTES DE ERRO, ATRASOS DE TRANSMISSÃO• USO DE LIMIARES (THRESHOLD) PARA GERAR ALARMES

• DIAGNÓSTICO DE PROBLEMAS• TAMBÉM CHAMADO DE ISOLAÇÃO DE FALHAS• UMA FALTA PODE GERAR UMA FALHA

• USAMOS OS 2 TERMOS DE FORMA INTERCAMBIÁVEL• USO DE TÉCNICAS PARA DIAGNOSTICAR A LOCALIZAÇÃO E RAZÃO DA FALHA• TÉCNICAS PODEM USAR CORRELAÇÃO DE EVENTOS, TESTES DE DIAGNÓSTICOS, ...

• USO DE SISTEMAS ESPECIALISTAS• SOLUÇÕES EMERGENCIAIS

• PARA NÃO DEIXAR A REDE PARADA• PODE NECESSITAR DE TESTES ADICIONAIS

• PARA PERMITIR A VERIFICAÇÃO DO FUNCIONAMENTO DE RECURSOS DA REDE EMCONDIÇÕES NORMAIS OU ARTIFICIAIS

• EXEMPLOS: TESTES DE ECO, DE CONECTIVIDADE• RESOLUÇÃO DE PROBLEMAS

• AÇÕES NECESSÁRIAS AO RESTABELECIMENTO DOS ELEMENTOS COM PROBLEMAS• AÇÕES PODE SER SUGERIDAS AUTOMATICAMENTE

• USO DE SISTEMAS ESPECIALISTAS• NOTIFICAÇÃO E TRACKING

• TAMBÉM CHAMADO SUPERVISÃO DE ALARMES• INTERFACE DO USUÁRIO INDICA QUAIS ELEMENTOS ESTÃO FUNCIONANDO, QUAIS ESTÃO

FUNCIONANDO PARCIALMENTE E QUAIS ESTÃO FORA DE OPERAÇÃO• INCLUI NÍVEIS DE SEVERIDADE• PODE INDICAR POSSÍVEIS CAUSAS• PODE AVISAR VISUALMENTE, COM EMAIL, PAGER, ...• PROVÊ REGISTRO DE OCORRÊNCIAS E EMISSÃO DE RELATÓRIOS PARA ANÁLISE

SOBRE EVENTOS E ALARMES• EVENTOS SÃO MOMENTOS "INTERESSANTES" DE ATIVIDADE NA REDE

• PODEM REPRESENTAR FALHAS OU NÃO• PODEM SER IMPORTANTES OU NÃO

• UMA FALHA PODE DESENCADEAR MUITOS EVENTOS• QUEREMOS LEVAR PROBLEMAS (E NÃO EVENTOS INDIVIDUAIS) À ATENÇÃO DO OPERADOR

ATRAVÉS DE ALARMES• DEVE PORTANTO HAVER FILTRAGEM DE EVENTOS PARA GERAR ALARMES• NA REALIDADE, PODE HAVER VÁRIOS TIPOS DE FILTROS

• FILTROS BASEADOS EM THRESHOLDS PARA GERAR EVENTOS A PARTIR DEMEDIÇÕES

• FILTROS DE AGRUPAMENTO PARA CORRELACIONAR EVENTOS ENTRE SI EDESCOBRIR CAUSAS COMUNS (PROBLEMAS)

• FILTROS DE PRIORIDADE ASSOCIAM UMA CRITICALIDADE A PROBLEMAS (E OALARME CORRESPONDENTE)

• A AÇÃO A SER FEITA POR UMA ALARME É CONFIGURÁVEL• MUDAR O MAPA DA REDE• ENVIAR UM EMAIL• MANDAR UMA MENSAGEM PARA UM PAGER• ETC.

• VER O RESULTADO NA FIGURA ABAIXO


USO DE LIMIARES (THRESHOLDS)• LIMIARES SÃO APLICADOS A VARIÁVEIS DE MIB QUE TENHAM VALOR NUMÉRICO• AS VEZES, DEVE-SE VERIFICAR VALORES ABSOLUTOS DE CONTADORES

• EXEMPLO: ifInErrors, ifOutErrors, ...• AS VEZES, É PREFERÍVEL USAR PERCENTUAIS

• EXEMPLO: ifInOctets, ifOutOctets, ...• VALORES DE LIMIARES SÃO AJUSTADOS APÓS DESCOBRIR O COMPORTAMENTO "NORMAL" DO

SISTEMA


• UM LIMIAR PODE TER UM VALOR DE "RE-ARMAÇÃO"• INTRODUZ HISTERESE PARA EVITAR MÚLTIPLOS EVENTOS QUANDO O VALOR OSCILA A

REDOR DO LIMIAR

TROUBLE TICKETING• USADO PARA CONTROLAR PROBLEMAS E ACOMPANHAR SUA SOLUÇÃO• UM TROUBLE TICKET PODE SER ABERTO POR UM USUÁRIO OU AUTOMATICAMENTE PELA

PLATAFORMA OU ALGUMA APLICAÇÃO• DEPENDE DA POLÍTICA IMPLANTADA

• NORMALMENTE APLICAÇÕES DE TROUBLE TICKETING PERMITEM RELATÓRIOS SOFISTICADOS• SISTEMAS DE TOUBLE TICKETING PODEM SE INTEGRADOS A UM SISTEMA DE HELP DESK

GERÊNCIA DE FALTAS PARA INTERFACES USANDO A MIB-2• A MONITORAÇÃO DE INTERFACES PODE SER USADA PARA DETECTAR CONDIÇÕES DE 3 TIPOS

DIFERENTES:• PROBLEMAS: UMA CONDIÇÃO QUE NECESSITA DA ATENÇÃO DO OPERADOR

• PODE USAR UM LIMIAR DE ZERO PARA SEMPRE CHAMAR A ATENÇÃO DOOPERADOR

• CONDIÇÕES NÃO USUAIS: PODEM OCORRER COM BAIXA FREQUÊNCIA MAS PODEM SETORNAR UM PROBLEMA SE A FREQUÊNCIA AUMENTAR

• CONDIÇÕES NORMAIS DE CARGA (WORKLOAD): PARA CONTABILIZAR A ATIVIDADENORMAL DE UMA INTERFACE

• PODE TAMBÉM DETECTAR PROBLEMAS DE EXCESSO DE CARGA• O QUE OLHAR?

• ifOperStatus NÃO IGUAL A ifAdminStatus INDICA UM PROBLEMA• ifLastChange INDICA QUANDO A INTERFACE MUDOU DE ESTADO

• ifInErrors E ifOutErrors PODEM SER USADOS PARA CALCULAR TAXAS DE ERROS• AS TAXAS DE ERROS DEVEM SER BAIXAS E MUITO MENORES DO QUE AS TAXAS DE

ENTRADA E SAÍDA DE PACOTES• ifInDiscards E ifOutDiscards INDICAM PACOTES JOGADOS FORA (DESCARTADOS) DEVIDO A

LIMITAÇÕES DE RECURSOS (MEMÓRIA, POR EXEMPLO)• AS TAXAS DE DESCARTE DEVEM SER PEQUENAS E MUITO MENORES DO QUE AS

TAXAS DE ENTRADA E SAÍDA DE PACOTES• ifInUcastPkts E ifInNUcastPkts INDICAM PACOTES DE ENTRADA COM UNICAST E NÃO-UNICAST

(NORMALMENTE BROADCAST)• IDEM PARA ifOutUcastPkts E ifOutNUcastPkts• AS TAXAS DE BROADCAST DEVEM SER MUITO PEQUENAS (ATÉ UNS 2% DA

CAPACIDADE)• NA IF-MIB (VERSÃO EXPANDIDA DO GRUPO interfaces - VER RFC 2233), TEM

CONTADORES SEPARADOS PARA BROADCAST E UNICAST• ifInUnknownProtos SEMPRE INDICA UM PROBLEMA• ipForwDatagrams DEVE SER ZERO NUM HOST• ipInAddrErrors INDICA UM ENDEREÇO ERRADO (EXEMPLO: DE UMA OUTRA SUB-REDE) QUE


NÃO DEVERIA TER CHEGADO NESTA INTERFACE: INDICA UM PROBLEMA• ipOutNoRoutes INDICA DATAGRAMAS JOGADOS FORA DEVIDO À AUSÊNCIA DE ROTA

POSSÍVEL: INDICA UM ERRO• ipInHdrErrors INDICA UMA CONDIÇÃO NÃO USUAL MAS NÃO NECESSARIAMENTE UM

PROBLEMA• A IF-MIB (RFC 2233) PERMITE GERAR UM TRAP QUANDO O ENLACE MUDA DE ESTADO

GERÊNCIA DE FALTAS PARA REDES ETHERNET• EXISTEM TRÊS MIBs PARA IEEE 802.3

• RFC 2108 PARA REPETIDORES (UM REPETIDOR DE MÚLTIPLAS PORTAS É CHAMADO DECONCENTRADOR OU HUB)

• AS VARIÁVEIS SÃO rptr...• RFC 2358 PARA A INFORMAÇÃO DE "ETHERNET-LIKE INTERFACE TYPES" (ETHERLIKE-MIB)

• AS VARIÁVEIS SÃO dot3...• RFC 2239 PARA A INFORMAÇÃO DE MEDIA ATTACHMENT UNIT (MAU)

• BAIXO NÍVEL PARA DIFERENCIAR 10BASET, 10BASE5, ..., TIPOS DE CONECTORES,BASEBAND VERSUS BROADBAND, ETC.

• USO DAS VARIÁVEIS DA ETHERLIKE-MIB• ifErrors E ifOutErrors INDICAM ERROS• SE AUMENTAREM, PODE-SE INVESTIGAR OS ERROS COM MAIS CUIDADO• ERROS DE ENTRADA (RECEPÇÃO):

VARIÁVEL DESCRIÇÃO USO PARA DETECTAR FALTAS

dot3StatsAlignmentErrorsQUADRO NÃO RECONHECIDOPOR NÃO TER NÚMERO INTEIRODE BYTES

PROBLEMA NÃO LOCAL

dot3StatsFCSErrorsQUADRO RECONHECIDO MASCOM FRAME CHECK SEQUENCE(CHECKSUM) ERRADO

CONDIÇÃO NÃO USUAL: DEVE SERMUITO PEQUENO. SE NÃO FOR, TEMUM PROBLEMA NÃO LOCAL

dot3StatsFrameTooLongsQUADRO MAIOR QUE O MAIORQUADRO POSSÍVEL

ERRO NÃO LOCAL: SOFTWAREREMOTO COM PROBLEMAS

dot3StatsInternalMacReceiveErrorsQUADRO NÃO RECEBIDO PORERRO INTERNO DA CAMADAMAC

PROBLEMA LOCAL: FALHA NAPLACA DE REDE

dot3StatsSQETestErrorsERRO NO TESTE ESPECIAL DEINTERFACE CHAMADO "SIGNALQUALITY ERROR"

PROBLEMA LOCAL: FALHA NAPLACA DE REDE

• USO DAS VARIÁVEIS DA ETHERLIKE-MIB (CONTINUAÇÃO)• CONTADORES DE SAÍDA (TRANSMISSÃO):

VARIÁVEL DESCRIÇÃO USO PARA DETECTAR FALTAS

dot3StatsSingleCollisionFrames

QUADROSRETRANSMITIDOS COMSUCESSO APÓS UMA ÚNICACOLISÃO

AQUI SÓ CONTAMOS AS COLISÕESDESTA INTERFACE

O SOMATÓRIO DE COLISÕES DEVE SER<= 2% DO TRÁFEGO DESTA INTERFACE

SE HOUVER COLISÕES DEMAIS NAREDE TODA, O TRÁFEGO ESTÁ ALTODEMAIS

SE HOUVER COLISÕES DEMAIS DE UMAÚNICA INTERFACE, A INTERFACE ESTÁCOM PROBLEMA

dot3StatsMultiplesCollisionFramesQUADROSRETRANSMITIDOS COMSUCESSO APÓS MAIS DE

VER COLISÕES ACIMA


UMA COLISÃO

dot3StatsDefferedTransmissions

QUADROS QUE NÃOFORAM TRANSMITIDOS DEPRIMEIRA PORQUE O MEIOESTAVA OCUPADO

CONDIÇÃO NÃO USUAL

dot3StatsLateCollisions

QUADROS COM COLISÃODETECTADA DEPOIS DOTEMPO MÁXIMO POSSÍVELPARA UMA REDEOPERANDOADEQUADAMENTE

REDE LONGA DEMAIS OU ALGUMAPLACA NÃO DETECTA COLISÕESADEQUADAMENTE

dot3StatsExcessiveCollisions

QUADROS QUE NÃOFORAM TRANSMITIDOSPOR TEREM SOFRIDO MAISDO QUE 16 COLISÕES

VER COLISÕES ACIMA

dot3StatsInternalMacTransmitErrors

QUADROS NÃOTRANSMITIDOS POR ERROINTERNO DA CAMADAMAC

PROBLEMA LOCAL: FALHA NA PLACADE REDE

dot3StatsCarrierSenseErrorsERROS DE DETECÇÃO DEPORTADORA

PROBLEMA LOCAL: CONEXÃO FROUXACOM O MEIO

dot3CollTable

UMA TABELA DEFREQUÊNCIAS DECOLISÕES COM 3COLUNAS: 2 DE ÍNDICE E AFREQUÊNCIA DE COLISÃODOS QUADROS. OS ÍNDICESSÃO O ifIndex DAINTERFACE E O NÚMEROPOSSÍVEL DE COLISÕES (0A 15)

VER COLISÕES ACIMA

• USO DAS VARIÁVEIS DE REPETIDORES• DEVIDO À EXISTÊNCIA FREQUENTE DE REPETIDORES EXPANSÍVEIS (STACKABLE HUBS), A

MIBS IDENTIFICA:• UM REPETIDOR, QUE CONTÉM ...• VÁRIOS GRUPOS, QYE CONTÊM ...• VÁRIAS PORTAS

• rptrTotalPartionedPorts: INDICA QUANTAS PORTAS ESTÃO AUTO-PARTICIONADA• ISTO É, REMOVIDAS DA REDE PELO PRÓPRIO HUB DEVIDO A EXCESSO DE COLISÕES

OU UMA COLISÃO COM DURAÇÃO ACIMA DO PERMITIDO• PODE SER DEVIDO A QUEBRA NO CABO, CONECTOR RUIM, ETC.

• rptrPortAdminStatus E rptrPortOperStatus: COMO ifAdminStatus E ifOperStatus• rptrPortAutoPartitionedState: INDICA SE ESTA PORTA ESTÁ AUTO-PARTICIONADA• rptrMonitorPortAutoPartitions CONTA AS TRANSIÇÕES DE AUTO-PARTICIONAMENTO E PODE

INDICAR UM PROBLEMA INTERMITENTE• rptrMonitorGroupTotalErrors E rptrMonitorPortTotalErrors EXISTEM PARA FACILITAR O POLLING

• FAZ POLL DE MENOS VARIÁVEIS E INVESTIGA COM MAIS CUIDADO SE HOUVERMUITOS ERROS

• rptrReset PODE SER USADO PARA CAUSAR UM RESET NO EQUIPAMENTO

GERÊNCIA DE DESEMPENHOSISTEMAS DE FILAS

• UM SISTEMA SIMPLES DE FILAS CONSISTE DE UM SERVIDOR ONDE CHEGAM FREGUESES,FORMANDO UMA FILA

• A FILA SE FORMA DEVIDO À NATUREZA PROBABILÍSTICA DE DUAS VARIÁVEIS


• O TEMPO ENTRE CHEGADAS DE FREGUESES, E• O TEMPO DE SERVIÇO (PARA ATENDER UM FREGUÊS)

• SISTEMA REGIDO PELAS LEIS DOS PROCESSOS ESTOCÁSTICOS

EXEMPLOS• BANCO• SUPERMERCADO• ENLACE DE COMUNICAÇÃO DE DADOS

• NA FIGURA ACIMA:• λ É A MÉDIA DA TAXA DE CHEGADA• µ É A MÉDIA DA TAXA DE SERVIÇO

• TOMANDO O EXEMPLO DE UM ENLACE DE COMUNICAÇÃO DE DADOS USANDO COMUTAÇÃO DEPACOTES

• OS FREGUESES SÃO PACOTES (OU QUADROS, ETC., DEPENDENDO DA CAMADA)• O SERVIDOR É O CANAL DE TRANSMISSÃO• A FILA SE FORMA PORQUE NOVOS PACOTES PODEM CHEGAR ENQUANTO UM QUADRO

ESTÁ SENDO TRANSMITIDO• COMO CARACTERIZAR λ E µ?

• TEM VÁRIAS FORMAS, DESDE QUE AS UNIDADES SEJAM IGUAIS• EXEMPLO: SE EXPRESSARMOS λ E µ EM BITS POR SEGUNDO, ENTÃO:

• λ = NÚMERO DE PACOTES/SEGUNDO• µ = C/L

• C = CAPACIDADE DO CANAL EM BITS POR SEGUNDO• L = TAMAMHO MÉDIO DE UM PACOTE EM BITS

• O QUE DETERMINA O DESEMPENHO DA FILA SÃO BASICAMENTE OS PROCESSOS ESTOCÁSTICOSQUE REGEM A ENTRADA E O SERVIÇO

• O QUE É MAIS IMPORTANTE DISSO SÃO AS TAXAS MÉDIAS (λ E µ)• E PRINCIPALMENTE A UTILIZAÇÃO DO SERVIDOR ( ρ = λ/µ)

• A UTILIZAÇÃO PODE SER VISTA COMO O PERCENTUAL DE OCUPAÇÃO DO SERVIDOR• É UM NÚMERO ENTRE 0 E 1• A UTILIZAÇÃO INSTANTÂNEA VARIA COM TEMPO• ρ É A UTILIZAÇÃO MÉDIA

• PODEMOS JUNTAR VÁRIAS FILAS E FORMAR UMA REDE DE FILAS• EXEMPLO: PARA MODELAR UMA REDE DE COMPUTADORES• EXERCÍCIO: QUAL SERIA A REDE DE FILAS PARA A SEGUINTE REDE DE COMPUTADORES, SE

O CÍRCULOS REPRESENTAM PONTOS DE ENTRADA E SAÍDA DE TRÁFEGO E AS INHASREPRESENTAM ENLACES DE COMUNICAÇÃO FULL-DUPLEX?


• MEDIDAS DE DESEMPENHO DE INTERESSE• VAZÃO (ρC BITS POR SEGUNDO)• TEMPO DE RESPOSTA

• PODE SER NUM ÚNICO ENLACE MAS É NORMALMENTE FIM-A-FIM• COMO CARACTERIZAR O TEMPO DE REPOSTA?

• TEM TRÊS COMPONENTES PRINCIPAIS: T = W + TT + TL

• TEMPO DE ESPERA EM FILA• TEMPO DE SERVIÇO QUE CONSISTE DE:

• TEMPO DE TRANSMISSÃO• TEMPO DE LATÊNCIA

• COMO ESTIMAR CADA COMPONENTE?• O TEMPO DE LATÊNCIA TEM BASICAMENTE A VER COM A DISTÂNCIA

• SUPÕE-SE, POR EXEMPLO, QUE O SINAL TRAFEGA A 80% DA VELOCIDADE DA LUZ (300.000KM/SEG), OU 240.000 KM/SEG OU ENTRE 10 E 15 MILISSEGUNDOS ENTRE RECIFE E SÃOPAULO

• NORMALMENTE É DESPREZÍVEL MAS PODE SER DOMINANTE PARA UM ENLACE DESATÉLITE (1/4 DE SEG. IDA E VOLTA)

• O TEMPO DE TRANSMISSÃO É O TEMPO QUE OS BITS TEM QUE FICAR NO MEIO ATÉ TERMINAR ATRANSMISSÃO

• TT = TAMANHO MÉDIO DO PACOTE EM BITS / CAPACIDADE DO ENLACE EM BITS PORSEGUNDO

• O TEMPO EM FILA É MAIS DIFÍCIL DE ESTIMAR, MAS PODE-SE USAR O SEGUINTE VALORAPROXIMADO:

• W = 1/µ(1-ρ)• RESULTADO FINAL: UM GRÁFICO APROXIMADO DO TEMPO DE RESPOSTA (T) SEGUE ABAIXO


• ESTE GRÁFICO EXIBE UM "JOELHO"• COM UTILIZAÇÃO MENOR QUE O JOELHO (UNS 70%), O DESEMPENHO MÉDIO E A

VARIABILIDADE DO SERVIÇO SÃO BONS• COM UTILIZAÇÃO MENOR, A MÉDIA E A VARIABILIDADE FICAM BEM PIORES

• RESULTADO• É UMA REGRA BÁSICA DA AVALIAÇÃO DE DESEMPENHO QUE A UTILIZAÇÃO DE

QUALQUER RECURSO COMPARTILHADO DEVE FICAR ABAIXO DO JOELHO DA CURVA DEDESEMPENHO

• OBSERVE QUE PARA CERTAS TECNOLOGIAS COMO ETHERNET, AS COLISÕES NOSFAZEM PERDER CAPACIDADE E, PORTANTO, NÃO PODEMOS PASSAR DE UNS 50%(SE FOR UM MEIO COMPARTILHADO)

• UMA SEGUNDA REGRA BÁSICA DA AVALIAÇÃO DE DESEMPENHO É QUE UM MAUDESEMPENHO INDICA ALGUM GARGALO NUM LUGAR LOCALIZADO E NÃO, EM GERAL, UMPROBLEMA GENERALIZADO DE DESEMPENHO

• DEVE-SE LOCALIZAR O GARGALO• PODEMOS TAMBÉM RELACIONAR O TEMPO MÉDIO DE RESPOSTA (OU DE ESPERA) COM A

TAMANHO DA FILA ATRAVÉS DA LEI DE LITTLE:• N = λW = ρ/(1-ρ)

• ONDE N = TAMANHO MÉDIO DA FILA• OUTRAS MEDIDAS DE DESEMPENHO: CONFIABILIDADE

• PODE SER CONSIDERADO COMO SENDO DISPONIBILIDADE (% DISPONÍVEL)• 95%: PARA TESTES OU PROTÓTIPOS (438 HORAS/ANO DE DOWNTIME)• 99,5%: BAIXA DISPONIBILIDADE (44 HORAS/ANO DE DOWNTIME)• 99,95%: BOA DISPONIBILIDADE (4 HORAS/ANO DE DOWNTIME)• 99,98%: ALTA DISPONIBILIDADE (2 HORAS/ANO DE DOWNTIME)• 99,99%: LIMITE SUPERIOR ATUALMENTE (50 MINUTOS/ANO DE DOWNTIME)

• OU PODE SER RECUPERABILIDADE• DUAS MEDIDAS

• MEAN TIME BETWEEN FAILURE (MTBF)• MEAN TIME TO REPAIR (MTTR)

• DISPONIBILIDADE = MTTR/(MTTR+MTBF)PRIMEIRA FACETA DA GERÊNCIA DE DESEMPENHO: DESCOBRINDO PROBLEMAS

• A GERÊNCIA DE DESEMPENHO POSSUI VÁRIAS FACETAS• UMA DELAS É PRESTAR ATENÇÃO ÀS MEDIDAS DE DESEMPENHO E ALERTAR QUANDO ALGO NÃO

VAI BEM• ISSO PODE SER FEITO DA SEGUINTE FORMA


• ADQUIRE UM BASELINE DE DESEMPENHO DESCREVENDO O QUE É COMPORTAMENTONORMAL PARA O DESEMPENHO

• ISTO É, AS VÁRIAS MEDIDAS ESCOLHIDAS PARA RETRATAR O DESEMPENHO DAREDE

• ISSO É FEITO AO LONGO DE ALGUMAS SEMANAS DE OPERAÇÃO• AJUSTA-SE THRESHOLDS ACIMA DOS VALORES NORMAIS PARA GERAR EVENTOS QUANDO

O DESEMPENHO CRUZAR OS LIMIARES• TIPICAMENTE TEM 2 LIMIARES: ADVERTÊNCIA E CRÍTICO

SEGUNDA FACETA DA GERÊNCIA DE DESEMPENHO: PLANEJAMENTO DE CAPACIDADE• CONSISTE EM OBSERVAR O DESEMPENHO COM TEMPO E:

• ANALISAR TENDÊNCIAS• BALANCEAR A CARGA DA REDE ENTRE RECURSOS• PLANEJAMENTO DE EXPANSÕES (OU MUDANÇAS) DE CONFIGURAÇÃO DA REDE

• IMPLICA EM GUARDAR DADOS HISTÓRICOS DE MEDIDAS DE DESEMPENHO• DADOS JOGADOS FORA DEPOIS DE UM TEMPO

• MAS NÃO OS "EVENTOS" (GUARDA "PARA SEMPRE")QUE ESTATÍSTICAS DE DESEMPENHO INTERESSAM?

• PARA INTERFACES• UTILIZAÇÃO DOS ENLACES, POR HORA

• PODE INCLUIR DISTRIBUIÇÃO DE FREQUÊNCIA COM HISTOGRAMA (0-20%, 20%-60%,60%-100%)

• UTILIZAÇÃO DAS INTERFACES, POR PROTOCOLO• QUALIDADE DOS ENLACES, POR HORA

• FRAÇÃO DE ERROS NA ENTRADA E NA SAÍDA• NÚMERO TOTAL DE ERROS• DISPONIBILIDADE• PIORES INTERFACES, DIARIAMENTE

• PARA ROTEADORES• UTILIZAÇÃO DE CPU• UTILIZAÇÃO DE MEMÓRIA• DISPONIBILIDADE• TAXA DE DESCARTE• TAXA TOTAL DE PACOTES CHAVEADOS POR SEGUNDO

• PARA LANS ETHERNET• COLISÕES DEVEM FICAR EM, NO MÁXIMO, 3%• ALGUNS ADMINISTRADORES TOLERAM ATÉ 5%

• PARA HOSTS (NO QUE DIZ RESPEITO À REDE APENAS, POR ENQUANTO)• TAXA DE RETRANSMISSÃO TCP

• EXERCÍCIO• MOSTRE COMO USAR SNMP PARA OBTER AS MEDIDAS DE DESEMPENHO DISCUTIDAS

ACIMA• OBSERVE QUE NENHUMA MEDIDA ACIMA NOS FORNECE TEMPO DE RESPOSTA

• SNMP NÃO FORNECE ISSO POIS NÃO MEDE NADA FIM-A-FIM• PODE USAR PING E/OU TRACEROUTE E/OU PATHCHAR PARA OBTER ESSES VALORES

• AINDA TEREMOS MUITO A FALAR SOBRE COMO OBTER MEDIDAS DE DESEMPENHO QUANDOFALARMOS DE RMON (REMOTE MONITORING) ADIANTE

DIFERENÇAS ENTRE GERENCIAMENTO DE LANs E WANs• LEI BÁSICA: "O GARGALO DE DESEMPENHO É A WAN"• O MOTIVO PODE SER VISTO NA SEGUINTE TABELA COMPARATIVA ENTRE LANs E WANs

• PORTANTO, PARA DESEMPENHO, OLHO NA WAN!

LAN WAN

PRINCIPALMENTE COMUTADA PRINCIPALMENTE ROTEADA

USUÁRIOS ESTÃO NO MESMO LUGAR FÍSICO USUÁRIOS GEOGRAFICAMENTE DISPERSOS

CABEAÇÃO PRIVADA USO DE SERVIÇO DE TELES

EQUIPAMENTOS DOMINAM O CUSTO CUSTO DOMINADO POR ENLACES

ALTA VELOCIDADE BAIXA VELOCIDADE


LARGURA DE BANDA À VONTADE LARGURA DE BANDA LIMITADA

LARGURA DE BANDA BARATA LARGURA DE BANDA CARA

TEMPO DE RESPOSTA RÁPIDO TEMPO DE RESPOSTA MAIS LENTO

TÉCNICAS DE CONSERVAÇÃO DE LARGURA DE BANDA• DEVIDO À CRITICALIDADE DA WAN NO QUE DIZ RESPEITO AO DESEMPENHO, BONS ROTEADORES

NOS AJUDAM A CONSERVAR LARGURA DE BANDA• ALGUMAS TÉCNICAS SÃO MENCIONADAS ABAIXO

• O ROTEADOR NÃO PROPAGA BROADCAST PARA A WAN (UFA!)• ROTEADORES SUPORTAM VÁRIOS PROTOCOLOS DE ROTEAMENTO DE FORMA AO

ADMINISTRADOR PODER ESCOLHER UM DELES EM FUNÇÃO DE SUAS NECESSIDADES• UMA FORMA DE ESCOLHER É DE LEVAR A QUANTIDADE DE TRÁFEGO GERADO PELO

PROTOCOLO• EXEMPLO: RIP GERA MAIS TRÁFEGO QUE OSPF

• ROTEADORES PODE USAR BANDWIDTH-ON-DEMAND QUANDO UM ENLACE CONGESTIONA• UM ENLACE DISCADO PODE SER USADO PARA DAR MAIS LARGURA DE BANDA• A GENERALIZAÇÃO DISSO USANDO VÁRIAS TECNOLOGIAS PARA FORMAR UM ÚNICO

ENLACE É "BANDWIDTH AGGREGATION"• USANDO "MULTILINK PPP", PODE-SE COMBINAR: ENLACES PRIVADOS, ENLACES

TELEFÔNICOS COMUTADOS (POTS), ISDN, ...)

• O ROTEADOR PODE USAR COMPRESSÃO DE DADOS

• O ROTEADOR PODE PRIORIZAR CERTO TRÁFEGO• EXEMPLO: PRIORIDADE PARA TRÁFEGO INTERATIVO TELNET

• O ROTEADOR PODE FORNECER GARANTIAS DE LARGURA DE BANDA PARA CERTO TRÁFEGOATRAVÉS DA RESERVA DE CERTA LARGURA DE BANDA POR PROTOCOLO

• SE ALGUM PROTOCOLO NÃO USA SUA BANDA, ELA PODE SER TEMPORARIAMENTEALOCADA PARA OUTRO PROTOCOLO


• PERMITE OFERECER MELHORES GARANTIAS DE DESEMPENHO PARA TRÁFEGOINTERATIVO OU TRANSACIONAL

• O ROTEADOR PODE IMPLEMENTAR "EQUIDADE ENTRE SESSÕES" PARA EQUILIBRAR A LARGURA

DE BANDA RECEBIDA POR CADA SESSÃO DE UM PROTOCOLO• É UMA EXTENSÃO DA TÉCNICA DE RESERVA POR PROTOCOLO (ACIMA)

• O ROTEADOR PODE IMPLEMENTAR MULTICAST

• UMA ÚNICA CÓPIA DA INFORMAÇÃO É ENVIADA PARA MÚLTIPLOS DESTINOS NUMA"ÁRVORE DE ENTREGA"

• ESTÁ SE TORNANDO EXTREMAMENTE IMPORTANTE HOJE EM DIA

• O ROTEADOR PODE IMPLEMENTAR O PROTOCOLO RSVP PARA RESERVAR RECURSOS E GARANTIR(OU QUASE) A QUALIDADE DO SERVIÇO (QoS)


REMOTE MONITORING (RMON)• O APARECIMENTO DE RMON É O EVENTO MAIS SIGNIFICATIVO NO MUNDO SNMP DESDE A

INVENÇÃO DO PRÓPRIO SNMP• QUAIS SÃO OS PROBLEMAS COM SNMP QUE LEVARAM AO APARECIMENTO DE RMON?

• O POLLING CENTRALIZADO A PARTIR DE UMA ESTAÇÃO DE GERÊNCIA NÃO TEM ESCALA• O TRÁFEGO DE GERÊNCIA PODE PIORAR A SITUAÇÃO DA REDE, ESPECIALMENTE

EM ENLACES WAN• O TRABALHO INTEIRO ESTÁ SENDO FEITO PELA ESTAÇÃO DE GERÊNCIA, IMPONDO UM

LIMITE SUPERIOR NO NÚMERO DE SEGMENTOS DE REDE MONITORADOS• AS MIBs EXISTENTES SÓ FORNECEM INFORMAÇÃO SOBRE EQUIPAMENTOS INDIVIDUAIS E

NÃO SOBRE SEGMENTOS INTEIROS• EXEMPLO: É DIFÍCIL OBTER UMA MATRIZ DE TRÁFEGO ENTRE ORIGEM-DESTINO

• A MONITORAÇÃO PÁRA QUANDO HÁ UMA QUEBRA DE CONECTIVIDADE ENTRE AESTAÇÃO DE GERÊNCIA E PARTES REMOTAS DA REDE

• SOLUÇÃO QUE RMON TRAZ:• DISTRIBUIR AS RESPONSABVILIDADES DE FORMA A COLOCAR INTELIGÊNCIA NUMA

SONDA REMOTA (REMOTE PROBE) PARA MONITORAR SEGMENTOS DE REDE• POR ENQUANTO, BASTA IMAGINAR UM PROBE PERMANENTEMENTE LOCALIZADO NUM

SEGMENTO COMPARTILHADO DE REDE E MONITORANDO-O EM MODO PROMÍSCUO• O PROBE SABE TUDO QUE PASSA NO SEGMENTO DE REDE• VEREMOS O QUE FAZER COM SWITCHES DEPOIS• O PROBE PODE SER STANDALONE OU ESTAR EMBUTIDO EM OUTRO EQUIPAMENTO

(HUB, SWITCH, ROTEADOR) OU ATÉ EM NETWORK INTERFACE CARDS (NIC - OUPLACAS DE REDE)

• A ESTAÇÃO DE GERÊNCIA ACESSA O PROBE PARA OBTER INFORMAÇÃO MASTIGADA• A INFORMAÇÃO MASTIGADA É APRESENTADA SOB FORMA DE UMA MIB

• PORTANTO, RMON FORNECE O EMBRIÃO DE UMA SOLUÇÃO DE GERÊNCIA DISTRIBUÍDA• QUANDO RMON FOI INVENTADA, OS SEGUINTES OBJETIVOS DE PROJETO FORAM LEVADOS EM

CONSIDERAÇÃO• OPERAÇÃO OFF-LINE

• UM MONITOR (PROBE) DEVE COLETAR INFORMAÇÃO SOBRE FALTAS, DESEMPENHOE CONFIGURAÇÃO MESMO QUANDO NÃO ESTÁ SENDO ACESSADO POR UMGERENTE

• AS ESTATÍSTICAS SÃO ACUMULADAS PARA ACESSO FUTURO PELO GERENTE• O PROBE PODE TENTAR AVISAR O GERENTE (VIA TRAP) SE HOUVER UM EVENTO

EXCEPCIONAL• O PROBE DEVE PODER DETECTAR CONDIÇÕES DE ERRO E REPORTÁ-LAS

• PARA TANTO, O PROBE DEVE SER ALTAMENTE CONFIGURÁVEL (PARA INDICAR OQUE MONITORAR, O QUE VERIFICAR, QUE AÇÃO TOMAR QUANDO HÁ UMACONDIÇÃO EXCEPCIONAL, ETC.)

• PARA REPORTAR UMA CONDIÇÃO DE ERRO, NÃO E SUFICIENTE ENVIAR UM TRAP• O TRAP PODE SER PERDIDO• DEVE HAVER MECANISMO DE LOG PARA QUE A ESTAÇÃO DE GERÊNCIA

EXAMINE EVENTOS QUE OCORRERAM NO PASSADO E LOGADOS PELOPROBE

• O PROBE DEVE PODER FAZER CERTOS TIPOS DE ANÁLISE NOS DADOS COLETADOS• EXEMPLO: ORDENAR OS HOSTS DO SEGMENTO POR ORDEM DE TRÁFEGO, ERRO,

ETC.• DEATA FORMA, A ESTAÇÃO DE GERÊNCIA NÃO TEM QUE PEGAR TODOS OS DADOS

E ANALISÁ-LOS: BASTA PEGAR OS DADOS MAIS IMPORTANTES• O PROBE DEVE SER CONTROLÁVEL POR MAIS DE UM GERENTE

• PODE HAVER MAIS DE UM GERENTE POR MOTIVOS DE CONFIABILIDADE, PORTEREM FUNCIONALIDADES DIFERENTES, POR ATENDEREM A UNIDADESDIFERENTES DE UMA ORGANIZAÇÃO, ETC.

• PARA CONTROLAR UM PROBE, A MIB (DO AGENTE DENTRO DO PROBE) TEM VÁRIASTABELAS DE CONTROLE E SETAR VARIÁVEIS NESTAS TABELAS AFETA AOPERAÇÃO DO PROBE

• AS TABELAS CONTÊM UMA VARIÁVEL PARA CONTER O NOME DO GERENTE QUECONTROLA ("POSSUI") UMA LINHA DA TABELA

• APENAS ESTE GERENTE PODE ALTERAR A LINHA (MUDAR A


CONFIGURAÇÃO)A MIB RMON

• RFC 1757 (EXTENSÃO PARA TOKEN RING NA RFC 1513)• CONTÉM 10 GRUPO OPCIONAIS

O GRUPO statistics• MANTÉM ESTATÍSTICAS DE UTILIZAÇÃO E DE ERROS PARA CADA SEGMENTO MONITORADO PELO

PROBE• O PROBE PODE TER MAIS DE UMA INTERFACE E SE CONECTAR A MAIS DE UM SEGMENTO

DE REDE E MONITORAR CADA UM DELES• HÁ UMA TABELA CONTENDO BASICAMENTE CONTADORES PARA O SEGMENTO INTEIRO

• SE APLICA A UM SEGMENTO ETHERNET• EXTENSÃO PARA TOKEN RING NA RFC 1513• CONTÉM O QUE JÁ TEM NA MIB-2 E NA ETHER-LIKE MIB (dot3Stats) MAS CONTA PARA O

SEGMENTO INTEIRO• OS CONTADORES DA TABELA statistics

• etherStatsDropEvents: NÚMERO DE VEZES QUE PACOTES DEIXARAM DE SER TRATADOS PELOPROBE DEVIDO À FALTA DE RECURSOS

• etherStatsOctets: NÚMERO DE BYTES RECEBIDOS INCLUINDO PACOTES ERRADOS• etherStatsPkts: NÚMERO DE PACOTES (QUADROS) RECEBIDOS INCLUINDO PACOTES

NORMAIS, PACOTES ERRADOS, PACOTES DE DE BROADCAST E DE MULTICAST• etherStatsBroadcastPkts: NÚMERO DE PACOTES DE BROADCAST• etherStatsMulticastPkts: NÚMERO DE PACOTES DE MULTICAST• etherStatsCRCAlignErrors: NÚMERO DE PACOTES RECEBIDOS COM TAMANHO CORRETO

(ENTRE 64 E 1518 BYTES) MAS COM ERRO DE CRC OU DE ENQUADRAMENTO (NÚMERO DEBITS NÃO É MÚLTIPLO DE 8)

• etherStatsUndersizePkts: NÚMERO DE PACOTES BEM FORMADOS MAS MENORES QUE 64 BYTES• etherStatsOversizePkts: NÚMERO DE PACOTES BEM FORMADOS MAS MAIORES QUE 1518 BYTES• etherStatsFragments: NÚMERO DE PACOTES MENORES QUE 64 BYTES E COM ERROS DE CRC OU

DE ENQUADRAMENTO (RESULTADOS DE COLISÃO, PROVAVELMENTE)• etherStatsJabbers: NÚMERO DE PACOTES MAIORES QUE 1518 BYTES E COM ERROS DE CRC OU

DE ENQUADRAMENTO• etherStatsCollisions: NÚMERO TOTAL DE COLISÕES• etherStatsPkts64Octets: NÚMERO DE PACOTES COM TAMANHO 64 BYTES• etherStatsPkts65to127Octets: NÚMERO DE PACOTES COM TAMANHO ENTRE 65 E 127 BYTES• etherStatsPkts128to255Octets: NÚMERO DE PACOTES COM TAMANHO ENTRE 128 E 255 BYTES• etherStatsPkts256to511Octets: NÚMERO DE PACOTES COM TAMANHO ENTRE 256 E 511 BYTES• etherStatsPkts512to1023Octets: NÚMERO DE PACOTES COM TAMANHO ENTRE 512 E 1023 BYTES• etherStatsPkts1024to1518Octets: NÚMERO DE PACOTES COM TAMANHO ENTRE 1024 E 1518

BYTES• O CONTROLE DA TABELA:


• PODE-SE PEDIR PARA MONITORAR UMA DETERMINADA INTERFACE (CRIANDO UMA LINHAPARA ELA)

• PODE-SE INFORMAR O NOME DO GERENTE QUE "POSSUI" ESTA LINHA DE CONTROLEO GRUPO history

• PERMITE REGISTRAR AMOSTRAS ESTATÍSTICAS PERIÓDICAS DE INFORMAÇÕES DO GRUPO statistics• A TABELA DE CONTROLE DESTE GRUPO PERMITE DEFINIR FUNÇÕES DE AMOSTRAGEM

• A TABELA DE DADOS, TAMBÉM DESTE GRUPO, CONTÉM AS AMOSTRAS• UMA FUNÇÃO DE AMOSTRAGEM É DEFINIDA POR:

• UMA INTERFACE A SER MONITORADA (historyControlDataSource)• O INTERVALO DE AMOSTRAGEM EM SEGUNDOS (ENTRE 1 E 3600). O DEFAULT É 1800 (30

MINUTOS) (historyControlInterval)• O NÚMERO DE AMOSTRAS QUE SER QUER GUARDAR DO PASSADO

(historyControlBucketsRequested)• O NÚMERO DE AMOSTRAS QUE REALMENTE SÃO AGUARDADAS

(historyControlBucketsGranted)• PODE SER MENOR DO QUE O QUE FOI PEDIDO DEVIDO A LIMITAÇõES DE RECURSOS

• APÓS CONFIGURAR UMA FUNÇÃO DE AMOSTRAGEM (OU MAIS), A TABELA DE DADOS DO GRUPOCONTERÁ ATÉ historyControlBucketsGranted DE TODOS OS CONTADORES DO GRUPO statistics (MENOSOS TAMANHOS DE PACOTES)

• ESTE BUFFER DE AMOSTRAGEM É CIRCULAR (AS ÚLTIMAS historyControlBucketsGrantedAMOSTRAS SÃO GUARDADAS)

• ALÉM DO MAIS, A TABELA DE DADOS CONTÉM UMA COLUNA PARA A UTILIZAÇÃO DO MEIO(etherHistoryUtilization)

• A UTILIZAÇÃO É EXTREMAMENTE ÚTIL PARA VER SE HÁ SOBRECARGA (CONGESTÃO) NOMEIO

• TIPICAMENTE, CONSIDERA-SE UMA UTILIZAÇÃO DE 50% COMO LIMITE ACEITÁVELNUM SEGMENTO ETHERNET COMPARTILHADO

• NUM TOKEN RING OU SEGMENTO ETHERNET NÃO COMPARTILHADO, PODE SERMAIS: ATÉ UNS 75-80%

• A UTILIZAÇÃO É CALCULADA COMO SEGUE:• U = [(PACKETS X (96 + 64) + BYTES X 8) / (INTERVALO X 10.000.000)] X 100%• O MOTIVO É QUE CADA QUADRO É PRECEDIDO DE UM PREÂMBULO DE

SINCRONIZAÇÃO DE 64 BITS E DEVE HAVER PELO MENOS 96 BITS ENTRE QUADROS(INTERFRAME GAP)

O GRUPO host• CONTÉM CONTADORES PARA VÁRIOS TIPOS DE TRÁFEGO PARA/DE OS HOSTS DO SEGMENTO• O PROBE APRENDE QUEM SÃO OS HOSTS DO SEGMENTO ESCUTANDO O MEIO E OBSERVANDO OS

ENDEREÇOS MAC ORIGEM E DESTINO• PARA CADA HOST, O PROBE MANTÉM:

• PACOTES ENTRANDO E SAINDO• BYTES ENTRANDO E SAINDO• PACOTES EM ERRO GERADOS PELO HOST• PACOTES DE BROADCAST GERADOS PELO HOST• PACOTES DE MULTICAST GERADOS PELO HOST

O GRUPO hostTopN• CONTÉM ESTATÍSTICAS DE HOSTS ORDENADAS POR ALGUM PARÂMETRO• UMA DAS 7 VARIÁVEIS DO GRUPO host PODE SER USADA PARA ORDENAR A TABELA• O TAMANHO DA TABELA (O NÚMERO DE HOSTS) E O INTERVALO DE AMOSTRAGEM PODEM SER

CONFIGURADOS• A TABELA ORDENADA CONTÉM:

• O ENDEREÇO MAC DO HOST EM QUESTÃO (hostTopNAddress)• O VALOR DO ÚLTIMO DELTA (TAMANHO DA MUDANÇA NA ÚLTIMA AMOSTRA) DA

VARIÁVEL SELECIONADA (hostTopNRate)• A TABELA ESTÁ ORDENADA POR VALOR DESTA VARIÁVEL

O GRUPO matrix• CONTÉM INFORMAÇÃO DE UTILIZAÇÃO E DE ERRO EM FORMA DE MATRIZ PARA CADA PAR DE

ENDEREÇOS MAC• PARA CADA PAR, A TABELA DE DADOS MANTÉM:

• UM CONTADOR DE PACOTES• UM CONTADOR DE BYTES• UM CONTADOR DE ERROS

• NA REALIDADE, HÁ DUAS TABELAS


• ORIGEM-DESTINO (matrixSDTable)• PARA SABER O TRÁFEGO DE UM HOSTS PARA TODOS OS DEMAIS

• DESTINO-ORIGEM (matrixDSTable)• PARA SABER O TRÁFEGO DE TODOS OS HOSTS PARA UM DETERMINADO HOST

O GRUPO alarm• PERMITE ESTABELECER UM INTERVALO DE AMOSTRAGEM E LIMIARES ASSOCIADOS A QUALQUER

COUNTER OU INTEGER MANTIDOS PELO PROBE• O QUE DEVE SER CONFIGURADO NA TABELA DE CONTROLE:

• UM INTERVALO DE AMOSTRAGEM• UMA VARIÁVEL SER MONITORADA• DOIS LIMIARES (PARA CRIAR HISTERESE)• O TIPO DE LIMIAR (ABSOLUTO OU DELTA)• QUANDO GERAR UM EVENTO (CHAMADO "ALARME" PELO RMON)

• AO CRUZAR UM DOS LIMIARES, OU O OUTRO, OU AMBOS• UM INDICE DENTRO DA TABELA DE EVENTOS (A SER DISCUTIDA ADIANTE) DIZENDO QUE

AÇÃO TOMAR• PODE SER LOGAR O EVENTO E/OU GERAR UM TRAP

O GRUPO event• DESCREVE TODOS OS EVENTOS QUE O PROBE PODE GERAR• UM EVENTO PODE SER GERADO COMO SEGUE:

• PELO CRUZAMENTO DE UM LIMIAR (GRUPO alarm)• COMO RESULTADO DE UM FILTRO (VER GRUPO filter ADIANTE)

• A DESCRIÇÃO DE UM EVENTO INDICA UMA AÇÃO A SER FEITA• PODE SER LOGAR O EVENTO NA logTable (COM TIMESTAMP E DESCRIÇÃO)• PODE GERAR UM TRAP SNMP

O GRUPO filter• PERMITE QUE O MONITOR OBSERVE PACOTES QUE ATENDAM A CERTAS CARACTERÍSTICAS• PERMITE PORTANTO QUE O PROBE SE TORNE UM "ANALISADOR REMOTO DE PROTOCOLOS"• PARA TODOS OS PACOTES QUE ATENDAM (OU QUE NÃO ATENDAM) A UMA CERTA CONDIÇÃO, O

PROBE PODE:• ADQUIRIR ESTATÍSTICAS SOBRE OS PACOTES FILTRADOS• CAPTURAR OS PACOTES FILTRADOS (VER ADIANTE)

• UM FILTRO PODE SER DEFINIDO PARA:• EXAMINAR QUALQUER COMBINAÇÃO DE BITS EM QUALQUER LUGAR DE UM PACOTE

(DATA FILTER)• FILTRAR PACOTES COM DETERMINADA CONDIÇÃO DE ERRO (TAMANHO, CRC,

ENQUADRAMENTO) (STATUS FILTER)• VÁRIOS FILTROS SÃO COMBINADOS NUM CANAL (CHANNEL)

• UM PACOTE SATISFAZ O CANAL (PASSOU PELO CANAL) SE PASSAR POR QUALQUER UM


DOS FILTROS ASSOCIADOS AO CANAL• UM PACOTE QUE PASSOU PELO CANAL DISPARA UM EVENTO (DO GRUPO event)

O GRUPO capture• PERMITE CAPTURAR E ARMAZENAR PARCIAL OU TOTALMENTE PACOTES QUE FORAM FILTRADOS

EM ALGUM CANAL• COMPLETA PORTANTO A FUNÇÃO DO PROBE COMO "ANALISADOR REMOTO DE

PROTOCOLOS"• AO DEFINIR, NA TABELA DE CONTROLE, UMA LINHA QUE SE REFIRA A ALGUM CANAL DE

FILTRAGEM, O PROBE PASSA A ARMAZENAR PACOTES NA TABELA DE DADOS DO GRUPO• O NÚMERO TOTAL DE BYTES DISPONÍVEIS NO BUFFER DE SALVAMENTO, O NÚMERO DE BYTES A

SALVAR POR PACOTE, QUAIS BYTES SALVAR, E VÁRIOS OUTROS PARÂMETROS SÃOCONFIGURÁVEIS NA TABELA DE CONTROLE

• A TABELA DE DADOS CONTÉM OS PACOTES SALVOS E PODE SER ACESSADA PELA ESTAÇÃO DEGERÊNCIA

• REALITY CHECK: MUITOS PROBES DO MERCADO FORAM TESTADOS E ALGUNS PERDEM MUITOSPACOTES QUE DEVERIAM SER CAPTURADOS (DEVIDO A PROBLEMAS DE DESEPENHO DO PROBE)

A VANTAGEM BÁSICA DO RMON• PERMITE QUE UMA PESSOA DE SUPORTE A REDE POSSA SUPORTAR MAIS SEGMENTOS DE REDE

ONDE E COMO USAR RMON NUM SEGMENTO COMPARTILHADO• IDEALMENTE, CADA SEGMENTO COMPARTILHADO TERIA UM PROBE RMON• DEVIDO AO CUSTO ELEVADO, É FREQUENTE USAR PROBES RMON APENAS EM:

• BACKBONES• POR QUE AFETAM MUITA GENTE• PERMITE DETECTAR PROBLEMAS QUE AFETAM O CAMPUS INTEIRO• PERMITE MONITORAR TRÁFEGO QUE CRUZA GRUPOS DE TRABALHO E, ASSIM,

MELHOR DEFINIR OS GRUPOS DE TRABALHO• SEGMENTOS COM SERVIDORES CRÍTICOS• SEGMENTOS DE GRUPOS DE TRABALHO CRÍTICOS

• ISTO É, CRÍTICOS PARA O BUSINESS DA EMPRESA• PARA EMERGÊNCIAS, PROBES PORTÁTEIS PODEM SER USADOS E LOCALIZADOS

TEMPORARIAMENTE NUM SEGMENTOONDE E COMO USAR RMON COM SWITCHES

• PARA ADQUIRIR ESTATÍSTICAS SOBRE TODOS OS QUADROS QUE PASSAM NA REDE, O PROBERMON OPERA EM MODO PROMÍSCUO E DEPENDE DO BROADCAST FÍSICO (DE CAMADA 1) PARAESCUTAR TUDO

• ISSO NÃO É POSSÍVEL NUMA SWITCH ONDE QUADROS TRAFEGAM APENAS NAS PORTASNECESSÁRIAS (COM EXEÇÃO DA OPERAÇÃO DE FLOODING)

• COMO FAZER ENTÃO PARA RMON FUNCIONAR EM AMBIENTES COMUTADOS?• A SOLUÇÃO ÓBVIA DE A SWITCH TER PROBES EMBUTIDOS ESCUTANDO EM CADA PORTA

NÃO FUNCIONA HOJE (EM 1999) DEVIDO A PROBLEMAS DE DESEMPENHO• NENHUMA SWITCH É CAPAZ DE ACOMPANHAR O TRÁFEGO EM TODAS AS PORTAS

A 100 Mbps (FAST ETHERNET), E MUITO MENOS A 1 Gbps E ADQUIRIR ASESTATÍSTICAS RMON

• ESTE PROBLEMA DE DESEMPENHO É A RAZÃO PRINCIPAL QUE EXPLICA POR QUESWITCHES DE PRIMEIRA GERAÇÃO NÃO TINHAM PROBES RMON EMBUTIDOS

• DISCUTIMOS AS ALTERNATIVAS POSSÍVEIS ABAIXO• PRIMEIRA ALTERNATIVA: PROBE RMON NA PLACA DE REDE (NIC) E NÃO NA SWITCH• SEGUNDA ALTERNATIVA: GRUPOS RMON BÁSICOS PARA CADA PORTA DA SWITCH

• A SWITCH CONSEGUE ACOMPANHAR O TRÁFEGO E FORNECER OS GRUPOS statistics, history,alarms E events

• ESTA FUNCIONALIDADE É BÁSICA E DEVE SER SEMPRE EXIGIDA EM QUALQUER SWITCH• NÃO DEGRADA O DESEMPENHO DA SWITCH

• TERCEIRA ALTERNATIVA: ROVING EMBEDDED PROBES• OU "PROBES EMBUTIDOS ERRANTES"• UM PROBE COMPLETO (COM TODOS OS GRUPOS RMON) ESTÁ INCLUÍDO NA SWITCH MAS

PODE ADQUIRIR ESTATÍSTICAS APENAS PARA UMA PORTA (OU UM PEQUENO GRUPO DEPORTAS)

• A PORTA (OU GRUPO) SENDO MONITORADO É CONFIGURÁVEL• AO DETECTAR ALGUMA ANOMALIA NUMA PORTA ATRAVÉS DOS GRUPOS BÁSICOS, O

ROVING PROBE PODE SER DIRECIONADO PARA ESTA PORTA• QUARTA ALTERNATIVA: ESPELHAMENTO DE PORTA

• A SWITCH POSSUI UMA PORTA PARA DIAGNÓSTICOS E O TRÁFEGO DE QUALQUER PORTAPODE SER ESPELHADO NESTA PORTA DE DIAGNÓSTICOS


• UM PROBE EXTERNO COMPLETO PODE MONITORAR A PORTA ESPELHO• A DESVANTAGEM BÁSICA ESTÁ CLARA: O PROBE DEVE SER FISICAMENTE CONECTADO À

PORTA ESPELHO QUANDO NECESSÁRIO• A ALTERNATIVA PODE SER USADA NUMA PORTA DE ALTA VELOCIDADE, JÁ QUE NÃO

AFETA O DESEMPENHO DA SWITCH• QUINTA ALTERNATIVA: MONITORAÇÃO COOPERATIVA

• USAR PROBES ESPECIALIZADOS EM LUGARES ESTRATÉGICOS DIFERENTES• EXEMPLO:

• FAZER FILTRAGEM E CAPTURA DE PACOTES EM SWITCHES QUE FICAM NAPERIFERIA, PERTO DE ONDE O TRÁFEGO É GERADO E RECEBIDO

• MANTER ESTATÍSTICAS DE TRÁFEGO (HISTORY, MATRIX, HOST, HOSTTOPN) NOSSWITCHES CENTRAIS QUE OBSERVAM A ATIVIDADE NO BACKBONE E OS PADRÕESDE TRÁFEGO

RMON2• RMON (CHAMADO RMON1) TEM LIMITAÇÕES:

• NÃO PODE ENXERGAR A ORIGEM E O DESTINO VERDADEIROS DOS PACOTES• PORQUE OPERA NO NÍVEL DE ENLACE

• DE FORMA GERAL, RMON1 NÃO ENXERGA ALÉM DO SEGMENTO NO QUAL ESTÁCONECTADO

• RMON2 (RFC 2021) FOI CRIADO PARA PROVER ESTATÍSTICAS PARA AS CAMADAS 3 A 7 DEPROTOCOLOS

• QUALQUER CAMADA ACIMA DE "REDE" É CHAMADA UMA CAMADA DE "APLICAÇÃO", OQUE NÃO SIGNIFICA QUE SEJA DA CAMADA 7

• NÃO DESCREVEREMOS RMON2 EM DETALHES• OS GRUPOS DA MIB RMON2 SÃO:

• PROTOCLO DIRECTORY: INFORMA QUAIS PROTOCOLOS (IP, TCP, SMTP, ETC.) O PROBECONHECE

• PROTOCOL DISTRIBUTION: ESTATÍSTICAS AGREGADAS SOBRE O TRÁFEGO GERADO PORCADA PROTOCOLO EM CADA SEGMENTO DE REDE

• ADDRESS MAP: MANTÉM A CORRESPONDÊNCIA ENTRE ENDEREÇOS IP, ENDEREÇOS MAC EPORTAS

• NETWORK-LAYER HOST: ESTATÍSTICAS SOBRE O TRÁFEGO QUE ENTRA E SAI DOS HOSTS,BASEADO NO ENDEREÇO DE REDE

• NETWORK-LAYER MATRIX: ESTATÍSTICAS SOBRE O TRÁFEGO ENTRE PARES DE HOSTS,BASEADO NO ENDEREÇO DE REDE

• INCLUI TopN DA MATRIZ


• APPLICATION-LAYER HOST: ESTATÍSTICAS SOBRE O TRÁFEGO QUE ENTRA E SAI DOSHOSTS, BASEADO NO ENDEREÇO DE APLICAÇÃO

• APPLICATION-LAYER MATRIX: ESTATÍSTICAS SOBRE O TRÁFEGO ENTRE PARES DE HOSTS,BASEADO NO ENDEREÇO DE APLICAÇÃO

• INCLUI TopN DA MATRIZ• USER HISTORY COLLECTION: ADQUIRE AMOSTRAS DE VARIÁVEIS INDICADAS PELO

USUÁRIO NAS FREQUÊNCIAS DESEJADAS• QUALQUER VARIÁVEL DE QUALQUER MIB!

• PROBE CONFIGURATION: DEFINE PARÂMETROS DE CONFIGURAÇÃO DO PROBE• INCLUI DESTINO DE TRAPS• INCLUI CONFIGURAÇÃO DE LINHAS SERIAIS PARA ACESSO OUT-OF-BAND PELA

ESTAÇÃO DE GERÊNCIAUTILIZAÇÃO DE PROBES RMON1/RMON2 PARA SOLUCIONAR PROBLEMAS CONCRETOS

• SEGUE UMA DESCRIÇÃO DE VÁRIOS "CASOS" RESOLVIDOS COM RMON• [FALTA TAMBÉM ACHAR E DESCREVER UMA BOA APLICAÇÃO RMON DISPONÍVEL

COMERCIALMENTE]• CASO 1:

• PROBLEMA: O GERENTE DE REDE NUMA GRANDE EMPRESA ESTÁ COM PROBLEMAS COMOS USUÁRIOS FINAIS. USUÁRIOS NA DIVISÃO DE ENGENHARIA ESTÃO RODANDOSIMULAÇÕES E UTILIZAM A REDE CORPORATIVA. AS SIMULAÇÕES PODEM RODARDURANTE DIAS E PRECISAM DE UM CONJUNTO COMPLEXO DE CONEXÕESCLIENTE/SERVIDOR QUE DEVEM RODAR A VELOCIDADE MÁXIMA DURANTE TODA ASIMULAÇÃO. A PARTIR DE UM CERTO MOMENTO, AS SIMULAÇÕES COMEÇARAM ADEMORAR DUAS VEZES MAIS E A DIVISÃO DE ENGENHARIA ESTÁ CULPANDO A FALTA DEBANDA PASSANTE NA REDE E QUER QUE A REDE ETHERNET DE 10 Mbps MIGRE PARA100Mbps OU MAIS

• METODOLOGIA: O GERENTE DE REDE COLETOU "HISTÓRIAS" DOS PROBES RMONCOLOCADOS EM CERTOS LUGARES DA REDE DE ENGENHARIA. ELE ENTÃO PRODUZIUGRÁFICOS MOSTRANDO UTILIZAÇÃO E IDENTIFICANDO OS HOSTS QUE MAIS "FALAM" NAREDE

• SOLUÇÃO: O GERENTE DE REDE APRESENTOU SEUS GRÁFICOS E MOSTROU QUE AUTILIZAÇÃO DA REDE NUNCA ULTRAPASSA 10%. PORÉM, QUEM MAIS FALA NA REDE DAENGENHARIA É UM TERMINAL-X QUE RODA UM SCREEN SAVER EXTREMAMENTEELABORADO A PARTIR DE UMA ESTAÇÃO DE TRABALHO LOCAL. O SCREEN SAVER É OCULPADO PELA LENTIDÃO DA SIMULAÇÃO. A DIVISÃO DE ENGENHARIA DEIXOU DERECLAMAR.

• CASO 2:• PROBLEMA: UM USUÁRIO FINAL NUMA GRANDE EMPRESA FARMACÊUTICA ESTÁ

RECLAMANDO SOBRE UM TEMPO DE RESPOSTAS ANORMALMENTE LENTO QUANDOACESSA SEUS DADOS DE PESQUISA. A EMPRESA ONDE ELE TRABALHA TEM SERVIDORESNOVELL NUMA REDE LOCAL COMUTADA.

• METODOLOGIA: OS SWITCHES TÊM UM ROVING PROBE EMBUTIDO COM SUPORTE TOTAL ARMON (TODOS OS GRUPOS) PARA UMA PORTA QUALQUER DO SWITCH. USANDO ESTEROVING PROBE, UM FILTRO COM CAPTURA DE PACOTES FOI CONFIGURADO PARACAPTURAR TODO O TRÁFEGO ENTRE O PC DO USUÁRIO E O RESTO DA REDE.

• SOLUÇÃO: A PARTIR DOS DADOS COLETADOS, FICOU CLARO QUE PARA CADA ACESSO AOSERVIDOR, HAVIA FREQUENTEMENTE MÚLTIPLAS RESPOSTAS DO SERVIDOR. eSTAANÁLISE INDICOU QUEDEVERIA HAVER UM PROBLEMA COM O PC OU A PLACA DE REDEOU COM O CABO. UMA INSPEÇÃO VISUAL REVELOU QUE O CABO RJ-45 CONECTANDO O PCAO SWITCH ESTAVA DESGASTADO E A COMUNICAÇÃO ENTRE O PC E TODOS OS HOSTSESTAVA MUITO INTERMITENTE.UM NOVO CABO RJ-45 RESOLVEU O PROBLEMA.

• CASO 3:• PROBLEMA: UM GOVERNO MUNICIPAL TEM SOFRIDO PROBLEMAS DE TEMPO DE RESPOSTA

CRESCENTE NA SUA REDE. USUÁRIOS COMEÇAM A RELATAR PROBLEMAS COM O ACESSOAOS SERVIDORES UNIX VIA TCP/IP. DEPOIS DE UMA HORA, MAIS OU MENOS, O USUÁRIOSCOMEÇAM A RELATAR PROBLEMAS COM TEMPO DE RESPOSTA ENVOLVENDO OUTROSPROTOCOLOS E SERVIDORES. EVENTUALEMENTE, DECIDE-SE REBOOTAR OS SERVIDORES.OS PROBE\LEMAS DESAPARECEM POR UM TEMPO MAS VOLTANDO, MAIS RAPIDAMENTEAINDA.

• METODOLOGIA: O GERENTE DE REDE DECIDIU INSTRUMENTAR SUAS REDE COM VÁRIOSPROBES RMON. IMEDIATAMENTE, DESCOBRIU QUE A TAXA DE BROADCAST CRESCIAMATÉ 40% DO TRÁFEGO TOTAL DA REDE. TENDO VISTO ISSO, ELE CONFIGUROU FILTROSPARA CAPTURAR PACOTES DE BROADCAST. a ANÁLISE DOS PACOTES CAPTURADOSREVELOU QUE VÁRIOS DOS SERVIDORES ESTAVAM ENVIANDO PEDIDOS ARP A TAXAS


ANORMALMENTE ALTAS. COLOCANDO FILTROS PARA CAPTURAR ALGUMAS CONVERSASCLIENTE/SERVIDOR, ELE DESCOBRIU QUE CADA PEDIDO DO CLIENTE ESTAVA SENDOREPONDIDO PELOS SERVIDORES NÃO COM UMA RESPOSTA MAS COM UM PEDIDO ARP.

• SOLUÇÃO: O GERENTE DE REDE ENTENDEU QUE OS SERVIDORES ESTAVAM PERDENDO AINFORMAÇÃO DA CACHE ARP ASSIM QUE A INFORMAÇÃO ERA DESCOBERTA (ISTO É, ACACHE ARP ESTAVA SENDO ESVAZIADA IMEDIATAMENTE). VERIFICANDO ACONFIGURAÇÃO DOS SERVIDORES, FOI DESCOBERTO QUE O VALOR DE TIMEOUT DACACHE ARP TINHA SIDO ESTABELECIDA EM MILISSEGUNDOS, EM VEZ DE MINUTOS. oACERTO DO VALOR RESOLVEU O PROBLEMA COMPLETAMENTE.

• CASO 4:• PROBLEMA: UMA GRANDE EMPRESA DE PETRÓLEO CONSTRUI UMA GRANDE REDE

CORPORATIVA ROTEADA COM MUITAS ROTAS ALTERNATIVAS. O BACKBONE CONSISTE DEENLACES WAN CONECTADOS EM MALHA PERMITINDO ATÉ 3 CAMINHOS ALTERNATIVOSPARA O TRÁFEGO. PERIODICAMENTE, NUMA CERTA HORA DO DIA, USUÁRIOS REMOTOSLIGAM PARA O HELP DESK REPORTANDO SÉRIOS PROBLEMAS DE COMUNICAÇÃO COM OCENTRO DE PROCESSAMENTO DE DADOS. MONTAGENS NFS SÃO PERDIDAS E CONEXÕESCAEM. TÉCNICOS PROCURAM O PROBLEMA MAS ELE SOME SOZINHO DEPOIS DE UMAHORA.

• METODOLOGIA: APÓS COLOCAR PROBES RMON NAS REDES LOCAIS PRINCIPAISCONECTADAS À WAN, O GERENTE DE REDE DECIDIU ESTABELECER UM BASELINE PARAESSAS REDES. VÁRIOS LIMIARES "APERTADOS" FORAM ESTABELECIDOS PARA GERAREVENTOS COM QUALQUER PEQUENO DESVIO DE COMPORTAMENTO DE TRÁFEGO (EMPACOTES POR SEGUNDO). DURANTE UM PERÍODO PROBLEMÁTICO, O PROBE DE UMA REDELOCAL COMEÇOU A GERAR EVENTOS. O PROBE REPORTOU QUE O TRÁFEGO ESTAVA 10 A12 VEZES ACIMA DO NORMAL E QUE A UTILIZAÇÃO PASSAVA DE 70%. OS DOIS HOSTS COMMAIOR TRÁFEGO (TOP 2 TALKERS) ERAM PORTAS DO ROTEADOR ENTRE A LAN E A WAN.UMA CAPTURA DE PACOTES DESTE TRÁFEGO MOSTROU QUE A MAIOR PARTE DO TRÁFEGOTINHA ORIGEM E DESTINO FORA DA LAN.

• SOLUÇÃO: DESCOBRIU-SE QUE UM DOS ROTEADORES DA WAN ESTAVA CALCULANDO SUATABELA DE ROTAS DE FORMA ERRADA MAS APENAS DURANTE VERIFICAÇÕESPERIÓDICAS FEITAS POR UM TÉCNICO DURANTE CERTO HORÁRIO DO DIA. EM VEZ DEROTEAR TRÁFEGO DENTRO DA MALHA WAN, O TRÁFEGO ERA DESVIADO PARA A LANONDE SERIA ROTEADO DE VOLTA PARA A WAN ATRAVÉS DE OUTRA ROTA. A LAN TINHASE TORNADO PARTE DO BACKBONE CORPORATIVO DURANTE UMA HORA ATÉ QUE OROTEADOR PROBLEMÁTICO VOLTASSE AO COMPORTAMENTO NORMAL. UM PROTOCOLODE ROTEAMENTO DIFERENTE FOI IMPLANTADO E A LISTA DE CONTROLE DE ACESSO DOROTEADOR FOI MODIFICADA PARA REMOVER O IMPACTO DAS ATIVIDADES DO TÉCNICO.

• CASO 5:

• PROBLEMA: UM GRANDE FABRICANTE DE TURBINAS DE AVIÃO IMPLANTOU A REDE ACIMAPARASEUS ENGENHEIROS DE CAD/CAM QUE ESTÃO TRABALHANDO NUM NOVO PROJETO DE TURBINA.O SEGMENTO ETHERNET TEM MÚLTIPLOS USUÁRIOS E MÚLTIPLOS SERVIDORES NUM ÚNICODOMÍNIO DE COLISÃO. A MONITORAÇÃO CONTÍNUA DO TRÁFEGO COM UM PROBE RMON MOSTRAQUE A UTILIZAÇÃO DO SEGMENTO JÁ ESTÁ PASSANDO DOS LIMITES ACEITÁVEIS(FREQUENTEMENTE ACIMA DE 50%) E ESTÁ AFETANDO O TRABALHO DOS ENGENHEIROS.

• METODOLOGIA: O TIME DE SUPORTE DE REDE DECIDIU TROCAR O HUB POR UM SWITCH. TAMBÉMDECIDIRAM SEGMENTAR OS USUÁRIOS DE ACORDO COM OS PROTOCOLOS E OS SERVIDORESUSADOS.

• SOLUÇÃO: UM PROBE RMON2 MONITORANDO O SEGMENTO DURANTE VÁRIAS SEMANAS MOSTRAQUE SISTEMAS ESTÃO SENDO USADOS POR QUE USUÁRIOS USANDO QUE PROTOCOLOS. COM ESTA


INFORMAÇÃO, AS VLANs DA SWITCH PODEM SER CONFIGURADOS.

GERÊNCIA DE HOSPEDEIROSTIPOS DE HOSPEDEIROS

• DOIS TIPOS DE HOSPEDEIROS• SERVIDORES• ESTAÇÕES CLIENTES

• HÁ GRANDE DIFERENÇA NO GERENCIAMENTO DOS DOIS TIPOS• SÃO POUCOS SERVIDORES MAS CADA UM TEM GRANDE IMPORTÂNCIA, POIS OFERECE UM

SERVIÇO PARA VÁRIOS USUÁRIOS• SÃO MUITAS ESTÇÕES CLIENTES.CADA UMA É MENOS IMPORTANTE, MAS GERENCIAR

TODAS APRESENTA DIFICULDADES DEVIDO À ESCALA• VEREMOS ALGUNS DETALHES DO GERENCIAMENTO DE ESTAÇÕES CLIENTES NO PRÓXIMO

CAPÍTULO QUANDO FALARMOS DE DESKTOP MANAGEMENT INTERFACE (DMI) DA DESKTOPMANAGEMENT TASK FORCE (DMTF)

O QUE QUEREMOS GERENCIAR NUM HOSPEDEIRO SERVIDOR?• É MUITO DIFERENTE DE DISPOSITIVOS DE REDE PORQUE UM HOSPEDEIRO TEM MUITO MAIS

"INTELIGÊNCIA" E É MUITO MAIS VERSÁTIL• A GERÊNCIA DE SISTEMAS É MUITO MAIS ABRANGENTE DO QUE A GERÊNCIA DE REDE

• DIVIDIREMOS A DISCUSSÃO EM• ÁREAS DE GERENCIAMENTO• OBJETOS GERENCIADOS• ATRIBUTOS DOS OBJETOS GERENCIADOS• FUNÇÕES DE GERENCIAMENTO DESEJADAS• MÉTRICAS EXPOSTAS EM RELATÓRIOS

ÁREA DEGERENCIAMENTO

OBJETOSGERENCIADOS

ATRIBUTOS DOSOBJETOS

FUNÇÕES MÉTRICAS/RELATÓRIOS

NODOS SISTEMAS UNIXSISTEMAS NTPERIFÉRICOS

HOME DO HOSTRELEASEMODELOFABRICANTENÚMERO DE SÉRIE

MONITORAÇÃO DESTATUSMONITORAÇÃO DEDESEMPENHOLIMIARES NAUTILIZAÇÃO DA CPUEXEMPLO: 90%DURANTE 5 MINUTOSCOM REARM DE 80%DIAGNÓSTICO DEPROBLEMASACOMPANHAMENTODE PROBLEMASACOMPANHAMENTODE UTILIZAÇÃO DERECURSOS COMCONTABILIDADE/FATURAMENTOAUDITORIA DESEGURANÇAESCALONAMENTODE TAREFAS EBALANCEAMENTODE CARGALOG DE PROBLEMAS

UTILIZAÇÃO DACPU

USUÁRIOS E GRUPOS USUÁRIOSGRUPOS DEUSUÁRIOS

USUÁRIONOME DE LOGINSENHALOGIN HABILITADOUIDDIRETÓRIO DECASASHELLGRUPOS

ADICIONAR EREMOVER USUÁRIOSE GRUPOSMUDANÇA DEATRIBUTOSQUOTASPERMISSÕES

ESPAÇOCONSUMIDOLOGINS FEITOS


NOMESALA FÍSICAFONESQUOTA DE ESPAÇOEM DISCOGRUPONOMEGIDMEMBROS

KERNEL DRIVERSDISPOSITIVOSPROCESSOS

VERSÃO E RELEASEDRIVERSPARÂMETROS DOKERNEL (TAMANHODE TABELAS, ...)SUBSISTEMASPARÂMETROS DEDISPOSITIVOSTAMANHO DEPROCESSOSQUANTIDADE DECPU POR PROCESSO

RECONFIGURAÇÃODO KERNELIMPLANTAÇÃO DEUM NOVO KERNELMUDANÇA DEPRIORIDADE DEPROCESSOSMATAR PROCESSOS

PROCESSOSATIVOSUTILIZAÇÃO DEMEMÓRIAFÍSICA E VIRTUALHIT RATE DACACHE

DISCOS PARTIÇÕESSISTEMAS DEARQUIVOSCONFIGURAÇÃO DEDISCOSDIRETÓRIOSEXPORTADOSDIRETÓRIOSMONTADOSPARTIÇÃO DE SWAP

SWAPCAPACIDADEESPAÇOUSADO/LIVRETIPO (ARQUIVO,PARTIÇÃO)DISPOSITIVOSISTEMA DEARQUIVOSDISPOSITIVOPARTIÇÃOPONTOS DEMONTAGEM(LOCAL E REMOTO)PERMISSÕES DEEXPORTAÇÃOCAPACIDADEESPAÇOUSADO/LIVREESPAÇO MÍNIMOLIVRENOMES DEARQUIVOSLONGOS/CURTOSPRIORIDADE NAVERIFICAÇÃO DOSISTEMA DEARQUIVOS

MONITORAÇÃO DEUTILIZAÇÃO DERECURSOS (ESPAÇOLIVRE)BACKUPSGERÊNCIA DEESPAÇOLIMIARES NAUTILIZAÇÃO DOESPAÇO EM SWAPEXEMPLO: 75%DURANTE 5 MINUTOSCOM REARM DE 65%MONITORAÇÃO DESTATUSMONITORAÇÃO DEDESEMPENHOLIMIARES NAUTILIZAÇÃO DOSDISCOSEXEMPLO: 90%DURANTE 10MINUTOS COMREARM DE 80%DIAGNÓSTICO DEPROBLEMASACOMPANHAMENTODE PROBLEMASACOMPANHAMENTODE UTILIZAÇÃO DERECURSOS COMCONTABILIDADE/FATURAMENTO

UTILIZAÇÃO DECADA UNIDADEFÍSICAUTILIZAÇÃO DECADA UNIDADELÓGICAUTILIZAÇÃO DECADACONTROLADORATAXA DE I/O PARACADA UNIDADEFÍSICA/LÓGICA/CONTROLADORAI/O DE DISCODEVIDO ÀGERÊNCIA DEMEMÓRIASWAP-IN E SWAP-OUT

SOFTWAREINSTALADO

PRODUTOINSTALADO

NOMEOPÇÕES DEINSTALAÇÃOOPÇÕES DEREMOÇÃODIRETÓRIO DEINSTALAÇÃOSUBPRODUTOSINSTALADOS

GERENCIAMENTO DELICENÇASINSTALAÇÃO DENOVO SOFTWAREDESINSTALAÇÃO DESOFTWARE

INFORMAÇÃO DECADASTRO

SPOOLING PROTOCOLO DE IMPRESSORAS GERÊNCIA DE RELATÓRIOS DE


SPOOLSPOOLER LOCALSPOOLER REMOTO

FÍSICASIMPRESSORASLÓGICAS(DESTINOS)ARQUIVOS DEACESSOPARÂMETROS DECONFIGURAÇÃO

IMPRESSORASACOMPANHAMENTODE STATUSDISTRIBUIÇÃO DERELATÓRIOS

PROBLEMAS

INTERFACES DEREDE

PLACAS DE REDE TIPOVELOCIDADEENDEREÇO IPENDEREÇO MAC

ACOMPANHAMENTODE TRÁFEGOACOMPANHAMENTODE TAXAS DE ERROS

TAXA DE I/O EMPACOTES EBYTES/SEGTAXA DE ERROS

• A IMPORTÂNCIA DA AUTOMAÇÃO (SCRIPTS) NA GERÊNCIA DE SISTEMAS• A IMPORTÂNCIA DE EXAMINAR ARQUIVOS DE LOG

• CERTOS PRODUTOS (CHAMADOS WATCHDOGS) PROCURAM PADRÕES EM ARQUIVOS DELOG E GERAM EVENTOS PARA PLATAFORMAS DE GERÊNCIA

O MUNDO SNMP E A GERÊNCIA DE HOSPEDEIROS E SISTEMAS• A GERÊNCIA DE SISTEMAS É NORMALMENTE FEITA SEM USAR SNMP

• SNMP CHEGOU TARDE A ESTA ÁREA• O MUNDO SNMP DEFINIU A HOST RESOURCE MIB (RFC 1514) PARA ESTE PROPÓSITO• DESCREVEMOS ESTA MIB RAPIDAMENTE AGORA

SYSTEM GROUP• DATA DO SISTEMA• DISPOSITIVO E PARÂMETROS DE BOOT• NÚMERO DE USUÁRIOS LOGADOS• NÚMERO DE PROCESSOS EXECUTANDO• NÚMERO MÁXIMO DE PROCESSOS

STORAGE GROUP• QUANTIDADE DE MEMÓRIA PRINCIPAL• TABELA DE DISPOSITIVOS DE ARMAZENAMENTO

• TIPOS DE DISPOSIVITIVOS (FIXED DISK, REMOVABLE DISK, CD, FLOPPY, RAM DISK, ...)• DESCRIÇÃO• UNIDADES DE ALOCAÇÃO• TAMANHO• UNIDADES DE ALOCAÇÃO USADAS• FALHAS DE ALOCAÇÃO

DEVICE GROUP• TABELA DE DISPOSITIVOS

• TIPO (IMPRESSORA, PROCESSADOR, ...)• DESCRIÇÃO• STATUS (RUNNING, WARNING, TESTING, DOWN, UNKNOWN)• NÚMERO DE ERROS

• TABELA DE PROCESSADORES• UTILIZAÇÃO (%) DURANTE O ÚLTIMO MINUTO

• TABELA DE PLACAS DE REDE• TABELA DE IMPRESSORAS

• STATUS (IDLE, PRINTING, WARMUP, ...)• ESTADO DE ERRO DETECTADO: UM BIT CADA PARA:

• LOW PAPER• NO PAPER• LOW TONER• NO TONER• DOOR OPEN• JAMMED• OFFLINE• SERVICE REQUESTED

• TABELA DE DISCOS E DE PARTIÇÕES• TABELA DE SISTEMAS DE ARQUIVOS (LOCAIS OU REMOTOS)

• TIPO• PONTO DE MONTAGEM (LOCAL E REMOTO)• TIPO


• PERMISSÕES DE ACESSO• SE É BOOTÁVEL OU NÃO• DATAS DE BACKUP PARCIAL E COMPLETO

RUNNING SOFTWARE GROUP• INCLUI UMA DESCRIÇÃO DO SOFTWARE CARREGADO EM MEMÓRIA (FÍSICA OU VIRTUAL) E

PRONTO PARA RODAR• INCLUI SISTEMA OPERACIONAL, DRIVERS, APLICAÇÕES

• VARIÁVEIS DA TABELA• NOME DO SOFTWARE• PATH DO ARQUIVO EXECUTÁVEL• PARÂMETROS DE EXECUÇÃO• TIPO (OPERATING SYSTEM, DRIVER, APPLICATION, UNKNOWN)• STATUS

• RUNNING• RUNNABLE• NOT RUNNABLE (SLEEPING)• INVALID (NÃO CARREGADO)

RUNNING SOFTWARE PERFORMANCE GROUP• PARA CADA PROCESSO:

• O NÚMERO DE CENTI-SEGUNDOS DE CPU OBTIDOS PELO PROCESSO• A QUANTIDADE DE MEMÓRIA REAL ALOCADA AO PROCESSO

INSTALLED SOFTWARE GROUP• UMA TABELA TEM UMA ENTRADA PARA CADA SOFTWARE INSTALADO• TABELA INCLUI

• NOME DO SOFWTARE• TIPO (OPERATING SYSTEM, DRIVER, APPLICATION)• DATA DE INSTALAÇÃO

GERÊNCIA DE APLICAÇÕES• O PROPÓSITO DAS TECNOLOGIAS DE INFORMÁTICA É DE EXECUTAR APLICAÇÕES• AS APLICAÇÕES PRECISAM DE RECURSOS PARA FUNCIONAREM

• ARQUIVOS EXECUTÁVEIS• ARQUIVOS• COMUNICAÇÃO ENTRE PROCESOS• CONEXÕES DE REDE• ETC.

• É IMPORTANTE PODER• CONFIGURAR APLICAÇÕES• DETECTAR FALHAS NAS APLICAÇÕES• MONITORAR O DESEMPENHO DE APLICAÇÕES• CONTROLAR A APLICAÇÃO AO LONGO DE SUA VIDA

• A GERÊNCIA DE APLICAÇÕES É GERALMENTE FEITA COM SOFTWARE ESPECIALIZADO QUEFREQUENTEMENTE FAZ PARTE DO SOFTWARE DA APLICAÇÃO

• HÁ ESFORÇOS DE ELABORAÇÃO DE MIBs PARA PODER USAR SNMP PARA MONITORAR ECONTROLAR APLICAÇÕES

REQUISITOS PARA A GERÊNCIA DE APLICAÇÕES• GERÊNCIA DE DESEMPENHO

• MONITORAÇÃO DA QUALIDADE DE SERVIÇO OBTIDO• MONITORAÇÃO DE TEMPO DE RESPOSTA• MONITORAÇÃO DE VAZÃO DE INFORMAÇÃO NAS CONEXÕES• MONITORAÇÃO DA TAXA DE ERROS SOFRIDA

• MONITORAÇÃO DE RECURSOS UTILIZADOS• CPU• MEMÓRIA REAL• MEMÓRIA VIRTUAL

• PLANEJAMENTO DE CAPACIDADE• QUE RECURSOS A APLICAÇÃO NECESSITARÁ NO FUTURO

• OBTENÇÃO DE BASELINES DE DESEMPENHO• GERÊNCIA DE FALTAS

• MONITORAÇÃO DE DISPONIBILIDADE


• MONITORAÇÃO DO STATUS (RODANDO, ESPERANDO, ...)• GERAÇÃO DE EVENTOS NA DETECÇÃO DE PROBLEMAS

• GERÊNCIA DE CONTABILIDADE• DEFINIÇÃO DA UNIDADE DE TRABALHO (TRANSAÇÃO, TEMPO, ...)• MONITORAÇÃO DA UTILIZAÇÃO DE RECURSOS

• GERÊNCIA DE CONFIGURAÇÃO• DISTRIBUIÇÃO• INSTALAÇÃO• DESINSTALAÇÃO• BASELINES DE CONFIGURAÇÃO• CONTROLE OPERACIONAL

• PARAR, SUSPENDER, RESTAURAR, RECONFIGURAR• CADASTRO DE SOFTWARE INSTALADO• CADASTRO DE SOFTWARE EXECUTANDO (PROCESSOS)

FORMAS DE GERENCIAR A APLICAÇÃO• SEM INSTRUMENTAÇÃO

• USANDO COMANDOS DO SISTEMA OPERACIONAL PARA VER RECURSOS UTILIZADOS,STATUS, DE PROCESSOS, ETC.

• USANDO COMANDOS DO SISTEMA OPERACIONAL OU APLICAÇÕES WATCHDOG PARAEXAMINAR ARQUIVOS (DE LOG, P. EX.) MANTIDOS PELA APLICAÇÃO

• COM INSTRUMENTAÇÃO DA APLICAÇÃO• PERMITE UMA GERÊNCIA MAIS EFICAZ

MIBs PARA A GERÊNCIA DE APLICAÇÕES• ARQUITETURA GERAL

• AS MIBs PRINCIPAIS ENVOLVIDAS:• HOST RESOURCE MIB (RFC 1514)

• PARA GERENCIAR O HOSPEDEIRO COMO UM TODO• SYSTEM-LEVEL APPLICATION MIB (RFC 2287)

• PARA GERENCIAR A APLICAÇÃO SEM INSTRUMENTAÇÃO• APENAS ATRAVÉS DE INFORMAÇÃO DO SISTEMA OPERACIONAL (SOBRE A

APLICAÇÃO)• APPLICATION MIB (AINDA NÃO SAIU COMO RFC [AGOSTO 1999])

• GERÊNCIA GERAL DE APLICAÇÕES, SUPONDO INSTRUMENTAÇÃO DA APLICAÇÃO• NETWORK SERVICES MONITORING MIB (RFC 2248)

• GERÊNCIA GERAL DE APLICAÇÕES QUE USAM A REDE• ISTO É, CRIAM "ASSOCIAÇÕES" OU CONEXÕES


• MIB GENÉRICA DO TIPO DE APLICAÇÃO• PARA GERENCIAR UMA APLICAÇÃO ESPECÍFICA (DIGAMOS UM SERVIDOR WWW),

PRECISAMOS DE INFORMAÇÃO MAIS ESPECÍFICA DO QUE TEM NAS OUTRAS MIBs• EXISTEM ESFORÇOS PARA CRIAR MIBs PARA VÁRIAS APLICAÇÕES ESPECÍFICAS

• DNS SERVER MIB (RFC 1611)• DNS RESOLVERr MIB (RFC 1612)• RELATIONAL DATABASE MANAGEMENT SYSTEM MIB (RFC 1697)• MAIL MONITORING MIB (RFC 2249)• WWW SERVICES MIB (RFC 2594)• DIRECTORY SERVER MONITORING MIB (RFC 2605)

• MIB ESPECÍFICA DE PRODUTO• MIBs PROPRIETÁRIAS EXISTEM PARA APLICAÇÕES COMO PARA DISPOSITIVOS DE

REDE• AINDA HÁ RELATIVAMENTE POUCO SUPORTE PARA ESSAS MIBs

• NÃO ESTÁ CLARO QUE A GERÊNCIA DE APLICAÇÕES SERÁ FEITA COM SNMP• PARA ENCERRAR A DISCUSSÃO, APRESENTAMOS BREVEMENTE 2 MIBs

• SYSAPPL-MIB (RFC 2287)• WWW-MIB (RFC 2594)

SYSAPPL-MIB

• SUPORTA GERÊNCIA DE:• CONFIGURAÇÃO• FALTAS• DESEMPENHO

• NÃO É ESPECÍFICA DE UMA APLICAÇÃO PARTICULAR• UMA APLICAÇÃO É UMA COLEÇÃO DE ARQUIVOS EXECUTÁVEIS E OUTROS ARQUIVOS

INSTALADOS E EXECUTANDO NUM COMPUTADOR HOSPEDEIRO• A MIB NÃO SUPÕE INSTRUMENTAÇÃO DA APLICAÇÃO

• A INFORMAÇÃO DEVE SER DESCOBERTA ATRAVÉS DO SISTEMA OPERACIONAL• NÃO REQUER MODIFICAÇÃO ÀS APLICAÇÕES• QUALQUER APLICAÇÃO PODE SER (PARCIALMENTE) GERENCIADA• ESTA MIB NÃO É SUFICIENTE SOZINHA PARA A GERÊNCIA DA APLICAÇÃO

• AS OUTRAS MIBs MAIS ESPECÍFICAS PODERÃO REFERENCIAR AS MIBs MAISGENÉRICAS

• A MIB MODELA:• A APLICAÇÃO COMO UM TODO• OS ELEMENTOS ESTÁTICOS (ARQUIVOS) INDIVIDUAIS QUE FORMAM A APLICAÇÃO• OS ELEMENTOS DINÂMICOS (PROCESSOS) INDIVIDUAIS QUE FORMAM A APLICAÇÃO

• OS GRUPOS DA MIB SÃO:• SYSTEM APPLICATION INSTALLED GROUP• SYSTEM APPLICATION RUN GROUP• SYSTEM APPLICATION MAP GROUP

SYSTEM APPLICATION INSTALLED GROUP• MODELAGEM ESTÁTICA• PERMITE SABER:

• QUE PACOTES DE APLICAÇÃO ESTÃO INSTALADOS (sysApplInstallPkgTable)• FABRICANTE• NOME DO PRODUTO• VERSÃO• NÚMERO DE SÉRIE• DATA DE INSTALAÇÃO• LOCAL (DIRETÓRIO) DE INSTALAÇÃO

• QUE ELEMENTOS (ARQUIVOS) COMPÕEM CADA PACOTE (sysApplInstallElmtTable)• NOME DO ELEMENTO• TIPO

• NON-EXECUTABLE• OPERATING SYSTEM• DEVICE DRIVER• APPLICATION

• DATA DE INSTALAÇÃO• DIRETÓRIO DE INSTALAÇÃO• TAMANHO DO ARQUIVO DEPOIS DA INSTALAÇÃO


• TAMANHO ATUAL DO ARQUIVO• PAPEL DO ELEMENTO (UM BIT PARA CADA PAPEL ABAIXO)

• EXECUTÁVEL• EXCLUSIVE (UMA CÓPIA)• PRIMARY (SÓ UM ELEMENTO PODE SER O PRINCIPAL)• REQUIRED (DEVE ESTAR RODANDO PARA QUE A APLICAÇÃO ESTEJA OK)• DEPENDENT (SÓ PODE ESTAR RODANDO SE OS PRIMARY ESTIVEREM)

SYSTEM APPLICATION RUN GROUP• MODELA A APLICAÇÃO QUANDO ESTÁ EXECUTANDO OU DEPOIS QUE JÁ EXECUTOU

• MODELAGEM DE COMPORTAMENTO DINÂMICO• AS TABELAS:

• APLICAÇÕES QUE ESTÃO RODANDO (sysApplRunTable)• DATA E HORA QUE INICIOU• STATUS (RUNNING, RUNNABLE, WAITING, EXITING, OTHER)

• APLICAÇÕES QUE RODARAM NO PASSADO (sysApplPastRunTable)• DATA E HORA QUE INICIOU E TERMINOU• STATUS DE TÉRMIMO (COMPLETE, FAILED, OTHER)

• ELEMENTOS (PROCESSOS) DE APLICAÇÕES QUE ESTÃO RODANDO (sysApplElmtRunTable)• CONTÉM UMA LINHA DA TABELA PARA CADA PROCESSO EM EXISTÊNCIA NO

SISTEMA OPERACIONAL• ÍNDICES APONTANDO PARA AS OUTRAS TABELAS (INSTALLED GROUP)• HORA QUE PROCESSO INICIOU• STATUS• NOME DO ARQUIVO EXECUTÁVEL• PARÂMETROS DE EXECUÇÃO• TEMPO DE CPU• MEMÓRIA REAL ALOCADA• NÚMERO DE ARQUIVOS ABERTOS• NOME DO DONO DO PROCESSO

• ELEMENTOS (PROCESSOS) DE APLICAÇÕES QUE RODARAM NO PASSADO(sysApplElmtPastRunTable)

• AS LINHAS DA TABELA ANTERIOR QUE CORRESPONDEREM A APLICAÇÕESIDENTIFICADAS SÃO MOVIDAS PARA CÁ QUANDO O PROCESSO TERMINA

SYSTEM APPLICATION MAP GROUP• MAPEIA "PROCESS IDS" PARA REFERÊNCIAS ÀS TABELAS DA APLICAÇÃO

• IDENTIFICA A APLICAÇÃO (PACOTE) E O ELEMENTO DO PACOTE

WWW-MIB

• MIB PARA SERVIDORES WWW• OS GRUPOS SÃO:

• INFORMAÇÃO DE SERVIÇOS• ESTATÍSTICAS DE PROTOCOLOS• ESTATÍSTICAS DE DOCUMENTOS

INFORMAÇÃO DE SERVIÇOS• TABELA ÚNICA DESCREVENDO TODOS OS SERVIÇOS WWW GERENCIADOS PELO AGENTE

• DESCRIÇÃO• PESSOA DE CONTATO• PROTOCOLO (OID DA IANA PARA PROTOCOLOS BEM CONHECIDOS)• NOME DNS (FULLY QUALIFIED DOMAIN NAME DO SERVIÇO)• TIPO (SERVER, CLIENTE, PROXY, CACHING PROXY, OTHER)• STATUS

• DOWN• RUNNING• HALTED• CONGESTED• RESTARTING

• DATA/HORA DE INÍCIO• DATA/HORA QUE SERVIÇO ENTROU NO ESTADO (STATUS) ATUAL

ESTATÍSTICAS DE PROTOCOLOS• ESTATÍSTICAS SOBRE O TRÁFEGO RECEBIDO OU ENVIADO PO UM SERVIÇO WWW• OS CONTADORES ESTÃO ORGANIZADOS EM 5 TABELAS

• wwwSummaryTable: SUMÁRIO DO TRÁFEGO E OPERAÇÃO DE PROTOCOLO POR SERVIÇO


WWW (PARA TODOS OS TIPOS DE PEDIDOS• REQUESTS/RESPONSES IN/OUT• BYTES IN/OUT

• wwwRequestInTable: CADA TIPO DE PEDIDO ENTRANDO É CONTADO INDIVIDUALMENTE• OS TIPOS DE PEDIDOS DEPENDEM DO PROTOCOLO

• wwwRequestOutTable: CADA TIPO DE PEDIDO SAINDO É CONTADO INDIVIDUALMENTE• wwwResponseInTable: CADA TIPO DE RESPOSTA ENTRANDO É CONTADO INDIVIDUALMENTE• wwwResponseOutTable: CADA TIPO DE RESPOSTA SAINDO É CONTADO INDIVIDUALMENTE

ESTATÍSTICAS DE DOCUMENTOS• CONTÉM INFORMAÇÃO SOBRE OS DOCUMENTOS QUE FORAM ACESSADOS NO PASSADO• QUATRO TIPOS DE ESTATÍSTICAS

• DETALHES DAS ÚLTIMAS N TENTATIVAS DE MANIPULAR DOCUMENTOS• NOME DO DOCUMENTO• DATA/HORA• TIPO DE PEDIDO• TIPO DE RESPOSTA• NÚMERO DE BYTES

• OS N DOCUMENTOS MAIS MANIPULADOS (ORDENADOS)• NOME DO DOCUMENTO• NÚMERO DE ACESSOS• NÚMERO DE BYTES TRANSFERIDOS

• OS N DOCUMENTOS QUE MAIS GERARAM TRÁFEGO (ORDENADOS)• ESTATÍSTICAS SUMARIZADAS

GERÊNCIA DE REDES DE COMPUTADORES PROGRAMApaginas.unisul.br/carlos.luz/gerencia/gerencia.pdf ·...

Documents

Transcript of GERÊNCIA DE REDES DE COMPUTADORES PROGRAMApaginas.unisul.br/carlos.luz/gerencia/gerencia.pdf ·...