Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
RMON
Introduo
Criado pelos mesmos grupos que desenvolveram o
TCP/IP e o SNMP, o RMON um padro IETF de
gerenciamento de redes cuja sigla representa Remote
Network Monitoring MIB. Primeiramente, desenvolveuse o padro SNMP; somente depois pensou-se no
RMON.
Simple Network Management Protocol, ou SNMP, um
protocolo de gerenciamento realmente simples: a nica
informao que se tem atravs de um alerta SNMP
que existe um problema em um ponto da rede. Os
alertas do SNMP padro notificam um problema
somente quando ele j atingiu uma condio extrema
suficiente a ponto de comprometer a comunicao na
rede como um todo.
Introduo
15/10/2009
Introduo
Assim, o RMON tornou-se um padro por volta de
1990. O RMON II foi publicado recentemente para
estender as capacidades do RMON, cujo padro
est disponvel nas RFCs 1757 e 1531 e
apresentam padres para redes Ethernet e Token
Ring.
15/10/2009
15/10/2009
15/10/2009
A Arquitetura RMON
O RMON um padro IETF. Portanto, no uma soluo
proprietria. Na realidade, um s fabricante dificilmente ir
implementar a soluo RMON completa. No cenrio do
gerenciamento RMON, os equipamentos de rede carregam
MIBs RMON, a rede transporta os dados, um sistema de
gerenciamento aceita alarmes e notifica usurios, e uma
ferramenta de anlise 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 relao s outras arquiteturas de gerenciamento. O
trabalho de gerenciamento simplificado e a resoluo dos
problemas facilitada. Assim, aumenta a disponibilidade da
rede e caem os custos de manuteno 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 trfego corporativo
(ou seja, alm dos segmentos de rede), e do trfego
especfico camada de aplicao. Essa capacidade
implementada pelo RMON-II.
15/10/2009
RMON
15/10/2009
RMON
Caractersticas
Usado em LANs e WANs
Uso de Probes - monitores das redes que trabalham
em modo promscuo verificando cada pacote da LAN
Monitores:
Comunicam-se com uma estao central de gerenciamento de rede
Podem produzir estatsticas de erros da rede, colises e outros
Podem armazenar partes dos pacotes ou pacotes inteiros para
anlises posteriores
VISO GERAL
Os dispositivos de gerenciamento remoto de redes,
normalmente chamados de monitores ou sondas
(probes), so instrumentos cuja existncia dirigida
exclusivamente ao gerenciamento de redes.
Geralmente, so independentes (standalone) e
direcionam boa parte de seus recursos internos ao
gerenciamento da rede a qual esto conectados.
Uma organizao pode empregar vrios destes
dispositivos para o gerenciamento de sua rede um por
segmento. Adicionalmente, os monitores podem ser
utilizados para que um provedor de servios de
gerenciamento de rede possa acessar uma rede cliente,
normalmente separada geograficamente.
VISO GERAL
Os objetos definidos na RFC 1757 so objetos
de interface entre agentes RMON e aplicaes
de gerenciamento RMON. Ainda que a maioria
desses objetos sirva a qualquer tipo de
gerenciamento de redes, alguns so especficos
s redes Ethernet. A estrutura desta MIB
permite que outros objetos sejam desenvolvidos
para outros tipos de redes. H uma expectativa
de que futuras verses da RFC 1757 ou outros
documentos definam extenses para outros
tipos de redes, como FDDI ou Token Ring.
15/10/2009
OBJETIVOS
O padro RMON foi desenvolvido no intuito de
resolver questes que outros protocolos de
gerenciamento no eram capazes. Com base
nestas questes, a RFC 1757 define objetivos
gerenciais que o padro RMON deve observar:
OBJETIVOS
Operao Off-line
Existem situaes em que uma estao de gerenciamento no
estar em contato contnuo com seus dispositivos de
gerenciamento remoto. Esta situao pode ocorrer como
conseqncia de projeto, a fim de que se reduzam os custos de
comunicao, ou por falha da rede, quando a comunicao
entre a estao de gerenciamento e o monitor fica
comprometida em sua qualidade.
Por esta razo, a MIB RMON permite que um monitor seja
configurado para realizar suas atividades de diagnstico e coleta
de dados estatsticos continuamente, mesmo quando a
comunicao com a estao de gerenciamento seja impossvel
ou ineficiente. O monitor poder ento comunicar-se como a
estao de gerenciamento quando uma condio excepcional
ocorrer.
OBJETIVOS
Operao Off-line
Assim, mesmo em circunstncias em que a comunicao
entre monitor e estao de gerenciamento no contnua,
as informaes de falha, desempenho e configurao
podem ser acumuladas de forma continua, e transmitidas
estao de gerenciamento conveniente e eficientemente
quando necessrio.
15/10/2009
OBJETIVOS
Monitoramento Proativo
Dados os recursos disponveis no monitor,
normalmente desejvel e potencialmente til que ele
execute rotinas de diagnstico de forma contnua e
que acumule os dados de desempenho da rede. O
monitor estar sempre disponvel no incio de uma
falha; assim, ele poder notificar a estao de
gerenciamento da falha, assim como armazenar
informaes estatsticas a seu respeito. Esta
informao estatstica poder ser analisada pela
estao de gerenciamento numa tentativa de
diagnosticar as causas do problema.
OBJETIVOS
Deteco e Notificao de Problemas
O monitor pode ser configurado para reconhecer
condies, que, normalmente, so de erro e verificar pelas
mesmas continuamente. No advento de uma destas
condies, o evento pode ser registrado e as estaes de
gerenciamento notificadas de vrias formas.
OBJETIVOS
Valor Agregado aos Dados
Considerando o fato de que os dispositivos de
gerenciamento remoto representam recursos
dedicados exclusivamente a funes de
gerenciamento, e considerando tambm que os
mesmos localizam-se diretamente nas pores
monitoradas da rede, pode-se dizer que estes
dispositivos permitem a agregao de valor aos
dados coletados. Por exemplo, indicando quais os
hosts que geram a maior quantidade de trfego ou
erros, um dispositivo pode oferecer ( estao de
gerenciamento) informaes preciosas para a
resoluo de toda uma classe de problemas.
15/10/2009
OBJETIVOS
Gerenciamento Mltiplo
Uma organizao pode ter mais de uma estao de
gerenciamento para as vrias unidades da empresa,
para funes distintas, ou como tentativa de
proporcionar recuperao em caso de falha (crash
recovery). Como tais ambientes so comuns na
prtica, um dispositivo de gerenciamento de rede
remoto dever ser capaz de lidar com mltiplas
estaes de gerenciamento concorrendo para a
utilizao de seus recursos.
CONVENES
Dois novos tipos de dados foram introduzidos como
convenes textuais nesta MIB. Essas convenes
facilitam a compreenso da especificao e podem
servir como base para comparao com outras
especificaes quando apropriado. A introduo dessas
convenes, convm esclarecer, no tem qualquer
efeito sobre a sintaxe ou semntica dos objetos
gerenciados. Seu uso um artifcio explicativo do
mtodo utilizado. Objetos definidos em funo de um
desses mtodos so codificados por meio das regras
que definem o tipo de dado primitivo. Assim, fica claro
que a utilizao destes campos d-se por convenincia
aos leitores e desenvolvedores, com o claro objetivo de
proporcionar documentos MIB claros, concisos e no
ambguos. Os dois novos tipos de dados so:
OwnerString e EntryStatus.
MIB RMON
internet (1)
mib-2 (1)
system (1)
10
15/10/2009
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
Estatsticas Ethernet;
Histrico de Controle;
Histrico Ethernet;
Alarme;
Host;
HostTopN;
Matriz;
Filtro;
Captura de Pacotes;
Evento.
A estrutura da MIB
Estes grupos so as unidades bsicas de conformidade.
Se um dispositivo de monitoramento remoto implementa
um grupo, dever implementar todos os objetos
definidos naquele grupo.
Todos os grupos nesta MIB so opcionais. A
implementao da mesma exige a implementao do
grupo de sistema e interfaces definidos na MIB-II. E
esta, por sua vez, poder exigir a implementao de
grupos adicionais.
Estes grupos so definidos para que exista um
mecanismo adequado para a identificao dos objetos
no ambiente de gerenciamento, e para que os sistemas
de gerenciamento implementem adequadamente o
conjunto de objetos necessrios ao funcionamento do
esquema.
11
15/10/2009
A estrutura da MIB
Grupo de Estatsticas Ethernet
Este grupo contm as estatsticas levantadas por um
monitor para cada interface Ethernet do dispositivo
gerenciado. Ele servir de modelo para a implementao
de grupos para outros tipos de rede, como Token Ring e
FDDI. Consiste apenas do etherStatsTable.
A estrutura da MIB
Grupo de Histrico de Controle
O controle da amostragem estatstica dos dados de
vrios tipos de rede a funo deste grupo. Ele
consiste apenas do historyControlTable.
A estrutura da MIB
Grupo de Alarme
O grupo de alarme realiza amostragens estatsticas das
variveis do monitor e as compara aos limites previamente
configurados. Se uma varivel monitorada ultrapassa o limite
estabelecido, um evento gerado. Este grupo consiste do
alarmTable e requer a implementao do grupo de evento.
Grupo de Host
O grupo de host contm dados estatsticos a respeito de cada
um dos hosts descobertos na rede. O grupo descobre os hosts
na rede atravs da captura de pacotes recebidos
promiscuamente da rede. Com estes pacotes, monta uma lista
dos endereos MAC da origem e destino. Este grupo consiste
de trs objetos: hostControlTable, hostTable e hostTimeTable.
12
15/10/2009
A estrutura da MIB
Grupo de HostTopN
A funo deste grupo preparar relatrios descritivos
dos hosts que ocupam o topo da lista de uma
determinada estatstica. As estatsticas disponveis
so amostras de uma das estatsticas padro num
intervalo de tempo especificado pela estao de
gerenciamento. Essas estatsticas so, na realidade,
taxas. A estao de gerenciamento tambm dever
determinar a quantidade de hosts a ser analisada. Os
objetos deste grupo so: hostTopNControlTable e
hostTopNTable. Este grupo requer a implementao
do grupo de host.
A estrutura da MIB
Grupo de Matriz
O grupo de matriz armazena dados das conversas
entre conjuntos de dois endereos. 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 critrios
estabelecidos atravs de uma equao de filtragem.
Os pacotes que satisfazem determinados critrios
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 aps
passarem por determinado canal ou filtro a funo
deste grupo. Ele consiste de dois objetos:
bufferControlTable e captureBufferTable. Este grupo
requer a implementao do grupo de filtro.
Grupo de Evento
O grupo de evento controla a gerao e notificao
de eventos de um determinado dispositivo. Consiste
do eventTable e do logTable.
13
15/10/2009
14
15/10/2009
Compartilhamento de recursos
entre mltiplos gerenciadores
Quando mais de uma estao desejam utilizar funes
que competem por uma quantidade finita de recursos no
dispositivo de gerenciamento, um mtodo para facilitar o
compartilhamento de seus recursos necessrio.
Conflitos em potencial incluem:
Duas estaes necessitam utilizar simultaneamente recursos
que, somados, excedem a capacidade do dispositivo.
Um estao de gerenciamento necessita utilizar uma quantidade
significativa de recursos por um perodo prolongado.
Uma estao de gerenciamento aloca recursos e falha,
deixando os recursos alocados, impedindo que outras estaes
possam utiliz-los.
Compartilhamento de recursos
entre mltiplos gerenciadores
Compartilhamento de recursos
entre mltiplos gerenciadores
15
15/10/2009
Compartilhamento de recursos
entre mltiplos gerenciadores
Compartilhamento de recursos
entre mltiplos gerenciadores
Deve-se destacar o fato de que uma aplicao poder
confiar nas instncias pertencentes ao monitor pois
estas devero ser alteradas raramente. Instncias
pertencentes propria aplicao de gerenciamento so
menos persistentes que as anteriores e menos
confiveis. Instncias pertencentes a outras aplicaes
so as menos confiveis, pois podem ser alteradas a
qualquer momento pela aplicao, sem advertncia
prvia.
16
15/10/2009
17
15/10/2009
Concluso
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
padro RMON uma MIB definida para permitir a
implementao de um esquema proativo de
gerenciamento, baseado na definio de limites de
tolerncia para a rede.
Outras RFCs estendem as funes RMON definindo
padres de gerenciamento para elementos no cobertos
pela RFC 1757. Na sua maioria, e assim como o prprio
padro RMON, definem extenses de MIB para realizar
tarefas especficas.
Concluso
Como ilustrao do grande apelo comercial do RMON,
estimativas indicavam vendas de equipamentos RMON na
ordem de 1 bilho de dlares para o ano de 1997. Este um
indicativo bastante forte da fora deste padro e leva a crer
que os esforos no sentido de estender as funcionalidades do
mesmo sero de grande importncia na evoluo 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, alm disso, a capacidade
de gerenciamento em qualquer um dos 7 nveis da camada
OSI, alm de permitir a administrao de aplicativos
distribudos como Lotus Notes e Sybase SQL.
Concluso
Espera-se, da evoluo do RMON, o suporte avanado
arquitetura cliente/servidor, permitindo, por exemplo, a
utilizao de monitores como proxys de gerenciamento
SNMP. Nessa estrutura, o dispositivo atuando como
proxy seria responsvel pelo gerenciamento dos
equipamentos localizados na sua rede. Haveria uma
reduo no trfego SNMP das aplicaes de
gerenciamento, aumentando a disponibilidade da rede
como um todo. Outra caracterstica desejvel seria o
suporte a topologias avanadas, com backbones de alta
velocidade e redes virtuais (VLANs).
18
15/10/2009
Concluso
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 atuao,
permitindo que a rede permanea mais tempo no ar,
garantindo um melhor desempenho como um todo e
minimizando os tempos e custos de manuteno em geral. O
RMON, apesar de contribuir decisivamente para a evoluo
do paradigma de gerenciamento, no a soluo definitiva.
Com a constante evoluo das tecnologias de rede, novas
solues de gerenciamento surgiro e substituiro os
padres existentes. O que fica evidente, entretanto, que
RMON um marco para a gerncia de redes: os novos
protocolos certamente iro buscar no RMON a inspirao
para a implementao de algumas de suas caractersticas.
Referncias bibliogrficas
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
19
15/10/2009
RMON2
Mesmo sendo RMON um passo significante no
monitoramento remoto de LANs e WANs, o uso da verso 1
revelou algumas desvantagens - fraquezas que foram
consertadas em RMON2.
Listamos, abaixo, alguns exemplos:
Monitoramento de trfego ampliado: Anlises tradicionais baseadas
em RMON oferecem ao gerente de rede um poderoso sistema de
correo de erros e uma capacidade de monitorar um segmento LAN
no nvel MAC, mas no conseguem enxergar o trfego quando este
ultrapassa as barreiras do roteamento. Com RMON2, gerentes de rede
sero capazes de ver o trfego desde a camada 3 at a 7 do modelo
OSI (Open Systems Interconnect), Isto significa que gerentes sero
capazes de ver como flui o trfego de rede em cada um dos 7 nveis do
modelo OSI - uma capacidade que ter um impacto significante no
controle e resoluao de erros em ambientes cliente/servidor. Figura 1
nos mostra o nvel de visibilidade que RMON e RMON2 provem
dentro de um segmento LAN ou de uma rede em cada uma das
camadas do OSI.
20
15/10/2009
Estrutura da RMON2-MIB
Os objetos definidos em RMON2-MIB so
arranjados nos seguintes grupos:
Estrutura da RMON2-MIB
Os 9 grupos apresentados formam a base de toda RMON2MIB. Se um dispositivo de gerenciamento remoto implementa
um grupo, ento ele deve implementar todos os objetos
naquele grupo. Por exemplo, um agente que implementa o
grupo network layer matrix deve implementar o
nlMatrixSDTable e o nlMatrixDSTable.
Implementaes desta MIB devem tambm implementar os
grupos system e interfaces da MIB-II. Pode-se, sem prejuzo
nenhum, implementar outros grupos que sejam necessrios.
Os grupos de RMON2-MIB so definidos para prover um
significado no assinalamento dos identificadores dos objetos
e para fornecer um mtodo para que os agentes saibam
quais objetos eles devem implementar.
21
15/10/2009
Os 9 Grupos da RMON2-MIB
Os 9 Grupos da RMON2-MIB
Concluso
22