SRX 3400 and SRX 3600 Services Gateways Overview

JUNOS software for the SRX 3400 and SRX 3600 services gateways integrates the world-class network security and routing capabilities of Juniper networks. JUNOS software for these service gateways includes the wide range of security services including policies, screens, NAT, class-of-service classifiers, and the rich, extensive set of flow-based services that are also supported on the other devices in the SRX-series services gateways

The distributed parallel processing architecture of the SRX 3400 and SRX 3600 services gateways includes multiple processors to manage sessions and run security and other services processing. This architecture provides greater flexibility and allows for high throughput and fast performance.

Here is an overview of the main components involved in setting up a session for a packet and processing the packets as they transit the SRX 3400 and SRX 3600 services gateways:

The SPU maintains a session table with entries for all sessions that it established and whose packets it processes. When an SPU receives a packet from an NPU, it checks its session table to ensure that the packet belongs to it.

For SRX 3400 and SRX 3600 services gateways, one SPU acts in concert performing its regular session management and flow processing functions and acting as a central point in which it arbitrates sessions and allocates resources. When an SPU performs in this manner it is said to be in combo mode.

For the SRX 3400 and SRX 3600, one SPU always runs in what is referred to as combo-mode in which it implements both the functionality of the central point and the flow and session management functionality. In combo-mode, the SPU and the central point share the same load-balancing thread (LBT) and packet-ordering thread (POT) infrastructure. For more information, see Central Point and Combo-Mode Support.

The central point maintains a global session table with information about the owner SPU of a particular session. It functions as a central repository and resource manager for the whole system.

Central Point and Combo-Mode Support

The central point (CP) in the architecture has two basic flow functionalities: load balancing and traffic identification (global session matching). The central point forwards a packet to its Services Processing Unit (SPU) upon session matching, or distributes traffic to an SPU for security processing if the packet does not match any existing session.

An SPU dedicated to central point functionality is called a large central point. However, when such a dedicated SPU is not affordable, you can configure the SPU to perform normal flow processing as well as the functions of the central point. When an SPU functions in such a dual manner, it is said to be in combination or combo mode. In combo mode, the central point and SPU share the same load-balancing thread (LBT) and packet-ordering thread (POT) infrastructure. SRX 3400 and SRX 3600 devices always support combo-mode.

Load Distribution in Combo Mode

The central point maintains SPU mapping table (for load distribution) that lists live SPUs with the logic SPU IDs mapped to the physical Trivial Network Protocol (TNP) addresses mapping. In combo mode, the SPU that hosts the central point is included in the table. The load distribution algorithm is adjusted based on session capacity and processing power to avoid overloading of sessions.

Sharing Processing Power and Memory in Combo Mode

The CPU processing power in a combo-mode SPU is shared based on the platform and the number of SPUs in the system. Similarly, the CPU memory is also shared between the central point and SPU.

An SPU has multiple cores (CPUs) for networking processing. In "small" SPU combo mode, CPU functionality takes a small portion of the cores, whereas "medium" SPU combo-mode requires a larger portion of cores. The processing power for central point functionalities and flow processing is shared, based on the number of SPUs, as shown in Table 1.

Table 54: Combo Mode Processing:

Following the Data Path for a Unicast Session

JUNOS software for the SRX 3400 and SRX 3600 services gateways is a distributed parallel processing high throughput and high performance system. This section describes the process that the services gateway undertakes in establishing a session for packets belonging to a flow that transits the device.

To illustrate session establishment and the packet “walk” including the points at which services are applied to the packets of a flow, this example uses the simple case of a unicast session.

This packet “walk” brings together the packet-based processing and flow-based processing that the JUNOS software performs on the packet.

Session Lookup and Packet Match Criteria

To determine if a packet belongs to an existing flow, the services gateway attempts to match the packet’s information to that of an existing session based on the following six match criteria:

• Source address
• Destination address
• Source port
• Destination port
• Protocol
• Unique token from a given zone and virtual router

Understanding Session Creation: First Packet Processing

This section explains how a session is set up to process the packets composing a flow. To illustrate the process, this section uses an example with a source “a” and a destination “b”. The direction from source to destination for the packets of the flow is referred to as (a -> b). The direction from destination to source is referred to as (b -> a).

1. A Packet Arrives at an interface on the device and the IOC processes it.

   The IOC dequeues the packet and sends it to the NPU with which it communicates.

2. The NPU receives the packet from the IOC and processes it.
   1. The NPU performs basic sanity checks on the packet and applies some screens configured for the interface to the packet.
   2. If a session match is found, the session has already been created on an SPU that was assigned to it, so the NPU forwards the packet to the SPU for processing along with the session ID.

   Example: Packet (a ->b) arrives at NPU1 from IOC1. NPU1 performs sanity checks and applies DoS screens to the packet. NPU1 checks its session table for a tuple match and no existing session is found. NPU1 forwards the packet to the central point on SPU1 for assignment to an SPU.

3. The Central Point (CP) Creates a Session with a “Pending” State.

   The central point maintains a global session table that includes entries for all sessions that exist across all SPUs on the device. It participates in session creation and delegates and arbitrates session resources allocation.

   This process entails the following parts:

   1. The central point checks its session table and gate table to determine if a session or a gate exists for the packet it receives from the NPU. (An NPU has forwarded a packet to the central point because its table indicates there is no session for it. The central point verifies this information before allocating an SPU for the session.)
   2. If there is no entry that matches the packet in either table, the central point creates a pending wing for the session and selects an SPU to be used for the session, based on its load-balancing algorithm.
   3. The central point forwards the first packet of the flow to the selected SPU in a message telling it to set up a session locally to be used for the packet flow.

   Example: The central point creates pending wing (a ->b) for the session. It selects SPU1 to be used for the session. It sends SPU1 the (a->b) packet along with a message to create a session for it. (It happens to be the case that SPU1 is the SPU that runs in combo mode. Therefore, its session-management and flow-processing services are used for the session.)

4. The SPU Sets Up the Session.

   Each SPU, too, has a session table, which contains information about its sessions. When the SPU receives a message from the central point to set up a session, it checks its session table to ensure that a session does not already exist for the packet.

   1. If there is no existing session for the packet, the SPU sets up the session locally.
   2. The SPU sends a message to the central point, telling it to install the session.

   During first-packet processing, if NAT is enabled, the SPU allocates IP address resources for NAT. In this case, the first-packet processing for the session is suspended until the NAT allocation process is completed.

   The SPU adds to the queue any additional packets for the flow that it might receive until the session has been installed.

   Example: SPU1 creates the session for (a ->b) and sends a message back to the central point (implemented on the same SPU) telling it to install the pending session.

5. The Central Point Installs the Session.

   The central point receives the install message from the SPU.

   1. It sets the state for the session’s pending wing to active.
   2. It installs the reverse wing for the session as an active wing.
   3. It sends an ACK (acknowledge) message to the SPU, indicating that the session is installed.

   Example: The central point receives a message from SPU1 to install the session for (a->b). It sets the session state for (a->b) wing to active. It installs the reverse wing (b->a) for the session and makes it active; this allows for delivery of packets from the reverse direction of the flow: destination (b) to be delivered to the source (a).

6. The SPU Sets Up the Session on the Ingress and Egress NPUs.

   NPUs maintain information about a session for packet forwarding and delivery. Session information is set up on the egress and ingress NPUs (which sometimes are the same) so that packets can be sent directly to the SPU that manages their flows and not to the central point for redirection.

7. Fast-Path Processing Takes Place.

   For the remainder of the steps entailed in packet processing, proceed to Step 1 in “Understanding Fast-Path Processing”.

Understanding Fast-Path Processing

All packets undergo fast path-processing. However, if a session exists for a packet, the packet undergoes fast-path processing and bypasses the first-packet process. When there is already a session for the packet’s flow, the packet does not transit the central point.

Here is how fast-path processing works: NPUs at the egress and ingress interfaces contain session tables that include the identification of the SPU that manages a packet’s flow. Because the NPUs have this session information, all traffic for the flow, including reverse traffic, is sent directly to that SPU for processing.