Ferramenta IPERF Geração e Medição de Tráfego TCP e UDP

dx.doi.org/10.7437/NT2236-7640/2014.02.003Notas Tcnicas, v. 4, n. 2, p. 113, 2014

Ferramenta IPERF: gerao e medio de Trfego TCP e UDPIPERF tool: generation and evaluation of TCP and UDP data traffic

Pedro Henrique Diniz da Silva e Nilton Alves JniorCentro Brasileiro de Pesquisas Fsicas,

Rua Dr. Xavier Sigaud 150,Rio de Janeiro, RJ - 22290-180, Brasil

Resumo: Este trabalho demonstra a utilizao da ferramenta de medio e gerao de trfego de dados Trans-port Control Protocol (TCP) e User Datagram Protocol (UDP) conhecida como IPERF. Uma ferramenta tilpara engenheiros e administradores de rede, do tipo cliente/servidor, desenvolvida com cdigo livre e gratuita.Ela permite, como uma de suas principais vantagens, a alterao de parmetros TCP, tal como o tamanho dajanela TCP, alm de exibir relatrios de banda nos modos TCP e UDP, e relatrios de jitter e perda de pacotesno modo UDP. Neste documento, so exibidos alguns casos em que a ferramenta til e como ela pode serutilizada para auxiliar na anlise de desempenho de redes TCP/IP.

Palavras-chave: Redes de computadores; Medio de desempenho de redes de computadores; Gerao detrfego TCP e UDP.

Abstract: This work demonstrates the use of Transport Control Protocol (TCP) and User Datagram Protocol(UDP) data traffic measurement and generation tool known as IPERF. This tool is useful for network engineersand administrators, developed based on the client/server, open source and free models. It allows you, as oneof its main advantages, to modify TCP parameters such as the TCP window size, in addition to view reports ofbandwidth in TCP and UDP modes, and reports of jitter and packet loss in UDP mode. In this document, wereport some cases where the IPERF tool is useful and how it can be used to assist in analyzing the performanceof TCP/IP networks.

Keywords: Computer networks; Performance evaluation of computer networks; TCP and UDP traffic genera-tion.

1. INTRODUO

Os grandes experimentos de fsica necessitam cadavez mais de uma infraestrutura de computao de ponta ededicada. Atualmente, todos esses experimentos comparti-lham quantidades enormes de dados para se beneficiar deuma capacidade descentralizada de processamento e armaze-namento computacional. O meio fsico para que esses com-partilhamentos aconteam so as redes de computadores.

Esses grandes experimentos sempre estiveram pre-sentes na pesquisa e desenvolvimento da rea de computa-o (em especial possvel citar o protocolo http/www emais recentemente as pesquisas em tecnologias para ope-rao de uma rede a 100 Gbps [1; 2]).O Centro Brasileirode Pesquisas Fsicas (CBPF/MCTI), por meio de seu Grupode Computao e Instrumentao, tem tido uma atuao dedestaque nesta linha, seja atravs da coordenao da Rede-Rio de Computadores (a rede acadmica para pesquisa e en-sino do Estado do Rio de Janeiro) e da liderana tcnica daREDECOMEP-Rio (que foi inaugurada recentemente comum backbone de 10 Gbps sobre um suporte tecnolgico deat 1.9Tbps em Multiplexao Densa por Diviso de Com-primento de Onda - DWDM, do ingls Dense Wavelength

Electronic address: [email protected] address: [email protected]

Division Multiplexing[3], em mais de 300 km de fibras ticasinstaladas)1,2[4; 5; 6; 7; 8]. No entanto, os desafios para asredes acadmicas de alta velocidade, em especial como su-porte instrumentao cientfica remota em fsica, so aindaimensos. Apesar da infraestrutura local ter melhorado signi-ficativamente e as redes terem atingido um desempenho dealtssima velocidade em seu ponto final, obter um timo de-sempenho entre as redes envolvidas fim a fim ainda um de-safio. necessrio pesquisar, entender e desenvolver tecno-logias e ferramentas de anlise de desempenho de redes como envolvimento de diversos protocolos em vrias camadas de

1 Em junho de 2014, foi inaugurada a RedeRio Metropolitana(REDECOMEP-Rio), uma parceria da RedeRio/FAPERJ com aRNP/MCTI. Esta uma infraestrutura de fibras ticas prprias que for-mam uma rede de alta velocidade para as instituies de ensino, ci-ncia, tecnologia, inovao e de governo na cidade do Rio de Ja-neiro. A REDECOMEP-Rio interconecta 86 pontos, pertencentes a51 instituies acadmicas na regio metropolitana do Rio de Ja-neiro estendendo-se por mais de 300 quilmetros em um backbone de10Gbps em tecnologia DWDM atingindo uma banda agregada de at1,9 Tbps. A coordenao e o projeto tcnico da REDECOMEP-Rio fi-caram sob a responsabilidade do CBPF (para mais informaes vide:http://www.redecomep.rnp.br/?consorcio=2).

2 Atualmente, os projetos RedeRio/FAPERJ e REDECOMEP Rio de Ja-neiro esto sob coordenao de operaes da equipe do Coordenao deEngenharia de Operaes (CEO) da RedeRio/FAPERJ. A operao dasredes est sob a responsabilidade da Coordenao de Atividades Tcni-cas (CAT) do Centro Brasileiro de Pesquisas Fsicas (CBPF/MCTI).

2 Pedro Henrique Diniz da Silva e Nilton Alves Jnior

comunicao fim a fim. Pesquisar e avaliar o desempenho deredes de computadores, especialmente aquelas dedicadas agrandes experimentos colaborativos de fsica, envolve a an-lise de mtricas que caracterizem seu comportamento, desdea sua topologia fsica (fim a fim) quanto todas as especifi-caes operacionais e projetos lgicos. Para isto devem serfeitas escolhas corretas e anlises de diversas mtricas nosdiferentes nveis funcionais de uma rede. Essas mtricas po-dem ser obtidas atravs de tcnicas de medio ativa(videseo 2) que consistem na injeo de pacotes de controle narede, ou passivas3, em que so apenas observados os paco-tes que trafegam pela rede. As caractersticas da rede queso geralmente medidas e analisadas pelas ferramentas paraa anlise de desempenho de rede so:

1. Largura de banda e taxa de uso dos canais de comuni-cao envolvidos (throughput ou vazo): a largura debanda indica a capacidade mxima de transmisso no-minal de uma conexo, enquanto que o throughput ouvazo trata-se da quantidade de dados transferidos deum ponto a outro da rede em um determinado perodode tempo.

2. Perda de pacotes: trata-se do nmero de pacotes envi-ados por um emissor, mas no recebidos pelo recep-tor, sendo, geralmente, obtido como um percentual deperda de pacotes na rede. Esse percentual estimadocom base no nmero total de pacotes perdidos divididopelo total de pacotes enviados. Para uma boa anlisedessa mtrica deve-se levar em considerao diversosfatores como a caracterizao do tamanho dos buffersde armazenamento temporrio, a anlise da saturaode enlaces e o congestionamento da rede fim a fim.

3. Tempo de resposta (latncia ou atraso da rede): es-tima o tempo que um pacote demora para sair de suaorigem e chegar ao seu destino. Em geral, a latnciada rede medida como o atraso de ida e volta de umpacote na rede, tambm conhecido como Round TripTime (RTT).

4. Jitter: obtido como o desvio padro do atraso de pa-cotes enviados em sequncia. A medio da variaoda latncia impacta no uso da rede para transfernciade grandes volumes de dados, em especial para apli-caes que necessitem de alto desempenho em temporeal.

Como parte integrante de um projeto coordenadopela Coordenao de Atividades Tcnicas (CAT) do CBPF,cujo objetivo principal garantir e otimizar o acesso doCBPF aos grandes experimentos internacionais e a troca degrandes volumes de dados sob a Internet em alta velocidade

3 O mtodo de medio passivo analisa o desempenho de redes atravsdo uso de dispositivos passivos, que no interferem no trfego da redequando realizam suas medies, i.e., esses dispositivos apenas observamo trfego corrente que passa pelo ponto de observao. Exemplos deferramentas de medio passiva so as que utilizam o protocolo SimpleNetwork Management Protocol (SNMP), como CACTI [9] e MRTG [10].

e alta disponibilidade, que desenvolvemos o presente docu-mento. Com este projeto pretendemos pesquisar e desenvol-ver as ferramentas para avaliao de desempenho inter-redes,com o objetivo de melhorar a taxa de utilizao dos recursoscomputacionais disponveis fim a fim dos projetos desenvol-vidos no CBPF. Dessa forma, este documento surge comouma necessidade de se compreender o funcionamento da fer-ramenta de medio ativa de rede IPERF, como uma soluode cdigo aberto, para realizar medies de vazo dos enla-ces da RedeRio/FAPERJ e do projeto REDECOMEP-Rio.

Apesar de haverem disponveis na Internet diversostutorias sobre a ferramenta IPERF, alm de pginas Web quedemonstrem o seu funcionamento, h a carncia de artigoscientficos que abordem de uma maneira clara e objetiva oseu funcionamento e utilizao. Ademais, no h na litera-tura cientfica textos que demonstrem em conjunto explica-es sobre a ferramenta e suas mtricas observveis, alm decasos prticos da vida profissional de administradores e en-genheiros de rede em que essa aplicao seja bem adequadae simples de ser utilizada. Desse modo, neste trabalho, es-tamos interessados em demonstrar o funcionamento da fer-ramenta IPERF e alguns casos especficos de sua utilizao,que sejam teis vida prtica de engenheiros e administra-dores de redes, inclusive para os responsveis pelo CEO daRedeRio/FAPERJ.

Nas prximas sees, so dadas uma viso geraldas ferramentas de medio ativas de rede e da ferramentaIPERF. Em sequncia, so abordados alguns tpicos essen-ciais para a compreenso do funcionamento da ferramentaem relao aos protocolos da camada de transporte da pi-lha de protocolos TCP/IP, o UDP e o TCP. Em seguida, soapresentados os procedimentos de instalao e de utilizaoda ferramenta IPERF e tambm so expostos alguns casosespecficos de polticas de controle de banda, testes de ba-lanceamento de carga e gerao de fluxos UDP de altas taxasde transferncia. Por fim, so apresentadas as concluses re-ferentes anlise do funcionamento da ferramenta IPERF edos estudos de casos.

2. VISO GERAL DAS FERRAMENTAS DE MEDIOATIVAS DE REDE

As ferramentas de medio ativa de rede proveema abordagem mais simples e mais flexvel para a estimaoda vazo da rede [11]. Essas ferramentas so fundamentais,pois permitem analisar o trfego de dados e os pontos crti-cos de uma rede, avaliando a sua topologia a fim de verificarse a qualidade dos servios oferecidos pela rede est sendoatendida, alm de auxiliar no planejamento futuro da rede.

Esse tipo de ferramenta de medio tem como ob-jetivo injetar pacotes de teste na rede, para a partir de entomedir o desempenho da rede avaliando como esse trfego deteste se comporta na rede.

nesse contexto que se inserem os geradores de tr-fego como ferramentas de medio ativas de redes de com-putadores, assim como a ferramenta IPERF. Os geradores detrfego permitem que sejam gerados fluxos de dados comcaractersticas especficas para simular o acesso a uma apli-cao, como o trfego de voz ou vdeo, por exemplo. Com

CBPF-NT-003/14 3

isso, possvel testar a eficincia das configuraes de Qua-lity of Service(QoS), Access Control List (ACLs), traffic-shapping4, Virtual Private Networks (VPNs), dentre muitasoutras.

Diversas so as ferramentas de medio ativa dis-ponveis na Internet, tanto de cdigo aberto como Clink[12], IPERF [13], Netperf [14], Pathrate [15], NUTTCP [16],quanto pagas como PathView [17]. Cada uma dessas ferra-mentas utiliza tcnicas diferentes para determinar a capaci-dade de trfego, porm no objetivo desse documento rea-lizar a anlise nem comparao de todas essas ferramentas.Portanto, apresentado, a partir da seo 3, uma anlise dofuncionamento da ferramenta IPERF.

3. VISO GERAL DA FERRAMENTA IPERF

O IPERF uma ferramenta que rene em uma nicaaplicao o relatrio da anlise de vrias mtricas, como acapacidade mxima fim-a-fim a nvel de transporte, o jitter ea perda de pacotes. A sua utilizao simplifica a anlise deproblemas de rede por parte dos administradores de redes.Desse modo, essa foi uma das motivaes de sua escolhacomo ferramenta para anlise nesse documento.

Em se tratando de ferramentas de medio ativa deredes, o IPERF uma ferramenta amplamente utilizada paramedir a vazo e a qualidade de um enlace de rede. Ele per-mite a anlise da qualidade de um enlace segundo algumasdas mtricas apontadas na seo 1, como a seguir:

1. Jitter (variao do atraso entre os pacotes de dadossucessivos): pode ser medida por meio do envio defluxos de pacotes do User Datagram Protocol (UDP)com a ferramenta IPERF.

2. Perda de datagramas: pode ser medida, tambm, comtestes UDP.

3. Vazo: medidas atravs de testes TCP (Transfer Con-trol Protocol) e UDP por meio do IPERF.

O IPERF um software livre desenvolvido peloNLANDR/DAST (National Laboratory for Applied NetworkResearch/Distributed Applications Support Team) no incioda dcada de 2000, como uma alternativa para medio dorendimento da banda de redes de computadores atravs deTCP e UDP [18]. A ferramenta no possui interface grficapor padro, sendo sua operao relativamente simples atra-vs da CLI (Command Line Interface). Porm, existe tam-bm um front-end grfico desenvolvido em linguagem Javaconhecido como Jperf, que permite a visualizao dos resul-tados graficamente. No entanto, a utilizao desse front-endno ser abordada nesse documento.

O IPERF funciona, basicamente, em um modelo cli-ente/servidor, onde o servidor atende s solicitaes de tes-tes e o cliente inicia as sesses de testes. Ele est disponvel

4 O termo traffic shapping (em portugus, modelagem de trfego) trata dalimitao da vazo de trfego de redes de dados, em geral por meio detcnicas de priorizao de trfego.

como open source compilvel ou binrio executvel para di-versas plataformas incluindo Windows, Linux, Solaris, MacOS, OpenBSD e FreeBSD.

Os testes de performance realizados pelo IPERF po-dem ser utilizados para validar uma rede, tanto em segmentoscabeados quanto sem fio. Os testes podem ser utilizados, porexemplo, para identificar o mau desempenho de uma rede ouat mesmo para desqualificar a porta de um switch ou rotea-dor defeituoso.

Por padro, o protocolo utilizado pelos testes comIPERF o TCP, porm o protocolo UDP pode ser tambmutilizado. Dentre as principais caractersticas da ferramentaem relao a cada um dos protocolos citados podem ser des-tacadas:

1. TCP

(a) Medida da largura de banda(b) Reporta o tamanho do MSS/MTU (Maximum

Segment Size/Maximum Transmission Unit)(c) Suporta a modificao do tamanho de janelas

TCP

(d) Conexes simultneas tanto para o cliente quantopara o servidor

2. UDP

(a) Cliente pode criar fluxos UDP de largura debanda variada

(b) Mede a perda de pacotes

(c) Mede o jitter(d) Cliente e servidor podem ter mltiplas conexes

simultneas (indisponvel no Windows)

Entretanto, vale-se ainda ressaltar que muitos fa-tores podem limitar o rendimento de conexes TCP, comoperdas, congestionamento da rede e entregas fora de ordem.Desse modo, testes com UDP proveem maior transparncia,onde podemos medir diretamente as perdas, o jitter e as en-tregas fora de ordem.

4. PROTOCOLOS TCP E UDP

O modelo de protocolos TCP/IP que a Internet im-plementa tem dois protocolos de transporte principais: oUDP e o TCP.

O User Datagram Protocol (UDP), definido na RFC768 [19], utiliza o protocolo IP para transportar uma mensa-gem de uma mquina para outra, e prov o mesmo meca-nismo de entrega de datagramas sem conexo e inseguro queo IP. Ele no utiliza confirmaes para garantir que as men-sagens cheguem ao destino, alm de no ordenar as mensa-gens entrantes e no prov um feedback para controlar a taxacom que a informao trafega entre as mquinas [20]. Dessaforma, uma aplicao que faz uso do protocolo UDP paraentrega de mensagens entre hosts aceita a total responsabili-dade de lidar com o problema de confiabilidade, incluindo aperda de mensagens, duplicao, atraso, entrega fora de or-dem e perda de conectividade.


O UDP utiliza o protocolo IP para transportar men-sagens, mas adiciona a capacidade de distinguir entre mlti-plos destinos dentro de um determinado host, atravs de me-canismos conhecidos como portas. As portas, em conjuntocom o endereo IP, identificam a fonte e o destino de cadamensagem. Em suma, ele nada mais do que uma interfacepara o protocolo IP, cuja funo bsica servir como mul-tiplexador e demultiplexador de processos para o trfego deinformaes do protocolo IP.

Assim sendo, os programas aplicativos que depen-dem de UDP funcionam muito bem em um ambiente local,mas falham de modo dramtico quando so utilizados na In-ternet. Desse modo, onde o IPERF se faz presente, per-mitindo aos profissionais de Tecnologia da Informao (TI)testarem a conectividade UDP.

O Transport Control Protocol (TCP), definido naRFC 793 [21] o protocolo da camada de transporte ori-entado conexo e que oferece um servio de entrega con-fivel, ao contrrio do que ocorre com o UDP. Os protocolosde transporte confiveis usam uma nica tcnica fundamen-tal conhecida como confirmao positiva com retransmisso(tambm conhecida como ACK). A tcnica requer que umreceptor se comunique com a fonte, enviando de volta umamensagem de confirmao (ACK) quando recebe os dados.O remetente mantm um registro de cada pacote que enviae espera por uma confirmao antes de enviar o prximo pa-cote. A Figura 4. 1 mostra como o mais simples protocolo detransferncia com confirmao positiva transfere os dados.

Figura 4. 1: Exemplo simples de confirmao positiva com retransmisso.

Os eventos ocorridos no transmissor e no receptor esto apresentados esquerda e direita. Cada linha diagonal cruzando o meio mostra a

transferncia de uma mensagem atravs da rede.

Nessa tcnica de retransmisso, o transmissor ini-cia um timer depois de transmitir um pacote. Quando o ti-mer expira, o transmissor assume que o pacote foi perdido eretransmite-o.

O protocolo TCP implementa uma forma mais com-plexa de confirmao positiva com retransmisso, conhecidacomo tcnica de janela deslizante. Essa tcnica permite umamelhor utilizao da largura de banda disponvel, pois per-mite que o transmissor envie mltiplos pacotes antes de rece-ber uma confirmao, e permite que se impea que um trans-missor rpido sobrecarregue um receptor lento. Essa tcnicade controle conhecida como controle de fluxo do TCP.

O funcionamento do mecanismo de janela desli-

zante pode ser visto como uma sequncia de pacotes a seremtransmitidos, como pode ser visualizado na Figura 4.2. Oprotocolo implementa uma pequena janela de tamanho fixona sequncia de dados a serem transmitidos e transmite todosos pacotes que se encontram nessa janela.

pct0recebido,entregueACK00123456789




pct0enviado0123456789



pct3enviado,janelacheia0123456789

ACK0recebido,pct4enviado0123456789





Remetente DestinatrioMensagensdeRede

JaneladeTransmisso JaneladeRecepo Figura 4. 2: Protocolo de janela deslizante com quatro pacotes na janela. A

janela desliza de modo que o pacote em seguida ela pode ser enviadoquando uma confirmao for recebida para o primeiro pacote da mesma.

Ao passo que as confirmaes vo sendo recebidasa janela vai deslizando. Desse modo, o nmero de pacotesque podem ser enviados enquanto no so reconhecidos emqualquer dado momento limitado pelo tamanho da janela.

O desempenho dos protocolos de janelas deslizan-tes depende do tamanho da janela e da velocidade de trans-misso de pacotes na rede. Aumentando-se o tamanho dajanela deslizante pode-se eliminar quase que completamenteo tempo ocioso da rede [20].

O protocolo TCP implementa um mecanismo de ja-nela deslizante especializado para resolver dois problemasprimordiais: a transmisso eficiente e o controle de fluxo.O mecanismo de janela do TCP torna possvel enviar v-rios segmentos antes de uma confirmao chegar ao receptor,mantendo a rede ocupada e aumentando o rendimento. Essemecanismo permite que o receptor restrinja a transmisso atque haja espao suficiente em seu buffer para acomodar maisdados, resolvendo o problema de controle de fluxo fim-a-fim.Um ponto importante tambm a ser observado que o meca-nismo de janela deslizante do TCP opera a nvel de octetos,e no no nvel de segmentos ou pacotes, numerando sequen-cialmente os octetos do fluxo de dados.

Resumidamente, podemos dizer que o TCP permiteo envio de x segmentos de tamanho mximo conhecido comoMSS (Maximum Segment Size) antes da recepo de umACK, que o tamanho da janela TCP. Logo, a taxa de trans-misso mxima de uma sesso TCP pode ser controlada pelotamanho da janela TCP. Portanto, a vazo para uma determi-nada conexo TCP transmitindo a cada RTT segundos podeser dada por [22]:

CBPF-NT-003/14 5

Vazo =x [segmentos] MSS [bytes]

RTT [segundos]=

Tamanho da Janela TCP [bytes]RTT [segundos]

(1)

Alm do mecanismo de janela deslizante o TCP im-plementa tambm um mecanismo de controle de congestio-namento que visa adaptar a taxa de envio de dados cargada rede. Esse mecanismo , basicamente, composto por doisalgoritmos: o algoritmo de partida lenta e o de preveno decongestionamento [22].

O algoritmo de partida lenta utilizado no estabele-cimento de uma conexo TCP, com o objetivo de fazer comque a taxa de transmisso do transmissor convirja para a ca-pacidade de transmisso disponvel na rede. Em seguida, iniciada a fase de preveno de congestionamento, utilizadapara controlar o tamanho da janela de transmisso dinamica-mente [23].

Com o auxlio dos algoritmos de partida lenta e con-trole de congestionamento, do lado do transmissor uma ja-nela de congestionamento (TCP CWND) calculada base-

ada na taxa de perda de pacotes, e do lado do receptor uti-lizada uma janela de recepo (TCP RWND) que informa aotransmissor quantos bytes ele (receptor) capaz de aceitarem um dado momento. Por fim, o menor valor entre a TCPCWND e a TCP RWND anunciada determina quantos bytespodem ser realmente transmitidos pelo transmissor em umdado momento.

4.1. Ajustando a Janela TCP

Segundo a RFC 6349 [24], para que se evite a limi-tao da performance TCP ambas as janelas TCP (RWND eCWND) devem ser maiores do que o produto do atraso delargura de banda ou Bandwidth-Delay Product (BDP):

BDP [Bytes .s] =RTT [segundos] menor largura de banda do link [bits]

8(2)

A Figura 4.3 auxilia na compreenso de como aconfigurao incorreta da janela TCP pode influenciar naperformance TCP.

Figura 4. 3: Exemplo para o clculo do produto da largura de banda pelo

atraso.

Supondo um enlace Wide Area Network (WAN) de60 Mbps com atraso de ida e volta de 50 ms (RT T = 50ms) etamanho de janela do transmissor de 64 KB, o BDP seria de384 KB. Esse BDP representa seis vezes o tamanho da janelado transmissor. Dessa forma, o transmissor alcanaria umavazo de, aproximadamente, 10 Mbps.

Porm, quando o tamanho da janela TCP excede oBDP, o limite mximo de FPS (Frames Per Second) do en-lace atingido, e ento a frmula para o clculo da Vazomxima TCP alcanvel [24]:

Vazo TCPmx[bps] = FPS5mx (MTU[Bytes]-40)8 (3)

onde FPSmx o nmero mximo de quadros por segundopara o enlace em questo e o MTU o tamanho mximo doquadro. Alm disso, esse clculo baseado no protocolo IPverso 4 com cabealhos TCP/IP de 20 bytes cada (20 paraTCP e 20 para IP) dentro do MTU, onde cada byte representa8 bits.

Por exemplo, levando em considerao o FPS m-ximo de uma conexo Fast Ethernet de 100 Mbps valendo8127 quadros por segundo e o MTU Ethernet de 1500 Bytes,logo a Vazo TCP mxima de 94,9 Mbps.

Enfim, para se calcular a Vazo TCP em funo dotamanho da janela TCP, a seguinte frmula pode ser utili-zada:

Vazo TCP [bps] =tamanho da janela TCP [Bytes] 8

RTT[segundos](4)

Vale ainda ressaltar que pacotes perdidos podem de-gradar seriamente uma conexo TCP. Por exemplo, em umaLAN Gigabit Ethernet conectada a uma WAN a 10 Mbpspode resultar em casos em que a WAN operar de modo in-devido, com rajadas de gigabits, gerando perdas de pacotes eretransmisses TCP.

5 O presente documento no visa demonstrar os mtodos para se obter oFPS de cada tipo de enlace, porm a RFC 6349 [24] demonstra os princi-pais casos prticos de sua obteno.


5. INSTALAO DA FERRAMENTA IPERF

Nesta seo, sero abordados os procedimen-tos de instalao da ferramenta IPERF em plataformasUNIX/Linux e Windows. Em ambos os sistemas a ferra-menta pode ser facilmente instalada.

Como o IPERF funciona segundo o modelo cli-ente/servidor, ento, em geral, aps sua instalao neces-srio que em um host a ferramenta seja executada como cli-ente, enquanto que em outro a mesma seja executada comoservidor.

A Figura 5. 1 apresenta um esquema onde o IPERF instalado em mquinas Linux e Windows, servindo comoservidor e cliente, respectivamente.

Figura 5. 1: Exemplo de funcionamento na ferramenta IPERF em

arquitetura cliente/servidor.

A aplicao disponibilizada amplamente em di-versos locais espalhados pela web, seja como verso compi-lada ou cdigo fonte. Neste documento, ser feito refernciaaos cdigos disponibilizados pelo Frum Francs do IPERF,encontrado em: http://iperf.fr.

A verso utilizada em todos os testes realizadosnesse documento foi a verso 2 mais recente, o release 2.0.5.

Atualmente, existe tambm a verso 3 da ferra-menta, conhecida como iperf3. Ela uma nova implementa-o disponibilizada por uma comunidade global de desenvol-vedores, cujo intuito simplificar e diminuir o cdigo baseda aplicao, e prover um conjunto de bibliotecas com funci-onalidades que possam ser utilizadas em outros programas.Alm disso, essa verso implementa um conjunto de novasfunes, como o informe do nmero de pacotes TCP retrans-mitidos e da taxa de utilizao mdia da CPU. Porm, comoessa mais nova verso ainda est em fase de desenvolvimentoinicial e apresenta uma srie de bugs ainda no corrigidos op-tamos por utilizar a verso 2.x nesse documento.

5.1. GNU/Linux

O aplicativo pode ser baixado e utilizado como umarquivo executvel, sem a necessidade de se realizar sua ins-talao. Para utiliz-lo basta seguir os procedimentos descri-tos abaixo:

root@servidor:# wget http://iperf.fr/download/iperf_2.0.5/iperf/iperf_2.0.5-2_i386root@servidor:# chmod +x iperf_2.0.5-2_i386root@servidor:# mv iperf_2.0.5-2_i386 /usr/bin/iperf

5.2. Windows

Assim como para o GNU/Linux, no Windows, oIPERF tambm pode ser encontrado como um arquivo exe-cutvel. Para utiliz-lo basta realizar o download da ferra-menta em: http://iperf.fr/download/iperf_2.0.5/iperf-2.0.5-2-win32.zip, extrair o arquivo e execut-lo.

6. PARMETROS DISPONVEIS

Nesta seo, sero apresentados todos os parme-tros disponibilizados pela ferramenta e a descrio de cadaum deles. Como o objetivo deste documento no esgotartodas as opes disponveis pela aplicao, sero apresen-tadas somente as consideradas como mais importantes e asmais utilizadas. So elas: configurao padro; formataoda sada; medida da largura de banda bidirecional e bidire-cional simultnea; alterao do tamanho da janela TCP; al-terao da porta TCP, do intervalo de relatrios e do tempode transmisso de dados.

Aps a seo 6 ser apresentada a seo 7 que ser-vir como um complemento, onde sero demonstrados al-guns casos prticos em que a ferramenta IPERF pode ser uti-lizada por administradores e engenheiros de rede para reali-zar testes de desempenho de rede.

6.1. Descrio dos Parmetros Disponveis

Segundo a seo de ajuda do IPERF podemos veri-ficar todas as possveis opes disponveis pela aplicao:

CBPF-NT-003/14 7

Cliente/Servidor:Opes Descrio-f, format Formato do relatrio: Kbits,Mbits, Kbytes, MBytes-i, interval Segundos entre os relatrios peridicos de vazo-l, len Comprimento do buffer para se ler ou escrever (padro de 8 KB)-m, print_mss Imprime o tamanho mximo do segmento TCP (MTU cabealho TCP/IP)-o, output Emite o relatrio ou a mensagem de erro para o arquivo especificado-p, port Porta do servidor a escutar/ se conectar-u, udp Utiliza UDP em vez de TCP-w, window Tamanho da janela TCP (tamanho do buffer de socket6)-B, bind Se liga a um , uma interface ou endereo multicast-C, compatibility Para utilizar com verses antigas, no envia mensagens extras-M, mss Estabelece o tamanho mximo do segmento TCP (MTU 40 bytes)-N, nodelay Estabelece nenhum atraso TCP, desabilitando o algoritmo de Nagle7

-V, IPv6Version Estabelece o domnio para IPv6Servidor:Opes Descrio-s, server Roda em modo servidor-U, single_udp Roda em mode UDP single thread-D, daemon Roda o servidor como um daemonCliente:Opes Descrio-b, bandwidth Para UDP, largura de banda para enviar em bits/s (padro de 1 Mbit/s, implica a

opo u)-c, client Roda em modo cliente, conectando-se ao -d, dualtest Realiza um teste bidirecional simultaneamente-n, num Nmero de bytes a serem transmitidos (em vez de t)-r, tradeoff Realiza um teste bidirecional individualmente-t, time Tempo em segundos para transmitir dados (padro de 10 segundos)-F, fileinput Entra com os dados a serem transmitidos de um arquivo-I, stdin Entra com os dados a serem transmitidos do stdin-L, listenport Porta para receber testes bidirecionais de volta-P, parallel Nmero de threads de clientes em paralelo para serem executadas-T, ttl Time-to-Live, para multicast (padro 1)-Z, linux-congestion

Estabelece o algoritmo de controle de congestionamento (somente para Linux)

Diversos:Opes Descrio-x, reportexclude[CDMSV]

Exclui os relatrios C (conexo) D (dados) M (multicast) S (definies) V(servidor)

-y, reportstyle C Relatrio com valores separados por vrgulas-h, help Imprime a mensagem de ajuda e sai-v, version Imprime as informaes de verso e sai

Tabela 6. 1: Opes do IPERF.

6.2. Configurao de Parmetros

Para cada um dos casos apresentados a seguir con-sideraremos o IP do cliente IPERF como 192.168.0.3 e o doservidor como 192.168.0.4. A Figura 6. 1 demonstra essa

6 Um socket de redes TCP estabelece um elo de comunicao entre duasaplicaes que esto conectadas em uma rede. So definidos como acombinao de um endereo IP e o nmero de uma porta do protocoloTCP [25].

7 O algoritmo TCP/IP de Nagle foi projetado para evitar problemas compacotes pequenos, chamados de tinygrams, em redes lentas. O algoritmodiz que uma conexo TCP/IP pode ter somente um segmento pequenopendente que ainda no fora confirmado. A definio de "pequeno"varia,mas geralmente definido como "inferior ao tamanho do segmento"quepara redes ethernet de cerca de 1500 bytes.

configurao.

Figura 6. 1: Configurao de cliente/servidor.

6.2.1. Configuraes Padro

Por padro, o cliente IPERF se conecta ao servidorIPERF na porta TCP 5001.


Servidor Cliente

#iperf -s #iperf -c 192.168.0.3

--------------------------------------------

Server listening on TCP port 5001

TCP window size: 85.3 KByte (default)

--------------------------------------------

[ 4] local 192.168.0.4 port 5001 connected with

192.168.0.3 port 38110

[ ID] Interval Transfer Bandwidth

[ 4] 0.0-10.0 sec 112 MBytes 93.9 Mbits/sec

-----------------------------------------------

Client connecting to 192.168.0.3,TCP port 5001


----------------------------------------------


192.168.0.3 port 5001



6.2.2. Formatao da Sada

A opo f permite exibir a sada nos seguintes for-matos: (b) bits, (B) bytes, (k) kilobits, (K) kilobytes, (m)megabits, (M) megabytes, (g) gigabits e (G) gigabytes.

Servidor Cliente #iperf -s #iperf -c 192.168.0.3 -f M ----------------------------------------------



----------------------------------------------


192.168.0.4 port 38111



----------------------------------------------

Client connecting to 192.168.0.3, TCP port 5001

TCP window size: 0.02 MByte (default)

----------------------------------------------

[ 3] local 192.168.0.4 port 38111 connected

with 192.168.0.3 port 5001


[ 3] 0.0-10.0 sec 112 MBytes 11.2 MBytes/sec

6.2.3. Medida de Largura de Banda Bidirecional

O servidor IPERF se conecta de volta ao cliente per-mitindo a medio da largura de banda de modo bidirecionalindividualmente. Por padro, somente a largura de banda docliente ao servidor medida.

Servidor Cliente #iperf -s #iperf -c 192.168.0.3r ----------------------------------------------



----------------------------------------------


192.168.0.4 port 56648



----------------------------------------------



----------------------------------------------


with 200.20.94.64 port 5001


----------------------------------------------



----------------------------------------------

----------------------------------------------



----------------------------------------------


with 192.168.0.3 port 5001




192.168.0.3 port 38335


6.2.4. Medio da Largura de Banda Bidirecional Simultnea

Por padro, somente a largura de banda do clientepara o servidor mensurada. Para realizar medies bidire-cionais simultneas, utiliza-se o argumento d.

Servidor Cliente #iperf -s #iperf -c 192.168.0.3d ----------------------------------------------



----------------------------------------------


192.168.0.4 port 38118

----------------------------------------------



----------------------------------------------


with 192.168.0.4 port 5001



[ 6] 0.0-10.0 sec 31.4 MBytes 26.2 Mbits/sec

----------------------------------------------



----------------------------------------------

----------------------------------------------



----------------------------------------------


with 192.168.0.3 port 5001


192.168.0.3 port 35503




6.2.5. Alterao do Tamanho da Janela TCP

O tamanho da janela TCP pode variar entre 2 e65.535 bytes, de acordo com o cabealho TCP. Em especial,em sistemas Linux quando especificado o tamanho do bufferTCP com argumento w, o kernel aloca o dobro do tamanhoespecificado.

Servidor Cliente #iperf s w 13KB #iperf -c 192.168.0.3w 13KB ----------------------------------------------


TCP window size: 13.0 KByte

----------------------------------------------

[324] local 192.168.0.3 port 5001 connected

with 192.168.0.4 port 38120


[324] 0.0-10.0 sec 104 MBytes 87.1 Mbits/sec

----------------------------------------------


TCP window size: 13.0 Kbyte

----------------------------------------------


with 192.168.0.3 port 5001


[136] 0.0-10.0 sec 104 MBytes 87.1 Mbits/sec

6.2.6. Alterao da Porta TCP, Intervalo de Relatrios e Tempode Transmisso de Dados

O argumento p pode ser utilizado para alterar aporta de comunicao TCP do servidor IPERF. Entretanto,ela deve ser alterada em ambos cliente e servidor, onde o pa-dro a porta TCP 5001. O argumento t especifica o tempode durao dos testes (durao padro de 10 segundos) e oargumento i especifica o intervalo entre os relatrios de lar-gura de banda medida em segundos.

Servidor Cliente #iperf s p 10000 #iperf -c 192.168.0.3p 10000 t 20 i 5

----------------------------------------------



----------------------------------------------


with 192.168.0.4 port 57008


[ 4] 0.0-20.3 sec 1.14 MBytes 471 Kbits/sec

----------------------------------------------

Client connecting to 192.168.0.3, TCP port

10000

TCPwindow size: 8.00 KByte (default)

----------------------------------------------


with 192.168.0.3 port 10000


[ 136] 0.0-5.0 sec 296 KBytes 485 Kbits/sec

[ 136] 5.0-10.0 sec 288 Kbytes 472 Kbits/sec

[ 136] 10.0-15.0 sec 288 KBytes 472 Kbits/sec

[ 136] 15.0-20.0 sec 288KBytes 472 Kbits/sec

[ 136] 0.0-20.4 sec 1.14 Mbytes470 Kbits/sec

6.2.7. Testes UDP

A opo de testes UDP fornece informaes sobreo jitter e a perda de pacotes. O jitter a variao (desvio-padro) dos tempos de chegada de pacotes, ou seja, o jit-ter pode ser considerado como a variao da latncia [26].Para aplicaes como transmisso de vdeo e udio (VoIP porexemplo), no importa se pacotes demoram 10ms, 20ms ou100ms para chegarem ao receptor contanto que o tempo detransmisso seja constante. Para o caso de chamadas VoIP,altas taxas de jitter podem interromper uma ligao. O pro-blema de jitter , em geral, atenuado com o armazenamentodos fluxos em buffers do lado do receptor, o que no afeta alargura de banda, mas aumenta o retardo suavizando a flutu-ao.

Vale ressaltar que os resultados reportados pelo ser-vidor so ligeiramente mais precisos, uma vez que o trans-missor pode calcular a taxa de transmisso logo aps realizar

CBPF-NT-003/14 9

Servidor Cliente

#iperf s u #iperf -c 192.168.0.3u b 50m

----------------------------------------------

Server listening on UDP port 5001

Receiving 1470 byte datagrams

UDP buffer size: 110 KByte (default)

----------------------------------------------


192.168.0.4 port 54729


Jitter Lost/Total Datagrams


0.126 ms 0/42531 (0%)

[ 3] 0.0-10.0 sec 1 datagrams received out-of-

order

----------------------------------------------

Client connecting to 192.168.0.3, UDP port 5001

Sending 1470 byte datagrams


----------------------------------------------


192.168.0.3 port 5001



[ 3] Sent 42532 datagrams

[ 3] Server Report:


0.125 ms 0/42531 (0%)

[ 3] 0.0-10.0 sec 1 datagrams received out-of-

order

a ltima escrita em seu buffer de transmisso, isto , antes deos dados terem efetivamente percorrido o enlace.

6.2.8. MSS Maximum Segment Size

O MSS (Maximum Segment Size) ou Tamanho M-ximo do Segmento a maior quantidade de dados, em bytes,que pode ser transportada em um frame sem ser fragmentado.Como o tamanho dos cabealhos TCP e IP valem 40 bytessem levar em considerao as opes do cabealho IPv4 e oMTU o tamanho mximo em bytes em um frame, ento oMSS pode ser calculado da seguinte forma:

MSS = MTU (cabealho TCP+ cabealho IP)= MTU 40 bytesopes do cabealho IPv4

Servidor Cliente #iperf s #iperf -c 192.168.0.3m ----------------------------------------------



----------------------------------------------

----------------------------------------------



----------------------------------------------


with 192.168.0.3 port 5001


[ 3] 0.0-10.0 sec 2967912595171227 bits 0.00

(null)s/sec

[ 3] MSS size 1448 bytes (MTU 1500 bytes,

ethernet)

6.2.9. Testes em Paralelo

A opo de realizar ou no conexes TCP mltiplasem paralelo depende, diretamente, do tamanho do BDP emrelao ao tamanho da janela TCP configurada. Por exemplo,para uma largura de banda de 100 Mbps e RTT de 1 ms, entoo BDP vale aproximadamente 13 KB. Nesse caso, para umajanela TCP de 8 KB o nmero de conexes TCP para ocupara largura de banda disponvel 2.

Servidor Cliente #iperf s #iperf -c 192.168.0.3P 2 ----------------------------------------------



----------------------------------------------


with 192.168.0.4 port 50936


with 192.168.0.4 port 50937


[308] 0.0-10.0 sec 54.0 MBytes 45.3 Mbits/sec


[SUM] 0.0-10.0 sec 108 MBytes 90.5 Mbits/sec

----------------------------------------------



----------------------------------------------


with 192.168.0.3 port 5001


with 192.168.0.3 port 5001




[SUM] 0.0-10.0 sec 108 MBytes 90.5 Mbits/sec

7. ESTUDOS DE CASO

Nesta seo, so apresentados alguns casos reais emque a utilizao do IPERF auxilia na homologao de redesque fazem uso de tcnicas de polticas de controle de bandae de tcnicas de balanceamento de carga, e auxilia tambmna gerao de fluxos UDP de altas taxas de transmisso paramedio de largura de banda em enlaces onde no possvelutilizar um servidor IPERF.

7.1. Polticas de Controle de Banda

As polticas de controle de banda so amplamenteutilizadas por Internet Service Providers (ISPs) de modo alimitar a banda estabelecida em contrato.

Esse documento no visa demonstrar as tcnicas deimplementao desse tipo de poltica. Ele visa apenas de-monstrar como a ferramenta IPERF pode ser utilizada paraverificar e testar a aplicao dessas polticas.

A Figura 7.1 demonstra o layout da rede utilizadanos testes. Temos ambos os servidor e cliente IPERF conec-tados a um roteador. O cliente 192.168.0.2 est conectado interface f0/2 do roteador e o servidor est conectado inter-face f0/1 do roteador. Nesse caso, est sendo aplicada umapoltica de limitao de trfego de 15 Mbps entrante na in-terface f0/2.

Figura 7. 1: Layout da rede para testes de poltica de controle de banda.

Na Figura 7.2, podemos verificar o comando apli-cado no cliente e a sua respectiva sada antes de serem apli-cadas as polticas de controle. possvel observar que foramgerados 94,5 Mbps de trfego UDP pelo cliente e foram re-portados 94,4 Mbps e nenhuma perda pelo servidor.

Figura 7. 2: Comando IPERF aplicado ao cliente antes da aplicao daspolticas ao roteador.

Na Figura 7.3, podemos verificar o comando apsserem aplicadas as polticas ao roteador. Podemos notar queapesar de serem gerados 94,5 Mbps pelo cliente, assim comono exemplo anterior sem as polticas aplicadas, aps as mes-mas serem aplicadas o trfego reportado pelo servidor se li-mitou a 14,2 Mbps, apresentando 85% de perdas. Isso de-


monstra as polticas de limitao fazendo com que os pacotesentrantes na interface f0/2 sejam perdidos.

Figura 7. 3: Comando IPERF aplicado ao cliente aps a aplicao daspolticas ao roteador.

7.2. Testes de Balanceamento de Carga

As tcnicas de balanceamento de carga ou load ba-lancing so amplamente utilizadas por provedores de servi-os de Internet de modo a tornar mais eficiente o uso da lar-gura de banda disponvel. Essas tcnicas remetem a umafuncionalidade dos roteadores de distribuir pacotes atravsde mltiplos enlaces baseado em informaes de roteamento.

Um balanceamento de carga efetivo tenta fazer ouso mais eficiente da banda disponvel e distribui o trfegoentre diversas rotas, baseando-se em protocolos de rotea-mento, e/ou interfaces distintas, baseando-se em protoco-los de agregao de enlaces como Link Aggregation ControlProtocol (LACP), por exemplo [27]. O algoritmo respon-svel por realizar a distribuio de trfego depende de cadaimplementao individualmente e, com isso, sua eficinciapode variar. Especificamente, tratando-se de equipamentosCisco, equipamentos esses que so utilizados no backboneda RedeRio/FAPERJ e REDECOMEP Rio de Janeiro, sosuportados dois modos de balanceamento de carga. So eles:o balanceamento baseado em pacotes e o baseado em fluxos(ou destinos).

Cada um dos modos citados acima possui uma apli-cabilidade diferente. No modo por destino todos os pacotesdestinados a um dado IP so entregues atravs de um mesmocaminho, preservando assim a ordem dos pacotes, mas comum uso desigual dos enlaces. No modo por pacotes, cadapacote entregue atravs de enlaces diferentes, garantindoum uso igual de cada um dos enlaces. Porm, nesse casoos pacotes podem chegar fora de ordem ao destino, devido aatrasos diferentes em cada um dos enlaces da rede.

O modo de balanceamento padro apresentado pe-los roteadores Cisco atravs dos mecanismos de roteamentodinmico como os Open Shortest Path First (OSPF), InteriorGateway Routing Protocol (IGRP) e Intermediate System toIntermediate System (IS-IS) o modo por destino. Como obackbone da RedeRio/FAPERJ e REDECOMEP opera atra-vs de uma dessas configuraes, vamos exemplificar ummtodo simples para verificar o funcionamento do balancea-mento utilizando a ferramenta IPERF.

Como em modo UDP, o IPERF no possui controlede fluxo nem controle de congestionamento, ento o clientetenta enviar dados ao servidor somente a taxa especificadapelo parmetro b. Assim, como em modo UDP no ocorre atransmisso confivel de dados, no existindo a necessidade

de que o servidor envie confirmaes ao cliente ao receberos dados, no h a necessidade de um servidor escutandona porta UDP especificada pelo cliente. Portanto, podemosutilizar somente um cliente IPERF gerando trfego em modoUDP e utilizar alguma outra ferramenta passiva de monitora-mento de redes para checar as taxas de transmisso atingidasem cada enlace.

No teste demonstrado na Figura 7.4 foram utiliza-dos 6 switches/roteadores Cisco ME 3400E e um clienteIPERF gerando trfego UDP. Nesse caso, 4 roteadores (R1,R2, R3 e R4) foram utilizados para simular um backbonecom Interior Gateway Protocol (IGP), especificamente oOSPF, com balanceamento de carga por fluxos e 2 deles (R5e R6) foram utilizados para simular dois enlaces com opera-doras distintas. Dois fluxos distintos de 50 Mbps foram gera-dos no mesmo cliente com destino para R5 e R6, durante 12horas (43200 segundos). Cada um dos comandos utilizadospara gerar cada um dos fluxos pode ser encontrado a seguir:

Fluxo 1:$iperf c 10.0.40.2 u b 50m t 43200 i 2Fluxo 2:$iperf c 10.0.40.2 u b 50m t 43200 i 2

Desse modo, podemos verificar as tcnicas de ba-lanceamento de trfego operando atravs da utilizao da fer-ramenta IPERF, por meio da gerao de trfego UDP, sem anecessidade de um servidor em operao. Casos similares aesse podem ser de grande valia quando for necessrio testarenlaces, mas no for possvel o acesso a um servidor IPERFpara responder s solicitaes.

Esse documento no visa demonstrar as tcnicas debalanceamento utilizadas nem como implement-las, pormas mesmas podem ser encontradas em [28]. Para obtermos asimagens referentes s taxas de transmisso em cada uma dasinterfaces de R1 foi utilizada a ferramenta RRDTool [29].Essa ferramenta simples e fcil de utilizar, sendo ampla-mente utilizada para monitoramento de redes de computado-res.

7.3. Gerao de Trfego UDP de Altas Taxas

Para caminhos em que sejam necessrios um espaode buffers grande, como o caso de caminhos em que o RTT alto por exemplo, necessrio que algumas opes de altaperformance, discutidas a seguir, sejam ativadas.

A maioria dos sistemas operacionais suportam li-mites de buffer de transmisso e recepo por conexo se-parados, os quais podem ser configurados pelo usurio, pelaaplicao ou outro mecanismo, contanto que estejam dentrodos limites mximos de memria.

Os tamanhos dos socket buffers padres podem seralterados por controles globais do sistema operacional. Oajuste manual desses buffers a maneira mais simples dese aumentar o desempenho de aplicaes quaisquer, como ocaso do IPERF.

Nessa seo, so exemplificados como os parme-tros de buffers em um sistema Linux devem ser alteradospara aumentarmos a taxa de gerao de trfego UDP como IPERF. O ajuste desses parmetros em outros tipos de sis-temas e uma explicao mais detalhada sobre transfernciade alto desempenho podem ser encontrados em [30].

CBPF-NT-003/14 11

10.0.

0.0/24

10.0.30.0/24

10.0.10.0/24 10.0.

20.0/

2410.0.40.0/24

192.168.0.0/24eth0

.105

g0/1

.50

g0/3

.2

g0/1

.1

g0/2.2

g0/1.1 g0

/2

.2

g0/2

.1

g0/3.1

g0/1.2

g0/2.2

g0/1.1

R2

R3

R4

R1

R5

Cliente IperfGerador de trfego

Roteador R5Destino do trfegofluxo 1: iperf -c 10.0.40.2 -u -b 50m -t 43200 -i 2

fluxo 2: iperf -c 10.0.50.2 -u -b 50m -t 43200 -i 2

10.0.50.0

/24g0/4

.1

g0/1

.1

R6

Roteador R6Destino do trfego

fluxo 1

fluxo 2

Figura 7. 4: Testes de balanceamento de carga com a ferramenta IPERF.

Em um sistema Linux, os parmetros do sistema po-dem ser lidos ou alterados pela ferramenta sysctl, como em:

Leitura de todos os parmetros: #sysctl a

Ajuste de parmetro: #sysctl w [parmetro]=[valor]

Os parmetros responsveis por alterar o tamanhodos buffers padro para sockets UDP para transmisso erecepo so, respectivamente: net.core.wmem_default enet.core.rmem_default[30]. Ao ajustarmos esses parme-tros conseguimos aumentar ou diminuir o tamanho do bufferUDP, de acordo com as necessidades. Por exemplo, podemosajustar ambos os buffers para 1 MB da seguinte forma:

root@iperf_client: # sysctl w net.core.wmem_default=1048576

root@iperf_server: # sysctl w net.core.rmem_default=1048576

Como valor inicial para ajuste do tamanho dos buf-fers o valor do BDP pode ser utilizado acrescentado de umvalor adicional referente a um overhead especfico do sis-tema operacional.

A Figura 7.5 exemplifica um caso testado em labo-ratrio, em que dois roteadores modelos Cisco ME3400 Eso conectados diretamente, sendo que o roteador R1 co-nectado ao cliente IPERF e o R2 possui uma rota para o en-dereo 192.168.250.1/32 apontando para Null0. Nesse caso,o cliente gera trfego UDP para o endereo 192.168.250.1sem receber nenhuma resposta, servindo apenas para testar-mos o enlace.

Assim sendo, para esse caso de um enlace a 1 Gbpse RTT de 1,691 ms, e considerando o overhead citado ante-

riormente, temos um tamanho de buffer de cerca de:

Buffer UDP=BDP(

1.000.000.000 bits1 segundo

1 byte8 bits

0,001691 segundo = 211375 bytes)

+overhead = 307200 bytes

Buffer Default(110 KB) Buffer Alterado (300 KB) Cliente

IPERF

# iperf -c 192.168.250.1 -u -b 1000m -t

20 -i 5

# iperf -c 192.168.250.1 -u -b 1000m -t 20 -i

5

Gerao

de

Trfego

---------------------------------------

Client connecting to 192.168.250.1, UDP

port 5001



---------------------------------------

[ 3] local 192.168.200.2 port 39549

connected with 192.168.250.1 port 5001


[ 3] 0.0- 5.0 sec 218 MBytes 365

Mbits/sec

[ 3] 5.0-10.0 sec 220 MBytes 370

Mbits/sec

[ 3] 10.0-15.0 sec 220 MBytes 369

Mbits/sec

[ 3] 15.0-20.0 sec 198 MBytes 332

Mbits/sec

[ 3] 0.0-20.0 sec 855 MBytes 359

Mbits/sec


[ 3] WARNING: did not receive ack of last

datagram after 10 tries.

-------------------------------------------

Client connecting to 192.168.250.1, UDP port

5001



-------------------------------------------

[ 3] local 192.168.200.2 port 50355

connected with 192.168.250.1 port 5001


[ 3] 0.0- 5.0 sec 337 MBytes 565

Mbits/sec

[ 3] 5.0-10.0 sec 352 MBytes 591

Mbits/sec

[ 3] 10.0-15.0 sec 358 MBytes 600

Mbits/sec

[ 3] 0.0-20.0 sec 1.37 GBytes 587

Mbits/sec


[ 3] WARNING: did not receive ack of last

datagram after 10 tries.

Tabela 7. 1: Alterao de buffer UDP para maior desempenho detransmisso.

Ento, conforme a Tabela 7.1 demonstra, um au-mento de aproximadamente 3 vezes o tamanho do bufferUDP default implicou em um aumento de 63,50% na taxade transmisso UDP. Dessa maneira, podemos alterar o ta-manho do buffer at encontrarmos a taxa de transmisso m-


Figura 7. 5: Layout da rede de teste para gerao de trfego UDP de altastaxas.

xima UDP que conseguimos obter para um determinado en-lace.

8. CONCLUSO

O presente trabalho visou demonstrar a utilizaoda ferramenta de gerao e medio de trfego IPERF. Pri-meiramente, foram apresentadas uma viso geral das ferra-mentas de medio ativa de redes e da ferramenta IPERF. Emseguida, foi apresentada uma breve introduo sobre os prin-cipais conceitos referentes aos protocolos UDP e TCP, pri-mordiais para compreender o funcionamento da ferramenta.Em sequncia, foram apresentados os procedimentos de ins-talao da ferramenta, os parmetros principais de utilizaoe, por fim, alguns casos prticos em que pode ser utilizada.

Em suma, dentre os protocolos de transporte o TCPfragmenta as mensagens da aplicao em pacotes IP, po-dendo realizar a deteco e correo de erros, o controle defluxo fim-a-fim (da origem ao destino), alm de ser um pro-tocolo orientado a conexes. O UDP no orientado a co-nexo, no faz controle de fluxo nem de congestionamento eno garante que os pacotes sejam entregues ao destino. Ba-sicamente, ele serve para transaes que envolvem apenasmensagens curtas, rpidas e do tipo pergunta/resposta. Ouseja, til para situaes em que a rapidez mais importantedo que a preciso. Apesar de servir, essencialmente, paratransmisso de mensagens curtas, o que implica em baixautilizao de banda, muito se tem estudado para otimizaoda pilha de protocolos UDP/IP sobre redes de altas velocida-des [31].

Em se tratando da ferramenta IPERF, os procedi-mentos de instalao apresentados na seo 5 demonstraramser bastante simples e rpidos, tanto para plataformas Win-dows quanto Linux. O mesmo se aplica a outras plataformascomo MAC e Solaris, no tendo sido apresentados nesse do-cumento.

O IPERF se mostrou uma ferramenta simples, po-rm muito til. Ela pode ser utilizada para testar o desem-penho de conexes TCP e sesses UDP, alm da perda depacotes e jitter atravs do modo UDP. Prov informaesbsicas necessrias para a soluo de problemas relaciona-dos aos protocolos UDP e TCP.

Como a banda disponvel pode ser influenciada pordiversos fatores, como os citados a seguir, o IPERF demons-tra ser mais til para testes em ambientes fora de produo:

1. os horrios do dia e dias da semana em que as medi-es so realizadas;

2. carga muito alta de utilizao de CPU, o que pode im-pedir que a aplicao e a pilha de protocolos de rede

obtenham tempo suficiente de CPU para processar ospacotes;

3. rotas em uso no momento das medies. Em algunsmomentos, diferentes caminhos na rede podem ser to-mados, implicando em atrasos diferentes, podendo ge-rar entregas fora de ordem e, consequentemente, pro-vocando retransmisses no caso do TCP

Devido a esses e outros fatores, tais como: rotasassimtricas do cliente para o servidor e do servidor para ocliente; e a compresso de dados em funo dos protocolosutilizados pela aplicao, os testes de largura de banda devemser realizados de forma bidirecional. Isso permite verificarse a banda disponvel comparvel em ambos os sentidosdependendo de que n esteja sendo usado como servidor.

Alm disso, vale ainda ressaltar que os testes UDPrealizados utilizando somente o cliente IPERF til para ca-sos em que somente se deseja saturar enlaces e se tem co-nhecimento da banda de cada enlace em todo o caminho.Para casos em que se deseja medir a banda til, reportandoa perda de pacotes e o jitter, necessrio a utilizao do ser-vidor IPERF, sendo possvel assim notar congestionamentosna rede.

Contudo, o IPERF ainda apresentou como princi-pais caractersticas:

1. Simplicidade de uso;

2. Eficcia no que se prope, que gerar e medir o tr-fego;

3. Permisso de utilizar dados reais para simular a trans-ferncia confivel de dados, simulando o envio atravsde um protocolo de transferncia confivel de dadoscomo o FTP;

4. Auxlio na compreenso de como a alterao dos pa-rmetros do TCP, como a janela TCP e a utilizao doalgoritmo de Nagle, podem influenciar na utilizao dalargura de banda disponvel;

5. Auxlio a administradores de rede a dimensionar asaplicaes que fazem uso da rede, como por exemploa vazo de servidores.

6. Possibilidade de gerar trfego UDP de altas taxas, sema necessidade de um servidor para receber o trfego,simplificando os testes na rede.

Entretanto, apesar das caractersticas positivas que aferramenta apresenta, ela ainda carece de algumas melhoriaspara o seu aprimoramento. Dentre elas, podemos citar as queforam consideradas como mais pertinentes:

1. Medio do atraso de ida e volta dos pacotes direta-mente pela aplicao IPERF, para auxiliar no clculodo BDP.

2. Mtodo de deteco da largura de banda de cada umdos enlaces no caminho dos pacotes na rede, a fim dedetectar gargalos fim a fim, para auxiliar na detecode congestionamentos na rede.

CBPF-NT-003/14 13

3. Mtodo de deteco do modo Duplex (Half ou Full)de cada um dos enlaces fim a fim.

Cada uma dessas consideraes tornam-se relevan-tes para melhorar a anlise e desempenho de redes atravs daferramenta IPERF.

Em sntese, pode-se afirmar que o IPERF torna sim-ples medir o desempenho de aplicaes baseadas em fluxosTCP e UDP, apesar de no ser possvel simular e testar odesempenho de todo tipo de aplicao, como o caso deaplicaes Web interativas.

[1] KISSEL, E. et al. Efficient wide area data transfer proto-cols for 100 Gbps networks and beyond. Proceedings of theThird International Workshop on Network-Aware Data Mana-gement. Denver, Colorado: ACM: 1-10 p. 2013.2

[2] GARZOGLIO, G. et al. Big Data Over a 100G Networkat Fermilab. Journal of Physics: Conference Series, v.513, n. 6, p. 7, 2014. ISSN 1742-6596. Disponvel em:.

[3] PINTO, J. D. O. et al. DWDM em Redes Metropolitanas. NotaTcnica do CBPF NT001/02. Rio de Janeiro, Brasil 2002.

[4] ESTEVES, A. M. B. Sistema de monitoramento de redesbaseado nos protocolos SNMP e SpanningTree 2013. (Disser-tao de Mestrado em Fsica - Instrumentao Cientfica).Centro Brasileiro de Pesquisas Fsicas, Rio de Janeiro, RJ,Brasil.

[5] MIRANDA, E. F. Desenvolvimento de Sitema para Moni-toramento de Redes de Computadores e Servidor LookingGlass 2013. (Dissertao de Mestrado em Fsica - Instrumen-tao Cientfica). Centro Brasileiro de Pesquisas Fsicas, Riode Janeiro, RJ, Brasil.

[6] MIRANDA, E. F.; ALVES JR., N.; SOUZA, M. G. M. Desen-volvimento de um Repositrio RIB-BGP. Notas Tcnicas doCBPF, Rio de Janeiro, RJ, Brasil, v. 3, n. 2, p. 6, 2013. ISSN0101-9201. Disponvel em:.

[7] ALVES JR., N. et al. Topologia e Modelagem Relacional daInternet Brasileira. Nota Tcnica do CBPF - NT-004/4. Rio deJaneiro, RJ, Brasil 2004.

[8] ALVES JR., N. Caracterizao de redes complexas aplicao modelagem relacional entre Sistemas Autnomos da Inter-net 2007. (Tese de Doutorado em Modelagem Computacio-nal). IPRJ, Universidade do Estado do Rio de Janeiro, NovaFriburgo, RJ, Brasil.

[9] CACTI GROUP INC. Cacti - The complete RRDTool-based graphing solution. 2014. Disponvel em:. Acesso em: 27 de julho de2014.

[10] OETIKER, T. MRTG - Tobi Oetikers MRTG - TheMulti Router Traffic Grapher. 2011. Disponvel em:. Acesso em: 28 de julhode 2014.

[11] LABIT, Y.; OWEZARSKI, P.; LARRIEU, N. Evaluation ofActive Measurement Tools for Bandwidth Estimation in RealEnvironment. Third IEEE/IFIP Workshop on End-to-End Mo-nitoring Techniques and Services, E2EMON. Nice, Frana:IEEE: 71 - 85 p. 2005.

[12] DOWNEY, A. B. Clink: a tool for estimating In-ternet link characteristics. 1999. Disponvel em:. Acesso em:28 de julho de 2014.

[13] FRENCH FORUM FOR IPERF. Iperf. 2014. Disponvel em:< https://iperf.fr/ >. Acesso em: 28 de julho de 2014.

[14] JONES, R. Netperf Homepage. 2014. Disponvel em:. Acessoem: 28 de julho de 2014.

[15] DOVROLIS, C. Pathrate - A measurement tool for

the capacity of network paths. 2006. Disponvel em:.Acesso em: 28 de julho de 2014.

[16] NUTTCP DEVELOPMENT TEAM. NUTTCPWelcome Page. 2014. Disponvel em:.Acesso em: 28 de julho de 2014.

[17] APPNETA. PathView - Network health monitoring over anynetwork. 2014. Disponvel em:. Acesso em:28 de julho de 2014.

[18] NCSA NEWS REPORT TEAM. NLANR DAST Team Re-leases New Software. NCSA NEWS, 2001. Disponvel em:. Acesso em: 12 de maio de 2014.

[19] POSTEL, J. RFC 768 - User Datagram Protocol. Internet En-gineering Task Force (IETF), p.3. 1980.

[20] COMMER, D. E. Redes de Computadores e Internet. 4a edi-o. ed. Porto Alegre: Artmed/Bookman, 2007.

[21] POSTEL, J. RFC 793 - Transmission Control Protocol. Inter-net Engineering Task Force (IETF), p.85. 1981.

[22] REZENDE, J. F. D.; COSTA, L. H. M. K.; RUBINSTEIN,M. G. Avaliao Experimental e Simulao do Protocolo TCPem Redes de Alta Velocidade XXII Simpsio Brasileiro deTelecomunicaes - SBrT05 Campinas, SP, Brasil: 6 p. 2005.

[23] ALLMAN, M.; PAXSON, V.; BLANTON, E. RFC 5681 -TCP Congestion Control. Internet Engineering Task Force(IETF), p.18. 2009.

[24] CONSTANTINE, B. et al. RFC 6349 - Framework for TCPThroughput Testing. Internet Engineering Task Force (IETF),p.27. 2011.

[25] KUROSE, J. F.; ROSS, K. W. Redes de computadores e a In-ternet: uma abordagem top-down. 5a edio. So Paulo: Ad-dison Wesley, 2010.

[26] TANEMBAUM, A. S. Redes de Computadores. 3a edio. SoPaulo: Elsevier, 2003.

[27] CISCO SYSTEMS INC. Configuring EtherChannels. In:(Ed.). Cisco ME 3400 Switch Software Configuration Guide,Rel. 12.2(25)EX. San Jose, California, Estados Unidos, 2005.cap. 31, p.602 - 623.

[28] CISCO SYSTEMS INC. Configuring a Load-BalancingScheme. In: (Ed.). IP Switching Cisco Express ForwardingConfiguration Guide. San Jose, California, Estados Unidos,2012. cap. 5, p.47 - 58.

[29] OETIKER, T. About RRDtool - Logging and graphing 2013.Disponvel em: . Acesso em:12 de maio de 2014.

[30] PITTSBURGH SUPERCOMPUTING CENTER. Ena-bling High Performance Data Transfers. 2014. Disponvelem: . Acesso em: 12 de maio de 2014.

[31] JIN, H.-W.; YOO, C. Impact of protocol overheads onnetwork throughput over high-speed interconnects: measure-ment, analysis, and improvement. J. Supercomput., v. 41, n. 1,p. 17-40, 2007. ISSN 0920-8542.

Documents

Ferramenta IPERF Geração e Medição de Tráfego TCP e UDP