Gerência de Redes de Computadores Objetivos Gerais INTRODUÇÃO À GERÊNCIA DE REDES DE COMPUTADORES. Objetivos Específicos

Transcrição

1 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 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. 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 STRUCTURE OF MANAGEMENT INFORMATION (SMIv1) OBJECT IDENTIFIERS MÓDULOS MIB A ESPECIFICAÇÃO DE UM MÓDULO DEFINIÇÃO DE OBJETOS GERENCIADOS REGRAS PARA A DEFINIÇÃO DE OBJETOS E MIBs DIAGRAMAS CASE TRAPS DICAS PARA CRIAR MIBs PROPRIETÁRIAS 2.6 SMI VERSÃO 2 3. O NÍVEL DE APLICAÇÃO 3.1 APLICAÇÕES E PLATAFORMAS DE GERÊNCIA 3.2 GERÊNCIA DE CONFIGURAÇÃO 3.3 GERÊNCIA DE FALTAS 3.4 GERÊNCIA DE DESEMPENHO 3.5 REMOTE MONITORING (RMON) 3.6 GERÊNCIA DE HOSPEDEIROS 3.7 GERÊNCIA DE APLICAÇÕES INTRODUÇÃO À GERÊNCIA DE REDES DE COMPUTADORES A NECESSIDADE DE GERÊNCIA AS REDES ESTÃO FICANDO CADA VEZ MAIS IMPORTANTES PARA AS EMPRESAS NÃO SÃO MAIS INFRA-ESTRUTURA DISPENSÁVEL: SÃO DE MISSÃO CRÍTICA (NÃO PODEM PARAR!) AS REDES SÃO CADA VEZ MAIORES ATINGEM MAIS GENTE NA EMPRESA ATINGEM MAIS LUGARES FÍSICOS DA EMPRESA ATINGEM MAIS PARCEIROS DA EMPRESA ATINGEM ATÉ OS CLIENTES DA EMPRESA AS REDES SÃO CADA VEZ MAIS HETEROGÊNEAS MESCLAGEM DE TECNOLOGIAS MESCLAGEM DE FORNECEDORES AS TECNOLOGIAS SÃO CADA VEZ MAIS COMPLEXAS EXEMPLO: PARA SUPORTAR SERVIÇOS QUE NÃO SEJAM BEST-EFFORT (VÍDEO CONFERÊNCIA,...) A FALTA DE PESSOAL QUALIFICADO CONTINUA RESULTADO: PRECISAMOS DE BOAS SOLUÇÕES PARA GERENCIAR AS REDES GERÊNCIA = TUDO QUE É NECESSÁRIO PARA MANTER AS REDES FUNCIONANDO BEM O QUE É GERÊNCIA? CINCO ÁREAS DA GERÊNCIA (EM ORDEM DE IMPORTÂNCIA) GERÊNCIA DE CONFIGURAÇÃO RESPONSÁVEL PELA DESCOBERTA, MANUTENÇÃO E MONITORAÇÃO DE MUDANÇAS À ESTRUTURA FÍSICA E LÓGICA DA REDE DEVE-SE LEMBRAR QUE A REDE É MUITO DINÂMICA: HAVERÁ CONSTANTES "MOVES, ADDS AND CHANGES" (MAC) FUNÇÕES BÁSICAS: COLETA DE INFORMAÇÕES DE CONFIGURAÇÃO DESCOBRIMENTO DE ELEMENTOS DESCOBRIMENTO DA INTERCONECTIVIDADE ENTRE ELEMENTOS GERAÇÃO DE EVENTOS EMISSÃO DE EVENTOS QUANDO RECURSOS SÃO ADICIONADOS OU REMOVIDOS PERMITE MANTER UM INVENTÁRIO ATUALIZADO ATRIBUIÇÃO DE VALORES INICIAIS AOS PARÂMETROS DOS ELEMENTOS GERENCIADOS REGISTRO DE INFORMAÇÕES REGISTRO DAS INFORMAÇÕES DE CONFIGURAÇÃO, PERMITINDO A EMISSÃO DE RELATÓRIOS FEITO A PARTIR DA INFORMAÇÃO COLETADAS NAS 3 FUNÇÕES ANTERIORES ALTERAÇÃO DE CONFIGURAÇÃO DOS ELEMENTOS GERENCIADOS PARA CORRIGIR FALHA OU PROBLEMA DE SEGURANÇA OU REDIMENSIONAR OU MUDAR A ALOCAÇÃO DE RECURSOS PARA MELHORAR O DESEMPENHO VÊ-SE PORTANTO QUE HÁ RELAÇÃO ENTRE AS VÁRIAS ÁREAS INÍCIO E ENCERRAMENTO DE OPERAÇÃO DOS ELEMENTOS GERENCIADOS GERÊNCIA DE FALTAS RESPONSÁVEL PELA DETECÇÃO, ISOLAMENTO E CONSERTO DE FALHAS NA REDE DETECÇÃO DE FALTAS MANUTENÇÃO E MONITORAÇÃO DO ESTADO DE CADA UM DOS ELEMENTOS GERENCIADOS PERCEPÇÃO DE QUE ESTÁ HAVENDO UM PROBLEMA ISOLAÇÃO DE FALHAS UMA FALTA PODE GERAR UMA FALHA USO DE TÉCNICAS PARA DIAGNOSTICAR A LOCALIZAÇÃO E RAZÃO DA FALHA TÉCNICAS PODEM USAR CORRELAÇÃO DE EVENTOS, TESTES DE DIAGNÓSTICOS,... ANTECIPAÇÃO DE FALHAS MONITORAÇÃO DE INDICADORES QUE POSSAM PREVER A OCORRÊNCIA DE FALHAS TAXAS CRESCENTES DE ERRO, ATRASOS DE TRANSMISSÃO USO DE LIMIARES (THRESHOLD) PARA GERAR ALARMES SUPERVISÃO DE ALARMES INTERFACE DO USUÁRIO INDICA QUAIS ELEMENTOS ESTÃO FUNCIONANDO, QUAIS ESTÃO FUNCIONANDO PARCIALMENTE E QUAIS ESTÃO FORA DE OPERAÇÃO INCLUI NÍVEIS DE SEVERIDADE PODE INDICAR POSSÍVEIS CAUSAS PODE AVISAR VISUALMENTE, COM , PAGER,... AÇÕES NECESSÁRIAS AO RESTABELECIMENTO DOS ELEMENTOS COM PROBLEMAS AÇÕES PODE SER SUGERIDAS AUTOMATICAMENTE TESTES PARA PERMITIR A VERIFICAÇÃO DO FUNCIONAMENTO DE RECURSOS DA REDE EM CONDIÇÕES NORMAIS OU ARTIFICIAIS EXEMPLOS: TESTES DE ECO, DE CONECTIVIDADE PROVÊ REGISTRO DE OCORRÊNCIAS E EMISSÃO DE RELATÓRIOS PARA ANÁLISE GERÊNCIA DE DESEMPENHO RESPONSÁVEL PELA MONITORAÇÃO DE DESEMPENHO, A ANÁLISE DESSE DESEMPENHO E PLANEJAMENTO DE CAPACIDADE SELEÇÃO DE INDICADORES DE DESEMPENHO O DESEMPENHO CORRENTE DA REDE DEVE SE BASEAR EM INDICADORES TAIS COMO ATRASO, VAZÃO, DISPONIBILIDADE, UTILIZAÇÃO, TAXA DE ERROS, ETC. MONITORAÇÃO DE DESEMPENHO MONITORA OS INDICADORES DE DESEMPENHO BASELINE (COMPORTAMENTO NORMAL) PODE SER ESTABELECIDO LIMIARES PODEM SER DEFINIDOS PARA GERAR EVENTOS OU ALARMES MANTÉM REGISTROS HISTÓRICOS PARA PERMITIR A ANÁLISE E PLANEJAMENTO FUTUROS ANÁLISE DE DESEMPENHO E PLANEJAMENTO DE CAPACIDADE ALTERAÇÃO DO MODO DE OPERAÇÃO EXEMPLO: PASSAR DE UM SEGMENTO COMPARTILHADO PARA UMA REDE COMUTADA GERÊNCIA DE SEGURANÇA RESPONSÁVEL PELA PROTEÇÃO DOS ELEMENTOS DA REDE, MONITORANDO E DETECTANDO VIOLAÇÕES DA POLÍTICA DE SEGURANÇA ESTABELECIDA PREOCUPA-SE COM A PROTEÇÃO DOS ELEMENTOS DA REDE DEVE APOIAR A POLÍTICA DE SEGURANÇA DA EMPRESA CRIAÇÃO E MANUTENÇÃO DE SERVIÇOS DE SEGURANÇA PROVÊ MECANISMOS PARA CRIAR, REMOVER E CONTROLAR OS SERVIÇOS DE SEGURANÇA MONITORAÇÃO DOS SERVIÇOS DE SEGURANÇA PODE DISPARAR ALARMES AO DETECTAR VIOLAÇÕES DE SEGURANÇA MANUTENÇÃO DE LOGS DE SEGURANÇA PARA DETECTAR VIOLAÇÕES NÃO ÓBVIAS MANUALMENTE (OU COM PROGRAMAS BATCH AUTOMÁTICOS) GERÊNCIA DE CONTABILIDADE RESPONSÁVEL PELA CONTABILIZAÇÃO E VERIFICAÇÃO DE LIMITES DA UTILIZAÇÃO DE RECURSOS DA REDE, COM A DIVISÃO DE CONTAS FEITA POR USUÁRIOS OU GRUPOS DE USUÁRIOS. COLETA DE INFORMAÇÕES DE UTILIZAÇÃO MONITORA QUAIS RECURSOS E QUANTO DESSES RECURSOS ESTÃO SENDO UTILIZADOS POR QUE ENTIDADE ESTABELECIMENTO DE COTAS DE UTILIZAÇÃO LIMITES DE USO DE RECURSOS POR USUÁRIO OU GRUPO DE USUÁRIOS ESTABELECIMENTO DE ESCALAS DE TARIFAÇÃO PARA DIVIDIR O CUSTO ENTRE USUÁRIOS OU DEPARTAMENTOS DE UMA EMPRESA AS INFORMAÇÕES PODEM SER UTILIZADAS APENAS PARA ESTATÍSTICAS APLICAÇÃO DAS TARIFAS E FATURAMENTO ARQUITETURA GERAL DE UMA SOLUÇÃO DE GERÊNCIA OS 4 COMPONENTES DA ARQUITERURA DE GERÊNCIA OS ELEMENTOS GERENCIADOS DEVEM POSSUIR UM SOFTWARE ESPECIAL PARA PERMITIR SUA GERÊNCIA O SOFTWARE CHAMA-SE DE AGENTE AS ESTAÇÕES DE GERÊNCIA NORMALMENTE CENTRALIZADAS PARA FACILITAR A GERÊNCIA FREQUENTEMENTE SÓ TEM UMA O SOFTWARE QUE CONVERSA DIRETAMENTE COM OS AGENTES NOS ELEMENTOS GERENCIADOS É CHAMADO DE GERENTE POSSUEM FUNÇÕES AUTOMÁTICAS DE GERÊNCIA (EX. POLL REGULAR DOS AGENTES) PODE OBTER INFORMAÇÃO DE GERÊNCIA PRESENTE NOS AGENTES PODEM ALTERAR ESTA INFORMAÇÃO POSSUEM INTERFACE COM O USUÁRIO PARA FACILITAR A GERÊNCIA VEREMOS DETALHES LOGO ADIANTE PROTOCOLO DE GERÊNCIA USADO ENTRE GERENTE E AGENTES PARA TROCAR INFORMAÇÃO DE GERÊNCIA PERMITE OPERAÇÕES DE MONITORAMENTO (READ) E OPERAÇÕES DE CONTROLE (WRITE) INFORMAÇÃO DE GERÊNCIA DEFINE OS DADOS QUE PODEM SER REFERENCIADOS EM OPERAÇÕES DO PROTOCOLO EXEMPLOS: TAXA DE ERRO, STATUS DE UMA LINHA DE COMUNICAÇÃO, ETC. A VISÃO FÍSICA DA REDE GERENCIADA A GERÊNCIA DE REDE NA ARQUITETURA RM-OSI DA ISO

2 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 GERÊNCIA DE FALTAS SPECTRUM'S ALARM 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 [ ] com 32 bytes de dados: Resposta de : bytes=32 tempo=553ms Resposta de : bytes=32 tempo=458ms Resposta de : bytes=32 tempo=512ms Resposta de : bytes=32 tempo=393ms Estatísticas do Ping para : 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 Rastreando a rota para [ ] com no máximo 30 saltos: ms 140 ms 136 ms ms 138 ms 136 ms cgnet2.cgnet.com.br [ ] ms 143 ms 147 ms cgnet-s4-4-dist01.rce.embratel.net.br [ ] ms 226 ms 220 ms ebt-a dist01.rjo.embratel.net.br [ ] ms 196 ms 190 ms ebt-f5-0-0-core01.rjo.embratel.net.br [ ] ms 345 ms 346 ms * 387 ms 366 ms core1-fddi-0.newyork.cw.net [ ] ms 328 ms 413 ms core1-hssi-3.westorange.cw.net [ ] ms 391 ms 430 ms core2.sacramento.cw.net [ ] ms 523 ms 449 ms border8-fddi-0.sacramento.cw.net [ ] ms 634 ms 639 ms globalcenter.sacramento.cw.net [ ] ms 574 ms 593 ms pos m.cr1.snv.globalcenter.net [ ] 13 * 688 ms 654 ms pos m.hr2.snv.globalcenter.net [ ] ms 630 ms 635 ms [ ] 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: ( ) 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 = (ESPERA 5 SEGUNDOS) interfaces.iftable.ifentry.ifinerrors.1 = 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 RESULTADO: A COMPLEXIDADE ESTÁ NAS POUCAS NMSs (NETWORK MANAGEMENT STATIONS) E NÃO NOS MILHARES DE ELEMENTOS GERENCIADOS FRAMEWORK (VERSÃO 1) BASEADO EM TRÊS DOCUMENTOS STRUCTURE OF MANAGEMENT INFORMATION (SMI) - RFC 1155 A LINGUAGEM USADA PARA ESPECIFICAR A INFORMAÇÃO GERENCIADA MANAGEMENT INFORMATION BASE (MIB) PRINCIPAL - RFC 1156 DEFINE AS VARIÁVEIS DE GERÊNCIA QUE TODO ELEMENTO GERENCIADO DEVE TER OUTRAS MIBs EXISTEM PARA FINS PARTICULARES SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) - RFC 1157 O PROTOCOLO USADO ENTRE GERENTE E AGENTE PARA A GERÊNCIA, PRINCIPALMENTE TROCANDO VALORES DE VARIÁVEIS DE GERÊNCIA MODELO BÁSICO OPERACIONAL: "TRAP-BASED POLLING" TRAPS SÃO EVENTOS COMUNICADOS DO AGENTE PARA O GERENTE POLLINGS SÃO CONSULTAS PERIÓDICAS FEITAS PELO GERENTE AOS AGENTES DMTF DESKTOP MANAGEMENT TASK FORCE LIDERADO PELA MICROSOFT FEITO PARA GERENCIAR PCs NA MESA MODELO DE INFORMAÇÃO ORIENTADO A OBJETO CIM = COMMON INFORMATION MODEL ARQUITETURA OSI DE GERENCIAMENTO VEIO DO MUNDO OSI DA ISO DEMOROU MUITO PARA SER FEITO E FOI ADOTADO MUITO POUCO SÓ NO MUNDO DAS TELECOMUNICAÇÕES, JUNTO COM TMN USA MIBs TAMBÉM PROTOCOLO CMIP MUITO MAIS COMPLEXO DO QUE SNMP CMIP = COMMON MANAGEMENT INFORMATION PROTOCOL DEFINE TAMBÉM DE SERVIÇO DE GERÊNCIA (CMIS) CMIS = COMMON MANAGEMENT INFORMATION SERVICE UMA TENTATIVA DE RESGATE FOI FEITA COM CMOT CMOT = CMIP OVER TCP/IP NÃO SERÁ DISCUTIDO NESTE CURSO DEVIDO A SUA POUCA UTILIZAÇÃO TELECOMMUNICATIONS MANAGEMENT NETWORK (TMN) ESPECIALMENTE FEITO PARA GERENCIAR REDES DE TELECOMUNICAÇÕES (TELEFÔNICAS, BASICAMENTE) DESENVOLVIDO PELA CCITT (HOJE ITU-T) BASTANTE USADO ENRE AS OPERADORAS DE TELECOMUNICAÇÕES INCIPIENTE NO BRASIL TMN É UMA REDE PARALELA PARA GERENCIAR A REDE PRINCIPAL INTERCONECTA SISTEMAS DE SUPORTE À OPERAÇÃO (OPERATIONS SYSTEMS) FEITO PARA GERENCIAR: A PRÓPRIA TMN

3 REDES DE TELEFONIA, INCLUINDO TELEFONIA MÓVEL TERMINAIS DE TRANSMISSÃO (MULTIPLEXADORES, EQUIPAMENTOS SDH,...) SISTEMAS DE TRANSMISSÃO ANALÓGICOS E DIGITAIS PABX INFRA-ESTRUTURA (MÓDULOS DE TESTES, SISTEMAS DE ENERGIA,...) ETC. USA PROTOCOLOS OSI ARQUITETURA DA SOLUÇÃO SNMP USA O MODELO FETCH-STORE DE VARIÁVEIS DE GERÊNCIA MANTIDAS NOS AGENTES MUITO SIMPLES MAS PODEROSO AÇÕES ESPECIAIS SÃO EFEITOS COLATERIAIS DE OPERAÇÕES STORE EXEMPLOS: LINK UP, LINK DOWN TRÊS VERSÕES: SNMPv1, SNMPv2, SNMPv3 PRIMITIVAS BÁSICAS (SNMPv1) GET - OBTER O VALOR DE UMA VARIÁVEL GET-NEXT - PERMITE CAMINHAR NAS VARIÁVEIS PARA CAMINHAR EM TABELAS DE TAMANHO DESCONHECIDO; OU QUANDO NÃO SE SABE QUE VARIÁVEIS SÃO SUPORTADAS PELO AGENTE SET - ALTERAR O VALOR DE UMA VARIÁVEL TRAP - INFORMAR EVENTOS EXTRAORDINÁRIOS DO AGENTE PARA O GERENTE MODELO BÁSICO: TRAP-DIRECTED POLLING 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) ONDE SNMP SE INSERE NA PILHA TCP/IP: O MODELO CLIENTE-SERVIDOR DO SNMP: tcpconnlocalport (DIGAMOS 21) tcpconnremaddress (DIGAMOS ) tcpconnremport (DIGAMOS 2059) O VALOR DA COLUNA DE ESTADO DESSA CONEXÃO TERIA IDENTIFICADOR: ESSES IDENDIFICADORES (OBJECT IDENTIFIERS - OIDs) SÃO USADOS NOS COMANDOS GET, GET- NEXT, SET, TRAP 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 IDENTIFICAÇÃO DE UMA VARIÁVEL SIMPLES iso.org.dod.internet.mgmt.mib-2.system.sysdescr 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.mib-2.interfaces.iftable A LINHA SE CHAMA ifentry E CONTÉM VÁRIOS OBJETOS, ENTRE OS QUAIS ifindex E ifdescr CADA INTERFACE TEM UM ifindex ÚNICO (1, 2,...) A DESCRIÇÃO DA PRIMEIRA INTERFACE SERIA: iso.org.dod.internet.mgmt.mib- 2.interfaces.ifTable.ifEntry.ifDescr.1 EXEMPLO: UMA CONEXÃO TCP É IDENTIFICADA POR 4 COLUNAS DA TABELA tcpconntable: tcpconnlocaladdress (DIGAMOS ) 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)

4 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 GRUPO interfaces (RFC 1573) QUANTIDADE DE INTERFACES (ifnumber) A TABELA DE INTERFACES (iftable.ifentry) DESCRIÇÃO DA INTERFACE (ifdescr) TIPO DA INTERFACE (iftype) VELOCIDADE DE TRANSMISSÃO (ifspeed) ENDEREÇO FÍSICO DO MEIO (ifphysaddress) CONTADOR DE BYTES NA ENTRADA (ifinoctets) UM VALOR ÚNICO DE CONTADOR NÃO DÁ INFORMAÇÃO PRECISA PEGAR DOIS VALORES E CALCULAR A DIFERENÇA CONTADOR DE BYTES NA SAÍDA (ifoutoctets) CONTADOR DE ERROS NA ENTRADA (ifinerrors) CONTADOR DE ERROS NA SAÍDA (ifouterrors) EM SNMPv2, FOI SUBSTITUIDA PELA IF-MIB A MIB-2 GRUPO at (ADDRESS TRANSLATION - RFC 1213) NÃO É MAIS USADO SÓ TEM VALOR HISTÓRICO GRUPO ip (RFC 1573, RFC 1354) VÁRIOS CONTADORES, ENDEREÇOS, MAPEAMENTO DE ENDEREÇOS, ROTAS, ETC. EM SNMPv2, FOI MOVIDA PARA A IP-MIB E A IP-FORWARDING-MIB GRUPO icmp (RFC 1573, RFC 1354) VÁRIOS CONTADORES MENSAGENS ENVIADAS E RECEBIDAS, CONTADOR POR TIPO, COM E SEM ERRO, ETC. EM SNMPv2, FOI MOVIDA PARA A IP-MIB E A IP-FORWARDING-MIB GRUPO tcp (RFC 1354) IDENTIFICADOR DO ALGORITMO DE RETRANSMISSÃO NÚMERO MÁXIMO DE CONEXÕES SIMULTÂNEAS PERMITIDAS NÚMERO DE SEGMENTOS ENVIADOS E RECEBIDOS TABELA DE CONEXÕES ETC. EM SNMPv2, FOI MOVIDA PARA A TCP-MIB A MIB-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 GRUPO snmp (RFC 1907) VÁRIAS INFORMAÇÕES (CONTADORES, ETC.) SOBRE O PROTOCOLO SNMP EM SNMPv2, FOI MOVIDA PARA A SNMPv2-MIB MIB-2: WALK NUM 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 system.sysuptime.0 = Timeticks: ( ) 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 interfaces.iftable.ifentry.ifdescr.3 = "le1" Hex: 6C 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: interfaces.iftable.ifentry.ifspeed.2 = Gauge: interfaces.iftable.ifentry.ifspeed.3 = Gauge: interfaces.iftable.ifentry.ifphysaddress.1 = "" interfaces.iftable.ifentry.ifphysaddress.2 = Hex: E 88 2B interfaces.iftable.ifentry.ifphysaddress.3 = Hex: E 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 = interfaces.iftable.ifentry.ifinoctets.2 = interfaces.iftable.ifentry.ifinoctets.3 = 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 = interfaces.iftable.ifentry.ifoutoctets.2 = interfaces.iftable.ifentry.ifoutoctets.3 = 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 = ip.ipinhdrerrors.0 = 241 ip.ipinaddrerrors.0 = 0 ip.ipforwdatagrams.0 = ip.ipinunknownprotos.0 = 0 ip.ipindiscards.0 = 783 ip.ipindelivers.0 = ip.ipoutrequests.0 = 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 = IpAddress: ip.ipaddrtable.ipaddrentry.ipadentaddr = IpAddress: ip.ipaddrtable.ipaddrentry.ipadentaddr = IpAddress: ip.ipaddrtable.ipaddrentry.ipadentifindex = 1 ip.ipaddrtable.ipaddrentry.ipadentifindex = 3 ip.ipaddrtable.ipaddrentry.ipadentifindex = 2 ip.ipaddrtable.ipaddrentry.ipadentnetmask = IpAddress: ip.ipaddrtable.ipaddrentry.ipadentnetmask = IpAddress: ip.ipaddrtable.ipaddrentry.ipadentnetmask = IpAddress: ip.ipaddrtable.ipaddrentry.ipadentbcastaddr = 0 ip.ipaddrtable.ipaddrentry.ipadentbcastaddr = 1 ip.ipaddrtable.ipaddrentry.ipadentbcastaddr = 1 icmp.icmpoutmsgs.0 = icmp.icmpouterrors.0 = 0 icmp.icmpoutdestunreachs.0 = icmp.icmpouttimeexcds.0 = 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 = 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 = tcp.tcpoutsegs.0 = tcp.tcpretranssegs.0 = tcp.tcpconntable.tcpconnentry.tcpconnstate = established(5)... tcp.tcpconntable.tcpconnentry.tcpconnlocaladdress = IpAddress: tcp.tcpconntable.tcpconnentry.tcpconnlocalport = tcp.tcpconntable.tcpconnentry.tcpconnremaddress = IpAddress: tcp.tcpconntable.tcpconnentry.tcpconnremport = udp.udpindatagrams.0 = udp.udpnoports.0 = udp.udpinerrors.0 = 0 udp.udpoutdatagrams.0 = icmp.icmpinmsgs.0 = icmp.icmpinerrors.0 = 0 icmp.icmpindestunreachs.0 = 27 icmp.icmpintimeexcds.0 = 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 MIB-2: WALK NUM AGENTE

5 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 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 GERÊNCIA DE REDE: ELEMENTOS GERENCIADOS: ROTEADORES PONTES SWITCHES HUBS REPETIDORES CABEAMENTO 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 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" 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

6 VÁRIAS OPÇÕES DE ARQUITETURA GRÁFICA (SISTEMA DE JANELAS, LOOK-AND-FEEL) PODE EXISTIR AS APLICAÇÕES DE GERÊNCIA SE "PLUGAM" NA PLATAFORMA UMA API (APPLICATION PROGRAMMING INTERFACE) PERMITE QUE AS APLICAÇÕES ACESSEM OS RECURSOS INTERNOS DA PLATAFORMA (EXEMPLO: BANCO DE DADOS DE TOPOLOGIA) A PLATAFORMA TRATA DE COMUNICAÇÃO DE BAIXO NÍVEL A PLATAFORMA MONITORA (FAZ POLLING E RECEBE TRAPS) A PLATAFORMA PODE SUPORTAR VÁRIOS PROTOCOLO DE GERÊNCIA PADRONIZADOS OU NÃO-PADRONIZADOS, USANDO GATEWAYS A PLATAFORMA MANTÉM VÁRIOS BANCOS DE DADOS DE ELEMENTOS GERENCIADOS E TOPOLOGIA DE USUÁRIOS DE POLÍTICAS DE GERÊNCIA (REGRAS DE GERÊNCIA) DE LOG DE EVENTOS DE SCRIPTS DE AUTOMAÇÃO EX.: CARGA DE PARÂMETROS DE UM ROTEADOR DE HELP DE MIBs AS FUNÇÕES PRINCIPAIS DE UMA PLATAFORMA LEVANTAMENTO DA TOPOLOGIA DA REDE ELABORAÇÃO DE MAPAS DE REDE DANDO VÁRIAS VISÕES DA REDE (FÍSICA, CONECTIVIDADE, DEPARTAMENTAL,...) NOTIFICAÇÕES DE ALARME SÃO FREQUENTEMENTE FEITAS NO MAPA COM UM CÓDIGO DE COR CARGA E MANIPULAÇÃO DE MIBs BROWSING DE MIBs TRATAMENTO DE EVENTOS EVENTOS SÃO GERADOS COM TRAPS OU VIA POLLING PODENDO INCLUIR FILTRAGEM, CORRELAÇÃO, TRANSFORMAÇÃO EM ALARMES INCLUI AVISOS AO USUÁRIO (SONOROS, VISUAIS, , PAGER,...) O DIAGNÓSTICO DE FALHAS (ISOLAÇÃO) É FREQUENTEMENTE FEITO PELAS APLICAÇÕES ADICIONAIS LOG TOTAL DE EVENTOS INTERESSANTES GERAÇÃO DE RELATÓRIOS HELP INTEGRADO INTERFACE VIA EMULAÇÃO DE TERMINAL (TELNET) GERÊNCIA PELA "PORTA DOS FUNDOS" FREQUENTEMENTE USADO DEVIDO À FRACA SEGURANÇA DO SNMP EMPRESAS FREQUENTEMENTE DESABILITAM A OPERAÇÃO "SET" DO SNMP INTEGRAÇÃO DAS APLICAÇÕES (VIDE À FRENTE) VISÃO LÓGICA DE UMA PLATAFORMA COM APLICAÇÕES INTEGRAÇÃO DAS APLICAÇÕES À PLATAFORMA NECESSIDADE DE TER INTEGRAÇÃO SEAMLESS ("SEM COSTURAS") HÁ ENORMES DIFERENÇAS DE NÍVEL DE INTEGRAÇÃO ENTRE APLICAÇÕES E A PLATAFORMA VÁRIAS FORMAS DE INTEGRAÇÃO SEGUEM INTERFACE DO USUÁRIO A APLICAÇÃO POSSUI O MESMO TIPO DE INTERFAEC QUE A PLATAFORMA COM LOOK-AND-FEEL SIMILAR (EX. MOTIF, WINDOWS,...) INTEGRAÇÃO PELO MENU A APLICAÇÃO PODE SER EXECUTADA A PARTIR DO MENU DA PLATAFORMA HELP O HELP DA APLICAÇÃO ESTÁ INTEGRADO COM O HELP DA PLATAFORMA NAVEGAÇÃO ÚNICA, ÍNDICE INTERGADO,... TOPOLOGIA A APLICAÇÃO ACESSA O BD DE OBEJTOS E TOPOLOGIA MANTIDA PELA PLATAFORMA EVITA DUPLICAÇÃO MUITAS APLICAÇÕES FAZEM SEU PRÓPRIO DISCOVERY IMAGINE CADASTRAR 500 ELEMENTOS NA PLATAFORMA E EM 3 APLICAÇÕES DIFERENTES!! BASE DE DADOS A APLICAÇÃO USA O BD DA PLATAFORMA PARA ARMAZENAR SEUS PRÓPRIOS DADOS EVITA DUPLICAÇÃO E PERMITE ACESSO A DADOS VIA SQL PROVAVELMENTE PERMITE MELHORES RELATÓRIOS COM FERRAMENTAS MAIS PODEROSAS DE GERAÇÃO DE RELATÓRIOS MIB AS MIBs NECESSÁRIAS PARA A APLICAÇÃO SÃO CARREGADAS PELA PLATAFORMA E DISPONIBILIZADAS PARA A APLICAÇÃO COMUNICAÇÃO A APLICAÇÃO USA A PLATAFORMA PARA ACESSAR OS ELEMENTOS GERENCIADOS POLL SNMP, ATENDIMENTO A TRAPS, ETC. EVITA POLL DUPLICADO AOS ELEMENTOS EVENTOS OS EVENTOS GERADOS PELA APLICAÇÃO PODEM SER MANIPULADOS PELA PLATAFORMA INSTALAÇÃO A APLICAÇÃO POSSUI UM PROCESSO DE INSTALAÇÃO COMPATÍVEL COM A INSTALAÇÃO DA PLATAFORMA PROCESSOS A APLICAÇÃO ESTÁ INTEGRADA COM OS PROCESSOS QUE EXECUTAM A PLATAFORMA POR EXEMPLO, AO ENCERRAR A PLATAFORMA, A APLICAÇÃO TAMBÉM É ENCERRADA DIAGNÓSTICO (TRACING/LOGGING) A APLICAÇÃO PROVÊ A PLATAFORMA DE INFORMAÇÕES DE DIAGNÓSTICO A RESPEITO DE CONDIÇÕES INESPERADAS PODE-SE ASSIM MANTER UMA ÚNICA BASE DE DADOS DE INFORMAÇÕES DE DIAGNÓSTICO LOCALIZAÇÃO DE ARQUIVOS A APLICAÇÃO SEGUE AS NORMAS DA PLATAFORMA PRAA DAR NOMES AOS ARQUIVOS E EVITAR CONFLITOS DE NOMES COM A PLATAFORMA E COM OUTRAS APLICAÇÕES AS GRANDES PLATAFORMAS OPEN VIEW (HEWLETT PACKARD) NETVIEW (IBM) TIVOLI (IBM) SUNNET MANAGER (SUN MICROSYSTEMS) SPECTRUM (CABLETRON) CA-UNICENTER (COMPUTER ASSOCIATES) GERÊNCIA DISTRIBUÍDA FALTA DE ESCALA NA SOLUÇÃO CENTRALIZADAS APRESENTADA ATÉ AGORA TRÁFEGO DEMAIS INDO PARA A NMS GARGALO DE COMUNICAÇÃO EVENTOS DEMAIS A SEREM TRATADOS PELA NMS GARGALO DE PROCESSADOR FALTA DE MOBILIDADE NA CONSOLE NÃO É PROBLEMA SE USAR INTERFACE WEB NÚMERO LIMITADO DE USUÁRIOS PODEM EXECUTAR A GERÊNCIA SIMULTANEAMENTE SOLUÇÕES INCIPIENTES AINDA VEREMOS ALGUMAS NUM CAPÍTULO À FRENTE A ÚNICA SOLUÇÃO (PARCIAL) MADURA É O USO DE REMOTE MONITORING PROBES (SONDAS DE MONITORAÇÃO REMOTA) ALGUMAS MIBs IMPORTANTES A LISTA COMPLETA DE MIBs DE GERÊNCIA ESTA AQUI FALAREMOS DO CONTEÚDO DE ALGUMAS DESSAS MIBs E DE SUA UTILIDADE PARA O GERENCIAMENTO ADIANTE SNMPv1 RFC Título Status 1213 Management Information Base for Network Management of TCP/IP-based standard internets: MIB-II 1157 A Simple Network Management Protocol (SNMP) standard 1155 Structure and Identification of Management Information for TCP/IP-based standard Internets SNMPv2 RFC Título Status 1908 Coexistence between Version 1 and Version 2 of the Internet-standard Network draft Management Framework 1907 Management Information Base for Version 2 of the Simple Network draft Management Protocol (SNMPv2) 1906 Transport Mappings for Version 2 of the Simple Network Management Protocol draft (SNMPv2) 1905 Protocol Operations for Version 2 of the Simple Network Management Protocol draft (SNMPv2) 1904 Conformance Statements for Version 2 of the Simple Network Management draft Protocol (SNMPv2) 1903 Textual Conventions for Version 2 of the Simple Network Management draft Protocol (SNMPv2) 1902 Structure of Management Information for Version 2 of the Simple Network draft Management Protocol (SNMPv2) 1901 Introduction to Community-based SNMPv2 experiment al SNMPv3 RFC Título Status 2275 View-based Access Control Model (VACM) for the Simple Network Management propose Protocol (SNMP) d 2274 User-based Security Model (USM) for version 3 of the Simple Network propose Management Protocol (SNMPv3) d 2273 SNMPv3 Applications propose d 2272 Message Processing and Dispatching for the Simple Network Management propose Protocol (SNMP) d 2271 An Architecture for Describing SNMP Management Frameworks propose d Network RFC Título Status 2096 IP Forwarding Table MIB proposed 2021 Remote Network Monitoring Management Information Base Version 2 using proposed SMIv SNMPv2 Management Information Base for the Internet Protocol using SMIv2 proposed 1757 Remote Network Monitoring Management Information Base draft 1213 Management Information Base for Network Management of TCP/IP-based standard internets: MIB-II Transmission RFC Título Status 2515 Definitions of Managed Objects for ATM Management proposed 2358 Definitions of Managed Objects for the Ethernet-like Interface Types proposed 2320 Definitions of Managed Objects for Classical IP and ARP Over ATM Using proposed SMIv2 (IPOA-MIB) 2233 The Interfaces Group MIB using SMIv2 proposed 2108 Definitions of Managed Objects for IEEE Repeater Devices using SMIv2 proposed 1493 Definitions of Managed Objects for Bridges draft Application RFC Título Status 2249 Mail Monitoring MIB proposed 1697 Relational Database Management System (RDBMS) Management Information proposed Base (MIB) using SMIv2

7 1612 DNS Resolver MIB Extensions proposed 1611 DNS Server MIB Extensions proposed 1514 Host Resources MIB proposed GERÊNCIA DE CONFIGURAÇÃO CONTEÚDO GERÊNCIA DE TOPOLOGIA GERÊNCIA DE DISPOSITIVOS GERÊNCIA DE TOPOLOGIA HÁ VÁRIOS TIPOS DE TOPOLOGIA VISÃO DE CONECTIVIDADE FÍSICA (TOPOLOGIA FÍSICA): INDICA QUEM ESTÁ FISICAMENTE CONECTADO A QUEM NESTA VISÃO DE TOPOLOGIA, GOSTARÍAMOS DE IR MAIS LONGE AINDA E VER OS DOMÍNIOS DE COLISÃO (ISTO É, ONDE HÁ SEGMENTOS COMPARTILHADOS E ONDE HÁ SWITCHING) VISÃO DE CONECTIVIDADE LÓGICA: ENXERGAR APENAS AS CONEXÕES ENTRE ENDEREÇOS IP (ISTO É, ONDE HÁ ROTEAMENTO) PORTANTO, ESTE TIPO DE TOPOLOGIA EVIDENCIA OS DOMÍNIOS DE BROADCAST E ONDE HÁ ROTEADORES PARA CRUZAR DE UM DOMÍNIO DE BROADCAST PARA OUTRO ESTA VISÃO NÃO MOSTRA HUBS, PONTES E SWITCHES DOMÍNIOS DE BROADCAST PODEM SER FÍSICOS (AGRUPAMENTO FÍSICO VIA HUB/PONTE/SWITCH) OU LÓGICOS (LANs VIRTUAIS - VLANs) VISÃO ADMINISTRATIVA (OU DEPARTAMENTAL): AGRUPAMENTO DOS DISPOSITIVOS DE REDE DE ACORDO COM UM AGRUPAMENTO ADMINISTRATIVO, SEM RELAÇÃO COM ASPECTOS DE CONECTIVIDADE FÍSICA OU LÓGICA VISÃO DE SERVIÇOS: EVIDENCIA OS DISPOSITIVOS DE REDE UTILIZADOS PELOS VÁRIOS SERVIÇOS (EXEMPLO: ) DESTA FORMA, SE O 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: ECHOS, RESPOSTAS, PACOTES ARPs (EM BROADCAST!), RESPOSTAS ARP O QUE MATA É O BROADCAST DE ARP MUITO USADO, APESAR DA CARGA 4. BROADCAST DE UM PACOTE ICMP ECHO USA DIRECTED BROADCAST (ENVIO PARA UMA REDE REMOTA PEDINDO BROADCAST) PARECE BOM SE O ESPAÇO DE ENDEREÇAMENTO É GRANDE (CLASS A, B) MAS TEM POUCOS DISPOSITIVOS NA REDE PODE GERAR MUITO TRÁFEGO E MUITAS COLISÕES NAS PESPOSTAS POR ISSO, NÃO É SUPORTADO EM TODO LUGAR PORQUE MUITOS ROTEADORES DESLIGAM O BROADCAST PARA EVITAR GRANDE TRÁFEGO PODE CRIAR BROADCAST STORMS DEVIDO A MÁS IMPLEMENTAÇÕES DE IP (BROADCAST DE BROADCAST,...) 5. PEDIDO ICMP PARA OBTER MÁSCARA DE SUBREDE AJUDA A DETERMINAR A ESTRUTURA DA REDE PODE AJUDAR A DETECTAR UM PROBLEMA COMUM: MÁSCARAS DE SUBREDE ERRADAS EM INTERFACES DA MESMA REDE 6. PACOTE ICMP ECHO COM TIME-TO-LIVE CRESCENTE TÉCNICA USADA POR TRACEROUTE EXECELENTE PARA DESCOBRIR ROTAS E PORTANTO ROTEADORES MANDA O PACOTE PARA ALGUNS ENDEREÇOS DA REDE REMOTA, NÃO TODOS PORQUE O ROTEAMENTO VAI SER IGUAL 7. ESCUTA BROADCASTS DO PROTOCOLO RIP OS PACOTES RIP CONTÊM TABELAS DE ROTEAMENTO E, PORTANTO, ENDEREÇOS DE REDE E DE ROTEADORES 8. EXAMINAR MAPAS DNS PARA DESCOBRIR MÁQUINAS IMPORTANTES E ROTEADORES USA ZONE TRANSFERS HOJE, ZONE TRANSFERS SÃO FREQUENTEMENTE DESABILITADO POR MOTIVOS DE SEGURANÇA 9. BROADCAST DE PACOTE SNMP TEMPESTADE DE RESPOSTAS PODE ENGARGALAR A REDE QUEM NÃO TEM AGENTE SNMP NÃO É DESCOBERTO 10. USANDO SNMP, EXAMINAR A CACHE ARP DOS ROTEADORES FAZ PARTE DA MIB SÓ PODE SER FEITO QUANDO OS ROTEADORES SÃO DECOBERTOS (VER ADIANTE) 11: USANDO SNMP, APROVEITAR A MONITORAÇÃO PASSIVA DE RMON VEREMOS RMON ADIANTE RMON MANTÉM INFORMAÇÃO SOBRE TUDO QUE VÊ PASSANDO NA REDE E MANTÉM TABELAS QUE DIZEM QUE ENDEREÇOS EXISTEM (INCLUINDO MAC, IP) ESTE É O MÉTODO PREFERIDO MAS AINDA NÃO TEM IMPLANTAÇÃO DE RMON EM ESCALA SUFICIENTE PARA DECOBRIR TUDO SOLUÇÃO TÍPICA: TÉCNICA 3: PING SEQUENCIAL PARA DESCOBRIR DISPOSITIVOS UM POUCO DE AJUDA MANUAL PARA INICIAR (EX.: REDES DE INTERESSE) TÉCNICA 6: TRACEROUTE DE CADA DISPOSITIVO DESCOBERTO PARA DESCOBRIR ROTEADORES TÉCNICA 5: DESCOBRE MÁSCARA DE CADA INTERFACE DE ROTEADORES DESCOBERTA ACIMA TÉCNICA 2 (SEGUNDA PARTE): MANDA ECHO PARA UDP PORTA NÃO USADA (PROVAVELMENTE) E ANOTA O ENDEREÇO IP DA MENSAGEM QUE VOLTA (PARA DESCOBRIR A INTERFACE REMOTA NA QUAL O REPLY SAIU E, ASSIM, DESCOBRIR MULTI- HOMED HOSTS) IDENTIFICA REDES ATRAVÉS DAS CLASSES IP DESCOBERTAS IDENTIFICA SUB-REDES ATRAVÉS DE MÁSCARAS DE SUBREDE TÉCNICA 10: VERIFICA CACHE ARP DE ROTEADORES PARA DESCOBRIR NOVOS DISPOSITIVOS COM TEMPO SEM FAZER UM DESCOBRIMENTO TOTAL DESCOBRIMENTO DA TOPOLOGIA FÍSICA VER LIVRO "HOW TO MANAGE YOUR NETWORK USING SNMP: THE NETWORK MANAGEMENT PRACTICUM", PÁGINA 308 BASEADO NO SNMP E DEPENDE PORTANTO DE TER AGENTES SNMP NOS HUBS, PONTES E SWITCHES DEPENDE DAS MIBS DE REPETIDORES (HUBS) E PONTES HÁ UMA MIB DE DESCOBRIMENTO SENDO ELABORADA PELA IETF MAS PARECE QUE O TRABALHO PAROU NO FINAL DE 1998 DEVIDO A UMA PATENTE DA IBM SEGUEM RESULTADOS DE "DESCOBRIR" A INTERNET: OBTIDO DAQUI: 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 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. 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

8 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 USAMOS OS 2 TERMOS DE FORMA INTERCAMBIÁVEL USO DE TÉCNICAS PARA DIAGNOSTICAR A LOCALIZAÇÃO E RAZÃO DA FALHA TÉCNICAS PODEM USAR CORRELAÇÃO DE EVENTOS, TESTES DE DIAGNÓSTICOS,... USO DE SISTEMAS ESPECIALISTAS SOLUÇÕES EMERGENCIAIS PARA NÃO DEIXAR A REDE PARADA PODE NECESSITAR DE TESTES ADICIONAIS PARA PERMITIR A VERIFICAÇÃO DO FUNCIONAMENTO DE RECURSOS DA REDE EM CONDIÇÕES NORMAIS OU ARTIFICIAIS EXEMPLOS: TESTES DE ECO, DE CONECTIVIDADE RESOLUÇÃO DE PROBLEMAS AÇÕES NECESSÁRIAS AO RESTABELECIMENTO DOS ELEMENTOS COM PROBLEMAS AÇÕES PODE SER SUGERIDAS AUTOMATICAMENTE USO DE SISTEMAS ESPECIALISTAS NOTIFICAÇÃO E TRACKING TAMBÉM CHAMADO SUPERVISÃO DE ALARMES INTERFACE DO USUÁRIO INDICA QUAIS ELEMENTOS ESTÃO FUNCIONANDO, QUAIS ESTÃO FUNCIONANDO PARCIALMENTE E QUAIS ESTÃO FORA DE OPERAÇÃO INCLUI NÍVEIS DE SEVERIDADE PODE INDICAR POSSÍVEIS CAUSAS PODE AVISAR VISUALMENTE, COM , 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 MANDAR UMA MENSAGEM PARA UM PAGER ETC. VER O RESULTADO NA FIGURA ABAIXO 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 TAMBÉM CHAMADO DE ISOLAÇÃO DE FALHAS UMA FALTA PODE GERAR UMA FALHA INTRODUZ HISTERESE PARA EVITAR MÚLTIPLOS EVENTOS QUANDO O VALOR OSCILA A REDOR DO LIMIAR 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" TROUBLE TICKETING USADO PARA CONTROLAR PROBLEMAS E ACOMPANHAR SUA SOLUÇÃO UM TROUBLE TICKET PODE SER ABERTO POR UM USUÁRIO OU AUTOMATICAMENTE PELA PLATAFORMA OU ALGUMA APLICAÇÃO DEPENDE DA POLÍTICA IMPLANTADA NORMALMENTE APLICAÇÕES DE TROUBLE TICKETING PERMITEM RELATÓRIOS SOFISTICADOS SISTEMAS DE TOUBLE TICKETING PODEM SE INTEGRADOS A UM SISTEMA DE HELP DESK GERÊNCIA DE FALTAS PARA INTERFACES USANDO A MIB-2 A MONITORAÇÃO DE INTERFACES PODE SER USADA PARA DETECTAR CONDIÇÕES DE 3 TIPOS DIFERENTES: PROBLEMAS: UMA CONDIÇÃO QUE NECESSITA DA ATENÇÃO DO OPERADOR PODE USAR UM LIMIAR DE ZERO PARA SEMPRE CHAMAR A ATENÇÃO DO OPERADOR CONDIÇÕES NÃO USUAIS: PODEM OCORRER COM BAIXA FREQUÊNCIA MAS PODEM SE TORNAR UM PROBLEMA SE A FREQUÊNCIA AUMENTAR CONDIÇÕES NORMAIS DE CARGA (WORKLOAD): PARA CONTABILIZAR A ATIVIDADE NORMAL DE UMA INTERFACE PODE TAMBÉM DETECTAR PROBLEMAS DE EXCESSO DE CARGA O QUE OLHAR? ifoperstatus NÃO IGUAL A ifadminstatus INDICA UM PROBLEMA iflastchange INDICA QUANDO A INTERFACE MUDOU DE ESTADO ifinerrors E ifouterrors PODEM SER USADOS PARA CALCULAR TAXAS DE ERROS AS TAXAS DE ERROS DEVEM SER BAIXAS E MUITO MENORES DO QUE AS TAXAS DE ENTRADA E SAÍDA DE PACOTES ifindiscards E ifoutdiscards INDICAM PACOTES JOGADOS FORA (DESCARTADOS) DEVIDO A LIMITAÇÕES DE RECURSOS (MEMÓRIA, POR EXEMPLO) AS TAXAS DE DESCARTE DEVEM SER PEQUENAS E MUITO MENORES DO QUE AS TAXAS DE ENTRADA E SAÍDA DE PACOTES ifinucastpkts E ifinnucastpkts INDICAM PACOTES DE ENTRADA COM UNICAST E NÃO-UNICAST (NORMALMENTE BROADCAST) IDEM PARA ifoutucastpkts E ifoutnucastpkts AS TAXAS DE BROADCAST DEVEM SER MUITO PEQUENAS (ATÉ UNS 2% DA CAPACIDADE) NA IF-MIB (VERSÃO EXPANDIDA DO GRUPO interfaces - VER RFC 2233), TEM CONTADORES SEPARADOS PARA BROADCAST E UNICAST ifinunknownprotos SEMPRE INDICA UM PROBLEMA

9 ipforwdatagrams DEVE SER ZERO NUM HOST ipinaddrerrors INDICA UM ENDEREÇO ERRADO (EXEMPLO: DE UMA OUTRA SUB-REDE) QUE NÃO DEVERIA TER CHEGADO NESTA INTERFACE: INDICA UM PROBLEMA ipoutnoroutes INDICA DATAGRAMAS JOGADOS FORA DEVIDO À AUSÊNCIA DE ROTA POSSÍVEL: INDICA UM ERRO ipinhdrerrors INDICA UMA CONDIÇÃO NÃO USUAL MAS NÃO NECESSARIAMENTE UM PROBLEMA A IF-MIB (RFC 2233) PERMITE GERAR UM TRAP QUANDO O ENLACE MUDA DE ESTADO GERÊNCIA DE FALTAS PARA REDES ETHERNET EXISTEM TRÊS MIBs PARA IEEE RFC 2108 PARA REPETIDORES (UM REPETIDOR DE MÚLTIPLAS PORTAS É CHAMADO DE CONCENTRADOR OU HUB) AS VARIÁVEIS SÃO rptr... RFC 2358 PARA A INFORMAÇÃO DE "ETHERNET-LIKE INTERFACE TYPES" (ETHERLIKE-MIB) AS VARIÁVEIS SÃO dot3... RFC 2239 PARA A INFORMAÇÃO DE MEDIA ATTACHMENT UNIT (MAU) BAIXO NÍVEL PARA DIFERENCIAR 10BASET, 10BASE5,..., TIPOS DE CONECTORES, BASEBAND VERSUS BROADBAND, ETC. USO DAS VARIÁVEIS DA ETHERLIKE-MIB iferrors E ifouterrors INDICAM ERROS SE AUMENTAREM, PODE-SE INVESTIGAR OS ERROS COM MAIS CUIDADO ERROS DE ENTRADA (RECEPÇÃO): VARIÁVEL DESCRIÇÃO USO PARA DETECTAR FALTAS dot3statsalignmenter QUADRO NÃO RECONHECIDO POR PROBLEMA NÃO LOCAL rors NÃO TER NÚMERO INTEIRO DE BYTES dot3statsfcserrors QUADRO RECONHECIDO MAS COM FRAME CHECK SEQUENCE (CHECKSUM) ERRADO dot3statsframetoolo QUADRO MAIOR QUE O MAIOR ngs QUADRO POSSÍVEL dot3statsinternalmac ReceiveErrors QUADRO NÃO RECEBIDO POR ERRO INTERNO DA CAMADA MAC ERRO NO TESTE ESPECIAL DE dot3statssqetesterro INTERFACE CHAMADO "SIGNAL rs QUALITY ERROR" 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 USO DAS VARIÁVEIS DA ETHERLIKE-MIB (CONTINUAÇÃO) CONTADORES DE SAÍDA (TRANSMISSÃO): VARIÁVEL DESCRIÇÃO USO PARA DETECTAR FALTAS dot3statssinglecollisi QUADROS RETRANSMITIDOS COM onframes SUCESSO APÓS UMA ÚNICA COLISÃO AQUI SÓ CONTAMOS AS COLISÕES DESTA INTERFACE O SOMATÓRIO DE COLISÕES DEVE SER <= 2% DO TRÁFEGO DESTA INTERFACE SE HOUVER COLISÕES DEMAIS NA REDE TODA, O TRÁFEGO ESTÁ ALTO DEMAIS dot3statsdefferedtra nsmissions dot3statslatecollisio ns QUADROS QUE NÃO FORAM TRANSMITIDOS DE PRIMEIRA PORQUE O MEIO ESTAVA OCUPADO CONDIÇÃO NÃO USUAL QUADROS COM COLISÃO DETECTADA REDE LONGA DEMAIS OU ALGUMA DEPOIS DO TEMPO MÁXIMO POSSÍVEL PLACA NÃO DETECTA COLISÕES PARA UMA REDE OPERANDO ADEQUADAMENTE ADEQUADAMENTE QUADROS QUE NÃO FORAM dot3statsexcessiveco TRANSMITIDOS POR TEREM SOFRIDO VER COLISÕES ACIMA llisions MAIS DO QUE 16 COLISÕES dot3statsinternalmac TransmitErrors dot3statscarriersense Errors dot3colltable QUADROS NÃO TRANSMITIDOS POR ERRO INTERNO DA CAMADA MAC PROBLEMA LOCAL: FALHA NA PLACA DE REDE PROBLEMA LOCAL: CONEXÃO ERROS DE DETECÇÃO DE PORTADORA FROUXA 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) 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 SE HOUVER COLISÕES DEMAIS DE UMA ÚNICA INTERFACE, A INTERFACE ESTÁ COM PROBLEMA QUADROS RETRANSMITIDOS COM dot3statsmultiplescol SUCESSO APÓS MAIS DE UMA lisionframes COLISÃO VER COLISÕES ACIMA EXEMPLOS BANCO SUPERMERCADO ENLACE DE COMUNICAÇÃO DE DADOS NA FIGURA ACIMA: λ É A MÉDIA DA TAXA DE CHEGADA µ É A MÉDIA DA TAXA DE SERVIÇO TOMANDO O EXEMPLO DE UM ENLACE DE COMUNICAÇÃO DE DADOS USANDO COMUTAÇÃO DE PACOTES OS FREGUESES SÃO PACOTES (OU QUADROS, ETC., DEPENDENDO DA CAMADA) O SERVIDOR É O CANAL DE TRANSMISSÃO A FILA SE FORMA PORQUE NOVOS PACOTES PODEM CHEGAR ENQUANTO UM QUADRO ESTÁ SENDO TRANSMITIDO COMO CARACTERIZAR λ E µ? TEM VÁRIAS FORMAS, DESDE QUE AS UNIDADES SEJAM IGUAIS EXEMPLO: SE EXPRESSARMOS λ E µ EM BITS POR SEGUNDO, ENTÃO: λ = NÚMERO DE PACOTES/SEGUNDO µ = C/L C = CAPACIDADE DO CANAL EM BITS POR SEGUNDO L = TAMAMHO MÉDIO DE UM PACOTE EM BITS O QUE DETERMINA O DESEMPENHO DA FILA SÃO BASICAMENTE OS PROCESSOS ESTOCÁSTICOS QUE REGEM A ENTRADA E O SERVIÇO O QUE É MAIS IMPORTANTE DISSO SÃO AS TAXAS MÉDIAS (λ E µ) E PRINCIPALMENTE A UTILIZAÇÃO DO SERVIDOR ( ρ = λ/µ) A UTILIZAÇÃO PODE SER VISTA COMO O PERCENTUAL DE OCUPAÇÃO DO SERVIDOR É UM NÚMERO ENTRE 0 E 1 A UTILIZAÇÃO INSTANTÂNEA VARIA COM TEMPO ρ É A UTILIZAÇÃO MÉDIA PODEMOS JUNTAR VÁRIAS FILAS E FORMAR UMA REDE DE FILAS EXEMPLO: PARA MODELAR UMA REDE DE COMPUTADORES EXERCÍCIO: QUAL SERIA A REDE DE FILAS PARA A SEGUINTE REDE DE COMPUTADORES, SE O CÍRCULOS REPRESENTAM PONTOS DE ENTRADA E SAÍDA DE TRÁFEGO E AS INHAS 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 ( KM/SEG), OU 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 REPRESENTAM ENLACES DE COMUNICAÇÃO FULL-DUPLEX? MEDIDAS DE DESEMPENHO DE INTERESSE VAZÃO (ρc BITS POR SEGUNDO) TEMPO DE RESPOSTA

10 RESULTADO É UMA REGRA BÁSICA DA AVALIAÇÃO DE DESEMPENHO QUE A UTILIZAÇÃO DE QUALQUER RECURSO COMPARTILHADO DEVE FICAR ABAIXO DO JOELHO DA CURVA DE DESEMPENHO OBSERVE QUE PARA CERTAS TECNOLOGIAS COMO ETHERNET, AS COLISÕES NOS FAZEM PERDER CAPACIDADE E, PORTANTO, NÃO PODEMOS PASSAR DE UNS 50% (SE FOR UM MEIO COMPARTILHADO) UMA SEGUNDA REGRA BÁSICA DA AVALIAÇÃO DE DESEMPENHO É QUE UM MAU DESEMPENHO INDICA ALGUM GARGALO NUM LUGAR LOCALIZADO E NÃO, EM GERAL, UM PROBLEMA GENERALIZADO DE DESEMPENHO DEVE-SE LOCALIZAR O GARGALO PODEMOS TAMBÉM RELACIONAR O TEMPO MÉDIO DE RESPOSTA (OU DE ESPERA) COM A TAMANHO DA FILA ATRAVÉS DA LEI DE LITTLE: N = λw = ρ/(1-ρ) ONDE N = TAMANHO MÉDIO DA FILA OUTRAS MEDIDAS DE DESEMPENHO: CONFIABILIDADE PODE SER CONSIDERADO COMO SENDO DISPONIBILIDADE (% DISPONÍVEL) 95%: PARA TESTES OU PROTÓTIPOS (438 HORAS/ANO DE DOWNTIME) 99,5%: BAIXA DISPONIBILIDADE (44 HORAS/ANO DE DOWNTIME) 99,95%: BOA DISPONIBILIDADE (4 HORAS/ANO DE DOWNTIME) 99,98%: ALTA DISPONIBILIDADE (2 HORAS/ANO DE DOWNTIME) 99,99%: LIMITE SUPERIOR ATUALMENTE (50 MINUTOS/ANO DE DOWNTIME) OU PODE SER RECUPERABILIDADE DUAS MEDIDAS MEAN TIME BETWEEN FAILURE (MTBF) MEAN TIME TO REPAIR (MTTR) DISPONIBILIDADE = MTTR/(MTTR+MTBF) PRIMEIRA FACETA DA GERÊNCIA DE DESEMPENHO: DESCOBRINDO PROBLEMAS A GERÊNCIA DE DESEMPENHO POSSUI VÁRIAS FACETAS UMA DELAS É PRESTAR ATENÇÃO ÀS MEDIDAS DE DESEMPENHO E ALERTAR QUANDO ALGO NÃO VAI BEM ISSO PODE SER FEITO DA SEGUINTE FORMA ADQUIRE UM BASELINE DE DESEMPENHO DESCREVENDO O QUE É COMPORTAMENTO NORMAL PARA O DESEMPENHO ISTO É, AS VÁRIAS MEDIDAS ESCOLHIDAS PARA RETRATAR O DESEMPENHO DA REDE ISSO É FEITO AO LONGO DE ALGUMAS SEMANAS DE OPERAÇÃO AJUSTA-SE THRESHOLDS ACIMA DOS VALORES NORMAIS PARA GERAR EVENTOS QUANDO O DESEMPENHO CRUZAR OS LIMIARES TIPICAMENTE TEM 2 LIMIARES: ADVERTÊNCIA E CRÍTICO SEGUNDA FACETA DA GERÊNCIA DE DESEMPENHO: PLANEJAMENTO DE CAPACIDADE CONSISTE EM OBSERVAR O DESEMPENHO COM TEMPO E: ANALISAR TENDÊNCIAS BALANCEAR A CARGA DA REDE ENTRE RECURSOS PLANEJAMENTO DE EXPANSÕES (OU MUDANÇAS) DE CONFIGURAÇÃO DA REDE IMPLICA EM GUARDAR DADOS HISTÓRICOS DE MEDIDAS DE DESEMPENHO DADOS JOGADOS FORA DEPOIS DE UM TEMPO MAS NÃO OS "EVENTOS" (GUARDA "PARA SEMPRE") QUE ESTATÍSTICAS DE DESEMPENHO INTERESSAM? PARA INTERFACES UTILIZAÇÃO DOS ENLACES, POR HORA PODE INCLUIR DISTRIBUIÇÃO DE FREQUÊNCIA COM HISTOGRAMA (0-20%, 20%-60%, 60%-100%) UTILIZAÇÃO DAS INTERFACES, POR PROTOCOLO QUALIDADE DOS ENLACES, POR HORA FRAÇÃO DE ERROS NA ENTRADA E NA SAÍDA NÚMERO TOTAL DE ERROS DISPONIBILIDADE PIORES INTERFACES, DIARIAMENTE PARA ROTEADORES UTILIZAÇÃO DE CPU UTILIZAÇÃO DE MEMÓRIA DISPONIBILIDADE TAXA DE DESCARTE TAXA TOTAL DE PACOTES CHAVEADOS POR SEGUNDO PARA LANS ETHERNET COLISÕES DEVEM FICAR EM, NO MÁXIMO, 3% ALGUNS ADMINISTRADORES TOLERAM ATÉ 5% PARA HOSTS (NO QUE DIZ RESPEITO À REDE APENAS, POR ENQUANTO) TAXA DE RETRANSMISSÃO TCP EXERCÍCIO MOSTRE COMO USAR SNMP PARA OBTER AS MEDIDAS DE DESEMPENHO DISCUTIDAS ACIMA OBSERVE QUE NENHUMA MEDIDA ACIMA NOS FORNECE TEMPO DE RESPOSTA SNMP NÃO FORNECE ISSO POIS NÃO MEDE NADA FIM-A-FIM PODE USAR PING E/OU TRACEROUTE E/OU PATHCHAR PARA OBTER ESSES VALORES AINDA TEREMOS MUITO A FALAR SOBRE COMO OBTER MEDIDAS DE DESEMPENHO QUANDO FALARMOS DE RMON (REMOTE MONITORING) ADIANTE DIFERENÇAS ENTRE GERENCIAMENTO DE LANs E WANs LEI BÁSICA: "O GARGALO DE DESEMPENHO É A WAN" O MOTIVO PODE SER VISTO NA SEGUINTE TABELA COMPARATIVA ENTRE LANs E WANs PORTANTO, PARA DESEMPENHO, OLHO NA WAN! LAN WAN PRINCIPALMENTE COMUTADA USUÁRIOS ESTÃO NO MESMO LUGAR FÍSICO CABEAÇÃO PRIVADA EQUIPAMENTOS DOMINAM O CUSTO ALTA VELOCIDADE LARGURA DE BANDA À VONTADE LARGURA DE BANDA BARATA 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 CARA TEMPO DE RESPOSTA RÁPIDO TEMPO DE RESPOSTA MAIS LENTO TÉCNICAS DE CONSERVAÇÃO DE LARGURA DE BANDA DEVIDO À CRITICALIDADE DA WAN NO QUE DIZ RESPEITO AO DESEMPENHO, BONS ROTEADORES NOS AJUDAM A CONSERVAR LARGURA DE BANDA ALGUMAS TÉCNICAS SÃO MENCIONADAS ABAIXO O ROTEADOR NÃO PROPAGA BROADCAST PARA A WAN (UFA!) ROTEADORES SUPORTAM VÁRIOS PROTOCOLOS DE ROTEAMENTO DE FORMA AO ADMINISTRADOR PODER ESCOLHER UM DELES EM FUNÇÃO DE SUAS NECESSIDADES UMA FORMA DE ESCOLHER É DE LEVAR A QUANTIDADE DE TRÁFEGO GERADO PELO PROTOCOLO EXEMPLO: RIP GERA MAIS TRÁFEGO QUE OSPF ROTEADORES PODE USAR BANDWIDTH-ON-DEMAND QUANDO UM ENLACE CONGESTIONA UM ENLACE DISCADO PODE SER USADO PARA DAR MAIS LARGURA DE BANDA A GENERALIZAÇÃO DISSO USANDO VÁRIAS TECNOLOGIAS PARA FORMAR UM ÚNICO ENLACE É "BANDWIDTH AGGREGATION" USANDO "MULTILINK PPP", PODE-SE COMBINAR: ENLACES PRIVADOS, ENLACES TELEFÔNICOS COMUTADOS (POTS), ISDN,...) O ROTEADOR PODE USAR COMPRESSÃO DE DADOS 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 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 O ROTEADOR PODE IMPLEMENTAR O PROTOCOLO RSVP PARA RESERVAR RECURSOS E GARANTIR

11 (OU QUASE) A QUALIDADE DO SERVIÇO (QoS) REMOTE MONITORING (RMON) O APARECIMENTO DE RMON É O EVENTO MAIS SIGNIFICATIVO NO MUNDO SNMP DESDE A INVENÇÃO DO PRÓPRIO SNMP QUAIS SÃO OS PROBLEMAS COM SNMP QUE LEVARAM AO APARECIMENTO DE RMON? O POLLING CENTRALIZADO A PARTIR DE UMA ESTAÇÃO DE GERÊNCIA NÃO TEM ESCALA O TRÁFEGO DE GERÊNCIA PODE PIORAR A SITUAÇÃO DA REDE, ESPECIALMENTE EM ENLACES WAN O TRABALHO INTEIRO ESTÁ SENDO FEITO PELA ESTAÇÃO DE GERÊNCIA, IMPONDO UM LIMITE SUPERIOR NO NÚMERO DE SEGMENTOS DE REDE MONITORADOS AS MIBs EXISTENTES SÓ FORNECEM INFORMAÇÃO SOBRE EQUIPAMENTOS INDIVIDUAIS E NÃO SOBRE SEGMENTOS INTEIROS EXEMPLO: É DIFÍCIL OBTER UMA MATRIZ DE TRÁFEGO ENTRE ORIGEM-DESTINO A MONITORAÇÃO PÁRA QUANDO HÁ UMA QUEBRA DE CONECTIVIDADE ENTRE A ESTAÇÃO DE GERÊNCIA E PARTES REMOTAS DA REDE SOLUÇÃO QUE RMON TRAZ: DISTRIBUIR AS RESPONSABVILIDADES DE FORMA A COLOCAR INTELIGÊNCIA NUMA SONDA REMOTA (REMOTE PROBE) PARA MONITORAR SEGMENTOS DE REDE POR ENQUANTO, BASTA IMAGINAR UM PROBE PERMANENTEMENTE LOCALIZADO NUM SEGMENTO COMPARTILHADO DE REDE E MONITORANDO-O EM MODO PROMÍSCUO O PROBE SABE TUDO QUE PASSA NO SEGMENTO DE REDE VEREMOS O QUE FAZER COM SWITCHES DEPOIS O PROBE PODE SER STANDALONE OU ESTAR EMBUTIDO EM OUTRO EQUIPAMENTO (HUB, SWITCH, ROTEADOR) OU ATÉ EM NETWORK INTERFACE CARDS (NIC - OU PLACAS DE REDE) A ESTAÇÃO DE GERÊNCIA ACESSA O PROBE PARA OBTER INFORMAÇÃO MASTIGADA A INFORMAÇÃO MASTIGADA É APRESENTADA SOB FORMA DE UMA MIB PORTANTO, RMON FORNECE O EMBRIÃO DE UMA SOLUÇÃO DE GERÊNCIA DISTRIBUÍDA QUANDO RMON FOI INVENTADA, OS SEGUINTES OBJETIVOS DE PROJETO FORAM LEVADOS EM CONSIDERAÇÃO OPERAÇÃO OFF-LINE UM MONITOR (PROBE) DEVE COLETAR INFORMAÇÃO SOBRE FALTAS, DESEMPENHO E CONFIGURAÇÃO MESMO QUANDO NÃO ESTÁ SENDO ACESSADO POR UM GERENTE AS ESTATÍSTICAS SÃO ACUMULADAS PARA ACESSO FUTURO PELO GERENTE O PROBE PODE TENTAR AVISAR O GERENTE (VIA TRAP) SE HOUVER UM EVENTO EXCEPCIONAL O PROBE DEVE PODER DETECTAR CONDIÇÕES DE ERRO E REPORTÁ-LAS PARA TANTO, O PROBE DEVE SER ALTAMENTE CONFIGURÁVEL (PARA INDICAR O QUE MONITORAR, O QUE VERIFICAR, QUE AÇÃO TOMAR QUANDO HÁ UMA CONDIÇÃO EXCEPCIONAL, ETC.) PARA REPORTAR UMA CONDIÇÃO DE ERRO, NÃO E SUFICIENTE ENVIAR UM TRAP O TRAP PODE SER PERDIDO DEVE HAVER MECANISMO DE LOG PARA QUE A ESTAÇÃO DE GERÊNCIA EXAMINE EVENTOS QUE OCORRERAM NO PASSADO E LOGADOS PELO PROBE O PROBE DEVE PODER FAZER CERTOS TIPOS DE ANÁLISE NOS DADOS COLETADOS EXEMPLO: ORDENAR OS HOSTS DO SEGMENTO POR ORDEM DE TRÁFEGO, ERRO, ETC. DEATA FORMA, A ESTAÇÃO DE GERÊNCIA NÃO TEM QUE PEGAR TODOS OS DADOS E ANALISÁ-LOS: BASTA PEGAR OS DADOS MAIS IMPORTANTES O PROBE DEVE SER CONTROLÁVEL POR MAIS DE UM GERENTE PODE HAVER MAIS DE UM GERENTE POR MOTIVOS DE CONFIABILIDADE, POR TEREM FUNCIONALIDADES DIFERENTES, POR ATENDEREM A UNIDADES DIFERENTES DE UMA ORGANIZAÇÃO, ETC. PARA CONTROLAR UM PROBE, A MIB (DO AGENTE DENTRO DO PROBE) TEM VÁRIAS TABELAS DE CONTROLE E SETAR VARIÁVEIS NESTAS TABELAS AFETA A OPERAÇÃO DO PROBE AS TABELAS CONTÊM UMA VARIÁVEL PARA CONTER O NOME DO GERENTE QUE CONTROLA ("POSSUI") UMA LINHA DA TABELA APENAS ESTE GERENTE PODE ALTERAR A LINHA (MUDAR A CONFIGURAÇÃO) A MIB RMON RFC 1757 (EXTENSÃO PARA TOKEN RING NA RFC 1513) CONTÉM 10 GRUPO OPCIONAIS O GRUPO statistics MANTÉM ESTATÍSTICAS DE UTILIZAÇÃO E DE ERROS PARA CADA SEGMENTO MONITORADO PELO PROBE O PROBE PODE TER MAIS DE UMA INTERFACE E SE CONECTAR A MAIS DE UM SEGMENTO DE REDE E MONITORAR CADA UM DELES HÁ UMA TABELA CONTENDO BASICAMENTE CONTADORES PARA O SEGMENTO INTEIRO SE APLICA A UM SEGMENTO ETHERNET EXTENSÃO PARA TOKEN RING NA RFC 1513 CONTÉM O QUE JÁ TEM NA MIB-2 E NA ETHER-LIKE MIB (dot3stats) MAS CONTA PARA O SEGMENTO INTEIRO OS CONTADORES DA TABELA statistics etherstatsdropevents: NÚMERO DE VEZES QUE PACOTES DEIXARAM DE SER TRATADOS PELO PROBE DEVIDO À FALTA DE RECURSOS etherstatsoctets: NÚMERO DE BYTES RECEBIDOS INCLUINDO PACOTES ERRADOS etherstatspkts: NÚMERO DE PACOTES (QUADROS) RECEBIDOS INCLUINDO PACOTES NORMAIS, PACOTES ERRADOS, PACOTES DE DE BROADCAST E DE MULTICAST etherstatsbroadcastpkts: NÚMERO DE PACOTES DE BROADCAST etherstatsmulticastpkts: NÚMERO DE PACOTES DE MULTICAST etherstatscrcalignerrors: NÚMERO DE PACOTES RECEBIDOS COM TAMANHO CORRETO (ENTRE 64 E 1518 BYTES) MAS COM ERRO DE CRC OU DE ENQUADRAMENTO (NÚMERO DE BITS NÃO É MÚLTIPLO DE 8) etherstatsundersizepkts: NÚMERO DE PACOTES BEM FORMADOS MAS MENORES QUE 64 BYTES etherstatsoversizepkts: NÚMERO DE PACOTES BEM FORMADOS MAS MAIORES QUE 1518 BYTES etherstatsfragments: NÚMERO DE PACOTES MENORES QUE 64 BYTES E COM ERROS DE CRC OU DE ENQUADRAMENTO (RESULTADOS DE COLISÃO, PROVAVELMENTE) etherstatsjabbers: NÚMERO DE PACOTES MAIORES QUE 1518 BYTES E COM ERROS DE CRC OU DE ENQUADRAMENTO etherstatscollisions: NÚMERO TOTAL DE COLISÕES etherstatspkts64octets: NÚMERO DE PACOTES COM TAMANHO 64 BYTES etherstatspkts65to127octets: NÚMERO DE PACOTES COM TAMANHO ENTRE 65 E 127 BYTES etherstatspkts128to255octets: NÚMERO DE PACOTES COM TAMANHO ENTRE 128 E 255 BYTES etherstatspkts256to511octets: NÚMERO DE PACOTES COM TAMANHO ENTRE 256 E 511 BYTES etherstatspkts512to1023octets: NÚMERO DE PACOTES COM TAMANHO ENTRE 512 E 1023 BYTES etherstatspkts1024to1518octets: NÚMERO DE PACOTES COM TAMANHO ENTRE 1024 E 1518 BYTES O CONTROLE DA TABELA: PODE-SE PEDIR PARA MONITORAR UMA DETERMINADA INTERFACE (CRIANDO UMA LINHA PARA ELA) PODE-SE INFORMAR O NOME DO GERENTE QUE "POSSUI" ESTA LINHA DE 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 ( ) + BYTES X 8) / (INTERVALO X )] X 100% O MOTIVO É QUE CADA QUADRO É PRECEDIDO DE UM PREÂMBULO DE SINCRONIZAÇÃO DE 64 BITS E DEVE HAVER PELO MENOS 96 BITS ENTRE QUADROS (INTERFRAME GAP) O GRUPO host CONTÉM CONTADORES PARA VÁRIOS TIPOS DE TRÁFEGO PARA/DE OS HOSTS DO SEGMENTO O PROBE APRENDE QUEM SÃO OS HOSTS DO SEGMENTO ESCUTANDO O MEIO E OBSERVANDO OS ENDEREÇOS MAC ORIGEM E DESTINO PARA CADA HOST, O PROBE MANTÉM: PACOTES ENTRANDO E SAINDO BYTES ENTRANDO E SAINDO PACOTES EM ERRO GERADOS PELO HOST PACOTES DE BROADCAST GERADOS PELO HOST PACOTES DE MULTICAST GERADOS PELO HOST O GRUPO hosttopn CONTÉM ESTATÍSTICAS DE HOSTS ORDENADAS POR ALGUM PARÂMETRO UMA DAS 7 VARIÁVEIS DO GRUPO host PODE SER USADA PARA ORDENAR A TABELA O TAMANHO DA TABELA (O NÚMERO DE HOSTS) E O INTERVALO DE AMOSTRAGEM PODEM SER CONFIGURADOS A TABELA ORDENADA CONTÉM: O ENDEREÇO MAC DO HOST EM QUESTÃO (hosttopnaddress) O VALOR DO ÚLTIMO DELTA (TAMANHO DA MUDANÇA NA ÚLTIMA AMOSTRA) DA VARIÁVEL SELECIONADA (hosttopnrate) A TABELA ESTÁ ORDENADA POR VALOR DESTA VARIÁVEL O GRUPO matrix CONTÉM INFORMAÇÃO DE UTILIZAÇÃO E DE ERRO EM FORMA DE MATRIZ PARA CADA PAR DE ENDEREÇOS MAC PARA CADA PAR, A TABELA DE DADOS MANTÉM: UM CONTADOR DE PACOTES UM CONTADOR DE BYTES UM CONTADOR DE ERROS NA REALIDADE, HÁ DUAS TABELAS ORIGEM-DESTINO (matrixsdtable) PARA SABER O TRÁFEGO DE UM HOSTS PARA TODOS OS DEMAIS DESTINO-ORIGEM (matrixdstable) PARA SABER O TRÁFEGO DE TODOS OS HOSTS PARA UM DETERMINADO HOST O GRUPO alarm PERMITE ESTABELECER UM INTERVALO DE AMOSTRAGEM E LIMIARES ASSOCIADOS A QUALQUER COUNTER OU INTEGER MANTIDOS PELO PROBE O QUE DEVE SER CONFIGURADO NA TABELA DE CONTROLE: UM INTERVALO DE AMOSTRAGEM UMA VARIÁVEL SER MONITORADA DOIS LIMIARES (PARA CRIAR HISTERESE) O TIPO DE LIMIAR (ABSOLUTO OU DELTA) QUANDO GERAR UM EVENTO (CHAMADO "ALARME" PELO RMON) AO CRUZAR UM DOS LIMIARES, OU O OUTRO, OU AMBOS UM INDICE DENTRO DA TABELA DE EVENTOS (A SER DISCUTIDA ADIANTE) DIZENDO QUE AÇÃO TOMAR PODE SER LOGAR O EVENTO E/OU GERAR UM TRAP O GRUPO event DESCREVE TODOS OS EVENTOS QUE O PROBE PODE GERAR UM EVENTO PODE SER GERADO COMO SEGUE: PELO CRUZAMENTO DE UM LIMIAR (GRUPO alarm) COMO RESULTADO DE UM FILTRO (VER GRUPO filter ADIANTE) A DESCRIÇÃO DE UM EVENTO INDICA UMA AÇÃO A SER FEITA PODE SER LOGAR O EVENTO NA logtable (COM TIMESTAMP E DESCRIÇÃO) PODE GERAR UM TRAP SNMP O GRUPO filter PERMITE QUE O MONITOR OBSERVE PACOTES QUE ATENDAM A CERTAS CARACTERÍSTICAS PERMITE PORTANTO QUE O PROBE SE TORNE UM "ANALISADOR REMOTO DE PROTOCOLOS" PARA TODOS OS PACOTES QUE ATENDAM (OU QUE NÃO ATENDAM) A UMA CERTA CONDIÇÃO, O PROBE PODE: ADQUIRIR ESTATÍSTICAS SOBRE OS PACOTES FILTRADOS CAPTURAR OS PACOTES FILTRADOS (VER ADIANTE) UM FILTRO PODE SER DEFINIDO PARA: EXAMINAR QUALQUER COMBINAÇÃO DE BITS EM QUALQUER LUGAR DE UM PACOTE (DATA FILTER) FILTRAR PACOTES COM DETERMINADA CONDIÇÃO DE ERRO (TAMANHO, CRC, ENQUADRAMENTO) (STATUS FILTER) VÁRIOS FILTROS SÃO COMBINADOS NUM CANAL (CHANNEL) UM PACOTE SATISFAZ O CANAL (PASSOU PELO CANAL) SE PASSAR POR QUALQUER UM DOS FILTROS ASSOCIADOS AO CANAL

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

13 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 GERENCIAMENT O NODOS USUÁRIOS E GRUPOS OBJETOS GERENCIADOS SISTEMAS UNIX SISTEMAS NT PERIFÉRICOS USUÁRIOS GRUPOS DE USUÁRIOS ATRIBUTOS DOS OBJETOS FUNÇÕES MÉTRICAS/RELAT ÓRIOS HOME DO HOST MONITORAÇÃO DE UTILIZAÇÃO DA RELEASE STATUS CPU 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 ACOMPANHAMEN TO DE PROBLEMAS ACOMPANHAMEN TO DE UTILIZAÇÃO DE RECURSOS COM CONTABILIDADE/F ATURAMENTO AUDITORIA DE SEGURANÇA ESCALONAMENTO DE TAREFAS E BALANCEAMENTO DE CARGA LOG DE PROBLEMAS USUÁRIO NOME DE LOGIN SENHA LOGIN HABILITADO ADICIONAR E REMOVER USUÁRIOS E GRUPOS MUDANÇA DE ESPAÇO CONSUMIDO LOGINS FEITOS KERNEL DISCOS DRIVERS DISPOSITIVOS PROCESSOS PARTIÇÕES SISTEMAS DE ARQUIVOS CONFIGURAÇÃO DE DISCOS DIRETÓRIOS EXPORTADOS DIRETÓRIOS MONTADOS PARTIÇÃO DE SWAP 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 VERSÃO E RELEASE DRIVERS PARÂMETROS DO KERNEL (TAMANHO DE TABELAS,...) SUBSISTEMAS PARÂMETROS DE DISPOSITIVOS TAMANHO DE PROCESSOS QUANTIDADE DE CPU POR PROCESSO SWAP CAPACIDADE ESPAÇO USADO/LIVRE TIPO (ARQUIVO, PARTIÇÃO) DISPOSITIVO SISTEMA DE ARQUIVOS DISPOSITIVO PARTIÇÃO PONTOS DE MONTAGEM (LOCAL E REMOTO) PERMISSÕES DE EXPORTAÇÃO CAPACIDADE ESPAÇO USADO/LIVRE ESPAÇO MÍNIMO LIVRE NOMES DE ARQUIVOS LONGOS/CURTOS PRIORIDADE NA VERIFICAÇÃO DO SISTEMA DE ARQUIVOS RECONFIGURAÇÃ O DO KERNEL IMPLANTAÇÃO DE UM NOVO KERNEL MUDANÇA DE PRIORIDADE DE PROCESSOS MATAR PROCESSOS MONITORAÇÃO DE UTILIZAÇÃO DE RECURSOS (ESPAÇO LIVRE) BACKUPS GERÊNCIA DE ESPAÇO LIMIARES NA UTILIZAÇÃO DO ESPAÇO EM SWAP EXEMPLO: 75% DURANTE 5 MINUTOS COM REARM DE 65% MONITORAÇÃO DE STATUS MONITORAÇÃO DE DESEMPENHO LIMIARES NA UTILIZAÇÃO DOS DISCOS EXEMPLO: 90% DURANTE 10 MINUTOS COM REARM DE 80% DIAGNÓSTICO DE PROBLEMAS ACOMPANHAMEN TO DE PROBLEMAS ACOMPANHAMEN TO DE UTILIZAÇÃO DE RECURSOS COM CONTABILIDADE/F ATURAMENTO PROCESSOS ATIVOS UTILIZAÇÃO DE MEMÓRIA FÍSICA E VIRTUAL HIT RATE DA CACHE UTILIZAÇÃO DE CADA UNIDADE FÍSICA UTILIZAÇÃO DE CADA UNIDADE LÓGICA UTILIZAÇÃO DE CADA CONTROLADORA TAXA DE I/O PARA CADA UNIDADE FÍSICA/LÓGICA/CO NTROLADORA I/O DE DISCO DEVIDO À GERÊNCIA DE MEMÓRIA SWAP-IN E SWAP- OUT SOFTWARE INSTALADO SPOOLING INTERFACES DE REDE PRODUTO INSTALADO NOME OPÇÕES DE INSTALAÇÃO OPÇÕES DE REMOÇÃO DIRETÓRIO DE INSTALAÇÃO SUBPRODUTOS INSTALADOS PROTOCOLO DE IMPRESSORAS SPOOL FÍSICAS SPOOLER LOCAL IMPRESSORAS SPOOLER REMOTO LÓGICAS PLACAS DE REDE (DESTINOS) ARQUIVOS DE ACESSO PARÂMETROS DE CONFIGURAÇÃO TIPO VELOCIDADE ENDEREÇO IP ENDEREÇO MAC GERENCIAMENTO INFORMAÇÃO DE DE LICENÇAS CADASTRO INSTALAÇÃO DE NOVO SOFTWARE DESINSTALAÇÃO DE SOFTWARE GERÊNCIA DE RELATÓRIOS DE IMPRESSORAS PROBLEMAS ACOMPANHAMEN TO DE STATUS DISTRIBUIÇÃO DE RELATÓRIOS ACOMPANHAMEN TAXA DE I/O EM TO DE TRÁFEGO PACOTES E ACOMPANHAMEN BYTES/SEG TO 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 CERTOS PRODUTOS (CHAMADOS WATCHDOGS) PROCURAM PADRÕES EM ARQUIVOS DE LOG E GERAM EVENTOS PARA PLATAFORMAS DE GERÊNCIA O MUNDO SNMP E A GERÊNCIA DE HOSPEDEIROS E SISTEMAS A GERÊNCIA DE SISTEMAS É NORMALMENTE FEITA SEM USAR SNMP SNMP CHEGOU TARDE A ESTA ÁREA O MUNDO SNMP DEFINIU A HOST RESOURCE MIB (RFC 1514) PARA ESTE PROPÓSITO DESCREVEMOS ESTA MIB RAPIDAMENTE AGORA SYSTEM GROUP DATA DO SISTEMA DISPOSITIVO E PARÂMETROS DE BOOT NÚMERO DE USUÁRIOS LOGADOS NÚMERO DE PROCESSOS EXECUTANDO NÚMERO MÁXIMO DE PROCESSOS STORAGE GROUP QUANTIDADE DE MEMÓRIA PRINCIPAL TABELA DE DISPOSITIVOS DE ARMAZENAMENTO TIPOS DE DISPOSIVITIVOS (FIXED DISK, REMOVABLE DISK, CD, FLOPPY, RAM DISK,...) DESCRIÇÃO UNIDADES DE ALOCAÇÃO TAMANHO UNIDADES DE ALOCAÇÃO USADAS FALHAS DE ALOCAÇÃO DEVICE GROUP TABELA DE DISPOSITIVOS TIPO (IMPRESSORA, PROCESSADOR,...) DESCRIÇÃO STATUS (RUNNING, WARNING, TESTING, DOWN, UNKNOWN) NÚMERO DE ERROS TABELA DE PROCESSADORES UTILIZAÇÃO (%) DURANTE O ÚLTIMO MINUTO TABELA DE PLACAS DE REDE TABELA DE IMPRESSORAS STATUS (IDLE, PRINTING, WARMUP,...) ESTADO DE ERRO DETECTADO: UM BIT CADA PARA: LOW PAPER NO PAPER LOW TONER NO TONER DOOR OPEN JAMMED OFFLINE SERVICE REQUESTED TABELA DE DISCOS E DE PARTIÇÕES TABELA DE SISTEMAS DE ARQUIVOS (LOCAIS OU REMOTOS) TIPO PONTO DE MONTAGEM (LOCAL E REMOTO) TIPO PERMISSÕES DE ACESSO SE É BOOTÁVEL OU NÃO DATAS DE BACKUP PARCIAL E COMPLETO RUNNING SOFTWARE GROUP INCLUI UMA DESCRIÇÃO DO SOFTWARE CARREGADO EM MEMÓRIA (FÍSICA OU VIRTUAL) E PRONTO PARA RODAR INCLUI SISTEMA OPERACIONAL, DRIVERS, APLICAÇÕES VARIÁVEIS DA TABELA NOME DO SOFTWARE PATH DO ARQUIVO EXECUTÁVEL PARÂMETROS DE EXECUÇÃO TIPO (OPERATING SYSTEM, DRIVER, APPLICATION, UNKNOWN) STATUS RUNNING RUNNABLE NOT RUNNABLE (SLEEPING) INVALID (NÃO CARREGADO) RUNNING SOFTWARE PERFORMANCE GROUP PARA CADA PROCESSO: O NÚMERO DE CENTI-SEGUNDOS DE CPU OBTIDOS PELO PROCESSO A QUANTIDADE DE MEMÓRIA REAL ALOCADA AO PROCESSO INSTALLED SOFTWARE GROUP UMA TABELA TEM UMA ENTRADA PARA CADA SOFTWARE INSTALADO TABELA INCLUI NOME DO SOFWTARE TIPO (OPERATING SYSTEM, DRIVER, APPLICATION) DATA DE INSTALAÇÃO GERÊNCIA DE APLICAÇÕES O PROPÓSITO DAS TECNOLOGIAS DE INFORMÁTICA É DE EXECUTAR APLICAÇÕES AS APLICAÇÕES PRECISAM DE RECURSOS PARA FUNCIONAREM ARQUIVOS EXECUTÁVEIS ARQUIVOS COMUNICAÇÃO ENTRE PROCESOS CONEXÕES DE REDE ETC. É IMPORTANTE PODER CONFIGURAR APLICAÇÕES DETECTAR FALHAS NAS APLICAÇÕES MONITORAR O DESEMPENHO DE APLICAÇÕES CONTROLAR A APLICAÇÃO AO LONGO DE SUA VIDA A GERÊNCIA DE APLICAÇÕES É GERALMENTE FEITA COM SOFTWARE ESPECIALIZADO QUE FREQUENTEMENTE FAZ PARTE DO SOFTWARE DA APLICAÇÃO HÁ ESFORÇOS DE ELABORAÇÃO DE MIBs PARA PODER USAR SNMP PARA MONITORAR E CONTROLAR APLICAÇÕES REQUISITOS PARA A GERÊNCIA DE APLICAÇÕES GERÊNCIA DE DESEMPENHO MONITORAÇÃO DA QUALIDADE DE SERVIÇO OBTIDO MONITORAÇÃO DE TEMPO DE RESPOSTA MONITORAÇÃO DE VAZÃO DE INFORMAÇÃO NAS CONEXÕES

14 MONITORAÇÃO DA TAXA DE ERROS SOFRIDA MONITORAÇÃO DE RECURSOS UTILIZADOS CPU MEMÓRIA REAL MEMÓRIA VIRTUAL PLANEJAMENTO DE CAPACIDADE QUE RECURSOS A APLICAÇÃO NECESSITARÁ NO FUTURO OBTENÇÃO DE BASELINES DE DESEMPENHO GERÊNCIA DE FALTAS MONITORAÇÃO DE DISPONIBILIDADE MONITORAÇÃO DO STATUS (RODANDO, ESPERANDO,...) GERAÇÃO DE EVENTOS NA DETECÇÃO DE PROBLEMAS GERÊNCIA DE CONTABILIDADE DEFINIÇÃO DA UNIDADE DE TRABALHO (TRANSAÇÃO, TEMPO,...) MONITORAÇÃO DA UTILIZAÇÃO DE RECURSOS GERÊNCIA DE CONFIGURAÇÃO DISTRIBUIÇÃO INSTALAÇÃO DESINSTALAÇÃO BASELINES DE CONFIGURAÇÃO CONTROLE OPERACIONAL PARAR, SUSPENDER, RESTAURAR, RECONFIGURAR CADASTRO DE SOFTWARE INSTALADO CADASTRO DE SOFTWARE EXECUTANDO (PROCESSOS) FORMAS DE GERENCIAR A APLICAÇÃO SEM INSTRUMENTAÇÃO USANDO COMANDOS DO SISTEMA OPERACIONAL PARA VER RECURSOS UTILIZADOS, STATUS, DE PROCESSOS, ETC. USANDO COMANDOS DO SISTEMA OPERACIONAL OU APLICAÇÕES WATCHDOG PARA EXAMINAR ARQUIVOS (DE LOG, P. EX.) MANTIDOS PELA APLICAÇÃO COM INSTRUMENTAÇÃO DA APLICAÇÃO PERMITE UMA GERÊNCIA MAIS EFICAZ MIBs PARA A GERÊNCIA DE APLICAÇÕES ARQUITETURA GERAL AS MIBs PRINCIPAIS ENVOLVIDAS: HOST RESOURCE MIB (RFC 1514) PARA GERENCIAR O HOSPEDEIRO COMO UM TODO SYSTEM-LEVEL APPLICATION MIB (RFC 2287) PARA GERENCIAR A APLICAÇÃO SEM INSTRUMENTAÇÃO APENAS ATRAVÉS DE INFORMAÇÃO DO SISTEMA OPERACIONAL (SOBRE A APLICAÇÃO) APPLICATION MIB (AINDA NÃO SAIU COMO RFC [AGOSTO 1999]) GERÊNCIA GERAL DE APLICAÇÕES, SUPONDO INSTRUMENTAÇÃO DA APLICAÇÃO NETWORK SERVICES MONITORING MIB (RFC 2248) GERÊNCIA GERAL DE APLICAÇÕES QUE USAM A REDE ISTO É, CRIAM "ASSOCIAÇÕES" OU CONEXÕES MIB GENÉRICA DO TIPO DE APLICAÇÃO PARA GERENCIAR UMA APLICAÇÃO ESPECÍFICA (DIGAMOS UM SERVIDOR WWW), PRECISAMOS DE INFORMAÇÃO MAIS ESPECÍFICA DO QUE TEM NAS OUTRAS MIBs EXISTEM ESFORÇOS PARA CRIAR MIBs PARA VÁRIAS APLICAÇÕES ESPECÍFICAS DNS SERVER MIB (RFC 1611) DNS RESOLVERr MIB (RFC 1612) RELATIONAL DATABASE MANAGEMENT SYSTEM MIB (RFC 1697) MAIL MONITORING MIB (RFC 2249) WWW SERVICES MIB (RFC 2594) DIRECTORY SERVER MONITORING MIB (RFC 2605) MIB ESPECÍFICA DE PRODUTO MIBs PROPRIETÁRIAS EXISTEM PARA APLICAÇÕES COMO PARA DISPOSITIVOS DE REDE AINDA HÁ RELATIVAMENTE POUCO SUPORTE PARA ESSAS MIBs NÃO ESTÁ CLARO QUE A GERÊNCIA DE APLICAÇÕES SERÁ FEITA COM SNMP PARA ENCERRAR A DISCUSSÃO, APRESENTAMOS BREVEMENTE 2 MIBs SYSAPPL-MIB (RFC 2287) WWW-MIB (RFC 2594) SYSAPPL-MIB SUPORTA GERÊNCIA DE: CONFIGURAÇÃO FALTAS DESEMPENHO NÃO É ESPECÍFICA DE UMA APLICAÇÃO PARTICULAR UMA APLICAÇÃO É UMA COLEÇÃO DE ARQUIVOS EXECUTÁVEIS E OUTROS ARQUIVOS INSTALADOS E EXECUTANDO NUM COMPUTADOR HOSPEDEIRO A MIB NÃO SUPÕE INSTRUMENTAÇÃO DA APLICAÇÃO A INFORMAÇÃO DEVE SER DESCOBERTA ATRAVÉS DO SISTEMA OPERACIONAL NÃO REQUER MODIFICAÇÃO ÀS APLICAÇÕES QUALQUER APLICAÇÃO PODE SER (PARCIALMENTE) GERENCIADA ESTA MIB NÃO É SUFICIENTE SOZINHA PARA A GERÊNCIA DA APLICAÇÃO AS OUTRAS MIBs MAIS ESPECÍFICAS PODERÃO REFERENCIAR AS MIBs MAIS GENÉRICAS A MIB MODELA: A APLICAÇÃO COMO UM TODO OS ELEMENTOS ESTÁTICOS (ARQUIVOS) INDIVIDUAIS QUE FORMAM A APLICAÇÃO OS ELEMENTOS DINÂMICOS (PROCESSOS) INDIVIDUAIS QUE FORMAM A APLICAÇÃO OS GRUPOS DA MIB SÃO: SYSTEM APPLICATION INSTALLED GROUP SYSTEM APPLICATION RUN GROUP SYSTEM APPLICATION MAP GROUP SYSTEM APPLICATION INSTALLED GROUP MODELAGEM ESTÁTICA PERMITE SABER: QUE PACOTES DE APLICAÇÃO ESTÃO INSTALADOS (sysapplinstallpkgtable) FABRICANTE NOME DO PRODUTO VERSÃO NÚMERO DE SÉRIE DATA DE INSTALAÇÃO LOCAL (DIRETÓRIO) DE INSTALAÇÃO QUE ELEMENTOS (ARQUIVOS) COMPÕEM CADA PACOTE (sysapplinstallelmttable) NOME DO ELEMENTO TIPO NON-EXECUTABLE OPERATING SYSTEM DEVICE DRIVER APPLICATION DATA DE INSTALAÇÃO DIRETÓRIO DE INSTALAÇÃO TAMANHO DO ARQUIVO DEPOIS DA INSTALAÇÃO TAMANHO ATUAL DO ARQUIVO PAPEL DO ELEMENTO (UM BIT PARA CADA PAPEL ABAIXO) EXECUTÁVEL EXCLUSIVE (UMA CÓPIA) PRIMARY (SÓ UM ELEMENTO PODE SER O PRINCIPAL) REQUIRED (DEVE ESTAR RODANDO PARA QUE A APLICAÇÃO ESTEJA OK) DEPENDENT (SÓ PODE ESTAR RODANDO SE OS PRIMARY ESTIVEREM) SYSTEM APPLICATION RUN GROUP MODELA A APLICAÇÃO QUANDO ESTÁ EXECUTANDO OU DEPOIS QUE JÁ EXECUTOU MODELAGEM DE COMPORTAMENTO DINÂMICO AS TABELAS: APLICAÇÕES QUE ESTÃO RODANDO (sysapplruntable) DATA E HORA QUE INICIOU STATUS (RUNNING, RUNNABLE, WAITING, EXITING, OTHER) APLICAÇÕES QUE RODARAM NO PASSADO (sysapplpastruntable) DATA E HORA QUE INICIOU E TERMINOU STATUS DE TÉRMIMO (COMPLETE, FAILED, OTHER) ELEMENTOS (PROCESSOS) DE APLICAÇÕES QUE ESTÃO RODANDO (sysapplelmtruntable) CONTÉM UMA LINHA DA TABELA PARA CADA PROCESSO EM EXISTÊNCIA NO SISTEMA OPERACIONAL ÍNDICES APONTANDO PARA AS OUTRAS TABELAS (INSTALLED GROUP) HORA QUE PROCESSO INICIOU STATUS NOME DO ARQUIVO EXECUTÁVEL PARÂMETROS DE EXECUÇÃO TEMPO DE CPU MEMÓRIA REAL ALOCADA NÚMERO DE ARQUIVOS ABERTOS NOME DO DONO DO PROCESSO ELEMENTOS (PROCESSOS) DE APLICAÇÕES QUE RODARAM NO PASSADO (sysapplelmtpastruntable) AS LINHAS DA TABELA ANTERIOR QUE CORRESPONDEREM A APLICAÇÕES IDENTIFICADAS SÃO MOVIDAS PARA CÁ QUANDO O PROCESSO TERMINA SYSTEM APPLICATION MAP GROUP MAPEIA "PROCESS IDS" PARA REFERÊNCIAS ÀS TABELAS DA APLICAÇÃO IDENTIFICA A APLICAÇÃO (PACOTE) E O ELEMENTO DO PACOTE WWW-MIB MIB PARA SERVIDORES WWW OS GRUPOS SÃO: INFORMAÇÃO DE SERVIÇOS ESTATÍSTICAS DE PROTOCOLOS ESTATÍSTICAS DE DOCUMENTOS INFORMAÇÃO DE SERVIÇOS TABELA ÚNICA DESCREVENDO TODOS OS SERVIÇOS WWW GERENCIADOS PELO AGENTE DESCRIÇÃO PESSOA DE CONTATO PROTOCOLO (OID DA IANA PARA PROTOCOLOS BEM CONHECIDOS) NOME DNS (FULLY QUALIFIED DOMAIN NAME DO SERVIÇO) TIPO (SERVER, CLIENTE, PROXY, CACHING PROXY, OTHER) STATUS DOWN RUNNING HALTED CONGESTED RESTARTING DATA/HORA DE INÍCIO DATA/HORA QUE SERVIÇO ENTROU NO ESTADO (STATUS) ATUAL ESTATÍSTICAS DE PROTOCOLOS ESTATÍSTICAS SOBRE O TRÁFEGO RECEBIDO OU ENVIADO PO UM SERVIÇO WWW OS CONTADORES ESTÃO ORGANIZADOS EM 5 TABELAS wwwsummarytable: SUMÁRIO DO TRÁFEGO E OPERAÇÃO DE PROTOCOLO POR SERVIÇO WWW (PARA TODOS OS TIPOS DE PEDIDOS REQUESTS/RESPONSES IN/OUT BYTES IN/OUT wwwrequestintable: CADA TIPO DE PEDIDO ENTRANDO É CONTADO INDIVIDUALMENTE OS TIPOS DE PEDIDOS DEPENDEM DO PROTOCOLO wwwrequestouttable: CADA TIPO DE PEDIDO SAINDO É CONTADO INDIVIDUALMENTE wwwresponseintable: CADA TIPO DE RESPOSTA ENTRANDO É CONTADO INDIVIDUALMENTE wwwresponseouttable: CADA TIPO DE RESPOSTA SAINDO É CONTADO INDIVIDUALMENTE ESTATÍSTICAS DE DOCUMENTOS CONTÉM INFORMAÇÃO SOBRE OS DOCUMENTOS QUE FORAM ACESSADOS NO PASSADO QUATRO TIPOS DE ESTATÍSTICAS DETALHES DAS ÚLTIMAS N TENTATIVAS DE MANIPULAR DOCUMENTOS NOME DO DOCUMENTO DATA/HORA TIPO DE PEDIDO TIPO DE RESPOSTA NÚMERO DE BYTES OS N DOCUMENTOS MAIS MANIPULADOS (ORDENADOS)

15 NOME DO DOCUMENTO NÚMERO DE ACESSOS NÚMERO DE BYTES TRANSFERIDOS OS N DOCUMENTOS QUE MAIS GERARAM TRÁFEGO (ORDENADOS) ESTATÍSTICAS SUMARIZADAS