6/6/2014 Blog LabCisco: IPERF no Monitoramento de Desempenho em Redes

http://labcisco.blogspot.com.br/2013/04/iperf-no-monitoramento-de-desempenho-em.html 1/5

Seja bem-vindo ao Blog LabCisco, um espaço para que os leitores dos livros do Prof. Samuel Henrique Bucke Brito possam expandir a experiência de leitura através de

novos artigos em formato de laboratório e que também traz novidades da área de telecomunicações e redes de computadores.

Início Downloads & Laboratórios Canal no YouTube Autor UNIMEP

Patrocínio Ouro

Pesquisar no Blog

domingo, 14 de abril de 2013

IPERF no Monitoramento de Desempenho em Redes

Olá Pessoal.

O IOS da Cisco traz algumas ferramentas bem úteis para medir o desempenho de dispositivos

de interconexão em infraestrutura de redes (switches, roteadores, etc), a exemplo do SLA-

Monitor e do NetFlow. É igualmente importante a tarefa de monitoramento e avaliação do

desempenho dos links das estações até os servidores da rede, para garantir que a vazão

dimensionada para fins de acesso aos recursos dos servidores esteja realmente adequada.

É nesse contexto que uma ferramenta muito útil denominada Iperf se destaca pela sua

simplicidade e principalmente por ser gratuita. O Iperf é um software livre que foi desenvolvido

pelo National Laboratory for Applied Network Research (NLANR). Ele foi originalmente

desenvolvido para fins de pesquisa com o intuito de testar a largura de banda (throughput) em

links, ou seja, medir o desempenho de redes de computadores. O software não possui interface

gráfica, sendo sua operação muito simples através da linha de comando. Também existe uma

versão do Iperf em Java, denominada Jperf, que possui interface gráfica e que gera gráficos a

partir das medidas realizadas.

Em síntese a operação do Iperf se resume à sua execução entre duas máquinas, uma em modo

servidor que ficará "ouvindo" as requisições e outra em modo cliente que ficará responsável por

gerar tráfego para estressar a rede e extrair as medidas de desempenho.

Para exemplificar o uso dessa ferramenta vamos considerar o cenário ilustrado na figura abaixo

que é bem simples e suficiente para a demonstração. Iremos executar o software em modo

servidor na máquina File-Server (Windows Server 2008) para posteriormente executarmos o

software em modo cliente em qualquer máquina, por exemplo um notebook executando Linux

para fins de análise de desempenho.

Participar deste siteGoogle Friend Connect

Membros (216) Mais »

Já é um membro? Fazer login

Login | Comunidade

Blog Lab Cisco

1.790Curtir

CURTIR no Facebook

Patrocínio Prata

Comprar o Livro de Laboratórios

Comprar o Livro de IPv6

6/6/2014 Blog LabCisco: IPERF no Monitoramento de Desempenho em Redes

http://labcisco.blogspot.com.br/2013/04/iperf-no-monitoramento-de-desempenho-em.html 2/5

O leitor pode baixar o Iperf para Linux e Windows através da página oficial do projeto em

http://sourceforge.net/projects/iperf/. A ferramenta é multiplataforma e o teste funciona

normalmente entre estações Linux-Linux, Windows-Linux ou Windows-Windows. Para executar

o software em modo servidor, basta digitar o seguinte comando:

iperf -s

A partir desse momento a máquina estará ouvindo requisições TCP na porta 5001, onde o

cliente posteriormente irá gerar tráfego para estressar o enlace entre cliente-servidor. Feito isso,

a partir de outra máquina qualquer na rede que tenha alcançabilidade IP ao servidor, seja no

contexto da mesma rede local ou mesmo atrás de roteadores, podemos executar o software em

modo cliente com o seguinte comando:

iperf -c 192.168.7.3

Por padrão o cliente irá gerar tráfego TCP na porta 5001 do servidor (192.168.7.3) durante 10

segundos. Reparem que no exemplo da figura abaixo utilizei alguns parâmetros opcionais para

alterar o tempo padrão (de 10s para 15s) e também o intervalo de geração dos relatórios para

registrar as medidas a cada 1s. Há vários outros parâmetros que você pode (e deve) explorar,

então trago um resumo das principais opções:

- s -> Execução em modo servidor na porta 5001

- c -> Execução em modo cliente, sendo necessário informar o IP do servidor

- b -> Define a banda a ser utilizada em bps (apenas para UDP)

- d -> Gera tráfego nos dois sentidos (por padrão o tráfego é sentido cliente->servidor)

- u -> Utiliza o UDP como protocolo de transporte

- f -> Define a unidade do relatório, que pode ser: Kbits, Mbits, KBytes, MBytes

- i -> Define o intervalo de tempo de registro do relatório de saída

- m -> Exibe na saía o tamanho máximo do MTU

- o -> Armazena a saída em arquivo externo, ex.: -o <nome-do-arquivo>

- p -> Altera a porta padrão de execução, ex.: iperf -s -p 2222

- P -> Somente em modo cliente, gera tráfego simulando vários clientes em paralelo

- t -> Define o tempo de duração dos testes, sendo o padrão 10 segundos

labcisco.blogspot.com.br

97.57% / 2.43%

IPv 4

189.89.242.89

Esse blog é acessível via

IPv6. Se o globo estiver

girando, então você

também possui conexão

IPv6.

Sua Conexão

IPv 6

not available

Atualizações no E-Mail

Email address... Submit

► 2014 (33)

▼ 2013 (81)

► Dezembro (5)

► Novembro (3)

► Outubro (4)

► Setembro (6)

► Agosto (7)

► Julho (8)

► Junho (5)

► Maio (7)

▼ Abril (6)

Espelhamento de Portas emSw itches Remotos (RSPAN)...

Configuração de Espelhamento dePortas em Sw itch

IPERF no Monitoramento deDesempenho em Redes

Falha na Atualização KB2823324da Microsoft

Categorias de Cabos de Par-Trançado

Palestra de IPv6 na UNIMEP

► Março (7)

► Fevereiro (11)

► Janeiro (12)

► 2012 (15)

Arquivo de Postagens

Lançamento do Cisco Packet Tracer6.0.1

Configuração de Sw itch Multi-Layer(Layer-3)

Categorias de Cabos de Par-Trançado

O Espectro Eletromagnético naNatureza

Configuração da Nuvem MPLS emProvedores

Novo Livro CCNA 5.0

Wireshark na Análise de Tráfego eProtocolos em Redes

Interpretação dos Resultados do Ping

Top 10 Posts

6/6/2014 Blog LabCisco: IPERF no Monitoramento de Desempenho em Redes

http://labcisco.blogspot.com.br/2013/04/iperf-no-monitoramento-de-desempenho-em.html 3/5

Postado por Samuel Henrique Bucke Brito às 00:17

Marcadores: Desempenho, Gerenciamento, LAN, Monitoramento, NMS, SLA

No exemplo da figura anterior (que representa a saída do software cliente) a gente pode observar

que durante o teste a largura de banda apresentou uma variação média entre 9Mbps e 15Mbps,

cujo PÉSSIMO resultado é um indicativo de problema se o link entre o cliente e o servidor for de

100 Mbps ou 1 Gbps.

No projeto de uma rede você sempre deve ter em mente que a vazão dos servidores deve ser

suficientemente maior que a vazão das estações para que os recursos dos servidores possam

ser simultaneamente utilizados por várias estações. Resultados ruins no teste com essa

ferramenta podem demonstrar que o link do servidor está subdimensionado nos horários de pico

em que existem múltiplas máquinas querendo acessar os recursos do servidor.

Outra opção muito útil é realizar a medição anterior utilizando o UDP como protocolo de

tranpsorte. O interessante de fazê-lo é que também será medido o jitter do enlace, ou seja, a

variação entre os tempos de latência fim-a-fim (atraso) na comunicação - uma importante

métrica de desempenho para verificar a estabilidade (ou instabilidade) da rede.

Para realizar a medição via UDP, basta adicionar o parâmetro "-u" no servidor (iperf -s -u)

e cliente (iperf -c 192.168.0.1 -u). Há outros parâmetros e caso vocês queiram

conhecer mais detalhes da ferramenta, recomendo a leitura da documentação técnica

disponibilizada na página oficial do projeto. Espero que esse artigo seja útil no dia-a-dia de

vocês, usem e abusem da ferramenta.

Abraço.

Samuel.

+2 Recomende isto no Google

Respostas

Responder

9 comentários:

Renato Silva 14 de agosto de 2013 13:40

Excelente já utilizei a ferramenta! Muito bom o artigo.

Responder

Academia de Tecnologia da Informação 7 de setembro de 2013 19:20

Ótimo artigo, obrigado, estava apenas observando que alguns autores como Forouzan e Michal A. Gallo,

diz que largura de banda é o que temos de capacidade total do link, e throughput (vazão) é o que

realmente sai do link que deve ser menor ou igual a largura de banda.

Responder

Samuel Henrique Bucke Brito 9 de setembro de 2013 00:40

Conceitualmente essa definição está perfeitamente correta! As ferramentas de teste que

estressam o link têm por objetivo gerar tráfego até atingir o limite REAL do link - que

normalmente não é exatamente o limite nominal.

Abraço.

Anônimo 8 de setembro de 2013 21:20

"No projeto de uma rede você sempre deve ter em mente que a vazão dos servidores deve ser

suficientemente maior que a vazão das estações para que os recursos dos servidores possam ser

simultaneamente utilizados por várias estações" - Professor, quando você relata isso, poderia ser um

IPERF no Monitoramento deDesempenho em Redes

Servidor de Terminais no PacketTracer 6 Beta

Status do IPv6

Sep 20, 2019

Apr 15, 2011

Feb 06, 2015

Jul 28, 2014

Sep 14, 2012

IPv4 ExhaustionCounter

▼Present Status (RIR)

X-day and Reserved Blocks

AfriNIC

3.18

APNIC

0.89

ARIN

0.94

LACNIC0.33

RIPE NCC1.08

（Remaining /8）

via IPv4

Status do IPv4

246,059

Acessos ao Blog

Em Defesa da Internet

200-120 (12)

802.11 (1)

802.3 (3)

ACL (3)

ANSI/TIA (1)

ARP (1)

AS (7)

Backup (1)

BGP (6)

Big-Data (2)

Blog (7)

Cabo (2)

Cat5e (1)

Cat6 (1)

Cat6A (1)

Cat7 (1)

CCNA (8)

CEF (1)

Busca por Palavra-Chave

6/6/2014 Blog LabCisco: IPERF no Monitoramento de Desempenho em Redes

http://labcisco.blogspot.com.br/2013/04/iperf-no-monitoramento-de-desempenho-em.html 4/5

Respostas

Responder

Respostas

Responder

Respostas

Responder

dimensionamento tipo: Link do servidor em GB e das estações em MB, nesse caso, teríamos uma rede

extra só para os servers correto?

Aproveitando essa pergunda, existe algum calculo de dimensionamento para essas tarefas? No exemplo

acima, como poderia f icar esse dimensionamento?

Sugestão, poderia fazer um curso desses tópicos em um curso de fundamentos de redes, que seria pré-

requesitos para os que já tem no seu EAD, e explorar essas tools e outras como o iperf, iptraf, w ireshar,

entres outras, e outros simuladores!

Parabéns pelo blos e artigos!! Estou visualizando todos sem correria! :-)

Responder

Samuel Henrique Bucke Brito 9 de setembro de 2013 00:44

A definição desses limiares depende totalmente do perfil do ambiente e envolve tanto os

equipamentos da infraestrutura (incluindo os links), como também o uso que é feito das

aplicações. Ou seja, não basta simplesmente manter as estações operando a 100Mbps e os

servidores a 1 ou 2 Gbps simplesmente para garantir que o servidor tenha mais vazão para

atender várias estações simultaneamente. É necessário saber o uso que as estações no

nível de acesso fazem dos serviços nos servidores para dimensionar sua vazão!

Já recebi várias sugestões para fazer um curso nesses moldes, mas gravar as aulas

consome muito tempo e ultimamente estou envolvido em vários projetos que não me permitem

fazê-lo.

Abraço.

Anônimo 9 de setembro de 2013 00:53

Professor Samuel, você mencionou "É necessário saber o uso que as estações no nível de acesso

fazem dos serviços nos servidores para dimensionar sua vazão!"

Poderia explicar essa oração com um caso prático, f icou meio abstrato pra mim ainda essa dúvica!

Exite alguma ferramenta que posso dimensionar essa questão, já que o gargalo já posso usar IPERF!

Pensei q só aumentar o meio de transmissão do servidor já resolvia a questão de múltiplas conexão dos

clientes!

Grato pelo feedback!!

Responder

Samuel Henrique Bucke Brito 9 de setembro de 2013 01:46

Com qual frequência uma determinada estação faz requisições aos servidores

(isoladamente)? Todas essas requisições implicam em quanto de uso de banda ao longo do

tempo?

Aumentar a capacidade de transmissão do link do servidor melhora o desempenho, sem

dúvidas, mas a questão é: Aumentar para quanto? O objetivo de mapear as máquinas de

acesso é justamente conseguir constuir um modelo determinístico!

Quanto mais estações existirem, então mais máquinas têm que ser atendidas pelo(s)

servidor(es). Quanto mais conexões cada estação faz individualmente ao(s) servidor(es),

então mais conexões têm que ser atendidas. Atender às máquinas e suas conexões requer

banda.

Anônimo 9 de setembro de 2013 15:07

Muito grato pela resposta, clara e objetiva!! Vc usa algum softw are para dimensionar essas

requisições/banda isoladamente para um cliente ao servirdor? Existe?

Abs

Responder

Samuel Henrique Bucke Brito 9 de setembro de 2013 19:23

Há vários softw ares de monitoramento que fazem essa tarefa, seja através do SNMP ou

através de processos locais. No contexto específ ico de uma infraestrutura baseada em

equipamentos Cisco (sw itches e roteadores), o NetFlow é MUITO útil para esse f im. Através

dele você consegue classif icar o tráfego em fluxos, ou seja, é possível visualizar

especif icamente o f luxo relacionado a um determinado sistema em execução em algum

servidor.

Abraço.

Certif icação (11)

CGI.br (6)

Cisco (64)

Classe D (2)

CORE (3)

Desempenho (9)

DHCP (6)

DHCP Snooping (1)

Disponibilidade (3)

Educação (8)

EGP (5)

EIGRP (3)

Entrevista (1)

Errata (2)

Ether-Channel (1)

Ethernet (5)

Facebook (1)

Fibra Óptica (2)

Fotos (2)

Física (1)

Gerenciamento (7)

GNS (2)

Governança (4)

ICMPv6 (4)

IEEE (4)

IETF (3)

IGP (2)

Informatize-se (1)

Internet (30)

IOS (6)

IoT (2)

IPSec (3)

IPv4 (14)

IPv6 (38)

ISP (4)

ISR (1)

Laboratório (49)

LACNIC (2)

LAN (5)

Linux (10)

Livros (18)

Marco Civil da Internet (3)

MIB (1)

Microsoft (4)

Monitoramento (7)

MPLS (1)

Multicast (3)

Multimídia (4)

NAT (1)

NDP (1)

Negócios (2)

NetFlow (1)

NIC.br (17)

NMS (3)

Notícias (15)

NTP (2)

Ondas (1)

OSPF (3)

Packet-Tracer (3)

Palestra (8)

Par-Trançado (1)

Peering (4)

Pesquisa (1)

PIM-DM (2)

PIM-SM (2)

Ping (1)

PoE (1)

Policing (2)

Policy-Map (2)

PSTN (1)

PTT (2)

Pós-Graduação (2)

QoS (4)

Redes Convergentes (2)

Redistribuição (1)

Relay-Agent (1)

Restrição de Banda (1)

6/6/2014 Blog LabCisco: IPERF no Monitoramento de Desempenho em Redes

http://labcisco.blogspot.com.br/2013/04/iperf-no-monitoramento-de-desempenho-em.html 5/5

Postagem mais recente Postagem mais antigaInício

Assinar: Postar comentários (Atom)

Digite seu comentário...

Comentar como: Conta do Google

Publicar

Visualizar

RFC (6)

Rotas (2)

Roteamento (12)

Route-Map (1)

Route-Reflector (1)

SDN (1)

Segurança (11)

Shaping (1)

SLA (5)

SNMP (1)

SSH (1)

STP (2)

Sw itch (14)

Telecomunicações (4)

Teleconferência (1)

Telefonia (2)

Telnet (1)

Terminal-Server (1)

TV (2)

UNIMEP (14)

VLAN (4)

VoIP (2)

VPN (4)

VRF (2)

Vídeo (10)

WAN (2)

Wireless (3)

Wireshark (3)

WLAN (1)

Prof. Samuel Henrique Bucke Brito. Modelo Simple. Tecnologia do Blogger.