Gerenciamento de
Redes de TCP/IP
Introdução

O que é o Gerenciamento de Redes?
• Ações que permitem que a rede de
computadores permaneça operando da
forma mais adequada a maior parte do
tempo
• Envolve: expectativa dos usuários +
recursos financeiros disponíveis
• Gerenciamento manual é gerenciamento?
Introdução

Gerentes e recursos auxiliares
• Motivo econômico: gerenciar uma rede
com muitos gerentes é caro
 16
equipamentos - 1 gerente
 32 equipamentos - 2 gerentes
 64 equipamentos - 4 gerentes
 128 equipamentos - 8 gerentes
 256 equipamentos - 16 gerentes!!!
Introdução
• Motivo técnico: gerentes humanos são
muito “lentos” para perceberem certos
eventos de rede
Introdução

Gerenciamento de Redes em Ciência da
Computação: estudo de formas que
auxiliem o gerente da rede em manter a
mesma sempre ativa
 Envolve:
• Protocolos
• Equipamentos
• Software de gerenciamento
O que deve ser gerenciado?

A OSI dividiu o gerenciamento em 5 áreas
funcionais distintas:
• Gerenciamento de Falhas
 Ex.:
Como avisar ao gerente que o enlace da
corporação caiu?
• Gerenciamento de Configuração
 Ex.:
Quais os roteadores da rede devem sofrer
um atualização do sistemas operacional?
O que deve ser gerenciado?
• Gerenciamento de Desempenho
 Ex.:
Por que a conexão de 2Mbps com a
Internet só está funcionando a 1Mbps?
• Gerenciamento de Segurança
 Ex.:
Quem acessou os arquivos restritos às 5
horas da manhã?
• Gerenciamento de Contabilização
 Ex.:
Que usuário utiliza mais a impressora?
 Ex.: Quem mais utiliza HTTP às 15 horas?
O que deve ser gerenciado?

Tipicamente o gerenciamento se preocupa
com elementos internos ao domínio
administrativo
• Redes de uma corporação
• Universidade e seus setores
 Com o advento da Internet, o
gerenciamento deve se preocupar também
com elementos externos
• Por que o roteador do provedor de acesso
não está repassando os pacotes
corretamente?
O que deve ser gerenciado?
Portáteis
Internet
Hubs
Switches
Hosts
Roteadores
Impressoras
Estação de
Gerenciamento
Etapas do gerenciamento

Criação e implantação da rede
• Projeto físico - determinação de quais os
equipamentos que serão utilizados
• Configuração - determinação de quais os
endereços IP atribuídos aos equipamentos
 Manutenção
• Instalação das estruturas (software) de
gerenciamento
• Monitoração e configuração
Modelo de gerenciamento

O modelo de gerenciamento define as
estruturas necessárias para se ter o
gerenciamento de redes
Processo Gerente
Base de
dados
Solicitações
Respostas
Notificações
Rede
Processo Agente
Base de
dados
Modelo de gerenciamento




Para cada funcionalidade/dispositivo existem
programas específicos que capturam as
informações de interesse
Inevitavelmente, com um grande número de
equipamentos necessitaremos de um grande
número de programas para gerenciar a rede
Equipamentos com mesmas funcionalidades,
mas de fabricantes diferentes, são gerenciados
por programas diferentes
Não existiria uma forma padrão de aquisição de
informações em uma rede de computadores?
Protocolos

ICMP
• O ICMP é considerado parte da camada IP
• Entretanto é encapsulado em um pacote
IP
Datagrama IP
Cabeçalho
IP
20 bytes
Mensagem ICMP
Protocolos
32 bits
Tipo
Código
Checksum
(conteúdo depende do Tipo e Código da mensagem)
• As mensagens podem ser classificadas como
requisições ou erros
• Nenhuma mensagem de erro pode ser gerada em
resposta a outra mensagem de erro
Protocolos

Implementação do ping
• Mensagem ICMP Echo Request
• Resposta: ICMP Echo Reply
 Implementação do tracert
• Uso de campo TTL do protocolo IP
• Enquanto receber mensagens de descarte
sabe que não chegou ao final
• Chega ao destino com um Echo Reply
Gerenciamento não
intrusivo

Analisa-se o conteúdo da rede através da
monitoração do enlace
 Um software (sniffer) captura todos os
pacotes do enlace e fornece resultados
sobre o tráfego
 Não intrusivo porque não coloca nenhum
tráfego de gerenciamento extra na rede
Protocolos


IAB (Internet Activities Board) tinha 3 opções
(1988)
• High-level Entity Management System (HEMS)
• Simple Gateway Monitoring Protocol (SGMP)
• Common Management Information Protocol over
TCP (CMOT)
Decisão: implementar SNMP (baseado em SGMP) com
vistas ao CMOT (CMIP over TCP) -> IETF (Internet
Engineering Task Force)


SNMP
• Para gerenciamento de falhas e configuração
• Baseado em IP
Resultado: SNMP é o padrão de fato no gerenciamento de
redes atualmente
GERÊNCIA SNMP
SIMPLE MANAGEMENTE NETWORK PROTOCOL (SNMP)

Inicialmente desenvolvido em 1988 como uma pequena solução
para gerenciamento de dispositivos conectados a Internet;

Padrão para as redes baseadas no conjunto de protocolos TCP/IP
como a Internet:
• Simples de implementar;
• Amplamente difundido;

Compõe os frameworks de gerência de redes padrão IETF;

Evolutivo: SNMPv2, SNMPv3, RMON1, RMON2 ...
GERÊNCIA SNMP
SIMPLE MANAGEMENTE NETWORK PROTOCOL (SNMP)

Composto de:
• Protocolo para trocas de mensagens;
• Padrões para estruturar a informação;

Originalmente o SNMP oferecia suporte somente para o
gerenciamento de bridges, routers e gateways, mas rapidamente
este suporte foi estendido para todo o tipo de dispositivo de rede;

Além das redes ethernet, existem implementações do SNMP para
suporte a Novell IPX/SPX, ApleTalk DDP e outras tecnologias de
enlace como ARCNET, ATM e FDDI.
GERÊNCIA SNMP
EVOLUÇÃO SNMP

SNMPv1 continua sendo a versão completa padronizada para a
Internet;

Segundo o IETF cada especificação (Request For Coments) pode
apresentar os níveis proposta, rascunho, completa, experimental e
histórica ;

O SNMPv3 é a terceira versão do SNMP em desenvolvimento com a
proposta de adicionar características necessárias para o suporte dos
ambientes de Internet atuais;

O SNMPv3 está passando para o nível rascunho e as principais
propostas são a segurança e novas implementações para administração
remota.
GERÊNCIA SNMP
EVOLUÇÃO SNMP
Nome
Nível
Descrição
SNMPv1
Completa
A versão Original, definida pela RFC 1157 [maio de
1990].
SNMPsec
Histórica
A primeira tentativa de adição de Segurança ao SNMPv1,
definida pelas RFCs 1351 [julho de 1992], 1352 [julho de
1992] e 1353 [julho de 1992].
SNMPv2p
Histórica
Outra tentativa de adição de Segurança ao SNMP,
definida pelas RFCs 1441[abril de 1993], 1445 [abril de
1993], 1446 [abril de 1993], 1448 [abril de 1993] e 1449
[abril de 1993].
SNMP2c
Experimental
Foi uma tentativa de combinar o protocolo de operação
do SNMPv2 com com a segurança do SNMPv1, definida
pelas RFCs 1901 [janeiro de 1996] , 1905 [janeiro de
1996] e 1906 [janeiro de 1996].
GERÊNCIA SNMP
EVOLUÇÃO SNMP
SNMPv2u
Experimental
Foi uma tentativa de oferecer segurança baseada nas
operações de nomes de usuários e protocolos SNMPv2,
definida pelas RFCs 1905 [January 1996],1906 [janeiro
de 1996],1909 [fevereiro de 1996] e 1910 [fevereiro de
1996].
SNMPv2*
Experimental
Foi uma tentativa de adicionar as melhores
características do SNMPv2p e SNMPv2u, definida pelo
documento encontrado no site SNMP Research.
SNMPv3
Proposta
Proposta atual para a adição de segurança e
administração remota ao SNMP, definida pelas RFCs
2271 [janeiro de 1998], 2271 [janeiro de 1998], 2272
[janeiro de 1998], 2273 [janeiro de 1998], 2274 [janeiro de
1998] e 2275 [janeiro de 1998].
Protocolos

SNMP (Simple Network Management Protocol)
• Simples porque os recursos gerenciados
necessitam de pouco processamento nas tarefas
de gerenciamento; mínimo de software necessário
• Tarefas mais complexas de processamento e
armazenagem de dados são de responsabilidade
do sistema gerenciador
• Poucas funções de gerenciamento são
pertinentes aos recursos gerenciados
• Para o protocolo ser simples existe um conjunto
limitado de comandos e mensagens do protocolo
possíveis
Protocolos
• Protocolo não orientado a conexão; nenhuma
ação prévia é necessária no envio de mensagens;
nenhuma ação é necessária após as mensagens
terem sido enviadas
• Conseqüência: não existe nenhuma garantia que
as mensagens do protocolo chegarão ao destino
• Na prática, entretanto, a maioria das mensagens
são entregues, e aquelas que não são podem ser
retransmitidas
• Robustez: como não existe conexão, nem o
gerente nem o sistema gerenciado necessitam um
do outro para operar
Protocolos




Para que um recurso possa ser gerenciado, basta
criar um agente SNMP para o recurso
O gerenciamento é feito de forma uniforme por
um sistema de gerenciamento
A interface de gerenciamento é então a interface
do sistema que interage com os agentes
Cada endereço IP pode possuir vários agentes
SNMP, mas de forma geral tem-se apenas um
gerente e várias expansões do mesmo
Protocolos

Agentes SNMP podem ser encontrados em:
• Hubs mais sofisticados
• Servidores de rede e seus sistemas operacionais
• Placas de rede mais sofisticadas e respectivos hosts
• Dispositivos de rede como pontes, switch’s e roteadores
• Equipamentos de testes como analisadores e monitores de
rede
• No-breaks
• Modens
• Bastidor de modens
• Servidores Web
• Servidores de FTP
• etc, etc e etc
Modelo SNMP
Sistema de Gerenciamento
Sistema Gerenciado
Recursos
Mensagens SNMP
Gerente SNMP
Agente SNMP
UDP
UDP
IP
IP
Enlace
Enlace
Físico
Físico
Rede
Trap
Resposta
Set
Get
Get-Next
Objetos
Gerenciados
Trap
Resposta
Set
Get-Next
Get
Aplicação de
Gerenciamento
SNMP
SNMP - Aplicação
Apresentação
Sessão
UDP - Transporte
IP - Rede
Local
Network
Header
IP
Header
UDP
Header
Mensagem SNMP
Datagrama UDP
Datagrama IP
Quadro no nível de enlace
Local
Network
Trailer
SNMP - Mensagens

SNMP Protocol Data Units (PDUs)
• Mensagem SNMP
 Versão
+ Comunidade (header de
autenticação)
 PDU
• 5 tipos de PDUs
 GetRequest
 GetNextRequest
 GetResponse
 SetRequest
 Trap
SNMP - Campos das
Mensagens
Versão
Tipo
de
PDU
Request
ID
Comunidade
Status
de
Erro
PDU GetRequest, GetNextRequest,
GetResponse ou SetRequest
Índice
do
Erro
Objeto 1,
Valor 1
Objeto 2,
Valor 2
...
VarBind List

Get, GetNext, Set e GetResponse têm o
mesmo formato
 Trap tem formato exclusivo
SNMP - Campos das
Mensagens

Campos
• Versão. Para garantir que gerente e agente estão
executando a mesma versão do protocolo.
Mensagens com versões diferentes são
descartadas.
• Comunidade. Garante o acesso a um conjunto
limitado de objetos da MIB. Caso exista
diferenças na comunidade é emitido pelo agente
uma trap que indica falha de autenticação
• Caso a versão e comunidade estejam
consistentes então é processada a PDU logo a
seguir
SNMP - Campos das
Mensagens
• Tipo de PDU. Inteiro que identifica a
operação a ser processada
0
- GetRequest;
 1 - GetNextRequest;
 2 - GetResponse;
 3 - SetRequest;
 4 - Trap
• Request ID. Inteiro que identifica pares de
mensagens SNMP entre agente e gerente.
SNMP - Campos das
Mensagens
• Status de Erro. Identifica operações executadas
com sucesso ou um dos cinco erros previstos
0 (noError) - Operação sem erros
 1 (tooBig) - O tamanho da PDU GetResponse excede
um limite local
 2 (noSuchName) - Não existe objeto com o nome
requisitado
 3 (badValue) - Uma PDU SetRequest contém uma
variável de tipo, tamanho ou valor inconsistente
 4 (readOnly) - Uma PDU SetRequest foi enviada para
alterar o valor de um objeto read-only
 5 (genErr) - Erro genérico

SNMP - Campos das
Mensagens
• Índice do Erro. Indica a qual par objetovalor, passado na PDU, se refere o erro
• VarBind. Ligação entre um objeto e um
valor; VarBind List: lista destas ligações
• Em GetRequest e GetNextRequest os
objetos possuem valores associados igual
a NULL (tipo de dado especial de ASN.1)
Arquitetura de Gerenciamento
Baseada na Web

Interface de gerenciamento: browser
 Vantagem: Independência de plataforma
• Existem navegadores para todas as
plataformas mais usadas
 As informação de gerenciamento são
armazenadas em um WebServer
 O browser acessa o WebServer para obter
tais informações
Arquitetura de Gerenciamento
Baseada na Web
Browser A
Web Server
Browser C
Browser B
Arquitetura de Gerenciamento
Baseada na Web

Existem duas formas de gerenciamento
• Gerentes SNMP usando WebServers
O browser acessa um gerente que acessa as
informações via SNMP
 As informações são disponibilizadas em páginas HTML
pelo gerente SNMP

• Agentes SNMP com HTTP
O browser acessa diretamente os recursos através do
browser
 O WebServer acessa os dados através de SNMP
 Os dados são disponibilizados através de páginas HTML
geradas pelo agente SNMP
 O recurso gerenciado deve possuir capacidade de
processamento para suportar ao mesmo tempo um
WebServer e um agente SNMP

Arquitetura de Gerenciamento
Baseada na Web
Browser
HTTP
HTTP
Web Server
Web Server
Páginas HTML
Páginas HTML
SNMP
Agente SNMP
Gerente
SNMP
SNMP
Agente SNMP
Management Information
Base (MIB) - Conceitos

É uma base de dados conceitual
• Os dados podem estar realmente em um SGBD

ex.: Taxa de utilização de um link
• Os dados podem ser encontrados nos próprios
recursos




ex.: Estado atual de uma interface
Uma MIB é apresentada como uma árvore de dados
estruturada
Nodos intermediários contém sub-nodos, mas não
contém nenhum valor associado
Se um nodo não possui sub-nodos então ele é
chamado de objeto e possui um valor associado
Management Information
Base (MIB) - Identificação
Cada nodo possui um identificador (OID)
O OID de um nodo é composto pelo OID de seu pai mais o
seu próprio identificador relativo


Raiz
Nodo(1)
Nodo(1)
Objeto(1)
Nodo(2)
Nodo(2)
Nodo(1)
Objeto(2)
Objeto(1)


O nodo raiz da MIB não possui OID
A árvore é percorrida em profundidade começando pelos
ramos da esquerda e seguindo a direita
Management Information
Base (MIB) - Identificação

O uso de número nos OIDs dificulta a
compreensão de cada nodo da MIB
 Alternativamente, um OID pode ser
substituído por um nome melhor
explicativo: OID Name
• ex.: system = 1.3.6.1.2.1.1
• ex.: sysUpTime = 1.3.6.1.2.1.1.3
 Nas identificações, o OID e o OID Name
podem ser utilizados conjuntamente
• ex.: sysUpTime = system.3
(MIB) Recursos Envolvidos



Para executar o gerenciamento, o sistema utiliza
várias fontes de informação em relação às MIBs
• Valores do dado acessado: agente no recurso
gerenciado
• Descrição do dado acessado: arquivo de MIB
• Tipo do dado acessado: arquivo de MIB
O que é um arquivo de MIB? Arquivo que
descreve uma base de dados conceitual
informando a descrição de cada dado, seu tipo e
estruturação dentro da árvore
Apenas o valor do dado é recuperado através do
acesso aos agentes
(MIB) Recursos Envolvidos



Normalmente apenas o gerente necessita de um arquivo de
MIB
• O gerente pode não conhece a natureza dos dados
• O arquivo pode ser compilador para que as informações
sejam acessadas mais rapidamente
• Uso de um compilador de MIB pelo gerente
O agente não precisa se utilizar de um arquivo de MIB
• Ele sempre sabe a natureza dos dados que está
implementando
• Um arquivo de MIB é utilizado pelos agentes quando uma
nova implementação é realizada, mas o arquivo serve
apenas como documentação
Com freqüência o termo “arquivo MIB” é referenciado
apenas por MIB, o que pode gerar confusão
Elementos do
Gerenciamento

Para que o gerenciamento possa ser implantado, temos
necessariamente que utilizar os seguintes elementos:
• Gerente (estação de gerenciamento, sistema
gerenciador)

Acessa dados de uma base localizada no sistema gerenciado
• Agente (recurso gerenciado, sistema gerenciado)

Exporta os dados da base de gerenciamento para que o gerente
possa ter acesso aos mesmos
• Protocolo (ex.: SNMP)

Fornece o mecanismo de comunicação entre o gerente e agente
• Base de dados (ex.: MIB)

Os dados a serem gerenciados, seu valor, tipo e significado
Bases de Gerenciamento



Cada MIB define um conjunto de objetos que
podem ser acessados pelos gerentes
MIB-I (RFC 1066, RFC 1156)
• Publicada pela primeira vez em 1990
• Apresentava objetos para gerenciamento genérico
de equipamentos
MIB-II (RFC 1158, RFC 1213)
• Definições da MIB-I foram expandida e
melhoradas
• Permite expansão da MIB para melhoramentos
específicos de empresas
MIB-II



Dividida em três sub-árvores
• ccitt (0), administrada pelo CCITT
• iso (1), administrada pela ISO
• joint-iso-ccitt(2), pela ISO e CCITT
iso(1), org(3), U.S. Departament of Defense:
dod(6) e internet(1)
Sobre internet temos:
• directory(1): reservado para uso da ISO
• mgmt(2): para gerenciamento genérico
• experimental(3): para experimentações
• private(4) com enterprises(1): para gerenciamento
específico
MIB-II

Os objetos da MIB-II são encontrados no OID 1.3.6.1.2.1
ou mgmt.1 ou mib-2
• system (mib-2.1): descrições gerais do sistema
gerenciado
• interfaces (mib-2.2): gerenciamento das interfaces do
sistema
• ip (mib-2.4): para gerenciamento a nível IP
• icmp (mib-2.5): objetos relativos ao protocolo ICMP
• tcp (mib-2.6): para gerenciamento de conexões TCP
• udp (mib-2.7): para gerenciamento de transmissões UDP
• snmp (mib-2.10): para gerenciamento do próprio SNMP
SMI


SMI - Structure of Management Information
• Conjunto de regras que define como uma MIB é
especificada
• Definido na RFC1155
• Melhoramentos na RFC1212 e RFC1215
• Um arquivo de MIB usa a notação ASN.1 e as
regras SMI para definir os objetos da MIB
SMI define que cada objeto da MIB deve possuir:
• Um nome (OID) que identifica o objeto unicamente
• Uma sintaxe que identifica o tipo do objeto
• Uma codificação que descreve como as
informações serão transmitidas
Exemplo

MRTG
 Mib- Browser
Gerenciamento de Redes Plataformas de Gerenciamento


Pacote de software que fornece as
funcionalidades básicas de gerenciamento para
vários componentes diferentes de rede.
Objetivo: fornecer funcionalidades genéricas
para gerenciamento padrão dos vários
dispositivos.
• GUI
• Mapa da rede
• DBMS
• Método padrão de consulta aos dispositivos
• Menu de sistema programáveis
• Log de eventos
Gerenciamento de Redes Plataformas de Gerenciamento

Adicionalmente:
• Ferramentas gráficas
• API de programação
• Segurança do sistema de gerenciamento extra

Exemplos:
• NetManager (Sun)
• OpenView (HP)
• NetView (IBM)
• Unicenter TNG (Computer Associates)
Gerenciamento de Redes Arquiteturas de Gerenciamento

Arquitetura centralizada
• Todos os alertas e eventos centralizados
• Todas as informações de gerenciamento
centralizadas
• Todas as aplicações de gerenciamento
centralizadas
• Vantagens:
Detecção de problemas correlacionados
 Acessibilidade e segurança facilitadas

• Desvantagens:
Difícil expansão
 Tráfego carregado nas proximidades do gerente

Gerenciamento de Redes Arquiteturas de Gerenciamento

Arquitetura centralizada
NMS
Gerenciamento de Redes Arquiteturas de Gerenciamento

Arquitetura Hierárquica
•
•
•
•
•
•
Gerenciamento através de clientes e servidores
Não depende de apenas um sistema de gerenciamento
Tarefas de gerenciamento são distribuídas
A monitoração da rede é distribuída
Dados armazenados de forma centralizada
Vantagens:


Menor tráfego em um ponto específico
Clientes menos “pesados”
• Desvantagens:


Equipamentos gerenciados devem ser determinados
logicamente
Recuperação de informações mais lenta
Gerenciamento de Redes Arquiteturas de Gerenciamento

Arquitetura Hierárquica
NMS
Servidor
DBMS
NMS
Cliente
NMS
Cliente
Gerenciamento de Redes Arquiteturas de Gerenciamento

Arquitetura Distribuída
• Combina arquitetura centralizada com hierárquica
• Não depende de apenas um sistema de
gerenciamento
• Tarefas de gerenciamento são distribuídas
• O monitoramento é distribuído
• Dados, alertas e eventos são centralizados
• As aplicações são centralizadas
Gerenciamento de Redes Arquiteturas de Gerenciamento

Arquitetura Distribuída
DBMS
DBMS
NMS
NMS
DBMS
NMS
Gerenciamento de Redes Aplicações de Gerenciamento
Aplicação
1
Aplicação
2
...
Aplicação
N
Plataforma de Gerenciamento
Gerenciamento de Redes Aplicações de Gerenciamento




Para gerenciamento específico de dispositivos
Devem evitar duplicações de funcionalidades
com a plataforma de gerenciamento
Integração através de APIs e menu do sistema da
plataforma
Integrar-se a várias plataformas de
gerenciamento
Gerenciamento de Redes Sistemas de Gerenciamento

Como escolher um sistema de gerenciamento?
• Sistema = Plataforma + Aplicações
• Passos na escolha do sistema
1. Inventário dos dispositivos gerenciáveis da rede
2. Determinar a área funcional do gerenciamento
3. Escolher as aplicações de gerenciamento para os
dispositivos
4. Escolher a plataforma de gerenciamento de acordo com
as aplicações selecionadas
RMON - Gerenciamento por
Polling


Para um gerenciamento adequado, o gerente da
rede deve coletar dados importantes
freqüentemente
• Uso de polling
• Intervalos muito grandes trazem imprecisões
• Intervalos muito pequenos trazem
congestionamento
Encontrar um intervalo ótimo é muito difícil
porque depende-se de muitas variáveis
• Carga normal da rede
• Carga alterada em horários de pico
• Natureza das aplicações
RMON - Gerenciamento de
Segmentos Locais

Cada segmento Ethernet utiliza CSMA/CD na
transmissão
• Colisões podem ocorrer
• Todos os dispositivos recebem os quadros
transmitidos
• O nível de rede apenas recebe dados se:
O nível de enlace for o destino
 O nível de enlace aceitar pacotes de multicast
apropriados
 O nível de enlace aceitar pacotes de multicast mapeados
inadequadamente
 O nível de enlace receber pacotes de broadcast
 O nível de enlace estiver operando em modo promíscuo

RMON - Gerenciamento de
Segmentos Locais

Se a estação de gerenciamento se encontrar na
própria Ethernet gerenciada, não há a
necessidade de pooling
• A estação de gerenciamento apenas precisa
processar os quadros do segmento
• Colocar a interface Ethernet em modo promíscuo
• O nível de rede aceitará todos os pacotes mas
descartará os não apropriados
• Logo, deve-se ter um nível de rede também em
modo promíscuo
RMON - Segmentos
Remotos

Mas como fazer se a estação de gerenciamento
não fizer parte do mesmo segmento gerenciado?
• A estação sempre fará parte de pelo menos um
segmento, para conectá-la a rede gerenciada
• O tráfego total de segmentos remotos só é visto
pelos dispositivos daquele segmento
• Solução: introduzir em cada segmento remoto um
coletor de dados que se comunica com a estação
de gerenciamento da rede
• Nome deste coletor: Probe RMON
RMON - Probes RMON

Um probe RMON possui pelo menos uma
interface Ethernet para um segmento a ser
gerenciado
 A interface Ethernet do probe opera em
modo promíscuo, processando todos os
pacotes do segmento
 Um mesmo probe pode possuir várias
interfaces, para processar informações de
vários segmentos ao mesmo tempo
 Cada segmento corresponde a uma
interface do probe
RMON - Probes RMON



O probe coleta e processa as informações dos
segmentos e comunica-se com a(s) estação(ões)
de gerenciamento através de SNMP (v1, v2 ou v3)
Cada probe é então um agente SNMP especial,
que implementa uma MIB para gerenciamento
global de segmentos
A MIB-II é suportada no probe para o
gerenciamento do próprio, mais suporte à MIB
RMON para gerenciamento do segmento
RMON - Probes RMON

Um probe RMON pode ser encontrado em várias
formas
• Micro padrão colocado na rede local para capturar
os quadros usando placas Ethernet comuns em
modo promíscuo
• Equipamento dedicado colocado na rede local
com placas Ethernet especiais
• Internamente a hubs inteligentes
O hub deve possuir capacidade de processamento de
pacotes até o nível de aplicação!!!
 O hub deve possuir um endereço IP!!!
 O processamento realizado não deve influir na carga de
rede

RMON - Probes RMON
• Internamente em pontes (bridges) utilizadas para
segmentar ou isolar domínios de colisão
• Internamente em switches inteligentes
O switch deve processar pacotes até o nível de
aplicação
 Deve possui um endereço IP
 O processamento interno não deve afetar a capacidade
de switching

• Ligado diretamente a portas de hubs e switches
Em hubs faz parte da rede local simplesmente
 Em switches, deve ser configurado para interferir no
comportamento da interface Ethernet do switch, de modo
a receber todos os quadros do segmento

RMON - MIB RMON



A MIB-II permite o gerenciamento de objetos
relativos a dispositivos em particular
Implementar apenas a MIB-II em um probe RMON
permitiria o gerenciamento apenas do probe em
si, mas não do segmento
Como a MIB-II não possui objetos que descrevam
parâmetros dos segmentos, necessita-se de uma
MIB específica para essa funcionalidade: a MIB
RMON
RMON - MIB RMON



Assim, um probe RMON é capaz de comunicar à estação de
gerenciamento da rede parâmetros de um segmento
devolvendo objetos da MIB RMON
Um probe é estritamente um agente SNMP que implementa,
além da MIB-II, a MIN RMON
Não existe nenhuma mudança formal nas entidades do
gerenciamento padrão. Apenas tem-se uma nova MIB:
• Gerente da rede global => gerente
• Protocolos de gerenciamento => SNMP (v1, v2 ou v3)
• Dispositivos dos segmentos => agentes
• Probe RMON => agente
• Bases de informação => MIB-II e MIB-RMON
RMON - MIB RMON



Estruturalmente tem-se um agente mais
especializado.
• Conceito estendido deste agente: gerente
intermediário
Definido na RFC1271, posteriormente foi revisto
na RFC1757
Principais objetivos das definições:
• Operação offline
• Monitoração preemptiva
• Detecção e divulgação de problemas
• Dados de valor agregado
• Múltiplos gerentes