Nebula Устранение неполадок — распространённые проблемы

В этой статье рассматриваются наиболее распространённые проблемы — если устройство остаётся офлайн, не отображаются данные/логи (PoE, использование ЦП, использование данных, логи и т. д.), конфигурации не применяются (управление прошивкой), а также использование журналов событий.

Мы очень рады видеть, что наше облачное решение Nebula набирает обороты в полевых условиях и становится всё более ключевым направлением при расширении нашего портфолио. То, что начиналось как «отдельное» решение, в соответствии с нашими инвестициями и прогнозами, стало краеугольным камнем наших операций и продуктов. Однако с этим сдвигом в фокусе оборудование с поддержкой Nebula всё чаще используется в профессиональных сетевых средах. Этот сдвиг вызывает у многих наших клиентов вопрос: «Что я могу сделать, чтобы проанализировать свои проблемы, прежде чем обращаться к кому-то ещё?»

Это руководство даст некоторые идеи и рекомендации по проверке в случае, если ваши устройства работают некорректно — некоторые из них носят более общий характер (= примеры лучших практик), некоторые — более специфичны для различных технологических областей.

Примечание: устройства под управлением Nebula не предназначены для настройки каким-либо образом через консольное подключение — пожалуйста, используйте SSH-доступ к устройствам Nebula только для мониторинга и, возможно, совместно с нашей службой поддержки/отделом НИОКР для проведения отладочных измерений.

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

Представьте: вы успешно зарегистрировали устройство, возможно, даже настроили некоторые параметры по своему усмотрению, и сейчас находитесь на этапе развертывания устройства. Однако по неизвестным вам причинам устройство просто не выходит в онлайн как на месте, так и в интерфейсе, не отображая состояние онлайн и не отвечая.

Это одна из самых распространённых проблем при развертывании устройств 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)

Конфигурации не применяются

Возможно, у вас возникает проблема, когда устройство отображается как онлайн, но изменения конфигурации, кажется, не применяются? Проверьте прошивку! Некоторые изменения требуют последней версии прошивки для корректной работы, и иногда изменения задерживаются по этой причине:

Это отличный пример того, чего мы не хотели бы видеть — в данном случае прошивка брандмауэра устарела, и это задерживает применение новых блоков конфигурации, хотя все остальные показатели (использование ЦП, ОЗУ, количество клиентов, состояние онлайн/офлайн) выглядят нормально. Задержка применения блоков конфигурации особенно, но не исключительно, касается новых функций, реализованных в последних версиях прошивки. Таким образом, помимо вышеупомянутой «проблемы с DNS», это может быть полезной подсказкой.

Мониторинг через Nebula — полезная информация под рукой!

Функции мониторинга предоставляют реальные преимущества и инструменты для ваших активов мониторинга и аналитики. Для начала с простого — устройство отображается как офлайн, но у вас есть ощущение, что оно всё ещё связывается с облачным центром Nebula? Просто перейдите на главную страницу устройства — для шлюзов это будет:

Devices -> Firewall

и выполните тест Ping — если тест Ping успешно сообщает устройству «Ping destination W.X.Y.Z» и устройство действительно получает это и может ответить успешными пингами, это означает, что устройство на самом деле всё ещё связывается с NCC, и состояние офлайн может быть связано с кэшем браузера или cookie.

Другой реальный пример: несколько портов коммутатора постоянно показывают в журнале событий сообщения о переключении между соединениями 10 Мбит/с и 1 Гбит/с, и вы не уверены, вызывает ли это коммутатор проблемы?

Проверьте таблицу MAC-адресов через:

Devices > Switches > (выберите коммутатор) > Live Tools > Switch Tables > Run-Button

Теперь у вас есть информация, которая может помочь — в приведённом примере оказалось, что все порты коммутатора с таким поведением имели MAC-поставщика с очень специфическим производителем, что указывает скорее на конкретный тип клиента с этой проблемой, а не на неисправность коммутатора. Возможное решение — установить фиксированную скорость на указанных клиентах и соответствующих портах коммутатора.

Существует множество других примеров того, как мониторинг может творить чудеса при решении ошибок, но, думаю, вы поняли суть.

Использование журналов событий для лучшего понимания процессов «под капотом»

Журналы событий, которые есть у каждой технологической области, предоставляют огромную помощь в информировании о причинах, почему что-то не работает — особенно при проблемах с WiFi.
Рассмотрим один пример на примере WiFi-сети с тремя разными записями:

Проанализируем три разных пункта по очереди:

1. Это сообщает нам, что определённая станция с определённым MAC-адресом подключилась к соответствующей точке доступа. Она подключилась с уровнем сигнала -81 дБм, что в конечном итоге слишком слабо.
2. Станция покинула определённый SSID, точку доступа, канал по причине WiFi reason 3. Коды причин WiFi — это унифицированные коды для идентификации и понимания поведения WiFi. Код причины WiFi 3 просто означает, что станция самостоятельно решила покинуть SSID.
3. Произошёл процесс роуминга (= переход с одной точки доступа на другую) у определённого клиента.

Конечно, это лишь краткий взгляд на то, что могут рассказать журналы событий, но это показывает, что журналы событий могут быть мощным инструментом для понимания того, что на самом деле происходит в вашей сети. В частности, в отношении проблем с WiFi существуют дополнительные инструменты для оценки качества WiFi, такие как Wireless Health, списки клиентов и т. д. Следующие статьи могут дать вам больше информации по этой теме:

Nebula AP «Лёгкое устранение неполадок»

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