Data: 03/09/99 Hora: 17:02 Máquina: 200.248.40.130
Nome : Giovanni Ely Rocco
Endereco : 4
opiniao :
Investigaria os objetos RMON do Grupo Host na Máquina B (switch
com RMON).
Os agentes RMON permitem coletar de dados e acumular estatísticas
(necessário para a análise do padrão de tráfego
da rede local).
O Grupo Host provê estatísticas de tráfego para
cada nó da rede, mantendo uma lista de endereços MAC de origem
e destino dos Host da rede, observando os pacotes da rede de forma promíscua.
Nota 3
Data: 03/09/99 Hora: 17:08 Máquina: 200.248.40.130
Nome : Marcelo Faoro de Abreu
Endereco : 4
opiniao :
Para conhecer o padrão de tráfego da rede acima eu investigaria,
na máquina B, os seguintes objetos:
· etherStatsOctets, para observar as estatísticas de octetosSeriam analisados os objetos acima na máquina B, porque é um switch e
· etherStatsPkts, para observar a quantidade de pacotes que trafegam
· etherStatsUndersizePkts, para ver quantos pacotes possuem tamanho inferior ao mínimo
· etherStatsOversizePkts, para ver quantos pcts possuem tamanho exessivo
· etherStatsCollision, para analisar a quantidade de colisões
· hostOutBroadcastPkts, para analisar a quantidade de Broadcasts
· hostOutMulticastPkts, para verificar a quantidade de Multicasts
Nota 4
Data: 03/09/99 Hora: 17:12 Máquina: 200.248.40.130
Nome : Henrique Oliveira da Silva
Endereco : 4
Data: 03/09/99 Hora: 17:19 Máquina: 200.248.40.130
Nome : Rogerio Tessari
Endereco : 4
opiniao : Eu investigaria o switch A com que contem o agente
RMON, pois através dele é permitido investigar todo o tráfego
entre os dois domínios de subredes locais, bem como o status do
Hub e do Roteador, visto que o agente RMON pode se comunicar com os respectivos
agentes SNMP destas máquinas. Com o grupo Protocol Distribution
da MIB RMON (ProtocolDist) seria possível levantar estatísticas
quanto ao número de octetos e pacotes recebidos para cada protocolo
suportado, permitindo assim um bom detalhamento do tráfego, pois
desta forma podemos obter informações de qualquer protocolo
configurado no probe e não só os IP e/ou TCP.
Nota 3
Data: 03/09/99 Hora: 17:25 Máquina: 200.248.40.130
Nome : Ricardo Augusto Manfredini
Endereco : 4
opiniao :
Para conhecer os padrões de tráfego, eu utilizaria os
objetos rmon
do switch B, com o grupo de objetos Host (hostOutPkts , hostOutErrors,
etc)
poderia identificar o tráfego entre os segmentos, por exemplo
determinar se
o segmento de rede ligado ao hub C esta gerado muito tráfego
e assim poder
tirar alguma estação do hub e conectada-la diretamente
a uma porta do switch.
Utilizando ainda o grupo de objetos Protocol poderia descobrir que
que tipos de pacotes estão circulando por cada segmento.
Ainda com os objetos History poderia armazenar informações
históricas
sobre o segmento de rede(número de colisões - etherHistoryCollisions,
pacotes com erros de CRC- etherHistoryCRCAlignErrors, etc), podendo
montar
estatística de erros por pacotes transmitidos,por exemplo.
Através dos grupos Event e Alarm eu geraria alarmes sempre que
um algum
evento monitorado ultapassa-se algum valor histórico,por exemplo
o número de
colisões ultapassa a valor de etherHistoryCollisions é
acionado o alarme
alarmRisingThreshold, que tem como valor máximo de colisões
aceitáveis o
valor de etherHistoryCollisions, e dispararia um evento que geraria
um trap
para o administrador da rede.
Nota 4
Data: 03/09/99 Hora: 17:26 Máquina: 200.248.40.130
Nome : Elisa Terezinha Machado
Endereco : 4
opiniao : Investigaria a máquina B,switch com Rmon. Parti
do pressuposto que as máquinas existentes podem ser servidores.
Os objetos gerenciáveis que seriam investigados são:
Data: 03/09/99 Hora: 17:26 Máquina: 200.248.40.130
Nome : Cristiane Pinheiro Almeron
Endereco :
opiniao : No switch, que é um agente RMON, eu investigaria
os objetos hostControlTable e hostTable, no grupo Host, para obter os contadores
dos tipos de tráfegos.
Também utilizaria o grupo Statistics para colher dados de cada
interface monitorada, como por exemplo, CRC, colisões e tamanhos
de pacotes diferentes. Ainda no switch, eu olharia o grupo Matrix, para
conhecer a quantidade de tráfego e os erros.
Já no Hub, que é um agente SNMP, eu olharia em cada um
dos grupos (IP, TCP,...) o número de datagramas recebidos e enviados,
para conhecer qual é o protocolo mais utilizado, qual é a
sua taxa de transmissão, erros,...
Além disso, eu utilizaria o ethload, no Hub e no roteador, para
obter maiores informações quanto ao tráfego.
Nota 3
Data: 03/09/99 Hora: 17:28 Máquina: 200.248.40.130
Nome : Claudia Butignol
Endereco : 3
opiniao :
Eu faria a analise do trafego da rede atraves da monitoracao do switch com agente RMON.
Utilizaria para isso os grupos:
Statistics - que fornece dados a respeito do volume e tipos de pacotes que estao trafegando na rede analisada. Com isso podemos ter uma ideia de como esta a utilizacao da banda, atraves do total de colisoes, pacotes transmitidos ok,fragmentados. Com o objeto etherStatsBroadcastPkts podemos verificar a quantidade de pacotes bons direcionados para o endereço broadcast. Assim é possível verificar o volume de tráfego broadcast no segmento ethernet analisado e através desta informação podemos detectar possíveis broadcast storm, nesse caso é importante verificar o período que isso ocorre, com que freqüência, com carga leve ou carga baixa.
Host - usado para obter estatísticas sobre servidores específicos da LAN. O monitor aprende sobre novos hosts da LAN observando a origem e o destino do endereço MAC dos pacotes. Um conjunto de estatísticas é mantido para cada Host conhecido. Com isso podemos verificar onde estao os gargalos na rede.
Filter - instruir um monitor para observar pacotes específicos em uma interface. Assim seria interessante monitorar determinados pacotes como por exemplo os broadcast.
Nota 4
Data: 03/09/99 Hora: 17:30 Máquina: 200.248.40.130
Nome : Lia Cláudia Matté
Endereco : 4
opiniao : Eu faria minha investigacao na maquina B, porque nesta
maquina eu consigo observar tanto o trafego que entra na rede como o trafego
interno. Dentro do switch com RMON eu observaria os seguintes objetos gerenciados:
EtherStatsTable para identificar quais as interface que mais possuem tráfego,
e daquelas mais utilizadas examinaria o tamanho dos pacotes que trafegam
por ela, e se são multicast ou broadcast. Com essa observacao teria
uma ideia geral de que tipo de pacotes trafegam pela rede;
Com a hostTable identificaria quais os host utilizados, e em hostEntry
conseguiria verificar o número de pacotes que entram, que saem,
os pacotes com erros, o tamanho medio dos pacotes. Assim identificaria
quais os hosts mais utilizados, e que tipo de servico eles oferecem;
Sabendo quais os hosts mais utilizados poderia utilizar os objetos
do grupo matrix para identificar quais os dispositivos que utilizam mais
determinados host, esta estatística de tráfego pode ser feita
através da tabela matrixSDTable.
A partir desta visão geral eu conseguiria ter uma idéia
inicial do tipo de pacote que trafega na rede e quem mais os utiliza.
Nota 4
Data: 03/09/99 Hora: 17:32 Máquina: 200.248.40.130
Nome : Silvio Fernando Angonese
Endereco : 4
opiniao : Eu investigaria o Switch ( Máquina B )pois
ele possui um agente RMON que está armazenando as estatísticas
de tráfego de toda a rede em análise. Utilizaria o software
de gerenciamento de redes Mib-Browser , a MIB RMON, e analisaria no grupo
Statistics os seguintes Objetos:
Data: 03/09/99 Hora: 17:32 Máquina: 200.248.40.130
Nome : Cristina Cemin
Endereco :
opiniao : Eu investigaria a máquina B por possuir um
agente RMON e utilizaria os seguintes grupos: STATISCS : porque dá
estatísticas de CRC, colisões e tamanhos de pacotes diferentes.
Assim poderia determinar, por exemplo, um nro máximo de colisões
permitidas e quando ultrapassasse esse limite disparava um evento que soasse
um alarme para avisar que o limite de colisões foi ultrapassada
(Uso do Grupo Alarm que defini um conjunto de entradas para performance
de rede. Se um limite é alcançado, um alarme é gerado
e enviado para o console ] central). HOST : porque eu conseguiria obter
estatísticas sobre servidores específicos da LAN,observando
a origem e o destino do endereço MAC dos pacotes, mantendo assim
um conjunto de estatísticas para cada Host conhecido. HOSTTOPN :
utilizaria para manter estatísticas sobre o conjunto de hosts. Poderia
com isso manter uma lista que guardasse as estatísticas dos hosts
mais utilizados no horário de maior concetração da
rede. MATRIX: Usaria para conseguir informações sobre o tráfego
entre pares de hosts em uma subrede, onde a informação ficará
armazenada em uma matriz. Nesse grupo faria uso principalmente das seguintes
tabelas: - matrixSDTable: para armazenar estatísticas do tráfego
de um host de certa origem para suas destinações.
- matrixSDSourceAddress: para conseguir o endereço MAC de origem.
- matrixSDDestAddress: para conseguir o endereço MAC de destino.
Nota 4
Data: 03/09/99 Hora: 17:36 Máquina: 200.248.40.130
Nome : Taís Adriana Citton
Endereco : 4
opiniao :
Sendo o A um roteador e B um Switch com RMON, eu investigaria
a máquina B, pois com o RMON no switch ele tem condições
de monitorar
todo o tráfego da rede.
Utilizaria como ferramenta de auxilio para monitorar,o Mib Browser
que vimos em aula. Alguns grupos que analisaria dentro do Mib Browser:
--> Statistics: contém estatísticas básicas para
cada sub-rede monitorada,
e permite estatísticas para analisar colisões e tamanho
de pacotes
diferentes.
--> History:utilizado para definir funções de amostras
de uma ou mais
interfaces monitoradas. Consistindo de duas tabelas:
historyControlTable, que especifica a interface e os detalhes da
função e etherHistoryTable, onde os dados são
gravados.
--> Alarm:usado para definir um conjunto de entradas para performance
de rede. Consiste da tabela alarmTable, onde cada entrada especifica
uma variável para ser monitorada, guardando os valores mais
recentes.
--> Host:utilizado para obter estatísticas sobre servidores
específicos da LAN.
O monitor aprende sobre novos hosts da LAN observando a origem e o
destino do
endereço MAC dos pacotes. Um conjunto de estatísticas
é mantido para cada Host
conhecido.
--> Matrix: usado para reaver informações específicas,
como quais dispositivos
fazem mais uso de um servidor.
--> Event: consiste de uma tabela Controle e uma de Dados. A tabela
Controle,
eventTable, contém definições de eventos. Cada
registro dessa tabela contém
os parâmetros que descrevem um evento para ser gerado quando
certas condições
são alcançadas.
Dentro de cada um destes grupos citados anteriormente, analisaria ainda
os objetos
mais importantes dentro de cada um dos grupos.
Nota 4
Data: 03/09/99 Hora: 17:38 Máquina: 200.248.40.130
Nome : Joacir Giaretta
Endereco : 3
opiniao : Eu investigaria a máquina C (switch c/RMON).
A escolha deste objeto se deve ao fato do RMON possuir algumas caracterísitcas
importantes: Operação off-line, motinoração
pró-ativa, detecção e relato de problemas e dados
de valor adicionado. É possível investigar vários
aspectos da rede nos vários grupos do RMON. No grupo estatísticas
podemos ter várias estatísticas de erros, como colisões,
undersize e oversize, além de estatísticas sobre os pacotes:
quais são broadcast, multicast, quantos pacotes ruins, quantos foram
descartados pelo agente, podendo saber por exemplo se exite alguma situação
de Broadcast Storm. Poderia-se utilizar o grupo Alarme para determinar
limiares que serão comparadas com amostragens de variáveis
selecionadas, e se forem ultrapassadas geram eventos de informação.
O grupo Host pode ser usado para obter estatísticas sobre servidores
específicos da rede, mostrando estatísticas diversas dos
vários tipos de tráfego existentes, sendo muito útil
no gerenciamento de configuração. Outros grupos existem para
nos fornecer informações diversas sobre a situação
da rede e ajudar na resolução de problemas.
Nota 3,5
Data: 03/09/99 Hora: 17:38 Máquina: 200.248.40.130
Nome : Cristina Cemin
Endereco : 4
opiniao : Eu investigaria a máquina B por possuir um
agente RMON e utilizaria os seguintes grupos: STATISCS : porque dá
estatísticas de CRC, colisões e tamanhos de pacotes diferentes.
Assim poderia determinar, por exemplo, um nro máximo de colisões
permitidas e quando ultrapassasse esse limite disparava um evento que soasse
um alarme para avisar que o limite de colisões foi ultrapassada
(Uso do Grupo Alarm que defini um conjunto de entradas para performance
de rede. Se um limite é alcançado, um alarme é gerado
e enviado para o console ] central). HOST : porque eu conseguiria obter
estatísticas sobre servidores específicos da LAN,observando
a origem e o destino do endereço MAC dos pacotes, mantendo assim
um conjunto de estatísticas para cada Host conhecido. HOSTTOPN :
utilizaria para manter estatísticas sobre o conjunto de hosts. Poderia
com isso manter uma lista que guardasse as estatísticas dos hosts
mais utilizados no horário de maior concetração da
rede. MATRIX: Usaria para conseguir informações sobre o tráfego
entre pares de hosts em uma subrede, onde a informação ficará
armazenada em uma matriz. Nesse grupo faria uso principalmente das seguintes
tabelas: - matrixSDTable: para armazenar estatísticas do tráfego
de um host de certa origem para suas destinações. - matrixSDSourceAddress:
para conseguir o endereço MAC de origem. - matrixSDDestAddress:
para conseguir o endereço MAC de destino.
Nota 4
Data: 03/09/99 Hora: 17:39 Máquina: 200.248.40.130
Nome : Alessandro Boeira dos Reis
Endereco : 5
opiniao : Conforme a figura acima, os
objetos gerenciados seriam:
Data: 03/09/99 Hora: 17:40 Máquina: 200.248.40.130
Nome : Daniel Antonio Faccin
Endereco : 4
opiniao : Investigaria o Switch (B). O agente RMON, colocado
sobre o Switch que é o responsável pelo tráfego de
toda a informação na rede, permite também o monitoramento
de objetos não gerenciáveis. O tráfego de entrada/saída
também ocorrerá de forma constante sobre a máquina
B.Os objetos que poderiam ser utilizados para isso seriam: ifDescr, ifType,
ifMTU, ifSpeed, ifAdminStatus, ifTable, ifEntry, ifNumber. Utilizando outros
grupos de agentes RMON pode-se executar continuamente diagnósticos
e verificar a situação da rede em termos de carga, problemas,
monitorar protocolos e gerenciar os acessos. Mesmo Off-line, são
armazenadas estatísticas que ficarão disponíveis para
serem repassadas ao gerente posteriormente. Essas características
permitem que o gerenciamento sobre a rede e seus componentes seja mais
completo.
Nota 3
Data: 03/09/99 Hora: 17:41 Máquina: 200.248.40.130
Nome : Eliseu Dewes
Endereco : 3
opiniao : b) SWITCH - RMON - Objetos que investiguem pacotes
com erro, número de colisões, tamanho de pacotes Alguns exemplos
de Objetos por GRUPO: STATISTICS Através da variável etherStatsOctets
pode-se identificar a interface com o maior volume de tráfego ALARM
E EVENTS rmon.alarm.alarmTable.alarmEntry.alarmIndex rmon.alarm.alarmTable.alarmEntry.alarmInterval
rmon.alarm.alarmTable.alarmEntry.alarmVariable rmon.alarm.alarmTable.alarmEntry.alarmStatus
HOSTS Identificação do volume de tráfego rmon.hosts.hostTable.hostEntry.hostAddress
rmon.hosts.hostTable.hostEntry.hostInOctets rmon.hosts.hostTable.hostEntry.hostOutOctets
MATRIX Identificação qual máquina estabeleceu conexão
com quais hosts da rede rmon.matrix.matrixSDTable.matrixSDEntry.matrixSDSourceAddress
Nota 3,5
Data: 03/09/99 Hora: 17:42 Máquina: 200.248.40.130
Nome : Eliseu Dewes
Endereco : 3
opiniao : b) SWITCH - RMON - Objetos que investiguem pacotes
com erro, número de colisões, tamanho de pacotes Alguns exemplos
de Objetos por GRUPO: STATISTICS Através da variável etherStatsOctets
pode-se identificar a interface com o maior volume de tráfego ALARM
E EVENTS rmon.alarm.alarmTable.alarmEntry.alarmIndex rmon.alarm.alarmTable.alarmEntry.alarmInterval
rmon.alarm.alarmTable.alarmEntry.alarmVariable rmon.alarm.alarmTable.alarmEntry.alarmStatus
HOSTS Identificação do volume de tráfego rmon.hosts.hostTable.hostEntry.hostAddress
rmon.hosts.hostTable.hostEntry.hostInOctets rmon.hosts.hostTable.hostEntry.hostOutOctets
MATRIX Identificação qual máquina estabeleceu conexão
com quais hosts da rede rmon.matrix.matrixSDTable.matrixSDEntry.matrixSDSourceAddress
Nota 3,5
Data: 03/09/99 Hora: 17:42 Máquina: 200.248.40.130
Nome : Cristina Cemin
Endereco : 4
opiniao : Eu investigaria a máquina B por possuir um
agente RMON e utilizaria os seguintes grupos: STATISCS : porque dá
estatísticas de CRC, colisões e tamanhos de pacotes diferentes.
Assim poderia determinar, por exemplo, um nro máximo de colisões
permitidas e quando ultrapassasse esse limite disparava um evento que soasse
um alarme para avisar que o limite de colisões foi ultrapassada
(Uso do Grupo Alarm que defini um conjunto de entradas para performance
de rede. Se um limite é alcançado, um alarme é gerado
e enviado para o console ] central). HOST : porque eu conseguiria obter
estatísticas sobre servidores específicos da LAN,observando
a origem e o destino do endereço MAC dos pacotes, mantendo assim
um conjunto de estatísticas para cada Host conhecido. HOSTTOPN :
utilizaria para manter estatísticas sobre o conjunto de hosts. Poderia
com isso manter uma lista que guardasse as estatísticas dos hosts
mais utilizados no horário de maior concetração da
rede. MATRIX: Usaria para conseguir informações sobre o tráfego
entre pares de hosts em uma subrede, onde a informação ficará
armazenada em uma matriz. Nesse grupo faria uso principalmente das seguintes
tabelas: - matrixSDTable: para armazenar estatísticas do tráfego
de um host de certa origem para suas destinações. - matrixSDSourceAddress:
para conseguir o endereço MAC de origem. - matrixSDDestAddress:
para conseguir o endereço MAC de destino.
Data: 03/09/99 Hora: 17:44 Máquina: 200.248.40.130
Nome : André Zampieri
Endereco : 3
opiniao : Investigaria o switch com RMON - máquina B.
Neste switch eu analisaria as informações dos seguintes objetos
do grupo Statistics. Este grupo fornece estatísticas de CRC, colisões
e tamanhos de pacotes diferentes. Estes são alguns objetos específicos
do grupo Statistics que seria analisado:
Nota 3,5
Data: 03/09/99 Hora: 17:45 Máquina: 200.248.40.130
Nome : Marilda Spindola Chiaramonte
Endereco : 4
opiniao : Na rede local mostrada acima, há uma possibilidade
de conhecer o padrão de tráfego através do monitoramento
do Swicth na máquina B. Este objeto gerenciado permite tráfego
de entrada e saída, assim pode-se observar pacotes enviados e recebidos,
taxas de erros, unicasts e broadcasts através do gerenciamento MIB-II
com o protocolo SNMP, que tem como função inspecionar a rede
fornecendo informações com dados sobre as entidades físicas
e lógicas. Neste caso o protocolo SNMP é bem suportado pela
rede, pois esta não é uma rede muito grande.
Sobre o objeto gerenciado haveria a necessidade de se fazer algumas
inquisões, verificando assim o padrão de resposta. O agente
SNMP facilita a comunicação entre o objeto gerenciado e a
aplicação gerenciadora, e as operações de get,
set e trap podem fornecer os atributos dos objetos(alterações
ou simples leituras destes atributos) e as ocorrências de eventos
entre estes objetos.
Os objetos da MIB-II são usados para nos fornecer informações
específicas dos dispositivos da rede, assim este gerenciador poderia
informar qual o sistema de operação dos dispositivos na rede,
como se apresenta a interface da rede com o meio físico, o mapeamento
de endereços IP em endereços físicos, os vários
protocolos suportados, os meios de transmissão além do status
do próprio protocolo SNMP.
Além da MIB-II com SNMP, poderíamos ter também
a presença de um agente RMON nesta máquina para prover informações
adicionais sobre possíveis objetos não gerenciáveis.
Algumas características do RMON permitem-nos diagnosticar a rede
quanto a valores de carga, seus problemas (tráfego lento, erros),
quais protocolos estão sendo executados e gerenciamento de acessos.
Nota 3
Data: 03/09/99 Hora: 17:45 Máquina: 200.248.40.130
Nome : André Zampieri
Endereco : 3
opiniao : Investigaria o switch com RMON - máquina B.
Neste switch eu analisaria as informações dos seguintes objetos
do grupo Statistics. Este grupo fornece estatísticas de CRC, colisões
e tamanhos de pacotes diferentes.
Estes são alguns objetos específicos do grupo Statistics que seria analisado:
* etherStatsOctets, para observar o número total de octetos de dados recebidos na rede
* etherStatsPkts, para obter informações do número total de pacotes recebidos
* etherStatsUndersizePkts, para obter informações sobre os pacotes menores de 64 octetos
* etherStatsOversizePkts, paraa obter informações de quantos pacotes são maiores de 1518 octetos
* etherStatsCollision, o número de colisões totais neste segmento ethernet
Com estas informações posso tirar conclusões sobre o tráfego da rede.
Data: 03/09/99 Hora: 17:48 Máquina: 200.248.40.130
Nome : Maximiliano Z. Pezzin
Endereco : 4
opiniao : Basicamente, na máquina A deve-se realizar
um controle a fim de se
determinar quais os principais tipos de dados da rede.
Na máquina A (roteador)
No grupo interfaces
ifinUnPckts - para saber qual é a taxa de unicast IN na rede
ifinNUnPckts - para saber qual é a taxa de nao unicast IN na
rede
ifOutUnPckts - para saber qual é a taxa de unicast OUT na rede
ifOutNUnPckts - para saber qual é a taxa de nao unicast OUT
na rede
ifinUnknowProtos - pois indica pacotes eliminados por problema de protocolo
ifSpeed - pois indica a banda em bits/s
ifInOctets e ifOutOctets - indicando o numero de octetos que trafegam
No grupo System
sysServices - indicaria quais os serviços estariam disponíveis
No grupo TCP
tcpActiveOpens - para saber quantas coneccões ativas TCP existem
tcpPassiveOpens - para saber quantas coneccões passivas TCP
existem
tcpCurrStab - para saber quantas coneccões estabelecidasTCP
existem
Na máquina B, o teste recai no tipo de dados que circula, os
tipos de conexao
e caracteristicas tipacas de acesso como tamanho, taxas de erro ...
Na máquina B (switch com rmon)
No grupo INTERFACES
filterpktdata - para descobrir a quantia de pacotes válidos
(dados)
filterpktdatamask - para definir quais pacotes serão analisados
No grupo ESTATISTICAS
etherstatspkts - número total de pacotes circulando (totais)
etherstatBroadcastsspkts - número pacotes circulando broadcast
etherstatMulticastsspkts - número pacotes circulando multicast
etherstatscolisions - detecta colisoes geradas (nao as dos outros)
etherstatspkts64octs - para descobrir o % por tamanho de pacote
(fazendo o ítem acima para todos os grupos pode-se saber qual
o percentual
de tamanhos diferentes 65-128, 129-259 entre outros ...)
etherstatsOversizepkts - número de pacotes maiores de 1518 oct.
(performance)
etherstatsUdnersizepkts - número de pacotes menores de 64 octetos
(warning)
etherstatsCRCAlignErros - pois possibilitará descobrir erros
No grupo HOST ----> (neste tempo é o tempo da tabela gerada)
hosttimeInpkts - para saber o numero de pacotes corretamente rx (neste
tempo)
hosttimeOutpkts - para saber o numero de pacotes corretamente tx (neste
tempo)
hosttimeInOctets - para saber o numero de pacotes corretamente rx (neste
tempo)
hosttimeOutOctets - para saber o numero de octetos corretamente tx
(neste tempo)
hosttimeOutErrors - para saber o numero de pacotes errados (neste tempo)
hosttimeOutBroadcastPkts - para saber o numero de pacotes corretamente
tx BroadCast (neste tempo)
hosttimeOutMulticastPkts - para saber o numero de pacotes corretamente
tx Multicast (neste tempo)
Na máquina C (HUB)
No grupo INTERFACES
ifInUcastPkts - descobrir o % de unicast recebido
ifOutUcastPkts - descobrir o % de unicast enviado
ifInNUcastPkts - descobrir o % de nao-unicast recebido
ifOutNucastPkts - descobrir o % de nao-unicast recebido
ifOutQlen - para saber como esta a fila de pacotes na saída
ifSpeed - para saber qual a velocidade da interface em Bits/s
Nota 4
Data: 03/09/99 Hora: 17:50 Máquina: 200.248.40.130
Nome : Alexandre Meneghetti
Endereco : 2
opiniao :
Os objetos gerenciados seriam investigados na máquina B, por
ela
possuir RMON. Alguns objetos utilizados seriam:
etherStatsPkts: montante de pacotes recebidos.
etherStatsBroadcastPkts: número de pacotes broadcast recebidos
corretamente.
etherStatsMulticastPkts: número de pacotes multicast recebidos
corretamente.
etherStatsCRCAlignErrors: pacotes entre 64 e 1518 octetos com erros
no FCS.
etherStatsUndersizePkts: pacotes recebidos com menos de 64 octetos.
etherStatsOversizePkts: pacotes recebidos com mais de 1518 octetos.
etherStatsCollisions: número total de colisões no segmento
ethernet.
Utilização dos objetos do grupo History associados ao
grupo statistics
para uma melhor visualização dos dados colhidos.
Nota 3
Data: 03/09/99 Hora: 17:54 Máquina: 200.248.40.130
Nome : Alessandra Cini
Endereco : 4
opiniao : Visto que na máquina B temos um agente RMON,
eu utilizaria o grupo Statistics da RMON MIB para monitorar esta máquina
e obter as estatísticas básicas de cada subrede.
Utilizaria também o grupo Host para obter estatísticas
sobre servidores específicos da rede, a partir da origem e o destino
do endereço MAC dos pacotes, sabendo assim, quais servidores estão
sendo mais acessados.
Também é muito importante utilizar o grupo Matrix para
obter informações sobre o tráfego entre os pares de
hosts da subrede, possibilitando saber quais dispositivos fazem mais uso
de um servidor.
Uma outra alternativa, ou uma complementação, é
utilizar o software Comtest NM Elite. Este software permite inspecionar
o tráfego da Rede e isolar problemas de desempenho. A multitarefa
do Comtest NM Elite permite capturar e registrar constantemente as estatísticas
da rede local, enquanto continua a realizar outras tarefas.
Nota 3,5
Data: 03/09/99 Hora: 17:56 Máquina: 200.248.40.130
Nome : Iraci Cristina da Silveira
Endereco : 4
opiniao : Como a questão é conhecer o padrão
de tráfego da rede local eu investigaria começando pela máquina
B - switch com RMON.O raciocínio empregado é começar
do geral para o detalhe. Somente o RMON permite focalizar todo tráfego
da rede . Já o SNMP permitiria analisar apenas o tráfego
destinado ao recurso em si. Com o RMON poderia iniciar pelo grupo history
para obter uma amostragem histórica da rede. Com ela poderia conhecer
os valores de etherhistorypkts, etherhistoryoctets, etherhistorybroadcastPkts,
etherhistorymulticastpkts e outros. Como são valores da tabela identificando
cada uma das interfaces poderia obter uma estatística de quais interfaces
estão mais ocupadas,tamanho dos pacotes, taxa de erro. Juntamente
com o grupo history usar objetos de statistcs, também com o intuito
de visão geral. A partir da visão geral e das informações
obtidas em cada interface, teria meios de começar a diminuir a análise,
ou seja, determinar focos menores para estudo.
Ainda com RMON utilizando os objetos do grupo host e hosttopn poderia
analisar cada nó da rede, podendo localizar os pontos de maior tráfego,
o que poderia levar a uma melhor análise da própria topologia
da rede e a identificar estações com problema. Os objetos
que dariam esta informação seriam:hostcontroltable,hosttimetable.
Detalhando mais um pouco poderia associar objetos do grupo MAtrix,
detalhando o tráfego entre 2 host localizados na análise
do parágrafo anterior. Teria ainda como ferramentas adicionais os
agentes SNMP que trariam informações somente a respeito do
tráfego relacionado ao roteador e ao hub (recursos que possuem o
agente).
Analisaria a performance através dos objetos IFinErroes,ifouterrors,
ifinoctets, ifinucastpkts, ifouucastpkts e outros do grupo interface. A
partir daí analisaria os protocolos através dos grupos IP,
TCP, ICMP, UDP,EGP,SNMP. Poderia identificar quais os protocolos ,serviços
ou funções do sistema que estariam gerando maior tráfego.
Nota 3
Data: 03/09/99 Hora: 17:59 Máquina: 200.248.40.130
Nome : Rogério Callegari
Endereco :
opiniao :
A partir da máquina B (switch com agente RMON) podemos definir
objetos para monitoração da rede utilizando os grupos
do RMON.
Através do grupo History pode-se analisar informações
sobre o segmento
de rede, como por exemplo os números de colisões (etherHistoryCollisions,
os pacotes com erros de CRC (etherHistoryCRCAlignErrors), entre outros.
Utilizando o grupo Event e Alart, este por sua vez requer o primeiro,
poderia gerar alarmes sempre que algum evento ultrapasse valor definido,
por exemplo o número de colisões ultrapassou o valor
do objeto etherHistoryCollisions,
neste caso é acionado o alarme (alarmRisingThreshold), este
por sua vez
tem um valor máximo de colisãos aceitáveis. Neste
caso o administrador
receberia um alarme. Dê acordo com o estudo realizado em sala
de aula,
existem uma vários objetos que poderiamos relacionar.
Nota 3
Data: 03/09/99 Hora: 18:01 Máquina: 200.248.40.130
Nome : Alex Fabio Pellin
Endereco : 4
opiniao : No agente SNMP do reteador (A) pode-se medir a quantidade
de
trafego que sai e entra na rede. Isso pode ser feito analisando-se
a variacao do contador de octetos que passam pela porta interna,
em uma determinada unidade de tempo.
ifInOctets para medir os dados que saem da rede, e ifOutOctets
para medir os dados que entram na rede (em octetos).
No agente SNMP C, é interessante verificar o trafego que entra
em cada uma das portas do HUB (ifInOctets). Isso significa que
a estacao que esta na ponta gerou estes dados. Por ser um HUB,
não é interessante medir a saida de dados para as estações,
pois
em todas as portas (com exceção da entrada) teremos a
mesma saída.
Outro dado relevante aqui é a medição do número
de pacotes Unicast
(ifInUCastPkts) e não-unicast (ifInNUCastPkts). Isso possibilita
verificar se alguma máquina está gerando muito trafego
não unicast.
Essa medição pode ser interessante quando se tem problemas
de
problemas de broadcast storm na rede.
Se se a medição feita foi na porta de comunicação
com o SWITCH,
medindo-se a quantidade de octetos na entrada (inInOctets)
pode-se concluir a respeito da quantidade de dados que entram
no segmento de rede(pode ser feito pelo SWITCH). Nesta porta,
pode-se tambem medir a quantidade de pacotes não-unicast que
entram e saem do segmento, permitindo conclusões sobre a origem
de possiveis broadcast.
O agente RMON B é o ponto ideal para se medir a utilização
da rede
como um todo. O objeto etherStatsOctets pode ser utilizado para
se fazer medições sobre a utilização da
rede ethernet com maior
precisão.
O objeto etherStatsCollisions é utilizado para se medir o número
de
colisões em segmento da rede. No nosso ambiente, o caso mais
crítico é o segmento que comunica com o HUB. No SWITCH,
se medirmos
o objeto etherStatsBroadcastPkts temos dados a respeito da quantidade
de broadcasts de cada segmento.
Nota 4
Data: 03/09/99 Hora: 18:07 Máquina: 200.248.40.130
Nome : Liliane de Fatima Giordano
Endereco : 4
opiniao : Para conhecer melhor o padrão de tráfego
da rede local mostrada na figura acho interessante investigar o Switch
com um agente RMON. Obtendo informações para dimensionar
o tráfego, verificar estatísticas e ate broadcast storm.
Utilizando os grupos statistics para detectar erros e problemas físicos,
hosts para analisar o tráfego recebido e enviado, verificando-se
problemas de performance, o grupo alarm caso ocorram valores que ultapassem
algum valor histórico, como o número de colisões e
o event para notificar algum evento monitorado.
Com o grupo matrix poderia verificar a comunicação, para
saber em qual parte da rede o tráfego esta mais congestionado.
Também poderia ser analisado no agente SNMP do Hub os grupos
IP, TCP para se saber a taxa de transmissão de datagramas enviados
e recebidos e o protocolo mais usado.
Nota 3,5
Data: 03/09/99 Hora: 18:09 Máquina: 200.248.40.130
Nome : Veronica Louroza Estivalet
Endereco : 4
opiniao : A máquina que investigaria e a B(Switch).Sabendo
que o switch
o equipamento que tem conectar os segmentos de rede locais
poderemos observar o trafego na rede.
Para obter informações sobre o tráfego e o desempenho
utilizaria
os objetos RMON com o grupo Host e Statistic. Controlando estes
dois grupos é possível monitorar os recursos e evitar
sobrecarga..
A utilização do grupo Alarms é útil para
monitorar qualquer informação
que apresente valor fora do intervalo definido. Desta forma o administrador
é avisado sobre qualquer alteração que possa ocorrer.
O mecanismo utilizado
para notificação do administrador é através
do grupo Events.
Utilizando estes grupos creio que podemos obter uma boa base de informações
sobre o funcionamento da rede, e definindo, quando necessário,
novas
alternativas para o seu funcionamento.
Nota 3
Data: 03/09/99 Hora: 18:20 Máquina: 200.248.40.130
Nome : Vander Ortigara
Endereco : 4
opiniao : Analisaria a máquina B (switch com RMON), pois
é um switch que está ligando os segmentos da rede local e
trabalha com RMON. Então é possível monitorar cada
porta do switch e obter os dados dos segmentos de rede, uma vez que os
agentes RMON conseguem medir a rede toda (neste caso o segmento todo ligado
a cada porta). Procuraria obter dados principalmente sobre quantidade de
pacotes trafegando na rede, tipos destes pacotes, velocidade média
da rede e pacotes com erros. Para isso, utilizaria os seguintes Objetos
Gerenciados: Grupo Statistics do RMON:
Com estas três informações, é possível
saber, dentre o número total de pacotes, qual a taxa de pacotes
Broadcast, de Multicast e também Unicast que circulam pela rede,
ou seja, estimativa do tipo de pacotes circulando.
Grupo Interfaces MIB-II:
Apenas lembrando que, assim como IfSpeed, a medida destes dois objetos deve ser tomada não apenas nas portas do switch, mas em todas as portas possíveis ou suficientes para se ter uma amostragem razoável, permitindo uma melhor estimativa destas taxas. Acredito que com estas informações seja possível se ter uma boa noção do padrão de tráfego nesta rede.
Data: 03/09/99 Hora: 18:22 Máquina: 200.248.40.130
Nome : Samuel Carrion
Endereco : 3
opiniao : Eu investigaria os opbjetos RMON do switch B. A escolha
do RMON foi pelo tipo de informação oferecida pelos seus
objetos, que eu considerei mais relevante para identificar o padrão
de tráfego do que a oferecida pelo SNMP. Além disso, o hub
possui o problema de acesso às estações conectadas
diretamente ao switch ( e por consequencia ao tráfego entre elas)
e o roteador perderia performance caso fosse colocado em modo promíscuo.
Basicamente os grupos Statistics e History foram considerados interessantes
para diagnosticar o tráfego. É possível verificar,
no grupo Statistics
Já o grupo History apresenta dados similares, coletados periodicamente
conforme definições na historyControlTable. O armazenamento
desses dados fica a cargo da tabela etherHistoryTable. A tabulação
destes dados pode oferecer informações como por exemplo horários
de pico de utilização, horários com taxas de erro
mais elevada e horários com maiores incidência de broadcast.
Nota 4
Data: 03/09/99 Hora: 18:26 Máquina: 200.248.40.130
Nome : Christian Zambenedetti
Endereco : 4
opiniao : Eu investigaria a máquina B que é um
switch com RMON pois ele fornece a capacidade para monitorar a rede e análise
dos dados para gerenciar aplicações que coletam informações
como estatísticas de segmento e tendências, análise
do padrão de tráfego, largura de banda usada e alarmes. Isto
reduz o trabalho da administração da rede e os custos com
a solução de problemas.
Também é possível manter um histórico destas tendências, que pode ser usado futuramente para identificar as tendências potenciais.
Outro ponto positivo do RMON é que com ele pode-se analisar sites remotos e solucionar problemas comuns, evitando o custo de uma viagem de técnicos no local. Como dentro de uma LAN o número de segmentos aumentam, há a necessidade de uma arquitetura que não deixe a banda ser muito ocupada com os pacotes echo.
Com RMON podemos evitar isso impondo limites de gets. Além dos aspectos acima, ainda podemos: - observar pacotes, capturar todos os pacotes que passem por um filtro ou apenas gravar estatísticas baseadas nos pacotes;
Data: 03/09/99 Hora: 18:26 Máquina: 200.248.40.130
Nome : Samuel Carrion
Endereco :
opiniao : Enviei a resposta de uma segunda máquina, pois
a primeira perdeu o acesso à rede após o teste objetivo.
Data: 03/09/99 Hora: 18:38 Máquina: 200.248.40.130
Nome : Ronald Lopes de Oliveira
Endereco : 4
opiniao : Inicialmente eu iria usar usar o grupo Interfaces
para verificar quais de interfaces e a velocidade suportada pela rede,
nas máquinas A e C, usando os objetos gerenciados ifType e ifSpeed.
Também seria interessante verificar nas máquinas ( A,B e C ) qual o status de operação das das portas, usando para isto o objeto ifOperStatus.
Após, através da máquina C,realizando duas amostras num intervalo de tempo iria verificar os seguintes objetos:
Nota 3,5