Объясните, зачем нужен Bridge в Mikrotik?

Зарегистрирован: 13.08.2008
Пользователь #: 70,537
Сообщения: 315

Зарегистрирован: 22.01.2016
Пользователь #: 160,064
Сообщения: 9205

Зарегистрирован: 19.05.2010
Пользователь #: 87,707
Сообщения: 286

Зарегистрирован: 22.01.2016
Пользователь #: 160,064
Сообщения: 9205

Зарегистрирован: 13.08.2008
Пользователь #: 70,537
Сообщения: 315

Зарегистрирован: 13.08.2008
Пользователь #: 70,537
Сообщения: 315

Зарегистрирован: 13.08.2008
Пользователь #: 70,537
Сообщения: 315

Зарегистрирован: 13.08.2008
Пользователь #: 70,537
Сообщения: 315

Зарегистрирован: 22.01.2016
Пользователь #: 160,064
Сообщения: 9205

Зарегистрирован: 13.08.2008
Пользователь #: 70,537
Сообщения: 315

Источник

Стоит заметить, что существует не один способ организации VLAN трафика на Mikrotik. Но только один из этих способов конфигурации VLAN является наиболее корректным, позволяющим исключить проблемы с производительностью и подключением.

Начиная с версии RouterOS 6.41 стало возможно использовать мост для фильтрации VLAN и именно эта конфигурация рекомендована официальным Wiki Mikrotik.

Освоить MikroTik Вы можете с помощью онлайн-куса « Настройка оборудования MikroTik ». Курс основан на официальной программе MTCNA. Автор курса – официальный тренер MikroTik. Подходит и тем, кто уже давно работает с микротиками, и тем, кто еще их не держал в руках. В курс входит 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект.

Рассмотрим базовую конфигурацию VLAN позволяющую разделить локальную сеть на два виртуальных сегмента для разных отделов офиса.

Базовая схема коммутации VLAN

Для начала нам необходимо создать мост bidge1 с фильтрацией VLAN. Для включение фильтрации VLAN перейдите во вкладку VLAN и отметьте пункт «VLAN Filtering».

Мост с фильтрацией VLAN

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

Добавляем порты в мост bidge1 и назначаем им PVID.

Добавление access порта с PVID в bridge

Добавляем соответствующие записи в VLAN таблицу моста.

VLAN таблица моста

В случае работающей VLAN фильтрации на bridge таблица VLAN выглядит примерно так:

Освоить MikroTik Вы можете с помощью онлайн-куса « Настройка оборудования MikroTik ». Курс основан на официальной программе MTCNA. Автор курса – официальный тренер MikroTik. Подходит и тем, кто уже давно работает с микротиками, и тем, кто еще их не держал в руках. В курс входит 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект.

Всё гениально и просто.
Спасибо кеп!

Подскажите пожалуйста, в некоторых мануалах видел, что на этапе добавления записей в таблицу VLAN добавляют помимо портов еще и бридж, в каких случаях это нужно делать, а в каких нет?

Если вы повесите vlan на бридж, то он будет доступен на всех интерфейсах (портах) входящих в этот бридж, вот и все.

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

Не понимаю о чем вы, что за доступ к процессору и порты cpu? Бридж не может быть никаким портом cpu! Если вы работаете с vlan, то вам нужно для начала понять что это такое, разобраться в понятиях trunk и access порта. И тогда больше не будете терять доступ к управлению микротиком.
Если вы хотите в порт микротика отправлять vlan и при этом чтобы подключенный на этот порт клиент работал без vlan (не умеет работать с vlan), то вам нужен access порт.

Не надо создавать фильтрацию vlan на существующем бридже, через который осуществляется управление микротиком. Здесь ключевое слово СОЗДАТЬ мост.

У вас по записям и по картинкам как раз и управление и фильтрация на одном бридже bidge1

Источник

Manual:Interface/Bridge

Applies to RouterOS: v3, v4+

Contents

Summary

Ethernet-like networks (Ethernet, Ethernet over IP, IEEE 802.11 in ap-bridge or bridge mode, WDS, VLAN) can be connected together using MAC bridges. The bridge feature allows the interconnection of hosts connected to separate LANs (using EoIP, geographically distributed networks can be bridged as well if any kind of IP network interconnection exists between them) as if they were attached to a single LAN. As bridges are transparent, they do not appear in traceroute list, and no utility can make a distinction between a host working in one LAN and a host working in another LAN if these LANs are bridged (depending on the way the LANs are interconnected, latency and data rate between hosts may vary).

Bridge Interface Setup

Sub-menu: /interface bridge

To combine a number of networks into one bridge, a bridge interface should be created (later, all the desired interfaces should be set up as its ports). One MAC address from slave (secondary) ports will be assigned to the bridge interface, the MAC address will be chosen automatically, depending on «port-number», and it can change after a reboot. To avoid unwanted MAC address changes, it is recommended to disable «auto-mac», and to manually specify MAC by using «admin-mac».

Properties

Example

To add and enable a bridge interface that will forward all the protocols:

Spanning Tree Protocol

RouterOS bridge interfaces are capable of running Spanning Tree Protocol to ensure a loop-free and redundant topology. For small networks with just 2 bridges STP does not bring much benefits, but for larger networks properly configured STP is very crucial, leaving STP related values to default may result in completely unreachable network in case of a even single bridge failure. To achieve a proper loop-free and redundant topology, it is necessary to properly set bridge priorities, port path costs and port priorities.

Warning: In RouterOS it is possible to set any value for bridge priority between 0 and 65535, the IEEE 802.1W standard states that the bridge priority must be in steps of 4096. This can cause incompatibility issues between devices that does not support such values. To avoid compatibility issues, it is recommended to use only these priorities: 0, 4096, 8192, 12288, 16384, 20480, 24576, 28672, 32768, 36864, 40960, 45056, 49152, 53248, 57344, 61440

STP has multiple variants, currently RouterOS supports STP, RSTP and MSTP. Depending on needs, either one of them can be used, some devices are able to run some of these protocols using hardware offloading, detailed information about which device support it can be found in the Hardware Offloading section. STP is considered to be outdated and slow, it has been almost entirely replaced in all network topologies by RSTP, which is backwards compatible with STP. For network topologies that depend on VLANs, it is recommended to use MSTP since it is a VLAN aware protocol and gives the ability to do load balancing per VLAN groups. There are a lot of considerations that should be made when designing a STP enabled network, more detailed case studies can be found in the Spanning Tree Protocol section. In RouterOS the protocol-mode property controls the used STP variant.

Note: By the IEEE 802.1ad standard the BPDUs from bridges that comply with IEEE 802.1Q are not compatible with IEEE 802.1ad bridges, this means that the same bridge VLAN protocol should be used across all bridges in a single Layer2 domain, otherwise (R/M)STP will not function properly.

Per port STP

There might be certain situations where you want to limit STP functionality on a single or multiple ports. Below you can find some examples for different use cases.

Warning: Be careful when changing the default (R/M)STP functionality, make sure you understand the working principles of STP and BPDUs. Misconfigured (R/M)STP can cause unexpected behaviour.

In this example BPDUs will not be sent out through ether1. In case the bridge is the root bridge, then loop detection will not work on this port. If another bridge is connected to ether1, then the other bridge will not receive any BPDUs and therefore might become as a second root bridge. You might want to consider blocking received BPDUs as well.

Note: You can use Interface Lists to specify multiple interfaces.

In this example all received BPDUs on ether1 are dropped. This will prevent other bridges on that port becoming a root bridge.

Warning: If you intend to drop received BPDUs on a port, then make sure to prevent BPDUs from being sent out from the interface that this port is connected to. A root bridge always sends out BPDUs and under normal conditions is waiting for a more superior BPDU (from a bridge with a lower bridge ID), but the bridge must temporarily disable the new root-port when transitioning from a root bridge to designated bridge. If you have blocked BPDUs only on one side, then a port will flap continuously.

In this example if ether1 receives a BPDU, it will block the port and will require you to manually re-enable it.

Bridge Settings

Sub-menu: /interface bridge settings

Note: In case you want to assign Simple Queues (Simple QoS) or global Queue Trees to traffic that is being forwarded by a bridge, then you need to enable the use-ip-firewall property. Without using this property the bridge traffic will never reach the postrouting chain, Simple Queues and global Queue Trees are working in the postrouting chain. To assign Simple Queues or global Queue Trees for VLAN or PPPoE traffic in a bridge you should enable appropriate properties as well.

Port Settings

Sub-menu: /interface bridge port

Port submenu is used to enslave interfaces in a particular bridge interface.

Example

To group ether1 and ether2 in the already created bridge1 bridge

Interface lists

Starting with RouterOS v6.41 it possible to add interface lists as a bridge port and sort them. Interface lists are useful for creating simpler firewall rules, you can read more about interface lists at the Interface List section. Below is an example how to add interface list to a bridge:

Ports from a interface list added to a bridge will show up as dynamic ports:

It is also possible to sort the order of lists in which they appear in the /interface bridge port menu. This can be done using the move command. Below is an example how to sort interface lists:

Note: The second parameter when moving interface lists is considered as «before id», the second parameter specifies before which interface list should be the selected interface list moved. When moving first interface list in place of the second interface list, then the command will have no effect since the first list will be moved before the second list, which is the current state either way.

Hosts Table

MAC addresses that have been learned on a bridge interface can be viewed in the /interface bridge host menu. Below is a table of parameters and flags that can be viewed.

Sub-menu: /interface bridge host

Monitoring

To get the active hosts table:

Static entries

Since RouterOS v6.42 it is possible to add a static MAC address entry into the hosts table. This can be used to forward a certain type of traffic through a specific port. Another use case for static host entries is for protecting the device resources by disabling the dynamic learning and rely only on configured static host entries. Below is a table of possible parameters that can be set when adding a static MAC address entry into the hosts table.

Sub-menu: /interface bridge host

For example, if it was required that all traffic destined to 4C:5E:0C:4D:12:43 is forwarded only through ether2, then the following commands can be used:

Bridge Monitoring

Sub-menu: /interface bridge monitor

Used to monitor the current status of a bridge.

Example

To monitor a bridge:

Bridge Port Monitoring

Sub-menu: /interface bridge port monitor

Statistics of an interface that belongs to a bridge.

(R/M)STP algorithm assigned role of the port:

Example

To monitor a bridge port:

Bridge Hardware Offloading

Since RouterOS v6.41 it is possible to switch multiple ports together if a device has a built-in switch chip. While a bridge is a software feature that will consume CPU’s resources, the bridge hardware offloading feature will allow you to use the built-in switch chip to forward packets, this allows you to achieve higher throughput, if configured correctly. In previous versions (prior to RouterOS v6.41) you had to use the master-port property to switch multiple ports together, but in RouterOS v6.41 this property is replaced with the bridge hardware offloading feature, which allows your to switch ports and use some of the bridge features, for example, Spanning Tree Protocol. More details about the outdated master-port property can be found in the Master-port page.

Note: When upgrading from previous versions (before RouterOS v6.41), the old master-port configuration is automatically converted to the new Bridge Hardware Offloading configuration. When downgrading from newer versions (RouterOS v6.41 and newer) to older versions (before RouterOS v6.41) the configuration is not converted back, a bridge without hardware offloading will exist instead, in such a case you need to reconfigure your device to use the old master-port configuration.

Below is a list of devices and feature that supports hardware offloading (+) or disables hardware offloading (-):

Note: When upgrading from older versions (before RouterOS v6.41), only the master-port configuration is converted. For each master-port a bridge will be created. VLAN configuration is not converted and should not be changed, check the Basic VLAN switching guide to be sure how VLAN switching should be configured for your device.

Bridge Hardware Offloading should be considered as port switching, but with more possible features. By enabling hardware offloading you are allowing a built-in switch chip to processes packets using it’s switching logic. The diagram below illustrates that switching occurs before any software related action:

A packet that is received by one of the ports always passes through the switch logic first. Switch logic decides to which ports the packet should be going to (most commonly this decision is made based on the destination MAC address of a packet, but there might be other criteria that might be involved based on the packet and the configuration). In most cases the packet will not be visible to RouterOS (only statistics will show that a packet has passed through), this is because the packet was already processed by the switch chip and never reached the CPU, though it is possible in certain situations to allow a packet to be processed by the CPU. To allow the CPU process a packet you need to forward the packet to the CPU and not allow the switch chip to forward the packet through a switch port directly, this is usually called passing a packet to the switch CPU port (or the bridge CPU port in bridge VLAN filtering scenario).

By passing a packet to the switch CPU port you are prohibiting the switch chip to forward the packet directly, this allows the CPU to process the packet and lets the CPU to forward the packet. Passing the packet to the CPU port will give you the opportunity to route packets to different networks, perform traffic control and other software related packet processing actions. To allow a packet to be processed by the CPU, you need to make certain configuration changes depending on your needs and on the device you are using (most commonly passing packets to the CPU are required for VLAN filtering setups). Check the manual page for your specific device:

Warning: Certain bridge and Ethernet port properties are directly related to switch chip settings, changing such properties can trigger a switch chip reset, that will temporarily disable all Ethernet ports that are on the switch chip for the settings to have an effect, this must be taken into account whenever changing properties on production environments. Such properties are DHCP Snooping, IGMP Snooping, VLAN filtering, L2MTU, Flow Control and others (exact settings that can trigger a switch chip reset depends on the device’s model).

Example

Port switching with bridge configuration and enabled hardware offloading since RouterOS v6.41:

Make sure that hardware offloading is enabled by checking the «H» flag:

Note: Port switching in RouterOS v6.41 and newer is done using the bridge configuration. Prior to RouterOS v6.41 port switching was done using the master-port property, for more details check the Master-port page.

Bridge VLAN Filtering

Note: Currently only CRS3xx series devices are capable of using bridge VLAN filtering and hardware offloading at the same time, other devices will not be able to use the benefits of a built-in switch chip when bridge VLAN filtering is enabled. Other devices should be configured according to the method described in the Basic VLAN switching guide. If an improper configuration method is used, your device can cause throughput issues in your network.

Bridge VLAN Filtering since RouterOS v6.41 provides VLAN aware Layer2 forwarding and VLAN tag modifications within the bridge. This set of features makes bridge operation more like a traditional Ethernet switch and allows to overcome Spanning Tree compatibilty issues compared to configuration when tunnel-like VLAN interfaces are bridged. Bridge VLAN Filtering configuration is highly recommended to comply with STP (IEEE 802.1D), RSTP (IEEE 802.1W) standards and is mandatory to enable MSTP (IEEE 802.1s) support in RouterOS.

Sub-menu: /interface bridge vlan

Warning: The vlan-ids parameter can be used to specify a set or range of VLANs, but specifying multiple VLANs in a single bridge VLAN table entry should only be used for ports that are tagged ports. In case multiple VLANs are specified for access ports, then tagged packets might get sent out as untagged packets through the wrong access port, regardless of the PVID value.

Sub-menu: /interface bridge host

Bridge Host table allows monitoring learned MAC addresses and when vlan-filtering is enabled shows learned VLAN ID as well.

Note: Make sure you have added all needed interfaces to the bridge VLAN table when using bridge VLAN filtering. For routing functions to work properly on the same device through ports that use bridge VLAN filtering, you will need to allow access to the CPU from those ports, this can be done by adding the bridge interface itself to the VLAN table, for tagged traffic you will need to add the bridge interface as a tagged port and create a VLAN interface on the bridge interface. Examples can be found at the Management port section.

Warning: When allowing access to the CPU, you are allowing access from a certain port to the actual router/switch, this is not always desirable. Make sure you implement proper firewall filter rules to secure your device when access to the CPU is allowed from a certain VLAN ID and port, use firewall filter rules to allow access to only certain services.

VLAN Example #1 (Trunk and Access Ports)

Note: Improperly configured bridge VLAN filtering can cause security issues, make sure you fully understand how Bridge VLAN table works before deploying your device into production environments.

VLAN Example #2 (Trunk and Hybrid Ports)

VLAN Example #3 (InterVLAN Routing by Bridge)

Create a bridge with disabled vlan-filtering to avoid losing access to the router before VLANs are completely configured:

Add bridge ports and specify pvid for VLAN access ports to assign their untagged traffic to the intended VLAN:

Add Bridge VLAN entries and specify tagged and untagged ports in them. In this example bridge1 interface is the VLAN trunk that will send traffic further to do InterVLAN routing:

Configure VLAN interfaces on the bridge1 to allow handling of tagged VLAN traffic at routing level and set IP addresses to ensure routing between VLANs as planned:

In the end, when VLAN configuration is complete, enable Bridge VLAN Filtering:

Management access configuration

There are multiple ways to setup management access on a device that uses bridge VLAN filtering. Below are some of the most popular approaches to properly enable access to a router/switch. Start by creating a bridge without VLAN filtering enabled:

The only requirement is to create an IP address on the bridge interface.

In this example VLAN99 will be used to access the device, a VLAN interface on the bridge must be created and an IP address must be assigned to it.

For example, if you want to allow access to the router/switch from access ports ether3, ether4 and from trunk port sfp-sfpplus1, then you must add this entry to the VLAN table:

After that you can enable VLAN filtering:

To allow untagged traffic to access the router/switch, start by creating an IP address on the bridge interface.

It is required to add VLAN 1 to ports from which you want to allow the access to the router/switch, for example, to allow access from access ports ether3, ether4 add this entry to the VLAN table:

Make sure that PVID on the bridge interface matches the PVID value on these ports:

After that you can enable VLAN filtering:

Note: If connection to the router/switch through an IP address is not required, then steps adding this IP address can be skipped since connection to the router/switch through Layer2 protocols (e.g. MAC-telnet) will be working either way.

VLAN Tunneling (Q-in-Q)

Since RouterOS v6.43 the RouterOS bridge is IEEE 802.1ad compliant and it is possible to filter VLAN IDs based on Service VLAN ID (0x88A8) rather than Customer VLAN ID (0x8100). The same principals can be applied as with IEEE 802.1Q VLAN filtering (the same setup examples can be used). Below is a topology for a common Provider bridge:

In this example R1, R2, R3 and R4 might be sending any VLAN tagged traffic by 802.1Q (CVID), but SW1 and SW2 needs isolate traffic between routers in a way that R1 is able to communicate only with R3 and R2 is only able to communicate with R4. To do so, you can tag all ingress traffic with a SVID and only allow these VLANs on certain ports. Start by enabling 802.1ad VLAN protocol on the bridge, use these commands on SW1 and SW2:

In this setup ether1 and ether2 are going to be access ports (untagged), use the pvid parameter to tag all ingress traffic on each port, use these commands on SW1 and SW2:

Specify tagged and untagged ports in the bridge VLAN table, use these commands on SW1 and SW2:

When bridge VLAN table is configured, you can enable bridge VLAN filtering, use these commands on SW1 and SW2

Warning: By enabling vlan-filtering you will be filtering out traffic destined to the CPU, before enabling VLAN filtering you should make sure that you set up a Management port. The difference between using different EtherTypes is that you must use a Service VLAN interface. Service VLAN interfaces can be created as regular VLAN interface, but the use-service-tag parameter toggles if the interface will use Service VLAN tag.

Note: Currently only CRS3xx series switches are capable of hardware offloading VLAN filtering based on SVID (Service VLAN ID) tag when ether-type is set to 0x88a8.

Tag stacking

Since RouterOS v6.43 it is possible to forcefully add a new VLAN tag over any existing VLAN tags, this feature can be used to achieve a CVID stacking setup, where a CVID (0x8100) tag is added before an existing CVID tag. This type of setup is very similar to Provider bridge setup, to achieve the same setup but with multiple CVID tags (CVID stacking) we can use the same topology:

In this example R1, R2, R3 and R4 might be sending any VLAN tagged traffic, it can be 802.1ad, 802.1Q or any other type of traffic, but SW1 and SW2 needs isolate traffic between routers in a way that R1 is able to communicate only with R3 and R2 is only able to communicate with R4. To do so, you can tag all ingress traffic with a new CVID tag and only allow these VLANs on certain ports. Start by selecting the proper EtherType, use these commands on SW1 and SW2:

In this setup ether1 and ether2 will ignore any VLAN tags that are present and add a new VLAN tag, use the pvid parameter to tag all ingress traffic on each port and allow tag-stacking on these ports, use these commands on SW1 and SW2:

Specify tagged and untagged ports in the bridge VLAN table, you only need to specify the VLAN ID of the outer tag, use these commands on SW1 and SW2:

When bridge VLAN table is configured, you can enable bridge VLAN filtering, which is required in order for the PVID parameter have any effect, use these commands on SW1 and SW2

Warning: By enabling vlan-filtering you will be filtering out traffic destined to the CPU, before enabling VLAN filtering you should make sure that you set up a Management port.

Fast Forward

Fast Forward allows to forward packets faster under special conditions. When Fast Forward is enabled, then the bridge can process packets even faster since it can skip multiple bridge related checks, including MAC learning. Below you can find a list of conditions that MUST be met in order for Fast Forward to be active:

Note: Fast Forward disables MAC learning, this is by design to achieve faster packet forwarding. MAC learning prevents traffic from flooding multiple interfaces, but MAC learning is not needed when a packet can only be sent out trough just one interface.

Warning: Fast Forward is disabled when hardware offloading is enabled. Hardware offloading can achieve full write-speed performance when it is active since it will use the built-in switch chip (if such exists on your device), fast forward uses the CPU to forward packets. When comparing throughput results, you would get such results: Hardware offloading > Fast Forward > Fast Path > Slow Path.

It is possible to check how many packets where processed by Fast Forward:

Note: If packets are processed by Fast Path, then Fast Forward is not active. Packet count can be used as an indicator whether Fast Forward is active or not.

Since RouterOS 6.44beta28 it is possible to monitor Fast Forward status, for example:

Warning: Disabling or enabling fast-forward will temporarily disable all bridge ports for settings to take effect. This must be taken into account whenever changing this property on production environments since it can cause all packets to be temporarily dropped.

IGMP Snooping

IGMP Snooping which controls multicast streams and prevents multicast flooding is implemented in RouterOS starting from version 6.41.
It’s settings are placed in bridge menu and it works independently in every bridge interface.
Software driven implementation works on all devices with RouterOS but CRS1xx/2xx/3xx series switches also support IGMP Snooping with hardware offloading.

Sub-menu: /interface bridge /interface bridge mdb

Note: IGMP membership reports are only forwarded to ports that are connected to a multicast router or to another IGMP Snooping enabled bridge. If no port is marked as a multicast-router then IGMP membership reports will not be forwarded to any port.

DHCP Snooping and DHCP Option 82

Sub-menu: /interface bridge /interface bridge port

Starting from RouterOS version 6.43, bridge supports DHCP Snooping and DHCP Option 82. The DHCP Snooping is a Layer2 security feature, that limits unauthorized DHCP servers from providing a malicious information to users. In RouterOS you can specify which bridge ports are trusted (where known DHCP server resides and DHCP messages should be forwarded) and which are untrusted (usually used for access ports, received DHCP server messages will be dropped). The DHCP Option 82 is an additional information (Agent Circuit ID and Agent Remote ID) provided by DHCP Snooping enabled devices that allows identifying the device itself and DHCP clients.

In this example, SW1 and SW2 are DHCP Snooping and Option 82 enabled devices. First, we need to create a bridge, assign interfaces and mark trusted ports. Use these commands on SW1:

For SW2 configuration will be similar, but we also need to mark ether1 as trusted, because this interface is going to receive DHCP messages with Option 82 already added. You need to mark all ports as trusted if they are going to receive DHCP messages with added Option 82, otherwise these messages will be dropped. Also, we add ether3 to the same bridge and leave this port untrusted, imagine there is an unauthorized (rogue) DHCP server. Use these commands on SW2:

Then we need to enable DHCP Snooping and Option 82. In case your DHCP server does not support DHCP Option 82 or you do not implement any Option 82 related policies, this option can be disabled. Use these commands on SW1 and SW2:

Now both devices will analyze what DHCP messages are received on bridge ports. The SW1 is responsible for adding and removing the DHCP Option 82. The SW2 will limit rogue DHCP server form receiving any discovery messages and drop malicious DHCP server messages from ether3.

Note: Currently only CRS3xx devices fully support hardware DHCP Snooping and Option 82. For CRS1xx and CRS2xx series switches it is possible to use DHCP Snooping along with VLAN switching, but then you must make sure that DHCP packets are sent out with the correct VLAN tag using egress ACL rules. Other devices are capable of using DHCP Snooping and Option 82 features along with hardware offloading, but you must make sure that there is no VLAN related configuration applied on the device, otherwise DHCP Snooping and Option 82 might not work properly. See Bridge Hardware Offloading section with supported features.

Bridge Firewall

Sub-menu: /interface bridge filter, /interface bridge nat

The bridge firewall implements packet filtering and thereby provides security functions that are used to manage data flow to, from and through bridge.

Packet flow diagram shows how packets are processed through router. It is possible to force bridge traffic to go through /ip firewall filter rules (see: Bridge Settings)

There are two bridge firewall tables:

General bridge firewall properties are described in this section. Some parameters that differ between nat and filter rules are described in further sections.

Properties

Notes

Bridge Packet Filter

Sub-menu: /interface bridge filter

Properties

Bridge NAT

Sub-menu: /interface bridge nat

Источник