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).
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 "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".
|add-dhcp-option82 (yes | no; Default: no)||Whether to add DHCP Option-82 information (Agent Remote ID and Agent Circuit ID) to DHCP packets. Can be used together with Option-82 capable DHCP server to assign IP addresses and implement policies. This property only has an effect when |
|admin-mac (MAC address; Default: none)||Static MAC address of the bridge. This property only has an effect when |
|ageing-time (time; Default: 00:05:00)||How long a host's information will be kept in the bridge database.|
|arp (disabled | enabled | local-proxy-arp | proxy-arp | reply-only; Default: enabled)||Address Resolution Protocol setting|
|arp-timeout (auto | integer; Default: auto)||How long the ARP record is kept in the ARP table after no packets are received from IP. Value |
|auto-mac (yes | no; Default: yes)||Automatically select one MAC address of bridge ports as a bridge MAC address, bridge MAC will be chosen from the first added bridge port. After a device reboots, the bridge MAC can change depending on the port-number.|
|comment (string; Default: )||Short description of the interface.|
|dhcp-snooping (yes | no; Default: no)||Enables or disables DHCP Snooping on the bridge.|
|disabled (yes | no; Default: no)||Changes whether the bridge is disabled.|
|ether-type (0x9100 | 0x8100 | 0x88a8; Default: 0x8100)||Changes the EtherType, which will be used to determine if a packet has a VLAN tag. Packets that have a matching EtherType are considered as tagged packets. This property only has an effect when |
|fast-forward (yes | no; Default: yes)||Special and faster case of Fast Path which works only on bridges with 2 interfaces (enabled by default only for new bridges). More details can be found in the Fast Forward section.|
|forward-delay (time; Default: 00:00:15)||The time which is spent during the initialization phase of the bridge interface (i.e., after router startup or enabling the interface) in the listening/learning state before the bridge will start functioning normally.|
|frame-types (admit-all | admit-only-untagged-and-priority-tagged | admit-only-vlan-tagged; Default: admit-all)||Specifies allowed frame types on a bridge port. This property only has an effect when |
|igmp-snooping (yes | no; Default: no)||Enables multicast group and port learning to prevent multicast traffic from flooding all interfaces in a bridge.|
|igmp-version (2 | 3; Default: 2)||Selects the IGMP version in which IGMP general membership queries will be generated. This property only has an effect when |
|ingress-filtering (yes | no; Default: no)||Enables or disables VLAN ingress filtering, which checks if the ingress port is a member of the received VLAN ID in the bridge VLAN table. By default, VLANs that don't exist in the bridge VLAN table are dropped before they are sent out (egress), but this property allows you to drop the packets when they are received (ingress). Should be used with|
|l2mtu (read-only; Default: )||L2MTU indicates the maximum size of the frame without a MAC header that can be sent by this interface. The L2MTU value will be automatically set by the bridge and it will use the lowest L2MTU value of any associated bridge port. This value cannot be manually changed.|
|last-member-interval (time; Default: 1s)||If a port has |
|last-member-query-count (integer: 0..4294967295; Default: 2)||How many times should |
|max-hops (integer: 6..40; Default: 20)||Bridge count which BPDU can pass in an MSTP enabled network in the same region before BPDU is being ignored. This property only has an effect when |
|max-message-age (time; Default: 00:00:20)||How long to remember Hello messages received from other STP/RSTP enabled bridges. This property only has an effect when |
|membership-interval (time; Default: 4m20s)||The amount of time after an entry in the Multicast Database (MDB) is removed if an IGMP membership report is not received on a certain port. This property only has an effect when |
|mld-version (1 | 2; Default: 1)||Selects the MLD version in which MLD general membership queries will be generated. This property only has an effect when the RouterOS IPv6 package is enabled and igmp-snooping is set to |
|mtu (integer; Default: auto)||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 |
|multicast-querier (yes | no; Default: no)|
Multicast querier generates IGMP general membership queries to which all IGMP capable devices respond with an IGMP membership report, usually a PIM (multicast) router or IGMP proxy generates these queries When RouterOS IPv6 package is enabled, the bridge will also generate MLD general membership queries.
By using this property you can make an IGMP 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 and IGMP Snooping will not function properly. Only untagged IGMP/MLD general membership queries are generated. This property only has an effect when
|multicast-router (disabled | permanent | temporary-query; Default: temporary-query)||Changes the state of a bridge itself if IGMP membership reports are going to be forwarded to it. This property can be used to forward IGMP membership reports to the bridge for further multicast routing or proxying. This property only has an effect when |
|name (text; Default: bridgeN)||Name of the bridge interface.|
|priority (integer: 0..65535 decimal format or 0x0000-0xffff hex format; Default: 32768 / 0x8000)||Bridge priority, used by R/STP to determine root bridge, used by MSTP to determine CIST and IST regional root bridge. This property has no effect when |
|protocol-mode (none | rstp | stp | mstp; Default: rstp)||Select Spanning tree protocol (STP) or Rapid spanning tree protocol (RSTP) to ensure a loop-free topology for any bridged LAN. RSTP provides a faster spanning tree convergence after a topology change. Select MSTP to ensure loop-free topology across multiple VLANs. Since RouterOS v6.43 it is possible to forward Reserved MAC addresses that are in the 01:80:C2:00:00:0X range, this can be done by setting the |
|pvid (integer: 1..4094; Default: 1)||Port VLAN ID (pvid) specifies which VLAN the untagged ingress traffic is assigned to. It applies e.g. to frames sent from bridge IP and destined to a bridge port. This property only has an effect when |
|querier-interval (time; Default: 4m15s)||Used to change the interval of how often a bridge checks if it is the active multicast querier. This property only has an effect when |
|query-interval (time; Default: 2m5s)||Used to change the interval of how often IGMP general membership queries are sent out. This property only has an effect when |
|query-response-interval (time; Default: 10s)||Interval in which an IGMP capable device must reply to an IGMP query with an IGMP membership report. This property only has an effect when |
|region-name (text; Default: )||MSTP region name. This property only has an effect when |
|region-revision (integer: 0..65535; Default: 0)||MSTP configuration revision number. This property only has an effect when |
|startup-query-count (integer: 0..4294967295; Default: 2)||Specifies how many times must |
|startup-query-interval (time; Default: 31s250ms)||Used to change the amount of time after a bridge starts sending out IGMP general membership queries after the bridge is enabled. This property only has an effect when |
|transmit-hold-count (integer: 1..10; Default: 6)||The Transmit Hold Count used by the Port Transmit state machine to limit the transmission rate.|
|vlan-filtering (yes | no; Default: no)||Globally enables or disables VLAN functionality for the bridge.|
Changing certain properties can cause the bridge to temporarily disable all ports. This must be taken into account whenever changing such properties on production environments since it can cause all packets to be temporarily dropped. Such properties include
fast-forward and others.
To add and enable a bridge interface that will forward L2 packets:
To monitor the current status of a bridge interface, use the
/interface bridge monitor
|current-mac-address (MAC address)||Current MAC address of the bridge|
|designated-port-count (integer)||Number of designated bridge ports|
|port-count (integer)||Number of the bridge ports|
|root-bridge (yes | no)||Shows whether the bridge is the root bridge of the spanning tree|
|root-bridge-id (text)||The root bridge ID, which is in form of bridge-priority.bridge-MAC-address|
|root-path-cost (integer)||The total cost of the path to the root-bridge|
|root-port (name)||Port to which the root bridge is connected to|
|state (enabled | disabled)||State of the bridge|
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.
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 do 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 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.
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.
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.
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 behavior.
Create edge ports
Setting a bridge port as an edge port will restrict it from sending BPDUs and will ignore any received BPDUs:
Drop sent BPDUs
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 it might become a second root bridge.
You can use Interface Lists to specify multiple interfaces.
Drop received BPDUs
The bridge filter input or NAT rules cannot drop received 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 CRS1xx/CRS2xx with Access Control List (ACL) support:
In this example all received BPDUs on ether1 are dropped.
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 a designated bridge. If you have blocked BPDUs only on one side, then a port will flap continuously.
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.
Under the bridge settings menu, it is possible to control certain features for all bridge interfaces and monitor global bridge counters.
/interface bridge settings
|use-ip-firewall (yes | no; Default: no)||Force bridged traffic to also be processed by prerouting, forward, and postrouting sections of IP routing (see more details on Packet Flow article). This does not apply to routed traffic. This property is required in case you want to assign Simple Queues or global Queue Tree to traffic in a bridge. Property |
|use-ip-firewall-for-pppoe (yes | no; Default: no)||Send bridged un-encrypted PPPoE traffic to also be processed by IP/Firewall. This property only has an effect when |
|use-ip-firewall-for-vlan (yes | no; Default: no)||Send bridged VLAN traffic to also be processed by IP/Firewall. This property only has an effect when |
|allow-fast-path (yes | no; Default: yes)||Whether to enable a bridge Fast Path globally.|
|bridge-fast-path-active (yes | no; Default: )||Shows whether a bridge FastPath is active globally, Fast Path status per bridge interface is not displayed.|
|bridge-fast-path-packets (integer; Default: )||Shows packet count forwarded by bridge Fast Path.|
|bridge-fast-path-bytes (integer; Default: )||Shows byte count forwarded by bridge Fast Path.|
|bridge-fast-forward-packets (integer; Default: )||Shows packet count forwarded by bridge Fast Forward.|
|bridge-fast-forward-bytes (integer; Default: )||Shows byte count forwarded by bridge Fast Forward.|
In case you want to assign Simple Queues 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 submenu is used to add interfaces in a particular bridge.
/interface bridge port
|auto-isolate (yes | no; Default: no)||When enabled, prevents a port moving from discarding into forwarding state if no BPDUs are received from the neighboring bridge. The port will change into a forwarding state only when a BPDU is received. This property only has an effect when |
|bpdu-guard (yes | no; Default: no)||Enables or disables BPDU Guard feature on a port. This feature puts the port in a disabled role if it receives a BPDU and requires the port to be manually disabled and enabled if a BPDU was received. Should be used to prevent a bridge from BPDU related attacks. This property has no effect when |
|bridge (name; Default: none)||The bridge interface where the respective interface is grouped in.|
|broadcast-flood (yes | no; Default: yes)||When enabled, bridge floods broadcast traffic to all bridge egress ports. When disabled, drops broadcast traffic on egress ports. Can be used to filter all broadcast traffic on an egress port. Broadcast traffic is considered as traffic that uses FF:FF:FF:FF:FF:FF as destination MAC address, such traffic is crucial for many protocols such as DHCP, ARP, NDP, BOOTP (Netinstall), and others. This option does not limit traffic flood to the CPU.|
|edge (auto | no | no-discover | yes | yes-discover; Default: auto)||Set port as edge port or non-edge port, or enable edge discovery. Edge ports are connected to a LAN that has no other bridges attached. An edge port will skip the learning and the listening states in STP and will transition directly to the forwarding state, this reduces the STP initialization time. If the port is configured to discover edge port then as soon as the bridge detects a BPDU coming to an edge port, the port becomes a non-edge port. This property has no effect when |
|fast-leave (yes | no; Default: no)||Enables IGMP Fast leave feature on the port. Bridge will stop forwarding traffic to a bridge port whenever an IGMP Leave message is received for appropriate multicast stream. This property only has an effect when |
|frame-types (admit-all | admit-only-untagged-and-priority-tagged | admit-only-vlan-tagged; Default: admit-all)||Specifies allowed ingress frame types on a bridge port. This property only has an effect when |
|ingress-filtering (yes | no; Default: no)||Enables or disables VLAN ingress filtering, which checks if the ingress port is a member of the received VLAN ID in the bridge VLAN table. Should be used with |
|learn (auto | no | yes; Default: auto)||Changes MAC learning behavior on a bridge port|
|multicast-router (disabled | permanent | temporary-query; Default: temporary-query)||Changes the state of a bridge port whether IGMP membership reports are going to be forwarded to this port. By default IGMP membership reports (most importantly IGMP Join messages) are only forwarded to ports that have a multicast router or a IGMP Snooping enabled bridge connected to. Without at least one port marked as a |
|horizon (integer 0..429496729; Default: none)||Use split horizon bridging to prevent bridging loops. Set the same value for a group of ports, to prevent them from sending data to ports with the same horizon value. Split horizon is a software feature that disables hardware offloading. Read more about Bridge split horizon.|
|internal-path-cost (integer: 0..4294967295; Default: 10)||Path cost to the interface for MSTI0 inside a region. This property only has effect when |
|interface (name; Default: none)||Name of the interface.|
|path-cost (integer: 0..4294967295; Default: 10)||Path cost to the interface, used by STP to determine the best path, used by MSTP to determine the best path between regions. This property has no effect when |
|point-to-point (auto | yes | no; Default: auto)||Specifies if a bridge port is connected to a bridge using a point-to-point link for faster convergence in case of failure. By setting this property to |
|priority (integer: 0..240; Default: 128)||The priority of the interface, used by STP to determine the root port, used by MSTP to determine root port between regions.|
|pvid (integer 1..4094; Default: 1)||Port VLAN ID (pvid) specifies which VLAN the untagged ingress traffic is assigned to. This property only has an effect when |
|restricted-role (yes | no; Default: no)||Enable the restricted role on a port, used by STP to forbid a port from becoming a root port. This property only has an effect when |
|restricted-tcn (yes | no; Default: no)||Disable topology change notification (TCN) sending on a port, used by STP to forbid network topology changes to propagate. This property only has an effect when |
|tag-stacking (yes | no; Default: no)||Forces all packets to be treated as untagged packets. Packets on ingress port will be tagged with another VLAN tag regardless if a VLAN tag already exists, packets will be tagged with a VLAN ID that matches the |
|trusted (yes | no; Default: no)||When enabled, it allows forwarding DHCP packets towards the DHCP server through this port. Mainly used to limit unauthorized servers to provide malicious information for users. This property only has an effect when |
|unknown-multicast-flood (yes | no; Default: yes)||When enabled, the bridge floods unknown multicast traffic to all bridge egress ports. When disabled, drops unknown multicast traffic on egress ports. Multicast addresses that are in the MDB table are considered as learned multicasts and therefore will not be flooded to all ports. Without IGMP Snooping all multicast traffic will be dropped on egress ports. Has an effect only on an egress port. This option does not limit traffic flood to the CPU. Note that local multicast addresses (18.104.22.168/24) are not flooded when |
|unknown-unicast-flood (yes | no; Default: yes)||When enabled, bridge floods unknown unicast traffic to all bridge egress ports. When disabled, drops unknown unicast traffic on egress ports. If a MAC address is not learned in the host table, then the traffic is considered as unknown unicast traffic and will be flooded to all ports. MAC address is learnt as soon as a packet on a bridge port is received, then the source MAC address is added to the bridge host table. Since it is required for the bridge to receive at least one packet on the bridge port to learn the MAC address, it is recommended to use static bridge host entries to avoid packets being dropped until the MAC address has been learned. Has effect only on an egress port. This option does not limit traffic flood to the CPU.|
To group ether1 and ether2 in the already created bridge1 interface.
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:
Ports from an 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. This can be done using the
move command. Below is an example of how to sort interface lists:
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 the 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.
Bridge Port Monitoring
To monitor the current status of bridge ports, use the
/interface bridge port monitor
|edge-port (yes | no)||Whether the port is an edge port or not.|
|edge-port-discovery (yes | no)||Whether the port is set to automatically detect edge ports.|
|external-fdb (yes | no)||Whether the registration table is used instead of a forwarding database.|
|forwarding (yes | no)||Shows if the port is not blocked by (R/M)STP.|
|hw-offload-group (switchX)||Switch chip used by the port.|
|learning (yes | no)||Shows whether the port is capable of learning MAC addresses.|
|multicast-router (yes | no)||Shows if a multicast router is detected on the port.|
|port-number (integer 1..4095)||A port-number will be assigned in the order that ports got added to the bridge, but this is only true until reboot. After reboot, the internal port numbering will be used.|
|point-to-point-port (yes | no)||Whether the port is connected to a bridge port using full-duplex (yes) or half-duplex (no).|
|role (designated | root port | alternate | backup | disabled)|
(R/M)STP algorithm assigned the role of the port:
|sending-rstp (yes | no)||Whether the port is sending RSTP or MSTP BPDU types. A port will transit to STP type when RSTP/MSTP enabled port receives an STP BPDU.|
|status (in-bridge | inactive)||Port status:|
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.
/interface bridge host
|age (read-only: time)||The time since the last packet was received from the host. Appears only for dynamic, non-external, and non-local host entries|
|bridge (read-only: name)||The bridge the entry belongs to|
|disabled (read-only: flag)||Whether the static host entry is disabled|
|dynamic (read-only: flag)||Whether the host has been dynamically created|
|external (read-only: flag)||Whether the host has been learned using an external table, for example, from a switch chip or Wireless registration table. Adding a static host entry on a hardware-offloaded bridge port will also display an active external flag|
|invalid (read-only: flag)||Whether the host entry is invalid, can appear for statically configured hosts on already removed interface|
|local (read-only: flag)||Whether the host entry is created from the bridge itself (that way all local interfaces are shown)|
|mac-address (read-only: MAC address)||Host's MAC address|
|on-interface (read-only: name)||Which of the bridged interfaces the host is connected to|
To get the active hosts table:
Since RouterOS v6.42 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 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 host table.
/interface bridge host
|bridge (name; Default: none)||The bridge interface to which the MAC address is going to be assigned.|
|disabled (yes | no; Default: no)||Disables/enables static MAC address entry.|
|interface (name; Default: none)||Name of the interface.|
|mac-address (MAC address; Default: )||MAC address that will be added to the host table statically.|
|vid (integer: 1..4094; Default: )||VLAN ID for the statically added MAC address entry.|
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 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.
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 (-):
|RouterBoard/[Switch Chip] Model||Features in Switch menu||Bridge STP/RSTP||Bridge MSTP||Bridge IGMP Snooping||Bridge DHCP Snooping||Bridge VLAN Filtering||Bonding|
|CRS1xx/CRS2xx series||+||+||-||+ 2||+ 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.
- The feature will not work properly in VLAN switching setups.
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 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:
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).
Port switching with bridge configuration and enabled hardware offloading since RouterOS v6.41:
Make sure that hardware offloading is enabled and active by checking the "H" flag:
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
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 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).
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 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-only-untagged-and-priority-tagged will be automatically added as untagged ports for the
/interface bridge vlan
|bridge (name; Default: none)||The bridge interface which the respective VLAN entry is intended for.|
|disabled (yes | no; Default: no)||Enables or disables Bridge VLAN entry.|
|tagged (interfaces; Default: none)||Interface list with a VLAN tag adding action in egress. This setting accepts comma-separated values. e.g. |
|untagged (interfaces; Default: none)||Interface list with a VLAN tag removing action in egress. This setting accepts comma-separated values. e.g. |
|vlan-ids (integer 1..4094; Default: 1)||The list of VLAN IDs for certain port configuration. This setting accepts the VLAN ID range as well as comma-separated values. e.g. |
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 trunk 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.
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 bridge interface (or switch-cpu port on CRS3xx series switch), 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 in the Management port section.
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.
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.
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).
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.
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 the end, when VLAN configuration is complete, enable Bridge VLAN Filtering.
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.
Add bridge ports and specify
pvid on hybrid VLAN ports to assign untagged traffic to the intended VLAN.
Add Bridge VLAN entries and specify tagged and untagged ports in them. In this example egress VLAN tagging is done on ether6,ether7,ether8 ports too, making them into hybrid ports.
In the end, when VLAN configuration is complete, enable Bridge VLAN Filtering.
You don't have to add access ports as untagged ports, they will be added dynamically as an untagged port with the VLAN ID that is specified in
pvid, you can specify just the trunk port as a tagged port. All ports that have the same
pvid set will be added as untagged ports in a single entry. You must take into account that the bridge itself is a port and it also has a
pvid value, this means that the bridge port also will be added as an untagged port for the ports that have the same
pvid. You can circumvent this behavior by either setting different
pvid on all ports (even the trunk port and bridge itself), or to use
frame-type set to
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:
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 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:
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.
In case VLAN filtering is used and access from the trunk and/or access ports with tagged traffic is desired, additional steps are required. 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:
In case VLAN filtering is used and access from trunk and/or access ports with untagged traffic is desired, you need 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 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:
If the connection to the router/switch through an IP address is not required, then steps adding an IP address can be skipped since a connection to the router/switch through Layer2 protocols (e.g. MAC-telnet) will be working either way.
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
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 the bridge VLAN table is configured, you can enable bridge VLAN filtering, use these commands on SW1 and SW2:
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 a regular VLAN interface, but the
use-service-tag parameter toggles if the interface will use the Service VLAN tag.
ether-type=0x8100 is configured, the bridge checks the outer VLAN tag and sees if it is using EtherType
0x8100. If the bridge receives a packet with an outer tag that has a different EtherType, it will mark the packet as
untagged. Since RouterOS only checks the outer tag of a packet, it is not possible to filter 802.1Q packets when 802.1ad protocol is used.
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
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:
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 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:
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 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
- 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-floodis set to
unknown-unicast-floodis set to
broadcast-floodis set to
- MAC address for the bridge matches with a MAC address from one of the bridge slave ports
horizonfor both ports is set to
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 through just one interface.
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:
If packets are processed by Fast Path, then Fast Forward is not active. Packet count can be used as an indicator of whether Fast Forward is active or not.
Since RouterOS 6.44 it is possible to monitor Fast Forward status, for example:
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.
Starting from RouterOS version 6.41, the bridge supports IGMP 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 CRS1xx/2xx/3xx series switches also support IGMP Snooping with hardware offloading.
To enable IGMP snooping on a bridge, set
To monitoring multicast groups, use
print command in the
'/interface bridge mdb' menu.
To monitoring ports that are connected to a multicast router, use
monitor command in the
'/interface bridge port' menu.
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
Starting from RouterOS version 6.43, the bridge supports DHCP Snooping and DHCP Option 82. 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:
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:
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 from receiving any discovery messages and drop malicious DHCP server messages from ether3.
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 the Bridge Hardware Offloading section with supported features.
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.
/interface bridge filter, /interface bridge nat
|802.3-sap (integer; Default: )||DSAP (Destination Service Access Point) and SSAP (Source Service Access Point) are 2 one-byte fields, which identify the network protocol entities which use the link-layer service. These bytes are always equal. Two hexadecimal digits may be specified here to match an SAP byte.|
|802.3-type (integer; Default: )||Ethernet protocol type, placed after the IEEE 802.2 frame header. Works only if 802.3-sap is 0xAA (SNAP - Sub-Network Attachment Point header). For example, AppleTalk can be indicated by the SAP code of 0xAA followed by a SNAP type code of 0x809B.|
|action (accept | drop | jump | log | mark-packet | passthrough | return | set-priority; Default: )||Action to take if the packet is matched by the rule:|
|arp-dst-address (IP address; Default: )||ARP destination IP address.|
|arp-dst-mac-address (MAC address; Default: )||ARP destination MAC address.|
|arp-gratuitous (yes | no; Default: )||Matches ARP gratuitous packets.|
|arp-hardware-type (integer; Default: 1)||ARP hardware type. This is normally Ethernet (Type 1).|
|arp-opcode (arp-nak | drarp-error | drarp-reply | drarp-request | inarp-reply | inarp-request | reply | reply-reverse | request | request-reverse; Default: )||ARP opcode (packet type)|
|arp-packet-type (integer 0..65535 | hex 0x0000-0xffff; Default: )||ARP Packet Type.|
|arp-src-address (IP address; Default: )||ARP source IP address.|
|arp-src-mac-address (MAC addres; Default: )||ARP source MAC address.|
|chain (text; Default: )||Bridge firewall chain, which the filter is functioning in (either a built-in one, or a user-defined one).|
|dst-address (IP address; Default: )||Destination IP address (only if MAC protocol is set to IP).|
|dst-mac-address (MAC address; Default: )||Destination MAC address.|
|dst-port (integer 0..65535; Default: )||Destination port number or range (only for TCP or UDP protocols).|
|in-bridge (name; Default: )||Bridge interface through which the packet is coming in.|
|in-interface (name; Default: )||Physical interface (i.e., bridge port) through which the packet is coming in.|
|in-interface-list (name; Default: )||Set of interfaces defined in interface list. Works the same as |
|ingress-priority (integer 0..63; Default: )||Matches the priority of an ingress packet. Priority may be derived from VLAN, WMM, DSCP or MPLS EXP bit. read more»|
|ip-protocol (dccp | ddp | egp | encap | etherip | ggp | gre | hmp | icmp | icmpv6 | idpr-cmtp | igmp | ipencap | ipip | ipsec-ah | ipsec-esp | ipv6 | ipv6-frag | ipv6-nonxt | ipv6-opts | ipv6-route | iso-tp4 | l2tp | ospf | pim | pup | rdp | rspf | rsvp | sctp | st | tcp | udp | udp-lite | vmtp | vrrp | xns-idp | xtp; Default: )||IP protocol (only if MAC protocol is set to IPv4)|
|jump-target (name; Default: )||If |
|limit (integer/time,integer; Default: )||Restricts packet match rate to a given limit.|
|log-prefix (text; Default: )||Defines the prefix to be printed before the logging information.|
|mac-protocol (802.2 | arp | homeplug-av | ip | ipv6 | ipx | length | lldp | loop-protect | mpls-multicast | mpls-unicast | packing-compr | packing-simple | pppoe | pppoe-discovery | rarp | service-vlan | vlan | integer 0..65535 | hex 0x0000-0xffff; Default: )||Ethernet payload type (MAC-level protocol). To match protocol type for VLAN encapsulated frames (0x8100 or 0x88a8), a vlan-encap property should be used.|
|out-bridge (name; Default: )||Outgoing bridge interface.|
|out-interface (name; Default: )||Interface that the packet is leaving the bridge through.|
|out-interface-list (name; Default: )||Set of interfaces defined in interface list. Works the same as |
|packet-mark (name; Default: )||Match packets with a certain packet mark.|
|packet-type (broadcast | host | multicast | other-host; Default: )||MAC frame type:|
|src-address (IP address; Default: )||Source IP address (only if MAC protocol is set to IPv4).|
|src-mac-address (MAC address; Default: )||Source MAC address.|
|src-port (integer 0..65535; Default: )||Source port number or range (only for TCP or UDP protocols).|
|stp-flags (topology-change | topology-change-ack; Default: )||The BPDU (Bridge Protocol Data Unit) flags. Bridge exchange configuration messages named BPDU periodically for preventing loops|
|stp-forward-delay (integer 0..65535; Default: )||Forward delay timer.|
|stp-hello-time (integer 0..65535; Default: )||STP hello packets time.|
|stp-max-age (integer 0..65535; Default: )||Maximal STP message age.|
|stp-msg-age (integer 0..65535; Default: )||STP message age.|
|stp-port (integer 0..65535; Default: )||STP port identifier.|
|stp-root-address (MAC address; Default: )||Root bridge MAC address.|
|stp-root-cost (integer 0..65535; Default: )||Root bridge cost.|
|stp-root-priority (integer 0..65535; Default: )||Root bridge priority.|
|stp-sender-address (MAC address; Default: )||STP message sender MAC address.|
|stp-sender-priority (integer 0..65535; Default: )||STP sender priority.|
|stp-type (config | tcn; Default: )||The BPDU type:|
|tls-host (string; Default: )||Allows matching https traffic based on TLS SNI hostname. Accepts GLOB syntax for wildcard matching. Note that matcher will not be able to match hostname if the TLS handshake frame is fragmented into multiple TCP segments (packets).|
|vlan-encap (802.2 | arp | ip | ipv6 | ipx | length | mpls-multicast | mpls-unicast | pppoe | pppoe-discovery | rarp | vlan | integer 0..65535 | hex 0x0000-0xffff; Default: )||Matches the MAC protocol type encapsulated in the VLAN frame.|
|vlan-id (integer 0..4095; Default: )||Matches the VLAN identifier field.|
|vlan-priority (integer 0..7; Default: )||Matches the VLAN priority (priority code point)|
- 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
- VLAN matchers are only valid for
- IP or IPv6 related matchers are only valid if mac-protocol is either set to
- 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.
/interface bridge filter
|action (accept | drop | jump | log | mark-packet | passthrough | return | set-priority; Default: accept)||Action to take if the packet is matched by the rule:|
This section describes specific bridge NAT options.
/interface bridge nat
|action (accept | drop | jump | mark-packet | redirect | set-priority | arp-reply | dst-nat | log | passthrough | return | src-nat; Default: accept)||Action to take if the packet is matched by the rule:|
|to-arp-reply-mac-address (MAC address; Default: )||Source MAC address to put in Ethernet frame and ARP payload, when |
|to-dst-mac-address (MAC address; Default: )||Destination MAC address to put in Ethernet frames, when |
|to-src-mac-address (MAC address; Default: )||Source MAC address to put in Ethernet frames, when |