"Slow internet" behind a NAT router is at least three different problems wearing the same complaint: an egress link that's fine alone but slows down the moment several links carry traffic together, a whole LAN's browsing dragging because of what the CPU is quietly dropping, or one direction of a speed test falling short of a number the same cable proved it could hit. This is the order that tells them apart, the display and configuration commands for each, and the causes that show up again and again.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
NAT is what's running when the symptom shows up, which is not the same thing as NAT being what's causing it.
A NAT router sits at the point where every one of these symptoms gets reported, so it's the first thing blamed — and it's rarely the actual fault. The real question is which of three shapes the slowdown takes: it only appears once more than one WAN link is carrying traffic at the same time; it's there all the time, for everyone, on every link; or it only shows up in one direction of a speed test that a direct connection proved could hit full rate. Each shape points at a completely different part of the box — link/board forwarding, CPU-level packet policing, or interface rate matching — and none of them get fixed by staring at the NAT configuration itself.
What follows is that three-way split, the checks and exact commands for each, five root causes that account for most of these tickets in the field, and FAQ answers pulled from real cases.
Sort the complaint onto this tree before touching a single NAT rule.
Whether the slowdown is constant or conditional, and which direction it hits, tells you which of the checks below actually applies.
Diagram labels are kept in English for engineering clarity.
A link that's only slow under combined load, a whole office that's slow all the time, and one direction of a speed test falling short are three different faults with three different fixes. Sort the ticket here first, then work the matching stage below.
Three stages, three different bottlenecks — link and board forwarding, CPU-level packet policing, and interface-rate mismatch.
Any single link tested alone is fine; only combined load is slow. Work through these in order rather than changing several things at once.
#
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 caseWeb pages loading slowly for everyone downstream of a NAT interface, with no obvious link or bandwidth problem, is a CPU-policing symptom before it's anything else.
<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 loadsUpstream speed tests normally, downstream doesn't — and removing the router from the path proves the downlink itself is capable of full interface rate.
<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 deviceOnce the stage above has told you where to look, these five account for most of what's actually wrong.
SYMPTOMAny single WAN link tested alone gives normal browsing and download speed. The slowdown only appears once several fixed-IP egress links are all carrying real traffic at the same time.
CAUSESome high-end LAN cards (8FE1GE, 24GE) run in a centralized routing-forwarding mode by default. Under the combined load of several active egress links at once, that centralized path becomes the bottleneck — even though link quality, load balancing, MSS and STP all check out individually.
FIXDisable centralized routing-forwarding on the high-end LAN card so it stops being the shared choke point for multi-egress traffic.
[Huawei] set workmode lan-card l3centralizeSYMPTOMEvery host behind the router experiences slow page loads, but bandwidth utilization and CPU usage both look completely normal.
CAUSEThe default CPU-defend policy applied to all boards rate-limits DNS reply packets to only 128 packets per second. A busy network's legitimate DNS reply volume can exceed that easily, and everything above the limit gets silently dropped before hosts ever see the response — which looks exactly like a generic slow-internet complaint.
FIXCreate a dedicated CPU-defend policy and raise the dns-reply rate limit well above real traffic volume, then apply it globally.
[Huawei] cpu-defend policy dns
[Huawei-cpu-defend-policy-dns] packet-type dns-reply rate-limit 512
[Huawei] cpu-defend-policy dns globalSYMPTOMUpstream speed test is fine. Downstream speed test falls well short of interface rate, and removing the router from the path proves the downlink alone can hit full gigabit speed.
CAUSEDownstream traffic flowing from a high-speed interface (10GE) toward a lower-speed interface (GE) has nowhere to go once it outpaces what the GE side can actually forward — the mismatch itself produces the drops, independent of anything upstream.
FIXMatch interface types and rates where possible; where they can't be matched, apply QoS traffic shaping so the high-speed side never sends faster than the low-speed side can absorb.
[Huawei-GigabitEthernet0/0/1] qos gts cir 1000000 cbs 125000SYMPTOMA multi-egress slowdown gets blamed on link quality, load balancing, fragmentation, or STP in turn — each test shows a partial improvement or none at all, and the real fix is still further down the list.
CAUSESeveral plausible causes can each contribute a small amount without being the actual bottleneck. Disabling STP, for instance, genuinely improves throughput in some cases, but "better" is not the same as "meets the required bandwidth" — stopping at the first improvement instead of finishing the elimination order wastes time chasing partial fixes.
FIXWork the elimination order through to the end — link quality, load balancing, TCP MSS, STP, then high-end LAN card forwarding mode — and don't stop at the first test that shows any improvement at all.
SYMPTOMQoS shaping is already applied on the outbound interface, but a downstream device — an optical modem, a base station — still can't keep up, and throughput stays below what shaping alone should allow.
CAUSEShaping the rate isn't the same as sizing the buffer. Sending at a shaped rate that's still faster than a slow peer device can process causes that device's own receive buffer to overflow, which produces drops that look like a shaping problem but are actually a queue-depth problem.
FIXReduce the outbound queue's maximum packet count alongside the shaping configuration, so the router doesn't keep handing the slow peer more than it can absorb.
qos queue-profile limit
queue 0 to 7 length packets 512Pulled straight from the field — the ones worth having an answer ready for.
Work the elimination order in sequence rather than guessing: shut down links one at a time to rule out a single bad link, enable ip load-balance hash src-ip, test tcp adjust-mss for fragmentation, test undo stp enable, and if the slow interface sits on a high-end LAN card (8FE1GE, 24GE), disable its centralized routing-forwarding mode last. That last step is what actually resolves it more often than the others.
Check display logbuffer for CPCAR_DROP_MPU entries against packet-type dns-reply. The default CPU-defend policy rate-limits DNS replies to just 128 pps across every board, and a busy network's real DNS reply volume clears that easily — the drops never show up in bandwidth or CPU graphs because they're happening at the CPU-policing layer, not the forwarding layer.
No errors doesn't mean no bottleneck — a 10GE interface can simply send faster than a GE interface can forward, and the excess has nowhere to go but dropped. Match the interface types and rates where you can, and where you can't, apply QoS shaping (qos gts) so the high-speed side throttles itself to what the low-speed side can actually absorb.
Only disable it if the topology genuinely has no loop to protect against — check that first, independent of the speed problem. In the field case behind this note, disabling STP measurably improved throughput but still wasn't the actual fix; the real bottleneck was the high-end LAN card's forwarding mode. Treat an STP improvement as a clue to keep going, not as the answer.
display logbuffer is the fastest way to tell them apart — a CPCAR_DROP_MPU entry naming a specific packet-type (dns-reply, in the common case) with a real Drop-Count is the device telling you outright that it discarded its own traffic on purpose. Genuine upstream path loss won't show up there at all; it shows up as ordinary ping loss or jitter measured beyond the router, not inside its own logs.
This note is built around Huawei AR-series routers and the field cases behind display logbuffer, display nat session number, display cpu-usage, cpu-defend policy and qos gts — including the high-end LAN card's centralized-forwarding mode, which is specific to that hardware family. If your router is a different vendor, the exact commands change, but the three-way diagnostic split — multi-egress link contention, CPU-level packet policing, and interface-rate mismatch — carries over directly. It doesn't cover SD-WAN dynamic path selection or quality-based steering, or throughput overhead specific to encrypted tunnels running over the same egress links.
Tell us whether it's every link or just when several are active together, and what display logbuffer / display nat session number show, and we'll help you find the actual bottleneck.