analise da rede de computadores do instituto´ federal de ... · testes de desempenho de...

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.4 TOE 16

Figura 2.3: TCP offload engine (10GEA, 2016).

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.


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.


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.


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).


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.


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.


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.


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.


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>.

analise da rede de computadores do instituto´ federal de ... · testes de desempenho de...

Documents