Důležité upozornění: |
Tento článek bude řešit nejčastější problémy - pokud zařízení zůstávají offline, Nelze zobrazit žádná data/logy (PoE, využití CPU, využití dat, logy atd.), konfigurace nejsou tlačeny (správa firmwaru), pomocí protokolů událostí.
Jsme velmi rádi, že naše řešení Nebula Cloud nabírá v terénu na síle a také je stále více klíčovým bodem zájmu, pokud jde o rozšiřování našeho portfolia. To, co začalo jako "vedlejší" řešení, se v souladu s našimi investicemi a předpověďmi stalo základním kamenem našich operací a produktů. S tímto posunem v zaměření se však zařízení podporující technologii Nebula stále častěji používají v profesionálních síťových prostředích. Tento posun s sebou nese otázku pro mnoho našich zákazníků "Co mohu udělat pro analýzu svých problémů, než se obrátím na někoho jiného?".
Tento průvodce poskytne několik nápadů a podnětů, co zkontrolovat v případě, že vaše zařízení nefunguje správně - některé z nich jsou spíše obecného charakteru (= příklady osvědčených postupů), některé jsou trochu specifičtější pro různé technologické oblasti.
Jako předpoklad již máme příručku o přístupu k firewallům podporujícím Nebulu prostřednictvím SSH, která vám již ve spojení s referenčními příručkami CLI z možná pomůže získat trochu přehled o různých možnostech, co zkontrolovat, když se připojujete prostřednictvím SSH k příslušným zařízením Nebula:
Přístup k bráně Nebula Firewall přes SSH a zachycení paketů / sledování paketů z internetu.
Poznámka: Zařízení spravovaná systémem Nebula nejsou určena k tomu, aby byla v jakékoliv podobě konfigurována prostřednictvím konzolového připojení - přístup přes SSH k zařízením Nebula používejte pouze pro monitorování a případně, ve spolupráci s naším oddělením podpory/R&D, pro ladění měření.
Zařízení zůstávají offline
Představte si to - úspěšně jste zaregistrovali své zařízení, možná jste dokonce nakonfigurovali některá nastavení podle svých představ a nyní jste ve fázi nasazení zařízení. Z vám zatím neznámých důvodů se však dané zařízení prostě nechce připojit online jak na místě, fungovat, tak i plně ukazovat, že je online a reaguje.
Jedná se o jeden z nejčastějších problémů při nasazování zařízení Nebula - důvodem je ve zkratce to, že zařízení se ve výchozím nastavení snaží resolvovat buď na adresu s.nebula.zyxel.com, nebo d.nebula.zyxel.com. To s sebou nese dva problémy:
- Vícenásobně kaskádovaná subdoména (např. this.that.andthis.alsothis.domain.com) může u některých poskytovatelů DNS vést k problémům.
- Podle novějších standardů se subdoména může skládat i z jednoho znaku, zatímco dříve to byly minimálně tři znaky. Některé servery DNS s tím mají problémy.
Velmi často se setkáváme s tím, že servery DNS poskytovatelů internetových služeb s tím mají problémy. Naše doporučení: Změňte výchozí server DNS na 8.8.8.8 nebo 1.1.1.1. Více informací naleznete zde:
Nevidím žádná data!
Občas se na nás obracejí zákazníci a stěžují si, že se poprvé po delší době přihlásili a jejich data jsou buď pryč, nebo se "nic nezobrazuje". Může to být tím, že z důvodu delší nečinnosti na portálu je organizace nastavena do úsporného režimu Cloud, který v podstatě po 30 dnech nečinnosti přeruší sběr všech informací. Režim Cloud-Saving Mode by měl být indikován výzvou a bannerem (světle modrý banner). Řešení: Vypněte režim Cloud Saving Mode a počkejte několik minut, data by se pak měla brzy obnovit.
Další informace naleznete zde: Režim úspory dat v cloudu (Nebula BASE Pack)
Konfigurace nejsou odesílány
Může se vám stát, že se vaše zařízení skutečně zobrazuje online, ale změna konfigurace se zřejmě neuplatní? Zkontrolujte firmware! Některé změny mohou ke správnému fungování vyžadovat nejnovější firmware a někdy jsou kvůli tomu změny zdržovány:
V tomto případě je firmware brány firewall zastaralý, což zdržuje případné použití nových bloků konfigurace, zatímco všechny ostatní statistiky (CPU, využití RAM, počet klientů, stav online/offline) se zdají být v pořádku. Zdržování konfiguračních bloků se týká zejména, ale ne výhradně, nových funkcí implementovaných v nejnovějším firmwaru. Takže to, kromě výše prezentovaného "DNS-Issue", mohou být cenné rady.
Monitorování prostřednictvím Nebula - užitečné poznatky na dosah ruky!
Funkce monitorování poskytují skutečné výhody a nástroje pro vaše monitorovací a analytické prostředky. Začněme něčím jednoduchým - zařízení se zobrazuje jako offline, ale máte pocit, že stále správně komunikuje s centrem Nebula Cloud Center? Stačí přejít na hlavní stránku zařízení - pro brány by to bylo:
dyn_repppp_0a proveďte ping-test - pokud se při ping-testu skutečně podaří zařízení úspěšně sdělit "Ping destination W.X.Y.Z" a zařízení to skutečně přijme a může poskytnout zpětnou vazbu o úspěšném pingu, znamená to, že zařízení skutečně stále komunikuje s NCC a stav offline může být problémem souvisejícím s mezipamětí prohlížeče nebo soubory cookie.
Další příklad z reálného života: na několika portech přepínače se neustále zobrazují zprávy protokolu událostí, které indikují přepínání mezi 10Mb/s připojeními a 1Gb/s připojeními, a vy si nejste jisti, zda problémy nezpůsobuje přepínač?
Zkontrolujte tabulku MAC prostřednictvím:
Devices > Switches > (select Switch) > Live Tools > Switch Tables > Run-Button
Víte, že máte informace, které by vám mohly pomoci - ve zmíněném reálném příkladu se ukázalo, že všechny porty přepínače vykazující toto chování měly velmi specifického dodavatele MAC, což zase ukazuje spíše na konkrétní typ klienta, který má tento problém, a to znamená, že přepínač neměl problém - možným řešením by zde mohlo být nastavení pevné rychlosti na zmíněných klientech a příslušných portech přepínače.
Existuje mnoho dalších příkladů, jak monitorování může dělat zázraky při řešení chyb, ale myslím, že v tomto ohledu chápete pointu.
Využití protokolů událostí k lepšímu pochopení procesů "pod kapotou"
Protokoly událostí, které má každá technologická oblast své vlastní, vám nabízejí obrovskou pomoc při informování o důvodech, proč věci nefungují - zejména v případě problémů souvisejících s WiFi.
Podívejme se na jeden příklad prostřednictvím sítě WiFi, který ukazuje tři různé záznamy:
Analyzujme 3 různé body po sobě:
- To nám říká, že se k příslušnému přístupovému bodu připojila určitá stanice s určitou adresou MAC. Připojila se se silou signálu -81 dBm, což je nakonec příliš slabé (pro referenci se podívejte na tento návod: Zlepšení roamingu WiFi na mých přístupových bodech Nebula? )
- Stanice opustila konkrétní SSID, AP, kanál z důvodu WiFi 3. Kódy důvodů WiFi jsou jednotné kódy pro identifikaci a pochopení chování WiFi. Pro referenci se podívejte na tento článek: Jaký je význam kódů důvodů deautentizace 802.11?
Kód důvodu WiFi 3 jednoduše říká, že se stanice aktivně rozhodla opustit SSID. - Došlo k procesu roamingu (= přesunu z jednoho AP na druhé) určitého klienta.
Nyní je to samozřejmě jen vrcholný pohled na to, co vám protokoly událostí mohou říci, ale ukazuje, že protokoly událostí mohou být mocným nástrojem pro pochopení toho, co se ve vaší síti skutečně děje. Konkrétně s ohledem na problémy WiFi existují další nástroje pro vyhodnocení kvality WiFi, jako je Wireless Health, Client lists atd. následující články vám mohou poskytnout více informací i k tomuto tématu:

Komentáře
0 komentářůProsím přihlaste se, abyste mohli napsat komentář.