Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1 2 След.
RSS
Запутались с UI проблемами на Unifi на конкретном клиентском сайте - сеть на UDMP., UniFi Protect
 
Вот топология сети: Несколько недель назад я подумал, что свитч US-8 в подвале вышел из строя. Он показывал, что оффлайн, несмотря на то, что ему всего месяц онлайн. Он включался после перезагрузки питания, мигал белым индикатором загрузки, но так и не показывал синий свет или не отображался онлайн. Поэтому я заменил его другим US-8.

Теперь я начинаю думать, что что-то не так. Хотя проблем с кабелями, соединяющими UDMP и свитч US-8 в подвале нет, он постоянно меняет скорость между FE & GBE по какой-то причине. Также Unifi показывает, что огромное количество устройств подключено к свитчу US-8 в подвале, что совсем не так. Это невозможно. Любые устройства с именем "master bed" подключены к свитчу US-8 в спальне, устройства в гостиной подключены к свитчу US-8 в гостиной, а Sonos Amp в гостиной на самом деле находится в сетевой стойке в подвале, напрямую подключен к UDMP. Но Unifi показывает другое. Смотрите ниже:

Все это началось после обновления оригинального свитча US-8 в подвале до прошивки 6.2.14. Еще более странно? US-8, который я думал, что сломан, и который я заменил, когда я привез его в свою мастерскую, снова выходит в онлайн, хотя он не подключен к исходной клиентской сети. Я начинаю подозревать, что что-то не так с самим UDMP? Еще один момент, который стоит упомянуть. Даже когда свитч US-8 в подвале показывает, что он меняет скорость между FE & GBE, Apple TV, подключенный к нему, всегда отображает GBE. Всякий раз, когда Apple TV в использовании, он показывает, что получает GBE. Таким образом, порт #1 (uplink) и порт #8 (Apple TV) свитча в подвале всегда окрашены в зеленый цвет и указывают на GBE, но при просмотре вкладки устройств в Unifi свитч US-8 в подвале будет переключаться между FE & GBE. Я никогда не сталкивался с подобным в своих Unifi-сетях. Очень странно.

Странно, как заменяющий US-8 в подвале меняет скорость его подключения к UDMP в соответствии с Unifi. Отображение в интерфейсе Unifi. То, как он переключается каждые 5 минут, говоря, что его подключение uplink от UDMP, – это FE против GBE. Однако Unifi никогда не показывает подключенный порт 1 нового свитча US-8 в подвале в качестве чего-то отличного от 1GBE зеленого для порта #1 этого US-8. Еще одна новая вещь с этим заменяющим свитчем US-8 в подвале – это блокировка STP проводных устройств Sonos. Все началось после прошивки 6.2.14, но, кроме этого, мои внутренние ощущения также говорят мне, что что-то не так. Смотрите ниже:

Я также не знал до возникновения проблем на этом объекте, что ни одна из моделей UDMP не имеет встроенной функциональности STP.

Какие у вас есть идеи, что может идти не так или что мне стоит попробовать исправить? Первое, что я сделаю, когда снова буду физически на объекте, – это отключить свитч US-8 в подвале и посмотреть, что Unifi будет отображать после этого. Но в целом я всегда чувствовал, что эта сеть работает на 100% с момента развертывания. Хотя я развернул ее так, как обычно это делаю на других Unifi-сайтах.
 
Пропуск данных на самом деле не вызывает увеличения циклов процессора коммутатора. Он должен легко передавать 16Gbps по бэкплейну. Загрузка управления – вот что приводит к повышению нагрузки на процессор.
 
Кажется, мне стоит мониторить загрузку CPU на моём свитче… Мне и так хватало дел в списке задач. Проблемы Spanning Tree с Sonos не такие уж и таинственные. Для любого свитча нужно знать, участвует ли он в Spanning Tree, и если нет или если он отключен, пропускает ли он BPDUs, которые устройства Spanning Tree нуждаются для управления мешем (деревом)? Если свитч не участвует в STP и при этом пропускает BPDUs, можно подключать сколько угодно Sonos устройств к Ethernet. Распространённая рекомендация на множестве форумов – использовать неадминистрируемые свитчи с Sonos, поскольку они, как правило, не участвуют в STP и, как правило, пропускают BPDUs, хотя, конечно, были и исключения. Если свитч участвует в STP, он должен пропускать BPDUs. Для этих свитчей и более крупных Sonos установок я обычно делаю центральный свитч STP корневым мостом, снижая приоритет моста (4096), чтобы моё сетевое оборудование управляло Spanning Tree, но вполне возможно просто позволить одному из Sonos устройств быть корневым мостом, особенно если Sonos – единственное устройство, использующее STP в сети. Кроме того, если Sonos установка имеет хорошее Wi-Fi соединение, можно использовать только беспроводное подключение. Для любой коммутируемой сети, которая не пропускает BPDUs, используйте Sonos полностью по беспроводной сети или подключайте только одно Sonos устройство к Ethernet. Как только вы подключите второе Sonos устройство (или любое другое устройство, использующее STP), вы рискуете получить сетевые циклы, поскольку устройства не видят свитч как резервное соединение и оставят его в состоянии пересылки. В Wireshark можно увидеть BPDUs, отфильтровав по STP.
 
Спасибо, что продолжаешь добавлять детали. Очень помогло.
 
Чтобы вернуться к этой теме: оказалось, моя проблема была в прошивке версии 6.2.14. Модели US-8 и US-8-60W плохо отреагировали на эту версию, и это стало постепенно известно в сообществе. Поэтому UI посоветовали обновить эти устройства до бета-версии прошивки. Это действительно позволило вывести коммутаторы из режима высокого использования CPU и цикла перезагрузок. Даже с этой новой бета-прошивкой, они все еще периодически показывают нелепо высокие проценты использования CPU, даже когда коммутаторы простаивают и практически ничего не делают. Когда они вообще не загружены.

По крайней мере, сейчас, с бета-прошивкой, они только колеблются в диапазоне 5-15% CPU. На 6.2.14 они постоянно показывали 40-60%, просто так, без причины. Это была просто ошибка прошивки, которая почему-то плохо работала с этими моделями коммутаторов.

После этого я особо не мог анализировать проблемы STP, потому что сделал Sonos устройствами, о которых идет речь, беспроводными на коммутаторе, который я тогда считал "проблемным". Так что на самом деле, настройка была простой и понятной, но просто попала под неофициально не объявленную ошибку прошивки. Поэтому сейчас сложно понять, что к чему, потому что было потрачено много времени на попытки этого и того. А на самом деле, корневой причиной была плохая сборка программного обеспечения. Это сделало большую часть предыдущей диагностики и предположений бесполезными, к сожалению.

Теперь мне придётся снова подключить Sonos оборудование по проводу, чтобы посмотреть, что произойдёт. Но мне кажется, что даже бета-версия прошивки не полностью устранила проблемы с этими моделями коммутаторов. Благодарю за то, что она решила их достаточно, чтобы сейчас они перестали быть проблемой.

Я обнаружил, что единственный способ, чтобы у меня не было проблем с Sonos – это если всё подключено по проводу или всё работает по беспроводной сети. Если сделать комбинацию из того и другого, то всё может быть чем угодно, и они будут вызывать всякую непоследовательную чепуху в твоей сети.
 
Запусти top и выложи результат сюда. Блок кода сделает это легче читать.
 
Кажется, что для запуска цикла перезагрузки достаточно уже 40-50%. Примерно там и держится. Как только значение падает к 50%, он перезагружает устройство. Цикл перезагрузки около 3 минут.
 
Снова случился огромный скачок:
 
Ты тоже прав, все остальные 8-портовые коммутаторы, которые я удаленно просматриваю с клиентских сайтов, все время показывают совершенно ровные значения. Никаких скачков. А вот эти трое — все скачут. Один, очевидно, гораздо хуже двух других.
 
Учитывая сжатые сроки, эти короткие всплески означают серьезное кратковременное использование ЦП. Если бы вы увеличили масштаб, то они, вероятно, показывали бы 100% на протяжении нескольких секунд или даже минут.
 
Ну, судя по твоим словам, @gregorio, несмотря на то, что другие 2 модуля USC-8 за последние 24 часа намного спокойнее того проблемного USC-8, их поведение всё равно какое-то нестабильное? Ну, они же вроде бы и не на "прямой линии", верно?
 
Что ещё безумнее, так это насколько стабилен основной коммутатор. Почти как на кардиограмме, как ты и говорил. Единственный небольшой скачок произошёл, когда я вчера вечером переключил настройки с STP на RTSP. Все 3 @ USC-8 работают от этого коммутатора, и он спокоен, тих и собран, питает все точки доступа и ещё к нему по кабелю подключен Sonos Amp с изоляцией портов. Этот коммутатор просто как огурец..................
 
По поводу проблем с US-8: единственное, что с него тянет данные – это старый Apple TV, подключенный по проводу. В двух других настройках US-8 тоже есть Apple TV той же модели, подключенный по проводу, но они были совершенно новые. Интересно, может быть, дело в сетевом порте именно этого старого Apple TV, и лучше бы его заменить или просто подключить по Wi-Fi?
 
Ох, смотри-ка, показатели среднего значения нагрузки на проблемном US-8 в 8-10 раз выше, чем на остальных двух серверах...
 
График должен быть более плавной линией. Можешь ли ты запустить `top` и посмотреть, что там пожирает процессор?
 
Вот что безумное: Unifi до сих пор говорит, что Sonos подключен к US-8 в подвале, хотя это 100% не так. Сейчас всё работает по Wi-Fi.
 
В общем, ничего особенного, если не считать сумасшедший пинг прошлой ночью. Однако, она сейчас тоже не тянет никакой информации. Но в истории всё ещё постоянно наблюдаются небольшие подъемы и спады: Кстати, в 11 вечера я переключил всё с STP на RTSP, и посмотрите на статистику сейчас от не проблемных USC-8's: Статистика на "проблемном" устройстве в настройке в главной спальне, очевидно, намного выше, чем у остальных двух.
 
Какие показатели памяти и ЦП?
 
Сказал как дурак! Тот самый USC-8, который дольше всего отлаживается, опять перезагружается. Остальные же уже давно не перезагружаются. Может, он просто бракованный USC-8? Могла ли одна новая, сразу из коробки, неисправная машина просто устроить этот бардак и головную боль? Хаха. Оставайтесь на связи, Бэт-фанаты! 😀 😂 🤣
 
Тут вообще никакой логики и смысла в том, что происходило, пока все это не стабилизировалось сегодня внезапно. Я переключил все переключатели на дефолтные RTSP, так как к ним больше нет подключенных Sonos. Кроме Sonos Amp, подключенного к основному переключателю. Его порт я просто изолировал для программирования по кругу. Теперь вроде все хорошо и стабильно, по крайней мере, пока что. Хотя я и знаю, что это ничего не значит. Надо понаблюдать пару дней.

После того, как я прогнал отладочный пинг на всех 3 @ US-8 переключателях, выяснилось, что все они модели USC-8. Это заставило меня прогнать отладочный пинг на всех клиентских сайтах с "US-8'ами", и там тоже ВСЕ USC-8 модели. Значит, обычные US-8 они не выпускали уже давно, потому что многие из этих устройств на клиентских сайтах были развернуты 3-4 года назад.

Когда я смотрю здесь, в сообществе, мне неясно, почему USC-8 — это менее производительная модель, чем US-8. Кроме того, насколько я слышал, что это действительно так. Хотя, судя по постам в сообществе, USC-8, похоже, не справляются с STP/RTSP корректно, даже когда настройки верные?
Страницы: 1 2 След.
Читают тему (гостей: 1)