Best Practices for Defining Policies on High-End SRX Series Devices

A secure network is vital to a business. To secure a network, a network administrator must create a security policy that outlines all of the network resources within that business and the required security level for those resources. The security policy applies the security rules to the transit traffic within a context (from-zone to to-zone) and each policy is uniquely identified by its name. The traffic is classified by matching the source and destination zones, the source and destination addresses, and the application that the traffic carries in its protocol headers with the policy database in the data plane.

Juniper SRX1400, SRX3400, SRX3600, SRX5600, and SRX5800 Services Gateway devices support up to 1024 source address objects, 1024 destination address objects, and 128 application objects. These objects can be used in either a single policy rule or multiple policy definitions. SRX1400 devices allow you to define a maximum of 10,000 policy rules, SRX3400 and SRX3600 devices allow 40,000, and SRX5600 and SRX5800 devices allow a maximum of 80,000 policy rules. However, you can have up to 1024 source or destination address objects and 128 application objects, regardless of the number of policies defined.


Therefore, as you increase the number of addresses and applications in each rule, the amount of memory that is used by the policy definition increases, and sometimes the system runs out of memory with fewer than 80,000 policies.

To get the actual memory utilization of a policy on the Packet Forwarding Engine (PFE) and the Routing Engine (RE), you need to take various components of the memory tree into consideration. The memory tree includes the following two components:

  • Policy context–Used to organize all policies in this context. Policy context includes variables such as source and destination zones
  • Policy entity–Used to hold the policy data. Policy entity calculates memory using parameters such as policy name, IP addresses, address count, applications, firewall authentication, WebAuth, IPsec, count, application services, and Junos Services Framework (JSF)

Additionally, the data structures used to store policies, rule sets, and other components use different memory on the Packet Forwarding Engine and on the Routing Engine. For example, address names for each address in the policy are stored on the Routing Engine, but no memory is allocated at the Packet Forwarding Engine level. Similarly, port ranges are expanded to prefix and mask pairs and are stored on the Packet Forwarding Engine, but no such memory is allocated on the Routing Engine.

Accordingly, depending on the policy configuration, the policy contributors to the Routing Engine are different from those to the Packet Forwarding Engine, and memory is allocated dynamically.

Memory is also consumed by the “deferred delete” state. In the deferred delete state, when an SRX Series device applies a policy change, there is transitory peak usage whereby both the old and new policies are present. So for a brief period, both old and new policies exist on the Packet Forwarding Engine, taking up twice the memory requirements.

Therefore, there is no definitive way to infer clearly how much memory is used by either component (Packet Forwarding Engine or Routing Engine) at any given point in time, because memory requirements are dependent on specific configurations of policies, and memory is allocated dynamically.

The following best practices for policy implementation enable you to better use system memory and to optimize policy configuration:

  • Use single prefixes for source and destination addresses. For example, instead of using /32 addresses and adding each address separately, use a large subnet that covers most of the IP addresses you require.
  • Use application “any” whenever possible. Each time you define an individual application in the policy, you can use an additional 52 bytes.
  • Use fewer IPv6 addresses because IPv6 addresses consume more memory.
  • Use fewer zone pairs in policy configurations. Each source or destination zone uses about 16,048 bytes of memory.
  • The following parameters can change how memory is consumed by the bytes as specified:
    • Firewall authentication–About 16 bytes or more (unfixed)
    • Web authentication–About 16 bytes or more (unfixed)
    • IPsec–12 bytes
    • Application services–28 bytes
    • Count–64 bytes
  • Use global policies because they decrease overall memory usage in terms of source and destination prefixes and applications used.
  • Check memory utilization before and after compiling policies.

We recommend using global policies whenever possible. Global policies provide you with the flexibility to perform actions on traffic without the restrictions of zone specifications.

The memory requirement for each device is different. Some devices support 512,000 sessions by default and the bootup memory is usually at 72 to 73 percent. Other devices can have up to 1 million sessions and the bootup memory can be up to 83 to 84 percent. In the worst-case scenario, to support about 80,000 policies in the SPU, the SPU should boot with a flowd kernel memory consumption of up to 82 percent, and with at least 170 megabytes of memory available.