RouterOS Switch Chip Hardware Guide
RouterOS Switch Chip Hardware Guide
Section titled “RouterOS Switch Chip Hardware Guide”Summary
Section titled “Summary”MikroTik devices across multiple product lines contain dedicated switch chip hardware that accelerates Layer 2 forwarding. When switch chip offloading is active, packets are forwarded at wire speed by the switch chip without involving the CPU. This guide covers the concepts and configuration for hardware switching, VLAN tagging, port isolation, and ACL rules, and explains the key differences between switch chip families — including the distinction between CRS (Cloud Router Switch) and CSS (Cloud Smart Switch) product lines.
Switch Chip Families
Section titled “Switch Chip Families”MikroTik switch chips fall into four families, each with distinct chip hardware, feature sets, and configuration commands.
Family Overview
Section titled “Family Overview”| Family | Switch Chips | ACL Command | VLAN Command | Max ACL Rules |
|---|---|---|---|---|
| RouterBOARD (non-CRS) | QCA8337, Atheros8327/16/27, MT7621, MT7531, 88E6393X, 88E6191X | /interface ethernet switch rule | /interface ethernet switch vlan | 16–256 |
| CRS1xx/2xx | QCA-8511, QCA-8513L, QCA-8519 | /interface ethernet switch acl | /interface ethernet switch egress-vlan-tag + /ingress-vlan-translation | 128 |
| CRS3xx/CRS5xx/CCR2116/CCR2216 | Marvell 98DX series | /interface ethernet switch rule | Bridge VLAN filtering | 128–1365 |
CRS vs CSS: Platform Distinction
Section titled “CRS vs CSS: Platform Distinction”CRS (Cloud Router Switch) devices run RouterOS as their primary operating system. CRS3xx and CRS5xx series additionally support dual-boot into SwOS (a simplified switch operating system) via /system routerboard settings set boot-os=swos. All RouterOS configuration documented in this guide applies to CRS devices.
CSS (Cloud Smart Switch) devices run SwOS by default and do not support RouterOS. Configuration for CSS devices is performed through the SwOS web interface or Winbox SwOS mode. CSS devices are out of scope for RouterOS documentation.
Key rule: If your switch runs RouterOS, it is a CRS or RouterBOARD device. CSS switches are SwOS-only.
Hardware Switching Architecture
Section titled “Hardware Switching Architecture”How Hardware Offloading Works
Section titled “How Hardware Offloading Works”Standard RouterOS bridge forwarding processes packets in software, using the CPU to make forwarding decisions. When a switch chip is present and hardware offloading is enabled, the switch chip intercepts bridged traffic and makes forwarding decisions independently in hardware. The CPU is bypassed for data-plane traffic, reducing latency and allowing wire-speed forwarding even at 10G and 25G link speeds.
Hardware offloading is controlled per bridge port using the hw parameter:
/interface bridgeadd name=bridge1 vlan-filtering=yes
/interface bridge portadd bridge=bridge1 interface=ether2 hw=yesadd bridge=bridge1 interface=ether3 hw=yesadd bridge=bridge1 interface=ether4 hw=yesWhen hw=yes is set and the switch chip supports offloading, the port gains an H flag visible in /interface bridge port print. If the H flag is absent, offloading failed — typically because of an unsupported feature combination (see below).
Conditions That Disable Hardware Offloading
Section titled “Conditions That Disable Hardware Offloading”The following configurations cause a port to fall back to software bridging even when hw=yes is set:
- Bridge uses a protocol mode (STP/RSTP/MSTP) with unsupported features on the chip
- Multiple bridges present (only one bridge can use hardware offloading at a time on most chips)
- An unsupported EtherType is configured (MT7621, MT7531, RTL8367, EN7523 chips only support
0x8100; enabling0x88a8or0x9100disables offload) - Tag stacking features are enabled on chips that do not support them
Verifying Offload Status
Section titled “Verifying Offload Status”/interface bridge port printPorts with the H (hardware offload) flag are forwarded by the switch chip. Ports without H are forwarded in software.
Switch Chip Model Comparison
Section titled “Switch Chip Model Comparison”RouterBOARD Non-CRS Chips
Section titled “RouterBOARD Non-CRS Chips”Embedded switch chips found on routers such as RB5009, RB3011, RB2011, hEX series.
| Feature | QCA8337 | Atheros8327 | MT7621 | 88E6393X |
|---|---|---|---|---|
| Port Mirroring | Yes | Yes | Yes | Yes |
| TX Rate Limit | Yes | Yes | No | Yes |
| RX Rate Limit | Yes | Yes | No | Yes |
| Host Table Size | 2048 | 2048 | 2048 | 16K |
| VLAN Table | 4096 | 4096 | 4096 | 4096 |
| ACL Rules | 92 | 92 | None | 256 |
| VLAN EtherType | 0x8100 only | 0x8100 only | 0x8100 only | All |
CRS1xx/CRS2xx Chips (Qualcomm Atheros)
Section titled “CRS1xx/CRS2xx Chips (Qualcomm Atheros)”| Chip | Devices | FDB | ACL Rules | Jumbo |
|---|---|---|---|---|
| QCA-8511 | CRS105, CRS106, CRS112 | 2048 | 128 | 9204 |
| QCA-8513L | CRS109, CRS125 | 2048 | None | 4064 |
| QCA-8519 | CRS210, CRS212, CRS226 | 2048 | 128 | 9204 |
CRS1xx/2xx chips use a distinct VLAN configuration model (ingress translation tables and egress tag tables) rather than bridge VLAN filtering. They support static link aggregation but not LACP (802.3ad). There is no L3 hardware offloading on these chips.
CRS3xx/CRS5xx/CCR Chips (Marvell 98DX)
Section titled “CRS3xx/CRS5xx/CCR Chips (Marvell 98DX)”| Chip | Example Devices | ACL Rules | FDB | Notable |
|---|---|---|---|---|
| 98DX3236 | CRS326-24G-2S+, CRS328-24P | 128 | 16K | Entry-level |
| 98DX3257 | CRS354-48G | 170 | 32K | 48-port GE |
| 98DX8208/8216 | CRS309, CRS317 | 1024 | 32K–128K | 10G SFP+ |
| 98DX8332 | CRS326-24S+2Q+ | 256 | 32K | 10G access |
| 98DX4310 | CRS504-4XQ, CRS510-8XS | 1024 | 128K | 100G |
| 98DX8525 | CRS518-16XS-2XQ, CCR2216 | 1024 | 128K | 25G/100G |
| 98DX7335 | CRS812-8DS-2DQ-2DDQ | 1365 | 128K | 400G |
| 98DX3255 | CCR2116-12G-4S+ | 512 | 32K | 16-core CPU |
CRS3xx/CRS5xx chips support LACP bonding, IGMP/MLD snooping, DHCP snooping, RSPAN, MLAG, L3 hardware offloading, and PTP hardware timestamping. These features are absent on CRS1xx/2xx and most RouterBOARD chips.
VLAN Configuration by Chip Family
Section titled “VLAN Configuration by Chip Family”CRS3xx/CRS5xx and RouterBOARD: Bridge VLAN Filtering
Section titled “CRS3xx/CRS5xx and RouterBOARD: Bridge VLAN Filtering”For CRS3xx/CRS5xx and RouterBOARD chips (from RouterOS v6.41+), the recommended approach uses bridge VLAN filtering. This approach is standards-compliant and supports MSTP.
Access port (untagged ingress, untagged egress):
/interface bridgeadd name=bridge1 vlan-filtering=yes
/interface bridge portadd bridge=bridge1 interface=ether2 hw=yes pvid=10add bridge=bridge1 interface=ether3 hw=yes pvid=10add bridge=bridge1 interface=ether7 hw=yes # trunk
/interface bridge vlanadd bridge=bridge1 vlan-ids=10 tagged=ether7 untagged=ether2,ether3pvid sets the VLAN assigned to untagged ingress traffic. Ports listed as untagged in the VLAN table strip the tag on egress.
Trunk port (tagged egress for multiple VLANs):
/interface bridge vlanadd bridge=bridge1 vlan-ids=10 tagged=ether7add bridge=bridge1 vlan-ids=20 tagged=ether7add bridge=bridge1 vlan-ids=30 tagged=ether7RouterBOARD Non-CRS: Switch VLAN Table (Legacy)
Section titled “RouterBOARD Non-CRS: Switch VLAN Table (Legacy)”RouterBOARD chips also support a switch-level VLAN table, which is independent of bridge VLAN filtering. This approach predates bridge VLAN filtering and may be used on older configurations.
/interface ethernet switch vlanadd ports=ether2,ether3 switch=switch1 vlan-id=200add ports=ether2,ether4 switch=switch1 vlan-id=300
/interface ethernet switch portset ether2 vlan-mode=secure vlan-header=add-if-missingset ether3 vlan-mode=secure vlan-header=always-strip default-vlan-id=200set ether4 vlan-mode=secure vlan-header=always-strip default-vlan-id=300VLAN mode options control how strictly the switch enforces VLAN table membership:
| Mode | Untagged Traffic | Tagged (VLAN match) | Tagged (no match) |
|---|---|---|---|
disabled | Forward | Forward | Forward |
fallback | Forward | Forward | Drop |
check | Drop | Forward | Drop |
secure | Drop | Forward (if ingress+egress in table) | Drop |
CRS1xx/CRS2xx: Ingress Translation + Egress Tag Tables
Section titled “CRS1xx/CRS2xx: Ingress Translation + Egress Tag Tables”CRS1xx/2xx chips use a separate mechanism from bridge VLAN filtering. Untagged ingress traffic is assigned to VLANs using ingress translation rules; egress tagging is controlled per VLAN.
/interface ethernet switch ingress-vlan-translationadd ports=ether6 customer-vid=0 new-customer-vid=200add ports=ether7 customer-vid=0 new-customer-vid=300
/interface ethernet switch egress-vlan-tagadd tagged-ports=ether2 vlan-id=200add tagged-ports=ether2 vlan-id=300
/interface ethernet switch vlanadd ports=ether2,ether6 vlan-id=200 learn=yesadd ports=ether2,ether7 vlan-id=300 learn=yesVLAN Tunneling (Q-in-Q) — CRS3xx/CRS5xx Only
Section titled “VLAN Tunneling (Q-in-Q) — CRS3xx/CRS5xx Only”Provider bridge (802.1ad) with double-tagging is supported on CRS3xx/CRS5xx devices:
/interface bridgeset bridge1 ether-type=0x88a8Note: The 98DX3255 chip (used in CRS354 series and CCR2116) does not support VLAN filtering on 1Gbps interfaces for 0x88a8 and 0x9100 VLAN types.
Port Isolation
Section titled “Port Isolation”Port isolation prevents direct communication between ports while permitting access to uplink ports. Configuration differs by chip family.
RouterBOARD Non-CRS: Port Isolation Override
Section titled “RouterBOARD Non-CRS: Port Isolation Override”/interface bridgeadd name=bridge1/interface bridge portadd bridge=bridge1 interface=sfp1 hw=yesadd bridge=bridge1 interface=ether1 hw=yesadd bridge=bridge1 interface=ether2 hw=yesadd bridge=bridge1 interface=ether3 hw=yes
/interface ethernet switch port-isolationset ether1 forwarding-override=sfp1set ether2 forwarding-override=sfp1set ether3 forwarding-override=sfp1forwarding-override forces all egress traffic from the port to specific port(s) only, regardless of the MAC forwarding table. This is Private VLAN-equivalent behavior.
Isolated switch groups (two independent port domains sharing no traffic):
/interface ethernet switch port-isolationset ether1 forwarding-override=ether2,ether3set ether2 forwarding-override=ether1,ether3set ether3 forwarding-override=ether1,ether2set ether4 forwarding-override=ether5set ether5 forwarding-override=ether4When VLAN table support is present (QCA8337, Atheros8327/8316/8227/7240), VLAN lookup can override port isolation. For strict isolation between ports sharing a VLAN, use switch rules with new-dst-ports="".
CRS3xx/CRS5xx: Isolated Port Flag
Section titled “CRS3xx/CRS5xx: Isolated Port Flag”/interface ethernet switch portset ether1 isolated=yesset ether2 isolated=yesIsolated ports cannot forward traffic to other isolated ports. They can still communicate with non-isolated ports. This integrates with VLAN filtering and hardware-offloaded bonding interfaces.
CRS1xx/CRS2xx: Isolation Leakage Profiles
Section titled “CRS1xx/CRS2xx: Isolation Leakage Profiles”Port isolation on CRS1xx/2xx uses leakage profiles, where each profile defines which destination ports traffic may reach:
/interface ethernet switch portset ether1 isolation-leakage-profile-override=0set ether2 isolation-leakage-profile-override=0Multiple ports sharing a leakage profile value of 0 are isolated from each other, forwarding only to uplink ports not assigned to the profile.
ACL Rules
Section titled “ACL Rules”Access Control Lists provide wire-speed packet filtering, forwarding modification, and VLAN assignment in hardware.
RouterBOARD Non-CRS and CRS3xx/CRS5xx: Switch Rules
Section titled “RouterBOARD Non-CRS and CRS3xx/CRS5xx: Switch Rules”Both RouterBOARD and CRS3xx/CRS5xx devices use /interface ethernet switch rule. Rules are evaluated in order; first match wins.
Drop traffic from a specific MAC address:
/interface ethernet switch ruleadd ports=ether1 switch=switch1 \ src-mac-address=64:D1:54:81:EF:8E/FF:FF:FF:FF:FF:FF \ new-dst-ports=""new-dst-ports="" with no ports drops the packet.
Redirect to CPU for inspection:
/interface ethernet switch ruleadd ports=ether2 switch=switch1 redirect-to-cpu=yes mac-protocol=arpVLAN assignment based on source MAC (MAC-based VLAN):
/interface ethernet switch ruleadd switch=switch1 ports=ether7 \ src-mac-address=A4:12:6D:77:94:43/FF:FF:FF:FF:FF:FF \ new-vlan-id=200Ingress rate limiting (first 32 rules on QCA8337/Atheros8327):
/interface ethernet switch ruleadd ports=ether3 switch=switch1 rate=10MMatch Conditions
Section titled “Match Conditions”| Field | Applies To | Description |
|---|---|---|
src-mac-address | All | Source MAC with mask |
dst-mac-address | All | Destination MAC with mask |
mac-protocol | All | EtherType (ip, arp, ipv6, 0x88a8, etc.) |
vlan-id | All | VLAN ID |
vlan-header | All | VLAN header presence |
vlan-priority | All | PCP value (0–7) |
src-address / dst-address | All | IPv4 source/destination with mask |
src-address6 / dst-address6 | All | IPv6 source/destination |
protocol | All | IP protocol number |
src-port / dst-port | All | TCP/UDP port number |
dscp | All | DSCP value (0–63) |
flow-label | CRS3xx+ | IPv6 flow label |
IPv4 and IPv6 conditions cannot be combined in the same rule.
ACL Rule Limits by Chip
Section titled “ACL Rule Limits by Chip”| Chip | Max Rules |
|---|---|
| Atheros8316 | 8–32 |
| QCA8337, Atheros8327 | 8–16 (92 entries total, 16 usable per port) |
| 88E6393X | 42–256 |
| CRS3xx 98DX3236 | 128 |
| CRS3xx 98DX3257 | 170 |
| CRS3xx 98DX8332 | 256 |
| CRS3xx 98DX3255 (CCR2116) | 512 |
| CRS3xx 98DX8208/8216 | 1024 |
| CRS5xx 98DX4310 | 1024 |
| CRS5xx 98DX7335 | 1365 |
CRS1xx/CRS2xx: ACL Menu
Section titled “CRS1xx/CRS2xx: ACL Menu”CRS1xx/2xx devices use a separate ACL table under /interface ethernet switch acl. Rules can be applied to ingress or egress:
/interface ethernet switch acladd action=drop src-mac-addr-state=sa-not-found \ src-ports=ether6,ether7 table=egressadd action=drop src-mac-addr-state=static-station-move \ src-ports=ether6,ether7 table=egressThe QCA-8513L chip (CRS109, CRS125) does not support ACL rules.
Port Security
Section titled “Port Security”Use ACL rules together with bridge learning controls to restrict which MAC addresses may communicate on a port.
Allow only one specific MAC address on ether1 (CRS3xx/RouterBOARD):
/interface ethernet switch ruleadd ports=ether1 switch=switch1 \ src-mac-address=64:D1:54:81:EF:8E/FF:FF:FF:FF:FF:FFadd new-dst-ports="" ports=ether1 switch=switch1
/interface bridge portset [find interface=ether1] learn=no unknown-unicast-flood=no
/interface bridge hostadd bridge=bridge1 interface=ether1 mac-address=64:D1:54:81:EF:8EThe first rule allows the known MAC; the second drops everything else on that port. Disabling learning and flood prevents unknown unicast bypass.
Traffic Mirroring
Section titled “Traffic Mirroring”Port-Based Mirroring (RouterBOARD Non-CRS)
Section titled “Port-Based Mirroring (RouterBOARD Non-CRS)”/interface ethernet switchset switch1 mirror-source=ether2 mirror-target=ether3mirror-source and mirror-target must belong to the same switch chip.
Port-Based Mirroring (CRS3xx, RouterOS 7.15+)
Section titled “Port-Based Mirroring (CRS3xx, RouterOS 7.15+)”/interface ethernet switch portset ether2 mirror-ingress=yes mirror-egress=yesset ether3 mirror-target=yesVLAN/MAC/IP-Based Mirroring (CRS3xx/CRS5xx)
Section titled “VLAN/MAC/IP-Based Mirroring (CRS3xx/CRS5xx)”# Mirror by VLAN/interface ethernet switch ruleadd mirror=yes ports=ether1 switch=switch1 vlan-id=100
# Mirror by source MAC/interface ethernet switch ruleadd mirror=yes ports=ether1 switch=switch1 \ src-mac-address=64:D1:54:D9:27:E6/FF:FF:FF:FF:FF:FFRemote SPAN (RSPAN) — CRS3xx/CRS5xx Only
Section titled “Remote SPAN (RSPAN) — CRS3xx/CRS5xx Only”RSPAN tunnels mirrored traffic to a remote analyzer over a VLAN:
/interface bridge vlanadd bridge=bridge1 tagged=ether3 vlan-ids=999The mirror target port must be on the same switch chip. It can be a standalone interface or bridge member.
Feature Comparison Across Chip Families
Section titled “Feature Comparison Across Chip Families”| Feature | RouterBOARD | CRS1xx/2xx | CRS3xx/CRS5xx |
|---|---|---|---|
| Hardware Offloading | Yes | Yes | Yes |
| Bridge VLAN Filtering (hw) | Yes (v7) | No | Yes |
| Switch VLAN Table | Yes | Separate tables | Via switch rules |
| ACL / Switch Rules | Yes | Yes (separate menu) | Yes |
| Port Isolation | Yes (port-isolation) | Yes (leakage profiles) | Yes (isolated=yes) |
| LACP / 802.3ad | No | No | Yes |
| IGMP Snooping (hw) | No | Yes | Yes |
| DHCP Snooping | No | No | Yes |
| L3 Hardware Offloading | No | No | Yes |
| Q-in-Q / 802.1ad | Chip-dependent | No | Yes (most chips) |
| MSTP | No | No | Yes |
| RSPAN | No | No | Yes |
| PTP Hardware Timestamps | No | No | Yes |
| Dual Boot (RouterOS/SwOS) | No | No | Yes (CRS3xx/5xx) |
Multi-Chip Devices
Section titled “Multi-Chip Devices”Some MikroTik devices contain two or more independent switch chips managing different port groups:
| Device | Switch Chip 1 | Switch Chip 2 |
|---|---|---|
| RB3011 | ether1–ether5 (QCA8337) | ether6–ether10 (QCA8337) |
| RB4011iGS+ | ether1–ether5 (RTL8367) | ether6–ether10 (RTL8367) |
| RB1100AHx4 | ether1–ether5 | ether6–ether10 / ether11–ether13 |
On multi-chip devices, traffic between ports on different switch chips must pass through the CPU by default. To enable hardware-forwarded VLAN traffic across chip boundaries, add all ports to a single bridge with vlan-filtering=yes and configure the bridge VLAN table to include ports from both chips.
/interface bridgeadd name=bridge1 vlan-filtering=yes
/interface bridge portadd bridge=bridge1 interface=ether2 hw=yesadd bridge=bridge1 interface=ether3 hw=yesadd bridge=bridge1 interface=ether6 hw=yesadd bridge=bridge1 interface=ether7 hw=yes
/interface bridge vlanadd bridge=bridge1 tagged=ether2,ether3,ether6,ether7 vlan-ids=10