This article provides guidance to customers with lower end ION Platform (ION1000, ION2000, ION1200) for memory management considerations prior to upgrading ION software.
1. Introduction: Understanding Memory Considerations for ION Platforms
Lower end ION Platforms (ION1000, ION2000, ION1200) which are running ION Element SW series 5.x and currently using >80% of memory are at risk of experiencing unexpected reboots due to out-of-memory (OOM) errors. The risk increases after upgrading from 5.6.x to 6.x due to overall software architecture difference between the release series. Prior to making any upgrade, it is important to ensure that an assessment of available system memory is considered. Memory exhaustion can occur in environments where customers have custom application definitions with a large prefix list, and or security policy rules with similarly large prefixes. The compilation process is memory-intensive and can lead to out of memory issues with large or complex policies. An Upgrade advisory has been added to our release notes in the upgrade considerations page.
2. Proactive Configuration Best Practices for Memory Optimization
Implementing the below practices can help reduce memory exhaustion conditions and improve device stability on lower end ION Platforms
a. General Guidelines
- Removing Custom Applications: Sanitize and trim the custom applications which are not in use, this can increase system available memory.
- Regrouping the prefix which can accommodate in the larger subnet
- Remove unused prefix sets
- Review any custom apps that are configured as scan apps and ensure affinity is set to "None"
- Prior to making changes to prefix filters or custom applications assess the current memory utilization to determine risk.
- Make changes during a maintenance window / off hours when usage should be lower. There is the possibility of a reboot while implementing some of the changes below
- Consider moving a high number of global prefixes to local prefixes
b. Specific considerations for managing Prefix lists and Custom Application Design
Prefix List Management:
- Avoid full port ranges: Do not add a full port range (1 to 65535) for custom applications which are not scan apps
- Minimize /32 prefixes: Avoid adding too many /32 prefixes to existing custom applications, especially those that already use a full port range.
- Group local prefixes: It is better to group local prefixes within an associated security policy and update them in a single operation.
- Optimize prefix list updates: Design prefix list updates to be optimized for either their size or frequency to better handle scenarios where available memory is low.
Custom Application Design
- Set path_affinity: If strict affinity is not required, set path_affinity=none as the default value.
- Set app_unreachability: If application unreachability is not required, set app_unreachability=false as the default value.
- Use only needed ports for custom apps: When defining custom applications, specify only the necessary ports rather than using full port ranges (1 to 65535). This approach can reduce the memory footprint and maintain application visibility. However, identifying the exact ports used can be challenging, requiring an understanding of the application's purpose and usage, and may necessitate freezing port ranges to current configurations.
c. Important Considerations and Potential Impacts
- Application Visibility: Moving to a security policy with a local prefix (without AppDef) will result in limited application-specific visibility. For example, in "flow browser," you will only be able to view flows by source IP rather than by AppDef. Application health visibility will be lost until the AppDef is recreated and added back into the policy.
- Traffic Steering and Dropping: Without AppDef, you will not be able to steer custom application traffic. If someone unintentionally adds a security rule above this with DENY for these prefixes but with other applications, the custom application traffic would be dropped.
