Un equipo AntiDDoS que parece totalmente configurado puede seguir dejando pasar un ataque de principio a fin. Esta es la cadena de diagnóstico que encuentra por qué, en orden — si realmente existe una tarea de desvío, si el tráfico de ataque supera el umbral de detección, si el equipo de detección todavía se comunica con SecoManager, y el comando display que detecta una tabla de recursos silenciosamente agotada por debajo de todo lo demás.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
El equipo está activo, la política está aplicada, la licencia se muestra activa — y el ataque igual pasó. Esa brecha casi siempre está en uno de estos cuatro puntos concretos.
Una política de protección totalmente configurada no garantiza que el equipo esté defendiendo realmente una IP determinada en este momento exacto. Entre “la política existe” y “el tráfico se está limpiando” hay una cadena de estados que debe sostenerse de extremo a extremo: debe existir una tarea de desvío para la IP atacada, el equipo de detección debe haber visto realmente que el tráfico de ataque cruzó su umbral, ese equipo de detección todavía debe poder informarlo a SecoManager, y la propia tabla de recursos del equipo debe conservar una entrada libre para alojar el nuevo estado. Con que falle un solo eslabón, el ataque pasa directo mientras todo aguas arriba sigue mostrando verde.
A continuación, esta cadena en el orden en que conviene revisarla, los comandos exactos para cada etapa, las cinco causas raíz que aparecen una y otra vez tras las primeras comprobaciones, y respuestas de casos de campo para las situaciones que no encajan claramente en ninguna etapa.
Cuatro eslabones, revisados de arriba abajo — el primero que resulta vacío es donde está el problema real.
Recorra esta cadena en orden en lugar de saltar directamente a la comprobación de la tabla de recursos al final; cada etapa descarta toda una categoría de causas antes de pasar a la siguiente.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Observe lo que esta cadena deja fuera a propósito: nunca pregunta si la propia política de defensa contra ataques está bien ajustada. Esa pregunta solo importa una vez confirmados intactos los cuatro eslabones anteriores — ajustar una política que nunca recibe tráfico, o que nunca obtiene una entrada libre en la tabla, no cambia nada.
Cada etapa tiene su propio lugar a revisar y su propio comando — confirmar una etapa es la forma más rápida de descartar todo lo que hay detrás de ella.
Empiece aquí, no en la CLI del equipo — el estado de desvío vive del lado de SecoManager, e indica cuál de las siguientes etapas aplica realmente.
<Huawei> display anti-ddos destination-ip ip x.x.x.x
// no entry returned -> this IP's traffic was never mirrored to the detection device
// an entry with zero counters -> traffic is arriving but hasn't crossed threshold yetSolo se genera una tarea de desvío una vez que el propio equipo de detección reporta la anomalía — una política de defensa perfectamente configurada aguas abajo no cambia nada si este paso nunca se dispara.
<Huawei> display interface brief
// confirm the detection interface status is up and is actually receiving mirrored traffic,
// not just physically up with nothing arriving on itEl detector puede ver el ataque perfectamente bien y aun así nunca generar una tarea de desvío si SecoManager nunca se entera.
<Huawei> ping -a x.x.x.x(detection device log-port IP) x.x.x.x(SecoManager collector IP)
// unreachable in either direction -> the detector-to-manager channel itself is the fault,
// not the attack-defense configuration on either endEsta es la comprobación que detecta el fallo sin síntomas evidentes en ningún otro sitio — todo aguas arriba reporta que está bien, y el equipo aun así no defiende.
<Huawei> display anti-ddos resource slot slot-id cpu cpu-id
// check the free column for the resource item this attack/IP needs
// free = 0 -> defense for anything new on this resource stops here, regardless of policy
<Huawei> display cpu-usage slot slot-id cpu cpu-id
<Huawei> display ddos slot
// cross-check: is the SPU CPU actually registered, and how loaded is it right nowUna vez que la cadena de cuatro etapas anterior le ha indicado dónde está el problema, estas cinco causas explican la mayor parte de lo que realmente está mal.
SYMPTOMdisplay anti-ddos destination-ip ip x.x.x.x no devuelve ninguna entrada de monitoreo para la dirección atacada, aunque tanto la política de defensa como el objeto de protección parecen estar correctamente configurados.
CAUSEEl desvío depende por completo de que el equipo de detección vea primero el tráfico de esta IP. Si la configuración de espejo o desvío del router aguas arriba en realidad no incluye el tráfico de esta dirección — un error de alcance, no un error de AntiDDoS — el equipo nunca tiene oportunidad de medirlo, y mucho menos de compararlo con un umbral.
FIXRevise la configuración de espejo/desvío en el router que alimenta al equipo de detección conforme a la documentación del producto para esa configuración de interfaz, antes de tocar nada dentro de la propia política de AntiDDoS.
SYMPTOMLa tarea de desvío existe, el umbral de detección claramente se superó, el canal hacia SecoManager está bien — y el ataque aun así no se está limpiando.
CAUSEdisplay anti-ddos resource muestra la columna free del elemento de recurso correspondiente en 0. El equipo se quedó sin espacio para instalar nuevo estado de defensa, y esto no se anuncia como lo haría una falla de hardware o el vencimiento de una licencia — simplemente limita en silencio lo que el equipo puede proteger a partir de ese punto.
FIXConvierta display anti-ddos resource en un paso estándar de esta lista de verificación, no en un último recurso. Si free está en 0, la solución es capacidad y limpieza en ese elemento de recurso, no otra revisión de la configuración de la política.
<Huawei> display anti-ddos resource
// free column at 0 for the resource item this attack needs -> defense stops here
// regardless of how correctly everything upstream is configuredSYMPTOMdisplay ddos slot muestra la CPU como no registrada, y la defensa simplemente nunca se activa en esa tarjeta, sin importar lo que diga la política.
CAUSEUna CPU de detección o limpieza no registrada no puede ejecutar las funciones de defensa en absoluto. Esto muy a menudo es un problema de licencia subyacente — una licencia en estado Trial (ESN no coincidente), una licencia vencida, o una licencia que cayó en estado Default — más que algo mal en la propia CPU.
FIXVerifique primero display license. Si el estado no es Normal, resolver la licencia es la solución real; registrar manualmente la CPU con el tipo correcto solo tiene sentido una vez que la propia licencia esté sana.
<Huawei> display ddos slot
// CPU not registered -> check License state before anything else
<Huawei> display license
// License state should read Normal; Trial / Default / expired all block real defense capacity
[Huawei] firewall ddos detect-spu slot x cpu x
// specifies the CPU type once the License itself is confirmed healthySYMPTOMdisplay health muestra que la utilización de la CPU de la tarjeta SPU ya está en o por encima del 95%, y la calidad de la defensa se degrada bajo una carga que un equipo saludable absorbería sin problema.
CAUSEUna CPU de SPU saturada no puede mantener el ritmo de instalación de nuevo estado ni la inspección por paquete a la velocidad que exige el ataque, independientemente de si la propia tabla de recursos todavía tiene entradas libres.
FIXComo medida inmediata, configure un agujero negro en el router aguas arriba para la única IP atacada más dañina, para proteger el margen de CPU del resto de lo que se está defendiendo. Pida al operador aguas arriba que aplique limitación de velocidad o filtrado de protocolo contra el ataque en su borde. Como solución estructural, considere agregar tarjetas SPU para elevar el techo del equipo.
SYMPTOMEl tráfico de negocio cae notablemente justo después de pasar por el equipo AntiDDoS, o el tráfico de negocio se dispara y sigue reenviándose con el mismo volumen elevado sin reducción visible.
CAUSEEstos son dos problemas distintos que por error se persiguen con los mismos pasos de resolución. Una caída respecto a una línea base por lo demás estable, que aparece solo después del equipo, apunta a un bloqueo falso (tráfico legítimo atrapado por una política demasiado estricta). Un pico claro por encima de la línea base que sigue reenviándose casi a volumen completo después del equipo apunta a un ataque no detenido (una fuga de protección) — en ese caso es cuando hay que ejecutar la cadena de cuatro etapas anterior.
FIXClasifique primero qué forma está viendo antes de abrir cualquier configuración. Un bloqueo falso se corrige aflojando la regla de política específica que se dispara en exceso; un ataque no detenido se corrige trabajando la cadena de desvío-umbral-comunicación-recurso, no endureciendo más la política.
Extraídas directamente del campo — las que vale la pena tener respondidas de antemano.
No necesariamente todo el equipo — los elementos de recurso se rastrean por separado, y un chasis con varias tarjetas SPU puede revisarse por ranura y por CPU con display anti-ddos resource slot slot-id cpu cpu-id. Lo que sí significa es que ese elemento de recurso específico en 0 no puede aceptar nuevo estado, lo cual basta por sí solo para explicar por qué un ataque o una IP en particular no se está defendiendo mientras otros sí.
Mire primero la línea base. Si el tráfico de negocio era estable antes del equipo y solo cae después de él, sin ningún pico correspondiente aguas arriba, eso es un bloqueo falso — tráfico legítimo está siendo atrapado por una regla de política demasiado agresiva. Si el tráfico ya estaba visiblemente elevado por encima de lo normal antes de llegar al equipo, una caída después del equipo es exactamente cómo se ve una limpieza correcta.
Confirme que la IP de destino realmente tenga un objeto de protección creado e implementado en el equipo, no solo configurado en algún lugar de SecoManager. Si la IP nunca se implementó en el propio equipo, este nunca realiza estadísticas de tráfico para esa dirección — naturalmente no hay datos de tráfico para disparar nada, sin importar cuán correcto sea el resto de la configuración.
Sí, directamente. El estado Trial más a menudo significa que la licencia se activó con un ESN que no coincide con el equipo, y está limitada a 60 días de uso. Un equipo que funciona con una licencia Trial o vencida puede caer en estado Default, lo que interrumpe la función de negocio por completo en lugar de simplemente degradarla. Volver a solicitar y reactivar una licencia que coincida con el ESN correcto es la única solución real — no existe una solución de configuración para un problema de estado de licencia.
Dos causas habituales superan a un valor de umbral mal ajustado: la interfaz de detección en realidad no está recibiendo el tráfico espejado para esa IP específica (revise primero display interface brief y la configuración de espejo), o la propia entrada de monitoreo de la IP de destino nunca se creó porque la dirección nunca se desplegó como objeto de protección. Confirme que el tráfico está llegando antes de asumir que el propio número de umbral necesita cambiar.
Esta nota se basa en la familia de equipos Huawei AntiDDoS gestionada mediante SecoManager, y en la lista de verificación de campo detrás de su comportamiento de desvío, detección, comunicación y tabla de recursos. Asume un despliegue gestionado por SecoManager con limpieza basada en desvío; un despliegue independiente o en modo bypass sigue una lista de verificación relacionada pero no idéntica. No cubre en profundidad la configuración específica de FlowSpec o desvío BGP, ni el enlace de limpieza en la nube para ataques que superan por completo la capacidad local.
Cuéntenos qué etapa de la cadena resultó vacía — desvío, umbral, comunicación o la tabla de recursos — junto con la salida de display anti-ddos resource, y le ayudamos a interpretarla.