'Internet lento' detrás de un router NAT es en realidad al menos tres problemas distintos bajo la misma queja: un enlace de salida que va bien solo pero se ralentiza en cuanto varios enlaces llevan tráfico juntos, toda una LAN cuya navegación se arrastra por lo que la CPU descarta silenciosamente, o una dirección de una prueba de velocidad que no alcanza una cifra que el mismo cable ya demostró poder alcanzar. Este es el orden que los distingue, los comandos display y de configuración para cada uno, y las causas que aparecen una y otra vez.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
El NAT es lo que está corriendo cuando aparece el síntoma, lo cual no es lo mismo que el NAT sea la causa.
Un router NAT se sitúa justo en el punto donde se reporta cada uno de estos síntomas, así que es lo primero que se culpa — y rara vez es la falla real. La verdadera pregunta es cuál de las tres formas toma la ralentización: solo aparece cuando más de un enlace WAN lleva tráfico al mismo tiempo; está presente todo el tiempo, para todos, en cada enlace; o solo se muestra en una dirección de una prueba de velocidad que una conexión directa demostró poder alcanzar a plena tasa. Cada forma apunta a una parte completamente distinta del equipo — reenvío de enlace/tarjeta, limitación de paquetes a nivel de CPU, o coincidencia de tasa de interfaz — y ninguna se arregla mirando fijamente la configuración de NAT en sí.
A continuación, esa división en tres, las comprobaciones y comandos exactos para cada una, cinco causas raíz que explican la mayoría de estos casos en el campo, y respuestas de preguntas frecuentes extraídas de casos reales.
Clasifique la queja en este árbol antes de tocar una sola regla de NAT.
Si la ralentización es constante o condicional, y qué dirección afecta, le indica cuál de las comprobaciones siguientes aplica realmente.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Un enlace que solo es lento bajo carga combinada, toda una oficina lenta todo el tiempo, y una dirección de una prueba de velocidad que se queda corta son tres fallas distintas con tres soluciones distintas. Clasifique primero el caso aquí, luego trabaje la etapa correspondiente a continuación.
Tres etapas, tres cuellos de botella distintos — reenvío de enlace y tarjeta, limitación de paquetes a nivel de CPU, y desajuste de tasa de interfaz.
Cualquier enlace probado solo está bien; solo la carga combinada es lenta. Recorra esto en orden en lugar de cambiar varias cosas a la 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 que cargan lento para todos aguas abajo de una interfaz NAT, sin un problema obvio de enlace o ancho de banda, es ante todo un síntoma de limitación 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 loadsLa prueba de velocidad ascendente es normal, la descendente no — y quitar el router de la ruta demuestra que el enlace descendente en sí puede alcanzar la tasa completa de interfaz.
<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 deviceUna vez que la etapa anterior le indica hacia dónde mirar, estas cinco explican la mayoría de lo que realmente está mal.
SÍNTOMACualquier enlace WAN probado solo da velocidad de navegación y descarga normal. La ralentización solo aparece cuando varios enlaces de salida de IP fija llevan tráfico real al mismo tiempo.
CAUSAAlgunas tarjetas LAN de gama alta (8FE1GE, 24GE) funcionan en modo de reenvío de enrutamiento centralizado por defecto. Bajo la carga combinada de varios enlaces de salida activos a la vez, esa ruta centralizada se convierte en el cuello de botella — aunque la calidad del enlace, el balanceo de carga, el MSS y el STP estén todos correctos individualmente.
SOLUCIÓNDeshabilite el reenvío de enrutamiento centralizado en la tarjeta LAN de gama alta para que deje de ser el punto de estrangulamiento compartido del tráfico multi-salida.
[Huawei] set workmode lan-card l3centralizeSÍNTOMACada host detrás del router experimenta cargas de página lentas, pero tanto la utilización de ancho de banda como el uso de CPU se ven completamente normales.
CAUSALa política CPU-defend predeterminada aplicada a todas las tarjetas limita los paquetes de respuesta DNS a solo 128 paquetes por segundo. El volumen legítimo de respuestas DNS de una red ocupada puede superar eso fácilmente, y todo lo que exceda el límite se descarta silenciosamente antes de que los hosts vean la respuesta — lo cual se ve exactamente como una queja genérica de internet lento.
SOLUCIÓNCree una política CPU-defend dedicada y eleve el límite de tasa de dns-reply muy por encima del volumen de tráfico real, luego aplíquela globalmente.
[Huawei] cpu-defend policy dns
[Huawei-cpu-defend-policy-dns] packet-type dns-reply rate-limit 512
[Huawei] cpu-defend-policy dns globalSÍNTOMALa prueba de velocidad ascendente está bien. La prueba de velocidad descendente se queda muy por debajo de la tasa de interfaz, y quitar el router de la ruta demuestra que el enlace descendente por sí solo puede alcanzar la velocidad gigabit completa.
CAUSAEl tráfico descendente que fluye de una interfaz de alta velocidad (10GE) hacia una de menor velocidad (GE) no tiene adónde ir una vez que supera lo que el lado GE puede reenviar realmente — el desajuste en sí produce las pérdidas, independientemente de cualquier cosa aguas arriba.
SOLUCIÓNIguale los tipos y tasas de interfaz cuando sea posible; donde no se puedan igualar, aplique conformación de tráfico QoS para que el lado de alta velocidad nunca envíe más rápido de lo que el lado de baja velocidad puede absorber.
[Huawei-GigabitEthernet0/0/1] qos gts cir 1000000 cbs 125000SÍNTOMAUna ralentización multi-salida se atribuye por turnos a la calidad del enlace, el balanceo de carga, la fragmentación o el STP — cada prueba muestra una mejora parcial o ninguna, y la solución real todavía está más abajo en la lista.
CAUSAVarias causas plausibles pueden contribuir cada una un poco sin ser el cuello de botella real. Deshabilitar el STP, por ejemplo, realmente mejora el throughput en algunos casos, pero 'mejor' no es lo mismo que 'cumple con el ancho de banda requerido' — detenerse en la primera mejora en lugar de terminar el orden de eliminación desperdicia tiempo persiguiendo soluciones parciales.
SOLUCIÓNRecorra el orden de eliminación hasta el final — calidad del enlace, balanceo de carga, MSS TCP, STP, luego modo de reenvío de la tarjeta LAN de gama alta — y no se detenga en la primera prueba que muestre alguna mejora.
SÍNTOMALa conformación QoS ya está aplicada en la interfaz saliente, pero un dispositivo descendente — un módem óptico, una estación base — todavía no puede seguir el ritmo, y el throughput se mantiene por debajo de lo que la conformación por sí sola debería permitir.
CAUSAConformar la tasa no es lo mismo que dimensionar el búfer. Enviar a una tasa conformada que sigue siendo más rápida de lo que un dispositivo par lento puede procesar hace que el propio búfer de recepción de ese dispositivo se desborde, lo que produce pérdidas que parecen un problema de conformación pero en realidad son un problema de profundidad de cola.
SOLUCIÓNReduzca el número máximo de paquetes de la cola saliente junto con la configuración de conformación, para que el router no siga entregando al par lento más de lo que puede absorber.
qos queue-profile limit
queue 0 to 7 length packets 512Extraídas directamente del campo — las que vale la pena tener respondidas de antemano.
Siga el orden de eliminación en secuencia en lugar de adivinar: apague los enlaces uno a uno para descartar un enlace defectuoso, habilite ip load-balance hash src-ip, pruebe tcp adjust-mss para fragmentación, pruebe undo stp enable, y si la interfaz lenta está en una tarjeta LAN de gama alta (8FE1GE, 24GE), deshabilite su modo de reenvío de enrutamiento centralizado al final. Ese último paso es lo que realmente lo resuelve con más frecuencia que los demás.
Revise display logbuffer para entradas CPCAR_DROP_MPU contra packet-type dns-reply. La política CPU-defend predeterminada limita las respuestas DNS a solo 128 pps en cada tarjeta, y el volumen real de respuestas DNS de una red ocupada supera eso fácilmente — las pérdidas nunca aparecen en los gráficos de ancho de banda o CPU porque ocurren en la capa de limitación de CPU, no en la capa de reenvío.
Sin errores no significa sin cuello de botella — una interfaz 10GE simplemente puede enviar más rápido de lo que una interfaz GE puede reenviar, y el exceso no tiene adónde ir salvo ser descartado. Iguale los tipos y tasas de interfaz donde pueda, y donde no pueda, aplique conformación QoS (qos gts) para que el lado de alta velocidad se limite a lo que el lado de baja velocidad puede absorber realmente.
Solo deshabilítelo si la topología realmente no tiene ningún bucle contra el cual proteger — verifique eso primero, independientemente del problema de velocidad. En el caso de campo detrás de esta nota, deshabilitar el STP mejoró mensurablemente el throughput pero aún no era la solución real; el verdadero cuello de botella era el modo de reenvío de la tarjeta LAN de gama alta. Trate una mejora de STP como una pista para seguir, no como la respuesta.
display logbuffer es la forma más rápida de distinguirlos — una entrada CPCAR_DROP_MPU que nombra un packet-type específico (dns-reply, en el caso común) con un Drop-Count real es el dispositivo diciéndole directamente que descartó su propio tráfico a propósito. Una pérdida genuina de ruta ascendente no aparecerá ahí en absoluto; se muestra como pérdida o jitter de ping ordinario medido más allá del router, no dentro de sus propios registros.
Esta nota se basa en routers Huawei serie AR y en los casos de campo detrás de display logbuffer, display nat session number, display cpu-usage, cpu-defend policy y qos gts — incluyendo el modo de reenvío centralizado de la tarjeta LAN de gama alta, específico de esa familia de hardware. Si su router es de otro fabricante, los comandos exactos cambian, pero la división diagnóstica en tres — contención de enlaces multi-salida, limitación de paquetes a nivel de CPU, y desajuste de tasa de interfaz — se traslada directamente. No cubre la selección de ruta dinámica SD-WAN ni el enrutamiento basado en calidad, ni la sobrecarga de throughput específica de túneles cifrados que corren sobre los mismos enlaces de salida.
Cuéntenos si es en todos los enlaces o solo cuando varios están activos juntos, y qué muestran display logbuffer / display nat session number, y le ayudaremos a encontrar el cuello de botella real.