I would like to know about internal efficiency when using interface lists in firewall rules. For example, if I need to match packets between multiple interfaces in all directions, what would be more efficient for CPU?
Using interface lists
/interface list
add name=testlist
/interface list member
add interface=vlan101 list=testlist
add interface=vlan102 list=testlist
/ip firewall mangle
add action=mark-packet chain=forward in-interface-list=testlist new-packet-mark=intervlan out-interface-list=testlist passthrough=yes
This is an example with only two interfaces. The more interfaces are part of this configuration, the more rules would be needed. Lists are definitely easier from usability point of view, but I’m curious if it’s also more efficient. On the other hand, if internally expanding the lists results in more rules, it could be slower potentially. Technically speaking, this example with two interfaces has the possibility of four variations: vlan101 => vlan101, vlan101 => vlan102, vlan102 => vlan102, vlan102 => vlan101.
This is more of an academic question, although with a large number of interfaces it could get practical meaning.
I’d expect that one rule using interface-list would be more effective than multiple rules using interfaces. One aspect is overhead of executing a rule, which is the same for any rule (regardless the check types), and I assume it’s not trivial. The other aspect is handling interface-lust members, these could be either checked very efficiently in a close loop inside rule … or they could be handled very inefficiently by caling simillar rule with single interface for every list member. I’d expect ROS to implement the former (efficient) strategy in which case using interface lists makes lots of sense.
But the above is only my speculation. Only MT engineers can give you a definite answer to your question, and to get an answer you’d probably have to open a ticket with support (e.g. via e-mail).
a. For traffic to or from a single subnet USE: SRC or DST address x.x.x.0/24
b. For traffic to or from two or more whole subnets USE: interface lists
c. For traffic to or from remote subnets (not known to the router) USE: firewall address lists
d. For traffic to or from a group of users ( less than a subnet or from various subnets ) WITH OR WITHOUT other whole subnets USE: firewall address lists
An exception to b, is that the management interface list entry may contain only only one subnet ( interface list used in neighbours discovery and in mac-server mac-winbox )
Thank you both for input. If RouterOS 7 uses nftables behind the scenes, then it has the ability to define multiple interfaces in a single rule (unlike iptables). And because it’s a built-in nftables functionality, I’m sure it is as efficient as it can be.
I did a quick anecdotal iperf single stream test and watched CPU usage. Two-rule approach loaded one core up to 97% and even 100% very briefly. The interface list method loaded one core to 88%. Granted, it’s not a very scientific test with many factors, but the results were consistent on multiple runs. It definitely didn’t get worse.
I like that approach. It wouldn’t be too bad if RouterOS allowed you to reuse existing subnet/network definitions rather than having to re-enter them across different spaces, such as /ip addresses and ip firewall address-list.
Coming from a software engineering background, if I have many instances of the same thing and I make a conscious decision to update one - then I have to update them all. Having a single instance and referencing that many times is much easier to tweak.
Additionally, being able to specify multiple interfaces in firewall rules would be nice to reduce the number of interface lists based on permutations - though I believe RouterOS uses iptables rather than nftables. The latter supports comma-separated in/out interfaces.