[Запрос на исправление ошибки] Опция DHCP 82 на hEX S по умолчанию не отключает HW-Forward, RouterOS
RcRaCk2k
Guest
0
09.03.2025 19:32:00
Привет! При включении DHCP-Option 82 на hEX S все подключённые порты в этом бридже теряют аппаратное ускорение, и скорость падает примерно до 380 Мбит/с. Моя конфигурация: bridge1 -> порты: sfp1 (trusted yes) ether1 (trusted no) Всё работает нормально, но как только включаешь DHCP-Option 82 — сразу проседает производительность. При этом устройству не нужно передавать DHCP-пакеты, поступающие на sfp1, на CPU, только пакеты, идущие на ether1, должны быть перенаправлены на CPU внутри Switch-Chip. Значит, включение DHCP-Option 82 не должно влиять на производительность бриджа.
RcRaCk2k
Guest
0
25.03.2025 20:14:00
Спасибо за подсказку по той матрице. Есть ли какая-нибудь матрица, где можно посмотреть, в каких устройствах Mikrotik установлены какие Switch-Chip? Я ищу переключатели 88E6393X, 88E6191X, 88E6190.
NathanA
Guest
0
25.03.2025 20:27:00
Ниже таблицы характеристик переключающих чипов вы можете увидеть список продуктов, в которых используется каждая модель переключающего чипа, а также какие конкретные интерфейсы/порты подключены к этим чипам.
CGGXANNX
Guest
0
25.03.2025 20:37:00
Также обратите внимание, что для устройств с этим сетевым чипом (RB5009, CCR2004-16G-2S+, L009), хотя включение DHCP Snooping сохраняет аппаратное ускорение на мосту, оно делает fast path на мосту неработоспособным и влияет на fasttrack. Если у вас есть WAN-порт вне моста, то fasttrack будет работать для соединений между WAN-портом и интерфейсами на мосту (включая VLAN), но и fast path, и fasttrack будут неэффективны для трафика между участниками моста (например, для трафика между VLAN). У меня есть личный опыт с этой проблемой. Документация недавно обновлена и теперь это упоминается: Включение функции DHCP snooping отключит fast path на мосту, что в свою очередь повлияет на возможность fasttrack для соединений через этот мост.
lurker888
Guest
0
25.03.2025 20:51:00
Но было бы очень здорово, если бы это реализовали.
RcRaCk2k
Guest
0
31.03.2025 20:31:00
Хорошо, но почему это нормально на версии v6.69.6? При включении DHCP-Snooping на v6.69.6 скорость не падает до примерно 300 Мбит/с. Те 849,70 Мбит/с, что показаны на скриншоте — это 100% скорости от провайдера.
NathanA
Guest
0
01.04.2025 01:19:00
Обратите внимание, что на этом скриншоте по-прежнему видно, что fast path для моста не работает... счётчики fast path в Bridge > Settings всё ещё на нуле. Также ни один из портов моста не показывает аппаратное ускорение. И в конце концов, один из четырёх виртуальных «ядер» (потоков) ЦП почти полностью загружен во время передачи.
Интересно, правда, что у вас такая большая разница в производительности пересылки между RouterOS 6 и 7 на hEX S при использовании программного моста без аппаратного ускорения и fast path. Вы точно используете абсолютно одинаковую конфигурацию при сравнении ROS 6 и 7 на одном и том же устройстве? Если взять ваш hEX S с прошивкой 6.49 и обновить до 7, не меняя конфигурацию, скорость падает до 300 мегабит?
CGGXANNX
Guest
0
02.04.2025 13:13:00
Перечитывая исходное сообщение, у него/неё настроено так, что sfp1 является частью моста, и тесты проводятся между sfp1 и другими Ethernet-портами. Это значит, что даже с отключенным DHCP Snooping эти тесты никогда не выполнялись аппаратно, потому что sfp1 находится вне коммутатора и всегда обрабатывается CPU: ] Этот порт всегда имеет прямое 1Gbps соединение с CPU, даже когда коммутатор не используется: . У меня нет RB760iGS, есть только RB750Gr3, значит я не могу воспроизвести те же условия теста (с одним портом вне коммутатора), но полученные результаты на MT7621A в hEX под RouterOS 7.18.2 отчасти совпадают с опытом автора. Настройка фаервола — из defconf.
При полной аппаратной разгрузке всех портов моста, при включённом или выключенном Bridge VLAN Filtering, скорость передачи между двумя портами моста (оба подключены к коммутатору) легко достигает максимума линка (950Mbps по iperf3, 1Gbps на Ethernet-порту). Загрузка CPU минимальна. Счётчики Bridge Fast Path и Fast Forward не увеличиваются.
При наличии аппаратной разгрузки, с Bridge VLAN Filtering, скорость маршрутизации между VLAN с fasttrack достигает 930Mbps по iperf3 (на Ethernet-порту 980Mbps). Два ядра CPU загружены на максимум, счётчики Bridge Fast Path и Fasttrack растут соответственно. Это такой же результат, как и с fasttrack для LAN-WAN трафика.
Если отключить аппаратную разгрузку, включив IGMP Snooping, скорость маршрутизации между VLAN с fasttrack достигает 944Mbps средне по iperf3. Два ядра CPU загружены полностью, счётчики Bridge Fast Path и Fasttrack растут соответственно. Этот результат стабильнее и лучше, чем при включённой аппаратной разгрузке!
Моё предположение: на RB750Gr3, когда не используется коммутатор, CPU обеспечивает два 1Gbps канала на порты (я тестировал между ether2 и ether3), но при аппаратной разгрузке коммутатор имеет всего один 1Gbps канал к CPU, которым нужно делиться при маршрутизации между VLAN.
При аппаратной разгрузке отключенной (через IGMP Snooping) скорость коммутации в пределах одного L2 достигает в среднем 940Mbps по iperf3, чуть медленнее, чем маршрутизация между VLAN! Одно ядро CPU загружено полностью, другое — примерно на 50%. Счётчик Fasttrack, как и ожидается, не растёт, а Bridge Fast Path растёт согласно ожиданиям. Если подключены только два порта, тогда растёт счётчик Bridge Fast Forward.
=> Вывод на этом этапе: RB750Gr3 и, вероятно, RB760iGS с тем же CPU и коммутатором достаточно быстрые для коммутации или маршрутизации (с fasttrack) iperf3 пропускной способности >= 930Mbps, как с аппаратной разгрузкой моста, так и без неё.
Если аппаратную разгрузку отключить, выключив IGMP Snooping, но включив DHCP Snooping (с опцией 82 или без неё), производительность коммутации (в одном L2) значительно падает. Скорость iperf3 в среднем около 420Mbps, загрузка CPU — 1.6 ядра. Счётчик Bridge Fast Path не растёт (как и документировано MikroTik). При тех же параметрах, но с маршрутизацией между VLAN, скорость iperf3 падает до 280Mbps в среднем. Счётчики Fast Path и Fasttrack не растут, как и должно быть.
Эти показатели совпадают с моими прежними тестами LAN-WAN на роутере при отключённом fasttrack и примерно соответствуют опубликованным MikroTik значениям для 512-байт и 25 правил.
=> Вывод: в RouterOS 7 Bridge Fast Path значительно улучшает производительность коммутации, когда аппаратной разгрузки нет, а fasttrack требует работающий Bridge Fast Path. Включение DHCP Snooping отключает Bridge Fast Path (и делает fasttrack неработающим при маршрутизации между портами моста).
Я не понимаю, почему производительность коммутации без Fast Path и аппаратной разгрузки в RouterOS 6 лучше — хотя показатели ниже, чем в RouterOS 7 с включённым Fast Path. Так что даже на RouterOS 6 лучше не использовать DHCP Snooping на hEX / hEX S.
mkx
Guest
0
02.04.2025 15:11:00
Блок-схема при отключённом коммутировании показывает, что оба соединения между свитчем и CPU используются попеременно… и использование двух соседних портов действительно может распределять трафик между обеими линиями. Если бы вы использовали только чётные или только нечётные порты (ether2+ether4 или ether1+ether3), результаты, скорее всего, были бы ближе к тем, что вы получили с включённым аппаратным ускорением (то есть с коммутированием). Блок-схема hEX S почти идентична, за исключением того, что одно из соединений между свитчем и CPU выделено под SFP-порт, если в него вставлен модуль (в этом случае ситуации с включённым и выключенным коммутированием становятся похожими с точки зрения доступной пропускной способности между свитчем и CPU).
RcRaCk2k
Guest
0
02.04.2025 19:45:00
Да, после обновления до версии 7.xx я заметил снижение. Конфигурация — это шаблон для всех моих «hEX S», поэтому настройка всегда одинаковая.
NathanA
Guest
0
04.04.2025 14:01:00
Думаю, в выводах упущен главный момент. Да, на этом железе в ROS 6 без быстрого пути через мост наблюдается небольшое падение. Но автор темы, похоже, спокойно относится к относительно такой производительности. По-прежнему видим значения около 800 Мбит/с, то есть почти гигабит. Автор темы вроде бы не жаловался на скорость до обновления до ROS 7, когда скорость упала примерно до 300 – это вдвое меньше того, что показывала старая версия с той же конфигурацией (и, судя по твоему отчету, при этом система потребляет еще БОЛЬШЕ ресурсов CPU, чтобы передавать МЕНЬШЕ пакетов). Не понимаю, как на это можно смотреть и не признать, что произошел серьезный регресс. Для меня же более интересный вопрос – это специфический сбой именно для этого железа или общий.
RcRaCk2k
Guest
0
06.04.2025 18:56:00
Как я вижу, версия 6.49 использует все 4 ядра процессора для входящего и исходящего трафика (sfp1 > ether1 = загрузка, ether1 > sfp1 = отдача). В версии 7.x (7.18.2 в моих тестах, но и другие версии ведут себя так же) загрузкой занимается только ядро CPU 0, а отдача распределяется по ядрам 0,1,2,3 — то есть на 100%. Трафик всегда проходит через процессор, это нормально из-за конструкции платы. Процессор с частотой 800 МГц должен справляться с 250-320 Мбит/с. Значит, 4 таких ядра должны обеспечить 1000-1280 Мбит/с. Единственная проблема между версиями 6.49 и 7.18 — это то, что загрузка закреплена только за CPU#0.
NathanA
Guest
0
06.04.2025 21:11:00
Это не то, что показывает скриншот, который вы опубликовали 31 марта. Там скриншот маршрутизатора с версией 6.49, вы скачиваете со скоростью 850 Мбит/с через Oolka Speedtest, и загрузка CPU 0 составляет 81,5%, CPU 1 — 6%, CPU 2 — 7,5%, CPU 3 — 9,5%. То есть даже с версией 6.49 загрузка в основном ложится на один ядро процессора (по крайней мере, один скачиваемый файл с одного источника).
Поскольку это происходит и на 6.49, и на 7.x, но версия 7.x при этом работает гораздо хуже, получается, что проблема в 7.x скорее связана с меньшей эффективностью использования процессора, а не с тем, как распределяется нагрузка между ядрами или потоками.
К тому же, часть моего комментария, на который вы отвечали («в общем»), ставила под сомнение, возникает ли это падение производительности только на устройствах с MMIPS или на всех устройствах. Чтобы это выяснить, кто-нибудь должен проверить на RB951, запустив там тот же тест. RB951 подходит, потому что более быстрый процессор может и не заметить нагрузку при передаче 1 Гбит/с без использования fast path. Скоро я попробую запустить подобный сравнительный тест между hEX S и RB951.
Не обязательно. Я подозреваю, что не весь трафик можно бесконечно масштабировать на несколько потоков процессора. Аналогично тому, почему балансировка нагрузки round-robin между более чем одним интерфейсом может быть проблемной, я думаю, существует риск, что пакеты из одного разговора или «потока» могут прийти в неправильном порядке, если несколько потоков CPU участвуют в обработке трафика этого потока.
В случае программного мостирования очень вероятно, что любой набор кадров с одинаковыми src-mac и dst-mac будет «привязан» к одному ядру. Аналогично для L3-форвардинга — по одинаковым src-ip (+ возможно src-port) и dst-ip (+ возможно dst-port).
