Nebula Fejlfinding - Almindelige Problemer

Denne artikel vil fejlsøge de mest almindelige problemer - hvis enheden forbliver offline, ikke kan se nogen data/logfiler (PoE, CPU-forbrug, dataforbrug, logfiler osv.), konfigurationer ikke bliver skubbet ud (firmware-administration), ved brug af hændelseslogfiler.

Vi er meget glade for at se vores Nebula Cloud-løsning vinde frem i marken og samtidig blive et mere og mere centralt fokus i forbindelse med udvidelsen af vores portefølje. Det, som begyndte som en "spin-off"-løsning, er i overensstemmelse med vores investeringer og forudsigelser blevet en hjørnesten i vores drift og produkter. Med dette skift i fokus bliver Nebula-kompatibelt udstyr i stigende grad anvendt i professionelle netværksmiljøer. Dette skift rejser for mange af vores kunder spørgsmålet: "Hvad kan jeg gøre for at analysere mine problemer, inden jeg kontakter andre?"

Denne guide vil give nogle idéer og input til ting, man kan tjekke, hvis dine enheder ikke fungerer korrekt - nogle af dem er mere generelle (= bedste praksis-eksempler), mens andre er mere specifikke for forskellige teknologifelter.

Bemærk: Nebula-administrerede enheder er ikke beregnet til at blive konfigureret på nogen måde via konsolforbindelse - brug venligst kun SSH-adgang til Nebula-enheder til overvågning og eventuelt, i samarbejde med vores support-/R&D-afdeling, til fejlfinding og målinger.

Enheder forbliver offline

Forestil dig dette - du har registreret din enhed med succes, måske endda konfigureret nogle indstillinger efter ønske, og du er nu i udrulningsfasen af din enhed. Men af ukendte årsager vil den pågældende enhed simpelthen ikke komme online, hverken på stedet, i drift, eller vise sig som online og responsiv.

Dette er et af de mest almindelige problemer ved udrulning af Nebula-enheder - årsagen til dette er kort fortalt, at enhederne som standard forsøger at løse enten s.nebula.zyxel.com eller d.nebula.zyxel.com. Dette medfører to problemer:

1. Et flere gange kaskaderet subdomæne (f.eks. this.that.andthis.alsothis.domain.com) kan give problemer for nogle DNS-udbydere
2. Ifølge nyere standarder kan et subdomæne også bestå af et enkelt tegn, hvor det tidligere skulle være mindst tre tegn. Nogle DNS-servere har problemer med dette.

Meget ofte ser vi, at internetudbyderes DNS-servere har problemer med dette. Vores anbefaling: skift standard DNS-server til enten 8.8.8.8 eller 1.1.1.1. Mere information kan findes her:

Hvad skal jeg gøre, hvis min Nebula-enhed ikke kan komme online / har forbindelsesproblemer / ikke kommunikerer med NCC?

Jeg kan ikke se nogen data!

Nogle gange kontakter kunder os og klager over, at de har logget ind for første gang i lang tid, og deres data enten er væk eller "intet vises". Det kan skyldes, at organisationen på grund af længere inaktivitet på portalen er sat i Cloud-Saving Mode, som grundlæggende stopper al indsamling af information efter en inaktiv periode på 30 dage. Cloud-Saving Mode bør være angivet med en prompt og et banner (lyseblåt banner). Løsningen: slå Cloud Saving Mode fra og vent et par minutter, så skulle data snart være tilbage.

Mere information kan ses her: Cloud-Saving Mode (Nebula BASE Pack)

Konfigurationer bliver ikke skubbet ud

Du kan have problemet, at din enhed faktisk viser sig som online, men ændringer i konfigurationen ser ikke ud til at blive anvendt? Tjek firmwaren! Nogle ændringer kræver muligvis den nyeste firmware for at fungere korrekt, og nogle gange bliver ændringer holdt tilbage på grund af det:

Dette er et perfekt eksempel på, hvad vi ikke ønsker at se - i dette tilfælde er firewall-firmwaren forældet, og dette holder til sidst nye konfigurationsblokke tilbage, mens alle andre statistikker (CPU, RAM-forbrug, antal klienter, online/offline status) ser fine ud. Tilbageholdelsen af konfigurationsblokke gælder især, men ikke udelukkende, nye funktioner implementeret i den nyeste firmware. Så det, udover det "DNS-problem" præsenteret ovenfor, kan være værdifulde tips.

Overvågning via Nebula - nyttige indsigter lige ved hånden!

Overvågningsfunktionerne giver reelle fordele og værktøjer til dine overvågnings- og analyseaktiver. For at begynde med noget enkelt - en enhed viser sig som offline, men du har en fornemmelse af, at den stadig kommunikerer korrekt med Nebula Cloud Center? Gå bare til enhedens hovedside - for gateways vil det være:

Devices -> Firewall

og lav en Ping-Test - hvis pingtesten faktisk lykkes med at fortælle enheden "Ping destination W.X.Y.Z", og enheden rent faktisk modtager dette og kan give feedback om succesfulde pings, betyder det, at enheden faktisk stadig kommunikerer med NCC, og offline-tilstanden kan være et browser-cache- eller cookie-relateret problem.

Et andet eksempel fra virkeligheden: flere switch-porte viser konstant hændelseslogbeskeder, der indikerer en skiften mellem 10Mb/s-forbindelser og 1Gb/s-forbindelser, og du er usikker på, om switchen forårsager problemer?

Tjek MAC-tabellen via:

Devices > Switches > (vælg Switch) > Live Tools > Switch Tables > Kør-knap

Du har nu information, som kan hjælpe dig - i nævnte eksempel fra virkeligheden viste det sig, at alle switch-porte med denne adfærd havde en meget specifik MAC-leverandør, hvilket peger på en bestemt klienttype, der har dette problem, og dermed havde switchen ikke noget problem - en mulig løsning her kunne være at indstille en fast hastighed på de pågældende klienter og de respektive switch-porte.

Der findes mange andre eksempler på, hvordan overvågning kan udføre mirakler for at løse fejl, men jeg tror, du forstår pointen her.

Brug af hændelseslogfiler til bedre forståelse af processer "under motorhjelmen"

Hændelseslogfilerne, som hvert teknologifelt har sine egne af, giver dig en enorm hjælp til at informere om årsager til, at ting ikke fungerer - især ved WiFi-relaterede problemer.
Lad os se på et eksempel via et WiFi-netværk, der viser tre forskellige indlæg:

Lad os analysere de 3 forskellige punkter én efter én:

1. Dette fortæller os, at en bestemt station med en bestemt MAC-adresse har oprettet forbindelse til den respektive Access Point. Den har oprettet forbindelse med en signalstyrke på -81dBm, hvilket i sidste ende er for svagt.
2. En station har forladt et specifikt SSID, AP, kanal på grund af WiFi årsag 3. WiFi årsagskoder er ensartede koder til at identificere og forstå WiFi-adfærd. WiFi årsagskode 3 angiver ganske enkelt, at stationen proaktivt har besluttet at forlade SSID.
3. Der var en roamingproces (= flytning fra en AP til en anden) af en bestemt klient.

Dette er naturligvis kun et glimt af, hvad hændelseslogfiler kan fortælle dig, men det viser, at hændelseslogfiler kan være et kraftfuldt værktøj til at forstå, hvad der faktisk sker i dit netværk. Specifikt med hensyn til WiFi-problemer findes der yderligere værktøjer til at evaluere WiFi-kvaliteten, såsom Wireless Health, klientlister osv. Følgende artikler kan også give dig mere indsigt i dette emne:

Nebula AP "Easy Troubleshoot"

Wireless Health-løsning fra Zyxel Networks