Hardware Switching on CCR2004-16G-2S+

RouterOS Beginner Basics
1

Hello,

I have a CCR2004-16G-2S+ device and want to define Ports 9-16 mapped to the hardware switch2 as a LAN switch.
Ports 1-8 to be used for ISP connection and other purposes.

In order to benefit of hardware switching, what should the settings be?
Can it be done without a lan-bridge? As i see in Switch/Settings there is a check box “Switch all ports”.
But strange, if i check it, then on next reconnect it became again unchecked.

Thanks!

2

https://cdn.mikrotik.com/web-assets/product_files/CCR2004-16G-2S_240151.png
Switch Chip 88E6191X times 2 with 8 ports per switch, supports Bridge VLAN Filtering. No L3 Hardware Offloading.
https://help.mikrotik.com/docs/spaces/ROS/pages/15302988/Switch+Chip+Features
https://help.mikrotik.com/docs/spaces/ROS/pages/328068/Bridging+and+Switching#BridgingandSwitching-BridgeVLANFiltering
https://help.mikrotik.com/docs/spaces/ROS/pages/28606465/Bridge+VLAN+Table
Links above are suggested reading for your device. Forum VLAN tutorial follows.
http://forum.mikrotik.com/t/using-routeros-to-vlan-your-network/126489/1

3

Thanks, ConradPino, I have read the documentation, first link, before posting here.
Unfortunately, the chapter describing Port Switching is quite short.

As I said, I checked Switch all ports for Switch2 chip, but it is not persistent on reconnect.
Also, assigning LAN address on “ether9” and configuring DHCP Server on it, will it dispatch the addresses for local lan? I tried it without success.
I don’t need any other “advanced” features like VLAN, filtering or so..

Or maybe better to go with “classical” bridge solution and add in a lan bridge ports 9-16?
Will it have some performance issues compared to true/native hardware chip level switching? or will it still be used if i go with a brigde?

4

In order to get “true/native hardware switching” on layer2 on any version of ROS released from 2018 onwards, you use what is listed in documentation under “Bridge Hardware Offloading”.

  • Create an /interface/bridge object
  • add ports to it under /interface/bridge/ports (Bridge->Ports in GUI), with the hardware offload setting enabled
  • configure vlans and such if wanted
  • look for the H-flag on the ports, which should be there as long as the prerequisites from the documentation are met.

There’s a general standard caveat in documentation saying only one ROS bridge can do hardware offloading, and default best-practice is “only one bridge total unless you know you need more”.
I actually kinda wonder if that’s an accurate description of ROS software limitation, or is it a bit more of “no more than one bridge object with HW offload per one switch-chip”.
But if you want to use ports 1-8 (one chip) as straight-to-CPU not added to any bridge, and ports 9-16 (other chip) as HW offloaded bridge that’s for sure fine.

Basically ignore the /interface/ethernet/switch menu. You won’t gain any noticeable performance that way on this hardware, and you can give yourself a lot of grief.
The “switch all ports” is a weird setting specific to one chip you don’t have, and it’s not doing what you’re looking for.

To answer your DHCP question, no, after you have ports as bridge members you don’t ever attach any software feature to the physical ports.
You attach the DHCP server on the bridge-to-cpu interface, which is confusingly “the bridge itself” (bridge1, my-bridge-name-here, whatever).
Or, if using vlans, attach a layer3 vlan interface to the bridge-itself interface, then DHCP server to the vlan interface.

5

In reality it is “one bridge per switch chip” … and it can be the same bridge on both chips. Since there are many caveats around HW offloading bridge(s) (some think single port can somehow be HW offloaded, some don’t consider which ports belong to which switch chip, with multiple bridges one has to set things up correctly so that intended bridge(s) is(are) offloaded, etc.) and not many users know and/or understand them, it’s safer to go with “single bridge per device”.

6

Thanks, that’s great to know, and well, kinda what I hope-xpected.
Admittedly I could imagine there’s some legacy software limitation that really wouldn’t ever perform the HW-programming on any bridge beyond the first one found, or such.
ROS is quirky but it’s part of why we love it so much, right? :slight_smile:

7

Thank You for Your answers!

So, a classical logical bridge is the way to go, and it will benefit automatically once the ports are on the same switch chip.
I know how to setup and configure it.

I thought there is something “magic” to do it on a more physical level, without a bridge definition :slight_smile: .