@corbyatkingsway, похоже, у вас проблема с CPU (в смысле, вы исчерпываете ресурсы процессора). Вопрос в том, почему. Похоже, использование CPU в обеденное время примерно в пределах нормы — около 20%. Работает сетевое приложение, управление AP и коммутаторами. Для вашей конфигурации это выглядит вполне разумно. Увеличение связано с ростом трафика пользователей (ну да, спасибо, доктор Очевидность). Так что давайте подробнее рассмотрим вашу конфигурацию. Вы упоминали две SFP+ LAN-связи, этого делать не стоит. Лучше использовать одну SFP+ связь с агрегационным коммутатором. —примечание… нет, не используйте все встроенные 8 портов вообще. Это только вызовет проблемы.

Можете рассказать подробнее о вашей конфигурации? Сколько VLAN? Насколько велики подсети /24? /16? Как организована маршрутизация между ними? Множество правил межсетевого экрана на уровне VLAN? Правила трафика / фильтры / блокировки по приложениям или категориям? Я копаю в том, что все эти мелочи используют CPU для работы.

Например, в почте, когда вы блокируете адрес из-за спама, каждое новое сообщение нужно сравнивать со списком заблокированных адресов. Чем больше вы добавляете, тем больше мощности требуется для сравнения. Может быть (я не знаю), у вас настроено много вещей, которые нагружают CPU?

У вас есть двойной WAN? (это также использует CPU/RAM).

Как я уже упоминал (и деньги — это не бесплатные вещи), для решения этой проблемы придется что-то потратить. Вы можете попробовать настроить VM и перенести управление сетью на нее (VM тоже "что-то" стоят, даже если у вас есть локальный хост). Это также будет стоить вам в виде сложности и времени на выполнение самых простых задач. Замена оборудования на более мощное устройство UniFi будет стоить, переход на сторонний маршрутизатор тоже будет стоить. Так что вопрос в том, если вы не сможете контролировать использование CPU, куда уходят ваши деньги.

Вы можете продать uxg-pro и udmp-max и покрыть часть расходов.

Лично я бы рассмотрел Federation Gateway. Да, это стоит немало денег. Даже если вы сможете снизить текущее использование CPU на 15%, я уверен, что со временем вы будете добавлять пользователей, оборудование, функции, и все вернется к этому снова.

Дома я использовал UXG-Pro с саморазвернутым сетевым приложением И UDMP. Все работало идеально. Так что я уверен, что вы сможете все настроить, независимо от того, что вы решите. Но усложнение (как я делал… но у меня были причины) не дешевле, если учесть стоимость управления/сложности и т.д.

Я заменил все это на pro-max, чтобы упростить. Это мягкая экономия стоила затрат на оборудование (и я избавился от кучи ненужного оборудования).

Давайте углубимся в ваши конкретные настройки конфигурации.

@acebmxer В последнее время нет. Раньше да. Говорят, нужно отключать некоторые функции, например, идентификацию трафика или частоту обновления веб-интерфейса. В принципе, я считаю, что мне этого не должно быть нужно делать. Может, маркетинговые спецификации нужно сделать более конкретными, или предложить ссылку на "эти спецификации/результаты при этих условиях: количество VLAN, количество SSID, IDS/IPS включены/выключены и т.д.". Их калькулятор предполагает 10 клиентов на точку доступа, ну, они что-то должны предполагать, а значит, если у меня 65 точек доступа, это 650 клиентов, что в моем случае получается верно, но распределение очень разное. У меня будет 50 клиентов на точку доступа в этом здании с 4 точками, 40/точка в этом здании, может быть 10 на этих точках на этой части кампуса. Калькулятор также не учитывает коммутаторы, что, возможно, не имеет значения, не уверен. В общем, хотел сказать, что в прошлом служба поддержки UI (для меня она была отличной, когда была реальная проблема) не будет считать это проблемой как таковой. Если они захотят, и один из них наткнулся на этот пост, потому что он был отмечен ранее, я был бы рад помочь.

@kanewolf Ок, вижу. Очень мало трафика между VLAN, практически весь трафик VLAN идёт к шлюзу. Возможно, стоит ещё раз рассмотреть возможность переложить маршрутизацию VLAN на коммутаторы, которые смогут это обработать и где физически имеет смысл изолировать.

Что я и пытался сказать, так это то, что если у тебя два коммутатора подключены к UDMP через DAC, то трафик между ними должен проходить через ЦП UDMP. Возможно, переход с USW-Aggregation на USW-Pro-Aggregation, который может переложить маршрутизацию L3 между твоими VLAN, поможет снизить нагрузку на ЦП UDMP. Это будет зависеть от объема трафика между VLAN.

Если у вас WAN 1GE, используете ли вы два порта 10GE для LAN? Если да, то весь трафик проходит через CPU UDMP. L3 агрегирующий коммутатор потенциально может решить эту проблему.

У нас тут обед, поэтому трафик немного снизился, но это обычная картина по будням. Хотя, надо сказать, экран долго грузился, чтобы этот скрин сделать.

К слову, за последние 30 минут с тех пор, как я выключил Traffic ID, загрузка CPU, как описано выше в top, вообще не изменилась. Но опять время обеда, и объем трафика значительно снизился, как и загрузка CPU в GUI. В top Java и Suricata все еще скачут от 50% до 100+%. Если задуматься, я не очень хорошо знаю top, поэтому не знаю, показывает ли он общую загрузку всех ядер или как это отображается. Но GUI не соответствует данным top. Когда объем трафика снизился, GUI стал работать гораздо быстрее. Возможно, попробую подключиться к GUI напрямую, а не через Site Manager, просто для оценки отзывчивости.

Похоже, проблема в том, сколько CPU «съедает» сетевое приложение, а не IPS/IDS. Это не самый удобный способ получить информацию, но пробовали ли вы запустить `top` в активной SSH-сессии на шлюзе и посмотреть, что потребляет ресурсы? Если выяснится, что сетевое приложение использует большую часть CPU, то перенос его на другой сервер, скорее всего, решит проблемы на шлюзе. Вы упомянули, что оно работает в VM (довольно большой, кстати), и через неделю у вас начинаются проблемы. Два вопроса по этому поводу: (1) какие конкретно проблемы возникали, и (2) оставалась ли хорошей производительность интернета? Если виновато сетевое приложение, то его лучше перенести на отдельный выделенный сервер (на PC-железе или на CloudKey Enterprise). Если же сетевое приложение не основная причина нагрузки на CPU на шлюзе, то стоит задуматься о более мощном шлюзе (EFG) или не-UniFi-маршрутизаторе.

@corbyatkingsway вот ссылка на fedex и Fortress: https://www.youtube.com/watch?v=mOl1wzDSM0k