Suporte a VLAN Trunk em Servidores Linux

Olá Pessoal.

Tradicionalmente utilizamos switches multi-layer ou roteadores quando precisamos fazer o roteamento inter-VLAN em ambientes que possuem múltiplas VLANs associadas com suas respectivas sub-redes, uma vez que essas caixas especializadas oferecem suporte nativo ao encapsulamento 802.1q (trunk). Em um dos artigos mais lidos do blog, intitulado "Configuração de Switch Multi-Layer", explico ao leitor como configurar um switch Cisco para essa finalidade, através da criação de interfaces virtuais vinculadas às suas VLANs, de maneira que essas interfaces podem ser configuradas com um IP que será o gateway de todas as máquinas membros da respectiva VLAN.

Essa mesma tarefa pode ser configurada em um servidor Linux, por isso a topologia apresentada abaixo será utilizada para exemplificar o processo de configuração de roteamento inter-VLAN no Linux. Assim como nos artigos anteriores, estou considerando que o roteador Linux está instalado com a distribuição Debian GNU/Linux (ou seus derivados, como o Ubuntu). 

A primeira etapa consiste na instalação do pacote denominado vlan para que, posteriormente, as configurações de rede do Linux ofereçam suporte à criação de interfaces lógicas roteadas (layer-3) do tipo VLAN. Essa tarefa é simples e rápida através do APT:

apt-get install vlan

Agora basta editar o arquivo de configuração das interfaces de rede que fica localizado em "/etc/network/interfaces". A partir da interface física eth0 (trunk 802.1q), criaremos duas novas interfaces lógicas denominadas eth0.100 (vlan100) e eth0.200 (vlan200).

###--- em /etc/network/interfaces

auto eth0
iface eth0 inet manual

   auto eth0.100
   iface eth0.100 inet static
      address 192.168.100.254
      netmask 255.255.255.0

   auto eth0.200
   iface eth0.200 inet static
      address 192.168.200.254
      netmask 255.255.255.0

Na sintaxe eth0.100 fazemos referência à interface física antes do ponto e, depois do ponto, fazemos referência ao número da VLAN vinculada à interface. É somente depois da instalação do pacote vlan que o Linux passa a reconhecer essa sintaxe. Uma alternativa válida seria utilizar uma convenção diferente de nomes em que fazemos referência direta à VLAN na denominação da interface em conjunto com o parâmetro vlan-raw-device para associá-la a sua respectiva VLAN. O exemplo abaixo traz a mesma configuração anterior com essa sintaxe alternativa:

###--- em /etc/network/interfaces

auto eth0
iface eth0 inet manual

auto vlan100
iface vlan100 inet static
   vlan-raw-device eth0
   address 192.168.100.254
   netmask 255.255.255.0

auto vlan200
iface vlan200 inet static
   vlan-raw-device eth0
   address 192.168.200.254
   netmask 255.255.255.0

Como o Linux não permite o roteamento entre sub-redes por padrão, é necessário instruir seu kernel a fazê-lo por meio de um dos comandos abaixos, lembrando que a primeira opção é volátil, ou seja, será perdida em caso de boot, enquanto que a segunda opção é persistente:

opção 1) echo "1" > /proc/sys/net/ipv4/ip_forward
opção 2) sysctl -w net.ipv4.ip_forward=1

Obs.: Vale ressaltar que as interfaces lógicas do tipo VLAN são diferentes das tradicionais sub-interfaces lógicas vinculadas às interfaces físicas. A criação de sub-interfaces lógicas é uma técnica simples de virtualização de interfaces físicas nativamente reconhecida pelo Linux, procedimento realizado através da sintaxe ethX:X. Por outro lado, o Linux torna-se capaz de interpretar cabeçalhos 802.1q (trunk) quando utilizamos o pacote vlan para criar interfaces lógicas roteadas do tipo VLAN (sintaxe ethX.X).

Façam seus testes...

Samuel.

Paradigma SDN de Redes Programáveis

Olá Pessoal.

Um tema ainda recente na área de redes de computadores e que tem se destacado de maneira crescente nos últimos anos, inclusive com a adoção de algumas soluções comerciais por parte das principais empresas fabricantes de dispositivos de redes, é um novo paradigma de controle da infraestrutura conhecido como SDN (acrônimo de Software-Defined Network).

O termo surgiu em 2005 decorrente de pesquisas originalmente desenvolvidas pela Universidade de Stanford. O principal argumento favorável à SDN é que essa abordagem viabiliza que os serviços em execução na infraestrutura de rede podem ser gerenciados mais facilmente e com grande flexibilidade. Qual seria a idéia principal dessa presunção? É isso que vou tentar elucidar de maneira objetiva nesse artigo...

Atualmente na arquitetura dos principais dispositivos de redes (hardware), a exemplo de roteadores e switches, é comum organizarmos a disposição dos seus componentes eletrônicos em dois planos lógicos que são conhecidos como: 

1. Plano de Dados ou Encaminhamento 
2. Plano de Controle ou Gerência. 

O motivo de fazê-lo é garantir máximo desempenho à principal tarefa desses dispositivos: o encaminhamento de pacotes entre suas interfaces. No entanto o encaminhamento não pode ocorrer por si só sem informações de controle que determinem a inteligência dessas ações. 

Como a tarefa de encaminhamento de pacotes entre interfaces é bastante direta e objetiva, então sua implementação faz parte do plano de encaminhamento. Já a implementação da inteligência que diz respeito à gerência, configurações e protocolos dos dispositivos faz parte do plano de controle. 

Para entender melhor tudo isso vamos pegar como exemplo um roteador. Sabemos que o processo de roteamento, seja estático ou dinâmico, somente é possível porque os roteadores formam uma tabela de roteamento com informações que são consultadas para determinar o destino dos pacotes, o que torna possível encaminhá-los para suas respectivas interfaces de saída que devem alcançar o destino previsto.

A descrição acima é verdadeira, mas muito simplista. Na realidade existem memórias eletrônicas na arquitetura dos roteadores que armazenam algumas estruturas de dados que são utilizadas em variados contextos. Então vamos detalhar um pouco mais essas estruturas, mas tenham em mente que o exemplo aqui trazido é generalista e diferentes fabricantes podem implementar essas estruturas de maneira particular em seus equipamentos! Observem na figura abaixo os principais componentes de um roteador:

É no plano de controle que fica armazenada uma estrutura de dados denominada RIB (Routing Information Base). Essa estrutura é reponsável por armazenar todas as informações de vizinhança entre os roteadores e todas as rotas conhecidas até um determinado destino, seja ela a melhor ou não - simplesmente todas as rotas possíveis estão armazenadas nessa estrutura. É com base nessas estruturas que agem os principais protocolos de roteamento, seja para adicionar, modificar, remover ou consultar seu conteúdo. É de se imaginar que essa estrutura normalmente não é pequena e que esse processo de implementar a inteligência da rede não é simples porque envolve a ação de algoritmos que podem ser bem complexos.

Para otimizar o desempenho de encaminhamento dos roteadores existe outra estrutura de dados no plano de encaminhamento que é denominada FIB (Forwarding Information Base), essa sim mais próxima da tradicional tabela de roteamento que consultamos frequentemente no cotidiano. A FIB é uma estrutura bem mais simples que armazena somente a melhor rota para cada destino, ou algumas melhores dependendo da inteligência de roteamento. Normalmente essa estrutura é implementada através de tabelas hash para torná-la menor e agilizar o processo de busca de informação (lookup). 

Ou seja, a FIB (plano de encaminhamento) é gerada a partir da RIB (plano de controle). Dessa forma a operação do plano de encaminhamento ganha um certo grau de independência dos processos em execução no plano de controle e os dispositivos de rede podem fazer um lookup mais rápido e eficiente, o que reflete no desempenho do encaminhamento de pacotes. Em síntese, o plano de encaminhamento se limita a receber os pacotes, buscar uma correspondência na FIB e fazer o encaminhamento dos pacotes se houver essa correspondência. Mais uma vez reforço que essa descrição não é uma regra e pode variar na implantação de diferentes dispositivos e de diferentes fabricantes!

O paradigma SDN propõe uma ruptura nesse modelo tradicional, através do desacoplamento ainda maior entre os planos de controle e de encaminhamento. Assim passam a existir novos elementos na rede que ficam "exclusivamente" responsáveis pelo controle (inteligência), denominados controladores. E mais, esses controladores são programáveis via software, o que permite que toda a rede seja gerenciada e até mesmo remodelada com base em suas necessidades reais. A figura abaixo ilustra essa proposta:

Ao fazê-lo os dispositivos da infraestrutura tornam-se eletronicamente bastante simplificados porque seu foco passa a ser a tarefa de encaminhamento dos pacotes (plano de encaminhamento), desde que haja interfaces programáveis via software (API) que possam se comunicar com os controladores externos. Existem algumas propostas de padronização dessas APIs, mas sem dúvidas a mais conhecida delas é o OpenFlow que, a cada dia, passa a ser aderido por mais empresas fabricantes de dispositivos de redes.

Embora SDN seja o nome consagrado na academia (e isso não deve mudar), eu particularmente não acho que o nome Software-Defined Network seja o mais adequado, visto que atualmente é comum a implementação dos planos através de software na arquitetura interna (localmente) dos dispositivos. Ao meu ver a mudança mais visível na SDN é a idéia da controladora externa, algo que na realidade não chega a ser uma grande novidade se tomarmos como exemplo as controladoras de várias soluções wireless existentes no mercado e que ficam responsáveis pelo gerenciamento centralizado dos APs.

O grande diferencial do SDN, na realidade, é a proposta da utilização de interfaces programáveis (APIs) entre os dispositivos e a(s) controladora(s), o que traz potencial para que TODO o modo de operação das redes seja repensado e reescrito! Um passo além, o esforço de padronização dessas interfaces traz um potencial ainda maior para esse paradigma. 

Há uma vertente de pesquisadores que entende que esse novo paradigma assusta as empresas fabricantes de dispositivos de redes porque equipamentos com hardware convencional podem ser utilizados como controladora e por isso essas empresas perderiam mercado para novos entrantes. São muitos os que defendem essa idéia...

Eu tenho minhas dúvidas e diria até que não concordo com isso, pelo menos não dessa maneira radical. Penso assim porque é necessário reconhecer que uma das características mais relevantes na disputa entre as empresas fabricantes de dispositivos de rede está justamente na qualidade e desempenho do hardware desenvolvido - e isso não deve mudar, principalmente quando pensamos em ambientes onde há grande fluxo de dados.

Entendam que essa visão não é contrária ao paradigma SDN, afinal existe um grande potencial em "casar" o desenvolvimento de hardware de qualidade aliado com interfaces programáveis, principalmente no que diz respeito à possibilidade de as empresas criarem controladoras próprias e APIs que ofereçam flexibilidade para ambientes específicos, a exemplo de Data-Centers,  algo que a Cisco (e outros fabricantes) já oferece. Quem tiver mais interesse na solução SDN da Cisco, saiba que ela é denominada ONE (Open Network Environment). Vejam detalhes no link abaixo:

http://www.cisco.com/web/solutions/trends/open_network_environment/index.html

Essa é mais um daqueles tópicos recentes de pesquisa na área de redes em que é muito difícil assegurar os rumos do seu futuro comercial...

Abraço.

Samuel.

Espelhamento de Portas em Switches Remotos (RSPAN)

Olá Pessoal.

No artigo anterior intitulado "Configuração de Espelhamento de Portas em Switch" foi explicado o conceito por trás do recurso SPAN (Switched Port Analyzer) com os passos necessários para configurá-lo,  já que esse é um recurso útil no monitoramento do tráfego da rede através do espelhamento de portas na linha Catalyst de Switches da Cisco.

Alguns leitores do blog interessados no assunto me pediram para escrever um artigo sobre o recurso RSPAN (Remote Switched Port Analyzer) que permite ampliar esse monitoramento em redes maiores através da criação de sessões de monitoramento com o destino do tráfego espelhado em algum outro switch remoto.

Para exemplificar como seria o processo de configuração do RSPAN estaremos considerando o cenário abaixo em que agora existem dois switches interligados através de um entroncamento (trunk), diferente do cenário do artigo anterior que havia um único switch. Vamos supor que a máquina na interface f0/2 quer se comunicar com a outra máquina e para tal enviou um quadro destinado a f0/1. Reparem que o quadro por ela originado é espelhado através da rede até chegar na interface f0/7 do switch remoto onde está "pendurado" o monitorador!

No SPAN tradicional (um único switch) você informava uma fonte (interfaces ou VLAN) e uma porta de destino onde os quadros espelhados eram entregues. No RSPAN o processo é um pouco diferente, já que envolve mais de um switch. Da mesma forma continua sendo necessário informar a(s) fonte(s) que podem ser interfaces (seja de acesso, trunk ou mesmo uma agregação lógica port-channel) ou uma VLAN. A diferença é que agora o destino será uma VLAN RSPAN por onde os quadros espelhados irão trafegar através da rede até chegarem no switch remoto que irá direcioná-los para a porta de destino!

 

Portanto, considerando o cenário da figura anterior, agora temos dois switches para configurar, o SW1 com as interfaces f0/1 e f0/2 de origem em que ocorrerá o espelhamento dos quadros e o SW2 com a interface f0/7 de destino onde o tráfego será entregue. Naturalmente que é necessário que entre os dois switches exista um canal de comunicação através da VLAN do RSPAN - a VLAN 33 nesse exemplo. Vamos às configurações:

01. SW1(config)# vlan 33

02. SW1(config-vlan)# name VLAN-RSPAN

03. SW1(config-vlan)# remote span

04. SW1(config-vlan)# exit

05. SW1(config)# interface g0/1

06. SW1(config-if)# switchport mode trunk 

07. SW1(config-if)# exit  

09. SW1(config)# monitor session 1 interface f0/1

10. SW1(config)# monitor session 1 interface f0/2

11. SW1(config)# monitor session 1 destination remote vlan 33     

Primeiro foi criada a VLAN 33 que já recebeu a instrução de que será utilizada para fins de transporte dos quadros espelhados pelo RSPAN. Na sequência configuramos a interface g0/1 em modo de entroncamento (trunk), ou seja, ela será capaz de transportar tráfego de todas as VLANs que existirem entre os switches, inclusive a VLAN RSPAN (33). Por fim foram informadas as interfaces de origem e reparem que agora o destino do espelhamento será a VLAN remota previamente criada.

01. SW2(config)# vlan 33
02. SW2(config-vlan)# name VLAN-RSPAN
03. SW2(config-vlan)# remote span
04. SW2(config-vlan)# exit
05. SW2(config)# interface g0/1
06. SW2(config-if)# switchport mode trunk
07. SW2(config-if)# exit
08. SW2(config)# monitor session 1 source remote vlan 33
09. SW2(config)# monitor session 1 destination interface f0/7 

As primeiras linhas (de 1 a 7) são idênticas e fazem exatamente a mesma coisa. A diferença é que no SW2 informamos a VLAN RSPAN (33) como origem e já configuramos qual será a interface de destino do tráfego espelhado. É só isso...
 

Abraço.

Samuel.

Configuração de Espelhamento de Portas em Switch

Olá Pessoal.

Um recurso muito útil para fins de monitoramento na linha Catalyst de Switches da Cisco® é denominado SPAN, acrônimo de Switched Port Analyzer. Esse recurso também é chamado de port-mirroring (espelhamento de porta) ou port-monitoring (monitoramento de porta).

Logo nas primeiras aulas de redes de computadores os alunos estudam conceitualmente os principais dispositivos de interconexão onde são apresentadas as principais diferenças entre dois dispositivos concentradores: (i) HUB e (ii) Switch.

Nessa ocasião os alunos aprendem que mesmo ambos os dispositivos sendo elementos centrais (concentradores) que criam uma topologia física de estrela, o modo de operação entre eles é distinto implicando em diferentes topologias lógicas, conforme pode ser observado na figura abaixo.

O HUB cria uma topologia lógica de barramento porque eletronicamente todas as suas portas estão ligadas em um mesmo barramento físico, o que implica na existência de um único dominío de colisão compartilhado entre todas as portas. Ele é um simples dispositivo repetidor que (i) recebe sinal em uma porta de entrada, (ii) amplifica esse sinal e (iii) despacha esse sinal para todas as demais portas de saída. Como ele é um dispositivo de camada física, não possui inteligência para analisar os cabeçalhos dos quadros.

Uma vez que a topologia lógica do HUB é de barramento, o sinal recebido em uma porta é retransmitido para TODAS as demais portas, o que é ruim do ponto de vista de desempenho e segurança. Por causa disso é muito simples interceptar o tráfego/conteúdo dessa rede através de algum software sniffer, já que todo sinal entre quaisquer máquinas é propagado para todas as portas. O Wireshark é um exemplo de software gratuito de interceptação de pacotes (analisador de protocolos) e pode ser baixado no link http://www.wireshark.org/.

Por outro lado o Switch cria uma topologia lógica de estrela porque eletronicamente possui uma matriz (denominada matriz crossbar) que permite o chaveamento de circuitos ponto-a-ponto entre duas portas específicas, o que implica em um domínio de colisão para cada porta. Para estabelecer esses circuitos entre duas portas os switches são dispositivos da camada de enlace e possuem inteligência para analisar os cabeçalhos dos quadros, motivo pelo qual eles utilizam o endereço físíco das interfaces (MAC) no processo de encaminhamento.

É comum o uso de softwares de interceptação de quadros/pacotes em redes de computadores para fins de monitoramento e análise da "saúde" da rede. O problema de utilizar esses softwares nas redes que possuem switch (diga-se de passagem quase todas atualmente), é que ao conectar o computador monitorador em uma porta qualquer do switch ele não será capaz de "escutar" nenhum tráfego entre os circuitos fechados nas demais portas. Por exemplo, uma comunicação entre dois computadores ligados nas portas f0/1 e f0/02 de um switch não será transmitida na porta f0/3 (nem em qualquer outra).

É para resolver esse problema que existem as tecnologias de port-mirroring. Essa tecnologia de espelhamento consiste em configurar uma determinada porta do switch para espelhar todo o tráfego entre os circuitos das demais portas, daí no nome espelhamento. Ou seja, essa porta irá se tornar o "dedo-duro" da rede replicando todo o tráfego como se fosse um HUB. Naturalmente essa porta será aquela em que o computador monitorador estará executando o software de interceptação (sniffer).

Vamos considerar o cenário ilustrado na figura abaixo para exemplificar o processo de configuração do SPAN nos seguintes modelos de Switch Catalyst da Cisco: 2940, 2950, 2955, 2960, 2970, 3550, 3560, 3560-E, 3750 e 3750-E. Em outros modelos de switches os comandos para configuração do SPAN podem ser diferentes! 

Reparem que temos uma rede local em que existe um notebook conectado na interface f0/7 do switch e que estará executando um software de interceptação, como por exemplo o Wireshark. Ao fazê-lo a interface de rede do notebook é colocada em modo promíscuo, ou seja, ela passará a capturar todo tráfego escutado por ela, seja ele direcionado a ela ou não. Caberá ao switch a função de replicar (espelhar) todos os quadros das demais portas para a interface f0/7. 

No exemplo seguinte vamos configurar a interface f0/7 como a porta de destino do monitorador e optaremos pelo espelhamento do tráfego apenas das interfaces f0/1 e f0/2 (origem). Para esse cenário a configuração do switch seria a seguinte:

Switch# configure terminal
Switch(config)# monitor session 1 source interface f0/1
Switch(config)# monitor session 1 source interface f0/2
Switch(config)# monitor session 1 destination interface f0/7 
Switch(config)# exit
Switch# show monitor session

Ao invés de informar as interfaces de origem manualmente, também é possível monitorar toda uma VLAN previamente configurada no switch. Nesse caso seria informada apenas a VLAN como origem e todas as interfaces associadas à respectiva VLAN teriam  seu tráfego automaticamente espelhado para a porta de destino SPAN. À medida que portas são removidas ou associadas com a VLAN, então seu tráfego já será espelhado. Não é possível combinar o espelhamento de interfaces e VLANs! Vamos supor que as interfaces f0/1 e f0/2 do exemplo anterior estivessem associadas com a VLAN-13, a configuração seria:

Switch(config)# monitor session 1 source vlan 13

Switch(config)# monitor session 1 destination interface f0/7

Existe ainda a possibilidade de ampliar o monitoramento em redes maiores criando sessões de monitoramento com o destino do tráfego espelhado em algum outro switch remoto através do recurso RSPAN (Remote Switched Port Analyzer). Se vocês tiverem interesse nessa tecnologia, me avisem que escreverei outro artigo para exemplificar sua configuração.

Abraço.

Samuel.

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. 

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  

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.