How to mitigate shared memory pool allocation failures
924
Created On 07/02/25 16:44 PM - Last Modified 07/02/25 18:57 PM
Objective
- Mitigate shared memory pool allocation failures: Fail-Thresh & Fail-nomem found in the output of the command "show dataplane pool statistics".
Environment
- Dataplane
- Shared Memory Pool Users
Procedure
- Check the name of the dataplane function or shared memory pool user experiencing memory allocation failures to identify the associated feature. Use the following name pattern as a guide:
- Names starting with appid relate to application identification.
- Names starting with ctd relate to the Content-Driven Threat engine.
- Names starting with proxy, ssl or prl, relate to decryption.
- Names starting with http2, relate to HTTP/2 inspection.
- Names starting with wif, relate to stripping data from traffic and forwarding to SLS(Strata Logging Service)'s enhanced application logging(EAL).
- Names starting with sml, relate to State Machine Language used in the CTD inspection.
- Names starting with uappid, relate to the Unique Application ID(identification) within the Application Identification Cloud Engine (ACE).
- Names starting with cad, relate to cloud application identification.
- Names such as appinfo and parent_info, relate to the predict session and child sessions common with protocols like VoIP (SIP), which establish a control session and then open separate child sessions for the actual media streams (e.g., RTP, RTCP).
- Names containing hs, indicate handshake-related functions.
- Names containing openssl refer to the use of OpenSSL for handling TLS 1.3 connections, with the dataplane allocating dynamic memory from a proxy pool.
- Names containing decode indicate decode filters, which handle decoding of various formats like Base64, ZIP (Deflate), UTF-16/32, BDAT chunks, etc.
- Names containing l7 refer to Layer 7 inspection.
- General Mitigation Recommendation: Where possible, reduce the traffic rate being inspected by the firewall to lower memory usage.
- Feature-Specific Mitigation Steps:
- For application identification-related functions, consider using application override to exclude applications suspected of high memory usage from the application ID process. Be aware that this means that this application traffic would bypass content inspection.
When applicable and in case of traffic sent to a trusted server, consider enabling DSRI “Disable Server Response Inspection". Be aware that this will disable the layer 7 inspection on the server-to-client direction of the traffic flow. - For ctd-related functions, consider implementing a security policy rule with a minimal security profile for trusted traffic that does not require Layer 7 inspection. This can be done by inserting a security policy rule on top of the existing one, with fewer or no security profiles enabled in the Actions tab.
- For decryption-related functions, identify the traffic that requires decryption and apply a decryption policy rule specific to that traffic. For traffic that should be excluded from decryption, create a corresponding decryption exclusion rule.
- For HTTP/2-related functions, consider disabling HTTP/2 inspection by enabling Strip ALPN.
- For application identification-related functions, consider using application override to exclude applications suspected of high memory usage from the application ID process. Be aware that this means that this application traffic would bypass content inspection.
- If the memory allocation failure issue persists despite these measures, open a support case for further investigation.