Gerência de Redes - Parte 3

15/10/2009

1

RMON

Introdução

• Criado pelos mesmos grupos que desenvolveram oTCP/IP e o SNMP, o RMON é um padrão IETF degerenciamento de redes cuja sigla representa RemoteNetwork Monitoring MIB. Primeiramente, desenvolveu-se o padrão SNMP; somente depois pensou-se noRMON.

• Simple Network Management Protocol, ou SNMP, é umprotocolo de gerenciamento realmente simples: a únicainformação que se tem através de um alerta SNMP éque existe um problema em um ponto da rede. Osalertas do SNMP padrão notificam um problemasomente quando ele já atingiu uma condição extremasuficiente a ponto de comprometer a comunicação narede como um todo.

Introdução• Ao contrário do que se pode imaginar, o SNMP não é capaz de

definir o problema, nem sua gravidade; não fornece, tampouco,recursos para uma investigação das causas desse problema. Odiagnóstico do problema é uma tarefa do administrador da rede.Assim, o SNMP é simplesmente um alerta para uma condiçãoextrema da rede.

• O comitê do IETF decidiu que, para promover uma maior e melhorexpansão das tecnologias de rede, era necessário um padrão degerenciamento de redes mais sofisticado. As principaiscaracterísticas do novo padrão, o RMON, seriam: interoperabilidadeindependentemente de fabricante; capacidade de fornecerinformações precisas a respeito das causas de falha nofuncionamento normal da rede, assim como da severidade dessafalha; finalmente, o novo padrão deveria oferecer ferramentasadequadas para diagnóstico da rede. Além destas características, opadrão deveria oferecer um mecanismo proativo para alertar oadministrador dos eventuais problemas da rede, além de métodosautomáticos capazes de coletar dados a respeito dessesproblemas.

15/10/2009

2

Introdução

• Assim, o RMON tornou-se um padrão por volta de1990. O RMON II foi publicado recentemente paraestender as capacidades do RMON, cujo padrãoestá disponível nas RFCs 1757 e 1531 eapresentam padrões para redes Ethernet e TokenRing.

Uma visão geral

• As estatísticas indicam: enquanto apenas 30%dos custos de uma rede estão diretamenteassociados à aquisição de hardware, os 70%restantes dizem respeito à manutenção e aosuporte dessa rede.

• No momento da aquisição dos equipamentos deuma rede, o elemento determinante na escolhada melhor opção é, via de regra, o custo. Umavez iniciado o processo de expansão dessarede, os verdadeiros custos se manifestam.Neste momento, o departamento administrativoirá questionar: e o gerenciamento da rede?

Uma visão geral

• Alguns exemplos de recursos oferecidos por ferramentas de gerenciamento de redes são:– Dados de interoperação das redes; – Alertas de problemas; – Aviso antecipado de problemas; – Captura automática de dados; – Gráficos de utilização de hosts em tempo real; – Gráficos de eventos da rede.

15/10/2009

3

Os custos de uma rede

• Como indicado anteriormente, os custos relacionados à aquisição de equipamentos constituem em torno de 30% do custo total da rede; os 70% restantes estão associados aos custos de manutenção e suporte da rede. A fim de reduzir os custos da rede, podem ser destacadas algumas políticas:


• Proteção do Investimento – Evitar a aquisição de equipamentos com pequeno ou

nenhum grau de escalabilidade. Procurar adquirir produtos baseados numa mesma infra-estrutura e que permitam atualizações naturalmente, sem a necessidade de troca do equipamento.


• Aumento da Disponibilidade– Quanto mais tempo a rede estiver no ar, tanto maior

será sua capacidade de produção. A disponibilidadedepende de hardware tanto quanto de software. Doponto de vista de hardware, a rede deverá utilizardispositivos com sistemas de redundância em todosos níveis, desde suprimentos de energia, até HDs,processadores e up-links; do ponto de vista desoftware, deverá permitir o aviso automático decondições extremas, paging de pessoal e capturaautomática de dados em ocasião de erros. Enfim,quanto maior a capacidade da rede de manter-se noar, em condições normais de funcionamento, tantomaior será sua capacidade de produzir.

15/10/2009

4


• Manutenção Simplificada– A rede deverá permitir o rápido isolamento do problema. O

sistema de gerenciamento deverá identificar o problema,sua origem, e a abordagem mais indicada para resolvê-lo.

– O diagnóstico remoto deverá ser facilitado através daintegração das ferramentas de diagnóstico da rede emseus componentes. O sistema de gerenciamento deverápermitir a notificação antecipada dos problemas da redeantes mesmo que eles ocorram. Isto deverá ser realizadoatravés da configuração de graus de tolerância para osvários elementos da rede. Desta forma, cria-se um novoparadigma de gerenciamento, onde o suporte da rede érealizado de forma proativa, ao invés de reativa.


• Rápida Resolução de Problemas – Utilizar, sempre que possível, equipamentos de rede

inteligentes, capazes de coletar dados sobre o seu funcionamento e atualizarem suas configurações remotamente, via software. Dessa forma, o sistema de gerenciamento remoto poderá dispor dos dados registrados por um determinado equipamento para otimizar seu desempenho ao longo do tempo.


• Todos os itens acima justificam a adoção de uma solução de gerência de redes, particularmente, um sistema com características como as do RMON. Para entender, portanto, como os custos de operação de redes podem ser reduzidos através da utilização do RMON, é necessário compreender sua arquitetura. Somente com essa compreensão será possível avaliar quanto pode ser economizado em tempo e dinheiro na operação de uma rede corporativa.

15/10/2009

5

A Arquitetura RMON

• O RMON é um padrão IETF. Portanto, não é uma solução proprietária. Na realidade, um só fabricante dificilmente irá implementar a solução RMON completa. No cenário do gerenciamento RMON, os equipamentos de rede carregam MIBs RMON, a rede transporta os dados, um sistema de gerenciamento aceita alarmes e notifica usuários, e uma ferramenta de análise RMON interage com os grupos RMON e seus dados.

• Dentre os protocolos de gerenciamento, o RMON é, certamente, dos primeiros a permitir o gerenciamento proativo. Talvez seja esta a grande vantagem do mesmo em relação às outras arquiteturas de gerenciamento. O trabalho de gerenciamento é simplificado e a resolução dos problemas facilitada. Assim, aumenta a disponibilidade da rede e caem os custos de manutenção de forma significativa.

A Arquitetura RMON

• A contrapartida dessa enorme vantagem é que o RMON é um protocolo que atua apenas até a camada MAC. A capacidade de gerenciamento das camadas superiores é que permite a um protocolo o monitoramento ponto-a-ponto do tráfego corporativo (ou seja, além dos segmentos de rede), e do tráfego específico à camada de aplicação. Essa capacidade é implementada pelo RMON-II.

Exemplo: Gerenciando colisões numa Rede ETHERNET

• Considere uma rede Ethernet em que o nível de saturação de colisões aceitável é de 60%. Através de uma estação de gerenciamento, o adminsitrador da rede configura, no dispositivo de gerenciamento (monitor) da rede, o limite de saturação de colisões para 40%, por exemplo. Se, num dado momento, a rede exceder esse valor, uma armadilha (trap) RMON será disparada e enviada ao sistema de gerenciamento. O sistema de gerenciamento será responsável por exibir o mapa de alerta e os dados recebidos do monitor, além de notificar o administrador da rede do recebimento desse alerta (através de um pager, por exemplo). O alerta poderá, também, iniciar um processo de filtragem e captura de dados para análise posterior.

15/10/2009

6

Exemplo: Gerenciando colisões numa Rede ETHERNET

• Como foi ilustrado, a configuração de alarmes poderá garantir a operação da rede dentro dos níveis definidos pelo administrador. No momento em que um alarme é emitido, é possível identificar e corrigir as causas da condição de erro através da análise dos dados coletados pelo monitor antes e após o disparo do alarme. Esta forma de resolução de problemas, antes que estes atinjam níveis intoleráveis, é, certamente, o grande diferencial do RMON.

O padrão RMON: RFC 1757

• A RFC 1757 define o padrão RMON de gerenciamento. Segundo a RFC, o RMON não é uma pilha de protocolos, nem sequer um protocolo por si só. Na realidade, trata-se de uma extensão de MIB, Management Information Base, para ser utilizada com protocolos de gerenciamento de rede em internets baseadas em TCP/IP.

RMON

15/10/2009

7

RMON

• Características– Usado em LANs e WANs– Uso de Probes - monitores das redes que trabalham

em modo promíscuo verificando cada pacote da LAN– Monitores:

• Comunicam-se com uma estação central de gerenciamento de rede• Podem produzir estatísticas de erros da rede, colisões e outros• Podem armazenar partes dos pacotes ou pacotes inteiros para

análises posteriores

VISÃO GERAL

• Os dispositivos de gerenciamento remoto de redes, normalmente chamados de monitores ou sondas (probes), são instrumentos cuja existência é dirigida exclusivamente ao gerenciamento de redes. Geralmente, são independentes (standalone) e direcionam boa parte de seus recursos internos ao gerenciamento da rede a qual estão conectados.

• Uma organização pode empregar vários destes dispositivos para o gerenciamento de sua rede um por segmento. Adicionalmente, os monitores podem ser utilizados para que um provedor de serviços de gerenciamento de rede possa acessar uma rede cliente, normalmente separada geograficamente.

VISÃO GERAL

• Os objetos definidos na RFC 1757 são objetos de interface entre agentes RMON e aplicações de gerenciamento RMON. Ainda que a maioria desses objetos sirva a qualquer tipo de gerenciamento de redes, alguns são específicos às redes Ethernet. A estrutura desta MIB permite que outros objetos sejam desenvolvidos para outros tipos de redes. Há uma expectativa de que futuras versões da RFC 1757 ou outros documentos definam extensões para outros tipos de redes, como FDDI ou Token Ring.

15/10/2009

8

OBJETIVOS

• O padrão RMON foi desenvolvido no intuito de resolver questões que outros protocolos de gerenciamento não eram capazes. Com base nestas questões, a RFC 1757 define objetivos gerenciais que o padrão RMON deve observar:

OBJETIVOS

• Operação Off-line– Existem situações em que uma estação de gerenciamento não

estará em contato contínuo com seus dispositivos de gerenciamento remoto. Esta situação pode ocorrer como conseqüência de projeto, a fim de que se reduzam os custos de comunicação, ou por falha da rede, quando a comunicação entre a estação de gerenciamento e o monitor fica comprometida em sua qualidade.

– Por esta razão, a MIB RMON permite que um monitor seja configurado para realizar suas atividades de diagnóstico e coleta de dados estatísticos continuamente, mesmo quando a comunicação com a estação de gerenciamento seja impossível ou ineficiente. O monitor poderá então comunicar-se como a estação de gerenciamento quando uma condição excepcional ocorrer.

OBJETIVOS

• Operação Off-line– Assim, mesmo em circunstâncias em que a comunicação

entre monitor e estação de gerenciamento não é contínua, as informações de falha, desempenho e configuração podem ser acumuladas de forma continua, e transmitidas à estação de gerenciamento conveniente e eficientemente quando necessário.

15/10/2009

9

OBJETIVOS

• Monitoramento Proativo – Dados os recursos disponíveis no monitor, é

normalmente desejável e potencialmente útil que ele execute rotinas de diagnóstico de forma contínua e que acumule os dados de desempenho da rede. O monitor estará sempre disponível no início de uma falha; assim, ele poderá notificar a estação de gerenciamento da falha, assim como armazenar informações estatísticas a seu respeito. Esta informação estatística poderá ser analisada pela estação de gerenciamento numa tentativa de diagnosticar as causas do problema.

OBJETIVOS

• Detecção e Notificação de Problemas – O monitor pode ser configurado para reconhecer

condições, que, normalmente, são de erro e verificar pelas mesmas continuamente. No advento de uma destas condições, o evento pode ser registrado e as estações de gerenciamento notificadas de várias formas.

OBJETIVOS

• Valor Agregado aos Dados – Considerando o fato de que os dispositivos de

gerenciamento remoto representam recursos dedicados exclusivamente a funções de gerenciamento, e considerando também que os mesmos localizam-se diretamente nas porções monitoradas da rede, pode-se dizer que estes dispositivos permitem a agregação de valor aos dados coletados. Por exemplo, indicando quais os hosts que geram a maior quantidade de tráfego ou erros, um dispositivo pode oferecer (à estação de gerenciamento) informações preciosas para a resolução de toda uma classe de problemas.

15/10/2009

10

OBJETIVOS

• Gerenciamento Múltiplo – Uma organização pode ter mais de uma estação de

gerenciamento para as várias unidades da empresa, para funções distintas, ou como tentativa de proporcionar recuperação em caso de falha (crash recovery). Como tais ambientes são comuns na prática, um dispositivo de gerenciamento de rede remoto deverá ser capaz de lidar com múltiplas estações de gerenciamento concorrendo para a utilização de seus recursos.

CONVENÇÕES • Dois novos tipos de dados foram introduzidos como

convenções textuais nesta MIB. Essas convençõesfacilitam a compreensão da especificação e podemservir como base para comparação com outrasespecificações quando apropriado. A introdução dessasconvenções, convém esclarecer, não tem qualquerefeito sobre a sintaxe ou semântica dos objetosgerenciados. Seu uso é um artifício explicativo dométodo utilizado. Objetos definidos em função de umdesses métodos são codificados por meio das regrasque definem o tipo de dado primitivo. Assim, fica claroque a utilização destes campos dá-se por conveniênciaaos leitores e desenvolvedores, com o claro objetivo deproporcionar documentos MIB claros, concisos e nãoambíguos. Os dois novos tipos de dados são:OwnerString e EntryStatus.

MIB RMON

internet (1)

private(4)experimental (3)mgmt (2)directory (1) security(5) snmpV2(6)

mib-2 (1)

system (1) rmon (16)...

15/10/2009

11

MIB RMON

RMON (mib-2 16)

Statistics (1)

History (2)

Alarm (3)

Host (4)

HostTopN (5)

Matrix(6)

Filter (7)

Capture (8)

Event (9)

TokenRing (10)

A estrutura da MIB

• A extensão RMON da MIB consiste de conjunto de definições de objetos; cada um destes objetos é classificado segundo o grupo a que foi associado. Eis os grupos definidos pela MIB:

– Estatísticas Ethernet; – Histórico de Controle; – Histórico Ethernet; – Alarme; – Host; – HostTopN; – Matriz; – Filtro; – Captura de Pacotes; – Evento.

A estrutura da MIB

• Estes grupos são as unidades básicas de conformidade. Se um dispositivo de monitoramento remoto implementa um grupo, deverá implementar todos os objetos definidos naquele grupo.

• Todos os grupos nesta MIB são opcionais. A implementação da mesma exige a implementação do grupo de sistema e interfaces definidos na MIB-II. E esta, por sua vez, poderá exigir a implementação de grupos adicionais.

• Estes grupos são definidos para que exista um mecanismo adequado para a identificação dos objetos no ambiente de gerenciamento, e para que os sistemas de gerenciamento implementem adequadamente o conjunto de objetos necessários ao funcionamento do esquema.

15/10/2009

12

A estrutura da MIB

• Grupo de Estatísticas Ethernet – Este grupo contém as estatísticas levantadas por um

monitor para cada interface Ethernet do dispositivo gerenciado. Ele servirá de modelo para a implementação de grupos para outros tipos de rede, como Token Ring e FDDI. Consiste apenas do etherStatsTable.

A estrutura da MIB

• Grupo de Histórico de Controle – O controle da amostragem estatística dos dados de

vários tipos de rede é a função deste grupo. Ele consiste apenas do historyControlTable.

• Grupo de Histórico Ethernet – Este grupo registra amostras periódicas da rede

Ethernet e as armazena para análise posterior. Outros grupos deverão ser definidos para outras redes como Token Ring e FDDI. Consiste apenas do etherHistoryTable.

A estrutura da MIB

• Grupo de Alarme – O grupo de alarme realiza amostragens estatísticas das

variáveis do monitor e as compara aos limites previamente configurados. Se uma variável monitorada ultrapassa o limite estabelecido, um evento é gerado. Este grupo consiste do alarmTable e requer a implementação do grupo de evento.

• Grupo de Host– O grupo de host contém dados estatísticos a respeito de cada

um dos hosts descobertos na rede. O grupo descobre os hostsna rede através da captura de pacotes recebidos promiscuamente da rede. Com estes pacotes, monta uma lista dos endereços MAC da origem e destino. Este grupo consiste de três objetos: hostControlTable, hostTable e hostTimeTable.

15/10/2009

13

A estrutura da MIB

• Grupo de HostTopN– A função deste grupo é preparar relatórios descritivos

dos hosts que ocupam o topo da lista de uma determinada estatística. As estatísticas disponíveis são amostras de uma das estatísticas padrão num intervalo de tempo especificado pela estação de gerenciamento. Essas estatísticas são, na realidade, taxas. A estação de gerenciamento também deverá determinar a quantidade de hosts a ser analisada. Os objetos deste grupo são: hostTopNControlTable e hostTopNTable. Este grupo requer a implementação do grupo de host.

A estrutura da MIB

• Grupo de Matriz– O grupo de matriz armazena dados das conversas

entre conjuntos de dois endereços. Quando um dispositivo detecta uma nova conversa, ele cria uma nova entrada em suas tabelas. O grupo consiste de: matrixControlTable, matrixSDTable e matrixDSTable.

• Grupo de Filtro – Este grupo identifica pacotes que satisfazem critérios

estabelecidos através de uma equação de filtragem. Os pacotes que satisfazem determinados critérios formam um fluxo de dados que pode gerar eventos ou ser capturado. O grupo consiste de dois objetos: filterTable e channelTable.

A estrutura da MIB

• Grupo de Captura de Pacotes– Permitir que pacotes sejam capturados após

passarem por determinado canal ou filtro é a função deste grupo. Ele consiste de dois objetos: bufferControlTable e captureBufferTable. Este grupo requer a implementação do grupo de filtro.

• Grupo de Evento– O grupo de evento controla a geração e notificação

de eventos de um determinado dispositivo. Consiste do eventTable e do logTable.

15/10/2009

14

Controle dos dispositivos RMON

• Devido a natureza complexa das funções dos dispositivos de gerenciamento, normalmente, faz-se necessária uma configuração prévia. Em muitos casos, as funções necessitam de parâmetros para que uma coleta de dados seja realizada adequadamente. A operação só pode ser realizada após estes parâmetros estarem devidamente configurados.

• Vários grupos funcionais definidos nesta MIB têm uma ou mais tabelas adequadas à configuração de parâmetros de controle, e uma ou mais tabelas de dados para o armazenamento dos resultados de uma determinada operação.


• As tabelas de controle são, por natureza, do tipo leitura e escrita; as tabelas de dados, por sua vez, são tipicamente apenas de leitura. Devido ao fato de que os parâmetros nas tabelas de controle descrevem os dados nas tabelas de dados, muitos deles somente podem ser alterados quando forem inválidos. Isto significa que, para alterar um determinado parâmetro de controle é necessário invalidá-lo. Uma vez inválido, o parâmetro é removido da tabela de controle, juntamente com todos os dados associados nas tabelas de dados. Somente então, cria-se uma nova entrada na tabela de controle para o parâmetro em questão. Observe que a exclusão de uma entrada na tabela de controle também serve como um mecanismo para a recuperação dos recursos associados àqueles dados.


• Alguns objetos nesta MIB fornecem mecanismos para a execução de uma ação no dispositivo remoto de gerenciamento. A ação pode ser realizada em conseqüência à alteração do estado do objeto. Para os objetos definidos nesta MIB, uma solicitação para armazenar um valor no objeto igual ao valor atualmente armazenado será ignorada pelo mesmo.

• Para permitir o controle por múltiplos gerenciadores, os recursos devem ser compartilhados por vários deles. tratam-se, tipicamente, da memória e dos recursos computacionais que uma função necessita.

15/10/2009

15

Compartilhamento de recursos entre múltiplos gerenciadores

• Quando mais de uma estação desejam utilizar funções que competem por uma quantidade finita de recursos no dispositivo de gerenciamento, um método para facilitar o compartilhamento de seus recursos é necessário. Conflitos em potencial incluem:– Duas estações necessitam utilizar simultaneamente recursos

que, somados, excedem a capacidade do dispositivo. – Um estação de gerenciamento necessita utilizar uma quantidade

significativa de recursos por um período prolongado. – Uma estação de gerenciamento aloca recursos e falha,

deixando os recursos alocados, impedindo que outras estações possam utilizá-los.


• Existe um mecanismo, definido nesta MIB, disponível para cada função inicializada a partir de uma estação de gerenciamento, que evita esse tipo de conflito e ajuda a resolvê-los quando eles ocorrem. Cada função tem um rótulo identificando o iniciador (dono) da função. Este identificador é preenchido pelo iniciador e permite que:– Uma estação reconhece os recursos alocados para si e que não são

mais necessários. – Um operador pode identificar o dono de um determinado recurso e

negociar para que seja liberado. – Um operador pode, unilateralmente, resolver liberar recursos alocados

por um outro operador. – No momento da inicialização, uma estação de gerenciamento pode

reconhecer recursos previamente reservados. Com esta informação, a estação poderá liberar recursos não mais necessários.


• Estações de gerenciamento devem suportar qualquer formato do OwnerString determinado pela política local da empresa. Como sugestão, o identificador deverá conter um ou mais de: endereço IP, nome da estação de gerenciamento, nome, telefone ou localização do operador da estação de gerenciamento. Esta informação permitirá aos usuários o compartilhamento mais eficiente dos recursos.

• Normalmente, existe certa funcionalidade padrão que o dispositivo ou administrador deseja configurar. Os recursos alocados para estas funcionalidades serão de longa duração e estarão associados ao próprio dispositivo ou administrador. Neste caso, ou o dispositivo ou o administrador deverá definir o OwnerString com um stringiniciando com monitor . Modificações indiscriminadas dessas configurações são desencorajadas. Com efeito, uma estação de gerenciamento somente deverá alterar estes objetos com autorização do administrador do dispositivo.

15/10/2009

16


• Os recursos num monitor são normalmente escassos e alocados quando uma linha é acrescentada a uma tabela de controle por uma aplicação. Como várias aplicações podem utilizar um determinado monitor simultaneamente, alocação indiscriminada dos recursos de um monitor poderá causar falta de recursos no mesmo.

• Quando uma estação de gerenciamento deseja utilizar uma função de um monitor, encoraja-se que, primeiramente, ela investigue a tabela de controle daquela função em busca de uma instância com parâmetros semelhantes para que possa compartilhar. Esta situação é particularmente indicada para as funções pertencentes ao próprio monitor, que tendem a sofrer poucas alterações. Se uma estação de gerenciamento decide compartilhar uma instância pertencente a uma segunda estação de gerenciamento, deverá levar em conta o fato de que a estação dona da instância poderá modificá-la ou exclui-la inadvertidamente, a qualquer momento.


• Deve-se destacar o fato de que uma aplicação poderá confiar nas instâncias pertencentes ao monitor pois estas deverão ser alteradas raramente. Instâncias pertencentes à propria aplicação de gerenciamento são menos persistentes que as anteriores e menos confiáveis. Instâncias pertencentes a outras aplicações são as menos confiáveis, pois podem ser alteradas a qualquer momento pela aplicação, sem advertência prévia.

Inclusão de linhas entre múltiplos gerenciadores

• A inclusão de linhas nas tabelas definidas por esta MIB deverá ser realizada pelo método descrito na RFC 1212. Nesta MIB, linhas são incluídas nas tabelas para configurar uma determinada função. Esta configuração normalmente envolve a definição de parâmetros que controlam a operação da função.

• O agente deverá checar esses parâmetros para garantir que são apropriados uma vez observadas as restrições definidas e outras específicas à implementação, como a falta de recursos. Na implementação desta MIB, pode-se definir dois momentos para notificar a estação de gerenciamento de que os parâmetros são inválidos:– Quando a estação de gerenciamento altera cada parâmetro. – Quando a estação define o EntryStatus do objeto como válido.

15/10/2009

17


• Se o segundo for o escolhido, não ficará claro à estação de gerenciamento qual dos parâmetros de configuração estão inválidos, causando a emissão do erro badValue. Assim, sempre que possível, a implementação da MIB deverá observar a primeira opção em detrimento da segunda, por fornecer maiores detalhes a respeito do parâmetro inválido.

• Um problema pode surgir quando várias estações de gerenciamento tentarem alterar um parâmetro de configuração simultaneamente através do SNMP.


• Quando o processo envolve a criação de uma entrada numa tabela de controle, os gerenciadores podem colidir, tentando criar a mesma entrada. Como proteção contra esta situação, cada entrada na tabela de controle tem um objeto para o controle de estado da entrada com uma semântica especial que auxilia na resolução de conflitos entre gerenciadores. Assim, o mecanismo de criação de uma entrada na tabela sempre irá tentar criar o objeto de controle de estado. Se ele já existir, um erro é retornado e a tabela não é alterada. Pois, quando vários gerenciadores tentam criar a mesma entrada conceitual na tabela, apenas o primeiro será bem sucedido; os demais receberão um erro.


• Quando um gerenciador deseja criar uma nova entrada numa tabela de controle, deverá escolher um índice para aquela entrada. Esta escolha poderá ser realizada de várias formas, de preferência visando a minimização da possibilidade de repetição de índices utilizados por outros gerenciadores. Se o índice já existe, o mecanismo descrito anteriormente cuidará para que as colisões sejam evitadas.

• Como algumas tabelas definidas nesta MIB referenciam outras tabelas da mesma, ao incluir ou excluir entradas numa determinada tabela, é permitida a existência de referências pendentes ou não resolvidas. Não está definida qualquer ordem para inclusão ou exclusão de entradas nessas tabelas.

15/10/2009

18

Conclusão

• O RMON é uma arquitetura definida pela RFC 1757 para o gerenciamento proativo de redes. Funciona sobre a pilha TCP/IP, integrado ao SNMP. Na realidade, o padrão RMON é uma MIB definida para permitir a implementação de um esquema proativo de gerenciamento, baseado na definição de limites de tolerância para a rede.

• Outras RFCs estendem as funções RMON definindo padrões de gerenciamento para elementos não cobertos pela RFC 1757. Na sua maioria, e assim como o próprio padrão RMON, definem extensões de MIB para realizar tarefas específicas.

Conclusão

• Como ilustração do grande apelo comercial do RMON, estimativas indicavam vendas de equipamentos RMON na ordem de 1 bilhão de dólares para o ano de 1997. Este é um indicativo bastante forte da força deste padrão e leva a crer que os esforços no sentido de estender as funcionalidades do mesmo serão de grande importância na evolução dos sistemas de gerenciamento de rede.

• O RMON-II, sucessor natural do RMON, realiza um mapeamento de todos os grupos RMON nos mais populares protocolos de rede como IP, IPX, DECnet, AppleTalk, Vines e protocolos OSI em geral. Oferece, além disso, a capacidade de gerenciamento em qualquer um dos 7 níveis da camada OSI, além de permitir a administração de aplicativos distribuídos como Lotus Notes e Sybase SQL.

Conclusão

• Espera-se, da evolução do RMON, o suporte avançado à arquitetura cliente/servidor, permitindo, por exemplo, a utilização de monitores como proxys de gerenciamento SNMP. Nessa estrutura, o dispositivo atuando como proxy seria responsável pelo gerenciamento dos equipamentos localizados na sua rede. Haveria uma redução no tráfego SNMP das aplicações de gerenciamento, aumentando a disponibilidade da rede como um todo. Outra característica desejável seria o suporte a topologias avançadas, com backbones de alta velocidade e redes virtuais (VLANs).

15/10/2009

19

Conclusão

• A arquitetura RMON realizou uma quebra no paradigma de gerenciamento de redes. Enquanto arquiteturas concorrentes atuavam de forma reativa no surgimento de problemas na rede, o RMON define um modelo proativo de atuação, permitindo que a rede permaneça mais tempo no ar, garantindo um melhor desempenho como um todo e minimizando os tempos e custos de manutenção em geral. O RMON, apesar de contribuir decisivamente para a evolução do paradigma de gerenciamento, não é a solução definitiva.

• Com a constante evolução das tecnologias de rede, novas soluções de gerenciamento surgirão e substituirão os padrões existentes. O que fica evidente, entretanto, é que RMON é um marco para a gerência de redes: os novos protocolos certamente irão buscar no RMON a inspiração para a implementação de algumas de suas características.

Referências bibliográficas

• Waldbusser, S. "RFC 1757 - Remote Network Monitoring Management Information Base."

• NetScout System, Inc. "RMON, RMON2, and Beyond."

• STALLINGS, William. Snmp, Snmpv2, Snmpv3 and Rmon 1 and 2. Addison-Wesley, 3rd edition, 1999.

RMON2

15/10/2009

20

RMON2

• Mesmo sendo RMON um passo significante no monitoramento remoto de LANs e WANs, o uso da versão 1 revelou algumas desvantagens - fraquezas que foram consertadas em RMON2.

• Listamos, abaixo, alguns exemplos:

– Monitoramento de tráfego ampliado : Análises tradicionais baseadas em RMON oferecem ao gerente de rede um poderoso sistema de correção de erros e uma capacidade de monitorar um segmento LAN no nível MAC, mas não conseguem enxergar o tráfego quando este ultrapassa as barreiras do roteamento. Com RMON2, gerentes de rede serão capazes de ver o tráfego desde a camada 3 até a 7 do modelo OSI (Open Systems Interconnect), Isto significa que gerentes serão capazes de ver como flui o tráfego de rede em cada um dos 7 níveis do modelo OSI - uma capacidade que terá um impacto significante no controle e resoluçao de erros em ambientes cliente/servidor. Figura 1 nos mostra o nível de visibilidade que RMON e RMON2 provêem dentro de um segmento LAN ou de uma rede em cada uma das camadas do OSI.

Limitações supridas pelo RMON2

– Maior confiança no fornecedor : atualmente, para que algum produto seja "baseado em RMON" ele necessita apenas implementar um dos grupos RMON. Com isso, as capacidades RMON podem variar drasticamente de um fornecedor para outro, dependendo do número de grupos RMON MIB que o produto suporta. RMON2 requerirá que produtos implementem-na mais amplamente para que possa ser considerado "baseado em RMON2".

– Correlação com a Camada Física : monitores baseados em RMON coletam estatísticas no nível 2, a camada Data Link do modelo OSI. Esta camada se concentra primordialmente com a formação dos pacotes: endereçamento e entrega. Embora esse tipo de informação seja muito útil para a resolução de problemas, não se tem nenhuma visão do nível físico. RMON2 tem a habilidade de relacionar informação de porta ou cabeamento na estação final, aumentando incrivelmente a visibilidade da rede.

Limitações supridas pelo RMON2

– História Completa : com RMON2, qualquer objeto MIB pode ser localmente rastreado e gravado em um log histórico.

• Os benefícios do RMON estendem a monitoração aos maisaltos níveis das camadas do protocolo. Enquanto RMONsomente provê estatísticas de tráfego na camada MAC doprotocolo, RMON2 provê um discernimento das estatísticasde tráfego bem maior, especificando o protocolo e asaplicações que geraram aquele tráfego. Este conhecimento éde vital importância nos dias de hoje. Estender a visão dosegmento RMON para uma mais ampla fornecida peloRMON2 faz com que gerentes de rede tenham maisinformações e maior conhecimento para gerenciar, corrigir oserros e monitorar redes cada vez mais complexas. Comoresultado, RMON2 permitirá a análise cliente/servidor de umanova classe inteira de aplicações; monitoramento e projetointer-rede; e registro nas camadas de rede e aplicação.

15/10/2009

21

Estrutura da RMON2-MIB

• Os objetos definidos em RMON2-MIB são arranjados nos seguintes grupos: – protocol directory (protocolDir) – protocol distribution (protocolDist) – address mapping (addressMap) – network layer host (nlHost) – network layer matrix (nlMatrix) – application layer host (alHost) – application layer matrix (alMatrix) – user history (usrHistory) – probe configuration (probeConfig)

Objetos RMON e RMON2

Estrutura da RMON2-MIB

• Os 9 grupos apresentados formam a base de toda RMON2-MIB. Se um dispositivo de gerenciamento remoto implementaum grupo, então ele deve implementar todos os objetosnaquele grupo. Por exemplo, um agente que implementa ogrupo network layer matrix deve implementar onlMatrixSDTable e o nlMatrixDSTable.

• Implementações desta MIB devem também implementar osgrupos system e interfaces da MIB-II. Pode-se, sem prejuízonenhum, implementar outros grupos que sejam necessários.

• Os grupos de RMON2-MIB são definidos para prover umsignificado no assinalamento dos identificadores dos objetose para fornecer um método para que os agentes saibamquais objetos eles devem implementar.

15/10/2009

22

Os 9 Grupos da RMON2-MIB

• Grupo Protocol Directory (protocolDir) : Lista os protocolos que o probetem a capacidade de monitorar e permite a adição, remoção e configuração das entradas nesta lista.

• Grupo Protocol Distribution (protocolDist) : Coleta as quantidades relativas de octetos e pacotes para os diferentes protocolos detectados no segmento da rede.

• Grupo Address Map (addressMap) : Lista endereços MAC para endereços de rede descobertos pelo probe e em qual interface eles estavam na última utilização.

• Grupo Network Layer Matrix (nlMatrix) : Calcula a quantidade de tráfego enviado entre cada par de endereço de rede descoberto pelo probe. Embora hlMatrixControlTable também tenha objetos que controlam alMatrixTable, a implementação da alMatrixTable não é necessária para a implementação total desse grupo.

• Grupo Application Layer Host (alHost) : Calcula a quantidade de tráfego, por protocolo, enviado de e para cada endereço de rede descoberto pelo probe. Implementações desse grupo requerem a implementação do grupo Network Layer Host.

Os 9 Grupos da RMON2-MIB• Grupo Application Layer Matrix (alMatrix) : Calcula a quantidade de

tráfego, por protocolo, enviado de cada par de endereço de rededescoberto pelo probe. Implementações desse grupo requerem que ogrupo Network Layer Matrix também seja implementado.

• Grupo User History Collection (usrHistory) : O grupo usrHistory combinamecanismos usados nos grupos alarm e history para prover um mecanismode história especificado pelo usuário utilizando três tabelas adicionais: duasde controle e uma de dados. Esta função tem sido feita tradionalmente poraplicações NMS, via polling periódico. O grupo userHistory permite queessa tarefa seja descarregada em um probe RMON. Os dados sãocoletados da mesma maneira que qualquer tabela de dados history (porexemplo etherHistoryTable) exceto que o usuário especifica as instânciasMIB a serem coletadas. Os objetos são coletados em bucket-groups, com ointuito de que todas as instâncias MIB no mesmo bucket-group sejamcoletadas da forma mais atômica possível pelo probe RMON.

• Grupo Probe Configuration (probeConfig) : Este grupo permite controlara configuração de vários parâmetros operacionais do probe. As entradas deusrHistoryObject associadas com outra usrHistoryControlTable nãoprecisam estar ativas antes da entrada de controle estar ativada.

Conclusão• Coletar Estatística de Níveis mais Altos : estatísticas na camada de rede

e aplicação usando as tabelas traffic, host, matrix e matrix Top N permitirão aos gerentes ver quais clientes estão falando com quais servidores, ampliando a visão da rede.

• Tradução de Endereços : amarrar endereços da camada MAC com endereços da camada de rede torna mais fácil a leitura de todos endereços. A habilidade de detectar endereços IP duplicados permitirá que os gerentes de rede solucionem problemas que devastam roteadores e LANs virtuais. Tradução de endereços e suporte a plataforma de gerência SNMP melhorará o mapeamento da topologia e aumentará a eficiência da gerência.

• História Definida pelo Usuário : o padrão RMON original permite coletar dados históricos somente em um conjunto predefinido de estatísticas. RMON2 permitirá aos gerentes de rede configurar os dados históricos de qualquer contador no sistema.

• Filtragem Melhorada : RMON2 permitirá aos usuários configurar os filtros de forma mais flexível e eficiente.

• Configuração de Probes : o padrão original RMON não lida com o problema criado na configuração e controle de diferentes probes de fornecedores diversos. O novo padrão RMON2 permitirá a configuração de diferentes marcas de probes baseados em diferentes aplicações RMON.

Gerência de Redes - Parte 3

Documents

Transcript of Gerência de Redes - Parte 3