Nebula Probleemoplossing - Veelvoorkomende problemen

Dit artikel behandelt de meest voorkomende problemen - als het apparaat offline blijft, geen gegevens/logs zichtbaar zijn (PoE, CPU-gebruik, datagebruik, logs, enz.), configuraties niet worden doorgevoerd (firmwarebeheer), met gebruik van de gebeurtenislogs.

We zijn erg blij om te zien dat onze Nebula Cloud-oplossing terrein wint in de praktijk en steeds meer een belangrijke focus wordt bij het uitbreiden van ons portfolio. Wat begon als een "spin-off"-oplossing is, in lijn met onze investeringen en voorspellingen, een hoeksteen van onze operaties en producten geworden. Met deze verschuiving in focus wordt Nebula-geschikte apparatuur steeds meer gebruikt in professionele netwerkomgevingen. Deze verschuiving roept bij veel van onze klanten de vraag op: "Wat kan ik zelf doen om mijn problemen te analyseren, voordat ik contact opneem met iemand anders?"

Deze gids geeft enkele ideeën en suggesties om te controleren als uw apparaten niet correct functioneren - sommige zijn meer algemeen van aard (= best practice voorbeelden), andere zijn wat specifieker voor verschillende technologiegebieden.

Opmerking: Nebula-beheerste apparaten zijn niet bedoeld om op enigerlei wijze via een consoleverbinding geconfigureerd te worden - gebruik SSH-toegang tot Nebula apparaten alleen voor monitoring en eventueel, in samenwerking met onze support-/R&D-afdeling, voor debugmetingen.

Apparaten blijven offline

Stel je voor - je hebt je apparaat succesvol geregistreerd, misschien zelfs enkele instellingen naar wens geconfigureerd en je bevindt je nu in de uitrolfase van je apparaat. Om redenen die je nog niet kent, wil het betreffende apparaat echter gewoon niet online komen, zowel ter plaatse, in werking, als volledig online en responsief getoond worden.

Dit is een van de meest voorkomende problemen bij het uitrollen van Nebula apparaten - de reden hiervoor is kort gezegd dat de apparaten standaard proberen te verbinden met s.nebula.zyxel.com of d.nebula.zyxel.com. Dit brengt twee problemen met zich mee:

1. Meermalen geneste subdomeinen (bijv. dit.dat.endit.ookdit.domein.com) kunnen problemen veroorzaken bij sommige DNS-providers
2. Volgens nieuwere standaarden kan een subdomein ook uit één teken bestaan, terwijl dat voorheen minimaal drie tekens moest zijn. Sommige DNS-servers hebben hier problemen mee.

Vaak zien we dat DNS-servers van internetproviders hier problemen mee hebben. Onze aanbeveling: wijzig de standaard DNS-server naar 8.8.8.8 of 1.1.1.1. Meer informatie is hier te vinden:

Wat moet ik doen als mijn Nebula apparaat niet online kan komen / verbindingsproblemen heeft / niet communiceert met NCC?

Ik zie geen gegevens!

Soms nemen klanten contact met ons op, klagend dat ze voor het eerst na lange tijd zijn ingelogd en hun gegevens verdwenen zijn of "er niets wordt weergegeven". Het kan zijn dat door langere inactiviteit op het portaal de organisatie is ingesteld op de Cloud-Saving Modus, die in principe alle informatieverzameling stopzet na een inactieve periode van 30 dagen. De Cloud-Saving Modus wordt aangegeven met een melding en een banner (lichtblauwe banner). De oplossing: schakel de Cloud-Saving Modus uit en wacht een paar minuten, de gegevens zouden dan snel weer zichtbaar moeten zijn.

Meer informatie is hier te vinden: Cloud-Saving Modus (Nebula BASE Pack)

Configuraties worden niet doorgevoerd

Je kunt het probleem hebben dat je apparaat wel online wordt weergegeven, maar dat het wijzigen van de configuratie niet lijkt te werken? Controleer de firmware! Sommige wijzigingen vereisen de nieuwste firmware om correct te functioneren, en soms worden wijzigingen daardoor tegengehouden:

Dit is een perfect voorbeeld van wat we niet willen zien - in dit geval is de firewall-firmware verouderd, wat uiteindelijk nieuwe configuratieblokken tegenhoudt terwijl alle andere statistieken (CPU, RAM-gebruik, aantal clients, online/offline status) prima lijken. Het tegenhouden van configuratieblokken geldt vooral, maar niet uitsluitend, voor nieuwe functies die in de recentste firmware zijn geïmplementeerd. Dus dit, naast het hierboven genoemde "DNS-probleem", kan waardevolle tips opleveren.

Monitoring via Nebula - Handige inzichten binnen handbereik!

De monitoringfuncties bieden echte voordelen en tools voor je monitoring- en analysemiddelen. Om met iets eenvoudigs te beginnen - een apparaat wordt als offline weergegeven, maar je hebt het gevoel dat het nog steeds goed communiceert met het Nebula Cloud Center? Ga dan naar de hoofdpagina van het apparaat - voor gateways is dat:

Devices -> Firewall

en voer een Ping-test uit - als de ping-test het apparaat succesvol kan bereiken met "Ping destination W.X.Y.Z" en het apparaat dit ontvangt en een succesvolle ping teruggeeft, betekent dit dat het apparaat nog steeds communiceert met het NCC en dat de offline status mogelijk een browsercache- of cookie-gerelateerd probleem is.

Een ander praktijkvoorbeeld: meerdere switch-poorten tonen constant gebeurtenislogberichten die een wisseling aangeven tussen 10Mb/s en 1Gb/s verbindingen, en je weet niet zeker of de switch problemen veroorzaakt?

Controleer de MAC-tabel via:

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

Je hebt nu informatie die je kan helpen - in genoemd praktijkvoorbeeld bleek dat alle switch-poorten die dit gedrag vertoonden een zeer specifieke MAC-leverancier hadden, wat wijst op een specifiek type client met dit probleem, wat betekent dat de switch zelf geen probleem had - een mogelijke oplossing zou kunnen zijn om een vaste snelheid in te stellen op genoemde clients en de betreffende switch-poorten.

Er zijn veel andere voorbeelden van hoe monitoring wonderen kan verrichten bij het oplossen van fouten, maar ik denk dat je het punt begrijpt.

Gebruik van de gebeurtenislogs voor beter begrip van processen "onder de motorkap"

De gebeurtenislogs, waarvan elk technologiegebied zijn eigen heeft, bieden enorme hulp bij het informeren over redenen waarom dingen niet werken - vooral bij WiFi-gerelateerde problemen.
Laten we een voorbeeld bekijken via een WiFi-netwerk, met drie verschillende vermeldingen:

Laten we de 3 verschillende punten een voor een analyseren:

1. Dit vertelt ons dat een bepaald station, met een bepaald MAC-adres, verbinding heeft gemaakt met het betreffende Access Point. Het heeft verbinding gemaakt met een signaalsterkte van -81dBm, wat uiteindelijk te zwak is.
2. Een station heeft een specifieke SSID, AP, kanaal verlaten vanwege WiFi reden 3. WiFi reden codes zijn uniforme codes om WiFi-gedrag te identificeren en te begrijpen. WiFi reden code 3 geeft simpelweg aan dat het station proactief heeft besloten de SSID te verlaten.
3. Er was een roamingproces (= verplaatsen van het ene AP naar het andere) van een bepaalde client.

Dit is natuurlijk slechts een korte blik op wat gebeurtenislogs kunnen vertellen, maar het laat zien dat gebeurtenislogs een krachtig hulpmiddel kunnen zijn om te begrijpen wat er daadwerkelijk met je netwerk gebeurt. Specifiek met betrekking tot WiFi-problemen zijn er aanvullende tools om de WiFi-kwaliteit te evalueren, zoals Wireless Health, clientlijsten, enz. De volgende artikelen kunnen je ook meer inzicht geven in dit onderwerp:

Nebula AP "Easy Troubleshoot"

Wireless Health-oplossing van Zyxel Networks