Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Бедный Pro Max, 24-слойная маршрутизация производительность хромает., wifiman
 
Недавно я "апгрейднул" свою сеть, заменив Cisco SG350 на UniFi Pro Max 24 PoE в качестве основного коммутатора, который обрабатывает Layer 3 маршрутизацию (чтобы разгрузить мой роутер). У меня уже были UniFI точки доступа и несколько вспомогательных UniFi коммутаторов (Enterprise 8 PoE на моем столе и Mini за телевизором), поэтому я хотел консолидировать остальную часть сети в единый UI для управления. Вот упрощенный вид того, как выглядит моя сеть сейчас (надеюсь, вы сможете прочитать мой почерк). Я запускаю саморазмещенный UniFi контроллер, который в целом себя хорошо ведет. С тех пор как я установил Pro Max 24 PoE, у меня возникли периодические проблемы с производительностью любого трафика, который должен проходить через Layer 3 маршруты в коммутаторе Pro Max 24 PoE. Из-за соображений изоляции управления (которые, вероятно, излишние, но что поделать) у меня есть несколько немаршрутизированных VLAN, на которых находится мой Mac Mini с коммутаторами, но они недоступны, если вы не подключены напрямую к порту, поддерживающему этот VLAN. Когда я провожу тест скорости по этой управляющей VLAN к Plex серверу или UniFi контроллеру (то есть все коммутаторы выполняют только Layer 2 коммутацию), он постоянно насыщает самый медленный линк (обычно 1Gbps) в пути. Когда я провожу тот же тест, по тем же физическим проводам, но через маршрут, проходящий через Layer 3 маршрутизацию основного коммутатора (VLAN 6 в VLAN 31 в данном случае), я получаю нелепо низкие скорости, обычно <1Mbps. Это не совсем стабильно, иногда он работает как ожидалось, но не надежно. У меня также есть проблемы с веб-сайтами через интернет, хотя иногда эти проблемы касаются только одного устройства и не других (в основном WiFi, но не проводной). Другие действия по устранению неполадок, которые я предпринял, включают просмотр журналов UniFi Controller, но они, похоже, не указывают на какие-либо проблемы. Я также запустил Wireshark на компьютере во время его медленной работы с некоторыми трафиками и увидел, по-видимому, довольно большое количество TCP Dup Ack, TCP Retransmit и некоторые другие пакеты ошибок TCP. Я не думаю, что у меня есть какая-либо необычная топология, и она хорошо работала, когда я использовал коммутатор Cisco, что заставляет меня думать, что это связано с самим коммутатором UniFi. Поиск в основном выявил жалобы на функции Layer 3, а не на производительность, поэтому я не могу сказать, является ли это распространенной вещью или нет. Однако мне кажется, что если бы это была распространенная проблема, Layer 3 был бы совершенно непригоден для использования, и я вижу отчеты о других, более конкретных проблемах, поэтому люди его используют?
 
С Layer 3 Switching есть больше проблем, чем те, что были указаны. Скорее всего, вам придется использовать конфигурацию "Router on a Stick". На каком оборудовании у вас установлен OPNsense?
 
Также 56 часов — это почти 2.5 дня, что является очень специфично важным периодом времени. Если у вас есть счетчик миллисекунд или микросекунд в аппаратной части или коде, то, скорее всего, именно в этот момент произойдет переполнение знакового 32-битного целого числа.
 
@andne ты продвинулся в этом вопросе? У меня похожая проблема. Дело не в том, что устройство замедляется, а в том, что оно вообще перестает работать. У меня точно такие же ошибки в логах f028 на Pro Max 16 PoE, которые, кажется, происходят примерно каждые 2.5 дня. Устройства в основной vlan не могут видеть устройства в vlan, размещенном на Pro Max 16, и наоборот. Перезагрузка коммутатора или повторное применение настроек через консоль, после чего устройство работает снова в течение 2.5 дня, прежде чем проблема повторяется.
 
У меня открыт тикет, и вчера вечером получил ответ, что они передали сообщение об ошибке в инженерный отдел, так что надеюсь, они смогут что-нибудь сделать. Теперь просто жду от них дальнейших ответов по этому вопросу.
 
@andne Я прекрасно понимал, что Layer 3 Switches не будут полностью функциональны, но опубликовал результаты сравнения CPU/SoC по PassMark, чтобы дать тебе ориентир, если ты выберешь топологию "Router on a Stick". Это было не для сравнения Layer 3 Routing и Layer 3 Switching. Вижу, что ты продолжаешь тестировать Layer 3 Switch, может, стоит проверить наличие утечек DNS между VLAN'ами и посмотреть, добавлена ли поддержка mDNS. Но в целом, топология "Router on a stick" - это экономичное решение для небольших сетей.
 
Не совсем так, моя система работает нормально после перезагрузки, но затем начинает выдавать проблемы спустя какое-то время (насколько я помню, около 56 часов работы, как минимум, когда появляется упоминавшееся ранее сообщение в логах, если это связано). Никаких изменений в конфигурации при этом не вносилось. Следующая перезагрузка (когда я делаю это, нужно быть осторожным и убедиться, что сеть достаточно спокойна, чтобы не вызвать серьезных сбоев) снова решает проблему на время.
 
Четырехядерный Atom C3000 серии (точно модель сейчас не вспомню). Понятно, что раньше, когда я тестировал производительность маршрутизатора «router on a stick», у меня был двухядерный Atom D525, так что скорее всего, более новый чип будет работать лучше. Или, предположим, я могу вернуть Cisco-коммутатор между ними, так как знаю, что он как минимум неплохо справляется – в любом случае, я реализую топологию типа «router on a stick».

Я провёл ещё немного тестов, и не все проводные клиенты работают одинаково хорошо, а WiFi определённо испытывает серьёзные проблемы с производительностью. Я отслеживаю трафик между двумя узлами на разных VLAN (Mac Mini к Plex) и вижу, где теряются пакеты. Mac Mini отправляет повторные передачи, а Plex-сервер получает только один пакет. Судя по всему, пакет всё же доходит после третьей повторной передачи. Сложно проанализировать каждую передачу пакетов, но такое поведение встречается несколько раз в коротком (<20 секунд) логе.

В общем, я просто поражён, что поведение устройств на уровне L3 может быть настолько плохим, учитывая, что я вижу информацию о том, что их используют в крупных развёртываниях. Моё понимание в том, что разгрузка маршрутизации L3 VLAN на коммутатор — распространённая топология, поэтому я бы ожидал, что базовые аспекты пересылки пакетов между VLAN (которые, как я думаю, просто требуют обновления заголовка MAC-адреса и тега VLAN) будут работать надежно, даже если более продвинутые функции, такие как ACL, специфичные для порта, или BGP, не поддерживаются.
 
Возможно, это как-то связано. Я заметил это ещё некоторое время назад, но не придал этому значения, и снова заметил сегодня, когда проблема возобновилась после перезагрузки коммутатора в воскресенье. Примерно с 56 часов непрерывной работы начали появляться многочисленные ошибки ядра, следующие (и они продолжаются до сих пор):
[202370.910000] unknown rt error code f028
[202370.940000] unknown rt error code f028
[202702.970000] unknown rt error code f028
[202724.320000] unknown rt error code f028
[202747.220000] unknown rt error code f028
[202801.120000] unknown rt error code f028
[203337.930000] unknown rt error code f028
[203370.300000] unknown rt error code f028
...
[267294.110000] unknown rt error code f028
[267298.600000] unknown rt error code f028
[267318.060000] unknown rt error code f028
[267333.020000] unknown rt error code f028
[267397.600000] unknown rt error code f028
[267422.660000] unknown rt error code f028
[267461.600000] unknown rt error code f028
[267466.870000] unknown rt error code f028
Подключаясь удаленно к другим коммутаторам, которые работают значительно дольше, я не вижу подобных сообщений, не говоря уже об их количестве. Может, это связано с моей проблемой? У меня открыт тикет в Ubiquity, куда я добавил ту же информацию. Может, они смогут что-то определить по этому и придумать программный патч (или скажут, что это известный признак аппаратной неисправности)?
 
Согласен, это попытка сравнить программное решение маршрутизатора с управляющим процессором, который не должен находиться в пути данных для маршрутизации уровня 3 на коммутаторе, поскольку это, как ожидается, выполняется исключительно в ASIC коммутатора (поэтому он обычно работает на скоростях, близких к скорости линии связи). По крайней мере, именно так поступают все остальные производители коммутаторов.

Возможно, мой программный маршрутизатор действительно обладает достаточной производительностью для маршрутизации пакетов на скорости гигабита, признаю, я не тестировал его после перехода с системы на базе D525 на серию C3000. Или, возможно, оборудование UDM было бы хорошей заменой там и могло бы сделать все правильно для выгрузки по сравнению с маршрутизацией, чтобы поддерживать скорость (поскольку некоторые из них имеют интегрированный коммутатор), но я пока избегал продуктов Ubiquiti, поскольку то, что я вижу из интерфейса для них в программном обеспечении контроллера, не дает мне той гибкости настройки, которой я в настоящее время пользуюсь в OPNsense.
 
Свитч предоставляет VLAN 6 как немаркированный на этом порту, все остальные VLAN-ы маркируются свитчем, а у Mac Mini есть виртуальные интерфейсы для обработки этого трафика. Так что VLAN 1331 — это виртуальный интерфейс, VLAN 6 (маршрут, который он использует для достижения VLAN 31) — это физический интерфейс. Затем Enterprise 8 PoE маркирует трафик VLAN 6 и отправляет весь трафик на Pro Max 24 PoE как трафик с маркировкой VLAN (без VLAN по умолчанию на этих портах). Да, я могу получить такую пропускную способность, но потом у меня бывают периоды, когда я её не могу получить, или только некоторые устройства могут её получить (что ещё больше не имеет смысла). Перезагрузка свитча с Layer 3 конфигурацией, похоже, улучшает ситуацию на день-два, что почти наверняка означает, что это не проблема оборудования, а что-то странное происходит в программном обеспечении? Даже это кажется очень странным (и очень устранимым с помощью обновления прошивки).
 
Более длинный тест, тоже хорошо:
 
Привет @andne, заинтересовался этим и быстро провел лабораторный тест. Мини-ПК на базе SFP+ N100 с двумя Linux VM. SFP+ порты отображены 1:1 к VM. Оба подключены к USW Pro Aggregation, у которого есть одно 10G соединение с моим USW Pro Max 24 PoE. Создал две L3 сети со свитчем в качестве шлюза: Тест iperf3 из VM в VM через USW Pro Agg, маршрутизируемый USW Pro Max 24 PoE:
 
Сравнивать энергопотребление управляющего CPU в SoC, которые могут использовать аппаратное ускорение сети, с программными маршрутизаторами – это вообще имеет смысл?
 
Сравнительный анализ производительности CPU/SoC из базы данных PassMark CPU здесь. Когда найдёшь точный процессор Intel Atom C300, добавь его и сделай сравнительный анализ.

Ubiquiti UXG/UCG Max/Ultra: Qualcomm Quad-core ARM® Cortex®-A53 на 1.5 GHz
Ubiquiti UDM-P: Amazon Quad-core ARM® Cortex®-A57 на 1.7 GHz
Сторонний AMD Ryzen Embedded V1500B Quad-core @ 2.20GHz
 
Если бы у меня были проблемы с работой каких-либо функций, я бы с тобой согласился. Однако, сеть работает, просто часто с пониженной производительностью. Включение flow control, похоже, улучшило ситуацию для одной VLAN (только проводные клиенты), но меньше – для другой (смесь проводных и беспроводных клиентов).

Насчет конкретных ссылок, которые ты прислал, мне не нужно определять статические маршруты, потому что все маршруты уже известны сети UniFi (хотя мне пришлось определить некоторые статические маршруты в моем роутере, и они работают нормально), и я уверен, что ограниченная поддержка ACLs будет для меня вполне достаточной, так как на моем Cisco свитче тоже были не особо сложные ACLs, только базовая фильтрация IP, которая предотвращает перекрестные разговоры между клиентскими VLANs, но позволяет им обоим общаться с VLAN сервера (поэтому у меня 3 основные VLANs).
 
Не могу поверить, что это возможно, ведь коммутаторы Ubiquiti Layer 3 на самом деле не полностью функциональные Layer 3 коммутаторы. Вам придется развернуть их как Layer 2 коммутаторы.https://community.ui.com/questions/Layer-3-Switch-Static-Routes-do-NOT-work/5f7e98ac-745c-4437-b74c-cefe5630deaahttps://community.ui.com/questions/Deploy-one-way-isolation-VLAN-with-UniFi-Layer-3-Switches-and-ACL-Rules/b42f3c6a-4483-437f-a630-86f2652c03d5
 
Если не запускать FC, это может привести к переполнению буфера, из-за чего пакеты просто отбрасываются при передаче больших объемов данных. Возможно, именно это ты и видишь.
 
Связи между коммутаторами имеют более высокую пропускную способность (сейчас 2,5 Гбит/с, планируется в конечном итоге довести до 10 Гбит/с, когда я приобрету соответствующее оборудование), но соединение с Mac Mini всё ещё 1 Гбит/с. Кстати, это могло бы объяснить, почему Wi-Fi работает с наибольшими проблемами, раз точки доступа работают со скоростью 1 Гбит/с к коммутатору, а коммутатор — со скоростью 1 Гбит/с к роутеру (т.е. нет многогигабитных соединений на пути). Сначала я думал, что у меня может быть проблема с качеством сигнала на многогигабитных соединениях, поскольку они были новые и эти порты были принудительно ограничены до 1 Гбит/с, но после тестирования и получения полной скорости 1 Гбит/с через VLAN 1331 независимо от этих настроек (и отсутствия улучшений в других местах) я перестал двигаться в этом направлении и позволил портам автоматически договариваться о скорости, как они обычно это делают. В общем, я включил глобально управление потоком (ранее было выключено) и посмотрю, смогу ли я повторить некоторые тесты с ним.
 
Вы используете какие-то порты с пропускной способностью выше 1 Гбит/с? Возможно, проблема в Flow Control. Убедитесь, что он включен на всех коммутаторах, если вы используете такие порты.
Страницы: 1
Читают тему (гостей: 1)