Nebula Hibaelhárítás – Gyakori problémák

Ez a cikk a leggyakoribb problémák hibaelhárításával foglalkozik – ha az eszközök offline állapotban maradnak, nem látható semmilyen adat/napló (PoE, CPU használat, adatforgalom, naplók stb.), a konfigurációk nem kerülnek továbbításra (firmware kezelés), az eseménynaplók használatával.

Nagyon örülünk, hogy Nebula Felhőmegoldásunk egyre nagyobb lendületet vesz a terepen, és egyre inkább kulcsfontosságú fókuszponttá válik portfóliónk bővítése során. Ami egy „spin-off” megoldásként indult, az befektetéseinkkel és előrejelzéseinkkel összhangban a működésünk és termékeink sarokkövévé vált. Azonban ezzel a fókuszváltással a Nebula-képes eszközök egyre inkább professzionális hálózati környezetekben kerülnek használatra. Ez a váltás sok ügyfelünkben felveti a kérdést: „Mit tehetek a problémáim elemzéséért, mielőtt másokhoz fordulnék?”

Ez az útmutató ötleteket és javaslatokat ad arra, hogy mit érdemes ellenőrizni, ha az eszközök nem működnek megfelelően – egyesek inkább általános jellegűek (= legjobb gyakorlat példák), mások pedig egy kicsit specifikusabbak a különböző technológiai területekre.

Megjegyzés: Nebula által kezelt eszközök nem konfigurálhatók semmilyen formában konzolkapcsolaton keresztül – kérjük, csak SSH hozzáférést használjon a Nebula eszközökhöz monitorozásra, és esetlegesen, támogatásunkkal vagy fejlesztői részlegünkkel együttműködve hibakeresési mérésekhez.

Az eszközök offline állapotban maradnak

Képzelje el – sikeresen regisztrálta az eszközét, talán beállított néhány konfigurációt az igényeinek megfelelően, és most az eszköz telepítési fázisában van. Azonban, az Ön számára még ismeretlen okból, az adott eszköz egyszerűen nem akar online állapotba kerülni sem a helyszínen, sem működés közben, sem pedig nem jelenik meg online és válaszképes állapotban.

Ez az egyik leggyakoribb probléma Nebula eszközök telepítésekor – röviden a probléma oka, hogy az eszközök alapértelmezés szerint az s.nebula.zyxel.com vagy a d.nebula.zyxel.com címeket próbálják feloldani. Ez két problémát okoz:

1. Többszörösen egymásba ágyazott aldomain (pl. ez.az.ésez.is.domain.com) problémákat okozhat egyes DNS szolgáltatóknál
2. Az újabb szabványok szerint egy aldomain akár egyetlen karakterből is állhat, míg korábban minimum három karakter volt. Egyes DNS szerverek ezzel problémát tapasztalnak.

Gyakran tapasztaljuk, hogy internetszolgáltatók DNS szerverei problémáznak ezen. Ajánlásunk: módosítsa az alapértelmezett DNS szervert 8.8.8.8-ra vagy 1.1.1.1-re. További információ itt található:

Mit tegyek, ha a Nebula eszközöm nem tud online lenni / kapcsolat problémái vannak / nem kommunikál az NCC-vel?

Nem látok semmilyen adatot!

Előfordul, hogy ügyfelek hozzánk fordulnak azzal a panasszal, hogy hosszabb idő után bejelentkeztek, és az adataik eltűntek vagy „semmi sem jelenik meg”. Elképzelhető, hogy a portálon hosszabb inaktivitás miatt a szervezet Felhő-megtakarítási módba került, ami alapvetően 30 napos tétlenség után leállítja az információgyűjtést. A Felhő-megtakarítási módot egy értesítés és egy világoskék sáv jelzi. A megoldás: kapcsolja ki a Felhő-megtakarítási módot, és várjon néhány percet, az adatok hamarosan vissza kell, hogy jöjjenek.

További információ itt található: Felhő-megtakarítási mód (Nebula BASE Pack)

A konfigurációk nem kerülnek továbbításra

Előfordulhat, hogy az eszköz online állapotban van, de a konfiguráció módosításai nem lépnek életbe? Ellenőrizze a firmware-t! Egyes változtatások a legfrissebb firmware-t igénylik a megfelelő működéshez, és néha emiatt visszatarthatók a változtatások:

Ez egy tökéletes példa arra, amit nem szeretnénk látni – ebben az esetben a tűzfal firmware elavult, és ez visszatartja az új konfigurációs blokkok alkalmazását, miközben minden más statisztika (CPU, RAM használat, kliens szám, online/offline állapot) rendben van. A konfigurációs blokkok visszatartása különösen, de nem kizárólagosan az új funkciókra vonatkozik, amiket a legfrissebb firmware tartalmaz. Ez, az előző „DNS-probléma” mellett, értékes tipp lehet.

Monitorozás Nebula-val – hasznos betekintés az ujjhegyén!

A monitorozási funkciók valódi előnyöket és eszközöket biztosítanak a felügyelet és elemzés területén. Kezdjünk egy egyszerű példával – egy eszköz offline állapotban jelenik meg, de úgy érzi, hogy mégis kommunikál a Nebula Felhőközponttal? Egyszerűen lépjen az eszköz főoldalára – átjárók esetén ez:

Eszközök -> Tűzfal

és végezzen egy Ping-tesztet – ha a ping teszt sikeresen elküldi az üzenetet „Ping cél W.X.Y.Z” és az eszköz ezt fogadja, majd visszajelzést ad a sikeres pingről, az azt jelenti, hogy az eszköz valóban kommunikál az NCC-vel, és az offline állapot inkább böngésző cache vagy cookie problémából eredhet.

Egy másik valós példa: több kapcsolóport folyamatosan eseménynapló üzeneteket mutat, amelyek 10Mb/s és 1Gb/s közötti váltakozást jeleznek, és bizonytalan, hogy a kapcsoló okozza-e a problémát?

Ellenőrizze a MAC táblát ezen a helyen:

Eszközök > Kapcsolók > (kapcsoló kiválasztása) > Élő eszközök > Kapcsoló táblák > Futtatás gomb

Most már rendelkezik olyan információval, ami segíthet – ebben a valós példában kiderült, hogy az összes ilyen viselkedést mutató kapcsolóport egy nagyon specifikus MAC gyártóhoz tartozott, ami inkább egy adott kliens típus problémájára utal, tehát a kapcsolónak nem volt gondja – egy lehetséges megoldás lehet a fix sebesség beállítása az érintett klienseken és a kapcsolóportokon.

Sok más példa is van arra, hogyan tud a monitorozás csodákat tenni a hibák elhárításában, de gondolom, érti az alapvető lényegét.

Eseménynaplók használata a folyamatok „motorháztető alatti” jobb megértéséhez

Az eseménynaplók, amelyek minden technológiai területnek megvannak a sajátjai, óriási segítséget nyújtanak abban, hogy megértsük, miért nem működnek a dolgok – különösen WiFi-vel kapcsolatos problémák esetén.
Nézzünk meg egy példát egy WiFi hálózaton keresztül, három különböző bejegyzéssel:

Elemezzük egymás után a 3 különböző pontot:

1. Ez azt jelzi, hogy egy bizonyos állomás, egy adott MAC-címmel, csatlakozott a megfelelő hozzáférési ponthoz. -81dBm jelerősséggel csatlakozott, ami végül is túl gyenge.
2. Egy állomás elhagyott egy adott SSID-t, AP-t, csatornát egy WiFi 3-as ok miatt. A WiFi okkódok egységes kódok a WiFi viselkedés azonosítására és megértésére. A WiFi okkód 3 egyszerűen azt jelenti, hogy az állomás proaktívan döntött úgy, hogy elhagyja az SSID-t.
3. Volt egy roaming folyamat (= átváltás egyik AP-ról a másikra) egy adott kliens esetében.

Ez természetesen csak egy kis betekintés abba, mit mondhatnak az eseménynaplók, de jól mutatja, hogy az eseménynaplók hatékony eszközök lehetnek hálózata valós működésének megértéséhez. Különösen WiFi problémák esetén további eszközök állnak rendelkezésre a WiFi minőség értékelésére, mint például a Wireless Health, klienslisták stb. Az alábbi cikkek további betekintést nyújthatnak ebben a témában:

Nebula AP „Egyszerű hibaelhárítás”

Wireless Health-megoldás a Zyxel Networks-től