http://mikrotik.moscow Новое в теме [Запрос на исправление ошибки] Опция DHCP 82 на hEX S по умолчанию не отключает HW-Forward форума RouterOS на сайте Mikrotik.moscow [mikrotik.moscow] ru http://backend.userland.com/rss2 Tue, 14 Jul 2026 04:20:46 +0300 [Запрос на исправление ошибки] Опция DHCP 82 на hEX S по умолчанию не отключает HW-Forward RouterOS в форуме RouterOS.
Это не то, что показывает скриншот, который вы опубликовали 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).
06.04.2025 21:11:00, NathanA.]]> http://mikrotik.moscow/forum/forum57/88107-zapros-na-ispravlenie-oshibki_-optsiya-dhcp-82-na-hex-s-po-umolchaniyu-ne-otklyuchaet-hw_forward/message423537 http://mikrotik.moscow/forum/forum57/88107-zapros-na-ispravlenie-oshibki_-optsiya-dhcp-82-na-hex-s-po-umolchaniyu-ne-otklyuchaet-hw_forward/message423537 Sun, 06 Apr 2025 21:11:00 +0300 RouterOS [Запрос на исправление ошибки] Опция DHCP 82 на hEX S по умолчанию не отключает HW-Forward RouterOS в форуме RouterOS.
Как я вижу, версия 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.
06.04.2025 18:56:00, RcRaCk2k.]]> http://mikrotik.moscow/forum/forum57/88107-zapros-na-ispravlenie-oshibki_-optsiya-dhcp-82-na-hex-s-po-umolchaniyu-ne-otklyuchaet-hw_forward/message423536 http://mikrotik.moscow/forum/forum57/88107-zapros-na-ispravlenie-oshibki_-optsiya-dhcp-82-na-hex-s-po-umolchaniyu-ne-otklyuchaet-hw_forward/message423536 Sun, 06 Apr 2025 18:56:00 +0300 RouterOS [Запрос на исправление ошибки] Опция DHCP 82 на hEX S по умолчанию не отключает HW-Forward RouterOS в форуме RouterOS.
Думаю, в выводах упущен главный момент. Да, на этом железе в ROS 6 без быстрого пути через мост наблюдается небольшое падение. Но автор темы, похоже, спокойно относится к относительно такой производительности. По-прежнему видим значения около 800 Мбит/с, то есть почти гигабит. Автор темы вроде бы не жаловался на скорость до обновления до ROS 7, когда скорость упала примерно до 300 – это вдвое меньше того, что показывала старая версия с той же конфигурацией (и, судя по твоему отчету, при этом система потребляет еще БОЛЬШЕ ресурсов CPU, чтобы передавать МЕНЬШЕ пакетов). Не понимаю, как на это можно смотреть и не признать, что произошел серьезный регресс. Для меня же более интересный вопрос – это специфический сбой именно для этого железа или общий.
04.04.2025 14:01:00, NathanA.]]> http://mikrotik.moscow/forum/forum57/88107-zapros-na-ispravlenie-oshibki_-optsiya-dhcp-82-na-hex-s-po-umolchaniyu-ne-otklyuchaet-hw_forward/message423535 http://mikrotik.moscow/forum/forum57/88107-zapros-na-ispravlenie-oshibki_-optsiya-dhcp-82-na-hex-s-po-umolchaniyu-ne-otklyuchaet-hw_forward/message423535 Fri, 04 Apr 2025 14:01:00 +0300 RouterOS [Запрос на исправление ошибки] Опция DHCP 82 на hEX S по умолчанию не отключает HW-Forward RouterOS в форуме RouterOS.
Да, после обновления до версии 7.xx я заметил снижение. Конфигурация — это шаблон для всех моих «hEX S», поэтому настройка всегда одинаковая.
02.04.2025 19:45:00, RcRaCk2k.]]> http://mikrotik.moscow/forum/forum57/88107-zapros-na-ispravlenie-oshibki_-optsiya-dhcp-82-na-hex-s-po-umolchaniyu-ne-otklyuchaet-hw_forward/message423534 http://mikrotik.moscow/forum/forum57/88107-zapros-na-ispravlenie-oshibki_-optsiya-dhcp-82-na-hex-s-po-umolchaniyu-ne-otklyuchaet-hw_forward/message423534 Wed, 02 Apr 2025 19:45:00 +0300 RouterOS [Запрос на исправление ошибки] Опция DHCP 82 на hEX S по умолчанию не отключает HW-Forward RouterOS в форуме RouterOS.
Блок-схема при отключённом коммутировании показывает, что оба соединения между свитчем и CPU используются попеременно… и использование двух соседних портов действительно может распределять трафик между обеими линиями. Если бы вы использовали только чётные или только нечётные порты (ether2+ether4 или ether1+ether3), результаты, скорее всего, были бы ближе к тем, что вы получили с включённым аппаратным ускорением (то есть с коммутированием). Блок-схема hEX S почти идентична, за исключением того, что одно из соединений между свитчем и CPU выделено под SFP-порт, если в него вставлен модуль (в этом случае ситуации с включённым и выключенным коммутированием становятся похожими с точки зрения доступной пропускной способности между свитчем и CPU).
02.04.2025 15:11:00, mkx.]]> http://mikrotik.moscow/forum/forum57/88107-zapros-na-ispravlenie-oshibki_-optsiya-dhcp-82-na-hex-s-po-umolchaniyu-ne-otklyuchaet-hw_forward/message423533 http://mikrotik.moscow/forum/forum57/88107-zapros-na-ispravlenie-oshibki_-optsiya-dhcp-82-na-hex-s-po-umolchaniyu-ne-otklyuchaet-hw_forward/message423533 Wed, 02 Apr 2025 15:11:00 +0300 RouterOS [Запрос на исправление ошибки] Опция DHCP 82 на hEX S по умолчанию не отключает HW-Forward RouterOS в форуме RouterOS.
Перечитывая исходное сообщение, у него/неё настроено так, что sfp1 является частью моста, и тесты проводятся между sfp1 и другими Ethernet-портами. Это значит, что даже с отключенным DHCP Snooping эти тесты никогда не выполнялись аппаратно, потому что sfp1 находится вне коммутатора и всегда обрабатывается CPU: ] https://cdn.mikrotik.com/web-assets/product_files/RB760iGS-esw3_190600.png Этот порт всегда имеет прямое 1Gbps соединение с CPU, даже когда коммутатор не используется: https://cdn.mikrotik.com/web-assets/product_files/RB760iGS-dsw_180523.png. У меня нет 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.
02.04.2025 13:13:00, CGGXANNX.]]> http://mikrotik.moscow/forum/forum57/88107-zapros-na-ispravlenie-oshibki_-optsiya-dhcp-82-na-hex-s-po-umolchaniyu-ne-otklyuchaet-hw_forward/message423532 http://mikrotik.moscow/forum/forum57/88107-zapros-na-ispravlenie-oshibki_-optsiya-dhcp-82-na-hex-s-po-umolchaniyu-ne-otklyuchaet-hw_forward/message423532 Wed, 02 Apr 2025 13:13:00 +0300 RouterOS [Запрос на исправление ошибки] Опция DHCP 82 на hEX S по умолчанию не отключает HW-Forward RouterOS в форуме RouterOS.
Обратите внимание, что на этом скриншоте по-прежнему видно, что fast path для моста не работает... счётчики fast path в Bridge > Settings всё ещё на нуле. Также ни один из портов моста не показывает аппаратное ускорение. И в конце концов, один из четырёх виртуальных «ядер» (потоков) ЦП почти полностью загружен во время передачи.

Интересно, правда, что у вас такая большая разница в производительности пересылки между RouterOS 6 и 7 на hEX S при использовании программного моста без аппаратного ускорения и fast path. Вы точно используете абсолютно одинаковую конфигурацию при сравнении ROS 6 и 7 на одном и том же устройстве? Если взять ваш hEX S с прошивкой 6.49 и обновить до 7, не меняя конфигурацию, скорость падает до 300 мегабит?
01.04.2025 01:19:00, NathanA.]]> http://mikrotik.moscow/forum/forum57/88107-zapros-na-ispravlenie-oshibki_-optsiya-dhcp-82-na-hex-s-po-umolchaniyu-ne-otklyuchaet-hw_forward/message423531 http://mikrotik.moscow/forum/forum57/88107-zapros-na-ispravlenie-oshibki_-optsiya-dhcp-82-na-hex-s-po-umolchaniyu-ne-otklyuchaet-hw_forward/message423531 Tue, 01 Apr 2025 01:19:00 +0300 RouterOS [Запрос на исправление ошибки] Опция DHCP 82 на hEX S по умолчанию не отключает HW-Forward RouterOS в форуме RouterOS.
Хорошо, но почему это нормально на версии v6.69.6? При включении DHCP-Snooping на v6.69.6 скорость не падает до примерно 300 Мбит/с. Те 849,70 Мбит/с, что показаны на скриншоте — это 100% скорости от провайдера.
31.03.2025 20:31:00, RcRaCk2k.]]> http://mikrotik.moscow/forum/forum57/88107-zapros-na-ispravlenie-oshibki_-optsiya-dhcp-82-na-hex-s-po-umolchaniyu-ne-otklyuchaet-hw_forward/message423530 http://mikrotik.moscow/forum/forum57/88107-zapros-na-ispravlenie-oshibki_-optsiya-dhcp-82-na-hex-s-po-umolchaniyu-ne-otklyuchaet-hw_forward/message423530 Mon, 31 Mar 2025 20:31:00 +0300 RouterOS [Запрос на исправление ошибки] Опция DHCP 82 на hEX S по умолчанию не отключает HW-Forward RouterOS в форуме RouterOS.
Но было бы очень здорово, если бы это реализовали.
25.03.2025 20:51:00, lurker888.]]> http://mikrotik.moscow/forum/forum57/88107-zapros-na-ispravlenie-oshibki_-optsiya-dhcp-82-na-hex-s-po-umolchaniyu-ne-otklyuchaet-hw_forward/message423529 http://mikrotik.moscow/forum/forum57/88107-zapros-na-ispravlenie-oshibki_-optsiya-dhcp-82-na-hex-s-po-umolchaniyu-ne-otklyuchaet-hw_forward/message423529 Tue, 25 Mar 2025 20:51:00 +0300 RouterOS [Запрос на исправление ошибки] Опция DHCP 82 на hEX S по умолчанию не отключает HW-Forward RouterOS в форуме RouterOS.
Также обратите внимание, что для устройств с этим сетевым чипом (RB5009, CCR2004-16G-2S+, L009), хотя включение DHCP Snooping сохраняет аппаратное ускорение на мосту, оно делает fast path на мосту неработоспособным и влияет на fasttrack. Если у вас есть WAN-порт вне моста, то fasttrack будет работать для соединений между WAN-портом и интерфейсами на мосту (включая VLAN), но и fast path, и fasttrack будут неэффективны для трафика между участниками моста (например, для трафика между VLAN). У меня есть личный опыт с этой проблемой. Документация недавно обновлена и теперь это упоминается: https://help.mikrotik.com/docs/spaces/ROS/pages/328068/Bridging+and+Switching#BridgingandSwitching-BridgeInterfaceSetup Включение функции DHCP snooping отключит fast path на мосту, что в свою очередь повлияет на возможность fasttrack для соединений через этот мост.
25.03.2025 20:37:00, CGGXANNX.]]> http://mikrotik.moscow/forum/forum57/88107-zapros-na-ispravlenie-oshibki_-optsiya-dhcp-82-na-hex-s-po-umolchaniyu-ne-otklyuchaet-hw_forward/message423528 http://mikrotik.moscow/forum/forum57/88107-zapros-na-ispravlenie-oshibki_-optsiya-dhcp-82-na-hex-s-po-umolchaniyu-ne-otklyuchaet-hw_forward/message423528 Tue, 25 Mar 2025 20:37:00 +0300 RouterOS [Запрос на исправление ошибки] Опция DHCP 82 на hEX S по умолчанию не отключает HW-Forward RouterOS в форуме RouterOS.
Ниже таблицы характеристик переключающих чипов вы можете увидеть список продуктов, в которых используется каждая модель переключающего чипа, а также какие конкретные интерфейсы/порты подключены к этим чипам.
25.03.2025 20:27:00, NathanA.]]> http://mikrotik.moscow/forum/forum57/88107-zapros-na-ispravlenie-oshibki_-optsiya-dhcp-82-na-hex-s-po-umolchaniyu-ne-otklyuchaet-hw_forward/message423527 http://mikrotik.moscow/forum/forum57/88107-zapros-na-ispravlenie-oshibki_-optsiya-dhcp-82-na-hex-s-po-umolchaniyu-ne-otklyuchaet-hw_forward/message423527 Tue, 25 Mar 2025 20:27:00 +0300 RouterOS [Запрос на исправление ошибки] Опция DHCP 82 на hEX S по умолчанию не отключает HW-Forward RouterOS в форуме RouterOS.
Спасибо за подсказку по той матрице. Есть ли какая-нибудь матрица, где можно посмотреть, в каких устройствах Mikrotik установлены какие Switch-Chip? Я ищу переключатели 88E6393X, 88E6191X, 88E6190.
25.03.2025 20:14:00, RcRaCk2k.]]> http://mikrotik.moscow/forum/forum57/88107-zapros-na-ispravlenie-oshibki_-optsiya-dhcp-82-na-hex-s-po-umolchaniyu-ne-otklyuchaet-hw_forward/message423526 http://mikrotik.moscow/forum/forum57/88107-zapros-na-ispravlenie-oshibki_-optsiya-dhcp-82-na-hex-s-po-umolchaniyu-ne-otklyuchaet-hw_forward/message423526 Tue, 25 Mar 2025 20:14:00 +0300 RouterOS [Запрос на исправление ошибки] Опция DHCP 82 на hEX S по умолчанию не отключает HW-Forward RouterOS в форуме RouterOS.
Привет! При включении 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 не должно влиять на производительность бриджа.
09.03.2025 19:32:00, RcRaCk2k.]]> http://mikrotik.moscow/forum/forum57/88107-zapros-na-ispravlenie-oshibki_-optsiya-dhcp-82-na-hex-s-po-umolchaniyu-ne-otklyuchaet-hw_forward/message423525 http://mikrotik.moscow/forum/forum57/88107-zapros-na-ispravlenie-oshibki_-optsiya-dhcp-82-na-hex-s-po-umolchaniyu-ne-otklyuchaet-hw_forward/message423525 Sun, 09 Mar 2025 19:32:00 +0300 RouterOS