Community discussions

MikroTik App
 
marcodor
just joined
Topic Author
Posts: 15
Joined: Tue Jan 25, 2011 8:44 pm

Hardware Switching on CCR2004-16G-2S+

Mon Jan 20, 2025 10:06 am

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!
 
ConradPino
Member
Member
Posts: 441
Joined: Sat Jan 21, 2023 12:44 pm
Location: San Francisco Bay
Contact:

Re: Harware switching on CCR2004-16G-2S+

Mon Jan 20, 2025 1:07 pm

https://cdn.mikrotik.com/web-assets/pro ... 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/R ... p+Features
https://help.mikrotik.com/docs/spaces/R ... NFiltering
https://help.mikrotik.com/docs/spaces/R ... VLAN+Table
Links above are suggested reading for your device. Forum VLAN tutorial follows.
viewtopic.php?t=143620
 
marcodor
just joined
Topic Author
Posts: 15
Joined: Tue Jan 25, 2011 8:44 pm

Re: Harware switching on CCR2004-16G-2S+

Mon Jan 20, 2025 2:09 pm

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 [x] 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?
 
wrkq
Frequent Visitor
Frequent Visitor
Posts: 79
Joined: Mon Jul 29, 2019 10:59 pm

Re: Hardware Switching on CCR2004-16G-2S+

Wed Jan 22, 2025 12:09 am

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.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 13301
Joined: Thu Mar 03, 2016 10:23 pm

Re: Hardware Switching on CCR2004-16G-2S+

Wed Jan 22, 2025 7:45 am

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".

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".
 
wrkq
Frequent Visitor
Frequent Visitor
Posts: 79
Joined: Mon Jul 29, 2019 10:59 pm

Re: Hardware Switching on CCR2004-16G-2S+

Wed Jan 22, 2025 10:47 am

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".
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? :)
 
marcodor
just joined
Topic Author
Posts: 15
Joined: Tue Jan 25, 2011 8:44 pm

Re: Hardware Switching on CCR2004-16G-2S+

Thu Jan 23, 2025 12:56 pm

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 :) .