'Internet lenta' atrás de um roteador NAT é na verdade pelo menos três problemas diferentes com a mesma queixa: um link de saída que está bem sozinho mas fica lento assim que vários links carregam tráfego juntos, uma LAN inteira com navegação arrastada por causa do que a CPU está descartando silenciosamente, ou uma direção de um teste de velocidade que fica aquém de um número que o mesmo cabo já provou conseguir atingir. Esta é a ordem que os distingue, os comandos display e de configuração para cada um, e as causas que aparecem repetidamente.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
O NAT é o que está rodando quando o sintoma aparece, o que não é o mesmo que o NAT ser a causa.
Um roteador NAT fica exatamente no ponto onde cada um desses sintomas é relatado, então é a primeira coisa culpada — e raramente é a falha real. A verdadeira pergunta é qual das três formas a lentidão assume: só aparece quando mais de um link WAN carrega tráfego ao mesmo tempo; está presente o tempo todo, para todos, em todos os links; ou só aparece em uma direção de um teste de velocidade que uma conexão direta provou conseguir atingir a taxa plena. Cada forma aponta para uma parte completamente diferente do equipamento — encaminhamento de link/placa, policiamento de pacotes em nível de CPU, ou correspondência de taxa de interface — e nenhuma delas se resolve encarando a configuração de NAT em si.
A seguir está essa divisão em três, as verificações e comandos exatos para cada uma, cinco causas raiz que respondem pela maioria desses chamados em campo, e respostas de perguntas frequentes tiradas de casos reais.
Classifique a reclamação nesta árvore antes de mexer em uma única regra de NAT.
Se a lentidão é constante ou condicional, e qual direção ela afeta, indica qual das verificações abaixo realmente se aplica.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Um link que só é lento sob carga combinada, um escritório inteiro lento o tempo todo, e uma direção de um teste de velocidade que fica aquém são três falhas diferentes com três correções diferentes. Classifique primeiro o chamado aqui, depois trabalhe a etapa correspondente abaixo.
Três etapas, três gargalos diferentes — encaminhamento de link e placa, policiamento de pacotes em nível de CPU, e incompatibilidade de taxa de interface.
Qualquer link testado sozinho está bem; só a carga combinada é lenta. Percorra isso em ordem em vez de mudar várias coisas de uma vez.
#
interface Vlanif100
ip address 10.1.1.1 255.255.255.0
dhcp select interface
dhcp server dns-list 10.1.1.1
#
interface Vlanif10
ip address 10.2.1.1 255.255.255.252
nat outbound 2000
#
interface GigabitEthernet1/0/0
ip address 10.3.1.1 255.255.255.252
nat outbound 2000
#
interface GigabitEthernet1/0/1
ip address 10.4.1.1 255.255.255.252
nat outbound 2000
#
interface GigabitEthernet1/0/2
ip address 10.5.1.1 255.255.255.252
nat outbound 2000
#
ip route-static 0.0.0.0 0.0.0.0 10.2.1.2
ip route-static 0.0.0.0 0.0.0.0 10.3.1.2
ip route-static 0.0.0.0 0.0.0.0 10.4.1.2
ip route-static 0.0.0.0 0.0.0.0 10.5.1.2
// four fixed-IP egress links, all NAT-translated, all in active use at once
[Huawei] ip load-balance hash src-ip
// load-balance by source IP across the four egress links
[Huawei-GigabitEthernet1/0/0] tcp adjust-mss 1200
// tested for fragmentation -- improved things only slightly here
[Huawei] undo stp enable
// improved speed but still short of the required bandwidth on its own
[Huawei] system-view
[Huawei] set workmode lan-card l3centralize
// disables centralized routing-forwarding on the 8FE1GE/24GE high-end LAN card
// -- this is what actually resolved the slowdown in this casePáginas web carregando devagar para todos a jusante de uma interface NAT, sem um problema óbvio de link ou largura de banda, é antes de tudo um sintoma de policiamento por CPU.
<Huawei> display logbuffer
2016-2-6 05:06:16+00:00 Huawei %%01DEFD/4/CPCAR_DROP_MPU(l)[1751]:Some packets are dropped by
cpcar on the MPU. (Packet-type=dns-reply, Drop-Count=13741)
2016-2-6 05:16:16+00:00 Huawei %%01DEFD/4/CPCAR_DROP_MPU(l)[1752]:Some packets are dropped by
cpcar on the MPU. (Packet-type=dns-reply, Drop-Count=10879)
2016-2-6 05:26:16+00:00 Huawei %%01DEFD/4/CPCAR_DROP_MPU(l)[1753]:Some packets are dropped by
cpcar on the MPU. (Packet-type=dns-reply, Drop-Count=32302)
// tens of thousands of legitimate DNS replies being dropped by CPU policing every ten minutes
<Huawei> display cpu-usage
// CPU usage was in the normal range -- not a general overload problem
<Huawei> display interface GigabitEthernet 0/0/1
// bandwidth utilization normal, Duplex: FULL -- not a physical-layer bottleneck
<Huawei> display nat session number
// NAT session resources were not at their limit
<Huawei> system-view
[Huawei] cpu-defend policy dns
[Huawei-cpu-defend-policy-dns] packet-type dns-reply rate-limit 512
[Huawei-cpu-defend-policy-dns] auto-defend enable
[Huawei-cpu-defend-policy-dns] quit
[Huawei] cpu-defend-policy dns
[Huawei] cpu-defend-policy dns global
// raises the dns-reply rate limit from the default 128 to 512 -- resolved the slow page loadsO teste de velocidade upstream é normal, o downstream não — e remover o roteador do caminho prova que o próprio downlink é capaz da taxa total de interface.
<Huawei> system-view
[Huawei] qos queue-profile limit
[Huawei-qos-queue-profile-limit] queue 0 to 4 length bytes 1000000
[Huawei] interface GigabitEthernet0/0/1
[Huawei-GigabitEthernet0/0/1] qos queue-profile limit
[Huawei-GigabitEthernet0/0/1] qos gts cir 1000000 cbs 125000
// shapes the 10GE-side traffic down to 1000M before it reaches the GE downlink
#
qos queue-profile limit
queue 0 to 7 length packets 512 // caps the max packets a queue can buffer
#
interface GigabitEthernet0/0/1
qos queue-profile limit
qos gts cir 1000000 cbs 125000 // shapes to 1000M for a slower downstream peer deviceDepois que a etapa acima indicar para onde olhar, essas cinco respondem pela maior parte do que realmente está errado.
SINTOMAQualquer link WAN testado sozinho dá velocidade normal de navegação e download. A lentidão só aparece quando vários links de saída de IP fixo carregam tráfego real ao mesmo tempo.
CAUSAAlgumas placas LAN de ponta (8FE1GE, 24GE) rodam em modo de encaminhamento de roteamento centralizado por padrão. Sob a carga combinada de vários links de saída ativos ao mesmo tempo, esse caminho centralizado se torna o gargalo — mesmo que a qualidade do link, o balanceamento de carga, o MSS e o STP estejam todos corretos individualmente.
SOLUÇÃODesabilite o encaminhamento de roteamento centralizado na placa LAN de ponta para que ela pare de ser o ponto de estrangulamento compartilhado do tráfego multi-saída.
[Huawei] set workmode lan-card l3centralizeSINTOMACada host atrás do roteador enfrenta carregamentos de página lentos, mas tanto a utilização de largura de banda quanto o uso de CPU parecem completamente normais.
CAUSAA política CPU-defend padrão aplicada a todas as placas limita os pacotes de resposta DNS a apenas 128 pacotes por segundo. O volume legítimo de respostas DNS de uma rede ocupada pode facilmente superar isso, e tudo acima do limite é silenciosamente descartado antes de os hosts verem a resposta — o que parece exatamente uma reclamação genérica de internet lenta.
SOLUÇÃOCrie uma política CPU-defend dedicada e eleve o limite de taxa de dns-reply bem acima do volume real de tráfego, depois aplique-a globalmente.
[Huawei] cpu-defend policy dns
[Huawei-cpu-defend-policy-dns] packet-type dns-reply rate-limit 512
[Huawei] cpu-defend-policy dns globalSINTOMAO teste de velocidade upstream está bem. O teste de velocidade downstream fica bem abaixo da taxa de interface, e remover o roteador do caminho prova que o downlink sozinho consegue atingir a velocidade gigabit total.
CAUSAO tráfego downstream fluindo de uma interface de alta velocidade (10GE) para uma de velocidade menor (GE) não tem para onde ir assim que ultrapassa o que o lado GE consegue realmente encaminhar — a incompatibilidade em si produz as perdas, independentemente de qualquer coisa upstream.
SOLUÇÃOIguale os tipos e taxas de interface quando possível; onde não puderem ser igualados, aplique modelagem de tráfego QoS para que o lado de alta velocidade nunca envie mais rápido do que o lado de baixa velocidade consegue absorver.
[Huawei-GigabitEthernet0/0/1] qos gts cir 1000000 cbs 125000SINTOMAUma lentidão multi-saída é culpada por vez pela qualidade do link, balanceamento de carga, fragmentação ou STP — cada teste mostra uma melhora parcial ou nenhuma, e a correção real ainda está mais adiante na lista.
CAUSAVárias causas plausíveis podem contribuir um pouco cada, sem ser o gargalo real. Desabilitar o STP, por exemplo, genuinamente melhora o throughput em alguns casos, mas 'melhor' não é o mesmo que 'atende à largura de banda necessária' — parar na primeira melhora em vez de terminar a ordem de eliminação desperdiça tempo perseguindo correções parciais.
SOLUÇÃOPercorra a ordem de eliminação até o fim — qualidade do link, balanceamento de carga, MSS TCP, STP, depois modo de encaminhamento da placa LAN de ponta — e não pare no primeiro teste que mostrar qualquer melhora.
SINTOMAA modelagem QoS já está aplicada na interface outbound, mas um dispositivo downstream — um modem óptico, uma estação base — ainda não consegue acompanhar, e o throughput permanece abaixo do que a modelagem sozinha deveria permitir.
CAUSAModelar a taxa não é o mesmo que dimensionar o buffer. Enviar a uma taxa modelada que ainda é mais rápida do que um dispositivo peer lento consegue processar faz o próprio buffer de recepção desse dispositivo transbordar, o que produz perdas que parecem um problema de modelagem mas na verdade são um problema de profundidade de fila.
SOLUÇÃOReduza a contagem máxima de pacotes da fila outbound junto com a configuração de modelagem, para que o roteador não continue entregando ao peer lento mais do que ele consegue absorver.
qos queue-profile limit
queue 0 to 7 length packets 512Tiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.
Siga a ordem de eliminação em sequência em vez de adivinhar: desligue os links um de cada vez para descartar um link defeituoso, habilite ip load-balance hash src-ip, teste tcp adjust-mss para fragmentação, teste undo stp enable, e se a interface lenta estiver em uma placa LAN de ponta (8FE1GE, 24GE), desabilite seu modo de encaminhamento de roteamento centralizado por último. Esse último passo é o que realmente resolve mais vezes do que os outros.
Verifique display logbuffer para entradas CPCAR_DROP_MPU contra packet-type dns-reply. A política CPU-defend padrão limita as respostas DNS a apenas 128 pps em cada placa, e o volume real de respostas DNS de uma rede ocupada supera isso facilmente — as perdas nunca aparecem nos gráficos de largura de banda ou CPU porque acontecem na camada de policiamento de CPU, não na camada de encaminhamento.
Sem erros não significa sem gargalo — uma interface 10GE simplesmente pode enviar mais rápido do que uma interface GE consegue encaminhar, e o excesso não tem para onde ir a não ser ser descartado. Iguale os tipos e taxas de interface onde puder, e onde não puder, aplique modelagem QoS (qos gts) para que o lado de alta velocidade se limite ao que o lado de baixa velocidade consegue realmente absorver.
Só desabilite se a topologia genuinamente não tiver nenhum loop contra o qual proteger — verifique isso primeiro, independentemente do problema de velocidade. No caso de campo por trás desta nota, desabilitar o STP melhorou mensuravelmente o throughput mas ainda não era a correção real; o verdadeiro gargalo era o modo de encaminhamento da placa LAN de ponta. Trate uma melhora de STP como uma pista para continuar, não como a resposta.
display logbuffer é a forma mais rápida de diferenciá-los — uma entrada CPCAR_DROP_MPU nomeando um packet-type específico (dns-reply, no caso comum) com um Drop-Count real é o dispositivo dizendo diretamente que descartou seu próprio tráfego de propósito. Uma perda genuína de caminho upstream não aparecerá ali de forma alguma; ela aparece como perda ou jitter de ping comum medido além do roteador, não dentro dos próprios logs.
Esta nota se baseia em roteadores Huawei série AR e nos casos de campo por trás de display logbuffer, display nat session number, display cpu-usage, cpu-defend policy e qos gts — incluindo o modo de encaminhamento centralizado da placa LAN de ponta, específico dessa família de hardware. Se o seu roteador for de outro fabricante, os comandos exatos mudam, mas a divisão diagnóstica em três — contenção de links multi-saída, policiamento de pacotes em nível de CPU, e incompatibilidade de taxa de interface — se aplica diretamente. Não cobre seleção dinâmica de caminho SD-WAN ou direcionamento baseado em qualidade, nem sobrecarga de throughput específica de túneis criptografados rodando sobre os mesmos links de saída.
Conte-nos se é em todos os links ou só quando vários estão ativos juntos, e o que display logbuffer / display nat session number mostram, e ajudamos você a encontrar o gargalo real.