Nebula Solución de Problemas - Problemas Comunes

Este artículo abordará la solución de los problemas más comunes - si el dispositivo permanece desconectado, no se pueden ver datos/registros (PoE, uso de CPU, uso de datos, registros, etc.), las configuraciones no se aplican (gestión de firmware), utilizando los registros de eventos.

Estamos muy contentos de ver que nuestra solución en la nube Nebula está ganando terreno en el campo, además de ser cada vez más un enfoque clave cuando se trata de ampliar nuestro portafolio. Lo que comenzó como una solución "spin-off" se ha convertido, en alineación con nuestras inversiones y predicciones, en una piedra angular de nuestras operaciones y productos. Sin embargo, con este cambio de enfoque, el equipo compatible con Nebula se está utilizando cada vez más en entornos profesionales de redes. Este cambio plantea la pregunta para muchos de nuestros clientes: "¿Qué puedo hacer para analizar mis problemas antes de contactar a alguien más?"

Esta guía proporcionará algunas ideas y sugerencias sobre cosas que verificar en caso de que sus dispositivos no funcionen correctamente; algunas son de naturaleza más genérica (= ejemplos de buenas prácticas), otras son un poco más específicas para diferentes campos tecnológicos.

Nota: los dispositivos gestionados por Nebula no están destinados a ser configurados de ninguna forma mediante conexión por consola - por favor, utilice solo el acceso SSH a los dispositivos Nebula para monitoreo y, posiblemente, en cooperación con nuestro departamento de soporte/I+D, para mediciones de depuración.

Los dispositivos permanecen desconectados

Imagínese esto: ha registrado su dispositivo con éxito, tal vez incluso configuró algunos ajustes a su gusto y ahora está en la fase de despliegue de su dispositivo. Sin embargo, por razones aún desconocidas para usted, el dispositivo en cuestión simplemente no quiere conectarse, tanto en el sitio, operando, como mostrando completamente que está en línea y responde.

Este es uno de los problemas más comunes al desplegar dispositivos Nebula: la razón, en términos breves, es que los dispositivos por defecto intentan resolver a s.nebula.zyxel.com o d.nebula.zyxel.com. Esto genera dos problemas:

1. Un subdominio en cascada múltiple (por ejemplo, este.ese.yesto.tambiénesto.dominio.com) puede causar problemas para algunos proveedores de DNS.
2. Según estándares más recientes, un subdominio también puede consistir en un solo carácter, mientras que antes era un mínimo de tres caracteres. Algunos servidores DNS tienen problemas con esto.

Muy a menudo, vemos que los servidores DNS de los proveedores de servicios de internet tienen problemas con esto. Nuestra recomendación: cambie el servidor DNS predeterminado a 8.8.8.8 o 1.1.1.1. Más información se puede encontrar aquí:

¿Qué debo hacer si mi dispositivo Nebula no puede conectarse / tiene problemas de conexión / no se comunica en NCC?

¡No puedo ver ningún dato!

A veces, los clientes nos contactan quejándose de que han iniciado sesión por primera vez después de mucho tiempo y sus datos han desaparecido o "no se muestra nada". Puede ser que, debido a una inactividad prolongada en el portal, la organización esté configurada en Modo de Ahorro en la Nube, que básicamente corta toda la recolección de información tras un período inactivo de 30 días. El Modo de Ahorro en la Nube debería indicarse mediante un aviso y un banner (banner azul claro). La solución: desactive el Modo de Ahorro en la Nube y espere unos minutos, los datos deberían volver pronto.

Más información puede verse aquí: Modo de Ahorro en la Nube (Paquete BASE de Nebula)

Las configuraciones no se aplican

Puede que tenga el problema de que su dispositivo aparece en línea, pero los cambios en la configuración parecen no aplicarse. ¡Verifique el firmware! Algunos cambios pueden requerir el firmware más reciente para funcionar correctamente, y a veces los cambios se retienen debido a esto:

Este es un ejemplo perfecto de lo que no quisiéramos ver: en este caso, el firmware del firewall está desactualizado, y esto retrasa la eventual aplicación de nuevos bloques de configuración, mientras que todas las demás estadísticas (CPU, uso de RAM, número de clientes, estado en línea/desconectado) parecen estar bien. La retención de bloques de configuración aplica especialmente, pero no exclusivamente, a nuevas funciones implementadas en el firmware más reciente. Así que, aparte del "Problema de DNS" presentado anteriormente, estos podrían ser consejos valiosos.

Monitoreo a través de Nebula - ¡Información útil al alcance de su mano!

Las funciones de monitoreo proporcionan beneficios reales y herramientas para sus activos de monitoreo y análisis. Para comenzar con algo simple: un dispositivo aparece desconectado, pero usted tiene la sensación de que todavía se comunica correctamente con el Centro en la Nube Nebula. Simplemente vaya a la página principal del dispositivo; para gateways, esto sería:

Dispositivos -> Firewall

y haga una prueba de Ping - si la prueba de ping logra con éxito decirle al dispositivo "Destino de ping W.X.Y.Z" y el dispositivo realmente recibe esto y puede dar retroalimentación de pings exitosos, esto significa que el dispositivo aún se está comunicando con el NCC y el estado desconectado podría ser un problema relacionado con la caché o cookies del navegador.

Otro ejemplo de la vida real: múltiples puertos de switch muestran constantemente mensajes en el registro de eventos indicando un cambio entre conexiones de 10Mb/s y 1Gb/s, y usted no está seguro si el switch está causando problemas.

Verifique la tabla MAC mediante:

Dispositivos > Switches > (seleccionar Switch) > Herramientas en Vivo > Tablas del Switch > Botón Ejecutar

Ahora tiene información que podría ayudarle: en dicho ejemplo real, resultó que todos los puertos de switch que mostraban este comportamiento tenían un proveedor MAC muy específico, lo que apunta más bien hacia un tipo específico de cliente que tiene este problema, y eso significa que el switch no tenía problema. Una posible solución aquí podría ser configurar una velocidad fija en dichos clientes y en los respectivos puertos del switch.

Hay muchos otros ejemplos de cómo el monitoreo puede obrar milagros para resolver errores, pero supongo que ya entiende la idea.

Uso de los registros de eventos para obtener una mejor comprensión de los procesos "bajo el capó"

Los registros de eventos, que cada campo tecnológico tiene los suyos propios, le ofrecen una ayuda tremenda para informarle sobre las razones por las cuales las cosas no funcionan, especialmente en problemas relacionados con WiFi.
Veamos un ejemplo a través de una red WiFi, mostrando tres entradas diferentes:

Analicemos los 3 puntos diferentes uno tras otro:

1. Esto nos dice que una cierta estación, con una dirección MAC determinada, se ha conectado al punto de acceso respectivo. Se conectó con una intensidad de señal de -81dBm, que eventualmente es demasiado débil.
2. Una estación ha dejado un SSID, AP, canal específico debido a un motivo WiFi 3. Los códigos de motivo WiFi son códigos unificados para identificar y entender el comportamiento WiFi. El Código de Motivo WiFi 3 simplemente indica que la estación decidió proactivamente abandonar el SSID.
3. Hubo un proceso de roaming (= movimiento de un AP a otro) de un cliente determinado.

Esto, por supuesto, es solo una pequeña muestra de lo que los registros de eventos pueden decirle, pero muestra que los registros de eventos pueden ser una herramienta poderosa para entender lo que realmente está sucediendo en su red. Específicamente en relación con problemas de WiFi, hay herramientas adicionales para evaluar la calidad WiFi, como Wireless Health, listas de clientes, etc. Los siguientes artículos también pueden darle más información sobre este tema:

Nebula AP "Solución Fácil de Problemas"

Solución Wireless Health de Zyxel Networks