How is the new “/interface list” feature implemented on the underlying iptables system?
Does it scale well when lots of interfaces are in the list? (like 400 or so)
I do know that for address lists there exists an underlying “ipset” feature that stores lists
of addresses or subnets as a hashed list and can directly be referenced from an iptables rule.
But for input and output interfaces, I don’t think such a feature exists.
Am I right in assuming that a firewall filter line with specification of an input interface as an
interface list instead of a specific interface will result in a number of iptables lines, one for each
of the interfaces in the list?
And what will happen when both the input and the output interface are specified as an interface
list, will that result in a number of lines equal to the square of the number of interfaces in that list?
Ok that would be good… at least then it does not have to do a separate rule per interface as with iptables -i and -o
In RouterOS you can select “all ethernet”, “all vlan”, “all ppp” which I think maps to “eth+”, “vlan+” and “ppp+”
in the -i and -o spec, but there is no “all gre”, “all ipip” etc which would map to “gre+” and “tunl+”.
So, the workaround is to put all ipip tunnels in an interface list and use that.
However, in this application there are >400 ipip tunnel interfaces.
(that would not be required when multipoint tunnel interfaces were allowed in RouterOS as they are in Linux,
but that is another topic)
I just created that 394 address IPIP interface list and placed 5 drop rules in my firewall using the list.
I can not see any significant performance degradation or higher processor load on my CCR 1009.
Maybe a slower router could show more…
Very good, Marius! Thanks for implementing that!
Of course a CCR1009 is barely affected by anything, I have never seen our CCR go above 1% CPU, sometimes
I even wonder if there may be a bug in the CPU indication on the CCR
I see if I can setup some test.