Summary

...

The Cloud Router Switch series are CCR3xx, CRS5xx series switches and CCR2116, CCR2216 routers have highly integrated switches with high-performance CPU and feature-rich packet processors. The CRS3xx series switches These devices can be designed into various Ethernet applications including unmanaged switch, Layer 2 managed switch, carrier switch, inter-VLAN router, and wired unified packet processingprocessor.

Features

Models

This table clarifies the main differences between Cloud Router Switch models and CCR routers.

Abbreviations

• FDB - Forwarding Database
• MDB - Multicast Database
• SVL - Shared VLAN Learning
• IVL - Independent VLAN Learning
• PVID - Port VLAN ID
• ACL - Access Control List
• CVID - Customer VLAN ID
• SVID - Service VLAN ID

Port switching

In order to set up a port switching on CRS3xx series switches, check the Bridge Hardware Offloading page.

VLAN

Since RouterOS version 6.41, a bridge 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 tunnel-like VLAN interfaces are bridged. Bridge VLAN Filtering configuration is highly recommended to comply with STP (802.1D), RSTP (802.1w) standards and it is mandatory to enable MSTP (802.1s) support in RouterOS.

VLAN Filtering

The main VLAN setting is vlan-filtering, which globally controls VLAN awareness and VLAN tag processing in the bridge. If vlan-filtering=no is used, the bridge ignores VLAN tags, works in a shared-VLAN-learning (SVL) mode and cannot modify VLAN tags of packets. Turning on vlan-filtering=yes, 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 its own Port VLAN ID (pvid).

Sub-menu: /interface bridge

...

Sub-menu: /interface bridge port

...

VLAN Table

Bridge VLAN table represents per-VLAN port mapping with an egress VLAN tag action. tagged ports send out frames with a specified VLAN ID tag. untagged ports remove the VLAN tag before sending out frames.

Sub-menu: /interface bridge vlan

...

Abbreviations

• FDB - Forwarding Database
• MDB - Multicast Database
• SVL - Shared VLAN Learning
• IVL - Independent VLAN Learning
• PVID - Port VLAN ID
• ACL - Access Control List
• CVID - Customer VLAN ID
• SVID - Service VLAN ID

Port switching

...

In order to set up a port switching, check the Bridge Hardware Offloading page.

VLAN

...

Since RouterOS version 6.41, a bridge 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 tunnel-like VLAN interfaces are bridged. Bridge VLAN Filtering configuration is highly recommended to comply with STP (802.1D), RSTP (802.1w) standards and it is mandatory to enable MSTP (802.1s) support in RouterOS.

VLAN Filtering

VLAN filtering is described on the Bridge VLAN Filtering section.

VLAN setup examples

Below are describes some of the most common ways how to utilize VLAN forwarding.

Port-Based VLAN

The configuration is described on the Bridge VLAN FIltering section.

MAC Based VLAN

Enable switching on ports by creating a bridge with enabled hw-offloading:

/interface bridge
add name=bridge1 vlan-filtering=yes
/interface bridge port
add bridge=bridge1 interface=ether2 hw=yes
add bridge=bridge1 interface=ether7 hw=yes

Add VLANs in the Bridge VLAN table and specify ports:

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

Add Switch rules which assign VLAN id based on MAC address:

/interface ethernet switch rule
add switch=switch1 ports=ether7 src-mac-address=A4:12:6D:77:94:43/FF:FF:FF:FF:FF:FF new-vlan-id=200
add switch=switch1 ports=ether7 src-mac-address=84:37:62:DF:04:20/FF:FF:FF:FF:FF:FF new-vlan-id=300
add switch=switch1 ports=ether7 src-mac-address=E7:16:34:A1:CD:18/FF:FF:FF:FF:FF:FF new-vlan-id=400

Protocol Based VLAN

VLAN setup examples

Below are describes some of the most common ways on how to utilize VLAN forwarding on the CRS3xx series switches.

Port-Based VLAN

The configuration for CRS3xx switches is described in the Bridge VLAN FIltering section.

MAC Based VLAN

Enable switching on ports by creating a bridge with enabled hw-offloading:

/interface bridge
add name=bridge1 vlan-filtering=yes
/interface bridge port
add bridge=bridge1 interface=ether2 hw=yes
add bridge=bridge1 interface=ether6 hw=yes
add bridge=bridge1 interface=ether7 hw=yes
add bridge=bridge1 interface=ether8 hw=yes

Add VLANs in the Bridge VLAN table and specify ports:

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

Add Switch rules which assign VLAN id based on MAC addressprotocol:

/interface ethernet switch rule
add switch=switch1 mac-protocol=ip new-vlan-id=200 ports=ether7 src-mac-address=A4:12:6D:77:94:43/FF:FF:FF:FF:FF:FFether6 switch=switch1
add mac-protocol=ipx new-vlan-id=200
add300 ports=ether7 switch=switch1 ports=ether7 src-
add mac-address=84:37:62:DF:04:20/FF:FF:FF:FF:FF:FFprotocol=0x80F3 new-vlan-id=300
add switch=switch1 400 ports=ether7 src-mac-address=E7:16:34:A1:CD:18/FF:FF:FF:FF:FF:FF new-vlan-id=400

Protocol Based VLAN

ether8 switch=switch1

VLAN Tunneling (Q-in-Q)

Since RouterOS v6.43 it is possible to use a provider bridge (IEEE 802.1ad) and Tag Stacking VLAN filtering, and hardware offloading at the same time. The configuration is described in the Bridge VLAN Tunneling (Q-in-Q) section.

Ingress VLAN translation

It is possible to translate a certain VLAN ID to a different VLAN ID using ACL rules on an ingress port. In this example we create two ACL rules, allowing bidirectional communication. This can be done by doing the following.

Create a new bridge and add ports to it with hardware Enable switching on ports by creating a bridge with enabled hw- offloading:

/interface bridge
add name=bridge1 vlan-filtering=yesno
/interface bridge port
add interface=ether1 bridge=bridge1 interface=ether2 hw=yes
add interface=ether2 bridge=bridge1 interface=ether6 hw=yes
add bridge=bridge1 interface=ether7 hw=yes
add bridge=bridge1 interface=ether8 hw=yes

Add ACL rules to translate a VLAN ID in each directionAdd VLANs in the Bridge VLAN table and specify ports:

/interface bridgeethernet switch vlanrule
add bridge=bridge1 taggednew-dst-ports=ether2 untagged=ether6 new-vlan-idsid=200
add20 bridgeports=bridge1ether1 taggedswitch=ether2switch1 untagged=ether7 vlan-idsid=30010
add bridge=bridge1 taggednew-dst-ports=ether1 new-vlan-id=10 ports=ether2 untaggedswitch=ether8switch1 vlan-idsid=40020

Add Switch rules which assign VLAN id based on MAC protocolboth VLAN IDs to the bridge VLAN table:

/interface ethernetbridge switch rulevlan
add mac-protocol=ip new-vlan-id=200 ports=ether6 switch=switch1
add mac-protocol=ipx new-vlan-id=300 ports=ether7 switch=switch1
add mac-protocol=0x80F3 new-vlan-id=400 ports=ether8 switch=switch1

VLAN Tunneling (Q-in-Q)

Since RouterOS v6.43 it is possible to use a provider bridge (IEEE 802.1ad) and Tag Stacking VLAN filtering, and hardware offloading at the same time on CRS3xx series switches. The configuration for CRS3xx switches is described in the Bridge VLAN Tunneling (Q-in-Q) section.

Ingress VLAN translation

It is possible to translate a certain VLAN ID to a different VLAN ID using ACL rules on an ingress port. In this example we create two ACL rules, allowing a bidirectional communication. This can be done by doing the following.

Create a new bridge and add ports to it with hardware offloading:

bridge=bridge1 tagged=ether1 vlan-ids=10
add bridge=bridge1 tagged=ether2 vlan-ids=20

Enable bridge VLAN filtering:

/interface bridge set bridge1 vlan-filtering=yes

(R/M)STP

...

CRS3xx, CRS5xx series switches, and CCR2116, CCR2216 routers are capable of running STP, RSTP, and MSTP on a hardware level. For more detailed information you should check out the Spanning Tree Protocol manual page.

Bonding

...

CRS3xx, CRS5xx series switches and CCR2116, CCR2216 routers support hardware offloading with bonding interfaces. Only 802.3ad and balance-xor bonding modes are hardware offloaded, other bonding modes will use the CPU's resources. You can find more information about the bonding interfaces in the Bonding Interface section. If 802.3ad mode is used, then LACP (Link Aggregation Control Protocol) is supported.

To create a hardware offloaded bonding interface, you must create a bonding interface with a supported bonding mode:

/interface bonding
add mode=802.3ad name=bond1 slaves=ether1,ether2

This interface can be added to a bridge alongside other interfaces:

/interface bridge
add name=bridge

/interface bridge
add name=bridge1 vlan-filtering=no
/interface bridge port
add bridge=bridge interface=ether1 bridge=bridge1=bond1 hw=yes
add bridge=bridge interface=ether3 hw=yes
add interfacebridge=ether2bridge bridgeinterface=bridge1ether4 hw=yes

Add ACL rules to translate a VLAN ID in each direction:

/interface ethernet switch rule
add new-dst-ports=ether2 new-vlan-id=20 ports=ether1 switch=switch1 vlan-id=10
add new-dst-ports=ether1 new-vlan-id=10 ports=ether2 switch=switch1 vlan-id=20

Add both VLAN IDs to the bridge VLAN table:

/interface bridge vlan
add bridge=bridge1 tagged=ether1 vlan-ids=10
add bridge=bridge1 tagged=ether2 vlan-ids=20

Enable bridge VLAN filtering:

/interface bridge set bridge1 vlan-filtering=yes

(R/M)STP

CRS3xx series switches are capable of running STP, RSTP and MSTP on a hardware level. For more detailed information you should check out the Spanning Tree Protocol manual page.

Bonding

Since RouterOS v6.42 all CRS3xx series switches support hardware offloading with bonding interfaces. Only 802.3ad and balance-xor bonding modes are hardware offloaded, other bonding modes will use the CPU's resources. You can find more information about the bonding interfaces in the Bonding Interface section. If 802.3ad mode is used, then LACP (Link Aggregation Control Protocol) is supported.

To create a hardware offloaded bonding interface, you must create a bonding interface with a supported bonding mode:

/interface bonding
add mode=802.3ad name=bond1 slaves=ether1,ether2

This interface can be added to a bridge alongside with other interfaces:

/interface bridge
add name=bridge
/interface bridge port
add bridge=bridge interface=bond1 hw=yes
add bridge=bridge interface=ether3 hw=yes
add bridge=bridge interface=ether4 hw=yes

Make sure that the bonding interface is hardware offloaded by checking the "H" flag:

Make sure that the bonding interface is hardware offloaded by checking the "H" flag:

/interface bridge port print 
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload 
 #     INTERFACE            

/interface bridge port print 
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload 
 #     INTERFACE                                 BRIDGE                                 HW
 0   H bond1                                     bridge                                 yes
 1   H ether3                                    bridge                                 yes
 2   H ether4                                    bridge                                 yes

...

Multi-chassis Link Aggregation Group

...

MLAG (Multi-chassis Link Aggregation Group) implementation in RouterOS allows configuring LACP bonds on two separate devices, while the client device believes to be connected on the same machine. This provides a physical redundancy in case of switch failure. All CRS3xx, CRS5xx series and CCR2116, CCR2216 devices can be configured with MLAG. Read here for more information.

L3 Hardware Offloading

...

Layer3 hardware offloading (otherwise known as IP switching or HW routing) will allow to offload some of the router features on to the switch chip. This allows to reach wire speeds when routing packets, which simply would not be possible with the CPU. 

The feature can be enabled with:

/interface ethernet switch
set switch1 l3hw=yes

Currently supported and unsupported feature list:

...

Depending on the complexity of routes in routing table, max HW accelerated route count could change (see hardware specific limits below). Whole-byte IP prefixes (/8, /16, /24, etc.) occupy less HW space than others (e.g., /22).

If HW route limit is reached new routes will fall back to CPU, except cases when newly added route overlaps with already existing routes processed by hardware. In this case destinations that were processed in hardware will continue to be processed in hardware. The user should choose the device with HW capability large-enough to store all the routes.

...

Where:

• CPU - feature is supported but processed by CPU
• HW - feature is supported and offloaded in hardware (works when l3hw=yes)
• FW - feature is supported and offloaded in hardware (works when l3hw=fw)
• N/A - feature is not available, meaning that L3 Hardware offloading MUST be disabled for these features to work

List of supported devices and their limits

...

1. 4500 / 3750 ³

...

*1 When the HW limit of Fasttrack or NAT entries is reached, other connections will fall back to the CPU. MikroTik's smart connection offload algorithm ensures that the connections with the most traffic are offloaded to the hardware.

*2 Fasttrack connections share the same HW memory with ACL rules. Depending on the complexity, one ACL rule may occupy the memory of 3-6 Fasttrack connections.

*3 (Both MPLS and Bridge Port Extender are disabled) / (MPLS, Bridge Port Extender, or both are enabled). MPLS shares the HW memory with Fasttrack connections. Moreover, enabling MPLS requires the allocation of the entire memory region, which could store up to 750 Fasttrack connections otherwise. The same applies to Bridge Port Extender. However, MPLS and Bridge Port Extended may use the same memory region, so enabling them both doesn't double the limitation of Fasttrack connections.

*4 All NAT entries cannot be used due to the limited amount of Fasttrack connections.

Port isolation

Since RouterOS v6.43 is it possible to create a Private VLAN setup on CRS3xx series switches, an example can be found in the Switch chip port isolation manual page. Hardware offloaded bonding interfaces are not included in the switch port-isolation menu, but it is still possible to configure port-isolation individually on each secondary interface of the bonding.

IGMP Snooping

CRS3xx series switches are capable of using IGMP Snooping on a hardware level. To see more detailed information, you should check out the IGMP Snooping manual page.

DHCP Snooping and DHCP Option 82

CRS3xx series switches are capable of using DHCP Snooping with Option 82 on a hardware level. The switch will create a dynamic ACL rule to capture the DHCP packets and redirect them to the main CPU for further processing. To see more detailed information, please visit the DHCP Snooping and DHCP Option 82 manual page.

Mirroring

Mirroring lets the switch sniff all traffic that is going in a switch chip and send a copy of those packets out to another port (mirror-target). This feature can be used to easily set up a tap device that allows you to inspect the traffic on your network on a traffic analyzer device. It is possible to set up a simple port-based mirroring, but it is also possible to set up more complex mirroring based on various parameters. Note that mirror-target port has to belong to the same switch (see which port belongs to which switch in /interface ethernet menu). Also mirror-target can have a special 'cpu' value, which means that sniffed packets will be sent out of switch chips cpu port. There are many possibilities that can be used to mirror certain traffic, below you can find most common mirroring examples:

Port Based Mirroring:

/interface ethernet switch
set switch1 mirror-source=ether2 mirror-target=ether3

...

features onto the switch chip. This allows reaching wire speeds when routing packets, which simply would not be possible with the CPU. 

Offloaded feature set depends on the used chipset. Read here for more info.

Port isolation

...

Since RouterOS v6.43 is it possible to create a Private VLAN setup, an example can be found in the Switch chip port isolation manual page. Hardware offloaded bonding interfaces are not included in the switch port-isolation menu, but it is still possible to configure port-isolation individually on each secondary interface of the bonding.

IGMP/MLD Snooping

...

CRS3xx, CRS5xx series switches and CCR2116, CCR2216 routers are capable of using IGMP/MLD Snooping on a hardware level. To see more detailed information, you should check out the IGMP/MLD snooping manual page.

DHCP Snooping and DHCP Option 82

...

CRS3xx, CRS5xx series switches and CCR2116, CCR2216 routers are capable of using DHCP Snooping with Option 82 on a hardware level. The switch will create a dynamic ACL rule to capture the DHCP packets and redirect them to the main CPU for further processing. To see more detailed information, please visit the DHCP Snooping and DHCP Option 82 manual page.

Controller Bridge and Port Extender

...

Controller Bridge (CB) and Port Extender (PE) is an IEEE 802.1BR standard implementation in RouterOS. 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.

Mirroring

...

Mirroring is a function that allows a network switch to duplicate all the data passing through it and send a copy to another specified port, known as the mirror-target. This feature is useful for setting up a tap device, which allows for analyzing network traffic using a separate device. You can set up mirroring in a simple way by designating source ports (see mirror-egress and mirror-ingress in /interface/ethernet/switch/port), or you can configure more advanced mirroring based on different criteria (see mirror in /interface/ethernet/switch/rule).

It is important to note that the mirror-target port must be on the same switch. You can check the device block diagram or navigate to the /interface/ethernet menu to identify which interfaces are connected where. When setting up the configration, it is not mandatory to add the mirror-target interface to the same hardware offloaded bridge where the source ports are set up. The mirror-target port can be a standalone interface (not configured as a bridge port), or it can be within a bridge setup. When using the mirror-target with a bridge, note that data and mirrored traffic may both travel on the same LAN. In such cases, consider employing RSPAN (Remote Switch Port Analyzer), where mirrored traffic is encapsulated into a separate VLAN before being transmitted over the network.

Additionally, you can set the mirror-target port to a special value "cpu", which means that the copied packets will be sent to the switch chip's CPU port.

Configuration examples

Port Based Mirroring

Starting from RouterOS version 7.15, it is possible to configure multiple source ports and selectively choose whether to mirror incoming traffic, outgoing traffic, or both. In this example, both incoming and outgoing traffic from the ether2 interface will be copied and sent to the ether3 interface for monitoring or analysis.

# Since RouterOS v7.15
/interface ethernet switch port
set ether2 mirror-egress=yes mirror-ingress=yes
/interface ethernet switch
set switch1 mirror-target=ether3

# Older RouterOS:
/interface ethernet switch
set switch1 mirror-source=ether2 mirror-target=ether3

VLAN Based Mirroring

Using ACL rules, it is possible to mirror packets from multiple interfaces using the ports setting. Additionally, you can specify more detailed criteria such as VLAN ID, MAC/IP address or TCP/UDP port. Only ingress packets are mirrored to mirror-target interface. This example will mirror incoming VLAN 11 traffic from the ether2 interface, and send copies to the ether3 interface. To use an ACL rule with a vlan-id matcher, you need to have bridge vlan-filtering enabled.

/interface bridge
set bridge1 vlan-filtering=yes
/interface ethernet switch
set switch1 mirror-target=ether3
/interface ethernet switch rule
add mirror=yes ports=ether1 switch=switch1 vlan-id=11

MAC Based Mirroring

This example will mirror incoming traffic with 64:D1:54:D9:27:E6 MAC destination or source address from the ether1 interface, and send copies to the ether3 interface.

/interface ethernet switch
set switch1 mirror-target=ether3
/interface ethernet switch rule
add mirror=yes ports=ether1 switch=switch1 dst-mac-address=64:D1:54:D9:27:E6/FF:FF:FF:FF:FF:FF
add mirror=yes ports=ether1 switch=switch1 src-mac-address=64:D1:54:D9:27:E6/FF:FF:FF:FF:FF:FF

IP Based Mirroring

This example will mirror incoming traffic with 192.168.88.0/24 IP destination or source address from the ether1 interface, and send copies to the ether3 interface.

/interface ethernet switch
set switch1 mirror-target=ether3 mirror-source=none
/interface ethernet switch rule
add mirror=yes ports=ether1 switch=switch1 src-address=192.168.88.0/24
add mirror=yes ports=ether1 switch=switch1 dst-address=192.168.88.0/24

There are other options as well, check the ACL section to find out all possible parameters that can be used to match packets.

Remote Switch Port Analyzer

This example will mirror incomming and outgoing traffic from the ether2 interface, copies will be encapsulated in 802.1Q VLAN using the 999 as VLAN ID, and packets will be sent to the ether3 interface. If the original traffic is already VLAN tagged, RSPAN will add another layer of VLAN tagging as an outer tag. This results in the mirrored traffic being tagged twice. If the mirror-target port is included in vlan-filtering bridge, it is not required to make the interface as tagged VLAN member under the /interface/bridge/vlan menu for the RSPAN.

/interface ethernet switch port
set switch1ether2 mirror-sourceegress=noneyes mirror-targetingress=ether3yes
/interface ethernet switch
set rule
addswitch1 mirror-target=yesether3 portsrspan=ether1,ether2 switch=switch1

VLAN Based Mirroring:

/interface bridge
set bridge1 vlan-filtering=yes
/interface ethernet switch
set switch1 mirror-target=ether3 mirror-source=none
/interface ethernet switch rule
add mirror=yes ports=ether1 switch=switch1 vlan-id=11

MAC Based Mirroring:

/interface ethernet switch
set switch1 mirror-target=ether3 mirror-source=none
/interface ethernet switch rule
add mirror=yes ports=ether1 switch=switch1 dst-mac-address=64:D1:54:D9:27:E6/FF:FF:FF:FF:FF:FF
add mirror=yes ports=ether1 switch=switch1 src-mac-address=64:D1:54:D9:27:E6/FF:FF:FF:FF:FF:FF

Protocol Based Mirroring:

/interface ethernet switch
set switch1 mirror-target=ether3 mirror-source=none
/interface ethernet switch rule
add mirror=yes ports=ether1 switch=switch1 mac-protocol=ipx

IP Based Mirroring:

/interface ethernet switch
set switch1 mirror-target=ether3 mirror-source=none
/interface ethernet switch rule
add mirror=yes ports=ether1 switch=switch1 src-address=192.168.88.0/24
add mirror=yes ports=ether1 switch=switch1 dst-address=192.168.88.0/24

There are other options as well, check the ACL section to find out all possible parameters that can be used to match packets.

Traffic Shaping

yes rspan-egress-vlan-id=999 rspan-ingress-vlan-id=999

Property Reference

Sub-menu: /interface/ethernet/switch

Sub-menu: /interface/ethernet/switch/port

Sub-menu: /interface/ethernet/switch/rule

Traffic Shaping

...

It It is possible to limit a certain type of traffic using ACL rules. For CRS3xx series switches it is possible to limit ingress traffic that matches certain parameters with ACL rules and it is possible to limit ingress/egress traffic per port basis. For ingress traffic QoS policer is used, for egress traffic QoS shaper is used.basis. The policer is used for ingress traffic, the shaper is used for egress traffic. The ingress policer controls the received traffic with packet drops. Everything that exceeds the defined limit will get dropped. This can affect the TCP congestion control mechanism on end hosts and achieved bandwidth can be actually less than defined. The egress shaper tries to queue packets that exceed the limit instead of dropping them. Eventually, it will also drop packets when the output queue gets full, however, it should allow utilizing the defined throughput better.

Port-based traffic police and shaperPort Based Traffic Shaping:

/interface ethernet switch port
set ether1 ingress-rate=10M egress-rate=5M

MAC Based Traffic Shaping-based traffic policer:

/interface ethernet switch rule
add ports=ether1 switch=switch1 src-mac-address=64:D1:54:D9:27:E6/FF:FF:FF:FF:FF:FF rate=10M

VLAN Based Traffic Shaping-based traffic policer:

/interface bridge
set bridge1 vlan-filtering=yes
/interface ethernet switch rule
add ports=ether1 switch=switch1 vlan-id=11 rate=10M

...

Protocol Based Traffic Shaping-based traffic policer:

/interface ethernet switch rule
add ports=ether1 switch=switch1 mac-protocol=ipx rate=10M

There are other options as well, check the ACL section to find out all possible parameters that can be used to match packets.

Traffic Storm Control

...

Since RouterOS v6.42 it is possible to enable traffic storm control on CRS3xx series devices. A traffic storm can emerge when certain frames are continuously flooded on the network. For example, if a network loop has been created and no loop avoidance mechanisms are used (e.g. Spanning Tree Protocol), broadcast or multicast frames can quickly overwhelm the network, causing degraded network performance or even complete network breakdown. With CRS3xx, CRS5xx series switches and CCR2116, CCR2216 routers it is possible to limit broadcast, unknown multicast and unknown unicast traffic. Unknown unicast traffic is considered when a switch does not contain a host entry for the destined MAC address. Unknown multicast traffic is considered when a switch does not contain a multicast group entry in the /interface bridge mdb menu. Storm control settings should be applied to ingress ports, the egress traffic will be limited.

...

/interface ethernet switch port
set ether1 storm-rate=1 limit-broadcasts=yes limit-unknown-unicasts=yes

MPLS hardware offloading

...

Since RouterOS v6.41 it is possible to offload certain MPLS functions to the switch chip, the switch must be a (P)rovider router in a PE-P-PE setup in order to achieve hardware offloading. A setup example can be found in the Basic MPLS setup example manual page. The hardware offloading will only take place when LDP interfaces are configured as physical switch interfaces (e.g. Ethernet, SFP, SFP+).

Switch Rules (ACL)

...

Access Control List contains ingress policy and egress policy engines. See this table on how many rules each device supports (limited by RouterOS). It is an advanced tool for wire-speed packet filtering, forwarding and modifying based on Layer2, Layer3 and Layer4 protocol header field conditions.packet filtering, forwarding and modifying based on Layer2, Layer3 and Layer4 protocol header field conditions.

Sub-menu: /interface ethernet switch rule

...

Port Security

...

It is possible to limit allowed MAC addresses on a single switch port on CRS3xx series switches. For example, to allow 64:D1:54:81:EF:8E MAC address on a switch port, start by switching multiple ports together, in this example 64:D1:54:81:EF:8E is going to be located behind ether1. 

...

Dual Boot

...

“Dual The “dual boot” feature allows you to choose which operating system you prefer to use on CRS3xx series switches, RouterOS or SwOS. Device operating system could be changed using:

• Command-line (/system routerboard settings set boot-os=swos)
• Winbox
• Webfig
• Serial Console

More details about SwOS are described here: SwOS manual

Configuring SwOS using RouterOS

...

Since RouterOS 6.43 it is possible to load, save and reset SwOS configuration, as well as upgrade SwOS and set an IP address for the switch CRS3xx series switches by using RouterOS.

• Save configuration with /system swos save-config

...

See also

CRS Router

CRS3xx VLANs with Bonds

Basic VLAN switching

Bridge Hardware Offloading

Route Hardware Offloading

Spanning Tree Protocol

MTU on RouterBOARD

Layer2 misconfiguration

Bridge VLAN Table

Bridge IGMP/MLD snooping

Multi-chassis Link Aggregation Group