Bolıvar Rodrigues Lagos
Analise da Rede de Computadores do InstitutoFederal de Santa Catarina Campus Sao Jose
Sao Jose – SC
2016
Bolıvar Rodrigues Lagos
Analise da Rede de Computadores do InstitutoFederal de Santa Catarina Campus Sao Jose
Monografia apresentada a Coordenacao doCurso Superior de Tecnologia em Sistemasde Telecomunicacoes do Instituto Federal deSanta Catarina para a obtencao do diploma deTecnologo em Sistemas de Telecomunicacoes.
Orientador:
Prof. Odilson Tadeu Valle, Dr.
CURSO SUPERIOR DE TECNOLOGIA EM SISTEMAS DE TELECOMUNICACOES
INSTITUTO FEDERAL DE SANTA CATARINA
Sao Jose – SC
2016
Monografia sob o tıtulo “Analise da Rede de Computadores do Instituto Federal de Santa
Catarina campus Sao Jose”, defendida por Bolıvar Rodrigues Lagos e aprovada em 22 de
Agosto de 2016, em Sao Jose, Santa Catarina, pela banca examinadora assim constituıda:
Prof. Odilson Tadeu Valle, Dr.Orientador
Prof. Ederson Torresini, Me.IFSC
Prof. Marcelo Maia Sobral, Dr.IFSC
Agradecimentos
Gostaria de agradecer a todos que tornaram possıvel a conclusao desta monografia, em
especial ao meu orientador Odilson Tadeu Valle pela paciencia e dedicacao durante o desenvol-
vimento do trabalho.
Gostaria de agradecer tambem o pessoal da CTIC, por ceder o espaco para testes, em espe-
cial ao Ricardo Martins que acompanhou em diversos momentos.
Resumo
Testes de desempenho de equipamentos sao necessarios em redes de computadores, atravesde softwares de acesso livre e possıvel efetuar uma boa analise em uma rede local.
A presente monografia tem como intuito mostrar diversos testes de desempenho em equipa-mentos da rede do Instituto Federal de Santa Catarina (IFSC) campus Sao Jose, como se tratade um estudo de caso nao ha o desenvolvimento de uma aplicacao especifica e sim o estudocomportamental dos equipamentos.
Atraves da utilizacao de softwares geradores de trafego, como Ostinato e Iperf, pode-sesimular uma sobrecarga na rede afim de analisar o comportamento dos equipamentos envolvidosatraves do ARP Flooding. Testes de casos reais como o loop, visam verificar falhas humanasou de implementacao da infraestrutura da rede, o que pode acontecer durante a ampliacao oumanutencao da rede ou ate mesmo a troca de um patch cord.
Por ultimo o TCP Offload, que e um recurso da placa de rede, visa otimizar o trafego dedados em aplicacoes que utilizem o TCP como transporte de dados, segmentando os cabecalhosTCP durante o processamento dos pacotes.
Abstract
Performance tests in equipments are necessary in computer networks, through free softwa-res is possible to make a good analise in a local network.
This monograph has the intention to show several performance tests in equipaments fromIFSC, this is a equipment behavior case study, there is no aplication development.
Using traffic generators software like Ostinato and Iperf, we can simulate a overload of datain the network to analise equipament behavior through the ARP Flooding, real case tests likeswitch loop, that can happen during network expansion or even a network cable change. Lastlythe TCP Offload aims to increase data traffic for applications that use TCP as protocol.
Sumario
Lista de Figuras
Lista de Abreviaturas p. 10
1 Introducao p. 11
1.1 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 11
1.2 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 12
2 Fundamentacao Teorica p. 13
2.1 Metodologia dos testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 13
2.2 Gerenciamento de Redes . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 13
2.3 ARP e RARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 14
2.4 TOE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15
2.5 Geradores de Trafego . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 17
2.5.1 Ostinato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 17
2.5.2 Iperf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19
2.5.3 Jperf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 20
2.5.4 Dsniff e Macof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 22
2.6 Consideracoes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23
3 Analise da Rede de Computadores p. 24
3.1 Inventario dos Equipamentos . . . . . . . . . . . . . . . . . . . . . . . . . . p. 24
3.2 ARP Flooding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 29
3.3 Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 32
3.4 Sobrecarga de trafego . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 33
3.5 TCP offload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 35
4 Conclusoes p. 38
Referencias Bibliograficas p. 39
Lista de Figuras
2.1 Ciclo Gerenciamento de Rede (BUENO, 2012). . . . . . . . . . . . . . . . . p. 14
2.2 Protocolo Address Resolution Protocol (ARP) (FOROUZAN, 2008). . . . . . p. 15
2.3 TCP offload engine (10GEA, 2016). . . . . . . . . . . . . . . . . . . . . . . p. 16
2.4 Criacao do datagrama. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18
2.5 Mac origem e destino. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18
2.6 IP de origem e IP destino. . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18
2.7 Dados do campo payload. . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19
2.8 transmissao via pacotes ou rajadas. . . . . . . . . . . . . . . . . . . . . . . . p. 19
2.9 Iperf servidor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 20
2.10 Iperf cliente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 20
2.11 Graphical User Interface (GUI) Jperf (JPERF, 2001). . . . . . . . . . . . . . p. 21
2.12 Servidor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 21
2.13 tempo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 22
2.14 Velocidade da porta do switch. . . . . . . . . . . . . . . . . . . . . . . . . . p. 22
2.15 ARP Flooding com a ferramenta Macof. . . . . . . . . . . . . . . . . . . . . p. 23
3.1 Visao Geral da rede do IFSC. . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25
3.2 Inventario da Rede Nacional de Pesquisa (RNP). . . . . . . . . . . . . . . . p. 26
3.3 Laboratorio de redes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27
3.4 Sala Ctic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27
3.5 Desenvolvimento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 28
3.6 Sala CAD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 28
3.7 Cenario do ARP Flooding. . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30
3.8 Port Mirror. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30
3.9 Captura de pacotes com espelhamento de porta. . . . . . . . . . . . . . . . . p. 31
3.10 Captura de pacotes pelo host C. . . . . . . . . . . . . . . . . . . . . . . . . . p. 31
3.11 loop no Switch (ROGIER, 2016). . . . . . . . . . . . . . . . . . . . . . . . . p. 32
3.12 Ping de 4 Requests com destino broadcast . . . . . . . . . . . . . . . . . . . p. 33
3.13 Captura de pacotes pelo software Wireshark. . . . . . . . . . . . . . . . . . . p. 33
3.14 Ostinato configurado com 10 rajadas de 100 pacotes. . . . . . . . . . . . . . p. 34
3.15 trafego configurado em 700Mbps. . . . . . . . . . . . . . . . . . . . . . . . p. 34
3.16 Medicao da Bandwidth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 34
3.17 Captura dos pacotes enviados pelo Ostinato. . . . . . . . . . . . . . . . . . . p. 35
3.18 Recursos da Network Interface Card (NIC). . . . . . . . . . . . . . . . . . . p. 36
3.19 Segmento TCP sem campo Checksum. . . . . . . . . . . . . . . . . . . . . . p. 36
3.20 Sem offload. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 36
3.21 Com offload. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 37
10
Lista de Abreviaturas
IFSC Instituto Federal de Santa Catarina
MAC Media Access Control
TCP Transmission Control Protocol
UDP User Datagram Protocol
ARP Address Resolution Protocol
RARP Reverse Address Resolution Protocol
ICMP Internet Control Message Protocol
STP Spanning Tree Protocol
GNU Gnu is Not Unix
GPL General Public License
GUI Graphical User Interface
CLI Comand Line Interface
API Application Programming Interface
IP Internet Protocol
RNP Rede Nacional de Pesquisa
NIC Network Interface Card
NLANDR DAST National Laboratory for Applied Network Research/Distributed Applicati-
ons Support Team
TOE Tcp Offload Engine
11
1 Introducao
Para manter a integridade e um bom funcionamento dos equipamentos de uma rede local,
o monitoramento via software e altamente recomendado, isso permite que rapidamente seja
detectado algum problema de desempenho ou falha e corrigi-lo o mais breve possıvel. Devido
a alta quantidade de equipamentos conectados em uma rede local, ha a possibilidade de fazer
vistoria pessoalmente, porem, e muito trabalhoso, para isso existe software para monitorar o
trafego ou ate mesmo emitir alertas em casos mais crıticos, como quedas de enlace ou ausencia
de sinal.
Software de monitoramento sao praticamente ilimitados, existe uma infinidade de software
de acesso livre que podem auxiliar na execucao de testes e na melhora do desempenho da rede.
Pode-se tambem monitorar equipamentos ativos na rede, atraves de software graficos ou via
console.
O foco deste trabalho consiste em utilizar essas ferramentas, algumas ja disponıveis no
ambiente de rede do IFSC campus Sao Jose e faze-las trabalhar em conjunto com um soft-
ware gerador de trafego, coletando dados e informacoes dos equipamentos e monitorando seu
comportamento com esta alta carga de informacoes, atraves disso obtem-se resultados do com-
portamento desses equipamentos com uma carga maxima, e posteriormente, determinar o que
pode ser feito no caso de um desempenho ruim da rede.
Neste trabalho foi efetuado uma abordagem com estudo de caso sobre switchs gerenciaveis,
com a finalidade de mostrar o comportamento desses equipamentos ao aplicar-se uma sobre-
carga de trafego.
1.1 Motivacao
A estrutura de rede do IFSC campus Sao Jose, assim como de qualquer instituicao, seja ela
publica ou privada, esta sujeita a falhas, estas falhas podem ser humanas ou dos proprios equi-
pamentos. A medida que essa estrutura vai crescendo e a quantidade de usuarios aumentando,
1.2 Objetivo 12
a tendencia e aumentar o numero de falhas.
Juntamente com o crescimento da estrutura vem o problema financeiro, equipamentos de
rede e softwares possuem um custo muito elevado, seria muito mais simples se pudessemos
colocar os melhores equipamentos disponıveis no mercado e em quantidades ilimitadas, mas
esse e um recurso limitado pela instituicao, por esse motivo deve-se fazer um bom planejamento
ao implantar a rede, e um bom monitoramento da mesma para mante-la com um funcionamento
estavel.
Sabendo-se disso iremos utilizar os recursos disponıveis atualmente, equipamentos ja im-
plantados e software de monitoramento gratuito.
1.2 Objetivo
O objetivo desse trabalho e efetuar um estudo de caso sobre os equipamentos ativos da
rede do IFSC campus Sao Jose, esse estudo ira envolver a analise comportamental dos switchs
atraves de um serie de ensaios envolvendo a aplicacao de alto trafego nos equipamentos.
Atraves de um mapeamento da infraestrutura do IFSC, serao identificados os principais
equipamentos ativos atraves de um levantamento dos principais pontos conectados em cada
laboratorio e sala de aula. Esse levantamento e necessario para estimar quais pontos necessitam
mais atencao e justamente aplicar o trafego nesses pontos.
13
2 Fundamentacao Teorica
Neste capıtulo serao abordados alguns conceitos teoricos referentes a execucao do trabalho
bem como alguns dos protocolos envolvidos durante os ensaios praticos. Esses conceitos sao
necessarios para uma melhor compreensao do desenvolvimento do trabalho.
2.1 Metodologia dos testes
Para verificar como se comportam os switches em determinadas situacoes como por exem-
plo com a aplicacao de um alto trafego, diversos cenarios foram aplicados afim de testar o
desempenho dos mesmos.
Para isso e necessario seguir alguns passos:
• Protocolos Envolvidos : Estudo dos protocolos de camada de enlace.
• Software: Instalacao e configuracao dos softwares utilizados durante os testes.
• Ensaios: Realizacao dos testes praticos no ambiente do IFSC campus Sao Jose.
• Conclusoes: O que se determinou a partir dos testes.
2.2 Gerenciamento de Redes
(BUENO, 2012) diz que basicamente um monitoramento de rede opera sobre 3 pontos
principais como mostra a Figura 2.1, independente da estrutura ou do modelo adotado, esses
pontos sao:
• Coleta de dados (polling): Atraves de software aplicado em um hardware especifico,
geralmente um ativo de rede, informacoes sao enviadas em intervalos determinados por
um administrador ou no momento em que for solicitado.
2.3 ARP e RARP 14
• Analise: Apos coletados os dados enviados, as mensagens de notificacao sao analisadas
pelo software de gerenciamento.
• Acao: Apos a analise, se houver alguma falha, uma medida corretiva sera efetuada, ou
algum alerta sera acionado.
Figura 2.1: Ciclo Gerenciamento de Rede (BUENO, 2012).
2.3 ARP e RARP
Conforme (FOROUZAN, 2008) uma rede local e constituıda de equipamentos fısicos in-
terligados entre si, os hosts e roteadores sao reconhecidos por seus enderecos logicos chamados
de endereco Internet Protocol (IP), e enderecos fısicos chamados Media Access Control (MAC)
Address. O endereco IP e composto por 32 bits separados em 4 bytes, sendo cada byte repre-
sentado em sua forma decimal indo de 0 a 255. O MAC e composto por 48 bits separados em 6
bytes, cada byte representado na sua forma Hexadecimal de 00 a FF.
Para um datagrama ir de uma origem a um destino e preciso um endereco logico e um
fısico, um mapeamento de portas combina um endereco IP a um endereco MAC, ele pode ser
feito estatico ou dinamicamente, e geralmente e armazenado em uma tabela. O protocolo ARP
visa mapear dinamicamente essa tabela, composta por endereco IP e endereco MAC, sabendo
o endereco IP o protocolo consegue descobrir o endereco MAC associado e armazena-lo, o
Reverse Address Resolution Protocol (RARP) por sua vez atraves de um endereco MAC e capaz
de descobrir um endereco IP (FOROUZAN, 2008).
Para uma estacao descobrir o endereco fısico de outra, ela envia um pacote de consulta
ARP, que inclui endereco IP e MAC do remetente e o endereco IP do destino, o destinatario ira
retornar uma mensagem com o seu endereco MAC, conforme mostra a figura 2.2. Como esse
2.4 TOE 15
pacote de consulta e enviado em broadcast, todos os hosts conectados ao mesmo barramento re-
cebem essa mensagem, mas somente a maquina de destino retorna a mensagem (FOROUZAN,
2008).
Figura 2.2: Protocolo ARP (FOROUZAN, 2008).
2.4 TOE
Controladores ethernet estao experienciando grandes taxas de dados, que exigem muitos
recursos de hardware e software para processamento de pacotes. O protocolo TCP/IP consome
uma grande quantidade de processamento, o que pode provocar gargalos na rede quando houver
um trafego significativo, visto que o processador tambem precisa executar outras aplicacoes
simultaneamente (GUPTA ALLEN LIGHT, 2006).
O Tcp Offload Engine (TOE) foi desenvolvido para incrementar a transferencia de dados,
segmentando os cabecalhos TCP durante o processamento dos pacotes. O TOE permite que o
sistema operacional descarregue todo o trafego TCP para um hardware especializado no con-
trolador de rede NIC (GUPTA ALLEN LIGHT, 2006), isso pode ser observado na figura 2.3. O
TOE geralmente e utilizado em servidores, onde o processamento e o trafego de dados e mais
significativo do que hosts comuns.
2.5 Geradores de Trafego 17
2.5 Geradores de Trafego
Conforme (FILIPPETTI, 2009) geradores de trafego sao software que permitem o envio de
pacotes com dados a fim de testar a conectividade de um enlace, eles permitem que gerem-se
um fluxo de dados configuravel, com isso e possıvel efetuar testes para aplicacoes especificas.
Diversos software estao disponıveis para efetuar esses testes, muitos deles sao disponibili-
zados gratuitamente, e permitem geracao e transmissao de trafego via protocolo de transporte
User Datagram Protocol (UDP) e Transmission Control Protocol (TCP).
Os software utilizados durante a Realizacao dos ensaios foram:
• Ostinato ;
• Iperf;
• Jperf;
• Dsniff.
2.5.1 Ostinato
Licenciado pela Gnu is Not Unix (GNU) General Public License (GPL), Ostinato e um
software gerador de pacotes de rede e analisador, com uma GUI amigavel e uma poderosa
Application Programming Interface (API) em Python para testes em redes de computadores.
Cria e envia pacotes e bursts(rajadas contendo varios pacotes) para envio de dados e diferentes
taxas de transmissao (ORG, 2001).
O software Ostinato permite a criacao e configuracao de pacotes de dados para a maioria dos
protocolos, seu metodo de configuracao permite que tenha uma stream de dados com cabecalhos
ajustaveis, escolha do protocolo e ate mesmo definir os dados contidos no payload, o metodo
de envio de dados tambem e configuravel, sendo possıvel enviar pacotes ou rajadas.
Configuracao do Ostinato
Para envio de dados com o Ostinato deve-se primeiramente configurar alguns parametros
da criacao do datagrama, a figura 2.4 mostra a configuracao dos protocolos em cada camada.
2.5 Geradores de Trafego 18
Figura 2.4: Criacao do datagrama.
Como o envio de dados e para um destino especifico deve-se definir o endereco MAC de
origem e destino, figura 2.5.
Figura 2.5: Mac origem e destino.
Da mesma forma que o MAC, o IP de origem e destino tambem deve ser configurado, figura
2.6. E possıvel a configuracao do IP de destino ser o endereco de broadcast, nesse caso sera
transmitido para todas as portas.
Figura 2.6: IP de origem e IP destino.
A configuracao dos dados contidos no campo payload, figura 2.7, permite o preenchimento
do campo com valores em hexadecimal.
2.5 Geradores de Trafego 19
Figura 2.7: Dados do campo payload.
O software tambem permite a configuracao de envio de dados, pacotes ou rajadas, figura
2.8. No formato envio de pacotes, sao transmitidos os mesmos a uma taxa configuravel, da
mesma forma o formato rajadas, porem, com as rajadas contendo uma grande quantidade de
pacotes.
Figura 2.8: transmissao via pacotes ou rajadas.
2.5.2 Iperf
O Iperf e um software livre desenvolvido pelo National Laboratory for Applied Network
Research/Distributed Applications Support Team (NLANDR DAST) no inıcio da decada de
2000, sua principal caracterıstica consiste em simular o trafego de dados em redes de com-
putadores para testes de estresse e medicao de desempenho. Seu funcionamento baseia-se no
modelo cliente/servidor. O cliente envia uma requisicao de conexao especificando um endereco
IP ou o nome do servidor que estara escutando pedidos de requisicao. Assim que for estabe-
lecida a conexao, sera enviado datagramas do cliente para o servidor que pode ser escolhido
como protocolo de transporte tanto TCP quanto UDP, no caso do UDP nao ha a necessidade de
uma conexao, apenas e enviado de uma origem a um destino.(IPERF, 2001).
Alem de envio de dados, o Iperf faz a medicao da taxa de transmissao de dados entre o
cliente e o servidor, bem como informacoes sobre latencia e jitter.
2.5 Geradores de Trafego 20
Seu modelo de conexao e relativamente simples, um host cliente e um host servidor, pri-
meiramente o servidor deve ”escutar”pedidos de conexao em uma porta especifica, conforme
demonstra a figura 2.9, Iperf escutando conexoes na porta 5001, porta padrao definida pelo
proprio software, porem a mesma pode ser mudada pelo proprio usuario.
Figura 2.9: Iperf servidor.
No lado do cliente e necessario especificar o endereco IP do servidor a quem ira efetuar a
conexao, figura 2.9, multiplos hosts cliente podem conectar-se a um unico servidor.
Figura 2.10: Iperf cliente.
2.5.3 Jperf
Distribuıdo pela licenca Apache 2.0, Jperf e a Interface grafica do Iperf, para testes de
performance e escalabilidade, roda em Java e e totalmente compatıvel com o Comand Line
Interface (CLI) Iperf (JPERF, 2001).
2.5 Geradores de Trafego 21
Figura 2.11: GUI Jperf (JPERF, 2001).
Sua GUI permite um uso muito mais intuitivo do software, permitindo que o usuario confi-
gure parametros com apenas um clique ou inserindo valores em um certo campo. A figura 2.12
mostra a conexao do cliente Jperf em um servidor de IP 172.18.20.200 atraves da porta 5001.
Figura 2.12: Servidor.
Afim de medir a taxa de transmissao real da porta do switch um teste de 60 segundos foi
efetuado, figura 2.13 a porta do switch possui um valor nominal de 1 Gbps, porem, como pode
ser visto na figura 2.14 , a velocidade da porta chega a um valor proximo de 800 Mbps.
2.5 Geradores de Trafego 22
Figura 2.13: tempo.
A velocidade real da porta foi medida afim de determinar qual o valor em Mbps sera apli-
cado para efetuar a sobrecarga no switch.
Figura 2.14: Velocidade da porta do switch.
2.5.4 Dsniff e Macof
O software Macof e um utilitario que faz parte da suıte Dsniff, seu funcionamento consiste
em enviar milhares de requisicoes ARP com enderecos MAC falsos, para testes na tabela MAC
do switch, este software roda no sistema operacional Linux e pode ser instalado via gerenciador
de pacotes.
Apos instalado o Dsniff basta utilizar a ferramenta Macof para envio de requisicoes. O
software Macof trabalha enviando milhares de requisicoes ARP a um destino especifico, geral-
mente um switch, essas requisicoes contem enderecos MAC falsos e preenchem a tabela ARP
do switch com esses enderecos.
Para utilizacao do software Macof deve ser especificado a interface de saıda de dados, o IP
do host destino e a quantidade de pacotes a ser enviados, como mostra a figura 2.15.
2.6 Consideracoes Finais 23
Figura 2.15: ARP Flooding com a ferramenta Macof.
2.6 Consideracoes Finais
Os software apresentados acima compoe a base do trabalho, e sao amplamente utilizados
no decorrer da monografia, atraves deles sera efetuado diversos testes visando verificar o com-
portamento dos switches.
24
3 Analise da Rede de Computadores
Este capitulo consiste em apresentar os testes praticos que foram efetuados durante o desen-
volvimento do trabalho, bem como os resultados da analise efetuada. Para se fazer uma analise
de desempenho e funcionalidade de uma rede de computadores, em primeiro lugar deve-se fazer
o o inventario dos equipamentos que compoe a rede, objetivando conhece-la profundadamente.
Uma vez tendo-se ciencia da rede e identificando-se seus possıveis gargalos, deve-se proceder
testes de desempenho funcional nesses gargalos. Para isto, propomos os testes:
• ARP Flooding: Que tem por objetivo verificar a capacidade e responsividade de um
switch com o aumento exponencial de enderecos MAC;
• Loop: Testa a funcionalidade do STP e o comportamento do equipamento quando esse
esta com um loop ativo.
• Sobrecarga no trafego: Verifica se ha alguma perda de desempenho ou dados durante a
aplicacao de uma sobrecarga no trafego.
• TCP offload: Visa otimizar a taxa de transferencia de dados que utilizam protocolo TCP,
apos a analise do nucleo da rede realizaremos teste de desempenho entre hosts e servido-
res adotando essa tecnologia.
3.1 Inventario dos Equipamentos
Conhecer a rede a qual ira monitorar e o primeiro passo para efetuar uma melhor analise,
e importante saber onde estao os pontos mais crıticos ou com a maior concentracao de equi-
pamentos, a figura 3.1 mostra uma visao geral da interligacao dos Racks do IFSC, onde estao
concentrados os switchs que farao parte dos testes, durante a contabilizacao dos equipamen-
tos foram inclusos equipamentos ativos e passivos, porem, no desenho da rede apenas foram
inclusos os equipamentos ativos, somente nesses equipamentos foram efetuados os testes.
3.1 Inventario dos Equipamentos 25
Figura 3.1: Visao Geral da rede do IFSC.
O campus recebe um par de fibra otica de 10 Gbps da RNP da UFSC, sendo que uma delas
fica como redundancia e sao conectados no switch otico da sala RNP do IFSC campus Sao Jose.
A conexao entre os tres principais pontos do IFSC campus Sao Jose, como pode ser observado
na figura 3.1, possuem conexoes redundantes com link agregation e operam nesse enlace a 2
Gbps.
A sala RNP e o principal ponto, e onde esta concentrado a maior quantidade de equipa-
mentos, todo trafego de saıda para internet passa por este ponto, a sala dispoe de tres racks. O
primeiro rack possui um Switch otico para conexao da fibra fornecida pela RNP, o segundo rack
somente com ativos de rede, um firewall, seis Switchs gerenciaveis e sete servidores, o terceiro
rack somente com equipamentos passivos, dois patch panel(16 portas) e quatro patch panel(24
portas), o detalhamento desta sala pode ser observado na figura 3.2.
3.1 Inventario dos Equipamentos 26
Figura 3.2: Inventario da RNP.
Partindo da RNP a infra cobre os laboratorios de redes 1, 2, 3 e laboratorio instrumentacao,
divide-se em outros dois pontos principais, sala Ctic e laboratorio de desenvolvimento. Os
laboratorios de rede dividem-se em tres laboratorios, o primeiro contendo um rack com um
Switch e um patch panel, conforme figura 3.3, o laboratorio de redes 2 possui um rack com dois
Switchs e tres patch panel. O terceiro laboratorio de redes contendo um Switch e o laboratorio
de instrumentacao com um rack contendo dois Switchs e dois patch panel.
3.1 Inventario dos Equipamentos 27
Figura 3.3: Laboratorio de redes.
A sala da Ctic possui um rack com quatro switchs empilhados e um rack para passivos
contendo quatro patch panel, conforme mostra a figura 3.4, juntamente com a sala da secretaria
que possui apenas um pequeno rack com dois switchs.
Figura 3.4: Sala Ctic.
3.1 Inventario dos Equipamentos 28
O laboratorio de desenvolvimento tambem e um ponto importante, possui um rack com
cinco Switchs empilhados e quatro patch panel, figura 3.5.
Figura 3.5: Desenvolvimento.
Por fim, do laboratorio de desenvolvimento e interligado com os tres laboratorios de CAD,
figura 3.6.
Figura 3.6: Sala CAD.
3.2 ARP Flooding 29
A partir da analise e estudo da topologia da rede do IFSC campus Sao Jose foi definido os
principais pontos para aplicacao do trafego. Os tres pontos principais sao Sala RNP, Laboratorio
de desenvolvimento e CTIC, basicamente todo o trafego da rede passa por esses tres pontos.
Levando em conta a facilidade de acesso aos locais foram escolhidos a sala da CTIC e do RNP
como parametro para a aplicacao dos testes.
3.2 ARP Flooding
O ARP Flooding ou MAC Flooding e um teste em nıvel de camada de enlace que consiste
em enviar requisicoes ARP ao Switch. Switchs sao capazes de atrelar uma porta especıfica a um
endereco MAC do host a qual esta conectado, para um melhor desempenho o Switch armazena
esse endereco MAC em uma tabela, que fica armazenado na memoria do equipamento, esta
memoria, porem, possui um limite. O ARP Flooding consiste justamente em explorar esse
limite de memoria ao enviar milhares de requisicoes ARP com enderecos MAC falsos, dessa
maneira, ao enviar um pacote destinado a certo endereco MAC, o Switch ira acessar a tabela e
vera que ha outro endereco MAC armazenado, quando isso ocorre um pacote sera enviado a um
endereco de hardware desconhecido.
Ao efetuar o ARP Flooding temos duas possibilidades,
• Travamento do Switch: Ficara totalmente fora de operacao, comprometendo a rede ;
• Modo Failopen: O Switch ira abandonar o uso da tabela e se comportar como um hub,
quando ele nao sabe para qual destino enviar e apenas transmite pacotes para todas as
portas.
Ainda que hajam algumas perdas ou um funcionamento nao eficiente do Switch o segundo
caso e o ideal.
Cenario do ARP Flooding
Para o cenario de teste de verificacao do comportamento do switch sera necessario de pelo
menos tres hosts
• Host A: Ira mandar uma serie de pacotes ICMP para o host B ;
• Host B: Recebera pacotes ICMP enviados pelo host A ;
3.2 ARP Flooding 30
• Host C: Ficara responsavel apenas pela captura de pacotes com software Wireshark. .
Os tres hosts estao dispostos conforme figura 3.7.
Figura 3.7: Cenario do ARP Flooding.
O host C ficou apenas com a funcao de escutar os pacotes, esses pacotes nao estao desti-
nados a porta a qual esta conectado o host C, porem, o mesmo conseguira escutar devido ao
comportamento posteriormente ao teste de ARP flooding. Com o software wireshark e possıvel
filtrar a captura de pacotes apenas para pacotes Internet Control Message Protocol (ICMP) e
salva-los em um arquivo para posterior analise.
A porta a qual esta conectado o host C esta configurado no modo espelhamento de porta,
ela recebe todos os dados da porta a qual esta conectado host B.
Figura 3.8: Port Mirror.
Como pode ser visto na figura 3.10 o switch se comporta em modo failopen, diferente de
um hub, que envia pacotes para todas as portas, o switch interpreta quadros, e envia para um
3.2 ARP Flooding 31
endereco MAC especifico. O teste foi efetuado enviando pacotes ICMP do host A para o host
B, como o switch trabalha atraves de uma tabela ARP, em que estao enderecados numero de IP
e endereco MAC associados a cada porta, o pacote ICMP iria transitar diretamente do host A
ao host B, nao sendo replicado a outras portas. Apos a tabela ARP do switch ser inundada com
enderecos MAC falsos, ocorrem pacotes com mensagens ”Destination Unreachble”(destino
inalcancavel), pois o endereco MAC do destino nao corresponde ao da tabela, posteriormente
o switch ira abandonar essa tabela, enviando mensagens em broadcast, ou seja, para todas as
portas, conforme os hosts forem respondendo as mensagens broadcast, como o protocolo ARP
e dinamico, essa tabela sera reatualizada.
Foram efetuados captura de pacotes de dois modos, com espelhamento e sem espelhamento
de porta, no modo espelhamento de porta, ha um filtro para a porta a qual esta conectado host
B, alguns pacotes aparecem com ”Destino inalcancavel”, porem, a perda nao e tao significativa.
Figura 3.9: Captura de pacotes com espelhamento de porta.
Na figura 3.10 a captura foi efetuada sem espelhamento de porta, ou seja, nao ha um filtro de
datagramas para uma porta especifica, uma grande quantidade de pacotes e perdida, da mesma
forma com o campo “Destino inalcancavel”.
Figura 3.10: Captura de pacotes pelo host C.
Nota-se que ao efetuar o ARP Flooding diversos pacotes aparecem com campo “Destino
inalcancavel”, isso acontece pois o switch, utilizando sua tabela MAC, envia pacotes ao destino
e como houve alteracao do endereco de hardware pelo ARP o mesmo nao consta mais em sua
memoria. A medida que esses pacotes vao se tornando inacessıveis o switch faz uma nova
atualizacao da tabela de forma dinamica.
3.3 Loop 32
3.3 Loop
Conforme (LOBATO, 2013) Loops na rede podem acontecer de forma nao intencional,
durante uma mudanca de cabeamento ou ampliacao da estrutura, podem causar diversos pro-
blemas, incluindo:
• Tempestade de broadcast;
• Multiplas copias de quadros;
• Instabilidade da tabela MAC.
Esses problemas podem gerar uma condicao de sobrecarga na rede, onde quadros sao re-
transmitidos infinitamente na rede, ocasionando lentidao e ate o travamento do Switch. Para nao
ocorrer esse problema o Spanning Tree Protocol deve ser ativado (LOBATO, 2013).
Teste de loop
A figura 3.11 exemplifica a maneira como foi efetuado o teste de loop, conectando um cabo
de rede entre as portas do Switch, a figura nao representa a imagem real do teste que foi efetuado
no Switch D-link, e apenas uma representacao do teste.
Figura 3.11: loop no Switch (ROGIER, 2016).
O rack da CTIC possui 4 Switchs D-link 3100 empilhados, o teste foi feito no quarto Switch
do empilhamento, conectando as portas 17 e 18, com o STP ativo o comportamento do switch
nao apresenta mudancas, imediatamente apos a desativacao do Spanning Tree Protocol (STP) o
Switch travou, travando tambem os outros 3 Switchs do empilhamento.
3.4 Sobrecarga de trafego 33
O teste abaixo mostra como ocorre uma broadcast Storm, na figura 3.12 foi efetuado um
teste de ping de apenas 4 Requests com um switch em loop, com apenas alguns segundos de
captura de pacotes os 4 pacotes enviados foram replicados infinitamente, figura 3.13.
Figura 3.12: Ping de 4 Requests com destino broadcast
Figura 3.13: Captura de pacotes pelo software Wireshark.
Quando se faz um loop imediatamente e gerado uma infinidade de pacotes repetidos, com
destino ao broadcast para todas as portas do switch, aumentando seu processamento interno e
ocasionando a inoperabilidade de equipamento, isso demonstra a importancia do STP e o que
ocorre quando ele nao esta ativo.
3.4 Sobrecarga de trafego
Nesse ensaio foram efetuados testes de trafego utilizando os softwares Ostinato e Jperf,
utilizando o Jperf com o trafego configurado em 100 Mbps, 500 Mbps e 700 Mbps, figura 3.15.
A velocidade nominal da porta e de 1 Gbps, porem foram efetuados testes e a velocidade real
da porta chega proximo aos 850 Mbps, figura 2.14. Mesmo efetuando uma sobrecarga na porta
em 700 Mbps e ao mesmo tempo enviando pacotes com o software Ostinato nao houve perda
de dados.
A figura 3.14 mostra a configuracao dos pacotes ICMP, utilizando dez bursts(rajadas) con-
tendo cem pacotes, totalizando dois mil pacotes, mil requests e mil replys, efetuados com o
software Ostinato.
3.4 Sobrecarga de trafego 34
Figura 3.14: Ostinato configurado com 10 rajadas de 100 pacotes.
A figura 3.15 mostra um teste aplicando um trafego TCP de 700 Mbps, logo em seguida
efetuado um teste com envio de pacotes dois mil pacotes ICMP figura 3.14.
Figura 3.15: trafego configurado em 700Mbps.
Mesmo com um trafego alto nao houveram perda de pacotes e nem mesmo dados em TCP,
a velocidade da porta teve uma leve variacao, porem nada significativo, conforme exemplifica a
figura 3.16.
Figura 3.16: Medicao da Bandwidth.
3.5 TCP offload 35
A figura 3.17 mostra a captura de pacotes efetuada com o software Wireshark com filtros
para pacotes ICMP, pode-se notar que todos os mil pacotes enviados atraves da rajada de dados
foram capturados pela interface, bem como seus replys, totalizando os dois mil pacotes.
Figura 3.17: Captura dos pacotes enviados pelo Ostinato.
Uma sobrecarga na rede torna todas as aplicacoes muito lentas, para evitar essa situacao e
preciso analisar se a atual rede esta preparada para receber essa grande quantidade de dados, foi
visto nessa analise que mesmo aplicando um alto trafego no switch, nao ocorrem perdas signi-
ficantes de desempenho, concluindo entao que a atual rede e capaz de suprir uma quantidade
significativa de dados.
3.5 TCP offload
Para testar a conexao efetuando o offload engine foi utilizado o software Ethtool, atraves
deste software e possıvel habilitar/desabilitar diversos recursos da NIC.
A figura 3.18 mostra os recursos disponıveis na NIC, iremos habilitar o TCP-Segmentation-
Offload, para habilitar esse recurso e necessario habilitar tambem o Generic-Receive-Offload e
o Generic-Segmentation-Offload, por default esses recursos vem desabilitados.
3.5 TCP offload 36
Figura 3.18: Recursos da NIC.
Como observado na figura 3.19, nao ha campo de verificacao de checksum, isso torna a
conexao mais rapida devido ao tempo de processamento do checksum, a validacao e feita nas
camadas inferiores, atraves do hardware dedicado da NIC.
Figura 3.19: Segmento TCP sem campo Checksum.
O grafico mostra a taxa media da bandwidth ao longo de dez minutos de testes efetuados
com o TCP offload desabilitado, figura 3.20.
Figura 3.20: Sem offload.
3.5 TCP offload 37
No grafico seguinte a taxa media da bandwidth ao longo dos mesmos dez minutos de testes
efetuados com o TCP offload habilitado, figura 3.21.
Figura 3.21: Com offload.
Nao basta apenas o nucleo da rede obter um bom desempenho, a comunicacao entre cli-
entes e servidores tambem deve funcionar de uma maneira efetiva, atraves do TCP offload foi
constatado que ao segmentarmos os pacotes TCP e obtido um desempenho significativo na
comunicacao entre hosts.
38
4 Conclusoes
Uma bateria de testes foi feita nos principais switches do campus Sao Jose, afim de testar o
desempenho dos mesmos, o levantamento dos equipamentos e necessario para se conhecer bem
o nucleo da rede, quais pontos devem ser examinados e por onde passa a maior quantidade de
dados.
O ARP Flooding testa a tabela MAC do switch, como ela se comporta com uma inundacao
de requisicoes ARP, e como os quadros sao transmitidos dessa maneira.
O teste de loop visa verificar o funcionamento do STP e o comportamento dos quadros ao
desabilita-lo.
Atraves da sobrecarga no trafego da rede vemos como o switch se comporta utilizando o
maximo do trafego, algo que nao e muito comum, mas que ao ocorrer podem acarretar em
graves problemas.
O TCP Offload visa melhorar o desempenho da rede segmentando os cabecalhos TCP em
um hardware dedicado na NIC, em portas de alta velocidade como Gigabit e 10 Gigabit ha um
ganho significativo na transferencia de dados.
39
Referencias Bibliograficas
10GEA. TCP/IP Offload Engine TOE. 2016. Acessado em 10-07-2016. Disponıvel em:<https://www.10gea.org/whitepapers/tcpip-offload-engine-toe/>.
BUENO, E. M. Monitoramento de Redes de Computadores com uso de Ferramentas deSoftware Livre. Brasil: UFPR, 2012. 10–16 p.
FILIPPETTI, M. Geradores de Trafego para Labs. Brasil, 2009. Acessado em 08-04-2016.Disponıvel em: <http://blog.ccna.com.br/2009/09/25/geradores-de-trafego-para-labs/>.
FOROUZAN, S. C. F. B. A. Protocolo TCP/IP 3.Ed. Brasil: AMGH Editora, 2008. 159–275 p.
GUPTA ALLEN LIGHT, I. H. P. Boosting Data Transfer with TCP Offload Engine Technology.Brasil: Dell Power Solutions, 2006. 1–5 p.
IPERF. Iperf. Brasil, 2001. Acessado em 08-04-2016. Disponıvel em: <http://http://iperf.fr>.
JPERF. Jperf. Brasil, 2001. Acessado em 08-04-2016. Disponıvel em:<http://http://github.com/AgilData/jperf>.
LOBATO, G. E. L. C. Arquitetura e Protocolos de Rede TCP-IP. Brasil: Escola Superior deRedes, 2013. 185–201 p.
ORG, O. Ostinato Org. Brasil, 2001. Acessado em 08-04-2016. Disponıvel em:<http://http://ostinato.org/>.
ROGIER, B. How to Identify and Quickly Fix Switching Loops. 2016. Acessado em10-07-2016. Disponıvel em: <http://blog.performancevision.com/how-to-identify-and-quickly-fix-switching-loops>.