O gráfico de taxa média de um switch pode parecer perfeitamente estável enquanto uma porta descarta silenciosamente pacotes por causa de uma rajada que durou um único milissegundo. Veja aqui como reconhecer o sintoma, capturar e ler a rajada real, percorrer um caso real em que o log de falha apontava para a causa errada, e as medidas de mitigação que realmente funcionam depois que você confirma do que se trata.
By Yuwen Zhang (Atlas), founder of AtlasCommTech — 13 years of carrier & enterprise network deployments · Updated July 2026
Já vi um gráfico de utilização média de cinco minutos ficar abaixo de 30% enquanto essa mesma porta descartava pacotes silenciosamente — a ferramenta simplesmente não estava olhando para a escala de tempo correta.
Plataformas de gerenciamento de rede e ferramentas de monitoramento de desempenho normalmente calculam a utilização em vários segundos a alguns minutos. Nessa resolução, a curva de tráfego de uma porta parece suave e sem nada de anormal. Mas um segundo é um período enorme para uma interface que movimenta pacotes em taxa de linha multigigabit — ao aproximar para granularidade de milissegundos, o mesmo tráfego costuma se revelar serrilhado, com picos que atingem muitas vezes sua própria média. Quando o pico é severo o suficiente para estourar o buffer do switch, isso é uma microrrajada, e ela produz descartes que nunca aparecem como um problema de utilização sustentada.
A seguir está como uma microrrajada realmente se parece, a ordem de verificação a seguir sem adivinhar, um caso real de campo em que os logs de classificação de falhas apontavam diretamente para a causa errada, e as medidas de mitigação que realmente funcionam depois de confirmado o problema.
As microrrajadas duram de 1 a 100 milissegundos e podem atingir picos de dezenas ou centenas de vezes a taxa média — às vezes acima da própria largura de banda da porta.
Uma microrrajada é uma explosão de tráfego muito curta e muito densa em uma porta — normalmente de 1 a 100 ms — que atinge uma taxa instantânea muito acima da média medida, e no pior caso, acima da própria largura de banda física da porta. Não é uma falha do monitoramento perdê-la em resolução de 5 minutos; é um descompasso de resolução. O tráfego sob uma curva macro de aparência plana costuma ser uma curva micro serrilhada, e quando os dentes ficam grandes o suficiente, isso é a rajada.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Três condições se combinam para criar a maioria das microrrajadas: comportamento de aplicação em rajadas (padrões de solicitação/resposta, tráfego sensível à latência tentando enviar o mais rápido possível), mais largura de banda de entrada do que de saída no mesmo caminho de encaminhamento (um cano grande alimentando um pequeno, ou várias portas de mesma velocidade convergindo em uma só), e o clássico padrão serrilhado do TCP sob prevenção de congestionamento (partida lenta e depois redução pela metade). Nenhuma das três exige qualquer configuração incorreta — são comportamentos normais de tráfego colidindo com um buffer pequeno demais para aquele instante.
Os contadores de descarte e os alarmes de QoS indicam que provavelmente ocorreu uma microrrajada; a captura espelhada e os recursos de detecção do próprio switch indicam o tamanho e a frequência.
Qualquer um dos sintomas abaixo significa “provavelmente ocorreu uma microrrajada aqui”, não uma confirmação — as verificações a seguir são as que realmente confirmam isso.
<HUAWEI>display interface 10GE1/0/1
10GE1/0/1 current state : UP (ifindex: 8)
Line protocol current state : UP
Last 300 seconds input rate: 225 bits/sec, 0 packets/sec
Last 300 seconds output rate: 2075 bits/sec, 1 packets/sec
Input peak rate 2387819 bits/sec, Record time: 2025-11-26 16:11:22+08:00
Output peak rate 1277476 bits/sec, Record time: 2025-11-26 15:51:14+08:00
Input:
Discard: 0, Frames: --
Output:
Discard: 89, Buffers Purged: 0
// average rate looks trivial -- but 89 egress discards already happenedDescartes no lado de saída, não no de entrada, são a assinatura característica de uma microrrajada, e não de um problema de CRC ou de camada física.
<HUAWEI>display qos queue statistics interface 10GE1/0/1
Queue CIR/PIR Passed Pass Rate Dropped Drop Rate Drop Time
(% or kbps) (Packets/Bytes) (pps/bps) (Packets/Bytes) (pps/bps)
----------------------------------------------------------------------------------------------
6 0 21 0 0 0 -
10000000 6930 88 0 0
----------------------------------------------------------------------------------------------
7 0 255 0 0 0 -
10000000 31365 492 0 0Um gráfico de E/S de 1 milissegundo é a granularidade que uma microrrajada realmente precisa para se tornar visível — o intervalo padrão de vários segundos só mostra a mesma curva plana que a plataforma de monitoramento já deu.
Dois recursos integrados fazem isso sem qualquer captura espelhada — nenhum está disponível em todos os modelos de switch, então verifique o suporte do seu hardware antes de presumir que ele existe.
[HUAWEI] interface 100GE 1/0/1
[HUAWEI-100GE1/0/1] qos buffer-monitoring percent low 60 high 90
<HUAWEI> display qos buffer-monitoring result interface 100GE 1/0/1
Queue Time BufferUsage(Bytes) Percent(%)
----------------------------------------------------------------
0 2015-11-11 14:36:15.208 1602016 100
// a saved record here confirms a microburst occurred, and precisely when
[HUAWEI] qos micro-burst detection enhanced enable
[HUAWEI] interface 100GE 1/0/1
[HUAWEI-100GE1/0/1] qos micro-burst detection enableUm cliente de rede de campus com uma pilha S12700E-8 relatou tempos limite intermitentes dos clientes através do switch central — pings longos nunca perdiam pacotes, pings com pacotes grandes também não, apenas o tráfego real de aplicações era afetado. Os logs mostravam um alarme de razão de variação da taxa de saída em uma porta GigabitEthernet, junto com um log “Packets are discarded for congestion” que, nesta versão de software, lia-se exatamente como congestionamento entre placas. Remover uma grande pilha de configuração de espelhamento de porta aliviou o sintoma, mas não o resolveu. display qos micro-burst statistics na interface com perdas mostrou tráfego muito longe do teto real de encaminhamento da plataforma — então não deveria ter sido congestionamento entre placas de forma alguma. Espelhar essa mesma interface mostrou uma captura serrilhada com uma janela de um milissegundo atingindo aproximadamente 8-9 megabits — cerca de 8Gb/s — em uma porta de velocidade Gigabit; uma captura de pacotes adicional na mesma interface flagrou um host específico enviando vários pacotes superdimensionados dentro desse mesmo milissegundo. A lição: nesta plataforma e versão, o congestionamento comum em nível de porta é registrado com a mesma redação do congestionamento entre placas, o que desvia o diagnóstico para “o plano de encaminhamento não consegue encaminhar tanto” quando a causa real é uma única porta recebendo um impacto instantâneo muito acima de sua própria largura de banda. Julgue combinando sinais — utilização de largura de banda da interface, qos micro-burst statistics e captura espelhada — nunca apenas pela redação do log.
Depois de confirmado que uma rajada realmente está ocorrendo, estas são as interpretações erradas que levam a procurar no lugar errado.
SYMPTOMOs descartes estão subindo, mas o dispositivo nunca gerou nenhum alarme sobre o uso do buffer — então se assume que os buffers estão bem e que a contagem de descarte deve estar medindo outra coisa.
CAUSELer a ocupação do buffer exige sondagem de CPU, a mesma restrição que limita a frequência de amostragem da própria utilização. Sondar de forma agressiva o suficiente para captar um evento em escala de milissegundos elevaria o uso de CPU o bastante para desacelerar todo o dispositivo, então o switch deliberadamente não tenta alarmar sobre o estado do buffer nessa resolução.
FIXTrate os contadores de descarte, a captura espelhada e o recurso dedicado de detecção de microrrajada como os substitutos previstos para um alarme de buffer que nunca virá — não espere por ele.
SYMPTOMO gráfico de utilização da porta nunca ultrapassa 20-30%, então a teoria de perda de pacotes relacionada a rajadas é descartada de imediato.
CAUSEA utilização média e a taxa instantânea de rajada não são a mesma medida, assim como velocidade e aceleração não são a mesma coisa. Uma placa de rede transmite na sua taxa física total ou não transmite nada — nunca em taxa fracionária — então uma porta com média de 20-30% ainda pode estar operando a 100% da taxa de linha por alguns milissegundos, e depois ficar ociosa.
FIXNunca descarte uma microrrajada com base apenas na utilização média — recorra diretamente a uma captura espelhada em escala de milissegundos ou ao recurso de detecção integrado.
SYMPTOMO switch é o dispositivo que registra os descartes, então ele passa a ser tratado como o que está com defeito.
CAUSEAlém de uma pequena quantidade de tráfego de protocolo, os switches não geram o tráfego que estoura seus próprios buffers — os hosts finais é que geram. O que o switch pode fazer é amplificar uma rajada: várias portas de mesma velocidade enviando para uma só, ou uma relação de convergência desfavorável, empilham os picos de várias rajadas exatamente no momento em que colidem na porta de saída compartilhada.
FIXRastreie a origem do tráfego e a relação de convergência no design da rede, não apenas a interface que por acaso registrou o descarte.
SYMPTOMA aplicação é descrita como tendo tráfego imprevisível e de baixa intensidade, então uma rajada séria parece improvável.
CAUSEA placa de rede de um servidor transmite na sua taxa física de enlace total sempre que tem algo enfileirado, depois fica ociosa esperando pela camada de aplicação. Em média ao longo do tempo isso pode parecer 20-30% de utilização, mas em nível de microssegundos é na verdade 100% ou 0%, nunca intermediário — que é exatamente do que uma microrrajada é feita.
FIXNão use “a aplicação não está tão ocupada” como motivo para pular uma captura em escala de milissegundos — é exatamente o padrão de tráfego mais propenso a produzir uma.
SYMPTOMUma captura espelhada em uma interface carregada acima de 10Gbps mostra perdas ou parece inconsistente de execução para execução, mesmo que a configuração da captura pareça correta.
CAUSEUma captura baseada em PC só é confiável até aproximadamente 1Gbps de taxa de interface, e uma baseada em servidor até aproximadamente 10Gbps; além disso, a própria ferramenta de captura se torna o gargalo e começa a perder ou representar mal os pacotes — exatamente o que você está tentando observar.
FIXAcima de aproximadamente 10Gbps, ou para qualquer janela de monitoramento sustentado, use um dispositivo dedicado de terceiros para captura e análise em vez de um PC ou servidor de uso geral rodando Wireshark.
Na ordem aproximada em que vale a pena tentá-las — primeiro o mais barato e com menor efeito colateral.
[HUAWEI-GigabitEthernet0/0/1] qos burst-mode enhanced
[HUAWEI] traffic classifier c_latency
[HUAWEI-classifier-c_latency] if-match dscp af41
[HUAWEI] traffic behavior b_latency
[HUAWEI-behavior-b_latency] remark local-precedence 6
[HUAWEI] traffic policy p_edge
[HUAWEI-trafficpolicy-p_edge] classifier c_latency behavior b_latency
[HUAWEI-GigabitEthernet0/0/2] traffic-policy p_edge inbound
[HUAWEI-GigabitEthernet0/0/1] qos queue 3 shaping cir 500 mbps pir 800 mbps
// shaping adds latency -- reach for it after the other options, not beforeTiradas diretamente do campo — as que vale a pena ter uma resposta pronta.
Não. O congestionamento comum e sustentado também aparece no gráfico de taxa média — que é exatamente o que o monitoramento de rotina, incluindo as verificações da nossa nota de verificação de saúde do switch de datacenter, foi feito para detectar. Uma microrrajada é especificamente uma rajada tão curta — de 1 a 100 milissegundos — que é invisível na resolução normal de monitoramento, embora ainda estoure o buffer da porta naquele instante.
Porque ler a ocupação do buffer exige sondagem de CPU, e sondar de forma agressiva o suficiente para captar um evento em escala de milissegundos elevaria a utilização de CPU o bastante para desacelerar todo o dispositivo. É exatamente por isso que os contadores de descarte, a captura espelhada e o recurso dedicado de detecção de microrrajada existem como substitutos para um alarme que não vai chegar.
Se você só precisa confirmar que uma rajada ocorreu e aproximadamente quando, o buffer-monitoring do monitoramento de congestionamento é mais leve e suportado em mais modelos. Se você precisa da taxa e duração reais para planejamento de capacidade, o modo aprimorado da detecção de microrrajada fornece números reais por interface em resolução de 1ms — ao custo de rodar apenas em uma interface por vez.
Sim, e essa é de longe a interpretação errada mais comum dos dados. A utilização média e a taxa instantânea de rajada não são a mesma medida, assim como velocidade e aceleração não são a mesma coisa. Uma porta com média de 20-30% ainda pode estar operando a 100% da taxa de linha por alguns milissegundos, porque é literalmente assim que uma placa de rede transmite — na taxa física total ou nada.
Na ordem aproximada em que ajudam sem efeitos colaterais: adicione largura de banda de saída no link de gargalo; evite padrões de tráfego de muitos para um no design; habilite qos burst-mode enhanced para que portas carregadas possam tomar mais do buffer dinâmico compartilhado; separe o tráfego sensível à latência em uma fila de prioridade mais alta para que não seja o tráfego descartado; e recorra ao shaping de saída apenas por último, já que ele corrige o descarte adicionando latência de encaminhamento, o que é uma contrapartida própria.
Esta nota se baseia no modelo de buffer/QoS dos switches de campus e chassi Huawei série S — display interface, display qos queue statistics, qos buffer-monitoring, qos micro-burst detection — e no caso de campo por trás dela. Se sua plataforma for de outro fabricante, os comandos exatos mudam, mas o conceito subjacente se aplica diretamente: o monitoramento de taxa média não capta rajadas de milissegundos por design, e confirmar uma exige captura espelhada ou um recurso de detecção dedicado. Não cobre em profundidade a absorção de rajadas em fabrics sem perdas leaf-spine de datacenter (PFC, ECN) — esse é o assunto da solução de armazenamento sem perdas vinculada.
Conte-nos qual interface, a contagem de descarte, e se você já tentou uma captura espelhada, e ajudamos você a interpretá-la.