[nixx]

есть типовая задача - прилетающие с разных офисов eoip-каналы надо запихивать во вланы, и дальше уже производить с ними всякий роутинг/нат и т.д. ("дальше" к данному вопросу не относится и делается не на микротиках).

знаю два варианта реализации:

1) создаем влан-интерфейс на ether-порту микротика и бриджуем его персональным бриджом с еоип-каналом (число бриджей равно числу вланов/каналов)

2) создаем бридж с включенной влан-фильтрацией, вешаем на него все вланы как вланы (Bridge -> VLANs), а не как интерфейсы, и в нем же бриджуем соответствующие вланы с еоип-каналами

 

второй вариант более нравится по причине его внешней простоты и легкости по сравнению с первым (тупо меньше на экране всякого болтается ))

при этом у второго варианта вижу минус - нельзя бриджевать влан с вланом (ну т.е. технически невозможно соединить один с другим)

 

но таки переделал конфиг под второй вариант (ни трафика, ни вообще чего бы то ни было не изменилось) и получил... удвоение нагрузки на процы. было 20-30 процентов, сейчас 50-55.

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

 

вопрос - в целях оптимальной производительности я обречен на болтающиеся в конфиге нцать бриджей по числу каналов/вланов, или же я что-то не так делаю?

 

ps: микротик hEX.

[jffulcrum]

9 часов назад, nixx сказал:

удвоение нагрузки на процы. было 20-30 процентов, сейчас 50-55.

 

Если вы софт-интерфейсы пихаете в мосты, выключается  все: HW offload, FastForward и прочее. В Tools - Profile посмотрите, на что приходится нагрузка. Ну и плюс в одном большом мосту широковещательные пакеты будут проверяться по всем дыркам.

[nixx]

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

в обоих случаях по profile проц кушает процесс networking - в случае первого варианта слабее, второго - сильнее. всё остальное близко к нулям.

но куда полезут широковещательные пакеты, если в бридже четко сказано "вот этот влан с вот этим еоипом"?

 

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

 

ps: routeros 6.48.7, конфиг на ресетнутом "в ноль", только нужное.

 

Скрытый текст

/interface bridge add name=br-main protocol-mode=none vlan-filtering=yes
/interface eoip add mac-address=02:A3:C8:74:4B:32 mtu=1500 name=eoip-2813-1001 remote-address=77.88.7.8 tunnel-id=1001
/interface eoip add mac-address=02:4E:C8:70:F3:3D mtu=1500 name=eoip-2009-1002 remote-address=22.33.5.6 tunnel-id=1002
/interface bridge port add bridge=br-main interface=ether1
/interface bridge port add bridge=br-main interface=eoip-2009-1002 pvid=2009
/interface bridge port add bridge=br-main interface=eoip-2813-1001 pvid=2813
/interface bridge vlan add bridge=br-main tagged=ether1 untagged=eoip-2009-1002 vlan-ids=2009
/interface bridge vlan add bridge=br-main tagged=ether1 untagged=eoip-2813-1001 vlan-ids=2813

примерно так второй вариант выглядит

 

Edited July 20, 2023 by nixx

[weedman]

Предположу - посмотрте как настраивать меню switch для данного роутера, может так прекинете нагрузку с цпу на свитч-чип, но это предположение.

[Negator]

Я наоборот вланы пихаю в EOIP каналы. И внутри все с тегом. Для меня так логичнее.

А чаще в VPLS, VPLS быстрее

Ну и далее по 2 варианту.

[jffulcrum]

Bridge VLAN Filtering без HW offload гораздо процессорозатратнее обычных игрищ с мостами, так уж устроено. В том числе потому, что процу приходится матчить каждый широковещательный пакет с каждым портом моста, про это упоминалось на MUM когда эту фичу вводили. FIB или в железе, или ее вообще нету.

[nixx]

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

Bridge VLAN Filtering без HW offload гораздо процессорозатратнее обычных игрищ с мостами, так уж устроено. В том числе потому, что процу приходится матчить каждый широковещательный пакет с каждым портом моста, про это упоминалось на MUM когда эту фичу вводили.

за это уточнение огромное спасибо. с учетом того, что у меня там ожидается эдак под 150+ еоипов и вланов - перспективы роста нагрузки великолепны ))

значит, остаюсь на старом варианте.

[Negator]

это на обычном hex 150 eoip и vlan ?

 

[nixx]

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

это на обычном hex 150 eoip и vlan ?

ну да. а что? вопрос в объеме трафика, от которого напрямую зависит нагрузка, а не в количестве каналов. сейчас у меня 100 с копейками мегабит по сотне каналов бегает, как оказалось.

про 150 я соврал, тут все 250 будет... )

[jffulcrum]

Тут уже на какой-нибудь 3011 или 4011 прицелиться стоит

[nixx]

12 часов назад, jffulcrum сказал:

Тут уже на какой-нибудь 3011 или 4011 прицелиться стоит

вообще ccr1009 (или 1100ahx4) ожидается, но это если hex до 40-50% по обоим ядрам доползет. пока ему очень далеко )

график процессоров - это сумма загрузки ядер. т.е. максимум там 400.

[Saab95]

Цитата

Тут уже на какой-нибудь 3011 или 4011 прицелиться стоит

Нет, они медленные, самое выгодное это CCR1009, он быстрее 4011 будет и есть 10Г порт.

 

Цитата

с учетом того, что у меня там ожидается эдак под 150+ еоипов и вланов - перспективы роста нагрузки великолепны

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

 

У нас несколько лет назад работала такая схема, только в центре стоял CCR1036 и сливал данные через 10Г порт на брас, который разбирал абонентские вланы. А абонентские вланы приходили в EoIP туннелях (в центре все арп и изучения маков были отключены). Вторая сторона EoIP была заведена на большом количестве микротиков, к которым подключались коммутаторы и вланы с них бриджевались в EoIP, на них тоже арп и изучение маков было отключено.

 

Было в пике чуть поболее 3000 EoIP интерфейсов (соответственно 3000 вланов и 3000 бриджей), трафика около 5Г максимум. Загрузка была под 70-80 процентов. Никакого НАТ и прочих других настроек на устройстве не было. Зависаний и проблем так же не возникало. Работала эта схема во время перевода одной сети со схемы L2 в центр на схему полного L3, т.к. транзит L2 уже был не возможен, т.к. шла замена транспортного оборудования.