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: [email protected]"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