Gerencia de Redes Snmp

Gerência de Redes de Computadores Objetivos Gerais
Aprender 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 PROGRAMA
1.INTRODUÇÃO À GERÊNCIA DE REDES DE COMPUTADORES 1.1 A NECESSIDADE DE GERÊNCIA 1.2 O QUE É GERÊNCIA 1.3 ARQUITETURA GERAL DE UMA SOLUÇÃO DE GERÊNCIA 1.4 DEMONSTRAÇÕES DE SOLUÇÕES DE GERÊNCIA 2. O NÍVEL DE INSTRUMENTAÇÃO: MODELO DE INFORMAÇÃO 2.1 PADRÕES NO MUNDO DA GERÊNCIA 2.2ARQUITETURA DA SOLUÇÃO SNMP 2.3 OBJETOS, INSTÂNCIAS E MIBs 2.4 A MIB-2 2.5 STRUCTURE OF MANAGEMENT INFORMATION (SMIv1) 2.5.1 OBJECT IDENTIFIERS 2.5.2 MÓDULOS MIB 2.5.3 A ESPECIFICAÇÃO DE UM MÓDULO 2.5.4 DEFINIÇÃO DE OBJETOS GERENCIADOS 2.5.5 REGRAS PARA A DEFINIÇÃO DE OBJETOS E MIBs 2.5.6 DIAGRAMAS CASE 2.5.7 TRAPS 2.5.8 DICAS PARA CRIAR MIBs PROPRIETÁRIAS 2.6 SMI VERSÃO 2 3. O NÍVEL DE INSTRUMENTAÇÃO: MODELO OPERACIONAL 3.1 O PROTOCOLO SNMP 3.2 OPERAÇÕES GET, GETNEXT, GETBULK 3.3 OPERAÇÕES SET, TRAP, INFORM 3.4 MAPEAMENTO PARA A CAMADA DE TRANSPORTE 3.5 BASIC ENCODING RULES (BER) 4. O NÍVEL DE INSTRUMENTAÇÃO: IMPLEMENTAÇÃO 4.1 FONTES DE INFORMAÇÃO E DE CÓDIGO 4.2 USO DO PROTOCOLO SNMP EM JAVA: UMA API E UM GERENTE 5. O NÍVEL DE APLICAÇÃO 5.1 APLICAÇÕES E PLATAFORMAS DE GERÊNCIA 5.2 GERÊNCIA DE CONFIGURAÇÃO 5.3 GERÊNCIA DE FALTAS

5.4 GERÊNCIA DE DESEMPENHO 5.5 REMOTE MONITORING (RMON) 5.6 GERÊNCIA DE HOSPEDEIROS 5.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 CINCO ÁREAS DA GERÊNCIA (EM ORDEM DE IMPORTÂNCIA)

• • • •

O QUE É GERÊ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 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

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

•

•

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 FABRICANTE GERÊNCIA DE DESEMPENHO NETCLARITY LANQUEST SPECTRUM'S ALARM GERÊNCIA DE FALTAS CABLETRON MANAGERS MANIPULAÇÃO DE ALARMES TRAP EXPLODER EMPIRE TECHNOLOGIES GERÊNCIA DE SEGURANÇA BOKS SECURIX GERÊNCIA DE BENS ASSETVIEW HP CONFIGURAÇÃO NETBUILDER 3COM CONFIGURAÇÃO CISCO WORKS CISCO

•

DEMONSTRAÇÕES DE SOLUÇÕES DE GERÊNCIA
• GERÊNCIA AD HOC C:> ping rtbbdsc.campus-ii.ufpb.br Disparando contra rtbbdsc.campus-ii.ufpb.br [150.165.13.61] com 32 bytes de dados: Resposta de 150.165.13.61: bytes=32 tempo=553ms Resposta de 150.165.13.61: bytes=32 tempo=458ms Resposta de 150.165.13.61: bytes=32 tempo=512ms Resposta de 150.165.13.61: bytes=32 tempo=393ms Estatí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.com Rastreando a rota para www.playboy.com [206.251.29.10] com no máximo 30 saltos: 1 2 3 4 145 142 153 220 ms ms ms ms 140 138 143 226 ms ms ms ms 136 136 147 220 ms ms ms ms 200.241.195.28 cgnet2.cgnet.com.br [200.241.195.30] cgnet-S4-4-dist01.rce.embratel.net.br [200.249.241.13] 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.0 system.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ÊNCIA
INTERNET-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

• •

•

DMTF
• • • •

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 DESKTOP MANAGEMENT TASK FORCE LIDERADO PELA MICROSOFT FEITO PARA GERENCIAR PCs NA MESA MODELO DE INFORMAÇÃO ORIENTADO A OBJETO • CIM = COMMON INFORMATION MODEL 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 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 OSI DE GERENCIAMENTO
• • • • • • • • • • • • •

TELECOMMUNICATIONS MANAGEMENT NETWORK (TMN)

•

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 MIBs
MODELO 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 - 2
OBJETOS 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 - 3
OBJETOS E INSTÂNCIAS
• EXEMPLO: • A TABELA DE INTERFACES DE REDE SE CHAMA iso.org.dod.internet.mgmt.mib2.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.mib2.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, GETNEXT, SET, TRAP

•

OBJETOS, INSTÂNCIAS E MIBs - 4
MIBs
• • • • 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-2
GRUPO 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 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

GRUPO interfaces (RFC 1573)

•

A MIB-2
GRUPO at (ADDRESS TRANSLATION - RFC 1213) GRUPO ip (RFC 1573, RFC 1354) 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 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 • • VÁRIOS CONTADORES, ENDEREÇOS, MAPEAMENTO DE ENDEREÇOS, ROTAS, ETC. EM SNMPv2, FOI MOVIDA PARA A IP-MIB E A IP-FORWARDING-MIB • • NÃO É MAIS USADO SÓ TEM VALOR HISTÓRICO

GRUPO tcp (RFC 1354)

A MIB-2
GRUPO udp (RFC 1354)
• • • • • • DATAGRAMAS DESTINADOS A PORTAS DESCONHECIDAS CONTADORES DE DATAGRAMAS ENTRANDO E SAINDO ETC. EM SNMPv2, FOI MOVIDA PARA A UDP-MIB VÁRIAS INFORMAÇÕES (CONTADORES, ETC.) SOBRE O PROTOCOLO SNMP EM SNMPv2, FOI MOVIDA PARA A SNMPv2-MIB

GRUPO snmp (RFC 1907)

MIB-2: WALK NUM AGENTE
FEITO COM O PACOTE CMU-SNMP NUMA ESTAÇÃO SUN
system.sysDescr.0 = "Sun SPARCstation Solaris2. CheckPoint FireWall-1 Version 2.1" system.sysObjectID.0 = OID: enterprises.1919.1.1 system.sysUpTime.0 = Timeticks: (836503909) 96 days, 19:37:19 system.sysContact.0 = "Fernando Barros" system.sysName.0 = "fw.xpto.com.br" system.sysLocation.0 = "Sala 202" system.sysServices.0 = 72 interfaces.ifNumber.0 = 3 interfaces.ifTable.ifEntry.ifIndex.1 = 1 interfaces.ifTable.ifEntry.ifIndex.2 = 2 interfaces.ifTable.ifEntry.ifIndex.3 = 3 interfaces.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 = 8232 interfaces.ifTable.ifEntry.ifMtu.2 = 1500 interfaces.ifTable.ifEntry.ifMtu.3 = 1500 interfaces.ifTable.ifEntry.ifSpeed.1 = Gauge: 10000000 interfaces.ifTable.ifEntry.ifSpeed.2 = Gauge: 10000000 interfaces.ifTable.ifEntry.ifSpeed.3 = Gauge: 10000000 interfaces.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:00 interfaces.ifTable.ifEntry.ifLastChange.2 = Timeticks: (0) 0:00:00 interfaces.ifTable.ifEntry.ifLastChange.3 = Timeticks: (0) 0:00:00 interfaces.ifTable.ifEntry.ifInOctets.1 = 610783 interfaces.ifTable.ifEntry.ifInOctets.2 = 99903685 interfaces.ifTable.ifEntry.ifInOctets.3 = 94029823 interfaces.ifTable.ifEntry.ifInUcastPkts.1 = 0 interfaces.ifTable.ifEntry.ifInUcastPkts.2 = 0 interfaces.ifTable.ifEntry.ifInUcastPkts.3 = 0 interfaces.ifTable.ifEntry.ifInNUcastPkts.1 = 0 interfaces.ifTable.ifEntry.ifInNUcastPkts.2 = 0 interfaces.ifTable.ifEntry.ifInNUcastPkts.3 = 0 interfaces.ifTable.ifEntry.ifInDiscards.1 = 0 interfaces.ifTable.ifEntry.ifInDiscards.2 = 0 interfaces.ifTable.ifEntry.ifInDiscards.3 = 0 interfaces.ifTable.ifEntry.ifInErrors.1 = 0 interfaces.ifTable.ifEntry.ifInErrors.2 = 0 interfaces.ifTable.ifEntry.ifInErrors.3 = 0

MIB-2: WALK NUM AGENTE
interfaces.ifTable.ifEntry.ifInUnknownProtos.1 = 0 interfaces.ifTable.ifEntry.ifInUnknownProtos.2 = 0 interfaces.ifTable.ifEntry.ifInUnknownProtos.3 = 0 interfaces.ifTable.ifEntry.ifOutOctets.1 = 610783 interfaces.ifTable.ifEntry.ifOutOctets.2 = 98517639 interfaces.ifTable.ifEntry.ifOutOctets.3 = 88755644 interfaces.ifTable.ifEntry.ifOutUcastPkts.1 = 0 interfaces.ifTable.ifEntry.ifOutUcastPkts.2 = 0 interfaces.ifTable.ifEntry.ifOutUcastPkts.3 = 0

interfaces.ifTable.ifEntry.ifOutNUcastPkts.1 = 0 interfaces.ifTable.ifEntry.ifOutNUcastPkts.2 = 0 interfaces.ifTable.ifEntry.ifOutNUcastPkts.3 = 0 interfaces.ifTable.ifEntry.ifOutDiscards.1 = 0 interfaces.ifTable.ifEntry.ifOutDiscards.2 = 0 interfaces.ifTable.ifEntry.ifOutDiscards.3 = 0 interfaces.ifTable.ifEntry.ifOutErrors.1 = 0 interfaces.ifTable.ifEntry.ifOutErrors.2 = 5422 interfaces.ifTable.ifEntry.ifOutErrors.3 = 8 interfaces.ifTable.ifEntry.ifOutQLen.1 = Gauge: 0 interfaces.ifTable.ifEntry.ifOutQLen.2 = Gauge: 0 interfaces.ifTable.ifEntry.ifOutQLen.3 = Gauge: 0 interfaces.ifTable.ifEntry.ifSpecific.1 = OID: .ccitt.nullOID interfaces.ifTable.ifEntry.ifSpecific.2 = OID: .ccitt.nullOID interfaces.ifTable.ifEntry.ifSpecific.3 = OID: .ccitt.nullOID ip.ipForwarding.0 = forwarding(1) ip.ipDefaultTTL.0 = 255 ip.ipInReceives.0 = 189046788 ip.ipInHdrErrors.0 = 241 ip.ipInAddrErrors.0 = 0 ip.ipForwDatagrams.0 = 186087726 ip.ipInUnknownProtos.0 = 0 ip.ipInDiscards.0 = 783 ip.ipInDelivers.0 = 1384691 ip.ipOutRequests.0 = 904804 ip.ipOutDiscards.0 = 0 ip.ipOutNoRoutes.0 = 0 ip.ipReasmTimeout.0 = 60 ip.ipReasmReqds.0 = 1624 ip.ipReasmOKs.0 = 1624 ip.ipReasmFails.0 = 0 ip.ipFragOKs.0 = 4 ip.ipFragFails.0 = 0 ip.ipFragCreates.0 = 22 ip.ipAddrTable.ipAddrEntry.ipAdEntAddr.127.0.0.1 = IpAddress: 127.0.0.1 ip.ipAddrTable.ipAddrEntry.ipAdEntAddr.200.252.241.2 = IpAddress: 200.252.241.2 ip.ipAddrTable.ipAddrEntry.ipAdEntAddr.200.252.242.53 = IpAddress: 200.252.242.53 ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = 1 ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.200.252.241.2 = 3 ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.200.252.242.53 = 2 ip.ipAddrTable.ipAddrEntry.ipAdEntNetMask.127.0.0.1 = IpAddress: 255.0.0.0 ip.ipAddrTable.ipAddrEntry.ipAdEntNetMask.200.252.241.2 = IpAddress: 255.255.255.248 ip.ipAddrTable.ipAddrEntry.ipAdEntNetMask.200.252.242.53 = IpAddress: 255.255.255.128 ip.ipAddrTable.ipAddrEntry.ipAdEntBcastAddr.127.0.0.1 = 0 ip.ipAddrTable.ipAddrEntry.ipAdEntBcastAddr.200.252.241.2 = 1 ip.ipAddrTable.ipAddrEntry.ipAdEntBcastAddr.200.252.242.53 = 1

MIB-2: WALK NUM AGENTE
icmp.icmpInMsgs.0 = 61390 icmp.icmpInErrors.0 = 0 icmp.icmpInDestUnreachs.0 = 27 icmp.icmpInTimeExcds.0 = 57101 icmp.icmpInParmProbs.0 = 0 icmp.icmpInSrcQuenchs.0 = 0 icmp.icmpInRedirects.0 = 0 icmp.icmpInEchos.0 = 4208 icmp.icmpInEchoReps.0 = 54 icmp.icmpInTimestamps.0 = 0 icmp.icmpInTimestampReps.0 = 0 icmp.icmpInAddrMasks.0 = 0 icmp.icmpInAddrMaskReps.0 = 0 icmp.icmpOutMsgs.0 = 182290 icmp.icmpOutErrors.0 = 0 icmp.icmpOutDestUnreachs.0 = 90030

icmp.icmpOutTimeExcds.0 = 87547 icmp.icmpOutParmProbs.0 = 0 icmp.icmpOutSrcQuenchs.0 = 0 icmp.icmpOutRedirects.0 = 505 icmp.icmpOutEchos.0 = 0 icmp.icmpOutEchoReps.0 = 4208 icmp.icmpOutTimestamps.0 = 0 icmp.icmpOutTimestampReps.0 = 0 icmp.icmpOutAddrMasks.0 = 0 icmp.icmpOutAddrMaskReps.0 = 0 tcp.tcpRtoAlgorithm.0 = vanj(4) tcp.tcpRtoMin.0 = 200 tcp.tcpRtoMax.0 = 60000 tcp.tcpMaxConn.0 = -1 tcp.tcpActiveOpens.0 = 9892 tcp.tcpPassiveOpens.0 = 3575 tcp.tcpAttemptFails.0 = 175 tcp.tcpEstabResets.0 = 55 tcp.tcpCurrEstab.0 = Gauge: 2 tcp.tcpInSegs.0 = 145450 tcp.tcpOutSegs.0 = 108150 tcp.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 = 1246911 udp.udpNoPorts.0 = 1246911 udp.udpInErrors.0 = 0 udp.udpOutDatagrams.0 = 638087

COMO ESCREVER UMA MIB
EXEMPLO 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) COMO A INFORMAÇÃO DE GERÊNCIA É AGRUPADA E NOMEADA AS OPERAÇÕES PERMITIDAS

SMI DESCREVE:
• •

• •

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 { 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

SINTAXE PARA ESPECIFICAR O VALOR DE UM OID
• • • • •

SMI: IDENTIFICADORES DE OBJETOS (OIDs) - 2
OIDs PODEM REPRESENTAR QUALQUER COISA, NÃO APENAS OBJETOS
• EXEMPLO: IDENTIFICADOR DE PRODUTO (sysObjectID)

SMI: IDENTIFICADORES DE OBJETOS (OIDs) - 3
OIDs 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 MIB
A 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 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 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

MÓDULOS SÃO UM MECANISMO DE ESCOPO DE NOMES
• • •

REGRAS DE FORMAÇÃO DE NOMES DE MÓDULOS
• • • • •

SMI: MÓDULOS MIB - 2
O 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 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

O QUE UM MÓDULO NÃO PODE CONTER

SINTAXE DA DEFINIÇÃO DE UM MÓDULO

Sintaxe: <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 - 3
SINTAXE 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ÓDULO
A 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 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-SMI DisplayString, PhysAddress FROM RFC1213-MIB OBJECT-TYPE FROM RFC-1212 TRAP-TYPE FROM RFC-1515; -- Some or all of the following: -- Textual Conventions -- Registration points -- Groups -- SNMP managed Objects -- SNMP traps END

FORMATO BÁSICO DO MÓDULO
• •

•

SMI: IDENTIFICADORES DE OBJETOS
OBJECT IDENTIFIER É USADO PARA
• • • • • • • PONTOS DE REGISTRO DE ALTO NÍVEL NA ÁRVORE GRUPOS DE OBJETOS VALOR PARA ITENS COM A SINTAXE OBJECT IDENTIFIER COMO PARA NOMES DE MÓDULOS MAS INICIANDO COM LETRA MINÚSCULA 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

REGRAS PARA NOMES GRUPOS

EXEMPLOS
system OBJECT IDENTIFIER ::= { mib-2 1 }

SMI: DEFINIÇÃO DE OBJETOS GERENCIADOS
TRÊS TIPOS DE OBJETOS PODEM SER DEFINIDOS USANDO A MACRO OBJECT-TYPE
• • TABELAS LINHAS DE TABELAS

• •

Onde:

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> <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; e Valores 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; e Valores para <status>, <description>, etc. são definidos depois. Exemplo: ifTable OBJECT-TYPE SYNTAX SEQUENCE OF IfEntry ACCESS not-accessible STATUS 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 e o 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); e Valores para <status>, <description>, etc. serão definidos depois. Exemplo: ifEntry OBJECT-TYPE SYNTAX IfEntry ACCESS not-accessible STATUS mandatory INDEX { 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>"}" <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; e Valores para <leafSyntax>, <access>, <status>, etc. serão definidos depois.

•

Onde:

Exemplos: sysUpTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory ::= { system 2 }

ipAdEntAddr OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS 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> <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) }

• • Onde:

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>] ")" ")" <lower> and <higher> podem ser inteiros positivos ou negativos, strings de bits constantes, ou constantes hexstring; <enumName> inicia com letra minuscula seguida de um número arbitrário de letras, dígitos, e hifen. <enumValue> é um inteiro positivo, constante bitstring ou hexstring que não tenha valor zero <smallest> e <largest> podem ser inteiros nã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)

Onde:

•

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ável SYNTAX OCTET STRING tamanho variável SYNTAX 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 read-only read-write

•

VALORES PARA ACCESS
• •

• •

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 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 STRING DE DESCRIÇÃO PARA APONTAR UM OUTRO LUGAR (OBJETO, DOCUMENTO) QUE DESCREVE O MESMO OBJETO OU DO QUAL O OBJETO DEPENDE

• •

VALORES PARA DESCRIPTION
• • • • •

VALORES PARA REFERENCE

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

VALORES PARA DEFVAL

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 CODIFICAÇÃO DA INSTÂNCIA UM ÚNICO COMPONENTE É USADO

•

TIPO SINTÁTICO INTEGER

STRING DE TAMANHO N COMPONENTES SÃO USADOS, UM PARA CADA BYTE DO STRING. O TIPO FIXO DEVE INDICAR O TAMANHO (VIA CONVENÇÃO TEXTUAL OU NÃO) STRING DE TAMANHO N+1 COMPONENTES SÃO USADOS: O TAMANHO EM BYTES SEGUIDO DOS VARIÁVEL BYTES, UM POR COMPONENTE IpAddress IDENTIFICADOR OBJETO 4 COMPONENTES SÃO USADOS: CADA BYTE DO ENDEREÇO EM "NETWORK ORDER" DE N+1 COMPONENTES SÃO USADOS: O NÚMERO DE COMPONENTES NO VALOR DO OID SEGUIDO DOS COMPONENTES DO VALOR DO OID

NetworkAddress

CINCO 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: TRAPS
USADOS 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 USADO PARA DEFINIR TRAPS SINTAXE SEGUE: <trapItem> = <trapName> "TRAP-TYPE" "ENTERPRISE" <oidName> [ "VARIABLES" "{" <varName>["," <varName>]... "}" ] [ "DESCRIPTION" <description> ] [ "REFERENCE" <reference> ] "::=" <value> <trapName> é o nome do trap sendo definido; <oidName> pode ser "snmp" ou o valor a retornar no campo "enterprise"; <value> é o valor do trap retornado em um dos campos "generic-trap" ou "specific-trap"; e Valores para <varName>, <description>, e <reference> serão definidos depois.

A MACRO TRAP-TYPE
• •

•

Onde:

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 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 PROVÊ TODA A SEMÂNTICA NECESSÁRIA À IMPLEMENTAÇÃO COMO PARA OBJECT-TYPE

VALORES PARA VARIABLES
• • • •

VALORES PARA DESCRIPTION VALORES PARA REFERENCE
• •

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-TYPE ENTERPRISE foo ::= 45 coldStart é um generic trap; e fooTrap é um enterprise-specific trap.

Onde

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ÁRIAS
POR 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 FABRICANTE PARA ESTENDER AS MIBs PADRÃO E AUMENTAR A MONITORAÇÃO E CONTROLE DO

DEVE ADICIONAR NO GALHO enterprises.nomeDaEmpresa COMO 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.

SMIv2
DESCREVEMOS AS MUDANÇAS PRINCIPAIS NA SMIv2 COMPARADA COM SNMv1 DESCRITA ACIMA HÁ 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-ENTITY LAST-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 iso.org.dod.internet.snmpV2.snmpModules (1.3.6.1.6.3) TAMBÉM PODE CONTER REVISÕES COM DATA E DESCRIÇÃO

• • •

OIDs

TAMBÉM

EM

sysObjectID MELHOR DEFINIDOS
OIDs DE PRODUTOS PODEM SER DEFINIDOS COM A MACRO OBJECT-IDENTITY router2522 OBJECT-ODENTITY STATUS 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-CONVENTION DISPLAY-HINT "255a" STATUS current DESCRIPTION "Represents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire 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 may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length." SYNTAX OCTET STRING (SIZE (0..255))

VÁRIAS TEXTUAL CONVENTIONS PRÉ-DEFINIDAS NO MÓDULO SNMPv2TC
• • • • • DisplayString • PhysAddress • MacAddress • TruthValue • TestAndIncr • • OCTET STRING (SIZE(0..255)) OCTET STRING OCTET STRING (SIZE(6)) INTEGER { true(1), false(2) } 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 current DESCRIPTION "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 current DESCRIPTION "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 PROTOCOLO
AS ITERAÇÕES CONSISTEM GERALMENTE DE UM PEDIDO SEGUIDO DE UMA RESPOSTA AS 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 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 SEM ERRO

•

•

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 ERROS SE APLICAM À OPERAÇÃO INTEIRA

•

REPOSTA COM ERRO
•

•

•

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 } PARA COMUNICAÇÃO GERENTE-A-GERENTE • PARA GANHAR ESCALABILIDADE SNMP NUNCA FOI FELIZ NESSA ÁREA MUITO POUCO USADO

DETALHES ADICIONAIS PARA A OPERAÇÃO INFORM
• • •

TRANSPORT MAPPINGS
ENVOLVE 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 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 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 VALOR O 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 a2 1d 02 02 02 30

75 62 6c 69 63 01 11 01 00 01 00 12 30 10

06 08 2b 06 01 02 01 01 01 00 04 04 75 6e 69 78

O NÍVEL DE INSTRUMENTAÇÃO CONSIDERAÇÕES DE IMPLEMENTAÇÃO FONTES DE INFORMAÇÃO E CÓDIGO
UNIX
• • • • 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ÓDIGO
WINDOWS
• • 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 • SnmpSession • • initializeSNMP() • INICIALIZA OS SERVIDORES NECESSÁRIOS PARA A OPERAÇÃO DO PACOTE 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 write SnmpParameters param = new SnmpParameters("ufpbnet", "naosei"); // associa os parametros ao agente agentInfo.setSnmpParam(param); session.setDefaultPeer(agentInfo); ... // faz pedidos, trata respostas session.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 pedido if(!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 = Integer C = Counter T = TimeTicks G = Gauge S = Octet String O = Object ID IP = 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()

• • • • SnmpOctet • SnmpCounter32 • SnmpOid • •

• 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 ARMAZENA UM VALOR DO TIPO SMI "OCTET STRING" ARMAZENA UM VALOR DO TIPO SMIv2 "Counter32" (OU SMIV1 Counter)

•

•

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ÇÃO
CONTEÚ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-ANDFEEL) 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 SIMULTANEAMENTE SOLUÇÕES INCIPIENTES AINDA • VEREMOS ALGUMAS NUM CAPÍTULO À FRENTE

A

GERÊNCIA

•

•

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

SNMPv1

RFC 1213 1157 1155

Título Status Management Information Base for Network Management of TCP/IP-based standard internets: MIB-II A Simple Network Management Protocol (SNMP) standard Structure and Identification of Management Information for TCP/IP-based standard Internets Título Status Coexistence between Version 1 and Version 2 of the Internet-standard Network draft Management Framework Management Information Base for Version 2 of the Simple Network draft Management Protocol (SNMPv2) Transport Mappings for Version 2 of the Simple Network Management Protocol draft (SNMPv2) Protocol Operations for Version 2 of the Simple Network Management Protocol draft (SNMPv2) Conformance Statements for Version 2 of the Simple Network Management draft Protocol (SNMPv2) Textual Conventions for Version 2 of the Simple Network Management Protocol draft (SNMPv2) Structure of Management Information for Version 2 of the Simple Network draft Management Protocol (SNMPv2) Introduction to Community-based SNMPv2 experimental Título Status View-based Access Control Model (VACM) for the Simple Network Management proposed Protocol (SNMP) User-based Security Model (USM) for version 3 of the Simple Network proposed Management Protocol (SNMPv3) SNMPv3 Applications proposed Message Processing and Dispatching for the Simple Network Management Protocol proposed (SNMP) An Architecture for Describing SNMP Management Frameworks proposed Título Status IP Forwarding Table MIB proposed Remote Network Monitoring Management Information Base Version 2 using proposed SMIv2 SNMPv2 Management Information Base for the Internet Protocol using SMIv2 proposed Remote Network Monitoring Management Information Base draft Management Information Base for Network Management of TCP/IP-based standard internets: MIB-II Título Status Definitions of Managed Objects for ATM Management proposed Definitions of Managed Objects for the Ethernet-like Interface Types proposed Definitions of Managed Objects for Classical IP and ARP Over ATM Using proposed SMIv2 (IPOA-MIB) The Interfaces Group MIB using SMIv2 proposed Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2 proposed Definitions of Managed Objects for Bridges draft Título Status Mail Monitoring MIB proposed Relational Database Management System (RDBMS) Management Information proposed Base (MIB) using SMIv2 DNS Resolver MIB Extensions proposed DNS Server MIB Extensions proposed Host Resources MIB proposed

SNMPv2
RFC 1908 1907 1906 1905 1904 1903 1902 1901

SNMPv3
RFC 2275 2274 2273 2272 2271

Network
RFC 2096 2021 2011 1757 1213

Transmission
RFC 2515 2358 2320 2233 2108 1493

Application
RFC 2249 1697 1612 1611 1514

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 MULTIHOMED 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 ADIANTE CONFIGURAÇÃ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 FALTAS
A 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 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

•

•

• •

TAMBÉM CHAMADO DE ISOLAÇÃO DE FALHAS

•

•

•

• 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ÃOUNICAST (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 SUBREDE) QUE NÃO DEVERIA TER CHEGADO NESTA INTERFACE: INDICA UM PROBLEMA • ipOutNoRoutes INDICA DATAGRAMAS JOGADOS FORA DEVIDO À AUSÊNCIA DE ROTA POSSÍVEL: INDICA UM ERRO • ipInHdrErrors INDICA UMA CONDIÇÃO NÃO USUAL MAS NÃO NECESSARIAMENTE UM PROBLEMA • A IF-MIB (RFC 2233) PERMITE GERAR UM TRAP QUANDO O ENLACE MUDA DE ESTADO GERÊNCIA DE FALTAS PARA REDES ETHERNET • EXISTEM TRÊS MIBs PARA IEEE 802.3

•

RFC 2108 PARA REPETIDORES (UM REPETIDOR DE MÚLTIPLAS PORTAS É CHAMADO 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): DESCRIÇÃO USO PARA DETECTAR FALTAS

•

•

VARIÁVEL

dot3StatsAlignmentErr QUADRO NÃO RECONHECIDO POR PROBLEMA NÃO LOCAL ors NÃO TER NÚMERO INTEIRO DE BYTES dot3StatsFCSErrors QUADRO 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 ERRO NÃO LOCAL: SOFTWARE REMOTO COM PROBLEMAS PROBLEMA LOCAL: FALHA NA PLACA DE REDE PROBLEMA LOCAL: FALHA NA PLACA DE REDE

dot3StatsFrameTooLo QUADRO MAIOR QUE O MAIOR ngs QUADRO POSSÍVEL dot3StatsInternalMacR QUADRO NÃO RECEBIDO POR ERRO eceiveErrors INTERNO DA CAMADA MAC ERRO NO TESTE ESPECIAL DE dot3StatsSQETestErro INTERFACE CHAMADO "SIGNAL rs QUALITY ERROR" •

USO DAS VARIÁVEIS DA ETHERLIKE-MIB (CONTINUAÇÃO) • CONTADORES DE SAÍDA (TRANSMISSÃO): DESCRIÇÃO USO PARA DETECTAR FALTAS AQUI SÓ CONTAMOS AS COLISÕES DESTA INTERFACE O SOMATÓRIO DE COLISÕES DEVE SER <= 2% DO TRÁFEGO DESTA INTERFACE

VARIÁVEL

dot3StatsSingleCollisi QUADROS RETRANSMITIDOS COM SE HOUVER COLISÕES DEMAIS NA onFrames SUCESSO APÓS UMA ÚNICA COLISÃO REDE TODA, O TRÁFEGO ESTÁ ALTO DEMAIS SE HOUVER COLISÕES DEMAIS DE UMA ÚNICA INTERFACE, A INTERFACE ESTÁ COM PROBLEMA

dot3StatsMultiplesColl QUADROS RETRANSMITIDOS COM VER COLISÕES ACIMA isionFrames SUCESSO APÓS MAIS DE UMA COLISÃO QUADROS QUE NÃO FORAM dot3StatsDefferedTran TRANSMITIDOS DE PRIMEIRA PORQUE CONDIÇÃO NÃO USUAL smissions O MEIO ESTAVA OCUPADO QUADROS COM COLISÃO DETECTADA REDE LONGA DEMAIS OU ALGUMA dot3StatsLateCollision DEPOIS DO TEMPO MÁXIMO POSSÍVEL PLACA NÃO DETECTA COLISÕES s PARA UMA REDE OPERANDO ADEQUADAMENTE ADEQUADAMENTE QUADROS QUE NÃO FORAM dot3StatsExcessiveCol TRANSMITIDOS POR TEREM SOFRIDO VER COLISÕES ACIMA lisions MAIS DO QUE 16 COLISÕES dot3StatsInternalMacT QUADROS NÃO TRANSMITIDOS POR ransmitErrors ERRO INTERNO DA CAMADA MAC PROBLEMA LOCAL: FALHA NA PLACA DE REDE

dot3StatsCarrierSense PROBLEMA LOCAL: CONEXÃO FROUXA ERROS DE DETECÇÃO DE PORTADORA Errors COM O MEIO UMA TABELA DE FREQUÊNCIAS DE COLISÕES COM 3 COLUNAS: 2 DE ÍNDICE E A FREQUÊNCIA DE COLISÃO VER COLISÕES ACIMA DOS QUADROS. OS ÍNDICES SÃO O ifIndex DA INTERFACE E O NÚMERO POSSÍVEL DE COLISÕES (0 A 15)

dot3CollTable

•

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 DESEMPENHO
SISTEMAS 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 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 MÉDIA DA TAXA DE CHEGADA

• • •

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:

•

µ = 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 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

• •

λ = NÚMERO DE PACOTES/SEGUNDO

•

• •

O QUE É MAIS IMPORTANTE DISSO SÃO AS TAXAS MÉDIAS (λ E µ)

•

•

ρ É 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/µ(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 COMPORTAMENTO NORMAL PARA O DESEMPENHO

DESCREVENDO

O

QUE

É

• 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 PRINCIPALMENTE COMUTADA USUÁRIOS ESTÃO NO MESMO LUGAR FÍSICO CABEAÇÃO PRIVADA EQUIPAMENTOS DOMINAM O CUSTO ALTA VELOCIDADE LARGURA DE BANDA À VONTADE WAN PRINCIPALMENTE ROTEADA USUÁRIOS GEOGRAFICAMENTE DISPERSOS USO DE SERVIÇO DE TELES CUSTO DOMINADO POR ENLACES BAIXA VELOCIDADE LARGURA DE BANDA LIMITADA

•

LARGURA DE BANDA BARATA TEMPO DE RESPOSTA RÁPIDO

LARGURA DE BANDA CARA 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 ORIGEMDESTINO • 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 CONTROLE O 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 HOST O GRUPO alarm

•

•
•

PERMITE ESTABELECER UM INTERVALO DE AMOSTRAGEM E LIMIARES ASSOCIADOS A QUALQUER COUNTER OU INTEGER MANTIDOS PELO PROBE O QUE DEVE SER CONFIGURADO NA TABELA DE CONTROLE: • UM INTERVALO DE AMOSTRAGEM • UMA VARIÁVEL SER MONITORADA • DOIS LIMIARES (PARA CRIAR HISTERESE) • O TIPO DE LIMIAR (ABSOLUTO OU DELTA) • QUANDO GERAR UM EVENTO (CHAMADO "ALARME" PELO RMON) • AO CRUZAR UM DOS LIMIARES, OU O OUTRO, OU AMBOS • UM INDICE DENTRO DA TABELA DE EVENTOS (A SER DISCUTIDA ADIANTE) DIZENDO QUE AÇÃO TOMAR • PODE SER LOGAR O EVENTO E/OU GERAR UM TRAP

O GRUPO event • DESCREVE TODOS OS EVENTOS QUE O PROBE PODE GERAR • UM EVENTO PODE SER GERADO COMO SEGUE: • PELO CRUZAMENTO DE UM LIMIAR (GRUPO alarm) • COMO RESULTADO DE UM FILTRO (VER GRUPO filter ADIANTE) • A DESCRIÇÃO DE UM EVENTO INDICA UMA AÇÃO A SER FEITA

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)

• •

PODE SER LOGAR O EVENTO NA logTable (COM TIMESTAMP E DESCRIÇÃO) PODE GERAR UM TRAP SNMP

•

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 REDE ONDE E COMO USAR RMON NUM SEGMENTO COMPARTILHADO • IDEALMENTE, CADA SEGMENTO COMPARTILHADO TERIA UM PROBE RMON • DEVIDO AO CUSTO ELEVADO, É FREQUENTE USAR PROBES RMON APENAS EM: • BACKBONES • POR QUE AFETAM MUITA GENTE • PERMITE DETECTAR PROBLEMAS QUE AFETAM O CAMPUS INTEIRO • PERMITE MONITORAR TRÁFEGO QUE CRUZA GRUPOS DE TRABALHO E, ASSIM, MELHOR DEFINIR OS GRUPOS DE TRABALHO • SEGMENTOS COM SERVIDORES CRÍTICOS • SEGMENTOS DE GRUPOS DE TRABALHO CRÍTICOS •

•

•

• ISTO É, CRÍTICOS PARA O BUSINESS DA EMPRESA PARA EMERGÊNCIAS, PROBES PORTÁTEIS PODEM SER USADOS E LOCALIZADOS TEMPORARIAMENTE NUM SEGMENTO ONDE 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ÊNCIA UTILIZAÇÃ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 HOSPEDEIROS
TIPOS 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 OBJETOS ATRIBUTOS DOS FUNÇÕES MÉTRICAS/RELATÓ GERENCIAMENTO GERENCIADOS OBJETOS RIOS NODOS SISTEMAS UNIX HOME DO HOST MONITORAÇÃO DE UTILIZAÇÃO DA SISTEMAS NT RELEASE STATUS CPU PERIFÉRICOS MODELO MONITORAÇÃO DE FABRICANTE DESEMPENHO NÚMERO DE SÉRIE LIMIARES NA UTILIZAÇÃO DA CPU EXEMPLO: 90% DURANTE 5 MINUTOS COM REARM DE 80% DIAGNÓSTICO DE PROBLEMAS ACOMPANHAMENT O DE PROBLEMAS ACOMPANHAMENT O DE UTILIZAÇÃO DE RECURSOS COM CONTABILIDADE/F ATURAMENTO AUDITORIA DE SEGURANÇA ESCALONAMENTO DE TAREFAS E BALANCEAMENTO DE CARGA LOG DE PROBLEMAS USUÁRIOS E USUÁRIOS USUÁRIO ADICIONAR E ESPAÇO GRUPOS GRUPOS DE NOME DE LOGIN REMOVER CONSUMIDO USUÁRIOS SENHA USUÁRIOS E LOGINS FEITOS LOGIN GRUPOS HABILITADO MUDANÇA DE UID ATRIBUTOS DIRETÓRIO DE QUOTAS CASA PERMISSÕES SHELL GRUPOS NOME SALA FÍSICA FONES QUOTA DE ESPAÇO EM DISCO GRUPO NOME GID MEMBROS KERNEL DRIVERS VERSÃO E RECONFIGURAÇÃO PROCESSOS ATIVOS DISPOSITIVOS RELEASE DO KERNEL UTILIZAÇÃO DE PROCESSOS DRIVERS IMPLANTAÇÃO DE MEMÓRIA

DISCOS

SOFTWARE INSTALADO

SPOOLING

INTERFACES DE

PARÂMETROS DO UM NOVO KERNEL FÍSICA E VIRTUAL KERNEL MUDANÇA DE HIT RATE DA (TAMANHO DE PRIORIDADE DE CACHE TABELAS, ...) PROCESSOS SUBSISTEMAS MATAR PARÂMETROS DE PROCESSOS DISPOSITIVOS TAMANHO DE PROCESSOS QUANTIDADE DE CPU POR PROCESSO PARTIÇÕES SWAP MONITORAÇÃO DE UTILIZAÇÃO DE SISTEMAS DE CAPACIDADE UTILIZAÇÃO DE CADA UNIDADE ARQUIVOS ESPAÇO RECURSOS FÍSICA CONFIGURAÇÃO USADO/LIVRE (ESPAÇO LIVRE) UTILIZAÇÃO DE DE DISCOS TIPO (ARQUIVO, BACKUPS CADA UNIDADE DIRETÓRIOS PARTIÇÃO) GERÊNCIA DE LÓGICA EXPORTADOS DISPOSITIVO ESPAÇO UTILIZAÇÃO DE DIRETÓRIOS SISTEMA DE LIMIARES NA CADA MONTADOS ARQUIVOS UTILIZAÇÃO DO CONTROLADORA PARTIÇÃO DE DISPOSITIVO ESPAÇO EM SWAP TAXA DE I/O PARA SWAP PARTIÇÃO EXEMPLO: 75% CADA UNIDADE PONTOS DE DURANTE 5 FÍSICA/LÓGICA/CO MONTAGEM MINUTOS COM NTROLADORA (LOCAL E REMOTO) REARM DE 65% I/O DE DISCO PERMISSÕES DE MONITORAÇÃO DE DEVIDO À EXPORTAÇÃO STATUS GERÊNCIA DE CAPACIDADE MONITORAÇÃO DE MEMÓRIA ESPAÇO DESEMPENHO SWAP-IN E SWAPUSADO/LIVRE LIMIARES NA OUT ESPAÇO MÍNIMO UTILIZAÇÃO DOS LIVRE DISCOS NOMES DE EXEMPLO: 90% ARQUIVOS DURANTE 10 LONGOS/CURTOS MINUTOS COM PRIORIDADE NA REARM DE 80% VERIFICAÇÃO DO DIAGNÓSTICO DE SISTEMA DE PROBLEMAS ARQUIVOS ACOMPANHAMENT O DE PROBLEMAS ACOMPANHAMENT O DE UTILIZAÇÃO DE RECURSOS COM CONTABILIDADE/F ATURAMENTO PRODUTO NOME GERENCIAMENTO INFORMAÇÃO DE INSTALADO OPÇÕES DE DE LICENÇAS CADASTRO INSTALAÇÃO INSTALAÇÃO DE OPÇÕES DE NOVO SOFTWARE REMOÇÃO DESINSTALAÇÃO DIRETÓRIO DE DE SOFTWARE INSTALAÇÃO SUBPRODUTOS INSTALADOS PROTOCOLO DE IMPRESSORAS GERÊNCIA DE RELATÓRIOS DE SPOOL FÍSICAS IMPRESSORAS PROBLEMAS SPOOLER LOCAL IMPRESSORAS ACOMPANHAMENT SPOOLER REMOTO LÓGICAS O DE STATUS (DESTINOS) DISTRIBUIÇÃO DE ARQUIVOS DE RELATÓRIOS ACESSO PARÂMETROS DE CONFIGURAÇÃO PLACAS DE REDE TIPO ACOMPANHAMENT TAXA DE I/O EM

REDE

• •

O DE TRÁFEGO PACOTES E ACOMPANHAMENT BYTES/SEG O DE TAXAS DE TAXA DE ERROS ERROS A IMPORTÂNCIA DA AUTOMAÇÃO (SCRIPTS) NA GERÊNCIA DE SISTEMAS A IMPORTÂNCIA DE EXAMINAR ARQUIVOS DE LOG

VELOCIDADE ENDEREÇO IP ENDEREÇO MAC

CERTOS PRODUTOS (CHAMADOS WATCHDOGS) PROCURAM PADRÕES 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

•

EM

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 UTILIZADOS, STATUS, DE PROCESSOS, ETC.

•

VER

RECURSOS

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