Nebula Felsökning - Vanliga problem

Den här artikeln kommer att felsöka de vanligaste problemen - om enheten förblir offline, inte kan visa några data/loggar (PoE, CPU-användning, dataanvändning, loggar etc.), konfigurationer inte pushas (firmware-hantering), med hjälp av händelselogg.

Vi är mycket glada över att se att vår Nebula Cloud-lösning får allt större genomslag ute i fält samt blir mer och mer ett nyckelfokus när det gäller att utöka vår portfölj. Det som började som en "spin-off"-lösning har, i linje med våra investeringar och förutsägelser, blivit en hörnsten i vår verksamhet och våra produkter. Men med detta fokusbyte används Nebula-kompatibel utrustning allt mer i professionella nätverksmiljöer. Denna förändring väcker frågan för många av våra kunder: "Vad kan jag göra för att analysera mina problem innan jag kontaktar någon annan?"

Denna guide kommer att ge några idéer och tips på saker att kontrollera om dina enheter inte fungerar som de ska - några är mer av generell karaktär (= bästa praxis-exempel), andra är lite mer specifika för olika tekniska områden.

Observera: Nebula-hanterade enheter är inte avsedda att konfigureras på något sätt via konsolanslutning - använd endast SSH-åtkomst till Nebula-enheter för övervakning och eventuellt, i samarbete med vår support-/R&D-avdelning, felsökningsmätningar.

Enheter förblir offline

Föreställ dig detta - du har registrerat din enhet framgångsrikt, kanske till och med konfigurerat några inställningar efter eget tycke och du är nu i driftsättningsfasen för din enhet. Men av ännu okända skäl vill den aktuella enheten helt enkelt inte komma online, varken på plats, fungera eller visa sig vara online och responsiv.

Detta är ett av de vanligaste problemen vid driftsättning av Nebula-enheter - orsaken till detta, kortfattat, är att enheterna som standard försöker lösa till antingen s.nebula.zyxel.com eller d.nebula.zyxel.com. Detta medför två problem:

1. En flertalet gånger kaskadiserad subdomän (t.ex. this.that.andthis.alsothis.domain.com) kan orsaka problem för vissa DNS-leverantörer
2. Enligt nyare standarder kan en subdomän också bestå av ett enda tecken, medan det tidigare var minst tre tecken. Vissa DNS-servrar har problem med detta.

Mycket ofta ser vi att internetleverantörers DNS-servrar har problem med detta. Vår rekommendation: ändra standard DNS-server till antingen 8.8.8.8 eller 1.1.1.1. Mer information finns här:

Vad ska jag göra om min Nebula-enhet inte kan komma online / har anslutningsproblem / inte kommunicerar med NCC?

Jag kan inte se några data!

Ibland kontaktar kunder oss och klagar på att de har loggat in för första gången på länge och deras data antingen är borta eller att "inget visas". Det kan bero på att organisationen, på grund av längre inaktivitet på portalen, är inställd på Cloud-Saving Mode, vilket i praktiken stoppar all insamling av information efter en inaktiv period på 30 dagar. Cloud-Saving Mode bör indikeras med en prompt och en banner (ljusblå banner). Lösningen: stäng av Cloud Saving Mode och vänta några minuter, datan bör då snart vara tillbaka.

Mer information finns här: Cloud-Saving Mode (Nebula BASE Pack)

Konfigurationer pushas inte

Du kan ha problemet att din enhet faktiskt visar sig vara online, men ändringar i konfigurationen verkar inte tillämpas? Kontrollera firmware! Vissa ändringar kan kräva den senaste firmware för att fungera korrekt, och ibland hålls ändringar tillbaka på grund av detta:

Detta är ett perfekt exempel på vad vi inte vill se - i detta fall är brandväggens firmware föråldrad, vilket håller tillbaka nya konfigurationsblock från att tillämpas, medan alla andra statusar (CPU, RAM-användning, antal klienter, online/offline-status) verkar vara bra. Denna spärr för konfigurationsbitar gäller särskilt, men inte uteslutande, nya funktioner som implementerats i den senaste firmware-versionen. Så detta, förutom "DNS-problemet" som presenterades ovan, kan vara värdefulla tips.

Övervakning via Nebula - Användbara insikter nära till hands!

Övervakningsfunktionerna ger verkliga fördelar och verktyg för din övervakning och analys. För att börja med något enkelt - en enhet visar offline, men du har känslan att den fortfarande kommunicerar med Nebula Cloud Center korrekt? Gå bara till enhetens huvudsida - för gateways blir det:

Devices -> Firewall

och gör ett Ping-test - om ping-testet faktiskt lyckas meddela enheten "Ping destination W.X.Y.Z" och enheten faktiskt tar emot detta och kan ge återkoppling om lyckade ping, betyder det att enheten faktiskt fortfarande kommunicerar med NCC och offline-statusen kan bero på cache eller cookie-relaterade problem i webbläsaren.

Ett annat verkligt exempel: flera switchportar visar konstant händelseloggmeddelanden som indikerar en växling mellan 10Mb/s-anslutningar och 1Gb/s-anslutningar, och du är osäker på om switchen orsakar problem?

Kontrollera MAC-tabellen via:

Devices > Switches > (välj Switch) > Live Tools > Switch Tables > Run-Button

Du har nu information som kan hjälpa dig - i nämnda verkliga exempel visade det sig att alla switchportar som visade detta beteende hade en mycket specifik MAC-leverantör, vilket i sin tur pekar mot en specifik klienttyp som har detta problem, och det betyder att switchen inte hade något problem - en möjlig lösning här kan vara att ställa in en fast hastighet på dessa klienter och respektive switchportar.

Det finns många andra exempel på hur övervakningen kan göra underverk för att lösa fel, men jag antar att du förstår poängen med detta.

Använda händelseloggar för att få bättre förståelse för processer "under huven"

Händelseloggarna, som varje teknikområde har sina egna av, erbjuder dig ett enormt stöd genom att informera dig om orsaker till varför saker inte fungerar - särskilt vid WiFi-relaterade problem.
Låt oss titta på ett exempel via ett WiFi-nätverk, som visar tre olika poster:

Låt oss analysera de tre olika punkterna en efter en:

1. Detta berättar för oss att en viss station, med en viss MAC-adress, har anslutit till respektive accesspunkt. Den har anslutit med en signalstyrka på -81dBm, vilket i slutändan är för svagt.
2. En station har lämnat ett specifikt SSID, AP, kanal på grund av en WiFi-anledning 3. WiFi-anledningskoder är enhetliga koder för att identifiera och förstå WiFi-beteende. WiFi-anledningskod 3 anger helt enkelt att stationen proaktivt har beslutat att lämna SSID.
3. Det pågick en roamingprocess (= flytt från en AP till en annan) för en viss klient.

Detta är förstås bara en snabb glimt av vad händelseloggar kan berätta för dig, men det visar att händelseloggar kan vara ett kraftfullt verktyg för att förstå vad som faktiskt händer i ditt nätverk. Specifikt när det gäller WiFi-problem finns det ytterligare verktyg för att utvärdera WiFi-kvaliteten, såsom Wireless Health, klientlistor etc. Följande artiklar kan också ge dig mer insikt i detta ämne:

Nebula AP "Easy Troubleshoot"

Wireless Health-lösning från Zyxel Networks