blog labcisco_ iperf no monitoramento de desempenho em redes
TRANSCRIPT
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.