« Internet lent » derrière un routeur NAT recouvre au moins trois problèmes différents sous la même plainte : un lien de sortie qui va bien seul mais ralentit dès que plusieurs liens portent du trafic ensemble, tout un LAN dont la navigation traîne à cause de ce que le CPU rejette discrètement, ou une direction d'un test de débit qui n'atteint pas un chiffre que le même câble a pourtant prouvé pouvoir atteindre. Voici l'ordre qui les distingue, les commandes display et de configuration pour chacun, et les causes qui reviennent sans cesse.
Par Yuwen Zhang (Atlas), fondateur d'AtlasCommTech — 13 ans de déploiements de réseaux opérateurs et d'entreprise · Mis à jour en juillet 2026
Le NAT tourne au moment où le symptôme apparaît, ce qui n'est pas la même chose que le NAT en étant la cause.
Un routeur NAT se trouve exactement au point où chacun de ces symptômes est signalé, donc c'est la première chose blâmée — et c'est rarement la panne réelle. La vraie question est de savoir laquelle des trois formes prend le ralentissement : il n'apparaît que lorsque plusieurs liens WAN portent du trafic en même temps ; il est là tout le temps, pour tout le monde, sur chaque lien ; ou il n'apparaît que dans une direction d'un test de débit qu'une connexion directe a prouvé pouvoir atteindre à plein régime. Chaque forme pointe vers une partie complètement différente du boîtier — transmission liaison/carte, limitation de paquets au niveau CPU, ou adéquation du débit d'interface — et aucune ne se règle en fixant la configuration NAT elle-même.
Voici ce partage en trois, les vérifications et commandes exactes pour chacun, cinq causes racines qui expliquent la plupart de ces tickets sur le terrain, et des réponses de FAQ tirées de cas réels.
Classez la plainte sur cet arbre avant de toucher la moindre règle NAT.
Que le ralentissement soit constant ou conditionnel, et la direction qu'il touche, indique laquelle des vérifications ci-dessous s'applique réellement.
Les légendes du schéma restent en anglais pour la clarté technique.
Un lien qui n'est lent que sous charge combinée, tout un bureau lent en permanence, et une direction d'un test de débit qui ne suffit pas sont trois pannes différentes avec trois corrections différentes. Classez d'abord le ticket ici, puis traitez l'étape correspondante ci-dessous.
Trois étapes, trois goulots d'étranglement différents — transmission liaison et carte, limitation de paquets au niveau CPU, et inadéquation du débit d'interface.
Chaque lien testé seul va bien ; seule la charge combinée est lente. Parcourez ces points dans l'ordre plutôt que de changer plusieurs choses à la fois.
#
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 caseDes pages web qui se chargent lentement pour tout le monde en aval d'une interface NAT, sans problème apparent de liaison ou de bande passante, est avant tout un symptôme de limitation 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 loadsLe test de débit amont est normal, l'aval non — et retirer le routeur du chemin prouve que la liaison descendante elle-même est capable du débit d'interface complet.
<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 deviceUne fois que l'étape ci-dessus vous a dit où regarder, ces cinq causes expliquent l'essentiel de ce qui ne va pas.
SYMPTÔMEChaque lien WAN testé seul donne une vitesse de navigation et de téléchargement normale. Le ralentissement n'apparaît que lorsque plusieurs liens de sortie à IP fixe portent tous du trafic réel en même temps.
CAUSECertaines cartes LAN haut de gamme (8FE1GE, 24GE) fonctionnent par défaut en mode de transmission routée centralisée. Sous la charge combinée de plusieurs liens de sortie actifs à la fois, ce chemin centralisé devient le goulot d'étranglement — même si la qualité du lien, la répartition de charge, le MSS et le STP sont tous corrects individuellement.
SOLUTIONDésactivez la transmission routée centralisée sur la carte LAN haut de gamme pour qu'elle cesse d'être le point d'étranglement partagé du trafic multi-sortie.
[Huawei] set workmode lan-card l3centralizeSYMPTÔMEChaque hôte derrière le routeur subit des chargements de pages lents, mais l'utilisation de la bande passante et l'utilisation du CPU paraissent toutes deux parfaitement normales.
CAUSELa politique CPU-defend par défaut appliquée à toutes les cartes limite les paquets de réponse DNS à seulement 128 paquets par seconde. Le volume légitime de réponses DNS d'un réseau chargé peut facilement dépasser cela, et tout ce qui dépasse la limite est silencieusement rejeté avant même que les hôtes ne voient la réponse — ce qui ressemble exactement à une plainte générique d'internet lent.
SOLUTIONCréez une politique CPU-defend dédiée et relevez la limite de débit dns-reply bien au-dessus du volume de trafic réel, puis appliquez-la globalement.
[Huawei] cpu-defend policy dns
[Huawei-cpu-defend-policy-dns] packet-type dns-reply rate-limit 512
[Huawei] cpu-defend-policy dns globalSYMPTÔMELe test de débit amont est bon. Le test de débit aval reste bien en dessous du débit d'interface, et retirer le routeur du chemin prouve que la liaison descendante seule peut atteindre la pleine vitesse gigabit.
CAUSELe trafic descendant allant d'une interface haut débit (10GE) vers une interface à débit inférieur (GE) n'a nulle part où aller une fois qu'il dépasse ce que le côté GE peut réellement transmettre — l'inadéquation elle-même produit les pertes, indépendamment de tout ce qui se passe en amont.
SOLUTIONFaites correspondre les types et débits d'interface quand c'est possible ; là où ce n'est pas possible, appliquez le lissage de trafic QoS pour que le côté haut débit n'envoie jamais plus vite que ce que le côté bas débit peut absorber.
[Huawei-GigabitEthernet0/0/1] qos gts cir 1000000 cbs 125000SYMPTÔMEUn ralentissement multi-sortie est tour à tour attribué à la qualité du lien, à la répartition de charge, à la fragmentation, ou au STP — chaque test montre une amélioration partielle ou aucune, et la vraie solution est encore plus bas dans la liste.
CAUSEPlusieurs causes plausibles peuvent chacune contribuer un peu sans être le véritable goulot d'étranglement. Désactiver le STP, par exemple, améliore réellement le débit dans certains cas, mais « mieux » n'est pas la même chose que « répond à la bande passante requise » — s'arrêter à la première amélioration au lieu de terminer l'ordre d'élimination fait perdre du temps à poursuivre des correctifs partiels.
SOLUTIONParcourez l'ordre d'élimination jusqu'au bout — qualité du lien, répartition de charge, MSS TCP, STP, puis mode de transmission de la carte LAN haut de gamme — et ne vous arrêtez pas au premier test montrant une quelconque amélioration.
SYMPTÔMELe lissage QoS est déjà appliqué sur l'interface sortante, mais un appareil aval — un modem optique, une station de base — n'arrive toujours pas à suivre, et le débit reste inférieur à ce que le lissage seul devrait permettre.
CAUSELisser le débit n'est pas la même chose que dimensionner le tampon. Envoyer à un débit lissé qui reste plus rapide que ce qu'un appareil pair lent peut traiter fait déborder le propre tampon de réception de cet appareil, ce qui produit des pertes qui ressemblent à un problème de lissage mais sont en réalité un problème de profondeur de file.
SOLUTIONRéduisez le nombre maximal de paquets de la file sortante en plus de la configuration de lissage, pour que le routeur ne continue pas à envoyer au pair lent plus qu'il ne peut absorber.
qos queue-profile limit
queue 0 to 7 length packets 512Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Suivez l'ordre d'élimination en séquence plutôt que de deviner : coupez les liens un par un pour écarter un lien défectueux, activez ip load-balance hash src-ip, testez tcp adjust-mss pour la fragmentation, testez undo stp enable, et si l'interface lente se trouve sur une carte LAN haut de gamme (8FE1GE, 24GE), désactivez son mode de transmission routée centralisée en dernier. C'est cette dernière étape qui résout réellement le problème le plus souvent.
Vérifiez les entrées CPCAR_DROP_MPU dans display logbuffer contre packet-type dns-reply. La politique CPU-defend par défaut limite les réponses DNS à seulement 128 pps sur chaque carte, et le volume réel de réponses DNS d'un réseau chargé dépasse facilement cela — les pertes n'apparaissent jamais dans les graphiques de bande passante ou de CPU car elles se produisent au niveau de la limitation CPU, pas au niveau de la transmission.
Aucune erreur ne signifie pas aucun goulot d'étranglement — une interface 10GE peut simplement envoyer plus vite que ce qu'une interface GE peut transmettre, et l'excédent n'a nulle part où aller sinon être rejeté. Faites correspondre les types et débits d'interface là où vous le pouvez, et là où vous ne le pouvez pas, appliquez le lissage QoS (qos gts) pour que le côté haut débit se limite à ce que le côté bas débit peut réellement absorber.
Ne le désactivez que si la topologie n'a réellement aucune boucle à protéger — vérifiez cela d'abord, indépendamment du problème de vitesse. Dans le cas de terrain derrière cette note, désactiver le STP a mesurablement amélioré le débit mais n'était toujours pas la véritable solution ; le vrai goulot d'étranglement était le mode de transmission de la carte LAN haut de gamme. Considérez une amélioration STP comme un indice pour continuer, pas comme la réponse.
display logbuffer est le moyen le plus rapide de les distinguer — une entrée CPCAR_DROP_MPU nommant un packet-type spécifique (dns-reply, dans le cas courant) avec un Drop-Count réel signifie que l'équipement vous dit carrément qu'il a délibérément rejeté son propre trafic. Une véritable perte de chemin en amont n'apparaîtra pas du tout là ; elle se manifeste par une perte ou une gigue de ping ordinaire mesurée au-delà du routeur, pas dans ses propres journaux.
Cette note s'appuie sur des routeurs Huawei série AR et sur les cas de terrain derrière display logbuffer, display nat session number, display cpu-usage, cpu-defend policy et qos gts — y compris le mode de transmission centralisée de la carte LAN haut de gamme, spécifique à cette famille de matériel. Si votre routeur est d'un autre fournisseur, les commandes exactes changent, mais la répartition diagnostique en trois — contention de liens multi-sortie, limitation de paquets au niveau CPU, et inadéquation de débit d'interface — s'applique directement. Elle ne couvre pas la sélection de chemin dynamique SD-WAN ni l'orientation basée sur la qualité, ni la surcharge de débit spécifique aux tunnels chiffrés fonctionnant sur les mêmes liens de sortie.
Dites-nous si c'est sur chaque lien ou seulement quand plusieurs sont actifs ensemble, et ce que montrent display logbuffer / display nat session number, et nous vous aiderons à trouver le véritable goulot d'étranglement.