Gerencia De Redes De Computadores
Ensaios: Gerencia De Redes De Computadores. Pesquise 861.000+ trabalhos acadêmicosPor: • 21/5/2014 • 7.252 Palavras (30 Páginas) • 454 Visualizações
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-2
2.5 STRUCTURE OF MANAGEMENT INFORMATION (SMIv1)
2.5.1 OBJECT IDENTIFIERS
2.5.2 MÓDULOS MIB
2.5.3 A ESPECIFICAÇÃO DE UM MÓDULO
2.5.4 DEFINIÇÃO DE OBJETOS GERENCIADOS
2.5.5 REGRAS PARA A DEFINIÇÃO DE OBJETOS E MIBs
2.5.6 DIAGRAMAS CASE
2.5.7 TRAPS
2.5.8 DICAS PARA CRIAR MIBs PROPRIETÁRIAS
2.6 SMI VERSÃO 2
3. O NÍVEL DE 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 EMAIL, PAGER, ...
• AÇÕES NECESSÁRIAS AO RESTABELECIMENTO DOS ELEMENTOS COM PROBLEMAS
• AÇÕES PODE SER SUGERIDAS AUTOMATICAMENTE
• TESTES
• PARA PERMITIR A VERIFICAÇÃO DO FUNCIONAMENTO DE RECURSOS DA REDE EM CONDIÇÕES NORMAIS OU ARTIFICIAIS
• EXEMPLOS: TESTES DE ECO, DE CONECTIVIDADE
• PROVÊ REGISTRO DE OCORRÊNCIAS E EMISSÃO DE RELATÓRIOS PARA ANÁLISE
GERÊNCIA DE DESEMPENHO
• RESPONSÁVEL PELA MONITORAÇÃO DE DESEMPENHO, A ANÁLISE DESSE DESEMPENHO E PLANEJAMENTO DE CAPACIDADE
• SELEÇÃO DE INDICADORES DE DESEMPENHO
• O DESEMPENHO CORRENTE DA REDE DEVE SE BASEAR EM INDICADORES TAIS COMO ATRASO, VAZÃO, DISPONIBILIDADE, UTILIZAÇÃO, TAXA DE ERROS, ETC.
• MONITORAÇÃO DE DESEMPENHO
• MONITORA OS INDICADORES DE DESEMPENHO
• BASELINE (COMPORTAMENTO NORMAL) PODE SER ESTABELECIDO
• LIMIARES PODEM SER DEFINIDOS PARA GERAR EVENTOS OU ALARMES
• MANTÉM REGISTROS HISTÓRICOS PARA PERMITIR A ANÁLISE E PLANEJAMENTO FUTUROS
• ANÁLISE DE DESEMPENHO E PLANEJAMENTO DE CAPACIDADE
• ALTERAÇÃO DO MODO DE OPERAÇÃO
• EXEMPLO: PASSAR DE UM SEGMENTO COMPARTILHADO PARA UMA REDE COMUTADA
GERÊNCIA DE SEGURANÇA
• RESPONSÁVEL PELA PROTEÇÃO DOS ELEMENTOS DA REDE, MONITORANDO E DETECTANDO VIOLAÇÕES DA POLÍTICA DE SEGURANÇA ESTABELECIDA
• PREOCUPA-SE COM A PROTEÇÃO DOS ELEMENTOS DA REDE
• DEVE APOIAR A POLÍTICA DE SEGURANÇA DA EMPRESA
• CRIAÇÃO E MANUTENÇÃO DE SERVIÇOS DE SEGURANÇA
• PROVÊ MECANISMOS PARA CRIAR, REMOVER E CONTROLAR OS SERVIÇOS DE SEGURANÇA
• MONITORAÇÃO DOS SERVIÇOS DE SEGURANÇA
• PODE DISPARAR ALARMES AO DETECTAR VIOLAÇÕES DE SEGURANÇA
• MANUTENÇÃO DE LOGS DE SEGURANÇA
• PARA DETECTAR VIOLAÇÕES NÃO ÓBVIAS MANUALMENTE (OU COM PROGRAMAS BATCH AUTOMÁTICOS)
GERÊNCIA DE CONTABILIDADE
• RESPONSÁVEL PELA CONTABILIZAÇÃO E VERIFICAÇÃO DE LIMITES DA UTILIZAÇÃO DE RECURSOS DA REDE, COM A DIVISÃO DE CONTAS FEITA POR USUÁRIOS OU GRUPOS DE USUÁRIOS.
• COLETA DE INFORMAÇÕES DE UTILIZAÇÃO
• MONITORA QUAIS RECURSOS E QUANTO DESSES RECURSOS ESTÃO SENDO UTILIZADOS POR QUE ENTIDADE
• ESTABELECIMENTO DE COTAS DE UTILIZAÇÃO
• LIMITES DE USO DE RECURSOS POR USUÁRIO OU GRUPO DE USUÁRIOS
• ESTABELECIMENTO DE ESCALAS DE TARIFAÇÃO
• PARA DIVIDIR O CUSTO ENTRE USUÁRIOS OU DEPARTAMENTOS DE UMA EMPRESA
• AS INFORMAÇÕES PODEM SER UTILIZADAS APENAS PARA ESTATÍSTICAS
• APLICAÇÃO DAS TARIFAS E FATURAMENTO
ARQUITETURA GERAL DE UMA SOLUÇÃO DE GERÊNCIA
• OS 4 COMPONENTES DA ARQUITERURA DE GERÊNCIA
• OS ELEMENTOS GERENCIADOS
• DEVEM POSSUIR UM SOFTWARE ESPECIAL PARA PERMITIR SUA GERÊNCIA
• O SOFTWARE CHAMA-SE DE AGENTE
• AS ESTAÇÕES DE GERÊNCIA
• NORMALMENTE CENTRALIZADAS PARA FACILITAR A GERÊNCIA
• FREQUENTEMENTE SÓ TEM UMA
• O SOFTWARE QUE CONVERSA DIRETAMENTE COM OS AGENTES NOS ELEMENTOS GERENCIADOS É CHAMADO DE GERENTE
• POSSUEM FUNÇÕES AUTOMÁTICAS DE GERÊNCIA (EX. POLL REGULAR DOS AGENTES)
• PODE OBTER INFORMAÇÃO DE GERÊNCIA PRESENTE NOS AGENTES
• PODEM ALTERAR ESTA INFORMAÇÃO
• POSSUEM INTERFACE COM O USUÁRIO PARA FACILITAR A GERÊNCIA
• VEREMOS DETALHES LOGO ADIANTE
• PROTOCOLO DE GERÊNCIA
• USADO ENTRE GERENTE E AGENTES PARA TROCAR INFORMAÇÃO DE GERÊNCIA
• PERMITE OPERAÇÕES DE MONITORAMENTO (READ) E OPERAÇÕES DE CONTROLE (WRITE)
• INFORMAÇÃO DE GERÊNCIA
• DEFINE OS DADOS QUE PODEM SER REFERENCIADOS EM OPERAÇÕES DO PROTOCOLO
• EXEMPLOS: TAXA DE ERRO, STATUS DE UMA LINHA DE COMUNICAÇÃO, ETC.
• A VISÃO FÍSICA DA REDE GERENCIADA
• A GERÊNCIA DE REDE NA ARQUITETURA RM-OSI DA ISO
• ESTRUTURA DE UMA ESTAÇÃO DE GERÊNCIA DE REDES
• OFERECE UMA VISÃO DA REDE NUM PONTO CENTRALIZADO
NORMALMENTE CONSTRUÍDA COM UMA PLATAFORMA E APLICAÇÕES SOBRE ESTA
PLATAFORMA DE GERÊNCIA
• É O "SISTEMA OPERACIONAL" DA GERÊNCIA
• OFERECE FUNÇÕES BÁSICAS DE GERÊNCIA (COMUNS A MUITAS APLICAÇÕES)
• OFERECE UM AMBIENTE PARA O DESENVOLVIMENTO E A INTEGRAÇÃO DE APLICAÇÕES
SOBRE AS PLATAFORMAS ESTÃO AS DIVERSAS APLICAÇÕES USADAS PELOS OPERADORES
A PLATAFORMA DEVE PROVER SERVIÇOS BÁSICOS PARA AS APLICAÇÕES QUE A USAM
• EXEMPLOS DE PLATAFORMAS
• OPENVIEW DA HP
• SUNNET MANAGER DA SUN MICROSYSTEMS
• NETVIEW DA IBM
• SPECTRUM DA CABLETRON
• CA-UNICENTER DA COMPUTER ASSOCIATES
• PRECISA DE MUITAS APLICAÇÕES PORQUE NÃO HÁ COMO TER UMA ÚNICA APLICAÇÃOZONA DE GERÊNCIA
• A DIFICULDADE DE FAZER APLICAÇÕES SIGNIFICA QUE FORNECEDORES SE ESPECIALIZAM
• EXEMPLOS DE APLICAÇÕES DE GERÊNCIA
FUNCIONALIDADE APLICAÇÃO FABRICANTE
GERÊNCIA DE DESEMPENHO NETCLARITY LANQUEST
GERÊNCIA DE FALTAS SPECTRUM'S ALARM MANAGERS CABLETRON
MANIPULAÇÃO DE ALARMES TRAP EXPLODER EMPIRE TECHNOLOGIES
GERÊNCIA DE SEGURANÇA BOKS SECURIX
GERÊNCIA DE BENS ASSETVIEW HP
CONFIGURAÇÃO NETBUILDER 3COM
CONFIGURAÇÃO CISCO WORKS CISCO
DEMONSTRAÇÕES DE SOLUÇÕES DE GERÊNCIA
• GERÊNCIA AD HOC
C:> ping rtbbdsc.campus-ii.ufpb.br
Disparando contra rtbbdsc.campus-ii.ufpb.br [150.165.13.61] com 32 bytes de dados:
Resposta de 150.165.13.61: bytes=32 tempo=553ms
Resposta de 150.165.13.61: bytes=32 tempo=458ms
Resposta de 150.165.13.61: bytes=32 tempo=512ms
Resposta de 150.165.13.61: bytes=32 tempo=393ms
Estatísticas do Ping para 150.165.13.61:
Pacotes: Enviados=4, Recebidos=4, Perdidos=0 (0%)
Tempos aproximados de ida e volta em milissegundos:
Mínimo = 393ms, Máximo=553ms, Média=479ms
traceroute www.playboy.com
Rastreando a rota para www.playboy.com [206.251.29.10]
com no máximo 30 saltos:
1 145 ms 140 ms 136 ms 200.241.195.28
2 142 ms 138 ms 136 ms cgnet2.cgnet.com.br [200.241.195.30]
3 153 ms 143 ms 147 ms cgnet-S4-4-dist01.rce.embratel.net.br [200.249.241.13]
4 220 ms 226 ms 220 ms ebt-A11-0-0-3-dist01.rjo.embratel.net.br [200.244.40.118]
5 201 ms 196 ms 190 ms ebt-F5-0-0-core01.rjo.embratel.net.br [200.255.197.33]
6 346 ms 345 ms 346 ms 204.189.136.137
7 * 387 ms 366 ms core1-fddi-0.NewYork.cw.net [204.70.2.17]
8 365 ms 328 ms 413 ms core1-hssi-3.WestOrange.cw.net [204.70.10.14]
9 403 ms 391 ms 430 ms core2.Sacramento.cw.net [204.70.4.49]
10 439 ms 523 ms 449 ms border8-fddi-0.Sacramento.cw.net [204.70.164.67]
11 610 ms 634 ms 639 ms globalcenter.Sacramento.cw.net [204.70.123.6]
12 612 ms 574 ms 593 ms pos4-3-155M.cr1.SNV.globalcenter.net [206.132.150.29]
13 * 688 ms 654 ms pos6-0-0-155M.hr2.SNV.globalcenter.net [206.251.0.109]
14 638 ms 630 ms 635 ms www.playboy.com [206.251.29.10]
Rastreamento completo.
• RESULTADO DISSO: TÉCNICA DA PORTA ABERTA
• GERENCIAMENTO REATIVO (POR INTERRUPÇÃO)
• NÃO TEM GERENCIAMENTO PRÓ-ATIVO
• NÃO TEM ESCALA
• O QUE FAZER QUANDO ALGUÉM FALA "A REDE ESTÁ LENTA!"?
• GERÊNCIA MANUAL COM INSTRUMENTAÇÃO SNMP
• SNMP É O PROTOCOLO DE GERÊNCIA MAIS USADO NO MUNDO
• USA OS COMANDOS SNMPGET E SNMPWALK DA CARNEGIE-MELLON UNIVERSITY (CMU) PARA OBTER DADOS DE GERÊNCIA
• EXEMPLO: ALGUÉM RECLAMA QUE NÃO CONSEGUE NAVEGAR NA INTERNET
• O ROTEADOR ESTÁ NO AR?
snmpget rtbbdsc.ufpb.br <senha> system.sysUpTime.0
system.sysuptime = Timeticks: (836503909) 96 days, 19:37:19
• A LINHA DE COMUNICAÇÃO PARA A INTERNET ESTÁ NO AR?
interfaces.ifTable.ifEntry.ifOperStatus.1 = up(1)
• VAMOS VER O NÚMERO DE ERROS
interfaces.ifTable.ifEntry.ifInErrors.1 = 220153
(ESPERA 5 SEGUNDOS)
interfaces.ifTable.ifEntry.ifInErrors.1 = 220364
• MUITOS ERROS!! (211 EM 5 SEGUNDOS)
• VAMOS AVISAR O RESPONSÁVEL, PASSANDO A INFORMAÇÃO CORRETA
system.sysContact.0 = "Fernando Barros"
system.sysName.0 = "fw.xpto.com.br"
system.sysLocation.0 = "Sala 202"
system.sysDescr.0 = "CISCO ROUTER ABC, MODEL XYZ, VER. 11.0"
• COMO AGUENTAR 1000 DISPOSITIVOS COM ESSA TÉCNICA???
• GERÊNCIA AUTOMÁTICA WEBMANAGER
• APLICAÇÃO DESENVOLVIDA NA UFPb POR JACQUES E PETER
• GERÊNCIA AUTOMÁTICA DO FUTURO (PRÓXIMO!)
• WBEM DA FREERANGE
O NÍVEL DE INSTRUMENTAÇÃO: MODELO DE INFORMAÇÃO
PADRÕES NO MUNDO DA GERÊNCIA
INTERNET-STANDARD NETWORK MANAGEMENT FRAMEWORK
• TAMBÉM CHAMADO "GERÊNCIA SNMP" DEVIDO AO PROTOCOLO PRINCIPAL: SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP)
• USADO EM PRATICAMENTE TODO O MUNDO DA GERÊNCIA
• MENOS COMPLEXO DO QUE OUTRAS ALTERNATIVAS E, POR ISSO MESMO, APARECEU PRIMEIRO E DE DIFUNDIU
• LIÇÃO: "ROUGH CONSENSUS AND WORKING CODE" É MELHOR DO QUE UM MONTE DE COMITÊS
• AXIOMA FUNDAMENTAL: O IMPACTO DE ADICIONAR GERÊNCIA DE REDE AOS ELEMENTOS GERENCIADOS DEVE SER MÍNIMO, REFLETINDO UM MENOR DENOMINADOR COMUM
• RESULTADO: A SOLUÇÃO BÁSICA DE GERÊNCIA (INSTRUMENTAÇÃO) E O PROTOCOLO SNMP (VERSÃO 1) SÃO MUITO SIMPLES
• RESULTADO: A COMPLEXIDADE ESTÁ NAS POUCAS NMSs (NETWORK MANAGEMENT STATIONS) E NÃO NOS MILHARES DE ELEMENTOS GERENCIADOS
• FRAMEWORK (VERSÃO 1) BASEADO EM TRÊS DOCUMENTOS
• STRUCTURE OF MANAGEMENT INFORMATION (SMI) - RFC 1155
• A LINGUAGEM USADA PARA ESPECIFICAR A INFORMAÇÃO GERENCIADA
• MANAGEMENT INFORMATION BASE (MIB) PRINCIPAL - RFC 1156
• DEFINE AS VARIÁVEIS DE GERÊNCIA QUE TODO ELEMENTO GERENCIADO DEVE TER
• OUTRAS MIBs EXISTEM PARA FINS PARTICULARES
• SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) - RFC 1157
• O PROTOCOLO USADO ENTRE GERENTE E AGENTE PARA A GERÊNCIA, PRINCIPALMENTE TROCANDO VALORES DE VARIÁVEIS DE GERÊNCIA
• MODELO BÁSICO OPERACIONAL: "TRAP-BASED POLLING"
• TRAPS SÃO EVENTOS COMUNICADOS DO AGENTE PARA O GERENTE
• POLLINGS SÃO CONSULTAS PERIÓDICAS FEITAS PELO GERENTE AOS AGENTES
DMTF
• DESKTOP MANAGEMENT TASK FORCE
• LIDERADO PELA MICROSOFT
• FEITO PARA GERENCIAR PCs NA MESA
• MODELO DE INFORMAÇÃO ORIENTADO A OBJETO
• CIM = COMMON INFORMATION MODEL
ARQUITETURA OSI DE GERENCIAMENTO
• VEIO DO MUNDO OSI DA ISO
• DEMOROU MUITO PARA SER FEITO E FOI ADOTADO MUITO POUCO
• SÓ NO MUNDO DAS TELECOMUNICAÇÕES, JUNTO COM TMN
• USA MIBs TAMBÉM
• PROTOCOLO CMIP MUITO MAIS COMPLEXO DO QUE SNMP
• CMIP = COMMON MANAGEMENT INFORMATION PROTOCOL
• DEFINE TAMBÉM DE SERVIÇO DE GERÊNCIA (CMIS)
• CMIS = COMMON MANAGEMENT INFORMATION SERVICE
• UMA TENTATIVA DE RESGATE FOI FEITA COM CMOT
• CMOT = CMIP OVER TCP/IP
• NÃO SERÁ DISCUTIDO NESTE CURSO DEVIDO A SUA POUCA UTILIZAÇÃO
TELECOMMUNICATIONS MANAGEMENT NETWORK (TMN)
• ESPECIALMENTE FEITO PARA GERENCIAR REDES DE TELECOMUNICAÇÕES (TELEFÔNICAS, BASICAMENTE)
• DESENVOLVIDO PELA CCITT (HOJE ITU-T)
• BASTANTE USADO ENRE AS OPERADORAS DE TELECOMUNICAÇÕES
• INCIPIENTE NO BRASIL
• TMN É UMA REDE PARALELA PARA GERENCIAR A REDE PRINCIPAL
• INTERCONECTA SISTEMAS DE SUPORTE À OPERAÇÃO (OPERATIONS SYSTEMS)
• FEITO PARA GERENCIAR:
• A PRÓPRIA TMN
• REDES DE TELEFONIA, INCLUINDO TELEFONIA MÓVEL
• TERMINAIS DE TRANSMISSÃO (MULTIPLEXADORES, EQUIPAMENTOS SDH , ...)
• SISTEMAS DE TRANSMISSÃO ANALÓGICOS E DIGITAIS
• PABX
• INFRA-ESTRUTURA (MÓDULOS DE TESTES, SISTEMAS DE ENERGIA, ...)
• ETC.
• USA PROTOCOLOS OSI
ARQUITETURA DA SOLUÇÃO SNMP
• USA O MODELO FETCH-STORE DE VARIÁVEIS DE GERÊNCIA MANTIDAS NOS AGENTES
• MUITO SIMPLES MAS PODEROSO
• AÇÕES ESPECIAIS SÃO EFEITOS COLATERIAIS DE OPERAÇÕES STORE
• EXEMPLOS: LINK UP, LINK DOWN
• TRÊS VERSÕES: SNMPv1, SNMPv2, SNMPv3
• PRIMITIVAS BÁSICAS (SNMPv1)
• GET - OBTER O VALOR DE UMA VARIÁVEL
• GET-NEXT - PERMITE CAMINHAR NAS VARIÁVEIS
• PARA CAMINHAR EM TABELAS DE TAMANHO DESCONHECIDO; OU
• QUANDO NÃO SE SABE QUE VARIÁVEIS SÃO SUPORTADAS PELO AGENTE
• SET - ALTERAR O VALOR DE UMA VARIÁVEL
• TRAP - INFORMAR EVENTOS EXTRAORDINÁRIOS
• DO AGENTE PARA O GERENTE
• MODELO BÁSICO: TRAP-DIRECTED POLLING
• ONDE SNMP SE INSERE NA PILHA TCP/IP:
• O MODELO CLIENTE-SERVIDOR DO SNMP:
A SEGURANÇA SNMP
• BASEADA EM UMA SENHA APENAS (COMMUNITY NAME)
• UM DOS MOTIVOS DA GERÊNCIA INCOMPLETA DE REDES COM SNMP
• SET É POUCO USADO PARA CONTROLAR DISPOSITIVOS
• MUITOS FABRICANTES NEM IMPLEMENTAM SET!
• UM AGENTE PODE IMPLEMENTAR VÁRIAS COMUNIDADES
• CADA COMUNIDADE DÁ ACESSO A UMA "MIB VIEW" DEFINIDA LOCALMENTE
• CADA COMUNIDADE PODE TER CERTOS DIREITOS DE ACESSO (DEFINIDOS LOCALMENTE)
• DUAS COMUNIDADES COMUMENTE IMPLEMENTADAS:
• READ COMMUNITY
• WRITE COMMUNITY
OBJETOS, INSTÂNCIAS E MIBs
MODELO ESTRUTURADO EM ÁRVORE
• PARA IDENTIFICAR AS VARIÁVEIS DE GERÊNCIA
• ÁRVORE USADA DEVIDO AO NÚMERO DE VARIÁVEIS
• CADA ÓRGÃO DE PADRONIZAÇÃO INTERNACIONAL TEM SEU ESPAÇO DENTRO DA ESTRUTURA
• CADA NODO DA ÁRVORE POSSUI UM RÓTULO
• RÓTULO = DESCRIÇÃO TEXTUAL + NÚMERO
• O TOPO DA ÁRVORE É MOSTRADO ABAIXO (SNMPv1)
OBJETOS, INSTÂNCIAS E MIBs - 2
OBJETOS E INSTÂNCIAS
• CADA NODO DA ÁRVORE AGRUPA UM CONJUNTO DE OBJETOS RELACIONADOS
• "OBJETO" NÃO É USADO NO SENTIDO DA ORIANTEÇÃO A OBJETO
• OS OBJETOS DESCREVEM A INFORMAÇÃO MANTIDA NOS AGENTES
• UMA INSTÂNCIA DE UM OBJETO (UMA VARIÁVEL) É O QUE REALMENTE É MANIPULADO PELO PROTOCOLO
• OBJETOS PODEM SER DE DOIS TIPOS BÁSICOS:
• SIMPLES (ESCALARES)
• UMA LINHA DE UMA TABELA
• SE HOUVER VÁRIAS INSTÂNCIAS, A TABELA TERÁ VÁRIAS LINHAS
• SÓ HÁ TABELAS BI-DIMENSIONAIS CONTENDO OBJETOS SIMPLES
• IDENTIFICAÇÃO DE UM OBJETO
• iso.org.dod.internet.mgmt.mib-2.system.sysDescr
• 1.3.6.1.2.1.1.1
• IDENTIFICAÇÃO DE UMA VARIÁVEL SIMPLES
• iso.org.dod.internet.mgmt.mib-2.system.sysDescr.0
• 1.3.6.1.2.1.1.1.0
• LINHAS DE TABELAS SÃO IDENTIFICADAS UNICAMENTE ATRAVÉS DE UMA (OU MAIS) COLUNAS COM CONTEÚDO ÚNICO
• A "CHAVE" DA TABELA
OBJETOS, INSTÂNCIAS E MIBs - 3
OBJETOS E INSTÂNCIAS
• EXEMPLO:
• A TABELA DE INTERFACES DE REDE SE CHAMA iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable
• A LINHA SE CHAMA ifEntry E CONTÉM VÁRIOS OBJETOS, ENTRE OS QUAIS ifIndex E ifDescr
• CADA INTERFACE TEM UM ifIndex ÚNICO (1, 2, ...)
• A DESCRIÇÃO DA PRIMEIRA INTERFACE SERIA: iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifDescr.1
• EXEMPLO:
• UMA CONEXÃO TCP É IDENTIFICADA POR 4 COLUNAS DA TABELA tcpConnTable:
• tcpConnLocalAddress (DIGAMOS 89.1.1.42)
• tcpConnLocalPort (DIGAMOS 21)
• tcpConnRemAddress (DIGAMOS 10.0.0.51)
• tcpConnRemPort (DIGAMOS 2059)
• O VALOR DA COLUNA DE ESTADO DESSA CONEXÃO TERIA IDENTIFICADOR:
• 1.3.6.1.2.1.6.13.1.1.89.1.1.42.21.10.0.0.51.2059
• ESSES IDENDIFICADORES (OBJECT IDENTIFIERS - OIDs) SÃO USADOS NOS COMANDOS GET, GET-NEXT, SET, TRAP
OBJETOS, INSTÂNCIAS E MIBs - 4
MIBs
• UM "MÓDULO MIB" É UM AGRUPAMENTO DE OBJETOS RELACIONADOS
• HÁ UMA MIB PADRÃO (mib-2) QUE TODOS OS AGENTES DEVEM SUPORTAR
• MIBs SÃO CONHECIDAS PELOS AGENTES E PELO GERENTE
• O GERENTE NÃO SABE EXATAMENTE QUE MIBs SÃO SUPORTADAS POR UM DETERMINADO AGENTE
• AGENTES NORMALMENTE SUPORTAM MAIS MIBs, DEPENDENDO DO TIPO DE EQUIPAMENTO OU SOFTWARE QUE ELES SÃO:
• MIB DE REPETIDORES
• MIB DE ROTEADORES
• MIB ETHERNET
• MIB ATM
• MIB DE MONITORAÇÃO REMOTA (RMON)
• MIB DE DNS
• MIB DE SERVIDOR WEB
• E MAIS VÁRIAS DEZENAS DE MIBs
• FREQUENTEMENTE, AGENTES SUPORTAM MIBs PROPRIETÁRIAS
• EMBAIXO DE iso.org.dod.internet.private.enterprises
A MIB-2
• A mib-2 TEM MUDADO DE SNMPv1 PARA SNMPv2
• DESCREVEMOS A VERSÃO ORIGINAL (MAIS USADA)
A MIB-2
GRUPO system (RFC 1907)
• DESCRIÇÃO DO DISPOSITIVO (sysDescr)
• NOME DO DISPOSITIVO (sysName)
• IDENTIFICAÇÃO DO AGENTE (sysObjectID)
• DEVERIA IDENTIFICAR O HARDWARE, SOFTWARE, RECURSOS DO AGENTE
• NA PRÁTICA, UM OID DIFERENTE É DADO A CADA VERSÃO DE CADA PRODUTO
• HÁ QUANTO TEMPO O AGENTE ESTÁ NO AR (sysUpTime)
• LOCALIZAÇÃO FÍSICA DO DISPOSITIVO (sysLocation)
• PESSOA RESPONSÁVEL PELO ELEMENTO (sysContact)
• SERVIÇOS OFERECIDOS PELO DISPOSITIVO (sysServices)
• USA UM BIT PARA CADA CAMADA OSI
• NO SNMPv2, FOI MOVIDO PARA A MIB SNMPv2-MIB
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.1919.1.1
system.sysUpTime.0 = Timeticks: (836503909) 96 days, 19:37:19
system.sysContact.0 = "Fernando Barros"
system.sysName.0 = "fw.xpto.com.br"
system.sysLocation.0 = "Sala 202"
system.sysServices.0 = 72
interfaces.ifNumber.0 = 3
interfaces.ifTable.ifEntry.ifIndex.1 = 1
interfaces.ifTable.ifEntry.ifIndex.2 = 2
interfaces.ifTable.ifEntry.ifIndex.3 = 3
interfaces.ifTable.ifEntry.ifDescr.1 = "lo0" Hex: 6C 6F 30
interfaces.ifTable.ifEntry.ifDescr.2 = "le0" Hex: 6C 65 30
interfaces.ifTable.ifEntry.ifDescr.3 = "le1" Hex: 6C 65 31
interfaces.ifTable.ifEntry.ifType.1 = softwareLoopback(24)
interfaces.ifTable.ifEntry.ifType.2 = ethernet-csmacd(6)
interfaces.ifTable.ifEntry.ifType.3 = ethernet-csmacd(6)
interfaces.ifTable.ifEntry.ifMtu.1 = 8232
interfaces.ifTable.ifEntry.ifMtu.2 = 1500
interfaces.ifTable.ifEntry.ifMtu.3 = 1500
interfaces.ifTable.ifEntry.ifSpeed.1 = Gauge: 10000000
interfaces.ifTable.ifEntry.ifSpeed.2 = Gauge: 10000000
interfaces.ifTable.ifEntry.ifSpeed.3 = Gauge: 10000000
interfaces.ifTable.ifEntry.ifPhysAddress.1 = ""
interfaces.ifTable.ifEntry.ifPhysAddress.2 = Hex: 08 00 20 7E 88 2B
interfaces.ifTable.ifEntry.ifPhysAddress.3 = Hex: 08 00 20 7E 88 2B
interfaces.ifTable.ifEntry.ifAdminStatus.1 = up(1)
interfaces.ifTable.ifEntry.ifAdminStatus.2 = up(1)
interfaces.ifTable.ifEntry.ifAdminStatus.3 = up(1)
interfaces.ifTable.ifEntry.ifOperStatus.1 = up(1)
interfaces.ifTable.ifEntry.ifOperStatus.2 = up(1)
interfaces.ifTable.ifEntry.ifOperStatus.3 = up(1)
interfaces.ifTable.ifEntry.ifLastChange.1 = Timeticks: (0) 0:00:00
interfaces.ifTable.ifEntry.ifLastChange.2 = Timeticks: (0) 0:00:00
interfaces.ifTable.ifEntry.ifLastChange.3 = Timeticks: (0) 0:00:00
interfaces.ifTable.ifEntry.ifInOctets.1 = 610783
interfaces.ifTable.ifEntry.ifInOctets.2 = 99903685
interfaces.ifTable.ifEntry.ifInOctets.3 = 94029823
interfaces.ifTable.ifEntry.ifInUcastPkts.1 = 0
interfaces.ifTable.ifEntry.ifInUcastPkts.2 = 0
interfaces.ifTable.ifEntry.ifInUcastPkts.3 = 0
interfaces.ifTable.ifEntry.ifInNUcastPkts.1 = 0
interfaces.ifTable.ifEntry.ifInNUcastPkts.2 = 0
interfaces.ifTable.ifEntry.ifInNUcastPkts.3 = 0
interfaces.ifTable.ifEntry.ifInDiscards.1 = 0
interfaces.ifTable.ifEntry.ifInDiscards.2 = 0
interfaces.ifTable.ifEntry.ifInDiscards.3 = 0
interfaces.ifTable.ifEntry.ifInErrors.1 = 0
interfaces.ifTable.ifEntry.ifInErrors.2 = 0
interfaces.ifTable.ifEntry.ifInErrors.3 = 0
MIB-2: WALK NUM AGENTE
interfaces.ifTable.ifEntry.ifInUnknownProtos.1 = 0
interfaces.ifTable.ifEntry.ifInUnknownProtos.2 = 0
interfaces.ifTable.ifEntry.ifInUnknownProtos.3 = 0
interfaces.ifTable.ifEntry.ifOutOctets.1 = 610783
interfaces.ifTable.ifEntry.ifOutOctets.2 = 98517639
interfaces.ifTable.ifEntry.ifOutOctets.3 = 88755644
interfaces.ifTable.ifEntry.ifOutUcastPkts.1 = 0
interfaces.ifTable.ifEntry.ifOutUcastPkts.2 = 0
interfaces.ifTable.ifEntry.ifOutUcastPkts.3 = 0
interfaces.ifTable.ifEntry.ifOutNUcastPkts.1 = 0
interfaces.ifTable.ifEntry.ifOutNUcastPkts.2 = 0
interfaces.ifTable.ifEntry.ifOutNUcastPkts.3 = 0
interfaces.ifTable.ifEntry.ifOutDiscards.1 = 0
interfaces.ifTable.ifEntry.ifOutDiscards.2 = 0
interfaces.ifTable.ifEntry.ifOutDiscards.3 = 0
interfaces.ifTable.ifEntry.ifOutErrors.1 = 0
interfaces.ifTable.ifEntry.ifOutErrors.2 = 5422
interfaces.ifTable.ifEntry.ifOutErrors.3 = 8
interfaces.ifTable.ifEntry.ifOutQLen.1 = Gauge: 0
interfaces.ifTable.ifEntry.ifOutQLen.2 = Gauge: 0
interfaces.ifTable.ifEntry.ifOutQLen.3 = Gauge: 0
interfaces.ifTable.ifEntry.ifSpecific.1 = OID: .ccitt.nullOID
interfaces.ifTable.ifEntry.ifSpecific.2 = OID: .ccitt.nullOID
interfaces.ifTable.ifEntry.ifSpecific.3 = OID: .ccitt.nullOID
ip.ipForwarding.0 = forwarding(1)
ip.ipDefaultTTL.0 = 255
ip.ipInReceives.0 = 189046788
ip.ipInHdrErrors.0 = 241
ip.ipInAddrErrors.0 = 0
ip.ipForwDatagrams.0 = 186087726
ip.ipInUnknownProtos.0 = 0
ip.ipInDiscards.0 = 783
ip.ipInDelivers.0 = 1384691
ip.ipOutRequests.0 = 904804
ip.ipOutDiscards.0 = 0
ip.ipOutNoRoutes.0 = 0
ip.ipReasmTimeout.0 = 60
ip.ipReasmReqds.0 = 1624
ip.ipReasmOKs.0 = 1624
ip.ipReasmFails.0 = 0
ip.ipFragOKs.0 = 4
ip.ipFragFails.0 = 0
ip.ipFragCreates.0 = 22
ip.ipAddrTable.ipAddrEntry.ipAdEntAddr.127.0.0.1 = IpAddress: 127.0.0.1
ip.ipAddrTable.ipAddrEntry.ipAdEntAddr.200.252.241.2 = IpAddress: 200.252.241.2
ip.ipAddrTable.ipAddrEntry.ipAdEntAddr.200.252.242.53 = IpAddress: 200.252.242.53
ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = 1
ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.200.252.241.2 = 3
ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.200.252.242.53 = 2
ip.ipAddrTable.ipAddrEntry.ipAdEntNetMask.127.0.0.1 = IpAddress: 255.0.0.0
ip.ipAddrTable.ipAddrEntry.ipAdEntNetMask.200.252.241.2 = IpAddress: 255.255.255.248
ip.ipAddrTable.ipAddrEntry.ipAdEntNetMask.200.252.242.53 = IpAddress: 255.255.255.128
ip.ipAddrTable.ipAddrEntry.ipAdEntBcastAddr.127.0.0.1 = 0
ip.ipAddrTable.ipAddrEntry.ipAdEntBcastAddr.200.252.241.2 = 1
ip.ipAddrTable.ipAddrEntry.ipAdEntBcastAddr.200.252.242.53 = 1
MIB-2: WALK NUM AGENTE
icmp.icmpInMsgs.0 = 61390
icmp.icmpInErrors.0 = 0
icmp.icmpInDestUnreachs.0 = 27
icmp.icmpInTimeExcds.0 = 57101
icmp.icmpInParmProbs.0 = 0
icmp.icmpInSrcQuenchs.0 = 0
icmp.icmpInRedirects.0 = 0
icmp.icmpInEchos.0 = 4208
icmp.icmpInEchoReps.0 = 54
icmp.icmpInTimestamps.0 = 0
icmp.icmpInTimestampReps.0 = 0
icmp.icmpInAddrMasks.0 = 0
icmp.icmpInAddrMaskReps.0 = 0
icmp.icmpOutMsgs.0 = 182290
icmp.icmpOutErrors.0 = 0
icmp.icmpOutDestUnreachs.0 = 90030
icmp.icmpOutTimeExcds.0 = 87547
icmp.icmpOutParmProbs.0 = 0
icmp.icmpOutSrcQuenchs.0 = 0
icmp.icmpOutRedirects.0 = 505
icmp.icmpOutEchos.0 = 0
icmp.icmpOutEchoReps.0 = 4208
icmp.icmpOutTimestamps.0 = 0
icmp.icmpOutTimestampReps.0 = 0
icmp.icmpOutAddrMasks.0 = 0
icmp.icmpOutAddrMaskReps.0 = 0
tcp.tcpRtoAlgorithm.0 = vanj(4)
tcp.tcpRtoMin.0 = 200
tcp.tcpRtoMax.0 = 60000
tcp.tcpMaxConn.0 = -1
tcp.tcpActiveOpens.0 = 9892
tcp.tcpPassiveOpens.0 = 3575
tcp.tcpAttemptFails.0 = 175
tcp.tcpEstabResets.0 = 55
tcp.tcpCurrEstab.0 = Gauge: 2
tcp.tcpInSegs.0 = 145450
tcp.tcpOutSegs.0 = 108150
tcp.tcpRetransSegs.0 = 11268
...
tcp.tcpConnTable.tcpConnEntry.tcpConnState.127.0.0.1.32773.127.0.0.1.33692 =
established(5)
...
tcp.tcpConnTable.tcpConnEntry.tcpConnLocalAddress.127.0.0.1.32773.127.0.0.1
.33692 = IpAddress: 127.0.0.1
...
tcp.tcpConnTable.tcpConnEntry.tcpConnLocalPort.127.0.0.1.32773.127.0.0.1.
33692 = 32773
...
tcp.tcpConnTable.tcpConnEntry.tcpConnRemAddress.127.0.0.1.32773.127.0.0.1.
33692 = IpAddress: 127.0.0.1
...
tcp.tcpConnTable.tcpConnEntry.tcpConnRemPort.127.0.0.1.32773.127.0.0.1.
33692 = 33692
...
udp.udpInDatagrams.0 = 1246911
udp.udpNoPorts.0 = 1246911
udp.udpInErrors.0 = 0
udp.udpOutDatagrams.0 = 638087
O NÍVEL DE APLICAÇÃO
CONTEÚDO DO CAPÍTULO:
• APLICAÇÕES E PLATAFORMAS DE GERÊNCIA
• ALGUMAS MIBs IMPORTANTES
• GERÊNCIA DE CONFIGURAÇÃO
• GERÊNCIA DE FALTA
• GERÊNCIA DE DESEMPENHO
• MONITORAÇÃO REMOTA (RMON)
• GERÊNCIA DE HOSPEDEIROS
• GERÊNCIA DE APLICAÇÕES
APLICAÇÕES E PLATAFORMAS DE GERÊNCIA
GERÊNCIA DE REDE E GERÊNCIA DE SISTEMA
• UMA REDE CORPORATIVA NÃO CONSISTE APENAS DA INFRA-ESTRUTURA DE REDE
• TUDO TEM QUE FUNCIONAR, NÃO APENAS A INFRA-ESTRUTURA DE REDE
• A GERÊNCIA DE REDE:
• ELEMENTOS GERENCIADOS:
• ROTEADORES
• PONTES
• SWITCHES
• HUBS
• REPETIDORES
• CABEAMENTO
• MODEMS
• SERVIDORES DE TERMINAIS
• MULTIPLEXADORES
• ENLACES SÍNCRONOS PRIVADOS
• ENLACES FRAME RELAY
• CONEXÕES ATM
• ETC.
• TAREFAS TÍPICAS DE GERENCIAMENTO DESSES ELEMENTOS
• CONFIGURAÇÃO DE DISPOSITIVOS
• ADMINISTRAÇÃO DE ENDEREÇOS IP
• SERVIÇOS DE DIRETÓRIO
• MONITORAÇÃO DE TRÁFEGO
• DIAGNÓSTICO DE FALTAS
• TRATAMENTO DE ALARMES
• RESTAURAÇÃO DE SERVIÇO
• ANÁLISE DE DADOS E RELATÓRIOS
• TROUBLE TICKETING
• SEGURANÇA DE REDE
• INVENTÁRIO
• A GERÊNCIA DE SISTEMAS
• ELEMENTOS GERENCIADOS:
• SERVIDORES DE ARQUIVOS
• SERVIDORES DE IMPRESSÃO
• SERVIDORES DE BANCO DE DADOS
• SERVIDORES DE APLICAÇÃO
• ESTAÇÕES DE TRABALHO
• BANCOS DE DADOS
• SISTEMAS OPERACIONAIS
• CORREIO ELETRÔNICO
• APLICAÇÕES (SHRINK-WRAPPED, IN-HOUSE, ETC.)
• TAREFAS TÍPICAS DE GERENCIAMENTO DESSES ELEMENTOS
• AUTOMAÇÃO DE CONSOLE
• MONITORAÇÃO DE DESEMPENHO
• DIAGNÓSTICO DE FALTAS
• INVENTÁRIO
• DISTRIBUIÇÃO DE SOFTWARE
• CONTROLE DE LICENÇAS DE SOFTWARE
• ADMINISTRAÇÃO DE USUÁRIOS (CONTAS)
• TROUBLE TICKETING
• GERÊNCIA DE ARMAZENAMENTO
• BACKUP
• GERÊNCIA DE SPOOL
• SEGURANÇA DE SISTEMA
AS ÁREAS DE GERÊNCIA
• A CLASSIFICAÇÃO ACIMA MOSTRA DUAS DIMENSÕES
• PARA CADA DIMENSÃO, PODEMOS SUB-DIVIDIR EM 5 ÁREAS (CLASSIFICAÇÃO ISO):
• GERÊNCIA DE CONFIGURAÇÃO
• GERÊNCIA DE FALTAS
• GERÊNCIA DE DESEMPENHO
• GERÊNCIA DE SEGURANÇA
• GERÊNCIA DE CONTABILIDADE
• NESTA LISTA, AS ÁREAS DA ISO ESTÃO EM ORDEM DE IMPORTÂNCIA PARA O USUÁRIO
• JÁ VIMOS ALGUNS DETALHES DE CADA ÁREA ANTES E VEREMOS MAIS DETALHES À FRENTE
APLICAÇÕES DE GERÊNCIA
• LISTAMOS ABAIXO ALGUMAS APLICAÇÕES TÍPICAS DE UM AMBIENTE DE GERÊNCIA
• O PROPÓSITO É MOSTRAR A VARIEDADE (E COMPLEXIDADE!) DAS APLICAÇÕES DE GERÊNCIA NECESSÁRIAS NUMA SOLUÇÃO DE GERÊNCIA COMPLETA
• TAMBÉM MOSTRA COMO A FUNCIONALIDADE É TIPICAMENTE JUNTADA EM APLICAÇÕES
• NENHUMA APLICAÇÃO DE GERÊNCIA FAZ TUDO!
• POLLING SNMP E MIB BROWSING
• TRATAMENTO DE TRAPS
• AUTODESCOBRIMENTO E AUTOTOPOLOGIA
• TRATAMENTO DE EVENTOS (RECEPÇÃO, FILTRAGEM, CORRELAÇÃO) E ALARMES
• AUTOMAÇÃO DE DIAGNÓSTICO (SISTEMAS ESPECIALISTAS)
• TOUBLE TICKETING, HELP DESK
• CONFIGURAÇÃO DE DISPOSITIVOS DE REDE
• MONITORAÇÃO E ANÁLISE DE TRÁFEGO
• ANÁLISE ESTATÍSTICA, TRENDING, EMISSÃO DE RELATÓRIOS
• INVENTÁRIO, GERÊNCIA DA PLANTA BAIXA DE CABEAMENTO
• PLANEJAMENTO DE CAPACIDADE, PROJETO DE REDE
• GERÊNCIA DE ESTAÇÕES CLIENTES (PCs)
• AUTOMAÇÃO DE CONSOLE, CONSOLIDAÇÃO DE MENSAGENS PARA O OPERADOR
• GERÊNCIA DE BANCOS DE DADOS
• GERÊNCIA DE APLICAÇÕES
• GERÊNCIA DE CONFIGURAÇÃO E CONTROLE DE MUDANÇA
• GERÊNCIA DE HOSPEDEIRO (GERÊNCIA DE WORKLOAD, ARMAZENAMENTO, BACKUP, CONTAS DE USUÁRIOS, ...)
• GERÊNCIA DE IMPRESSÃO (SPOOL)
• DISTRIBUIÇÃO DE SOFTWARE, GERÊNCIA DE LICENÇAS
• CONTABILIDADE DE RECURSOS E FATURAMENTO
• GERÊNCIA DE SEGURANÇA
PLATAFORMAS DE GERÊNCIA
• FRAMEWORK DE GERENCIAMENTO
• FRAMEWORK É UMA SOLUÇÃO QUASE PRONTA PARA RESOLVER UM PROBLEMA DE UM CERTO DOMÍNIO E QUE PODE SER ADEQUADO A UMA SOLUÇÃO PARTICULAR ATRAVÉS DO FORNECIMENTO (OU REDEFINIÇÃO) DE CERTOS MÓDULOS
• BASEADO NO HOLLYWOOD PRINCIPLE: "DON'T CALL US, WE'LL CALL YOU"
• CAPTURA AS COISAS COMUNS QUE QUALQUER APLICAÇÃO DE GERÊNCIA QUER
• PERMITE INTEGRAR AS VÁRIAS APLICAÇÕES DE GERÊNCIA
• AS APLICAÇÕES PODEM SE INTEGRAR MELHOR SE USAREM A API DA PLATAFORMA
• PORTANTO, A PLATAFORMA É TAMBÉM UM AMBIENTE DE DESENVOLVIMENTO
• ARQUITETURA GERAL DE UMA PLATAFORMA DE GERÊNCIA
• OBSERVE OS SEGUINTES COMPONENTES/CARACTERÍSTICAS:
• A PLATAFORMA EXECUTA NUMA NETWORK MANAGEMENT STATION (NMS)
• A NMS É ACESSADA ATRAVÉS DE ESTAÇÕES DE DISPLAY
• AS VEZES, DIZ-SE QUE A NMS É UM "SERVIDOR DE GERENCIAMENTO" E AS ESTAÇÕES DE DISPLAY SÃO "ESTAÇÕES DE GERÊNCIA"
• VÁRIAS OPÇÕES DE ARQUITETURA GRÁFICA (SISTEMA DE JANELAS, LOOK-AND-FEEL) PODE EXISTIR
• AS APLICAÇÕES DE GERÊNCIA SE "PLUGAM" NA PLATAFORMA
• UMA API (APPLICATION PROGRAMMING INTERFACE) PERMITE QUE AS APLICAÇÕES ACESSEM OS RECURSOS INTERNOS DA PLATAFORMA (EXEMPLO: BANCO DE DADOS DE TOPOLOGIA)
• A PLATAFORMA TRATA DE COMUNICAÇÃO DE BAIXO NÍVEL
• A PLATAFORMA MONITORA (FAZ POLLING E RECEBE TRAPS)
• A PLATAFORMA PODE SUPORTAR VÁRIOS PROTOCOLO DE GERÊNCIA PADRONIZADOS
• OU NÃO-PADRONIZADOS, USANDO GATEWAYS
• A PLATAFORMA MANTÉM VÁRIOS BANCOS DE DADOS
• DE ELEMENTOS GERENCIADOS E TOPOLOGIA
• DE USUÁRIOS
• DE POLÍTICAS DE GERÊNCIA (REGRAS DE GERÊNCIA)
• DE LOG DE EVENTOS
• DE SCRIPTS DE AUTOMAÇÃO
• EX.: CARGA DE PARÂMETROS DE UM ROTEADOR
• DE HELP
• DE MIBs
• AS FUNÇÕES PRINCIPAIS DE UMA PLATAFORMA
• LEVANTAMENTO DA TOPOLOGIA DA REDE
• ELABORAÇÃO DE MAPAS DE REDE
• DANDO VÁRIAS VISÕES DA REDE (FÍSICA, CONECTIVIDADE, DEPARTAMENTAL, ...)
• NOTIFICAÇÕES DE ALARME SÃO FREQUENTEMENTE FEITAS NO MAPA COM UM CÓDIGO DE COR
• CARGA E MANIPULAÇÃO DE MIBs
• BROWSING DE MIBs
• TRATAMENTO DE EVENTOS
• EVENTOS SÃO GERADOS COM TRAPS OU VIA POLLING
• PODENDO INCLUIR FILTRAGEM, CORRELAÇÃO, TRANSFORMAÇÃO EM ALARMES
• INCLUI AVISOS AO USUÁRIO (SONOROS, VISUAIS, EMAIL, PAGER, ...)
• O DIAGNÓSTICO DE FALHAS (ISOLAÇÃO) É FREQUENTEMENTE FEITO PELAS APLICAÇÕES ADICIONAIS
• LOG TOTAL DE EVENTOS INTERESSANTES
• GERAÇÃO DE RELATÓRIOS
• HELP INTEGRADO
• INTERFACE VIA EMULAÇÃO DE TERMINAL (TELNET)
• GERÊNCIA PELA "PORTA DOS FUNDOS"
• FREQUENTEMENTE USADO DEVIDO À FRACA SEGURANÇA DO SNMP
• EMPRESAS FREQUENTEMENTE DESABILITAM A OPERAÇÃO "SET" DO SNMP
• INTEGRAÇÃO DAS APLICAÇÕES (VIDE À FRENTE)
• VISÃO LÓGICA DE UMA PLATAFORMA COM APLICAÇÕES
• INTEGRAÇÃO DAS APLICAÇÕES À PLATAFORMA
• NECESSIDADE DE TER INTEGRAÇÃO SEAMLESS ("SEM COSTURAS")
• HÁ ENORMES DIFERENÇAS DE NÍVEL DE INTEGRAÇÃO ENTRE APLICAÇÕES E A PLATAFORMA
• VÁRIAS FORMAS DE INTEGRAÇÃO SEGUEM
• INTERFACE DO USUÁRIO
• A APLICAÇÃO POSSUI O MESMO TIPO DE INTERFAEC QUE A PLATAFORMA COM LOOK-AND-FEEL SIMILAR (EX. MOTIF, WINDOWS, ...)
• INTEGRAÇÃO PELO MENU
• A APLICAÇÃO PODE SER EXECUTADA A PARTIR DO MENU DA PLATAFORMA
• HELP
• O HELP DA APLICAÇÃO ESTÁ INTEGRADO COM O HELP DA PLATAFORMA
• NAVEGAÇÃO ÚNICA, ÍNDICE INTERGADO, ...
• TOPOLOGIA
• A APLICAÇÃO ACESSA O BD DE OBEJTOS E TOPOLOGIA MANTIDA PELA PLATAFORMA
• EVITA DUPLICAÇÃO
• MUITAS APLICAÇÕES FAZEM SEU PRÓPRIO DISCOVERY
• IMAGINE CADASTRAR 500 ELEMENTOS NA PLATAFORMA E EM 3 APLICAÇÕES DIFERENTES!!
• BASE DE DADOS
• A APLICAÇÃO USA O BD DA PLATAFORMA PARA ARMAZENAR SEUS PRÓPRIOS DADOS
• EVITA DUPLICAÇÃO E PERMITE ACESSO A DADOS VIA SQL
• PROVAVELMENTE PERMITE MELHORES RELATÓRIOS COM FERRAMENTAS MAIS PODEROSAS DE GERAÇÃO DE RELATÓRIOS
• MIB
• AS MIBs NECESSÁRIAS PARA A APLICAÇÃO SÃO CARREGADAS PELA PLATAFORMA E DISPONIBILIZADAS PARA A APLICAÇÃO
• COMUNICAÇÃO
• A APLICAÇÃO USA A PLATAFORMA PARA ACESSAR OS ELEMENTOS GERENCIADOS
• POLL SNMP, ATENDIMENTO A TRAPS, ETC.
• EVITA POLL DUPLICADO AOS ELEMENTOS
• EVENTOS
• OS EVENTOS GERADOS PELA APLICAÇÃO PODEM SER MANIPULADOS PELA PLATAFORMA
• INSTALAÇÃO
• A APLICAÇÃO POSSUI UM PROCESSO DE INSTALAÇÃO COMPATÍVEL COM A INSTALAÇÃO DA PLATAFORMA
• PROCESSOS
• A APLICAÇÃO ESTÁ INTEGRADA COM OS PROCESSOS QUE EXECUTAM A PLATAFORMA
• POR EXEMPLO, AO ENCERRAR A PLATAFORMA, A APLICAÇÃO TAMBÉM É ENCERRADA
• DIAGNÓSTICO (TRACING/LOGGING)
• A APLICAÇÃO PROVÊ A PLATAFORMA DE INFORMAÇÕES DE DIAGNÓSTICO A RESPEITO DE CONDIÇÕES INESPERADAS
• PODE-SE ASSIM MANTER UMA ÚNICA BASE DE DADOS DE INFORMAÇÕES DE DIAGNÓSTICO
• LOCALIZAÇÃO DE ARQUIVOS
• A APLICAÇÃO SEGUE AS NORMAS DA PLATAFORMA PRAA DAR NOMES AOS ARQUIVOS E EVITAR CONFLITOS DE NOMES COM A PLATAFORMA E COM OUTRAS APLICAÇÕES
• AS GRANDES PLATAFORMAS
• OPEN VIEW (HEWLETT PACKARD)
• NETVIEW (IBM)
• TIVOLI (IBM)
• SUNNET MANAGER (SUN MICROSYSTEMS)
• SPECTRUM (CABLETRON)
• CA-UNICENTER (COMPUTER ASSOCIATES)
GERÊNCIA DISTRIBUÍDA
• FALTA DE ESCALA NA SOLUÇÃO CENTRALIZADAS APRESENTADA ATÉ AGORA
• TRÁFEGO DEMAIS INDO PARA A NMS
• GARGALO DE COMUNICAÇÃO
• EVENTOS DEMAIS A SEREM TRATADOS PELA NMS
• GARGALO DE PROCESSADOR
• FALTA DE MOBILIDADE NA CONSOLE
• NÃO É PROBLEMA SE USAR INTERFACE WEB
• NÚMERO LIMITADO DE USUÁRIOS PODEM EXECUTAR A GERÊNCIA SIMULTANEAMENTE
• SOLUÇÕES INCIPIENTES AINDA
• VEREMOS ALGUMAS NUM CAPÍTULO À FRENTE
• A ÚNICA SOLUÇÃO (PARCIAL) MADURA É O USO DE REMOTE MONITORING PROBES (SONDAS DE MONITORAÇÃO REMOTA)
ALGUMAS MIBs IMPORTANTES
• A LISTA COMPLETA DE MIBs DE GERÊNCIA ESTA AQUI
• FALAREMOS DO CONTEÚDO DE ALGUMAS DESSAS MIBs E DE SUA UTILIDADE PARA O GERENCIAMENTO ADIANTE
SNMPv1
RFC
Título Status
1213 Management Information Base for Network Management of TCP/IP-based internets: MIB-II standard
1157 A Simple Network Management Protocol (SNMP) standard
1155 Structure and Identification of Management Information for TCP/IP-based Internets standard
SNMPv2
RFC
Título Status
1908 Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework draft
1907 Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2) draft
1906 Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2) draft
1905 Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2) draft
1904 Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2) draft
1903 Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2) draft
1902 Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2) draft
1901 Introduction to Community-based SNMPv2 experimental
SNMPv3
RFC
Título Status
2275 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) proposed
2274 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) proposed
2273 SNMPv3 Applications proposed
2272 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) proposed
2271 An Architecture for Describing SNMP Management Frameworks proposed
Network
RFC
Título Status
2096 IP Forwarding Table MIB proposed
2021 Remote Network Monitoring Management Information Base Version 2 using SMIv2 proposed
2011 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 internets: MIB-II standard
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 SMIv2 (IPOA-MIB) proposed
2233 The Interfaces Group MIB using SMIv2 proposed
2108 Definitions of Managed Objects for IEEE 802.3 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 Base (MIB) using SMIv2 proposed
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: EMAIL)
• DESTA FORMA, SE O EMAIL DEIXAR DE FUNCIONAR, PODE-SE DIAGNOSTICAR P PROBLEMA MAIS RAPIDAMENTE
• MESMO ENTRE AS PRIMEIRAS 2 VISÕES, TEM MUITA DIFERENÇA DEVIDO A
• EQUIPAMENTOS TRANSPARENTES (HBS, PONTES, SWITCHES)
• LANS VIRTUAIS (VLANs OU DOMÍNIOS DE BROADCAST CONFIGURÁVEIS)
• PORT SWITCHING HUBS
• NÃO TEM "SWITCHING", APESAR DO NOME
• HUBS COM SEGMENTAÇÃO CONFIGURÁVEL
• EQUIVALENTE A DOMÍNIO DE COLISÃO CONFIGURÁVEL
• MESNOS POPULARES HOJE DEVIDO A QUEDA DE PREÇO DE SWITCHES
• GOSTARÍAMOS DE LEVANTAR AS TOPOLOGIAS DE FORMA AUTOMÁTICA
• É MUITO IMPORTANTE PARA UMA SOLUÇÃO DE GERÊNCIA, JÁ QUE ENTRAR COM TODA ESTA INFORMAÇÃO MANUALMENTE E MANTÊ-LA ATUALIZADA É DIFÍCIL OU IMPOSSÍVEL
• PARA REDES GRANDES, É IMPOSSÍVEL. BASTA PENSAR QUE NUMA REDE GRANDE, HÁ DEZENAS DE MUDANÇAS DIÁRIAS DE TOPOLOGIA E ELAS NÃO SÃO SEQUER INFORMADAS AO "PESSOAL DE GERÊNCIA"
• HOJE, A VISÃO DE CONECTIVIDADE LÓGICA PODE SER LEVANTADA
• A CONECTIVIDADE FÍSICA TAMBÉM, MAS DEPENDENDO DE TER DISPOSITIVOS GERENCIÁVEIS EM TODO LUGAR, MESMO NOS DISPOSITIVOS NORMALMENTE TRANSPARENTES (HUBS, SWITCHES)
• OS OUTROS TIPOS DE CONECTIVIDADE DEVEM SER INFORMADAS (CONFIGURADAS) MANUALMENTE
• FALAREMOS ABAIXO DE ALGUNS ALGORITMOS PARA:
• O DESCOBRIMENTO DE DISPOSITIVOS
• O DESCOBRIMENTO DA TOPOLOGIA LÓGICA (CONECTIVIDADE LÓGICA)
• O RESULTADO É ARMAZENADO NUM BANCO DE DADOS, NORMALMENTE PELA ESTAÇÃO DE GERÊNCIA
• HÁ DUAS FORMAS BÁSICAS DE DESCOBRIR DISPOSITIVOS E TOPOLOGIA
• FORMA ATIVA, ONDE A NMS ENVIA INFORMAÇÃO NA REDE PARA DESCOBRIR INFORMAÇÃO
• DESCOBRIMENTO MAIS VELOZ MAS COM MAIOR INTERFERÊNCIA
• A FORMA PASSIVA EM QUE A NMS (OU OUTROS DISPOSITIVOS) ESCUTA A REDE DE FORMA PASSIVA E DESCOBRE DISPOSITIVOS SEM CARREGAR A REDE COM TRÁFEGO ADICIONAL
• VÁRIOS PROTOCOLOS PODEM SER USADOS PARA DESCOBRIR DISPOSITIVOS E TOPOLOGIA:
• ARP (ADDRESS RESOLUTION PROTOCOL)
• ICMP (INTERNET CONTROL MESSAGE PROTOCOL)
• RIP (ROUTING INFORMATION PROTOCOL)
• DNS (DOMAINS NAME SERVICE)
• SNMP (SIMPLE NETWORK MANAGEMENT PROTOCOL)
• 1. MONITORAÇÃO PASSIVA DE PACOTES ARP
• INTERFACE TEM QUE ENTRAR EM MODO PROMÍSCUO
• ESCUTA TODOS OS PACOTES ARP E CONSTROI UMA LISTA DE ENDEREÇOS MAC/IP
• SÓ FUNCIONA PARA SUB-REDES CONECTADAS DIRETAMENTE À ESTAÇÃO QUE ESCUTA
• 2. MONITORAÇÃO ATIVA DE PACOTES ARP
• ENVIA PACOTES IP USANDO UDP PARA UMA PORTA SEM UTILIZAÇÃO PROVÁVEL E MONITORA O ARP QUE SAÍ E A RESPOSTA ARP
• PODE MONITORAR TAMBÉM O PACOTE DE ERRO (PORT UNREACHABLE) QUE VOLTA
• LIMITA A GERAÇÃO A MAIS OU MENOS 4 PACOTES/SEG. PARA NÃO CARREGAR A REDE DEMAIS
• SÓ FUNCIONA PARA SUB-REDES CONECTADAS DIRETAMENTE À ESTAÇÃO QUE ESCUTA
• 3. SCAN SEQUENCIAL DE ENDEREÇOS IP COM PACOTE ICMP ECHO
• PARA UMA REDE CLASSE B, VAI GERAR: 65000 ECHOS, 65000 RESPOSTAS, 65000 PACOTES ARPs (EM BROADCAST!), 65000 RESPOSTAS ARP
• O QUE MATA É O BROADCAST DE ARP
• MUITO USADO, APESAR DA CARGA
• 4. BROADCAST DE UM PACOTE ICMP ECHO
• USA DIRECTED BROADCAST (ENVIO PARA UMA REDE REMOTA PEDINDO BROADCAST)
• PARECE BOM SE O ESPAÇO DE ENDEREÇAMENTO É GRANDE (CLASS A, B) MAS TEM POUCOS DISPOSITIVOS NA REDE
• PODE GERAR MUITO TRÁFEGO E MUITAS COLISÕES NAS PESPOSTAS
• POR ISSO, NÃO É SUPORTADO EM TODO LUGAR PORQUE MUITOS ROTEADORES DESLIGAM O BROADCAST PARA EVITAR GRANDE TRÁFEGO
• PODE CRIAR BROADCAST STORMS DEVIDO A MÁS IMPLEMENTAÇÕES DE IP (BROADCAST DE BROADCAST, ...)
• 5. PEDIDO ICMP PARA OBTER MÁSCARA DE SUBREDE
• AJUDA A DETERMINAR A ESTRUTURA DA REDE
• PODE AJUDAR A DETECTAR UM PROBLEMA COMUM: MÁSCARAS DE SUBREDE ERRADAS EM INTERFACES DA MESMA REDE
• 6. PACOTE ICMP ECHO COM TIME-TO-LIVE CRESCENTE
• TÉCNICA USADA POR TRACEROUTE
• EXECELENTE PARA DESCOBRIR ROTAS E PORTANTO ROTEADORES
• MANDA O PACOTE PARA ALGUNS ENDEREÇOS DA REDE REMOTA, NÃO TODOS PORQUE O ROTEAMENTO VAI SER IGUAL
• 7. ESCUTA BROADCASTS DO PROTOCOLO RIP
• OS PACOTES RIP CONTÊM TABELAS DE ROTEAMENTO E, PORTANTO, ENDEREÇOS DE REDE E DE ROTEADORES
• 8. EXAMINAR MAPAS DNS PARA DESCOBRIR MÁQUINAS IMPORTANTES E ROTEADORES
• USA ZONE TRANSFERS
• HOJE, ZONE TRANSFERS SÃO FREQUENTEMENTE DESABILITADO POR MOTIVOS DE SEGURANÇA
• 9. BROADCAST DE PACOTE SNMP
• TEMPESTADE DE RESPOSTAS PODE ENGARGALAR A REDE
• QUEM NÃO TEM AGENTE SNMP NÃO É DESCOBERTO
• 10. USANDO SNMP, EXAMINAR A CACHE ARP DOS ROTEADORES
• FAZ PARTE DA MIB
• SÓ PODE SER FEITO QUANDO OS ROTEADORES SÃO DECOBERTOS (VER ADIANTE)
• 11: USANDO SNMP, APROVEITAR A MONITORAÇÃO PASSIVA DE RMON
• VEREMOS RMON ADIANTE
• RMON MANTÉM INFORMAÇÃO SOBRE TUDO QUE VÊ PASSANDO NA REDE E MANTÉM TABELAS QUE DIZEM QUE ENDEREÇOS EXISTEM (INCLUINDO MAC, IP)
• ESTE É O MÉTODO PREFERIDO MAS AINDA NÃO TEM IMPLANTAÇÃO DE RMON EM ESCALA SUFICIENTE PARA DECOBRIR TUDO
• SOLUÇÃO TÍPICA:
• TÉCNICA 3: PING SEQUENCIAL PARA DESCOBRIR DISPOSITIVOS
• UM POUCO DE AJUDA MANUAL PARA INICIAR (EX.: REDES DE INTERESSE)
• TÉCNICA 6: TRACEROUTE DE CADA DISPOSITIVO DESCOBERTO PARA DESCOBRIR ROTEADORES
• TÉCNICA 5: DESCOBRE MÁSCARA DE CADA INTERFACE DE ROTEADORES DESCOBERTA ACIMA
• TÉCNICA 2 (SEGUNDA PARTE): MANDA ECHO PARA UDP PORTA NÃO USADA (PROVAVELMENTE) E ANOTA O ENDEREÇO IP DA MENSAGEM QUE VOLTA (PARA DESCOBRIR A INTERFACE REMOTA NA QUAL O REPLY SAIU E, ASSIM, DESCOBRIR MULTI-HOMED HOSTS)
• IDENTIFICA REDES ATRAVÉS DAS CLASSES IP DESCOBERTAS
• IDENTIFICA SUB-REDES ATRAVÉS DE MÁSCARAS DE SUBREDE
• TÉCNICA 10: VERIFICA CACHE ARP DE ROTEADORES PARA DESCOBRIR NOVOS DISPOSITIVOS COM TEMPO SEM FAZER UM DESCOBRIMENTO TOTAL
• DESCOBRIMENTO DA TOPOLOGIA FÍSICA
• VER LIVRO "HOW TO MANAGE YOUR NETWORK USING SNMP: THE NETWORK MANAGEMENT PRACTICUM", PÁGINA 308
• BASEADO NO SNMP E DEPENDE PORTANTO DE TER AGENTES SNMP NOS HUBS, PONTES E SWITCHES
• DEPENDE DAS MIBS DE REPETIDORES (HUBS) E PONTES
• HÁ UMA MIB DE DESCOBRIMENTO SENDO ELABORADA PELA IETF MAS PARECE QUE O TRABALHO PAROU NO FINAL DE 1998 DEVIDO A UMA PATENTE DA IBM
• SEGUEM RESULTADOS DE "DESCOBRIR" A INTERNET:
• OBTIDO DAQUI: http://www.caida.org/Tools/Skitter
• COMECE AQUI: hopdistance.htm
• APÓS DESCOBRIR OS DISPOSITIVOS E A TOPOLOGIA, QUEREMOS TRAÇAR UM MAPA QUE MOSTRE OS RESULTADOS E EVIDENCIE A CONECTIVIDADE
• É COMUM QUERER MOSTRAR APENAS OS DISPOSITIVOS MAIS IMPORTANTES PARA O USUÁRIO
• COMO DESCOBRIR O QUE E IMPORTANTE?
• HEURÍSTICAS:
• ipForwarding = 1 (gateway ou roteador)
• ifNumber > 2
• sysObject IDENTIFICA O DISPOSITIVO COMO SWITCH OU ROTEADOR OU SERVIDOR
• ipOutRequests/sec > 100
• etc., etc.
• O OPERADOR DA REDE AINDA TEM QUE AJUDAR PARA JUNTAR OS DISPOSITIVOS DO MAPA NAS VISÕES MAIS ÚTEIS PARA ELE
• O MÁXIMO QUE O SOFTWARE DE DESCOBRIMENTO PODE FAZER É AGRUPAR EM SUBREDES IP
• ALÉM DO DESCOBRIMENTO DE TOPOLOGIA, A GERÊNCIA DE TOPOLOGIA TAMBÉM ENVOLVE:
• DEFINIÇÃO DE LANS VIRTUAIS (VLANs) PARA FACILIAR MOVES, ADDS, CHANGES
• CONFIGURAÇÃO DE SPANNING TREE (ESCOLHER A RAIZ DA ÁRVORE, POR EXEMPLO)
• VEREMOS MAIS SOBRE ISSO ADIANTE
CONFIGURAÇÃO DE DISPOSITIVOS
• A CONFIGURAÇÃO DE DISPOSITIVOS DEVE BASEAR-SE EM IMAGENS QUE REPRESENTEM OS DISPOSITIVOS FÍSICOS FIELMENTE
• PODE-SE CONFIGURAR GRAFICAMENTE:
• STATUS DE CADA PORTA
• ENDEREÇOS MAC E/OU IP ASSOCIADOS ÀS PORTAS
• ATRIBUTOS DE PORTAS OU DO DISPOSITIVO
• FAZER UM RESET REMOTO, ETC.
• PARA ROTEADORES, PODE-SE CONFIGURAR O TIPO DE ROTEAMENTO (IP, IPX, APPLETALK), REGRAS DE FILTRAGEM, SE FAZ BRIDGING TAMBÉM OU NÃO, ETC.
• BASELINING
• AS CONFIGURAÇÕES DE DISPOSITIVOS DEVEM SER GUARDADOS EM ARQUIVOS (FORMANDO O BASELINE) DE FORMA A:
• PERMITIR CONFIGURAR UM OU MAIS DISPOSITIVOS SEMELHANTES A PARTIR DE UM ARQUIVO DE BASELINE ARMAZENADO
• VERIFICAR SE A CONFIGURAÇÃO DA REDE INTEIRA ESTÁ DE ACORDO COM O BASELINE
• RECONFIGURAR A REDE PARCIAL OU TOTALMENTE A PARTIR DO BASELINE EM CASO DE PROBLEMA
• A CONFIGURAÇÃO DE DISPOSITIVOS PERMITE AINDA:
• INSTALAR NOVAS VERSÕES DO SOFTWARE DE CONTROLE, INCLUINDO AGENTES
• PERMITE FAZER UPDATE EM BULK (VÁRIOS DISPOSITIVOS)
• PERMITE FAZER UPDATE ESCALONADO (À NOITE)
• PERMITE FAZER UPDATE AUTOMÁTICO (SEM ATENDIMENTO HUMANO)
• NORMALMENTE USA TFTP (TRIVIAL FILE TRANSFER PROTOCOL)
• RASTREAR O HISTÓRICO DE TODOS OS UPGRADES E MUDANÇAS DE CONFIGURAÇÃO DOS DISPOSITIVOS
• FREQUENTEMENTE FEITO A PARTIR DE UM SOFTWARE DE COTROLE DE INVENTÁRIO QUE PODE CONTROLAR TAMBÉM OS CONTRATOS DE MANUTENÇÃO, ETC.
• A PLANTA BAIXA DE CABEAMENTO, INCLUINDO LAYOUT DOS PRÉDIOS, ETC.
GERÊNCIA DE FALTAS
A GERÊNCIA DE FALTAS PODE SER DIVIDIDA NAS SEGUINTES TAREFAS BÁSICAS:
• COLETA DE DADOS E DETECÇÃO DE FALTAS
• MANUTENÇÃO E MONITORAÇÃO DO ESTADO DE CADA UM DOS ELEMENTOS GERENCIADOS
• PERCEPÇÃO DE QUE ESTÁ HAVENDO UM PROBLEMA
• PODE INCLUIR A ANTECIPAÇÃO DE FALHAS
• MONITORAÇÃO DE INDICADORES QUE POSSAM PREVER A OCORRÊNCIA DE FALHAS
• TAXAS CRESCENTES DE ERRO, ATRASOS DE TRANSMISSÃO
• USO DE LIMIARES (THRESHOLD) PARA GERAR ALARMES
• DIAGNÓSTICO DE PROBLEMAS
• TAMBÉM CHAMADO DE ISOLAÇÃO DE FALHAS
• UMA FALTA PODE GERAR UMA FALHA
• USAMOS OS 2 TERMOS DE FORMA INTERCAMBIÁVEL
• USO DE TÉCNICAS PARA DIAGNOSTICAR A LOCALIZAÇÃO E RAZÃO DA FALHA
• TÉCNICAS PODEM USAR CORRELAÇÃO DE EVENTOS, TESTES DE DIAGNÓSTICOS, ...
• USO DE SISTEMAS ESPECIALISTAS
• SOLUÇÕES EMERGENCIAIS
• PARA NÃO DEIXAR A REDE PARADA
• PODE NECESSITAR DE TESTES ADICIONAIS
• PARA PERMITIR A VERIFICAÇÃO DO FUNCIONAMENTO DE RECURSOS DA REDE EM CONDIÇÕES NORMAIS OU ARTIFICIAIS
• EXEMPLOS: TESTES DE ECO, DE CONECTIVIDADE
• RESOLUÇÃO DE PROBLEMAS
• AÇÕES NECESSÁRIAS AO RESTABELECIMENTO DOS ELEMENTOS COM PROBLEMAS
• AÇÕES PODE SER SUGERIDAS AUTOMATICAMENTE
• USO DE SISTEMAS ESPECIALISTAS
• NOTIFICAÇÃO E TRACKING
• TAMBÉM CHAMADO SUPERVISÃO DE ALARMES
• INTERFACE DO USUÁRIO INDICA QUAIS ELEMENTOS ESTÃO FUNCIONANDO, QUAIS ESTÃO FUNCIONANDO PARCIALMENTE E QUAIS ESTÃO FORA DE OPERAÇÃO
• INCLUI NÍVEIS DE SEVERIDADE
• PODE INDICAR POSSÍVEIS CAUSAS
• PODE AVISAR VISUALMENTE, COM EMAIL, PAGER, ...
• PROVÊ REGISTRO DE OCORRÊNCIAS E EMISSÃO DE RELATÓRIOS PARA ANÁLISE
SOBRE EVENTOS E ALARMES
• EVENTOS SÃO MOMENTOS "INTERESSANTES" DE ATIVIDADE NA REDE
• PODEM REPRESENTAR FALHAS OU NÃO
• PODEM SER IMPORTANTES OU NÃO
• UMA FALHA PODE DESENCADEAR MUITOS EVENTOS
• QUEREMOS LEVAR PROBLEMAS (E NÃO EVENTOS INDIVIDUAIS) À ATENÇÃO DO OPERADOR ATRAVÉS DE ALARMES
• DEVE PORTANTO HAVER FILTRAGEM DE EVENTOS PARA GERAR ALARMES
• NA REALIDADE, PODE HAVER VÁRIOS TIPOS DE FILTROS
• FILTROS BASEADOS EM THRESHOLDS PARA GERAR EVENTOS A PARTIR DE MEDIÇÕES
• FILTROS DE AGRUPAMENTO PARA CORRELACIONAR EVENTOS ENTRE SI E DESCOBRIR CAUSAS COMUNS (PROBLEMAS)
• FILTROS DE PRIORIDADE ASSOCIAM UMA CRITICALIDADE A PROBLEMAS (E O ALARME CORRESPONDENTE)
• A AÇÃO A SER FEITA POR UMA ALARME É CONFIGURÁVEL
• MUDAR O MAPA DA REDE
• ENVIAR UM EMAIL
• MANDAR UMA MENSAGEM PARA UM PAGER
• ETC.
• VER O RESULTADO NA FIGURA ABAIXO
USO DE LIMIARES (THRESHOLDS)
• LIMIARES SÃO APLICADOS A VARIÁVEIS DE MIB QUE TENHAM VALOR NUMÉRICO
• AS VEZES, DEVE-SE VERIFICAR VALORES ABSOLUTOS DE CONTADORES
• EXEMPLO: ifInErrors, ifOutErrors, ...
• AS VEZES, É PREFERÍVEL USAR PERCENTUAIS
• EXEMPLO: ifInOctets, ifOutOctets, ...
• VALORES DE LIMIARES SÃO AJUSTADOS APÓS DESCOBRIR O COMPORTAMENTO "NORMAL" DO SISTEMA
• UM LIMIAR PODE TER UM VALOR DE "RE-ARMAÇÃO"
• INTRODUZ HISTERESE PARA EVITAR MÚLTIPLOS EVENTOS QUANDO O VALOR OSCILA A REDOR DO LIMIAR
TROUBLE TICKETING
• USADO PARA CONTROLAR PROBLEMAS E ACOMPANHAR SUA SOLUÇÃO
• UM TROUBLE TICKET PODE SER ABERTO POR UM USUÁRIO OU AUTOMATICAMENTE PELA PLATAFORMA OU ALGUMA APLICAÇÃO
• DEPENDE DA POLÍTICA IMPLANTADA
• NORMALMENTE APLICAÇÕES DE TROUBLE TICKETING PERMITEM RELATÓRIOS SOFISTICADOS
• SISTEMAS DE TOUBLE TICKETING PODEM SE INTEGRADOS A UM SISTEMA DE HELP DESK
GERÊNCIA DE FALTAS PARA INTERFACES USANDO A MIB-2
• A MONITORAÇÃO DE INTERFACES PODE SER USADA PARA DETECTAR CONDIÇÕES DE 3 TIPOS DIFERENTES:
• PROBLEMAS: UMA CONDIÇÃO QUE NECESSITA DA ATENÇÃO DO OPERADOR
• PODE USAR UM LIMIAR DE ZERO PARA SEMPRE CHAMAR A ATENÇÃO DO OPERADOR
• CONDIÇÕES NÃO USUAIS: PODEM OCORRER COM BAIXA FREQUÊNCIA MAS PODEM SE TORNAR UM PROBLEMA SE A FREQUÊNCIA AUMENTAR
• CONDIÇÕES NORMAIS DE CARGA (WORKLOAD): PARA CONTABILIZAR A ATIVIDADE NORMAL DE UMA INTERFACE
• PODE TAMBÉM DETECTAR PROBLEMAS DE EXCESSO DE CARGA
• O QUE OLHAR?
• ifOperStatus NÃO IGUAL A ifAdminStatus INDICA UM PROBLEMA
• ifLastChange INDICA QUANDO A INTERFACE MUDOU DE ESTADO
• ifInErrors E ifOutErrors PODEM SER USADOS PARA CALCULAR TAXAS DE ERROS
• AS TAXAS DE ERROS DEVEM SER BAIXAS E MUITO MENORES DO QUE AS TAXAS DE ENTRADA E SAÍDA DE PACOTES
• ifInDiscards E ifOutDiscards INDICAM PACOTES JOGADOS FORA (DESCARTADOS) DEVIDO A LIMITAÇÕES DE RECURSOS (MEMÓRIA, POR EXEMPLO)
• AS TAXAS DE DESCARTE DEVEM SER PEQUENAS E MUITO MENORES DO QUE AS TAXAS DE ENTRADA E SAÍDA DE PACOTES
• ifInUcastPkts E ifInNUcastPkts INDICAM PACOTES DE ENTRADA COM UNICAST E NÃO-UNICAST (NORMALMENTE BROADCAST)
• IDEM PARA ifOutUcastPkts E ifOutNUcastPkts
• AS TAXAS DE BROADCAST DEVEM SER MUITO PEQUENAS (ATÉ UNS 2% DA CAPACIDADE)
• NA IF-MIB (VERSÃO EXPANDIDA DO GRUPO interfaces - VER RFC 2233), TEM CONTADORES SEPARADOS PARA BROADCAST E UNICAST
• ifInUnknownProtos SEMPRE INDICA UM PROBLEMA
• ipForwDatagrams DEVE SER ZERO NUM HOST
• ipInAddrErrors INDICA UM ENDEREÇO ERRADO (EXEMPLO: DE UMA OUTRA SUB-REDE) QUE NÃO DEVERIA TER CHEGADO NESTA INTERFACE: INDICA UM PROBLEMA
• ipOutNoRoutes INDICA DATAGRAMAS JOGADOS FORA DEVIDO À AUSÊNCIA DE ROTA POSSÍVEL: INDICA UM ERRO
• ipInHdrErrors INDICA UMA CONDIÇÃO NÃO USUAL MAS NÃO NECESSARIAMENTE UM PROBLEMA
• A IF-MIB (RFC 2233) PERMITE GERAR UM TRAP QUANDO O ENLACE MUDA DE ESTADO
GERÊNCIA DE FALTAS PARA REDES ETHERNET
• EXISTEM TRÊS MIBs PARA IEEE 802.3
• RFC 2108 PARA REPETIDORES (UM REPETIDOR DE MÚLTIPLAS PORTAS É CHAMADO DE CONCENTRADOR OU HUB)
• AS VARIÁVEIS SÃO rptr...
• RFC 2358 PARA A INFORMAÇÃO DE "ETHERNET-LIKE INTERFACE TYPES" (ETHERLIKE-MIB)
• AS VARIÁVEIS SÃO dot3...
• RFC 2239 PARA A INFORMAÇÃO DE MEDIA ATTACHMENT UNIT (MAU)
• BAIXO NÍVEL PARA DIFERENCIAR 10BASET, 10BASE5, ..., TIPOS DE CONECTORES, BASEBAND VERSUS BROADBAND, ETC.
• USO DAS VARIÁVEIS DA ETHERLIKE-MIB
• ifErrors E ifOutErrors INDICAM ERROS
• SE AUMENTAREM, PODE-SE INVESTIGAR OS ERROS COM MAIS CUIDADO
• ERROS DE ENTRADA (RECEPÇÃO):
VARIÁVEL
DESCRIÇÃO USO PARA DETECTAR FALTAS
dot3StatsAlignmentErrors QUADRO NÃO RECONHECIDO POR NÃO TER NÚMERO INTEIRO DE BYTES PROBLEMA NÃO LOCAL
dot3StatsFCSErrors QUADRO RECONHECIDO MAS COM FRAME CHECK SEQUENCE (CHECKSUM) ERRADO CONDIÇÃO NÃO USUAL: DEVE SER MUITO PEQUENO. SE NÃO FOR, TEM UM PROBLEMA NÃO LOCAL
dot3StatsFrameTooLongs QUADRO MAIOR QUE O MAIOR QUADRO POSSÍVEL ERRO NÃO LOCAL: SOFTWARE REMOTO COM PROBLEMAS
dot3StatsInternalMacReceiveErrors QUADRO NÃO RECEBIDO POR ERRO INTERNO DA CAMADA MAC PROBLEMA LOCAL: FALHA NA PLACA DE REDE
dot3StatsSQETestErrors ERRO NO TESTE ESPECIAL DE INTERFACE CHAMADO "SIGNAL QUALITY ERROR" PROBLEMA LOCAL: FALHA NA PLACA DE REDE
• USO DAS VARIÁVEIS DA ETHERLIKE-MIB (CONTINUAÇÃO)
• CONTADORES DE SAÍDA (TRANSMISSÃO):
VARIÁVEL
DESCRIÇÃO USO PARA DETECTAR FALTAS
dot3StatsSingleCollisionFrames QUADROS RETRANSMITIDOS COM SUCESSO APÓS UMA ÚNICA COLISÃO AQUI SÓ CONTAMOS AS COLISÕES DESTA INTERFACE
O SOMATÓRIO DE COLISÕES DEVE SER <= 2% DO TRÁFEGO DESTA INTERFACE
SE HOUVER COLISÕES DEMAIS NA REDE TODA, O TRÁFEGO ESTÁ ALTO DEMAIS
SE HOUVER COLISÕES DEMAIS DE UMA ÚNICA INTERFACE, A INTERFACE ESTÁ COM PROBLEMA
dot3StatsMultiplesCollisionFrames QUADROS RETRANSMITIDOS COM SUCESSO APÓS MAIS DE UMA COLISÃO VER COLISÕES ACIMA
dot3StatsDefferedTransmissions QUADROS QUE NÃO FORAM TRANSMITIDOS DE PRIMEIRA PORQUE O MEIO ESTAVA OCUPADO CONDIÇÃO NÃO USUAL
dot3StatsLateCollisions QUADROS COM COLISÃO DETECTADA DEPOIS DO TEMPO MÁXIMO POSSÍVEL PARA UMA REDE OPERANDO ADEQUADAMENTE REDE LONGA DEMAIS OU ALGUMA PLACA NÃO DETECTA COLISÕES ADEQUADAMENTE
dot3StatsExcessiveCollisions QUADROS QUE NÃO FORAM TRANSMITIDOS POR TEREM SOFRIDO MAIS DO QUE 16 COLISÕES VER COLISÕES ACIMA
dot3StatsInternalMacTransmitErrors QUADROS NÃO TRANSMITIDOS POR ERRO INTERNO DA CAMADA MAC PROBLEMA LOCAL: FALHA NA PLACA DE REDE
dot3StatsCarrierSenseErrors ERROS DE DETECÇÃO DE PORTADORA PROBLEMA LOCAL: CONEXÃO FROUXA COM O MEIO
dot3CollTable UMA TABELA DE FREQUÊNCIAS DE COLISÕES COM 3 COLUNAS: 2 DE ÍNDICE E A FREQUÊNCIA DE COLISÃO DOS QUADROS. OS ÍNDICES SÃO O ifIndex DA INTERFACE E O NÚMERO POSSÍVEL DE COLISÕES (0 A 15) VER COLISÕES ACIMA
• USO DAS VARIÁVEIS DE REPETIDORES
• DEVIDO À EXISTÊNCIA FREQUENTE DE REPETIDORES EXPANSÍVEIS (STACKABLE HUBS), A MIBS IDENTIFICA:
• UM REPETIDOR, QUE CONTÉM ...
• VÁRIOS GRUPOS, QYE CONTÊM ...
• VÁRIAS PORTAS
• rptrTotalPartionedPorts: INDICA QUANTAS PORTAS ESTÃO AUTO-PARTICIONADA
• ISTO É, REMOVIDAS DA REDE PELO PRÓPRIO HUB DEVIDO A EXCESSO DE COLISÕES OU UMA COLISÃO COM DURAÇÃO ACIMA DO PERMITIDO
• PODE SER DEVIDO A QUEBRA NO CABO, CONECTOR RUIM, ETC.
• rptrPortAdminStatus E rptrPortOperStatus: COMO ifAdminStatus E ifOperStatus
• rptrPortAutoPartitionedState: INDICA SE ESTA PORTA ESTÁ AUTO-PARTICIONADA
• rptrMonitorPortAutoPartitions CONTA AS TRANSIÇÕES DE AUTO-PARTICIONAMENTO E PODE INDICAR UM PROBLEMA INTERMITENTE
• rptrMonitorGroupTotalErrors E rptrMonitorPortTotalErrors EXISTEM PARA FACILITAR O POLLING
• FAZ POLL DE MENOS VARIÁVEIS E INVESTIGA COM MAIS CUIDADO SE HOUVER MUITOS ERROS
• rptrReset PODE SER USADO PARA CAUSAR UM RESET NO EQUIPAMENTO
GERÊNCIA DE DESEMPENHO
SISTEMAS DE FILAS
• UM SISTEMA SIMPLES DE FILAS CONSISTE DE UM SERVIDOR ONDE CHEGAM FREGUESES, FORMANDO UMA FILA
• A FILA SE FORMA DEVIDO À NATUREZA PROBABILÍSTICA DE DUAS VARIÁVEIS
• O TEMPO ENTRE CHEGADAS DE FREGUESES, E
• O TEMPO DE SERVIÇO (PARA ATENDER UM FREGUÊS)
• SISTEMA REGIDO PELAS LEIS DOS PROCESSOS ESTOCÁSTICOS
EXEMPLOS
• BANCO
• SUPERMERCADO
• ENLACE DE COMUNICAÇÃO DE DADOS
• NA FIGURA ACIMA:
• É A MÉDIA DA TAXA DE CHEGADA
• É A MÉDIA DA TAXA DE SERVIÇO
• TOMANDO O EXEMPLO DE UM ENLACE DE COMUNICAÇÃO DE DADOS USANDO COMUTAÇÃO DE PACOTES
• OS FREGUESES SÃO PACOTES (OU QUADROS, ETC., DEPENDENDO DA CAMADA)
• O SERVIDOR É O CANAL DE TRANSMISSÃO
• A FILA SE FORMA PORQUE NOVOS PACOTES PODEM CHEGAR ENQUANTO UM QUADRO ESTÁ SENDO TRANSMITIDO
• COMO CARACTERIZAR E ?
• TEM VÁRIAS FORMAS, DESDE QUE AS UNIDADES SEJAM IGUAIS
• EXEMPLO: SE EXPRESSARMOS E EM BITS POR SEGUNDO, ENTÃO:
• = NÚMERO DE PACOTES/SEGUNDO
• = C/L
• C = CAPACIDADE DO CANAL EM BITS POR SEGUNDO
• L = TAMAMHO MÉDIO DE UM PACOTE EM BITS
• O QUE DETERMINA O DESEMPENHO DA FILA SÃO BASICAMENTE OS PROCESSOS ESTOCÁSTICOS QUE REGEM A ENTRADA E O SERVIÇO
• O QUE É MAIS IMPORTANTE DISSO SÃO AS TAXAS MÉDIAS ( E )
• E PRINCIPALMENTE A UTILIZAÇÃO DO SERVIDOR ( = /)
• A UTILIZAÇÃO PODE SER VISTA COMO O PERCENTUAL DE OCUPAÇÃO DO SERVIDOR
• É UM NÚMERO ENTRE 0 E 1
• A UTILIZAÇÃO INSTANTÂNEA VARIA COM TEMPO
• É A UTILIZAÇÃO MÉDIA
• PODEMOS JUNTAR VÁRIAS FILAS E FORMAR UMA REDE DE FILAS
• EXEMPLO: PARA MODELAR UMA REDE DE COMPUTADORES
• EXERCÍCIO: QUAL SERIA A REDE DE FILAS PARA A SEGUINTE REDE DE COMPUTADORES, SE O CÍRCULOS REPRESENTAM PONTOS DE ENTRADA E SAÍDA DE TRÁFEGO E AS INHAS REPRESENTAM ENLACES DE COMUNICAÇÃO FULL-DUPLEX?
• MEDIDAS DE DESEMPENHO DE INTERESSE
• VAZÃO (C BITS POR SEGUNDO)
• TEMPO DE RESPOSTA
• PODE SER NUM ÚNICO ENLACE MAS É NORMALMENTE FIM-A-FIM
• COMO CARACTERIZAR O TEMPO DE REPOSTA?
• TEM TRÊS COMPONENTES PRINCIPAIS: T = W + TT + TL
• TEMPO DE ESPERA EM FILA
• TEMPO DE SERVIÇO QUE CONSISTE DE:
• TEMPO DE TRANSMISSÃO
• TEMPO DE LATÊNCIA
• COMO ESTIMAR CADA COMPONENTE?
• O TEMPO DE LATÊNCIA TEM BASICAMENTE A VER COM A DISTÂNCIA
• SUPÕE-SE, POR EXEMPLO, QUE O SINAL TRAFEGA A 80% DA VELOCIDADE DA LUZ (300.000 KM/SEG), OU 240.000 KM/SEG OU ENTRE 10 E 15 MILISSEGUNDOS ENTRE RECIFE E SÃO PAULO
• NORMALMENTE É DESPREZÍVEL MAS PODE SER DOMINANTE PARA UM ENLACE DE SATÉLITE (1/4 DE SEG. IDA E VOLTA)
• O TEMPO DE TRANSMISSÃO É O TEMPO QUE OS BITS TEM QUE FICAR NO MEIO ATÉ TERMINAR A TRANSMISSÃO
• TT = TAMANHO MÉDIO DO PACOTE EM BITS / CAPACIDADE DO ENLACE EM BITS POR SEGUNDO
• O TEMPO EM FILA É MAIS DIFÍCIL DE ESTIMAR, MAS PODE-SE USAR O SEGUI
...