+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Тайны мостов в RouterOS раскрыты

Тайны мостов в RouterOS раскрыты, RouterOS

sindy

Guest

21.03.2021 17:51:00

Эта тема посвящена реакции на многочисленные случаи недоразумений по поводу того, почему "сам мост" (bridge) в некоторых случаях должен быть указан среди тегированных или нетегированных портов VLAN, почему VLAN-интерфейсы должны быть привязаны к "мосту", а не к его составным портам и так далее. То, что в сетевой терминологии слова "интерфейс" и "порт" имеют несколько значений, вносит дополнительную путаницу. В этой теме не рассматриваются детали "нового" способа обработки нескольких VLAN на одном мосту; для этого есть отличная тема от @pcunite. Итак, начнем с картинки аппаратной схемы:

Здесь всё понятно: есть коммутатор, который отвечает за L2-перенаправление и фильтрацию VLAN, и к одному из физических Ethernet-портов этого коммутатора с помощью одного из физических Ethernet-портов роутера подключен сам роутер. Мы можем указать коммутатору, какие VLAN разрешены на каждом порту, другими словами — какие порты входят в каждый VLAN. На коммутаторе может работать какой-то вариант Spanning Tree Protocol, чтобы предотвратить L2-петли из-за неправильного подключения. В продвинутых моделях фильтры могут контролировать передачу кадров с входного (ingress) порта на выходной (egress).

На роутере мы можем назначить IP-адрес напрямую физическому интерфейсу; если хотим, чтобы роутер имел доступ к нескольким VLAN, то можно использовать столько физических интерфейсов, сколько нужно, и подключать каждый к Access-порту соответствующего VLAN на коммутаторе. Но лучше подключить физический интерфейс роутера к trunk-порту коммутатора и для каждого VLAN создать виртуальный VLAN-интерфейс, привязанный к этому физическому интерфейсу. Виртуальный VLAN-интерфейс выбирает из кадров, поступающих через физический интерфейс, те, что с нужным VLAN ID, снимает с них тег и передаёт дальше на движок маршрутизации. В направлении назад (egress) движок маршрутизации посылает кадры через этот интерфейс, они получают нужный VLAN ID, и выходят через физический интерфейс.

Для наглядности можно использовать чуть более абстрактную схему для представления той же архитектуры:

Эта диаграмма всё ещё отражает топологию, показанную на первом рисунке, только с немного иной точки зрения. Абстракция позволяет забыть о физической природе компонентов и сосредоточиться только на их функционале. Даже если большую часть реализации мы сделаем в чистом софте, роли функциональных частей не поменяются: остаётся роутер с одним интерфейсом, подключённым к одному порту коммутатора, сам коммутатор и его другие порты.

Теперь программный модуль под названием "bridge" в RouterOS реализует три вышеперечисленных элемента: интерфейс роутера, направленный на коммутатор, порт коммутатора, направленный на роутер, и сам коммутатор.

Ниже иллюстрация этого:

Пока всё предельно понятно, не так ли? А теперь — о запутанных моментах. Когда вы добавляете "bridge", создаются все три компонента (интерфейс роутера, порт коммутатора и сам коммутатор), взаимосвязь между ними жёстко фиксирована, ни у одного из компонентов нет параметра конфигурации, который бы пересекался с параметрами двух других. Параметры всех трёх элементов собраны в одной строке таблицы /interface bridge.

В частности:
- параметры, совпадающие по названию с параметрами в строках /interface bridge port, например pvid или ingress-filtering, относятся к порту коммутатора, направленному на роутер;
- параметры, совпадающие по названию с параметрами в строках /interface ethernet, например mtu или arp-timeout, относятся к интерфейсу роутера, направленному на коммутатор;
- параметры, которые не подходят ни под одну из двух групп, в основном относятся к виртуальному коммутатору. Исключением являются параметры admin-mac и auto-mac, которые тоже относятся к интерфейсу роутера, направленному на коммутатор.

Параметр name общий для всех трёх элементов.

Поэтому, когда указывают членство порта коммутатора, направленного на роутер, в VLAN, используется одно и то же имя для идентификации и самого виртуального коммутатора, и порта роутера:

/interface bridge vlan add bridge=bridge-row-name vlan-ids=10,… tagged=bridge-row-name,…

В фильтрах моста связь кадра с портом коммутатора, направленным на роутер, определяет, какую цепочку (chain) использовать: input обрабатывает кадры, выходящие из виртуального коммутатора через этот порт, output — кадры, входящие в виртуальный коммутатор через этот порт, а forward — кадры, которые обходят этот порт.

Zacharias

Guest

12.11.2021 18:36:00

@sindy , To my understanding, what you describe as the switch-facing interface of the router, and the router-facing port of the switch is actually what enables the switch to communicate with the CPU of the Device (Management Access, Layer 3 Services and more ), the communication line of the switch with the Routing Block ( Switch - > CPU Port ). So the Bridge consists of the Switching Block and the Switch-CPU Port. Am i missing something ?

sindy

Guest

12.11.2021 19:04:00

It’s unfortunately not that simple. The internal Ethernet link between the physical switch chip and the CPU is not a 100 % functional equivalent of the link between the router-facing port of the virtual switch and the virtual-switch-facing port of the router. VLAN frames from wireless and L2-tunnel interfaces can flow to and from the virtual switch even if the router-facing port of the virtual switch is not a member one of the respective VLAN. But the /interface vlan attached to the virtual-switch-facing interface of the router can only send/receive traffic to/from the virtual switch if the respective VLAN is allowed on the router-facing port of the virtual switch.

Zacharias Guest	#4 0 13.11.2021 11:08:00 Yes, but how can you not include the CPU Port in the Bridge Entity ?

Amm0

Guest

13.11.2021 19:47:00

I think that gist of @sindy ’s description while it’s convenient to think of the “bridge” as being the L2 access to “CPU port”, like it for “/ethernet switch”. And, this simplifying assumption likely works in most cases – e.g. you probably need to add the bridge as a VLAN port in Bridge VLANs if you’re doing L3 stuff too. But that’s not exactly true in all cases. And, it’s also a counter-intuitive configuration: treating the bridge as a port in the VLAN tab, while a lot of times necessary, isn’t natural esp. if you think of “classic” access port/truck terms. So the “router side” and “bridging side” way of describing “under the covers” of the “new VLAN method” is actually a helpful way if you’re trying to understand the “why you need to add the bridge as port”. @pcunite VLAN manifesto describes the various options, some good practices, and mechanics, BUT not the why. And @SiB is also right, some pictures next to packet traces/“L2 frames breakouts” is awful helpful way of presenting it. While the Vinn diagram shows the multi-faceted roles, it doesn’t actually help understanding the relationships.

sindy

Guest

13.11.2021 20:31:00

Easily. The bridge is a software thing, and so is the router, so both run “inside” the CPU, hence the traffic between the “software switch” facing “software port” of the “software router” and the “software router” facing “software port” of the “software switch” never passes across the CPU port. Think of CCR or CHR where no switch chips exist and bridging is nevertheless possible. Hardware-wise, the CPU port ↔ switch chip port connection is inside the bridge, not between the bridge and the router. A frame coming from the wire first hits the Ethernet port of the switch chip, then it gets sent via the CPU-facing port of the switch chip to the physical-switch-facing port of the CPU, and only then it gets to the “software router” facing “software port” of the “software switch” (or doesn’t, if it instead gets forwarded to the “software switch” port to which a wireless interface or an L2 tunnel interface are connected). Internally, the “hardware accelerated bridging” in fact means that one of the ports of the full-software bridge is the switch-chip-facing port of the CPU, so frames that can be forwarded directly between Ethernet ports of the switch chip don’t ever get to the CPU. But the aim of the concept is not to bother the administrator with these under the hood details and let them see it as a single bridge with both physical and virtual ports.

Zacharias Guest	#7 0 14.11.2021 18:10:00 Ok @sindy i agree… the CPU port ↔ switch chip port connection is inside the bridge So it is part of the Bridge Entity…

mkx

Guest

14.11.2021 18:40:00

I don’t think it matters how things are implemented to the last detail. Surely implementation is different on devices with switch chip from implementation on devices without switch chip. Only MT developers can tell how exactly are things implemented under the hood. What matters is conceptual design and that one is same for all devices. Understanding concept is key to using bridge correctly and effectively. And first post of this thread explains concept quite nicely. Even if I personally agree with explanation by @sindy this doesn’t mean it’s entirely correct. Too bad nobody from Mikrotik chimed in to add any details (or even only to tell that @sindy ’s explanation is spot on).

Guscht

Guest

02.01.2022 20:48:00

AFAIU the CPU-Port is called the same as the bridge. This is very confusing, MT should have named this “CPU-Port” or something. Short explanation: If the CPU-Port is set untagged, this is the only way to communicate with the Bridge Interface (itself) and services “behind”, like DHCP, NTP… In this state “bridge1” is CPU-Port and Interface. If the CPU-Port is set tagged, you will need a dedicated VLAN-Interface - bound to the bridge. But you wont be able to connect to the Bridge Interface itself! Services behind are reached through this dedicated VLAN-interface via the CPU-Port (called “bridge1”, but this refers to the CPU-Port only - not to the Bridge as dedicated Interface). Long explanation: Default settings without any VLAN-Interfaces, the Bridge is CPU-Port and Interface at the same time:

DHCP will work:

Same settings, changing to “tagged only” results in a total connectivity lost :

Now, the ingress-setting filters all tagless/untagged traffic, but the Frames get tagless/untagged forwarded to the Bridge-Interface+CPU-Port (as defined in the first picture). Now we change the VLAN-setting, placing the CPU-Port into tagged state:

At this point the connectivity is lost as well! For my understanding the bridge itself (as Interface AND CPU-Port) can work only untagged . Why was the connectivity lost? Via the PVID the ingressing frame gets its (internal) tag. Via the VLAN-tab the bridge/CPU-Port is egressed tagged as well… I see no other conclusion, the bridge-interface+CPU-Port works only untagged. Now, we enable/create a VLAN-Interface, bound to the bridge:

And suddenly, in a mysterious way, everything works again:

To me, it seems the way you place the bridge/CPU-Port into tagged or untagged state triggers something: CPU-Port/bridge = untagged → in this state, the only working settings (in the bridge/VLAN) menu are “admit all” and “admit only untagged…” . This refers to the Interface and the CPU-Port. CPU-Port/bridge = tagged → in this state, the bridge-interface itself wont work anymore (because the frame to it are tagged). The only working settings are “admit all” and “admit only tagged…”. But they refer to the CPU-Port only (as the Bridge-Interface isnt reachable anymore) → VLAN-Interfaces bound to the bridge.

And this is very confusing to me and to all I have spoken! I dont understand why MT has created such a “Frankenstein-like” monster as their VLAN-Implentation. I have never seen such a complicated way (and undocumented too) by any other vendor. Id recommend simply not to deal with the Bridge as dedicated Interface. Simply create VLAN-interfaces, bound them to the bridge and see the “bridge itself” as CPU-Port (under Bridge → VLAN).

SiB Guest	#10 0 03.01.2022 01:10:00 I think that before v7.20 we will know next generation of “new vlan setup”, we should create some versioning for that. PS. Nice post.

Zacharias Guest	#11 0 03.01.2022 11:18:00 Well yes, If you want to use the Bridge Interface itself and the Bridge CPU port for Management access then you must use untagged Traffic. If you want to allow only Tagged Traffic to the Bridge Interface then you must create a VLAN Interface and access the CPU Port through that ( and ofcorse the appropriate VLAN configuration is needed ) …

sindy

Guest

#12

03.01.2022 14:00:00

@Guscht , the “CPU port” is an oversimplification, based on an assumption that CPU is equivalent to the router process and that the bridge process runs somewhere else than on the CPU. If this simplification helps you understand the concept, stick with it, but actually the “port of the virtual switch” and “interface of the virtual router” form up the demarcation line between the bridge process and the router process, which both run at the CPU. This confusing blending of multiple logical objects into a single one is not an invention of the Mikrotik team - this is how bridge is implemented in Linux kernel and represented in its configuration layer. What I likely haven’t stressed enough in my OP is that the /interface vlan configuration is related to the router part, and the /interface bridge vlan configuration is related to the virtual switch part. So there is nothing surprising on the fact that if a tagless frame carrying an IP packet arrives to an Ethernet port of a virtual switch with pvid=N , it will only reach the router process if either the pvid of the “router-facing port of the virtual switch” is also N , or if an /interface vlan with vlan-id=N is attached to the “bridge-facing port of the router”. In the former case, the in-interface as seen by the router will be the “bridge-facing port of the router” itself; in the latter one, it will be that /interface vlan . What I find annoying is that you cannot set pvid to none to get all VLANs tagged at the respective port, i.e. there must always be some “native vlan” associated to each port (including the “router-facing virtual port of the virtual switch”).

Amm0 Guest	#13 0 03.01.2022 14:53:00 Yup that’s a problem & very cleaver/clean solution. Wish MT did that.

tdw Guest	#14 0 03.01.2022 16:53:00 If you set ingress-filtering=yes frame-types=admit-only-vlan-tagged on a port it removes the untagged membership, i.e. the pvid= setting is ignored, making the port tagged-only.

sindy

Guest

#15

03.01.2022 17:44:00

Wow, thank you, it seems I haven’t checked the behaviour for a long time… actually, it seems it’s even not necessary to activate the ingress-filtering to make the port accept frames tagged with the VID which is set as the pvid of that port, as adding the interface explicitly to the tagged list on / interface bridge vlan row for that VID prevents/supersedes the automatic addition of the port to the untagged list. [me@myTik] > interface bridge port print detail where interface=ether5
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload
0 interface=ether5 bridge=bridge priority=0x80 path-cost=10 internal-path-cost=10 edge=auto point-to-point=auto learn=auto horizon=none hw=no auto-isolate=no restricted-role=no restricted-tcn=no
pvid=3333 frame-types=admit-all ingress-filtering=no unknown-unicast-flood=yes unknown-multicast-flood=yes broadcast-flood=yes tag-stacking=no bpdu-guard=no trusted=no
multicast-router=temporary-query fast-leave=no
[me@myTik] > interface bridge vlan print where vlan-ids=3333
Flags: X - disabled, D - dynamic
# BRIDGE VLAN-IDS CURRENT-TAGGED CURRENT-UNTAGGED
0 bridge 3333 bridge
ether5 Of course, it does make sense to use ingress-filtering to prevent tagless frames from being accepted on that port (and probably tagged with the VID stated in its pvid ). So it should even be possible to handle the “mysterious” VLAN 1 on the bridge using an /interface vlan , by adding “bridge” (the router-facing port of the virtual switch) to the tagged list on the /interface bridge vlan row with vlan-ids=1 .

Zacharias Guest	#16 0 03.01.2022 19:04:00 @sindy , That is documented in the manual.. When frame-type=admit-only-vlan-tagged is used on a port, then the port is not dynamically added as an untagged port for the PVID. Source: https://help.mikrotik.com/docs/display/ROS/Bridge+VLAN+Table

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры