Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Central Point Architecture in Security Devices Overview

The central point delegates the session processing to one of the SPUs. When a session is not 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.

Understanding SRX Series Services Gateways Central Point Architecture

The central point (CP) architecture has two basic flow functionalities: load balancing and traffic identification (global session matching). As described in this topic, the central point architecture is implemented either in centric mode, in which all session distribution and session matching is performed by the central point, or in mixed-mode, in which a percentage of Services Processing Unit (SPU) is dedicated to performing the central point functionality.

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.

Note:

The central point architecture is also implemented in CP-lite mode in which session management is offloaded from the central point to SPUs for performance and session scaling improvement. CP-lite is not discussed in this topic.

The SRX Series device type in conjunction with the Junos OS release determine which mode is supported.

Table 1 identifies the central point architecture implementation that is supported on SRX Series devices for various releases.

Table 1: Central Point Implementation on SRX Series Devices in Conjunction With Junos OS Releases
 

Mode Supported on SRX1400

Mode Supported On SRX3000 Series Devices

Mode Supported on SRX5000 Series Devices

Junos OS Release 12.3X48 and Previous Releases

  • CP centric

  • mixed-mode

  • CP centric

  • mixed-mode

  • CP centric

  • mixed-mode

  • Junos OS Release 15.1X49-D10

  • Junos OS Release 15.1X49-D15

  • Junos OS Release 15.1X49-D20

These SRX Series devices are no longer supported.

These SRX Series devices are no longer supported.

  • CP centric

Note:

NG-SPC renders combo mode obsolete.

Junos OS Release 15.1X49-D30 and later releases

These SRX Series devices are no longer supported.

These SRX Series devices are no longer supported.

  • CP-lite

Note:

NG-SPC renders mixed-mode obsolete.

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. The central point architecture is implemented in CP centric mode, in which all session distribution and session matching is performed by the CP or in combo mode

On some SRX Series devices, an entire SPU cannot be dedicated for central point functionality, but a certain percentage of the SPU is automatically allocated for central point functionality and the rest is allocated for normal flow processing. When an SPU performs the function of central point as well as normal flow processing, it is said to be in combination, or mixed, mode.

The percentage of SPU dedicated to the central point functionality depends on the number of SPUs in the device. Based on the number of SPUs, there are three modes available on the SRX Series devices— small central point, medium central point, and large central point.

In small central point mode, a small percentage of an SPU is dedicated to central point functionality and the rest is dedicated to the normal flow processing. In medium central point mode, an SPU is almost equally shared for central point functionality and normal flow processing. In large central point mode, an entire SPU is dedicated to central point functionality. In mixed-mode, the central point and SPU share the same load-balancing thread (LBT) and packet-ordering thread (POT) infrastructure.

This topic includes the following sections:

Load Distribution in mixed 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 mixed-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 mixed Mode

The CPU processing power in a mixed-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 mixed-mode, CPU functionality takes a small portion of the cores, whereas "medium" SPU mixed-mode requires a larger portion of cores. The processing power for central point functionalities and flow processing is shared, based on the number of Services Processing Cards (SPC), as shown in Table 2. Platform support depends on the Junos OS release in your installation.

Table 2: mixed Mode Processing

SRX Series device

Central point mode with 1 SPC or SPC2

Central point mode with 2 or more SPCs or SPC2s

Central point mode with 1 or 2 SPC3s

Central point mode with more than 2 SPC3s

SRX1400

Small

Medium

NA

NA

SRX3400

Small

Medium

NA

NA

SRX3600

Small

Medium

NA

NA

SRX3400 (expanded performance and capacity license)

Small

Large

NA

NA

SRX3600 (expanded performance and capacity license)

Small

Large

NA

NA

SRX5600

Large

Large

Medium

Large

SRX5800

Large

Large

Medium

Large

SRX5400

Large

Large

Medium

Large

Note:

The mixed-mode processing only exists with SPCI on SRX1400, SRX3400, SRX3600, and SRX5000 line devices.

Understanding Enhancements to Central Point Architecture for the SRX5000 Line

Previously, for the SRX5000 line of services gateways, the central point was a bottleneck in device performance and scaling. When more Services Processing Cards (SPCs) were integrated into the system, the overall processing power increased linearly, but the system connections per second (cps) remained constant and could not be improved because of the single centralized point in the system. This severely impacted the overall system utilizations in both capacity and cps.

Starting with Junos OS Release 15.1X49-D30 and Junos OS Release 17.3R1, on SRX5000 line devices, the central point architecture is enhanced to handle higher connections per second (cps). The new central point architecture prevents data packets from going through the central point by off-loading session management functionalists to the Services Processing Unit (SPU). Therefore, data packets are directly forwarded from the network processing unit to the SPU instead of going through the central point.

The central point architecture is divided into two modules, the application central point and the distributed central point. The application central point is responsible for global resource management and loading balancing, while the distributed central point is responsible for traffic identification (global session matching). The application central point functionality runs on the dedicated central point SPU, while the distributed central point functionality is distributed to the rest of the SPUs. Now the central point sessions are no longer on the dedicated central point SPU, but with distributed central point on other flow SPUs.

Note:

The central point for SRX5000 line refers to the application central point, or the distributed central point or both, with respect to global resource management and load balancing, it refers to the application central point, whereas with respect to traffic identification and session management, it refers to the distributed central point (sometimes referred to the SPU as well).

Note:

The SNMP log and SNMP trap were generated by the central point with rate limit. Now, the SNMP log and SNMP trap are generated by the SPU or central point. As there is more than one SPU, the number of SNMP log and traps generated are more. To verify the number of connections per second (CPS) on the device run SNMP MIB walk nxJsNodeSessionCreationPerSecond command. The SNMP polling mechanism calculates the CPS value based on the average number of CPS in the past 96 seconds. So, if the CPS is not constant, the number of CPS reported is inaccurate.

Understanding Central Point Session Limit Performance Enhancements

Starting in Junos OS 15.1X49-D70 and Junos OS Release 17.3R1, a new session connection (conn-tag) tag option is available to allow you to add a flow filter to further distinguish GRPS tunneling protocol, user plane (GTP-U) flow sessions and Stream Control Transmission Protocol (SCTP) flow sessions.

The flow session connection tuple consists of a 32-bit connection tag that is used to uniquely identify GTP-U sessions and SCTP sessions that are not distinguishable by the six part tuple only. You can configure the system to include the session connection tag tuple to identify GTP-U sessions and SCTP sessions by adding the session connection tag to the standard six tuples that identify a session. The system determines the DCP for GTP-U/SCTP by hashing the session connection tag.

The central point architecture distributes GTP-U traffic handled by a gateway GPRS support node (GGSN) and SGSN pair on all SPUs by switching to tunnel endpoint identifier (TEID)-based hash distribution. To handle load-balancing issues, tag-based hash distribution is used to ensure even distribution of SCTP traffic from different associations among all SPUs. (The connection tag for GTP-U is the TEID and for SCTP is the vTag.)

Understanding Central Point Architecture Flow Support for GTP and SCTP

Starting in Junos OS Release 15.1X49-D40 and Junos OS Release 17.3R1, the central point architecture provides enhanced support for GPRS tunneling protocol, control (GTP-C), GPRS tunneling protocol, user plane (GTP-U), and Stream Control Transmission Protocol (SCTP).

The central point architecture, which is supported on the SRX5400, SRX5600, and SRX5800 devices, is enhanced to address the GTP-C message rate-limiting to protect gateway GPRS support node (GGSN) from GTP-C message flood, to prevent GTP-C packet drop issues during SGSN handover, and to distribute GTP-U traffic handled by a GGSN and SGSN pair on all SPUs by switching to tunnel endpoint identifier (TEID)-based hash distribution. Use the enable-gtpu-distribution command to enable or disable GTP-U session distribution. By default, the enable-gtpu-distribution command is disabled.

Connection-tag to flow session tuple is introduced to resolve GTP/SCTP load balance issue. All session including Distributed CP (DCP) session and SPU session are modified to accommodate connection-tag. The session creation have following tuple: src-ip, dst-ip, src-port, dst-port, protocol, session-token and connection tag.

The GTP ALG requires GTP-C sessions to be fixed by hashing GGSN IP addresses. The GTP ALG deny GTP-C session creation if the first packet is of uncertain direction, which will cause packet drop. To prevent the GTP-C packets from being dropped, a new flow session is created and the GTP-C traffic is allowed to pass even if the GGSN or SGSN direction is not determined. Later, the GGSN IP is determined using the correct SPU to create the flow session and age out the old session. The intermittent packets hitting the old session will be forwarded to the new SPU and be processed on the new session.

To handle load-balancing issues, tag-based hash distribution is used to ensure even distribution of GTP-U/SCTP traffic among all SPUs. A 32-bit connection tag is introduced that uniquely identifies the GTP-U and the SCTP sessions. The connection tag for GTP-U is the TEID and for SCTP is the vTag. The default connection-tag is 0. The connection tag remains 0 if it is not used by the sessions. Flow will determine connection tag for GTP-U/SCTP sessions and distribute them by hashing connection tag.

A SCTP association is a connection between two SCTP endpoints. Each SCTP endpoint identifies the association with a tag. During association setup (4-way handshakes), two SCTP endpoints exchange their own tags for packet receiving. During 4-way handshake, the receiver of INIT/INIT-ACK records the value of itag, and places into the vtag field of every SCTP packet that transmit within this association. Then the peer uses the vtag to validate the sender of this packet.

Flow sessions created after CP-Lite as follows:

SPU is selected by hash(tag), the Client to Server traffic is handled on hash (tagB) SPU then forwarded to hash (tagA) SPU. Server to Client traffic is handled on hash (tagA) SPU directly.

  1. After receive INIT packet, on hash (tagA) SPU:

    DCP-session A1: client=> server, SCTP, Conn ID: 0x0;

    Session A1: client=> server, SCTP, Conn ID: 0x0;

    On hash (tagB) SPU: no session.

  2. After receive INIT-ACK packet, on hash (tagA) SPU:

    DCP-session A1: client=> server, SCTP, Conn ID: 0x0;

    DCP-session A2: server => client, SCTP, Conn ID: tagA;

    Session A1: client=> server, SCTP, Conn ID: 0x0;

    Session A2: server => client, SCTP, Conn ID: tagA;

    On hash (tagB) SPU: no session.

  3. After receive COOKIE-ECHO packet, on hash (tagA) SPU:

    DCP-session A1: client=> server, SCTP, Conn ID: 0x0;

    DCP-session A2: server => client, SCTP, Conn ID: tagA;

    Session A1: client=> server, SCTP, Conn ID: 0x0;

    Session A2: server => client, SCTP, Conn ID: tagA;

    Session A3: client=> server, SCTP, Conn ID: tagB;

    On hash (tagB) SPU:

    DCP-session: client => server, SCTP, Conn ID: tag B

  4. After receive COOKIE-ACK packet, flow sessions have no change.

  5. After handshake succeeds, HEARBEAT will be send on all paths.

Understanding the Flow Session Connection Filter Option

Starting in Junos OS 15.1X49-D70 and Junos OS Release 17.3R1, a new session connection (conn-tag) tag option is available to allow you to add a flow filter to further distinguish GRPS tunneling protocol, user plane (GTP-U) flow sessions and Stream Control Transmission Protocol (SCTP) flow sessions.

The flow session connection tuple consists of a 32-bit connection tag that is used to uniquely identify GTP-U sessions and SCTP sessions that are not distinguishable by the six part tuple only. You can configure the system to include the session connection tag tuple to identify GTP-U sessions and SCTP sessions by adding the session connection tag to the standard six tuples that identify a session. The system determines the DCP for GTP-U/SCTP by hashing the session connection tag.

The central point architecture distributes GTP-U traffic handled by a gateway GPRS support node (GGSN) and SGSN pair on all SPUs by switching to tunnel endpoint identifier (TEID)-based hash distribution. To handle load-balancing issues, tag-based hash distribution is used to ensure even distribution of SCTP traffic from different associations among all SPUs. (The connection tag for GTP-U is the TEID and for SCTP is the vTag.)

Release History Table
Release
Description
15.1X49-D70
Starting in Junos OS 15.1X49-D70 and Junos OS Release 17.3R1, a new session connection (conn-tag) tag option is available to allow you to add a flow filter to further distinguish GRPS tunneling protocol, user plane (GTP-U) flow sessions and Stream Control Transmission Protocol (SCTP) flow sessions.
15.1X49-D70
Starting in Junos OS 15.1X49-D70 and Junos OS Release 17.3R1, a new session connection (conn-tag) tag option is available to allow you to add a flow filter to further distinguish GRPS tunneling protocol, user plane (GTP-U) flow sessions and Stream Control Transmission Protocol (SCTP) flow sessions.
15.1X49-D40
Starting in Junos OS Release 15.1X49-D40 and Junos OS Release 17.3R1, the central point architecture provides enhanced support for GPRS tunneling protocol, control (GTP-C), GPRS tunneling protocol, user plane (GTP-U), and Stream Control Transmission Protocol (SCTP).
15.1X49-D30
Starting with Junos OS Release 15.1X49-D30 and Junos OS Release 17.3R1, on SRX5000 line devices, the central point architecture is enhanced to handle higher connections per second (cps).