Thanks you. Hope I can get some light to clarify some doubts on a post I opened regarding this
Hehe, you beat me to it.
No, my issue hasn't been resolved (and is still present in 7.22beta1), so I'm still using my workaround.
After @strods asked me to email in a packet capture a month ago, I received no further response until 7.21 got released to stable, and then all of a sudden someone replied to my ticket yesterday, asking for a supout file.
If @gabacho4 is having the same issue, then I guess it won't be fixed in stable until 7.22 releases, assuming it actually gets looked at this time around...
I do use and like CapsMan myself. But I do not use almost any of advanced features.
Considering your recommendation:
I thought on the oposite scenario.
How to solve the same problem but in local fowarding?
As far as I know this tool, there is no way of replicating some Firewall Rules through the CapsMan signaling to Caps. It is correct?
A very unmatured method that passed on my mind was:
- On CapsMan create an specific chain that will be “magically” replicated to Caps
- On Cap, beyond the chain that automagically came from CapsMan, another automagically entry on Firewall Rules that says “whatever packets that comes from the radio interfaces controlled by CapsMan Jump to MagicallyReplicatedChainFromCapsman.
P.S.: Rereading my answer, this seems much more like the concept of SDN than CapsMan. Which isn't a bad thing... Maybe it could be a new tool that can be used in conjunction with CapsMan.
While I appreciate the variant effort, that is a whole lot of noise for something that simply just works on 7.20.x, and also just works as it should on other routing platforms.
I’m going to wait until they fix it rather than hack up dhcp scripts. Thanks
[admin@MikroTik] /system/resource/irq/rps> export
2026-01-15 17:27:24 by RouterOS 7.20.7
[admin@MikroTik] /system/resource/irq/rps> print
0 X ether1
1 X ether2
2 X ether3
3 X ether4
4 X ether5
5 X ether6
6 X ether7
7 X ether8
8 X sfp-sfpplus1
[admin@MikroTik] /system/resource/irq/rps> export
2026-01-15 17:29:13 by RouterOS 7.21
[admin@MikroTik] /system/resource/irq/rps> print
0 X ether1
1 X ether2
2 X ether3
3 X ether4
4 X ether5
5 X ether6
6 X ether7
7 X ether8
8 X sfp-sfpplus1
What’s new? The fact that it now shows up in WinBox?
This for real? They finally did it? Hurray!
For my cap ac (arm): on 7.20.7 /system/resource/irq/rps menu was available. Now on 7.21 it is gone. Apparently it is now arm64 only.
yes " * arm64 - allow enabling receive packet steering on /system/resource/irq/rps menu in order to overcome unbalanced CPU load;"
It’s gone from RB4011 too, also arm. MT doesn’t stop to surprise us!
Yes they did it, but unfortunately it was botched because you cannot specify a :0: preferred subnet…
They should split at least the ARM32 version into a -lite and -full version… ARM32 devices like hAP ac2 suffer from lack of flash space (and thus the urge to keep image small) but for other ARM devices (like RB4011) this issue isn’t present.
RPS is about the kernel spreading interrupt requests across all CPU cores. It doesn’t know/care about how you’ve configured the ports.
My understanding was there is one network interface on the CPU connected to one of the switch ASIC ports. Hence only one IRQ, not one per switch port. But this seems not to be the case.
Anyway, I agree my setup hardly benefits from RPS. The questions was more out of curiosity.
Problem solved by downgrading to LTS.
I’ll report this here on the v7.21 thread, but I’m sure this affects all previous versions. I’ll avoid calling it a bug, but (to me) it’s a very undesirable behavior.
For testing, I used an old RB3011 that was running v7.19.1. Upgraded it to latest (v7.21), everything fine.
On v7.21, I “reset-configuration” with
/system/reset-configuration skip-backup=yes keep-users=yes no-defaults=yes
Upon first boot, was asked to see license, and configurations were really cleaned up, no problem on that.
And here what I believe shouldn’t happen and, at least to me, is an undesirable behavior. Even after a software reset-configuration, command history, on the CLI, can still be seen. I can see commands from before the reset-configuration, and I don’t believe this should happen. While commands containing “password” won’t go to the history, and this is great, there are lots of other commands that can have sensitive information and i would NOT like them to persist even between reset-configurations.
To me, there’s no point on the command history NOT being cleared up on the reset-configuration sequence.
The command to clear history already exists (/console/clear-history), and to me it should be automatically applied with reset-configuration.
I believe there is no MPLS handler implemented for RPS, so all traffic is distributed to a single CPU core, therefore there doesn't seem to be any noticeable improvement in core utilization for this type of traffic.
It is called reset-configuration and not reset-configuration-and-cli-history. Joke aside, I give this a +1. I would not expect a configuration reset to have cli history left behind. It is probably because of keep users flag. CLI history is per user.
hmmmmm CLI history is per user … great guess I hadn’t considered.
Tried a new “reset-configuration” with keep-users=no …. and CLI history is indeed wiped out!
Great catch, thanks!
That being said …. i would still not expect a reset-config to persist old CLI history. But mistery (kind of) solved. Thanks!
Hello, I upgraded my router Chateau LTE6 from 7.20.2 to 7.21. After that the ssh and webfig (https) are broken. For ssh log, I see auth timeout.
So I downgraded again the router to 7.20.2 and everything were Ok.
I don’t know which port connects to the CPU (switchX on some routers), but you could look at the CPU/IRQ utilization in Winbox/Webfig and tinker with enabling/disabling it on various interfaces to find out.
Where did you get this screenshot with command stats?