[mrrc]

Cеть, построенная на 1Гбит\с, структурные подразделения находятся в своем изолированном адресном пространстве в vlan-ах, также в отдельный vlan вынесен серверный сегмент со своей адресацией, с которым могут взаимодействовать пользователи из упомянутых vlan посредством маршрутизации на центральном маршрутизаторе, в который включен серверный сегмент.

 

Vlan-ы построены на бриджах коммутаторов\маршрутизаторов, включен VLAN filtering.
На центральном маршрутизаторе созданы vlan-интерфейсы, навешена требуемая адресация подсетей, регулируется маршрутизация между подсетями vlan-ов.

Проблема заключается в скорости внутрисетевого обмена данными,  когда задействуется маршрутизация между подсетями vlan-ов на центральном маршрутизаторе.

В случае обмена в рамках L2 сегмента vlan-а (к примеру прокинуть сегмент сети по vlan через цепочку коммутаторов на самый удаленный коммутатор, подключить там клиента с адресацией серверной подсети и попробовать закачать файл - скорость ~110-115 Мб/c, что практически честно для гигабитной физики.
Аналогично, но уже при задействовании маршрутизации подсетей vlan-ов на центральном маршрутизаторе - ~60-70Мб\с.
При этом в обоих случаях при обмене загрузка проца центрального маршрутизатора не превышает 25-30%.
Но если смотреть через Tools -> Profile с маршрутизацией одно из ядер доходит до ~92%, плюс около ~50% берет на себя процесс firewall, ~32% networking.
Обмен без маршрутизации между подсетями, Tools -> Profile центрального маршрутизатора показывает одно из ядер до 80%, networking ~40%, ethernet ~22%, загрузка же firewall где-то там в дали списка.

Можно констатировать, что падение скорости обмена происходит при задействовании ip-маршрутизации между внутренними подсетями на центральном маршрутизаторе.
Bribge Settings -> Use IP Firewall разумеется не включался, Fast Past Path-ы задейстованы по умолчанию в параметрах настройки бриджей, как и Hardware offload на портах.

 

Из возможных предварительно видимых решений - использование правил FastTrack с учетом направления и назначения трафика между vlan-интерфейсами, вовлеченными во внутрисетевой обмен. Потому как на центральном маршрутизаторе имеются фильтрация и маркировка трафика брандмауэром, списки, ipsec, etc для управления доступом наружу и извне к себе, это все не должно пострадать. Поможет ли в данной ситуации FastTrack? Погонял идею на тестовом стенде - успехом не увенчалось.

Или пробовать перестроить парадигму настройки vlan с бриджа на switch на центральном маршрутизаторе, но ведь как видно проблема проявляется только во время L3 обмена.

Либо только замена самого маршрутизатора, но где гарантия, что прирост производительности будет пропорционален вложениям и процесс вновь не упрется в одно из ядер?

Да, центральный маршрутизатор - RB1100AHx4, в сети используются от hAP ac2 до 326-х, 328-х, все на 6.49.7

В общем перед тем, как что-то предпринять, хотел бы вначале послушать умные головы.

[jffulcrum]

1 час назад, mrrc сказал:

RB1100AHx4

Если есть FW, то практический предел L3 маршрутизации - в районе 500 Мбит/с. Больше можно вытащить или через fasttrack, или через переделку и максимальное упрощение firewall:

 

1. Максимально использовать interface и interface lists вместо ip адресов/address lists

2. Максимально раскидывать трафик в forward в chains,чтобы пакеты проходили не всю гирлянду правил, а только те правила, что им реально нужны.

3. Address lists с DNS - это вообще оверкилл, которого надо избегать. Вплоть до выноса такого функционала на отдельное устройство.

4. Маршрутизацию тоже надо смотреть - rules, VRF - всё это дорого и медленно, свести в маркировку, опять же маркировать стараться по Interfaces/lists

 

Но гигабит вы с него всё равно не вытащите. Практика - 600-650 достижимы, если роутер занимается чем-то еще.

[mrrc]

51 минуту назад, jffulcrum сказал:

Если есть FW, то практический предел L3 маршрутизации - в районе 500 Мбит/с

FW, списки конечно присутствуют, куда без этого, поэтому у меня весьма неплохие и стабильные показатели с учетом имеющегося. Лишать себя всей гибкости конфигурирования, которые дает микрот, выиграв при этом сверху ~100-150Мбит/с, так себе вариант. Тогда уж смотреть в сторону отдельных сегментов 10Gbit/s между особо требовательными к обмену узлами, не завязывая передачу на работу базовой СКС, чтобы прочувствовать контраст.

 

Собственно поэтому в первую очередь и рассмотрел возможность задействовать fasttrack. Но только в рамках внутрисетевого обмена между вовлеченными в обмен интерфейсами, в моем случае пользовательскими и серверным vlan. Но либо лыжи не едут, либо пытаюсь скрестить теплое с мягким - быть может данный функционал на vlan-ах, поднятых на бриджах с VLAN filtering-ом, не будет работать для разгрузки ЦП? Ибо добиться результата пока не удалось. Пробовал fasttrack-connection как предписывают маны с connection-state=established,related, так и без, для каждого направления со своей парой правил, с указанием входящего и исходящего интерфейсов.

 

Ну и более производительная железка, в качестве маршрутизатора, также не гарантирует, что прирост производительности окажется пропорционален вложениям судя по сказанному.

[jffulcrum]

С CCR2004, где ядра толще, и частотнее, вытащите больше, не вопрос. Вопрос цены. С x86 вопрос в покупке лицензии, с чем в РФ проблемы, ну и нужна ROS7 для современного железа.

 

45 минут назад, mrrc сказал:

Лишать себя всей гибкости конфигурирования, которые дает микрот, выиграв при этом сверху ~100-150Мбит/с, так себе вариант.

Ну, всей не лишаетесь. Но конфиг усложнится, да.

[mrrc]

7 минут назад, jffulcrum сказал:

С CCR2004, где ядра толще, и частотнее, вытащите больше, не вопрос

Частотнее, но ведь не намного, тип процессора другой, да.

Выше уже больше уклон на многоядерность, не сколько на частоту, а с учетом как видим неважного распределения ROS процессорного времени на все имеющиеся ядра, может оказаться те же яйца или минимум прироста производительности(

 

По варианту с fasttrack - есть ли смысл упираться? По главному вопросу так и не понятно.

[mrrc]

Интересное наблюдение, а работает ли вообще FastTrack.

Применительно к моему случаю, что может быть логичнее схемы:

bridgeХ.ХХ - vlan-интерфейсы серверного сегмента и пользовательского, между подсетями которых и должен выполняться обмен по быстрому пути.

 

add action=fasttrack-connection chain=forward connection-state=established,related disabled=no in-interface=bridge1.10 out-interface=bridge1.30
add action=fasttrack-connection chain=forward connection-state=established,related disabled=no in-interface=bridge1.30 out-interface=bridge1.10
add action=accept chain=forward connection-state=established,related disabled=no in-interface=bridge1.10 out-interface=bridge1.30
add action=accept chain=forward connection-state=established,related disabled=no in-interface=bridge1.30 out-interface=bridge1.10

Пускать по FastTrack-у соединения между интерфейсами, задействованными во внутрисетевом обмене.

Результата нет, трафик ложится в правила, скорость та же, Profile по ресурсам без изменений.

Пробую чисто из мана для всего:

 

add action=fasttrack-connection chain=forward connection-state=established,related
add action=accept chain=forward connection-state=established,related

 

Не вижу результата.

В мане по FastTrack-у первым правилом идет динамическое, но там оно accept, как и в Mangle-ах и Raw, в моем же случае в качестве действия указывается passthrough почему-то.
Пробую все на тестовом стенде в виде RB1100AHx2 с максимально приближенной копией продакшн-СКС.

[jffulcrum]

А iperf при этом не UDP ли использует?

[mrrc]

@jffulcrum не очень понял в части приведенной утилиты. Если чем я проверял скоростные показатели - то банально перекачка исошника на 1,5 гига между узлами, находящимися в разных подсетях.

 

[jffulcrum]

Torch выключен в момент тестирования? В Ip - Settings FastPath включен?

[mrrc]

Torch не включал (трафик при транзитной перекачке наблюдал в правилах), FastPath включен, там все по дефолту.

В мане по FastPath имеется такое:

 

Цитата

Bridge handler

Bridge fast path is automatically used if following conditions are met:

bridge VLAN filtering is disabled,

Но т.к. vlan-ы у меня на бридже и разумеется задействован VLAN filtering, это может являться причиной неработоспособности FastTrack-а?

Еще все же действие динамических правил passthrough вместо accept непонятно.

Изменено 15 февраля, 2023 пользователем mrrc

[Saab95]

RB1100 спокойно роутит данные между двумя гигабитными портами без проблем и сильной загрузки процессора. Более того даже полнодуплексный тест пакетами 1500 байт позволяет передать 1+1 гига из одного порта в 1+1 гига в другой порт, то есть суммарный симплексный трафик 4 гига.

 

Нужно искать проблему в файрволах, шейперах и т.п. Очень частая проблема это как раз файрвол и манглы, делают разные защиты от взломов, ограничения ненужные - трафик проходит через десятки правил и проверок - это сильно снижает производительность.

 

Кроме всего зачем добавлять вланы в бридж? Что бы устройства из сети одного влана передавали данные в сеть другого? Смысл тогда вланов? Они должны на микротике терминироваться и все, это не коммутатор.

[mrrc]

10 минут назад, Saab95 сказал:

Нужно искать проблему в файрволах, шейперах и т.п. Очень частая проблема это как раз файрвол и манглы, делают разные защиты от взломов, ограничения ненужные - трафик проходит через десятки правил и проверок - это сильно снижает производительность.

Шейперов нет, FW, да, это рабочий инструмент, манглы только для реализации файловера, заворачивания запросов dns на себя любимого и блокировки софта неконтролируемых доступов. Все это необходимо в решении задач.

 

14 минут назад, Saab95 сказал:

Кроме всего зачем добавлять вланы в бридж?

Никто и не говорил, что вилана добавляются в бридж. Они именно и терминируются на маршрутизаторе. Виланы развернуты на бридже, на котором включен VLAN filtering, такова парадигма настройки и далее раздаются на коммутаторы. Отсюда я и задавался вопросом, что может конкретно на маршрутизаторе перестроить vlan-ы с бриджа на Switch Chip (вроде эти два варианта увязываемы между оборудованием), дабы отказаться от VLAN filtering на бридже, а далее опять же с помощью FastTrack (который может все же заработает?) упростить проход трафика между вовлеченными во внутренний обмен vlan-интерфейсами, как выше приводил пример.

[Saab95]

Можете перенастроить на свиччип, но на нем целых 3 свиччипа, это 1-5, 6-10 и 11-13 сетевые порты. Поэтому сетевые кабели нужно подключать так, что бы данные между этими свиччипами не ходили через процессор. Тогда трафик между вланами по Л2 не будет загружать процессор устройства.

[mrrc]

26 минут назад, Saab95 сказал:

Можете перенастроить на свиччип, но на нем целых 3 свиччипа

Ну на стенде с RB1100AHx2 пока два свиччипа.

То есть для терминирования серверной группы и порт от пользовательских подсетей завести на один из свитччипов (чтобы обмен обвязать в рамках одного чипа), а вход провайдеров и нетребовательного к нагрузкам подключения сделать на втором, если я верно улавливанию вашу мысль.

 

26 минут назад, Saab95 сказал:

Тогда трафик между вланами по Л2 не будет загружать процессор устройства

Ну трафик по L2 в рамках вилана (подсети) у меня и не загружает процессор на всем вовлеченном оборудовании, загружает процессор трафик по L3 как раз между посетями виланов при внутренней маршрутизации на маршрутизаторе.

Изменено 15 февраля, 2023 пользователем mrrc

[mrrc]

21 час назад, Saab95 сказал:

Можете перенастроить на свиччип, но на нем целых 3 свиччипа, это 1-5, 6-10 и 11-13 сетевые порты. Поэтому сетевые кабели нужно подключать так, что бы данные между этими свиччипами не ходили через процессор. Тогда трафик между вланами по Л2 не будет загружать процессор устройства.

На RB1100AHx2 добился результата, переведя на нем vlan-ы с бриджа на Switch Chip заработал и FastTrack, почти удвоив скорость обмена между подсетями вланов, не повредив функциональность ros.

Но на продакшн устройстве RB1100AHx4 другие Switch-chip-ы используются, а они согласно wiki не поддерживают VLAN-таблиц и взлетит ли решение там еще не пробовал.

[SUrov_IBM]

Mrrc, здравствуйте.

 

Если верить анонсу, то начиная с RouterOS версия 7.1rc1 (2021-Aug-19 13:06):

"*) added bridge HW offload support for vlan-filtering on RTL8367 switch chip (RB4011, RB1100AHx4)"

 

У меня Mikrotik hEX S после перехода на RouterOS v 7.x стал поддерживать switch chip, недоступный для RouterOS v 6.

 

Возможно и Вашем случае это поможет, но нужно учесть - работа "аппаратной разгрузки" возможна только в приделах оного конкретно взятого чипа, но не между чипами в коммутатора / маршрутизаторе.

[mrrc]

@SUrov_IBM Добрый вечер, спасибо за информацию!

Тут проблема скорее в ограничениях от Fast Path-а, который не дружит с vlan-filtering, а из-за этого не отрабатывают правила FastTrack-а. Сам по себе HW offload support for vlan-filtering может и не сделать существенной погоды. Но все это предположения, лишенные практики.

Думаю, разумно будет пойти по пути перевода вланов с бриджа на чип, а если на RB1100AHx4 это не сработает (хотя странно, с более младшей моделью RB1100AHx2 все удалось), тогда смотреть в сторону перехода на 7.х, просто если уходить на эту ветку, скорее всего потянет за собой апгрейд и всего комплекса остального оборудования, от 6.х хотя бы точнее знаешь, чего ожидать, так сказать. Про обвязку ресурсоемкого обмена в рамках одного чипа я понял, вписываюсь в его пять портов.

Но что я не питаю особой надежды:

 

Цитата

Warning: Not all devices with a switch chip are capable of VLAN switching on a hardware level, check the supported features for each switch chip, the compatibility table can be found Here. If a device has VLAN table support, then it is capable of VLAN switching using the built-in switch chip.

 

Цитата

 

RTL8367

Vlan table no

 

 

Изменено 16 февраля, 2023 пользователем mrrc

[sol]

Посмотрите чем закончилась моя тема относительно FastTrack

 

[sirmax]

@Saab95ну где вы?

[Saab95]

/ip firewall mangle
add action=fasttrack-connection chain=prerouting

Вот так фасттрак включается.

[alibek]

Или не включается, если ограничения и условия не соблюдены.

Вы смысл слова "включается" правильно понимаете?

Речь не о том, чтобы указать его в настройке, а о том, чтобы он реально работал.

[mrrc]

10 часов назад, sol сказал:

Посмотрите чем закончилась моя тема относительно FastTrack

А ничем. Очередными дебатами с саабом.
У меня возможность применения FastTrack-а в решении задачи направлено именно на внутрисетевой обмен, задействуя быстрый путь только для общения подсетей vlan-интерфейсов между собой. И оно работает, на имеющемся стенде, во всяком случае. Но поднялось только после отключения влан фильтеринга на бридже и переноса с него vlan-ов на свиччип (изменения парадигмы настройки vlan на маршрутизаторе).

 

8 часов назад, Saab95 сказал:

Вот так фасттрак включается.

Для чего включается и где о об этом говорится в документации по FastTrack?
Быстрый путь нужен мне для обмена непосредственно между подсетями интерфейсов, через которые происходит высокая нагрузка.

Изменено 17 февраля, 2023 пользователем mrrc

[jffulcrum]

В одном Сааб прав - роутер должен маршрутизировать, а не коммутировать. Для коммутации у МТ есть отдельная линейка обородования.

[mrrc]

Соглашусь, кесарю - кесарево.

Но тогда вопрос, кто должен осуществлять маршрутизацию подсетей vlan. Коммутатор L3, получается, лишенный обременений в виде FW и т.п., на который переносится и терминирование vlan в таковом случае с маршрутизатора.

[jffulcrum]

На маршрутизаторе VLAN терминируются. То есть там не надо делать L2 функционала с мостами, VLAN создаются просто как интерфейсы, дочерние к портам. А приходят они с коммутатора ядра.

 

Что касается скоростей, то тут или делать FW многопоточным, через chains, или fastTrack, включению которого уже не будет таких помех.