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 a disciplina, o aluno terá noções não apenas das formas de gerenciar uma rede mas também terá adquirido noções sobre o desenvolvimento 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 FALTAS5.4 GERÊNCIA DE DESEMPENHO

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

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

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 PODEM PARAR!)

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 DE RELATÓ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 OU MUDAR 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 ELEMENTOS GERENCIADOS

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 COMO ATRASO, 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 BATCH AUTOMÁ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 UTILIZADOS POR 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 DO PROTOCOLO

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 ESTA PLATAFORMA 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 OPERADORES A 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 DE GERÊ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 ALARM MANAGERS

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.137

7 * 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 ERROS interfaces.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 DE INFORMAÇÃO

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

TAMBÉM CHAMADO "GERÊNCIA SNMP" DEVIDO AO PROTOCOLO PRINCIPAL: SIMPLE NETWORK MANAGEMENT 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 DEVE

TER 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) COLUNAS COM 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 DETERMINADO AGENTE

AGENTES NORMALMENTE SUPORTAM MAIS MIBs, DEPENDENDO DO TIPO DE EQUIPAMENTO OU SOFTWARE 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 30 interfaces.ifTable.ifEntry.ifDescr.2 = "le0" Hex: 6C 65 30 interfaces.ifTable.ifEntry.ifDescr.3 = "le1" Hex: 6C 65 31 interfaces.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 2B interfaces.ifTable.ifEntry.ifPhysAddress.3 = Hex: 08 00 20 7E 88 2B interfaces.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:00interfaces.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 = 610783

interfaces.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 = 1ip.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 = 0

icmp.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 CADA COMPONENTE 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 DETERMINADA

ANTES 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

EXEMPLO EXAMPLE-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 IfEntryACCESS 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 UMA DETERMINADA 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 TABELA EXISTENTE 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.

serão definidos depois.

Exemplos:sysUpTime OBJECT-TYPE

SYNTAX TimeTicksACCESS read-onlySTATUS 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 COMO VALOR 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 DE TEMPO (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" PARA ESTA 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 TAMANHO FIXO

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

STRING DE TAMANHO VARIÁVEL

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

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

IDENTIFICADOR DE OBJETO

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

NetworkAddressCINCO COMPONENTES SÃO USADOS. O PRIMEIRO COMPONENTE TEM VALOR 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 SUA FUNÇÃ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ÓS UM TIMEOUT

O NÚMERO DE COLUNAS DE UMA TABELA DEVE SER PEQUENO O SUFICIENTE PARA QUE UMA LINHA 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 DE OUTROS

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 BEM

NO SEU PAPEL ORIGINAL

DIAGRAMAS CASE MOSTRAM VISUALMENTE A RELAÇÃO ENTRE CONTADORES

SMI: TRAPSUSADOS PELO AGENTE PARA INDICAR UM EVENTO EXTRAORDINÁRIO PARA 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 USADOS CONJUNTAMENTE 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>

serão definidos depois.

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 DO FABRICANTE

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 COM

SNMv1 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: mrose@dbc.mtview.ca.us"DESCRIPTION

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

OBSERVE QUE MÓDULOS SÃO IDENTIFICADOS COM OIDs TAMBÉM EM iso.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 current

DESCRIPTION "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 ÓRDEM LEXICOGRÁ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

EXEMPLO linkUp 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 DE UMA 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 MESMOS VALORES 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 PELO AGENTE

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

AO CAMINHAR NUMA TABELA, CADA INSTÂNCIA DA PRIMEIRA COLUNA É RETORNADA, DEPOIS DA 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ÇÃO DE 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 COLOCA createAndGo 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Á TEM

COLUNAS 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 AR 0.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 O QUE 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 UMA COLEÇÃO DE TIPOS MENOS COMPLEXOS

A DECOMPOSIÇÃO GRADUAL CHEGA EVENTUALMENTE A TIPOS SIMPLES COMO INTEGER CADA 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ÚMERO MÍ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, OCTET STRING, OBJECT IDENTIFIER)

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

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 SEGUEM PARA 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 DA ASN.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 E TAMANHO

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 DAR SUPORTE 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 POUCO DIFERENTE

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 NO EXEMPLO

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), O PAR PODE SER ESPECIFICADO AQUI PARA ELIMINAR O PARÂMETRO "PEER" NOS PEDIDOS

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 (CONCATENANDO UM 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 CALLBACK QUANDO 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 PELO PACOTE

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 DE GERÊ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 UM CERTO DOMÍNIO E QUE PODE SER ADEQUADO A UMA SOLUÇÃO PARTICULAR ATRAVÉS DO

FORNECIMENTO (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 AS ESTAÇÕ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 DADOS DE 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 COM LOOK-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 3 APLICAÇÕ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 A INSTALAÇÃ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 A RESPEITO DE CONDIÇÕES INESPERADAS

PODE-SE ASSIM MANTER UMA ÚNICA BASE DE DADOS DE INFORMAÇÕES DE DIAGNÓ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 OUTRAS APLICAÇÕ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 Status

1213Management Information Base for Network Management of TCP/IP-based internets: MIB-II

standard

1157 A Simple Network Management Protocol (SNMP) standard

1155Structure and Identification of Management Information for TCP/IP-based Internets

standard

SNMPv2RFC Título Status

1908Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework

draft

1907Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)

draft

1906Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)

draft

1905Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)

draft

1904Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)

draft

1903Textual 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 SNMPv2experimental

SNMPv3RFC Título Status

2275View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)

proposed

2274User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)

proposed

2273 SNMPv3 Applications proposed

2272Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)

proposed

2271 An Architecture for Describing SNMP Management Frameworks proposed

NetworkRFC Título Status

2096 IP Forwarding Table MIB proposed

2021Remote Network Monitoring Management Information Base Version 2 using SMIv2

proposed

2011 SNMPv2 Management Information Base for the Internet Protocol using SMIv2 proposed1757 Remote Network Monitoring Management Information Base draft

1213Management Information Base for Network Management of TCP/IP-based internets: MIB-II

standard

TransmissionRFC Título Status

2515 Definitions of Managed Objects for ATM Management proposed2358 Definitions of Managed Objects for the Ethernet-like Interface Types proposed

2320Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 (IPOA-MIB)

proposed

2233 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 Status

2249 Mail Monitoring MIB proposed

1697Relational Database Management System (RDBMS) Management Information Base (MIB) using SMIv2

proposed

1612 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 ONDE HÁ 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 DE CONECTIVIDADE 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 PROBLEMA MAIS 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 SEQUER INFORMADAS 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 NORMALMENTE TRANSPARENTES (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 DE GERÊ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 FORMA PASSIVA 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 REDE E 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 DESCOBRIR ROTEADORES

TÉCNICA 5: DESCOBRE MÁSCARA DE CADA INTERFACE DE ROTEADORES DESCOBERTA ACIMA

TÉCNICA 2 (SEGUNDA PARTE): MANDA ECHO PARA UDP PORTA NÃO USADA (PROVAVELMENTE) E ANOTA O ENDEREÇO IP DA MENSAGEM QUE VOLTA (PARA DESCOBRIR 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 NETWORK

MANAGEMENT PRACTICUM", PÁGINA 308 BASEADO NO SNMP E DEPENDE PORTANTO DE TER AGENTES SNMP NOS HUBS, PONTES E

SWITCHES 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 MOSTRE OS RESULTADOS E EVIDENCIE A CONECTIVIDADE

É COMUM QUERER MOSTRAR APENAS OS DISPOSITIVOS MAIS IMPORTANTES PARA O USUÁ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 MAPA NAS VISÕES MAIS ÚTEIS PARA ELE

O MÁXIMO QUE O SOFTWARE DE DESCOBRIMENTO PODE FAZER É AGRUPAR EM SUBREDES 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 OS DISPOSITIVOS 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 DOS DISPOSITIVOS

FREQUENTEMENTE FEITO A PARTIR DE UM SOFTWARE DE COTROLE DE INVENTÁ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 EM CONDIÇÕ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 DE MEDIÇÕES

FILTROS DE AGRUPAMENTO PARA CORRELACIONAR EVENTOS ENTRE SI E DESCOBRIR CAUSAS COMUNS (PROBLEMAS)

FILTROS DE PRIORIDADE ASSOCIAM UMA CRITICALIDADE A PROBLEMAS (E O ALARME 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 DO OPERADOR

CONDIÇÕES NÃO USUAIS: PODEM OCORRER COM BAIXA FREQUÊNCIA MAS PODEM SE TORNAR UM PROBLEMA SE A FREQUÊNCIA AUMENTAR

CONDIÇÕES NORMAIS DE CARGA (WORKLOAD): PARA CONTABILIZAR A ATIVIDADE NORMAL 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 ESTADOGERÊ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 DE

CONCENTRADOR 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

dot3StatsAlignmentErrors

QUADRO NÃO RECONHECIDO POR NÃO TER NÚMERO INTEIRO DE BYTES

PROBLEMA NÃO LOCAL

dot3StatsFCSErrorsQUADRO RECONHECIDO MAS COM FRAME CHECK SEQUENCE (CHECKSUM) ERRADO

CONDIÇÃO NÃO USUAL: DEVE SER MUITO PEQUENO. SE NÃO FOR, TEM UM PROBLEMA NÃO LOCAL

dot3StatsFrameTooLongs

QUADRO MAIOR QUE O MAIOR QUADRO POSSÍVEL

ERRO NÃO LOCAL: SOFTWARE REMOTO COM PROBLEMAS

dot3StatsInternalMacReceiveErrors

QUADRO NÃO RECEBIDO POR ERRO INTERNO DA CAMADA MAC

PROBLEMA LOCAL: FALHA NA PLACA DE REDE

dot3StatsSQETestErrors

ERRO NO TESTE ESPECIAL DE INTERFACE CHAMADO "SIGNAL QUALITY ERROR"

PROBLEMA LOCAL: FALHA NA PLACA 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

QUADROS RETRANSMITIDOS COM SUCESSO APÓS UMA ÚNICA COLISÃO

AQUI SÓ CONTAMOS AS COLISÕES DESTA INTERFACE

O SOMATÓRIO DE COLISÕES DEVE SER <= 2% DO TRÁFEGO DESTA INTERFACE

SE HOUVER COLISÕES DEMAIS NA REDE TODA, O TRÁFEGO ESTÁ ALTO DEMAIS

SE HOUVER COLISÕES DEMAIS DE UMA ÚNICA INTERFACE, A INTERFACE ESTÁ COM PROBLEMA

dot3StatsMultiplesCollisionFrames

QUADROS RETRANSMITIDOS COM SUCESSO APÓS MAIS DE UMA COLISÃO

VER COLISÕES ACIMA

dot3StatsDefferedTransmissions

QUADROS QUE NÃO FORAM TRANSMITIDOS DE PRIMEIRA PORQUE O MEIO ESTAVA OCUPADO

CONDIÇÃO NÃO USUAL

dot3StatsLateCollision QUADROS COM COLISÃO DETECTADA REDE LONGA DEMAIS OU ALGUMA

sDEPOIS DO TEMPO MÁXIMO POSSÍVEL PARA UMA REDE OPERANDO ADEQUADAMENTE

PLACA NÃO DETECTA COLISÕES ADEQUADAMENTE

dot3StatsExcessiveCollisions

QUADROS QUE NÃO FORAM TRANSMITIDOS POR TEREM SOFRIDO MAIS DO QUE 16 COLISÕES

VER COLISÕES ACIMA

dot3StatsInternalMacTransmitErrors

QUADROS NÃO TRANSMITIDOS POR ERRO INTERNO DA CAMADA MAC

PROBLEMA LOCAL: FALHA NA PLACA DE REDE

dot3StatsCarrierSenseErrors

ERROS DE DETECÇÃO DE PORTADORAPROBLEMA LOCAL: CONEXÃO FROUXA COM O MEIO

dot3CollTable

UMA TABELA DE FREQUÊNCIAS DE COLISÕES COM 3 COLUNAS: 2 DE ÍNDICE E A FREQUÊNCIA DE COLISÃO DOS QUADROS. OS ÍNDICES SÃO O ifIndex DA INTERFACE E O NÚMERO POSSÍVEL DE COLISÕES (0 A 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 HOUVER MUITOS 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 DE PACOTES

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ÁSTICOS QUE 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 INHAS REPRESENTAM 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.000 KM/SEG), OU 240.000 KM/SEG OU ENTRE 10 E 15 MILISSEGUNDOS ENTRE RECIFE E SÃO PAULO

NORMALMENTE É DESPREZÍVEL MAS PODE SER DOMINANTE PARA UM ENLACE DE SATÉ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 A TRANSMISSÃO

TT = TAMANHO MÉDIO DO PACOTE EM BITS / CAPACIDADE DO ENLACE EM BITS POR

SEGUNDO O TEMPO EM FILA É MAIS DIFÍCIL DE ESTIMAR, MAS PODE-SE USAR O SEGUINTE VALOR

APROXIMADO: W = /(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 DE DESEMPENHO

OBSERVE QUE PARA CERTAS TECNOLOGIAS COMO ETHERNET, AS COLISÕES NOS FAZEM 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 MAU DESEMPENHO INDICA ALGUM GARGALO NUM LUGAR LOCALIZADO E NÃO, EM GERAL, UM PROBLEMA 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 É COMPORTAMENTO NORMAL PARA O DESEMPENHO

ISTO É, AS VÁRIAS MEDIDAS ESCOLHIDAS PARA RETRATAR O DESEMPENHO DA REDE

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 QUANDO FALARMOS 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ÁFEGO ATRAVÉS DA RESERVA DE CERTA LARGURA DE BANDA POR PROTOCOLO

SE ALGUM PROTOCOLO NÃO USA SUA BANDA, ELA PODE SER TEMPORARIAMENTE ALOCADA PARA OUTRO PROTOCOLO

PERMITE OFERECER MELHORES GARANTIAS DE DESEMPENHO PARA TRÁFEGO INTERATIVO 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 A ESTAÇÃ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 - OU PLACAS 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, DESEMPENHO E CONFIGURAÇÃO MESMO QUANDO NÃO ESTÁ SENDO ACESSADO POR UM GERENTE

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 O QUE MONITORAR, O QUE VERIFICAR, QUE AÇÃO TOMAR QUANDO HÁ UMA CONDIÇÃ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 PELO PROBE

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, POR TEREM FUNCIONALIDADES DIFERENTES, POR ATENDEREM A UNIDADES DIFERENTES DE UMA ORGANIZAÇÃO, ETC.

PARA CONTROLAR UM PROBE, A MIB (DO AGENTE DENTRO DO PROBE) TEM VÁRIAS TABELAS DE CONTROLE E SETAR VARIÁVEIS NESTAS TABELAS AFETA A OPERAÇÃO DO PROBE

AS TABELAS CONTÊM UMA VARIÁVEL PARA CONTER O NOME DO GERENTE QUE CONTROLA ("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 PELO PROBE 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 DE BITS 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 LINHA PARA 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 GRUPO CONTERÁ ATÉ historyControlBucketsGranted DE TODOS OS CONTADORES DO GRUPO statistics (MENOS OS TAMANHOS DE PACOTES)

ESTE BUFFER DE AMOSTRAGEM É CIRCULAR (AS ÚLTIMAS historyControlBucketsGranted AMOSTRAS 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) NO MEIO

TIPICAMENTE, CONSIDERA-SE UMA UTILIZAÇÃO DE 50% COMO LIMITE ACEITÁVEL NUM SEGMENTO ETHERNET COMPARTILHADO

NUM TOKEN RING OU SEGMENTO ETHERNET NÃO COMPARTILHADO, PODE SER MAIS: 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 HOSTO 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ÃO

CONFIGURÁVEIS NA TABELA DE CONTROLE A TABELA DE DADOS CONTÉM OS PACOTES SALVOS E PODE SER ACESSADA PELA ESTAÇÃO DE

GERÊNCIA REALITY CHECK: MUITOS PROBES DO MERCADO FORAM TESTADOS E ALGUNS PERDEM MUITOS

PACOTES 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 REDEONDE 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 PROBE RMON OPERA EM MODO PROMÍSCUO E DEPENDE DO BROADCAST FÍSICO (DE CAMADA 1) PARA ESCUTAR TUDO

ISSO NÃO É POSSÍVEL NUMA SWITCH ONDE QUADROS TRAFEGAM APENAS NAS PORTAS NECESSÁ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 AS ESTATÍSTICAS RMON

ESTE PROBLEMA DE DESEMPENHO É A RAZÃO PRINCIPAL QUE EXPLICA POR QUE SWITCHES 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 DE PORTAS)

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 PORTA PODE 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 NA PERIFERIA, PERTO DE ONDE O TRÁFEGO É GERADO E RECEBIDO

MANTER ESTATÍSTICAS DE TRÁFEGO (HISTORY, MATRIX, HOST, HOSTTOPN) NOS SWITCHES CENTRAIS QUE OBSERVAM A ATIVIDADE NO BACKBONE E OS PADRÕES DE 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 DE PROTOCOLOS

QUALQUER CAMADA ACIMA DE "REDE" É CHAMADA UMA CAMADA DE "APLICAÇÃO", O QUE 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 PROBE CONHECE

PROTOCOL DISTRIBUTION: ESTATÍSTICAS AGREGADAS SOBRE O TRÁFEGO GERADO POR CADA PROTOCOLO EM CADA SEGMENTO DE REDE

ADDRESS MAP: MANTÉM A CORRESPONDÊNCIA ENTRE ENDEREÇOS IP, ENDEREÇOS MAC E PORTAS

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 DOS

HOSTS, 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 COM OS USUÁRIOS FINAIS. USUÁRIOS NA DIVISÃO DE ENGENHARIA ESTÃO RODANDO SIMULAÇÕES E UTILIZAM A REDE CORPORATIVA. AS SIMULAÇÕES PODEM RODAR DURANTE DIAS E PRECISAM DE UM CONJUNTO COMPLEXO DE CONEXÕES CLIENTE/SERVIDOR QUE DEVEM RODAR A VELOCIDADE MÁXIMA DURANTE TODA A SIMULAÇÃO. A PARTIR DE UM CERTO MOMENTO, AS SIMULAÇÕES COMEÇARAM A DEMORAR DUAS VEZES MAIS E A DIVISÃO DE ENGENHARIA ESTÁ CULPANDO A FALTA DE BANDA PASSANTE NA REDE E QUER QUE A REDE ETHERNET DE 10 Mbps MIGRE PARA 100Mbps OU MAIS

METODOLOGIA: O GERENTE DE REDE COLETOU "HISTÓRIAS" DOS PROBES RMON COLOCADOS EM CERTOS LUGARES DA REDE DE ENGENHARIA. ELE ENTÃO PRODUZIU GRÁFICOS MOSTRANDO UTILIZAÇÃO E IDENTIFICANDO OS HOSTS QUE MAIS "FALAM" NA REDE

SOLUÇÃO: O GERENTE DE REDE APRESENTOU SEUS GRÁFICOS E MOSTROU QUE A UTILIZAÇÃO DA REDE NUNCA ULTRAPASSA 10%. PORÉM, QUEM MAIS FALA NA REDE DA ENGENHARIA É UM TERMINAL-X QUE RODA UM SCREEN SAVER EXTREMAMENTE ELABORADO A PARTIR DE UMA ESTAÇÃO DE TRABALHO LOCAL. O SCREEN SAVER É O CULPADO PELA LENTIDÃO DA SIMULAÇÃO. A DIVISÃO DE ENGENHARIA DEIXOU DE RECLAMAR.

CASO 2: PROBLEMA: UM USUÁRIO FINAL NUMA GRANDE EMPRESA FARMACÊUTICA ESTÁ

RECLAMANDO SOBRE UM TEMPO DE RESPOSTAS ANORMALMENTE LENTO QUANDO ACESSA SEUS DADOS DE PESQUISA. A EMPRESA ONDE ELE TRABALHA TEM SERVIDORES NOVELL NUMA REDE LOCAL COMUTADA.

METODOLOGIA: OS SWITCHES TÊM UM ROVING PROBE EMBUTIDO COM SUPORTE TOTAL A RMON (TODOS OS GRUPOS) PARA UMA PORTA QUALQUER DO SWITCH. USANDO ESTE ROVING PROBE, UM FILTRO COM CAPTURA DE PACOTES FOI CONFIGURADO PARA CAPTURAR 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 AO SERVIDOR, HAVIA FREQUENTEMENTE MÚLTIPLAS RESPOSTAS DO SERVIDOR. eSTA ANÁLISE INDICOU QUEDEVERIA HAVER UM PROBLEMA COM O PC OU A PLACA DE REDE OU COM O CABO. UMA INSPEÇÃO VISUAL REVELOU QUE O CABO RJ-45 CONECTANDO O PC AO SWITCH ESTAVA DESGASTADO E A COMUNICAÇÃO ENTRE O PC E TODOS OS HOSTS ESTAVA 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 ACESSO AOS SERVIDORES UNIX VIA TCP/IP. DEPOIS DE UMA HORA, MAIS OU MENOS, O USUÁRIOS COMEÇAM A RELATAR PROBLEMAS COM TEMPO DE RESPOSTA ENVOLVENDO OUTROS PROTOCOLOS E SERVIDORES. EVENTUALEMENTE, DECIDE-SE REBOOTAR OS SERVIDORES. OS PROBE\LEMAS DESAPARECEM POR UM TEMPO MAS VOLTANDO, MAIS RAPIDAMENTE AINDA.

METODOLOGIA: O GERENTE DE REDE DECIDIU INSTRUMENTAR SUAS REDE COM VÁRIOS PROBES RMON. IMEDIATAMENTE, DESCOBRIU QUE A TAXA DE BROADCAST CRESCIAM ATÉ 40% DO TRÁFEGO TOTAL DA REDE. TENDO VISTO ISSO, ELE CONFIGUROU FILTROS PARA CAPTURAR PACOTES DE BROADCAST. a ANÁLISE DOS PACOTES CAPTURADOS REVELOU QUE VÁRIOS DOS SERVIDORES ESTAVAM ENVIANDO PEDIDOS ARP A TAXAS ANORMALMENTE ALTAS. COLOCANDO FILTROS PARA CAPTURAR ALGUMAS CONVERSAS CLIENTE/SERVIDOR, ELE DESCOBRIU QUE CADA PEDIDO DO CLIENTE ESTAVA SENDO REPONDIDO PELOS SERVIDORES NÃO COM UMA RESPOSTA MAS COM UM PEDIDO ARP.

SOLUÇÃO: O GERENTE DE REDE ENTENDEU QUE OS SERVIDORES ESTAVAM PERDENDO A INFORMAÇÃO DA CACHE ARP ASSIM QUE A INFORMAÇÃO ERA DESCOBERTA (ISTO É, A CACHE ARP ESTAVA SENDO ESVAZIADA IMEDIATAMENTE). VERIFICANDO A CONFIGURAÇÃO DOS SERVIDORES, FOI DESCOBERTO QUE O VALOR DE TIMEOUT DA CACHE ARP TINHA SIDO ESTABELECIDA EM MILISSEGUNDOS, EM VEZ DE MINUTOS. o ACERTO 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 DE ENLACES WAN CONECTADOS EM MALHA PERMITINDO ATÉ 3 CAMINHOS ALTERNATIVOS PARA O TRÁFEGO. PERIODICAMENTE, NUMA CERTA HORA DO DIA, USUÁRIOS REMOTOS LIGAM PARA O HELP DESK REPORTANDO SÉRIOS PROBLEMAS DE COMUNICAÇÃO COM O CENTRO DE PROCESSAMENTO DE DADOS. MONTAGENS NFS SÃO PERDIDAS E CONEXÕES

CAEM. TÉCNICOS PROCURAM O PROBLEMA MAS ELE SOME SOZINHO DEPOIS DE UMA HORA.

METODOLOGIA: APÓS COLOCAR PROBES RMON NAS REDES LOCAIS PRINCIPAIS CONECTADAS À WAN, O GERENTE DE REDE DECIDIU ESTABELECER UM BASELINE PARA ESSAS REDES. VÁRIOS LIMIARES "APERTADOS" FORAM ESTABELECIDOS PARA GERAR EVENTOS COM QUALQUER PEQUENO DESVIO DE COMPORTAMENTO DE TRÁFEGO (EM PACOTES POR SEGUNDO). DURANTE UM PERÍODO PROBLEMÁTICO, O PROBE DE UMA REDE LOCAL COMEÇOU A GERAR EVENTOS. O PROBE REPORTOU QUE O TRÁFEGO ESTAVA 10 A 12 VEZES ACIMA DO NORMAL E QUE A UTILIZAÇÃO PASSAVA DE 70%. OS DOIS HOSTS COM MAIOR 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ÁFEGO TINHA ORIGEM E DESTINO FORA DA LAN.

SOLUÇÃO: DESCOBRIU-SE QUE UM DOS ROTEADORES DA WAN ESTAVA CALCULANDO SUA TABELA DE ROTAS DE FORMA ERRADA MAS APENAS DURANTE VERIFICAÇÕES PERIÓDICAS FEITAS POR UM TÉCNICO DURANTE CERTO HORÁRIO DO DIA. EM VEZ DE ROTEAR TRÁFEGO DENTRO DA MALHA WAN, O TRÁFEGO ERA DESVIADO PARA A LAN ONDE SERIA ROTEADO DE VOLTA PARA A WAN ATRAVÉS DE OUTRA ROTA. A LAN TINHA SE TORNADO PARTE DO BACKBONE CORPORATIVO DURANTE UMA HORA ATÉ QUE O ROTEADOR PROBLEMÁTICO VOLTASSE AO COMPORTAMENTO NORMAL. UM PROTOCOLO DE ROTEAMENTO DIFERENTE FOI IMPLANTADO E A LISTA DE CONTROLE DE ACESSO DO ROTEADOR 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 ACIMAPARA SEUS 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 ÚNICO DOMÍNIO DE COLISÃO. A MONITORAÇÃO CONTÍNUA DO TRÁFEGO COM UM PROBE RMON MOSTRA QUE 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ÉM DECIDIRAM SEGMENTAR OS USUÁRIOS DE ACORDO COM OS PROTOCOLOS E OS SERVIDORES USADOS.

SOLUÇÃO: UM PROBE RMON2 MONITORANDO O SEGMENTO DURANTE VÁRIAS SEMANAS MOSTRA QUE 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 DESKTOP MANAGEMENT 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 DE

GERENCIAMENTOOBJETOS

GERENCIADOSATRIBUTOS DOS

OBJETOSFUNÇÕES MÉTRICAS/

RELATÓRIOSNODOS SISTEMAS UNIX

SISTEMAS NTPERIFÉRICOS

HOME DO HOSTRELEASEMODELOFABRICANTENÚMERO DE SÉRIE

MONITORAÇÃO DE STATUSMONITORAÇÃO DE DESEMPENHOLIMIARES NA UTILIZAÇÃO DA CPUEXEMPLO: 90% DURANTE 5 MINUTOS COM REARM DE 80%DIAGNÓSTICO DE PROBLEMASACOMPANHAMENTO DE PROBLEMASACOMPANHAMENTO DE UTILIZAÇÃO DE RECURSOS COM CONTABILIDADE/FATURAMENTOAUDITORIA DE SEGURANÇAESCALONAMENTO DE TAREFAS E BALANCEAMENTO DE CARGALOG DE PROBLEMAS

UTILIZAÇÃO DA CPU

USUÁRIOS E GRUPOS

USUÁRIOSGRUPOS DE USUÁRIOS

USUÁRIONOME DE LOGINSENHALOGIN HABILITADOUIDDIRETÓRIO DE CASASHELLGRUPOSNOMESALA FÍSICAFONESQUOTA DE ESPAÇO EM DISCOGRUPONOMEGIDMEMBROS

ADICIONAR E REMOVER USUÁRIOS E GRUPOSMUDANÇA DE ATRIBUTOSQUOTASPERMISSÕES

ESPAÇO CONSUMIDOLOGINS FEITOS

KERNEL DRIVERSDISPOSITIVOSPROCESSOS

VERSÃO E RELEASEDRIVERSPARÂMETROS DO KERNEL

RECONFIGURAÇÃO DO KERNELIMPLANTAÇÃO DE UM NOVO KERNELMUDANÇA DE

PROCESSOS ATIVOSUTILIZAÇÃO DE MEMÓRIAFÍSICA E VIRTUAL

(TAMANHO DE TABELAS, ...)SUBSISTEMASPARÂMETROS DE DISPOSITIVOSTAMANHO DE PROCESSOSQUANTIDADE DE CPU POR PROCESSO

PRIORIDADE DE PROCESSOSMATAR PROCESSOS

HIT RATE DA CACHE

DISCOS PARTIÇÕESSISTEMAS DE ARQUIVOSCONFIGURAÇÃO DE DISCOSDIRETÓRIOS EXPORTADOSDIRETÓRIOS MONTADOSPARTIÇÃO DE SWAP

SWAPCAPACIDADEESPAÇO USADO/LIVRETIPO (ARQUIVO, PARTIÇÃO)DISPOSITIVOSISTEMA DE ARQUIVOSDISPOSITIVOPARTIÇÃOPONTOS DE MONTAGEM (LOCAL E REMOTO)PERMISSÕES DE EXPORTAÇÃOCAPACIDADEESPAÇO USADO/LIVREESPAÇO MÍNIMO LIVRENOMES DE ARQUIVOS LONGOS/CURTOSPRIORIDADE NA VERIFICAÇÃO DO SISTEMA DE ARQUIVOS

MONITORAÇÃO DE UTILIZAÇÃO DE RECURSOS (ESPAÇO LIVRE)BACKUPSGERÊNCIA DE ESPAÇOLIMIARES NA UTILIZAÇÃO DO ESPAÇO EM SWAPEXEMPLO: 75% DURANTE 5 MINUTOS COM REARM DE 65%MONITORAÇÃO DE STATUSMONITORAÇÃO DE DESEMPENHOLIMIARES NA UTILIZAÇÃO DOS DISCOSEXEMPLO: 90% DURANTE 10 MINUTOS COM REARM DE 80%DIAGNÓSTICO DE PROBLEMASACOMPANHAMENTO DE PROBLEMASACOMPANHAMENTO DE UTILIZAÇÃO DE RECURSOS COM CONTABILIDADE/FATURAMENTO

UTILIZAÇÃO DE CADA UNIDADE FÍSICAUTILIZAÇÃO DE CADA UNIDADE LÓGICAUTILIZAÇÃO DE CADA CONTROLADORATAXA DE I/O PARA CADA UNIDADE FÍSICA/LÓGICA/CONTROLADORAI/O DE DISCO DEVIDO À GERÊNCIA DE MEMÓRIASWAP-IN E SWAP-OUT

SOFTWARE INSTALADO

PRODUTO INSTALADO

NOMEOPÇÕES DE INSTALAÇÃOOPÇÕES DE REMOÇÃODIRETÓRIO DE INSTALAÇÃOSUBPRODUTOS INSTALADOS

GERENCIAMENTO DE LICENÇASINSTALAÇÃO DE NOVO SOFTWAREDESINSTALAÇÃO DE SOFTWARE

INFORMAÇÃO DE CADASTRO

SPOOLING PROTOCOLO DE SPOOLSPOOLER LOCALSPOOLER REMOTO

IMPRESSORAS FÍSICASIMPRESSORAS LÓGICAS (DESTINOS)ARQUIVOS DE ACESSOPARÂMETROS DE CONFIGURAÇÃO

GERÊNCIA DE IMPRESSORASACOMPANHAMENTO DE STATUSDISTRIBUIÇÃO DE RELATÓRIOS

RELATÓRIOS DE PROBLEMAS

INTERFACES DE REDE

PLACAS DE REDE TIPOVELOCIDADE

ACOMPANHAMENTO DE TRÁFEGO

TAXA DE I/O EM PACOTES E

ENDEREÇO IPENDEREÇO MAC

ACOMPANHAMENTO DE TAXAS DE ERROS

BYTES/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 DE LOG 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 QUE FREQUENTEMENTE FAZ PARTE DO SOFTWARE DA APLICAÇÃO

HÁ ESFORÇOS DE ELABORAÇÃO DE MIBs PARA PODER USAR SNMP PARA MONITORAR E CONTROLAR 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 PARA EXAMINAR 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 MAIS GENÉ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ÇÕES IDENTIFICADAS 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