Nebula Отстраняване на неизправности - Чести проблеми

Тази статия ще разгледа отстраняването на най-честите проблеми - ако устройството остава офлайн, не се виждат никакви данни/логове (PoE, използване на CPU, използване на данни, логове и др.), конфигурациите не се прилагат (управление на фърмуера), използване на събитийни логове.

Много се радваме да видим, че нашето Nebula облачно решение набира скорост на терен, както и че става все по-ключов фокус при разширяването на нашето портфолио. Това, което започна като „спин-оф“ решение, се превърна, в съответствие с нашите инвестиции и прогнози, в основен камък на нашите операции и продукти. Въпреки това, с тази промяна на фокуса, оборудването с възможности за Nebula се използва все повече в професионални мрежови среди. Тази промяна поражда въпроса за много от нашите клиенти: „Какво мога да направя, за да анализирам проблемите си, преди да се обърна към някой друг?“

Това ръководство ще предостави някои идеи и насоки за неща, които да проверите, ако вашите устройства не функционират правилно - някои от тях са по-общи по характер (= добри практики), а други са по-специфични за различни технологични области.

Бележка: Устройствата, управлявани от Nebula, не са предназначени да се конфигурират по никакъв начин чрез конзолна връзка - моля използвайте SSH достъп до Nebula устройствата само за мониторинг и евентуално, в сътрудничество с нашата поддръжка/отдел R&D, за дебъгване.

Устройствата остават офлайн

Представете си - успешно сте регистрирали устройството си, може би дори сте конфигурирали някои настройки по ваш вкус и сега сте в етап на внедряване на устройството. Въпреки това, по причини, които все още не знаете, устройството просто не иска да се свърже онлайн както на място, така и да показва, че е онлайн и отзивчиво.

Това е един от най-честите проблеми при внедряване на Nebula устройства - причината за това, в кратки линии, е че устройствата по подразбиране се опитват да разрешат адрес към s.nebula.zyxel.com или d.nebula.zyxel.com. Това носи два проблема:

1. Многократно каскадно поддоменово име (например this.that.andthis.alsothis.domain.com) може да доведе до проблеми при някои DNS доставчици
2. Според по-новите стандарти, поддомен може да се състои и от един символ, докато преди минимумът беше три символа. Някои DNS сървъри имат проблеми с това.

Много често виждаме DNS сървърите на интернет доставчици да имат проблеми с това. Нашата препоръка: сменете стандартния DNS сървър на 8.8.8.8 или 1.1.1.1. Повече информация може да намерите тук:

Какво да направя, ако моето Nebula устройство не може да се свърже онлайн / има проблеми с връзката / не комуникира с NCC?

Не виждам никакви данни!

Понякога клиентите се свързват с нас, оплаквайки се, че са влезли за първи път след дълго време и данните им са изчезнали или „не се показва нищо“. Възможно е, поради дълга неактивност в портала, организацията да е настроена в Режим на пестене на облака, който на практика прекъсва събирането на информация след период на бездействие от 30 дни. Режимът на пестене на облака трябва да бъде индикиран с подсещане и с банер (светлосин банер). Решението: изключете режима на пестене на облака и изчакайте няколко минути, данните би трябвало скоро да се върнат.

Повече информация може да намерите тук: Режим на пестене на облака (Nebula BASE Pack)

Конфигурациите не се прилагат

Може да имате проблем, при който устройството ви показва, че е онлайн, но промените в конфигурацията сякаш не се прилагат? Проверете фърмуера! Някои промени може да изискват най-новия фърмуер, за да функционират правилно, и понякога промените се блокират поради това:

Това е перфектен пример за нещо, което не бихме искали да видим - в този случай фърмуерът на защитната стена е остарял и това блокира евентуално прилагането на нови блокове от конфигурацията, докато всички други статистики (CPU, използване на RAM, брой клиенти, състояние онлайн/офлайн) изглеждат нормални. Блокирането на части от конфигурацията важи особено, но не изключително, за нови функции, внедрени в най-новия фърмуер. Така че, освен „DNS-проблема“, представен по-горе, това може да са ценни съвети.

Мониторинг чрез Nebula - Полезна информация на една ръка разстояние!

Функциите за мониторинг предоставят реални ползи и инструменти за вашите мониторингови и аналитични активи. За да започнем с нещо просто - устройство показва, че е офлайн, но имате усещането, че все още комуникира правилно с Nebula Cloud Center? Просто отидете на основната страница на устройството - за шлюзове това би било:

Devices -> Firewall

и направете Ping-тест - ако тестът за пинг успее да изпрати успешно „Ping дестинация W.X.Y.Z“ и устройството го получи и може да върне обратна връзка за успешни пингове, това означава, че устройството все още комуникира с NCC и състоянието офлайн може да е свързано с кеш или бисквитки на браузъра.

Друг реален пример: няколко порта на суич постоянно показват съобщения в логовете за събития, индикиращи превключване между връзки 10Mb/s и 1Gb/s, и не сте сигурни дали суичът причинява проблеми?

Проверете MAC таблицата чрез:

Devices > Switches > (изберете суич) > Live Tools > Switch Tables > Run-Button

Сега имате информация, която може да ви помогне - в посочения реален пример се оказа, че всички портове на суича, показващи това поведение, имат специфичен MAC производител, което насочва към конкретен тип клиент, който има този проблем, а това означава, че суичът няма проблем - възможно решение тук може да бъде задаване на фиксирана скорост на тези клиенти и съответните портове на суича.

Има много други примери за това как мониторингът може да направи чудеса при разрешаването на грешки, но предполагам, че разбирате идеята.

Използване на събитийните логове за по-добро разбиране на процесите „под капака“

Събитийните логове, които всяка технологична област има свои, ви предоставят огромна помощ при информирането за причините, поради които нещата не работят - особено при проблеми с WiFi.
Нека разгледаме един пример с WiFi мрежа, показваща три различни записа:

Нека анализираме трите различни точки една след друга:

1. Това ни казва, че определена станция с конкретен MAC адрес се е свързала към съответната точка за достъп. Свързала се е със сила на сигнала -81dBm, което на практика е твърде слабо.
2. Станция е напуснала конкретен SSID, AP, канал поради WiFi причина 3. WiFi кодовете за причина са унифицирани кодове за идентифициране и разбиране на поведението на WiFi. WiFi причина код 3 просто означава, че станцията е взела проактивно решение да напусне SSID.
3. Имало е процес на роуминг (= преместване от една точка за достъп към друга) на определен клиент.

Това, разбира се, е само бегъл поглед към това, което събитийните логове могат да ви кажат, но показва, че те могат да бъдат мощен инструмент за разбиране на това, което всъщност се случва във вашата мрежа. Специално по отношение на WiFi проблемите, има допълнителни инструменти за оценка на качеството на WiFi, като Wireless Health, списъци с клиенти и др. Следните статии също могат да ви дадат повече информация по тази тема:

Nebula AP „Лесно отстраняване на неизправности“

Wireless Health решение от Zyxel Networks