[sol]

Коллеги, тут в одной конторе встретил интересную схему работы:

Есть несколько микротиков на TILE архитектуре. Разных. Везде сделано след. образом Порты собраны в бридж и уже на бридже нарезаны виланы и т.д. Местные говорит что "так заведено", и что это "True путь, офф. рекомендация микротика, под такую схему в Латвии пилится и оптимизируется софт".

 

Мне же это всё видится надуманным и странным. Ибо плодит лишние сущности. Это же TILE, там нет свитч-чипов и каждый порт сам по себе. Решительно не понятно для чего собирать пачку портов в бридж если не надо, собственно, бриджевать.

 

Сам я в микротах не шибко. Прошу комментариев общественности.

[alibek]

Кто как привык, тот так и делает.

[sol]

Т.е. заметных "противопоказаний" нет?

[jffulcrum]

Надо смотреть вглубь, возможно роутер всё-таки и мостом между сегментами на L2 выступает, или есть какие-то пакетные правила/ACL на L2. 

[Кошачии ловец]

23 часа назад, sol сказал:

Коллеги, тут в одной конторе встретил интересную схему работы:

Есть несколько микротиков на TILE архитектуре. Разных. Везде сделано след. образом Порты собраны в бридж и уже на бридже нарезаны виланы и т.д. Местные говорит что "так заведено", и что это "True путь, офф. рекомендация микротика, под такую схему в Латвии пилится и оптимизируется софт".

 

Мне же это всё видится надуманным и странным. Ибо плодит лишние сущности. Это же TILE, там нет свитч-чипов и каждый порт сам по себе. Решительно не понятно для чего собирать пачку портов в бридж если не надо, собственно, бриджевать.

 

Сам я в микротах не шибко. Прошу комментариев общественности.

Ерунда все это

[sol]

3 часа назад, jffulcrum сказал:

Надо смотреть вглубь, возможно роутер всё-таки и мостом между сегментами на L2 выступает, или есть какие-то пакетные правила/ACL на L2. 

Это понятно. Если нет свитччипа то ясно и игелю, что единственный способ соединить пару виланов на разных порта - это бридж.

 

У меня-то речь про другое. В конторе бытует мнение, что описанный мною вариант это типа труъ путь.

[jffulcrum]

MT тем и хорош - гибкостью и напиханным функционалом. Нет какого-то единственного Tru-пути. Я с ними 15 лет вожусь, и до сих пор удивляют попадающиеся реализации.

[gger]

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

Это понятно. Если нет свитччипа то ясно и игелю, что единственный способ соединить пару виланов на разных порта - это бридж.

 

У меня-то речь про другое. В конторе бытует мнение, что описанный мною вариант это типа труъ путь.

Решал подобную задачу год назад.

из плюсов- удобное чтение конфига.

из минусов - 1-4% нагрузки цпу за функцию «бридж»

[Negator]

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

На остальные порты просто навешиваем вланы по необходимости.

И для этого выделили еще один порт в микротик.

Правильно это или нет, но работает, и вланов пару сотен и все прочее там есть.

[nixx]

В 12.04.2024 в 14:42, sol сказал:

Есть несколько микротиков на TILE архитектуре. Разных. Везде сделано след. образом Порты собраны в бридж и уже на бридже нарезаны виланы и т.д. Местные говорит что "так заведено", и что это "True путь, офф. рекомендация микротика, под такую схему в Латвии пилится и оптимизируется софт".

 

Мне же это всё видится надуманным и странным. Ибо плодит лишние сущности. Это же TILE, там нет свитч-чипов и каждый порт сам по себе. Решительно не понятно для чего собирать пачку портов в бридж если не надо, собственно, бриджевать.

https://forum.nag.ru/index.php?/topic/186709-varianty-bridzhinga-proizvoditelnost/

я страдал подобным. лучше не надо.

эта схема правильна для свитчей CRS, но никак не для роутеров, насколько я понял, - на роутерах получаете перерасход cpu, и далеко не 1-4 процента, как выше пишут.

Изменено 21 апреля пользователем nixx

[Saab95]

В 13.04.2024 в 23:49, gger сказал:

Решал подобную задачу год назад.

из плюсов- удобное чтение конфига.

из минусов - 1-4% нагрузки цпу за функцию «бридж»

Забыли еще один плюс - быстрая смена интерфейса.

 

В 12.04.2024 в 17:36, sol сказал:

Т.е. заметных "противопоказаний" нет?

Например на роутере 200 интерфейсов вланов, а может быть и 1000. Вдруг порт сбоит и надо срочно перекинуть на другой - в случае бриджа достаточно в одном месте имя интерфейса изменить и все. В случаев вланов на интерфейсе нужно всем 200 или 1000 вланам настройки поменять, что приведет к переактивации интерфейса, а с ним и IP адреса, DHCP сервера (если висят на каждом влане) и т.п.

 

В 13.04.2024 в 16:40, sol сказал:

У меня-то речь про другое. В конторе бытует мнение, что описанный мною вариант это типа труъ путь.

А как иначе - конфиг везде однотипный, нет привязки к интерфейсам. Есть бриджи вида bridge1, bridge2 и т.п. с такими именами идет вся работа, легко автоматизировать и разбивать интерфейсы (бриджы) по типам. А то на одном роутере будет ether1, на другом sfp1, на третьем sfp-sfpplus1, на другом sfpplus1, еще может быть combo или всякие там sfp28, а что через пару лет будет с гипотетическим sfp50 или sfp100.

 

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

[sol]

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

Например на роутере 200 интерфейсов вланов, а может быть и 1000. Вдруг порт сбоит и надо срочно перекинуть на другой - в случае бриджа достаточно в одном месте имя интерфейса изменить и все. В случаев вланов на интерфейсе нужно всем 200 или 1000 вланам настройки поменять, что приведет к переактивации интерфейса, а с ним и IP адреса, DHCP сервера (если висят на каждом влане) и т.п.

Антон, если у вас 100+ виланов, то у вас есть скрипт, который генерирует этот конфиг. Без вариантов. Ибо руками такое делать может только очень странный человек. И при наличии скрипта проблема становится высосанной из пальца. Сменился интерфейс - перегенерировался конфиг.

 

Ну и как всегда, вы на волне радио "Восхваление ФМ". Вопрос был не про мифическое "удобство", а про то, действительно ли такая схема есть расово верная и действительно ли софт пилится под неё или это всё домыслы.

 

[Saab95]

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

если у вас 100+ виланов, то у вас есть скрипт, который генерирует этот конфиг. Без вариантов. Ибо руками такое делать может только очень странный человек. И при наличии скрипта проблема становится высосанной из пальца. Сменился интерфейс - перегенерировался конфиг.

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

 

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

 

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

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

При наличии системы автоматизации очень удобно иметь интерфейсы именно в виде бриджей. Видели, наверное, в новых прошивках микротика появился интерфейс с именем lo, то есть loopback. А ранее его не было. И не факт, что через несколько версий прошивок его не переименуют в loopback уже.

 

Кроме всего на wi-fi устройствах микротика, обычно беспроводной интерфейс имеет имя wlan1, а на устройствах с двумя интерфейсами бывает так, что нужный интерфейс имеет имя wlan2, а wlan1 не используется.

 

Поэтому и выгодно использовать бриджи - loopback для внутреннего IP, bridge_wlan для работы с радио, bridge_ptp для мостов, bridge_ap и bridge_cpe соответственно на базах и клиентах. По кабелям bridge_pon интерфейс ПОН сети, bridge_sw интерфейс дальнейшей разводки на коммутаторах и т.п.

 

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