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
Como avisar ao gerente que o enlace da
Ex.:
corporação caiu?
• Gerenciamento de Configuração
Quais os roteadores da rede devem sofrer
Ex.:
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
Roteadores
Hubs
Estação de
Switches Impressoras
Gerenciamento
Hosts
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
Solicitações
Processo Gerente Processo Agente
Respostas
Base de Notificações Base de
dados dados
Rede
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
Mensagem ICMP
IP
20 bytes
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
Aplicação de Objetos
Gerenciamento Gerenciados
Resposta
Resposta
Get-Next
Get-Next
Trap
Trap
Set
Set
Get
Get
Mensagens SNMP
Gerente SNMP Agente SNMP
UDP UDP
IP IP
Enlace Enlace
Físico Físico
Rede
SNMP
SNMP - Aplicação
Apresentação
Sessão
UDP - Transporte
IP - Rede
Local Local
IP UDP
Network
Header Header Mensagem SNMP Network
Header Trailer
Datagrama UDP
Datagrama IP
Quadro no nível de enlace
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
Comu- PDU GetRequest, GetNextRequest,
Versão
nidade GetResponse ou SetRequest
Tipo Status Índice
Request Objeto 1, Objeto 2,
de de do ...
ID Valor 1 Valor 2
PDU Erro Erro
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 objeto-
valor, 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 B
Browser C
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(2)
Nodo(1) Nodo(2)
Objeto(1) 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
DBMS Servidor 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 Aplicação Aplicação
1 2 ... 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