[Oisf-users] Multi-tenancy, memory requirements, performance?

Victor Julien lists at inliniac.net
Wed Mar 29 12:59:04 UTC 2017

On 24-03-17 23:18, Alan Amesbury wrote:
> What's the effect of Suricata's multi-tenancy on memory footprint?  We're looking at running with multi-tenancy so we can set HOME_NETS to various values for different VLANs.  So, for example, if I have 25k rules that I want to run with 50 different tenancy configurations, what's the impact on memory use?  I don't know the internal details of Suricata's rule expansion, but it seems to me one way that it might happen is those rules with common variables across different tenancy configurations will have a footprint expand in line with the number of those configurations.  Note that I'm talking about using Suricata in live capture mode; my understanding is VLANs are the only selector available in that mode.

In the current implementation, each tenant is a unique detection engine
w/o much (if any) sharing with other tenants. So if once tenant takes
1GiB you can assume that adding another with just slight config changes
will use another 1GiB, etc.

It would be nice to share more. Tricky part of it is that tenants can be
loaded and unloaded dynamically at runtime, so thread safety during
sharing would be quite tricky. Not impossible of course.

> I'm looking specifically at Suricata v3.2.1 with Hyperscan.  I don't have a clear understanding of packet path through Suricata, but would guess that the IP/port logic portion would be done first as that seems like pretty straightforward bitwise math.  If Suricata (Hyperscan?) builds the rulesets in such a way that basic packet logic and payload inspection (e.g., the Hyperscan portion) are decoupled, it seems like memory usage might not increase all that much if Suricata is able to detect functional duplicate rules between differing tenancy configs (same rule, differing values for HOME_NET and such)... but I'm totally shooting in the dark, and that's why I'm hoping to find out more here.  I did look at the source, but source code and I aren't really on speaking terms.  ;-)

The MPM algo (ac/hs/etc) does not affect the rule grouping. In 3.2 rules
are grouped based on: ipver, ipproto, direction (toserver/toclient),

> Searches of http://suricata.readthedocs.io turned up little on multi-tenancy, and nothing on what impact multi-tenancy has on memory usage.  I did a little Google searching as well, but didn't turn up anything else that looked relevant to multi-tenancy and memory usage.  Anyway, if nothing else, pointers in the right direction would be greatly appreciated.  Thanks in advance for any insights you can provide!

Yeah, we need to write up more about it. If you're willing to help it
would be much appreciated.

Victor Julien
PGP: http://www.inliniac.net/victorjulien.asc

More information about the Oisf-users mailing list