http://mikrotik.moscow Новое в теме Низкая производительность RB5009 при работе за NAT форума RouterOS на сайте Mikrotik.moscow [mikrotik.moscow] ru http://backend.userland.com/rss2 Sat, 01 Aug 2026 01:22:11 -0400 Низкая производительность RB5009 при работе за NAT RouterOS в форуме RouterOS.
Я использую это слово в смысле «предположение, выдвигаемое в качестве основания для доказательства», а не в смысле «докторской диссертации». Предполагаю, что тебе интереснее стройная аргументация, а не просто спор ради спора, верно? Linux bridge изначально не отличается хорошим UI/UX дизайном и нормальными мануалами в Linux man pages, и это отразилось и на MikroTik.

Если мы согласны, что при указанной конфигурации OP никак не может снять нагрузку с CPU, то я не вижу, как MT может решить эту проблему лучшим софтварным бриджем. Аппаратные ограничения по PPS фиксируются на этапе проектирования, за исключением нюансов вроде частоты тактирования, которую упомянул pe1chl.

Если же ты предлагаешь, что лучшее программное решение как-то скинет нагрузку на уже имеющийся коммутационный чип RB5009 и позволит работать на полной скорости, то, как мне кажется, ты упускаешь из виду разнородность железа MT. В отличие от гигантов, которыми ты восхищаешься, MT не разрабатывает свои собственные кастомные микросхемы под идеальные софтварные решения. Единственный способ избежать проблем с совместимостью при использовании такого количества разных COTS-чипов — упростить все дизайны до наименее производительного общего уровня. При таком подходе аппаратными функциями могут пользоваться только те, что есть во всех микросхемах. MT пошёл другим путём: они предоставляют доступ ко всем функциям чипов, заставляя пользователя разбираться, что и как, и избегать конфигураций, требующих от RouterOS имитации отсутствующих ASIC-функций программным путём, с которыми ты так борешься.

MikroTik не исправит этот конструктивный недостаток без полного переработки исходников. Если добавить «кастомные ASIC», чтобы поддержать софт, тогда да — получится более аккуратная реализация… но при этом не будет за $59 хEX.
01.05.2024 15:39:00, tangent.]]> http://mikrotik.moscow/forum/forum57/85413-nizkaya-proizvoditelnost-rb5009-pri-rabote-za-nat/message396173 http://mikrotik.moscow/forum/forum57/85413-nizkaya-proizvoditelnost-rb5009-pri-rabote-za-nat/message396173 Wed, 01 May 2024 15:39:00 -0400 RouterOS Низкая производительность RB5009 при работе за NAT RouterOS в форуме RouterOS.
Тот мой связанный тред — это не диссертация, а про ошибки в UI/UX дизайне RouterOS, включая саму замороченную концепцию Linux bridging. Суть в том, что изначально Linux bridge — штука сложная, у неё ни нормального UI/UX, ни толковых мануалов в Linux man pages нет, и это негативно отразилось и на MikroTik, который опирается на оригинальный "data plane" ядра Linux для L2 переключения (бридж, VLANы, STP, фильтрация VLAN и так далее). Речь не только про L3 hardware offloading, а ещё и про сложнейший L2 offloading и L2 fast-path (один бридж + VLAN фильтрация на большинстве железок MikroTik). Для MikroTik нет универсального решения, но в этом и проблема Linux switchdev/dsa/bridging в целом.

У Juniper, Nokia, Cisco и Huawei такой проблемы нет, потому что их сисадмины сетевого ПО с самого начала сделали свой платформозависимый исходный код слоя 2 и реализацию, а там такой сложности не было. Поэтому у Cisco/Juniper и подобных концепция бриджинга (называется IRB) довольно унифицирована и настраивается одинаково на всём современном железе.

MikroTik не сможет исправить этот дизайн-фейл без полной переработки кода, что явно в ближайшее время не случится — может быть, это произойдёт в ROSv8, но тогда придётся полностью менять CLI на современный декларативный конфиг (в стиле Juniper) и обновлять API/rest API, что дорого и сомнительно, что MikroTik готов финансово это потянуть. У меня есть знакомые в этой сфере в США, и они зарабатывают порядка 500 тысяч долларов в год на такие роли. MikroTik — маленькая европейская компания, и почти ни одна европейская технологическая компания не способна платить лидеру по разработке сетевого софта $500k и выше.
01.05.2024 09:10:00, DarkNate.]]> http://mikrotik.moscow/forum/forum57/85413-nizkaya-proizvoditelnost-rb5009-pri-rabote-za-nat/message396172 http://mikrotik.moscow/forum/forum57/85413-nizkaya-proizvoditelnost-rb5009-pri-rabote-za-nat/message396172 Wed, 01 May 2024 09:10:00 -0400 RouterOS Низкая производительность RB5009 при работе за NAT RouterOS в форуме RouterOS.
Мой вывод из той темы применительно к этой такой: существует какое-то изменение в конфигурации RouterOS, которое могло бы значительно ускорить работу приложения автора поста, но единственная причина, почему этого не сделали — слишком много вариантов настройки, и автор просто выбрал неправильный путь. Я неправильно применил идею из другой вашей темы, @DarkNate? Признаю, возможно, что что-то упускаю, раз не изучал /export конфигурацию, но не вижу никакой настройки, которая принципиально могла бы справиться с комбинацией: программный NAT (RB5009 не может аппаратно разгружать NAT), крошечные пакеты, единственный источник пакетов и отсутствие предсказуемых потоков соединений, то есть никаких возможностей для ускоренного маршрута. Автор поста едва ли мог придумать более жестокий тест для NAT-маршрутизатора — и сделал это сознательно и с дурными намерениями.
29.04.2024 21:13:00, tangent.]]> http://mikrotik.moscow/forum/forum57/85413-nizkaya-proizvoditelnost-rb5009-pri-rabote-za-nat/message396171 http://mikrotik.moscow/forum/forum57/85413-nizkaya-proizvoditelnost-rb5009-pri-rabote-za-nat/message396171 Mon, 29 Apr 2024 21:13:00 -0400 RouterOS Низкая производительность RB5009 при работе за NAT RouterOS в форуме RouterOS.
Одна из проблем с RB5009, о которой нужно знать, — это то, что у него 4 ядра и переменная тактовая частота. Обычно он работает на 350 МГц, но может разгоняться до 1400 МГц, когда операционная система решает, что это нужно. К сожалению, механизмы регулировки скорости здесь не оптимальны для роутеров, и уж точно не для теста, который проводится: кажется, что регулятор основывается на общей нагрузке системы. Поэтому, когда нагрузка приходится только на одно ядро, он видит максимум 25% загрузки системы и неохотно увеличивает частоту. Переключение вверх/вниз происходит довольно быстро, и кажется, что при прерывистой нагрузке частота не держится высокой на протяжении всего теста. Один из способов обойти это — просто установить частоту процессора на 1400 МГц вручную вместо режима «авто». Теоретически тогда процессор будет греться сильнее, но на практике разница не такая заметная, как у процессоров Intel.
29.04.2024 20:12:00, pe1chl.]]> http://mikrotik.moscow/forum/forum57/85413-nizkaya-proizvoditelnost-rb5009-pri-rabote-za-nat/message396170 http://mikrotik.moscow/forum/forum57/85413-nizkaya-proizvoditelnost-rb5009-pri-rabote-za-nat/message396170 Mon, 29 Apr 2024 20:12:00 -0400 RouterOS Низкая производительность RB5009 при работе за NAT RouterOS в форуме RouterOS.
OP снова стал жертвой сложности абстракции конфигурации MikroTik. Истинную причину определить без дампа конфигурации невозможно, но это явно кричит о типичной неправильной настройке Linux bridge. Однако OP явно разбирается в парадигме switchdev/Linux DSA, так что оставлю это здесь.
29.04.2024 17:47:00, DarkNate.]]> http://mikrotik.moscow/forum/forum57/85413-nizkaya-proizvoditelnost-rb5009-pri-rabote-za-nat/message396169 http://mikrotik.moscow/forum/forum57/85413-nizkaya-proizvoditelnost-rb5009-pri-rabote-za-nat/message396169 Mon, 29 Apr 2024 17:47:00 -0400 RouterOS Низкая производительность RB5009 при работе за NAT RouterOS в форуме RouterOS.
Я только что получил RB5009 и пытаюсь понять, как добиться нормальной производительности при подключении к множеству разных хостов и портов. У меня есть сервер за NAT, который должен проверять открытые порты в большой подсети, но при этом я достигаю всего около ~150K пакетов в секунду/~80 Мбит/с. Используя /tool/profile, вижу, что нагрузка на firewall примерно ~75 %, а на сеть около ~15 % CPU при 300K пакетов в секунду от сервера. Интерфейс, к которому подключен сервер и который входит в мост, показывает: RX 300K пакетов в секунду, FP RX 150K пакетов в секунду. Мост: RX 150K пакетов в секунду, FP RX 150K пакетов в секунду. WAN-интерфейс: TX 150K пакетов в секунду. Почему только половина пакетов отражается как FP и на мосту? Есть ли способ сделать это быстрее?
13.04.2024 23:58:00, AlexX9.]]> http://mikrotik.moscow/forum/forum57/85413-nizkaya-proizvoditelnost-rb5009-pri-rabote-za-nat/message396168 http://mikrotik.moscow/forum/forum57/85413-nizkaya-proizvoditelnost-rb5009-pri-rabote-za-nat/message396168 Sat, 13 Apr 2024 23:58:00 -0400 RouterOS