RMON e RMON2 Remote Network Monitoring

Luciano Paschoal Gaspary O protocolo SNMP e a MIB-II ainda so amplamente utilizados para o gerenciamento de equipamentos de rede. Agentes de software presentes nesses equipamentos coletam informaes sobre o trfego de entrada e sada dos mesmos (ex.: nmero de pacotes recebidos e enviados). Com essas informaes, o gerente de rede tem conhecimento sobre o volume de trfego gerado por cada dispositivo monitorado. Para ter uma noo aproximada do trfego total da rede, preciso somar os valores obtidos de cada dispositivo. A distribuio cada vez maior, tanto geogrfica como lgica, das redes de computadores tornou a utilizao desta abordagem complexa e ineficiente. Os equipamentos que suprem a dificuldade apontada acima so denominados monitores de rede ou probes. Tipicamente, um monitor opera em um segmento de rede local no modo promscuo, observando cada pacote propagado nesse segmento. Os monitores podem produzir estatsticas com base nos pacotes observados (ex.: taxa de erros, nmero de colises, nmero de pacotes entregues por segundo, entre outros). Alm disso, podem armazenar pacotes para submet-los, posteriormente, a algum tipo de anlise. Filtros podem ser utilizados para limitar o nmero de pacotes contabilizados ou capturados, baseado em seu tipo ou alguma outra caracterstica. As estatsticas e o trfego armazenado podem ser recuperados pelas aplicaes de gerenciamento atravs do protocolo SNMP [PER98]. Segundo Stallings [STA96], a maior contribuio ao conjunto de padres SNMP foi a especificao de RMON1, MIB para monitorao remota, suplementar MIB-II. Essa MIB foi criada para estabelecer funes e interfaces para a comunicao entre estaes de gerenciamento e os probes. Os objetos RMON so organizados em 20 grupos. Os primeiros 10 grupos constituem a MIB RMON1, voltada ao gerenciamento das operaes realizadas nos nveis fsico e de enlace em redes Ethernet. Ela compila estatsticas e informaes histricas como nmero de colises, erros de CRC, entre outras [MIL97]. Uma extenso dessa MIB adaptada para redes Token Ring est enquadrada em um grupo definido em um documento prprio. Os 10 grupos restantes constituem a MIB RMON2, proposta para viabilizar a coleta de estatsticas e informaes para protocolos acima do nvel de enlace. Ela permite a monitorao de padres de uso da rede e a observao do trfego de aplicaes clienteservidor (ex.: HTTP, FTP, DNS, entre outras) e comunicaes fim a fim [PER98] (vide figura 1).

Root ISO Org DoD Internet Private Mgmt MIB1 & 2 RMON1 MIB1 MIB2 1. Statistics 2. History 3. Alarm 4. Hosts 5. Host Top N 6. Matrix 7. Filter 8. Capture 9. Event 10. Token Ring

RMON

11. Protocol Directory 12. Protocol Distribution 13. Address Map 14. Network-Layer Host 15. Network-Layer Matrix 16. Application-Layer Host 17. Application-Layer Matrix 18. UsrHistory 19. Probe Configuration 20. RMON Conformance RMON2

Figura 1 - Grupos das MIBs RMON e RMON2

1. Histrico e evoluo das MIBs RMON

Antes da existncia das MIBs RMON, vendedores forneciam dispositivos de monitorao dotados de teclado e visor. Os usurios desses dispositivos precisavam estar fisicamente presentes em frente aos mesmos para observar as estatsticas por eles coletadas. Havia vrias interfaces e formatos para apresentar os resultados coletados aos usurios. Alm disso, as informaes recuperadas por dispositivos de diferentes fabricantes no eram coincidentes. Segundo Perkins [PER98], o passo inicial rumo a definio do padro RMON ocorreu quando alguns fabricantes comearam a desenvolver probes que no possuiam interface. Esses dispositivos eram uma "caixa-preta" com uma interface de rede e outra serial. interface serial era conectado um terminal ASCII para configurao inicial do probe. Alguns destes dispositivos usavam um protocolo proprietrio, outros SNMP, para recuperar informaes de MIBs no padronizadas. Lderes do IETF reuniram essas iniciativas e formaram, em 1990, o grupo de trabalho RMON. O primeiro documento gerado pelo grupo foi a RFC 1271, publicada em novembro de 1991. Este documento contm a definio da MIB RMON1 para redes Ethernet. Em 1993 o grupo de trabalho props extenses para redes Token Ring atravs da RFC1513 (vide tabela 1). O incio dos trabalhos para a definio de RMON2 ocorreu em 1994. Paralelamente, o resultado das primeiras implementaes e operaes com RMON1 foi utilizado para aprimorar a verso original desta MIB. Esta iniciativa deu origem RFC 1757, publicada em fevereiro de 1995, que substituiu a RFC 1271. Os trabalhos na definio da MIB RMON2 resultaram na publicao das RFCs 2021 e 2074, em janeiro de 1997.

Tabela 1 - RFCs de RMON

RFC 1271
obsolet

Ttulo Remote Network Monitoring Management Information Base Token Ring Extensions to the Remote Network Monitoring MIB

Data Novembro de 1998 Setembro de 1993

1513 1757 2021 2074

2613 internet draft internet draft internet draft

Remote Network Monitoring Management Information Base Fevereiro de 1995 Remote Network Monitoring Management Information Base Version Janeiro de 1997 2 using SMIv2 Remote Network Monitoring MIB Protocol Identifiers Janeiro de 1997 Remote Network Monitoring MIB Extensions for Switched Networks Junho de 1999 Version 1.0 Remote Network Monitoring Management Information Base for High Capacity Networks Remote Network Monitoring MIB Protocol Identifier Macros Remote Network Monitoring MIB Protocol Identifier Reference -

Ainda em 1997 novos trabalhos foram iniciados: MIB RMON para redes de alta velocidade e aprimoramento dos identificadores de protocolos.

2. Objetivos almejados para RMON

As metas definidas pelo grupo de trabalho para a definio das MIBs RMON so descritas nas RFCs 1757 e 2021 [PER98]. So elas: Operao off -line: nem sempre a estao de gerenciamento estar em constante contato com os probes RMON; isto pode ser feito com a finalidade de diminuir os custos de comunicao (especialmente quando o enlace de comunicao uma linha discada) ou por falha entre as estaes de gerenciamento e os agentes. Por essa razo, a MIB RMON deve permitir que os agentes sejam configurados para realizar diagnsticos e coletar estatsticas continuamente, mesmo que a comunicao entre a estao de gerenciamento e os agentes no seja possvel ou no seja eficiente. O agente deve tentar notificar a estao de gerenciamento sobre a ocorrncia de algum evento importante. Se a comunicao de notificao falhar, a informao sobre essa ocorrncia pode ser continuamente acumulada pelos monitores e repassada s estaes de gerenciamento da forma mais conveniente e eficiente possvel. Monitorao pr-ativa: os recursos disponveis nos monitores so potencialmente teis para continuamente executar d iagnsticos e manter logs de desempenho da rede. Como o monitor est sempre disponvel desde o incio de qualquer problema, ele deve poder notificar a estao de gerenciamento sobre a ocorrncia de uma determinada falha e fazer um registro histrico de informaes estatsticas sobre as falhas ocorridas. Esse histrico pode ser revisado pela estao de gerenciamento para, no futuro, realizar diagnsticos sobre as causas dos problemas. Deteco e registro de problemas: o monitor deve poder ser configurado para o reconhecimento de determinadas condies, realizando constantes averiguaes. Quando uma dessas condies ocorre, o evento pode ser armazenado num log e as estaes de gerenciamento podem ser notificadas de diferentes maneiras.

 Dados com valor agregado: o monitor de rede deve poder realizar anlises especficas com os dados coletados na sub-rede onde atua, liberando a estao de gerenciamento dessa responsabilidade. Por exemplo, o probe pode analisar o trfego da sub-rede para determinar que estaes geram maior trfego ou maior nmero de erros na sub-rede em questo [STA96]. Mltiplos gerentes : uma organizao pode ter mltiplas estaes de gerenciamento em diferentes unidades da organizao e com diferentes funes, possibilitando assim uma fcil recuperao de falhas. Como os ambientes com mltiplas estaes de gerenciamento so comuns, os monitores remotos devem ter a capacidade de se relacionar com mais de uma estao de gerenciamento, usando assim seus recursos potencialmente.

3. Grupos da MIB RMON1

Os agentes RMON1 podem residir no apenas em dispositivos dedicados tarefa de monitorao (probes), mas tambm em equipamentos como switches, roteadores, entre outros. Distribudos em pontos remotos, eles coletam informaes definidas na MIB RMON1, analisando os quadros que trafegam nos segmentos da rede. A figura 1 lista os grupos da MIB RMON1 e ilustra onde ela se enquadra dentro dos padres da ISO e do IETF [RMO97]. So eles [ART98, PER98, STA96]: statistics : esse grupo prov estatsticas medidas pelo monitor em cada uma de suas interfaces. As estatsticas incluem nmero de pacotes unicast, broadcast e multicast, nmero de colises observadas no segmento, nmero de pacotes no contabilizados pelo agente, entre outras; history: registra amostras estatsticas periodicamente e armazena para uma posterior recuperao. Em cada amostra, so coletados dados pr-determinados. No caso de redes Ethernet, alguns dos dados coletados so: nmero de octetos e de pacotes observados, nmeros de pacotes broadcast e multicast, nmero de erros de CRC, nmero de colises, entre outros. Esta funcionalidade contribui tanto para a reduo de trfego SNMP na rede como para a diminuio do processamento realizado pela estao de gerenciamento [TEC97] (vide figura 2); alarm: esse g rupo periodicamente obtm amostras estatsticas de variveis da MIB e as compara com limiares superior e inferior previamente configurados. Se o valor recuperado ultrapassa o limite superior ou fica abaixo do limite inferior, um evento gerado. Para limitar a gerao de alarmes, o grupo define o mecanismo denominado histerese; host : mantm estatsticas sobre cada host descoberto na rede. O termo host designa qualquer equipamento dotado de uma interface de rede; hostTopN : o grupo hostTopN mantm relatrios que especificam os principais hosts de uma lista, ordenados por uma de suas estatsticas (ex.: primeiros 20 hosts com maior nmero de pacotes enviados); matrix:armazena estatsticas de trfego e nmero de erros entre pares de hosts; filter: esse grupo prov um mecanismo para a estao de gerenciamento poder instruir o probe a observar pacotes selecionados. O critrio para seleo dos pacotes definido no formato de um ou mais filtros conjugados;

 capture: usado para configurar um esquema de armazenamento temporrio para captura de pacotes, de acordo com um dos critrios de seleo definido no grupo filter; event: esse grupo controla a gerao e notificao de eventos.
Ferramentas de Histria dos anlise objetos Gerente SNMP Dispositivo de rede Agente SNMP
Consulta do gerente (para cada objeto) Resposta do agente (valor do objeto)

MIB

(a) Esquema de consultas tradicional Ferramentas de Gerente anlise SNMP Dispositivo de rede Agente RMON Consulta do gerente
(envie histria) Resposta do agente (tabela histria)

Histria local MIB RMON

(b) Esquema de consultas em solues RMON/RMON2

Figura 2 - Interaes entre gerentes e agentes

4. Monitorao de trfego de protocolos de nveis superiores

A MIB RMON2 uma extenso da MIB RMON1 tradicional, criada para suportar a monitorao de protocolos de alto nvel [GAS98]. Os grupos definidos por ela so ilustrados na figura 1. So os seguintes: protocol directory: um repositrio que indica todos os protocolos (encapsulamentos) que o probe capaz de interpretar; protocol distribution: agrega estatsticas sobre o volume de trfego gerado por cada protocolo, por segmento de rede local; address map: associa cada endereo de rede ao respectivo endereo MAC, armazenando-os em uma tabela. A traduo de endereos permite a gerao de mapas topolgicos aprimorados e a deteco de endereos IP duplicados em uma rede; network-layer host: coleciona estatsticas sobre o volume de trfego de entrada e sada das estaes com base no endereo do nvel de rede. Como conseqncia, o gerente pode observar alm dos roteadores que interligam as sub-redes e identificar as reais estaes que esto se comunicando. Este grupo coleta estatsticas similares s do grupo host da MIB RMON1. A diferena que o grupo nlHost faz esta coleta com base no endereo de rede e no no endereo MAC; network-layer matrix: prov estatsticas sobre o volume de trfego entre pares de estaes com base no endereo do nvel de rede; application-layer host: agrega estatsticas sobre o volume de trfego de entrada e sada das estaes com base em endereos do nvel de aplicao. Consultas a este grupo permitem que o gerente trace um perfil sobre o volume de trfego

gerado ou recebido por aplicaes especficas como o Lotus Notes, o Microsoft Mail, entre outras; application-layer matrix: coleciona estatsticas sobre o volume de trfego entre pares de estaes com base no endereo do nvel de aplicao; user history collection: amostra periodicamente objetos especificados pelo usurio (gerente) e armazena as informaes coletadas de acordo com parmetros definidos tambm pelo usurio. No padro RMON1, esta funcionalidade oferecida para um conjunto pr-definido de objetos; probe configuration: define parmetros de configurao padres para probes RMON. Deste modo, a estao de gerenciamento com software de um fabricante capaz de configurar remotamente um probe de outro fabricante; rmon conformance: descreve requisitos de conformidade para a MIB RMON2.

a. Visibilidade no nvel de rede Com RMON1 , um probe pode monitorar todo o trfego da LAN a qual est ligado. Ele pode capturar todos os quadros relativos sub -camada MAC do nvel de enlace e ler os endereos MAC fonte e destino dos mesmos. O probe capaz de prover informaes detalhadas sobre o trfego de quadros enviados e recebidos por cada estao em cada LAN associada. Contudo, se um roteador est ligado a uma destas LANs, no h como determinar a fonte do trfego que chega por ele, tampouco o destino de quadros que saem do segmento via este roteador [STA96]. Esta situao ilustrada na figura 3 (extrada de [TEC97]).

Figura 3 - Limitao da MIB RMON1 Com RMON2, por outro lado, o probe capaz de operar com protocolos localizados acima do nvel de enlace. Ele pode, por exemplo, ler o cabealho do protocolo do nvel de rede encapsulado no quadro, que tipicamente o protocolo IP. Isto permite a ele analisar o trfego que passa atravs do roteador para determinar a fonte e destino reais dos pacotes. Com esta capacidade, o gerente de rede pode responder a uma srie de questes como: 1. Se h sobrecarga na LAN devido ao trfego que chega via o roteador, que subredes ou estaes so responsveis por atrair este volume de trfego? 2. Se um roteador est sobrecarregado devido a um grande volume de trfego de sada, que estaes locais so responsveis por este volume de trfego e para que sub-redes ou estaes destinos o trfego direcionado? 3. Se existe um grande volume de dados que chega via um roteador e deixa o segmento atravs de outro, que redes ou estaes so responsveis por este volume de trfego? Com respostas a questes como estas, o gerente de rede pode ser capaz de fazer um melhor planejamento para confinar este trfego e, consequentemente, melhorar o

desempenho da rede. Por exemplo, ele pode verificar que clientes esto se comunicando com que servidores e posicionar estes sistemas em s egmentos apropriados da rede, visando otimizar o fluxo de trfego. b. Visibilidade no nvel de aplicao Um probe RMON2 no est limitado monitorao e decodificao de trfego no nvel de rede. Ele pode observar tambm protocolos do nvel de aplicao. importante salientar que utilizando a terminologia apresentada na RFC que define o RMON2, qualquer protocolo acima do nvel de rede considerado um protocolo de aplicao. Um probe RMON2, por exemplo, capaz de verificar acima do nvel IP atravs da leitura e decodificao de protocolos de nveis superiores como TCP encapsulados no datagrama IP e, mais ainda, verificando os cabealhos dos protocolos do nvel de aplicao. Isto permite ao gerente de rede monitorar trfego com um alto grau de detalhamento [STA96]. Com RMON2, uma aplicao de gerenciamento de rede pode implementar a gerao de grficos apresentando porcentagens de trfego por protocolo ou por aplicaes. Novamente, este nvel de detalhamento viabiliza a otimizao da carga da rede e a manuteno do seu desempenho.

Referncias bibliogrficas
[ART96] ARTOLA, ESMILDA SENZ. Olho vivo - Sistema Especialista para Gerncia Pr-Ativa Remota. Dissertao de Mestrado. Porto Alegre: PGCC da UFRGS, 1996. [GAS98] GASPARY, LUCIANO P. Estudo do padro RMON2. Trabalho Individual n. 646. Porto Alegre: PGCC da UFRGS, 1998. [MIL97] MILLER, MARK. Managing Internetworks with SNMP. Second Edition. USA: M&T Books, 1997. [PER98] PERKINS, DAVID T. RMON - Remote Monitoring of SNMP-Managed LANs. First Edition. USA: Prentice Hall, 1998. [RMO97] RMON METHODOLOGY. RMON Methodology. Disponvel por WWW em http://www.3com.com/nsc/500251.html (6 Nov. 1997). [STA96] STALLINGS, WILLIAM. SNMP, SNMPv2 and RMON: Practical Network Management. Second Edition. USA: Addison Wesley, 1996. [TEC97] TECHNOLOGY BANDWIDTH MANAGEMENT FOR CORPORATE INTRANETS. Monitoring Intranet Traffic Flows with Disponvel por WWW em RMON/RMON2. http://www.3com.com.nsc/500631b.htm (22 de julho de 1998).