Nebula [Fehlerbehebung] - Allgemeine Probleme

Wichtiger Hinweis:
Sehr geehrte Kundin, sehr geehrter Kunde, bitte beachten Sie, dass wir maschinelle Übersetzung verwenden, um Artikel in Ihrer Landessprache bereitzustellen. Es kann sein, dass nicht alle Texte korrekt übersetzt werden. Wenn es Fragen oder Unstimmigkeiten bezüglich der Genauigkeit der Informationen in der übersetzten Version gibt, lesen Sie bitte den Originalartikel hier:Originalversion

In diesem Artikel geht es um die Behebung der häufigsten Probleme - wenn das Gerät offline bleibt, keine Daten/Protokolle angezeigt werden (PoE, CPU-Nutzung, Datennutzung, Protokolle usw.), Konfigurationen nicht übertragen werden (Firmware-Verwaltung) und die Ereignisprotokolle verwendet werden.

Wir freuen uns sehr darüber, dass unsere Nebula-Cloud-Lösung in der Praxis immer mehr an Bedeutung gewinnt und auch bei der Erweiterung unseres Portfolios immer mehr in den Mittelpunkt rückt. Was als "Spin-Off"-Lösung begann, hat sich in Übereinstimmung mit unseren Investitionen und Prognosen zu einem Eckpfeiler unseres Betriebs und unserer Produkte entwickelt. Mit dieser Verlagerung des Schwerpunkts werden Nebula-fähige Geräte jedoch immer häufiger in professionellen Netzwerkumgebungen eingesetzt. Diese Verschiebung bringt für viele unserer Kunden die Frage mit sich: "Was kann ich tun, um meine Probleme zu analysieren, bevor ich mich an jemand anderen wende?"

Dieser Leitfaden enthält einige Ideen und Anregungen, was zu prüfen ist, wenn Ihre Geräte nicht ordnungsgemäß funktionieren - einige davon sind eher allgemeiner Natur (= Best-Practice-Beispiele), einige sind etwas spezifischer für verschiedene Technologiebereiche.

Als Voraussetzung haben wir bereits einen Leitfaden für den Zugriff auf Nebula-fähige Firewalls via SSH, der Ihnen in Verbindung mit den CLI-Referenzleitfäden aus dem vielleicht schon einen kleinen Einblick in verschiedene Möglichkeiten gibt, worauf Sie achten sollten, wenn Sie sich via SSH mit den jeweiligen Nebula-Geräten verbinden:

Zugriff auf Ihre Nebula Firewall via SSH und Durchführung eines Packet Capture / Packet Trace aus dem Internet

Hinweis: Nebula-verwaltete Geräte sind nicht dazu gedacht, in irgendeiner Form über eine Konsolenverbindung konfiguriert zu werden - bitte nutzen Sie den SSH-Zugriff auf Nebula-Geräte nur zur Überwachung und eventuell, in Zusammenarbeit mit unserer Support-/F&E-Abteilung, für Debugging-Messungen.

Die Geräte bleiben offline

Stellen Sie sich vor, Sie haben Ihr Gerät erfolgreich registriert, vielleicht sogar einige Einstellungen nach Ihren Wünschen konfiguriert und befinden sich nun in der Bereitstellungsphase Ihres Geräts. Doch aus Gründen, die Sie noch nicht kennen, will das betreffende Gerät einfach nicht online gehen, weder vor Ort, noch in Betrieb, noch vollständig online und reaktionsfähig.

Dies ist eines der häufigsten Probleme bei der Bereitstellung von Nebula-Geräten - der Grund dafür ist, kurz gesagt, dass die Geräte standardmäßig versuchen, sich entweder auf s.nebula.zyxel.com oder d.nebula.zyxel.com aufzulösen. Dies bringt zwei Probleme mit sich:

  1. Eine mehrfach kaskadierte Subdomain (z.B. this.that.andthis.alsothis.domain.com) kann bei einigen DNS-Providern zu Problemen führen
  2. Nach neueren Standards kann eine Subdomain auch aus einem einzigen Zeichen bestehen, während es früher mindestens drei Zeichen waren. Bei einigen DNS-Servern gibt es damit Probleme.

Sehr oft sehen wir, dass die DNS-Server von Internetanbietern damit Probleme haben. Unsere Empfehlung: Ändern Sie den Standard-DNS-Server entweder auf 8.8.8.8 oder 1.1.1.1. Weitere Informationen finden Sie hier:

Was sollte ich tun, wenn mein Nebula-Gerät nicht online gehen kann / Verbindungsprobleme hat / nicht mit dem NCC kommuniziert?

Ich kann keine Daten sehen!

Manchmal melden sich Kunden bei uns und beschweren sich, dass sie sich seit längerer Zeit zum ersten Mal wieder eingeloggt haben und ihre Daten entweder weg sind oder "nichts angezeigt wird". Es könnte sein, dass die Organisation aufgrund längerer Inaktivität auf dem Portal in den Cloud-Spar-Modus geschaltet ist, der grundsätzlich alle Datenerhebungen nach einer Inaktivitätszeit von 30 Tagen abbricht. Der Cloud-Spar-Modus sollte durch eine Eingabeaufforderung und durch ein Banner (hellblau) angezeigt werden. Die Lösung: Schalten Sie den Cloud-Spar-Modus aus und warten Sie ein paar Minuten, dann sollten die Daten bald wieder verfügbar sein.

mceclip0.png

Weitere Informationen finden Sie hier: Cloud-Spar-Modus (Nebula BASE Pack)

Konfigurationen werden nicht gepusht

Sie haben vielleicht das Problem, dass Ihr Gerät zwar online ist, aber die Änderung der Konfiguration nicht funktioniert? Prüfen Sie die Firmware! Einige Änderungen erfordern die neueste Firmware, um richtig zu funktionieren, und manchmal werden Änderungen deshalb zurückgehalten:

mceclip1.png

Dies ist ein perfektes Beispiel für das, was wir nicht sehen wollen - in diesem Fall ist die Firewall-Firmware veraltet, was die Anwendung neuer Konfigurationsblöcke verhindert, während alle anderen Statistiken (CPU, RAM-Nutzung, Client-Nummer, Online-/Offline-Status) in Ordnung zu sein scheinen. Das Zurückhalten von Konfigurationsblöcken gilt insbesondere, aber nicht ausschließlich, für neue Funktionen, die in der neuesten Firmware implementiert sind. Abgesehen von dem oben geschilderten "DNS-Problem" könnten dies also wertvolle Hinweise sein.

Monitoring via Nebula - Nützliche Einblicke auf Knopfdruck!

Die Überwachungsfunktionen bieten echte Vorteile und Werkzeuge für Ihre Überwachungs- und Analysefunktionen. Um mit etwas Einfachem zu beginnen - ein Gerät wird als offline angezeigt, aber Sie haben das Gefühl, dass es immer noch ordnungsgemäß mit dem Nebula Cloud Center kommuniziert? Gehen Sie einfach auf die Hauptseite des Geräts - bei Gateways wäre dies:

Devices -> Firewall

und führen Sie einen Ping-Test durch - wenn der Ping-Test es tatsächlich schafft, dem Gerät erfolgreich mitzuteilen "Ping destination W.X.Y.Z" und das Gerät dies tatsächlich empfängt und eine Rückmeldung über erfolgreiche Pings geben kann, bedeutet dies, dass das Gerät tatsächlich noch mit dem NCC kommuniziert und der Offline-Zustand ein Problem mit dem Browser-Cache oder den Cookies sein könnte.

Ein weiteres Beispiel aus der Praxis: Mehrere Switch-Ports zeigen ständig Ereignisprotokollmeldungen an, die ein Umschalten zwischen 10Mb/s-Verbindungen und 1Gb/s-Verbindungen anzeigen, und Sie sind sich nicht sicher, ob der Switch Probleme verursacht?

mceclip2.png

Prüfen Sie die MAC-Tabelle über:

Devices > Switches > (select Switch) > Live Tools > Switch Tables > Run-Button

mceclip3.png

Sie wissen, dass Sie Informationen haben, die Ihnen helfen könnten - in besagtem realen Beispiel stellte sich heraus, dass alle Switch-Ports, die dieses Verhalten zeigten, einen ganz bestimmten MAC-Anbieter hatten, was wiederum eher darauf hindeutet, dass ein bestimmter Client-Typ dieses Problem hat, und das bedeutet, dass der Switch kein Problem hatte - eine mögliche Lösung könnte hier die Einrichtung einer festen Geschwindigkeit auf den besagten Clients und den entsprechenden Switch-Ports sein.

Es gibt noch viele andere Beispiele dafür, wie die Überwachung bei der Fehlerbehebung Wunder bewirken kann, aber ich denke, Sie verstehen, worauf ich hinaus will.

Verwendung der Ereignisprotokolle, um ein besseres Verständnis der Prozesse "unter der Haube" zu erhalten

Die Ereignisprotokolle, von denen jeder Technologiebereich seine eigenen hat, bieten Ihnen eine enorme Hilfe, wenn es darum geht, die Gründe zu ermitteln, warum etwas nicht funktioniert - insbesondere bei WiFi-Problemen.
Werfen wir einen Blick auf ein Beispiel über ein WiFi-Netzwerk, das drei verschiedene Einträge zeigt:

mceclip4.png

Lassen Sie uns die 3 verschiedenen Punkte nacheinander analysieren:

  1. Dies sagt uns, dass eine bestimmte Station, mit einer bestimmten MAC-Adresse, sich mit dem entsprechenden Access Point verbunden hat. Sie hat sich mit einer Signalstärke von -81dBm verbunden, was letztendlich zu schwach ist (als Referenz siehe dieses Tutorial: Verbesserung des WiFi-Roamings auf meinen Nebula Access Points? )
  2. Eine Station hat eine bestimmte SSID, einen AP, einen Kanal aufgrund eines WiFi-Grundes verlassen 3. WiFi Reason Codes sind einheitliche Codes zur Identifizierung und zum Verständnis des WiFi-Verhaltens. Als Referenz lesen Sie bitte diesen Artikel: Was ist die Bedeutung von 802.11 Deauthentication Reason Codes?
    WiFi Reason Code 3 besagt einfach, dass die Station proaktiv beschlossen hat, die SSID zu verlassen.
  3. Es gab einen Roaming-Prozess (= Umzug von einem AP zu einem anderen) eines bestimmten Clients.

Dies ist natürlich nur ein kleiner Einblick in das, was Ereignisprotokolle aussagen können, aber es zeigt, dass Ereignisprotokolle ein mächtiges Werkzeug sein können, um zu verstehen, was tatsächlich in Ihrem Netzwerk passiert. Speziell im Hinblick auf WiFi-Probleme gibt es zusätzliche Tools zur Bewertung der WiFi-Qualität, wie z. B. Wireless Health, Client-Listen usw. Die folgenden Artikel können Ihnen auch zu diesem Thema weitere Einblicke geben:

Nebula AP "Einfache Fehlerbehebung"

Wireless Health-Lösung von Zyxel Networks

Beiträge in diesem Abschnitt

War dieser Beitrag hilfreich?
0 von 6 fanden dies hilfreich
Teilen