Un dispositivo se muestra perfectamente en línea en la interfaz de administración del inquilino — canal de configuración en verde, página de gestión de dispositivos limpia — y la autenticación Portal aun así falla para todos los usuarios detrás de él. La página de gestión de dispositivos lee el canal de configuración, no el que realmente autentica a los usuarios. Así se demuestra que el propio canal de autenticación ha quedado desconectado silenciosamente mientras todo lo demás sigue reportando salud, usando el registro del canal del dispositivo y, cuando eso no es concluyente, una comparación directa del conteo de caché mediante redis-cli en una sesión SSH.
By Yuwen Zhang (Atlas), founder of AtlasCommTech — 13 years of carrier & enterprise network deployments · Updated July 2026
Un controlador no rastrea un único estado en línea/desconectado por dispositivo — rastrea varios, y la interfaz de administración solo le muestra uno de ellos.
La conexión de un dispositivo con un controlador de campus gestionado en la nube no es una única marca en línea/desconectado. Se divide en canales separados — configuración, rendimiento, autenticación y (en despliegues fabric) un canal IP Group — cada uno con su propio estado independiente. La página de gestión de dispositivos que la mayoría de los ingenieros revisa primero lee el canal de configuración. Si ese canal está activo, el dispositivo se muestra en verde, y resulta tentador descartar el dispositivo por completo. Pero si específicamente el canal de autenticación quedó obsoleto mientras el canal de configuración se mantuvo activo, los inicios de sesión Portal siguen fallando y nada en el lugar obvio le dice por qué.
A continuación, el triaje que delimita correctamente este tipo de falla, el método del registro del canal del dispositivo que cubre la mayoría de los casos, la comparación de caché por root SSH más redis-cli para los casos que ese método no resuelve, y la elección de remediación entre reiniciar un solo AP y reiniciar todo el servicio de autenticación.
Cuatro causas producen el mismo ticket de "Portal sigue fallando" — aquí es donde se ubica el canal de autenticación falso desconectado entre ellas, y cómo pasar del síntoma a la prueba.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Las otras tres causas se anuncian claramente — una interrupción del servicio en la nube es a nivel de todo el sitio, una falla de red aparece en la URL del navegador y en los registros de acceso, un problema de compatibilidad se limita a un tipo de dispositivo. El falso desconectado es el silencioso: todo lo que está aguas arriba parece estar bien.
Primero delimite el alcance, luego pruébelo de dos formas distintas, y después elija la corrección del tamaño adecuado.
Antes de perseguir específicamente el canal de autenticación, delimite la falla usando las mismas tres comprobaciones que se aplican a cualquier reclamo de autenticación.
Este es el camino rápido — responde directamente si el canal de autenticación específicamente fue registrado como desconectado alguna vez.
Cuando el registro del canal no es concluyente por sí solo, esta comparación lo resuelve — los dos recuentos coinciden o no.
/opt/redis/bin/redis-cli -h 10.173.10.11 -p 26542 -cipherdir /opt/redis/etc/cipher -a campuscachedb@ossdbuser@Example@123
hgetall "ac_campus_portalserver_devtonode"
exitEl tamaño de la discrepancia en los recuentos decide qué palanca activar — reiniciar APs individualmente no se adapta a una desviación a escala de plataforma.
https://<management-plane-ip>:18102
// log in with the admin account, open the product's Services tab
// search for the target service, select it, click Stop, wait for status to change, then click StartEl mecanismo anterior es sencillo una vez que se ve — estas son las formas en que realmente hace tropezar a los ingenieros.
SÍNTOMALa página de gestión de dispositivos muestra el dispositivo en verde y saludable, pero los usuarios detrás de él no pueden completar la autenticación Portal.
CAUSAUn controlador rastrea la configuración, el rendimiento, la autenticación y (en escenarios fabric) el estado IP Group como canales separados. La página de gestión de dispositivos lee específicamente el canal de configuración. Un dispositivo puede mostrarse totalmente en línea ahí mientras su canal de autenticación — el que realmente importa para los inicios de sesión Portal — está obsoleto.
SOLUCIÓNUna vez que el canal de configuración se verifica como correcto y la autenticación sigue fallando, deje de mirar la página de gestión de dispositivos y vaya directamente al registro del canal del dispositivo para el historial del canal de autenticación de ese dispositivo específico.
SÍNTOMANada en la interfaz de administración misma marca un problema — sin alarma, sin estado rojo, sin discrepancia evidente en ninguna parte de la pantalla.
CAUSALa interfaz no verifica cruzadamente la lista de dispositivos de la plataforma contra el propio recuento de registros de la caché de autenticación — los dos números pueden desviarse silenciosamente, y nada revela esa desviación a menos que alguien cuente ambos lados de forma independiente y los compare.
SOLUCIÓNTrate el recuento en línea visible en la administración y el recuento en línea de la caché redis como dos números independientes que deben compararse activamente — no asuma que la interfaz le avisaría si hubieran divergido.
SÍNTOMAEjecutar un comando redis-cli simple contra la caché del controlador devuelve un error de autenticación o nada en absoluto, haciendo parecer que el propio servicio de caché está caído.
CAUSALa instancia de redis de este controlador se ejecuta en un puerto no predeterminado con TLS habilitado a través de un directorio de cifrado específico y una contraseña de cuenta de servicio — nada de eso lo proporciona una invocación simple de redis-cli. El comando debe llevar exactamente -h, -p, -cipherdir y -a, o falla antes de siquiera llegar a la consulta real de la caché.
SOLUCIÓNInvóquelo siempre con el conjunto completo de indicadores — host, puerto, directorio de cifrado y credencial de cuenta de servicio — como un solo comando, no construido interactivamente, y salga de la sesión root en cuanto termine la consulta.
/opt/redis/bin/redis-cli -h 10.173.10.11 -p 26542 -cipherdir /opt/redis/etc/cipher -a campuscachedb@ossdbuser@Example@123
hgetall "ac_campus_portalserver_devtonode"SÍNTOMAReiniciar el único AP afectado soluciona ese dispositivo, pero la misma falla sigue apareciendo en otros lugares del inquilino.
CAUSACuando la discrepancia en el recuento es grande, no se trata de un puñado de entradas obsoletas — es el propio servicio de autenticación el que necesita restablecer conexiones a escala de plataforma. Reiniciar los AP uno por uno trata un problema de nivel de servicio como uno de nivel de dispositivo, y nunca logra alcanzarlo.
SOLUCIÓNCompare el tamaño de la discrepancia antes de elegir un remedio: una brecha pequeña y aislada se soluciona con un reinicio de AP; una brecha grande y dispersa se soluciona reiniciando CampusAAAAuthService.
SÍNTOMAUn ticket independiente describe fallos de autenticación en puertos cableados, con códigos de error y una cadena RADIUS que no coinciden con nada descrito aquí.
CAUSAEl canal de autenticación y su modo de falla de falso desconectado son específicos de un controlador que actúa como servidor Portal sobre el protocolo Haca. La autenticación 802.1X/NAC cableada funciona con una cadena cliente-dispositivo de acceso-RADIUS completamente separada, con sus propios códigos de error y su propia CLI, y no tiene nada que ver con esta discrepancia caché-versus-interfaz.
SOLUCIÓNNo recurra a una comparación de caché con redis-cli en un ticket de autenticación cableada — trabaje la cadena 802.1X/NAC según sus propios términos.
Extraídas directamente del campo — aquellas para las que vale la pena tener una respuesta lista.
El canal de configuración es lo que el controlador usa para enviar configuración a un dispositivo, y también es lo que refleja el estado de la página de gestión de dispositivos. El canal de rendimiento es cómo el controlador recibe informes de CPU, memoria y conteo de terminales — su pérdida afecta la visibilidad de monitoreo, no el reenvío. El canal de autenticación existe específicamente cuando el controlador actúa como servidor Portal sobre el protocolo Haca; cuando está desconectado, la autenticación Portal para ese dispositivo falla aunque el reenvío y la gestión parezcan correctos.
Un dispositivo realmente desconectado se muestra desconectado en todas partes — canal de configuración, canal de rendimiento, página de gestión de dispositivos, todo. Un canal de autenticación falso desconectado es más limitado: el dispositivo es alcanzable, su canal de configuración está activo, y la interfaz de administración lo muestra saludable, pero su entrada de caché del canal de autenticación nunca se actualizó tras un ciclo anterior de desconexión-reconexión, por lo que los inicios de sesión Portal enrutados a través de él siguen fallando.
Un comando de solo lectura como hgetall contra esta clave específica es una consulta, no una escritura, y es el método documentado para esta comprobación exacta. Las precauciones que importan son de procedimiento: use la cuenta root solo durante la consulta, proporcione todos los indicadores de conexión exactamente como está documentado, y salga de la sesión inmediatamente después en lugar de dejar una shell root abierta.
Observe cuán grande es la brecha. Si es una diferencia pequeña —un dispositivo o unos pocos— reiniciar ese AP para forzarlo a reconstruir su sesión es la corrección proporcionada. Si la brecha es grande, es el propio servicio de autenticación subyacente el que necesita reiniciarse para que todos los dispositivos se reconecten a la vez; reiniciar dispositivos individualmente a esa escala simplemente no alcanzará.
No. Esta condición de falso desconectado es específica del canal de autenticación que un controlador mantiene cuando actúa como servidor Portal sobre Haca. La autenticación 802.1X/NAC cableada funciona con una cadena cliente-dispositivo de acceso-RADIUS completamente separada, con sus propios códigos de error y CLI, y no se ve afectada en absoluto por esta discrepancia particular de caché frente a interfaz.
Esta nota se basa en el modelo de canales de un controlador de campus gestionado en la nube específico, su registro del canal del dispositivo, y la comparación de caché por root más redis-cli documentada para él, además de la guía operativa detrás de ella. Cubre específicamente el caso de falso desconectado del canal de autenticación Portal/Haca — no cubre fallas del canal de configuración o rendimiento, estados desconectados relacionados con licencias, ni autenticación 802.1X/NAC cableada, todos los cuales siguen sus propias rutas de diagnóstico separadas.
Cuéntenos el recuento en línea visible en la administración frente a lo que muestra la caché de autenticación, y le ayudaremos a interpretar la diferencia.