15/10/2009

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

Ao contrrio do que se pode imaginar, o SNMP no capaz de

definir o problema, nem sua gravidade; no fornece, tampouco,
recursos para uma investigao das causas desse problema. O
diagnstico do problema uma tarefa do administrador da rede.
Assim, o SNMP simplesmente um alerta para uma condio
extrema da rede.
O comit do IETF decidiu que, para promover uma maior e melhor
expanso das tecnologias de rede, era necessrio um padro de
gerenciamento de redes mais sofisticado. As principais
caractersticas do novo padro, o RMON, seriam: interoperabilidade
independentemente de fabricante; capacidade de fornecer
informaes precisas a respeito das causas de falha no
funcionamento normal da rede, assim como da severidade dessa
falha; finalmente, o novo padro deveria oferecer ferramentas
adequadas para diagnstico da rede. Alm destas caractersticas, o
padro deveria oferecer um mecanismo proativo para alertar o
administrador dos eventuais problemas da rede, alm de mtodos
automticos capazes de coletar dados a respeito desses
problemas.

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.

Uma viso geral

As estatsticas indicam: enquanto apenas 30%
dos custos de uma rede esto diretamente
associados aquisio de hardware, os 70%
restantes dizem respeito manuteno e ao
suporte dessa rede.
No momento da aquisio dos equipamentos de
uma rede, o elemento determinante na escolha
da melhor opo , via de regra, o custo. Uma
vez iniciado o processo de expanso dessa
rede, os verdadeiros custos se manifestam.
Neste momento, o departamento administrativo
ir questionar: e o gerenciamento da rede?

Uma viso geral

Alguns exemplos de recursos oferecidos por
ferramentas de gerenciamento de redes so:

Dados de interoperao das redes;

Alertas de problemas;
Aviso antecipado de problemas;
Captura automtica de dados;
Grficos de utilizao de hosts em tempo real;
Grficos de eventos da rede.

15/10/2009

Os custos de uma rede

Como indicado anteriormente, os custos
relacionados aquisio de equipamentos
constituem em torno de 30% do custo total da rede;
os 70% restantes esto associados aos custos de
manuteno e suporte da rede. A fim de reduzir os
custos da rede, podem ser destacadas algumas
polticas:

Os custos de uma rede

Proteo do Investimento
Evitar a aquisio de equipamentos com pequeno ou
nenhum grau de escalabilidade. Procurar adquirir produtos
baseados numa mesma infra-estrutura e que permitam
atualizaes naturalmente, sem a necessidade de troca
do equipamento.

Os custos de uma rede

Aumento da Disponibilidade
Quanto mais tempo a rede estiver no ar, tanto maior
ser sua capacidade de produo. A disponibilidade
depende de hardware tanto quanto de software. Do
ponto de vista de hardware, a rede dever utilizar
dispositivos com sistemas de redundncia em todos
os nveis, desde suprimentos de energia, at HDs,
processadores e up-links; do ponto de vista de
software, dever permitir o aviso automtico de
condies extremas, paging de pessoal e captura
automtica de dados em ocasio de erros. Enfim,
quanto maior a capacidade da rede de manter-se no
ar, em condies normais de funcionamento, tanto
maior ser sua capacidade de produzir.

15/10/2009

Os custos de uma rede

Manuteno Simplificada
A rede dever permitir o rpido isolamento do problema. O
sistema de gerenciamento dever identificar o problema,
sua origem, e a abordagem mais indicada para resolv-lo.
O diagnstico remoto dever ser facilitado atravs da
integrao das ferramentas de diagnstico da rede em
seus componentes. O sistema de gerenciamento dever
permitir a notificao antecipada dos problemas da rede
antes mesmo que eles ocorram. Isto dever ser realizado
atravs da configurao de graus de tolerncia para os
vrios elementos da rede. Desta forma, cria-se um novo
paradigma de gerenciamento, onde o suporte da rede
realizado de forma proativa, ao invs de reativa.

Os custos de uma rede

Rpida Resoluo de Problemas
Utilizar, sempre que possvel, equipamentos de rede
inteligentes, capazes de coletar dados sobre o seu
funcionamento e atualizarem suas configuraes
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.

Os custos de uma rede

Todos os itens acima justificam a adoo de
uma soluo de gerncia de redes,
particularmente, um sistema com caractersticas
como as do RMON. Para entender, portanto,
como os custos de operao de redes podem
ser reduzidos atravs da utilizao do RMON,
necessrio compreender sua arquitetura.
Somente com essa compreenso ser possvel
avaliar quanto pode ser economizado em tempo
e dinheiro na operao de uma rede
corporativa.

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.

Exemplo: Gerenciando colises numa Rede

ETHERNET
Considere uma rede Ethernet em que o nvel de
saturao de colises aceitvel de 60%. Atravs de
uma estao de gerenciamento, o adminsitrador da rede
configura, no dispositivo de gerenciamento (monitor) da
rede, o limite de saturao de colises 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 responsvel por exibir o mapa de
alerta e os dados recebidos do monitor, alm de notificar
o administrador da rede do recebimento desse alerta
(atravs de um pager, por exemplo). O alerta poder,
tambm, iniciar um processo de filtragem e captura de
dados para anlise posterior.

15/10/2009

Exemplo: Gerenciando colises numa Rede

ETHERNET

Como foi ilustrado, a configurao de alarmes

poder garantir a operao da rede dentro dos
nveis definidos pelo administrador. No
momento em que um alarme emitido,
possvel identificar e corrigir as causas da
condio de erro atravs da anlise dos dados
coletados pelo monitor antes e aps o disparo
do alarme. Esta forma de resoluo de
problemas, antes que estes atinjam nveis
intolerveis, , certamente, o grande diferencial
do RMON.

O padro RMON: RFC 1757

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

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)

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

mib-2 (1)

system (1)

... rmon (16)

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

A extenso RMON da MIB consiste de conjunto de definies de

objetos; cada um destes objetos classificado segundo o grupo a
que foi associado. Eis os grupos definidos pela 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.

Grupo de Histrico Ethernet

Este grupo registra amostras peridicas da rede
Ethernet e as armazena para anlise posterior.
Outros grupos devero 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 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

Controle dos dispositivos RMON

Devido a natureza complexa das funes dos
dispositivos de gerenciamento, normalmente, faz-se
necessria uma configurao prvia. Em muitos casos,
as funes necessitam de parmetros para que uma
coleta de dados seja realizada adequadamente. A
operao s pode ser realizada aps estes parmetros
estarem devidamente configurados.
Vrios grupos funcionais definidos nesta MIB tm uma
ou mais tabelas adequadas configurao de
parmetros de controle, e uma ou mais tabelas de
dados para o armazenamento dos resultados de uma
determinada operao.

Controle dos dispositivos RMON

As tabelas de controle so, por natureza, do tipo leitura
e escrita; as tabelas de dados, por sua vez, so
tipicamente apenas de leitura. Devido ao fato de que os
parmetros nas tabelas de controle descrevem os dados
nas tabelas de dados, muitos deles somente podem ser
alterados quando forem invlidos. Isto significa que,
para alterar um determinado parmetro de controle
necessrio invalid-lo. Uma vez invlido, o parmetro
removido da tabela de controle, juntamente com todos
os dados associados nas tabelas de dados. Somente
ento, cria-se uma nova entrada na tabela de controle
para o parmetro em questo. Observe que a excluso
de uma entrada na tabela de controle tambm serve
como um mecanismo para a recuperao dos recursos
associados queles dados.

Controle dos dispositivos RMON

Alguns objetos nesta MIB fornecem mecanismos para a
execuo de uma ao no dispositivo remoto de
gerenciamento. A ao pode ser realizada em
conseqncia alterao do estado do objeto. Para os
objetos definidos nesta MIB, uma solicitao para
armazenar um valor no objeto igual ao valor atualmente
armazenado ser ignorada pelo mesmo.
Para permitir o controle por mltiplos gerenciadores, os
recursos devem ser compartilhados por vrios deles.
tratam-se, tipicamente, da memria e dos recursos
computacionais que uma funo necessita.

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

Existe um mecanismo, definido nesta MIB, disponvel para cada

funo inicializada a partir de uma estao de gerenciamento, que
evita esse tipo de conflito e ajuda a resolv-los quando eles
ocorrem. Cada funo tem um rtulo identificando o iniciador (dono)
da funo. Este identificador preenchido pelo iniciador e permite
que:
Uma estao reconhece os recursos alocados para si e que no so
mais necessrios.
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 inicializao, uma estao de gerenciamento pode
reconhecer recursos previamente reservados. Com esta informao, a
estao poder liberar recursos no mais necessrios.

Compartilhamento de recursos
entre mltiplos gerenciadores

Estaes de gerenciamento devem suportar qualquer formato do

OwnerString determinado pela poltica local da empresa. Como
sugesto, o identificador dever conter um ou mais de: endereo IP,
nome da estao de gerenciamento, nome, telefone ou localizao
do operador da estao de gerenciamento. Esta informao
permitir aos usurios o compartilhamento mais eficiente dos
recursos.
Normalmente, existe certa funcionalidade padro que o dispositivo
ou administrador deseja configurar. Os recursos alocados para
estas funcionalidades sero de longa durao e estaro associados
ao prprio dispositivo ou administrador. Neste caso, ou o dispositivo
ou o administrador dever definir o OwnerString com um string
iniciando com monitor. Modificaes indiscriminadas dessas
configuraes so desencorajadas. Com efeito, uma estao de
gerenciamento somente dever alterar estes objetos com
autorizao do administrador do dispositivo.

15

15/10/2009

Compartilhamento de recursos
entre mltiplos gerenciadores

Os recursos num monitor so normalmente escassos e alocados

quando uma linha acrescentada a uma tabela de controle por uma
aplicao. Como vrias aplicaes podem utilizar um determinado
monitor simultaneamente, alocao indiscriminada dos recursos de
um monitor poder causar falta de recursos no mesmo.
Quando uma estao de gerenciamento deseja utilizar uma funo
de um monitor, encoraja-se que, primeiramente, ela investigue a
tabela de controle daquela funo em busca de uma instncia com
parmetros semelhantes para que possa compartilhar. Esta
situao particularmente indicada para as funes pertencentes
ao prprio monitor, que tendem a sofrer poucas alteraes. Se uma
estao de gerenciamento decide compartilhar uma instncia
pertencente a uma segunda estao de gerenciamento, dever
levar em conta o fato de que a estao dona da instncia poder
modific-la ou exclui-la inadvertidamente, a qualquer momento.

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.

Incluso de linhas entre mltiplos

gerenciadores
A incluso de linhas nas tabelas definidas por esta MIB
dever ser realizada pelo mtodo descrito na RFC 1212.
Nesta MIB, linhas so includas nas tabelas para
configurar uma determinada funo. Esta configurao
normalmente envolve a definio de parmetros que
controlam a operao da funo.
O agente dever checar esses parmetros para garantir
que so apropriados uma vez observadas as restries
definidas e outras especficas implementao, como a
falta de recursos. Na implementao desta MIB, pode-se
definir dois momentos para notificar a estao de
gerenciamento de que os parmetros so invlidos:
Quando a estao de gerenciamento altera cada parmetro.
Quando a estao define o EntryStatus do objeto como vlido.

16

15/10/2009

Incluso de linhas entre mltiplos gerenciadores

Se o segundo for o escolhido, no ficar claro
estao de gerenciamento qual dos parmetros
de configurao esto invlidos, causando a
emisso do erro badValue. Assim, sempre que
possvel, a implementao da MIB dever
observar a primeira opo em detrimento da
segunda, por fornecer maiores detalhes a
respeito do parmetro invlido.
Um problema pode surgir quando vrias
estaes de gerenciamento tentarem alterar um
parmetro de configurao simultaneamente
atravs do SNMP.

Incluso de linhas entre mltiplos

gerenciadores
Quando o processo envolve a criao de uma entrada
numa tabela de controle, os gerenciadores podem
colidir, tentando criar a mesma entrada. Como proteo
contra esta situao, cada entrada na tabela de controle
tem um objeto para o controle de estado da entrada com
uma semntica especial que auxilia na resoluo de
conflitos entre gerenciadores. Assim, o mecanismo de
criao 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 no alterada. Pois, quando
vrios gerenciadores tentam criar a mesma entrada
conceitual na tabela, apenas o primeiro ser bem
sucedido; os demais recebero um erro.

Incluso de linhas entre mltiplos

gerenciadores
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 vrias formas, de preferncia visando a minimizao
da possibilidade de repetio de ndices utilizados por
outros gerenciadores. Se o ndice j existe, o
mecanismo descrito anteriormente cuidar para que as
colises sejam evitadas.
Como algumas tabelas definidas nesta MIB referenciam
outras tabelas da mesma, ao incluir ou excluir entradas
numa determinada tabela, permitida a existncia de
referncias pendentes ou no resolvidas. No est
definida qualquer ordem para incluso ou excluso de
entradas nessas tabelas.

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.

Limitaes supridas pelo

RMON2
Maior confiana 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 nmero de grupos RMON MIB que o
produto suporta. RMON2 requerir que produtos implementemna mais amplamente para que possa ser considerado "baseado
em RMON2".
Correlao com a Camada Fsica: monitores baseados em
RMON coletam estatsticas no nvel 2, a camada Data Link do
modelo OSI. Esta camada se concentra primordialmente com a
formao dos pacotes: endereamento e entrega. Embora esse
tipo de informao seja muito til para a resoluo de
problemas, no se tem nenhuma viso do nvel fsico. RMON2
tem a habilidade de relacionar informao de porta ou
cabeamento na estao final, aumentando incrivelmente a
visibilidade da rede.

Limitaes supridas pelo

RMON2
Histria Completa: com RMON2, qualquer objeto MIB pode ser
localmente rastreado e gravado em um log histrico.

Os benefcios do RMON estendem a monitorao aos mais

altos nveis das camadas do protocolo. Enquanto RMON
somente prov estatsticas de trfego na camada MAC do
protocolo, RMON2 prov um discernimento das estatsticas
de trfego bem maior, especificando o protocolo e as
aplicaes que geraram aquele trfego. Este conhecimento
de vital importncia nos dias de hoje. Estender a viso do
segmento RMON para uma mais ampla fornecida pelo
RMON2 faz com que gerentes de rede tenham mais
informaes e maior conhecimento para gerenciar, corrigir os
erros e monitorar redes cada vez mais complexas. Como
resultado, RMON2 permitir a anlise cliente/servidor de uma
nova classe inteira de aplicaes; monitoramento e projeto
inter-rede; e registro nas camadas de rede e aplicao.

20

15/10/2009

Estrutura da RMON2-MIB
Os objetos definidos em RMON2-MIB so
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 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

Grupo Protocol Directory (protocolDir): Lista os protocolos que o probe

tem a capacidade de monitorar e permite a adio, remoo e configurao
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 endereos MAC para endereos
de rede descobertos pelo probe e em qual interface eles estavam na ltima
utilizao.
Grupo Network Layer Matrix (nlMatrix): Calcula a quantidade de trfego
enviado entre cada par de endereo de rede descoberto pelo probe.
Embora hlMatrixControlTable tambm tenha objetos que controlam
alMatrixTable, a implementao da alMatrixTable no necessria para a
implementao total desse grupo.
Grupo Application Layer Host (alHost): Calcula a quantidade de trfego,
por protocolo, enviado de e para cada endereo de rede descoberto pelo
probe. Implementaes desse grupo requerem a implementao do grupo
Network Layer Host.

Os 9 Grupos da RMON2-MIB

Grupo Application Layer Matrix (alMatrix): Calcula a quantidade de

trfego, por protocolo, enviado de cada par de endereo de rede
descoberto pelo probe. Implementaes desse grupo requerem que o
grupo Network Layer Matrix tambm seja implementado.
Grupo User History Collection (usrHistory): O grupo usrHistory combina
mecanismos usados nos grupos alarm e history para prover um mecanismo
de histria especificado pelo usurio utilizando trs tabelas adicionais: duas
de controle e uma de dados. Esta funo tem sido feita tradionalmente por
aplicaes NMS, via polling peridico. O grupo userHistory permite que
essa tarefa seja descarregada em um probe RMON. Os dados so
coletados da mesma maneira que qualquer tabela de dados history (por
exemplo etherHistoryTable) exceto que o usurio especifica as instncias
MIB a serem coletadas. Os objetos so coletados em bucket-groups, com o
intuito de que todas as instncias MIB no mesmo bucket-group sejam
coletadas da forma mais atmica possvel pelo probe RMON.
Grupo Probe Configuration (probeConfig): Este grupo permite controlar
a configurao de vrios parmetros operacionais do probe. As entradas de
usrHistoryObject associadas com outra usrHistoryControlTable no
precisam estar ativas antes da entrada de controle estar ativada.

Concluso

Coletar Estatstica de Nveis mais Altos: estatsticas na camada de rede

e aplicao usando as tabelas traffic, host, matrix e matrix Top N permitiro
aos gerentes ver quais clientes esto falando com quais servidores,
ampliando a viso da rede.
Traduo de Endereos: amarrar endereos da camada MAC com
endereos da camada de rede torna mais fcil a leitura de todos
endereos. A habilidade de detectar endereos IP duplicados permitir que
os gerentes de rede solucionem problemas que devastam roteadores e
LANs virtuais. Traduo de endereos e suporte a plataforma de gerncia
SNMP melhorar o mapeamento da topologia e aumentar a eficincia da
gerncia.
Histria Definida pelo Usurio: o padro RMON original permite coletar
dados histricos somente em um conjunto predefinido de estatsticas.
RMON2 permitir aos gerentes de rede configurar os dados histricos de
qualquer contador no sistema.
Filtragem Melhorada: RMON2 permitir aos usurios configurar os filtros
de forma mais flexvel e eficiente.
Configurao de Probes: o padro original RMON no lida com o
problema criado na configurao e controle de diferentes probes de
fornecedores diversos. O novo padro RMON2 permitir a configurao de
diferentes marcas de probes baseados em diferentes aplicaes RMON.

22