Prova de Gerência de redes


Data: 03/09/99

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 octetos
· 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
Seriam analisados os objetos acima na máquina B, porque é um switch e
possui agentes RMON que forneceriam informações sobre a parte da rede
até o HUB.
Também seria necessário analisar a máquina C, por que é um HUB e possui
agente SNMP que forneceria atravéz dos objetos do grupo de estatística
informações sobre o tráfego no segmento pertencente àquele HUB.

Nota 4


Data: 03/09/99 Hora: 17:12 Máquina: 200.248.40.130

Nome : Henrique Oliveira da Silva
Endereco : 4

Nota 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:

Nota 4

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:

Nota 4


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:

Assim poderia analisar o trafego da rede utilizando os objetos acima e agentes RMON (como estatisticas e historia) na maquina B (switch) que poderia controlar todas as portas da rede e verificar o padrao de trafego em uma rede local. A primeira impressao seria usar o Roteador, porem este nao pode interagir com agentes RMON alem de nao conseguir alterar os pacotes por tratarem com enderecos MAC.
 
Nota 3

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:

Com estas informações posso tirar conclusões sobre o tráfego da rede.

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.

Fazendo-se uma média dos dados obtidos a partir destes objetos gerenciados em cada porta do switch, pode-se ter uma idéia da rede como um todo, tipos de pacotes trafegando, quantidade de pacotes, nível de colisões e taxa de utilização da rede.

Grupo Interfaces MIB-II:

Estas informações também podem auxiliar na estimativa de pacotes com erros, juntamente com o objeto EtherStatsCRCAlignErrors do RMON.

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;

Nota 3

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:

Com estas médias poderia se fazer a relação de pacotes descartados em relação ao total de pacotes que tra- fegavem no momento em que se realizou as tomadas de tempo. Poderia verificar assim qual o percentual de pacotes unicast e broadcast que estão trafegando na rede. Também poderia se analisar através destes objetos citados acima quais portas estariam com um maior trafego de pacotes e com erros. Desta maneira estaria monitorando o tráfego entre as entações e o roteador. Obs.: Minha máquina trancou e perdi uma parte das explicações.( A Liliane foi usar a máquina )

Nota 3,5