Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
ContentIndex
  
[+] Expand All
[-] Collapse All

No index entries found.

Related Documentation

  • Security Policies Overview
  • Understanding Security Policy Rules
  • Understanding Global Address Books
  • Global Policy Overview
  • Example: Configuring a Global Policy with No Zone Restrictions
  • Checking Memory Status

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.

Table 12 provides the policy limitations for high-end SRX Series devices.

Table 12: Policy Limitations for High-End SRX Series Devices

Policy Limitations

SRX1400

SRX3400
SRX3600

SRX5400
SRX5600
SRX5800

Address objects

1024

4096

4096

Application objects

3072

3072

3072

Security policies

40,000

40,000

80,000

Policy contexts (zone pairs)

4096

4096

8192

Policies per context

10240

40,000

80,000

Policies with counting enabled

1024

1024

1024

Note: The number of source and destination address objects allowed per firewall policy is 4096. The systemwide maximum allowed is 150,000 address objects.

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
  • Check memory utilization before and after compiling policies.

    Note: 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.

Related Documentation

  • Security Policies Overview
  • Understanding Security Policy Rules
  • Understanding Global Address Books
  • Global Policy Overview
  • Example: Configuring a Global Policy with No Zone Restrictions
  • Checking Memory Status

Modified: 2016-05-01