Bridge fast forward mikrotik что это

Mikrotik с нуля. 04 Коммутация

Ранее уже обсуждалось, что RouterBOARD может в себя включать встроенный коммутатор.

В данной схеме устройство в себе объединяет два чипа коммутации: гигабитный и 100мбитный.
Любой порт данного устройства можно либо объединить в логически единый коммутатор, либо порт может работать отдельно, на 3-м уровне.

Нужно понимать что сам по себе чип коммутации способен коммутировать без участия процессора, при этом существуют разные чипы коммутации, которые могут быть включены в состав RouterBOARD.
https://wiki.mikrotik.com/wiki/Manual:Switch_Chip_Features

Выше приведена диаграмма RB2011, в составе которого входят два чипа: Atheros8327 (ether1-ether5+sfp1); Atheros8227 (ether6-ether10)
Возможности данных чипов приведена ниже:

hAP ac lite (RB952Ui-5ac2nD)

hAP ac lite имеет на борту чип Atheros8227 (ether1-ether5)

На уровне switch мы можем управлять элементами:
— switch
— port
— port-isolation
— host
— vlan
— rule

При этом при попытке создать rule, мы получим ошибку, поскольку данный switch не поддерживает rule.

Объединение портов

Здесь стоит упомянуть, что до версии 6.41 в коммутации было понятие master-port.
После версии 6.41 все объединения портов выполняются через bridge.
Поэтому не рекомендуется даунгрейдить на версию ниже 6.41
Далее весь материал будет применяться к версии 6.41 и старше.

Итак, принадлежность портов к тому или иному свитчу или чипу можно определить командами:
interface ethernet print
interface ethernet switch port print

Как видно, в данной модели RouterBOARD все порты «живут» на одном чипе switch1.

Например, hAP ac lite имеет на борту чип Atheros8227 (ether1-ether5). И при включении функции Bridge VLAN Filtering, Hardware Offload будет невозможна, т.к. данный чип не поддерживает эту функцию. Hardware Offload будет автоматически отключена и в обработке коммутации Bridge будет участвовать CPU.

Fast Path

Настройка Bridge

Как видно, мы добавили все три порта в Bridge. Теперь все IP адреса должны «жить» на интерфейсе Bridge.
DHCP также должен быть привязан к интерфейсу Bridge

interface bridge port print

Если добавить в созданный Bridge интерфейсы wifi:

interface bridge port print

Как видно, на интерфейсах wlan отсутствует Hardware Offload. Это из-за того, что интерфейсы wlan «не живут» на чипе switch

Источник

Bridge

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 the 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

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».

Sub-menu: /interface bridge

When the last client on the bridge port unsubscribes to a multicast group and the bridge is acting as an active querier, the bridge will send group-specific IGMP/MLD query, to make sure that no other client is still subscribed. The setting changes the response time for these queries. In case no membership reports are received in a certain time period ( last-member-interval * last-member-query-count ), the multicast group is removed from the multicast database (MDB).

Maximum transmission unit, by default, the bridge will set MTU automatically and it will use the lowest MTU value of any associated bridge port. The default bridge MTU value without any bridge ports added is 1500. The MTU value can be set manually, but it cannot exceed the bridge L2MTU or the lowest bridge port L2MTU. If a new bridge port is added with L2MTU which is smaller than the actual-mtu of the bridge (set by the mtu property), then manually set value will be ignored and the bridge will act as if mtu=auto is set.

When adding VLAN interfaces on the bridge, and when VLAN is using higher MTU than default 1500, it is recommended to set manually the MTU of the bridge.

Multicast querier generates periodic IGMP/MLD general membership queries to which all IGMP/MLD capable devices respond with an IGMP/MLD membership report, usually a PIM (multicast) router or IGMP proxy generates these queries.

By using this property you can make an IGMP/MLD snooping enabled bridge to generate IGMP/MLD general membership queries. This property should be used whenever there is no active querier (PIM router or IGMP proxy) in a Layer2 network. Without a multicast querier in a Layer2 network, the Multicast Database (MDB) is not being updated, the learned entries will timeout and IGMP/MLD snooping will not function properly.

Only untagged IGMP/MLD general membership queries are generated, IGMP queries are sent with IPv4 0.0.0.0 source address, MLD queries are sent with IPv6 link-local address of the bridge interface. The bridge will not send queries if an external IGMP/MLD querier is detected (see the monitoring values igmp-querier and mld-querier ).

Example

To add and enable a bridge interface that will forward L2 packets:

Источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

Правильное использование Fast Path и FastTrack в Mikrotik

С самого основания данного ресурса мы не перестаем придерживаться мнения, что практика всегда должна опираться на необходимый теоретический минимум, давая в своих статьях порой обширные теоретические отступления. Без теории практика превращается в подобие шаманских камланий с бубном, когда вроде сделал все тоже самое, но ничего не работает. В этом плане технология FastTrack в Mikrotik, несмотря на всю свою простоту, держит пальму первенства по количеству возникающих с ней проблем, которые, в большинстве своем, возникают именно от незнания и непонимания работы этой технологии.

Что такое Fast Path

Основной проблемой роутеров Mikrotik, особенно недорогих моделей, является достаточно слабая вычислительная мощность процессора, являющаяся сдерживающим фактором для реализации многих сложных сетевых сценариев. Причина этого кроется в достаточно сложном процессе обработки трафика роутером, в чем можно убедиться подробно изучив диаграммы Packet Flow, показывающие порядок прохождения пакетов через устройство. Если вы собираетесь серьезно работать с устройствами Mikrotik, то данный раздел документации рекомендуется знать хотя бы на твердую четверку, так как именно здесь находятся ответы на многочисленные вопросы типа: «я все сделал по инструкции, но ничего не работает» или «работает, но как-то не так».

В настоящий момент Fast Path можно использовать для:

Однако использование данной технологии имеет ряд ограничений, так для IPv4 FastPath требуется среди прочего:

Для мостов требуется:

Это не полный список, с полным списком ограничений вы можете ознакомиться в официальной документации. Но уже этого достаточно, чтобы понять, с Fast Path не все так просто и за производительность приходится расплачиваться возможностями. Если мы хотим использовать быстрый путь, то нам следует отказаться практически от любого контроля и фильтрации трафика.

При этом может возникнуть ситуация, когда один из интерфейсов поддерживает Fast Path, а другой нет. В этом случае возможны два варианта: если входящий интерфейс поддерживает Fast Path, то часть пути (насколько это возможно) пакеты пройдут через него, а затем перейдут на Slow Path (медленный путь) с полной обработкой трафика на CPU. Если интерфейс входа не поддерживает Fast Path, то трафик проделает весь путь по Slow Path, вне зависимости от того, поддерживает Fast Path интерфейс выхода или нет.

Еще один важный момент: Fast Path можно использовать только для IPv4 TCP или UDP соединений. Однако в правилах нет необходимости указывать протокол, для всего неподдерживаемого трафика Fast Path будет игнорироваться.

Практическое применение Fast Path

Для мостов по умолчанию активируется опция Fast Forward, включающая для передаваемых пакетов быстрый путь, но при этом помним, что DHCP-snooping не должен быть включен, а также отсутствовать любая фильтрация трафика или VLAN внутри моста.

А вот дальше уже становится интереснее. Туннельные соединения и L2TP поддерживают Fast Path, но это лишает нас возможности использовать IPsec, поэтому от Fast Path для данных видов соединений придется отказаться. Тем более что система не даст нам создать интерфейс, сочетающий Fast Path и IPsec.

Правда для L2TP-соединений вы можете одновременно установить обе опции, но при включённом IPsec Fast Path будет игнорироваться. Тем не менее мы категорически не рекомендуем использовать такие неоднозначные варианты настройки, потому как при обновлении RouterOS поведение системы может измениться, что способно привести к неожиданным и непредсказуемым результатам.

Практическое использование Fasttrack

Fasttrack можно без преувеличения назвать самой неправильно настраиваемой опцией. Если выполнить поиск в сети интернет, то можно увидеть множество материалов про то, как решить те или иные проблемы с Fasttrack. Но большинство этих проблем также связаны с непониманием работы данной технологии. Давайте разберемся, что же такое Fasttrack, это сочетание Fast Path + Connection Tracking, проще говоря мы можем отправить все уже установленные и связанные с ними соединения по быстрому пути.

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

Еще один важный момент, вы обязательно должны указать Connection State для этого правила, если вы этого не сделаете, то получите огромную дыру в безопасности, так как мимо брандмауэра по короткому пути пойдут все пакеты. Мы бы не стали заострять на этом внимание, но в нашей практике были случаи, когда администраторы включали Fasttrack для всего транзитного трафика.

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

Что изменилось? Теперь по быстрому пути идут пакеты только из локальной сети в интернет и обратно. Все остальные соединения полноценно обрабатываются ядром RouterOS и могут полностью использовать все ее возможности.

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

Также обратите внимание, что Fasttrack применяется именно для транзитных соединений, не влияя на входящие и исходящие соединения самого роутера. Мы бы не заостряли на этом внимание, но в сети нам попадались инструкции, когда пакеты маркировались в цепочках INPUT и OUTPUT, а затем эти метки соединений пытались использовать в цепочке FORWARD, надо ли говорить, что подобные конструкции работать не будут.

А теперь выключаем Fasttrack и видим, что роутер полностью лег, но при этом даже не смог прокачать тариф, упершись в планку 80 Мбит/с:

Дополнительные материалы:

Mikrotik

The Dude

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Источник

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

Источник