JUNOS software for SRX-series services gateways is a distributed parallel processing high throughput and high performance system. The distributed parallel processing architecture of the SRX-series 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.
The SRX 5600 and SRX 5800 services gateways include I/O cards (IOC) and Services Processing Cards (SPCs) that each contain processing units that process a packet as it traverses the device. A Network Processing Unit (NPU) runs on an IOC. An IOC has one or more NPUs. One or more Services Processing Units (SPUs) run on an SPC.
These processing units have different responsibilities. All flow-based services for a packet are executed on a single SPU. Otherwise, however, the lines are not clearly divided in regard to the kinds of services that run on these processors. (For details on flow-based processing, see Understanding Flow-Based Processing.) For example:
These discrete, cooperating parts of the system, including the central point, each store the information identifying whether a session exists for a stream of packets and the information against which a packet is matched to determine if it belongs to an existing session.
This architecture allows the device to distribute processing of all sessions across multiple SPUs. It also allows an NPU to determine if a session exists for a packet, to check the packet, and to apply screens to it. How a packet is handled depends on whether it is the first packet of a flow.
If the packet matches an existing flow, processing for the packet is assessed in the context of its flow state. The SPU maintains the state for each session, and the settings are then applied to the rest of the packets in the flow. If the packet does not match an existing flow, it is used to create a flow state and a session is allocated for it.
Figure 5 illustrates the path the first packet of a flow takes as it enters the device: the NPU determines that no session exists for the packet, and the NPU sends the packet to the central point; the central point selects the SPU to set up the session for the packet and process it, and it sends the packet to that SPU. The SPU processes the packet and sends it to the NPU for transmission from the device. (This high-level description does not address application of features to a packet.)
Figure 5: First-Packet Processing
For details on session creation for the first packet in a flow, see Understanding Session Creation: First-Packet Processing.
After the first packet of a flow has traversed the system and a session has been established for it, it undergoes fast-path processing.
Subsequent packets of the flow also undergo fast-path processing; in this case, after each packet enters the session and the NPU finds a match for it in its session table, the NPU forwards the packet to the SPU that manages its session.
Figure 6 illustrates fast-path processing. This is the path a packet takes when a flow has already been established for its related packets. (It is also the path that the first packet of a flow takes after the session for the flow that the packet initiated has been set up.) After the packet enters the device, the NPU finds a match for the packet in its session table, and it forwards the packet to the SPU that manages the packet’s session. Note that the packet bypasses interaction with the central point.
Figure 6: Fast-Path Processing
This section explains how a session is created and the process a packet undergoes as it transits the services gateway.
Here is an overview of the main components involved in setting up a session for a packet and processing the packets both discretely and as part of a flow as they transit the SRX 5600 and SRX 5800 services gateways:
The NPU session table contains an entry for a session if the session is established on an SPU for a packet that had previously entered the device via the interface and was processed by this NPU. The SPU installs the session in the NPU table when it creates the session.
An NPU determines if a session exists for a packet by checking the packet information against its session table. If the packet matches an existing session, the NPU sends the packet and the metadata for it to the SPU. If there is no session, the NPU sends the packet to the central point for SPU assignment.
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. It also checks its session table when it receives a packet from the central point (CP) and a message to establish a session for that packet to verify that there is not an existing session for the packet.
The central point’s main function is to delegate session processing to one of the SPUs. If the session has not yet been established, the central point selects an SPU to establish the session for the flow, based on load- balancing criteria. If the session already exists, the central point forwards packets for that flow to the SPU hosting it. It also redirects packets to the correct SPU in the event that the NPU fails to do so.
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.
This section describes the process that the services gateway undertakes in establishing a session for packets belonging to a flow that transits the SRX-series services gateways.
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. It includes the following sections:
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:
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).
Step 1. A Packet Arrives at an Interface on the Device and the NPU Processes It.
This section describes how a packet is handled when it arrives at a services gateway ingress IOC.
Example: Packet (a ->b) arrives at NPU1. NPU1 performs sanity checks and applies DoS screens to the packet. NPU checks its session table for a tuple match and no existing session is found. NPU1 forwards the packet to the central point for assignment to an SPU.
Step 2. 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:
Example: The central point creates pending wing (a ->b) for the session. It selects SPU1 to be used for it. It sends SPU1 the (a->b) packet along with a message to create a session for it.
Step 3. 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.
 |
Note: 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 telling it to install the pending session.
Step 4. The Central Point Installs the Session.
The central point receives the install message from the SPU.
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).
Step 5. 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.
Step 6. Fast-Path Processing Takes Place.
For the remainder of the steps entailed in packet processing, proceed to Step 1 in Understanding Fast-Path Processing.
Figure 7 illustrates the first part of the process the first packet of a flow undergoes after it reaches the services gateway. At this point a session is set up to process the packet and the rest of the packets belonging to its flow. Subsequently, it and the rest of the packets of flow undergo fast-path processing.
Figure 7: Session Creation: First-Packet 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.
To illustrate the fast-path 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).
This section describes how a packet is handled when it arrives at a services gateway’s IOC.
The NPU performs sanity checks and applies some screens, such as denial-of-service (DoS) screens, to the packet.
Example: Packet (a ->b) arrives at NPU1. NPU1 performs sanity checks on the packet, applies DoS screens to it, and checks its session table for a tuple match. It finds a match and that a session exists for the packet on SPU1. NPU1 forwards the packet to SPU1 for processing.
Most of a packet’s processing occurs on the SPU to which its session is assigned. The packet is processed for packet-based features such as stateless firewall filters, traffic shapers, and classifiers, if applicable. Configured flow-based security and related services such as firewall features, NAT, ALGs, and so forth, are applied to the packet. (For information on how security services are determined for a session, see Zones and Policies.)
Example: SPU1 receives packet (a->b) from NPU1. It checks its session table to verify that the packet belongs to one of its sessions. Then it processes packet (a ->b) according to input filters and CoS features that apply to its input interface. The SPU applies the security features and services that are configured for the packet’s flow to it, based on its zone and policies. If any are configured, it applies output filters, traffic shapers and additional screens to the packet.
Example: SPU1 forwards packet (a ->b) to NPU2, and NPU2 applies DoS screens.
Example: The interface transmits packet (a->b) from the device.
This step mirrors Step 1 exactly in reverse. See Step 1 in this section for details.
Example: Packet (b->a) arrives at NPU2. NPU2 checks its session table for a tuple match. It finds a match and that a session exists for the packet on SPU1. NPU2 forwards the packet to SPU1 for processing.
This step is the same as Step 2 except that it applies to reverse traffic. See Step 2 in this section for details.
Example: SPU1 receives packet (b->a) from NPU2. It checks its session table to verify that the packet belongs to the session identified by NPU2. Then it applies packet-based features configured for the NPU1’s interface to the packet. It processes packet (b->a) according to the security features and other services that are configured for its flow, based on its zone and policies. (See Zones and Policies.)
This step is the same as Step 3 except that it applies to reverse traffic. See Step 3 in this section for details.
Example: SPU1 forwards packet (b->a) to NPU1. NPU1 processes any screens configured for the interface.
This step is the same as Step 4 except that it applies to reverse traffic. See Step 4 in this section for details.
Example: The interface transmits packet (b->a) from the device.
Figure 8 illustrates the process a packet undergoes when it reaches the services gateway and a session exists for the flow that the packet belongs to.
Figure 8: "Packet Walk” for Fast Path Processing
