Beginner Basics • Re: CRS326-4C+20G+2Q+ high CPU with incoming packets

Hi!

You're jumping in on the deep end here. What you want can generally be done, but expect a bit of a learning curve on the way. Actually I've helped someone with a setup similar to yours recently and the results were very satisfying.

The CRS (Cloud Router Switch) devices are named quite awkwardly, and in fact have a bit of a strange architecture that you have to be aware of. (Actually, the architecture is very similar to the switches from other manufacturers, but their configuration interfaces generally don't expose you to these. Mikrotik does.)

The CRS series are routers *only* in that they support the full functionality of RouterOS. These functions are carried out on the CPU which is quite weak, and basically only useful for minimal routing, management, etc. purposes. (In my book this is actually a huge plus; full VPN support for management purposes has come in very useful for me in some setups.) That your have significant CPU load is because your packets are getting somehow handled by the CPU. I'll get back to why that might be.

The CRS series also include quite powerful switch chips that are in fact fully capable of wire speed switching.

Mikrotik follows the Linux way of configuring things almost exactly. This means that semantically a "bridge" using the DSA (Distributed Switching Architecture) is defined. The functions of this can always be done in software (in CPU, and having a weak one, it's usefulness is very limited), however when there is an appropriate hardware switch attached (as in your device), the bridge can have some or all functionality "offloaded" to hardware. This is when you get wire-speed. The offloading happens automatically - that is when your configuration can be offloaded, it is done, you only get an indication that it was or wasn't. Thus it's your job to create a configuration where there is nothing that *excludes* offloading.

So currently your configuration is not suitable on at least two points:
* For hardware offloading to occur, you *have* to use a bridge. Even if it includes only one physical port, go from there. Not having a bridge in no way simplifies your setup and I don't know why you would assume that.
* Actually bridges under Linux and therefore Mikrotik always have a (sort of virtual/implicit) port connecting them to the CPU. Some consequences:
* If you send BUM (Broadcast, Unknown unicast, Multicast) traffic in, then it will go out on all ports of the switch, except the one that it came in on. So even if you are only sending unicast traffic - because its destination is unknown (not yet learned) - it will be flooded to all ports, including the CPU, which will result in CPU load when it has to receive these packets. This will be mitigated once a device where the packets are going actually gets connected. If your packets are broadcast/multicast, CPU involvement will still occur.
* If you are indeed sending this amount of traffic, and you require no CPU involvement in this (only L2 as you put it), the switch can be configured to *not* forward these packets to the CPU. This is actually the correct configuration for such setups. There are again two approaches to this:
1. Your switch supports direct filtering rules. This sort of filtering can be done at MAC address, MAC protocol (and if your traffic is actually IP, then at the IP source/destination address, IP protocol, port number, etc.) levels.
2. The above (not involving the CPU) can also be done via assigning them to a VLAN internally. This is probably simpler to configure, but then your device really has no access to that network, including possibly as a DHCP server, or SSH, to your machines etc.

Anyhow, when asking a question please always include a (possible sanitized) full config output.

And tell us *what* the traffic is: how is it addressed at the MAC level? at the IP level? is it IP at all? is it unicast? is it multicast?

Statistics: Posted by MaxOffload — Tue Mar 25, 2025 2:13 am