Cisco Cisco Firepower Management Center 4000

As illustrated in the above figure, packet latency timing is tested at the following 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.

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.

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.

For more information on drop rules, see 

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.

See the following sections for more information:

.