RMON
Remote Network Monitoring
Criado pelos mesmos grupos que desenvolveram o TCP/IP e o SNMP, o RMON é um padrão IETF de gerenciamento de redes cuja sigla representa Remote Network Monitoring MIB. Primeiramente, desenvolveu-se o padrão SNMP; somente depois pensou-se no RMON.
The Remote Network MONitoring (RMON) MIB was developed by the IETF to support monitoring and protocol analysis of LANs. The original version (sometimes referred to as RMON1) focused on OSI Layer 1 and Layer 2 information in Ethernet and Token Ring networks. It has been extended by RMON2 which adds support for Network- and Application-layer monitoring and by SMON which adds support for switched networks. It is an industry standard specification that provides much of the functionality offered by proprietary network analyzers. RMON agents are built into many high-end switches and routers (such as those built by 3Com and Cisco).
Simple Network Management Protocol, ou SNMP, é um protocolo de gerenciamento realmente simples: a única informação que se tem através de um alerta SNMP é que existe um problema em um ponto da rede. Os alertas do SNMP padrão notificam um problema somente quando ele já atingiu uma condição extrema suficiente a ponto de comprometer a comunicação na rede como um todo.
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. O diagnóstico do problema é uma tarefa do administrador da rede. Assim, o SNMP é simplesmente um alerta para uma condição extrema da rede.
O comitê do IETF decidiu que, para promover uma maior e melhor expansão das tecnologias de rede, era necessário um padrão de gerenciamento de redes mais sofisticado. As principais características do novo padrão, o RMON, seriam: interoperabilidade independentemente de fabricante; capacidade de fornecer informações precisas a respeito das causas de falha no funcionamento normal da rede, assim como da severidade dessa falha; finalmente, o novo padrão deveria oferecer ferramentas adequadas para diagnóstico da rede. Além destas características, o padrão deveria oferecer um mecanismo proativo para alertar o administrador dos eventuais problemas da rede, além de métodos automáticos capazes de coletar dados a respeito desses problemas.
Assim, o RMON tornou-se um padrão por volta de 1990. O RMON II foi publicado recentemente para extender as capacidades do RMON, cujo padrão está disponível nas RFCs 1757 e 1531 e apresentam padrões para redes Ethernet e Token Ring.
Overview
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 extendem 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ópio padrão RMON, definem extensões de MIB para realizar tarefas específicas.
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 extender 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.
Espera-se, da evolução do RMON, o suporte avançado à arquitetura cliente/servidor, permitindo, por exemplo, a utilização de monitores como proxies 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).
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.
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 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.
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.
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.
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.
An RMON implementation typically operates in a client/server model. Monitoring devices (commonly called "probes" in this context) contain RMON software agents that collect information and analyze packets. These probes act as servers and the Network Management applications that communicate with them act as clients. While both agent configuration and data collection use SNMP, RMON is designed to operate differently than other SNMP-based products:
* Probes have more responsibility for data collection and processing, which reduces SNMP traffic and the processing load of the clients.
* Information is only transmitted to the management application when required, instead of continuous polling.
In short, RMON is designed for "flow-based" monitoring, while SNMP is often used for "device-based" management. The disadvantage is that remote devices shoulder more of the management burden, and require more resources to do so. Some devices balance this trade-off by implementing only a subset of the RMON MIB groups (see below). A minimal RMON agent implementation could support only statistics, history, alarm, and event.
The RMON1 MIB consists of ten groups:
1. Statistics: real-time LAN statistics e.g. utilization, collisions, CRC errors
2. History: history of selected statistics
3. Alarm: definitions for RMON SNMP traps to be sent when statistics exceed defined thresholds
4. Hosts: host specific LAN statistics e.g. bytes sent/received, frames sent/received
5. Hosts top N: record of N most active connections over a given time period
6. Matrix: the sent-received traffic matrix between systems
7. Filter: defines packet data patterns of interest e.g. MAC address or TCP port
8. Capture: collect and forward packets matching the Filter
9. Event: send alerts (SNMP traps) for the Alarm group
10. Token Ring: extensions specific to Token Ring
The RMON2 MIB adds ten more groups:
1. Protocol Directory: list of protocols the probe can monitor
2. Protocol Distribution: traffic statistics for each protocol
3. Address Map: maps network-layer (IP) to MAC-layer addresses
4. Network-Layer Host: layer 3 traffic statistics, per each host
5. Network-Layer Matrix: layer 3 traffic statistics, per source/destination pairs of hosts
6. Application-Layer Host: traffic statistics by application protocol, per host
7. Application-Layer Matrix: traffic statistics by application protocol, per source/destination pairs of hosts
8. User History: periodic samples of user-specified variables
9. Probe Configuration: remote config of probes
10. RMON Conformance: requirements for RMON2 MIB conformance
Important RFCs
* RMON1: RFC 2819 - Remote Network Monitoring Management Information Base
* RMON2: RFC 2021 - Remote Network Monitoring Management Information Base Version 2 using SMIv2
* SMON: RFC 2613 - Remote Network Monitoring MIB Extensions for Switched Networks
* Overview: RFC 3577 - Introduction to the RMON Family of MIB Modules
Criado pelos mesmos grupos que desenvolveram o TCP/IP e o SNMP, o RMON é um padrão IETF de gerenciamento de redes cuja sigla representa Remote Network Monitoring MIB. Primeiramente, desenvolveu-se o padrão SNMP; somente depois pensou-se no RMON.
The Remote Network MONitoring (RMON) MIB was developed by the IETF to support monitoring and protocol analysis of LANs. The original version (sometimes referred to as RMON1) focused on OSI Layer 1 and Layer 2 information in Ethernet and Token Ring networks. It has been extended by RMON2 which adds support for Network- and Application-layer monitoring and by SMON which adds support for switched networks. It is an industry standard specification that provides much of the functionality offered by proprietary network analyzers. RMON agents are built into many high-end switches and routers (such as those built by 3Com and Cisco).
Simple Network Management Protocol, ou SNMP, é um protocolo de gerenciamento realmente simples: a única informação que se tem através de um alerta SNMP é que existe um problema em um ponto da rede. Os alertas do SNMP padrão notificam um problema somente quando ele já atingiu uma condição extrema suficiente a ponto de comprometer a comunicação na rede como um todo.
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. O diagnóstico do problema é uma tarefa do administrador da rede. Assim, o SNMP é simplesmente um alerta para uma condição extrema da rede.
O comitê do IETF decidiu que, para promover uma maior e melhor expansão das tecnologias de rede, era necessário um padrão de gerenciamento de redes mais sofisticado. As principais características do novo padrão, o RMON, seriam: interoperabilidade independentemente de fabricante; capacidade de fornecer informações precisas a respeito das causas de falha no funcionamento normal da rede, assim como da severidade dessa falha; finalmente, o novo padrão deveria oferecer ferramentas adequadas para diagnóstico da rede. Além destas características, o padrão deveria oferecer um mecanismo proativo para alertar o administrador dos eventuais problemas da rede, além de métodos automáticos capazes de coletar dados a respeito desses problemas.
Assim, o RMON tornou-se um padrão por volta de 1990. O RMON II foi publicado recentemente para extender as capacidades do RMON, cujo padrão está disponível nas RFCs 1757 e 1531 e apresentam padrões para redes Ethernet e Token Ring.
Overview
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 extendem 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ópio padrão RMON, definem extensões de MIB para realizar tarefas específicas.
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 extender 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.
Espera-se, da evolução do RMON, o suporte avançado à arquitetura cliente/servidor, permitindo, por exemplo, a utilização de monitores como proxies 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).
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.
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 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.
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.
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.
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.
An RMON implementation typically operates in a client/server model. Monitoring devices (commonly called "probes" in this context) contain RMON software agents that collect information and analyze packets. These probes act as servers and the Network Management applications that communicate with them act as clients. While both agent configuration and data collection use SNMP, RMON is designed to operate differently than other SNMP-based products:
* Probes have more responsibility for data collection and processing, which reduces SNMP traffic and the processing load of the clients.
* Information is only transmitted to the management application when required, instead of continuous polling.
In short, RMON is designed for "flow-based" monitoring, while SNMP is often used for "device-based" management. The disadvantage is that remote devices shoulder more of the management burden, and require more resources to do so. Some devices balance this trade-off by implementing only a subset of the RMON MIB groups (see below). A minimal RMON agent implementation could support only statistics, history, alarm, and event.
The RMON1 MIB consists of ten groups:
1. Statistics: real-time LAN statistics e.g. utilization, collisions, CRC errors
2. History: history of selected statistics
3. Alarm: definitions for RMON SNMP traps to be sent when statistics exceed defined thresholds
4. Hosts: host specific LAN statistics e.g. bytes sent/received, frames sent/received
5. Hosts top N: record of N most active connections over a given time period
6. Matrix: the sent-received traffic matrix between systems
7. Filter: defines packet data patterns of interest e.g. MAC address or TCP port
8. Capture: collect and forward packets matching the Filter
9. Event: send alerts (SNMP traps) for the Alarm group
10. Token Ring: extensions specific to Token Ring
The RMON2 MIB adds ten more groups:
1. Protocol Directory: list of protocols the probe can monitor
2. Protocol Distribution: traffic statistics for each protocol
3. Address Map: maps network-layer (IP) to MAC-layer addresses
4. Network-Layer Host: layer 3 traffic statistics, per each host
5. Network-Layer Matrix: layer 3 traffic statistics, per source/destination pairs of hosts
6. Application-Layer Host: traffic statistics by application protocol, per host
7. Application-Layer Matrix: traffic statistics by application protocol, per source/destination pairs of hosts
8. User History: periodic samples of user-specified variables
9. Probe Configuration: remote config of probes
10. RMON Conformance: requirements for RMON2 MIB conformance
Important RFCs
* RMON1: RFC 2819 - Remote Network Monitoring Management Information Base
* RMON2: RFC 2021 - Remote Network Monitoring Management Information Base Version 2 using SMIv2
* SMON: RFC 2613 - Remote Network Monitoring MIB Extensions for Switched Networks
* Overview: RFC 3577 - Introduction to the RMON Family of MIB Modules
Comentários