Custom Snort 3 Intrusion Policies for Access Control

Packet and intrusion rule latency threshold configuration

Updated: February 4, 2026

Want to summarize with AI?

Describes latency-based settings that use thresholding to manage packet and rule processing performance in access control policies.

Packet and intrusion rule latency threshold configuration is a performance management mechanism that

uses thresholding to manage packet and rule processing performance in access control policies,
measures elapsed time for packet and rule processing operations, and
implements protective actions when configurable time thresholds are exceeded.

Processing mechanisms

This configuration includes two distinct processing mechanisms:

Packet latency thresholding: Measures the total elapsed time taken to process a packet by applicable decoders, preprocessors, and rules, and ceases inspection of the packet if the processing time exceeds a configurable threshold.
Rule latency thresholding: Measures the elapsed time each rule takes to process an individual packet, suspends the violating rule along with a group of related rules for a specified time if the processing time exceeds the rule latency threshold a configurable consecutive number of times, and restores the rules when the suspension expires.

Note

Snort 2 is not supported on Threat Defense version 7.7. For information on Snort 2 features that are supported in versions earlier than 7.7, refer to the Firewall Management Center guide that matches your Firewall Threat Defense version.

Latency-based performance settings

Latency-based performance settings are a system configuration mechanism that

takes performance settings from the latest intrusion rule update deployed on the system,
applies settings based on the security level of the network analysis policy (NAP) associated with the access control policy, and
evaluates the most secure network analysis policy among custom rules when multiple policies are configured.

Policy evaluation logic

The latency settings that are actually applied depend on the security level of the network analysis policy (NAP) associated with the access control policy. Generally, this is the default NAP policy. However, if custom network analysis rules are configured, and if any of these specify a NAP policy that is more secure than the default NAP policy, then latency settings are based on the most secure NAP policy among the custom rules. If the default NAP policy or any custom rules invoke a custom NAP policy, then the security level used in the evaluation is the system-provided base policy on which each custom NAP policy is based.

This policy evaluation logic applies regardless of whether the effective threshold and network analysis configurations are inherited or configured directly in the policy.

Packet latency thresholding

Packet latency thresholding is a software-based latency implementation that

measures elapsed time, not just processing time, to more accurately reflect the actual time required for the rule to process a packet,
does not enforce strict timing, and
can improve system performance by stopping inspection of packets that require excessive processing time.

Packet latency thresholding operation

A timer starts for each packet when decoder processing begins. Timing continues either until all processing ends for the packet or until the processing time exceeds the threshold at a timing test point.

The trade-off for the performance and latency benefits derived from latency thresholding is that uninspected packets could contain attacks.

Packet latency timing is tested at these test points:

after the completion of all decoder and preprocessor processing and before rule processing begins
after processing by each rule

If the processing time exceeds the threshold at any test point, packet inspection ceases.

Tip

Total packet processing time does not include routine TCP stream or IP fragment reassembly times.

Packet latency thresholding has no effect on events triggered by a decoder, preprocessor, or rule processing the packet. Any applicable decoder, preprocessor, or rule triggers normally until a packet is fully processed, or until packet processing ends because the latency threshold is exceeded, whichever comes first. If a drop rule detects an intrusion in an inline deployment, the drop rule triggers an event and the packet is dropped.

Note

No packets are evaluated against rules after processing for that packet ceases because of a packet latency threshold violation. A rule that would have triggered an event cannot trigger that event, and for drop rules, cannot drop the packet.

Packet latency thresholding can improve system performance in both passive and inline deployments, and can reduce latency in inline deployments, by stopping inspection of packets that require excessive processing time. These performance benefits might occur when, for example:

for both passive and inline deployments, sequential inspection of a packet by multiple rules requires an excessive amount of time
for inline deployments, a period of poor network performance, such as when someone downloads an extremely large file, slows packet processing

In a passive deployment, stopping the processing of packets might not contribute to restoring network performance because processing simply moves to the next packet.

Packet latency thresholding notes

By default, the latency-based performance settings for packet handling are disabled. You may choose to enable it. However, Cisco recommends that you do not change the default value for the threshold setting. The information in this section applies only if you choose to specify custom values.

Enable packet latency thresholding

Enable packet latency thresholding to monitor and manage packet processing delays, which helps optimize network performance and identify potential bottlenecks.

Packet latency thresholding allows you to set performance parameters for packet processing. This feature is useful for monitoring network performance and ensuring optimal packet flow through the system.

Procedure

	1.	In the access control policy editor, click Advanced. In the new UI, select Advanced Settings from the drop-down arrow at the end of the packet flow line.
	2.	Click Edit () next to Latency-Based Performance Settings. If View () appears instead, settings are inherited from an ancestor policy, or you do not have permission to modify the settings.
	3.	Click Packet Handling in the Latency-Based Performance Settings pop-up window.
	4.	Check the Enabled check box.
	5.	Click OK.
	6.	Click Save to save the policy.

What to do next

Deploy configuration changes.

Configure packet latency thresholding

This task enables you to configure packet latency thresholding for latency-based performance settings.

By default, the latency-based performance settings for packet handling is disabled. You may choose to enable it. However, Cisco recommends that you do not change the default value for the threshold setting.

Procedure

	1.	In the access control policy editor, click Advanced. In the new UI, select Advanced Settings from the drop-down arrow at the end of the packet flow line.
	2.	Click Edit () next to Latency-Based Performance Settings. System () > Monitoring > Statistics
	3.	If the configuration is unlocked, uncheck Inherit from base policy to enable editing.
	4.	Click Packet Handling in the Latency-Based Performance Settings pop-up window. By default, Installed Rule Update is selected. We recommend using this default. The values displayed do not reflect the automated settings.
	5.	If you choose to specify custom values: Check the Enabled check box, and see Packet latency thresholding notes for recommended minimum Threshold settings. You must specify custom values in both the packet handling tab and the rule handling tab.
	6.	Click OK.
	7.	Click Save to save the policy.

What to do next

Deploy configuration changes.

Rule latency thresholding

Rule latency thresholding is a software-based latency implementation that

measures elapsed time, not just processing time, to more accurately reflect the actual time required for the rule to process a packet,
does not enforce strict timing, and
temporarily suspends rules that exceed specified processing time thresholds to improve system performance.

Rule latency thresholding operations

A timer measures the processing time each time a packet is processed against a group of rules. Any time the rule processing time exceeds a specified rule latency threshold, the system increments a counter. If the number of consecutive threshold violations reaches a specified number, the system takes these actions:

suspends the rules for the specified period
triggers an event indicating the rules have been suspended
re-enables the rules when the suspension expires
triggers an event indicating the rules have been re-enabled

The system zeroes the counter when the group of rules has been suspended, or when rule violations are not consecutive. Permitting some consecutive violations before suspending rules lets you ignore occasional rule violations that might have negligible impact on performance and focus instead on the more significant impact of rules that repeatedly exceed the rule latency threshold.

The trade-off for the performance and latency benefits derived from latency thresholding is that uninspected packets could contain attacks.

Rule latency thresholding has no effect on intrusion events triggered by the rules processing the packet. A rule triggers an event for any intrusion detected in the packet, regardless of whether the rule processing time exceeds the threshold. If the rule detecting the intrusion is a drop rule in an inline deployment, the packet is dropped. When a drop rule detects an intrusion in a packet that results in the rule being suspended, the drop rule triggers an intrusion event, the packet is dropped, and that rule and all related rules are suspended.

Note

Packets are not evaluated against suspended rules. A suspended rule that would have triggered an event cannot trigger that event and, for drop rules, cannot drop the packet.

Rule latency thresholding can improve system performance in both passive and inline deployments, and can reduce latency in inline deployments, by suspending rules that take the most time to process packets. Packets are not evaluated again against suspended rules until a configurable time expires, giving the overloaded device time to recover. These performance benefits might occur when:

hastily written, largely untested rules require an excessive amount of processing time
a period of poor network performance, such as when someone downloads an extremely large file, causes slow packet inspection

Rule latency thresholding examples

This example shows five consecutive rule processing times that do not result in rule suspension.

Example diagram

In this example, the time required to process each of the first three packets violates the rule latency threshold of 1000 microseconds, and the violations counter increments with each violation. Processing of the fourth packet does not violate the threshold, and the violations counter resets to zero. The fifth packet violates the threshold and the violations counter restarts at one.

This example shows five consecutive rule processing times that do result in rule suspension.

Example diagram

In the second example, the time required to process each of the five packets violates the rule latency threshold of 1000 microseconds. The group of rules is suspended because the rule processing time of 1100 microseconds for each packet violates the threshold of 1000 microseconds for the specified five consecutive violations. Any subsequent packets, represented in the figure as packets 6 through n, are not examined against suspended rules until the suspension expires. If more packets occur after the rules are re-enabled, the violations counter begins again at zero.

Rule latency thresholding notes

Rule latency thresholding suspends rules for the time specified by Suspension Time when the time rules take to process a packet exceeds Threshold for the consecutive number of times specified by Consecutive Threshold Violations Before Suspending Rule.

By default, latency-based performance settings for both packet and rule handling are automatically populated by the latest deployed intrusion rule update, and we recommend that you do not change the default.

The information in this topic applies only if you choose to specify custom values.

You can enable rule 134:1 to generate an event when rules are suspended, and rule 134:2 to generate an event when suspended rules are enabled.

Table 1. Rule latency thresholding options
Option	Description
Threshold	Specifies the time in microseconds that rules should not exceed when examining a packet.
Consecutive Threshold Violations Before Suspending Rule	Specifies the consecutive number of times rules can take longer than the time set for Threshold to inspect packets before rules are suspended.
Suspension Time	Specifies the number of seconds to suspend a group of rules.

Configure rule latency thresholding

Configure rule latency thresholding to customize how the system handles rules when latency conditions are detected, improving overall performance and system responsiveness.

Procedure

	1.	In the access control policy editor, click Advanced. In the new UI, select Advanced Settings from the drop-down arrow at the end of the packet flow line.
	2.	Click Edit () next to Latency-Based Performance Settings. If View () appears instead, settings are inherited from an ancestor policy, or you do not have permission to modify the settings. If the configuration is unlocked, uncheck Inherit from base policy to enable editing.
	3.	Click Rule Handling in the Latency-Based Performance Settings pop-up window. By default, Installed Rule Update is selected. We recommend using this default. The values displayed do not reflect the automated settings.
	4.	If you choose to specify custom values: You can configure any of the options in Rule latency thresholding notes. You must specify custom values in both the packet handling tab and the rule handling tab.
	5.	Click OK.
	6.	Click Save to save the policy.

What to do next

If you want to generate events, enable latency rules 134:1 and 134:2.
Deploy configuration changes.

Need help?

Open a support case

(Requires a Cisco Service Contract)

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.