Performance impact of the MX IPS rulesets

[Dennisvw99]

I want to make a well informed decision if I want to use the Connectivity, Balanced or Security ruleset of the Threat Protection IPS of the MX. The documentation states the security rules that are attached to each mode, but it does not say how it impacts the speed or latency for traffic passing through. Of course this depends on the size of the packets, MX model and maybe other factors, but there is no estimation to be found on the internet. Has anyone an idea of the impact on performance the rulesets have in any situation?

[KarstenI]

I have not seen anything other than the MX sizing guide:

https://meraki.cisco.com/product-collateral/mx-sizing-guide

But it looks like that these values come quite close to the reality. For me, I typically operate my MXes with the security-ruleset because they are much broader than the others. Although I never found MX-specific implementation information, I would expect that it is based on the Talos base-configuration:

https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/214405-what-are-the-metrics-used-...

[Bruce]

I don’t believe the setting of the IPS, connectivity, security or balanced, has much, if any, impact on the performance of the MX. The processing of the rules is the same, it’s just which rules are included - do you want to be more permissive and potentially get less false positives (i.e. more connectivity focused), or do you want to lock down hard and stop anything suspicious, or be balanced. Obviously enabling IDS/IPS itself does have an impact as it changes the traffic flow and processing.

[Dennisvw99 · Accepted solution]

I got my answer! Steve Harrison, Senior Technical Marketing Engineer at Cisco Meraki and writer of Exploring Snort | Cisco Meraki Blog told me this:

'due to the current out of band (i.e. parallel process) nature of the Snort daemon in the MX architecture, no additional latency is added to the packets. This operating model will change in the near future though and whilst we have not finalised testing to to prove these assumptions, the parallel threaded workflow nature of v3 of the Snort daemon (used in MX16+ codes) will mean that we anticipate the additional delay to be in the realm of 10-100 microseconds and no more.'

Thank you for the replies!