Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Критическое падение пропускной способности UDP на UDM Pro (узкое место на CPU подтверждено), UniFi Network
 
Привет всем, я опубликовываю это, чтобы задокументировать проблему, с которой я разбираюсь уже несколько дней — крайне низкая производительность UDP на UDM Pro. После тщательного тестирования я уверен, что причина в CPU-bound NAT/UDP обработке в firmware 4.0.x–4.4.x. Этот пост включает все тесты, которые я провел, на случай если другие смогут воспроизвести проблему.

Конфигурация железа:
UDM Pro (firmware 4.4.6 на момент тестирования)
UniFi 48-port PoE switch (USW-Pro-48 PoE) через SFP+ uplink
Несколько VLAN, без IDS/IPS, без Smart Queues, без DPI
Все функции безопасности отключены во время тестов
WAN: 1 Гбит/с симметричная оптика
LAN тесты: прямой путь 10G через SFP+

Краткое описание симптомов:
TCP работает нормально — я получаю полную скорость TCP (≈950 Мбит/с) в обе стороны.
UDP критически деградирует — при тестах iperf3 UDP пропускная способность падает до ~300–350 Мбит/с с огромными потерями пакетов.
CPU скачет на 100% на одном ядре во время операций UDP/NAT.
Это явно указывает на то, что offload не работает для UDP в текущей firmware.

Команда тестирования (reverse UDP):
iperf3 -4c [server] -u -b 1G -R --bind [LAN_IP] -t 120 --dont-fragment

[ 5] 0.00-1.00 sec 40.1 MBytes 336 Mbits/sec 0.043 ms 54719/88985 (61%)
[ 5] 1.00-2.00 sec 39.6 MBytes 332 Mbits/sec 0.041 ms 53112/87302 (60%)

Наблюдаемое поведение:
Пропускная способность UDP остается в районе 300–350 Мбит/с.
Потери пакетов около 50–60%.
Всплески задержки.
CPU на UDM Pro прыгает на 100% на одном ядре, стабильно.
TCP сразу после этого возвращается к 950 Мбит/с без проблем.

Изменение IP-адреса bind, VLAN, портов, SFP+ vs RJ45 или WAN IPv4 vs IPv6 никаких результатов не дало.

Дополнительные тесты:
1. Отключил все в разделе "Security"
  IPS/IDS off
  Threat detection off
  Geo-blocking off
  Signature updates off
  Traffic identification off
  → Никаких изменений.

2. Пробовал SFP+ → RJ45 модуль и прямой RJ45
  Никакой разницы.

3. Пробовал IPv4 vs IPv6
  Небольшое улучшение.

4. Пробовал LAN-only UDP тесты
  LAN → LAN UDP маршрутизация также ограничена в том же диапазоне 300–350 Мбит/с при маршрутизации через UDM Pro. Прямая коммутация на уровне L2 достигает полной скорости.

5. Пробовал WireGuard клиент на Windows, сначала через UDM — скорость ограничена, потом напрямую без UDM — получил ожидаемую скорость.

Выводы:
Все указывает на то, что на firmware 4.3.x–4.4.x UDM Pro:
Не аппаратно-ускоряет UDP NAT/маршрутизацию должным образом → что заставляет CPU максимизироваться → что жестко ограничивает пропускную способность UDP до ~300–350 Мбит/с → с огромными потерями пакетов.
TCP не затронут, потому что аппаратное ускорение работает для TCP.

Это согласуется с сообщениями сообщества о том, что ветка firmware 4.3–4.4 сломала аппаратное ускорение, особенно для WireGuard и высокоскоростных UDP потоков.

Просьба:
Может ли Ubiquiti, пожалуйста:
Подтвердить, сломано ли UDP/NAT ускорение на UDM Pro в firmware 4.0–4.4.
Предоставить информацию по поводу:
планируется ли исправление
намеренно ли отключено ускорение
есть ли обходные пути кроме downgrade firmware.

Рад предоставить больше данных.

Если команде UniFi нужны:
полные логи iperf
pcap файлы
графики CPU
support файлы

Я могу все это предоставить.

Спасибо.
 
Привет, у меня была точно такая же проблема с UDM SE. 800-900 Мбит/с при CPU core на максимум (100%), когда я делал передачу данных через туннель Wireguard на симметричном интернете 8 Гбит/с. Перед тем как ты спросишь, сервер Wireguard был на другой машине, способной пропускать минимум 7 Гбит/с внутри туннеля. Я избавился от UDM SE и вернулся на виртуализированный маршрутизатор. Я мог бы взять Cloud Fiber Gateway, но я больше не доверяю маршрутизаторам Unifi.
 
Я углубился в эту проблему после своего предыдущего поста. Оказывается, это известная проблема уже много лет, но Ubiquiti так и не дал на неё нормального ответа. Вот тред с пять лет назад с точно такими же симптомами и ещё один с трёх лет назад. По моему мнению, реальность такова: в UDM Pro просто нет аппаратного разгрузки UDP, но я был бы рад, если бы @UI-Team меня исправил, если я не прав. Вы можете проверить это сами, запустив ethtool -k ethX на вашем WAN порту и посмотрев rx-udp_tunnel-port-offload: off [fixed]

root@Dream-Machine-Pro:~# ethtool -k eth9
Features for eth9:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: on
tx-checksum-ip-generic: off [fixed]
tx-checksum-ipv6: on
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: on
tx-tcp-mangleid-segmentation: off
tx-tcp6-segmentation: on
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on [fixed]
tx-vlan-offload: off [fixed]
ntuple-filters: on
receive-hashing: on
highdma: on
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-ipxip4-segmentation: off [fixed]
tx-ipxip6-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-gso-partial: off [fixed]
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
tx-udp-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: off [fixed]
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]
tls-hw-tx-offload: off [fixed]
tls-hw-rx-offload: off [fixed]
rx-gro-hw: off [fixed]
tls-hw-record: off [fixed]

Мне удалось получить более-менее рабочее решение, отключив все правила QoS, но меня поражает, что мы получаем софт настолько требовательный к железу, что приходится отключать функции, чтобы обеспечить стабильность. По моему, если не переходить на что-то вроде UCG Fiber, то это то, с чем нам придётся мириться.
 
Мы столкнулись с той же проблемой. Прямо сейчас устанавливаем Aspera вместе с техниками IBM, а прочитать это было очень разочаровывающе. Нужно срочно это исправить.
 
Я вижу то же самое. С отключёнными IPS, блокировками по странам и прочим, у меня 100% использование одного ядра процессора и видны потери пакетов во время тестов. Достигаю примерно 700 Мбит на UDP. TCP достигает linereate3 на 930 Мбит без явной разницы в нагрузке на CPU.
 
Вот я и добавлю свой голос — два года пытаюсь разобраться с этой проблемой, и мне удалось воспроизвести её на своём UDM Pro. Я рад, что похоже наконец-то найдено решение.
 
Есть ли какие-нибудь новости по этому поводу? У нас есть Unifi Dream Machine SE (и Pro), и обе испытывают одинаковые проблемы. Мне пришлось ограничить скорость портов на 2 машинах до 100 Мбит/с, иначе маршрутизатор(ы) падали при использовании Aspera, например. Это действительно противный баг, который бьёт по двум (крупным) производственным площадкам.
 
Я заметил, что скорости передачи данных через Media Shuttle были серьёзно ограничены. Media Shuttle замедляет передачу, когда теряется слишком много пакетов. Я попросил команду поддержки Signiant (Media Shuttle) повторить ваше тестирование шаг за шагом на моём UDM SE. Я получаю точно такие же результаты. Надеюсь, это будет исправлено в следующем обновлении. Мои клиенты недовольны скоростями передачи. @UI-Team Это известная проблема?
 
Могу подтвердить, что последняя версия 5.0.12 не решает эту проблему. Внутри моей сети я получаю примерно 4 Гбит/с пропускной способности UDP при нагрузке на процессор около 20%, но через WAN это прыгает до 100% на одном ядре, и я получаю более 45% потери пакетов выше 300 Мбит/с.
 
Следю за этим, так как у меня такая же проблема!
 
Столкнулся с теми же проблемами на UDM SE, работает Unifi OS 4.4.6. @Beregor, ты когда-нибудь проверял Early access и какие-нибудь из релизов 5.0.X, чтобы узнать, решают ли они эту проблему?
 
Это серьёзная проблема ещё со времён USG-4 Pro. Я докладывал об этой проблеме, но они ничего с ней не делали. Похоже, им плевать, что UDP-трафик маршрутизируется на WAN-порты.
 
Уже несколько недель пытаюсь это исправить, после того как заметил, что не получаю нормальные скорости. Все внутренние устройства общаются с нормальной скоростью 1G, но как только выхожу за пределы WAN, скорость падает как у всех. Перепробовал всё возможное, чтобы это исправить, даже запускал iPerf прямо с самого шлюза. Нужно срочно это решить. Люблю Unifi, но ненавижу этот баг.
 
Давно мучаюсь с похожей проблемой на UDM Pro Max. @UI-Team обратите внимание на это и выпустите обновление!
Страницы: 1
Читают тему (гостей: 1)