Gerência de Redes - 4.RMON

1,488 views
1,334 views

Published on

Gerência de redes, redes, rmon

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,488
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
42
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Monitores são equipamentos e/ou software usados para observar e controlar uma determinada LAN ou conjunto de dispositivos. São também chamados de probes e possuem algum tipo de inteligência, além de armazenar dados coletados. Monitoram a situação normal e alertam um gerente de uma anormalidade com mensagem de traps. Focam em indicadores como limites de erros e perfis de tráfego. Possuem certa independência: em caso de falha no gerente, continuam a coletar dados até a sua volta à operação. Podem ter múltiplas interfaces de rede, permitindo o monitoramento de várias redes distintas ou do tráfego entre elas. Monitores sabem o que ocorre numa rede e possuem inteligência para reagir a certas situações, isto o torna extremamente útil.
  • RMON é uma extensão a SNMP que agrega funcionalidades de monitoramento da rede e oferecem informações vitais para gerenciamento. A MIB II somente oferece informação local de dispositivos individuais. RMON oferece informações que dizem respeito a rede de forma distribuída, como contadores de pacotes e erros numa determinada LAN. Ao final, RMON é basicamente uma especificação de MIB. Nenhuma mudança é necessária na SMI SNMP ou mesmo no protocolo SNMP, está tudo especificado dentro da MIB RMON. A MIB RMON é definida na RFC 2819 e apresenta mecanismos para um gerente configurar e controlar um monitor remoto, coletar seus dados importantes e receber seus alarmes. A MIB também permite o “compartilhamento” do monitor entre várias estações gerentes. Os grupos de objetos RMON ficam abaixo do ramo da MIB-II.
  • A configuração da RMON basicamente diz respeito ao tipo e a forma dos dados a serem coletados. Para cada estatística existe parâmetros definidos pelo gerente (Ex. intervalo de medição). Normalmente, existirão duas tabelas: uma de controle ( control table ) e uma de resultados do monitoramento ( data table ). Para cada pedido existirá um conjunto de dados que estará na tabela de dados. Tentativas de alterar um pedido por parte de um gerente prejudicaria uma coleta em execução, assim, antes de alterar a linha, converte-se ela para invalid . Com isso a coleta é terminada. Várias estações de gerenciamento podem requerer estatísticas e dados da rede simultaneamente. Cada gerente configura seus pedidos na tabela de controle. Cada entrada nesta tabela possui um identificador que será usado depois para reconhecer o dado coletado na tabela de resultados Os problemas que podem surgir com a utilização de um mesmo monitor por vários gerentes são: Muitos pedidos concorrentes de vários gerentes podem sobrecarregar a capacidade de um monitor Uma única estação gerente pode alocar muitos recursos do monitor e mantê-los por muito tempo (“injustiça” no atendimento) Uma estação gerente pode alocar recursos e sofrer um problema impedindo a liberação destes recursos para outros gerentes
  • A tabela em SNMP é uma estrutura lógica de objetos. Existem operações sobre linhas inteiras (deletar, acrescentar, controle de consistência) Criação de linhas: pode-se usar valores default Adição de uma linha: gerente envia operação de set com todos os dados necessários. O monitor verifica a consistência dos dados segundo a MIB RMON Deleção de uma linha: operação de set para EntryStatus como invalid Modificação de linhas: normalmente se deleta as linhas correspondentes e se cria novas de acordo com a alteração. A identificação do gerente que fez o pedido de monitoramento é feita pelo valor do objeto do tipo ownerString. É sugerido que este nome contenha informações específicas da estação gerente como seu endereço IP, o nome da estação, sua localização, ...
  • statistics (1) : contadores simples de tráfego (octetos, colisões, erros, etc) numa interface de rede history (2) : conjuntos de estatísticas pedidas e coletadas em intervalos definidos host (4) : para cada host descoberto na rede, o monitor pode coletar estatísticas de tráfego e erros. hostTopN (5) : os hosts que apresentarem números mais relevantes (“tops”) num determinado intervalo, são ordenados e apresentados numa tabela para fins de geração de relatórios. Requer a implementação do grupo host matrix (6) : estabelece tabelas onde se sabe os valores de tráfego de e para cada sistema na rede. Aqui se reconhece as origens e destinos dos pacotes que trafegam na rede. Cada entrada é criada para cada nova informação de comunicação entre dois endereços, obtida de pacotes recebidos. Útil para detecção de intrusos. filter (7) : parâmetros que definem critérios de filtragem dos pacotes criando “canais” (fluxos de pacotes que satisfazem determinada expressao lógica usada na filtragem) packet capture (8) : configuração do armazenamento dos resultados da filtragem feita (buffers ou número de pacotes a serem capturados). Requer a implementação do grupo filter.
  • alarm (3) : o grupo contém variáveis que devem ser vigiadas e relacionamentos com eventos que serão disparados no caso destas variáveis ultrapassarem certos limites. Estes limites definem o que pode ser um indicativo de problema e também o que pode ser uma volta à normalidade. Sua implementação exige o grupo event. event (9) : define cada evento, o tipo e última ocorrẽncia. Eventos normalmente são gerados por: - Cruzamento de um limiar previamente estabelecido (grupo alarm ) - Resultado de um filtro (grupo filter ) Pode definir ações como notificar um gerente via trap ou atualizar um arquivo de log, ou mesmo acionar uma captura de tráfego.
  • Alarmes podems ser configurados para dispararem em resposta a eventos observados pelo monitor. Por exemplo o monitoramento do número de erros num segmento de LAN pode ser parametrizado com um limite superior (rising threshold) e um inferior (falling threshold). Eventos podem ser configurados para que sejam disparados em função dos parãmetros acima. Por exemplo, o envio de uma trap que alerta para o alto número de erros na LAN.
  • RMON 1 basicamente lidava com quadros em nível de enlace (camada MAC), apesar de chamá-los de pacotes. Uma extensão à RMON 1 era requerida para observar o tráfego de protocolos acima da camada MAC. Assim, monitores RMON 2 podem analisar PDU’s de níveis superiores (camadas de rede até aplicação) oferecendo a possibilidade de monitoramento do tráfego proveniente de roteadores e até de aplicações distintas. Com isso, os fenômenos de tráfego podem ser melhor compreendidos (fatos como aplicações mais “pesadas”, servidores mais acessados, protocolos mais exigidos, etc). Qualquer camada acima de "rede" é chamada uma camada de "aplicação", o que não significa que seja da camada 7 RFC 4502 – é um padrão – STD59. SMON; A MIB SMON é um padrão proposto na RFC 2613. Esta MIB estende as facilidades de RMON para uso em redes comutadas (switched). Neste tipo de rede o tráfego não tem característica broadcast (meio compartilhado). Os mecanismos propostos em RMON não oferecem facilidades para estas características específicas. São disponibilizadas facilidades para monitoramento de tráfego entre portas distintas, espelhamento de tráfego, VLAN’s, e adequação à monitoramento IEEE 802.1q (priorização) e 802.1p (suporte VLAN’s)
  • RMON2 é apresentado como uma extensão de grupos a RMON1. Estes novos objetos específicos irão oferecer as facilidades de RMON2: protocol directory (11) : informações sobre os diversos protocolos que o monitor pode analisar. protocol distribution (12) : dados do tráfego apresentado por protocolo. address map (13) : dados do mapeamento de endereços MAC em endereços de rede e portas. network-layer host (14) : estatísticas de tráfego a nível de endereços de rede, entrante e sainte num determinado host. network-layer matrix (15) : estatísticas de tráfego de e para, a nível de endereços de rede. application-layer host (16) : estatísticas de tráfego a nível de aplicação, entrante e sainte num determinado host. application-layer matrix (17) : estatísticas de tráfego de e para, a nível de aplicação. user history (18) : dados específicos por usuários. probe configuration (19) : parâmetros operacionais de configuração do monitor RMON (configurações de interações com interfaces seriais, aspectos de download de informações, destinos de traps, etc)
  • RMON2 é apresentado como uma extensão de grupos a RMON1. Estes novos objetos específicos irão oferecer as facilidades de RMON2: protocol directory (11) : informações sobre os protocolos que o monitor pode analisar. protocol distribution (12) : dados do tráfego apresentado por protocolo. address map (13) : dados do mapeamento de endereços MAC em endereços de rede. network-layer host (14) : estatísticas de tráfego a nível de endereços de rede, entrante e sainte num determinado host. network-layer matrix (15) : estatísticas de tráfego de e para, a nível de endereços de rede. application-layer host (16) : estatísticas de tráfego a nível de aplicação, entrante e sainte num determinado host. application-layer matrix (17) : estatísticas de tráfego de e para, a nível de aplicação. user history (18) : dados específicos por usuários. probe configuration (19) : parâmetros operacionais de configuração do monitor RMON (configurações de interações com interfaces seriais, aspectos de download de informações, destinos de traps, etc). Existe uma implementação de um agente RMON2 livre (RAMON - http://www.nongnu.org/ramon/ ) mas ainda em estágios preliminares.
  • O ntop um monitor de tráfego que mostra a utlização de rede. Ele roda sobre UNIX/Linux assim como Windows. Através de um browser WEB se pode navegar nas informações de tráfego que ele disponibiliza e ter um snapshot da situação da rede. Sua configuração também é feita via browser. Ele roda normalmente na porta 3000. Apesar de não suportar o padrão RMON, ele se comporta como um monitor remoto com uma interface WEB, e que não consome muitos recursos de CPU e memória. Características: - Ordena a informação de tráfego segundo vários critérios por protocolo (vários) por origem/destino matriz de subredes - Apresenta estatísticas similares a RMON - Estatísticas de domínios Internet, AS (Autonomous Systems) e VLAN - Armazena as informações em disco (formato RRD) - Identifica usuários e OS passivamente - API's para acesso remoto em Perl / PHP / Python - Gráficos - Suporte a HTTPS
  • Monte uma solução de monitoramento de rede remoto com o utilitário ntop (http://www.ntop.org). Acesse o monitor através de um browser e interprete as informações disponibilizadas. Note que as configurações do ntop são todas feitas na sua interface WEB. Para acessa-lo use o browser, ponha o endereço da máquina, mesmo que seja a local (localhost). Use sua porta padrão: 3000.
  • Gerência de Redes - 4.RMON

    1. 1. Sumário <ul><li>Monitores remotos
    2. 2. RMON1 </li><ul><li>Objetivos
    3. 3. Configuração de RMON
    4. 4. Grupos
    5. 5. Eventos e Alarmes </li></ul><li>RMON2 </li><ul><li>Novos Grupos </li></ul></ul>
    6. 6. Monitores
    7. 7. Monitoramento com RMON
    8. 8. RMON - Objetivos <ul><li>Operação independente da estação gerenciadora
    9. 9. Monitoramento proativo (depende de recursos e da rede)
    10. 10. Detecção de problemas – monitoramento preemptivo
    11. 11. Dados de valor adicionado (especialização)
    12. 12. Suporte a vários gerentes </li></ul>
    13. 13. Configuração do RMON <ul><li>Dois tipos de dados da tabela de controle definem o acesso aos dados: </li><ul><li>OwnerString : é uma string que identifica o dono da entrada na tabela. É sugerido que este nome contenha informações específicas da estação gerente como seu endereço IP, o nome da estação, sua localização, ...
    14. 14. EntryStatus : é um valor inteiro que indica o estado atual da entrada na tabela. Operações de set irão criar a entrada. Inicializações serão feitas e logo depois a entrada terá status de valid . Após o trabalho ter acabado o status se torna invalid . Valores possíveis: </li></ul></ul><ul><ul><ul><li>Valid (1)
    15. 15. createRequest (2)
    16. 16. underCreation (3)
    17. 17. Invalid (4) </li></ul></ul></ul>
    18. 18. Exemplo de Manipulação de Tabelas RMON <ul><li>A coluna EntryStatus define o estado de uma determinada linha da tabela. Seus valores podem ser: </li><ul><li>createRequest
    19. 19. underCreation
    20. 20. Valid
    21. 21. invalid </li></ul><li>A coluna do tipo ownerString indica qual gerente fez o pedido de monitoramento </li></ul>
    22. 22. Grupos da MIB RMON <ul><li>Grupos de estatísticas de tráfego e erro </li><ul><li>statistics (1)
    23. 23. history (2)
    24. 24. host (4)
    25. 25. hostTopN (5) </li></ul><li>Matriz de tráfego entre sistemas </li><ul><li>matrix (6) </li></ul><li>Grupos de filtragem e captura de tráfego </li><ul><li>filter (7)
    26. 26. packet capture (8) </li></ul></ul>
    27. 27. Grupos da MIB RMON <ul><li>Grupos de alarmes e eventos </li><ul><li>alarm (3)
    28. 28. event (9) </li></ul></ul>
    29. 29. Eventos e Alarmes
    30. 30. RMON 2
    31. 31. Novos Grupos RMON 2 <ul><li>protocol directory (11)
    32. 32. protocol distribution (12)
    33. 33. address map (13)
    34. 34. network-layer host (14)
    35. 35. network-layer matrix (15)
    36. 36. application-layer host (16)
    37. 37. application-layer matrix (17)
    38. 38. user history (18)
    39. 39. probe configuration (19) </li></ul>
    40. 40. Grupos RMON 1 e 2
    41. 41. ntop
    42. 42. Atividade Prática <ul><li>Uso do ntop como opção de monitoramento remoto </li></ul>

    ×