安全设备中的中心点架构概述

中心点 （CP） 架构具有两个基本的流量功能：负载平衡和流量识别（全局会话匹配）。如本主题所述，中心点架构要么以中心模式实现，其中所有会话分配和会话匹配都由中心点执行，要么在混合模式下实现，其中一定比例的服务处理单元 （SPU） 专用于执行中心点功能。

中心点的主要功能是将会话处理委派给其中一个 SPU。如果尚未建立会话，中心点将根据负载平衡标准选择一个 SPU 为流建立会话。如果会话已存在，中央点会将该流的数据包转发到托管该流的 SPU。如果 NPU 无法将数据包重定向到正确的 SPU，它也会这样做。

中央点维护一个全局会话表，其中包含有关特定会话的所有者 SPU 的信息。它充当整个系统的中央存储库和资源管理器。

注意：

中心点架构也在 CP-lite 模式下实施，在该模式下，会话管理从中心点卸载到 SPU，以提高性能和会话扩展。本主题不讨论 CP-lite。

SRX 系列防火墙类型与 Junos OS 版本相结合，可确定支持的模式。

表 1 列出了各种版本的 SRX 系列防火墙支持的中心点架构实施。

表 1：与 Junos OS 版本结合使用的 SRX 系列设备上的中心点实施

	SRX1400支持的模式	SRX3000 系列支持的模式	SRX5000线路上支持的模式
Junos OS Release 12.3X48 and Previous Releases	以 CP 为中心 混合模式	以 CP 为中心 混合模式	以 CP 为中心 混合模式
Junos OS Release 15.1X49-D10 Junos OS Release 15.1X49-D15 Junos OS Release 15.1X49-D20	不再支持这些 SRX 系列防火墙。	不再支持这些 SRX 系列防火墙。	以 CP 为中心 注意： NG-SPC 使组合模式过时。
Junos OS Release 15.1X49-D30 and later releases	不再支持这些 SRX 系列防火墙。	不再支持这些 SRX 系列防火墙。	精简版 注意： NG-SPC 使混合模式过时。

中央点在会话匹配时将数据包转发到其服务处理单元 （SPU），或者在数据包与任何现有会话不匹配时将流量分发到 SPU 进行安全处理。中心点架构以 CP 为中心的模式实现，其中所有会话分配和会话匹配都由 CP 或组合模式执行

在某些 SRX 系列防火墙上，整个 SPU 不能专用于中心点功能，但一定百分比的 SPU 会自动分配给中心点功能，其余部分分配给正常流量处理。当 SPU 执行中心点功能以及正常流处理时，它被称为组合或 mixed, 模式。

专用于中央点功能的 SPU 百分比取决于设备中的 SPU 数量。根据 SPU 的数量，SRX 系列防火墙有三种模式可用 — 小型中心点、中型中心点和大型中心点。

在小型中心点模式下，SPU 的一小部分专用于中心点功能，其余部分专用于正常流处理。在中等中心点模式下，SPU 几乎平均共享以实现中心点功能和正常流量处理。在大型中心点模式下，整个 SPU 专用于中心点功能。在混合模式下，中央点和 SPU 共享相同的负载平衡线程 （LBT） 和数据包排序线程 （POT） 基础结构。

本主题包括以下部分：

• 混合模式下的负载分配
• 在混合模式下共享处理能力和内存

从 Junos OS 15.1X49-D30 版和 Junos OS 17.3R1 版开始，在SRX5000系列设备上，中心点架构得到了增强，可以处理更高的每秒连接数 （cps）。新的中心点架构通过将会话管理功能员卸载到服务处理单元 （SPU），防止数据包通过中心点。因此，数据包直接从网络处理单元转发到 SPU，而不是通过中央点。

中心点架构分为应用中心点和分布式中心点两个模块。应用程序中心点负责全局资源管理和负载平衡，而分布式中心点负责流量识别（全局会话匹配）。应用程序中心点功能在专用中心点 SPU 上运行，而分布式中心点功能则分发给其余 SPU。现在，中心点会话不再位于专用中心点 SPU 上，而是将分布式中心点置于其他流 SPU 上。

注意：

SRX5000线路的中心点是指应用程序中心点或分布式中心点或两者，对于全局资源管理和负载平衡，它指的是应用程序中心点，而对于流量识别和会话管理，它指的是分布式中心点（有时也称为 SPU）。

注意：

SNMP 日志和 SNMP 陷阱由具有速率限制的中心点生成。现在，SNMP 日志和 SNMP 陷阱由 SPU 或中心点生成。由于存在多个 SPU，因此生成的 SNMP 日志和陷阱数量更多。要验证设备上每秒的连接数 （CPS），请运行 SNMP MIB walk nxJsNodeSessionCreationPerSecond 命令。SNMP 轮询机制根据过去 96 秒内的平均 CPS 数计算 CPS 值。因此，如果 CPS 不是恒定的，则报告的 CPS 数量是不准确的。

SRX5400、SRX5600和SRX5800设备上支持的中央点架构得到了增强，可以解决 GTP-C 消息速率限制问题，以保护网关 GPRS 支持节点 （GGSN） 免受 GTP-C 消息泛洪的影响，防止 SGSN 切换期间出现 GTP-C 丢包问题，并通过切换到基于隧道端点标识符 （TEID） 的散列分配，在所有 SPU 上分配由 GGSN 和 SGSN 对处理的 GTP-U 流量。使用 enable-gtpu-distribution 命令启用或禁用 GTP-U 会话分发。默认情况下，该 enable-gtpu-distribution 命令处于禁用状态。

引入流会话元组的连接标记是为了解决 GTP/SCTP 负载平衡问题。包括分布式 CP （DCP） 会话和 SPU 会话在内的所有会话都将被修改以容纳连接标记。会话创建具有以下元组：src-ip、dst-ip、src-port、dst-port、协议、会话令牌和连接标记。

GTP ALG 要求通过对 GGSN IP 地址进行哈希处理来修复 GTP-C 会话。如果第一个数据包的方向不确定，GTP ALG 会拒绝创建 GTP-C 会话，这将导致丢包。为了防止 GTP-C 数据包被丢弃，将创建一个新的流会话，并且即使未确定 GGSN 或 SGSN 方向，也允许 GTP-C 流量通过。稍后，使用正确的 SPU 确定 GGSN IP，以创建流会话并老化旧会话。到达旧会话的间歇性数据包将被转发到新 SPU，并在新会话上进行处理。

为了处理负载均衡问题，使用基于标签的哈希分配来确保在所有 SPU 之间均匀分配 GTP-U/SCTP 流量。引入了一个 32 位连接标记，用于唯一标识 GTP-U 和 SCTP 会话。GTP-U 的连接标记是 TEID，SCTP 的连接标记是 vTag。默认连接标记为 0。如果会话未使用连接标记，则连接标记将保持为 0。Flow 将确定 GTP-U/SCTP 会话的连接标记，并通过散列连接标记来分发它们。

SCTP 关联是两个 SCTP 终结点之间的连接。每个 SCTP 端点标识与标记的关联。在关联设置（4 次握手）期间，两个 SCTP 端点交换自己的标记以进行数据包接收。在 4 次握手期间，INIT/INIT-ACK 的接收方记录 itag 的值，并将在此关联内传输的每个 SCTP 数据包的 vtag 字段中放置。然后对等方使用 vtag 验证此数据包的发送方。

在 CP-Lite 之后创建的流程会话，如下所示：

SPU 由哈希（标记）选择，客户端到服务器的流量在哈希 （tagB） SPU 上处理，然后转发到哈希 （tagA） SPU。服务器到客户端的流量直接在散列 （tagA） SPU 上处理。

1. 接收 INIT 数据包后，在哈希 （tagA） SPU 上：

   DCP 会话 A1：客户端 = > 服务器、SCTP、连接 ID：0x0;

   会话 A1：客户端 = > 服务器、SCTP、连接 ID：0x0;

   在哈希 （标记 B） SPU 上：无会话。

2. 接收 INIT-ACK 数据包后，在哈希 （tagA） SPU 上：

   DCP 会话 A1：客户端 = > 服务器、SCTP、连接 ID：0x0;

   DCP 会话 A2：服务器 => 客户端、SCTP、连接 ID：标签A;

   会话 A1：客户端 = > 服务器、SCTP、连接 ID：0x0;

   会话 A2：服务器 => 客户端、SCTP、连接 ID：标签 A;

   在哈希 （标记 B） SPU 上：无会话。

3. 收到 COOKIE-ECHO 数据包后，在哈希 （tagA） SPU 上：

   DCP 会话 A1：客户端 = > 服务器、SCTP、连接 ID：0x0;

   DCP 会话 A2：服务器 => 客户端、SCTP、连接 ID：标签A;

   会话 A1：客户端 = > 服务器、SCTP、连接 ID：0x0;

   会话 A2：服务器 => 客户端、SCTP、连接 ID：标签 A;

   会话 A3：客户端=>服务器、SCTP、连接 ID：标签 B;

   在哈希 （标记 B） SPU 上：

   DCP 会话：客户端 => 服务器、SCTP、Conn ID：标记 B

4. 收到 COOKIE-ACK 数据包后，流会话没有变化。

5. 握手成功后，将在所有路径上发送 HEARBEAT。