Настройка
Я — айтишник в небольшой компании, и недавно перевёл нас с устаревшей плоской сети на первые этапы более сегрегированной схемы. Прикладываю обзор сети.
SW01 — CRS309-1G-8S+IN, SwOS 2.13
SW02 — CRS309-1G-8S+IN, SwOS 2.13
SW03 — CSS610-8G-2S+IN, SwOSlite 2.17 (ошибки были и на предыдущих версиях, к сожалению, не задокументированы)
SW04 — CSS610-8G-2S+IN, SwOSlite 2.17 (аналогично, ошибки были и раньше, без документации)
ROUTER01 — RB5009UG+S+IN, RouterOS 7.12
Есть VLAN-оверлей, который я не отобразил. В общем, все соединения между свитчами и двумя точками доступа Ubiquiti настроены как trunk (строгий режим, только tagged, порт в VID 4090 и не является членом VLAN). Свитчи и точки доступа работают в management VLAN и принимают подключения только из неё. SSID привязаны к VLAN тегам. ROUTER01 роутит и фильтрует трафик между VLAN. На инфра-сервере крутятся несколько ВМ, в том числе openvz контейнер для мониторинга.
Проблемы
Проблема проявлялась в случайных пропаданиях связи. Когда меня не было на месте, подтвердить быстро не удавалось, и воспроизвести ошибку тоже. Тогда я сделал маленький инструмент, который периодически пингует набор IP и пишет логи в CSV. Запустил это в openvz-контейнере, где уже работает prometheus SNMP экспортер для сетевого железа. Потом скомпилировал утилиту под armv7 и aarch64, чтобы запускать на NAS и даже на точках доступа Ubiquiti.
С каждого мониторящего узла (infra, NAS, AP) пингуются другие устройства, по обе стороны от проблемы. Это позволило выявить виновника — SW03. Все системы на той же стороне (ближайшие свитчи SW01 или SW02) остаются доступны с приемлемым временем отклика. Я периодически импортирую CSV в InfluxDB для просмотра через Grafana. Сейчас есть данные за много дней, и я заметил несколько странностей.
Наблюдения/Выводы
SW03 случайно прекращает передачу трафика.
SW04 делает то же самое, но сначала не было видно — используется в лаборатории, где нет круглосуточных пингов.
Пропадания не связаны ни с каким видимым событием.
Кажется, что чип свитча перестаёт пересылать трафик, НО две точки доступа на этом же свитче могут пару минут пинговаться друг с другом, когда остальной трафик не идёт.
Интерфейс управления свитча продолжает отвечать на пинги без перебоев.
Пропадания длятся ровно 5 минут с точностью до интервала пинга в 1 секунду!
После этих 5 минут трафик возобновляется и всё работает как надо.
Счётчики ошибок на SW03 фиксируют только RX паузы, которые при этом невидимы через SNMP! Mikrotik?!
SNMP счетчики ошибок ничего не показывают вокруг событий.
Я настроил порт-миррор на SW02, и пакетный захват показывает, что после начала сбоя пакеты перестают проходить до возвращения соединения через 5 минут.
Я пришёл из куда более крупной инфраструктуры (другие свитчи, полностью перемешанные резервные 10G каналы по нескольким зданиям с ~80 хостами, 5 фаерволами и разными интернет-линками). Тут я не пытаюсь заморочиться сверх меры и не подозреваю ошибку конфигурации.
Ровно 5 минут подозрительно похоже на таймаут watchdog и перезагрузку части железа.
Эксперименты
Хотел исключить перегрев S+RJ10 — они греются. Поэтому есть отдельный аплинк через обычный S-RJ01 и обычный порт на CSS610.
Сам аплинк проблемой вряд ли является — SW03 отвечает по интерфейсу администрирования даже, когда точки доступа недоступны.
Если бы AP были виноваты, NAS должен был бы стабильно пинговать роутер и быть доступен с SNMP-экспортера.
Если я не ошибаюсь, другой причины для таких сбоев, не связанных с SW03, нет.
Сначала думал, что HW-поломка SW03, поменял конфигурации SW03 и SW04 (идентичные модели) — ошибка появилась и на другом железе тоже!
Делаю вывод — проблема в OS, если бы это был HW, пострадал бы весь парк или значительная часть, и я бы уже наткнулся на обсуждения.
У меня был неиспользуемый CRS326-24G-2S+RM (со свежим SwOS), который я добавил вместо SW03. Имелся только один spare PoE инжектор — на одну AP. Во время работы произошёл как минимум один сбой: AP на SW03 отключилась, а AP на CRS326 отвечала нормально.
Это ещё больше указывает на проблему с SwOSlite или обеими нашими CSS610, хотя у них разные серийники и даже разные vendor bits в MAC, так что это вряд ли одна партия.
— Я на пределе, единственный выход — заменить свитчи и больше не брать CSS.
Очень раздражён, ведь я привнёс Mikrotik в компанию с «они мощные за свои деньги и при этом «нормальные» устройства», а теперь «Я» — причина всех проблем.
Люди понимают, что редкий, но случайный сбой — худшая лотерея, а пропадания в важных встречах — катастрофа.
Есть идеи, в чём причина? Как дальше копать? Вопросы по отсутствующей информации?
С уважением, Моу
Я — айтишник в небольшой компании, и недавно перевёл нас с устаревшей плоской сети на первые этапы более сегрегированной схемы. Прикладываю обзор сети.
SW01 — CRS309-1G-8S+IN, SwOS 2.13
SW02 — CRS309-1G-8S+IN, SwOS 2.13
SW03 — CSS610-8G-2S+IN, SwOSlite 2.17 (ошибки были и на предыдущих версиях, к сожалению, не задокументированы)
SW04 — CSS610-8G-2S+IN, SwOSlite 2.17 (аналогично, ошибки были и раньше, без документации)
ROUTER01 — RB5009UG+S+IN, RouterOS 7.12
Есть VLAN-оверлей, который я не отобразил. В общем, все соединения между свитчами и двумя точками доступа Ubiquiti настроены как trunk (строгий режим, только tagged, порт в VID 4090 и не является членом VLAN). Свитчи и точки доступа работают в management VLAN и принимают подключения только из неё. SSID привязаны к VLAN тегам. ROUTER01 роутит и фильтрует трафик между VLAN. На инфра-сервере крутятся несколько ВМ, в том числе openvz контейнер для мониторинга.
Проблемы
Проблема проявлялась в случайных пропаданиях связи. Когда меня не было на месте, подтвердить быстро не удавалось, и воспроизвести ошибку тоже. Тогда я сделал маленький инструмент, который периодически пингует набор IP и пишет логи в CSV. Запустил это в openvz-контейнере, где уже работает prometheus SNMP экспортер для сетевого железа. Потом скомпилировал утилиту под armv7 и aarch64, чтобы запускать на NAS и даже на точках доступа Ubiquiti.
С каждого мониторящего узла (infra, NAS, AP) пингуются другие устройства, по обе стороны от проблемы. Это позволило выявить виновника — SW03. Все системы на той же стороне (ближайшие свитчи SW01 или SW02) остаются доступны с приемлемым временем отклика. Я периодически импортирую CSV в InfluxDB для просмотра через Grafana. Сейчас есть данные за много дней, и я заметил несколько странностей.
Наблюдения/Выводы
SW03 случайно прекращает передачу трафика.
SW04 делает то же самое, но сначала не было видно — используется в лаборатории, где нет круглосуточных пингов.
Пропадания не связаны ни с каким видимым событием.
Кажется, что чип свитча перестаёт пересылать трафик, НО две точки доступа на этом же свитче могут пару минут пинговаться друг с другом, когда остальной трафик не идёт.
Интерфейс управления свитча продолжает отвечать на пинги без перебоев.
Пропадания длятся ровно 5 минут с точностью до интервала пинга в 1 секунду!
После этих 5 минут трафик возобновляется и всё работает как надо.
Счётчики ошибок на SW03 фиксируют только RX паузы, которые при этом невидимы через SNMP! Mikrotik?!
SNMP счетчики ошибок ничего не показывают вокруг событий.
Я настроил порт-миррор на SW02, и пакетный захват показывает, что после начала сбоя пакеты перестают проходить до возвращения соединения через 5 минут.
Я пришёл из куда более крупной инфраструктуры (другие свитчи, полностью перемешанные резервные 10G каналы по нескольким зданиям с ~80 хостами, 5 фаерволами и разными интернет-линками). Тут я не пытаюсь заморочиться сверх меры и не подозреваю ошибку конфигурации.
Ровно 5 минут подозрительно похоже на таймаут watchdog и перезагрузку части железа.
Эксперименты
Хотел исключить перегрев S+RJ10 — они греются. Поэтому есть отдельный аплинк через обычный S-RJ01 и обычный порт на CSS610.
Сам аплинк проблемой вряд ли является — SW03 отвечает по интерфейсу администрирования даже, когда точки доступа недоступны.
Если бы AP были виноваты, NAS должен был бы стабильно пинговать роутер и быть доступен с SNMP-экспортера.
Если я не ошибаюсь, другой причины для таких сбоев, не связанных с SW03, нет.
Сначала думал, что HW-поломка SW03, поменял конфигурации SW03 и SW04 (идентичные модели) — ошибка появилась и на другом железе тоже!
Делаю вывод — проблема в OS, если бы это был HW, пострадал бы весь парк или значительная часть, и я бы уже наткнулся на обсуждения.
У меня был неиспользуемый CRS326-24G-2S+RM (со свежим SwOS), который я добавил вместо SW03. Имелся только один spare PoE инжектор — на одну AP. Во время работы произошёл как минимум один сбой: AP на SW03 отключилась, а AP на CRS326 отвечала нормально.
Это ещё больше указывает на проблему с SwOSlite или обеими нашими CSS610, хотя у них разные серийники и даже разные vendor bits в MAC, так что это вряд ли одна партия.
— Я на пределе, единственный выход — заменить свитчи и больше не брать CSS.
Очень раздражён, ведь я привнёс Mikrotik в компанию с «они мощные за свои деньги и при этом «нормальные» устройства», а теперь «Я» — причина всех проблем.
Люди понимают, что редкий, но случайный сбой — худшая лотерея, а пропадания в важных встречах — катастрофа.
Есть идеи, в чём причина? Как дальше копать? Вопросы по отсутствующей информации?
С уважением, Моу
