Dépannage Nebula - Problèmes courants

Cet article traite du dépannage des problèmes les plus courants - si les appareils restent hors ligne, si vous ne voyez aucune donnée/journal (PoE, utilisation CPU, utilisation des données, journaux, etc.), si les configurations ne sont pas appliquées (gestion du firmware), en utilisant les journaux d'événements.

Nous sommes très heureux de voir que notre solution Cloud Nebula prend de l’ampleur sur le terrain et devient de plus en plus un axe clé dans l’expansion de notre portefeuille. Ce qui a commencé comme une solution « spin-off » est devenu, en accord avec nos investissements et prévisions, une pierre angulaire de nos opérations et produits. Cependant, avec ce changement de focus, les équipements compatibles Nebula sont de plus en plus utilisés dans des environnements réseau professionnels. Ce changement soulève pour beaucoup de nos clients la question : « Que puis-je faire pour analyser mes problèmes avant de contacter quelqu’un d’autre ? »

Ce guide vous donnera quelques idées et conseils sur ce qu’il faut vérifier si vos appareils ne fonctionnent pas correctement - certains sont de nature plus générique (= exemples de bonnes pratiques), d’autres sont un peu plus spécifiques à différents domaines technologiques.

Note : les appareils gérés par Nebula ne doivent en aucun cas être configurés via une connexion console - veuillez utiliser uniquement l’accès SSH aux appareils Nebula pour la surveillance et éventuellement, en collaboration avec notre support/département R&D, pour des mesures de débogage.

Les appareils restent hors ligne

Imaginez ceci : vous avez enregistré votre appareil avec succès, peut-être même configuré certains paramètres selon vos préférences et vous êtes maintenant en phase de déploiement de votre appareil. Cependant, pour des raisons qui vous sont encore inconnues, l’appareil en question ne veut tout simplement pas se connecter en ligne, ni sur site, ni fonctionner, ni apparaître comme en ligne et réactif.

C’est l’un des problèmes les plus courants lors du déploiement des appareils Nebula - la raison en bref est que les appareils tentent par défaut de résoudre soit s.nebula.zyxel.com soit d.nebula.zyxel.com. Cela pose deux problèmes :

1. Un sous-domaine en cascade multiple (par exemple this.that.andthis.alsothis.domain.com) peut entraîner des problèmes chez certains fournisseurs DNS
2. Selon les normes récentes, un sous-domaine peut aussi être composé d’un seul caractère, alors qu’auparavant il fallait au minimum trois caractères. Certains serveurs DNS rencontrent des difficultés avec cela.

Très souvent, nous constatons que les serveurs DNS des fournisseurs d’accès Internet ont des problèmes avec cela. Notre recommandation : changez le serveur DNS par défaut pour 8.8.8.8 ou 1.1.1.1. Plus d’informations sont disponibles ici :

Que faire si mon appareil Nebula ne peut pas se connecter en ligne / rencontre des problèmes de connexion / ne communique pas avec NCC ?

Je ne vois aucune donnée !

Parfois, des clients nous contactent en se plaignant qu’ils se connectent pour la première fois depuis longtemps et que leurs données ont disparu ou que « rien n’est affiché ». Il se peut qu’en raison d’une longue période d’inactivité sur le portail, l’organisation soit passée en mode d’économie Cloud, ce qui interrompt la collecte d’informations après une période d’inactivité de 30 jours. Le mode d’économie Cloud devrait être indiqué par une invite et une bannière (bannière bleu clair). La solution : désactivez le mode d’économie Cloud et attendez quelques minutes, les données devraient bientôt réapparaître.

Plus d’informations sont disponibles ici : Mode d’économie Cloud (Nebula BASE Pack)

Les configurations ne sont pas appliquées

Vous pouvez avoir le problème que votre appareil apparaisse en ligne, mais que les modifications de configuration ne semblent pas s’appliquer ? Vérifiez le firmware ! Certaines modifications nécessitent la dernière version du firmware pour fonctionner correctement, et parfois les changements sont bloqués à cause de cela :

C’est un parfait exemple de ce que nous ne voulons pas voir - dans ce cas, le firmware du pare-feu est obsolète, ce qui empêche l’application de nouveaux blocs de configuration, alors que toutes les autres statistiques (CPU, utilisation RAM, nombre de clients, état en ligne/hors ligne) semblent correctes. Ce blocage des blocs de configuration s’applique en particulier, mais pas exclusivement, aux nouvelles fonctionnalités implémentées dans les firmwares les plus récents. Donc, en plus du « problème DNS » présenté ci-dessus, ce sont des conseils utiles.

Surveillance via Nebula - Des informations utiles à portée de main !

Les fonctionnalités de surveillance apportent de réels bénéfices et outils à vos actifs de monitoring et d’analyse. Pour commencer par quelque chose de simple - un appareil apparaît hors ligne, mais vous avez le sentiment qu’il communique toujours correctement avec le Cloud Center Nebula ? Allez simplement à la page principale de l’appareil - pour les passerelles, ce serait :

Devices -> Firewall

et effectuez un test Ping - si le test ping parvient effectivement à indiquer à l’appareil « Ping destination W.X.Y.Z » et que l’appareil reçoit cela et peut retourner un retour de pings réussis, cela signifie que l’appareil communique en fait toujours avec le NCC et que l’état hors ligne pourrait être un problème lié au cache ou aux cookies du navigateur.

Un autre exemple concret : plusieurs ports de commutateur affichent constamment des messages dans le journal d’événements indiquant une bascule entre des connexions 10Mb/s et 1Gb/s, et vous vous demandez si le commutateur est en cause ?

Vérifiez la table MAC via :

Devices > Switches > (sélectionner le Switch) > Live Tools > Switch Tables > Bouton Exécuter

Vous avez maintenant des informations qui peuvent vous aider - dans cet exemple concret, il s’est avéré que tous les ports de commutateur affichant ce comportement avaient un fournisseur MAC très spécifique, ce qui indique plutôt un type de client spécifique ayant ce problème, signifiant que le commutateur n’avait pas de problème - une solution possible ici pourrait être de configurer une vitesse fixe sur ces clients et les ports de commutateur respectifs.

Il existe de nombreux autres exemples de la manière dont la surveillance peut faire des miracles pour résoudre des erreurs, mais je pense que vous avez saisi l’idée.

Utiliser les journaux d’événements pour mieux comprendre les processus « sous le capot »

Les journaux d’événements, dont chaque domaine technologique dispose de ses propres, vous offrent une aide précieuse pour vous informer des raisons pour lesquelles les choses ne fonctionnent pas - notamment dans les problèmes liés au WiFi.
Regardons un exemple via un réseau WiFi, montrant trois entrées différentes :

Analysons les 3 points différents un par un :

1. Cela nous indique qu’une certaine station, avec une certaine adresse MAC, s’est connectée au point d’accès respectif. Elle s’est connectée avec une puissance de signal de -81dBm, ce qui est finalement trop faible.
2. Une station a quitté un SSID, un point d’accès, un canal spécifique en raison d’un code raison WiFi 3. Les codes raison WiFi sont des codes unifiés pour identifier et comprendre le comportement WiFi. Le code raison WiFi 3 indique simplement que la station a décidé de quitter proactivement le SSID.
3. Il y a eu un processus de roaming (= déplacement d’un point d’accès à un autre) d’un certain client.

Ceci n’est bien sûr qu’un aperçu rapide de ce que les journaux d’événements peuvent vous dire, mais cela montre que les journaux d’événements peuvent être un outil puissant pour comprendre ce qui se passe réellement dans votre réseau. Spécifiquement pour les problèmes WiFi, il existe des outils supplémentaires pour évaluer la qualité WiFi, tels que Wireless Health, les listes de clients, etc. Les articles suivants peuvent également vous donner plus d’informations sur ce sujet :

Nebula AP « Easy Troubleshoot »

Solution Wireless Health par Zyxel Networks