Nebula Feilsøking - Vanlige problemer

Denne artikkelen vil feilsøke de mest vanlige problemene - hvis enheten forblir offline, kan ikke se noen data/logger (PoE, CPU-bruk, databruk, logger osv.), konfigurasjoner blir ikke sendt (firmware-administrasjon), ved bruk av hendelseslogger.

Vi er svært glade for å se at vår Nebula Cloud-løsning får økt fart ute i feltet, samt blir mer og mer et nøkkelfokus når det gjelder å utvide vår portefølje. Det som startet som en "spin-off"-løsning har, i samsvar med våre investeringer og spådommer, blitt en hjørnestein i våre operasjoner og produkter. Med dette skiftet i fokus brukes Nebula-kompatibelt utstyr i økende grad i profesjonelle nettverksmiljøer. Dette skiftet reiser spørsmålet for mange av våre kunder: "Hva kan jeg gjøre for å analysere mine problemer før jeg kontakter noen andre?"

Denne guiden vil gi noen ideer og innspill om ting å sjekke hvis enhetene dine ikke fungerer som de skal - noen av dem er mer generelle (= beste praksis-eksempler), mens noen er litt mer spesifikke for ulike teknologifelt.

Merk: Nebula-administrerte enheter er ikke ment å konfigureres på noen måte via konsolltilkobling - vennligst bruk kun SSH-tilgang til Nebula-enheter for overvåking og eventuelt, i samarbeid med vår support-/F&U-avdeling, feilsøkingsmålinger.

Enheter forblir offline

Tenk deg dette - du har registrert enheten din med suksess, kanskje til og med konfigurert noen innstillinger etter eget ønske, og du er nå i utrullingsfasen av enheten. Men av grunner du ennå ikke kjenner til, vil enheten rett og slett ikke komme online verken på stedet, i drift, eller vise seg som online og responsiv.

Dette er et av de vanligste problemene ved utrulling av Nebula-enheter - årsaken til dette, kort fortalt, er at enhetene som standard prøver å løse til enten s.nebula.zyxel.com eller d.nebula.zyxel.com. Dette medfører to problemer:

1. En flere ganger kaskadert underdomene (f.eks. this.that.andthis.alsothis.domain.com) kan føre til problemer for noen DNS-leverandører
2. I henhold til nyere standarder kan et underdomene også bestå av et enkelt tegn, mens det tidligere måtte være minst tre tegn. Noen DNS-servere har problemer med dette.

Ofte ser vi at DNS-servere hos internettleverandører har problemer med dette. Vår anbefaling: endre standard DNS-server til enten 8.8.8.8 eller 1.1.1.1. Mer informasjon finnes her:

Hva bør jeg gjøre hvis min Nebula-enhet ikke får kontakt / har tilkoblingsproblemer / ikke kommuniserer med NCC?

Jeg kan ikke se noen data!

Noen ganger kontakter kunder oss og klager over at de har logget inn for første gang på lenge, og dataene deres enten er borte eller "ingenting vises". Det kan være at på grunn av lengre inaktivitet på portalen, er organisasjonen satt til Cloud-Saving Mode, som i praksis stopper all innsamling av informasjon etter en inaktiv periode på 30 dager. Cloud-Saving Mode skal indikere dette med en melding og et banner (lyseblått banner). Løsningen: slå av Cloud Saving Mode og vent noen minutter, dataene bør da komme tilbake snart.

Mer informasjon kan sees her: Cloud-Saving Mode (Nebula BASE Pack)

Konfigurasjoner blir ikke sendt

Du kan ha problemet at enheten din faktisk viser at den er online, men endringer i konfigurasjonen ser ut til ikke å bli anvendt? Sjekk firmware! Noen endringer kan kreve den nyeste firmwaren for å fungere riktig, og noen ganger holdes endringer tilbake på grunn av dette:

Dette er et perfekt eksempel på hva vi ikke ønsker å se - i dette tilfellet er brannmurens firmware utdatert, og dette holder tilbake at nye konfigurasjonsblokker blir brukt, mens alle andre statuser (CPU, RAM-bruk, antall klienter, online/offline-status) ser fine ut. Tilbakeholdelsen av konfigurasjonsbiter gjelder spesielt, men ikke utelukkende, nye funksjoner implementert i den nyeste firmwaren. Så dette, i tillegg til "DNS-problemet" beskrevet ovenfor, kan være verdifulle tips.

Overvåking via Nebula - Nyttige innsikter rett ved fingertuppene!

Overvåkingsfunksjonene gir reelle fordeler og verktøy til dine overvåkings- og analyseressurser. For å begynne med noe enkelt - en enhet viser offline, men du føler at den fortsatt kommuniserer med Nebula Cloud Center korrekt? Gå bare til enhetens hovedside - for gateways vil dette være:

Devices -> Firewall

og utfør en Ping-Test - hvis ping-testen faktisk klarer å sende meldingen "Ping destination W.X.Y.Z" og enheten mottar dette og kan gi tilbakemelding om vellykkede pings, betyr dette at enheten faktisk fortsatt kommuniserer med NCC og offline-tilstanden kan være et problem med nettleserens cache eller cookies.

Et annet ekte eksempel: flere switch-porter viser konstant hendelseslogg-meldinger som indikerer veksling mellom 10Mb/s-tilkoblinger og 1Gb/s-tilkoblinger, og du er usikker på om switchen forårsaker problemer?

Sjekk MAC-tabellen via:

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

Du har nå informasjon som kan hjelpe deg - i nevnte eksempel viste det seg at alle switchporter som viste denne oppførselen hadde en veldig spesifikk MAC-leverandør, noe som igjen peker mot en spesifikk klienttype som har dette problemet, og det betyr at switchen ikke hadde feil - en mulig løsning her kunne være å sette fast hastighet på nevnte klienter og de respektive switch-portene.

Det finnes mange andre eksempler på hvordan overvåkingen kan gjøre underverker for å løse feil, men jeg tror du forstår poenget her.

Bruk av hendelseslogger for å få bedre forståelse av prosesser "under panseret"

Hendelsesloggene, som hvert teknologifelt har sine egne av, gir deg enorm hjelp til å informere om årsaker til at ting ikke fungerer - spesielt ved WiFi-relaterte problemer.
La oss se på ett eksempel via et WiFi-nettverk, som viser tre forskjellige oppføringer:

La oss analysere de 3 forskjellige punktene etter hverandre:

1. Dette forteller oss at en bestemt stasjon, med en bestemt MAC-adresse, har koblet seg til den respektive tilgangspunktet. Den har koblet til med et signalstyrke på -81dBm, som til slutt er for svakt.
2. En stasjon har forlatt et spesifikt SSID, AP, kanal på grunn av WiFi årsak 3. WiFi årsakskoder er standardiserte koder for å identifisere og forstå WiFi-adferd. WiFi årsakskode 3 angir enkelt at stasjonen proaktivt har bestemt seg for å forlate SSID.
3. Det var en roaming-prosess (= bevegelse fra ett AP til et annet) av en bestemt klient.

Nå er dette selvfølgelig bare et glimt av hva hendelseslogger kan fortelle deg, men det viser at hendelseslogger kan være et kraftig verktøy for å forstå hva som faktisk skjer i nettverket ditt. Spesielt med tanke på WiFi-problemer finnes det tillegg verktøy for å evaluere WiFi-kvaliteten, som Wireless Health, klientlister osv. Følgende artikler kan gi deg mer innsikt i dette emnet også:

Nebula AP "Easy Troubleshoot"

Wireless Health-løsning fra Zyxel Networks