Viktig merknad: |
Denne artikkelen vil feilsøke de vanligste problemene - hvis enheten forblir frakoblet, ikke kan se noen data / logger (PoE, CPU-bruk, databruk, logger osv.), konfigurasjoner blir ikke pushet (fastvareadministrasjon), ved hjelp av hendelsesloggene.
Vi er veldig glade for å se at Nebula Cloud-løsningen vår tar fart ute i felten, og at den blir mer og mer sentral når det gjelder å utvide porteføljen vår. Det som begynte som en "spin-off"-løsning, har i tråd med våre investeringer og prognoser blitt en hjørnestein i vår virksomhet og våre produkter. Dette skiftet i fokus har imidlertid ført til at Nebula-kompatibelt utstyr brukes mer og mer i profesjonelle nettverksmiljøer. Dette skiftet får mange av kundene våre til å stille seg spørsmålet: "Hva kan jeg gjøre for å analysere problemene mine før jeg kontakter noen andre?"
Denne veiledningen gir deg noen ideer og innspill til hva du kan sjekke hvis enhetene dine ikke fungerer som de skal - noen av dem er av mer generell karakter (= eksempler på beste praksis), mens andre er mer spesifikke for ulike teknologiområder.
Som en forutsetning har vi allerede en guide om hvordan du får tilgang til Nebula-kompatible brannmurer via SSH, som sammen med CLI-referanseguider fra kan gi deg et innblikk i ulike muligheter for hva du bør sjekke når du kobler deg til de respektive Nebula-enhetene via SSH:
Få tilgang til Nebula-brannmuren via SSH og foreta en Packet Capture / Packet Trace fra Internett.
Merk: Nebula-administrerte enheter er ikke ment å konfigureres via konsolltilkobling - bruk kun SSH-tilgang til Nebula-enheter for overvåking og eventuelt, i samarbeid med vår support- og FoU-avdeling, feilsøkingsmålinger.
Enhetene forblir frakoblet
Forestill deg dette - du har registrert enheten din, kanskje til og med konfigurert noen innstillinger etter eget ønske, og du er nå i driftsfasen for enheten. Men av grunner du ennå ikke kjenner til, vil den aktuelle enheten rett og slett ikke være online, verken på stedet, i drift eller når den viser seg å være online og responsiv.
Dette er et av de vanligste problemene ved distribusjon av Nebula-enheter. Årsaken er kort fortalt at enhetene som standard prøver å løse opp til enten s.nebula.zyxel.com eller d.nebula.zyxel.com. Dette medfører to problemer:
- Et underdomene med flere kaskader (f.eks. this.that.andthis.alsoothis.domain.com) kan føre til problemer for enkelte DNS-leverandører.
- I henhold til nyere standarder kan et underdomene også bestå av ett tegn, mens det tidligere måtte bestå av minst tre tegn. Noen DNS-servere har problemer med dette.
Svært 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.8 eller 1.1.1.1. Du finner mer informasjon her:
Jeg kan ikke se noen data!
Det hender at kunder tar kontakt med oss og klager over at de har logget inn for første gang på lenge, og at dataene enten er borte eller at "ingenting vises". Det kan være at organisasjonen er satt i Cloud-Saving Mode på grunn av lang tids inaktivitet på portalen, noe som i utgangspunktet kutter all innsamling av informasjon etter en inaktivitetsperiode på 30 dager. Cloud-Saving Mode skal indikeres med en melding og et banner (lyseblått banner). Løsningen: Slå av Cloud Saving Mode og vent noen minutter, så skal dataene snart være tilbake.
Du finner mer informasjon her: Skysparingsmodus (Nebula BASE Pack)
Konfigurasjoner blir ikke overført
Du har kanskje problemer med at enheten din faktisk vises på nettet, men at konfigurasjonsendringer ikke virker? Sjekk fastvaren! Noen endringer kan kreve den nyeste fastvaren for å fungere som de skal, og noen ganger blir endringer holdt tilbake på grunn av dette:
Dette er et perfekt eksempel på hva vi ikke ønsker å se - i dette tilfellet er fastvaren til brannmuren utdatert, og dette hindrer at nye konfigurasjonsblokker blir tatt i bruk, mens all annen statistikk (CPU, RAM-bruk, klientnummer, online/offline-status) ser ut til å være i orden. Tilbakeholdelsen av konfigurasjonsblokker gjelder spesielt, men ikke utelukkende, nye funksjoner som er implementert i den nyeste fastvaren. Så det, bortsett fra "DNS-problemet" presentert ovenfor, kan være verdifulle tips.
Overvåking via Nebula - nyttig innsikt til fingerspissene!
Overvåkingsfunksjonene gir reelle fordeler og verktøy til overvåkings- og analyseverktøyene dine. Bare for å begynne med noe enkelt - en enhet vises som frakoblet, men du har en følelse av at den fortsatt kommuniserer med Nebula Cloud Center? Bare gå til enhetens hovedside - for gatewayer vil dette være:
Devices -> Firewall
og gjør en ping-test - hvis ping-testen faktisk klarer å fortelle enheten "Ping destination W.X.Y.Z", og enheten faktisk mottar dette og kan gi tilbakemelding om vellykkede pinger, betyr dette at enheten faktisk fortsatt kommuniserer med NCC, og at frakoblingstilstanden kan være et problem knyttet til nettleserens cache eller informasjonskapsler.
Et annet eksempel fra virkeligheten: Flere switch-porter viser stadig hendelsesloggmeldinger som indikerer at det veksles mellom 10 Mb/s og 1 Gb/s, og du er usikker på om det er switchen som forårsaker problemer?
Sjekk MAC-tabellen via:
Devices > Switches > (select Switch) > Live Tools > Switch Tables > Run-Button
Du vet at du har informasjon som kan hjelpe deg - i det nevnte eksemplet fra virkeligheten viste det seg at alle svitsjportene som viste denne oppførselen hadde en veldig spesifikk MAC-leverandør, noe som igjen peker mot at en spesifikk klienttype hadde dette problemet, og at svitsjen ikke hadde noe problem - en mulig løsning her kan være å sette opp en fast hastighet på nevnte klienter og de respektive svitsjportene.
Det finnes mange andre eksempler på hvordan overvåking kan utrette mirakler for å løse feil, men jeg antar at du skjønner poenget.
Bruk av hendelsesloggene for å få en bedre forståelse av prosessene "under panseret".
Hendelsesloggene, som hvert teknologifelt har sine egne av, kan være til stor hjelp når det gjelder å finne ut hvorfor ting ikke fungerer - spesielt når det gjelder WiFi-relaterte problemer.
La oss ta en titt på et eksempel via et WiFi-nettverk, med tre ulike oppføringer:
La oss analysere de tre ulike punktene etter hverandre:
- Dette forteller oss at en bestemt stasjon, med en bestemt MAC-adresse, har koblet seg til det aktuelle tilgangspunktet. Den har koblet seg til med en signalstyrke på -81dBm, noe som er for svakt (se denne veiledningen for referanse: Forbedre WiFi-roaming på Nebula Access Points? )
- En stasjon har forlatt en spesifikk SSID, AP eller kanal på grunn av en WiFi-årsak 3. WiFi-årsakskoder er enhetlige koder for å identifisere og forstå WiFi-atferd. Se denne artikkelen som referanse: Hva betyr 802.11 Deauthentication Reason Codes?
WiFi Reason Code 3 angir ganske enkelt at stasjonen proaktivt har bestemt seg for å forlate SSID-en. - Det var en roaming-prosess (= flytting fra en AP til en annen) for en bestemt klient.
Dette er selvfølgelig bare et lite glimt av hva hendelseslogger kan fortelle deg, men det viser at hendelseslogger kan være et effektivt verktøy for å forstå hva som faktisk skjer i nettverket ditt. Når det gjelder WiFi-problemer, finnes det flere verktøy for å evaluere WiFi-kvaliteten, for eksempel Wireless Health, Client lists osv. Følgende artikler kan også gi deg mer innsikt i dette emnet: