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 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. However, depending on the way the LANs are interconnected, latency and data rate between hosts may vary.

Network loops may emerge (intentionally or not) in complex topologies. Without any special treatment, loops would prevent the network from functioning normally, as they would lead to avalanche-like packet multiplication. Each bridge runs an algorithm that calculates how the loop can be prevented. (R/M)STP allows bridges to communicate with each other, so they can negotiate a loop-free topology. All other alternative connections that would otherwise form loops are put on standby, so that should the main connection fail, another connection could take its place. This algorithm exchanges configuration messages (BPDU - Bridge Protocol Data Unit) periodically, so that all bridges are updated with the newest information about changes in a network topology. (R/M)STP selects a root bridge which is responsible for network reconfiguration, such as blocking and opening ports on other bridges. The root bridge is the bridge with the lowest bridge ID.

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 the "port-number", and it can change after a reboot. To avoid unwanted MAC address changes, it is recommended to disable "auto-mac" and manually specifying the MAC address by using "admin-mac".

Sub-menu: /interface bridge

Example  

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

[admin@MikroTik] > interface bridge add
[admin@MikroTik] > interface bridge print 
Flags: X - disabled, R - running 
0 R name="bridge1" mtu=auto actual-mtu=1500 l2mtu=65535 arp=enabled arp-timeout=auto mac-address=5E:D2:42:95:56:7F protocol-mode=rstp fast-forward=yes 
igmp-snooping=no auto-mac=yes ageing-time=5m priority=0x8000 max-message-age=20s forward-delay=15s transmit-hold-count=6 vlan-filtering=no 
dhcp-snooping=no 

Bridge Monitoring

To monitor the current status of a bridge interface, use the monitor command.

Sub-menu: /interface bridge monitor

[admin@MikroTik] /interface bridge monitor bridge1 
                  state: enabled
    current-mac-address: CC:2D:E0:E4:B3:38
            root-bridge: yes
         root-bridge-id: 0x8000.CC:2D:E0:E4:B3:38
         root-path-cost: 0
              root-port: none
             port-count: 2
  designated-port-count: 2
           fast-forward: no

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 many benefits, but for larger networks properly configured STP is very crucial, leaving STP-related values to default may result in a completely unreachable network in case of an 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.

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 backward 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 an STP enabled network, more detailed case studies can be found in the Spanning Tree Protocol article. In RouterOS, the protocol-mode property controls the used STP variant.

Per-port STP

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

Create edge ports

Setting a bridge port as an edge port will restrict it from sending BPDUs and will ignore any received BPDUs:

/interface bridge
add name=bridge1
/interface bridge port
add bridge=bridge1 interface=ether1 edge=yes
add bridge=bridge1 interface=ether2

Drop received BPDUs

The bridge filter or NAT rules cannot drop BPDUs when the bridge has STP/RSTP/MSTP enabled due to the special processing of BPDUs. However, dropping received BPDUs on a certain port can be done on some switch chips using ACL rules:

On CRS3xx:

/interface ethernet switch rule
add dst-mac-address=01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF new-dst-ports="" ports=ether1 switch=switch1

On CRS1xx/CRS2xx with Access Control List (ACL) support:

/interface ethernet switch acl
add action=drop mac-dst-address=01:80:C2:00:00:00 src-ports=ether1

In this example all received BPDUs on ether1 are dropped.

Enable BPDU guard

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

/interface bridge
add name=bridge1
/interface bridge port
add bridge=bridge1 interface=ether1 bpdu-guard=yes
add bridge=bridge1 interface=ether2

Enable Root guard

In this example, ether1 is configured with restricted-role=yes. It prevented the port from becoming the root port for the CIST or any MSTI, regardless of its best spanning tree priority vector. Such a port will be selected as an Alternate Port (discarding state) and remains so as long as it continues to receive superior BPDUs. It will automatically transition to the forwarding state when it no longer detects a superior root path. Network administrators may enable this setting to safeguard against external bridges influencing the active spanning tree.

/interface bridge
add name=bridge1
/interface bridge port
add bridge=bridge1 interface=ether1 restricted-role=yes
add bridge=bridge1 interface=ether2

[admin@MikroTik] /interface/bridge/port monitor [find]
                 interface: ether1                   ether2
                    status: in-bridge                in-bridge
               port-number: 1                        2
                      role: alternate-port           designated-port
                 edge-port: no                       yes
       edge-port-discovery: yes                      yes
       point-to-point-port: yes                      yes
              external-fdb: no                       no
              sending-rstp: yes                      yes
                  learning: no                       yes
                forwarding: no                       yes
          actual-path-cost: 20000                    20000
            root-path-cost: 20000                    
         designated-bridge: 0x7000.64:D1:54:C7:3A:6E 
           designated-cost: 0                        
    designated-port-number: 1                        
          hw-offload-group: switch1                  switch1

Bridge Settings

Under the bridge settings menu, it is possible to control certain features for all bridge interfaces and monitor global bridge counters.

Sub-menu: /interface bridge settings

Port Settings

Port submenu is used to add interfaces in a particular bridge.

Sub-menu: /interface bridge port

/interface bridge port set [find interface=sfp28-1] !internal-path-cost

/interface bridge port set [find interface=sfp28-1] !path-cost

Example

To group ether1 and ether2 in the already created bridge1 interface.

[admin@MikroTik] /interface bridge port add bridge=bridge1 interface=ether1
[admin@MikroTik] /interface bridge port add bridge=bridge1 interface=ether2
[admin@MikroTik] /interface bridge port print
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload 
 #     INTERFACE       BRIDGE       HW  PVID PRIORITY  PATH-COST INTERNAL-PATH-COST    HORIZON
 0     ether1          bridge1      yes  100     0x80         10                 10       none
 1     ether2          bridge1      yes  200     0x80         10                 10       none

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. Below is an example how to add an interface list to a bridge:

/interface list
add name=LAN1
add name=LAN2
/interface list member
add interface=ether1 list=LAN1
add interface=ether2 list=LAN1
add interface=ether3 list=LAN2
add interface=ether4 list=LAN2
/interface bridge port
add bridge=bridge1 interface=LAN1
add bridge=bridge1 interface=LAN2

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

[admin@MikroTik] /interface bridge port> pr
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload 
 #     INTERFACE       BRIDGE       HW  PVID PRIORITY  PATH-COST INTERNAL-PATH-COST    HORIZON
 0     LAN1            bridge1      yes    1     0x80         10                 10       none
 1  D  ether1          bridge1      yes    1     0x80         10                 10       none
 2  D  ether2          bridge1      yes    1     0x80         10                 10       none
 3     LAN2            bridge1      yes    1     0x80         10                 10       none
 4  D  ether3          bridge1      yes    1     0x80         10                 10       none
 5  D  ether4          bridge1      yes    1     0x80         10                 10       none

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

[admin@MikroTik] > /interface bridge port move 3 0
[admin@MikroTik] > /interface bridge port print
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload 
 #     INTERFACE       BRIDGE       HW  PVID PRIORITY  PATH-COST INTERNAL-PATH-COST    HORIZON
 0     LAN2            bridge1      yes    1     0x80         10                 10       none
 1  D  ether3          bridge1      yes    1     0x80         10                 10       none
 2  D  ether4          bridge1      yes    1     0x80         10                 10       none
 3     LAN1            bridge1      yes    1     0x80         10                 10       none
 4  D  ether1          bridge1      yes    1     0x80         10                 10       none
 5  D  ether2          bridge1      yes    1     0x80         10                 10       none

Bridge Port Monitoring

To monitor the current status of bridge ports, use the monitor command.

Sub-menu: /interface bridge port monitor

[admin@MikroTik] /interface bridge port monitor [find interface=sfp-sfpplus2]
               interface: sfp-sfpplus2
                  status: in-bridge
             port-number: 1
                    role: root-port
               edge-port: no
     edge-port-discovery: yes
     point-to-point-port: yes
            external-fdb: no
            sending-rstp: yes
                learning: yes
              forwarding: yes
               path-cost: 2000
          root-path-cost: 4000
       designated-bridge: 0x8000.DC:2C:6E:9E:11:1C
         designated-cost: 2000
  designated-port-number: 2

Hosts Table

MAC addresses that have been learned on a bridge interface can be viewed in the 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:

[admin@MikroTik] /interface bridge host print
Flags: X - disabled, I - invalid, D - dynamic, L - local, E - external 
 #       MAC-ADDRESS        VID ON-INTERFACE            BRIDGE
 0   D   B8:69:F4:C9:EE:D7      ether1                  bridge1
 1   D   B8:69:F4:C9:EE:D8      ether2                  bridge1
 2   DL  CC:2D:E0:E4:B3:38      bridge1                 bridge1
 3   DL  CC:2D:E0:E4:B3:39      ether2                  bridge1

Static entries

It is possible to add a static MAC address entry into the host table. This can be used to forward a certain type of traffic through a specific port. Another use case for static host entries is to protect the device resources by disabling dynamic learning and relying 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 host 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:

/interface bridge host
add bridge=bridge interface=ether2 mac-address=4C:5E:0C:4D:12:43

Multicast Table

When IGMP/MLD snooping is enabled, the bridge will start to listen to IGMP/MLD communication, create multicast database (MDB) entries, and make forwarding decisions based on the received information. Packets with link-local multicast destination addresses 224.0.0.0/24 and ff02::1 are not restricted and are always flooded on all ports and VLANs. To see learned multicast database entries, use the print command.

Sub-menu: /interface bridge mdb

[admin@MikroTik] /interface bridge mdb print 
Flags: D - DYNAMIC
Columns: GROUP, VID, ON-PORTS, BRIDGE
 #   GROUP              VID  ON-PORTS  BRIDGE 
 0 D ff02::2              1  bridge1   bridge1
 1 D ff02::6a             1  bridge1   bridge1
 2 D ff02::1:ff00:0       1  bridge1   bridge1
 3 D ff02::1:ff01:6a43    1  bridge1   bridge1
 4 D 229.1.1.1           10  ether2    bridge1
 5 D 229.2.2.2           10  ether3    bridge1
                             ether2           
 6 D ff02::2             10  ether5    bridge1
                             ether3           
                             ether2           
                             ether4           

Static entries

Since RouterOS version 7.7, it is possible to create static MDB entries for IPv4 and IPv6 multicast groups.

Sub-menu: /interface bridge mdb

For example, to create a static MDB entry for multicast group 229.10.10.10 on ports ether2 and ether3 on VLAN 10, use the command below:

/interface bridge mdb
add bridge=bridge1 group=229.10.10.10 ports=ether2,ether3 vid=10

Verify the results with the print command:

[admin@MikroTik] > /interface bridge mdb print where group=229.10.10.10
Columns: GROUP, VID, ON-PORTS, BRIDGE
 # GROUP         VID  ON-PORTS  BRIDGE 
12 229.10.10.10   10  ether2    bridge1
                      ether3   

In case a certain IPv6 multicast group does not need to be snooped and it is desired to be flooded on all ports and VLANs, it is possible to create a static MDB entry on all VLANs and ports, including the bridge interface itself. Use the command below to create a static MDB entry for multicast group ff02::2 on all VLANs and ports (modify the ports setting for your particular setup):

/interface bridge mdb
add bridge=bridge1 group=ff02::2 ports=bridge1,ether2,ether3,ether4,ether5

[admin@MikroTik] > /interface bridge mdb print where group=ff02::2
Flags: D - DYNAMIC
Columns: GROUP, VID, ON-PORTS, BRIDGE
 #   GROUP    VID  ON-PORTS  BRIDGE 
 0   ff02::2                 bridge1
15 D ff02::2    1  bridge1   bridge1
16 D ff02::2   10  bridge1   bridge1
                   ether2           
                   ether3           
                   ether4           
                   ether5           
17 D ff02::2   20  bridge1   bridge1
                   ether2           
                   ether3           
18 D ff02::2   30  bridge1   bridge1
                   ether2           
                   ether3     

Bridge Hardware Offloading

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.

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

Footnotes:

1. The feature will not work properly in VLAN switching setups. It is possible to correctly snoop DHCP packets only for a single VLAN, but this requires that these DHCP messages get tagged with the correct VLAN tag using an ACL rule, for example, /interface ethernet switch acl add dst-l3-port=67-68 ip-protocol=udp mac-protocol=ip new-customer-vid=10 src-ports=switch1-cpu. DHCP Option 82 will not contain any information regarding VLAN-ID.
2. The feature will not work properly in VLAN switching setups.
3. The HW vlan-filtering and R/M/STP was added in the RouterOS 7.1rc1 (for RTL8367) and 7.1rc5 (for MT7621) versions. The switch does not support other ether-type 0x88a8 or 0x9100 (only 0x8100 is supported) and no tag-stacking. Using these features will disable HW offload.
4. The HW offloading will be disabled only for the specific bridge port, not the entire bridge.
5. Only 802.3ad and balance-xor modes can be HW offloaded. Other bonding modes do not support HW offloading.
6. Currently, HW offloaded bridge support for the IPQ-PPE switch chip is still a work in progress. We recommend using, the default, non-HW offloaded bridge (enabled RSTP).
7. The 802.3ad mode is compatible only with R/M/STP enabled bridge.

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 process packets using its 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 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, this is usually called a packet forwarding to the switch CPU port (or the bridge interface in bridge VLAN filtering scenario). 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:

• CRS1xx/2xx series switches
• CRS3xx, CRS5xx series switches and CCR2116, CCR2216 routers
• non-CRS series switches

Example

Port switching with bridge configuration and enabled hardware offloading:

/interface bridge
add name=bridge1
/interface bridge port
add bridge=bridge1 interface=ether2 hw=yes
add bridge=bridge1 interface=ether3 hw=yes
add bridge=bridge1 interface=ether4 hw=yes
add bridge=bridge1 interface=ether5 hw=yes

Make sure that hardware offloading is enabled and active by checking the "H" flag:

[admin@MikroTik] /interface bridge port print
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload 
 #     INTERFACE       BRIDGE       HW  PVID PRIORITY  PATH-COST INTERNAL-PATH-COST    HORIZON
 0   H ether2          bridge1      yes    1     0x80         10                 10       none
 1   H ether3          bridge1      yes    1     0x80         10                 10       none
 2   H ether4          bridge1      yes    1     0x80         10                 10       none
 3   H ether5          bridge1      yes    1     0x80         10                 10       none

Bridge VLAN Filtering

Bridge VLAN Filtering provides VLAN-aware Layer 2 forwarding and VLAN tag modifications within the bridge. This set of features makes bridge operation more similar to a traditional Ethernet switch and allows overcoming Spanning Tree compatibility issues compared to the configuration when 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.

The main VLAN setting is vlan-filtering which globally controls VLAN-awareness and VLAN tag processing in the bridge. If vlan-filtering=no is configured, the bridge ignores VLAN tags, works in a shared-VLAN-learning (SVL) mode, and cannot modify VLAN tags of packets. Turning on vlan-filtering enables all bridge VLAN related functionality and independent-VLAN-learning (IVL) mode. Besides joining the ports for Layer2 forwarding, the bridge itself is also an interface therefore it has Port VLAN ID (pvid).

Bridge VLAN table

Bridge VLAN table represents per-VLAN port mapping with an egress VLAN tag action. The tagged ports send out frames with a corresponding VLAN ID tag. The untagged ports remove a VLAN tag before sending out frames. Bridge ports with frame-types set to admit-all or admit-only-untagged-and-priority-tagged will be automatically added as untagged ports for the pvid VLAN.

Sub-menu: /interface bridge vlan

Bridge port settings

Each bridge port have multiple VLAN related settings, that can change untagged VLAN membership, VLAN tagging/untagging behavior and packet filtering based on VLAN tag presence.

Sub-menu: /interface bridge port

Bridge host table

Bridge host table allows monitoring learned MAC addresses. When vlan-filtering is enabled, it shows learned VLAN ID as well (enabled independent-VLAN-learning or IVL).

[admin@MikroTik] > /interface bridge host print where !local 
Flags: X - disabled, I - invalid, D - dynamic, L - local, E - external 
 #       MAC-ADDRESS        VID ON-INTERFACE       BRIDGE
 0   D   CC:2D:E0:E4:B3:AA  300 ether3             bridge1
 1   D   CC:2D:E0:E4:B3:AB  400 ether4             bridge1

VLAN Example - Trunk and Access Ports

Create a bridge with disabled vlan-filtering to avoid losing access to the device before VLANs are completely configured. If you need a management access to the bridge, see the Management access configuration section.

/interface bridge
add name=bridge1 vlan-filtering=no

Add bridge ports and specify pvid for access ports to assign their untagged traffic to the intended VLAN. Use frame-types setting to accept only tagged or untagged packets.

/interface bridge port
add bridge=bridge1 interface=ether2 frame-types=admit-only-vlan-tagged
add bridge=bridge1 interface=ether6 pvid=200 frame-types=admit-only-untagged-and-priority-tagged
add bridge=bridge1 interface=ether7 pvid=300 frame-types=admit-only-untagged-and-priority-tagged
add bridge=bridge1 interface=ether8 pvid=400 frame-types=admit-only-untagged-and-priority-tagged

Add Bridge VLAN entries and specify tagged ports in them. Bridge ports with frame-types set to admit-only-untagged-and-priority-tagged will be automatically added as untagged ports for the pvid VLAN.

/interface bridge vlan
add bridge=bridge1 tagged=ether2 vlan-ids=200 
add bridge=bridge1 tagged=ether2 vlan-ids=300
add bridge=bridge1 tagged=ether2 vlan-ids=400

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

/interface bridge set bridge1 vlan-filtering=yes 

Optional step is to set frame-types=admit-only-vlan-tagged on the bridge interface in order to disable the default untagged VLAN 1 (pvid=1).

/interface bridge set bridge1 frame-types=admit-only-vlan-tagged

VLAN Example - Trunk and Hybrid Ports

Create a bridge with disabled vlan-filtering to avoid losing access to the router before VLANs are completely configured. If you need a management access to the bridge, see the Management access configuration section.

/interface bridge
add name=bridge1 vlan-filtering=no

Add bridge ports and specify pvid on hybrid VLAN ports to assign untagged traffic to the intended VLAN.  Use frame-types setting to accept only tagged packets on ether2.

/interface bridge port
add bridge=bridge1 interface=ether2 frame-types=admit-only-vlan-tagged
add bridge=bridge1 interface=ether6 pvid=200
add bridge=bridge1 interface=ether7 pvid=300
add bridge=bridge1 interface=ether8 pvid=400

Add Bridge VLAN entries and specify tagged ports in them. In this example egress VLAN tagging is done on ether6,ether7,ether8 ports too, making them into hybrid ports. Bridge ports with frame-types set to admit-all will be automatically added as untagged ports for the pvid VLAN.

/interface bridge vlan 
add bridge=bridge1 tagged=ether2,ether7,ether8 vlan-ids=200
add bridge=bridge1 tagged=ether2,ether6,ether8 vlan-ids=300
add bridge=bridge1 tagged=ether2,ether6,ether7 vlan-ids=400

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

/interface bridge set bridge1 vlan-filtering=yes 

Optional step is to set frame-types=admit-only-vlan-tagged on the bridge interface in order to disable the default untagged VLAN 1 (pvid=1).

/interface bridge set bridge1 frame-types=admit-only-vlan-tagged

VLAN Example - InterVLAN Routing by Bridge

Create a bridge with disabled vlan-filtering to avoid losing access to the router before VLANs are completely configured.  If you need a management access to the bridge, see the Management access configuration section.

/interface bridge
add name=bridge1 vlan-filtering=no

Add bridge ports and specify pvid for VLAN access ports to assign their untagged traffic to the intended VLAN. Use frame-types setting to accept only untagged packets.

/interface bridge port
add bridge=bridge1 interface=ether6 pvid=200 frame-types=admit-only-untagged-and-priority-tagged
add bridge=bridge1 interface=ether7 pvid=300 frame-types=admit-only-untagged-and-priority-tagged
add bridge=bridge1 interface=ether8 pvid=400 frame-types=admit-only-untagged-and-priority-tagged

Add Bridge VLAN entries and specify tagged ports in them. In this example bridge1 interface is the VLAN trunk that will send traffic further to do InterVLAN routing. Bridge ports with frame-types set to admit-only-untagged-and-priority-tagged will be automatically added as untagged ports for the pvid VLAN.

/interface bridge vlan
add bridge=bridge1 tagged=bridge1 vlan-ids=200
add bridge=bridge1 tagged=bridge1 vlan-ids=300
add bridge=bridge1 tagged=bridge1 vlan-ids=400

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.

/interface vlan
add interface=bridge1 name=VLAN200 vlan-id=200
add interface=bridge1 name=VLAN300 vlan-id=300
add interface=bridge1 name=VLAN400 vlan-id=400

/ip address
add address=20.0.0.1/24 interface=VLAN200
add address=30.0.0.1/24 interface=VLAN300
add address=40.0.0.1/24 interface=VLAN400

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

/interface bridge set bridge1 vlan-filtering=yes 

Optional step is to set frame-types=admit-only-vlan-tagged on the bridge interface in order to disable the default untagged VLAN 1 (pvid=1).

/interface bridge set bridge1 frame-types=admit-only-vlan-tagged

Since RouterOS v7, it is possible to route traffic using the L3 HW offloading on certain devices. See more details on L3 Hardware Offloading.

Management access configuration

There are multiple ways to set up 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:

/interface bridge
add name=bridge1 vlan-filtering=no

Untagged access without VLAN filtering

In case VLAN filtering will not be used and access with untagged traffic is desired, the only requirement is to create an IP address on the bridge interface.

/ip address
add address=192.168.99.1/24 interface=bridge1

Tagged access without VLAN filtering

In case VLAN filtering will not be used and access with tagged traffic is desired, create a routable VLAN interface on the bridge and add an IP address on the VLAN interface.

/interface vlan
add interface=bridge1 name=MGMT vlan-id=99
/ip address
add address=192.168.99.1/24 interface=MGMT

Tagged access with VLAN filtering

In case VLAN filtering is used and access with tagged traffic is desired, additional steps are required. In this example, VLAN 99 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.

/interface vlan
add interface=bridge1 name=MGMT vlan-id=99
/ip address
add address=192.168.99.1/24 interface=MGMT

For example, if you want to allow access to the device from ports ether3, ether4, sfp-sfpplus1 using tagged VLAN 99 traffic, then you must add this entry to the VLAN table. Note that the bridge1 interface is also included in the tagged port list:

/interface bridge vlan
add bridge=bridge1 tagged=bridge1,ether3,ether4,sfp-sfpplus1 vlan-ids=99

After that you can enable VLAN filtering:

/interface bridge set bridge1 vlan-filtering=yes

Untagged access with VLAN filtering

In case VLAN filtering is used and access with untagged traffic is desired, the VLAN interface must use the same VLAN ID as the untagged port VLAN ID (pvid). Just like in the previous example, start by creating a VLAN interface on the bridge and add an IP address for the VLAN.

/interface vlan
add interface=bridge1 name=MGMT vlan-id=99
/ip address
add address=192.168.99.1/24 interface=MGMT

For example, untagged ports ether2 and ether3 should be able to communicate with the VLAN 99 interface using untagged traffic. In order to achieve this, these ports should be configured with the pvid that matches the VLAN ID on management VLAN. Note that the bridge1 interface is a tagged port member, you can configure additional tagged ports if necessary (see the previous example).

/interface bridge port
set [find interface=ether2] pvid=99
set [find interface=ether3] pvid=99
/interface bridge vlan 
add bridge=bridge1 tagged=bridge1 untagged=ether2,ether3 vlan-ids=99

After that you can enable VLAN filtering:

/interface bridge set bridge1 vlan-filtering=yes 

Changing untagged VLAN for the bridge interface

In case VLAN filtering is used, it is possible to change the untagged VLAN ID for the bridge interface using the pvid setting. Note that creating routable VLAN interfaces and allowing tagged traffic on the bridge is a more flexible and generally recommended option.

First, create an IP address on the bridge interface.

/ip address
add address=192.168.99.1/24 interface=bridge1

For example, untagged bridge1 traffic should be able to communicate with untagged ether2 and ether3 ports and tagged sfp-sfpplus1 port in VLAN 99. In order to achieve this, bridge1, ether2, ether3 should be configured with the same pvid and sfp-sfpplus1 added as a tagged member.

/interface bridge
set [find name=bridge1] pvid=99
/interface bridge port
set [find interface=ether2] pvid=99
set [find interface=ether3] pvid=99
/interface bridge vlan
add bridge=bridge1 tagged=sfp-sfpplus1 untagged=bridge1,ether2,ether3 vlan-ids=99

After that you can enable VLAN filtering:

/interface bridge set bridge1 vlan-filtering=yes 

VLAN Tunneling (QinQ)

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 principles 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 an SVID and only allow these VLANs on certain ports. Start by enabling the service tag 0x88a8, introduced by 802.1ad, on the bridge. Use these commands on SW1 and SW2:

/interface bridge
add name=bridge1 vlan-filtering=no ether-type=0x88a8

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:

/interface bridge port
add interface=ether1 bridge=bridge1 pvid=200
add interface=ether2 bridge=bridge1 pvid=300
add interface=ether3 bridge=bridge1

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

/interface bridge vlan
add bridge=bridge1 tagged=ether3 untagged=ether1 vlan-ids=200
add bridge=bridge1 tagged=ether3 untagged=ether2 vlan-ids=300

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

/interface bridge set bridge1 vlan-filtering=yes 

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

/interface bridge
add name=bridge1 vlan-filtering=no ether-type=0x8100

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:

/interface bridge port
add interface=ether1 bridge=bridge1 pvid=200 tag-stacking=yes
add interface=ether2 bridge=bridge1 pvid=300 tag-stacking=yes
add interface=ether3 bridge=bridge1

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:

/interface bridge vlan
add bridge=bridge1 tagged=ether3 untagged=ether1 vlan-ids=200
add bridge=bridge1 tagged=ether3 untagged=ether2 vlan-ids=300

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

/interface bridge set bridge1 vlan-filtering=yes

MVRP

Multiple VLAN Registration protocol (MVRP) is a protocol based on Multiple Registration Protocol (MRP) which allows to register attributes (VLAN IDs in case of MVRP) with other members of Bridged LAN.

An MRP application can make or withdraw declarations of attributes which result in registration or leaving of those attributes with other MRP participants.

Here's how it works.

MRP consists of two parts:

• Applicant - responsible for sending declarations (or leaves). Its behavior can be configured on a per-port basis using the setting called mvrp-applicant-state, and per-VLAN using the mvrp-forbidden setting.

• Registrar - responsible for registering incoming declarations. Its configuration can be set per-port using the mvrp-registrar-state setting, and per-VLAN using the mvrp-forbidden setting.

Registration Propagation: Incoming registration on a bridge port dynamically makes that specific port a tagged VLAN member. Additionally, the attributes associated with this registration are spread to all active (forwarding) bridge ports as a declaration.

Declaration Operation: In case of MVRP, the configured VLAN's get declared on each port, but they will only get configured as members of those VLAN's when a declaration is received from the LAN (Registrar will register the VLAN). From the perspective of an end-station, a single declaration will be registered on each upstream port across the entire LAN. When another end-station declares the same attribute, a path of registrations will be made between the two (or more) end stations, see the picture below. 

MVRP helps to dynamically propagate VLAN information throughout the bridged network and configure VLANs only on the needed ports. This makes the network efficient by avoiding unnecessary traffic flooding.

As noted before, MVRP is only active on ports that are forwarding. In case of MSTP declarations and registrations are made only if the port is forwarding in the MSTI in which VLAN is mapped.

The point-to-point ports speed up the process of registration (or leaving). Manually configuring point-to-point=yes can be advantageous for non-Ethernet interfaces.

Property Reference

Sub-menu: /interface bridge

Sub-menu: /interface bridge port

The port menu enables control over the applicant and registrar settings on a per-port basis.

 To monitor the currently declared and registered VLAN IDs, use the monitor command.

[admin@MikroTik] > interface/bridge/port monitor [find interface=sfp-sfpplus1]
            interface: sfp-sfpplus1
               status: in-bridge
          port-number: 1
                 role: designated-port
            edge-port: no
  edge-port-discovery: yes
  point-to-point-port: yes
         external-fdb: no
         sending-rstp: yes
             learning: yes
           forwarding: yes
     actual-path-cost: 2000
     hw-offload-group: switch1
    declared-vlan-ids: 1,10,20-21
  registered-vlan-ids: 1,10,20,30-33

Sub-menu: /interface bridge vlan

All ports that are members of static VLANs or dynamic untagged VLANs created by the port pvid setting are treated as "fixed." Meaning the registrar disregards all MRP messages and remains registered (IN) for those VLANs.

When VLAN is neither manually configured nor created by the port pvid setting, incoming registrations on a bridge port can dynamically designate that specific port as a tagged VLAN member. The mvrp-forbidden feature allows creating a list of ports that are restricted from registering into a specific VLAN ID.

VLANs that are static or dynamic will be declared by the applicants unless this functionality is disabled by the port's mvrp-applicant-state, or by VLAN's mvrp-forbidden setting.

Sub-menu: /interface bridge vlan mvrp

The MVRP attributes menu can be used to see internal MVRP attribute states, as specified in the IEEE 802.1Q-2011.

[admin@Mikrotik] /interface/bridge/vlan/mvrp print where vlan-id=10
Columns: BRIDGE, PORT, VLAN-ID, REGISTRAR-STATE, APPLICANT-STATE, LAST-EVENT
 #  BRIDGE    PORT           VLAN-ID  REGISTRAR-STATE  APPLICANT-STATE  LAST-EVENT
 1  bridge67  sfp-sfpplus1        10  IN               Quiet Active     JoinIn    
 9  bridge67  sfp-sfpplus5        10  MT               Quiet Active     JoinEmpty 
17  bridge67  sfp-sfpplus9        10  MT               Quiet Active     JoinEmpty 
25  bridge67  sfp-sfpplus13       10  IN               Quiet Active     JoinIn 

Fast Forward

Fast Forward allows forwarding 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:

• Bridge has fast-forward set to yes
• Bridge has only 2 running ports
• Both bridge ports support Fast Path, Fast Path is active on ports and globally on the bridge
• Bridge Hardware Offloading is disabled
• Bridge VLAN Filtering is disabled
• Bridge DHCP snooping is disabled
• unknown-multicast-flood is set to yes
• unknown-unicast-flood is set to yes
• broadcast-flood is set to yes
• MAC address for the bridge matches with a MAC address from one of the bridge slave ports
• horizon for both ports is set to none

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

[admin@MikroTik] /interface bridge settings> pr
              use-ip-firewall: no
     use-ip-firewall-for-vlan: no
    use-ip-firewall-for-pppoe: no
              allow-fast-path: yes
      bridge-fast-path-active: yes
     bridge-fast-path-packets: 0
       bridge-fast-path-bytes: 0
  bridge-fast-forward-packets: 16423
    bridge-fast-forward-bytes: 24864422

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

[admin@MikroTik] /interface bridge monitor bridge1 
                  state: enabled
    current-mac-address: B8:69:F4:C9:EE:D7
            root-bridge: yes
         root-bridge-id: 0x8000.B8:69:F4:C9:EE:D7
         root-path-cost: 0
              root-port: none
             port-count: 2
  designated-port-count: 2
           fast-forward: yes

IGMP/MLD Snooping

The bridge supports IGMP/MLD snooping. It controls multicast streams and prevents multicast flooding on unnecessary ports. Its settings are placed in the bridge menu and it works independently in every bridge interface. Software-driven implementation works on all devices with RouterOS, but CRS3xx, CRS5xx series switches, CCR2116, CR2216 routers, and 88E6393X, 88E6191X, 88E6190 switch chips also support IGMP/MLD snooping with hardware offloading. See more details on IGMP/MLD snooping manual.

DHCP Snooping and DHCP Option 82

DHCP Snooping and DHCP Option 82 is supported by bridge. The DHCP Snooping is a Layer2 security feature, that limits unauthorized DHCP servers from providing 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 additional information (Agent Circuit ID and Agent Remote ID) provided by DHCP Snooping enabled devices that allow 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:

/interface bridge
add name=bridge
/interface bridge port
add bridge=bridge interface=ether1
add bridge=bridge interface=ether2 trusted=yes

For SW2, the 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:

/interface bridge
add name=bridge
/interface bridge port
add bridge=bridge interface=ether1 trusted=yes
add bridge=bridge interface=ether2 trusted=yes
add bridge=bridge interface=ether3

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:

/interface bridge
set [find where name="bridge"] dhcp-snooping=yes add-dhcp-option82=yes

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 from receiving any discovery messages and drop malicious DHCP server messages from ether3.

Controller Bridge and Port Extender

Controller Bridge (CB) and Port Extender (PE) is an IEEE 802.1BR standard implementation in RouterOS for CRS3xx, CRS5xx series switches and CCR2116, CCR2216 routers. It allows virtually extending the CB ports with a PE device and managing these extended interfaces from a single controlling device. Such configuration provides a simplified network topology, flexibility, increased port density, and ease of manageability. See more details on Controller Bridge and Port Extender manual.

Bridge Firewall

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

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

There are two bridge firewall tables:

• filter - bridge firewall with three predefined chains:
  • input - filters packets, where the destination is the bridge (including those packets that will be routed, as they are destined to the bridge MAC address anyway)
  • output - filters packets, which come from the bridge (including those packets that has been routed normally)
  • forward - filters packets, which are to be bridged (note: this chain is not applied to the packets that should be routed through the router, just to those that are traversing between the ports of the same bridge)
• nat - bridge network address translation provides ways for changing source/destination MAC addresses of the packets traversing a bridge. Has two built-in chains:
  • srcnat - used for "hiding" a host or a network behind a different MAC address. This chain is applied to the packets leaving the router through a bridged interface
  • dstnat - used for redirecting some packets to other destinations

You can put packet marks in bridge firewall (filter and NAT), which are the same as the packet marks in IP firewall configured by '/ip firewall mangle'. In this way, packet marks put by bridge firewall can be used in 'IP firewall', and vice versa.

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

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

Footnotes:

• STP matchers are only valid if the destination MAC address is 01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF (Bridge Group address), also STP should be enabled.

• ARP matchers are only valid if mac-protocol is arp or rarp

• VLAN matchers are only valid for 0x8100 or 0x88a8 ethernet protocols

• IP or IPv6 related matchers are only valid if mac-protocol is either set to ip or ipv6

• 802.3 matchers are only consulted if the actual frame is compliant with IEEE 802.2 and IEEE 802.3 standards. These matchers are ignored for other packets.

Bridge Packet Filter

This section describes specific bridge filter options.

Sub-menu: /interface bridge filter

Bridge NAT

This section describes specific bridge NAT options.

Sub-menu: /interface bridge nat

See also

• CRS1xx/2xx series switches
• CRS3xx, CRS5xx series switches, and CCR2116, CCR2216 routers
• Switch chip features
• MTU on RouterBOARD
• Layer2 misconfiguration
• Bridge VLAN Table
• Wireless VLAN Trunk
• VLANs on Wireless