Un cliente que se autentica, obtiene una dirección IP y luego se desconecta no es la misma falla que un cliente que nunca se conecta en absoluto, ni la de uno que no puede itinerar limpiamente entre AP — es su propia categoría, con sus propias seis causas raíz: defensas WIDS que actúan mal contra su propia red, fallos de contabilidad, problemas de sincronización de Portal, un AP ascendente con dificultades, mala sintonización de radio, y una tabla de DHCP snooping que se llena silenciosamente en un switch intermedio.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
La definición importa aquí: se trata de un cliente que llegó a estar en línea — se autenticó, obtuvo una dirección IP — y solo después se desconectó.
"Desconexión anormal" se define con precisión por una razón: un terminal que obtuvo una dirección IP y luego se desconecta repentinamente. Esa es una falla distinta de un cliente que nunca logra conectarse en absoluto — eso es un problema de autenticación, cubierto en nuestra nota de resolución de problemas de autenticación Portal/PSK/802.1X — y distinta también de un cliente que se conecta bien pero no puede itinerar limpiamente entre AP, que es un problema de configuración de itinerancia, cubierto en nuestra nota de configuración de itinerancia Wi-Fi. Esta nota comienza solo después de que el cliente ya está completamente en línea.
A continuación, las dos formas en que realmente se divide la desconexión repentina, las comprobaciones para cada una, las seis causas raíz que explican casi todos estos casos, y respuestas de FAQ extraídas de casos reales de campo.
Cada desconexión repentina es o bien algo que forzó deliberadamente al cliente a desconectarse, o bien algo que se rompió silenciosamente por debajo de una sesión que en realidad nunca se cerró a propósito.
Ubicar primero el síntoma en este árbol indica cuáles tres causas revisar primero, en lugar de adivinar entre las seis a la vez.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
La rama izquierda es una función haciendo exactamente lo que se configuró para hacer, solo que contra el objetivo equivocado — WIDS, contabilidad o sincronización de Portal forzando la sesión a desconectarse a propósito. La rama derecha es algo completamente distinto fallando silenciosamente y tumbando la sesión Wi-Fi como efecto secundario.
Un solo comando le dice mucho antes de siquiera tocar WIDS, RADIUS o la radio.
<HUAWEI> display aaa abnormal-offline-record all
// look for an accounting-related reason, or "WEB user synchronize fail"
// an empty result here means the disconnect isn't an AAA/Portal event -- check WIDS, the AP link, or the radio insteadUna vez que las comprobaciones anteriores le han dicho en qué rama está, una de estas seis es casi siempre la respuesta real.
SÍNTOMALos clientes se desconectan repentina y repetidamente, pero solo en zonas cubiertas por AP cerca del límite entre dos AC — y solo cuando ambos AC tienen WIDS habilitado.
CAUSACuando dos AC se configuran como un único grupo de itinerancia AC a AC y WIDS está habilitado en ambos, el motor WIDS de cada AC puede ver los propios AP del otro AC como radios no reconocidas y empezar a contraatacarlos — enviando tramas de desautenticación destinadas a dispositivos no autorizados hacia AP que en realidad pertenecen a la misma red de confianza. Esto es específico de los grupos de itinerancia multi-AC; una implementación de un solo AC no tiene este modo de falla.
SOLUCIÓNAñada los AP de cada AC a la lista blanca WIDS del otro AC, para que ningún controlador trate las radios legítimas del otro como un objetivo de contraataque.
SÍNTOMAUn cliente o AP específico sigue siendo desconectado, y las alarmas de detección de ataques de WIDS (fuerza bruta de clave débil, deauth/disassociation falsificado, inundación, IV débil) se disparan repetidamente para la misma fuente.
CAUSALa lógica de detección hace exactamente lo que está diseñada para hacer — solo que un patrón de cliente legítimo pero inusualmente ocupado o ruidoso cruza los mismos umbrales que un ataque real. Dejada con los ajustes predeterminados, la misma fuente repetida también puede generar una avalancha de alarmas duplicadas además de las desconexiones.
SOLUCIÓNActive el registro de detección de ataques para confirmar que realmente es este cliente o AP el que lo desencadena, use la función de silencio de detección para detener las alarmas repetidas de la misma fuente mientras investiga, y vuelva a desactivar la detección de ataques una vez confirmado el patrón — dejarla activa indefinidamente sí cuesta algo de rendimiento.
SÍNTOMAEl cliente se autentica bien, obtiene una dirección IP, parece completamente en línea — y luego se desconecta poco después, sin ningún síntoma del lado de la radio.
CAUSALa dirección o el puerto del servidor de contabilidad en realidad no coinciden en ambos extremos, o el servidor RADIUS no admite o no ha habilitado la contabilidad en absoluto — y el AC trata el propio fallo de contabilidad como un motivo para forzar la sesión fuera de línea, aunque la autenticación ya haya tenido éxito.
SOLUCIÓNConfirme que la IP y el puerto del servidor de contabilidad coinciden con la configuración del AC, y que la contabilidad está realmente habilitada en el servidor RADIUS. Si el servidor RADIUS aún no admite contabilidad, desactive la contabilidad en la plantilla de contabilidad, o configure una política de permanecer en línea si falla la contabilidad para que el usuario siga conectado de todos modos.
SÍNTOMAdisplay aaa abnormal-offline-record all muestra WEB user synchronize fail como motivo de desconexión.
CAUSAEl dispositivo y el servidor Portal no lograron sincronizar la información del usuario entre sí, y el dispositivo fuerza al usuario a desconectarse como resultado directo de ese fallo de sincronización — independientemente de si la conexión de radio del cliente estuvo bien todo el tiempo.
SOLUCIÓNVerifique si el servidor Portal realmente tiene habilitada la sincronización de información; si el servidor Portal no admite la función en absoluto, desactive la sincronización de información de usuarios autenticados por Portal en el dispositivo en lugar de dejar que siga forzando a los usuarios a desconectarse.
<HUAWEI> display aaa abnormal-offline-record all
// Offline reason: WEB user synchronize fail -> device-to-Portal-server sync failure, not a radio problemSÍNTOMALas desconexiones se agrupan en AP o radios específicas, sin ninguna señal de WIDS, contabilidad o Portal en los registros.
CAUSAUn intervalo de beacon configurado demasiado largo alarga los propios intervalos de reposo del cliente y hace que la reconexión parezca una desconexión; configurado demasiado corto, en cambio añade una sobrecarga de aire innecesaria. Por separado, si las radios nunca se han ajustado, AP individuales pueden tener una utilización de canal alta o canales solapados con AP vecinos — ambos producen el mismo síntoma similar a desconexión por un mecanismo completamente distinto.
SOLUCIÓNAjuste el intervalo de beacon para que coincida con la cantidad real de VAP en la radio en lugar de dejar un valor predeterminado dimensionado para otro despliegue, y ejecute el ajuste de radio (ajuste automático de canal/potencia) para resolver la utilización de canal y el solapamiento entre AP vecinos.
SÍNTOMALos clientes se conectan, obtienen una dirección, y se desconectan casi inmediatamente después, en toda la red o en los puertos descendentes de un switch específico — sin ninguna señal de WIDS, contabilidad o radio que lo explique.
CAUSAUn switch intermedio con dhcp snooping enable configurado mantiene una tabla de enlace de tamaño fijo. Una vez que esa tabla se llena, el switch deja de reenviar completamente cualquier paquete DHCP adicional — así que un cliente que ya tiene un arrendamiento pierde la capacidad de renovarlo, y se desconecta en el instante en que el arrendamiento no puede renovarse. Se lee exactamente como un problema de Wi-Fi, pero la falla real es un límite de tabla en un switch cableado en la ruta.
SOLUCIÓNSi el DHCP snooping no es estrictamente necesario en ese segmento, desactívelo; si lo es, verifique el número de entradas actual contra el límite de tabla de snooping de la plataforma en lugar de dejar que falle silenciosamente. No lo deje deshabilitado permanentemente sin un plan — es una función de seguridad contra servidores DHCP no autorizados, no solo una molestia.
[Switch] undo dhcp snooping enable
// only if the feature isn't required on this segment -- otherwise size or scope the snooping table insteadSacadas directamente del campo — las que vale la pena tener respondidas de antemano.
Son categorías de falla distintas con soluciones distintas. Un cliente que nunca se conecta está fallando la autenticación — Portal, PSK o 802.1X — y está cubierto en nuestra nota de resolución de problemas de autenticación inalámbrica. Esta nota comienza solo después de que el cliente ya tiene una dirección IP y estaba completamente en línea.
Los problemas de itinerancia tratan de un traspaso limpio entre AP mientras el cliente permanece conectado todo el tiempo — cubierto en nuestra nota de configuración de itinerancia Wi-Fi. Esta nota trata de un cliente que permanece en el mismo AP y luego se desconecta directamente, sin ningún traspaso involucrado.
Un registro vacío significa que la desconexión no fue un evento de contabilidad o sincronización de Portal según el subsistema AAA. Revise a continuación los registros de WIDS y detección de ataques, y la propia conectividad del AP con su AC — una desconexión que el subsistema AAA nunca vio suele estar más arriba, en la radio o en el enlace AP-AC.
El contraataque mutuo entre AP requiere específicamente dos AC en un grupo de itinerancia, por lo que una implementación de un solo AC no tiene ese modo de falla en particular. Sin embargo, la detección de ataques ordinaria aún puede fallar en un solo AC si sus umbrales son demasiado agresivos para una red genuinamente ocupada — revise los registros de detección y considere la función de silencio antes de descartar el WIDS por completo.
No como solución permanente. El DHCP snooping es una función de seguridad que bloquea servidores DHCP no autorizados en ese segmento, y dejarlo desactivado reabre esa exposición. La mejor solución a largo plazo es dimensionar o acotar la tabla de snooping solo a las VLAN que realmente lo necesitan, y volver a habilitarlo una vez resuelto el problema de capacidad subyacente — vea nuestra nota de resolución de problemas de DHCP para el panorama más amplio.
Un patrón correlacionado en el tiempo apunta a algo programado o periódico en lugar de un fallo de radio puntual — un barrido de detección de ataques programado, un trabajo por lotes de contabilidad RADIUS, una ola de renovaciones de arrendamiento DHCP en el cambio de turno, o un trabajo periódico de escaneo/ajuste de radio. Compare las marcas de tiempo en aaa abnormal-offline-record y los registros de WIDS/registro con cualquier trabajo programado antes de asumir que es aleatorio.
Esta nota se basa en la arquitectura WLAN AC/AP de Huawei, su modelo de clasificación de desconexión anormal, y los mecanismos aaa abnormal-offline-record, WIDS y DHCP snooping detrás de ella, además de los casos de campo que los respaldan. No cubre en profundidad las causas del lado del cliente — el propio controlador Wi-Fi de un dispositivo o su comportamiento de ahorro de energía pueden producir un síntoma similar y quedan fuera de lo que el lado de red puede diagnosticar — ni plataformas de controlador que no sean de Huawei.
Cuéntenos qué muestra display aaa abnormal-offline-record all, si es uno o dos AC en un grupo de itinerancia, y cómo se agrupan las desconexiones, y le ayudamos a acotarlo.