CPU saving tricks and best practice - any?

Hello,

just wanted to ask if there any recommendations on which way to solve typical tasks on Mikrotiks to save resources?

Say, when it comes to mangle there is a well-known advice to do packet-mark or routing-mark based on marks made by connection-mark rules. This is very easy to understand as we don’t even need to understand the deep mechanics of RouterOS to understand that marking several connections easier that marking many packets.

But there are a lot of mysterious places that may impact CPU and RAM as well. Say, if I add a net to Address List I can write, for example, ‘192.168.0.0/24’ or ‘192.168.0.0-192.168.0.255’ or even ‘192.168.0.1-192.168.0.254’, and I don’t know if it’ll affect the CPU at all.

Any ideas, please?

Rule order.

Would be interesting to know exactly the firewall matchers priorities (e.g. interface input, Mac address, SRC IP, ..) to tune up rules (in addition to correct rules reordering as pukkita said)

About address lists, I usually set networks in CIDR format (not ranges) but I’m not aware if it’s the best solution

Surely I always mark connections and not packets (but for advanced QoS needs I have to)

.. ..

If you were bored, you could go read the source code of netfilter. :wink:

I’d think that they probably have a data structure that’s a list of pointers to the match functions for each rule, and possibly even sorted in descending order of speediness… return false upon first failed check, since all criteria must return true.
Certainly regex payload matching is ultra slow compared to “this 32 bit IP address = that 32 bit IP address”
in a 32bit processor, that’s just one command of machine code. (not sure how many cpu cycles it is)

Netfilter is interesting because many of these interesting match types are modules, called on the Linux prompt by -m [arg] [arg] [arg]

eg - the ability to specify multiple port numbers in the same rule is actually a module
-m multiport --port 100,200,300:400,500

ROS is silently translating into that format, certainly. . .

I’d be more than happy than know main pitfalls and potentially problematic places which may lead to serious resource overuse. Say, use packet-mark instead of connection-mark is bad, we push router to spend extra CPU.

sure ..I’ll start tomorrow :laughing:

I’m sure I’ve seen somewhere a mikrotik matcher priority list, but I didn’t remember where. Maybe in a MUM presentation video ..?!?..
Anyway, knowing the matchers speed/priority could help to understand the best way to design rules. An overkill? Probably but in some ddos situations maybe could help.

yes important topic to optimize

especially with lower end devices

with bandwidth growing a config what work one year, the next year works but at 90% cpu usage

What I say is that even if we have wiki and some presentations to explain things in fact I really tired to differentiate between 5.x and 6.x. The wiki is more that full formally but lack of explanations in sense of “how it really works” and yes, “how can I do things effectively”. Keeping in mind Mikrotik hardware pricing (so we can get more powerful device to be sure in the, say, its CPU power), but I’d really like to implement things in the nicest and cutest way.

The problem is, I don’t expect to see big documentation upgrade (but to show versions difference) and in the the docs explains things. So there are some situations when I’m not sure if it’s me who don’t understand the RouterOS approaches or it is the ROS bug or hidden feature.

Yeah - documentation version has been a bit of an issue ever since the old days.

Personally, I started with Mikrotik long after I understood networking theory AND iptables, so learning MT has just been a case of learning how ROS does things. The white papers on various topics are good whenever I’m learning something new, MPLS for instance, but I mostly use the documentation as a command reference. I feel that in this regard, the documentation is pretty good, insofar as google is very good at taking me directly to the most relevant page.

Some of the community-supplied material is good but (in my opinion) needs a major cleanup, especially if the Internet has moved on since the document was written. (an article that includes filtering bogon routes has LOTS of prefixes that were idle back then, but are active today)

If more people were willing to learn “theory” and best practice, they’d find Mikrotik much easier to work with.

The same true for every network device. But lack of best-practice docs for MT pushes me personally to guess and bother instead of spend an hour on reading kind of “This common problem should be solved this way since this and this reason is important on MT”.

For instant example, I’ve read a lot of posts over the Internet on how to do dual-WAN link and some of these posts (even new one) are reprints old and quite inelegant approaches like scheduling script that will ping ISP’s gw to check if link is alive and then rewriting the device’s whole routing table (while using recursive routing and some built-in feature like netwatch may help a lot). As for me, all these posts may be voided and never appeared if we have good howto docs with good explanations what, how and why should be done in different cases.

Just the grumbling, indeed :slight_smile: I understand that MT is good as of their size and their hardware and software good too compared to other solutions of the same price.

But some explanations which config line impacts CPU more or less would be more that nice present for everyone here, I guess.

GOD I hate those solutions. Scripts are great for certain things - especially event-driven things (alas they don’t offer many event-based script hooks, like “pppoe connection established” or “dhcp-client received new IP address”)

I’ve seen some crazy stuff in these forums that makes me want to reach into the screen and shake people “just do THIS! What you’re doing is flat-out insane!” In their defense, they didn’t know the in’s and out’s of whatever protocol naturally does what they want…

I laugh because some posts on here are like people wanting to graft alligator heads onto their sheep because the wolves keep eating their sheep, and the sheep could protect itself with an alligator head - now how to let alligator teeth eat grass… post on forums begging for solution! (just get some guard dogs, silly!)

My favorite questions are about why firewall won’t allow to put hostname (or better site URL) into deny or allow rule on the firewall to block facebook on someone’s company LAN. The best argument then is “Microsoft ISA allow me to use hostnames so why Microtik won’t?” Thus, “such silly Mikrotik”, isn’t it? :slight_smile:

If you want people to do things right way you need to educate them. Unless they don’t have time, or brain, or background education, or… whatever. And of course at the first place you have to educate people how to ask the right questions to get right answers.

This is why you’ll always have job :slight_smile:

The funny thing is - if you want to block hostnames, all you have to do is force DNS to your own server, and poison the hostnames you want to block with using RPZ or just make facebook.com resolve to 127.0.0.1 (haha)

You don’t HAVE to do EVERYTHING in one little box.

That solution is SO MUCH faster and less CPU hogging than running regex on each and every packet looking for facebook.com - which is actually a 100% waste of time now ANYWAY since facebook uses SSL.

Derrrrrr! You might as well print out all JPG files detected so you can inspect them for the Loch Ness monster - it would be an equally useful endeavor. :wink: