CRS106-1C-5S Packet loss CPU->switch?

RouterOS General
1

Hi
To start with, yes I know this is a switch so ideally bridge configs should not be used but my application is extremely low throughput, talking like 0-200 kbit/s so not getting max switch performance is not really a concern for me. (And I’m running the main bridge ports HW offloaded too so I guess that would bring it closer to the performance of a pure switch config anyway)

But My question is this, I’m running some ping monitoring netwatch just to log the health of my devices on this network and this ping fails sometimes for one to several seconds but I can not see any real interruptions on my network between the three ports in the bridge (combo1, sfp1, sfp2) so therefor I begun to think this happens between the CPU and bridge/switch chip.
Any Ideas? Is it possible that the netwatch task or the CPU traffic is simply prioritized away under certain running conditions because of the low processing power? If so, can I somehow check that?

I can also add that if I disable HW offload for these bridge ports and force all traffic trough the CPU, then I see real network drops when ping drops, probably no surprise.
netwatch.png
ping.png
brconf.png

2

Your CRS has a pretry weak CPU but should be able to handle a few Mbps without too much sweat. When it comes to outages, many things might be happening. One is actual overload due to some “stupid” task … having winbox connected can load switch’s CPU a lot (if open windows update lots of contents). Another possibility is “overloading” netwatch itself … try to run it less frequently so that timeout expires sooner than it should start new check (doesn’t explain actual traffic loss though).

Open terminal window and run CPU profile to see which task(s) - if any - consume lots of CPU cycles.

3

Yes, I know switches have weak CPU. It can not see that this happens more if I try to load the CPU but I have not reached 100% either. This is without winbox connected. And the interruptions still happens if I keep only a single netwatch so I don’t think it is caused by netwatch itself either. “Management” is the only thing that peeks a little in CPU profile.