Guia explicativo · Resiliência de rede
O que é teste de estresse de rede: explicação para provedores
O que é teste de estresse de rede: é colocar um equipamento ou um trecho da rede sob carga acima do uso normal, de forma controlada, para descobrir em que ponto ele começa a falhar. No provedor, o teste responde perguntas como quantas sessões o concentrador aceita por segundo, quantos pacotes a borda processa e o que acontece quando um link cai e o outro recebe tudo.
Resumo
- O teste de estresse procura o ponto de quebra de um equipamento, e não apenas confirma que ele aguenta o dia a dia.
- A carga sobe em degraus, enquanto se observam perda de pacotes, latência, CPU, memória e sessões.
- No provedor, os limites que mais derrubam a rede são de pacotes por segundo e de sessões novas, e não de banda.
- [object Object]
O que é teste de estresse de rede e o que ele mede
O teste de estresse de rede é um ensaio em que a carga passa de propósito do que a rede vê no horário de pico, até algo ceder. O resultado é um número: o limite real de cada peça, medido e não estimado pela ficha do fabricante.
A ficha técnica de um roteador ou de um concentrador informa números de laboratório, quase sempre com pacotes de tamanho favorável e uma única função ligada. Na sua rede, o mesmo equipamento faz NAT, filtros, roteamento e exportação de fluxos ao mesmo tempo, e o limite real costuma ficar abaixo do anunciado.
O teste de estresse mede essa diferença. Ele aplica carga crescente, observa o comportamento e registra o degrau em que a perda de pacotes aparece, a latência dispara ou a CPU trava o plano de controle.
Antes de gerar qualquer tráfego, vale saber onde procurar. A avaliação de resiliência anti-DDoS da Táquion Tech não envia carga contra a rede: ela lê configuração, fluxos, contratos e folga dos links, e aponta quais equipamentos estão mais perto do limite.
Teste de carga, de estresse, de resistência e de pico
Os nomes se confundem, mas cada teste responde uma pergunta diferente. A tabela separa os quatro com exemplos de provedor.
| Tipo | Pergunta que responde | Exemplo no provedor |
|---|---|---|
| Teste de carga | A rede aguenta o pico esperado com folga? | Simular o tráfego de uma noite de domingo com a base atual mais o crescimento do ano |
| Teste de estresse | Em que ponto ela quebra e como quebra? | Subir sessões PPPoE por segundo até o concentrador recusar ou travar |
| Teste de resistência | Ela se mantém estável sob carga alta por horas? | Deixar o CGNAT perto do limite de sessões durante uma noite e acompanhar a memória |
| Teste de pico | Ela suporta um salto repentino de carga? | Mudar todo o tráfego de um link para outro de uma vez, como numa falha |
As métricas que o teste observa
Banda é só uma das medidas, e nem sempre a primeira a ceder. Num provedor, estas são as que mostram o ponto de quebra.
- Pacotes por segundo: quantos pacotes o equipamento encaminha, o que importa mais que a banda quando os pacotes são pequenos.
- Sessões novas por segundo: quantas conexões PPPoE, NAT ou BGP ele consegue abrir num intervalo curto.
- Perda e latência: o momento em que pacotes começam a sumir e o atraso deixa de ser estável.
- CPU e memória: quanto sobra para o plano de controle, que mantém as sessões de roteamento e a gerência.
- Tempo de recuperação: quanto o equipamento leva para voltar ao normal depois que a carga cai.
Como é feito um teste de estresse na prática
O teste segue um roteiro: pergunta clara, cenário montado, carga em degraus, observação e parada no primeiro sinal de falha. O diagrama mostra a sequência.
1 · Pergunta
Definir o limite a descobrir
Por exemplo, quantas sessões por segundo o concentrador aceita antes de o RADIUS começar a recusar.
2 · Cenário
Montar o laboratório ou a janela
Equipamento igual ao de produção em bancada, ou janela de baixo uso com plano de volta e equipe atenta.
3 · Degraus
Subir a carga aos poucos
Cada degrau dura o suficiente para estabilizar, com perda, latência, CPU e sessões anotadas.
4 · Quebra
Registrar onde e como cedeu
O primeiro degrau com perda ou instabilidade vira o limite medido, com o modo de falha descrito.
5 · Margem
Comparar com o pico real
A distância entre o limite e o pico da rede mostra quanto falta para o problema aparecer sozinho.
O teste para no primeiro sinal de falha. Levar o equipamento ao travamento total em produção não acrescenta informação e coloca assinantes em risco.
Em laboratório, o gerador de tráfego pode ser um equipamento dedicado de teste ou um servidor com software de geração de pacotes. Em produção, a carga costuma ser parcial, somada ao tráfego real, e o critério de parada precisa estar combinado antes.
Exemplo de geração de carga em laboratório
Uma bancada simples usa dois servidores, um de cada lado do equipamento testado. Os comandos abaixo mostram a diferença entre medir banda com pacotes grandes e medir pacotes pequenos.
# Servidor do outro lado do equipamento testado
iperf3 -s -B 192.0.2.10
# Banda com pacotes grandes: 8 fluxos TCP por 5 minutos
iperf3 -c 192.0.2.10 -P 8 -t 300
# Pacotes pequenos: UDP de 64 bytes, subindo a taxa a cada degrau
iperf3 -c 192.0.2.10 -u -l 64 -b 200M -t 120
iperf3 -c 192.0.2.10 -u -l 64 -b 400M -t 120
iperf3 -c 192.0.2.10 -u -l 64 -b 800M -t 120
# No equipamento testado, acompanhe CPU, perda e contadores a cada degrau
É comum o equipamento passar folgado no primeiro teste e começar a perder pacotes no degrau de 64 bytes muito antes de chegar à banda nominal. Para volumes maiores que um servidor gera, entram ferramentas próprias de geração de pacotes ou equipamentos de teste dedicados.
Em que momento o teste de estresse de rede é necessário?
O teste vira necessário quando a rede passa a depender de um equipamento que nunca foi levado ao limite. O problema aparece em dias raros, quando a carga muda de uma vez e não aos poucos.
No dia a dia, a carga cresce devagar e os gráficos avisam com antecedência. Os eventos abaixo concentram em minutos o que normalmente se espalha em horas, e é neles que o limite desconhecido aparece.
- Volta da energia num bairro: centenas de ONUs religam juntas e pedem sessão ao concentrador e ao RADIUS no mesmo minuto.
- Queda de um link ou de um POP: todo o tráfego migra para o caminho que sobrou, que pode nunca ter recebido essa carga.
- Pico de audiência: final de campeonato ou lançamento de jogo junta streaming e downloads na mesma hora.
- Ataque DDoS: pacotes pequenos em quantidade enorme testam a borda sem pedir licença.
No caso da energia, a reconexão em massa pode deixar o concentrador no limite por vários minutos, como mostra o guia sobre concentrador PPPoE com CPU em 100%. Um teste prévio de sessões por segundo diz se o equipamento aguenta ou se precisa de limite de aceitação.
Não sabe qual equipamento está mais perto do limite?
Na avaliação de resiliência anti-DDoS, um Especialista lê a borda, os links e o histórico de tráfego e mostra onde um pico ou um ataque vão encontrar o ponto fraco.
Sinais de que a rede está perto de um limite desconhecido
Marque o que vale para a sua rede hoje
- O concentrador nunca foi testado com reconexão de toda a base ao mesmo tempo.
- O link reserva é menor que o principal e nunca carregou o tráfego inteiro.
- A CPU da borda passa de metade da capacidade no horário de pico.
- O CGNAT chega perto do limite de sessões nas noites de maior uso.
- O equipamento foi escolhido pela banda nominal, sem conferir pacotes por segundo.
- Uma queda de energia já deixou assinantes sem conexão por muito mais tempo que a própria falta de luz.
Duas marcas ou mais indicam um limite que ninguém mediu e que vai aparecer no próximo evento raro. Medir antes, em laboratório ou em janela, custa menos que descobrir com a base inteira fora.
Na prática: o link reserva que nunca tinha carregado tudo
Um caso comum mostra o teste de pico evitando uma queda futura. O provedor tinha dois trânsitos, mas o segundo nunca tinha recebido o tráfego inteiro.
- Pergunta: se o link principal cair no pico, o link reserva e a porta da borda ligada a ele aguentam?
- Cenário: janela de madrugada, com o tráfego real menor, e plano de volta escrito antes de mexer.
- Degraus: a preferência de rota foi mudando aos poucos, passando partes do tráfego para o reserva.
- Quebra: antes de chegar ao total, a porta da borda ligada ao reserva começou a descartar pacotes por fila cheia.
- Margem: o limite estava abaixo do pico de domingo, e a correção foi trocar a porta e renegociar o link reserva.
Sem o teste, a falha apareceria no primeiro rompimento do link principal num domingo à noite, com a equipe procurando o problema no lugar errado. O mesmo raciocínio vale para o CGNAT redundante, como mostra o guia sobre como deixar o CGNAT redundante.
Erros comuns em teste de estresse de rede
Os erros mais comuns medem a coisa errada ou expõem assinantes sem necessidade. Todos produzem um número que não corresponde ao comportamento real da rede.
Evite no teste de estresse
- Testar só com pacotes grandes: a banda passa e o limite de pacotes por segundo fica escondido.
- Usar um único fluxo TCP: um fluxo sozinho mede o servidor de teste, e não o equipamento no meio.
- Testar com funções desligadas: sem NAT, filtros e exportação de fluxos, o equipamento parece mais forte do que é.
- Ir até o travamento em produção: o limite já apareceu no primeiro degrau com perda.
- Esquecer o plano de controle: sessões BGP e gerência caem antes do encaminhamento, e o teste precisa olhar as duas coisas.
Para a parte de ataque, o teste de estresse se encontra com o teste da proteção DDoS. O guia sobre como testar proteção DDoS mostra o que pode ser conferido com tráfego mínimo, sem simular um ataque inteiro.
Quando vale fazer o teste e quando a avaliação basta?
A avaliação sem tráfego basta para achar os pontos fracos óbvios e decidir onde investir. O teste de estresse vale quando falta um número exato para uma decisão cara, como comprar um equipamento ou aceitar um contrato.
- Avaliação primeiro: quando ninguém sabe a folga dos links, a CPU da borda no pico ou o que as operadoras oferecem.
- Teste em laboratório: antes de colocar um concentrador ou um roteador novo em produção, com a configuração real.
- Teste em janela: para conferir failover de links e de CGNAT, com plano de volta e equipe atenta.
- Teste com fornecedor especializado: quando a pergunta envolve volumes de ataque que nenhum servidor da casa gera.
Um teste de estresse sem uma pergunta definida vira só um número bonito no relatório. Comece pela leitura da rede, escolha o limite que mais preocupa e teste esse primeiro.
Perguntas frequentes
Teste de estresse de rede derruba os assinantes?
Não deveria, quando feito em laboratório ou em janela de baixo uso com parada no primeiro sinal de falha. O risco aparece quando o teste é feito em produção sem plano de volta ou levado até o travamento.
Qual a diferença entre teste de estresse e teste de velocidade?
O teste de velocidade mede a banda que chega a um assinante num momento. O teste de estresse sobrecarrega um equipamento ou um trecho da rede para descobrir o limite e o modo de falha.
Existe norma para teste de estresse em rede?
Existem metodologias de referência, como a RFC 2544 para medir vazão, perda e latência de equipamentos e a ITU-T Y.1564 para ativação de serviços Ethernet [CONFIRMAR na norma]. Elas padronizam a medição, mas não dizem qual limite a sua rede precisa ter.
Dá para fazer teste de estresse com iperf?
Dá para testes menores, desde que se usem vários fluxos e pacotes pequenos além dos grandes. Para volumes acima do que um servidor gera, são necessárias ferramentas de geração de pacotes ou equipamentos de teste dedicados.
Quem pode autorizar um teste de estresse na rede?
Quem responde pela rede, por escrito, com escopo, horário e critério de parada definidos. Se o tráfego atravessa operadoras ou outras redes, elas também precisam ser avisadas antes.
Responsável técnico da Táquion Tech · Registro profissional [PREENCHER]
Mais de 15 anos em operações de rede, com gestão de infraestruturas de TI, administração de data centers e condução de equipes em migrações de TI e telecomunicações, com foco em alta disponibilidade e segurança.
A Táquion Tech é uma empresa de engenharia de redes de Balneário Camboriú (SC) que projeta, opera e dá suporte a redes de provedores de internet e de empresas.
Fontes
- RFC 2544: Benchmarking Methodology for Network Interconnect Devices: metodologia de medição de vazão, latência, perda de quadros e rajadas em equipamentos de rede, com vários tamanhos de pacote
- RFC 6349: Framework for TCP Throughput Testing: orienta a medição de vazão TCP com vários fluxos, base para não medir o servidor de teste no lugar da rede
- ITU-T Y.1564: Ethernet service activation test methodology: metodologia da UIT para testar serviços Ethernet em degraus de carga antes da ativação
